This section is an attempt to unify boundarycondition specifications within NavierStokes codes. The structures and conventions developed are a compromise between simplicity and generality. It is imperative that they be easy to use initially, but that they are general enough to provide future flexibility and extensibility.
This section may be somewhat daunting initially. It is suggested that the reader refer to the Boundary Condition Examples during study of the following sections to help resolve any questions and confusions that might arise.
The difficulty with boundary conditions is that there is such a wide variety used, and even a single boundarycondition equation is often implemented differently in different codes. Some boundary conditions, such as a symmetry plane, are fairly well defined. Other boundary conditions are much looser in their definition and implementation. An inflow boundary is a good example. It is generally accepted how many solution quantities should be specified at an inflow boundary (from mathematical wellposedness arguments), but what those quantities are will change with the class of flow problems (e.g., internal flows vs. external flows), and they will also change from code to code.
An additional difficulty for CFD analysis is that in some situations different boundarycondition equations are applied depending on local flow conditions. Any boundary where the flow can change from inflow to outflow or supersonic to subsonic is a candidate for flowdependent boundarycondition equations.
These difficulties have molded the design of our boundarycondition specification structures and conventions. We define boundarycondition types that establish the equations to be enforced. However, for those more loosely defined boundary conditions, such as inflow/outflow, the boundarycondition type merely establishes general guidelines on the equations to be imposed. Augmenting (and superseding) the information provided by the boundarycondition type is precisely defined boundarycondition solution data. We rely on our conventions for dataname identifiers to identify the exact quantities involved in the boundary conditions.
One flexibility that is provided by this approach is that boundarycondition information can easily be built during the course of an analysis. For example, during gridgeneration phases minimal information (e.g., the boundarycondition type) may be given. Then prior to running of the flow solver, more specific boundarycondition information, such as Dirichlet or Neumann data, may be added to the database.
An additional flexibility provided by the structures of this section is that both uniform and nonuniform boundarycondition data can be described within the same framework.
We realize that most current codes allow little or no flexibility in choosing solution quantities to specify for a given boundarycondition type. We also realize the coding effort involved with checking for consistency between I/O specifications and internal boundarycondition routines. To make these boundarycondition structures more palatable initially, we adopt the convention that if no solution quantities are specified for a given boundarycondition type, then the code is free to enforce any appropriate boundary condition (see Boundary Condition Specification Data).
Note that there are no boundarycondition structures defined for abutting or overset interfaces, unless they involve cases of symmetry or degeneracy. In other words, it is a CGNS design intent that a given zone boundary segment or location should at most be defined (or covered) by either a boundary condition or a multizone interface connectivity, but not by both. There is also no separate boundarycondition structure for periodic boundary conditions (i.e., when a zone interfaces with itself). Both of these situations are addressed by interface connectivity data structures.
In the sections to follow, the definitions of boundarycondition structures are presented in the first six sections. Boundarycondition types are then discussed in detail, including a description of the boundarycondition equations to be enforced for each type; this section also describes the distinction between boundarycondition types that impose a set of equations regardless of local flow conditions and those that impose different sets of boundarycondition equations depending on the local flow solution. The rules for matching boundarycondition types and the appropriate sets of boundarycondition equations are next discussed. Details of specifying data to be imposed in boundarycondition equations are provided next. Finally, several examples of boundary conditions are presented.
Prior to presenting the detailed boundary condition structures, we give a brief overview of the hierarchy used to describe boundary conditions.
Boundary conditions are classified as either fixed or flowdependent. Fixed boundary conditions enforce a given set of boundarycondition equations regardless of flow conditions; whereas, flowdependent boundary conditions enforce different sets of boundarycondition equations depending on local flow conditions. We incorporate both fixed and flowdependent boundary conditions into a uniform framework. This allows all boundary conditions to be described in a similar manner. We consider this functionally superior to separately treating fixed and flowdependent boundary conditions, even though the latter allows a simpler description mechanism for fixed boundary conditions. The current organization also makes sense considering the fact that flowdependent boundary conditions are composed of multiple sets of fixed boundary conditions.
The above figure depicts the hierarchy used for prescribing a single boundary condition. Each boundary condition includes a type that describes the general equations to enforce, a patch specification, and a collection of data sets. The minimum required information for any boundary condition is the patch specification and the boundarycondition type (indicated by “BC type (compound)” in the figure). This minimum information is similar to that used in many existing flow solvers.
Generality in prescribing equations to enforce and their associated boundarycondition data is provided in the optional data sets.
Each data set contains all boundary condition data required for a given fixed or simple boundary condition.
Each data set is also tagged with a boundarycondition type.
For fixed boundary conditions, the hierarchical tree contains a single data set, and the two boundarycondition types shown in the above figure are identical.
Flowdependent or compound boundary conditions contain multiple data sets, each to be applied separately depending on local flow conditions.
The compound boundarycondition type describes the general flowdependent boundary conditions, and each data set contains associated simple boundarycondition types.
For example, a farfield boundary condition would contain four data sets, where each applies to the different combinations of subsonic and supersonic inflow and outflow.
See the sections Boundary Condition Type Structure Definition: BCType_t
and Matching Boundary Condition Data Sets for more details.
Within a single data set, boundary condition data is grouped by equation type into Dirichlet and Neumann data.
The lower leaves of the above figure show data for generic flowsolution quantities \(\alpha\) and \(\beta\) to be applied in Dirichlet conditions, and data for \(\gamma\) and \(\delta\) to be applied in Neumann boundary conditions.
DataArray_t
entities are employed to store these data and to identify the specific flow variables they are associated with.
In situations where the data sets (or any information contained therein) are absent from a given boundarycondition hierarchy, flow solvers are free to impose any appropriate boundary conditions. Although not pictured in the above figure, it is also possible to specify the reference state from which the flow solver should extract the boundarycondition data.
ZoneBC_t
¶All boundarycondition information pertaining to a given zone is contained in the ZoneBC_t
structure.
ZoneBC_t< int CellDimension, int IndexDimension, int PhysicalDimension > :=
{
List( Descriptor_t Descriptor1 ... DescriptorN ) ; (o)
List( BC_t<CellDimension, IndexDimension, int PhysicalDimension>
BC1 ... BCN ) ; (o)
ReferenceState_t ReferenceState ; (o)
DataClass_t DataClass ; (o)
DimensionalUnits_t DimensionalUnits ; (o)
List( UserDefinedData_t UserDefinedData1 ... UserDefinedDataN ) ; (o)
} ;
Note
Default names for the Descriptor_t
, BC_t
, and UserDefinedData_t
lists are as shown; users may choose other legitimate names. Legitimate names must be unique within a given instance of ZoneBC_t
and shall not include the names DataClass
, DimensionalUnits
, or ReferenceState
.
All lists within a ZoneBC_t
structure entity may be empty.
ZoneBC_t
requires three structure parameters, CellDimension
, IndexDimension
and PhysicalDimension
, which are passed onto all BC_t
substructures.
Boundarycondition information for a single patch is contained in the BC_t
structure. All boundarycondition information pertaining to a given zone is contained in the list of BC_t
structure entities.
If a zone contains N boundarycondition patches, then N (and only N) separate instances of BC_t
must be provided in the ZoneBC_t
entity for the zone.
That is, each boundarycondition patch must be represented by a single BC_t
entity.
Reference data applicable to all boundary conditions of a zone is contained in the ReferenceState
structure.
DataClass
defines the zonal default for the class of data contained in the boundary conditions of a zone.
If the boundary conditions contain dimensional data, DimensionalUnits
may be used to describe the system of dimensional units employed.
If present, these three entities take precedence over all corresponding entities at higher levels of the hierarchy, following the standard precedence rules.
Referencestate data is useful for situations where boundarycondition data is not provided, and flow solvers are free to enforce any appropriate boundary condition equations.
The presense of ReferenceState
at this level or below specifies the appropriate flow conditions from which the flow solver should extract its boundarycondition data.
For example, when computing an external flowfield around an airplane, an engine nozzle exit is often simulated by imposing a stagnation pressure boundary condition (or some other stagnation quantity) different from freestream.
The nozzleexit stagnation quantities could be specified in an instance of ReferenceState
at this level or below in lieu of providing explicit Dirichlet or Neumann data. (See Boundary Condition Specification Data.)
The UserDefinedData_t
data structure allows arbitrary userdefined data to be stored in Descriptor_t
and DataArray_t
children without the restrictions or implicit meanings imposed on these node types at other node locations.
BC_t
¶BC_t
contains boundarycondition information for a single BC surface patch of a zone.
A BC patch is the subrange of the face of a zone where a given boundary condition is applied.
The structure contains a boundarycondition type, as well as one or more sets of boundarycondition data that are used to define the boundarycondition equations to be enforced on the BC patch. For most boundary conditions, a single data set is all that is needed. The structure also contains information describing the normal vector to the BC surface patch.
BC_t< int CellDimension, int IndexDimension, int PhysicalDimension > :=
{
List( Descriptor_t Descriptor1 ... DescriptorN ) ; (o)
BCType_t BCType ; (r)
GridLocation_t GridLocation ; (o/d)
IndexRange_t<IndexDimension> PointRange ; (r:o)
IndexArray_t<IndexDimension, ListLength[], int> PointList ; (o:r)
int[IndexDimension] InwardNormalIndex ; (o)
IndexArray_t<PhysicalDimension, ListLength[], real>
InwardNormalList ; (o)
List( BCDataSet_t<CellDimension, IndexDimension, ListLength[], GridLocation>
BCDataSet1 ... BCDataSetN ) ; (o)
BCProperty_t BCProperty ; (o)
FamilyName_t FamilyName ; (o)
List( AdditionalFamilyName_t AddFamilyName1 ... AddFamilyNameN ) ; (o)
ReferenceState_t ReferenceState ; (o)
DataClass_t DataClass ; (o)
DimensionalUnits_t DimensionalUnits ; (o)
List( UserDefinedData_t UserDefinedData1 ... UserDefinedDataN ) ; (o)
int Ordinal ; (o)
} ;
Note
Default names for the Descriptor_t, BCDataSet_t, and UserDefinedData_t lists are as shown; users may choose other legitimate names. Legitimate names must be unique within a given instance of BC_t and shall not include the names BCProperty, BCType, DataClass, DimensionalUnits, FamilyName, GridLocation, InwardNormalIndex, InwardNormalList, Ordinal, PointList, PointRange, or ReferenceState.
GridLocation is optional; if absent its default value is Vertex. For other allowble values, see the table below.
One of PointRange or PointList must be specified but not both. They must define a subrange of the zone.
InwardNormalIndex is only an option for structured grids. For unstructured grid boundaries, it should not be used. InwardNormalIndex may have only one nonzero element, whose sign indicates the computationalcoordinate direction of the BC patch normal; this normal points into the interior of the zone.
InwardNormalList contains a list of vectors normal to the BC patch pointing into the interior of the zone. It is a function of PhysicalDimension and ListLength[]. The vectors are located at the vertices of the BC patch when GridLocation is set to Vertex. Otherwise, they are located at edge/face midpoints. The vectors are not required to have unit magnitude.
If PointRange and InwardNormalList are specified, an ordering convention is needed for indices on the BC patch. An ordering convention is also needed if a range is specified and local data is present in the BCDataSet_t substructures. FORTRAN multidimensional array ordering is used.
BCType
specifies the boundarycondition type, which gives general information on the boundarycondition equations to be enforced.
The BC patch may be specified by PointRange
if it constitutes a logically rectangular region.
In all other cases, PointList
should be used to list the vertices or cell edges/faces making up the BC patch.
When GridLocation
is set to Vertex
, then PointList
or PointRange
refer to vertex indices, for both structured and unstructured grids.
When GridLocation
is set to EdgeCenter
, then PointRange/List
refer to edge elements.
For 3D grids, when GridLocation
is set to FaceCenter
, IFaceCenter
, etc., then PointRange/List
refer to face elements.
The interpretation of PointRange/List
is summarized in the table below:
CellDimension 
GridLocation 







1 
vertices 
 
 
cells (line elements) 
2 
vertices 
edges 
 
cells (area elements) 
3 
vertices 
edges 
faces 
cells (volume elements) 
Note: In the table, *FaceCenter
stands for the possible types: IFaceCenter
, JFaceCenter
, KFaceCenter
, or FaceCenter
.
For structured grids, face centers are indexed using the minimum of the connecting vertex indices, as described in Structured Grid Notation and Indexing Conventions.
For unstructured grids, edge and face elements are indexed using their element numbering as defined in the Elements_t
data structures.
The BC patch defined by PointRange/List
is a surface region over which the particular set of boundary conditions is applied.
However, in the current standard there is no mechanism to specify whether boundary conditions are enforced in the weak or strong form.
If boundary conditions are imposed using collocation (i.e., strong form), there is also no requirement that they be imposed at the same locations used to define the BC patch (via PointRange/List
).
In the case when BC patches are defined in terms of vertices (or edges in 3D), then the bounding vertices will be located on multiple BC patches.
If boundary conditions are imposed using collocation at vertices, then for this case there is no mechanism to determine which BC patch takes precedence for any of these bounding vertices.
Some boundary conditions require a normal direction to be specified in order to be properly imposed.
For structured zones a computationalcoordinate normal can be derived from the BC patch specification by examining redundant index components.
Alternatively, for structured zones this information can be provided directly by InwardNormalIndex
.
From Note 4, this vector points into the zone and can have only one nonzero element.
For exterior faces of a zone in 3D, InwardNormalIndex
should take the following values:
Face 

Face 


imin 

imax 

jmin 

jmax 

kmin 

kmax 

The physicalspace normal vectors of the BC patch may be described by InwardNormalList
; these are located at vertices or cell faces, consistent with the BC patch specification.
InwardNormalList
is listed as an optional field because it is not always needed to enforce boundary conditions, and the physicalspace normals of a BC patch can usually be constructed from the grid.
However, there are some situations, such as gridcoordinate singularity lines, where InwardNormalList
becomes a required field, because it cannot be generated from other information.
The BC_t
structure provides for a list of boundarycondition data sets, described in the next section.
In general, the proper BCDataSet_t
instance to impose on the BC patch is determined by the BCType
association table.
The mechanics of determining the proper data set to impose is described in the section Matching Boundary Condition Data Sets.
For a few boundary conditions, such as a symmetry plane or polar singularity, the value of BCType
completely describes the equations to impose, and no instances of BCDataSet_t
are needed.
For “simple” boundary conditions, where a single set of Dirichlet and/or Neumann data is applied, a single BCDataSet_t
will likely appear (although this is not a requirement).
For “compound” boundary conditions, where the equations to impose are dependent on local flow conditions, several instances of BCDataSet_t
will likely appear; the procedure for choosing the proper data set is more complex as described in the section Matching Boundary Condition Data Sets.
A BCProperty_t
data structure may be used to record special properties associated with particular boundary condition patches, such as wall functions or bleed regions.
FamilyName
identifies the family to which the boundary belongs. Family names link the mesh boundaries to the CAD surfaces. (See the section on Family Data Structure Definition for more details.)
Boundary conditions may also be defined directly on families. In this case, the BCType
must be FamilySpecified
.
If, under a BC_t
structure, both FamilyName_t
and BCType_t
are present, and the BCType
is not FamilySpecified
, then the BCType
that is specified takes precedence over any BCType
that might be stored in a FamilyBC_t
structure under the specified Family_t
.
The actual name of the referredto Family_t
can be in the same base or another base, as detailed in Base Level Families.
Reference data applicable to the boundary conditions of a BC patch is contained in the ReferenceState
structure.
DataClass
defines the default for the class of data contained in the boundary conditions.
If the boundary conditions contain dimensional data, DimensionalUnits
may be used to describe the system of dimensional units employed.
If present, these three entities take precedence over all corresponding entities at higher levels of the hierarchy, following the standard precedence rules.
The UserDefinedData_t
data structure allows arbitrary userdefined data to be stored in Descriptor_t
and DataArray_t
children without the restrictions or implicit meanings imposed on these node types at other node locations.
Ordinal
is userdefined and has no restrictions on the values that it can contain. It is included for backward compatibility to assist implementation of the CGNS system into applications whose I/O depends heavily on the numbering of BC patches.
Since there are no restrictions on the values contained in Ordinal
(or that Ordinal
is even provided), there is no guarantee that the BC patches for a given zone in an existing CGNS database will have sequential values from 1 to N without holes or repetitions.
Use of Ordinal
is discouraged and is on a userbeware basis.
int
PointRange
, PointList
BC_t
requires the structure function ListLength
, which is used to specify the number of vertices or edge/face elements making up the BC patch.
If PointRange
is specified, then ListLength
is obtained from the number of points (inclusive) between the beginning and ending indices of PointRange
.
If PointList
is specified, then ListLength
is the number of indices in the list of points. In this situation, ListLength
becomes a user input along with the indices of the list PointList
.
By user we mean the application code that is generating the CGNS database.
ListLength
is also the number of elements in the list InwardNormalList
.
Note that syntactically PointList
and InwardNormalList
must have the same number of elements.
If neither PointRange
or PointList
is specified in a particular BCDataSet_t
substructure, ListLength
must be passed into it to determine the length of BC data arrays.
BCDataSet_t
¶BCDataSet_t
contains Dirichlet and Neumann data for a single set of boundarycondition equations.
Its intended use is for simple boundarycondition types, where the equations imposed do not depend on local flow conditions.
BCDataSet_t< int CellDimension, int IndexDimension,
int ListLengthParameter, GridLocation_t GridLocationParameter > :=
{
List( Descriptor_t Descriptor1 ... DescriptorN ) ; (o)
BCTypeSimple_t BCTypeSimple ; (r)
BCData_t<ListLengthBCData[]> DirichletData ; (o)
BCData_t<ListLengthBCData[]> NeumannData ; (o)
GridLocation_t GridLocation ; (o/d)
IndexRange_t<IndexDimension> PointRange ; (o)
IndexArray_t<IndexDimension, ListLength, int> PointList ; (o)
ReferenceState_t ReferenceState ; (o)
DataClass_t DataClass ; (o)
DimensionalUnits_t DimensionalUnits ; (o)
List( UserDefinedData_t UserDefinedData1 ... UserDefinedDataN ) ; (o)
} ;
Note
Default names for the Descriptor_t
and UserDefinedData_t
lists are as shown; users may choose other legitimate names. Legitimate names must be unique within a given instance of BCDataSet_t
and shall not include the names BCTypeSimple
, DataClass
, DimensionalUnits
, DirichletData
, GridLocation
, NeumannData
, PointList
, PointRange
, or ReferenceState
.
BCTypeSimple
is the only required field. All other fields are optional and the Descriptor_t
list may be empty.
GridLocation
is optional; if absent its default value is GridLocationParameter
. For 2D grids (CellDimension = 2
), GridLocation
may take the values of Vertex
or EdgeCenter
. For 3D grids (CellDimension = 3
), GridLocation
may take the values of Vertex
, EdgeCenter
, FaceCenter
, IFaceCenter
, JFaceCenter
or KFaceCenter
.
PointRange
and PointList
are both optional; only one of them may be specified. They must define a face subrange of the zone.
BCDataSet_t
requires the structure parameters CellDimension
, IndexDimension
, ListLengthParameter
, and GridLocationParameter
.
These are all used to control the grid location and length of data arrays in the Dirichlet
and Neumann
substructures.
They are inputs for the structure functions ListLength[]
and ListLengthBCData[]
defined below.
BCTypeSimple
specifies the boundarycondition type, which gives general information on the boundarycondition equations to be enforced.
BCTypeSimple
is also used for matching boundary condition data sets.
Boundarycondition data is separated by equation type into Dirichlet and Neumann conditions. Dirichlet boundary conditions impose the value of the given variables, whereas Neumann boundary conditions impose the normal derivative of the given variables. The mechanics of specifying Dirichlet and Neumann data for boundary conditions is covered in the section Boundary Condition Specification Data.
The substructures DirichletData
and NeumannData
contain boundarycondition data that may be constant over the BC patch, or defined locally at each vertex or edge/face of the patch. Locally defined data may be specified in one of two ways.
If GridLocation
, PointRange
and PointList
are all absent, then the data is defined consistent with the BC patch specification of the parent BC_t
structure.
In this case, the location of the locally defined data is given by GridLocationParameter
and the length of the data arrays are given by ListLengthParameter
.
If GridLocation
and one of PointRange
or PointList
is present, then the length of the data arrays is given by ListLength[]
.
Reference quantities applicable to the set of boundarycondition data are contained in the ReferenceState
structure. DataClass
defines the default for the class of data contained in the boundarycondition data.
If the boundary conditions contain dimensional data, DimensionalUnits
may be used to describe the system of dimensional units employed.
If present, these three entities take precedence over all corresponding entities at higher levels of the hierarchy, following the standard precedence rules.
The UserDefinedData_t
data structure allows arbitrary userdefined data to be stored in Descriptor_t
and DataArray_t
children without the restrictions or implicit meanings imposed on these node types at other node locations.
int
PointRange
, PointList
BCDataSet_t
requires the structure function ListLength
, which is used to specify the length of locally defined Dirichlet and Neumann data arrays when the grid location of these quantities differs from that of the BC patch definition. If PointRange
is specified, then ListLength
is obtained from the number of points (inclusive) between the beginning and ending indices of PointRange
. If PointList
is specified, then ListLength
is the number of indices in the list of points. In this situation, ListLength
becomes a user input along with the indices of the list PointList
. By user we mean the application code that is generating the CGNS database.
If neither PointRange
or PointList
is specified in a particular BCDataSet_t
substructure, ListLength
must be passed into it to determine the length of BC data arrays.
int
ListLengthParameter
, PointRange
, PointList
BCDataSet_t
also requires the structure function ListLengthBCData
. If PointRange
or PointList
is present, then ListLengthBCData
takes the value of ListLength
. If both are absent, then it takes the value ListLengthParameter
.
BCData_t
¶BCData_t
contains a list of variables and associated data for boundarycondition specification.
Each variable may be given as global data (i.e., a scalar) or local data defined at each grid point or cell face of the BC patch.
By convention all data specified in a given instance of BCData_t
is to be used in the same type of boundarycondition equation.
For example, the use of separate BCData_t
substructures for Dirichlet and Neumann equations in the BCDataSet_t
structure of the previous section.
BCData_t< int ListLength > :=
{
List( Descriptor_t Descriptor1 ... DescriptorN ) ; (o)
List( DataArray_t<DataType, 1, 1>
DataGlobal1 ... DataGlobalN ) ; (o)
List( DataArray_t<DataType, 1, ListLength>
DataLocal1 ... DataLocalN ) ; (o)
DataClass_t DataClass ; (o)
DimensionalUnits_t DimensionalUnits ; (o)
List( UserDefinedData_t UserDefinedData1 ... UserDefinedDataN ) ; (o)
} ;
Note
Default names for the Descriptor_t
, DataArray_t
, and UserDefinedData_t
lists are as shown; users may choose other legitimate names. Legitimate names must be unique within a given instance of BCData_t
and shall not include the names DataClass
or DimensionalUnits
.
There are no required elements; all three lists may be empty.
This structure definition shows separate lists for global verses local data.
The global data is essentially scalars, while the local data variables have size determined by the structure parameter ListLength
.
For DataArray_t
entities with standardized dataname identifiers, DataType
is determined by convention.
For userdefined variables, DataType
is a user input.
Two important points need to be mentioned regarding this structure definition.
First, this definition allows a given instance of BCData_t
to have a mixture of global and local data.
For example, if a user specifies Dirichlet data that has a uniform stagnation pressure but has a nonuniform velocity profile, this structure allows the user to describe the stagnation pressure by a scalar in the DataGlobal
list and the velocity by an array in the DataLocal
list.
Second, the only distinction between the lists (aside from default names, which will be seldom used) is the parameters passed into the DataArray_t
structure.
Therefore, in actual implementation of this BCData_t
structure it may not be possible to distinguish between members of the global and local lists without querying inside the DataArray_t
substructures.
Straightforward mapping onto the ADF or HDF database will not provide any distinctions between the members of the two lists. This hopefully will not cause any problems.
DataClass
defines the default for the class of data contained in the boundarycondition data.
If the boundarycondition data is dimensional, DimensionalUnits
may be used to describe the system of dimensional units employed.
If present, these two entities take precedence over all corresponding entities at higher levels of the hierarchy, following the standard precedence rules.
The UserDefinedData_t
data structure allows arbitrary userdefined data to be stored in Descriptor_t
and DataArray_t
children without the restrictions or implicit meanings imposed on these node types at other node locations.
BCProperty_t
¶BCProperty_t
allows the recording of special properties associated with particular boundary condition patches.
At the current time, only two properties (WallFunction_t
and Area_t
) are included, but extensions involving boundary conditions may be implemented as additional nodes under BCProperty_t
in the future.
BCProperty_t :=
{
List( Descriptor_t Descriptor1 ... DescriptorN ) ; (o)
WallFunction_t WallFunction ; (o)
Area_t Area ; (o)
List( UserDefinedData_t UserDefinedData1 ... UserDefinedDataN ) ; (o)
} ;
Note
Default names for the Descriptor_t
and UserDefinedData_t
lists are as shown; users may choose other legitimate names. Legitimate names must be unique within a given instance of BCProperty_t
and shall not include the names WallFunction
or Area
.
The WallFunction_t
and Area_t
data structures may be used to record properties associated with the use of wall functions, or arearelated boundary conditions such as bleed, respectively.
The UserDefinedData_t
data structure allows arbitrary userdefined data to be stored in Descriptor_t
and DataArray_t
children without the restrictions or implicit meanings imposed on these node types at other node locations.
WallFunction_t
¶The WallFunction_t
data structure allows data associated with the use of wall function boundary conditions to be recorded.
WallFunction_t :=
{
List( Descriptor_t Descriptor1 ... DescriptorN ) ; (o)
WallFunctionType_t WallFunctionType ; (r)
List( UserDefinedData_t UserDefinedData1 ... UserDefinedDataN ) ; (o)
} ;
Note
Default names for the Descriptor_t
and UserDefinedData_t
lists are as shown; users may choose other legitimate names. Legitimate names must be unique within a given instance of WallFunction_t
and shall not include the name WallFunctionType
.
WallFunctionType_t
is a required enumeration data structure that is used to define the type of wall functions being used.
WallFunctionType_t := Enumeration(
WallFunctionTypeNull,
WallFunctionTypeUserDefined,
Generic ) ;
Because there is such a wide array of methods for employing wall functions (few of which are welldocumented), the type Generic
is used to simply indicate that a wall function is employed, without specifying details.
Area_t
¶The Area_t
data structure allows data associated with arearelated boundary conditions such as bleed to be recorded.
Area_t :=
{
List( Descriptor_t Descriptor1 ... DescriptorN ) ; (o)
AreaType_t AreaType ; (r)
DataArray_t<real, 1, 1> SurfaceArea ; (r)
DataArray_t<real, 1, 32> RegionName ; (r)
List( UserDefinedData_t UserDefinedData1 ... UserDefinedDataN ) ; (o)
} ;
Note
Default names for the Descriptor_t
and UserDefinedData_t
lists are as shown; users may choose other legitimate names. Legitimate names must be unique within a given instance of Area_t
and shall not include the names AreaType
, RegionName
, or SurfaceArea
.
AreaType_t
is a required enumeration data structure that is used to define the type of area being defined.
AreaType_t := Enumeration(
AreaTypeNull,
AreaTypeUserDefined,
BleedArea,
CaptureArea ) ;
If AreaType
is set to BleedArea
, the value of SurfaceArea
is the size of the current bleed surface.
Note that bleed is commonly used with wall boundary conditions. The bleed area is the surface area of the boundary condition patch.
If AreaType
is set to CaptureArea
, then SurfaceArea
represents the size of the current capture surface.
For inlet flows, for example, the capture area is the area of a fictitious surface in front of the inlet in which mass is pulled into the inlet.
This is used to calculate the mass flow for the boundary condition patch based on the formula:
where \(\mathit{MFR}\) is the desired mass flow ratio and \(A_{cap}\) is the capture area. Another interpretation is the farupstream crosssectional area of the stream tube that feeds the inlet. Note that the capture area is usually defined with an outflow boundary condition, which is commonly used at an engine face.
The RegionName
is character identifier, and is needed so that a specific region can span multiple surfaces over multiple zones.
BCType_t
¶BCType_t
is an enumeration type that identifies the boundarycondition equations to be enforced at a given boundary location.
BCType_t := Enumeration(
BCTypeNull, BCTypeUserDefined, BCAxisymmetricWedge, BCDegenerateLine.
BCDegeneratePoint, BCDirichlet, BCExtrapolate, BCFarfield, BCGeneral,
BCInflow, BCInflowSubsonic, BCInflowSupersonic, BCNeumann,
BCOutflow, BCOutflowSubsonic, BCOutflowSupersonic, BCSymmetryPlane,
BCSymmetryPolar, BCTunnelInflow, BCTunnelOutflow, BCWall,
BCWallInviscid, BCWallViscous, BCWallViscousHeatFlux,
BCWallViscousIsothermal, FamilySpecified ) ;
The boundarycondition type is further defined as simple, BCTypeSimple_t
, or compound, BCTypeCompound_t
, which are subsets of the enumeration type BCType_t
.
BCTypeSimple_t := Enumeration(
BCTypeNull, BCTypeUserDefined, BCAxisymmetricWedge, BCDegenerateLine.
BCDegeneratePoint, BCDirichlet, BCExtrapolate, BCGeneral,
BCInflowSubsonic, BCInflowSupersonic, BCNeumann,
BCOutflowSubsonic, BCOutflowSupersonic, BCSymmetryPlane,
BCSymmetryPolar, BCTunnelInflow, BCTunnelOutflow, BCWall,
BCWallInviscid, BCWallViscous, BCWallViscousHeatFlux,
BCWallViscousIsothermal, FamilySpecified ) ;
BCTypeCompound_t := Enumeration(
BCTypeNull, BCTypeUserDefined, BCInflow, BCOutflow,
BCFarfield ) ;
The members of BCTypeSimple_t
completely identify the equations to impose, while those of BCTypeCompound_t
give a general description of the class of boundarycondition equations to impose.
The specific boundarycondition equations to enforce for each value of BCType_t
are listed in separate tables for Simple Boundary Condition Types and Compound Boundary Condition Types.
The subdivision of BCType_t
is based on function. For simple boundary conditions, the equations and data imposed are fixed; whereas, for compound boundary conditions different sets of equations are imposed depending on local flow conditions at the boundary. This distinction requires additional rules for dealing with simple and compound boundarycondition types.
For the inflow/outflow boundarycondition descriptions, 3D inviscid compressible flow is assumed; the 2D equivalent should be obvious. These same boundary conditions are typically used for viscous cases also. This “3D Euler” assumption will be noted wherever used.
In the following tables, \(Q\) is the solution vector, \(\mathbf{q}\) is the velocity vector whose magnitude is \(q\), the unit normal to the boundary is \(\mathbf{n}\), and \(\partial () / \partial n =\mathbf{n} \cdot \nabla\) is differentiation normal to the boundary.

Boundary Condition Description 

BCGeneral 
Arbitrary conditions on \(Q\) or \(\partial Q / \partial n\) 
BCDirichlet 
Dirichlet condition on \(Q\) vector 
BCNeumann 
Neumann condition on \(\partial Q / \partial n\) 
BCExtrapolate 
Extrapolate \(Q\) from interior 
BCWallInviscid 
Inviscid (slip) wall

BCWallViscousHeatFlux 
Viscous noslip wall with heat flux

BCWallViscousIsothermal 
Viscous noslip, isothermal wall

BCWallViscous 
Viscous noslip wall; special cases are

BCWall 
General wall condition; special cases are 
BCInflowSubsonic 
Inflow with subsonic normal velocity

BCInflowSupersonic 
Inflow with supersonic normal velocity
Same as 
BCOutflowSubsonic 
Outflow with subsonic normal velocity

BCOutflowSupersonic 
Outflow with supersonic normal velocity
Same as 
BCTunnelInflow 
Tunnel inlet (subsonic normal velocity)

BCTunnelOutflow 
Tunnel exit (subsonic normal velocity)

BCDegenerateLine 

BCDegeneratePoint 

BCSymmetryPlane 
Symmetry plane; face should be coplanar

BCSymmetryPolar 
Polarcoordinate singularity line; special case of

BCAxisymmetricWedge 
Axisymmetric wedge; special case of 
FamilySpecified 
A boundary condition type is being specified for the family to which the current boundary belongs. A 

Boundary Condition Description 

BCInflow 
Inflow, arbitrary normal Mach; test on normal Mach, then perform one of: 
BCOutflow 
Outflow, arbitrary normal Mach; test on normal Mach, then perform one of: 
BCFarfield 
Farfield inflow/outflow, arbitrary normal Mach; test on normal velocity and normal Mach, then perform one of: 
The BC_t
structure allows for a arbitrary list of boundarycondition data sets, described by the BCDataSet_t
structure.
For simple boundary conditions, a single data set must be chosen from a list that may contain more than one element.
Likewise, for a compound boundary condition, a limited number of data sets must be chosen and applied appropriately.
The mechanism for the proper choice of data sets is controlled by the BCType
field of the BC_t
structure, the BCTypeSimple
field of the BCDataSet_t
structure, and the boundarycondition type association table.
In the following discussion, we will use the “/” notation for fields or elements of a structure type.
BC_t
is used for both simple and compound boundary conditions; hence, the field BC_t
/BCType
is of type BCType
.
Conversely, the substructure BCDataSet_t
is intended to enforce a single set of boundarycondition equations independent of local flow conditions (i.e., it is appropriate only for simple boundary conditions).
This is why the field BCDataSet_t
/BCTypeSimple
is of type BCTypeSimple_t
and not BCType_t
.
The appropriate choice of data sets is determined by matching the field BC_t
/BCType
with the field BCDataSet_t/BCTypeSimple
as specified in the boundarycondition type association table.
For simple boundary conditions, a single match from the list of BCDataSet_t
instances is required.
For all BCTypeSimple_t
identifiers, except BCInflowSupersonic
and BCOutflowSupersonic
, an exact match is necessary. BCInflowSupersonic
will match itself or BCDirichlet
; BCOutflowSupersonic
will match itself or BCExtrapolate
.
For compound boundary conditions, the association table specifies which simple boundarycondition types are appropriate.
Since compound boundary conditions enforce different boundarycondition equation sets depending on local flow conditions, several instances of BCDataSet_t
will be matched for each BCTypeCompound_t
identifier.
The accompanying rule determines which of the matching data sets to apply at a given location on the BC patch.
This provides a general procedure applicable to both BCTypeSimple_t
and BCTypeCompound_t
situations.
For a given BC_t/BCType
use those instances of BCDataSet_t
whose field BCDataSet_t/BCTypeSimple
matches according to the following table.
Apply the matching data set or sets as prescribed by the appropriate usage rule.

Associated 

BCInflow 
BCInflowSupersonic BCInflowSubsonic Usage Rule:

BCOutflow 
BCOutflowSupersonic BCOutflowSubsonic Usage Rule:

BCFarfield 
BCInflowSupersonic BCInflowSubsonic BCOutflowSupersonic BCOutflowSubsonic Usage Rule:

BCInflowSupersonic 
BCInflowSupersonic BCDirichlet Usage Rule:

BCOutflowSupersonic 
BCOutflowSupersonic BCExtrapolate Usage Rule:

All others 
Selfmatching 
Although we present a strict division between the two categories of boundarycondition types, we realize that some overlap may exist.
For example, some of the more general simple boundarycondition types, such as BCWall
, may include a situation of inflow/outflow (say if the wall is porous).
These complications require further guidelines on appropriate definition and use of boundarycondition types. The real distinctions between BCTypeSimple_t
and BCTypeCompound_t
are as follows:
BCTypeSimple_t
identifiers always match themselves; BCTypeCompound_t
identifiers never match themselves.
BCTypeSimple_t
identifiers always produce a single match; BCTypeCompound_t
will produce multiple matches.
The usage rule for BCTypeSimple_t
identifiers is always trivial  apply the single matching data set regardless of local flow conditions.
Therefore, any boundary condition that involves application of different data sets depending on local flow conditions should be classified BCTypeCompound_t
.
If a type that we have classified BCTypeSimple_t
is used as a compound type (BCWall
for a porous wall is an example), then it should somehow be reclassified.
One option is to define a new BCTypeCompound_t
identifier and provide associated BCTypeSimple_t
types and a usage rule.
Another option may be to allow some identifiers to be both BCTypeSimple_t
and BCTypeCompound_t
and let their appropriate use be based on context. This is still undetermined.
For a given simple boundary condition (i.e., one that is not dependent on local flow conditions), the database provides a set of boundarycondition equations to be enforced through the structure definitions for BCDataSet_t
and BCData_t
.
Apart from the boundarycondition type, the precise equations to be enforced are described by boundarycondition solution data.
These specified solution data are arranged by “equation type”:
 Dirichlet
\(Q = Q_{specified}\)
 Neumann
\(\partial Q / \partial n = (\partial Q / \partial n)_{specified}\)
The DirichletData
and NeumannData
entities of BCData_t
list both the solution variables involved in the equations (through the dataname identifier conventions) and the specified solution data.
Two issues need to be addressed for specifying Dirichlet or Neumann boundarycondition data. The first is whether the data is global or local:
 Global BC data
Data applied globally to the BC patch; for example, specifying a uniform total pressure at an inflow boundary
 Local BC data
