> 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


-------------------------------------------------------------------------
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

Reply via email to