Spartan '14 Help
Back to Main or Home(J)

Convergence Questions

The algorithms in Spartan will typically perform well on most systems when solving quantum mechanical equations. However, there are times when one may see "convergence problems". What to do when this occurs? The following covers the typical areas to examine when a calculation has trouble converging.

The first question to ask is "Am I having problems converging the geometry, or the wavefunction?" The answer to this question will lead to different sections of this FAQ below. The first section "General Issues" covers some topics which are relevant to both geometry and wavefunction (SCF) convergence.


General Issues

Some common convergence issues: If you've made it this far, you have examined your molecule and believe everything is correct in the calculation setup. Now it's time to delve deeper into the calculation. The first thing to do is determine whether problems are related to the geometry optimization or the self consistent field calculation (SCF) of the wavefunction. If you have one or more geometry cycles displayed in the output dialogue, the problem is likely related to geometry optimization. (Of course, there may be exceptions, so examine the error message carefully.)

The following section includes several references to "keywords". Keywords are type-in options, to be entered in the "Options" field in Spartan's calculation dialogue. Keywords are NOT case sensitive. Multiple keywords are separated by spaces.

Geometry Optimization Issues

  • Re-examine the geometry.
    If the starting geometry is poor, some new chemistry might be occurring that you do not anticipate. For example, if a hydrogen is too close to a nitrogen, a bond may form (that you don't want) Recall that the bonds drawn on the screen mean absolutely nothing to the quantum calculations.

    At times the job may be converging normally, just slowly, and one only needs to resubmit a job that has 'run out of cycles'. But before you resubmit, examine the current conformation of the molecule. Jobs that run out of cycles do so because atoms have moved a lot during the geometry optimization. Chances are that some chemistry is occurring (a bond forming or breaking) that you may not desire.. This could be due to poor initial geometry (see above) or a poor initial Hessian (discussed below). Adding the GEOMETRYCYCLES=xxx or OPTCYCLE=xxx (where xxx is some large number) keyword should keep the job from terminating early.

    It is also possible that the algorithm is seeking the minima (or transition state) at a higher level of precision than you need. You can change the precision criteria by using the GRADIENTTOLERANCE=x or DISTANCETOLERANCE=x. (TOLG=x or TOLD=x are shorter versions of these keywords.)

  • Check the Hessian
    The most common problem with geometry optimizations is that the default Hessian is poor. Usually a molecular mechanics Hessian saves many geometry optimization steps for standard systems, and semi-empirical Hessians are good for transition searches. (These are the defaults). But these defaults can sometimes be poor approximations for molecules outside their range of parameterization.

    You can choose a conservative Hessian with the HESS=UNIT keyword. While this will typically avoid bad modes in the Hessian, it does slow the optimization procedures.

    The best Hessian is one generated at the same theory level as the one you are attempting use for optimization. Often this is too expensive (from a time perspective) to calculate, but if you are having trouble you may want to generate this high quality Hessian. This can be accomplished by doing an energy calculation with the IR button checked. (This will generate a Hessian.) When this completes you can resubmit the job as a geometry optimization (or transition state optimization).

  • Start simple
    It is always good advice to start by using a lower theory level. In general we suggest using the Minimizer (the Minimize button in the Spartan interface uses molecular mechanics to reduce strain energy and 'clean up' molecules that have been constructed by hand), and then (perhaps) doing a quick geometry optimization at a simple level of theory such as semi-empirical or Hartree-Fock with a small basis (3-21G*). There are, however, instances when this might not be a good idea; for example, one should NOT typically use the Minimizer before submitting a Transition State Geometry optimization. There are also cases where a lower level theory level may simply produce poor results on your type of molecule. After some hands-on experience you will know better than anyone else what works for your favorite class of molecules.

    Another approach is useful when building large molecules:
    1. Start with a small core of your molecule and optimize it at the theory you desire.
    2. Then add some atoms to the core, (perhaps minimizing the new atoms with molecular mechanics, while 'freezing' the original core)
    3. Optionally, you may want to freeze the core atoms and minimize the new atoms at a lower theory level. You can use molecular mechanics in the Spartan interface (the Minimize button), or any other theory from the calculations dialogue. (Make sure to select the "Frozen Atoms" box next to the words "Subject To:" in the calculations dialogue.)
    4. Then submit the entire molecule for a final geometry optimization. Make sure to deselect "frozen atoms" in the calculations dialogue.
    You can repeat this procedure until the full molecule is complete. The above approach is often useful when searching for transition states.


Special Issues with Transition State Searches

Spartan treats Transition State searches as a special case of geometry optimizations. Because of the flat nature of the potential energy surface and other unique characteristics of transition states, transition state geometry tasks can be more difficult to perform than the typical ground state geometry. The above discussion on geometry optimizations holds for transition state geometries. The strategy of starting small and working up to larger molecules and methods applies to transition state searching. However, for efficient transition state searches the importance of a good starting geometry and a good Hessian are especially critical.

A good starting geometry can be found using Spartan's transition state builder/searching feature. A number of examples of using this can be found in Chapter 10 of our Spartan '14 Tutorial and User's Guide. (Also see the sections on Spartan Reaction Database and Transition States in Chapter 22 for additional information on these features.) Setting up an Energy Profile calculation is another way of getting a good starting point for transition state geometry tasks.

Once a good starting point is found a good Hessian is required. Often Spartan's default Hessian (a semi-empirical guess) is good enough. The best Hessian is obtained from an initial IR/frequency calculation. i.e. First do a single point energy calculation with the IR property checked. When this completes, examine the vibrations (Display Menu > Spectra). Ideally there is one negative frequency (noted with an "i" in front of the frequency), and upon animating, this should look like motion along the reaction coordinate associated with the transition state. If largest imaginary frequency is not what you expect, or there are no imaginary frequencies, the starting geometry is not close enough to the transition state.

In very difficult cases I sometimes force a complete analytical/exact Hessian every few cycles. For example assuming the geometry is close to the actual transition state would :

  1. do a single point energy with IR selected.
  2. check to make sure there is only 1 negative eigenvalue, and that it looks right by animating it.
  3. run a TS with the keyword OPTCYCLE=5 (or some small number). This job will (most likely) run out of optimization cycles.
  4. Go back to step 1 to get the real/exact hessian and repeat.

If at any point in step 2 you discover that there is no longer a good negative eigenvalue you need to adjust the geometry. One useful strategy is to do an energy profile calculation to find a rough TS. The SN2 Reaction of Bromide and Methyl Chloride tutorial and the Thermodynamic vs. Kinetic Control tutorial (from Chapter 10 of the Spartan '14 Tutorial and User's Guide provide good examples of this strategy.

Wavefunction (SCF) Convergence Issues

Gaining insight into SCF convergence issues is more difficult. The non-linear Schrodinger equation and the non-locality of electrons make it difficult to understand what is actually occurring. It is often useful to request progress data from the convergence process. This can be done by using the PRINTLEV=2 keyword, or examining the "Verbose Output". Examining this output can yield several clues, you should see both the energy and the "DIIS error" slowly decrease. We suggest you try some of the steps below and observe their results in the verbose output.

  • Likely the first keyword to try is the CONVERGE keyword. This changes a number of internal flags which often leads to better SCF stability, at the cost of slower performance. For more information see below for more specifics.
  • If it looks like the system is converging, just slowly, you may simply need to be patient and let the optimization continue on its own. Use the SCFCYCLE=xxx to increase the number of SCF cycles to try before the program gives up.
  • If the SCF looks like it has stopped converging, but the "Error" is not decreasing, you may need to change the tolerance. Setting SCFTOLERANCE=HIGH or SCFTOLERANCE=VERYHIGH increases internal accuracy. While this may make the calculation more internally consistent (thus improving convergence), it will demand lower error (thus demanding more cycles). Conversely SCFTOLERANCE=LOW will decrease the tolerances, usually speeding up the calculation at the cost of a significant reduction in precision. This is not advised for geometry optimizations.
  • If you can live with a less accurate result, you can allow the convergence algorithm to stop earlier by using the previously mentioned SCFTOLERANCE keyword with a tolerance level. For example, using SCFTOLERACE=6 keyword (default value is 7). Note the format of SCFTOLERANCE is flexible; "0.000001", "1.0e-6", and "6" all mean the same thing. If you increase SCFTOLERANCE above 7, you should also increase THRESH=x to a value that is at least 2x greater than the new SCFTOLERANCE.
  • For difficult cases, it is sometimes helpful to combine the SCFTOLERANCE=LOW with the "CONVERGE" keyword. This will increase the precision of the integrals, while at the same time requiring lower convergence. As mentioned above this is not advised for geometry optimizations, and if used there should only be done for the first few geometry cycles.
  • It is possible that the initial wavefunction is bad. You can change the initial guess with the GUESS=CORE keyword. If you have an open shell system you may need to add the MIX keyword to construct a better guess. For some systems with metals the default guess is already a core guess. In this case you may achieve better results with the GUESS=SAD keyword. (SAD stands for "superposition of atomic densities", a quick method for generating a initial wavefunction.)
  • Sometimes molecules with diffuse basis sets can cause unique problems. This can be attributed to "nearly linearly dependent" basis functions. Spartan automatically checks for linear dependence in the basis set, and will project out near-degeneracies, if they exist. This will result in there being slightly few molecular orbitals than there are basis functions. This is done by considering the eigenvalues of the overlap matrix. Very small eigenvalues are an indication that the basis set is close to being linearly dependent. The size at which the eigenvalues are considered to be too small is governed by the option keyword BASIS_LIN_DEP_THRESH. By default this is set to 5, corresponding to a threshold of 10^-5. This has been found to give reliable results, however, if you have a poorly behaved SCF, and you suspect there maybe linear dependence in you basis, the threshold should be increased.
  • As a last resort, you may need to adjust the details of the algorithm itself. This is an 'art form', with no hard and fast rules (at least not yet discovered. When they are discovered we will put them into the code explicitly so that the next generation of users will not have to deal with this level of detail.).

    Some relevant keywords are:
    • DIIS=SCF_ALGORITHM or DIIS=DIIS_GDM
    • DIIS=x where x is the dimension of the DIIS space. or NODIIS to turn the standard algorithm off.
    • If you are using semi-empirical methods (MNDO, AM1, RM1, or PM3) some useful keywords are:
      • USEPSEUDO, NOPSEUDO to turn on and off a fast diagonalization method.
      • DAMP=x and NODAMP to turn damping on and off. (x is a number between 0.0 and 1.0.)
    • For HF and DFT methods:
      • VARTHRESH=4 ignore fewer integrals. Default is 3.
      • SCF_ALGORITHM=x where x can be one of DIIS, DM, DIIS_DM, GDM, DIIS_GDM or ROOTHAAN
    • Some DFT only keywords are:
      • BIGGRID to choose a more accurate electron density grid.
      • It should be noted that due to the numerical nature of the DFT calculation the numerical results are often not as stable as HF calculations. You may have to live with smaller tolerances in both the SCF calculation and in geometry optimizations (specifically in the uncertainty of the forces/gradients).

Converging the CPHF in frequency/IR calculation

Rarely, the calculation of the Hessian (frequency) will not converge and produce the "Out of Iterations- IterZ". This is usually due to precision problems so the CONVERGE keyword may help. If, after the examining the verbose output, it seems reasonable that simply waiting longer will cause the job to converge, one can use the keyword SET_ITER=100 keyword to let the algorithm continue 100 steps. (the default is 30.) One can also decrease the convergence criteria by using the SET_CONV=5 keyword. (The default is 6.)

Concluding Remarks

Computational Chemistry is a developing discipline. Quantum chemical calculation methods have matured to a level such that programs like Spartan can routinely provide results for molecular geometries, energies, and a host of calculated properties at a predictable and useful level of accuracy with very little user intervention. Chances are good that if you spend some time with the hints mentioned above, you will overcome any computational obstacles that your specific system presents. Since it is likely that you are focused on a finite class of molecules, when you uncover the approach that works on one system, it is likely that this will also work on similar molecules.

Return to Top

Other Questions

  1. I ran a geometry optimization followed by a frequency calculation and it shows a negative eigenvalue. Doesn't that imply that I've found a transition state?

    Yes it does, If the gradient is zero. There are a few likely causes of this behavior:

    • The frequency calculation and the geometry minimization must be at the same theory level, and with the same basis set.
    • You are *almost* at the minima but the gradient is not sufficiently small.
      In this case the lowest eigenvalues are not that meaningful. If you suspect this is the case, you should be able to double check this by resubmitting the molecule with another geometry optimization and with the gradient tolerance increased a bit. As you are starting this new optimization with a very high quality Hessian you will likely fine tune the minimization in just a few optimization cycles. The energy and the maximum gradient should decrease and the final frequency calculation will show no negative eigenvalues, indicating us that you are indeed at a minima.
    • For some reason the Minimizer found a transition state.
      Many times this is due to a symmetry issue. It may also be that your starting configuration was very close to a transition state, and the minimizer found that transition state (with a zero gradient/force) rather than the minima you were looking for. If this is the case you should physically modify the geometry a bit and submit the job again.
    • A less common explanation might be that the Hessian is not very accurate. In this case you might see a few very small frequencies that (numerically) are very close to zero. This can be the case for very large molecules, and most often occurs with DFT methods due to the inherent numerical approximations used in DFT as well as the numerical electronic grid used.
    Return to Top

  2. A geometry optimization ran out of cycles. How do I restart?

    Simply resubmitting the job will continue the optimization. If you believe it will continue to take a lot of cycles, you can increase the maximum number of cycles with the GEOMETRYCYCLES= keyword. Running out of cycles usually implies that you had a bad starting guess, or that some unexpected chemistry is occurring (such as bond breaking). Review the Geometry optimization section for a more thorough discussion on what can go wrong and how to fix it.

    Return to Top
  3. What are the specifics of the CONVERGE keyword?

    The CONVERGE keyword behaves differently for different computational tasks.

    • For semi-empirical jobs, the CONVERGE keyword is equivalent to DAMP=0.75, DIIS=7, and NOPSEUDO.
    • For quantum mechanics jobs, it is equivalent to VARTHRESH=0, THRESH=0 SMALL_PROD_XCMAT=10 and MAXSCF=15.
    Return to Top
  4. I got a 'CnV slipped through' error message. What should I do?

    This error message implies that there is an approximate symmetry, but not exact enough. (Some internal round-off error in detecting symmetry has occurred.)

    Typically turning off symmetry with the IGNORESYMMETRY keyword will resolve the issue. Sometimes clicking the 'Minimize button' a few times will force the symmetry to be more exact and also solve the problem.



Keywords mentioned

SCF=UNRESTRICTED, SCF=RESTRICTED
HESS=UNIT
GUESS=CORE
SCFTOLERANCE=x
PRINTLEV=2
GEOMETRYCYCLES=999, OPTCYCLE=999
HESS=UNIT
SCFTOLERANCE=x
SCFCYCLE=xxx
THRESH=x *
VARTHRESH=x *
GUESS=CORE
DIIS=x, NODIIS
USEPSEUDO, NOPSEUDO *
DAMP=x, NODAMP *
SCF_ALGORITHM=x *
BIGGRID *
CONVERGE
BASIS_LIN_DEP_THRESH
Return to Top



Back to Main or Home(J)
japan@wavefun.com
Last modified: Thu Jun 20 10:47:57 PDT 2013