Foundation, ESI/Keysight/OpenCFD, or foam-extend? A Practical Guide to the Three OpenFOAM Branches
“OpenFOAM” isn’t one piece of software with one release schedule — it’s a name shared by three actively developed, independently governed codebases that diverged from the same origin and have been evolving separately for over a decade. On cloudHPC we now provide foam-extend 5.0 alongside both the OpenFOAM Foundation release and OpenCFD’s release (the branch now under Keysight Technologies following its 2025 acquisition of ESI Group), and the question we get most often is simple: which one should I actually use?
There’s no universally correct answer — it depends on your case, your solvers, and how much you value bleeding-edge features versus a stable, well-validated baseline. Here’s the breakdown.
A shared origin, three separate paths
All three branches trace back to the original FOAM/OpenFOAM codebase released under GPL in 2004. The split happened progressively: OpenCFD (the company behind the original release) was acquired by Silicon Graphics International in 2011, which led to the creation of the non-profit OpenFOAM Foundation to hold the trademark and steward an independent release line. OpenCFD itself became part of ESI Group in 2012 and resumed releasing its own version directly from 2016 onward — and as of May 2025, ESI Group (and with it OpenCFD) was acquired by Keysight Technologies, which now maintains that branch. foam-extend, meanwhile, is a community fork maintained by Wikki Ltd and contributors that split off early to preserve and extend features the other branches didn’t carry forward.
Three governance models, three release cadences, three sets of priorities. That’s the real story behind “which version should I use.”
OpenFOAM Foundation (openfoam.org)
Governance: Non-profit, community-governed, currently at major version 13, releasing roughly once a year.
Character: The Foundation branch prioritizes stability, backward compatibility, and a clean, well-documented core. It’s the version most closely aligned with the code style and structure taught in university courses and the official OpenFOAM tutorials, and several practitioners report it gives closer agreement with experimental validation data on certain turbulent-flow benchmarks compared to the ESI branch — worth knowing if your work leans toward research validation rather than industrial throughput.
Best fit for: Academic use, teaching, research reproducibility, and any workflow where you want a slower-moving, thoroughly reviewed core without a six-month feature-churn cycle to track.
OpenCFD / Keysight (openfoam.com)
Governance: Corporate-backed (Keysight Technologies, via the ESI/OpenCFD business unit), bi-annual releases (June and December — most recently v2506 and v2512).
Character: This is the fastest-moving branch, and it shows in the feature set: overset mesh support (independently moving/overlapping mesh regions, useful for multi-body relative motion problems), the #eval and broader function-object/expression syntax for dynamic dictionary evaluation, and generally the first branch to receive new turbulence models, multiphase solver improvements, and GPU/accelerator-oriented development. Because of the faster cadence, it also tends to be the branch industrial CFD teams gravitate toward when they need a feature that just isn’t in the other two yet.
Best fit for: Industrial applications with moving/overset geometry, teams that want the newest solver capabilities as soon as they land, and anyone already working inside the broader Keysight/ESI simulation ecosystem.
foam-extend 5.0
Governance: Community-driven fork maintained by Wikki Ltd, slower and less frequent releases (5.0 is the current stable line), but distinguished by features that were either never merged upstream or were dropped from the other branches along the way.
Character: foam-extend is the specialist’s branch. It carries a genuinely different solver architecture in places (fvBlockMatrix for fully-implicit block-coupled solving, used for example in advanced porous-media and coupled multiphase solvers) and is the branch of choice for:
- Fluid-Structure Interaction (FSI) — the
FluidStructureInteractiontoolkit provides implicit (strong) coupling between fluid and solid solvers via the IQN-ILS algorithm, going well beyond the weak/explicit coupling available elsewhere. - Turbomachinery — enhanced sliding-mesh and GGI (Generalized Grid Interface) capabilities specifically developed and validated for rotating-machinery cases.
- Solid mechanics and coupled physics — the
solidMechanicstoolbox and related structural solvers, useful when a case genuinely needs solid-domain physics rather than a fluid-only treatment. - Advanced numerics for niche physics — block-coupled solvers for heterogeneous porous media, acoustic cavitation modeling via Helmholtz-equation solvers, and other research-grade capabilities that live in the “extend-bazaar” ecosystem around the core release.
Best fit for: FSI problems, turbomachinery with sliding/GGI interfaces, and any case that needs a solver capability specific to this branch — accepting in return a smaller user community, a different (sometimes steeper) learning curve, and a slower release cycle.
Choosing between them: a quick decision guide
| If your priority is… | Consider |
|---|---|
| Teaching, research reproducibility, a stable well-documented core | OpenFOAM Foundation |
| Overset meshes, newest solvers/turbulence models fastest, industrial throughput | OpenCFD / Keysight |
| Fluid-structure interaction, turbomachinery with GGI, specialized coupled physics | foam-extend 5.0 |
In practice, many teams don’t pick one and stay there forever — they run the bulk of their cases on whichever branch matches their day-to-day solver needs, then reach for foam-extend specifically when a project calls for FSI or turbomachinery capability the other branches don’t offer. The three branches share enough of their DNA (case structure, most boundary condition syntax, the general blockMesh/snappyHexMesh workflow) that switching for a specific project is a manageable jump, not a total re-learn.
Why running all three matters — and why that’s easier on cloudHPC
Maintaining working, correctly compiled installations of three independently evolving codebases — each with its own compiler flags, third-party library versions, and MPI configuration — is real infrastructure overhead. It’s exactly the kind of setup work that’s easy to get wrong once and then have to redo every time a case needs a branch you don’t currently have configured.
On cloudHPC, OpenFOAM Foundation, OpenCFD/Keysight, and foam-extend 5.0 are available as ready-to-use environments, so the choice of branch becomes a technical decision about your case — not a decision constrained by whichever version happens to already be compiled on your workstation. Need to prototype a turbomachinery case with GGI in foam-extend and validate the same geometry against the latest overset-mesh solver in the OpenCFD branch? Both are one session away, with the parallel compute to run them properly.
Not sure which branch fits your case? cloudhpc.cloud provides on-demand access to OpenFOAM Foundation, OpenCFD/Keysight, and foam-extend 5.0 — pre-configured and ready to run.
CloudHPC is a HPC provider to run engineering simulations on the cloud. CloudHPC provides from 1 to 224 vCPUs for each process in several configuration of HPC infrastructure - both multi-thread and multi-core. Current software ranges includes several CAE, CFD, FEA, FEM software among which OpenFOAM, FDS, Blender and several others.
New users benefit of a FREE trial of 300 vCPU/Hours to be used on the platform in order to test the platform, all each features and verify if it is suitable for their needs
