You are here

Gaussian

Table of Contents

Introduction

WestGrid has acquired a full commercial license for Gaussian 09 (G09). Gaussian software is available for use by all approved WestGrid account holders, subject to some license restrictions (see User Responsibilities below). As of May 6, 2011, WestGrid moved the Gaussian license from the Checkers cluster to the Grex cluster. The license is being renewed on annual basis. 

Note: In addition to using the WestGrid-licensed Gaussian 09 installation on Grex, University of Alberta users may apply to use Gaussian 03 or Gaussian 09 on machines operated by Academic Information and Communication Technologies. Contact research.support@ualberta.ca for more information. Similarly University of Calgary researchers may apply to use Gaussian 03 on local U of C resources by contacting support@hpc.ucalgary.ca. There is also a University of Manitoba campus license for Gaussian 03, which applies to the covered users and the Grex cluster only; to access, contact support@westgrid.ca.

User Responsibilities and Access

Due to licensing restrictions, researchers must agree to certain conditions in order to use Gaussian software on WestGrid systems. Follow the directions given here to apply. Users are expected to be generally familiar with Gaussian capabilities, input file format and the use of restart files. Also, please read the Efficiency Considerations section of the Gaussian 09 Online Manual in order to learn about memory and disk requirements of different types of computations.

There is also system-specific information given in the following sections that is important for effective use of Gaussian.

Note: inappropriate use of the memory-related parameters can cause jobs not to start, to fail, or prevent the batch scheduler from using the system efficiently.

System Characteristics and Limitations

Gaussian is available to approved WestGrid users on grex.westgrid.ca. See the Grex QuickStart Guide for an overview of the Grex cluster.

Parallel job limitations

The Linda parallel environment is not available on this system, so a parallel job is restricted to at most the twelve processor cores on a single node.

File system issues

By default, if the Gaussian environment is initialized by an appropriate module command (described below), the Gaussian scratch directory will be automatically assigned to use the most appropriate file system. However, due to the large size of restart files associated with some Gaussian analyses it is also important to ensure that all Gaussian jobs be started from under /global/scratch/<your_username>. Do not run your jobs from /home/<your_username>. Instead, copy your input files to your directory under /global/scratch, cd to that directory and then submit your job with qsub from there.

To avoid overloading the file server, do not include a %RWF directive of the form:

%RWF=read_write_file.rwf

in your Gaussian input file. Including such a directive places the frequently-accessed temporary "read/write file" in the job's current working directory. Leaving this directive out of the input file would put the rwf file in a job-specific temporary directory in a local file system on the execution node. This yields better performance for the Gaussian job and takes the load off the file server. It is usually necessary to include a %CHK directive in order to save the checkpoint file, but it is seldom necessary to save the RWF file.

Using Gaussian

Job Submission

Gaussian 09 is available to WestGrid users only on grex.westgrid.ca. Like other jobs on WestGrid systems, Gaussian jobs are run by submitting an appropriate script for batch scheduling using the qsub command. A sample script, gaussian.pbs, is shown further down on this page. For example, to submit a serial Gaussian job with a time limit of 168 hours (one week), use

qsub -l walltime=168:00:00 gaussian.pbs

See the Grex QuickStart Guide and the Running Jobs page for more information about submitting jobs on Grex.

Job Time Limit and Restart (Checkpoint) Files

At the time of writing, the maximum time limit for Gaussian jobs on Grex is 21 days (504 hours). The -l flag with the walltime option, as shown on the qsub command above, is used to request a specific limit on the elapsed time for the job. The format is qsub -l walltime=hhh:mm:ss for a given number of hours (hhh), minutes (mm) and seconds (ss).

