GAMESS documentation
Section 1 - Overview
Section 2 - Input Description
Section 3 - Input Examples
Section 4 - Further Information
Section 5 - Programmer's Reference
Section 6 - Hardware Specifics
( 5 May 98)
**********************************
* *
* 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. Any known problems with older versions of compilers
are described in the control language files themselves.
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 AXP or VAX computers under VMS (*VAX).
For DEC Unix systems, see category 3.
3) UNIX computers (usually *UNX). This includes machines
such as the IBM RS/6000, DEC AXP, Sun SPARC, Linux on
Intel, and numerous others. Some of the others are
parallel computers such as the IBM SP2 and Cray T3E.
1
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.
1
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.
1
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. They are also now
frequently found on scalar machines.
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)
1
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.
1
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)
1
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 IBM version has
been in use for so long prior to this that it should still
be reliable. 1992 was a long time ago, so good luck...
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 control language and source code
which we distribute assumes you have a scalar IBM system.
If your system does have a VF attached, then follow the
comments in the VM or MVS control language which show you
how to change these to use a VF. (You can find all these
places by a string search for "VF"). In addition, change
UNPORT.SRC's subroutine ASKVEC so that it returns true
for IBM equipment.
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.
1
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. 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.
For some reason, the VS FORTRAN compiler does not
accept the FORTRAN 77 syntax "COMPLEX*16 FUNCTION XXX"
used in two places in ZHEEV.SRC. You should change these
to read "COMPLEX FUNCTION XXX*16" before you compile.
VM: The distribution 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, they have not been
used in a long time, and 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.
1
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. We have also heard that
ZHEEV.SRC may need to be compiled with optimization
turned off.
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.
1
- - - - -
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.
1
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
1
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 four classes:
Supported: the IBM SP2, IBM RS/6000, DEC AXP, Sun
ultraSPARC, and Intel Pentium under RedHat Linux. These
are the only types of computer we currently have at ISU,
so these are the only systems we can guarantee will work.
Both the source code and the C-shell control language is
correct for these.
Acquainted: Convex, ConvexSPP, Cray, Cray T3D and T3E,
Fujitsu AP and VPP, Hitachi SR, HP 9000, NEC SX, and SGI.
We do not have access to these systems at ISU, and so
we cannot guarantee 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.
Jettisoned: Alliant, Apollo, Ardent, Celerity,
DECstations, FPS model 500, IBM AIX mainframes, Intel
Paragon, Kendall Square, MIPS, NCube, Thinking Machines.
In most cases the company is out of business, or the number
of machines in use has dropped to near zero. Accordingly,
these versions were dropped from the source code UNPORT.SRC
and compiling scripts in fall 1997. Of these, only the
Celerity version's passing should be mourned, as this was
the original UNIX port of GAMESS, back in July 1986.
Terra Incognita: everything else! You will have to
decide on the bit packing, the contents of UNPORT, write
the control language, and generally use your head.
* * * * *
You should have a file called "readme.unix" at hand
before you start to compile GAMESS. These directions
should be followed carefully. Before you start, read the
notes on your system below, and read the compiler clause
for your system in 'comp', as notes about problems with
certain compiler versions are kept there.
1
Convex: C-series vector system. John Montgomery
wrote the *CVX lines. We do not get many requests for the
Convex version, and its reliability is questionable.
ConvexSPP: the SPP is a parallel system built with HP
PA-RISC nodes, and so this version is derived from the HP
version. It differs only in the control language used to
compile and link, which was supplied to us by Dave Mullally
of Convex Corporation. Be careful checking the test
inputs on this system.
Cray: this means the C90 type vector systems.
Thanks to Dick Hilderbrandt, Kim Baldridge, Richard Walsh,
and Howard Pritchard for their help with Crays and UNICOS.
This is a 64 bit system, so be sure to activate the "*SNG"
line in actvte.code, in addition to "*UNX". This version
should be reasonably reliable.
Cray T3D or T3E: These are parallel computers from
Cray. We are in the process of changing the parallelization
of GAMESS, and have switched (without testing) from use of
a TCGMSG emulation to native MPI calls. It should work, at
least on the T3E. Special source files second.t3d and
getenv.t3d are needed, from ~/gamess/misc.
DECaxpfxx: These are scalar systems, running OSF (aka
Digital Unix), respectively. The target name is "decaxpf77"
or "decaxpf90" depending on which compiler you happen to
have (the two perform very similarly). If you wish to run
in parallel, a special version of TCGMSG ported by DEC
Ireland for 32 bit integers is available by anonymous FTP
from our WWW server, www.msg.ameslab.gov, in the file file
~/tcgmsg/dec.axp.tar.Z. The XDR option does not work, so
this tar file is for pure DEC AXP environments only.
Fujitsu: The AP is a parallel system (SPARC nodes),
and the VPP is a vector system. On the AP, you will most
likely compile in parallel from the beginning, and will be
using the system's MPI library. For the VPP systems, the
program will also use the system MPI if you choose to link
in parallel. The *FUJ code in UNPORT and VECTOR was written
by Ross Nobes in August 1991 for the VPP line. The VPP
version was verified in Feb 1998 by Anthony Russell, and
the AP version added by Ajay Limaye at the same time, in
Alistair Rendell's group at Australian National University.
Hitachi SR2201. This is a MPP platform. This version
is due to Masato Yamanishi of Tokyo University. The MPI
library on this system is used to run in parallel, so do
not try using TCGMSG.
1
HP 9000: Any PA-RISC series 700 workstation. The HP
version is due to Fred Senese, Don Phillips, and Tsuneo
Hirano. Dave Mullally has verified this version in summer
of 1997, but be careful about running test cases for this
version.
IBM 6000: "superscalar" RS/6000. Use the *UNX lines
when you compile ACTVTE. When you select the target of
"ibm6000", the compiling script will activate *IBM lines
everywhere, except *UNX in IOLIB and *AIX in UNPORT.
Before you begin, inspect the "comp" script's ibm6000 xlf
clause to ensure it matches your compiler version. The
xlf compiler has changed quite a lot, with many added
compiler flags. If you have an old version of the xlf
compiler, you cannot use the "flush_" call in FLSHBF in
UNPORT.SRC, which requires manual editing of UNPORT.SRC.
IBM 9076: The SP1 and SP2 parallel systems, based
on RS/6000 hardware. Most of the installation process
is identical to IBM6000. The comp section for "ibm9076"
assumes you have a SP2 with Power2 nodes, so other models
will require that you change -qarch before compiling. You
do not need to install TCGMSG, as GAMESS uses the native
"Parallel Environment" message passing library, when you
select a parallel version in "comp" and "lked".
NEC SX-3/SX-4: vector system. This port was done by
Janet Fredin at the NEC Systems Laboratory in Texas in 1993,
and it was updated by her in July 1997. You should select
both *UNX and *SNG when manually compiling ACTVTE.CODE.
Compile actvte with "f77sx -float0 -w -o actvte.x actvte.f".
This version uses *CRY lines, except *UNX in IOLIB and *NEC
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. The installation scripts
build a parallel executable (using MPI), but if you run this
on one node with the pargms script, it will behave as a
sequential version. 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
PC Unix: this means Linux or FreeBSD systems, using
f2c/gcc as a "FORTRAN compiler". This version was written
by Pedro Vazquez in Brazil in December 1993, and modified
by Klaus-Peter Gulden in Germany. The usefulness of this
version has matched the growth of interest in PC Unix, due
to the improvement in Intel CPU performance, and increase
in memory and disk capacities, to near workstation levels.
We have acquired a 266 MHz PentiumPro PC running RedHat
Linux in August 1997, and find it performs flawlessly.
Caution: The compiler flags are chosen for the RedHat 4.2
distribution, and perhaps change for other PC Unices.
1
Silicon Graphics: scalar system. This version is used
by a fair number of people, so the source code is reliable.
However, SGI FORTRAN compilers are of poor quality, and so
you should read 'comp' carefully about how to work around
the various problems each version seems to have. Problems
are a function of both compiler version and the chip being
compiled for, so the list in 'comp' should be regarded as an
approximation only. You may very well have to experiment
with optimization levels to get correct numerical results.
SGI has sold machines with R2000, R3000, R4x00, R5000,
R8000, and R10000 processors. If you are not sure which you
have, type "hinv" to find out. The target "sgi" compiles for
either the R8000 or R10000 chip, defaulting to the latter.
The "sgiold" target produces code for either the older R3000
or R4x00 chip, defaulting to the latter. Therefore, if you
have a R3000 or R8000 system, you must use 'vi' to make the
simple edit described in comments within the 'comp' script
to select for your chip. There is a special clause for the
R5000 in 'comp', which is initially commented out.
If you intend to run in parallel, you have two choices.
A special version of TCGMSG created by Omar Stradella is
the tested option, if you feel experimental, you can try to
use the MPI library of SGI. The default is the former, and
you can download this by anonymous FTP to www.msg.ameslab.gov,
file sgi.mips.tar.Z within directory tcgmsg. If you decide
to try MPI, go to http://www.sgi.com/Products/Evaluation, to
download the message passing toolkit. To use this you must
change 'comp' in two places: activate *MPI instead of *TCG
when compiling DDI.SRC, and add the correct SGI target to
the "sed hack" that "hardwire LOOP balancing". The 'lked'
script will need an addition like this,
if ($TARGET == sgi) set MSG_LIBRARIES='-L/my/mpi/path -lmpi'
and to execute with 'pargms', add
if ($TARGET == sgi-mpi) then
set GMSPATH= .....
chdir $SCR
set echo
mpirun -np $NNODES $GMSPATH/gamess.$VERNO.x $JOB
unset echo
endif
Sun: scalar system. This version is tuned for the new
ultraSPARC 2 chips, running current Solaris. If you have
an older SPARC system, change the 'comp' script's choice
for the architecture. The new Solaris and FORTRAN can use
disk files larger than 2 GBytes, as we have verified, if
you download the replacement I/O library from
http://www.sun.com/workshop/performance/largefiles.html
We have not yet had a chance to test the MPI library which
Sun provides, but have modified TCGMSG to function under
the current release of Solaris.
1
* * *
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); }
1
Below is a template C shell 'script' to execute
GAMESS. Invoke this script by entering the command
seqgms JOB >& JOB.log &
where JOB is the name of your .inp file (and is probably
in lower case).
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 save or
erase these files from a previous job of the same name.
#!/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 /u3/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
...many other setenv's deleted...
# 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