Is "exuding sliver tetrahedra" part of mmg3d features - here's a mesh where mmg gets stuck

[Mathias-Fuchs]

Hello,
here: https://mathiasfuchs.com/sliverOut.mesh is a not too large mesh which seems to make mmg3d get stuck - the problem probably are some sliver tetrahedra but that it just my speculation! I might be wrong about the cause of the problem. Just the command

mmg3d.exe sliverOut.mesh

doesn’t finish - at least not after waiting for a few minutes, with the release build of mmg3d.exe from the latest develoment branch. The term “exuding sliver tetrahedra” seems to be the term papers use for this problem. Mmg seems to be trying to insert too many vertices. Why does mmg want to split so much? Which constraint is it fighting with? And what is the least permissive way to tell mmg to “be more chill” about that constrant, so that it come up with something. I need a finite element mesh, but at least the quality of the worst tet should improve.
I have tried out many possible combinations of settings that seem to relax some constraints, and rund with the “-d” flag, for instance:

mmg3d_O3 -d -hgrad 1000 -nr -nofem sliverOut.me

and other combinations of flags. Every time, mmg3d gets stuck splitting infinitely.

Cheers, Mathias
The input looks relatively harmless:

[tcdoe]

Hi,
Those slivers that I see (viewing in gmsh), are probably not just slivers, but also intersecting faces. This will cause mmg3D to fail for sure. You have to clean up that surface mesh and get rid of those. You can do that manually very easily in Blender. Or by whatever other software, or in your process.
Then I’m sure mmg3d will work as expected on this simple shape.
edit: if that is a 3D mesh (not surface), it’s possible that the original surface is funky, so fixing it also will involve fixing in whatever you used to generate the original mesh, prior to mmg3d.
Hope that helps,
Todd (abemis.com).

[Mathias-Fuchs]

Thanks for the answer.
EDIT: I checked and there are no intersecting faces!
My question was the following:

Is exuding sliver tetrahedra part of mmg3d features?

This is a question about what mmg3d actually advertises itself as. Is the user expected to identify thin tetrahedra beforehand, or not?
By the way, of course I’m not interested in this particular mesh, I’m interested in the general way mmg works. This “flan” mesh is just the smallest example I could find where mmg does not finish. In any case, it might be a good feature of mmg if mmg could identify mesh failures beforehand, instead of hanging because I will not be the only user coming up with problematic input.

[lcirrott]

Hello Mathias,

Is exuding sliver tetrahedra part of mmg3d features?

I cannot answer to this exact question, but looking at the large geometrical size of the input mesh, I can manage to get some results with

mmg3d_O3 sliverOut.mesh -hausd 1000

(with or without -nofem)

So:

• one problem seems to be related to the high coordinate values in the input mesh – although I always forget its implementation, the Hausdorff parameter should have a dimensional value (see -hausd – Mmg Platform), and the default one is way too small…
• I also see some intersecting internal faces at the bottom of your model, although Mmg does not seem to be bothered by it.

I don’t know if this kind of adaptation pattern is good enough for your application, so the “is exuding sliver tetrahedra a feature?” question may still be pending

Hope this helps!
Luca

[tcdoe]

Edit2: I also forgot to mention that the size of sliverOut.mesh is somehow wrong (500000+)? So that’s another issue to address when you remake sliverOut, etc.
Edit: I think I might have misstated a bit about the intersecting. I took another look, and what is likely happening is that sliverOut.mesh is not a proper FE mesh for some reason. I don’t know what you used to generate this initial mesh (did you mention? I might have missed it), but this often happens for me when I try to generate a mesh (I’m using CGAL) from a surface that has intersecting faces. But it could happen for other reasons too.
In my limited experience mmg3d cannot handle a topologically weird mesh such as sliverOut.mesh. In these screenshots I’ve highlighted the problems (in Gmsh, and loaded into Blender). For instance you can see that there is no node next to node 12, so that’s not a sliver, it’s called something else but I can’t remember off-hand. The whole mesh is pretty wonky.
You will have to redo sliverOut.mesh to get a better fully topo input mesh for mmg3d, or it’s not going to work and you’ll get that ‘infinite’ result that you mentioned.
Hope that helps!

