( 2 Jun 94)
**********************************
* *
* Section 6 - Hardware Specifics *
* *
**********************************
This section of the manual contains pages dealing in a
general way with dynamic memory allocation in GAMESS, the
BLAS routines, and vectorization.
The remaining portions of this section consist of
specific suggestions for each type of machine. You should
certainly read the section pertaining to your computer.
It is probably a good idea to look at the rest of the
machines as well, you may get some ideas! The directions
for executing GAMESS are given, along with hints and other
tidbits.
The version of the compiler which has been most
recently used is listed. This does not imply that older
versions (or indeed newer versions) do not work. Any
known problems with older versions are described.
The currently supported machines are:
1) IBM computers running any of the various MVS and VM
operating systems (*IBM). VM is often called CMS.
For IBM AIX systems, see category 3.
2) Digital Equipment computers under VMS (*VAX).
For DEC Ultrix systems, see category 3.
3) UNIX computers (*UNX). This includes machines such
as the IBM RS/6000, DEC AXP, and numerous others.
Some of the others are parallel computers such as
Intel Paragon and Thinking Machines CM-5.
4) Cray Research computers under UNICOS. (mainly *CRY,
with some *UCS)
dynamic memory in GAMESS
GAMESS allocates its working memory from one large
pool of memory. This pool consists of a single large
array, which is partitioned into smaller arrays as GAMESS
needs storage. When GAMESS is done with a piece of
memory, that memory is freed for other uses.
The units for memory are words, a term which GAMESS
defines as the length used for floating point numbers
(usually 64 bits, that is 8 bytes per word).
GAMESS contains two memory allocation schemes. For
some systems, a primitive implementation allocates a large
array of a *FIXED SIZE* in a common named /FMCOM/. This
is termed the "static" implementation, and the parameter
MEMORY= in $CONTRL cannot request an amount larger than
chosen at compile time. Wherever possible, a "dynamic"
allocation of the memory is done, so that MEMORY= can (in
principle) request any amount. The memory management
routines take care of the necessary details to fool the
rest of the program into thinking the large memory pool
exists in common /FMCOM/.
Computer systems which have a "static" memory
allocation are IBM mainframes running VM or MVS, or
Apollo and maybe a very few other Unix systems to which
we have no direct access for testing purposes. If your
job requires a larger amount of memory than is available,
your only recourse is to recompile UNPORT.SRC after
choosing a larger value for MEMSIZ in SETFM.
Computer which have "dynamic" memory allocation are
VMS machines and almost all Unix systems. In principle,
MEMORY= can request any amount you want to use, without
recompiling. In practice, your operating system will
impose some limitation. As outlined below, common sense
imposes a lower limit than your operating system will.
By default, most systems allocate a moderate amount of
memory: 750,000 words. This amount is adequate for
almost all HF (RHF, UHF, ROHF, GVB) runs, although
RUNTYP=HESSIAN may require more. Large GUGA runs (CI,
MCSCF) may require an increased value for MEMORY in
$CONTRL, perhaps to 2,000,000 words. EXETYP=CHECK runs
will always tell you the amount of memory you need.
Many places in GAMESS implement an out of memory
algorithm, whenever the in memory algorithm can require an
excessive amount. The in memory algorithms will perform
very poorly when the work arrays reside in virtual memory
rather than physical memory. This excessive page faulting
activity can be avoided by letting GAMESS choose its out
of core algorithms. These are programmed such that large
amounts of numbers are transferred to and from disk at the
same time, as opposed to page faulting for just a few
values in that page. So, pick an amount for MEMORY= that
will reside in the physical memory of your system!
The object code and local storage for GAMESS compiles
to about 5 Mbytes on most systems. Add this value to the
number of Mbytes requested by MEMORY= (the conversion is
multiply by 8, then divide by 1024 twice). For example,
750,000 words of memory leads to a total program size of
11 Mbytes. Depending on how many GAMESS jobs you run
simultaneously, and the total number of Mbytes of physical
memory installed in your system, you may be able to
increase the MEMORY= value.
A general guideline is to select an amount of memory
that will not be paged often. If your system has 64
Mbytes, and you are running only two copies of GAMESS at
one time, a reasonable choice for MEMORY= would be to
increase GAMESS to a total size of 28 Mbytes. That leaves
some memory for the operating system.
The routines involved in memory allocation are VALFM,
to determine the amount currently in use, GETFM to grab
a block of memory, and RETFM to return it. Note that
calls to RETFM must be in exactly inverse order of the
calls to GETFM. SETFM is called once at the beginning of
GAMESS to initialize, and BIGFM at the end prints a "high
water mark" showing the maximum memory demand. GOTFM
tells how much memory is not yet allocated.
BLAS routines
The BLAS routines (Basic Linear Algebra Subprograms)
are designed to perform primitive vector operations, such
as dot products, or vector scaling. They are often found
implemented in assembler language in a system library,
even on scalar machines. If this is the case, you should
use the vendor's version!
The BLAS are a simple way to achieve BOTH moderate
vectorization AND portability. The BLAS are easy to
implement in FORTRAN, and are provided in the file
BLAS.SRC in case your computer does not have these
routines in a library.
The BLAS are defined in single and double precision,
e.g. SDOT and DDOT. The very wonderful implementation
of generic functions in FORTRAN 77 has not yet been
extended to the BLAS. Accordingly, all BLAS calls in
GAMESS use the double precision form, e.g. DDOT. The
source code activator translates these double precision
names to single precision, for machines such as Cray and
ETA which run in single precision.
Machines which probably do provide assembler versions
of the BLAS are all vector machines, i.e. Cray or FPS.
If the ESSL library is installed on your IBM, then you
have vectorized versions of these routines. They also
are found in the Celerity UNIX library.
The reference for the BLAS is
C.L.Lawson, R.J.Hanson, D.R.Kincaid, F.T.Krogh
ACM Trans. on Math. Software 5, 308-323(1979)
Vectorization of GAMESS
As a result of a Joint Study Agreement between IBM and
NDSU, GAMESS has been tuned for the IBM 3090 vector
facility (VF), together with its high performance vector
library known as the ESSL. This vectorization work took
place from March to September of 1988, and resulted in
a program which is significantly faster in scalar mode, as
well as one which can take advantage (at least to some
extent) of a vector processor's capabilities. Since our
move to ISU we no longer have access to IBM mainframes,
but support for the VF, as well as MVS and VM remains
embedded within GAMESS. Several other types of vector
computers are supported as well.
Anyone who is using a current version of the program,
even on scalar machines, owes IBM their thanks both for
NDSU's having had access to a VF, and the programming time
to do code improvements in the second phase of the JSA,
from late 1988 to the end of 1990.
Some of the vectorization consisted of rewriting loops
in the most time consuming routines, so that a vectorizing
compiler could perform automatic vectorization on these
loops. This was done without directives, and so any
vectorizing compiler should be able to recognize the same
loops.
In cases where your compiler allows you to separate
scalar optimization from vectorization, you should choose
not to vectorize the following sections: INT2A, GRD2A,
GRD2B, and GUGEM. These sections have many very small
loops, that will run faster in scalar mode. The remaining
files will benefit, or at least not suffer from automatic
compiler vectorization.
The highest level of performance, obtained by
vectorization at the matrix level (as opposed to the
vector level operations represented by the BLAS) is
contained in the file VECTOR.SRC. This file contains
replacements for the scalar versions of routines by the
same names that are contained in the other source code
modules. VECTOR should be loaded after the object code
from GAMESS.SRC, but before the object code in all the
other files, so that the vector versions from VECTOR are
the ones used.
Most of the routines in VECTOR consist of calls to
vendor specific libraries for very fast matrix operations,
such as IBM's Engineering and Scientific Subroutine
Library (ESSL). Look at the top of VECTOR.SRC to see
what vector computers are supported currently.
If you are trying to bring GAMESS up on some other
vector machine, do not start with VECTOR. The remaining
files (excepting BLAS, which are probably in a system
library) represent a complete, working version of GAMESS.
Once you have verified that all the regular code is
running correctly, then you can adapt VECTOR to your
machine for the maximum possible performance.
Vector mode SCF runs in GAMESS on the IBM 3090 will
proceed at about 90 percent of the scalar speed on these
machines. Runs which compute an energy gradient may
proceed slightly faster than this. MCSCF and CI runs
which are dominated by the integral transformation step
will run much better in vector mode, as the transformation
step itself will run in about 1/4 time the scalar time on
the IBM 3090 (this is near the theoretical capability of
the 3090's VF). However, this is not the only time
consuming step in an MCSCF run, so a more realistic
expectation is for MCSCF runs to proceed at 0.3-0.6 times
the scalar run. If very large CSF expansions are used
(say 20,000 on up), however, the main bottleneck is the CI
diagonalization and there will be negligible speedup in
vector mode. Several stages in an analytic hessian
calculation benefit significantly from vector processing.
A more quantitative assessment of this can be reached
from the following CPU times obtained on a IBM 3090-200E,
with and without use of its vector facility:
ROHF grad RHF E RHF hess MCSCF E
BENCH10 BENCH4 BENCH13 BENCH7
------- ------ ------- ------
scalar 168 ( 1 ) 164 ( 1 ) 917 ( 1 ) 903 ( 1 )
vector 146 (0.87) 143 (0.87) 513 (0.56) 517 (0.57)
IBM
---
GAMESS runs on all IBM S/370 equipment such as the
438x, 308x, and 3090 systems (and plug compatibles) under
any of the MVS, MVS/XA, MVS/ESA, VM, VM HPO, or VM/XA
systems, as all of these support the exact same compiler,
VS FORTRAN. IBM AIX systems are described with the other
UNIX systems.
We do not have access to IBM mainframes at Iowa State,
so the VM, MVS, and AIX/370 versions have not been tested
by us since summer 1992. However, the MVS version has
been in use for so long prior to that that this version
should still be reliable.
XA: The source code assumes that you have one of the
extended address systems, by which we mean either XA or
the newer ESA. This means the file UNPORT.SRC has a
dimension of 5,000,000 for the /FMCOM/ dynamic memory
pool. If you have XA, use the compiler option DC(FMCOM)
to put this common block above the line. If you do not
have an XA system, then this dimension is way too large to
fit "below the 16 Mbyte line". Before you compile, you
must change the dimension of /FMCOM/, perhaps to 750,000
words, in order to obtain a 12 Mbyte load module. Of
course, do not use the DC(FMCOM) compile option in this
case. The control language provided assumes XA in *.MVS
files, and assumes its absence in the *.CMS files. The
*.CMS files have comments showing how to change things
if you have VM/XA on your system.
In the following, MVS means either MVS, MVS/XA, or
MVS/ESA, and likewise VM means VM, VM HPO, or VM/XA.
Vectorization: The MVS and VM control language
which we distribute assumes you have a scalar IBM system.
If your system does have a VF attached, then follow the
comments in these files which show you how to change the
language to use a VF. You can find all these places by
a string search for "VF".
Assembler: The IBM version comes with two assembler
routines for timing purposes. These have been tested with
both the F and H level assemblers. They are provided
instead of using CLOCK and DATIM in VS FORTRAN version 2
for backward compatibility with VS FORTRAN version 1.
They also work the same under VM and MVS, which is nice.
Compiler: The FORTRAN compiler which we last tested
is VS FORTRAN 2.4.0. You should use OPT(3) and NOSDUMP
for all modules. We used VS FORTRAN 1.4.1 for several
years, this is a very reliable compiler. Updated versions
of 2.3.0 and early versions of 2.4.0 do not compile SPDD
in VECTOR.SRC correctly. See the comments in this routine
if you have a IBM VF, and check EXAM07.INP's gradient very
carefully. Some versions of 2.3.0 will not vectorize
SGRAD and SHESS, in GRD1 and HSS1B respectively. The
symptom is a bombout at compile time, the fix is to use
PARM=NOVECTOR.
VM: The distribution tape contains some EXEC's named
*.CMS (you should COPYFILE * CMS B = EXEC =) for both
compilation and execution. The COMPALL EXEC does not
require ACTVTE, instead it uses XEDIT. These EXEC's
assume that the VMBATCH software has been installed on
your system, but they ought to be easy to modify for other
batch facilities. A 20 cylinder (3380) minidisk is
capable of storing both the source code (in V record
format, to avoid storing trailing blanks), and the
object code TEXTLIB. This minidisk must be linked in
read-only mode by VMBATCH when GAMESS is run. Any
co-workers can also link in read-only mode, so that only
one copy of the EXEC for execution and the TEXTLIB is
needed. Thus, the GAMESS minidisk probably should not
be your main A-disk. You must specify the number
of extents for file DASORT. You may want to experiment
with creating a single record direct file, with the correct
file lengths with a small FORTRAN program. COPYFILE this
single record file to your job's DASORT file, and this
file will not be filled with zeros when first open, and
it will grow only to the size it needs to be.
MVS: The *.MVS files are JCL control language for
this operating system. The *.MVS files are correct, to
the best of my knowledge. However, we did not use these
files, instead we used MVSMAINT.CMS to submit MVS jobs
from VM. If you have any problmes with the *.MVS files,
look at the contents of MVSMAINT.CMS for help. The *.MVS
files were created by editing out the correct JCL in
MVSMAINT, but mistakes can easily creep into JCL! The MVS
system provides a very nice feature that lets disk files
span more than one physical volume. Look at the control
language for AOINTS for an example.
VMS
---
The VMS version of GAMESS is correct for VAX scalar,
VAX vector, or Alpha based VMS systems. The graphics
programs will run under DECwindows, and can also produce
PostScript output.
We have an Alpha based AXP system at Iowa State, so
the best tested version of GAMESS is for the AXP. But,
GAMESS has run on VAX scalar systems for over a decade,
so you should have no trouble with that version either.
However, FORTRAN 6.0 on VMS processors seems to have a
problem with EIGEN.SRC for degenerate eigenvectors, for
the default KDIAG=1 method.
GAMESS was adapted to the VAX vector 6000 and 9000
systems by Chuck Schneider of Digital in Maynard. If
you have the FORTRAN HPO compiler as well as the Digital
Extended Math Library (DXML) you should be able to run
GAMESS in vector mode.
All three versions are identical, with one exception.
The line calling ERRSET in BEGING in UNPORT.SRC cannot
be used on an Alpha, so it is commented out CVAX. You
should change this line with a text editor to *VAX if
you are on a VAX based system. All versions, including
even the Alpha systems, use the *VAX lines for historical
reasons. Detailed compiling instructions can be found
in the README.VMS file.
- - - - -
Caution to VAX VECTOR users:
Very recent changes to the compiling scripts which
were necessitated by the arrival of our Alpha system
mean that the compiling *.COM files have not been tested
yet on a VAX vector based machine. If you have one of
these, we'd appreciate hearing if you have any problems.
The main change is that COMP.COM now vectorizes all but
a handful of files, and the DXML library is now required
rather than being optional. LKED.COM searches VECTOR.OLB
before GAMESS.OLB, in order to find the special vector
routines instead of their scalar counterparts. It would
be a good idea to verify this by looking at the load map.
Be careful checking test case results.
- - - - -
Your environment for running GAMESS should include
four logical variables, namely
$ ASSIGN DKA300:[MIKE.GAMESS] GAMESS:
$ ASSIGN DKA300:[MIKE.GAMESS.TOOLS] TOOLS:
$ ASSIGN DKA300:[MIKE.GAMESS.GRAPHICS] PLT:
$ ASSIGN DKB500:[SCRATCH.MIKE] SCR:
The latter is any disk area where you can write very
large scratch files while the batch jobs are running. It
is best if everyone has their own separate directory in
this scratch area. If your system manager has not already
made the above logical assignments for you, you can place
these in your LOGIN.COM file.
- - - - -
System managers should note that if you have more
than one disk, you can use MOUNT/BIND to achieve as large
as possible a "logical disk" for SCR:. Users may need to
have their WSEXTENT and PGFLQUO values in AUTHORIZE
increased to allow "reasonable" physical and virtual
memory use (16 MB and 24 MB respectively??? although
"reasonable" values will depend on your installed memory).
These AUTHORIZE values may require adjustment of SYSGEN
parameters WSMAX and VIRTUALPAGECNT.
Input for GAMESS must be stored in a file with the
extension .INP, such as MYFILE.INP. Run GAMESS by
$ SUBMIT GAMESS:RUNGMS/PARAM=myfile -
/LOG=[any.dir]myfile/NAME=myfile
The RUNGMS.COM file is:
$ deck = P1 ! name of .INP input deck.
$ IF deck.EQS."" THEN EXIT
$!
$! Pick up a copy of the input.
$!
$ COPY 'deck'.INP SCR:'deck'.F05
$!
$ ASSIGN SCR:'deck'.IRC IRCDATA
$ ASSIGN SCR:'deck'.F05 INPUT
$ ASSIGN SYS$OUTPUT OUTPUT
$ ASSIGN SCR:'deck'.DAT PUNCH
$ ASSIGN SCR:'deck'.F08 AOINTS
$ ASSIGN SCR:'deck'.F09 MOINTS
$ ASSIGN SCR:'deck'.F10 DICTNRY
$ ASSIGN SCR:'deck'.F11 DRTFILE
$ ASSIGN SCR:'deck'.F12 CIVECTR
$ ASSIGN SCR:'deck'.F13 NTNFMLA
$ ASSIGN SCR:'deck'.F14 CIINTS
$ ASSIGN SCR:'deck'.F15 WORK15
$ ASSIGN SCR:'deck'.F16 WORK16
$ ASSIGN SCR:'deck'.F17 CSFSAVE
$ ASSIGN SCR:'deck'.F18 FOCKDER
$ ASSIGN SCR:'deck'.F20 DASORT
$ ASSIGN SCR:'deck'.F23 JKFILE
$ ASSIGN SCR:'deck'.F24 ORDINT
$ ASSIGN SCR:'deck'.F25 EFPIND
$!
$ SET RMS_DEFAULT/DISK /BLOCK_COUNT=64 /BUFFER_COUNT=1
$ SET PROCESS/NAME=GMS_'deck'
$ RUN GAMESS:GAMESS.EXE
$!
$ DIRECTORY/SIZE=ALL/DATE SCR:'deck'.*
$ DELETE SCR:'deck'.F*;*
$ EXIT
Cray
----
We are grateful to Dick Hilderbrandt, formerly of San
Diego Supercomputer Center (SDSC) for the support and
help needed to get GAMESS ported to the Cray. Rozeanne
Steckler and Kim Baldridge of SDSC have continued to
provide support for the Cray version embedded in GAMESS.
Richard Walsh of the Minnesota Supercomputer Center
debugged the program for CFT77 and UNICOS, and helped with
the vectorization.
GAMESS is installed at the Alabama, Illinois (NCSA),
Minnesota, North Carolina, Ohio, Pittsburgh, San Diego,
and Texas Cray supercomputer centers. Ask the consultants
at each for more information about running there.
The compiling process for UNICOS is nearly identical
to other Unix systems, see below. Among other things,
this means you should follow README.UNIX for step by step
compiling instructions. Of course, Crays use VECTOR.SRC
but don't use BLAS.SRC. Every source code module must
pass through ACTVTE, in order to turn the program into
single precision. Activate *UNX in IOLIB, *UCS in UNPORT,
and *CRY everywhere else. Dynamic memory is implemented
for UNICOS. UNPORT.SRC contains two things which may
concern you: Unicos version 6 added the FLUSH system
call, which you should remove from FLSHBF if you have an
older version of Unicos. ABRT calls TRBK to generate a
subroutine traceback, and you may need to remove this if
you have a Cray-2 system.
UNIX
----
GAMESS will run on many kinds of UNIX computers.
These systems runs the gamut from very BSD-like systems
to very ATT-like systems, and even AIX. Our experience
has been that all of these UNIX systems differ from each
other. So, putting aside all the hype about "open systems",
we divide the Unix world into three classes:
Supported: the IBM RS/6000 and DEC AXP.
These are the only types of computer we currently have at
ISU, so these are the only systems we can guaranty work.
Both the source code and the *.CSH C-shell control language
is correct for these.
Acquainted: Alliant, Apollo, Celerity, Convex,
DECstations, FPS model 500, Fujitsu VP models, HP 9000 7x0,
MIPS, Silicon Graphics, Stardent TITAN, and Sun.
We do not have access to these systems at ISU, and so
we cannot guaranty that these work. GAMESS has been run
on each of these, but perhaps not recently. The source
code for these systems is probably correct, but the control
language may not be. Be sure to run all the test cases to
verify that the current GAMESS still works on these brands.
Terra Incognita: everything else, such as Data
General, other HPs, Encore.... You will have to decide on
the bit packing, the contents of UNPORT, write the control
language, and generally use your head.
The Berkeley like UNIX systems include three simple
bit manipulation functions: AND, LSHIFT, RSHIFT. The
"*UNX" version of GAMESS uses these where necessary.
Unfortunately, these functions are often not found on more
System V like machines. Many such machines can use the
"*VAX" or "*IBM" or "*CRY" unpacking code. If none of
these will work on your system, you can easily implement
the *UNX functions in C:
int and_ (i, j); int *i, *j;
{ return (*i & *j); }
int lshift_ (i, n); unsigned *i; int *n;
{ return (*i << *n); }
int rshift_ (i, n); unsigned *i; int *n;
{ return (*i >> *n); }
In addition to reading about your computer below, you
should look at the compiling clauses in the file COMP.CSH
for additional information about compiler and operating
system versions which are known to work.
AIX: IBM provides us with many flavors of their
Unix, which is called AIX. AIX/6000 runs on their
RS/6000 workstations, and a slightly modified form runs
on their Scalable Parallel systems. AIX/RT runs on the
old RT systems, AIX/370 on their mainframes, and AIX/PS2
on IBM'S Intel PCs. GAMESS has been run on the three
of these, which have completely different compilers.
Nonetheless, the *AIX lines in UNPORT.SRC are (basically)
correct for all three.
AIX/6000: "superscalar" system. Use the *UNX lines
when you compile ACTVTE (do not use -O when compiling
ACTVTE if you have XLF 2.2 installed). When you select
the target "aix6000", the compiling script will activate
*IBM everywhere, except *UNX in IOLIB and *AIX in UNPORT.
Before you begin, inspect the "comp" script's aix6000 xlf
clause to ensure it matches your compiler version, which
you can learn by the command "lslpp -h xlfcmp.obj". We
have not yet had the chance to try XL FORTRAN version 3.
AIX/SP1: parallel system, based on RS/6000 hardware.
Most of the installation process is identical to AIX/6000.
The compiler has a slightly different name, so select the
target of "aixsp1". You do not need to install TCGMSG,
as GAMESS uses the native message passing language, when
you select a parallel link in "lked".
AIX/370: scalar or vector system. The control
language provided in COMP.CSH assumes your system has a
vector facility. You should compile the ACTVTE program by
turning on the *AIX lines found in it. ACTVTE should then
turn on the *AIX lines in UNPORT.SRC, and *IBM lines in
every other source code module. There are a few lines of
code in UNPORT which must be added to the other *AIX lines
found in this file, in order to get AIX/370 to work. We
thank Dave Hrovat of the U. of Washington for these. These
extra PRAGMA statements must refer to routines with
lower case names. These few added lines begin with CAIX
so that they are not used by the other AIX flavors. The
compiling script uses 'sed' to automatically ensure the
CAIX lines begin with blanks. BENCH08 and BENCH11 have
never worked under AIX/370, bombing in the SQWRIT routine.
AIX/RT: scalar system. Activate *AIX when you are
manually compiling ACTVTE. The compiling script will
activate *IBM everywhere, except *AIX in UNPORT. Read the
note about the RT compiler in COMP.CSH before you proceed,
the compiler version used is crucial! The RT version
uses the *AIX lines, which are correct, but the current
OPEN statements in IOLIB seem to present a problem.
Alliant: vector system. Activate *VAX everywhere,
except *ALL in VECTOR and UNPORT, and *UNX in IOLIB.
John Montgomery wrote the *ALL lines, so we know they're
good. This version has been used by the Steven's group
at CARB, during 1991 and 1992, but recently the vector
code seems to have stopped working.
Apollo: Steve Elbert wrote the *APO lines in UNPORT,
which are correct for a DN10000 system. We do not have
control language for the 10000. The smaller model numbers
in the Domain series require that you manually change the
*A68 strings at the bottom of UNPORT to *APO before you
compile. This timing routine comes from Matt Gilbert, who
also provided the 'apollo68' control language for these
smaller, Motorola 68000 based systems.
Celerity Computing: scalar system. Use the library
BLAS. Activate *UNX everywhere, except *CEL in UNPORT.
This company has been out of business for some time, and
this GAMESS version was last used in summer 1992.
Convex: vector system. Activate *VAX everywhere,
except *CVX in VECTOR and UNPORT, and *UNX in IOLIB. John
Montgomery wrote the *CVX lines, so we know they're good.
Several people use this version, so it is now fairly
reliable. If you use a Convex in a parallel META cluster,
you may improve wall clock performance by adding -fi to
the fc options in "comp" and "lked".
DEC AXP and DECstation: These are scalar systems,
running OSF/1 and Ultrix, respectively. Select a target
of "decalpha" or "decmips" depending on which of these
you have. They are very similar, and share a similar
compiler called DEC FORTRAN, whose current release is 3.3
Because GAMESS runs correctly on our AXP system, it should
continue to work on DECstations as well. "comp" will
activate *UNX lines everywhere, except *DEC in UNPORT.SRC.
If you have a DECstation, you must also have a copy of
a special error handling file "zmips.c".
The following note should be read by DECstation owners
who have not upgraded their compilers. Each release of the
compiler (originally called FORTRAN for RISC) slowed down
in I/O sections of GAMESS, until version 3.1. For example,
BENCH04 required 655 CPU seconds with f77 1.0, 862 with 3.0,
and 583 with 3.1. Wall clock times for 1.0, 3.0, and 3.1
were 759, 971, 717. The number of compiler bugs has also
decreased with each release. Do yourself a favor and
upgrade if you are using a release older than 3.1.
We do not support Ultrix on VAX machines, since these
have a different compiler. Why aren't you running VMS if
you have a VAX?
FPS model 500: vector system. Activate *UNX lines
everywhere, except for *CEL in VECTOR and UNPORT. (*CEL
is used in VECTOR because this system was developed by
Celerity Computing before its purchase by FPS, and since
*FPS in VECTOR is reserved for the older x64 FPS models).
This version was tested by us off site in 1989, and was
used by a few people in 1990.
Fujitsu UXP/M: vector system. Activate *UNX lines in
IOLIB, *FUJ in UNPORT and VECTOR, and *IBM elsewhere. The
.CSH scripts assume that GAMESS is being installed on a
VP2200 system and that the Scientific Subroutine Library
(SSLII) is available. For other VP2000-series systems,
change the option -p2200 to the appropriate model number in
COMP.CSH. Fujitsu computers are marketed by Fujitsu,
Amdahl, Siemans, and ICL, so if you have one of these, try
the Fujitsu version. The *FUJ code in UNPORT and VECTOR
and in the compiling scripts was written by Ross Nobes in
August 1991. The usual Unix command 'fsplit' does not
exist on this system, so Ross had to write a script to do
this. I'm sure he'd be glad to give you a copy of it.
This version was verified again in November 1992.
HP 9000: This is likely to apply to the scalar 7xx
models only. Activate *IBM everywhere, except use *UNX
in IOLIB, and '*HP ' in UNPORT. The lines in UNPORT are
from Fred Senese, Don Phillips, and Tsuneo Hirano. Be
rather careful about running test cases for this version.
The "comp" script has very conservative optimization levels,
so you might want to play with higher levels to get more
performance. We put the slow choices in since HP seems to
have difficulty delivering a reliable optimizing f77.
Intel: The parallel version of GAMESS works on Paragon
and iPSC/860 systems ("Intel" does *not* mean 80x86 PCs!).
Message passing is done using the native system calls, so
there is no need to build TCGMSG. On an iPSC, you need a
special C file named gamess/misc/getenv.ipsc which should
be manually compiled after "compall", and explicitly linked
by editing "lked". GAMESS was tested on a Paragon in 1994.
KSR: The parallel version of GAMESS has been ported to
this platform by Winfried Schneider of Siemans-Nixdorf, a
marketer of the KSR/1 in Europe. Activate *UNX through
the program, except *KSR in UNPORT, GUGEM, GUGDGA, GUGDGB.
Use the -r8 flag when compiling ACTVTE itself.
MIPS: This was tested by the company, basically using
the SGI version (*SGI in UNPORT). The control language may
need some changes in order to work, as the company used the
-G 7 compile and link options. Neither SGI or DECstns
require this, so it is not in the supplied control language.
NEC SX-3: vector system. This port was done by Janet
Fredin at the NEC Systems Laboratory in Texas in fall 1993.
Select both *UNX and *UCS when manually compiling ACTVTE.CODE.
Compile actvte with "f77sx -float2 -w -o actvte.x actvte.f".
This version uses *CRY lines, except *UNX in IOLIB and *SX3
in UNPORT and VECTOR. Before compiling, note that you must
have a copy of the NEC memory allocation routine stored by
the name gamess/misc/zunix.nec, Before linking, make sure
you have placed your site dependent path to the BLAS library
in the lked script. Before running, you need to add five
lines to the execution script:
setenv F_RECLUNIT BYTE
setenv F_ABORT YES
setenv F_ERROPT1 252,252,2,2,1,1,2,1
setenv F_PROGINF detail
setenv F_SETBUF 4096
Silicon Graphics: scalar system. Activate *UNX
everywhere, except *SGI in UNPORT. This version is used
by a fair number of people, so it should be reliable.
The "comp" script generates code for R4000 processors,
and thus must be edited before using it on R3000 based
systems (type "hinv" if you are not sure what you have).
Stardent TITAN: vector system. Activate *VAX lines
everywhere, except *UNX in IOLIB and *ARD in VECTOR and
UNPORT. The "ardent" measures direct access file sizes in
integers rather than bytes, so the compiling script changes
an 8 to a 2 in the *UNX open statement in RAOPEN. This
version was last tested by others in October 1992.
Sun 3/4/SPARCstn: scalar system. Activate *UNX lines
everywhere, except *SUN in UNPORT. Mariusz Klobukowski and
Dave Feller have Suns, so this version is recently tested,
and should be fairly reliable. Everyone using the current
release (late 1990) of Sun FORTRAN (1.3.1) reports I/O
problems. Lance Jacobs has found that you can request a
replacement FORTRAN library from Sun that that will fix the
problems. Lance also suggests that you avoid using TMPFS
if you store FORTRAN scratch files in the /tmp area.
Thinking Machines CM-5: since this system supports a
FORTRAN callable message passing library, we were able to
make this machine run the parallel version of GAMESS even
though TCGMSG does not support this platform. The "tmc"
version is much like the Sun, using *UNX lines throughout,
except for *TMC lines in UNPORT and TCGSTB which invoke
the CMMD message passing library. I/O is poor on a CM-5,
so we have mainly used direct SCF only. If you try MCSCF
or MP2, you may need to use the C shell "limit" command
to raise the open file limit.
* * *
UNPORT.SRC contains support for several others,
like Stardent "stellar" and Data General, but you may
encounter more difficulties than with the above.
* * *
Please use the *.CSH scripts supplied with GAMESS to
compile and link the program. The scripts know how to
activate the source code (using different strings in
different files). They know how to delete the scalar
versions of subroutines automatically when compiling on a
vector machine. They know the names of your compiler, and
the libraries to be searched, and so on. Some detailed
directions for how to use the scripts can be found in the
file named gamess/misc/readme.unix
* * *
The next page shows a C shell 'script' to execute
GAMESS. Invoke this script by entering the command
nice +10 rungms JOB >& JOB.log &
where JOB is the name of your .inp file (and is probably
in lower case). The USER variable should be set to your
name automatically when you login (spell this LOGNAME for
some systems).
You should change the directory where the .inp file is
to be found. If you like, the output can be put in its
own separate file, rather than the .log file, by assigning
OUTPUT to the desired file.
Note that the .dat and .irc files are OPENed with
STATUS='NEW', and the job will bomb unless you clear
away any older versions of these files. Since there are
no version numbers as on a VAX, you probably should use
separate names for each .inp file, thereby automatically
avoiding .dat and .irc conflicts.
#!/bin/csh
#
# C-shell script to execute a GAMESS test job. Invoke by
# 'rungms JOB >& JOB.log &'
# where JOB is the name of the 'JOB.inp' file to be run.
#
# The next two lines need to be customized.
# SCR is a directory for large temporary files.
#
set path=($path /u/mike/gamess)
set SCR=/scr/$USER
#
set JOB=$1
date
echo ----- GAMESS execution script -----
set echo
# Copy the input.
cp $JOB.inp $SCR/$JOB.F05
# file assignments.
setenv IRCDATA $SCR/$JOB.irc
setenv INPUT $SCR/$JOB.F05
setenv PUNCH $SCR/$JOB.dat
setenv AOINTS $SCR/$JOB.F08
setenv MOINTS $SCR/$JOB.F09
setenv DICTNRY $SCR/$JOB.F10
setenv DRTFILE $SCR/$JOB.F11
setenv CIVECTR $SCR/$JOB.F12
setenv NTNFMLA $SCR/$JOB.F13
setenv CIINTS $SCR/$JOB.F14
setenv WORK15 $SCR/$JOB.F15
setenv WORK16 $SCR/$JOB.F16
setenv CSFSAVE $SCR/$JOB.F17
setenv FOCKDER $SCR/$JOB.F18
setenv DASORT $SCR/$JOB.F20
setenv JKFILE $SCR/$JOB.F23
setenv ORDINT $SCR/$JOB.F24
setenv EFPIND $SCR/$JOB.F25
# now execute GAMESS.
# JOB is not used, except to show in the 'ps' display.
gamess.01.x $JOB
unset echo
echo ----- accounting info -----
date
ls -lF $SCR/$JOB.*
rm $SCR/$JOB.F*
rm $SCR/$JOB.dat
time
FPS
---
FPS Computing purchased Celerity Computing, and is now
marketing Celerity's vector processing UNIX system as the
FPS model 500. For a description of how to run GAMESS on
this machine, see the pages regarding the UNIX version.
The rest of this section refers only to FPS's traditional
product line, the various x64 attached processors.
GAMESS has not been tested on an FPS in quite a while,
so there may be compile errors. It is quite possible that
this version no longer works. We no longer distribute FPS
control language with GAMESS.
GAMESS runs under the SJE F03-200 operating system.
Use the FORTRAN compiler APFTN64 with /OPT=3 for all
modules. Do not compile the BLAS on FPS.
ETA
---
The *ETA version was once used on ETA-10 and Cyber-205
systems. The compilers on these systems were frequently
unable to generate correct code. Now that CDC is out of
the computer business, this version has fallen into
complete disuse.
