-
Notifications
You must be signed in to change notification settings - Fork 27
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
Improves robustness of SignedDistance
query
#706
Conversation
using detail::isGeq; | ||
using detail::isLeq; | ||
|
||
const PointType& A = tri[0]; |
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.
👍 much better!
// would also require generating cell-to-face connectivity for the surface | ||
// mesh. | ||
break; | ||
default: // Use precomputed normal for edges and vertices |
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.
I remember when debugging the original SignedDistance PR that the BVH traversal sometimes only accumulated one face of an edge pseudo-normal; was that the underlying issue here?
In any case, I think it might be good to have a debug check/tracker variable here for the edge and vertex pseudo-normals:
- If we keep track of the number of normals we accumulated for the current weighted sum, an edge closest point should have exactly two accumulated normals, one for each face.
- Not sure about the angle-weighted normal for vertex closest points, but I think we could check that there at least 3? (since any angle at a triangle vertex should be less than 180 degrees)
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.
I remember when debugging the original SignedDistance PR that the BVH traversal sometimes only accumulated one face of an edge pseudo-normal; was that the underlying issue here?
There were a few problems. Most prominently:
primal::closest_point()
was using strict inequality tests, so points that were within `EPS of an edge or vertex could be marked as interior (face), and either not counted for the edge/vertex test, or would clear out the normal- The logic for determining whether to clear normals and/or sum normals needed some improvement.
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.
The underlying issue is that we're using purely geometric tests, so we cannot guarantee that the we're catching all (both) faces in the star of an edge or all faces in the star of a vertex.
A potentially better, but more expensive way to handle this would be to:
- Weld the mesh to ensure that we have a mesh instead of a collection of disjoint faces (see Port vertex welding code to GPUs via RAJA #705)
- Compute the pseudo-normal at each vertex of the welded mesh
- Only keep track of the single closest point
- Derive the sign from the normal of the mesh at this point.
This would robustly handle the face, edge and vertex cases for a watertight surface mesh.
The other downside of this approach would be that it would involve more memory (to store the normals) and more computation time (to weld the mesh and compute the normals)
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.
We can certainly add a debug check/variable to count the number of accumulated normals.
What would you suggest we do with that information though?
I suppose we can add an option to add scalar fields to the output vtk mesh to visualize this (closest point type and count)
8409610
to
90252bf
Compare
199b75f
to
6520ec9
Compare
6bde074
to
5ef1b3d
Compare
COMPILER: "[email protected]" | ||
HOST_CONFIG: "ruby-toss_3_x86_64_ib-${COMPILER}.cmake" | ||
BUILD_TYPE: "Release" | ||
EXTRA_CMAKE_OPTIONS: "-DAXOM_QUEST_ENABLE_EXTRA_REGRESSION_TESTS:BOOL=ON" |
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.
Should options like this and AXOM_ENABLE_MFEM_SIDRE_DATACOLLECTION
be documented in our ReadTheDocs configuration options?
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.
Thanks @bmhan12. In general, yes, we should document all our user-facing config options.
In the past, we have intentionally omitted a few niche options from our documentation, including the two that you mentioned:
AXOM_QUEST_ENABLE_EXTRA_REGRESSION_TESTS
is a developer option. We have a few quest regression tests that are always on and this option adds additional tests.AXOM_ENABLE_MFEM_SIDRE_DATACOLLECTION
was intended as a short-lived option -- it was added because we couldn't yet enable this feature by default, and we plan to remove this option (and enable the feature by default) as soon as we can. As far as I can tell, we should be able to do this once we have a working hip configuration.
There are a few other undocumented options in the code, like AXOM_MINT_USE_SIDRE
that we might also want to consider
axom/src/axom/mint/CMakeLists.txt
Lines 18 to 19 in 3999cf2
cmake_dependent_option( AXOM_MINT_USE_SIDRE "Enables Sidre support in Mint" ON | |
"AXOM_ENABLE_SIDRE" OFF) |
Any of these should be easy enough to add to the docs. We might want to discuss this further as a team. I'll create an issue for it.
Update: #711
I've resolved the issues in #703, added more quest regression tests and enabled these in some CI jobs, so this PR should be ready for review. For completeness, here are the two examples and their isosurfaces from #703
The plane appears to be underresolved to capture all the features, but the spurious signs (topological noise) have been resolved in both cases, and the signs agree with those of the InOutOctree. |
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.
@kennyweiss , thank you for the work.
60d399a
to
cb2457b
Compare
… edges and vertices of the mesh There are noticeable improvements in quest_regression_test against `tetrahedron` and `plane_simple` meshes, but it does not fix all cases. For example, ``` > ./tests/quest_regression_test -m ../data/quest_tetrahedron -r 99 99 99 --min -5 -5 -5 --max 5 5 5 ``` is fixed (went from 202 bad points to 0 bad points), while ``` > ./tests/quest_regression_test -m ../data/quest_tetrahedron -r 100 100 100 --min -5 -5 -5 --max 5 5 5 ``` is improved, but still has errors -- it went from 2125 bad points to 1024 bad points.
…parisons Using new `EPS` tolerance parameter.
* Use fuzzy comparisons in closest_point calculations to better determine when the closest point is on an edge or a vertex * Improves tests that determine if we should reset the cached sum of normals and to see if we should add a new normal to the current point
…didate struct Since we've improved the robustness of the edge and vertex cases and we're tracking which case we're in, we no longer need a separate vector to track the sum of edge normals and the sum of vertex normals.
Includes some additional minor fixes.
This counter tracks the number of entities at the current closest point. This is expected to be 2 for edges and higher for vertices. Added per PR suggestion.
Adds tests for the `tetrahedron` mesh as well as the `boxedSphere` mesh. Also adds a regression configuration for the `plane_simp` mesh, as described in #703
…default: Debug) Also use `Release` build for `linux_clang10` Azure CI job.
…ld_type` Options are: 'Debug' (default), 'RelWithDebInfo', 'Release' and 'RelMinSize'
…est regression tests
cb2457b
to
8821ea2
Compare
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.
Kenny, thank you for your diligent work.
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.
LGTM - great to see robustness improvements in Primal as well 👍
@@ -78,7 +78,7 @@ struct Arguments | |||
bool use_shared {false}; | |||
bool use_batched_query {false}; | |||
bool ignore_signs {false}; | |||
quest::SignedDistExec exec_space; | |||
quest::SignedDistExec exec_space {quest::SignedDistExec::CPU}; |
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.
Good catch - I was running into some issues with wonky execution space values on optimized builds as well.
Summary
primal::closest_point(pt, triangle)
by adding anEPS
tolerance parameter and using fuzzy comparisons to better determine if/when the closest point is on an edge or vertex of the triangleSignedDistance
to better track whether the closest point is on an edge or vertex.For these two cases, we need to track the weighted sum of all triangles incident in the edge or vertex
SignedDistance
tracks which case it is in (face, edge or vertex)plane_simp.stl
triangle mesh that was reported in Regression in signed distance query #703as well as a new
tetrahedron.stl
mesh that was added for this PRTODO
plane_simp
andtetrahedron
)data
submodule after merging Adds datasets and regression for debugging SignedDistance query axom_data#8