GROMACS

Our recommendation: Follow these three steps to get the fastest program:

1. Use the most recent version of GROMACS that we provide or build your own.
2. Use the newest Hardware: use 1 GPU on the partitions zen2_0256_a40x2 or zen3_0512_a100x2 on VSC-5.
3. Do some performance analysis to decide if a single GPU Node (likely) or multiple CPU Nodes via MPI (unlikely) better suits your problem.

In most cases it does not make sense to run on multiple GPU nodes with MPI; Whether using one or two GPUs per node.

First you have to decide on which hardware GROMACS should run, we call this a partition, described in detail at SLURM. On any login node, type sinfo to get a list of the available partitions, or take a look at vsc4_queue and vsc5_queue. We recommend the partitions zen2_0256_a40x2 or zen3_0512_a100x2 on VSC-5; they have plenty nodes available with 2 GPUs each. The partition has to be set in the batch script, see the example below. Be aware that each partition has different hardware, so choose the parameters accordingly. GROMACS decides mostly on its own how it wants to work, so don't be surprised if it ignores settings like environment variables.

Type spack find -l gromacs or module avail gromacs on cuda-zen/zen/skylake spack trees on VSC-5/4. You can list available variants with spack: spack find -l gromacs +cuda or spack find -l gromacs +mpi.

Because of the low efficiency of GROMACS on many nodes with many GPUs via MPI, we do not provide gromacs + cuda + mpi.

We provide the following GROMACS variants:

We recommend GPU Nodes, use the cuda-zen spack tree on VSC-5:

cuda-zen:

• Gromacs +cuda ~mpi, all compiled with GCC

Since the gromacs + cuda packages do not have MPI support, there is no gmx_mpi binary, only gmx.

For Gromacs on CPU only but with MPI, use zen spack tree on VSC-5 or skylake on VSC-4:

zen:

• Gromacs +openmpi +blas +lapack ~cuda, all compiled with GCC
• Gromacs +openmpi +blas +lapack ~cuda, all compiled with AOCC

skylake:

• Gromacs +openmpi +blas +lapack ~cuda, all compiled with GCC
• Gromacs +openmpi +blas +lapack ~cuda, all compiled with Intel
• Gromacs +intelmpi +blas +lapack ~cuda, all compiled with GCC
• Gromacs +intelmpi +blas +lapack ~cuda, all compiled with Intel

In some of these packages, there is no gmx binary, only gmx_mpi, but this also works on one single node.

Write a batch script (example below) including:

• some SLURM parameters: the #BATCH … part)
• export environment variables: e.g. export CUDA_VISIBLE_DEVICES=0
• clean modules: module purge
• load modules: module load gromacs/2022.2-gcc-9.5.0-…
• starting the program in question: gmx …

mybatchscript.sh

#!/bin/bash
#SBATCH --job-name=myname
#SBATCH --partition=zen2_0256_a40x2
#SBATCH --qos=zen2_0256_a40x2
#SBATCH --gres=gpu:1
 
unset OMP_NUM_THREADS
export CUDA_VISIBLE_DEVICES=0
 
module purge
module load gromacs/2022.2-gcc-9.5.0-...
gmx mdrun -s topol.tpr

Type sbatch myscript.sh to submit such your batch script to SLURM. you get the job id, and your job will be scheduled and executed automatically.

There is a whole page dedicated to monitoring the CPU and GPU, for GROMACS the relevant sections are section Live and GPU.

As a short example we ran gmx mdrun -s topol.tpr with different options, where topol.tpl is just some sample topology, we don't actually care about the result, we just want to know how many ns/day we can get, GROMACS tells you that at the end of every run. Such a short test can be done in no time.

The following table lists our 5 tests: Without any options GROMACS already runs fine (a). Setting the number of tasks (b) is not needed; if set wrong can even slow the calculation down significantly ( c ) due to over provisioning! We would advise to enforce pinning, in our example it does not show any effects though (d), we assume that the tasks are pinned automatically already. The only further improvement we could get was using the -update gpu option, which puts more load on the GPU (e).

