Repository navigation
Document interior points in initial tetrahedral meshes - #165
Conversation
|
Thx! |
|
Looks like there's a Mac test failure in the new test. Could you/Codex take a look? |
Head branch was pushed to by a user without write access
|
The failing assertion was mine: it assumed that every output tetrahedron satisfies the requested volume bound. Rotating the same cube reproduces violations on Linux too (for example, a maximum volume of 0.0232 with max_volume=0.02), so increasing a floating-point tolerance would not address it. In 9ac3419 I kept the interior-point connectivity check and now check positive tetrahedron volumes and total cube volume instead. The included documentation and PR description match those checks. The six tests, Ruff, and Sphinx with -W pass locally on Linux/Python 3.14. I cannot run macOS locally; its CI result still needs verification. |
Add a tested recipe for including interior points when generating a tetrahedral mesh, addressing the documentation request in #70. The example uses the existing
MeshInfo.set_points/set_facetsworkflow, checks that the requested point participates in a tetrahedron, and checks positive tetrahedron volumes and total unit-cube volume. The example also passesmax_volumeto request refinement; it does not assert a strict per-cell upper bound.The documentation includes the example directly from the test suite. It also corrects the
insert_pointsparameter description: the current wrapper does not forward that object to TetGen. This does not implement or depend on #69, and is limited to initial mesh generation.Validation on Linux/Python 3.14: all 6 tests pass (one existing empty-options warning), whole-repository Ruff passes, and Sphinx HTML builds with
-Wwithout warnings. The exact example runs independently; removing its interior input point makes the acceptance check fail. Other platform/Python combinations were not run locally.Developed with Codex assistance.