On Wed, 15 Jun 2016, Cody Permann wrote: > I'm afraid not, even restricting the conversation to active elements. > Only active neighbors on sides get their dofs ghosted, but point > neighbors are still kept as semilocal elements. > > Well this is good news. This means that this is not a libMesh bug! > What is the use for semi-local then? If it's not a record of what's > ghosted, what do people use it for?
Search me. IIRC I came up with the definition as the minimum necessary to allow certain topological queries, but I hadn't thought about what others would use the definition for. > Based on what little information I've given you about my problem, > what suggestion would you have for when about when I can expect to > safely access an off-processor DOF and when I cannot based on the > libMesh API? Hmm... if you loop over all neighbors and you find an active local element, then your DoFs should be ghosted. If you loop over all neighbors and you find an inactive element, then you could use Elem::which_side_am_i to get the opposing side, use Elem::active_family_tree_by_side to get the active elements there, and loop over those: if you find an active local element then your DoFs should be ghosted. --- Roy ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381 _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
