Ottaviani-Horton-Erba Transport Model Prepared by Aaron Redd -- aredd@plasma.physics.lehigh.edu Matteo Erba -- erba@plasma.physics.lehigh.edu Arnold Kritz -- kritz@plasma.physics.lehigh.edu UNPACKING INSTRUCTIONS > gunzip ohe_model.tar.gz > tar xvf ohe_model.tar INSTRUCTIONS FOR PRINTING DOCUMENTATION: Latex file twice to obtain correct cross-references: > latex ohe_model.tex > latex ohe_model.tex > dvips -f ohe_model.dvi > ohe_model.ps CONTENTS: This directory should contain the following files: README driver.f ohe_model.tex ohe_model.f stripx.f xtverb.f ipin_1 ipout_1 makefile (uses gmake) These files are as follows: README: This file. Brief descriptions of the other files, and instructions for compiling the module containing the Ottaviani-Horton-Erba (OHE)transport model and its driver. driver.f: A simple driver program for the OHE module. This file reads the namelist from the input file 'ipin' and produces the output file 'ipout' which reflects the input variables and contains the thermal and particle diffusivities. ohe_model.tex: LaTeX file, with fortran code embedded inside, that describes this implementation of the OHE transport model. ohe_model.f: The fortran code stripped out of the LaTeX file. This file is intended only for use in compiling the code. The documentation is contained in the LaTeX file "ohe_model.tex". The makefile is written so that the make utility (using gmake) will always extract a new version of "ohe_model.f" from the fortran code embedded in the LaTeX master file. stripx.f: Utility routine, used by the driver program, which strips all annotation and comments out of the input namelist before it is read. Modified by D. McCune (November 1998) to work with namelist on the DEC alpha workstation. xtverb.f: Utility program which can pull fortran code out of a LaTeX document, leaving a fortran file. In this case, it is used to read the tex files described above and generate the corresponding fortran file. ipin_1: Sample input namelist for running the OHE transport model. Copy this file to a file called "ipin" before running this module. ipout_1: Sample output. This file contains the output that should be produced in file "ipout" when the sample input "ipin" file is used. makefile: File used by the gmake utility. NOTE, "gmake" not "make" must be used. This makefile has been written to work on the IBM/AIX, SUN/Solaris, SGI/IRIX and the DEC/alpha platforms and can be modified to work on other systems. This makefile contains the instructions for compiling and building both the "xtverb" utility and the "xohe" program. The choice of the CPU environment variable determines the platform and whether the compilation is single or double precision. The executable file, "xohe" is constructed using the files described above. The makefile also includes a clean option ("gmake clean") to remove all binaries. COMPILATION INSTRUCTIONS: * On IBM/AIX, SUN/Solaris, SGI/Irix or DEC/alpha platforms, simply type: gmake at the unix prompt. The makefile contains all the instructions needed by the "gmake" utility to create the test executable, which is called "xohe". NOTE: The makefile uses make-variable CPU to control platform- dependent settings. CPU can be set either by defining an environment variable CPU, or by editing the makefile to include a line CPU=... , or by typing CPU=... on the gmake execute line. If CPU is not set, it is defaulted to IBM. This version of the makefile is prepared for CPU=IBM (for an IBM/AIX system), for CPU=SOL (for Solaris), for CPU=SGI (for the SGI Origin 200) and CPU=DEC (for the DEC alpha). If you add another CPU branch to the makefile, please let us know what works. PRECISION: Note that the makefile CPU environment determines flags for the DEC, IBM SGI and SOL (SUN) platform and also determines whether the flags are set for single or double precision on each platform. For example a CPU variable of IBM results in a double precision compilation on the AIX platform; whereas, a CPU variable IBM_R4 results in a single precision compilation on the AIX platform. The module can be run either single or double precision. However, when the module was used in the BALDUR code, it was used and tested ONLY as a double precision module. * If the make utility does not work, or if the module is being compiled on a non-IBM, non-SUN, non SGI, or non DEC platform, then the compilations will need to be done by hand. What follows are step-by-step instructions for creating the test executable xohe. 1) First, generate the utility "xtverb". The only source code needed is xtverb.f. For example, on an IBM/AIX system, this compilation could be accomplished by: xlf -o xtverb xtverb.f 2) Pull the fortran code out of each LaTeX file using the utility "xtverb". The LaTeX file goes into "xtverb" in standard input, while standard output is the fortran file. xtverb < ohe_model.tex > ohe_model.f 3) Compile and produce object codes for "driver.f" and "ohe_model.f". On the IBM/AIX system, an object code is produced when the compiler is invoked with a "-c" option: xlf -c -o driver.o driver.f xlf -c -o ohe_model.o ohe_model.f xlf -c -o stripx.o stripx.f 4) Link these object codes together, producing the executable "xohe". For example: xlf -o xohe driver.o ohe_model.o stripx.o There are, of course, several compiling options that one could use when carrying out steps (1)-(4). The makefile contains the recommended compiling options for the IBM, SGI, SUN, and DEC systems, along with a brief description of each. These comments should make the task of finding analogous compiling options on another system easier. RUNNING INSTRUCTIONS: "xohe" requires only one input file, the namelist "ipin". To produce the test case, copy the sample input "ipin_1", to the file "ipin" and run "xohe". As it runs, "xohe" will generate two files: "temp" and "ipout". "temp" is a temporary file, containing the input namelist without annotation and notes. "temp" is actually the file read during the namelist read in the xohe program. "ipout" is the output file. At the beginning of this file, the input namelist (with annotation) is reproduced. When this package is ported to a new platform, it is suggested that the test case be run first. Each time, compare the output file "ipout" with the sample output file, "ipout_1" in order to verify that all is working as expected. IF YOU HAVE ANY PROBLEMS, PLEASE CONTACT: ARNOLD KRITZ, Lehigh University kritz@plasma.physics.lehigh.edu MATTEO ERBA, Lehigh University erba@plasma.physics.lehigh.edu AARON REDD, Lehigh University aredd@plasma.physics.lehigh.edu