diff --git a/Gemfile b/Gemfile new file mode 100644 index 00000000..e4bb3af0 --- /dev/null +++ b/Gemfile @@ -0,0 +1,5 @@ +source 'https://rubygems.org' +group :jekyll_plugins do + gem 'github-pages' + gem 'jekyll-twitter-plugin' +end diff --git a/SU2.bib b/SU2.bib index e8af641f..5c6dbf0b 100644 --- a/SU2.bib +++ b/SU2.bib @@ -1,4 +1,105 @@ +@inproceedings{mortazawy_mehdi_numerical_2018, + address = {Glasgow, UK}, + title = {Numerical {Investigation} of {Shock} {Wave} {Propagation} in {Ducts} with {Grooves}}, + url = {http://congress.cimne.com/eccm_ecfd2018/admin/files/fileabstract/a1413.pdf}, + abstract = {The pressure attenuation of moving shocks when they propagate in ducts is of great importance in a wide variety of applications, such as health, safety, and transportation. The objective of this research is to investigate the propagation of shock waves in ducts with roughness. The roughness is added in the form of grooves as in an existing experiment. Straight and branching ducts are considered in order to better understand the mechanisms causing attenuation of the shock and the physics behind the evolution of the complex wave patterns resulting from diffraction and reflection of the primary moving shock. A finite +volume numerical method is used and further validated for several test cases relevant to this study. The computed results are compared with experimental measurements in ducts with grooves. Good agreement between high resolution simulations and experiment is obtained for the shock speeds and complex wave patterns created by the grooves. Time histories of pressure at various locations, and shock strengths are presented and compared with measurements. Different groove geometries have been tested in the numerical simulation in + order to identify the shape that will better diminish shock strength. Animations of the computed results are shown to reveal salient features of the unsteady flowfield.}, + language = {English}, + booktitle = {Proceeding of 6th {European} {Conference} on {Computational} {Mechanics} ({ECCM} 6) and 7th {European} {Conference} on {Computational} {Fluid} {Dynamics} ({ECFD} 7)}, + author = {{Mortazawy Mehdi}}, + month = jun, + year = {2018}, + keywords = {Shock, Shock Wave} +} + +@inproceedings{mehdi_numerical_2019, + address = {San Diego}, + title = {A {Numerical} {Investigation} of {Shock} {Wave} {Propagation} in {Ducts} with {Grooves}}, + url = {https://doi.org/10.2514/6.2019-2152}, + doi = {10.2514/6.2019-2152}, + abstract = {Experimental investigations and numerical simulations of normal shock waves of different strengths propagating inside ducts with roughness are presented. The roughness is added in the form of grooves. Straight and branching ducts are considered in order to better explore the mechanisms causing attenuation of the shock and the physics behind the evolution of the complex wave patterns resulting from diffraction and reflection of the primary moving shock. A well-established finite volume numerical method is used and further validated for several test cases relevant to this study. The computed results are compared with experimental measurements in ducts with grooves. Good agreement between high resolution simulations and the experiment is obtained for the shock speeds and complex wave patterns created by the grooves. High frequency response time histories of pressure at various locations were recorded in the experiments. The recorded pressure histories and shock strengths were found in fair agreement with the two-dimensional simulation results as long as the shock stays in the duct. Overall, the physics of the interactions of the moving shock, the diffracted and reflected waves with the grooves are adequately captured in the high resolution simulations. Therefore, shocks propagating in ducts with different groove geometries have been simulated in order to identify the groove shape that diminishes shock strength.}, + language = {English}, + booktitle = {Proceedings of a meeting held 7-11 {January} 2019, {San} {Diego}, {California}, {USA}}, + publisher = {AIAA}, + author = {Mehdi, Mortazawy and Konstantinos, Kontis and John, Ekaterinaris}, + month = jan, + year = {2019}, + keywords = {Shock, Shock Attenuation, Shock Interaction, Shock Propagation, Shock Wave, Supersonic}, + pages = {22} +} + +@phdthesis{mortazawy_mehdi_numerical_2018-1, + address = {Daytona Beach, Florida}, + type = {Thesis}, + title = {Numerical {Simulation} of {Shock} {Wave} {Propagation} in {Ducts} with {Grooves}}, + copyright = {Public}, + shorttitle = {Numerical {Simulation} of {Shock} {Wave} {Propagation} in {Ducts} with {Grooves}}, + url = {https://commons.erau.edu/edt/389/}, + abstract = {The pressure attenuation of moving shocks when they propagate in ducts, is of great importance in a wide variety of applications, such as health, safety, and transportation. The objective of this research is to simulate the propagation of shock waves in ducts with roughness. The roughness is added in the form of grooves as in an existing experiment. Different shapes are considered in order to better understand the physics behind the evolution of the complex shock patterns resulting from diffraction, reflection and refraction of the primary moving shock. The contribution of grooves and duct shape on these phenomena and pressure attenuation is investigated. The numerical method is validated through several test cases, and the results are compared against the theory and the experimental measurements. Good agreement between high resolution computations and the experiment is obtained for the shock speeds and complex wave patterns created by the grooves. Time histories of pressure at various locations are also compared. It is found that accurate pressure history agreement requires a close representation of the full experimental setup to fully capture boundary layer development, and pressure losses associated with unsteady moving shocks in long ducts. Different groove geometries have been tested in the numerical computation in order to identify the shape that will diminish shock strength, hence pressure extrema more effectively. Analysis and animations of the computed results are employed to reveal salient features of the unsteady flowfield.}, + language = {English}, + school = {Embry-Riddle Aeronautical University}, + author = {{Mortazawy Mehdi}}, + month = may, + year = {2018}, + keywords = {Moving Shock, Schlieren, Shock Attenuation, Shock Propagation, Shock wave, Supersonic} +} +@article{Gutierrez2019, + author = {Gutierrez, David Rodriguez and Poggie, Jonathan}, + title = {Effects of Power Deposition on the Aerodynamic Forces on a Slender Body}, + journal = {AIAA Journal}, + volume = {56}, + number = {7}, + pages = {2911--2917}, + year = {2018}, + doi = {10.2514/1.J057004}, + url = {https://doi.org/10.2514/1.J057004}, +} + +@incollection{kumar2019combination, + title={Combination of Polynomial Chaos with Adjoint Formulations for Optimization Under Uncertainties}, + author={Kumar, Dinesh and Raisee, Mehrdad and Lacor, Chris}, + booktitle={Uncertainty Management for Robust Industrial Design in Aeronautics}, + pages={567--582}, + year={2019}, + publisher={Springer} +} + +@inproceedings{morelli2019simulation, + title={Simulation and Analysis of Oscillating Airfoil Ice Shapes via a Fully Unsteady Collection Efficiency Approach}, + author={Morelli, Myles and Zhou, Beckett Y and Guardone, Alberto and others}, + booktitle={75th International Annual Forum American Helicopter Society (AHS)}, + pages={1--12}, + year={2019} +} + +@article{razaaly2019impact, + title={Impact of geometric, operational, and model uncertainties on the non-ideal flow through a supersonic ORC turbine cascade}, + author={Razaaly, Nassim and Persico, Giacomo and Congedo, Pietro Marco}, + journal={Energy}, + volume={169}, + pages={213--227}, + year={2019}, + publisher={Elsevier} +} + +@incollection{kaynak2019transition, + title={Transition Modeling for Low to High Speed Boundary Layer Flows with CFD Applications}, + author={Kaynak, Unver and Bas, Onur and Cakmakcioglu, Samet Caka and Tuncer, Ismail Hakki}, + booktitle={Boundary Layer Flows-Theory, Applications and Numerical Methods}, + year={2019}, + publisher={IntechOpen} +} + +@inproceedings{sharma2019numerical, + title={Numerical investigation of noise generation by rod-airfoil configuration using DES (SU2) and the FW-H analogy}, + author={Sharma, Sparsh and Geyer, Thomas F and Sarradj, Ennes and Schmidt, Heiko}, + booktitle={25th AIAA/CEAS Aeroacoustics Conference}, + pages={2400}, + year={2019} +} + @inproceedings{albring_challenges_2019, title = {Challenges in {Sensitivity} {Computations} for ({D}) {DES} and {URANS}}, url = {https://arc.aiaa.org/doi/pdf/10.2514/6.2019-0169}, @@ -942,4 +1043,4 @@ @phdthesis{kline_continuous_2017 school = {Department of Aeronautics and Astronautics, Stanford University}, author = {Kline, H. L.}, year = {2017} -} \ No newline at end of file +} diff --git a/_config.yml b/_config.yml index f8ffca91..f09ad726 100644 --- a/_config.yml +++ b/_config.yml @@ -1,6 +1,6 @@ # Site settings -title: SU2, the Open-Source CFD Code -email: su2code.central@gmail.com +title: SU2 | Multiphysics Simulation and Design Software +email: info@su2foundation.org description: > Website for the SU2 Project @@ -22,6 +22,10 @@ gems: - jekyll-seo-tag - jekyll-sitemap +whitelist: + - jekyll-redirect-from + + exclude: - Gemfile - Gemfile.lock @@ -37,6 +41,15 @@ defaults: layout: post sectionid: blog +- scope: + path: _docs_v7 + type: docs_v7 + values: + layout: docs_v7 + sectionid: docs_v7 + seo: + type: "WebPage" + - scope: path: _docs type: docs @@ -55,16 +68,33 @@ defaults: seo: type: "WebPage" +- scope: + path: _vandv + type: vandv + values: + layout: vandv + sectionid: vandv + seo: + type: "WebPage" collections: docs: permalink: /:collection/:path/ output: true + docs_v7: + permalink: /:collection/:path/ + output: true tutorials: permalink: /:collection/:path/ output: true + vandv: + permalink: /:collection/:path/ + output: true posts: permalink: /blog/:year/:month/:day/:title/ output: true # Google Analytics google_analytics: UA-28187985-1 + +plugins: + - jekyll-gist diff --git a/_data/docs_v7.yml b/_data/docs_v7.yml new file mode 100644 index 00000000..4c50ae29 --- /dev/null +++ b/_data/docs_v7.yml @@ -0,0 +1,52 @@ +- title: Introduction to SU2 + docs_v7: + - home + - contribute + +- title: New in Version 7 + docs_v7: + - Guide-to-v7 + +- title: Quick Start + docs_v7: + - Quick-Start + +- title: Installation + docs_v7: + - Download + - Installation + - Build-SU2-From-Source + - Test-Cases + +- title: Users Guide + docs_v7: + - Configuration-File + - Mesh-File + - Restart-File + - Theory + - Solver-Setup + - Physical-Definition + - Markers-and-BC + - Convective-Schemes + - Custom-Output + - Linear-Solvers-and-Preconditioners + - Multizone + - Execution + +- title: Developer Docs + docs_v7: + - Gitting-Started + - Developing-SU2-on-GitHub-(Internal-Developers) + - Running-Regression-Tests + - Code-Review + - Code-Structure + - Style-Guide + - Advanced-AD-Techniques + +- title: FAQ + docs_v7: + - FAQ + +- title: Contact + docs_v7: + - Contact diff --git a/_data/vandv.yml b/_data/vandv.yml new file mode 100644 index 00000000..de4b668c --- /dev/null +++ b/_data/vandv.yml @@ -0,0 +1,10 @@ +- title: The SU2 V&V Collection + vandv: + - home + - Contribute + +- title: Compressible Flow + vandv: + - MMS_FVM_Navier_Stokes + - Flat_Plate + - Bump_Channel diff --git a/_docs/Code-Review.md b/_docs/Code-Review.md index ceffba73..819c64a7 100644 --- a/_docs/Code-Review.md +++ b/_docs/Code-Review.md @@ -12,19 +12,19 @@ The goal of code review is to maintain correct code in a consistent style. Human All developers and users (internal and external) are encouraged to participate in the code review process. The SU2 suite is a computational environment we are all working to maintain. When performing a code review, you should be asking yourself "Is this code that I want in our environment". A single developer may have written the bulk of the pull request, but once a change has been incorporated the whole community is in charge of future changes (maintenance, debugging, etc.). Questions you should ask yourself are 1. Is this a desirable change to the code base? -- Does it make code more legible? +- Does it make the code more legible? - Add new features? - Fix a bug? 2. Is the change implemented in the correct way? - Does it interact minimally with the rest of the code? - Does it have the correct algorithmic complexity? -- Is it located in the place? (file, etc.) +- Is it located in the right place? (file, etc.) 3. Is the code legible? - Is the code mostly legible on its own without documentation? - Are the variable names concise and accurate? -- Is there documentation where necessary, and it is correct? +- Is there documentation where necessary, and is it correct? 4. Does the code follow established conventions? - Does it match the SU2 code style? diff --git a/_docs/Contact.md b/_docs/Contact.md index cade3b85..9a09f691 100644 --- a/_docs/Contact.md +++ b/_docs/Contact.md @@ -10,10 +10,10 @@ Users of SU2 who have questions not addressed in the User's Guide, Developer's G If you find bugs or issues in the source code or would like to submit a feature request, please use the issue tracker on the SU2 GitHub page at: [https://github.com/su2code/SU2/issues](https://github.com/su2code/SU2/issues) ### SU2 User's Mailing List -Users are encouraged to join the SU2 user's email list. This list will be used to communicate important information to users such as new releases or event announcements. To join, follow the link below, enter your email address, and follow the directions for confirmation. Your email address will not be shared or used for anything except email communication from the development team. +Users are encouraged to join the SU2 user's email list. This list will be used to communicate important information to users such as new releases or event announcements. To join, follow the link below. We take privacy matters seriously - please see our privacy and cookie policies for more information. -[Join the List!](http://su2devsociety.org/su2-user-registration/) +[Join the List!](https://su2foundation.org/) -### Join the SU2 Developer Team +### Join the SU2 Development Team All developers that would like to contribute to SU2 are encouraged to get involved on [GitHub](https://github.com/su2code/SU2). Whether you would like to share new features or fixes with the community through Pull Requests, report issues or feature requests, or discuss the latest with your fellow developers, your participation is most welcome! diff --git a/_docs/Cygwin-Build-for-Windows.md b/_docs/Cygwin-Build-for-Windows.md index 35b24134..b2db2228 100644 --- a/_docs/Cygwin-Build-for-Windows.md +++ b/_docs/Cygwin-Build-for-Windows.md @@ -24,7 +24,7 @@ At the package selection step, search for the following terms and select the ass * python: install the packages under the python sub-heading * cpp: all debug, pre-processor, regular expression packages. -#### Example SU2 installation on WINDOWS 10 using 64-bit Cygwin +### Example SU2 installation on WINDOWS 10 using 64-bit Cygwin The CYGWIN `bash` shell is used for all steps on the command line. It is automatically available after the first installation step (typically to be launched via the CYGWIN desktop icon). @@ -132,6 +132,13 @@ The CYGWIN `bash` shell is used for all steps on the command line. It is automat ./bootstrap ``` +1. Set compiler flags (just to be sure not to use the debug option -g) + + ```bash + export CFLAGS='-O2' + export CXXFLAGS='-O2' + ``` + 1. Create Makefiles: > NOTE: didn't yet get `tecio` working, therefore disabled with `--disable-tecio`
@@ -153,6 +160,18 @@ The CYGWIN `bash` shell is used for all steps on the command line. It is automat make install ``` +1. Reduce size of executables significantly (strip symbols, see also [CYGWIN FAQ 6.3](https://www.cygwin.com/faq.html). The SU2_CFD.exe is reduced from approx. 600MB to 15MB. Can be omitted if compiled with the -s option to gcc. + > NOTE: This should **NOT** be necessary if compiler flags are set as shown in step 7 + ```bash + make install-strip + ``` + +1. Cleanup the installation. This removes also the intermediate big executables from the build folders. + + ```bash + make clean + ``` + 1. Add the `$SU2_HOME` and `$SU2_RUN` environment variables to `~/.bashrc` (and `source ~/.bashrc`) ```bash diff --git a/_docs/Download.md b/_docs/Download.md index 2e8a3495..ed1f8561 100644 --- a/_docs/Download.md +++ b/_docs/Download.md @@ -5,5 +5,5 @@ permalink: /docs/Download/ SU2 is freely available for use under the GNU Lesser General Public License, version 2.1. Please reference the [license details](https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html) for terms and conditions. -Please visit our [download portal](../../download.html) to obtain binary executables or the SU2 source code and [register as a user of SU2](http://su2devsociety.org/su2-user-registration/)! +Please visit our [download portal](../../download.html) to obtain binary executables or the SU2 source code and [register as a user of SU2](https://su2foundation.org/)! diff --git a/_docs/Gitting-Started.md b/_docs/Gitting-Started.md index bec9afb6..019b366c 100644 --- a/_docs/Gitting-Started.md +++ b/_docs/Gitting-Started.md @@ -9,8 +9,8 @@ As you now know, GitHub is the center of all development efforts in SU2. The su We follow [a popular git branching strategy](http://nvie.com/posts/a-successful-git-branching-model/) in order to leverage decentralized development. This list describes the types of branches on the SU2 repository. You'll want to pick the right one to work with, in order keep the merging process simple. -- master -- stable, latest release and fixes -- develop -- current development, generally the branch for you to fork or start a new branch from +- master -- stable, latest release and fixes +- develop -- current development, generally the branch for you to fork or start a new branch from - feature_* -- feature specific branches - fix_* -- branches that fix a particular bug or capability (not new features) diff --git a/_docs/index.md b/_docs/index.md index af26f4d1..646d95bc 100644 --- a/_docs/index.md +++ b/_docs/index.md @@ -1,5 +1,5 @@ --- -title: SU2, the Open-Source CFD Code +title: SU2, Multiphysics Simulation and Design Software permalink: /docs/home/ redirect_from: /docs/index.html --- diff --git a/_docs_v7/Advanced-AD-Techniques.md b/_docs_v7/Advanced-AD-Techniques.md new file mode 100644 index 00000000..e79f30a7 --- /dev/null +++ b/_docs_v7/Advanced-AD-Techniques.md @@ -0,0 +1,93 @@ +--- +title: Advanced AD Techniques +permalink: /docs_v7/Advanced-AD-Techniques/ +--- + +[Algorithmic Differentiation](https://en.wikipedia.org/wiki/Automatic_differentiation) (AD) is a frequently used method to calculate +the derivative of a function by means of the transformation of the underlying program which calculates the +numerical values of this function. As distinguished from symbolic differentiation an explicit expression for the +derivative is never formed. An advantage over FD is that no truncation errors are present, thus the numerical +value can be determined up to machine accuracy. + +Consider a function `y = f(x)`, using the reverse mode of AD we get + +`xb = (df/dx)^T yb` + +with an arbitrary seed vector `yb`. + + +### Expression Templates + +In SU2 we use the AD tool [CoDi](https://github.com/SciCompKL/CoDiPack) to enable the computation of arbitrary derivatives. It is based on the [Expression Template](https://en.wikipedia.org/wiki/Expression_templates) approach. Here the overloaded operators no longer return the (computationally expensive) result of an expression, +but a small temporary object that acts as a placeholder for this particular expression. Using this objects +we can build an internal representation of each expression to directly compute and store its partial derivatives during the evaluation of the program. This information is then used to correctly accumulate the gradients (or rather `xb`) in a second reverse sweep. + +The picture below shows the computational graph for the expression `φ=cos(v1)v2` and the compile-time representation as object with `su2double` being the general datatype used throughout SU2. +![Expression Templates](http://www.scicomp.uni-kl.de/wordpress/wp-content/uploads/2016/05/Screenshot-from-2016-05-20-15-49-59.png) + +This object can be traversed to compute and store the partial derivatives `∂φ/∂v1=cos(v1)` and `∂φ/∂v2=-sin(v1)v2` based on the derivatives of each involved unary or binary operation. If recording is enabled the traversal of the computational graph of each +expression is started as soon as it occurs on the right-hand side in a statement. Note that the partial derivatives are only stored if the corresponding argument has some dependency on the input variables set by the user. This kind of dependency or +activity tracking is relatively easy to accomplish since every variable stores an index along with its value. A +zero index represents passive variables while a non-zero index identifies active variables. This index will be +non-zero only if the corresponding variable has been assigned an expression with at least one active variable +as an argument. + +### AD Tool Wrapper + +The CoDi library provides a special datatype and is automatically included +during the compilation if AD support is requested by the user (see [[AD Build]]) . For developers of SU2 there is no need to deal +with this library explicitly which is why there are simple wrapper routines for the most important features +available. These are for example the following: + +* `AD::RegisterInput(su2double &var)`: Registers the variable as input, i.e. sets the index to a +non-zero value. The exact value is determined by the AD tool. +* `AD::StartRecording()`: Starts the recording by enabling the traversal of the computational graphs +of each subsequent expression to store the partial derivatives. +* `AD::StopRecording()`: Stops the recording of information. +* `AD::ComputeAdjoint()`: Interprets the stored information to compute the gradient. +* `AD::Reset()`: Deletes all stored information, i.e. the adjoint values and the partial derivatives to +enable a new recording. +* `AD::ClearAdjoints()`: Sets the adjoint values to zero but keeps the derivative information, thereby +enabling a new interpretation with a different seed vector `yb`. + +Since the actual interpretation of the adjoints is done by the AD tool, we need some functions to set and +extract the derivative information. To account for other datatypes (like for example types that implement +the forward mode of AD or types for the complex step method) these functions are enclosed in the namespace +`SU2_TYPE`: +* `SU2_TYPE::SetDerivative(su2double &var, double &val)`: Sets the adjoint value of a variable +before calling `AD::ComputeAdjoint()`. +* `SU2_TYPE::GetDerivative(su2double &var)`: Returns the interpreted adjoint value of a variable +registered as input. Note: at the moment this function must be called in the same order as `AD::RegisterInput(su2double &var)`. + +### Local Preaccumulation + +To alleviate the high memory requirements we apply the so called local preaccumulation method. Here we +compute and store the local Jacobi matrices of certain enclosed code parts instead of storing each individual +statement contribution. To illustrate the method consider the code shown in the listing below which computes the +volume of 2D elements of the mesh. Without using preaccumulation and if we assume that nDim equals 2 we +have to store 12 partial derivative values for the 3 statements (2 ∗ 2 in line 7, 2 ∗ 2 in line 8 and 4 in line 11). + +``` + AD::StartPreacc(); + AD::SetPreaccIn(val_coord_Edge_CG, nDim); + AD::SetPreaccIn(val_coord_Elem_CG, nDim); + AD::SetPreaccIn(val_coord_Point, nDim); + + for (iDim = 0; iDim < nDim; iDim++) { + vec_a[iDim] = val_coord_Elem_CG[iDim]-val_coord_Point[iDim]; + vec_b[iDim] = val_coord_Edge_CG[iDim]-val_coord_Point[iDim]; + } + + Local_Volume = 0.5*fabs(vec_a[0]*vec_b[1]-vec_a[1]*vec_b[0]); + + AD::SetPreaccOut(Local_Volume); + AD::EndPreacc(); + + return Local_Volume; +``` + +With preaccumulation we only store the derivatives of the variables flagged using `AD::SetPreaccIn` with +respect to the variables flagged with `AD::SetPreaccOut`. For our example this results in 6 values, which +means total saving of memory of 50%. Note that this exemplary code snippet is executed for every element +in the mesh. Throughout the code this method is applied at several spots where a clear identification of +inputs and outputs was possible. diff --git a/_docs_v7/Build-SU2-From-Source.md b/_docs_v7/Build-SU2-From-Source.md new file mode 100644 index 00000000..b5b3b16f --- /dev/null +++ b/_docs_v7/Build-SU2-From-Source.md @@ -0,0 +1,187 @@ +--- +title: Build SU2 From Source +permalink: /docs_v7/Build-SU2-From-Source/ +redirect_from: /docs/Build-SU2-From-Source/ +--- + +***This guide is for version 7 only.*** +For information on how to build older versions of SU2, have a look [here](/docs_v7/Build-from-Source/). + +Note that the following guide works only on Linux/MacOS and on Windows using Cygwin or the [Linux Subsystem](https://docs.microsoft.com/en-us/windows/wsl/install-win10). + +--- + +## Content ## +- [Quick Compilation Guide](#quick-compilation-guide) +- [Requirements](#requirements) + - [Compilers](#compilers) + - [Python](#python) + - [Optional: swig and mpi4py](#optional-swig-and-mpi4py) +- [Automatically Installed Dependencies](#automatically-installed-dependencies) + - [Meson and Ninja](#meson-and-ninja) + - [CoDiPack and MeDiPack](#codipack-and-medipack) +- [Configuration and Compilation](#configuration-and-compilation) + - [Basic Configuration](#basic-configuration) + - [Advanced Configuration](#advanced-configuration) + - [Compilation](#compilation) +- [Troubleshooting](#troubleshooting) + +--- + +## Quick Compilation Guide ## + +This is a quick guide to compile and install a *basic version* of SU2. For more information on the requirements and a more detailed description of the build system **continue reading** the rest of this page. + +Short summary of the minimal requirements: + +- C/C++ compiler +- Python 3 + +**Note:** all other necessary build tools and dependencies are shipped with the source code or are downloaded automatically. + +If you have these tools installed, you can create a configuration using the `meson.py` found in the root source code folder: +``` +./meson.py build +``` +Use `ninja` to compile and install the code + +``` +./ninja -C build install +``` +--- + + +## Requirements ## + +### Compilers ### +Installing SU2 from source requires a C++ compiler. The GNU compilers (gcc/g++) are open-source, widely used, and reliable for building SU2. The Intel compiler set has been optimized to run on Intel hardware and has also been used successfully by the development team to build the source code, though it is commercially licensed. The Apple LLVM compiler (Clang) is also commonly used by the developers. + +- GNU gcc / g++ +- Intel icc / icpc +- Apple LLVM (clang) + +**Note**: SU2 uses some C++11 features, that means at least GCC >= v4.7, Clang >= v3.0 or Intel C++ >= v12.0 is necessary. + +### MPI ### +In order to build SU2 with parallel support, you need a suitable MPI installation on your machine. During the configuration the build tool does a check and enables MPI support. If no installation is found, a serial version of SU2 will be compiled. + +### Python ### + +SU2 requires Python 3 for compilation and for running the python scripts. Make sure that you have properly set up the `python3` executables in your environment. + +### Optional: swig and mpi4py ### +If you want to use the python wrapper capabilities, also `swig` and `mpi4py` are required. On **Linux** `swig` should be available in the package manager of your distribution and `mpi4py` can be installed using [pip](https://pip.pypa.io/en/stable/). + +On **Mac OS X**, you can use the [Homebrew](http://brew.sh/) package manager. Once it is installed on your system, you can install Swig by running: + + $ sudo brew install swig + +Install mpi4py with Python pip using easy install: + + $ sudo easy_install pip + $ sudo pip install mpi4py + +--- + +## Automatically installed dependencies ## + +The following dependencies are automatically downloaded (or initialized if source code was cloned using `git`) during the [configuration](#configuration-and-compilation). + +### Meson and Ninja ### +The build system of SU2 is based on a combination of [meson](http://mesonbuild.com/) (as the front-end) and [ninja](https://ninja-build.org/) (as the back-end). Meson is an open source build system meant to be both extremely fast, and, even more importantly, as user friendly as possible. Ninja is a small low-level build system with a focus on speed. + +### CoDiPack and MeDiPack ### +In order to use the discrete adjoint solver the compilation requires two additional (header-only) libraries. [CoDi](https://github.com/SciCompKL/CoDiPack) provides the AD datatype and [MeDi](https://github.com/SciCompKL/MeDiPack) provides the infrastructure for the MPI communication when the reverse mode of AD is used. + +--- +## Configuration and Compilation ## + +Like mentioned above, SU2 uses meson and ninja for configuration and compilation, respectively. A configuration using meson is generated first and then an invocation of ninja is used to compile SU2 with this configuration. + +### Basic Configuration ### +In the root folder of the sources you will find a python script called `meson.py`. This script generates a configuration. It will also check whether all dependencies are found and downloads some of them if necessary see [previous section](#automatically-installed-dependencies). + +**Note**: For the following steps you can also use preinstalled versions of `meson` and `ninja` available on your machine. Just replace the `./meson.py` and `./ninja` calls with the binaries of the respective installations. However, this way you have to manually make sure that the correct versions of [CoDiPack and MeDiPack](#codipack-and-medipack) are placed in the `externals/` folders. + +The only required argument for `meson.py` is a name of a directory where it should store the configuration. You can have multiple configurations in different folders next to each other. To generate a basic configuration that will be stored in the folder `build` use + +``` + ./meson.py build +``` + +Options can be passed to the script to enable or disable different features of SU2. Below you find a list of project options and their default values: + +| Option | Default value | Description | +|---| --- | --- | +| `-Denable-autodiff` | `false` | enable AD (reverse) support (needed for discrete adjoint solver) | +| `-Denable-directdiff` | `false` | enable AD (forward) support | +| `-Denable-pywrapper` | `false` | enable Python wrapper support| +| `-Dwith-mpi` | `auto` | Set dependency mode for MPI (`auto`,`required`,`disabled`) | +| `-Denable-cgns` | `true` | enable CGNS support | +| `-Denable-tecio` | `true` | enable TECIO support | +| `-Denable-mkl` | `false` | enable Intel MKL support | +| `-Denable-openblas` | `false` | enable OpenBLAS support | +| `-Denable-pastix` | `false` | enable PaStiX support | + +For example to enable AD support pass the option to the `meson.py` script along with a value: +``` +./meson.py build -Denable-autodiff=true +``` +To set a installation directory for the binaries and python scripts, use the `--prefix` option, e.g.: + +``` +./meson.py build -Denable-autodiff=true --prefix=/home/username/SU2 +``` +If you are not interested in setting custom compiler flags and other options you can now go directly to the [Compilation](#compilation) section, otherwise continue reading the next section. + +### Advanced Configuration ### +In general meson appends flags set with the environment variable `CXX_FLAGS`. It is however recommended to use +mesons built-in options to set debug mode, warning levels and optimizations. All options can be found [here](https://mesonbuild.com/Builtin-options.html) or by using `./meson.py configure`. An already created configuration can be modified by using the `--reconfigure` flag, e.g.: +``` +./meson.py build --reconfigure --buildtype=debug +``` +Note that it is only possible to change one option at once. + +#### Build Type #### + +The debug mode can be enabled by using the `--buildtype=debug` option. This adds `-g` flag and disables all compiler optimizations. If you still want to have optimizations, use `--buildtype=debugoptimized`. The default build type is `release`. + +#### Compiler optimizations #### + +The optimization level can be set with `--optimization=level`, where `level` corresponds to a number between 0 (no optimization) and 3 (highest level of optimizations). The default level is 3. + +#### Warning level #### + +The warning level can be set with `--warnlevel=level`, where `level` corresponds to a number between 0 (no warnings) and 3 (highest level of warning output). Level 1 corresponds to `-Wall`, level 2 to `-Wall -Wextra` and level 3 to `-Wall -Wextra -Wpedantic`. The default level is 0. + +**Note:** The warning flags `-Wno-unused-parameter`, `-Wno-empty-body` and `-Wno-format-security` are always added by default. + +#### Linear algebra options #### + +Compiling with support for a BLAS library (`-Denable-mkl` or `-Denable-openblas`) is highly recommended if you use the high order finite element solver, or radial basis function interpolation in fluid structure interaction problems. +`-Denable-mkl` takes precedence over `-Denable-openblas`, by default the build system looks for MKL in `/opt/intel/mkl`, this can be changed via option `-Dmkl_root`. +When OpenBLAS support is requested the build system uses [pkg-config](https://en.wikipedia.org/wiki/Pkg-config) to search the system for package `openblas`, option `-Dblas-name`, if the library was built from source it may be necessary to set the environment variable PKG_CONFIG_PATH. + +For large structural FEA problems on highly anisotropic grids iterative linear solvers might fail. Version 7 introduces experimental support for the direct sparse solver [PaStiX](https://gforge.inria.fr/projects/pastix/) (`-Denable-pastix`) see detailed instructions in `TestCases/pastix_support/readme.txt`. + +**Note:** The BLAS library needs to provide support for LAPACK functions. + +### Compilation ### + +Finally to compile and install SU2 use +``` +./ninja -C build install +``` +where `build` is again a folder with a configuration created using a call to `meson.py` described in the previous section. By default ninja uses all available cores in your system for the compilation. You can set the number of cores manually by using the `-jN` flag, where `N` is the number of cores you want to use. + +--- + +## Troubleshooting ## + +### MPI installation is not found ### +Meson looks for an MPI installation using [pkg-config](https://en.wikipedia.org/wiki/Pkg-config). But if your MPI implementation does not provide them, it will search for the standard wrapper executables, `mpic`, `mpicxx`, `mpic++`. If these are not in your path, they can be specified by setting the standard environment variables `MPICC`, `MPICXX` during configuration. + +### mpi4py library is not found ### +The build system uses [`get_python_lib()`](https://docs.python.org/3/distutils/apiref.html#distutils.sysconfig.get_python_lib) to look for the library installation path. If `mpi4py` is not installed in that path, you can provide a custom library path with `--python_path=`. + + diff --git a/_docs_v7/Build-SU2-Windows.md b/_docs_v7/Build-SU2-Windows.md new file mode 100644 index 00000000..3ffb1254 --- /dev/null +++ b/_docs_v7/Build-SU2-Windows.md @@ -0,0 +1,50 @@ +--- +title: Build SU2 on Windows +permalink: /docs_v7/Build-SU2-Windows/ +--- + +***This guide is for version 7 only.*** +This document will guide you through the steps to compile SU2 on Windows using the [Minimalist GNU for Windows +](http://www.mingw.org/) development environment (MinGW) and [Microsoft MPI](https://docs.microsoft.com/en-us/message-passing-interface/microsoft-mpi). + +Note that there are multiple other ways of compiling SU2 on Windows (for example using Cygwin, Visual Studio, the Linux Subsystem) and all of them should(!) work one way or the other, +however, we can only document (and support) a limited number of possibilities. + +--- + +- [Requirements](#requirements) +- [Installation of Dependencies](#installation-of-dependencies) +- [Configuration and Compilation](#configuration-and-compilation) +- [Running the executables](#running-the-executables) + +--- + +## Requirements + +- Windows 10* +- Python 3.7 (download [here](https://www.python.org/downloads/windows/) or from the Microsoft Store) +- MinGW-w64 version 8.1.0* (download [here](https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe/download)) +- Microsoft MPI v10.1.2* (download [here](https://www.microsoft.com/en-us/download/details.aspx?id=100593), you need the `msmpisetup.exe` and the `msmpisdk.msi`) +- SU2 v7.x.x (download [here](https://su2code.github.io/download) or clone using git) + +*Other version might work, but this has not been verified yet. + + +## Installation of Dependencies + +- Install Microsoft MPI by simply executing the installers `msmpisetup.exe` and the `msmpisdk.msi`. + +- Install MinGW by executing the installer `mingw-w64-install.exe`. Choose Version `8.1.0` and Architecture `x86_64` on the Settings page. +Everything else can stay on their default values. On the next page set a destination folder and remember it! Click next until everything has been downloaded and installed. + +## Configuration and Compilation + +In the file browser go to the mingw installation directory and execute the file `mingw-w64`. This should open the command prompt. Navigate to the SU2 source code directory (in the command prompt you can change directories using `cd` and list directories using `dir`). +Now you can follow the steps in the [Linux/MacOS Configuration and Compilation section](/docs_v7/Build-SU2-From-Source/#configuration-and-compilation). But make sure to use `python meson.py` and `ninja.exe` instead of `./meson.py` and `./ninja`, respectively. + + + + +## Running the executables +Add SU2 to the system path. This will allow you to use the executables from any directory without explicitly specifying the path to the executable. To do that access the system variables by typing “environ” in the search/run box of the start menu, select “edit the system environment variables”, and then select “Environment Variables” from the System Properties menu. Edit the “Path” system variable (or select “New” if no “Path” system variable exists) and add the path to the SU2 executables, i.e. the path that you have set with the `--prefix` option (if option was not given, the default is `C:\bin`). When there is more than one directory listed in “Path” they must be separated by semicolons. +Running SU2 in Windows is identical to running in [Linux or Mac OS environments](/_docs_v7/Execution.md) and is run from the command line (whether cmd.exe or the freely-available Console2 for Windows). However, you may have to use `mpiexec` instead of `mpirun` to execute the code in parallel. diff --git a/_docs_v7/Code-Review.md b/_docs_v7/Code-Review.md new file mode 100644 index 00000000..56f760bf --- /dev/null +++ b/_docs_v7/Code-Review.md @@ -0,0 +1,45 @@ +--- +title: Code Review +permalink: /docs_v7/Code-Review/ +--- + +Code review is a process where changes to the SU2 repository are examined by other developers before being merged into the development branch + +# Purpose +The goal of code review is to maintain correct code in a consistent style. Humans make mistakes, and code review is in place to catch mistakes before they become part of the main code suite. Good code is not just correct, but is also legible, and what is clear to the code author may not be clear to a reader of the code. Code review ensures that the code is understandable by at least two developers + +# Philosophy +All developers and users (internal and external) are encouraged to participate in the code review process. The SU2 suite is a computational environment we are all working to maintain. When performing a code review, you should be asking yourself "Is this code that I want in our environment". A single developer may have written the bulk of the pull request, but once a change has been incorporated the whole community is in charge of future changes (maintenance, debugging, etc.). Questions you should ask yourself are + +1. Is this a desirable change to the code base? +- Does it make code more legible? +- Add new features? +- Fix a bug? + +2. Is the change implemented in the correct way? +- Does it interact minimally with the rest of the code? +- Does it have the correct algorithmic complexity? +- Is it located in the place? (file, etc.) + +3. Is the code legible? +- Is the code mostly legible on its own without documentation? +- Are the variable names concise and accurate? +- Is there documentation where necessary, and it is correct? + +4. Does the code follow established conventions? +- Does it match the SU2 code style? +- Do the variable names follow the same patterns as in other parts of the code? + +# Good code changes +The above list is a long list of questions. A large change to the code will be much harder to review than a small change. As such, good pull requests will contain a minimal set of changes to be useful. Pull requests should "do one thing". In some cases, "doing one thing" may be a large change to the code, such as adding a new flow solver. In most cases, changes can be done in small increments that can each individually be reviewed and evaluated. Pull requests should not be of the form "Add a new config option and fix a bug in interation_structure.cpp". These should be two separate pull requests. + +# The Code Review Process +Github provides an easy interface for performing code reviews as part of every Pull Request. After a Pull Request is submitted to the SU2 'develop' branch, two different developers must review and approve the code changes before the request can be merged, in addition to passing the Travis CI regression test suite. Reviewers have the opportunity to comment on the changes and requests specific changes. + +In response to these comments, the pull requester should make changes to the code (or engage in dialogue on disagreements). Traditionally this is done with the characters "PTAL", which stand for "Please take a(nother) look". + +When a reviewer is happy with the proposed changes to the code, the reviewer should approve and can say "LGTM", standing for "looks good to me". In general, the changes to the code should be finalized before a LGTM is given, though if there are only very minor outstanding issues an LGTM can be given along with the changes. For example, if the only outstanding issue with the PR is that a word has been misspelled, a reviewer may make an inline comment about the misspelling, and in the main dialogue say "LGTM with the comment fix". + +All developers are encouraged to participate in the code review process, as the code is for everyone. However, there will typically be a specific set of developers who are experts in the section of code that is being modified. Generally, an LGTM should be gotten from at least one of these developers before merging. Users can be requested using "@username", for example, "PTAL @su2luvr". This sends that user an email about the pull request. Similarly, this can be used to request the opinions of other developers. While this can feel burdensome, it is in place to maintain good, correct code. Please use good judgement -- if the change is a spelling fix in a comment, it is not necessary to solicit the opinion of the entire development team. + +Once the proper set of "LGTM"s has been received, the change can be merged. If the pull-requester has commit access, it is tradition to let them make the merge. If the requester does not, then the main/final reviewer can submit the merge. If the pull-request came from an internal branch, the branch should be deleted on conclusion if it is no longer useful. diff --git a/_docs_v7/Code-Structure.md b/_docs_v7/Code-Structure.md new file mode 100644 index 00000000..4a00cbf4 --- /dev/null +++ b/_docs_v7/Code-Structure.md @@ -0,0 +1,56 @@ +--- +title: Code Structure +permalink: /docs_v7/Code-Structure/ +--- + +Full details on the class hierarchy and internal structure of the code can be found in the Doxygen documentation for SU2. A brief description for the major C++ classes is given on this page. + +The objective of this section is to introduce the C++ class structure of SU2 at a high level. The class descriptions below focus on the structure within SU2_CFD (the main component of SU2), but many of the classes are also used in the other modules. Maximizing the flexibility of the code was a fundamental driver for the design of the class architecture, and an overview of the collaboration diagram of all classes within SU2_CFD is shown below. + +![Class Structure General](../../docs_files/class_c_driver__coll__graph.png) + +At the highest level, SU2_CFD has a driver class, **CDriver**, that controls the solution of a multiphysics simulation. The **CDriver** class is responsible for instantiating all of the geometry, physics packages, and numerical methods needed to solve a particular problem. The **CDriver** class within SU2_CFD instantiates many classes, including the following: +- **CConfig** - Reads and stores the problem configuration, including all options and settings from the input file (extension .cfg). +- **COutput** - Writes the output of the simulation in a user-specified format (Paraview, Tecplot, CGNS, comma-separated values, etc.). +- **CIntegration** - Solves the particular governing equations by calling the child classes CMultiGridIntegration, CSingleGridIntegration. This is used for both multigrid or single-grid calculations, and it connects the subclasses CGeometry, CSolver, and CNumerics for performing integration in time and space. +- **CIteration** - Classes that complete an iteration of a single physics package, e.g., fluid or structure. + +The core capabilities of the computational tool are embedded within the CGeometry, CSolver, and CNumerics classes that manage the geometry, the main solver functionality (definition of the terms in the PDE), and the numerical methods, respectively. In the next subsection, these three classes will be discussed. + +## CGeometry Class + +This class reads and processes the input mesh file (extension .su2), and it includes several child classes, such as: +CPhysicalGeometry - Constructs the dual mesh structure from the primal mesh. Note that the FVM formulation in SU2 is based on the dual mesh with edge-based data structures. + +- **CMultiGridGeometry** - If multigrid is requested, this class automatically creates consecutively coarser meshes from the original input mesh using a control volume agglomeration procedure. These coarse grid levels are then used for multigrid calculations. +- **CPrimalGrid** and **CDualGrid** - Two classes (see Fig. below) that are used for defining the geometrical characteristics of the primal and dual grids. + +![Class Structure Geometry](../../docs_files/Class_Structure_Geometry.png) + +## CSolver Class + +In this class, the solution procedure is defined. Each child class of CSolver represents a solver for a particular set of governing equations. These solver classes contain subroutines with instructions for computing each spatial term of the PDE, e.g., loops over the mesh edges to compute convective and viscous fluxes, loops over the mesh nodes to compute source terms, and routines for imposing various boundary condition types for the PDE. + +One or more of these child classes will be instantiated depending on the desired physics, and several examples are: +- **CEulerSolver** - For the Euler equations (compressible or incompressible). +- **CTurbSolver** - For a turbulence model. +- **CAdjEulerSolver** - For the adjoint equations of the Euler equations. + +The solver containers also lead to one of the defining features of SU2: the ability to easily construct multi-physics problems by combining multiple solvers representing different physics. For example, the mean flow equations are easily coupled to the S-A turbulence model by instantiating both the CNSSolver class and the CTurbSASolver class. These two solver containers will control the solution of the different PDEs while being integrated simultaneously, and the information they contain can be freely passed back and forth. Another example of this flexibility arises when solving the adjoint equations. For instance, when solving the adjoint Euler equations, both the CAdjEulerSolver and the CEulerSolver classes are instantiated, as the adjoint equations require a copy of the flow solution that will be read from a solution file and stored by the CEulerSolver class. + +![Class Structure Sol](../../docs_files/class_c_solver__inherit__graph.png) + +The solver classes call the CVariable class for storing unknowns and other variables pertinent to the PDE at each mesh node, several classes in CNumerics in order to specify a spatial discretization of the governing equations (to be discussed below), and, if necessary, container classes for holding the matrices and vectors needed by linear solvers. A detailed list of all child classes found within CSolver is given in the Fig. below, but in general, these classes can be briefly described as follows: +- **CVariable** - Used to store variables at every point in the grid, such as the conservative variables (unknowns of the PDE). Depending on the system of equations being solved, CVariable instantiates a certain child class and stores a set of variables particular to that problem at each grid node. For example, the CNSVariable child class stores the variables for the Navier-Stokes equations, which will include viscosity, while the CEulerVariable child class does not need to store viscosity. A detailed list of all these child classes is given in the Fig. below. +- **CSysMatrix** - Stores values for the Jacobians of fluxes and source terms in a sparse matrix structure for implicit calculations. It includes various methods for solving a linear system, including Krylov methods such as GMRES and BiCGSTAB, in addition to several preconditioning techniques, such as Jacobi, LU-SGS, or line implicit preconditioning. +- **CSysVector** - Holds and manipulates vectors needed by the linear solvers in combination with CSysMatrix to store the sparse matrix representation of the Jacobian. + +![Class Structure Var](../../docs_files/class_c_variable__inherit__graph.png) + +## CNumerics Class + +This class discretizes each system of governing equations using the numerical schemes specified in the input file. There are several child classes that provide a wide range of discretization techniques for convective fluxes, viscous fluxes, and any source terms that might be present in a given PDE. For example, if one is interested in solving the Navier-Stokes equations expressed in a non-inertial frame, CNumerics would call one child class corresponding to the convective scheme, one corresponding to the viscous terms, and a third for the discretization of the momentum source term that arises from the transformation of the equations to a rotating reference frame. + +As another example, during a single iteration of an implicit calculation, methods in the CNumerics classes would compute the flux contributions and Jacobians at each node (using the variables stored in the CVariable class). These flux and Jacobian values are transferred back to the CSolver class, and the CSolver class calls routines within CSysMatrix in order to solve the resulting linear system of equations for the solution update. The Fig. below shows a list of the various capabilities in the CNumerics class. + +![Class Structure Numerics](../../docs_files/Class_Structure_Numerics.png) diff --git a/_docs_v7/Configuration-File.md b/_docs_v7/Configuration-File.md new file mode 100644 index 00000000..2bb841a0 --- /dev/null +++ b/_docs_v7/Configuration-File.md @@ -0,0 +1,20 @@ +--- +title: Configuration File +permalink: /docs_v7/Configuration-File/ +--- + +The configuration file is a text file that contains a user's options for a particular problem to be solved with the SU2 suite. It is specified as an input upon execution of SU2 components. This section briefly describes the file format and other conventions. + +The SU2 configuration file name typically carries a name of the form *filename.cfg*. The file extension .cfg is optional (this is our own convention), and the prefix can be any valid string with no spaces; e.g. config.cfg, su2-config.cfg, and flow_config.cfg are all suitable file names. + +**Note: An example configuration file, called config_template.cfg, can be found in the root SU2/ directory. The developers keep this file up to date with the latest options, and it serves as the first reference for the available options in SU2** + +The configuration file consists of only three elements: +- **Options**. An option in the file has the following syntax: option_name = value, where option_name is the name of the option and value is the desired option value. The value element may be a scalar data type, a list of data types, or a more complicated structure. The "=" sign must come immediately after the option_name element and is not optional. Lists of data types may be formatted for appearance using commas, ()-braces, {}-braces, and []-braces, though this is not required. Semicolons are semantically relevant for several option types and may not be used as convenience delimiters. SU2 will exit with an error if there are options in the config file which do not exist or if there are options with improper formatting. Some example option formats are given below. + - `FREESTREAM_VELOCITY = ( 5.0, 0.00, 0.00 ) % braces and commas can be used for list options` + - `REF_ORIGIN_MOMENT= 0.25 0.0 0.0 % however, braces and commas are optional for lists` + - `KIND_TURB_MODEL = NONE % space between elements is not significant` +- **Comments**. On a given line in the file, any text appearing after a % is considered a comment and is ignored by SU2. Additional % signs after the first on a given line are not significant. +- **White space**. Empty lines are ignored. On text lines that define options, white space (tabs, spaces) can be used to format the appearance of the file + +SU2 includes strict error checking of the config file upon execution of one of the C++ modules. For example, the code will throw errors if unknown options are specified, options appear more than once, extra text appears outside of comments, etc. diff --git a/_docs_v7/Contact.md b/_docs_v7/Contact.md new file mode 100644 index 00000000..a22845f5 --- /dev/null +++ b/_docs_v7/Contact.md @@ -0,0 +1,19 @@ +--- +title: Contact +permalink: /docs_v7/Contact/ +--- + +### SU2 Forum at CFD Online and GitHub + +Users of SU2 who have questions not addressed in the User's Guide, Developer's Guide, or FAQs pages, please post the question in the CFD online forum. [http://www.cfd-online.com/Forums/su2/](http://www.cfd-online.com/Forums/su2/) + +If you find bugs or issues in the source code or would like to submit a feature request, please use the issue tracker on the SU2 GitHub page at: [https://github.com/su2code/SU2/issues](https://github.com/su2code/SU2/issues) + +### SU2 User's Mailing List +Users are encouraged to join the SU2 user's email list. This list will be used to communicate important information to users such as new releases or event announcements. To join, follow the link below. We take privacy matters seriously - please see our privacy and cookie policies for more information. + +[Join the List!](https://su2foundation.org/) + +### Join the SU2 Development Team + +All developers that would like to contribute to SU2 are encouraged to get involved on [GitHub](https://github.com/su2code/SU2). Whether you would like to share new features or fixes with the community through Pull Requests, report issues or feature requests, or discuss the latest with your fellow developers, your participation is most welcome! diff --git a/_docs_v7/Convective-Schemes.md b/_docs_v7/Convective-Schemes.md new file mode 100755 index 00000000..95111bdf --- /dev/null +++ b/_docs_v7/Convective-Schemes.md @@ -0,0 +1,106 @@ +--- +title: Convective Schemes +permalink: /docs_v7/Convective-Schemes/ +--- + +This page lists the convective schemes available in SU2 and their associated options, it is not meant as a detailed theory guide but some application guidance is given nonetheless. +The options listed here do not apply to the high order DG solver. + +--- + +## Content ## + +- [Introduction](#introduction) +- [Compressible Flow](#compressible-flow) + - [Central schemes](#central-schemes) + - [Upwind schemes](#upwind-schemes) +- [Incompressible Flow](#incompressible-flow) + - [Central schemes](#central-schemes) + - [Upwind schemes](#upwind-schemes) +- [Turbulence Equations](#turbulence-equations) + +--- + +## Introduction ## + +Convective schemes are used in the FVM discretization of convective fluxes through the faces of the dual-grid control volumes. +They are selected via option `CONV_NUM_METHOD_FLOW` and fall under the two broad categories of central and upwind. +Central schemes tend to be more robust whereas second order upwind schemes can be more accurate (i.e. less dissipative). +To achieve second order upwind schemes need to be used with MUSCL reconstruction (`MUSCL_FLOW = YES`), see the "gradients and limiters" page for the MUSCL-related options. + +**Note:** MUSCL options have no effect on central schemes or on coarse multigrid levels in general. + +## Compressible Flow ## + +| Solver | Version | +| --- | --- | +| `EULER`, `NAVIER_STOKES`, `RANS` | 7.0.0 | + +### Central Schemes ### + +- `JST` - Jameson-Schmidt-Turkel scheme with scalar dissipation defined by the second and fourth order dissipation coefficients in option `JST_SENSOR_COEFF = (2nd, 4th)` the default values are 0.5 and 0.02 respectively. This scheme offers a good compromise between accuracy and robustness but it will over predict viscous drag contributions in low-Re meshes. +- `JST-KE` - Equivalent to `JST` with 0 fourth order coefficient (the computational effort is slightly reduced as solution Laplacians no longer need to be computed); +- `LAX-FRIEDRICH` - The simplest of central schemes with a first order dissipation term specified via `LAX_SENSOR_COEFF` (the default is 0.15), this scheme is the most stable and least accurate due to its very dissipative nature. + +The option `CENTRAL_JACOBIAN_FIX_FACTOR` (default value 4.0) affects all central schemes. +In implicit time marching it improves the numerical properties of the Jacobian matrix so that higher CFL values can be used. +To maintain CFL at lower-than-default values of dissipation coefficients, a higher factor should be used. + +**Note:** The Lax-Friedrich scheme is always used on coarse multigrid levels when any central scheme is selected. + +### Upwind Schemes ### + +- `ROE` - Classic Roe scheme; +- `L2ROE` - Low dissipation Low Mach Roe (L^2 Roe); +- `LMROE` - Rieper's Low Mach Roe; +- `TURKEL_PREC` - Roe scheme with Turkel preconditioning; +- `AUSM` - Advection Upstream Splitting Method; +- `AUSMPLUSUP` - AUSM+up, revised Mach and pressure splittings; +- `AUSMPLUSUP2` - AUSM+up2, uses an alternative pressure flux formulation; +- `SLAU` - Simple Low dissipation AUSM scheme; +- `SLAU2` - SLAU with the alternative pressure flux formulation; +- `HLLC` - Harten-Lax-van Leer-Contact; +- `CUSP` - Convective Upwind Split Pressure; +- `MSW` - Modified Steger-Warming. + +Some of the schemes above have tunning parameters or accept extra options, the following table lists those options and indicates to which schemes they apply (if a scheme does not appear on the table, no options apply to it). + +| Option \ Scheme | `ROE` | `L2ROE` | `TURKEL_PREC` | `AUSMPLUSUP[2]` | `SLAU[2]` | `HLLC` | `CUSP` | +| --------------------------------- | ----- | ------- | ------------- | --------------- | --------- | ------ | ------ | +| **`ROE_KAPPA`** | X | X | X | | | X | | +| **`ENTROPY_FIX_COEFF`** | X | X | X | | | | X | +| **`ROE_LOW_DISSIPATION`** | X | | | | X | | | +| **`USE_ACCURATE_FLUX_JACOBIANS`** | | | | X | X | | | +| **`MIN/MAX_ROE_TURKEL_PREC`** | | | X | | | | | + +- `ROE_KAPPA`, default 0.5, constant that multiplies the left and right state sum; +- `ENTROPY_FIX_COEFF`, default 0.001, puts a lower bound on dissipation by limiting the minimum convective Eigenvalue to a fraction of the speed of sound. Increasing it may help overcome convergence issues, at the expense of making the solution sensitive to this parameter. +- `ROE_LOW_DISSIPATION`, default `NONE`, methods to reduce dissipation in regions where certain conditions are verified, `FD` (wall distance based), `NTS` (Travin and Shur), `FD_DUCROS` and `NTS_DUCROS` as before plus Ducros' shock sensor; +- `USE_ACCURATE_FLUX_JACOBIANS`, default `NO`, if set to `YES` accurate flux Jacobians are used instead of Roe approximates, slower on a per iteration basis but in some cases allows much higher CFL values to be used and therefore faster overall convergence; +- `MIN_ROE_TURKEL_PREC` and `MAX_ROE_TURKEL_PREC`, defaults 0.01 and 0.2 respectively, reference Mach numbers for Turkel preconditioning. + +**Note:** Some schemes are not compatible with all other features of SU2, the AUSM family and CUSP are not compatible with unsteady simulations of moving grids, non-ideal gases are only compatible with the standard Roe and HLLC schemes. + +## Incompressible Flow ## + +| Solver | Version | +| --- | --- | +| `INC_EULER`, `INC_NAVIER_STOKES`, `INC_RANS` | 7.0.0 | + +### Central Schemes ### + +`JST` and `LAX-FRIEDRICH` are available with low speed preconditioning, the afforementioned 1st, 2nd, and 4th order dissipation coefficients apply to these schemes but the `CENTRAL_JACOBIAN_FIX_FACTOR` option does not. + +### Upwind Schemes ### + +`FDS` - Flux Difference Splitting with low speed preconditioning, this scheme does not have tunning parameters. + +## Turbulence Equations ## + +| Solver | Version | +| --- | --- | +| `RANS`, `INC_RANS` | 7.0.0 | + +Only one method is currently available: `SCALAR_UPWIND` which must be selected via option `CONV_NUM_METHOD_TURB`. +This method does not have any special parameters. + diff --git a/_docs_v7/Custom-Output.md b/_docs_v7/Custom-Output.md new file mode 100644 index 00000000..d8bc4ba7 --- /dev/null +++ b/_docs_v7/Custom-Output.md @@ -0,0 +1,144 @@ +--- +title: History and Solution Output +permalink: /docs_v7/Custom-Output/ +redirect_from: /docs/Custom-Output/ +--- + +With v7.0 we have introduced a new way of customizing the output on screen, in the history file and in the visualization files. +It is now possible to individually define what you want to have in your output. + +## Content ## + +- [Restart and Visualization Files](#restart-and-visualization-files) + - [Setting Output Fields](#setting-output-fields) +- [Customizing the Screen and History output](#customizing-the-screen-and-history-output) + - [Screen Output](#screen-output) + - [History Output](#history-output) + +--- + + +Let's define some terminology first. + +- **Screen output** : The convergence history printed on the console. +- **History output**: The convergence history written to a file. +- **Volume output** : Everything written to the visualization and restart files. +- **Output field**: A single scalar value for screen and history output or a vector of a scalar quantity at every node in the mesh for the volume output. +- **Output group**: A collection of output fields. + + +**Note**: You can print all available output fields and groups available for the current solver (set with the `SOLVER` option) by calling `SU2_CFD` with the `-d` flag, i.e. +``` +SU2_CFD -d +``` + + +## Restart and Visualization Files ## + +SU2 can output the solution in several file formats. You can specify what files you want to have by setting the option `OUTPUT_FILES` to a list of files. The valid options are described in the following table: + +| Option value | Description | +|---|---| +| `RESTART` | Native SU2 binary restart format | +| `RESTART_ASCII` | ASCII CSV restart format | +| `CSV` | ASCII CSV restart format (identical to `RESTART_ASCII`) | +| `PARAVIEW` | Binary Paraview .vtk format | +| `PARAVIEW_ASCII` | ASCII Paraview .vtk format | +| `TECPLOT` | Binary Tecplot .szplt format | +| `TECPLOT_ASCII` | ASCII Tecplot .dat format | +| `SURFACE_CSV` | Surface values in CSV format (includes all markers set with `MARKER_PLOTTING`) | +| `SURFACE_PARAVIEW` | Surface values in binary Paraview .vtk format (includes all markers set with `MARKER_PLOTTING`)| +| `SURFACE_PARAVIEW_ASCII` | Surface values in ASCII Paraview .vtk format (includes all markers set with `MARKER_PLOTTING`)| +| `SURFACE_TECPLOT` | Surface values in binary Tecplot .szplt format (includes all markers set with `MARKER_PLOTTING`)| +| `SURFACE_TECPLOT_ASCII` | Surface values in ASCII Tecplot .dat format (includes all markers set with `MARKER_PLOTTING`)| + +The default value of `OUTPUT_FILES` is `(RESTART, PARAVIEW, SURFACE_PARAVIEW)`. The output frequency can be set by using the `OUTPUT_WRT_FREQ` option. If it is a time-dependent problem, the frequency is based on the time iterations, while for steady-state problems it is based on the outer or inner iterations, depending on whether it is a multi-zone or single-zone problem, respectively. + +**Note:** If run SU2 in parallel you should always use binary output files to get the best performance. + +### Setting Output Fields ### + +The `VOLUME_OUTPUT` option can be used to set fields for the restart and visualization files. Here you have the option to specify either single fields and/or groups. + +### Example ### + +For the compressible Navier-Stokes solver (i.e. `SOLVER=NAVIER_STOKES`), a **non-exhaustive list** of possible fields/groups is the following: + +| Field Name | Description | Group Name | +|---|---|---| +| `COORD-X` | x coordinate | `COORDINATES` | +| `COORD-Y` | y coordinate | `COORDINATES` | +| `COORD-Z` | z coordinate | `COORDINATES` | +| `DENSITY` | Density | `SOLUTION` | +| `MOMENTUM-X` | Momentum x-component | `SOLUTION` | +| `MOMENTUM-Y` | Momentum y-component | `SOLUTION` | +| `MOMENTUM-Z` | Momentum z-component | `SOLUTION` | +| `ENERGY` | Energy | `SOLUTION` | +| `PRESSURE` | Pressure| `PRIMITIVE` | +| `TEMPERATURE` | Temperature | `PRIMITIVE` | +| `MACH` | Mach Number | `PRIMITIVE` | +| `PRESSURE_COEFF` | Pressure Coefficient | `PRIMITIVE` | +| `LAMINAR_VISCOSITY` | Laminar viscosity | `PRIMITIVE` | +| `SKIN_FRICTION-X` | Skin friction coefficient x-component | `PRIMITIVE` | +| `SKIN_FRICTION-Y` | Skin friction coefficient y-component | `PRIMITIVE` | +| `SKIN_FRICTION-Z` | Skin friction coefficient z-component | `PRIMITIVE` | +| `HEAT_FLUX` | Heat flux | `PRIMITIVE` | +| `Y_PLUS` | Y-Plus | `PRIMITIVE` | + + +## Customizing the Screen and History Output ## + +### Screen Output ### +You can define the output fields you want to have on screen by using the config option `SCREEN_OUTPUT`. +Fields available depend on the solver you are using. Fields available for **all solvers** are the following: + +- `TIME_ITER`: Time iteration index +- `OUTER_ITER`: Outer (coupling) iteration index (for multi-zone problems only) +- `INNER_ITER`: Inner iteration index (pseudo-time iteration) +- `CUR_TIME`: Current physical time of your simulation +- `TIME_STEP`: Current time step +- `WALL_TIME`: Current average wall-clock time for one iteration + + + +If you run a multizone problem, the convergence history of the individual zones (i.e. the convergence of the inner iteration) is disabled by default and only the convergence of the outer iteration is shown. That means `SCREEN_OUTPUT` in the sub-config files is ignored. You can still print fields from individual zones by using the field name and the zone index. For example in an Fluid-Structure interaction problem the drag in zone 0 and the von-Mises stress in zone 1 can be used as fields by adding `DRAG[0]` and/or `VMS[1]` to the screen output in the main config file. It is possible to force the output of the full inner convergence history per zone by setting `WRT_ZONE_CONV` to `YES`. + +You can also customize the frequency when the convergence history should be written to screen by using `SCREEN_WRT_FREQ_INNER`, `SCREEN_WRT_FREQ_OUTER` and `SCREEN_WRT_FREQ_TIME`. + + +### History Output ### + +The history output can be customized in a similar fashion to the screen output by using the `HISTORY_OUTPUT` option. In fact, screen and history outputs share all fields which means that everything that can written to screen can be written also to the history file and vice versa. However, instead of specifying single output fields, for the history output it is **only possible** to specify output groups by using the group name. + +If you run a multizone problem, in addition to the history files per zone, a file (default: `history_multizone.dat`) will be created where the convergence history of the outer iteration is stored. Groups for this output can be set by using the `HISTORY_OUTPUT` option in the main config file. + +You can also customize the frequency when the convergence history should be written to the history file by using `HISTORY_WRT_FREQ_INNER`, `HISTORY_WRT_FREQ_OUTER` and `HISTORY_WRT_FREQ_TIME`. + +### Example ### + +For the compressible Navier-Stokes solver (i.e. `SOLVER=NAVIER_STOKES`), a **non-exhaustive list** of possible fields/groups is the following: + +| Field Name (for screen output) | Description | Group Name (for history output) | +|---|---|---| +| `TIME_ITER` | Time iteration index | `ITER` | +| `OUTER_ITER` | Outer (coupling) iteration index. | `ITER` | +| `INNER_ITER` | Inner iteration index (pseudo-time iteration). | `ITER` | +| `CUR_TIME` | Current physical time of your simulation. | `TIME_DOMAIN` | +| `TIME_STEP` | Current time step. | `TIME_DOMAIN` | +| `WALL_TIME` | Current average wall-clock time for one iteration. | `WALL_TIME` | +| `RMS_DENSITY` | Root-mean square residual of the density. | `RMS_RES` | +| `RMS_MOMENTUM-X` | Root-mean square residual of the momentum x-component. | `RMS_RES` | +| `RMS_MOMENTUM-Y` | Root-mean square residual of the momentum y-component. | `RMS_RES` | +| `RMS_MOMENTUM-Z` | Root-mean square residual of the momentum z-component. | `RMS_RES` | +| `RMS_ENERGY` | Root-mean square residual of the energy. | `RMS_RES` | +| `DRAG` | Total Drag coefficient. | `AERO_COEFF` | +| `LIFT` | Total Lift coefficient | `AERO_COEFF` | +| `SIDEFORCE` | Total Sideforce coefficient. | `AERO_COEFF` | +| `MOMENT-X` | Total Moment around the x-axis. | `AERO_COEFF` | +| `MOMENT-Y` | Total Moment around the y-axis. | `AERO_COEFF` | +| `MOMENT-Z` | Total Moment around the z-axis. | `AERO_COEFF` | +| `FORCE-X` | Total Force in x direction. | `AERO_COEFF` | +| `FORCE-Y` | Total Force in y direction. | `AERO_COEFF` | +| `FORCE-Z` | Total Force in z direction.| `AERO_COEFF` | +| `EFFICIENCY` | Total Lift-to-drag ratio. | `AERO_COEFF` | + diff --git a/_docs_v7/Cygwin-Build-for-Windows.md b/_docs_v7/Cygwin-Build-for-Windows.md new file mode 100644 index 00000000..7b2605a3 --- /dev/null +++ b/_docs_v7/Cygwin-Build-for-Windows.md @@ -0,0 +1,211 @@ +--- +title: Cygwin Build for Windows +permalink: /docs_v7/Cygwin-Build-for-Windows/ +--- + +### Overview +Cygwin provides a unix-like environment on a Windows machine, and emulates some of the functionality of a linux distribution. Downloads and more information on Cygwin is available at http://www.cygwin.com/. To compile and run SU2 in Cygwin on a Windows machine, you will need to configure Cygwin with the appropriate packages (listed below), and then continue from within Cygwin as though you were using a linux machine. +In summary, the steps are: + +1. Download Cygwin installer +2. Install Cygwin, selecting the packages necessary to compile the source code. +3. Download the source code into a directory within cygwin/ +4. Install SU2 according to the directions for the linux installation. + +### Notes on installing Cygwin for first-time or beginner Cygwin users +* It is often recommended to install in a directory rather than the default C:\ location. +* The Cygwin shell will only be able to access folders that are within the cygwin\ directory; you will need to install and run SU2 inside the cygwin directory. + +### Cygwin packages +At the package selection step, search for the following terms and select the associated packages to install. This list is a work-in-progress, and further packages may be required or desired. + +#### Basic +* g++, gcc compiler +* python: install the packages under the python sub-heading +* cpp: all debug, pre-processor, regular expression packages. + +### Example SU2 installation on WINDOWS 10 using 64-bit Cygwin + +The CYGWIN `bash` shell is used for all steps on the command line. It is automatically available after the first installation step (typically to be launched via the CYGWIN desktop icon). + +1. Install CYGWIN (64-bit version) and development packages + * Download and run: + + [setup-x86_64.exe](https://www.cygwin.com/setup-x86_64.exe) + + Inside the Cygwin Setup GUI use `C:\cygwin64` for both `Root Directory` and `Local Package Directory`. `Chose a Download Site` close to you (also http mirrors often work better). Continue to complete the bare minimum installation. This will end with a desktop icon named `Cygwin64 Terminal`. Double-click this to open the shell and launch further commands from there. + + For detailed informations on how to install CYGWIN and selected packages see [CYGWIN Installation](https://cygwin.com/install.html). + + * Install development tools (dependencies on these packages will be automatically selected by CYGWIN) + + > NOTE: A single command installing all required packages in one is given below this list + + 1. General build environment tools + * autoconf + * autoconf2.5 + * autogen + * automake + * automake1.15 + * libtool + * make + 1. Compilers + * gcc-g++ + * mingw64-x86_64-gcc-core + * mingw64-x86_64-gcc-g++ + 1. Python + * python37 + * python37-devel + * python3-configobj + 1. OpenMPI + * libopenmpi-devel + * openmpi + 1. Miscellaneous + * vim (or any other editor in order to be able to edit files) + * rsh + * wget (to be able to download from the command line) + * zlib-devel + + * All-in-one installation of packages (after the initial minimum installation): + + > NOTE: Prepend path to `setup-x86_64.exe` (depending where it has been downloaded) + + ```bash + setup-x86_64.exe -q -P autoconf,autoconf2.5,autogen,automake,automake1.15,libtool,make,gcc-g++,mingw64-x86_64-gcc-core,mingw64-x86_64-gcc-g++,python37,python37-devel,python3-configobj,libopenmpi-devel,openmpi,vim,rsh,wget,zlib-devel + ``` + +1. Configure CYGWINs default mount point (optional, but following steps use a syntax relying on this) + + ```bash + mount -c / -o binary,noacl,posix=0 + mount -m > /etc/fstab + ``` + +1. Configure OpenMPI + + Because in OpenMPI the C++ interface was removed, the option `-lmpi_cxx` has to be removed from the linker defaults. We need to check if this option is contained in the wrapper control file. This depends on the installed OpenMPI libraries. + + Assuming the 64-bit CYGWIN is installed in `C:\cygwin64` and `/etc/fstab` has been modified as in the previous step: + + ```bash + cat /c/cygwin64/usr/share/openmpi/mpic++-wrapper-data.txt | grep lmpi_cxx + ``` + + If the option is set, then the following lines would be the result of the above `grep`command: + + libs=-lmpi_cxx -lmpi + libs_static=-lmpi_cxx -lmpi -lopen-rte -lopen-pal -lm -lgdi3 + + > NOTE: If `-lmpi_cxx` was not found, skip the next step + + If this is the case, edit `mpic++-wrapper-data.txt` and remove the `-lmpi_cxx` options so that the respective lines look like this: + + libs=-lmpi + libs_static=-lmpi -lopen-rte -lopen-pal -lm -lgdi3 + +1. Set the Python version for the installation process (for permanent setting add this line to `~/.profile`) + + ```bash + export PYTHON=/usr/bin/python3.7 + ``` + +1. Get the SU2 source code: + + * Download following file for SU2 version 6.2.0 + + ```bash + wget https://github.com/su2code/SU2/archive/v6.2.0.tar.gz + ``` + + * Extract files and change into the folder where the files were extracted to: + + ```bash + tar -xzvf v6.2.0.tar.gz + cd SU2-6.2.0 + ``` + + > NOTE: This is later the folder where the SU2_HOME variable points to + +1. Run the utility for autoconf/automake toolchain setup: + + ```bash + ./bootstrap + ``` + +1. Set compiler flags (just to be sure not to use the debug option -g) + + ```bash + export CFLAGS='-O2' + export CXXFLAGS='-O2' + ``` + +1. Create Makefiles: + + > NOTE: didn't yet get `tecio` working, therefore disabled with `--disable-tecio`
+ > NOTE: Removed `-DHAVE_EXECINFO_H` from metis cppflags (potentially could be solved via [gnulib](https://www.gnu.org/software/gnulib/manual/html_node/execinfo_002eh.html)) + + ```bash + ./configure --prefix=/home/Andreas/SU2-6.2.0 -enable-mpi --with-cc=/usr/bin/mpicc --with-cxx=/usr/bin/mpicxx --disable-tecio --with-metis-cppflags="-D_FILE_OFFSET_BITS=64 -DNDEBUG -DNDEBUG2 -DHAVE_GETLINE" + ``` + +1. Compile and link using: + + ```bash + make + ``` + +1. Distribute executables, etc. to their intended locations: + + ```bash + make install + ``` + +1. Reduce size of executables significantly (strip symbols, see also [CYGWIN FAQ 6.3](https://www.cygwin.com/faq.html). The SU2_CFD.exe is reduced from approx. 600MB to 15MB. Can be omitted if compiled with the -s option to gcc. + > NOTE: This should **NOT** be necessary if compiler flags are set as shown in step 7 + ```bash + make install-strip + ``` + +1. Cleanup the installation. This removes also the intermediate big executables from the build folders. + + ```bash + make clean + ``` + +1. Add the `$SU2_HOME` and `$SU2_RUN` environment variables to `~/.bashrc` (and `source ~/.bashrc`) + + ```bash + export SU2_RUN="path_where_you_want_the_Executables" (use same folder here as in the configure command above) + export SU2_HOME="/d/software/CFD/SU2/SU2-6.2.0" <-- UPDATE THIS folder according to your environment + export PATH=$PATH:$SU2_RUN + export PYTHONPATH=$PYTHONPATH:$SU2_RUN + ``` + +1. Test serial and parallel versions: + + ```bash + cd $SU2_HOME/QuickStart + ``` + + SERIAL command (due to the previous step `SU2_CFD.exe` should now be available in the path): + + ```bash + SU2_CFD.exe inv_NACA0012.cfg + ``` + + PARALLEL command: + Both `mpirun` and `mpiexec` do the same; `mpiexec` is recommended as the standard command. + + ```bash + mpiexec -n 4 SU2_CFD.exe inv_NACA0012.cfg + ``` + + If more processes are requested than cores are available an error will be thrown: + + > There are not enough slots available in the system. + + On WINDOWS this can be if hyperthreading is active. A system physically having 4 CPUs (cores), would show 8 CPUs in case of hyperthreading. Oversubscribe allows more processes than cores (which not necessarily is faster). + + ```bash + mpiexec -n 8 -oversubscribe SU2_CFD.exe inv_NACA0012.cfg + ``` diff --git a/_docs_v7/Developing-SU2-on-GitHub-(Internal-Developers).md b/_docs_v7/Developing-SU2-on-GitHub-(Internal-Developers).md new file mode 100644 index 00000000..97b90519 --- /dev/null +++ b/_docs_v7/Developing-SU2-on-GitHub-(Internal-Developers).md @@ -0,0 +1,92 @@ +--- +title: Developing SU2 on GitHub (Internal Developers) +permalink: /docs_v7/Developing-SU2-on-GitHub-(Internal-Developers)/ +--- + +The repository for SU2 is being hosted here on GitHub. As you are likely aware, GitHub is simply an online project hosting service with a very useful web interface and additional tools to aid code development with Git as its backbone. Git is a version control system (VCS) that is similar to SVN, Mercurial, etc., and it helps organize the development of code over time by tracking changes. + +To get started, you need to create a personal user account on GitHub (free) and follow the [basic setup instructions](https://help.github.com/articles/set-up-git). These instructions include how to get Git installed on your local machine. To sync up your local settings with GitHub, change the user.email and user.name variables for your local git configuration with +``` +git config --global user.email "your_email@domain.com" +git config --global user.name "Your Name" +``` +Note that the email address should be the one associated with your GitHub account. + +SU2 is an open-source repository that can be found as part of the [**su2code** organization on GitHub](https://github.com/su2code). The web interface is useful for viewing the recent commits to the code, changes to the code over time, documentation and tutorials, or for creating and viewing branches, for instance. To contribute to the SU2 organization repositories directly, an administrator for the project must add you as a member of the development team with push and pull privileges. However, we encourage all developers to fork the repository and to submit pull requests with their interesting new features that they would like included in the code. We are constantly reviewing pull requests as a development team. + +Most of the day-to-day development of the code will be done on your local machine at the command line using Git. After setting up Git and gaining access to the SU2 repository, create a local copy of the entire repository on your machine by cloning the version that is hosted on GitHub: +``` +git clone https://github.com/su2code/SU2.git +``` +After cloning, you should have a new SU2/ folder in your current working directory. Move into SU2/ to see the project files and to start working with the code through Git. You can see the most recent changes by typing +``` +git log +``` + +## Typical Workflow with Git + +Now that you have a local copy of SU2 from the GitHub repository, you can begin to make changes to the codebase. This section gives an example of the typical workflow for making changes to the code, committing them locally, and then pushing your changes to the remote GitHub repository. + +Please read the "Code Reviews" section of the wiki before making changes to familiarize yourself with the requirements for a good code change. + +We follow the popular ["GitFlow"](https://nvie.com/posts/a-successful-git-branching-model/) branching model for scalable development. In the SU2 repository, the master branch represents the latest stable major or minor release (7.0, 6.2.0, etc.), it should only be modified during version releases. Work that is staged for release is put into the develop branch via Pull Requests (to be discussed in a moment) from various "feature" branches where folks do their day-to-day work on the code. At release time, the work that has been merged into the develop branch is pushed to the master branch and tagged as a release. + +When a repository is cloned, all of the branches are as well, and so no additional work is necessary to acquire the development branch. However, you must tell git to switch to the development branch, which can be done with the "checkout" command + ``` + git checkout -b develop origin/develop + ``` + + +### Opening a Pull Request ### + +Now that changes will be on top of the development branch, code changes can be made. This next section describes the steps for creating a pull request. + +1. Create a new branch for making your changes. + ``` + git checkout -b fix_quadvol + ``` + Additionally, create a branch with the same name on the SU2 github repository. First, make sure the current SU2 branch is set to develop + + ![Develop Branch](../../docs_files/pr_develop_branch.png) + + then create a new branch with the appropriate name. + + ![Create Branch](../../docs_files/pr_create_branch.png) + + Depending on whether your branch name starts with `fix_`, `feature_` or `chore_`, if you open a pull request for that branch, it will automatically get the label `fix`, `feature` or`chore`, respectively. Once it is merged, this label and the title of your PR will be used to generate a change log for the next release. + +2. Make changes to the existing files (using your favorite text editor or integrated development environment, IDE) or add local files or folders to be tracked and compared against the global repo files. + + ``` + git add file1.cpp file2.cpp + ``` + +3. Optionally check that your changes have been registered and/or the files that you want have been added added + + ``` + git status + ``` + +4. Commit the changes to your local repository (not the global repository on GitHub) and create a descriptive message about your change. Commit messages are the easiest tool for examining past code changes, so it is important that they serve as documentation. A good commit message will consist of a short descriptive message on the first line, followed by a longer descriptive message. If the PR addresses any issues, they should be identified in the commit message. A good (fake) commit message is below. + + ``` + git commit -m "Fix computation of the volume for skewed quadrilateral elements." \ + -m "If a 2-D quadrilateral element is sufficiently skewed, the volume approximation is not computed properly. This modifies the volume computation to use the base and height of the quadrilateral instead of the base and hypotenuse. This fixes cases where the volume was incorrectly computed to be less than zero. Fixes issue #10." + ``` + + +4. Push the code to the remote version of the branch on GitHub + + ``` + git push origin fixquadvol + ``` + +5. This will automatically register on github, and you can use the online API to make a pull request + + ![Submit Request 1](../../docs_files/pr_submit_request_1.png) + + ![Submit Request 2](../../docs_files/pr_submit_request_2.png) + +6. Now your code is available for code review! + +We encourage developers to submit draft pull requests on GitHub, which has several benefits. This helps keep the community updated as you work on your particular feature, and offers the opportunity for others to collaborate or offer helpful feedback in the process. Duplicate work and wasted effort can be avoided this way. Additionally, draft pull requests will also benefit from continuous integration testing, and you will be alerted to any regression test failures immediately, which can also save development effort. diff --git a/_docs_v7/Download.md b/_docs_v7/Download.md new file mode 100644 index 00000000..a734532f --- /dev/null +++ b/_docs_v7/Download.md @@ -0,0 +1,9 @@ +--- +title: Download +permalink: /docs_v7/Download/ +--- + +SU2 is freely available for use under the GNU Lesser General Public License, version 2.1. Please reference the [license details](https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html) for terms and conditions. + +Please visit our [download portal](../../download.html) to obtain binary executables or the SU2 source code and [register as a user of SU2](https://su2foundation.org/)! + diff --git a/_docs_v7/Execution.md b/_docs_v7/Execution.md new file mode 100644 index 00000000..c10fd1e2 --- /dev/null +++ b/_docs_v7/Execution.md @@ -0,0 +1,112 @@ +--- +title: Execution +permalink: /docs_v7/Execution/ +--- + +Once downloaded and installed, and now that you know the basics for setting up your problems, SU2 will be ready to run simulations and design problems. Using simple command line syntax, users can execute the individual C++ programs while specifying the problem parameters in the all-purpose configuration file. For users seeking to utilize the more advanced features of the suite (such as shape optimization or adaptive mesh refinement), Python scripts that automate more complex tasks are available. Appropriate syntax and information for running the C++ modules and python scripts can be found below. + +--- + +## Content + +- [C++ Modules](#c-modules) +- [Python Scripts](#python-scripts) + - [Parallel Computation Script (parallel-computation.py)](#parallel-computation-script-parallel_computationpy) + - [Continuous Adjoint Gradient Calculation (continuous_adjoint.py)](#continuous-adjoint-gradient-calculation-continuous_adjointpy) + - [Discrete Adjoint Gradient Calculation (discrete_adjoint.py)](#discrete-adjoint-gradient-calculation-discrete_adjointpy) + - [Finite Difference Gradient Calculation (finite_differences.py)](#finite-difference-gradient-calculation-finite_differencespy) + - [Shape Optimization Script (shape_optimization.py)](#shape-optimization-script-shape_optimizationpy) + +--- + +## C++ Modules + +As described in the [Software Components](/docs_v7/Software-Components/) page, there are a number of C++ modules that are the core of the SU2 suite. After compilation, each can be executed at the command line using a Unix-based terminal (or appropriate emulator, such as Cygwin). The executables for these modules can be found in the `$SU2_HOME//bin` directories and in the `$SU2_HOME/SU2_PY` directory. The configuration file specifies the problem and solver parameters for all SU2 modules and must be included at runtime. + +The syntax for running each C++ module individually in serial is: +``` +$ SU2_MODULE your_config_file.cfg +``` +where `SU2_MODULE` can be any of the C++ modules on the [Software Components](/docs_v7/Software-Components/) and `your_config_file.cfg` is the name of the configuration file that you have prepared for the problem. An example of a call to SU2_CFD with a configuration file "default.cfg" is included below: +``` +$ ./SU2_CFD default.cfg +``` +where the executable, SU2_CFD, and the [Configuration File](/docs_v7/Configuration-File/), default.cfg, are located in the current working directory. Please see the [Build from Source](/docs_v7/Build-SU2-from-Source/) page for how you can set up environment variables to run the modules from any directory. Additionally, SU2 is a fully-parallel suite, and assuming that you have compiled with MPI support, each of the modules can be executed in parallel. For example, to run the CFD solver on 8 cores, you might enter: +``` +$ mpirun -n 8 SU2_CFD default.cfg +``` +Note that, depending on your flavor of MPI, you may need to use a different launcher, such as *mpiexec*. Please see the documentation for your particular MPI implementation. + +## Python Scripts + +The distribution of SU2 includes several Python scripts that coordinate the use of the C++ modules to perform more advanced analyses and simulations. A working installation of Python is highly recommended, as a number of tasks can be easily automated using provided scripts (e.g., computing a drag polar). These Python scripts can be found in the `$SU2_HOME/SU2_PY`. + +All of the scripts can be executed by calling python and passing the appropriate SU2 python script and options at runtime. The syntax is as follows: +``` +$ python script_name.py [options] +``` +where *script_name.py* is the name of the script to be run, and [options] is a list of options available to each script file. A brief description of the most commonly used scripts, their execution syntax, and runtime options are included below. Users are encouraged to look at the source code of the python scripts. As with many Python programs, the code is easily readable and gives the specifics of the implementation. They can also be used as templates for writing your own scripts for automating SU2 tasks. + +### Parallel Computation Script (parallel_computation.py) + +The parallel computation script, parallel_computation.py, coordinates the steps necessary to run SU2_CFD in parallel and produce solution output files. The script calls SU2_CFD in parallel (using MPI) with the indicated number of ranks. At the conclusion of the simulation, the parallel_computation.py script generates the solution files from the restart file written during execution by calling the SU2_SOL module. The SU2_SOL module can be executed at any time (in serial or parallel) to generate solution files in a specified format from a restart file and corresponding mesh. + +Usage: `$ python parallel_computation.py [options]` + +Options: +* `-h, --help` show help message and exit +* `-f FILE, --file=FILE` read config from FILE +* `-n PARTITIONS, --partitions=PARTITIONS` number of PARTITIONS +* `-c COMPUTE, --compute=COMPUTE COMPUTE` direct and adjoint problem + +### Continuous Adjoint Gradient Calculation (continuous_adjoint.py) + +The continuous adjoint calculation script, continuous_adjoint.py, automates the procedure for calculating sensitivities using a continuous adjoint method. The script calls SU2_CFD to first run a direct analysis to obtain a converged solution, then calls SU2_CFD again to run an adjoint analysis on the converged flow solution to obtain surface sensitivities. The SU2_DOT module is then called to project design variable perturbations onto the surface sensitivities calculated in the adjoint solution to arrive at the gradient of the objective function with respect to the specified design variables. + +Usage: `$ python continuous_adjoint.py [options]` + +Options: +* `-h, --help` show help message and exit +* `-f FILE, --file=FILE` read config from FILE +* `-n PARTITIONS, --partitions=PARTITIONS` number of PARTITIONS +* `-c COMPUTE, --compute=COMPUTE COMPUTE` direct and adjoint problem +* `-s STEP, --step=STEP DOT` finite difference STEP + +### Discrete Adjoint Gradient Calculation (discrete_adjoint.py) + +Similar to the continuous adjoint script, the discrete adjoint script calls SU2_CFD to generate a flow solution and then calls SU2_CFD_AD to run an adjoint computation based on the objective function specified in the config file. Finally, SU2_DOT_AD is called to map the surface sensitivities onto the design variables specified desig variables. + +Usage: `$ python discrete_adjoint.py [options]` + +Options: +* `-h, --help` show help message and exit +* `-f FILE, --file=FILE` read config from FILE +* `-n PARTITIONS, --partitions=PARTITIONS` number of PARTITIONS +* `-c COMPUTE, --compute=COMPUTE COMPUTE` direct and adjoint problem + +### Finite Difference Gradient Calculation (finite_differences.py) + +The finite difference calculation script is used to calculate the gradient of an objective function with respect to specified design variables using a finite difference method. This script calls SU2_CFD repeatedly, perturbing the input design variables and mesh using SU2_DEF, stores the sensitivity values, and outputs the gradient upon exit. + +Usage: `$ python finite_differences.py [options]` + +Options: +* `-h, --help` show help message and exit +* `-f FILE, --file=FILE` read config from FILE +* `-n PARTITIONS, --partitions=PARTITIONS` number of PARTITIONS +* `-s STEP, --step=STEP` finite difference STEP +* `-q QUIET, --quiet=QUIET` if True, output QUIET to log files + +### Shape Optimization Script (shape_optimization.py) + +The shape optimization script coordinates and synchronizes the steps necessary to run a shape optimization problem using the design variables and objective function specified in the configuration file. The optimization is handled using SciPy's SLSQP optimization algorithm by default. Objective functions (drag, lift, etc.) are determined by running a direct flow solution in SU2_CFD, and gradients are obtained using the adjoint solution by default (other options can be selected). For each major iteration in the design process, the mesh is deformed using SU2_DEF, and the sequence is repeated until a local optimum is reached. + +Usage: `$ python shape_optimization.py [options]` + +Options: +* `-h, --help` show help message and exit +* `-f FILE, --file=FILE` read config from FILE +* `-r NAME, --name=NAME` try to restart from project file NAME +* `-n PARTITIONS, --partitions=PARTITIONS` number of PARTITIONS +* `-g GRADIENT, --gradient=GRADIENT` Method for computing the GRADIENT (ADJOINT, DISCRETE_ADJOINT, FINDIFF, NONE) +* `-q QUIET, --quiet=QUIET` True/False Quiet all SU2 output (optimizer output only) diff --git a/_docs_v7/FAQ.md b/_docs_v7/FAQ.md new file mode 100644 index 00000000..8e041953 --- /dev/null +++ b/_docs_v7/FAQ.md @@ -0,0 +1,56 @@ +--- +title: FAQ +permalink: /docs_v7/FAQ/ +--- + +# Frequently Asked Questions +### I have a question that isn't answered here. Where can I get more help? +If the answer to your question is not here, try the [forum](http://cfd-online.com/Forums/su2/). + +### I am new to CFD and I don't know where to start. Can you help me? +The best place to start for a new user after installing the code is the [Quick Start](/docs_v7/Quick-Start/) tutorial. + +### Where is the documentation? +The most easy-to-use documentation is here on GitHub, and you just found it! Users are especially encouraged to go through the docs in the Installation and Users Guide sections for all of the necesary details for running your first calculations. + +For more detail on what configuration options are available and their syntax, see the file config_template.cfg in the SU2 root directory: https://github.com/su2code/SU2/blob/master/config_template.cfg + + +### My simulation diverges. What should I do? +Adjust the configuration file options, or improve mesh quality. Refer to the forum, tutorials, and TestCases for more specific examples (many of the config files there can be used as initial templates for your own cases. The most common option to change is to lower the CFL number to improve stability. + + +### When I run in parallel, the code prints multiples of the same line, for example: +``` +> Iter Time(s) Res[Rho] Res[RhoE] CLift(Total) CDrag(Total) + +> Iter Time(s) Res[Rho] Res[RhoE] CLift(Total) CDrag(Total) + +> Iter Time(s) Res[Rho] Res[RhoE] CLift(Total) CDrag(Total) + +> 0 0.190073 -3.585391 -2.989014 0.114015 0.100685 + +> 0 0.190073 -3.585391 -2.989014 0.114015 0.100685 + +> 0 0.190073 -3.585391 -2.989014 0.114015 0.100685 +``` + +The code has not been compiled properly with parallel support. Refer to the installation instructions. + + +### What is the format of the residuals that are written to the console, and what do they mean? +Residuals are printed in log10 format, and indicate how close the solution is to satisfying the governing equations. Convergence is usually determined by a desired reduction in the residual - a reduction of "6" would mean the residual is 10^-6 of its initial value. If possible, it is recommended to converge your simulations until the residuals reach machine precision. + + +### Help! I just updated the code from a version that previously worked for me, and now there is an error. What do I do? +* Easy fix: read the error output. If it says that there is an unrecognized config file option, remove the associated line from the config file. Note that the config options may change between code releases to allow more control, use new features, or simplify the config file. +* Medium fix: revert to the release you used to use. Make sure that the release/version number for the TestCases repository is the same, and remember to recompile. If a case which previously converged now diverges, or otherwise doesn't do what you expect, try changing the options like CFL number, artificial dissipation coefficients, etc. Read the initial output of the code to make sure that what you have set in the config file is being applied - some config file options only apply to certain solvers. +* Advanced fix: after exhausting the easy and medium options, or if a clear bug like a segfault occurs, [post an Issue on the GitHub repository](https://github.com/su2code/SU2/issues). + + +### I'm getting a warning about "Nonphysical points". What does that mean, and how do I fix it? +A nonphysical point means the flow solution has encountered a negative density, pressure, or temperature. If the warnings stop after a few iterations, it's ok. If the warnings continue, the solution is likely diverging and you may need to adjust the config file options. + + +### Where can I get the suite of test cases for SU2? +The test case config files are found in the SU2 code repo, while the meshes are located in a separate repository under the SU2 organization. We recommend copying the meshes into place within the SU2 source directory where the config files reside (under version control). See [this page](/docs_v7/Test-Cases/) for directions. diff --git a/_docs_v7/Gitting-Started.md b/_docs_v7/Gitting-Started.md new file mode 100644 index 00000000..cc08f795 --- /dev/null +++ b/_docs_v7/Gitting-Started.md @@ -0,0 +1,21 @@ +--- +title: GIT-ting Started +permalink: /docs_v7/Gitting-Started/ +--- + +As you now know, GitHub is the center of all development efforts in SU2. The su2code organization contains the main code repository as well as supporting materials. You can check out all of the development activity, and new developers are encouraged to log feature requests, questions, and bug reports through the GitHub issue tracker. Developers can have their code contributions integrated through GitHub as well. For more information, keep reading! + +## Branching Model + +We follow [a popular git branching strategy](http://nvie.com/posts/a-successful-git-branching-model/) in order to leverage decentralized development. This list describes the types of branches on the SU2 repository. You'll want to pick the right one to work with, in order keep the merging process simple. + +- master -- stable, latest release and fixes +- develop -- current development, generally the branch for you to fork or start a new branch from +- feature_* -- feature specific branches +- fix_* -- branches that fix a particular bug or capability (not new features) + +## Contributing Code + +SU2 merges new code contributions through pull requests. As a new developer, you'll want to fork SU2 to your personal account. This creates a clone of the whole SU2 repository, branches and all, inside your github account. Generally you'll want to start from the develop branch, but you can check with the developers if you think it would be more appropriate to work on a feature branch. + +You can push all of your working changes to your forked repository. Once you're happy with these, and want to push them to the origin repository, submit a pull request to the 'develop' branch under the SU2 repo. Make sure to pull any new changes from the origin repository before submitting the pull request, so that the changes can be merged more simply. The SU2 developers will review the changes, make comments, ask for some edits. Then when everything looks good, your changes will merge into the main development branch! diff --git a/_docs_v7/Guide-to-v7.md b/_docs_v7/Guide-to-v7.md new file mode 100644 index 00000000..c6047a9e --- /dev/null +++ b/_docs_v7/Guide-to-v7.md @@ -0,0 +1,79 @@ +--- +title: Guide to Version v7 +permalink: /docs_v7/Guide-to-v7/ +redirect_from: /docs/Guide-to-v7/ +--- + +With v7.0 we have introduced a lot of updates and changes that affect how you interact with the code. This document gives an overview on the most important changes, so that you can quickly update your existing config files to be compatible with v7.0. + +### Definition of the physical problem and solver ### + +The option `PHYSICAL_PROBLEM` has been renamed to `SOLVER`. The rational behind this change is that we are going to have several different solvers in the future which essentially solve the same physical problems. You can find a list of current solvers in the new [Solver Setup](/docs_v7/Solver-Setup) section. + +### Definition of the incompressible solver ### + +The option `REGIME_TYPE` has been removed. In line with the change above, the incompressible solver is now specified using the `SOLVER` option by setting it to `INC_EULER`, `INC_NAVIER_STOKES` or `INC_RANS`. + +### Controlling the solver ### + +We have made the control of the different solvers more consistent. In particular setting the number of iterations. The option `EXT_ITER` has been removed and is replaced depending on the definition of the problem. Options for defining a time-dependent problem also changed. More details can be found in the table below and in section [Solver Setup](/docs_v7/Solver-Setup). + +| Old option name | New option name | Note +| --- | --- | --- | +| `EXT_ITER` | `INNER_ITER`/`ITER` or `OUTER_ITER` or `TIME_ITER`| Depending on the problem +| `UNSTEADY_SIMULATION` | `TIME_MARCHING` | Option values are the same as before | +| - | `TIME_DOMAIN` | Value `YES` enables the time-dependent mode (default is `NO`) | +| `UNST_TIMESTEP` | `TIME_STEP` | - | +| `UNST_TIME` | `MAX_TIME` | - | +| `UNST_TIME_ITER` | `INNER_ITER` | - | + +### Output options ### + +A lot of effort has been put into making the output more customizable. Below you find a list of options that have changed. + +| Old option name | New option name | Note +| --- | --- | --- | +| `SOLUTION_FLOW_FILENAME` | `SOLUTION_FILENAME` | - | +| `RESTART_FLOW_FILENAME` | `RESTART_FILENAME` | - | +| `SURFACE_FLOW_FILENAME` | `SURFACE_FILENAME` | - | +| `VOLUME_FLOW_FILENAME` | `VOLUME_FILENAME` | - | +| `OUTPUT_FORMAT` | `TABULAR_FORMAT` | This option now defines **only** the format of tabular outputs like the history files (values are `CSV`, `TECPLOT`) | +| - | `OUTPUT_FILES` | Replaces the options `WRT_VOL_SOL`, `WRT_SRF_SOL`, `WRT_CSV_SOL`, `WRT_BINARY_RESTART`, by specifying a list of files to output (see [Custom Output](/docs_v7/Custom-Output))| +| `WRT_SOL_FREQ_DUALTIME`, `WRT_SOL_FREQ` | `OUTPUT_WRT_FREQ` | - | +| `WRT_CON_FREQ_DUALTIME`, `WRT_CON_FREQ` | `SCREEN_WRT_FREQ_INNER`, `SCREEN_WRT_FREQ_OUTER`, `SCREEN_WRT_FREQ_TIME` | Same options exist for history output (by replacing `SCREEN_*` with `HISTORY_*`) | +| `WRT_OUTPUT`| - | Removed. Equivalent behavior can be achieved by setting `OUTPUT_FILES` to `NONE` | +| `WRT_RESIDUALS`, `WRT_LIMITERS` | `VOLUME_OUTPUT`| Add the corresponding fields to the new option | +| `LOW_MEMORY_OUTPUT` | - | Removed. Equivalent behavior can be achieved by setting `VOLUME_OUTPUT` to `COORDINATES, SOLUTION`| + +**Important note**: Visualization files are now also written when the code runs in parallel (if added to `OUTPUT_FILES`). + +### ASCII Restart format ### + +The ASCII restart format has been changed to a `CSV` format. As a consequence **ASCII restart files** generated with a version before 7.0 are not compatible any more. However, in your installation directory you will find a python script called `convert_to_csv.py` that will convert old restart files to the new format. On your commandline use +``` +convert_to_csv.py -i your_restart.dat +``` +to run the script. This will create a file called `your_restart.csv` wich can be used as input if you disable reading binary files with `READ_BINARY_RESTART` set to `NO`. + +### Grid/mesh movement ### + +Mesh movement has been split into grid movement (motion is applied on the whole mesh, `GRID_MOVEMENT` option) and surface movement (motion is defined for a particular marker, `SURFACE_MOVEMENT` option). + +| Option | Option values | Options to define the movement| +| --- | --- | --- | +|`GRID_MOVEMENT`| `RIGID_MOTION`, `ROTATING_FRAME`, `STEADY_TRANSLATION` | `MOTION_ORIGIN`, `TRANSLATION_RATE`, `ROTATION_RATE`, `PITCHING_OMEGA`, `PITCHING_AMPL`, `PITCHING_PHASE`, `PLUNGING_OMEGA`, `PLUNGING_AMPL` +| `SURFACE_MOVEMENT` | `DEFORMING`, `MOVING_WALL`, `EXTERNAL`, `EXTERNAL_ROTATION` | `SURFACE_MOTION_ORIGIN`, `SURFACE_TRANSLATION_RATE`, `SURFACE_ROTATION_RATE`, `SURFACE_PITCHING_OMEGA`, `SURFACE_PITCHING_AMPL`, `SURFACE_PITCHING_PHASE`, `SURFACE_PLUNGING_OMEGA`, `SURFACE_PLUNGING_AMPL` + + +### Setting convergence criteria ### +Below are the options that have changed or are removed: + +| Old option name | New option name | Note +| --- | --- | --- | +| `RESIDUAL_MINVAL` | `CONV_RESIDUAL_MINVAL` | - | +| `CAUCHY_ELEMS` | `CONV_CAUCHY_ELEMS` | - | +| `CAUCHY_EPS` | `CONV_CAUCHY_EPS` | - | +| `CONV_CRITERIA` | `CONV_FIELD` | Accepts all fields available as output for the current solver (see [Solver Setup](/docs_v7/Solver-Setup#setting-convergence-critera))| +| `RESIDUAL_REDUCTION` | - | Removed. Equivalent behavior can be achieved by choosing a relative residual field for `CONV_FIELD` and setting `CONV_RESIDUAL_MINVAL` appropriately. + + diff --git a/_docs_v7/Installation.md b/_docs_v7/Installation.md new file mode 100644 index 00000000..e1fd39c2 --- /dev/null +++ b/_docs_v7/Installation.md @@ -0,0 +1,64 @@ +--- +title: Installation +permalink: /docs_v7/Installation/ +--- + +## Installing SU2 + +SU2 has been designed with ease of installation and use in mind. This means that, wherever possible, a conscious effort was made to develop in-house code components rather than relying on third-party packages or libraries to maintain high portability. In simple cases (serial version with no external libraries), the flow solver can be compiled and executed with just a C++ compiler. + +However, the capabilities of SU2 can be extended using externally-provided software. For example, parallel computations require an installed implementation of MPI (Message Passing Interface) for data communication. Again, to facilitate ease of use and to promote the open source nature, whenever external software is required within the SU2 suite, packages that are free or open source have been favored, and we try to ship, build, and link them automatically for you. These dependencies and third-party packages are discussed below. + +**Building from source**: refer to the [Source Installation Guide](/docs_v7/Build-SU2-From-Source/). This is the typical install method for Linux/Mac OS X. + +The binary executables available on the download page are intended to get new users up and running as quickly as possible. This option is best for new CFD users or those looking to quickly sample some of the features of SU2. To make these binary distributions available to a wide range of potential users, some advanced features requiring external libraries and dependencies have been disabled (most notably the ability to run simulations in parallel). In other words, the pre-compiled binary executables are simply the serial version of the SU2 C++ modules. + +No compilation is required for users who select the binary distribution of SU2. Simply install the binaries, open a terminal, and proceed to the Quick Start Tutorial. Binaries are available for multiple platforms, including installers for Windows. + +**Windows users**: please refer to the [Windows Installation Guide](/docs_v7/Windows-Installation/). + +## Required Software for Running SU2 + +### Command Line Terminal + +In general, all SU2 execution occurs via command line arguments within a terminal. For Unix/Linux or Mac OS X users, the native terminal applications are needed. For Windows users, Console is recommended. + +### Data Visualization + +Users of SU2 need a data visualization tool to post-process solution files. The software currently supports ASCII and binary output formats natively read by ParaView and Tecplot, respectively. ParaView provides full functionality for data visualization and is freely available under an open source license. Tecplot is a commercially-licensed software package widely used by the scientific computing community and is available for purchase. Some SU2 results are also output to comma-separated value (.csv) files, which can be read by a number of software packages. Additional output formats may be added in the future. The two most typical packages used by the development team are the following: +- ParaView +- Tecplot + +## Optional Third-Party Software + +Although not required, several third-party packages help extend the capabilities of SU2 for particular purposes. Details of the capabilities enabled in SU2 by adding the packages and how to obtain them are provided here. + +### Grid Generation + +Users wishing to perform analyses on their own meshes must have a means of generating them. The native SU2 grid format is designed for readability and ease of use: users with simple computational domains can write scripts to generate the appropriate meshes (and some example scripts are provided in the mesh files page). For more complex configurations, grid generation software is recommended, and it should have the capability to export to SU2 or CGNS file formats. Several open-source and commercial products are available, and a list of common options is included below. +- Pointwise +- Gmsh +- ICEM CFD +- Gambit + +Note that there are also a number of excellent contributions from the open-source community for creating and converting meshes between various formats (e.g., OpenFOAM to SU2 format). The developers encourage members of the community to share their contributions in this regard, and many of these contributions can be found in the threads of the SU2 forum on CFD Online. + +### CGNS Library + +To make creating your own meshes easier and more accessible, support for the open CGNS data standard has been included within SU2. The main advantage gained is that complex meshes created in a third-party software package (one that supports unstructured, single-zone CGNS file export) can be used directly within SU2 without the need for conversion to the native format. Moreover, as CGNS is a binary format, the size of the mesh files can be significantly reduced. If needed, a converter from CGNS to the SU2 format has been built into SU2 (See the inviscid wedge tutorial). Starting with SU2 v4.3, the source code of the CGNS library is shipped with SU2 in the externals/ directory, and it is automatically built and linked for you when compiling SU2. **NOTE: SU2 supports only CGNS files in the ADF format at this time.** + +### Parallel Tools + +Users wishing to run simulations on distributed-memory computers will need an implementation of the Message Passing Interface (MPI) standard. In these situations, SU2 performs the grid partitioning using the ParMETIS software package. ParMETIS comes packaged with the SU2 source code in the externals/ directory, and it will be automatically built and linked for you. However, you will still need access to an MPI implementation alongside your C/C++ compiler on your system. A variety of implementations of the MPI standard exist, and they can often be installed using package managers on Linux or Mac OS X. Alternatively, users can download and build their own MPI implementations from source. The following are some well-known, freely-available implementations of MPI: +- OpenMPI +- MPICH +- MVAPICH + +### Python & Python Modules + +Each of the C++ modules for SU2 can be called directly from the command line and do not require Python, including parallel calculations with MPI. However, the coupling of the C++ modules needed for, for example, design optimization problems can be automated via the execution of the appropriate Python scripts included in the software distribution. For instance, when performing shape design, the shape_optimization.py script is available to automate all steps. Note that this script has additional dependencies on the NumPy and SciPy modules for scientific computing in Python, including optimization routines in the SciPy library. These packages are freely available at the sites linked below: +- Python +- NumPy +- SciPy + +Alternatively, Python and these packages can be found in prebuilt installations, such as the Anaconda Distribution, or from package managers like Homebrew for Mac OS X. diff --git a/_docs_v7/Linear-Solvers-and-Preconditioners.md b/_docs_v7/Linear-Solvers-and-Preconditioners.md new file mode 100755 index 00000000..46535d9f --- /dev/null +++ b/_docs_v7/Linear-Solvers-and-Preconditioners.md @@ -0,0 +1,112 @@ +--- +title: Linear Solvers and Preconditioners +permalink: /docs_v7/Linear-Solvers-and-Preconditioners/ +--- + +Linear solvers (and preconditioners) are used in implicit (pseudo)time integration schemes (any option with "IMPLICIT" or "DUAL-TIME" in the name). +This page lists the available options and provides guidance on how to setup the linear solvers for best results. +As the numerical properties of the linear systems vary significantly with application, and even with application-specific options, a "one size fits all" default setting is not available. + +--- + +## Content ## + +- [Option List](#option-list) + - [Linear Solvers](#linear-solvers) + - [Linear Preconditioners](#linear-preconditioners) + - [External Solvers](#external-solvers) +- [Setup Advice](#setup-advice) + - [Fluid Simulations](#fluid-simulations) + - [Structural Simulations](#structural-simulations) + - [Mesh Deformation](#mesh-deformation) + - [Discrete Adjoint](#discrete-adjoint) + +--- + +## Option List ## + +### Linear Solvers ### + +The following options accept a type of linear solver: +- `LINEAR_SOLVER`: Main option for direct/primal and continuous adjoint problems. The linear solver used by all physics solvers of the zone associated with the configuration file. +- `DISCADJ_LIN_SOLVER`: Main option for discrete adjoint problems. +- `DEFORM_LINEAR_SOLVER`: Linear solver for elasticity-based mesh deformation. + +In most applications the linear solver tolerance is defined by option `LINEAR_SOLVER_ERROR`, and the maximum number of iterations by `LINEAR_SOLVER_ITER`. +Mesh deformation uses `DEFORM_LINEAR_SOLVER_ERROR` and `DEFORM_LINEAR_SOLVER_ITER`, as it may coexist with other physics in the same physical zone. + +The available types of (iterative) linear solver are: + +| Type | Description | Notes | +| --- | --- | --- | +| `FGMRES` | Flexible Generalized Minimum Residual | This is the default option. | +| `RESTARTED_FGMRES` | Restarted `FGMRES` (reduces memory footprint) | Restart frequency controlled by `LINEAR_SOLVER_RESTART_FREQUENCY`. | +| `BCGSTAB` | Bi-Conjugate Gradient Stabilized | See setup advice. | +| `CONJUGATE_GRADIENT` | Conjugate Gradient | Use it only for elasticy, or mesh deformation problems (i.e. symmetric/self-adjoint). | +| `SMOOTHER` | Iterative smoothing with the selected preconditioner. | Relaxation factor controlled by `LINEAR_SOLVER_SMOOTHER_RELAXATION` | + +**Note**: The `SMOOTHER` option is not available for mesh deformation applications (as it stands little chance of doing any smoothing). + +### Linear Preconditioners ### + +Analogously to the above options, the following accept a type of linear preconditioner: +- `LINEAR_SOLVER_PREC` +- `DISCADJ_LIN_PREC` +- `DEFORM_LINEAR_SOLVER_PREC` + +The available types of preconditioner are: + +| Type | Description | Notes | +| --- | --- | --- | +| `JACOBI` | Block Jacobi preconditioner. | Lowest computational cost and effectiveness. | +| `LU_SGS` | Lower-Upper Symmetric Gauss-Seidel. | Lowest memory footprint, intermediate cost and effectiveness. | +| `ILU` | Incomplete Lower Upper factorization with connectivity-based sparse pattern. | Highest cost and effectiveness, fill-in is controlled by `LINEAR_SOLVER_ILU_FILL_IN`. | +| `LINELET` | Line-implicit Jacobi preconditioner. | Tridiagonal systems solved along grid lines normal to walls, Jacobi elsewhere. | + +**Note**: Only `JACOBI` and `ILU` are compatible with discrete adjoint solvers. + +### External Solvers ### + +Version 7 introduces experimental support for the direct sparse solver [PaStiX](https://gforge.inria.fr/projects/pastix/) see detailed options in `TestCases/pastix_support/readme.txt` + +## Setup Advice ## + +For tiny problems with ~10k nodes almost any solver will do, these settings are more important for medium-large problems. + +**Disclaimer**: Your own experience is more important that this advice, but if you have yet to gain some this should help. + +### Fluid Simulations ### + +Fastest overall convergence is usually obtained by using the highest CFL number for which the flow solver is stable, and the linear systems still reasonably economic to solve. +For example central schemes like JST allow very high CFL values, however at some point (100-400 for RANS grids) the linear systems become too expensive to solve and performance starts decreasing. +Upwind schemes are less plagued by this as stability considerations usually put a lower limit on CFL, and the linear systems are better conditioned to begin with. + +Like CFL, the linear solver tolerance should be the highest (i.e. less accurate) possible for which the flow solver is still stable, usually in the 0.05-0.001 range, having to go lower is often a sign of poor mesh quality resulting in localized high residuals. +A high linear tolerance does not reduce the accuracy of the final results since the solution is iterative, and on each iteration of the flow solver the right hand side of the linear system is the nonlinear residual, only this residual needs to be low for accurate solution of the discretized nonlinear equations. + +The maximum number of iterations should allow the linear solver to converge, however the memory footprint of `FGMRES` (which should be your default solver) is proportional to that number, if that becomes a problem you can switch to `RESTARTED_FGMRES` or `BCGSTAB`, the latter may perform better for stiff systems like those resulting from central schemes at high CFL. +For a typical problem with an upwind scheme 10 iterations should be sufficient, for central schemes up to 50 may be required. + +High CFL cases will usually require the `ILU` preconditioner, while low CFL cases may run better with `LU_SGS` as even if more linear iterations are required, `LU_SGS` has no setup cost. + +Finally, the concept of high/low CFL is somewhat case dependent, for RANS meshes (stretched close to walls) and upwind schemes, high is greater than 100 and low less than 20, central schemes move the limits down, time domain and less stretched meshes (e.g. for Euler or Navier-Stokes simulations) move the limits up. + +### Structural Simulations ### + +At scale these become the most difficult systems to solve in SU2 due to their elliptical nature, they are easier for time-domain problems nonetheless always start with the `ILU` preconditioner. +A much larger number of linear iterations is required (>100) `RESTARTED_FGMRES` or `CONJUGATE_GRADIENT` should therefore be used. +For linear elasticity an error of at most 1e-8 should be targeted as contrary to fluid problems there are no outer iterations, for nonlinear elasticity 1e-6 may suffice as a few nonlinear iterations are required. + +**Note**: If the solution becomes challenging, and the problem is 2D or you have RAM to spare, consider using the external direct solvers. + +### Mesh Deformation ### + +For elasticity-based mesh deformation the advice is the same as for structural simulations. + +### Discrete Adjoint ### + +Discrete adjoint applications respond well to high CFL values, the advice is generally the same as for the primal counterpart (fluid or structural). +The `ILU` preconditioner should be used as `JACOBI` will only give an advantage for very low CFL values. + +**Note**: For steady-state discrete adjoint problems the system matrix does not change, therefore the external direct solvers may achieve the shortest solution time for 2D and medium scale (<1M nodes) 3D problems. + diff --git a/_docs_v7/Markers-and-BC.md b/_docs_v7/Markers-and-BC.md new file mode 100755 index 00000000..6b8dbc80 --- /dev/null +++ b/_docs_v7/Markers-and-BC.md @@ -0,0 +1,264 @@ +--- +title: Markers and Boundary Conditions +permalink: /docs_v7/Markers-and-BC/ +--- + +The term *Marker* refers to a named entity in your mesh file. Boundary conditions are defined by assigning names of the markers to the corresponding option. Below you will find a list of the most common boundary conditions along with a short description. + +--- + +## Content ## + +- [Euler (Slip) Wall](#euler-slip-wall) +- [Symmetry Wall](#symmetry-wall) +- [Constant Heatflux (no-slip) Wall](#constant-heatflux-no-slip-wall) +- [Isothermal (no-slip) Wall](#isothermal-no-slip-wall) +- [Farfield Boundary Condition](#farfield-boundary-condition) +- [Inlet Boundary Condition](#inlet-boundary-condition) + - [Total Conditions](#total-conditions) + - [Mass Flow Inlet](#mass-flow-inlet) + - [Velocity Inlet](#velocity-inlet) + - [Pressure Inlet](#pressure-inlet) +- [Outlet Boundary Condition](#outlet-boundary-condition) + - [Pressure Outlet (Compressible)](#pressure-outlet-compressible) + - [Pressure Outlet (Incompressible)](#pressure-outlet-incompressible) + - [Mass Flow Outlet](#mass-flow-outlet) +- [Periodic Boundary Condition](#periodic-boundary-condition) +- [Structural Boundary Conditions](#structural-boundary-conditions) + - [Clamped Boundary](#clamped-boundary) + - [Displacement Boundary](#displacement-boundary) + - [Load Boundary](#load-boundary) + - [Normal Pressure Boundary](#normal-pressure-boundary) + +--- + +## Euler (Slip) Wall ## + +| Solver | Version | +| --- | --- | +| `EULER`, `NAVIER_STOKES`, `RANS`, `INC_EULER`, `INC_NAVIER_STOKES`, `INC_RANS`, `FEM_EULER`, `FEM_NAVIER_STOKES` | 7.0.0 | + +An Euler wall for inviscid flow is defined with the `MARKER_EULER` option. It can also be used as a slip wall in viscous flow. Only the marker name has to be given for this option. + +For all Finite Volume (FVM) solvers, i.e. not the `FEM_*` solvers, its implementation is identical to `MARKER_SYM` solvers and both options can be used interchangeably. + +``` +MARKER_EULER = (Euler_Wall1, Euler_Wall2, ...) +``` + +**Note**: Be aware when switching from an Euler solver to a Navier-Stokes one that most solid walls should become `MARKER_HEATFLUX` (and vice versa). + +## Symmetry Wall ## + +| Solver | Version | +| --- | --- | +| `EULER`, `NAVIER_STOKES`, `RANS`, `INC_EULER`, `INC_NAVIER_STOKES`, `INC_RANS`, `FEM_EULER`, `FEM_NAVIER_STOKES` | 7.0.0 | + +A symmetry wall is defined with using the `MARKER_SYM` option. Only the marker name has to be given for this option. + +For all Finite Volume (FVM) solvers, i.e. not the `FEM_*` solvers, its implementation is identical to `MARKER_SYM` solvers and both options can be used interchangeably. + +``` +MARKER_SYM = (Symmetry_Wall1, Symmetry_Wall2, ...) +``` + +## Constant Heatflux (no-slip) Wall ## + +| Solver | Version | +| --- | --- | +| `NAVIER_STOKES`, `RANS`, `INC_NAVIER_STOKES`, `INC_RANS`, `FEM_NAVIER_STOKES`, `HEAT_EQUATION_FVM` | 7.0.0 | + + +A wall with a prescribed constant heatflux is defined with the `MARKER_HEATFLUX` option. The option format is the marker name followed by the value of the heatflux (in Watts per square meter `[W/m^2],[J/(s*m^2)]`), e.g. +``` +MARKER_HEATFLUX = (Wall1, 1e05, Wall2, 0.0) +``` + +**Note**: Typically Navier-Stokes and RANS simulations are setup with adiabatic walls (heatflux = 0). + +## Isothermal (no-slip) Wall ## + +| Solver | Version | +| --- | --- | +| `NAVIER_STOKES`, `RANS`, `INC_NAVIER_STOKES`, `INC_RANS`, `FEM_NAVIER_STOKES`, `HEAT_EQUATION_FVM` | 7.0.0 | + +A wall with a constant temperature is defined with the `MARKER_ISOTHERMAL` option. The option format is the marker name followed by the value of the temperature (in Kelvin `[K]`), e.g. +``` +MARKER_ISOTHERMAL = (Wall1, 300.0, Wall2, 250.0) +``` + +## Farfield Boundary Condition ## + +| Solver | Version | +| --- | --- | +| `EULER`, `NAVIER_STOKES`, `RANS`, `INC_EULER`, `INC_NAVIER_STOKES`, `INC_RANS`, `FEM_EULER`, `FEM_NAVIER_STOKES` | 7.0.0 | + +A marker can be defined as a Farfield boundary by addings its name to the `MARKER_FAR` option. No other values are necesseary for that option. The actual values which will be prescribed depend on the solver and other user input settings. More details can be found in the [Physical Definition](/docs_v7/Physical-Definition/) section. + +``` +MARKER_FAR= (farfield) +``` + +## Inlet Boundary Condition ## +Inlet boundary conditions are set using the option `MARKER_INLET`. + +### Total Conditions ### + +| Solver | Version | +| --- | --- | +| `EULER`, `NAVIER_STOKES`, `RANS`, `FEM_EULER`, `FEM_NAVIER_STOKES` | 7.0.0 | + +To describe the **Total Conditions** at the inlet, set the option `INLET_TYPE= TOTAL_CONDITIONS` (which is the default). The format for `MARKER_INLET` then is the marker name, followed by the Total Temperature (in Kelvin `[K]`), the total Pressure (in Pascal `[Pa]`) and the flow direction unity vector (in meter per second `[m/s]`). For example: +``` +INLET_TYPE= TOTAL_CONDITIONS +MARKER_INLET = (inlet1, 300, 1e6, 1.0, 0.0, 0.0, inlet2, 400, 1e6, 0.0, 1.0, 0.0) +``` + +### Mass Flow Inlet ### + +| Solver | Version | +| --- | --- | +| `EULER`, `NAVIER_STOKES`, `RANS`, `FEM_EULER`, `FEM_NAVIER_STOKES` | 7.0.0 | + +To describe the **Mass Flow** at the inlet, set the option `INLET_TYPE= MASS_FLOW`. The format for `MARKER_INLET` then is the marker name, followed by the Density (in `[kg/m^3`]), the Velocity magnitude (in meter per second `[m/s]`) and the flow direction unity vector (in meter per second `[m/s]`). For example: +``` +INLET_TYPE= MASS_FLOW +MARKER_INLET = (inlet1, 1.13 , 20, 1.0, 0.0, 0.0, inlet2, 1.15, 10, 0.0, 1.0, 0.0) +``` +**Note**: It is not possible to combine Mass Flow Inlet BCs and Total Condition Inlet BCs yet. + +### Velocity Inlet ### + +| Solver | Version | +| --- | --- | +| `INC_EULER`, `INC_NAVIER_STOKES`, `INC_RANS` | 7.0.0 | + +To describe the **Velocity** at the inlet, set the option `INC_INLET_TYPE= VELOCITY_INLET`. The format for `MARKER_INLET` then is the marker name, followed by the Temperature (in Kelvin `[K`]), the Velocity magnitude (in meter per second `[m/s]`) and the flow direction unity vector (in meter per second `[m/s]`). + +``` +INC_INLET_TYPE= VELOCITY_INLET, VELOCITY_INLET +MARKER_INLET = (inlet1, 300 , 20, 1.0, 0.0, 0.0, inlet2, 200, 10, 0.0, 1.0, 0.0) +``` + +### Pressure Inlet ### + +| Solver | Version | +| --- | --- | +| `INC_EULER`, `INC_NAVIER_STOKES`, `INC_RANS` | 7.0.0 | + +To describe the **Total Pressure** at the inlet, set the option `INC_INLET_TYPE= PRESSURE_INLET`. The format for `MARKER_INLET` then is the marker name, followed by the Temperature (in Kelvin `[K]`), the Total Pressure (in Pascal `[Pa]`) and the flow direction unity vector (in meter per second `[m/s]`). + +``` +INC_INLET_TYPE= PRESSURE_INLET, PRESSURE_INLET +MARKER_INLET = (inlet1, 300 , 1e6, 1.0, 0.0, 0.0, inlet2, 200, 1e6, 0.0, 1.0, 0.0) +``` + +**Note 1**: It is possible to combine Velocity Inlet BCs and Pressure Inlet BCs. + +**Note 2**: Updates to the velocity based on the prescribed pressure are damped in order to help with stability/convergence. The damping coefficient can be changed using the `INC_INLET_DAMPING` option (default is `0.1`). + +## Outlet Boundary Condition ## + +Outlet boundary conditions are set using the `MARKER_OUTLET` option. + +### Pressure Outlet (Compressible) ### + +| Solver | Version | +| --- | --- | +| `EULER`, `NAVIER_STOKES`, `RANS`, `FEM_EULER`, `FEM_NAVIER_STOKES` | 7.0.0 | + +To describe the static thermodynamic pressure at an outlet, the format for `MARKER_OUTLET` is the marker name, followed by the value of the static pressure (in Pascal `[Pa]`). + +``` +MARKER_OUTLET = (outlet, 1e5) +``` + +### Pressure Outlet (Incompressible) ### + +| Solver | Version | +| --- | --- | +| `INC_EULER`, `INC_NAVIER_STOKES`, `INC_RANS`| 7.0.0 | + +To describe the pressure at an outlet, set the option `INC_OUTLET_TYPE= PRESSURE_OUTLET`. The format for `MARKER_OUTLET` is the marker name, followed by the value of the gauge pressure (in Pascal `[Pa]`). + +``` +INC_OUTLET_TYPE= PRESSURE_OUTLET +MARKER_OUTLET = (outlet, 1e1) +``` + +**Note**: Gauge pressure is zero-referenced against ambient air pressure, so it is equal to absolute pressure minus atmospheric pressure. + +### Mass Flow Outlet ### + +| Solver | Version | +| --- | --- | +| `INC_EULER`, `INC_NAVIER_STOKES`, `INC_RANS`| 7.0.0 | + +To describe the mass flow at an outlet, set the option `INC_OUTLET_TYPE= MASS_FLOW_OUTLET`. The format for `MARKER_OUTLET` is the marker name, followed by the value of the target mass flow (in kilogramm per second `[kg/s]`). + +``` +INC_OUTLET_TYPE= MASS_FLOW_OUTLET +MARKER_OUTLET = (outlet, 1e1) +``` + +**Note**: Updates to the pressure based on the prescribed mass flow are damped in order to help with stability/convergence. The damping coefficient can be changed using the `INC_OUTLET_DAMPING` option (default is `0.1`). + +### Periodic Boundary Condition ### + +| Solver | Version | +| --- | --- | +| `NAVIER_STOKES`, `RANS`, `INC_NAVIER_STOKES`, `INC_RANS`, `FEM_NAVIER_STOKES` | 7.0.0 | + +## Structural Boundary Conditions ## + +### Clamped Boundary ### + +| Solver | Version | +| --- | --- | +| `ELASTICITY` | 7.0.0 | + +The format for this boundary condition consists of a list of all clamped surfaces (markers). Structural displacements are set to 0 for the nodes on those surfaces. + +``` +MARKER_CLAMPED = (surface_1,...,surface_N) +``` + +**Note**: A well posed structural problem requires at least one surface as `MARKER_CLAMPED` or `MARKER_DISPLACEMENT`. + +### Displacement Boundary ### + +| Solver | Version | +| --- | --- | +| `ELASTICITY` | 7.0.0 | + +The displacements of the nodes on `surface` are enforced, the displacement vector is specified by magnitude and direction (the x/y/z components), internally the solver makes the direction unitary, the multiplier (should usually be set to 1) can be used to increase/decrease the magnitude for example after scaling an existing mesh. +``` +MARKER_DISPLACEMENT = (surface, multiplier, magnitude `[m]`, x component, y component, z component) +``` + +**Note**: Be aware of intersecting surfaces with incompatible displacements, there are shared nodes between adjacent surfaces. + +### Load Boundary ### + +| Solver | Version | +| --- | --- | +| `ELASTICITY` | 7.0.0 | + +A force-like boundary condition but specified in terms of pressure (units of Pa) which is integrated to obtain nodal forces. The syntax is identical to `MARKER_DISPLACEMENT`. +``` +MARKER_LOAD = (surface, multiplier, magnitude `[Pa]`, x component, y component, z component) +``` + +**Note**: In the context of nonlinear elasticity, this is not a following force. + +### Normal Pressure Boundary ### + +| Solver | Version | +| --- | --- | +| `ELASTICITY` | 7.0.0 | + +Normal pressure boundary condition (positive means into the surface). This is a following force both magnitude and direction depend of the deformation of the structure. +``` +MARKER_PRESSURE = (surface, inward pressure `[Pa]`) +``` + diff --git a/_docs_v7/Mesh-File.md b/_docs_v7/Mesh-File.md new file mode 100644 index 00000000..56178220 --- /dev/null +++ b/_docs_v7/Mesh-File.md @@ -0,0 +1,151 @@ +--- +title: Mesh File +permalink: /docs_v7/Mesh-File/ +--- + +SU2 mainly uses a native mesh file format as input into the various suite components. Support for the CGNS data format has also been included as an input mesh format. CGNS support can be useful when it is necessary to create complex geometries in a third-party mesh generation package that can export CGNS files. A converter from CGNS to the native format is also built into SU2. Details on how to create and use these mesh formats is given below. + +--- + +## Content ## + +- [SU2 Native Format (.su2)](#su2-native-format-su2) + - [Description](#description) + - [Specification](#specification) + - [Examples](#examples) +- [CGNS Format](#cgns-format) + - [Compiling with CGNS Support](#compiling-with-cgns-support) + - [Using and Converting CGNS Meshes](#using-and-converting-cgns-meshes) +- [Third-Party Mesh Software](#third-party-mesh-software) + +--- + +## SU2 Native Format (.su2) + + In keeping with the open-source nature of the project, SU2 features its own native mesh format. The format is meant to be simple and readable. A description of the mesh and some examples are below. + +### Description + +The SU2 mesh format carries an extension of .su2, and the files are in a readable ASCII format. As an unstructured code, SU2 requires information about both the node locations as well as their connectivity. The connectivity description provides information about the types of elements (triangle, rectangle, tetrahedron, hexahedron, etc.) that make up the volumes in the mesh and also which nodes make up each of those elements. Lastly, the boundaries of the mesh, or _markers_, are given names, or tags, and their connectivity is specified in a similar manner as the interior nodes. + +### Specification + +Consider the following simple, 2D mesh for a square domain consisting of 8 triangular elements. It will be used to explain the .su2 mesh format. + +![Square Mesh Example](../../docs_files/square.png) + +**Square Mesh Example: Note that the figure uses Tecplot node and element number (1-based). The node and element numbering for SU2 start at 0.** + +The first line of the .su2 mesh declares the dimensionality of the problem. SU2 can handle 2D or 3D geometries. As a note, for 2D simulations, it is recommended that a truly 2D mesh is used (no z-coordinates) rather than a quasi-2D mesh (one or more cells deep in the third dimension with symmetry boundary conditions). For the 2D square mesh, the dimension is defined as follows: + +``` +NDIME= 2 +``` + +SU2 searches specifically for the keyword `NDIME=` in order to set the dimension, and the dimension value will be stored for use throughout the code. This value would be 3 for a 3D mesh. Note that while "%" is used here to denote comments, SU2 does not officially recognize it as such. Extra text added to the mesh file between sections (such as lines following a "%") will simply be ignored. + +To specify the point list, SU2 first searches for the string `NPOIN=` and stores the total number of nodes in the mesh. This value is given first, as it is used to set up a loop over all of the grid points that must immediately follow this line. Then, the coordinates for each of the nodes are given. This is specified in the .su2 format as: + +``` +NPOIN= 9 +0.00000000000000 0.00000000000000 +0.50000000000000 0.00000000000000 +1.00000000000000 0.00000000000000 +0.00000000000000 0.50000000000000 +0.50000000000000 0.50000000000000 +1.00000000000000 0.50000000000000 +0.00000000000000 1.00000000000000 +0.50000000000000 1.00000000000000 +1.00000000000000 1.00000000000000 +``` + +In this case, there are 9 nodes in the 3x3 square above. Immediately after the node number specification comes the list of node coordinates in cartesian space. Each line gives the coordinates for a single grid vertex. The grid points are assigned a global element index of 0 through 8 in the order they appear in the file. This global element index is implied by the ordering and does not need to be explicitly specified by the file, although some legacy meshes may still contain an explicit index at the end of the line that can be ignored. + +For a 2D mesh, only x and y coordinates are required, but a 3D mesh would give x, y, and z coordinates. The global index values for the nodes and elements stored within SU2 are zero-based, as opposed to starting from 1 as Tecplot does. The global index numbering of the nodes is implicit in the order they are given in the file. For example, the point (0.0,0.0), the first in the list given in the mesh file, will carry global index 0, the point (0.5,0.0) carries global index 1, and so on. Therefore, the location of each node in the list above can be confirmed in space by adding 1 to the implied global index from the ordering and comparing with the figure above. + +The next part of the file describes the interior element connectivity, which begins with the `NELEM=` keyword: + +``` +NELEM= 8 +5 0 1 3 +5 1 4 3 +5 1 2 4 +5 2 5 4 +5 3 4 6 +5 4 7 6 +5 4 5 7 +5 5 8 7 +``` + +SU2 is based on unstructured mesh technology, and thus supports several element types for both 2D and 3D elements. Unlike for structured meshes where a logical, ordered indexing can be assumed for neighboring nodes and their corresponding cells (quadrilaterals in 2D and hexahedral elements in 3D), for an unstructured mesh, a list of nodes that make up each element, or the connectivity as it is often called, must be provided. First, SU2 will search for the string `NELEM=` and then store the number of interior elements. This value is given first, as it is used to set up a loop over all of the elements which must immediately follow this line. For the square mesh above, this corresponds to the 8 triangular interior elements that are assigned a global element index of 0 through 7 in the order they appear in the file. This global element index is implied by the ordering and does not need to be explicitly specified by the file, although some legacy meshes may still contain an explicit index at the end of the line that can be ignored. + +Each following line describes the connectivity of a single element. The first integer on each line is a unique identifier for the type of element that is described. SU2 supports line, triangle, quadrilateral, tetrahedral, pyramid, prism, and hexahedral elements. The identifiers follow the VTK format: + + +|Element Type | Identifier | +--------------|------------| +|Line | 3| +|Triangle |5| +|Quadrilateral |9| +|Tetrahedral |10| +|Hexahedral |12| +|Prism |13| +|Pyramid |14| + +In our square mesh, all elements are triangles, and thus the identifier (first integer) on all lines is 5. Following the identifier is a list of the node indices that make up the element. Each triangular element will have 3 nodes specified, a rectangular element would have 4 nodes specified, a tetrahedral element would have 4 nodes specified, and so on. Note again that the global index values for the nodes and elements stored within SU2 are zero-based, as opposed to starting from 1 as Tecplot does, which was used to create the mesh image. For example, take the triangular element described in the first line, which would be indexed as 0 in SU2 (1 in Tecplot). The SU2 nodes are given as (0,1,3) which would correspond to (1,2,4) in Tecplot. Looking at the figure of the mesh above, we see that this is the lower left triangular element. The ordering of the nodes given in the connectivity list for a specific element is important, and the user is referred to the VTK format guide for the correct ordering for each supported element type (page 9). + +The final component of the mesh is a description of all boundaries (which we call markers), including a name (what we call a tag). For each boundary, the connectivity information is specified using the same node global index values given above. For a 2D mesh, only line elements are supported along the boundaries. For a 3D mesh, triangular and quadrilateral elements are the possible options for boundary elements. This section of the .su2 mesh file appears as: + +``` +NMARK= 4 +MARKER_TAG= lower +MARKER_ELEMS= 2 +3 0 1 +3 1 2 +MARKER_TAG= right +MARKER_ELEMS= 2 +3 2 5 +3 5 8 +MARKER_TAG= upper +MARKER_ELEMS= 2 +3 8 7 +3 7 6 +MARKER_TAG= left +MARKER_ELEMS= 2 +3 6 3 +3 3 0 +``` + +First, the number of boundaries, or markers, is specified using the "NMARK=" string. Then for each marker, a name, or tag, is specified using "MARKER_TAG=." This tag can be any string name, and the tag name is used in the configuration file for the solver when specifying boundary conditions. Here, the tags "lower," "right," "upper," and "left" would be used. The number of elements on each marker, using "MARKER_ELEMS=," must then be specified before listing the connectivity information as is done for the interior mesh elements at the start of the file. Again, the unique VTK identifier is given at the start of each line followed by the node list for that element. For our example, only line elements (identifier 3) exist along the markers, and on each boundary of the square there are 2 edges of a triangle that make up the marker. These elements can again be verified with the mesh figure above. + +### Examples + Attached here is the simple square mesh from above in .su2 format, along with codes for creating this file in the Python, C++, and Fortran 90 programming languages. These scripts are meant to be examples of how to write .su2 meshes in a few common languages which can be easily modified for creating new meshes: + +- Square mesh: [square.su2](../../docs_files/square.su2) +- Python square mesh generator: [square.py](../../docs_files/square.py) +- C++ square mesh generator: [square.cpp](../../docs_files/square.cpp) +- Fortran 90 square mesh generator: [square.f90](../../docs_files/square.f90) + +## CGNS Format + +To make creating your own meshes easier and more accessible, support for the open CGNS data standard has been included within SU2. The main advantage gained is that complex meshes created in a third-party software package (one that supports unstructured, single-zone CGNS file export in ADF format) can be used directly within SU2 without the need for conversion to the native format. Moreover, as CGNS is a binary format, the size of the mesh files can be significantly reduced. + +### Compiling with CGNS Support + +Starting with SU2 v4.3, the source code of the CGNS library is shipped with SU2 in the externals/ directory, and it is automatically built and linked for you when compiling SU2 (ADF support only). + +### Using and Converting CGNS Meshes + +In order to use a CGNS mesh (assuming the CGNS library has been installed and SU2 successfully compiled), the user simply needs to specify the input mesh format to be "CGNS" in the configuration file for their simulation. The configuration file option is "MESH_FORMAT=" and appears as: + +``` +MESH_FORMAT= CGNS +``` + +It is important to note that SU2 will not use any specific boundary conditions that are embedded within the CGNS mesh. However, it *will* use the names given to each boundary as the marker tags. These marker tags are used to set the boundary conditions in the configuration file. Therefore, it is recommended that the user give names to each boundary in their mesh generation package before exporting to CGNS. If you do not know the number of markers or their tags within a CGNS file, you can simply attempt a simulation in SU2_CFD (leaving out the boundary information in the configuration file at first), and during the preprocessing stage, SU2 will read and print the names of all boundary markers to the console along with other grid information before throwing an error due to incomplete boundary definitions. The user can then incorporate these marker tags into the configuration file with the appropriate boundary conditions. + + If needed, a converter from CGNS to the SU2 format has been built into SU2 (See the [inviscid wedge tutorial](../tutorials/Inviscid_Wedge)). + +## Third-Party Mesh Software + +We are continuously working to integrate SU2 with industry-standard tools. The latest releases of the Pointwise meshing software can both export and import meshes in the native ASCII SU2 format. In addition, a number of other packages support direct output to the SU2 format, such as GMSH and CENTAUR. CGNS files created by a number of other meshing packages have been successfully tested and used, such as those from ICEM CFD, for instance. diff --git a/_docs/Multizone.md b/_docs_v7/Multizone.md similarity index 93% rename from _docs/Multizone.md rename to _docs_v7/Multizone.md index 6937c043..5c66656d 100644 --- a/_docs/Multizone.md +++ b/_docs_v7/Multizone.md @@ -1,10 +1,23 @@ --- title: Basics of Multi-Zone Computations -permalink: /docs/Multizone +permalink: /docs_v7/Multizone/ --- SU2 is capable of solving physical problems in distinct zones coupled through interfaces. Applications range from Fluid-Fluid coupling (e.g. using a sliding mesh approach) over Conjugate-Heat-Transfer to Fluid-Structure Interactions problems. The following section gives an overview on the general terminology for multizone computations and how you can make use of these features. For specific problem-related options, please refer to the Tutorials. +--- + +## Content ## + +- [What is Zone ?](#what-is-a-zone-) +- [Multi-zone and Multi-physics](#multi-zone-and-multi-physics) + - [How to set up a single-physics Problem](#how-to-set-up-a-single-physics-problem) + - [Sub-config files](#sub-config-files) + - [How to set up a multi-physics Problem](#how-to-set-up-a-multi-physics-problem) + - [Providing mesh information for a multi-zone problem](#providing-mesh-information-for-a-multi-zone-problem) + +--- + ## What is a Zone ? ## We refer to a Zone as a subdomain in your physical problem. For example consider a heated cylinder immersed into a fluid. In this case, the solid cylinder would be refered to as zone 0 and the fluid domain as zone 1. All zones can be discretized independently and do not need to be matching at the interfaces. See the figure below. diff --git a/_docs_v7/Physical-Definition.md b/_docs_v7/Physical-Definition.md new file mode 100644 index 00000000..0cdf462d --- /dev/null +++ b/_docs_v7/Physical-Definition.md @@ -0,0 +1,101 @@ +--- +title: Physical Definition +permalink: /docs_v7/Physical-Definition/ +redirect_from: /docs/Physical-Definition/ +--- + +The physical definition of a case includes the definition of the free-stream, the reference values and the non-dimensionalization. +SU2 offers different ways of setting and computing this definition. This document gives a short overview on the config options and their physical relation. + +--- + +## Content ## + +- [Reference Values](#reference-values) +- [Free-stream Definition (Compressible)](#free-stream-definition-compressible) + - [Thermodynamic State](#thermodynamic-state) + - [Mach Number and Velocity](#mach-number-and-velocity) + - [Reynolds Number and Viscosity](#reynolds-number-and-viscosity) + - [Non-Dimensionalization](#non-dimensionalization) +- [Flow Condition (Incompressible)](#flow-condition-incompressible) + - [Thermodynamic and Gauge Pressure](#thermodynamic-and-gauge-pressure) + - [Initial State and Non-Dimensionalization](#initial-state-and-non-dimensionalization) + +--- + +## Reference Values ## + +| Solver | Version | +| --- | --- | +| `EULER`, `NAVIER_STOKES`, `RANS`, `INC_EULER`, `INC_NAVIER_STOKES`, `INC_RANS`, `FEM_EULER`, `FEM_NAVIER_STOKES` | 7.0.0 | + +The following table depicts the reference values used by most of the solvers in SU2. The highlighted variables vary depending on the actual solver and the user input. + + +| Variable | Unit | Reference | +|---|---|---| +| Length | $$m$$ | $$l_{ref} = 1$$ | +| **Density** | $$\frac{kg}{m^3}$$ | $$\rho_{ref}$$ (based on user input) | +| **Velocity** | $$\frac{m}{s}$$ | $$v_{ref}$$ (based on user input)| +| **Temperature** | $$K$$ | $$T_{ref}$$ (based on user input) | +| **Pressure** | $$Pa$$ | $$p_{ref}$$ (based on user input) | +| Viscosity | $$\frac{kg}{ms}$$ | $$\mu_{ref} = \rho_{ref}v_{ref}l_{ref}$$ | +| Time | $$s$$ | $$t_{ref} = \frac{l_{ref}}{v_{ref}}$$ | +| Heatflux | $$\frac{W}{m^2}$$ | $$Q_{ref} = \rho_{ref}v^3_{ref} $$ | +| Gas Constant | $$\frac{m^2}{s^2 K}$$ | $$R_{ref} = \frac{v^2_{ref}}{T_{ref}}$$| +| Conductivity | $$\frac{W}{mK}$$ | $$k_{ref} = \mu_{ref}R_{ref}$$ | +| Force | $$N$$ | $$ F_{ref} = \rho_{ref}v^2_{ref}l^2_{ref} $$ | + + +## Free-Stream Definition (Compressible) ## + +| Solver | Version | +| --- | --- | +| `EULER`, `NAVIER_STOKES`, `RANS`,`FEM_EULER`, `FEM_NAVIER_STOKES` | 7.0.0 | + +The physical definition for the compressible solvers in SU2 based around the definition of the free-stream. The free-stream values are not only used as boundary conditions for the `MARKER_FAR` option, but also for initialization and non-dimensionalization. That means even if you don't have any farfield BCs in your problem, it might be important to prescribe physically meaningful values for the options. + +### Thermodynamic State ### + +The thermodynamic state of the free-stream is defined by the pressure $$p_{\infty}$$, the density $$\rho_{\infty}$$ and the temperature $$T_{\infty}$$. Since these quantities are not independent, only two of these values have to be described and the third one can be computed by an equation of state, depending on the fluid model used. There are two possible ways implemented that can be set using `FREESTREAM_OPTION`: + +- `TEMPERATURE_FS` (default): Density $$\rho_{\infty}$$ is computed using the specified pressure $$p_{\infty}$$ (`FREESTREAM_PRESSURE`) and temperature $$T_{\infty}$$ (`FREESTREAM_TEMPERATURE`). +- `DENSITY_FS`: Temperature $$T_{\infty}$$ is computed using the specified pressure $$p_{\infty}$$ (`FREESTREAM_PRESSURE`) and density $$\rho_{\infty}$$ (`FREESTREAM_DENSITY`). + +### Mach Number and Velocity ### + +The free-stream velocity $$v_{\infty}$$ is always computed from the specified Mach number $$Ma_{\infty}$$ (`MACH_NUMBER`) and the computed thermodynamic state. The flow direction is based on the angle of attack (`AOA`) and the side-slip angle (`SIDESLIP_ANGLE`, for 3D). + +### Reynolds Number and Viscosity ### + +If it is a viscous computation, by default the pressure $$p_{\infty}$$ will be recomputed from a density $$\rho_{\infty}$$ that is found from the specified Reynolds number $$Re$$ (`REYNOLDS_NUMBER`). Note that for an ideal gas this does not change the Mach number $$Ma_{\infty}$$ as it is only a function of the temperature $$T_{\infty}$$. If you still want to use the thermodynamic state for the free-stream definition, set the option `INIT_OPTION` to `TD_CONDITIONS` (default: `REYNOLDS`). In both cases, the viscosity is computed from the dimensional version of Sutherland's law or the constant viscosity (`FREESTREAM_VISCOSITY`), depending on the `VISCOSITY_MODEL` option. + +### Non-Dimensionalization ### + +For all schemes, as reference values for the density and temperature the free-stream values are used, i.e. $$ \rho_{ref} = \rho_{\infty}, T_{ref} = T_{\infty}$$. The reference velocity is based on the speed of sound defined by the reference state: $$v_{ref} = \sqrt{\frac{p_{ref}}{\rho_{ref}}}$$. The dimensionalization scheme can be set using the option `REF_DIMENSIONALIZATION` and defines how the reference pressure $$p_{ref}$$ is computed: + +- `DIMENSIONAL`: All reference values are set to `1.0`, i.e. the computation is dimensional. +- `FREESTREAM_PRESS_EQ_ONE`: Reference pressure equals free-stream pressure, $$p_{ref} = p_{\infty}$$. +- `FREESTREAM_VEL_EQ_MACH`: Reference pressure is chosen such that the non-dimensional free-stream velocity equals the Mach number: $$p_{ref} = \gamma p_{\infty}$$. +- `FREESTREAM_VEL_EQ_ONE`: Reference pressure is chosen such that the non-dimensional free-stream velocity equals `1.0`: $$p_{ref} = Ma^2_{\infty} \gamma p_{\infty}$$. + +## Flow Condition (Incompressible) ## + +| Solver | Version | +| --- | --- | +| `INC_EULER`, `INC_NAVIER_STOKES`, `INC_RANS` | 7.0.0 | + +The physical definition of the incompressible solvers is accomplished by setting an appropriate flow condition for initialization and non-dimensionalization. SU2 solves the [incompressible Navier-Stokes equations](/docs_v7/Theory/#incompressible-rans) in a general form allowing for variable density due to heat transfer through the low-Mach approximation (or incompressible ideal gas formulation). + +### Thermodynamic and Gauge Pressure ### + +In the incompressible problem the thermodynamic pressure is decoupled from the governing equations and density is therefore only a function of temperature variations. The absolute value of the pressure is not important and any reference to the pressure $$p$$ is considered as the gauge value, i.e. it is zero-referenced against ambient air pressure, so it is equal to absolute pressure minus (an arbitrary) atmospheric pressure. + +### Initial State and Non-Dimensionalization ### + +The initial state, i.e. the initial values of density $$\rho_0$$, velocity vector $$\bar{v}_{0}$$ and temperature $$T_0$$ are set with `INC_DENSITY_INIT`, `INC_VELOCITY_INIT` and `INC_TEMPERATURE_INIT`, respectively. The initial pressure $$p_0$$ is always set to `0.0`. + +The reference values $$\rho_{ref}, T_{ref}, v_{ref}$$ equal the initial state values by default (or if `INC_NONDIM= INITIAL_VALUES`). If `INC_NONDIM` is set to `REFERENCE_VALUES` you can define different values for them using the options `INC_DENSITY_REF`, `INC_VELOCITY_REF` and `INC_TEMPERATURE_REF`. The reference pressure is always computed by $$p_{ref} = \rho_{ref}v^2_{ref}$$. + +**Note:** The initial state is also used as boundary conditions for `MARKER_FAR`. + diff --git a/_docs_v7/Post-processing.md b/_docs_v7/Post-processing.md new file mode 100644 index 00000000..83546186 --- /dev/null +++ b/_docs_v7/Post-processing.md @@ -0,0 +1,22 @@ +--- +title: Post-processing +permalink: /docs_v7/Post-processing/ +--- + +SU2 is capable of outputting solution files and other result files that can be visualized in a number of formats, including ParaView (.vtk), Tecplot (.dat for ASCII, .plt for binary), CGNS (.cgns), comma-separated values (.csv), or STL (.stl) depending on the problem. + +At the end of each simulation (or at a a frequency specified by the user), SU2 will output several files that contain all of the necessary information for post-processing of results, visualization, and a restart. **Note that when the code is compiled and running in parallel, only restart files will be generated during runtime to avoid overheads.** The restart files can then be used as input to generate the visualization files using SU2_SOL. This will be done automatically if the parallel_computation.py script is used, but it can also be done manually at any time by calling SU2_SOL. In fact, this offers additional flexibility, as solution files in multiple formats can always be generated/regenerated as long as the original mesh and a restart file are available. SU2_SOL can be called from the command line like any of the other modules, in serial or parallel. + +For a PDE analysis (direct solution), these files might look like the following: +- **flow.dat** or **flow.vtk**: full volume flow solution. +- **surface_flow.dat** or **surface_flow.vtk**: flow solution along the surface of the geometry. +- **surface_flow.csv**: comma-separated values (.csv) file containing values along the surface of the geometry. +- **history.dat** or **history.csv**: file containing the convergence history information. +- **restart_flow.dat**: restart file in an internal format for restarting simulations in SU2. Contains the flow solution at each node (description below). + +For adjoint solutions, the file names are slightly different and depend on the particular objective chosen: +- **adjoint.dat** or **adjoint.vtk**: full volume adjoint solution. +- **surface_adjoint.dat** or **surface_adjoint.vtk**: adjoint solution along the surface of the geometry. +- **surface_adjoint.csv**: comma-separated values (.csv) file containing values along the surface of the geometry. +- **history.dat** or **history.csv**: file containing the convergence history information. +- **restart_adj_cd.dat**: readable restart file in an internal format for restarting this simulation in SU2. Note that the name of the objective appears in the file name. In this example, it is the coefficient of drag. diff --git a/_docs_v7/Quick-Start.md b/_docs_v7/Quick-Start.md new file mode 100644 index 00000000..07ef8d8a --- /dev/null +++ b/_docs_v7/Quick-Start.md @@ -0,0 +1,123 @@ +--- +title: Quick Start +permalink: /docs_v7/Quick-Start/ +--- + +![NACA 0012 Pressure](../../docs_files/naca0012_pressure.png) + +## Introduction + +Welcome to the Quick Start Tutorial for the SU2 software suite. This tutorial is intended to demonstrate some of the key features of the analysis and design tools in an easily accessible format. Completion of this tutorial only requires a few minutes. If you haven't done so already, please visit the [Download](/download.html) and [Installation](/docs_v7/Installation/) pages to obtain the most recent stable release of the software and details for installation. This tutorial requires only the SU2_CFD tool from the SU2 suite. + +## Goals +Upon completing this simple tutorial, the user will be familiar with performing the flow and continuous adjoint simulation of external, inviscid flow around a 2D geometry and be able to plot both the flow solution and the surface sensitivities that result. The specific geometry chosen for the tutorial is the NACA 0012 airfoil. Consequently, the following capabilities of SU2 will be showcased in this tutorial: + +- Steady, 2D, Euler and Continuous Adjoint Euler equations +- Multigrid +- JST numerical scheme for spatial discretization +- Euler implicit time integration +- Euler Wall and Farfield boundary conditions + +## Resources + +The files necessary to run this tutorial are included in the SU2/QuickStart/ directory. For the other tutorials, the files will be found in the TestCases/ repository. Two files are needed as input to the code: a configuration file describing the options for the particular problem, and the corresponding computational mesh file. The files are in QuickStart/ and can also be found in the TestCases repository under TestCases/euler/naca0012. + +## Tutorial + +The following tutorial will walk you through the steps required to compute the flow and adjoint solutions around the NACA 0012 airfoil using SU2. Again, we assume that you have already obtained and compiled the SU2_CFD code (either individually, or as part of the complete SU2 package) for a serial computation. If you have yet to complete this requirement, please see the [Download](/download.html) and [Installation](/docs_v7/Installation) pages. + +### Background + +The NACA0012 airfoil is one of the four-digit wing sections developed by the National Advisory Committee for Aeronautics (NACA), and it is a widely used geometry for many CFD test cases. The numbering system is such that the first number indicates the maximum camber (in percent of chord), the second shows the location of the maximum camber (in tens of percent of chord) and the last two digits indicate the maximum thickness (in percent of chord). More information on these airfoil sections can be found here or in the book 'Theory of Wing Sections' by Abbott and von Doenhoff. + +### Problem Setup + +This problem will solve the Euler equations on the NACA0012 airfoil at an angle of attack of 1.25 degrees, using air with the following freestream conditions: + +- Pressure = 101,325 Pa +- Temperature = 273.15 K +- Mach number = 0.8 + +The aim is to find the flow solution and the adjoint solution with respect to an objective function defined as the drag on the airfoil. + +### Mesh Description + +The unstructured mesh provided is in the native .su2 format. It consists of 10,216 triangular cells, 5,233 points, and two boundaries (or "markers") named *airfoil* and *farfield*. The airfoil surface uses a flow-tangency Euler wall boundary condition, while the farfield uses a standard characteristic-based boundary condition. The figure below gives a view of the mesh. + +![NACA 0012 Mesh](../../docs_files/naca0012_mesh.png) + +Figure (1): Far-field and zoom view of the computational mesh. + +### Configuration File Options + +Aside from the mesh, the only other file required to run the SU2_CFD solver details the configuration options. It defines the problem, including all options for the numerical methods, flow conditions, multigrid, etc., and also specifies the names of the input mesh and output files. In keeping simplicity for this tutorial, only two configuration options will be discussed. More configuration options will be discussed throughout the remaining tutorials. + +Upon opening the inv_NACA0012.cfg file in a text editor, one of the early options is the MATH_PROBLEM: +``` +% Mathematical problem (DIRECT, CONTINUOUS_ADJOINT, DISCRETE_ADJOINT) +MATH_PROBLEM= DIRECT +``` +SU2 is capable of running the direct and adjoint problems for several sets of equations. The direct analysis solves for the flow around the geometry, and quantities of interest such as the lift and drag coefficient on the body will be computed. Solving the adjoint problem leads to an efficient method for obtaining the change in a single objective function (e.g., the drag coefficient) relative to a large number of design variables (surface deformations). The direct and adjoint solutions often couple to provide the objective analysis and gradient information needed by an optimizer when performing aerodynamic shape design. In this tutorial, we will perform DIRECT and CONTINUOUS_ADJOINT solutions for the NACA 0012 airfoil. + +The user can also set the format for the solution files: +``` +% Output file format +OUTPUT_FILES= (RESTART, TECPLOT, SURFACE_TECPLOT) +``` +SU2 can output solution files in the .vtk (ParaView), .dat (Tecplot ASCII), and .szplt (Tecplot binary) formats which can be opened in the ParaView and Tecplot visualization software packages, respectively. We have set the file type to TECPLOT in this tutorial by, but users without access to Tecplot are encouraged to download and use the freely available [ParaView](http://www.paraview.org) package. To output solution files for ParaView, set the `OUTPUT_FILES` option to `(RESTART, PARAVIEW, SURFACE_PARAVIEW)` which is the default value if the option is not present. + +### Running SU2 + +The first step in this tutorial is to solve the Euler equations: + 1. Either navigate to the QuickStart/ directory or create a directory in which to run the tutorial. If you have created a new directory, copy the config file (inv_NACA0012.cfg) and the mesh file (mesh_NACA0012_inv.su2) to this directory. + 2. Run the executable by entering `SU2_CFD inv_NACA0012.cfg` at the command line. If you have not set the $SU2_RUN environment variable you will need to run `../bin/SU2_CFD inv_NACA0012.cfg` (from the QuickStart directory) or use the appropriate path to your SU2_CFD executable at the command line. + 3. SU2 will print residual updates with each iteration of the flow solver, and the simulation will finish after reaching the specified convergence criteria. + 4. Files containing the flow results (with "flow" in the file name) will be written upon exiting SU2. The flow solution can be visualized in ParaView (.vtk) or Tecplot (.dat or .szplt). More specifically, these files are: + - **flow.szplt** or **flow.vtk** - full volume flow solution. + - **surface_flow.szplt** or **surface_flow.vtk** - flow solution along the airfoil surface. + - **surface_flow.csv** - comma separated values (.csv) file containing values along the airfoil surface. + - **restart_flow.dat** - restart file in an internal format for restarting this simulation in SU2. + - **history.dat** or **history.csv** - file containing the convergence history information. + +Next, we want to run the adjoint solution to get the sensitivity of the objective function (the drag over the airfoil) to conditions within the flow: + 1. Open the config file and change the parameter `MATH_PROBLEM` from `DIRECT` to `CONTINUOUS_ADJOINT`, and save this file. + 2. Rename the restart file (restart_flow.dat) to "solution_flow.dat" so that the adjoint code has access to the direct flow solution. + 3. Run the executable again by entering `SU2_CFD inv_NACA0012.cfg` at the command line. + 4. SU2 will print residual updates with each iteration of the adjoint solver, and the simulation will finish after reaching the specified convergence criteria. + 5. Files containing the adjoint results (with "adjoint" in the file name) will be written upon exiting SU2. The flow solution can be visualized in ParaView (.vtk) or Tecplot (.dat or .szplt). More specifically, these files are: + - **adjoint.szplt** or **adjoint.vtk** - full volume adjoint solution. + - **surface_adjoint.szplt** or **surface_adjoint.vtk** - adjoint solution along the airfoil surface. + - **surface_adjoint.csv** - comma separated values (.csv) file containing values along the airfoil surface. + - **restart_adj_cd.dat** - restart file in an internal format for restarting this simulation in SU2. Note that the name of the objective appears in the file name. + - **history.dat** or **history.csv** - file containing the convergence history information. + +Note that as of SU2 v4.1, you can also compute a discrete adjoint for the Euler equations. Assuming that you have built the code with [algorithmic differentiation support](/docs_v7/Build-SU2-From-Source/#basic-configuration), you can run the discrete adjoint with the following steps instead: + 1. Open the config file and change the parameter `MATH_PROBLEM` from `DIRECT` to `DISCRETE_ADJOINT`, and save this file. + 2. Rename the restart file (restart_flow.dat) to "solution_flow.dat" so that the adjoint code has access to the direct flow solution. + 3. Run the executable again by entering `SU2_CFD_AD inv_NACA0012.cfg` at the command line. Note that the `SU2_CFD_AD` executable will only be available when the source has been compiled with AD support. + +### Results + +The following figures were created in Tecplot using the SU2 results. These results are contained in the flow.dat, surface_flow.dat, adjoint.dat, and surface_adjoint.dat files. + +#### Flow Solution + +![NACA 0012 Pressure](../../docs_files/naca0012_pressure.png) + +Figure (2): Pressure contours around the NACA 0012 airfoil. + +![NACA 0012 Pressure Distribution](../../docs_files/naca0012_cp.png) + +Figure (3): Coefficient of pressure distribution along the airfoil surface. Notice the strong shock on the upper surface (top line) and a weaker shock along the lower surface (bottom line). + +#### Adjoint Solution + +![NACA 0012 Adjoint Density](../../docs_files/naca0012_psirho.png) + +Figure (4): Contours of the adjoint density variable. + +![NACA 0012 Surface Sensitivity](../../docs_files/naca0012_sensitivity.png) + +Figure (5): Surface sensitivities. The surface sensitivity is the change in the objective function due to an infinitesimal deformation of the surface in the local normal direction. These values are calculated at each node on the airfoil surface from the flow and adjoint solutions at negligible computational cost using an additional step not described in this tutorial. + +Congratulations! You've successfully performed your first flow simulations with SU2. Move on to the [tutorials](https://su2code.github.io/tutorials/home) to learn much more about using the code, and don't forget to read through the information in the user's guide. Having problems with the quick start or visualizing the results? Visit the [FAQs](/docs_v7/FAQ) page, or see our forum at [CFD-online](http://www.cfd-online.com/Forums/su2/). diff --git a/_docs_v7/Restart-File.md b/_docs_v7/Restart-File.md new file mode 100644 index 00000000..5ee20b21 --- /dev/null +++ b/_docs_v7/Restart-File.md @@ -0,0 +1,11 @@ +--- +title: Restart File +permalink: /docs_v7/Restart-File/ +--- + +The SU2 binary restart format has the extension `.dat`, but it is also possible to write out restart files in a simple ASCII file format with extension `.csv`. Have a look at the [Output section](/docs_v7/Custom-Output/) to learn how to change output file formats. + +The restart files are used to restart the code from a previous solution and also to run the adjoint simulations, which require a flow solution as input. In order to run an adjoint simulation, the user must first change the name of the `restart_flow.dat` file (or `restart_flow.csv` if ASCII format) to `solution_flow.dat` (or `solution_flow.csv`) in the execution directory (these default file names can be adjusted in the config file). It is important to note that the adjoint solver will create a different adjoint restart file for each objective function, e.g. `restart_adj_cd.dat`. + +To restart a simulation the `RESTART_SOL` flag should be set to `YES` in the configuration file. If performing an unsteady restart the `RESTART_ITER` needs to be set to the iteration number which you want to restart from. For instance if we want to restart at iteration 100 and run the unsteady solver with 2nd-order dual time stepping method, we will need to specify `RESTART_ITER = 100` and have the restart files `solution_flow_00098.dat` and `solution_flow_00099.dat`. + diff --git a/_docs_v7/Running-Regression-Tests.md b/_docs_v7/Running-Regression-Tests.md new file mode 100644 index 00000000..333bfe68 --- /dev/null +++ b/_docs_v7/Running-Regression-Tests.md @@ -0,0 +1,19 @@ +--- +title: Running Regression Tests +permalink: /docs_v7/Running-Regression-Tests/ +--- + +The regression tests can be run on your local machine by using the Python scripts available in the SU2/TestCases/ directory and the mesh files from the su2code/TestCases repository. See the [Test Cases](/docs_v7/Test-Cases/) page for more information on working with the TestCases repo. + +When you are ready to combine your modifications into the develop branch, creating a pull request will automatically run these same regression tests on the Travis CI system. Your pull request must pass these tests in order to be merged into the develop branch. In the pull request, you will be able to see the state of the tests, and by clicking on links find the details of the test results. + +If you are working with a forked version of the repository, you can use the following directions to run these same regression tests within your repository rather than within the su2code/ repository. This is preferable if you are not ready to submit your code to the develop branch and just want to run the tests, or if you want to create your own regression tests. + +1. Modify the travis.yml file in the develop branch to update the ***email address*** and ***repository url***. At this point you can also modify which branch will have the tests run. Commit the change to your fork/develop. +2. Sign up for Travis CI and allow access to your account. +3. Activate the repository within Travis CI. +4. Modify the "README" file in the SU2/ directory such that the url points to the results for your fork rather than su2code/SU2. +5. Commit the result into your fork/develop. +6. View the results: when you open up your fork/develop on github the readme file should display. There will be a colored link going to the travis CI build which state whether the test is building, passing, or failing. This link will lead to the details of the tests. Pull requests between your fork/develop and any branches you have created on your fork will also run regression tests. + +If the tests do not run at first, double check that the repository is activated within Travis CI, and if so push a commit with some small change to the travis.yml file to your repository. If it still doesn't work, double check your urls and refer to Travis CI help menu. diff --git a/_docs_v7/Software-Components.md b/_docs_v7/Software-Components.md new file mode 100644 index 00000000..7fd6e00b --- /dev/null +++ b/_docs_v7/Software-Components.md @@ -0,0 +1,40 @@ +--- +title: Software Components +permalink: /docs_v7/Software-Components/ +--- + +The SU2 software suite is composed of a set of C++ based software modules that perform a wide range of CFD analysis and PDE-constrained optimization tasks. An overall description of each module is included below to give perspective on the suite's capabilities, while more details can be found in the Developer's Guide. Some modules can be executed individually, most notably SU2_CFD to perform high-fidelity analysis, but the real power of the suite lies in the coupling of the modules to perform complex activities, including design optimization and adaptive grid refinement, among others. + +A key feature of the C++ modules is that each has been designed to separate functionality as much as possible and to leverage the advantages of the class-inheritance structure of the programming language. This makes SU2 an ideal platform for prototyping new numerical methods, discretization schemes, governing equation sets, mesh perturbation algorithms, adaptive mesh refinement schemes, parallelization schemes, etc. You simply need to define a new subclass and get down to business. This philosophy makes SU2 quickly extensible to a wide variety of PDE analyses suited to the needs of the user, and work is ongoing to incorporate additional features for future SU2 releases. +The key C++ and Python tools in the SU2 software suite are briefly described below for the current release, but note that modules may be added and removed with future development. + +## C++ Software Modules + +- **SU2_CFD (Computational Fluid Dynamics Code)**: Solves direct, adjoint, and linearized problems for the Euler, Navier-Stokes, and Reynolds-Averaged Navier-Stokes (RANS) equation sets, among many others. SU2_CFD can be run serially or in parallel using MPI. It uses a Finite Volume Method (FVM), and an edge-based structure. A Discontinuous-Galerkin Finite Element Method solver is currently being completed and will be available to the public in an upcoming release. Explicit and implicit time integration methods are available with centered or upwinding spatial integration schemes. The software also has several advanced features to improve robustness and convergence, including residual smoothing, preconditioners, and agglomeration multigrid. +- **SU2_DOT (Gradient Projection Code)**: Computes the partial derivative of a functional with respect to variations in the aerodynamic surface. SU2_DOT uses the surface sensitivity, the flow solution, and the definition of the geometrical variable to evaluate the derivative of a particular functional (e.g. drag, lift, etc.). This is essentially a large dot product operation between the adjoint sensitivities and geometric sensitivities for the particular design variable parameterization. +- **SU2_DEF (Mesh Deformation Code)**: Computes the geometrical deformation of an aerodynamic surface and the surrounding volumetric grid. Once the type of deformation is defined, SU2_DEF performs the grid deformation by solving the linear elasticity equations on the volume grid. Three-dimensional geometry parameterization is defined using Free Form Deformation, while two-dimensional problems can be defined by both Free From Deformation or bump functions, such as Hicks-Henne. +- **SU2_MSH (Mesh Adaptation Code)**: Performs grid adaptation using various techniques based on an analysis of a converged flow solution, adjoint solution, and linearized problem to strategically refine the mesh about key flow features. This module also contains a preprocessor that creates the appropriate structures for periodic boundary conditions. +- **SU2_SOL (Solution Export Code)**: Generates the volumetric and surface solution files from SU2 restart files. +- **SU2_GEO (Geometry Definition Code)**: Geometry preprocessing and definition code. In particular, this module performs the calculation of geometric constraints for shape optimization. + +While they are not C++ modules, two other similar directories included in the source distribution should be mentioned. First, the **SU2_IDE** (Integrated Development Environment) directory contains files associated with various IDEs to aid developers (Eclipse, VisualStudio, Wing, Xcode). Second, the **SU2_PY** directory contains all of the files making up the Python framework, and some of these will be highlighted in a section below. + +### Algorithmic Differentiation Support and Discrete Adjoint + +SU2 includes integrated support for Algorithmic Differentiation (AD) based on Operator Overloading to compute arbitrary derivatives. One application of this feature is the discrete adjoint solver that is implemented in SU2. In contrast to the continuous adjoint method, special versions of the modules SU2_CFD and SU2_DOT are required to use this solver. + +- **SU2_CFD_AD**: Solves the discrete adjoint equations using a consistent linearization of the flow solver with the help of AD. Although it has additionally the same features as SU2_CFD, using it for other solvers will result in a slight slow-down due to the AD overhead. +- **SU2_DOT_AD**: The discrete adjoint formulation does not include the influence of the mesh deformation, therefore this module will compute the required partial derivative of the functional with respect to variations in the computational mesh. Instead of SU2_DOT, SU2_DOT_AD uses the volume sensitivities to evaluate the derivative. Finally, the resulting sensitivities on the aerodynamic surface are projected on to the particular design parameterization. + +## Python Scripts + +The various software modules of SU2 can be coupled together to perform complex analysis and design tasks using supplied Python scripts. A brief description of the scripts included in the current release of the software is provided below. + +- **High-fidelity analysis scripts**. These scripts have been designed to enhance the flexibility of the SU2 framework. More specifically, they simplify the execution of parallel tasks, grid adaptation, or interfacing with other software. + - **parallel_computation.py**: Handles the setup and execution of parallel CFD jobs on multi-core or cluster computing architectures. The script executes SU2_CFD in parallel and after the computation is completed runs SU2_SOL to provide a solution ready to be opened by a post-processing software of your choosing. + - **mesh_deformation.py**: Handles the setup and execution of parallel mesh deformation jobs on multi-core or cluster computing architectures. The script executes SU2_DEF in parallel. +- **Optimal shape design scripts**. These scripts have been designed to automate the optimal shape design process that includes functional and gradient computation, mesh deformation, and an optimization algorithm. + - **continuous_adjoint.py**: Automatically computes the sensitivities of a specified functional with respect to design parameter perturbations (specified in the SU2_CFD configuration file) using the continuous adjoint method. The SU2_CFD and SU2_DOT modules are called to perform the analysis. + - **discrete_adjoint.py**: Automatically computes the sensitivities of a specified functional with respect to design parameter perturbations (specified in the SU2_CFD configuration file) using the discrete adjoint method. The SU2_CFD_AD and SU2_DOT_AD modules are called to perform the analysis. + - **finite_differences.py**: Automatically computes the sensitivities of a specified functional with respect to design parameter perturbations using a finite difference method. As with the continuous_adjoint.py script, design variable information is read from the configuration file and SU2_CFD is called repeatedly to calculate the appropriate gradient elements. + - **shape_optimization.py**: Orchestrates all SU2 modules to perform shape optimization. The choice of objective function, design variables and additional module settings specifying the optimization problem are controlled through options in the configuration file. diff --git a/_docs_v7/Solver-Setup.md b/_docs_v7/Solver-Setup.md new file mode 100644 index 00000000..17a70316 --- /dev/null +++ b/_docs_v7/Solver-Setup.md @@ -0,0 +1,180 @@ +--- +title: Solver Setup +permalink: /docs_v7/Solver-Setup/ +--- + +**This guide is for version 7 only** + +This is a basic introduction on how to set up a simulation using SU2. We distinguish between single-zone computations and multi-zone computations. The following considers a single zone only. For an explanation on multi-zone problems, continue with [Basics of Multi-Zone Computations](/docs_v7/Multizone). + +--- + +## Content ## +- [Defining the Problem](#defining-the-problem) + - [Restarting the Simulation](#restarting-the-simulation) +- [Controlling the Simulation](#controlling-the-simulation) + - [Time-dependent Simulation](#time-dependent-simulation) + - [Steady-state Simulation](#steady-state-simulation) + - [Setting convergence criteria](#setting-convergence-criteria) + +--- + +# Defining the Problem # + +| Solver | Version | +| --- | --- | +| `ALL`| 7.0.0 | + +SU2 is capable of dealing with different kinds of physical problems. The kind of problem is defined by choosing a solver using the `SOLVER` option. A list of possible values and a description can be found in the following table: + +| Option Value | Problem | Type | +|---|---|---| +|`EULER` | **Euler's equation** |Finite-Volume method | +|`NAVIER_STOKES` | **Navier-Stokes' equation** | Finite-Volume method | +|`RANS` | **Reynolds-averaged 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| +|`HEAT_EQUATION_FVM` | **Heat equation** | Finite-Volume method | +|`ELASTICITY` | **Equations of elasticity** | Finite-Element method | +|`FEM_EULER` | **Euler's equation** | Discontinuous Galerkin FEM | +|`FEM_NAVIER_STOKES`| **Navier-Stokes' equation** | Discontinuous Galerkin FEM | +|`MULTIPHYSICS` | Multi-zone problem with different solvers in each zone | - | + +Every solver has its specific options and we refer to the tutorial cases for more information. However, the basic controls detailed in the remainder of this page are the same for all problems. + +## Restarting the simulation ## + +| Solver | Version | +| --- | --- | +| `ALL`| 7.0.0 | + +A simulation can be restarted from a previous computation by setting `RESTART_SOL=YES`. If it is a time-dependent problem, additionally `RESTART_ITER` must be set to the time iteration index you want to restart from: + +``` +% ------------------------- Solver definition -------------------------------% +% +% Type of solver +SOLVER= EULER +% +% Restart solution (NO, YES) +RESTART_SOL= NO +% +% Iteration number to begin unsteady restarts (used if RESTART_SOL= YES) +RESTART_ITER= 0 +% +``` + + + +--- + +# Controlling the simulation # + +| Solver | Version | +| --- | --- | +| `ALL`| 7.0.0 | + +A simulation is controlled by setting the number of iterations the solver should run (or by setting a convergence critera). The picture below depicts the two types of iterations we consider. + +![Types of Iteration](../../docs_files/unst_singlezone.png) + + +SU2 makes use of an outer time loop to march through the physical time, and of an inner loop which is usually a pseudo-time iteration or a (quasi-)Newton scheme. The actual method used depends again on the specific type of solver. + +## Time-dependent Simulation ## + +| Solver | Version | +| --- | --- | +| `ALL`| 7.0.0 | + +To enable a time-dependent simulation set the option `TIME_DOMAIN` to `YES` (default is `NO`). There are different methods available for certain solvers which can be set using the `TIME_MARCHING` option. For example for any of the FVM-type solvers a first or second-order dual-time stepping (`DUAL_TIME_STEPPING-1ST_ORDER`/`DUAL_TIME_STEPPING-2ND_ORDER`) method or a conventional time-stepping method (`TIME_STEPPING`) can be used. + +``` +% ------------------------- Time-dependent Simulation -------------------------------% +% +TIME_DOMAIN= YES +% +% Time Step for dual time stepping simulations (s) +TIME_STEP= 1.0 +% +% Total Physical Time for dual time stepping simulations (s) +MAX_TIME= 50.0 +% +% Number of internal iterations +INNER_ITER= 200 +% +% Number of time steps +TIME_ITER= 200 +% +``` + +The solver will stop either when it reaches the maximum time (`MAX_TIME`) or the maximum number of time steps (`TIME_ITER`), whichever event occurs first. Depending on the `TIME_MARCHING` option, the solver might use an inner iteration loop to converge each physical time step. The number of iterations within each time step is controlled using the `INNER_ITER` option. + +## Steady-state Simulation ## + +| Solver | Version | +| --- | --- | +| `ALL`| 7.0.0 | + +A steady-state simulation is defined by using `TIME_DOMAIN=NO`, which is the default value if the option is not present. In this case the number of iterations is controlled by the option `ITER`. + +**Note:** To make it easier to switch between steady-state, time-dependent and multizone simulations, the option `INNER_ITER` can also be used to specify the number of iterations. If both options are present, `INNER_ITER` has precedence. + +## Setting convergence criteria ## + +| Solver | Version | +| --- | --- | +| `ALL`| 7.0.0 | + +Despite setting the maximum number of iterations, it is possible to use a convergence criterion so that the solver will stop when it reaches a certain value of a residual or if variations of a coefficient are below a certain threshold. To enable a convergence criterion use the option `CONV_FIELD` to set an output field that should be monitored. The list of possible fields depends on the solver. Take a look at [Custom Output](/docs_v7/Custom-Output/) to learn more about output fields. Depending on the type of field (residual or coefficient) there are two types of methods: + +### Residual ### +If the field set with `CONV_FIELD` is a residual, the solver will stop if it is smaller than the value set with +`CONV_RESIDUAL_MINVAL` option. Example: + +``` +% ------------------- Residual-based Convergence Criteria -------------------------% +% +CONV_FIELD= RMS_DENSITY +% +% +% Min value of the residual (log10 of the residual) +CONV_RESIDUAL_MINVAL= -8 +% +``` + +### Coefficient ### +If the field set with `CONV_FIELD` is a coefficient, a Cauchy series approach is applied. A Cauchy element is defined as the relative difference of the coefficient between two consecutive iterations. The solver will stop if the average over a certain number of elements (set with `CONV_CAUCHY_ELEMS`) is smaller than the value set with `CONV_CAUCHY_EPS`. The current value of the Cauchy coefficient can be written to screen or history by adding the `CAUCHY` field to the `SCREEN_OUTPUT` or `HISTORY_OUTPUT` option (see [Custom Output](/docs_v7/Custom-Output/)). Example: + +``` +% ------------------ Coefficient-based Convergence Criteria -----------------------% +% +CONV_FIELD= DRAG +% +% +% Number of elements to apply the criteria +CONV_CAUCHY_ELEMS= 100 +% +% Epsilon to control the series convergence +CONV_CAUCHY_EPS= 1E-10 +% +``` +For both methods the option `CONV_STARTITER` defines when the solver should start monitoring the criterion. + +**Note:** The option `CONV_FIELD` also accepts a list of fields to monitor. The solver will stop if all fields reach their respective stopping criterion (i.e. the minimum value for residuals or the cauchy series threshold for coefficients as mentioned above). + diff --git a/_docs_v7/Style-Guide.md b/_docs_v7/Style-Guide.md new file mode 100644 index 00000000..11f02921 --- /dev/null +++ b/_docs_v7/Style-Guide.md @@ -0,0 +1,103 @@ +--- +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. + +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). + +## C++ style guide + +### 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. + +### 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. + +### Files, functions, and variables + +Here some basic recommendation are made 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. +- 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. +- 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 + +### 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 \________.\*/. + +### Comments + +The documentation, and comments must be Doxygen friendly, here I include some basic features: +- 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. +- 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 + +- 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. +- Iteration: iPoint, jPoint, kPoint, iNode, jNode, kNode, iElem, jElem, kElem, iDim, iVar, iMesh, iEdge. diff --git a/_docs_v7/Test-Cases.md b/_docs_v7/Test-Cases.md new file mode 100644 index 00000000..6d138bd3 --- /dev/null +++ b/_docs_v7/Test-Cases.md @@ -0,0 +1,24 @@ +--- +title: Test Cases +permalink: /docs_v7/Test-Cases/ +--- + +If you would like to experiment with some available cases, be sure to check out the suite of test cases that are available to you, as described below. + +**Note:** While many of the cases are used for regression testing, the test case suite is provided **without any guarantees on performance or expected results**. Tutorials (which are more thoroughly checked for convergence and results) can be found [here](/tutorials/home/). + +The test cases have been structured to separate the config files (found in the SU2 repo in SU2/TestCases/), which need to remain under version control, from the mesh/solution data (remain in a separate TestCases repo). The idea is that developers will update their config files along with their code changes in the SU2 repo so that pull requests can be automatically checked with Travis CI. The meshes and solution data, which change much less frequently and are larger files, remain in the TestCases repo. + +The two repositories contain the same directory structure for the test cases, with complementary (**not overlapping**) file sets. The responsibility is on the developer to add files to both repositories in matching directory locations when adding new test cases. This makes it very easy for one to recombine the full set of files or for Travis CI to do this automatically. To run the regression tests locally, one might do the following, assuming paths are set correctly such that SU2_CFD is available: +``` +$ 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 +``` + +Note that there are a number of test cases included in the suite that are not covered within the regressions. After completing the copy step in the process above, one will have all of the necessary config and mesh files within the appropriate locations for running the test cases individually instead of through the regression script. If you would like to view the separate test cases repository with the mesh/solution data, you can find it within a dedicated repo on [GitHub](https://github.com/su2code/TestCases). diff --git a/_docs_v7/Theory.md b/_docs_v7/Theory.md new file mode 100644 index 00000000..fe376d08 --- /dev/null +++ b/_docs_v7/Theory.md @@ -0,0 +1,206 @@ +--- +title: Governing Equations in SU2 +permalink: /docs_v7/Theory/ +--- + +**This guide is for version 7 only** + +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. + +--- + +## Content ## +- [Compressible Navier-Stokes](#compressible-rans) +- [Compressible Euler](#compressible-euler) +- [Incompressible Navier-Stokes](#incompressible-rans) +- [Incompressible Euler](#incompressible-euler) +- [Elasticity](#elasticity) +- [Heat Conduction](#heat-conduction) + +--- + +# Compressible Navier-Stokes # + +| Solver | Version | +| --- | --- | +| `NAVIER_STOKES`, `RANS`, `FEM_NAVIER_STOKES` | 7.0.0 | + + +SU2 solves the compressible Navier-Stokes equations 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, \rho \bar{v}, \rho E \right \}^\mathsf{T}$$ + +$$S$$ is a generic source term, and the convective and viscous fluxes are + +$$\bar{F}^{c} = \left \{ \begin{array}{c} \rho \bar{v} \\ \rho \bar{v} \otimes \bar{v} + \bar{\bar{I}} p \\ \rho E \bar{v} + p \bar{v} \end{array} \right \}$$ + +and + +$$\bar{F}^{v} = \left \{ \begin{array}{c} \cdot \\ \bar{\bar{\tau}} \\ \bar{\bar{\tau}} \cdot \bar{v} + \kappa \nabla T \end{array} \right \}$$ + +where $$\rho$$ is the fluid density, $$\bar{v}=\left\lbrace u, v, w \right\rbrace^\mathsf{T}$$ $$\in$$ $$\mathbb{R}^3$$ is the flow speed in Cartesian system of reference, $$E$$ is the total energy per unit mass, $$p$$ is the static pressure, $$\bar{\bar{\tau}}$$ is the viscous stress tensor, $$T$$ is the temperature, $$\kappa$$ is the thermal conductivity, and $$\mu$$ is the viscosity. The viscous stress tensor can be expressed in vector notation as + +$$\bar{\bar{\tau}}= \mu \left ( \nabla \bar{v} + \nabla \bar{v}^{T} \right ) - \mu \frac{2}{3} \bar{\bar I} \left ( \nabla \cdot \bar{v} \right )$$ + +Assuming a perfect gas with a ratio of specific heats $$\gamma$$ and specific gas constant $$R$$, one can close the system by determining pressure from $$p = (\gamma-1) \rho \left [ E - 0.5(\bar{v} \cdot \bar{v} ) \right ]$$ and temperature from the ideal gas equation of state $$T = p/(\rho R)$$. Conductivity can be a constant, or we assume a constant Prandtl number $$Pr$$ such that the conductivity varies with viscosity as $$\kappa = \mu c_p / Pr$$. + +It is also possible to model non-ideal fluids within SU2 using more advanced fluid models that are available, but this is not discussed here. Please see the tutorial on the topic. + +For laminar flows, $$\mu$$ is simply the dynamic viscosity $$\mu_{d}$$, which can be constant or assumed to satisfy Sutherland's law as a function of temperature alone, and $$Pr$$ is the dynamic Prandtl number $$Pr_d$$. For turbulent flows, we solve the Reynolds-averaged Navier-Stokes (RANS) equations. In accord with the standard approach to turbulence modeling based upon the Boussinesq hypothesis, which states that the effect of turbulence can be represented as an increased viscosity, the viscosity is divided into dynamic and turbulent components, or $$\mu_{d}$$ and $$\mu_{t}$$, respectively. Therefore, the effective viscosity in becomes + +$$\mu =\mu_{d}+\mu_{t}$$ + +Similarly, the thermal conductivity in the energy equation becomes an effective thermal conductivity written as + +$$\kappa =\frac{\mu_{d} \, c_p}{Pr_{d}}+\frac{\mu_{t} \, c_p}{Pr_{t}}$$ + +where we have introduced a turbulent Prandtl number $$Pr_t$$. The turbulent viscosity $$\mu_{t}$$ is obtained from a suitable turbulence model involving the mean flow state $$U$$ and a set of new variables for the turbulence. + +Within the `NAVIER_STOKES` and `RANS` 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. In the `FEM_NAVIER_STOKES` solver, we discretize the equations in space with a nodal Discontinuous Galerkin (DG) finite element method (FEM) with high-order (> 2nd-order) capability. + +--- + +# Compressible Euler # + +| Solver | Version | +| --- | --- | +| `EULER`, `FEM_EULER` | 7.0.0 | + +SU2 solves the compressible Euler equations, which can be obtained as a simplification of the compressible Navier-Stokes equations in the absence of viscosty and thermal conductivity. 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 are given by + +$$U = \left \{ \rho, \rho \bar{v}, \rho E \right \}^\mathsf{T}$$ + +$$S$$ is a generic source term, and the convective flux is + +$$\bar{F}^{c} = \left \{ \begin{array}{c} \rho \bar{v} \\ \rho \bar{v} \otimes \bar{v} + \bar{\bar{I}} p \\ \rho E \bar{v} + p \bar{v} \end{array} \right \}$$ + +where $$\rho$$ is the fluid density, $$\bar{v}=\left\lbrace u, v, w \right\rbrace^\mathsf{T}$$ $$\in$$ $$\mathbb{R}^3$$ is the flow speed in Cartesian system of reference, $$E$$ is the total energy per unit mass, $$p$$ is the static pressure, and $$T$$ is the temperature. Assuming a perfect gas with a ratio of specific heats $$\gamma$$ and gas constant $$R$$, one can close the system by determining pressure from $$p = (\gamma-1) \rho \left [ E - 0.5(\bar{v} \cdot \bar{v} ) \right ]$$ and temperature from the ideal gas equation of state $$T = p/(\rho R)$$. + +Within the `EULER` 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. In the `FEM_EULER` solver, we discretize the equations in space with a nodal Discontinuous Galerkin (DG) finite element method (FEM) with high-order (> 2nd-order) capability. + +--- + +# Incompressible Navier-Stokes # + +| Solver | Version | +| --- | --- | +| `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 + +$$ \mathcal{R}(V) = \frac{\partial V}{\partial t} + \nabla \cdot \bar{F}^{c}(V) - \nabla \cdot \bar{F}^{v}(V,\nabla V) - S = 0 $$ + +where the conservative variables are given by + +$$U=\left\lbrace \rho, \rho\bar{v},\rho c_{p} T \right\rbrace ^\mathsf{T}$$ + +but the working variables within the solver are the primitives given by + +$$V = \left \{ p, \bar{v}, T \right \}^\mathsf{T}$$ + +$$S$$ is a generic source term, and the convective and viscous fluxes are + +$$\bar{F}^{c}(V) = \left\{\begin{array}{c} \rho \bar{v} \\ \rho \bar{v} \otimes \bar{v} + \bar{\bar{I}} p \\ \rho c_{p} \, T \bar{v} \end{array} \right\}$$ + +$$\bar{F}^{v}(V,\nabla V) = \left\{\begin{array}{c} \cdot \\ \bar{\bar{\tau}} \\ \kappa \nabla T \end{array} \right\} $$ + +where $$\rho$$ is the fluid density, $$\bar{v}=\left\lbrace u, v, w \right\rbrace^\mathsf{T}$$ $$\in$$ $$\mathbb{R}^3$$ is the flow speed in Cartesian system of reference, $$p$$ is the pressure, $$\bar{\bar{\tau}}$$ is the viscous stress tensor, $$T$$ is the temperature, $$\kappa$$ is the thermal conductivity, and $$\mu$$ is the viscosity. The viscous stress tensor can be expressed in vector notation as + +$$\bar{\bar{\tau}}= \mu \left ( \nabla \bar{v} + \nabla \bar{v}^{T} \right ) - \mu \frac{2}{3} \bar{\bar I} \left ( \nabla \cdot \bar{v} \right )$$ + +In the low-Mach form of the equations, the pressure is decomposed into thermodynamic and dynamic components. $$p$$ is interpreted as the dynamic pressure in the governing equations, and $$p_o$$ is the thermodynamic (operating) pressure, which is constant in space. The system is now closed with an equation of state for the density that is a function of temperature alone $$\rho = \rho(T)$$. Assuming an ideal gas with a specific gas constant $$R$$, one can determine the density from $$\rho = \frac{p_o}{R T}$$. + +Conductivity can be a constant, or we assume a constant Prandtl number $$Pr$$ such that the conductivity varies with viscosity as $$\kappa = \mu c_p / Pr$$. For laminar flows, $$\mu$$ is simply the dynamic viscosity $$\mu_{d}$$, which can be constant or assumed to satisfy Sutherland's law as a function of temperature alone, and $$Pr$$ is the dynamic Prandtl number $$Pr_d$$. For turbulent flows, we solve the incompressible Reynolds-averaged Navier-Stokes (RANS) equations. In accord with the standard approach to turbulence modeling based upon the Boussinesq hypothesis, which states that the effect of turbulence can be represented as an increased viscosity, the viscosity is divided into dynamic and turbulent components, or $$\mu_{d}$$ and $$\mu_{t}$$, respectively. Therefore, the effective viscosity in becomes + +$$\mu =\mu_{d}+\mu_{t}$$ + +Similarly, the thermal conductivity in the energy equation becomes an effective thermal conductivity written as + +$$\kappa =\frac{\mu_{d} \, c_p}{Pr_{d}}+\frac{\mu_{t} \, c_p}{Pr_{t}}$$ + +where we have introduced a turbulent Prandtl number $$Pr_t$$. The turbulent viscosity $$\mu_{t}$$ is obtained from a suitable turbulence model involving the mean flow state $$U$$ and a set of new variables for the turbulence. + +The governing equation set in the general form above is very flexible for handling a number of variations in the modeling assumptions, from constant density inviscid flows up to variable density turbulent flows with a two-way coupled energy equation and temperature-dependent transport coefficients. Natural convection and 2D axisymmetric problems can be treated in a straightforward manner with the addition of source terms. + +Within the `INC_NAVIER_STOKES` and `INC_RANS` 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. We apply a density-based scheme that is a generalization of artificial compressibility in order to achieve pressure-velocity coupling and solve the incompressible equations in a fully coupled manner. + +--- + +# Incompressible Euler # + +| Solver | Version | +| --- | --- | +| `INC_EULER` | 7.0.0 | + +SU2 solves the incompressible Euler equations as a simplification of the low-Mach formulation above in the absence of viscosity and thermal conductivity (no energy equation is required). The equations can be expressed in differential form as + +$$ \mathcal{R}(V) = \frac{\partial V}{\partial t} + \nabla \cdot \bar{F}^{c}(V) - S = 0 $$ + +where the conservative variables are given by + +$$U=\left\lbrace \rho, \rho\bar{v} \right\rbrace ^\mathsf{T}$$ + +but the working variables within the solver are the primitives given by + +$$V = \left \{ p, \bar{v} \right \}^\mathsf{T}$$ + +$$S$$ is a generic source term, and the convective flux is + +$$\bar{F}^{c}(V) = \left\{\begin{array}{c} \rho \bar{v} \\ \rho \bar{v} \otimes \bar{v} + \bar{\bar{I}} p \end{array} \right\}$$ + +where $$\rho$$ is a fluid density (constant), $$\bar{v}=\left\lbrace u, v, w \right\rbrace^\mathsf{T}$$ $$\in$$ $$\mathbb{R}^3$$ is the flow speed in Cartesian system of reference, and $$p$$ is the dynamic pressure. + +Within the `INC_EULER` solver, 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. We apply a density-based scheme that is a generalization of artificial compressibility in order to achieve pressure-velocity coupling and solve the incompressible equations in a fully coupled manner. + +--- + +# 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. + +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. + +--- + +# Elasticity # + +| Solver | Version | +| --- | --- | +| `ELASTICITY` | 7.0.0 | + +For structural analysis of solids in SU2, we solve the elasticity equations in a form allowing for geometric non-linearities expressed as + +$$ \rho_s \frac{\partial^2 \mathbf{u}}{\partial t^2} = \nabla (\mathbf{F} \cdot \mathbf{S}) + \rho_s \mathbf{f} $$ + +where $$\rho_s$$ is the structural density, $$\mathbf{u}$$ are the displacements of the solid, $$\mathbf{F}$$ is the material deformation gradient, $$\mathbf{S}$$ is the second Piola-Kirchhoff stress tensor, and $$\mathbf{f}$$ is the volume forces on the structural domain. + +In the `ELASTICITY` solver, we discretize the equations in space with a nodal finite element method (FEM). + +--- + +# Heat Conduction # + +| Solver | Version | +| --- | --- | +| `HEAT_EQUATION_FVM` | 7.0.0 | + +The governing equation for heat conduction through a solid material can be expressed in differential form as the following: + +$$ R(U) = \frac{\partial U}{\partial t} - \nabla \cdot \bar{F}^{v}(U,\nabla U) - S = 0 $$ + +where the conservative variable is $$U=\left\lbrace \rho_s c_{p_s} T\right\rbrace$$, $$\rho_s$$ is the solid density, $$c_{p_s}$$ is the specific heat of the solid, and $$T$$ is the temperature. The viscous flux can be written as + +$$ \bar{F}^{v}(U,\nabla U) = \kappa_s \nabla T $$ + +where $$\kappa_s$$ is the thermal conductivity of the solid. The material properties of the solid are considered constant. + +Within the `HEAT_EQUATION_FVM` solver, 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 viscous flux is evaluated at the midpoint of an edge. diff --git a/_docs_v7/Windows-Demo.md b/_docs_v7/Windows-Demo.md new file mode 100644 index 00000000..c925786e --- /dev/null +++ b/_docs_v7/Windows-Demo.md @@ -0,0 +1,34 @@ +--- +title: Windows Demo +permalink: /docs_v7/Windows-Demo/ +--- + +This tutorial is intended to demonstrate 1) How to set up system variable, 2) How to run SU2 on Windows. + +## Set up system variable +1. Click Windows key +![System Variable Figure 1](../../docs_files/windows_system_variable_01.png) +2. Type "environ" in the search/run box of the start menu, select "edit the system environment variables" +![System Variable Figure 2](../../docs_files/windows_system_variable_02.png) +3. Click "Environment Variables..." +![System Variable Figure 3](../../docs_files/windows_system_variable_03.png) +4. Click "Path" system variable and then click "Edit" (or select "New" if "Path" system variable doesn't exist) +![System Variable Figure 4](../../docs_files/windows_system_variable_04.png) +![System Variable Figure 5](../../docs_files/windows_system_variable_05.png) +05. You need to add path to SU2 exectuables. In this example, we add C:\SU2 in the Path variable. If you didn't use the default values from the installer, you should add the path where your executables exist ex) "C:\Program Files (x86)\SU2" +![System Variable Figure 6](../../docs_files/windows_system_variable_06.png) +06. Don't forget to click "OK" +![System Variable Figure 7](../../docs_files/windows_system_variable_07.png) + +## Running SU2 on Windows +1. Click Windows key +![Windows Quickstart Figure 1](../../docs_files/windows_quick_start_01.png) +2. Type "cmd" in the search/run box of the start menu, select "Command Prompt" +![Windows Quickstart Figure 2](../../docs_files/windows_quick_start_02.png) +3. Move to the directory containing the config file and the mesh file +![Windows Quickstart Figure 3](../../docs_files/windows_quick_start_03.png) +4. Run the executable by entering "SU2_CFD inv_channel.cfg" at the command line. **If you didn't add the path to SU2 executables in system variable "Path", this command won't work** +![Windows Quickstart Figure 4](../../docs_files/windows_quick_start_04.png) +5. SU2 will print residual updates with each iteration of the flow solver, and the simulation will finish after reaching the specified convergence criteria +![Windows Quickstart Figure 6](../../docs_files/windows_quick_start_06.png) +6. Files containing the results will be written upon exiting SU2. The flow solution can be visualized in ParaView (.vtk) or Tecplot (.dat for ASCII). To visualize the flow solution in ParaView update the OUTPUT_FORMAT setting in the configuration file diff --git a/_docs_v7/Windows-Installation.md b/_docs_v7/Windows-Installation.md new file mode 100644 index 00000000..f75f5b31 --- /dev/null +++ b/_docs_v7/Windows-Installation.md @@ -0,0 +1,25 @@ +--- +title: Windows Installation +permalink: /docs_v7/Windows-Installation/ +--- + +As of release 4.1.1, SU2 supports Windows platforms from Windows 7 through Windows 10 in (x86) 32-bit and (x64) 64-bit architectures (see details and limitations below). Please note that the executables have been built to support any version of Windows but have only been tested on Windows 7 and Windows 10, x64 platform. The x86 versions are available for legacy support but are limited to smaller problems due to the 2 GB memory limit in x86 systems; a 64-bit architecture is recommended. Windows binaries are packaged as an Archive (.zip). If you encounter a problem installing or running in Windows please contact the support team for assistance. + +This version is built with CGNS 3.3.0 but no Tecplot binary support (Tecplot text format output is always available). + +## Installation + +1. **Download and unpack the archive**. Download the .zip for your operating system (Windows 7 or Windows 10) and unzip it where you want it to be installed. + +2. **Add SU2 environment variables**. This is done through the Environment Variables control panel. You can access these by typing "environ" in the search/run box of the start menu. Start a New System variable. Assign the Variable Name "SU2_RUN", and assign the Variable Value to be the path to your SU2 Executables (the folder that contains SU2_CFD.exe for example). If you used the default values from the installer, this could be "C:\SU2\". This variable will allow you to quickly navigate to the SU2 directory using "cd %SU2_RUN%", and run the executables using "%SU2_RUN%\" if SU2\ has not been added to the system path. + +*NOTE*: if the directory name contains white space, the executables may not work without appending ".exe", and the python scripts may not work. Additionally, when setting the enviornment variables and paths, quotes must be added, for example: "C:\Program Files\"Stanford ADL"\SU2\" + +3. **Add SU2 to the system path**. Access the system variables by typing "environ" in the search/run box of the start menu, select "edit the system environment variables", and then select "Environment Variables" from the System Properties menu. Edit the "Path" system variable (or select "New" if no "Path" system variable exists) and add the path to the SU2 executables. When there is more than one directory listed in "Path" they must be separated by semicolons. This will allow you to use the executables from any directory without explicitly specifying the path to the executable. + +4. **Optional: Install Microsoft MPI to enable parallel mode**. As the well-known, freely-available, open-source implementations of MPI listed in the Install section may not support Windows, you may want to install Microsoft MPI. + +## Running SU2 in Windows + +Running SU2 in Windows is identical to running in Linux or Mac OS environments and is run from the command line (whether cmd.exe or the freely-available Console2 for Windows). If your executable path contains white space you may need to add ".exe" . + diff --git a/_docs_v7/contribute.md b/_docs_v7/contribute.md new file mode 100644 index 00000000..6c8af16a --- /dev/null +++ b/_docs_v7/contribute.md @@ -0,0 +1,33 @@ +--- +title: Contribute +permalink: /docs_v7/contribute/ +--- + +Do you want to contribute to the SU2 documentation? It's easy! Just create a fork of the [SU2 Project Website repository](https://github.com/su2code/su2code.github.io), write your documentation, and open a pull request. + +## Writing content + +The documentation in this site is stored under the `_docs` folder. To add your contributions: + +**1.** Add a new Markdown file inside the subfolder, as `_docs/Your_Documentation.md`. Add the following [front matter](https://jekyllrb.com/docs_v7/frontmatter/) to your file: + +``` +--- +title: Your Documentation Page +permalink: /docs_v7/Your_Documentation/ +--- + +I'm contributing to SU2! Don't forget the trailing '/' on the permalink! +``` + +**2.** Add the documentation pagename to the `_data/docs.yml` file, in order to list it in the navigation panel (create a new subgroup if necessary): + +``` +- title: Your Subgroup of Documentation + docs: + - Your_Documentation +``` + +**3.** If you have supporting images or other auxiliary files, please add them to the folder `docs_files` in the root directory of the repository. Don't forget to add the correct relative links to these files in your docs, if necessary. + +**4.** When you are ready, submit a pull request to the **develop** branch of the [repository](https://github.com/su2code/su2code.github.io)... and it's all done! Thanks for your contribution! diff --git a/_docs_v7/index.md b/_docs_v7/index.md new file mode 100644 index 00000000..6039735d --- /dev/null +++ b/_docs_v7/index.md @@ -0,0 +1,12 @@ +--- +title: SU2, Multiphysics Simulation and Design Software +permalink: /docs_v7/home/ +redirect_from: /docs_v7/index.html +--- +

+SU2 Logo +

+ +The SU2 suite is an open-source collection of C++ based software tools for performing Partial Differential Equation (PDE) analysis and solving PDE-constrained optimization problems. The toolset is designed with Computational Fluid Dynamics (CFD) and aerodynamic shape optimization in mind, but is extensible to treat arbitrary sets of governing equations such as potential flow, elasticity, electrodynamics, chemically-reacting flows, and many others. SU2 is under active development by individuals all around the world on [GitHub](https://github.com/su2code/SU2) and is released under an open-source license. + +For a detailed description of the code philosophy, components, and implementations, please see our [SU2 AIAA Journal article](http://arc.aiaa.org/doi/abs/10.2514/1.J053813). diff --git a/_includes/docs_nav.html b/_includes/docs_nav.html index 68f593d4..9481a71e 100644 --- a/_includes/docs_nav.html +++ b/_includes/docs_nav.html @@ -13,7 +13,7 @@

{% for item in section.docs %} {% assign item_url = item | prepend:"/docs/" | append:"/" %} {% assign p = site.docs | where:"url", item_url | first %} - {{ p.title }} + {{ p.title }} {% endfor %} diff --git a/_includes/docs_v7_nav.html b/_includes/docs_v7_nav.html new file mode 100644 index 00000000..b567f65c --- /dev/null +++ b/_includes/docs_v7_nav.html @@ -0,0 +1,22 @@ +
+{% for section in site.data.docs_v7 %} +
+ +
+
    + {% for item in section.docs_v7 %} + {% assign item_url = item | prepend:"/docs_v7/" | append:"/" %} + {% assign p = site.docs_v7 | where:"url", item_url | first %} + {{ p.title }} + {% endfor %} +
+
+
+{% endfor %} +
diff --git a/_includes/footer.html b/_includes/footer.html index a42ab5e0..a2a1eadc 100644 --- a/_includes/footer.html +++ b/_includes/footer.html @@ -4,7 +4,7 @@

{{ site.title }} {{ site.time | date: '%Y' }} | Powered by Jekyll Doc Theme | - Our Cookie Policy + Privacy Policy

diff --git a/_includes/head.html b/_includes/head.html index 76aa3dbb..96396ced 100644 --- a/_includes/head.html +++ b/_includes/head.html @@ -1,6 +1,9 @@ - - + @@ -12,12 +15,11 @@ - - + + - - {% seo %} + - - + + diff --git a/_includes/js_files.html b/_includes/js_files.html index c1f7a2e7..2cd83d84 100644 --- a/_includes/js_files.html +++ b/_includes/js_files.html @@ -2,7 +2,7 @@ var baseurl = '{{ site.baseurl }}' - - + + - + diff --git a/_includes/section_docs_v7_nav.html b/_includes/section_docs_v7_nav.html new file mode 100644 index 00000000..4e5df750 --- /dev/null +++ b/_includes/section_docs_v7_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 docs = site.data.docs_v7 | map: 'docs_v7' | 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 docs_v7 %} + {% assign document_url = document | prepend:"/docs_v7/" | append:"/" %} + {% if document_url == page.url %} +
    + {% if forloop.first %} + + {% else %} + {% assign previous = forloop.index0 | minus: 1 %} + {% assign previous_page = docs_v7[previous] | prepend:"/docs_v7/" | append:"/" %} + + {% endif %} + + {% if forloop.last %} + + {% else %} + {% assign next = forloop.index0 | plus: 1 %} + {% assign next_page = docs_v7[next] | prepend:"/docsv_7/" | append:"/" %} + + {% endif %} + +
    + {% break %} + {% endif %} +{% endfor %} diff --git a/_includes/section_nav.html b/_includes/section_nav.html index 28e3153a..4b6a94f0 100644 --- a/_includes/section_nav.html +++ b/_includes/section_nav.html @@ -24,7 +24,7 @@ {% assign previous = forloop.index0 | minus: 1 %} {% assign previous_page = docs[previous] | prepend:"/docs/" | append:"/" %} @@ -40,7 +40,7 @@ {% assign next = forloop.index0 | plus: 1 %} {% assign next_page = docs[next] | prepend:"/docs/" | append:"/" %} diff --git a/_includes/topnav.html b/_includes/topnav.html index f170e2e8..f9eb8378 100644 --- a/_includes/topnav.html +++ b/_includes/topnav.html @@ -7,20 +7,19 @@ - - + + + + + diff --git a/_layouts/docs_v7.html b/_layouts/docs_v7.html new file mode 100644 index 00000000..f36be6ce --- /dev/null +++ b/_layouts/docs_v7.html @@ -0,0 +1,30 @@ +--- +layout: default +--- + +
    +
    +
    + {% include docs_v7_nav.html %} +
    + +
    +

    {{ page.title }}

    +
    {{ content }}
    +

    +
    + + Improve this page + +

    +
    + {% include section_docs_v7_nav.html %} +
    + +
    +
    + + + diff --git a/_layouts/vandv.html b/_layouts/vandv.html new file mode 100644 index 00000000..5089e5ce --- /dev/null +++ b/_layouts/vandv.html @@ -0,0 +1,25 @@ +--- +layout: default +--- + +
    +
    +
    + {% include vandv_nav.html %} +
    + +
    +

    {{ page.title }}

    +
    {{ content }}
    +

    +
    + + Improve this page + +

    +
    + {% include vandv_section_nav.html %} +
    + +
    +
    diff --git a/_tutorials/design_features/Turbulent_2D_Constrained_RAE2822.md b/_tutorials/design_features/Turbulent_2D_Constrained_RAE2822.md index 8cc1838d..d57ddaf8 100755 --- a/_tutorials/design_features/Turbulent_2D_Constrained_RAE2822.md +++ b/_tutorials/design_features/Turbulent_2D_Constrained_RAE2822.md @@ -17,7 +17,7 @@ We will walk through the shape design process and highlight several options rela ## Resources -You can find the resources for this tutorial in the folder [Turbulent_Shape_Design](https://github.com/su2code/su2code.github.io/tree/master/Turbulent_2D_Constrained_RAE2822) in the [tutorial repository](https://github.com/su2code/Tutorials). You will need the mesh file [mesh_RAE2822_turb.su2](../../Turbulent_2D_Constrained_RAE2822/mesh_RAE2822_turb.su2), the config file [turb_SA_RAE2822.cfg](../../Turbulent_2D_Constrained_RAE2822/turb_SA_RAE2822.cfg) and initial solution files for the solver and adjoint [solution_flow.dat](../../Turbulent_2D_Constrained_RAE2822/solution_flow.dat), [solution_adj_cd.dat](../../Turbulent_2D_Constrained_RAE2822/solution_adj_cd.dat), and [solution_adj_cmz.dat](../../Turbulent_2D_Constrained_RAE2822/solution_adj_cmz.dat). +You can find the resources for this tutorial in the folder [Turbulent_Shape_Design](https://github.com/su2code/su2code.github.io/tree/master/Turbulent_2D_Constrained_RAE2822) in the [tutorial/website repository](https://github.com/su2code/su2code.github.io). You will need the mesh file [mesh_RAE2822_turb.su2](../../Turbulent_2D_Constrained_RAE2822/mesh_RAE2822_turb.su2), the config file [turb_SA_RAE2822.cfg](../../Turbulent_2D_Constrained_RAE2822/turb_SA_RAE2822.cfg) and initial solution files for the solver and adjoint [solution_flow.dat](../../Turbulent_2D_Constrained_RAE2822/solution_flow.dat), [solution_adj_cd.dat](../../Turbulent_2D_Constrained_RAE2822/solution_adj_cd.dat), and [solution_adj_cmz.dat](../../Turbulent_2D_Constrained_RAE2822/solution_adj_cmz.dat). ## Tutorial diff --git a/_tutorials/index.md b/_tutorials/index.md index 9f8128f1..b1ebfab0 100644 --- a/_tutorials/index.md +++ b/_tutorials/index.md @@ -32,11 +32,13 @@ 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/) -Simulation of external, transitional flow over a flat plate (transitional latminar-turbulent case) -* [Turbulent ONERAM6](/tutorials/Turbulent_ONERAM6/) +Simulation of external, transitional flow over a flat plate (transitional latminar-turbulent case). +* [Turbulent ONERAM6](/tutorials/Turbulent_ONERAM6/) Simulation of external, viscous flow around a 3D geometry (isolated wing) using a turbulence model. -* [Epistemic Uncertainty Quantification of RANS predictions of NACA 0012 airfoil](/tutorials/UQ_NACA0012/) -Perform uncertainty quantification of errors arising due to assumptions inherent in turbulence models +* [Epistemic Uncertainty Quantification of RANS predictions of NACA 0012 airfoil](/tutorials/UQ_NACA0012/) +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. #### Incompressible Flow diff --git a/_vandv/Bump_Channel.md b/_vandv/Bump_Channel.md new file mode 100644 index 00000000..be7b5c3c --- /dev/null +++ b/_vandv/Bump_Channel.md @@ -0,0 +1,80 @@ +--- +title: 2D Bump-in-Channel RANS Verification Case +permalink: /vandv/Bump_Channel/ +--- + +| Solver | Version | +| --- | --- | +| `RANS` | 7.0.0 | + +

    +Skin Friction Grid Convergence SST x = 0.75 +

    + + +The details of the 2D Bump-in-Channel Verification case are taken from the [NASA TMR website](https://turbmodels.larc.nasa.gov/bump.html). + +By comparing the SU2 results of the bump-in-channel case against CFL3D and FUN3D on a sequence of refined grids and seeing agreement of key quantities, we can build a high degree of confidence that the SA and SST models are implemented correctly. Therefore, the goal of this case is to verify the implementations of the SA and SST models in SU2. + +## Problem Setup + +The bump-in-channel case is low Mach test case (nearly incompressible) for a fully turbulent flow over a no-slip wall featuring an elevated bump on the surface. The primary difference between this case and the flat plate case is that pressure gradients are induced by the wall curvature of the bump, which makes this case more challenging for turbulence models. + +This problem will solve the flow past the bump with these conditions: +- Freestream Temperature = 300 K +- Freestream Mach number = 0.2 +- Reynolds number = 3.0E6 +- Reynolds length = 1.0 m + +The length of the section of wall with the bump is 1.5 meters, and it is represented by an adiabatic no-slip wall boundary condition. The lower boundaries of the domain upstream and downstream of the bump section are modeled as symmetry planes. Inlet and outlet boundary conditions are used on the left and right boundaries of the domain, and a symmetry boundary condition is used over the top region of the domain (the upper wall of the channel), which is located 5 meters away from the bump. All other fluid and boundary conditions are applied as prescribed on the NASA TMR website. + +## Mesh Description + +Structured meshes of increasing density are used to perform a grid convergence study. The meshes are identical to the 2D versions found on the [NASA TMR website](https://turbmodels.larc.nasa.gov/bump_grids.html) for this case after converting to 2D, unstructured CGNS format (ADF). These meshes are named according to the number of vertices in the x and y directions, respectively. The mesh sizes are: + +1. 89x41 - 3520 quadrilaterals +2. 177x81 - 14080 quadrilaterals +3. 353x161 - 56320 quadrilaterals +4. 705x321 - 225280 quadrilaterals +5. 1409x641 - 901120 quadrilaterals + +If you would like to run the bump-in-channel problem for yourself, you can use the files available in the [SU2 V&V repository](https://github.com/su2code/VandV/tree/master/rans/bump_in_channel_2d). Configuration files for both the SA and SST cases, as well as all grids in CGNS format, are provided. A Python script is also distributed in order to easily recreate the figures seen below from the data. *Please note that the mesh files found in the repository have been gzipped to reduce storage requirements and should be unzipped before use.* + +## Results + +The results for the mesh refinement study are presented and compared to results from FUN3D and CFL3D, including results for both the SA and SST turbulence models. + +We will compare the convergence of the lift and drag coefficient on the bump with grid refinement, as well as the value of the skin friction coefficient at 3 locations on the bump (x = 0.63, x = 0.75, x = 0.87). We also show the skin friction and pressure coefficients plotted along the length of the bump. For both turbulence models, we present profiles of the eddy viscosity and x-velocity at the x = 0.75 location (top of the bump). For the SST model, we show additional profiles for the turbulent kinetic energy and dissipation near the wall at the x = 0.75 location. All cases were converged until the density residual was reduced to 10-13, which is demonstrated by a figure containing residual convergence histories for each mesh. + +Both the SA and SST models exhibit excellent agreement in the figures below. With grid refinement, we see that all quantities of interest asymptote very close to those of FUN3D and CFL3D (and additional codes not shown here but displayed on the NASA TMR), which builds high confidence in the implementations of these two turbulence models in SU2. The SU2 results for all profile comparisons are nearly indistinguishable from the CFL3D and FUN3D counterparts. + +### SA Model + +

    +Drag Grid Convergence SA +Lift Grid Convergence SA +Skin Friction Grid Convergence SA x = 0.63 +Skin Friction Grid Convergence SA x = 0.75 +Skin Friction Grid Convergence SA x = 0.87 +Skin Friction Profile SA +Pressure Profile SA +Eddy Viscosity Profile SA +Velocity Profile SA +Residual Convergence SA +

    + +### SST Model + +

    +Drag Grid Convergence SST +Lift Grid Convergence SST +Skin Friction Grid Convergence SST x = 0.63 +Skin Friction Grid Convergence SST x = 0.75 +Skin Friction Grid Convergence SST x = 0.87 +Skin Friction Profile SST +Pressure Profile SST +Eddy Viscosity Profile SST +Velocity Profile SST +Residual Convergence SST +

    + diff --git a/_vandv/Flat_Plate.md b/_vandv/Flat_Plate.md new file mode 100644 index 00000000..8cc76961 --- /dev/null +++ b/_vandv/Flat_Plate.md @@ -0,0 +1,69 @@ +--- +title: 2D Zero Pressure Gradient Flat Plate RANS Verification Case +permalink: /vandv/Flat_Plate/ +--- + +| Solver | Version | +| --- | --- | +| `RANS` | 7.0.0 | + +

    +Skin Friction Grid Convergence SA +

    + +The details of the Zero Pressure Gradient Flat Plate case are taken from the [NASA TMR website](https://turbmodels.larc.nasa.gov/flatplate.html). + +By comparing the SU2 results of the flat plate case against CFL3D and FUN3D on a sequence of refined grids and seeing agreement of key quantities, we can build a high degree of confidence that the SA and SST models are implemented correctly. Therefore, the goal of this case is to verify the implementations of the SA and SST models in SU2. + +## Problem Setup + +Turbulent flow over a zero pressure gradient flat plate is a common test case for the verification of turbulence models in CFD solvers. The flow is everywhere turbulent and a boundary layer develops over the surface of the flat plate. The lack of separation or other more complex flow phenomena allows turbulence models to predict the flow with a high level of accuracy. + +This problem will solve the flow past the flatplate with these conditions: +- Freestream Temperature = 300 K +- Freestream Mach number = 0.2 +- Reynolds number = 5.0E6 +- Reynolds length = 1.0 m + +The length of the flat plate is 2 meters, and it is represented by an adiabatic no-slip wall boundary condition. Also part of the domain is a symmetry plane located before the leading edge of the flat plate. Inlet and outlet boundary conditions are used on the left and right boundaries of the domain, and a far-field boundary condition is used over the top region of the domain, which is located 1 meter away from the flat plate. All other fluid and boundary conditions are applied as prescribed on the NASA TMR website. + +## Mesh Description + +Structured meshes of increasing density are used to perform a grid convergence study. The meshes are identical to the 2D versions found on the [NASA TMR website](https://turbmodels.larc.nasa.gov/flatplate_grids.html) for this case after converting to native SU2 ASCII mesh format. These meshes are named according to the number of vertices in the x and y directions, respectively. The mesh sizes are: + +1. 35x25 - 816 quadrilaterals +2. 69x49 - 3264 quadrilaterals +3. 137x97 - 13056 quadrilaterals +4. 273x193 - 52224 quadrilaterals +5. 545x385 - 208896 quadrilaterals + +![Turb Plate Mesh](/vandv_files/Flat_Plate/images/turb_plate_mesh_bcs.png) +Figure (1): Mesh with boundary conditions: inlet (red), outlet (blue), far-field (orange), symmetry (purple), wall (green). + +If you would like to run the flat plate problems for yourself, you can use the files available in the [SU2 V&V repository](https://github.com/su2code/VandV/tree/master/rans/flatplate). Configuration files for both the SA and SST cases, as well as all grids in SU2 format, are provided. A Python script is also distributed in order to easily recreate the figures seen below from the data. + +## Results + +The results for the mesh refinement study are presented and compared to results from FUN3D and CFL3D, including results for both the SA and SST turbulence models. + +We will compare the convergence of the drag coefficient on the flat plate with grid refinement, as well as the value of the skin friction coefficient at one point on the plate (x = 0.97). We also show the skin friction coefficient plotted along the length of the plate. All cases were converged until the density residual was reduced to 10-13, which is demonstrated by a figure containing residual convergence histories for each mesh. + +Both the SA and SST models exhibit excellent agreement in the figures below. With grid refinement, we see that both drag and skin friction values asymptote very close to those of FUN3D and CFL3D (and additional codes not shown here but displayed on the NASA TMR), which builds high confidence in the implementations of these two turbulence models in SU2. + +### SA Model + +

    +Drag Grid Convergence SA +Skin Friction Grid Convergence SA +Skin Friction Profile SA +Residual Convergence SA +

    + +### SST Model + +

    +Drag Grid Convergence SST +Skin Friction Grid Convergence SST +Skin Friction Profile SST +Residual Convergence SST +

    diff --git a/_vandv/MMS_FVM_Navier_Stokes.md b/_vandv/MMS_FVM_Navier_Stokes.md new file mode 100644 index 00000000..11a93043 --- /dev/null +++ b/_vandv/MMS_FVM_Navier_Stokes.md @@ -0,0 +1,70 @@ +--- +title: Method of Manufactured Solutions for Compressible Navier-Stokes +permalink: /vandv/MMS_FVM_Navier_Stokes/ +--- + +| Solver | Version | +| --- | --- | +| `NAVIER_STOKES`| 7.0.0 | + +

    +Accuracy RMS Rho +

    + +This page contains the results of running MMS for the compressible Navier-Stokes system in order to formally verify the order-of-accuracy for the 2nd-order finite volume solver in SU2. These cases were completed with SU2 v7.0.0. + +For more details, please see the presentation on the subject from the [4th Annual SU2 Developers Meeting](https://su2foundation.org/wp-content/uploads/2019/05/SU2_Verification_EdwinTom.pdf). + +## Problem Setup + +The basic concept behind the Method of Manufactured Solutions (MMS) is to verify a code by ensuring that it reproduces a predefined solution (the "manufactured solution") when the governing equations are forced with the source term that corresponds to the manufactured solution. Verification is then possible by computing formal order of accuracy using the global error on a sequence of refined grids. + +The 2D manufactured solution used in this case for the compressible Navier-Stokes equations is given by: + +

    +NS MMS +

    + +which will be solved on a unit quad domain. Contours of the solution are shown below. + +

    +NS MMS Density +NS MMS Pressure +NS MMS Mach +

    + +A symbolic manipulation package such as Maple or SymPy is used to generate the required source terms automatically by evaluating the governing equations at the manufactured solution. + +## Results + +The results for solving the 2D MMS problem on a sequence of 5 grids are given below. The unit domain meshes are composed of quadrilaterals (triangles are also possible), and the mesh sizes are 9x9, 17x17, 33x33, 65x65, 129x129, and 257x257. + +Several variations of the numerical methods are tested, namely the Roe upwind scheme with and without limiters, the JST scheme, and both the Green-Gauss and weighted least-squares approaches for computing flow variable gradients. In the figures, the abbreviations represent the following: Roe = Roe uwpind scheme with 2nd-order MUSCL reconstruction, JST = Jameson-Schmidt-Turkel centered scheme, GG = Green-Gauss gradient method, LIM = Venkatakrishnan-Wang limiter, WLS = Weighted Least-Squares gradient method. + +Figures containing the formal order of accuracy and the global error for both L-infinity and L2 norms for each of the conserved variables (density, momentum, and energy) are shown below. The figures with the global error also present the ideal slopes for first- and second-order accuracy. As expected for the finite volume solver in SU2, all results correctly asymptote to second-order accuracy as the mesh is refined, which verifies the accuracy of the solver for the methods investigated. + +If you would like to run the MMS problems for yourself, you can use the files available in the [SU2 V&V repository](https://github.com/su2code/VandV/tree/master/mms/fvm_navierstokes). The compute_order_of_accuracy.py script drives the other files in this folder. Simply set the number of ranks on which to run the cases by modifying the 'nRank' variable at the top of the script and then execute with: + +$ compute_order_of_accuracy.py + +The script will automatically generate the required meshes and execute SU2 solutions for the four different cases on those meshes for comparison. Four config files are provided, but you can modify them or add new ones. Simply change the config files listed at the top of the compute_order_of_accuracy.py script. Postprocessing is also automatically performed by the script, including the creation of figures for global error vs relative grid size and observed order of accuracy vs relative grid size. + +

    +Slope RMS Rho +Accuracy RMS Rho +Slope RMS Rho-U +Accuracy RMS Rho-U +Slope RMS Rho-V +Accuracy RMS Rho-V +Slope RMS Rho-E +Accuracy RMS Rho-E +Slope Max Rho +Accuracy Max Rho +Slope Max Rho-U +Accuracy Max Rho-U +Slope Max Rho-V +Accuracy Max Rho-V +Slope Max Rho-E +Accuracy Max Rho-E +

    + diff --git a/_vandv/contribute.md b/_vandv/contribute.md new file mode 100644 index 00000000..7e5e1fcb --- /dev/null +++ b/_vandv/contribute.md @@ -0,0 +1,33 @@ +--- +title: Contribute +permalink: /vandv/Contribute/ +--- + +Do you want to contribute to SU2 with a V&V case study? It's easy! Just create a fork of the [SU2 Project Website repository](https://github.com/su2code/su2code.github.io), write your case study and open a pull request. + +## Writing content + +The case studies in this section of the site are stored under the `_vandv` folder. To add your contributions: + +**1.** Add a new Markdown file inside the subfolder, as `_vandv/Your_Case_Name.md`. Add the following [front matter](https://jekyllrb.com/docs/frontmatter/) to your file: + +``` +--- +title: Your Case Study Title +permalink: /docs/Your_Case_Name +--- + +I'm contributing to SU2! +``` + +**2.** Create a new subfolder in `_vandv_files/` as `_vand/Your_Case_Name`, where you can store any additional files needed for your case study, such as images of results. Don't forget to provide the relative links in your Markdown file to these auxiliary files, if necessary. + +**3.** Add the case study pagename to the `_data/vandv.yml` file, in order to list it in the navigation panel: + +``` +- title: Your Subgroup of Case Studies + vandv: + - Your_Case Name +``` + +**4.** When you are ready, submit a pull request to the **develop** branch of the [SU2 Project Website repository](https://github.com/su2code/su2code.github.io)... and it's all done! Thanks for your contribution! diff --git a/_vandv/index.md b/_vandv/index.md new file mode 100644 index 00000000..f7f62757 --- /dev/null +++ b/_vandv/index.md @@ -0,0 +1,26 @@ +--- +title: The SU2 V&V Collection +permalink: /vandv/home/ +redirect_from: /vandv/index.html +--- + +The case studies presented in this section demonstrate the verification and validation (V&V) of the solvers within the SU2 suite. Verification activities assess whether a particular model has been implemented correctly in software, i.e., it is coded as specified and bug-free. Validation activities assess whether a particular model matches the physical reality for a situation of interest, typically via comparison with experiment. + +When available, rigorous verification via formal order of accuracy assessment by exact or manufactured solutions is performed. When exact or manufactured solutions are not available, code-to-code comparisons are made. By comparing SU2 results against many well-established codes on a sequence of refined grids and seeing agreement of key quantities in the limit, we can build a high degree of confidence that the models found within SU2 are implemented correctly. + +We will continue to add cases over time to demonstrate V&V of additional physical models in SU2, and we encourage contributions from the community! Please see the contribute page for instructions on how to contribute. + +**NOTE**: The primary purpose of this section of the website is to demonstrate V&V of the SU2 suite, and as such, the case studies are not written as tutorials. However, you can typically find the files needed to run the cases yourself in the [project V&V repository](https://github.com/su2code/vandv) or here in the [project website repository](https://github.com/su2code/su2code.github.io) . + + +## Summary of V&V case studies +------ + +#### Compressible Flow + +* [Method of Manufactured Solutions for Compressible Navier-Stokes](/vandv/MMS_FVM_Navier_Stokes/) +Formal order of accuracy of the finite volume solver in SU2 for the laminar Navier-Stokes equations is assessed. +* [2D Zero Pressure Gradient Flat Plate RANS Verification Case](/vandv/Flat_Plate/) +Code-to-code comparisons of drag and skin friction on a turbulent flat plate is presented using data from the NASA Turbulence Modeling Resource. +* [2D Bump-in-Channel RANS Verification Case](/vandv/Bump_Channel/) +Code-to-code comparisons for a bump in a channel, which results in pressure gradients, is presented using data from the NASA Turbulence Modeling Resource. diff --git a/allposts.html b/allposts.html index 44bbe602..29e5c5ef 100644 --- a/allposts.html +++ b/allposts.html @@ -9,7 +9,7 @@

    All Posts

    {% for page in site.posts %}

    - {{ page.title }} + {{ page.title }} on {{ page.date | date: "%B %e, %Y" }} {% if page.author %} by {{ page.author }}{% endif %}

    {% endfor %} diff --git a/cookie_declaration.html b/cookie_declaration.html index 0b5a9a90..855a03f2 100644 --- a/cookie_declaration.html +++ b/cookie_declaration.html @@ -1,12 +1,103 @@ --- title: Cookie Declaration -layout: default +layout: null ---
    -
    -
    -

    Cookie Declaration

    - -
    -
    + +
    +
    +

    Cookie Policy for SU2 Multiphysics Simulation and Design Software

    + +

    This is the Cookie Policy for SU2 Multiphysics Simulation and Design +Software, accessible from https://su2code.github.io/

    + +

    What Are Cookies

    + +

    As is common practice with almost all professional websites this site +uses cookies, which are tiny files that are downloaded to your computer, +to improve your experience. This page describes what information they +gather, how we use it and why we sometimes need to store these cookies. +We will also share how you can prevent these cookies from being stored +however this may downgrade or 'break' certain elements of the sites +functionality.

    + +

    For more general information on cookies see the Wikipedia article on +HTTP Cookies.

    + +

    How We Use Cookies

    + +

    We use cookies for a variety of reasons detailed below. Unfortunately +in most cases there are no industry standard options for disabling +cookies without completely disabling the functionality and features they +add to this site. It is recommended that you leave on all cookies if you +are not sure whether you need them or not in case they are used to +provide a service that you use.

    + +

    Disabling Cookies

    + +

    You can prevent the setting of cookies by adjusting the settings on +your browser (see your browser Help for how to do this). Be aware that +disabling cookies will affect the functionality of this and many other +websites that you visit. Disabling cookies will usually result in also +disabling certain functionality and features of the this site. Therefore +it is recommended that you do not disable cookies.

    + +

    The Cookies We Set

    + +
      + +
    • +

      Site preferences cookies

      +

      In order to provide you with a great experience on this site we +provide the functionality to set your preferences for how this site runs +when you use it. In order to remember your preferences we need to set +cookies so that this information can be called whenever you interact +with a page is affected by your preferences.

      +
    • + +
    + +

    Third Party Cookies

    + +

    In some special cases we also use cookies provided by trusted third +parties. The following section details which third party cookies you +might encounter through this site.

    + +
      + +
    • +

      This site uses Google Analytics which is one of the most +widespread and trusted analytics solution on the web for helping us to +understand how you use the site and ways that we can improve your +experience. These cookies may track things such as how long you spend on +the site and the pages that you visit so we can continue to produce +engaging content.

      +

      For more information on Google Analytics cookies, see the +official Google Analytics page.

      +
    • + +
    + +

    More Information

    + +

    Hopefully that has clarified things for you and as was previously +mentioned if there is something that you aren't sure whether you need or +not it's usually safer to leave cookies enabled in case it does interact +with one of the features you use on our site. This Cookies Policy was +created with the help of the Cookies Policy Template +Generator and the Terms and Conditions +Template.

    + +

    However if you are still looking for more information then you can +contact us through one of our preferred contact methods:

    + +
      +
    • Email: info@su2foundation.org
    • + +
    + +
    +
    diff --git a/develop.html b/develop.html index 8c82fee1..458079f2 100644 --- a/develop.html +++ b/develop.html @@ -1,5 +1,5 @@ --- -title: SU2 Developers +title: SU2 Development layout: default --- @@ -9,34 +9,11 @@

    Join the Team

    -

    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 programming skills to take SU2 to the next level.

    +

    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.

    -

    We invite all contributors to the SU2 project to become members of the SU2 International Developers Society (IDS). The mission of the society is to connect, inspire, and expand the SU2 developer community. Membership is free and offers some serious perks.

    - -
    - -

    SU2 is being developed by individuals and organized teams around the world. Currently, the most active teams contributing to SU2 are:

    -
    - -
    - -

    Note I: If you are actively working on SU2 and your team is not in the list, please let us know and we will add your team and profile to this webpage.

    +

    SU2 is being developed collaboratively by individuals and organized teams around the world. A goal of the SU2 Foundation is to provide a trusted, neutral forum or community collaboration around the SU2 project, including transparent, community-driven technical governance. All individuals and groups are welcome to join the community and development process. Please contact the SU2 Foundation if you would like more information, or head straight to our GitHub repository, as described below.


    @@ -45,10 +22,10 @@

    Join the Team


    -

    Gitting Started

    +

    Git-ting Started

    -

    GitHub is the center of all development efforts in SU2. The su2code GitHub organization contains the main code repository as well as supporting materials:

    +

    GitHub is the center of all development efforts in SU2. The su2code GitHub organization contains the primary code repository, as well as supporting materials:


    diff --git a/docs_files/SU2_Color_NoBackground.png b/docs_files/SU2_Color_NoBackground.png new file mode 100644 index 00000000..88c9994a Binary files /dev/null and b/docs_files/SU2_Color_NoBackground.png differ diff --git a/docs_files/unst_singlezone.png b/docs_files/unst_singlezone.png new file mode 100644 index 00000000..f8944008 Binary files /dev/null and b/docs_files/unst_singlezone.png differ diff --git a/download.html b/download.html index 843e29c8..cbe6190c 100644 --- a/download.html +++ b/download.html @@ -11,6 +11,40 @@
    + + + + +

    Downloading SU2

    @@ -19,49 +53,34 @@

    Downloading SU2

    SU2 is available freely for use under the GNU Lesser General Public License, version 2.1. Please reference the license details for terms and conditions.

    -

    Before downloading the software, please take a moment to register for the user email list, so you won't miss out on the latest news and announcements from the SU2 project. We respect your privacy, and the information we collect is used only for statistics and never shared. Your participation lets us build a better tool to suit the needs of our community. Should you wish, you can unsubscribe at any time here.

    +

    Before downloading the software, please take a moment to register for the email list, so you won't miss out on the latest news and announcements from the SU2 project. We respect your privacy, and the information we collect is used only for statistics and never shared. Your participation lets us build a better tool to suit the needs of our community.


    -

    Register +

    Register



    Binary Executables

    -

    This option is for users who wish to use SU2 without the need to compile the program from source. Note: binary distributions for macOS, Linux, and Windows have reduced functionality; non-default libraries and dependencies are removed (serial versions only).

    - -

    The following binaries are available for download by clicking the buttons below: -

      -
    • macOS Sierra 10.13: Apple LLVM version 9.1.0. -
    • Linux (Redhat 6.6): g++ (GCC) 4.8.5. -
    • Linux (Ubuntu 14.04): g++ (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4. -
    • Windows 7: Microsoft Visual C++ 2010. -
    • Windows 10: MinGW version 7.3.0. Microsoft MPI for parallel binaries. See details. -
    -

    - +

    This option is for users who wish to use SU2 without the need to compile the program from source.
    Note: binary distributions for macOS, Linux, and Windows are serial only!


    -

    Current Release for macOS/Linux: SU2 v6.2.0

    +


    @@ -72,11 +91,11 @@

    Current Release for Windows: SU2 v6.0.0

    @@ -95,7 +114,14 @@

    Source Code


    -

    Source (.tar.gz) +


    @@ -115,7 +141,14 @@

    Tutorials

    As part of our documentation and training, we ship a set of tutorials that walk the user through setting up and executing a number of examples. These cases start from the basics and help the user learn SU2 quickly. Later tutorials cover advanced SU2 capabilities, such as optimal shape design.

    -

    Web Tutorials (.tar.gz) +


    The entire set of documentation and tutorials ships with the main project website repository. You can download all of the necessary files (including config files and grids) using the following:

    @@ -133,10 +166,14 @@

    Test Case Suite

    The latest release of the test cases will also be tagged and available on the GitHub releases page, and for convenience, you can download the this source code from the latest release directly with the button below:


    - -
    -

    Test Cases (.tar.gz) -

    +

    Note that, while many of the cases are used for regression testing, this test case suite is provided without any guarantees on performance or expected results. Keep in mind that small changes to the configuration options can often result in large changes to the output. We encourage the community to experiment with these test cases, or even try (and share!) other interesting validation cases with SU2!

    diff --git a/download/su2-macos-latest.tgz b/download/su2-macos-latest.tgz index a438337e..73102af6 100644 Binary files a/download/su2-macos-latest.tgz and b/download/su2-macos-latest.tgz differ diff --git a/download/su2-redhat-latest.tgz b/download/su2-redhat-latest.tgz index a73c7533..9ef7ccd1 100644 Binary files a/download/su2-redhat-latest.tgz and b/download/su2-redhat-latest.tgz differ diff --git a/download/su2-ubuntu-latest.tgz b/download/su2-ubuntu-latest.tgz index 8dcb92bf..62a4fb2e 100644 Binary files a/download/su2-ubuntu-latest.tgz and b/download/su2-ubuntu-latest.tgz differ diff --git a/download_v7.html b/download_v7.html new file mode 100644 index 00000000..68b8e0f2 --- /dev/null +++ b/download_v7.html @@ -0,0 +1,247 @@ +--- +title: Downloading SU2 +layout: default +--- + +
    + +
    +
    + +
    +
    + + + + + + +
    +
    +

    Downloading SU2

    + +
    + +

    SU2 is available freely for use under the GNU Lesser General Public License, version 2.1. Please reference the license details for terms and conditions.

    + +

    Before downloading the software, please take a moment to register for the email list, so you won't miss out on the latest news and announcements from the SU2 project. We respect your privacy, and the information we collect is used only for statistics and never shared. Your participation lets us build a better tool to suit the needs of our community.

    + +
    + +
    +

    Register +

    + +
    +
    + +

    Binary Executables

    +

    This option is for users who wish to use SU2 without the need to compile the program from source. We provide serial and parallel (using MPI) versions.

    + Disclaimer: For best performance and compatibility you should always consider building SU2 from source. Also note that the Discrete Adjoint functionality is not available when using the binary executables. + +
    +
    + +
    +

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

    Version

    Notes

    Published

    Size

    SU2 for Linux-

     
    SU2 MPI for LinuxRequires installation of MPICH

     
    SU2 for macOS-

     
    SU2 MPI macOSRequires installation of MPICH

     
    SU2 for Windows-

     
    SU2 MPI for WindowsRequires installation of Microsoft MPI

    + +
    +
    +

    Source Code

    +

    There are a number of ways to access the SU2 source code. If you will be developing the code, we recommend that you clone the repository. On a Linux/Unix/Mac system with the standard git client, this can be done by executing:

    + +

    $ git clone https://github.com/su2code/SU2.git

    + +

    You may also browse the code on GitHub directly. A link on the right hand side provides the option to download a current snapshot of the master branch repository as a ZIP file. The latest release will also be tagged and available on the GitHub releases page, and for convenience, you can download the this source code from the latest release directly with the button below:

    + +
    + +
    + +
    + +
    + +

    Once you have obtained a copy of the code, follow the installation instructions to compile and install from source.

    + + +
    +
    +

    Previous Versions

    +

    SU2 is hosted on GitHub, and previous versions are tagged and available on the releases page.

    + +
    +
    + +

    Tutorials

    +

    As part of our documentation and training, we ship a set of tutorials that walk the user through setting up and executing a number of examples. These cases start from the basics and help the user learn SU2 quickly. Later tutorials cover advanced SU2 capabilities, such as optimal shape design.

    + +
    + +
    +
    +

    The entire set of documentation and tutorials ships with the main project website repository. You can download all of the necessary files (including config files and grids) using the following:

    + +

    $ git clone https://github.com/su2code/su2code.github.io

    + +
    +
    + +

    Test Case Suite

    +

    SU2 comes with an extensive collection of common test cases. The test cases contain meshes and configuration files that can be run to ensure different components of the suite are working properly. Test cases (configuration and mesh files) are included in a separate repository, also available on GitHub that can be accessed using:

    + +

    $ git clone https://github.com/su2code/TestCases.git

    + +The latest release of the test cases will also be tagged and available on the GitHub releases page, and for convenience, you can download the this source code from the latest release directly with the button below:

    + +
    + +
    + +

    Note that, while many of the cases are used for regression testing, this test case suite is provided without any guarantees on performance or expected results. Keep in mind that small changes to the configuration options can often result in large changes to the output. We encourage the community to experiment with these test cases, or even try (and share!) other interesting validation cases with SU2!

    + +

    Please see the documentation on how to use the test cases.

    + +
    + + + + + diff --git a/img/drivaer.png b/img/drivaer.png index f0d2ab61..fb1d731f 100644 Binary files a/img/drivaer.png and b/img/drivaer.png differ diff --git a/img/logoSU2_v3.3_mod.png b/img/logoSU2_v3.3_mod.png index 6f2ea8c6..3d26d813 100644 Binary files a/img/logoSU2_v3.3_mod.png and b/img/logoSU2_v3.3_mod.png differ diff --git a/index.html b/index.html index 35c91917..69f67a08 100644 --- a/index.html +++ b/index.html @@ -18,50 +18,36 @@

    Powerful. Fast. Free.

    - +
    -
    -
    - -

    4th Annual SU2 Developers Meeting

    -

    NEW: The virtual meeting details for each session are here. Register and join!

    -

    Find the full meeting agenda for all three days here.

    -

    May 8-10, 2019

    -

    Villa Monastero, Varenna, Italy

    -
    - -

    SU2 has grown in just a few years from a small, open-source tool for aerodynamics, to a large community of users and developers with a passion for multidisciplinary optimization. As an open-source project, we believe in building a vibrant community, involving everyone in the spirit of open collaboration.

    -

    So, for the fourth consecutive year, we are gathering some of the most active development teams from around the world in one place to showcase the latest in SU2. We invite you to join us with the incredible scenery of Lake Como as the backdrop. And if you can't attend in person, you can always join virtually from the comfort of your sofa. Please register below today!

    - -

    This is what we have prepared for you:

    - -

      -
    • A new edition of 2018's successful hackathon!
    • -
    • A day full of presentations on what you can do with SU2, from our experienced developers all over the world.
    • -
    • An open discussion on the future of our project.
    • -

    - -
    -

    Politecnico di Milano is the local organiser of the event. More information on the venue and accomodation can be found here.


    +
    +
    +

    NEW: Our community voted for SU2 v7.0 "Blackbird" to be released soon!

    +

    Set future directions of SU2 by signing up.

    +
    - -
    +
    +

    What is SU2?

    -

    SU2 is an open-source collection of software tools written in C++ and Python for the analysis of partial differential equations (PDEs) and PDE-constrained optimization problems on unstructured meshes with state-of-the-art numerical methods. SU2 is a leading technology for adjoint-based optimization. Through the initiative of users and developers around the world, SU2 is now a well established tool in the computational sciences with wide applicability to aeronautical, automotive, naval, and renewable energy industries, to name a few.

    +

    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.

    - +
    @@ -71,7 +57,7 @@

    What is SU2?

    Stay informed.

    -

    Keep up with the latest announcements and events by registering for our mailing list and following us on twitter and facebook. For detailed updates on the source code, watch the SU2 repository on GitHub. +

    Keep up with the latest announcements and events by registering for our mailing list and following us on twitter and facebook. For detailed updates on the source code, watch the SU2 repository on GitHub.

    @@ -99,24 +85,22 @@

    Free and open. Always.

    - -
    + +

    Meet state-of-the-art.

    -

    SU2 isn't just software. It's a research platform. Catch up to the state-of-the-art and push the boundaries in your field with SU2.

    +

    SU2 isn't just software. It's a scientific research platform. Catch up to the state-of-the-art and push the boundaries in your field with SU2.

    -

    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.

    +

    SU2 is an open-source collection of software tools written in C++ and Python for the analysis of partial differential equations (PDEs) and PDE-constrained optimization problems on unstructured meshes with state-of-the-art numerical methods. Through the initiative of users and developers around the world, SU2 is now a well established tool with wide applicability to aeronautical, automotive, ship, and renewable energy industries, to name a few.

    @@ -130,3 +114,4 @@

    Meet state-of-the-art.

    + diff --git a/vandv_files/Bump_Channel/images/bump_cd_gridconv_sa.png b/vandv_files/Bump_Channel/images/bump_cd_gridconv_sa.png new file mode 100644 index 00000000..ed48d6c0 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cd_gridconv_sa.png differ diff --git a/vandv_files/Bump_Channel/images/bump_cd_gridconv_sst.png b/vandv_files/Bump_Channel/images/bump_cd_gridconv_sst.png new file mode 100644 index 00000000..cc5eb30c Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cd_gridconv_sst.png differ diff --git a/vandv_files/Bump_Channel/images/bump_cf_0p63_gridconv_sa.png b/vandv_files/Bump_Channel/images/bump_cf_0p63_gridconv_sa.png new file mode 100644 index 00000000..2c738fb8 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cf_0p63_gridconv_sa.png differ diff --git a/vandv_files/Bump_Channel/images/bump_cf_0p63_gridconv_sst.png b/vandv_files/Bump_Channel/images/bump_cf_0p63_gridconv_sst.png new file mode 100644 index 00000000..e58734c2 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cf_0p63_gridconv_sst.png differ diff --git a/vandv_files/Bump_Channel/images/bump_cf_0p75_gridconv_sa.png b/vandv_files/Bump_Channel/images/bump_cf_0p75_gridconv_sa.png new file mode 100644 index 00000000..8e6666fa Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cf_0p75_gridconv_sa.png differ diff --git a/vandv_files/Bump_Channel/images/bump_cf_0p75_gridconv_sst.png b/vandv_files/Bump_Channel/images/bump_cf_0p75_gridconv_sst.png new file mode 100644 index 00000000..b4222dcc Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cf_0p75_gridconv_sst.png differ diff --git a/vandv_files/Bump_Channel/images/bump_cf_0p87_gridconv_sa.png b/vandv_files/Bump_Channel/images/bump_cf_0p87_gridconv_sa.png new file mode 100644 index 00000000..d93b57f4 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cf_0p87_gridconv_sa.png differ diff --git a/vandv_files/Bump_Channel/images/bump_cf_0p87_gridconv_sst.png b/vandv_files/Bump_Channel/images/bump_cf_0p87_gridconv_sst.png new file mode 100644 index 00000000..7b4d54aa Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cf_0p87_gridconv_sst.png differ diff --git a/vandv_files/Bump_Channel/images/bump_cf_profile_sa.png b/vandv_files/Bump_Channel/images/bump_cf_profile_sa.png new file mode 100644 index 00000000..ec312855 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cf_profile_sa.png differ diff --git a/vandv_files/Bump_Channel/images/bump_cf_profile_sst.png b/vandv_files/Bump_Channel/images/bump_cf_profile_sst.png new file mode 100644 index 00000000..b81c5510 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cf_profile_sst.png differ diff --git a/vandv_files/Bump_Channel/images/bump_cl_gridconv_sa.png b/vandv_files/Bump_Channel/images/bump_cl_gridconv_sa.png new file mode 100644 index 00000000..57ce5346 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cl_gridconv_sa.png differ diff --git a/vandv_files/Bump_Channel/images/bump_cl_gridconv_sst.png b/vandv_files/Bump_Channel/images/bump_cl_gridconv_sst.png new file mode 100644 index 00000000..4b969ad0 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cl_gridconv_sst.png differ diff --git a/vandv_files/Bump_Channel/images/bump_cp_profile_sa.png b/vandv_files/Bump_Channel/images/bump_cp_profile_sa.png new file mode 100644 index 00000000..48a785c1 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cp_profile_sa.png differ diff --git a/vandv_files/Bump_Channel/images/bump_cp_profile_sst.png b/vandv_files/Bump_Channel/images/bump_cp_profile_sst.png new file mode 100644 index 00000000..0f5f4dc4 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_cp_profile_sst.png differ diff --git a/vandv_files/Bump_Channel/images/bump_eddy_profile_sa.png b/vandv_files/Bump_Channel/images/bump_eddy_profile_sa.png new file mode 100644 index 00000000..26139808 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_eddy_profile_sa.png differ diff --git a/vandv_files/Bump_Channel/images/bump_eddy_profile_sst.png b/vandv_files/Bump_Channel/images/bump_eddy_profile_sst.png new file mode 100644 index 00000000..355c36c2 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_eddy_profile_sst.png differ diff --git a/vandv_files/Bump_Channel/images/bump_k_profile_sst.png b/vandv_files/Bump_Channel/images/bump_k_profile_sst.png new file mode 100644 index 00000000..0bf2053d Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_k_profile_sst.png differ diff --git a/vandv_files/Bump_Channel/images/bump_omega_profile_sst.png b/vandv_files/Bump_Channel/images/bump_omega_profile_sst.png new file mode 100644 index 00000000..5f0e4452 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_omega_profile_sst.png differ diff --git a/vandv_files/Bump_Channel/images/bump_residual_convergence_sa.png b/vandv_files/Bump_Channel/images/bump_residual_convergence_sa.png new file mode 100644 index 00000000..66751ff6 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_residual_convergence_sa.png differ diff --git a/vandv_files/Bump_Channel/images/bump_residual_convergence_sst.png b/vandv_files/Bump_Channel/images/bump_residual_convergence_sst.png new file mode 100644 index 00000000..0fd20c4b Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_residual_convergence_sst.png differ diff --git a/vandv_files/Bump_Channel/images/bump_vel_profile_sa.png b/vandv_files/Bump_Channel/images/bump_vel_profile_sa.png new file mode 100644 index 00000000..1731c123 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_vel_profile_sa.png differ diff --git a/vandv_files/Bump_Channel/images/bump_vel_profile_sst.png b/vandv_files/Bump_Channel/images/bump_vel_profile_sst.png new file mode 100644 index 00000000..72b1e4d2 Binary files /dev/null and b/vandv_files/Bump_Channel/images/bump_vel_profile_sst.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/accuracy_max_rho.png b/vandv_files/FVM_Navier_Stokes/images/accuracy_max_rho.png new file mode 100644 index 00000000..c2723205 Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/accuracy_max_rho.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/accuracy_max_rhoe.png b/vandv_files/FVM_Navier_Stokes/images/accuracy_max_rhoe.png new file mode 100644 index 00000000..a5117474 Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/accuracy_max_rhoe.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/accuracy_max_rhou.png b/vandv_files/FVM_Navier_Stokes/images/accuracy_max_rhou.png new file mode 100644 index 00000000..c1efa156 Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/accuracy_max_rhou.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/accuracy_max_rhov.png b/vandv_files/FVM_Navier_Stokes/images/accuracy_max_rhov.png new file mode 100644 index 00000000..c9452d00 Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/accuracy_max_rhov.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/accuracy_rms_rho.png b/vandv_files/FVM_Navier_Stokes/images/accuracy_rms_rho.png new file mode 100644 index 00000000..a08c1829 Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/accuracy_rms_rho.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/accuracy_rms_rhoe.png b/vandv_files/FVM_Navier_Stokes/images/accuracy_rms_rhoe.png new file mode 100644 index 00000000..91db2c5b Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/accuracy_rms_rhoe.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/accuracy_rms_rhou.png b/vandv_files/FVM_Navier_Stokes/images/accuracy_rms_rhou.png new file mode 100644 index 00000000..670231b7 Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/accuracy_rms_rhou.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/accuracy_rms_rhov.png b/vandv_files/FVM_Navier_Stokes/images/accuracy_rms_rhov.png new file mode 100644 index 00000000..ba051eab Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/accuracy_rms_rhov.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/ns_mms.png b/vandv_files/FVM_Navier_Stokes/images/ns_mms.png new file mode 100644 index 00000000..154f8975 Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/ns_mms.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/ns_mms_density.png b/vandv_files/FVM_Navier_Stokes/images/ns_mms_density.png new file mode 100644 index 00000000..63202fab Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/ns_mms_density.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/ns_mms_mach.png b/vandv_files/FVM_Navier_Stokes/images/ns_mms_mach.png new file mode 100644 index 00000000..cf20e38d Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/ns_mms_mach.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/ns_mms_pressure.png b/vandv_files/FVM_Navier_Stokes/images/ns_mms_pressure.png new file mode 100644 index 00000000..5c265934 Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/ns_mms_pressure.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/slope_max_rho.png b/vandv_files/FVM_Navier_Stokes/images/slope_max_rho.png new file mode 100644 index 00000000..7cddffab Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/slope_max_rho.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/slope_max_rhoe.png b/vandv_files/FVM_Navier_Stokes/images/slope_max_rhoe.png new file mode 100644 index 00000000..1d5e872b Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/slope_max_rhoe.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/slope_max_rhou.png b/vandv_files/FVM_Navier_Stokes/images/slope_max_rhou.png new file mode 100644 index 00000000..8888e929 Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/slope_max_rhou.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/slope_max_rhov.png b/vandv_files/FVM_Navier_Stokes/images/slope_max_rhov.png new file mode 100644 index 00000000..e23f749d Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/slope_max_rhov.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/slope_rms_rho.png b/vandv_files/FVM_Navier_Stokes/images/slope_rms_rho.png new file mode 100644 index 00000000..83aeb5ac Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/slope_rms_rho.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/slope_rms_rhoe.png b/vandv_files/FVM_Navier_Stokes/images/slope_rms_rhoe.png new file mode 100644 index 00000000..191d7051 Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/slope_rms_rhoe.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/slope_rms_rhou.png b/vandv_files/FVM_Navier_Stokes/images/slope_rms_rhou.png new file mode 100644 index 00000000..ef452f35 Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/slope_rms_rhou.png differ diff --git a/vandv_files/FVM_Navier_Stokes/images/slope_rms_rhov.png b/vandv_files/FVM_Navier_Stokes/images/slope_rms_rhov.png new file mode 100644 index 00000000..3642bed3 Binary files /dev/null and b/vandv_files/FVM_Navier_Stokes/images/slope_rms_rhov.png differ diff --git a/vandv_files/Flat_Plate/images/flatplate_cd_gridconv_sa.png b/vandv_files/Flat_Plate/images/flatplate_cd_gridconv_sa.png new file mode 100644 index 00000000..ef778803 Binary files /dev/null and b/vandv_files/Flat_Plate/images/flatplate_cd_gridconv_sa.png differ diff --git a/vandv_files/Flat_Plate/images/flatplate_cd_gridconv_sst.png b/vandv_files/Flat_Plate/images/flatplate_cd_gridconv_sst.png new file mode 100644 index 00000000..b8903d33 Binary files /dev/null and b/vandv_files/Flat_Plate/images/flatplate_cd_gridconv_sst.png differ diff --git a/vandv_files/Flat_Plate/images/flatplate_cf_0p97_gridconv_sa.png b/vandv_files/Flat_Plate/images/flatplate_cf_0p97_gridconv_sa.png new file mode 100644 index 00000000..7d9c8d08 Binary files /dev/null and b/vandv_files/Flat_Plate/images/flatplate_cf_0p97_gridconv_sa.png differ diff --git a/vandv_files/Flat_Plate/images/flatplate_cf_0p97_gridconv_sst.png b/vandv_files/Flat_Plate/images/flatplate_cf_0p97_gridconv_sst.png new file mode 100644 index 00000000..e5fe239e Binary files /dev/null and b/vandv_files/Flat_Plate/images/flatplate_cf_0p97_gridconv_sst.png differ diff --git a/vandv_files/Flat_Plate/images/flatplate_cf_profile_sa.png b/vandv_files/Flat_Plate/images/flatplate_cf_profile_sa.png new file mode 100644 index 00000000..cbc08f75 Binary files /dev/null and b/vandv_files/Flat_Plate/images/flatplate_cf_profile_sa.png differ diff --git a/vandv_files/Flat_Plate/images/flatplate_cf_profile_sst.png b/vandv_files/Flat_Plate/images/flatplate_cf_profile_sst.png new file mode 100644 index 00000000..f1e3212c Binary files /dev/null and b/vandv_files/Flat_Plate/images/flatplate_cf_profile_sst.png differ diff --git a/vandv_files/Flat_Plate/images/flatplate_residual_convergence_sa.png b/vandv_files/Flat_Plate/images/flatplate_residual_convergence_sa.png new file mode 100644 index 00000000..d5befa70 Binary files /dev/null and b/vandv_files/Flat_Plate/images/flatplate_residual_convergence_sa.png differ diff --git a/vandv_files/Flat_Plate/images/flatplate_residual_convergence_sst.png b/vandv_files/Flat_Plate/images/flatplate_residual_convergence_sst.png new file mode 100644 index 00000000..6d1dbaa7 Binary files /dev/null and b/vandv_files/Flat_Plate/images/flatplate_residual_convergence_sst.png differ diff --git a/vandv_files/Flat_Plate/images/turb_plate_mesh_bcs.png b/vandv_files/Flat_Plate/images/turb_plate_mesh_bcs.png new file mode 100644 index 00000000..c54c72df Binary files /dev/null and b/vandv_files/Flat_Plate/images/turb_plate_mesh_bcs.png differ