In the projection part we loop over var/elem under the assumption that the var
types are different. That way the fe objects are not created over and over...
In my case (and I suspect most frequently) the vars are all the same, so it
really should just be a loop over the elements, get the interpolation weights,
and then apply them to all the vars. In my case that world speed this up by 5x.
Also, if each system projects all of its N vectors at once that could be a big
win - potentially another factor of N. The only drawback in this case is all
the old and new vectors must exist concurrently instead of sequentially, so it
costs more in RAM.
-Ben
----- Original Message -----
From: Roy Stogner <[EMAIL PROTECTED]>
To: Kirk, Benjamin (JSC-EG)
Cc: [email protected] <[email protected]>
Sent: Tue Sep 09 23:23:19 2008
Subject: RE: [Libmesh-devel] ProjectVector::operator()
On Tue, 9 Sep 2008, Kirk, Benjamin (JSC-EG) wrote:
> (1) eliminate the var/elem loop - just loop on elem and extract the dof
> indices for all vars at once.
Certainly a good idea. Hmm... why aren't we reversing the loops in
the main project_vector calculations? Just time and effort and fear
of regressing the code?
> (2) I believe the dof indices were getting added twice when
> (elem->refinement_flag() == Elem::JUST_REFINED)?
> (added inside the if statement and then again afterward?
Whoops - yeah, I wrote this patch in a hurry (in fact the first
version had a silly bug or two).
> (3) Thread-safe by converting to a parallel reduce. The other option
> would be to mutex the send_list but I expect that would perform much
> worse.
Thanks; I'd intended to mutex the send_list, but I don't use threading
so the whole problem completely slipped my mind.
> (4) reuse the same elem range for both threaded operations.
Good idea, I guess. Is constructing that range an expensive
operation? Is it something we should be caching in UnstructuredMesh?
> I'm gonna bang on it tomorrow with many processors & threads in various
> combination.
Thanks! It's clearly not the big win I hoped it would be, but even if
it's not getting at our current bottleneck, the problem it fixes would
be a bottleneck eventually.
---
Roy
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
