GAMESS-US: Difference between revisions

<translate>

[[Category:Software]]

The General Atomic and Molecular Electronic Structure System (GAMESS)

<ref name="homepage">GAMESS Homepage: http://www.msg.ameslab.gov/gamess/</ref>  

is a general ''ab initio'' quantum chemistry package.

Compute Canada clusters use the Slurm scheduler. For more about submitting and monitoring jobs,  

see [[Running jobs]].

The first step is to prepare a GAMESS input file containing the molecular geometry and a specification of the calculation to be carried out.  Please refer to the GAMESS Documentation <ref name="gamess-docs">Documentation: http://www.msg.ameslab.gov/gamess/documentation.html</ref>

and particularly Chapter 2 "Input Description"<ref name="gamess-input">Input Description (PDF): http://www.msg.ameslab.gov/gamess/GAMESS_Manual/input.pdf</ref> for a description the file format and keywords.

Besides your input file (in our example, "name.inp"), you have to prepare a job script to define the compute resources for the job. Input file and job script must be in the same directory.

{{File

   |name=gamess_job.sh

#SBATCH --time=0-00:30          # time (DD-HH:MM)

export SLURM_CPUS_PER_TASK

## Uncomment the following two lines to use /scratch instead of local disk

#mkdir -p $SCR

module load gamess-us/20170420-R1

rungms name.inp  &>  name.out

}}

Use the following command to submit the job to the scheduler:

By default, scratch files will be written to local disk on the compute node. We expect this to give the best performance. If there is insufficient space on local disk, you can use /scratch instead by setting the <code>SCR</code> environment variable as shown in the comments in the example above.

GAMESS calculations can make use of more than one CPU. The number of CPUs  

available for a calculation is determined by the <code>--cpus-per-task</code>  

setting in the job script.  

As GAMESS has been built using [https://en.wikipedia.org/wiki/Unix_domain_socket sockets] for parallelization, it can only

use CPU cores that are located on the same compute node. Therefore  

the size of the nodes in the cluster, e.g. 32 CPU cores per node on [[Graham]].

Quantum chemistry calculations are known to not scale well to large numbers

of CPUs as compared to e.g. classical molecular mechanics, which means  

basis functions, and the level of theory.

To determine a reasonable number of CPUs to use, one needs to run a scaling  

test--- That is, run the same input file using different numbers of CPUs  

calculations to run slower when increasing the number of CPUs.

Quantum chemistry calculations are often "memory bound"--- meaning that

larger molecules at high level of theory need a lot of memory (RAM),  

results to free up memory, reading them back from disk later in the calculation.

Even our fastest SCRATCH storage is several orders of magnitudes slower

than the memory, so you should make sure to assign sufficient memory to GAMESS.

This is a two-step process:  

# Request memory for the job in the submission script. Using <code>--mem-per-cpu=4000M</code> is a reasonable value, since it matches the memory-to-CPU ratio on the base nodes. Requesting more than that may cause the job to wait to be scheduled on a large-memory node.

# In the <code>$SYSTEM group</code> of the input file, define the <code>MWORDS</code> and <code>MEMDDI</code> options.  This tells GAMESS how much memory it is allowed to use.  

#* <code>MWORDS</code> is the maximum replicated memory which a job can use, on every core. This is given in units of 1,000,000 words (as opposed to 1024*1024 words), and a word is defined as 64 bits = 8 bytes.  

#* <code>MEMDDI</code> is the grand total memory needed for the distributed data interface (DDI) storage, given in units of 1,000,000 words. The memory required on each processor core for a run using <tt>p</tt> CPU-cores is therefore <tt>MEMDDI/p + MWORDS</tt>.  

Please refer to the <code>$SYSTEM group</code> section in the GAMESS documentation<ref name="gamess-input" /> if you want more details.

It is important to leave a few hundred MB of memory between the memory requested from the scheduler and the memory that GAMESS is allowed to use, as a safety margin.  If the <code>slurm-{JOBID}.out</code> file contains a message like "slurmstepd: error: Exceeded step/job memory limit at some point",then Slurm has terminated the job for trying to use more memory than was requested. In that case one needs to either reduce the <code>MWORDS</code> or <code>MEMDDI</code> in the input file or increase the <code>--mem-per-cpu</code> in the submission script.

<references />

</translate>