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 :-) > I should have said "Sieve point" :) A mesh piece is a vertex, edge, face, cell, etc. > 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. I am not against that. Matt > > 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 > > -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110516/695f51c5/attachment.html>
