Required elements vs required faces in 3d

Developers Help
#1

Hi

Is there something to be aware of regarding required triangles in 3d ? Required triangles are not preserved in my case.
Here is the context: I have a part of the domain (tets) that I require to enforce a relationship between meshes.
I also set the surface triangles of the domain to be required, I labeled them to be able to compute displacement and metric based on the distance to the object. In the latter, the surface corresponds to the 0 of the distance levelset.
The strategy goes south with these triangles not being preserved. Any insights about why they would not be preserved?
The tets are properly preserved so I can certainly change the strategy and use them instead .
Best regards

#2

Hi Christophe,

I am not sure to understand the issue (maybe a picture of the mesh can help): are you trying to preserve non-surfacic triangles (triangles that are not at the interface of tetra with different references)?

If yes, Mmg will ignore these triangles in default mode but you can enforce their preservation using the opnbdy mode (MMG3D_IPARAM_opnbdy). If your triangles are “true” boundary triangles and are required, Mmg should be able to preserve it.

Regards,
Algiane

#3

I am trying to preserve triangles at the interface between two materials, they are not on the boundary of the domain.

The documentation says:
Preserve triangles at interface of 2 domains with same reference

The triangles have indeed the same reference but I guess you are talking about the domains, no ?
in that case the labels of the domains are different.

#4

I understood reference as label but maybe it is identifier? In that case the faces keep their id throughout the remeshing?

#5

Hello,

It is always hard to find a common vocabulary: for Mmg, a reference is the integer associated to the entity that allows to identify to which material (for a volume element) it belongs or which boundary condition (for a boundary entity) must be applied. If you are used to Gmsh, the Mmg reference matches with the Gmsh physical tag.

If by identifier you mean the face index: no, Mmg doesn’t preserve the numbering.

To get back to your initial issue: if you provide required triangles between two different materials, Mmg should preserve it…

#6

This is not the case, the required triangles are not preserved. May be there is something wrong in my code. I will check one more time.

Could there be an issue if the required face is a face of a required tet? I would not see why but I ask anyway.
I implemented a workaround that reconstruct the set of faces and the number remains constant as expected (required tets work well in my case)
Thank you for your help

#7

Hi,

Normally required faces and tetra are compatible…
I will try to take a look at your code. I keep you aware.

Best

#8

Dear @Algiane
I have found the issue.
it is a combination of requiring elements and tracking the ids of the required elements through the labels that caused the issue.
To fix this, I set the option opnbdy to 1

#9

Dear @prudhomm ,

Thanks for this feedback and sorry I wasn’t more helpful.

I am still not sure to understand entirely the issue:

  • you provide required triangles (and tetrahedra);
  • you store ids of elements in the ref field of Mmg so after remeshing and despite Mmg renumbering you can recover the initial index of a required element;
  • the combination of these two things leads Mmg to lost some required triangles?

If yes, the only reason I can see why Mmg would lose triangles would be that a required triangle would end up between 2 tetra with the same ref (so the same id would be stored in two tetra): is it what happens?

Just for information :

  • opnbdy mode is slower than “classic” mode so if you can use a trick to avoid its use, it can be interesting;
  • also, this mode has not been implemented within ParMmg (and is implementation is not planned)

Best Regards,
Algiane

#10

it is what happens, indeed.

I have seen that the option opnbdy slows down mmg quite a lot.
We keep the id in order to keep a relation between the meshes to avoid having to resort to localization before interpolation. We have now alternatives that avoid keeping the relations. See eg the video I pushed on the forum.