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 that regularly contribute can sign up to the CP2K developer mailing list.

Prepare the patch

  1. Fork the CP2K Repository on GitHub via “Fork” on
    1. Also 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. Move to the downloaded 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. 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
    4. push the changes: git push
  12. You can also rebase your feature branch, in this case do the previous point and then:
    1. git checkout my-new-feature
    2. git pull --rebase upstream 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.
dev/starting.txt · Last modified: 2019/03/05 16:18 by tmueller