Skip to content

Stabilise contactmerge

Jonathan Youett requested to merge stabilise_contactmerge into master

I still run into problems using the new implementation within ContactMerge. I added a new test example to projectiontest.cc where a wrong edge intersection is found, which leads StandardMerge to stop running properly. The problem in this test case (where both triangles are almost orthogonal to each other) is the following: One vertex is forward projected in the negative projection direction, and hence dismissed. Still, the inverse projection and edge intersection is performed using the forward projected triangle (where one of the vertices is projected in the wrong direction). While in this test case all inverse projected vertices are correctly dismissed, one edge intersection is falsely accepted.

I also ran into similar problems, where all inverse projected vertices were false accepted, which all originate from one or more wrong forward projected vertices.

The fix that I use in my code is to declare a projection invalid whenever the forward projection is too far in the wrong direction.

This fix on the one hand provides a much better performance of the advancing front algorithm but on the other hand also prevents one intersection case that might be desired: When the forward projection is negative because of an overlap of the grids, there can still be valid inverse projections/edge intersections. To allow this case in a certain amount, the projection is only declared invalid if the negative projection is larger than 2*allowedOverlap (or some other number). An example for this is given in the projectiontest.cc->test_project_overlap

Merge request reports