OpenFOAM is the leading free, open source software for computational fluid dynamics (CFD), distributed exclusively under the General Public Licence (GPL) by The OpenFOAM Foundation (
openfoam.org). It is maintained by CFD Direct which continually improves the quality of OpenFOAM, with emphasis on robustness, usability and extensibility. It is important to recognise how CFD Direct achieved this, to ensure that OpenFOAM continues to improve.
In 1989, Henry Weller began writing “FOAM” in C++, in an attempt to introduce software engineering into engineering. FOAM included libraries of functionality, using object orientation (and later, generic programming) to minimise code duplication. Applications were then built using the library functionality, to solve particular problems in CFD, beginning with transient, incompressible, laminar flow. New applications and libraries followed and in 2004, FOAM became “OpenFOAM” and was released as free, open source software by Weller, Chris Greenshields and Mattijs Janssens, through OpenCFD Ltd, the company they founded.
OpenFOAM soon attracted the interest of organisations wishing to take advantage of its zero licence cost, transparency and flexibility. Several companies funded the development of new functionality including the meshing tool snappyHexMesh, released in 2008. In 2011, The OpenFOAM Foundation was created by Weller and Greenshields to own the copyright of OpenFOAM to ensure it would always be licensed free and open source only. OpenCFD was acquired by SGI Corp but, following the departure of its CEO, SGI sold OpenCFD to ESI Group in 2012.
From 2011 to 2014, there was a drive for new functionality at the expense of software (re-)design and repair, both key components of maintenance. Code was written too quickly, which was not sufficiently consistent, reusable and interoperable. The cost to rewrite the “bad” code — the technical debt — grew rapidly, with the prospect that it would soon reach an unsustainable level. The situation was reflected by a sharp rise in the number of unresolved issues, reported on the OpenFOAM Issue Tracking system (see below).
In 2014 Weller and Greenshields left ESI Group to manage and develop OpenFOAM back to a sustainable position. From late 2014 to early 2015, code was repaired to reduce the number of unresolved issues from 288 to 120. The development line of OpenFOAM (
OpenFOAM-dev) was released through the OpenFOAM source code repository to encourage greater feedback from users. CFD Direct was launched in 2015 and the number of unresolved issues reduced further to 75 by 2016.
At that time, a series of articles — Issues with OpenFOAM Part 1, Part 2 and Part 3 – explained many of the practical aspects surrounding OpenFOAM maintenance. They concluded that dedicated funding was needed for maintenance which led to the first campaign for maintenance funding through the OpenFOAM Foundation. This evolved into a set of defined packages of support for OpenFOAM maintenance, with the current 2023 funding campaign setting a target of €500,000.
Redesigning Code and Replacing Functionality
By the end of 2017, the number of unresolved issues stagnated at around 50. These issues could not simply be repaired because they related to fundamental problems in some underlying functionality. Issues with OpenFOAM: Part 3 highlighted that problems clustered around particular components of OpenFOAM, with 30% of unresolved issues associated with arbitrary mesh interface (AMI) and 17% associated with heat transfer, including conjugate heat transfer (CHT).
The problem with AMI (and ACMI and Repeat AMI) was that the methods were non-conservative and consequently unreliable for many problems. From 2017 to 2022, a new method known as Non-Conformal Coupling (NCC) was created, implemented, tested and released, primarily by Will Bainbridge. The method was conservative so eliminated the problems of AMI/ACMI. At a cost of approximately 1 man-year of maintenance funding, NCC is worthy of a PhD in its own right and was integrated into OpenFOAM as a complete replacement for AMI. This represents a remarkably good value for a robust, accurate numerical method for CFD with rotating and sliding geometries, that is fully transparent and free to use.
The issues relating to heat transfer and CHT were eliminated through two pieces of work. First, the creation of the ThermophysicalTransportModels library in OpenFOAM v8 introduced a
divq() function representing the divergence ∇•q of the heat flux q. This function replaced relevant code within applications, boundary conditions and data processing to ensure consistent heat transfer across OpenFOAM. Then, more recently, modular solvers have been introduced to
OpenFOAM-dev which describe: different fluids, including incompressible, isothermal, compressible, multicomponent and multiphase interface capturing and Euler-Euler; and solids. They can be coupled using the foamMultiRun application, enabling CHT with any fluid solver, e.g. multiphase, without any additional, duplicate code.
As 2022 draws to a close, the number of unresolved issues sits at 15, in contrast to its all time high of 288 in 2014. The technical debt, which grew principally from 2011-2014, has largely been “repaid” by the work of CFD Direct, with funding from supporters of OpenFOAM. The work involved repair, redesign and associated “publishing” (code management, compilation, packaging, downloads, licensing, documentation and promotion) — the critical work that constitutes maintenance. Consistency, reusability and interoperability help to meet the critical needs of users: availability, usability, robustness and extensibility.
CFD Direct is committed to maintaining OpenFOAM into the future. Repair work will continue, more often around niche functionality that undergoes less testing. The Lagrangian functionality is undergoing a major redesign and the plan is to transition fully to modular solvers. Further redesign is continually required to meet critical user needs while introducing new functionality. Together with OpenFOAM Training, documentation and supporting tools, this enables users to solve more problems reliably with OpenFOAM.