On 11 Nov 2014, at 04:28, Jed Brown <[email protected]> wrote: > Matthew Knepley <[email protected]> writes: >>> at which point the nullspace is not attached, no? >>> >> >> Crap, that is right. I think we should propagate the nullspace from pmat[1]. > > Uh, there is no reason pmat[1] can be expected to have the same null > space. pmat[1] is the zero matrix in some important cases, and the null > space of the Schur complement (or its SIMPLE-type approximation) depends > on boundary conditions in a different block (thus problematic for > segregated assembly). I've been unsuccessful so far in my search for an > elegant solution, but passing the null space along in this way is > encouraging overt lying and can be expected to break other algorithms as > well as any consistency tests we might add in the future.
OK, so it's sounds like this is probably a deliberate choice. I note that the
code currently does this:
fieldsplit.c:703
ierr = MatSetFromOptions(jac->schur);CHKERRQ(ierr);
ierr = MatGetNullSpace(jac->pmat[1], &sp);CHKERRQ(ierr);
if (sp) {
ierr = MatSetNullSpace(jac->schur, sp);CHKERRQ(ierr);
}
i.e. takes the nullspace from pmat[1] and hangs it on the schur complement. I
was under the impression that when I'm informing the field split setup of the
nullspace, composing the nullspace with the IS that defines split 1 was
informing the PC that the schur complement has this nullspace, but this
discussion now has me a little confused. I guess my best option is to user a
"user" PC for the schur complement, because then I can set everything up by
hand.
Cheers,
Lawrence
signature.asc
Description: Message signed with OpenPGP using GPGMail
