Review report of NCLASS module by Jon Kinsey: Summary Recommendation: this code is in good shape and should be approved by the committee. Details are presented in the form and checklist, below. National Transport Code Modules Library Standards Form and Checklist. --------------------------------------------------------------------- Fill in the blank areas with comments on the code, relating to the indicated NTC modules library code standard or goal... ============================================================================= Space is provided here for general comments. ----------------------------------------------------------------------------- NCLASS is a Fortran-77 code but uses namelists and open statements according to Fortran-90 standards. It is a single precision code developed and tested by W. Houlberg using Microsoft Fortran Powerstation 4.0 and Compaq Visual Fortran 6.1. The reviewer finds that the code runs correctly on all workstation brands tested: DEC, SGI, SUN, IBM, HP, and Linux (Pentium II w/ Portland Group). The output agreed to within four digit accuracy on all the platforms tested. The makefile was rewritten using the 'Lehigh standard' format and is organized so that extension to another architecture should be straightforward. Users making makefile changes should communicate these back to the authors, so that these may be posted in a new release to the NTCC website. ============================================================================= ** GENERAL STANDARDS ** ============================================================================= Standard: Provide source code for each physics module or code. ----------------------------------------------------------------------------- done. ============================================================================= Standard: Provide test case(s) with driver program(s) with input and output data and their documentation. ----------------------------------------------------------------------------- done. ============================================================================= Standard: Provide script to compile and link (e.g., makefile). The script should make at least some provision for portability to multiple brands of UNIX (at minimum). Provide clear documentation (possibly in the README file) on how to use the script or makefile. ----------------------------------------------------------------------------- done. ============================================================================= Standard: Provide a README file giving (a) the name of the module and its authors, (b) the location and form of general module documentation, and (c) information (or pointer to more detailed documentation) enabling a user to build binaries from the source code. ----------------------------------------------------------------------------- done. Module includes a README file in HTML format. ============================================================================= Standard: Provide documentation about how the module should be used, for example, whether the module needs to be initialized or used sequentially. Important usability issues, such as the existence of state information in COMMON or other static memory, which persists between calls, must be described. ----------------------------------------------------------------------------- done. ============================================================================= Standard: Eliminate graphics calls embedded in physics modules. ----------------------------------------------------------------------------- done. ============================================================================= Standard: The source code files (e.g. *.f, *.c, or *.cpp files) should be submitted rather than requiring extraction from another file. ----------------------------------------------------------------------------- done. ============================================================================= Standard: Authors may upgrade their modules with approval of the current chairperson of the NTCC modules committee. If the upgrade is extensive, the chairperson can require that the upgrade be subject to a full review. ----------------------------------------------------------------------------- OK ============================================================================= Goal: Multi-platform portability (code should run on different computers). ----------------------------------------------------------------------------- multiple brands of UNIX. W. Houlberg warns that some old F77 compilers may complain about the F90 OPEN statements contained in the code, but no problems have yet been reported. ============================================================================= Goal: Provide error checking (but not stops). ----------------------------------------------------------------------------- iflag return argument ============================================================================= Goal: Portability (code should run in different environments, e.g. different operating systems). ----------------------------------------------------------------------------- only UNIX is confirmed. ============================================================================= Goal: Minimize external dependencies that cost money (i.e. avoid using expensive proprietary licenses). ----------------------------------------------------------------------------- no external dependencies. ============================================================================= Standard: Supply warnings in the documentation when the above goal has not been met. ----------------------------------------------------------------------------- OK ============================================================================= Goal: Arrays should be dynamically allocated. ----------------------------------------------------------------------------- no, this is a Fortran-77 code using parameter statements for static dimensioning. There are no large internal arrays. ============================================================================= Standard: The characteristics of I/O should be clearly documented (i.e. the implementation of I/O unit numbers, if any). ----------------------------------------------------------------------------- done. The I/O is handled through the driver routine with the unit numbers described in the documentation. ============================================================================= Goal: Avoid using hard-wired I/O unit numbers. Allow informational output to be switched on or off. Provide a method for rerouting warning or error message output to a user specified file or I/O unit number. ----------------------------------------------------------------------------- done. Unit numbers are hard-wired, but only in driver routine. ============================================================================= ============================================================================= ** DOCUMENTATION STANDARDS ** ============================================================================= Standard: Provide name of contact person for support. ----------------------------------------------------------------------------- done. ============================================================================= Standard: Provide date of last revision. ----------------------------------------------------------------------------- in the HTML file nclass_pt_info.html ============================================================================= Standard: Provide at least comments describing module or code, citations to publications (if any), and range of validity. ----------------------------------------------------------------------------- done. ============================================================================= Standard: Specify the precision of floating point calculations. ----------------------------------------------------------------------------- done: single precision using the f77 compiler (Note: reviewer did not test on any Cray machines). ============================================================================= Standard: Provide the index of input-output variables for each module (include type of variable, dimension, units). ----------------------------------------------------------------------------- done. ============================================================================= Standard: List dependencies -- names of external routines called. ----------------------------------------------------------------------------- no external dependencies -- matrix operation routines are included in the distribution. ============================================================================= Standard: Provide statement of known bugs. ----------------------------------------------------------------------------- no known bugs. ============================================================================= Goal: Index of modules, routines, variables. ----------------------------------------------------------------------------- just input & output arguments -- but the code is well commented, including .html file description with mathematical notation. ============================================================================= Goal: Publication of code or module in journal (such as Computer Physics Communications). ----------------------------------------------------------------------------- W.A. Houlberg, K.C. Shaing, S.P. Hirshman, M.C. Zarnstorff, Phys. Plasmas 4 (1997) 3230 ============================================================================= Goal: Online hyper-text reference documentation. ----------------------------------------------------------------------------- all documentation is in HTML format. ============================================================================= Goal: Interactive online help menus. ----------------------------------------------------------------------------- HTML documentation files are included in the module. ============================================================================= ============================================================================= **DATA STANDARDS** ============================================================================= ============================================================================= Goal: Provide interface routines to data. ----------------------------------------------------------------------------- N.A.: no data interface other than calling arguments. ============================================================================= Goal: Use self-describing data files (such as NetCDF). ----------------------------------------------------------------------------- no file i/o other than ascii driver routine output. ============================================================================= Goal: Use public domain, portable, available and well-documented data file formats. ----------------------------------------------------------------------------- N.A. ============================================================================= Goal: Establish standards for variable names, units, dimensions independent variables and grid descriptions as they appear in the module interfaces. ----------------------------------------------------------------------------- Naming conventions are in place for the various groups of subroutines and for variable prefixes and suffixes. The conventions are described in the "Naming Conventions" section in the HTML file, nclass_pt_info.html. =============================================================================y) *************************************************** General Atomics 13-308a P.O. Box 85608 San Diego, CA 92186-9784 Ph: (858) 455-3336 Fax: (858) 455-3586 "Research is what I'm doing when I don't know what I'm doing. " -- Wernher von Braun ***************************************************