WIND User's Guide - Keyword Reference, CGNSBASE

(WIND Documentation Home Page) (WIND User's Guide) (GMAN User's Guide) (MADCAP User's Guide) (CFPOST User's Guide) (WIND Utilities) (Common File User's Guide) (WIND Installation Guide) (WIND Developer's Reference) (Guidelines Documents)

(Introduction) (Tutorial) (Geometry and Flow Physics Modeling) (Numerical Modeling) (Boundary Conditions) (Convergence Monitoring) (Files) (Scripts) (Parallel Processing) (Keyword Reference) (Test Options)

CGNSBASE - Use CGNS files

CGNSBASE basename

This keyword specifies that the grid and flow data are obtained from, and written to, CGNS (CFD General Notation System) files, not common files. The user-specified basename is the name of the CGNSBase_t node in the grid and flow files. [Detailed information on the CGNS standard may be found at the CGNS web site external link .]

It should be noted that, strictly speaking, there is no notion of a CGNS file, only of a CGNS database implemented within one or more ADF (Advanced Data Format) files. We nevertheless use the terminology "CGNS file" in the WIND documentation. In addition, a true CGNS database has a single CGNSBase_t node as its root. In the current WIND implementation, however, the grid and flow solution are stored in separate files, with both files having their own CGNSBase_t node with the same basename.

If the CGNSBASE keyword is not used, the grid and flow data are assumed to be in common files.

WIND supports the most common CGNS features, but not all. Some specific limitations on the implementation of CGNS in the WIND code are listed below.

Many WIND input options may be specified on a zonal basis, using the zone number to identify the zone. In the CGNS standard, zones are identified by a name. When CGNS files are used in WIND, it is assumed that the zone number maps to the zone's position in an alphanumerically sorted list of zone names.

Note that the naming convention Zonen, where n is the zone number, is alphanumeric only up to Zone9. Zone10 through Zone19 would get sorted between Zone1 and Zone2, and so on. However, spaces are allowed in names, so "Zone n", with two spaces, (e.g., Zone 1, Zone 2, ..., Zone 99, Zone100, ...) is alphanumeric up to Zone999.
The CGNS default names "GridCoordinates" and "FlowSolution" are used for the CGNS GridCoordinates_t and FlowSolution_t nodes. For each zone, only one grid and one flow solution are stored.
In a CGNS database, the scaling data must be stored with the data itself, but the units to be used may be stored with the data or higher in the node tree. The WIND implementation assumes that the units are stored with the data.
If grid velocities are stored in the grid file, it is assumed that the units are ft/sec.
The CGNS nodes for storing time-dependent data are not yet supported in WIND.
For overlapping grids, CGNS allows hole points to be identified using multiple OversetHoles_t nodes. WIND currently assumes that all hole points in a zone are identified in a single OversetHoles_t node, using a PointList.
WIND writes convergence and time history information to the list output (.lis) and time history (.cth) files, respectively, not to a CGNS file.

There are also some WIND features and capabilities that are not supported by the current CGNS standard. These include chemistry and MFD flows, specified boundary layer transition, and bleed boundary conditions. Several proposals are pending to extend the CGNS standard, but for now CGNS files created by WIND for these types of flows may not be fully CGNS compliant, and should be considered unique to the WIND implementation.