Extracting Subdomains from XML File Converted from GMSH

Question

Hi,

I have generated a 3d mesh from GMSH and converted it to XML. I wish to implement simple Dirichlet boundary conditions on the borders of the mesh (and one internal surface). Dolfin, however, does not recognise any labels inherited from GMSH, as I get the following error:

*** Warning: Found no facets matching domain for boundary condition.

I have found a similar question on the forums ( http://fenicsproject.org/qa/2986/how-to-define-boundary-condition-for-mesh-generated-by-gmsh ) but I must admit I don't fully understand the solution.

Below, I have prepared a very simple .geo file that constructs a cube and labels the 6 surfaces and volume. Would anyone be able to show me the modifications I would need to make to this .geo file so that dolfin can see the subdomains?

Thanks

P.S. Is the problem simplified if I export gmsh files in the medit format and then convert to XML?

//Construct a cube in GMSH

//Build a line
Point(1) = {0, 0, 0, 1.0};
Point(2) = {0, 0, 10, 1.0};
Line(1) = {1, 2};

//Extrude line to create a surface (square)
Extrude {10, 0, 0} {
  Line{1};
}

//Extrude surface to create a volume (cube)
Extrude {0, 10, 0} {
  Surface{5};
}

//Six surfaces of the cube
Physical Surface(28) = {18};
Physical Surface(29) = {26};
Physical Surface(30) = {22}; 
Physical Surface(31) = {14};
Physical Surface(32) = {27};
Physical Surface(33) = {5};

//Volume of the cube
Physical Volume(34) = {1};

Answer 1

Hi,

try it like this:

//Six surfaces of the cube
Physical Surface(0) = {18};
Physical Surface(1) = {26};
Physical Surface(2) = {22}; 
Physical Surface(3) = {14};
Physical Surface(4) = {27};
Physical Surface(5) = {5};

//Volume of the cube
Physical Volume(0) = {1};

You could also find more detail explanation on the link you have posted above (in comments section):
http://fenicsproject.org/qa/2986/how-to-define-boundary-condition-for-mesh-generated-by-gmsh

Try it and say if it works or not:)

Regards, Maksim

Comments

Hi

This procures solved the problem I was having for my original, complicated mesh.

It also solved the problem with the cube example above but, additionally, I had not noticed that dolfin-convert had produced a _physical_region.xml and _facet_region.xml for the cube.msh even before I had made the changes above (Though this was not the case for my more complicated mesh).

Boundary conditions were recognised without problem after that.

Thanks,

---

Actually, a quick update.

I found that I had to start the labeling at 1 as opposed to 0. I.e.

//Six surfaces of the cube
Physical Surface(1) = {18};
Physical Surface(2) = {26};
Physical Surface(3) = {22}; 
Physical Surface(4) = {14};
Physical Surface(5) = {27};
Physical Surface(6) = {5};

//Volume of the cube
Physical Volume(1) = {1};

If I started at 0, no error was reported, but it would confuse the physical volume with the first surface boundary and misapply the Dirichlet boundary conditions. It might have something to do with 0 being reserved as a default for all boundaries and subdomains.

---

I found that I had to start the labeling at 1 as opposed to 0.

Yes, you are right.
I have checked it and got the same result.
Thank you!

We have to manually renumber Physical Surface and Physical Volume from 1, like you did here, otherwise we get wrong boundary conditions.

I use this "dolfin-convert" script file under Ubuntu OS to convert mesh from GMSH (.msh) to Fenics dolfin format (.xml):
https://github.com/FEniCS/dolfin/blob/master/scripts/dolfin-convert/dolfin-convert

Also I can't convert mesh is generated by GMSH under Windows OS to Fenics dolfin under Ubuntu OS, because it ("dolfin-convert" script) throws an error, so I have to generate mesh in GMSH under Ubuntu OS.