Comment sections can appear anywhere in the file (except within other sections) as:

  (0 "comment text") 

You should precede each long section, or group of related sections, by a comment section explaining what is to follow.

Example:

  (0 "Variables:")
   (37 (
   (relax-mass-flow 1)
   (default-coefficient ())
   (default-method 0)
   )) 

Header sections can appear anywhere in the file (except within other sections). The following is an example:

  (0 "fluent24.2.0 build-id: 0") 

The purpose of this section is to identify the program that wrote the file. Although it can appear anywhere, it is one of the first sections in the file. Additional header sections indicate other programs that may have been used in generating the file. It provides a history mechanism showing where the file came from and how it was processed.

The dimensions of the grid appear as:

  (2 ND) 

where ND is 2 or 3. This section is supported as a check that the grid has the appropriate dimension.

Format:

  (10 (zone-id first-index last-index type ND)(
   x1 y1 z1
   x2 y2 z2
   .
   .
   .
   )) 

The following is an example of a 2D grid:

  (10 (1 1 2d5 1 2)(
   1.500000e-01 2.500000e-02
   1.625000e-01 1.250000e-02
     .
     .
     .
   1.750000e-01 0.000000e+00
   2.000000e-01 2.500000e-02
   1.875000e-01 1.250000e-02
   )) 

Because the grid connectivity is composed of integers representing pointers (see Cells and Faces), using hexadecimal conserves space in the file and provides for faster file input and output. The header indices are in hexadecimal so that they match the indices in the bodies of the grid connectivity sections. The zone-id and type are also in hexadecimal for consistency.

This section indicates the pairings of periodic faces on periodic boundaries. Grids without periodic boundaries do not have sections of this type. The format of the section is as follows:

  (18 (first-index last-index periodic-zone shadow-zone)(
   f00 f01
   f10 f11
   f20 f21
   .
   .
   .
   )) 

where

These are in hexadecimal format. The indices in the section body (f*) refer to the faces on each of the periodic boundaries (in hexadecimal), the indices being offsets into the list of faces for the grid.

Example:

  (18 (1 2b a c) (
   12 1f
   13 21
   ad 1c2
   .
   .
   .
   )) 

The declaration section for cells is similar to that for nodes.

  (12 (zone-id first-index last-index type element-type)) 

Again, zone-id is zero to indicate that it is a declaration of the total number of cells. If last-index is zero, then there are no cells in the grid. This is useful when the file contains only a surface mesh to alert Ansys Fluent that it cannot be used. In a declaration section, the type has a value of zero and the element-type is not present.

For example,

  (12 (0 1 3e3 0)) 

It states that there are 3e3 (hexadecimal) = 995 cells in the grid. This declaration section is required and must precede the regular cell sections.

The element-type in a regular cell section header indicates the type of cells in the section, as follows:

where NN and NF will vary, depending on the specific polyhedral cell.

Regular cell sections have no body, but they have a header of the same format where first-index and last-index indicate the range for the particular zone, type indicates whether the cell zone is an active zone (solid or fluid), or inactive zone (currently only parent cells resulting from hanging node adaption). Active zones are represented with type=1, while inactive zones are represented with type=32.

In the earlier versions of Ansys Fluent, a distinction was made between solid and fluid zones. This is now determined by properties (that is, material type).

A type of zero indicates a dead zone and will be skipped by Ansys Fluent. If a zone is of mixed type (element-type=0), it will have a body that lists the element-type of each cell.

Example:

  (12 (9 1 3d 0 0)(
   1 1 1 3 3 1 1 3 1
   .
   .
   .
   )) 

Here, there are 3D (hexadecimal) = 61 cells in cell zone 9, of which the first 3 are triangles, the next 2 are quadrilaterals, and so on.

The format for face sections is as follows:

  (13 (zone-id first-index last-index bc-type face-type)) 

where

The current valid boundary condition types are defined in the following table:

The faces resulting from the intersection of non-conformal grids are placed in a separate face zone, where a factor of 1000 is added to the bc-type (for example, 1003 is a wall zone).

The current valid face types are defined in the following table:

where NN will vary, depending on the specific polygonal face.

