{"id":4844,"date":"2020-11-23T17:42:56","date_gmt":"2020-11-23T17:42:56","guid":{"rendered":"http:\/\/ri.itservices.manchester.ac.uk\/csf3\/?page_id=4844"},"modified":"2025-08-07T14:00:44","modified_gmt":"2025-08-07T13:00:44","slug":"gaussian16","status":"publish","type":"page","link":"https:\/\/ri.itservices.manchester.ac.uk\/csf3\/software\/applications\/gaussian16\/","title":{"rendered":"Gaussian 16"},"content":{"rendered":"

Gaussian<\/a> is a general purpose suite of electronic structure programs.<\/p>\n

Versions g16c01 (and g16a03) are installed on the CSF. They are available as binaries only. The source code is not available on the CSF.<\/p>\n

Gaussian 09 is also available on the CSF<\/a>.
\nGaussian 16 Linda (multi-node) available on the CSF<\/a>.<\/p>\n

Restrictions on use<\/h2>\n

The University of Manchester site license allows access for all staff and students of the university, however strict licensing restrictions are in place. Access to this software is not automatic.<\/p>\n

Please contact us via our help form<\/a> to request access to Gaussian 16.<\/p>\n

Set up procedure<\/h2>\n

G16 has been been installed on CSF with optimized versions for the different Intel com pute node architectures. In general a less optimized version will run on more compute nodes. But a more optimized version requires newer architectures and so will not run on older compute nodes.<\/p>\n

The detectcpu<\/code> modulefile will use the best version for the compute node your job is running on. This modulefile must be loaded inside your jobscript, not on the login node. If you prefer to use exactly the same version for all of your job runs, there are also modulefiles to select a specific version.<\/p>\n

After being added to the relevant unix group, you will be able to access the executables by loading the modulefile<\/p>\n

For G16 C01<\/h3>\n
# This can ONLY be loaded inside your jobscript. It won't load on the login node.<\/strong>\r\nmodule load apps\/binapps\/gaussian\/g16c01_em64t_detectcpu    # Detects the CPU type and uses the\r\n                                                            # fastest version for that CPU\r\n\r\n# These can be loaded on the login node and inherited by your job or loaded in the jobscript.<\/strong>\r\n# Least optimized to most optimized:\r\nmodule load apps\/binapps\/gaussian\/g16c01_em64t              # Nehalem\/Westmere (SSE4.2) any node\r\n\r\nmodule load apps\/binapps\/gaussian\/g16c01_em64t_nehalem      # (as above)\r\n\r\nmodule load apps\/binapps\/gaussian\/g16c01_em64t_sandybridge  # For Sandybridge (AVX), Ivybridge,\r\n                                                            # Haswell, Broadwell, Skylake nodes\r\n\r\nmodule load apps\/binapps\/gaussian\/g16c01_em64t_haswell      # For Haswell (AVX2), Broadwell and\r\n                                                            # Skylake nodes\r\n<\/pre>\n
For G16 C01 with Dipole Moments Output<\/h3>\n
This version uses a modified l914.exe<\/code> to allow it to output Dipole Moments, which are not normally output.<\/p>\n
# This can ONLY be loaded inside your jobscript. It won't load on the login node.<\/strong>\r\nmodule load apps\/binapps\/gaussian\/g16c01_em64t_dm<\/strong>_detectcpu    # Detects the CPU type and uses the\r\n                                                               # fastest version for that CPU\r\n\r\n# These can be loaded on the login node and inherited by your job or loaded in the jobscript.<\/strong>\r\n# Least optimized to most optimized:\r\nmodule load apps\/binapps\/gaussian\/g16c01_em64t_dm<\/strong>              # Nehalem\/Westmere (SSE4.2) any node\r\n\r\nmodule load apps\/binapps\/gaussian\/g16c01_em64t_dm<\/strong>_nehalem      # (as above)\r\n\r\nmodule load apps\/binapps\/gaussian\/g16c01_em64t_dm<\/strong>_sandybridge  # For Sandybridge (AVX), Ivybridge,\r\n                                                               # Haswell, Broadwell, Skylake nodes\r\n\r\nmodule load apps\/binapps\/gaussian\/g16c01_em64t_dm<\/strong>_haswell      # For Haswell (AVX2), Broadwell and\r\n                                                               # Skylake nodes\r\n<\/pre>\n
G16 A03<\/h3>\n
Note: we strongly<\/strong> recommend using the more recent versions above.<\/p>\n
# Replace the c01 part of the modulefile name with a03 in the above modulefiles. For example:\r\nmodule load apps\/binapps\/gaussian\/g16a03_em64t_detectcpu\r\n<\/pre>\n
We recommend you do this in your jobscript, see examples below (not on the command line before job submission as per the previous CSF2).<\/p>\n
Gaussian MUST ONLY<\/strong> be run in batch. Please DO NOT<\/strong> run g16<\/code> on the login nodes. Computational work found to be running on the login nodes will be killed WITHOUT WARNING<\/strong>.<\/p>\n
Gaussian Scratch<\/h2>\n
Gaussian uses an environment variable $GAUSS_SCRDIR<\/code> to specify a directory path for where to write scratch<\/em> (temporary) files (two-electron integral files, integral derivative files and a read-write<\/em> file for temporary workings).<\/p>\n
It is set to your scratch<\/em> directory (~\/scratch<\/code>) when you load the modulefile. This is a Lustre filesystem which provides good I\/O performance. Do not be tempted to use your home directory for Gaussian scratch files – the files can be huge, making the home area at risk of going over quota. So this gives you a sensible default location for temp files if you wish. But we advise how you can use a better setting below.<\/p>\n
Using a Scratch Directory per Job<\/h3>\n
We recommend using a different scratch directory for each job<\/strong>. This improves file access times if you run many jobs – writing 1000s of scratch files to a single directory can slow down your jobs. It is much better to create a directory for each<\/em> job within your scratch<\/code> area. It is also then easy to delete the entire directory if Gaussian has left unwanted scratch files behind.<\/p>\n
\r\n# In the jobscript:\r\nexport GAUSS_SCRDIR=\/scratch\/$USER\/gau_temp_$SLURM_JOB_ID\r\nmkdir -p $GAUSS_SCRDIR\r\n<\/pre>\n
See below for example jobscripts<\/a> that do this.<\/p>\n
Using a node-local directory<\/h3>\n
A faster, but smaller, local $TMPDIR<\/code> on each compute node is available should users prefer to use that. It can be more efficient if you have a need to create lots of small files, but space is limited. The AMD 168-core Genoa nodes in the multicore<\/code> partition all have a 1.6TB local disk. Use this with caution – if you fill the local disk, your job will crash!<\/strong>.<\/p>\n
\r\n# Slurm creates the temp $TMPDIR. FOR SMALL FILES ONLY.<\/strong>\r\n# It also deletes the folder (and all files) at the end of the job.\r\n# You should take a copy of any files from this area within your jobscript<\/em>.\r\n# You will NOT have access to this temp area after the job has finished.\r\nexport GAUSS_SCRDIR=$TMPDIR\r\n<\/pre>\n
If your job writes a huge .rwf<\/code>, say, then it will likely run out of space in this area and your job will crash. <\/p>\n
Cleaning up scratch files<\/h3>\n
Gaussian should<\/em> delete scratch files automatically when a job completes successfully or dies cleanly. However, it often fails to do this. Scratch files are also not<\/em> deleted when a job is killed externally or terminates abnormally so that you can use the scratch files to restart the job (if possible). Consequently, leftover files may accumulate in the scratch directory, and it is your responsibility to delete these files. Please check periodically<\/strong> whether you have a lot of temporary Gaussian files that can be deleted.<\/p>\n
Very large Gaussian scratch files<\/h3>\n
Occasionally some jobs create .rwf<\/code> files which are very large (several TB). The batch system will not permit a job to create files bigger than 4TB. If your gaussian job fails and the .rwf<\/code> file is 4TB then it may be that this limit has prevented your job from completing. You should re-run the job and in your input<\/strong> file request that the .rwf<\/code> file be split into multiple files. For example to split the file into two 3TB files add the following Link 0 line at the upper part of your input file:<\/p>\n
%rwf=\/scratch\/myusername\/myjob\/one.rwf,3000GB,\/scratch\/myusername\/myjob\/two.rwf,3000GB\r\n<\/pre>\n
Serial batch job<\/h2>\n
In the examples below we give example jobscripts using the BASH shell (the default used by most CSF users) and also the C shell, which is popular amongst computational chemists.<\/p>\n
Example job submission<\/h3>\n
It is recommended you run from within your scratch<\/code> area and use one directory per job:<\/p>\n
cd ~\/scratch\r\nmkdir job1\r\ncd job1\r\n<\/pre>\n
Create a job script, for example:<\/p>\n