NASA Logo, National Aeronautics and Space Administration
[Home] [Archive] [Resources] [History] [Contacts]

NPARC Alliance CFD Verification and Validation Documentation Guidelines


Last Updated: Wednesday, 10-Feb-2021 10:13:52 EST

This document provides some guidelines on the documentation of the validation cases. The objective is consistency in the reporting of validation results. Further the guidelines will allow a comparison of conclusions drawn from a variety of studies.

The following guidelines are intended for all validation cases; however, the level of detail of information may vary according to whether the case is an example, verification, or validation case. The proper level of detail will be indicated below.

An example requires more of a step-by-step instruction on the procedure for performing an analysis. At a minimum this requires brief descriptions of problem and a single common grid (*.cgd) file and an input data (*.dat) file for showing users how to run with a certain feature of the WIND code.

A verification case requires a description of the problem along with information on the computation procedures, computer system, list files, convergence histories, and some flow properties. The intent is to be able to determine if WIND continues to give consistent or improved results after being installed on a new system or modified.

A validation case requires complete documentation to examine the performance and accuracy of WIND. This includes examination of the sensitivity to variations in the grid density, turbulence models, and other input parameters.

Documentation Format

The desired format for the documentation is HTML documents for posting on the Archive. If someone is running a case, but is not familiar with HTML, they may write an ASCII text file. The webmaster will then create the HTML document. See the File Naming Conventions for information on naming the document files.

Documentation Guidelines

