VecLoadIntoVector and double dispatch

[Jed Brown]

On Thu, 3 Dec 2009 15:09:03 -0600, Barry Smith <bsmith at mcs.anl.gov> wrote:
>     But then your viewer must know about DM? That means that your  
> viewer knows about the internal structure of the vector?

Actually, it doesn't use any internal knowledge about the vector, but it
does know about the DM (which has metadata like connectivity).

>     I think this is very wrong. The viewer object is a lower level  
> object, it doesn't even know about linear algebra or vectors, nothing.  
> It should only expose a bunch of methods that the "higher level"  
> objects use. No viewer class show know about any Vec class or even the  
> existence of the Vec abstract class, but Vec classes can know about  
> the abstract Viewer class and even specific viewer classes.

I'm struggling with this and the "loops" are troubling.

So in a common scenario, we have a vector based on DMComposite which is
composed of, say, one DA and one unstructured DM (I call it FS).  It's
the TS that will be making the call to write model state out at special
time steps and will need to read the state back later in the adjoint
model.  The TS cannot know anything about the DM or implementation
details of the Vec, therefore it is only allowed to call VecView,
VecLoadIntoVector, and some viewer function to find time steps.

So there needs to be some chunk of code that knows how to wire up this
file with appropriate metadata, and some other chunks that can write
Vecs and DMs wherever the Viewer tells it to.  The first clearly belongs
with the Viewer, the latter doesn't clearly (to me) belong on either
side.  Since it only uses the VecGetArray level of information about the
vec, but uses an internal Viewer API, it seems more closely coupled to
the viewer.  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.

In this case, I have a new viewer so having dispatch in the other
objects is constraining because I would have to go modify every one that
I want my viewer to work with.  But if I was implementing a new Vec, I
wouldn't want the viewer to be in charge of dispatch because then I'd
have to go modify those viewers.

I'd love to hear your suggestions.


Jed