Mesh
For a wide variety of numerical algorithms, a Grid (i.e. a mere ordering of points and their location) is not sufficient and a Mesh might be required. This is usually obtained by connecting grid points using polygonal elements (also referred to as cells), such as triangles or quadrilaterals. A mesh, denoted by , can then be defined as a collection of such elements :
For regular grids, the mesh elements can be inferred, as a
blocked arrangement of quadrilaterals. For unstructured grids or reduced grids (refSection{grid}),
these elements can
no longer be inferred, and explicit connectivity rules are required.
The Mesh class combines the knowledge of classes Nodes,
Cells, Edges, and provides a means to access connectivities
or adjacency relations between these classes).
Nodes describes the nodes of the mesh, Cells describes the elements
such as triangles and quadrilaterals, and Edges describes the lines connecting
the nodes of the mesh. refFigure{mesh-composition} sketches the composition of the
Mesh class with common access methods for its components. Differently from the
Grid, the Mesh may be distributed in memory. The physical domain is
decomposed in sub-domains and a corresponding mesh partition
is defined as:
More details regarding this aspect are given in refSection{parallelisation}.
A Mesh may simply be read from file by a MeshReader,
or generated from Grid by a MeshGenerator. The latter option is illustrated
in refFigure{conceptual_technical}, where the grid points will become the nodes
of the mesh elements. Following code shows how this can be achieved in practice for “structured” grids,
and refFigure{mesh-O16} visualises the resulting mesh for grids N16 and O16.
Grid grid( "O16" ); MeshGenerator generator( "structured" ); Mesh mesh = generator.generate( grid );
Because several element types can coexist as cells, the class Cells
is composing a more complex interplay of classes, such as Elements,
ElementType, BlockConnectivity, and MultiBlockConnectivity.
This composition is detailed in refFigure{mesh-cells}.
Atlas provide various type of connectivity tables: BlockConnectivity, IrregularConnectivity
and MultiBlockConnectivity. BlockConnectivity is used when all elements of the mesh are of
the same type, while IrregularConnectivity is more flexible and used when the elements in
the mesh can be of any type. The BlockConnectivity implementation has a regular structure
of the lookup tables and therefore provides better computational performance compared to
the IrregularConnectivity.
Finally the MultiBlockConnectivity supports those cases where the mesh contains various types
of elements but they can still be grouped into collections of elements of the same type so that
numerical algorithms can still benefit from performing operations using elements
of one element type at a time.
The Elements class provides the view of elements of one type with node and edge connectivities
as a BlockConnectivity. The interpretation
of the elements of this one type is delegated to the ElementType class.
The Cells class is composed of multiple Element and provides a unified view
of all elements regardless of their shape.
The MultiBlockConnectivity provides a matching unified connectivity table. Each block in the
MultiBlockConnectivity shares its memory with the BlockConnectivity present in the Element to
avoid memory duplication (see refFigure{mesh-connectivity}).
Although currently the mesh is composed of two-dimensional elements such as quadrilaterals and triangles, three-dimensional mesh elements such as hexahedra, tetrahedra, etc. are envisioned in the design and can be naturally embedded within the presented data structure. However, at least for the foreseeable future in NWP and climate applications, the vertical discretisation may be considered orthogonal to the horizontal discretisation due to the large anisotropy of physical scales in horizontal and vertical directions. Given a number of vertical levels, polygonal elements in the horizontal are then extruded to prismatic elements oriented in the vertical direction (e.g.cite{macdonald2011modelingirregulargrids}).