Conversation
|
Thanks a lot for contributing! I'd suggest to make this PR only about i-PI and ask you to please remove the nixify commit. (As a heads up, I don't think packaging belongs into this repo - but let's have this discussion elsewhere). As for the i-PI part, please do the following to make the tests pass:
|
|
All done, sorry for the brief delay and thanks for the comment. I suppose those issues are a lesson about using your own build tools instead of the official ones. |
|
Thanks for the changes! The code looks good to me. Do you maybe also want to add a test for it? We already have the test_i-pi.sh script for testing the client mode. |
|
Implemented a simple test where CP2K communicates with another instance of itself through the i–PI protocol. E: Huh, the |
Oh, that's neat!
You pretty much nailed it :-) ... however I don't think we need to add a new Dockerfile (they come with overhead). You can just add your server test to the existing test_i-pi.sh script. If we adjust the summary messages and add some comments then it should be straightforward to tell these two tests apart. |
i–PI force evaluation method & Nix building
This PR adds two features:
FORCE_EVALcalledIPI.The motivation for these changes is to open up the power of CP2K as a MD/Optimization engine to other software, so that other programs may take advantage of the advanced features of CP2K using their own force evaluation methods. The original goal was to interface our multiscale and fragment calculation package Spicy with CP2K. However, since communication takes place through the communications protocol established by i–PI, any code that can communicate this way could be interfaced to CP2K with out further modifications (or so we hope).
i–PI protocol & implementation
i–PI itself is an engine built for path integral molecular dynamics build on a "server–client" division of labour. i–PI takes the role of the server and handles the evolution of the system, while one or more clients are responsible for the evaluation of the atomic forces. The server communicates with the clients through network sockets, sending atomic positions and cell data and receiving forces in turn. Here, the communications protocol (documented mostly by implementation…) established by i–PI is reused to provide as universal an interface as possible.
CP2K has previously implemented i–PI client side functionality (as a runtype), meaning that it has been able to compute forces for an i–PI server. Here, the other side of the coin is implemented, where an external program provides forces for CP2K. Existing infrastructure is reused where possible.
Example input:
Note the
DRIVERsubsection, which gives the precise socket location and type.Nix
Nix is a package manager and build tool focused on transferability and reproducibility. The files added (
flake.*,nix/overlay.nix,nix/cp2k.nix) provide a reproducible build and development environment for CP2K without interfering with any existing infrastructure.Usage is simple:
nix buildwill build/download all dependencies and build CP2Knix developwill enter a development environment with all dependencies,fortls, andfprettifyPossible issues