dev-zero/cp2k

Quantum chemistry and solid state physics software package

cp2k's Issues

cmake: basic COSMA support

includes CMake flag and detection

cmake module is provided directly by cosma

cmake: basic libgrid support

includes CMake flag and detection

I would not bother about that one. the grid module will most probably never be a standalone library at least not in its current form. What is there is sufficient for now.

cmake: support for overriding __DATA_DIR

maybe tie the base path to the install dir (/usr/local) via the CMake GNU module?

cmake: check for /proc/stat access

some platforms do not have /proc/stat (or /proc at all), we should check for it and add __NO_STATM_ACCESS automatically

cmake: support DEBUG build

cmake: Github CI support for CMake

see also what we have for DBCSR, minimal version just to verify the CMakeLists.txt with the target CMake and Ninja version would be useful

should also include cmake-format and/or cmake-lint

cmake: 'dist' target to build tarball

cmake: basic libxc support

includes CMake flag and detection

libxc has cmake module already when we compile it (both libxc 4.3.4 and libxc 5.0.0) so I will include it in the cmake directory just in case.

cmake: check libxc version/API, blacklist

libxc broke the API (and some functionals) in the past, it would be nice if the CMake macro would detect that and error out with a proper message

spack cmake package.

I've tried to build this feature/cmake branch with spack. My package currently looks like this:

# Copyright 2013-2020 Lawrence Livermore National Security, LLC and other
# Spack Project Developers. See the top-level COPYRIGHT file for details.
#
# SPDX-License-Identifier: (Apache-2.0 OR MIT)

from spack import *


class Cp2kCmake(CMakePackage):
    """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
    """

    homepage = "https://www.cp2k.org"
    url      = "https://github.com/dev-zero/cp2k"
    git      = "https://github.com/dev-zero/cp2k.git"

    version('develop', branch='feature/cmake')

    build_directory = 'spack-build'

    variant('mpi', default=True, description='Enable MPI support')
    variant('smm', default='libxsmm', values=('libxsmm', 'libsmm', 'blas'),
            description='Library for small matrix multiplications')

    depends_on('blas')
    depends_on('lapack')
    depends_on('fftw-api@3')
    depends_on('mpi@2:', when='+mpi')

    depends_on('dbcsr')
    depends_on('[email protected]:~header-only', when='smm=libxsmm')

    # Build dependencies
    depends_on('python', type='build')
    depends_on("py-fypp", type="build")
    depends_on("pkgconfig", type='build')

    conflicts('smm=libxsmm',  when='target=aarch64:', msg='libxsmm is not available on arm')
    
    # Make sure dependencies use openmp threading
    conflicts('^fftw~openmp')
    conflicts('^openblas threads=none')
    conflicts('^openblas threads=pthreads')

    def cmake_args(self):
        return [
            self.define_from_variant('USE_MPI', 'mpi'),
        ]

I had to fix:

• two build errors, one about get_accdrv_active_device_id not being exported from dbcsr, so I patched dbcsr locally. And another one about truncated lines due to CPABORT calls, which is just trimmed a bit.
• adding a make install target: #41

I create the following environment file in the parent folder where I had cloned both cp2k and dbcsr:

$ ls
cp2k  dbcsr  spack.yaml
$ cat spack.yaml 

spack:
  specs: 
    - cp2k-cmake@develop %gcc@:9 ^openblas threads=openmp ^dbcsr@develop +openmp +cuda cuda_arch=70 ^cuda@:11.0 ^fftw +openmp
  develop:
    cp2k-cmake:
      path: ./cp2k
      spec: cp2k-cmake@develop
    dbcsr:
      path: ./dbcsr
      spec: dbcsr@develop

$ spack -e . install -v
...
[+] /home/harmen/spack/opt/spack/linux-ubuntu20.04-zen2/gcc-9.3.0/cp2k-cmake-develop-aytliij634jsqmkoybvbefdm6qojl3dy

and it works just fine. I wonder if the spack package would get a lot shorter after migration to cmake.

I'm just leaving this here, cause I don't know where else to share it.

cmake: ScaLAPACK support

includes CMake flag and detection. Question here: should we allow for an MPI-build without ScaLAPACK at all? Seems untested and I would vote 'no'.

cmake: libvori support

includes CMake flag and detection, it may make sense to extend libvori's CMakeLists.txt by an Export like we have for DBCSR such that one only has to set the CMake include path to get the lib

cmake: make building libcp2k optional

cmake: basic spglib support

includes CMake flag and detection

Took the cmake module from SIRIUS (thanks to the 2 Simons)

