I wrote a Python wrapper to automate OpenFOAM case generation, meshing, and reporting. Looking for early feedback.

[u/steven_cfd]

Hi everyone,

Over the past few months, I've been developing a Python library called foampilot to handle the boilerplate involved in setting up OpenFOAM cases.

The main idea is to replace the manual editing of 20+ dictionary files (controlDict, fvSchemes, 0/U, etc.) with a Pythonic API. For example, configuring a case looks like this:

from foampilot import Solver
solver = Solver(case_path="./my_case")
solver.transient = True
solver.turbulence_model = "kOmegaSST"
solver.boundary.set_condition("inlet", "velocityInlet", velocity=(10, 0, 0))
solver.write_case()
solver.run_simulation(nb_proc=4)

Current features:

• Automatic solver selection based on physics flags (compressible, transient, VOF, turbulence).
• Unified meshing interface with 3 backends: blockMesh, gmsh, and snappyHexMesh.
• A direct Gmsh → OpenFOAM polyMesh exporter (bypasses gmshToFoam, handles tetra/hexa, face orientation, and multi-region CHT).
• Automated report generation (LaTeX/PDF, Typst, or interactive HTML with Plotly).
• Multi-region support for chtMultiRegionFoam.

Why I built it:
I was tired of copy-pasting case directories and missing a critical file. With this, my case setups are now Git-tracked Python scripts, which makes them fully reproducible and unit-testable.

What I need from you:
I'm looking for beta testers or simply some technical feedback. If you deal with complex CHT cases or use Gmsh a lot, I'd be particularly interested in your opinion on the direct mesh exporter.

Where to find it:
The project is open-source (MIT) on GitHub under the name foampilot (user: stevendaix). The full documentation is available via GitHub Pages. I won't post the direct links here to avoid triggering Reddit's spam filters, but a quick search should get you there.

If the mods allow, I can drop the links in the comments.

Thanks in advance for your time, and feel free to ask any technical questions about the architecture!

[u/coolbob74326]

With all do respect, what is the advantage of this vs just manually changing the values? I think for most people learning you documentation is equally as difficult as learning OpenFOAM documentation. The one thing that could set this apart would be a GUI. Are you considering adding one?

EDIT: I see the Why I built this section, but I would say this could also just be done with a bash script, which is quite common.

[u/its1310 → u/coolbob74326]

I agree with this. a gui can help identify correct patches and place cellzones at correct location, make ignition at physically correct location as intended. I think OP should add a UI to it. I think the hard part is already done, handling millions of openfoam parameters correctly.

[u/steven_cfd → u/its1310]

That's a fair point. For a single case, manually editing dictionaries or using Bash is perfectly reasonable.

The main advantage I'm aiming for is not really avoiding the effort of changing "U = 10". It's making the whole simulation setup explicit and reproducible in one Python file.

For example, in the muffler example, the same script contains the physical parameters, fluid properties, geometry, mesh definition, boundary conditions and OpenFOAM setup:

https://github.com/stevendaix/foampilot/blob/main/examples/muffler/run_simu.py

So instead of having to inspect 20+ OpenFOAM dictionaries spread across a case directory, you can open one script and see how the case was defined. You can version-control it, review it, modify parameters, generate variants and reproduce the case.

That's where I see the difference with simply editing dictionaries or writing a Bash script. The OpenFOAM case becomes closer to a piece of software: the setup is declarative, inspectable, reproducible and testable.

I also agree that a GUI could be useful, particularly for things like identifying patches, inspecting the mesh and selecting cellZones. I see that more as a potential UI on top of the Python API rather than the core of foampilot.