[petsc-dev] DMDA_*PERIODIC and DMDA_XYZGHOSTED

[Dmitry Karpeev]

The DM and PetscLayout behind a Vec can be merged, with PetscLayout becoming
the simplest DM implementation.
The user doesn't need to know there is a DM created (or increfed) every time
a Vec is created, just like they don't know
now that there is a PetscLayout.  But those that *want* to know, can obtain
the underlying DM and start doing cool stuff
to the Vec.   In particular, DM is the natural place to inject geometric
information, generalizing DMDA to the unstructured
case.  For example, a DM can allow to access the Vec data by "stencil",
which in the DMDA case is the usual thing,
and in the unstructured mesh case is, say, element restrictions.  This would
encapsulate the "expanded space" idea
that Jed described a while ago in a tentative unstructured API.  This would
require, however, some iterator model,
which is a kind of flexible local fine-granularity "on demand" scatter.



On Tue, Dec 7, 2010 at 2:52 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> On Dec 7, 2010, at 2:41 PM, Jed Brown wrote:
>
> > On Tue, Dec 7, 2010 at 21:31, Dmitry Karpeyev <dkarpeev at gmail.com>
> wrote:
> > I actually prefer the model where a geometric object (e.g., a DA)
> controls the restriction (e.g., DAGlobalToLocalBegin, etc).
> >
> > Okay, but does the user need to use something like DMSliced just to
> update a local form?
> >
> > Things like VecView already need a way to follow an upward link to a DM.
>  There is a delicate issue of circular dependencies if _p_Vec was given a
> slot for the DA.  On the one hand, I feel like it would be cleaner if every
> Vec had a link to _some_ DM, which, as far as the Vec is concerned, is just
> a "function space".  The default implementation would be flat Cartesian
> space.
>
>    I like this model for its consistency. The "default" DM is currently
> essentially PetscLayout. But have resisted making the model public because
> it is yet one more object class people need to learn about to do anything,
> forcing people to know about DM (or PetscLayout) before they can create a
> vector. Plus all Vecs have a PetscLayout (hidden) even if they also have a
> more sophisticated DM as well, I don't like that because I think it can be
> confusing to people that sometimes there are two "DMS".
>
>  IS, Vec, Mat, KSP (SNES and TS)  --> IS, DM, Vec, Mat, KSP. Yes it is just
> one more object but difficulty of use grows exponentially with number of
> object types.
>
>
>
>
> > On the other hand, it makes a dependency loop unless you always pass
> pairs (DM,Vec) around (ugly and weird), or (a very limited subset of) the DM
> API becomes part of the Vec "package".
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20101207/c1036af6/attachment.html>