Skip to content

i–PI server functionality#3420

Merged
oschuett merged 3 commits intocp2k:masterfrom
FurstPlattner:ipi
Jun 17, 2024
Merged

i–PI server functionality#3420
oschuett merged 3 commits intocp2k:masterfrom
FurstPlattner:ipi

Conversation

@FurstPlattner
Copy link
Contributor

i–PI force evaluation method & Nix building

This PR adds two features:

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:

&GLOBAL
  RUN_TYPE MD
&END GLOBAL

&FORCE_EVAL
  METHOD IPI
  &SUBSYS
    &CELL
      ABC 10.0 10.0 10.0
      PERIODIC NONE
    &END CELL
    &TOPOLOGY
      COORD_FILE_FORMAT xyz
      COORD_FILE_NAME yourMoleculeHere.xyz
    &END TOPOLOGY
  &END SUBSYS
&END FORCE_EVAL

&MOTION
  &MD
    STEPS 1000
    TIMESTEP 0.25
    ENSEMBLE NVT
    TEMPERATURE 300
    &THERMOSTAT
      TYPE CSVR
      REGION MASSIVE
      &CSVR
        TIMECON 25
      &END CSVR
    &END THERMOSTAT
  &END MD
  &DRIVER
    HOST myHost
    PORT 8421
    UNIX
    SLEEP_TIME 0.1
  &END DRIVER
&END MOTION

Note the DRIVER subsection, 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:

  • Install Nix
  • nix build will build/download all dependencies and build CP2K
  • nix develop will enter a development environment with all dependencies, fortls, and fprettify

Possible issues

  • This is my first time working on production–level Fortran code, so please review carefully.
  • I'm not quite sure how what has been implemented interacts with CP2Ks parallelism. In practice, I don't think parallelism is required for an i–PI server, but it would be good if behaviour was correct anyway.
  • This implementation is limited to a single client.

@oschuett
Copy link
Member

oschuett commented May 21, 2024

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:

@FurstPlattner
Copy link
Contributor Author

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.
Let me know if there's anything else!

@FurstPlattner FurstPlattner changed the title i–PI & Nix i–PI server functionality May 30, 2024
@oschuett
Copy link
Member

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.

@FurstPlattner
Copy link
Contributor Author

FurstPlattner commented Jun 11, 2024

Implemented a simple test where CP2K communicates with another instance of itself through the i–PI protocol.
I hope I understood the workings of your CI correctly! And sorry for taking a while, I was out of the office last week.

E: Huh, the Misc test passes on my machine. I'll try to look into it.

@oschuett
Copy link
Member

oschuett commented Jun 12, 2024

Implemented a simple test where CP2K communicates with another instance of itself through the i–PI protocol.

Oh, that's neat!

I hope I understood the workings of your CI correctly!

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.

@oschuett oschuett merged commit cd6f6b9 into cp2k:master Jun 17, 2024
@fstein93 fstein93 mentioned this pull request Jun 18, 2024
@FurstPlattner FurstPlattner deleted the ipi branch October 24, 2024 13:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants