+
+Figure (1): A MATLAB simulation of a one period advection (red) of an initial value discontinuity (black) using the Lax-Wendroff method.
+
+SU2 uses **slope limiters** to avoid these oscillations by damping second-order terms near shocks and other regions with sharp gradients. The second-order reconstruction is kept where the solution is smooth. This preserves solution accuracy in regions with smooth gradients and helps obtain physical results and numerical stability in regions close to the shock.
+
+Before mathematically describing the form of the limiters implemented in SU2, it is useful to briefly understand two concepts. These include **Total Variation** and **Godunov's Theorem**.
+
+### Total Variation and Total Variation Diminishing
+We can first introduce the concept of **total variation** (TV) which is a measure of how oscillatory a solution is. In a discrete one dimensional setting, TV can be calculated as the following:
+
+$$ TV(u^n) = \sum_j |u^n_{j+1} - u^n_j| $$
+
+
+
+Figure (2): A numerical scheme resulting in both high and low TV.
+
+A scheme can be said to be **total variation diminishing** (TVD) if
+
+$$ TV(u^{n+1}) \leq TV(u^n) $$
+
+where for every successive timestep $$n$$, the total variation of the solution does not increase.
+
+A favorable property of TVD schemes is that they are **monotonicity preserving**. This means they do not introduce new extrema into the solution and local minimum (maximum) are non-decreasing (increasing) in time. These are both desirable qualities for correctly resolving a shock and ensuring the solution is physical.
+
+### Godunov's Theorem
+The question of "How accurate can a TVD scheme be?" is still unanswered. For this, we turn to [Godunov's Theorem](https://en.wikipedia.org/wiki/Godunov%27s_theorem).
+
+**Godunov's Theorem**:
+1. A linear scheme is monotone if and only if it is total variation diminishing.
+2. Linear total variation diminishing schemes are at most first-order accurate.
+
+The first statement is simple, stating that for linear schemes, the characteristic of being monotone and TVD is equivalent. The second statement is more interesting. It states that if we want to construct a linear TVD (monotone) scheme, the best we can be possibly hope for is first-order accuracy.
+
+Recall that the original motivation for a slope limiter was to prevent the formation of oscillations in the solution. In the section above, we noted that TVD schemes are monotonicity preserving (a favorable property in resolving a shock). However, through Godunov's theorem, we note that if we also want high-order accuracy, **our TVD discretization MUST be nonlinear**
+
+The inclusion of a slope limiter into a TVD scheme accomplishes this idea.
+
+
+## Available Limiter Options
+
+The field `SLOPE_LIMITER_FLOW` in the `.cfg` file specifies which limiter to use. Note that this option is only used if `MUSCL_FLOW = YES` (which specifies to use a second-order method).
+The [Laminar Cylinder](https://su2code.github.io/tutorials/Laminar_Cylinder/) shows an example of this.
+The [Turbulent Flat Plate example](https://su2code.github.io/tutorials/Turbulent_Flat_Plate/) sets `SLOPE_LIMITER_TURB`, which is used for the turbulence equations (if `MUSCL_TURB = YES`), rather than for the flow equations.
+More possible applications of limiters are listed below.
+
+
+### Slope Limiter Fields
+
+| Configuration Field | Description | Notes |
+| --- | --- | --- |
+| `SLOPE_LIMITER_FLOW` | Flow equations | Need `MUSCL_FLOW = YES` |
+| `SLOPE_LIMITER_TURB` | Turbulence equations | Need `MUSCL_TURB = YES` |
+| `SLOPE_LIMITER_SPECIES` | Species evolution equations | Need `MUSCL_SPECIES = YES` |
+| `SLOPE_LIMITER_ADJFLOW` | Adjoint flow equations | Need `MUSCL_ADJFLOW = YES` |
+| `SLOPE_LIMITER_ADJTURB` | Adjoint turbulence equations | Need `MUSCL_ADJTURB = YES` |
+
+
+The `SLOPE_LIMITER_` options above may each be changed to use different limiters, which are listed and explained below.
+
+**Note:** the Discontinuous-Galerkin methods (DG) / Higher-order methods (HOM) do not use limiters.
+
+
+
+### Available Limiters
+
+| Type | Description | Notes |
+| --- | --- | --- |
+| `NONE` | No limiter | |
+| `BARTH_JESPERSEN` | Barth-Jespersen | This limiter is a smooth version of the commonly seen Barth-Jespersen limiter seen in the literature |
+| `VENKATAKRISHNAN` | Venkatakrishnan | |
+| `VENKATAKRISHNAN_WANG` | Venkatakrishnan-Wang | |
+| `NISHIKAWA_R3` | Nishikawa-R3 | |
+| `NISHIKAWA_R4` | Nishikawa-R4 | |
+| `NISHIKAWA_R5` | Nishikawa-R5 | |
+| `SHARP_EDGES` | Venkatakrishnan with sharp-edge modification | This limiter should not be used for flow solvers |
+| `WALL_DISTANCE` | Venkatakrishnan with wall distance modification | This limiter should not be used for flow solvers |
+| `VAN_ALBADA_EDGE` | Van Albada (edge formulation) | This limiter is only implemented for flow solvers and does not output limiter values when using the VOLUME_OUTPUT option |
+
+The default limiter is `VENKATAKRISHNAN`.
+
+### Limiter Parameters and Further Details
+
+The `VENKAT_LIMITER_COEFF` parameter is generally a small constant, defaulting to $$0.05$$, but its specific definition depends on the limiter being used.
+
+For the `VENKATAKRISHNAN`, `SHARP_EDGES`, and `WALL_DISTANCE` limiters, the `VENKAT_LIMITER_COEFF` parameter refers to $$K$$ in $$\epsilon^2=\left(K\bar{\Delta} \right)^3$$, where $$\bar{\Delta}$$ is an average grid size (this is hardcoded as 1m and thus all tuning is via $$K$$). For NISHIKAWA_Rp limiters, $$\epsilon^p=\left(K\bar{\Delta} \right)^{p+1}$$ (p = 3, 4 or 5).
+The $$K$$ parameter defines a threshold, below which oscillations are not damped by the limiter, as described by [Venkatakrishnan](https://doi.org/10.1006/jcph.1995.1084).
+Thus, a large value will approach the case of using no limiter with undamped oscillations, while too small of a value will slow the convergence and add extra diffusion.
+The SU2 implementation of the `BARTH_JESPERSEN` limiter actually uses `VENKATAKRISHNAN` with $$K=0$$.
+**Note:** the value of `VENKAT_LIMITER_COEFF` depends on both the mesh and the flow variable and thus should be reduced if the mesh is refined.
+
+When using the `VENKATAKRISHNAN_WANG` limiter, `VENKAT_LIMITER_COEFF` is instead $$\varepsilon '$$ in $$\varepsilon = \varepsilon ' (q_{max} - q_{min})$$, where $$q_{min}$$ and $$q_{max}$$ are the respective *global* minimum and maximum of the field variable being limited.
+This global operation incurs extra time costs due to communication between MPI ranks.
+The original work by [Wang](https://doi.org/10.2514/6.1996-2091) suggests using `VENKAT_LIMITER_COEFF` in the range of $$[0.01, 0.20]$$, where again larger values approach the case of using no limiter.
+**Note:** unlike the aforementioned `VENKATAKRISHNAN` limiter and NISHIKAWA_Rp limiter, the `VENKATAKRISHNAN_WANG` limiter does not depend directly on the mesh size and can thus be used without non-dimensionalization. If the `VENKATAKRISHNAN` limiter is used outside of non-dimensional mode, the fields with larger values (pressure and temperature) will generally be limited more aggressively than velocity.
+
+
+The `NONE`, `BARTH_JESPERSEN`, `VENKATAKRISHNAN`, `VENKATAKRISHNAN_WANG`, and NISHIKAWA_Rp limiter options all have no **geometric modifier**.
+A geometric modifier increases limiting near walls or sharp edges. This is done by multiplying the limiter value by a **geometric factor**.
+
+For both the `SHARP_EDGES` and `WALL_DISTANCE` limiters, the influence of the geometric modifier is controlled with `ADJ_SHARP_LIMITER_COEFF` which defaults to 3.0.
+**Note:** these limiters should not be used for flow solvers, as they only apply to the continuous adjoint solvers.
+
+Increasing this parameter will decrease the value of the limiter and thus make the field more diffusive and less oscillatory near the feature (sharp edge or wall).
+
+In the `SHARP_EDGES` limiter, the qualification of what makes an edge "sharp" is described by the parameter `REF_SHARP_EDGES` (defaults to 3.0). Increasing this will make more edges qualify as "sharp".
+Other than the addition of this geometric factor, these limiters are the same as the `VENKATAKRISHNAN` limiter and should also use `VENKAT_LIMITER_COEFF` (given by $$K$$ below).
+
+Specifically, given the distance to the feature, $$d_{\text{feature}}$$, an intermediate measure of the distance, $$d$$, is calculated. The parameter $$c$$ is set by `ADJ_SHARP_LIMITER_COEFF`.
+
+
+$$ d(d_{\text{feature}}; c, K) = \frac{d_{\text{feature}}} { (c \cdot K \bar{\Delta}) } - 1$$
+
+Then, the geometric factor is given by
+
+$$ \gamma (d) = \frac{1}{2} (1+d+\sin(\pi \cdot d)/ \pi) $$
+
+Note that the geometric factor is nonnegative and nondecreasing in $$d_{feature}$$.
+
+
+After the number of iterations given by `LIMITER_ITER` (default $$999999$$), the value of the limiter will be frozen.
+
+
+The option `FROZEN_LIMITER_DISC` tells whether the slope limiter is to be frozen in the discrete adjoint formulation (default is `NO`).
+
+
+## Empirical comparison of limiters on a periodic advective domain
+An example problem of the linear advection problem against four unique wave-forms was simulated in MATLAB to illustrate differences between the primary limiters in SU2. The wave forms contain both smooth and discontinuous initial conditions and are advected for a single period with a CFL of $$\sigma = 0.8$$. The domain is discretized with $$N = 200$$ cells. The Lax-Wendroff scheme was used as a comparative case:
+
+$$ u_j^{n+1} = u_j^{n} - \sigma (u_j^{n} - u_{j-1}^{n}) - \frac{1}{2}\sigma(1-\sigma) \left[ \phi_{j+\frac{1}{2}}(u_{j+1}^{n} - u_j^{n}) - \phi_{j-\frac{1}{2}}(u_{j}^{n} - u_{j-1}^{n}) \right] $$
+
+where $$\phi_{j+\frac{1}{2}}$$ is the scalar value of the limiter at the interface of cell $$u_j$$ and $$u_{j+1}$$.
+
+
+
+Figure (3): A MATLAB simulation of one period advection (red) of an initial condition (black) using various schemes, with and without limiters.
+
+From the above example we note:
+* The **Lax-Wendroff** scheme produces oscillations near sudden gradients due to dispersion errors. From Godunov's theorem this is expected as the scheme is second-order accurate and does not utilize a limiter.
+* The **Barth-Jespersen** limiter performs well for most of the waveforms. However, the Barth-Jespersen limtier is known to be compressive and will turn smooth waves into square waves. This is best seen with the value discontinuity on the very left.
+* The **Van-Albada** limiter also performs well. It is slightly more diffusive than Barth-Jespersen but has robust convergence properties.
+* The **Venkatakrishnan** limiter is similar to the Barth-Jespersen and has significantly improved convergence properties. However, it is more diffusive and does require a user-specified parameter $$K$$ that is flow dependent.
diff --git a/_docs_v7/Solver-Setup.md b/_docs_v7/Solver-Setup.md
index baf046a3..65a0c996 100644
--- a/_docs_v7/Solver-Setup.md
+++ b/_docs_v7/Solver-Setup.md
@@ -31,6 +31,8 @@ SU2 is capable of dealing with different kinds of physical problems. The kind of
|`EULER` | **Euler's equation** |Finite-Volume method |
|`NAVIER_STOKES` | **Navier-Stokes' equation** | Finite-Volume method |
|`RANS` | **Reynolds-averaged Navier-Stokes' equation** | Finite-Volume method|
+|`NEMO_EULER` | **Thermochemical Nonequilibrium Euler's equation** |Finite-Volume method |
+|`NEMO_NAVIER_STOKES` | **Thermochemical Nonequilibrium Navier-Stokes' equation** | Finite-Volume method |
|`INC_EULER` | **Incompressible Euler's equation** | Finite-Volume method |
|`INC_NAVIER_STOKES` | **Incompressible Navier-Stokes' equation** | Finite-Volume method|
|`INC_RANS` | **Incompressible Reynolds-averaged Navier-Stokes' equation** | Finite-Volume method|
diff --git a/_docs_v7/Streamwise-Periodicity.md b/_docs_v7/Streamwise-Periodicity.md
new file mode 100644
index 00000000..e239e87b
--- /dev/null
+++ b/_docs_v7/Streamwise-Periodicity.md
@@ -0,0 +1,107 @@
+---
+title: Streamwise Periodicity
+permalink: /docs_v7/Streamwise-Periodicity/
+---
+
+| Solver | Version |
+| --- | --- |
+| `INC_NAVIER_STOKES`, `INC_RANS` | 7.0.0 |
+
+
+This page contains an overview of the theory behind streamwise periodic flow and builds upon [Incompressible Navier-Stokes](/docs_v7/Theory/#incompressible-navier-stokes). A tutorial for [Streamwise Periodic Flow](/tutorials/Inc_Streamwise_Periodic/) is available.
+
+---
+
+- [Limitations](#limitations)
+- [Introduction](#introduction)
+- [Pressure and Velocity Periodiciy](#pandv-periodiciy)
+ - [Massflow prescription](#massflow)
+- [Temperature Periodiciy](#T-periodiciy)
+ - [Fake temperature periodicity via outlet heat sink](#fake-temperature-periodicity-via-outlet-heat-sink)
+- [References](#references)
+
+---
+
+## Limitations
+- can only be used with the incompressible solver, namely `INC_NAVIER_STOKES` and `INC_RANS`
+- temperature dependent fluid properties (e.g. $$c_p, \mu_{lam}$$) cannot be used with real streamwise periodic flow
+
+## Introduction
+
+A flow can be modeled as streamwise periodic if the following statements hold true:
+
+$$\begin{align}
+\bar{v}\left( \bar{x} \right) &= \bar{v} \left( \bar{x}+\bar{t} \right), \\
+p\left( \bar{x} \right) &= p \left( \bar{x}+\bar{t} \right) + \Delta p_0, \\
+T\left( \bar{x} \right) &= T \left( \bar{x}+\bar{t} \right) - \Delta T_0.
+\end{align}$$
+
+With $$\bar{t}$$ being the translation vector between periodic interfaces and $$\Delta p_0, \Delta T_0$$ the constant pressure or temperature drop between the periodic interfaces.
+
+## Pressure and Velocity Periodicity
+
+The continuous relation between physical pressure $$p$$ and periodic/reduced pressure $$\tilde{p}$$ in space is:
+
+$$p\left( \bar{x} \right) = \tilde p \left( \bar{x} \right) - \frac{\Delta p_0}{\left\lVert\bar{t}\right\rVert_2}t_p, \quad t_p =\frac{1}{\left\lVert\bar{t}\right\rVert_2} \left| \left( \bar{x} - \bar{x}^\star \right) \cdot \bar{t} \right|.$$
+
+This separation into two parts can be interpreted as a "constant" and a "linear" (along the domain) contribution.
+This relation is used to compute the recovered pressure for postprocessing.
+Inserting this pressure formulation into the momentum equation of the incompressible Navier-Stokes equation (see [here](/docs_v7/Theory/#incompressible-navier-stokes)) results in:
+
+$$\frac{\partial \bar{v}}{\partial t} + \nabla\cdot\left( \rho \bar{v} \otimes \bar{v} + \bar{\bar{I}}\tilde{p} - \bar{\bar \tau} \right) - \frac{\Delta p_0}{\left\lVert\bar{t}\right\rVert_2^2}\bar{t} = 0,$$
+
+where two things changed:
+1. Working variable of the pressure $$p$$ changed to the periodic pressure $$\tilde{p}$$.
+2. A constant source term is added to the formulation of the momentum equation.
+
+The source term is now the force that drives the flow and scales with the prescribed pressure drop $$\Delta p_0$$.
+
+This substitution of the pressure variable has to be done in every place it appears. For pressure there is nothing further to do e.g. for the boundary conditions, which will be different for the derivation of periodic temperature.
+
+### Massflow prescription
+
+In applications often the massflux $$\dot{m}_0^2$$ is known and the pressure drop is the observable. If a massflow is prescribed the pressure drop $$\Delta p_0$$ in the source term is adapted with each iteration to match the current massflow $$\dot{m}^2$$ with the prescribed massflow:
+
+
+$$\Delta p_0^{n+1} - \Delta p_0^{n} = \Delta \left( \Delta p_0 \right) = \frac{\frac{1}{2} \rho \left( \dot{m}_0^2 - \dot{m}^2 \right)}{\left( \rho A \right)^2}.$$
+
+$$\rho$$ is the density and $$A$$ the flowed through inlet Area. For the pressure drop update a relaxation factor $$\phi$$ is used:
+
+$$\Delta p_0^{n+1} = \Delta p_0^{n} + \phi \Delta \left( \Delta p_0 \right).$$
+
+## Temperature Periodicity
+
+The here presented approach for periodicity in temperature is only possible if only heatflux or symmetry boundary conditions are used, isothermal walls in particular are not allowed. In that case use the [method described below](#fake-temperature-periodicity-via-outlet-heat-sink) is used:
+
+Similar to the pressure term for the momentum equation the Temperature can be split in a periodic and a linear part:
+
+$$T\left( \bar{x} \right) = \tilde T \left( \bar{x} \right) + \frac{\Delta T_0}{\left\lVert\bar{t}\right\rVert_2}t_p, \quad t_p =\frac{1}{\left\lVert\bar{t}\right\rVert_2} \left| \left( \bar{x} - \bar{x}^\star \right) \cdot \bar{t} \right|$$
+
+Just as with the pressure term, this relation is used to compute the recovered temperature for postprocessing.
+Inserting the temperature formulation into the energy equation results in:
+
+$$\frac{\partial \left( \rho c_p \tilde{T} \right)}{\partial t} + \nabla\cdot\left( \rho c_p \tilde{T} \bar{v} - \kappa\nabla \tilde{T} \right) + \frac{Q \rho }{ \dot{m}\left\lVert\bar{t}\right\rVert_2^2} \left[ \bar{t} \cdot \bar{v} \right] = 0$$
+
+With $$Q$$ being the integrated heatflux across the domain boundaries in Watts. In contrast to the derivation for pressure periodicity in the momentum equations the boundary conditions have to adapted for the energy equation. The heatflux (Neumann) wall contribution for the energy equation becomes:
+
+$$- \int_{\partial\Omega} \left( \kappa\nabla T \right) \cdot \bar{n} dS + \int_{\partial\Omega} \kappa\frac{Q}{\dot{m} c_p \left\lVert\bar{t}\right\rVert_2^2} \left[ \bar{t} \cdot \bar{n} \right] dS = 0 $$
+
+### Temperature periodicity via outlet heat sink
+
+In cases where the above requirements cannot be held (e.g. isothermal walls, CHT interfaces) a simple massflow averaged outlet heat sink is implemented. In these cases pressure is still periodic but temperature is solved in its non-periodic form. Energy is extracted from the domain just at the outlet such that the temperature profile via the periodic interface is approximately retained. This of course is a major simplification that enables the use of an approximated temperature profile over the periodic interface. Solution interpretation, especially if it involves surface temperature integrals near the periodic faces, should be done with the necessary care.
+
+The residual contributions are in twofold. Firstly an either user provided or computed heat is extracted at the outlet with massflow averaged weighting which proved to be better than area averaged weighting:
+
+$$Res -= \frac{\dot m_{local}}{\dot m_{global}} Q_{integrated}$$
+
+The second term is adaptive and scales with the difference between the initial temperature `INC_TEMPERATURE_INIT` and the actual area averaged temperature on the inlet:
+
+$$Res += \frac{1}{2} |\dot m| c_p \left( T_{inlet} - \frac{T_{init}}{T_{ref}} \right)$$
+
+This allows to set the general temperature level in the domain and thereby also allows for the use of temperature material parameters, or isothermal walls and CHT interfaces.
+
+## References
+
+$$^1$$ S.V. Patankar, C.H. Liu, and E.M. Sparrow. Fully developed flow and heat transfer in ducts having streamwise-periodic variations of cross-sectional area. *Journal of Heat Transfer*, 99(2):180–186, 1977. doi: [https://doi.org/10.1115/1.3450666](https://doi.org/10.1115/1.3450666)
+
+$$^2$$ Steven B. Beale. On the implementation of stream-wise periodic boundary conditions. In *ASME 2005 Summer Heat Transfer Conference collocated with the ASME 2005 Pacific Rim Technical Conference and Exhibition on Integration and Packaging of MEMS, NEMS, and ElectronicSystems*, pages 771–777. American Society of Mechanical Engineers, 2005. doi: [https://doi.org/10.1115/HT2005-72271](https://doi.org/10.1115/HT2005-72271)
\ No newline at end of file
diff --git a/_docs_v7/Style-Guide.md b/_docs_v7/Style-Guide.md
index 11f02921..fe2666f5 100644
--- a/_docs_v7/Style-Guide.md
+++ b/_docs_v7/Style-Guide.md
@@ -3,101 +3,71 @@ title: Style Guide
permalink: /docs_v7/Style-Guide/
---
-SU2 is released under an open source license to facilitate its widespread use and development in the scientific computing community. To support uniformity and consistency in the style of the source code, a C++ style guide has been included on this page, and it is strongly encouraged that outside developers adhere to the guidelines dictated in the style guide to maintain readability of the source.
+To support uniformity and consistency in the style of the source code, a C++ style guide has been included on this page, and it is strongly encouraged that outside developers adhere to the guidelines dictated in the style guide to maintain readability of the code.
Any contributions from the scientific community at-large are encouraged and welcomed. Feel free to contact the development team at any time.
-This document describes the conventions that will be used when implementing new features in SU2. This includes allowed syntactic and semantic language features, filename conventions, indentation conventions and more. The consistency is fundamental, it is very important that any programmer be able to look at another part of the code and quickly understand it, the uniformity in the style is a key issue. Some of the ideas expressed in this document comes from the Google C++ Style Guide (revision 3.188).
+This document describes the conventions that will be used when implementing new features in SU2. Consistency is fundamental, it is very important that any programmer be able to look at another part of the code and quickly understand it. Some of the ideas expressed in this document come from the Google C++ Style Guide, others from the [C++ Core Guidelines](https://github.com/su2code/SU2/issues/1218).
## C++ style guide
+Below is summary of the rules we try to follow in SU2. **Older parts of SU2 are not good examples of these rules.**
+
+**Duplicating code is absolutely not allowed.**
+
### Version numbering
-Each code of the SU2 suite must have a release number following the rule Major.Patch, where the Major number is increased each time a new major update is performed and the Patch number is increased each time new features are added. The configuration file also has a number following the rule Major.Patch, where Major correspond with the SU2_CFD major version and Patch is increased with new changes.
+The SU2 suite has a major release number followed the rule minor.path, where the minor number is increased each time a significant update is performed and the patch number is increased in maintenance releases.
+Patch releases cannot break backward compatibility.
### Standard conformance, and formatting
-Source code must comply with the C++ ISO/ANSI standard. with respect to the formatting some recommendation can be made:
-- Each line of text in your code should be at most 80 characters long.
-- Non-ASCII characters should be rare, and must use UTF-8 formatting.
-- Use only spaces (default indent is 2 spaces). You can set your editor to emit spaces when you hit the tab key.
-- Sections in public, protected and private order, each indented one space.
-- The hash mark that starts a preprocessor directive should always be at the beginning of the line.
-- When you have a boolean expression that is longer than the standard line length, be consistent in how you break up the lines.
+SU2 is written for C++11, the formatting rules are defined in a `clang-format` file located in the root of the repository.
+**New files must follow the formatting rules exactly.**
+
+SU2 uses pre-commit to enforce a consistent formatting. To use, [install pre-commit](https://pre-commit.com/#install) and run `pre-commit install` at the root of the project. You can now force the formatting on all files with `pre-commit run -a`. This will also run all pre-commit hooks before each commit, preventing dirty commits in the repository.
### Files, functions, and variables
-Here some basic recommendation are made for creating files, functions, and variables:
+Basic recommendations for creating files, functions, and variables:
- C++ filenames must have extension .cpp.
- C++ header filenames must have extension .hpp. In general, every .cpp file should have an associated .hpp file.
-- C++ inline filenames must have extension .inl. Define functions inline only when they are small, say, 10 lines or less.
-- All subprograms (subroutines of functions) must be contained in a class. Each parent class must be contained in a file with the same name as the class (plus extension ’.cpp’, and ’.hpp’). This implies that there can only be one parent class per file.
-- When defining a function, parameter order is: inputs, then outputs.
+- When defining a function, the parameter order is: inputs, then outputs.
- Order of includes. Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries', your project's.
-- Prefer small and focused functions.
+- Write small and focused functions.
- Use overloaded functions (including constructors) only if a reader looking at a call site can get a good idea of what is happening without having to first figure out exactly which overload is being called.
- Local variables. Place a function's variables in the narrowest scope possible, and initialize variables in the declaration.
-- Static or global variables of class type are forbidden: they cause hard-to-find bugs due to indeterminate order of construction and destruction.
-- In the initialization, use 0 for integers, 0.0 for reals, NULL for pointers, and '\0' for chars.
-
-### Classes
-
-The classes are the key element of the object oriented programming, here some basic rules are specified.
-In general, constructors should merely set member variables to their initial values. Any complex initialization should go in an explicit Init() method.
-- You must define a default constructor, and destructor.
-- Use the C++ keyword explicit for constructors with one argument.
-- Use a struct only for passive objects that carry data; everything else is a class.
-- Do not overload operators except in rare, special circumstances.
-- Use the specified order of declarations within a class: public: before private:, methods before data members (variables), etc.
-
-### Syntactic and semantic requirements
-
-In this section you can find some basic rules for programming:
-- All allocated memory must be deallocated at program termination.
-- Read or write operations outside an allocated memory block are not allowed.
-- Read or write outside index bounds in arrays or character variables are not allowed.
-- No uninitialized/undefined values may be used in a way that could affect the execution.
-- Local variables that are not used must be removed.
-- Pointer variables must be initialized with NULL unless they are obviously initialized in some other way before they are used.
-- Indentation will be two steps for each nested block-level.
-- In the header file, at the beginning of each program unit (class, subroutine or function) there must be a comment header describing the purpose of this code. The doxygen format should be used.
-- When possible, it is better to use #DEFINE with a physical meaning to simplify the code.
-- The code must be compiled using doxygen to be sure that there is no warning in the commenting format.
-- When describing a function the following tag must be used: \brie_, \para_\[in\], \para_\[out\], \retur_, \overload.
-- Static or global variables of class type are forbidden: they cause hard-to-find bugs due to indeterminate order of construction and destructionUse 0 for integers, 0.0 for reals, NULL for pointers, and '\0' for chars.
-- All parameters passed by reference must be labeled const. We strongly recommend that you use const whenever it makes sense to do so.
-- In the code short, int, and the unsigned version of both must be used case depending.
-- Code should be 64-bit and 32-bit friendly. Bear in mind problems of printing, comparisons, and structure alignment
+- Static or global variables of class type are forbidden.
+- Make abundant use of `const`.
+- Always use `su2double` for floating point variables, do not use `double`, `float`, or `auto`.
+- Use `auto` or `auto&` or `auto*` for other types of variables.
-### Naming
-
-The most important consistency rules are those that govern naming. The style of a name immediately informs us what sort of thing the named entity is: a type, a variable, a function, a constant, a macro, etc., without requiring us to search for the declaration of that entity.
-
-The following naming conventions for variables must be used:
-- Geometry: Normal, Area (2D, and 3D), Volume (2D, and 3D), Coord, Position. Solution: Solution, Residual, Jacobian.
-- Function names, variable names, and filenames should be descriptive; eschew abbreviation. Types and variables should be nouns, while functions should be "command" verbs.
-- Elementary functions that set or get the value of a variable (e.g. Number) must be called as GetNumber(), or GetNumber(). Function names start with a capital letter and have a capital letter for each new word, with no underscores.
-- Variable names are all lowercase, with underscores between words.
-- The name for all the classes must start with the capital "C" letter, followed by the name of the class (capitalizing the first letter), if the name is composed by several words, all the words must be together, e.g.: CPrimalGrid.
-- All the variables that are defined in a class must be commented using /\*< \brief \________.\*/.
+### Code Documentation
-### Comments
-
-The documentation, and comments must be Doxygen friendly, here I include some basic features:
+Classes and functions must be documented with doxygen:
- Start each file with a copyright notice, followed by a description of the contents of the file.
-- Every class definition should have an accompanying comment that describes what it is for and how it should be used.
-- Declaration comments describe use of the function; comments at the definition of a function describe operation.
-- In general the actual name of the variable should be descriptive enough to give a good idea of what the variable is used for.
+- Every class/function definition must have an accompanying comment that describes what it is for and how it should be used.
+- The code must be compiled using doxygen to be sure that there are no warnings in the commenting format.
+- When describing a function or class the following tags must be used: `\brief`, `\param[in]`, `\param[out]`, `\return`, `\overload`.
+- Do not document the obvious, but rather the expected behavior/usage or the class or function, use `\note` to add details of an algorithm, include links to literature when appropriate.
- In your implementation you should have comments in tricky, non-obvious, interesting, or important parts of your code.
- Pay attention to punctuation, spelling, and grammar; it is easier to read well-written comments than badly written ones.
- Short, and long comments must be in inside of /\*--- (your comment here) ---\*/, and they must be located just before the line to be commented.
- Math comments are welcome and should be in the Latex language.
-### Debugger tools
+### Naming
+
+The consistency boat sailed a long time ago in SU2, the information below is more descriptive than prescriptive.
-- The C++ code must support the following features for debugging:
-- Array index bounds may be checked at runtime.
-- Conformance with C++ may be checked.
-- Use of obsolescent features may be reported as compilation warnings.
-- Unused variables may be reported as compilation warnings.
+The following naming conventions are in use:
+- Function names, variable names, and filenames should be descriptive; eschew abbreviation. Types and variables should be nouns, while functions should be "command" verbs.
+- Elementary functions that set or get the value of a variable (e.g. Number) must be called as SetNumber(), or GetNumber(). Function names start with a capital letter and have a capital letter for each new word, with no underscores.
+- The name for all the classes must start with the capital "C" letter, followed by the `NameOfTheClass` (camel case).
- Iteration: iPoint, jPoint, kPoint, iNode, jNode, kNode, iElem, jElem, kElem, iDim, iVar, iMesh, iEdge.
+
+**Variable names**
+- Acceptable styles are `lowerCamelCase` and `snake_case`.
+- Member variables can be `CamelCase`, or be ended `with_underscore_`.
+- Template parameters are `CamelCase`.
+- Be consistent and follow the existing style if you are modifying or fixing code, do not increase entropy...
+
diff --git a/_docs_v7/Test-Cases.md b/_docs_v7/Test-Cases.md
index 6d138bd3..3063a7f7 100644
--- a/_docs_v7/Test-Cases.md
+++ b/_docs_v7/Test-Cases.md
@@ -14,8 +14,6 @@ The two repositories contain the same directory structure for the test cases, wi
$ git clone https://github.com/su2code/SU2.git
$ git clone https://github.com/su2code/TestCases.git
$ cd SU2/
-$ ./configure
-$ make install
$ cp -R ../TestCases/* ./TestCases/
$ cd ./TestCases/
$ python serial_regression.py
diff --git a/_docs_v7/Theory.md b/_docs_v7/Theory.md
index 3b1ebfd6..c03d7ddc 100644
--- a/_docs_v7/Theory.md
+++ b/_docs_v7/Theory.md
@@ -3,15 +3,19 @@ title: Governing Equations in SU2
permalink: /docs_v7/Theory/
---
-This page contains a very brief summary of the different governing equation sets that are treated in each of the solvers within SU2. The reader will be referred to other references for the full detail of the numerical implementations, but we will also describe the approaches at a high level here.
+This page contains a very brief summary of the different governing equation sets that are treated in each of the solvers within SU2. The reader will be referred to other references in some instances for the full detail of the numerical implementations, but the approaches are also described at a high level here.
---
- [Compressible Navier-Stokes](#compressible-navier-stokes)
- [Compressible Euler](#compressible-euler)
+- [Thermochemical Nonequilibrium Navier-Stokes](#thermochemical-nonequilibrium-navier-stokes)
+- [Thermochemical Nonequilibrium Euler](#thermochemical-nonequilibrium-euler)
- [Incompressible Navier-Stokes](#incompressible-navier-stokes)
- [Incompressible Euler](#incompressible-euler)
- [Turbulence Modeling](#turbulence-modeling)
+- [Species Transport](#species-transport)
+- [Combustion](#combustion)
- [Elasticity](#elasticity)
- [Heat Conduction](#heat-conduction)
@@ -86,6 +90,68 @@ Within the `EULER` solvers, we discretize the equations in space using a finite
---
+# Thermochemical Nonequilibrium Navier-Stokes #
+
+| Solver | Version |
+| --- | --- |
+| `NEMO_NAVIER_STOKES` | 7.0.0 |
+
+
+To simulate hypersonic flows in thermochemical nonequilibrium, SU2-NEMO solves the Navier-Stokes equations for reacting flows, expressed in differential form as
+
+$$ \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 are the working variables and given by
+
+$$U = \left \{ \rho_{1}, \dots, \rho_{n_s}, \rho \bar{v}, \rho E, \rho E_{ve} \right \}^\mathsf{T}$$
+
+$$S$$ is a source term composed of
+
+$$S = \left \{ \dot{w}_{1}, \dots, \dot{w}_{n_s}, \mathbf{0}, 0, \dot{\theta}_{tr:ve} + \sum_s \dot{w}_s E_{ve,s} \right \}^\mathsf{T}$$
+
+and the convective and viscous fluxes are
+
+$$\bar{F}^{c} = \left \{ \begin{array}{c} \rho_{1} \bar{v} \\ \vdots \\ \rho_{n_s} \bar{v} \\ \rho \bar{v} \otimes \bar{v} + \bar{\bar{I}} p \\ \rho E \bar{v} + p \bar{v} \\ \rho E_{ve} \bar{v} \end{array} \right \}$$
+
+and
+
+$$\bar{F}^{v} = \left \{ \begin{array}{c} \\- \bar{J}_1 \\ \vdots \\ - \bar{J}_{n_s} \\ \bar{\bar{\tau}} \\ \bar{\bar{\tau}} \cdot \bar{v} + \sum_k \kappa_k \nabla T_k - \sum_s \bar{J}_s h_s \\ \kappa_{ve} \nabla T_{ve} - \sum_s \bar{J}_s E_{ve} \end{array} \right \}$$
+
+In the equations above, the notation is is largely the same as for the compressible Navier-Stokes equations. An individual mass conservation equation is introduced for each chemical species, indexed by $$s \in \{1,\dots,n_s\}$$. Each conservation equation has an associated source term, $$\dot{w}_{s}$$ associated with the volumetric production rate of species $$s$$ due to chemical reactions occuring within the flow.
+
+Chemical production rates are given by $$ \dot{w}_s = M_s \sum_r (\beta_{s,r} - \alpha_{s,r})(R_{r}^{f} - R_{r}^{b}) $$
+
+where the forward and backward reaction rates are computed using an Arrhenius formulation.
+
+A two-temperature thermodynamic model is employed to model nonequilibrium between the translational-rotational and vibrational-electronic energy modes. As such, a separate energy equation is used to model vibrational-electronic energy transport. A source term associated with the relaxation of vibrational-electronic energy modes is modeled using a Landau-Teller formulation $$ \dot{\theta}_{tr:ve} = \sum _s \rho_s \frac{dE_{ve,s}}{dt} = \sum _s \rho_s \frac{E_{ve*,s} - E_{ve,s}}{\tau_s}. $$
+
+Transport properties for the multi-component mixture are evaluated using a Wilkes-Blottner-Eucken formulation.
+
+---
+
+# Thermochemical Nonequilibrium Euler #
+
+| Solver | Version |
+| --- | --- |
+| `NEMO_EULER` | 7.0.0 |
+
+
+To simulate inviscid hypersonic flows in thermochemical nonequilibrium, SU2-NEMO solves the Euler equations for reacting flows which can be obtained as a simplification of the thermochemical nonequilibrium Navier-Stokes equations in the absence of viscous effects. They can be expressed in differential form as
+
+$$ \mathcal{R}(U) = \frac{\partial U}{\partial t} + \nabla \cdot \bar{F}^{c}(U) - S = 0 $$
+
+where the conservative variables are the working variables and given by
+
+$$U = \left \{ \rho_{1}, \dots, \rho_{n_s}, \rho \bar{v}, \rho E, \rho E_{ve} \right \}^\mathsf{T}$$
+
+$$S$$ is a source term composed of
+
+$$S = \left \{ \dot{w}_{1}, \dots, \dot{w}_{n_s}, \mathbf{0}, 0, \dot{\theta}_{tr:ve} + \sum_s \dot{w}_s E_{ve,s} \right \}^\mathsf{T}$$
+
+and the convective and viscous fluxes are
+
+$$\bar{F}^{c} = \left \{ \begin{array}{c} \rho_{1} \bar{v} \\ \vdots \\ \rho_{n_s} \bar{v} \\ \rho \bar{v} \otimes \bar{v} + \bar{\bar{I}} p \\ \rho E \bar{v} + p \bar{v} \\ \rho E_{ve} \bar{v} \end{array} \right \}$$
+
# Incompressible Navier-Stokes #
| Solver | Version |
@@ -93,7 +159,9 @@ Within the `EULER` solvers, we discretize the equations in space using a finite
| `INC_NAVIER_STOKES`, `INC_RANS` | 7.0.0 |
-SU2 solves the incompressible Navier-Stokes equations in a general form allowing for variable density due to heat transfer through the low-Mach approximation (or incompressible ideal gas formulation). The equations can be expressed in differential form as
+SU2 solves the incompressible Navier-Stokes equations in a general form allowing for variable density due to heat transfer through the low-Mach approximation (or incompressible ideal gas formulation).
+The reader is referred to [this paper](https://arc.aiaa.org/doi/10.2514/1.J058222) for extended details on the incompressible Navier-Stokes and Euler solvers in SU2.
+The equations can be expressed in differential form as
$$ \mathcal{R}(V) = \frac{\partial V}{\partial t} + \nabla \cdot \bar{F}^{c}(V) - \nabla \cdot \bar{F}^{v}(V,\nabla V) - S = 0 $$
@@ -163,9 +231,64 @@ Within the `INC_EULER` solver, we discretize the equations in space using a fini
# Turbulence Modeling #
-The Shear Stress Transport (SST) model of Menter and the Spalart-Allmaras (S-A) model are two of the most common and widely used turbulence models. The S-A and SST standard models, along with several variants, are implemented in SU2. The reader is referred to the [NASA Turbulence Modeling Resource](https://turbmodels.larc.nasa.gov/index.html) (TMR) for the details of each specific model, as the versions in SU2 are implemented according to the well-described formulations found there.
+Available for `RANS`, `INC_RANS`.
+
+SU2 implements several variants of the SST and SA turbulence models, for specifics of the models please see the [NASA Turbulence Modeling Resource](https://turbmodels.larc.nasa.gov/index.html) (TMR).
+For information on how to use turbulence models in SU2 see the [users guide](https://su2code.github.io/docs_v7/Physical-Definition/).
+
+The edge-based finite volume discretization of flow solvers is also used in turbulence solvers. Convective fluxes are evaluated using a scalar upwind scheme (1st or 2nd order).
+
+## Wall functions
+
+Available for `RANS`, `INC_RANS`.
+
+The wall function model of Nichols and Nelson (2004) has been implemented in the compressible and the incompressible solver, for the SA as well as the SST models. For the compressible solver, the wall function model takes into account the frictional heating of the wall according to the Crocco-Busemann relation when the wall boundary conditions is not isothermal. When the wall model is active, the value of the dimensional distance of the first node from the wall can be $$ y^+ > 5$$. When the wall model is not active, $$y^+ < 5 $$ and in addition a fine mesh is necessary close to the wall to resolve the near wall boundary layer.
+
+---
+
+# 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} \rho D \nabla Y_{1} \\ ... \\ \rho D \nabla Y_{N-1} \end{array} \right\} $$
+
+with $$D$$ $$[m^2/s]$$ being the mass diffusion.
+For turbulence modeling, the diffusion coefficient becomes:
+
+$$\rho D = \rho D_{lam} + \frac{\mu_T}{Sc_{T}}$$
+
+where $$\mu_T$$ is the eddy viscosity and $$Sc_{T}$$ $$[-]$$ the turbulent Schmidt number.
+
+---
+
+# Combustion #
+
+| Solver | Version |
+| --- | --- |
+| `INC_NAVIER_STOKES` | 8.0.0 |
+
+Combustion with tabulated chemistry solves the scalar transport equations for total enthalpy $$h_t=h + h_{chem}$$, which is the sum of the sensible enthalpy and the chemical enthalpy. Additionally, it solves a transport equation for the progress variable $$C$$, indicating the progress of combustion. Reaction source terms for the progress variable, as well as necessary thermodynamic quantities like density, temperature, viscosity, heat capacity, etc. are all obtained from a 2D lookup table where the properties are stored as a function of the progress variable and total enthalpy. Note that temperature is now a quantity that is retrieved from the lookup table. These lookup tables are constructed from 1D detailed chemistry simulations, using codes like Cantera, Ember, FlameMaster (RWTH Aachen) or Chem1d (TU Eindhoven) and are also known as flamelets or Flamelet Generated Manifolds (FGM).
+
+The progress variable-enthalpy approach is used to simulate laminar premixed flames. Nonpremixed flames can also be simulated by simply using a lookup table for non-premixed flames. The progress variable then effectively becomes a mixture fraction. Combustion with conjugate heat transfer is also supported in the tabulated chemistry approach.
+Additional transport of (reacting) species can be supported as well. The source terms for these additional species have to be stored in the lookup table. A split-source-term approach is supported, where the source term is assumed to be of the form $$S_{total} = S_{Production} + Y \cdot S_{Consumption}.$$ We store the production and consumption terms in the lookup table and construct the total source term internally. If only a total source term is available, the consumption source term can be set to zero.
+
+At the moment there is no turbulence-chemistry interaction implemented in this approach and the Lewis number is assumed to be $$Le=1$$.
-Within the turbulence solvers, we discretize the equations in space using a finite volume method (FVM) with a standard edge-based data structure on a dual grid with vertex-based schemes. The convective and viscous fluxes are evaluated at the midpoint of an edge.
+For a detailed introduction to flamelet modeling see the work of [van Oijen et al.](https://www.sciencedirect.com/science/article/pii/S0360128515300137)
---
diff --git a/_docs_v7/Thermochemical-Nonequilibrium.md b/_docs_v7/Thermochemical-Nonequilibrium.md
new file mode 100644
index 00000000..aff2df7c
--- /dev/null
+++ b/_docs_v7/Thermochemical-Nonequilibrium.md
@@ -0,0 +1,400 @@
+---
+title: Thermochemical Nonequilibrium
+permalink: /docs_v7/Thermochemical-Nonequilibrium/
+---
+
+This page contains a summary of the physical models implemented in the NEMO solvers in SU2 designed ot simulate hypersonic flows in thermochemical nonequilibrium. This includes detials on thermodynamic and chemistry models, as well as transport properties and boundary conditions.
+
+---
+
+- [Thermodynamic Model](#thermodynamic-model)
+- [Finite Rate Chemistry](#finite-rate-chemistry)
+- [Vibrational Relaxation](#vibrational-relaxation)
+- [Viscous Phenomena and Transport Coefficients](#viscous-phenomena-and-transport-coefficients)
+ - [Wilkes-Blottner-Eucken](#wilkes-blottner-eucken)
+ - [Gupta-Yos](#gupta-yos)
+ - [Sutherland Viscosity Model](#sutherland-viscosity-model)
+- [Slip Flow](#slip-flow)
+- [Gas-surface Interaction](#gas-surface-interaction)
+
+---
+
+# Thermodynamic Model #
+
+| Solver | Version |
+| --- | --- |
+| `NEMO_EULER`, `NEMO_NAVIER_STOKES` | 7.0.0 |
+
+A rigid-rotor harmonic oscillator (RRHO) two-temperature model is used to model the thermodynamic state of continuum hypersonic flows. Through the independence of the energy levels, the total energy and vibrational--electronic energy per unit volume can be expressed as
+$$ \rho e = \sum_s \rho_s \left(e_s^{tr} + e_s^{rot} + e_s^{vib} + e_s^{el} + e^{\circ}_s + \frac{1}{2} \bar{v}^{\top} \bar{v}\right),
+$$
+and
+$$
+ \rho e^{ve} = \sum_s \rho_{s} \left(e_s^{vib} + e_s^{el}\right).
+$$
+
+Considering a general gas mixture consisting of polyatomic, monatomic, and free electron species, expressions for the energy stored in the translational, rotational, vibrational, and electronic modes are given as
+$$
+ e^{tr}_s =\begin{cases}
+ \frac{3}{2} \frac{R}{M_s} T & \text{for monatomic and polyatomic species,}\\
+ 0 & \text{for electrons,}
+ \end{cases}
+$$
+$$
+ e^{rot}_s =\begin{cases}
+ \frac{\xi }{2} \frac{R}{M_s} T & \text{for polyatomic species,}\\
+ 0 & \text{for monatomic species and electrons,}
+ \end{cases}
+$$
+\
+where $$\xi$$ is an integer specifying the number of axes of rotation,
+$$
+ e^{vib}_s =\begin{cases}
+ \frac{R}{M_s} \frac{\theta^{vib}_s}{exp\left( \theta^{vib}_s / T^{ve}\right) - 1} & \text{for polyatomic species,}\\
+ 0 & \text{for monatomic species and electrons,}
+ \end{cases}
+$$
+\
+where $$\theta^{vib}_s$$ is the characteristic vibrational temperature of the species, and
+
+
+$$
+ e^{el}_s =\begin{cases}
+ \frac{R}{M_s}\frac{\sum_{i=1}^{\infty} g_{i,s}{\theta^{el}_{i,s} \exp(-\theta^{el}_{i,s}/T_{ve})}}{\sum_{i=0}^{\infty} g_{i,s} exp(-\theta^{el}_{i,s}/T_{ve})} & \text{for polyatomic and monatomic species,}\\
+ \frac{3}{2} \frac{R}{M_s} T^{ve} & \text{for electrons,}
+ \end{cases}
+$$
+
+where $$\theta^{el}_s$$ is the characteristic electronic temperature of the species and $$g_i$$ is the degeneracy of the $$i^{th}$$ state.
+
+---
+
+# Finite Rate Chemistry #
+
+| Solver | Version |
+| --- | --- |
+| `NEMO_EULER`, `NEMO_NAVIER_STOKES` | 7.0.0 |
+
+The source terms in the species conservation equations are the volumetric mass production rates which are governed by the forward and backward reaction rates, $$R^f$$ and $$R^b$$, for a given reaction $$r$$, and can be expressed as
+$$
+ \dot{w}_s = M_s \sum_r (\beta_{s,r} - \alpha_{s,r})(R_{r}^{f} - R_{r}^{b}).
+$$
+
+From kinetic theory, the forward and backward reaction rates are dependent on the molar concentrations of the reactants and products, as well as the forward and backward reaction rate coefficients, $$k^f$$ and $$k^b$$, respectively, and can be expressed as
+$$
+ R_{r}^f = k_{r}^f \prod_s (\frac{\rho_s}{M_s})^{\alpha_{s,r}},
+$$
+and
+$$
+ R_{r}^b = k_{r}^b \prod_s (\frac{\rho_s}{M_s})^{\beta_{s,r}}.
+$$
+
+For an Arrhenius reaction, the forward reaction rate coefficient can be computed as
+$$
+ k_{r}^f = C_r(T_r)^{\eta_r} exp\left(- \frac{\epsilon_r}{k_B T_r}\right),
+$$
+where $$C_r$$ is the pre-factor, $$T_r$$ is the rate-controlling temperature for the reaction, $$\eta_r$$ is an empirical exponent, and $$\epsilon_r$$ is the activation energy per molecule.
+
+The rate-controlling temperature of the reaction is calculated as a geometric average of the translation-rotational and vibrational-electronic temperatures,
+$$
+ T_r = (T)^{a_r}(T^{ve})^{b_r}.
+$$
+
+The value of he equilibrium constant $$K_{eq}$$ is expressed as
+
+$$
+ K_{eq} = \exp( A_0 \left(\frac{T^c}{10,000}\right) + A_1 + A_2 \log \left( \frac{10,000}{T^c} \right) + A_3 \left( \frac{10,000}{T^c} \right) + A_4 \left( \frac{10,000}{T^c} \right)^2 ),
+$$
+
+where $$T^c$$ is a controlling temperature and $$A_0 - A_4$$ are constants dependent on the reaction. These reaction constants, the rate constrolling temperature and Arrhenius parameters are stored within the fluid model class in SU2 NEMO.
+
+---
+
+# Vibrational Relaxation #
+
+| Solver | Version |
+| --- | --- |
+| `NEMO_EULER`, `NEMO_NAVIER_STOKES` | 7.0.0 |
+
+Vibrational relaxation is computed using a standard Landau-Teller relaxation time with a Park high-temperature correction
+$$
+ \dot{\Theta}^{tr:ve} = \sum _s \rho_s \frac{de^{ve}_{s}}{dt} = \sum _s \rho_s \frac{e^{ve*}_{s} - e^{ve}_{s}}{\tau_s},
+$$
+where $$\tau_s$$ is computed using a combination of the Landau-Teller relaxation time, $$\langle \tau_s \rangle_{L-T}$$, and a limiting relaxation time from Park, $$\tau_{ps}$$ using
+$$
+ \tau_s = \langle \tau_s \rangle_{L-T} + \tau_{ps},
+$$
+and
+$$
+ \langle \tau_s \rangle_{L-T} = \frac{\sum_r X_r}{\sum_r X_r/\tau_{sr}}.
+$$
+The interspecies relaxation times are taken from experimental data from Millikan and White, expressed as
+$$
+ \tau_{sr} = \frac{1}{P}exp\left[A_sr\left(T^{-1/3} - 0.015\mu_{sr}^{1/4}\right) - 18.42\right].
+$$
+A limiting relaxation time, $$\tau_{ps}$$, is used to correct for under-prediction of the Millikan--White model at high temperatures. $$\tau_{ps}$$ is defined as
+$$
+ \tau_{ps} = \frac{1}{\sigma_s c_s n},
+$$
+
+where $$\sigma_s$$ is the effective collision~cross-section.
+
+---
+
+# Viscous Phenomena and Transport Coefficients #
+
+| Solver | Version |
+| --- | --- |
+| `NEMO_NAVIER_STOKES` | 7.0.0 |
+
+
+Mass, momentum, and energy transport in fluids are all governed by molecular collisions, and expressions for these transport properties can be derived from the kinetic theory. The mass diffusion fluxes, $$\mathbf{J}_s$$, are computed using Fick's Law of Diffusion:
+$$
+ \mathbf{J}_s = - \rho D_s \nabla(Y_s) + Y_s \sum_k \rho D_k \nabla(Y_k)
+$$
+
+where $$c_s$$ is the species mass fraction and $$D_s$$ is the species multi-component diffusion coefficient. The values of $$D_s$$ are computed as a weighted sum of binary diffusion coefficients between all species in the mixture. These are obtained by solving the Stefan--Maxwell equations under the Ramshaw approximations. The viscous stress tensor is written as
+$$
+ \boldsymbol{\sigma} = \mu \left( \nabla \mathbf{u} + \nabla {\mathbf{u}}^\mathsf{T} - \frac{2}{3} \mathbf{I} (\nabla \cdot \mathbf{u}) \right),
+$$
+where $$\mu$$ is the mixture viscosity coefficient. The conduction heat flux for each thermal energy mode, $$\mathbf{q}^{k}$$, is modeled by Fourier’s Law of heat conduction:
+$$
+\mathbf{q}^{k} = \kappa^{k} \nabla(T^k),
+$$
+
+where $$\kappa^{k}$$ is the thermal conductivity associated with energy mode $$k$$.
+
+$$D_s$$, $$\mu$$, and $$\kappa$$ can be evaluated using the models discussed below by selecting the appropriate options in the configuration file.
+
+
+## Wilkes-Blottner-Eucken ##
+
+The mixture dynamic viscosity and thermal conductivity are computed using Wilke's semi-empirical mixing rule as
+
+$$
+\mu = \sum_s \frac{X_s \mu_s}{\phi_s},
+$$
+
+and
+
+$$
+\kappa = \sum_s \frac{X_s \kappa_s}{\phi_s},
+$$
+
+where $$X_s$$ is the mole fraction of species $$s$$. The species dynamic viscosity is computed using Blottner's three paramter curve fit for high temperature air,
+
+$$
+\mu_s = 0.1 \exp [(A_s\log(T) + B_s)\log(T) + C_s].
+$$
+
+The species thermal conductivities are computed according to Eucken's formula as
+
+$$
+\kappa^{tr}_s = \mu_s \left( \frac{5}{2} C_{v_s}^{trans} + C_{v_s}^{rot} \right),
+$$
+
+$$
+\kappa^{ve}_s = \mu_s C^{ve}_{v_s}.
+$$
+
+And the term $$\phi_s$$ is given by
+$$
+\phi_s = \sum_r X_r \left[ 1 + \sqrt{\frac{\mu_r}{\mu_s}}\left( \frac{M_r}{M_s} \right)^{1/4} \right]^{2} \left[ \sqrt{8 \left(1 + \frac{M_s}{M_r} \right)} \right]^{-1}.
+$$
+
+The effective species diffusion coefficeint is copmuted as a weighted sum of the species binary diffusion coefficients
+
+$$
+\frac{(1 - X_i)}{D_i} = \sum_{i \neq j} \frac{X_j}{D_{ij}},
+$$
+
+where the binary diffusion coefficients are computed as
+
+$$
+\rho D_{ij} = 1.1613 \times 10^{-25} \frac{M \sqrt{T \left( \frac{1}{M_i} + \frac{1}{M_j} \right) }}{\Omega_{ij}^{(1,1)}}.
+$$
+
+Collision integrals are computed using a four parameter curve fit for neutral-neutral, neutral-ion, and electron-ion collisions
+
+$$
+\pi \Omega_{ij}^{(n,n)} = D T^{A(\log(T))^2 + B \log(T) + C},
+$$
+
+where A-D are constants. Ion-ion, electron-ion, and electron-electron collisions modeled using a shielded Coulomb potential as
+
+$$
+\pi \Omega_{ij}^{(n,n)} = 5.0 \times 10^{15} \pi (\lambda_D / T)^2 \log \{D_n T^{*} \left[ 1 - C_n \exp\left( -c_n T^{*} \right) \right] + 1 \}
+$$
+
+where
+
+$$
+T^{*} = \frac{\lambda_D}{e^2_{CGS} / (k_{B,CGS} T) }
+$$
+
+and the Debye length $$\lambda_D$$ is defined as
+
+$$
+\lambda_D = \sqrt{\frac{k_{B,CGS} T}{4 \pi n_{e,CGS} e^2_{CGS}}}.
+$$
+
+The Wilkes-Blottner-Eucken model is generally efective up to temperatures of 10,000 K. Above these temperatures it is recommended to use the Gupta-Yos model.
+
+## Gupta-Yos ##
+
+Aother model develped by Gupta focuses on the transport properties of weakly ionized flows, and is generally more accurate than the Wilkes-Blottner-Eucken model at temperatures above 10,000 K.
+
+The forumalae for the transport coefficients are dependent on the collision terms
+
+$$
+\Delta_{s,r}^{(1)}(T) = \frac{8}{3} \left[ \frac{2M_s M_r}{\pi R T (M_s + M_r)} \right]^{1/2} \pi {\Omega_{s,r}^{(1,1)}}
+$$
+
+and
+$$
+\Delta_{s,r}^{(2)}(T) = \frac{16}{5} \left[ \frac{2M_s M_r}{\pi R T (M_s + M_r)} \right]^{1/2} \pi {\Omega_{s,r}^{(2,2)}},
+$$
+
+where the collision cross-sections are computed as described in the Wilkes-Blottner-Eucken section.
+
+The mixutre viscoisty is computed as
+
+$$
+\mu = \sum_{s \neq e} \frac{m_s \gamma_s}{\sum_{r \neq e} \gamma_r \Delta_{s,r}^{(2)}(T_{tr}) + \gamma_r \Delta_{e,r}^{(2)}(T_{ve})} + \frac{m_e \gamma_e}{\sum_r \gamma_r \Delta_{e,r}^{(2)}(T_{ve}) }
+$$
+
+where
+
+$$
+\gamma_s = \frac{\rho_s}{\rho M_s}.
+$$
+
+Thermal conductivity is computed in terms of different energy modes. The contribution due to translation modes is expressed as
+
+$$
+\kappa_t = \frac{15}{4} k_{B} \sum_{s \neq e}
+\frac{\gamma_s}{\sum_{r \neq e} a_{s,r} \gamma_r \Delta_{s,r}^{(2)}(T_{tr}) + 3.54 \gamma_e \Delta_{s,e}^{(2)}(T_{ve})},
+$$
+
+where
+
+$$
+a_{s,r} = 1 + \frac{\left[1 - (m_s/m_r) \right] \left[ 0.45 - 2.54(m_s/m_r) \right] }{\left[1 + (m_s/m_r) \right]^2}
+$$
+
+and where
+
+$$
+m_s = \frac{M_s}{N_{av}}
+$$
+
+with $$N_{av}$$ being Avogadro's Number. The thermal conductivity for the rotational modes is expressed as
+
+$$
+\kappa_r = k_{B} \sum_{s \neq e}
+\frac{\gamma_s}{\sum_{r \neq e} \gamma_r \Delta_{s,r}^{(1)}(T_{tr}) + \gamma_e \Delta_{s,e}^{(1)}(T_{ve})}.
+$$
+
+The mixture translational/rotational thermal conductivity can then be expressed as
+
+$$
+\kappa_{tr} = \kappa_t + \kappa_r.
+$$
+
+The vibrational/electronic mode thermal conductivity is
+
+$$
+\kappa_{ve} = k_{B} \frac{C_{ve}}{R} \sum_{s \in molecules} \frac{\gamma_s}
+{\sum_{r \neq e} \gamma_r \Delta_{s,r}^{(1)}(T_{tr}) + \gamma_e \Delta_{s,r}^{(1)}(T_{ve}) }
+$$
+
+and the thermal conductivity for electrons is given by
+
+$$
+\kappa_e = \frac{15}{4} k_{B} \frac{\gamma_e}{\sum_r 1.45 \gamma_r \Delta_{e,r}^{(2)}(T_{ve})}.
+$$
+
+Finally, the binary diffusion coefficient for heavy particles is given by
+
+$$
+D_{s,r} = \frac{k_{B} T_{tr}}{p \Delta_{s,r}^{(1)}(T_{tr})},
+$$
+
+and for electrons,
+
+$$
+D_{e,r} = \frac{k_{B} T_{ve}}{p \Delta_{e,r}^{(1)}(T_{ve})}.
+$$
+
+## Sutherland Viscosity Model ##
+
+In addition to the two models discussed above, there is the option to use a Sutherland model to calculate the flow viscosity. The Sutherland model is not applicable at high temperatures.
+
+In this case, the viscosity is computed as
+
+$$
+\mu = \mu_{0} \left( \frac{T}{T_{0}} \right)^{3/2} \frac{T_0 + S_{\mu}}{T + S_{\mu}},
+$$
+
+where $$T_0$$ is a reference temperature (273.15 K), $$\mu_0$$ is a reference viscosity, and $$S_{\mu}$$ is the Sutherland constant.
+
+If the Sutherland model is selected with a NEMO solver, species diffusion coefficients and thermal conductivity are computed using the models described in the Wilkes-Blottner-Eucken section.
+
+---
+
+# Slip Flow #
+
+| Solver | Version |
+| --- | --- |
+| `NEMO_NAVIER_STOKES` | 7.0.0 |
+
+SU2-NEMO uses the Maxwell velocity and Smoluchowski temperature jump equations to compute the velocity and temperature of the gas in contact with the surface. The equations are given as
+$$
+v_s = \frac{2 - \sigma}{\sigma} \lambda \frac{\partial v}{\partial n } + \\
+\frac{3}{4} \frac{\mu}{\rho T} \frac{\partial T}{\partial x},
+$$
+
+and
+$$
+T - T_w = \frac{2 - \alpha}{\alpha} \lambda \frac{2\gamma}{(\gamma + 1 )Pr} \frac{\partial T}{\partial n},
+$$
+
+respectively, where $$\mu$$ is the flow viscosity, $$\rho$$ is the mixture density, $$Pr$$ is the Prandtl number, $$\gamma$$ is the specific heat ratio, $$T$$ is the temperature of the gas, $$T_w$$ is the temperature of the surface, and $$\lambda$$ is the mean free path, calculated as
+$$
+ \lambda = \frac{\mu}{\rho} \frac{\pi}{\sqrt{2RT}}.
+$$
+
+The coefficients $$\sigma$$ and $$\alpha$$ are referred to as the Tangential Momentum Accommodation Coefficient (TMAC) and the Thermal Accommodation Coefficient (TAC), respectively. The values of the accommodation coefficients depend on the physical characteristics of the surface, and are usually determined empirically.
+
+
+---
+
+# Gas-surface Interaction #
+
+| Solver | Version |
+| --- | --- |
+| `NEMO_NAVIER_STOKES` | 7.0.0 |
+
+Mechanisms of gas-surface interaction are implemented as specific boundary conditions within the SU2-NEMO computational suite. The net result of recombination reactions occurring on the surface is a production of chemical species due to catalytic reactions, $$\dot{\omega}_s^{cat}$$, that must be balanced by the normal diffusive and convective flux at the wall. For steady flow and a no-slip boundary, this can be expressed as
+
+$$
+ \mathbf{J}_s \cdot \mathbf{n} = \dot{\omega}_s^{cat}.
+$$
+
+In SU2-NEMO, the chemical production of species due to catalytic processes is included in the computation of the viscous component of the residual, as an additional diffusive flux equivalent to the chemical source term computed due to catalytic reactions. Gradients of species density are then computed directly as part of the SU2-NEMO computational routine, which are used to compute gradients of species mass fraction at wall vertices.
+
+Options in SU2-NEMO include a super-catalytic wall in which species concentrations are set to specify full recombination to a specified equilibrium concentration (typically the free-stream conditions)
+
+$$
+Y_{w,s} = Y_{eq,s},
+$$
+
+as well as a partiall catalytic wall using a specified reaction efficiency model
+
+$$
+ \dot{\omega}_s^{cat} = \gamma_s Y_s \rho_w \sqrt{\frac{R_s T_w}{2\pi}},
+$$
+
+where $$\gamma_{s}$$ is the species catalytic efficiency, and represents the proportion of incident mass flux of monatomic species $$s$$ which recombines into its heteronuclear diatomic molecule at the wall.
+
+---
diff --git a/_docs_v7/Tracy-Integration.md b/_docs_v7/Tracy-Integration.md
new file mode 100644
index 00000000..ba95983c
--- /dev/null
+++ b/_docs_v7/Tracy-Integration.md
@@ -0,0 +1,99 @@
+---
+title: Integrating Tracy Profiler with SU2
+permalink: /docs_v7/Tracy-Integration/
+---
+
+- [Introduction](#introduction)
+- [Compiling SU2 with Tracy](#compiling-su2-with-tracy)
+- [Instrumenting SU2 Code](#instrumenting-su2-code)
+- [Running the Profiler and Visualizing Data](#running-the-profiler-and-visualizing-data)
+- [Conclusion](#conclusion)
+
+---
+
+## Introduction
+
+Tracy is a high-performance, real-time profiler designed for C++ applications, offering nanosecond-resolution timing with minimal overhead. It is an excellent tool for profiling computationally intensive software like SU2, where traditional profilers such as Valgrind may introduce significant slowdowns. This guide provides step-by-step instructions for integrating Tracy with SU2, enabling users to analyze and optimize the performance of their CFD simulations effectively.
+
+## Compiling SU2 with Tracy
+
+To compile SU2 with Tracy support, follow these steps:
+
+- Configure the build with Tracy enabled using Meson:
+ ```bash
+ ./meson.py setup build -Dwith-mpi=disabled --buildtype=debugoptimized -Denable-tracy=true --prefix=
+{% for section in site.data.gsoc %}
+
diff --git a/_includes/gsoc_section_nav.html b/_includes/gsoc_section_nav.html
new file mode 100644
index 00000000..f5feadf8
--- /dev/null
+++ b/_includes/gsoc_section_nav.html
@@ -0,0 +1,52 @@
+{% comment %}
+Map grabs the doc sections, giving us an array of arrays. Join, flattens all
+the items to a comma delimited string. Split turns it into an array again.
+{% endcomment %}
+{% assign gsoc = site.data.gsoc | map: 'gsoc' | join: ',' | split: ',' %}
+
+{% comment %}
+Because this is built for every page, lets find where we are in the ordered
+document list by comparing url strings. Then if there's something previous or
+next, lets build a link to it.
+{% endcomment %}
+
+{% for document in gsoc %}
+ {% assign document_url = document | prepend:"/gsoc/" | append:"/" %}
+ {% if document_url == page.url %}
+
+
+{% endfor %}
+
+
+ + + {{ section.title }} + +
+
+
+ -
+ {% for item in section.gsoc %}
+ {% assign item_url = item | prepend:"/gsoc/" | append:"/" %}
+ {% assign p = site.gsoc | where:"url", item_url | first %}
+ {{ p.title }}
+ {% endfor %}
+
-
+ {% if forloop.first %}
+
- + + Previous + + + {% else %} + {% assign previous = forloop.index0 | minus: 1 %} + {% assign previous_page = gsoc[previous] | prepend:"/gsoc/" | append:"/" %} +
- + + Previous + + + {% endif %} + + {% if forloop.last %} +
- + + Next + + + {% else %} + {% assign next = forloop.index0 | plus: 1 %} + {% assign next_page = gsoc[next] | prepend:"/gsoc/" | append:"/" %} +
- + + Next + + + {% endif %} + + + {% break %} + {% endif %} +{% endfor %} diff --git a/_includes/head.html b/_includes/head.html index cd199958..1e4389db 100644 --- a/_includes/head.html +++ b/_includes/head.html @@ -19,7 +19,10 @@ - + + + + diff --git a/_includes/su2gui_nav.html b/_includes/su2gui_nav.html new file mode 100644 index 00000000..f2d70c56 --- /dev/null +++ b/_includes/su2gui_nav.html @@ -0,0 +1,22 @@ +
- + + Previous + + + {% else %} + {% assign previous = forloop.index0 | minus: 1 %} + {% assign previous_page = su2gui[previous] | prepend:"/su2gui/" | append:"/" %} +
- + + Previous + + + {% endif %} + + {% if forloop.last %} +
- + + Next + + + {% else %} + {% assign next = forloop.index0 | plus: 1 %} + {% assign next_page = su2gui[next] | prepend:"/su2gui/" | append:"/" %} +
- + + Next + + + {% endif %} + + + {% break %} + {% endif %} +{% endfor %} diff --git a/_includes/topnav.html b/_includes/topnav.html index b8173023..60e22f64 100644 --- a/_includes/topnav.html +++ b/_includes/topnav.html @@ -18,15 +18,16 @@
- Docs
- Tutorials
- V&V -
- Forum +
- User Forum +
- Slack
- Develop +
- GUI +
- GSOC
+{% for section in site.data.su2gui %}
+
diff --git a/_includes/su2gui_section_nav.html b/_includes/su2gui_section_nav.html
new file mode 100644
index 00000000..a57f63f6
--- /dev/null
+++ b/_includes/su2gui_section_nav.html
@@ -0,0 +1,52 @@
+{% comment %}
+Map grabs the doc sections, giving us an array of arrays. Join, flattens all
+the items to a comma delimited string. Split turns it into an array again.
+{% endcomment %}
+{% assign su2gui = site.data.su2gui | map: 'su2gui' | join: ',' | split: ',' %}
+
+{% comment %}
+Because this is built for every page, lets find where we are in the ordered
+document list by comparing url strings. Then if there's something previous or
+next, lets build a link to it.
+{% endcomment %}
+
+{% for document in su2gui %}
+ {% assign document_url = document | prepend:"/su2gui/" | append:"/" %}
+ {% if document_url == page.url %}
+
+
+{% endfor %}
+
+
+ + + {{ section.title }} + +
+
+
+ -
+ {% for item in section.su2gui %}
+ {% assign item_url = item | prepend:"/su2gui/" | append:"/" %}
+ {% assign p = site.su2gui | where:"url", item_url | first %}
+ {{ p.title }}
+ {% endfor %}
+
-
+ {% if forloop.first %}
+
diff --git a/_layouts/gsoc.html b/_layouts/gsoc.html
new file mode 100644
index 00000000..1276685d
--- /dev/null
+++ b/_layouts/gsoc.html
@@ -0,0 +1,55 @@
+---
+layout: default
+---
+
+ SU2_CFD config_NICFD_PINN.cfg
+```
+where `````` is the number of cores. [Figure 5](#mesh_highlight) shows the residual trends of the flow solution of the course of 10k iterations.
+
+
+Figure (5): Convergence history of the SU2 simulation.
+
+
+### Results
+
+The Mach number and compressibility factor of the flow solution is visualized in the image below. The flow expands to supersonic speeds in the divergent section of the nozzle, where the compressibility factor approaches a value of 1.0, while the compressibility factor is significantly lower in the convergent section of the nozzle.
+
+Figure (6): Mach number of the flow solution (top) and compressibility factor of the fluid (bottom).
diff --git a/_tutorials/compressible_flow/Transitional_Flat_Plate/Transitional_Flat_Plate.md b/_tutorials/compressible_flow/Transitional_Flat_Plate/Transitional_Flat_Plate.md
index 11160a89..aacd7e7d 100644
--- a/_tutorials/compressible_flow/Transitional_Flat_Plate/Transitional_Flat_Plate.md
+++ b/_tutorials/compressible_flow/Transitional_Flat_Plate/Transitional_Flat_Plate.md
@@ -42,7 +42,7 @@ For verification, we will be comparing SU2 results against the results of natura
### Problem Setup
-The length of the flat plate is 1.5 meters, and it is represented by an adiabatic no-slip wall boundary condition. There is a symmetry plane located before the leading edge of the flat plate. Inlet boundary condition is used on the left boundary of the domain, and outlet boundary condition is applied to the top and right boundaries of the domain. The freestream velocity, density, viscosity and turbulence intensity (%) is specified as 50.1 m/s, 1.2 kg/m^3, 1.8e-05 and 0.18%, respectively. Since the Mach number is about 0.15, compressibility effects are negligible; therefore, the incompressible flow solver can be employed.
+The length of the flat plate is 1.5 meters, and it is represented by an adiabatic no-slip wall boundary condition. There is a symmetry plane located before the leading edge of the flat plate. Inlet boundary condition is used on the left boundary of the domain, and outlet boundary condition is applied to the top and right boundaries of the domain. The freestream velocity, density, viscosity and turbulence intensity (%) is specified as 50.1 m/s, 1.2 kg/m^3, 1.8e-05 and 0.18% (u'/U=0.0018), respectively. Since the Mach number is about 0.15, compressibility effects are negligible; therefore, the incompressible flow solver can be employed.
### Mesh Description
@@ -62,17 +62,17 @@ Several of the key configuration file options for this simulation are highlighte
% LINEAR_ELASTICITY, POISSON_EQUATION)
SOLVER= INC_RANS
%
-% Specify turbulent model (NONE, SA, SA_NEG, SST)
+% Specify turbulent model (NONE, SA, SST)
KIND_TURB_MODEL= SA
%
-% Specify transition model (NONE, BC)
-KIND_TRANS_MODEL= BC
+% Specify transition model
+SA_OPTIONS= BCM
%
-% Specify Turbulence Intensity (%)
-FREESTREAM_TURBULENCEINTENSITY = 0.18
+% Specify Turbulence Intensity (u'/U)
+FREESTREAM_TURBULENCEINTENSITY = 0.0018
```
-The governing equations are RANS with the Spalart-Allmaras (`SA`) turbulence model. By entering `KIND_TRANS_MODEL= BC`, the Bas-Cakmakcioglu Algebraic Transition Model is activated. This model requires freestream turbulence intensity that is to be used in the transition correlation, thus the `FREESTREAM_TURBULENCEINTENSITY` option is also used. The BC model achieves its purpose by modifying the production term of the 1-equation SA turbulence model. The production term of the SA model is damped until a considerable amount of turbulent viscosity is generated, and after that point, the damping effect on the transition model is disabled. Thus, a transition from laminar to turbulent flow is obtained.
+The governing equations are RANS with the Spalart-Allmaras (`SA`) turbulence model. By entering `SA_OPTIONS= BCM`, the Bas-Cakmakcioglu Algebraic Transition Model is activated. This model requires freestream turbulence intensity that is to be used in the transition correlation, thus the `FREESTREAM_TURBULENCEINTENSITY` option is also used. The BC model achieves its purpose by modifying the production term of the 1-equation SA turbulence model. The production term of the SA model is damped until a considerable amount of turbulent viscosity is generated, and after that point, the damping effect on the transition model is disabled. Thus, a transition from laminar to turbulent flow is obtained.
The incompressible freestream properties are specified as follows. (Please see "Notes" for freestream properties of other transitional flat plate test cases).
diff --git a/_tutorials/compressible_flow/Transitional_Flat_Plate_T3A/Transitional_Flat_Plate_T3A.md b/_tutorials/compressible_flow/Transitional_Flat_Plate_T3A/Transitional_Flat_Plate_T3A.md
new file mode 100644
index 00000000..2705cb32
--- /dev/null
+++ b/_tutorials/compressible_flow/Transitional_Flat_Plate_T3A/Transitional_Flat_Plate_T3A.md
@@ -0,0 +1,110 @@
+---
+title: Transitional Flat Plate for T3A and T3A-
+permalink: /tutorials/Transitional_Flat_Plate_T3A/
+written_by: Sunoh Kang
+for_version: 7.5.0
+solver: RANS
+requires: SU2_CFD
+complexity: basic
+follows:
+---
+
+## Goals
+
+Upon completing this tutorial, the user will be familiar with performing an external, transitional flow over a flat plate. The flow over the flat plate will be laminar until it reaches a point where a transition correlation depending on local flow variables is activated. The results can be compared to the zero pressure gradient natural transition experiment of T3A & T3A-[ERCOFTAC](http://cfd.mace.manchester.ac.uk/ercoftac/doku.php). The following capabilities of SU2 will be showcased in this tutorial:
+
+- Steady, 2D, incompressible RANS equations
+- k-w SST-2003m turbulence model with Langtry and Menter 2009 ([LM2009](https://turbmodels.larc.nasa.gov/langtrymenter_4eqn.html)) transition model
+- L2Roe convective scheme in space (2nd-order, upwind)
+- Corrected average-of-gradients viscous scheme
+- Euler implicit time integration
+- farfield, Outlet, Symmetry and No-Slip Wall boundary conditions
+
+## Resources
+
+The resources for this tutorial can be found in the [compressible_flow/Transitional_Flat_Plate/LM](https://github.com/su2code/Tutorials/tree/master/compressible_flow/Transitional_Flat_Plate/LM) directory in the [tutorial repository](https://github.com/su2code/Tutorials).
+
+## Tutorial
+
+The following tutorial will walk you through the steps required when solving for the transitional flow over a flat plate using SU2. It is assumed you have already obtained and compiled the SU2_CFD code for a serial or parallel computation. If you have yet to complete these requirements, please see the [Download](/docs_v7/Download/) and [Installation](/docs_v7/Installation/) pages.
+
+### Background
+
+Practically, most CFD analyses are carried out using fully turbulent fields that do not account for boundary layer transition. Given that the flow is everywhere turbulent, no separation bubbles or other complex flow phenomena evolve. A transition model can be introduced, however, such that the flow begins as laminar by damping the production term of the turbulence model until a point where a transition correlation is activated. Currently, Langtry and Menter transition model ([LM](https://turbmodels.larc.nasa.gov/langtrymenter_4eqn.html)) that uses k-w SST-2003m as the baseline turbulence model is implemented in SU2.
+
+For verification, we will be comparing SU2 results against the results of natural transition flat plate experiment of [ERCOFTAC](http://cfd.mace.manchester.ac.uk/ercoftac/doku.php). The experimental data include skin friction coefficient distribution versus the local Reynolds number over the flat plate.
+
+### Problem Setup
+
+The length of the flat plate is 20 meters, and it is represented by an adiabatic no-slip wall boundary condition. There is a symmetry plane located before the leading edge of the flat plate. far boundary condition is used on the left and top boundary of the domain, and outlet boundary condition is applied to the right boundaries of the domain. Flow condition, you can reference from https://doi.org/10.2514/6.2022-3679.
+
+### Mesh Description
+
+The mesh used for T3A tutorial, which provided by [AIAA Transition modeling workshop-I](https://transitionmodeling.larc.nasa.gov).
+The mesh used for T3A- tutorial, which consists of 122,880 quadrilaterals.
+Both T3A and T3A- boundary conditions are shown below.
+
+
+
+Figure (1): Mesh with boundary conditions (red: far, blue:out, orange:symmetry, green:wall)
+
+### Configuration File Options
+
+Several of the key configuration file options for this simulation are highlighted here.
+
+```
+% Physical governing equations (EULER, NAVIER_STOKES,
+% WAVE_EQUATION, HEAT_EQUATION,
+% LINEAR_ELASTICITY, POISSON_EQUATION)
+SOLVER= RANS
+%
+% Specify turbulent model (NONE, SA, SST)
+KIND_TURB_MODEL= SST
+%
+% Specify versions/corrections of the SST model (V2003m, V1994m, VORTICITY, KATO_LAUNDER, UQ, SUSTAINING)
+SST_OPTIONS= NONE
+%
+% Transition model (NONE, LM)
+KIND_TRANS_MODEL= LM
+
+...
+
+%
+% Free-stream turbulence intensity
+FREESTREAM_TURBULENCEINTENSITY = 0.01
+
+```
+
+In the LM model, transition onset location is affected by freestream turbulence intensity.
+
+### Running SU2
+
+To run this test case, follow these steps at a terminal command line:
+
+1. Copy the ([config file](https://github.com/su2code/Tutorials/tree/master/compressible_flow/Transitional_Flat_Plate/LM/)) and ([mesh file](https://github.com/su2code/Tutorials/tree/master/compressible_flow/Transitional_Flat_Plate/LM/)) so that they are in the same directory. Move to the directory containing the config file and the mesh file. Make sure that the SU2 tools were compiled, installed, and that their install location was added to your path.
+
+2. Run the executable by entering
+
+ ```
+ $ SU2_CFD transitional_LM_model_ConfigFile.cfg
+ ```
+
+ at the command line.
+
+3. SU2 will print residual updates for each iteration of the flow solver, and the simulation will finish upon reaching the specified convergence criteria.
+
+4. Files containing the results will be written upon exiting SU2. The flow solution can be visualized in Tecplot or ParaView.
+
+### Results
+
+The figure below compares the skin friction results obtained by the LM transition model to the result of another solver(=Fluent 19.0) and experimental data.
+
+
+Figure (2): Comparison of the skin friction coefficients for the T3A case.
+
+Figure (3): Comparison of the skin friction coefficients for the T3A- case.
+
+
+## Notes
+
+The [LM model](https://turbmodels.larc.nasa.gov/langtrymenter_4eqn.html) is designed using general subsonic transition experiment results(T-S wave, bypass transition, and separation-induced transition). So, This LM model can't provide appropriate simulation results for crossflow, supersonic, and hypersonic flow transition(= crossflow instability, 1st mode, Mack 2nd mode).
diff --git a/_tutorials/compressible_flow/UQ_NACA0012/UQ_NACA0012.md b/_tutorials/compressible_flow/UQ_NACA0012/UQ_NACA0012.md
index ffe9095e..cd0ceb05 100644
--- a/_tutorials/compressible_flow/UQ_NACA0012/UQ_NACA0012.md
+++ b/_tutorials/compressible_flow/UQ_NACA0012/UQ_NACA0012.md
@@ -73,8 +73,8 @@ If there is a need to perform the perturbations individually (for example to run
```
% ------------------- UNCERTAINTY QUANTIFICATION DEFINITION -------------------%
%
-% Using uncertainty quantification module (YES, NO). Only available with SST
-USING_UQ= YES
+% Using uncertainty quantification module. Available as an option for the SST turbulence model.
+SST_OPTIONS= UQ
%
% Eigenvalue perturbation definition (1, 2, or 3)
UQ_COMPONENT= 1
diff --git a/_tutorials/compressible_flow/Unsteady_NACA0012/Unsteady_NACA0012.md b/_tutorials/compressible_flow/Unsteady_NACA0012/Unsteady_NACA0012.md
index b97bcecc..f7b6cd73 100644
--- a/_tutorials/compressible_flow/Unsteady_NACA0012/Unsteady_NACA0012.md
+++ b/_tutorials/compressible_flow/Unsteady_NACA0012/Unsteady_NACA0012.md
@@ -24,7 +24,6 @@ Furthermore, the user is introduced in the so-called windowing approach, a regul
- Dual time-stepping for unsteady flows
- Windowing
- Time-convergence
-- Code parallelism (optional)
This tutorial also provides an explanation for properly setting up viscous, compressible, unsteady 2D flow conditions in SU2.
We also introduce a new type of time-convergence criteria for periodic flows, which monitors the change of the time-average of a specific objective, such as lift or drag, in order to assess convergence.
@@ -69,8 +68,8 @@ Figure (3): Close-up view of the airfoil surface and the aerodynamic coefficient
### Configuration File Options ###
-Configuration of the physical problem is similar to the ONERA M6 tutorial, that one can access [here](../Turbulent_ONERAM6). However, contrary to the ONERA M6 case, here a unsteady simulation is performed, hence, the Unsteady RANS (URANS) equations in 2D must be solved.
-Unsteady simulations in SU2 are computed by employing a dual time-stepping scheme. To this end, one first performs a spatial discretization as explained in the [ONERA M6](../Turbulent_ONERAM6) tutorial.
+Configuration of the physical problem is similar to the ONERA M6 tutorial, that one can access [here](../Turbulent_ONERAM6). However, contrary to the ONERA M6 case, here an unsteady simulation is performed, hence, the Unsteady RANS (URANS) equations in 2D must be solved.
+Unsteady RANS simulations in SU2 are typically computed via the dual time-stepping approach. To this end, one first performs a spatial discretization as explained in the [ONERA M6](../Turbulent_ONERAM6) tutorial.
After that, a time discretization in physical time is performed, that results in a residual equation of the form
$$ R(u^n) = 0 \qquad \forall n=1,\dots,N. $$
@@ -97,13 +96,13 @@ TIME_DOMAIN = YES
TIME_MARCHING= DUAL_TIME_STEPPING-2ND_ORDER
%
% Time Step for dual time stepping simulations (s)
-TIME_STEP= 5e-3
+TIME_STEP= 5e-4
%
% Maximum Number of physical time steps.
-TIME_ITER= 2200
+TIME_ITER= 2000
%
% Number of internal iterations (dual time method)
-INNER_ITER= 50
+INNER_ITER= 10
%
% Time discretization for inner iteration.
TIME_DISCRE_FLOW= EULER_IMPLICIT
@@ -167,10 +166,10 @@ WINDOW_CAUCHY_CRIT = YES
CONV_WINDOW_FIELD= (TAVG_DRAG, TAVG_LIFT)
%
% Number of elements to apply the criteria
-CONV_WINDOW_CAUCHY_ELEMS= 100
+CONV_WINDOW_CAUCHY_ELEMS= 10
%
% Epsilon to control the series convergence
-CONV_WINDOW_CAUCHY_EPS= 1E-2
+CONV_WINDOW_CAUCHY_EPS= 1E-4
%
% Number of iterations to wait after the iteration specified in WINDOW_START_ITER.
CONV_WINDOW_STARTITER = 10
@@ -197,37 +196,25 @@ RESTART_ITER = 499
### Running SU2
-Instructions for running this test case are given here for both serial and parallel computations.
-
-#### In Serial
-
-The wing mesh should fit on a single-core machine. To run this test case in serial, follow these steps at a terminal command line:
- 1. Move to the directory containing the config file (unsteady_NACA0012.cfg) and the mesh file (unsteady_NACA0012_mesh.su2). Make sure that the SU2 tools were compiled, installed, and that their install location was added to your path.
- 2. Run the executable by entering in the command line:
-
+The airfoil mesh should fit on a single-core machine. To run this test case follow these steps at a terminal command line:
+ 1. Move to the directory containing the config file ([unsteady_naca0012.cfg](https://github.com/su2code/Tutorials/tree/master/compressible_flow/Unsteady_NACA0012/unsteady_naca0012.cfg)) and the mesh file ([unsteady_naca0012_mesh.su2](https://github.com/su2code/Tutorials/tree/master/compressible_flow/Unsteady_NACA0012/unsteady_naca0012_mesh.su2)). Make sure that the SU2 tools were compiled, installed, and that their install location was added to your path.
+ 2. For serial execution run the command:
```
$ SU2_CFD unsteady_NACA0012.cfg
```
3. SU2 will print residual updates with each iteration of the flow solver, and the simulation will terminate after reaching the specified convergence criteria.
- 4. Files containing the results will be written upon exiting SU2. The flow solution can be visualized in ParaView (.vtk) or Tecplot (.dat for ASCII).
-
-#### In Parallel
-
-If SU2 has been built with parallel support, the recommended method for running a parallel simulation is through the use of the parallel_computation.py Python script. This automatically handles the domain decomposition and execution with SU2_CFD, and the merging of the decomposed files using SU2_SOL. Follow these steps to run the ONERA M6 case in parallel:
- 1. Move to the directory containing the config file ([unsteady_naca0012.cfg](https://github.com/su2code/Tutorials/tree/master/compressible_flow/Unsteady_NACA0012/unsteady_naca0012.cfg)) and the mesh file ([unsteady_naca0012_mesh.su2](https://github.com/su2code/Tutorials/tree/master/compressible_flow/Unsteady_NACA0012/unsteady_naca0012_mesh.su2)). Make sure that the SU2 tools were compiled with parallel support, installed, and that their install location was added to your path.
- 2. Run the python script which will automatically call SU2_CFD and will perform the simulation using `NP` number of processors by entering in the command line:
-
- ```
- $ parallel_computation.py -n NP -f unsteady_NACA0012.cfg
- ```
+ 4. Files containing the results will be written on every time step.
- 3. SU2 will print residual updates with each iteration of the flow solver, and the simulation will terminate after reaching the specified convergence criteria.
- 4. The python script will automatically call the `SU2_SOL` executable for generating visualization files from the native restart file written during runtime. The flow solution can then be visualized in ParaView (.vtk) or Tecplot (.dat for ASCII).
+To run the case in parallel (using MPI) simply do:
+```
+$ mpirun -n NP SU2_CFD unsteady_NACA0012.cfg
+```
+Where NP is the number of processors, note that different MPI distributions may need slightly different syntax (e.g. mpiexec).
### Results
-Results for the turbulent flow about the NACA0012 airfoil are shown below. The first picture shows the time dependent
+Results for the flow about the NACA0012 airfoil are shown below. The first picture shows the time dependent
drag (black) as well as the windowed average from iteration 500 up to the current iteration computed with different
windowing-functions.
The Hann-Square-windowed time-average set up in this tutorial is displayed by the red line.
diff --git a/_tutorials/contribute.md b/_tutorials/contribute.md
index c1ffa3e7..2a12b404 100644
--- a/_tutorials/contribute.md
+++ b/_tutorials/contribute.md
@@ -15,14 +15,14 @@ Do you want to contribute to SU2 with a tutorial? It's easy! Just create a fork
The tutorials in this section of the site are stored under the `_tutorials` folder. To add your contributions:
-**1.** Create a new subfolder in `_tutorials/` as `_tutorials/Your_Folder_Name`, where you will store your subgroup of tutorials. You can also add your conribution to an existing folder if it fits better within the existing structure.
+**1.** Create a new subfolder in `_tutorials/` as `_tutorials/Your_Folder_Name`, where you will store your subgroup of tutorials. You can also add your contribution to an existing folder if it fits better within the existing structure.
**2.** Add a new Markdown file inside the subfolder, as `_tutorials/Your_Folder_Name/Your_Tutorial.md`. Add the following [front matter](https://jekyllrb.com/docs/frontmatter/) to your file:
```
---
title: Your Tutorial Title
-permalink: /docs/Your_Folder_Name/Your_Tutorial/
+permalink: /tutorials/Your_Folder_Name/Your_Tutorial/
---
I'm contributing to SU2!
@@ -32,7 +32,7 @@ I'm contributing to SU2!
```
- title: Your Subgroup of Tutorials
- docs:
+ tutorials:
- Your_Tutorial
```
diff --git a/_tutorials/design_features/Inc_Turbulent_Bend_Opt/Inc_Turbulent_Bend_Opt.md b/_tutorials/design_features/Inc_Turbulent_Bend_Opt/Inc_Turbulent_Bend_Opt.md
new file mode 100644
index 00000000..02679155
--- /dev/null
+++ b/_tutorials/design_features/Inc_Turbulent_Bend_Opt/Inc_Turbulent_Bend_Opt.md
@@ -0,0 +1,218 @@
+---
+title: Adjoint design optimization of a turbulent 3D pipe bend
+permalink: /tutorials/Inc_Turbulent_Bend_Opt/
+written_by: Nijso Beishuizen
+for_version: 8.0.1
+revised_by:
+revision_date:
+revised_version:
+solver: INC_RANS
+requires: SU2_CFD, FADO
+complexity: advanced
+follows: Inc_Turbulent_Bend
+---
+
+
+
+
+#### Figure (1): The 90 degree bend with the FFD box.
+
+
+## Goals
+
+This tutorial closely follows the design optimization setup of the 2D mixing channel, see the tutorial on design optimization for [Species Transport](/tutorials/Species_Transport/). We will use the python framework [FADO](https://github.com/su2code/FADO) to set up the optimization problem. In this tutorial however we will optimize the pressure drop of the 90 degree pipe bend. The CFD results were already discussed previously in [this tutorial](/tutorials/Inc_Turbulent_Bend/). Here we focus on the following aspects:
+* Setup of the FFD box for a 3D problem using SU2_DEF.
+* Setup of the FADO problem:
+ - using previous solutions of the CFD and adjoint solver to reduce computing time.
+ - automatically add the correct keywords for the FFD box (type and degrees of freedom).
+ - discussion of mesh quality issues and improvement using FFD constraints.
+* Presentation of the final setup and results.
+
+If you have not done so already, please first have a look at the prerequisite tutorials for a better understanding.
+
+## Prerequisites
+
+Besides the python library FADO, you will need to compile SU2 with automatic differentiation support. Note that the script provided uses 8 cores, so you need to compile with mpi support as well as enable autodiff:
+```
+./meson.py setup build --optimization=2 -Ddebug=false -Denable-autodiff=true -Dwith-mpi=enabled --prefix=/home/user/Codes/su2_github_develop/su2/
+```
+
+## Resources
+
+You can find the resources for this tutorial in the folder [design/Inc_Turbulent_Bend_Wallfunctions](https://github.com/su2code/Tutorials/tree/master/design/Inc_Turbulent_Bend_Wallfunctions) and the respective subfolders. Note that the setup used in this tutorial uses a pipe bend with a shorter pipe length before and after the bend to reduce the computing time. We have also merged all wall boundaries and all symmetry planes into one wall boundary and one symmetry plane. The gmsh file is provided in the repository so you can create your own pipe bend(s) with it.
+
+## 1. Basic setup of FFD box and FADO
+Usually, designs are created with a CAD tool. These designs are then discretized into a computational mesh for CFD analysis. When optimizing a design, we then only have the discretized mesh available. We could manipulate the mesh nodes directly but this does not lead to very smooth deformations. Instead we modify our mesh using FFD boxes. The nodes of the FFD box are moved according to the design sensitivities, and the mesh nodes inside the FFD box are then smoothly deformed using Bezier curves (default) or B-splines.
+Figure (1) above shows the setup that we will be using.
+
+### Creation of the FFD box
+The FFD box can be created and added to the .su2 mesh file using SU2_DEF. The important parameters to add to the configuration file are:
+
+```
+FFD_DEFINITION= (BOX, \
+-0.06, -0.009, -0.001, \
+ 0.209, -0.009, -0.001, \
+ 0.209, 0.060, -0.001, \
+-0.06, 0.060, -0.001, \
+-0.06, -0.009 ,0.27, \
+ 0.209 ,-0.009, 0.27, \
+ 0.209, 0.060, 0.27, \
+-0.06, 0.060, 0.27 )
+
+FFD_DEGREE= (5,5,5)
+DV_KIND= FFD_SETTING
+DV_MARKER= ( wall, symmetry)
+DV_PARAM= (1.0)
+```
+Our FFD box is 5x5x5 cells, or 6x6x6=216 nodes. With each 3 degrees of freedom for the x-,y- and z-direction, we get a total of 648 d.o.f. The box is slightly larger than our original bend, but most importantly the symmetry plane is completely inside the FFD box.
+We run the command
+
+```
+$ SU2_DEF sudo_0_add_FFD_box.cfg
+```
+
+We will only use the file *sudo_0_add_FFD_box.cfg* to create the FFD box. This command will create a new .su2 mesh called *mesh_out.su2* that has the definition of the FFD box added to the file. Note that at this stage we need to provide the boundaries inside the FFD box that are allowed to deform using the keyword **DV_MARKER**. The nodes on the boundaries inside the FFD box are part of the information that is added with the FFD box to the mesh_out.su2 mesh file.
+
+
+### Setup the FADO script optimization.py
+
+Previously the python script *set_ffd_design_var.py* was used in the tutorial on the optimization of the mixing channel. We can however create the correct entries with a couple of simple python commands and add them directly to the main python script that FADO will use, *optimization.py*. We already used *optimization.py* before in the tutorial [Species Transport](/tutorials/Species_Transport/) and we will highlight some changes here.
+
+For the optimization, we need to modify 2 things in our config file: **DV_KIND** and **DV_PARAM**. The keyword **DV_PARAM** contains N entries of the form *( BOX, 0, 0, 0, 1.0, 0.0, 0.0 );*
+ Note that the meaning of the entries are *( FFD_BoxTag, i_Ind, j_Ind, k_Ind, x_Disp, y_Disp, z_Disp )* , meaning that after the keyword **BOX**, we get the 3 indices i,j,k of the FFD box, followed by the allowed displacement of that index in the x-,y- and z-direction. Mesh nodes in the symmetry plane only move in the symmetry plane, so symmetry is preserved.
+
+The list of FFD control points can be created using:
+```python
+s = "FFD_CONTROL_POINT"
+ffd_string = s
+for i in range((DX**NDIM)*NDIM - 1):
+ ffd_string = ffd_string + ", " + s
+```
+In the sudo.cfg file we have a placeholder which has the form:
+```
+DV_KIND= __FFD_CTRL_PTS__
+```
+And we automatically replace the placeholder **\_\_FFD_CTRL_PTS\_\_** in the fado script during run-time using the command
+```
+replace_dv_kind = Parameter([ffd_string], LabelReplacer("__FFD_CTRL_PTS__"))
+```
+
+For the **DV_PARAM** string, we can use a similar piece of python code:
+
+```python
+dv_param_string=""
+for idim in range(NDIM):
+ xdim = ydim = zdim = "0.0"
+ if (idim==0): xdim="1.0"
+ elif (idim==1): ydim="1.0"
+ elif (idim==2): zdim="1.0"
+ for k in range(DX):
+ for j in range(DX):
+ for i in range(DX):
+ s = "( BOX, " + str(i) + ", " + str(j) + ", " + str(k) + ", " + xdim + ", " + ydim + ", " + zdim + " );"
+ dv_param_string += s
+```
+which is replaced using:
+```python
+replace_dv_param =Parameter([dv_param_string], LabelReplacer("__FFD_PARAM__"))
+```
+
+The only thing we need to take care of now is to define the correct number of FFD nodes DX=6 and the correct dimension of the problem, NDIM=3. You could even get these values from the .su2 mesh file if you want!
+
+In our config file sudo.cfg, we also use the following setting:
+```
+FFD_CONTINUITY= 1ST_DERIVATIVE
+```
+Which means that when the sides of the FFD box cuts through the mesh, then at the cut, we want the mesh deformation to stay first order continuous. If you do not do this, you might get sharp jumps in your mesh at the location of the intersection.
+
+Unfortunately, if we use this unconstrained setup, the mesh deformation will be as shown in Figure (2) below:
+
+
+#### Figure (2): The unconstrained deformation leads to mesh cells that have collapsed on the symmetry plane. This leads to convergence issues at the next design iteration.
+
+As you can see, the row of cells just above the symmetry plane has collapsed onto the symmetry plane, leading to a very bad mesh. In the next design iteration, the simulations do not converge anymore and the optimization procedure stops. So we need some additional constraints on the movement of the nodes of the FFD box.
+
+### constrained FFD deformation
+
+The problem here is that the mesh nodes on the symmetry plane are not allowed to move vertically, they only move horizontally outward inside the symmetry plane. Unfortunately, the FFD deformation is such that mesh nodes just above the symmetry plane are moved down, almost on the symmetry plane. To improve the quality of the mesh deformation, we disallow the vertical movement of the FFD box nodes on the nodes in the bottom plane of the FFD box, with j-index 0 and vertical displacement (0,1,0). In Figure (3), the plane with index j=0 is the bottom plane, indicated in yellow. So we remove entries in the **DV_PARAM** list of the form *(BOX, i_Ind, 0, k_Ind, 0,1,0)*. Additionally, we also disallow the vertical movement of the nodes in the plane j=1.
+Since we disallow vertical movement in 2x(6x6)=72 nodes in the planes with $$j=0$$ and $$j=1$$, The total degrees of freedom is then $$648 - 72 = 576$$ d.o.f.
+
+
+
+#### Figure (3): The 90 degree bend with the FFD box.
+
+
+The number of design variables needs to be reduced by 2x6x6 and we need to remove 2x6x6 strings from the ffd_string:
+```python
+nDV = nDV - 2*DX*DX
+ffd_string.replace(s+", ","",2*DX*DX)
+```
+
+Additionally, we need to remove the vertical movement of the nodes in the plane with j=[0,1]:
+
+```python
+jlist = [0,1]
+dof = "0.0, 1.0, 0.0"
+
+for j in jlist:
+ for k in range(DX):
+ for i in range(DX):
+ remove_dof = "( BOX, " + str(i) + ", " + str(j) + ", " + str(k) + ", " + dof + " )"
+ print("removing ", remove_dof)
+ dv_param_string = dv_param_string.replace(remove_dof+";", "", 1)
+ # in case the plane is at the end, the string does not have a semicolon
+ dv_param_string = dv_param_string.replace(remove_dof, "", 1)
+```
+
+Another modification to the configuration file that we would like to add is to restart from the solution of the previous design. SU2 will automatically interpolate the solution to the nearest neighbor if the mesh coordinates do not match. Since we might not have an initial solution to start with, we would like to switch from **RESTART= NO** to **RESTART= YES** after the first iteration.
+
+We can do this with a simple *sed* command that searches and replaces the string in config.cfg in the working directory and then copies the config file back to the base dir:
+
+```python
+restart_yes="sed -i 's/RESTART_SOL= NO/RESTART_SOL= YES/' config.cfg && cp " + configCopy + " ../../"
+```
+
+The easiest way to perform the update is to simply add it as another ExternalRun process:
+```python
+update_restart = ExternalRun("UPDATE_RESTART",restart_yes,False) # True means sym links are used for addData
+update_restart.addData(configCopy)
+```
+This means that we will call this function every design iteration, but only in the first design iteration will it have an effect.
+
+FADO copies the restart file and all other necessary files from the base directory (where you start your script) into the working directory. Here, the working directory is called *OPTIM*. Inside *OPTIM* we have subdirectories for the different runs, i.e. *OPTIM/DEFORM*, OPTIM/DIRECT*, *OPTIM/ADJOINT* and *OPTIM/DOT*. When all runs in this directory are done, they are archived in *DSN_001*, *DSN_002*, etc.
+
+So what we will do now is every time after we run the primal solver, we copy the restart file from the working directory *OPTIM/DIRECT* back to the base dir.
+
+```python
+cfd_command = "mpirun -n " + ncores + " " + su2_run + "SU2_CFD " + configMaster + "&& cp restart.csv ../../solution.csv"
+```
+
+Note that the primal solver by default saves the file restart.csv (keyword: **RESTART_FILENAME= restart**), but reads the file solution.csv (keyword: **SOLUTION_FILENAME= solution**). Note that we save ASCII files here, which is determined by the option **OUTPUT_FILES= RESTART_ASCII**. When reading ASCII restart files, we also need **READ_BINARY_RESTART= NO**.
+Please go through the *optimization.py* script now and check the settings. By default, the above procedure to restart from a previous solution is not active. You can activate it now if you wish.
+
+## 2. FADO optimized result
+
+We run the optimization script:
+
+```
+$ python optimization.py
+```
+
+We have set it to run 5 design iterations. Please note that the optimization was set up for a parallel run.
+
+The objective values for the 5 design iterations are given in the table below.
+
+
+| iteration | $$\Delta P$$, total| $$\Delta P$$, bend| gain, total| gain, bend |
+| --------|--------|--------|--------|--------|
+|0|89.0 [Pa]|20.7 [Pa]| -| - |
+|1|84.9 [Pa]|16.6 [Pa]|4.6 %|19.8 %|
+|2|82.1 [Pa]|13.8 [Pa]|7.8 %|33.3 %|
+|3|81.6 [Pa]|13.3 [Pa]|8.3 %|35.7 %|
+|4|79.9 [Pa]|11.6 [Pa]|10 %|44 %|
+
+
+We see that the global pressure drop between the inlet and the outlet reduces from 89 Pa to 80 Pa, a reduction of more than 10 %. However, since we are optimizing only the bend, we should subtract the pressure drop of the straight parts and only consider the pressure drop of the bend for a more fair comparison. In paraview, we can integrate the pressure in a 2D slice at the start and end of the bend. The pressure drop of the bend comes to $$\Delta P = 20.7 Pa$$. That means that the reduction of pressure drop in the bend is actually 44 % !
+
+
+#### Figure (4): Optimized bend after 5 design iterations, with the deformed FFD box.
diff --git a/_tutorials/design_features/Inviscid_3D_Constrained_ONERAM6/Inviscid_3D_Constrained_ONERAM6.md b/_tutorials/design_features/Inviscid_3D_Constrained_ONERAM6/Inviscid_3D_Constrained_ONERAM6.md
index 4e9f2d43..785f5011 100644
--- a/_tutorials/design_features/Inviscid_3D_Constrained_ONERAM6/Inviscid_3D_Constrained_ONERAM6.md
+++ b/_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.
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.
diff --git a/_tutorials/design_features/Multi_Objective_Shape_Design/Multi_Objective_Shape_Design.md b/_tutorials/design_features/Multi_Objective_Shape_Design/Multi_Objective_Shape_Design.md
index 8652806a..8fab8f2e 100644
--- a/_tutorials/design_features/Multi_Objective_Shape_Design/Multi_Objective_Shape_Design.md
+++ b/_tutorials/design_features/Multi_Objective_Shape_Design/Multi_Objective_Shape_Design.md
@@ -19,7 +19,7 @@ Upon completing this tutorial, the user will be familiar with setting up and run
- Constraints as penalty functions
- Combining objectives in the adjoint evaluation of the gradient to reduce computational cost.
-The intent of this tutorial is to introduce multi-objective, single-point optimization and explain how this can be implemented using SU2. This tutorial uses the same geometry and flow conditions as described in the inviscid supersonc wedge tutorial.
+The intent of this tutorial is to introduce multi-objective, single-point optimization and explain how this can be implemented using SU2. This tutorial uses the same geometry and flow conditions as described in the inviscid supersonic wedge tutorial.
The capabilities of combining multiple objectives and incorporating penalty functions into the adjoint formulation in SU2 are discussed further in section 3.4 of [this work](https://purl.stanford.edu/mm280hp6972).
@@ -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 -----------------------%
%
diff --git a/_tutorials/design_features/Species_Transport/Species_Transport.md b/_tutorials/design_features/Species_Transport/Species_Transport.md
new file mode 100644
index 00000000..10706f7d
--- /dev/null
+++ b/_tutorials/design_features/Species_Transport/Species_Transport.md
@@ -0,0 +1,315 @@
+---
+title: Unconstrained shape design of a two way mixing channel
+permalink: /tutorials/Species_Transport/
+written_by: TobiKattmann
+for_version: 7.2.1
+revised_by:
+revision_date:
+revised_version:
+solver: INC_RANS
+requires: SU2_CFD, FADO
+complexity: advanced
+follows: Inc_Species_Transport
+---
+
+## Disclaimer
+
+This Tutorial builds directly on the case given as Prerequisite on the top of the site [link](/tutorials/Inc_Species_Transport/). Therefore details to the problem setup, mesh, etc. are not repeated here. However the process outlined in this tutorial is directly applicable to many other cases using SU2.
+
+Instead of the python tools for finite differences or shape optimization that are part of SU2 directly, the standalone python tool [FADO](https://github.com/su2code/FADO) is used. Please follow the information on the given github repo in order to use FADO.
+
+## Goals
+
+This tutorial is a rather extensive guide covering the following steps, assuming a converging primal case is present:
+1. Validation of perfect restarts as a basis for the Discrete Adjoint solver (this is done using a separate bash-script). This section focuses on code development aspects, and may be skipped by general users.
+2. Setting up an FFD-box and writing it to the mesh
+3. Manual testing of the mesh deformation
+4. Gradient validation using FADO
+5. Shape optimization using FADO
+
+Following these steps proved to be especially useful when developing new features as each step is an incremental rise in complexity and is much easier to debug, compared starting right away with an optimization that then fails to provide satisfactory results.
+
+## Resources
+
+You can find the resources for this tutorial in the folder [incompressible_flow/Inc_Species_Transport](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport) and the respective subfolders.
+
+## 1. Restart Validation
+
+The script [restart_validation.sh](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport/restart_validation.sh) performs 4 simulations using `species3_venturiPrimitive.cfg` to check whether primal and primal-adjoint restarts work. This script is best used with `HISTORY_OUTPUT= RMS_RES` as then the output comparison is the most straight forward. The SU2 binary is deduced from the environmental variable `SU2_RUN`, so make sure that is set correctly. With the explanation given here and the comments in the script it should be straight forward adaptable to other cases.
+1. Primal simulation with n+1 timesteps. This is the ground truth of the expected residual values. Takes Residuals from the `history` file.
+2. Primal simulation with n timesteps. We will restart steps 3. and 4. from this simulation.
+3. Primal simulation with 1 timestep, restarted from simulation in 2nd step. Takes Residuals from the `history` file.
+4. Adjoint simulation with 1 timestep, using the primal restart file from simulation in 2nd step. The primal residuals that are printed in the screen output are taken for comparison.
+
+When using the recommended `HISTORY_OUTPUT= RMS_RES` the output should provide the following:
+```
+-5.010542647 -4.537626591 -4.207538398 0.4686163065 -6.594021422 0.4978738082 -5.253262361 -5.467591972
+-5.010542647 -4.537626591 -4.207538398 0.4686163065 -6.594021422 0.4978738082 -5.253262361 -5.467591972
+-5.010542647 -4.537626591 -4.207538398 0.4686163065 -6.594021422 0.4978738082 -5.253262361 -5.467591972
+```
+Where in each row the residual of each equation is listed (P, vx, vy, T, k, w, Species_0, Species_1). The primal restart (2nd row) and the adjoint primal restart (3rd row) provide identical results compared to the 'full' primal simulation (1st row). Small deviations in the last digits are not an issue, especially when higher iteration counts are used (here only 10). But if the adjoint restart provides a clearly different result then this should be debugged before attempting a gradient validation or even optimization.
+
+The config option `OUTPUT_PRECISION= 16` can be set to compare more digits if necessary.
+
+Execute the scipt by:
+```
+$ bash restart_validation.sh
+```
+
+## 2. FFD-Box Setup
+
+The setup is fairly simple when following some simple rules. The additional block of code necessary to write the FFD box is given below. Essentially, there are only 3 options (`FFD_DEFINITION`, `FFD_DEGREE` and `DV_MARKER`) where user input is necessary. `DV_KIND= FFD_SETTING` and `DV_PARAM= ( 1.0 )` are fixed and not to be changed.
+
+```
+% -------------------- FREE-FORM DEFORMATION PARAMETERS -----------------------%
+%
+% FFD box definition: 3D case (FFD_BoxTag, X1, Y1, Z1, X2, Y2, Z2, X3, Y3, Z3, X4, Y4, Z4,
+% X5, Y5, Z5, X6, Y6, Z6, X7, Y7, Z7, X8, Y8, Z8)
+% 2D case (FFD_BoxTag, X1, Y1, 0.0, X2, Y2, 0.0, X3, Y3, 0.0, X4, Y4, 0.0,
+% 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0)
+% Start at the lowest leftest corner and turn counter-clockwise
+FFD_DEFINITION= (BOX, \
+0.065, 0.01, 0.0, \
+0.15, 0.01, 0.0 \
+0.15, 0.02, 0.0, \
+0.065, 0.02, 0.0, \
+0.0, 0.0 ,0.0, \
+0.0 ,0.0, 0.0, \
+0.0, 0.0, 0.0, \
+0.0, 0.0, 0.0 )
+%
+% FFD box degree: 3D case (i_degree, j_degree, k_degree)
+% 2D case (i_degree, j_degree, 0)
+FFD_DEGREE= (6, 1, 0)
+%
+DV_KIND= FFD_SETTING
+%
+% Marker of the surface in which we are going apply the shape deformation
+% NOTE: for deformation the outlet should be a MARKER_SYM to hinder the mesh being ripped apart.
+DV_MARKER= ( wall )
+%
+% Parameters of the shape deformation
+% - FFD_SETTING ( 1.0 )
+% - FFD_CONTROL_POINT ( FFD_BoxTag, i_Ind, j_Ind, k_Ind, x_Disp, y_Disp, z_Disp )
+DV_PARAM= ( 1.0 )
+```
+
+`FFD_DEFINITION`: The first input to this option is the FFD-Box name. Here simply `BOX` was chosen. Following are the 4 (or 8 in 3D) corner points of the FFD box. The order of how the points are written is crucial. The FFD-box points are addressed via i-j-k indices and for keeping the minimum leftover sanity it of course is highly desirable to have these i-j-k indices align with the x-y-z cartesian axes. Or, in case the FFD box sides do not coincide with the cartesian axes, you know how the i-j-k indices work.
+Now assuming FFD-sides align with cartesian axes. The first point in `FFD_DEFINITION` has to be the corner point with the lowest x,y,z-value. The second point is the point following the x-axes only (i.e. keeping y and z constant). Like that the i-index coincides with the x-axes. The third point is found following the y-axes starting from the previous 2nd point (keeping x and z constant). The fourth point is the remaining on that z-constant plane. In 3D follow the first point in z-direction and repeat the process on the higher z-plane. In 2D the process can be explained simplified by: Start with the point with smallest x,y-value and turn counter-clockwise.
+
+`FFD_DEGREE`: Determines the number of FFD-Box points per i-j-k-index. The degree plus 1 gives the number of points used. Note: for ease of manual use it is highly recommended to start with a low amount here. Using more once the process is dialed in, is no problem.
+
+`DV_MARKER`: Boundary markers that are going to be deformed by the FFD-Box. Note that the Mesh deformation in SU2 is a 2-stage process:
+1. The FFD-Box deforms only the boundary mesh nodes that are inside of the initial FFD-Box. These nodes are stored at the bottom of the `.su2` mesh that contain the FFD-Box.
+2. The deformed boundary from the previous step is now boundary condition for a Linear Elasticity style volume mesh morpher.
+
+This FFD box is written to `MESH_OUT_FILENAME` by calling:
+```
+$ SU2_DEF .cfg
+```
+
+
+Figure (1): FFD-Box with fixed points (red) and allowed deformation direction indicated by arrows.
+
+## 3. Mesh deformation test
+
+Before attempting a gradient validation or optimization it is good practice to check whether the mesh deformation process creates valid and good quality meshes. It is also possible to already check reasonable preliminary bounds for FFD values, that can be set in an optimization. This can be done in a manual process which is rather simple.
+
+First, some general FFD-Box deformation parameters. Additions are `FFD_TOLERANCE`, `FFD_ITERATIONS` and `FFD_CONTINUITY` which was set to `USER_INPUT` in order to not fix any points at all. With that option one can manually fix FFD-Box points using `FFD_FIX_I`/`J`/`K` options but this process can also be done without that options as will be shown below.
+
+```
+% -------------------- FREE-FORM DEFORMATION PARAMETERS -----------------------%
+%
+% Tolerance of the Free-Form Deformation point inversion
+FFD_TOLERANCE= 1E-10
+%
+% Maximum number of iterations in the Free-Form Deformation point inversion
+FFD_ITERATIONS= 500
+%
+% FFD box definition: 3D case (FFD_BoxTag, X1, Y1, Z1, X2, Y2, Z2, X3, Y3, Z3, X4, Y4, Z4,
+% X5, Y5, Z5, X6, Y6, Z6, X7, Y7, Z7, X8, Y8, Z8)
+% 2D case (FFD_BoxTag, X1, Y1, 0.0, X2, Y2, 0.0, X3, Y3, 0.0, X4, Y4, 0.0,
+% 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0)
+% Start at the lowest leftest corner and turn counter-clockwise
+FFD_DEFINITION= (BOX, \
+0.065, 0.01, 0.0, \
+0.15, 0.01, 0.0 \
+0.15, 0.02, 0.0, \
+0.065, 0.02, 0.0, \
+0.0, 0.0 ,0.0, \
+0.0 ,0.0, 0.0, \
+0.0, 0.0, 0.0, \
+0.0, 0.0, 0.0 )
+%
+% FFD box degree: 3D case (i_degree, j_degree, k_degree)
+% 2D case (i_degree, j_degree, 0)
+FFD_DEGREE= (6, 1, 0)
+%
+% Surface grid continuity at the intersection with the faces of the FFD boxes.
+% To keep a particular level of surface continuity, SU2 automatically freezes the right
+% number of control point planes (NO_DERIVATIVE, 1ST_DERIVATIVE, 2ND_DERIVATIVE, USER_INPUT)
+FFD_CONTINUITY= USER_INPUT
+%
+% Definition of the FFD planes to be frozen in the FFD (x,y,z).
+% Value from 0 FFD degree in that direction. Pick a value larger than degree if you don't want to fix any plane.
+%FFD_FIX_I= (0,2,3)
+%FFD_FIX_J= (0,2,3)
+%FFD_FIX_K= (0,2,3)
+```
+
+The next set of option changes `DV_KIND`, `DV_PARAM` and `DV_VALUE` have to be specified for each Design Variable. So each of those options must have the same number of entries.
+
+For `DV_KIND` the tag `FFD_CONTROL_POINT_2D` is simply repeated 10 times.
+
+The `DV_PARAM` option lists, which of the FFD-Box points is going to be deformed and also the direction of deformation. So `(BOX, 2, 0, 0.0, 1.0)` refers to a point in the FFD-Box names `BOX` with the i-j-indices `2, 0` and will be deformed along the vector `0.0, 1.0` i.e. in y-direction. In 3D, this is of course extended by k-indices and the z-axis.
+The `DV_PARAM` list can either be created by hand or by editing the output of a helping script that ships with SU2 (same directory as `SU2_CFD` binary etc.):
+```
+$ python set_ffd_design_var.py -i 6 -j 1 -k 0 -b BOX -m 'wall' --dimension 2
+```
+which creates these list for the `FFD_CONTROL_POINT_2D`'s in x-y-z direction, but we are only interested in the y-direction.
+```
+% FFD_CONTROL_POINT_2D (Y)
+DEFINITION_DV= ( 19, 1.0 | wall | BOX, 0, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 1, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 2, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 3, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 4, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 5, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 6, 0, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 0, 1, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 1, 1, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 2, 1, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 3, 1, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 4, 1, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 5, 1, 0.0, 1.0 ); ( 19, 1.0 | wall | BOX, 6, 1, 0.0, 1.0 )
+```
+Now in order to get the `DV_PARAM` list simply the first part of each entry, namely `11, 1.0 | wall |` has to be deleted.
+Here the user can also fix certain Design variables by simply not using them in the lists. Note how in the given `DV_PARAM` the first point is `(BOX, 2, 0, 0, 0.0, 1.0, 0.0 )` instead of `(BOX, 0, 0, 0, 0.0, 1.0, 0.0 )`. Like so. The first two points with the lowest i-index are fixed.
+
+`DV_Value` simply gives the Deformation of the respective Design Variable. If in `DV_PARAM` only unit vectors are given as deformation direction (which is the case as we only use `0.0, 1.0, 0.0`) then `DV_VALUE` is the deflection in [m] and therefore some intuition can be used when choosing testing values.
+
+```
+% ----------------------- DESIGN VARIABLE PARAMETERS --------------------------%
+%
+DV_KIND= FFD_CONTROL_POINT_2D, FFD_CONTROL_POINT_2D, FFD_CONTROL_POINT_2D, FFD_CONTROL_POINT_2D, FFD_CONTROL_POINT_2D, FFD_CONTROL_POINT_2D, FFD_CONTROL_POINT_2D, FFD_CONTROL_POINT_2D, FFD_CONTROL_POINT_2D, FFD_CONTROL_POINT_2D
+%
+% Marker of the surface in which we are going apply the shape deformation
+% NOTE: for deformation the outlet should be a MARKER_SYM to hinder the mesh being ripped apart.
+DV_MARKER= ( wall )
+%
+% Parameters of the shape deformation
+% - FFD_SETTING ( 1.0 )
+% - FFD_CONTROL_POINT ( FFD_BoxTag, i_Ind, j_Ind, k_Ind, x_Disp, y_Disp, z_Disp )
+DV_PARAM= (BOX, 2, 0, 0.0, 1.0); (BOX, 3, 0, 0.0, 1.0); (BOX, 4, 0, 0.0, 1.0); (BOX, 5, 0, 0.0, 1.0); (BOX, 6, 0, 0.0, 1.0); (BOX, 2, 1, 0.0, 1.0); (BOX, 3, 1, 0.0, 1.0); (BOX, 4, 1, 0.0, 1.0); (BOX, 5, 1, 0.0, 1.0); (BOX, 6, 1, 0.0, 1.0)
+% Excluded FFD points that are fixed to keep a nice geometry and mesh
+%DV_PARAM= (BOX, 0, 0, 0.0, 1.0); (BOX, 1, 0, 0.0, 1.0); (BOX, 0, 1, 0.0, 1.0); (BOX, 1, 1, 0.0, 1.0);
+%
+% Value of the shape deformation
+% first row: lower row y-direction
+% second row: upper row y-direction
+DV_VALUE= 0.003, 0.003, 0.004, 0.005, 0.005, \
+ 0.003, 0.003, 0.004, 0.005, 0.005
+```
+
+The most important options for the volume mesh algorithm are listed below. This tutorial does not go in depth on these options.
+
+```
+% ------------------------ GRID DEFORMATION PARAMETERS ------------------------%
+%
+% Linear solver or smoother for implicit formulations (FGMRES, RESTARTED_FGMRES, BCGSTAB)
+DEFORM_LINEAR_SOLVER= FGMRES
+%
+% Preconditioner of the Krylov linear solver (ILU, LU_SGS, JACOBI)
+DEFORM_LINEAR_SOLVER_PREC= ILU
+%
+% Number of smoothing iterations for mesh deformation
+DEFORM_LINEAR_SOLVER_ITER= 1000
+%
+% Number of nonlinear deformation iterations (surface deformation increments)
+DEFORM_NONLINEAR_ITER= 1
+%
+% Minimum residual criteria for the linear solver convergence of grid deformation
+DEFORM_LINEAR_SOLVER_ERROR= 1E-14
+%
+% Print the residuals during mesh deformation to the console (YES, NO)
+DEFORM_CONSOLE_OUTPUT= YES
+%
+% Deformation coefficient (linear elasticity limits from -1.0 to 0.5, a larger
+% value is also possible)
+DEFORM_COEFF = 0.0
+%
+% Type of element stiffness imposed for FEA mesh deformation (INVERSE_VOLUME,
+% WALL_DISTANCE, CONSTANT_STIFFNESS)
+DEFORM_STIFFNESS_TYPE= WALL_DISTANCE
+%
+% Deform the grid only close to the surface. It is possible to specify how much
+% of the volumetric grid is going to be deformed in meters or inches (1E6 by default)
+DEFORM_LIMIT = 1E6
+```
+
+This mesh deformation is executed via:
+```
+$ SU2_DEF .cfg
+```
+
+In this special case the deformed produces a bad mesh at the outlet, as the mesh is 'ripped apart' there. This happens because the FFD-Box only deforms what is prescribed in `DV_MARKER` and the remaining boundaries are considered 'clamped' in the volume mesh algorithm. All boundaries? No! The boundaries in `MARKER_SYM` are allowed to move along their symmetry plane in the volume mesher.This obviously requires the boundary to form a single plane which is the case for the present outlet. So, if the outlet is prescribed as a `MARKER_SYM` for the Volume deformation step the mesh deformation will yield a reasonable mesh.
+
+After the mesh deformation it is advisable to also run a primal simulation on that deformed mesh, as the simulation settings (e.g. `CFL_NUMBER`) might not lead to a converging simulation anymore. For a later optimization run this testing can help keeping a converging primal through all deformations.
+
+
+Figure (2): Mesh breaks at the `outlet`, as `outlet` nodes are clamped.
+
+
+Figure (3): Defining the `outlet` as `MARKER_SYM` results in a satisfactory deformed mesh.
+
+## 4. Gradient Validation
+
+In the gradient validation the Discrete Adjoint gradient is compared against a Finite Difference gradient. The script `gradient_validation.py` is using FADO, so please make yourself familiar with the tutorials in that respective repository. But with the comments in the file and observing the output it is possible to reverse engineer many aspects.
+
+Notable here is that, first, all deformed primal computations are done and the baseline at the very end. This is done as the discrete adjoint requires the solution of the baseline mesh, so that is done right before computing the discrete adjoint gradient.
+The `MARKER_SYM`-trick that was introduced in the mesh-deformation section is also applied here and also in the `SU2_DOT_AD` step. This is required to stay consistent between the mesh deformation execution and the gradient projection.
+
+The Objective Function used is `SURFACE_SPECIES_VARIANCE` and, as the name suggests, sums the local differences in the species mass fraction against the mean, and can therefore be used as a measure for uniform mixing. A Variance of zero would indicate perfect mixing.
+
+The gradient validation script is executed via:
+```
+$ python gradient_validation.py
+```
+
+In order to postprocess the results a python script is added which compares both gradients and prints to screen and file:
+```
+$ python postprocess.py
+```
+
+At a maximum of ~0.05% relative difference between the discrete adjoint and finite difference gradient,the agreement is excellent.
+```
++---+-------------------+-------------------+-------------------+-------------------+
+| # | DA gradient | FD gradient | absolute diff | relative diff [%] |
++---+-------------------+-------------------+-------------------+-------------------+
+| 0 | -0.0031128563 | -0.0031137331 | 0.0000008768 | 0.0281680151 |
+| 1 | -0.0005406673 | -0.0005409528 | 0.0000002856 | 0.0528178961 |
+| 2 | 0.0011094759 | 0.0011093871 | 0.0000000888 | 0.0080034781 |
+| 3 | 0.0017487956 | 0.0017487712 | 0.0000000245 | 0.0014009004 |
+| 4 | 0.0017256761 | 0.0017256695 | 0.0000000066 | 0.0003839967 |
+| 5 | -0.0031128563 | -0.0031137331 | 0.0000008769 | 0.0281689729 |
+| 6 | -0.0005406673 | -0.0005409528 | 0.0000002855 | 0.0528118802 |
+| 7 | 0.0011094759 | 0.0011093871 | 0.0000000888 | 0.0080064097 |
+| 8 | 0.0017487956 | 0.0017487711 | 0.0000000246 | 0.0014043103 |
+| 9 | 0.0017256761 | 0.0017256695 | 0.0000000066 | 0.0003847820 |
++---+-------------------+-------------------+-------------------+-------------------+
+```
+
+## 5. Optimization
+
+The setup of a shape optimization with FADO is rather straight forward once a working gradient validation script is available. It is usually a good idea to add lower and upper bounds to the design variables. In the case of FFD-Box points these values translate directly into the cartesian space and a first estimation can be made intuitively.
+
+The second notable extension to the gradient validation is of course the optimization setup itself. Please follow the tutorials FADO provides to learn more about the capabilities and options. But, in the provided script some additional explanations are given and more details to certain function can be printed to screen by adding e.g. `printDocumentation(driver.setFailureMode)` to the script if more information for that option are required.
+
+The optimization method used is [SLSQP](https://docs.scipy.org/doc/scipy/reference/optimize.minimize-slsqp.html) from the [SciPy](https://docs.scipy.org/doc/scipy/index.html) library.
+
+The unconstrained optimization with the objective function of `SURFACE_SPECIES_VARIANCE` (as in the gradient validation introduced) is started with the following command:
+```
+$ python optimization.py
+```
+
+In order to compute the gradient norms of each Design iteration a `gradient_norm.py` script was added. The script will write a `gradient_norm.csv` into the folder root which.
+
+A helpful visualization after an optimization run is having the series of deformed meshes with their primal solution and FFD-Boxes. These solution are in their respective folders and one could tediously load every single one of them.
+The script `create_Visu_symlinks.py` sweeps through the `DSN_*` folders and collects symbolic links of the primal solution and FFD-Boxes into a `visu_files` folder. The symbolic links also renames each file and appends an iteration number to the end of the filename (e.g. `ffd_004.vtk -> ../DSN_004/DEFORM/ffd_boxes_def_0.vtk`). Like so, this data can be loaded in [Paraview](https://www.paraview.org/), or probably any other post-processor, as a time series which allows for easy cycling through the designs.
+
+
+Figure (4): Objective Function value and Gradient Norm over optimizer iterations. Capped after 12 iterations.
+
+
+Figure (5): Baseline and Optimized Mesh with the respective FFD-Boxes.
+
+
+Figure (6): Optimization series from baseline to final mesh with FFD-Boxes.
diff --git a/_tutorials/design_features/Unsteady_Shape_Opt_NACA0012/Unsteady_Shape_Opt_NACA0012.md b/_tutorials/design_features/Unsteady_Shape_Opt_NACA0012/Unsteady_Shape_Opt_NACA0012.md
index 1938d3c0..9750fba9 100644
--- a/_tutorials/design_features/Unsteady_Shape_Opt_NACA0012/Unsteady_Shape_Opt_NACA0012.md
+++ b/_tutorials/design_features/Unsteady_Shape_Opt_NACA0012/Unsteady_Shape_Opt_NACA0012.md
@@ -27,7 +27,6 @@ Consequently, the following capabilities of SU2 will be showcased in this tutori
- Windowed sensitivity calculation
- Unsteady adjoints
- Unsteady Optimization
-- Code parallelism
This tutorial uses the windowing techniques explained in [here](../Unsteady_NACA0012), to compute meaningful optimization objectives.
Hence it is recommended to read that tutorial first.
@@ -42,6 +41,8 @@ in the [project website repository](https://github.com/su2code/Tutorials).
You will need the configuration file ([unsteady_naca0012_opt.cfg](https://github.com/su2code/Tutorials/tree/master/design/Unsteady_Shape_Opt_NACA0012/unsteady_naca0012_opt.cfg)) and
the mesh file ([unsteady_naca0012_FFD.su2](https://github.com/su2code/Tutorials/tree/master/design/Unsteady_Shape_Opt_NACA0012/unsteady_naca0012_FFD.su2)).
+The used mesh already contains an FFD-Box. For more information on how to set up an FFD-Box on your own, please follow [this tutorial](/tutorials/Species_Transport/).
+
## Tutorial ##
The following tutorial will walk you through the steps required when performing a shape optimization of the NACA0012 airfoil using SU2.
@@ -51,7 +52,7 @@ If you have yet to complete these requirements, please see the [Download](/docs_
### Background ###
-This test case is for the NACA0012 airfoil in viscous unsteady flow. The NACA airfoils are two dimensional shapes for aircraft wings developed by the National Advisory Committee for Aeronautics (NACA, 1915-1958, predeccessor of NASA). The NACA-4-Digit series is a set of 78 airfoil configurations which were created for wind-tunnel tests to explore the effect of different airfoil shapes on aerdynamic coefficients as drag or lift.
+This test case is for the NACA0012 airfoil in viscous unsteady flow. The NACA airfoils are two dimensional shapes for aircraft wings developed by the National Advisory Committee for Aeronautics (NACA, 1915-1958, predecessor of NASA). The NACA-4-Digit series is a set of 78 airfoil configurations which were created for wind-tunnel tests to explore the effect of different airfoil shapes on aerodynamic coefficients as drag or lift.
### Mesh Description ###
@@ -129,7 +130,7 @@ TIME_DOMAIN = YES
TIME_MARCHING= DUAL_TIME_STEPPING-2ND_ORDER
%
% Time Step for dual time stepping simulations (s)
-TIME_STEP= 5e-3
+TIME_STEP= 5e-4
%
% Maximum Number of physical time steps.
TIME_ITER= 2200
diff --git a/_tutorials/incompressible_flow/Inc_Combustion/Inc_Combustion.md b/_tutorials/incompressible_flow/Inc_Combustion/Inc_Combustion.md
new file mode 100644
index 00000000..81001ecf
--- /dev/null
+++ b/_tutorials/incompressible_flow/Inc_Combustion/Inc_Combustion.md
@@ -0,0 +1,453 @@
+---
+title: "Incompressible, Laminar Combustion Simulation"
+permalink: "/tutorials/Inc_Combustion/"
+written_by: EvertBunschoten
+for_version: 8.1.0
+revised_by: EvertBunschoten
+revision_date: 04-10-2024
+revised_version: 8.1.0
+solver: INC_NAVIER_STOKES
+requires: SU2_CFD, mlpcpp
+complexity: advanced
+follows:
+---
+
+
+## Goals
+
+Version 8.0.0 of SU2 supports the simulation of reduced-order combustion simulations. In particular, flamelet-generated manifold (FGM) simulations. The FGM solver in SU2 computes the transport of a set of controlling variables. These are used to interpolate a manifold of detailed-chemistry flamelet data to retrieve the thermo-chemical state of the mixture, and reaction source terms. This capability can be used to solve 2D and 3D, laminar, (partially) premixed, direct and adjoint simulations with heat loss and modeling of differential diffusion effects. The latter is relevant specifically lean hydrogen flames. This tutorial describes how to set up a premixed hydrogen combustion simulation case. Additionally, information is provided regarding the governing equations and preferential diffusion model. Finally, the relevant options in the configuration file regarding the SU2 FGM solver are discussed.
+
+## Resources and Prerequisites
+
+The resources for this tutorial can be found in the [incompressible_flow/Inc_Combustion/1__premixed_hydrogen](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Combustion/1__premixed_hydrogen) directory in the [tutorial repository](https://github.com/su2code/Tutorials). You will need the following files:
+1. *Configuration file*: The configuration file for this case is named [H2_burner.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Combustion/1__premixed_hydrogen/H2_burner.cfg).
+2. *Mesh file*: The geometry for this test case is a simple, 2D burner geometry with a cooled burner plate ([H2_Burner.su2](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Combustion/1__premixed_hydrogen/H2_burner.su2)).
+3. *Manifold files*: The working principle of the FGM method is the manifold containing the flamelet data. From this manifold, thermo-chemical and reaction source term information is retrieved during the simulation. SU2 supports the use of 2D and 3D look-up tables (LUT), as well as multi-layer perceptrons (MLP). In the current tutorial, MLP's will be utilized. These files have the `.mlp` extension. Evaluating MLP's in SU2 is done through the `MLPCpp` sub-module. Make sure you configure SU2 with the flag `-Denable-mlpcpp=true` to clone this submodule.
+
+The mesh is created using [gmsh](https://gmsh.info/) and a respective `.geo` script is available to recreate/modify the mesh [H2_Burner.geo](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Combustion/1__premixed_hydrogen/H2_burner.geo). The mesh is unstructured (i.e. only contains triangular elements) with 70495 elements and 35926 points. This mesh is quite large, but a high resolution is required in order to resolve the flame front.
+
+
+Figure (1): Computational mesh with color indication of the used boundary conditions.
+
+The MLP files describe five architectures. These are used to predict the thermo-chemical state, preferential diffusion scalars, and reaction source terms.
+
+
+## Prerequisites
+
+The following tutorial assumes you already compiled `SU2_CFD` in serial or parallel, please see the [Download](/docs_v8/Download/) and [Installation](/docs_v8/Installation/) if that is not done yet. Additionally it is advised to perform an entry level incompressible tutorial first, as this tutorial only goes over species transport with combustion.
+
+## Background
+
+The SU2 FGM solver solves two sets of transport equations: FGM controlling variables and optionally passive species. The solver supports up to three controlling variables, those representing the progress variable $$(\mathcal{Y})$$, total enthalpy ($$h$$), and optionally mixture fraction $$(Z)$$. The controlling variables are used as inputs to the flamelet data manifold to extract the thermo-chemical state variables and reaction source terms. The passive species $$(Y_j)$$ represent species of interest such as emissions. The solutions of the passive species distribution do not affect the behavior of the controlling variables, but can be used to define custom outputs and objective functions. The solution process is visualized in the [solution process](#solutionprocess).
+
+
+
+The `CSpeciesSolver` object in SU2 solves the controlling variables and passive species transport equations. These come in three variations, depending on the problem set-up and reactants:
+
+1. pre-mixed, no preferential diffusion:
+
+$$
+\begin{equation}
+ \frac{\partial \rho \mathcal{Y}}{\partial t} + \nabla\cdot(\rho\vec{u}\mathcal{Y}) - \nabla\cdot\left(\rho D\nabla\mathcal{Y}\right) = \dot{\omega}_\mathcal{Y}
+\end{equation}
+$$
+
+$$
+\begin{equation}
+ \frac{\partial \rho h}{\partial t} + \nabla\cdot(\rho\vec{u} h) - \nabla\cdot\left(\rho D\nabla h\right) = 0
+\end{equation}
+$$
+
+$$
+\begin{equation}
+ \frac{\partial \rho Y_j}{\partial t} + \nabla\cdot(\rho\vec{u}Y_j) - \nabla\cdot\left(\rho D\nabla Y_j\right) = \dot{\omega}^+ + \dot{\omega}^- Y_j
+\end{equation}
+$$
+
+2. partially or non-premixed, no preferential diffusion:
+
+$$
+\begin{equation}
+ \frac{\partial \rho \mathcal{Y}}{\partial t} + \nabla\cdot(\rho\vec{u}\mathcal{Y}) - \nabla\cdot\left(\rho D\nabla\mathcal{Y}\right) = \dot{\omega}_\mathcal{Y}
+\end{equation}
+$$
+
+$$
+\begin{equation}
+ \frac{\partial \rho h}{\partial t} + \nabla\cdot(\rho\vec{u} h) - \nabla\cdot\left(\rho D\nabla h\right) = 0
+\end{equation}
+$$
+
+$$
+\begin{equation}
+ \frac{\partial \rho Z}{\partial t} + \nabla\cdot(\rho\vec{u}Z) - \nabla\cdot\left(\rho D\nabla Z\right) = \dot{\omega}_\mathcal{Y}
+\end{equation}
+$$
+
+$$
+\begin{equation}
+ \frac{\partial \rho Y_j}{\partial t} + \nabla\cdot(\rho\vec{u}Y_j) - \nabla\cdot\left(\rho D\nabla Y_j\right) = \dot{\omega}^+ + \dot{\omega}^- Y_j
+\end{equation}
+$$
+
+3. pre-mixed, partially pre-mixed, non-premixed, with preferential diffusion:
+
+$$
+\begin{equation}
+ \frac{\partial \rho \mathcal{Y}}{\partial t} + \nabla\cdot(\rho\vec{u}\mathcal{Y}) - \nabla\cdot\left(\rho D\nabla\beta_\mathcal{Y}\right) = \dot{\omega}_\mathcal{Y}
+\end{equation}
+$$
+
+$$
+\begin{equation}
+ \frac{\partial \rho h}{\partial t} + \nabla\cdot(\rho\vec{u} h) - \nabla\cdot\left(\beta_{h,1}\nabla T + \rho D\nabla\beta_{h,2}\right) = 0
+\end{equation}
+$$
+
+$$
+\begin{equation}
+ \frac{\partial \rho Z}{\partial t} + \nabla\cdot(\rho\vec{u}Z) - \nabla\cdot\left(\rho D\nabla\beta_Z\right) = 0
+\end{equation}
+$$
+
+$$
+\begin{equation}
+ \frac{\partial \rho Y_j}{\partial t} + \nabla\cdot(\rho\vec{u}Y_j) - \nabla\cdot\left(\rho D\nabla Y_j\right) = \dot{\omega}^+ + \dot{\omega}^- Y_j
+\end{equation}
+$$
+
+Here, $D$ is the diffusion coefficient in $$m^2s^{-1}$$, $$\rho\dot{\omega}_\mathcal{Y}$$ the progress variable source term in $$kg m^{-3} s^{-1}$$, and $$\rho\dot{\omega}^+$$ and $$\rho\dot{\omega}^-$$ the passive species production and consumption rates respectively. The $$\beta-$$ terms on the left hand side of equations 8-10 are used to model preferential diffusion. These are discussed in more detail in the section describing the preferential diffusion model.
+
+
+The test case covered in this tutorial represents a simplified version of a two-dimensional, pre-mixed hydrogen burner with preferential diffusion and a heat exchanger emulator suspended in the hot exhaust. The purpose of this test case is to demonstrate the capabilities of the SU2 FGM solver (differential diffusion, heat loss), not a solution for a realistic hydrogen combustion problem.
+
+
+## Problem Setup
+
+In order to run a FGM simulation in SU2, an additional set-up step apart from defining the mesh and configuration file is required. This step involves the definition of a flamelet data manifold which includes the necessary data required by SU2 to include the relevant phenomena. This section describes the two manifold formats supported by SU2 for FGM simulations, as well as an example of the set-up of the manifold used in the current tutorial. One of the key features in accurately modeling (lean) hydrogen combustion is the modeling of the effects of preferential diffusion. The preferential diffusion model currently implemented in SU2 is the model formulated by [Nithin et al](https://doi.org/10.1080/13647830.2021.1970232). This section briefly summarizes this model and how to enable it in SU2 FGM simulations. Finally, this section describes the boundary and initial condition of the current test case, as well as the methodologies available to ignite the mixture.
+
+### Manifold set-up
+
+During FGM simulations, thermo-chemical, as well as reaction data is interpolated from a manifold of detailed-chemistry flamelet data based on a set of controlling variables. In SU2, two types of manifold are supported: two or three-dimensional look-up tables (LUT) and feed-forward, dense, multi-layer perceptrons (MLP).
+
+The flamelet fluid model in SU2 requires thermo-chemical and scalar source term data from the manifold to function. First the manifold should have the controlling variable names as input variables in with the corresponding units:
+
+1. Progress variable ($$\mathcal{Y}$$)[-]
+2. Total enthalpy ($$h$$)[J kg^-1]
+3. optional: mixture fraction ($$Z$$)[-]
+
+In the current tutorial, the following progress variable definition is used:
+
+$$
+\begin{split}
+\mathcal{Y} = -7.36Y_{H_2}-23.01Y_H-2.04Y_{O_2}-4.8Y_O\\+1.83Y_{H_2O}
+-15.31Y_{OH}-57.02Y_{H_2O_2}+24.55Y_{HO_2}
+\end{split}
+$$
+
+The manifold should also contain the following thermo-chemical data. The variable name in the manifold should correspond to the bracketed term and be stored in the corresponding units.
+1. Temperature (`Temperature`)[K]
+2. Specific heat (`Cp`)[J kg^-1 K^-1]
+3. Dynamic viscosity (`ViscosityDyn`)[]
+4. Thermal conductivity (`Conductivity`)[W m^-1 K^-1]
+5. Diffusivity (`DiffusionCoefficient`)[m^2 s^-1]
+6. Density (`Density`) [kg m^-3] or mixture molar weight (`MolarWeightMix`) [kg mol^-1]
+
+The distinction between storing the fluid density or molar weight depends on the configuration file setting for `INC_DENSITY_MODEL`. MOre on that the section on configuration file settings.
+
+Finally, the manifold should contain the source terms for the progress variable and optionally passive species.
+
+1. Progress variable source term [kg m^-3 s^-1]
+2. Optionally: Passive species production and consumption terms [kg m^-3 s^-1]
+
+The manifold may contain more data for passive look-up purposes. If these are not defined, they will be ignored during the SU2 FGM solution process.
+
+The two manifold formats currently supported in SU2 are the unstructured look-up table and dense, feed-forward multi-layer perceptron.
+The look-up table format supported in SU2 is based around the two-dimensional, trapezoidal map approach. The table file format should be in the dragon file format. For pre-mixed problems without differential diffusion (e.g. pre-mixed methane problems), a two-dimensional table is sufficient. An example of such a table can be found in the [methane combustion test case](https://github.com/su2code/TestCases/tree/master/flamelet/01_laminar_premixed_ch4_flame_cfd/fgm_ch4.drg). The two table dimensions should span the progress variable and total enthalpy dimension.
+
+For partially- or non-premixed problems or pre-mixed problems with preferential diffusion, a three-dimensional table is required. SU2 supports a quasi-3D table format, consisting of two-dimensonal trapezoidal maps stacked in the third dimension. An example of this can be found in the [partially premixed methane combustion test case](https://github.com/su2code/TestCases/tree/master/flamelet/06_laminar_partial_premixed_ch4_flame_cfd/LUT_methane_3D.drg). The first two dimensions should span the progress variable and total enthalpy dimension, while the third dimension should be mixture fraction.
+
+
+
+### Preferential diffusion model
+
+Pre-mixed combustion of reactants with high hydrogen content at lean conditions undergo a phenomenon called preferential diffusion. Here, the hydrogen diffuses differently from the other species in the mixture, causing local variations in mixture fraction and inherent instabilities in the flame front, even during laminar flow. Accurately modeling preferential diffusion is therefore crucial to capturing the behavior of pre-mixed hydrogen flames. The modeling of preferential diffusion is supported in SU2 through the [Efimov model](https://doi.org/10.1080/13647830.2021.1970232). When solving hydrogen FGM problems, SU2 solves the following transport equations for the controlling variables:
+
+$$
+\begin{equation}
+ \frac{\partial \rho \mathcal{Y}}{\partial t} + \nabla\cdot(\rho\vec{u}\mathcal{Y}) - \nabla\cdot\left(D\nabla\beta_\mathcal{Y}\right) = \dot{\omega}_\mathcal{Y}
+\end{equation}
+$$
+
+$$
+\begin{equation}
+ \frac{\partial \rho h}{\partial t} + \nabla\cdot(\rho\vec{u} h) - \nabla\cdot\left(\beta_{h,1}\nabla T + D\nabla\beta_{h,2}\right) = 0
+\end{equation}
+$$
+
+$$
+\begin{equation}
+ \frac{\partial \rho Z}{\partial t} + \nabla\cdot(\rho\vec{u}Z) - \nabla\cdot\left(D\nabla\beta_Z\right) = 0
+\end{equation}
+$$
+
+Here, $$\mathcal{Y},h$$ and $$Z$$ are the progress variable, total enthalpy, and mixture fraction respectively. Preferential diffusion is modeled through the $$\beta$$-terms in the third term on the left hand side of equations 2-4. [The following work](https://doi.org/10.1080/13647830.2021.1970232) contains details on the definitions of these scalars.
+Within the manifold, these scalars shall be named as follows:
+
+1. $$\beta_\mathcal{Y}$$ (`Beta_ProgVar`)[-]
+2. $$\beta_{h,1}$$ (`Beta_Enth_Thermal`)[J kg^-1 K^-1]
+3. $$\beta_{h,2}$$ (`Beta_Enth`)[J kg^-1]
+4. $$\beta_Z$$ (`Beta_MixFrac`)[-]
+
+If not all the $$\beta$$- terms are detected, while preferential diffusion is enabled, an error will be raised. During the initialization of the fluid model, a message will be displayed in the terminal indicating whether the preferential diffusion model is enabled.
+
+## Configuration File Options
+
+The SU2 FGM solver is enabled through the options in the configuration file. In this section, the key settings are discussed, as well as recommended settings for specific problems. All available options concerning the FGM solver are listed below as they occur in the [config_template.cfg](https://github.com/su2code/SU2/blob/master/config_template.cfg).
+
+### Enabling Flamelet Fluid Model
+The SU2 FGM solver is enabled by setting `FLUID_MODEL=FLUID_FLAMELET`. This option results in the `CFluidFlamelet` class to be used as the fluid model during the simulation. Using the `FLUID_FLAMELET` option requires the options for `KIND_SCALAR_MODEL`, `DIFFUSIVITY_MODEL`, `VISCOSITY_MODEL`, and `CONDUCTIVITY_MODEL` to be set to `FLAMELET` as well. For the `INC_DENSITY_MODEL`, there are two options. By setting `INC_DENSITY_MODEL=VARIABLE`, the local density is calculated through the ideal gas law.
+
+$$
+\begin{equation}
+\rho=\frac{pW_M}{R_uT}
+\end{equation}
+$$
+
+where $$p$$ is the free-stream pressure, $$R_u$$ the universal gas constant, and $$W_M$$ and $$T$$ the mean molecular weight and temperature respectively, which are obtained from the manifold. Finally, the option for `INC_ENERGY_EQUATION` should be set to `YES` when solving FGM problems. In order to enable preferential
+diffusion, set the option `PREFERENTIAL_DIFFUSION` to `YES` (set by default to `NO`).
+
+In the current example for the hydrogen burner, the following options are used:
+```
+FLUID_MODEL= FLUID_FLAMELET
+KIND_SCALAR_MODEL= FLAMELET
+DIFFUSIVITY_MODEL= FLAMELET
+PREFERENTIAL_DIFFUSION= YES
+VISCOSITY_MODEL= FLAMELET
+CONDUCTIVITY_MODEL= FLAMELET
+INC_DENSITY_MODEL= VARIABLE
+INC_ENERGY_EQUATION = YES
+```
+### Controlling variable definition
+
+The names of the controlling variables can be defined by the user through `CONTROLLING_VARIABLE_NAMES`. At least two names are required, corresponding to the progress variable and total enthalpy respectively. When a third is provided, it will be interpreted as the mixture fraction.
+
+The names of the controlling variable source terms may be defined through the option `CONTROLLING_VARIABLE_SOURCE_NAMES`. The length of this array should correspond to that defined under `CONTROLLING_VARIABLE_NAMES`. In case no source terms are required for certain controlling variables (e.g. total enthalpy and/or mixture fraction), the corresponding term may be set to `NULL`. The controlling variable source terms can be included in the volume output by including `SOURCE` in the `VOLUME_OUTPUT`.
+
+It is also possible to define convergence criteria based on the controlling variables through the `CONV_FIELD` option. Here, include `RMS_` where `` is the name of the controlling variable as defined under `CONTROLLING_VARIABLE_NAMES`.
+
+In the current example, the controlling variables and their respective sources are defined as
+```
+CONTROLLING_VARIABLE_NAMES=(ProgressVariable,EnthalpyTot,MixtureFraction)
+CONTROLLING_VARIABLE_SOURCE_NAMES=(ProdRateTot_PV,NULL,NULL)
+```
+corresponding to the progress variable, total enthalpy, and mixture fraction respectively.
+
+### Manifold options
+
+The manifold format is defined through the option `INTERPOLATION_METHOD` (same as for using the data-driven fluid model), for which the options `LUT` and `MLP` are supported, corresponding to using a look-up table and one or more multi-layer perceptrons respectively.
+
+The file name(s) corresponding to the files describing the manifold are to be listed under `FILENAMES_INTERPOLATOR`. When using the `LUT` option for `INTERPOLATION_METHOD`, only one `.drg` file is required, while multiple files may be listed when using the `MLP` option. Any number of `.mlp` files may be provided, as long as they have the controlling variable names as their input variables and collectively are able to predict the required quantities. When using the `MLP` option, make sure one `.mlp` file is included which p`SU2` will raise an error if certain required variables are not present in the manifold.
+
+The table format supported under the option `LUT` allows for the interpolation of 2D or 3D unstructured data. The algorithm used by the table is a simplified version of the trapezoidal map to perform 2D queries on unstructured data. The query algorithm is described in detail in section 6.1 of [Computational Geometry: Algorithms and Applications by de Berg et. al.](https://link.springer.com/book/10.1007/978-3-540-77974-2). In order to perform 3D queries, the table shall be constructed of multiple, 2D trapezoidal maps, stacked in the third dimension. Interpolation is performed through identifying the nearest two table levels, performing a 2D query on each, and linearly interpolating the final result along the third dimension. For FGM purposes, the x- and y-dimension of the table are assumed to be the progress variable and total enthalpy respectively. In the case of simulations involving mixing and/or preferential diffusion, the third table dimension is assumed to be the mixture fraction.
+Examples of such 2D and 3D tables can be found in the `SU2` [unit tests](https://github.com/su2code/SU2/tree/master/UnitTests/Common/containers/) or [test cases](https://github.com/su2code/TestCases/tree/master/flamelet/01_laminar_premixed_ch4_flame_cfd).
+
+
+The artificial neural network type supported under the option `MLP` is the dense, feed-forward multi-layer perceptron. For FGM simulations, one or multiple MLP's can be loaded, over which the required flamelet manifold variables should be distributed. This offers the benefit of being able to use different MLP architectures for different data. `SU2` uses the [MLPCpp module](https://github.com/EvertBunschoten/MLPCpp.git) to evaluate MLP's during simulations. After training MLP architectures on flamelet data, it is possible to load these into `SU2` by storing the architecture, weights, biases, and activation function information in the supported `.mlp` format. Information on how to translate networks trained through TensorFlow to the `.mlp` format, see the [MLPCpp repository](https://github.com/EvertBunschoten/MLPCpp.git). Examples of such MLP files can be found in the `SU2` [unit tests](https://github.com/su2code/SU2/tree/master/UnitTests/Common/toolboxes/multilayer_perceptron), [test cases](https://github.com/su2code/TestCases/tree/master/flamelet/07_laminar_premixed_h2_flame_cfd), and the [MLPCpp repository](https://github.com/EvertBunschoten/MLPCpp.git). The neural networks were trained using the [SU2 DataMiner](https://github.com/EvertBunschoten/SU2_DataMiner) code. This repository contains test cases and tutorials which explain the data generation and set-up needed to train multi-layer perceptrons for flamelet-generated manifold applications.
+
+
+The preferred choice of manifold depends on the application, available computational resources, and available know-how. Typically, using a table results in shorter query times, and therefore simulation times compared to using MLP's. On the other hand, storing three-dimensional look-up tables with sufficient resolution for accurate FGM simulations requires substial amounts of memory (in the order of giga-bytes per core). If memory usage is not a constraint, using a LUT manifold therefore results in superior computational performance compared to using MLP's. The LUT uses linear interpolation over each cell in 2D queries. For highly non-linear data, this may result in inaccuracies and subsequent numerical instabilities during the simulation process. Using the MLP option allows for the use of non-linear activation functions, resulting in more smooth output data trends. The latter may result in improved solver robustness if the corresponding MLP can be trained to be sufficiently accurate. Finally, training artificial neural networks on flamelet data can be a cumbersome process and choosing an appropriate network architecture may not always be straightforward. On the other hand, generating a look-up table is comparatively easier.
+
+In the current example, a set of MLP's is used to define the manifold:
+```
+INTERPOLATION_METHOD= MLP
+FILENAMES_INTERPOLATOR= (MLP_TD1.mlp, MLP_TD2.mlp, MLP_PD.mlp, MLP_SPV.mlp, MLP_PNO.mlp, MLP_null.mlp)
+```
+Here, [MLP_TD1.mlp](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Combustion/1__premixed_hydrogen/MLP_TD1.mlp), and [MLP_TD2.mlp](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Combustion/1__premixed_hydrogen/MLP_TD2.mlp) are used to predict the thermo-chemical fluid properties, [MLP_PD.mlp](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Combustion/1__premixed_hydrogen/MLP_PD.mlp) the preferential diffusion scalars, [MLP_SPV.mlp](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Combustion/1__premixed_hydrogen/MLP_SPV.mlp) the progress variable source term and heat release, and [MLP_PNO.mlp](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Combustion/1__premixed_hydrogen/MLP_PNO.mlp) the production term for the passive $NO$ specie. [MLP_null.mlp](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Combustion/1__premixed_hydrogen/MLP_null.mlp) is a dummy MLP which returns 0 irrespective of the controlling variable values. This file is required when using `NULL` for any parameters such as source terms.
+
+
+### Passive species definition
+
+The option `USER_SCALAR_NAMES` can be used to define species of interest for which respective transport equations will be solved. The list of species names defined in this option will correspond to the names of the species in the volume output of `SU2`.
+
+The source terms for the species of interest are defined under `USER_SOURCE_NAMES`, which expects two inputs per specie defined under `USER_SCALAR_NAMES`; the species production and consumption term as per equation 3. If no production and/or consumption term is required, use the `NULL` variable instead. Like the controlling variables, the net source term for the passive species is included in the volume output by including `SOURCE` in the options for `VOLUME_OUTPUT`.
+
+In the current example, the solution for $NO$ is computed as a species of interest. This specie is defined as
+```
+USER_SCALAR_NAMES= (Y_NO)
+USER_SOURCE_NAMES = ( \
+ Y_dot_net-NO, NULL \
+)
+```
+The solution for $$NO$$ will be stored in the volume output under the name ```Y_NO``` and only the production term will be used to define this species' source term. The name `Y_dot_net-NO` corresponds to the MLP output in the file [MLP_PNO.mlp](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Combustion/1__premixed_hydrogen/MLP_PNO.mlp).
+
+### Passive look-up terms
+
+Not all output variables from the manifold are included in the volume output by default. In order to monitor the spatial distribution of for example the preferential diffusion scalars, mean molecular weight, or any other output variable included in the manifold, they can be included in the `LOOKUP_NAMES` option. The parameters defined under `LOOKUP_NAMES` will be interpolated from the manifold during the solution process and are included in the volume output when including the option `LOOKUP` in the options for `VOLUME_OUTPUT`.`SU2` will raise an error if the variable is not present in the manifold outputs.
+
+A quantity of interest which is not computed in `SU2` is the heat release per unit volume. In the current example, this term is included in the volume output through a passive look-up.
+```
+LOOKUP_NAMES=(Heat_Release)
+```
+which corresponds to the heat release predicted by [MLP_SPV.mlp](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Combustion/1__premixed_hydrogen/MLP_SPV.mlp).
+
+### Ignition methods
+
+The flames simulated in any combustion simulation need to be initialized (or numerically 'ignited'). Three options are available for this artificial ignition process in `SU2` through the option `FLAME_INIT_METHOD`.
+
+The first option is a straight flame front, enabled through setting `FLAME_INIT_METHOD=FLAME_FRONT`. Here a straight flame front is constructed during the solution initialization where the progress variable linearly transitions from the initial value to its upper limit over a defined flame thickness. This option is prefered in simulations where not a lot of iterations are required for the flow to develop before initiating a flame. The options for defining this flame front can be defined under `FLAME_INIT=(x,y,z,n_x,n_y,n_z,t_f,L_f)` where:
+
+- `x,y,z`: spatial location of flame front (m).
+- `n_x,n_y,n_z`: flame front normal unit vector components.
+- `t_f`: flame thickness (m) over which the progress variable transition takes place.
+- `L_f`: Extend of the hot solution after the flame front (m).
+
+The second option is through an artificial spark, enabled through setting `FLAME_INIT_METHOD=SPARK`. This option produces a sphere within which artificial source terms are applied to the controlling variables over a set of (outer) iterations. This ignition method is preferred in simulations where the flow needs a substantial number of iterations to develop (e.g. partially or non-premixed simulations). The parameters for defining an artificial spark are defined under the option `SPARK_INIT=(x,y,z,r,iter_start,duration)` where:
+
+- `x,y,z` : spatial location of the spark center (m).
+- `r`: spark sphere radius (m).
+- `iter_start`: (outer) iteration after which the spark will be applied.
+- `duration`: number of (outer) iterations for which the artificial spark will be applied.
+
+The source terms applied to the controlling variables are defined under the option `SPARK_REACTION_RATES`. This option expects an array with the same length as `CONTROLLING_VARIABLE_NAMES` containing the source terms applied to the controlling variables within the spark sphere.
+
+The final and default option for initializing the solution is to perform a cold flow analysis without a flame front. This option is enabled through setting `FLAME_INIT_METHOD=NONE`.
+
+In the current example, the `SPARK` ignition method is used. Here, an artificial spark is placed in the domain, which applies a source term to the progress variable transport equation. The spark location and radius is highlighed in the figure below by the red circle.
+```
+FLAME_INIT_METHOD= SPARK
+SPARK_INIT= (0.001, 0.0004, 0.00, 1e-4, 100, 5)
+SPARK_REACTION_RATES=(1000, 0, 0)
+```
+The spark will be initialized at iteration 100 and will remain active for another 5 iterations. This should be sufficient to artificially ignite the mixture and have the flame front propagate naturally.
+
+
+
+### Boundary conditions
+
+The boundary conditions for the `SU2` FGM solver are defined similarly as those defined for regular species transport problems. Make sure that the the number of species defined under `MARKER_INLET_SPECIES` equates the sum of controlling variables and passive species. By default, all boundary conditions are perceived as weak boundary conditions.
+
+Iso-thermal wall or conjugate heat transfer boundary conditions affect the transport of total enthalpy. When using weak boundary conditions for iso-thermal walls, a heat flux term is applied to the enthalpy transport equation:
+
+$$
+\begin{equation}
+f = k \nabla T \cdot \vec{n}
+\end{equation}
+$$
+
+where $f$ is the heat flux perceived as a residual term to the enthalpy transport equation, and $n$ the local boundary normal unit vector.
+When defining the iso-thermal wall as a strong boundary condition, a 1D Newton solver process is initialized along the boundary, where
+
+$$
+h_{i+1} = h_i + c_p(\mathcal{y},h_i,Z) (T_b - T(\mathcal{y},h_i,Z))
+$$
+
+is iterated until the temperature difference $$T_b - T(\mathcal{y},h_i,Z)$$ is less than 1e-3K.
+
+For the current example, the equivalence ratio at the inlet was set to 0.5, translating to a mixture fraction of 1.447e-2. The reactants are presumed at a temperature of 300K at the inlet, while isothermal wall boundary conditions are applied on the burner wall (350K) and heat exchanger emulator (400K). The iso-thermal wall boundary conditions are defined as strong boundary conditions, meaning that the total enthalpy is locally enforced to achieve the imposed temperature.
+```
+SPECIES_INIT=(-0.575, 2.227e3, 1.447e-2)
+MARKER_INLET_SPECIES = (inlet, -0.575, 2.227e3, 1.447e-2, 0)
+MARKER_INLET=(inlet, 300.0, 0.565,1,0,0)
+
+MAKER_SPECIES_STRONG_BC=(burner_wall, cylinder_wall)
+MARKER_ISOTHERMAL= (burner_wall, 350, cylinder_wall, 400)
+```
+### Convective scheme
+Just like for regular species transport problems, there are two options available for the `CONV_NUM_METHOD_SPECIES`, those being `SCALAR_UPWIND` and `BOUNDED_SCALAR`.
+
+The convective residual term in cell volume $$\Omega$$ as computed through `SCALAR_UPWIND` is as follows:
+
+$$
+R_{C, \mathrm{SCALAR\_UPWIND}} = \iiint_\Omega\nabla\cdot(\rho\vec{u}Y)\,d\Omega
+$$
+
+When using the `BOUNDED_SCALAR` option, a correction term is applied, which compensates for the effect of flow divergence.
+
+$$
+R_{C, \mathrm{BOUNDED\_SCALAR}} = R_{C, \mathrm{SCALAR\_UPWIND}} - \iiint_\Omega Y \nabla\cdot\rho\vec{u}\,d\Omega
+$$
+
+The effect of flow divergence can be significant in the early stages of convergence near boundaries. This may result in solution instabilities for transported scalars with source terms such as the progress variable. Therefore, it is highly recommended to use `BOUNDED_SCALAR` for FGM simulations in SU2.
+
+The current example uses the ```BOUNDED_SCALAR``` option.
+
+
+# Hydrogen Burner Tutorial Set-Up
+
+The current section describes the hydrogen burner tutorial in more detail.
+
+## Manifold set-up
+
+In the current tutorial, a set of MLP's is used for the manifold. These MLP's are visualized below.
+- Thermodynamic properties:
+
+
+
+
+
+- Preferential diffusion scalars:
+
+
+
+- Progress variable source term and heat release rate:
+
+
+
+- NO source term:
+
+
+
+All networks use the Gaussian Error Linear Unit (GELU) activation function for all hidden layers and were trained on flamelet data consisting of adiabatic free-flame data, burner-stabilized data, and chemical equilibrium data obtained over a range of equivalence ratio's and reactant temperature of 0.3-6.0 and 280K-900K respectively.
+
+## Initial conditions
+
+This test case represents a simplified version of a pre-mixed hydrogen burner with a heat exchanger emulator downstream of the burner hole. The reactants (hydrogen and air at 1 atm) are pre-mixed at an equivalence ratio of 0.5 and at a temperature of 300 Kelvin. Given the species mass fractions at this equivalence ratio and the given temperature, the initial value for the transported species are
+
+$$
+\begin{align}
+\mathcal{Y}_{\mathrm{init}} = -0.575 && h_{\mathrm{init}} = 2227 J kg^{-1} && Z_{\mathrm{init}} = 1.447e-2
+\end{align}
+$$
+
+No $$NO$$ is present in the pre-mixed solution, so the value of $$Y_{NO}$$ is zero upon initialization. The initial values for the species are therefore
+```
+SPECIES_INIT=(-0.575, 2.227e3, 1.447e-2, 0)
+```
+
+## Configuration File Options
+
+All available options concerning species transport are listed below as they occur in the [config_template.cfg](https://github.com/su2code/SU2/blob/master/config_template.cfg).
+
+The majority of the relevant options for the current tutorial are discussed in the previous sections.
+
+All available output can be printed to screen using the `dry-run` feature of SU2:
+```
+$ SU2_CFD -d .cfg
+```
+
+## Running SU2
+
+The simulation can be run in serial using the following command:
+```
+$ SU2_CFD H2_burner.cfg
+```
+or in parallel with your preferred number of cores:
+```
+$ mpirun -n <#cores> SU2_CFD H2_burner.cfg
+```
+
+## Results
+
+After 3000 iterations, the simulation converges to the following solution. This solution should not be taken as a fully accurate representation of the current problem, as neither the mesh nor manifold were optimized for the current application.
+
+ The following image shows the solution for the progress variable and total enthalpy side-by-side. The progress variable solution indicates the progress of the reaction, with a local maximum next to the flame front, as is the case for lean, pre-mixed flames with preferential diffusion and no stretch. The total enthalpy solution correctly shows decreases near the cooled surfaces.
+
+
+
+The solution for the mixture fraction and NO species is shown in the next figure. Due to the effects of preferential diffusion, the mixture fraction solution shows a local minimum in regions of positive flame curvature. The NO solution contains a local maximum in the region of maximum temperature and remaining nearly constant afterwards due to the reduction in temperature from the heat exchanger emulator.
+
+
+Finally, the results for the temperature and heat release rate are shown below. These quantities are not retrieved through solving transport equations, but by retrieving them from the flamelet manifold.
+
+
diff --git a/_tutorials/incompressible_flow/Inc_Species_Transport/Inc_Species_Transport.md b/_tutorials/incompressible_flow/Inc_Species_Transport/Inc_Species_Transport.md
new file mode 100644
index 00000000..bd32055c
--- /dev/null
+++ b/_tutorials/incompressible_flow/Inc_Species_Transport/Inc_Species_Transport.md
@@ -0,0 +1,169 @@
+---
+title: Species Transport
+permalink: /tutorials/Inc_Species_Transport/
+written_by: TobiKattmann
+for_version: 7.2.1
+revised_by:
+revision_date:
+revised_version:
+solver: INC_RANS
+requires: SU2_CFD
+complexity: intermediate
+follows: Inc_Turbulent_Flat_Plate
+---
+
+
+## Goals
+
+Upon completing this tutorial, the user will be familiar with adding passive species transport equations to an incompressible or compressible flow problem. The necessary steps and config options will be explained with the example of a simple 2D incompressible mixing channel system. Output options will be explained as well.
+
+Limitations: Mixture dependent fluid properties are not available yet. The mass diffusion coefficient can only be chosen as a constant for a all species transport equations.
+
+## Resources
+
+The resources for this tutorial can be found in the [incompressible_flow/Inc_Species_Transport](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport) directory in the [tutorial repository](https://github.com/su2code/Tutorials). You will need the configuration file ([species3_primitiveVenturi.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport/species3_primitiveVenturi.cfg)) and the mesh file ([primitiveVenturi.su2](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport/primitiveVenturi.su2)).
+
+The mesh is created using [gmsh](https://gmsh.info/) and a respective `.geo` script is available to recreate/modify the mesh [primitiveVenturi.geo](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport/primitiveVenturi.geo). The mesh is fully structured (i.e. only contains Quadrilateral elements) with 3364 elements and 3510 points. A progression towards walls is used but the mesh resolution is for demonstration purposes only. The small size also makes it ideal for code development.
+
+
+Figure (1): Computational mesh with color indication of the used boundary conditions.
+
+## Prerequisites
+
+The following tutorial assumes you already compiled `SU2_CFD` in serial or parallel, please see the [Download](/docs_v7/Download/) and [Installation](/docs_v7/Installation/) if that is not done yet. Additionally it is advised to perform an entry level incompressible tutorial first, as this tutorial only goes over species transport
+
+## Background
+
+The geometry with two separate inlets, a junction where the two feeders meet and a nozzle leading to an outlet, resembles loosely a venturi mixer. The geometry massively simplifies these design principles. The material properties and provided mass fractions at the inlet are for demonstration purposes.
+
+## Problem Setup
+
+The material properties of the incompressible mean flow represent air:
+- Density (constant) = 1.1766 kg/m^3
+- Viscosity (constant) = 1.716e-5 kg/(m-s)
+- Inlet Velocities (constant) = 1 m/s in normal direction
+- Outlet Pressure (constant) = 0 Pa
+
+The SST turbulence model is used with the default settings of freestream turbulence intensity of 5% and a turbulent-to-laminar viscosity ratio of 10.
+
+The material properties specific to the species transport equations are:
+- Mass Diffusivity (constant) = 1e-3 m^2/s
+- Mass fractions at the eastern inlet: 0.5, 0.5
+- Mass fractions at the northern inlet: 0.6, 0.0
+
+## Configuration File Options
+
+All available options concerning species transport are listed below as they occur in the [config_template.cfg](https://github.com/su2code/SU2/blob/master/config_template.cfg).
+
+The options as of now are fairly limited. Species transport is switched on by setting `KIND_SCALAR_MODEL= SPECIES_TRANSPORT`. The `DIFFUSIVITY_MODEL= CONSTANT_DIFFUSIVITY` is currently the only available therefore the only additional choice the value of `DIFFUSIVITY_CONSTANT`. For the `SCHMIDT_NUMBER_TURBULENT` please consult [the respective theory](/docs_v7/Theory/#species-transport).
+
+The number of species transport equations is not set individually but deduced from the number of values given in the respective lists for species options. SU2 checks whether the same amount of values is given in each option and solves the appropriate amount of equations. `MARKER_INLET_SPECIES` is one of these options and has to be used alongside a usual `MARKER_INLET`. For outlets, symmetries or walls this is not necessary.
+
+The option `SPECIES_USE_STRONG_BC` should be left to `NO` and is an experimental option where a switch to strongly enforced boundary conditions can be made.
+
+For `CONV_NUM_METHOD_SPECIES= SCALAR_UPWIND` a second order MUSCL reconstruction and multiple limiters are available.
+
+The `TIME_DISCRE_SPECIES` can be either an implicit or explicit euler and a CFL reduction coefficient `CFL_REDUCTION_SPECIES` compared to the regular `CFL_NUMBER` is available.
+
+The inital species mass fractions are given by the list `SPECIES_INIT= 1.0, ...`.
+
+`SPECIES_CLIPPING= YES` with the respective lists for min and max enforces a strict lower and upper limit for the mass fraction solution used by the solver.
+
+```
+% --------------------- SPECIES TRANSPORT SIMULATION --------------------------%
+%
+% Specify scalar transport model (NONE, SPECIES_TRANSPORT)
+KIND_SCALAR_MODEL= SPECIES_TRANSPORT
+%
+% Mass diffusivity model (CONSTANT_DIFFUSIVITY)
+DIFFUSIVITY_MODEL= CONSTANT_DIFFUSIVITY
+%
+% Mass diffusivity if DIFFUSIVITY_MODEL= CONSTANT_DIFFUSIVITY is chosen. D_air ~= 0.001
+DIFFUSIVITY_CONSTANT= 0.001
+%
+% Turbulent Schmidt number of mass diffusion
+SCHMIDT_NUMBER_TURBULENT= 0.7
+%
+% Inlet Species boundary marker(s) with the following format:
+% (inlet_marker, Species1, Species2, ..., SpeciesN-1, inlet_marker2, Species1, Species2, ...)
+MARKER_INLET_SPECIES= (inlet, 0.5, ..., inlet2, 0.6, ...)
+%
+% Use strong inlet and outlet BC in the species solver
+SPECIES_USE_STRONG_BC= NO
+%
+% Convective numerical method for species transport (SCALAR_UPWIND)
+CONV_NUM_METHOD_SPECIES= SCALAR_UPWIND
+%
+% Monotonic Upwind Scheme for Conservation Laws (TVD) in the species equations.
+% Required for 2nd order upwind schemes (NO, YES)
+MUSCL_SPECIES= NO
+%
+% Slope limiter for species equations (NONE, VENKATAKRISHNAN, VENKATAKRISHNAN_WANG, BARTH_JESPERSEN, VAN_ALBADA_EDGE)
+SLOPE_LIMITER_SPECIES = NONE
+%
+% Time discretization for species equations (EULER_IMPLICIT, EULER_EXPLICIT)
+TIME_DISCRE_SPECIES= EULER_IMPLICIT
+%
+% Reduction factor of the CFL coefficient in the species problem
+CFL_REDUCTION_SPECIES= 1.0
+%
+% Initial values for scalar transport
+SPECIES_INIT= 1.0, ...
+%
+% Activate clipping for scalar transport equations
+SPECIES_CLIPPING= NO
+%
+% Maximum values for scalar clipping
+SPECIES_CLIPPING_MAX= 1.0, ...
+%
+% Minimum values for scalar clipping
+SPECIES_CLIPPING_MIN= 0.0, ...
+```
+
+For the screen, history and volume output multiple straight forward options were included. Whenever a number is used at the end of the keyword, one for each species (starting at zero) can be added.
+```
+SCREEN_OUTPUT= RMS_SPECIES_0, ..., MAX_SPECIES_0, ..., BGS_SPECIES_0, ..., \
+ LINSOL_ITER_SPECIES, LINSOL_RESIDUAL_SPECIES, \
+ SURFACE_SPECIES_0, ..., SURFACE_SPECIES_VARIANCE
+```
+
+For `HISTORY_OUTPUT` the residuals are included in `RMS_RES` and the linear solver quantities in `LINSOL`. The surface outputs can be included with `SPECIES_COEFF` or `SPECIES_COEFF_SURF` for each surface individually.
+
+For `VOLUME_OUTPUT` no extra output field has the be set. The mass fractions are included in `SOLUTION` and the volume residuals in `RESIDUAL`.
+
+All available output can be printed to screen using the `dry-run` feature of SU2:
+```
+$ SU2_CFD -d .cfg
+```
+
+## Running SU2
+
+The simulation can be run in serial using the following command:
+```
+$ SU2_CFD species3_primitiveVenturi.cfg
+```
+or in parallel with your preferred number of cores (for this small case not more than 4 cores should be used):
+```
+$ mpirun -n <#cores> SU2_CFD species3_primitiveVenturi.cfg
+```
+
+## Results
+
+The case converges nicely as expected on such a simple case and mesh.
+
+
+Figure (2): Residual plot (Incompressible mean flow, SST turbulence model, species transport).
+
+Note that there is still some unphysical mass fraction fluctuation for Species_0 at the junction corner. This becomes much less apparent by using `MUSCL_SPECIES = YES` but does not fully disappear.
+
+
+Figure (3): Volume mass fractions for both species. Species_1 is mirrored for better comparison.
+
+Velocity magnitude field along which the species are transported. For a much less homogenous mixture at the outlet one could decrease the `DIFFUSIVITY_CONSTANT` which makes for a more interesting optimization problem.
+
+
+Figure (4): Velocity Magnitude in the domain.
+
+## Additional remarks
+
+An in depth optimization of this case with addition of the FFD-box, gradient validation and some more steps can found [here](/tutorials/Species_Transport/).
diff --git a/_tutorials/incompressible_flow/Inc_Species_Transport_Composition_Dependent_Model/Inc_Species_Transport_Composition_Dependent_Model.md b/_tutorials/incompressible_flow/Inc_Species_Transport_Composition_Dependent_Model/Inc_Species_Transport_Composition_Dependent_Model.md
new file mode 100644
index 00000000..90820c70
--- /dev/null
+++ b/_tutorials/incompressible_flow/Inc_Species_Transport_Composition_Dependent_Model/Inc_Species_Transport_Composition_Dependent_Model.md
@@ -0,0 +1,232 @@
+---
+title: Composition-Dependent model for Species Transport equations
+permalink: /tutorials/Inc_Species_Transport_Composition_Dependent_Model/
+written_by: Cristopher-Morales
+for_version: 7.5.0
+revised_by:
+revision_date:
+revised_version:
+solver: INC_RANS
+requires: SU2_CFD
+complexity: intermediate
+follows: Inc_Species_Transport
+---
+
+
+## Goals
+
+In this tutorial, the user will be familiar with the composition-dependent model in SU2 based on the Ideal Gas law for a gas mixture. The necessary steps and configuration options for the aforementioned model will be explained through a 3D incompressible kenics static mixer for a methane-air mixture.
+
+## Resources
+
+The resources for this tutorial can be found in the [incompressible_flow/Inc_Species_Transport_Composition_Dependent_Model](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport_Composition_Dependent_Model) directory in the [tutorial repository](https://github.com/su2code/Tutorials). To complete this tutorial, you will need the configuration file ([kenics_mixer_tutorial.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport_Composition_Dependent_Model/kenics_mixer_tutorial.cfg)) and the mesh file ([kenics.su2](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport_Composition_Dependent_Model/kenics.su2)).
+
+The mesh is created using [gmsh](https://gmsh.info/) and a respective `.geo` script is available to recreate/modify the mesh [kenics_mixer_tutorial.geo](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Species_Transport_Composition_Dependent_Model/kenics_mixer_tutorial.geo). The mesh consists of 128790 volume elements and 138324 points.
+
+
+Figure (1): Computational mesh (top figure) and 2D cross-section view with color markers showing the boundary conditions and geometry (bottom figure).
+
+## Prerequisites
+
+The following tutorial assumes you have already compiled `SU2_CFD` in serial or parallel, please see the [Download](/docs_v7/Download/) and [Installation](/docs_v7/Installation/). Likewise, it is advised to perform the tutorial regarding species transport in a venturi mixer([Inc_Species_Transport](/tutorials/Inc_Species_Transport/)) where the species transport options are explained, as this tutorial mainly focuses on the composition-dependent options.
+
+## Background
+
+The geometry consists of a Static Kenics mixer with three blades, all the blades are perpendicular to each other, and are twisted 180 degrees along the z-axis in order to enhance the mixing. Furthermore, two inlets are considered, where pure air and pure methane are injected at each inlet. Finally, one outlet is considered at the end of the mixer device.
+
+
+## Problem Setup
+
+In this problem, we investigate the flow and mixing along the kenic static mixer. Thus, we have the following boundary conditions at the inlets and outlet:
+
+- Equal Inlet Velocities (constant) = 5 m/s in normal direction (z-direction)
+- Outlet Pressure (constant) = 0 Pa
+- Inlet Temperature (both inlets) = 300 K
+- Adiabatic walls.
+
+In this case, the energy equation is switched `OFF` as we consider two streams with the same temperature and adiabatic walls.
+
+The SST turbulence model is used with default settings of freestream turbulence intensity of 5% and turbulent-to-laminar viscosity ratio of 10. However, in order to highlight the new option available in SU2 of having different turbulence intensities and turbulent-to-laminar viscosity ratios, these will be given as marker inlets for turbulence that will be explained in the following section.
+
+The thermochemical properties for each gas are given below:
+* Methane:
+ - Molecular Weight = 16.043 [g / mol]
+ - Viscosity: 1.1102E-05 [kg /(m s)]
+ - Heat capacity at constant pressure: 2224.43 [J/(kg K)]
+ - Thermal Conductivity: 0.0357 [W /(m K)]
+* Air:
+ - Molecular Weight = 28.960 [g / mol]
+ - Viscosity: 1.8551E-05 [kg /(m s)]
+ - Heat capacity at constant pressure: 1009.39 [J/(kg K)]
+ - Thermal Conductivity: 0.0258 [W /(m K)]
+
+The species mass fractions at each inlet are the following:
+
+- Inlet_gas: mass fraction methane, Y_CH4 = 1.0 (pure methane, Y_air=0.0)
+- Inlet_air: mass fraction methane, Y_CH4 = 0.0 (pure air, Y_air=1.0)
+
+It should be noted that within SU2, for a mixture of N species, N-1 species transport equations are solved and, the last species is computed as $$1-\sum Y_i$$. Thus, in this tutorial, a transport equation for methane is being solved. For more information, please see [Theory](/docs_v7/Theory/).
+
+## Configuration File Options
+
+All available options concerning species transport are listed in the [config_template.cfg](https://github.com/su2code/SU2/blob/master/config_template.cfg).Here, we are going to focus on the composition-dependent options.
+
+For activating the composition-dependent model, the fluid model must be chosen as `FLUID_MODEL= FLUID_MIXTURE`. It must be noted that this model is only compatible with `INC_DENSITY_MODEL= VARIABLE`. Otherwise, an error message will be displayed during runtime.
+
+A low-mach number approximation for incompressible flows allows the pressure to be decomposed into dynamic and thermodynamic (operating) pressure (see [Theory](/docs_v7/Theory/). The operating pressure is used for computing the mixture density using the Ideal gas law. The thermodynamic pressure might strongly affect the density at the inlets, causing unphysical results. Therefore, the thermodynamic pressure must be provided by the user for the `FLUID_MIXTURE` model and, it is no longer computed from the free-stream conditions as it is done in the other fluid models. As in mixing and combustion processes, the operating pressure is often assumed as 101325 pa, then this is the default value considered inside SU2 if the thermodynamic pressure is not given in the .cfg file. In the.cfg file, the thermodynamic pressure is specified as `THERMODYNAMIC_PRESSURE= 101325.0`.
+
+Subsequently, the molecular weights and heat capacities at constant pressure must be provided as a list as follows: `MOLECULAR_WEIGHT= W_1, W_2,...., W_N` , `SPECIFIC_HEAT_CP = Cp_1, Cp_2,..., Cp_N`. The length of the list must match the number of the N species in the mixture. Moreover, the mean molecular weight is computed as a mole fraction average, and the mixture heat capacity is computed as a mass fraction average. For more information, please see $$^{1},^{3}$$.
+
+For the conductivity model, the following options are available: `CONDUCTIVITY_MODEL= CONSTANT_CONDUCTIVITY, CONSTANT_PRANDTL, POLYNOMIAL_CONDUCTIVITY `. In this tutorial, the option `CONSTANT_CONDUCTIVITY` is used. For this option, a constant conductivity for each species must be provided as follows: `THERMAL_CONDUCTIVITY_CONSTANT= k_1, k_2,...., k_N`.
+Currently, the only mixing law available in SU2 for computing the mixture thermal conductivity is based on the Wilke mixing law. Therefore, this is the default option, and it is hardcoded for the `FLUID_MIXTURE` option. For more information regarding this mixing model, please see $$^{1},^{2}$$.
+
+Similar treatment is done for the laminar Prandtl numbers: `PRANDTL_LAM= Pr_1, Pr_2,....,Pr_N`. Finally, for turbulence simulations, the option of turbulent Prandlt number can be enabled as `TURBULENT_CONDUCTIVITY_MODEL= CONSTANT_PRANDTL_TURB`. If this option is enabled, the turbulent Prandtl numbers must have the same structure as the Laminar Prandtl numbers: `PRANDTL_TURB= Pr_Turb_1, Pr_Turb_2, ..., Pr_Turb_N`. For more information about laminar and turbulent Prandlt numbers, please see [Theory](/docs_v7/Theory/).
+
+For the present tutorial, the options are given below:
+
+```
+% -------------------- FLUID PROPERTIES ------------------------------------- %
+%
+FLUID_MODEL= FLUID_MIXTURE
+% Thermodynamics(operating) Pressure (101325 Pa default value, only for incompressible flow and FLUID_MIXTURE)
+THERMODYNAMIC_PRESSURE= 101325.0
+%
+MOLECULAR_WEIGHT= 16.043, 28.960
+%
+SPECIFIC_HEAT_CP = 2224.43, 1009.39
+%
+CONDUCTIVITY_MODEL= CONSTANT_CONDUCTIVITY
+THERMAL_CONDUCTIVITY_CONSTANT= 0.0357, 0.0258
+%
+PRANDTL_LAM= 0.72, 0.72
+%
+TURBULENT_CONDUCTIVITY_MODEL= CONSTANT_PRANDTL_TURB
+PRANDTL_TURB= 0.90, 0.90
+```
+
+Regarding the viscosity model, the following options are available `VISCOSITY_MODEL= SUTHERLAND, CONSTANT_VISCOSITY, POLYNOMIAL_VISCOSITY`. In the case of `CONSTANT_VISCOSITY`, the viscosities must be provided as a list as follows: `MU_CONSTANT= mu_1, mu_2, ..., mu_N`. Similarly, if `SUTHERLAND` model is chosen, the Sutherland parameters must be given as a list for each species in the mixture. For completeness, an example for SUTHERLAND option is shown below for a mixture of two species:
+
+```
+% --------------------------- VISCOSITY MODEL ---------------------------------%
+%
+VISCOSITY_MODEL= SUTHERLAND
+%
+MU_REF= 1.118E-05, 1.716E-05
+%
+MU_T_REF= 273, 273
+%
+SUTHERLAND_CONSTANT= 97, 111
+```
+
+For this tutorial, as the energy equation is not being solved, we use `CONSTANT_VISCOSITY` as the viscosity model. Finally, for computing the mixture viscosity, two models are available in SU2: Wilke and Davidson Models. They can be enabled using the following option: `MIXING_VISCOSITY_MODEL = WILKE, DAVIDSON`. Please see $$^{2},^{4}$$ for more information on these models..
+The options used in this tutorial are shown below:
+
+```
+% --------------------------- VISCOSITY MODEL ---------------------------------%
+%
+VISCOSITY_MODEL= CONSTANT_VISCOSITY
+%
+MU_CONSTANT= 1.1102E-05, 1.8551E-05
+%
+MIXING_VISCOSITY_MODEL = WILKE
+```
+
+The Species transport is switched on by setting `KIND_SCALAR_MODEL= SPECIES_TRANSPORT`. For the mass diffusivity, the following models are available `DIFFUSIVITY_MODEL= CONSTANT_DIFFUSIVITY, CONSTANT_SCHMIDT, UNITY_LEWIS, CONSTANT_LEWIS` , where `CONSTANT_DIFFUSIVITY` is the default model. For the first two, a constant value must be specified in the.cfg file for all species, as it is done in the species transport tutorial [Inc_Species_Transport](/tutorials/Inc_Species_Transport/). For the UNITY_LEWIS, no values must be provided because the diffusivity is computed using the mixture thermal conductivity, density and heat capacity at constant pressure; for more information, please see $$^{3}$$. For highly diffusive gases, such as hydrogen, the `CONSTANT_LEWIS` option could be used. For this option, the Lewis numbers of the N-1 species for which a transport equation is being solved must be provided as a list using the option `CONSTANT_LEWIS_NUMBER= Le_1, Le_2, ..., Le_N_1`. Finally, for turbulent simulations, the turbulent diffusivity is computed based on the `SCHMIDT_NUMBER_TURBULENT`. For reference, please consult [the respective theory](/docs_v7/Theory/#species-transport).
+
+Finally, for the SST model, it is possible to provide the intensity and turbulent-to-laminar viscosity ratios per inlet. For this option, we use the following structure: `MARKER_INLET_TURBULENT= (inlet_1, TurbIntensity_1, TurbLamViscRatio_1, inlet_2, TurbIntensity_2, TurbLamViscRatio_2, ...)`.
+
+As final remarks, the option `MARKER_SPECIES_STRONG_BC` is advised to not to be used when the convective scheme for species and turbulent are `CONV_NUM_METHOD_SPECIES= BOUNDED_SCALAR` and `CONV_NUM_METHOD_TURB= BOUNDED_SCALAR`, respectively. When `SCALAR_UPWIND` is used in both cases, the `MARKER_SPECIES_STRONG_BC` is advised to be used to enforce boundary conditions and improve convergence for this convective scheme. This can be used with the following structure `MARKER_SPECIES_STRONG_BC= (marker1, marker2, ....)`. The convective scheme `BOUNDED_SCALAR` will be further explained in the section [Convective-Schemes](/docs_v7/Convective-Schemes/).
+
+Likewise, `SPECIES_CLIPPING= NO` is only recommended when the option `SCALAR_UPWIND` is used. The option `BOUNDED_SCALAR` performs well without using the clipping option.
+
+The other species transport options can be found in the species transport tutorial([Inc_Species_Transport](/tutorials/Inc_Species_Transport/)).
+
+For completeness, the options aforementioned are shown below:
+
+```
+% -------------------- BOUNDARY CONDITION DEFINITION --------------------------%
+%
+MARKER_HEATFLUX= ( inner_wall, 0.0,blade_1, 0.0, blade_2, 0.0, blade_3, 0.0, outer_wall,0.0)
+%
+SPECIFIED_INLET_PROFILE= NO
+%
+INC_INLET_TYPE= VELOCITY_INLET VELOCITY_INLET
+MARKER_INLET= ( inlet_gas, 300, 5.0, 0.0, 0.0, 1.0, inlet_air, 300, 5.0, 0.0, 0.0, 1.0 )
+MARKER_INLET_SPECIES= (inlet_gas, 1.0, inlet_air, 0.0 )
+%
+MARKER_INLET_TURBULENT= (inlet_gas, 0.05, 10, inlet_air, 0.05, 10)
+INC_OUTLET_TYPE= PRESSURE_OUTLET
+MARKER_OUTLET= ( outlet, 0.0 )
+%
+% --------------------- SPECIES TRANSPORT SIMULATION --------------------------%
+%
+% Specify scalar transport model (NONE, SPECIES_TRANSPORT)
+KIND_SCALAR_MODEL= SPECIES_TRANSPORT
+%
+% Mass diffusivity model (CONSTANT_DIFFUSIVITY)
+DIFFUSIVITY_MODEL= UNITY_LEWIS
+%
+% Turbulent Schmidt number of mass diffusion
+SCHMIDT_NUMBER_TURBULENT= 0.7
+%
+% Convective numerical method for species transport (SCALAR_UPWIND, BOUNDED_SCALAR)
+CONV_NUM_METHOD_SPECIES= BOUNDED_SCALAR
+%
+% Monotonic Upwind Scheme for Conservation Laws (TVD) in the species equations.
+% Required for 2nd order upwind schemes (NO, YES)
+MUSCL_SPECIES= NO
+%
+% Slope limiter for species equations (NONE, VENKATAKRISHNAN, VENKATAKRISHNAN_WANG, BARTH_JESPERSEN, VAN_ALBADA_EDGE)
+SLOPE_LIMITER_SPECIES = NONE
+%
+% Time discretization for species equations (EULER_IMPLICIT, EULER_EXPLICIT)
+TIME_DISCRE_SPECIES= EULER_IMPLICIT
+%
+% Initial values for scalar transport
+SPECIES_INIT= 1.0
+%
+% Activate clipping for scalar transport equations
+SPECIES_CLIPPING= NO
+```
+
+## Running SU2
+
+The simulation can be run in serial using the following command:
+```
+$ SU2_CFD kenics_mixer_tutorial.cfg
+```
+or in parallel with your preferred number of cores (for this case, it is recommended to use 4 cores in order to speed up the simulation):
+```
+$ mpirun -n <#cores> SU2_CFD kenics_mixer_tutorial.cfg
+```
+
+## Results
+
+This case shows a smooth convergence and does not have the flat residuals observed in the [Inc_Species_Transport](/tutorials/Inc_Species_Transport/).
+
+
+Figure (2): Residual plot (Incompressible mean flow, SST turbulence model, species transport).
+
+We observe that using the option `CONV_NUM_METHOD_SPECIES= BOUNDED_SCALAR` addressed the unphysical mass fraction fluctuations observed in the tutorial ([Inc_Species_Transport](/tutorials/Inc_Species_Transport/)). Similarly, it can be noted how the mixing process is enhanced by the mixer units.
+
+
+Figure (3): Mass fractions of methane at the different locations along the Kenics static mixer.
+
+Velocity magnitude along the Kenics static mixers.
+
+
+Figure (4): Velocity magnitude at different locations along the Kenics static mixer.
+
+The plots are cross sections of the mixing device at the following locations: 0.04, 0.09, 0.1067, 0.1133, 0.1267, 0.1333, 0.18 and 0.24 m.
+
+### References
+$$^{1}$$ B. Poling, J. Prausnitz, J. O’Connell, The Properties of Gases and Liquids, 5th Edition, McGraw-Hill Education,2000.(URL https://books.google.nl/books?id=9tGclC3ZRX0C)
+
+$$^{2}$$ C. R. Wilke, A viscosity equation for gas mixtures, The Journal of Chemical Physics 18 (4) (1950),517–519.(https:doi:10.1063/1.1747673).
+
+$$^{3}$$ T. Poinsot, D. Veynante, Theoretical and Numerical Combustion, Ch. 1, 2012.
+
+$$^{4}$$ T. A. Davidson, A simple and accurate method for calculating viscosity of gaseous mixtures. (URL https://www.osti.gov/biblio/6129940)
+
+
+## Additional remarks
diff --git a/_tutorials/incompressible_flow/Inc_Streamwise_Periodic/Inc_Streamwise_Periodic.md b/_tutorials/incompressible_flow/Inc_Streamwise_Periodic/Inc_Streamwise_Periodic.md
new file mode 100644
index 00000000..801bb415
--- /dev/null
+++ b/_tutorials/incompressible_flow/Inc_Streamwise_Periodic/Inc_Streamwise_Periodic.md
@@ -0,0 +1,207 @@
+---
+title: Streamwise Periodic Flow
+permalink: /tutorials/Inc_Streamwise_Periodic/
+written_by: TobiKattmann
+for_version: 7.1.0
+revised_by:
+revision_date:
+revised_version:
+solver: INC_RANS
+requires: SU2_CFD
+complexity: intermediate
+follows: Inc_Laminar_Flat_Plate
+---
+
+
+## Goals
+
+Upon completing this tutorial, the user will be familiar with performing streamwise periodic simulations using the incompressible solver. All available features and limitations of streamwise periodic flow will be discussed. Consequently, the following capabilities of SU2 will be showcased in this tutorial:
+- How to activate streamwise periodic flow without energy equation
+- Switch between pressure drop and massflow prescription
+- Adding the energy equation as true streamwise periodic flow and limitations
+- Alternative to streamwise periodic temperature
+
+## Resources
+
+The resources can be found in the [incompressible_flow/Inc_Streamwise_Periodic](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Streamwise_Periodic) directory in the [tutorial repository](https://github.com/su2code/Tutorials). It contains the mesh file and two configuration files which will be discussed in this tutorial. Additionally, the script to create the used mesh with [gmsh](https://gmsh.info/) can be found that folder as well.
+
+A more detailed theory description is available in the Docs [here](/docs_v7/Streamwise-Periodicity).
+
+## Tutorial
+
+The following tutorial will walk you through the steps required when solving for a streamwise periodic flow using the incompressible solver. It is assumed you have already obtained and compiled the SU2_CFD code for a serial computation. If you have yet to complete these requirements, please see the [Download](/docs_v7/Download/) and [Installation](/docs_v7/Installation/) pages.
+Users unfamiliar with using the incompressible solver can take a look at the other incompressible testcases, especially the [Laminar Flat Plate with Heat Transfer](/tutorials/Inc_Laminar_Flat_Plate/).
+
+### Background
+
+Flows through periodically repeating geometries can be approximated by just simulating a unit cell with streamwise periodicity. This model assumption of fully developed flow can be a justified approximation but has to be checked whether it is suitable. A 2D slice through a pin-fin heat-exchanger unit-cell is presented in this tutorial.
+
+### Problem Setup
+
+This problem will solve for the incompressible RANS flow the following conditions:
+- Density (constant) = 1045.0 kg/m^3
+- Viscosity (constant) = 0.001385 kg/(m-s)
+- Specific Heat Capacity (constant)= 3540.0 J/(kg-K)
+- laminar Prandtl number (constant) = 11.7
+
+As streamwise periodic flow is simulated, periodic boundaries are used instead of in-/outlets boundaries. The pin surfaces are heatlfux markers and are heated with 5e5 W/m^2. The remaining boundaries are symmetry markers.
+
+
+
+*Figure (1)*: Figure of the computational mesh with the used boundary conditions.
+
+### Mesh Description
+
+The computational mesh for the fluid has 8477 quad elements and is therefore fully structured. In- and outlet are meshed with 50 points and a progression such that y+<1 everywhere as the SST turbulence model is used. Each quarter-pin is meshed with 45 points in streamwise direction. A [gmsh script](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Streamwise_Periodic/chtPinArray_2d.geo) is available to recreate/modify the mesh.
+
+### Configuration File Options
+
+The available options for streamwise periodic flow are explained in this section.
+
+Note that streamwise periodic flow is only available for the incompressible solver.
+
+Using streamwise periodic flow requires having a periodic marker pair which can be set using `MARKER_PERIODIC= (, , ...)`. The designated inlet has to be set first as a convention. The vector between periodic points on the in- and outlet has to be given as well in the case for translational periodicity as is discussed here. From the `config_template.cfg`:
+```
+% Periodic boundary marker(s) (NONE = no marker)
+% Format: ( periodic marker, donor marker, rotation_center_x, rotation_center_y,
+% rotation_center_z, rotation_angle_x-axis, rotation_angle_y-axis,
+% rotation_angle_z-axis, translation_x, translation_y, translation_z, ... )
+MARKER_PERIODIC= ( NONE )
+```
+For the rotation center and angle a zero has to provided such that in this case the marker definition looks like:
+```
+MARKER_PERIODIC= ( fluid_inlet, fluid_outlet, 0.0,0.0,0.0, 0.0,0.0,0.0, 0.0111544,0.0,0.0 )
+```
+At the moment, only one periodic marker pair is allowed, i.e. the combination with spanwise periodic flow is not possible.
+
+`KIND_STREAMWISE_PERIODIC` activates streamwise periodic flow with the choice between a prescribed `PRESSURE_DROP` or `MASSFLOW`. With `PRESSURE_DROP` the prescribed value is set using `STREAMWISE_PERIODIC_PRESSURE_DROP` which also serves as a starting value if `MASSFLOW` is chosen.
+
+Use `STREAMWISE_PERIODIC_MASSFLOW` for the respective massflow. With a precribed massflow the necessary pressure drop is determined iteratively, i.e. based on the difference between actual and target massflow an update to the pressure drop is estimated. This update can be relaxed using `INC_OUTLET_DAMPING`. Starting with a conservative guess to `STREAMWISE_PERIODIC_PRESSURE_DROP` and `INC_VELOCITY_INIT` will most likely a wise move.
+
+If the energy equation is active then one can use `STREAMWISE_PERIODIC_TEMPERATURE= YES` if only heatflux and symmetry boundaries are used additional to the periodic markers. If that is not possible (i.e. if isothermal walls are used or a CHT interface is present), a heatsink at the outlet will automatically extract energy from the domain and will force the area-averaged inlet temperature to be identical to `INC_TEMPERATURE_INIT`. In order to support this process the user can provide an amount via `STREAMWISE_PERIODIC_OUTLET_HEAT` in Watts. If the value `0.0` (or none for that matter) is given, the integrated heat via `MARKER_HEATFLUX` is used.
+
+Below the relevant excerpt from the `config_template.cfg` is shown.
+```
+% --------------------- STREAMWISE PERIODICITY DEFINITION ---------------------%
+%
+% Generally for streamwise periodicity one has to set MARKER_PERIODIC= (, , ...)
+% appropriately as a boundary condition.
+%
+% Specify type of streamwise periodicity (default=NONE, PRESSURE_DROP, MASSFLOW)
+KIND_STREAMWISE_PERIODIC= NONE
+%
+% Delta P [Pa] value that drives the flow as a source term in the momentum equations.
+% Defaults to 1.0.
+STREAMWISE_PERIODIC_PRESSURE_DROP= 1.0
+%
+% Target massflow [kg/s]. Necessary pressure drop is determined iteratively.
+% Initial value is given via STREAMWISE_PERIODIC_PRESSURE_DROP. Default value 1.0.
+% Use INC_OUTLET_DAMPING as a relaxation factor. Default value 0.1 is a good start.
+STREAMWISE_PERIODIC_MASSFLOW= 0.0
+%
+% Use streamwise periodic temperature (default=NO, YES)
+% If NO, the heatflux is taken out at the outlet.
+% This option is only necessary if INC_ENERGY_EQUATION=YES
+STREAMWISE_PERIODIC_TEMPERATURE= NO
+%
+% Prescribe integrated heat [W] extracted at the periodic "outlet".
+% Only active if STREAMWISE_PERIODIC_TEMPERATURE= NO.
+% If set to zero, the heat is integrated automatically over all present MARKER_HEATFLUX.
+% Upon convergence, the area averaged inlet temperature will be INC_TEMPERATURE_INIT.
+% Defaults to 0.0.
+STREAMWISE_PERIODIC_OUTLET_HEAT= 0.0
+%
+```
+
+Additional `SCREEN_OUTPUT` for streamwise periodic flow is `STREAMWISE_MASSFLOW`, `STREAMWISE_DP` (i.e. Delta P or pressure drop) and `STREAMWISE_HEAT` which shows the heatflux integrated over HEATFLUX_MARKERS. By adding `STREAMWISE_PERIODIC` to `HISTORY_OUTPUT` those values are written the history file.
+
+In this tutorial, 2 configuration files are provided which differ in the streamwise periodic options.
+
+[First](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Streamwise_Periodic/sp_pinArray_2d_dp_hf_tp.cfg), one of the simplest setups with a user provided pressure drop over the domain is chosen. Temperature periodicity is activated.
+```
+% --------------------- STREAMWISE PERIODICITY DEFINITION ---------------------%
+%
+KIND_STREAMWISE_PERIODIC= PRESSURE_DROP
+STREAMWISE_PERIODIC_PRESSURE_DROP= 208.023676
+%
+STREAMWISE_PERIODIC_TEMPERATURE= YES
+%
+```
+For the [second configuration](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Streamwise_Periodic/sp_pinArray_2d_mf_hf.cfg) a massflow is prescribed. The initial pressure drop matches the final value but changes within the first iterations until the flow converges. Streamwise periodic temperature is deactivated so the outlet heatsink is used. In this case the 3 heatflux markers form a full circle which makes an exact computation of the introduced heatflux possible which can be then specified using the `STREAMWISE_PERIODIC_OUTLET_HEAT`. Note that an exact computation of this value is not always possible and also not necessary as the area-averaged inlet temperature must match `INC_TEMPERATURE_INIT` upon convergence which serves as an anchor for the temperature.
+```
+% --------------------- STREAMWISE PERIODICITY DEFINITION ---------------------%
+%
+KIND_STREAMWISE_PERIODIC= MASSFLOW
+STREAMWISE_PERIODIC_MASSFLOW= 0.85
+STREAMWISE_PERIODIC_PRESSURE_DROP= 208.023676
+INC_OUTLET_DAMPING= 0.01
+%
+STREAMWISE_PERIODIC_TEMPERATURE= NO
+% Computation of outlet heat: Heatflux * Area = Heatflux * pi * radius (as we have an accumulated full circle)
+% 5e5[W/m] * pi * 2e-3[m]
+STREAMWISE_PERIODIC_OUTLET_HEAT= -3141.5926
+%
+```
+
+### Running SU2
+
+To run this test case, follow these steps at a terminal command line:
+ 1. Move to the directory containing the config files and the mesh files. Make sure that the SU2 tools were compiled, installed, and that their install location was added to your path.
+ 2. Run the executable by entering
+
+ ```
+ $ SU2_CFD sp_pinArray_2d_dp_hf_tp.cfg
+ ```
+ at the command line for the first configuration. The filename makes use of some abbreviations: sp=streamwise periodic, 2d=2 dimensions, dp= delta p (prescribed), hf= heatflux (markers only), tp=temperature periodicity. The second configuration is run with
+
+ ```
+ $ SU2_CFD sp_pinArray_2d_mf_hf.cfg
+ ```
+
+ If SU2 is compiled with MPI support then you can execute SU2 in parallel
+
+ ```
+ $ mpirun -n <#cores> SU2_CFD sp_pinArray_2d_mf_hf.cfg
+ ```
+
+ where more than 8 cores do not provide major speedups due to the small mesh size.
+ 3. SU2 will print residual updates with each outer iteration of the flow solver, and the simulation will terminate after reaching the specified convergence criteria.
+ 4. Files containing the results will be written upon exiting SU2. The provided configuration files will write Paraview Multiblock files (.vtm) by default. The flow solution can be visualized in ParaView (.vtk) or Tecplot (.dat for ASCII) by setting the respective `OUTPUT_FILES` fields.
+
+### Results
+
+The results for both simulations are discussed in this section. The difference is only visible for Temperature as both configurations end up having the same pressure drop and massflow by construction.
+
+The visualizations are done using [Paraview](https://www.paraview.org/). To better visualize the differences, the `Reflect` (along symmetry axes) and `Transform` (at periodic interface) filters were used.
+
+The velocity contour lines are shown in Figure (2). The turquoise line delimits the simulation domain. Demonstrating the computation of a fully developed flow on just a representative unit cell.
+
+
+
+*Figure (2)*: Velocity magnitude contour lines. The turquoise line delimits the simulation domain.
+
+In Figure (3) the pressure is visualized. On the top the periodic pressure which is used as solution variable does not exhibit a pressure drop over the domain and can be interpreted to show only local phenomena. On the bottom the recovered ("physical") pressure subtracts a linear term over the domain and therefore recovers the expected pressure drop. Note that negative pressures are possible in the incompressible solver as only pressure differences are used and the absolute pressure value is irrelevant.
+
+
+
+*Figure (3)*: Pressure contour lines. Top: Periodic pressure that is used as solution variable. Bottom: Recovered pressure computed as postprocessing variable.
+
+Similar to pressure is the handling of the streamwise periodic temperature. The visualization in Figure (4) is from the first discussed configuration. On the top the temperature filed is truly periodic and on the bottom the recoverd temperature allows a real world interpretation.
+
+
+
+*Figure (4)*: Temperature contour lines. Top: Periodic temperature that is used as solution variable. Bottom: Recovered temperature computed as postprocessing variable.
+
+The temperature of the second configuration with the outlet heat sink is shown in Figure (5). Of course in this case only one temperature to be analyzed. Note that the temperature on the periodic in- and outlet are identical. The outlet heat sink is necessary to prevent an infinite rise in temperature in the case of only heatflux boundaries.
+
+
+
+*Figure (5)*: Temperature contour lines for simulation with an outlet heatsink.
+
+### Additional remarks
+
+The **extension to CHT** cases is straight forward as the options in the fluid zone remain the same. `STREAMWISE_PERIODIC_TEMPERATURE= NO` has to be set as that feature is not compatible with the conjugate heat interfaces. A `STREAMWISE_PERIODIC_OUTLET_HEAT` can be provided by just integrating all heatflux markers of the combined fluid and heat zones. This of course does not handle possible isothermal walls but the excess energy is automatically balanced. A [2D CHT testcase](https://github.com/su2code/TestCases/tree/master/incomp_navierstokes/streamwise_periodic/chtPinArray_2d) based on the geometry presented here and a [3D CHT testcase](https://github.com/su2code/TestCases/tree/master/incomp_navierstokes/streamwise_periodic/chtPinArray_3d) are available in the testcases of SU2 under `TestCases/incomp_navierstokes/streamwise_periodic/`.
+
+**Temperature depended material properties** are only reasonable to be used with `STREAMWISE_PERIODIC_TEMPERATURE= NO` as the solution variable Temperature would be truly periodic and therefore non-physical. The recovered Temperature would need to be used instead which is not available in the code at the moment.
+
+The **discrete adjoint** does not work with `KIND_STREAMWISE_PERIODIC= MASSFLOW` in the moment. All other features are working with the discrete adjoint solver.
diff --git a/_tutorials/incompressible_flow/Inc_Turbulent_Bend/Inc_Turbulent_Bend.md b/_tutorials/incompressible_flow/Inc_Turbulent_Bend/Inc_Turbulent_Bend.md
new file mode 100644
index 00000000..a9c65419
--- /dev/null
+++ b/_tutorials/incompressible_flow/Inc_Turbulent_Bend/Inc_Turbulent_Bend.md
@@ -0,0 +1,181 @@
+---
+title: Turbulent Bend with wall functions
+permalink: /tutorials/Inc_Turbulent_Bend/
+written_by: Nijso Beishuizen
+for_version: 7.4.0
+revised_by:
+revision_date:
+revised_version:
+solver: INC_RANS
+requires: SU2_CFD
+complexity: intermediate
+follows: Inc_Turbulent_Flat_Plate
+---
+
+
+
+Figure (1): impression of the 90 degree bend with velocity contours.
+
+## Goals
+
+In this tutorial we will simulate the turbulent flow in a 90 degree pipe bend. We will touch upon the following aspects:
+- the mesh generation in the meshing tool gmsh
+- the setup of the model in SU2, using wall functions with the SST turbulence model
+- creating a more suitable inlet profile from the solution with uniform inlet conditions
+- postprocessing the results with python and paraview
+
+
+## Resources
+
+The resources for this tutorial can be found in the [incompressible_flow/Inc_Turbulent_Bend_Wallfunctions](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Turbulent_Bend_Wallfunctions) directory in the [tutorial repository](https://github.com/su2code/Tutorials). You will need the configuration file ([sudo.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Turbulent_Bend_Wallfunctions/sudo.cfg)) and the mesh file ([sudo_coarse.su2](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Turbulent_Bend_Wallfunctions/sudo_coarse.su2)). Additionally, the Gmsh geometry is also provided so you can recreate the mesh yourself: [sudo_coarse.geo](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Turbulent_Bend_Wallfunctions/sudo_coarse.geo).
+
+This test case was also presented at the 2022 SU2 conference:
+- [2022 su2 conference](https://su2foundation.org/su2conference2022/)
+- [doc:Turbulence modeling with wall functions](https://drive.google.com/file/d/16al4x0VIk9tDepSBjrJf0YTqaEu9QHDn/view)
+- [youtube:Turbulence modeling with wall functions](https://drive.google.com/file/d/16al4x0VIk9tDepSBjrJf0YTqaEu9QHDn/view)
+
+## Tutorial
+
+The following tutorial will briefly introduce the mesh generation with the meshing software [gmsh](https://gmsh.info/), which is a great tool especially for structured mesh generation. The test case will then be set up, using wall functions to avoid the use of very fine meshes. The postprocessing with paraview will be briefly introduced, where we do a quick check to see if the solution looks right, and then perform some data extraction for comparison with measurements.
+
+### Background
+
+The turbulent flow though the 90 degree circular pipe bend can be seen in Figure 1 and is characterized by 3 flow phenomena that we will try to capture. First of all, the turbulent flow separates in the bend. The exact location depends on the Reynolds number and the radius of curvature of the bend. Secondly, the flow re-attaches after the bend and finally, two counter-rotating vortices are formed after the bend, called Dean vortices. This particular geometry was studied experimentally by Sudo, Sumida and Hibara (*Experiments in Fluids* 25, 1998) [doi](https://doi.org/10.1007/s003480050206) and simulation results can be found in Dutta, Saha, Nandi and Pal (*Eng. Science Technol.* 19(2), 2016) [doi](https://doi.org/10.1016/j.jestch.2015.12.005).
+
+### Problem Setup
+
+The configuration is a 90 degree bend with a diameter of D=0.104 m and a radius of curvature of 2D=0.208 m. We make use of the horizontal symmetry plane and only simulate the upper half of the pipe. The Reynolds number based on pipe diameter is 60,000, which corresponds to a mean velocity of 8.7 m/s. A straight section of L=5D is attached before and a section of L=10D is attached after the bend. Uniform velocity and turbulence boundary conditions are applied at the inlet. The entry length of 5L is not sufficient for turbulence to fully develop and in the experimental setup, the entry and exit lengths were 100D and 40D. This means that the flow conditions that we impose at the inlet are not the actual, fully developed turbulent flow profiles that were present in the experiment. However, This can be solved by first performing a simulation with uniform inlet conditions and then restarting the simulation with an imposed profile for all the transported variables. The inlet profile can be created with paraview from the CFD solution by extracting the solution at 4D downstream of the inlet, where the flow is already partially developed.
+
+### Mesh Description
+
+The mesh consists of a structured mesh with 70k cells and 75k points. The mesh was created using Gmsh and the configuration file to create the mesh can be found here: [sudo_coarse.geo](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Turbulent_Bend_Wallfunctions/sudo_coarse.geo). The only thing you need to do to create a mesh from the geometry is start Gmsh, and then load the .geo file. You will then see the geometry in the Gmsh visualization window. If you click on *Mesh->3D* the 3D mesh will be generated. You can then export the mesh as a .su2 file by choosing *File->Export*. The mesh will automatically be saved in su2 format when the filename has the extension .su2. In general, you should not choose *save all elements* because this will also save additional points that were used to construct the geometry but are not part of the final mesh, like for example the center of a circle.
+
+
+
+Figure (2): Mesh generated by Gmsh, showing the cross-sectional block structured mesh.
+
+### Configuration File Options
+
+Several of the key configuration file options for this simulation are highlighted here. First, we activate the turbulence model:
+
+```
+% ------------- direct, adjoint, and linearized problem definition ------------%
+%
+SOLVER= INC_RANS
+INC_NONDIM= DIMENSIONAL
+KIND_TURB_MODEL= SST
+SST_OPTIONS= V2003m
+```
+
+We use the incompressible RANS solver to activate the turbulence model and we then choose the SST turbulence model, using the `SST_OPTIONS= V2003m` variant.
+
+```
+INC_INLET_TYPE= VELOCITY_INLET
+INC_OUTLET_TYPE= PRESSURE_OUTLET
+```
+
+The inlet boundary is a velocity inlet and the outlet boundary is a pressure outlet.
+
+```
+MARKER_HEATFLUX= ( wall_1, 0.0, wall_2,0.0, wall_bend,0.0)
+MARKER_INLET= ( inlet, 300.0, 8.7, 0.0, 0.0, 1.0 )
+MARKER_OUTLET= ( outlet, 0.0)
+MARKER_SYM= ( symmetry_1, symmetry_bend, symmetry_2 )
+MARKER_INLET_TURBULENT= (inlet, 0.10, 100.0)
+```
+
+There is no heat transfer, so we set zero heatflux boundary conditions on the walls and we impose a velocity of 8.7 m/s, corresponding to the experiment of *Sudo et al.* The outlet pressure is set to 0 Pa. With the keyword **MARKER_INLET_TURBULENT**, we set the inlet turbulent intensity and the viscosity ratio. Now we are ready to set up the wall function model:
+
+```
+MARKER_WALL_FUNCTIONS= ( wall_1, STANDARD_WALL_FUNCTION, wall_2,STANDARD_WALL_FUNCTION, wall_bend, STANDARD_WALL_FUNCTION )
+WALLMODEL_KAPPA= 0.41
+WALLMODEL_B= 5.5
+WALLMODEL_MINYPLUS= 1.0
+WALLMODEL_MAXITER= 200
+WALLMODEL_RELFAC= 0.5
+```
+
+We activate the wall functions with a single option **MARKER_WALL_FUNCTIONS**. At this moment, the only wall function that you can use is the **STANDARD_WALL_FUNCTION**. Setting **MARKER_WALL_FUNCTIONS** is sufficient to set up the wall function model, but there are 5 additional expert options that you can set as well. The constant kappa is interpreted as the von Karman constant and is usually chosen as 0.41. The integration constant B is chosen as 5.5. The minimum value of y+ where the wall function is switched off because the mesh is fine enough to be considered fully resolved is 1.0. A value of 5.0 is the default value chosen in the paper of *Nichols and Nelson (2004)*, but lower values are also possible. Note that Spalding's fit gives us the nondimensional velocity and therefore the wall shear stress in the entire boundary layer.
+An iterative process (Newton's method) is used to compute the nondimensional velocity u+ from y+. The maximum number of iterations chosen here is 200, which is usually more than sufficient. The relaxation factor chosen for the Newton method is 0.5. If you see messages appearing like this:
+
+```Warning: computation of wall coefficients (y+) did not converge in 56 points```
+
+you can either let the computations continue until the warning messages disappear, increase the maximum number of iterations or decrease the relaxation factor. If these measures do not help, then the problem is most probably due to the mesh quality or due to the physics (flow separation).
+
+### Running SU2
+
+If possible, always use a parallel setup to increase computational time. Run the SU2_CFD executable in parallel using MPI and 4 nodes by entering
+
+ $ mpirun -n 4 SU2_CFD sudo.cfg
+
+Your results should converge in around 1000 iterations.
+
+### Results
+
+
+Figure (3): Velocity contour with location of the slices where experimental values were obtained.
+
+The paraview multiblock file can now be visualized, and the result is shown in Figure (3). Shown is the velocity magnitude on the horizontal symmetry plane together with a number of contour plots at several vertical locations in the bend.
+
+## Part 2 : restart with an inlet profile
+
+In the experiment, the pipe bend was preceded by a very long straight pipe section with a length of 100D, ensuring that the turbulent flow is fully developed by the time it arrives at the pipe bend. In our simulations, we have only a straight section with a total length of 5D and constant inlet properties. We will now restart the simulation with an inlet profile that we extract from a slice of the pipe. It is a planar slice with the normal in the Z-direction, located at Z=2.5D from the inlet. Because in a multiblock mesh, nodes are duplicated on the boundary, so we first perform an *Extract Block* and select only the interior nodes. We then apply the slice on this extracted block. To keep the original quadrilateral cells, we de-select the option *triangulate slice*. Also make sure that the option *Merge duplicated points in the slice* is selected. In the information tab, you should see that the number points is 618, and we will check later that this corresponds with the number of nodes that SU2 expects in the inlet boundary file.
+Now save the slice data, making sure that only the slice is selected in the Pipeline Browser. Choose the .csv file format, and choose as _Arrays To Write_ only the variables *Omega*, *Pressure*, *Velocity* and *Turb_Kin_Energy*. The point coordinates are automatically saved. Also choose scientific notation with precision "6" to make sure that you have enough digits for the accurate interpolation of the inlet profile. A simple pvpython script is provided in the tutorials folder here: [paraview_extract_slice_data.py](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Turbulent_Bend_Wallfunctions/paraview_extract_slice_data.py). This is a python script that you can run with paraview's pvpython command and it will generate an inlet.csv file for you :
+
+```
+$ pvpython paraview_extract_slice_data.py
+```
+
+
+
+With python, matlab or a simple *awk* command it is easy to put the data in the correct format for the SU2 inlet profile. The awk command below reads the file *inlet.csv*, it assumes that the comma acts as a separator, it skips the first line (the header), and then prints the necessary columns and outputs it in the file inlet_test. We want symmetric data in the y-axis, so we check if the y-coordinate in column 2 is positive, and then we write this data for positive and negative y-coordinates. We write the data into the file *inlet_test*.
+
+```
+awk -F ',' '(NR>1) {if ($2>0.0) {printf ("%8f \t %8f \t %8f \t %6f \t %6f \t %6f \t %f \t %6f \t %6f \t %6f\n ", -$2,$3,-0.52,300.0, $9, 0.0, 0.0, 1.0, $6, $1);printf ("%8f \t %8f \t %8f \t %6f \t %6f \t %6f \t %f \t %6f \t %6f \t %6f\n ", $2,$3,-0.52,300.0, $9, 0.0, 0.0, 1.0, $6, $1)}}' inlet.csv > inlet_data
+```
+
+
+
+Now we setup SU2 to use an inlet boundary file. We change some configuration options. Locate and change the following options in the file:
+
+```
+RESTART_SOL= YES
+SPECIFIED_INLET_PROFILE= YES
+INLET_FILENAME= inlet.dat
+```
+
+
+
+The solution was saved as *restart.dat* and the filename used for the restart is named *solution.dat* (locate the option for the filenames in the config file!). You can simply copy the *restart.dat* file to *solution.dat* and restart the simulation with the above options. If you restart and the file *inlet.dat* is not present, SU2 will stop with the message
+
+``` Looked for: inlet.dat.```
+```Created a template profile file with default values named example_inlet.dat```
+```You can use this file as a guide for making your own profile specification.```
+
+You will now have an example inlet profile saved in the file *example_inlet.dat*. You can now check that this file has 618 rows of data, for each of the nodes on the inlet plane. We only need the header (the first 5 lines of the file), so you can open the file, copy the first 5 lines, open the file *inlet_data* and add the 5 lines to the top of the file. You can now save this file as *inlet.dat* and restart the simulation.
+
+### Results
+
+We will now compare the simulation results of the pipe bend with results from the paper of *Sudo et al.* Some velocity measurements were performed at several locations in the pipe bend, and the location that we will use for comparison are shown in the figure below.
+
+
+
+Figure (4): Pipe bend showing the location of the slices that will be used for comparison with measurements.
+
+Below are some of the contour plots taken at several locations in the pipe, showing the velocity normal to the plane with the isocontours in black. The top half are the simulation results and the bottom half are the experimental results from *Sudo et al (1998)*. We see that the main flow features are captured in the simulation.
+
+
+
+
+
+Figure (5): mean flow velocities in several pipe cross sections.
+
+A paraview script to extract the slices data as individual contour plots one by one can be found here: [extract_contours_sudo_bend.py](https://github.com/su2code/Tutorials/blob/master/incompressible_flow/Inc_Turbulent_Bend_Wallfunctions/extract_contours_sudo_bend.py).
+
+Below is a comparison of the axial velocity on the horizontal symmetry line through the vertical plane at $$\phi=90^0$$. The flow separation in the bend is difficult to capture correctly, and it leads to an underestimation of the local velocity near the inner radius of the bend.
+
+
+
+Figure (6): velocity on the symmetry line in the vertical planar cross-section at $$\phi=90^0$$.
+
+The paraview script to extract the line data as a .csv file can be found here: [paraview_extract_linedata.py](https://github.com/su2code/Tutorials/blob/master/incompressible_flow/Inc_Turbulent_Bend_Wallfunctions/paraview_extract_linedata.py)
diff --git a/_tutorials/incompressible_flow/Inc_Urban_City/Inc_Urban_City.md b/_tutorials/incompressible_flow/Inc_Urban_City/Inc_Urban_City.md
new file mode 100644
index 00000000..78a43d65
--- /dev/null
+++ b/_tutorials/incompressible_flow/Inc_Urban_City/Inc_Urban_City.md
@@ -0,0 +1,181 @@
+---
+title: Wind velocity and pollutant dispersion in a city
+permalink: /tutorials/Inc_Urban_City/
+written_by: Nijso Beishuizen
+for_version: 8.4.0
+revised_by:
+revision_date:
+revised_version:
+solver: INC_NAVIER_STOKES
+requires: SU2_CFD
+complexity: intermediate
+---
+
+
+
+Figure (1): Flow through the streets of the city center of amsterdam.
+
+## Goals
+
+In this tutorial we will look at the modeling of wind speed and pollutant dispersion in a realistic depiction of a city - in this case the city center of Amsterdam. We will show the following aspects:
+- outline of creating a mesh of a city using GIS data
+- obtaining weather data of a specific date
+- simulate wind velocity to map pedestrian comfort.
+- simulate dispersion of a smoke cloud from a point source (burning car for instance) through streets to assess evacuation zone
+
+
+## Resources
+
+The resources for this tutorial can be found in the [incompressible_flow/Inc_Urban_City](https://github.com/su2code/Tutorials/tree/develop/incompressible_flow/Inc_Urban_City) directory in the [tutorial repository](https://github.com/su2code/Tutorials).
+
+
+### Background
+
+CFD simulations around buildings in a city have many applications. One application is to investigate pedestrian comfort due to strong winds that can occur around large buildings. Another application is the risk assessment in case of an accident where harmful polutants are released, for instance the smoke of a car fire. Both of these cases can be simulated with SU2 very easily. The challenge is in obtaining a mesh of the region of interest.
+
+Information about buildings, specifically their surface shape and often even their height and 3D shape, is available in many countries like the Netherlands. This data is stored in GIS-databases (Geographic Information System). Google maps and google earth are examples of well-known GIS databases. We will use 2D building information and create a 2D mesh from it.
+With a simple python script it is possible to retrieve information of buildings given a city name, or longitude-latitude coordinates.
+These building contours then need to be converted into a set of closed contours that can be given to a mesher like gmsh to create a 2D mesh for the SU2 CFD solver.
+
+
+### Pedestrian comfort: flow through the streets of Amsterdam
+
+What was the least comfortable street to walk on in the city center of Amsterdam, on new years day 2026 at noon?
+
+First, we need the average wind velocity at that time. A simple python script can get that information from open-meteo, given the latitude and longitude, using the python requests library:
+
+```python
+import requests
+city center of amsterdam
+[lat,lon]=[52.373080,4.892453]
+# Open-Meteo API endpoint (free, no API key needed)
+url = "https://api.open-meteo.com/v1/forecast"
+date="2026-01-01"
+#time=12:00
+params = {
+ 'latitude': lat,
+ 'longitude': lon,
+ 'start_date': date,
+ 'end_date': date,
+ 'daily': 'temperature_2m_mean,pressure_msl_mean,wind_speed_10m_max,wind_speed_10m_mean,wind_direction_10m_dominant,relative_humidity_2m_mean',
+ 'timezone': 'auto'
+ }
+response = requests.get(url, params=params)
+data = response.json()
+print(data)
+```
+
+We can also get the building information as polygons. For this information, we can use the overpass API (). We can grab all buildings within a certain radius from our given latitude and longitude. The core of the program is:
+```python
+overpass_url = "https://overpass-api.de/api/interpreter"
+ overpass_query = f"""
+ [out:json][timeout:60];
+ (
+ way["building"](around:{radius_meters},{latitude},{longitude});
+ relation["building"](around:{radius_meters},{latitude},{longitude});
+ way["building:part"](around:{radius_meters},{latitude},{longitude});
+ relation["building:part"](around:{radius_meters},{latitude},{longitude});
+ );
+ out geom;
+ """
+```
+This information can then be saved as polygon data to a file. The information that we retrieved is visualized in Figure 2:
+
+
+
+Figure 2: Visualization of the building information that was retrieved. The polygon data was saved as a pickle file for further processing.
+
+We found 1615 buildings in this region.
+With this polygon information, we can build a 2D CFD mesh, but the first step towards that goal is to merge all the connecting and overlapping buildings. For buildings that are not touching but are separated by a very small distance, we use the dilate-erode method. First, let buildings that are very close grow in size, then compute the new contours of the merged shapes, then erode the shapes again to go back to their original size. We also remove any contours with small surface areas. We are then left with only 125 buildings, a huge reduction!
+
+We can further smooth the shapes by using dilation-erosion, and also by using the Douglas-Peucker method to simplify polygons and reduce node and edge count. After this procedure we went from 10730 vertices to 2374 . We also remove all buildings with an are smaller than 25 square meters. We are now left with 115 buildings and 2209 edges.
+
+
+### Mesh Description
+
+The final step in creating this setup is to give all polygons to gmsh and create the mesh. We use a triangulated mesh with a quadrilateral inflation layer around the buildings. The final mesh is 786k cells.
+
+
+Figure 3: Gmsh mesh and zoom of the mesh around the royal palace showing the inflation layers.
+
+Note that the mesh is very coarse close to the wall and needs to be refined for more accurate results. For resolved boundary layers the dimensionless wall cell size needs to be $y^{+} < 1$.
+We have also made some simplifications in the geometry and physics. Note that cutting to a circular shape means that at the edges the results are inaccurate because we are missing the effect of buildings outside of the circular area. Also note that assuming a 2D planar scenario is not accurate. We do not take into account the different heights of the buildings and we also do not take into account that the wind blows over the entire city and has a downward component as well. So although this simulation will not accurately represent the wind velocity through the streets in a quantitative way, at least qualitatively they give an impression of the accelerating wind speeds through the streets of the city center.
+
+
+### Configuration File Options
+
+The setup itself is a standard setup. The main input is the velocity:
+```
+% wind speed on 01-01-2026 at 12:00 in Amsterdam (262 degrees 6.81 m/s)
+INC_VELOCITY_INIT = (6.74, 0.95, 0.0 )
+```
+
+And we need to define the boundaries. We only have a far-field and the walls of the building:
+```
+MARKER_FAR= farfield
+MARKER_HEATFLUX= wall_buildings
+```
+
+
+### Running SU2
+
+If possible, always use a parallel setup to reduce computational time (wall clock time). Run the SU2_CFD executable in parallel using MPI and 4 nodes by entering:
+
+ $ mpirun -n 4 SU2_CFD amsterdam.cfg
+
+
+
+
+### Results
+
+
+
+Figure (4): Zoom of the flow through the streets of the city center of amsterdam.
+
+The zoom of the wind velocity in Figure 4 shows the wind around the royal palace on the 'dam' with the national monument for war victims on the right. It is clear that walking through the 'paleisstraat' into the main square would have been very uncomfortable.
+
+
+### Fire!
+
+What if there was a fire on the main square? How would the smoke be transported by the wind through the streets of Amsterdam? This can be simulated very easily by adding a species source term using the python wrapper. We will use a simple circular constant source of smoke and add it to the species transport equation.
+```python
+# ################################################################## #
+# Source term for smoke/fire #
+# ################################################################## #
+def smoke(SU2Driver, iPoint, nDim):
+
+ allCoords = SU2Driver.Coordinates()
+ coord = allCoords.Get(iPoint)
+ x = coord[0]
+ y = coord[1]
+ R = np.sqrt(x*x + y*y)
+ # source size: R = 5 m, source term located at center (0,0)
+ if (R < 5.0):
+ # source is kg.m^-3.s^-1
+ Sc = 0.1
+ else:
+ Sc = 0.0
+ return Sc
+
+```
+
+This source term was added to a standard python wrapper script, the configuration file was left unchanged, except for the addition of the keyword
+```bash
+PYTHON_CUSTOM_SOURCE= YES
+```
+to activate the custom source term.
+
+
+
+Figure (5): Zoom of the 'Dam' square in front of the royal palace.
+
+Figure 5 clearly shows that the smoke blows into the 'Damrak' street.
+
+
diff --git a/_tutorials/incompressible_flow/Inc_Von_Karman/Inc_Von_Karman.md b/_tutorials/incompressible_flow/Inc_Von_Karman/Inc_Von_Karman.md
new file mode 100644
index 00000000..83a221f8
--- /dev/null
+++ b/_tutorials/incompressible_flow/Inc_Von_Karman/Inc_Von_Karman.md
@@ -0,0 +1,207 @@
+---
+title: Unsteady von Karman vortex shedding
+permalink: /tutorials/Inc_Von_Karman/
+written_by: Nijso Beishuizen
+for_version: 8.0.1
+revised_by:
+revision_date:
+revised_version:
+solver: INC_NAVIER_STOKES
+requires: SU2_CFD
+complexity: intermediate
+---
+
+
+
+Figure (1): impression of the von Karman vortex shedding. A high quality mp4 video can be found [here](../../../tutorials_files/incompressible_flow/Inc_Von_Karman/images/unsteady_cylinder.mp4)
+
+## Goals
+
+In this tutorial we will simulate the laminar but unsteady vortex shedding behind a 2D circular cylinder, also known as von Karman vortex shedding. The unsteady pattern behind the cylinder is known as a von Karman sheet. In this tutorial we will touch upon the following aspects:
+- Setting up an unsteady simulation in SU2
+- Choosing appropriate settings for the unsteady simulation
+- Inspecting the effects of our choices for the numerical setup
+- Creating movies with paraview
+- Extracting the shedding frequency with paraview
+- visualize the forces on the cylinder with paraview
+
+
+## Resources
+
+The resources for this tutorial can be found in the [incompressible_flow/Inc_Von_Karman](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Von_Karman_Cylinder) directory in the [tutorial repository](https://github.com/su2code/Tutorials). You will need the configuration file ([unsteady_incomp_cylinder.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Von_Karman_Cylinder/unsteady_incomp_cylinder.cfg)) and the mesh file ([cylinder_wake.su2](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Von_Karman_cylinder/cylinder_wake.su2)). Additionally, the Gmsh geometry is also provided so you can recreate the mesh yourself: [cylinder_wake.geo](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Von_Karman_Cylinder/cylinder_wake.geo).
+
+
+### Background
+
+When the Reynolds number $$Re=\rho \cdot V \cdot D / \mu$$ is low (Re < 40), the flow around a circular cylinder is laminar and steady. At around Re=49, the flow becomes unsteady and a periodic shedding of vortices forms in the wake of the cylinder, known as vortex shedding. The frequency of this vortex shedding is usually expressed in terms of the Strouhal number $$St= f \cdot D / U_{\infty}$$, with f the shedding frequency, D the diameter of the cylinder and U the far-field velocity. Important experimental work can be found in the paper of Williamson, *Vortex Dynamics in the Cylinder Wake*, Annual Review of Fluid Mechanics (1996) [doi](https://doi.org/10.1146/annurev.fl.28.010196.002401). After around Re=180, a second frequency is observed experimentally, in the longitudinal direction. This frequency can only be observed in a 3D simulation. The increase in number of frequencies continues until after around Re=1000 the flow is considered fully turbulent.
+
+### Problem Setup
+
+The configuration is a circular cylinder of diameter $$D=0.01 m$$ surrounded by a far field at $$L = 30 D$$ and a rectangular wake region of $$X = 150 D$$. The far-field velocity is $$U_{\infty} = 0.12 m/s$$. With a viscosity of $$\mu=1.0 \cdot 10^{-5}$$ and a density of $$\rho = 1 kg/m3$$, the Reynolds number is $$Re = 120$$.
+
+
+Figure 2: Computational domain for the von Karman vortex shedding.
+
+The solution is initialized with uniform flow conditions. After an initial phase of around 4 seconds, the flow becomes periodic with a specific frequency depending on the Reynolds number.
+
+
+### Mesh Description
+
+The mesh consists of a structured mesh with 70k cells and 75k points. The mesh was created using Gmsh and the configuration file to create the mesh can be found here: [cylinder_wake.geo](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Von_Karman/cylinder_wake.geo). The only thing you need to do to create a mesh from the geometry is start Gmsh, and then load the .geo file. You will then see the geometry in the Gmsh visualization window. If you click on *Mesh->2D* the 2D mesh will be generated. You can then export the mesh as a .su2 file by choosing *File->Export*. The mesh will automatically be saved in su2 format when the filename has the extension .su2. In general, you should not choose *save all elements* because this will also save additional points that were used to construct the geometry but are not part of the final mesh, like for example the center of a circle.
+
+
+### Configuration File Options
+
+Several of the key configuration file options for this simulation are highlighted here. First, we activate the turbulence model:
+
+```
+SOLVER= INC_NAVIER_STOKES
+INC_NONDIM= DIMENSIONAL
+KIND_TURB_MODEL= NONE
+```
+
+We use the incompressible NAVIER-STOKES without turbulence model, since the flow is unsteady but laminar.
+
+```
+TIME_DOMAIN = YES
+TIME_MARCHING= DUAL_TIME_STEPPING-2ND_ORDER
+TIME_STEP= 0.005
+MAX_TIME=25.00
+TIME_ITER=2500
+INNER_ITER= 20
+```
+
+The **TIME_DOMAIN** keyword activates transient simulations. We use a second order timestep, with a step size of $$\Delta t = 0.01 s$$. The maximum time is set to $$t_{max} = 25 s$$ or 2500 iterations, whichever is reached first. We use 20 inner iterations per timestep, which sufficiently converges the residuals. This is important to check, insufficient convergence per time step quickly leads to large errors.
+
+```
+INC_VELOCITY_INIT= ( 0.12, 0.0, 0.0 )
+MARKER_HEATFLUX= ( cylinder, 0.0 )
+MARKER_FAR= ( farfield_in,farfield_side,farfield_out )
+MARKER_MONITORING= ( cylinder )
+```
+
+There is no heat transfer, so we set zero heatflux boundary conditions on the walls and we impose a far-field velocity of 0.12 m/s. The **MARKER_MONITORING** keyword is used to monitor forces at the cylinder surface. We are interested in the lift and drag coefficient.
+
+```
+% monitoring points in the cylinder wake
+CUSTOM_OUTPUTS= 'velocity : Macro{sqrt(pow(VELOCITY_X, 2) + pow(VELOCITY_Y, 2) )};\
+ probe1 : Probe{$velocity}[0.15, 0.0]'
+HISTORY_OUTPUT= (TIME_ITER, CUR_TIME, RMS_RES, LIST, DRAG, LIFT, SURFACE_STATIC_PRESSURE, CUSTOM)
+```
+
+We define a monitoring point called *probe1* at location $$(x,y)=(0.15, 0.0)$$ downstream of the cylinder and at the centerline. In this probe, we monitor the velocity magnitude $velocity$, that we compute from the existing velocity components. We write the probe information to the history output using the keyword **CUSTOM**.
+
+
+### Running SU2
+
+If possible, always use a parallel setup to reduce computational time (wall clock time). Run the SU2_CFD executable in parallel using MPI and 4 nodes by entering:
+
+ $ mpirun -n 4 SU2_CFD unsteady_incomp_cylinder.cfg
+
+
+
+### Results
+
+
+Figure (3): Developed von Karman street with injected particles.
+
+The figure above shows the von Karman vortices. A movie of the von Karman Vortex shedding as shown in this tutorial can be made using the paraview statefile here: [statefile_with_particles.pvsm](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Von_Karman_Cylinder/statefile_with_particles.pvsm). The colored vorticity gradients are created in the wake immediately behind the cylinder, and transported downstream. In paraview, we inject particles and let them be transported downstream over streamlines. We can clearly see that the particles are not mixed homogeneously but are being transported in batches of red and green particles moving with their corresponding vortices.
+
+
+
+
+A link to a high quality video can be found [here](https://github.com/su2code/su2code.github.io/tree/master/tutorials_files/incompressible_flow/Inc_Von_Karman/images/unsteady_cylinder_arrow.mp4).
+
+The forces on the cylinder can also be visualized, see the above movie. We see the unsteady velocity magnitude, and on the cylinder surface we visualize the local force as the local pressure normal to the surface. For this we need to extract the surface data only and then compute the surface normal using a programmable filter. We can then visualize the glyph distribution. The total lift force is the integrated vertical component, whose size can be visualize as a colored arrow of a size proportional to the lift force using another programmable filter. Below the image we visualize the lift force in time using the PlotSelectionOverTime feature.
+
+
+
+Figure (4): Strouhal number, comparison with experimental data from Williamson (2006).
+
+The Strouhal number can be computed from the lift coefficient that was stored in the history.csv file. A simple python file gives us the frequency from the FFT:
+
+```python
+#%matplotlib inline
+#import matplotlib.pyplot as plt
+import pandas as pd
+import numpy as np
+import scipy.fftpack
+import csv
+
+# Return value belonging to key in config.cfg
+# (splits key= value for you)
+def find_config_key_value(filename,config_key):
+ with open(filename, "r") as file:
+ for line in file:
+ line = line.split('=')
+ if line[0] == config_key:
+ print(line[-1].strip() )
+ return(line[-1].strip())
+ raise ValueError('key not found:',config_key)
+
+# diameter of cylinder
+D = 0.01
+
+# read history, use comma as separator, with zero or more spaces before or after
+df = pd.read_csv('history.csv', sep='\s*,\s*')
+
+T = float(find_config_key_value('unsteady_incomp_cylinder.cfg','TIME_STEP'))
+U = find_config_key_value('unsteady_incomp_cylinder.cfg','INC_VELOCITY_INIT')
+N = len(df.index)
+print('timestep=',T)
+print('samplepoints=',N)
+print('velocity=',U)
+U = float(U.replace('(','').replace(')','').split(',')[0].strip())
+print('velocity=',U)
+
+# assign data
+x = df['"Cur_Time"']
+y = df['"CL"']
+
+# compute DFT with optimized FFT
+xf = np.linspace(0.0, 1.0/(2.0*T), N//2)
+yf = np.fft.fft(y)
+yf2 = 2.0/N * np.abs(yf[:N//2])
+
+#fig, ax = plt.subplots()
+#plt.xlim(0,5.0)
+#ax.plot(xf, yf2 )
+#plt.show()
+
+print("index of max = ",np.argmax(yf2))
+freq = xf[np.argmax(yf2)]
+print("frequency of max = ",freq)
+St = freq * D / U
+print("strouhal number = ",St)
+```
+
+
+When we compare the Strouhal number with the experimental data from Williamson, we see in Figure 4 that the frequency is slightly overpredicted. We will vary some numerical settings to investigate the impact on the prediction of the Strouhal number.
+
+
+
+### Numerical variations
+
+
+
+Figure (5): Comparison of different numerical settings.
+
+In Figure 5, we see the effect of different numerical settings on the prediction of the Strouhal number. The second order scheme predicts a Strouhal number of $$St = 0.1734$$, slightly over predicting the experimental value of $$St_{exp} = 0.170$$. Note that our predictions of the Strouhal frequency depends on the number of samples and sampling rate that we provide to the FFT. We took 2500 timesteps of 0.01 s which contains enough cycles for an accurate frequency prediction using an fft.
+When switching from second order in time to first order, the Strouhal number is under predicted by 6 % compared to the experimental value. Also, when increasing the time step from 0.01 s to 0.02 seconds, the St decreases by 2 \%. When increasing the time step even further to $$ \Delta t = 0.04 s $$, St is under predicted by 8 %. The period of the dimensional frequency is $$f \approx 0.5 s$$, so with a timestep of 0.01 s we have 50 time steps per period, we have 25 time steps when $$\Delta t = 0.02 s$$, and only 12 time steps when $$\Delta t = 0.04 s$$. It is clear that 12 time steps per period is not sufficient.
+
+It is also known that the size of the computational domain influences the results, so we reduce the domain by half, $$L = 15 D$$ and $$X = 75 D$$. The Strouhal then increases to $$St = 0.1768$$, an increase of 2 %. It seems that a far-field that is 15D away from the cylinder is sufficient.
+
+As a final test, the testcase can be executed for varying Reynolds numbers, ranging from Re=60 to Re=180, giving the result in Figure (6).
+
+
+
+Figure (6): Comparison of numerical Strouhal numbers with experiments for varying Reynolds numbers.
+
+We get a pretty good agreement compared to the experimentally measured values.
+
+### Final notes
+
+The paraview statefile to create the movie can be found here: [statefile_with_particles.pvsm](https://github.com/su2code/Tutorials/blob/master/incompressible_flow/Inc_Von_Karman/statefile_with_particles.pvsm)
+and here:
+[statefile_movablearrow_timeseries.pvsm](https://github.com/su2code/Tutorials/blob/master/incompressible_flow/Inc_Von_Karman/statefile_movablearrow_timeseries.pvsm)
+Note that you have to select your own, local files when you load the statefile.
diff --git a/_tutorials/index.md b/_tutorials/index.md
index a2e84cb0..0a0c86f1 100644
--- a/_tutorials/index.md
+++ b/_tutorials/index.md
@@ -38,8 +38,10 @@ Simulation of external, laminar flow over a flat plate (classical Navier-Stokes
Simulation of external, laminar flow around a 2D cylinder.
* [Turbulent Flat Plate](/tutorials/Turbulent_Flat_Plate/)
Simulation of external, turbulent flow over a flat plate (classical RANS validation).
-* [Transitional Flat Plate](/tutorials/Transitional_Flat_Plate/)
+* [Transitional Flat Plate(BC transition model)](/tutorials/Transitional_Flat_Plate/)
Simulation of external, transitional flow over a flat plate (transitional latminar-turbulent case).
+* [Transitional Flat Plate(LM transition model)](/tutorials/Transitional_Flat_Plate_T3A/)
+Simulation of external, transitional flow over a flat plate(T3A & T3A-) (transitional latminar-turbulent case).
* [Turbulent ONERAM6](/tutorials/Turbulent_ONERAM6/)
Simulation of external, viscous flow around a 3D geometry (isolated wing) using a turbulence model.
* [Unsteady NACA0012](/tutorials/Unsteady_NACA0012/)
@@ -48,6 +50,12 @@ Simulation of unsteady, external, viscous flow around an airfoil.
Perform uncertainty quantification of errors arising due to assumptions inherent in turbulence models.
* [Non-ideal compressible flow in a supersonic nozzle](/tutorials/NICFD_nozzle/)
Simulation of compressible flow in a nozzle using non-ideal thermodynamic models.
+* [Data-driven equation of state for non-ideal compressible fluids](/tutorials/NICFD_nozzle_datadriven/)
+Demonstration of data-driven equation of state using a physics-informed neural network.
+* [Turbomachinery: Aachen Turbine stage with mixing plane](/tutorials/Aachen_Turbine/)
+Simulation of compressible flow of the Aachen turbine demonstrating turbomachinery application.
+* [Actuator Disk with Variable Load](/tutorials/ActuatorDisk_VariableLoad/)
+Simulation of an actuator disk with variable load.
#### Incompressible Flow
@@ -56,17 +64,28 @@ A simulation of internal, inviscid, incompressible flow around a NACA 0012 hydro
* [Laminar Flat Plate with Heat Transfer](/tutorials/Inc_Laminar_Flat_Plate/)
Simulation of external, laminar, incompressible flow over a flat plate (classical Navier-Stokes case).
* [Turbulent Flat Plate](/tutorials/Inc_Turbulent_Flat_Plate/)
-Simulation of external, turbulentm incompressible flow over a flat plate (classical RANS case).
+Simulation of external, turbulent incompressible flow over a flat plate (classical RANS case).
* [Turbulent NACA 0012](/tutorials/Inc_Turbulent_NACA0012/)
Simulation of external, viscous, incompressible flow around the NACA 0012 using a turbulence model.
* [Laminar Backward-facing Step](/tutorials/Inc_Laminar_Step/)
Simulation of internal, laminar, incompressible flow over a backward-facing step with an inlet velocity profile input from file.
* [Laminar Buoyancy-driven Cavity](/tutorials/Inc_Laminar_Cavity/)
Simulation of internal, laminar, incompressible flow in a differentially-heated cavity under the influence of gravity (classical natural convection case).
-* [Heated Cylinders with Conjugate Heat Transfer](/tutorials/Inc_Heated_Cylinders/)
-Simulation of a coupled CHT problem incorporating multiple physical zones.
+* [Streamwise Periodicity](/tutorials/Inc_Streamwise_Periodic/)
+Simulation of internal, turbulent, incompressible flow in a unit cell of a 2D pin-fin heat exchanger.
+* [Species Transport](/tutorials/Inc_Species_Transport/)
+Simulation of internal, turbulent, incompressible flow through a mixing channel.
+* [Species Transport Composition Dependent Model](/tutorials/Inc_Species_Transport_Composition_Dependent_Model/)
+Simulation of internal, turbulent, 3D incompressible flow through a Kenics static mixer.
+* [Vortex Shedding](/tutorials/Inc_Von_Karman/)
+Simulation of unsteady laminar vortex shedding behind a circular cylinder.
+* [Turbulent Bend](/tutorials/Inc_Turbulent_Bend/)
+Simulation of turbulent flow in a 90 degree pipe bend using wall functions.
+* [Urban City](/tutorials/Inc_Urban_City/)
+Simulation of wind velocity and smoke through the city center of Amsterdam.
#### Structural Mechanics
+
* [Linear Elasticity](/tutorials/Linear_Elasticity/)
Simulation of an elasticity problem with small deformations
* [Linear Dynamics](/tutorials/Linear_Dynamics/)
@@ -77,18 +96,35 @@ Simulation of a non-linear structural problem with large deformations
Simulation of a non-linear problem with multiple material definitions
#### Multiphysics
+
* [Static Fluid-Structure Interaction](/tutorials/Static_FSI/)
Non-linear structural mechanics coupled with incompressible Navier-Stokes flow
+* [Dynamic Fluid-Structure Interaction with the Python wrapper](/tutorials/Dynamic_FSI_Python/)
+Linear Nastran-like model coupled with compressible unsteady RANS equations using the Python wrapper.
+* [Static Conjugate Heat Transfer](/tutorials/Static_CHT/)
+Simulation of multiple heated cylinders in incompressible fluid flow.
+* [Unsteady Conjugate Heat Transfer](/tutorials/Inc_Heated_Cylinders_Unsteady/)
+Simulation of an unsteady coupled CHT problem incorporating multiple physical zones.
+* [Conjugate Heat Transfer between Solid Domains](/tutorials/SS_CR_CHT/)
+Simulation of CHT between solid domains with contact resistance.
+* [Pre-mixed Hydrogen Combustion](/tutorials/Inc_Combustion/)
+Simulation of a laminar, pre-mixed hydrogen flame on a cooled burner plate.
+* [Python wrapper for User Defined Functionality](/tutorials/TFC_python/)
+Use the Python wrapper to setup user defined source terms, initial conditions and boundary conditions for combustion.
#### Shape Design Features
-* [Unconstrained shape design of an transonic inviscid airfoil at a cte. AoA](/tutorials/Inviscid_2D_Unconstrained_NACA0012/)
+* [Unconstrained shape design of an transonic inviscid airfoil at a cte. AoA](/tutorials/Inviscid_2D_Unconstrained_NACA0012/)
Get a basic introduction to the SU2 design capabilities by performing an optimal shape design of a 2D geometry (isolated airfoil) without constraints.
* [Constrained shape design of a transonic turbulent airfoil at a cte. CL](/tutorials/Turbulent_2D_Constrained_RAE2822/)
Perform an optimal shape design of a 2D geometry (isolated airfoil at turbulent regime) with flow and geometrical constraints.
* [Constrained shape design of a transonic inviscid wing at a cte. CL](/tutorials/Inviscid_3D_Constrained_ONERAM6/)
Learn the basis of 3D design by performing an optimal shape design of an isolated wing with geometrical constraints.
* [Multi-Objective Shape Design of an Inviscid Supersonic Ramp](/tutorials/Multi_Objective_Shape_Design/)
- Perform an optimal shape design with multiple objectives and a penalty function
+Perform an optimal shape design with multiple objectives and a penalty function
* [Unsteady Shape Optimization](/tutorials/Unsteady_Shape_Opt_NACA0012/)
- Shape optimization of an 2D airfoil in unsteady flow conditions.
+Shape optimization of an 2D airfoil in unsteady flow conditions.
+* [Species Transport](/tutorials/Species_Transport/)
+Optimization of internal, turbulent, incompressible flow through a mixing channel.
+* [Optimizing pressure drop of a pipe bend](/tutorials/Inc_Turbulent_Bend_Opt/)
+Optimization of the pressure drop (also known as head loss), of a pipe bend.
diff --git a/_tutorials/multiphysics/TFC_python/TFC_python.md b/_tutorials/multiphysics/TFC_python/TFC_python.md
new file mode 100644
index 00000000..c68c858b
--- /dev/null
+++ b/_tutorials/multiphysics/TFC_python/TFC_python.md
@@ -0,0 +1,319 @@
+---
+title: User Defined combustion model with Python
+permalink: /tutorials/TFC_python/
+written_by: Nijso Beishuizen
+for_version: 8.3.0
+revised_by:
+revision_date:
+revised_version:
+solver: INC_NAVIER_STOKES
+requires: SU2_CFD, python
+complexity: advanced
+---
+
+
+Figure (1): high-pressure turbulent premixed flame of the Paul-Scherrer Institute (PSI), Switzerland
+
+## Goals
+
+In this tutorial we will simulate a high pressure turbulent premixed flame using the Turbulent Flamespeed Closure (TFC) model. This is a simple turbulent combustion model that can be implemented with a User Defined Source (UDS) in python.
+In this tutorial we will touch upon the following aspects:
+- Compile and run SU2 from within python using the python wrapper
+- Create a User Defined Source
+- Create User Defined boundary conditions
+- Create User Defined initial conditions
+- Overwrite the enthalpy (temperature) field with a user defined field
+
+
+## Resources
+
+The resources for this tutorial can be found in the [TFC_python](https://github.com/su2code/Tutorials/tree/develop/multiphysics/TFC_python) directory in the [tutorial repository](https://github.com/su2code/Tutorials). You will need the configuration file ([psi.cfg](https://github.com/su2code/Tutorials/tree/develop/multiphysics/TFC_python/adiabatic/psi.cfg)) and the mesh file ([psi.su2](https://github.com/su2code/Tutorials/tree/develop/multiphysics/TFC_python/adiabatic/psi.su2)). Additionally, the Gmsh geometry is also provided so you can recreate the mesh yourself: [psi.geo](https://github.com/su2code/Tutorials/tree/develop/multiphysics/TFC_python/psi.geo). Files for the non-adiabatic case are in the folder [enthalpy](https://github.com/su2code/Tutorials/tree/develop/multiphysics/TFC_python/enthalpy) and files for the case with source term quenching and custom wall boundary conditions are in the folder [quench](https://github.com/su2code/Tutorials/tree/develop/multiphysics/TFC_python/quench)
+
+
+### Background
+
+Turbulent combustion can be very expensive to simulate, especially when high accuracy is required and detailed information about specific species (NOx emissions for instance) is required. The Turbulent Flamespeed Closure (TFC) model, first pioneered by Zimont, is a very simple model for turbulent premixed combustion that aims to give accurate predictions for temperature in turbulent premixed combustion. When the goal is to mainly resolve the flame structure and gas temperature to compute for instance burner temperatures in a conjugate heat transfer setup, then the TFC model has sufficient accuracy. In the TFC model, a transport equation for the progress variable is solved:
+
+$$ \frac{\partial c}{dt} + \nabla \cdot (\rho u c) = \nabla\cdot (\frac{\mu_t}{Sc_t}\nabla c) + \rho S_c$$
+
+and the combustion source term is given by
+$$ S_c = \rho_u U_t \nabla c$$,
+with $$\rho_u$$ the unburnt density of the gas an $$U_t$$ the turbulent flamespeed. The Zimont model uses the gradient of the progress variable to construct the source term, but other models exist as well. These models can be implemented easily in SU2 by writing a user defined source term in the python wrapper.
+
+### Problem Setup
+
+First, SU2 needs to be compiled with python support. Add the option *-Denable-pywrapper=true* to the meson setup. In this case, we compile including mpi support:
+
+```bash
+$ ./meson.py setup build --optimization=2 -Ddebug=false -Denable-pywrapper=true -Dwith-mpi=enabled -Dcustom-mpi=true --prefix=/home/user/Codes/su2code/su2/
+```
+
+Note that the python wrapper (or your python setup) might need additional python packages that you need to install. Especially the python package mpi4py is important if you would like to work with mpi. The mpi4py package should match your installed mpi library, usually openmpi or mpich. The easiest way to setup a working environment is to create a conda environment and install all necessary packages in this environment.
+
+
+### Mesh Description
+
+The geometry of this testcase is provided as a gmsh file and matches the of the experimental setup of Griebel et al (2007), [doi](https://doi.org/10.1016/j.proci.2006.07.042).
+
+The mesh consists of a a coarse structured mesh with 16.3k cells and 16.6k points. The mesh was created using Gmsh and the configuration file to create the mesh can be found here: [psi.geo](https://github.com/su2code/Tutorials/tree/develop/multiphysics/TFC_python/psi.geo). The only thing you need to do to create a mesh from the geometry is start Gmsh, and then load the .geo file. You will then see the geometry in the Gmsh visualization window. If you click on *Mesh->2D* the 2D mesh will be generated. You can then export the mesh as a .su2 file by choosing *File->Export*. The mesh will automatically be saved in su2 format when the filename has been given the extension .su2. In general, you should not choose *save all elements* because this will also save additional points that were used to construct the geometry but are not part of the final mesh, like for example the center of a circle.
+
+
+### Configuration File Options
+
+The setup for this testcase consists of 2 files:
+- the run.py file is the python file that runs the case. in this file, we simply import the su2 capabilities using *import pysu2*
+- the psi.cfg file for the basic setup. Some settings will be overwritten by python.
+
+In the configuration file, we have set up a case for turbulent incompressible flow using the k-omega SST model. We have also deactivated the energy equation (sensible enthalpy) and species transport.
+```
+SOLVER= INC_RANS
+KIND_TURB_MODEL= SST
+INC_ENERGY_EQUATION= NO
+KIND_SCALAR_MODEL= SPECIES_TRANSPORT
+PYTHON_CUSTOM_SOURCE= YES
+```
+
+Note that the although the enthalpy equation is not solved, the enthalpy field is present. It is just a constant field and not altered by any computation. Every iteration, the temperature is computed from the enthalpy field, independent of the energy equation being active or not.
+To activate the custom source term, the keyword **PYTHON_CUSTOM_SOURCE= YES** is used.
+
+in the python file, we have defined several functions to set up the testcase. The first function creates a simple initial condition for the progress variable c:
+```python
+
+################################################################## #
+# create a function for the initial progress variable c #
+# ################################################################ #
+def initC(coord):
+ x = coord[0]
+ #y = coord[1]
+ #z = coord[2]
+ # location where the flame should be
+ flame_x = 0.012
+ if (x < flame_x):
+ C = 0.0
+ else:
+ C = 1.0
+
+ return C
+
+# ###################################################################
+# loop over all vertices and set the species progress variable c #
+# ################################################################# #
+def SetInitialSpecies(SU2Driver):
+ allCoords = SU2Driver.Coordinates()
+ iSPECIESSOLVER = SU2Driver.GetSolverIndices()['SPECIES']
+ for iPoint in range(SU2Driver.GetNumberNodes()):
+ coord = allCoords.Get(iPoint)
+ C = initC(coord)
+ # now update the initial condition for the species
+ SU2Driver.Solution(iSPECIESSOLVER).Set(iPoint,0,C)
+
+```
+
+
+Figure(2): initial temperature field created using the python wrapper
+
+Note that when setting the species solution, we use the index=0, because we have only 1 species transport equation. When setting a flow solution, the index to the required field should be used. The indices can be retrieved using:
+```python
+print("indices of solver variables: ", getsolvar(driver))
+```
+with the result:
+```
+indices of solver variables: {'PRESSURE': 0, 'VELOCITY_X': 1, 'VELOCITY_Y': 2, 'TEMPERATURE': 3}
+```
+
+Note that index 3 is actually the sensible enthalpy, and from this, we compute the temperature. In our setup we want to overwrite the temperature. Because internally, temperature is always computed from the energy equation (be that temperature, or enthalpy), it is best to overwrite the enthalpy and let SU2 compute the temperature internally.
+
+in the main function, we simply check in the config file if **RESTART=YES** to decide if we want to overwrite the initial solution for the progress variable with our user defined initial solution:
+
+```python
+ # ### Check if we do a restart or not. ###
+ with open('psi.cfg') as f:
+ if 'RESTART_SOL= YES' in f.read():
+ if rank == 0:
+ print("restarting from file")
+ else:
+ # We can set an initial condition by calling this function:
+ if rank == 0:
+ print("Using user defined initial condition.")
+ SetInitialSpecies(driver)
+
+```
+
+The functions *update_temperature* and *zimont* implement the algebraic temperature relationship and the source term for the progress variable. Then in the main function, we simply loop over all points in the domain, compute the source term and add it to the progress variable equation:
+```python
+ Source = driver.UserDefinedSource(iSPECIESSOLVER)
+
+ # set the source term, per point
+ for i_node in range(driver.GetNumberNodes() - driver.GetNumberHaloNodes()):
+ # add source term:
+ # default TFC of Zimont: rho*Sc = rho_u * U_t * grad(c)
+ S = zimont(driver,i_node)
+ Source.Set(i_node,0,S)
+
+```
+
+Note that we do not add the source term to the halo nodes, which are used in parallel computing. In parallel computing we divide the mesh in parts and each cpu gets a part, which is called a rank. The points on the interface between ranks need information from the other side of the interface. But this information is computed on another rank and not directly available. This is why each rank has halo points, which are copies of the points on the other side of the rank. During a synchronisation step, all information in the halo nodes is updated so the local computations on each of the ranks can proceed with the correct information present at the rank boundaries. They should not be taken into account in any computation, because they are in fact copies of points that *are* taken into account during the computation.
+For the temperature update, we update all points, including the halo points. Because we overwrite the entire enthalpy (and temperature) field, and no other computations are performed on the enthalpy field, the halo points would not get updated and not updating them will lead to incorrect computations of gradients at the rank interface.
+
+```python
+ # for the update of temperature, we need to update also the halo nodes
+ for i_node in range(driver.GetNumberNodes()):
+ # set the temperature to T = c*Tf + (1-c)*Tu
+ update_temperature(driver, i_node)
+```
+
+The actual temperature update is done in update_temperature:
+```python
+# ################################################################## #
+# Temperature is an algebraic function of c
+# ################################################################## #
+def update_temperature(SU2Driver, iPoint):
+ # first, get the progress variable
+ iSPECIESSOLVER = SU2Driver.GetSolverIndices()['SPECIES']
+ # Note: returns a list
+ C = SU2Driver.Solution(iSPECIESSOLVER)(iPoint,0)
+ T = Tu*(1-C) + Tf*C
+
+ iFLOWSOLVER = SU2Driver.GetSolverIndices()['INC.FLOW']
+ # 0 1 2 3
+ # pressure, velocity-x, velocity-y, enthalpy
+ iENTH = 3
+ SU2Driver.Solution(iFLOWSOLVER).Set(iPoint,iENTH, cp_u*(T-Tref))
+```
+We update the sensible enthalpy and let SU2 compute the temperature internally.
+
+The computation of the source term according to Zimon is given by:
+```python
+# ################################################################## #
+# Source term according to Zimont
+# ################################################################## #
+def zimont(SU2Driver, iPoint, nDim):
+
+ iSSTSOLVER = SU2Driver.GetSolverIndices()['SST']
+ tke, dissipation = SU2Driver.Solution(iSSTSOLVER)(iPoint)
+
+ iSPECIESSOLVER = SU2Driver.GetSolverIndices()['SPECIES']
+ # get the gradient of species_0
+ gradc = SU2Driver.Gradient(iSPECIESSOLVER)(iPoint,0)
+ primindex = SU2Driver.GetPrimitiveIndices()
+ iDENSITY = primindex.get("DENSITY")
+ iMU = primindex.get("LAMINAR_VISCOSITY")
+
+ rho = SU2Driver.Primitives()(iPoint,iDENSITY)
+ mu = SU2Driver.Primitives()(iPoint,iMU)
+ nu=mu/rho
+ # Turbulent Flamespeed Closure with Dinkelacker correction
+ up = np.sqrt((2.0/3.0) * tke )
+ lt = (0.09**0.75) * (tke**1.5) / dissipation
+ Re = up*lt/nu
+
+ Ut = Slu * (1.0 + (0.46/Le) * np.power(Re,0.25) * np.power(up/Slu,0.3) * np.power(Pu,0.2) )
+
+ norm_gradc = 0.0
+ for idim in range(nDim):
+ norm_gradc += gradc[idim]*gradc[idim]
+ norm_gradc = np.sqrt(norm_gradc)
+ Sc = rho_u * Ut * norm_gradc
+
+ return Sc
+```
+Note that we are using here a different formulation for the turbulent velocity, as described in papers by Dinkelacker and Muppala. The turbulence velocity is now such that if the turbulent kinetic energy is zero, the laminar flame velocity is retrieved. We also include a correction for the Lewis number to take into account the effect of preferential diffusion on the flame speed. This allows to work with hydrogen as a fuel as well. Note that for accurate simulations of hydrogen flames, especially in the laminar regime, preferential diffusion needs to be taken into account in a more elaborate way by introducing the mixture fraction and by considering the flame as a partially premixed flame (even a perfectly premixed hydrogen flame will become partially premixed in the flame zone).
+
+
+### Running SU2
+
+If possible, always use a parallel setup to reduce computational time (wall clock time). Run the SU2_CFD executable in parallel using MPI and 4 nodes by entering:
+
+```bash
+$ mpirun -n 4 python run.py
+```
+
+
+### Results
+
+
+Figure (3): visualization of the TFC source term for the turbulent combustion model, together with the streamlines.
+
+
+The solution of the flame region can be visualised using the User Defined Source UDS_0. A large recirculation region has also formed between the flame and the wall of the combustion chamber, causing heat transfer between the flame and the wall.
+
+Note that we clip the species between [0,1] to prevent (temporary) unphysical values and prevent divergence. Sometimes this clipping is necessary on coarse grids. The clipping will be visible in the residuals of the progress variable, since clipping prevents local convergence.
+
+### Heat losses: enthalpy source term
+
+When heat losses at the wall need to be taken into account, this can be done by solving the energy (enthalpy) equation. The wall boundaries can be given a wall temperature in the usual way. To take into account combustion, we add a source term similar to the Zimont source term for the progress variable. This replaces the algebraic computation of the enthalpy and temperature.
+
+```python
+ iENTH = 3
+ Source_h.Set(i_node, iENTH, 0.0284*50.5*1e6*S)
+```
+
+The source term S needs to be multiplied by the lower heating value of the mixture 50.5 MJ/kg and the mass fraction of methane in the mixture (with equivalence ratio 0.5, this amounts to Y=0.0284).
+In the config file, the wall temperature can now be set to an appropriate temperature. Since the combustion chamber is known to become very hot, we set the walls to 1200K. The wall temperature is imposed weakly, meaning that we compute the wall flux from Fourier's law and impose that flux:
+
+$$q_w = k_f \left(
+ \frac{\partial T}{\partial n}
+\right)_{\textrm{wall}}$$
+
+The near wall mesh needs to be fine enough to accurately represent the flux.
+
+
+
+Figure (4): visualization of the temperature with a line plot showing the wall temperature.
+
+Figure 4 shows the temperature in the domain, clearly showing the thermal boundary layer at the wall. In the upper left corner the temperature redistribution due to the recirculation zone is also clearly present.
+More accurate modeling can be achieved by taking into account the effect of heat loss on the laminar flame speed. In cantera, the laminar flame speed can be computed and a relationship for the laminar flame speed $$S_L(\Delta h_t)$$ as a function of the enthalpy deficiency can be used instead of a constant $$S_L$$. The local flame quenching due to heat losses at the wall can then be taken into account. The total enthalpy can be computed from the sensible enthalpy and the progress variable, noticing that when the progress variable is 1, then all chemical enthalpy has been converted into sensible enthalpy.
+
+The heating value of methane is 50.5 MJ/kg, and with a mass fraction of $$Y=0.0284$$ we have a chemical enthalpy of
+
+$$h_{\textrm{chem}}^{\textrm{max}} = 1.4342 MJ/kg$$.
+
+With our chemical enthalpy converted to sensible enthalpy, our flame temperature ends up to be around 1735K.
+
+With the measured flame temperature of T=1777K (used in our algebraic relationship for temperature), we compute a sensible enthalpy of 2MJ/kg, very close to the total enthalpy computed using the sum of the initial sensible enthalpy and the chemical enthalpy.
+
+Our progress variable now tells us that the chemical enthalpy that we have left is
+
+$$h_{\textrm{chem}} = c \cdot h_{chem}^{\textrm{max}}$$.
+
+Since total enthalpy is conserverved during combustion, the temperature difference between the actual temperature and the temperature computed from the sensible enthalpy gives us the heat loss. With this enthalpy deficiency we can compute the local laminar flame speed and the corrected source term.
+
+
+Figure (4): visualization of the source term showing the results using constant laminar flamespeed (top) and the variable laminar flamespeed (bottom).
+
+
+
+Figure (5): visualization of the temperature showing the result using constant laminar flamespeed (top) and the variable laminar flamespeed (bottom).
+
+Figures 4 and 5 show a comparison between the simulation results using a constant laminar flamespeed and a variable laminar flamespeed that takes into account local heat losses. In Figure 4, the source term is smaller close to the wall where the flame attaches. The temperature field in Figure 5 shows that the flame zone is more diffusive.
+
+Figure (6): Line plot of the progress variable on the centerline showing the result using constant laminar flamespeed and variable laminar flamespeed.
+
+Figure 6 confirms that the flame is more diffuse with variable S_L.
+
+Note that with python it is also very easy to impose temperature profiles. The code is simply:
+```python
+
+def ApplyWallTemperature(SU2Driver, marker_ids):
+ """Applies an isothermal wall boundary condition on a specific wall"""
+ for marker_id in marker_ids:
+ if marker_id < 0:
+ continue
+ allCoords = SU2Driver.Coordinates()
+ # the top horizontal wall is 1200K, but the vertical side wall goes from 1200K down to 700K
+ # to match the inlet pipe temperature (which has zero heat flux BC)
+ for i_vertex in range(driver.GetNumberMarkerNodes(marker_id)):
+ i_point = SU2Driver.GetMarkerNode(marker_id, i_vertex)
+ coord = allCoords.Get(i_point)
+ Tw = 673 + 500.0 * (coord[1]-0.0125)/0.025
+ driver.SetMarkerCustomTemperature(marker_id, i_vertex, hf)
+```
+And in the config file, we simply add
+```bash
+MARKER_PYTHON_CUSTOM= (wall_top, wall_side )
+```
+
+The wall temperature is now a function of the vertical coordinate y.
+
+
+
diff --git a/_tutorials/multiphysics/Unsteady_FSI_Python/Dynamic_FSI_Python.md b/_tutorials/multiphysics/Unsteady_FSI_Python/Dynamic_FSI_Python.md
index efc42ea0..a728d66f 100644
--- a/_tutorials/multiphysics/Unsteady_FSI_Python/Dynamic_FSI_Python.md
+++ b/_tutorials/multiphysics/Unsteady_FSI_Python/Dynamic_FSI_Python.md
@@ -2,7 +2,7 @@
title: Dynamic Fluid-Structure Interaction (FSI) using the Python wrapper and a Nastran structural model
permalink: /tutorials/Dynamic_FSI_Python/
written_by: Nicola-Fonzi
-for_version: 7.0.6
+for_version: 7.1.0
revised_by:
revision_date:
revised_version:
@@ -37,6 +37,8 @@ You can find the resources for this tutorial in [this folder](https://github.com
In the [main directory](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_fsi_python), there are other 5 subdirectories containing the configuration files and structural models for the different Mach numbers. Please do not mix those files as the structural models and configurations are different at the different aerodynamic conditions.
+Before starting this tutorial, please be sure to have compiled SU2 with the python wrapper enabled. Further, two packages are required that can be downloaded from your package manager: libspatialindex and petsc, with their python counterparts rtree and petsc4py.
+
### Background
The solution process will follow a very similar flow as the one explained in [this](https://su2code.github.io/tutorials/Static_FSI/) tutorial,
@@ -61,7 +63,7 @@ $$
\end{cases}
$$
-Where $$m$$ is the mass of the airfoil, $$I$$ the inertia around the center of mass, $$S$$ the static moment of inertia at the rotation axis, $$C$$ and $$K$$ the dampings and stiffnesses respectively. $$L$$ and $$M$$ are the lift and pitching up moment.
+Where $$m$$ is the mass of the airfoil, $$I$$ the inertia around the rotation axis, $$S$$ the static moment of inertia at the rotation axis, $$C$$ and $$K$$ the dampings and stiffnesses respectively. $$L$$ and $$M$$ are the lift and pitching up moment.
These equations are usually adimensionalised to obtain results independent from the free-stream density of the flow.
Indeed, we can define the following parameters:
@@ -159,7 +161,6 @@ DEFORM_MESH = YES
MARKER_DEFORM_MESH = ( airfoil )
DEFORM_STIFFNESS_TYPE = WALL_DISTANCE
DEFORM_LINEAR_SOLVER_ITER= 200
-MARKER_FLUID_LOAD = ( airfoil )
```
Where we selected the airfoil as our marker for coupling.
@@ -197,8 +198,6 @@ Available keywords for the config file:
* __NMODES__ (int): number of modes to use in the analysis. If n modes are available in the punch file, but only the first m
This work is licensed under a Creative Commons Attribution 4.0 International License
diff --git a/_tutorials/multiphysics/contact_resistance_cht/SS_CR_CHT.md b/_tutorials/multiphysics/contact_resistance_cht/SS_CR_CHT.md
new file mode 100644
index 00000000..4b89540c
--- /dev/null
+++ b/_tutorials/multiphysics/contact_resistance_cht/SS_CR_CHT.md
@@ -0,0 +1,154 @@
+---
+title: Solid-to-Solid Conjugate Heat Transfer with Contact Resistance
+permalink: /tutorials/SS_CR_CHT/
+written_by: EvertBunschoten
+for_version: 8.0.1
+revised_by: EvertBunschoten
+revised_version: 8.0.1
+solver: MULTIPHYSICS
+requires: SU2_CFD, Gmsh
+complexity: advanced
+follows: Static_CHT
+userguide: Multizone
+---
+
+## Goals
+
+This tutorial shows the ability of SU2 to solve conjugate heat transfer problems between solids with contact resistance. Two solids with a different material composition are conducting thermal energy to one another. The thermal energy transfer is limited through the application of contact resistance. In addition, an incompressible flow (air) flows along the two solids, participating in the transfer of thermal energy.
+
+
+## Resources
+
+The resources for this tutorial can be found in the [multiphysics/contact_resistance_cht](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht) directory in the [tutorial repository](https://github.com/su2code/Tutorials). You will need the configuration files for all physical zones ([fluid.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/fluid.cfg), [solid_1.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/solid_1.cfg), [solid_2.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/contact_resistance_cht/solid_2)), the cofiguration file to invoke a multiphysics simulation run ([master.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/master.cfg)) and the mesh files. These can be generated through GMesh using the .geo files for the [fluid zone](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/fluid_3.geo), and solid zones ([solid 1](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/solid_1.geo), [solid 2](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/solid_2.geo)).
+
+
+## Tutorial
+
+The following tutorial will walk you through the steps required when solving for a coupled CHT solution incorporating multiple physical zones and contact resistance. It is assumed you have already obtained and compiled the SU2_CFD code for a serial computation. If you have yet to complete these requirements, please see the [Download](/docs_v8/Download/) and [Installation](/docs_v8/Installation/) pages.
+
+### Background
+
+Typical engineering applications involving conjugate heat transfer often do not concern a single solid material. For example, a pipe transporting a fluid may be composed of different layers of materials or a heat exchanger in a fluid flow has to be attached to the surrounding structure using insulation material. Depending on the application, the estimation of heat transfer through touching solid mediums can be crucial. Unlike the transfer between solid and fluid mediums, the contact between solid mediums is imperfect. Small cavities between the neighboring solids may result in a significant resistance in heat transfer compared to the idealized situation of perfect contact. SU2 allows the user to model the contact resistance between solid domains.
+
+The heat flux between a conjugate heat transfer interface and the neighboring cell for an idealized contact (no contact resistance) is defined as
+
+$$
+q_{w} = \frac{T - T_w}{\frac{l}{k}}
+$$
+
+where $T$ is the temperature in the neighboring cell, $T_w$ the wall temperature, $l$ the distance between the cell center and the interface, and $k$ the thermal conductivity of the solid medium. The effect of contact resistance is modeled similarly compared to the contact resistance of [Ansys Fluent](https://www.afs.enea.it/project/neptunius/docs/fluent/html/th/node358.htm).
+
+$$
+q_{w} = \frac{T - T_w}{\frac{l}{k} + R_c}
+$$
+
+Here, $R_c$ is the contact resistance with the units $m K W^{-1}$, or the inverse of the heat transfer coefficient. For ideal contact, $R_c$ is equal to zero. This results in the temperature on both sides of the interface to be equal. Applying a non-zero value for $R_c$ restricts the heat transfer between the two solid domains, resulting in a temperature discontinuity. To illustrate this, consider the following set-up with two solid domains.
+
+
+Figure 1: Two solid domains subject to iso-thermal boundary conditions connected by a zone interface.
+
+
+Here, the two colored blocks have different thermal properties and are subject to two isothermal walls. The temperature profile along the centerline for various values of $R_c$ is shown below. The discontinuity between the temperatures on either side of the interface is proportional to the value of $R_c$.
+
+
+Figure 2: The effect of altering the contact resistance at the interface between the solid domains.
+
+What follows is a tutorial with heat transfer between solid and fluid domains that illustrates the use of the contact resistance model.
+
+### Problem Setup
+
+This problem will solve for the incompressible flow along side two solid, metal blocks with different thermal properties, subject to heat transfer with contact resistance at the interface between the blocks. The simulation setup is shown below. The two solid blocks are squares with a side length of 1.0e-02m, while the fluid domain has a width of 5.0e-03m.
+
+
+Figure 3: Computational setup for the tutorial problem for conjugate heat transfer between solid and fluid domains.
+
+The following flow conditions that are set for the fluid domain with a Reynolds number of 260:
+- Fluid model: incompressible, ideal gas
+- Density = 1.29 kg/m^3
+- Inlet Velocity Magnitude = 0.1 m/s
+- Inlet temperature = 300 K
+- Viscosity (constant) = 1.0e-05 kg/(m-s)
+
+Solid domain 1 has the material properties of stainless steel:
+- Density = 8935 kg/m^3
+- Specific heat = 3850 J/(kg-K)
+- Thermal conductivity = 26 W/(m-K)
+
+Solid domain 2 has the material properties of copper:
+- Density = 8000 kg/m^3
+- Specific heat = 4420 J/(kg-K)
+- Thermal conductivity = 61 W/(m-K)
+
+The two solid blocks each are subject to an iso-thermal wall boundary condition, which drives the transfer of heat between the solid domains and the fluid. The interface type for all domains was set to ```DIRECT_TEMPERATURE_ROBIN_HEATFLUX```, with a contact resistance value of 1.0e-04 K-m/W applied to the interface between Solid 1 and Solid 2. All other boundaries were defined as symmetry boundary conditions.
+
+
+### Mesh Description
+
+The computational domain for this tutorial is made up of three separate meshes; [Solid 1](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/solid_mesh_1.su2), [Solid 2](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/solid_mesh_2.su2), and [Fluid](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/fluid_mesh.su2). The meshes for the solid domains are simple, square meshes with 40 nodes along each side, while the fluid domain mesh is refined near the interface with the solid domains. These meshes can alternatively be generated through Gmesh. The .geo files for [Solid 1](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/solid_1.geo), [Solid 2](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/solid_2.geo), and [Fluid](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/fluid_3.geo) allow for the generation of the respective SU2 mesh files.
+
+
+Figure 4: The computational mesh with all three physical zones.
+
+### Configuration File Options
+
+Several of the key configuration file options for this simulation are highlighted here. For this problem, four configuration files are used. The [master configuration file](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/master.cfg) describes the interface between the fluid and solid domains as well as the application of contact resistance.
+```
+CONFIG_LIST = (solid_1.cfg, solid_2.cfg, fluid.cfg)
+MARKER_ZONE_INTERFACE= (cht_interface_1_2, cht_interface_2_1,\
+ cht_interface_1_3, cht_interface_3_1,\
+ cht_interface_2_3, cht_interface_3_2)
+
+MARKER_CHT_INTERFACE= (cht_interface_1_2, cht_interface_2_1,\
+ cht_interface_1_3, cht_interface_3_1,\
+ cht_interface_2_3, cht_interface_3_2)
+
+```
+Here, ```cht_interface_1_2``` and ```cht_interface_2_1``` are the boundaries connecting Solid 1 with Solid 2, while the other interfaces connect the fluid and solid domains. The contact resistance model in SU2 allows the user to apply a contact resistance value for each of the interfaces.
+
+```
+CHT_INTERFACE_CONTACT_RESISTANCE = (1e-4,0,0)
+```
+
+Be mindful that the number of values for contact resistance should match the number of interfaces. For solid-fluid interfaces, the contact resistance model does not apply. Applying a non-zero value for contact resistance for such interfaces will therefore not affect the simulation results.
+
+The configurations for the [steel solid domain](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/solid_1.cfg), [copper solid domain](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/solid_2.cfg), and [fluid domain](https://github.com/su2code/Tutorials/tree/master/multiphysics/contact_resistance_cht/fluid_3.cfg) all contain standard settings for multi-physics simulations.
+
+
+### Running SU2
+
+In order to run this test case, follow these steps at a terminal command line:
+ 1. Move to the directory containing the config files and the mesh files. Make sure that the SU2 tools were compiled, installed, and that their install location was added to your path.
+ 2. Run the executable by entering
+
+ ```
+ $ SU2_CFD master.cfg
+ ```
+
+ at the command line.
+ 3. SU2 will print residual updates with each outer iteration of the flow solver, and the simulation will terminate after reaching running for 2000 iterations
+ 4. Files containing the results will be written upon exiting SU2. The solutions for both solid and fluid domains are contained in a single ParaView multiblock file (.vtm), from which the solutions can be loaded.
+
+### Results
+
+The temperature solution of the completed simulation is shown below. The hot, stainless steel block heats up the flow in the fluid domain, which transfers the heat partially to the copper block downstream through convection.
+
+
+Figure 5: Temperature solution for the current setup.
+
+The effect of the application of contact resistance becomes clear when visualizing the temperature trend across interfaces. Three temperature trends according to each interface are shown below and are color coded corresponding to the lines shown in Figure 6.
+
+
+Figure 6: Temperature trends across the heat transfer interfaces.
+
+The temperature trends across the solid-fluid interfaces (green, red) are continuous, the temperature trend across the solid-solid interface (purple) shows a discontinuity at the interface as a result of the application of contact resistance. This effect can be exaggerated when increasing the value for the contact resistance. For example, when applying a contact resistance value of 10 W-m/K,
+```
+CHT_INTERFACE_CONTACT_RESISTANCE = (10.0,0,0)
+```
+ the two solid domains are currently essentially insulated from one another. This results in the following temperature solution.
+
+
+Figure 7: Temperature solution for a contact resistance value of 10.0 W-m/K.
+
+
+
+Figure 8: Temperature trends across the interfaces for a contact resistance value of 10.0 W-m/K.
diff --git a/_tutorials/incompressible_flow/Inc_Heated_Cylinders/Inc_Heated_Cylinders.md b/_tutorials/multiphysics/steady_cht/Static_CHT.md
similarity index 61%
rename from _tutorials/incompressible_flow/Inc_Heated_Cylinders/Inc_Heated_Cylinders.md
rename to _tutorials/multiphysics/steady_cht/Static_CHT.md
index 4466e131..0d8712fa 100644
--- a/_tutorials/incompressible_flow/Inc_Heated_Cylinders/Inc_Heated_Cylinders.md
+++ b/_tutorials/multiphysics/steady_cht/Static_CHT.md
@@ -1,18 +1,19 @@
---
-title: Heated Cylinders with Conjugate Heat Transfer
-permalink: /tutorials/Inc_Heated_Cylinders/
+title: Static Conjugate Heat Transfer (CHT)
+permalink: /tutorials/Static_CHT/
written_by: oleburghardt
for_version: 7.0.0
-revised_by: talbring
-revision_date: 2020-03-03
-revised_version: 7.0.2
+revised_by: oleburghardt
+revision_date: 2021-01-18
+revised_version: 7.0.8
solver: MULTIPHYSICS
-requires: SU2_CFD
+requires: SU2_CFD, SU2_CFD_AD, SU2_DOT_AD, SU2_DEF
complexity: advanced
-follows:
+follows: Inc_Laminar_Flat_Plate
+userguide: Multizone
---
-
+
## Goals
@@ -28,7 +29,7 @@ The intent of this tutorial is to introduce a simple multiple physical zones cas
## Resources
-The resources for this tutorial can be found in the [incompressible_flow/Inc_Heated_Cylinders](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders) directory in the [tutorial repository](https://github.com/su2code/Tutorials). You will need the configuration files for all physical zones ([flow_cylinder.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/flow_cylinder.cfg), [solid_cylinder1.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/solid_cylinder1.cfg), [solid_cylinder2.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/solid_cylinder2.cfg), [solid_cylinder3.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/solid_cylinder3.cfg)), the cofiguration file to invoke a multiphysics simulation run ([cht_2d_3cylinders.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/cht_2d_3cylinders.cfg)) and the mesh file ([mesh_cht_3cyl.su2](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/mesh_cht_3cyl.su2)).
+The resources for this tutorial can be found in the [multiphysics/steady_cht](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht) directory in the [tutorial repository](https://github.com/su2code/Tutorials). You will need the configuration files for all physical zones ([flow_cylinder.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/flow_cylinder.cfg), [solid_cylinder1.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/solid_cylinder1.cfg), [solid_cylinder2.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/solid_cylinder2.cfg), [solid_cylinder3.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/solid_cylinder3.cfg)), the cofiguration file to invoke a multiphysics simulation run ([cht_2d_3cylinders.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/cht_2d_3cylinders.cfg)) and the mesh file ([mesh_cht_3cyl_ffd.su2](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/mesh_cht_3cyl_ffd.su2)).
## Tutorial
@@ -45,7 +46,7 @@ The correct interface temperature distribution has then to be found by the simul
This problem will solve for the incompressible flow over three cylinders as well as for the heat equation in all cylinders that are coupled by energy conservation across the interfaces.
The following flow conditions that are set to match the Reynolds number of 40. For hollow cylinders with outer diameters of 1m:
-- Density (variable) = 0.00042 kg/m^3
+- Density (variable) = 0.000210322 kg/m^3
- Farfield Velocity Magnitude = 3.40297 m/s
- Farfield Flow Direction, unit vector (x,y,z) = (1.0, 0.0, 0.0)
- Farfield Temperature = 288.15 K
@@ -61,15 +62,14 @@ A constant temperature boundary condition of 350 K on the inner core drives the
The computational mesh for the fluid zone is composed 33700 elements (quad-dominant). The far-field boundary contains 80 line elements and the cylinders surfaces all have 400 line elemtents.
The meshes for all three cylinders are composed of 4534 elements (quad-dominant) each, their inner diamaters are composed of 40 line elements, at their outer diamaters the mesh matches the one of the fluid zone.
-
+
Figure (1): Figure of the computational mesh with all four physical zones.
Uniform velocity boundary conditions are used for the farfield.
### Configuration File Options
-Several of the key configuration file options for this simulation are highlighted here. First we show how we start a multiphysics simulation run incorporating CHT by choosing the following options in a main config file [cht_2d_3cylinders.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/cht_2d_3cylinders.cfg) (see [https://su2code.github.io/docs/Multizone](https://su2code.github.io/docs/Multizone) how to setup a multiphysics simulation in general):
-
+Several of the key configuration file options for this simulation are highlighted here. First we show how we start a multiphysics simulation run incorporating CHT by choosing the following options in a main config file [cht_2d_3cylinders.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/cht_2d_3cylinders.cfg) (see [https://su2code.github.io/docs_v7/Multizone](https://su2code.github.io/docs_v7/Multizone) how to setup a multiphysics simulation in general):
```
MARKER_ZONE_INTERFACE= (cylinder_outer1, cylinder_inner1, cylinder_outer2, cylinder_inner2, cylinder_outer3, cylinder_inner3)
%
@@ -79,7 +79,7 @@ MARKER_CHT_INTERFACE= (cylinder_outer1, cylinder_inner1, cylinder_outer2, cylind
By setting `MARKER_CHT_INTERFACE` for the outer diameters, temperature and heat flux data will be exchanged between the solvers at these boundaries in each outer iteration.
-As in the [laminar flat plate with heat transfer tutorial](/tutorials/Inc_Laminar_Flat_Plate/), we activate the energy equation in the flow domain config ([flow_cylinder.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/flow_cylinder.cfg)) but this time we allow for variable density as the heat input causes a non-neglectable influence on the density:
+As in the [laminar flat plate with heat transfer tutorial](/tutorials/Inc_Laminar_Flat_Plate/), we activate the energy equation in the flow domain config ([flow_cylinder.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/flow_cylinder.cfg)) but this time we allow for variable density as the heat input causes a non-neglectable influence on the density:
```
% ---------------- INCOMPRESSIBLE FLOW CONDITION DEFINITION -------------------%
@@ -107,7 +107,7 @@ FLUID_MODEL= INC_IDEAL_GAS
SPECIFIC_HEAT_CP= 1004.703
```
-The config files for the solid zones are quite short and mostly identical. E.g. for the first cylinder in upstream direction ([solid_cylinder1.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/solid_cylinder1.cfg)), we have to invoke the heat equation solver by
+The config files for the solid zones are quite short and mostly identical. E.g. for the first cylinder in upstream direction ([solid_cylinder1.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/solid_cylinder1.cfg)), we have to invoke the heat equation solver by
```
% Physical governing equations (EULER, NAVIER_STOKES,
@@ -126,18 +126,18 @@ MARKER_ISOTHERMAL= ( core1, 350.0 )
The solid's material properties are chosen as follows.
```
% Solid density (kg/m^3)
-SOLID_DENSITY= 0.00021
+MATERIAL_DENSITY= 0.00021
%
% Solid specific heat (J/kg*K)
-SPECIFIC_HEAT_CP_SOLID = 1004.703
+SPECIFIC_HEAT_CP = 1004.703
%
% Solid thermal conductivity (W/m*K)
-THERMAL_CONDUCTIVITY_SOLID= 0.1028
+KT_CONSTANT= 0.1028
```
### Running SU2
-The CHT simulation for the provided mesh will execute relatively, given that the coupled outer loop has to converge to a interface temperature solution as well. To run this test case, follow these steps at a terminal command line:
+The CHT simulation for the provided mesh will execute relatively quick, given that the coupled outer loop has to converge to a interface temperature solution as well. To run this test case, follow these steps at a terminal command line:
1. Move to the directory containing the config files and the mesh files. Make sure that the SU2 tools were compiled, installed, and that their install location was added to your path.
2. Run the executable by entering
@@ -167,37 +167,82 @@ As for this test case, the objective function will be the sum of all integrated
```
% For a weighted sum of objectives: separate by commas, add OBJECTIVE_WEIGHT and MARKER_MONITORING in matching order.
OBJECTIVE_FUNCTION= TOTAL_HEATFLUX
-%
+
+```
+
+in [cht_2d_3cylinders.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/cht_2d_3cylinders.cfg),
+
+```
% Marker(s) of the surface where the functional (Cd, Cl, etc.) will be evaluated
MARKER_MONITORING= (cylinder_outer1, cylinder_outer2, cylinder_outer3)
```
-in [flow_cylinder.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/flow_cylinder.cfg) and
+in [flow_cylinder.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/flow_cylinder.cfg) and
```
% Marker(s) of the surface where the functional (Cd, Cl, etc.) will be evaluated
MARKER_MONITORING= ( NONE )
```
-in [solid_cylinder1.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/solid_cylinder1.cfg), [solid_cylinder2.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/solid_cylinder2.cfg) and [solid_cylinder3.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/solid_cylinder3.cfg).
+in [solid_cylinder1.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/solid_cylinder1.cfg), [solid_cylinder2.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/solid_cylinder2.cfg) and [solid_cylinder3.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/steady_cht/solid_cylinder3.cfg).
One could also set objective functions in all the solid config files seperately which would in the end give same results.
-Based on all four solution files from the different zones ([solution_flow_0.dat](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/solution_flow_0.dat), [solution_flow_1.dat]([../../](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/)Inc_Heated_Cylinders/solution_flow_1.dat), [solution_flow_2.dat](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/solution_flow_2.dat), [solution_flow_3.dat](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Heated_Cylinders/solution_flow_3.dat)) that can be found in the directory that contains the config files and the mesh, we start the discrete adjoint run by entering
+Based on all four solution files from the different zones (`solution_flow_0.dat` and so on), we start the discrete adjoint run by entering
```
$ SU2_CFD_AD cht_2d_3cylinders.cfg
```
-### Results
+### Results and Validation
-Results are given here for the SU2 discrete adjoint solutions for the integrated heat fluxes from all three solid cylinders into the incompressible fluid flow.
Surface node sensitivities can be obtained from the discrete adjoint solutions via
```
+$ cp restart_adj_totheat_0.dat solution_adj_totheat_0.dat
+$ cp restart_adj_totheat_1.dat solution_adj_totheat_1.dat
+$ cp restart_adj_totheat_2.dat solution_adj_totheat_2.dat
+$ cp restart_adj_totheat_3.dat solution_adj_totheat_3.dat
$ SU2_DOT_AD cht_2d_3cylinders.cfg
```
-and be checked against finite differences to find a perfect agreement.
+which are written to surface output files for each zone. Sensitivites from `surface_sens_0.dat` are shown as blue arrows, for all solid zones (`surface_sens_1.dat`, `surface_sens_2.dat`, `surface_sens_3.dat`) as red arrows.
-
+
Figure (2): Heat flux sensitivities obtained from the discrete adjoint flow solution (blue) and the discrete adjoint heat solutions (red), their sum giving the correct result. Note the sensitivity change in downstream direction in both directions and magnitude.
+
+In order to validate the sensitivities (and therefore the discrete adjoint solutions, too), a free-form deformation box was already created around the first heated cylinder, to project all sensitivities onto one design variable (a FFD box control point) to check the obtained derivative against finite differences.
+
+
+Figure (3): FFD box of degree 24x1.
+
+The upper middle control point at (12,1), moving into y-direction, is then used to define a single design parameter modifying the shape. This can be done by
+
+```
+DV_KIND= FFD_CONTROL_POINT_2D
+DV_MARKER= ( cylinder_outer1, cylinder_inner1 )
+DV_PARAM= ( MAIN_BOX, 12, 1, 0.0, 1.0 )
+```
+
+as in the main config file. The derivative of the integrated heat flux with respect to this design veriable was thus alsp automatically computed and written to `of_grad_0.dat` and `of_grad_1.dat`; the other to cylinders are giving no direct contribution as their shape is not affected).
+
+We will check the derivative (0.152507 + 0.234148 + 0.0 + 0.0 = 0,386655) against finite differences at magnitudes from 1.0e-2 to 1.0e-6. To this end, we have to deform the multizone mesh by setting
+
+```
+DV_VALUE= 0.00001
+```
+
+and running
+
+```
+$ SU2_DEF cht_2d_3cylinders.cfg
+```
+
+which will produce the deformed multizone mesh `mesh_cht_3cyl_out.su2`, on which the integrated heatflux can be recomputed (analogously for other magnitudes). Relative errors to the value generated from discrete adjoints are given below.
+
+magnitude | heatflux value | FD derivative | rel. error (%)
+--- | --- | --- | ---
+1.0e-2 | -31.89331058028049 | 0,390077422 | 0,8861153
+1.0e-3 | -31.89682435269217 | 0.387001813 | 0.0906675
+1.0e-4 | -31.89717268560501 | 0.386688997 | 0.0097636
+1.0e-5 | -31.89720748792119 | 0.38665835 | 0.0018381
+1.0e-6 | -31.89721096784924 | 0.38665548 | 0.001095
diff --git a/_tutorials/multiphysics/steady_fsi/Static_FSI.md b/_tutorials/multiphysics/steady_fsi/Static_FSI.md
index c1822ebf..4c49e195 100644
--- a/_tutorials/multiphysics/steady_fsi/Static_FSI.md
+++ b/_tutorials/multiphysics/steady_fsi/Static_FSI.md
@@ -199,7 +199,7 @@ RESTART_FILENAME = restart_fsi_steady
VOLUME_FILENAME = fsi_steady
```
-where the volume files ```fsi_steady_*.vtu``` and restart files ```restart_fsi_steady_*.vtu``` will be appended the zone number.
+where the volume files ```fsi_steady_*.vtu``` and restart files ```restart_fsi_steady_*.dat``` will be appended the zone number.
#### Applying coupling conditions to the individual domains
@@ -280,12 +280,14 @@ which will show the following convergence history:
The code is stopped as soon as the values of ```avg[bgs][0]``` and ```avg[bgs][1]``` are below the convergence criteria set in the config file.
-The displacement field on the structural domain and the velocity field on the flow domain obtained in ```fsi_steady_1.vtu```_and ```fsi_steady_0.vtu``` respectively are shown below:
+The displacement field on the structural domain and the velocity field on the flow domain obtained in ```fsi_steady_1.vtu```_and ```fsi_steady_0.vtu``` respectively can be visualized with paraview and are shown below:
+Note that the cantilever geometry is stored as the original undeformed geometry and a displacement field. In paraview, the geometry can be deformed to match the flow domain using the 'Warp by Vector' filter.
+
#### Relaxing the computation
In order to increase the speed of convergence, it is normally a good option to apply a relaxation
diff --git a/_tutorials/multiphysics/unsteady_cht/Inc_Heated_Cylinders_Unsteady.md b/_tutorials/multiphysics/unsteady_cht/Inc_Heated_Cylinders_Unsteady.md
new file mode 100644
index 00000000..d10bcb82
--- /dev/null
+++ b/_tutorials/multiphysics/unsteady_cht/Inc_Heated_Cylinders_Unsteady.md
@@ -0,0 +1,88 @@
+---
+title: Unsteady Conjugate Heat Transfer
+permalink: /tutorials/Inc_Heated_Cylinders_Unsteady/
+written_by: oleburghardt
+for_version: 7.1.0
+revised_by: TobiKattmann
+revision_date: 2021-03-04
+revised_version: 7.1.1
+solver: INC_NAVIER_STOKES, HEAT_EQUATION
+requires: SU2_CFD
+complexity: advanced
+follows: Static_CHT
+userguide: Multizone
+---
+
+
+ + +## Goals + +This tutorial is a follow-up on the [heated cylinders with conjugate heat transfer tutorial](/tutorials/Inc_Heated_Cylinders/) where a steady CHT solution was computed for a problem involving multiple physical zones. +The following capabilities of SU2 will be showcased in this tutorial: + +- Time domain and time-marching config file options (plus related ones) for unsteady simulations +- Use of time iterations, outer and inner iterations +- Paraview multiblock output + +The intent of this tutorial is to demonstrate how a steady CHT simulation can be turned into an unsteady one. + +## Resources + +The resources for this tutorial can be found in the [Inc_Heated_Cylinders_Unsteady](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht) directory in the [tutorial repository](https://github.com/su2code/Tutorials). You will need the configuration files for all physical zones ([flow_cylinder.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/flow_cylinder.cfg), [solid_cylinder1.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/solid_cylinder1.cfg), [solid_cylinder2.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/solid_cylinder2.cfg), [solid_cylinder3.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/solid_cylinder3.cfg)), the cofiguration file to invoke a multiphysics simulation run ([cht_2d_3cylinders.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/cht_2d_3cylinders.cfg)) and the mesh file ([mesh_cht_3cyl.su2](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/mesh_cht_3cyl.su2)). + +## Tutorial + +The following tutorial will walk you through the steps required when solving for an unsteady coupled CHT solution. It is assumed you have already obtained and compiled the SU2_CFD code for a serial computation. If you have yet to complete these requirements, please see the [Download](/docs/Download/) and [Installation](/docs/Installation/) pages and that make sure you have completed the [heated cylinders with conjugate heat transfer tutorial](/tutorials/Inc_Heated_Cylinders/). + +### Background + +For unsteady flows around walls that are transferring heat from an adjacent (solid) zone, the coupling of temperature and heat flux distributions has to be resolved for each and every time step. Both will vary over time as they depend on the current flow field. + +### Problem Setup + +The problem setup is the same as in the [heated cylinders with conjugate heat transfer tutorial](/tutorials/Inc_Heated_Cylinders/) except for the density. It is increased in all zones by a factor of 100 so that for the flow we obtain a Reynolds number of 4000 which will make it unsteady. Thus we set +``` +INC_DENSITY_INIT= 0.0210322 +``` +in [flow_cylinder.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/flow_cylinder.cfg) and + +``` +MATERIAL_DENSITY= 0.0210322 +``` +in [solid_cylinder1.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/solid_cylinder1.cfg), [solid_cylinder2.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/solid_cylinder2.cfg) and [solid_cylinder3.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/solid_cylinder3.cfg) + +For simplicity we leave all other parameters unchanged. + +### Mesh Description + +The [mesh](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/mesh_cht_3cyl.su2) is the same as in the [heated cylinders with conjugate heat transfer tutorial](/tutorials/Inc_Heated_Cylinders/). + +### Configuration File Options + +An unsteady simulation is set up by enabling the time domain and choosing a time marching algorithm in the [master config file](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/cht_2d_3cylinders.cfg): + +``` +TIME_DOMAIN = YES +% +% +TIME_MARCHING= DUAL_TIME_STEPPING-2ND_ORDER +``` + +The time marching parameters have to match the flow physics that should be resolved. For a given inlet velocity of 3.40297 m/s at Re = 4000, the Strouhal number estimation for the most upstream cylinder is Sr = 0.21. This gives a frequency of f = Sr*v = 0.71Hz for the vortex shedding so that a time step of 0.05s is chosen in the [master config file](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/cht_2d_3cylinders.cfg): + +``` +TIME_STEP= 0.05 +``` + +In order to sufficiently resolve the coupling in each time step, we set the number of outer iterations to 200 in the [master config file](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/cht_2d_3cylinders.cfg): + +``` +OUTER_ITER = 200 +``` + +The number of inner (zone-internal) iterations is set to 1 by default. We do not have to touch any of the zone-specific config files for unsteady options. + +### Running SU2 + +One time iteration will run rather quick and it is up to the user for how long the simulation should run or, equivalently, which physical time span should be covered. In the video above, 1000 time steps had been computed to generate a 50s realtime video. See the [heated cylinders with conjugate heat transfer tutorial](/tutorials/Inc_Heated_Cylinders/) how to execute SU2_CFD. \ No newline at end of file diff --git a/_tutorials/workflow_features/paraview_live/paraview_live.md b/_tutorials/workflow_features/paraview_live/paraview_live.md new file mode 100644 index 00000000..c905e926 --- /dev/null +++ b/_tutorials/workflow_features/paraview_live/paraview_live.md @@ -0,0 +1,100 @@ +--- +title: Realtime update of residuals and solution in paraview +permalink: /tutorials/paraview_live/ +written_by: Nijso Beishuizen +for_version: 7.5.0 +solver: all +requires: paraview +complexity: easy +--- + +## Introduction + +Often we want to view the solution residuals to see if the solution converges. If the residuals seem to stall or oscillate, this might be an indication that the setup is incorrect. A setting has to be changed or the mesh quality has to be improved to ensure convergence. Sometimes this stalling behavior is temporary, and a look at an intermediate paraview solution can lead to more insight. The intermediate solution can also show if the solution is converging towards the expected solution. In this tutorial we will briefly discuss a paraview setup that will give a live update of the residuals as well as the paraview solution. + +## SU2 Configuration file + +We will first discuss some SU2 options that affect our workflow. + +The residuals are saved in the history file. The filename is given by the keyword **CONV_FILENAME= history**. Its contents are determined by the keyword **HISTORY_OUTPUT**. We usually store the RMS values of the residuals with the number of iterations, so we set **HISTORY_OUTPUT= ITER RMS_RES**. The file can be saved either in tecplot format or as comma separated values (csv). We use the csv file format because it is very easy to read in paraview. This is the default but can be set explicitly with the keyword **TABULAR_FORMAT= CSV**. The filename will now be called **history.csv** . The paraview solution is written every x iterations in the filename given by **VOLUME_FILENAME** and x depends on the value of **OUTPUT_WRT_FREQ**. You can save a (2D or 3D) paraview solution using either **OUTPUT_FILES= PARAVIEW** with the extension (suffix) *.vtu* or **OUTPUT_FILES= PARAVIEW_MULTIBLOCK** with extension *.vtm*. To summarize, the following settings are recommended for the paraview live update: + +```bash +TABULAR_FORMAT= CSV +CONV_FILENAME= history +OUTPUT_FILES= RESTART, PARAVIEW, PARAVIEW_MULTIBLOCK +OUTPUT_WRT_FREQ= 100, 10, 10 +VOLUME_FILENAME= flow +VOLUME_OUTPUT= RESIDUAL, PRIMITIVE, SOLUTION +HISTORY_OUTPUT= ITER, RMS_RES +``` + +## Paraview setup + +The paraview live update will simply reload the contents of these files every x seconds, where x is a user defined value. If you haven't installed paraview yet, you can download the latest version here: + +[paraview download](https://www.paraview.org/download/) + +We open paraview and add a new source. Choose *Live Programmable Source*. + +Then choose the *Output Data Set Type* from the list. If you save a regular paraview file, the output filename ends with *.vtu*. Then choose *vtkUnstructuredGrid*. If you save a multiblock paraview file that has the extension *.vtm*, then choose vtkMultiBlockDataSet. + +In the *Script* section, copy the following python script: + +```python +# .vtu paraview +from paraview.vtk.vtkIOXML import vtkXMLUnstructuredGridReader as vtuReader +reader = vtuReader() +reader.SetFileName('flow.vtu') +reader.Update() +self.GetOutputDataObject(0).ShallowCopy(reader.GetOutput()) +``` + +or for a multiblock paraview file: + +```python +# .vtm multiblock +from paraview.vtk.vtkIOXML import vtkXMLMultiBlockDataReader as vtmreader +vtmreader = vtmreader() +vtmreader.SetFileName('flow.vtm') +vtmreader.Update() +self.GetOutputDataObject(0).ShallowCopy(vtmreader.GetOutput()) +``` + +The only thing you need to change here is the filename. Note that this script assumes that you have started paraview in the directory where the paraview filename can be found. The section *Script (RequestInformation)* can be left empty. In the next section, called *Script (CheckNeedsUpdate)*, write the following: + +```python +import time +# the update frequency is 30 seconds +UpdateFrequency = 30 +if not hasattr(self, "_my_time"): + setattr(self, "_my_time", time.time()) + +t = time.time() +lastTime = getattr(self, "_my_time") + +if t - lastTime > UpdateFrequency: + setattr(self, "_my_time", t) + self.SetNeedsUpdate(True) +``` + +And that's it! You now have a paraview viewer that automatically reads the paraview solution file every 30 seconds! Below the script section you can choose as coloring one of the solution fields, as with a regular paraview session. + +You can create a similar setup for the history file to view the residuals. We therefore create a second *Live Programmable Source*. We can keep the *CheckNeedsUpdate* block the same, but since this file gets updated every iteration, we can change the frequency to a lower value, for instance 5 seconds. To load the history file, we set the *Output Data Set Type* to *vtkTable* and add the following code to the *Script* block: + +```python +import numpy as np +import pandas as pd + +data = pd.read_csv("history.csv",sep=',') +print(data.keys()) +print(len(data.columns)) +for name in data.keys(): + array = data[name].to_numpy() + output.RowData.append(array, name) +``` + +If you now create 2 RenderView windows next to each other (either use *Split Horizontal axis* or use *Split Vertical Axis*) you can visualize the contour in one window and the residuals in the second window. Make sure that when you create the viewing window for the line plot, it is set to *Line Chart View*. The contour plot window uses the default *Render View*. You can now select the residuals from the *Series Parameters* list. + + +Figure (1): screenshot of the paraview live setup. + diff --git a/_vandv/30p30n.md b/_vandv/30p30n.md new file mode 100644 index 00000000..2271c081 --- /dev/null +++ b/_vandv/30p30n.md @@ -0,0 +1,98 @@ +--- +title: Three-Element High-Lift Subsonic Airfoil +permalink: /vandv/30p30n/ +--- + +| Solver | Version | Author | +| --- | --- | --- | +| `RANS` | 7.3.0 | P. Gomes | + +The details of the 30P30N validation case are taken from the [Fourth Aerodynamics Prediction Challenge (APC-IV) website](https://cfdws.chofu.jaxa.jp/apc/apc4/). + +
+
+
+
+
diff --git a/_layouts/su2gui.html b/_layouts/su2gui.html
new file mode 100644
index 00000000..045e4848
--- /dev/null
+++ b/_layouts/su2gui.html
@@ -0,0 +1,55 @@
+---
+layout: default
+---
+
+
+
+
+ {% include gsoc_nav.html %}
+
+
+
+
+ {% unless true %} + + + + + +
+ {% endunless %} +
+
+ {{ page.title }}
+{{ content }}
+ + {% unless true %} + + + + + +
+ {% endunless %} +
+
+
+ Improve this page
+
+
+
+
+
+
diff --git a/_su2gui/Build-From-Source.md b/_su2gui/Build-From-Source.md
new file mode 100644
index 00000000..40ae023b
--- /dev/null
+++ b/_su2gui/Build-From-Source.md
@@ -0,0 +1,20 @@
+---
+title: Build From Source
+permalink: /su2gui/Build-From-Source/
+---
+
+This section guides you through using the source code to run SU2GUI on your device, enabling custom changes and optimizations.
+
+### Minimal Requirements
+
+- Python 3
+- SU2 Software
+- Python Libraries listed in [requirements.txt](Link)
+
+### Installation and Setup
+
+Clone the source code from our [GitHub repository](Link). Navigate to the root folder and run `su2gui.py`. You can also pass additional options or create your custom terminal arguments.
+
+### Command to Start the Server
+
+ usage: python su2gui.py [-h] [-p PORT] [-c CASE] [-m MESH] [--config CONFIG] [--restart RESTART]
diff --git a/_su2gui/Configurations.md b/_su2gui/Configurations.md
new file mode 100644
index 00000000..d260dc90
--- /dev/null
+++ b/_su2gui/Configurations.md
@@ -0,0 +1,48 @@
+---
+title: Configurations
+permalink: /su2gui/configurations/
+---
+
+This section explains how to use the configuration file and Config Tab in SU2GUI. For an overview of what a configuration file is, please refer to the [configuration file](../../docs_v7/Configuration-File/) page.
+
+## Loading a Configuration File
+SU2GUI allows users to load a configuration file through both the GUI and the terminal. Loading the file is optional, as SU2GUI will create one if the user does not provide it. Before doing so, it is necessary for the user to initialize a Case. It is recommended to load the mesh file before the configuration file to set boundary condition properties and ensure proper functionality.
+
+**Steps to load configuration file:**
+
+ 1. Start a new case and load mesh file. Follow these guides for detailed steps on [starting a new case](../Manage-Cases/#starting-a-new-case) and [loading a mesh file](../Mesh-File).
+
+
+ 2. Click on the "Load Config File" option. 
+
+
+ 3. In the pop-up window, choose the desired configuration file. 
+
+
+ 4. The configuration file should now be loaded, and the properties in the GUI should be updated accordingly. 
+
+
+
+For instructions on loading a configuration file through the terminal, refer to the guide on [ Terminal Initialization](./../Terminal-Initialization).
+
+## Config Tab
+
+The Config Tab allows users to analyze and modify the current state of the Configuration File. It presents the data in JSON format, which is then converted into a configuration file for SU2 when the solver is initiated.
+
+
+
+### Adding New Properties
+
+User can add/modify Properties in configuration file using this. Place the Key in key textbox and Value in Value textbox. By default, Key is capitalised and preceding and trailing spaces are removed from the Key. Ways to add Value for property are given below:
+
+- **Adding Float/Int**: The system attempts to convert all input into a float. If the conversion fails, it proceeds with other data types.
+
+- **Adding Boolean**: The system recognizes "YES," "NO," "TRUE," and "FALSE" in any case (uppercase or lowercase) and stores them as boolean values.
+
+- **Adding List**: When a list is added, it creates a list of elements and checks if each element is a digit. Below are examples of correct and incorrect list formats:
+
+
+
+ | **Correct List** | (outlet1, 101325, outlet2, 101325) | [outlet1, 101325, outlet2, 101325] | outlet1, 101325, outlet2, 101325 | outlet1 101325 outlet2 101325 |
+ |-------------------|------------------------------------|------------------------------------|---------------------------------|--------------------------------|
+ | **Incorrect List** | (outlet1, 101325, outlet2, 101325 | outlet1, 101325, outlet2, 101325} | outlet1, 101325 outlet2 101325 | outlet1101325 outlet2101325 |
\ No newline at end of file
diff --git a/_su2gui/Initialization.md b/_su2gui/Initialization.md
new file mode 100644
index 00000000..c689d10d
--- /dev/null
+++ b/_su2gui/Initialization.md
@@ -0,0 +1,78 @@
+---
+title: Initialization
+
+permalink: /su2gui/Initialization/
+---
+
+Initialization is the process of setting up the initial conditions and parameters required to start a simulation. Proper initialization is crucial as it significantly influences the convergence and accuracy of the simulation. By specifying initial values or states, you provide a starting point for the solver, which helps in stabilizing the simulation and achieving reliable results more efficiently.
+
+SU2GUI supports three methods for initializing a problem, which are available under the Initialization section of the menu:
+
+- [**Uniform Initialization**](#uniform-initialization)
+- [**Initialization using Restart File**](#initialization-using-restart-file)
+- [**Patch Initialization**](#patch-initialization)
+
+### Opening the Initialization Options
+
+1. Start a new case and load the mesh file. Follow these guides for detailed steps on [starting a new case](../Manage-Cases/#starting-a-new-case) and [loading a mesh file](../Mesh-File).
+
+2. Navigate to the Initialization section from the left menu:
+ 
+
+Follow the steps below according to the type of initialization needed.
+
+---
+
+## Uniform Initialization
+
+**Description**: This method involves assigning a single set of initial values (like pressure, velocity, temperature, etc.) uniformly across the entire computational domain.
+
+**Use Case**: Uniform initialization is commonly used when you have little prior knowledge about the flow field or when you want to start with a simple baseline.
+
+**Steps for Uniform Initialization**
+
+1. After opening the Initialization options, select **Uniform Initialization** from the drop-down menu.
+
+2. Enter the required properties. The properties will vary depending on the selected Solver and Configurations.
+
+3. Press the **Initialize** button. The problem will be initialized, and the visualization window will update accordingly.
+
+---
+
+## Initialization using Restart File
+
+**Description**: This method uses a previously saved simulation state from a Restart file to initialize the current simulation.
+
+**Use Case**: This is ideal for continuing simulations from where they left off or for testing variations without starting from scratch, which can save time and resources.
+
+SU2GUI supports both `.dat` and `.csv` formats for restart files.
+
+**Steps for Restart Initialization**
+
+1. After opening the Initialization options, select **Restart File Initialization** from the drop-down menu.
+
+2. Click on the **Load Restart File** option. 
+
+3. In the pop-up window, choose the desired restart file. 
+
+4. The Restart file will be loaded, and the visualization window will update accordingly. 
+
+For instructions on loading a restart file through the terminal, refer to the guide on [ Terminal Initialization](./../Terminal-Initialization).
+
+---
+
+## Patch Initialization
+
+**Description**: Patch initialization allows you to define different initial conditions for specific regions (or patches) within the computational domain.
+
+**Use Case**: This method is useful for simulations with complex geometries or varying conditions, enabling more precise control over the initial state of the simulation.
+
+SU2GUI currently supports three types of patch initialization: Plane, Sphere, and Box.
+
+**Steps for Patch Initialization**
+
+1. After opening the Initialization options, select **Patch Initialization** from the drop-down menu.
+
+2. Select type of Patch and enter the required properties for both zones. The properties will change according to the selected Solver and Configurations.
+
+3. Press the **Initialize** button. The problem will be initialized, and the visualization window will update accordingly. 
diff --git a/_su2gui/Installation.md b/_su2gui/Installation.md
new file mode 100644
index 00000000..904e95fb
--- /dev/null
+++ b/_su2gui/Installation.md
@@ -0,0 +1,26 @@
+---
+title: Installation
+permalink: /su2gui/Installation/
+---
+
+SU2GUI is designed to be easy to install and offers an intuitive user experience. However, it requires the SU2 software suite to be installed on your system. For instructions on installing SU2, please refer to the [SU2 Installation Guide](../../docs_v7/Installation/).
+
+### Prerequisites
+
+- Python 3.10 or higher
+- SU2 installed on your system. Follow the installation instructions [here](../../docs_v7/Installation/).
+
+## Installation
+
+You can install SU2GUI via pip:
+
+ pip install su2gui
+
+
+### Usage
+To launch the GUI, run the following command in your terminal:
+
+
+ SU2_GUI
+
+For a quick introduction to using SU2GUI, visit the [Quick start](./../Quick-Start) page. For additional terminal options, refer to the [Terminal Initialization](./../Terminal-Initialization) page.
diff --git a/_su2gui/Introduction.md b/_su2gui/Introduction.md
new file mode 100644
index 00000000..24e73b71
--- /dev/null
+++ b/_su2gui/Introduction.md
@@ -0,0 +1,39 @@
+---
+title: Welcome to SU2GUI
+permalink: /su2gui/Introduction/
+---
+
+**Welcome to SU2GUI!**
+
+SU2GUI is a Python-based Graphical User Interface (GUI) designed to simplify the setup, execution, and analysis of simulations using the SU2 software suite. It offers an intuitive interface with real-time visualization and comprehensive case management capabilities. It utilizes several Python libraries such as Pandas, VTK, JSON, Trame, and Vuetify to deliver its full functionality. These libraries handle data processing, visualization, and user interface components, making SU2GUI both powerful and versatile.
+
+## Why Use SU2GUI?
+
+- **User-Friendly Interface:** Navigate complex simulations with ease.
+- **Real-Time Visualization:** See results as they happen, enabling quick adjustments.
+- **Comprehensive Case Management:** Organize, load, and manage your simulations effortlessly.
+
+## Explore the SU2GUI Workflow
+
+Here’s a snapshot of how SU2GUI simplifies your work:
+
+
+
+### 1. Launch SU2GUI
+Get started by running the `SU2_GUI` command in your terminal. This opens up the graphical interface where operations are conducted.
+
+### 2. Start Your Case
+You can either create a new case or load your previous case. Upload the necessary files—including mesh, configuration, and more—directly through the GUI if needed and make the required changes. SU2GUI keeps everything organized so you can focus on your simulation.
+
+### 3. Run Your Simulation
+With everything loaded, you can set up and run your simulation directly from the GUI. SU2GUI provides a user-friendly environment to configure parameters, initialize conditions, and start the solver.
+
+### 4. Visualize Results
+As the simulation runs, you can visualize and analyze the results in real-time using the integrated visualization tools within SU2GUI. This allows for immediate feedback and adjustments to the simulation if needed.
+
+### 5. Manage Your Cases
+Easily manage your simulation projects with SU2GUI’s case management features. Download, delete, or switch between cases with just a few clicks.
+
+## Ready to Get Started?
+
+Dive deeper with our [QuickStart guide](./../Quick-Start) and get started with SU2GUI.
\ No newline at end of file
diff --git a/_su2gui/Logs-Tab-and-Errors.md b/_su2gui/Logs-Tab-and-Errors.md
new file mode 100644
index 00000000..ec09e973
--- /dev/null
+++ b/_su2gui/Logs-Tab-and-Errors.md
@@ -0,0 +1,38 @@
+---
+title: Log Tab and Errors
+permalink: /su2gui/Logs-Errors/
+---
+
+The SU2 and SU2GUI logs provide essential information about the execution and performance of both the SU2 software and SU2GUI. These logs can be accessed and analyzed real-time on SU2GUI under LOGS Tab.
+
+
+## SU2 Logs
+
+
+
+The SU2 logs contain detailed information about the solver's execution, including convergence history, residual values, and solution progress. These logs are invaluable for identifying convergence issues, detecting numerical instabilities, and gaining insights into the overall simulation process.
+
+Each SU2 log file is stored within the corresponding case folder and is unique to that specific case. To access the SU2 log for a particular case, you can download the case folder. Reviewing these log files allows for a detailed analysis of the solver's performance and the progress of individual simulations.
+
+---
+## SU2GUI Logs
+
+
+
+The SU2GUI logs capture interactions and events within the graphical user interface. These logs are useful for understanding user actions, identifying errors or warnings, and tracking the workflow followed during a simulation setup.
+
+Unlike the SU2 logs, the SU2GUI log file is updated and cleared each time SU2GUI is started. This ensures that the log file only contains information from the current session, preventing the accumulation of data from previous sessions.
+
+---
+
+## Error/Warn Message
+
+
+
+In addition to capturing interactions and events within the graphical user interface, SU2GUI also displays any Error and Warning messages received in the log files as pop-up dialog box. This feature helps users quickly identify and address any issues or potential problems during the simulation setup or execution.
+
+By presenting these messages in a pop-up format, SU2GUI ensures that users are immediately alerted to any errors or warnings, allowing for prompt action to be taken. This real-time feedback enhances the user experience and facilitates efficient troubleshooting.
+
+### Importance of Log Analysis
+
+Analyzing the SU2 and SU2GUI logs can provide valuable insights into the simulation process, help diagnose issues, and optimize the performance of your simulations. It is recommended to review these logs whenever you are troubleshooting or optimizing your SU2 simulations to ensure a smooth and efficient workflow.
diff --git a/_su2gui/Manage-Cases.md b/_su2gui/Manage-Cases.md
new file mode 100644
index 00000000..ba4173d7
--- /dev/null
+++ b/_su2gui/Manage-Cases.md
@@ -0,0 +1,52 @@
+---
+title: Manage Cases
+permalink: /su2gui/Manage-Cases/
+---
+
+Loading a case is essential to start working with SU2GUI, as it helps organize all files related to the case. The ability to download, delete, and load previous test cases gives users greater control over their case library.
+
+### Steps for Starting a New Case
+
+1. Click the **Cases** button in the top menu to open the **Manage Cases** dialog box.
+
+2. In the dialog box, click the **New Case** button to open the **Start a New Case** dialog box.
+
+3. Enter the case name and check the box if you want to remove all previous cases.
+
+4. Click **Initialize** to start the new case.
+
+---
+
+### Steps for Downloading a Case(s)
+
+1. Click the **Cases** button in the top menu to open the **Manage Cases** dialog box.
+
+2. From the drop-down menu, select the case you want to download, or check the box to select all cases (including the current case).
+
+3. Click the **Download** button to download the selected case(s).
+
+---
+
+### Steps for Deleting a Case(s)
+
+1. Click the **Cases** button in the top menu to open the **Manage Cases** dialog box.
+
+2. From the drop-down menu, select the case you want to delete, or check the box to select all cases (excluding the current case).
+
+3. Click the **Delete** button to remove the selected case(s).
+
+---
+
+### Steps for Loading an Existing Case(s)
+
+1. Click the **Cases** button in the top menu to open the **Manage Cases** dialog box.
+
+2. From the drop-down menu, select the case you want to load.
+
+3. Click the **Load** button to load the selected case.
+
+---
+
+## Loading a Case from the Terminal
+
+When starting SU2GUI from the terminal, users can specify a case name. If the case already exists, SU2GUI will load it; if not, it will start a new case. For instructions on loading a case through the terminal, refer to the guide on [Terminal Initialization](./../Terminal-Initialization).
\ No newline at end of file
diff --git a/_su2gui/Mesh.md b/_su2gui/Mesh.md
new file mode 100644
index 00000000..4fc44b8e
--- /dev/null
+++ b/_su2gui/Mesh.md
@@ -0,0 +1,28 @@
+---
+title: Mesh File
+permalink: /su2gui/Mesh-File/
+---
+
+
+This section explains how to use the mesh file in SU2GUI. Currently, SU2GUI only supports mesh files in .su2 format. For an overview of what a mesh file is, please refer to the [mesh file](../../docs_v7/Mesh-File/) page.
+
+## Loading a Mesh File
+
+SU2GUI offers the option to load a mesh file through both the GUI and the terminal. Loading the `.su2` mesh file is mandatory. Before doing so, it is necessary for the user to initialize a Case.
+
+**Steps to load mesh file:**
+
+ 1. Start a new case. Follow these guides for detailed steps on [starting a new case](./../Manage-Cases/#starting-a-new-case).
+
+
+ 2. Click on the "Load Mesh File" option. 
+
+
+ 3. In the pop-up window, choose the desired mesh file. 
+
+
+ 4. The mesh file should now be loaded, and the properties in the GUI should be updated accordingly. 
+
+
+
+For instructions on loading a mesh file through the terminal, refer to the guide on [ Terminal Initialization](./../Terminal-Initialization).
\ No newline at end of file
diff --git a/_su2gui/Quick-Start.md b/_su2gui/Quick-Start.md
new file mode 100644
index 00000000..9361526b
--- /dev/null
+++ b/_su2gui/Quick-Start.md
@@ -0,0 +1,80 @@
+---
+title: Quick Start
+permalink: /su2gui/Quick-Start/
+---
+
+Welcome to the Quick Start Tutorial for the SU2GUI. This tutorial introduces key features of SU2GUI, taking only a few minutes to complete. If you haven’t done so already, please visit the [SU2](../../docs_v7/Installation/) and [SU2_GUI](./../Installation) download pages to obtain the latest stable releases and installation details. This tutorial mirrors the [SU2 Quick Start](../../docs_v7/Quick-Start/) guide and requires both the SU2_CFD and SU2_GUI tools.
+
+This guide will help you:
+
+- [Set up SU2GUI](#setup-su2gui)
+- [Start a new case](#start-a-new-case)
+- [Load mesh file](#load-mesh-file)
+- [Load Configurations](#load-configurations)
+- [Run simulation](#run-simulation)
+- [Download case](#download-case)
+- [Analyze results](#analyze-results)
+
+### Setup SU2GUI
+
+If you haven’t installed SU2_GUI, run the following command:
+
+ pip install su2gui
+
+To start the GUI, enter the following in your terminal:
+
+ SU2_GUI
+
+### Start a New Case
+
+1. In the pop-up window, enter a new case name (e.g., `inv_naca0012`).
+2. Press the Create button.
+
+
+
+### Load Mesh File
+
+We will load the mesh file from [SU2/mesh_NACA0012_inv.su2](https://github.com/su2code/SU2/blob/master/QuickStart/mesh_NACA0012_inv.su2):
+
+1. Click on "Load Mesh File" from the top pane.
+2. In the pop-up window, select the mesh file, and it will be loaded.
+
+
+
+### Load Configurations
+
+Next, load the configuration file from [SU2/QuickStart/inv_NACA0012.cfg](https://github.com/su2code/SU2/blob/master/QuickStart/inv_NACA0012.cfg):
+
+1. Click on "Load Config File" from the top pane.
+2. In the pop-up window, choose the configuration file. You can also make other configuration changes through the GUI.
+
+
+
+### Run Simulation
+
+1. Navigate to the Solver node from the Menu.
+2. Set the desired number of iterations (default may be 250).
+3. Press the Start Solver button to begin the simulation.
+
+
+
+### Download Case
+
+1. From the top pane, click on the Case button.
+2. Select your current case (`inv_naca0012`) from the Cases dropdown menu.
+3. Click the Download button to download the case.
+
+
+
+### Analyze Results
+
+1. In the top pane, select "Mach" from the Color By dropdown menu.
+2. Turn off the mesh preview using the indicated button.
+3. Zoom in on the mesh for a better view and analyze the results.
+
+
+
+## Next Steps
+
+- Further analyze the results in Paraview.
+- Explore the [SU2 QuickStart](../../docs_v7/Quick-Start/) guide for more details.
diff --git a/_su2gui/Result-Analysis.md b/_su2gui/Result-Analysis.md
new file mode 100644
index 00000000..1e516cbf
--- /dev/null
+++ b/_su2gui/Result-Analysis.md
@@ -0,0 +1,43 @@
+---
+title: Result Analysis
+permalink: /su2gui/Result-Analysis/
+---
+
+## Analyzing SU2 Output Files
+
+When working with SU2, several key output files are generated that are crucial for analyzing the performance and results of your simulations. These files include `History.csv`, `Restart.csv`, and various files representing the current state of the solver. Understanding and analyzing these files is essential for extracting meaningful insights and further refining your simulations.
+
+### History Tab
+
+The `History.csv` file logs the convergence history of your simulation. It typically includes data such as iteration number, residuals, lift and drag coefficients, and other relevant metrics. By analyzing this file, you can:
+
+- **Monitor Convergence**: Ensure your simulation is converging by tracking how residuals decrease over iterations.
+- **Evaluate Performance**: Assess key metrics like lift and drag coefficients to determine the aerodynamic characteristics of your model.
+- **Identify Issues**: Detect irregularities that may indicate problems with your simulation setup.
+
+SU2GUI provides a convenient "History Tab" feature that allows you to visualize the `History.csv` file in real time, enabling you to monitor the convergence and track key metrics as they evolve. You can also select specific parameters to plot, enabling more focused analysis of key metrics.
+
+
+
+---
+### Geometry Tab
+
+The `Restart.csv` file stores the simulation state at a specific point in time. It is essential for:
+
+- **Real-Time Monitoring**: Track the solver's state in real time to monitor progress and make necessary adjustments.
+- **Resuming Simulations**: Continue an interrupted simulation from the last saved state.
+- **Debugging**: Examine the current state to identify and resolve issues if the simulation encounters problems.
+
+SU2GUI offers a "Geometry Tab" feature that lets you visualize the `Restart.csv` file in real time, facilitating real-time monitoring.
+
+
+---
+### Output Files for Further Analysis
+
+SU2 generates various output files, such as:
+
+- **Flow Field Data**: Velocity, pressure, and temperature distributions.
+- **Surface Data**: Pressure and skin friction coefficients.
+- **Visualization Files**: Files compatible with tools like ParaView.
+
+SU2GUI allows you to download all output files from a case. For instructions on case management, refer to the [case installation procedure](../Manage-Cases/). By thoroughly analyzing these files, you can gain insights, validate models, and make informed decisions for future simulations.
diff --git a/_su2gui/Supported-Functionalities.md b/_su2gui/Supported-Functionalities.md
new file mode 100644
index 00000000..969ef4dc
--- /dev/null
+++ b/_su2gui/Supported-Functionalities.md
@@ -0,0 +1,45 @@
+---
+title: Supported Functionalities
+permalink: /su2gui/Supported-Functionalities/
+---
+
+
+In this section, we explore the various supported functionalities of the SU2 GUI. While the SU2 GUI currently doesn't support all the features of the SU2 suite, you can still make adjustments using traditional methods.
+
+The supported properties are organized according to the nodes in the Side Menu:
+
+### Physics
+
+This node supports selecting Solver, Turbulence Model, Sub-Model, Energy Equation, and Wall Function.
+
+For more details on models in SU2, refer to this [page](../../docs_v7/Physical-Definition/).
+
+### Materials
+
+This node supports selecting the type of fluid density, viscosity, heat capacity, and conductivity, and specifying the necessary properties.
+
+### Numeric
+
+This node supports selecting the type of Spatial Gradients, MUSCL Spatial Gradients, and CFL value.
+
+### Boundaries
+
+This node contains sub-nodes based on the user's mesh file. Each sub-node allows you to modify the properties of that boundary.
+
+Currently supported Boundary Markers include:
+
+`MARKER_ISOTHERMAL`, `MARKER_HEATFLUX`, `MARKER_HEATTRANSFER`, `MARKER_EULER`, `MARKER_WALL_FUNCTIONS`, `MARKER_OUTLET`, `INC_OUTLET_TYPE`, `MARKER_SYM`, `MARKER_FAR`, `MARKER_INLET`, `INC_INLET_TYPE`, `INLET_TYPE`, `MARKER_SUPERSONIC_INLET`, `MARKER_SUPERSONIC_OUTLET`.
+
+### Initialization
+
+This node provides options for initializing the simulation. Uniform initialization requires constant values, Patch Initialization requires constant values for two zones, and Restart File Initialization requires a restart file in .dat or .csv format.
+
+For more details on initialization, refer to this [page](../Initialization/).
+
+### FileIO
+
+This node supports managing file input/output. It includes options to rename Restart, Volume Output, and History files, and select their writing frequency for the current case. Additionally, there are options to overwrite Restart and Volume files.
+
+### Solver
+
+This node allows you to adjust the residual convergence value and iteration count, with support currently limited to ITER. Using the solver button, you can start SU2_CFD, and visualization will begin as the restart file is created. Please note that result visualization is currently supported only for 2D simulations, not 3D.
\ No newline at end of file
diff --git a/_su2gui/Terminal-Initialization.md b/_su2gui/Terminal-Initialization.md
new file mode 100644
index 00000000..40b47a87
--- /dev/null
+++ b/_su2gui/Terminal-Initialization.md
@@ -0,0 +1,46 @@
+---
+title: Terminal Initialization
+permalink: /su2gui/Terminal-Initialization/
+---
+
+SU2GUI can be initialized directly from the terminal, allowing users to provide the Case Name and other relevant files during initialization.
+
+### Usage
+
+The basic syntax for initializing SU2GUI from the terminal is as follows:
+
+ usage: SU2_GUI [-h] [-p PORT] [-c CASE] [-m MESH] [--config CONFIG] [--restart RESTART]
+
+
+### Options
+
+- `-h, --help`
+ Displays the help message and exits.
+
+- `-p , --port PORT`
+ Specifies the port to be used. The default port is `8080`.
+
+- `-c , --case CASE`
+ Defines the name of the case to start with.
+
+- `-m , --mesh MESH`
+ Specifies the path to the SU2 mesh file in `.su2` format.
+
+- `--config CONFIG`
+ Specifies the path to the configuration file in `.cfg` format.
+
+- `--restart RESTART`
+ Specifies the path to the restart file in `.csv` or `.dat` format.
+
+### Important Notes
+
+- **Case Name Requirement**: The Case Name must be provided for the initialization of the MESH, CONFIG, or RESTART file. Without specifying a Case Name, these files cannot be initialized.
+
+- All the options mentioned above are completely optional. Users can choose to provide any combination of these options based on their requirements.
+
+### Example Command
+
+To initialize SU2GUI with a specific case name, port, mesh file, configuration file, and restart file, use the following command:
+
+
+ SU2_GUI -p 5000 -c case_name -m path_to_mesh_file --config path_to_config_file --restart path_to_restart_file
diff --git a/_tutorials/compressible_flow/Aachen_Turbine/Aachen_Turbine.md b/_tutorials/compressible_flow/Aachen_Turbine/Aachen_Turbine.md
new file mode 100644
index 00000000..c59324f2
--- /dev/null
+++ b/_tutorials/compressible_flow/Aachen_Turbine/Aachen_Turbine.md
@@ -0,0 +1,392 @@
+---
+title: Aachen turbine stage with Mixing-plane
+permalink: /tutorials/Aachen_Turbine/
+written_by: alecappiello
+for_version: 8.1.0
+revised_by: joshkellyjak
+revision_date:
+revised_version: 8.1.0
+solver: RANS
+requires: SU2_CFD
+complexity: advanced
+follows: compressible flow tutorials
+---
+
+
+
+## Goals
+Upon completing this tutorial, the user will become familiar with 3D steady-state RANS calculations of multi-row axial turbines, elaborating viscous, compressible flows of air, modelled as an ideal gas.
+
+
+The geometry chosen for the tutorial is a 1-1/2 axial turbine stage (stator 1 - rotor - stator 2), from Gallus, H. E., et al. "*Endwall and Unsteady Flow Phenomena in an Axial Turbine Stage.*" ASME. J. Turbomach. October 1995; 117(4): 562–570. https://doi.org/10.1115/1.2836568.
+
+
+The solution will provide a flow field that can be compared against experimental data. However, to achieve a meaningful result, much more refined grids should be used.
+
+*Note that the original stator geometries have been modified, increasing the blade count from 36 to 41.*
+
+
+The intent of this tutorial is to introduce a compressible flow problem involving an axial turbine to explain how turbo-specific features are used within SU2.
+The following capabilities of SU2 will be showcased in this tutorial:
+- Steady, 3D RANS equations with the Spalart–Allmaras (SA) turbulence model
+- Giles non-reflective boundary conditions
+- Non-reflective mixing-plane
+- Hub and Shroud surface treatment
+- Turbo Performance BCs
+- Wall functions
+
+
+## Resources
+
+You can find the resources for this tutorial in the folder [compressible_flow/Aachen_Turbine](https://github.com/su2code/Tutorials/tree/master/compressible_flow/Aachen_Turbine) in the [tutorial repository](https://github.com/su2code/Tutorials).
+You will need the mesh file [Aachen_Turbine.su2](https://github.com/su2code/Tutorials/tree/master/compressible_flow/Aachen_Turbine/Aachen_Turbine.su2) and the main config file [Aachen_Turbine.cfg](https://github.com/su2code/Tutorials/tree/master/compressible_flow/Aachen_Turbine/Aachen_Turbine.cfg), together with the sub-config files: [stator1.cfg](https://github.com/su2code/Tutorials/tree/master/compressible_flow/Aachen_Turbine/stator1.cfg), [rotor.cfg](https://github.com/su2code/Tutorials/tree/master/compressible_flow/Aachen_Turbine/rotor.cfg), [stator2.cfg](https://github.com/su2code/Tutorials/tree/master/compressible_flow/Aachen_Turbine/stator2.cfg).
+
+*Note that, while the mesh used for this tutorial feature boundary layer refinements at the endwalls and on blade surfaces,
+it does not include the rotor tip gap and it is rather coarse. For comparison of the results against literature, a finer meshes should be used.*
+
+
+
+## Tutorial
+
+The following tutorial will walk you through the steps required when solving state-state flows through multi-row turbines using SU2. It is assumed you have already obtained and compiled SU2_CFD. If you have yet to complete these requirements, please see the [Download](/docs_v7/Download/) and [Installation](/docs_v7/Installation/) pages.
+
+### Background
+
+This example uses a 3D one and a half turbine stage encompassing one stator, one rotor and a downstream stator, equal to the
+first one. Consequently, the case requires multiple frame of reference to account for the rotation of the rotor.
+
+
+### Problem Setup
+
+This tutorial will solve the flow through the Aachen turbine for the following boundary conditions:
+- Working fluid is air
+- Inlet Stagnation Temperature = 308.26 K
+- Inlet Stagnation Pressure = 158245.38 Pa
+- Inlet Flow Direction, unit vector (Flow dir-norm, Flow dir-tang, Flow dir-span) = (1.0, 0.0, 0.0)
+- Outlet Static Pressure = 110050.96 Pa
+- Rotor Rotational Speed, vector component (x y z) = 0.0 0.0 -366.52 rad/s
+
+
+### Geometry Description
+
+To reduce the computational cost, the geometrical periodicity of the system is exploited reducing the computational domain to one blade passage per row
+(with the blade at the centre of the mesh). As it will be explained later, this requires the use of periodic boundary conditions.
+
+
+
+Figure (1): Computational domain reduction.
+
+### Mesh Description
+The mesh is composed of hexahedral elements, with 53634 elements for stator 1 passage, 67935 elements for the rotor passage and 52374 for stator 2 passage.
+
+*Upon preparing the mesh, it is important to make sure that the machine axis is the Z-axis and that the flow proceeds in the positive z-direction.*
+
+
+### Multizone Config File
+The current case features a multizone domain. As a consequence, the `MULTIZONE` option must be used, and the list of sub-config files (one per zone) must be provided via `CONFIG_LIST`. An example of the necessary syntax is provided in the following box.
+
+```
+MULTIZONE= YES
+
+% List of config files for zone-specific options
+CONFIG_LIST=(stator1.cfg, rotor.cfg, stator2.cfg)
+```
+#### Sub-config Files
+The most important information that must be specified in the sub-config files concerns the grid movement. To activate it, the `GRID_MOVEMENT` option must be specified, together with the `MOTION_ORIGIN` and angular velocity (`ROTATION_RATE`) components about the rotation axis.\
+For the solver initialization the motion Mach number is specified via the `MACH_MOTION`. \
+Finally, a smoother convergence can be achieved via the `RAMP_ROTATING_FRAME`. Although not used in the present case, it can be activated similarly to the outlet pressure ramp, describe later in this tutorial.
+
+These options are shown for the rotor sub-config file in the following box.
+
+```
+% Type of dynamic mesh (NONE, ROTATING_FRAME)
+GRID_MOVEMENT = ROTATING_FRAME
+
+MACH_MOTION= 0.35
+
+MOTION_ORIGIN= 0.0 0.0 0.0
+
+% Angular velocity vector in rad/s
+ROTATION_RATE= 0.0 0.0 -366.52
+
+RAMP_ROTATING_FRAME= NO
+
+% Parameters of the rotating frame ramp:
+ starting rotational speed,
+ updating-iteration-frequency,
+ total number of iterations for the ramp
+RAMP_ROTATING_FRAME_COEFF= (0.0, 150.0, 2000)
+```
+
+### Boundary Conditions
+To setup a turbomachinery CFD calculation, several kinds of boundary conditions are needed. The boundary conditions relevant to the Aachen turbine test case are discussed in the following, together with the necessary syntax to activate them.
+
+#### Adiabatic, no-slip boundary conditions:
+
+This kind of boundary condition is applied to all solid walls, highlighted in grey in Figure 2, such as HUB, SHROUD
+AND BLADE belonging to each row. To make a wall adiabatic the ```MARKER_HEATFLUX``` can be used specifying a zero heatflux. This will also ensure that a no-slip condition is enforced on that wall.
+The following box shows the syntax to be used to enforce this boundary condition at all solid walls present in the meshes.
+
+```
+% Format: (marker, 0.0)
+
+MARKER_HEATFLUX = (BLADE1, 0.0, BLADE2, 0.0, BLADE3, 0.0, HUB1, 0.0, SHROUD1, 0.0, HUB2, 0.0, SHROUD2, 0.0, HUB3, 0.0, SHROUD3, 0.0)
+```
+
+Figure (2): Hub, shroud and blade surfaces.
+
+
+#### (Rotational) Periodic boundary conditions:
+This kind of boundary condition is applied to pairs of surfaces, such as the sides of the domain
+(highlighted in Figure 3 in brown and purple). To enforce it, ```MARKER_PERIODIC``` should be used, providing the name of a "periodic marker" (purple surface), a "donor marker" (brown surface).
+In cases involving rotational periodicity (in contrast to translational periodicity) the coordinates of the rotation centre (x,y,z) and the rotation angle components (x-axis, y-axis, z-axis) should be provided.
+The following box shows the syntax to be used to enforce this boundary condition at all sold walls present in the meshes.
+```
+
+% Format: ( periodic marker, donor marker, rot_cen_x, rot_cen_y, rot_cen_z, rot_angle_x-axis, rot_angle_y-axis, rot_angle_z-axis, translation_x, translation_y, translation_z)
+
+MARKER_PERIODIC = (PER1_STATOR1, PER2_STATOR1, 0.0, 0.0, 0.0, 0.0, 0.0, 8.7804878, 0.0, 0.0, 0.0, PER1_ROTOR, PER2_ROTOR, 0.0, 0.0, 0.0, 0.0, 0.0, 8.7804878, 0.0, 0.0, 0.0, PER1_STATOR2, PER2_STATOR2, 0.0, 0.0, 0.0, 0.0, 0.0, 8.7804878, 0.0, 0.0, 0.0)
+
+```
+
+Figure (3): Periodic and donor surfaces.
+
+#### Non-reflective boundary conditions
+Non-reflective boundary conditions can be enforced by means of the
+```MARKER_GILES``` boundary. They are used for both inlet-outlet, as well as mixing-plane boundaries. Furthermore, under-relaxation factors can be provided both for the average and Fourier components at any boundary where the Giles boundary condition is used. For additional details about their implementation and usage, the reader is referred to the paper by [Vitale et al.](https://doi.org/10.2514/1.B37685)
+
+##### Inlet and outlet boundaries
+The ```TOTAL_CONDITIONS_PT``` option allows to enforce the total inlet condition on a chosen boundary (identified by its marker). These include pressure and temperature, together with the incoming flow direction, expressed via its local coordinates (normal, tangential and radial to the chosen boundary).
+The ```STATIC_PRESSURE_1D``` can be used to enforce the outlet static pressure value on a boundary where the flow is in radial equilibrium.
+These two options are applied to the inlet and outlet surfaces of the domain, respectively, highlighted in light blue in Figure 4.
+The following box presents the corresponding syntax.
+
+```
+% Non reflecting boundary condition for inflow and outflow:
+
+% Format inlet:
+( marker, TOTAL_CONDITIONS_PT, Total Pressure , Total Temperature, Flow dir-norm, Flow dir-tang, Flow dir-span, under-relax-avg, under-relax-fourier)
+
+(INFLOW_STATOR1, TOTAL_CONDITIONS_PT, 158245.38, 308.26, 1.0, 0.0, 0.0, 0.3, 0.0)
+
+
+% Format outlet:
+(marker, STATIC_PRESSURE_1D, Static Pressure value, -, -, -, -, under-relax-avg, under-relax-fourier)
+
+(OUTFLOW_STATOR2, STATIC_PRESSURE_1D, 110050.96,
+0.0, 0.0, 0.0, 0.0 , 1.0, 0.0)
+```
+
+
+Figure (4): Non-reflective inlet and outlet boundary conditions
+
+###### Mixing-plane surfaces
+For mixing plane surfaces, as those highlight in light red in Figure 5, ```MIXING_IN``` and ```MIXING_OUT``` tags are used, depending on whether the flow enters or exits through that boundary.
+The following box shows the corresponding syntax.
+
+```
+% Non reflecting boundary condition for mixing-plane:
+% Format mixing-plane in and out:
+( marker, MIXING_IN or MIXING_OUT, -, -, -, -, -, -, under-relax-avg, under-relax-fourier)
+
+(OUTFLOW_STATOR1, MIXING_OUT, 0.0, 0.0, 0.0, 0.0, 0.0, 0.3, 0.0,
+INFLOW_ROTOR, MIXING_IN, 0.0, 0.0, 0.0, 0.0, 0.0, 0.3, 0.0)
+```
+
+Additionally, to activate the transfer of information between zones at the mixing planes, couples of boundaries forming a mixing-plane must be specified via the ```MARKER_MIXINGPLANE_INTERFACE``` and ```MARKER_ZONE_INTERFACE``` in stream-wise order, as shown in the following box.
+
+```
+MARKER_MIXINGPLANE_INTERFACE= (OUTFLOW_STATOR1, INFLOW_ROTOR, OUTFLOW_ROTOR, INFLOW_STATOR2)
+
+MARKER_ZONE_INTERFACE= (OUTFLOW_STATOR1, INFLOW_ROTOR, OUTFLOW_ROTOR, INFLOW_STATOR2)
+```
+
+
+
+The kind of interpolation method to be used at the mixing-planes can be specified via the ```MIXINGPLANE_INTERFACE_KIND```. Possible options are: ```LINEAR_INTERPOLATION```, ```NEAREST_SPAN```, ```MATCHING```.
+
+```
+MIXINGPLANE_INTERFACE_KIND= LINEAR_INTERPOLATION
+```
+To make the mixing-plane turbulent, the following option must be used:
+```
+TURBULENT_MIXINGPLANE= YES
+```
+
+
+Figure (5): Non-reflective mixing-plane
+
+To turn on the non-reflective behaviour, the `SPATIAL_FOURIER` should be set to `YES`. However, for the current tutorial it is not activated, as in the following box.
+```
+SPATIAL_FOURIER = NO
+```
+If needed, extra under relaxation factor for the Giles BC at the hub and shroud can be provided as follows:
+```
+GILES_EXTRA_RELAXFACTOR = (0.05, 0.05)
+```
+
+Finally, the kind of average process for linearizing the Navier-Stokes equation at inflow and outflow boundaries, including mixing-plane(s), can be controlled by ```AVERAGE_PROCESS_KIND```. Possible options are: ```ALGEBRAIC```, ```AREA```, ```MASSSFLUX```, ```MIXEDOUT```. The default one is ```AREA```, however, only the ```MIXEDOUT``` option guarantees that the mixing plane treatment is conservative.\
+The following box shows the setting to be used for the current case.
+
+```
+AVERAGE_PROCESS_KIND= MIXEDOUT
+```
+
+
+#### Shroud boundary condition
+The ```MARKER_SHROUD``` allows to specify the mesh boundaries belonging to the shroud, as those highlighted in dark red in Figure 6.
+When a boundary is tagged as part of the shroud, its grid velocity components are set to 0, mimicking the physical behaviour of a shroud wall. Only rotating zones, such as a rotor, are affected.
+The following box shows the syntax to enforce this functionality.
+```
+MARKER_SHROUD = (SHROUD1, SHROUD2, SHROUD3)
+```
+
+
+Figure (6): Shroud boundary condition
+
+#### Wall functions
+To guarantee a low computational cost, a particularly coarse mesh, featuring large $y^{+}$ values, was used. Therefore, to achieve convergence of the present calculation, wall functions are needed. These are activated by the ```MARKER_WALL_FUNCTIONS```, followed by the ```MARKER_TAG``` of the boundaries to which the wall functions will be applied.
+The following box shows the basic syntax to active the wall functions for the current case.
+```
+% format:
+% MARKER_WALL_FUNCTIONS = (MARKER_TAG, STANDARD_WALL_FUNCTION)
+
+MARKER_WALL_FUNCTIONS= ( BLADE1, STANDARD_WALL_FUNCTION,
+ BLADE2, STANDARD_WALL_FUNCTION,
+ BLADE3, STANDARD_WALL_FUNCTION,
+ HUB1, STANDARD_WALL_FUNCTION,
+ SHROUD1, STANDARD_WALL_FUNCTION,
+ HUB2, STANDARD_WALL_FUNCTION,
+ SHROUD2, STANDARD_WALL_FUNCTION,
+ HUB3, STANDARD_WALL_FUNCTION,
+ SHROUD3, STANDARD_WALL_FUNCTION)
+
+WALLMODEL_KAPPA= 0.41
+WALLMODEL_B= 5.5
+WALLMODEL_MINYPLUS= 5.0
+WALLMODEL_MAXITER= 200
+WALLMODEL_RELFAC= 0.5
+```
+
+
+#### Ramps
+
+To ease the convergence of turbomachinery cases, particularly when the pressure ratio of the machine is large, the use of ramps can be beneficial. These can be applied to both rotational speed and outlet pressure via ```RAMP_OUTLET_PRESSURE``` and ```RAMP_ROTATING_FRAME```. \
+For the sake of completeness, the use of the outlet pressure ramp is demonstrated presenting in the following box the syntax to activate it.
+
+```
+% Specify ramp option for Outlet pressure (YES, NO) default NO
+RAMP_OUTLET_PRESSURE= YES
+%
+% Parameters of the outlet pressure ramp (starting outlet pressure, updating-iteration-frequency, total number of iteration for the ramp)
+RAMP_OUTLET_PRESSURE_COEFF= (140000.0, 150.0, 2000)
+```
+
+
+
+
+#### Turbo Performance and Analysis
+To have SU2_CFD computing the typical turbomachinery performance indexes, the turbomachinery layout and machine kind must be specified by means of ```TURBOMACHINERY_KIND``` and ```TURBO_PERF_KIND```. The former lets you specify whether the machine is axial, centripetal, centrifugal, etc., while the latter lets you specify whether the machine is a compressor or a turbine. These data must be specified for each zone of which the machine is made up of.
+
+Additionally, the inlet and outlet boundary to each zone must be specified in stream-wise order via the ```MARKER_TURBOMACHINERY```, as well as the inlet and the outlet boundaries of the full machine via the ```MARKER_ANALYZE```.
+
+Finally, the performance averaging method, i.e. AREA, MASSSFLUX, MIXEDOUT, etc., must be specified via the ```PERFORMANCE_AVERAGE_PROCESS_KIND```. In case the MIXEDOUT option is selected, the parameters for the Newton method used for the mixed out process can be specified via ```MIXEDOUT_COEFF```.
+
+The following box summarizes the setup for the Turbo Performance and Analysis of the current case.
+
+```
+% Specify kind of architecture (AXIAL, CENTRIPETAL, CENTRIFUGAL, CENTRIPETAL_AXIAL)
+TURBOMACHINERY_KIND= AXIAL AXIAL AXIAL
+
+TURBO_PERF_KIND= (TURBINE, TURBINE, TURBINE)
+
+MARKER_TURBOMACHINERY= (INFLOW_STATOR1, OUTFLOW_STATOR1,
+ INFLOW_ROTOR, OUTFLOW_ROTOR,
+ INFLOW_STATOR2, OUTFLOW_STATOR2)
+
+MARKER_ANALYZE = (INFLOW_STATOR1, OUTFLOW_STATOR2)
+
+% (ALGEBRAIC, AREA, MASSSFLUX, MIXEDOUT) default AREA
+PERFORMANCE_AVERAGE_PROCESS_KIND= MIXEDOUT
+
+%Parameters of the Newton method for the MIXEDOUT average algorithm (under relaxation factor, tolerance, max number of iterations)
+MIXEDOUT_COEFF= (1.0, 1.0E-05, 15)
+```
+
+
+#### Plotting
+
+You can choose which boundaries to include in the surface flow file written by SU2_CFD via ```MARKER_PLOTTING```.
+The following box shows the setting to export the three blade surfaces to the surface flow solution file.
+
+```
+% Marker(s) of the surface in the surface flow solution file
+MARKER_PLOTTING= (BLADE1, BLADE2, BLADE3)
+```
+
+
+### Configuration File Options
+The initialization of the flow solver can be performed from thermodynamic quantities, directly with `INIT_OPTION=TD_CONDITIONS`. It is recommended that you always confirm the resulting initialization state in the console output during runtime of SU2 that is reported just before the solver begins iterating.
+The initialization options are specified in the following box.
+
+```
+% Free-stream pressure (101325.0 N/m^2 by default, only Euler flows)
+FREESTREAM_PRESSURE= 140000.0
+%
+% Free-stream temperature (273.15 K by default)
+FREESTREAM_TEMPERATURE= 300.0
+%
+% Free-stream temperature (1.2886 Kg/m3 by default)
+FREESTREAM_DENSITY= 1.7418
+%
+% Free-stream option to choose if you want to use Density (DENSITY_FS) or Temperature TEMPERATURE_FS) to initialize the solution
+FREESTREAM_OPTION= TEMPERATURE_FS
+%
+% Free-stream Turbulence Intensity
+FREESTREAM_TURBULENCEINTENSITY = 0.025
+%
+% Free-stream Turbulent to Laminar viscosity ratio
+FREESTREAM_TURB2LAMVISCRATIO = 100.0
+%
+%
+%Init option to choose between Reynolds (default) or thermodynamics quantities for initializing the solution (REYNOLDS, TD_CONDITIONS)
+INIT_OPTION= TD_CONDITIONS
+```
+
+#### Final Remarks
+
+To have the residuals exported from each volume zone `WRT_ZONE_HIST` should be set to `YES`.
+
+### Running SU2
+
+To run this test case, the standard procedure can be followed. At a terminal command line:
+
+1. Move to the directory containing the config files (Aachen_Turbine.cfg, stator1.cfg, rotor.cfg, stator2.cfg) and the mesh (Aachen_Turbine.su2) file. Make sure that the SU2 tools were compiled, installed, and that their install location was added to your path.
+2. Run the executable by entering in the command line:
+
+ ```
+ $ SU2_CFD Aachen_Turbine.cfg
+ ```
+
+3. SU2 will print residual updates with each iteration of the flow solver, and the simulation will terminate after reaching the specified convergence criteria.
+4. Files containing the results will be written upon exiting SU2. The flow solution can be visualized in ParaView (.vtk) or Tecplot (.dat for ASCII), depending on the user requirements in the config file.
+
+### Results
+
+Figure 7a and b show the relative Mach number distributions on a cylindrical cut slicing the flow domain at approximately mid-span. The resulting cylindrical surface is presented in Fig. 7a, while it 2D planar counter part is shown in Fig.7b for an easier visualization.
+
+To compute it the following steps can be take in a post-processing tool, such as Tecplot or ParaView:
+
+1. Compute Radius $R$, angualr coordinate $\theta$, and their product $R \cdot \theta$
+
+2. Compute the relative velocity components and the relative Mach number
+
+3. Slice the flow volume at $R = const$ and plot the relative Mach number on the corresponding iso-surface at $R = const$ (Fig. 7a)
+
+3. Extract the slice
+
+4. Plot the relative Mach number contour of the extracted slice in a 2D space $(R \cdot \theta$ vs $z)$ and reverse the Z-axis, Fig. 7b.
+
+
+
+Figure (7): (a) Relative Mach number contour on a cylindrical cut (blade-to-blade view) at midspan of the turbine flow domain; (b) planar (blade-to-blade) view of the cylindrical cut.
diff --git a/_tutorials/compressible_flow/ActuatorDisk_VariableLoad/ActuatorDisk_VariableLoad.md b/_tutorials/compressible_flow/ActuatorDisk_VariableLoad/ActuatorDisk_VariableLoad.md
new file mode 100644
index 00000000..c1f7c967
--- /dev/null
+++ b/_tutorials/compressible_flow/ActuatorDisk_VariableLoad/ActuatorDisk_VariableLoad.md
@@ -0,0 +1,258 @@
+---
+title: Actuator Disk With Variable Load
+permalink: /tutorials/ActuatorDisk_VariableLoad/
+written_by: Ettore Saetta, Renato Tognaccini
+for_version: 7.0.8
+revised_by:
+revision_date:
+revised_version:
+solver: RANS
+requires: SU2_CFD
+complexity: Basic
+follows:
+---
+
+
+
+## Goals
+
+Upon completing this tutorial, the user will be able to simulate the presence of a propeller by a general actuator disk boundary condition. The model enables the simulation of propellers with variable load distribution and including swirl. The specific geometry chosen for the tutorial is composed by an actuator disk and a semi-infinite spinner (grid file and propeller data courtesy of Mauro Minervino, Centro Italiano Ricerche Aerospaziali (CIRA)).
+
+This tutorial is referred only to the actuator disk model `VARIABLE_LOAD` implemented in the V7.0.7.
+
+## Resources
+
+The resources for this tutorial can be found in the [compressible_flow/ActuatorDisk_VariableLoad](https://github.com/su2code/Tutorials/tree/feature_tutorial_ActuatorDisk/compressible_flow/ActuatorDisk_VariableLoad) directory in the [Tutorials repository](https://github.com/su2code/Tutorials). You will need the configuration file ([propeller_variable_load.cfg](https://github.com/su2code/Tutorials/blob/feature_tutorial_ActuatorDisk/compressible_flow/ActuatorDisk_VariableLoad/propeller_variable_load.cfg)), the mesh file ([propeller_variable_load.su2](https://github.com/su2code/Tutorials/blob/feature_tutorial_ActuatorDisk/compressible_flow/ActuatorDisk_VariableLoad/propeller_variable_load.su2)) and the propeller input data file ([ActuatorDisk.dat](https://github.com/su2code/Tutorials/blob/feature_tutorial_ActuatorDisk/compressible_flow/ActuatorDisk_VariableLoad/ActuatorDisk.dat)).
+*It is important to note that the grid used in this tutorial is very coarse to keep computational effort low, finer meshes should be used.*
+
+It is also presented the use of [OptimalPropeller.py](https://github.com/su2code/SU2/tree/master/SU2_PY/OptimalPropeller.py) script, very useful tool to generate a propeller input data file with variable load when only total thrust is known.
+
+## Tutorial
+
+The following tutorial will walk you through the steps required when solving a flow in presence of a propeller using SU2. The tutorial will also shows how to generate the propeller input data file witht the help of the [OptimalPropeller.py](https://github.com/su2code/SU2/tree/master/SU2_PY/OptimalPropeller.py) script when only total thrust is known. To this end, it is assumed you have already obtained and compiled SU2_CFD. If you have yet to complete these requirements, please see the [Download](/docs_v7/Download/) and [Installation](/docs_v7/Installation/) pages.
+
+### Background
+
+This test case is for an actuator disk with a semi-infinite spinner. The actuator disk is a model used to simulate the effects on the aiframe of rotary wings by a simple momentum theory [1].
+In aeronautics it is a crucial topic for the airframe integration. Nowadays, a good actuator disk model is getting importance in order to simulate the effects of the propellers
+of given performance on the airframe by fast CFD analysis.
+However, the disadvantage of using an actuator disk model is that the unsteady effects are neglected.
+
+The actuator disk model used in this tutorial has been implemented referring to a propeller, so the input data file is suitable for a propeller, but not for a wind turbine. However, the model itself, can also be suitable for any rotary wing device. Note that the model has been tested only for propellers.
+
+The hypothesis that we will consider are: compressible and axial flow (the angle between propeller axis and freestream is small).
+
+### Problem Setup
+
+This problem will solve the flow with these conditions:
+- Freestream Mach number = 0.55996
+- Angle of attack (AOA) = 0.0 deg
+- Reynolds number = 3.65E7 (based on propeller diameter)
+- Reynolds length = 5.0292 m
+
+The global propeller data are:
+- Thrust coefficient = 0.15
+- Advance Ratio = 2.81487
+- Radius = 2.5146 m
+
+The thrust coefficient is defined using the "Renard" definition: the reference force is $$\rho n^2D^4$$, where *n* are the propeller rounds per second and *D* is the propeller diameter
+The advance ratio is defined as $$J=\frac{V_\infty}{nD}$$.
+
+### Mesh Description
+
+The computational domain contains the actuator disk mounted on a semi-infinite spinner. The mesh consists of 48,736 elements and 51,847 nodes. Again, we note that this is a very coarse mesh, and should one wish to obtain more accurate solutions for comparison with results in the literature, finer grids should be used.
+
+Three boundary conditions are employed:
+- Actuator Disk on the two surfaces (upstream and downstream) of the actuator disk.
+- Navier-Stokes adiabatic wall on the spinner.
+- Far-field condition on the outer domain surface.
+
+
+Figure (1): Far-field view of the computational domain.
+
+
+Figure (2): Mesh of the domain in the *x-y* plane.
+
+
+Figure (3): Close-up view of the mesh of the actuator disk in the *y-z* plane at *x=0*.
+
+
+Figure (4): Close-up view of the mesh of the spinner in the *y-x* plane.
+
+### Configuration File Options
+
+Only the actuator disk boundary condition options are highlighted here:
+
+```
+% -------------------- ACTUATOR DISK BOUNDARY CONDITION --------------------------%
+%
+ACTDISK_DOUBLE_SURFACE = YES
+%
+% Actuator disk boundary type (VARIABLE_LOAD, VARIABLES_JUMP, BC_THRUST,
+% DRAG_MINUS_THRUST)
+ACTDISK_TYPE= VARIABLE_LOAD
+%
+% Actuator disk data input file name
+ACTDISK_FILENAME= ActuatorDisk.dat
+%
+% Actuator disk boundary marker(s) with the following formats (NONE = no marker)
+% Variable Load: (inlet face marker, outlet face marker,
+% 0.0, 0.0, 0.0, 0.0, 0.0, 0.0) Markers only effectively used.
+MARKER_ACTDISK = ( DISK, DISK_BACK, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 )
+```
+
+The `ACTDISK_DOUBLE_SURFACE` option, in this case, is set to `true` because the actuator disk surface has been splitted in two parts: upstream and sownstream surfaces.
+The `ACTDISK_TYPE` option, is used to choose the actuator disk boundary type. In this tutorial, we consider a variable load distribution along the disk, and that also take the *swirl* term into consideration. The actuator disk type that meets these conditions is the `VARIABLE_LOAD`.
+The `ACTDISK_FILENAME` option is used to specify the name of the actuator disk data input file. Further we will see how to generate this file if only total thrust is known and not the details on the load distribution.
+The `MARKER_ACTDISK` option, requires the following arguments:
+- Marker of the upstream surface of the actuator disk.
+- Marker of the downstream surface of the actuator disk.
+- 6 zero arguments. These arguments have a different meaning using different `ACTDISK_TYPE`. In this case, they are all set to `0.0` because they are not needed.
+
+*If there are more actuator disks, it is possible to append them in the `MARKER_ACTDISK` option.*
+
+### Input Data File
+
+The input data file is needed for the `VARIABLE_LOAD` actuator disk type.
+An example of this file (used in this tutoral) is here reported:
+
+```
+MARKER_ACTDISK= DISK DISK_BACK
+CENTER= 0.0 0.0 0.0
+AXIS= 1.0 0.0 0.0
+RADIUS= 2.5146
+ADV_RATIO= 2.81487
+NROW= 37
+# rs=r/R dCT/drs dCP/drs dCR/drs
+ 0.2031 0.020066 0.0890674 0.0
+ 0.2235 0.019963 0.0932674 0.0
+ 0.2439 0.021707 0.0982980 0.0
+ 0.2644 0.024667 0.1064153 0.0
+ 0.2848 0.029147 0.1189045 0.0
+ 0.3257 0.043674 0.1588513 0.0
+ 0.3461 0.053380 0.1849900 0.0
+ 0.3665 0.064327 0.2145367 0.0
+ 0.3870 0.076521 0.2471873 0.0
+ 0.4278 0.103679 0.3203392 0.0
+ 0.4483 0.118918 0.3609085 0.0
+ 0.4687 0.135619 0.4051864 0.0
+ 0.4891 0.152986 0.4518863 0.0
+ 0.5096 0.171453 0.5011266 0.0
+ 0.5300 0.190755 0.5528521 0.0
+ 0.5504 0.211062 0.6072281 0.0
+ 0.5709 0.231313 0.6620508 0.0
+ 0.5913 0.251252 0.7161404 0.0
+ 0.6117 0.271376 0.7700722 0.0
+ 0.6322 0.290980 0.8219708 0.0
+ 0.6526 0.309848 0.8715231 0.0
+ 0.6730 0.328502 0.9202496 0.0
+ 0.6935 0.346774 0.9681596 0.0
+ 0.7139 0.364895 1.0156277 0.0
+ 0.7343 0.381991 1.0603740 0.0
+ 0.7548 0.398417 1.1036331 0.0
+ 0.7752 0.413550 1.1442054 0.0
+ 0.7956 0.427447 1.1820164 0.0
+ 0.8161 0.440093 1.2163819 0.0
+ 0.8365 0.451007 1.2453084 0.0
+ 0.8569 0.460535 1.2682212 0.0
+ 0.8774 0.467765 1.2823500 0.0
+ 0.8978 0.471296 1.2839416 0.0
+ 0.9182 0.470303 1.2701343 0.0
+ 0.9387 0.460921 1.2317719 0.0
+ 0.9591 0.434937 1.1470356 0.0
+ 0.9795 0.377288 0.9746048 0.0
+```
+
+The `MARKER_ACTDISK` option, as the same for the configuration file, is used to specify the markers of the actuator disk surfaces. All the next propeller data will be referred to these surfaces.
+The `CENTER` option contains the coordinates of the actuator disk center, expressed in the grid reference system.
+The `AXIS` option contains the components of the unit vector normal to the actuator disk surface.
+The `RADIUS` option is used to specify the actuator disk radius.
+The `ADV_RATIO` option contains the advance ratio of the propeller defined as $$J=\frac{V_\infty}{nD}$$, where *n* are the propeller rounds per second and *D* is the propeller diameter.
+The `NROW` option isused to indicate the number of radial stations of the actuator disk in which we assign the load distribution.
+The next row is a dummy row, so it is skipped.
+Then there are 4 columns containing respectively:
+- The non dimensional radial station $$\overline{r}=\frac{r}{R}$
+- The thrust coefficient distribution $$\frac{\mathrm{d}C_T}{\mathrm{d}\overline{r}}$$
+- The power coefficient distribution $$\frac{\mathrm{d}C_P}{\mathrm{d}\overline{r}}$
+- The radial force coefficient distribution $$\frac{\mathrm{d}C_R}{\mathrm{d}\overline{r}}$$
+
+These coefficients are defined using the "Renard" definition: the reference force is $$\rho n^2D^4$$, while the reference power is reference force is $$\rho n^3D^5$$
+
+*It is possible to append other propellers data at the end of the input file. Note that the order and the format of the options should not be changed.*
+
+The visualization of the tabular input for this case is shown in the following figure:
+
+
+Figure (5): Thrust coefficient distribution along the non-dimensional radius.
+
+
+Figure (6): Power coefficient distribution along the non-dimensional radius.
+
+### Optimal Propeller Script
+
+As already anticipated, the [OptimalPropeller.py](https://github.com/su2code/SU2/tree/master/SU2_PY/OptimalPropeller.py) script can be used to automatically generate the propeller input data file when the details on the variable load are not known.
+This script allows the user to use the `VARIABLE_LOAD` actuator disk type also when only total thrust is known. The variable load distribution is obtained by the inviscid theory of the optimal propeller [1].
+
+The input is interactive, and requires the following data:
+1. Number of radial stations (where local data should be generated).
+2. $$CT$$: the total thrust coefficient defined using the "Renard" definition.
+3. $$R$$: The propeller radius expressed in meters.
+4. $$r_{\textrm{hub}}$$: the hub radius expressed in meters.
+5. $$J$$: the advance ratio.
+6. $$V_{\textrm{inf}}$$: the free-stream velocity expressed in m/s.
+7. Here, the script asks if you want to use the tip loss Prandtl correction (*yes* is the default choise).
+8. $$N$$: if you chose yes in the previous stage, it requires also the number of propeller blades.
+
+Once the input is given, the script provides 3 plots showing the tip loss Prandtl correction function, the axial and rotational interference factors and the thrust and power coefficients distributions along the non dimentional radius.
+The script also provides 2 files:
+- ActuatorDisk.cfg: containing the actuator disk boundary condition options needed in the configuration file.
+- ActuatorDisk.dat: containing the propeller input data file.
+
+*Note that the two generated files have some empty fields that need to be filled.*
+
+
+### References
+
+[1] *Glauert H., Airplane Propellers, in Aerodynamic Theory, Ed. Durand W. F., Vol. IV, pp. 169 - 360, Springer, 1935.*
+
+### Running SU2
+
+The actuator disk with variable load test case is small and will execute relatively quickly on a single workstation or laptop in serial. To run this test case, follow these steps at a terminal command line:
+ 1. Move to the directory containing the configuration file ([propeller_variable_load.cfg](https://github.com/su2code/Tutorials/blob/feature_tutorial_ActuatorDisk/compressible_flow/ActuatorDisk_VariableLoad/propeller_variable_load.cfg)), the mesh file ([propeller_variable_load.su2](https://github.com/su2code/Tutorials/blob/feature_tutorial_ActuatorDisk/compressible_flow/ActuatorDisk_VariableLoad/propeller_variable_load.su2)) and the propeller input data file ([ActuatorDisk.dat](https://github.com/su2code/Tutorials/blob/feature_tutorial_ActuatorDisk/compressible_flow/ActuatorDisk_VariableLoad/ActuatorDisk.dat)). Make sure that the SU2 tools were compiled, installed, and that their install location was added to your path.
+ 2. Run the executable by entering
+
+ ```
+ $ SU2_CFD propeller_variable_load.cfg
+ ```
+
+ at the command line.
+ 3. SU2 will print residual updates with each iteration of the flow solver, and the simulation will terminate after meeting the specified convergence criteria.
+ 4. Files containing the results will be written upon exiting SU2. The flow solution can be visualized in ParaView (.vtk) or Tecplot (.dat for ASCII).
+
+### Results
+
+Some results for this test case are shown below.
+
+
+Figure (7): Mach number contour in the *x-z* plane.
+
+
+Figure (8): Pressure coefficient contour in the *x-z* plane.
+
+
+Figure (9): Tangential velocity vectors just downstream the actuator disk. Swirl effect visualization.
+
+
+Figure (10): Momentum in normal direction along *x* for different stations.
+
+
+Figure (11): Pressure coefficient along *x* for different stations.
+
+
+Figure (12): Tangential velocity component along *x* for different stations.
+
+
+Figure (13): Pressure coefficient jump along the non-dimensional radius.
+
+
+Figure (14): Tangential velocity component along *z* just upstream (State 1) and downstream (State 2) the actuator disk.
diff --git a/_tutorials/compressible_flow/NICFD_nozzle/NICFD_nozzle_datadriven.md b/_tutorials/compressible_flow/NICFD_nozzle/NICFD_nozzle_datadriven.md
new file mode 100644
index 00000000..6bac3dcf
--- /dev/null
+++ b/_tutorials/compressible_flow/NICFD_nozzle/NICFD_nozzle_datadriven.md
@@ -0,0 +1,115 @@
+---
+title: Non-ideal compressible flows with physics-informed neural networks
+permalink: /tutorials/NICFD_nozzle_datadriven/
+written_by: EvertBunschoten
+for_version: 8.4.0
+solver: RANS
+requires: SU2_CFD SU2_DataMiner
+complexity: advanced
+follows:
+---
+
+## Goals
+
+Upon completing this tutorial, the user will be familiar with performing simulations of nonideal compressible fluids through the use of physics-informed neural networks. The flow is simulated through the same supersonic convergent-divergent nozzle as in the [tutorial](https://su2code.github.io/tutorials/NICFD_nozzle/) for nonideal compressible fluid flows.
+The following capabilities of will be showcased in this tutorial:
+- Using [SU2 DataMiner](https://github.com/EvertBunschoten/SU2_DataMiner.git) to train physics-informed neural networks for fluid simulations.
+- Data-driven equation of state with multi-layer perceptrons.
+- Giles boundary conditions
+
+The intent of this tutorial is to explain how to use the data-driven equation of state in SU2 for fluid simulations and how to train the neural network(s) required for modeling the fluid properties. The fluid used in this tutorial is Siloxane MM, but the methods explained in this tutorial can also be repeated for different fluids available within CoolProp.
+
+## Background
+
+The data-driven equation of state in SU2 can be used to calculate the thermodynamic state properties of the fluid during CFD calculations. The method uses an equation of state based on entropy potential, allowing for the thermodynamic state variables to be directly calculated from the density and internal energy, which can be directly obtained from the solution of the flow transport equations.
+
+The thermodynamic state variables are calculated from the Jacobian and Hessian of entropy w.r.t. density and internal energy. The data-driven fluid model in SU2 uses a physics-informed neural network to calculate the entropy Jacobian and Hessian such that thermodynamic consistency is maintained.
+
+The data-driven, entropy-based equation of state is discussed more in detail in [this paper](https://doi.org/10.1016/j.compfluid.2025.106932).
+
+## Resources and Set-Up
+
+You can find the resources for this tutorial in the folder [compressible_flow/NICFD_nozzle/PhysicsInformed](https://github.com/su2code/Tutorials/tree/master/compressible_flow/NICFD_nozzle/PhysicsInformed) in the [tutorial repository](https://github.com/su2code/Tutorials).
+You will need the python scripts and the [nozzle contour file](https://github.com/su2code/Tutorials/tree/master/compressible_flow/NICFD_nozzle/PhysicsInformed/nozzle_curve.csv) which describes the shape of the nozzle. The SU2 config file and mesh will be automatically generated using the scripts in this tutorial.
+
+This tutorial requires [SU2 DataMiner](https://github.com/EvertBunschoten/SU2_DataMiner.git) to run. Follow the installation instructions on the repository page, and install the required python packages. To be able to use the data-driven fluid model in SU2, compile SU2 with the following command:
+
+```
+meson.py build -Denable-mlpcpp=true
+```
+
+which will download the [MLPCpp](https://github.com/EvertBunschoten/MLPCpp.git) submodule enabling the evaluation of deep, dense multi-layer perceptrons in SU2.
+
+
+## Tutorial
+
+The following steps explain how to train physics-informed neural networks for data-driven fluid simulations in SU2.
+
+### 1. Generate SU2 DataMiner Configuration
+Similar to SU2, SU2 DataMiner uses a configuration file to store information regarding the type of fluid, the resolution of the training data set, and the hyperparameters of the networks. Running the script [0:generate_config.py](https://github.com/su2code/Tutorials/tree/master/compressible_flow/NICFD_nozzle/PhysicsInformed/0:generate_config.py) generates the SU2 DataMiner configuration used in this tutorial and is saved as a binary file named ```SU2DataMiner_MM.cfg```.
+
+### 2. Generate Training Data
+The thermodynamic state data used to train the network for the data-driven fluid simulation is generated using the Helmholtz equation of state evalauted through the python module for CoolProp. The thermodynamic state data are generated on a density-static energy grid for the gas and supercritical phase between the minimum and maximum density of the fluid supported by CoolProp. The ranges for density and energy or pressure and temperature within which training data are generated can be manually specified.
+
+By running the script [1:generate_fluid_data.py](https://github.com/su2code/Tutorials/tree/master/compressible_flow/NICFD_nozzle/PhysicsInformed/1:generate_fluid_data.py) will generate the thermodynamic state data used for the training of the network and generate contour plots of the temperature, pressure, and speed of sound. The complete set of thermodynamic state data is stored in the file titled *fluid_data_full.csv*. 80% of the randomly sampled fluid data is used to update the weights of the network during training, 10% is used to monitor the convergence of the training process, and the remaining 10% is used to validate the accuracy of the network upon completion of the training process. The complete data set contains approximately 2.3e5 unique data points.
+
+
+Figure (1): Section of training data set near the critial point ('cp').
+
+
+### 3. Train physics-informed neural network
+The network used in this tutorial uses two hidden layers with 12 nodes each. The exponential function is used as the hidden layer activation function. This is an unusual choice, but is motivated by the fact that it reduces the computational cost required to calculate the network Jacobian and Hessian during the CFD solution process.
+The training process uses an exponential decay function for the learning rate, with an initial value of 1e-3. During each update step, the weights and biases of the network are adjusted according to the value of the loss function evaluated on a batch of 64 training data points. The hidden layer architecture and learning rate of the network used in this tutorial were selected through trial and error.
+More details regarding the training method are presented in the [literature](https://doi.org/10.1016/j.compfluid.2025.106932).
+
+The training progress can be followed from the terminal, but can also be monitored from the training convergence plots that are periodically updated under ```Worker_0/Model_0/```.
+
+After training, the weights and biases of the network are stored in the SU2 DataMiner configuration.
+
+IMAGE: training history plot, predicted vs training data
+
+
+Figure (2): Training convergence history
+
+
+
+Figure (3): Compressibility factor from reference data (black) and evaluated by data-driven equation of state (red).
+
+
+### 4. Preparation of the Simulation
+
+To run data-driven fluid simulations in SU2, you need the SU2 configuration file, the mesh, and the file describing the multilayer perceptron. Running the script [3:prepare_simulation.py](https://github.com/su2code/Tutorials/tree/master/compressible_flow/NICFD_nozzle/PhysicsInformed/3:prepare_simulation.py) generates the computational mesh, writes the SU2 configuration file, and writes the ASII file containing the weights and biases of the network.
+
+The mesh is generated using gmesh in which the computational domain is generated accoring to the nozzle contour. The nozzle wall is modeled as a non-slip surface and prism layer refinement is applied to resolve the boundary layer.
+
+
+Figure (4): Computational mesh used for the nozzle flow simulation (top) and highlight of the throat area near the wall (bottom).
+
+The inflow condition is modeled as a non-reflective Giles boundary condition where the pressure and temperature of the critical point of the fluid are imposed as the stagnation pressure and stagnation temperature. The outflow is also modeled as a non-reflective Giles boundary condition, where a static pressure 10 times lower than the inflow pressure is imposed. To improve the stability of the solution process, the pressure imposed at the outflow boundary ramps down from the inflow stagnation pressure to the target value over the course of the first 200 flow iterations.
+
+The data-driven fluid model with the physics-informed entropy-based equation of state is enabled through the following options in the [SU2 configuration file](https://github.com/su2code/Tutorials/tree/master/compressible_flow/NICFD_nozzle/PhysicsInformed/config_NICFD_PINN.cfg):
+```
+FLUID_MODEL= DATADRIVEN_FLUID
+USE_PINN= YES
+INTERPOLATION_METHOD= MLP
+FILENAMES_INTERPOLATOR= MLP_siloxane_MM.mlp
+```
+where the ```USE_PINN= YES``` option enables the use of a physics-informed neural network for thermodynamic state calculations. The file ```MLP_siloxane_MM.mlp``` is the ASII file which describes the network architecture and the network weights and biases. At the start of the SU2 solution process, the network weigths and biases are imported into SU2 through the MLPCpp sub-module.
+
+
+### 5. Run SU2
+The simulation us run by the following command
+```
+mpirun -n
+
+
+ {% include su2gui_nav.html %}
+
+
+
+
+ {% unless true %} + + + + + +
+ {% endunless %} +
+
+ {{ page.title }}
+{{ content }}
+ + {% unless true %} + + + + + +
+ {% endunless %} +
+
+
+ Improve this page
+
+
+
++ + +## Goals + +This tutorial is a follow-up on the [heated cylinders with conjugate heat transfer tutorial](/tutorials/Inc_Heated_Cylinders/) where a steady CHT solution was computed for a problem involving multiple physical zones. +The following capabilities of SU2 will be showcased in this tutorial: + +- Time domain and time-marching config file options (plus related ones) for unsteady simulations +- Use of time iterations, outer and inner iterations +- Paraview multiblock output + +The intent of this tutorial is to demonstrate how a steady CHT simulation can be turned into an unsteady one. + +## Resources + +The resources for this tutorial can be found in the [Inc_Heated_Cylinders_Unsteady](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht) directory in the [tutorial repository](https://github.com/su2code/Tutorials). You will need the configuration files for all physical zones ([flow_cylinder.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/flow_cylinder.cfg), [solid_cylinder1.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/solid_cylinder1.cfg), [solid_cylinder2.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/solid_cylinder2.cfg), [solid_cylinder3.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/solid_cylinder3.cfg)), the cofiguration file to invoke a multiphysics simulation run ([cht_2d_3cylinders.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/cht_2d_3cylinders.cfg)) and the mesh file ([mesh_cht_3cyl.su2](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/mesh_cht_3cyl.su2)). + +## Tutorial + +The following tutorial will walk you through the steps required when solving for an unsteady coupled CHT solution. It is assumed you have already obtained and compiled the SU2_CFD code for a serial computation. If you have yet to complete these requirements, please see the [Download](/docs/Download/) and [Installation](/docs/Installation/) pages and that make sure you have completed the [heated cylinders with conjugate heat transfer tutorial](/tutorials/Inc_Heated_Cylinders/). + +### Background + +For unsteady flows around walls that are transferring heat from an adjacent (solid) zone, the coupling of temperature and heat flux distributions has to be resolved for each and every time step. Both will vary over time as they depend on the current flow field. + +### Problem Setup + +The problem setup is the same as in the [heated cylinders with conjugate heat transfer tutorial](/tutorials/Inc_Heated_Cylinders/) except for the density. It is increased in all zones by a factor of 100 so that for the flow we obtain a Reynolds number of 4000 which will make it unsteady. Thus we set +``` +INC_DENSITY_INIT= 0.0210322 +``` +in [flow_cylinder.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/flow_cylinder.cfg) and + +``` +MATERIAL_DENSITY= 0.0210322 +``` +in [solid_cylinder1.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/solid_cylinder1.cfg), [solid_cylinder2.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/solid_cylinder2.cfg) and [solid_cylinder3.cfg](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/solid_cylinder3.cfg) + +For simplicity we leave all other parameters unchanged. + +### Mesh Description + +The [mesh](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/mesh_cht_3cyl.su2) is the same as in the [heated cylinders with conjugate heat transfer tutorial](/tutorials/Inc_Heated_Cylinders/). + +### Configuration File Options + +An unsteady simulation is set up by enabling the time domain and choosing a time marching algorithm in the [master config file](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/cht_2d_3cylinders.cfg): + +``` +TIME_DOMAIN = YES +% +% +TIME_MARCHING= DUAL_TIME_STEPPING-2ND_ORDER +``` + +The time marching parameters have to match the flow physics that should be resolved. For a given inlet velocity of 3.40297 m/s at Re = 4000, the Strouhal number estimation for the most upstream cylinder is Sr = 0.21. This gives a frequency of f = Sr*v = 0.71Hz for the vortex shedding so that a time step of 0.05s is chosen in the [master config file](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/cht_2d_3cylinders.cfg): + +``` +TIME_STEP= 0.05 +``` + +In order to sufficiently resolve the coupling in each time step, we set the number of outer iterations to 200 in the [master config file](https://github.com/su2code/Tutorials/tree/master/multiphysics/unsteady_cht/cht_2d_3cylinders.cfg): + +``` +OUTER_ITER = 200 +``` + +The number of inner (zone-internal) iterations is set to 1 by default. We do not have to touch any of the zone-specific config files for unsteady options. + +### Running SU2 + +One time iteration will run rather quick and it is up to the user for how long the simulation should run or, equivalently, which physical time span should be covered. In the video above, 1000 time steps had been computed to generate a 50s realtime video. See the [heated cylinders with conjugate heat transfer tutorial](/tutorials/Inc_Heated_Cylinders/) how to execute SU2_CFD. \ No newline at end of file diff --git a/_tutorials/workflow_features/paraview_live/paraview_live.md b/_tutorials/workflow_features/paraview_live/paraview_live.md new file mode 100644 index 00000000..c905e926 --- /dev/null +++ b/_tutorials/workflow_features/paraview_live/paraview_live.md @@ -0,0 +1,100 @@ +--- +title: Realtime update of residuals and solution in paraview +permalink: /tutorials/paraview_live/ +written_by: Nijso Beishuizen +for_version: 7.5.0 +solver: all +requires: paraview +complexity: easy +--- + +## Introduction + +Often we want to view the solution residuals to see if the solution converges. If the residuals seem to stall or oscillate, this might be an indication that the setup is incorrect. A setting has to be changed or the mesh quality has to be improved to ensure convergence. Sometimes this stalling behavior is temporary, and a look at an intermediate paraview solution can lead to more insight. The intermediate solution can also show if the solution is converging towards the expected solution. In this tutorial we will briefly discuss a paraview setup that will give a live update of the residuals as well as the paraview solution. + +## SU2 Configuration file + +We will first discuss some SU2 options that affect our workflow. + +The residuals are saved in the history file. The filename is given by the keyword **CONV_FILENAME= history**. Its contents are determined by the keyword **HISTORY_OUTPUT**. We usually store the RMS values of the residuals with the number of iterations, so we set **HISTORY_OUTPUT= ITER RMS_RES**. The file can be saved either in tecplot format or as comma separated values (csv). We use the csv file format because it is very easy to read in paraview. This is the default but can be set explicitly with the keyword **TABULAR_FORMAT= CSV**. The filename will now be called **history.csv** . The paraview solution is written every x iterations in the filename given by **VOLUME_FILENAME** and x depends on the value of **OUTPUT_WRT_FREQ**. You can save a (2D or 3D) paraview solution using either **OUTPUT_FILES= PARAVIEW** with the extension (suffix) *.vtu* or **OUTPUT_FILES= PARAVIEW_MULTIBLOCK** with extension *.vtm*. To summarize, the following settings are recommended for the paraview live update: + +```bash +TABULAR_FORMAT= CSV +CONV_FILENAME= history +OUTPUT_FILES= RESTART, PARAVIEW, PARAVIEW_MULTIBLOCK +OUTPUT_WRT_FREQ= 100, 10, 10 +VOLUME_FILENAME= flow +VOLUME_OUTPUT= RESIDUAL, PRIMITIVE, SOLUTION +HISTORY_OUTPUT= ITER, RMS_RES +``` + +## Paraview setup + +The paraview live update will simply reload the contents of these files every x seconds, where x is a user defined value. If you haven't installed paraview yet, you can download the latest version here: + +[paraview download](https://www.paraview.org/download/) + +We open paraview and add a new source. Choose *Live Programmable Source*. + +Then choose the *Output Data Set Type* from the list. If you save a regular paraview file, the output filename ends with *.vtu*. Then choose *vtkUnstructuredGrid*. If you save a multiblock paraview file that has the extension *.vtm*, then choose vtkMultiBlockDataSet. + +In the *Script* section, copy the following python script: + +```python +# .vtu paraview +from paraview.vtk.vtkIOXML import vtkXMLUnstructuredGridReader as vtuReader +reader = vtuReader() +reader.SetFileName('flow.vtu') +reader.Update() +self.GetOutputDataObject(0).ShallowCopy(reader.GetOutput()) +``` + +or for a multiblock paraview file: + +```python +# .vtm multiblock +from paraview.vtk.vtkIOXML import vtkXMLMultiBlockDataReader as vtmreader +vtmreader = vtmreader() +vtmreader.SetFileName('flow.vtm') +vtmreader.Update() +self.GetOutputDataObject(0).ShallowCopy(vtmreader.GetOutput()) +``` + +The only thing you need to change here is the filename. Note that this script assumes that you have started paraview in the directory where the paraview filename can be found. The section *Script (RequestInformation)* can be left empty. In the next section, called *Script (CheckNeedsUpdate)*, write the following: + +```python +import time +# the update frequency is 30 seconds +UpdateFrequency = 30 +if not hasattr(self, "_my_time"): + setattr(self, "_my_time", time.time()) + +t = time.time() +lastTime = getattr(self, "_my_time") + +if t - lastTime > UpdateFrequency: + setattr(self, "_my_time", t) + self.SetNeedsUpdate(True) +``` + +And that's it! You now have a paraview viewer that automatically reads the paraview solution file every 30 seconds! Below the script section you can choose as coloring one of the solution fields, as with a regular paraview session. + +You can create a similar setup for the history file to view the residuals. We therefore create a second *Live Programmable Source*. We can keep the *CheckNeedsUpdate* block the same, but since this file gets updated every iteration, we can change the frequency to a lower value, for instance 5 seconds. To load the history file, we set the *Output Data Set Type* to *vtkTable* and add the following code to the *Script* block: + +```python +import numpy as np +import pandas as pd + +data = pd.read_csv("history.csv",sep=',') +print(data.keys()) +print(len(data.columns)) +for name in data.keys(): + array = data[name].to_numpy() + output.RowData.append(array, name) +``` + +If you now create 2 RenderView windows next to each other (either use *Split Horizontal axis* or use *Split Vertical Axis*) you can visualize the contour in one window and the residuals in the second window. Make sure that when you create the viewing window for the line plot, it is set to *Line Chart View*. The contour plot window uses the default *Render View*. You can now select the residuals from the *Series Parameters* list. + + +Figure (1): screenshot of the paraview live setup. + diff --git a/_vandv/30p30n.md b/_vandv/30p30n.md new file mode 100644 index 00000000..2271c081 --- /dev/null +++ b/_vandv/30p30n.md @@ -0,0 +1,98 @@ +--- +title: Three-Element High-Lift Subsonic Airfoil +permalink: /vandv/30p30n/ +--- + +| Solver | Version | Author | +| --- | --- | --- | +| `RANS` | 7.3.0 | P. Gomes | + +The details of the 30P30N validation case are taken from the [Fourth Aerodynamics Prediction Challenge (APC-IV) website](https://cfdws.chofu.jaxa.jp/apc/apc4/). + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-
-
-
-
+
+
+
+
-
-
-
-
+
+
+
+
+
+
+
+
+### T3B
+The experiment data from [here](http://cfd.mace.manchester.ac.uk/ercoftac/)
+
+C : Coarse
+
+M : Medium
+
+F : Fine
+
+X : Extra fine
+
+
+
+
+
+
+
+### T3Am
+The experiment data from [here](http://cfd.mace.manchester.ac.uk/ercoftac/)
+
+Mesh_1 : Tiny
+
+Mesh_2 : Coarse
+
+Mesh_3 : Medium
+
+Mesh_4 : Fine
+
+Mesh_5 : Extra Fine
+
+Mesh_6 : Ultra Fine
+
+
+
+
+
+
+### NLF0416
+Fluent and SU2, the NLF-0416 airfoil results oscillate near the separation region. So, Here are shown only the fine-level grid results of every 1000 iterations and the instantaneous.
+
+C : Coarse
+
+M : Medium
+
+F : Fine
+
+Every 1000 iteration results :
+
+
+
+
+
+
+Instantaneous result is :
+
+
+
+
+
+
+
+
+### E387
+Experimental results are available. The pressure coefficient distribution has been compared for 4 angles of attack, namely 0deg, 2deg, 4deg, and 6deg. Cl-alpha and polar curves are also avaliable for comparison.
+
+Pressure coefficient distribution obtained through ROE scheme.
+
+
+
+
+
+
+
+
+Cl-alpha and polar curve obtained through ROE scheme.
+
+
+
+
+
+
+Pressure coefficient distribution obtained through L2ROE scheme.
+
+
+
+
+
+
+
+
+Cl-alpha and polar curve obtained through L2ROE scheme.
+
+
+
+
\ No newline at end of file
diff --git a/_vandv/SANDIA_jet.md b/_vandv/SANDIA_jet.md
new file mode 100644
index 00000000..1cfbb47f
--- /dev/null
+++ b/_vandv/SANDIA_jet.md
@@ -0,0 +1,155 @@
+---
+title: 2D Axisymmetric, Nonpremixed, Nonreacting, Variable Density, Turbulent Jet Flow
+permalink: /vandv/SANDIA_jet/
+---
+
+| Solver | Version | Author |
+| --- | --- | --- |
+| `INC_RANS` | 7.5.0 | Sem Bosmans |
+
+
+The details of the 2D Axisymmetric, Nonpremixed, Nonreacting, Variable Density, Turbulent Jet Flow are taken from [Sandia National Laboratories database](https://tnfworkshop.org/data-archives/simplejet/propanejet) [1](#ref1),[2](#ref2).
+
+By comparing the results of SU2 simulations case against the experimental data, as well as OpenFOAM simulation results [3](#ref3) (and MFSim [4](#ref4)), we can build a high degree of confidence that the composition-dependent model is implemented correctly in combination with the SST turbulence model. Therefore, the goal of this case is to validate the implementation of the composition-dependent model in SU2.
+
+## Problem Setup
+The problem consists of a turbulent propane jet mixing into coflowing air. The schematic overview of this problem is given in the figure below:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -34,26 +34,29 @@
Powerful. Fast. Free.
-
+
@@ -95,10 +98,10 @@<
+
+
-
+
+
+
+
+
+
+ +
6th Annual SU2 Conference
+The 6th edition of the SU2 conference takes place in Varenna/Italy from the 29th to the 30th of September.
+Registration and abstract submission are open now and the links to the respective platforms together with all up-to-date information can be found on the conference website.
++
-
+ 
+
+
-
-
-
- What is SU2?
---Computational analysis tools have revolutionized the way we design engineering systems, but most established codes are proprietary, unavailable, or prohibitively expensive for many users. The SU2 team is changing this, making multiphysics analysis and design optimization software freely available and involving everyone in its creation and development.
- -Find a detailed description of the code philosophy, components, and implementations in the SU2 AIAA Journal article. Whether it's discrete adjoints, non-ideal compressible CFD, high-performance computing, or incompressible flows with heat transfer, SU2 has something for you.
-
-
+
-
-
-
+ What is SU2?
++Computational analysis tools have revolutionized the way we design engineering systems, but most established codes are proprietary, unavailable, or prohibitively expensive for many users. The SU2 team is changing this, making multiphysics analysis and design optimization software freely available and involving everyone in its creation and development.
+ +Find a detailed description of the code philosophy, components, and implementations in the SU2 AIAA Journal article. Whether it's discrete adjoints, non-ideal compressible CFD, high-performance computing, or incompressible flows with heat transfer, SU2 has something for you.
+
@@ -95,10 +98,10 @@
<
A strong foundation.
The SU2 community continues to grow rapidly, and together, we are making a measurable, worldwide impact on CFD. Now, it's time to tap into our collective expertise, creativity, and skills to take the project to the next level.
- +We are proud to announce the SU2 Foundation, a new non-profit organization formed in the United States. The mission of the SU2 Foundation is to promote global software development and education to increase the pace of innovation in the engineering sciences for the benefit of all society.
-