User Tools

Site Tools


Starting development

CP2K invites the community to contribute to its development! Documentation improvements, bug fixes, performance enhancements, portability issues, new features, new methods … you are encouraged to contribute so that the community as a whole can benefit.

CP2K is a large project, there is no way to study the full code, and start when that is done! Start working on small patches first, that are easy to code, to test and to integrate. Small patches are easier to review and thus will be more quickly merged to the Git master branch. As experience with the code grows, tackling larger projects becomes realistic. Developers who contribute regularly can join the developers team on Github.

Prepare the patch

  1. Fork the CP2K Repository on GitHub via “Fork” on
    1. Even as a member of the development team you will not be able to push directly to the `master` branch of the repository. This is by intention and we would like to ask you to send changes as Pull Requests instead.
  2. On your machine, clone the repository via git clone --recursive
  3. Change into the created cp2k directory: cd cp2k
  4. Start working in a new branch: git checkout -b my-new-feature
  5. Make your changes to the code
  6. Add new and changed files: git add …
  7. Commit the changes: git commit
    1. Please follow the guidelines
  8. Do the first push to your fork, give the remote branch the same name as the local one: git push -u origin my-new-feature
  9. Do some more work, then repeat point 6. and 7.
  10. Push your new changes to the remote repository via git push (note: the '-u origin my-new-feature' does not have to be repeated)
  11. Use the GitHub interface at to create a pull-request

Update your copy of the master/rebase your patch

  1. To update the 'master' of your fork to the same state as the 'master' of the CP2K repository:
    1. tell your local git repository once about the remote: git remote add upstream
    2. make sure you are on the right branch: git checkout master
    3. 'rebase' your current branch on top of the cp2k/cp2k master: git pull --rebase upstream master
  2. To update a branch with patches onto the updated master branch:
    1. git checkout my-new-feature
    2. git rebase master, this may generate rebase/merge-conflicts you should resolve now. If you got lost, you can always use git rebase --abort (with Git 1.8 and newer) to revert the attempted rebase
    3. after a rebase of a branch with commits which was already pushed to a remote, you have to force-push: git push --force

Submit the patch

Following these guidelines will avoid common mistakes and make it easier to integrate patches. It usually takes less than one hour:

  1. make -j pretty to auto-format the code (variables).
  2. make -j ARCH=… VERSION=“sdbg pdbg ssmp” will check if the code compiles in serial (sdbg) / parallel (pdbg) / with omp (ssmp).
  3. prepare and add testcases suitable for regtesting the code (i.e. that run quickly through all new code paths)
  4. run these testcases by hand. Be sure to use bounds checking, and valgrind to check for undefined variables or memory leaks (see debug page)
  5. run the full regression testing suite, be sure the new testcases run correctly, and no other tests are incorrectly affected.
  6. pay attention to:
    1. are new files, including tests, visible ? Use 'git add' as needed.
    2. Are only the intended files and code modified ? Use 'git revert' as needed
    3. Does the code contain stray write statements or debug info ?
    4. Is all new code sufficiently documented and explained ?
    5. Are the input keywords clearly described ?
    6. Are proper citations added the bibliography ?
  7. if any of the above steps required changes to the code, go back to the first step, otherwise go to the next step.
  8. go to, GitHub will usually notify you directly that you have a branch from which you could create a Pull Request (PR) and since it is a fork of another repository, it will suggest to make the PR against that original repository (for instance the CP2K master branch)
    1. you can check the status of your PR at
    2. we use 'rebase' to keep the Git history linear, meaning that in your final Pull Request there can't be any merge commits
  9. the PR will trigger the CP2K Continuous Integration (CI) system to check conventions and running some checks
    1. In the case of success, the PR will be merged by one of the CP2K administrators
    2. In the case of error, please check what's wrong in the CI logs, fix it in your branch, and commit/push again. The CI will automatically rerun on the new version of the code (no need to close the PR, it will be automatically updated!). Repeat until the CI runs fine.

Prepare a development environment with Spack

The HPC package manager Spack can be used to provide a development environment for CP2K.

We assume that you followed the basic instructions to install Spack and that the spack command is available and that you have a checkout of the CP2K source code (for the latter, follow the instructions above).
  1. change into the CP2K directory: cd cp2k
  2. create a Spack environment (here for building an sopt profile) to make sure we collect all dependencies in one view: spack env create -d envs/sopt
  3. activate the Spack environment using: spack env activate -d envs/sopt
  4. install everything required for CP2K and build & install CP2K from the current source tree (this may take while): spack dev-build cp2k@master ~openmp ~mpi
  5. start a new shell with all the environment variables set using spack build-env cp2k@master ~openmp ~mpi – bash
  6. to recompile, run: make VERSION=sopt

If you experience problems with other tools (like your editor) when inside the Spack environment, you can directly run the build command using: spack build-env cp2k@master ~openmp ~mpi -- make VERSION=sopt

dev/starting.txt · Last modified: 2022/12/16 09:27 by krack