I wonder why OpenFOAM code has its own data structures Lists, HashTables, ... etc. when there is the STL in C++?

Another question related to the linear solvers, Why it is not using other mature libraries like PETSc, Trilinos,... ?

Are there any good reasons behind those choices?

  • 5
    $\begingroup$ It's probably a better question on the OpenFOAM forums. But OpenFOAM's origin dates back to the 1990s when neither modern C++ nor PETSc were around. One would make different design choices today than were made 25 years ago. $\endgroup$ Jun 1, 2020 at 19:37
  • 1
    $\begingroup$ I think it was designed to be as self-contained as possible, using as few dependencies as possible. Although, to be fair, it still has plenty of dependencies. $\endgroup$
    – Paul
    Jun 2, 2020 at 2:45

2 Answers 2


Straight from Henry's finger tips: a comment which goes in the general direction of the OP's question.

As Wolfgang pointed out, OpenFOAM predates many developments we're used to, including the STL and all later developments. Now, the OpenFOAM devs face the question of whether to stick with their implementations and strive for consistency; or to refactor their code to accomodate the STL and other features, with all the associated risks and errors such a large scale refactoring brings along.

What can be observed from OpenFOAM's code base is that they follow ideas of the STL with their own implementation, e.g. in some container classes.

And, as a totally unrelated side-note, another example of software devs sticking to their tried and tested framework and avoiding the new an shiny: Gtk-2 vs. Gtk-3. To quote from the developer quoted in the article: "We would gain nothing and waste months (or even years) on porting."

  • $\begingroup$ Do you think this is a case of institutional inertia at work here? Or does the cited developer have a valid point? $\endgroup$
    – Paul
    Jun 3, 2020 at 0:15
  • $\begingroup$ I don't think so. If you have working container classes, why refactor your code to use STL containers? In the comment from the bug tracker, Henry states that without additional funding, such changes to the code base are pointless for them: no additional functionality for a lot of work and risk of introducing errors, which entails even more work. Don't forget, this is an open source project, hence there is no institution from which inertia may be derived. This is no Microsoft retaining good old XP-styled dialogues well into Windows 10. The valid point is lack of funds. $\endgroup$
    – Dohn Joe
    Jun 3, 2020 at 8:26

In the light of more recent information:

OpenFOAM follows the C++11 standard without any exception at the time of writing. Therefore, you can use any C++ containers of this standard within OpenFOAM.

OpenFOAM, at least .com version, has been updated very long time ago to entirely align the ISO/IEC 14882:2011 (i.e. C++11) standard. The main reason why the more recent C++ standards were not considered is the fact that the compiler support by the majority of compilers for the C++14 and above is not covering the entire standard yet (see compiler support tables), and OpenFOAM must consider compilers other than Gcc and Clang.

Additionally, the Standard Template Library (i.e. STL) is not the C++ standard (see). Having said that, all major OpenFOAM low-level containers (e.g. UList) use almost all the utilities provided or abstracted by the STL in deep-down level, e.g. iterators.

Using the containers from an implementation of a C++ standard (e.g., Gcc or Clang implements the standards or STL components in different ways in low level) are not suitable for easily and robustly developing, maintaining and modifying the levels of abstraction required by numerical continuum mechanics problems, but OpenFOAM is, subjectively, in a very elegant way. And the containers you have mentioned are not the ones a typical user can interact with.

Also, it is not true that OpenFOAM does not or will not bring the external linear solver suites into play. For example, HPC-OpenFOAM Technical Committee has been testing PETSc-OpenFOAM for more than a year. GPU support discussion and tests are even decade older! Nvidia, Intel, and AMD are close contact with OpenFOAM as well in this regard.

The problem is that the OpenFOAM development is on the shoulders of the few who has tons of things on their plates without chopped support. Some software companies use OpenFOAM for their work horse, and sell their products with mombo-jombo legal tricks (you know them). This hampers the healthy level of development that OpenFOAM can achieve. Despite these bloodsuckers, thanks to the OpenFOAM community and ethical industrial partners, OpenFOAM still rocks.

EDIT: Here petsc4Foam provided by the official OpenFOAM.

EDIT-2: Here PETSc in OpenFOAM-v2006.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.