Gmsh mesh in freefem

I’ve been trying to export a gmsh mesh to freefem including the physical groups (for labeling purpose). Does anyone have any pointers on how to do that?
I have 3 physical groups: inlet, outlet, wall (which includes all the walls in the geometry). I’m exporting the file as .mesh file, and I can import it into freefem using mesh Th(nameoffile). However, I can’t seem to find the labels.
I’ve read in another thread about using labels(Th), but that apparently only finds 2 labels.

An update: there’s a difference between using gmsh 2.7.1 and 4.7.1. It looks like it’s almost working in 4.7.1 (i.e. uploading the mesh into freefem and asking for its labels returns 3 labels).
On the other hand, what should be a hole in the mesh is now meshed, too. The outside mesh is red, while the inside mesh is orange, and I couldn’t figure out what it means.

If you want to reproduce this, here is the .geo file.

In gmsh 4.7.1: save as .msh, version 2 ASCII. If you save all elements you get a correct mesh, but incorrect labels. If you don’t save all elements you get an incorrect mesh but (presumably) correct labels.
In gmsh 2.7.1: save as .msh, version 2 ASCII. No matter whether you select to ignore physical groups or not, the mesh is correct but the labels are not.

I meshed with an element size factor of 50 in both cases.
Import it into freefem using:

load “gmsh”
mesh Th = gmshload(“tesla.msh”);
int[int] labs = labels(Th);
cout << “LABELS \n” << labs << endl;

As said earlier, the results of plot and labels vary based on which version of gmsh you use and which option you select. As a cheatsheet:
2.7.1 => correct mesh, incorrect labels
4.7.1, all elements => correct mesh, incorrect labels
4.7.1, unselect all elements => incorrect mesh, presumably correct labels.

Does anyone know how to get both a correct mesh and the correct labels?

I’d suggest you use the .mesh (Inria MEDIT) format. This is partially covered in this tutorial.

1 Like

I have a couple of problems with MEDIT files. First of all, the mesh is 3D, and I don’t really know how to handle it (in the definition of the problem). Secondly, if I don’t export all elements with a MEDIT file, I get an error. Specifically, “WARNING!!! The mesh file just contains a set of vertices”.
If I do export all elements, though, I get the incorrect labels once again.

Even if you follow the different steps from the tutorial?

I just tried adding the readmesh3 (which seemed to be the only difference from my code to his) and I still get the same problem.

load “msh3”
mesh3 Th(“tesla.mesh”);
Th = readmesh3(“tesla.mesh”);

I think I can reproduce your issue. This maybe be due to the “Reverse Surface” in your .geo. Not sure though, have you tried a simplified geometry?

I initially made the geometry using gmsh GUI and added the reverse surface manually to the .geo because I was getting an “assertion error: Area > 0” in freefem.
Even then, if I do remove the reverse surface and make the .msh in 4.7.1, I either get the assertion error (if I export all elements) or keep getting the same wrong geometry from earlier.
I remember trying out a holed square to check out if gmsh was having some problems with the not simply connected surface, but the meshing worked alright. I don’t think I had labels on, however.
I tried it out again just to be sure and, yeah, I get the same problem.

On the bright side, by trying it on a simple square, I noticed that the mesh as read by freefem is different from the one in gmsh even for simply connected surfaces, so it’s most likely a problem with gmshload.

It seems to be necessary to create an element set as well.

Physical Surface(“channel”) = {31};

Then when I export the mesh in gmsh-format version 2 ascii without the include all elements option and import it in Freefem++ then I get the three labels 2, 3, 4. Label 1 is assigned to channel in the msh-file.

By the way in gmsh the elements inherit their numbering scheme (clockwise or counterclockwise) from the underlying geometry. In Freefem++ node numbers have to be given in counterclockwise order (as with most FEM-programs I know) otherwise you get the “assertion error: Area > 0”.
This means for Freefem++ the elements have a negative area. Such elements are also called inside out in some commercial finite element programs.


The physical surface seems to solve the problem. Thanks to both of you!

I figured the assertion error was due to the number scheme, but it felt off to me that gmsh didn’t automatically reverse the surface to make it compliant with what most programs need.