Fri Oct 30 17:05:16 US/Eastern 1998
Author:
Doug McCune
Princeton Plasma Physics Lab
Princeton, NJ, o8544
Phone: [609]243-2731
E-mail: transp_support@pppl.gov
Title: Ufiles and related modules
Module: ufiles.tar.gz
FTP Site: ftp.pppl.gov
Abstract: Ufiles are a simple file format standard for the exchange of single precision floating point scientific data. The Ufiles standard has enjoyed and continues to enjoy wide use in the plasma physics / fusion research community. Ufiles software implements the standard; this software was the backbone of diagnostic data analysis on the TFTR tokamak from 1983 to 1997. Ufiles come in four organizations: 0d, 1d, 2d, and 3d. All Ufiles contain a keyword indexed list of scalar values, 0d Ufiles contain only this list; for 1d, 2d, and 3d Ufiles the scalar list can have zero length. 1d Ufiles contain a gridded numeric representation of a 1d function of the form f(x), with numeric data, labeling, and physical units labeling for the function data and the x axis data. 2d Ufiles contain a numeric representation of f(x,y) with similar labeling. 3d Ufiles contain a numeric representation of f(x,y,z), again with similar labeling. A rich set of automatable interactive fortran-77 utility programs are available for the display and manipulation of Ufiles data. Ufiles come in several format variants, including: ascii, network-portable compressed binary, NetCDF, and HDF.
Standard: | Provide source code for each physics module or code. |
| In the tar files | |
Standard: | Provide test case(s) with driver program(s) with input and output data and their documentation. |
| In the tar files | |
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. |
| In the tar files -- code ported to multiple unix workstations but not CRAY | |
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. |
| In u_install.tar | |
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. |
| This is in the documentation. | |
Standard: | Eliminate graphics calls embedded in physics modules. |
| NA: these are not physics modules -- rather, these are i/o and graphics modules. | |
Standard: | The source code files (e.g. *.f, *.c, or *.cpp files) should be submitted rather than requiring extraction from another file. |
| OK | |
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) |
| Several types of workstations , not CRAY as of this time. working VMS versions of the code exist, but, the VMS build system has not been included in the distribution at this time. If users require this they should contact us. | |
Goal: | Provide error checking (but not stops). |
| This is generally adhered to. | |
Goal: | Portability (code should run in different environments, e.g. different operating systems. |
| VMS/UNIX, multiple brands of UNIX (OSF1, SunOS, HP_UX, IRIX64, AIX, Linux). Ufiles loss-free compressed binary format is network portable btw UNIX machines (any endian-ness) and VMS. | |
Goal: | Minimize external dependencies that cost money (i.e. avoid using expensive proprietary licenses). |
| XTCTEK needs Motif, otherwise there are no dependencies that cost money. | |
Standard: | Supply warnings in the documentation when the above goal has not been met. |
| This is in the README and INSTALL files. | |
Goal: | Arrays should be dynamically allocated. |
| Generally not satisfied in this legacy fortran-77 code. | |
Standard: | The characteristics of I/O should be clearly documented(i.e. the implementation of I/O unit numbers, if any). |
| This is 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. |
| As described in the documentation, the user has control of selection of fortran logical unit numbers for i/o operations. | |
Standard: | Provide name of contact person for support. |
| In READMEs and on Web page. | |
Standard: | Provide date of last revision |
| This should go by the date on the tar file. | |
Standard: | Provide at least comments describing module or code,citations to publications (if any), and range of validity. |
| This is given in the documentation. There are no publications. | |
Standard: | Specify the precision of floating point calculations. |
| Generally single precision, as indicated in the module abstracts. | |
Standard: | Provide the index of input-output variables for each module (include type of variable, dimension, units). |
| This is in the documentation. | |
Standard: | Provide statement of known bugs. |
| There are "limitations" in UREAD, which are described in the documentation. | |
Goal: | Index of modules, routines, variables. |
| not available | |
Goal: | ublication of code or module in journal (such as Computer Physics Communications) |
| not done | |
Goal: | Interactive online help menus |
| not done | |
Standard: | Provide interface routines to data. |
| These are interface routines to data | |
Goal: | Use self-describing data files (such as NetCDF). |
| NetCDF and HDF format option available for Ufiles. | |
Goal: | Use public domain, portable, available and well-documented data file formats. |
| Ufiles tries to be all of these things. | |
Goal: | Establish standards for variable names, units, dimensions independent variables and grid descriptions as they appearin the module interfaces. |
| Although the code is thought to be written in a reasonable style, I don't think this goal has been met. But it is not a pressing concern. | |