OpenFOAM is free, open source software in computational fluid dynamics for real-world engineering and scientific applications. CFD Direct is committed to maintain OpenFOAM, demonstrated by the thousands of code commits to OpenFOAM-dev, with support from contributors. Maintenance concerns the evolution of software in response to changes in user expectation and environment. We have introduced an agile strategy suitable to the feedback process of software evolution and have identified key areas of OpenFOAM that requiring significant redesign, e.g. AMI and particles.
The work requires adequate funding and personnel who are able, willing and committed. We have recently recruited Will Bainbridge to our team, who has worked with us previously as a core developer of OpenFOAM, producing excellent code in areas such as multiphase flows with heat and mass transfer.
Software Maintenance
Maintenance is fundamental to software evolution which is governed by Lehman’s Laws that recognise the following points.
- Software must be adapted continually and increase in functionality to maintain satisfaction.
- Maintenance work is required to prevent an increase in complexity and a reduction in quality.
- Effective growth of software occurs at a characteristic rate and is limited by the time required to retain familiarity with the software.
- The evolution process is self-regulating and involves feedback systems, which should be treated accordingly.
Continual Adaptation
Adaptations are not only driven by demands of particular applications but also by changes in the environment, e.g. the continuous decrease in hardware costs increases the demand for parallel computation. User satisfaction requires enhancing existing functionality, e.g. removing the strict time step limitation from the MULES algorithm that once made (large-scale) marine hydrodynamics simulations it prohibitively costly. Satisfaction is gained by resolving issues reported by users, e.g. enabling MULES to work effectively for setting tank simulations. Effective implementation of new functionality in OpenFOAM involves much more refactoring of code to unlock existing functionality than writing new code.
Managing Complexity
Development of new functionality must be accompanied by work to ensure quality and prevent an increase in complexity. Some components of OpenFOAM have a significantly high proportion of unresolved issues, requiring essential maintenance through our funding campaign. Major redesign of a particular component, e.g. post-processing in OpenFOAM v4.0, can make it considerably easier to use and customise. Redesign and refactoring of function objects and removal of redundant utilities led to a reduction of 10,000 lines of code.
Growth is Limited
Rate of software growth is limited by Brooke’s “law” that argues that an attempt to increase in development output by increasing the number of programmers, N, is offset by an increase in the overhead of communication between developers, which can increase with N ². Communication overhead can be reduced by effective division of tasks, but there is a limit to the divisibility of any piece of software. Growth is practically limited because maintainers need time to retain sufficient familiarity with the software content and behaviour. Excessive growth is unsustainable when those associated with the software, i.e. contributors, users, trainers, documentation writers, do not keep up with the changes.
Stable Evolution
Evolution is a self-regulating system. When the rate of software growth increases, it generally leads to an increase in reported issues (bugs, feature enhancements, etc.); and, resolving those issues requires time from developers, which tends to reduce the rate of growth. The evolution process is particularly stable, resembling negative feedback, with an agile maintenance strategy where issues reported by users are resolved by effective code changes that are rapidly packaged and tested by the users. With infrequent code release, including large changes to functionality, the evolution process can be unstable when, for example, correcting one issue creates one or more new issues.