<div class="gmail_quote">On Sat, Feb 25, 2012 at 13:10, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov">karpeev@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":2z1">I wrote this before the thread moved to petsc-dev, so there is some overlap with the below.<div><div>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.</div>


<div><br></div><div>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:</div><div>       DMGetFieldDMs(DM dm, PetscInt *fieldcount, DM **fielddms);</div>


<div>The field names can simply be the corresponding DM names, etc.  The fielddms can be lightweight, sharing the underlying</div><div>topology.  That's up to the implementation to arrange, though.  This addresses nested splits.</div>
</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2z1"><div>

<div><br></div><div>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 </div>


<div>       DMGetSplitDM(DM dm, const char *splitname, DM *splitdm);</div><div>Then calling DMGetFieldDMs on the splitdm retrieves the corresponding fields.</div><div>Again, splitdm and dm can share common data structures, as arranged  by the particular DM implementation.</div>


<div>The advantage of this approach over push/pop is that we can simultaneously use different splits of the same topology.</div><div><br></div><div>It is rather easy to apply the same scheme and have DMs serve up (overlapping) domain decompositions useful for (G)ASM.</div>


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


<div></div></div></div></blockquote></div><br>