Advection Solver

PIC

Advection Solver

Department of Aeronautics, Imperial College London, UKScientific Computing and Imaging Institute, University of Utah, USA December 2, 2016

Nektar++ Tutorial

1 Introduction x1.1 Goals x1.2 Background x1.3 Problem description 2 Pre-processing x2.1 Mesh generation x2.2 Configuring problem definitions 3 Running the solver 4 Post-processing 5 Summary x5.1 Additional Exercises

1 Introduction

[next] [prev] [prev-tail] [tail] [up] Chapterx1Introduction Welcome to the tutorial of the Advection problem using the Advection-Diffusion-Reaction (ADR) Solver in the Nektar++ framework. This tutorial is aimed to show the main features of the ADR solver in a simple manner. If you have not already downloaded and installed Nektar++, please do so by visiting nektar.info, where you can also find the User-Guide with the instructions to install the library. This tutorial requires:

Nektar++ ADRSolver and pre- and post-processing tools,

the open-source mesh generator Gmsh,

the visualisation tool Paraview or VisIt

1.1 Goals

After the completion of this tutorial, you will be familiar with:

the generation of a simple mesh in Gmsh and its conversion into a Nektar++-compatible format;

the visualisation of the mesh in Paraview or VisIt

the setup of the initial and boundary conditions, the parameters and the solver settings;

running a simulation with the ADR solver; and

the post-processing of the data and the visualisation of the results in Paraview or VisIt.

Task: 1.1 Prepare for the tutorial. Make sure that you have:

Installed and tested Nektar++ v4.3.5from a binary package, or compiled it from source. By default binary packages will install all executables in /usr/bin. If you compile from source they will be in the sub-directory dist/bin of the build directory you created in the Nektar++ source tree. We will refer to the directory containing the executables as $NEK for the remainder of the tutorial.

Downloaded the tutorial files: basics-advection-diffusion.tar.gz

Unpack it using tar -xzvf basics-advection-diffusion.tar.gz to produce a

directory basics-advection-diffusion with subdirectories called tutorial and

complete.

We will refer to the tutorial directory as $NEKTUTORIAL.

The tutorial folder contains:

a Gmsh file to generate the mesh, ADR_mesh.geo;

a .msh file containing the mesh in Gmsh format, ADR_mesh.msh;

Task: 1.2 Additionally, you should also install

a visualization package capable of reading VTK files, such as ParaView (which can be downloaded from here) or VisIt (downloaded from here). Alternatively, you can generate Tecplot formatted .dat files for use with Tecplot.

1.2 Background

The ADR solver can solve various problems, including the unsteady advection, unsteady diffusion, unsteady advection diffusion equation, etc. For a more detailed description of this solver, please refer to the User-Guide.

In this tutorial we focus on the unsteady advection equation

. \frac{∂u}{∂t} + V · ∇u = 0,

(1.1) where u is the independent variable and V = [V_{x}V_{y}V_{z}] is the advection velocity. The unsteady advection equation can be solved in one, two and three spatial dimensions. We will here consider a two-dimensional problem, so that V = [V_{x}V_{y}].

1.3 Problem description

The problem we want to run consists of a given initial condition (which depends on x and y) travelling in the x-direction at a constant advection velocity. To model this problem we create a computational domain also referred to as mesh or grid (see section 2.1) on which we apply the following two-dimensional function as initial condition and periodic as well as time-dependent Dirichlet boundary conditions at the mesh boundaries

.  \frac{∂u}{∂t} + V_{x} \frac{∂u}{∂x} + V_{y} \frac{∂u}{∂y} = 0, u(x, y; t = 0) = sin(κx) cos(κy), u(x_{b} = [−1, 1], y_{b}; t) = periodic, u(x_{b}, y_{b} = [−1, 1]; t) = sin(κ(x − V_{x}t)) cos(κ(y − V_{y}t)),

(1.2)

where x_{b} and y_{b} represent the boundaries of the computational domain (see section 2.2), V_{x} = 2, V_{y} = 0 and κ = 2π.

We successively setup the other parameters of the problem, such as the time-step, the time-integration scheme, the I/O configuration, etc. (see section 2.2). We finally run the solver (see section 3) and post-process the data in order to visualise the results (see section 4).

[next] [prev] [prev-tail] [front] [up] 2 Pre-processing

[next] [prev] [prev-tail] [tail] [up]

Chapterx2Pre-processing

As already mentioned to set up the probelm we have two step. The first is setting up a mesh in an input xml format consistent with Nektar++ as discussed in section 2.1. We also need to configure the problem initial, boundary and parameters which are discussed in 2.2.

2.1 Mesh generation

