[petsc-dev] attaching field information to PetscLayout?

[Matthew Knepley]

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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110516/4c171870/attachment.html>