Implementation of new dynamics model

[zerothi]

Dear dev's

I am interested in using iPi as a backend communicator with a DFT program (in this case Siesta) by implementing my own dynamics class in Python, possibly on top of an already implemented i-Pi MD method.

I.e. the basic use would be using i-Pi as a coordinate/force communicator.

I have searched around in the code-base for such an example, to no avail. Also the manual does not mention such a case (or did I miss it?).

1. Is i-Pi directly enabled to hook a class into the machinery using sockets etc.?
2. If so, where should I start to implement such things?
   I looked at Apply a force based on positions of all beads #227 which seems to suggest what to do, but I could not figure out what to do (other than manipulating the Motion class).

Any help would be greatly appreciated. If successful I would be happy to back-contribute such an example/tutorial to the development.

[ceriottm]

Hello, not very clear what you want to do. We already have a socket backend in SIESTA, do you want to have a native Python interface for SIESTA or you want to implement new MD scheme?

[zerothi]

Hi Michele,

Basically I want a native Python interface for exchanging coordinates with Siesta.

import ipi

ipi.initiate_socket(...)
while ipi.not_finished():
    xa = ipi.getcoordinates() # retrieve coordinates from Siesta
    forces = ipi.getforces() # retrieve forces from Siesta
    xa_new = xa + forces * (...)
    ipi.sendcoordinates(xa_new) # return coordinates to Siesta

Something like the above. My manipulation of the returned coordinates could be from an intrinsic ipi scheme or from my own method.

PS. FYI I am one of the current main contributors to Siesta. So I am aware and can run the current ipi interface.

[ceriottm]

Ok but would the forces come from SIESTA or from another program? What you want to do seems more like the way PLUMED works, i.e. you do the propagation of the dynamics in SIESTA and compute some kind of additional force term in i-PI. If you want to do dynamics using the forces from SIESTA why don't you just run i-PI?
If you want a native interface that works in the sense i-PI works (i-PI propagates, SIESTA computes the forces) then you should write Python bindings for SIESTA so that you can get the forces directly - look at how FFYaff works for instance, in ipi/engine/forcefields.py

[zerothi]

I have amended the above snippet to clarify that coordinates and forces are returned from Siesta, and only coordinates are returned to Siesta.

I want to do dynamics (test a new method not currently implemented in i-PI or any other code) using the forces from Siesta. So I want to customize my own dynamics routine which does the displacements.
I have also looked at PLUMED, but that doesn't seem to be directly what I want.

If you want to do dynamics using the forces from SIESTA why don't you just run i-PI?

Exactly, but how can I use i-PI as a backend and create my own dynamics routine? It seems that i-PI requires one to use the thermostats/PIMD shipped with i-PI.

If you want a native interface that works in the sense i-PI works (i-PI propagates, SIESTA computes the forces) then you should write Python bindings for SIESTA so that you can get the forces directly - look at how FFYaff works for instance, in ipi/engine/forcefields.py

It just seemed a bit like double work because then I need to re-create the entire socket engine, plus communication protocol for Siesta. Since i-PI already have all these details it seems, to me, like the right tool! ;)

Basically we want to amend a new MD method in i-PI. How can we accomplish this?
The physics is that we want the GLE with our own friction and fluctuation forces out of equilibrium.

Sorry if I am not being clear enough.

[ceriottm]

Excellent, now all is clear. I'd say the right thing to do is to implement your own MD method in i-PI. This is relatively easy - just take a motion/ class as example and hack it. For starters, you can hijack the motion/dynamics.py and then take the time to make it into a similar class that can be called separately.
Also, keep in mind that the current GLE implementation is super general. There's essentially nothing you cannot do by just changing the form of the GLE matrices. For instance, say you want to implement the "quantum thermal bath" - that is essentially a special case of the a "quantum thermostat" in which you make the friction kernel be delta-like. IMO it's a bad idea (as you need to fine-tune the coupling to different DOF to limit ZPE leakage) but you can formulate the problem as a specific form of the GLE matrices. Same is true for GLE schemes that are written as a chain of oscillators, and so on.
My point is - you might be trying to re-implement a feature that is already there....
Perhaps it's best you write me off-GH as this is getting more into a scientific discussion than one on coding and i-PI :-)

[zerothi]

Super, great!

Thanks for your detailed out-look on the GLE. We will create a more detailed answer and return to you off-site :)

👍