Computational Science Stack Exchange is a question and answer site for scientists using computers to solve scientific problems. It only takes a minute to sign up.
Sign up to join this community
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?
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."
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.
