@mkrack, as simplification I removed the options zero_force_core_shell_atom and grand_total_force from write_forces(). I hope that's ok for you?

I'm having second thoughts...

Since we default to the .xyz extension, I figured it would be a good idea to write the forces in the offical XYZ format.

However, the more user-friendly move is probably to restore our old (custom) format that we had before #3778.

Meanwhile the Phonopy developers have already adopted to our new (custom) format (phonopy/phonopy#538). Fortunately, they also kept the parser for the old format.

Any opinions?

@mkrack, as simplification I removed the options zero_force_core_shell_atom and grand_total_force from write_forces(). I hope that's ok for you?

I don't see how this simplification for the forces printout can work for the special case of core-shell model runs which include three particle sets, i.e. cores, shells, and atoms, instead of just one (atoms).

I'm having second thoughts...

Since we default to the .xyz extension, I figured it would be a good idea to write the forces in the offical XYZ format.

CP2K can write already the particle forces like the particle coordinates or velocities in XMOL format (and here).

However, the more user-friendly move is probably to restore our old (custom) format that we had before #3778.

Why is the old format more user-friendly?

Meanwhile the Phonopy developers have already adopted to our new (custom) format (phonopy/phonopy#538). Fortunately, they also kept the parser for the old format.

Any opinions?

It's generally a bad idea to parse proprietary output files which are primarily written for human readers. The .restart files or the frc output files in XMOL or DCD format would be a better source as these are written in a well defined format.

If these files in standard formats are not written for each RUN_TYPE and METHOD combination, then we should use the existing routines for printing these files in a standard format.

It's generally a bad idea to parse proprietary output files which are primarily written for human readers.

While I generally agree, the format has been stable for the last 15 years. Hence, it's not a surprise that people built workflows around it. And popular run types, like ENERGY_FORCE, do indeed not write trajectories at the moment.

Why is the old format more user-friendly?

My hope is that by sticking to the old format when writing to a file we could avoid breaking all those workflows.