gmsh physical groups -> dolfin XML errors

[dajuno]

Hi,

there is an error in the conversion of gmsh meshes with tagged boundaries via physical lines/surfaces to dolfin XML. Consider the following unit square mesh, with boundary IDs 1 and 2:

h = 0.1;
Point(1) = {0, 0, 0, h};
Point(2) = {1, 0, 0, h};
Point(3) = {1, 1, 0, h};
Point(4) = {0, 1, 0, h};

Line(1) = {1, 2};
Line(2) = {2, 3};
Line(3) = {3, 4};
Line(4) = {4, 1};

Line Loop(5) = {1, 2, 3, 4};
Plane Surface(1) = {5};

Physical Line(1) = {3};   // lid
Physical Line(2) = {1, 2, 4};   // wall
Physical Surface(0) = {1};

Mesh 2;
Save "square.msh";

• After conversion with meshio-convert square.msh square.xml, the gmsh:geometrical and the gmsh:physical files will both contain a list of all vertices, dimension 2, with labels 0 in one file, and 1 in the other.
  Expected result (when converted with dolfin-convert) is a facet_region file that contains the labels (0, 1, 2) for all 27 facets of the mesh, and dim=1.
• Also, if <mesh_function type="uint"> was used rather than type="int", these files could be read by fenics' MeshFunction("size_t", ...) (instead of "int"). "uint" is more consistent, since "size_t" is used everywhere in the fenics documentation and dolfin-convert generates "uint".
• line breaks are missing in the gmsh:geometrical|phyiscal.xml files.

Best wishes,
David

[nschloe]

Okay, first thing I'm going to recommend to anyone using dolfin XML: Don't use it. Upstream as moved to XDMF, and you should probably do the same.

[dajuno]

I agree. It's more worthwhile making the XDMF conversion hassle-free. Apart from issue #260, how do you read physical groups in FEniCS from XDMF created by meshio? I know you're a FEniCS user yourself ;)
e: this is probably not the best place to discuss this.. I'll be following the discussion on the fenics slack, where the same question came up.

[nschloe]

Apart from issue #260, how do you read physical groups in FEniCS from XDMF created by meshio?

I've never done this.