From my understanding the printing of MOMENTS and MOMENTS_FT within BSE is limited to this method and does not work for normal RTP. Would it be possible to move the relevant BSE-specific switches from the DFT/REAL_TIME_PROPAGATION/PRINT/MOMENTS to e.g., .../BSE/PRINT/MOMENTS instead?
Currently for normal RTP the moments are printed via DFT/PRINT/MOMENTS, which given the BSE-specific MOMENTS section can cause some confusion.

Dear @Anyborr, we thought about moving the PRINT section with MOMENTS and MOMENTS_FT subsections into RTBSE subsection of RTP, but decided against it, as we plan to implement more real time methods which could probably use the same interface to print the moments, but with their own configuration sections. This would prevent print section duplication.
As of now, we are warning the user that a section is set which is not implemented for the standard RTP if the MOMENTS or MOMENTS_FT section is used without the RTBSE method for RTP, see

(https://github.com/cp2k/cp2k/blob/ad3ce71a450b1cd81fd944488742f4378e7c5979/src/motion/rt_propagation.F#L175C6-L182C94)

Specifically, we point the user to the correct RTP section in the warning for MOMENTS. Let me know if you feel that this is still insufficient to avoid confusion.

Dear @StepanMarek Thanks for your reply.
I still believe this will cause confusion for users of the RTP module. A warning message in the output likely won't be caught before the calculation is finished and the output analyzed.

Given your reply (avoiding code duplication is always worthwhile!), I would suggest at the least to add a note in the header of the cp2k manual page to indicate that this is currently only for use with RTBSE.

Also, maybe it would be worthwhile to implement your routines for the normal RTP as well? I know the padé method would be useful also for normal RTP to accelerate spectrum generation.

Best,

Dear @Anyborr, thanks for the suggestions!

Also, maybe it would be worthwhile to implement your routines for the normal RTP as well? I know the padé method would be useful also for normal RTP to accelerate spectrum generation.

I think we will go this way, though it might take us some time, but we (in the group) also think that the methods could be useful to others. I will probably mention the pull request here once I have prepared it.