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.
