Hi all,
I have a compound with a particular functional group surrounded by water molecules. I am using Gaussian G09 to optimise, first with HF/6-31+g** and then I will progressively move higher per stable structure. Unfortunately, of the twenty different model arrangements (4 functional groups I am interested in and 8, 10, 12, 14, 16) water molecules neighbouring) only three of the twenty ran successfully. The others suffered from the following error (atom numbers will have been different obviously):
GradGradGradGradGradGradGradGradGradGradGradGradGradGradGradGradGradGrad
Berny optimization.
Using GEDIIS/GDIIS optimizer.
Bend failed for angle 39 - 70 - 68
Tors failed for dihedral 15 - 39 - 70 - 68
Tors failed for dihedral 51 - 39 - 70 - 68
Tors failed for dihedral 69 - 68 - 70 - 39
FormBX had a problem.
Error termination via Lnk1e in /usr/local/g09_d01/l103.exe at Tue Mar 24 10:12:24 2015.
When I investigate this further, the first failure (Bend on the angle 39, 70, 68) is an angle between the oxygen and hydrogen of a water, followed by the hydrogen of a hydroxyl group. It turns out to be exactly 180 degrees. I understand the optimisation algorithm in gaussian struggles with inline angle.
Surely, restarting with a different arrangement to the water molecules isn't the best or only solution? Any tips or suggestions are very grateful.
Thanks
Anthony
Maybe you are using the opt=Z-Matrix option? I see no reason why you'd want to represent a system of many molecules by a Z-matrix, and from the log message it seems to me that's what you're doing here. I am by no means an expert, but I'd try to run optimization in Cartesian coordinates to avoid running into trouble with dihedrals.
You can try restarting the job with geom=(checkpoint,newdefinition); the last option will force gaussian to try different redundant coordinates for the system.
As Miłosz suggested, you can try opt=cartesian (providing the geometry in cartesian coordinates is different from running optimization in cartesian coordinates).
Other than that, the only idea I have is to change the starting geometry.
The problem with your calculation, similarly to what was stated before, is only a failure in the redundant coordinate system. Gaussian automatically builds redundant coordinates at the start of every calculation. During the course of an optimization these can become close to 180 deg and then the algorithm fails. There is in general nothing wrong with your calculation, the algorithm just cannot continue this way. It is not a problem at all.
You have several options to surpass this problem:
Redundant coordinates are a key ingredient to efficient computation, skipping them prevents you from that. To even cut more off the slate, you might want to consider running semi-empirical or force field pre-optimisations.
Hi Bartosz and Martin,
Many thanks for those answer. I've been using Gaussian for a while now yet evidently, there is still more theory and techniques I've yet to learn. I'll give these a try. Many thanks again.
Hi all, I've given some of the above suggestions a try.
Starting very low I began with HF/3-21+g* (freq and opt=loose). The face two issues:
1) WITHOUT cartesian, this approach I get 3/4 requirements converged with Maximum Force 0.009396 0.002500 NO still not converged. Then the simulation crashes because of the linear bend issue (the hydrogen bond between water the a hydroxyl group hit 180 degrees).
2) WITH opt=cartesian, my calculation never converges, not even 2/4 requirements converge. Is there a limitation (and I don't mean time) to the opt algorithm if I use 'cartesian'?
At the moment I am using the last step where the calculation satisfied all by the Maximum Force, and I'm running a Frequency calculation to see if it is a minimum. If it is I will increase the basis set for a more accurate energy calculation later on.
Edit: Running Freq on suggestion (1) are 3/4 convergence requirements were meet is producing three negative frequencies. Checking in GView, the largest negative frequencies are all the explicit water molecules.
Any thoughts are greatly appreciated. Thanks
4 years ago. This answer will be useless for all who took part in conversation, but may be someone else will read it. I agree that there are few possible solutions that Martin Schwarzer described. However i would disagree on their evaluation, especially on strongly negative characterisation of optimisation in cartesian coordinates. This way is not so horribly expansive. 1.5-2 time more expensive than redundant in the very worst case. Keep in mind that majority of periodic codes works exclusively with cartesian optimisations. This might be not extremely elegant solution but the safest and easiest.
Late to the party, but anyhoo
This is a redundant coordinate problem as stated by others. However, it is not complicated to fix as the output gives you a hint.
If you encounter this, view the molecule and locate the problematic angle. Then add redundant coordinates, replacing one of the atoms with one that doesn't give 180°. For instance, in the example given, you can replace the center atom 70 with atom center AtN, where angle 39-AtN-68 is not 180°.
39 AtN 68
15 39 AtN 68
51 39 AtN 68
69 68 AtN 39
Don't forget the modredundant option to opt.
I trust that the question was solved in the best way from the outstanding replies of good colleagues. Furthermore, nice to share an outstanding summary about "How to solve the error message in Gaussian" as follow:
https://docs.computecanada.ca/wiki/Gaussian_error_messages
Have a good day!!!@
Check https://computational-chemistry.com/en/blog/error-stopping-in-linear-structure-gaussian-09-16/
Thank you all so much for the answers to this problem. Really helped a lot when I encountered same problem
- Badges
- Science topic
- Similar topics
- Correction