Toon Verstraelen toon.ver... at
Mon Apr 25 08:36:39 UTC 2016


I ran into some bugs of the REFTRAJ ensemble, mostly related to the STEP 
counter. I could work around them but it would be nice to have a more 
permanent solution implemented in CP2K. I've attached a tar.gz file with 
inputs and outputs that show the problems. The calculations were ran with a 
recent development version of CP2K (at most a few days old). I've tuned the 
inputs such that they all execute quickly.

* The input orig3.inp just generates the file, which is 
used by the two other inputs (reftraj3_03.inp and reftraj3_04.inp) to 
illustrate the bugs. This is a simple Fist MD simulation with three water 
molecules in a small periodic box.

* The input reftraj3_03.inp just recomputes the force field energy for a 
few points from the trajectory The only visible issue is 
that the step counter for the first iteration is wrong. Probably, this is 
not a big issue but it may cause harm elsewhere and it is probably related 
to the following problem.

* The input reftraj3_04.inp does a PBE DFT calculations on the same 
snapshots as in reftraj3_03.inp, followed by a computation of the localized 
Wannier orbitals at all those snapshots. The same problem as before is 
still present. The first additional problem is that the Wannier centers of 
the first step are not written out, although they are clearly being 
computed. (This problem vanishes when FIRST_SNAPSHOT is set to 1.) The 
second additional problem is that the step numbers of the 
files reftraj3_04-HOMO_centers_s1-1_*.xyz are different from the MD step 
counter. Neither is the time mentioned in the title of these XYZ files, 
causing headaches when postprocessing the Wannier centers.

I took a quick look in the code for a potential solution. The first problem 
is fixable but the numbering of the Wannier XYZ files is not clear to me. 
Furthermore, there could be multiple ways to solve this. E.g., it would be 
much more transparent if the STEP counter would *not* be read from the input. Just counting steps as in an ordinary MD simulation 
would be a lot easier for a user to understand and it would also reduce the 
clutter in the reftraj code. There are a few other improvements that could 
be done along the way:

- Use zero-based indices for REFTRAJ%FIRST_SNAPSHOT and 
REFTRAJ%LAST_SNAPSHOT, such that they are compatible with the step counts 
of an ordinary MD simulation. That is a lot easier for the end user.

- Compute the frame to be read from as follows: FIRST_SNAPSHOT 
+ STRIDE*STEP, such that it becomes sensitive to STEP_START_VAL, making 
restart files easier to understand. 

Any help or comments would be appreciated.

Best Regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reftrajbugs.tar.gz
Type: application/octet-stream
Size: 84634 bytes
Desc: not available
URL: <>

More information about the CP2K-user mailing list