Dear all, I create a very simple gmsh file: just a square with "left", "bottom", "right" and "top" boundary. I have attached two versions of the mesh. 1) neu3.msh: This has the "PhysicalNames" declared at the beginning. I get a "File is not a valid Gmsh file" error. 2) neu4.msh: This has the "PhysicalNames" declared at the end. But if I now try to set Dirichlet bc for the "left" and "right" boundary, e.g. with bc0 = DirichletBC(W.sub(0), Expression("0.0"), "right") nothing seems to happen. I guess I'm missing sth. obvious here... Thank you! Henrik Error message for neu3.msh Traceback (most recent call last): File "charge.py", line 7, in <module> mymesh = Mesh("neu3.msh") File "<decorator-gen-274>", line 2, in __init__ File "/home/hb111949/.local/lib/python2.7/site-packages/PyOP2-0.11.0_425_g64db689-py2.7-linux-x86_64.egg/pyop2/profiling.py", line 203, in wrapper return f(*args, **kwargs) File "/home/hb111949/Code/firedrake/firedrake/mesh.py", line 351, in __init__ plex = _from_gmsh(meshfile) File "/home/hb111949/Code/firedrake/firedrake/mesh.py", line 152, in _from_gmsh gmsh_plex = PETSc.DMPlex().createGmsh(gmsh_viewer) File "PETSc/DMPlex.pyx", line 115, in petsc4py.PETSc.DMPlex.createGmsh (src/petsc4py.PETSc.c:214898) petsc4py.PETSc.Error: error code 62 [0] DMPlexCreateGmsh() line 140 in /rwthfs/rz/cluster/home/hb111949/Code/petsc/src/dm/impls/plex/plexgmsh.c [0] Invalid argument [0] File is not a valid Gmsh file -- Dipl.-Math. Henrik Büsing Institute for Applied Geophysics and Geothermal Energy E.ON Energy Research Center RWTH Aachen University ------------------------------------------------------ Mathieustr. 10 | Tel +49 (0)241 80 49907 52074 Aachen, Germany | Fax +49 (0)241 80 49889 ------------------------------------------------------ http://www.eonerc.rwth-aachen.de/GGE hbuesing@eonerc.rwth-aachen.de ------------------------------------------------------
Henrik, PETSc's DMPlexCreateGmsh() function does not recognize the "PhysicalNames" field, which is why the reader screws up in neu3.msh neu4.msh also fails because the boundaries in DMPlex are labeled by physical ID's, which is , not "PhysicalNames" strings. Also, if you're using the Mesh() function, you need to provide the entire mesh and not just the four 2-node lines? In any case, the GMSH file format (including where the physical ID's are located) can be found here: 9.1 MSH ASCII file format <http://geuz.org/gmsh/doc/texinfo/gmsh.html#MSH-ASCII-file-format> Thanks, Justin On Fri, Dec 18, 2015 at 1:18 AM, Buesing, Henrik < HBuesing@eonerc.rwth-aachen.de> wrote:
Dear all,
I create a very simple gmsh file: just a square with “left”, “bottom”, “right” and “top” boundary. I have attached two versions of the mesh.
1) neu3.msh: This has the “PhysicalNames” declared at the beginning. I get a “File is not a valid Gmsh file” error.
2) neu4.msh: This has the “PhysicalNames” declared at the end. But if I now try to set Dirichlet bc for the “left” and “right” boundary, e.g. with
bc0 = DirichletBC(W.sub(0), Expression("0.0"), “right”)
nothing seems to happen. I guess I’m missing sth. obvious here…
Thank you!
Henrik
Error message for neu3.msh
Traceback (most recent call last):
File "charge.py", line 7, in <module>
mymesh = Mesh("neu3.msh")
File "<decorator-gen-274>", line 2, in __init__
File "/home/hb111949/.local/lib/python2.7/site-packages/PyOP2-0.11.0_425_g64db689-py2.7-linux-x86_64.egg/pyop2/profiling.py", line 203, in wrapper
return f(*args, **kwargs)
File "/home/hb111949/Code/firedrake/firedrake/mesh.py", line 351, in __init__
plex = _from_gmsh(meshfile)
File "/home/hb111949/Code/firedrake/firedrake/mesh.py", line 152, in _from_gmsh
gmsh_plex = PETSc.DMPlex().createGmsh(gmsh_viewer)
File "PETSc/DMPlex.pyx", line 115, in petsc4py.PETSc.DMPlex.createGmsh (src/petsc4py.PETSc.c:214898)
petsc4py.PETSc.Error: error code 62
[0] DMPlexCreateGmsh() line 140 in /rwthfs/rz/cluster/home/hb111949/Code/petsc/src/dm/impls/plex/plexgmsh.c
[0] Invalid argument
[0] File is not a valid Gmsh file
--
Dipl.-Math. Henrik Büsing
Institute for Applied Geophysics and Geothermal Energy
E.ON Energy Research Center
RWTH Aachen University
------------------------------------------------------
Mathieustr. 10 | Tel +49 (0)241 80 49907
52074 Aachen, Germany | Fax +49 (0)241 80 49889
------------------------------------------------------
http://www.eonerc.rwth-aachen.de/GGE
hbuesing@eonerc.rwth-aachen.de
------------------------------------------------------
_______________________________________________ firedrake mailing list firedrake@imperial.ac.uk https://mailman.ic.ac.uk/mailman/listinfo/firedrake
Dear Henrik,
On 18 Dec 2015, at 10:00, Justin Chang <jychang48@gmail.com> wrote:
Henrik,
PETSc's DMPlexCreateGmsh() function does not recognize the "PhysicalNames" field, which is why the reader screws up in neu3.msh
neu4.msh also fails because the boundaries in DMPlex are labeled by physical ID's, which is , not "PhysicalNames" strings.
Also, if you're using the Mesh() function, you need to provide the entire mesh and not just the four 2-node lines? In any case, the GMSH file format (including where the physical ID's are located) can be found here:
9.1 MSH ASCII file format
Justin is right, we just defer to PETSc's mesh reader for Gmsh which doesn't understand the physicalnames. If you want to mark boundaries of the domain, you will need to use the "Physical Line" (in 2D) or "Physical Surface" (in 3D) functionality to give those boundaries integer IDs. In firedrake/tests/regression there is an example mesh of an annulus (annulus.geo and annulus.msh) that does this. The boundary is a Physical Line(9). Which means that we can impose Dirichlet conditions using: DirichletBC(V, ..., 9) Cheers, Lawrence
Dear Justin! Dear Lawrence! So just to be clear... Firedrake reads in the *.msh as well as the *.geo file. So both have to be present? Only the *.msh file is not sufficient? Henrik -- Dipl.-Math. Henrik Büsing Institute for Applied Geophysics and Geothermal Energy E.ON Energy Research Center RWTH Aachen University ------------------------------------------------------ Mathieustr. 10 | Tel +49 (0)241 80 49907 52074 Aachen, Germany | Fax +49 (0)241 80 49889 ------------------------------------------------------ http://www.eonerc.rwth-aachen.de/GGE hbuesing@eonerc.rwth-aachen.de ------------------------------------------------------
-----Ursprüngliche Nachricht----- Von: firedrake-bounces@imperial.ac.uk [mailto:firedrake- bounces@imperial.ac.uk] Im Auftrag von Lawrence Mitchell Gesendet: 18 December 2015 11:18 An: firedrake@imperial.ac.uk Betreff: Re: [firedrake] gmsh: Accessing PhysicalNames for boundary conditions
Dear Henrik,
On 18 Dec 2015, at 10:00, Justin Chang <jychang48@gmail.com> wrote:
Henrik,
PETSc's DMPlexCreateGmsh() function does not recognize the "PhysicalNames" field, which is why the reader screws up in neu3.msh
neu4.msh also fails because the boundaries in DMPlex are labeled by physical ID's, which is , not "PhysicalNames" strings.
Also, if you're using the Mesh() function, you need to provide the entire mesh and not just the four 2-node lines? In any case, the GMSH file format (including where the physical ID's are located) can be found here:
9.1 MSH ASCII file format
Justin is right, we just defer to PETSc's mesh reader for Gmsh which doesn't understand the physicalnames. If you want to mark boundaries of the domain, you will need to use the "Physical Line" (in 2D) or "Physical Surface" (in 3D) functionality to give those boundaries integer IDs.
In firedrake/tests/regression there is an example mesh of an annulus (annulus.geo and annulus.msh) that does this. The boundary is a Physical Line(9). Which means that we can impose Dirichlet conditions using:
DirichletBC(V, ..., 9)
Cheers,
Lawrence
On 18 Dec 2015, at 10:52, Buesing, Henrik <HBuesing@eonerc.rwth-aachen.de> wrote:
Dear Justin! Dear Lawrence!
So just to be clear... Firedrake reads in the *.msh as well as the *.geo file. So both have to be present? Only the *.msh file is not sufficient?
Oh no, firedrake doesn't touch the geo file. You should only need the msh file. Lawrence
On 18 Dec 2015, at 10:52, Buesing, Henrik <HBuesing@eonerc.rwth- aachen.de> wrote:
Dear Justin! Dear Lawrence!
So just to be clear... Firedrake reads in the *.msh as well as the *.geo file. So both have to be present? Only the *.msh file is not sufficient?
Oh no, firedrake doesn't touch the geo file. You should only need the msh file.
But going with your example tests/regression/annulus.msh. In the msh file there is no definition of the Physical Line. This is only present in the *.geo file... So how does firedrake know about "9" as index to the boundary? Henrik
On 18 Dec 2015, at 11:00, Buesing, Henrik <HBuesing@eonerc.rwth-aachen.de> wrote:
On 18 Dec 2015, at 10:52, Buesing, Henrik <HBuesing@eonerc.rwth- aachen.de> wrote:
Dear Justin! Dear Lawrence!
So just to be clear... Firedrake reads in the *.msh as well as the *.geo file. So both have to be present? Only the *.msh file is not sufficient?
Oh no, firedrake doesn't touch the geo file. You should only need the msh file.
But going with your example tests/regression/annulus.msh. In the msh file there is no definition of the Physical Line. This is only present in the *.geo file... So how does firedrake know about "9" as index to the boundary?
Aha! The impenetrable gmsh format strikes again: This section of the mesh file: $Elements 56 1 1 2 9 1 1 9 2 1 2 9 1 9 2 3 1 2 9 2 2 10 4 1 2 9 2 10 3 5 1 2 9 3 3 11 6 1 2 9 3 11 4 7 1 2 9 4 4 12 8 1 2 9 4 12 1 9 1 2 9 5 5 13 10 1 2 9 5 13 6 11 1 2 9 6 6 14 12 1 2 9 6 14 7 13 1 2 9 7 7 15 14 1 2 9 7 15 8 15 1 2 9 8 8 16 16 1 2 9 8 16 5 Is the 16 boundary facets, notice the 4th column is "9", indicating the physical ID. This is where the ID comes from. As Justin pointed out, the full description of this format is at http://geuz.org/gmsh/doc/texinfo/gmsh.html#MSH-ASCII-file-format Lawrence
On 18/12/15 11:00, Buesing, Henrik wrote:
On 18 Dec 2015, at 10:52, Buesing, Henrik <HBuesing@eonerc.rwth- aachen.de> wrote:
Dear Justin! Dear Lawrence!
So just to be clear... Firedrake reads in the *.msh as well as the *.geo file. So both have to be present? Only the *.msh file is not sufficient?
Oh no, firedrake doesn't touch the geo file. You should only need the msh file.
But going with your example tests/regression/annulus.msh. In the msh file there is no definition of the Physical Line. This is only present in the *.geo file... So how does firedrake know about "9" as index to the boundary?
The physical ids *are* present in the .msh file. The 'elements' list at the end contains both triangles and line segments. In fact the first 16 are the line segments with the physical id 9, in the 3rd column, and its 2 node numbers in the last 2 columns. The rest are the triangles with a physical id of 10 in the 3rd column, and its 3 nodes in the last 3 columns. See the link that Lawrence gave to see what the other columns indicate Cheers Stephan
-----Ursprüngliche Nachricht----- Von: firedrake-bounces@imperial.ac.uk [mailto:firedrake- bounces@imperial.ac.uk] Im Auftrag von Stephan Kramer Gesendet: 18 December 2015 12:19 An: firedrake@imperial.ac.uk Betreff: Re: [firedrake] gmsh: Accessing PhysicalNames for boundary conditions
On 18/12/15 11:00, Buesing, Henrik wrote:
On 18 Dec 2015, at 10:52, Buesing, Henrik <HBuesing@eonerc.rwth- aachen.de> wrote:
Dear Justin! Dear Lawrence!
So just to be clear... Firedrake reads in the *.msh as well as the *.geo file. So both have to be present? Only the *.msh file is not sufficient?
Oh no, firedrake doesn't touch the geo file. You should only need the msh file.
But going with your example tests/regression/annulus.msh. In the msh file there is no definition of the Physical Line. This is only present in the *.geo file... So how does firedrake know about "9" as index to the boundary?
The physical ids *are* present in the .msh file.
Thanks for clarifying that. Henrik
-----Ursprüngliche Nachricht----- Von: firedrake-bounces@imperial.ac.uk [mailto:firedrake- bounces@imperial.ac.uk] Im Auftrag von Stephan Kramer Gesendet: 18 December 2015 12:19 An: firedrake@imperial.ac.uk Betreff: Re: [firedrake] gmsh: Accessing PhysicalNames for boundary conditions
On 18/12/15 11:00, Buesing, Henrik wrote:
On 18 Dec 2015, at 10:52, Buesing, Henrik <HBuesing@eonerc.rwth- aachen.de> wrote:
Dear Justin! Dear Lawrence!
So just to be clear... Firedrake reads in the *.msh as well as the *.geo file. So both have to be present? Only the *.msh file is not sufficient?
Oh no, firedrake doesn't touch the geo file. You should only need the msh file.
But going with your example tests/regression/annulus.msh. In the msh file there is no definition of the Physical Line. This is only present in the *.geo file... So how does firedrake know about "9" as index to the boundary?
The physical ids *are* present in the .msh file. The 'elements' list at the end contains both triangles and line segments. In fact the first 16 are the line segments with the physical id 9, in the 3rd column, and its 2 node numbers in the last 2 columns. The rest are the triangles with a physical id of 10 in the 3rd column, and its 3 nodes in the last 3 columns. See the link that Lawrence gave to see what the other columns indicate [Buesing, Henrik] I guess my problem comes when creating the *.msh file with the gmsh gui. In my test.geo file I have the "Physical Line", but in my test.msh file every element has id "0". Probably I'm doing sth. wrong when creating the files with the gui. Thank you Stephan for clearing this up.
-----Ursprüngliche Nachricht----- Von: Buesing, Henrik Gesendet: 18 December 2015 13:03 An: 'firedrake@imperial.ac.uk' Betreff: AW: [firedrake] gmsh: Accessing PhysicalNames for boundary conditions
-----Ursprüngliche Nachricht----- Von: firedrake-bounces@imperial.ac.uk [mailto:firedrake- bounces@imperial.ac.uk] Im Auftrag von Stephan Kramer Gesendet: 18 December 2015 12:19 An: firedrake@imperial.ac.uk Betreff: Re: [firedrake] gmsh: Accessing PhysicalNames for boundary conditions
On 18/12/15 11:00, Buesing, Henrik wrote:
On 18 Dec 2015, at 10:52, Buesing, Henrik <HBuesing@eonerc.rwth- aachen.de> wrote:
Dear Justin! Dear Lawrence!
So just to be clear... Firedrake reads in the *.msh as well as the *.geo file. So both have to be present? Only the *.msh file is not sufficient?
Oh no, firedrake doesn't touch the geo file. You should only need the msh file.
But going with your example tests/regression/annulus.msh. In the msh file there is no definition of the Physical Line. This is only present in the *.geo file... So how does firedrake know about "9" as index to the boundary?
The physical ids *are* present in the .msh file. The 'elements' list at the end contains both triangles and line segments. In fact the first 16 are the line segments with the physical id 9, in the 3rd column, and its 2 node numbers in the last 2 columns. The rest are the triangles with a physical id of 10 in the 3rd column, and its 3 nodes in the last 3 columns. See the link that Lawrence gave to see what the other columns indicate [Buesing, Henrik] I guess my problem comes when creating the *.msh file with the gmsh gui. In my test.geo file I have the "Physical Line", but in my test.msh file every element has id "0". Probably I'm doing sth. wrong when creating the files with the gui. Thank you Stephan for clearing this up.
On 12/18/2015 04:06 AM, Buesing, Henrik wrote:
The physical ids *are* present in the .msh file. The 'elements' list at the end contains both triangles and line segments. In fact the first 16 are the line segments with the physical id 9, in the 3rd column, and its 2 node numbers in the last 2 columns. The rest are the triangles with a physical id of 10 in the 3rd column, and its 3 nodes in the last 3 columns. See the link that Lawrence gave to see what the other columns indicate
[Buesing, Henrik] I guess my problem comes when creating the *.msh file with the gmsh gui. In my test.geo file I have the "Physical Line", but in my test.msh file every element has id "0". Probably I'm doing sth. wrong when creating the files with the gui. Thank you Stephan for clearing this up.
I believe your example is missing a "Physical Surface" entry: Point(1) = {0, 0, 0, 1}; Point(2) = {0, 1, 0, 1}; Point(3) = {1, 1, 0, 1}; Point(4) = {1, 0, 0, 1}; Line(1) = {1, 4}; Line(2) = {4, 3}; Line(3) = {3, 2}; Line(4) = {2, 1}; Line Loop(12) = {4, 1, 2, 3}; Plane Surface(12) = {12}; Physical Surface(13) = {12}; Physical Line(7) = {4}; Physical Line(8) = {1}; Physical Line(9) = {2}; Physical Line(10) = {3};
participants (5)
-
Buesing, Henrik
-
Justin Chang
-
Lawrence Mitchell
-
Stephan Kramer
-
Tuomas Karna