## Re: [Libmesh-devel] Element node renumbering

 Re: [Libmesh-devel] Element node renumbering From: Norbert Stoop - 2008-11-14 19:03:59 ```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 ```

 [Libmesh-devel] Element node renumbering From: Norbert Stoop - 2008-11-14 14:29:10 ```Hi, I started to hack together some code which will add subdivision surface based FEM to libmesh. Assuming the mesh is a triangulation, I need to take special care of triangles with nodes that do not all have 6 edges (a consequence of the subdiv. approach). 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). Any idea if this renumbering would break something else in libmesh? Thanks in advance, Norbert ```
 Re: [Libmesh-devel] Element node renumbering From: John Peterson - 2008-11-14 15:19:40 ```On Fri, Nov 14, 2008 at 8:28 AM, Norbert Stoop wrote: > Hi, > > I started to hack together some code which will add subdivision surface > based FEM to libmesh. Assuming the mesh is a triangulation, I need to > take special care of triangles with nodes that do not all have 6 edges > (a consequence of the subdiv. approach). 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). > Any idea if this renumbering would break something else in libmesh? > I guess it depends on how you number the rest of them... if they are still counter-clockwise it will probably be OK... -- John ```
 Re: [Libmesh-devel] Element node renumbering From: Roy Stogner - 2008-11-14 15:31:11 ```On Fri, 14 Nov 2008, Norbert Stoop wrote: > I started to hack together some code which will add subdivision surface > based FEM to libmesh. Assuming the mesh is a triangulation, I need to > take special care of triangles with nodes that do not all have 6 edges > (a consequence of the subdiv. approach). 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). Wait... which is "the problematic node"? A hanging node? A midedge node that isn't a hanging node? There could be two of either of those. And in any case, we do assume that the first three nodes of a triangle are vertices. > Any idea if this renumbering would break something else in libmesh? Don't change the local ordering (even from clockwise to counter-clockwise), and make sure to reorder any children and neighbor links at the same time... those are the only certain problems that come immediately to mind. But I wouldn't guarantee I'm not forgetting something. --- Roy ```
 Re: [Libmesh-devel] Element node renumbering From: Roy Stogner - 2008-11-14 15:34:06 ``` On Fri, 14 Nov 2008, Roy Stogner wrote: > Don't change the local ordering (even from clockwise to > counter-clockwise), Whoops! I mean from counter-clockwise to clockwise. --- Roy ```
 Re: [Libmesh-devel] Element node renumbering From: Benjamin Kirk - 2008-11-14 16:27:48 ```> 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 ```
 Re: [Libmesh-devel] Element node renumbering From: Norbert Stoop - 2008-11-14 19:03:59 ```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 ```
 Re: [Libmesh-devel] Element node renumbering From: Benjamin Kirk - 2008-11-14 19:38:10 ```> 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. Ah, I didn't catch that step... >>> 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. Now that we can guarantee for triangles. We use the "embedding matrix" concept to define child node locations in terms of the parent nodes, and looking at http://libmesh.sourceforge.net/doxygen/face__tri3_8C-source.php http://libmesh.sourceforge.net/doxygen/face__quad4_8C-source.php Shows you are good for tri3 and quad4. >> 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. Sadly, that's probably the 4th time in a couple weeks that comment has been made with regard to a feature... I guess the doxygen documentation is not very conducive to light reading, and our examples are simple enough as to not scare people off... -Ben ```
 Re: [Libmesh-devel] Element node renumbering From: Norbert Stoop - 2008-11-14 20:10:30 ```Benjamin Kirk wrote: >> 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. > > Now that we can guarantee for triangles. > > We use the "embedding matrix" concept to define child node locations in > terms of the parent nodes, and looking at > http://libmesh.sourceforge.net/doxygen/face__tri3_8C-source.php > http://libmesh.sourceforge.net/doxygen/face__quad4_8C-source.php > > Shows you are good for tri3 and quad4. Okay, very nice. Thanks! >>> 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. > > Sadly, that's probably the 4th time in a couple weeks that comment has been > made with regard to a feature... I guess the doxygen documentation is not > very conducive to light reading, and our examples are simple enough as to > not scare people off... While I use the doxygen docs a lot, they cannot easily provide a new user like me with the big picture. In particular, when parts of the code are not tightly linked to other parts, such as the MeshTools. Maybe overhauling the index page at http://libmesh.sourceforge.net/doxygen/index.php would help. For example, mesh operations are listed there, but there's no link to the MeshTools page. But I'm sorry for being already the 4th to make this comment... ;-) -Norbert ```