Issues creating DMPlex from higher order mesh generated by gmsh
Hi. I'm trying to read a mesh of higher element order, in this example a mesh consisting of 10-node tetrahedral elements, from gmsh, into PETSC. But It looks like the mesh is not properly being loaded and converted into a DMPlex. gmsh tells me it has generated a mesh with 7087 nodes, but when I view my dm object it tells me it has 1081 0-cells. This is the printout I get ... Info : Done meshing order 2 (Wall 0.0169823s, CPU 0.016662s) Info : 7087 nodes 5838 elements ... DM Object: DM_0x84000000_0 1 MPI process type: plex DM_0x84000000_0 in 3 dimensions: Number of 0-cells per rank: 1081 Number of 1-cells per rank: 6006 Number of 2-cells per rank: 9104 Number of 3-cells per rank: 4178 Labels: celltype: 4 strata with value/size (0 (1081), 6 (4178), 3 (9104), 1 (6006)) depth: 4 strata with value/size (0 (1081), 1 (6006), 2 (9104), 3 (4178)) Cell Sets: 1 strata with value/size (2 (4178)) Face Sets: 6 strata with value/size (12 (190), 21 (242), 20 (242), 11 (192), 22 (242), 10 (188)) Field P2: adjacency FEM ... To replicate the error try generating a mesh according to https://gmsh.info/doc/texinfo/gmsh.html#t5 <https://gmsh.info/doc/texinfo/gmsh.html#t5> setting the element order to 2, and then loading the mesh using DMPlexCreateGmshFromFile I don't have any issues when i set the element order to 1. Thanks in advance, Vilmer
On Fri, May 5, 2023 at 10:55 AM Vilmer Dahlberg via petsc-users < [email protected]> wrote:
Hi.
I'm trying to read a mesh of higher element order, in this example a mesh consisting of 10-node tetrahedral elements, from gmsh, into PETSC. But It looks like the mesh is not properly being loaded and converted into a DMPlex. gmsh tells me it has generated a mesh with 7087 nodes, but when I view my dm object it tells me it has 1081 0-cells. This is the printout I get
Hi Vilmer, Plex makes a distinction between topological entities, like vertices, edges and cells, and the function spaces used to represent fields, like velocity or coordinates. When formats use "nodes", they mix the two concepts together. You see that if you add the number of vertices and edges, you get 7087, since for P2 there is a "node" on every edge. Is anything else wrong? Thanks, Matt
...
Info : Done meshing order 2 (Wall 0.0169823s, CPU 0.016662s)
Info : 7087 nodes 5838 elements
...
DM Object: DM_0x84000000_0 1 MPI process type: plex DM_0x84000000_0 in 3 dimensions: Number of 0-cells per rank: 1081 Number of 1-cells per rank: 6006 Number of 2-cells per rank: 9104 Number of 3-cells per rank: 4178 Labels: celltype: 4 strata with value/size (0 (1081), 6 (4178), 3 (9104), 1 (6006)) depth: 4 strata with value/size (0 (1081), 1 (6006), 2 (9104), 3 (4178)) Cell Sets: 1 strata with value/size (2 (4178)) Face Sets: 6 strata with value/size (12 (190), 21 (242), 20 (242), 11 (192), 22 (242), 10 (188)) Field P2: adjacency FEM ...
To replicate the error try generating a mesh according to
https://gmsh.info/doc/texinfo/gmsh.html#t5
<https://gmsh.info/doc/texinfo/gmsh.html#t5>
setting the element order to 2, and then loading the mesh using
DMPlexCreateGmshFromFile
I don't have any issues when i set the element order to 1.
Thanks in advance,
Vilmer
-- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
Matthew Knepley <[email protected]> writes:
On Fri, May 5, 2023 at 10:55 AM Vilmer Dahlberg via petsc-users < [email protected]> wrote:
Hi.
I'm trying to read a mesh of higher element order, in this example a mesh consisting of 10-node tetrahedral elements, from gmsh, into PETSC. But It looks like the mesh is not properly being loaded and converted into a DMPlex. gmsh tells me it has generated a mesh with 7087 nodes, but when I view my dm object it tells me it has 1081 0-cells. This is the printout I get
Hi Vilmer,
Plex makes a distinction between topological entities, like vertices, edges and cells, and the function spaces used to represent fields, like velocity or coordinates. When formats use "nodes", they mix the two concepts together.
You see that if you add the number of vertices and edges, you get 7087, since for P2 there is a "node" on every edge. Is anything else wrong?
Note that quadratic (and higher order) tets are broken with the Gmsh reader. It's been on my todo list for a while. As an example, this works when using linear elements (the projection makes them quadratic and visualization is correct), but is tangled when holes.msh is quadratic. $ $PETSC_ARCH/tests/dm/impls/plex/tutorials/ex1 -dm_plex_filename ~/meshes/holes.msh -dm_view cgns:s.cgns -dm_coord_petscspace_degree 2 SetFactory("OpenCASCADE"); radius = 0.3; DefineConstant[ nx = {1, Min 1, Max 30, Step 1, Name "Parameters/nx"} ny = {1, Min 1, Max 30, Step 1, Name "Parameters/ny"} extrude_length = {1, Min .1, Max 10, Step .1, Name "Parameters/extrusion length"} extrude_layers = {10, Min 1, Max 100, Step 1, Name "Parameters/extrusion layers"} ]; N = nx * ny; Rectangle(1) = {0, 0, 0, 1, 1, 0}; Disk(10) = {0.5, 0.5, 0, radius}; BooleanDifference(100) = {Surface{1}; Delete;}{Surface{10}; Delete;}; For i In {0:nx-1} For j In {0:ny-1} If (i + j > 0) Translate {i, j, 0} { Duplicata { Surface{100}; } } EndIf EndFor EndFor Coherence; // All the straight edges should have 8 elements Transfinite Curve {:} = 8+1; // Select the circles circles = {}; For i In {0:nx-1} For j In {0:ny-1} lo = .5 - radius - 1e-4; hi = .5 + radius + 1e-4; circles() += Curve In BoundingBox { i + lo, j + lo, -1e-4, i + hi, j + hi, +1e-4 }; EndFor EndFor // Circles need 16 elements Transfinite Curve {circles()} = 16+1; Mesh.Algorithm = 8; Extrude {0, 0, extrude_length} { Surface{100:100+N-1}; Layers{extrude_layers}; } e = 1e-4; extrude_start() = Surface In BoundingBox {-e, -e, -e, nx+e, ny+e, e}; extrude_end() = Surface In BoundingBox { -e, -e, extrude_length-e, nx+e, ny+e, extrude_length+e}; Physical Surface("start") = {extrude_start()}; Physical Surface("end") = {extrude_end()}; Physical Volume("solid") = {1:N};
On Mon, May 15, 2023 at 9:30 AM Jed Brown <[email protected]> wrote:
Matthew Knepley <[email protected]> writes:
On Fri, May 5, 2023 at 10:55 AM Vilmer Dahlberg via petsc-users < [email protected]> wrote:
Hi.
I'm trying to read a mesh of higher element order, in this example a mesh consisting of 10-node tetrahedral elements, from gmsh, into PETSC. But It looks like the mesh is not properly being loaded and converted into a DMPlex. gmsh tells me it has generated a mesh with 7087 nodes, but when I view my dm object it tells me it has 1081 0-cells. This is the printout I get
Hi Vilmer,
Plex makes a distinction between topological entities, like vertices, edges and cells, and the function spaces used to represent fields, like velocity or coordinates. When formats use "nodes", they mix the two concepts together.
You see that if you add the number of vertices and edges, you get 7087, since for P2 there is a "node" on every edge. Is anything else wrong?
Note that quadratic (and higher order) tets are broken with the Gmsh reader. It's been on my todo list for a while.
As an example, this works when using linear elements (the projection makes them quadratic and visualization is correct), but is tangled when holes.msh is quadratic.
$ $PETSC_ARCH/tests/dm/impls/plex/tutorials/ex1 -dm_plex_filename ~/meshes/holes.msh -dm_view cgns:s.cgns -dm_coord_petscspace_degree 2
Projection to the continuous space is broken because we do not have the lexicographic order on simplicies done. Are you sure you are projecting into the broken space? Thanks, Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
Hi Matt and Jed, Thanks for your replies. I did not consider that distinction Matt, that makes clearer. Maybe it's time to the DAG-stuff on the documentation another attempt... Jed, could you point me in the direction of a possible solution to this, if there exists one? In my (FEM) application I'm not using the weak-form stuff, but do I use PetscFE to describe my data layout and access it with DMPlexVec(Mat)Set(Get)Closure and friends. Thanks! Vilmer ________________________________ Från: Matthew Knepley <[email protected]> Skickat: den 15 maj 2023 15:42:20 Till: Jed Brown Kopia: Vilmer Dahlberg; [email protected] Ämne: Re: [petsc-users] Issues creating DMPlex from higher order mesh generated by gmsh On Mon, May 15, 2023 at 9:30 AM Jed Brown <[email protected]<mailto:[email protected]>> wrote: Matthew Knepley <[email protected]<mailto:[email protected]>> writes:
On Fri, May 5, 2023 at 10:55 AM Vilmer Dahlberg via petsc-users < [email protected]<mailto:[email protected]>> wrote:
Hi.
I'm trying to read a mesh of higher element order, in this example a mesh consisting of 10-node tetrahedral elements, from gmsh, into PETSC. But It looks like the mesh is not properly being loaded and converted into a DMPlex. gmsh tells me it has generated a mesh with 7087 nodes, but when I view my dm object it tells me it has 1081 0-cells. This is the printout I get
Hi Vilmer,
Plex makes a distinction between topological entities, like vertices, edges and cells, and the function spaces used to represent fields, like velocity or coordinates. When formats use "nodes", they mix the two concepts together.
You see that if you add the number of vertices and edges, you get 7087, since for P2 there is a "node" on every edge. Is anything else wrong?
Note that quadratic (and higher order) tets are broken with the Gmsh reader. It's been on my todo list for a while. As an example, this works when using linear elements (the projection makes them quadratic and visualization is correct), but is tangled when holes.msh is quadratic. $ $PETSC_ARCH/tests/dm/impls/plex/tutorials/ex1 -dm_plex_filename ~/meshes/holes.msh -dm_view cgns:s.cgns -dm_coord_petscspace_degree 2 Projection to the continuous space is broken because we do not have the lexicographic order on simplicies done. Are you sure you are projecting into the broken space? Thanks, Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/<http://www.cse.buffalo.edu/~knepley/>
participants (3)
-
Jed Brown -
Matthew Knepley -
Vilmer Dahlberg