[Table of Contents][Index][Version 4 | Version 3]

5.2 Boundaries

In this section we discuss the way in which boundaries are treated in OpenFOAM. The subject of boundaries is quite complex because their role in modelling is not simply that of a geometric entity but an integral part of the solution and numerics through boundary conditions or inter-boundary ‘connections’. A discussion of boundaries sits uncomfortably between a discussion on meshes, fields, discretisation, computational processing etc. 

We first need to consider that, for the purpose of applying boundary conditions, a boundary is generally broken up into a set of patches. One patch may include one or more enclosed areas of the boundary surface which do not necessarily need to be physically connected. A type is assigned to every patch as part of the mesh description, as part of the boundary file described in section 5.1.2. It describes the type of patch in terms of geometry or a data ‘communication link’. An example boundary file is shown below for a sonicFoam case. A type entry is clearly included for every patch (inlet, outlet, etc. ), with types assigned that include patch, symmetryPlane and empty.

17  
18  6
19  (
20      inlet
21      {
22          type            patch;
23          nFaces          50;
24          startFace       10325;
25      }
26      outlet
27      {
28          type            patch;
29          nFaces          40;
30          startFace       10375;
31      }
32      bottom
33      {
34          type            symmetryPlane;
35          inGroups        1(symmetryPlane);
36          nFaces          25;
37          startFace       10415;
38      }
39      top
40      {
41          type            symmetryPlane;
42          inGroups        1(symmetryPlane);
43          nFaces          125;
44          startFace       10440;
45      }
46      obstacle
47      {
48          type            patch;
49          nFaces          110;
50          startFace       10565;
51      }
52      defaultFaces
53      {
54          type            empty;
55          inGroups        1(empty);
56          nFaces          10500;
57          startFace       10675;
58      }
59  )
60  
61  // ************************************************************************* //

