1.7. Troubleshooting Problems in ORCA¶
When starting out with ORCA, trying out features for the first time, or when delving deeper into computational studies, one may run into issues that need troubleshooting. In this section, we summarize typical sources of errors and the error messages encountered to help with troubleshooting common problems.
Note
This section is to be a growing library of examples of common issues. If you are not able to find a solution to your problem here, please post in the ORCA Forum with a general description of your issue and—if possible—the input and/or output files that showcase the issue. If a type of problem comes up often enough, it will be included in this section for future releases!
1.7.1. ORCA Does Not Run…¶
If ORCA does not seem to be running at all, make sure that the path variables are set correctly (refer to the
Installation section) and that there are no other programs on your system that interfere with
the use of ORCA. One example is if there is another program named ORCA. To check if this is the case, check that
which orca or where orca (or an equivalent thereof) outputs the correct ORCA executable. If it does
not, try using the full path to the ORCA executable when trying to run a job. When in doubt, turn to the
section on Running ORCA.
If ORCA runs for you in serial, but not in parallel, first make sure that you are not running the main ORCA executable with mpirun. The main ORCA driver needs to be run in serial and will call the different modules in parallel if requested in the input file. If you try to run using mpirun, you will typically get the output
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! FATAL ERROR ENCOUNTERED !!!
!!! ----------------------- !!!
!!! I/O OPERATION FAILED !!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
and you may also have an error from prterun/mpirun. If any output is generated, this may be duplicated multiple times.
To run ORCA in parallel, you must also provide the complete path to the ORCA executable. Simply
using orca will result in the error:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! ERROR (ORCA_MAIN): For parallel runs !!!
!!! ORCA has to be called with full pathname !!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
See Hints on the Use of Parallel ORCA for more tips.
1.7.2. Where is my ORCA Output?¶
If you ran ORCA, see that some files were generated, but cannot find the output file itself, you are likely running ORCA without redirecting the output to a file. See Running ORCA for instructions.
If, however, you are missing other files that should be generated by ORCA and you are using a submission script, make sure that the script is copying all relevant files from where the job is actually being run.
1.7.3. Sudden Termination of ORCA¶
The general advice when ORCA terminates unexpectedly is to always look at the last few lines of output—ORCA typically tells you what is going on! For example,
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
INPUT ERROR
UNRECOGNIZED OR DUPLICATED KEYWORD(S) IN SIMPLE INPUT LINE
PAL12
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[file orca_main/main_input_keywordline.cpp, line 13941]:
tells us that the keyword PAL12 is not recognized. This is because
there are only simple keywords for the more common number of processors.
At this point, referencing the manual (searching for “parallel” or “processors”,
for example) tells us that only “PAL2 to PAL8 and PAL16, PAL32, PAL64” are
recognized simple inputs. That same part of the manual shows how to specify
any number of processors using the nprocs keyword in the %pal input block.
However, there are instances where no clear error message is printed. This may look something like this:
ORCA finished by error termination in <ORCA MODULE>
Calling Command: mpirun -np 8 /path/to/orca/module myjob.moduleinp.tmp myjob
[file orca_tools/qcmsg.cpp, line 394]:
.... aborting the run".
At this point, looking at the warnings issued by ORCA at startup can be very
helpful. This is located in the output file section titled WARNINGS—right
after the list of ORCA contributors and before the copy of the input file:
===========================================================================
WARNINGS
Please study these warnings very carefully!
===========================================================================
WARNING: Geometry Optimization
===> : Switching off AutoStart
For restart on a previous wavefunction, please use MOREAD
This is especially helpful if ORCA found something odd, but decided not to terminate and instead assumed that this was intended by the user.
Other warnings may be issued after the startup warnings. Search the output for
other instances of WARNING to see what ORCA flagged as possible issues during the calculation.
This could be—but is not limited to—non-converging (CAS)SCF, CPSCF, or CC iterations, linear
dependencies in the basis set, and memory problems. Typical trademarks of poorly converging
geometry and/or SCF runs include, for example:
*** Resetting DIIS ***
WARNING: the maximum gradient error descreased on average only by a factor 0.9
during the last 20 iterations
*** Initiating the TRAH-SCF procedure ***
or
0 -4604.304089906417 2.255713e+02 0.400 (TRAH MAcro) No
WARNING : negative HOMO - LUMO gap : -60.865582
0 dE -8.949363e+01 1.445336e+01 -5.5474e+02 0.400 (TRAH MIcro)
Next, check to see if the issue is maybe from outside of ORCA. For example, if you exceed time, disk, or memory limits of the queuing system you use to submit ORCA jobs, the system (or sometimes even an administrator) will terminate your job. In this case, there may be no error message or an error message from your queuing system or system shell. The form of error message you see will depend on your operating system and how the queuing system is set up. The queuing system may also gather the errors in a separate file.
1.7.4. Incorrect Input File Syntax¶
The following subsections explore common errors with input file syntax. It may be good in general to refer to the sections General Structure of the Input File and Input of Coordinates.
1.7.4.1. Unknown Simple Input Keyword¶
As shown above, the typical error message associated with an unrecognized simple input keyword is
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
INPUT ERROR
UNRECOGNIZED OR DUPLICATED KEYWORD(S) IN SIMPLE INPUT LINE
<KEYWORD>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
1.7.4.2. Unknown Input Block Keyword¶
Another issue with the input file syntax may be an unrecognized keyword in an input block. The error message for this is typically
Unknown identifier in <BLOCK_NAME> block line <LINE_NUMBER> :
Last token : <KEYWORD>
If you are sure that the keyword exists, check to make sure that you have closed all
input blocks with an end statement. Additionally, there may be some subblocks in the
input blocks that require an end statement.
1.7.4.3. Required Input is Missing¶
It is best practice that all ORCA input files specify at least three things: (1) a geometry, (2) a method to run,
and (3) a basis set. (1) can be set in the %coords block or using the simple input syntax. It may also be read from an
external file. (2) and (3) can be set using simple input keywords or their respective input blocks.
Refer to the sections General Structure of the Input File, Input of Coordinates,
Basis Sets, and the part of the manual for the desired method.
If a method or basis set is not specified, there is often no error message and a default is set. In these cases, it is important to check the output carefully! However, a missing geometry and some auxiliary basis sets do not have defaults and will result in an error. Following are examples of the errors encountered from these issues.
Missing geometry:
You must have a [COORDS] ... [END] block in your input
Missing auxiliary basis (caught in the main check):
ERROR: RI-MP2 needs an AuxC basis but none was defined!
Missing auxiliary basis (caught by SHARK):
Error (TMOIntegrals): Aux/C requested but not available in SHARK
ORCA finished by error termination in <MODULE>
If you are unsure of which auxiliary basis sets to use, a convenient functionality is !AutoAux. Note here that
these automatically generated auxiliary basis sets may lead to linear dependence issues.
Additionally, if an atom Xx is not defined in the provided basis set, it will give the error:
*****************************************************************
** There are no main basis functions on atom number 0 (Xx) **
*****************************************************************
The basis set was either not assigned or not available for this element - Aborting the run
This can be fixed by (1) requesting a different basis set in which that element is defined or (2) using the requested
basis set for all other elements and assigning a different basis set just for that element. This can be achieved by
using NewGTO (see Assigning Basis Functions to an Element).
Simply requesting RI when the chosen method uses exchange integrals will also lead to ORCA aborting,
as it does not know how to handle these integrals. The error message gives the user the options which
may be specified:
Error: RI is on but the HF exchange must be handled somehow
Use one of the keywords
RIJDX : treat the HF exchange exactly (equals RIJONX)
RIJCOSX: treat the HF exchange by chain-of-spheres
RIJK : treat Coulomb and exchange both by RI
Depending on the method run and what other keywords are specified, other inputs may be required. In most of these cases, ORCA outputs an error that should be self-explanatory. This error may, for example, look like:
Error: Missing keyword in <BLOCK_NAME> block
Missing keyword : <KEYWORD>
1.7.4.4. Missing end Statement¶
If an end statement is missing to close out an input block, a couple errors may occur.
Often, one encounters the Unrecognized symbol error, where the next symbol is interpreted as
being a part of the previous input block. This error would be of the form:
Unrecognized symbol in <BLOCK_NAME> block line <LINE_NUMBER> :
Last token : %
One may also get a more obvious error message:
'END' was expected at the end of the <BLOCK_NAME> block line <LINE_NUMBER> :
Last token : <PREVIOUS_KEYWORD>
1.7.4.5. Missing Symbols¶
Just as errors occur with not enough end statements, it is also the case with too many end statements.
For example, some inputs like %base, %moinp, and %MaxCore are global variables and not input blocks.
They therefore do not expect end statements. In this case, the error may look something like this:
ERROR: expect a '$', '!', '%', '*' or '[' in the input
Line <LINE_NUMBER> of <INPUT_FILE> (END)
Here, ORCA was not expecting another keyword and was instead looking for a symbol that would begin a new input block, geometry block, etc.
If instead you provide a keyword outside of an input block, forget the ! at the beginning of a
simple input line or the * for the geometry block, or write a comment without a #, you will get
the same error message as above, just with the first keyword it runs into after the missing symbol in place of END.
Trying to read in external files typically requires the file to be provided in quotation marks. If these are missing for
the %moinp keyword, for example, the error message is:
Error: Quotes expected after scanning %%moinp
An exception to this is that external coordinate files should not be specified using quotation marks in the simple
geometry input section (for example via *xyzfile).
1.7.4.6. Unrecognized Symbols¶
Another issue is if there are extra symbols than what ORCA is expecting.
A common example of this is the simple coordinates input, which begins with an asterisk and ends with an asterisk
on a new line if you provide the coordinates in the input file. However, reading coordinates from an external
file—using the *xyzfile syntax, for example—while also providing a second asterisk (on a new line) gives the error:
ERROR: found a coordinate definition line (* ctyp charge mult)
but could not read ctyp, charge and multiplicity
Using %% to open an input block instead of % or having a stray % in the input file results in the error:
Error: expected an identifier after '%%' in the input
However, using !! instead of ! for the simple input keywords gives an unrecognized keyword error as
it interprets the second exclamation mark as its own keyword. Other symbols that ORCA is not expecting
will give the error:
ERROR: expect a '$', '!', '%', '*' or '[' in the input
1.7.4.7. Cannot Open Files¶
If you need ORCA to read from another file, you will encounter an error if the file specified
does not exist. For example, using *xyzfile 0 1 geom.xyz will give the error
ORCA_ReadXYZFile::Error
There was a problem reading file: geom.xyz
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! FATAL ERROR ENCOUNTERED !!!
!!! ----------------------- !!!
!!! CANNOT OPEN FILE !!!
!!! Filename: geom.xyz !!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
if geom.xyz does not exist. This same error may be seen if the file exists, but quotation marks
are given around the file name. In that case, the error message will include the quotation marks in
the output of the file name.
Additionally, you may encounter this error if the coordinates are specified in the input file via the simple geometry
input block, but the keyword used suggests that ORCA should read from an external file. For example, using the *xyz
coordinate syntax with the keyword *xyzfile gives the error:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! FATAL ERROR ENCOUNTERED !!!
!!! ----------------------- !!!
!!! CANNOT OPEN FILE !!!
!!! Filename: !!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Characteristic here is the absence of a filename, as *xyzfile was used, but no external file was provided.
Other file types may have different error messages. For example, if a GBW file is read in with %moinp MOs.gbw,
but MOs.gbw does not exist, it will give the error:
Cannot open GBW file: MOs.gbw
1.7.4.8. End-of-file (EOF) Issues on Windows Machines¶
If you are running ORCA on a Windows machine, you may run into issues with your input file if it does not end with a blank line. A common case is that the last line tries to read coordinates from an external file, resulting in an error message claiming that the file is missing. If adding a blank line at the end of the input file does not help, also try adding a blank line at the end of (user-created) external files that ORCA is to read from.
1.7.4.9. Non-ASCII Characters¶
You may also get an error if you try to use a non-ASCII character in the input file. In older versions of ORCA, non-ASCII characters were not checked for, which could lead to seemingly valid keywords being flagged as unrecognized. Since ORCA 6.0.1, a helpful error message is printed to aid in finding these characters:
ERROR: non-ASCII character(s) found in words on line <LINE_NUMBER>:
<KEYWORD W/ NON-ASCII> Please remove all non-ASCII characters from your input file
Especially difficult to spot are non-ASCII characters like non-breaking spaces, en- and em-dashes, and the various types of quotation marks as these look very similar to their ASCII counterparts.
1.7.5. Out of Memory (OOM)¶
A typical error message that occurs if %MaxCore is not given
or if insufficient memory is available for the calculation to proceed
is Please increase MaxCore. This will typically be the case if
ORCA tried to estimate the memory needed and found that MaxCore
is not sufficient.
Note
MaxCore is given in MB and is the amount of maximum memory to allocate PER PROCESSING CORE!
ORCA may also overshoot MaxCore during the calculation and is not necessarily set
for all methods. As such, it is generally advised to set
MaxCore such that MaxCore * nprocs <= 0.75(Available Memory).
For some methods, ORCA tries to estimate the memory needed early on
during the calculation. If this estimation is larger than MaxCore, but smaller
than 2*MaxCore, ORCA will issue a warning and proceed. However, if the estimation is larger
than 2*MaxCore, ORCA will abort. You will then have to increase MaxCore
in the input file and run the job again.
In some cases, this rough estimation of the memory required is not enough and ORCA realizes during the calculation that it does not have enough memory to proceed. Such an error may look like this:
[file orca_tools/qcmem.cpp, line 949, Process 7]: OUT OF MEMORY ERROR!
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun noticed that process rank 0 with PID <PID> on node <NODE> exited on signal 11 (Segmentation fault).
--------------------------------------------------------------------------
4 total processes killed (some possibly by mpirun during cleanup)
ORCA finished by error termination in SCF
Calling Command: mpirun -np 8 /path/to/orca_scf_mpi myjob.gbw b myjob
[file orca_tools/qcmsg.cpp, line 458]:
.... aborting the run
Note that the OUT OF MEMORY ERROR message may not be in the output, depending on the method run.
1.7.6. Disk Full¶
Some ORCA calculations require a lot of data to be written to disk. This can either be temporary files used during the calculation and deleted afterwards or files that are stored even after the calculation is finished. If the disk becomes full at some point during the calculation, ORCA will abort. This may happen silently (without a clear error message) or with an error message that typically mentions not being able to write a matrix or set a pointer. For example:
Error TMatrixContainers::AddMatrix - Failed to add <INDICES> to <TMP_FILE>
or
Error TMatrixContainers::AddMatrix - Failed to set FilePointer
1.7.7. Basis Set Linear Dependence¶
If some functions in the basis set used are (nearly) linearly dependent, this may lead to numerical issues in
the calculation. This is more often the case for basis sets with diffuse functions and auxiliary basis sets generated
by !AutoAux. ORCA and SHARK try to catch these issues early. For example, you may see
WARNING! Potentially linear dependencies in the auxiliary basis
===>> At the moment, SHARK is not equipped to deal with this
... sorry, have to bail out
in the output. However, this is sometimes not caught and could lead to numerical instabilities or even ORCA aborting down the line. For example, one may encounter the issue:
Diagonalization failed with error code: -5 !
One part of the output to check in this case is the diagonalization of the overlap matrix. Very small eigenvalues could point to linear dependence issues. This output may look something like:
Diagonalization of the overlap matrix:
Smallest eigenvalue ... 3.064e-08
Time for diagonalization ... 3.223 sec
Threshold for overlap eigenvalues ... 1.000e-07
Number of eigenvalues below threshold ... 3
Smallest eigenvalue above threshold ... 1.002e-07
There are options to help mitigate linear dependence issues, which are explained in more detail in the section on Linear Dependence.
1.7.8. Symmetry of Molecule Not as Expected¶
If you run ORCA with symmetry (via !UseSym), be sure to check that the Auto-detected point group matches what
would be expected. The input geometry may not be perfectly symmetric due to numerical noise. In that case,
loosening the threshold for point group identification (for example, with %sym SymThresh 0.01 end) should
lead to the expected point group and ORCA will use a symmetry-perfected geometry for the calculation. For more
information, see the section ORCA and Symmetry.
1.7.9. Using Old ORCA Inputs¶
If you try using an old ORCA input file with a newer version of ORCA, you may find that it does not run. Often when this is the case, there will be an error message issued during the startup of the calculation. This message should help you troubleshoot the issue.
Here, the issue typically arises due to keywords and defaults which may have changed from one version to another. In some cases, a keyword may have even been deprecated. When updating to a new version of ORCA, it is often helpful to refer to the Detailed change log, as many of these changes are noted.
If you are trying to read in a GBW file from another version of ORCA, you may find that you run into an error such as:
WARNING!!!!!!!
Your GBWFile is either corrupt or from a different ORCA version!
Please be VERY careful with your calculation results!!!
Data_size, sizeof( TOrcaInfo ): 974880, 980832
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! FATAL ERROR ENCOUNTERED !!!
!!! ----------------------- !!!
!!! I/O OPERATION FAILED !!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
This is especially common when using !MORead or when using ORCA utility
programs, such as orca_plot. In the case of reading in starting orbitals for a subsequent
calculation, the additional keyword !Rescue may help. Note that with this,
fewer checks are performed, so it is important to make sure that the GBW file represents
a system that is compatible with the current input file.
For the case of plotting orbitals and certain densities with orca_plot,
you can either use the same ORCA version as the one that produced the GBW file
or you can run a calculation with the newer ORCA version by using !Rescue MORead NoIter
in the input file (and reading in the GBW file via the %moinp keyword). This calculation
should not take long and the new GBW file produced should be readable by orca_plot. Note
that in this case, all other settings should be specified as they were for the calculation
that produced the older GBW file.
If you are unsure about an input, please first consult the relevant parts of this ORCA Manual. It is provided by the ORCA developers and should contain all information about the functionality implemented in this version of ORCA. It is also important to reference the ORCA Manual for the version of ORCA that you are using. If you are viewing this manual online and are not using the most recent release version of ORCA, please update your ORCA version or find the ORCA Manual for the version you are using. If you are still unable to get an input file to work, the ORCA Forum is a great place to turn to for getting answers to your questions!
1.7.10. Reproducing Results of Other Program Packages or Older ORCA Versions¶
Reproducibility of results is fundamental in science, so it is good practice to compare results when switching from one program to another or from one ORCA version to another. If you are trying to do this and observe deviations that are larger than expected, here are some hints and tips.
Newer versions of ORCA might include changes to the default settings, which may affect the numerics. For example, ORCA 6 has improvements to the numerical integration grids. In most cases, these changes should lead to better results and are most likely the reason for differences between the latest ORCA release and previous versions. It is usually possible to manually set these values to their old defaults for comparison purposes. For such an inspection, compare the information in the output to see which values have changed. Reference the relevant sections of this manual to determine how to change these values.
In trying to reproduce results from another program in ORCA (or vice versa), it is important to check that the methods being used are in fact equivalent and that both programs compute the value(s) in question in the same manner. This may mean using some settings that you would not otherwise use so that you can make sure that the two should be comparable. For example, ORCA uses pure d- and f-functions (i.e. 5 d-functions and 7 f-functions instead of the Cartesian 6 d-functions and 10 f-functions) for all basis sets, so this should be taken into account when comparing to programs that do not.
If you still run into issues with reproducibility, open a post in the ORCA Forum and give enough details on what is being compared so that other users and developers can be of assistance. It is often helpful to include the input(s) and/or output(s).
1.7.11. Orbitals Not Found¶
If you encounter this error:
No orbitals were found in the gbw file
it is most likely that you are trying to use !MORead to read in a GBW file with
the same basename as the current input file. This is done automatically with ORCA’s
AutoStart feature (on by default), so you should be able to simply remove the !MORead
and %moinp parts of the input file. If you want to save the previous orbitals (for
later access) and read them in, copy the GBW file to something with a different basename and then
read that file in as usual.
1.7.12. Trouble Restarting Input File¶
Another AutoStart issue is when you make a significant change to your input file and try to rerun it without deleting the old ORCA outputs. This often happens if there is a significant mismatch in the geometry—like when atoms have been reordered or removed. In this case, the error encountered is:
Error: Input geometry does not match current geometry
Typically, the basis set can be changed without issue, though, as ORCA will perform a projection of the old orbitals onto the new basis set if needed.
If there is an issue with restarting a file, you can always try to run the job
from scratch by adding !NoAutoStart to the input file or by deleting all other
files with the same basename as the input file before rerunning.
1.7.13. SCF Convergence Problems¶
A typical problem that occurs for systems with complex electronic structures
like transition metal complexes or systems with many orbitals in a narrow energy range
(such as metal clusters) is a poorly-converging SCF. While ORCA offers keywords
like !SlowConv, this might not be the best option. Specifically, !SlowConv may
converge to a local minimum solution that is closer to that of the initial guess.
We have compiled a list of tips and tricks in the section Converging SCF Calculations.
1.7.13.1. Example: Converging DFT for Open-Shell Transition Metals¶
Since DFT is frequently applied to open-shell transition metals, we show here a (more or less trivial) example of a Cu(II) complex treated with DFT:
*xyz -2 2
Cu 0 0 0
Cl 2.25 0 0
Cl -2.25 0 0
Cl 0 2.25 0
Cl 0 -2.25 0
*
%compound
NewStep
!BP86 SV SlowConv
StepEnd
ReadMOs(1);
NewStep
! B3LYP NoRI TZVP TightSCF
%scf GuessMode CMatrix end
StepEnd
EndRun
Although it would not have been necessary for this particular example, this shows a
possible approach to converging such calculations. We first perform a less
accurate (but quicker) job using the RI approximation, a GGA
functional, and a small basis set without polarization functions. Note
that a larger damping factor has been used in order to guide the
calculation (!SlowConv).
The second job takes the orbitals of the first as input and performs a more accurate
hybrid DFT calculation. A subtle point in this calculation on a dianion in the gas phase
is the input specification GuessMode CMatrix, which requests the use of the corresponding
orbital projection. This matches the orbitals of the smaller basis set calculation
to those of the larger basis set. This is always required when the orbital energies
of the small basis set calculation are positive, as will be the case for anions.
1.7.14. Troublesome Geometry Optimizations¶
While some issues during optimization jobs give errors that have been covered above, there are problems that may arise which do not produce error messages or terminate ORCA. In some cases, you may get a normal termination, but the results you obtain are not valid. One must often use chemical intuition to determine if the geometry optimization yields reasonable structures and frequencies.
1.7.14.1. Imaginary Frequencies after Optimization¶
If a geometry optimization terminates normally, the algorithm has decided that it is sufficiently close to a stationary point on the potential energy surface. To test whether this stationary point is a minimum, maximum, or transition state or to check how close the structure is to the stationary point, a frequency calculation must be run. This might yield imaginary frequencies (which arise due to negative force constants as the frequencies are proportional to the square root of them), which indicates that we are not at a minimum.
-----------------------
VIBRATIONAL FREQUENCIES
-----------------------
Scaling factor for frequencies = 1.000000000 (already applied!)
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: -5.66 cm**-1 ***imaginary mode***
7: 14.88 cm**-1
8: 21.54 cm**-1
There are several approaches to deal with this issue. Typically, using tighter optimization criteria, tighter DFT grids, and/or tighter SCF convergence criteria helps, especially for small imaginary frequencies. Another approach can be to identify the normal modes associated with imaginary frequencies, distort the molecule along these vectors, and re-optimize the structure. Note that the compound script Iterative optimization does this exact process in an automated fashion.
1.7.14.2. Getting Unwanted Local Minima¶
If the optimized geometry you are getting is not the one you were expecting, you may be running into a nearby local minimum on the potential energy surface. This is often encountered when optimizing a molecule that has many rotamers.
First, check that the input geometry you have provided is reasonably close to the conformation you are aiming for. It may help to preoptimize the structure with an inexpensive method. If aiming for the global minimum, one may make use of GOAT to preoptimize the structure to a reasonable guess for the global minimum.
If there is symmetry breaking during the optimization, but you would like to enforce the original point group, look at the options in Geometry optimizations using symmetry.
1.7.14.3. Issues with Optimization Convergence¶
There are a few options you have when the calculation simply does not meet the optimization convergence criteria by the set number of maximum iterations. Inspect the last single point geometry along the optimization trajectory. If it seems intuitively close to a stationary point, try to rerun the optimization from this geometry. This is equivalent to rerunning the original input file, but increasing the number of iterations in the optimization.
Another approach is to first optimize with a less expensive method and/or smaller basis set, then use that geometry for the optimization at the level of theory wanted. The optimization can also first be done with looser convergence thresholds before tightening them as needed.
If none of these tips help, one may identify parts of the structure that are giving issues by analyzing
the trajectory of the optimization. The optimization may have gotten stuck at the end in a region where
the potential energy surface is nearly flat or has many shallow minima—such as for structures with many rotamers
or for systems with multiple molecules. In that case, some reasonable geometry constraints may be needed.
It may also be wise to change the trust radius or the maximum step in internal coordinates. In some cases,
cartesian optimization via !COPT may even be needed.
For more details, see the section Geometry Optimizations, especially for the Geometry Optimization Keywords.
1.7.15. “Strange” Results for Energies and Properties¶
If results for energies or properties seem off, first make sure that the geometry, spin multiplicity, and charge used are reasonable for the system at hand. Make sure that the input is a good approximation of the real system you are trying to model. To this end, consider if a solvent model is appropriate. This is especially important for charged systems. For mean-field methods, also consider using a dispersion correction if not already included. If heavy elements are included in the system, scalar relativistic methods may be appropriate, and possibly picture change and finite nucleus corrections.
Next, make sure that the SCF has converged well. For properties and post-HF energies and properties, the SCF should be converged tightly enough that the subsequent calculations do not suffer from the numerical noise of the underlying SCF results. A loose convergence threshold will ultimately affect the properties that follow from the results of the SCF.
For unrestricted methods, it is advisable to look at the calculated spin contamination in the output. If this is significant, results for the given system with that method may be unreliable. One should be careful in the analysis of the output file in this case. In some cases, the underlying representation of the system is flawed or incomplete, but in other cases, you may consider turning to methods that give pure spin state solutions, such as ROHF, ROKS, or multireference methods.
In general when using single reference methods, one should question if the system may exhibit multireference character.
In such a regime, results from single reference methods may not be reliable. To help determine this, there are a couple
diagnositics that can be computed. When running a coupled cluster calculation, the \(T_1\) diagnostic is commonly used to
estimate the importance of static correlation in the description of the system. The computed value is printed when running
a coupled cluster calculation and if greater than 0.02, the system may have multireference character. More reliable is
the newer S-diagnostic, which can be requested by %mdci DoSDiagnostic true end. See the
Coupled Cluster S-Diagnostic section for more information.
When running a multireference calculation, it is important to make sure that the final active space is reasonable
and includes all important orbitals that contribute to the static correlation. This may require changes to nel and norb.
Good starting orbitals are important here (see the section on Choice of Inital Guess).
Starting orbitals may also be generated from other calculations—for example using MP2 natural orbitals or QROs from
UKS—which often represent a more physically relevant starting guess. AVAS is
helpful for building the active space from these starting guesses, provided that you can intuitively determine the
AOs that contribute to the MOs you want to include in the active space. Note that although an active space may seem
reasonable, there may be convergence issues in CASSCF or in the post-CASSCF calculations when some of the active orbitals
are very highly occupied/unoccupied. Finally, one should also consider if a state-specific or state-averaged solution is
most appropriate for the system. Keywords which may need to be changed here are nroots, mult, weights, and irrep.
Finally, it should be checked that the methods used are appropriate for the system at hand. For example, MP2—and CCSD(T) to a lesser extent—has issues with orbital degeneracies. For properties, linear response and sum-over-states results are only reliable for systems without low-lying excited states. If the system is outside of the regime where the requested method is reliable, another method should be considered.
If everything seems reasonable, but there still seems to be an issue, post the case in the ORCA Forum. It could be that there is a technical reason for the values to be how they are or there may be a bug that should be fixed.