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. 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. >> >>
