Software Development Kit for CFD
OpenFOAM is free, open source software for computational fluid dynamics (CFD). The OpenFOAM Foundation distributes OpenFOAM publicly under the General Public License v3 in two forms:
- version releases (e.g. OpenFOAM version 5), which receive software patches to fix bugs;
- the development version,
OpenFOAM-dev, which is continuously updated.
At the heart of OpenFOAM is a software development kit (“SDK” or “devkit”), providing software and tools to build CFD applications. The SDK consists primarily of a collection of dynamic software libraries that each support some specific functionality. For example the incompressibleTransportModels library contains a family of viscosity models that are dependent on strain-rate. Using this library, a user can implement and use a new strain-rate dependent viscosity model in a few minutes. OpenFOAM is recognised for this high level of extensibility that enables users to customise their CFD, quickly and conveniently.
Redesigning OpenFOAM
CFD Direct includes OpenFOAM developers, led by its creator Henry Weller, who maintain the SDK. We redesign existing libraries, and create new ones, to maintain extensibility while developing new functionality that is not supported by the existing SDK. The work requires considerable experience and skill in software design, and commitment to OpenFOAM. It also requires an effective development process to redesign software without compromising robustness.
Critically, we adopt the release early, release often philosophy that underpins the success of other open source software, e.g. the Linux kernel. We develop new functionality in small, manageable steps, committing new code early and frequently to the public development repository. OpenFOAM users can identify issues (e.g. bugs), caused by the latest code changes, and report them through the Issue Tracking System. We can resolve these issues particularly quickly since they correspond to recent, small changes in code.
Repairing OpenFOAM
At the same time, SDK redesign provides the opportunity to repair issues that have remained unresolved for a longer period. The result is a net reduction in unresolved issues, shown in the graph below the period from early 2015 onwards. It demonstrates sustainable OpenFOAM development within an environment of frequent, early public code release with rapid-turnaround user feedback.
Sustainable OpenFOAM Development
Companies fund CFD Direct to develop OpenFOAM to include new and complex functionality. They take an active role in the developments, e.g. early testing new code submitted to OpenFOAM-dev. CFD Direct develops OpenFOAM both on its own, and in collaboration with other OpenFOAM contributors. Thus, sustainable OpenFOAM development occurs within a network of developers at CFD Direct and elsewhere, and users both from funding companies and the general public. Integration of new functionality must be coordinated with maintenance, i.e. the regular activities of: code redesign to improve extensibility; repair of issues to improve robustness; improving usability; and, managing necessary infrastructure (e.g. websites, tracking system).
Development of new functionality is funded by the companies who need it. However, many more companies that enjoy the benefits of sustainable development of OpenFOAM, including its extensibility and zero licence costs. They should share the cost of maintenance by purchasing a a Maintenance Plan from the OpenFOAM Foundation.
Unsustainable Development
Sustainable development therefore involves: early public code release with rapid-turnaround user feedback; a network of developers, funding companies and users; and, co-ordinated code integration and maintenance. With this in mind, we summarise some examples of unsustainable development below.
- Internal SDK development loses the benefits of user feedback and developer collaboration; maintenance of internal code often becomes costly and can suddenly become unmanageable, e.g. following the departure of a key member of staff.
- Code “dumping” involves an organisation offering us code “to put into OpenFOAM”, often because it is unmanageable; we inevitably need to re-implement the functionality from scratch in a sustainable manner, which requires funding.
- Rigid, fixed deliverable, development projects rely on a specification from one perspective, which is often too inflexible to adapt in response to feedback; they generally make no provision for maintenance activities, e.g. code redesign and repair.
- Roadmap developments put pressure on developers to tick boxes instead of rewarding them for producing robust, usable maintainable software.