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