The user can scan the tutorials for mesh generation configuration files, e.g.  blockMeshDict for blockMesh (see section 5.3) and snappyHexMeshDict for snappyHexMesh (see section 5.4, for examples of different types being used. The following example searches for blockMeshDict files that specify the symmetryPlane condition.

    find $FOAM_TUTORIALS -name blockMeshDict | \
        xargs grep -El "type[\t ]*symmetryPlane"

The next example searches for snappyHexMeshDict files that specify the wall condition.

    find $FOAM_TUTORIALS -name snappyHexMeshDict | \
        xargs grep -El "type[\t ]*wall"


Figure 5.3: Axi-symmetric geometry using the wedge patch type. 



5.2.1 Geometric (constraint) patch types

The main geometric types available in OpenFOAM are summarised below. This is not a complete list; for all types see $FOAM_SRC/finiteVolume/fields/fvPatchFields/constraint.

  • patch: generic type containing no geometric or topological information about the mesh, e.g. used for an inlet or an outlet.
  • wall: for patch that coincides with a solid wall, required for some physical modelling, e.g.  wall functions in turbulence modelling.
  • symmetryPlane: for a planar patch which is a symmetry plane.
  • symmetry: for any (non-planar) patch which uses the symmetry plane (slip) condition.
  • empty: for solutions in in 2 (or 1) dimensions (2D/1D), the type used on each patch whose plane is normal to the 3rd (and 2nd) dimension for which no solution is required.
  • wedge: for 2 dimensional axi-symmetric cases, e.g. a cylinder, the geometry is specified as a wedge of small angle (e.g.  1∘) and 1 cell thick, running along the centre line, straddling one of the coordinate planes, as shown in Figure 5.3; the axi-symmetric wedge planes must be specified as separate patches of wedge type.
  • cyclic: enables two patches to be treated as if they are physically connected; used for repeated geometries; one cyclic patch is linked to another through a neighbourPatch keyword in the boundary file; each pair of connecting faces must have similar area to within a tolerance given by the matchTolerance keyword in the boundary file.
  • cyclicAMI: like cyclic, but for 2 patches whose faces are non matching; used for sliding interface in rotating geometry cases.
  • processor: the type that describes inter-processor boundaries for meshes decomposed for parallel running.


5.2.2 Basic boundary conditions

Boundary conditions are specified in field files, e.g.  p, U, in time directories as described in section 4.2.8. An example pressure field file, p, is shown below for the sonicFoam case corresponding to the boundary file presented in section 5.2.1.

17  dimensions      [1 -1 -2 0 0 0 0];
18  
19  internalField   uniform 1;
20  
21  boundaryField
22  {
23      inlet
24      {
25          type            fixedValue;
26          value           uniform 1;
27      }
28  
29      outlet
30      {
31          type            waveTransmissive;
32          field           p;
33          psi             thermo:psi;
34          gamma           1.4;
35          fieldInf        1;
36          lInf            3;
37          value           uniform 1;
38      }
39  
40      bottom
41      {
42          type            symmetryPlane;
43      }
44  
45      top
46      {
47          type            symmetryPlane;
48      }
49  
50      obstacle
51      {
52          type            zeroGradient;
53      }
54  
55      defaultFaces
56      {
57          type            empty;
58      }
59  }
60  
61  // ************************************************************************* //

Every patch includes a type entry that specifies the type of boundary condition. They range from a basic fixedValue condition applied to the inlet, to a complex waveTransmissive condition applied to the outlet. The patches with non-generic types, e.g.  symmetryPlane, defined in boundary, use consistent boundary condition types in the p file.

The main basic boundary condition types available in OpenFOAM are summarised below using a patch field named Q. This is not a complete list; for all types see $FOAM_SRC/finiteVolume/fields/fvPatchFields/basic.

  • fixedValue: value of Q is specified by value.
  • fixedGradient: normal gradient of Q (∂Q ∕∂n) is specified by gradient.
  • zeroGradient: normal gradient of Q is zero.
  • calculated: patch field Q calculated from other patch fields.
  • mixed: mixed fixedValue/ fixedGradient condition depending on valueFraction (0 ≤ valueFraction   ≤ 1) where
                       ( | 1  corresponds to Q  = refValue, { valueFraction   =  | 0  corresponds to ∂Q ∕∂n  = refGradient. (
    (5.1)
  • directionMixed: mixed condition with tensorial valueFraction, to allow different conditions in normal and tangential directions of a vector patch field, e.g.  fixedValue in the tangential direction, zeroGradient in the normal direction.


5.2.3 Derived types

There are numerous more complex boundary conditions derived from the basic conditions. For example, many complex conditions are derived from fixedValue, where the value is calculated by a function of other patch fields, time, geometric information, etc. Some other conditions derived from mixed/directionMixed switch between fixedValue and fixedGradient (usually zeroGradient).

There are a number of ways the user can list the available boundary conditions in OpenFOAM, with the foamList utility being the quickest. The boundary conditions for scalar fields and vector fields, respectively, are listed as follows.

    foamList -scalarBCs
    foamList -vectorBCs

These produce longs lists which the user can scan through. If the user wants more information of a particular condition, they can try searching for examples in the tutorials, or look to the source code, where information is usually provided in the Description. For example, for the totalPressure boundary condition, examples in the tutorials can be found by the following.

    find $FOAM_TUTORIALS -type f | xargs grep -l totalPressure

The source code files can be located by the following.

    find $FOAM_SRC -name totalPressure

In the following sections we will highlight some particular important, commonly used boundary conditions.

5.2.3.1 The inlet/outlet condition

The inletOutlet condition is one derived from mixed, which switches between zeroGradient when the fluid flows out of the domain at a patch face, and fixedValue, when the fluid is flowing into the domain. For inflow, the inlet value is specified by an inletValue entry. A good example of its use can be seen in the damBreak tutorial, where it is applied to the phase fraction on the upper atmosphere boundary. Where there is outflow, the condition is well posed, where there is inflow, the phase fraction is fixed with a value of 0, corresponding to 100% air.

17  dimensions      [0 0 0 0 0 0 0];
18  
19  internalField   uniform 0;
20  
21  boundaryField
22  {
23      leftWall
24      {
25          type            zeroGradient;
26      }
27  
28      rightWall
29      {
30          type            zeroGradient;
31      }
32  
33      lowerWall
34      {
35          type            zeroGradient;
36      }
37  
38      atmosphere
39      {
40          type            inletOutlet;
41          inletValue      uniform 0;
42          value           uniform 0;
43      }
44  
45      defaultFaces
46      {
47          type            empty;
48      }
49  }
50  
51  // ************************************************************************* //


5.2.3.2 Entrainment boundary conditions

The combination of the totalPressure condition on pressure and pressureInletOutletVelocity on velocity is extremely common for patches where some inflow occurs and the inlet flow velocity is not known. That includes the atmosphere boundary in the damBreak tutorial, inlet conditions where only pressure is known, outlets where flow reversal may occur, and where flow in entrained, e.g.  on boundaries surrounding a jet through a nozzle.

The totalPressure condition specifies

     ( |{ p0          for outflow 1   2 p =  | p0 − 2|U  | for inflow (incompressible, subsonic) (
(5.2)

where the user specifies p0 through the p0 keyword. The pressureInletOutletVelocity condition specifies zeroGradient at all times, except on the tangential component which is set to fixedValue for inflow, with the tangentialVelocity defaulting to 0.

The idea behind this combination is that the condition is a standard combination in the case of outflow, but for inflow the normal velocity is allowed to find its own value. Under these circumstances, a rapid rise in velocity presents a risk of instability, but the rise is moderated by the reduction of inlet pressure, and hence driving pressure gradient, as the inflow velocity increases.

The specification of these boundary conditions in the U and p_rgh files, in the damBreak case, are shown below.

17  
18  dimensions      [0 1 -1 0 0 0 0];
19  
20  internalField   uniform (0 0 0);
21  
22  boundaryField
23  {
24      leftWall
25      {
26          type            noSlip;
27      }
28      rightWall
29      {
30          type            noSlip;
31      }
32      lowerWall
33      {
34          type            noSlip;
35      }
36      atmosphere
37      {
38          type            pressureInletOutletVelocity;
39          value           uniform (0 0 0);
40      }
41      defaultFaces
42      {
43          type            empty;
44      }
45  }
46  
47  
48  // ************************************************************************* //

17  dimensions      [1 -1 -2 0 0 0 0];
18  
19  internalField   uniform 0;
20  
21  boundaryField
22  {
23      leftWall
24      {
25          type            fixedFluxPressure;
26          value           uniform 0;
27      }
28  
29      rightWall
30      {
31          type            fixedFluxPressure;
32          value           uniform 0;
33      }
34  
35      lowerWall
36      {
37          type            fixedFluxPressure;
38          value           uniform 0;
39      }
40  
41      atmosphere
42      {
43          type            totalPressure;
44          p0              uniform 0;
45      }
46  
47      defaultFaces
48      {
49          type            empty;
50      }
51  }
52  
53  // ************************************************************************* //


5.2.3.3 Fixed flux pressure

In the above example, it can be seen that all the wall boundaries use a boundary condition named fixedFluxPressure. This boundary condition is used for pressure in situations where zeroGradient is generally used, but where body forces such as gravity and surface tension are present in the solution equations. The condition adjusts the gradient accordingly.

5.2.3.4 Time-varying boundary conditions

There are several boundary conditions for which some input parameters are specified by a function of time (using Function1 functionality) class. They can be searched by the following command.

    find $FOAM_SRC/finiteVolume/fields/fvPatchFields -type f | \
        xargs grep -l Function1 | xargs dirname | sort -u

They include conditions such as uniformFixedValue, which is a fixedValue condition which applies a single value which is a function of time through a uniformValue keyword entry.

The Function1 is specified by a keyword following the uniformValue entry, followed by parameters that relate to the particular function. The Function1 options are list below.

  • constant: constant value.
  • table: inline list of (time value) pairs; interpolates values linearly between times.
  • tableFile: as above, but with data supplied in a separate file.
  • csvFile: time-value data supplied in a file in CSV format.
  • square: square-wave function.
  • sine: sine function.
  • polynomial: polynomial function using a list (coeff exponent) pairs.

Examples or a time-varying inlet for a scalar are shown below.

  inlet
  {
      type         uniformFixedValue;
      uniformValue constant 2;
  }
  
  inlet
  {
      type         uniformFixedValue;
      uniformValue table ((0 0) (10 2));
  }
  
  inlet
  {
      type         uniformFixedValue;
      uniformValue tableFile;
      uniformValueCoeffs
      {
          fileName        ”dataTable.txt”;
      }
  }
  
  inlet
  {
      type         uniformFixedValue;
      uniformValue csvFile;
      uniformValueCoeffs
      {
          nHeaderLine         4;              // number of header lines
          refColumn           0;              // time column index
          componentColumns    (1);            // data column index
          separator           ”,”;            // optional (defaults to ”,”)
          mergeSeparators     no;             // merge multiple separators
          fileName            ”dataTable.csv”;
     }
  }
  
  inlet
  {
      type         uniformFixedValue;
      uniformValue square;
      uniformValueCoeffs
      {
          frequency    10;
          amplitude    1;
          scale        2;  // Scale factor for wave
          level        1;  // Offset
      }
  }
  
  inlet
  {
      type         uniformFixedValue;
      uniformValue sine;
      uniformValueCoeffs
      {
          frequency    10;
          amplitude    1;
          scale        2;  // Scale factor for wave
          level        1;  // Offset
      }
  }
  
  inlet
  {
      type         uniformFixedValue;
      uniformValue polynomial ((1 0) (2 2)); // = 1*t^0 + 2*t^2
  }

© 2011-2016 OpenFOAM Foundation
CC-NC-ND 3.0