[petsc-dev] Problems with PCReset_FieldSplit

[Dmitry Karpeyev]

It seems to me that PCReset_FieldSplit is buggy: it doesn't interact
correctly with named splits, particularly those set via
DMCreateFieldDecomposition() and the like.
Does anyone use PCFieldSplit with PCReset()?  It fails for me on
problems where splits are named and change (potentially even
appearing/disappearing) midway through the SNES iteration.

The reason seems to be this: PCReset_FieldSplit () will just about gut
the splits, leaving only the links themselves and the KSPs inside
(after KSPReset) hanging out there. Presumably, this is to save the
time allocating the links and creating the KSPs.

In the olden days the links were populated sequentially based on the
presumed (and immutable across PCReset) number of splits -- they were
matched up with strided ISs or DMComposite components based on their
implied position on the list.
When adding named splits, however, PCFieldSplitSetIS() will tack them
onto the end of the linked list, even though splits with those names
may already be out there (gutted by PCReset). Unless I'm missing
something, this is a problem (as confirmed by my code bombing).

One solution would be to make PCFieldSplitSetIS() search the linked
list for a split with the given name, and repopulate it, if found.
This doesn't solve the problem of a changing number of splits,
however.  A simpler, and more general, solution is to simply remove
the links altogether, reset the number of splits to 0, issetup =
PETSC_FALSE, etc.  That, of course, would eliminate the reuse that's
now being attempted, but I'm not sure how much we are really saving
there?  If it's okay to use this more radical approach, the fix is in
karpeev/fix-pc-fieldsplit-reset.  It's based on maint, and it would be
good for it to eventually end up as a patch to petsc-3.4.

If there are no objections, I'd like to have the fix branch merged into next.
Thanks.
Dmitry.