In this section we discuss the way in which boundaries are treated in OpenFOAM. The
subject of boundaries is a little involved 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, FoamX,
discretisation, computational processing etc. Its placement in this Chapter on
meshes is a choice of convenience.
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.
There are four attributes associated with a patch that are described below in
their natural hierarchy and Figure 6.3 shows the names of different patch types
introduced at each level of the hierarchy. The hierarchy described below is
very similar, but not identical, to the class hierarchy used in the OpenFOAM
library.
Base type
The type of patch described purely in terms of geometry or a
data ‘communication link’.
Primitive type
The base numerical patch condition assigned to a field
variable on the patch.
Derived type
A complex patch condition, derived from the primitive type,
assigned to a field variable on the patch.
Physical type
A type describing the boundary conditions in the physical
world which may include specification of derived or primitive types
on one or more fields, e.g. an inlet in fluid flow may be a fixedValue
condition on and fixedGradient condition on .
The patch types are specified in the mesh and field files of a OpenFOAM case. More
precisely:
the base type is specified under the type keyword for each patch in the
boundary file, located in the constant/polyMesh directory;
the numerical patch type, be it a primitive or derived type, is specified
under the type keyword for each patch in a field file.
The base type and numerical type are sufficient for the OpenFOAM case to run. However,
there is one further optional entry:
the physical type can be specified under the physicalType keyword
for each patch in the boundary file.
This entry is generated by FoamX and corresponds to the configuration of physical
patch types for individual OpenFOAM solvers. FoamX reads the entry when a
case is opened but if it does not exist, it will need to be specified by the
user.
An example boundary file is shown below for a sonicFoam case, followed by a
pressure field file, p, for the same case:
The type in the boundary file is patch for all patches except those that patches that
have some geometrical constraint applied to them, i.e. the symmetryPlane and
empty patches. The p file includes primitive types applied to the inlet and
bottom faces, and a more complex derived type applied to the outlet.
Comparison of the two files shows that the base and numerical types are
consistent where the base type is not a simple patch, i.e. for the symmetryPlane
and empty patches.
The physicalType for each patch in the boundary file correspond to a named
type in the FoamX configuration file for sonicFoam. For example, the inlet is
inletFixedTemp which is configured to be a standard supersonic inlet condition
with fixedValue on all fields: pressure p; velocity U; and temperature T. The type
applied to inlet in the p file corresponds accordingly.
The base and geometric types are described below; the keywords used for
specifying these types in OpenFOAM are summarised in Table 6.1.
Figure 6.4:
Axi-symmetric geometry using the wedge patch type.
Selection Key
Description
patch
generic patch
symmetryPlane
plane of symmetry
empty
front and back planes of 2D geometry
wedge
wedge front and back
cyclic
cyclic plane
wall
wall (used for wall functions in turbulent flows)
processor
inter-processor boundary
Table 6.1:
Basic patch types.
patch
The basic patch type for a patch condition that contains no geometric
or topological information about the mesh (with the exception of wall),
e.g. an inlet or an outlet.
wall
For cases which require wall turbulence modelling, a wall must be
specified with a wall patch type, so that the distance from the wall of
the cell centres next to the wall are stored as part of the patch.
symmetryPlane
For a symmetry plane.
empty
While OpenFOAM always generates geometries in 3 dimensions, it can be
instructed to solve in 2 (or 1) dimensions by specifying a special empty
condition 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 5 angle and 1 cell thick running along the
plane of symmetry, straddling one of the coordinate planes, as shown
in Figure 6.4. The axi-symmetric wedge planes must be specified as
separate patches of wedge type. The details of generating wedge-shaped
geometries using blockMesh are described in subsection 6.3.3.
cyclic
Enables two patches to be treated as if they are physically connected;
used for repeated geometries, e.g. heat exchanger tube bundles. A single
cyclic patch splits the faces in its faceList into two, and links the two
sets of faces as shown in Figure 6.5. Each face-face pair must be of
the same area but the faces do not need to be of the same orientation.
processor
If a code is being run in parallel, on a number of processors, then the
mesh must be divided up so that each processor computes on roughly
the same number of cells. The boundaries between the different parts
of the mesh are called processor boundaries.