Foam-Agent 2.0: Composable CFD Automation

• Foam-Agent 2.0 is a composable multi-agent framework that automates OpenFOAM CFD simulations from natural language prompts.
• It integrates specialized agents for meshing, configuration, execution, debugging, HPC submission, and visualization using a dynamic LangGraph workflow engine.
• The system enhances reliability with dependency-aware file generation and iterative error correction, demonstrating improved success rates across diverse CFD cases.

Foam-Agent 2.0 is a composable multi-agent framework for automating end-to-end Computational Fluid Dynamics simulation in OpenFOAM from a single natural language prompt. In the formulation reported in "Foam-Agent 2.0: An End-to-End Composable Multi-Agent Framework for Automating CFD Simulation in OpenFOAM," its scope extends across preprocessing, configuration generation, execution, iterative debugging, HPC submission, and post-simulation visualization, while exposing core capabilities as callable services through the Model Context Protocol (MCP) rather than only as a monolithic workflow (Yue et al., 17 Sep 2025). Relative to the earlier Foam-Agent, it retains hierarchical multi-index retrieval, dependency-aware file generation, and iterative error correction, but broadens the operational envelope to include a Meshing Agent, a Visualization Agent, external mesh ingestion, Gmsh-based geometry creation, Slurm script generation, and ParaView-based post-processing (Yue et al., 8 May 2025).

1. Lineage and problem setting

Foam-Agent 2.0 emerges from a line of work concerned with the steep learning curve of OpenFOAM and the manual burden of CFD case construction. The earlier Foam-Agent was introduced as a multi-agent framework that automates complex OpenFOAM-based CFD simulation workflows from natural language inputs, with three named technical innovations: a hierarchical multi-index retrieval system, a dependency-aware file generation system, and an iterative error correction mechanism (Yue et al., 8 May 2025). Foam-Agent 2.0 preserves those design commitments while reframing the system as an end-to-end and composable platform.

The architectural expansion is substantive rather than cosmetic. Foam-Agent employed four specialized agents—Architect Agent, Input Writer Agent, Runner Agent, and Reviewer Agent—organized in an iterative loop in which errors are analyzed, files corrected, and the process repeated until a successful run or a maximum iteration limit is reached (Yue et al., 8 May 2025). Foam-Agent 2.0 comprises six primary agentic components, adding a Meshing Agent and a Visualization Agent, and it extends execution beyond local runs to HPC clusters through automatic generation of HPC submission scripts (Yue et al., 17 Sep 2025). The paper also positions the framework as the first system to manage the full simulation pipeline, explicitly including advanced pre-processing with external mesh files and Gmsh, HPC submission support, and post-simulation visualization via ParaView (Yue et al., 17 Sep 2025).

This shift matters because OpenFOAM workflows are not reducible to file synthesis alone. The practical bottlenecks include geometry and mesh creation, consistency across 0/, constant/, and system/, execution orchestration, failure diagnosis, and post-processing. Foam-Agent 2.0 is defined by addressing all of those stages within one coordinated framework.

2. Multi-agent composition and orchestration

Foam-Agent 2.0 is organized around six specialized agents, each dedicated to a distinct portion of the OpenFOAM workflow (Yue et al., 17 Sep 2025).

Agent	Role
Architect Agent	Interprets the natural language prompt and plans files, folders, and dependencies
Meshing Agent	Handles OpenFOAM-native meshing, Gmsh, and external mesh import/conversion
Input Writer Agent	Generates OpenFOAM configuration files with dependency and consistency enforcement
Runner Agent	Executes simulations locally or on HPC clusters and monitors jobs
Reviewer Agent	Diagnoses log-file errors and coordinates iterative correction
Visualization Agent	Generates post-processing and visualization scripts using ParaView and/or Pyvista

The coordination layer is not described as a simple linear script. The execution flow is managed via a LangGraph stateful workflow engine, where nodes map to agentic tasks and transitions respond to conditional logic such as success, errors, and retries (Yue et al., 17 Sep 2025). The same source describes the workflow as dynamic and adaptive: the system creates an execution plan based on the user’s requirements and the current state, with agents delegating subtasks and correcting errors as needed.

A defining addition in Foam-Agent 2.0 is its composable service architecture. Using MCP, the framework exposes core functions as discrete, callable tools, enabling integration by other agentic systems such as Claude-code for exploratory workflows (Yue et al., 17 Sep 2025). The named MCP functions include create_case, plan_simulation_struct., generate_file_content, generate_mesh, generate_hpc_script, run_simulation, check_job_status, get_simulation_logs, review_and_suggest_fix, apply_fix, and generate_visualization. The paper characterizes this interface in terms of atomicity, statefulness, and decoupling: each function performs a minimal task, jobs are tracked by IDs, and meshing, file generation, execution, correction, and visualization can be invoked independently or chained.

