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.

For example,

 (0 "Variables:")
  (60 (
  (max-skew-limit 1.)
  (max-cell-skew 0.85)
  (skewness-method 0)
  )) 

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

 (1 "ANSYS(R) TGrid(TM) 3D, serial 15.0.0") 

The purpose of this section is to identify the program that wrote the file. Although this section can appear anywhere, it is typically one of the first sections in the file. Additional header sections indicate other programs that may have been used in generating the file. This 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 dimensions.

The nodes section appears as:

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

The following is an example of a two-dimensional 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
  )) 

As 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 also 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.

An example of such a section is as follows:

 (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)) 

When zone-id is zero, it indicates 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 as it serves to alert Fluent that it cannot be used in the solver.

In a declaration section, the type has a value of zero, while the element-type is not present.

For example,

 (12 (0 1 3e3 0)) 

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 fluid (type = 1) or solid (type = 17).

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

In the following example, 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.

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

The face section has a header with the same format as that for cells, but with a section index of 13. The format is as follows:

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

where:

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

A non-zero zone-id indicates a regular face section and will be followed by a body containing information about the grid connectivity. Each line describes one face and appears as follows:

 n0 n1 n2 c0 c1 

where n* are the defining nodes (vertices) of the face, and c* are the adjacent cells.

This is an example of 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.

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 x = number of nodes (vertices) of the face and nf is the final node of the face.

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 boundary mesh, both these values are zero.

bc-type indicates the ID of the boundary condition represented by the face section. The current valid boundary condition types are defined in the following table:

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

face-type indicates the type of faces in the zone as defined in the following table:

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

The edge section has a header of the following format:

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

where:

A zone-id of zero indicates a declaration section with no body, which provides a count of the total number of edges in the mesh. A non-zero zone-id indicates a regular edge section, and will be followed by a body containing information about the grid connectivity. Each line describes one edge and appears as follows:

 v0 v1 

where v0, v1 are the vertices defining the edge.

type denotes the edge type as defined in the following table:

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

face-id0 is the index of the first parent face in the section.

face-id1 is the index of the last parent face in the section.

parent-zone-id is the ID of the zone containing the parent faces

child-zone-id is the ID of the zone containing the children faces.

number-of-kids is the number of children of the parent face.

kid-id-n are the face IDs of the children.

These are in hexadecimal format. You can read files that contain this section in the meshing mode in Fluent.

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. You cannot read files that contain this section in the meshing mode in Fluent.

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 and then read it into the meshing mode of Fluent, this section will be skipped. Hence, all the information necessary to preserve the non-conformal interface will not be maintained. When you switch to the solution mode or read the mesh back into the solution mode, you will need to recreate the interface.