On Tue, 27 Jan 2009, Tim Kroeger wrote:
> I invented two new methods in NumericVector that might help you: One is
> NumericVector::is_ghosted(), that you can use to query whether a given vector
> does contain ghost dofs, and the other is NumericVector::init(const
> NumericVector&), which will
Dear Ben,
On Thu, 22 Jan 2009, Kirk, Benjamin (JSC-EG) wrote:
> I'd still like to ultimately change the PetscVector() to use
> VecCreateGhostWithArray() (or whatever the proper name is). In that
> approach we would allocate our own buffer (preferably in the NumericVector
> base class) and this b
Dear Roy,
On Thu, 22 Jan 2009, Roy Stogner wrote:
Currently, ex10 on 2 CPUs dies after the first refinement, when
operator() fails at TransientSystem::old_local_solution.operator()(i),
where i is outside of the local dofs on that processor, because at the
time the _global_to_local_map is empty.
Dear Roy/Ben,
Unfortunately, I did not have time today to make progress in this
issue. I will comment on your mails in the beginning of next week.
Best Regards,
Tim
--
Dr. Tim Kroeger
tim.kroe...@mevis.fraunhofer.dePhone +49-421-218-7710
tim.kroe...@cevis.uni-bremen.de
>> I think a
>> VecDuplicate followed by a VecCopy should do the trick, and I'll try
>> that out on the examples and on our few unit tests today if I find
>> time, but this is why I wanted other people looking at the problem;
>> I'm not familiar enough with PETSc's APIs
>
> Nor am I, as you see.
On Thu, 22 Jan 2009, Tim Kroeger wrote:
On Thu, 22 Jan 2009, Roy Stogner wrote:
and I'm not a fan of trial-and-error coding and debugging.
I agree than one shouldn't, but sometimes I tend to do so. (-:
It's especially a problem when you're stymied by the errors.
Currently, ex10 on 2 CP
On Thu, 22 Jan 2009, Roy Stogner wrote:
> On Thu, 22 Jan 2009, Tim Kroeger wrote:
>
>> I see. My idea is, since the vector is anyway cleared and re-initialized
>> in operator=, why not use PETSc's VecDuplicate() function.
>
> Can that be sufficient? The manual page says VecDuplicate doesn't
> c
On Thu, 22 Jan 2009, Tim Kroeger wrote:
> I see. My idea is, since the vector is anyway cleared and re-initialized in
> operator=, why not use PETSc's VecDuplicate() function.
Can that be sufficient? The manual page says VecDuplicate doesn't
copy the vector, just allocates storage for it. I
On Wed, 21 Jan 2009, Roy Stogner wrote:
I've found one of the bugs,
Great!
but don't know the best way to fix it.
With the attached patch, ex9 (at least) fails because the PetscVector
operator= is capable of taking a ghosted vector and producing a
non-ghosted vector copy with a non-empty glo
On Mon, 19 Jan 2009, Tim Kroeger wrote:
Please find attached the first version of "my part". I haven't tested it
because I had no idea how to do that. Well, at least it compiles. Perhaps it
is best that you guys implement your part now and then run one of the
examples on it, and in the case
Cc: Kirk, Benjamin (JSC-EG); libmesh-devel@lists.sourceforge.net
Sent: Mon Jan 19 12:56:11 2009
Subject: Re: [Libmesh-devel] Memory scaling of current_local_solution
On Mon, 19 Jan 2009, Tim Kroeger wrote:
> Please find attached the first version of "my part".
Looks good so far.
On Mon, 19 Jan 2009, Tim Kroeger wrote:
> Please find attached the first version of "my part".
Looks good so far.
> I haven't tested it because I had no idea how to do that. Well, at
> least it compiles. Perhaps it is best that you guys implement your
> part now and then run one of the example
Dear Roy/Ben,
Please find attached the first version of "my part". I haven't tested
it because I had no idea how to do that. Well, at least it compiles.
Perhaps it is best that you guys implement your part now and then run
one of the examples on it, and in the case that it doesn't work as
e
Dear all,
The method NumericVector::add(const T) seems to be completely unused;
at least the doxygen documentation states no reference to that method.
Actually, I'm quite sure the the implementation PetscVector::add(const
T) would not work for parallel vectors, because VecGetArray() supplies
a
14 matches
Mail list logo