Handle zero contour aligning with faces in MeshClassifier. #16950
Conversation
Change logic in MeshClassifier to handle the situation described in issue dealii#16888. Add a new type to the enum LocationToLevelSet that describes that the zero contour is exactly aligned with a face. Change the logic in MeshClassifier to set the "inside" cell sharing an aligned face to intersected and the other cell to outside.
Test that we do not integrate over the zero contour twice, when the zero contour falls exactly on the face that is shared between two cells.
|
I was thinking something like this @mschreter. Do you think this makes sense? |
There was a problem hiding this comment.
@simonsticko looks very good. I've tried the patch for our application considered in #16888 and the active_fe_index now looks as we agreed. Thank you very much :-).
| @@ -56,7 +57,8 @@ namespace NonMatching | |||
| inside, | |||
| outside, | |||
| intersected, | |||
| unassigned | |||
| unassigned, | |||
| aligned | |||
There was a problem hiding this comment.
Shall we add a comment/assert that a cell should never be aligned?
There was a problem hiding this comment.
Hello Everyone,
I think that the completeness of such a comment depends on the particular application of the MeshClassifier. In TraceFEM, for example, even faces should never be aligned with the interface.
There was a problem hiding this comment.
I think there should be an assert. I will add it.
| @@ -68,9 +68,11 @@ namespace NonMatching | |||
| std::minmax_element(local_levelset_values.begin(), | |||
| local_levelset_values.end()); | |||
|
|
|||
| if (*min_max_element.second < 0) | |||
| if (*min_max_element.first == 0.0 && *min_max_element.second == 0.0) | |||
There was a problem hiding this comment.
Should we introduce a small tolerance for the check?
There was a problem hiding this comment.
In my opinion, it is typical for level set methods to actively perturb the interface position so it does not pass through cell vertices exactly. Having this in mind, I would recommend to reserve the "aligned" category for the pure case without a tolerance. I see it as a level set post-processing: if "aligned" perturb so it becomes "intersected".
There was a problem hiding this comment.
I agree that, usually, one should never compare floating point number exactly. But here, also I think that we actually want to. Moving the zero-contour would just change it to one of the other values of LocationToLevelSet.
Regarding tracefem: If we choose to implement it like this I do not think you need to perturb the level set. If a face is aligned, you integrate over the zero contour of the cell that is chosen as intersected and not over the other cell, so it will work also for this case.
Change logic in
MeshClassifierto handle the situation described issue #16888. Add a new type to the enumLocationToLevelSetthat describes that the zero contour is exactly aligned with a face. Change the logic inMeshClassifierto set the "inside" cell sharing an aligned face to intersected and the other cell to outside.