On Thu, 3 Dec 2009 15:09:03 -0600, Barry Smith 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 metadat
Thanks for the explanation.
On Thu, 3 Dec 2009 13:48:21 -0600, Barry Smith 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
> (w
I'm sort of confused about vec->ops->loadintovectornative, this seems to
just be a way to let users provide *one* custom viewer on a particular
vector without breaking PETSc's own viewers. But it really doesn't
provide a reasonably solution for an intermediate library, or user code
with multiple v
On Dec 3, 2009, at 3:57 PM, Jed Brown wrote:
> On Thu, 3 Dec 2009 15:09:03 -0600, Barry Smith
> 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 v
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
> 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 be
On Dec 3, 2009, at 12:54 PM, Jed Brown wrote:
> I'm sort of confused about vec->ops->loadintovectornative, this
> seems to
> just be a way to let users provide *one* custom viewer on a particular
> vector without breaking PETSc's own viewers. But it really doesn't
> provide a reasonably soluti
