OpenFOAMGPT: LLM-Driven CFD Automation

• OpenFOAMGPT is an agent-based system that leverages large language models to automate computational fluid dynamics workflows in OpenFOAM.
• The framework employs a modular pipeline with Builder, Executor, and Interpreter agents to convert natural language queries into executable simulation cases.
• Its multi-agent variant features specialized agents for preprocessing, simulation, and postprocessing, achieving 100% reproducibility in extensive CFD benchmarks.

OpenFOAMGPT is an agent-based system that harnesses LLMs for automating computational fluid dynamics (CFD) workflows in OpenFOAM. This framework integrates advanced natural language processing with symbolic execution and direct program synthesis, enabling significant reductions in manual effort for setup, execution, and error correction of OpenFOAM simulations. OpenFOAMGPT adopts both monolithic and multi-agent architectural variants, with iterative developments demonstrated across distinct research efforts (Pandey et al., 10 Jan 2025, Wang et al., 2 Apr 2025, Feng et al., 27 Apr 2025).

1. System Architecture and Workflow

OpenFOAMGPT utilizes a modular, agent-oriented pipeline that translates user intent in natural language into fully-defined OpenFOAM cases. The original architecture employs a three-tiered control flow:

• Builder: Receives system prompt and user query, performs prompt templating (optionally with chain-of-thought priming), and generates a structured execution plan that delineates tasks (e.g., generate blockMeshDict, set boundary conditions, run solver).
• Executor: Orchestrates LLM calls, manages control flow and iterative correction, and directs error-initiated feedback loops.
• Interpreter: Converts LLM outputs into OpenFOAM dictionary files, enforces syntax, and validates structure.

An OpenFOAM runner module executes the simulation, captures logs, and drives the error correction feedback loop. Up to 20 iterations may be attempted per case to resolve LLM- or syntax-induced errors autonomously. Retrieval-augmented generation (RAG) can be enabled to provide in-context tutoring from indexed OpenFOAM tutorial examples, but was decoupled in some benchmarking to isolate zero-shot generalization capacity (Wang et al., 2 Apr 2025).

The 2.0 variant extends this system via a four-agent, tightly coupled multi-agent architecture:

• Pre-processing Agent: Parses natural language queries, extracts simulation parameters, and determines mesh strategy (e.g., blockMesh or snappyHexMesh).
• Prompt Generation Agent: Constructs templated LLM prompts for each simulation instance.
• Simulator Agent: Generates all OpenFOAM input files, executes the workflow, parses error logs, and iterates correction until convergence.
• Post-processing Agent: Automatically generates and executes field extraction, analysis, and visualization routines (Python scripts, ParaView VTK exports) (Feng et al., 27 Apr 2025).

Each agent operates deterministically (temperature=0), passing structured outputs through the pipeline to ensure bitwise reproducibility.

2. Task Spectrum and Automation Methodology

OpenFOAMGPT automates a range of CFD tasks:

• Case generation: Full pipeline from mesh creation to control file and dictionary population, including blockMeshDict generation, boundary and initial conditions, turbulence model selection, and solver parameter specification.
• Boundary and solver modification: Automated adjustment of boundary conditions (e.g., transition from fixed value to coded time-dependent types), turbulence models (RNG $k$-$\epsilon$, $k$-$\omega$ SST, LRR, LES closures), and time-stepping controls.
• Iterative error correction: Upon runtime errors, logs are appended to the next LLM query, and the loop iterates until a valid, converged case setup is obtained or the iteration cap is reached.
• Domain adaptation: Through RAG, the system can specialize its prompting and outputs for subdomains (e.g., aerospace, energy) by retrieving contextualized, annotated example cases from a vector database (Pandey et al., 10 Jan 2025).

Prompting best practices identified include minimal in-context few-shot examples for non-trivial entries (e.g., inclusion of a smoother entry in fvSolution), chain-of-thought decomposition ("list all patches, then assign types"), and explicit enumeration of required OpenFOAM dictionary keywords.

3. Quantitative Performance and Cost Analysis

Extensive validation has been performed using diverse OpenFOAM tutorials and real-world scenarios:

• Accuracy (zero-shot boundary/initial-condition tasks, $N=23$):

| Model | Success Rate | |----------------|-------------| | ChatGPT-4o | 74% | | OpenAI-o1 | 83% (on subset) | | Qwen 2.5-Max | 65% | | DeepSeek-V3 | 57% |

• Complex case generation: For scenarios such as "rising bubble" and "falling droplet," convergence was achieved within 8–20 iterations at token costs of \$0.25–\$0.67 (Qwen-pricing scale). API cost for OpenAI-o1 is $\sim14 \times$ greater per token than Qwen 2.5-Max, but provides improved reliability in complex flows. DeepSeek-V3 is 100$\times$ cheaper than o1 but less stable.
• Reproducibility and trustworthiness: OpenFOAMGPT 2.0 achieves 100% simulation success and reproducibility rates over 450+ automated runs, with identical outputs across repeated streams. This is tied to agent specialization, strict prompt grammars, dockerized execution, and temperature-zero LLM inference (Feng et al., 27 Apr 2025).
• RAG/few-shot enhancement: Incorporating 30k tokens per retrieval increases success rates by +10 pp at a marginal (\textasciitilde15–20%) cost increment, significantly reducing iteration count and error rates in edge cases.

