-
Configuration File
Mesh File
Restart File
Solver Setup
Physical Definition
Markers and Boundary Conditions
Convective Schemes
Slope Limiters and Shock Resolution
History and Solution Output
Linear Solvers and Preconditioners
Basics of Multi-Zone Computations
Execution
Aeroacoustic analysis of unsteady pressure
Flamelet Solver — Python Wrapper Wall Boundary Conditions
Output Fields Reference
Error Messages
-
Setup Guide: Steady RANS for External Aerodynamics
Setup Guide: Incompressible Flows
Setup Guide: Unsteady Flows and DES
Setup Guide: Laminar-Turbulent Transition
Setup Guide: Turbomachinery
Setup Guide: Heat Transfer and Conjugate Heat Transfer
Setup Guide: Species Transport and Combustion
Setup Guide: Shape Optimization with the Discrete Adjoint
Setup Guide: Non-Ideal Compressible Flows
-
Option Reference
Problem Definition
FluidModel
Data-driven fluid model parameters
Freestream Conditions
Reference Conditions
Boundary Markers
Time-marching
Linear solver definition
Convergence
Multi-grid
Spatial Discretization
Adjoint and Gradient
Sobolev Gradient Solver Parameters
Input/output files and formats
Dynamic mesh definition
Aeroelastic Simulation (Typical Section Model)
Wind Gust
Equivalent Area
Grid deformation
Deformable mesh
FEM flow solver definition
FEA solver
Multizone definition
Radiation solver
Heat solver
Visualize Control Volumes
Inverse design problem
Unsupported options
FFD point inversion
Automatic Differentation options
Python Options
Hybrid_RANSLES Options
Output Options
libROM options
Renamed and Removed Options
-
GIT-ting Started
Developing SU2 on GitHub (Internal Developers)
Running Regression Tests
Code Review
Code Structure
Style Guide
Advanced AD Techniques
Containers for Development
Writing Unit Tests
Integrating Tracy Profiler with SU2
Automatic Differentiation (AD)
Code Reference (Doxygen)
Debugging SU2
Documentation Improvements and Status
Glossary
Docs Check
GIT-ting 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 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 (join the SU2 slack channel or open a GitHub discussion to get in touch).
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 regularly 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, and when everything looks good, your changes will merge into the main development branch!
General Guidelines
- If you have a very clear plan for the work you are doing, open a draft pull request so that the maintainers can start reviewing early.
- If you are working on a large feature (1k+ lines of code (loc), or 200+ loc with changes to 10+ files) ask to be added to the SU2 organization to work from the SU2 repo directly instead of your fork (this makes reviewing easier).