AI Agents for CFD: The Case Ran. Is the Answer Right?

The log says it finished

The log ends the way you want a log to end. The solver reached its end time, the residuals fell, and the agent reports that the simulation completed. In a 2026 test of coding agents on OpenFOAM, the researchers looked at the meshes behind runs like that. In two of four obstacle-flow cases built with one of the models, the mesh did not represent the obstacle.

You can simulate flow past a cylinder without the cylinder. It converges beautifully.

AI agents for CFD can now take a sentence of text, write an OpenFOAM case, run it, read the errors and fix them, and on benchmark tasks most of those cases run to the end. Fewer of them are right. This article separates the two using the researchers’ own numbers, shows the failures that pass every log check, and gives a review routine for any case an agent hands you. I have no agent to sell and no objection to them. I would like them checked.

What do these agents actually do?

The idea is the same across the systems that have appeared in the last two years. A large language model receives your request. It retrieves similar tutorial cases and documentation, writes the case files, runs the mesher and the solver, reads the log, and edits the files when something fails. It repeats until the run completes or it gives up.

The named systems differ in how they organise that loop. Foam-Agent splits the work between several agents, with a layered retrieval system for different parts of a simulation, file generation that keeps the dictionaries consistent with each other, and an error-correction loop meant to resolve failures without human intervention. ChatCFD adds structured knowledge bases, an error locator and a component that writes a physical summary of the result. Researchers have also tested general-purpose coding agents with an OpenFOAM-focused prompt and nothing else.

OpenFOAM is the natural target. A case is a folder of plain-text dictionaries, the solver runs from the command line, and the log is text. A language model can read and write every part of it, which cannot be said of a solver driven through a graphical interface.

What do the success rates measure?

This is the part worth slowing down for.

Three things stand out.

• The same tool scores very differently on different benchmarks. Foam-Agent reports 83.6% on its authors’ tasks and scores 42.3% on ChatCFD’s. Neither number is wrong. They measure different tasks, and a success rate means little until you know the tasks.
• Running and being right are separate scores. ChatCFD’s own figures give 82.1% for runs that complete and 68.12% for physical fidelity. If every faithful case is also one that ran, which seems likely, then about one completed run in six was not physically meaningful by the authors’ own measure. That is my arithmetic on their numbers, and it is the most useful figure in the table.
• Some measures do check the answer. The metrics Xiao and colleagues report include an error against reference cases, which is how the last row can say how close 7 of the 9 runs came to the reference, in addition to whether they finished. That is the right kind of measure. It is harder to score well on, which is why you should always ask which kind a figure is.

Why are the hard errors the quiet ones?

The 2026 assessment by Xiao and colleagues at Peking University is the most candid paper in this small field, and it is worth reading for its failures.

On tutorial-like cases, a carefully prompted agent completed every run and came close to the reference on most. On planar obstacle flows, where the mesh had to be built rather than copied, things changed. With one model, in two of four cases the mesh did not represent the obstacle. In another run the agent reused a tutorial mesh without updating the geometry. A stronger model produced better meshes, and one mesh type still needed repeated human guidance. In preliminary high-speed combustion tests the agent could not reach a stable configuration by editing files in response to the log.

What the agent did well was fix errors that produce messages. An unsupported setting, a missing entry, a misspelt keyword: the log names the problem, and the agent repairs it. The authors’ conclusion is plain. Failing to represent the obstacle in the mesh, or other physics-related problems, is hard for agents to catch, and human oversight remains essential.

So the agents are best at the errors that announce themselves and weakest at the ones that do not. For an engineer that is exactly the wrong way round, because the errors that announce themselves were never the dangerous ones. A solver that crashes has told you something. A solver that converges on the wrong geometry has told you nothing, very convincingly.

The quiet errors, by family

These are the classes of mistake that pass every log check. None is specific to AI; humans make all of them. The difference is that an agent copying from tutorials makes them at speed, and an agent reading only the log has no way to notice.

• Geometry. A missing or misplaced feature, or a mesh scaled in millimetres when the vertices were written in metres.
• Units. Incompressible OpenFOAM solvers work with kinematic pressure, pressure divided by density, in m²/s². Forces then need a reference density that someone has to supply.
• Inherited settings. The viscosity, turbulence quantities, inlet profiles and end time of the tutorial the case started from, left in place because nothing complained.
• Plausible boundary conditions that are wrong for this problem. A wall function on a mesh nobody checked for y+, or a zero-gradient condition where a fixed value belonged.
• Too short a run. An unsteady case stopped before the flow reached its periodic state, then averaged.

A worked example: two errors that look perfect

Error 1: the millimetre cylinder. Take a standard benchmark: flow past a cylinder of diameter 0.1 m in a channel, with a mean inflow velocity of 1 m/s and a kinematic viscosity of 0.001 m²/s. The Reynolds number is 100, and the flow sheds vortices.

Now suppose the agent starts from a tutorial whose blockMesh dictionary scales all vertices by 0.001, and writes the new vertices in metres. The cylinder is now 0.1 mm across.

