Changes to C0 polyhedron tetrahedralization loops #4359
Conversation
having users separate blocks manually
GiudGiud
force-pushed
the
PR_poly_fixup
branch
2 times, most recently
from
5990f8c to
45a4142
Compare
GiudGiud
changed the title
| if (local_tet_quality[j2] == 0 || local_tet_quality[j2] == far_node) | ||
| { | ||
| nodes_by_geometry.erase(geometry_it); | ||
| has_skipped_adding_tets_and_retriangulating = true; |
There was a problem hiding this comment.
this is the saddest part of this PR. If we could still work with a valid surface mesh it would be a lot safer
unfortunately I seem to need this for every planar 4 node face, we always end up with an empty final tet
There was a problem hiding this comment.
unfortunately I seem to need this for every planar 4 node face, we always end up with an empty final tet
Oh, man - are we getting hit again by the nastiest open secret of tet meshing?
It is not always possible to generate a mesh that has only non-degenerate tets and conforms to an existing triangulation, unless we add at least one "Steiner point" on the volume interior! See this horrifyingly simple example: https://github.com/libMesh/libmesh/blob/devel/tests/geom/elem_test.h#L224-L240 I think this is probably why it's so hard to find a tet mesher that doesn't habitually add interior points and screw up Yaqi's plans: if you know you're sometimes going to need to add points just to make a mesh possible, why hesitate to add points to make a mesh better?
I fear the only completely robust solution for our polyhedra code may be to add a new element (C0IPPolyhedron? I'd hope to come up with a better name...) that adds a single Interior Point, after which getting a nice tetrahedralization becomes trivial.
But in the short run, if you're allowed to swap diagonals then I think you can generally fix the problem with some diagonal swapping.
Is this PR ready for review now that it's no longer marked WIP?
There was a problem hiding this comment.
Happy New Year!
But in the short run, if you're allowed to swap diagonals then I think you can generally fix the problem with some diagonal swapping.
I'm doing this to extrude polygons into prisms. On the sides I have quads. Are you saying I just need to do something to the diagonals of these (quad) polygons? There's no API for it right now right? It just comes from the ordering of the nodes in the polygon?
I fear the only completely robust solution for our polyhedra code may be to add a new element (C0IPPolyhedron? I'd hope to come up with a better name...) that adds a single Interior Point, after which getting a nice tetrahedralization becomes trivial.
Could we just use the centroid as the interior node? Seems like the tetrahedralization is trivial after doing that? (centroid to every triangle)
The thing is that I am doing this for finite volume sims, so I don't really need extra nodes. In fact I am not even sure I need a tetrahedralization (well except to compute the volume)
Is this PR ready for review now that it's no longer marked WIP?
Certainly ready for a look. if you use my MOOSE PR you can look at the current tetrahedralization of the hexagonal prism in exodus. You should see there is a non-matching edge inside, but is it a problem for the FE math? Certainly is a problem for me when converting the polyhedra to tets in some mesh generators
There was a problem hiding this comment.
the only completely robust solution for our polyhedra code may be to add a new element (C0IPPolyhedron
What about a C0PolygonalPrism element? We could always triangulate it as the union of triangular prisms, and we could possibly have custom FE that would be worth including in libmesh? "Tensor product" of the 1D line and the C0Polygon
EDIT: well except if we do the FE math with the tets, the 1D line won't really appear in one direction. We'd have to do something different. Maybe we would not use tets at all? Just triangular prism sub-elements
…ns on two sides that arise from extrusion - dont create a 0 vol elements if we have 3 surrounding nodes and everybody is coplanar - try to avoid this situation by improving as many potential 0-volume neighbor tets as possible when selecting which tet to construct
dont pick the second tet node that makes the future neighbors of size 0
- prioritize fixing more bad neighbors instead of always asking for quality improvements - don't consider the future neighbors when building the final tet
- would trigger some asserts as down to 2 neighnor nodes
GiudGiud
force-pushed
the
PR_poly_fixup
branch
from
3f652d6 to
313097a
Compare
|
Job Coverage, step Generate coverage on 313097a wanted to post the following: Coverage
Warnings
This comment will be updated on new commits. |
||||||||||||||||||||||||||
3 participants
based on top of the hexagon tiling PR, ignore that content for now! It's in another PR
see companion PR in MOOSE creating a bunch of polys with exodus viz of the tets:
idaholab/moose#32141