Since GROMACS is used in many and very different ways, it makes sense to benchmark various scenarios:

1. R-143a in hexane (20,248 atoms) with very high output rate
2. a short RNA piece with explicit water (31,889 atoms)
3. a protein inside a membrane surrounded by explicit water (80,289 atoms)
4. a VSC users test case (50,897 atoms)
5. a protein in explicit water (170,320 atoms)
6. a protein membrane channel with explicit water (615,924 atoms)
7. a huge virus protein (1,066,628 atoms)

Take a look at the test results resembling a similar case than your application.

In this chart we tested our various hardware on the 7 test cases, some recent GPUs like A100 GPU Nodes on VSC-5, some belong to VSC-3 (like GTX1080, K20), and are not accessible anymore:

In most cases 1 GPU is better than 2 GPUs!

In some cases, for example a large molecule like Test 7, you might want to run GROMACS on both GPUs. We strongly encourage you to test if you actually benefit from running with GPUs on many nodes.

To find out if more GPUs mean more work done we need some math: the parallel efficiency η is the ratio of the speedup factor S(N) and the number of processors N:

η = S(N) / N

In this chart we compare GROMACS parallel efficiency η of the 7 test cases with two GPU versus one GPU on VSC-5 A40 and A100 Nodes. Ideally two GPUs would bring a speedup S of 2, but also a N of 2, so the parallel efficiency would be 1. In reality, the speedup will be less than 1; and so will be the efficiency. An efficiency 0.45 for example means that with two GPUs, more than half the used resources were wasted! Because of the high demand on our GPU Nodes we kindly ask to test your case, and only use more than 1 GPU, if your efficiency is above 0.5.

Set the number of GPUs on the node visible to GROMACS with export CUDA_VISIBLE_DEVICES=0 for one GPU or export CUDA_VISIBLE_DEVICES=0,1 for both GPUs.

In most cases one node is better than more nodes.

In some cases, for example a large molecule like Test 7, you might want to run GROMACS on multiple nodes in parallel using MPI, with multiple GPUs (one each node). We strongly encourage you to test if you actually benefit from running with GPUs on many nodes. GROMACS can perform worse on many nodes in parallel than on a single one, even considerably!

Run GROMACS on multiple nodes with:

#SBATCH --nodes 2
gmx mdrun ...

Take a look at the chapter Dual GPU Scaling Efficiency to find out if more nodes are a good idea. In the below examples the efficiency is very low, even for the large test cases 6 and 7.

Note: the computation timed out for 4 with 32 nodes, before gromacs was able to estimate a performance. We can safely assume this example case is going to be less performant on 32 than on fewer nodes too.

Quick summary:

• Most problems (Small): 1 or 2 ranks per node
• Large problem: 8 ranks per node

If you want to run GROMACS on multiple nodes and multiple GPUs in parallel using MPI, best tell MPI how many processes should be launched on each node –map-by ppr:1:node. MPI would normally use many ranks, which is good for CPUs, but bad with GPUs! We encourage you to test a few number of ranks yourself with your specific application. Based on our tests listed in the following chart we recommend 1 ranks per node for most (small) problems, and only for large problems up to 8 ranks per node:

#SBATCH --nodes 2
mpirun -np 16 \
       --map-by ppr:8:node \
       ...
       gmx_mpi mdrun ...

The reason for this is that the graphics cards does more work than the CPU. GROMACS needs to copy data between different ranks on the CPUs and all GPUs, which takes more time with more ranks. GROMACS notices that and shows Wait GPU state copy at the end of the log. As an example our test 1 with 16 ranks on 1 node: the Wait GPU state copy amounts to 44.5% of the time spent!

The benchmarks are based on three articles of NHR@FAU, featuring in depth analysis on GROMACS Performance on various GPU systems, multi GPU setups and comparison with CPU:

https://hpc.fau.de/2022/02/10/gromacs-performance-on-different-gpu-types/

https://hpc.fau.de/2021/08/10/gromacs-shootout-intel-icelake-vs-nvidia-gpu/

https://hpc.fau.de/2021/06/18/multi-gpu-gromacs-jobs-on-tinygpu/