Recovering information from i-pi

[Marc Riera]

Hello,

I am planning to implement the ASPC (Always Stable Predictor-corrector) method to obtain the electrostatics of my system. However, this method requires to keep track of the history of the dipoles in time for a few steps. In order to do that, i need to store the dipoles for a given replica (either bead or replica for REMD) in the driver, and let the system class know them. That so far is not a big deal. The question comes here:

1. How can extract the timestep, the current step, and the replica ID from i-pi to my driver? I know that the fortran example in the i-pi code has the replica id feature, but it is difficult for me to try to adapt that to my c++ code. Is there any keyword I can send to the driver to get the information I need?

2. I think the answer to this one is yes, but I would like to confirm. Let's say that I have a system with 64 replicas. Is it possible to send replicas 1-16 to driver1, 17-32 to driver 2,... by just specifying a different "driver" in the xml?

Thanks a lot!

Marc

[Michele Ceriotti]

What you want to do sort of breaks the encapsulation principle behind i-PI. 

The way we deal with WF extrapolation (which works on a very similar basis) in quantum espresso is entirely on the driver side. You keep the trajectory memory on the client side, and only check you're receiving the same replica ID as the previous step. If you do, you extrapolate, if you don't you reset the history.  This is the only way to make the scheme robust. On his side, i-PI will guarantee that if you have as many running drivers as you have replicas, it will try to always pass the same replica to the same driver.

If you choose to do this, all you need is the replica ID, and we can help you figure out how to fetch that. Basically the relevant bits in the driver are

               CALL writebuffer(socket,"NEEDINIT    ",MSGLEN)  ! Signals that we need initialization data

that is you ask to get init data, to which i-PI will reply

         ELSEIF (trim(header) == "INIT") THEN     ! The driver is kindly providing a string for initialization

            CALL readbuffer(socket, rid)

            CALL readbuffer(socket, cbuf)

            CALL readbuffer(socket, initbuffer, cbuf)

i-PI passes the replica ID, and could send an initialization string, that you can happily ignore. Most codes don't do this at every step, but you can do that if you need the replica ID.

Answer to (2) is actually no. We're considering to do that, but never had a compelling use case this far. Drivers are allocated dynamically as they connect, and are assigned replicas to be computed in a load-balancing scheme. This means you can have any number of drivers, from one to the number of replicas, and i-PI will use them as well as it can.

Michele

[Marc Riera]

Hey Michele!

Thanks a lot. I think that the way you do the WF extrapolation will be useful in my scheme. That is a really good idea.

I think this will be enough to do so. Regarding the timestep, I think I will just set it to the value is supposed to be in our simulations, and maybe later also make the driver read the xml at the beginning to get that information.

I will let you know if I am having problems with getting the id of the replica, but I hope I can mange it.

Thank you very much! See you!

Marc