agentsclimarketplace

Openfoam

Skill svd-ai-lab/sim-plugin-openfoam/src/sim_plugin_openfoam/_skills/openfoam

Use when the user asks Codex, Claude Code, or another AI coding agent to run, inspect, or debug OpenFOAM cases through sim-cli. Supports case checks, solver execution, log inspection, result artifacts, replayable CFD workflows, and benchmark tasks.From its SKILL.md

Install
npx -y skills add svd-ai-lab/sim-plugin-openfoam --skill openfoam

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
  • runs commandsInstructs the agent to run 5 commands, including `uv run sim run solve.py --solver openfoam` and 4 more.

SKILL.md

7.5 KB, ~1.9k tokens by cl100k_base, as published. Nobody here has run it

openfoam-sim

You are driving OpenFOAM through sim-cli. This file is the index. Detail lives in references/ — load progressively, only what the task needs.


How to load this skill

Don't read every reference up front — context is precious. Walk this list:

  1. Always read references/case-setup.md before authoring any case.
  2. Pick a solver via references/solver-selection.md.
  3. Look up the fields & dictionaries you'll need in references/field-and-dictionary-matrix.md.
  4. For boundary conditions: references/boundary-conditions.md.
  5. If the case has turbulence: references/turbulence-setup.md.
  6. If the case is multiphase / VOF: references/multiphase-vof.md.
  7. If the case has heat or buoyancy: references/heat-transfer.md (and references/conjugate-heat-transfer.md for solid+fluid).
  8. For mesh generation: references/mesh-and-blockmesh.md.
  9. For schemes / solvers / relaxation: references/numerics-and-schemes.md.
  10. For runtime monitors / probes / forces: references/function-objects.md.
  11. For parallel execution and decomposition: references/parallel-execution.md.
  12. For runtime log diagnosis: references/log-parsing-and-residuals.md.
  13. For post-processing (sample lines, point queries, integrals): references/post-processing.md.
  14. For complete case skeletons by scenario: references/case-recipes.md.
  15. When something fails: references/error-recovery.md — decision tree + fix sequences.

sim-cli integration (one-shot mode)

Most benchmark/single-shot use is one-shot:

# 1. Write your driver script. Conventionally `solve.py`.
#    The script invokes blockMesh / solver / postProcess via subprocess,
#    parses the result, and writes the answer to disk.

# 2. Run via sim-cli:
uv run sim run solve.py --solver openfoam

# sim wraps the script in a RunResult (exit_code, stdout, stderr, duration,
# errors) and stores it under `.sim/runs/`. Browse with:
uv run sim logs                     # list runs
uv run sim logs last                # full last RunResult
uv run sim logs last --field exit_code

Persistent-session mode (uv run sim serve + uv run sim connect/exec/inspect/disconnect) is supported when sim-server is reachable, but is not required for typical case authoring.


Work sequence (the protocol)

Before writing any OpenFOAM file, classify the case:

  • Time: steady or transient?
  • Compressibility: incompressible or compressible?
  • Phases: single-phase, two-phase (VOF), or multi-region?
  • Turbulence: laminar, RANS (k-ε / k-ω SST / SpalartAllmaras), or LES/DNS?
  • Heat/buoyancy: isothermal, forced convection, or buoyancy-driven?

This classification fixes the solver family (see solver-selection.md), the required field set (see field-and-dictionary-matrix.md), and the turbulence boundary recipe (see turbulence-setup.md).

Then, in this order:

  1. Mesh (blockMesh or snappyHexMesh); validate with checkMesh.
  2. Fields in 0/: one per required field; consistent patch names with the mesh.
  3. Properties in constant/: transport, turbulence, thermophysical (when relevant).
  4. Numerics in system/: controlDict, fvSchemes, fvSolution. Start conservative (upwind, low CFL, tight relaxation) and upgrade after the case is stable.
  5. Run the chosen solver; tail the log; check the convergence signals (references/log-parsing-and-residuals.md).
  6. Post-process to extract the requested KPI.

Validate at every layer — don't push to "run solver" before checkMesh is clean and the field files reference patches that exist in the mesh.


Hard guardrails

These are mistakes LLMs make often. Don't.

  • Don't invent dictionary keys, patch types, or solver names. Every key in controlDict / fvSchemes / fvSolution / transportProperties / field files comes from a closed vocabulary. If you're not sure the key exists, look it up rather than guess.
  • Don't mix turbulence-model fields. k-ε needs k + epsilon + nut; k-ω SST needs k + omega + nut; Spalart-Allmaras needs nuTilda + nut. Mixing fields across models causes solver to abort at startup.
  • Don't use p when the solver expects p_rgh. Buoyant solvers (buoyantBoussinesqSimpleFoam, buoyantSimpleFoam, chtMultiRegionFoam) and VOF (interFoam) want p_rgh. Pure incompressible (icoFoam, simpleFoam, pimpleFoam) want p.
  • Don't use linear (central differencing) for alpha.water convection in VOF. It's unbounded; alpha will blow past [0,1]. Use vanLeer or MUSCL via the interfaceCompression family.
  • Don't set relaxation factors to 1.0 in steady-state SIMPLE without consistent yes (SIMPLEC). It's a recipe for divergence on most cases.
  • Don't keep aggressive second-order convection schemes on a fragile case. Stabilize with upwind first, upgrade to linearUpwind once residuals are well-behaved.
  • Don't treat checkMesh warnings as optional if the log is already diverging. Most divergence on a fresh case is a mesh-quality issue.
  • Don't assume 0/ exists. Many tutorials ship 0.orig/ and rely on Allrun to copy it; if you skip Allrun, do it yourself: cp -r 0.orig 0.
  • Don't run on more MPI ranks than numberOfSubdomains in decomposeParDict. They must match, or mpirun will hang or crash.

Output expected

When you finish, produce a short summary that states:

  • Solver and physics family chosen
  • Required fields and dictionaries authored
  • Turbulence model + wall treatment (if any) + estimated inlet turbulence
  • Numerical schemes used and any relaxation choices
  • Convergence signal observed (End reached? final residuals? continuity errors?)
  • The requested KPI value, with units
  • Any stability concerns or follow-up recommendations

For benchmark/grader contexts, this summary is implicit in the produced /tmp/agent/result.json — you still benefit from doing the mental checklist before submitting.


Reference index

FileWhen to read
references/case-setup.mdAlways, first
references/solver-selection.mdPicking a solver / pressure convention
references/field-and-dictionary-matrix.md"What files do I need?" lookup
references/boundary-conditions.mdConcrete BC syntax per type
references/turbulence-setup.mdAny turbulent case
references/mesh-and-blockmesh.mdMesh generation, blockMesh, checkMesh
references/numerics-and-schemes.mdfvSchemes, fvSolution, relaxation, algorithm controls
references/multiphase-vof.mdTwo-phase / VOF cases
references/heat-transfer.mdBuoyant or compressible-thermal
references/conjugate-heat-transfer.mdMulti-region fluid + solid
references/parallel-execution.mddecomposePar, MPI, reconstructPar
references/log-parsing-and-residuals.mdDiagnosing solver progress + convergence
references/post-processing.mdpostProcess, sample, point queries
references/function-objects.mdRuntime monitors (probes, forces, yPlus)
references/case-recipes.mdComplete skeletons by scenario
references/error-recovery.mdFailure decision tree + fix sequences
references/failure_patterns.mdCatalog of historical failures (legacy)

What ships with it: 29 files

175.2 KB alongside SKILL.md, 3 of them executable

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.