Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-28 Thread Roy Stogner
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

Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-27 Thread Tim Kroeger
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

Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-27 Thread Tim Kroeger
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.

Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-23 Thread Tim Kroeger
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

Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-22 Thread Kirk, Benjamin (JSC-EG)
>> 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.

Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-22 Thread Roy Stogner
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

Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-22 Thread Tim Kroeger
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

Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-22 Thread Roy Stogner
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

Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-22 Thread Tim Kroeger
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

Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-21 Thread Roy Stogner
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

Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-19 Thread Kirk, Benjamin (JSC-EG)
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.

Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-19 Thread Roy Stogner
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

Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-19 Thread Tim Kroeger
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

Re: [Libmesh-devel] Memory scaling of current_local_solution

2009-01-16 Thread Tim Kroeger
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