— this info might still be useful for you to know —
HI, I have to say whatever you used to check is giving you a false response, if you are checking the tapered cylinder that you posted. I can show them to you, there are many. They might be connected in some way, that somehow subtly ‘passes’ your auto-check even though still not manifold. I’ve had that happen many times.

[Mathias-Fuchs]

There are definitely no intersecting tetrahedra in the input mesh, I checked that multiple times.
Of course it is not a finite element mesh - mmg promises to remesh meshes such that they become finite element meshes, and this mesh is an input to mmg, not output. This input mesh is chosen by me deliberately to show that mmg sometimes runs hot instead of finishing, and to ask if mmg promises to deal with sliver tetrahedra or not. There is little point in dismissing the mesh as “wonky” - because it is deliberately chosen to be a bad quality mesh.
The point is that mmg should communicate with a helpful and constructive error message about what is wrong with its input, instead of just not finishing and running into an endless loop, and mmg should be clear about what it can do and what not. With this post I am trying to help users and developers of mmg by pointing out problems with mmg, not trying to mesh a flan.

[tcdoe]

Ok, so you are submitting an initial mesh that is so imperfect, that it causes mmg3d to fail. I don’t see why there is any reason to move ahead with this attempt to ‘break’ mmg3d. If you can’t make a mesh that corresponds to the mathematics that mmg3d is using, then it is an issue with your understanding of the mathematics of the process and topologies.

By your argument; you could just make any incrementally further poor initial mesh, that is increasingly difficult to re-mesh. For mmg3d to work properly and efficiently, super-elongated slivers in the initial poorly generated mesh are your problem to solve. It’s fair to evaluate a software with an input that is ‘designed’ to break the process. I understand that, but I don’t see why mmg3d has any responsibility to resolve your specific problems with your broken initial mesh. That is your responsibility.

If you want to help improve mmg3d, then perhaps you should develop yourself a method to reduce or eliminate the obvious problems with your initial mesh. Can you do that?

I have done that, by pre-processing of our hyper-structures. We spent a lot of time/effort to ensure a manifold, sliver-removed initial mesh for our structures. If we can do it, surely you can too?

Look forward to your reply where you have fixed your problems. Again, I do not see this as a problem with mmg3D. It is your initial mesh that is the problem, and possibly a misunderstanding about how topologies work.

[lcirrott]

Hello,
My two cents: as I have recalled in my previous reply, the documentation says

By default, the Hausdorff value is set to 0.01, which is a suitable value for an object of size 1 in each direction. for smaller (resp. larger) objects, you may need to decrease (resp. increase) the Hausdorff parameter.

So my understanding and experience is that here Mmg goes into what appears to be an “endless” splitting loop because this input mesh has very large sizes (in coordinates), and the default Hausdorff value is too small. By setting it appropriately, Mmg terminates well on that case on my computer.

Have you checked the size of the mesh coordinates and the Hausdorff value for the other cases that get stuck?
If they continue to get stuck even with reasonable Hausdorff parameters, then we can move on blaming the topology handling in Mmg

Bests,
Luca

[Mathias-Fuchs]

I point out a problem with mmg and it is pretty outrageous that you attack me by saying I can’t “make a mesh that corresponds to the mathematics of the process”, and then you tell me I have an issue with “my understanding of the mathematics.”
Just for your information: I have a PhD in Mathematics and a solid academic track record (Academic publications Mathias Fuchs). I can certainly help but I’m not going to help people with such a bad attitude. By the way, I have already contributed quite a number of interesting discussions on this forum and I am contributor to mmg itself (commit 92c2b977664b5fa360b6db2e5aee902bc238c6ce which is in the master branch), just look it up. I’m going to report your post.

[Mathias-Fuchs]

Yes, that kind of answers the question, but that means that the default setting in mmg is wrong and needs to be replaced with a more appropriate setting. However, you also throw a false accusation - that there are intersecting faces - which is not the case.

[Algiane]

Hello everyone,

First of all, thank you all for your interest in this forum and in Mmg. This forum lives on thanks to you and your involvement and all the exchanges you have here can be useful to others.

If it’s all right with you, I suggest we take a short break on this subject while I read the exchanges: I’ll try to respond as best I can before the end of the week.

Best,
Algiane