cmake: add -fallow-argument-mismatch for MPICH and GCC-10+

see cp2k/dbcsr#416

cmake: add 'regression-tests' target to run regtests

cmake: add CTest for running true unittests

cmake: require specific DBCSR configuration and version

There are numerous combinations on how to build CP2K and DBCSR and the combination of them. At the moment, building DBCSR as a submodule inside the current build system restricts the combinations and ensures that options are used consistently (for example MPI, CUDA, etc.).
Since we cannot test all combinations it may be a good idea to check for consistent options rigorously. DBCSR possibly has to be extended to export them in a parseable fashion.

cmake: detect linking against macOS Accelerate framework

needs special treatement due to non-standard BLAS/LAPACK interface via -D__ACCELERATE, see also DBCSRs CMake

cmake: detect sockets availability

the iPi driver needs socket support which may be unavailable (MinGW) or broken, we should check for it automatically

cmake: LIBINT version and configuration checking

we need a libint with specific flags, CMake could verify that what the user provides is sufficient

cmake: QUIP support

includes CMake flag and detection, possibly adding -fallow-argument-mismatch is needed for older QUIP versions and with GCC-10+

cmake: PEXSI support

includes CMake flag and detection

cmake: add CUDA/HIP support

some of this can be taken from DBCSR, but may need to be revisited since CMake gained a couple of feats/bugfixes since it started over there. Also: it may be useful to use sub-CMakeLists.txt for the dirs where this applies to avoid a mess.

also include CUDA Profiling support, see DBCSR for that part

cmake: add grid_miniapp target

cmake: support tools/ building

we have a couple of interesting tools/ which may be built with CMake as well to ensure they still work, add support for those extra targets, possibly ensuring that their CMakeLists.txt can be easily used standalone (similar to DBCSRs examples CMakeLists.txt which with ~3 line changes can be used standalone)

cmake: document multi-version building

the current build system allows to build multiple ARCHs and VERSIONs at the same time, of this multi-version may be worthwhile and should be doable when using Ninja (?). The least we need is some documentation that people have to have different build dirs for now and/or a script to automate multi-version builds like before

cmake: basic SIRIUS support

includes CMake flag and detection

cmake: revise default compiler flags mechanism

currently we are setting the global compiler flags via CMAKE_FLAGS, but the modern way is via generator expressions

cmake: document configuration recipes/preloads

in the current build system configurations can be stored as arch/ files, even though the default invocation should generate the arch file, people may still want to store/document/share configurations for specific platforms and setups. In DBCSR we have https://cp2k.github.io/dbcsr/develop/page/2-user-guide/1-installation/1-cmake-build-recipes.html, another option to collect configurations are CMake preload scripts

cmake: basic LIBINT support

includes CMake flag and detection

cmake: add 'python-bindings' target to build Python-bindings for libcp2k

also include things like cp2k --version, see also cp2k#1273 (and the latest failures on Alps/Eiger)

include grid_unittest

cmake: FPGA support

includes CMake flag and detection, probably have to contact original devs for verification of this, and maybe update deps since Intels oneAPI

cmake: support various dependency-less flags

everything not covered elsewhere:

• __MKL (while not dependency-less, we always get BLAS/LAPACK(/ScaLAPACK) and simply have to detect the vendor
• __GRID_CORE
• __PILAENV_BLOCKSIZE
• __CRAY_PM_ACCEL_ENERGY and __CRAY_PM_ENERGY
• __NO_MPI_THREAD_SUPPORT_CHECK
• __HAS_IEEE_EXCEPTIONS
• __CHECK_DIAG

cmake: check for ELPA version

ELPA has a working runtime detection and maintained the API for some time, nevertheless we should check for an ELPA version which has this API. Detecting a too old ELPA version should lead to a warning when linking dynamically, and an error when linking statically

cmake: upstream FindBLAS.cmake changes

currently there is a patched FindBLAS (and thus FindLAPACK) module, this is made such that we can detect a separately provided OpenMP-safe OpenBLAS. Ideally we should factor that out as a COMPONENTS argument for FindBLAS and send it to upstream for inclusion. At the same time possibly also implement the same for Intel MKL (which also provides different sets of threaded/non-thread libraries).

cmake: 'doc' target for building manual

cmake: basic ELPA support

includes CMake flag and detection

cmake: support the smm library

cmake: PLUMED support

includes CMake flag and detection

cmake: check SIRIUS version

SIRIUS changed the API in the past, we may want to check for a recent enough version

cmake: FFTW support

includes flag and detection, but we may have to check the lib further for threading and MPI