This section describes structure types intended primarily for timedependent flows. Data structures are presented for storing timedependent or iterative data, and for recording rigid and arbitary grid motion. The section concludes with several examples.
In order to keep a record of time dependent or iterative data, the data structures BaseIterativeData_t and ZoneIterativeData_t are used.
BaseIterativeData_t
¶The BaseIterativeData_t
data structure is located directly under the CGNSBase_t
node.
It 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.
The BaseIterativeData_t
data structure is defined as follows:
BaseIterativeData_t :=
{
int NumberOfSteps (r)
DataArray_t<real, 1, NumberOfSteps> TimeValues ; (o/r)
DataArray_t<int, 1, NumberOfSteps> IterationValues ; (r/o)
DataArray_t<int, 1, NumberOfSteps> NumberOfZones ; (o)
DataArray_t<int, 1, NumberOfSteps> NumberOfFamilies ; (o)
DataArray_t<char, 3, [65, MaxNumberOfZones, NumberOfSteps]>
ZonePointers ; (o)
DataArray_t<char, 3, [65, MaxNumberOfFamilies, NumberOfSteps]>
FamilyPointers ; (o)
List( DataArray_t<> DataArray1 ... DataArrayN ) ; (o)
List( Descriptor_t Descriptor1 ... DescriptorN ) ; (o)
DataClass_t DataClass ; (o)
DimensionalUnits_t DimensionalUnits ; (o)
List( UserDefinedData_t UserDefinedData1 ... UserDefinedDataN ) ; (o)
}
Note
Default names for the DataArray_t
, 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 BaseIterativeData_t
and shall not include the names DataClass
, DimensionalUnits
, FamilyPointers
, IterationValues
, NumberOfFamilies
, NumberOfZones
, TimeValues
, or ZonePointers
.
NumberOfSteps
is a required element of the BaseIterativeData_t
data structure. It holds either the number of time steps or the number of iterations being recorded.
TimeValues
or IterationValues
must be defined. If both are used, there must be a onetoone correspondence between them.
TimeValues
and IterationValues
are dataname identifiers corresponding to the time and iteration values stored in the file. When IterationValues
are used, the iterative data stored in the database correspond to values at the end of the associated iteration.
The dataname identifiers NumberOfZones
and ZonePointers
are only used if different zone data structures apply to different steps of the simulation. (See the Adapted Unstructured Mesh example.)
Similarly, if the geometry varies with time or iteration, then the dataname identifiers NumberOfFamilies
and FamilyPointers
are used to record which Family_t
data structure(s) correspond(s) to which step.
The DataArray_t
nodes for ZonePointers
and FamilyPointers
are defined as threedimensional arrays. For each recorded step, the names of all zones and families being used for the step may be recorded. Note that the names are limited to 65 characters; this is the maximum size of a name of a zone from another base: 32 chars + ‘/’ + 32 chars. Only one ‘/’ character is allowed, then the first token before the ‘/’ is the CGNSBase name and the second token is the Zone or Family name. If no ‘/’ is found, the name is a Zone or a Family name of the current CGNS Base. The variables MaxNumberOfZones
and MaxNumberOfFamilies
represent the maximum number of zones and families that apply to one step. So if NumberOfSteps
= 5 and NumberOfZones
= {2,2,3,4,3}, then MaxNumberOfZones
equals 4.
When NumberOfZones
and NumberOfFamilies
vary for different stored time steps, the name Null
is used in ZonePointers
and FamilyPointers
as appropriate for steps in which the NumberOfZones
or NumberOfFamilies
is less than the MaxNumberOfZones
or MaxNumberOfFamilies
.
Any number of extra DataArray_t
nodes are allowed. These should be used to record data not covered by this specification.
ZoneIterativeData_t
¶The ZoneIterativeData_t
data structure is located under the Zone_t
node. It may be used to record pointers to zonal data for each recorded step of the simulation, and is defined as follows:
ZoneIterativeData_t< int NumberOfSteps > :=
{
DataArray_t<char, 2, [32, NumberOfSteps]>
RigidGridMotionPointers ; (o)
DataArray_t<char, 2, [32, NumberOfSteps]>
ArbitraryGridMotionPointers ; (o)
DataArray_t<char, 2, [32, NumberOfSteps]>
GridCoordinatesPointers ; (o)
DataArray_t<char, 2, [32, NumberOfSteps]>
FlowSolutionPointers ; (o)
DataArray_t<char, 2, [32, NumberOfSteps]>
ZoneGridConnectivityPointers ; (o)
DataArray_t<char, 2, [32, NumberOfSteps]>
ZoneSubRegionPointers ; (o)
List( DataArray_t<> DataArray1 ... DataArrayN ) ; (o)
List( Descriptor_t Descriptor1 ... DescriptorN ) ; (o)
DataClass_t DataClass ; (o)
DimensionalUnits_t DimensionalUnits ; (o)
List( UserDefinedData_t UserDefinedData1 ... UserDefinedDataN ) ; (o)
}
Note
Default names for the DataArray_t
, 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 ZoneIterativeData_t
and shall not include the names ArbitraryGridMotionPointers
, DataClass
, DimensionalUnits
, FlowSolutionPointers
, GridCoordinatesPointers
, RigidGridMotionPointers
, ZoneGridConnectivityPointers
, or ZoneSubRegionPointers
.
The data arrays with dataname identifiers xxxPointers
contain lists of associated data structures for each recorded time value or iteration. These data structures contain data at the associated time value, or at the end of the associated iteration. There is an implied onetoone correspondence between each pointer (from 1, 2, …, NumberOfSteps
) and the associated TimeValues
and/or IterationValues
under BaseIterativeData_t
. They refer by name to data structures within the current zone. The name Null
is used when a particular time or iteration does not have a corresponding data structure to point to.
Any number of extra DataArray_t
nodes are allowed. These should be used to record data not covered by this specification.
The ZoneIterativeData_t
data structure may not exist without the BaseIterativeData_t
under the CGNSBase_t
node. However BaseIterativeData_t
may exist without ZoneIterativeData_t
.
RigidGridMotion_t
¶Adding rigid grid motion information to the CGNS file enables an application code to determine the mesh location without the need to alter the original mesh definition recorded under GridCoordinates_t
. A data structure named RigidGridMotion_t
is used to record the necessary data defining a rigid translation and/or rotation of the grid coordinates.
The rigid grid motion is recorded independently for each zone of the CGNS base. Therefore the RigidGridMotion_t
data structure is located under the zone data structure (Zone_t
). There may be zero to several RigidGridMotion_t
nodes under a Zone_t
node. The multiple rigid grid motion definitions may be associated with different iterations or time steps in the computation. This association is recorded under the ZoneIterativeData_t
data structure.
RigidGridMotion_t :=
{
List( Descriptor_t Descriptor1 ... DescriptorN ) ; (o)
RigidGridMotionType_t RigidGridMotionType ; (r)
DataArray_t<real, 2, [PhysicalDimension, 2]> OriginLocation ; (r)
DataArray_t<real, 1, PhysicalDimension> RigidRotationAngle ; (o/d)
DataArray_t<real, 1, PhysicalDimension> RigidVelocity ; (o)
DataArray_t<real, 1, PhysicalDimension> RigidRotationRate ; (o)
List( DataArray_t DataArray1 ... DataArrayN ) ; (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 RigidGridMotion_t
and shall not include the names DataClass
, DimensionalUnits
, OriginLocation
, RigidGridMotionType
, RigidRotationAngle
, RigidRotationRate
, or RigidVelocity
.
RigidGridMotionType
and OriginLocation
are the only required elements under RigidGridMotion_t
. All other elements are optional.
RigidGridMotionType_t
is an enumeration type that describes the type of rigid grid motion.
RigidGridMotionType_t := Enumeration(
RigidGridMotionTypeNull,
RigidGridMotionTypeUserDefined,
ConstantRate,
VariableRate ) ;
The characteristics of the grid motion are defined by the following dataname identifiers:
DataName Identifier 
Description 
Units 


Physical coordinates of the origin before and after the rigid grid motion 
\(L\) 

Rotation angles about each axis of the translated coordinate system.
If rotating about more than one axis, the rotation is performed first about the xaxis,
then the yaxis, then the zaxis. If not specified, 
\(\alpha\) 

Grid velocity vector of the origin translation 
\(L/T\) 

Rotation rate vector about the axis of the translated coordinate system 
\(\alpha/T\) 
Any number of DataArray_t
nodes are allowed. These may be used to record data not covered by this specification.
“Rigid grid motion” implies relative motion of grid zones. However, no attempt is made in the RigidGridMotion_t
data structure to require that the ZoneGridConnectivity_t
information be updated to be consistent with the new grid locations.
Whether the ZoneGridConnectivity_t
information refers to the original connectivity (of GridCoordinates
) or the latest connectivity (of the moved or deformed grid) is currently left up to the user.
ArbitraryGridMotion_t
¶When a grid is in motion, it is often necessary to account for the position of each grid point as the grid deforms.
When all grid points move at the same velocity, the grid keeps its original shape. This particular case of grid motion may be recorded under the RigidGridMotion_t
data structure.
On the other hand, if the grid points have different velocity, the grid is deforming. The ArbitraryGridMotion_t
data structure allows the CGNS file to contain information about arbitrary grid deformations.
If not present, the grid is assumed to be rigid.
Note that multiple GridCoordinates_t
nodes may be stored under a Zone_t
.
This allows the storage of the instantaneous grid locations at different time steps or iterations.
The arbitrary grid motion is recorded independently for each zone of the CGNS base.
Therefore the ArbitraryGridMotion_t
data structure is located under the zone data structure (Zone_t
).
There may be zero to several ArbitraryGridMotion_t
nodes under a single Zone_t
node.
The multiple arbitrary grid motion definitions may be associated with different iterations or time steps in the computation.
This association is recorded under the ZoneIterativeData_t
data structure.
ArbitraryGridMotion_t< int IndexDimension, int VertexSize[IndexDimension],
int CellSize[IndexDimension] > :=
{
ArbitraryGridMotionType_t ArbitraryGridMotionType ; (r)
List(DataArray_t<real, IndexDimension, DataSize[]>
GridVelocityX GridVelocityY ... ) ; (o)
List( Descriptor_t Descriptor1 ... DescriptorN ) ; (o)
GridLocation_t GridLocation ; (o/d)
Rind_t<IndexDimension> Rind ; (o/d)
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 ArbitraryGridMotion_t
and shall not include the names ArbitraryGridMotionType
, DataClass
, DimensionalUnits
, GridLocation
, or Rind
.
The only required element of the ArbitraryGridMotion_t
data structure is the ArbitraryGridMotionType
. Thus, even if a deforming grid application does not require the storage of grid velocity data, the ArbitraryGridMotion_t
node must exist (with ArbitraryGridMotionType = DeformingGrid
) to indicate that deformed grid points (GridCoordinates_t
) exist for this zone.
Rind
is an optional field that indicates the number of rind planes (for structured grids) or rind points or elements (for unstructured grids) included in the grid velocity data.
The GridLocation
specifies the location of the velocity data with respect to the grid; if absent, the data is assumed to coincide with grid vertices (i.e., GridLocation = Vertex).
ArbitraryGridMotion_t
requires three structure parameters; IndexDimension
identifies the dimensionality of the gridsize arrays, and VertexSize
and CellSize
are the number of core vertices and cells, respectively, in each index direction, excluding rind points.
For structured zones, core vertices and cells begin at [1,1,1]
(in 3D) and end at VertexSize
and CellSize
, respectively.
For unstructured zones, IndexDimension
is always 1.
ArbitraryGridMotionType_t
is an enumeration type that describes the type of arbitrary grid motion.
ArbitraryGridMotionType_t := Enumeration(
ArbitraryGridMotionTypeNull,
ArbitraryGridMotionTypeUserDefined,
NonDeformingGrid,
DeformingGrid ) ;
The DataArray_t
nodes are used to store the components of the grid velocity vector.
The table below lists the dataname identifiers used to record these vectors in Cartesian, cylindrical, and spherical coordinate systems.
DataName Identifier 
Description 
Units 


\(x\)component of grid velocity 
\(L/T\) 

\(y\)component of grid velocity 
\(L/T\) 

\(z\)component of grid velocity 
\(L/T\) 

\(r\)component of grid velocity 
\(L/T\) 

\(\theta\)component of grid velocity 
\(\alpha/T\) 

\(\phi\)component of grid velocity 
\(\alpha/T\) 

\(\xi\)component of grid velocity 
\(L/T\) 

\(\eta\)component of grid velocity 
\(L/T\) 

\(\zeta\)component of grid velocity 
\(L/T\) 
The field GridLocation
specifies the location of the grid velocities with respect to the grid; if absent, the grid velocities are assumed to coincide with grid vertices (i.e., GridLocation = Vertex). All grid velocities within a given instance of ArbitraryGridMotion_t
must reside at the same grid location.
Rind
is an optional field that indicates the number of rind planes (for structured grids) or rind points or elements (for unstructured grids) included in the data. Its purpose and function are identical to those described for the GridCoordinates_t
structure.
Note, however, that the Rind in this structure is independent of the Rind
contained in GridCoordinates_t
or FlowSolution_t
.
They are not required to contain the same number of rind planes or elements. Also, the location of any rind points is assumed to be consistent with the location of the core data points (e.g., if GridLocation = CellCenter
, rind points are assumed to be located at fictitious cell centers).
DataClass
defines the default for the class of data contained in the DataArray_t
entities. For dimensional grid velocities, 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.
Pointbypoint grid velocity implies a deformation (or potentially only motion) of the grid points relative to each other. Because the original grid coordinates definition remains unchanged with the name GridCoordinates
, any deformed coordinates must be written with a different name (e.g., MovedGrid#1
or another useddefined name) and are pointed to using GridCoordinatesPointers
in the data structure ZoneIterativeData_t
.
Pointbypoint grid velocity may also lead to relative motion of grid zones, or movement of grid along abutting interfaces.
However, no attempt is made here to require that the ZoneGridConnectivity_t
information be updated to be consistent with the new grid locations.
Whether the ZoneGridConnectivity_t
information refers to the original connectivity (of GridCoordinates
) or the latest connectivity (of the moved or deformed grid) is currently left up to the user.
onedimensional int
array of length IndexDimension
IndexDimension
, VertexSize[]
, CellSize[]
, GridLocation
, Rind
The function DataSize[]
is the size of the DataArrays containing the grid velocity components. It is identical to the function DataSize[]
defined for FlowSolution_t
.
Multiple ZoneGridConnectivity_t
nodes may be used to specify timedependent changes in the connectivity information associated with the zone.
The time variation is the recorded in the ZoneIterativeData_t
node as ZoneGridConnectivityPointers
.
In this example, the whole mesh moves rigidly, so the only timedependent data are the grid coordinates and flow solutions.
However, since the mesh moves rigidly, the grid coordinates need not be recorded at each time step.
Instead, a RigidGridMotion_t
data structure is recorded for each step of the computation.
The number of steps and time values for each step are recorded under BaseIterativeData_t
.
CGNSBase_t {
BaseIterativeData_t {
NumberOfSteps = N ;
TimeValues = time1, time2, ..., timeN ;
} ;
} ;
The multiple rigid grid motion and flow solution data structures are recorded under the zone. RigidGridMotionPointers
and FlowSolutionPointers
keep the lists of which RigidGridMotion_t
and FlowSolution_t
nodes correspond to each time step.
Zone_t Zone {
 Time independent data
GridCoordinates_t GridCoordinates
ZoneBC_t ZoneBC
ZoneGridConnectivity_t ZoneGridConnectivity
 Time dependent data
RigidGridMotion_t RigidGridMotion#1
RigidGridMotion_t RigidGridMotion#2
...
RigidGridMotion_t RigidGridmotion#N
FlowSolution_t Solution#0
FlowSolution_t Solution#1
FlowSolution_t Solution#2
...
FlowSolution_t Solution#N
ZoneIterativeData_t {
RigidGridMotionPointers = {"RigidGridMotion#1", "RigidGridMotion#2", ...,
"RigidGridMotion#N"}
FlowSolutionPointers = {"Solution#1", "Solution#2", ..., "Solution#N"}
}
}
Note that there may be more solutions under a zone than those pointed to by FlowSolutionPointers
. In this example, Solution#0
could correspond to a restart solution.
In this example, velocity vectors are node dependent allowing for mesh deformation. In such a case, it is difficult or even impossible to recompute the mesh at each time step. Therefore the grid coordinates are recorded for each step.
Multiple GridCoordinates_t
and FlowSolution_t
data structures are recorded under the zone.
In addition, the data structure ArbitraryGridMotion_t
is recorded for each step.
GridCoordinatesPointers
, FlowSolutionPointers
, and ArbitraryGridMotionPointers_t
keep the list of which grid coordinates definition, flow solution, and arbitrary grid motion definition correspond to each time step.
Zone_t Zone {
 Time independent data
ZoneBC_t ZoneBC
ZoneGridConnectivity_t ZoneGridConnectivity
 Time dependent data
List ( GridCoordinates_t GridCoordinates MovedGrid#1 MovedGrid#2 ...
MovedGrid#N )
List ( FlowSolution_t Solution#0 Solution#1 Solution#2 ... Solution#N )
List ( ArbitraryGridMotion_t ArbitraryGridMotion#1
ArbitraryGridMotion#2 ... ArbitraryGridMotion#N )
ZoneIterativeData_t {
GridCoordinatesPointers = {"MovedGrid#1", "MovedGrid#2", ...,
"MovedGrid#N"}
FlowSolutionPointers = {"Solution#1", "Solution#2", ..., "Solution#N"}
ArbitraryGridMotionPointers = {"ArbitraryGridMotion#1",
"ArbitraryGridMotion#2", ..., "ArbitraryGridMotion#N"}
}
}
In this example, the mesh size varies at each remeshing, therefore new zones must be created. ZonePointers
is used to keep a record of the zone definition corresponding to each recorded step.
Let’s assume that the solution is recorded every 50 iterations, and the grid is adapted every 100 iterations.
The number of steps, iteration values for each step, number of zones for each step, and name of these zones are recorded under BaseIterativeData_t
.
CGNSBase_t {
BaseIterativeData_t {
NumberOfSteps = 4
IterationValues = {50, 100, 150, 200}
NumberOfZones = {1, 1, 1, 1}
ZonePointers = {"Zone1", "Zone1", "Zone2", "Zone2"}
}
}
Each zone holds 2 solutions recorded at 50 iterations apart. Therefore the ZoneIterativeData_t
data structure must be included to keep track of the FlowSolutionPointers
.
Zone_t Zone1 {
 Constant data
GridCoordinates_t GridCoordinates
Elements_t Elements
ZoneBC_t ZoneBC
 Variable data
List ( FlowSolution_t InitialSolution Solution50 Solution100 )
ZoneIterativeData_t {
FlowSolutionPointers = {"Solution50", "Solution100", "Null", "Null"}
}
}
Zone_t Zone2 {
 Constant data
GridCoordinates_t GridCoordinates
Elements_t Elements
ZoneBC_t ZoneBC
 Variable data
List ( FlowSolution_t RestartSolution Solution150 Solution200 )
ZoneIterativeData_t {
FlowSolutionPointers = {"Null", "Null", "Solution150", "Solution200"}
}
}
Note
If the solution was recorded every 100 iterations instead of every 50 iterations, then each zone would have only one FlowSolution_t
node and the data structure ZoneIterativeData_t
would not be required.
Note that FlowSolutionPointers
is always an array of size NumberOfSteps
even if some of the steps are defined in another zone.
The following is an example demonstrating the use of the rigid grid motion, arbitrary grid motion, and timeaccurate data nodes in CGNS. The example is a 3zone case. Zone 1 is rigidly rotating about the xaxis at a constant rate, with no translation. Zone 2 is a deforming zone. Zone 3 is a fixed zone. This is a timeaccurate simulation with two solutions saved at times 15.5 and 31.0, corresponding to iteration numbers 1000 and 2000.
No units are given in this example, but a real case would establish them. Also, a real case would include connectivity, boundary conditions, and possibly other information as well. Each indentation represents a level down (a child) from the parent node.
Base (CGNSBase_t)
SimulationType (SimulationType_t) Data=TimeAccurate
BaseIterativeData (BaseIterativeData_t) Data=NumberOfSteps=2
TimeValues (DataArray_t) Data=(15.5, 31.0)
IterationValues (DataArray_t) Data=(1000, 2000)
Zone#1 (Zone_t)
GridCoordinates (GridCoordinates_t)
CoordinateX (DataArray_t)
CoordinateY (DataArray_t)
RigidGridMotion#1(RigidGridMotion_t) Data=RigidGridMotionType=ConstantRate
OriginLocation (DataArray_t) Data=(0,0,0), (0,0,0)
RigidRotationAngle (DataArray_t) Data=(5., 0., 0.)
RigidGridMotion#2(RigidGridMotion_t) Data=RigidGridMotionType=ConstantRate
OriginLocation (DataArray_t) Data=(0,0,0), (0,0,0)
RigidRotationAngle (DataArray_t) Data=(10., 0., 0.)
ZoneIterativeData (ZoneIterativeData_t)
RigidGridMotionPointers (DataArray_t) Data=(RigidGridMotion#1,
RigidGridMotion#2)
FlowSolutionPointers (DataArray_t) Data=(Soln#1, Soln#2)
Soln#1 (FlowSolution_t)
Density (DataArray_t)
VelocityX (DataArray_t)
Soln#2 (FlowSolution_t)
Density (DataArray_t)
VelocityX (DataArray_t)
Zone#2 (Zone_t)
GridCoordinates (GridCoordinates_t)
CoordinateX (DataArray_t)
CoordinateY (DataArray_t)
MovedGrid#1 (GridCoordinates_t)
CoordinateX (DataArray_t)
CoordinateY (DataArray_t)
MovedGrid#2 (GridCoordinates_t)
CoordinateX (DataArray_t)
CoordinateY (DataArray_t)
ArbitraryGridMotion#1 (ArbitraryGridMotion_t)
Data=ArbitraryGridMotionType=DeformingGrid
ArbitraryGridMotion#2 (ArbitraryGridMotion_t)
Data=ArbitraryGridMotionType=DeformingGrid
GridVelocityX (DataArray_t)
GridVelocityY (DataArray_t)
ZoneIterativeData (ZoneIterativeData_t)
ArbitraryGridMotionPointers (DataArray_t) Data=("ArbitraryGridMotion#1",
"ArbitraryGridMotion#2")
GridCoordinatesPointers (DataArray_t) Data=("MovedGrid#1",
"MovedGrid#2")
FlowSolutionPointers (DataArray_t) Data=("Soln#1", "Soln#2")
Soln#1 (FlowSolution_t)
Density (DataArray_t)
VelocityX (DataArray_t)
Soln#2 (FlowSolution_t)
Density (DataArray_t)
VelocityX (DataArray_t)
Zone#3 (Zone_t)
GridCoordinates (GridCoordinates_t)
CoordinateX (DataArray_t)
CoordinateY (DataArray_t)
ZoneIterativeData (ZoneIterativeData_t)
FlowSolutionPointers (DataArray_t) Data=("Soln#1", "Soln#2")
Soln#1 (FlowSolution_t)
Density (DataArray_t)
VelocityX (DataArray_t)
Soln#2 (FlowSolution_t)
Density (DataArray_t)
VelocityX (DataArray_t)
Note
Under BaseIterativeData_t
, one can give either TimeValues
, or IterationValues
, or both. In the example, both have been given.
The nodes NumberOfZones
and ZonePointers
are not required under the BaseIterativeData_t
node in this example because all existing zones are used for each time step.
Under ArbitraryGridMotion
, the GridVelocity
data is optional. In the example, it was put under one of the nodes but not under the other. Hence, “ArbitraryGridMotion#1
” in the example has no children nodes, while “ArbitraryGridMotion#2
” does.
The pointers under ZoneIterativeData_t
point to names of nodes within the same zone. Thus, for example, Soln#1
refers to the flow solution named Soln#1
in the same zone, even though there are flow solution nodes in other zones with the same name.
The name GridCoordinates
always refers to the original grid. Thus, when a grid is deforming, the deformed values must be put in GridCoordinates_t
nodes of a different name. In the example, the deformed grids (for Zone#2
) at the two times of interest were put into “MovedGrid#1
” and “MovedGrid#2
”.
Because the node “ArbitraryGridMotion#1
” doesn’t really add any information in the current example (since it was decided not to store GridVelocity
data under it), one has the option of not including this node in the CGNS file. If it is removed, then under Zone#2
’s ZoneIterativeData
, the ArbitraryGridMotionPointers
data would be replaced by:
Data = (Null, ArbitraryGridMotion#2)