(17 Oct 96)
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 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, and numerous others. Some of the others are parallel computers such as the IBM SP1 and SP2, Intel Paragon, Cray T3D or T3E, and the Thinking Machine CM-5.
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.
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)
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)
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.
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.
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.
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=myfileThe 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
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 SP2, 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 will work. Both the source code and the *.CSH C-shell control language is correct for these.
Acquainted: Alliant, Apollo, Celerity, Convex, Cray, Cray T3D/E, DECstations, FPS model 500, Fujitsu VP models, HP 9000 7x0, MIPS, Silicon Graphics, Stardent TITAN, 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.
You should have a file called "readme.unix" at hand before you start to compile GAMESS. Read the notes on your system below, and follow these directions carefully.
Alliant: vector system. John Montgomery wrote the *ALL lines in UNPORT, so we know they're good. This version is rather unreliable.
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. It is anybody's guess as to whether this version works.
Ardent TITAN: vector system. This version is rather unreliable.
Celerity Computing: scalar system. This company has been out of business for some time. This GAMESS version was last used in summer 1992.
Convex: C-series vector system. John Montgomery wrote the *CVX lines. Several people have used this version, so it is now fairly reliable.
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 X-MP, Y-MP, etc. vector systems. Thanks to Dick Hilderbrandt, Kim Baldridge, and Richard Walsh for their help with Crays and UNICOS. This is a 64 bit system, so be sure to activate the "*UCS" line in actvte.code, in addition to "*UNX". This version should be reasonably reliable. It is possible to use a TCGMSG to PVM translation code on the traditional Cray vector machines, see the t3d.readme file for more details.
Cray T3D or T3E: These are parallel computers from Cray. The T3D port was done by Nick Nystrom and Michael Lambert at PSC, and by Carlos Sosa at Cray Research. The parallelization is achieved by using a special C language file, t3dtcg.c, written by Martin Feyereisen and Carlos Sosa to translate GAMESS' TCGMSG calls to Cray's MPT PVM message passing library, and has been modified for the T3E by Cray's Howard Pritchard. Thus, you don't use TCGMSG on these systems. In addition to t3dtcg.c, you will also need a special source file getenv.t3d. Special directions for compilation are in the file gamess/misc/t3d.readme.
DECaxpfxx and DECmips: These are scalar systems, running OSF/1 and Ultrix, respectively. "axp" means alpha CPU chip, while "mips" means the older DECstation MIPS CPU machines. Use "decaxpf77" or "decaxpf90" depending on which compiler you happen to have (the two perform very similarly). The older DECstations should still work, since the source code is essentially identical to the AXP versions. If you have a DECstation, you must also use a special error handling file "zmips.c". The DEC UNIX version should be solid.
FPS model 500: vector system. This is a descendent of the Celerity, brought to market by FPS, and ultimately led to the Cray superserver series. It hasn't been tested since 1990.
Fujitsu UXP/M: vector system. The compiling scripts assume that GAMESS is being installed on a VP2200, and that the Scientific Subroutine Library is available. For other VP2000-series systems, change the option -p2200 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. The HP version is due to Fred Senese, Don Phillips, and Tsuneo Hirano. Be very careful about running test cases for this version. The "comp" script has some 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.
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 link in "lked".
IBM 370: scalar or vector mainframe. 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. There are a few lines 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 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.
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 (only), 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, and so should be fairly reliable. The Intel systems have very poor I/O capability, so they are really useful only for direct SCF and direct MP2 runs.
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. This is a 64 bit system, so be sure to turn on "*UCS" as well as "*UNX" when you are building ACTVTE, and use the -r8 flag when compiling this program. Be careful about running tests, and if you are ambitious, you can investigate using higher optimization levels in "comp".
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/SX-4: vector system. This port was done by
Janet Fredin at the NEC Systems Laboratory in Texas in 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
PCUnix: this means Linux or BSD type systems, using f2c/gcc as a "FORTRAN compiler". This version was written by Pedro Vazquez in Brazil, and modified by Klaus-Peter Gulden in Germany. It has never been tested by us, and so is offered strictly "as is". Caveat emptor! A lot of people have used it without incident, though.
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. SGI has sold machines with R2000, R3000, R4x00, 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 R8000 or R3000 system, you must use 'vi' to make the simple edit described in the comments within the 'comp' script to select for your chip. Omar Stradella of SGI has created a 64 bit version of TCGMSG to use on the R8000, and you can contact him at omar@boston.sgi.com to find out about getting a copy.
Sun: scalar system. This is a fairly reliable version. The version is for use with Sun's compiler, not GNU's g77.
Thinking Machines Corp.: The CM-5 is a parallel system based on the SPARC chip. Thanks to Steve Saroff for helping with this version. The CM-5 version uses the native CMMD message passing library, so do not build TCGMSG. This system has very poor I/O capability, so it is really useful only for direct SCF and direct MP2 runs.
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
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.
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 /u1/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