ORCA Common Errors and Problems

This page lists common errors and problems encountered when running calculations with ORCA.

For problems with installing or setting up ORCA see Setting up ORCA.

Sudden ORCA terminations

If ORCA terminates with the general message: "ORCA finished by error termination in [ORCA module]" with no other useful message above, the reason depends on which ORCA module was running. If the module running was a memory-intensive module such as: orca_mp2, orca_scfhess, orca_mdci, orca_mrci etc. it is possible that the job either ran out of memory or disk space, or there was problem with accessing memory or disk. It could also be a question of running a calculation of a small system with too many cores (running a 60 core calculation of a system with just a few atoms makes no sense and results in unpredictable results).

- For controlling memory see "Not enough memory" error messages" below. It is also a good idea to monitor live the memory usage for a running job (e.g. via the free command on Linux/Unix).

- To check whether the disk was the problem, log onto the scratch space of the computing node and check how much scratch space ORCA was generating. Note that the jobscript may already have deleted the scratch files in case of which you may have to restart the job and monitor how much scratch is generated right before the ORCA scratch. If ORCA generates more scratch than is available on the disk of the node you may be forced to invest in a larger disk for such calculations.

- Also note that random disk read/write errors can occur with ORCA if ORCA is being run on a network drive. A network drive is non-ideal for ORCA calculations where a lot of scratch is being written to disk.

- If neither disk or memory is the problem, then there may be a bug present. Ask in the ORCA forum and please provide all relevant details from the beginning. It is recommended to show the inputfile in the forum post as this helps the developers diagnose the problem much quicker. It is also useful information for the developer if you can reproduce the error on a molecular system that is as simple as possible (e.g. a diatomic molecule) or with an inputfile that contains as few options as possible.

"Not enough memory" error messages

ORCA needs more memory in order to complete the calculation if you get "Not enough memory" messages in the end of the outputfile. Controlling memory is usually necessary for various wavefunction theory calculations (MP2, CCSD(T), CASSCF, MRCI etc.) or when calculating excited states (TDDFT, CIS, EOM-CC, CASSCF, MRCI) or complex molecular properties (Hessian, NMR chemical shifts or spin-spin couplings). Knowing how to control the memory properly often allows you to make more efficient calculations as this reduces batches in some part of the code.

Memory usage in ORCA is controlled by the %maxcore keyword where the user should specify the memory per core in MB that the program is allowed to use.

Example:

! DLPNO-CCSD(T) def2-TZVP def2-TZVP/C
%maxcore 3000
%pal
nprocs 6
end

Here 3000 MB of memory per core is given to ORCA. Since the use of 6 CPU cores was requested this means that the total memory demand of ORCA is 6x3000=18000 MB = 18 GB

Make sure that the computing node has this total amount of physical memory available.

In general you should not ask for more than 75 % of the physical memory available (since ORCA occasionally will use more than the maxcore setting). So if the computer in this case has 24 GB or more of physical memory available, then things should be fine.

If the computing node you are using is also being used by other users, make sure not to request more memory than you are entitled to. For example if a 12-core node has 120 GB of memory and you submit a 6-core job then you are entitled to half of that memory for example (also note that sometimes queuing systems require you specify how much memory you want). So your 6-core job should only be allowed to use 60 GB of memory or a maxcore (memory per core) of 10 000 MB (10GB). As memory usage in ORCA often overshoots maxcore, lowering maxcore down to ~75 % of available physical memory: a maxcore setting of %maxcore 7500 is recommended.

Imaginary vibrational modes from a frequency job of an optimized structure (minimum)

Case 1. Small imaginary modes (~ below 100 cm-1) like:

-----------------------
VIBRATIONAL FREQUENCIES
-----------------------
0: 0.00 cm**-1
1: 0.00 cm**-1
2: 0.00 cm**-1
3: 0.00 cm**-1
4: 0.00 cm**-1
5: 0.00 cm**-1
6: -70.85 cm**-1 ***imaginary mode***
7: -50.05 cm**-1 ***imaginary mode***
8: 48.60 cm**-1
9: 169.21 cm**-1
10: 176.59 cm**-1
11: 241.39 cm**-1

