Portlib Library

***************

John Mandrekas, Ph.D.
Senior Research Scientist
Georgia Institute of Technology
Fusion Research Center
ESM Bldg. 0225
Atlanta, GA 30332-0225

(404) 894-7730
john.mandrekas@me.gatech.edu

Summary Recommendation:
I suggest that this library is approved by the committee.

General Comments:
The PortLib library contains a number of useful routines and functions that
perform certain system tasks. Some of these tasks are very common (e.g. elapsed
CPU time) and can be found in almost every code. While most Fortran compilers
provide access to such routines, the interface is not standard forcing the
developer to re-write part of his/her code and use conditional compilation every
time the code is ported into a new environment.

The PortLib library provides a standardized interface to these routines, greatly
simplifying the porting of codes to new platforms.

I successfully built, tested (using the inlcuded porttest program) and installed
the library on systems running Solaris 7 and HP-UX. I also linked some of my
codes with the PortLib library and it worked fine. In addition, I wrote small
programs to test some of the less common routines included in portlib, and they
worked as expected.

GENERAL STANDARDS

Standard: Provide source code for each physics module or code

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 (possible in the README file) on how to
use the script or Makefile.

Installation script exists and works on various UNIX platforms. Most common UNIX
platforms (including Linux)  are included. Clear documentation is included in
the README file. The GNU version of make (gmake) should be used.

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.

A README file exists with detailed information about the library. In addition,
the source code of most of the routines includes useful comments.

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.

Instructions about how this library should be linked are included in the README
file. Also, a test program (porttest) exists which tests various routines in the
library.

Standard: Eliminate graphics calls embedded in physics modules.
N/A

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)

The library can be used in multiple brands of UNIX and Linux.

Goal: Provide error checking (but not stops).

Some error checking exists.

Goal: Portability (code should run in different environments, e.g., different
operating systems).

Only UNIX (including LINUX)  is confirmed.

Goal: Minimize external dependencies that cost money (i.e., avoid using
expensive proprietary licenses).

Only gmake is required, which is freely available. The FPRERPOC scripts (which
have already been approved and are included in the NTCC site) are also required

and are included in the distribution. These scripts  require PERL, which is also
freely available.


Goal: Supply warnings in the documentation when the above goal has not been met.

OK

Goal: Arrays should be dynamically allocated.

OK in the f90 modules.

Standard: The characteristics of I/O should be clearly documented (i.e. the
implementation of I/O unit numbers, if any).

N/A

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.

N/A

DOCUMENTATION STANDARDS

Standard: Provide name of contact person for support.

OK

Standard: Provide date of last revision.

Included in the README file

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.

N/A

Standard: Provide the index of input-output variables for each module (include
types of variable, dimension, units).

N/A

Standard: List dependencies - names of external routines called.

OK where applicable.

Standard: Provide statement of known bugs.

No known bugs are listed

Goal: Index of modules, routines, variables.

N/A

Goal: Publication of code or module in journal (such as Computer Physics
Communications).

N/A

Goal: Online hyper-text reference documentation.

None available.

Goal: Interactive online help menus.

None available. A brief man page is available. Useful comments exist in the
source code of most routines and functions.

DATA STANDARDS

Goal: Provide interface routines to data.

N/A

Goal: Use self-describing data files (sunc as NetCDF)

N/A

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.

N/A