On Fri, 4 Dec 2009 18:29:19 -0600, Barry Smith bsmith at mcs.anl.gov wrote:
This may be crux of the current discussion.
This part was actually orthogonal to the extensible double dispatch
issue which was:
It should be possible for VecView(X,V) to invoke a third-party viewer
V even when
On Thu, 3 Dec 2009 16:40:10 -0600, Barry Smith bsmith at mcs.anl.gov wrote:
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
On Dec 4, 2009, at 2:58 AM, Jed Brown wrote:
On Thu, 3 Dec 2009 16:40:10 -0600, Barry Smith bsmith at mcs.anl.gov
wrote:
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
On Fri, Dec 4, 2009 at 8:52 AM, Barry Smith bsmith at mcs.anl.gov wrote:
On Dec 4, 2009, at 2:58 AM, Jed Brown wrote:
On Thu, 3 Dec 2009 16:40:10 -0600, Barry Smith bsmith at mcs.anl.gov
wrote:
The vector has a pointer to the DM so the VecView() for that
derived vector class has access
On Fri, 4 Dec 2009 08:52:44 -0600, Barry Smith bsmith at mcs.anl.gov wrote:
This is not accurate. The SAMRAI vector class does not implement
it. Yes, this means the SAMRAI vector class cannot use any PETSc built
in matrix classes, but that is ok it provides its own.
Right, so I would
On Dec 4, 2009, at 10:31 AM, Jed Brown wrote:
On Fri, 4 Dec 2009 08:52:44 -0600, Barry Smith bsmith at mcs.anl.gov
wrote:
This is not accurate. The SAMRAI vector class does not implement
it. Yes, this means the SAMRAI vector class cannot use any PETSc
built
in matrix classes, but
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
12 matches
Mail list logo