A common misconception is that a multi-agent CFD framework must behave as a single opaque autonomous actor. Foam-Agent 2.0 explicitly rejects that pattern. Its MCP exposure makes the system callable as a set of tool-like services, while LangGraph provides the stateful orchestration needed for full workflows.

3. End-to-end OpenFOAM workflow

Foam-Agent 2.0 covers the full OpenFOAM simulation pipeline from preprocessing to visualization (Yue et al., 17 Sep 2025). In preprocessing, the Meshing Agent supports OpenFOAM-native meshing, Gmsh via Python API, and import or conversion of external mesh files such as .msh, blockMeshDict, and snappyHexMeshDict. For Gmsh-based workflows, the agent generates a Python script to define geometry and mesh, executes it, and converts the resulting .msh file to OpenFOAM’s polyMesh format. For imported meshes, it processes the mesh inside the OpenFOAM environment and maps boundary names and types accordingly.

Configuration generation respects OpenFOAM’s standard directory hierarchy. The system/ directory contains control parameters and solver or time-step controls; constant/ contains physical property and turbulence models; 0/ contains initial and boundary conditions (Yue et al., 17 Sep 2025). The Input Writer Agent generates these files with explicit awareness of inter-file dependencies and uses schema validation tools such as Pydantic to enforce syntactic correctness and semantic consistency.

Execution is handled by the Runner Agent. It supports both local and HPC runs, can generate Slurm job scripts automatically when the user requests HPC resources or the problem size demands them, submits jobs, monitors progress, and captures logs (Yue et al., 17 Sep 2025). If failures occur, error data are routed to the Reviewer Agent, which proposes context-aware corrections and coordinates refinement cycles.

Post-processing is treated as a first-class stage rather than an afterthought. The Visualization Agent generates and executes visualization scripts using Pyvista or ParaView Python bindings, supports user-specified fields and visualization parameters, and, if an initial plotting attempt fails, iteratively debugs the plotting script until a successful PNG output is saved (Yue et al., 17 Sep 2025). This makes visualization part of the automated closure of the workflow.

The importance of this end-to-end design lies in closure. Earlier agentic systems often concentrated on case setup or retrieval. Foam-Agent 2.0 instead packages meshing, execution, debugging, and visualization into a single operational loop.

4. Retrieval, dependency management, and iterative refinement

The technical core of Foam-Agent 2.0 is a combination of hierarchical multi-index retrieval-augmented generation, dependency-aware file generation, and iterative refinement (Yue et al., 17 Sep 2025). The retrieval system segments domain knowledge into four specialized indices: Structure, Details, Execution Scripts, and Command Documentation. Rather than querying a monolithic knowledge base, the retriever selects the index aligned to the current stage of the simulation pipeline and formats the result as stage-specific context.

The paper gives the retrieval process in algorithmic form:

$$E \gets \operatorname{Embed}(q), \quad I \gets \operatorname{SelectIndex}(s), \quad R_i \gets \operatorname{TopK}(I, E, k=5), \quad R_f \gets \operatorname{FilterByRelevance}(R_i, q, c), \quad r \gets \operatorname{FormatContext}(R_f, s).$$

The earlier Foam-Agent describes the same basic design as a hierarchical multi-index retrieval system with specialized indices for tutorial structure, tutorial details, execution scripts, and command documentation, using 1536-dimensional vectors from OpenAI text-embedding-3-small and FAISS for retrieval (Yue et al., 8 May 2025). That continuity indicates that Foam-Agent 2.0 is not a wholesale replacement of prior mechanisms, but an extension of them into a broader workflow.

Dependency-aware file generation addresses the fact that many OpenFOAM failures arise from inconsistencies across files. Both Foam-Agent and Foam-Agent 2.0 model files as nodes in a directed acyclic graph and generate them in an order determined by dependencies (Yue et al., 8 May 2025). In the earlier formulation, the generation plan is written as $P = \{F_1, F_2, ..., F_n\}$, and contextual generation for a file $F_i$ includes previously written files $C_i$ as context. Foam-Agent 2.0 gives a concrete sequencing example: generate system/ configurations first, then constant/, then 0/, with later files referencing prior outputs for parameter consistency and constraint validation (Yue et al., 17 Sep 2025).

Iterative refinement closes the loop between generation and execution. Foam-Agent 2.0 states the process as:

$$P \gets \operatorname{Architect}(R), \quad G \gets \operatorname{Meshing}(R), \quad F^0 \gets \operatorname{InputWriter}(P),$$

followed by repeated Runner, error parsing, Reviewer, and Apply steps until success or a maximum number of attempts is reached (Yue et al., 17 Sep 2025). The earlier Foam-Agent makes the correction objective explicit as an optimization-style condition:

$$\text{Find } \Delta F \text{ such that } E(F + \Delta F) = \emptyset, \quad C(F + \Delta F) = \text{TRUE}.$$

