Introducing OpenFLUME
John Rising · 2026-11-01
Over ten years ago at Virgin Galactic, I needed to model a fluid network, and I ended up writing my own basic solver to do it.
Later, at Relativity Space, we needed one again. So I hired the engineer who had written the same kind of solver for SpaceX, and he wrote one for us. Eight years later, he's still maintaining it.
That's not unusual. It's what most teams in this field end up doing. The established tools for this kind of problem are NASA's GFSSP and C&R's SINDA/FLUINT, and both are good codes with a lot of heritage. But you have to request or license them and install them, and neither lets you read the implementation behind a result. And sooner or later you need to extend it anyway. The systems people actually work on are hard and complicated, and each one comes with its own special considerations and its own questions you need to ask. So organization after organization, and project after project, writes its own application-specific network code, validates it a little, and maintains it for years.
This is a solved problem that keeps getting solved again, privately, at great expense. It shouldn't be. So here's an open one.
OpenFLUME (Open FLUid Model Environment) is a finite-volume thermo-fluid network solver you can run in a web app in your browser or as a Python package. It's MIT-licensed. It's also alpha software, at version 0.3.1, so treat it that way.
The solver I kept not finishing
I knew, more-or-less, how I wanted to build and test it. That was never the hard part.
The hard part was the sheer amount of it. Nodes that store mass and energy and branches that carry flow are the easy part. Real-fluid properties, solid walls that conduct and radiate, transients that don't fall over, and then a verification record a stranger could actually rerun and believe? That's years. I would chip away at a rough draft every so often, get a little further, and run out of steam again.
This year, with a lot of AI help, I finally got it far enough that I think it's better than GFSSP or SINDA/FLUINT for a lot of cases. How the AI helped, and where it didn't, gets its own post.
No install, and your model stays on your machine
I wanted something an engineer could open on a locked-down corporate laptop without filing a ticket with IT. I also wanted students and researchers to be able to use it without waiting on a license or an approval.
So the web app is just static files. The solver runs locally via your browser or Python, and real-fluid properties come from CoolProp, compiled to WebAssembly and shipped with it. Nothing you build gets uploaded anywhere.¹
What it does
If you've used GFSSP or SINDA/FLUINT, the basic idea will feel familiar. You draw nodes and branches, and it solves coupled mass, momentum, and energy, with Newton–Raphson for steady problems and backward Euler for transients. The user manual covers all of it in more detail than anyone wants, but here's the gist.
- 19 branch types, from plain pipes and orifices up to cavitating venturis, regulators, and capillary channels
- Real fluids from CoolProp's 124-fluid catalog, plus ideal-gas and incompressible models
- Conjugate heat transfer with solid walls
- Transient two-phase flow with film boiling, for chilldown
- Opt-in compressible duct flow, including Fanno and Rayleigh choking and nozzles
- Combustion chambers coupled to NASA CEA tables
- Custom components, schedules, logic rules, and PID controllers, so you can model a system the way it's actually operated
- A Python package (
pip install openflume) that drives the same solver
The fastest way to get a feel for it is to open an example and poke at it. Tank blowdown is the simplest transient. If you want something harder, Cryogenic line cooldown chills a 61 m copper line with liquid hydrogen. There are 14 in the examples gallery.
Verification
Each verification case is labeled as analytic verification, comparison with another code, or comparison with experiment (§8.1). The reports are generated by scripts that run the current solver.
The compressible-flow report recreates NASA's GFSSP TFAWS-2007 verification study case for case, and all five cases land inside that paper's agreement band. The microfluidics report rebuilds six published networks from their papers. Cryogenic chilldown is compared against measured data from NBS Report 9264 (§8.4).
Most of the record is analytic. The experimental side is narrow, and chilldown agrees within an engineering band rather than as a precision prediction.
What it can't do
Read the full list in §1.7 before you lean on a result. The big ones are below.
- No shock capture, so no over-expanded nozzles and no thrust
- No acoustic waves, so no water hammer
- Cavitation only inside the cavitating-venturi model
- Two-phase flow is homogeneous equilibrium only
- Custom components run your JavaScript with no sandbox, so treat them like code
Try it, and tell me where it's wrong
Open Sanity: orifice hand-calc and click Run. The orifice should match the hand calculation of 0.8485 kg/s to within 0.5 %. Then open Tank blowdown, run it, and plot the tank pressure. That's the whole onboarding. The getting-started guide goes further.
The most useful thing you can send me is a case where OpenFLUME disagrees with a reference you trust. Tell me what the reference says and how close you expected it to be, and open an issue. A published validation case that covers something the current reports don't is almost as good (CONTRIBUTING.md).
I wrote my first version of this ten years ago because nothing open existed. I'd like the next engineer in that position to just click a link.
If OpenFLUME helps your work, the citation is on Zenodo at 10.5281/zenodo.22051608.
Notes
- Keeping your model on your machine doesn't settle export-control questions by itself. Those are still yours to judge.