Jump to content

Mod:ts troubleshooting

From ChemWiki

Common Issues Encountered using Gaussian

'"Guess=TCheck" .... were specified ... Continue anyway' appears and the job fails

This is the what happens when you set up a job from a log file or chk file. The default behaviour of GaussView is to create follow-on jobs (using the geometry, wavefunction and some other parameters from the previous job). This can be useful, but it's beyond the scope of this course. To correct this error, delete genchk geom=allcheck from the additional input line, in the Guess tab change the Guess method to Default and in the Solvation tab change the Model to None (or whatever model you were using). To prevent this error, copy the geometry to a new window and set up the job from there.

NtrErr Called from FileIO

This means Gaussian can't open a file or write to it (usually because it doesn't exist). Check the inputs in the job setup window, or see above.

Job fails: Error termination request processed by link 9999

This can mean one of many things unfortunately, as link 9999 is the job cleanup program of Gaussian. This often indicates a problem with the starting geometry. Open the log file in GaussView and see what the last step looks like. This often gives a clue as to what is wrong with the starting geometry. Some things to check are the geometry itself, that there are no extra or missing atoms, that the charge is correct etc.

If you keep getting this for a TS calculation, it indicates that in the initial force constant calculation, multiple negative eigenvalues were found. This will cause the TS calculation to fail by default (which direction should the TS calculation go?). To suppress the failure and force a search for the most significant eigenvalue specify opt=noeigen. Note that for a bad starting geometry this can land you on the wrong TS or with multiple imaginary frequencies, so monitor the job to check it's going in the right direction.

Opt=TS requires force constants or ModRedundant

This means you have requested a TS calculation but have not specified the prior calculation of force constants. To correct this, go to the job setup window and for Calculate Force Constants change 'Never' to Once.

More than one imaginary frequency

This indicates an inadequate starting geometry. Visualise each imaginary frequency (shown as a negative number in Gaussian/GaussView). Often the additional imaginary frequencies are symmetry-breaking where the optimisation algorithm gets 'stuck' on the top of a hill (stationary point). To resolve the problem, you can break the symmetry manually. At the bottom of the Display Vibrations window select Manual Displacement and choose a non-zero value, save the structure and run another TS optimisation. You might need to try different values for the manual displacement.

You should also check that all parameters are held constant between an optimisation and frequency calculation. This includes method, basis set, solvation or anything else that would change the energy or geometry in a calculation.

Edited Redundant Coordinates were ignored

This can indicate a bug with Gaussian. First check the job setup window that opt=modredundant is specified. The best way to fix this problem is to open the input file ('.com' or '.gjf'), scroll to the bottom where the redundant coordinates are specified and check they read something like:

B <atom number 1> <atom number 2> F

instead of

B <atom number 1> <atom number 2> <length> F

Molecule flying apart in TS calculation

If your system looks like it's breaking apart at the bond-forming centre, it suggests that TS calculation is moving in the wrong direction and minimising the reaction coordinate to reactants/products. In other words, the rest of the structure isn't properly minimised. Repeat Method 2 but make sure the atoms in the reaction centre are close enough together.

IRC finishes on the first step

An IRC will terminate when it encounters a shallow enough gradient. Sometimes the TS is too flat and the calculation terminates instantly. There are a couple strategies to deal with this: First, add in the Additional Keywords line IRC=stepsize=n, where n is an integer greater than 10 (default) Try 20 to begin with, then 30. This will cause the IRC calculation to take larger steps, hopefully to a region where the gradient is steeper.

A second, more thorough strategy is to tighten the convergence threshold. However, this requires reoptimising the TS with opt=tight int=grid=ultrafine. Rerun a frequency calculation also with int=grid=ultrafine. Now, for the IRC, specify IRC=tight int=grid=ultrafine or IRC=VTight int=grid=ultrafine. Note that with this strategy, it's not valid to compare energies or even differences in energy between other jobs that aren't optimised with opt=tight int=grid=ultrafine.

"Maximum number of corrector steps exceeded"

A quick fix is to simply increase the number of corrector steps and rerun, but this can often fail too. Specify IRC=MaxCycle=n where n is an integer greater than 20 (default). Try 50. In the case of failure, follow the above.

If this fails again, it might be that the calculation has landed on a bifurcation point/transition state linking two chiral minima. The IRC calculation has followed the PES down until the gradient has reached 0, so under normal circumstances it will terminate. However, the calculation breaks when it checks whether it can go further down in energy and which direction to go. This behaviour is normal and serves as a warning to tell the user that a minimum hasn't been found. This warning can be suppressed by setting Recorrect Steps to Never. Note that this geometry of the IRC is not a minimum now. You must reoptimise the geometry to a minimum by breaking symmetry and checking vibrations.

"Missing or bad data: RBond" when opening a Checkpoint file

This is a Gaussian bug. The easiest way to fix it is to open the log file, copy the geometry and run a single point energy calculation (Energy under Job Type). In addition, under General, uncheck Write Connectivity. Make sure the method, basis set and all other parameters are the same.

Input conversion error in IntKMC

Gaussian may instantly terminate your calculation with the above error message if the pathway to the submitted .gjf includes signs which cannot be interpreted correctly by Gaussian like spaces.

e.g. if folders in your pathway include spaces in their naming like "PC/usr123/TS Lab/exr 2/file.gjf", make sure to find the spaces and delete or replace them. to attain:

"PC/usr123/TS_Lab/exr_2/file.gjf" or "PC/usr123/TSLab/exr2/file.gjf" and your calculation should run fine.