Figure 1.1: Mesh generated by Gmsh.
The pre-processing step consists in generating the mesh in a Nektar++ compatible format. For doing so we can first use the open-source mesh-generator Gmsh to first create the geometry, that in our case is a square and successively the mesh. The mesh format provided by Gmsh shown in Fig. (1.1) - i.e. .msh extension - is not compatible with the Nektar++ solvers and, therefore, it needs to be converted.
To do so, we need to run the pre-processing routine called MeshConvert within Nektar++. This routine requires two line arguments, the mesh file generated by Gmsh, ADR_mesh.msh, and the name of the Nektar++-compatible mesh file that MeshConvert will generate, for instance ADR_mesh.xml. The command line for this step is
The generated .xml mesh file is reported below. 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, is constituted by the physical regions of the mesh called composite, where the composites formed by elements represent the solution sub-domains - i.e. the mesh sub-domains where we want to solve the linear advection problem (note that we will use these composites to define expansion bases on each sub-domain in section 1.4) - while the composites formed by edges are the boundaries of the domain where we need to apply suitable boundary conditions (note that we will use these composites to specify the boundary conditions in section 1.4). Finally, the fifth tag, DOMAIN, formally specifies the overall solution domain as the union of the three composites forming the three solution subdomains (note that the specification of three subdomain - i.e. composites - in this case is necessary since they are constituted by different element shapes). For additional details on the GEOMETRY tag refer to the User-Guide.
After having generated the mesh file in a Nektar++-compatible format, ADR_mesh.xml, we can visualise the Jacobian distribution across the mesh in order to evaluate its quality. This step can be done by using the following Nektar++ built-in post-processing routine:
where the optional command -j calculate the Jacobian distribution for each element of the mesh. This will produce a ADR_mesh.vtu file which can be directly read by the open-source visualisation tool called Paraview. In Fig. 1.2 we show the Jacobian distribution for the mesh considered in this tutorial, ADR_mesh.xml.
Before configuring the input files, if we want to use periodic boundary conditions, we need to make sure that the edges of the two periodic boundaries (i.e. xb = [−1,1],yb) are properly aligned. Gmsh and the MeshConvert routine within Nektar++ does not guarantee proper alignment. However, MeshConvert provides a module, called peralign, that enforces the reordering of pair of edges (for more details refer to the User-Guide. We can apply this by using the following command:
where -m peralign is selecting the module for aligning the edges which are specified by surf1 and surf2 (their IDs in this case are 200 and 400) and dir is the direction to which the two periodic edges are perpendicular (in this case x).
After having typed the last command, we have a mesh, ADR_mesh_aligned.xml, which is fully compatible with Nektar++ and which allows us applying periodic boundary conditions without encountering errors.
We can therefore now configure the conditions: initial conditions, boundary conditions, parameters and solver settings.
