Finite-Element Mesh#

The finite-element mesh specifies the geometry and topology of the discretization. It must be generated using external software before running PyLith. PyLith supports triangular and quadrilateral cells in 2D and tetrahedral and hexahedral cells in 3D. The vertex ordering must follow the convention shown in Fig. 8 and Fig. 9. The cells define the geometry of the domain; the basis order and quadrature order used to discretize the solution subfields are specified separately.

The mesh information specifies the vertex coordinates and the vertices composing each cell in the mesh. The mesh information must also define at least one set of vertices for which displacement (Dirichlet) boundary conditions will be provided. In most realistic problems, there will be several vertex groups, each with a unique identifying label. For example, one group might define a surface of the mesh where displacement (Dirichlet) boundary conditions will be applied, another might define a surface where traction (Neumann) boundary conditions will be applied, while a third might specify a surface that defines a fault. Similarly, the mesh information contains cell labels that define the material type for each cell in the mesh. For a mesh with a single material type, there will only be a single label for every cell in the mesh. See Materials and Boundary Conditions for more detailed discussions of setting the materials and boundary conditions.

2D cell types

Fig. 8 Cells available for 2D problems are the triangle and the quadrilateral.#

3D cell types

Fig. 9 Cells available for 3D problems are the tetrahedron and the hexahedron.#

Mesh Importer#

The default component for the PyLithApp mesher facility is MeshImporter, which provides the capabilities of reading the finite-element mesh from files. The MeshImporter includes a facility for reordering the mesh. Reordering the mesh so that vertices and cells connected topologically reside close together in memory improves overall performance.

Pyre User Interface

See MeshImporter component

PyLith supports reading meshes generated by Cubit (Exodus II files) and Gmsh. We have implemented our own readers for Exodus II files. For Gmsh files we use the reader included in PETSc; PETSc also supports several other formats, but they have not been tested for use with PyLith. Currently, PyLith requires that boundary conditions be specified by marking vertices and all materials are marked by the same label material-id with different label values for each material. The PyLith readers create the labels from the mesh input files. Refer to Mesh generation with Cubit and Gmsh for information about generating finite-element meshes using Cubit and Gmsh.

ASCII Mesh Files - MeshIOAscii#

The MeshIOAscii object is intended for reading small, simple ASCII files containing a mesh constructed by hand. We use this file format extensively in small tests. PyLith Mesh ASCII File describes the format of the files.

Table 10 Translation of ASCII mesh “tags” to PyLith mesh ‘label’ and ‘label_value’.#

MeshIOAscii entity

label

label_value

material-ids

material-id (hardwired)

value

Group name

name

1 (default)

Pyre User Interface

MeshIOAscii Component

Cubit (Exodus II) Mesh Files - MeshIOCubit#

The MeshIOCubit object reads the NetCDF Exodus II files output from Cubit. Beginning with Cubit 11.0, the names of the nodesets are included in the Exodus II files and PyLith can use these nodeset names or revert to using the nodeset ids.

Table 11 Translation of Cubit mesh “tags” to PyLith mesh ‘label’ and ‘label_value’.#

Cubit entity

label

label_value

Material block

material-id (hardwired)

Block value

Nodeset

Nodeset name

1 (default)

Pyre User Interface

MeshIOCubit Component

Warning

There are two versions of Cubit: Sandia National Laboratory provides a version to U.S. government agencies, and Coreform provides another version to all other users. The two verisions used to be essentially the same, but the differences have started to grow. We strive to provide Cubit Journal scripts that work with both versions without modification, but this is becoming more difficult.

Please be aware that we cannot guarantee that all Cubit Journal files will work with all versions of Cubit. You may need to make small adjustments (usually updating geometry ids) to get them to work with the version of Cubit you are using.

Gmsh Files - MeshIOPetsc#

The MeshIOPetsc object supports reading a variety of mesh formats. We have only thoroughly tested this interface using Gmsh files.

Table 12 Translation of Gmsh mesh “tags” to PyLith mesh ‘label’ and ‘label_value’.#

Gmsh entity

label

label_value

Material physical groups

material-id (hardwired)

tag

Boundary condition physical groups

Physical group name

tag

Important

The Gmsh file must end in .msh for the reader to recognize that it is a Gmsh file.

Tip

You can view the mesh quality in Gmsh using ToolsStatistics. We prefer the condition number quality metric, which Gmsh provides as SICN (signed inverse of the condition number). Click on 3D next to SICN to color the cells by mesh quality. Click on Plot to view the cumulative distribution of the metric over the cells.

Pyre User Interface

MeshIOPetsc Component

Distribution among Processes - Distributor#

The distributor uses a partitioner to compute which cells should be placed on each processor, computes the overlap among the processors, and then distributes the mesh among the processors. The type of partitioner is set via PETSc settings.

Note

METIS/ParMETIS are not included in the PyLith binaries due to licensing issues.

Pyre User Interface

Distributor Component

Uniform Global Refinement - Refiner#

The refiner is used to decrease node spacing by a power of two by recursively subdividing each cell by a factor of two. In a 2D triangular mesh a node is inserted at the midpoint of each edge, splitting each cell into four cells (see Fig. 10). In a 2D quadrilateral mesh a node is inserted at the midpoint of each edge and at the centroid of the cell, splitting each cell into four cells. In a 3D tetrahedral mesh a node is inserted at the midpoint of each edge, splitting each cell into eight cells. In a 3D hexahedral mesh a node is inserted at the midpoint of each edge, the centroid of each face, and at the centroid of the cell, splitting each cell into eight cells.

Global refinement

Fig. 10 Global uniform mesh refinement of 2D and 3D linear cells. The blue lines and orange circles identify the edges and vertices in the original cells. The purple lines and green circles identify the new edges and vertices added to the original cells to refine the mesh by a factor of two.#

Refinement occurs after distribution of the mesh among processors. This allows one to run much larger simulations by (1) permitting the mesh generator to construct a mesh with a node spacing larger than that needed in the simulation and (2) operations performed in serial during the simulation setup phase, such as, adjusting the topology to insert cohesive cells and distribution of the mesh among processors uses this much smaller coarse mesh. For 2D problems the global mesh refinement increases the maximum problem size by a factor of \(4^{n}\), and for 3D problems it increases the maximum problem size by a factor of \(8^{n}\), where \(n\) is the number of recursive refinement levels. For a tetrahedral mesh, the element quality decreases with refinement so \(n\) should be limited to 1-2.