Sid Sharma.CV
Home / Projects / Software and modeling tools
Typed handoffs between narrow agents, with a human approval gate before anything runs. The language model can propose, but it can never authorize execution

CFD Agents

Prototype software

An experimental, typed Python framework for guarded agentic workflows around OpenFOAM. Language models can interpret a request, explain a failure or propose a next step. Deterministic code, explicit contracts and human approval control what actually runs. A run that finishes can still be numerically wrong, and a numerically sound run can still be physically wrong.

RequestCase specPhysics & scale checksNumericsCase & meshReview gateExecuteNumerical healthPhysical validation
Methods & tools
Python · pydantic contracts · cfd CLI · OpenFOAM through WSL, SSH, native or HPC backends · NVIDIA Object-Oriented Agents (NOOA) · local (Ollama) or hosted models · provenance records · unit tests
Links
github.com/sidsharma2/cfd-agents ↗Apache-2.0
Project breakdown

WhatWhy guard the agent

Setting up a CFD case is a chain of decisions: which solver, which numerics, what mesh and what boundary conditions. Each decision can be wrong while the run still finishes. That gap is the whole reason this project exists.

A language model is useful to read a request or to explain a crash. But it should not be the thing that decides a case is ready to run, or that a converged run is physically right.

I built the framework around that separation. It keeps three claims apart and checks each one separately:

\[\text{execution success}\;\not\Rightarrow\;\text{numerical success}\;\not\Rightarrow\;\text{physical validation}\]

A run that ends cleanly can still have unbounded fields or poor conservation. A numerically healthy run can still be the wrong physics for the question.

HowNarrow agents, typed handoffs

Each agent does one job and hands a typed, validated artifact to the next:

  • Larry turns a request into a case specification.
  • Newton computes the scales that decide the regime.
  • Reggie sets the solver and numerics policy.
  • Betty writes the fields and dictionaries, and Bob handles the mesh.
  • Vera reviews the case before it runs.
\[\mathrm{Re}=\frac{UL}{\nu},\qquad \mathrm{Ma}=\frac{U}{a},\qquad \mathrm{CFL}=\frac{U\,\Delta t}{\Delta x}\]

The scale checks are computed deterministically before any numerics are chosen. They set laminar or turbulent, compressible or not, and the admissible time step.

Nothing executes until a human approves the exact plan. Then Bill runs only what was approved. After the run, Connie checks numerical health (residuals, conservation, boundedness, Courant number). Murphy diagnoses failures and gives them as proposals for a human to accept.

Language-model output enters only as a typed proposal, and the deterministic gates check it. It runs locally on the laptop behind my OpenFOAM work, described on the Sandia Flame D page. A bad run there wastes scarce compute time, which is part of why I guard execution so carefully.

ResultsScope of the prototype

The repository is public, with a citation file. It deliberately publishes no case results. The public copy leaves out private cases, meshes and logs, and the smallest end-to-end example is a mock lid-driven-cavity pipeline.

The framework is a prototype, with clear limits:

  • The post-processing and physical review agents are incomplete.
  • There is no complete reacting-flow or turbulence-model selection.
  • The LES stage of the round-jet sequence is an unverified extension.
  • A run that the framework completes is not a validated result. Physical validation still needs comparison with reference data.

The same contracts and journaled approvals are the base of AetherCFD Studio, the desktop workbench built on top of this framework.