On May 16, 2011, at 5:57 PM, Matthew Knepley wrote: > On Sat, May 14, 2011 at 10:14 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > In preparation for adding field information to PetscLayout (as discussed > below in the previous email) I have fixed up PETSc-dev so that > VecDuplicate(), MatDuplicate() and MatGetVecs() results in new objects that > reference the previous PetscLayouts (rather than produce new ones). Also, > inspired by a comment of Dmitry I have put the ISLocalToGlobalMapping mapping > and bmapping objects into the PetscLayout so that each individual Vec and Mat > doesn't need to mess with them. Please report any problems and if you find > places where new vectors are created directly rather than by duplication etc > report this as well. Note that these changes are all good things to do > independent of putting field information into the PetscLayout. > > For FEM stuff (like mixed elements, higher order, complicated bases), I need > layout information that maps > > mesh piece ---> (size, offset)
I have no idea what a mesh piece is nor how it can be indicated by only a size and an offset :-) Anyways, my thought is for "approach specific" stuff like this; one would put it in an object and then attach the object to the PetscLayout with ComposeObject. Now given any vector or matrix you can just pull out the particular information out of the PetscLayout which is shared by all the (associated) Vecs and Matrices. Only universally meaningful stuff like the fields would go directly into the PetscLayout. Barry > > I made a separate structure to contain this info, but it sounds like this > suped-up PetscLayout could contain it > instead. Is that feasible? > > Matt > > At this point I could add a PetscLayoutSetFields() or similar beasty. Some > possibilities > > PetscLayoutAddField(PetscLayout,name?,IS) to allow incrementally putting > them in or > > PetscLayoutSetFields(PetscLayout,n,names[]?,IS[]) to set them all at once > > and how would we get them into the PetscLayout that we usually don't > access directly. Have a > > PetscVecSetFields(Vec,n,names[]?,IS[]) and > PetscMatSetFields(Mat,n,names[]?,IS[]). > > One natural place to have set this information up is with the DMs. > For example DMDA with dof > 1 would have be default dof stride > fields; to allow other possibilities there could be DMDASetFields(). Also > Vecs and Mats with bs > 1 could be default get similar bs stride fields by > default. > DMComposite would by default have a field for each of the composed > DMs perhaps. > Likely each DM object should keep the root PetscLayouts that it > uses to create its vectors and matrices so all of its creations share a > common layout rather than the current model where each newly created vec or > mat from a DM gets a new PetscLayout (hmm, maybe I should fix the first). > > > Another issue is that there are other places where field information > should eventually be propagated. For example VecGetSubVector() and > MatGetSubMatrix/Matrices() new vectors matrices should get this information > from their parents (this way nesting of fieldsplit/bjacobi/asm/etc solvers > will become much easier and more automatic). And redoing all the > VecStrideXXX() routines to be more general for fields. > > Comments, suggestions, corrections? > > Barry > > > > > > > > On May 14, 2011, at 11:51 AM, Barry Smith 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? > > > > 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. > > > > > > > -- > What most experimenters take for granted before they begin their experiments > is infinitely more interesting than any results to which their experiments > lead. > -- Norbert Wiener
