Fri Apr 7 17:14:47 US/Eastern 2000
Author:
Jon Kinsey
General Atomics
San Diego, CA, 92186
Phone: [858]455-3336
E-mail: kinsey@gav.gat.com
Title: Kapisn neoclassical transport module
Module: Kapisn
URL of tar/zip file: ftp://ftp.pppl.gov/incoming/kapisn.tar.gz
Abstract: The KAPISN module computes neoclassical thermal transport from several models including the Rutherford, modified Hazeltine-Hinton, Bolton, Chang-Hinton (1982) and modified Chang-Hinton (1986) models. Each model computes the ion thermal conductivity at a single grid point whereby the electron thermal conductivity is computed externally in the driver routine assuming it to be equal to the square root of the mass ratio times the ion thermal conductivity. Inside the q=1 surface, it is assumed that the ion and electron thermal conductivities are equal. This module was used extensively in the MLT shooting code at General Atomics during the ITER model testing exercise using the modified Hinton-Hazeltine prescription.
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 portabilit to multiple brands of UNIX (at minimum). Provide clear documentation (possibly in the README file) on how to use the script or makefile. |
Done. A makefile is included with the module. | |
Standard: | Provide a README file giving (a) the name of the module andits authors, (b) the location and form of general module documentation, and (c) information (or pointer to more detailed documentation) enabling a user to build binariesfrom the source code. |
Done. | |
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. |
A latex file, with embedded Fortran coding, is included. | |
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. |
Done. | |
Goal: | Offer single and double precision versions or offer user control of precision at compile time |
Double precison only. | |
Goal: | Provide error checking (but not stops). |
None. | |
Goal: | Portability (code should run on multiple platforms and under different operating systems |
Module has been tested on HP-UX, IBM RS/6000, DEC alpha, and Linux workstations. | |
Goal: | Minimize external dependencies that cost money (i.e. avoid using expensive proprietary licenses). |
Done. | |
Standard: | Supply warnings in the documentation when the above goal has not been met. |
OK. | |
Goal: | Arrays should be dynamically allocated. |
All arrays are statically dimensioned. | |
Standard: | The characteristics of I/O should be clearly documented(i.e. the implementation of I/O unit numbers, if any). |
Done. Described in README file. | |
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. |
I/O numbers are currently hardwired with all I/O in driver routine. | |
Standard: | Provide name of contact person for support. |
---|---|
Done. | |
Standard: | Provide date of last revision |
4/7/00 | |
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. Double precision. | |
Standard: | Provide the index of input-output variables for each module (include type of variable, dimension, units). |
Done. | |
Standard: | Provide statement of known bugs. |
No known bugs. | |
Goal: | Index of modules, routines, variables. |
List of all files comprising module given in README file. | |
Goal: | Publication of code or module in journal (such as Computer Physics Communications) |
No reference for module, but references for relevant physics is included in the documentation. | |
Goal: | Online hyper-text reference documentation |
None. | |
Goal: | Interactive online help menus |
None. | |
Standard: | Provide interface routines to data. |
---|---|
N.A. | |
Goal: | Use self-describing data files (such as NetCDF). |
ASCII 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 appearin the module interfaces. |
N.A. | |