[petsc-dev] attaching field information to PetscLayout?

[Matthew Knepley]

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>