From 2f4b5828f3fff5d48bcbfccf0fb09c31c8ebb2ee Mon Sep 17 00:00:00 2001 From: TobiKattmann Date: Wed, 28 Jun 2023 10:40:26 +0200 Subject: [PATCH 01/14] Update frontpage with the 4th conference banner information. --- index.html | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index d97728cf..d88037ee 100644 --- a/index.html +++ b/index.html @@ -38,8 +38,9 @@

Powerful. Fast. Free.

-

3rd Annual SU2 Conference

-

Presentation slides and recordings will be available on the conference website.

+

4th Annual SU2 Conference

+

The 4th edition of the SU2 conference takes place in Varenna/Italy on the 23rd - 25th of October.

+

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.

From fc009845125e607ae5df5024f289c820bbfbd040 Mon Sep 17 00:00:00 2001 From: Ambati Rajashekar <89978753+Rajashekar25@users.noreply.github.com> Date: Sat, 22 Jul 2023 17:54:44 +0530 Subject: [PATCH 02/14] Update Test-Cases.md Removed ./configure and make install lines as they are not necessary. --- _docs_v7/Test-Cases.md | 2 -- 1 file changed, 2 deletions(-) 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 From 265f1376abad97aa95aa8987ed88d6aa6a90eb07 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Johannes=20Bl=C3=BChdorn?= Date: Fri, 11 Aug 2023 12:13:08 +0200 Subject: [PATCH 03/14] Update software versions and container image host. --- _docs_v7/Container-Development.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/_docs_v7/Container-Development.md b/_docs_v7/Container-Development.md index 99997899..753cea12 100644 --- a/_docs_v7/Container-Development.md +++ b/_docs_v7/Container-Development.md @@ -22,7 +22,7 @@ We use [Docker](https://www.docker.com/) container during the software developme The files for the creation of the containers can found in the [Docker-Builds](https://github.com/su2code/Docker-Builds) repository. Currently we have three different containers: -- **build-su2**: Based on Ubuntu 18.04 (GCC v7.4.0, OpenMPI v2.1.1) it features all necessary packages that are needed to compile SU2. Furthermore a script is provided (set as the [entrypoint](https://docs.docker.com/engine/reference/builder/#entrypoint)) that will checkout and compile a specific branch with provided build options. +- **build-su2**: Based on Ubuntu 20.04 (GCC v9.4.0, OpenMPI v4.0.3) it features all necessary packages that are needed to compile SU2. Furthermore a script is provided (set as the [entrypoint](https://docs.docker.com/engine/reference/builder/#entrypoint)) that will checkout and compile a specific branch with provided build options. - **test-su2**: Based on the latest **build-su2** container. Includes a script that checks out the test cases and the tutorials and runs a specified test script. - **build-su2-cross**: Based on the latest **build-su2** container it features an environment to create binaries for Linux, MacOS and Windows. All libraries are linked statically (including a custom build MPICH v3.3.2) with the binaries if a host file is specified in order achieve portability. For more information have a look at the [ReadMe](https://github.com/su2code/Docker-Builds/blob/master/build_cross/README.md). @@ -30,7 +30,8 @@ The files for the creation of the containers can found in the [Docker-Builds](ht It is assumed that you have added your linux username to the `docker` group, like it is explained [here](https://docs.docker.com/install/linux/linux-postinstall/). Otherwise `sudo` is required to run docker. There also a [rootless version](https://docs.docker.com/engine/security/rootless/) available. -The most recent versions can be found on [Docker Hub](https://hub.docker.com/r/su2code/) and can be pulled with `docker pull su2code/*` (where `*` can be replaced with `build-su2`, `test-su2` or `build-su2-cross`) if docker is properly installed on your machine. +The most recent versions of prebuilt container images can be found in the [GitHub container registry](https://github.com/orgs/su2code/packages). You can click on an image to see its versions and the command for pulling it, e.g., `docker pull ghcr.io/su2code/su2/build-su2:230704-1323`. + In the following we give a small overview on how to use the containers to compile and run the tests. We will only cover basic commands for docker. If you are interested in learning more, check out the [official documentation](https://docs.docker.com/). From a8fd00d198fd08225cc70a65611d328cee4fa95c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Johannes=20Bl=C3=BChdorn?= Date: Fri, 11 Aug 2023 12:14:45 +0200 Subject: [PATCH 04/14] Update docker commands. --- _docs_v7/Container-Development.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/_docs_v7/Container-Development.md b/_docs_v7/Container-Development.md index 753cea12..a183772c 100644 --- a/_docs_v7/Container-Development.md +++ b/_docs_v7/Container-Development.md @@ -41,7 +41,7 @@ In the following we give a small overview on how to use the containers to compil A container can be started using the `run` command and the name, e.g. ``` -docker run su2code/build-su2 +docker run su2code/su2/build-su2 ``` You should see the following message, which means that everything works as intended: ``` @@ -58,7 +58,7 @@ The containers we provide all feature entrypoint scripts, i.e. a script that is A typical call where the current directory on the host is mounted and used as working directory would look like this: ``` -docker run -ti --rm -v $PWD:/workdir/ -w /workdir --entrypoint bash su2code/build-su2 +docker run -ti --rm -v $PWD:/workdir/ -w /workdir --entrypoint bash su2code/su2/build-su2 ``` Here, we also override the entrypoint in order to execute a bash shell. Note, that all changes you make will be lost after you exit the container (except from changes in the working directory). Once in the bash you can simply use an existing or new clone of the repository to compile SU2 [the usual way](/docs_v7/Build-SU2-Linux-MacOS/). @@ -69,7 +69,7 @@ The scripts provide an easy way to directly clone and compile a specific branch The [compile script](https://github.com/su2code/Docker-Builds/blob/master/build/compileSU2.sh) expects two arguments, the build flags for meson and the branch name. They are given with `-f` and `-b`, respectively. E.g. to compile the master branch with python wrapper enabled: ``` -docker run -ti --rm su2code/build-su2 -f "-Denable-pywrapper=true" -b master +docker run -ti --rm su2code/su2/build-su2 -f "-Denable-pywrapper=true" -b master ``` ### Accessing source code and binaries ### @@ -83,7 +83,7 @@ Instead of checking out a fresh copy of the source code, it is also possible to ``` docker run -ti --rm -v ~/Documents/SU2:/workdir/src/SU2 \ -v ~/Documents/SU2/bin:/workdir/install/ -w /workdir \ - su2code/build-su2 -f "-Denable-pywrapper=true" + su2code/su2/build-su2 -f "-Denable-pywrapper=true" ``` The binaries can then be found at `~/Documents/SU2/bin`. @@ -100,7 +100,7 @@ The compiled binaries used for the tests must be mounted at `/install/bin`. The following command will clone the master branches of all required repositories and run the `parallel_regression.py` script: ``` docker run -ti --rm -v ~/Documents/SU2/bin:/workdir/install/bin \ - -w /workdir su2code/test-su2 -t master -b master -c master -s parallel_regression.py + -w /workdir su2code/su2/test-su2 -t master -b master -c master -s parallel_regression.py ``` Similar to the compilation script, you can use already existing clones of the repositories by mounting them at `/src/Tutorials`, `/src/SU2`, `/src/TestData` and omitting the `-t`, `-b` or `-c` option, respectively. @@ -109,9 +109,9 @@ The following example will compile SU2 using the `build-su2` container and then ``` docker run -ti --rm -v $PWD:/workdir/ -w /workdir \ - su2code/build-su2 -f "-Denable-pywrapper=true" -b develop + su2code/su2/build-su2 -f "-Denable-pywrapper=true" -b develop docker run -ti --rm -v $PWD/install/bin:/workdir/install/bin -w /workdir \ -v $PWD/src/SU2_develop:/workdir/src/SU2 \ - su2code/test-su2 -t develop -c develop -s parallel_regression.py -``` \ No newline at end of file + su2code/su2/test-su2 -t develop -c develop -s parallel_regression.py +``` From d70b17e580b07b781b03f142c975ed5b2b4abd5f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Johannes=20Bl=C3=BChdorn?= Date: Fri, 11 Aug 2023 12:28:08 +0200 Subject: [PATCH 05/14] Add descriptions of thread sanitizer containers. --- _docs_v7/Container-Development.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/_docs_v7/Container-Development.md b/_docs_v7/Container-Development.md index a183772c..c932a1b7 100644 --- a/_docs_v7/Container-Development.md +++ b/_docs_v7/Container-Development.md @@ -25,6 +25,8 @@ The files for the creation of the containers can found in the [Docker-Builds](ht - **build-su2**: Based on Ubuntu 20.04 (GCC v9.4.0, OpenMPI v4.0.3) it features all necessary packages that are needed to compile SU2. Furthermore a script is provided (set as the [entrypoint](https://docs.docker.com/engine/reference/builder/#entrypoint)) that will checkout and compile a specific branch with provided build options. - **test-su2**: Based on the latest **build-su2** container. Includes a script that checks out the test cases and the tutorials and runs a specified test script. - **build-su2-cross**: Based on the latest **build-su2** container it features an environment to create binaries for Linux, MacOS and Windows. All libraries are linked statically (including a custom build MPICH v3.3.2) with the binaries if a host file is specified in order achieve portability. For more information have a look at the [ReadMe](https://github.com/su2code/Docker-Builds/blob/master/build_cross/README.md). +- **build-su2-tsan**: Based on the same setup as **build-su2**, this container is intended to build SU2 with the thread sanitizer for automatic data race detection. To this end, it features a custom gcc build and provides a preconfigured environment for building with the thread sanitizer. +- **test-su2-tsan**: Like **test-su2** but based on the latest **build-su2-tsan** container instead. Can be used like **test-su2** and is intended for testing for data races. **Note:** The build containers *do not* include binaries to run SU2, and they are not intended to do so (except for running the regression tests). From d66039ab71e6b87d114e4863beff8551294cc6b5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Johannes=20Bl=C3=BChdorn?= Date: Fri, 11 Aug 2023 12:35:01 +0200 Subject: [PATCH 06/14] Extended description, wording. --- _docs_v7/Container-Development.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/_docs_v7/Container-Development.md b/_docs_v7/Container-Development.md index c932a1b7..0efb7927 100644 --- a/_docs_v7/Container-Development.md +++ b/_docs_v7/Container-Development.md @@ -23,16 +23,16 @@ We use [Docker](https://www.docker.com/) container during the software developme The files for the creation of the containers can found in the [Docker-Builds](https://github.com/su2code/Docker-Builds) repository. Currently we have three different containers: - **build-su2**: Based on Ubuntu 20.04 (GCC v9.4.0, OpenMPI v4.0.3) it features all necessary packages that are needed to compile SU2. Furthermore a script is provided (set as the [entrypoint](https://docs.docker.com/engine/reference/builder/#entrypoint)) that will checkout and compile a specific branch with provided build options. -- **test-su2**: Based on the latest **build-su2** container. Includes a script that checks out the test cases and the tutorials and runs a specified test script. -- **build-su2-cross**: Based on the latest **build-su2** container it features an environment to create binaries for Linux, MacOS and Windows. All libraries are linked statically (including a custom build MPICH v3.3.2) with the binaries if a host file is specified in order achieve portability. For more information have a look at the [ReadMe](https://github.com/su2code/Docker-Builds/blob/master/build_cross/README.md). +- **test-su2**: Based on the corresponding version of the **build-su2** container. Includes a script that checks out the test cases and the tutorials and runs a specified test script. +- **build-su2-cross**: Based on the corresponding version of the **build-su2** container. It features an environment to create binaries for Linux, MacOS and Windows. All libraries are linked statically (including a custom build MPICH v3.3.2) with the binaries if a host file is specified in order achieve portability. For more information have a look at the [ReadMe](https://github.com/su2code/Docker-Builds/blob/master/build_cross/README.md). - **build-su2-tsan**: Based on the same setup as **build-su2**, this container is intended to build SU2 with the thread sanitizer for automatic data race detection. To this end, it features a custom gcc build and provides a preconfigured environment for building with the thread sanitizer. -- **test-su2-tsan**: Like **test-su2** but based on the latest **build-su2-tsan** container instead. Can be used like **test-su2** and is intended for testing for data races. +- **test-su2-tsan**: Like **test-su2** but based on the corresponding version of the **build-su2-tsan** container instead. Can be used like **test-su2** and is intended for testing for data races. **Note:** The build containers *do not* include binaries to run SU2, and they are not intended to do so (except for running the regression tests). It is assumed that you have added your linux username to the `docker` group, like it is explained [here](https://docs.docker.com/install/linux/linux-postinstall/). Otherwise `sudo` is required to run docker. There also a [rootless version](https://docs.docker.com/engine/security/rootless/) available. -The most recent versions of prebuilt container images can be found in the [GitHub container registry](https://github.com/orgs/su2code/packages). You can click on an image to see its versions and the command for pulling it, e.g., `docker pull ghcr.io/su2code/su2/build-su2:230704-1323`. +The most recent versions of prebuilt container images can be found in the [GitHub container registry](https://github.com/orgs/su2code/packages). You can click on an image to see its versions and the command for pulling it, e.g., `docker pull ghcr.io/su2code/su2/build-su2:230704-1323` for a specific version of **build-su2**. In the following we give a small overview on how to use the containers to compile and run the tests. We will only cover basic commands for docker. If you are interested in learning more, check out the [official documentation](https://docs.docker.com/). @@ -50,7 +50,7 @@ You should see the following message, which means that everything works as inten SU2 v7 Docker Compilation Container SU2 source directory not found. Make sure to ... ``` -The containers we provide all feature entrypoint scripts, i.e. a script that is executed when the container is started. If no arguments are given, like in the command above, it just prints an error message. The arguments of the compile and test scripts are discussed [here](#using-the-scripts-to-compile-su2). If the image does not already exist locally, it will be pulled from docker hub. You can specify a tag by adding `:tagname` to the name. If none is specified, it will use `:latest` by default. Let us have a look at the most important arguments for the `docker run` command: +The containers we provide all feature entrypoint scripts, i.e. a script that is executed when the container is started. If no arguments are given, like in the command above, it just prints an error message. The arguments of the compile and test scripts are discussed [here](#using-the-scripts-to-compile-su2). Make sure to pull the image first, as explained above, or provide the full URL including a version tag, e.g., `ghcr.io/su2code/su2/build-su2:230704-1323`. Let us have a look at the most important arguments for the `docker run` command: - `-ti` (or `--interactive --tty`): Needed to provide input to the container (stdin) via the terminal. - `--rm`: Automatically remove the container when it exits (otherwise ressources (disk space) are still occupied) From a451fc13fa8438a7ea31f0a35d8d48983d892b33 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Johannes=20Bl=C3=BChdorn?= Date: Tue, 15 Aug 2023 16:08:32 +0200 Subject: [PATCH 07/14] Add paragraphs on thread sanitizer tests. --- _docs_v7/Container-Development.md | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/_docs_v7/Container-Development.md b/_docs_v7/Container-Development.md index 0efb7927..9c511745 100644 --- a/_docs_v7/Container-Development.md +++ b/_docs_v7/Container-Development.md @@ -58,11 +58,17 @@ The containers we provide all feature entrypoint scripts, i.e. a script that is - `--volume :` (or `-v`): Bind mount a volume where `` is a local folder on the host and `` the mount location in the container. - `--workdir ` (or `-w`): The working directory inside the container. +### Working interactively in a container ### + A typical call where the current directory on the host is mounted and used as working directory would look like this: ``` docker run -ti --rm -v $PWD:/workdir/ -w /workdir --entrypoint bash su2code/su2/build-su2 ``` -Here, we also override the entrypoint in order to execute a bash shell. Note, that all changes you make will be lost after you exit the container (except from changes in the working directory). Once in the bash you can simply use an existing or new clone of the repository to compile SU2 [the usual way](/docs_v7/Build-SU2-Linux-MacOS/). +Here, we also override the entrypoint in order to execute a bash shell. Note that all changes you make will be lost after you exit the container (except from changes in the working directory). Once in the bash you can simply use an existing or new clone of the repository to compile SU2 [the usual way](/docs_v7/Build-SU2-Linux-MacOS/), run a regression test script, or execute a specific regression test. + +This interactive way of using the container gives you most control over building and testing SU2, we recommend it particularly for running specific tests instead of entire test scripts, e.g., when debugging them with the thread sanitizer. If you look for an out-of-the-box way of compiling and testing SU2, please refer to the sections about using the scripts below. + +If you want to build SU2 with the thread sanitizer, you work with the **build-su2-tsan** container instead and compile SU2 as explained above. Note that the thread sanitizer is only meaningful for SU2 builds with OpenMP. You don't have to supply any additional flags when configuring, compiling, or running, the container provides a fully configured environment. Any test executed with SU2 built this way will perform thread sanitizer analysis. ## Using the scripts to compile SU2 ## @@ -117,3 +123,16 @@ docker run -ti --rm -v $PWD/install/bin:/workdir/install/bin -w /workdir \ -v $PWD/src/SU2_develop:/workdir/src/SU2 \ su2code/su2/test-su2 -t develop -c develop -s parallel_regression.py ``` + +### Running thread sanitizer tests ### + +If you want to run thread sanitizer tests, you have to build SU2 with the **build-su2-tsan** container and test with the **test-su2-tsan** container. Thread sanitizer analysis is only meaningful for OpenMP builds and the hybrid regression scripts. It is advisable to use optimized debug builds to reduce runtime while still getting useful stack traces. You should provide the `--tsan` flag to the test script, which disables tests that are either not compatible with the thread sanitizer or take too long to run. The following example demonstrates thread sanitizer testing. + +``` +docker run -ti --rm -v $PWD:/workdir/ -w /workdir \ + su2code/su2/build-su2-tsan -f "--buildtype=debugoptimized -Dwith-omp=true" -b develop + +docker run -ti --rm -v $PWD/install/bin:/workdir/install/bin -w /workdir \ + -v $PWD/src/SU2_develop:/workdir/src/SU2 \ + su2code/su2/test-su2-tsan -t develop -c develop -s hybrid_regression.py -a "--tsan" +``` From bfebfe008f49fc1e8ca385fb8747be49fb242dc8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Johannes=20Bl=C3=BChdorn?= Date: Tue, 15 Aug 2023 19:20:05 +0200 Subject: [PATCH 08/14] Add hint about develop branch. --- _docs_v7/Container-Development.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/_docs_v7/Container-Development.md b/_docs_v7/Container-Development.md index 9c511745..06f6ddbe 100644 --- a/_docs_v7/Container-Development.md +++ b/_docs_v7/Container-Development.md @@ -37,6 +37,8 @@ The most recent versions of prebuilt container images can be found in the [GitHu In the following we give a small overview on how to use the containers to compile and run the tests. We will only cover basic commands for docker. If you are interested in learning more, check out the [official documentation](https://docs.docker.com/). +Please note that some of the examples refer to features that are only available in the lasted [develop](https://github.com/su2code/SU2/tree/develop) branch of SU2. + ## Running a container ## From 12ddc8e8b99f69bef878a6f02944dfbb6556ebb1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Johannes=20Bl=C3=BChdorn?= Date: Tue, 15 Aug 2023 19:55:55 +0200 Subject: [PATCH 09/14] Small corrections. --- _docs_v7/Container-Development.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_docs_v7/Container-Development.md b/_docs_v7/Container-Development.md index 06f6ddbe..54e65571 100644 --- a/_docs_v7/Container-Development.md +++ b/_docs_v7/Container-Development.md @@ -20,7 +20,7 @@ A container is a virtual runtime environment that runs on top of a single operat We use [Docker](https://www.docker.com/) container during the software development life-cycle for running the regression tests and creating binaries for different operating systems during the release process. The execution of these containers is triggered by events (e.g. by a push to an open pull request) on Github using the [Github Actions](https://github.com/features/actions) feature. -The files for the creation of the containers can found in the [Docker-Builds](https://github.com/su2code/Docker-Builds) repository. Currently we have three different containers: +The files for the creation of the containers can found in the [Docker-Builds](https://github.com/su2code/Docker-Builds) repository. Currently we have five different containers: - **build-su2**: Based on Ubuntu 20.04 (GCC v9.4.0, OpenMPI v4.0.3) it features all necessary packages that are needed to compile SU2. Furthermore a script is provided (set as the [entrypoint](https://docs.docker.com/engine/reference/builder/#entrypoint)) that will checkout and compile a specific branch with provided build options. - **test-su2**: Based on the corresponding version of the **build-su2** container. Includes a script that checks out the test cases and the tutorials and runs a specified test script. @@ -37,7 +37,7 @@ The most recent versions of prebuilt container images can be found in the [GitHu In the following we give a small overview on how to use the containers to compile and run the tests. We will only cover basic commands for docker. If you are interested in learning more, check out the [official documentation](https://docs.docker.com/). -Please note that some of the examples refer to features that are only available in the lasted [develop](https://github.com/su2code/SU2/tree/develop) branch of SU2. +Please note that some of the examples refer to features that are only available in the latest [develop](https://github.com/su2code/SU2/tree/develop) branch of SU2. ## Running a container ## From 7532feb03c118f01a88b606660b67e93ca3e3e93 Mon Sep 17 00:00:00 2001 From: Cristopher-Morales Date: Tue, 29 Aug 2023 09:29:30 +0200 Subject: [PATCH 10/14] fixings and additions --- _docs_v7/Markers-and-BC.md | 12 +++++++++--- ..._Species_Transport_Composition_Dependent_Model.md | 5 ++--- _vandv/SANDIA_jet.md | 8 +++----- 3 files changed, 14 insertions(+), 11 deletions(-) diff --git a/_docs_v7/Markers-and-BC.md b/_docs_v7/Markers-and-BC.md index d4c925ec..f4edb12f 100755 --- a/_docs_v7/Markers-and-BC.md +++ b/_docs_v7/Markers-and-BC.md @@ -131,18 +131,24 @@ MARKER_FAR= (farfield) | --- | --- | | `RANS`, `INC_RANS`, | 7.3.0 | -The turbulence boundary conditions do not have a `MARKER_` keyword for the SA Turbulence model but can instead be set for inlet and freestream boundaries using the keyword: +The turbulence boundary conditions have a `MARKER_INLET_TURBULENT` keyword for the Turbulence models. For the SA turbulence model, ratio of turbulent to laminar viscosity can be provided at each inlet as follows: + +``` +MARKER_INLET_TURBULENT= (inlet_marker1, NuFactor1, inlet_marker2, NuFactor2, ...) +``` + +If 'MARKER_INLET_TURBULENT' is not provided in the .cfg file, SU2 will filled up the markers with the freestream option: ``` FREESTREAM_NU_FACTOR= 3 ``` -Conversely, for the SST turbulence model, it is possible to provide a 'MARKER_INLET' where turbulence intensity and turbulent-to-laminar ratio can be provided at each inlet as follows: +Similarly, for the SST turbulence model, turbulence intensity and turbulent-to-laminar ratio can be provided at each inlet as follows: ``` MARKER_INLET_TURBULENT= (inlet_1, TURBULENCEINTENSITY_1, TURB2LAMVISCRATIO_1 , inlet_2, TURBULENCEINTENSITY_1, TURB2LAMVISCRATIO_1 ,..) ``` -If 'MARKER_INLET_TURBULENT' are not provided in the .cfg file, SU2 will filled up the markers with the freestream options: +If 'MARKER_INLET_TURBULENT' is not provided in the .cfg file, SU2 will filled up the markers with the freestream options: ``` FREESTREAM_TURBULENCEINTENSITY= 0.05 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 index c937c4e0..0295da5e 100644 --- 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 @@ -131,11 +131,11 @@ 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). +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 `SPECIES_USE_STRONG_BC` is advised to be set to `NO` 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 `SPECIES_USE_STRONG_BC` is advised to be switched to `YES` to enforce boundary conditions and improve convergence for this convective scheme. The convective scheme `BOUNDED_SCALAR` will be further explained in the section [Convective-Schemes](/docs_v7/Convective-Schemes/). +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 in order 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. @@ -152,7 +152,6 @@ 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 ) -SPECIES_USE_STRONG_BC= NO MARKER_INLET_SPECIES= (inlet_gas, 1.0, inlet_air, 0.0 ) % MARKER_INLET_TURBULENT= (inlet_gas, 0.05, 10, inlet_air, 0.05, 10) diff --git a/_vandv/SANDIA_jet.md b/_vandv/SANDIA_jet.md index 108d2f93..7c15ebe1 100644 --- a/_vandv/SANDIA_jet.md +++ b/_vandv/SANDIA_jet.md @@ -8,9 +8,9 @@ permalink: /vandv/SANDIA_jet/ | `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},^{2}$$. +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},^{2}$$. -By comparing the results of SU2 simulations case against the experimental data, as well as OpenFOAM simulation results $$^{3}$$ (and MFSim $$^{4}$$), 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. +By comparing the results of SU2 simulations case against the experimental data, as well as OpenFOAM simulation results $$^{3}$$ (and MFSim $$^{4}$$), 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: @@ -137,8 +137,7 @@ The comparisons in the figures demonstrate good agreement with the experimental Mean density along Jet Centerline

-The experimental results for the mean density are given in Sandia’s database, but these are directly computed from the mixture fraction by making use of the ratio between the density of propane and air. The ratio that is being used for this purpose is 1.6 $$^{2}$$, whereas the expected ratio is lower. The higher density ratio used in the post-processing of the experimental data results in a wider -density range across the domain, which can partly explain the differences between the experimental data and the numerical results on the density along the jet centerline. Note that the spreading rate of a jet is independent of the initial density ratio $$^{2}$$. +The experimental results for the mean density are given in Sandia’s database, but these are directly computed from the mixture fraction by making use of the ratio between the density of propane and air. The ratio that is being used for this purpose is 1.6 $$^{2}$$, whereas the expected ratio is lower. The higher density ratio used in the post-processing of the experimental data results in a wider density range across the domain, which can partly explain the differences between the experimental data and the numerical results on the density along the jet centerline. Note that the spreading rate of a jet is independent of the initial density ratio $$^{2}$$.

Residuals Convergence for the Turbulent Jet Mixing @@ -147,7 +146,6 @@ density range across the domain, which can partly explain the differences betwee --- ### References - $$^{1}$$ R.W. Schefer, "Data Base for a Turbulent, Nonpremixed, Nonreacting, Propane-Jet Flow", tech. rep., Sandia National Laboratories, Livermore, CA, 2001. $$^{2}$$ R.W. Schefer, F.C. Gouldin, S.C. Johnson and W. Kollmann, "Nonreacting Turbulent Mixing Flows", tech. rep., Sandia National Laboratories, Livermore, CA, 1986. From 3b22c589f56550c0c992d4f7aa416e72ae06ac2a Mon Sep 17 00:00:00 2001 From: Cristopher-Morales Date: Tue, 29 Aug 2023 15:53:42 +0200 Subject: [PATCH 11/14] spelling fix --- _data/vandv.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_data/vandv.yml b/_data/vandv.yml index d989810f..b2aca204 100644 --- a/_data/vandv.yml +++ b/_data/vandv.yml @@ -12,6 +12,6 @@ - swbli - LM_transition -- title: Incompressbile Flow +- title: Incompressible Flow vandv: - SANDIA_jet \ No newline at end of file From ae1a4e793d74d4e8e7146e64a2f6b21693fb3d8c Mon Sep 17 00:00:00 2001 From: Cristopher-Morales Date: Wed, 30 Aug 2023 10:52:57 +0200 Subject: [PATCH 12/14] small fix --- .../Inc_Species_Transport_Composition_Dependent_Model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 index 0295da5e..90820c70 100644 --- 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 @@ -135,7 +135,7 @@ The Species transport is switched on by setting `KIND_SCALAR_MODEL= SPECIES_TRAN 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 in order 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/). +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. From 707310d0db80ca7f6f42a27866e4edbe3e1e211f Mon Sep 17 00:00:00 2001 From: Cristopher-Morales Date: Wed, 30 Aug 2023 13:35:14 +0200 Subject: [PATCH 13/14] adding incompressible V&V to the index --- _vandv/index.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/_vandv/index.md b/_vandv/index.md index 15ed7f9a..eba73388 100644 --- a/_vandv/index.md +++ b/_vandv/index.md @@ -31,3 +31,8 @@ Results for the 30p30n airfoil, mesh independence study at low angle-of-attack, Comparison of grid-converged results with experimental data. SA and SST turbulence models. * [2D Flat Plate (T3A & T3A-) for Langtry and Menter transition model](/vandv/LM_transition/) Comparison of grid-converged results with results of another solver and experimental data. + +#### Incompressible Flow + +* [2D Axisymmetric, Nonpremixed, Nonreacting, Variable Density, Turbulent Jet Flow](/vandv/SANDIA_jet/) +Comparison of grid-converged results with experimental data and other solvers for the Species Transport and Composition-Dependent model. From f16f12c9dd5bb32af16a37eb244909d38c8cd1b4 Mon Sep 17 00:00:00 2001 From: Nijso Date: Tue, 6 Feb 2024 23:38:43 +0100 Subject: [PATCH 14/14] Update Static_FSI.md small typo fix + info on deforming cantilever. --- _tutorials/multiphysics/steady_fsi/Static_FSI.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) 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: ![FSI Results1](../../tutorials_files/multiphysics/steady_fsi/images/fsi2.png) ![FSI Results2](../../tutorials_files/multiphysics/steady_fsi/images/fsi3.png) +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