A zone-id of zero indicates a declaration section, which provides a count of the total number of faces in the file. Such a section omits the bc-type and is not followed by a body with further information.

A nonzero zone-id indicates a regular face section, and will be followed by a body that contains information about the grid connectivity. Each line of the body will describe one face and will have the following format:

  n0 n1 n2 c0 c1 

where,

This is the format for a 3D grid with a triangular face format. The actual number of nodes depends on the face-type. The order of the cell indices is important, and is determined by the right-hand rule: if you curl the fingers of your right hand in the order of the nodes, your thumb will point toward c0.

For 2D grids, n2 is omitted. c1 is determined by the cross product of two vectors, and . The vector extends from n0 to n1, whereas the vector has its origin at n0 and points out of the grid plane toward the viewer. If you extend your right hand along and curl your fingers in the direction of the angle between and , your thumb will point along toward c1.

If the face zone is of mixed type (face-type= 0) or of polygonal type (face-type= 5), each line of the section body will begin with a reference to the number of nodes that make up that particular face, and has the following format:

  x n0 n1 ... nf c0 c1 

where,

All cells, faces, and nodes have positive indices. If a face has a cell only on one side, then either c0 or c1 is zero. For files containing only a surface mesh, both these values are zero.

For information on face-node connectivity for various cell types in Ansys Fluent, refer to Face-Node Connectivity in Ansys Fluent.

This section indicates the face hierarchy of the grid containing hanging nodes. The format of the section is as follows:

 (59 (face-id0 face-id1 parent-zone-id child-zone-id)
 (
 number-of-kids kid-id-0 kid-id-1 ... kid-id-n
.
.
.
 )) 

where,

These are in hexadecimal format.

This section indicates the cell hierarchy of the grid containing hanging nodes. The format of the section is as follows:

 (58 (cell-id0 cell-id1 parent-zone-id child-zone-id)
 (
 number-of-kids kid-id-0 kid-id-1 ... kid-id-n
.
.
.
 )) 

where,

These are in hexadecimal format.

This section indicates the relationship between the intersection faces and original faces. The intersection faces (children) are produced from intersecting two non-conformal surfaces (parents) and are some fraction of the original face. Each child will refer to at least one parent. The format of the section is as follows:

 (61 (face-id0 face-id1)
 (
 parent-id-0 parent-id-1
.
.
.
 )) 

where,

These are in hexadecimal format.

If you set up and save a non-conformal mesh in the solution mode of Fluent and then read it using the meshing mode of Fluent, this section will be skipped; consequently, all the information necessary to preserve the non-conformal interface will not be maintained. When you switch to or read the mesh back into the solution mode, you will need to recreate the interface.

There is typically one zone section for each zone referenced by the grid. Although some grid zones may not have corresponding zone sections, there cannot be more than one zone section for each zone.

A zone section has the following form:

  (39 (zone-id zone-type zone-name domain-id)(
  (condition1 . value1)
  (condition2 . value2)
  (condition3 . value3)
  .
  .
  .
   )) 

Grid generators and other preprocessors need only provide the section header and leave the list of conditions empty, as in

  (39 (zone-id zone-type zone-name domain-id)()) 

The empty parentheses at the end are required. The solver adds conditions as appropriate, depending on the zone type. When only zone-id, zone-type, zone-name, and domain-id are specified, the index 45 is preferred for a zone section. However, the index 39 must be used if boundary conditions are present, because any and all remaining information in a section of index 45 after zone-id, zone-type, zone-name, and domain-id will be ignored.

Here the zone-id is in decimal format. This is in contrast to the use of hexadecimal in the grid sections.

The zone-type is one of the following:

   axis
   exhaust fan
   fan
   fluid
   inlet vent
   intake fan
   interface
   interior
   mass-flow-inlet
   mass-flow-outlet
   outlet vent
   outflow
   periodic
   porous-jump
   pressure-far-field
   pressure-inlet
   pressure-outlet
   radiator
   shadow
   solid
   symmetry
   velocity-inlet
   wall 

