SU2: open-source CFD built for adjoint optimisation

SU2 — Stanford University Unstructured — is an open-source suite for computational fluid dynamics and, distinctively, for PDE-constrained optimisation. It originated in Juan Alonso’s group at Stanford, is released under the LGPL, and is now maintained by an international community.

As a flow solver it is compressible-oriented and aerospace-flavoured: RANS with the common turbulence models, transonic and supersonic flow, and unstructured meshes. If that were all it did, it would be one CFD code among several.

What makes it worth a separate integration is that adjoint capability was designed in from the beginning rather than added later.

Shape optimisation asks a question that is normally unaffordable. If your design variables are the positions of surface points, you may have thousands of them, and finding the gradient by finite difference means one flow solve per variable. At an hour a solve, that is not an optimisation loop — it is a year.

The adjoint method inverts the cost. By solving one additional adjoint problem alongside the flow solution, it produces the sensitivity of your objective to every design variable at roughly the cost of one extra solve, independent of how many variables there are. Thousands of gradients for the price of two runs.

SU2 implements both forms. The continuous adjoint derives the adjoint equations from the governing PDEs and then discretises them; the discrete adjoint differentiates the discretised solver itself, using algorithmic differentiation, and is exactly consistent with the flow solution it came from. Having both is unusual, and the discrete adjoint in particular is what makes gradients trustworthy enough to hand to an optimiser.

The output is a sensitivity map over the surface showing where moving the geometry would improve the objective and by how much — useful to a designer even without an automatic optimisation loop attached. More on the method in parametric studies and optimisation.

Not a competition so much as a division of labour. OpenFOAM is the broader general-purpose tool: wider physics coverage — multiphase, free surface, combustion, conjugate heat transfer — plus its own automatic mesher in snappyHexMesh, and a far larger user community.

SU2 is the one to reach for when aerodynamic shape design is the objectiverather than a single flow answer. OpenFOAM does have adjointOptimisationFoam, but it is less mature and less central to the project than SU2’s adjoint is to SU2.

SU2 also expects a mesh from elsewhere, so it does not replace the meshing half of an OpenFOAM workflow.

A case is driven by a single configuration file — conventionally .cfg — listing solver type, physics, numerical schemes, boundary conditions and, for an optimisation, the objective, the design variables and the constraints. It is flat and readable, and it is long: a shape optimisation configuration involves a great many interacting settings, and getting a gradient-based loop to behave requires understanding what most of them do.

Shape optimisation adds machinery beyond the solver: parameterising the surface, deforming the mesh as the shape changes without destroying its quality, and driving the outer optimisation loop. Mesh deformation in particular is where these workflows tend to fail — a shape change large enough to be interesting is often large enough to invert cells.