<div dir="ltr">Hello,<div><br></div><div>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.</div><div><br></div><div>* The input orig3.inp just generates the file orig3-pos-1.xyz, 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.</div><div><br></div><div>* The input reftraj3_03.inp just recomputes the force field energy for a few points from the trajectory orig3-pos-1.xyz. 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.</div><div><br></div><div>* 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.</div><div><br></div><div>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 <u>not</u> be read from the reftraj.xyz 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:</div><div><br></div><div>- 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.</div><div><br></div><div>- Compute the frame to be read from reftraj.xyz as follows: FIRST_SNAPSHOT + STRIDE*STEP, such that it becomes sensitive to STEP_START_VAL, making restart files easier to understand.¬†</div><div><br></div><div>Any help or comments would be appreciated.</div><div><br></div><div>Best Regards,</div><div><br></div><div>Toon</div></div>