To avoid lost work if there is an interruption during a long job, it is recommended that a checkpoint file be specified in your Gaussian input file, using the %chk Link0 directive on top of the input (just above the so called "root" section that starts with #) :

%chk=your_job_name.chk
%mem=2000mb
%nproc=2
# opt freq b3lyp/6-31g(d,p) gfprint iop(6/7=5)
...input title, charge/multiplicity etc. follow as required...

If you underestimated the time required for the job or if it was stopped due to a system problem (other than a disk failure!), you may be able to use the your_job_name.chk file to continue the calculation in a subsequent job.

Matching TORQUE and Gaussian Memory Limits

The Gaussian Link0 input directive %mem=[Gaussian_memory] can be used to increase the internal memory allocation for the Gaussian program, where, for example, Gaussian_memory=1600MB. For both G09 and G03 the amount of memory used by Gaussian can be significantly more than requested by %mem. This can cause the scheduler to assign jobs to nodes that do not have sufficient memory, which can lead to job failures and conflicts with other users' jobs.

The amount of extra memory used varies for different job types, and can be up to about 300-500 MB per process thread, or even higher, thus increasing with the amount requested. For example, if you used %mem=1600MB, you should tell TORQUE that your job needs 2000 MB, but, if you request %mem=3000MB, TORQUE should be advised that the job needs 3700 MB or more.

The mem option is used with the -l flag on the qsub command line to tell TORQUE how much memory the job requires. It can be combined with the walltime option as shown in this example:

qsub -l walltime=200:00:00,mem=3000MB gaussian.pbs

Running Parallel Gaussian Jobs

Some of the analyses available in the Gaussian suite support parallel processing. If you have not previously run parallel Gaussian jobs, please ask your colleagues for advice on which kind of analyses work well in parallel, or do some short test runs to compare the elapsed time as you increase the number of processors from 1 to 2 (or up to 12). No more than 12 processors may be used for a single Gaussian job on Grex.

To request a parallel calculation, use the %nproc directive in your Gaussian command file. For example to request two processor cores:

%nproc=2

As with the memory, it is not sufficient to tell only Gaussian how many processors you wish to use. TORQUE must also be told so that the batch job handling system assigns your job the correct number of processors. This is done using the nodes=1:ppn=... option of the -l flag on the qsub command line. For example:

qsub -l walltime=100:00:00,mem=2000MB,nodes=1:ppn=2 gaussian.pbs

In the example, ppn stands for processors per node. Two processors were requested. The number of nodes requested should always be one for Gaussian jobs. Please ensure that a colon, not a comma, is used to separate the nodes=1 from the ppn.

Administrators have noticed that users sometimes forget to add the memory and processor directives on the qsub command line. As noted on the Running Jobs page, you can add these directives to the batch job script instead, with lines of the form:

#PBS -l mem=2000MB
#PBS -l nodes=1:ppn=2

This is also illustrated in the sample job below.

Sample TORQUE Job Script for Running G09

The script below is an example of what gaussian.pbs might look like. Modify the lines containing your_g09_input.com and your_g09_output_name to reference your own input file and to give a descriptive name of your Gaussian output file, correspondingly.

#!/bin/bash
#PBS -S /bin/bash
#PBS -l mem=2000MB
#PBS -l nodes=1:ppn=2
# Adjust the mem and ppn above to match the requirements of your job

# Sample Gaussian job script

cd $PBS_O_WORKDIR

echo "Current working directory is `pwd`"
echo "Running on `hostname`"
echo "Starting run at: `date`"

# Set up the Gaussian environment using the module command:
module load gaussian

# Run g09
g09 < your_g09_input.com > your_g09_output_name_${PBS_JOBID}.out

Note the use of the module command to set up the environment for running Gaussian. The module would set the GAUSS_SCRDIR environment variable to a suitable location; there is usually no need to set it explicitly in your script. General information about modules is available on the WestGrid modules page.

Simplified G09 Job Submission Script

There is a script named pbsg09 that helps to automate TORQUE job creation and submission tasks. The manual editing of the job scripts, as above, is the most flexible way of using it. However, for most of the common Gaussian tasks the script can be recommended, for it takes care of matching of the resource requests for TORQUE job and Gaussian input. The job file with all its #PBS directives as discussed above, as well as %mem, %chk and %nproc directives are created automatically by the script based on user's command line input. (Consequently, this means that you should not create these entries explicitly in your input).

pbsg09 your_g09_input.gjf -ppn 2 -mem 2000MB -time 100:00:00

The pbsg09 command is available after you load the Gaussian module (module load gaussian) on Grex's login server. Note that it assumes that your input file has a .gjf extension (although .com will probably would work too), and expects the input file name to be the first parameter. The script does not work with compound (--Link 1--) Gaussian jobs yet. One can obtain futher information by using the pbsg09 -help command.

Using formchk

To run formchk interactively, to convert Gaussian output to a form suitable for transfer to another system, you should initialize the Gaussian environment in a manner similar to what is done in the batch job example above.

module load gaussian
formchk input.chk output.fchk

Converting files from Gaussian 03

If you have checkpoint files generated using Gaussian 03, these can be converted for use with Gaussian 09 on Grex using a utility, c8609, supplied with Gaussian 09. This command-line utility accepts one argument, the file name or path to the file to be converted. Note that the conversion occurs in-place, overwriting the input file. If you would like to retain the original input file, make a copy of it before running c8609. As explained in more detail below, the module command should be run to set up your environment.

Example of using c8609 interactively on Grex to convert an old checkpoint file, water.chk, to a format suitable for Gaussian 09:

module load gaussian
cp water.chk water.chk.old
c8609 water.chk

 

For More Information

Updated 2014-01-16 - only cosmetic changes.