Merge pull request #67 from su2code/develop

Develop

Author: pcarruscag

_data/tutorials.yml

@@ -26,6 +26,7 @@
   - Inc_Laminar_Step
   - Inc_Laminar_Cavity
   - Inc_Streamwise_Periodic
+  - Inc_Species_Transport
 
 - title: Structural Mechanics
   tutorials:
@@ -48,6 +49,7 @@
   - Inviscid_3D_Constrained_ONERAM6
   - Multi_Objective_Shape_Design
   - Unsteady_Shape_Opt_NACA0012
+  - Species_Transport
 
 - title: Event Content
   tutorials:

_docs_v7/Custom-Output.md

@@ -136,11 +136,11 @@ For the compressible Navier-Stokes solver (i.e. `SOLVER=NAVIER_STOKES`), a **non
 |  `DRAG` | Total Drag coefficient. |  `AERO_COEFF`  |
 |  `LIFT` | Total Lift coefficient |  `AERO_COEFF`  |
 |  `SIDEFORCE` | Total Sideforce coefficient.  |  `AERO_COEFF`  |
-|  `MOMENT-X` | Total Moment around the x-axis.  |  `AERO_COEFF`  |
-|  `MOMENT-Y` | Total Moment around the y-axis.  |  `AERO_COEFF`  |
-|  `MOMENT-Z` | Total Moment around the z-axis. |  `AERO_COEFF`  |
-|  `FORCE-X` | Total Force in x direction. |  `AERO_COEFF`  |
-|  `FORCE-Y` | Total Force in y direction. |  `AERO_COEFF`  |
-|  `FORCE-Z` | Total Force in z direction.|  `AERO_COEFF`  |
+|  `MOMENT_X` | Total Moment around the x-axis.  |  `AERO_COEFF`  |
+|  `MOMENT_Y` | Total Moment around the y-axis.  |  `AERO_COEFF`  |
+|  `MOMENT_Z` | Total Moment around the z-axis. |  `AERO_COEFF`  |
+|  `FORCE_X` | Total Force in x direction. |  `AERO_COEFF`  |
+|  `FORCE_Y` | Total Force in y direction. |  `AERO_COEFF`  |
+|  `FORCE_Z` | Total Force in z direction.|  `AERO_COEFF`  |
 |  `EFFICIENCY` | Total Lift-to-drag ratio. |  `AERO_COEFF`  |
 

_docs_v7/Restart-File.md

@@ -3,9 +3,43 @@ title: Restart File
 permalink: /docs_v7/Restart-File/
 ---
 
+
+## Saving files for restarts or adjoint runs
+
 The SU2 binary restart format has the extension `.dat`, but it is also possible to write out restart files in a simple ASCII file format with extension `.csv`. Have a look at the [Output section](/docs_v7/Custom-Output/) to learn how to change output file formats.
 
-The restart files are used to restart the code from a previous solution and also to run the adjoint simulations, which require a flow solution as input. In order to run an adjoint simulation, the user must first change the name of the `restart_flow.dat`  file (or `restart_flow.csv` if ASCII format) to `solution_flow.dat` (or `solution_flow.csv`) in the execution directory (these default file names can be adjusted in the config file). It is important to note that the adjoint solver will create a different adjoint restart file for each objective function, e.g. `restart_adj_cd.dat`.
+The restart files are used to restart the code from a previous solution and also to run the adjoint simulations, which require a flow solution as input. To save a restart file, the user needs to add the option `RESTART` to the keyword `OUTPUT_FILES`:
+
+`OUTPUT_FILES= RESTART`
+
+A restart file with the name given by the keyword `RESTART_FILENAME` is then saved at the end of the simulation, or after every number of iterations given by the keyword `OUTPUT_WRT_FREQ`. For instance,
+
+`RESTART_FILENAME= restart_flow` \
+`OUTPUT_WRT_FREQ= 100`
+
+will write the the file restart_flow.dat every 100 iterations when then the total number of iterations is larger than 100, or only once at the end of the simulation when the total number of iterations is smaller than 100. Note that the file extension (the suffix) is automatic and can be left out.
+If you would like to keep copies of previously saved restart files, this is possible by setting
 
