-
-
Notifications
You must be signed in to change notification settings - Fork 85
Notes on OpenFOAM
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.
The following OpenFOAM versions have been tested and are known to work out-of-the-box with this adapter:
-
OpenFOAM v1912 - openfoam.com
- (updates to laplacianFoam not yet ported (see #109, please manually set
solverType "basic"
when using laplacianFoam)
- (updates to laplacianFoam not yet ported (see #109, please manually set
- OpenFOAM v1906 - openfoam.com
- OpenFOAM v1812 - openfoam.com
- OpenFOAM v1806 - openfoam.com
- OpenFOAM v1712 - openfoam.com
- OpenFOAM 5.0 - openfoam.org, build 5.x-197d9d3bf20a (30/10/2017)
- OpenFOAM v1706 - openfoam.com
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:
- OpenFOAM-dev - openfoam.org (at least version 20191109): A compatible variant of the adapter is provided in the OpenFOAMdev branch. (see this pull request).
- OpenFOAM 7 - openfoam.org: A compatible variant of the adapter is provided in the OpenFOAM7 branch (see this pull request).
- OpenFOAM 6 - openfoam.org: A compatible variant of the adapter is provided in the OpenFOAM6 branch (see this pull request).
The following versions are known to be currently incompatible:
- OpenFOAM 4.1 - openfoam.org (let us know if you need to use this version)
- OpenFOAM 4.0 - openfoam.org (let us know if you need to use this version)
- OpenFOAM 3.0.1 - openfoam.org (see issue)
- OpenFOAM 2.3.1 - openfoam.org/.com (see issue)
- OpenFOAM v1606+ - openfoam.com
- foam-extend
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.
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".
- buoyantPimpleFoam
- buoyantSimpleFoam
- buoyantBoussinesqPimpleFoam
- laplacianFoam
- 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.
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.
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
andthermophysicalProperties
are provided.
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
andtransportProperties
are provided. -
transportProperties
contains densityrho
and heat capacityCp
. - 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).
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.
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 conductivityk
.
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.
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.
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");
}
}
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.
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.
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.
More information on precice.org. Subscribe to the preCICE mailing list.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Please use "precice.org" for the attribution.