GAMESS-US: Difference between revisions

From Alliance Doc
Jump to navigation Jump to search
No edit summary
Line 2: Line 2:
[[Category:Software]]
[[Category:Software]]


The General Atomic and Molecular Electronic Structure System (GAMESS)<ref name="homepage">GAMESS-US Homepage: http://www.msg.ameslab.gov/gamess/</ref>  
The General Atomic and Molecular Electronic Structure System (GAMESS)
is a general ab ''initio quantum'' chemistry package.
<ref name="homepage">GAMESS Homepage: http://www.msg.ameslab.gov/gamess/</ref>  
is a general ''ab initio'' quantum chemistry package.




== Running GAMESS ==  
== Running GAMESS ==  


Our Clusters are using the Slurm scheduler; for details about submitting jobs, see [[Running jobs]].
=== Job Submission ===
Our Clusters are using the Slurm scheduler; for details about submitting jobs,  
see [[Running jobs]].


First step is to prepare a GAMESS input file containing the molecular geometry and run parameters.
First step is to prepare a GAMESS input file containing the molecular geometry  
Please refer to the GAMESS Documentation<ref name="gamess-docs">GAMESS Documentation: http://www.msg.ameslab.gov/gamess/documentation.html</ref>
and run parameters. Please refer to the GAMESS Documentation
and particularly Chapter 2 "Input Description"<ref name="gamess-input">GAMESS: Input Description (PDF): http://www.msg.ameslab.gov/gamess/GAMESS_Manual/input.pdf</ref> for a description the file format and all available keywords.
<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 all available 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; both input file and job script must be in the same directory.
Besides your input file (in our example name.inp), you have to prepare a job  
script to define the compute resources for the job; both input file and job  
script must be in the same directory.


{{File
{{File
Line 21: Line 29:
   |contents=
   |contents=
#!/bin/bash
#!/bin/bash
#SBATCH --cpus-per-task=2       # Number of CPUs
#SBATCH --cpus-per-task=1       # Number of CPUs
#SBATCH --mem-per-cpu=2000M    # memory per CPU in MB
#SBATCH --mem-per-cpu=2000M    # memory per CPU in MB
#SBATCH --time=0-00:30          # time (DD-HH:MM)
#SBATCH --time=0-00:30          # time (DD-HH:MM)
export SLURM_CPUS_PER_TASK
## uncomment the following 2 lines to use network $SCRATCH
#export USRSCR="$SCRATCH/gamess_${SLURM_JOB_ID}/"
#mkdir -p $USRSCR


module load gamess-us/20170420-R1
module load gamess-us/20170420-R1
Line 29: Line 42:
rungms name.inp  &>  name.out
rungms name.inp  &>  name.out
}}
}}
=== Running GAMESS on multiple CPUs ===
GAMESS calculations can make use of more than one CPU. The number of CPUs
used for a calculation is controlled by the <code>--cpus-per-task</code>
setting in the submission script.
As GAMESS has been built using the "sockets" parallelization, it can only
use CPU cores that are located on the same compute node and therefore
the maximum number of CPU cores that can be used for a job is dictated by
the node configuraion of the system (e.g. 32 CPU cores per node on Graham).
Quantum chemistry calculations are known to not scale as well across
many CPUs as compared to e.g. classical molecular mechanics, which means
that they can't use large numbers of CPUs efficiently.  Exactly how many
CPUs can be utilized efficiently, depends on the size of a system (i.e.
number of atoms, number of basis functions and level of theory).
To determine a reasonable number of CPUs to use, one needs to run a scaling
test - that is running the same input file using different numbers of CPUs
and comparing the execution time.  Ideally the exection time should be half
as long when using twice as many CPUs (= 100% speedup).
Obviously it is not a good use of resources when a calculation runs only 30%
faster when doubling the number of CPUs and in extreme cases calculations
can become even slower when further increasing the number of CPUs.


== References ==
== References ==
<references />
<references />

Revision as of 14:13, 8 March 2018


This article is a draft

This is not a complete article: This is a draft, a work in progress that is intended to be published into an article, which may or may not be ready for inclusion in the main wiki. It should not necessarily be considered factual or authoritative.

The General Atomic and Molecular Electronic Structure System (GAMESS) [1] is a general ab initio quantum chemistry package.


Running GAMESS

Job Submission

Our Clusters are using the Slurm scheduler; for details about submitting jobs, see Running jobs.

First step is to prepare a GAMESS input file containing the molecular geometry and run parameters. Please refer to the GAMESS Documentation [2] and particularly Chapter 2 "Input Description"[3]

for a description the file format and all available 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; both input file and job script must be in the same directory.


File : gamess_job.sh

#!/bin/bash
#SBATCH --cpus-per-task=1       # Number of CPUs
#SBATCH --mem-per-cpu=2000M     # memory per CPU in MB
#SBATCH --time=0-00:30          # time (DD-HH:MM)

export SLURM_CPUS_PER_TASK
## uncomment the following 2 lines to use network $SCRATCH
#export USRSCR="$SCRATCH/gamess_${SLURM_JOB_ID}/"
#mkdir -p $USRSCR

module load gamess-us/20170420-R1

rungms name.inp  &>  name.out


Running GAMESS on multiple CPUs

GAMESS calculations can make use of more than one CPU. The number of CPUs used for a calculation is controlled by the --cpus-per-task setting in the submission script. As GAMESS has been built using the "sockets" parallelization, it can only use CPU cores that are located on the same compute node and therefore the maximum number of CPU cores that can be used for a job is dictated by the node configuraion of the system (e.g. 32 CPU cores per node on Graham).

Quantum chemistry calculations are known to not scale as well across many CPUs as compared to e.g. classical molecular mechanics, which means that they can't use large numbers of CPUs efficiently. Exactly how many CPUs can be utilized efficiently, depends on the size of a system (i.e. number of atoms, number of basis functions and level of theory).

To determine a reasonable number of CPUs to use, one needs to run a scaling test - that is running the same input file using different numbers of CPUs and comparing the execution time. Ideally the exection time should be half as long when using twice as many CPUs (= 100% speedup). Obviously it is not a good use of resources when a calculation runs only 30% faster when doubling the number of CPUs and in extreme cases calculations can become even slower when further increasing the number of CPUs.


References