This section defines the mesh. It specifies a list of vertices, edges (in two or three dimensions) and faces (in three dimensions) and how they connect to create the elemental decomposition of the domain. It also defines a list of composites which are used in the Expansions and Conditions sections of the file to describe the polynomial expansions and impose boundary conditions.
The GEOMETRY section is structured as
It has two (required) attributes:
DIM
specifies the dimension of the expansion elements.
SPACE
specifies the dimension of the space in which the elements exist.These attributes allow, for example, a two-dimensional surface to be embedded in a three-dimensional space.
PARTITION
may also appear in a partitioned mesh. However, this
attribute should not be explicitly specified by the user.
The contents of each of the VERTEX
, EDGE
, FACE
, ELEMENT
and CURVED
sections may optionally
be compressed and stored in base64-encoded gzipped binary form, using either little-endian or
big-endian ordering, as specified by the COMPRESSED
attribute to these sections. Currently
supported values are:
B64Z-LittleEndian
: Base64 Gzip compressed using little-endian ordering.
B64Z-BigEndian
: Base64 Gzip compressed using big-endian ordering.When generating mesh input files for Nektar++ using NekMesh
, the binary compressed form
will be used by default. To convert a compressed XML file into human-readable ASCII format
use, for example:
GEOMETRY
section is
laid out in uncompressed ASCII format.
Vertices have three coordinates. Each has a unique vertex ID. In uncompressed form, they are
defined within VERTEX
subsection as follows:
The VERTEX
subsection has optional attributes which can be used to apply a transformation to
the mesh:XSCALE
, YSCALE
, ZSCALE
, XMOVE
, YMOVE
, ZMOVE
They specify scaling factors (centred at the origin) and translations to the vertex coordinates. For example, the following snippet
defines two vertices with coordinates (0.0,0.0,0.0),(1.0,2.0,0.0).
All of these attributes can be arbitrary analytic expressions depending on pre- defined constants and parameters defined in the XML file and mathematical operations/functions of the latter. If omitted, default scaling factors 1.0, and translations of 0.0, are assumed.
EDGES
section is only necessary when DIM=2
or DIM=3
in the parent GEOMETRY
element and may be omitted for one-dimensional meshes.
Edges are defined by two vertices. Each edge has a unique edge ID. In uncompressed form, they are defined in the file with a line of the form
FACES
section is only necessary when DIM=3
in the parent GEOMETRY
element and
may otherwise be omitted.
Faces are defined by three or more edges. Each face has a unique face ID. They are defined in the file with a line of the form
The choice of tag specified (T or Q), and thus the number of edges specified depends on the geometry of the face (triangle or quadrilateral).
Elements define the top-level geometric entities in the mesh. Their definition depends upon the dimension of the expansion. For two-dimensional expansions, an element is defined by a sequence of three or four edges. For three-dimensional expansions, the element is defined by a list of faces. Elements are defined in the file with a line of the form
Again, the choice of tag specified depends upon the geometry of the element. The element tags are:
S
Segment
T
Triangle
Q
Quadrilateral
A
Tetrahedron
P
Pyramid
R
Prism
H
Hexahedron
CURVED
section is only necessary if curved edges or faces are present in the mesh and
may otherwise be omitted.
For mesh elements with curved edges and/or curved faces, a separate entry is used to describe the control points for the curve. Each curve has a unique curve ID and is associated with a predefined edge or face. The total number of points in the curve (including end points) and their distribution is also included as attributes. The control points are listed in order, each specified by three coordinates. Curved edges are defined in the file with a line of the form
Composites define collections of elements, faces or edges. Each has a unique composite ID associated with it. All components of a composite entry must be of the same type. The syntax allows components to be listed individually, using ranges, or a mixture of the two. Examples include
The composites can also optionally contain a name which is then used in the multi-block VTK output to label the block descriptively rather than by ID, for example
This tag specifies composites which describe the entire problem domain. It has the form of