VecLoadIntoVector and double dispatch
Barry Smith
bsmith at mcs.anl.gov
Thu Dec 3 15:09:03 CST 2009
On Dec 3, 2009, at 2:29 PM, Jed Brown wrote:
> Thanks for the explanation.
>
> On Thu, 3 Dec 2009 13:48:21 -0600, Barry Smith <bsmith at mcs.anl.gov>
> wrote:
>> This is wrong. What about a binary viewer method for the PETSc Vec
>> class implemented in SAMRAI? This definitely cannot rely on
>> VecGetArray() and belongs with the Vec class not the viewer classes
>> (which know nothing about SAMRAI even existing.
>
> I don't know what is in SAMRAI's Vec, but how about my HDF5 viewer
> that
> encodes information about the DM? The Vec doesn't know anything about
> my viewer existing.
But then your viewer must know about DM? That means that your
viewer knows about the internal structure of the vector?
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.
> Once we have more than one implementation of Viewer
> and more than one of Vec, no asymmetric solution can be perfect. I
> can
> live with static dispatch or other hacks for now.
I agree that no asymmetric solution is perfect, but I think it is
very useful to have a hierarchy of classes that "know" about other
classes; so the Vec class knows about Viewer classes but the Viewer
classes do not know about Vec classes. Otherwise you get nasty "loops
of knowledge" that are difficult to unwind.
Barry
>
> Jed
More information about the petsc-dev
mailing list