Dear Roy,
On Thu, 5 Feb 2009, Roy Stogner wrote:
> On Thu, 5 Feb 2009, Tim Kroeger wrote:
>
>> (3) It so happened that I looked at PetscVector::operator=(const
>> std::vector& v) and noticed that in the ghosted case, it might be
>> appropiate to set _is_closed to false. This is because for gho
On Thu, 5 Feb 2009, Tim Kroeger wrote:
> (1) In the ghosted version of PetscVector::init(), you have placed an assert
> that checks whether the mesh is disjoint. Why is this necessary?
No - it's an assert that checks whether someone's trying to initialize
a disjoint ghosted vector, which shoul
On Tue, 3 Feb 2009, Roy Stogner wrote:
> The part of the code that really *is* a regression is attached, as
> yet-another patch version. As far as I can tell, the most prominent
> (but hopefully increasingly lonely) current bug is that
> PetscVector::localize() doesn't seem to properly update a G
Dear Roy,
Thank you for your work and your patch.
I have looked at it and the following comments:
(1) In the ghosted version of PetscVector::init(), you have placed an
assert that checks whether the mesh is disjoint. Why is this
necessary?
(2) In PetscVector::close(), I currently wonder wh
On Tue, 3 Feb 2009, Roy Stogner wrote:
The part of the code that really *is* a regression is attached, as
yet-another patch version. As far as I can tell, the most prominent
(but hopefully increasingly lonely) current bug is that
PetscVector::localize() doesn't seem to properly update a GHOSTE
On Sat, 31 Jan 2009, Roy Stogner wrote:
On Sat, 31 Jan 2009, Tim Kroeger wrote:
On Fri, 30 Jan 2009, Roy Stogner wrote:
I think we need another argument to init. Probably a boolean with a
sane default value so as not to break API compatibility, but I'm not
sure on the details yet.
What a
On Sat, 31 Jan 2009, Tim Kroeger wrote:
> On Fri, 30 Jan 2009, Roy Stogner wrote:
>
>> I think we need another argument to init. Probably a boolean with a
>> sane default value so as not to break API compatibility, but I'm not
>> sure on the details yet.
>
> What about an enum type for that? It
Dear Roy,
On Fri, 30 Jan 2009, Roy Stogner wrote:
> I think we need another argument to init. Probably a boolean with a
> sane default value so as not to break API compatibility, but I'm not
> sure on the details yet.
What about an enum type for that? It could take the values AUTOMATIC
(which