I have been trying to run an IRC using the latest version of Psi4 (specifically commit 02a1496), but the IRC fails with the following message:
Read in cartesian Hessian and transformed it.
IRC_DATA is empty, so we are at the transition state.
Stepping in forward direction from TS.
Back-transformation to cartesian coordinates...
Could not converge backtransformation.
Using first guess instead.
The INTCO_EXCEPTion handler:
Could not take constrained step in an IRC computation.
Dynamic level is 0.
exc.g_really_quit() is 0.
**** Optimization has failed! (in 1 steps) ****
Is there anything I can do to make this converge?
A few things that may help:
Because of unrelated technical difficulties, it is more convenient for me to read in a Hessian produced by a separate job than it is to compute an initial Hessian here. I have tried setting write_hess_every to 0 instead. I get the same problem. If you want, I can supply you with the Hessian I’ve been using.
I have the same problem whether I run the IRC in the backwards or the forwards direction.
While I have not had difficulties converging this system in CFOUR previously, the expected reactant is a hydrogen-bonded complex.
I’ve done some additional testing at the SCF level, and I’ve gotten some strange results. I can get convergence if I use the ensure_bt_convergence keyword, but the step size never changes. The first time you attempt convergence with the keyword enabled, fix_bend_axes is not called. If you do not include the keyword but comment out the fix_bend_axes call on line 149 here, you get convergence.
Including the keyword also gets CCSD(T) convergence.
The keyword “ensure_bt_convergence” reduces the step size until one can be taken in cartesians. However, the first event in our IRC algorithm is a step in the direction of a Hessian eigenvector that is 1/2 the length of the requested IRC step size. So this keyword is probably not helping you get what you need.
On the other hand, if commenting out ‘fix_bend_axes’ allows convergence then I believe you are OK. This keyword fixes the meaning of quasi-linear bends. In some cases, it is needed to get a successful back-transformation but in others I’ve recently found it prevents a precisely chosen step. The latter is not generally critical for stationary point searches.
It’s a good idea to test with SCF if you can. Also, with printing turned up, the Hessian after its transformation to internal coordinates will be printed in the output. You could visually inspect that to see if it is reasonable. That is, do you see larger diagonal elements appropriate for stretches and bends.
At the SCF level, my Hessian looks reasonable, and I’m getting a reasonable trajectory. It looks like this was just one of those cases where “fix_bend_axes” shouldn’t be used, thanks!
We should probably modify the code to try to accomplish the step without
fixing the axes, and then if that fails (might be tricky to define “fail”
in general) retry with the axes fixed.
Separate issue – for reading in a Hessian that wasn’t computed within the same job, I believe you are going to run into problems. Specifically, at some point the libmints function get_writer_file_prefix began including the process ID – it wasn’t a problem before that. Since there is no way to know the PID in advance, this prevents the user from reading in a Hessian that was computed in a separate job. I think it might be worth avoiding the use of get_writer_file_prefix within optking and allowing the user to set a file prefix for optking, or perhaps just for reading the Hessian. Is that right @Rollin_King – what do you think?
A temporary work-around would be to rename the Hessian file within your IRC job input using the current PID, but that seems seriously sub-optimal as a long-term solution.
I can get around this because my cluster manager modifies Psi4 so it can read in the Hessian without a PID. This, of course, does nothing for the general case.
Some users have reported problems with supplying files due to a lack of a PID here. One of these files is the internal coordinate file for an optimization.
Yeah, we need a hack for this. There was, once upon a time, a PID override
that could be provided by the user, but I believe it has been obsoleted.
As long as we are using PIDs in filenames, then I think this functionality
should be brought back. There will always be at least ‘expert’ uses for it.