UseSym Keyword in ORCA fails to find appropriate number of SALCs

Question

I am trying to run some geometry optimizations in ORCA 5.0.4 and I am using the UseSym keyword to ensure that my molecules retain C_s Symmetry during optimization. The molecule that returns the error:

         *************************************************************
         *                GEOMETRY OPTIMIZATION CYCLE   6            *
         *************************************************************
[file orca_tools/Tool-Symmetry/symmain.cpp, line 1318]: Error (ORCA_SYM): TMoleculeSymmetry::ConstructSALCs failed to find appropriate number of SALCs!

is 4-Fluoroimidazole. From what I understand (I am not good at C++), UseSym runs the script symmain.cpp and provides the initial xyz coordinates of my input file to the ConstructSALCs class of the TMoleculeSymmetry module.

If the provided, initial coordinates are not symmetrical (or well aligned) enough within a certain margin of error, then ORCA cannot find a small enough number of "Symmetry Adapted Linear Combinations" for the molecule and the following determination of the point group fails.

This would mean that my initial coordinates are poorly pre-optimized and need to be made more symmetrical in line with the C_s point group. But the analogous molecules of 4-Chloro-, 4-Bromo- and 4-Iodoimidazole work just fine. Could it be that because Fluorine is the smallest, that this somehow affects the margin of error of the SALC determination?

I have checked the initial coordinates of Fluorimidazole and it looks pretty planar to me :

Both of these are in orthographic projection.

Here's the input file:

# 4-Fluoroimidazol-1-ide
# FC1=C[N-]C=N1

# Use B3LYP
# Use Becke-Johnson Dampening
# Use 4 CPU cores
# Run an iterative geometry optimization job
# Make detailled output file
# Let ORCA choose auxilliary basis sets
! B3LYP D3 PAL4 Opt LARGEPRINT autoaux UseSym
%maxcore 1500 # Maximum memory in MB per core

%method 
    RI on # use the RI approximation
end

# Basis set specifications
%basis basis "aug-cc-pVDZ" # General spec: aug-cc-pVDZ 
    newGTO Zn "aug-cc-pVDZ-PP" end # except for Zn-atoms: aug-cc-pVDZ-PP
    newECP Zn "SDD" end # use Stuttgart-Dresden ECPs for Zinc
    newGTO Br "aug-cc-pVDZ-PP" end # except for Br: aug-cc-pVDZ-PP
    newECP Br "SDD" end # use Stuttgart-Dresden ECPs for Br
    newGTO I "aug-cc-pVDZ-PP" end # except for I: aug-cc-pVDZ-PP
    newECP I "SDD" end # use Stuttgart-Dresden ECPs for I
end

# Insert xyz coords
*xyz -1 1
F     -1.920669   -1.239155    0.561931
C     -0.775487   -0.574040    0.365338
C     -0.664744    0.708473   -0.109333
N      0.652798    1.017049   -0.164707
C      1.317493   -0.077197    0.274888
N      0.453454   -1.062887    0.604201
H     -1.457650    1.379842   -0.396591
H      2.394805   -0.152085    0.352006
*

What parameter can I toggle in ORCA to make the SALC determination less sensitive to distorted geometries? Is it another reason entirely?

EDIT: I forgot to be more explicit: The optimization ran fine for 5 cycles. It crashes on cycle number 6. Did it just randomly reach a geometry from which the SALCs algorithm fails and crashes the calculation? Do just need more RAM?

Answer 1

As you said, your initial geometry may be on the verge of satisfying and not satisfying the Cs symmetry under ORCA's default threshold. Also note that although the molecule should eventually reach planarity, the change of planarity is not necessarily monotonic. A geometry optimizer may well temporarily deteriorate the planarity of your molecule, before finally restoring it (though good geometry optimizers should not deteriorate the planarity by too much during the optimization if the converged geometry is indeed planar). Furthermore, the circumstances where UseSym fails may be essentially random, such that though it fails for your fluorine case, it does not necessarily imply anything special about fluorine, and may just be a coincidence. Think of the geometry optimizer as a fly in the room; it tries to find the food in the room (the converged structure), but before that it may accidentally exit through the window (program abort). Whether it finds the window before it finds the food is essentially random.

To solve the problem, there are two approaches that can be combined. Firstly, note that even the symmetry program fails for one geometry during the optimization, you will probably be able to continue the calculation successfully by running a new geometry optimization calculation from that geometry. This is because the program will try to deduce the point group again, and that point group will be suitable for the molecule at least at the first geometry optimization step. In your system, this means that if you re-run your calculation from your last structure, the point group will probably be identified as C1, and you will end up with a C1 structure. If you want a rigorously symmetrized Cs structure, just run a third optimization job on the final structure: now the point group will be re-identified as Cs, and since the structure has already converged, it should be extremely easy (within 2~3 steps, for example) to re-converge the structure under the Cs symmetry, giving a rigorously planar and fully converged geometry.

Secondly, the threshold for detecting the point group can be loosened, by adding something similar to this to the input file:

%sym symthresh 0.01 end

The default threshold is 0.0001. The larger the threshold is, the more likely it is for the program to identify approximately symmetric molecules as symmetric.