VecLoadIntoVector and double dispatch

[Matthew Knepley]

On Fri, Dec 4, 2009 at 8:52 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> On Dec 4, 2009, at 2:58 AM, Jed Brown wrote:
>
>  On Thu, 3 Dec 2009 16:40:10 -0600, Barry Smith <bsmith at mcs.anl.gov>
>> wrote:
>>
>>>   The vector has a pointer to the DM so the VecView() for that
>>> derived vector class has access to the DM information.  The same
>>> viewer object can be used with a bunch of different sized Vecs since
>>> it gets the DM information out of each vector. With your model when
>>> the DM info is attached to the viewer you need to pass in a different
>>> viewer for different vectors (of different sizes). This is just plan
>>> nuts.
>>>
>>
>> The DM info is not attached to the viewer, I have plain Vecs with a DM
>> composed so it can call DMView as in your snippet below.  The viewer
>> holds no state with regard to the DM.  But VecView_MyViewer_DM needs to
>> get called somehow,
>>
>
>    Agreed.
>
>
>  it will in turn call DMView and use an internal
>> Viewer API so that the file has a connection from the Vec to the DM.
>>
>>    I say this is nonsense, it ain't more closely coupled to the viewer.
>>>
>>
>> VecGetArray is public, all vectors have to implement it in order to
>> function in PETSc.
>>
>
>    This is not accurate. The SAMRAI vector class does not implement it.
> Yes, this means the SAMRAI vector class cannot use any PETSc built in matrix
> classes, but that is ok it provides its own. (note also that PETSc allows
> incomplete implementations of abstract classes where a new class
> implementaiton simply does not provide some methods and errors are generated
> if one tries to use them; I think this is a great design feature because it
> allows many-method base abstract classes, but I realize most of the
> computing world would be shocked and disgusted by this design feature).
>
>
>
>  The internal Viewer API to write the bytes of a Vec
>> with some connection to a DM is not public in the sense that users never
>> call it directly and no other viewers implement it.  You can substitute
>> any other Vec and this code will still write it correctly because your
>> Vec would be broken if it didn't implement VecGetArray [1].
>>
>> DM currently monkey-patches Vec to set ops->view and
>> ops->loadintovector, but it doesn't rely on the implementation of Vec
>> (the definition of Vec_Seq/MPI is never used in src/dm) and in principle
>> DACreateGlobalVector could call VecSetFromOptions so that it's actually
>> operating with any Vec type (e.g. the Vec could implement it's
>> operations on a GPU, only bringing the values to the CPU for
>> VecGetArray).  Many viewers (formats) have no special representation of
>> vectors that come from a DM [2] which is the reason for having
>> ops->viewnative and ops->loadintovectornative.
>>
>>  But somehow, calling VecView needs to be able to call the viewer
>>>> with enough context for the viewer to wire up the metadata.  Note
>>>> that the coordinates of the nodes in the DM are part of the vector
>>>> (it's an ALE formulation) so the metadata is nontrivial.
>>>>
>>>
>>>   Each vector has a pointer to its DM (DMComposite etc) so its
>>> viewer can dump/read that info when needed. In fact, when writing a
>>> vector it could do something like
>>>
>>> myvecview(Vec v,Viewer viewer)
>>> {
>>>    DM dm = getreferencetoDMfrom(v);
>>>    DMView(dm,viewer);
>>>    ... now dump my vector with writes or whatever
>>>
>>
>> My code looks exactly like this, my point is that the elided part
>> involves only the public Vec API, but a private Viewer API.  I can put
>> this chunk of code anywhere, but it needs changes when I make private
>> changes to the viewer, it doesn't need anything when I make private
>> changes to the DM or Vec (it doesn't even need to know the types of
>> those objects).  It is currently sitting with my DM, mostly because I
>> wrote the DMView first.
>>
>>  You have to admit that it would be crazy to have the DM viewer method
>>> stored inside a viewer object which seems to be what your model is.
>>>
>>
>> I wish I could get the dispatch with a symmetric relationship, but in
>> lieu of that, I don't especially care where the function pointer is,
>> what matters is that there is a way to get DMView_MyViewer_YourDM
>> called [3].  As long as dispatch is happening via PetscTypeCompare against
>> all the known types, we are restricted in that we either have no way to
>> use a third-party Viewer, or no way to view a third-party DM.  The
>> current choice is the former; I don't think it's inherently superior,
>> it's just a choice of which component can be extended without modifying
>> every object it touches.
>>
>> If I was distributing a binary-only viewer plugin, I would have no
>> choice but to put all these methods in with the viewer (but I would
>> currently have no way to get them called).  Note that a viewer can be
>> very functional without ever using a private API or looking underneath
>> obj->data.  With all other PETSc objects (DM not so much because nobody
>> works with the generic DM interface), I can distribute a binary-only
>> implementation which is first class after dynamic loading.
>>
>> My DMView is packaged up with my DM because it needs to know many
>> internal details of the DM, but the higher level logic about how to
>> write a time-dependent file with association between Vecs and DMs and
>> possibly other objects is currently with my viewer.  Now I need to write
>> DMView_MyViewer_DMComposite, but I won't be able to get it called
>> without modifying DMComposite (not okay since my viewer is not part of
>> PETSc).
>>
>>    You know my answer. The Viewers are abstractions of file IO, ;
>>> except instead of having only methods like read()/write() bytes it has
>>> somewhat "higher level" operations. Note: these methods can include
>>> graphics operations for example that are still essentially like
>>> writes(). YOU are making the viewers into these strange "all knowing"
>>> beasts which I think is wrong.
>>>
>>
>> Current PETSc viewers put minimal metadata and associations into a file,
>> the application is mostly responsible for "knowing" what was in the file
>> and wiring everything up correctly.  I'm trying to get more of this in
>> the file, partly to go with a VisIt plugin that is not tied to a
>> specific model.  I don't want to maintain a bunch of manual calls to
>> HDF5 to walk this file in the VisIt plugin especially when this
>> functionality is useful in other contexts [4].  I also hate C++.  ;-)
>>
>> So I've been putting stuff like walking the header and attributes to
>> find out what's there, selecting a time step, etc., into my viewer.  The
>> viewer is able to offer up information like which fields are available
>> on which meshes, the plugin is a wrapper that uses this, DMLoadIntoDM
>> (but not this elegant), VecLoadIntoVector, etc., and stuffs it into
>> avt/vtk data structures.  Note that this plugin makes no direct calls to
>> HDF5 and uses only the public API of the Viewer, DM, and Vec.
>>
>
>   Ok so you are deriving a new Viewer that implements much higher level
> operations that are particular to PETSc (since it knows about Vecs and DMs).
> This is perhaps reasonable. But the vecload/view methods still belong in the
> Vec object :-)
>
>
>
>> Jed
>>
>>
>> [1] In my view, a Vec is just an element of some finite dimensional linear
>> space.  If you want to use a special format, or stuff extra info in
>> there to make function evaluation easier or some operation faster,
>> that's fine, but it's still just an element of this linear space and it
>> better satisfy the appropriate axioms.  The linear space that this
>> vector lives in is defined by the DM and we need this to do anything
>> useful (like visualization) with the vector.
>>
>
>
>   To the algebraic solvers I agree a " Vec is just an element of some
> finite dimensional ....." (since that is all the solvers need to know about
> them).  But to a specific application a Vec can be thought of as the linear
> algebra beast PLUS all kinds of grid information etc (like the DM).  So I
> think of a (application) Vec in the application as basically derived off of
> two classes:  the linear algebra beast PLUS a DM (it is implemented as a
> isA(linear algebra beast) and hasA(DM beast)).  This is why I feel so
> strongly that the VecView class that also reads/writes stuff related
> specifically to the Vec belongs with the Vec, not with the Viewer.
>

