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 solution for
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
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
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
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
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