are typically indicative of numerical noise present. The noise causing this might be present in the Hessian alone or it might have been present in in the energy or gradient in the geometry optimization resulting in a suboptimal geometry. In this case, the problem was fixed by increasing the integration grid in ORCA version 4. ORCA 5 has improved grids and thus problems like this are less likely to occur. If the RIJCOSX approximation was used in either the geometry optimization or the Hessian calculation, the numerical noise might also be due to the COSX grid. If you suspect grid noise, try tightening the grid further (go from !Defgrid2 to !Defgrid3 .For more information, see Numerical precision page.

It may also be that you simply need to lower the thresholds for the geometry optimization a bit (maybe the energy surface is a bit flat) so that you converge more precisely to the minimum. A tight geometry optimization ( use !TightOpt keyword) is a convenient way of doing that.

Case 2. Larger imaginary modes like:

VIBRATIONAL FREQUENCIES
-----------------------
0: 0.00 cm**-1
1: 0.00 cm**-1
2: 0.00 cm**-1
3: 0.00 cm**-1
4: 0.00 cm**-1
5: 0.00 cm**-1
6: -646.34 cm**-1 ***imaginary mode***
7: -467.58 cm**-1 ***imaginary mode***
8: -109.76 cm**-1 ***imaginary mode***
9: 7.86 cm**-1

however, are typically not indicative of numerical noise but rather indicative of a geometry that has not converged to a minimum. In this case, the reason for these imaginary modes is that the geometry optimization converged to a higher order saddlepoint. This can happen if the starting geometry for the optimization job was close to such a saddlepoint, particularly, if the saddlepoint geometry is symmetric. This was an example of a substituted biphenyl structure that has a nonplanar minimum but because the starting geometry was planar, the optimization converged to the planar saddlepoint instead. To fix a problem like this, simply change the geometry so that it no longer looks like the saddlepoint geometry.

If continuum solvation (CPCM) was used then it's also possible that the cavity construction (or the surface charges) are to blame, resulting in discontinuities. Turning the continuum off may solve the problem but if the continuum is necessary then it may be necessary to tweak the CPCM setting (e.g. the cavity construction). ORCA 5 has a more sophisticated cavity construction that reduces this problem.

Molecule explodes

In rare cases, geometry optimization of a molecule will cause the molecule to explode, i.e. the coordinates of the atoms are all over the place as revealed by the visualization program.

This can be due to a few reasons:

• Initial structure is bad. Atoms maybe too close. Maybe mix-up of Angstroms and Bohr units.
  Solution: Fix structure.
  

• Heavy elements are missing basis functions or an effective core potential to describe the core electrons.
  Solution: Carefully check what basis functions and ECPs are being assigned to each element (use ! Printbasis keyword to see more information).
  

• Bad behaviour of the optimizer due to the internal coordinates.
  Solution: Switch to a Cartesian coordinate system for the optimization (Use !COpt keyword instead of !Opt keyword). Will take longer but fixes rare cases of the internal coordinate system being inappropriate.

SCF convergence problems

If the SCF struggles to converge there are multiple possible reasons.

Before exploring a different SCF convergence strategy, however, it is worth checking basic things such as:

• Are the coordinates reasonable ? Visualize the coordinates in a visualization program. The SCF will struggle with too long or too short bonds etc.

• Have you mixed up Angstrom and Bohrs ?

• Is the charge and spin multiplicity correct?

• Are heavy elements missing basis functions or effective core potentials ?

• Do you have a complicated open-shell structure with multiple open-shells, perhaps requiring a broken-symmetry DFT strategy ? See BS-DFT page.

• Are you using a diffuse basis set such as aug-cc-pVTZ ? Such diffuse basis set can be difficult to use due to linear dependencies in the basis set. See bottom of this page for a discussion. The best solution is often to avoid such diffuse basis sets unless really needed. See basis set page for other alternatives (e.g. ma-def2-TZVP though it is not immune either to linear dependency problems). Doing a basis set convergence study is a good idea.

• Are you calculating an anion in the gas phase ? Anions are sometimes not stable in the gas phase and a continuum model (CPCM) may be required to stabilize the highest occupied orbitals.

• It the above does not apply, it's likely simply a tricky SCF to converge. Check out the SCF Convergence Issues page.

If nothing works, post your problem in the ORCA forum. To diagnose the problem the ORCA experts typically need to see the whole outputfile or inputfile, ideally with coordinates.

Geometry optimization fails to converge and/or the energy increases during optimization

There are a few reasons this could happen.

- If the energy during the optimization is not decreasing (as it should) then it is likely that there is numerical noise in the gradient. What might be happening is that during each step when the gradient is calculated, the noise in the gradient makes the optimizer predict inaccurate geometries. This numerical noise is most likely due to the use of an integration grid in the DFT exchange-correlation term or the COSX grid in the RIJCOSX approximation. Often the DFT exchange-correlation term is to blame and the solution is to increase the integration grid a little bit . It is also possible that the COSX grid is to blame and then an increase of the COSX grid would fix the problem. These problems are less common in ORCA 5. For more information, see Numerical precision page.

- It is also possible that the internal coordinate system in use (redundant internal coordinates) confuses the optimizer program that leads it to take bad steps (i.e. bad geometries). Switching to a Cartesian-coordinate optimizations ( ! COpt), even for just a few steps may fix this problem, and one can then switch to the faster internal coordinates later.

SCF energy or property is strange ( e.g. differs from a previous calculation or another program or charges, spin populations or orbitals are strange)

What can happen in any SCF calculation (DFT or HF) is that it converges to either an excited state (i.e. a different occupation of orbitals) or even a saddlepoint in orbital space instead of a minimum. Such cases are rare but are more likely to happen in cases of high symmetry (e.g. atoms, diatomics, or other high-symmetry geometries, e.g. benzene and ferrocene). This problem can subsequently affect a post-HF calculation, e.g. MP2, coupled-cluster.

As an example, this inputfile for diatomic I₂:

! B3LYP def2-TZVPP tightscf kdiis

*xyz 0 1
I -0.8112688 -0.2430916 0.0150128
I 1.8686027 -0.3386353 -0.0757158
*

will result in an SCF solution with an energy of -595.256765 hartree.

While nothing seemingly suspicious about this straightforward restricted DFT calculation, the energy is (as seen later) here much too high. This problematic example was discovered when an unusually large reaction energy for the reaction: Metalcomplex + I₂ => Metal-I₂-complex was found when calculating using B3LYP/def2-TZVPP with KDIIS.

The following things can be tried to find out whether the SCF solution is appropriate.

• Try different SCF convergers.

If KDIIS is turned off in this case, the energy is : -595.4364778 au instead; 112.8 kcal/mol lower in energy.

It thus seems that the use of the KDIIS algorithm (instead of the default DIIS) for some reason (likely random) made the calculation converge to something else. A bad SCF solution can be quite sensitive to the converger strategy used.

• Try different guesses for the initial orbitals.

If the guess is switched from the default PModel guess to the !Patom or !Hueckel guess, the SCF converges (with KDIIS) in this case to the correct -595.4364778 au energy. Often a bad SCF solution is quite dependent on the starting guess orbitals.

• Try rotating the valence orbitals (e.g. HOMO-LUMO) of the suspicious solution

A common reason for a wrong SCF solution is that highest-lying electrons are occupying the wrong orbital.

By reading in the orbitals of the previously converged solution and swapping the HOMO and the LUMO orbitals (or possibly: HOMO and LUMO+1, HOMO and LUMO+2, HOMO-1 and LUMO etc.) the SCF can be reconverged to the correct solution. Here the HOMO is no. 24 and the LUMO is no. 25.

! B3LYP def2-TZVPP tightscf kdiis MOREAD
%moinp "previous.gbw"
%scf
rotate {24,25,90,0,0} end
end

For this example, swapping HOMO and LUMO orbitals and reconverging, results in a correct converged energy of -595.43648 au. Note: this only works for this example if the orbitals are swapped at the previously converged solution via MOREAD (not if the orbitals are swapped in the beginning using the regular default guess orbitals).

• Analyze the electronic structure

By manually inspecting the electronic structure one can usually tell if something is wrong. Often the Mulliken charges or spin populations may already reveal if something is wrong, though in the case of diatomic iodine there is nothing to inspect since the atomic charges are zero and there is no spin density.

If the molecular orbitals are analyzed, however, the problem becomes clear for our example. For the higher-energy solution the HOMO looks like a σ* orbital while the LUMO is a nonbonding orbital. Chemical intuition obviously tells us that the σ* orbital should not be occupied for I₂.

For the lower-energy solution, this is in reverse, where the HOMO is a nonbonding orbital (iodine lonepair as expected) and the LUMO is a σ* orbital. The orbital analysis thus reveals what has happened, the SCF has converged to a solution where the HOMO and LUMO orbitals are swapped and the antibonding LUMO is occupied by 2 electrons. This antibonding character of this wrong SCF solution increases the total energy of the molecule by 112.8 kcal/mol.

• Perform a TDDFT calculation on top of the SCF.

By solving the TDDFT equations and analyzing the first transition energies can reveal whether you have converged to something strange; either a saddlepoint or an excited state (different electronic configuration).

Add %tddft nroots 4 end to the inputfile and run the calculation again.

The TDDFT output reveals:

STATE 1: E= -0.098115 au -2.670 eV -21533.7 cm**-1

24a -> 25a : 0.997998 (c= -0.99899838)

STATE 2: E= -0.010974 au -0.299 eV -2408.6 cm**-1

23a -> 25a : 0.998581 (c= -0.99929003)

STATE 3: E= 0.044783 au 1.219 eV 9828.6 cm**-1

22a -> 25a : 0.998823 (c= 0.99941125)

STATE 4: E= 0.092765 au 2.524 eV 20359.5 cm**-1

20a -> 25a : 0.994562 (c= -0.99727746)

showing that the first excited states have negative transition energies which does not make sense since they should be positive for a TDDFT calculation performed on the ground-state.

This suggests either that you have converged to an excited state or a saddlepoint. In fact the dominant orbital-hole pair for STATE 1 with the negative transition energy of -2.67 eV suggests that the HOMO (24) and LUMO(25) should be swapped as we had previously found out.

Note: The lack of negative transition energies does not rule out that your SCF is an excited state. The true ground-state may simply be inaccessible from the TDDFT linear response equations performed on the current SCF solution.

• Do a stability analysis of the SCF wavefunction

Add:

%scf Stabperform true end

to the inputfile. Once the SCF has converged, the electronic Hessian is calculated and ORCA will report if the SCF has converged to a saddlepoint in orbital space:

SCF STABILITY ANALYSIS RESULT

-----------------------------

RHF/RKS->UHF/UKS - triplet - external

Root Eigenvalue (au)

0 -0.132711

1 -0.045713

2 -0.021069

Stability Analysis indicates an UNSTABLE HF/KS wave function with SEVERAL negative eigenvalues.

--------------------------------------------------------------------

WARNING

Although your wave function is converged, the stability analysis

revealed an instability towards an UHF/UKS solution.

It is up to you to decide whether to use the wave function.

If you want to, it can be retrieved through the gbw file for

use as a guess for an UHF/UKS calculation or for RHF/RKS post-SCF.

--------------------------------------------------------------------

The stability analysis here clearly reveals that the SCF has converged to an n-th order saddlepoint instead of a minimum. For UHF/UKS wavefunctions the program can shift the solution in the direction of the eigenvector associated with the negative eigenvalue and attempt to reconverge. This is not possible for RHF/RKS so you may have to add the UHF/UKS keyword to the inputfile in order to use this feature.

ORCA calculation results differ from Program X

If you make a switch to ORCA from another program you may want to make sure that the two programs give the same results for a typical calculation. A few things to keep in mind when making this comparison:

• Start by comparing single-point calculations on the same geometry. A single-point energy comparision makes things easier to diagnose, as the programs may have different optimization algorithms and different thresholds for signalling convergence.

• Pay attention to the SCF convergence thresholds in the programs as well as the use of RI/RIJK/RIJCOSX approximations (might be best to turn these approximations off, to begin with, in both programs).

• It is easier to first compare a Hartree-Fock calculation than a DFT calculation. The Hartree-Fock method should be implemented identically in all programs but this is not always the case for a DFT calculation. DFT calculations come in the form of many different functionals that are sometimes implemented differently in different programs. Additionally the DFT exchange-correlation term requires numerical integration using a grid. Numerical integration can be handled differently in different programs and introduces numerical noise that needs to be minimized. A HF calculation should not have any numerical integration errors like this present.

• If you can reproduce HF energies with both programs but not DFT energies then you should next worry about differences in the exchange-correlation grid or a possibly different implementation of the functional. Also note that non-hybrid vs. hybrid DFT calculations may behave differently (perhaps the HF exchange is treated differently in the 2 programs).

• If you want to compare DFT results then pay special attention to the integration grid in both programs. It is probably too difficult to reproduce the same integration grid in both programs so an easier strategy is to crank up the integration grid in both programs (using their respective keywords) until the total energy stops (to a reasonable threshold) changing for each program as the grid increases. Once the numerical noise has been reduced, the energies should be comparable.

• If you want to compare B3LYP calculations in both programs then the exact B3LYP implementation matters. Unfortunately, least two different implementations exist where the functional differs in the precise LDA correlation functional used. One of them is sometimes called "Gaussian-style B3LYP" and the other one "Turbomole-style B3LYP". ORCA has both implementations: Use !B3LYP/G for Gaussian-style and !B3LYP for Turbomole-style. The two definitions will result in considerable differences in the total energy while not huge differences for relative energies (i.e. the B3LYP defintions are probably about equally good/bad).

• If you want to compare wB97X functionals then note that these functionals come in many different forms: wB97X, wB97X-D, wB97X-D3, wB97X-D3BJ, wB97X-V etc. These functionals do not only differ in terms of different dispersion correction but some of them have very different parameters (both range-separation parameters but also exchange and correlation functional parameters).
  wB97X != wB97X-D (minus dispersion term) and wB97X-D3 != wB97X-D3BJ != wB97X-V (minus dispersion term)

• Calculations on atoms (and sometimes diatomics or other molecules of high symmetry) are prone to finding alternative SCF solutions, depending on the orbital-guess. Try different guesses, stability analysis or swap orbitals manually as discussed above.

See also this forum thread for an example.

• There could be a difference between basis set implementations in programs. Pople-style (6-31G and 6-311G etc.) basis sets can for example be quite different as they were developed with Cartesian basis functions (e.g. 6 d-functions and 10 f-functions) in mind while ORCA uses spherical harmonics (5 d-functions and 7 f-functions). See more information in the manual. To avoid this uncertainty, maybe pick a basis set that is implemented in the same way in both programs, e.g. def2-SVP or cc-pVDZ. Use !PrintBasis in ORCA (and the appropriate keyword in the other program) to print out the basis set and compare directly the functions (note though that contraction coefficient may differ in terms of normalization).

• If you are calculating heavy elements then make sure the effective core potential is the same in both programs. The def2-ECP may e.g. differ between programs.

• If you use ZORA or DKH approximations then pay attention to possible implementation differences. Also note whether the 1-center approximation is turned on or off in ORCA.

• If you compare TDDFT results then check whether the Tamm-Dancoff approximation is being used or not. It is used by default in ORCA but not always in other programs.

• Continuum solvation models can be implemented differently in different programs. The cavity definition is of particular importance. Compare atomic radii that are used to define the cavity and whether GEPOL SES/SAS is being used.

• If you compare post-HF calculations then the frozen core definition in both programs is a crucial aspect. Frozen core definitions in ORCA have recently been updated and should be reliable. But other programs may have quite different defaults, especially for 3d transition metals or heavy p-block elements.

• If you compare coupled cluster results then pay attention to how the reference wavefunction is generated. This is particularly important for open-shell coupled cluster calculations. See coupled-cluster page. Note that open-shell DLPNO coupled cluster calculations use by default QRO reference orbitals.