Running
GaussianThis page describes the operating system commands required to
execute Gaussian on Unix-based computer systems. See the additional instructions
accompanying the program for the equivalent information for other operating systems.
This discussion assumes that the program has already been installed. The final
section lists the component links of the Gaussian 03 program. Running
Gaussian involves the following activities: Creating Gaussian
input describing the desired calculation. Specifying the locations
of the various scratch files. Specifying resource requirements. Initiating
program execution, in either interactive or batch mode. In this
page, we will assume that a basic Gaussian input file has been created,
and our discussion will examine the remaining three items on the list.

Gaussian uses several scratch
files in the course of its computation. They include: The Checkpoint
file: name.chk The Read-Write file: name.rwf The
Two-Electron Integral file: name.int The Two-Electron
Integral Derivative file: name.d2e
By default, these files are given a name generated from the process ID
of the Gaussian process, and they are stored in the scratch directory,
designated by the GAUSS_SCRDIR environment variable (UNIX).
You may also see files of the form name.inp
in this directory. These are the internal input files used by the
program. If the environment variable is unset, the location defaults to
the current working directory of the Gaussian process.
By default, these files are deleted
at the end of a successful run. However, you may wish to save the checkpoint file
for later use in another Gaussian job, for use by a visualization program,
to restart a failed job, and so on. This may be accomplished by naming
the checkpoint file, providing an explicit name and/or location for it, via a
%Chk command within the Gaussian input
file. Here is an example:
%Chk=water
This command, which is
placed at the beginning of the input file (before the route section-see chapter
3 for details), gives the checkpoint file the name water.chk, overriding
the usual generated name and causing the file to be saved at job conclusion. In
this case, the file will reside in the current directory. However, a command like
this one will specify an alternate directory location as well as filename:
%Chk=/chem/scratch2/water
If disk space in the scratch directory is
limited, but space is available elsewhere on the system, you may want to split
the scratch files among several disk locations. The following commands allow you
to specify the names and locations of the other scratch files:
%RWF=path Read-Write file
%Int=path Integral file
%D2E=path Integral Derivative file
In general,
the read-write file is by far the largest, and so it is the one for which an alternate
location is most often specified. Splitting Scratch Files Across DisksAn
alternate syntax is provided for splitting the Read-Write file, the Integral file,
and/or the Integral Derivative file among two or more disks (or file systems).
Here is the syntax for the %RWF command: %RWF=loc1,size1,loc2,size2,
... where each loc is a directory location or a file pathname, and
each size is the maximum size for the file segment at that location. Gaussian
will automatically generate unique filenames for any loc which specifies
a directory only. On UNIX systems, directory specifications (without filenames)
must include a terminal slash. By default, the sizes are in units of words;
the value may be followed by KB, MB or GB (without intervening
spaces) to designate KB, MB or GB, respectively, or by KW, MW or
GW to indicate units of kilowords, megawords or gigawords, respectively.
Note that 1 MB = 10242 bytes = 1,048,576 bytes (not 1,000,000 bytes). A
value of -1 for any size parameter indicates that any and all available
space may be used, and a value of 0 says to use the current size of an
existing segment. -1 is useful only for the last file specified, for which
it is the default. For example, the following directive splits the Read-Write
file across three disks:
%RWF=/dalton/s0/,60MW,/scratch/,800MB,/temp/s0/my_job,-1
The maximum sizes for the file segments are 480 MB, 800 MB, and unlimited,
respectively. Gaussian will generate names for the first two segments,
and the third will be given the name my_job. Note that the directory specifications
include terminal slashes. Due to limitations in current UNIX implementations,
-1 should be used with caution, as it will attempt to extend a file segment
beyond all remaining disk capacity on these systems; using it will also have the
side effect of keeping any additional file segments included in the list from
ever being used. Saving and Deleting Scratch FilesBy default, unnamed
scratch files are deleted at the end of the Gaussian run, and named files
are saved. The %NoSave command may be used to change this default behavior.
When this directive is included in an input file, named scratch files whose directives
appear in the input file before %NoSave will be deleted at the end
of a run (as well as all unnamed scratch files). However, if the % directive
naming the file appears after the %NoSave directive, the file will
be retained. For example, these commands specify a name for the checkpoint file,
and an alternate name and directory location for the read-write file, and cause
only the checkpoint file to be saved at the conclusion of the Gaussian
job:
%RWF=/chem/scratch2/water Files to be deleted go here.
%NoSave
%Chk=water Files to be saved go here.
Initialization FilesThe Gaussian system includes initialization
files to set up the user environment for running the program. These files are:
$g03root/g03/bsd/g03.login C shell
$g03root/g03/bsd/g03.profile Bourne shell
Note that the g03root environment variable must
be set up by the user. Thus, it is customary to include lines like the following
within the .login or .profile file for Gaussian users:
.login files:
setenv g03root location
source $g03root/g03/bsd/g03.login
.profile files:
g03root=location
export g03root
. $g03root/g03/bsd/g03.profile
Once things are set up correctly, the g03 command is used to
execute Gaussian 03 (see below).

