<div dir="ltr">Hi, thank you for your quick answers. yes the coordinates of the centers are really differing! My proceeding was to stop the CP2K-run in a controlled manner. This works with the directives WALLTIME or LAST_SNAPSHOT. Then I restarted the calculation with the options &EXT_RESTART RESTART_FILE_NAME polarizability-1.restart &DFT WFN_RESTART_FILE_NAME &SCF SCF_GUESS RESTART &REFTRAJ FIRST_SNAPSHOT With the next following timestep in the FIRST_SNAPSHOT option. 1.Run: 1-5 2.Run: FIRST_SNAPSHOT 6 Doing so the resulting Raman-Spectrum looks like a semi-circle looking like any systematic fault. Then I compared the coordinates and they were differing with a trajectory sequence from 1-5 and 7-10 for example. The next try i did was to restart the counters in the &EXT_RESTART section. Then the sequence was correct from 1-10 but there were some jumping atoms (the trajectory was ruptured) and the coordinates of the centers after the restart were still differing and the Raman-Spectrum looks like a hyperbola with an underlying sinus oscillation. And finally in my last try i discovered that CP2K takes everytime when called the first timestep to prove if the calculation converges. I changed the value of FIRST_SNAPSHOT to 1.Run: 1-5 2.Run: FIRST_SNAPSHOT 5 resulting in a sequence which was still correct (1-10) but without any jumping atoms and still differing coordinates of the wannier centers. But now the Raman-Spektrum calculated with TRAVIS was finally the same like in a single CP2K-Run. The point of interest now is if my tries lead to any kind of systematic fault in TRAVIS because of the Raman-spectrums were quite regularly? In the end I am glad to be able to do my calculations now. I did the imaginable simplest fault and hope to safe other people from doing the same! Regards, Tobias </div>