VecLoadIntoVector and double dispatch

[Jed Brown]

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.

> (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