I have a proposal for a moderate/major change for how we handle knowledge
of subfields/splits in PETSc.
Currently one can call PCFieldSplitSetIS() or PCFieldSplitSetFields() to
indicate the splitting of vectors(fields) into subvectors(subfields). But, in
fact, the knowledge of what splits make sense really comes in the generation of
the vectors and matrices and it is bad that the user needs to stash that
information somewhere and then bring it out and attach it to the PCFieldSplit.
It is especially annoying if one is using a fieldsplit inside, say a multigrid
preconditioner, and one has to somehow get that information down into the inner
PC.
I propose an alternative. All Vecs and Mats currently have associated
PetscLayouts and when a Vec or Mat is duplicated the new Vec or Mat has that
same PetscLayout. I propose each PetscLayout have associated with it an
optional set of IS indicating the subfields/subvectors (note that this is sort
of already true when you set a blocksize larger than 1 the PCFieldSplit will by
default use the strides for subfields). Thus PCFieldSplit can get directly from
its matrix the appropriate default splits. Similarly the VecStrideXXX()
operations can be made more general becoming VecSubVecXXX(). We also add
VecGetSubVec() to get appropriated sized subvectors easily.
The end result will be a relatively small change in the PETSc API and for
most users little or absolutely no change, but the power to compose easily will
really increase.
Comments, objections, improvements?
Do this before or after the next release? (I guess the conventional wisdom
answer would be after?).
Barry
BTW: It is true that parallel vectors and matrices share the PetscLayout from
their parent object (via VecDuplicate/MatDuplicate) but this is not true to
sequential Vec and Mat. Before adding Field information to PetscLayouts I would
need to change all the sequential duplicates to get a reference to their
parents PetscLayout instead of creating a new one.
