The new Function1 inputValue Mapper in OpenFOAM v2112

Dear OpenFOAM community. Today, I want to give you a quick summary of the new feature we introduced in the latest OpenFOAM version v2112 called the <Function1> wrapper functionality. This small article will give you some more insight for which cases you might use it.

As you might now, in OpenFOAM we can apply either a constant value to, e.g., a boundary condition such as a fixed temperature or velocity at a wall. However, if we want to make more fancy stuff, such as a time-based velocity or temperature changes, one can use either the codedFixed or codedMixed boundary condition to make whatever one wants to like or using the uniformFixedValue boundary condition which allows us to use the Function1 feature. (The difference between fixedValue and uniformFixedValue is simply that for fixedValue, we do not have the special functionality which is included in the <Function1> class)

However, imagine you want to change the mass-flow rate at the inlet based on a temperature value given in your domain (or pressure, or whatever quantity you have in mind). Doing so was only possible by using the codedFixed or codedMixed BC in previous versions.

The <Function1> class (implemented in the uniformFixedValue) allows us to use polynomials, tables and much more which is not helpful at all due to the fact that the base of the functionality is based on the <Time> in OpenFOAM. Therefore, any polynomial, table or other functionality only can evaluate time-dependent data. The rule was phi = f(t). It was not possible to define phi = f(T) or phi = f(rho) ...

The idea of the Function1 wrapper is to change the time-based implementation to any quantity you want to have. Hence, it allows us to create any functionality phi = f(whatEverValue).

An example that describes a velocity inlet based on the Function1 table and the new Function1 wrapper is given now (for clarifying). Lets assume the following boundary condition for the velocity inlet.

// Velocity boundary condition at the inlet
// The table is Time-based which
// t = 0 -> Ux = 1
// t = 2 -> Ux = 2
// t = 3 -> Ux = 1
// All values between the times are linear interpolated
inlet
{
    type    uniformFixedValue;
    value   table;
    values
    (
       (0  (1 0 0))
       (2  (2 0 0))
       (3  (1 0 0))
    );
}        

Here, depending on the simulation time, we get different values for the inlet. However, if you would like to, e.g., define the inlet velocity based on a surface temperature, you can do the same approach:

// Velocity boundary condition at the inlet based on the temperature
// --> not this is not working here
// The table is Time-based which means
// t = 273 -> Ux = 1
// t = 340 -> Ux = 2
// t = 365 -> Ux = 5
// All values between the times are linear interpolated
inlet
{
    type    uniformFixedValue;
    value   table;
    values
    (
       (273  (1 0 0))
       (340  (2 0 0))
       (365  (6 0 0))
    );
}        

In fact, the snippet above will not do what we want, as the x-values in the table are still time-based. Therefore, the new Function1 wrapper was introduced. We change the code and introduce the inputValueMapper (it looks complicated but its not).

// Velocity boundary condition at the inlet based on the temperatur
// The table is Time-based which means
// T = 273 -> Ux = 1
// T = 340 -> Ux = 2
// T = 365 -> Ux = 5
// All values between the Temperatures are linear interpolated
inlet
{
    type    uniformFixedValue;

    value
    {
        type??????????? inputValueMapper;??????????????????????????????????
        mode??????????? function;??????????????????????????????????????????
        
        function???????????????????????????????????????????????????????????
        {
            // Here we retrieve data from another FO (its the x-value)
        ??? type???????????????? functionObjectValue;???

            // The name of the FO????????????????????????       
        ??? functionObject?????? averageSurfaceTemperature;

            // The result used for x?????????
        ??? functionObjectResult average(<PatchName>,T);
?????????????????    
        ??? defaultValue???????? 200;
        }??????????????????????????????????????????????????????????????????
        
        value??????????????????????????????????????????????????????????????
        {??????????????????????????????????????????????????????????????????
        ??? type??????????? table;?????????????????????????????????????????
        ??? values
            (
                (273  (1 0 0))
                (340  (2 0 0))
                (365  (6 0 0))
            );
        }? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
    }
}        

The value is now a sub-dictionary which includes the inputValueMapper. The function {} includes the information from which FO we catch the data for the inputValueMapper and can be neglected if other options are used (see v2112 release notes). Finally, the table values are given. Doing so, you can simply create very interesting and great connections between different quantities and introduces high complex dependencies.

Hope this article gives some insight into the inputValueMapper and why we introduced it. The idea came up, when I was investigating into the swirlFanVelocity BC which is RPM based. The problem I had was, that we have fan speeds which might be based on the mass-flow rate and hence, the RPM must be mass-flow-dependent. The outcome was the inputValueMapper extension for the Function1 class.

Keep foaming, Tobi