[petsc-dev] DM field interfaces

[Jed Brown]

On Sat, Feb 25, 2012 at 13:10, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:

> 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.
>

There are two concepts, defining what the space for a given split _is_ and
how to get the part of the current state is needed to get a vector living
in that space. The IS is a rudimentary way to define what part is needed.
(You can use VecGetSubVector(X,isfield,&Xfield) or other methods to
reference that part of the state.) Unfortunately, it's not sufficient even
for a linear change of basis. An IS combined with a PF is sufficient for
non-mixed spaces. Mixed/staggered spaces need even more because the
transformation is defined through quadrature and projection. Maybe the
transformation should be entirely handled by the DM instead of giving the
user objects that apply the transformation.

But is the interface going to be DMTransformVec(dm,X,Y,dmt,Yt) that
transforms the perturbation Y to the state X into transformed variables
according to dmt? Or should we be getting back an object that does this
sort of transformation, so that we can amortize some setup coming from
matching dmt relative to dm? (Note that we also need an inverse
transformation.)


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