4. Failure Modes, Human Oversight, and Domain Limitations

Despite robust autonomous correction, several failure classes persist:

• Boundary/patch keyword omissions: Omission of required entries (e.g., missing smoother in fvSolution, use of type patch instead of empty for a symmetry plane) leads to simulation or initialization errors that cannot be resolved without explicit prompt or human intervention.
• Multi-phase/reactive solver complexity: Zero-shot performance degrades on setups requiring rare solver settings (e.g., custom interFoam- or reactingFoam-specific parameters, user-defined fields, or dynamic mesh controls).
• Performance drift and oversight: LLM model behavior can change with provider updates, requiring domain expert review in production engineering environments.

Practitioner guidance highlights the necessity of expert-in-the-loop review for:

• Complex geometries with intricate mesh zones, cyclic/empty patching, or coupled boundary conditions.
• Edge-case dictionary configurations, seldom-used solver directives, and custom code inclusions.

Best practices involve hybrid prompting strategies, with chain-of-thought priming and context-rich enumeration favored for nontrivial or error-prone cases (Wang et al., 2 Apr 2025).

5. Multi-Agent Advances: OpenFOAMGPT 2.0 and Extensible Pipelines

Multi-agent orchestration as seen in OpenFOAMGPT 2.0 and independently in Foam-Agent 2.0 (Yue et al., 17 Sep 2025) delivers end-to-end, deterministic simulation pipelines from a single user prompt. Distinguishing features:

• Workflow Decomposition: Separates preprocessing (intent extraction and parametrization), mesh generation (native, Gmsh, external import), configuration writing (dependency-aware, stateful), simulation execution (local/HPC, auto-Slurm/PBS scripts), log review and error fixing, and postprocessing (Python/ParaView scripts).
• Composable APIs: The Model Context Protocol (MCP) exposes each agent's function in a strongly-typed, composable manner for integration into broader agentic workflows.
• RAG Enhancement: Hierarchical multi-index retrieval (four FAISS indices: structure, details, scripts, documentation) driven by context-aware filtering; ablation demonstrates an improvement in benchmarked task success (single-index: 44.6%, hierarchical RAG: 57.3%, plus autonomous Reviewer: 88.2%) (Yue et al., 17 Sep 2025).
• HPC/autosubmission: Automatic detection of cluster details in query, with dynamic script generation conforming to site-specific directives.

6. Benchmarking, Validation Cases, and Impact

Representative validation cases span single- and multi-phase flows, porous media transport, grid/saturation/viscosity parametric studies, and automotive/aero external flows. Notable case classes:

• Poiseuille flow and mesh-dependence: Analytical vs. numerical solution comparison, achieving $\| u_{num} - u_{anal} \|_2 < \epsilon$.
• Grid and property sweeps: Automated benchmarks for grid-independence, REV determination, and parameter-space exploration.
• Aerodynamic performance: Automated drag coefficient calculation for canonical geometries (e.g., motorbike, airfoil), with full postprocessing and comparison to analytical/experimental/previous numerical benchmarks.

Performance, reproducibility, and simulation accuracy with OpenFOAMGPT 2.0 remain at 100% within the tested regime, with wall-clock overhead below 5% relative to manual OpenFOAM execution (Feng et al., 27 Apr 2025).

7. Limitations and Future Directions

OpenFOAMGPT in its current multi-agent incarnation targets OpenFOAM v2406 exclusively; extending to custom solvers, user-compiled plugins, or other CFD platforms (e.g., SU2, ANSYS Fluent) is an explicit development path. Large-scale HPC workflows (>1000 cores), ambiguous queries, and advanced multiphysics (FSI, combustion) require further agent specialization and logic.

Anticipated areas of focus include:

• Fine-tuning mid-sized LLMs (20–50B parameters) with curated CFD corpora to minimize API cost and maximize robustness.
• Multimodal integration, accepting mesh/CAD/snapshot inputs for enhanced geometry and patch assignment.
• Automated unit-testing and micro-prompting for dictionary validation and more granular error correction.
• Integration of uncertainty quantification and full optimization pipelines.

OpenFOAMGPT establishes a reproducible, extensible foundation for agent-driven, natural-language-based simulation orchestration in CFD, substantially lowering expertise barriers and accelerating parametric exploration, with emerging success in deterministic scientific computing (Wang et al., 2 Apr 2025, Pandey et al., 10 Jan 2025, Feng et al., 27 Apr 2025, Yue et al., 17 Sep 2025).