The DM and PetscLayout behind a Vec can be merged, with PetscLayout becoming the simplest DM implementation.<div>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</div>

<div>now that there is a PetscLayout.  But those that *want* to know, can obtain the underlying DM and start doing cool stuff</div><div>to the Vec.   In particular, DM is the natural place to inject geometric information, generalizing DMDA to the unstructured</div>

<div>case.  For example, a DM can allow to access the Vec data by "stencil", which in the DMDA case is the usual thing,</div><div>and in the unstructured mesh case is, say, element restrictions.  This would encapsulate the "expanded space" idea</div>

<div>that Jed described a while ago in a tentative unstructured API.  This would require, however, some iterator model,</div><div>which is a kind of flexible local fine-granularity "on demand" scatter.</div><div>

<br></div><div><br><br><div class="gmail_quote">On Tue, Dec 7, 2010 at 2:52 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@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 class="im"><br>
On Dec 7, 2010, at 2:41 PM, Jed Brown wrote:<br>
<br>
> On Tue, Dec 7, 2010 at 21:31, Dmitry Karpeyev <<a href="mailto:dkarpeev@gmail.com">dkarpeev@gmail.com</a>> wrote:<br>
> I actually prefer the model where a geometric object (e.g., a DA) controls the restriction (e.g., DAGlobalToLocalBegin, etc).<br>
><br>
> Okay, but does the user need to use something like DMSliced just to update a local form?<br>
><br>
> 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.<br>


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


<br>
  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.<br>
<div><div></div><div class="h5"><br>
<br>
<br>
<br>
> 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".<br>
<br>
</div></div></blockquote></div><br></div>