PGI Guide to GAMESS

This guide is intended to help build GAMESS using the PGI 2010 compilers.

Version Information

This guide was created for the release of GAMESS tagged as January 12, 2009 R3. This information is for both x64 processors running 64-bit Linux or x86 processors running 32-bit Linux.

Application Notes

GAMESS is freely available. Access to the source codes requires registration. The GAMESS webpage is at http://www.msg.chem.iastate.edu/GAMESS/

(From the webpage) "GAMESS is a program for ab initio molecular quantum chemistry. Briefly, GAMESS can compute SCF wavefunctions ranging from RHF, ROHF, UHF, GVB, and MCSCF. Correlation corrections to these SCF wavefunctions include Configuration Interaction, second order perturbation Theory, and Coupled-Cluster approaches, as well as the Density Functional Theory approximation. Nuclear gradients are available, for automatic geometry optimization, transition state searches, or reaction path following. Computation of the energy hessian permits prediction of vibrational frequencies, with IR or Raman intensities. Solvent effects may be modeled by the discrete Effective Fragment potentials, or continuum models such as the polarizable Continuum Model. Numerous relativistic computations are available, including third order Douglas-Kroll scalar corrections, and various spin-orbit coupling options. The Fragment Molecular Orbital method permits use of many of these sophisticated treatments to be used on very large systems, by dividing the computation into small fragments. Nuclear wavefunctions can also be computed, in VSCF, or with explicit treatment of nuclear orbitals by the NEO code.

A variety of molecular properties, ranging from simple dipole moments to frequency dependent hyperpolarizabilities may be computed. Many basis sets are stored internally, together with effective core potentials or model core potentials, so that essentially the entire periodic table can be considered.

Most computations can be performed using direct techniques, or in parallel on appropriate hardware. Graphics programs, particularly the MacMolplt program (for Macintosh, Windows, or Linux desktops), are available for viewing of the final results, and the Avogadro program can assist with preparation of inputs."

Obtaining the Source Code

The GAMESS license agreement can be accessed at http://www.msg.chem.iastate.edu/GAMESS/License_Agreement.html

After filling out the license agreement, you will receive email with the current password to the source download page. The password changes every week.

Follow the instructions in the email and download gamess-current.tar.gz

Prerequisites

None

Building GAMESS

  1. Untar the GAMESS package:

       tar -xvzf gamess-current.tar.gz
       cd gamess
    
  2. Edit the build files:

    In the file "compall" set the TARGET to either linux32 or linux64, depending on your particular target. Change the chdir line to point to your build directory and change the compiler line for your platform as follows:

       
       set TARGET=linux64 # set to either linux64 or linux32
       chdir /home/me/Documents/GAMESS/gamess # set to gamess source distribution
    
       if ($TARGET == linux64) set CCOMP='pgcc -fast'
       if ($TARGET == linux32) set CCOMP='pgcc -fast'
    

    Remove -m64 flag from extraflags line so that it reads:

       if ($TARGET == linux64)    set extraflags='-DLINUX64' 
       if ($TARGET == linux32)    set extraflags='-DLINUX32' 
    
    

    In the file "comp" set the TARGET to either linux32 or linux64, depending on your particular target. Change the chdir line to point to your build directory and change instances of pgf77 to pgfortran. Change the line:

       set FORTRAN=gfortran   # choose from gfortran, pgfortran, pathf90
    

    to:

       set FORTRAN=pgfortran    # choose from gfortran, pgfortran, pathf90
    

    In the file "lked" set the TARGET to either linux32 or linux64, depending on your particular target. Change the chdir line to point to your build directory and change instances of pgf77 to pgfortran. Change the line:

       set FORTRAN=gfortran      # choose from gfortran, pgfortran, pathf90
    

    to:

       set FORTRAN=pgfortran     # choose from gfortran, pgfortran, pathf90
    
  3. Build the code:

       ./compall >& build.log
    
  4. Building the Distributed Data Interface

    Change directories into "ddi":

       cd ddi
    

    Edit file "compddi". Change TARGET to either linux64 or linux32 as required by your hardware. Change all instances of pgf77 to pgfortran. Change the Fortran compiler to pgfortran. For example:

       if ($TARGET == linux64)    set FORTRAN=pgfortran
    

    Just beneath this, change the C compiler to pgcc and the CFLAGS to PGI values e.g.:

       set CC = 'pgcc'
       set CFLAGS = "-DLINUX -fast -I./include"
    

    Set the variables MAXCPUS and MAXNODES

    Compile the ddi interface:

       ./compddi >& compddi.log
    

    Move "ddikick.x" up one level:

    mv ddikick.x ..
    

    Move yourself up one level:

       cd ..
    
  5. Link the executable:

       ./lked gamess 01
    

    If you have ACML installed, the link step should pick that up and use it to link in the optimized BLAS routines. As the code was compiled with Interproceedural analysis, you will see an IPA recompile at link time.

    The resulting executable will be called "gamess.01.x"

Running GAMESS

Edit the scripts "runall" and "rungms":

  1. In "rumgms" and "runall" change the VERNO from 00 to 01 (or what you used in the above step).

  2. In "rungms" set the SCR variable to your scratch location.

    You will also need to correct pathnames for your installation. The unedited files all have "mike" in their pathnames.

  3. In "rungms" set the NCPUS variable to the number of cores to use.

To run the 44 example data sets, use the runall command. Please refer to the ddi/readme.ddi file for more information. If you have TCP troubles running the test codes, try starting the debug process be changing instances of "`hostname`" to "localhost" in "runall".

Verifying Correctness

The file "TESTS.DOC" gives a full explanation on verifying the example program's output. The abbreviated version is as follows. The "INPUT CARD" portion of each log file contains some expected values. You need to search the output to see if these values match the actual output. Note that there are difference between the log file's expected answer and the "TESTS.DOC" file's expected answers. You should use the log file's expected values. Also, there might be slight precision variances between the actual and expected values. Precision can change depending upon your system and compiler optimization. See the Precision FAQ for more information.

Known Issues and Limitations

None

Click me