11. Time-Dependent Flow#

This section describes structure types intended primarily for time-dependent flows. Data structures are presented for storing time-dependent or iterative data, and for recording rigid and arbitrary grid motion. The section concludes with several examples.

11.1. Iterative Data Structure Definitions#

In order to keep a record of time dependent or iterative data, the data structures BaseIterativeData_t and ZoneIterativeData_t are used.

11.1.1. Base Iterative Data Structure Definition: `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 one-to-one correspondence between them.

TimeValues and IterationValues are data-name 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 data-name 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 data-name 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 three-dimensional 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.

11.1.2. Zone Iterative Data Structure Definition: `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 data-name 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 one-to-one 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.

11.1.3. Particle Iterative Data Structure Definition: `ParticleIterativeData_t`#

The ParticleIterativeData_t data structure is located under the Particle_t node. It may be used to record pointers to particle data for each recorded step of the simulation, and is defined as follows:

ParticleIterativeData_t< int NumberOfSteps > :=
  {
  DataArray_t<char, 2, [32, NumberOfSteps]>
     ParticleCoordinatesPointers ;                                   (o)
  DataArray_t<char, 2, [32, NumberOfSteps]>
     ParticleSolutionPointers ;                                      (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

The data arrays with data-name 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 one-to-one 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 particle node. 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 ParticleIterativeData_t data structure may not exist without the BaseIterativeData_t under the CGNSBase_t node. However BaseIterativeData_t may exist without ParticleIterativeData_t.

11.2. Rigid Grid Motion Structure Definition: `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 data-name identifiers:

**Data-Name Identifiers for Rigid Grid Motion**#
Data-Name Identifier	Description	Units
`OriginLocation`	Physical coordinates of the origin before and after the rigid grid motion	\(L\)
`RigidRotationAngle`	Rotation angles about each axis of the translated coordinate system. If rotating about more than one axis, the rotation is performed first about the x-axis, then the y-axis, then the z-axis. If not specified, `RigidRotationAngle` is set to zero.	\(\alpha\)
`RigidVelocity`	Grid velocity vector of the origin translation	\(L/T\)
`RigidRotationRate`	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.

11.3. Arbitrary Grid Motion Structure Definition: `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 grid-size 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 3-D) 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 data-name identifiers used to record these vectors in Cartesian, cylindrical, and spherical coordinate systems.

**Data-Name Identifiers for Grid Velocity**#
Data-Name Identifier	Description	Units
`GridVelocityX`	\(x\)-component of grid velocity	\(L/T\)
`GridVelocityY`	\(y\)-component of grid velocity	\(L/T\)
`GridVelocityZ`	\(z\)-component of grid velocity	\(L/T\)
`GridVelocityR`	\(r\)-component of grid velocity	\(L/T\)
`GridVelocityTheta`	\(\theta\)-component of grid velocity	\(\alpha/T\)
`GridVelocityPhi`	\(\phi\)-component of grid velocity	\(\alpha/T\)
`GridVelocityXi`	\(\xi\)-component of grid velocity	\(L/T\)
`GridVelocityEta`	\(\eta\)-component of grid velocity	\(L/T\)
`GridVelocityZeta`	\(\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 user-defined 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.

Point-by-point 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 used-defined name) and are pointed to using GridCoordinatesPointers in the data structure ZoneIterativeData_t.

Point-by-point 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.

FUNCTION DataSize()

Return value:: one-dimensional int array of length IndexDimension
Dependencies:: 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.

11.4. Zone Grid Connectivities#

Multiple ZoneGridConnectivity_t nodes may be used to specify time-dependent changes in the connectivity information associated with the zone. The time variation is the recorded in the ZoneIterativeData_t node as ZoneGridConnectivityPointers.

11.5. Examples for Time-Dependent Flow#

11.5.1. Example - Rigid Grid Motion#

In this example, the whole mesh moves rigidly, so the only time-dependent 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.

11.5.2. Example - Deforming Grid Motion#

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"}
  }
}

11.5.3. Example - Adapted Unstructured Mesh#

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.

11.5.4. Example - Combination of Grid Motion and Time-Accuracy#

The following is an example demonstrating the use of the rigid grid motion, arbitrary grid motion, and time-accurate data nodes in CGNS. The example is a 3-zone case. Zone 1 is rigidly rotating about the x-axis at a constant rate, with no translation. Zone 2 is a deforming zone. Zone 3 is a fixed zone. This is a time-accurate 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)
```

11.5.5. Example - Moving Particles#

In this example, we will show how the ParticleIterativeData_t nodes can be used to provide time-dependent data in a ParticleData_t node.

Multiple ParticleCoordinates_t and ParticleSolution_t data structures are recorded under the particle node. ParticleCoordinatesPointers and ParticleSolutionPointers keep the list of which particle coordinates definition and particle solution definition correspond to each time step.

Particle_t Particles {

  !--- Time dependent data
  List ( ParticleCoordinates_t ParticleCoordinates MovedParticle#1 MovedParticle#2 ...
         MovedParticle#N )
  List ( ParticleSolution_t Solution#0 Solution#1 Solution#2 ... Solution#N )
  ParticleIterativeData_t {
    ParticleCoordinatesPointers = {"MovedParticle#1", "MovedParticle#2", ...,
       "MovedParticle#N"}
    ParticleSolutionPointers = {"Solution#1", "Solution#2", ..., "Solution#N"}
  }
}

Note that there may be more solutions under a particle node than those pointed to by ParticleCoordinatesPointers or ParticleSolutionPointers. In this example, ParticleCoordinates and Solution#0 could correspond to a restart solution.

Time-Dependent Flow

Contents

11. Time-Dependent Flow#

11.1. Iterative Data Structure Definitions#

11.1.1. Base Iterative Data Structure Definition: BaseIterativeData_t#

11.1.2. Zone Iterative Data Structure Definition: ZoneIterativeData_t#

11.1.3. Particle Iterative Data Structure Definition: ParticleIterativeData_t#

11.2. Rigid Grid Motion Structure Definition: RigidGridMotion_t#

11.3. Arbitrary Grid Motion Structure Definition: ArbitraryGridMotion_t#

11.4. Zone Grid Connectivities#

11.5. Examples for Time-Dependent Flow#

11.5.1. Example - Rigid Grid Motion#

11.5.2. Example - Deforming Grid Motion#

11.5.3. Example - Adapted Unstructured Mesh#

11.5.4. Example - Combination of Grid Motion and Time-Accuracy#

11.5.5. Example - Moving Particles#

11.1.1. Base Iterative Data Structure Definition: `BaseIterativeData_t`#

11.1.2. Zone Iterative Data Structure Definition: `ZoneIterativeData_t`#

11.1.3. Particle Iterative Data Structure Definition: `ParticleIterativeData_t`#

11.2. Rigid Grid Motion Structure Definition: `RigidGridMotion_t`#

11.3. Arbitrary Grid Motion Structure Definition: `ArbitraryGridMotion_t`#