I would like to point out here that the notion of a Vec as a member of a
vector space is very often in adequate. What we really want is a section of
a fiber bundle. This
is much more appropriate for most computational settings. That is why we
want grid information to tag along with the Vec.

  Matt


>  Regarding where code needs to be changed/where : The reason for the
> "native/super" support for the VecLoadIntoVector() (which I admit is
> terribly crude and ugly) is exactly so that one can implement a new
> loader/writer directly for a specific Vec/DM combination IN THE APPLICATION
> CODE or another library. One does not have to add it to src/vec/vec/impls
> Do you have suggestions on how one could improve the "native/super" thing
> to satisfy you?
>
> As I said before a Viewer in PETSc is just an abstraction/generalization of
> a file pointer with read/write methods on the file pointer. So it disturbs
> me that a method in a Viewer would even know what a Vec. It leads to these
> loops of knowledge that make code much more complicated. I would do anything
> to prevent these loops of knowledge I consider them so troublesome.
>
>   Barry
>
>
>
>
>
>
>> [2] Or the Vec doesn't use information about the DM when viewing on that
>> format if you like, I think this relationship is symmetric and
>> conceptually owned by neither.
>>
>> [3] I think the location of the source for DMView_MyViewer_YourDM is
>> mostly a packaging and distribution matter rather than a design matter.
>> I don't see a problem with it being distributed independently of either
>> MyViewer or YourDM (except for the technical issue of how it announces
>> it's existence).
>>
>> [4] It's all slightly complicated by the fact that for visualization,
>> it's important to be able to read chunks of the domain independently,
>> whereas the analysis code would prefer to only define proper collective
>> operations.
>>
>
>


-- 
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20091204/df374477/attachment.html>