Failure of Cartesian Optimisation in Gaussian and Problem with Dihedrals

[adragthest]

Hello,

I would like to report two issues pertaining to Gaussian 09 calculations:

1. When autodE detects problems with the optimisation in redundant internal coordinates it switches to cartesians; it seems that the use of cartesians to perform the optimisation and the use of Geom=ModRedun are not compatible. G09 terminates immediately with an error and the program stops: "Cannot AddRedundant with Cartesian or Z-matrix opts". Is it possible to fix this?
2. When an initially defined dihedral becomes undefined in the course of an optimisation sometimes autodE detects there is such a problem and switches to cartesians, in other cases not. It seems that autodE reads some output string of Gaussian to detect problems with dihedrals, but it seems they are many errors messages that Gaussian can output that signal problem with the coordinate system used to perform the optimisation. Wouldn't it be a solution to have autodE switch to cartesians irrespectively of the gaussian error to check if the optimisation completes without errors? I think that might be a solution instead of trying to capture all the error messages Gaussian has to signify such problems.

Many thanks!

[t-young31]

Hi @adragthest – thanks for the report

I'm not a Gaussian expert, nor do I have access to a Gaussian install anymore, so this might be a little tricky!

1. I'm not sure if it's possible to do a distance-constrained optimisation in cartesians in Gaussian, I might wager not. Can you can fix cartesian coordinates? (distance constraints are required for the path exploration, so would need a workaround, if it's possible)
2. You're totally right it's a match on a line https://github.com/duartegroup/autodE/blob/6a6eebe2b3c77c7a3f850b9e3c5cce32fafa7531/autode/wrappers/G09.py#L498

Wouldn't it be a solution to have autodE switch to cartesians irrespectively of the gaussian error to check if the optimisation completes without errors?

It would be a solution, but I think perhaps there are more errors that could be encountered that aren't bend errors than are. If you've got (an)other string(s) to add to the possibilities that'd be awesome

[adragthest]

@t-young31

Hello! Sorry for my delay in replying. You are right, it seems that in Gaussian (and I quote from the manual): "No partial optimization or freezing of variables can be done with purely Cartesian optimizations...". It is mentioned though that: "the mixed optimization format with all atoms specified via Cartesian lines in the Z-matrix can be used along with Opt=Z-matrix if these features are needed".

Is this something that can be implemented as a workaround?

Regarding the failure I was mentioning, the string is "Linear angle in Tors." I erroneously associated this to a problem with the dihedrals but actually it is a problem with an angle defined in the beginning of the optimisation becoming linear, causing the associated dihedrals to become undefined.

Yes I understand your point about the errors, the majority of which might not be associated with problems with bends. As an alternative, would a solution be to give the user the option to perform geometry optimisations in cartesian coordinates instead of internal redundants? I guess the answer depends on finding a workaround for the first part of my question...

On a different topic, I recently noticed that autodE fails for some very simple reactions, and I was trying to figure out why. After looking closely at the output files I noticed that most of the problems were caused by the use of xTB in the adaptive path method used to create the initial path and create an estimate of the TSs. The resulting TS guesses are so bad and distorted that autodE can never recover from and the calculation fails. Interestingly, autodE would check that the TS doesn't lead to the products and would switch to the adaptive path with the use of DFT. Sometimes though, the checks are passed and autodE promotes the TS guess to calculations downstream, despite the fact that the graph of it doesn't meet the criteria set by the program. After the DFT TS optimisation and an attempt to probe the conformational space of the TS resulting in one conformer only, autodE crashes because it realises that the only conformer found has the wrong connectivity and is left with no conformers at all to proceed.

I am still trying to find the cause of all this and I will come back with more information. In the meantime is it possible to use the method calculate_reaction_profile to perform the calculations as normal but skipping the use of xtb in the adaptive path method used for finding the TS (i.e. using DFT for the adaptive path directly)?