---
name: vibeflow-su2
description: Use when preparing, running, debugging, post-processing, or extending VibeFlow/VibeCAE SU2 CFD, heat-transfer, adjoint, deformation, and optimization workflows from 0-caseDict/caseDict, including SU2 config files, mesh conversion, history monitoring, restart files, and reusable SU2 case templates.
---

# VibeFlow SU2

This skill is responsible for using SU2 as the compressible/incompressible CFD, aerodynamic analysis, adjoint optimization, mesh deformation, and multiphysics backend for VibeCAE.

- Usage mode: generate SU2 configuration files, mesh entries, run scripts, and post-processing from `caseDict`.
- Development mode: develop SU2 templates, configuration generators, optimization workflows, post-processors, or SU2 source extensions when explicitly needed.

## When To Use

- The task involves external aerodynamics, airfoils/wings/aircraft, compressible flow, incompressible flow, heat conduction, weak fluid-structure coupling, adjoint sensitivity, or optimization.
- `.cfg` generation and runs with `SU2_CFD`, `SU2_DEF`, `SU2_DOT`, or `SU2_SOL` are needed.
- `history.csv`, `surface_flow.csv`, restart files, and volume/surface output need to be read.
- OpenFOAM is not the best backend, or the user explicitly selects SU2.

## First Decision: Usage Mode Or Development Mode

- Configuration, execution, convergence, and post-processing for the current case: use usage mode.
- Template generators, optimization drivers, mesh converters, or SU2 source extensions: use development mode.
- If SU2 commands, MPI, or the Python wrapper are unavailable or abnormal: switch to `vibeflow-toolchain` first.
- If geometry or mesh is not ready yet: switch to `vibeflow-geometry` / `vibeflow-mesh` first.

## What To Read First

- Flow model, boundaries, reference quantities, mesh, numerical schemes, convergence criteria, and optimization objectives in `0-caseDict/caseDict`.
- `references/su2-playbook.md`
- `references/su2-practical-tips.md`: software knowledge base, key concepts, failure interpretation, and adapter design points.
- Meshes under `B-mesh/` that can be used or converted for SU2.
- Existing `C-run/su2/`, `D-post/`, and `Ref/`.

## Inputs

- `0-caseDict/caseDict`
- SU2 mesh or convertible mesh
- Reference geometry, boundary names, Mach number, Reynolds number, angle of attack, thermal boundaries, and objective functions

## Outputs

- `C-run/su2/case-*/config.cfg`
- `C-run/su2/case-*/mesh.*`
- `C-run/su2/case-*/Allrun` / `Allclean`
- `history.csv`, surface/volume output, and restart files
- `D-post/su2_postprocess.py`

## Recommended Structure

```text
C-run/su2/
└── case-1/
    ├── config.cfg
    ├── mesh.su2
    ├── logs/
    ├── results/
    ├── restarts/
    ├── Allrun
    └── Allclean
```

## Usage-Mode Workflow

1. Map `caseDict` to SU2 configuration: `SOLVER`, `KIND_TURB_MODEL`, `MACH_NUMBER`, `REYNOLDS_NUMBER`, boundary markers, CFL, iteration count, and convergence monitoring.
2. Check whether mesh boundary markers are consistent with `caseDict`.
3. Generate `config.cfg`, keeping comments that explain key physical and numerical choices.
4. Run a short-iteration smoke test to check configuration parsing and boundary recognition.
5. Run the full case and monitor residuals, lift/drag, objective functions, or heat flux.
6. Use post-processing scripts to generate convergence curves, force coefficients, surface distributions, and required field files.
7. Write outputs, convergence status, and failure reasons back to `caseDict`.

## Development-Mode Workflow

1. Clarify the development target: configuration template, parameter sweep, adjoint optimization driver, mesh-deformation workflow, or SU2 source extension.
2. Write the development note first, recording the SU2 version, module commands, configuration interface, inputs, outputs, and validation example.
3. For template generators, preserve marker mapping and reference-quantity calculation notes.
4. For source extensions, prefer an independent branch or external directory, and do not directly modify the system installation.
5. Use at least one official tutorial or minimal case as a smoke test.

## Core Rules

- The SU2 configuration file is the executable artifact; `caseDict` is the source of truth for physical intent.
- Marker names, reference area, reference length, angle of attack, and Reynolds-number definitions must be explicit.
- For adjoint or optimization tasks, verify that the primal computation is stable before running the adjoint.
- Do not assume OpenFOAM patch names are SU2 markers; always inspect the conversion result.

## Validation

- SU2 commands are available.
- Mesh markers can be recognized by SU2.
- `config.cfg` can start at least a short run.
- `history.csv` or an equivalent monitor file is generated.
- Convergence curves and target quantities can be read by the post-processing script.

## Fallback Rules

- Boundary markers are inconsistent: return to the mesh stage.
- Physical reference quantities are unclear: return to `vibeflow-case-dict`.
- SU2 environment unavailable: return to `vibeflow-toolchain`.
- Results diverge: check mesh, CFL, boundaries, turbulence model, and initial values first.