Recent OpenFOAM.com versions work out-of-the-box. Recent OpenFOAM.org versions are also supported, but you will need a version-specific branch.

How to get OpenFOAM

The easiest way to start is to get binary packages for your Linux distribution. For example, to get OpenFOAM v2012 on Ubuntu:

# Add the signing key, add the repository, update:
wget -q -O - https://dl.openfoam.com/add-debian-repo.sh | sudo bash

# Install OpenFOAM v2012:
sudo apt-get install openfoam2012-dev

As these steps change your .profile, you need to log out and in again to make OpenFOAM fully discoverable.

Supported OpenFOAM versions

OpenFOAM is a project with long history and many forks, of which we try to support as many as possible.

Supported versions:

Known not supported versions: OpenFOAM v1606+ or older, OpenFOAM 3 or older, foam-extend (any version).

Supported OpenFOAM solvers

We support mainstream OpenFOAM solvers such as pimpleFoam (for FSI) or buoyantPimpleFoam, buoyantSimpleFoam, laplacianFoam (for CHT). Our community has tried the adapter with multiple different solvers that support function objects.

Notes on OpenFOAM features

End of the simulation

The adapter (by default) ignores the endTime set in the controlDict and stops the simulation when preCICE says so.

Let’s see this with more details. During the simulation, both the solver and preCICE try to control when the simulation should end. While in an explicit coupling scenario this is clearly defined, in an implicit coupling scenario the solver may schedule its exit (and therefore the last call to the adapter) before the coupling is complete. See how function objects are called for more details on this.

In order to prevent early exits from the solver, the solver’s endTime is set to infinity and it is later set to the current time when the simulation needs to end. This has the side effect of not calling any function object’s end() method normally, so these are triggered explicitly at the end of the simulation.

Function Objects

In principle, using other function objects alongside the preCICE adapter is possible. They should be defined before the adapter in the system/controlDict, as (by default and opt-out) the adapter controls when the simulation should end and explicitly triggers (only) the end() methods of any other function objects at the end of the simulation. If the end() of a function object depends on its execute(), then the latter should have been called before the preCICE adapter’s execute().

If you want to test this behavior, you may also include e.g. the systemCall function object in your system/controlDict:

functions
{

    systemCall1
    {
        type        systemCall;
        libs        ("libutilityFunctionObjects.so");

        executeCalls
        (
            "echo \*\*\* systemCall execute \*\*\*"
        );

        writeCalls
        (
            "echo \*\*\* systemCall write \*\*\*"
        );

        endCalls
        (
            "echo \*\*\* systemCall end \*\*\*"
        );
    }

    preCICE_Adapter
    {
        type preciceAdapterFunctionObject;
        libs ("libpreciceAdapterFunctionObject.so");
    }

}

Writing results

As soon as OpenFOAM writes the results, it will not try to write again if the time takes the same value again. Therefore, during an implicit coupling, we write again when the coupling timestep is complete. See also a relevant issue.

Adjustable timestep and modifiable runTime

In the system/controlDict, you may optionally specify the following:

adjustTimeStep  yes;
maxCo           0.5;

runTimeModifiable yes;

The adapter works both with fixed and adjustable timestep and it supports the runTimeModifiable feature. However, if you set a fixed timestep and runTimeModifiable, changing the configured timestep during the simulation will not affect the timestep used. A warning will be shown in this case.