Lawrence Mitchell <lawrence.mitch...@imperial.ac.uk> writes:
> 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. Matt and I have a long-running disagreement about nullspace handling in PETSc. He added the code that hangs it on an IS despite it not logically belonging on IS, simply because the implementation in PETSc happens to pass the IS along to the place he needed a nullspace. He's also making a bunch of assumptions about nullspaces agreeing in cases where there is no such guarantee (demonstrably, and in problems that we care about, but not on the problem he was solving at that time). Matt would be happy if someone fixed the code to handle nullspaces in a logically consistent way, but we can't just tear out his inconsistent code without having a replacement. Sadly, all the replacements I can think of are onerous for the user and potentially hard to implement/maintain. So I mostly stay quiet and work on other things, but it pains me every time a user grows a dependency on the abuse of ISs and perverse assumptions about nullspaces agreeing. I'd love to hear suggestions about how to get nullspace information into inner solvers without violating the object model. > I guess my best option is to user a "user" PC for the schur > complement, because then I can set everything up by hand. That isn't a bad choice.
signature.asc
Description: PGP signature
