VecLoadIntoVector and double dispatch

[Barry Smith]

On Dec 3, 2009, at 3:57 PM, Jed Brown wrote:

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

    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.

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

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

    I say this is nonsense, it ain't 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.

    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    (similar for  
reading in vectors with associated DMs).

in this way the viewing of your DM is nice encapsulated itself inside  
the DM object. 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.

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

    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.

    For a smart guy I'm surprised you've gone down this wrong track.

    Barry


>
>
> Jed