> To do this in a smooth way, it > is best to internally renumber a triangle's nodes so that the > problematic node is the first node of the triangle (ie Elem::_nodes[0] > returns that node).
As Roy suggested, might it not be the case that *all* the nodes in a given triangle are problem nodes? > Any idea if this renumbering would break something else in libmesh? The edge ordering is implied by the node ordering, so if you have boundary conditions specified in terms of (elem_id,side_id) you'll need to attend to that. Since we always do refinement by subdivision, The valence of level-0 element vertices should be the same all the way down the tree (right?), so you'll certainly do yourself a favor by reordering before any refinement. Since you are ultimately interested in patches (?), I wonder if instead you might want to use the MeshTools::build_node_to_elem_map() members: http://libmesh.sourceforge.net/doxygen/namespaceMeshTools.php It will give you the element connectivity for a given node. You could then tear down this list and check the size() of the ith entry. If it is not 6, you've got a problem node. Also, I wonder if we could add an unsigned char to each Node called 'valence' or something like that... It might not change the overall sizeof(Node) due to padding. Would that be useful? -Ben ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
