Skip to content

Notes on OpenFOAM

Gerasimos Chourdakis edited this page Feb 19, 2020 · 43 revisions

OpenFOAM is project with long history and many forks and we try to support several versions and variants. Here you may find a list of compatible versions, as well as notes on some features that may not be supported in a coupled simulation at the moment.

Compatible OpenFOAM versions

The following OpenFOAM versions have been tested and are known to work out-of-the-box with this adapter:

We are looking for a nice way to support multiple versions at the same time. In the meantime, the following OpenFOAM versions work but are seen as special cases:

The following versions are known to be currently incompatible:

If a version is not listed here, it may still be compatible. Please let us know if you want to use a version of OpenFOAM not listed here.

Compatible OpenFOAM solvers

The following OpenFOAM solvers (in the respective OpenFOAM versions) are known to work with the adapter. However, more solvers may be compatible. See also the section "Solver requirements".

Conjugate heat transfer

Compressible

  • buoyantPimpleFoam
  • buoyantSimpleFoam

Incompressible

  • buoyantBoussinesqPimpleFoam

Basic

  • laplacianFoam

Fluid-structure interaction

Incompressible

  • pimpleFoam / pimpleDyMFoam

Please note that the *DyMFoam dynamic mesh solvers were deprecated and merged into the respective standard solvers in OpenFOAM 6 and OpenFOAM v1806. The adapter-specific configuration is not affected, but you need to choose the correct one for your OpenFOAM version.

Solver requirements

The adapter can be loaded by any official OpenFOAM solver, but there are some requirements to use a solver for conjugate heat transfer simulations. See also Configuration.

First of all, the solver needs to be able to simulate heat transfer. This means that the solver should create a Temperature field (named T) and provide thermal conductivity or diffusivity fields.

Three categories of solvers are assumed: compressible, incompressible and basic solvers.

Compressible turbulent flow solvers

For example buoyantPimpleFoam or buoyantSimpleFoam. These solvers simulate heat transfer and compute the effective thermal conductivity automatically. They include the file turbulentFluidThermoModel.H and instantiate a compressible::turbulenceModel. This is needed in the adapter as a part of the effective conductivity is affected by the turbulence.

Assumptions:

  • Temperature is a registered IOObject named T.
  • The dictionaries turbulenceProperties and thermophysicalProperties are provided.

Incompressible turbulent flow solvers

Conjugate heat transfer

For example buoyantBoussinesqPimpleFoam or buoyantBoussinesqSimpleFoam. These solvers simulate heat transfer but do not compute the effective thermal conductivity, as they don't know the density of the fluid or the heat capacity. Therefore, values for these need to be provided. The adapter looks for them in the transportProperties dictionary.

For example, the following lines need to be added in the constant/transportProperties file:

rho              rho [ 1 -3  0  0 0 0 0 ] 50;
Cp               Cp  [ 0  2 -2 -1 0 0 0 ] 5;

The solver itself does not need to read these values.

Assumptions:

  • Temperature is a registered IOObject named T.
  • The dictionaries turbulenceProperties and transportProperties are provided.
  • transportProperties contains density rho and heat capacity Cp.
  • The turbulent thermal diffusivity is a registered IOObject named alphat. If it is not found, then only the laminar part of the thermal diffusivity is used (a warning is triggered in this case).

Fluid-structure interaction

For incompressible solvers (e.g. pimpleFoam), the adapter tries expects the kinematic viscosity nu and the density rho in the constant/transportProperties file. See also Configuration.

Basic solvers

For example laplacianFoam can simulate heat transfer, using a thermal diffusion parameter DT. The adapter additionally expects a value for the conductivity k in the transportProperties dictionary.

For example, the following lines need to be present in the constant/transportProperties file for the laplacianFoam:

DT               DT  [ 0  2 -1  0 0 0 0 ] 1;
k                k   [ 1  1 -3 -1 0 0 0 ] 100;

Do not delete the, already provided in the pure solver, DT, as laplacianFoam expects it. The value of k is connected to the one of DT and depends on the density (rho [ 1 -3 0 0 0 0 0 ]) and heat capacity (Cp [ 0 2 -2 -1 0 0 0 ]). It needs to hold DT = k / rho / Cp. The solver itself does not need to read the additional parameter.

Assumptions:

  • Temperature is a registered IOObject named T.
  • The dictionary transportProperties is provided.
  • transportProperties contains the conductivity k.

Other solvers

If a solver uses different variable names, or if its type is not determined automatically, you may define these in the adapter's configuration file.


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.

In order to disable this behavior, you may define the option preventEarlyExit: No in the adapter's configuration file. Still, if the solver exits before the coupling completes, a warning will be reported.

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.


Disclaimer

This offering is not approved or endorsed by OpenCFD Limited, producer and distributor of the OpenFOAM software via www.openfoam.com, and owner of the OPENFOAM® and OpenCFD® trade marks.