comp-chem/cp2k
1
0
Fork 0
mirror of https://github.com/cp2k/cp2k.git synced 2026-07-28 06:05:29 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Format Markdown files to comply with Linter

Browse source
This commit is contained in:
Ole Schütt 2020-08-24 23:11:31 +02:00 • committed by Ole Schütt
parent e71e4793a6
commit 243f8aaefc
32 changed files with 1008 additions and 577 deletions
Download patch file Download diff file Expand all files Collapse all files

521
INSTALL.md
View file

@ -1,312 +1,483 @@
# How to compile the CP2K code
## 1. Acquire the code
## 1. Acquire the code
For users, the preferred method is to [download a release](https://github.com/cp2k/cp2k/releases/).
For developers, the preferred method is to [download from Git](./README.md#downloading-cp2k-source-code).
For more details on downloading CP2K, see https://www.cp2k.org/download.
For more details on downloading CP2K, see <https://www.cp2k.org/download>.
## 2. Install prerequisites
The most convenient way to install pre-requisites is by using the [toolchain script](./tools/toolchain/install_cp2k_toolchain.sh).
For a complete introduction to the toolchain script, see the [README for users](./tools/toolchain/README_FOR_USERS.md) or the [README for developers](./tools/toolchain/README_FOR_DEVELOPERS.md).
For a complete introduction to the toolchain script,
see the [README for users](./tools/toolchain/README_FOR_USERS.md)
or the [README for developers](./tools/toolchain/README_FOR_DEVELOPERS.md).
The basic steps are:
- Read toolchain installation options:
```
> cd tools/toolchain/
> ./install_cp2k_toolchain.sh --help
```shell
cd tools/toolchain/
./install_cp2k_toolchain.sh --help
```
- Launch toolchain script (example option choice)
```
> ./install_cp2k_toolchain.sh --with-libxsmm=install --with-openblas=system \
```shell
./install_cp2k_toolchain.sh --with-libxsmm=install --with-openblas=system \
--with-fftw=system --with-reflapack=no --enable-cuda --enable-omp
```
- Once the script has completed successfully, follow the instructions given at the end of its output.
Note that the pre-built arch files provided by the toolchain are for the GNU compiler, users have to adapt them for other compilers. It is possible to use the provided [arch files](./arch) as guidance.
- Once the script has completed successfully, follow the instructions given at
the end of its output. Note that the pre-built arch files provided by the
toolchain are for the GNU compiler, users have to adapt them for other compilers.
It is possible to use the provided [arch files](./arch) as guidance.
Sub-points here discuss prerequisites needed to build CP2K. Copies of the recommended versions of 3rd party software can be downloaded from https://www.cp2k.org/static/downloads/.
Sub-points here discuss prerequisites needed to build CP2K. Copies of the
recommended versions of 3rd party software can be downloaded from <https://www.cp2k.org/static/downloads/>.
### 2a. GNU make (required, build system)
GNU make should be on your system (gmake or make on linux) and used for the build, go to https://www.gnu.org/software/make/make.html download from https://ftp.gnu.org/pub/gnu/make/
GNU make should be on your system (gmake or make on linux) and used for the build,
go to <https://www.gnu.org/software/make/make.html> download from <https://ftp.gnu.org/pub/gnu/make/>.
### 2b. Python (required, build system)
Python 3.5+ is needed to run the dependency generator. On most system Python is already installed. For more information visit: https://www.python.org/
Python 3.5+ is needed to run the dependency generator. On most system Python is
already installed. For more information visit: <https://www.python.org>
### 2c. Fortran and C Compiler (required, build system)
A Fortran 2008 compiler and matching C99 compiler should be installed on your system. We have good experience with gcc/gfortran (gcc >=4.6 works, later version recommended). Be aware that some compilers have bugs that might cause them to fail (internal compiler errors, segfaults) or, worse, yield a mis-compiled CP2K. Report bugs to compiler vendors; they (and we) have an interest in fixing them. A list of tested compiler can be found [here](https://www.cp2k.org/dev:compiler_support). Always run a `make -j test` (See point 5.) after compilation to identify these problems.
A Fortran 2008 compiler and matching C99 compiler should be installed on your system.
We have good experience with gcc/gfortran (gcc >=4.6 works, later version recommended).
Be aware that some compilers have bugs that might cause them to fail (internal
compiler errors, segfaults) or, worse, yield a mis-compiled CP2K. Report bugs to
compiler vendors; they (and we) have an interest in fixing them. A list of tested
compiler can be found [here](https://www.cp2k.org/dev:compiler_support).
Always run a `make -j test` (See point 5.) after compilation to identify these problems.
### 2d. BLAS and LAPACK (required, base functionality)
BLAS and LAPACK should be installed. Using vendor-provided libraries can make a very significant difference (up to 100%, e.g., ACML, MKL, ESSL), not all optimized libraries are bug free. Use the latest versions available, use the interfaces matching your compiler, and download all patches!
* The canonical BLAS and LAPACK can be obtained from the Netlib repository:
* http://www.netlib.org/blas/
* http://www.netlib.org/lapack/ and see also
* http://www.netlib.org/lapack-dev/
* Open fast alternatives, include:
* http://www.openblas.net/
* http://math-atlas.sourceforge.net/
* https://www.tacc.utexas.edu/research-development/tacc-software/gotoblas2
BLAS and LAPACK should be installed. Using vendor-provided libraries can make a
very significant difference (up to 100%, e.g., ACML, MKL, ESSL), not all optimized
libraries are bug free. Use the latest versions available, use the interfaces
matching your compiler, and download all patches!
If compiling with OpenMP support then it is recommended to use a non-threaded version of BLAS. In particular if compiling with MKL and using OpenMP you must define `-D__MKL` to ensure the code is thread-safe. MKL with multiple OpenMP threads in CP2K requires that CP2K was compiled with the Intel compiler. If the `cpp` precompiler is used in a separate precompilation step in combination with the Intel Fortran compiler, `-D__INTEL_COMPILER` must be added explicitly (the Intel compiler sets `__INTEL_COMPILER` otherwise automatically).
- The canonical BLAS and LAPACK can be obtained from the Netlib repository:
- <http://www.netlib.org/blas/>
- <http://www.netlib.org/lapack/> and see also
- <http://www.netlib.org/lapack-dev/>
- Open fast alternatives, include:
- <http://www.openblas.net>
- <http://math-atlas.sourceforge.net>
- <https://www.tacc.utexas.edu/research-development/tacc-software/gotoblas2>
On the Mac, BLAS and LAPACK may be provided by Apple's Accelerate framework. If using this framework, `-D__ACCELERATE` must be defined to account for some interface incompatibilities between Accelerate and reference BLAS/LAPACK.
If compiling with OpenMP support then it is recommended to use a non-threaded
version of BLAS. In particular if compiling with MKL and using OpenMP you must
define `-D__MKL` to ensure the code is thread-safe. MKL with multiple OpenMP
threads in CP2K requires that CP2K was compiled with the Intel compiler.
If the `cpp` precompiler is used in a separate precompilation step in combination
with the Intel Fortran compiler, `-D__INTEL_COMPILER` must be added explicitly
(the Intel compiler sets `__INTEL_COMPILER` otherwise automatically).
When building on/for Windows using the Minimalist GNU for Windows (MinGW) environment, you must set `-D__MINGW`, `-D__NO_STATM_ACCESS` and `-D__NO_IPI_DRIVER` to avoid undefined references during linking, respectively errors while printing the statistics.
On the Mac, BLAS and LAPACK may be provided by Apple's Accelerate framework.
If using this framework, `-D__ACCELERATE` must be defined to account for some
interface incompatibilities between Accelerate and reference BLAS/LAPACK.
When building on/for Windows using the Minimalist GNU for Windows (MinGW) environment,
you must set `-D__MINGW`, `-D__NO_STATM_ACCESS` and `-D__NO_IPI_DRIVER` to avoid
undefined references during linking, respectively errors while printing the statistics.
### 2e. MPI and SCALAPACK (optional, required for MPI parallel builds)
MPI (version 2) and SCALAPACK are needed for parallel code. (Use the latest versions available and download all patches!).
:warning: Note that your MPI installation must match the used Fortran compiler. If your computing platform does not provide MPI, there are several freely available alternatives:
MPI (version 2) and SCALAPACK are needed for parallel code.
(Use the latest versions available and download all patches!).
* MPICH2 MPI: http://www-unix.mcs.anl.gov/mpi/mpich/
* OpenMPI MPI: http://www.open-mpi.org/
* ScaLAPACK:
* http://www.netlib.org/scalapack/
* http://www.netlib.org/lapack-dev/
* ScaLAPACK can be part of ACML or cluster MKL. These libraries are recommended if available.
* Recently a [ScaLAPACK installer](http://www.netlib.org/scalapack/scalapack_installer.tgz) has been added that simplifies the installation.
:warning: Note that your MPI installation must match the used Fortran compiler.
If your computing platform does not provide MPI,
there are several freely available alternatives:
CP2K assumes that the MPI library implements MPI version 3. If you have an older version of MPI (e.g. MPI 2.0) available you must define `-D__MPI_VERSION=2` in the arch file.
- MPICH2 MPI: <http://www-unix.mcs.anl.gov/mpi/mpich/>
- OpenMPI MPI: <http://www.open-mpi.org/>
- ScaLAPACK:
- <http://www.netlib.org/scalapack/>
- <http://www.netlib.org/lapack-dev/>
- ScaLAPACK can be part of ACML or cluster MKL.
These libraries are recommended if available.
- Recently a [ScaLAPACK installer](http://www.netlib.org/scalapack/scalapack_installer.tgz)
has been added that simplifies the installation.
CP2K assumes that the MPI library implements MPI version 3. If you have an older
version of MPI (e.g. MPI 2.0) available you must define `-D__MPI_VERSION=2` in
the arch file.
### 2f. FFTW (optional, improved performance of FFTs)
FFTW can be used to improve FFT speed on a wide range of architectures. It is strongly recommended to install and use FFTW3. The current version of CP2K works with FFTW 3.X (use `-D__FFTW3`). It can be downloaded from http://www.fftw.org/
:warning: Note that FFTW must know the Fortran compiler you will use in order to install properly (e.g., `export F77=gfortran` before configure if you intend to use gfortran).
FFTW can be used to improve FFT speed on a wide range of architectures.
It is strongly recommended to install and use FFTW3. The current version of CP2K
works with FFTW 3.X (use `-D__FFTW3`). It can be downloaded from <http://www.fftw.org>
:warning: Note that on machines and compilers which support SSE you can configure FFTW3 with `--enable-sse2`. Compilers/systems that do not align memory (NAG f95, Intel IA32/gfortran) should either not use `--enable-sse2` or otherwise set the define `-D__FFTW3_UNALIGNED` in the arch file. When building an OpenMP parallel version of CP2K (ssmp or psmp), the FFTW3 threading library libfftw3_threads (or libfftw3_omp) is required.
:warning: Note that FFTW must know the Fortran compiler you will use in order to
install properly (e.g., `export F77=gfortran` before configure if you intend to
use gfortran).
:warning: Note that on machines and compilers which support SSE you can configure
FFTW3 with `--enable-sse2`. Compilers/systems that do not align memory (NAG f95,
Intel IA32/gfortran) should either not use `--enable-sse2` or otherwise set the
define `-D__FFTW3_UNALIGNED` in the arch file. When building an OpenMP parallel
version of CP2K (ssmp or psmp), the FFTW3 threading library libfftw3_threads
(or libfftw3_omp) is required.
### 2g. LIBINT (optional, enables methods including HF exchange)
* Hartree-Fock exchange (optional, use `-D__LIBINT`) requires the libint package to be installed.
* Recommended way to build libint: Download a CP2K-configured libint library from [libint-cp2k](https://github.com/cp2k/libint-cp2k). Build and install libint by following the instructions provided there. Note that using a library configured for higher maximum angular momentum will increase build time and binary size of CP2K executable (assuming static linking).
* CP2K is not hardwired to these provided libraries and any other libint library (version >= 2.5.0) should be compatible as long as it was compiled with `--enable-eri=1` and default ordering.
* Avoid debugging information (`-g` flag) for compiling libint since this will increase library size by a large factor.
* In the arch file of CP2K: add `-D__LIBINT` to the `DFLAGS`. Add `-L$(LIBINT_DIR)/lib -lint2 -lstdc++` to `LIBS` and `-I$(LIBINT_DIR)/include` to `FCFLAGS`. `lstdc++` is needed if you use the GNU C++ compiler.
* Libint 1 is no longer supported and the previously needed flags `-D__LIBINT_MAX_AM` and `-D__LIBDERIV_MAX_AM1` are ignored.
* `-D__MAX_CONTR=4` (default=2) can be used to compile efficient contraction kernels up to l=4, but the build time will increase accordingly.
- Hartree-Fock exchange (optional, use `-D__LIBINT`)
requires the libint package to be installed.
- Recommended way to build libint: Download a CP2K-configured libint library
from [libint-cp2k](https://github.com/cp2k/libint-cp2k). Build and install
libint by following the instructions provided there. Note that using a library
configured for higher maximum angular momentum will increase build time and
binary size of CP2K executable (assuming static linking).
- CP2K is not hardwired to these provided libraries and any other libint
library (version >= 2.5.0) should be compatible as long as it was compiled
with `--enable-eri=1` and default ordering.
- Avoid debugging information (`-g` flag) for compiling libint since this will
increase library size by a large factor.
- In the arch file of CP2K: add `-D__LIBINT` to the `DFLAGS`.
Add `-L$(LIBINT_DIR)/lib -lint2 -lstdc++` to `LIBS` and `-I$(LIBINT_DIR)/include`
to `FCFLAGS`. `lstdc++` is needed if you use the GNU C++ compiler.
- Libint 1 is no longer supported and the previously needed flags
`-D__LIBINT_MAX_AM` and `-D__LIBDERIV_MAX_AM1` are ignored.
- `-D__MAX_CONTR=4` (default=2) can be used to compile efficient contraction
kernels up to l=4, but the build time will increase accordingly.
### 2h. libsmm (optional, improved performance for matrix multiplication)
* A library for small matrix multiplies can be built from the included source (see exts/dbcsr/tools/build_libsmm/README). Usually only the double precision real and perhaps complex is needed. Link to the generated libraries. For a couple of architectures prebuilt libsmm are available at https://www.cp2k.org/static/downloads/libsmm/.
* Add `-D__HAS_smm_dnn` to the defines to make the code use the double precision real library. Similarly use `-D__HAS_smm_snn` for single precision real and `-D__HAS_smm_znn` / `-D__HAS_smm_cnn` for double / single precision complex.
* Add `-D__HAS_smm_vec` to enable the new vectorized interfaces of libsmm.
- A library for small matrix multiplies can be built from the included source
(see exts/dbcsr/tools/build_libsmm/README). Usually only the double precision
real and perhaps complex is needed. Link to the generated libraries. For a
couple of architectures prebuilt libsmm are available at <https://www.cp2k.org/static/downloads/libsmm/>.
- Add `-D__HAS_smm_dnn` to the defines to make the code use the double precision
real library. Similarly use `-D__HAS_smm_snn` for single precision real and
`-D__HAS_smm_znn` / `-D__HAS_smm_cnn` for double / single precision complex.
- Add `-D__HAS_smm_vec` to enable the new vectorized interfaces of libsmm.
### 2i. libxsmm (optional, improved performance for matrix multiplication)
* A library for matrix operations and deep learning primitives: https://github.com/hfp/libxsmm/
* Add `-D__LIBXSMM` to enable it, with suitable include and library paths, e.g. `FCFLAGS += -I${LIBXSMM_DIR}/include -D__LIBXSMM` and `LIBS += -L${LIBXSMM_DIR}/lib -lxsmmf -lxsmm -ldl`
- A library for matrix operations and deep learning primitives: <https://github.com/hfp/libxsmm/>.
- Add `-D__LIBXSMM` to enable it, with suitable include and library paths,
e.g. `FCFLAGS += -I${LIBXSMM_DIR}/include -D__LIBXSMM`
and `LIBS += -L${LIBXSMM_DIR}/lib -lxsmmf -lxsmm -ldl`
### 2j. CUDA (optional, improved performance on GPU systems)
* Specify NVCC (e.g. `NVCC = nvcc`) and NVFLAGS (e.g. `NVFLAGS = -O3 -g -w --std=c++11`) variables.
* `-D__ACC` needed to enable accelerator support.
* Use the `-D__DBCSR_ACC` to enable accelerator support for matrix multiplications.
* Add `-lstdc++ -lcudart -lnvrtc -lcuda -lcublas` to LIBS.
* Specify the GPU type (e.g. `GPUVER = P100`), possible values are K20X, K40, K80, P100, V100.
* Specify the C++ compiler (e.g. `CXX = g++`). Remember to set the flags to support C++11 standard.
* Use `-D__PW_CUDA` for CUDA support for PW (gather/scatter/fft) calculations.
* CUFFT 7.0 has a known bug and is therefore disabled by default. NVIDIA's webpage list a patch (an upgraded version cufft i.e. >= 7.0.35) - use this together with `-D__HAS_PATCHED_CUFFT_70`.
* Use `-D__CUDA_PROFILING` to turn on Nvidia Tools Extensions. It requires to link `-lnvToolsExt`.
* Link to a blas/scalapack library that accelerates large DGEMMs (e.g. libsci_acc)
- Specify NVCC (e.g. `NVCC = nvcc`) and
NVFLAGS (e.g. `NVFLAGS = -O3 -g -w --std=c++11`) variables.
- `-D__ACC` needed to enable accelerator support.
- Use the `-D__DBCSR_ACC` to enable accelerator support for matrix multiplications.
- Add `-lstdc++ -lcudart -lnvrtc -lcuda -lcublas` to LIBS.
- Specify the GPU type (e.g. `GPUVER = P100`),
possible values are K20X, K40, K80, P100, V100.
- Specify the C++ compiler (e.g. `CXX = g++`). Remember to set the flags to
support C++11 standard.
- Use `-D__PW_CUDA` for CUDA support for PW (gather/scatter/fft) calculations.
- CUFFT 7.0 has a known bug and is therefore disabled by default.
NVIDIA's webpage list a patch (an upgraded version cufft i.e. >= 7.0.35) -
use this together with `-D__HAS_PATCHED_CUFFT_70`.
- Use `-D__CUDA_PROFILING` to turn on Nvidia Tools Extensions.
It requires to link `-lnvToolsExt`.
- Link to a blas/scalapack library that accelerates large DGEMMs (e.g. libsci_acc)
### 2k. libxc (optional, wider choice of xc functionals)
* The version 4.0.3 (or later) of libxc can be downloaded from http://www.tddft.org/programs/octopus/wiki/index.php/Libxc.
* During the installation, the directories `$(LIBXC_DIR)/lib` and `$(LIBXC_DIR)/include` are created.
* Add `-D__LIBXC` to DFLAGS, `-I$(LIBXC_DIR)/include` to FCFLAGS and `-L$(LIBXC_DIR)/lib -lxcf03 -lxc` to LIBS.
* :warning: Note that the deprecated flags `-D__LIBXC2` and `-D__LIBXC3` are ignored.
- The version 4.0.3 (or later) of libxc can be downloaded from <http://www.tddft.org/programs/octopus/wiki/index.php/Libxc>.
- During the installation, the directories `$(LIBXC_DIR)/lib`
and `$(LIBXC_DIR)/include` are created.
- Add `-D__LIBXC` to DFLAGS, `-I$(LIBXC_DIR)/include` to FCFLAGS
and `-L$(LIBXC_DIR)/lib -lxcf03 -lxc` to LIBS.
- :warning: Note that the deprecated flags `-D__LIBXC2` and `-D__LIBXC3` are ignored.
### 2l. ELPA (optional, improved performance for diagonalization)
Library ELPA for the solution of the eigenvalue problem
* ELPA replaces the ScaLapack `SYEVD` to improve the performance of the diagonalization
* A version of ELPA can to be downloaded from http://elpa.rzg.mpg.de/software.
* During the installation the `libelpa.a` (or `libelpa_openmp.a` if OpenMP is enabled) is created.
* Minimal supported version of ELPA is 2018.05.001.
* Add `-D__ELPA` to `DFLAGS`
* Add `-I$(ELPA_INCLUDE_DIR)/modules` to `FCFLAGS`
* Add `-I$(ELPA_INCLUDE_DIR)/elpa` to `FCFLAGS`
* Add `-L$(ELPA_DIR)` to `LDFLAGS`
* Add `-lelpa` to `LIBS`
* For specific architectures it can be better to install specifically
optimized kernels (see BG) and/or employ a higher optimization level to compile it.
- ELPA replaces the ScaLapack `SYEVD` to improve the performance of the diagonalization
- A version of ELPA can to be downloaded from <http://elpa.rzg.mpg.de/software>.
- During the installation the `libelpa.a`
(or `libelpa_openmp.a` if OpenMP is enabled) is created.
- Minimal supported version of ELPA is 2018.05.001.
- Add `-D__ELPA` to `DFLAGS`
- Add `-I$(ELPA_INCLUDE_DIR)/modules` to `FCFLAGS`
- Add `-I$(ELPA_INCLUDE_DIR)/elpa` to `FCFLAGS`
- Add `-L$(ELPA_DIR)` to `LDFLAGS`
- Add `-lelpa` to `LIBS`
- For specific architectures it can be better to install specifically optimized
kernels (see BG) and/or employ a higher optimization level to compile it.
### 2m. PEXSI (optional, low scaling SCF method)
The Pole EXpansion and Selected Inversion (PEXSI) method requires the PEXSI library and two dependencies (ParMETIS or PT-Scotch and SuperLU_DIST).
* Download PEXSI (www.pexsi.org) and install it and its dependencies by following its README.md.
* PEXSI versions 0.10.x have been tested with CP2K. Older versions are not supported.
* PEXSI needs to be built with `make finstall`.
The Pole EXpansion and Selected Inversion (PEXSI) method requires the PEXSI
library and two dependencies (ParMETIS or PT-Scotch and SuperLU_DIST).
- Download PEXSI (www.pexsi.org) and install it and its dependencies by
following its README.md.
- PEXSI versions 0.10.x have been tested with CP2K. Older versions are not supported.
- PEXSI needs to be built with `make finstall`.
In the arch file of CP2K:
* Add `-lpexsi_${SUFFIX} -llapack -lblas -lsuperlu_dist_3.3 -lparmetis -lmetis`, and their paths (with `-L$(LIB_DIR)`) to LIBS.
* It is important that a copy of LAPACK and BLAS is placed before and after these libraries (replace `-llapack` and `-lblas` with the optimized versions as needed).
* In order to link in PT-Scotch instead of ParMETIS replace `-lparmetis -lmetis` with: `-lptscotchparmetis -lptscotch -lptscotcherr -lscotchmetis -lscotch -lscotcherr`
* Add `-I$(PEXSI_DIR)/fortran/` to FCFLAGS.
* Add `-D__LIBPEXSI` to DFLAGS.
- Add `-lpexsi_${SUFFIX} -llapack -lblas -lsuperlu_dist_3.3 -lparmetis -lmetis`,
and their paths (with `-L$(LIB_DIR)`) to LIBS.
- It is important that a copy of LAPACK and BLAS is placed before and after these
libraries (replace `-llapack` and `-lblas` with the optimized versions as needed).
- In order to link in PT-Scotch instead of ParMETIS replace `-lparmetis -lmetis`
with: `-lptscotchparmetis -lptscotch -lptscotcherr -lscotchmetis -lscotch -lscotcherr`
- Add `-I$(PEXSI_DIR)/fortran/` to FCFLAGS.
- Add `-D__LIBPEXSI` to DFLAGS.
Below are some additional hints that may help in the compilation process:
* For building PT-Scotch, the flag `-DSCOTCH_METIS_PREFIX` in `Makefile.inc` must not be set and the flag `-DSCOTCH_PTHREAD` must be removed.
* For building SuperLU_DIST with PT-Scotch, you must set the following in `make.inc`:
```
- For building PT-Scotch, the flag `-DSCOTCH_METIS_PREFIX` in `Makefile.inc`
must not be set and the flag `-DSCOTCH_PTHREAD` must be removed.
- For building SuperLU_DIST with PT-Scotch, you must set the following in `make.inc`:
```shell
METISLIB = -lscotchmetis -lscotch -lscotcherr
PARMETISLIB = -lptscotchparmetis -lptscotch -lptscotcherr
```
### 2n. QUIP (optional, wider range of interaction potentials)
QUIP - QUantum mechanics and Interatomic Potentials Support for QUIP can be enabled via the flag `-D__QUIP`.
For more information see http://www.libatoms.org/ .
QUIP - QUantum mechanics and Interatomic Potentials Support for QUIP can be
enabled via the flag `-D__QUIP`.
For more information see <http://www.libatoms.org>.
### 2o. PLUMED (optional, enables various enhanced sampling methods)
CP2K can be compiled with PLUMED 2.x (`-D__PLUMED2`).
See https://cp2k.org/howto:install_with_plumed for full instructions.
See <https://cp2k.org/howto:install_with_plumed> for full instructions.
### 2p. spglib (optional, crystal symmetries tools)
A library for finding and handling crystal symmetries
* The spglib can be downloaded from https://github.com/atztogo/spglib
* For building CP2K with the spglib add `-D__SPGLIB` to DFLAGS
- The spglib can be downloaded from <https://github.com/atztogo/spglib>
- For building CP2K with the spglib add `-D__SPGLIB` to DFLAGS
### 2q. SIRIUS (optional, plane wave calculations)
SIRIUS is a domain specific library for electronic structure calculations.
* The code is available at https://github.com/electronic-structure/SIRIUS
* For building CP2K with SIRIUS add `-D__SIRIUS` to DFLAGS.
* See https://electronic-structure.github.io/SIRIUS/ for more information.
- The code is available at <https://github.com/electronic-structure/SIRIUS>
- For building CP2K with SIRIUS add `-D__SIRIUS` to DFLAGS.
- See <https://electronic-structure.github.io/SIRIUS/> for more information.
### 2r. FPGA (optional, plane wave FFT calculations)
* Use `-D__PW_FPGA` to enable FPGA support for PW (fft) calculations. Currently tested only for Intel Stratix 10 and Arria 10 GX1150 FPGAs.
* Supports single precision and double precision fft calculations with the use of dedicated APIs.
* Double precision is the default API chosen when set using the `-D__PW_FPGA` flag.
* Single precision can be set using an additional `-D__PW_FPGA_SP` flag along with the `-D__PW_FPGA` flag.
* Kernel code has to be synthesized separately and copied to a specific location.
* See https://github.com/pc2/fft3d-fpga for the kernel code and instructions for synthesis.
* Read `src/pw/fpga/README.md` for information on the specific location to copy the binaries to.
* Currently supported FFT3d sizes - 16^3, 32^3, 64^3.
* Include aocl compile flags and `-D__PW_FPGA -D__PW_FPGA_SP` to `CFLAGS`, aocl linker flags to `LDFLAGS` and aocl libs to `LIBS`.
* CUDA and FPGA are mutually exclusive. Building with both `__PW_CUDA` and `__PW_FPGA` will throw a compilation error.
- Use `-D__PW_FPGA` to enable FPGA support for PW (fft) calculations.
Currently tested only for Intel Stratix 10 and Arria 10 GX1150 FPGAs.
- Supports single precision and double precision fft calculations with the use
of dedicated APIs.
- Double precision is the default API chosen when set using the `-D__PW_FPGA` flag.
- Single precision can be set using an additional `-D__PW_FPGA_SP` flag along
with the `-D__PW_FPGA` flag.
- Kernel code has to be synthesized separately and copied to a specific location.
- See <https://github.com/pc2/fft3d-fpga/>
for the kernel code and instructions for synthesis.
- Read `src/pw/fpga/README.md`
for information on the specific location to copy the binaries to.
- Currently supported FFT3d sizes - 16^3, 32^3, 64^3.
- Include aocl compile flags and `-D__PW_FPGA -D__PW_FPGA_SP` to `CFLAGS`,
aocl linker flags to `LDFLAGS` and aocl libs to `LIBS`.
- CUDA and FPGA are mutually exclusive. Building with both `__PW_CUDA` and
`__PW_FPGA` will throw a compilation error.
### 2s. COSMA (Distributed Communication-Optimal Matrix-Matrix Multiplication Algorithm)
* COSMA is a replacement of the pdgemm routine included in scalapack. The
library supports both CPU and GPUs. No specific flag during compilation is
needed to use the library in cp2k, excepted during linking time where the
library should be placed in front of the scalapack library.
* see https://github.com/eth-cscs/COSMA for more information.
- COSMA is a replacement of the pdgemm routine included in scalapack. The
library supports both CPU and GPUs. No specific flag during compilation is
needed to use the library in cp2k, excepted during linking time where the
library should be placed in front of the scalapack library.
- see <https://github.com/eth-cscs/COSMA> for more information.
## 3. Compile
### 3a. ARCH files
The location of compiler and libraries needs to be specified. Examples for a number of common architectures examples can be found in [arch folder](./arch/). The names of these files match `architecture.version` e.g., [Linux-x86-64-gfortran.sopt](./arch/Linux-x86-64-gfortran.sopt). Alternatively https://dashboard.cp2k.org/ provides sample arch files as part of the testing reports (click on the status field, search for 'ARCH-file').
* With -DNDEBUG assertions may be stripped ("compiled out").
* NDEBUG is the ANSI-conforming symbol name (not __NDEBUG).
* Regular release builds may carry assertions for safety.
The location of compiler and libraries needs to be specified.
Examples for a number of common architectures examples can be found in
[arch folder](./arch/). The names of these files match `architecture.version`
e.g., [Linux-x86-64-gfortran.sopt](./arch/Linux-x86-64-gfortran.sopt).
Alternatively <https://dashboard.cp2k.org> provides sample arch files as part of
the testing reports (click on the status field, search for 'ARCH-file').
- With -DNDEBUG assertions may be stripped ("compiled out").
- NDEBUG is the ANSI-conforming symbol name (not __NDEBUG).
- Regular release builds may carry assertions for safety.
Conventionally, there are six versions:
| Acronym | Meaning | Recommended for |
|---------|-------------------------|------------------------------------|
| sdbg | serial | single core testing and debugging |
| sopt | serial | general single core usage |
| ssmp | parallel (only OpenMP) | optimized, single node, multi core |
| pdbg | parallel (only MPI) | multi-node testing and debugging |
| popt | parallel (only MPI) | general usage, no threads |
| psmp | parallel (MPI + OpenMP) | general usage, threading might improve scalability and memory usage |
| Acronym | Meaning |
|---------|----------------------------------|
| sdbg | OpenMP + debug settings |
| popt | OpenMP + OMP_NUM_THREADS=1 |
| ssmp | OpenMP |
| pdbg | MPI + OpenMP + debug settings |
| popt | MPI + OpenMP + OMP_NUM_THREADS=1 |
| psmp | MPI + OpenMP |
You'll need to modify one of these files to match your system's settings.
You can now build CP2K using these settings (where -j N allows for a parallel build using N processes):
```
> make -j N ARCH=architecture VERSION=version
You can now build CP2K using these settings
(where -j N allows for a parallel build using N processes):
```shell
make -j N ARCH=architecture VERSION=version
```
e.g.
```shell
make -j N ARCH=Linux-x86-64-gfortran VERSION=sopt
```
> make -j N ARCH=Linux-x86-64-gfortran VERSION=sopt
```
as a short-cut, you can build several version of the code at once
```shell
make -j N ARCH=Linux-x86-64-gfortran VERSION="sopt popt ssmp psmp"
```
> make -j N ARCH=Linux-x86-64-gfortran VERSION="sopt popt ssmp psmp"
```
An executable should appear in the `./exe/` folder.
All compiled files, libraries, executables, .. of all architectures and versions can be removed with
All compiled files, libraries, executables, .. of all architectures and
versions can be removed with
```shell
make distclean
```
> make distclean
```
To remove only objects and mod files (i.e., keep exe) for a given ARCH/VERSION use, e.g.,
```
> make ARCH=Linux-x86-64-gfortran VERSION=sopt clean
To remove only objects and mod files (i.e., keep exe) for a given
ARCH/VERSION use, e.g.,
```shell
make ARCH=Linux-x86-64-gfortran VERSION=sopt clean
```
to remove everything for a given ARCH/VERSION use, e.g.,
```
> make ARCH=Linux-x86-64-gfortran VERSION=sopt realclean
```shell
make ARCH=Linux-x86-64-gfortran VERSION=sopt realclean
```
### 3b. Compilation Flags
The following flags should be present (or not) in the arch file, partially depending on installed libraries (see 2.)
* `-D__parallel -D__SCALAPACK` parallel runs
* `-D__LIBINT` use libint (needed for HF exchange)
* `-D__LIBXC` use libxc
* `-D__ELPA` use ELPA in place of SYEVD to solve the eigenvalue problem
* `-D__FFTW3` FFTW version 3 is recommended
* `-D__PW_CUDA` CUDA FFT and associated gather/scatter on the GPU
* `-D__MKL` link the MKL library for linear algebra and/or FFT
The following flags should be present (or not) in the arch file,
partially depending on installed libraries (see 2.)
* with `-D__GRID_CORE=X` (with X=1..6) specific optimized core routines can be selected. Reasonable defaults are [provided](./src/grid/collocate_fast.f90) but trial-and-error might yield (a small ~10%) speedup.
* with `-D__HAS_LIBGRID` (and `-L/path/to/libgrid.a` in LIBS) tuned versions of integrate and collocate routines can be [generated](./tools/autotune_grid/README).
* `-D__PILAENV_BLOCKSIZE`: can be used to specify the blocksize (e.g. `-D__PILAENV_BLOCKSIZE=1024`), which is a hack to overwrite (if the linker allows this) the PILAENV function provided by Scalapack. This can lead to much improved PDGEMM performance. The optimal value depends on hardware (GPU?) and precise problem. Alternatively, Cray provides an environment variable to this effect (e.g. `export LIBSCI_ACC_PILAENV=4000`)
* `-D__STATM_RESIDENT` or `-D__STATM_TOTAL` toggles memory usage reporting between resident memory and total memory
* `-D__CRAY_PM_ACCEL_ENERGY` or `-D__CRAY_PM_ENERGY` switch on energy profiling on Cray systems
* `-D__NO_ABORT` to avoid calling abort, but STOP instead (useful for coverage testing, and to avoid core dumps on some systems)
- `-D__parallel -D__SCALAPACK` parallel runs
- `-D__LIBINT` use libint (needed for HF exchange)
- `-D__LIBXC` use libxc
- `-D__ELPA` use ELPA in place of SYEVD to solve the eigenvalue problem
- `-D__FFTW3` FFTW version 3 is recommended
- `-D__PW_CUDA` CUDA FFT and associated gather/scatter on the GPU
- `-D__MKL` link the MKL library for linear algebra and/or FFT
- `-D__GRID_CORE=X` (with X=1..6) specific optimized core routines can be
selected. Reasonable defaults are [provided](./src/grid/collocate_fast.f90)
but trial-and-error might yield (a small ~10%) speedup.
- `-D__HAS_LIBGRID` (and `-L/path/to/libgrid.a` in LIBS) tuned versions of
integrate and collocate routines can be [generated](./tools/autotune_grid/README).
- `-D__PILAENV_BLOCKSIZE`: can be used to specify the blocksize (e.g. `-D__PILAENV_BLOCKSIZE=1024`),
which is a hack to overwrite (if the linker allows this) the PILAENV function
provided by Scalapack. This can lead to much improved PDGEMM performance.
The optimal value depends on hardware (GPU?) and precise problem.
Alternatively, Cray provides an environment variable to this effect
(e.g. `export LIBSCI_ACC_PILAENV=4000`)
- `-D__STATM_RESIDENT` or `-D__STATM_TOTAL`
toggles memory usage reporting between resident memory and total memory
- `-D__CRAY_PM_ACCEL_ENERGY` or `-D__CRAY_PM_ENERGY`
switch on energy profiling on Cray systems
- `-D__NO_ABORT` to avoid calling abort, but STOP instead (useful for coverage
testing, and to avoid core dumps on some systems)
Features useful to deal with legacy systems
* `-D__NO_MPI_THREAD_SUPPORT_CHECK` - Workaround for MPI libraries that do not declare they are thread safe (funneled) but you want to use them with OpenMP code anyways.
* `-D__NO_IPI_DRIVER` disables the socket interface in case of troubles compiling on systems that do not support POSIX sockets.
* `-D__HAS_IEEE_EXCEPTIONS` disables trapping temporarily for libraries like scalapack.
* The Makefile automatically compiles in the path to the data directory via the flag `-D__DATA_DIR`. If you want to compile in a different path, set the variable `DATA_DIR` in your arch-file.
* `-D__NO_STATM_ACCESS` - Do not try to read from /proc/self/statm to get memory usage information. This is otherwise attempted on several. Linux-based architectures or using with the NAG, gfortran, compilers.
* `-D__CHECK_DIAG` Debug option which activates an orthonormality check of the eigenvectors calculated by the selected eigensolver
- `-D__NO_MPI_THREAD_SUPPORT_CHECK` - Workaround for MPI libraries that do not
declare they are thread safe (funneled) but you want to use them with OpenMP
code anyways.
- `-D__NO_IPI_DRIVER` disables the socket interface in case of troubles compiling
on systems that do not support POSIX sockets.
- `-D__HAS_IEEE_EXCEPTIONS` disables trapping temporarily for libraries like scalapack.
- The Makefile automatically compiles in the path to the data directory via the
flag `-D__DATA_DIR`. If you want to compile in a different path, set the
variable `DATA_DIR` in your arch-file.
- `-D__NO_STATM_ACCESS` - Do not try to read from /proc/self/statm to get memory
usage information. This is otherwise attempted on several. Linux-based
architectures or using with the NAG, gfortran, compilers.
- `-D__CHECK_DIAG` Debug option which activates an orthonormality check of the
eigenvectors calculated by the selected eigensolver
### 3c. Building CP2K as a library
You can build CP2K for use as a library by adding `libcp2k` as an option to your `make` command, e.g.
```
> make -j N ARCH=Linux-x86-64-gfortran VERSION=sopt libcp2k
```
This will create `libcp2k.a` in the relevant subdirectory of `./lib/`. You will need to add this subdirectory to the library search path of your compiler (typically via the `LD_LIBRARY_PATH` environment variable or the `-L` option to your compiler) and link to the library itself with `-lcp2k`.
You can build CP2K for use as a library by adding `libcp2k` as an option to
your `make` command, e.g.
In order to use the functions in the library you will also require the `libcp2k.h` header file. This can be found in `./src/start/` directory. You should add this directory to the header search path of your compiler (typically via the `CPATH` environment variable or the `-I` option to your compiler).
For Fortran users, you will require the module interface file (`.mod` file) for every MODULE encountered in the source. These are compiler specific and are to be found in the subdirectory of `./obj/` that corresponds to your build, e.g.,
```shell
make -j N ARCH=Linux-x86-64-gfortran VERSION=sopt libcp2k
```
This will create `libcp2k.a` in the relevant subdirectory of `./lib/`. You will
need to add this subdirectory to the library search path of your compiler
(typically via the `LD_LIBRARY_PATH` environment variable or the `-L` option to
your compiler) and link to the library itself with `-lcp2k`.
In order to use the functions in the library you will also require the `libcp2k.h`
header file. This can be found in `./src/start/` directory. You should add this
directory to the header search path of your compiler (typically via the `CPATH`
environment variable or the `-I` option to your compiler).
For Fortran users, you will require the module interface file (`.mod` file) for
every MODULE encountered in the source. These are compiler specific and are to
be found in the subdirectory of `./obj/` that corresponds to your build, e.g.,
```shell
./obj/Linux-x86-64-gfortran/sopt/
```
In order for your compiler to find these, you will need to indicate their location to the compiler as is done for header files (typically via the `CPATH` environment variable or the `-I` option to your compiler).
## 4. If it doesn't work?
In order for your compiler to find these, you will need to indicate their
location to the compiler as is done for header files (typically via the `CPATH`
environment variable or the `-I` option to your compiler).
## 4. If it doesn't work
If things fail, take a break... go back to 2a (or skip to step 6).
## 5. Regtesting
If compilation works fine, it is recommended to test the generated binary, to exclude errors in libraries, or miscompilations, etc.
```
If compilation works fine, it is recommended to test the generated binary,
to exclude errors in libraries, or miscompilations, etc.
```shell
make -j ARCH=... VERSION=... test
```
should work if you can locally execute CP2K without the need for e.g. batch submission.
In the other case, you might need to configure the underlying testing script as described more systematically at https://www.cp2k.org/dev:regtesting
In the other case, you might need to configure the underlying testing script as
described more systematically at <https://www.cp2k.org/dev:regtesting>
## 6. Talk to us
In any case please tell us your comments, praise, criticism, thanks,... see https://www.cp2k.org/
In any case please tell us your comments, praise, criticism, thanks,... see <https://www.cp2k.org>.
## 7. Manual
A reference manual of CP2K can be found on the web: https://manual.cp2k.org/ or can be generated using the cp2k executable, see https://manual.cp2k.org/trunk/generate_manual_howto.html
## 8. Happy computing!
A reference manual of CP2K can be found on the web: <https://manual.cp2k.org> or
can be generated using the cp2k executable, see <https://manual.cp2k.org/trunk/generate_manual_howto.html>
## 8. Happy computing
The CP2K team.

40
README.md
View file

@ -1,20 +1,33 @@
# CP2K
CP2K is a quantum chemistry and solid state physics software package that can perform atomistic simulations of solid state, liquid, molecular, periodic, material, crystal, and biological systems. CP2K provides a general framework for different modeling methods such as DFT using the mixed Gaussian and plane waves approaches GPW and GAPW. Supported theory levels include DFTB, LDA, GGA, MP2, RPA, semi-empirical methods (AM1, PM3, PM6, RM1, MNDO, ...), and classical force fields (AMBER, CHARMM, ...). CP2K can do simulations of molecular dynamics, metadynamics, Monte Carlo, Ehrenfest dynamics, vibrational analysis, core level spectroscopy, energy minimization, and transition state optimization using NEB or dimer method.
CP2K is a quantum chemistry and solid state physics software package that can
perform atomistic simulations of solid state, liquid, molecular, periodic,
material, crystal, and biological systems. CP2K provides a general framework for
different modeling methods such as DFT using the mixed Gaussian and plane waves
approaches GPW and GAPW. Supported theory levels include DFTB, LDA, GGA, MP2,
RPA, semi-empirical methods (AM1, PM3, PM6, RM1, MNDO, ...), and classical force
fields (AMBER, CHARMM, ...). CP2K can do simulations of molecular dynamics,
metadynamics, Monte Carlo, Ehrenfest dynamics, vibrational analysis, core level
spectroscopy, energy minimization, and transition state optimization using NEB
or dimer method.
CP2K is written in Fortran 2008 and can be run efficiently in parallel using a combination of multi-threading, MPI, and CUDA.
CP2K is written in Fortran 2008 and can be run efficiently in parallel using
a combination of multi-threading, MPI, and CUDA.
## Downloading CP2K source code
To clone the current master (development version):
```console
$ git clone --recursive https://github.com/cp2k/cp2k.git cp2k
```shell
git clone --recursive https://github.com/cp2k/cp2k.git cp2k
```
Note the ``--recursive`` flag that is needed because CP2K uses git submodules.
To clone a release version v*x.y*:
```console
$ git clone -b support/vx.y https://github.com/cp2k/cp2k.git cp2k
```shell
git clone -b support/vx.y https://github.com/cp2k/cp2k.git cp2k
```
For more information on downloading CP2K, see [Downloading CP2K](https://www.cp2k.org/download).
@ -26,11 +39,16 @@ See [installation instructions](./INSTALL.md)
## Links
* [CP2K.org](https://www.cp2k.org) for showcases of scientific work, tutorials, exercises, presentation slides, etc.
* [The manual](https://manual.cp2k.org/) with descriptions of all the keywords for the CP2K input file
* [The dashboard](https://dashboard.cp2k.org) to get an overview of the currently tested architectures
* [The Google group](https://groups.google.com/group/cp2k) to get help if you could not find an answer in one of the previous links
* [Acknowledgements](https://www.cp2k.org/funding) for list of institutions and grants that help to fund the development of CP2K
* [CP2K.org](https://www.cp2k.org)
for showcases of scientific work, tutorials, exercises, presentation slides, etc.
* [The manual](https://manual.cp2k.org/)
with descriptions of all the keywords for the CP2K input file
* [The dashboard](https://dashboard.cp2k.org)
to get an overview of the currently tested architectures
* [The Google group](https://groups.google.com/group/cp2k) to get help if you
could not find an answer in one of the previous links
* [Acknowledgements](https://www.cp2k.org/funding) for list of institutions and
grants that help to fund the development of CP2K
## Directory organization

22
benchmarks/Fayalite-FIST/README.md
View file

@ -2,7 +2,15 @@
## Description
This is a short molecular dynamics run of 1'000 time steps in a NPT ensemble at 300K. It consists of 28'000 atoms - a 103 supercell with 28 atoms of iron silicate (Fe2SiO4, also known as Fayalite) per unit cell. The simulation employs a classical potential (Morse with a hard-core repulsive term and 5.5 angstrom cutoff) with long-range electrostatics using Smoothed Particle Mesh Ewald (SPME) summation. While CP2K does support classical potentials via the Frontiers In Simulation Technology (FIST) module, this is not a typical calculation for CP2K but is included to give an impression of the performance difference between machines for the MM part of a QM/MM calculation.
This is a short molecular dynamics run of 1'000 time steps in a NPT ensemble at
300K. It consists of 28'000 atoms - a 103 supercell with 28 atoms of iron silicate
(Fe2SiO4, also known as Fayalite) per unit cell. The simulation employs a classical
potential (Morse with a hard-core repulsive term and 5.5 angstrom cutoff) with
long-range electrostatics using Smoothed Particle Mesh Ewald (SPME) summation.
While CP2K does support classical potentials via the Frontiers In Simulation
Technology (FIST) module, this is not a typical calculation for CP2K but is
included to give an impression of the performance difference between machines
for the MM part of a QM/MM calculation.
## Benchmarks
@ -10,14 +18,16 @@ This is a short molecular dynamics run of 1'000 time steps in a NPT ensemble at
## Results
The best configurations are shown below. Click the links under "Detailed Results" to see more detail.
The best configurations are shown below.
Click the links under "Detailed Results" to see more detail.
<!-- markdownlint-disable MD013 -->
| Machine Name | Architecture | Date | SVN Revision | Fastest time (s) | Number of Cores | Number of Threads | Detailed Results |
| ------------ | ------------ | ---------- | ------------ | ---------------- | --------------- | --------------------------------- | ---------------- |
| HECToR | Cray XE6 | 21/1/2014 | 13196 | 403.928 | 512 cores | 2 OMP threads per MPI task | [hector-h2o-64](https://www.cp2k.org/performance:hector-h2o-64) |
| ARCHER | Cray XC30 | 9/1/2014 | 13473 | 197.117 | 576 cores | 1 OMP thread per MPI task | [archer-h2o-64](https://www.cp2k.org/performance:archer-h2o-64) |
| Magnus | Cray XC40 | 6/11/2014 | 14377 | 150.493 | 384 cores | 1 OMP thread per MPI task | [magnus-h2o-64](https://www.cp2k.org/performance:magnus-h2o-64) |
| Piz Daint | Cray XC30 | 12/05/2015 | 15268 | 207.972 | 192 cores | 1 OMP thread per MPI task, no GPU | [piz-daint-h2o-64](https://www.cp2k.org/performance:piz-daint-h2o-64) |
| Cirrus | SGI ICE XA | 24/11/2016 | 7566 | 166.192 | 1152 cores | 9 OMP threads per MPI task | [cirrus-h2o-64](https://www.cp2k.org/performance:cirrus-h2o-64) |
| Noctua | Cray CS500 | 25/09/2019 | 9f58d81 | 119.820 | 640 cores | 10 OMP thread per MPI task | [noctua-h2o-64](https://www.cp2k.org/performance:noctua-h2o-64) |
| Piz Daint | Cray XC30 | 12/05/2015 | 15268 | 207.972 | 192 cores | 1 OMP thread per MPI task, no GPU | [piz-daint-h2o-64](https://www.cp2k.org/performance:piz-daint-h2o-64) |
| Cirrus | SGI ICE XA | 24/11/2016 | 7566 | 166.192 | 1152 cores | 9 OMP threads per MPI task | [cirrus-h2o-64](https://www.cp2k.org/performance:cirrus-h2o-64) |
| Noctua | Cray CS500 | 25/09/2019 | 9f58d81 | 119.820 | 640 cores | 10 OMP thread per MPI task | [noctua-h2o-64](https://www.cp2k.org/performance:noctua-h2o-64) |
<!-- markdownlint-enable MD013 -->

25
benchmarks/QMMM_CBD_PHY/README.md
View file

@ -3,13 +3,14 @@
## Description
This benchmark performs a short QM/MM MD simulation of 5 steps.
The CBD_PHY system contains a phytochrome dimer (PBD-ID: 4O0P) with a bound chromophore,
solvated in water. There are 68 QM atoms in this system and 167,922 atoms in total.
The QM atoms are modelled using the GPW method with the DZVP-MOLOPT-GTH basis set and
PBE XC functional. For the MM part the Amber03 forcefield is used for the protein
and water molecules are treated using the TIP3P model. The QM/MM coupling is described
with the Gaussian Expansion of the Electrostatic Potential (GEEP) method, and the bonds between the
QM and MM atoms are treated using the Generalized Hybrid Orbital (GHO) method.
The CBD_PHY system contains a phytochrome dimer (PBD-ID: 4O0P) with a bound
chromophore, solvated in water. There are 68 QM atoms in this system and 167,922
atoms in total. The QM atoms are modelled using the GPW method with the DZVP-MOLOPT-GTH
basis set and PBE XC functional. For the MM part the Amber03 forcefield is used
for the protein and water molecules are treated using the TIP3P model. The QM/MM
coupling is described with the Gaussian Expansion of the Electrostatic Potential
(GEEP) method, and the bonds between the QM and MM atoms are treated using the
Generalized Hybrid Orbital (GHO) method.
## Files description
@ -23,8 +24,8 @@ the TIP3P water model are used.
## Results
### MD Energy file
```
<!-- markdownlint-disable MD013 -->
```cp2k-output
# Step Nr. Time[fs] Kin.[a.u.] Temp[K] Pot.[a.u.] Cons Qty[a.u.] UsedTime[s]
0 0.000000 239.300084734 300.000000000 -1095.757596412 -856.457511678 0.000000000
1 1.000000 218.500201290 273.924100193 -1067.608771800 -849.108570511 182.675886658
@ -33,12 +34,14 @@ the TIP3P water model are used.
4 4.000000 237.524625019 297.774184180 -1087.284636223 -849.760011204 26.518459213
5 5.000000 245.799648725 308.148217747 -1101.835669561 -856.036020836 27.761591604
```
<!-- markdownlint-enable MD013 -->
### Best Configurations
The best configurations are shown below.
The best configurations are shown below.
<!-- markdownlint-disable MD013 -->
| Machine Name | Architecture | Date | Commit No. | Fastest time (s) | Number of Cores | Number of Threads |
| ------------ | ------------ | ---------- | -----------| ---------------- | --------------- | --------------------------------- |
| ARCHER | Cray XC30 | 07/06/2020 | 6e0731f | 358.478 | 576 | 6 OMP threads per MPI task |
<!-- markdownlint-enable MD013 -->

45
benchmarks/QMMM_ClC/README.md
View file

@ -3,18 +3,20 @@
## Description
This benchmark performs a short QM/MM MD simulation of 5 steps.
ClC consists of a (ClC-ec1) chloride ion channel embedded in a lipid bilayer (PDB-ID: 1KPK),
which is solvated in water. Two variants are included for this system - ClC-19 and ClC-253
which differ only in having respectively 19 and 253 atoms treated quantum mechanically,
representing a small and large QM subsystem within a large MM subsystem (150,925 atoms in total).
The QM regions are modelled using the GPW method with the DZVP-MOLOPT-GTH basis set and the BLYP
XC functional and the corresponding pseudopotentials. An energy cut-off for the plane waves of
300 Ry was found to be suitable. The Amber14 forcefield is used for the protein and
lipid14 forcefield is used for the lipid molecules, and water molecules are treated using the TIP3P model.
The QM/MM coupling is described with the Gaussian Expansion of the Electrostatic Potential (GEEP)
method, and the bonds between the QM and MM atoms are treated using the Generalized Hybrid Orbital (GHO) method.
ClC consists of a (ClC-ec1) chloride ion channel embedded in a lipid bilayer
(PDB-ID: 1KPK), which is solvated in water. Two variants are included for this
system - ClC-19 and ClC-253 which differ only in having respectively 19 and 253
atoms treated quantum mechanically, representing a small and large QM subsystem
within a large MM subsystem (150,925 atoms in total). The QM regions are modelled
using the GPW method with the DZVP-MOLOPT-GTH basis set and the BLYP XC functional
and the corresponding pseudopotentials. An energy cut-off for the plane waves of
300 Ry was found to be suitable. The Amber14 forcefield is used for the protein
and lipid14 forcefield is used for the lipid molecules, and water molecules are
treated using the TIP3P model. The QM/MM coupling is described with the Gaussian
Expansion of the Electrostatic Potential (GEEP) method, and the bonds between
the QM and MM atoms are treated using the Generalized Hybrid Orbital (GHO) method.
See also https://doi.org/10.1021/acs.jctc.9b00424
See also <https://doi.org/10.1021/acs.jctc.9b00424>.
## Files description
@ -29,11 +31,10 @@ the TIP3P water model are used.
## Results
### MD Energy file
### MD Energy file for ClC-19
**ClC-19**
```
<!-- markdownlint-disable MD013 -->
```cp2k-output
# Step Nr. Time[fs] Kin.[a.u.] Temp[K] Pot.[a.u.] Cons Qty[a.u.] UsedTime[s]
0 0.000000 215.076797492 300.000000000 -596.086687006 -381.009889515 0.000000000
1 1.000000 198.652973057 277.091218635 -574.153507548 -375.500534491 70.967594760
@ -43,9 +44,9 @@ the TIP3P water model are used.
5 5.000000 229.995582697 320.809476493 -610.436739448 -380.441156751 15.286556874
```
**ClC-253**
### MD Energy file for ClC-253
```
```cp2k-output
# Step Nr. Time[fs] Kin.[a.u.] Temp[K] Pot.[a.u.] Cons Qty[a.u.] UsedTime[s]
0 0.000000 215.076797492 300.000000000 -1491.612940400 -1276.536142909 0.000000000
1 1.000000 198.662217163 277.104112782 -1469.689644927 -1271.027427764 473.027817380
@ -55,19 +56,15 @@ the TIP3P water model are used.
5 5.000000 230.080097510 320.927362031 -1506.045017099 -1275.964919589 86.374744609
```
### Best Configurations
The best configurations are shown below.
**ClC-19**
### Best Configuration for ClC-19
| Machine Name | Architecture | Date | Commit No. | Fastest time (s) | Number of Cores | Number of Threads |
| ------------ | ------------ | ---------- | -----------| ---------------- | --------------- | --------------------------------- |
| ARCHER | Cray XC30 | 16/06/2020 | 6e0731f | 225.171 | 384 | 4 OMP threads per MPI task |
**ClC-253**
### Best Configuration for ClC-253
| Machine Name | Architecture | Date | Commit No. | Fastest time (s) | Number of Cores | Number of Threads |
| ------------ | ------------ | ---------- | -----------| ---------------- | --------------- | --------------------------------- |
| ARCHER | Cray XC30 | 16/06/2020 | 6e0731f | 937.151 | 576 | 6 OMP threads per MPI task |
<!-- markdownlint-enable MD013 -->

28
benchmarks/QMMM_MQAE/README.md
View file

@ -3,17 +3,17 @@
## Description
This benchmark performs a short QM/MM MD simulation of 5 steps.
The MQAE system is a solute-solvent system consisting of a N-(6-methoxyquinolyl)
acetoethyl ester in solution. All 34 atoms of the ester are treated with QM whereas
the remaining water atoms are treated with MM. The parameters for the organic molecule
are created using the General Amber Force Field (GAFF) and the water molecules are
modelled using the SPCE model. The BLYP functional as the XC functional are used and an
energy cut-off of 400 Ry for the plane waves was found to be suitable.
The QM/MM coupling is described with the Gaussian Expansion of the Electrostatic
Potential (GEEP) method, and the bonds between theQM and MM atoms are treated
using the Generalized Hybrid Orbital (GHO) method.
The MQAE system is a solute-solvent system consisting of a N-(6-methoxyquinolyl)
acetoethyl ester in solution. All 34 atoms of the ester are treated with QM
whereas the remaining water atoms are treated with MM. The parameters for the
organic molecule are created using the General Amber Force Field (GAFF) and the
water molecules are modelled using the SPCE model. The BLYP functional as the XC
functional are used and an energy cut-off of 400 Ry for the plane waves was
found to be suitable. The QM/MM coupling is described with the Gaussian Expansion
of the Electrostatic Potential (GEEP) method, and the bonds between theQM and MM
atoms are treated using the Generalized Hybrid Orbital (GHO) method.
See also https://doi.org/10.1021/acs.jctc.9b00424
See also <https://doi.org/10.1021/acs.jctc.9b00424>.
## Files description
@ -27,8 +27,8 @@ the SPCE water model are used.
## Results
### MD Energy file
```
<!-- markdownlint-disable MD013 -->
```cp2k-output
# Step Nr. Time[fs] Kin.[a.u.] Temp[K] Pot.[a.u.] Cons Qty[a.u.] UsedTime[s]
0 0.000000 10.239105709 300.000000000 -191.999316391 -181.760210683 0.000000000
1 1.000000 8.558243627 250.751692693 -189.793945191 -181.235701564 54.682023599
@ -40,9 +40,9 @@ the SPCE water model are used.
### Best Configurations
The best configurations are shown below.
The best configurations are shown below.
| Machine Name | Architecture | Date | Commit No. | Fastest time (s) | Number of Cores | Number of Threads |
| ------------ | ------------ | ---------- | -----------| ---------------- | --------------- | --------------------------------- |
| ARCHER | Cray XC30 | 16/06/2020 | 6e0731f | 72.439 | 384 | 6 OMP threads per MPI task |
<!-- markdownlint-enable MD013 -->

53
benchmarks/QS/README.md
View file

@ -2,31 +2,46 @@
## Description
Ab-initio molecular dynamics of liquid water using the Born-Oppenheimer approach, using [Quickstep](https://www.cp2k.org/quickstep) DFT. Production quality settings for the basis sets (TZV2P) and the planewave cutoff (280 Ry) are chosen, and the Local Density Approximation (LDA) is used for the calculation of the Exchange-Correlation energy. The configurations were generated by classical equilibration, and the initial guess of the electronic density is made based on Atomic Orbitals.
Ab-initio molecular dynamics of liquid water using the Born-Oppenheimer approach,
using [Quickstep](https://www.cp2k.org/quickstep) DFT. Production quality settings
for the basis sets (TZV2P) and the planewave cutoff (280 Ry) are chosen, and the
Local Density Approximation (LDA) is used for the calculation of the Exchange-Correlation
energy. The configurations were generated by classical equilibration, and the
initial guess of the electronic density is made based on Atomic Orbitals.
## Benchmarks
- [`H2O-32.inp`](H2O-32.inp): a system of 32 water molecules (96 atoms, 256 electrons) in a 9.9 cubic angstrom cell and MD is run for 10 steps
- [`H2O-64.inp`](H2O-64.inp): a system of 64 water molecules (192 atoms, 512 electrons) in a 12.4 cubic angstrom cell and MD is run for 10 steps
- [`H2O-128.inp`](H2O-128.inp): a system of 128 water molecules (384 atoms, 1'024 electrons) in a 15.6 cubic angstrom cell and MD is run for 10 steps
- [`H2O-256.inp`](H2O-256.inp): a system of 256 water molecules (768 atoms, 2'048 electrons) in a 19.7 cubic angstrom cell and MD is run for 10 steps
- [`H2O-512.inp`](H2O-512.inp): a system of 512 water molecules (1'536 atoms, 4'096 electrons) in a 24.9 cubic angstrom cell and MD is run for 10 steps
- [`H2O-1024.inp`](H2O-1024.inp): a system of 1'024 water molecules (3'072 atoms, 8'192 electrons) in a 31.3 cubic angstrom cell and MD is run for 10 steps
- [`H2O-2048.inp`](H2O-2048.inp): a system of 2'048 water molecules (6'144 atoms, 16'384 electrons) in a 39.5 cubic angstrom cell and MD is run for 10 steps
- [`H2O-4096.inp`](H2O-4096.inp): a system of 4'096 water molecules (12'288 atoms, 32'768 electrons) in a 49.7 cubic angstrom cell and MD is run for 10 steps
- [`H2O-8192.inp`](H2O-8192.inp): a system of 8'192 water molecules (24'576 atoms, 65'536 electrons) in a 62.7 cubic angstrom cell and MD is run for 10 steps
- [`H2O-32.inp`](H2O-32.inp): a system of 32 water molecules (96 atoms,
256 electrons) in a 9.9 cubic angstrom cell and MD is run for 10 steps
- [`H2O-64.inp`](H2O-64.inp): a system of 64 water molecules (192 atoms,
512 electrons) in a 12.4 cubic angstrom cell and MD is run for 10 steps
- [`H2O-128.inp`](H2O-128.inp): a system of 128 water molecules (384 atoms,
1'024 electrons) in a 15.6 cubic angstrom cell and MD is run for 10 steps
- [`H2O-256.inp`](H2O-256.inp): a system of 256 water molecules (768 atoms,
2'048 electrons) in a 19.7 cubic angstrom cell and MD is run for 10 steps
- [`H2O-512.inp`](H2O-512.inp): a system of 512 water molecules (1'536 atoms,
4'096 electrons) in a 24.9 cubic angstrom cell and MD is run for 10 steps
- [`H2O-1024.inp`](H2O-1024.inp): a system of 1'024 water molecules (3'072 atoms,
8'192 electrons) in a 31.3 cubic angstrom cell and MD is run for 10 steps
- [`H2O-2048.inp`](H2O-2048.inp): a system of 2'048 water molecules (6'144 atoms,
16'384 electrons) in a 39.5 cubic angstrom cell and MD is run for 10 steps
- [`H2O-4096.inp`](H2O-4096.inp): a system of 4'096 water molecules (12'288 atoms,
32'768 electrons) in a 49.7 cubic angstrom cell and MD is run for 10 steps
- [`H2O-8192.inp`](H2O-8192.inp): a system of 8'192 water molecules (24'576 atoms,
65'536 electrons) in a 62.7 cubic angstrom cell and MD is run for 10 steps
## Results
The best configurations are shown below. Click the links under "Detailed Results"to see more detail.
The best configurations are shown below.
Click the links under "Detailed Results" to see more detail.
<!-- markdownlint-disable MD013 -->
| Machine Name | Architecture | Date | SVN Revision | Fastest time (s) | Number of Cores | Number of Threads | Detailed Results |
| ------------ | ------------ | ---------- | ------------ | ---------------- | --------------- | --------------------------------- | ---------------- |
| HECToR | Cray XE6 | 21/1/2014 | 13196 | 39.066 | 512 cores | 2 OMP threads per MPI task | [hector-h2o-64](https://www.cp2k.org/performance:hector-h2o-64) |
| ARCHER | Cray XC30 | 8/1/2014 | 13473 | 18.11 | 576 cores | 1 OMP thread per MPI task | [archer-h2o-64](https://www.cp2k.org/performance:archer-h2o-64) |
| Magnus | Cray XC40 | 22/10/2014 | 14377 | 17.275 | 384 cores | 1 OMP thread per MPI task | [magnus-h2o-64](https://www.cp2k.org/performance:magnus-h2o-64) |
| Piz Daint | Cray XC30 | 12/05/2015 | 15268 | 19.885 | 192 cores | 1 OMP thread per MPI task, no GPU | [piz-daint-h2o-64](https://www.cp2k.org/performance:piz-daint-h2o-64) |
| Cirrus | SGI ICE XA | 24/11/2016 | 17566 | 15.560 | 1152 cores | 9 OMP threads per MPI task | [cirrus-h2o-64](https://www.cp2k.org/performance:cirrus-h2o-64) |
| Noctua | Cray CS500 | 25/09/2019 | 9f58d81 | 13.3 | 640 cores | 10 OMP thread per MPI task | [noctua-h2o-64](https://www.cp2k.org/performance:noctua-h2o-64) |
| HECToR | Cray XE6 | 21/1/2014 | 13196 | 39.066 | 512 cores | 2 OMP threads per MPI task | [hector-h2o-64](https://www.cp2k.org/performance:hector-h2o-64) |
| ARCHER | Cray XC30 | 8/1/2014 | 13473 | 18.11 | 576 cores | 1 OMP thread per MPI task | [archer-h2o-64](https://www.cp2k.org/performance:archer-h2o-64) |
| Magnus | Cray XC40 | 22/10/2014 | 14377 | 17.275 | 384 cores | 1 OMP thread per MPI task | [magnus-h2o-64](https://www.cp2k.org/performance:magnus-h2o-64) |
| Piz Daint | Cray XC30 | 12/05/2015 | 15268 | 19.885 | 192 cores | 1 OMP thread per MPI task, no GPU | [piz-daint-h2o-64](https://www.cp2k.org/performance:piz-daint-h2o-64) |
| Cirrus | SGI ICE XA | 24/11/2016 | 17566 | 15.560 | 1152 cores | 9 OMP threads per MPI task | [cirrus-h2o-64](https://www.cp2k.org/performance:cirrus-h2o-64) |
| Noctua | Cray CS500 | 25/09/2019 | 9f58d81 | 13.3 | 640 cores | 10 OMP threads per MPI task | [noctua-h2o-64](https://www.cp2k.org/performance:noctua-h2o-64) |
<!-- markdownlint-enable MD013 -->

55
benchmarks/QS_DM_LS/README.md
View file

@ -4,15 +4,33 @@
This is a single-point energy calculation using linear-scaling DFT.
For large systems the linear-scaling approach for solving Self-Consistent-Field equations will be much cheaper computationally than using standard DFT and allows scaling up to 1 million atoms for simple systems. The linear scaling cost results from the fact that the algorithm is based on an iteration on the density matrix. The cubically-scaling orthogonalisation step of standard Quickstep DFT using OT is avoided and the key operation is sparse matrix-matrix multiplications, which have a number of non-zero entries that scale linearly with system size. These are implemented efficiently in the DBCSR library.
For large systems the linear-scaling approach for solving Self-Consistent-Field
equations will be much cheaper computationally than using standard DFT and allows
scaling up to 1 million atoms for simple systems. The linear scaling cost results
from the fact that the algorithm is based on an iteration on the density matrix.
The cubically-scaling orthogonalisation step of standard Quickstep DFT using OT
is avoided and the key operation is sparse matrix-matrix multiplications, which
have a number of non-zero entries that scale linearly with system size.
These are implemented efficiently in the DBCSR library.
The problem size can be tuned by the parameter `NREP` in the input file, whereby the number of atoms scales cubically with `NREP`.
The problem size can be tuned by the parameter `NREP` in the input file, whereby
the number of atoms scales cubically with `NREP`.
## Files Description
- [H2O-dft-ls.inp](H2O-dft-ls.inp) (NREP=6): H20 density functional theory linear scaling consisting of 20'736 atoms in a 59 cubic angstrom box (6'912 water molecules in total). An LDA functional is used with a DZVP MOLOPT basis set and a 300 Ry cut-off.
- [H2O-dft-ls.NREP4.inp](H2O-dft-ls.NREP4.inp): H20 density functional theory linear scaling consisting of 6'144 atoms in a 39 cubic angstrom box (2'048 water molecules in total). An LDA functional is used with a DZVP MOLOPT basis set and a 300 Ry cut-off.
- [H2O-dft-ls.NREP2.inp](H2O-dft-ls.NREP2.inp): H20 density functional theory linear scaling consisting of 6'144 atoms in a 39 cubic angstrom box (2'048 water molecules in total). An LDA functional is used with a DZVP MOLOPT basis set and a 300 Ry cut-off (a smaller version of the H2O-dft-ls benchmark, with NREP=2, meant to run on 1 node).
- [H2O-dft-ls.inp](H2O-dft-ls.inp) (NREP=6): H20 density functional theory
linear scaling consisting of 20'736 atoms in a 59 cubic angstrom box (6'912
water molecules in total). An LDA functional is used with a DZVP MOLOPT basis
set and a 300 Ry cut-off.
- [H2O-dft-ls.NREP4.inp](H2O-dft-ls.NREP4.inp): H20 density functional theory
linear scaling consisting of 6'144 atoms in a 39 cubic angstrom box (2'048
water molecules in total). An LDA functional is used with a DZVP MOLOPT basis
set and a 300 Ry cut-off.
- [H2O-dft-ls.NREP2.inp](H2O-dft-ls.NREP2.inp): H20 density functional theory
linear scaling consisting of 6'144 atoms in a 39 cubic angstrom box (2'048
water molecules in total). An LDA functional is used with a DZVP MOLOPT basis
set and a 300 Ry cut-off (a smaller version of the H2O-dft-ls benchmark, with
NREP=2, meant to run on 1 node).
- [TiO2.inp](TiO2.inp)
- [amorph.inp](amorph.inp)
@ -20,16 +38,19 @@ The problem size can be tuned by the parameter `NREP` in the input file, whereby
### NREP=4
The best configurations are shown below. Click the links under "Detailed Results" to see more detail.
The best configurations are shown below.
Click the links under "Detailed Results" to see more detail.
<!-- markdownlint-disable MD013 -->
| Machine Name | Architecture | Date | SVN Revision | Fastest time (s) | Number of Cores | Number of Threads | Detailed Results |
| ------------ | ------------ | ---------- | ------------ | ---------------- | --------------- | ---------------------------------- | ---------------- |
| HECToR | Cray XE6 | 16/1/2014 | 13196 | 98.256 | 65536 | 8 OMP threads per MPI task | [hector-h2o-dft-ls](https://www.cp2k.org/performance:hector-h2o-dft-ls) |
| ARCHER | Cray XC30 | 8/1/2014 | 13473 | 28.476 | 49152 | 4 OMP threads per MPI task | [archer-h2o-dft-ls](https://www.cp2k.org/performance:archer-h2o-dft-ls) |
| Magnus | Cray XC40 | 3/12/2014 | 14377 | 30.921 | 24576 | 2 OMP threads per MPI task | [magnus-h2o-dft-ls](https://www.cp2k.org/performance:magnus-h2o-dft-ls) |
| Piz Daint | Cray XC30 | 12/05/2015 | 15268 | 27.900 | 32768 | 2 OMP threads per MPI task, no GPU | [piz-daint-h2o-dft-ls](https://www.cp2k.org/performance:piz-daint-h2o-dft-ls) |
| Cirrus | SGI ICE XA | 24/11/2016 | 17566 | 543.032 | 2016 | 2 OMP threads per MPI task | [cirrus-h2o-dft-ls](https://www.cp2k.org/performance:cirrus-h2o-dft-ls) |
| Noctua | Cray CS500 | 25/09/2019 | 9f58d81 | 37.730 | 10240 | 10 OMP thread per MPI task | [noctua-h2o-dft-ls](https://www.cp2k.org/performance:noctua-h2o-dft-ls) |
| HECToR | Cray XE6 | 16/1/2014 | 13196 | 98.256 | 65536 | 8 OMP threads per MPI task | [hector-h2o-dft-ls](https://www.cp2k.org/performance:hector-h2o-dft-ls) |
| ARCHER | Cray XC30 | 8/1/2014 | 13473 | 28.476 | 49152 | 4 OMP threads per MPI task | [archer-h2o-dft-ls](https://www.cp2k.org/performance:archer-h2o-dft-ls) |
| Magnus | Cray XC40 | 3/12/2014 | 14377 | 30.921 | 24576 | 2 OMP threads per MPI task | [magnus-h2o-dft-ls](https://www.cp2k.org/performance:magnus-h2o-dft-ls) |
| Piz Daint | Cray XC30 | 12/05/2015 | 15268 | 27.900 | 32768 | 2 OMP threads per MPI task, no GPU | [piz-daint-h2o-dft-ls](https://www.cp2k.org/performance:piz-daint-h2o-dft-ls) |
| Cirrus | SGI ICE XA | 24/11/2016 | 17566 | 543.032 | 2016 | 2 OMP threads per MPI task | [cirrus-h2o-dft-ls](https://www.cp2k.org/performance:cirrus-h2o-dft-ls) |
| Noctua | Cray CS500 | 25/09/2019 | 9f58d81 | 37.730 | 10240 | 10 OMP threads per MPI task | [noctua-h2o-dft-ls](https://www.cp2k.org/performance:noctua-h2o-dft-ls) |
<!-- markdownlint-enable MD013 -->
### Weak Scaling on Piz Daint, CSCS
@ -38,10 +59,13 @@ Following results were obtained in the following conditions:
- Date: 15th November 2019
- CP2K version: version 7.0 (Development Version, git:78cea8eeebb25e459941d8a28d987c9990d92676)
- DBCSR version: v2.0.0-rc9 (git:15fdaba855385f12db7599a6e69b51a7a4ce8a9a)
- CP2K flags: omp libint fftw3 libxc elpa parallel mpi3 scalapack acc pw_cuda xsmm dbcsr_acc max_contr=4
- CP2K flags: omp libint fftw3 libxc elpa parallel mpi3 scalapack acc pw_cuda
xsmm dbcsr_acc max_contr=4
- Machine: Piz Daint (GPU partition), CSCS
- Slurm configuration: 2 MPI ranks per node, 12 OpenMP threads per MPI rank
- The cell contents specify the runtime (`grep 'CP2K ' output.out`) in seconds, while the cells marked with an `X` crashed with out-of-memory errors, and the cells left empty weren't measured.
- The cell contents specify the runtime (`grep 'CP2K ' output.out`) in seconds,
while the cells marked with an `X` crashed with out-of-memory errors, and the
cells left empty weren't measured.
| nodes / NREP | NREP=1 | NREP=2 | NREP=3 | NREP=4 | NREP=6 | NREP=8 | NREP=9 |
| ------------- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
@ -59,9 +83,10 @@ Following results were obtained in the following conditions:
| 64 nodes | 24.9 | 29.0 | 40.4 | 79.7 | 257.5 | X | |
| 128 nodes | 26.3 | 32.8 | 36.6 | 62.5 | 181.9 | 400.6 | X |
<!-- markdownlint-disable MD013 -->
| nodes / NREP | NREP=6 | NREP=8 | NREP=9 | NREP=10 | NREP=11 | NREP=12 | NREP=13 | NREP=14 | NREP=16 | NREP=18 | NREP=19 | NREP=20 |
| ------------- | ----- | ----- | ----- | ------- | ------- | ------- | ------- | ------- | ------- | ------- | ------- | ------- |
| 256 nodes | 132.6 | 262.3 | 359.2 | 498.8 | 647.1 | X | | | | | | |
| 512 nodes | 106.0 | 212.5 | 290.2 | 409.2 | 534.0 | 732.3 | 875.2 | 1030.1 | X | | | |
| 1024 nodes | 98.1 | 168.9 | | 284.7 | | 510.8 | | 786.5 | 1161.1 | 1607.3 | 1872.8 | X |
<!-- markdownlint-enable MD013 -->

107
benchmarks/QS_LiH_HFX/README.md
View file

@ -4,77 +4,100 @@ Hybrid benchmark to test CP2K scaling up to 10000s of cores
## Description
This is a single-point DFT energy calculation using Quickstep GAPW (Gaussian and Augmented Plane-Waves) with hybrid Hartree-Fock exchange. It consists of a 216 atom Lithium Hydride crystal with 432 electrons in a 12.3 cubic angstrom cell. These types of calculations are generally around one hundred times the computational cost of a standard local DFT calculation, although this can be reduced using the Auxiliary Density Matrix Method (ADMM). Using OpenMP is of particular benefit here as the HFX implementation requires a large amount of memory to store partial integrals. By using several threads, fewer MPI processes share the available memory on the node and thus enough memory is available to avoid recomputing any integrals on-the-fly, improving performance.
This is a single-point DFT energy calculation using Quickstep GAPW (Gaussian and
Augmented Plane-Waves) with hybrid Hartree-Fock exchange. It consists of a 216
atom Lithium Hydride crystal with 432 electrons in a 12.3 cubic angstrom cell.
These types of calculations are generally around one hundred times the
computational cost of a standard local DFT calculation, although this can be
reduced using the Auxiliary Density Matrix Method (ADMM). Using OpenMP is of
particular benefit here as the HFX implementation requires a large amount of
memory to store partial integrals. By using several threads, fewer MPI processes
share the available memory on the node and thus enough memory is available to
avoid recomputing any integrals on-the-fly, improving performance.
## Files description
- [`input_bulk_B88_3.inp`](input_bulk_B88_3.inp): needed to generate an initial wfn (wave function) file for the HFX runs (this should be run once before running the actual HFX benchmark, and is not a part of the benchmark)
- [`input_bulk_HFX_3.inp`](input_bulk_HFX_3.inp): the actual input file for the HFX benchmark
- the additional files [`t_c_g.dat`](../../data/t_c_g.dat) and [`POTENTIAL`](../../data/POTENTIAL) are needed, and can be found in the `cp2k/data/` directory.
- [`input_bulk_B88_3.inp`](input_bulk_B88_3.inp): needed to generate an initial
wfn (wave function) file for the HFX runs (this should be run once before
running the actual HFX benchmark, and is not a part of the benchmark)
- [`input_bulk_HFX_3.inp`](input_bulk_HFX_3.inp): the actual input file for the
HFX benchmark
- the additional files [`t_c_g.dat`](../../data/t_c_g.dat) and
[`POTENTIAL`](../../data/POTENTIAL) are needed, and can be found in the
`cp2k/data/` directory.
## Benchmark Requirements
To run these this benchmark, CP2K needs to be compiled with libint support (-D__LIBINT), and it is advantageous to have a OMP/MPI hybrid code (cp2k.psmp).
To run these this benchmark, CP2K needs to be compiled with libint support
(-D__LIBINT), and it is advantageous to have a OMP/MPI hybrid code (cp2k.psmp).
## How to Run the Benchmark
1) as a preliminary step, not part of the benchmark: run `input_bulk_B88_3.inp` (5min. with 256x1 mpixomp tasks) and rename the resulting wavefunction file `LiH_bulk_3-RESTART.wfn` to `B88.wfn`
1. as a preliminary step, not part of the benchmark: run `input_bulk_B88_3.inp`
(5min. with 256x1 mpixomp tasks) and rename the resulting wavefunction file
`LiH_bulk_3-RESTART.wfn` to `B88.wfn`
```
cp LiH_bulk_3-RESTART.wfn B88.wfn
```
```shell
cp LiH_bulk_3-RESTART.wfn B88.wfn
```
2) run `input_bulk_HFX_3.inp` on a number of nodes (about 30min on 2048 cores)
2. run `input_bulk_HFX_3.inp` on a number of nodes (about 30min on 2048 cores)
The obtained energies should be similar to (obtained on 2048 MPI x 8 OMP cores):
The obtained energies should be similar to (obtained on 2048 MPI x 8 OMP cores):
```
1 OT CG 0.15E+00 139.386 0.0014482195 -870.3838179520
2 OT LS 0.30E+00 19.767 1.0000000000 -870.7951031236
3 OT CG 0.30E+00 20.724 0.0001614074 -870.9275954835
4 OT LS 0.31E+00 19.665 1.0000000000 -870.9346994255
5 OT CG 0.31E+00 20.641 0.0000168390 -870.9347195049
6 OT LS 0.29E+00 19.760 1.0000000000 -870.9347906736
7 OT CG 0.29E+00 21.192 0.0000009576 -870.9347911831
```
```cp2k-output
1 OT CG 0.15E+00 139.386 0.0014482195 -870.3838179520
2 OT LS 0.30E+00 19.767 1.0000000000 -870.7951031236
3 OT CG 0.30E+00 20.724 0.0001614074 -870.9275954835
4 OT LS 0.31E+00 19.665 1.0000000000 -870.9346994255
5 OT CG 0.31E+00 20.641 0.0000168390 -870.9347195049
6 OT LS 0.29E+00 19.760 1.0000000000 -870.9347906736
7 OT CG 0.29E+00 21.192 0.0000009576 -870.9347911831
```
## Notes
The amount of memory available per MPI process must be altered according to the number of MPI processes being used. If this is not done the benchmark will crash with an out of memory (OOM) error. The input file keyword `MAX_MEMORY` in `input_bulk_HFX_3.inp` needs to be changed as follows:
The amount of memory available per MPI process must be altered according to the
number of MPI processes being used. If this is not done the benchmark will crash
with an out of memory (OOM) error. The input file keyword `MAX_MEMORY` in
`input_bulk_HFX_3.inp` needs to be changed as follows:
```
```cp2k-input
MAX_MEMORY 14000
```
should be changed to
```
```cp2k-input
MAX_MEMORY new_value
```
The new value of `MAX_MEMORY` is chosen by dividing the total amount of memory available on a node by the number of MPI processes being used per node.
The new value of `MAX_MEMORY` is chosen by dividing the total amount of memory
available on a node by the number of MPI processes being used per node.
If a shorter runtime is desirable, the following line in `input_bulk_HFX_3.inp`:
```
```cp2k-input
MAX_SCF 20
```
may be changed to
```
```cp2k-input
MAX_SCF 1
```
in order to reduce the maximum number of SCF cycles and hence the execution time.
If the runtime or required memory needs to be reduced so the benchmark can run on a smaller number of nodes, the OPT1 basis set can be used instead of the default OPT2. To this end, the line
in order to reduce the maximum number of SCF cycles and hence the execution
time. If the runtime or required memory needs to be reduced so the benchmark can
run on a smaller number of nodes, the OPT1 basis set can be used instead of the
default OPT2. To this end, the line
```
```cp2k-input
BASIS_SET OPT2
```
in `input_bulk_B88_3.inp` and in `input_bulk_HFX_3.inp` should be changed to
```
```cp2k-input
BASIS_SET OPT1
```
@ -82,22 +105,28 @@ BASIS_SET OPT1
### Best Configurations
The best configurations are shown below. Click the links under "Detailed Results" to see more detail.
The best configurations are shown below. Click the links under
"Detailed Results" to see more detail.
<!-- markdownlint-disable MD013 -->
| Machine Name | Architecture | Date | SVN Revision | Fastest time (s) | Number of cores | Number of threads | Detailed results |
| ------------:| ------------:| ----------:| ------------:| ----------------:| ---------------:| ----------------------------------:| ----------------:|
| HECToR | Cray XE6 | 21/1/2014 | 13196(*) | 121.362 | 65536 | 8 OMP threads per MPI task | [hector-lih-hfx](https://www.cp2k.org/performance:hector-lih-hfx) |
| ARCHER | Cray XC30 | 9/1/2014 | 13473(*) | 51.172 | 49152 | 6 OMP threads per MPI task | [archer-lih-hfx](https://www.cp2k.org/performance:archer-lih-hfx) |
| Magnus | Cray XC40 | 10/11/2014 | 14377(*) | 62.075 | 24576 | 4 OMP threads per MPI task | [magnus-lih-hfx](https://www.cp2k.org/performance:magnus-lih-hfx) |
| Piz Daint | Cray XC30 | 12/05/2015 | 15268 | 66.051 | 32768 | 4 OMP threads per MPI task, no GPU | [piz-daint-lih-hfx](https://www.cp2k.org/performance:piz-daint-lih-hfx) |
| Cirrus | SGI ICE XA | 24/11/2016 | 17566 | 483.676 | 2016 | 6 OMP threads per MPI task | [cirrus-lih-hfx](https://www.cp2k.org/performance:cirrus-lih-hfx) |
| Noctua | Cray CS500 | 25/09/2019 | 9f58d81 | 131.290 | 10240 | 4 OMP thread per MPI task | [noctua-lih-hfx](https://www.cp2k.org/performance:noctua-lih-hfx) |
| HECToR | Cray XE6 | 21/1/2014 | 13196(*) | 121.362 | 65536 | 8 OMP threads per MPI task | [hector-lih-hfx](https://www.cp2k.org/performance:hector-lih-hfx) |
| ARCHER | Cray XC30 | 9/1/2014 | 13473(*) | 51.172 | 49152 | 6 OMP threads per MPI task | [archer-lih-hfx](https://www.cp2k.org/performance:archer-lih-hfx) |
| Magnus | Cray XC40 | 10/11/2014 | 14377(*) | 62.075 | 24576 | 4 OMP threads per MPI task | [magnus-lih-hfx](https://www.cp2k.org/performance:magnus-lih-hfx) |
| Piz Daint | Cray XC30 | 12/05/2015 | 15268 | 66.051 | 32768 | 4 OMP threads per MPI task, no GPU | [piz-daint-lih-hfx](https://www.cp2k.org/performance:piz-daint-lih-hfx) |
| Cirrus | SGI ICE XA | 24/11/2016 | 17566 | 483.676 | 2016 | 6 OMP threads per MPI task | [cirrus-lih-hfx](https://www.cp2k.org/performance:cirrus-lih-hfx) |
| Noctua | Cray CS500 | 25/09/2019 | 9f58d81 | 131.290 | 10240 | 4 OMP threads per MPI task | [noctua-lih-hfx](https://www.cp2k.org/performance:noctua-lih-hfx) |
<!-- markdownlint-enable MD013 -->
(*) Prior to r14945, a bug resulted in an underestimation of the number of ERIs which should be computed (by roughly 50% for this benchmark. Therefore these results cannot be compared directly with later ones.
(*) Prior to r14945, a bug resulted in an underestimation of the number of ERIs
which should be computed (by roughly 50% for this benchmark. Therefore these
results cannot be compared directly with later ones.
### 2009-04-15
Running on ORNL's Cray XT5 (Jaguar) the following runtime has been obtained in a setup using 8 OMP threads per node (8 cores per node / 16 Gb per node).
Running on ORNL's Cray XT5 (Jaguar) the following runtime has been obtained in a
setup using 8 OMP threads per node (8 cores per node / 16 Gb per node).
| Cores | Full CP2K[s] | HFX[s] | local HFX[s] | Mem/node[Mb] |
| -----:| ------------:| -------:| ------------:| ------------:|

4
benchmarks/QS_low_scaling_GW/README.md
View file

@ -2,11 +2,11 @@
## Description
This benchmark is a low-scaling G0W0 calculation of a graphene nanoribbon.
This benchmark is a low-scaling G0W0 calculation of a graphene nanoribbon.
## Benchmark Requirements
To run the benchmark, CP2K needs to be compiled with libint support (`-D__LIBINT`).
To run the benchmark, CP2K needs to be compiled with libint support (`-D__LIBINT`).
## Description of Input Files

14
benchmarks/QS_mp2_rpa/128-H2O/README.md
View file

@ -1,8 +1,9 @@
# Quickstep Moeller-Plesset perturbation theory to 2nd order Random-Phase Approximation - 128 H2O
# Quickstep / MP2 / RPA / 128 H2O
## Description of Input Files
- [`H2O-128-PBE-TZ.inp`](H2O-128-PBE-TZ.inp): needed to generate an initial wfn for the SCF runs
- [`H2O-128-PBE-TZ.inp`](H2O-128-PBE-TZ.inp):
needed to generate an initial wfn for the SCF runs
- [`H2O-128-RI-dRPA-TZ.inp`](H2O-128-RI-dRPA-TZ.inp): actual RI-dRPA benchmark
## Additional files
@ -13,18 +14,19 @@
## How to Run the Benchmark
1) run `H2O-128-PBE-TZ.inp`: this will generate the file `H2O-128-PBE-TZ-RESTART.wfn`, necessary for the benchmark run.
2) run `H2O-128-RI-dRPA-TZ.inp` for the RI-RPA benchmark.
1. run `H2O-128-PBE-TZ.inp`: this will generate the file `H2O-128-PBE-TZ-RESTART.wfn`,
necessary for the benchmark run.
2. run `H2O-128-RI-dRPA-TZ.inp` for the RI-RPA benchmark.
## Results
### Results on Piz Daint, CSCS
<!-- markdownlint-disable MD013 -->
| Input File | Date | CP2K Git SHA | Number of nodes | Node Configuration | Runtime |
| ---------------------- | ---------- | ------------:| ---------------:| ------------------- | ------- |
| H2O-128-PBE-TZ.inp | 2019-08-19 | 4519a8ad7 | 4 nodes | 12 MPI x 1 OMP | ~2 min |
| H2O-128-RI-dRPA-TZ.inp | 2019-08-19 | 4519a8ad7 | 128 nodes | 2 MPI x 6 OMP | 80 min |
| H2O-128-RI-dRPA-TZ.inp | 2019-12-03 | 78cea8eee | 1024 nodes | 2 MPI x 6 OMP | 487 sec |
<!-- markdownlint-enable MD013 -->
*) The timings have been obtained on CRAY-XC50 (PizDaint@CSCS, GPU partition)

18
benchmarks/QS_mp2_rpa/32-H2O/README.md
View file

@ -1,4 +1,4 @@
# Quickstep Moeller-Plesset perturbation theory to 2nd order Random-Phase Approximation - 32 H2O
# Quickstep / MP2 / RPA / 32 H2O
## Description of Input Files
@ -9,18 +9,22 @@
- [`BASIS_H2O`](BASIS_H2O): contains the primary and auxiliary(RI) basis sets
- [`H2O-32.xyz`](H2O-32.xyz): geometry in xyz format
- [`H2O-32-PBE-TZ.inp`](H2O-32-PBE-TZ.inp): needed to generate an initial DFT wfn (RPA, MP2)
- [`H2O-32-HF-TZ.inp`](H2O-32-HF-TZ.inp): needed to refine DFT wfn at HF level (MP2)
- [`H2O-32-PBE-TZ.inp`](H2O-32-PBE-TZ.inp):
needed to generate an initial DFT wfn (RPA, MP2)
- [`H2O-32-HF-TZ.inp`](H2O-32-HF-TZ.inp):
needed to refine DFT wfn at HF level (MP2)
- [`H2O-32-RI-MP2-TZ.inp`](H2O-32-RI-MP2-TZ.inp): actual RI-MP2 benchmark (MP2)
- [`H2O-32-RI-dRPA-TZ.inp`](H2O-32-RI-dRPA-TZ.inp): actual RI-RPA benchmark (RPA)
the additional files [`t_c_g.dat`](../../../data/t_c_g.dat) and [`POTENTIAL`](../../../data/POTENTIAL) are taken from [cp2k/data](../../../data) directory.
the additional files [`t_c_g.dat`](../../../data/t_c_g.dat) and [`POTENTIAL`](../../../data/POTENTIAL)
are taken from [cp2k/data](../../../data) directory.
## How to Run the Benchmark
1) run `H2O-32-PBE-TZ.inp`: this will generate the file `H2O-32-PBE-TZ-RESTART.wfn`, necessary for the two benchmark runs.
2) run `H2O-32-RI-MP2-TZ.inp` for the RI-MP2 benchmark.
3) and/or run `H2O-32-RI-dRPA-TZ.inp` for the RI-RPA benchmark.
1. run `H2O-32-PBE-TZ.inp`: this will generate the file `H2O-32-PBE-TZ-RESTART.wfn`,
necessary for the two benchmark runs.
2. run `H2O-32-RI-MP2-TZ.inp` for the RI-MP2 benchmark.
3. and/or run `H2O-32-RI-dRPA-TZ.inp` for the RI-RPA benchmark.
## Results

52
benchmarks/QS_mp2_rpa/64-H2O/README.md
View file

@ -1,9 +1,14 @@
# Quickstep Moeller-Plesset perturbation theory to 2nd order Random-Phase Approximation - 64 H2O
# Quickstep / MP2 / RPA / 64 H2O
## Description of Input Files
- [`H2O-64-PBE-TZ.inp`](H2O-64-PBE-TZ.inp): needed to generate an initial wfn for the SCF runs
- [`H2O-64-RI-MP2-TZ.inp`](H2O-64-RI-MP2-TZ.inp): actual RI-MP2 benchmark: the system consists of 64 water molecules in a 12.4 cubic angstrom cell. This is exactly the same system as used in the [Quickstep H2O-64](../../QS/H2O-64.inp) benchmark but using a much more accurate model, which is around 100 times more computationally demanding than standard DFT calculations.
- [`H2O-64-PBE-TZ.inp`](H2O-64-PBE-TZ.inp):
needed to generate an initial wfn for the SCF runs
- [`H2O-64-RI-MP2-TZ.inp`](H2O-64-RI-MP2-TZ.inp): actual RI-MP2 benchmark:
the system consists of 64 water molecules in a 12.4 cubic angstrom cell.
This is exactly the same system as used in the [Quickstep H2O-64](../../QS/H2O-64.inp)
benchmark but using a much more accurate model, which is around 100 times more
computationally demanding than standard DFT calculations.
- [`H2O-64-RI-dRPA-TZ.inp`](H2O-64-RI-dRPA-TZ.inp): actual RI-dRPA benchmark
## Additional files
@ -12,45 +17,50 @@
- [`POTENTIAL_H2O`](POTENTIAL_H2O): contains the GTH pseudo potentials
- [`H2O-64.xyz`](H2O-64.xyz): geometry in xyz format
the additional files [`t_c_g.dat`](../../../data/t_c_g.dat) is needed for the RI-MP2 run, and can be found in the [cp2k/data](../../../data) directory.
the additional files [`t_c_g.dat`](../../../data/t_c_g.dat) is needed for the
RI-MP2 run, and can be found in the [cp2k/data](../../../data) directory.
## How to Run the Benchmark
1) run `H2O-64-PBE-TZ.inp`: this will generate the file `H2O-64-PBE-TZ-RESTART.wfn`, necessary for the two benchmark runs.
2) run `H2O-64-RI-MP2-TZ.inp` for the RI-MP2 benchmark.
3) and/or run `H2O-64-RI-dRPA-TZ.inp` for the RI-RPA benchmark.
1. run `H2O-64-PBE-TZ.inp`: this will generate the file `H2O-64-PBE-TZ-RESTART.wfn`,
necessary for the two benchmark runs.
2. run `H2O-64-RI-MP2-TZ.inp` for the RI-MP2 benchmark.
3. and/or run `H2O-64-RI-dRPA-TZ.inp` for the RI-RPA benchmark.
## Results
### Best Configurations
The best configurations are shown below. Click the links under "Detailed Results"to see more detail.
The best configurations are shown below.
Click the links under "Detailed Results"to see more detail.
<!-- markdownlint-disable MD013 -->
| Machine Name | Architecture | Date | SVN Revision | Fastest time (s) | Number of Cores | Number of Threads | Detailed Results |
| ------------ | ------------ | ---------- | ------------ | ---------------- | --------------- | ---------------------------------- | ---------------- |
| HECToR | Cray XE6 | 13/1/2014 | 13196 | 141.633 | 49152 | 8 OMP threads per MPI task | [hector-h2o-64-ri-mp2](https://www.cp2k.org/performance:hector-h2o-64-ri-mp2) |
| ARCHER | Cray XC30 | 9/1/2014 | 13473 | 83.945 | 36864 | 4 OMP threads per MPI task | [archer-h2o-64-ri-mp2](https://www.cp2k.org/performance:archer-h2o-64-ri-mp2) |
| Magnus | Cray XC40 | 4/11/2014 | 14377 | 63.891 | 24576 | 6 OMP threads per MPI task | [magnus-h2o-64-ri-mp2](https://www.cp2k.org/performance:magnus-h2o-64-ri-mp2) |
| Piz Daint | Cray XC30 | 12/05/2015 | 15268 | 48.15 | 32768 | 8 OMP threads per MPI task, no GPU | [piz-daint-h2o-64-ri-mp2](https://www.cp2k.org/performance:piz-daint-h2o-64-ri-mp2) |
| Cirrus | SGI ICE XA | 24/11/2016 | 17566 | 303.571 | 2016 | 1 OMP thread per MPI task | [cirrus-h2o-64-ri-mp2](https://www.cp2k.org/performance:cirrus-h2o-64-ri-mp2) |
| Noctua | Cray CS500 | 25/09/2019 | 9f58d81 | 82.571 | 10240 | 2 OMP thread per MPI task | [noctua-h2o-64-ri-mp2](https://www.cp2k.org/performance:noctua-h2o-64-ri-mp2) |
| HECToR | Cray XE6 | 13/01/2014 | 13196 | 141.633 | 49152 | 8 OMP threads per MPI task | [hector-h2o-64-ri-mp2](https://www.cp2k.org/performance:hector-h2o-64-ri-mp2) |
| ARCHER | Cray XC30 | 09/01/2014 | 13473 | 83.945 | 36864 | 4 OMP threads per MPI task | [archer-h2o-64-ri-mp2](https://www.cp2k.org/performance:archer-h2o-64-ri-mp2) |
| Magnus | Cray XC40 | 04/11/2014 | 14377 | 63.891 | 24576 | 6 OMP threads per MPI task | [magnus-h2o-64-ri-mp2](https://www.cp2k.org/performance:magnus-h2o-64-ri-mp2) |
| Piz Daint | Cray XC30 | 12/05/2015 | 15268 | 48.15 | 32768 | 8 OMP threads per MPI task, no GPU | [piz-daint-h2o-64-ri-mp2](https://www.cp2k.org/performance:piz-daint-h2o-64-ri-mp2) |
| Cirrus | SGI ICE XA | 24/11/2016 | 17566 | 303.571 | 2016 | 1 OMP thread per MPI task | [cirrus-h2o-64-ri-mp2](https://www.cp2k.org/performance:cirrus-h2o-64-ri-mp2) |
| Noctua | Cray CS500 | 25/09/2019 | 9f58d81 | 82.571 | 10240 | 2 OMP threads per MPI task | [noctua-h2o-64-ri-mp2](https://www.cp2k.org/performance:noctua-h2o-64-ri-mp2) |
<!-- markdownlint-enable MD013 -->
### Results on Monte Rosa, CSCS
| Input File | Configuration | Total Number of Cores| Runtime |
| --------------------- | -------------------------:| --------------------:| -------:|
| H2O-64-PBE-TZ.inp | 128 MPI x 2 OMP | 256 | 50 s |
| H2O-64-RI-MP2-TZ.inp | 1024 MPI x 2 OMP | 2048 | ~18 min |
| H2O-64-RI-dRPA-TZ.inp | 1024 MPI x 2 OMP | 2048 | ~12 min |
| Input File | Configuration | Total Number of Cores| Runtime |
| --------------------- | -------------------:| --------------------:| -------:|
| H2O-64-PBE-TZ.inp | 128 MPI x 2 OMP | 256 | 50 s |
| H2O-64-RI-MP2-TZ.inp | 1024 MPI x 2 OMP | 2048 | ~18 min |
| H2O-64-RI-dRPA-TZ.inp | 1024 MPI x 2 OMP | 2048 | ~12 min |
*) The timings have been obtained on CRAY-XE6 (MonteRosa@CSCS)
### Results on Piz Daint, CSCS
<!-- markdownlint-disable MD013 -->
| Input File | Date | CP2K Git SHA | Number of nodes | Node Configuration | Runtime |
| --------------------- | ---------- | ------------:| ---------------:| ------------------- | ------- |
| H2O-64-PBE-TZ.inp | 2019-08-07 | 4519a8ad7 | 4 nodes | 12 MPI x 1 OMP | 69 s |
| H2O-64-RI-dRPA-TZ.inp | 2019-08-07 | 4519a8ad7 | 128 nodes | 2 MPI x 6 OMP | 455 s |
<!-- markdownlint-enable MD013 -->
*) The timings have been obtained on CRAY-XC50 (PizDaint@CSCS, GPU partition)

14
benchmarks/QS_mp2_rpa/README.md
View file

@ -4,12 +4,16 @@ Hybrid benchmark for RI-MP2 and RI-dRPA.
## Description
This benchmark is a single-point energy calculation using 2nd order Moeller-Plesset perturbation theory (MP2) with the Resolution-of-the-Identity approximation to calculate the exchange-correlation energy.
This benchmark is a single-point energy calculation using 2nd order Moeller-Plesset
perturbation theory (MP2) with the Resolution-of-the-Identity approximation to
calculate the exchange-correlation energy.
## Benchmark Requirements
To run these benchmarks, CP2K needs to be compiled with libint support (`-D__LIBINT`). Libint library has to be compiled such that higher angular momentum can be computed (see: [libint-cp2k/README](https://github.com/cp2k/libint-cp2k), use, for example, `--with-libint-max-am=6 --with-libderiv-max-am1=5`.
It is advantageouss to have a OMP/MPI hybrid code (cp2k.psmp).
In particular the RI-MP2 and RI-dRPA inputs are suitable for being used with 2 threads per task.
To run these benchmarks, CP2K needs to be compiled with libint support (`-D__LIBINT`).
Libint library has to be compiled such that higher angular momentum can be computed
(see: [libint-cp2k/README](https://github.com/cp2k/libint-cp2k), use,
for example, `--with-libint-max-am=6 --with-libderiv-max-am1=5`.
It is advantageouss to have a OMP/MPI hybrid code (cp2k.psmp). In particular the
RI-MP2 and RI-dRPA inputs are suitable for being used with 2 threads per task.

4
benchmarks/QS_ot_ls/README.md
View file

@ -30,5 +30,5 @@ On rosa the total run times are approximately:
| H2O-4096.inp | 2304 cores | 15 min |
| H2O-65536.inp | | doesn't run so far... |
Runs performed with cp2k from 30.01.09 (no libdbcsr routines used), compiled with gfortran and linked to the default libraries.
Runs performed with cp2k from 30.01.09 (no libdbcsr routines used), compiled
with gfortran and linked to the default libraries.

18
benchmarks/QS_pao_ml_tio2/README.md
View file

@ -4,9 +4,11 @@ Large scale benchmark for PAO ML (and/or LS DFT in general).
## How to Run the Benchmark
Bunzip2 all files, have [`BASIS_MOLOPT`](../../data/BASIS_MOLOPT) and [`GTH_POTENTIALS`](../../data/GTH_POTENTIALS) available (from [cp2k/data](../../data/).
Bunzip2 all files, have [`BASIS_MOLOPT`](../../data/BASIS_MOLOPT) and
[`GTH_POTENTIALS`](../../data/GTH_POTENTIALS) available (from [cp2k/data](../../data/).
For tuning purposes, the length of the full benchmark can be reduced in the following ways:
For tuning purposes, the length of the full benchmark can be reduced in the
following ways:
- by reducing the number of MD steps (STEPS 20 -> STEPS 5)
- by doing only an energy calculation (RUN_TYPE MD -> RUN_TYPE ENERGY)
@ -14,13 +16,14 @@ For tuning purposes, the length of the full benchmark can be reduced in the foll
## Results Archive
Reference energies and timings using CP2K svn:17405, Piz Daint, Cray XC30, 1024 nodes, SB + K20X, +- 8Gb mem used per node
Reference energies and timings using CP2K svn:17405, Piz Daint, Cray XC30, 1024
nodes, SB + K20X, +- 8Gb mem used per node
### Output File
(last column timings per step)
```
```shell
> grep SCF out | head -n 10
------------------------------ Linear scaling SCF -----------------------------
SCF 1 -552962.443966503 -552962.443966503 28.188702
@ -35,8 +38,8 @@ Reference energies and timings using CP2K svn:17405, Piz Daint, Cray XC30, 1024
```
### MD Energy File
```
<!-- markdownlint-disable MD013 -->
```shell
> cat pao_ml_md-1.ener
# Step Nr. Time[fs] Kin.[a.u.] Temp[K] Pot.[a.u.] Cons Qty[a.u.] UsedTime[s]
0 0.000000 110.495412573 300.000000000 -554937.745690580 -554827.250278007 0.000000000
@ -61,10 +64,11 @@ Reference energies and timings using CP2K svn:17405, Piz Daint, Cray XC30, 1024
19 9.500000 105.405738067 286.181305486 -554932.815285468 -554827.409547401 365.768221021
20 10.000000 102.522367308 278.352824576 -554929.882289568 -554827.359922261 364.275226861
```
<!-- markdownlint-enable MD013 -->
### Timings
```
```cp2k-output
SUBROUTINE CALLS ASD SELF TIME TOTAL TIME
MAXIMUM AVERAGE MAXIMUM AVERAGE MAXIMUM
CP2K 1 1.0 0.182 0.228 8802.156 8802.158

6
benchmarks/QS_single_node/README.md
View file

@ -1,4 +1,6 @@
# Quickstep Single Node Regression Tests
The purpose of these tests is to give a quick idea of the performance of a system, when only a single node is available.
The tests should run in < 5 minutes on a modern node, and require less than 16Gb of memory.
The purpose of these tests is to give a quick idea of the performance of a
system, when only a single node is available.
The tests should run in < 5 minutes on a modern node,
and require less than 16Gb of memory.

39
benchmarks/QS_stmv/README.md
View file

@ -1,21 +1,37 @@
# STMV benchmark
This benchmark test the performance of CP2K to run calculations of the electronic structure of relatively complex systems containing a million atoms. The input is based on [earlier work](https://pubs.acs.org/doi/full/10.1021/acs.jctc.6b00398) where the electronic structure of the STMV virus was simulated based on DFT and subsystem DFT. Here, instead, the xTB tight-binding method is employed. The input is realistic in its input settings and might be useful to set up similar systems.
This benchmark test the performance of CP2K to run calculations of the electronic
structure of relatively complex systems containing a million atoms. The input is
based on [earlier work](https://pubs.acs.org/doi/full/10.1021/acs.jctc.6b00398)
where the electronic structure of the STMV virus was simulated based on DFT and
subsystem DFT. Here, instead, the xTB tight-binding method is employed. The input
is realistic in its input settings and might be useful to set up similar systems.
## Properties of the benchmark
The benchmark exercises in particular the sparse matrix handling and linear scaling algorithms in CP2K. It performs 1 step of geometry optimization, so requires SCF, energy and force calculations. Some properties are computed as well. Given the xTB method, relatively small block sizes dominate in the sparse matrix multiplication.
The benchmark exercises in particular the sparse matrix handling and linear
scaling algorithms in CP2K. It performs 1 step of geometry optimization, so
requires SCF, energy and force calculations. Some properties are computed as well.
Given the xTB method, relatively small block sizes dominate in the sparse matrix
multiplication.
## Typical timings and setup
A typical parallel run will require on the order of 256 nodes, to see completion of the benchmark in a reasonable time, and memory consumption. An invocation with slurm on a system with 32 threads per node (dual socket, Intel(R) Xeon(R) CPU E5-2695 v4 @ 2.10GHz, Piz Daint multi-core) could look like:
```
export OMP_NUM_THREADS=8
srun --cpu-bind=none --nodes=256 --ntasks=1024 --ntasks-per-node=4 --cpus-per-task=8 ./cp2k.psmp -i stmv_xtb.inp -o stmv_xtb.out
```
Which would need roughly 7Gb per rank (28Gb per node), and would run in in less than 4h. The timing report for this run (based on CP2K 7.0, git:bf104a630):
A typical parallel run will require on the order of 256 nodes, to see completion
of the benchmark in a reasonable time, and memory consumption. An invocation with
slurm on a system with 32 threads per node (dual socket, Intel(R) Xeon(R)
CPU E5-2695 v4 @ 2.10GHz, Piz Daint multi-core) could look like:
```shell
export OMP_NUM_THREADS=8
srun --cpu-bind=none --nodes=256 --ntasks=1024 --ntasks-per-node=4 \
--cpus-per-task=8 ./cp2k.psmp -i stmv_xtb.inp -o stmv_xtb.out
```
Which would need roughly 7Gb per rank (28Gb per node), and would run in in less
than 4h. The timing report for this run (based on CP2K 7.0, git:bf104a630):
```cp2k-output
SUBROUTINE CALLS ASD SELF TIME TOTAL TIME
MAXIMUM AVERAGE MAXIMUM AVERAGE MAXIMUM
CP2K 1 1.0 6.012 6.487 8256.073 8256.198
@ -103,8 +119,7 @@ SUBROUTINE CALLS ASD SELF TIME TOTAL TIME
and DBCSR statistics
```
```cp2k-output
COUNTER TOTAL BLAS SMM ACC
flops 2 x 2 x 2 36142856249008 0.0% 100.0% 0.0%
flops 2 x 2 x 8 39213980112512 0.0% 100.0% 0.0%
@ -177,13 +192,13 @@ and DBCSR statistics
-------------------------------------------------------------------------------
MEMORY| Estimated peak process memory [MiB] 6402
```
## Key output elements
SCF cycles output looks like
```
```cp2k-output
------------------------------ Linear scaling SCF -----------------------------
SCF 1 -2019286.740626037 -2019286.740626037 257.119279
SCF 2 -2022372.558790133 -3085.818164097 283.782252

54
benchmarks/README.md
View file

@ -2,19 +2,28 @@
This directory contains input files for CP2K's benchmarks.
For measurements from different machines, please refer to [CP2K benchmark suite](https://www.cp2k.org/performance), and for documentation on CP2K's input files, please refer to the [Input Reference Manual](https://manual.cp2k.org/). Python scripts for generating the scaling graphs are provided in [tools/benchmark_plots/](../tools/benchmark_plots).
For measurements from different machines, please refer to [CP2K benchmark suite](https://www.cp2k.org/performance),
and for documentation on CP2K's input files, please refer to the
[Input Reference Manual](https://manual.cp2k.org/). Python scripts for
generating the scaling graphs are provided in [tools/benchmark_plots/](../tools/benchmark_plots).
**Note:** the benchmark names make common use of acronyms. For explanations, please refer to the [Glossary of Acronyms and Abbreviations](https://www.cp2k.org/acronyms).
**Note:** the benchmark names make common use of acronyms. For explanations,
please refer to the [Glossary of Acronyms and Abbreviations](https://www.cp2k.org/acronyms).
## 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 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](https://www.cp2k.org/performance:systems).
## Benchmarks
See the `README.md` inside each benchmark sub-directory for descriptions of each benchmark along with performance numbers.
See the `README.md` inside each benchmark sub-directory for descriptions of each
benchmark along with performance numbers.
Benchmarks currently available:
@ -32,30 +41,42 @@ Benchmarks currently available:
### 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.
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:
The general way to run the benchmarks with the hybrid parallel executable is,
e.g. for 2 threads per rank:
```
```shell
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_options` specifies 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.
- The parallel_launcher is mpirun, mpiexec, or some variant such as aprun on
Cray systems or srun when using Slurm.
- `launcher_options` specifies 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
The reported walltime for a given run can be obtained by querying the resulting
`.log` file for CP2K's internal timing, as follows:
```shell
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 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 DBCSR
- `MESSAGE PASSING PERFORMANCE`: statistics on MPI calls in CP2K
- `T I M I N G`: timing and number of calls of CP2K functions
@ -66,6 +87,7 @@ Python scripts for generating the scaling graphs are provided in [cp2k/tools/ben
## 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](https://www.cp2k.org/performance:systems) for which benchmark data is provided.
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](https://www.cp2k.org/performance:systems)
for which benchmark data is provided.

43
src/grid/README.md
View file

@ -1,24 +1,32 @@
# grid: High performance primitives to power GPW & Co
This package hosts the performance critical grid operations of cp2k. The code is entirely written in C and can be built stand-alone in order to provide a good separation of concerns between computational chemists and performance engineers.
This package hosts the performance critical grid operations of cp2k. The code is
entirely written in C and can be built stand-alone in order to provide a good
separation of concerns between computational chemists and performance engineers.
Currently, this package offers the following main features:
- Collocate a single task, see `grid_collocate_pgf_product_cpu` in [grid_collocate_cpu.h](grid_collocate_cpu.h) for details.
- Collocate a list of tasks, see `grid_collocate_task_list` in [grid_task_list.h](grid_task_list.h) for details.
- Collocate a single task, see `grid_collocate_pgf_product_cpu` in
[grid_collocate_cpu.h](grid_collocate_cpu.h) for details.
- Collocate a list of tasks, see `grid_collocate_task_list` in
[grid_task_list.h](grid_task_list.h) for details.
## The .task files
For debugging all collocations can be written to .task files. To enable this feature edit the following line in [grid_collocate_cpu.c](grid_collocate_cpu.c):
```
For debugging all collocations can be written to .task files. To enable this
feature edit the following line in [grid_collocate_cpu.c](grid_collocate_cpu.c):
```C
// Set this to true to write each task to a file.
const bool DUMP_TASKS = false;
```
The files are given sequential names like `grid_collocate_00123.task`. Beware that MPI ranks can overwrite each other's files.
The files are given sequential names like `grid_collocate_00123.task`.
Beware that MPI ranks can overwrite each other's files.
The resulting .task files are human readable and diffable:
```
```task-file
#Grid collocate task v9
orthorhombic 1
border_mask 0
@ -31,8 +39,13 @@ grid 13 13 18 9.926167350636332098457e-24
For more information see [grid_collocate_replay.c](grid_collocate_replay.c).
## MiniApp
The `grid_collocate_miniapp.x` binary allows to run individual .task files. By default `grid_collocate_pgf_product_cpu` is called. When the `--batch` flag is set then `grid_collocate_task_list` is called instead.
```
The `grid_collocate_miniapp.x` binary allows to run individual .task files.
By default `grid_collocate_pgf_product_cpu` is called. When the `--batch` flag
is set then `grid_collocate_task_list` is called instead.
<!-- markdownlint-disable MD013 -->
```shell
$ cd cp2k/src/grid
$ make
$ ./grid_collocate_miniapp.x
@ -41,12 +54,17 @@ Usage: grid_base_ref_miniapp.x [--batch <cycles-per-block>] <cycles> <task-file>
$ ./grid_collocate_miniapp.x --batch 10 100 sample_tasks/collocate_ortho_density_l2200.task
Task: sample_tasks/collocate_ortho_density_l2200.task Batched: yes Cycles: 1.000000e+02 Max value: 1.579830e+02 Max diff: 1.705303e-13 Time: 1.884854e-03 sec
```
<!-- markdownlint-enable MD013 -->
## Unit Test
The `grid_collocate_unittest.x` binary runs the .task files from the [sample_tasks](./sample_tasks/) directory - with and without batching. Beware that this is merely a smoke test. The cp2k regtest suite provides much more thorough testing.
The `grid_collocate_unittest.x` binary runs the .task files from the
[sample_tasks](./sample_tasks/) directory - with and without batching.
Beware that this is merely a smoke test.
The cp2k regtest suite provides much more thorough testing.
```
<!-- markdownlint-disable MD013 -->
```shell
$ cd cp2k/src/grid
$ make
$ ./grid_collocate_unittest.x
@ -59,3 +77,4 @@ Task: ../../src/grid/sample_tasks/collocate_ortho_density_l0000.task Batche
Task: ../../src/grid/sample_tasks/collocate_ortho_non_periodic.task Batched: yes Cycles: 1.000000e+00 Max value: 4.483815e-01 Max diff: 0.000000e+00 Time: 1.882868e-02 sec
All tests have passed :-)
```
<!-- markdownlint-enable MD013 -->

25
src/pw/fpga/README.md
View file

@ -1,16 +1,19 @@
# FPGA
## Finding the kernel code
- See https://github.com/pc2/fft3d-fpga for the kernel code and instructions on synthesizing them for INTEL FPGAs.
- See <https://github.com/pc2/fft3d-fpga> for the kernel code and instructions
on synthesizing them for INTEL FPGAs.
### Copy the bitstream generated to a particular path
- The bitstream generated on synthesis can be found as the `.aocx` file.
- Copy this file to the following locations:
- If single precision: `~/cp2k/fpgabitstream/fft3d/synthesis_sp/syn??/*. `
- If double precision: `~/cp2k/fpgabitstream/fft3d/synthesis_dp/syn??/*.`
- where `syn??` is dependent on the size of the FFT3d
- Therefore, a 16^3 FFT3d file should be copied to `syn16` folder.
- The sizes supported are 16^3, 32^3, 64^3.
- If the required FFT size is different from the default options:
- modify the switch case in the `fft_fpga.c` to include the required size
and the path to the location of the bitstream.
- The bitstream generated on synthesis can be found as the `.aocx` file.
- Copy this file to the following locations:
- If single precision: `~/cp2k/fpgabitstream/fft3d/synthesis_sp/syn??/*.`
- If double precision: `~/cp2k/fpgabitstream/fft3d/synthesis_dp/syn??/*.`
- where `syn??` is dependent on the size of the FFT3d
- Therefore, a 16^3 FFT3d file should be copied to `syn16` folder.
- The sizes supported are 16^3, 32^3, 64^3.
- If the required FFT size is different from the default options:
- modify the switch case in the `fft_fpga.c` to include the required size
and the path to the location of the bitstream.

2
src/start/python/README.md
View file

@ -27,4 +27,4 @@ Python interpreter instances due to side effects in the library.
depending on your MPI implementation/configuration. In that case MPI must be
initialized first by using Mpi4py and the Fortran MPI communicator handler
must be passed down the CP2K via the respective `...comm` functions.
The reason for this is documented here: https://github.com/jhedev/mpi_python
The reason for this is documented here: <https://github.com/jhedev/mpi_python>

3
tests/Fist/EAM_LIB/README.md
View file

@ -1,5 +1,6 @@
# Fist EAM Regression Tests
The potentials for Ag, Pt and Au listed here are converted from the [LAMMPS distribution](http://lammps.sandia.gov).
The mixed file is generated by multiplication of Za(R)*Zb(R)/R as prescribed in Foiles et al., PRB 33 (1986) 7983.
The mixed file is generated by multiplication of Za(R)*Zb(R)/R as prescribed in
Foiles et al., PRB 33 (1986) 7983.
Note that the grid is quite loose, so `EMAX_SPLINE` is set to a high value (D. Passerone).

32
tests/README.md
View file

@ -2,34 +2,44 @@
This directory contains input files for CP2K's tests and regression tests.
Automatic test results are collected on [CP2K's dashboard](https://dashboard.cp2k.org) for different machines. For documentation on CP2K's input files, please refer to the [Input Reference Manual](https://manual.cp2k.org/).
Automatic test results are collected on [CP2K's dashboard](https://dashboard.cp2k.org)
for different machines. For documentation on CP2K's input files, please refer to
the [Input Reference Manual](https://manual.cp2k.org/).
**Note:** the test names make common use of acronyms. For explanations, please refer to the [Glossary of Acronyms and Abbreviations](https://www.cp2k.org/acronyms).
**Note:** the test names make common use of acronyms.
For explanations, please refer to the [Glossary of Acronyms and Abbreviations](https://www.cp2k.org/acronyms).
## Regression Tests
There is a very large number of regtests. For this reason, each individual regtest should be fast (e.g. shorter than a minute on a regular laptop with an sdbg version of the code). Since these tests do not need to return meaningful results (just consistent results), one can use e.g. small basis sets, low cutoffs, small EPS_DEFAULT, ...
There is a very large number of regtests. For this reason, each individual
regtest should be fast (e.g. shorter than a minute on a regular laptop with an
sdbg version of the code). Since these tests do not need to return meaningful
results (just consistent results), one can use e.g. small basis sets,
low cutoffs, small EPS_DEFAULT, ...
### Test Directories Structure
The test-suite is fully controlled by the following files:
- [`TEST_DIRS`](TEST_DIRS) is a list of directories that contain tests.
- [`TEST_TYPES`](TEST_TYPES) defines test types. I.e. specifies which words should be grepped and what field should be used in the numerical comparison.
- [`TEST_TYPES`](TEST_TYPES) defines test types. I.e. specifies which words
should be grepped and what field should be used in the numerical comparison.
Additionally, each test-subdirectory contains:
- `TEST_FILES`: the list of input files that need to be executed for the regression test. These files will be run in order.
- `TEST_FILES_RESET`: the list of files for which the reference output became invalid (e.g bug fix).
Additionally, each test-subdirectory contain `TEST_FILES`, which lists the input
files that need to be executed for the regression test.
These files will be run in order.
Some regression testing directories contain:
- `untested_inputs`: list of input files, which have a more meaningfull setup compared to the regtests, but that are not checked at every single commit.
- `untested_inputs`: list of input files, which have a more meaningfull setup
compared to the regtests, but that are not checked at every single commit.
### How to Run Regression Tests
For information on how to run regression testing, please refer to the [regression testing documentation](https://www.cp2k.org/dev:regtesting).
For information on how to run regression testing, please refer to the
[regression testing documentation](https://www.cp2k.org/dev:regtesting).
### How to Add a Regression Test
To add a regression test, commit the `.inp` file and add a corresponding entry to [`TEST_DIRS`](TEST_DIRS) and `TEST_FILES`.
To add a regression test, commit the `.inp` file and add a corresponding entry
to [`TEST_DIRS`](TEST_DIRS) and `TEST_FILES`.

36
tools/benchmark_plots/README.md
View file

@ -1,4 +1,4 @@
## Plotting benchmark results
# Plotting benchmark results
Two python scripts are provided to help plot benchmark results:
@ -6,25 +6,26 @@ Two python scripts are provided to help plot benchmark results:
- `plot_comparison.py` - Plots a comparison of results for an individual benchmark
Library requirements:
- `numpy`
- `matplotlib`
### `plot_benchmark.py`
## `plot_benchmark.py` usage
##### Usage:
```console
```shell
> python plot_benchmark.py --name <benchmarkname> --machine <machinename> \
[--shift <YSHIFT>] [--show]
```
##### Arguments:
## `plot_benchmark.py` arguments
- `--name`: Name of the benchmark to plot results for, e.g. fayalite-FIST
- `--machine`: Machine to plot results for, e.g. Magnus
- `--shift`: Fractional shift of label in y-direction, for fine tuning, e.g. 1.1
- `--show`: Show the plot window as well as saving to a file
##### Assumptions:
## `plot_benchmark.py` assumptions
The results will be read from files called:
`<machine>_benchmarks/<name>/<name>_besttimes.txt`
(converted to lower case) in the directory defined as `BASE`.
@ -32,15 +33,15 @@ This `BASE` directory should be edited directly in the script to set the
correct location for the benchmark results. See below for the format
of this file.
### `plot_comparison.py`
## `plot_comparison.py` usage
##### Usage:
```console
```shell
> python plot_comparison.py --name <benchmarkname> --machines <machinenames> \
[--shifts <YSHIFT>] [--show]
```
##### Arguments:
## `plot_comparison.py` arguments
- `--name`: Name of the benchmark to plot results for, e.g. fayalite-FIST
- `--machine`: List of machines to plot results for, e.g. Magnus ARCHER HECToR
- `--shift`: Fractional shifts of label in y-direction, for fine tuning,
@ -48,7 +49,8 @@ of this file.
If less shifts are specified than machines then they will be used in rotation.
- `--show`: Show the plot window as well as saving to a file
##### Assumptions:
## `plot_comparison.py` assumptions
The results will be read from files called:
`<machine>_benchmarks/<name>/<name>_besttimes.txt`
(converted to lower case) in the directory defined as `BASE`.
@ -56,16 +58,18 @@ This `BASE` directory should be edited directly in the script to set the
correct location for the benchmark results. See below for the format
of this file.
### Result File Format
## Result File Format
The result files should contain the result for a single run on each line in
the form:
```
```output
<nodes> <time> <configuration>
```
Where:
- `<nodes>`: is the number of nodes run on
- `<time>`: is the time taken in seconds
- `<configuration>`: is the configuration for the best time, eg `2_TH` if the best
result is obtained for 2 OpenMP threads per MPI task.
- `<configuration>`: is the configuration for the best time, eg `2_TH` if the
best result is obtained for 2 OpenMP threads per MPI task.

151
tools/doxify/README.md
View file

@ -1,43 +1,45 @@
## DOXYGEN
# DOXYGEN
This file describes the scripts used to add missing comments and parse existing comments
for subroutines and functions in CP2K. The objective of the scripts is to ensure that
all subroutines and functions in CP2K have a standard DOXYGEN comment block and to flag
any missing comments such that the CP2K developers can add/update these when time is
available.
This file describes the scripts used to add missing comments and parse existing
comments for subroutines and functions in CP2K. The objective of the scripts is
to ensure that all subroutines and functions in CP2K have a standard DOXYGEN
comment block and to flag any missing comments such that the CP2K developers can
add/update these when time is available.
The driver script `doxyify.sh` will process CP2K source code (`*.F` files)
processing one file at a time. The following steps are carried out for each `*.F` file:
The driver script `doxyify.sh` will process CP2K source code (`*.F` files) processing
one file at a time. The following steps are carried out for each `*.F` file:
1. Run `remove_double_ampersands.pl` - removes any any double ampersand characters
2. Run `fixcomments.pl` - does the addition of missing comments or updating of existing comments
3. Run `remove_extra_comments.pl` - removes any extra comment lines which arise from application
of `fixcomments.pl`
2. Run `fixcomments.pl` - does the addition of missing comments or updating of
existing comments
3. Run `remove_extra_comments.pl` - removes any extra comment lines which arise
from application of `fixcomments.pl`
4. Finally, overwrite the original `*.F` file with the updated version
To run the script, you should execute it with the name of the source file you want to
process:
To run the script, you should execute it with the name of the source file you
want to process:
```console
```shell
./doxyify.sh full_path_to_cp2k_src/myfile.F
```
or with a list of files, e.g.
```console
```shell
./doxyify.sh full_path_to_cp2k_src/myfile.F full_path_to_cp2k_src/myfile2.F full_path_to_cp2k_src/myfile2.F
```
In debug mode, the script will produce a lot of output if the whole source tree is processed so you may
wish to redirect the stdout to file, e.g.
In debug mode, the script will produce a lot of output if the whole source tree
is processed so you may wish to redirect the stdout to file, e.g.
```console
```shell
./doxyify.sh > comments.txt
```
### `remove_double_ampersands.pl`
## `remove_double_ampersands.pl`
Removes any double ampersand characters that occur at the end of one line and the start of
the next line, e.g:
Removes any double ampersand characters that occur at the end of one line and
the start of the next line, e.g:
```fortran
SUBROUTINE fred(a,b, &
@ -51,21 +53,22 @@ SUBROUTINE fred(a,b, &
c,d)
```
This is performed throughout the source code and is necessary as the ampersand is used
by `fixcomments.pl` to determine whether a subroutine/function definition extends across
multiple lines.
This is performed throughout the source code and is necessary as the ampersand
is used by `fixcomments.pl` to determine whether a subroutine/function definition
extends across multiple lines.
## `fixcomments.pl`
### `fixcomments.pl`
The script adds in missing comments and parses existing comments checking whether any data
is missing. For procedures with no existing comments, e.g. a subroutine with 3 arguments `a`, `b`
and `c:
The script adds in missing comments and parses existing comments checking whether
any data is missing. For procedures with no existing comments, e.g. a subroutine
with 3 arguments `a`, `b` and `c`:
```fortran
SUBROUTINE fred (a,b,c)
```
will be updated to (the ... are to indicate comments are required)
```fortran
! *****************************************************************************
!> \brief ...
@ -78,64 +81,70 @@ SUBROUTINE fred (a,b,c)
The scripts works as follows:
- We read through the source file until we see a comment block e.g. something beginning
with !>
- We read through the source file until we see a comment block e.g. something
beginning with `!>`
- We then loop over the comment block looking for entries for \brief, \param, \date,
\par, \version and \note and \author. If any of these items exist we store the details
in separate variables. We also keep a copy of the entire comment block in the oldheader
variable as we need to print the comment block out unchanged for MODULE and TYPE. When
parsing the header we ensure that we don't throw any text away.
- We then loop over the comment block looking for entries for `\brief`, `\param`,
`\date`, `\par`, `\version`, `\note`, and `\author`. If any of these items
exist we store the details in separate variables. We also keep a copy of the
entire comment block in the `oldheader` variable as we need to print the
comment block out unchanged for MODULE and TYPE. When parsing the header we
ensure that we don't throw any text away.
- Once the comment block has been read in we continue reading in the code line by line.
If we don't encounter any procedures then the output file will be identical to the
input file.
- Once the comment block has been read in we continue reading in the code line
by line. If we don't encounter any procedures then the output file will be
identical to the input file.
- However, if we encounter a procedure we then read in the line(s) containing the
definition, e.g.
- However, if we encounter a procedure we then read in the line(s) containing
the definition, e.g.
```fortran
SUBROUTINE fred(a,b,c)
```
```fortran
SUBROUTINE fred(a,b,c)
```
to an array called `@string`. We do this by splitting over space, comma, brackets etc. We
also take into account of the fact a subroutine / function definition can extend over multiple
lines via the ampersand (`&`) character and ampersand variable. The `@string` array then contains
the type of procedure, its name and the arguments, e.g. for the example above `@string` would
contain 5 elements: `SUBROUTINE`, `fred`, `a`, `b`, `c`.
to an array called `@string`. We do this by splitting over space, comma,
brackets etc. We also take into account of the fact a subroutine / function
definition can extend over multiple lines via the ampersand (`&`) character
and ampersand variable. The `@string` array then contains the type of procedure,
its name and the arguments, e.g. for the example above `@string` would contain
5 elements: `SUBROUTINE`, `fred`, `a`, `b`, `c`.
- Once we know the name and arguments of the procedure we loop over the arguments checking
to see whether the comment block contained a match. If it is does we use the existing text,
if no match is found then the standard text detailed above is output. We also check whether
any text exists for the `\brief` entry and re-use this if available, otherwise the `\brief ...`
text is added as detailed above. The script can also handle `\date`, `\par`, `\author`, `\note` and
`\version` entries if these should be required in future. At present these entries are copied
across unchanged if they exist and otherwise they are not added in.
- Once we know the name and arguments of the procedure we loop over the arguments
checking to see whether the comment block contained a match. If it is does we
use the existing text, if no match is found then the standard text detailed
above is output. We also check whether any text exists for the `\brief` entry
and re-use this if available, otherwise the `\brief ...` text is added as
detailed above. The script can also handle `\date`, `\par`, `\author`, `\note`
and `\version` entries if these should be required in future. At present these
entries are copied across unchanged if they exist and otherwise they are not
added in.
- Finally anything else that was found in the comment block is output and suitably annotated.
For example unmatched procedure arguments are flagged up, lines which begin with `!>`, `!`, or
`!> \something_or_other` are also annotated.
- Finally anything else that was found in the comment block is output and suitably
annotated. For example unmatched procedure arguments are flagged up, lines
which begin with `!>`, `!`, or `!> \something_or_other` are also annotated.
- The annotations used for marking up the comment block are as follows:
- `...` Added to `\brief` and `\param` only if no existing information is available. Other
commonly occurring entries such as `\par`, `\author`, `\version`, `\note` and `\date` if they exist
are passed through unchanged.
- `...` Added to `\brief` and `\param` only if no existing information is
available. Other commonly occurring entries such as `\par`, `\author`,
`\version`, `\note` and `\date` if they exist are passed through unchanged.
- `UNMATCHED_PROCEDURE_ARGUMENT` - gets appended on to any procedure arguments in the comment block
that don't match those in the procedure definition.
- `UNMATCHED_PROCEDURE_ARGUMENT` - gets appended on to any procedure arguments
in the comment block that don't match those in the procedure definition.
- `UNKNOWN_DOXYGEN_COMMENT` - for parts of the comment block which look like a standard Doxygen
block (e.g. lines that look like: `!> \something or other`) but not part of the standard
header above.
- `UNKNOWN_DOXYGEN_COMMENT` - for parts of the comment block which look like a
standard Doxygen block (e.g. lines that look like: `!> \something or other`)
but not part of the standard header above.
- `UNKNOWN_COMMENT` - lines that begin `!>` or `!` inside the comment block. These get placed into
a `!> \note with UNKNOWN_COMMENT` added at the start of the line.
- `UNKNOWN_COMMENT` - lines that begin `!>` or `!` inside the comment block.
These get placed into a `!> \note with UNKNOWN_COMMENT` added at the start
of the line.
The script also includes checks to ensure that the annotations are not added to a line
multiple times.
The script also includes checks to ensure that the annotations are not added to
a line multiple times.
## `remove_extra_comments.pl`
### `remove_extra_comments.pl`
Post-processing script to remove any double lines which begin `! ******`
e.g.

18
tools/input_editing/emacs/README.md
View file

@ -1,5 +1,3 @@
*title: cp2k-mode.el README, author: Lianheng Tong, date: Wednesday, 2014/01/22*
# `cp2k-mode.el`
`cp2k-mode.el` provides a major mode in emacs for editing CP2K input
@ -21,11 +19,13 @@ files. It has been tested on emacs 2.1, 2.3 and 2.4.
- `show-all` when called unfolds all sections recursively.
- `show-subtree` when called unfolds a folded section recursively.
- New interactive functions:
- `cp2k-indent-line`: indents the line according to CP2K input syntax.
- `cp2k-beginning-of-block`: goes to the beginning of the subsection, marks the current cursor position.
- `cp2k-end-of-block`: goes to the ending of the subsection, marks the current cursor position.
- `cp2k-indent-line`: indents the line according to CP2K input syntax.
- `cp2k-beginning-of-block`:
goes to the beginning of the subsection, marks the current cursor position.
- `cp2k-end-of-block`:
goes to the ending of the subsection, marks the current cursor position.
### Key Bindings:
### Key Bindings
| character | |
| ------------- |---------------|
@ -39,6 +39,7 @@ files. It has been tested on emacs 2.1, 2.3 and 2.4.
| C-c C-t | `show-subtree`
## Installation
You need to put `cp2k-mode.el` in one of your local emacs lisp
directories, which is in the search path of your emacs installation.
@ -48,8 +49,8 @@ If you have never installed any packages manually before, and do not
know the search path of your emacs installation, then in your home
directory create directory:
```
~/.emacs.d/lisp/
```shell
mkdir ~/.emacs.d/lisp/
```
This is the usual place where the local/user defined emacs lisp
@ -78,6 +79,7 @@ to your `.emacs` file.
### Tell emacs to recognize `*.inp` automatically as a cp2k input file
Add
```emacs
(add-to-list 'auto-mode-alist '("\\.inp\\'" . cp2k-mode))
```

6
tools/input_editing/vim/README.md
View file

@ -1,5 +1,7 @@
## Plugin for the Vim editor
# Plugin for the Vim editor
For more information on
* obtaining and using the Vim editor plugin for CP2K, see [CP2K Tools:vim](https://www.cp2k.org/tools:vim)
* creating the Vim editor plugin file cp2k.vim (together with the manual), see [How to generate the CP2K input reference manual](https://manual.cp2k.org/trunk/generate_manual_howto.html)
* creating the Vim editor plugin file cp2k.vim (together with the manual),
see [How to generate the CP2K input reference manual](https://manual.cp2k.org/trunk/generate_manual_howto.html)

63
tools/plan_mpi_omp/README.md
View file

@ -2,11 +2,26 @@
## Overview
CP2K's grid-based calculation as well as DBCSR's block sparse matrix multiplication (Cannon algorithm) prefer a square-number for the total rank-count (2d communication pattern). This is not to be obfuscated with a Power-of-Two (POT) rank-count that usually leads to trivial work distribution (MPI).
CP2K's grid-based calculation as well as DBCSR's block sparse matrix
multiplication (Cannon algorithm) prefer a square-number for the total rank-count
(2d communication pattern). This is not to be obfuscated with a Power-of-Two (POT)
rank-count that usually leads to trivial work distribution (MPI).
It can be more efficient to leave CPU-cores unused to achieve this square-number property than using all cores with a "wrong" total rank-count (sometimes a frequency upside over an "all-core turbo" emphasizes this property further). Counter-intuitively, even an unbalanced rank-count per node i.e., different rank-counts per socket can be an advantage. Pinning MPI processes and placing threads requires extra care to be taken on a per-node basis to load a dual-socket system in a balanced fashion or to setup space between ranks for the OpenMP threads.
It can be more efficient to leave CPU-cores unused to achieve this square-number
property than using all cores with a "wrong" total rank-count (sometimes a
frequency upside over an "all-core turbo" emphasizes this property further).
Counter-intuitively, even an unbalanced rank-count per node i.e., different
rank-counts per socket can be an advantage. Pinning MPI processes and placing
threads requires extra care to be taken on a per-node basis to load a dual-socket
system in a balanced fashion or to setup space between ranks for the OpenMP threads.
Because of the above-mentioned complexity, a script for planning MPI/OpenMP-hybrid execution (`plan.sh`) is available. Here is a first example for running the PSMP-binary on an SMP-enabled (Hyperthreads) dual-socket system with 24&#160;cores per processor/socket (96&#160;hardware threads in total). At first, a run with 48&#160;ranks and 2&#160;threads per core comes to the mind (`48x2`). However, for instance 16&#160;ranks with 6&#160;threads per rank may be better for performance (`16x6`). To easily place the ranks, Intel MPI is used:
Because of the above-mentioned complexity, a script for planning MPI/OpenMP-hybrid
execution (`plan.sh`) is available. Here is a first example for running the
PSMP-binary on an SMP-enabled (Hyperthreads) dual-socket system with
24&#160;cores per processor/socket (96&#160;hardware threads in total).
At first, a run with 48&#160;ranks and 2&#160;threads per core comes to the mind
(`48x2`). However, for instance 16&#160;ranks with 6&#160;threads per rank may
be better for performance (`16x6`). To easily place the ranks, Intel MPI is used:
```bash
mpirun -np 16 \
@ -16,17 +31,33 @@ mpirun -np 16 \
exe/Linux-x86-64-intelx/cp2k.psmp workload.inp
```
**NOTE**: For hybrid codes, `I_MPI_PIN_DOMAIN=auto` is recommended as it spaces the ranks according to the number of OpenMP threads (`OMP_NUM_THREADS`). It is not necessary and not recommended to build a rather complicated `I_MPI_PIN_PROCESSOR_LIST` for hybrid codes (MPI plus OpenMP). To display and to log the pinning and thread affinization at the startup of an application, `I_MPI_DEBUG=4` can be used with no performance penalty. The recommended `I_MPI_PIN_ORDER=bunch` ensures that ranks per node are split as even as possible with respect to sockets (e.g., 36&#160;ranks on a 2x20-core system are put in 2x18 ranks instead of 20+16 ranks).
**NOTE**: For hybrid codes, `I_MPI_PIN_DOMAIN=auto` is recommended as it spaces
the ranks according to the number of OpenMP threads (`OMP_NUM_THREADS`).
It is not necessary and not recommended to build a rather complicated `I_MPI_PIN_PROCESSOR_LIST`
for hybrid codes (MPI plus OpenMP). To display and to log the pinning and thread
affinization at the startup of an application, `I_MPI_DEBUG=4` can be used with
no performance penalty. The recommended `I_MPI_PIN_ORDER=bunch` ensures that
ranks per node are split as even as possible with respect to sockets (e.g.,
36&#160;ranks on a 2x20-core system are put in 2x18 ranks instead of 20+16 ranks).
## Plan Script
To configure the plan-script, the metric of the compute nodes can be given for future invocations so that only the node-count is required as an argument. The script's help output (`-h` or `--help`) initially shows the "system metric" of the computer the script is invoked on. For a system with 48&#160;cores (two sockets, SMP/HT enabled), setting up the "system metric" looks like (`plan.sh <num-nodes> <ncores-per-node> <nthreads-per-core> <nsockets-per-node>`):
To configure the plan-script, the metric of the compute nodes can be given for
future invocations so that only the node-count is required as an argument.
The script's help output (`-h` or `--help`) initially shows the "system metric"
of the computer the script is invoked on. For a system with 48&#160;cores
(two sockets, SMP/HT enabled), setting up the "system metric" looks like
(`plan.sh <num-nodes> <ncores-per-node> <nthreads-per-core> <nsockets-per-node>`):
```bash
./plan.sh 1 48 2 2
```
The script is storing the arguments (except for the node-count) as default values for the next plan (file: `$HOME/.xconfigure-cp2k-plan`). This allows to supply the system-type once, and to plan with varying node-counts in a convenient fashion. Planning for 8&#160;nodes of the above kind yields the following output (`plan.sh 8`):
The script is storing the arguments (except for the node-count) as default
values for the next plan (file: `$HOME/.xconfigure-cp2k-plan`). This allows to
supply the system-type once, and to plan with varying node-counts in a
convenient fashion. Planning for 8&#160;nodes of the above kind yields the
following output (`plan.sh 8`):
```text
================================================================================
@ -43,7 +74,12 @@ The script is storing the arguments (except for the node-count) as default value
--------------------------------------------------------------------------------
```
The first group of the output displays POT-style (trivial) MPI/OpenMP configurations (penalty denotes potential communication overhead), however the second group (if present) shows rank/thread combinations with the total rank-count hitting a square number (penalty denotes waste of compute due to not filling each node). For the given example, 8&#160;ranks per node with 12&#160;threads per rank may be chosen (`8x12`) and MPI-executed:
The first group of the output displays POT-style (trivial) MPI/OpenMP
configurations (penalty denotes potential communication overhead), however the
second group (if present) shows rank/thread combinations with the total rank-count
hitting a square number (penalty denotes waste of compute due to not filling each
node). For the given example, 8&#160;ranks per node with 12&#160;threads per rank
may be chosen (`8x12`) and MPI-executed:
```bash
mpirun -perhost 8 -host node1,node2,node3,node4,node5,node6,node7,node8 \
@ -53,10 +89,15 @@ mpirun -perhost 8 -host node1,node2,node3,node4,node5,node6,node7,node8 \
exe/Linux-x86-64-intelx/cp2k.psmp workload.inp
```
The script also suggests close-by configurations (lower and higher node-counts) that hit the square-property ("Try also the following node counts"). The example (as exercised above) was to illustrate how the script works, however it can be very helpful when running jobs especially on CPUs with not many prime factors in the core-count. Remember, the latter can be also the case for virtualized environments that reserve some of the cores to run the Hypervisor i.e., reporting less cores to the Operating System (guest OS) when compared to the physical core-count.
The script also suggests close-by configurations (lower and higher node-counts)
that hit the square-property ("Try also the following node counts"). The example
(as exercised above) was to illustrate how the script works, however it can be
very helpful when running jobs especially on CPUs with not many prime factors in
the core-count. Remember, the latter can be also the case for virtualized
environments that reserve some of the cores to run the Hypervisor i.e., reporting
less cores to the Operating System (guest OS) when compared to the physical core-count.
## References
[https://github.com/hfp/xconfigure/raw/master/config/cp2k/plan.sh](https://github.com/hfp/xconfigure/raw/master/config/cp2k/plan.sh)
[https://xconfigure.readthedocs.io/cp2k/](https://xconfigure.readthedocs.io/cp2k/)
<https://github.com/hfp/xconfigure/raw/master/config/cp2k/plan.sh>
<https://xconfigure.readthedocs.io/cp2k/>

6
tools/precommit/README.md
View file

@ -27,7 +27,7 @@ process each file individually, which makes them much more lightweight.
The [precommit.py](./precommit.py) script can be readily installed as git hook:
```
```shell
ln -fs ../../tools/precommit/precommit.py .git/hooks/pre-commit
```
@ -39,7 +39,7 @@ tedious installation a remote server is used by default. It is hosted at
The same server can also be started locally when Docker is available:
```
```shell
./start_local_server.sh
```
@ -48,7 +48,7 @@ The server can also be installed without Docker by following the steps in the
Once the server is up and running it can be used like this:
```
```shell
$ export CP2K_PRECOMMIT_SERVER="http://127.0.0.1:8080"
$ ./precommit.py
Running precommit checks using 8 workers and server: http://127.0.0.1:8080

2
tools/precommit/precommit.py
View file

@ -167,7 +167,7 @@ def print_box(fn, message):
def process_file(fn, allow_modifications):
# Make a backup copy.
orig_content = Path(fn).read_bytes()
bak_fn = SCRATCH_DIR / f"{Path(fn).name}_{int(time())}.bak"
bak_fn = SCRATCH_DIR / f"{Path(fn).name}_{time()}.bak"
shutil.copy2(fn, bak_fn)
if re.match(r".*\.(F|fypp)$", fn):

79
tools/toolchain/README.md
View file

@ -1,18 +1,19 @@
# The CP2K Toolchain
#### Options
## Options
To use the CP2K toolchain installer, you may want to first follow
the instructions given in installer help message:
```console
```shell
> ./install_cp2k_toolchain.sh --help
```
#### Basic usage
## Basic usage
If you are new to CP2K, and want a basic CP2K binary, then just calling
```console
```shell
> ./install_cp2k_toolchain.sh
```
@ -21,26 +22,28 @@ existing) and build libint, libxc, fftw and openblas (MKL will be used
instead if MKLROOT env variable is found) from scratch, and give you
a set of arch files that allow you to compile CP2K.
#### Complete toolchain build
## Complete toolchain build
For a complete toolchain build, with everything installed from
scratch, use:
```console
```shell
> ./install_cp2k_toolchain.sh --install-all
```
##### Package settings
### Package settings
One can then change settings for some packages, by setting
`--with-PKG` options after the `--install-all` option. e.g.:
```console
```shell
> ./install_CP2K_toolchain.sh --install-all --with-mkl=system
```
will set the script to look for a system MKL library to link, while
compile other packages from scratch.
##### MPI implementation choice
### MPI implementation choice
If you do not have a MPI installation, by default the `--install-all`
option will install MPICH for you. You can change this default
@ -48,10 +51,10 @@ behavior by setting `--mpi-mode` after the `--install-all` option.
## Trouble Shooting
Below are solutions to some of the common problems you may encounter when running
this script.
Below are solutions to some of the common problems you may encounter when
running this script.
##### The script terminated with an error message while installing a particular package.
### The script terminated with an error message
Look at the error message. If it does not indicate the reason for
failure then it is likely that some error occurred during
@ -64,12 +67,12 @@ parallel make processes were initiated. By default the script
tries to use all of the processors on you node. You can override
this behavior using `-j` option.
##### The script failed at a tarball downloading stage
### The script failed at a tarball downloading stage
Try run again with `--no-check-certificate` option. See the help
section for this option for details.
##### I have loaded libraries using module load XYZ, but --with-XYZ=system cannot find the XYZ library
### I've used --with-XYZ=system cannot find the XYZ library
The installation script in "system" mode will try to find a library
in the following system PATHS: `LD_LIBRARY_PATH`, `LD_RUN_PATH`,
@ -81,7 +84,7 @@ MKLROOT environment variable.
You can use:
```console
```shell
> module show XYZ
```
@ -98,8 +101,13 @@ to look for the library.
## Licenses
The toolchain only downloads and installs packages that are [compatible with the GPL](https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean). The follow table list the licenses of all those packages. While the toolchain does support linking proprietary software packages, like e.g. MKL, these have to be installed separately by the user.
The toolchain only downloads and installs packages that are
[compatible with the GPL](https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean).
The following table list the licenses of all those packages. While the toolchain
does support linking proprietary software packages, like e.g. MKL, these have to
be installed separately by the user.
<!-- markdownlint-disable MD013 -->
| Package | License | GPL Compatible |
| --------- | --------------------------------------------------------------------------------------- | -------------- |
| cmake | [BSD 3-Clause](https://gitlab.kitware.com/cmake/cmake/raw/master/Copyright.txt) | Yes |
@ -129,10 +137,11 @@ The toolchain only downloads and installs packages that are [compatible with the
| spglib | [BSD 3-Clause](https://github.com/atztogo/spglib/blob/master/COPYING) | Yes |
| superlu | [BSD 3-Clause](https://github.com/xiaoyeli/superlu/blob/master/License.txt) | Yes |
| valgrind | [GPL](https://sourceware.org/git/?p=valgrind.git;a=blob_plain;f=COPYING;hb=HEAD) | Yes |
<!-- markdownlint-enable MD013 -->
# For Developers
## For Developers
## Structure of the toolchain scripts:
### Structure of the toolchain scripts
- `install_cp2k_toolchain.sh` is the main script that will call all
other scripts. It contains default flag settings, user input
@ -180,22 +189,22 @@ The toolchain only downloads and installs packages that are [compatible with the
all of `${VARIABLE}` items in `arch_base.tmpl` to give the cp2k arch
files.
## `enable-FEATURE` options
### `enable-FEATURE` options
The `enable-FEATURE` options control whether a FEATURE is enabled or disabled.
Possible values are:
- `yes` (equivalent to using the option-keyword alone)
- `no`
## `with_PKG` and `PKG_MODE` variables:
### `with_PKG` and `PKG_MODE` variables
The `with_PKG` options controls how a package is going to be installed:
The `with_PKG` options controls how a package is going to be
installed:
- either compiled and installed from source downloaded
(`install`, or the option-keyword alone),
(`install`, or the option-keyword alone),
- or linked to locations provided by system search paths (`system`),
- or linked to locations provided by the user
(`<path>`, path to some directory),
- or linked to locations provided by the user (`<path>`, path to some directory),
- or that the installer won't be used (`no`).
For most packages the `with_pkg` variables will act like a switch for
@ -206,7 +215,7 @@ selector. In this case, while `with_PKG` controls the installation
method, the `PKG_MODE` variable picks which package to actually use.
This provides more flexibility.
## The IF_XYZ constructs
### The IF_XYZ constructs
Due to the fact that `install_cp2k_toolchain.sh` needs to produce
several different versions of the arch files: `psmp`, `pdbg`,
@ -215,7 +224,7 @@ different arch file versions.
The solution used by this script is to use a syntax construct:
```
```shell
IF_XYZ(A | B)
```
@ -225,7 +234,7 @@ is not passed as command line option (python `parse_if.py` filename).
The `IF_XYZ(A|B)` construct can be nested, so things like:
```
```shell
IF_XYZ(IF_ABC(flag1|flag2) | flag3)
```
@ -233,7 +242,7 @@ will parse to *flag1* if both *XYZ* and *ABC* are present in the command
line arguments of `parser_if.py`, to *flag2* if only *XYZ* is present,
and *flag3* if nothing is present.
## To ensure portability:
### To ensure portability
- one should always pass compiler flags through the
`allowed_gcc_flags` and `allowed_gfortran_flags` filters in
@ -243,13 +252,13 @@ and *flag3* if nothing is present.
- note that `allowed_gcc_flags` and `allowed_gfortran_flags` do not work
with `IF_XYZ` constructs. So if you have something like:
```
```shell
FCFLAGS="IF_XYZ(flag1 flag2 | flag3 flag4)"
```
Then you should break this into:
```
```shell
XYZ_TRUE_FLAGS="flags1 flags2"
XYZ_FALSE_FLAGS="flags3 flags4"
# do filtering
@ -259,7 +268,7 @@ XYZ_FALSE_FLAGS="$(allowed_gcc_flags $XYZ_FALSE_FLAGS)"
So that:
```
```shell
FCFLAGS="IF_XYZ($XYZ_TRUE_FLAGS | $XYZ_FALSE_FLAGS)"
```
@ -271,17 +280,17 @@ FCFLAGS="IF_XYZ($XYZ_TRUE_FLAGS | $XYZ_FALSE_FLAGS)"
- Try to avoid as much hard coding as possible:
e.g. instead of setting:
```
```shell
./configure --prefix=some_dir CC=mpicc FC=mpif90
```
use the common variables:
```
```shell
./configure --prefix=some_dir CC=${MPICC} FC=${MPIFC}
```
## To keep maintainability it is recommended that we follow the following practices:
## To keep maintainability it is recommended that we follow these practices
- Reuse as much functionality from the macros defined in the
`script/toolkit.sh` as possible