You are here


Table of Contents


WestGrid has acquired a full commercial license for Gaussian starting with version 09. The 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. On Grex, the Gaussian 09 releases from B.01 to E.01 as well as the most recent Gaussian 16 release A.03 are available. 

Note: In addition to using the WestGrid-licensed Gaussian 09 installation on Grex, University of Alberta users can use Gaussian 09 on Jasper and on Hungabee without requesting access.  Hungabee itself, however, requires a request to access the system. 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

Watch a WestGrid Seminar Series "Case Study: Molecular Modelling Using HPC and Gaussian" where Dr. Gino DiLabio, an Adjunct Professor in the Department of Physics at the University of Alberta highlights some of the top computational challenges his lab encounters and how his use of Gaussian on WestGrid computing facilities helps his research team overcome them.

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 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 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:


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.

For the same reason, it is never a good idea to define GAUSS_SCRDIR environment variable in your scripts. Instead, loading the appropriate Gaussian environment module will set the variable to the most appropriate location, in local /scratch or /global/scratch .

Using Gaussian

Job Submission

As of the time of writing, Gaussian versions of 09 and 16 are available to WestGrid users only on Loading an appropriate Gaussian module for a given Gaussian version/release gives access to the g09 command which is the main driver executable for the Gaussian suite of programs. Note that for Gaussian 16 the main program's name changes to g16; however, on Grex we provide a symlink to g09 for this version so that old scripts relying on the g09 name would still work. For now, the default Gaussian module on Grex still points to the recent G09.E01 version rather than to G16.A03 one. Interactive use of g09/g16 should be limited only to small test calculations. Like all the other production 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. See also the 'Simplified Gaussian Job Submission Script'  below.

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 #) :

# 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 G16 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. Linda workers are not available on Grex, so the jobs can use, at most, a single whole node.

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


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/G16

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

#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


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 g16
g16 < > your_g16_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. Specifying module name as per the above without explicit version loads the default modulefile which is g09.e01. In order to access Gaussian 16, replace the module load gaussian line with module load gaussian/g16.a03 in the script above.  Also change g09 to g16 whereever it appears.

Simplified Gaussian Job Submission Script

There is a script named pbsg16 (pbsg09 for Gaussian 09) 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 many of the common Gaussian tasks using 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).

pbsg16 your_gaussian_input.gjf -ppn 2 -mem 2000MB -time 100:00:00

The pbsg16 (pbsg09 for Gaussian 09)  command is available after you load the Gaussian module (module load gaussian or module load gaussian/g16.a03) 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 or pbsg16 -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

Using NBO6 with Gaussian 09 D.01

Starting from Gaussian 09 D.01, Gaussian can use binary version of NBO6 without recompiling Gaussian. Westgrid made NBO6 available on Grex. To use it with Gaussian, first access to the NBO6 code should be obtained as described on the NBO software page; then, after loading Gaussian module, the NBO module has to be loaded ( module load nbo/6.0 ). This makes Pop=NPA6, Pop=NBO6, Pop=NBO6Read and Pop=NBO6Delete keywords working in Gaussian calculations. 

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 2015-09-25 - Added NBO6 paragraph, added GAUSS_SCRDIR prohibition.
Updated 2017-02-01 - Modified to accommodate Gaussian 16.
Updated 2017-05-27 - Changed default example to Gaussian 16.

System Grex
Version G16 B.01 G09 D.01