
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:
 Geometry
Examine the molecule carefully. Try the same calculation at
a simpler theory level or with a smaller basis set. If the lower
theories work, they are likely good starting points for
advanced theories. (For quantum chemical calculations, theoretical approaches are listed in order of increasing complexity: Semi Empirical < HartreeFock < Density Functional < Configuration Interaction and Moller Plesset < Advanced Correlated).
Examine the molecule's current geometry carefully; do the
bond distances and angles seem correct? (Or nearly correct?)
Molecular Mechanics can sometimes produce strange results when metals
are involved. Semiempirical is fast and often very good, but it
also may also suffer from poor approximations, and may not be good
enough for your molecule.
Another common problem is that the
current geometry may have a symmetry that is not
a reasonable energy minima in the theory you are attempting
to use. Turning "Symmetry" off is sometimes
appropriate; this can be done by using the
IGNORESYMMETRY keyword.
Sometimes it is also necessary to physically break symmetry
by slightly changing bond distances or angles. (Watch the
symmetry label in the bottom right of the screen to determine if
your changes are large enough.)
 Charge
Make sure to count electrons and look for radicals in your
molecule. The charge and number of unpaired electrons
specified in the
Calculation Dialogue must be consistent with the
molecule.
 Unpaired Electrons
Are there unpaired
electrons? If so, you may want to choose an unrestricted
calculation by typing either SCF=UNRESTRICTED or
SCF=RESTRICTED
keyword in the options field in the calculation dialogue.
If your system includes a metal atom, ask yourself if the
metal is in a high or low spin state. Hemoglobin
complexing with Carbondioxide and molecular Oxygen are
common examples
where spin states need to be accounted for. Make sure
the multiplicity is consistent with the state you desire.
In questionable configurations one may need to try differing
number of unpaired electrons to see which one has the lowest
calculated energy. (i.e. 0,2,4... or
1,3,5... etc. depending on
whether there is an even or odd total number of electrons.)
 Symmetry
The use of symmetry can dramatically speed up calculations on
small symmetric molecules. However attempting to use symmetry
can sometimes cause difficulty in convergence. Use the
IGNORESYMMETRY keyword to disable the use of symmetry.
As mentioned in the
geometry section,
it is sometimes useful to physically break symmetry.
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 typein options, to be entered in the "Options" field in
Spartan's calculation dialogue. Keywords are NOT case sensitive. Multiple keywords are separated
by spaces.
 Reexamine 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 semiempirical 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 semiempirical or HartreeFock with a small basis (321G*).
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 handson experience you
will know better than anyone else what works for your favorite
class of molecules.
Another approach is useful when building large
molecules:
 Start with a small core of your molecule and
optimize it at the theory you desire.
 Then add some atoms to the
core, (perhaps minimizing the new atoms with molecular
mechanics, while 'freezing' the original core)
 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.)
 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.
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 semiempirical
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 :
 do a single point energy with IR selected.
 check to make sure there is only 1 negative eigenvalue, and
that it looks right by animating it.
 run a TS with the keyword OPTCYCLE=5 (or some small
number). This job will (most likely) run out of optimization
cycles.
 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 nonlinear Schrodinger equation and the
nonlocality 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.0e6", 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
neardegeneracies, 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 semiempirical 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.)
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

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
 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
 What are the specifics of the
CONVERGE keyword?
The CONVERGE keyword behaves differently for different
computational tasks.
 For semiempirical 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
 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 roundoff
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.
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
