Support multiple OpenFOAM versions with the same source

[MakisH]

Often users are bound to specific OpenFOAM variants (e.g. openfoam.com, openfoam.org, foam-extend) and versions (not always the latest, sometimes very old). However, often small or not-so-small differences will give errors during compilation. Therefore, we need a system to be able to support different versions at compile time.

Implementing such a system would help a lot dealing with issues such as #21, #8, #9, #26. A list of currently supported versions can be found in our wiki.

Fortunately, all the three main variants set the environment variables WM_PROJECT (OpenFOAM for .com and .org, foam for foam-extend) and WM_PROJECT_VERSION (4.1, 5.0, 6 (no dot), ... and dev for .org, v1712, v1806, ... for .com, 3.2, 4.0, ... for foam-extend) (see also #29). Versioning systems and other assumptions have changed much lately.

We currently use the WMake build system, developped together with OpenFOAM. This is a quite primitive system, but it is intrinsic to OpenFOAM. On top of it, I have added the Allwmake bash script to automate the procedure even more (also a common way in OpenFOAM-derived projects).

A few ideas on how to go on:

1. (ugly) Support different versions in different branches. The current state of the branch works with the latest version, Git tags/other branches for older versions.

   • This is how we support multiple SU2 and CalculiX versions.
   • Difficult to maintain, but easier than other options (e.g. different directories)
   • Here we have multiple "latest versions".

2. (ugly) Use pre-processor commands to check the version and activate different parts of the code.

   • A bit ugly and maybe difficult to maintain
   • Some changes (e.g. required in Support OpenFOAM 3.x #8 and Support OpenFOAM 2.2.x-2.4.x #9 ) are much bigger and spread throughout the code to treat with small patches

3. (ugly) Have source files like Adapter_of6_dev.C and Adapter_of4_5.C and let our script pick the correct ones.

   • Difficult to maintain
   • Keep the files kind of clean

4. Use a proper configuration system (e.g. CMake)

   • Ok, but how to solve our problem with it?
   • Do we need to replace WMake completely or can it work on top of it?

I would very much value your feedback on this.

[derekrisseeuw]

Hi Makis,

In my opinion the ideal openfoam adapter should be as portable as possible and easy to use. Therefore, the first solutions does not really work, because the user has to select the right branch.

The fourth option is the most elegant solution, but has a major flaw in my opinion. If the user wishes to support multiple openfoam versions, this approach does not work anymore.

Therefore, I think either the second or third option would be best.

[MakisH]

The fourth option is the most elegant solution, but has a major flaw in my opinion. If the user wishes to support multiple openfoam versions, this approach does not work anymore.

I am not sure I understood this part. Why will it not work?

[derekrisseeuw]

If I understand correctly, Configuring the make with Cmake will build the adapter according to the system configuration. So it will build the adapter using the openfoam version which is loaded at that moment.

However, if the user then wishes to switch to another version of openfoam, the adapter will not work, am I correct?

[MakisH]

But building one adapter for multiple versions of OpenFOAM would not work eitherways. Different executables need to be produced and each of them will be written in the $FOAM_USER_LIBBIN, which is different for every OpenFOAM installation.

If the user wishes to switch to another version of OpenFOAM, she would need to build the adapter also for this version, which is easy. The portability here mainly means having one source package that can adapt to the requested OpenFOAM version at the time it is being compiled.

[derekrisseeuw]

You're right! I forgot the fact that the adapter needs to build a seperate dynamic library in the $FOAM_USER_LIBBIN for every build.

In that case, the fourth solution would be best indeed. The user would need to build the adapter once for every openfoam installation.

Of course, the additional configuration is still an open question for now.

[MakisH]

An interesting (but short) discussion on cfd-online: Foam Version as a compile-time macro. There, it is suggested that one uses Git branches instead of pre-processor statements. I would, as well, agree.

[MakisH]

Mentioning this issue to @shkodm, he came up with the idea of using C++ templates, where the type would be the OpenFOAM version (which could be set once using macros). We did not check, but this could hide the non-used implementations from the compiler.

An abstract idea, at the moment, but thinking in design patterns in the code and not in building techniques is also a very nice idea.

[MakisH]

Another quick suggestion from @fsimonis: use C++ traits.