Figure 2.1: Mesh generated by Gmsh.
The pre-processing step consists of generating the mesh in a Nektar++ compatible format. To do this we can use the open-source mesh generator Gmsh to first define the geometry, which in our case is a square mesh. The resulting mesh is shown in Fig. 2.1. The mesh file format (.msh) generated by Gmsh is not directly compatible with the Nektar++ solvers and, therefore, it needs to be converted.
To do so, we need to run the Nektar++ pre-processing routine called NekMesh. This routine
requires two command-line arguments: the mesh file generated by Gmsh, Helm_mesh.msh; and
the name of the Nektar++-compatible mesh file that NekMesh will generate, for instance
Helm_mesh.xml.
$NEKTUTORIAL directory by calling
$NEK/NekMesh Helm_mesh.msh Helm_mesh.xml
or
$NEK/NekMesh Helm_mesh.msh Helm_mesh.xml:xml:uncompress
NekMesh to write the
file out in uncompressed ASCII format. The generated .xml mesh file is shown below and can
also be found in the completed directory. It contains 5 tags encapsulated within the GEOMETRY
tag, which describes the mesh. The first tag, VERTEX, contains the spatial coordinates of the
vertices of the various elements of the mesh. The second tag, EDGE contains the lines
connecting the vertices. The third tag, ELEMENT, defines the elements (note that in this
case we have both triangular - e.g. <T ID="0"> - as well as quadrilateral - e.g. <Q
ID="85"> - elements). The fourth tag, COMPOSITE, describes the physical regions of the
mesh and each composite may contain only one type of mesh entity. There are three
composites composed of triangular or quadrilateral elements which represent the
solution sub-domains where we want to solve the linear advection problem. We will
use these composites to define expansion bases on each sub-domain in section 2.1.
The composites formed by edges are the boundaries of the domain where we will
prescribe suitable boundary conditions in section 2.1. Finally, the fifth tag, DOMAIN,
formally specifies the overall solution domain as the union of the three element
composites. For additional details on the GEOMETRY specification refer to the User-Guide.
After generating the mesh file in the Nektar++-compatible format, Helm_mesh.xml, we can
visualise the mesh. This step can be done by using the following Nektar++ built-in
post-processing routine:
$NEKTUTORIAL directory by calling
$NEK/FieldConvert Helm_mesh.xml Helm_mesh.vtu
Alternatively a tecplot .dat file can be created by changing the extension of the second file, i.e.
$NEK/FieldConvert Helm_mesh.xml Helm_mesh.dat
Helm_mesh.vtu file which can be directly read by the open-source
visualisation tool called Paraview or VisIt. In Fig. 2.2 we show the mesh distribution for the
mesh considered in this tutorial, Helm_mesh.xml. We can now configure the conditions: initial conditions, boundary conditions, parameters and solver settings.
To set the various parameters, the solver settings and the initial and boundary conditions
needed, we create a new file called Helm_conditions.xml, which can be found within the
completed directory for this tutorial. This new file contains the CONDITIONS tag where we can
specify the parameters of the simulations, the solver settings, the initial conditions, the
boundary conditions and the exact solution and contains the EXPANSIONS tag where we can
specify the polynomial order to be used inside each element of the mesh, the type of expansion
bases and the type of points.
We begin to describe the Helm_conditions.xml file from the CONDITIONS tag, and in
particular from the boundary conditions, initial conditions and exact solution sections:
In the above piece of .xml, we first need to specify the non-optional tag called VARIABLES that
sets the solution variable (in this case u).
The second tag that needs to be specified is BOUNDARYREGIONS through which the user can
specify the regions where to apply the boundary conditions. For instance, <B ID="0"> C[100]
</B> indicates that composite 100 (which has been introduced in section 2) has a boundary
ID equal to 0. This boundary ID is successively used to prescribe the boundary
conditions.
The third tag is BOUNDARYCONDITIONS by which the boundary conditions are actually specified
for each boundary ID specified in the BOUNDARYREGIONS tag. The syntax <D VAR="u"
corresponds to a Dirichlet boundary condition for the variable u, while <N VAR="u"
corresponds to Neumann boundary conditions. For additional details on the various options
possible in terms of boundary conditions refer to the User-Guide.
Finally, <FUNCTION NAME="Forcing"> allows the specification of the Forcing function and
<FUNCTION NAME="ExactSolution"> permits us to provide the exact solution, against which
the L2 and L∞ errors are computed.
After having configured the VARIABLES tag, the boundary conditions, the forcing function and
the exact solution we can complete the tag CONDITIONS prescribing the parameters necessary
(PARAMETERS)and the solver settings (SOLVERINFO):
In the PARAMETERS tag, Lambda is the Helmholtz constant λ.
In the SOLVERINFO tag, EQTYPE is the type of equation to be solved, Projection is the spatial
projection operator to be used (which in this case is specified to be ‘Continuous’) For
additional solver-setting options refer to the User-Guide.
Finally, we need to specify the expansion bases we want to use in each of the three composites
or sub-domains (COMPOSITE="..") introduced in section 2:
In particular, for all the composites, COMPOSITE="C[i]" with i=1,2,3 we select identical basis
functions and polynomial order, where NUMMODES is the number of coefficients we want to use
for the basis functions (that is commonly equal to P+1 where P is the polynomial order of the
basis functions), TYPE allows selecting the basis functions FIELDS is the solution variable of
our problem and COMPOSITE are the mesh regions created by Gmsh. For additional details on
the EXPANSIONS tag refer to the User-Guide.
Helm_conditions.xml in the directory $NEKTUTORIAL with
λ = 2.5 or copy it from the completed directory.