That is creeping flow. There is no shedding, the solver converges quickly and smoothly, and the residual plot is the prettiest you will see all week. The checkMesh utility prints the bounding box of the domain, so one glance at its output catches this. A log-reading agent never looks there, because nothing went wrong.

Error 2: forces 18% low and coefficients exactly right. In an incompressible OpenFOAM case, the forces function object multiplies kinematic pressure by a reference density, rhoInf, to get pascals and then newtons. Suppose the fluid is air at 1.225 kg/m³ and the agent leaves rhoInf at 1, as in many tutorials. Every force is then low by the same factor.

The force coefficient function object divides by ½ ρ U² A using the same rhoInf, so the density cancels and the drag coefficient comes out correct. The coefficient plot looks perfect, and the report that quotes drag in newtons is wrong. I like this example because it survives exactly the check a careful person would make first, comparing C_D with a published value.

Both sets of numbers here are illustrative. The mechanisms are real.

A test case with known answers

If your team wants to evaluate an agent, or a new engineer, give it a problem with a published reference. The DFG benchmark for laminar flow around a cylinder, case 2D-2 from Schäfer and Turek (1996), is a good choice: two-dimensional, cheap, unsteady and documented to several digits.

The setup on the FeatFlow benchmark page is a channel 2.2 m long and 0.41 m high, with a cylinder of radius 0.05 m centred at (0.2, 0.2). The inflow is parabolic with a maximum of 1.5 m/s and a mean of 1.0 m/s, the kinematic viscosity is 0.001 m²/s and the density is 1, which gives Re = 100 on the diameter. The reference values on the finest mesh are:

Ask the agent for the case from a plain-language description, without naming the benchmark, and compare. A Strouhal number near 0.30 and a peak drag coefficient near 3.2 on a reasonable mesh say the setup is sound. No oscillation at all says something is missing: the cylinder, the unsteadiness, the resolution or the end time.

Notice that the cylinder sits slightly off the channel centreline, at 0.2 m in a channel 0.41 m high. Keep it there. An agent that tidies the geometry into a symmetric position has changed the benchmark, and its answer no longer compares with the reference.

How I would review a case an agent wrote

In this order. Most of it takes minutes.

1. Write down what you expect before you open the results. The quantities you care about and a rough range for each, from a hand estimate, a correlation or a previous study.
2. Look at the mesh before the flow. Run checkMesh, read the bounding box and open the geometry. Is every feature there, at the right size, in the right place?
3. Diff the case against the tutorial it came from. The agent will tell you what it changed. The dangerous lines are the ones it did not touch: viscosity, turbulence inputs, end time, write interval, function object settings.
4. Check units and reference values. Kinematic or static pressure, rhoInf, the viscosity in the transport dictionary, and the Reynolds number worked out by hand from the case files.
5. Read every boundary condition file, field by field, and ask whether it describes the physical problem. The log cannot answer that.
6. Check convergence and the balances. Mass in equals mass out, and energy too if it is solved. The convergence article on this blog covers what converged should mean.
7. Compare with something independent. A benchmark, a correlation, a measurement or a previous verified case. That is the difference between verification and validation, explained in its own article on this blog.
8. If the numbers will drive a decision, test the mesh. A mesh independence study applies to an agent’s mesh exactly as it does to yours.

This takes longer than writing the prompt. It takes much less time than writing the case.

Where AI agents for CFD help today

Where there is already a verified case and the agent changes parameters within it: a sweep over inlet velocities, a set of geometric variants of a validated design, a batch of post-processing scripts. The dangerous decisions were taken once, by a person, and the agent repeats the safe ones.

Where the work is boilerplate: function object dictionaries, sampling lines, scripts that turn a folder of results into a table.

Where the error is loud: a case that will not start, a dictionary with a syntax error, a missing library entry. Here the published agents are already good, and they save real time.

And in teaching, carefully. A student who sees a complete, running case in a minute learns the structure of OpenFOAM faster. The same student has to be taught to distrust it, which is a lesson worth more than the case.

Where I would not use them without a full review: new physics, three-dimensional industrial geometry, reacting or multiphase flows, and anything without a reference to compare with. The 2026 assessment names 3D and industrially relevant cases as future work, and its combustion tests did not stabilise. That is where the field stands this year.

What I would ask before adopting one

If someone proposes an AI agent for your team’s CFD setup, ask four questions.

• Which success metric is the figure? A run that completed and a result close to a reference are different numbers, sometimes far apart.
• On whose cases? A benchmark of tutorial variants says little about your geometry.
• What does the agent check before it reports success? If the answer is the log, you now know what it misses.
• Who reviews the case, and against what? If nobody, the agent is producing very fast, very tidy uncertainty.

The short version

Agents for CFD are real and improving quickly. They fix the errors that print messages and miss the ones that do not. Treat an agent’s case the way you would treat one from a capable new colleague in their first week: grateful for the time saved, and reading every file before anything leaves the building.

If you are at a conference this month where AI is on every slide, ask the speaker one question: of the cases that ran, how many were right?

For the broader question of whether trained models will replace simulation, see the article Will AI replace CFD? on this blog. If you have an agent-built or inherited model and want it checked file by file, that is what a model review is for.