The interior, fan, porous-jump, and radiator types can be assigned only to zones of faces inside the domain. The interior type is used for the faces within a cell zone; the others are for interior faces that form infinitely thin surfaces within the domain. Ansys Fluent allows the wall type to be assigned to face zones both on the inside and on the boundaries of the domain. Some zone types are valid only for certain types of grid components. For example, cell (element) zones can be assigned only one of the following types:

  fluid
   solid 

All of the other types listed above can be used only for boundary (face) zones.

The zone-name is a user-specified label for the zone. It must be a valid Scheme symbol ^[7] and is written without quotes. The rules for a valid zone-name (Scheme symbol) are as follows:

where a special-initial character is one of the following:

  ! $ % & * / : < = > ? ~ _ ^ 

and a special-subsequent is one of the following:

  . + - 

Examples of valid zone names are inlet-port/cold!—, eggs/easy, and e=m*cˆ2.

Some examples of zone sections produced by grid generators and preprocessors are as follows:

  (39 (1 fluid fuel 1)())
   (39 (8 pressure-inlet pressure-inlet-8 2)())
   (39 (2 wall wing-skin 3)())
   (39 (3 symmetry mid-plane 1)()) 

The domain-id is an integer that appears after the zone name, associating the boundary condition with a particular phase or mixture (sometimes referred to as phase-domains and mixture-domains).

This section indicates each cell’s partition. The format of the section is as follows:

 (40 (zone-id first-index last-index partition-count)(
 p1
 p2
 p3
 .
 .
 .
 pn
 )) 

where,

p1 = the partition of the cell whose ID is first-index

p2 = the partition of the cell whose ID is first-index , and so on

pn = the partition of the cell whose ID is last-index

partition-count = the total number of partitions

Partition IDs must be between 0 and one less than partition-count.

This section indicates the number of cells, faces, and nodes in the grid that corresponds to the data in the file. This information is used to check that the data and grid match. The format is

  (33 (n-elements n-faces n-nodes)) 

where the integers are written in decimal.

This section lists a flow field solution variable for a cell or face zone. The data are stored in the same order as the cells or faces in the legacy case file. Separate sections are written out for each variable for each face or cell zone on which the variable is stored. The format is

  (300 (sub-section-id zone-id size n-time-levels
   n-phases first-id last-id)
   ( data for cell or face with id = first-id
   data-for-cell-or-face with id = first-id+1
   ..
   data-for-cell-or-face with id = last-id
   ))

where sub-section-id is a (decimal) integer that identifies the variable field (for example, 1 for pressure, 2 for velocity). The complete list of these is available in the header file (xfile.h), which is located in your installation area.

where,

zone-id matches the ID used in legacy case file. size is 1 for a scalar, 2 or 3 for a vector, equal to the number of species for variables defined for each species). n-time-levels currently are not used.

A sample legacy data file section for the velocity field in a cell zone for a steady-state, single-phase, 2D problem is shown below:

 (300 (2 16 2 0 0 17 100)
 (8.08462024e-01 8.11823010e-02
  8.78750622e-01 3.15509699e-02
  1.06139672e+00 -3.74040119e-02
 ...
  1.33301604e+00 -5.04243895e-02
  6.21703446e-01 -2.46118382e-02
  4.41687912e-01 -1.27046436e-01
  1.03528820e-01 -1.01711005e-01
  )) 

The variables that are listed in the legacy data file depend on the models active at the time the file is written. Variables that are required by the solver based on the current model settings but are missing from the legacy data file are set to their default values when the legacy data file is read. Any extra variables that are present in the legacy data file but are not relevant according to current model settings are ignored.

This section lists the values of the residuals for a particular data field variable at each iteration:

  (302 (n residual-section-id size domain-id)
  (
  iteration_number unscaled_residual scaling_factor
   .
   .
   .
   )) 

where,

size is 1 for a scalar, 2 or 3 for a vector, equal to the number of species for variables defined for each species. The residual-section-id indicates the equation for which the residual is stored in the section, according to the C constants defined in a header file (xfile.h) available in your installation area, as noted in Grid Sections.

The equations for which residuals are listed in the legacy data file depend on the models active at the time the file is written. If the residual history is missing from the legacy data file for a currently active equation, it is initialized with zeros.