The first pre-processing step consists in generating the mesh in a Nektar++ compatible format. One option to do this is to 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. (2.1) - i.e. .msh extension - is not consistent with the Nektar++ solvers and, therefore, it needs to be converted. pict Figurex2.1: Mesh generated by Gmsh.

To do so, we need to run the pre-processing routine called NekMesh 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 NekMesh will generate, for instance ADR_mesh.xml. The command line for this step is Task: 2.1 Convert the .meh file into a Nektar++ input by calling

 $NEK/NekMesh ADR_mesh.msh ADR_mesh.xml

or

 $NEK/NekMesh ADR_mesh.msh ADR_mesh.xml:xml:uncompress

Note that by default the information is stored in Xml blocks of compressed data to reduce the size of large meshes. The second command above tells the converter NekMesh to write the file out in uncompressed format. The generated .xml mesh file is reported 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, 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 2.2) - 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 2.2). 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.

1 <? xmlxversion="1.0" xencoding=" utf−8" x?> x 2 < NEKTAR> x 3 xxx< GEOMETRYxDIM= "2"xSPACE= "2"> x 4 xxxxxx< VERTEX> x 5 xxxxxxxxx< VxID= "0"> 2.00000000 e−01 x−1.00000000 e+00 x0.00000000 e+00</ V> x 6 xxxxxxxxx< VxID= "1"> 5.09667784 e−01 x−6.15240515 e−01 x0.00000000 e+00</ V> x 7 xxxxxxxxx...x 8 xxxxxxxxx< VxID= "68"> −1.00000000 e+00 x1.25000000 e−01 x0.00000000 e+00</ V> x 9 xxxxxx</ VERTEX> x 10 xxxxxx< EDGE> x 11 xxxxxxxxx< ExID= "0"> x0x1x</ E> x 12 xxxxxxxxx< ExID= "1"> x1x2x</ E> x 13 xxxxxxxxx...x 14 xxxxxxxxx< ExID= "153"> x40x68x</ E> x 15 xxxxxx</ EDGE> x 16 xxxxxx< ELEMENT> x 17 xxxxxxxxx< TxID= "0"> x0x1x2x</ T> x 18 xxxxxxxxx< TxID= "1"> x3x4x5x</ T> x 19 xxxxxxxxx...x 20 xxxxxxxxx< QxID= "85"> x146x93x153x151x</ Q> x 21 xxxxx</ ELEMENT> x 22 xxxxxx< COMPOSITE> x 23 xxxxxxxxx< CxID= "1"> xT[0−30] x</ C> x 24 xxxxxxxxx< CxID= "2"> xQ[62−85] x</ C> x 25 xxxxxxxxx< CxID= "3"> xT[31−61] x</ C> x 26 xxxxxxxxx< CxID= "100"> xE[46,12,20,10,45] x</ C> x 27 xxxxxxxxx< CxID= "200"> xE[50,32,108,111,114,117,87,103] x</ C> x 28 xxxxxxxxx< CxID= "300"> xE[100,64,74,66,99] x</ C> x 29 xxxxxxxxx< CxID= "400"> xE[49,33,148,150,152−153,86,104] x</ C> x 30 xxxxxx</ COMPOSITE> x 31 xxxxxx< DOMAIN> xC[1,2,3]x</ DOMAIN> x 32 xxx</ GEOMETRY> x 33 </ NEKTAR>

After having generated the mesh file in a Nektar++-compatible format, ADR_mesh.xml, we can visualise the mesh. This step can be done by using the following Nektar++ built-in post-processing routine: Task: 2.2 Convert the .xml file into a .vtu format by calling

 $NEK/FieldConvert ADR_mesh.xml ADR_mesh.vtu

Alternatively a tecplot .dat file can be created by changing the extension of the second file, i.e.

 $NEK/FieldConvert ADR_mesh.xml ADR_mesh.dat

This will produce a ADR_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, ADR_mesh.xml.

PIC Figurex2.2: Mesh distribution with local polynomial subdivision 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. x_{b} = [−1, 1], y_{b}) are properly aligned. Gmsh and the NekMesh routine within Nektar++ does not guarantee proper alignment. However, NekMesh 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: Task: 2.3 Convert the .xml file into a .xml file with periodic edges aligned

 $NEK/NekMesh -m peralign:surf1=200:surf2=400:dir=x ADR_mesh.xml
 ADR_mesh_aligned.xml

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). Note that since we have not used the extension :xml:uncompress the blocks of data in this file are now stored in compressed format.

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.

2.2 Configuring problem definitions

