6.5. Vibrational Frequencies

Vibrational frequency calculations are available through analytical differentiation of the SCF energy as well as one- or two-sided numerical differentiation of analytical gradients, i.e. for Hartree-Fock and DFT models. For methods without analytical gradient a numerically calculated gradient can be used (keyword NumGrad) for numerical frequencies. Please note, that this will be a very time consuming calculation.

The use of vibrational frequency calculations is fairly simple:

# any Hartree-Fock or DFT model can be used here
! BP def2-TZVP

# Tight SCF convergence is advisable to minimize the numerical
# noise in the frequencies.
! TightSCF

# perform a geometry optimization first
! Opt

# Run an analytical or numerical frequency calculation afterwards
! AnFreq   # or just ``! Freq''
# numerical:
! NumFreq

# details of the numerical frequency calculation
%freq  CentralDiff true   # use central-differences (this is the default)
       Increment   0.005  # increment in bohr for the
                          # differentiation (default 0.005)
       end

! bohrs
* xyz 0 1
 O          -1.396288    -0.075107     0.052125
 O           1.396289    -0.016261    -0.089970
 H          -1.775703     1.309756    -1.111179
 H           1.775687     0.140443     1.711854
*

At the end of the frequency job you get an output like this:

-----------------------
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:       311.78 cm**-1
   7:       887.65 cm**-1
   8:      1225.38 cm**-1
   9:      1394.81 cm**-1
  10:      3624.88 cm**-1
  11:      3635.73 cm**-1

This output consists of the calculated vibrational frequencies, the vibrational modes and the thermochemical properties at 298.15 K. In the example above there are six frequencies which are identically zero. These frequencies correspond to the rotations and translations of the molecule. They have been projected out of the Hessian before the calculation of the frequencies and thus, the zero values do not tell you anything about the quality of the Hessian that has been diagonalized. The projection can be turned off by PROJECTTR FALSE under %FREQ, so that the frequencies of the translations and rotations can deviate from zero and the deviations represent a metric of the numerical error of the Hessian calculation. This is done automatically when there is e.g. an external electric field that makes the exact translational and/or rotational modes have non-zero frequencies (see section Adding finite electric field). However, in normal cases where the molecule is expected to obey both translational and rotational invariance, it is strongly discouraged to turn off PROJECTTR when calculating thermochemical quantities (especially entropies and Gibbs free energies). This is because when the frequencies of translational and rotational modes exceed CutOffFreq (which is 1 cm\(^{-1}\) by default), their contributions to the partition function will be calculated using the formulas for vibrations. As a result, the calculated entropy is inaccurate (due to treating translations and rotations as vibrations), is sensitive to numerical noise, and in particular exhibits a finite jump when the (theoretically zero) frequencies of the translational and rotational modes cross CutOffFreq. Therefore, the only case where the user needs to turn off PROJECTTR manually is when the exact Hessian is expected to have zero translational and rotational frequencies, and one wants to check how much the translational and rotational eigenvalues of the actually computed Hessian deviate from zero. The thermochemical quantities from such a calculation are less reliable and should not be used; even if they differ considerably from the results with PROJECTTR TRUE, this does not necessarily mean that the latter are unreliable.

Without PROJECTTR FALSE, the reliability of the calculated frequencies has to be judged by comparison of calculations with different convergence criteria, increments, integration grids etc. The numerical error in the frequencies may reach 50 cm\(^{-1}\) but should be considerably smaller in most cases. Significant negative frequencies indicate saddle points of the energy hypersurface and prove that the optimization has not resulted in an energy minimum.

OBS: By default, the Hessian is made translation invariant by applying the “acoustic sum rule” ([788]), which reduces the effect of noise from numerical integration coming from DFT or COSX, except for the Partial and Hybrid Hessians where it does not make sense. It can be set to false by using TRANSINVAR FALSE under %FREQ.

6.5.1. Mass dependencies

Of course the calculated frequencies depend on the masses used for each atom. While this can be influenced later through the orca_vib routine (see Section Isotope Shifts for more detail) and individually for each atom in the geometry input, one might prefer using a set of precise atomic masses rather than the set of atomic weights (which are set as default). This can be achieved through the !Mass2016 keyword, which triggers Orca to use those atomic masses representing either the most abundant isotope or the most stable isotope (if all isotopes are unstable) of a certain element (e.g. the mass of \(^{35}Cl\) for chlorine or the mass of \(^{98}Tc\)).

Note

The calculation of numerical frequencies puts rather high demands on both computer time and accuracy. In order to get reliable frequencies make sure that:

  • Your SCF is tightly converged. A convergence accuracy of at least 10\(^{-7}\) Eh in the total energy and 10\(^{-6}\) in the density is desirable.

  • Grids of at least DEFGRID2 (default) are used.

  • The use of two-sided (i.e. central) differences increases the computation time by a factor of two but gives more accurate and reliable results.

  • Small auxiliary basis sets like DGauss/J or DeMon/J may not result in fully converged frequencies (up to 40 cm\(^{-1}\) difference compared to frequencies calculated without RI). The def2/J universal auxiliary basis sets of Weigend that are now the default in ORCA (or the SARC/J for scalar relativistic calculations) are thought to give sufficiently reliable results.

  • Possibly, the convergence criteria of the geometry optimization need to be tightened in order to get fully converged results.

  • If you can afford it, decrease the numerical increment to 0.001 Bohr or so. This puts even higher demands on the convergence characteristics of the SCF calculation but should also give more accurate numerical second derivatives. If the increment is too small or too high inaccurate results are expected.

The calculation of analytical frequencies is memory consuming. To control memory consumption the %maxcore parameter must be set. For example %maxcore 8192 - use 8 Gb of memory per processor for the calculation. The user should provide the value according to the computer available memory. The batching based on %maxcore parameter will be introduced automatically to overcome probable memory shortage.

Numerical frequency calculations are restartable (but analytical frequency calculations are not). If the numerical frequencies job died for one reason or another you can simply continue from where it stopped as in the following example:

! STO-3G NumFreq
%freq  Restart true  # restart an old calculation
                     # this requires .res.* files to be present
       end
* int 0 1
    C  0 0 0 0.0000   0 0
    C  1 0 0 1.2160   0 0
    H  1 2 0 1.083  180 0
    H  2 1 3 1.083  180 0
*

Note

  • You must not change the level of theory, basis set or any other detail of the calculation. Any change will produce an inconsistent, essentially meaningless Hessian.

  • The geometry at which the Hessian is calculated must be identical. If you followed a geometry optimization by a frequency run then you must restart the numerical frequency calculation from the optimized geometry.

  • Numerical frequencies can be performed in multi-process mode. Please see section Calling the Program with Multiple Processes (“Hints on the use of parallel ORCA”) for more information.

  • The restart of Numerical frequencies will take off from the result files produced during the preceding run (BaseName.res.%5d.Type, whith Type being Dipoles, Gradients - and if requested Ramans or Nacmes). Please make sure that all these local result files get copied to your compute directory. If restart is set and no local files to be found, ORCA will restart from scratch. If ORCA finds a Hessian file on disk, it will only repeat the subsequent analysis.

  • The Hessian can be transformed to redundant internal coordinates. More information can be found in section Printing Hessian in Internal Coordinates.