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 r
> 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?
>>
>> T
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
>
> 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?
>
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
-
This SF.Net email is sponsored by the M
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. appr
On Fri, Nov 14, 2008 at 8:28 AM, Norbert Stoop <[EMAIL PROTECTED]> 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 edge
