On Tue, 8 Feb 2011, Kirk, Benjamin (JSC-EG311) wrote: > In general I think it may be dangerous to add dofs at the wrong time > - we don't currently build up a list of processors we need to > communicate with, but I could see that being a useful optimization.
In ParallelMesh we already make assumptions, which are nearly as strict as the send_list assumptions, about which parts of neighboring subpartitions a processor is going to need information for. There's probably other dangers that don't come to mind instantly. > In that case the list needs to be constructed after all dofs are > added to the list. I do like having APIs that have well-defined behavior that we can support. Occasional temporary use of "libmesh_experimental();" may be a necessary evil, but "libmesh_here_be_dragons();" ought to be avoidable from the start. > I'd think the best way to go is an API where the user can provide a > vector list of dofs to add, and internally we could then do error > checking as appropriate? Raw writeable access to the list just > feels dangerous. 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. --- Roy ------------------------------------------------------------------------------ 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
