Policy on support for OpenFOAM.org and other versions

[MakisH]

As the ESI / OpenCFD (.com) and CFD Direct / OpenFOAM Foundation (.org) versions are diverging more and more, it is becoming impossible to maintain the same level of support we started with. The amount of effort required is extremely high, especially since every new version of OpenFOAM.org brings several breaking changes.

There seem to be some users relying mainly on the latest versions of OpenFOAM.org, mainly judging from the download numbers of the release artifacts and PRs such as #310 (and similarly for foam-extend #302).

At the same time, we currently maintain commented-out configuration variants in some of our tutorials, and since OpenFOAM 10, a complete branch.

Motivation for supporting multiple versions is mainly because people are often restricted from custom codes and what version is installed on their local system. We couple codes, so we want to enable diversity. However, supporting old versions as well is becoming extremely complex and keeps the whole project behind.

As a way forward, and to (a) simplify our release process and (b) facilitate community contributions for other versions, I suggest the following:

• Our latest release only supports the latest OpenFOAM.com version, as we mostly already do. This means:
  • No more release artifacts for older versions
  • No more "if this version do this, else do that" (see Support multiple OpenFOAM versions with the same source #32)
  • If someone needs an older version, they can get an older version of the adapter.
• We host one branch for OpenFOAM.org, aiming to support the latest release of OpenFOAM.org.
  • The community can contribute to this branch.
  • Only compatibility updates can be contributed to these branches. All features and general fixes must be contributed to the develop branch.
  • We generate release artifacts for the latest supported version in every release.
  • If this is not ready, we proceed with our release, and attach additional artifacts later.
  • We only attach an artifact if all tests (see below) pass, and all preCICE features of the main adapter are supported or documented in the code and the user documentation.
• We similarly host one branch for foam-extend, etc.

For tutorials:

• We consider each OpenFOAM variant to be a separate code. This means that it will get its own case directory in some tutorials: fluid-openfoam-org.
• We only provide such variants for a couple of tutorials (partitioned-heat-conduction, flow-over-heated-plate, and perpendicular-flap, potentially also partitioned-pipe). If someone wants to port more cases, they can compare the changes.
• We add these cases to the system tests.

Any suggestions?

[hoehnp]

Generally, I would say considering the OpenFOAM ecosystem with codes developed with a certain version without porting to newer versions, I think precice is there a nice drop-in solution, when one needs to couple these codes. This does not only apply to certain versions, but also the different flavours of OF (foundation, ESI, extend). I, of course, understand that maintaining precice for a growing number of OF versions, especially OF11, is rather painful. However, I still believe that quite some use-cases of precice would not be feasible anymore and, thus, the value precice gives to the community, if one only stays with the latest versions. My suggestion would be to let maybe stick with some versions directly inside the project and let the others be maintained by the community. There seems to be an interest as the cited PRs are showing.

[MakisH]

@hoehnp thank you for speaking up! Questions:

1. Which versions would be relevant for you, and in which context? What is limiting you/your dependency to upgrade?
2. Would it be sufficient for you to use an older version of the adapter for an older version of OpenFOAM? I do understand that you would need a version compatible with preCICE v3, so we probably cannot escape releasing the usual set of version-specific packages for this release of the adapter.

[MakisH]

I just stumbled upon another potential user that cited the compatibility with multiple OpenFOAM versions as a reason to use preCICE.

[hoehnp]

@MakisH:

1. If i remember correctly CFDEMcoupling is based on OF6. I remember there was a discussion to upgrade to OF9, when talking to the developers, but considering this issue I assume it is still stuck to that version. The other software I mostly look into is solids4foam which also has an adapter, but I dont remember which versions it uses.
2. Then i for example as a consequence community contributions for officially unsupported versions or flavors had to be rejected. I also understand that probably adapters of different versions are not compatible with each other, right?

[MakisH]

Then i for example as a consequence community contributions for officially unsupported versions or flavors had to be rejected.

As I wrote in my first post, we would also like to support foam-extend, since this is apparently (via your contribution) possible. The goal here is to support what people need, without investing too much effort on versions that people don't need anymore.

I also understand that probably adapters of different versions are not compatible with each other, right?

What needs to be the same is the major preCICE version (v1, v2, v3). You can couple OpenFOAM v2312 that uses the adapter v1.3.0 and preCICE v3 with your foam-extend v5.1 project that uses your modification of the adapter, if that is ported to preCICE v3. What is not possible is mixing preCICE v2 with v3, since the way the data is serialized and exchanged has changed.

[precice-bot]

This issue has been mentioned on preCICE Forum on Discourse. There might be relevant details there:

https://precice.discourse.group/t/openfoam-org-adapter-doesnt-read-celldisplacement/1971/4

[precice-bot]

This issue has been mentioned on preCICE Forum on Discourse. There might be relevant details there:

https://precice.discourse.group/t/openfoam2-4-0-mnf-and-xdem-coupling/1995/4

[precice-bot]

This issue has been mentioned on preCICE Forum on Discourse. There might be relevant details there:

https://precice.discourse.group/t/will-there-be-openfoam-8-adapter-for-precice-v3/1999/2

[precice-bot]

This issue has been mentioned on preCICE Forum on Discourse. There might be relevant details there:

https://precice.discourse.group/t/trouble-installing-openfoam6-adapter-with-precice-v3/2065/2

[precice-bot]

This issue has been mentioned on preCICE Forum on Discourse. There might be relevant details there:

https://precice.discourse.group/t/openfoam-adapter-for-openfoam11-and-12/2073/2

[precice-bot]

This issue has been mentioned on preCICE Forum on Discourse. There might be relevant details there:

https://precice.discourse.group/t/volume-coupling-openfoam-10/2107/2

[MakisH]

At the preCICE Workshop 2024, me and @davidscn discussed with users on how to continue regarding this. Our current idea is:

• Stop considering that OpenFOAM.com and OpenFOAM.org have anything in common from now on. The two projects are uncontrollably diverging.
• Create different repositories under https://github.com/precice for the Foundation variant (and later potentially the foam-extend variant). I will do that.
• Only maintain one version (latest) for each variant.
• We will still develop and maintain mainly this repository. For the other repositories, we expect the community to step up.
• We will also port preCICE-related features from this repository to the other repositories, but we will not actively update for new OpenFOAM versions.
• We plan to keep track of the relevant differences between OpenFOAM versions in form of documentation, so that users interested in a specific OpenFOAM version can port what they need, without us having to support several older versions.
• We will remove all version-related preprocessor statements from the current repository.

Any feedback on this plan is very welcome.