4.7. 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.
At present, analytical Hessians can be calculated for SCF only. However, there are some additional restrictions. Analytical Hessians cannot be performed for
- Double-Hybrid functionals |
- RI-JK approximation |
Note that there is a separate section of the manual dedicated to vibrational spectroscopy (see section Vibrational Spectroscopy) that contains further examples and describes the calculation of anharmonic effects, Raman spectra, NRVS and things like isotope shifts or visualizing normal modes.
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 Finite Electric Fields).
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” ([560]), 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.
4.7.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 Parallel and Multi-Process Modules (“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, whithTypebeingDipoles,Gradients- and if requestedRamansorNacmes). 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.
4.7.2. Scaling factors for computed frequencies¶
When comparing computed vibrational frequencies to experiment, effects that are not regarded in the harmonic approximation are often corrected for by scaling the computed harmonic freuquencies.
First of all, a standard frequency calculation has to be carried out. After that, a .hess file can be found on disk. This file contains a line with the frequency scaling factor, that can be changed manually:
$frequency_scale_factor
0.90 <<<---- you change this to whatever you want
then, running orca_vib is required:
orca_vib myjob_scaled_freq.hess
The program reads the Hessian, diagonalizes it and applies the scaling factor. Whatever scaling factor was used in the actual input that generated the Hessian is irrelevant since the Hessian is re-diagonalized. To avoid confusion, we recommend that if the goal is to play with the scaling factor, leave the scaling factor in the input at 1.0. Nothing bad happens if you don’t though.
4.7.3. Restarting Numerical Frequency calculations¶
To restart a numerical frequencies calculation, use:
%FREQ
restart true
END
and ORCA will look for basename.res.{} files in the same folder where the calculation is being run, check for what has already been done and restart where it is needed.
4.7.4. Frequencies keyword list¶
In the ORCA program package, the calculation of frequencies through
the numerical or analytical Hessian is done via the orca_numfreq module and
the combination of the orca_propint, orca_scfresp, and orca_prop modules, respectively.
The parameters to control these frequency calculations can be specified in the %freq-block. Relevant simple input keywords are given in Table 4.6.
%freq
# Flags to switch frequencies calculation on/off
NumFreq false # numerical frequencies (available for all methods)
AnFreq false # analytical frequencies (available for HF, DFT)
# (One of these options has to be set to true,
# to request a freq calculation)
ScalFreq 1.0 # Scaling factor for frequencies (default = 1.0)
# NOTE: Scaling is applied to the frequencies after they are
# calculated. SCALED frequencies will be stored in the
# .hess file and printed in the output file.
# In the .hess file you have accesss to the frequency
# scaling factor (see below).
# Flags to control NumFreq calculation:
CentralDiff true # use central differences [f(x+h)-f(x-h)]/2h - or -
# use one-sided differences [f(x+h)-f(x)]/h
Restart false # restart a (numerical) frequency calculation
DX 0.005 # increment h
Increment 0.005 # increment h
Hybrid_Hess {...} end # calculate (numerical) Hybrid Hessian
Partial_Hess [...] end # calculate (numerical) Partial Hessian
# Flags to control subsequent vibrational analysis:
QuasiRRHO true # Evaluate Vibrational Entropy with
# Quasi-Rigid Rotor Harmonic Oscillator
QRRHORefFreq 25 # reference frequency used in the QuasiRRHO in cm-1
# default value is 100 from original paper
CutOffFreq 1.0 # Threshold for frequencies to be considered
# in spectra, thermochemistry and printout (cm-1)
Temp 298.15 # run the thermochemistry calculations at user-defined
# temperatures (max 16 temperatures, separated by ',')
T 290, 292, 295 # same as Temp
XTBVPT2 True # use XTB for the VPT2 correction of the IR
Delq 0.5 # the displacement in dimensionless coordinates used
# during the VPT2
TransInvar True # enforce translation invariance after calculating the Hessian?
NumHessTransInvar True # enforce translation invariance while calculating the Hessian?
# NOTE: TransInvar does not reduce the computational cost of the
# Hessian, and can be applied to analytic as well as numeric
# Hessians. NumHessTransInvar reduces the number of gradients
# that need to be calculated by 6 (for two-sided differentiation)
# or 3 (for one-sided differentiation) for numeric Hessians, but
# has no effect for analytic Hessians.
ProjectTR True # project out translation and rotation degrees of freedom
# in frequency calculation and thermochemistry analysis?
end
Keyword |
Description |
|
Perform an analytic frequency calculation (Alias: |
|
Perform a numerical frequency calculation |
|
Use the latest (2016) atomic masses of the most abundant or most stable isotopes instead of atomic weights |