* MP2: Split mp2_ri_get_sizes * Split mp2_ri_create_group * MP2: Call mp2_ri_get_integ_group_size outside of the loops The determined parameters are only calculated once * Split mp2_ri_allocate * Check replication explicitly This step prepares larger replication group sizes for open shell systems * Move some deallocation outside of the loop * Move Postprocessing of Gamma_P_ia outside of the loop * Interchange loops * Move more routines outside of the loops * Carry out dereplication at the end * Collect bits of P_ab afterwards * Interchange order of case in open-shell systems * Carry out replication only once * Remove unused variable * Save a dereplication step in the open-shell case * Split two lines * Correctly determine an adequate integral replication size * Set lower limit to integration group size Reduces communication from replication * Extend open-shell MP2 to block sizes larger than one * Chose a more suitable block size than just 1 * Several fixes * Consider more memory * Fix open-shell systems * Allocate memory for exchange of Y_i_aP only once * Preallocate buffers instad of reallocating them Reduces the memoryfootprint because it takes some time for the operating system to know that freed memory is actually free. * Use the same block size everywhere * Allocate memory only if necessary * Make pointers contiguous * Use for MP2+ADMM and double hybrid tests an automatic block size * Further adjustment memory management * Improve description of group size and abort if it is not a divisor of the number of MPI ranks * Use one central buffer for recv and send operations * Use automatic block sizes with single-node benchmark * Minor adjustments to memory management * MP2: Use available buffer for nearly degenerate occ-occ pairs * Skip estimation of left computation time in MP2 for the very first step |
||
|---|---|---|
| .. | ||
| Fayalite-FIST | ||
| QMMM_CBD_PHY | ||
| QMMM_ClC | ||
| QMMM_MQAE | ||
| QS | ||
| QS_diag | ||
| QS_DM_LS | ||
| QS_LiH_HFX | ||
| QS_low_scaling_GW | ||
| QS_mp2_rpa | ||
| QS_ot_ls | ||
| QS_pao_ml_tio2 | ||
| QS_rubri | ||
| QS_single_node | ||
| QS_stmv | ||
| README.md | ||
CP2K Benchmarks
This directory contains input files for CP2K's benchmarks.
For measurements from different machines, please refer to CP2K benchmark suite, and for documentation on CP2K's input files, please refer to the Input Reference Manual. Python scripts for generating the scaling graphs are provided in tools/benchmark_plots/.
Note: the benchmark names make common use of acronyms. For explanations, please refer to the Glossary of Acronyms and Abbreviations.
Introduction
The purpose of the CP2K benchmark suite is to provide performance which can be used to guide users towards the best configuration (e.g. machine, number of MPI processors, number of OpenMP threads) for a particular problem, and give a good estimation for the parallel performance of the code for different types of methods.
The systems used to obtain the benchmark results are described on the systems page.
Benchmarks
See the README.md inside each benchmark sub-directory for descriptions of each
benchmark along with performance numbers.
Benchmarks currently available:
- Fayalite-FIST
- QS
- QS_DM_LS
- QS_HFX
- QS_diag
- QS_mp2_rpa
- QS_ot_ls
- QS_pao_ml_tio2
- QS_rubri
- QS_single_node
- QS_stmv
Run Benchmarks
Some benchmarks require a preliminary step to generate an input file, e.g. a
wavefunction. When that is the case, it is specified in the README.md inside
the benchmark's sub-directory.
The general way to run the benchmarks with the hybrid parallel executable is, e.g. for 2 threads per rank:
export OMP_NUM_THREADS=2
parallel_launcher launcher_options path_to_cp2k.psmp -i inputfile.inp -o logfile.log
where:
- The parallel_launcher is mpirun, mpiexec, or some variant such as aprun on Cray systems or srun when using Slurm.
launcher_optionsspecifies parallel placement in terms of total numbers of nodes, MPI ranks/tasks, tasks per node, and OpenMP threads per task (which should be equal to the value given to OMP_NUM_THREADS). This is not necessary if parallel runtime options are picked up by the launcher from the job environment.
Obtain Benchmark Results
The reported walltime for a given run can be obtained by querying the resulting
.log file for CP2K's internal timing, as follows:
grep "CP2K " *.log
Moreover, the end of the resulting .log files contains some performance numbers:
DBCSR STATISTICS: statistics on DBCSR's computation and communication performance. First few lines: number of flops spent on different small dense block sizes, and which proportion of them ran on BLAS, Small Matrix-Matrix multiplicator (SMM), and GPU (ACC).DBCSR MESSAGE PASSING PERFORMANCE: statistics on MPI calls in DBCSRMESSAGE PASSING PERFORMANCE: statistics on MPI calls in CP2KT I M I N G: timing and number of calls of CP2K functions
Plotting
Python scripts for generating the scaling graphs are provided in cp2k/tools/benchmark_plots/.
Contributing
We encourage you to contribute benchmark results from your own local cluster or HPC system - just run the inputs and add timings in the relevant sections below. Please also update the list of machines for which benchmark data is provided.