-
Notifications
You must be signed in to change notification settings - Fork 299
Changes to C0 polyhedron tetrahedralization loops #4359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: devel
Are you sure you want to change the base?
Conversation
src/geom/cell_polyhedron.C
Outdated
| const Point x_i = side.point(0); | ||
| const Point n_i = | ||
| (side.point(1) - side.point(0)).cross | ||
| -(side.point(1) - side.point(0)).cross |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@roystgnr can I please get a fact check on this line (rest is WIP)?
I'm assuming that if the nodes are ordered in the counter-clockwise direction, the normal should point up. Is that correct?
Then placing my index along P0P1 and the major following Pn-1P0 (what this formula says?) I would get down, so instead I do
P1P0 x Pn-1P0 or similarly Pn-1P0 x P0P1 and I get up (the desired result)
am I getting this wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok the (center - center_side) (pointing inside) is flipping the sign. So changing it is wrong here, I ll change it back
ba43ada to
5990f8c
Compare
…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
5990f8c to
45a4142
Compare
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
| 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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