[petsc-users] Can't retrieve inner KSP from Schur complement

Barry Smith bsmith at mcs.anl.gov
Mon May 29 15:32:22 CDT 2017

   Likely the problem is that the inner objects do not yet exist when you are trying to set the options. It is kind of tricky to handle the construction of these multiple nested objects and when inner objects actually get created.

   Make sure you call KSPSetUp() on the outer KSP before you call this. But this may still not be enough to insure that this inner object has yet been created. Let us know.


I will add any error check for Na being null so it prints a useful error message instead of crashing.

> On May 29, 2017, at 3:24 PM, Lucas Clemente Vella <lvella at gmail.com> wrote:
> I want to set a custom convergence test for the inner KSPs of Schur complement method, so I am using PCFieldSplitGetSubKSP() to get the inner KSPs:
>     int n_subksp;
>     KSP *subksp = NULL;
>     PCFieldSplitGetSubKSP(s->pc, &n_subksp, &subksp);
>     assert(n_subksp == 2);
> But I get a segmentation fault on MatSchurComplementGetKSP(). From file src/ksp/ksp/utils/schurm.c (line 320):
> PetscErrorCode MatSchurComplementGetKSP(Mat S, KSP *ksp)
> {
>   Mat_SchurComplement *Na;
>   PetscFunctionBegin;
>   PetscValidHeaderSpecific(S,MAT_CLASSID,1);
>   PetscValidPointer(ksp,2);
>   Na   = (Mat_SchurComplement*) S->data;
>   *ksp = Na->ksp; // <<<<< segfaults on this line, 'Na' is an invalid pointer...
>   PetscFunctionReturn(0);
> }
> This is the stack trace given by valgrind:
> ==13559== Invalid read of size 8
> ==13559==    at 0x56B8780: MatSchurComplementGetKSP (schurm.c:320)
> ==13559==    by 0x55F5B08: PCFieldSplitGetSubKSP_FieldSplit_Schur(_p_PC*, int*, _p_KSP***) (fieldsplit.c:1367)
> ==13559==    by 0x5605187: PCFieldSplitGetSubKSP (fieldsplit.c:1869)
> ==13559==    by 0x166305: set_singular_convergence_test (solver-petsc.c:293)
> ### irrelevant calls, from inside my program
> ==13559==  Address 0x6c0 is not stack'd, malloc'd or (recently) free'd
> ==13559== 
> I tried doing this operation both before and after MatAssembly*() calls, and with both I get the same result. Petsc version is 3.7.5, installed from Ubuntu repository. Is this a bug? Or I am doing it wrong?
> -- 
> Lucas Clemente Vella
> lvella at gmail.com

More information about the petsc-users mailing list