It also maintains a review trajectory history $H = \{(F_i^1, E^1), ..., (F_i^n, E^n)\}$ for iterative solution generation (Yue et al., 8 May 2025).

These three mechanisms—stage-specific retrieval, dependency-aware generation, and iterative correction—are the primary explanation offered by the papers for high executable success rates and improved robustness.

5. Benchmark evidence and demonstrated capabilities

Foam-Agent 2.0 is evaluated on 110 OpenFOAM cases spanning a range of physics such as turbulent and laminar flows, multiphase, and combustion (Yue et al., 17 Sep 2025). Success is defined as a generated case configuration that runs to completion without error and produces correct outputs.

System	Claude 3.5 Sonnet	GPT-4o
MetaOpenFOAM	55.5%	17.3%
OpenFOAMGPT-Alt	37.3%	45.5%
Foam-Agent 2.0	88.2%	59.1%

The earlier Foam-Agent reported 83.6% success with Claude 3.5 Sonnet and 59.1% with GPT-4o on a dataset of 110 simulation tasks, with MetaOpenFOAM at 55.5% and OpenFOAM-GPT at 37.3% for Claude 3.5 Sonnet (Yue et al., 8 May 2025). Read together, the two papers present a version-to-version improvement from 83.6% to 88.2% under Claude 3.5 Sonnet, while retaining the same GPT-4o figure of 59.1%.

The ablation results in Foam-Agent 2.0 localize the gains. Inclusion of the Reviewer Agent is described as key, with success rate jumping from approximately 50% to above 80%; dependency-aware file generation aids error convergence by reducing reviewer loop count; and Hierarchical Multi-Index RAG outperforms single-index retrieval, with reported improvements from 44.6% to 57.3% without reviewer and from 84.6% to 88.2% with reviewer (Yue et al., 17 Sep 2025). The earlier paper similarly found that removing the error correction mechanism led to a 55.4% drop and that the specialized error correction mechanism provided a 36.4% performance improvement (Yue et al., 8 May 2025).

Qualitative case studies in Foam-Agent 2.0 include CounterFlowFlame, wedge, and forward step, where the agent’s output is described as closely matching human expert ground truth, unlike MetaOpenFOAM which produces physically or geometrically incorrect results (Yue et al., 17 Sep 2025). The paper also reports advanced capabilities beyond basic case setup: successful import of external .msh files with correct boundary assignment, Gmsh Python script generation for complex geometries, resource-aware Slurm script generation for parallel HPC runs, and self-correcting visualization generation for ParaView and Pyvista.

6. Limitations, misconceptions, and relation to lightweight coding agents

A common misconception is that end-to-end OpenFOAM automation necessarily requires either a monolithic LLM workflow or, conversely, an elaborate multi-agent stack. A preliminary assessment of tool-using coding agents for OpenFOAM shows a third design point: a general-purpose coding agent with a CFD-focused prompt, tutorial-first reuse, minimal edits, and log-driven repair can execute all 9 tutorial-derivative cases in FoamBench-Advanced with MiniMax-M2.1 and can complete 4/4 tested planar 2D obstacle-flow cases with GPT-5.2, while using a substantially lighter configuration than specialized multi-agent systems (Xiao et al., 12 Feb 2026).

That comparison is technically important for interpreting Foam-Agent 2.0. The preliminary assessment argues that model capability is the primary bottleneck for mesh and geometry creation, and it attributes strong gains in advanced 2D tasks directly to stronger backbones such as GPT-5.2 (Xiao et al., 12 Feb 2026). It also states that agentic search over file systems and tutorial corpora using shell commands can be operationally simpler than vector-database retrieval stacks for OpenFOAM workflows. This suggests that part of Foam-Agent 2.0’s design space should be understood not as settled architecture, but as one point on a spectrum between specialized composable frameworks and prompt-centered general coding agents.

The same assessment also marks the current limits of automation. It states that subtle physics or mesh errors not producing explicit log errors can go undetected without human oversight; that the method is robust for tutorial-like and simpler 2D tasks but struggles as geometrical or physical complexity increases, notably in 3D, combustion, and unstable flows; and that human-in-the-loop validation remains essential when automated agents may not recognize physics or data errors lacking explicit log signatures (Xiao et al., 12 Feb 2026). A plausible implication is that executable success, while necessary, is not sufficient as the sole criterion for scientific reliability in automated CFD pipelines.

Within that broader landscape, Foam-Agent 2.0 can be situated as a high-capability, high-coverage framework: it couples specialized agents, MCP-based composability, dependency-aware generation, and reviewer-driven repair to automate a larger share of the OpenFOAM lifecycle than earlier systems. At the same time, adjacent evidence indicates that future iterations will likely continue to be shaped by two variables already visible across the literature: backbone model capability and the balance between architectural specialization and lightweight prompt-driven control.