-To restart a simulation the `RESTART_SOL` flag should be set to `YES` in the configuration file. If performing an unsteady restart the `RESTART_ITER` needs to be set to the iteration number which you want to restart from. For instance if we want to restart at iteration 100 and run the unsteady solver with 2nd-order dual time stepping method, we will need to specify `RESTART_ITER = 100` and have the restart files `solution_flow_00098.dat` and `solution_flow_00099.dat`.
+`WRT_RESTART_OVERWRITE= NO`
+
+This option is available only for steady simulations. In unsteady simulations, the number of timesteps is appended to the filename automatically. Additional to the regular restart file, a restart file with the current iteration appended to the filename will be written every `OUTPUT_WRT_FREQ` iterations.
+
+## Starting a simulation from a saved solution
+
+When restarting the primal or starting an adjoint, the filename given by the keyword `SOLUTION_FILENAME` will be used. In order to restart the primal or start the run of an adjoint simulation, the user must therefore first change the name of the saved file, e.g. `restart_flow.dat`  (or `restart_flow.csv` if ASCII format) to the filename `solution_flow.dat` (or `solution_flow.csv`) in the execution directory. It is important to note that the adjoint solver will create a different adjoint restart file for each objective function, e.g. `restart_adj_cd.dat`.
+To restart a simulation the `RESTART_SOL` flag should be set to `YES` in the configuration file. 
+
+`RESTART_SOL= YES` \
+`SOLUTION_FILENAME= solution_flow`
+
+If performing an unsteady restart the `RESTART_ITER` needs to be set to the iteration number which you want to restart from. For instance if we want to restart at iteration 100 and run the unsteady solver with 2nd-order dual time stepping method, we will need to specify `RESTART_ITER = 100` and have the restart files `solution_flow_00098.dat` and `solution_flow_00099.dat`.
+ 
 
+| Option value | Default value | Description | Data type |
+|---|---|---|---|
+| `RESTART_FILENAME` | restart.dat | filename under which the restart file will be saved | string |
+| `OUTPUT_WRT_FREQ` | 250 | the frequency with which the output files will be saved | integer |
+| `WRT_RESTART_OVERWRITE` | YES | overwrite the restart file or (additionally) append the iteration number to the filename | boolean |
+| `RESTART_SOL` | solution | restart from file or from initial conditions | boolean |
+| `SOLUTION_FILENAME` | solution.dat | filename that will be used to restart the primal or start the adjoint computation | string |
+| `RESTART_ITER` | 1 | iteration number that an unsteady simulation will restart from | integer |

_docs_v7/Theory.md