The
%Mem command controls the amount of dynamic memory to be used by Gaussian.
By default, 6 megawords are used. This can be changed to n double-precision
words by specifying:
%Mem=n
For example, the following command sets memory use to 64 million bytes:
%Mem=8000000
The value given to %Mem may also be followed by KB,
KW, MB, MW, GB or GW (no intervening spaces)
to denote other units. For example, the following command also sets the amount
of dynamic memory to 64 MB:
%Mem=64MB
Even larger allocations
may be needed for very large direct SCF calculations, at least 3N2
words, where N is the number of basis functions. Frequency and post-SCF
calculations involving f functions should be given 6 MWords if possible. Using
more than 6 million words for moderate-sized calculations (i.e., a direct SCF
with less than 500 basis functions) does not improve performance on most systems.
Warning:
Requesting more memory than the amount of physical memory actually available
on a computer system will lead to very poor performance. If Gaussian
is being used on a machine with limited physical memory, so that the default of
48 MB is not available, the default algorithms as well as the default memory allocation
should be set appropriately during installation. See this
page for more details on using Gaussian efficiently.

Once all input and resource specifications are
prepared, you are ready to run the program. Gaussian 03 may be run
interactively using one of two command styles:
g03 job-name
g03 <input-file >output-file
In the first form,
the program reads input from job-name.com and writes its output
to job-name.log. When job-name is not specified, the program
reads from standard input and writes to standard output, and these can be redirected
or piped in the usual UNIX fashion. Either form of command can be forced in the
background in the same manner as any shell command using &. Scripts
and Gaussian Scripts designed to run Gaussian 03 may also
be created in several ways (we will use the C shell in these examples). First,
g03 commands like those above may be included in a shell script. Secondly,
actual Gaussian input may be included in the script using the <<
construct:
#!/bin/csh
g03 <<END >water.log
%Chk=water
#RHF/6-31G(d)
water energy
0 1
O
H 1 1.0
H 1 1.0 2 120.0
END
echo "Job done. "
All
lines preceding the string following the << symbols are taken as
input to the g03 command. Finally, loops may be created to run several
Gaussian jobs in succession. For example, the following script runs all
of the Gaussian input files specified as its command line arguments, and
it maintains a log of its activities in the file Status:
#!/bin/csh
echo "Current Job Status:" > Status
foreach file ($argv)
echo "Starting file $file at `date`" >> Status
g03 < $file > $file:r.log
echo "$file Done with status $status" >> Status
end
echo "All Done." >> Status
The following more complex script creates Gaussian input files on-the-fly
from the partial input in the files given as the script's command line arguments.
The latter are lacking full route sections; their route sections consist of simply
a # sign or a # line containing special keywords needed for that molecular system,
but no method, basis set, or calculation type. The script creates a two-step
job for each partial input file-a Hartree-Fock optimization followed by an MP2
single point energy calculation-consisting of both the literal commands included
in the script and the contents of each file specified at script execution time.
It includes the latter by exploiting the Gaussian 03 @ include
file mechanism:
#!/bin/csh
echo "Current Job Status:" > Status
foreach file ($argv)
echo "Starting file $file at `date`" >> Status
g03 <<END> $file:r.log
%Chk=$file:r
# HF/6-31G(d) FOpt
@$file/N
--Link1--
%Chk=$file:r
%NoSave
# MP2/6-31+G(d,p) SP Guess=Read Geom=AllCheck
END
echo "$file Done with status $status" >> Status
end # end of foreach
echo "All Done." >> Status
Batch Execution with NQSGaussian
may be run using the NQS batch facility on those UNIX systems that support it.
The subg03 command, defined in the initialization files, submits an input
file to a batch queue. It has the following syntax:
subg03 queue-name job-name [-scrdir dir1] [-exedir dir2] [-p n]
The two required parameters are the queue and job
names. Input is taken from job-name.com and output goes to job-name.log,
just as for interactive runs. The NQS log file is sent to job-name.batch-log.
The optional parameters -scrdir and -exedir are used to override
the default scratch and executable directories, respectively. Any other parameters
are taken to be NQS options. In particular, -p n can be used to
set the priority within the queue to n. This is priority for initiation
(1 being lowest), and does not affect the run-time priority. To submit an
NQS job from an interactive session, a file like the following should be created
(with filename name.job):
# QSUB -r name -o name.out -eo
# QSUB -lt 2000 -lT 2100
# QSUB -lm 7mw -lM 7mw
g03 <name.com
where name should be replaced with a name that is appropriate to your
calculation. The first line names the running job, names the output file, and
causes errors to be included in the output file. The time parameters are different
to allow addition of job control for cleanup, (for example, archiving the checkpoint
file in the event that the job exceeds its time limit). The memory parameters
are used both for initial scheduling of your job for execution and by the program
to determine dynamic memory use. This job would then be submitted by issuing
the command,
$ qsub name.job
and the output would be placed in your current working directory.

