On 4/14/10 10:45 AM, Roy Stogner wrote:
>
> On Wed, 14 Apr 2010, Boyce Griffith wrote:
>
>> I am not sure I understand exactly which DOFs wind up in get_send_list().
>
> Non-local DoFs on local elements, non-local DoFs on elements which
> neighbor local elements or meet local elements at at least one node,
> and non-local DoFs which are dependencies (through constraint
> equations) of any local or other ghost dof.
>
> In other words, a superset of the ghost_dofs you're creating, which
> only includes the first category. In our case that assertion is fine;
> in yours it should always fail on processor 0, and could potentially
> fail on any processor except the highest ranked.
>
> So our assertion is overzealous... but on the other hand, although
> what you're doing isn't a bug, it's probably unnecessary - could you
> just use current_local_solution? That should have a superset of the
> data you need. ---
> Roy
I think I'm starting to understand a little better how this works...
If I collect the needed ghost DOFs and use
solution->localize(system->current_local_solution, my_ghost_dofs);
it looks like only the requested ghost nodes are communicated. Is that
correct? Or should I just stick with using
solution->localize(system->current_local_solution);
?
Thanks!
-- Boyce
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