To set the various problem parameters, the solver settings, initial and boundary conditions and the expansion basese, we create a new file called ADR_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 ADR_conditions.xml file from the CONDITIONS tag, and in particular from the boundary conditions, initial conditions and exact solution sections:

1 < CONDITIONS> x 2 xxx...x 3 xxx...x 4 xxx...x 5 xxx< VARIABLES> x 6 xxxxxx< VxID= "0"> xux</ V> x 7 xxx</ VARIABLES> x 8 x 9 xxx< BOUNDARYREGIONS> x 10 xxxxxx< BxID= "0"> xC[100]x</ B> x 11 xxxxxx< BxID= "1"> xC[200]x</ B> x 12 xxxxxx< BxID= "2"> xC[300]x</ B> x 13 xxxxxx< BxID= "3"> xC[400]x</ B> x 14 xxx</ BOUNDARYREGIONS> x 15 x 16 xxx< BOUNDARYCONDITIONS > x 17 xxxxxx< REGIONxREF= "0"> x 18 xxxxxxxxx< DxVAR= "u"xUSERDEFINEDTYPE = "TimeDependent"x 19 xxxxxxxxxVALUE= "sin(k∗(x− advx∗t))∗cos(k∗(y− advy∗t))"x/> x 20 xxxxxx</ REGION> x 21 xxxxxx< REGIONxREF= "1"> x 22 xxxxxxxxx< PxVAR= "u"xVALUE= "[3]"x/> x 23 xxxxxx</ REGION> x 24 xxxxxx< REGIONxREF= "2"> x 25 xxxxxxxxx< DxVAR= "u"xUSERDEFINEDTYPE = "TimeDependent"x 26 xxxxxxxxxVALUE= "sin(k∗(x− advx∗t))∗cos(k∗(y− advy∗t))"x/> x 27 xxxxxx</ REGION> x 28 xxxxxx< REGIONxREF= "3"> x 29 xxxxxxxxx< PxVAR= "u"xVALUE= "[1]"x/> x 30 xxxxxx</ REGION> x 31 xxx</ BOUNDARYCONDITIONS > x 32 x 33 xxx< FUNCTIONxNAME= "InitialConditions"> x 34 xxxxxx< ExVAR= "u"xVALUE= "sin(k∗x)∗cos(k∗y)"x/> x 35 xxx</ FUNCTION> x 36 x 37 xxx< FUNCTIONxNAME= "AdvectionVelocity"> x 38 xxxxxx< ExVAR= "Vx"xVALUE= "advx"x/> x 39 xxxxxx< ExVAR= "Vy"xVALUE= "advy"x/> x 40 xxx</ FUNCTION> x 41 x 42 xxx< FUNCTIONxNAME= "ExactSolution"> x 43 xxxxxx< ExVAR= "u"xVALUE= "sin(k∗(x− advx∗t))∗cos(k∗(y− advy∗t))"x/> x 44 xxx</ FUNCTION> x 45 </ CONDITIONS>

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.1) 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 (note that in this case we used the additional tag USERDEFINEDTYPE="TimeDependent" which is a special option when using time-dependent boundary conditions), while <P VAR="u" corresponds to Periodic boundary conditions. For additional details on the various options possible in terms of boundary conditions refer to the User-Guide.

Finally, <FUNCTION NAME="InitialConditions"> allows the specification of the initial conditions, <FUNCTION NAME="AdvectionVelocity"> specifies the advection velocities in both the x- and y-direction (for this two-dimensional case) and is a non-optional parameters for the unsteady advection equation and <FUNCTION NAME="ExactSolution"> permits us to provide the exact solution, against which the L_{2} and L_{∞} errors are computed.

After having configured the VARIABLES tag, the initial and boundary conditions, the advection velocity and the exact solution we can complete the tag CONDITIONS prescribing the parameters necessary (PARAMETERS)and the solver settings (SOLVERINFO):

1 < CONDITIONS> x 2 xxx< PARAMETERS> x 3 xxxxxx< P> xFinTimex = x1.0x </ P> x 4 xxxxxx< P> xTimeStepx = x0.001x </ P> x 5 xxxxxx< P> xNumStepsx = xFinTime/TimeStepx</ P> x 6 xxxxxx< P> xIO_CheckStepsx= x100x </ P> x 7 xxxxxx< P> xIO_InfoStepsx = x100x </ P> x 8 xxxxxx< P> xadvxx = x2.0x </ P> x 9 xxxxxx< P> xadvyx = x0.0x </ P> x 10 xxxxxx< P> xkx = x2∗PIx </ P> x 11 xxx</ PARAMETERS> x 12 x 13 xxx< SOLVERINFO> x 14 xxxxxx< IxPROPERTY= "EQTYPE"x VALUE= "UnsteadyAdvection"x /> x 15 xxxxxx< IxPROPERTY= "Projection"x VALUE= "DisContinuous"x /> x 16 xxxxxx< IxPROPERTY= "AdvectionType"x VALUE= "WeakDG"x /> x 17 xxxxxx< IxPROPERTY= "UpwindType"x VALUE= "Upwind"x /> x 18 xxxxxx< IxPROPERTY= "TimeIntegrationMethod"x VALUE= "ClassicalRungeKutta4" /> x 19 xxx</ SOLVERINFO> x 20 xxx...x 21 xxx...x 22 xxx...

