[gmx-developers] Test case for single node

[Szilárd Páll]

Hi Guido,

On Mon, Feb 1, 2021 at 5:34 PM Guido Giuntoli <guido.giuntoli at huawei.com>
wrote:

> Hi,
>
>
>
> I am searching for representative input cases for GROMACS for performance
> evaluation.
>
>
>
> The selection criteria is centered on (priority order):
>
> 1.       inputs that are good representatives for the GROMACS  user
> community
>
> 2.       desirable to run in a single node (approx. 96 ARM cores /
> CPU-only) in no more than 1 hour
>
Note that a molecular dynamics simulation consists of many consecutive
iterations that (typically) have the same average computational cost over
time. As iterations are short (milliseconds or less), reliable benchmarking
can generally be done in relatively short wall-time. Typically, running a
few minutes long benchmarks is sufficient, assuming that there are no other
external factors with longer timescales that impact performance, e.g.
system temperature stabilization and related clock throttling.

The run lengths can be controlled using the command line, see
https://manual.gromacs.org/current/user-guide/mdrun-features.html#controlling-the-length-of-the-simulation

One typical command line invocation for a 5 minute benchmark with counter
resetting is:
gmx mdrun -nsteps -1 -maxh 0.083 -resethway

3.       makes good use of the memory system and exploits well the SIMD
> units (NEON and possibly SVE)
>
Molecular dynamics simulations, in particular those in the interest to a
large part of the GROAMCS community run in the strong scaling regime where
all working sets typically fit in at most L3 (or often L2) caches.

> Currently I have in mind 2 inputs cases:
>
> 1.       The “*ion channel”* that belongs to the Unified European
> Applications Benchmark Suite (UEABS). This input seems to be a good
> representative for the industry of proteins and polymer simulation (
> https://hpc.nih.gov/apps/gromacs/).
>
> 2.       The “*nonbonded-benchmark*” which is integrated inside GROMACS.
> The benchmark would allow analyzing different problem sizes and internal
> kernels (
> https://manual.gromacs.org/documentation/current/onlinehelp/gmx-nonbonded-benchmark.html
> ).
>
Those are reasonable, but given my above point regarding strong scaling, do
to make sure you focus on the right parallelization regime (so it is
representative of real-world use). Unless you run in a heterogeneous setup
(CPU+GPU), the main regime of interest is 50-1000 atoms/core (and the
~milliseconds per iteration performance). Hence, for a 96-core server, the
relevant use-cases will be in the 5000-100000 (at most 100000) atoms. The
"ion channel" case is on the larger end of this range.

I would appreciate some guidance or feedback about these two inputs cases
> and suggestions for considering. Are there good representatives of what the
> community normally use when they run GROMACS? Are there special parameters
> (such as time steps or problem size, etc.) to take into account for finally
> saying that the simulations are good examples of normal GROMACS executions?
>

Further test cases you can find here: https://zenodo.org/record/3893789

Cheers,
--
Szilárd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20210210/3e2c2fd7/attachment-0003.html>