OpenFOAM® v1812: New boundary conditions

OpenFOAM® v1812: New boundary conditions

20/12/2018

New wave generation models

Wave boundary conditions were first introduced in OpenFOAM with the release of OpenFOAM v1612 Additional conditions for static meshes have been added in subsequent releases. This release extends the current capabilities by the new waveMaker condition that generates waves by moving the mesh, either using a piston- or flapping-motion.

Source code
$FOAM_SRC/waveModels/derivedPointPatchFields/waveMaker
Examples
$FOAM_TUTORIALS/multiphase/interFoam/laminar/waveMakerFlap
$FOAM_TUTORIALS/multiphase/interFoam/laminar/waveMakerPiston
Attribution
These boundary conditions were supplied by the Environmental Hydraulics Institute IHCantabria - see commit 6f806a
Authors: Gabriel Barajas
Integration
The code has been updated by OpenCFD and added to the $FOAM_SRC/waveModels library available to the interFoam family of solvers - see commit da813d

New generalised boundary condition

uniformFixedValue is a special version of fixedValue that takes a single value (hence the uniform). In previous releases this was limited a spatially uniform but time-varying function with additional input, e.g. interpolating in time from a csv file:

type            uniformFixedValue;
uniformValue
{
    type            csvFile;
    nHeaderLine     1;
    refColumn       0;
    componentColumns ( 2 );
    separator       ",";
    mergeSeparators no;
    file            "<constant>/inlet.csv";
}
In this release this has been extended:
  • the API has been extended to allow also spatially varying functionality (see examples below).
  • optionally a local coordinate system can be specified. The uniformValue is now interpreted to be in the local coordinate system. Note that this is not relevant for scalar fields.
  • optionally a per-component (of the local coordinate system) scaling can be specified. Any of these scaling can themselves be user-defined tables

Example of a swirl velocity boundary condition:

// Define coordinate system
coordinateSystem
{
    type    cylindrical;
    e1      (0 1 0);
    e3      (1 0 0);    // axis direction
    origin  (0 0 0);
}

// Time-dependent uniform value (in local coordinates)
// Velocity is 1 in axial and -1 in tangential direction
uniformValue    (0 -1 1);
// Local-coordinate dependent scaling:
// scale1 : per-component scaling according to coordinate 1(= 'r'):
//          - at r=0 only axial component is preserved (scale 1)
//          - at r=1 radial and tangential components multiplied by 2
scale1          table ((0 (0 0 1))(1 (2 2 1)));

[Picture]

Example of a time-ramping annular profile (with linear variation across the radius) (unscaled arrows, coloured with velocity magnitude)

coordinateSystem
{
    type    cylindrical;
    e1      (0 1 0);
    e3      (1 0 0);    // axis direction
    origin  (0 0 0);
}

// Ramp velocity from 0 to 10 in axial direction
uniformValue    table ((0 (0 0 0))(1 (0 0 10)));
// Scale uniformValue according to 'r' component
scale1          table ((0 (1 1 0))(1 (1 1 1)));
Example of a piece-wise linear (in y) inlet profile

inlet
{
    type            uniformFixedValue;
    uniformValue    (10 0 0);
    scale2          table
    (
        (0 (0 0 0))
        (25.4e-3 (1 1 1))
    );
}

Note: the original uniformFixedValue boundary condition had problems with a time-varying uniform value and second order (in time) running

  • any reading of an old time field would cause re-evaluation - at the current time - so would give incorrect boundary values
  • hence any restart, decomposing or reconstruction would lead to the wrong values on the old-time field. This would affect any time derivatives on the boundary.

The fix to this implies that if there is a value entry it now gets read and it will not evaluate (this is a change from previous behaviour which would always evaluate the uniform value). Similarly decomposePar, reconstructPar will not evaluate the uniformValue but instead use mapping.

Source code
$FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/uniformFixedValue
Examples
$FOAM_TUTORIALS/combustion/reactingFoam/RAS/chockedNozzle

Improved atmospheric boundary layer conditions

Changing properties of the atmospheric boundary conditions is now possible as a function of time, e.g. to change the flow direction or ground conditions:

Inlet
{
    type            atmBoundaryLayerInletVelocity;
    flowDir         table
    (
        (  0    (1 0 0))
        (  10   (1 0 0))
        (  20   (0 1 0))
        ( 100   (0 1 0))
    );

    zDir            (0 0 1);

    Uref            table
    (
        (  0    10)
        (  10   10)
        (  20   20)
        ( 100   20)
    );

    Zref            20;
    z0              uniform 0.1;
    zGround         uniform 935.0;
}

Here the flowDir, zDir, Uref and zRef entries are Function1 types, e.g. permitting tabular, polynomial, CSV file forms. In addition, the z0 and zGround entries are PatchFunction1 types, enabling users to set time varying field values.

Source code
$FOAM_SRC/atmosphericModels/derivedFvPatchFields

Improved freestream condition

The restriction of fixed inflow values has been removed for the freestream boundary condition, whereby users can now specify a condition to impose inflow values via the new freestreamBC entry. For example, for atmospheric flows it is useful to set the inflow velocity according to an atmospheric boundary layer profile:

Inlet
{
    type            freestream;
    freestreamBC
    {
        type            atmBoundaryLayerInletVelocity;
        flowDir         (1 0 0);
        zDir            (0 0 1);
        Uref            10;
        Zref            20;
        z0              uniform 0.1;
        zGround         uniform 935.0;
    }
    value           $internalField;
}
Backwards compatibility has been maintained for earlier versions that use the freestreamValue entry, e.g.:

Inlet
{
    type            freestream;
    freestreamValue uniform (10 0 0);
}

Source code
$FOAM_SRC/finiteVolume/fields/fvPatchFields/derived/freestream