Field Functions in OpenFOAM

In March 2026, field functions were introduced to the development line of OpenFOAM (OpenFOAM-dev, packaged here) from The OpenFOAM Foundation.  Field functions, and the associated functionalFixedValue boundary condition, provide a flexible, convenient way of initialising fields.  This new functionality mostly removes the need for utilities, such as setFields, to initialise fields in a separate pre-processing step.

Before field functions

Users should be familiar with field files in OpenFOAM.   They are typically initialised in the “0” (zero) directory and have names corresponding to their solution variable name, e.g. “U” for the velocity field.  The syntax for the 0/U file typically begins with entries for the dimensions and internalField such as

dimensions    [velocity];
internalField uniform (0 0 0);

Here, the internalField is initialised to be uniform with a single value being sufficient to configure the field.  The only alternative entry, prior to field functions, was nonuniform, which must be followed by a list of values, one for every element of the field.  Pre-processing utilities like setFields generate nonuniform fields from uniform fields configured by a user.

Using field functions

Field functions instead provide the following options for initialising non-uniform fields directly.

• zonal: field values corresponding to different zones, created using zoneGenerators.
• surfaces: field values corresponding to regions separated by surfaces, e.g. “searchable” surfaces, STL/OBJ files, etc.
• distanceFunction: field values calculated using a function of distance across the domain.
• coded: field values calculated using a coded function.

An example of each field function is shown below for a scalar field with comments to explain the use.

internalField
{
    type        surfaces;
    defaultValue 1;

    surfaces
    {
        bubble
        {
            type   sphere; // "searchable" surface
            centre (0.5 0.5 0.5);
            radius 0.1;
            value  0;
        }

        air
        {
            type   plane;    // splits the domain with
            point  (0 1 0);  // the value applied on the
            normal (0 -1 0); // side opposing the normal
            value  0;
        }
    }
}

internalField
{
    type coded; // includes references "field" to itself
                // "C" to cell centres and "t" to time
    evaluate
    #{
        field = velocity(1, 0, 0) + (C ^ rate(2, 0, 0));
    #};
}

internalField 
{ 
    type zonal; 
    defaultValue  0;
    
    zones // overwrites the defaultValue 
    { 
        oil 
        { 
            type box; // zoneGenerator 
            box (0 -1 -1) (1 0 1); 
            value 1; 
        } 
    } 
}

internalField
{
    type        distanceFunction;
    direction   (1 0 0);

    function    // of (C & direction)
    {
        type        linearRamp;
        start       0; // start of ramp
        duration    1; // extent of ramp
    }
}

Defined dimensioned variables

The code for the coded field function above includes the constructor velocity(1, 0, 0).  This is an alternative constructor for a dimensioned<vector> with a dimensionSet for velocity and a value (1, 0, 0), expressed in standard form by

dimensioned<vector>(dimVelocity, vector(1, 0, 0))

The code above uses the pre-configured dimensionSet named dimVelocity.  OpenFOAM now has the same pre-configured dimensionSets with rational names, e.g. velocity, defined within a dimensions namespace.  The code above can thus be replaced by

dimensioned<vector>(dimensions::velocity, vector(1, 0, 0))

or, following the “using namespace dimensions;” directive,

dimensioned<vector>(velocity, vector(1, 0, 0))

A variadic function has been added to OpenFOAM that enables the dimensioned constructor to be contracted to

velocity(1, 0, 0)

The names of the new pre-configured dimensionSets can be listed by running foamUnits as follows:

foamUnits -all | grep ^Dimension

Further Information

• Defined dimensioned variables [ commit 42d70b02 ]
• The foamUnits utility [ commit f451f2d1 ]

functionalFixedValue boundary condition

A new functionalFixedValue boundary condition (BC) has been introduced to accompany field functions.  It can calculate a non-uniform field of values on patch faces using the same functions available to the field functions, i.e. zonal, surfaces, distanceFunction and coded.  The function is defined by the value keyword.  If the function is already defined in the internalField, then it can be substituted into the value entry using a macro, e.g.

