CASPT2 with SHARC+OpenMolcas

[ramess101]

I have been running some simple test simulations with SHARC+OpenMOLCAS. The system I have been practicing on is H2 in the lowest excited triplet state, where the molecule rapidly dissociates. I am trying to debug why I can successfully run simulations with CASSCF but my CASPT2 simulations consistently fail.

For example, I have been able to get meaningful results with SA(3,0,1)-CASSCF(2,10)/cc-pVDZ but not with SA(3,0,1)-CASPT2(2,10)/cc-pVDZ. Note that I have also used aug-cc-pVDZ with (2,18) and, similarly, CASSCF works fine while CASPT2 does not.

Specifically, CASPT2 fails on timestep #9 when running with 0.5 fs timesteps. It also fails at the same time (4.5 fs) when using 0.25 fs timesteps. This suggests that there is something that CASPT2 does not like about the partially dissociated molecule geometry (the bond length is only around 2 Angstroms at this point).

The error I am receiving in the MOLCAS output file is “Premature abort while reading buffer from disk. End of file reached.” It also reports, “Location: AixRd, File: JOBIPH,” which suggests that there is something wrong with the JOBIPH files it is reading in.

At first I thought I needed to increase the memory specification, but that did not have any effect. Then I noticed that the MOLCAS.1.JobIph.old and MOLCAS.3.JobIph.old files appear to be missing altogether from the scratchdir prior to the 9th step, whereas for all other timesteps they were present. I looked at $scratchdir/MOLCAS.out after the 8th timestep but did not find anything peculiar, i.e., I believe the 8th timestep completed successfully so I do not understand why there would not be a “.old” file.

Do you have any ideas as to what could be the source of this failure with CASPT2? Would it be helpful if I provided you with some input and/or output files?

[ramess101]

I just wanted to follow-up by saying that I have run into the same issue when simulating CH3. Specifically, I am able to successfully run CASSCF 5e,6o cc-pVTZ for 100+ fs with 0.5 fs timesteps. But when I try to simulate the same system with CASPT2 all of the jobs (~100 replicates) crash after approximately 4 fs. Recall that I am using MOLCAS for the QM calculations. Is this surprising or to be expected? Is MOLCAS CASPT2 just not going to work for these reactions where the molecule promptly dissociates?

[MartinPeschel]

I had the same problem with SHARC+OpenMolcas (simulation runs for a few steps then terminates with “Premature abort while reading buffer from disk. End of file reached.” It also reports, “Location: AixRd, File: JOBIPH,) on a very different molecule which does not dissociate, so the dissociation is not the problem. I think, the problem appears when SHARC produces an input for OpenMolcas where there is a CASPT2 calculation without a preceding RASSCF calculation. One can force SHARC to always request a RASSCF calculation commenting out the line if not 'samestep' in QMin or 'always_orb_init' in QMin: in gettasks in SHARC_MOLCAS.py, which worked for me as a surface level fix.

[ramess101]

@MartinPeschel

Thanks for the suggestion. I will give it a try and report back.

[ramess101]

@MartinPeschel

This does appear to be working! At least it got passed the previous point of failure. This time on the dubious step (step 9) it took nearly twice as long as the average step time. But then for step 10 and for all subsequent steps (so far) it has gone back to the normal step time.

I also wanted to ask for some clarification. Shown below is the original code:

All I have done to make my calculations work is comment out line #2500. But, I was wondering, did you also intend for me to unindent lines 2501-2509? Or should those remain under the same indentation as the if not mofile == '' conditional on line 2492?

As far as I can tell, commenting out line #2500 is sufficient. But I just wanted to make sure since I am not confident that I understand when not mofile == '' will be true.

[ramess101]

@MartinPeschel

Now I have a different problem. Although my jobs are running longer, they eventually run into this error in QM.log:

Numerical differentiation failed, both displacements have bad overlap! iatom=0, idir=2

Is there an obvious remedy for this issue? Do I need to use smaller time steps, larger active space, etc.?

Thanks

[MartinPeschel]

To answer your first question, when I first found the problem, i forgot to unindent them. I unindented them later. It seems to be no different, so my guess is that not mofile == '' is always true during a normal run. However to be on the safe side, i would unindent them. For your second problem: I did not have this problem yet, so i can't really help you very much. As a first step would check the MOLCAS.out files for the gradient calculation to see if they ran properly.

[ramess101]

@MartinPeschel

Perfect! I really appreciate the help.

[maisebastian]

Dear Users, thanks for discussing these two issues.

Regarding issue (1): “Premature abort while reading buffer from disk. End of file reached.”
As the problem does not appear in every time step, I guess that it is due to a "samestep" calculation, which can happen if SHARC realizes after a hop that it needs to calculate additional gradients. In such a case, SHARC requests a second calculation to the interface, where the "samestep" tells the interface that it can take the old orbitals without reoptimizing them. However, for CASPT2, it is not useful to do the "samestep" computations, because in CASPT2-mode the interface computes EVERY gradient anyways.
So the underlying issue arises because you use CASPT2 mode in combination with the gradient selection feature. For CASPT2, this feature does not give you any advantage, so you can deactivate gradient selection ("grad_all" in the input file). Then the "samestep" job should never occur and you will not have this problem ;)

Regarding issue (2): "Numerical differentiation failed, both displacements have bad overlap! iatom=0, idir=2"
There are no analytical gradients in MOLCAS for CASPT2, so the SHARC_MOLCAS interface computes the gradients by finite differences. As a consistency check, the interface compares the wave functions of the central point and each displacement (via overlaps). Only if the wave functions do not change a lot, the numerical differentiation scheme is justified.
In your case, it appears that the wave functions at the central point are very different from the wave functions at the displacement. This could mean that the highest state switched places with the lowest not-computed state, or that there are large active space rotations. The right way to do this would be to check whether you should adapt your active space size or the number of states that you include (both in state-averaging and in the dynamics). If it is not feasible to change these settings, then you should check which state is affected (check in the temporary MOLCAS output files, look for the "Overlap of the original states" matrix. If only the highest state is affected and the active state is not the highest state, then the problem might be not so bad and one can apply some quick fix to the interface to ignore the overlaps of the highest state.

Best regards,
Sebastian

[ramess101]

@maisebastian

1. OK, great. So to be clear, previously I was using grad_select. But with CASPT2 I should instead use grad_all. I will give that a try with the unedited SHARC_MOLCAS.py code.

2. OK, I will test out different active space sizes and/or the number of states in state averaging.

Thanks again!

[ramess101]

@maisebastian

I wanted to confirm that using "grad_all" instead of "grad_select" did resolve this issue without modifying SHARC_MOLCAS

Thanks!

Closing issue now