input_writer generates Foundation OpenFOAM v10 files with no indication — breaks on ESI OpenFOAM installations

[jasoncbraatz]

Summary

When using the input_writer MCP tool (or the underlying initial_write() function), the generated case files use Foundation OpenFOAM v10 naming conventions exclusively. This is undocumented at the tool level and causes immediate failures when users attempt to run cases on ESI OpenFOAM (e.g., v2312, v2406, v2512), which is widely used in industry via Homebrew, package managers, and compiled installations.

Environment

• Foam-Agent: latest (Docker image foam-agent:latest)
• Target OpenFOAM: ESI OpenFOAM v2512 (installed via Homebrew on macOS Apple Silicon)
• MCP Client: Claude Desktop (stdio transport)

Reproduction Steps

1. Use input_writer to generate a buoyancy-driven natural convection case (candle flame plume)
2. Attempt to run the generated case on ESI OpenFOAM v2512

What Happens

The generated files use Foundation-specific names and dictionary keys that ESI OpenFOAM does not recognize:

Generated (Foundation v10)	Required (ESI v2512)	Error
constant/physicalProperties	constant/thermophysicalProperties	fileNotFound
constant/momentumTransport	constant/turbulenceProperties	fileNotFound
object momentumTransport	object turbulenceProperties	dictionary lookup failure
model kEpsilon (inside RAS dict)	RASModel kEpsilon	missing entry
solver buoyantFoam	solver buoyantBoussinesqPimpleFoam or buoyantPimpleFoam	command not found

Each of these required manual debugging and file renaming/editing to resolve.

Suggested Enhancement

Add an optional openfoam_version or openfoam_fork parameter to the input_writer tool (and plan tool) that accepts values like foundation-v10 (default) or esi-v2512. When set to an ESI target, the generated files should use ESI naming conventions.

At minimum, the tool's output or documentation should clearly state that generated files target Foundation OpenFOAM v10 specifically, so users with ESI installations know to expect naming differences.

Workaround

We worked around this by:

1. Running the generated case inside the Foam-Agent Docker container (which bundles Foundation OpenFOAM v10)
2. Manually renaming files and editing dictionary keys for ESI compatibility

Additional Context

The README does state "OpenFOAM v10" as a requirement, but when using Foam-Agent as an MCP server integrated into an AI coding assistant, users may not realize "v10" means specifically the Foundation fork. ESI's version numbering (v2512, etc.) makes this especially confusing since both are "OpenFOAM" but with divergent file conventions.

This is a quality-of-life enhancement that would save significant debugging time for users on ESI installations. Thank you for the excellent tool! 🙏

[LeoYML]

Thanks. These are very good suggestions.

We will update the MCP tool description and the README immediately (in 1 day).

We will also support more OpenFOAM versions in the near future (in 2 weeks). This will require more work because we need to prepare a new RAG database and re-benchmark it.

[LeoYML]

We updated the documents and the MCP tool descriptions according to your suggestions. We will support more OpenFOAM versions in the future. We plan to support OpenFOAM v13. For ESI OpenFOAM, which version do you suggest supporting?

[jasoncbraatz]

Thanks. These are very good suggestions.

We will update the MCP tool description and the README immediately (in 1 day).

We will also support more OpenFOAM versions in the near future (in 2 weeks). This will require more work because we need to prepare a new RAG database and re-benchmark it.

I'm here to help in any way too! I'm actually a researcher in CFD (and a recovering dev - I'm still trying to start a Dev Anonymous but it turns out each dev is already anonymous so there went that dream..) kidding aside, just holler if I can take something off of your plate.. I'm pretty quick.

For your ESI question - v2312 is the one to target. It's the most widely deployed ESI version right now — it's what most industry users, cloud HPC providers (AWS, Azure CFD images), and university clusters have standardized on. It's been essentially the "LTS" of the ESI world. The good news is that the naming conventions(turbulenceProperties, thermophysicalProperties, solver binaries) have been stable across ESI versions for years. So supporting v2312 effectively gives you v2406 and v2512 for free — A v2512 install has the exact same file naming as v2312. The differences between ESI releases are mostly new solvers and internal numerics, not dictionary format changes.. finally something that stays static! :-)

This work is terrific !

Admittedly we are all (in CFD community) kind of miffed off about ESI vs Foundation differences - and I'm admitting publicly that I'm one of them in that crowd. That said, compared to an off the shelf like Ansys.. something like $30k a license per year? Not sure that (or other CFD simulation models) are worth anywhere near that compared to the computational flexibility and ability to tune the solvers in OpenFlow. That's why it's the forever favorite of the big aerospace giants over the off the shelf software.

So again, great job, and I'm here if you need me in any way - happy to help!

[LeoYML]

Yes, sure, we can keep in touch and cooperate in the future, you can find my name in our paper, and find me on LinkedIn.
If you want to join the development of Foam-Agent, I am very appreciate it, for example, if you want to support the ESI v2312, I can help review your code and finally merge it to our main branch.

The potential tasks for supporting this:

1. Collect the tutorials from the ESI v2312 and build the RAG database.
2. Optimize the input writer prompt.
3. Change the mcp tool description or support more mcp tools, treat the OpenFOAM as one of the optional parameters.

We plan to support OpenFOAM v13 and ESI v2312 in the near future, but in recent days, we are working on fine-tuning the best open-source model in our community. Some users want to use Foam-Agent with an open source model, but the current open source model is not smart, especially for the CFD domain. This project may have more priority than supporting more OpenFOAM versions. Anyway, we will try to support them one by one. We are a small team; we need more cooperation to help.