User Tools

Site Tools


Nice to Haves

This is a list of nice to have features or changes in CP2K that nobody got around to do, yet. ;-) They are noted down here so we don't forget about them.

Some of them may be suitable for one or more Google Summer of Code projects.

External Libraries

Input / Output

  • Refactor cp_output_handling.F such that it does not require the input_section. Instead there should be a routine to parse the input section once and store that information into a novel printkey_type.
  • Make it clear in the output at which nesting level the output is happening. For example, print “Entering nesting level X” before and “Exiting nesting level X” after. Proivde tools for highliting and folding the output files.
  • Evolve the printkey into a real logging mechanism. If the WRITE statements were converted into functions calls, one could annotate the output in a standardized way. Such annotations would then allow for parsing the output in a generic fashion.
  • A lone keyword of type logical should always shortcut to YES. This should be hard coded.

Missing features

  • Cut-off auto-calibration (Is it possible to provide good cut-off default values based on basis sets and desired precision?)
  • Estimation of time remaining until the simulation is done. Probably easy to do for MD using FIST. Order of magnitude estimation could possibly be provided using parameters from the input file with a good cost model, heuristics will likely be needed for more precise estimation.
  • Estimation of disk size simulation output files will take.
  • Support libint2, according to the manual, the libint2 maintainer himself is looking for someone creating a Fortran wrapper (some hints on how to do it are given as well), so this may be a two-part job: create a generic Fortran wrapper and submit to libint2, integrate it in cp2k.
  • Alternatively, one could consider switching to LibMints .
  • Support xcfun
  • Support GROMACS format for force fields and topology files in MM.
  • Provide a cp2k library/API:
  • Extend the preprocessor to accept @ELSE in the existing '@IF @ENDIF' and possibly remove the restriction on nesting.


  • Investigate performance delta of MM code in CP2K compared to another state of the art open source software (e.g. GROMACS). See if there are interesting ideas there which can be used.


  • The test coverage of the XC-functionals is pretty low. Since we have libxc as reference, one could easily write a unit-test that compares both implementations by applying them to a randomly generated density.
  • Setup a regtester with the PGI Community Edition Compiler.
  • Performance regression testing. Requires an empty machine for reproducibility. Test each kernel (FFT, LA, grid,…) in different regimes (compute-, communication-, overhead-bound).


  • Add support for CP2K input-files to GeSHi, which is what DokuWiki uses for syntax highlighting.

Dev Tools

  • A Fortran parser library for Python. As a starting point one could take the parser from gfortran and extend it to preserve white spaces. Alternatively, one could try to get the Open Fortran Parser to work with CP2K. A third option would be to improve the Fortran frontend for LLVM. Such a parser library would allow for advanced tools like:
    • static code analysis
    • generation of nice API docs
  • Run static code analysis e.g. on the gfortran AST to find common performance issues:
    • ALLOCATEs in OMP-regions or tight loops
    • ALLOCATABLEs / POINTERs that could go in the stack.
  • Fuzzy testing: Generate randomly valid input files, then check that they either run successfully for a few seconds or quit with a proper error message. The fuzzing could be extended to other settings, e.g. mpi, openmp, arch-file,etc.

Youthful Folly

  • Remove reference counting wherever possible. It leads to super-hard to find bugs, and most objects in CP2K have an obvious owner. This ownership assignment can be enforced by using ALLOCATABLEs in derived types.


Allocatables lead to faster code, can not lead to leaks, and are less prone to programming errors. This would be easier with a (not-yet-existing) -Wneedless-pointer warning in gfortran. In order of difficulty :

  • Switch local procedure variables from POINTER → ALLOCATABLE if they are
    • not passed to a procedure with explicit POINTER dummy arguments
    • not used in a pointer assignment
    • … ? It probably holds that the code is correct if it compiles.
    • special treatment might be useful for NULLIFY and ASSOCIATED
  • Remove POINTER attribute of dummy arguments
    • needs to be careful with INTENT(IN) pointers
  • Switch derived type members from POINTER to ALLOCATABLE



  • Remove dbcsr_mutable_type.
  • Remove various init-routines, rely on Fortran type initializers instead.


  • Eliminate the work matrices, the assignment to threads should be static.
  • Enforce clear separation of library layers. For example arnoldi should be independent from data storage format.
  • Do not pass any internal data-structure to the “outside”.
  • Merge dbcsrwrap and dbcsr_api. There should only be one API.
  • Strengthen the API with unit-tests.
  • Remove improper usage of INTERFACEs like this .


  • dbcsr_add does not check for symmetry.
  • dbcsr_add does not check the “transpose-state”.
  • dbcsr_copy has confusing order of arguments.

Missing features?

  • dbcsr_trace does not work with matrices of different symmetries.
  • dbcsr_add does not work with matrices of different symmetries.
  • Complex matrices are not fully supported, which is why they are not used in e.g. RTP.
  • Expose dbcsr's internal types as Fortran types. This means having separate types for symmetry/non-symmetric and int/float/complex.
  • MIC port (integrate)
  • Finish OpenCL port (kernels), make sure it runs on open source OpenCL stack provided by Mesa / Gallium (radeonsi driver is a good target).
  • Use the CUDA runtime compilation library instead of statically linking only a small list of preselected kernels.
dev/todo.txt · Last modified: 2017/02/10 10:34 by oschuett