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 Cs 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 Cs 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 : 4-Fluoroimidazole, orthographic projection

4-Fluoroimidazole, orthographic projection

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

    RI on # use the RI approximation

# 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

# 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?


1 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.

  • 2
    $\begingroup$ A better idea may be to use a drawing software like webmo or macmolplt to force the molecule to Cs symmetry and then run the optimisation. $\endgroup$
    – S R Maiti
    Commented Oct 6, 2023 at 9:43
  • $\begingroup$ maybe I was't explicit enough (again). the output file does show in the point group determination step that the determined symmetry is indeed C_s. And it works for multiple iterations. Then it crashes with the given error message. It works fine for homologous molecules. Could I just restart the calculation, or is the algorithm 100 % deterministic? $\endgroup$
    – J.Doe
    Commented Oct 9, 2023 at 11:12
  • $\begingroup$ @J.Doe Generally, serial calculations that do not use a random number generator (which include your calculation) are deterministic. If you are running your calculation in parallel, then this will introduce some non-determinism on the order of machine precision (10^-15). Depending on the specific calculation, this non-determinism may or may not be magnified to a sufficient extent as to change the convergence behavior or even whether the calculation aborts. $\endgroup$
    – wzkchem5
    Commented Oct 10, 2023 at 8:34
  • 1
    $\begingroup$ I think you need to remove the typo in "symthesh" before I can accept your answer. It's "symthresh". ORCA manual for 5.0.4 says %sym SymThresh 5.0e-2 end in it's explanation of the command. $\endgroup$
    – J.Doe
    Commented Oct 10, 2023 at 8:53
  • $\begingroup$ @J.Doe fixed, thanks $\endgroup$
    – wzkchem5
    Commented Oct 11, 2023 at 8:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .