This section, together with the CGNS File Mapping Figures , constitutes a complete description of the CGNS database structure, together with detailed descriptions of the contents of each attribute of each node. It is intended to be suitable as a reference for anyone implementing CGNS within their own database manager or using the CGIO Core Routines. It should also be of interest to those wishing to understand exactly where information is stored within a CGNS database.
Note that it is the advertised purpose of the CGNS MidLevel Library to store and retrieve information in conformity with the mapping herein described. Therefore, anyone accessing a CGNS database through the CGNS routines alone does not need a detailed understanding of the file mapping per se. However, this document should still prove useful in ascertaining the meaning of some of the arguments which must be supplied to the Library routines. Further, it will be necessary to consult the SIDS themselves to determine some of the naming conventions.
The node descriptions in this section are closely coupled to and crossreferenced with the CGNS File Mapping Figures, which show all the nodes defined in the SIDS that have child nodes. In the current section, the “Children:” entry in the list of Node Attributes is a link to the figure showing that node with its children. The “Label:” entry (or, in some cases, the “Name:” entry) is a link to the definition of the node’s data structure in the SIDS.
The nodal hierarchy of the CGNS database directly reflects that of the SIDS . Certain sections of the SIDS, notably BuildingBlock Structure Definitions , DataArray Structure Definitions , and Miscellaneous Data Structures , describe basic data structures which appear repeatedly as children of nodes representing more complex structures. In order to simplify the presentation and avoid the introduction of undefined terms, this section has been divided into two parts. The first defines a number of basic types which recur often in the structure, and the second describes higher level nodes of more specific function built from the basic nodes
In this section we describe CGNS nodes which hold fundamental types of information. Their structure and function, which are the same everywhere, are described here. However, the meaning of the data they hold at any particular point in a CGNS database depends on the context, i.e., the parent node. Therefore, where necessary, any special contextdependent meaning is elaborated in the paragraph devoted to the parent.
These are userassigned nodes designed to further describe the user’s intent. Their data is meant for human perusal or other userdesignated purposes.
Descriptor_t
¶The purpose of a node of type Descriptor_t
is to store textual data. It is not intended to be read by any system software, except to return the text for human examination.
The intent of the Descriptor_t
node is to hold comment sufficient to allow someone other than the originator to understand what the node contains. This may consist of a problem description, reference documents, personal notes, etc.
Any node may have zero to many Descriptor_t
children, with the uses differentiated by the Name field. At this time, there are no conventions for these names or for the form of the associated text. It is expected that a standard set such as README
, TimeStamp
, etc. will evolve as a matter of practice.
Name: 
User defined 

Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string to be stored, including any carriage control or null bytes. 
Data: 
String  Since line terminators can be stored within the data, the user could conceptually store an entire document in this area, read it into a program and then print it out. For example, an entire PostScript document describing the problem (and maybe results) could be stored in the Data field, read by a program and then sent to a printer. 
Children: 
None 
Cardinality: 
0, N 
Ordinal_t
¶Because there is no notion of order among children, there is occasionally a desire to order children in a way that survives from one opening of a CGNS database to another. The current CGNS Library provides means of doing this. However, another early method was to place the node “number” in a child of type Ordinal_t
.
Like Descriptor_t
, the Ordinal_t
node is completely under the control of the user, who takes full responsibility for its content. Unlike Descriptor_t
, CGNS conventions do not encourage the use of Ordinal_t
, as it usually encodes information which is redundant with the name. It is not read or written by standard CGNS software, and so there is no assurance that sibling nodes will be differently, consecutively, or consistently numbered by Ordinal_t
. Clearly, if Ordinal_t
must be used, no node should have more than one Ordinal_t
child, and no two siblings should have Ordinal_t
children containing the same data.
It is worth noting that, if consistent numbering is desired, one way of achieving it is to make the desired integer either the name or part of the name. In fact, if, for example, individual zones are left unnamed, the default convention will provide names of Zone1
, Zone2
, etc. Alternatively, the character strings “1
“, “2
“, …, are legal names. The CGNS software, of course, will return these as strings. This may necessitate type conversion or parsing before the names can be used as integer indices.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
1 
Data: 
The userdefined ordinal number (an integer). 
Children: 
None 
Cardinality: 
0,1 
DataClass_t
¶A DataClass_t
node specifies the dimensional nature of the data in and below its parent. It overrides any DataClass_t
information higher up in the tree. There are six recognized string values. It is necessary to consult the SIDS to determine the precise meaning.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
The length of the string 
Data: 
One of: 
Children: 
None 
Cardinality: 
0,1 
DimensionalUnits_t
¶A DimensionalUnits_t
node specifies dimensional units which apply to data in and below its parent. It overrides any DimensionalUnits_t
information higher up in the tree. There are five strings to specify, corresponding, respectively, to units for mass, length, time, temperature, and angular measure. The number of recognized string values varies with the physical property.
Units for three additional types of data are specified in a child node, AdditionalUnits_t .
Name: 



Label: 


DataType: 


Dimension: 
2 

Dimension Values: 
(32,5) 

Data: 


Children: 

Cardinality: 
0,1 
AdditionalUnits_t
¶An AdditionalUnits_t
node specifies dimensional units for additional types of data. To maintain compatibility with earlier CGNS versions, this is an optional child node of DimensionalUnits_t . The specified units apply to data in and below the parent of the corresponding DimensionalUnits_t
node, and override any AdditionalUnits_t
information higher up in the tree. There are three strings to specify, corresponding, respectively, to units for electric current, substance amount, and luminous intensity. The number of recognized string values varies with the physical property.
Name: 



Label: 


DataType: 


Dimension: 
2 

Dimension Values: 
(32,3) 

Data: 


Children: 
None 

Cardinality: 
0,1 
DataConversion_t
¶A DataConversion_t
node specifies a nonhomogeneous linear function which converts nondimensional data in its parent to raw dimensional data. Although in principle it overrides any DataConversion_t
information higher up in the tree, it is generally not meaningful for it to apply to more than one kind of physical data. Therefore, CGNS specifies its use only as a child of a node which actually contains a single type of real data.
There are two values to specify, corresponding to the scale factor and offset. The SIDS contain the exact conversion formula.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
2 
Data: 

Children: 
None 
Cardinality: 
0,1 
DimensionalExponents_t
¶A DimensionalExponents_t
node specifies the powers of mass, length, time, temperature, and angular measure which characterize dimensional data in its parent. Although in principle it overrides any DimensionalExponents_t
information higher up in the tree, it is generally not meaningful for it to apply to more than one kind of physical data. Therefore, CGNS specifies its use only as a child of a node which actually contains a single type of real data. There are five values to specify, corresponding to the five types of units specified using DimensionalUnits_t . The data type is real, not integer.
Exponents for three additional types of data are specified in a child node, AdditionalExponents_t .
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
5 
Data: 

Children: 

Cardinality: 
0,1 
AdditionalExponents_t
¶An AdditionalExponents_t
node specifies the powers of the units for additional types of data, which characterize the corresponding dimensional data. There are three values to specify, corresponding to the three types of units specified using AdditionalUnits_t . The data type is real, not integer.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
3 
Data: 

Children: 
None 
Cardinality: 
0,1 
DataArray_t
¶A DataArray_t
node is a very general type of node meant to hold large arrays of data, such as grids and flowfields. Often, some of the attributes of a DataArray_t
node depend on the context in which the node is found; that is, they are structure parameters.
For example, the SIDS specify that the Data Type of DataArray_t
is a structure parameter, “DataType
”, which may assume any of the values “In
”, “Rn
”, or “Cn
”.
The other two attributes of DataArray_t
, Dimensions
and DataSize
, also depend on the context where they are being used. Dimensions
is a function of the underlying dimensionality of the data being described (often IndexDimension
, defined in the CGNSBase_t
node), and the DataSize
may be inferred from detailed descriptions of the grid.
A node may have any number of DataArray_t
children. The meaning of their contents is differentiated by Name, often according to conventions specified by the SIDS. SIDS names are usually precise and descriptive, such as CoordinateTheta
or EnergyInternal
. (See the SIDS for a current list of sanctioned names .) Conversely, quantities not specified by the SIDS can be stored in DataArray_t
nodes, but should be given names other than those specified in the SIDS. In other words, to comply with the SIDS requires that one give a quantity the SIDSdefined name if and only if it is one of the SIDSdefined quantities.
Name: 
Context dependent 

Label: 

DataType: 
Context dependent 
Dimension: 
Context dependent 
Dimension Values: 
Context dependent 
Data: 
The array of data values 
Children: 

Cardinality: 
0, N 
Parameters: 

Integer array nodes perform the same function as nodes of type DataArray_t
, but store integer instead of real arrays. They are always of type int[]
or cgsize_t[]
, with the dimensions and values given either explicitly in the appropriate fields, or as parameters or functions. The cgsize_t
data type is used wherever there is the potential of exceeding the size limit for a 32bit integer (I4
), such as PointList
, PointRange
, and ElementRange
.
Name: 
Context dependent 

Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
1, 
Data: 
The array of integer values 
Cardinality: 
0,1 
Children: 
None 
Parameters: 

GridLocation_t
¶A GridLocation_t
node specifies the physical location, with respect to the underlying grid, with which the field data below its parent is associated. The value (data field) is a character string of enumeration type, i.e., it must take one of a number of predefined values. These values are: Vertex
, CellCenter
, FaceCenter
, IFaceCenter
, JFaceCenter
, KFaceCenter
, or EdgeCenter
. The strings are case sensitive, and an exact match is required. The GridLocation_t
node is optional, and the default is Vertex
.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of the string value 
Data: 

Children: 
None 
Cardinality: 
0,1 
Rind_t
¶The presence of a Rind_t
node indicates that field data stored below its parent includes values associated with a spatial extent beyond that of the basic underlying grid. Such data often arise from the use of ghost cells, or from the copying of information from adjacent zones.
Within a single zone, the size of the basic grid is found in the data field of the Zone_t node . The data field of a Rind_t
node contains integers specifying the number of planes (for structured grids) or number of rind points or elements (for unstructured grids) of included extra data. The planes for structured grids correspond to the low and high values in the i direction, low and high values in the j direction, and low and high values in the k direction (if needed), in that order. Note that the actual size of the field data, which is stored in a DataArray_t
sibling node, is a DataSize
structure parameter which depends on the basic grid size, the GridLocation
, and the Rind
.
The Rind_t
node is optional, and the default is no rind.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 

