Possible bug in unit conversion before printing in PLUMED interface?

[Barak Hirshberg]

Hello,

Not sure if this should be posted here or in the PLUMED users group. If you want me to move it there, just say so.

In any case,I am running the example files for using PLUMED with i-PI on the zundel cation.

It seems that when PLUMED prints the time in COLVAR file is doesn't multiply by the timestep to get the actual physical time.

I am attaching a file where I am using a.u in i-PI and a timestep of 20 a.u. I am also using a.u. in PLUMED.

Then, the COLVAR file (STRIDE=1) shows the time as 1,2...,10 instead of 20,40,...200.

Barak

[Michele Ceriotti]

Uhm. Not sure of whether this is a problem of i-PI or PLUMED. 

I wouldn't worry about it though, I can't see any practical issue descending from it. 

If you want to go to the bottom of it and submit a fix to either i-PI or PLUMED you're obviously welcome.

Nice way to get a bit into the code and contribute to it.

Cheers

M

[Barak Hirshberg]

Hi Michele,

Thanks for the answer.

I'll both post this on the PLUMED group, and try to look into it myself.

Will let you know if I can figure it out.

All the best,

Barak

[Barak Hirshberg]

Hi Michele,

Just a quick question - I suspect the the problem might be in i-PI.

the engine/forcefiled.py file of the i-PI distribution includes the following line:
"self.plumed.cmd("setTimestep", 1.)"

Which, if I understand correctly, passes the time step as equal to 1 always.

I may be completely wrong though...

What do you think?

Barak

[Michele Ceriotti]

I think that's true but if I recall when we implemented that it was a deliberate choice. 

PLUMED strides are always in units of the frequency with which plumed is called, and for various reasons we preferred to set the timer to print out the number of steps (for instance, in principle dt is a mutable quantity, but there would be no way of communicating the changes to plumed with the current framework.

In short, I don't think this is something you should worry about but let me know if you find some repercussions of this choice that are not merely aesthetical.

M

[Barak Hirshberg]

Hi Michele,

Omar Valsson suggested an (admittedly ad hoc) solution.

We can use any conversion factor in PLUMED for the time units.

As a result, simply adding UNITS TIME=2.4188843e-05/20.0 to the plumed.dat file should print the correct physical time in PLUMED in a.u. (assuming a time step of 20 a.u. is used in i-PI, otherwise this factor needs to be changed).

Notice that if you are using different units in i-PI, for example fs with a time step of 0.5 fs, this factor will be UNITS TIME=2.4188843e-05/0.5
Lastly, note that, as written in the PLUMED manual, all input/output will then be made using the i-PI units.

To conclude, you can add UNITS TIME=2.4188843e-05/iPI_TIMESTEP to plumed.dat to get the physical time printed in COLVAR in i-PI units.

Michele, do you think this fix may cause any problems while interfacing with i-PI? I guess not, because i-PI has its own variables keeping track of the time..

Thanks,

Barak

[Michele Ceriotti]

I fail to see the point in doing this. The technical problem on the i-PI side is that force providers are not supposed to depend on time, and so when you initialize the plumed connection there is no direct access to the dt information. One could probably hack a way of picking it up and passing it to PLUMED but who cares about having time units in PLUMED? IMO unless there is some mechanism to automatically pass the time step, it is better to leave it at one, so it is clear that is just a stepper and not an actual physical time. 

In any case do whatever you want with it, it will have no impact whatsoever on anything physical as far as I can tell.