On Fri, 4 Dec 2009 18:29:19 -0600, Barry Smith 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 X (including the DM
On Dec 4, 2009, at 10:31 AM, Jed Brown wrote:
> On Fri, 4 Dec 2009 08:52:44 -0600, Barry Smith
> 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
On Fri, 4 Dec 2009 08:52:44 -0600, Barry Smith 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 get an error if I t
On Thu, 3 Dec 2009 16:40:10 -0600, Barry Smith 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 DM information out
On Fri, Dec 4, 2009 at 8:52 AM, Barry Smith wrote:
>
> On Dec 4, 2009, at 2:58 AM, Jed Brown wrote:
>
> On Thu, 3 Dec 2009 16:40:10 -0600, Barry Smith
>> wrote:
>>
>>> The vector has a pointer to the DM so the VecView() for that
>>> derived vector class has access to the DM information. The
On Dec 4, 2009, at 2:58 AM, Jed Brown wrote:
> On Thu, 3 Dec 2009 16:40:10 -0600, Barry Smith
> 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 s
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
12 matches
Mail list logo
