Gaussian is a general purpose suite of electronic structure programs. Versions g16c01 is installed. It is available as binaries only. The source code is not available on the CSF.<\/p>\n
Gaussian 09 is not currently installed on CSF4. Please contact us via our help form<\/a> if you require access to this version (it is<\/em> installed on CSF3).<\/p>\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 G16 has been been installed on CSF with optimized versions for the different Intel compute 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 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:<\/p>\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 Gaussian uses an environment variable It is set to your scratch<\/em> directory ( Please either leave the A faster, but smaller, local 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 We now recommend using a different scratch directory for each job. 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 The example jobscripts below show how to use this method (it is simple – just two extra lines in your jobscript). The two lines are:<\/p>\n Occasionally some jobs create 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 It is recommended you run from within your Create a job script, for example:<\/p>\n Submit with the command:<\/p>\n where scriptname<\/em> is the name of your job script.<\/p>\n When the job has finished check whether Gaussian has left behind unwanted scratch files (you’ll need to know the job id). For example, assuming your job id was 456789:<\/p>\n On the CSF Gaussian is a multi-threaded application (shared memory) only, so a job will not<\/strong> run across multiple compute nodes. Hence you are limited to a maximum of 40 cores. This means that you must<\/em> run in the Follow the steps below to submit a parallel Gaussian job.<\/p>\n Old method<\/strong>: We used<\/em> to advise setting the number of cores to use for a job in the Gaussian input file using New method<\/strong>: We now recommend setting the For example, depending which shell<\/em> you use (look at the first line of your jobscript to find out):<\/p>\n Remember that Note: It is recommended you run from within your Create a job script, for example:<\/p>\n Submit with the command:<\/p>\n where scriptname<\/em> is the name of your job script.<\/p>\n Gaussian has two environment variables that can be used to say how many cores to use. We saw the The The Reminder: the Gaussian is a general purpose suite of electronic structure programs. Versions g16c01 is installed. It is available as binaries only. The source code is not available on the CSF. Gaussian 09 is not currently installed on CSF4. Please contact us via our help form if you require access to this version (it is installed on CSF3). Restrictions on use The University of Manchester site license allows access for all staff and students of the university,.. Read more »<\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"parent":49,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-551","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf4\/wp-json\/wp\/v2\/pages\/551","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf4\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf4\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf4\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf4\/wp-json\/wp\/v2\/comments?post=551"}],"version-history":[{"count":17,"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf4\/wp-json\/wp\/v2\/pages\/551\/revisions"}],"predecessor-version":[{"id":1382,"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf4\/wp-json\/wp\/v2\/pages\/551\/revisions\/1382"}],"up":[{"embeddable":true,"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf4\/wp-json\/wp\/v2\/pages\/49"}],"wp:attachment":[{"href":"https:\/\/ri.itservices.manchester.ac.uk\/csf4\/wp-json\/wp\/v2\/media?parent=551"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Restrictions on use<\/h2>\n
Set up procedure<\/h2>\n
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 for all of your job runs, there are also modulefiles to select a specific version.<\/p>\n# NOTE: CSF4 ONLY CONTAINS CASCADE LAKE NODES. WE RECOMMEND USING THE _detectcpu\r\n# OR THE _haswell MODULEFILES FOR BEST PERFORMANCE. The other modulefiles\r\n# match those available on CSF3 and will use the same level of optimization\r\n# as used on CSF3.\r\n\r\n# This can ONLY be loaded inside your jobscript. It won't load on the login node.\r\nmodule load 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\r\n# in the jobscript (recommended). Less optimized to most optimized:\r\nmodule load gaussian\/g16c01_em64t # Nehalem\/Westmere (SSE4.2) any node\r\n\r\nmodule load gaussian\/g16c01_em64t_nehalem # (as above)\r\n\r\nmodule load gaussian\/g16c01_em64t_sandybridge # For Sandybridge (AVX), Ivybridge, Haswell,\r\n # Broadwell, Skylake, Cascade Lake nodes\r\n\r\nmodule load gaussian\/g16c01_em64t_haswell # For Haswell (AVX2), Broadwell, Skylake\r\n # and Cascade Lake nodes\r\n<\/pre>\n
g16<\/code> on the login nodes. Computational work found to be running on the login nodes will be killed WITHOUT WARNING<\/strong>.<\/p>\nGaussian Scratch<\/h2>\n
$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~\/scratch<\/code>) when you load the modulefile (scratch<\/em> is a fast filesystem with good I\/O performance.)<\/p>\n$GAUSS_SCRDIR<\/code> at the default setting or, if you wish to set it to a job-specific directory, ensure you use a directory inside your scratch area (see below for how to do this.) DO NOT use your CSF home directory<\/em> or any additional Research Data Storage that you may have access to for the $GAUSS_SCRDIR<\/code>.<\/p>\n\/tmp<\/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 size of \/tmp<\/code> on all compute nodes is 800GB.<\/p>\nUsing a Scratch Directory per Job<\/h3>\n
scratch<\/code> area. It is also then easy to delete the entire directory if Gaussian has left unwanted scratch files behind.<\/p>\nexport GAUSS_SCRDIR=\/scratch\/$USER\/gau_temp_$SLURM_JOB_ID\r\nmkdir -p $GAUSS_SCRDIR\r\n<\/pre>\n
Very large Gaussian scratch files<\/h3>\n
.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 file request that the .rwf<\/code> file be split into multiple files. For example to split the file into two 3TB files:<\/p>\n%rwf=\/scratch\/$USER\/myjob\/one.rwf,3000GB,\/scratch\/$USER\/myjob\/two.rwf,3000GB\r\n<\/pre>\n
Serial batch job<\/h2>\n
Example job submission<\/h3>\n
scratch<\/code> area and use one directory per job:<\/p>\ncd ~\/scratch\r\nmkdir job1\r\ncd job1\r\n<\/pre>\n
\n
#!\/bin\/bash --login\r\n#SBATCH -p serial # (or --partition) Single-core job\r\n#SBATCH -n 1 # (or --ntasks=) Number of cores (always 1)\r\n\r\n# Load g16 for the CPU type our job is running on\r\nmodule load gaussian\/g16c01_em64t_detectcpu\r\n\r\n## Set up scratch dir (please do this!)\r\nexport GAUSS_SCRDIR=\/scratch\/$USER\/gau_temp_$SLURM_JOB_ID\r\nmkdir -p $GAUSS_SCRDIR\r\n\r\n## Say how much memory to use (max on CSF4 is 4GB per core)\r\nexport GAUSS_MDEF=$((SLURM_NTASKS*4))GB\r\n\r\n$g16root\/g16\/g16 < file.inp > file.out\r\n<\/pre>\n<\/li>\n
#!\/bin\/csh\r\n#SBATCH -p serial # (or --partition) Single-core job\r\n#SBATCH -n 1 # (or --ntasks=) Number of cores (always 1)\r\n\r\n# Load g16 for the CPU type our job is running on\r\nmodule load gaussian\/g16c01_em64t_detectcpu\r\n\r\n# Set up scratch dir (please do this!)\r\nsetenv GAUSS_SCRDIR \/scratch\/$USER\/gau_temp_$SLURM_JOB_ID\r\nmkdir -p $GAUSS_SCRDIR\r\n\r\n## Say how much memory to use (max on CSF4 is 4GB per core)\r\n@ mem = ( $SLURM_NTASKS * 4 )\r\nsetenv GAUSS_MDEF ${mem}GB\r\n\r\n$g16root\/g16\/g16 < file.inp > file.out\r\n<\/pre>\n<\/li>\n<\/ul>\nsbatch scriptname<\/em><\/pre>\n
cd ~\/scratch\/gau_temp_456789\r\nls\r\nGau-21738.inp Gau-21738.chk Gau-21738.d2e Gau-21738.int Gau-21738.scr\r\n\r\n# Example: Remove a specific scratch file\r\nrm Gau-21738.scr\r\n\r\n# Example: Remove all files in the directory (use with caution)\r\nrm Gau*\r\n\r\n# Example: go up and remove the empty directory\r\ncd ..\r\nrmdir gau_temp_456789\r\n<\/pre>\n
Parallel batch job<\/h2>\n
multicore<\/code> partition<\/em> to confine your job to a single node.<\/p>\nImportant Information About Requesting cores<\/h3>\n
#SBATCH -n<\/code> request in your jobscript and<\/em> using a Gaussian specific environment variable, also set in the jobscript. See below for further details and examples.<\/div>\n%NProcsShared<\/code> or %nprocs<\/code>. But this can easily lead to mistakes – if you change the number of cores in the jobscript but forget to also change it in the Gaussian input file you will either use too few cores (some of the cores your job requested are sat idle) or too many cores (your job is trying to use cores it shouldn’t, possibly trampling on another user’s job).<\/p>\nGAUSS_PDEF<\/code> environment variable in your jobscript (set it to $SLURM_NTASKS<\/code>) so that it always tells Gaussian the correct number of cores to use. This also means you don’t have to keep editing your Gaussian input file each time you want to run the input deck with a different number of cores.<\/p>\n# If using BASH (the default shell used by most CSF users):\r\nexport GAUSS_PDEF=$SLURM_NTASKS\r\n\r\n# If using CSH (the 'traditional' shell used by chemistry users):\r\nsetenv GAUSS_PDEF $SLURM_NTASKS\r\n<\/pre>\n
$SLURM_NTASKS<\/code> is automatically set by the batch system to the number of cores you requested on the #SBATCH -n<\/code> line in the jobscript. Hence there is only one number-of-cores to change if you want to run the job with a different number of cores.<\/p>\n%NProcShared<\/code> in the input file takes precedence over GAUSS_PDEF<\/code>, so one could override the latter by setting %NProcShared<\/code> in the input file. If you are using our recommended method of setting GAUSS_PDEF<\/code> in the jobscript, please remove any %NProcShared<\/code> line from your Gaussian input files.<\/p>\nExample job submission<\/h3>\n
#SBATCH -n<\/code> request in your jobscript and using a Gaussian specific variable, also set in the jobscript. See the above explanation for further details.<\/div>\nscratch<\/code> area and use one directory per job:<\/p>\ncd ~\/scratch\r\nmkdir job1\r\ncd job1\r\n<\/pre>\n
\n
#!\/bin\/bash --login\r\n#SBATCH -p multicore # (or --partition) Single-node multicore\r\n#SBATCH -n 20 # (or --ntasks=) Number of cores (2--40)\r\n\r\n# Load g16 for the CPU type our job is running on\r\nmodule load gaussian\/g16c01_em64t_detectcpu\r\n\r\n## Set up scratch dir (please do this!)\r\nexport GAUSS_SCRDIR=\/scratch\/$USER\/gau_temp_$SLURM_JOB_ID\r\nmkdir -p $GAUSS_SCRDIR\r\n\r\n## Say how much memory to use (4GB per core)\r\nexport GAUSS_MDEF=$((SLURM_NTASKS*4))GB\r\n\r\n## Inform Gaussian how many cores to use\r\nexport GAUSS_PDEF=$SLURM_NTASKS\r\n\r\n$g16root\/g16\/g16 < file.inp > file.out\r\n<\/pre>\n<\/li>\n
#!\/bin\/csh \r\n#SBATCH -p multicore # (or --partition) Single-node multicore\r\n#SBATCH -n 20 # (or --ntasks=) Number of cores (2--40)\r\n\r\n# Load g16 for the CPU type our job is running on\r\nmodule load gaussian\/g16c01_em64t_detectcpu\r\n\r\n# Set up scratch dir (please do this!)\r\nsetenv GAUSS_SCRDIR \/scratch\/$USER\/gau_temp_$SLURM_JOB_ID\r\nmkdir -p $GAUSS_SCRDIR\r\n\r\n## Say how much memory to use (4GB per core)\r\n@ mem = ( $SLURM_NTASKS * 4 )\r\nsetenv GAUSS_MDEF ${mem}GB\r\n\r\n## Inform Gaussian how many cores to use\r\nsetenv GAUSS_PDEF $SLURM_NTASKS\r\n\r\n$g16root\/g16\/g16 < file.inp > file.out\r\n<\/pre>\n<\/li>\n<\/ul>\nsbatch scriptname<\/em><\/pre>\n
GAUSS_PDEF vs GAUSS_CDEF<\/h3>\n
GAUSS_PDEF<\/code> variable above. Alternatively the GAUSS_CDEF<\/code> variable can be set but this must only<\/em> be used when you are using all<\/em> of the cores on a compute node. If you are unsure whether your job does this, please use the GAUSS_PDEF<\/code> variable as shown above.<\/p>\nGAUSS_CDEF<\/code> variable may<\/em> give increased performance because it pins g16<\/code> threads<\/em> (used to do the parallel processing in Gaussian) to specific CPU cores. Without pinning Linux is free to move the threads between cores, although it tries not to do this. When a thread is moved it invalidates the low-level memory caches which may reduce performance.<\/p>\nGAUSS_CDEF<\/code> variable uses a slightly different format to the GAUSS_PDEF<\/code> variable, as shown below:<\/p>\n#SBATCH -p multicore # (or --partition) Single-node multicore\r\n#SBATCH -n 40 # (or --ntasks=) Use all 40 cores in a cascade lake node\r\n\r\n# Say which cores to use, e.g., 0-39 (BASH shell):\r\nexport GAUSS_CDEF=0-$((SLURM_NTASKS-1))\r\n\r\n# Say which cores to use, e.g., 0-39 (C shell):\r\n@ maxcore = ( $SLURM_NTASKS - 1 )\r\nsetenv GAUSS_CDEF 0-$maxcore\r\n<\/pre>\n
GAUSS_CDEF<\/code> variable should only be used when you are using all<\/em> cores on a compute node. Jobs found to be using this variable incorrectly will be killed without warning because you will be slowing down other users’ jobs.<\/p>\nFurther info<\/h2>\n
\n