XMS-CASPT2 analytical gradients

[makochman]

Dear All,

I am interested in the excited-state relaxation dynamics of trans-1,3,5-hexatriene as a model of the photoisomerization processes of longer polyenes. I set up a series of nonadiabatic molecular dynamics (surface hopping) simulations in which the electronic structure of the molecule is described at the XMS-CASPT2/6-31G(d) level of theory. In these simulations, I am calculating the analytical gradients (i.e. the forces acting on the nuclei) and the nonadiabatic coupling vectors at each time step along the trajectory.

To my surprise, I found that during the simulations, the calculated gradients occasionally become very large, much larger than would normally be expected in the course of a molecular dynamics run. When that happens, the direction of the gradient typically changes abruptly from one time step to another. Moreover, the CASPT2 relaxed dipole moment takes extremely large values. These symptoms seem to match up with the problem reported previously by Nomotoatsu (please see https://github.com/nubakery/bagel/issues/191).

I am seeing this behaviour with BAGEL version 1.1.0-1 (installed on Linux Mint from the software repositories), as well as versions 1.1.2, and 1.2.2 (compiled on CentOS with the use of Intel compilers). I have not been able to make it go away by changing the parallelization settings, which is to say, the environment variables OMP_NUM_THREADS and BAGEL_NUM_THREADS.

Please find attached some input and output files which provide an example of the problem: https://drive.google.com/file/d/1f91UDti2ikE1zPlMIbIHSbuvLUQtryi5/view?usp=sharing

The calculation in the directory "initial_orbs" generates the CASSCF orbitals for use in the subsequent calculations. The directories "frame_0022", "frame_0023", etc. contain the molecular geometries from a succession of 9 molecular dynamics time steps. Because I used a very short time step (0.2 fs), the nuclear geometry changes very little. However, the gradient of the S1 state becomes very large and suddenly changes direction over frames 23 to 27. The underlying CASSCF calculation seems well-behaved.

What could be happening here? Is this a problem that is specific to some compilers and/or parallelization settings?

With kind regards,

Michał Kochman Postdoctoral Researcher University College London (UCL)

[shiozaki]

I will see if I can reproduce the behavior (hopefully soon...). I could not reproduce #191 on Ubuntu/gcc 7.

[makochman]

Dear Professor Shiozaki,

I've looked into the problem more carefully, and it seems that the abrupt change in the XMS-CASPT2 analytical gradients is due to a sudden change in the CASSCF wavefunction. Changing the CASSCF state-averaging scheme solves the problem, and the simulations now run without issue.

To be absolutely clear on this point, I think that this unexpected behaviour was due to a bad choice of state-averaging scheme in my simulations. I do not believe it is a bug. Apologies for the trouble!

With kind regards,

Michał

[shiozaki]

Oh great!! Thanks for letting me know.

On Fri, Jul 24, 2020 at 3:54 AM makochman notifications@github.com wrote:

Dear Professor Shiozaki,

I've looked into the problem more carefully, and it seems that the abrupt change in the XMS-CASPT2 analytical gradients is due to a sudden change in the CASSCF wavefunction. Changing the CASSCF state-averaging scheme solves the problem, and the simulations now run without issue.

To be absolutely clear on this point, I think that this unexpected behaviour was due to a bad choice of state-averaging scheme in my simulations. I do not believe it is a bug. Apologies for the trouble!

With kind regards,

Michał

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/nubakery/bagel/issues/207#issuecomment-663395330, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKDMITAR75HW4BHDLJVUNLR5E42RANCNFSM4OXHKWCA .