The following table lists the component programs of Gaussian
03—known as links—along with their primary functions:
| L0 | Initializes program and controls overlaying |
| L1 | Processes route section, builds list of links to execute,
and initializes scratch files | | L101 | Reads title
and molecule specification | | L102 | FP optimization |
| L103 | Berny optimizations to minima and TS, STQN transition
state searches | | L105 | MS optimization |
| L106 | Numerical differentiation of forces/dipoles to obtain
polarizability/ hyperpolarizability | | L107 | Linear-synchronous-transit
(LST) transition state search | | L108 | Potential
energy surface scan | | L109 | Newton-Raphson optimization |
| L110 | Double numerical differentiation of energies to produce
frequencies | | L111 | Double num. diff. of energies
to compute polarizabilities & hyperpolarizabilities | | L113 | EF
optimization using analytic gradients | | L114 | EF
numerical optimization (using only energies) | | L115 | Follows
reaction path using the intrinsic reaction coordinate (IRC) | | L116 | Numerical
self-consistent reaction field (SCRF) | | L117 | Post-SCF
SCRF | | L118 | Trajectory calculations |
| L120 | Controls ONIOM calculations | | L121 | ADMP
calculations | | L122 | Counterpoise calculations |
| L202 | Reorients coordinates, calculates symmetry, and checks
variables | | L301 | Generates basis set information |
| L302 | Calculates overlap, kinetic, and potential integrals |
| L303 | Calculates multipole integrals | | L308 | Computes
dipole velocity and Rx∇ integrals | | L310 | Computes
spdf 2-electron integrals in a primitive fashion | | L311 | Computes
sp 2-electron integrals | | L314 | Computes spdf 2-electron
integrals | | L316 | Prints 2-electron integrals |
| L319 | Computes 1-electron integrals for approximate spin
orbital coupling | | L401 | Forms the initial MO guess |
| L402 | Performs semi-empirical and molecular mechanics calculations |
| L405 | Initializes an MCSCF calculation | | L502 | Iteratively
solves the SCF equations (conven. UHF & ROHF, all direct methods, SCRF) |
| L503 | Iteratively solves the SCF equations using direct
minimization | | L506 | Performs an ROHF or GVB-PP
calculation | | L508 | Quadratically convergent SCF
program | | L510 | MC-SCF | | L601 | Population
and related analyses (including multipole moments) | | L602 | 1-electron
properties (potential, field, and field gradient) | | L604 | Evaluates
MOs or density over a grid of points | | L607 | Performs
NBO analyses | | L608 | Non-iterative DFT energies |
| L609 | Atoms in Molecules properties | | L701 | 1-electron
integral first or second derivatives | | L702 | 2-electron
integral first or second derivatives (sp) | | L703 | 2-electron
integral first or second derivatives (spdf) | | L716 | Processes
information for optimizations and frequencies | | L801 | Initializes
transformation of 2-electron integrals | | L802 | Performs
integral transformation (N3 in-core) | | L804 | Integral
transformation | | L811 | Transforms integral derivatives
& computes their contributions to MP2 2nd derivatives |
| L901 | Anti-symmetrizes 2-electron integrals |
| L902 | Determines the stability of the Hartree-Fock wavefunction |
| L903 | Old in-core MP2 | | L905 | Complex
MP2 | | L906 | Semi-direct MP2 | | L908 | OVGF
(closed shell) | | L909 | OVGF (open shell) |
| L913 | Calculates post-SCF energies and gradient terms |
| L914 | CI-Singles, RPA and Zindo excited states; SCF stability |
| L915 | Computes fifth order quantities (for MP5, QCISD(TQ)
and BD(TQ)) | | L916 | Old MP4 and CCSD |
| L918 | Reoptimizes the wavefunction | | L1002 | Iteratively
solves the CPHF equations; computes various properties (including NMR) |
| L1003 | Iteratively solves the CP-MCSCF equations |
| L1014 | Computes analytic CI-Singles second derivatives |
| L1101 | Computes 1-electron integral derivatives |
| L1102 | Computes dipole derivative integrals |
| L1110 | 2-electron integral derivative contribution to Fx |
| L1111 | 2 PDM and post-SCF derivatives | | L1112 | MP2
second derivatives | | L9999 | Finalizes calculation
and output | |