boundaryField
{
    inlet
    {
        type functionalFixedValue;

        value
        {
            $internalField;
        }
    }
    ...

As an alternative to the functions that vary in space, functionalFixedValue can use the timeFunction to calculate a uniform field of values that varies in time only.

With a zonal function, faces are filtered in the mesh which are then applied to common faces in the patch.  To improve computational efficiency, the zone specification should contain a patch zone generator to limit the zone only to patch faces.  See the link below for more information.

Further Information

• functionalFixedValue boundary condition [ commit d8393191 ]
• changed to use the value entry to specify a field function [ commit 0415ffee ]
• timeFunction [ commit f3a203d ]

Temperature boundary conditions

The externalTemperature boundary condition applies a heat flux condition to temperature on a wall patch. The heat flux can be specified directly, or calculated with Newton’s Law of Cooling. To use Newton’s Law of Cooling, the user provides a heat transfer coefficient, h and ambient temperature, Ta. h is a field function, so can vary in space or time using the zonal, surface, timeFunction, distanceFunction or coded functions.  It can, however, still be defined as uniform using the conventional syntax for a field.

As an alternative, the externalWallLayersHeatTransferCoefficient field function can be used for h, which adds layers of conducting material to (uniform and constant) h. The layers are specified with a list of their thermal conductivities (kappaLayers) and a list of their thicknesses (thicknessLayers), in the sub-dictionary for the field function, e.g.

wall
{ 
    type     externalTemperature;
    Ta       constant 300;
    h
    {
         type     externalLayersWallHeatTransferCoefficient;
         h        10;
         thicknessLayers (1e-3);
         kappaLayers     (0.025);
    }
    value    uniform 400;

The coupledTemperature boundary condition provides a heat flux condition between connected regions for conjugate heat transfer (CHT) simulations. A heat transfer coefficient, h can be specified, to account for thermal resistance between the regions. h is a field function, and can vary in space or time using the using the zonal, surface, timeFunction, distanceFunction or coded functions.

As an alternative, if the regions are connected by layers of conducting material, the wallLayersHeatTransferCoefficient field function can calculate h from the thickness and thermal conductivity of the layers. The thickness and thermal conductivity of the layers are specified in the sub-dictionary for the field function, e.g

wall
{ 
    type     coupledTemperature;
    h
    {
         type     wallLayersHeatTransferCoefficient;
         thicknessLayers (1e-3);
         kappaLayers     (0.025);
    }
    value    $internalField;

For solid regions separated by a thin gap, wallLayersHeatTransferCoefficient can be used to calculate h. However, if the solidDisplacement modular solver is used, the solid can move, changing the gap width between the connected solids. The displacementGapHeatTransferCoefficient field function calculates h from the solid displacement field. See the thermalBending tutorial for an example.

Further Information

• externalWallLayersHeatTransferCoefficient: [ commit 286aab1 ]
• wallLayersHeatTransferCoefficient: [ commit 286aab1 ]
• displacementGapHeatTransferCoefficient: [ commit a8dcaf5 ]

Bespoke field functions

There are also bespoke field functions for the initialisation of surface waves and atmospheric boundary layers.  Previously, a dedicated pre-processing utility and BC(s) were provided, e.g. setWaves and waveAlpha, waveVelocity for surface waves.  Instead, the bespoke field functions can be used as follows, with the waves example showing the entries for the 0/alpha.water field.

internalField 
{ 
    type waveAlpha;
    libs ("libwaves.so");
    liquid true; // liquid phase below the wave

boundaryField
{ 
    inlet
    {
        $internalField;
    }
    ...

internalField
{
    type atmosphericBoundaryLayerVelocity;
    libs ("libatmosphericModels.so");
}

boundaryField
{
    inlet
    {
        $internalField;
    }
    ...