Benjamin Kirk wrote: >> 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?
Ah, by "nodes" I was referring to the three vertices that geometrically define the triangle. From my current understanding of subdivision surface FE, it would require Tri3 (or 4 node Quads) anyway, so it shouldn't even matter. When you take an unstructured triangulated mesh and you do one trisection first, you'll always end up with triangles that have at most a single vertex with valence other than 6. >> 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. Yes, the valence of existing nodes does not change. And yes, I agree, one should do the reordering right at the beginning (well, after the very first refinement, see above). The problem is, when I refine a triangle which has vertex 0 with, e.g., valence 5. When I refine it, the subtriangle connected to this vertex needs its internal _nodes to be rearranged such that _nodes[0] points again to the valence 5 vertex. > 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. Wow, I was not aware of this functionality. I'll have a look at it. > 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? That could be useful. But let me first see if I can work around this with the MeshTools. - Norbert ------------------------------------------------------------------------- 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
