VecLoadIntoVector and double dispatch

[Barry Smith]

On Dec 4, 2009, at 10:31 AM, Jed Brown wrote:

> On Fri, 4 Dec 2009 08:52:44 -0600, Barry Smith <bsmith at mcs.anl.gov>  
> wrote:
>>     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.
>
> Right, so I would get an error if I tried to use my viewer with them,
> that's the same as if I tried MatMult with a PETSc matrix.  But we  
> don't
> have to go edit src/vec/vec any time we put something new in mat/ 
> impls.

     This may be crux of the current discussion. You state that if one  
wants to have a vecview method attached to a Vec that does stuff  
specificly related to a particular DM then one needs to edit something  
in src/vec/vec and THAT IS VERY BAD. I totally agree with you that is  
very bad, but my point is that one does not need to edit anything in  
src/vec/vec. For example, the parallel vectors created with  
DACreateGlobalVector() have a new vecview() method that stores the Vec  
in a different way then the default (converting to global natural  
ordering). This is done by defining the method VecView_MPI_DA() with  
the DA definition and then stuck into the function pointer, this is  
done in DA directory, not the vec directorty. In inheritence language  
a DA Vec is inherited off a regular Vec.

    Thus I do not understand your whole business of DMVecView(). No  
need for this, just change the VecView() for your DM vectors to do  
whatever is needed for your DM. No editing of src/vec/vec code needed.

    Barry

>
>> (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).
>
> I also think it is good, at least for this problem domain.  Especially
> if the alternative looks anything like Trilinos/Epetra.
>
>>    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)).
>
> Okay, so most DM-level operations take the DM as an explicit argument.
> Since the Vec holds a reference to it's DM, this explicit argument
> appears to be redundant.  It's a bit of a knowledge loop because src/ 
> vec
> is not allowed to know about the DM, but there are other contexts  
> where
> Vec has a DM.
>
> Hypothetically now, what if all the Vec functionality that really  
> needed
> to reference the DM was actually implemented as
>
>  VecGetDM(vec,&dm);
>  DMDoSomethingWithVec(dm,vec,...);
>
> When the vector has no context, it would be calling a "null" DM that
> just represented plain Cartesian space.  This would avoid
> monkey-patching Vec to get control from the purely algebraic world to
> src/dm, but it would mean that src/vec could no longer be completely
> oblivious to the existence of DM.
>
> Similar to MatMAIJRedimension, you could reinterpret the vector in any
> isometric space.  This would achieve something similar to the
> native/super distinction without limiting to just two options, and
> without src/vec having any knowledge of "viewer format".  The  
> difference
> that now Vec output including the DM is a property of the Vec rather
> than the viewer.
>
>>   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.
>
> There is a false separation here, the viewer can only be used if the  
> Vec
> is created in a context that knows about the viewer.  It can't be used
> if VecView is the first time that code aware of the viewer comes in
> contact with the Vec.
>
>> Do you have suggestions on how one could improve the "native/super"
>> thing to satisfy you?
>
> Hmm, so I'm not sure it would be terrible for VecView to always  
> dispatch
> through DMVecView (which may call back into src/vec to move the  
> bytes in
> the underlying algebraic representation).  It's still not enough to
> enable a third-party viewer that works with existing DMs (assuming the
> viewer never has a chance to patch the DMs before being called).
>
> For a completely autonomous/symmetric dispatch, there could be a  
> global
> table
>
>  [(DMType, ViewerType), function]
>
> As long as this table was dynamic, any number of viewers, DMs, could
> register methods in the table.  Holes in the table could be filled in
> from third-party sources.  It would not require patching the object  
> you
> want to view (actually it would prevent patching objects so that they
> viewed differently without changing the type of the object).
>
>> 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.
>
> I understand this and it bugs me, but I'm having trouble finding a  
> place
> for another object that knows about both.  *Something* needs to be  
> able
> to wire up and interpret the file, some of the logic is currently with
> my DMView, but the stuff that doesn't belong there is in the Viewer.
>
> Jed