On Feb 8, 2011, at 11:58 AM, Roy Stogner wrote: > Is there a less arbitrary way to describe the potential needs for an > expanded send_list? Wider stencils, e.g.? If there's a feature that > could go into the library itself it would be better to do that than to > break encapsulation.
I've been thinking about this a little bit as well. If there were a generic way to "connect" two dofs that aren't geometrically connected.... I think all of this would take care of itself. Then the send_list could get populated correctly.... sparsity patterns could get calculated properly.... and ghosted elements in ParallelMesh could be handled automatically. I would be willing to take a shot at implementing such a thing if we can decide on where it should go. This initial line of questioning about the send_list was just to get started down this path. We have fairly extensive needs in this area.... so we already have a lot of work planned in this direction. I think for now I will add the ability to attach a vector to the dof_map for off processor dofs that you need on your local processor. I will probably process this vector at the beginning of DofMap::prepare_send_list(). We can see where it goes from there. A quick question while we're on the subject. How does ParallelMesh decide what to ghost? Is it based on the stencil? Is there a similar way to the send_list to add more elements to the list that is ghosted? I just haven't looked at ParallelMesh yet... Derek ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
