[petsc-dev] DM field interfaces

[Dmitry Karpeev]

I wrote this before the thread moved to petsc-dev, so there is some overlap
with the below.
A given problem with the same "topology" -- a mesh and a total index layout
-- might define several useful splits -- collections of fields. Each field
might have further useful splits. I have useful examples from my
interaction with Moose/libMesh, although these are rather general.  A field
is now represented by an IS.  We could try to put netsted split definitions
into ISs (e.g., ISNest), but I think it's much more natural to keep all
nestedness inside DMs -- we already have examples of this in the
coarsening, refinement for MG and a pretty well understood interaction of
this sort of DM hierarchy. with a hierarchy of PCs.

Thus, I think it would be useful for a DM to return a split as a list of
DMs, which can be further split, if necessary:
       DMGetFieldDMs(DM dm, PetscInt *fieldcount, DM **fielddms);
The field names can simply be the corresponding DM names, etc.  The
fielddms can be lightweight, sharing the underlying
topology.  That's up to the implementation to arrange, though.  This
addresses nested splits.

We could use the same mehanism to implement alternative splits on the same
topology  -- these are different DMs sharing the topology internally.
 Instead of pushing and popping splits, they can be retrieved by name as
       DMGetSplitDM(DM dm, const char *splitname, DM *splitdm);
Then calling DMGetFieldDMs on the splitdm retrieves the corresponding
fields.
Again, splitdm and dm can share common data structures, as arranged  by the
particular DM implementation.
The advantage of this approach over push/pop is that we can simultaneously
use different splits of the same topology.

It is rather easy to apply the same scheme and have DMs serve up
(overlapping) domain decompositions useful for (G)ASM.
I'm now implementing both of these schemes (fieldsplit and subdomains) on
top of libMesh, but the code resides in the libMesh source tree to avoid a
circular dependence: as designed right now libMesh depends on PETSc.  The
API has to live in DM, though.


On Sat, Feb 25, 2012 at 12:36 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> On Feb 25, 2012, at 12:13 PM, Jed Brown wrote:
>
> > [migrating from petsc-maint]
> >
> > > What interface are we going to use for splitting out a DM for a vector
> > > field in a larger system? How do we get the bs=2 velocity DM out of the
> > > lid-driven cavity's bs=4 velocity, vorticity, and temperature DM?
> > >
> >
> >  again this is irrelevent here because the same issue is true for the
> ISs.
> >
> >  But
> >
> >  I explained this in my previous email:  DMPushSubDMType(DM,"name of a
> type of splitting like u,v,p or velocity,p"); DMPopSubDMType();  it is not
> perfect but a start. See that email for more details.
> >
> > // Conservative gas dynamics with fields ordered as [rho, rho*u, rho*v,
> rho*w, E]
> > DMGetFieldSplitting(dm,"conservative-vector",&fscons); // creates if it
> doesn't exist
> > DMFieldSplittingAddField(dm,fscons,"rho",{0});
> > DMFieldSplittingAddField(dm,fscons,"momentum",{1,2,3});
> > DMFieldSplittingAddField(dm,fscons,"Energy",{4});
> >
> > DMGetFieldSplitting(dm,"primitive-vector",&fsprim);
> >
> DMFieldSplittingSetPF(dm,fsprim,UserEquationOfStatePF,UserEquationOfStateInversePF);
> > DMFieldSplittingAddField(dm,fsprim,"velocity",{0,1,2});
> > DMFieldSplittingAddField(dm,fsprim,"pressure",{3});
> > DMFieldSplittingAddField(dm,fsprim,"Temperature",{4});
> >
> > If a transform is not specified, the indices would address the original
> state variables.
>

This API is for constructing splits, rather than pulling them out.
The two APIs do not conflict, but certain implementations might already
have "naturally defined" splits
(e.g., in libMesh by variable name).

Dmitry.

>
>    Jed,  It also makes it impossible to handle bizare things where for one
> spitting you want a subset of one thing actually in another thing. So why
> not use IS to define the names, this gives complete flexibility. Also this
> above is not adding fields: you are just giving names to subsets of fields
> indicated by the original numbering of fields.  Which is fine, but has
> confusing names (you are not AddField just naming it). My suggestion is
> just a more or less a concise way of doing what you are doing without the
> need for YET ANOTHER CLASS (fcons).
>
> >
> > Then PCFieldSplit and eventual nonlinear and time-stepping splitting
> methods would call
> >
> > DMGetFieldSplitting(dm,&nsplits,&splits);
> > // choose split number to use
> > split = splits[splitidx];
> > DMFieldSplittingGetName(dm,split,&splitname);
> >
> DMFieldSplittingGetFields(dm,split,&pf,&pfinv,&nfields,&isfields,&dmfields);
>
> I do not like this approach based on requesting by name, just push your
> name and then pop it. This way something "above" in the call stack can push
> to the right one then something further down can use it without having to
> know its name (sort of like your "default" split) but the push allows
> changing the default. You kind of assume that the guts is suppose to know
> what name to use?  // choose split number to use how is some PC deep inside
> suppose to know this?
>
>  I realize my proposal was not complete on detail.  I'm suggesting changes
> to your detail.
>
>  Barry
>
> >
> > If pf is not NULL, apply PF to the state variables, then isfields[i]
> denotes what to extract in order to live in dmfields[i], pfinv is needed to
> put a contribution back into the coupled dm.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120225/e9ec26c8/attachment.html>