When run with --enable-cuda, the toolchain script sets the GPU card version automatically to K20X (cf https://github.com/cp2k/cp2k/blob/master/tools/toolchain/install_cp2k_toolchain.sh#L1072).

Instead, there should be a command line option for choosing the right GPU version among the options allowed in DBCSR (cf https://github.com/cp2k/dbcsr/blob/develop/Makefile.inc#L20).

OpenBLAS hard-compiles the number of cores available at compile time as the max number of threads.
In an automated virtualized build environment, the number of cores is usually rather small, resulting in an OpenBLAS which does not scale to the number of available cores at runtime.

Spack (and Linux distros) for example have an explicit detection for a virtualized runtime and set NUM_THREADS=64. See also https://github.com/xianyi/OpenBLAS/wiki/faq#usage-1

maybe something like development version instead?

I'd suggest that we restrict formatting conventions and pretty make target to indentation/alignment only for the following reasons:

• less noise in commit history and less conflicts because formatting commits would occur less often and only change leading whitespace.
• this convention is easier to explain and justify to contributors while the current formatting conventions are a matter of taste. There should be no need to run make pretty before or after every single commit just to satisfy the formatting checker.
• fypp compatibility: the prettify used by cp2k is not compatible with fypp and currently ignores files containing fypp directives. The currently maintained fprettify version has less features (only whitespace formatting) but is compatible with fypp directives. I recommend to use fprettify --disable-whitespace for cp2k.

However some useful features of legacy prettify will no longer be available, I don't see a way to make these features fypp compatible:

• sorting of subroutine/function dummy arguments
• removal of unneeded use statements

Can we use another tools to check for unneeded use statements?

I wonder whether we want to keep our doxify script that autogenerates doxygen headers because it is not compatible with fypp. In turn I'd suggest to remove empty doxygen headers since empty documentation is rather meaningless.

For DBCSR we have similar discussions: cp2k/dbcsr#95, cp2k/dbcsr#39

Sometimes, the test QS/regtest-pod/hellium-pbe-5A.inp gives wrong results, for example on POPT version at UZH, see:

https://dashboard.cp2k.org/archive/gcc492-mkl1121-popt/rev_18530.txt

or PSMP

https://dashboard.cp2k.org/archive/gcc492-mkl1121-psmp/rev_18523.txt

Submitted by @alazzaro

The PR #21 led to a number of dashboard failures.

This seems to be a compiler bug as only gcc 7.3.0 and 4.9.2 crash while gcc 8.2.0 works fine.

Looking at the code it seems that an ALLOCATABLE is passed as an optional argument.

@RubenStaub, ALLOCATABLES often cause problems - unfortunately. So, maybe you could just pass in SUM(kTS) instead of the whole kTS array?

During a meeting with the others developers of sirius, it was suggested that sirius should be activated by default in cp2k (it is not at the moment because of some others issues hopefully fixed now). SIRIUS integration to cp2k is already in good shape despite the few glitches with the build system. We have few test cases for regression and basic functionalities up and running. The build has passed basic CI tests (I do not the psmp tests activated) but I think it would be a good opportunity to catch others potential problems (like the farming issue) in a more systematic way if SIRIUS is built by default.

I already have a patch ready for it but I wanted to have your view on this before making a pull request. I know it goes against the changes I made yesterday, but most of the changes where needed anyway.

At line 2726 of file /gpfs/data/krack/rt/auto/pdbg/cp2k/src/optimize_embedding_potential.F
Fortran runtime error: Unit number is negative and unit was not already opened with OPEN(NEWUNIT=...)

Error termination. Backtrace:
#0 0x3443869 in data_transfer_init
at /opt/tmp/stadler_h/src/gcc-7.3.0/libgfortran/io/transfer.c:2686
#1 0x9f241e in print_folded_coordinates
at /gpfs/data/krack/rt/auto/pdbg/cp2k/src/optimize_embedding_potential.F:2726

Unless on a detached HEAD, .git/HEAD contains something like ref: refs/heads/master (or a reference to the branch) and does not necessarily get updated on a git pull. So, to make this work one has to also parse the content and add a dependency on the referenced file (see also the changes to tools/regtesting/do_regtest in PR #11)

Building CP2K (respectively DBCSR) with PGI 18.7 yields the following errors:

PGF90-S-0091-Constant expression of wrong data type (dbcsr_types.F90: 495)
PGF90-S-0091-Constant expression of wrong data type (dbcsr_types.F90: 495)
   0 inform,   0 warnings,   2 severes, 0 fatal for dbcsr_types

older versions of PGI 18.x may instead produce an Internal Compiler Error instead.

A support ticket is open at PGI for this very issue. Since this is valid Fortran and other compilers have no problem with this part, there is not much we can do about.

Keeping this ticket as a reminder to test newer versions of PGI once they get released.

Due to its heritage, Flang has very similar issues: flang-compiler/flang/issues/239, flang-compiler/flang/issues/360, flang-compiler/flang/issues/424

Running the default toolchain on a
Intel(R) Xeon(R) CPU E5-2650v4
using gcc 5.3 results in an error in the compilation of libxsmm:

/tmp/ccToV8ay.s: Assembler messages:
/tmp/ccToV8ay.s:4090: Error: bad register name %zmm16' /tmp/ccToV8ay.s:4110: Error: bad register name %zmm13'
/tmp/ccToV8ay.s:4111: Error: bad register name %zmm11' /tmp/ccToV8ay.s:4112: Error: bad register name %zmm14'
/tmp/ccToV8ay.s:4124: Error: no such instruction: vpxord %zmm16,%zmm13,%zmm12' /tmp/ccToV8ay.s:4126: Error: no such instruction: vpxord %zmm16,%zmm11,%zmm11'
/tmp/ccToV8ay.s:4128: Error: no such instruction: `vpxord %zmm16,%zmm14,%zmm15'

compilation flag is SSE4.2

When compiling with CUDA support, the toolchain script does not automatically add the path to CUDA libraries.

To do:

• Add ${CUDA_PATH}/lib64 to LDFLAGS

A list of small annoying details that make CP2K more cumbersome to build:

• Users should be explicitly instructed that they need to have the environment variable CUDA_PATH defined if compiling with CUDA support (cf line https://github.com/cp2k/cp2k/blob/master/tools/toolchain/install_cp2k_toolchain.sh#L1071). Or this should be done by cp2k/tools/toolchain/install/setup.
• The installation instructions (https://github.com/cp2k/cp2k/blob/master/INSTALL.md) do not make it very clear visually that the toolchain script is the recommended way to go for installing CP2K
• The installation instructions in the repo (https://github.com/cp2k/cp2k/blob/master/INSTALL.md) do not correspond exactly to the installation instructions on the official website (https://www.cp2k.org/howto:compile and https://www.cp2k.org/howto:compile_with_cuda), make it confusing for users: should users follow the instructions in the repo? The ones on the website? What is more up-to-date?)

https://sourceforge.net/projects/cp2k/support

The regtesting is great, but it takes a lot of time. It would be good if do_regtest had some machinery to only run a few tests of each functionality (preferably those without huge runtimes) in order to make sure the CP2K basically runs fine.

This could be done e.g. by additional tagging in TEST_DIRS and/or individual TEST_FILES.

I have an issue with a hanging PR. It seems that the PR creation was interrupted during processing and it does not show up in the PR list (should be #55) as an issue. When I try now to create the PR again a validation error is shown claiming that the PR already exists. Does anybody know how to resolve this?

The regtest logs accessible via the CP2K Dashboard) (for example, this one) do not indicate which DBCSR version was used in the build, and this information is cumbersome to retrieve a posteriori now that DBCSR is used via git submodules.

Could the regtests log be completed to include the DBCSR version (or perhaps even better: SHA) used in the CP2K build?

the addition of SIRIUS to the toolchain broke the "default" configuration (running the toolchain without any arguments):

$ ./install_cp2k_toolchain.sh
WARNING: (./install_cp2k_toolchain.sh, line 309) No MPI installation detected on you system. Ignore this message if you are using Cray Linux Environment
nvcc not found, disabling CUDA by default
Not using MPI, so scalapack is disabled.
Not using MPI, so PEXSI is disabled.
ERROR: (./install_cp2k_toolchain.sh) For SIRIUS to work you need a working gsl library use --with-gsl option to specify if you wish to install the library or specify its location.

CC @mtaillefumier

When building CP2K using the toolchain script, the nvcc-flag gpu-architecture gets set twice, causing a compilation error.

To reproduce, create an arch file with:

./install_cp2k_toolchain.sh --with-sirius=no --with-gsl=no --with-libxsmm=install \
  --with-openblas=system --with-fftw=system --with-reflapack=no --enable-cuda \ 
  --enable-omp  --with-spglib=no --with-json-fortran=no

Failing compilation message:

nvcc -D__GNUC__=4 -D__GNUC_MINOR__=9 -Xcompiler=--std=gnu++98 -c \ 
-arch sm_35 -Xcompiler='-fopenmp' --std=c++11 -D__ACC -D__DBCSR_ACC \
-D__PW_CUDA  -D__LIBXSMM  -D__parallel  -D__FFTW3  -D__LIBINT \
-D__LIBINT_MAX_AM=6 -D__LIBDERIV_MAX_AM1=5 -D__LIBXC -D__SCALAPACK \
-D__HDF5   -arch sm_35 -I'/users/alicej/fix_cp2k_build/cp2k/exts/dbcsr/src' 

nvcc fatal   : redefinition of argument 'gpu-architecture'

Notice how -arch sm_35 occurs twice in the compilation instruction.

A related problem is that the Berry phase dipole only works with
equal occupation for all states (same for OT). This means the
smearing option is not possible (metals!), but simple diagonalization
schemes without smearing should work.

The fractional/scaled coordinate doesn't match with the cell_vector when the box is not orthogonal.

• https://www.cp2k.org/download
• https://www.cp2k.org/dev:release_checklist ... might have to change considerably, depending on availability of CI infrastructure to automatically build tarballs
• https://www.cp2k.org/dev:regtesting
• https://www.cp2k.org/dev:starting
• https://www.cp2k.org/performance
• https://www.cp2k.org/dev
• https://www.cp2k.org/news
• https://www.cp2k.org/howto:install_with_plumed
• https://www.cp2k.org/howto:cp2k_omen
• https://www.cp2k.org/tools:cubecruncher
• https://www.cp2k.org/admin:kohn ... rename to sham?
• https://www.cp2k.org/sidebar
• https://www.cp2k.org/about
• https://www.cp2k.org/dbcsr
• https://www.cp2k.org/tools:emacs
• https://www.cp2k.org/version_history

For example here: https://github.com/cp2k/cp2k/runs/21516830

The users can't possibly know what actually failed or what they would have to do to remedy the situation.
Furthermore, clicking the view more details leads back to the (almost) same page.

The cubecruncher is a very useful tool that is completely independent from the CP2K code base. Hence, with a bit of love (tests and docu) it could be made available to a larger audience. Eventually, it might even get included in Debian / Fedora.

This would also make for a good intern or GSOC project.

A growing fraction of our code are bash scripts. Hence, we should look into using a linter like
ShellCheck.

I think we should add SPDX License Identifier to our file headers. DBCSR already took the lead.

Version 1.0 of the DBCSR is ready for the inclusion in DBCSR. Let's start a discussion on how we can achieve that (submodule, copy, ...)

Dear Developers,

I've experienced that enabling CUDA support slows down CP2K compared with pure CPU version. I tried various ways to build the executable (mostly .popt) arise from this howto, but nothing changed.

As I know, GPU is used to accelerate matrix multiplications by DBCSR, that is set to employ a list of precomputed kernels for NVIDIA K20X, K40, K80, and P100. So I've got parameters list for my cards using this tutorial. And again, CPU version is much faster in, say, the official H2O-64 benchmark and in my setups as well.

I understand that is of a big request, but can GPU part of DBCSR be rewritten with the use of conventional CUDA tools or OpenACC as in LSDalton instead of precomputed kernels?

Best wishes

I have attempted to build for the Intel Broadwell cpu with the latest 6.1 release as well as the current git repo. In each case I end up with the following error:

...
ifort -fopenmp -m64 -I/projects/opt/intel/compilers_and_libraries_2018.3.222/linux/mkl/include -I'/usr/include' -I'/home/dog/benchmark_code_characterization/cp2k/cp2k/tools/toolchain/install/libint-1.1.6/include' -I'/home/dog/benchmark_code_characterization/cp2k/cp2k/tools/toolchain/install/libxc-4.0.3/include' -I'/home/dog/benchmark_code_characterization/cp2k/cp2k/tools/toolchain/install/libxsmm-1.9.0/include' -D__LIBXSMM -D__FFTW3 -D__LIBINT -D__LIBINT_MAX_AM=6 -D__LIBDERIV_MAX_AM1=5 -D__LIBXC -D__COMPILE_ARCH=""local"" -D__COMPILE_DATE=""Mon Oct 22 11:21:44 MDT 2018"" -D__COMPILE_HOST=""cn422"" -D__COMPILE_REVISION=""git:40be634"" -D__DATA_DIR=""/home/dog/benchmark_code_characterization/cp2k/cp2k/data"" -Wl,--enable-new-dtags -L'/usr/lib64' -Wl,-rpath='/usr/lib64' -L'/home/dog/benchmark_code_characterization/cp2k/cp2k/tools/toolchain/install/libint-1.1.6/lib' -Wl,-rpath='/home/dog/benchmark_code_characterization/cp2k/cp2k/tools/toolchain/install/libint-1.1.6/lib' -L'/home/dog/benchmark_code_characterization/cp2k/cp2k/tools/toolchain/install/libxc-4.0.3/lib' -Wl,-rpath='/home/dog/benchmark_code_characterization/cp2k/cp2k/tools/toolchain/install/libxc-4.0.3/lib' -L'/home/dog/benchmark_code_characterization/cp2k/cp2k/tools/toolchain/install/libxsmm-1.9.0/lib' -Wl,-rpath='/home/dog/benchmark_code_characterization/cp2k/cp2k/tools/toolchain/install/libxsmm-1.9.0/lib' -L/home/dog/benchmark_code_characterization/cp2k/cp2k/lib/local/ssmp -o /home/dog/benchmark_code_characterization/cp2k/cp2k/exe/local/libcp2k_unittest.ssmp libcp2k_unittest.o -lcp2kstart -lcp2kmc -lcp2kswarm -lcp2kmotion -lcp2kthermostat -lcp2kemd -lcp2ktmc -lcp2kmain -lcp2kgrid -ldbcsrarnoldi -ldbcsrx -lcp2kshg_int -lcp2keri_mme -lcp2kminimax -lcp2khfxbase -lcp2ksubsys -lcp2kxc -lcp2kao -lcp2kinput -lcp2kpw -lcp2kfft -lcp2kdbcsr_tensor -ldbcsr -ldbcsrmm -ldbcsrops -ldbcsrbblock -ldbcsrbdist -ldbcsrbase -ldbcsrdata -lmicsmm -lclsmm -lcp2kacc -lcp2kaccmic -lcp2kaccopencl -lcp2kfm -lcp2kcommon -lcp2kmpiwrap -lcp2kbase -lxsmmf -lxsmm -ldl -lpthread -lxcf03 -lxc -Wl,-Bstatic -lderiv -lint -Wl,-Bdynamic -lfftw3 -lfftw3_omp -Wl,--start-group /projects/opt/intel/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64/libmkl_gf_lp64.a /projects/opt/intel/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64/libmkl_core.a /projects/opt/intel/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64/libmkl_sequential.a -Wl,--end-group -lpthread -lm -ldl -lstdc++
libcp2k_unittest.o: In function main': libcp2k_unittest.c:(.text+0x0): multiple definition of main'
/projects/opt/intel/compilers_and_libraries_2018.3.222/linux/compiler/lib/intel64_lin/for_main.o:for_main.c:(.text+0x0): first defined here
/projects/opt/intel/compilers_and_libraries_2018.3.222/linux/compiler/lib/intel64_lin/for_main.o: In function main': for_main.c:(.text+0x2a): undefined reference to MAIN__'
make[3]: *** [/home/dog/benchmark_code_characterization/cp2k/cp2k/exe/local/libcp2k_unittest.ssmp] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [all] Error 2
make[1]: *** [ssmp] Error 2
make: *** [all] Error 2

Here are the steps I followed to build. I have loaded the intel/18.0.3 module which sets CC, CXX, FC, as well as MKLROOT.

1. Grabbed the latest repo

2. cd cp2k/tools/toolchain

3. $ ./install_cp2k_toolchain.sh -j 8 --mpi-mode=no --with-gcc=no
   --with-mkl=/projects/opt/intel/compilers_and_libraries_2018.3.222/linux/mkl
   --enable-omp
   --with-libxc=install
   --with-libint=install
   --with-fftw=system
   --with-mkl=system
   --with-libxsmm=install
   --with-reflapack=no

   This concludes successfully with the following output.

Done!
Now copy:
cp /home/dog/benchmark_code_characterization/cp2k/cp2k/tools/toolchain/install/arch/* to the cp2k/arch/ directory
To use the installed tools and libraries and cp2k version
compiled with it you will first need to execute at the prompt:
source /home/dog/benchmark_code_characterization/cp2k/cp2k/tools/toolchain/install/setup
To build CP2K you should change directory:
cd cp2k/
make -j 8 ARCH=local VERSION="sopt sdbg ssmp"

4. I followed the steps above and the "make -j 8...." line results in the error message above after some time in the build process.

On FreeBSD some people override compilers. By default, clang and gfortran are used.
Compiler information could be useful in cp2k -v.

Submitted by @yurivict

The current trunk fails in the valgrind test (SDBG) on the input QS/regtest-rel/Hg_rel.inp with message: "Matrix diagonalization failed" .

I found that the problem goes away if we run without -ffast-math flag, therefore I can assume that it is due to a numerical instability of the test.

Submitted by @alazzaro .

By using the github search in the repository, I see that there are

25 code results

https://github.com/cp2k/cp2k/search?q=svn&unscoped_q=svn

Besides the legacy reference in some scripts, for example:

cp2k/tools/build_utils/get_revision_number

there are other scripts that can probably be removed, for example:

cp2k/tools/svn2cl

while the FORCE_EVAL/SUBSYS/COORD allows to add an optional string after the coordinates to specify the connectivity, additional columns in a XYZ file are ignored, since the XYZ file format is not standardized. Nevertheless, it would be nice to have an option to tell CP2K to use the N-th additional column in a XYZ for the connectivity (or possibly other things).

@KanySUI is that about right?

maybe put them all into one cp2k-6.1.0-bin.tar.gz?

I believe this race affects at least these tests:

• QS/regtest-gpw-5/si7c_broy_gapw_a04_restart.inp
• QS/regtest-gapw-1/c8_broy_gapw_all_xashh.inp
• QS/regtest-gpw-7/si8_broy_kry_r.inp

But probably there are more. After we fix this we should revisit the thresholds of all tests that use SCF_GUESS RESTART

The good news is that it's easy to reproduce as it shows up in about 10% of the runs:

for i in {1..10} ; do 
  ../../../exe/local/cp2k.ssmp si7c_broy_gapw_a04_restart.inp | grep -e "Total energy:"
done

The test QS/regtest-kg/H2_H2O-kglri.inp, touched in the commit ebf37dd, fails on Daint with the farming regtest for 8 ranks. It doesn't crash when farming is not used and with fewer ranks. The log is:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x599e57f in ???
        at /home/abuild/rpmbuild/BUILD/glibc-2.22/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
#1  0xbb4af7 in __qs_grid_atom_MOD_initialize_atomic_grid
        at /store/uzh/uzh1/CP2K_AUTO_REGTEST/DAINT/CRAY_XC50-gfortran_mc/psmp/cp2k/src/qs_grid_atom.F:355
#2  0x15dc90f in init_kg_env
        at /store/uzh/uzh1/CP2K_AUTO_REGTEST/DAINT/CRAY_XC50-gfortran_mc/psmp/cp2k/src/kg_environment.F:346
#3  0x1723402 in __qs_environment_MOD_qs_init
        at /store/uzh/uzh1/CP2K_AUTO_REGTEST/DAINT/CRAY_XC50-gfortran_mc/psmp/cp2k/src/qs_environment.F:403
#4  0x1479190 in __f77_interface_MOD_create_force_env
        at /store/uzh/uzh1/CP2K_AUTO_REGTEST/DAINT/CRAY_XC50-gfortran_mc/psmp/cp2k/src/f77_interface.F:790
#5  0x786a06 in cp2k_run
        at /store/uzh/uzh1/CP2K_AUTO_REGTEST/DAINT/CRAY_XC50-gfortran_mc/psmp/cp2k/src/start/cp2k_runs.F:282
#6  0x785f08 in execute_job
        at /store/uzh/uzh1/CP2K_AUTO_REGTEST/DAINT/CRAY_XC50-gfortran_mc/psmp/cp2k/src/start/cp2k_runs.F:835
#7  0x788b13 in farming_run
        at /store/uzh/uzh1/CP2K_AUTO_REGTEST/DAINT/CRAY_XC50-gfortran_mc/psmp/cp2k/src/start/cp2k_runs.F:650
#8  0x788b13 in cp2k_run
        at /store/uzh/uzh1/CP2K_AUTO_REGTEST/DAINT/CRAY_XC50-gfortran_mc/psmp/cp2k/src/start/cp2k_runs.F:268
#9  0x78a44c in __cp2k_runs_MOD_run_input
        at /store/uzh/uzh1/CP2K_AUTO_REGTEST/DAINT/CRAY_XC50-gfortran_mc/psmp/cp2k/src/start/cp2k_runs.F:1111
#10  0x784fe9 in cp2k
        at /store/uzh/uzh1/CP2K_AUTO_REGTEST/DAINT/CRAY_XC50-gfortran_mc/psmp/cp2k/src/start/cp2k.F:281
#11  0x78125c in main

For the time being, I have removed the test from Daint.

Currently, this feature only works for PR that have their head_branch in the same repo.

I missed a reference to scripts in #46 which should have led to a failure when verifying the checksum, but it didn't, indicating that the CI does not get changes in the toolchain scripts.

the first error one usually sees is that building ELPA breaks with the following in the configure.log:

configure: error: in `/data/tiziano/cp2k/tools/toolchain/build/elpa-2017.05.002/obj_no_thread':
configure: error: C compiler cannot create executables

the config.log shows the following:

configure:3938: mpicc -O2 -ftree-vectorize -g -fno-omit-frame-pointer -march=native -ffast-math  -I'/data/tiziano/cp2k/tools/toolchain/install/openblas-0.2.20/include'   -Wl,--enable-new-dtags  -L'/data/tiziano/cp2k/tools/toolchain/install/openblas-0.2.20/lib' -Wl,-rpath='/data/tiziano/cp2k/tools/toolchain/install/openblas-0.2.20/lib' -L'/data/tiziano/cp2k/tools/toolchain/install/scalapack-2.0.2/lib' -Wl,-rpath='/data/tiziano/cp2k/tools/toolchain/install/scalapack-2.0.2/lib'  conftest.c -lscalapack  IF_OMP(-lopenblas_omp|-lopenblas) >&5
gcc: error: IF_OMP(-lopenblas_omp|-lopenblas): No such file or directory
configure:3942: $? = 1
configure:3980: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "elpa"
| #define PACKAGE_TARNAME "elpa"
| #define PACKAGE_VERSION "2017.05.002"
| #define PACKAGE_STRING "elpa 2017.05.002"
| #define PACKAGE_BUGREPORT "[email protected]"
| #define PACKAGE_URL ""
| #define PACKAGE "elpa"
| #define VERSION "2017.05.002"
| #define EARLIEST_API_VERSION 20170403
| #define CURRENT_API_VERSION 20170403
| #define WITH_MPI 1
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3985: error: in `/data/tiziano/cp2k/tools/toolchain/build/elpa-2017.05.002/obj_no_thread':
configure:3987: error: C compiler cannot create executables
See `config.log' for more details
[...]
LIBS='-lscalapack  IF_OMP(-lopenblas_omp|-lopenblas)'
[...]

indicating that an IF_* conditional macro leads into the package's build-system. This was introduced in commit fe53026 with the following:

export OPENBLAS_LIBS="IF_OMP(${OPENBLAS_LIBS_OMP}|${OPENBLAS_LIBS})"

which is then loaded into the $MATH_LIBS which in turn is used by the subsequent packages.

In fact, checking other package's build logs reveals that they got the same:

$ grep IF_OMP build/scalapack-2.0.2/SLmake.inc
LAPACKLIB     =  IF_OMP(-lopenblas_omp|-lopenblas)

we are most of the time saved by

• the build systems generously ignoring garbage on the linker line
• that we are building everything statically, because these macros are only resolved when linking CP2K

ELPA is using autoconf/automake which checks the flags properly and therefore fails to build. We can expect similar errors from other packages with proper build systems.

When building CP2K using the toolchain script, nvcc is given the flag -Xcompiler=--std=gnu++98, causing a compilation error in DBCSR.

To reproduce, create an arch file with:

./install_cp2k_toolchain.sh --with-sirius=no --with-gsl=no --with-libxsmm=install \
  --with-openblas=system --with-fftw=system --with-reflapack=no --enable-cuda \ 
  --enable-omp  --with-spglib=no --with-json-fortran=no

Problematic compilation instruction:

nvcc -D__GNUC__=4 -D__GNUC_MINOR__=9 -Xcompiler=--std=gnu++98 -c -arch sm_35 \
  -Xcompiler='-fopenmp' --std=c++11 -D__ACC -D__DBCSR_ACC -D__PW_CUDA \ 
  -D__LIBXSMM  -D__parallel  -D__FFTW3  -D__LIBINT -D__LIBINT_MAX_AM=6  \
  -D__LIBDERIV_MAX_AM1=5 -D__LIBXC -D__SCALAPACK -D__HDF5   \
  -I'/users/alicej/fix_cp2k_build/cp2k/exts/dbcsr/src' 

Observed compilation error:

/users/apps/fulen/UES/RH-7.4/sandboxes/hvictor/easybuild/software/GCCcore/6.2.0/include/c++/6.2.0/bits/c++0x_warning.h:32:2: 
error: #error This file requires compiler and library support for the ISO C++ 2011 standard. 
This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.

Currently PW_DFT uses json-sections instead of normal CP2K input sections.
This leads to input files with mixed format:

&MIXER
   "type" : "broyden1",
   "max_history" : 8
&END MIXER

that also lack common documention.

It would be nice if SIRIUS somehow exported its input metadata, which could then be translated into normal CP2K input section.

I found that a new section in dft_plus_u with name of enforce occupation.
Can I use this subsection to enforce localized electron into specific atom?
Because I want to determine U from self consistent approach like method developed by Nicola Marzari.

We have a user at Juelich Supercomputing Centre who wants to use libcp2k but I'm unsure how exactly we provide an installation of this. Is it enough to provide libcp2k.a in the LD_LIBRARY_PATH and libcp2k.hin the CPATH? For a Fortran user do I just add libcp2k.mod in the CPATH or would I require additional .mod files?

We use EasyBuild for our installations, if you're interested the relevant rules for CP2K are at https://github.com/easybuilders/easybuild-easyblocks/blob/develop/easybuild/easyblocks/c/cp2k.py

Many of our strategic decisions are based on assumptions about our user base. Unfortunatelly, we have very little hard evidence in this regard. I therefore propose that we conduct a simple survey among our google group subscribers.

Possible questions could be:

• How long have you been using CP2K?
• How often do you use CP2K?
• How do you obtain CP2K (distro, compile myself, provided by admin, ...)?
• What kind of hardware do you have (CPU / GPU generation, memory per node,...)?
• What kind of software do you have (versions of compiler, python, git, cmake, ...)?
• What kind of simulations do you run (QMMM, Metadyn, CDFT, kpoints, ...)?
• What do you consider CP2K's greatest strength?
• What do you consider CP2K's biggest weakness?

We now state Fortran 2008 as our default standart in the conventions. Hence we should now replace our own implementions with Fortran intrinsics were possible. The __F2008 flag is also no longer needed.

See also cp2k/dbcsr#129 .

Currently all our Python scripts are tested by calling them with --selftest. Unfortunately, virtually no script actually implements a proper self test. Still this test is useful as it verifies that syntax and imports work across different versions of Python.

I'd propose that in the future we require all scripts to support -h instead. Furthermore, scripts that match *_unittest.py are called again without any arguments.

I get this error when running the toolchain script.

cp2k-6.1.0/tools/toolchain/scripts/install_openmpi.sh: line 45: [: 19-18+deb8u10): integer expression expected

Full output of the ldd command:

ldd (Debian GLIBC 2.19-18+deb8u10) 2.19
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

The CP2K Dashboard shows a drop in performance of tests H2O-64 LS and H2O-64 MD on CRAY_XC50_GPU between CP2K commits f4ed3f9 and 53314e2. Notice the est. peak process memory drops significantly as well.

Do you have any idea what this performance drop might be due to ?

I tried to find out whether this was due to an update of DBCSR, but have trouble figuring out which DBCSR version is used in each one of these commits because of issue #154 and because of the following lines in the result log of commit f4ed3f9:

MAKE (err): Discovering programs ...
Discovering programs ...
/store/uzh/uzh1/CP2K_AUTO_PERFTEST/DAINT/CRAY_XC50-gfortran_gpu/psmp/cp2k/exts/Makefile.inc:2: *** "No DBCSR submodule available, please run 'git submodule update --init --recursive'".  Stop.
make[1]: *** [psmp] Error 2
make: *** [all] Error 2

Which DBCSR version was used in commit f4ed3f9 of CP2K if the compilation log indicates that the DBCSR submodule wasn't present?