A CGNS database describes the current state of one or more entire CFD (Computational Fluid Dynamics) problems, including the following:
Not all of these data need to be present at any particular time. The overall view is that of a shared database that can be accessed by the various software tools common to CFD, such as solvers, grid generators, field visualizers, and postprocessors. Each of these "applications" serves as an editor of the data, adding to, modifying, or interpreting it according to that application's specific role.
CGNS conventions and software provide for the recording of a complete and flexible problem description. The exact meaning of a subsonic inflow boundary condition, for example, can be described in complete detail if desired. User comments can be included nearly anywhere, affording the opportunity, for instance, for date stamping or history information to be included. Dimension and sizing information is carefully defined. Any number of flow variables may be recorded, with or without standard names, and it is also possible to add user-defined or site-specific data. These features afford the opportunity for applications to perform extensive error checking if desired.
Because of this generality, CGNS provides for the recording of much more descriptive information than current applications normally use. However, the provisions for this data are layered so that much of it is optional. It should be practical to convert most current applications to CGNS with little or no conceptual change, retaining the option to take advantage of more detailed descriptions as that becomes desirable.
CGNS specifications currently cover the bulk of CFD data that one might wish to exchange among sites or applications; for instance, nearly any type of field data can be recorded, and, based on its name, found and understood by any code that needs it. Global data (e.g., freestream Mach number, Reynolds number, angle of attack) and physical modeling instructions (e.g., thin layer assumptions, turbulence model) may be specified. Nevertheless, there are items specific to individual applications for which there is currently no specification within CGNS. Most commonly, these are operational instructions, such as number of sweeps, solution method, multigrid directives, and so on. Owing to the miscellaneous nature of this data, there has been no attempt to codify it within a global standard. It is therefore expected that many applications will continue to require small user-generated input files, presumably in ASCII format.
CGNS itself does not initiate action or undertake any function normally handled by the operating system. The user still performs CFD tasks according to existing processes. This includes selecting the computing platform, maintaining the files, and launching the applications.
However, the ease of communication between applications that CGNS provides should motivate the development of new batch and interactive mechanisms for the convenient application of CFD tools.