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,
the name of the Nektar++-compatible mesh file that
NekMesh will generate, for instance
$NEKTUTORIALdirectory by calling
$NEK/NekMesh Helm_mesh.msh Helm_mesh.xml
$NEK/NekMesh Helm_mesh.msh Helm_mesh.xml:xml:uncompress
NekMeshto write the file out in uncompressed ASCII format. The generated .xml mesh file is shown below and can also be found in the
completeddirectory. It contains 5 tags encapsulated within the
GEOMETRYtag, 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,
EDGEcontains 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
GEOMETRYspecification 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
$NEKTUTORIALdirectory 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.vtufile 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,
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
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
</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
The third tag is
BOUNDARYCONDITIONS by which the boundary conditions are actually specified
for each boundary ID specified in the
BOUNDARYREGIONS tag. The syntax
corresponds to a
Dirichlet boundary condition for the variable
Neumann boundary conditions. For additional details on the various options
possible in terms of boundary conditions refer to the User-Guide.
<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 (
Lambda is the Helmholtz constant λ.
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
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
EXPANSIONS tag refer to the User-Guide.
Helm_conditions.xmlin the directory
$NEKTUTORIALwith λ = 2.5 or copy it from the