In October 2010, the OpenFOAM Issue Tracking system was launched to enable users to report issues with OpenFOAM, the free, open source software for computation fluid dynamics (CFD).  The system uses the MantisBT tracking software in which issues can be presented, discussed and resolved between reporters, and developers and managers of the project. The tracking system has operated continuously since 2010, maintained on behalf of the OpenFOAM Foundation by the team at CFD Direct and Bruno Santos at blueCAPE.  The site was recently moved to a dedicated subdomain of the OpenFOAM Foundation — — with a new server and a clean, new installation of the latest version of MantisBT.  Almost 2,300 issues have been reported to date.  We encourage reports from users because, if there is a issue with OpenFOAM, it needs to be resolved.

What is an Issue?

We talk about an “issue” because it has broader meaning than “software bug” which is “… an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways”.1  This definition does not include most reports about OpenFOAM which rarely relate to outright errors and flaws, but instead address code extensibility, standardization, optimization, interoperability (e.g. with compilers, libraries), etc.  Also, in CFD, the notion of software working as intended is quite limited, since it is so difficult to anticipate the numerous ways the software might be deployed, with so many combinations of geometry, mesh size and quality, physical models, numerical methods, and initial / boundary conditions.  The error accumulated from each of these aspects of a CFD simulation often blurs the line between a correct and incorrect result.  Determining failure in CFD software should therefore not be preoccupied with a retrospective view of  the developer’s intentions when implementing functionality, but on a progressive view of a user’s expectations when running the software.  Put simply, an issue exists when OpenFOAM behaves in a manner that does not meet reasonable expectationsNote: where there is a clear error in case configuration, there is no issue; the Tracking System is not a free, user support forum.

An Issue with Design

This definition makes an important statement that we are not simply concerned with faulty programming, but also with issues of software design, interface and usability.  If one developer writes a function with a misleading name, so that is does not function as reasonably expected to another developer, it is an issue.  If an input file contains a keyword that a user is likely to misinterpret, it is an issue.  If poor design means an internal code interface does not meet expectations of client code, then there is an issue; code should follow the Principle of Least Astonishment, avoiding a mismatch between the “most obvious guess for what the code does, and is this what it actually does”.2  OpenFOAM is rich in functionality, and its development is dominated by unlocking that functionality through re-design, code rewrites and refactoring.

Roadmap to Nowhere

A common approach to software development is the waterfall model: a sequential (non-iterative) design process, involving stages from the initial capture of requirements to testing and operation.  The model relies on a specification formed from the requirements of one particular user which is generally inefficient because it fails to address the broad range of potential deployments of CFD software.  Testing within the waterfall model offers limited benefit, when it cannot hope to cover a sufficiently broad range of simulations.

Development roadmaps, that enable corporate managers to tick boxes, obstruct essential developments needed to resolve issues, particularly relating to software design and usability.  Unreliable software inevitably follows when developers are forced to build new functionality before resolving underlying issues.  Roadmaps stifle creativity needed to develop software because they “simply weigh down developers with ill-formulated goals and stressful process friction”.3 The GNU/Linux operating system, the most successful of all open source software, has never had a roadmap.

Agile CFD Development

A progressive strategy for CFD is agile software development involving users who raise issues they experience, working with contributors and developers to resolve the issues.  Release early, release often is an approach attributed to the success of GNU/Linux2 , which emphasizes the importance of frequent code release to support this strategy.  The approach can be exploited by free, open source software, especially using modern version control software such as Git, and public hosting through web-based services such as GitHub.

Continuous Upgrade

Software upgrade is a necessity to take advantage of new features and code fixes, and to ensure continued interoperability with other software, e.g. operating system, compilers, and third-party libraries and applications, as they themselves release new features and code fixes.  Despite broad public acceptance of regular upgrades to operating systems, smart-phones, etc, users and system administrators tend to resist upgrading OpenFOAM.  Failure to upgrade incurs a form of technical debt, which builds slowly at first, but increases rapidly as “interest” mounts, particularly due to problems of interoperability.  It is promoted by traditional software upgrade, based on infrequent version releases, because significant technical debt builds during long release cycles.

An alternative approach is continuous upgrade of each new code change when it is pushed into the code base.  This approach contributes regular, small amounts to the upgrade cost, rather than building up significant technical debt, as a means to reduce overall cost of upgrade in the long-term.  A major advantage is that any unexpected behaviour in the software, i.e. an issue, can be traced back to the last code change, so the problem code is then easy to identify, even for non-developers.  Once reported, the code can be easily fixed and reissued by the developer(s).  The remarkable success of WordPress, the most popular blogging system used by approximately 25% of all websites, is underpinned by frequent release, especially from within the ecosystem of WordPress plugin programs.  The presentation of this article through this website, with such efficiency, is testament to the success of agile development with frequent release.


  • OpenFOAM is mature, quality software, whose successful development demands that issues are resolved in a timely manner.
  • An issue exists if OpenFOAM behaves in a manner that does not meet reasonable expectations, including in design and usability.
  • (Re-)design is a major part of OpenFOAM development, involving unlocking its rich array of functionality.
  • Roadmap development obstructs issue resolution, resulting in unreliable software and inefficient development.
  • Free, open source software can exploit agile development with frequent code release, as the best strategy for CFD development.
  • Users should adopt continuous upgrade to minimize cost and benefit the agile development strategy.


  1. Wikipedia (2016-10-10), Software Bug.
  2. D.M. Drysdale (2007), High Quality Software Engineering (chapter 3. Design).
  3. E.S. Raymond (2000), The Cathedral and the Bazaar.
Issues with OpenFOAM, Pt. 1