( 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.