On May 16, 2011, at 9:16 PM, Dmitry Karpeev wrote: > On Mon, May 16, 2011 at 8:26 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: >> >> 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. > > Is PetscLayout a bona fide PetscObject now, so that composition is possible?
No, good point. Perhaps it will have to be converted. Damn I've spent 15 years trying to avoid making it a PetscObject (we'll still keep it as a private class not for general public use :-). Barry > > Dmitry. > > >> 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 >> >>
