On Sat, May 14, 2011 at 3:08 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > On May 14, 2011, at 2:47 PM, Dmitry Karpeev wrote: > >> On Sat, May 14, 2011 at 11:51 AM, Barry Smith <bsmith at mcs.anl.gov> wrote: >>> >>> ? ?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? >> >> Can these split ISs have communicators different from that of >> PetscLayout (this is something I use in GASM, >> for example)? > > ? Beats me. ?The ISs that define the splits could have a subcommunicator I > guess that is not either 1 or all.
What will be the meaning of overlapping splits? > > > ? Barry > >> >>> >>> ? ?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. >>> >>> > >