Data: 
Number of planes of extra data in low i , high i , low j , high j , etc., (for structured grids) or number of points or elements of extra data (for unstructured grids) 
Children: 
None 
Cardinality: 
0,1 
Parameters: 

IndexRange_t
¶An IndexRange_t
node describes a subregion of a zone. This may be, for example, a subblock or a portion of a face of a zone. It may be used to describe the locations of boundary condition patches and holes for overset grids.
Name: 


Label: 

DataType: 

Dimension: 
2 
Dimension Values: 

Data: 
First indices, last indices 
Children: 
None 
Cardinality: 
Context dependent 
Parameters: 

IndexArray_t
¶An IndexArray_t
node describes a general subregion of a zone. Unlike IndexRange_t
, it lists all the elements of the subregion, rather then only the first and last ones. Its use is similar to IndexRange_t
.
Name: 


Label: 

DataType: 

Dimension: 
2 
Dimension Values: 

Data: 
Index coordinates of each point or element in the list, or (for 
Children: 
None 
Cardinality: 
0,1 
Parameters: 

ReferenceState_t
¶The appearance of a ReferenceState_t
node is optional. It is used to specify the values of flow quantities at reference conditions, e.g., at freestream or stagnation. This is typically done for the whole database, in which case the ReferenceState_t
node is a child of the CGNSBase_t
node.
ReferenceState_t
nodes follow the usual convention that information specified lower in the tree overrides higher level specifications. Such overrides are therefore specified if a ReferenceState_t
node appears as a child of a Zone_t
, ZoneBC_t
, or BCDataSet_t
node.
The actual values are stored in one or more DataArray_t
children whose names identify the quantities being stored. If present, the units specified in the DimensionalUnits_t
child apply to all DataArray_t
children, subject to the usual override convention. ( I.e., if one of the DataArray_t
children itself has a DimensionalUnits_t
child, it takes precedence over the higher level specification.)
Name: 


Label: 

DataType: 

Children: 

Cardinality: 
0,1 
ConvergenceHistory_t
¶ConvergenceHistory_t
nodes are intended for the storage of lists of quantities accumulated during calculations associated with either the entire CGNS database or with a single zone.
In the former case, they are called Global convergence histories, and appear as children of the CGNSBase_t
node. In the latter, they are called Local and stored below, with the zones to which they correspond.
Each ConvergenceHistory_t
node is a parent of a collection of onedimensional DataArray_t
nodes, each of which contains a list of values of a quantity defined by the user. These quantities are differentiated by their userassigned Names. User definitions of the names are recorded in a Descriptor_t
child node with Name NormDefinitions
. Children of types DataClass_t
and DimensionalUnits_t
modify the meaning of the DataArray_t
children in the usual manner.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
1 
Data: 
Number of iterations 
Children: 

Cardinality: 
0,1 
IntegralData_t
¶IntegralData_t
nodes are intended for the storage of integrated flow quantities such as mass flows, forces and moments. These are kept in DataArray_t
children just as in the ConvergenceHistory_t
nodes, except that these nodes hold only one real number each.
Name: 
User defined 

Label: 

DataType: 

Children: 

Cardinality: 
0, N 
UserDefinedData_t
¶UserDefinedData_t
nodes are intended as a means of storing arbitrary userdefined data in Descriptor_t
and DataArray_t
children without the restrictions or implicit meanings imposed on these node types at other node locations.
Multiple Descriptor_t
and DataArray_t
children may be stored below a UserDefinedData_t
node, and the DataArray_t
children may be of any dimension and size.
Name: 
User defined 

Label: 

DataType: 

Children: 

Cardinality: 
0, N 
Gravity_t
¶An optional Gravity_t
node may be used to define the gravitational vector.
Name: 


Label: 

DataType: 

Children: 
See Gravity_t figure 
Cardinality: 
0,1 
In this section we describe nodes whose use is specialized to certain types of CFDrelated data. Although these nodes may appear in multiple places in a CGNS DataBase, they play a single role in the description of the data.
CGNS recognizes the notion of a collection of subdomains called zones, within each of which there is a single structured or unstructured grid. Mathematically, the grid is an assignment of a location in physical space to each element in a discrete computational space. An essential feature of the grid is the connection structure it inherits from the underlying computational space.
It is possible, given a grid, to create others from it, by translation to cell centers, for example. However, CGNS views these as new field structures associated with the original grid, and the File Mapping specifies that they be stored as FlowSolution_t or DiscreteData_t nodes .
GridCoordinates_t
¶A GridCoordinates_t
node describes a grid associated with a single zone. For a structured zone, the connection structure of the underlying computational space is that of a rectangular array, and its dimension is the IndexDimension
, that is, the number of integers required to identify a point in the grid. The physical dimension is the number of real coordinates assigned at each grid point and need not be the same. Thus CGNS can store a grid, for example, with IndexDimension
equal to two and a physical dimension of three, that is, a structured grid on a curved surface.
IndexDimension
is a zone dependent parameter. For an unstructured grid, it always equals one, meaning that a unique index is required to specified a node location. For a structured grid, IndexDimension
varries with the CellDimension
of the mesh. For a mesh composed of 3D cells, IndexDimension
equals 3, while for a mesh composed of surface or shell elements, IndexDimension
equals 2. The values of the physical coordinates of the grid points are stored in DataArray_t
children of GridCoordinates_t
. The names of the coordinates are stored in the Name field of the corresponding DataArray_t
node. For common coordinate systems, i.e., Cartesian, polar, cylindrical, and spherical, the names are specified by the SIDS.
Unlike FlowSolution_t and DiscreteData_t nodes , GridCoordinates_t
nodes are not permitted to have GridLocation_t
children, because all grid points are at vertices by definition.
Coordinate arrays may also contain rind data. If they do, the GridCoordinates_t
node must have a Rind_t
child node describing the amount of rind. All DataArray_t
nodes under GridCoordinates_t
must have the same size. Because the number of field quantities to be stored depends on the number of rind, the actual dimension values are functions, specified in this document by the generic term DataSize[]
.
Under each node of type Zone_t
, the original grid is contained in a node named GridCoordinates
. Additional GridCoordinates_t
data structures are allowed, with userdefined names, to store the grid at multiple time steps or iterations.
Name: 


Label: 

DataType: 

Dimension: 
2 
Dimension Values: 

Data: 

Children: 

Cardinality: 
0, N 
Parameters: 

Functions: 

Elements_t
¶The Elements_t
data structure is required for unstructured zones, and contains the element connectivity data, the element type, the element range, the parent elements data, and the number of boundary elements.
Name: 
User defined 

Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
2 
Data: 

Children: 

Cardinality: 
0, N 
Axisymmetry_t
¶The Axisymmetry_t
data structure may be included as a child of the CGNSBase_t
node to record the axis of rotation and the angle of rotation around this axis for an axisymmetric database.
Name: 


Label: 

DataType: 

Children: 

Cardinality: 
0,1 
RotatingCoordinates_t
¶The RotatingCoordinates_t
data structure may be included as a child of either the CGNSBase_t
node or a Zone_t
node to record the center of rotation and the rotation rate vector for a rotating coordinate system.
Name: 


Label: 

DataType: 

Children: 

Cardinality: 
0,1 
The object of computational field physics is to compute fields of physical data associated with points in space.
FlowSolution_t
¶A FlowSolution_t
node describes a field of physical data associated with the grid for a single zone. It is intended for the storage of computed flowfield data such as densities and pressures. There is no convention as to how many or what kind of quantities must or may be stored. In particular, it is not specified that the quantities need in any sense be either complete or nonredundant.
The data are stored in DataArray_t
children of FlowSolution_t
. These DataArray_t
nodes are dimensioned by the same underlying IndexDimension
parameter as the grid, and the order of storage within the DataArray_t
nodes is presumed the same as it is for the grid. The names of the physical quantities are stored in the Name field of the corresponding DataArray_t
node. For common fluid dynamic quantities the names are specified by the SIDS .
The relationship between the locations of the field quantities and the vertices of the grid is specified by a GridLocation_t
child node. If this node is absent, the field quantities are assumed to be associated with the grid vertices. Field arrays may also contain rind data. If they do, the FlowSolution_t
node must have a Rind_t
child node describing the amount of rind. All DataArray_t
nodes under a single FlowSolution_t
must have the same size. Field arrays containing different numbers of rind must be stored under different FlowSolution_t
nodes. There may be any number of nodes of type FlowSolution_t
under a Zone_t
.
Because the number of field quantities to be stored depends on the number of rind and on the location with respect to the grid, the actual dimension values are functions, specified in this document by the generic term DataSize[]
.
The meaning of the field arrays is modified in the usual way by any DataClass_t
or DimensionalUnits_t
children of the FlowSolution_t
node.
Name: 
User defined 

Label: 

DataType: 

Children: 

Cardinality: 
0, N 
Parameters: 

Functions: 

DiscreteData_t
¶DiscreteData_t
nodes are identical to FlowSolution_t
nodes, but are intended for the storage of fields of real data not usually identified as part of the field solution, such as cellcentered grids.
Name: 
User defined 

Label: 

DataType: 

Children: 

Cardinality: 
0, N 
Parameters: 

Functions: 

ZoneSubRegion_t
¶The ZoneSubRegion_t
node allows for the ability to give flowfield or other information over a subset of the entire zone in a CGNS file. This subset may be over a portion of a boundary, or it may be over a portion of the entire field.
Name: 
User defined 

Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
1 
Data: 
RegionCellDimension 
Children: 

Cardinality: 
0, N 
Parameters: 

Functions: 

Transform
Node¶The Transform
node is a node of type int[]
which is identified by its name rather than its label. Thus the name must be “Transform
“. It appears only as a child of a node of type GridConnectivity1to1_t
.
This node stores the transformation matrix relating the indices of two adjacent zones. Its data field contains a list of IndexDimension
signed integers, each within the range [IndexDimension, ..., +IndexDimension]
, and no two of which have the same absolute value. Thus in 3D allowed components are \(0\), \(\pm 1\), \(\pm 2\), and \(\pm 3\).
Each component of the array shows the image in the adjacent zone of a positive index increment in the current zone. The SIDS contain complete details.
Name: 


Label: 
“ 
DataType: 

Dimension: 
1 
Dimension Values: 

Data: 
Transformation matrix (shorthand) 
Children: 
None 
Cardinality: 
0,1 
Parameters: 

GridConnectivityType_t
¶The purpose of this node is to describe the type of zonetozone connectivity specified by its parent, which is always a GridConnectivity_t
node. The connectivity type is given in the data field as a character string which may take one of three specific values: Abutting
, Abutting1to1
, or Overset
.
There is a shorthand form of the GridConnectivity_t
node, namely, GridConnectivity1to1_t
, which incorporates the assumption that the connection is Abutting1to1
. Nodes of type GridConnectivity1to1_t
do not have GridConnectivityType_t
subnodes. However, GridConnectivity1to1_t
nodes can only be used to specify zonetozone connections on rectangular subregions between two structured zones. So the use of GridConnectivityType_t
subnodes to specify Abutting1to1
is required if the connecting regions are not rectangular, or if the connectivity involves a least one unstructured zone.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 
None 
Cardinality: 
0,1 
GridConnectivity1to1_t
¶This node is a shorthand format of GridConnectivity_t
capable of describing only Abutting1to1
connections between two structured zones. The underlying subregion must have rectangular data structure.
Each GridConnectivity1to1_t
node describes a subregion of a face of a zone whose vertices are coincident in a 1to1 fashion with those of a corresponding subregion of a face of another zone. Each ZoneGridConnectivity_t
node may have as many GridConnectivity1to1_t
(or GridConnectivity_t
) children as are required to describe the connection structure.
The location of the connected subregion of a face of the current zone is given in a single child of type IndexRange_t
, whose name is specified by the mapping as “PointRange
“. The location of the corresponding subregion on a face of the other zone is given in a single child of type IndexRange_t
, whose name is specified by the mapping as “PointRangeDonor
“. The first (i.e., beginning) points in these IndexRange_t
nodes are presumed to be coincident. The specification of the correspondence is completed by the inclusion of a Transform
child node which describes the relative orientation of the two systems of indices. The second (i.e., end) point of the PointRange
subnode specifies the extant of the connection.
In general, the File Mapping seeks to avoid the storage of redundant data. However, there are two redundancies associated with GridConnectivity1to1_t
. First, for the sake of symmetry, the information recorded here is duplicated (in reverse) in a corresponding node under the donor zone. It is expected that these two specifications will agree.
Second, the end point of the PointRangeDonor
can be calculated from the other three points specified, along with the transform. However, the transform cannot be inferred from the four points. Therefore, the end point of the PointRangeDonor
is considered to be redundant, and the three points and the transform are designated as the primary specification.
Name: 
User defined 

Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0, N 
Parameters: 

GridConnectivity_t
¶The GridConnectivity_t
node is the most general format for describing grid connectivity. It can describe onetoone, mismatched, and overset connectivity, and the underlying subregions of the connecting zones need not be rectangular.
Each GridConnectivity_t
node describes a subregion of a zone which corresponds to a subregion of another zone. Each ZoneGridConnectivity_t
node may have as many GridConnectivity_t
(or GridConnectivity1to1_t
) children as are required to describe the connection structure.
The location of the connected subregion of the current zone is given in a single child of type either IndexRange_t
or IndexArray_t
, whose name is specified by the mapping as “PointRange
“ or “PointList
“, respectively.
If the grid connectivity is onetoone, the corresponding subregion is defined with a single child of type IndexArray_t
, whose name is specified by the mapping as “PointListDonor
“. Otherwise, the corresponding subregion is defined by two child nodes, one defining the cells and the other the interpolation factors within the cells. See the SIDS for the complete description.
Name: 
User defined 

Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0, N 
Parameters: 

Functions: 

GridConnectivityProperty_t
¶An optional GridConnectivityProperty_t
node may be used to record special properties associated with particular connectivity patches.
Name: 


Label: 

DataType: 

Children: 

Cardinality: 
0,1 
Periodic_t
¶A Periodic_t
node may be used as a child of GridConnectivityProperty_t
to record data associated with a periodic interface.
Name: 


Label: 

DataType: 

Children: 

Cardinality: 
0,1 
AverageInterface_t
¶An AverageInterface_t
node is used as a child of GridConnectivityProperty_t
when data at the current connectivity interface is to be averaged in some way prior to passing it to a neighboring interface.
Name: 


Label: 

DataType: 

Children: 

Cardinality: 
0,1 
OversetHoles_t
¶A node of type OversetHoles_t
describes a region in a grid in which solution values are to be ignored because the data in the region is to be represented by values associated with other “overlapping” zones (equivalent to that specified by IBLANK
= 0 in the PLOT3D format). Each ZoneGridConnectivity_t
node may have as many OversetHoles_t
children as are required to describe the affected region.
Each hole is described either by a single child of type IndexArray_t
or by any number of children of type IndexRange_t
. The latter is provided as a means of specifying holes which are unions of small numbers of logically rectangular subregions. However, if the region is irregular, the intent is that it should be specified by a single child of type IndexArray_t
which lists the points.
Name: 
User defined 

Label: 

DataType: 

Children: 

Cardinality: 
0, N 
Parameters: 

ZoneGridConnectivity_t
¶Each Zone_t
node may have zero or more children of type ZoneGridConnectivity_t
. It holds no data, but serves as the point below which all connectivity data associated with the zone can be found. Multiple ZoneGridConnectivity_t
nodes may be used to specify timedependent changes in the connectivity information.
Name: 


Label: 

DataType: 

Children: 

Cardinality: 
0,N 
Parameters: 

Nodes in this group are used to specify the physical boundary conditions. Each boundary condition is associated with a subregion of a zone. For brevity below, we use the word “domain” to refer to the region on which a boundary condition is to be enforced.
The domain is usually, but not necessarily, a subregion of a face of the zone. The mapping is sufficiently general to permit the description of internal boundary conditions and boundary conditions which do not lie on a constant coordinate plane.
Mathematical boundary conditions are generally applied on subregions of physical dimension one less than the corresponding field problem. This condition, however, is neither defined nor enforced by the File Mapping.
A large number of standard boundary condition types` are named by the SIDS. In addition, it is possible to define new types as collections of Dirichlet and Neumann conditions. It is not possible to describe the entire array of possibilities within this document, and the reader should consult the SIDS for a full description.
InwardNormalIndex
¶An InwardNormalIndex
node is a node of type int[IndexDimension]
which is identified by its Name. It applies to structured grids only, and its function is to specify on which side of the domain the condition is to be enforced.
InwardNormalIndex
may have only one nonzero element, whose sign indicates the computationalcoordinate direction of the boundary condition patch normal; this normal points into the interior of the zone. For example, if the domain lies on the face of a threedimensional zone where the second index is a maximum, the inward normal index values are [0,1,0].
The InwardNormalIndex
node must apply to the entire domain of the boundary condition.
For a boundary condition on a face of a zone, the InwardNormalIndex
can be calculated from other data and need not be specified. Its purpose is to define the normal direction for internal boundary conditions and other cases where the direction is ambiguous.
Name: 


Label: 
“ 
DataType: 

Dimension: 
1 
Dimension Values: 

Data: 
Index of inward normal 
Children: 
None 
Cardinality: 
0,1 
Parameters: 

InwardNormalList
¶An InwardNormalList
node is a node of type IndexArray_t
identified by its Name. Its data field contains an array of physical (real) vectors which point into the region on which the boundary condition is to be applied. It may be used for boundary conditions on complex domains for which InwardNormalIndex
is not defined, or to store vectors orthogonal to the domain of the boundary condition where these are not easily calculated from the domain itself.
Name: 


Label: 

DataType: 

Dimension: 
2 
Dimension Values: 

Data: 
Inward normal vectors 
Children: 
None 
Cardinality: 
0,1 
Parameters: 

BCData_t
¶When global or local Dirichlet or Neumann boundary conditions are defined, a node of type BCData_t
is introduced to store the numerical data. For global data, this consists of a single quantity kept in a DataArray_t
child. For local data, e.g., a pressure profile, it is a vector of quantities stored in an order corresponding to that defining the domain and kept in a child node of type DataArray_t
.
Name: 


Label: 

DataType: 

Children: 
See BCData_t figure 
Cardinality: 
0,1 
Parameters: 

BCDataSet_t
¶The function of a BCDataSet_t
node is to specify the equations to be applied at the boundary, including any actual data values which may be required. The type of the equation is specified by the SIDS and recorded in the data field. For some types, the data is implicit or empty. For others, the data is specified in BCData_t
children.
If the locations at which the boundary conditions are to be applied are specified in BCDataSet_t
, using PointRange
or PointList
, the structure function ListLength
is used. Otherwise, the structure parameter ListLength
is required.
Name: 
User defined 

Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0, N 
Functions: 

Parameters: 

BC_t
¶A BC_t
node specifies a single boundary condition to be applied on a single zone. It specifies the domain on which the condition is to be applied and the equations to be enforced. All the BC_t
nodes for a single zone are found under that zone’s ZoneBC_t
node. A ZoneBC_t
node may have as many BC_t
children as are required to describe the physical boundary conditions on the corresponding zone.
The domain on which the boundary condition is to be enforced is specified by a single node of type either IndexRange_t
or IndexArray_t
. The equations are specified in one or more BCDataSet_t
children.
The type of the boundary condition, which may be either simple or compound, is specified in the data field. For a complete description, it is necessary to consult the SIDS.
Name: 
User defined 

Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 
See BC_t figure 
Cardinality: 
0, N 
Parameters: 

ZoneBC_t
¶The ZoneBC_t
node occurs at most once for each zone and serves as the location under which all boundary conditions on that zone are collected.
Name: 


Label: 

DataType: 

Children: 
See ZoneBC_t figure 
Cardinality: 
0,1 
Parameters: 

BCProperty_t
¶An optional BCProperty_t
node may be used to record special properties associated with particular boundary condition patches.
Name: 


Label: 

DataType: 

Children: 

Cardinality: 
0,1 
WallFunction_t
¶A WallFunction_t
node may be used as a child of BCProperty_t
to record data associated with the use of wall function boundary conditions.
Name: 


Label: 

DataType: 

Children: 

Cardinality: 
0,1 
Area_t
¶An Area_t
node may be used as a child of BCProperty_t
to record data associated with arearelated boundary conditions such as bleed.
Name: 


Label: 

DataType: 

Children: 
See Area_t figure 
Cardinality: 
0,1 
Nodes in this group serve to identify the physical model associated with the data being recorded. Nearly always, the data is of enumeration type and is selected from a collection of terms defined in detail in the SIDS. The names are largely self explanatory, and the detailed definitions will not be repeated here. Numerical values associated with the physical model depend on the type of modeling being chosen and are generally stored in child nodes of type DataArray_t
.
GoverningEquations_t
¶This node names the equation set being solved, for example, FullPotential
or NSTurbulent
. If NavierStokes, the diffusion terms retained may be specified in a DiffusionModel
subnode.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0,1 
Parameters: 

GasModel_t
¶A node of type GasModel_t
names the gas model used, for example, Ideal
or VanderWaals
.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0,1 
ViscosityModel_t
¶A node of type ViscosityModel_t
names the molecular viscosity model used to relate the viscosity to the temperature, for example, PowerLaw
or SutherlandLaw
.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0,1 
EquationDimension
¶A node named EquationDimension
, of type int[]
, gives the number of dependent variables required for a complete solution description, or the number of equations being solved. For example, for NSTurbulent
with the \(k\)\(\epsilon\) turbulence model in three dimensions, it is 7.
Name: 


Label: 
“ 
DataType: 

Dimension: 
1 
Dimension Values: 
1 
Data: 

Children: 
None 
Cardinality: 
0,1 
ThermalConductivityModel_t
¶A node of type ThermalConductivityModel_t
names the model used to relate the thermal conductivity to the temperature, for example, ConstantPrandtl
, PowerLaw
, or SutherlandLaw
. These closely parallel the viscosity model.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0,1 
TurbulenceClosure_t
¶A node of type TurbulenceClosure_t
names the method of closing the Reynolds stress equations when the governing equations are turbulent, for example, EddyViscosity
or ReynoldsStressAlgebraic
.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0,1 
TurbulenceModel_t
¶A node of type TurbulenceModel_t
names the equation set used to model the turbulence quantities, for example, Algebraic_BaldwinLomax
or OneEquation_SpalartAllmaras
.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0,1 
Parameters: 

ThermalRelaxationModel_t
¶A node of type ThermalRelaxationModel_t
names the equation set used to model the thermal relaxation quantities, for example, Frozen
or ThermalEquilib
.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0,1 
ChemicalKineticsModel_t
¶A node of type ChemicalKineticsModel_t
names the equation set used to model the chemical kinetics quantities, for example, Frozen
and ChemicalEquilibCurveFit
.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0,1 
EMElectricFieldModel_t
¶A node of type EMElectricFieldModel_t
names the electric field model used for electromagnetic flows, for example, Constant
or Voltage
.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0,1 
EMMagneticFieldModel_t
¶A node of type EMMagneticFieldModel_t
names the magnetic field model used for electromagnetic flows, for example, Constant
or Interpolated
.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0,1 
EMConductivityModel_t
¶A node of type EMConductivityModel_t
names the conductivity model used for electromagnetic flows, for example, Constant
or Equilibrium_LinRessler
.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0,1 
FlowEquationSet_t
¶A node of type FlowEquationSet_t
appears either at the highest level of the tree (under CGNSBase_t
), to indicate the equation set whose solution is recorded throughout the database, or below a Zone_t
node, to indicate the set of equations solved in that zone. The usual convention applies, i.e., specifications at the local (zone) level override global specifications.
Name: 


Label: 

DataType: 

Children: 

Cardinality: 
0,1 
Parameters: 

Because there is rarely a 1to1 connection between mesh regions and geometric entities, it is often desirable to set geometric associations indirectly in a CGNS file. That is, rather than setting the geometry data for each mesh entity (nodes, edges, and faces), it’s useful to associate them with intermediate objects. The intermediate objects are in turn linked to nodal regions of the computational mesh. This intermediate object is defined as a CFD family .
Each mesh surface may linked to the geometric entities of one or more CAD databases by a userdefined CFD family name. The CFD family corresponds to one or more CAD geometric entities on which the mesh face is projected. Each one of these geometric entities is described in a CAD file and is not redefined within the CGNS file.
Family_t
¶This node, a child of a CGNSBase_t
node or a Family_t
node, contains the definition of a single CFD family. Multiple Family_t
nodes are allowed.
Name: 
User defined 

Label: 

DataType: 

Children: 
See Family_t figure 
Cardinality: 
0, N 
FamilyName_t
¶This node is used to identify a family to which a particular zone or boundary belongs. Note that the name of the family is defined by the “Name” of the Family_t
node, and is stored as data in the FamilyName_t
node.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 
Name of CFD family 
Children: 
None 
Cardinality: 
0,1 
AdditionalFamilyName_t
¶This node is a supplement to the FamilyName_t
node, and is used to identify additional families to which a particular zone or boundary belongs.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 
Name of CFD family 
Children: 
None 
Cardinality: 
0,N 
FamilyBC_t
¶This node contains a boundary condition type for a particular CFD family.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0,1 
FamilyBCDataSet_t
¶A FamilyBCDataSet_t
node contains Dirichlet and Neumann data for a single set of boundary condition equations to be applied to a Family. It’s intended use is for simple boundary condition types, where the equations imposed do not depend on local flow conditions.
Name: 
User defined 

Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0, N 
GeometryReference_t
¶GeometryReference_t
nodes are used to associate a CFD family with one or more CAD databases.
Name: 
User defined 

Label: 

DataType: 

Children: 

Cardinality: 
0, N 
GeometryFile_t
¶This node contains the name of the CAD geometry file.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 
Name of the CAD geometry file 
Children: 
None 
Cardinality: 
1 
GeometryFormat_t
¶This enumeration node defines the format of the CAD geometry file.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 
Name of the CAD geometry format 
Children: 
None 
Cardinality: 
1 
GeometryEntity_t
¶GeometryEntity_t
nodes define the names of the entities in CAD geometry file that make up a CFD family.
Name: 
User defined 

Label: 

DataType: 

Children: 
None 
Cardinality: 
0, N 
Nodes in this section are used for information related to timedependent flows, and include specification of grid motion and storage of timedependent or iterative data.
BaseIterativeData_t
¶Located directly under the CGNSBase_t
node, the BaseIterativeData_t
node contains information about the number of time steps or iterations being recorded, and the time and/or iteration values at each step. In addition, it may include the list of zones and families for each step of the simulation, if these vary throughout the simulation.
Name: 
User defined 

Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
1 
Data: 

Children: 

Cardinality: 
0,1 
ZoneIterativeData_t
¶The ZoneIterativeData_t
node is a child of the Zone_t
node, and is used to store pointers to zonal data for each recorded step of the simulation.
Name: 
User defined 

Label: 

DataType: 

Children: 

Cardinality: 
0,1 
Parameters: 

RigidGridMotion_t
¶RigidGridMotion_t
nodes are used to store data defining rigid translation and/or rotation of the grid coordinates. Multiple RigidGridMotion_t
nodes may be associated with different iterations or time steps in the computation. This association is recorded under the ZoneIterativeData_t
node.
Name: 
User defined 

Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0, N 
ArbitraryGridMotion_t
¶ArbitraryGridMotion_t
nodes are used to store grid velocities for each grid point in a zone (i.e., for deforming grids). Multiple ArbitraryGridMotion_t
nodes may be associated with different iterations or time steps in the computation. This association is recorded under the ZoneIterativeData_t
node.
Note that instantaneous grid coordinates at different iterations or time steps may be recorded using multiple GridCoordinates_t
nodes under a Zone_t
node.
Name: 
User defined 

Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 

Cardinality: 
0, N 
Parameters: 

Functions: 

In this section we describe the highest levels of the hierarchy. Nodes in this section store only quantities which refer to all the entities below them. Therir primary function is to provide organization to the data below.
Zone_t
¶Directly below the highest level node in the database, which is by definition of type CGNSBase_t
, are found nodes of type Zone_t
providing entry into the data specific to each zone. There are as many Zone_t
nodes as there are zones. Their children, in turn, record grid, field, connectivity, and boundary conditions, and a variety of auxiliary data.
Name: 
User defined 

Label: 

DataType: 

Dimension: 
2 
Dimension Values: 

Data: 

Children: 
See Zone_t figure 
Cardinality: 
0, N 
Parameters: 

CGNSBase_t
¶The CGNSBase_t
node is by definition the highest level node in the database, and is located directly below the database root node. It provides entry into all other data. Multiple CGNSBase_t
nodes are allowed in a file. The particular database being accessed is determined by the name of the CGNSBase_t
node.
The only data stored in the node itself are CellDimension
, the dimensionality of a cell in the mesh (i.e., 3 for a volume cell and 2 for a face cell), and PhysicalDimension
, the number of indices required to specify a unique physical location in the field data being recorded. However, a variety of global information concerning the entire database may be stored in children of the CGNSBase_t
node. In particular, a Descriptor_t
node at this level can store user commentary on the entire history of the development of the database.
Other information typically stored directly below the CGNSBase_t
node includes convergence histories, reference states, dimensional units, integrated quantities, and information on the flow equations being solved.
Name: 
User defined 

Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
2 
Data: 

Children: 

Cardinality: 
0, N 
SimulationType_t
¶This enumerationtype node is a child of the CGNSBase_t
node, and specifies whether or not the data below CGNSBase_t
is timeaccurate.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 
None 
Cardinality: 
0,1 
ZoneType_t
¶This enumerationtype node is a required child of the Zone_t
node, and specifies whether the grid in that zone is structured or unstructured.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
Length of string 
Data: 

Children: 
None 
Cardinality: 
1 
CGNSLibraryVersion_t
¶A file containing a CGNS database also contains, directly below the root node, a CGNSLibraryVersion_t
node. This node stores the version number of the CGNS standard with which the file is consistent, and is created automatically when the file is created or modified using the CGNS MidLevel Library . Note that this node is not actually part of the CGNS database, since it is not located below a CGNSBase_t
node.
Note that a file may contain multiple CGNS databases, but there is only one CGNSLibraryVersion_t
node. It is assumed that the version number in the CGNSLibraryVersion_t
node is applicable to all the CGNS databases in the file.
Note also that some CGNS nodes may actually be links to CGNS nodes in other files. In this case, it is assumed that the CGNSLibraryVersion_t
node in the “toplevel” file is applicable to the file(s) containing the linked nodes.
Name: 


Label: 

DataType: 

Dimension: 
1 
Dimension Values: 
1 
Data: 
CGNS version number 
Children: 
None 
Cardinality: 
1 