In the PARAMETERS tag, FinTime is the final physical time of the simulation, TimeStep is the time-step, NumSteps is the number of steps, IO_CheckSteps is the step-interval when a output file is written, IO_InfoSteps is the step-interval when some information about the simulation are printed to the screen, advx and advy are the advection velocities V_{x} and V_{y}, respectively and k is the κ parameter. Note that advx, advy and k are used in the boundary and initial conditions tags as well as in the specification of the advection velocities.

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 ‘DisContinuous’), AdvectionType is the advection operator to be adopted (where the VALUE ‘WeakDG’ implies the use of a weak Discontinuous Galerkin technique), UpwindType is the numerical flux to be used at the element interfaces when a discontinuous projection is used, TimeIntegrationMethod allows selecting the time-integration scheme. 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.1:

1 < EXPANSIONS> x 2 xxx< ExCOMPOSITE= "C[1]"xNUMMODES= "5"xTYPE= "MODIFIED"xFIELDS= "u"x/> x 3 xxx< ExCOMPOSITE= "C[2]"xNUMMODES= "5"xTYPE= "MODIFIED"xFIELDS= "u"x/> x 4 xxx< ExCOMPOSITE= "C[3]"xNUMMODES= "5"xTYPE= "MODIFIED"xFIELDS= "u"x/> x 5 </ EXPANSIONS>

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.

Task: 2.4 Generate the file ADR_conditions.xml or copy it from the completed directory.

[next] [prev] [prev-tail] [front] [up] 3 Running the solver

[next] [prev] [prev-tail] [tail] [up]

Chapterx3Running the solver Now that we have the mesh file compatible with Nektar++ and periodic boundary conditions, ADR_mesh_aligned.xml, and we have completed the condition file, ADR_conditions.xml, we can run the solver by using the following command: Task: 3.1 Run the ADRSolver using the command:

$NEK/ADRSolver ADR_mesh_aligned.xml ADR_conditions.xml

Note that we have written the mesh in a separate file from the conditions. This is generally more efficient because it allows reopening just the condition file which is much smaller in size than the mesh file (especially for large problems). However, we could also have written both the mesh and the conditions in unique file and used the same command as above for running the solver (in this case with just one file instead of two as line argument).

As soon as the file finishes running, we should see the following screen output:

=========================================xxxxxxxxxxxxxxxxxEquationType:xUnsteadyAdvectionxxxxxxxxxxxxxxxxxSessionxName:xADR_mesh_alignedxxxxxxxxxxxxxxxxxSpatialxDim.:x2xxxxxxxxxxxMaxxSEMxExp.xOrder:x5xxxxxxxxxxxxxxxExpansionxDim.:x2xxxxxxxxxxxxxxxRiemannxSolver:xUpwindxxxxxxxxxxxxxxxAdvectionxType:xxxxxxxxxxxxxxProjectionxType:xDiscontinuousxGalerkinxxxxxxxxxxxxxxxxxxxxAdvection:xexplicitxxxxxxxxxxxxxxxxxxxxDiffusion:xexplicitxxxxxxxxxxxxxxxxxxxxTimexStep:x0.001xxxxxxxxxxxxxxxxxNo.xofxSteps:x1000xxxxxxxxxxCheckpointsx(steps):x100xxxxxxxxxxxxxIntegrationxType:xClassicalRungeKutta4x==========================================xInitialxConditions:xxx-xFieldxu:xsin(k*x)*cos(k*y)xWriting:x"ADR_mesh_aligned_0.chk"xSteps:x100xxxxxxTime:x0.1xxxxxxxxxxCPUxTime:x0.435392sxWriting:x"ADR_mesh_aligned_1.chk"xSteps:x200xxxxxxTime:x0.2xxxxxxxxxxCPUxTime:x0.430588sxWriting:x"ADR_mesh_aligned_2.chk"xSteps:x300xxxxxxTime:x0.3xxxxxxxxxxCPUxTime:x0.428503sxWriting:x"ADR_mesh_aligned_3.chk"xSteps:x400xxxxxxTime:x0.4xxxxxxxxxxCPUxTime:x0.428529sxWriting:x"ADR_mesh_aligned_4.chk"xSteps:x500xxxxxxTime:x0.5xxxxxxxxxxCPUxTime:x0.430142sxWriting:x"ADR_mesh_aligned_5.chk"xSteps:x600xxxxxxTime:x0.6xxxxxxxxxxCPUxTime:x0.429481sxWriting:x"ADR_mesh_aligned_6.chk"xSteps:x700xxxxxxTime:x0.7xxxxxxxxxxCPUxTime:x0.433232sxWriting:x"ADR_mesh_aligned_7.chk"xSteps:x800xxxxxxTime:x0.8xxxxxxxxxxCPUxTime:x0.431088sxWriting:x"ADR_mesh_aligned_8.chk"xSteps:x900xxxxxxTime:x0.9xxxxxxxxxxCPUxTime:x0.427919sxWriting:x"ADR_mesh_aligned_9.chk"xSteps:x1000xxxxxTime:x1xxxxxxxxxxxxCPUxTime:x0.436098sxWriting:x"ADR_mesh_aligned_10.chk"xTime-integrationxx:x4.31097sxWriting:x"ADR_mesh_aligned.fld"x-------------------------------------------xTotalxComputationxTimex=x4sx-------------------------------------------xLx2xerrorx(variablexu)x:x0.00863475xLxinfxerrorx(variablexu)x:x0.0390366

