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