Boyce Griffith wrote: > > 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); > > ?
current_local_solution is updated just by calling system.update(). This is done automatically when you do system.solve(), so you typically can just use current_local_solution without having to do anything special. Dave ------------------------------------------------------------------------------ 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