where the L2 and L inf errors are evaluated against the <FUNCTION NAME="ExactSolution"> provided in the ADR_conditions.xml file. To have a more detailed view on the solver settings and parameters used, it is possible to use the -v option (which stands for verbose) as follows: Task: 3.2 Rerun the ADRSolver with the verbose option:

$NEK/ADRSolver -v ADR_mesh_aligned.xml ADR_conditions.xml

The simulation has now produced 11 .chk binary files and a final .fld binary file (which in this case is identical to the tenth .chk file). These binary files contain the result of the simulation every 100 time-steps. This output interval has been chosen through the parameter IO_CheckSteps in ADR_conditions.xml, which was set equal to 100. Also, it is possible to note that every 100 time-steps the solver outputs the physical time of the simulation and the CPU time required for doing 100 time-steps. The interval of 100 time-steps is decided through the parameter IO_InfoSteps, which was also equal to [next] [prev] [prev-tail] [front] [up] 4 Post-processing

[next] [prev] [prev-tail] [tail] [up]

Chapterx4Post-processing Now that the simulation has been completed, we need to post-process the file in order to visualise the results. In order to do so, we can use the built-in post-processing routines within Nektar++. In particular, we can use the following command Task: 4.1 Convert the .xml and .chk files into a .vtu format by calling

 $NEK/FieldConvert ADR_mesh_aligned.xml ADR_conditions.xml ADR_mesh_aligned_0.chk
 ADR_mesh_aligned_0.vtu

which generates a .vtu file that is a readable format for the open-source package Paraview. Note that we typically have to specify both the mesh .xml file and the condition .xml file. We can now open the .vtu file just generated (which corresponds to the initial condition, being the number ‘0’ .chk file) and visualise it with Paraview. This produces the image in Fig.x(4.1).

PIC Figurex4.1: Initial solution x It is possible to use the same post-processing command for visualising the other .chk, thus monitoring the evolution of the simulation in time.

[next] [prev] [prev-tail] [front] [up] 5 Summary

[prev] [prev-tail] [tail] [up] Chapterx5Summary You should be now familiar with the following topics:

Generate a simple mesh in Gmsh and convert it in a Nektar++-compatible format; Visualise the mesh in Paraview; Setup the initial and boundary conditions, the parameters and the solver settings; Run the ADR solver; and Post-process the data in order to visualise results in Paraview.

5.1 Additional Exercises

Increase the polynomial order and plot the L_{2} error vs. the polynomial order in a semilogarithmic scale. Change the projection operator for a fixed polynomial order and look at the error. Increase the time-step for a fixed polynomial order and look at the error. If the solver is compiled with the MPI option, then try running the case in parallel

with mpirun -np 2.

Change the Projection Operator to Continuous to see the same problem running with a CG solver. Change the solver type to AdvectionDiffusion and CG to change the problem type. You also need to update the AdvectionType to NonConservative.

Tip: To check the additional settings and parameters that can be used for this solver, check the folder: $NEK/solvers/ADRSolver/Tests/ where you can find several tests associated to the ADR solver.

[prev] [prev-tail] [front] [up] [next]