[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1. Overview

Gmsh is an automatic three-dimensional finite element mesh generator, primarily Delaunay, with built-in pre- and post-processing facilities. Its design goal is to provide a simple meshing tool for academic problems with parametric input and advanced visualization capabilities.

Gmsh is built around four modules: geometry, mesh, solver and post-processing. All geometrical, mesh, solver and post-processing instructions are prescribed either interactively using the graphical user interface (GUI) or in ASCII data files using Gmsh's own scripting language. Interactive actions generate language bits in the input files, and vice versa. This makes it possible to automate all treatments, using loops, conditionals and external system calls. A brief description of the four modules is given hereafter.

1.1 Geometry: geometrical entity definition  
1.2 Mesh: finite element mesh generation  
1.3 Solver: external solver interface  
1.4 Post-processing: scalar, vector and tensor field visualization  
1.5 What Gmsh is pretty good at ...  
1.6 ... and what Gmsh is not so good at  
1.7 Syntactic rules used in this document  
1.8 Comments  


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.1 Geometry: geometrical entity definition

Geometries are created in a bottom-up flow by successively defining points, oriented lines (line segments, circles, ellipses, splines, ...), oriented surfaces (plane surfaces, ruled surfaces, triangulated surfaces, ...) and volumes. Compound groups of geometrical entities can be defined, based on these elementary geometric entities. Gmsh's scripting language allows all geometrical entities to be fully parameterized.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.2 Mesh: finite element mesh generation

A finite element mesh is a tessellation of a given subset of the three-dimensional space by elementary geometrical elements of various shapes (in Gmsh's case: lines, triangles, quadrangles, tetrahedra, prisms, hexahedra and pyramids), arranged in such a way that if two of them intersect, they do so along a face, an edge or a node, and never otherwise. All the finite element meshes produced by Gmsh are considered as "unstructured", even if they were generated in a "structured" way (e.g., by extrusion). This implies that the elementary geometrical elements are defined only by an ordered list of their nodes but that no predefined order relation is assumed between any two elements.

The mesh generation is performed in the same bottom-up flow as the geometry creation: lines are discretized first; the mesh of the lines is then used to mesh the surfaces; then the mesh of the surfaces is used to mesh the volumes. In this process, the mesh of an entity is only constrained by the mesh of its boundary(1). This automatically assures the conformity of the mesh when, for example, two surfaces share a common line. But this also implies that the discretization of an "isolated" (n-1)-th dimensional entity inside an n-th dimensional entity does not constrain the n-th dimensional mesh. Every meshing step is constrained by the characteristic length field, which can be uniform, specified by characteristic lengths associated with elementary geometrical entities, or associated with another mesh (the background mesh).

For each meshing step, all structured mesh directives are executed first, and serve as additional constraints for the unstructured parts. The implemented Delaunay algorithm is subdivided in the following five steps for surface/volume discretization:

  1. trivial meshing of a box including the convex polygon/polyhedron defined by the boundary nodes resulting from the discretization of the lines/surfaces;
  2. creation of the initial mesh by insertion of all the nodes on the lines/surfaces thanks to the Bowyer algorithm;
  3. boundary restoration to force all the edges/faces of the lines/surfaces to be present in the initial mesh;
  4. suppression of all the unwanted triangles/tetrahedra (in particular those containing the nodes of the initial box);
  5. insertion of new nodes by the Bowyer algorithm until the characteristic size of each simplex is lower or equal to the characteristic length field evaluated at the center of its circumscribed circle/sphere.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.3 Solver: external solver interface

External solvers can be interfaced with Gmsh through Unix or TCP/IP sockets, which permits to easily launch external computations and to collect and exploit the simulation results within Gmsh's post-processing module. The default solver interfaced with Gmsh is GetDP (http://www.geuz.org/getdp/). Small examples of solvers written in C, C++, Perl and Python are available in the source distribution (in the `utils/solvers/' directory).


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.4 Post-processing: scalar, vector and tensor field visualization

Multiple post-processing scalar, vector or tensor maps can be loaded and manipulated (globally or individually) along with the geometry and the mesh. Scalar fields are represented by iso-value lines/surfaces or color maps, while vector fields are represented by three-dimensional arrows or displacement maps. Post-processing functions include section computation, offset, elevation, boundary and component extraction, color map and range modification, animation, vector graphic output, etc. All post-processing options can be accessed either interactively or through the input ASCII text files. Scripting permits to automate all post-processing operations, e.g., for the creation of animations. User-defined operations can also be performed on post-processing views through dynamically loadable plugins.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.5 What Gmsh is pretty good at ...

Gmsh is a (relatively) small program, and was principally developed "in academia, to solve academic problems"... Nevertheless, over the years, many people outside universities have found Gmsh useful in their day-to-day jobs. Here is a tentative list of what Gmsh does best:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.6 ... and what Gmsh is not so good at

Due to its historical background and limited developer manpower, Gmsh has also some (a lot of?) weaknesses:

If you have the skills and some free time, feel free to join the project! We gladly accept any code contributions (see section 10. Programming notes) to remedy the aforementioned (and all other) shortcomings...


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.7 Syntactic rules used in this document

Here are the rules we tried to follow when writing this user's guide. Note that metasyntactic variable definitions stay valid throughout the manual (and not only in the sections where the definitions appear).

  1. Keywords and literal symbols are printed like this.
  2. Metasyntactic variables (i.e., text bits that are not part of the syntax, but stand for other text bits) are printed like this.
  3. A colon (:) after a metasyntactic variable separates the variable from its definition.
  4. Optional rules are enclosed in < > pairs.
  5. Multiple choices are separated by |.
  6. Three dots (...) indicate a possible (multiple) repetition of the preceding rule.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.8 Comments

All Gmsh ASCII text input files support both C and C++ style comments:

  1. any text comprised between /* and */ pairs is ignored;
  2. the rest of a line after a double slash // is ignored.

These commands won't have the described effects inside double quotes or inside keywords. Also note that `white space' (spaces, tabs, new line characters) is ignored inside all expressions.


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

Back to geuz.org/gmsh