CONTENTS
HOW CGNS HAS BEEN IMPLEMENTED INTO CFL3D:
All of the extra routines required to read and write the CGNS file utilize the "mid-level library" (see http://www.cgns.org). The user is responsible for downloading the CGNS library directly from the CGNS website and installing it appropriately. In the CFL3D code, the parameter "icgns" controls whether CGNS files are used or not.
With CGNS, CFL3D no longer needs to read from or write to a separate restart file. However, the input file has purposefully been kept unchanged (i.e., line 14 of the input file, which specifies the file name of the restart file when CGNS is not used, is read in but ignored when CGNS is employed). For now, CFL3D still gets the BC's and 1-to-1 information from the standard input file. (This information is also put in the CGNS file, although it is not used by CFL3D.) It is assumed that in the future, one may desire to read these items from the CGNS file, and shorten the standard input file. But we have deferred this for now.
Some advantages to the fact that the restart file is a CGNS file
are:
In other words, with CGNS, some day all that user will need is the CGNS file to get anything and everything he/she wants, from restarting to postprocessing. In fact, many commercial postprocessors already support CGNS files. However, CFL3D still prints out the "usual" PLOT3D-type files, in case they are needed, as well as other auxiliary files (like cfl3d.res, cfl3d.out, etc.) that are normally printed out. But, really, EVERYTHING is contained in the CGNS file! This is particularly useful because (a) all flow solution variables and turbulence information is in one file, and (b) if you want to keep track of your solution's progress as it is running, you can use the iwrest parameter to write out the CGNS file (=restart file) periodically and look at it via a postprocessor.
The user is encouraged to obtain the CGNS file viewer "adfviewer" (available from the CGNS website). It is very easy to use and should be self-explanatory.
Note that when CFL3D is run with mesh sequencing, AND IS STOPPED AT A LEVEL LOWER THAN THE FINEST GRID, there is no easy way to handle this with CGNS, since the CGNS file contains the FINE grid only. With "standard" CFL3D, the restart file would contain the coarser grid and solution only. With CGNS, it was decided to write out the coarse-grid FlowSolution ON THE FINE GRID, with data repeated in neighboring cells. Hence, if you plot the solution, it will be identical to the coarse grid solution, only all the fine-grid gridpoints will be used. A node called "Information" under "FlowSolution" says something like: Every-2nd-cell solution (1 level down)
Note that PATCHING and OVERSET information have not yet been included in the CGNS-part of CFL3D. I.e., the CGNS files are purposefully missing this information. The user can still run patched and overset cases with CGNS, but the patched/overset connectivity information (which is created by ronnie/maggie and placed in separate binary files) is never put into the CGNS file itself. This is similar to the "normal" mode of running CFL3D. In the "normal" mode, the user must have available a grid file, restart file, patched-info file, and overset-info file when running with patched/overset. With CGNS, the user must have available a CGNS file, patched-info file, and overset-info file.
Also, the "IMOVIE" option currently writes out multiple-time flowfield information to the plot3d file only, and not to the CGNS file. Similarly, when using iteravg to compute a running long-time-average of the solution, this is currently only written to the plot3d files cfl3d_avgg.p3d and cfl3d_avgq.p3d, and not to the CGNS file.
Also note that when using a CGNS grid file, NGRID (whose sign usually determines whether a grid of type CFL3D or PLOT3D is being read) in the CFL3D input file can be either + or -; i.e., its sign is irrelevant.
Finally, CFL3D currently writes out solution information to the CGNS file both at CELL CENTERS as well as within one rind cell at all boundaries. This is necessary in the long-term so that plotting packages will be able to extract correct BOUNDARY data (e.g., velocity=0 on solid surfaces) from the CGNS file. However, note that at the current time the BCs are not updated immediately prior to writing out the CGNS file, so the rind cells are "behind" by one iteration; this can mean "imperfect" matching at interfaces or slightly non-zero velocities on solid surfaces when plotting from the CGNS file, particularly if the solution is far from convergence.
You can download the actual CGNS file used to obtain the above screen shots here: ExampleN4412cgns.tar.gz... gzipped tar file (1.6 MB). This file was created using CGNS Version 2.4 software, with ADF method of data storage (HDF-5 method is also an available option).
plot3dg_to_cgns.F............program to convert a "standard" grid
file to a CGNS grid file (also needs
to read CFL3D input file in order to
capture BC and 1-to-1 connectivity info)
cgns_to_cfl3dinput.F.........program to read an existing CGNS file
and create a first-guess skeleton CFL3D
input file with most of the needed
relevant information in it
cgns_readhist.F..............program to read an existing CGNS file
and write out its convergence history
information to a separate formatted file
WHAT DIFFERENCE DOES CGNS MAKE?
Responsible NASA Official:
Christopher Rumsey
Page Curator:
Christopher Rumsey
Last Updated: 03/29/2013