I use mmg for working with FreeFEM++. I create the geometry in gmsh. While computing an integrated quantity in FreeFEM++ which involves element normals along a border, I found a mis-match. With the mesh from gmsh, I am getting (for. eg) 0.9 (which is expected), but on passing the mesh through mmg2d with -noinsert flag and computing I get (-0.9).
Hope you undertstand the concern. If I need to use some flags to resolve this, please let me know
Welcome to this forum.
Is it possible to attach the input mesh you give to mmg2d and its output mesh?
If I correctly understand your problem, after calling Mmg2d, the mesh edges are no longer oriented in accordance with the mesh triangles…
Thank you by advance,
Here you go. If you have FreeFEM you can easily debug this using a script in FreeFem++ i attach here.cylinder.msh (46.0 KB)
mcylinder.msh (59.8 KB)
cylinder.msh is from gmsh
mcylinder.msh from mmg: mmg2d_O3 in cylinder.msh -out mcylinder.msh -noinsert
label 5 one of the inner boundary label.
you can try 2,3,4,5,6. in the code and change (N.x<1e-10) to (N.x>1e-10) for more.
I think mmg is following a different convention than from FreeFEM++
Thanks for your reply
the freefem script i mentioned in the earlier messagescript4mmg.edp (247 Bytes)
Thank you for this script (as I am a beginner in FreeFem++ it has been very useful).
I have pushed a patch to have the same orientation for all the edges of a boundary of a given pysical domain (develop branch of mmg2d).
Beside, you can still have issues:
- Mmg2d don’t store the boundary entities of a mesh, it keeps only the mesh elements;
- At the end of the remeshing process, we reconstruct the boundaries of the mesh from the elements;
- Thus, if a triangle doesn’t have a neighbour through an edge, we create an edge oriented with respect to the triangle;
- If a triangle has a neighbour with a different reference (=color) we must choose with which triangle we will orient the edge:
- previously, we were oriented the edge with the triangle of maximal index (so two edges of a domain may have a different orientation);
- now, we orient the edge with respect to the domain with maximal reference;
In your test case it works because the gmsh physical references allows to obtain the same edge orientation than Mmg but as I don’t know the Gmsh (or the FreeFem++) convention, it is possible that sometimes you will ended with flipped edges. In this case, the only solution is to use a different numbering of the domain to impose the wanted edge orientation to Mmg.
I hope that it will help,
Thank you. And, my pleasure as I have to make you understand the problem I was facing. I hope mmgs and mmg3d is clear of this bug, so that I can confidently use it ? (At present everything works fine as far as normal orientation is concerned.)