MMG3D: preservation of internal faces and edges

Hello,

Thanks a lot for the latest mmg version. The new metric gradation is improving a lot the quality of my elements close to a required entity and it accelerates the algorithm convergence for a very fine metric.

At this moment, I encounter some problems with the 3d features, when I wish to freeze some internal faces or edges.
Please find in the attachment two of my scenarios.
• The first one only requires two triangles and two edges, and no other entity. In this case the tags are completely lost.
• The second one requires two triangles and two edges, which exists at the intersection of 2 or 4 tagged subdomains. In this case the output contains the required triangles and their associated tags, but it looses the edges.

Do you have some hints that could fix this issue?

Note that I am usually using the C interface for remeshing, but, in these examples the same results are obtained by the equivalent command :
mmg3d_O3 input1.mesh -sol input1.sol -hgrad 1.25 -hausd 0.05 -hmin 0.1 -hmax 1.0 -v 5

Thank you,
Bers regards,
Oana

input1.sol (817 Bytes)
input2.mesh (7.8 KB)
output1.mesh (30.7 KB)
output2.mesh (46.5 KB)
input1.mesh (6.2 KB)

Hi Oana,

Thank you for your feedback about the release!

Regarding your problem, for your first configuration:

  • by default, Mmg only supports boundary tags if they are supported by a “true” boundary. For Mmg, a “true” boundary is a triangle (resp. edge in 2D) which is on the external boundary of the mesh or at the interface of 2 tetrahedra (resp. triangles in 2D) with different references;
  • you can force Mmg to preserve other boundary tags using the -opnbdy option (MMG3D_IPARAM_opnbdy integer parameter of the API);
  • Note that this last option may slow down the remesher.

I am still looking of what happens on your second configuration…

Best regards,

Algiane

Hi Algiane,

Thank you for your prompt response.
The use of opnbdy solved the problem of my first previous scenario.
Yet, I noticed that it is not enough when only edges are required, as in the attached example.

Best regards,
Oana

input1edges.mesh (6.2 KB)

output1edges.mesh (30.7 KB)

Hi Oana,

I have pushed a correction in the release branch of the Mmg repository that allows to preserve the edge reference in your second configuration.

I confirm that in your first scenario, providing only edges don’t work : for Mmg, a boundary edge must belong to a boundary triangle. The physical reason is that in our mind, boundaries represent physical objects or domains.

Behind this, from a computational point of vue :

  • it is very expensive to check for every mesh edges if the edge is boundary or not. Checking only the edges of the boundary triangles allows to speed up the remesher;

  • allowing to have “inside” edges without a surface support may lead to some situations that the remesh doesn’t handle. For example, you may have an inside line composed by a suit of inside edges. If this edges aren’t required, we must allow collapses / split / move operators that preserve the tangent direction of the line but can modify all the “faces” around the edges (the faces of the tetra to which the edges belong). For now, as the edges are supported by triangles (which represent an underlying ideal surface), when we remesh a line, we preserve the “ideal surface” representation : in a certain sense the problem has fewer DoFs.

What represents the inside edges in your problem?

Regards,

Algiane

Hi Algiane,

I have tested the new commit. It works like a charm. Thank you.
Like in the example i sent you, the edges define intersections of multiple subdomains. Sometimes the intersections are defined by one point, an edge or a face and I need to freeze them, as they serve to communicate boundary values in the iterative domain decomposition solver I use. I don’t know how to demonstrate it, but I do believe that they always exists along faces (my second configuration). Thus, I should always respect this second configuration.

Have a nice day,
Bers regards,
Oana