CGNS (CFD General Notation System) — CAE Glossary

CGNS stands for "CFD General Notation System," a format for standardly storing CFD data. Its content is based on HDF5, a binary format, so it is fundamentally different from text files. Even with large-scale meshes containing millions of cells, data can be handled efficiently, and read/write operations are extremely fast.

That was exactly the problem. In the 1990s CFD industry, each solver saved in its own format, making the routine workflow—creating a mesh with mesher A, passing it to solver B, and visualizing results in post-processing tool C—extremely tedious. NASA and Boeing led the effort to create a "format independent of any single solver," which is how CGNS began.

That's correct—you cannot open it with a text editor. However, with specialized GUI tools like cgnsview or HDFView, you can graphically browse the tree structure. With Python, you can read and write using pyCGNS or h5py, making automated processing via scripts easy. For example, you can retrieve a node list like this:

Good question. CGNS can directly utilize HDF5's parallel I/O capabilities (MPI-IO). This means that even when distributed computing uses thousands of processes, each process can simultaneously write to its assigned region of a single CGNS file. Without this, you would have to aggregate all data on rank 0 before writing, causing memory and time to explode exponentially. For billion-cell-scale analyses, parallel CGNS is virtually mandatory.

It has a tree structure where each node stores a "name," "label (type)," and "data." Roughly speaking, the hierarchy looks like this:

Yes, they are. For structured grids, specifying the IJK size in Zone_t (e.g., 129×65×33) implicitly determines element connectivity, so Elements_t is not required. Conversely, for unstructured grids, Elements_t must explicitly store the vertex connectivity list for all elements. In practice, unstructured grids are far more common, so familiarity with handling Elements_t is essential. For mixed elements (tetrahedra + prisms, etc.), connectivity is stored by separating sections by element type.

That is CGNS's greatest advantage. For example, when creating a mesh with Pointwise or ICEM CFD and passing it to different solvers like ANSYS Fluent, OpenFOAM, FUN3D, or elsA, CGNS minimizes conversion effort. Since you can carry not just the mesh but also boundary conditions and solution data together, smooth handoff to post-processing tools (ParaView, Tecplot) is also achievable.

To be honest, it's not entirely seamless. The CGNS specification (SIDS: Standard Interface Data Structures) is quite broad, and the range supported by each solver can differ subtly. For example, one solver might write a special boundary condition type as a custom extension node, which another solver simply ignores. However, mesh coordinates and fundamental flow field data (pressure, velocity, temperature) have very high compatibility, so 80-90% of cases work without issues.

Yes, it does. Within FlowSolution_t, there is a GridLocation_t node that specifies either Vertex (nodes) or CellCenter (cell centers). Finite element-based solvers typically use node values, while finite volume-based solvers like Fluent, OpenFOAM, and FUN3D naturally work with cell-center values. Failing to check which representation is used can cause value shifts in post-processing, so be careful.

Yes, you can. There are nodes called BaseIterativeData_t and ZoneIterativeData_t that manage pointers to solution data for each time step. You can store all time steps in a single CGNS file or split them into separate files per step. In practice, for thousands of steps in unsteady LES, a single file can reach hundreds of GB, so splitting by step or saving sampled data is more realistic.

The aerospace industry is the most prolific user. At NASA and AIAA-related workshops, benchmark test cases are routinely distributed in CGNS format as a standard. In turbomachinery, CGNS facilitates data exchange between elsA, TURBO, and CFX. Recently, CGNS adoption has grown in automotive CFD, and many people use the Python meshio library to inter-convert between CGNS, STL, and VTK.

OpenFOAM has standard conversion utilities like ccm26ToFoam or cgnsToFoam (availability varies by version). The Foundation version may not have them, but the ESI (OpenCFD) version often includes CGNS support. Even without built-in support, you can write a Python script using pyCGNS to read the mesh and convert it to OpenFOAM's polyMesh format. Conversely, exporting OpenFOAM results to CGNS and visualizing with Tecplot is also a common workflow.

First, install cgnsview and browse a sample CGNS file. The tree structure becomes visually intuitive. Next, read the official CGNS documentation (SIDS), focusing on just three sections: GridCoordinates_t, Elements_t, and FlowSolution_t—that covers 80% of practical use. If you want to read and write in Python, install pyCGNS with pip install pyCGNS and experiment with a small mesh. That's the fastest path to proficiency.