The structure of the documentation guideline is to follow closely the Validation Process. The following are sections that should be included in the document.

  1. Title

    2. At the top of the document should be a short, but descriptive title.

  2. Orienting Image

    3. An image of the grid and / or flow field is useful for orienting the reader as to the general nature of the validation case. For display on the Web, use the JPEG (*.jpg) or GIF (*.gif) graphics file formats.

  3. Problem Description

    4. This should be one to two brief paragraphs describing the scope of the flow conditions, geometry, computational features, and flow properties examined in this test case. If a table is appropriate, then include it. Indicate the basis (analytical, computational, experimental) for the comparison of the computed results. Cite references if the validation case is based on reported work.

  4. Download tar File

    Include a link to a compresses tar file that contains all of the files in the archive for the validation case that can be downloaded. See the File Naming Conventions for information on naming the compressed tar file.

  5. Geometry Model

    The details on the definition of the flow domain and boundary geometry should be included. Enough information should be provided so that a reader may reconstruct the flow domain. For simple geometries, a description may be adequate. A figure may be helpful. For complex geometries a link to a file of coordinates or CAD file (IGES file) or references to original documents could be included.

  6. Grid Topology, Spacing, and Density

    7. This section discusses the grid topology used for the case and includes the number and types of blocks (H-block, O-block, Chimera, abutting, etc...). The size of the grid in each block should be listed, preferably in tabular form. Grid generation and quality parameters, such as wall spacing and stretching ratio should be reported. Comment on how the grid was generated with respects to the grid generation package. If a Fortran code was written to generate the grid, perhaps the source code can be linked as part of the validation case. If so, indicate the values of any inputs. For viscous flows, comment on how the wall spacing was determined, preferably with the discussion of the value of y+ for the first grid point off the wall. The common grid (*.cgd) file should be listed as a link. If a series of grids were used as part of a Grid Convergence Study, they should be listed in tabular form. See the File Naming Conventions document on suggestions for nameing files. A figure of the grid and / or parts of it may be helpful for describing the topology, quality, or density. If a PLOT3D grid was converted to a common grid (*.cgd) file, make a link to the CFCNVT command file. See the File Naming Conventions for information on naming this command file.

  7. Initial and Boundary Conditions

    8. This section contains a description of the initial flow field and flow boundary conditions to be imposed with respect to the flow domain. A tabular form is suggested if there is significant information. If a Fortran program was written to create the initial solution, this could be part of the archive and a link established to the source code file. Include links to CFCNVT and GMAN command files. See the File Naming Conventions for information on naming these command files.

  8. Computation Strategy

    9. The computational strategy for obtaining the computed flow field should be described. This includes indicating whether space-marching or time-marching is used and if turbulence or chemistry is modeled. Further such things as the algorithms and acceleration techniques used can be discussed. This section could be included with the next section on the discussion of the input data file. Also to be discussed is the use of distributed processing.

  9. Input Parameters and Files

    10. This section discusses the input parameters used in the input data (*.dat) file. These input parameters generally coorrespond to the desired computational strategy. For an example, one should include more detailed discussion of the inputs for each keyword and choice of input parameters as they relate to the physical problem and/or the operation of the WIND code. If more than one input data file is used, then a tabular form is suggested indicating various values of parameters and why the parameters were varied. Indicate what other files (*.cfl, *.chm, *.mpc) were created for the computations and provide links to access them.

  10. Computation

    11. This section discusses how the computations were performed. The version of WIND used should be indicated. If modifications to the source code were used, these should be indicated. A discussion of the computer system (CPU, number of processors, and operating system) should be included. If distributed processing was used, the multi-processing command (*.mpc) file should be referenced. The output should be written to a list (*.lis) file.
    The convergence properties of the computation for steady-state problems should be discussed along with the manner in which it was determined that it was time to stop the computation. If applicable, plots of the residual history should be included. Indicate if several segments of computation were needed and indicate if any input parameters were changed between each segment. The utility RESPLT can be used to create plot files of the residuals and other information in the list files. Command files with names of the form (resplt.run.#.com) should be written (see the File Naming Convention for information on naming archive files). These files should be made available to explicitly indicate how the residual data was determined. This is especially important for the example cases. If turbulence is modeled using a one or two-equation model, the convergence of the turbulence quantities should be discussed. Comment on other flow properties that were monitored (i.e. mass flow, thrust) as part of evaluating convergence.

  11. Post-Processing

    12. This section discusses post-processing to obtain the flow field properties of interest from the computation. The program CFPOST should be used to obtain information on the flowfield from the common files (*.cgd and *.cfl). Command files with names of the form (cfpost.run.#.com) should be written (see the File Naming Convention for information on naming archive files) and made available to explicitly indicate how the flow field information was obtained. This is especially important for the example cases. Indicate how these flow properties were computed. If CFPOST was used, include links to command files that generated the flow properties and / or displays. If Fortran codes were written for post-processing, then include links to the source and include as part of the archive. Show figures of flow contours to give an overall view of the flow field.

  12. Comparisons of the Results

    13. This section examines the comparison between the computed results and analytical, computational, and / or experimental results. Differences should be noted and reasons for differences should be stated. Include links to files containing analytical, computational, or experimental data. Include plots of comparisons.

  13. Sensitivity Studies

    14. This section discusses the results of sensitivity studies. Foremost, should be a Grid Convergence Study to examine how the solution changes with grid density. The validity of flow properties is resiquite on the condition that grid convergence has been established. The Grid Convergence Index (GCI) Method of Roach should be followed to ensure consistent report of the results of a grid convergence study.
    For viscous, turbulent flow computations, the sensitivity to the choice of turbulence model should be reported. If significant differences exist, one should comment on which turbulence model performs the best for the flow field. If no data exists for forming a basis of the comparison, then one should make a selection based on the historic validity of the turbulence model for other unit problems (i.e. if massive flow separation exists, it is likely that the k-epsilon model probably gives the more correct answer than the Baldwin-Lomax model).

  14. References

    15. Any references cited in the document should be listed. If the reference is already in the Bibliography then a link is sufficient. If a reference should be in the Bibliography, the information can be passed to the Validation Team Coordinators for inclusion.

  15. Log and Contact Information

    16. Information on the person performing the validation case should be included. This should include name, email address (and/or postal address), and phone number. If more than one person was involved in running the case or the case was run at different dates by different people, a log should be created in tabular form indicating which person performed which runs. The sections above can be added to by each successive person with appropriate discussion indicating the uniqueness of the runs.
NASA Logo - nasa.gov