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;
        }
    }
    ...

The functions used by the BC can vary in time.  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 ]

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;
    }
    ...