Introduction

The General Atomic and Molecular Electronic Structure System (GAMESS) is a general ab initio quantum chemistry package.  See the GAMESS home page for documentation. The version installed on WestGrid systems is the one maintained by the Gordon group at Iowa State University, not GAMESS-UK. 

GAMESS has been used by a number of WestGrid researchers, some installing it in their own directories. WestGrid adminstrators have installed GAMESS for general use on Checkers, Lattice and Grex.  See system-specific notes below. See the GAMESS entry in the main WestGrid software table for information about the version installed on each system.

Licensing

We are allowed to expose the executables, documentation and test files to our users, but, access to the source code is restricted.

Please read the license conditions on the GAMESS website before using the software on WestGrid.

Running GAMESS on Checkers

On Checkers (checkers.westgrid.ca), the GAMESS environment is configured with the module command (as illustrated in the sample scripts below).  The module load gamess command used in the examples is appropriate for the default version of GAMESS. If the default version is not the one you want, type module avail to see the list of available versions, then, change your script to load the one you do want.  See the WestGrid modules page for more information about modules.

As of this writing (2009-11-24), the installed version uses sockets rather than MPI for internode communication.  Although an MPI version was also tested and appeared to be faster than the sockets version, there are complications in how to request the computing resources when using the MPI version.  The scripts below are appropriate for the sockets version.  Please contact WestGrid technical support if you plan to use GAMESS, to make sure that there have not been significant changes in the way that it should be run.

An example of a minimal batch job script for running a serial version of GAMESS is

A minimal script for a parallel job is

Running GAMESS on Lattice

GAMESS has been configured on Lattice for MPI parallel execution. Good parallel performance for appropriate types of calculations and problem sizes should be expected. For example, a common Taxol benchmark scales well to at least 32 processors.

GAMESS on Lattice makes use of the MVAPICH 1.2 MPI-1 environment. To properly allocate processes, TORQUE jobs must be run using the rungms script provided. This script takes into account the GAMESS behavior of running one data communication and one computational process on each processor. The data communication process is lightweight and contributes little to the processor load. As noted in the Lattice QuickStart Guide, it is recommended that jobs on Lattice request whole nodes by using a TORQUE resource request of the form -l nodes=nn:ppn=8, with the processors per node parameter (ppn) equal to 8 and nn equal to the number of nodes. Do not use the procs resource request or the rungms script that is used to start GAMESS may not function correctly.

GAMESS scratch files are created in a sub-directory of the user's /global/scratch/$USER/gamess-scr directory. Each job uses a unique scratch directory named with the TORQUE job number. The scratch files are removed following each job whether it succeeds or fails, however it is good practice to check for scratch files following a run which terminates abnormally.

The rungms script writes important output files to the directory from which the job was submitted. The script will exit immediately, with a warning, if files exist from a previous run.

As an example, copy the Taxol GAMESS input files to a gtest directory:

mkdir ~/gtest
cd ~/gtest
cp /global/software/gamess/gamess2010oct01/sample/* .

The file taxol.pbs contains:

#!/bin/bash
GMS_PATH="/global/software/gamess/gamess2010oct01"
VER="03"
JOBNUM=$(basename $PBS_JOBID .hn001)
cd ${PBS_O_WORKDIR}
${GMS_PATH}/rungms taxol-6-31g ${VER} &> taxol-6-31g.${JOBNUM}.log

Note the version number 03 corresponds to the R3 release of GAMESS 2010-Oct-01, which is also the default. To submit the job using 24 processors (3 nodes with 8 processors per node):

qsub -l walltime=1:00:00 -l nodes=3:ppn=8 -l mem=30gb taxol.pbs

Adjust the mem parameter according to the number of whole nodes requested, requesting 10gb per node.  A copy of the output from this sample run is in taxol-6-31g.sample.log.

Running GAMESS on Grex

On Grex (grex.westgrid.ca), both sockets and MPI builds of GAMESS are available. The current (Aug. 2011) version of the code is installed. For the moment, it is recommended to use the sockets version for it is more robust. The procedure of running GAMESS jobs is thus similar to the one on Checkers cluster  (see above). The GAMESS environment is accessible via the module load gamess. The sockets version of GAMESS can be invoked with rungms script.

Behavior of the script can be influenced by environment variables.  By default, the script attempts to use local scratch directories on the nodes, which is a reasonable choice in most cases. If there is not enough space there, one can set GLOBAL_SCRATCH environment variable. It will place temporary GAMESS files under /global/scratch/$USER/gamess-scratch. In order to specify custom basis sets, the EXTBAS environment variable can be set.

Both -l procs=xxx and -l nodes=yyy:ppn=zzz styles are possible for specifying the CPU resources in theTorque scripts. There is no assumptions on how you specify your CPU cores over the requested nodes for the sockets version of GAMESS. The second parameter in the rungms script must be either 00 or sockets to make sure that it is the sockets version that you want to run. Input filese for GAMESS usually have the .inp extension (as in exam01.inp).

Updated 2012-01-06.