Lonely Boundary Face with Domains Preservation


we use the level set option to adapt to an implicit surface in 3D. In order to preserve defined volumes I add the level set information as via a mmg3d file and this works for simple cases. However, for more complex examples we get the following error more and more. The same problems work without providing the mm3d file but this looses the volume information obviously.

Is there anything we can do about it? What’s the likely cause (e.g. bad surface/volume mesh interaction at the boundary)?


  ## Error: MMG5_coquilFaceErrorMessage: at least 1 problem in surface remesh process (potential creation of a lonely boundary face):
            look at elt 696850: 91320 91283 91299 91321.
            adjacent tetras 697047 696932 697042 696942
            vertex required? 0 0 0 0

  ##        Try to modify the hausdorff number, the maximum mesh size or/and the value of angle detection.
 You can also try to run with -noswap option but probably the final mesh will have poor quality.

  ## Unable to improve mesh. Exiting.

  ## Unable to split mesh. Exiting.

I think I could pin this problem on a bad input mesh together with mmg options that prevent mmg from improving the mesh.

Hi Johannes,

This error is due to the detection of an inconsistency in the mesh: either Mmg detects that the mesh is already non conformal, either it detects an issue in our private data structures that can lead to a non-conformity if we apply the operator that we are simulating.

If your are sure that your input mesh is valid, it means that Mmg has created the issue (during either a collapse or a swap). I have a small pile of similar issues to find (hoping that a single bug is at the origin of all the errors) but the bug is very tricky and for now I didn’t find enough time to solve it :-(.
The creation of such a failure may be linked to the order of elements processing so if you are very lucky, a mesh renumbering may help (without any warranty).

I am sorry to not have a better answer for now.

If it is possible for you to share the mesh, metric and options that you are using, I can add it to the list of known test cases that are failing due to this error (for my private use only).

Best Regards,

Thanks a lot for you time! This is for sure a tricky edge case. My theory is as follows:

I provide surface triangles to the mmg to keep them but one of these is a sliver face which of course means that no proper tet mesh can be created. I think that mmg tries to resolve that sliver face due to my imposed constraint on the surface. I relaxed the conditions by only providing ridges (and required edges, see other question) and hence mmg will be able to resolve these problematic elements. The proper solution is of course to have a good input mesh in the first place. It might even be that this sliver face is at a non FEM corner tet (which in turn would totally fix that tet during optimisation).

Unfortunately, I cannot share this particular mesh due to an NDA. If I come across a mesh that we can share that exhibits this, I will gladly share it. Most of our own meshes have better quality though.

I was able to get around this problem as posted above while also ending up with a better mesh.


Your explanation makes sense, thanks for this feedback.