Data applied locally at each vertex or cell face of the BC patch; an example of this is varying total pressure specified at each grid point at an inflow boundary
The second issue is describing the actual solution quantities that are to be specified. Both of these issues are addressed by use of the DataArray_t
structure.
For some types of boundary conditions, many different combinations of solution quantities could be specified.
For example, BCInflowSubsonic
requires 4 solution quantities to be specified in 3D, but what those 4 quantities are varies with applications (e.g., internal verses external flows) and codes.
We propose the convention that the actual data being specified for any BCType
is given by the list of DataArray_t
entities included in DirichletData and NeumannData structures (actually by the identifier attached to each instance of DataArray_t
).
This frees us from having to define many versions of a given BCType
(e.g., BCInflowSubsonic1
, BCInflowSubsonic2
, etc.), where each has a precisely defined set of Dirichlet data.
We are left with the easier task of defining how many Dirichlet or Neumann quantities must be provided for each BCType
.
An example of using DataArray_t
identifier conventions to describe BC specification data is the following: subsonic inflow with uniform stagnation pressure, mass flow and crossflow angle specified; the Dirichlet data are stagnation pressure = 2.56, mass flow = 1.34, and crossflow angle has a ycomponent of 0.043 and a zcomponent of 0.02 (ignore dimensionalunits or normalization for the present). The specified solution variables and associated data are described as shown:
BCData_t<ListLength=?> DirichletData =
{{
DataArray_t<real, 1, 1> PressureStagnation = {{ Data(real, 1, 1) = 2.56 }} ;
DataArray_t<real, 1, 1> MassFlow = {{ Data(real, 1, 1) = 1.34 }} ;
DataArray_t<real, 1, 1> VelocityAngleY = {{ Data(real, 1, 1) = 0.043 }} ;
DataArray_t<real, 1, 1> VelocityAngleZ = {{ Data(real, 1, 1) = 0.02 }} ;
}} ;
Basically, this states that DirichletData
contains four instances of DataArray_t
with identifiers or names PressureStagnation
, MassFlow
, VelocityAngleY
and VelocityAngleZ
.
Each DataArray_t
structure entity contains a single floatingpoint value; these are the Dirichlet data for the BC. Note that Data(real, 1, 1)
means a single floatingpoint value.
The global verses local data issue can be easily handled by storing either a scalar, as shown above, for the global BC data case; or storing an array for the local BC data case. Storing an array of local BC data allows the capability for specifying nonconstant solution profiles, such as “analytic” boundarylayer profiles or profiles derived from experimental data. For the above example, if the stagnation pressure is instead specified at every vertex of the boundarycondition patch the following results:
BCData_t<ListLength=99> DirichletData =
{{
DataArray_t<real, 1, 99> PressureStagnation =
{{ Data(real, 1, 99) = (PTOT(n), n=1,99) }} ;
DataArray_t<real, 1, 1> MassFlow = {{ Data(real, 1, 1) = 1.34 }} ;
DataArray_t<real, 1, 1> VelocityAngleY = {{ Data(real, 1, 1) = 0.043 }} ;
DataArray_t<real, 1, 1> VelocityAngleZ = {{ Data(real, 1, 1) = 0.02 }} ;
}} ;
where, say, the boundary face is logically rectangular and contains \(11 \times 9\) vertices and the stagnation pressure at the vertices is given by the array PTOT()
.
To facilitate implementation of boundary conditions into existing flow solvers, we adopt the convention that if no boundarycondition data is specified, then flow solvers are free to enforce any appropriate boundarycondition equations.
This includes situations where entities of BCDataSet_t
, BCData_t
or DataArray_t
are absent within the boundarycondition hierarchy.
By convention, if no BCDataSet
entities are present, then application codes are free to enforce appropriate BCs for the given value of BCType
.
Furthermore, if the entities DirichletData
and NeumannData
are not present in an instance of BCDataSet_t
, or if insufficient data is present in DirichletData
or NeumannData
(e.g., if only one Dirichlet variable is present for a subsonic inflow condition), then application codes are free to fill out the boundarycondition data as appropriate for the BCTypeSimple
identifier.
The various levels of BC implementation allowed are shown in the following figure, from the lowest level in which the application codes interpret the BCType
, to the fully SIDScompliant BC implementation that completely defines the BC within the CGNS file.
An alternative approach to the present design could be to list all the solution variables and data (as DataArray_t
like structures) for the boundary condition, and contain descriptive tags in each one to indicate if they are Dirichlet or Neumann data.
We have not taken this approach. We think grouping boundarycondition data by “equation type” as we have done better allows for future extension to other types of boundary conditions (e.g., 2ndorder nonreflecting BC’s that result in partial differential equations to be solved at the boundary).
This section contains boundarycondition examples with increasing complexity. Included is the most simple BC_t
entity and one of the most complex.
The examples show situations of local and global boundarycondition data, simple and compound boundarycondition types, and multiple boundarycondition data sets that must be matched with the appropriate boundarycondition type.
Symmetry plane for a patch on the imin face of a 3D structured zone.
! CellDimension = 3, IndexDimension = 3
BC_t<3,3,3> BC1 =
{{
BCType_t BCType = BCSymmetryPlane ;
IndexRange_t<3> PointRange =
{{
int[3] Begin = [1,1,1 ] ;
int[3] End = [1,9,17] ;
}} ;
}} ;
Since the boundarycondition equations to be enforced are completely defined by the boundarycondition type BCSymmetryPlane
, no other information needs to be provided, except for the extent of the BC patch.
The BC patch is specified by PointRange
with a beginning index of (1,1,1) and an ending index of (1,9,17). By default, these refer to vertices.
A viscous solid wall for a 3D structured zone, where a Dirichlet condition is enforced for temperature; the wall temperature for the entire wall is specified to be 273 K. The BC patch is on the jmin face and is bounded by the indices (1,1,1) and (33,1,9).
! CellDimension = 3, IndexDimension = 3
BC_t<3,3,3> BC2 =
{{
BCType_t BCType = BCWallViscousIsothermal ;
IndexRange_t<3> PointRange =
{{
int[3] Begin = [1 ,1,1] ;
int[3] End = [33,1,9] ;
}} ;
! ListLength = 33*9 = 297
BCDataSet_t<297> BCDataSet1 =
{{
BCTypeSimple_t BCTypeSimple = BCWallViscousIsothermal ;
! Data array length = ListLength = 297
BCData_t<297> DirichletData =
{{
DataArray_t<real, 1, 1> Temperature =
{{
Data(real, 1, 1) = 273. ;
DataClass_t DataClass = Dimensional ;
DimensionalUnits_t DimensionalUnits =
{{
MassUnits = MassUnitsNull ;
LengthUnits = LengthUnitsNull ;
TimeUnits = TimeUnitsNull ;
TemperatureUnits = Kelvin ;
AngleUnits = AngleUnitsNull ;
}} ;
}} ;
}} ;
}} ;
}} ;
This is an example of a simple boundarycondition type, BCWallViscousIsothermal
.
By default there is a zero Dirichlet condition on the velocity, and BCDataSet1
states there is a Dirichlet condition on temperature with a global value of 273 K.
The data set contains a single BCData_t
entity, called DirichletData
, meaning a (possibly empty) collection of Dirichlet conditions should be enforced.
Within DirichletData
, there is a single DataArray_t
entity; this narrows the specification to a single Dirichlet condition.
This lone entity has the identifier Temperature
, which by the dataname identifier conventions is the identifier for static temperature.
The data contained in Temperature
is a floatingpoint scalar with a value of 273.
The qualifiers DataClass
and DimensionalUnits
specify that the temperature is dimensional with units of Kelvin.
Since BCWallViscousIsothermal
is a simple boundarycondition type, the appropriate data set contains a BCTypeSimple
entity whose value is BCWallViscousIsothermal
.
For this example, only a single data set is provided, and this data set has the correct boundarycondition type.
This is an example of a trivial dataset match.
Apart from velocity and temperature, additional “numerical” boundary conditions are typically required by NavierStokes flow solvers, but none are given here; therefore, a code is free to implement other additional boundary conditions as desired.
Although the boundarycondition data is global, we include in this example structure parameters that are the lengths of potential localdata arrays.
Comments are added to the example with the “!” notation to document the structure parameters.
The BC_t
structure function ListLength
is evaluated based on PointRange
.
Since GridLocation
is not specified in BC2
, any local data is at vertices by default.
The entity Temperature
contains global data, so the value of ListLength
is unused in DirichletData
.
This example raises the question of whether unused structure parameters are required in structure entities.
The answer is no. We included them here for completeness. The purpose of structure parameters is to mimic the need to define elements of a entity based on information contained elsewhere (at a higher level) in the CGNS database.
When this need is not present in a given instance of a structure entity, the structure parameters are superfluous.
In some of the following examples, structure parameters that are superfluous or otherwise not needed are denoted by “?
”.
Subsonic inflow for a 2D structured zone: The BC patch is on the imin face and includes \(j \in [2, 7]\).
As prescribed by the boundarycondition type, three quantities must be specified.
Uniform entropy and stagnation enthalpy are specified with values of 0.94 and 2.85, respectively.
A velocity profile is specified at face midpoints, given by the array v_inflow(j)
.
No dimensional or nondimensional information is provided.
! CellDimension = 2, IndexDimension = 2
BC_t<2,2,?> BC3 =
{{
BCType_t BCType = BCInflowSubsonic ;
GridLocation_t GridLocation = FaceCenter ;
IndexRange_t<2> PointRange =
{{
int[2] Begin = [1,2] ;
int[2] End = [1,6] ;
}} ;
! ListLength = 5
BCDataSet_t<5> BCDataSet1 =
{{
BCTypeSimple_t BCTypeSimple = BCInflowSubsonic ;
! Data array length = ListLength = 5
BCData_t<5> DirichletData =
{{
DataArray_t<real, 1, 1> EntropyApprox =
{{
Data(real, 1, 1) = 0.94 ;
}} ;
DataArray_t<real, 1, 1> EnthalpyStagnation =
{{
Data(real, 1, 1) = 2.85 ;
}} ;
DataArray_t<real, 1, 5> VelocityY =
{{
Data(real, 1, 5) = (v_inflow(j), j=3,7) ;
}} ;
}} ;
}} ;
}} ;
This is another example of a simple boundarycondition type.
The primary additional complexity included in this example is multiple Dirichlet conditions with one containing local data.
DirichletData
contains three DataArray_t
entities named EntropyApprox
, EnthalpyStagnation
and VelocityY
.
This specifies three Dirichlet boundary conditions to be enforced, and the names identify the solution quantities to set.
Since both EntropyApprox
and EnthalpyStagnation
have an arraylength structure parameter of one, they identify global data, and the values are provided.
VelocityY
is an array of data values and contains the values in v_inflow()
.
The length of the array is given by ListLength
, which represents the number of cell faces because BC3
is specified using the value of FaceCenter
for GridLocation
.
Note that the beginning and ending indices on the array v_inflow()
are unimportant (they are user inputs); there just needs to be five values provided.
Outflow boundary condition with unspecified normal Mach number for an imax face of a 3D structured zone: For subsonic outflow, a uniform pressure is specified; for supersonic outflow, no boundarycondition equations are specified.
! CellDimension = 3, IndexDimension = 3
BC_t<3,3,3> BC4 =
{{
BCType_t BCType = BCOutflow ;
IndexRange_t<3> PointRange = {{ }} ;
BCDataSet_t<?> BCDataSetSubsonic =
{{
BCTypeSimple_t BCTypeSimple = BCOutflowSubsonic ;
BCData_t<?> DirichletData =
{{
DataArray_t<real, 1, 1> Pressure = {{ }} ;
}} ;
}} ;
BCDataSet_t<?> BCDataSetSupersonic =
{{
BCTypeSimple_t BCTypeSimple = BCOutflowSupersonic ;
}} ;
}} ;
This is an example of a complex boundarycondition type; the equation set to be enforced depends on the local flow conditions, namely the Mach number normal to the boundary.
Two data sets are provided, BCDataSetSubsonic
and BCDataSetSupersonic
; recall the names are unimportant and are user defined.
The first data set has a boundarycondition type of BCOutflowSubsonic
and prescribes a global Dirichlet condition on static pressure.
Any additional boundary conditions needed may be applied by a flow solver. The second data set has a boundarycondition type of BCOutflowSupersonic
with no additional boundarycondition equation specification.
Typically, all solution quantities are extrapolated from the interior for supersonic outflow.
From the boundarycondition type association table, BCOutflow
requires two data sets with boundarycondition types BCOutflowSubsonic
and BCOutflowSupersonic
.
The accompanying usage rule states that the data set for BCOutflowSubsonic
should be used for a subsonic normal Mach number; otherwise, the data set for BCOutflowSupersonic
should be enforced.
Any additional data sets with boundarycondition types other than BCOutflowSubsonic
or BCOutflowSupersonic
could be provided (the definition of BC_t
allows an arbitrary list of BCDataSet_t
entities); however, they should be ignored by any code processing the boundarycondition information.
Another caveat is that providing two data sets with the same simple boundarycondition type would cause indeterminate results  which one is the correct data set to apply?
The actual global data value for static pressure is not provided; an abbreviated form of the Pressure
entity is shown.
This example also uses the “?
” notation for unused dataarraylength structure parameters.
Farfield boundary condition with arbitrary flow conditions for a jmax face of a 2D structured zone: If subsonic inflow, specify entropy, vorticity and incoming acoustic characteristics; if supersonic inflow specify entire flow state; if subsonic outflow, specify incoming acoustic characteristic; and if supersonic outflow, extrapolate all flow quantities. None of the extrapolated quantities for the different boundary condition possibilities need be stated.
! CellDimension = 2, IndexDimension = 2
BC_t<2,2,2> BC5 =
{{
BCType_t BCType = BCFarfield ;
IndexRange_t<2> PointRange = {{ }} ;
int[2] InwardNormalIndex = [0,1] ;
BCDataSet_t<?> BCDataSetInflowSupersonic =
{{
BCTypeSimple_t BCTypeSimple = BCInflowSupersonic ;
}} ;
BCDataSet_t<?> BCDataSetInflowSubsonic =
{{
BCTypeSimple_t BCTypeSimple = BCInflowSubsonic ;
BCData<?> DirichletData =
{{
DataArray_t<real, 1, 1> CharacteristicEntropy = {{ }} ;
DataArray_t<real, 1, 1> CharacteristicVorticity1 = {{ }} ;
DataArray_t<real, 1, 1> CharacteristicAcousticPlus = {{ }} ;
}} ;
}} ;
BCDataSet_t<?> BCDataSetOutflowSupersonic =
{{
BCTypeSimple_t BCTypeSimple = BCOutflowSupersonic ;
}} ;
BCDataSet_t<?> BCDataSetOutflowSubsonic =
{{
BCTypeSimple_t BCTypeSimple = BCOutflowSubsonic ;
BCData<?> DirichletData =
{{
DataArray_t<real, 1, 1> CharacteristicAcousticMinus = {{ }} ;
}} ;
}} ;
}} ;
The farfield boundarycondition type is the most complex of the compound boundarycondition types.
BCFarfield
requires four data sets; these data sets must contain the simple boundarycondition types BCInflowSupersonic
, BCInflowSubsonic
, BCOutflowSupersonic
and BCOutflowSubsonic
.
This example provides four appropriate data sets. The usage rule given for BCFarfield
states which set of boundarycondition equations to be enforced based on the normal velocity and normal Mach number.
The data set for supersonicinflow provides no information other than the boundarycondition type.
A flow solver is free to apply any conditions that are appropriate; typically all solution quantities are set to freestream reference state values.
The data set for subsonicinflow states that three Dirichlet conditions should be enforced; the three data identifiers provided are from the standard dataname identifier conventions.
The data set for supersonicoutflow only provides the boundarycondition type, and the data set for subsonicoutflow provides one Dirichlet condition on the incoming acoustic characteristic, CharacteristicAcousticMinus
.
Also provided in the example is the inwardpointing computationalcoordinate normal; the normal points in the \(j\) direction, meaning the BC patch is a jmax face.
This information could also be obtained from the BC patch description given in IndexRange
.
Note that this example shows only the overall layout of the boundarycondition entity.
IndexRange
and all DataArray_t
entities are abbreviated, and all unused structure functions are not evaluated.
There are circumstances when a user may wish to define a BC patch using vertices (under BC_t
), but store the BC data at face centers (under BCDataSet_t
).
The following example is similar to the Viscous Solid Wall example given previously, with the exception that the Dirichlet data for temperature is stored at face centers rather than at vertices.
As before, the example is a viscous solid wall in a 3D structured zone, where a Dirichlet condition is enforced for temperature; the wall temperature for the entire wall is specified to be 273 K. The BC patch is on the jmin face and is bounded by the indices (1,1,1) and (33,1,9).
! CellDimension = 3, IndexDimension = 3
BC_t<3,3,3> BC2 =
{{
BCType_t BCType = BCWallViscousIsothermal ;
! Grid location is Vertex by default
IndexRange_t<3> PointRange =
{{
int[3] Begin = [1 ,1,1] ;
int[3] End = [33,1,9] ;
}} ;
! ListLength = 33*9 = 297
BCDataSet_t<297> BCDataSet1 =
{{
BCTypeSimple_t BCTypeSimple = BCWallViscousIsothermal ;
GridLocation_t GridLocation = FaceCenter ;
IndexRange_t<3> PointRange =
{{
int[3] Begin = [1 ,1,1] ;
int[3] End = [32,1,8] ;
}} ;
! ListLength = 32*8 = 256
BCData_t<256> DirichletData =
{{
DataArray_t<real, 1, 1> Temperature =
{{
Data(real, 1, 1) = 273. ;
DataClass_t DataClass = Dimensional ;
DimensionalUnits_t DimensionalUnits =
{{
MassUnits = MassUnitsNull ;
LengthUnits = LengthUnitsNull ;
TimeUnits = TimeUnitsNull ;
TemperatureUnits = Kelvin ;
AngleUnits = AngleUnitsNull ;
}} ;
}} ;
}} ;
}} ;
}} ;
As in the previous Viscous Solid Wall example, although the boundarycondition data is global, we include in this example structure parameters that are the lengths of potential localdata arrays.
In BC_t
, GridLocation
is not specified, and thus is Vertex
by default.
The structure function ListLength
is 297, based on the specification of PointRange
, and that value is passed to BCDataSet_t
.
In this example PointRange
is specified in BCDataSet_t
, so the ListLength
passed into it from BC_t
is not used.
In BCDataSet_t
, GridLocation
is specified as FaceCenter
, and PointRange
is set accordingly.
The corresponding value of ListLength
is 256, which is passed into BCData_t
.
As before, in BCData_t
the entity Temperature
contains global data, so the value of ListLength
is unused.