diff --git a/_config.yml b/_config.yml
index 0f60842f..e63bd734 100644
--- a/_config.yml
+++ b/_config.yml
@@ -86,6 +86,15 @@ defaults:
seo:
type: "WebPage"
+- scope:
+ path: _gsoc
+ type: gsoc
+ values:
+ layout: gsoc
+ sectionid: gsoc
+ seo:
+ type: "WebPage"
+
collections:
docs:
permalink: /:collection/:path/
@@ -102,6 +111,9 @@ collections:
su2gui:
permalink: /:collection/:path/
output: true
+ gsoc:
+ permalink: /:collection/:path/
+ output: true
posts:
permalink: /blog/:year/:month/:day/:title/
output: true
diff --git a/_data/gsoc.yml b/_data/gsoc.yml
new file mode 100644
index 00000000..fad92a45
--- /dev/null
+++ b/_data/gsoc.yml
@@ -0,0 +1,11 @@
+- title: GSOC
+ gsoc:
+ - Introduction
+
+- title: Participation
+ gsoc:
+ - Participation
+
+- title: Assignments
+ gsoc:
+ - Assignments
diff --git a/_data/tutorials.yml b/_data/tutorials.yml
index 069c9300..c5e09c0e 100644
--- a/_data/tutorials.yml
+++ b/_data/tutorials.yml
@@ -19,6 +19,7 @@
- NICFD_nozzle
- NICFD_nozzle_datadriven
- Aachen_Turbine
+ - Actuator_Disk
- title: Incompressible Flow
tutorials:
@@ -49,6 +50,7 @@
- Static_CHT
- Inc_Heated_Cylinders_Unsteady
- SS_CR_CHT
+ - Inc_Laminar_Diffusion_Flame
- Inc_Combustion
- TFC_python
diff --git a/_gsoc/Assignments.md b/_gsoc/Assignments.md
new file mode 100644
index 00000000..a1a3ce60
--- /dev/null
+++ b/_gsoc/Assignments.md
@@ -0,0 +1,41 @@
+---
+title: Student Assignments
+permalink: /gsoc/Assignments/
+---
+
+**Welcome to SU2 - GSOC!**
+What is Google Summer of Code?
+
+[Google Summer of Code](https://summerofcode.withgoogle.com/)
+
+
+## SU2 introduction assignments
+
+To help newcomers start with SU2 and to help GSOC mentors with evaluating the level of students who would like to participate in Google Summer of Code, we have prepared a couple of introduction assignments. These assignments have to be made in the order they are given. These assignments give us an indication of your familiarity with SU2 and the SU2 code. These assignments, together with your active participation in the SU2 community, will be taken into account when deciding on GSOC projects.
+
+## Assignment 1: Compile SU2
+
+- Clone SU2 from github [SU2](https://github.com/su2code/SU2) on your system and compile it [compile instructions](https://su2code.github.io/docs_v7/Build-SU2-Linux-MacOS/) with different options, and run some tutorials [Tutorials](https://su2code.github.io/tutorials/home/). Get a proper understanding of the input and output of SU2.
+- Deliverable: None
+
+## Assignment 2: Set up a test case from scratch
+
+- Generate a 2D mesh for an axisymmetric, steady-state, turbulent jet case (for instance with [gmsh](https://gmsh.info/)), setup the configuration file, run the simulation, and extract results.
+- Deliverable: Testcase and small report (markdown) describing motivation for set-up, configuration options, convergence history, comparison with experimental values.
+Reference paper that could be used for comparison [report](https://www.researchgate.net/publication/254224677_Investigation_of_the_Mixing_Process_in_an_Axisymmetric_Turbulent_Jet_Using_PIV_and_LIF)
+
+## Assignment 3: Python wrapper test case
+
+- Set up a problem in the python wrapper (compile with python support) and run a test case.
+Testcase for the python wrapper: [flatplate](https://github.com/su2code/SU2/blob/master/TestCases/py_wrapper/flatPlate_unsteady_CHT/launch_unsteady_CHT_FlatPlate.py)
+- Deliverable: Testcase and small report describing the test case and showing the results.
+
+## Assignment 4: Modification of the python wrapper setup
+
+- Enable a spatially varying wall temperature for a steady-state compressible turbulent flat plate testcase.
+- Deliverable: Testcase and small report describing the results.
+
+## Assignment 5: Addition of new volume output:
+
+- Add the local speed of sound as computed by SU2 in the volume output (paraview files) and the screen output. Run the turbulent test case from point 2 with this new volume and screen output enabled.
+- Deliverable: explain implementation, show the history output of the new screen output and show some image with the volume output.
diff --git a/_gsoc/Introduction.md b/_gsoc/Introduction.md
new file mode 100644
index 00000000..f402af6d
--- /dev/null
+++ b/_gsoc/Introduction.md
@@ -0,0 +1,62 @@
+---
+title: Ideas List for SU2 Google Summer of Code
+permalink: /gsoc/Introduction/
+---
+
+**Welcome to SU2 - GSOC!**
+
+This is the updated ideas list for GSOC 2026. If you are interested in participating in [Google Summer of Code](https://summerofcode.withgoogle.com/about) with the SU2 team, then please read the page on [participation](https://su2code.github.io/gsoc/Participation/). The projects listed below have been tuned to fit within the google summer of code program and they have mentors assigned to them. We can also accept personal ideas beyond the ones presented below but you need to convince one of the mentors to support you. We also need you to be proficient in SU2 and have some kind of technical background beyond general computer science (studying physics, mechanical engineering, aerospace engineering,...).
+
+## Project BP: Adding pressure-based solver
+Project Description (max. 5 Sentences)
+The pressure-based solver has been requested for a long time. This solver is an important addition to the CFD solvers, especially for low Mach and incompressible flows. People have worked on it (detailed documentation available), and there is a branch that contains a working version, but this was never finalized and added to the main SU2 branch. Hence, the project's objective is to evaluate the current status of attempts, and propose a strategy for getting the pressure-based solver in the latest version of SU2.
+Expected Outcome (deliverables): Finalize pressure-based solver, validate with test cases, tutorial and merge the PR.
+- Skills Required: C++, experience with CFD and numerical methods
+- Possible Mentors: Nitish Anand and Edwin van der Weide
+- Expected Project Size: 175 hrs/medium
+- Difficulty rating: **medium-hard** (needs experience with Computational Fluid Dynamics)
+
+## Project GPU: Continuation of GPU acceleration in SU2
+Project Description (max. 5 Sentences)
+The SU2 code relies heavily on sparse linear algebra. In this area, there is significant speed-up potential with the adoption of GPU-based processing, as was demonstrated in the GSOC 24 project that applied CUDA to sparse matrix-vector multiplications in SU2. The objective of this project is to move more linear algebra operations to GPU in order to avoid host-device communication bottlenecks within the sparse linear system solver.
+Expected Outcome (deliverables): Make SU2’s sparse linear solver GPU-native, i.e. minimal host-device communication after the initial setup of the system.
+- Skills Required C++
+- Possible Mentors Pedro Gomes (lead), Ole Burghardt
+- Expected Project Size (90 hrs/ small , 175 hrs/medium, 350 hrs/large): 175 hrs (medium)
+- Difficulty rating: **medium**
+
+## Project AMR: Quick Adaptive Mesh refinement for 2D testcases
+Project Description (max. 5 Sentences)
+Many users have asked for adaptive mesh refinement capabilities. Several research groups are working on this. The aim of this project is to introduce a quick and easy adaptive mesh refinement that simply reads an existing results file and adaptively refines the meshes based on the value of a field.
+Expected Outcome (deliverables): SU2_AMR, an added executable that simply splits 2D quad and triangle cells
+- Skills Required: C++
+- Possible Mentors: Nijso Beishuizen (lead)
+- Expected Project Size (90 hrs/ small , 175 hrs/medium, 350 hrs/large): 175 hrs (medium)
+- Difficulty rating: **medium**
+
+## Project CMPLX: Performance Optimization of Complex Arithmetic in SU2
+Project Description (max. 5 Sentences)
+Complex arithmetic operations currently cause significant performance degradation in SU2 when features requiring complex numbers are enabled. This limitation affects the efficiency of certain solver capabilities and restricts their practical application in industrial-scale problems. Preliminary observations suggest that complex arithmetic is a primary bottleneck, but systematic profiling is needed to confirm and quantify these losses. The project's objective is to profile the solver to identify performance hotspots, validate that complex arithmetic is the root cause, and develop a custom complex arithmetic library optimised for SU2's specific use cases. This work will enable more efficient execution of complex-number-dependent features without compromising computational performance.
+Expected Outcome (deliverables): Performance profiling report, custom complex arithmetic library (if validated as necessary), benchmark comparisons demonstrating speedup, integration into SU2 codebase, and documentation with usage guidelines.
+- Skills Required: C++
+- Possible Mentors: Joshua A. Kelly (lead), Harsh Mishra
+- Expected Project Size (90 hrs/ small , 175 hrs/medium, 350 hrs/large): 175 hrs (medium)
+- Difficulty rating: **medium**
+
+## Project PIML: Towards physics-informed machine learning with SU2
+Project Description (max. 5 Sentences)
+SU2 uses algorithmic differentiation (AD) for the adjoint solver and has the ability to use multi-layer perceptrons in data-driven equation of state models through the [MLPCpp](https://github.com/EvertBunschoten/MLPCpp.git) submodule. The aim of this project is to combine these two functionalities to enable physics-informed machine learning (PIML) in SU2 by updating the weights and biases of multi-layer perceptrons using AD for sensitivity calculation. PIML would enable data-driven turbulence modeling, solving partial differential equations without a mesh, and open the door to many other interesting research opportunities.
+Expected Outcome (deliverables): Demonstration of training a MLP for a reference data set within SU2 and comparison, MLP training library including at least one commonly used training algorithm (e.g. Adam), and documentation explaining usage.
+- Skills Required: C++, experience with machine learning
+- Possible Mentors: Evert Bunschoten (lead)
+- Expected Project Size (90 hrs/ small , 175 hrs/medium, 350 hrs/large): 175 hrs (medium)
+- Difficulty rating: **medium-hard**
+
+## Project FWH: Generalizing FWH-Based Aeroacoustic Noise Prediction
+This project aims to generalize a Python tool that implements Farassat’s 1A formulation of the Ffowcs Williams-Hawkings (FWH) equation for far-field noise prediction. While originally developed for tandem cylinder test cases and recently extended to airfoils, the current implementation is limited by case-specific logic. The primary objective is to refactor the codebase into a robust, geometry-agnostic framework capable of handling diverse and complex flow configurations. Test cases should be included in the regression tests.
+Expected Outcome (deliverables): A stand-alone Python code.
+- Skills Required: Python
+- Possible Mentors: Huseyin Ozdemir, (lead) Nijso Beishuizen
+- Expected Project Size (90 hrs/ small, 175 hrs/medium, 350 hrs/large): 175 hrs (medium)
+- Difficulty rating: **medium**
+-
diff --git a/_gsoc/Participation.md b/_gsoc/Participation.md
new file mode 100644
index 00000000..3e851834
--- /dev/null
+++ b/_gsoc/Participation.md
@@ -0,0 +1,39 @@
+---
+title: Student Participation
+permalink: /gsoc/Participation/
+---
+
+**Welcome to SU2 - GSOC!**
+
+## What is Google Summer of Code?
+
+[Google Summer of Code](https://summerofcode.withgoogle.com/)
+
+Google Summer of Code is a program sponsored by Google to let students interested in Open Source work on cool and challenging open source projects. The basic idea is that you will work together with a mentor on a project. We have selected a couple of main topics for you but it is up to you to write a more complete project proposal. If you have ideas of your own, that is fine too but you will need to find a mentor to supervise such a project.
+
+If you would like to apply, please make sure that you have subscribed to [CFD-online](https://www.cfd-online.com/Forums/su2/) and github, and additionally join the developers team on slack (see our main website [su2code](https://su2code.github.io/). In that way you can stay informed about SU2, and our GSOC involvement.
+
+If you are interested in applying for GSOC with an SU2 project, please do the following:
+1. send an application email to gsoc@su2foundation.org with some personal details, education background and motivation.
+2. become a member of our slack channel and subscribe to the **general** and **gsoc** subchannel of SU2. Please introduce yourself :-)
+
+## To Apply:
+To be considered as a GSOC student for an SU2 project, it is not sufficient to simply write a proposal and send it to the google website. We will not accept students who never contacted us or did not finish the assignments. We encourage students to participate in code development by fixing bugs or working on features. The minimum requirements to get accepted by the SU2 team for a GSOC project are:
+
+- Create a brief resume with your contact details, your education and code experience. If we cannot contact you, *we will not contact you*.
+- Briefly write about your experience and interests in Computational Fluid Dynamics and SU2, and the specific project you would like to work on (if you know this already)
+- Briefly write about your current work schedule: are you studying/working, how will you manage the time, etc..
+- Send it to gsoc@su2foundation.org
+- Make the assignments on the assignment page and send us your github page with your results.
+- work on fixing things in SU2
+
+Then in the last stage:
+
+- **Together with a mentor** you will create a project proposal and a planning with a timeline containing a breakdown of the project in parts with periodic deliverables/milestones.
+
+## Evaluation
+Note that applying does not mean acceptance into the program. We will carefully consider your application to see if you are capable of the job, taking into account your experience and availability. We heavily weigh your participation and visibility in the introduction phase.
+Please note that experience with SU2 is required. A merged Pull Request on github is highly recommended experience. A pull request for a tutorial or validation testcase is also acceptable and will count as experience.
+
+## Use of AI
+We allow usage of AI tools to *assist* you with your work. However, we do not allow the use of AI in vibe-coding where you let AI generate code that you do not understand. We also do not allow AI for automatic discussions with mentors or other users. AI is your assistant, not your replacement. If you do everything with AI, we might as well do it ourselves without you.
diff --git a/_includes/gsoc_nav.html b/_includes/gsoc_nav.html
new file mode 100644
index 00000000..4065d44b
--- /dev/null
+++ b/_includes/gsoc_nav.html
@@ -0,0 +1,22 @@
+
+{% for section in site.data.gsoc %}
+
+
+
+
+ {% for item in section.gsoc %}
+ {% assign item_url = item | prepend:"/gsoc/" | append:"/" %}
+ {% assign p = site.gsoc | where:"url", item_url | first %}
+ {{ p.title }}
+ {% endfor %}
+
+
+
+{% endfor %}
+
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 %}
+
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
+---
+
+
+
+
+ {% include gsoc_nav.html %}
+
+
+
+
+
+
+
+
+
diff --git a/_tutorials/compressible_flow/ActuatorDisk_VariableLoad/ActuatorDisk_VariableLoad.md b/_tutorials/compressible_flow/ActuatorDisk_VariableLoad/ActuatorDisk_VariableLoad.md
index f532d610..c1f7c967 100644
--- a/_tutorials/compressible_flow/ActuatorDisk_VariableLoad/ActuatorDisk_VariableLoad.md
+++ b/_tutorials/compressible_flow/ActuatorDisk_VariableLoad/ActuatorDisk_VariableLoad.md
@@ -55,8 +55,8 @@ The global propeller data are:
- Advance Ratio = 2.81487
- Radius = 2.5146 m
-The thrust coefficient is defined using the "Renard" definition: the reference force is
, where *n* are the propeller rounds per second and *D* is the propeller diameter
-The advance ratio is defined as
.
+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
@@ -167,16 +167,16 @@ The `MARKER_ACTDISK` option, as the same for the configuration file, is used to
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
, where *n* are the propeller rounds per second and *D* is the propeller diameter.
+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
-- The thrust coefficient distribution
-- The power coefficient distribution
-- The radial force coefficient distribution
+- 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
, while the reference power is reference force is
+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.*
@@ -195,13 +195,13 @@ This script allows the user to use the `VARIABLE_LOAD` actuator disk type also w
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_hub: the hub radius expressed in meters.
-5. J: the advance ratio.
-6. Vinf: the free-stream velocity expressed in m/s.
+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.
+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:
diff --git a/_tutorials/compressible_flow/NICFD_nozzle/NICFD_nozzle_datadriven.md b/_tutorials/compressible_flow/NICFD_nozzle/NICFD_nozzle_datadriven.md
index 62c23885..6bac3dcf 100644
--- a/_tutorials/compressible_flow/NICFD_nozzle/NICFD_nozzle_datadriven.md
+++ b/_tutorials/compressible_flow/NICFD_nozzle/NICFD_nozzle_datadriven.md
@@ -11,7 +11,7 @@ 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](NICFD_nozzle.md) for nonideal compressible fluid flows.
+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.
diff --git a/_tutorials/incompressible_flow/Inc_Laminar_Diffusion_Flame/Inc_Laminar_Diffusion_Flame.md b/_tutorials/incompressible_flow/Inc_Laminar_Diffusion_Flame/Inc_Laminar_Diffusion_Flame.md
new file mode 100644
index 00000000..2490d2f6
--- /dev/null
+++ b/_tutorials/incompressible_flow/Inc_Laminar_Diffusion_Flame/Inc_Laminar_Diffusion_Flame.md
@@ -0,0 +1,193 @@
+---
+title: "Incompressible, Laminar counterflow diffusion flame"
+permalink: "/tutorials/Inc_Laminar_Diffusion_Flame/"
+written_by: Nijso Beishuizen
+for_version: 8.4.0
+revised_by: Nijso Beishuizen
+revision_date: 17-05-2026
+revised_version:
+solver: INC_NAVIER_STOKES
+requires: SU2_CFD
+complexity: intermediate
+follows:
+---
+
+
+## Goals
+
+
+*Figure (1): 2D axisymmetric configuration of the laminar counterflow diffusion flame. The axisymmetry is shown here vertically to align the simulation results with the usual lab orientation, but in the simulations, the axisymmetry axis is always horizontally at y=0.*
+
+In this tutorial we show how to setup a laminar diffusion flame computation for a counterflow flame. We will use a flamelet method to model combustion, which is a tabulated chemistry approach. The table was precomputed from 1D Cantera solutions using the SU2_DataMiner code. We then reproduce the experiments of C.K. Law, mentioned in his book *Combustion Physics* (2006).
+
+*Figure (2): Counterflow Diffusion burner from the Thomson Lab in Toronto: https://thomsonlab.mie.utoronto.ca/counterflow-diffusion-burner/.*
+## Resources
+
+The resources for this tutorial can be found in the [incompressible_flow/Inc_Laminar_Diffusion_Flame](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Laminar_Diffusion_Flame) 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 [counterflow.cfg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Laminar_Diffusion_Flame/counterflow.cfg).
+2. *Mesh file*: The geometry for this test case is a simple, 2D counterflow burner geometry, ([counterflow.su2](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Laminar_Diffusion_Flame/counterflow.su2)).
+3. *Manifold file*: We will use a 2D flamelet table with mixture fraction and enthalpy as the controlling variables. The lookup table contains a small enthalpy range for this specific setup. The detailed chemistry simulations were performed with cantera. The strain rate at which the counterflow flames were generated was 56 [1/s] to match the experimental setup. The file can be found at ([fgm_ch4_ZH.drg](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Laminar_Diffusion_Flame/fgm_ch4_ZH.drg)).
+
+The mesh is created using [gmsh](https://gmsh.info/) and a respective `.geo` script is available to recreate/modify the mesh [counterflow.geo](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Laminar_Diffusion_Flame/counterflow.geo). The mesh has quadrilateral cells, with 8324 elements and 8551 points. This very coarse mesh is sufficient to capture accurately resolve the flame for this testcase.
+
+
+*Figure (3): Computational mesh with color indication of the used boundary conditions.*
+
+
+## Background
+
+For premixed flames, the controlling variable is the progress variable C, which monitors the progress of combustion. The smallest value represents the unburnt mixture and the largest value the burnt mixture, and in the reaction zone the progress variable is monotonously increasing. For nonpremixed flames, also called diffusion flames, the main controlling variable is the mixture fraction Z: Z=1 for the fuel and Z=0 for the oxidizer. In partially premixed combustion we need to solve a transport equation for both. The usual flamelet approach is to solve 1D flames using detailed chemistry. This can be done with detailed chemistry packages like cantera, FlameMaster, chem1d or other chemistry software. The solution is then rewritten into progress variable space or mixture fraction space. For example temperature T(x) is rewritten to T(Z). For purely premixed flames, the 1d solutions have to be generated for the equivalence ratio $\phi$ of the problem that you want to study. For purely nonmpremixed flames, the 1d solutions have to be generated for the strain rate $s$ of the problem. The equivalence ratio stays constant in purely premixed flames. However, in purely nonpremixed flames the strain rate is usually not constant except in exceptional cases like counterflow diffusion flames. So in general, a nonpremixed laminar flame needs 2 controlling variables: the mixture fraction and a controlling variable representing the strain rate. This will be treated in another tutorial. For this tutorial we will stick with a fixed strain rate.
+That means combustion is in our case described solely by the transport equation for mixture fraction:
+
+$$ \frac{\partial Z}{dt} + \nabla \cdot (\rho u Z) = \nabla\cdot (D \nabla Z) $$
+
+Where the diffusion coefficient D is retrieved from the lookup table.
+
+When heat loss occurs, the enthalpy also has to be taken into account as a controlling variable. Usually, heat losses are important and are taken into account by default in flamelet approaches. We also generate a lookup table as function of mixture fraction and enthalpy here. In SU2, an additional enthalpy equation is solved together with mixture fraction (the original energy equation of the flow solver is de-activated). Fluid and chemistry properties are tabulated from cantera results, stored in a LUT.drg file and retrieved from the lookup table every iteration.
+
+
+## Problem Setup
+
+The Flamelet Generated Manifold method used the incompressible flow solver, so we set:
+```
+SOLVER = INC_NAVIER_STOKES
+```
+
+
+### Enabling Flamelet Fluid Model
+Setting the fluid model to **FLAMELET** activates the scalar solver. The **CONTROLLING_VARIABLE_NAMES** determines the number of transport equations. The number of controlling variables and their names have to match what is in the lookup table. The lookup table file is given using **FILENAMES_INTERPOLATOR**. With **CONTROLLING_VARIABLE_SOURCE_NAMES** we define the main reaction source term for each of the controlling variables. Just put NULL if the controlling variable does not have a source term. Note that mixture fraction and enthalpy do not get any source terms here.
+
+```
+FLUID_MODEL= FLUID_FLAMELET
+CONTROLLING_VARIABLE_NAMES= (MixtureFraction, EnthalpyTot)
+FILENAMES_INTERPOLATOR= fgm_ch4_ZH.drg
+CONTROLLING_VARIABLE_SOURCE_NAMES = (NULL, NULL)
+```
+
+We use a flamelet model for the other fluid submodels, except for density. For density, we use the incompressible ideal gas law. In that case we do not have to store density in the table. The results are the same.
+
+```
+KIND_SCALAR_MODEL= FLAMELET
+DIFFUSIVITY_MODEL= FLAMELET
+VISCOSITY_MODEL= FLAMELET
+CONDUCTIVITY_MODEL= FLAMELET
+INC_DENSITY_MODEL= VARIABLE
+INC_ENERGY_EQUATION = NO
+```
+Note that the energy equation from the flow solver will always be de-activated.
+
+
+### Passive look-up terms
+
+To compare the species mole fractions with experiments, we need to look up these values from the table and then save them in for instance the paraview file for visualization. All quantities defined by **LOOKUP_NAMES** are passive values and are only retrieved from the table and then saved to an output file.
+```
+LOOKUP_NAMES = (MolarWeightMix, Conductivity, Cp, Heat_Release, DiffusionCoefficient, X-CO, X-CO2, X-H2O, X-CH4, X-O2)
+```
+
+
+### Boundary conditions
+
+The inlet boundary conditions for the counterflow diffusion flame are U=0.45 m/s for the fuel and air inlet.
+At the wall, a zero heat flux is imposed. Note that for the flamelet method, we solve our own transport equation for the energy (total enthalpy). The regular energy equation of the flow solver is passive. We now have two methods to impose a boundary condition for the energy equation. The first one is using the temperature and heat flux from the flow solver:
+```
+MARKER_INLET = (inlet_fuel, 305., 0.45, 0.0, 1.0, 0.0, inlet_oxidizer, 305., 0.45, 0.0,-1.0, 0.0)
+MARKER_HEATFLUX= (wall_fuel, 0.0, wall_oxidizer, 0.0, wall_outlet, 0.0)
+```
+The inlet temperature is then internally converted to a value for total enthalpy and this value is imposed on the total enthalpy equation of the flamelet solver. The second method is by directly imposing the inlet value and boundary for total enthalpy,
+
+```
+MARKER_INLET_SPECIES = (inlet_fuel, 1.0, -4.654e6, inlet_oxidizer, 0.0, 1.9e3)
+MARKER_WALL_SPECIES= (wall_fuel, FLUX, 0.0, VALUE, -4.645e6, wall_oxidizer, FLUX, 0.0, VALUE, 1.90e3)
+```
+
+In this case, the temperature follows from the imposed enthalpy.
+To switch between the two methods, you can use the configuration option:
+```
+FLAMELET_ENTHALPY_BC= FLOW_MARKERS
+% FLAMELET_ENTHALPY_BC= SPECIES_MARKERS
+```
+Since we know from the experiment the inlet temperature, we use **FLOW_MARKERS** to define temperature.
+
+For the initialization of the flame we define a plane, and on one side of the plane we set Z=0 and on the other we set Z=1. We define a transition region of 1e-4 at the interface.
+```
+FLAME_INIT_METHOD= FLAME_FRONT
+% make sure to put it to NONE when restarting
+%FLAME_INIT_METHOD= NONE
+FLAME_INIT= (-0.006, 0.00, 0.00, 1.0, 0.0, 0.0, 1.0e-4, 1.0)
+```
+This method also overrules any values defined using **SPECIES_INIT**.
+
+### Manifold set-up
+The lookup table was generated using the SU2_DataMiner package, which can be found here:
+[SU2_DataMiner](https://github.com/su2code/SU2_DataMiner)
+We will not go into the table generation now, but merely provide the results. For the constant strain diffusion flamelets, we fix the strain rate and run a series of counterflow flames for different enthalpies (we vary the inlet temperature). The resulting solutions for temperature are shown below:
+
+
+*Figure (4): The 1D cantera solutions for the counterflow flames, using a variation in inlet temperature.*
+
+We then store the 1D solutions as a 2D field with mixture fraction and enthalpy as the independent variables. The result for temperature and heat release rate is shown below:
+
+
+*Figure (5): A 2D surface representation of the FGM, showing the temperature and the heat release rate as function of mixture fraction and enthalpy. Note that our enthalpy range is not very large. We can represent constant strain flames with different inlet temperatures, but for simulations with large heat losses the table has to be extended to lower enthalpies.*
+
+Note that the mixture fraction equation is a diffusion equation and does not contain any source terms, unlike the progress variable equation for premixed flames.
+
+
+## Running SU2
+
+The simulation can be run in serial using the following command:
+```
+$ SU2_CFD lam_nonprem_ch4.cfg
+```
+or in parallel with your preferred number of cores:
+```
+$ mpirun -n <#cores> SU2_CFD lam_nonprem_ch4.cfg
+```
+
+## Results
+
+After 800 iterations, the simulation has converged. The convergence plot normalized with the first value of the residual looks like this:
+
+
+*Figure (6): Residual plot showing convergence of the counterflow diffusion flame.*
+
+The residuals for pressure and velocity have dropped by 6 orders of magnitude, which is sufficient for this testcase.
+
+A contour plot of the temperature field in the domain is shown below. Note that only 1/3 of the right vertical edge is an outlet. The smaller outlet will force the flow to accelerate close to the outlet. This prevents backflow, which deteriorates convergence.
+
+
+*Figure (7): Result visualized using paraview. Shown is the temperature field and the streamlines colored by mixture fraction.*
+
+In the figure we have also indicated the isocontours of mixture fraction for values Z=0.4 (blue), Z=0.5 (dark purple) and Z=0.6 (red), showing that the maximum temperature occurs at $Z<0.4$. The flame looks very diffusive close to the outlet because of the blockage in the corners. Here, a low velocity recirculation zone in the top and bottom corner is mixing the fuel and air, causing the diffusive behavior.
+
+A figure of the temperature on the symmetry axis is shown below, together with measured results from Sung et al. (1995). These results are also mentioned in the book of C.K. Law, *Combustion Physics*.
+
+*Figure (8): Temperature as function of distance (from the fuel inlet) on the symmetry axis.*
+
+We see that the temperature profile is predicted quite accurately, for the first order as well as for the second order MUSCL scheme.
+
+The methane mole fraction at the fuel inlet was 23%, which can be clearly seen in the figure for mole fraction of $CH_4$ below.
+
+*Figure (9): Methane mole fraction as function of distance (from the fuel inlet) on the symmetry axis.*
+
+A first sanity check is always to to check that inlet mass fraction or mole fractions are correct. The consumption of $CH_4$ in the flame is also predicted correctly
+
+The $CO_2$ mole fraction is zero at both inlets and rises in the reaction zone.
+
+*Figure (10): Mole fraction of CO2 as function of distance (from the fuel inlet) on the symmetry axis.*
+
+As for $CH_4$, the $CO_2$ mole fraction in the flame zone is correctly predicted, the maximum value as well as the slope is matching with the experiment.
+
+The lookup value for CO is much lower than the experimentally measured value. CO as well as NO are very slow reactions, and are not accurately predicted by flamelet approaches. To get more accurate results for CO or NO, a separate transport equation should be solved for them. Instead of the value for CO, we look up the source term for the transport equation for CO.
+
+*Figure (11): Mole fraction of CO as function of distance (from the fuel inlet) on the symmetry axis.*
+
+The temperature can also be plotted as function of the mixture fraction, leading to the 1D flamelet result shown below.
+
+*Figure (12): Temperature as function of mixture fraction, using the values taken at the symmetry axis.*
+
+This shows the typical Burke-Schumann- like behavior where the diffusion flame can be described by a pre-flame and a post-flame zone with almost linear slope for temperature.
+
+Note that the lookup table for this tutorial is for methane-air and a strain rate of 56 1/s. If you have a different configuration, you will need to generate your own table.
+
diff --git a/_tutorials/incompressible_flow/Inc_Urban_City/Inc_Urban_City.md b/_tutorials/incompressible_flow/Inc_Urban_City/Inc_Urban_City.md
index 353bef12..78a43d65 100644
--- a/_tutorials/incompressible_flow/Inc_Urban_City/Inc_Urban_City.md
+++ b/_tutorials/incompressible_flow/Inc_Urban_City/Inc_Urban_City.md
@@ -1,5 +1,5 @@
---
-title: unsteady pollutant dispersion in a city
+title: Wind velocity and pollutant dispersion in a city
permalink: /tutorials/Inc_Urban_City/
written_by: Nijso Beishuizen
for_version: 8.4.0
@@ -26,7 +26,7 @@ In this tutorial we will look at the modeling of wind speed and pollutant disper
## Resources
-The resources for this tutorial can be found in the [incompressible_flow/Inc_Urban_City](https://github.com/su2code/Tutorials/tree/master/incompressible_flow/Inc_Urban_City) directory in the [tutorial repository](https://github.com/su2code/Tutorials).
+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
diff --git a/_tutorials/index.md b/_tutorials/index.md
index 0fa54c5a..2c590ab9 100644
--- a/_tutorials/index.md
+++ b/_tutorials/index.md
@@ -54,6 +54,8 @@ Simulation of compressible flow in a nozzle using non-ideal thermodynamic models
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
@@ -105,6 +107,8 @@ Simulation of multiple heated cylinders in incompressible fluid flow.
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.
+* [Laminar Diffusion Flame](/tutorials/Inc_Laminar_Diffusion_Flame/)
+Simulation of a laminar, non-premixed counterflow flame with constant strain rate.
* [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/)
diff --git a/_tutorials/multiphysics/TFC_python/TFC_python.md b/_tutorials/multiphysics/TFC_python/TFC_python.md
index 819403b5..c68c858b 100644
--- a/_tutorials/multiphysics/TFC_python/TFC_python.md
+++ b/_tutorials/multiphysics/TFC_python/TFC_python.md
@@ -27,7 +27,7 @@ In this tutorial we will touch upon the following aspects:
## Resources
-The resources for this tutorial can be found in the [TFC_python](https://github.com/su2code/Tutorials/tree/master/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/master/multiphysics/TFC_python/adiabatic/psi.cfg)) and the mesh file ([psi.su2](https://github.com/su2code/Tutorials/tree/master/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/master/multiphysics/TFC_python/psi.geo). Files for the non-adiabatic case are in the folder [enthalpy](https://github.com/su2code/Tutorials/tree/master/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/master/multiphysics/TFC_python/quench)
+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
@@ -55,7 +55,7 @@ Note that the python wrapper (or your python setup) might need additional python
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/master/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.
+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
diff --git a/download.html b/download.html
index 0b3cea57..9603593a 100644
--- a/download.html
+++ b/download.html
@@ -16,14 +16,14 @@