@@ -12,6 +12,7 @@ This page contains a very brief summary of the different governing equation sets
 - [Incompressible Navier-Stokes](#incompressible-navier-stokes)
 - [Incompressible Euler](#incompressible-euler)
 - [Turbulence Modeling](#turbulence-modeling)
+- [Species Transport](#species-transport)
 - [Elasticity](#elasticity)
 - [Heat Conduction](#heat-conduction)
 
@@ -169,6 +170,34 @@ Within the turbulence solvers, we discretize the equations in space using a fini
 
 ---
 
+# Species Transport #
+
+Compatible with `NAVIER_STOKES`, `RANS`, `INC_NAVIER_STOKES`, `INC_RANS`
+
+$$ \mathcal{R}(U) = \frac{\partial U}{\partial t} + \nabla \cdot \bar{F}^{c}(U) - \nabla \cdot \bar{F}^{v}(U,\nabla U)  - S = 0 $$
+
+where the conservative variables (which are also the working variables) are given by 
+
+$$U=\left\lbrace \rho Y_1, ..., \rho Y_{N-1} \right\rbrace ^\mathsf{T}$$
+
+with $$Y_i$$ $$[-]$$ being the species mass fraction. And 
+
+$$\sum_{i=0}^N Y_i = 1 \Rightarrow Y_N = 1 - \sum_{i=0}^{N-1} Y_i$$
+  
+$$S$$ is a generic source term, and the convective and viscous fluxes are
+
+$$\bar{F}^{c}(V) = \left\{\begin{array}{c} \rho Y_1 \bar{v} \\ ... \\\rho Y_{N-1} \, \bar{v} \end{array} \right\}$$
+
+$$\bar{F}^{v}(V,\nabla V) = \left\{\begin{array}{c} D \nabla Y_{1} \\ ... \\  D \nabla Y_{N-1} \end{array} \right\} $$
+
+with $$D$$ $$[m^2/s]$$ being the mass diffusion. 
+
+$$D = D_{lam} + \frac{\mu_T}{Sc_{T}}$$
+
+where $$\mu_T$$ is the eddy viscosity and $$Sc_{T}$$ $$[-]$$ the turbulent Schmidt number.
+
+---
+
 # Elasticity #
 
 | Solver | Version | 

_tutorials/design_features/Inviscid_3D_Constrained_ONERAM6/Inviscid_3D_Constrained_ONERAM6.md

@@ -101,7 +101,7 @@ FFD_CONTINUITY= 2ND_DERIVATIVE
 
 As the current implementation requires each FFD box to be a quadrilaterally-faced hexahedron (6 faces, 12 edges, 8 vertices), we can simply specify the 8 corner points of the box and the polynomial degree we would like to represent along each coordinate direction (x,y,z) in order to create the complete lattice of control points. It is convenient to think of the FFD box as a small structured mesh block with (i,j,k) indices for the control points, and note that the number of control points in each direction is the specified polynomial degree plus one. 
 
-In the example above, we are creating a box with control point dimensions 11, 9, and 2 in the x-, y-, and z-directions, respectively, for a total of 198 available control points. In the `FFD_DEFINITION` option, we give a name to the box ("WING"), and then list out the x, y, and z coordinates of each corner point. The order is important, and you can use the example above to match the convention. The degree is then specified in the `FFD_DEGREE` option. A view of the box with the control points numbered is in Figure (3). Note that the numbering in the figure is 1-based just for visualization, but within SU2, the control points have 0-based indexing. For example, the (1,1,1) control point in the figure is control point (0,0,0) within SU2. This is critical for specifying the design variables in the config file.
+In the example above, we are creating a box with control point dimensions 11, 9, and 2 in the x-, y-, and z-directions, respectively, for a total of 198 available control points. In the `FFD_DEFINITION` option, we give a name to the box ("WING"), and then list out the x, y, and z coordinates of each corner point. The order is important, and you can use the example above to match the convention. Alternatively, [this tutorial](/tutorials/Species_Transport/) contains more in-depth information on how the numbering should be done. The degree is then specified in the `FFD_DEGREE` option. A view of the box with the control points numbered is in Figure (3). Note that the numbering in the figure is 1-based just for visualization, but within SU2, the control points have 0-based indexing. For example, the (1,1,1) control point in the figure is control point (0,0,0) within SU2. This is critical for specifying the design variables in the config file.
 
 ![Opt. ONERA FFD](../../tutorials_files/design_features/Inviscid_3D_Constrained_ONERAM6/images/onera_ffd_points.png)
 Figure (3): View of the control point identifying indices, which increase in value along the positive coordinate directions. Note that the numbering here is 1-based just for visualization, but within SU2, the control points have 0-based indexing.

_tutorials/design_features/Multi_Objective_Shape_Design/Multi_Objective_Shape_Design.md

@@ -71,7 +71,7 @@ OBJECTIVE_WEIGHT= -1.0E-7,1.0
 ```
 These options define a weighted sum: -1.0E-7 x (SURFACE_TOTAL_PRESSURE at the outlet) + (DRAG on the lower surface). The OBJECTIVE_FUNCTION and OBJECTIVE_WEIGHT options are set automatically during the optimization process, and are used for the calculation of the gradient. If we were starting this problem from scratch, at this point we would run the gradient method desired, in order to confirm that the gradients are being calculated as expected. In this tutorial, the discrete adjoint is used by default. When multiple objectives are specified as shown, a single adjoint solution for a 'combo' objective will be calculated, representing the gradient for the weighted sum. The upside of this is that it reduces the number of adjoint solutions required, with the downside that the contributions of different functionals to the gradient value will not be known.
 
-Next the FFD box is defined in order to provide the design variables. The mesh is provided with the FFD box information already included, however when starting from scratch a preprocessing step using SU2_MSH is required. For further detail on FFD, see the [Constrainted Optimal Shape Design Tutorial](/tutorials/Inviscid_3D_Constrained_ONERAM6/).
+Next the FFD box is defined in order to provide the design variables. The mesh is provided with the FFD box information already included, however when starting from scratch a preprocessing step using SU2_MSH is required. For further detail on FFD, see this [Unconstrained species transport tutorial](/tutorials/Species_Transport/) or [Constrainted Optimal Shape Design Tutorial](/tutorials/Inviscid_3D_Constrained_ONERAM6/).
 ```
 % -------------------- FREE-FORM DEFORMATION PARAMETERS -----------------------%
 %