Normal orientation in mmg2d


#1

hello,
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
Regards
Tom


#2

Hello Tom,

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,

Regards,

Algiane


#3

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
Regards
Tom


#4

the freefem script i mentioned in the earlier messagescript4mmg.edp (247 Bytes)
Best regards
Tom


#5

ths script if you need to see this on other borders
script4mmg.edp (293 Bytes)


#6

Hi Tom,

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,

Regards,

Algiane


#7

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.)
Thanks again,
Tom