| 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
C-run/su2/
└── case-1/
├── config.cfg
├── mesh.su2
├── logs/
├── results/
├── restarts/
├── Allrun
└── Allclean
Usage-Mode Workflow
- Map
caseDict to SU2 configuration: SOLVER, KIND_TURB_MODEL, MACH_NUMBER, REYNOLDS_NUMBER, boundary markers, CFL, iteration count, and convergence monitoring.
- Check whether mesh boundary markers are consistent with
caseDict.
- Generate
config.cfg, keeping comments that explain key physical and numerical choices.
- Run a short-iteration smoke test to check configuration parsing and boundary recognition.
- Run the full case and monitor residuals, lift/drag, objective functions, or heat flux.
- Use post-processing scripts to generate convergence curves, force coefficients, surface distributions, and required field files.
- Write outputs, convergence status, and failure reasons back to
caseDict.
Development-Mode Workflow
- Clarify the development target: configuration template, parameter sweep, adjoint optimization driver, mesh-deformation workflow, or SU2 source extension.
- Write the development note first, recording the SU2 version, module commands, configuration interface, inputs, outputs, and validation example.
- For template generators, preserve marker mapping and reference-quantity calculation notes.
- For source extensions, prefer an independent branch or external directory, and do not directly modify the system installation.
- 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.