ORCA crashes because of RI approximation?

Question

I am doing a geometry optimization for a cationic imidazolate-zinc complex.

I'm trying to run an optimization using this input file. It uses the RI approximation.

ORCA seems to be running fine until it hits the RI-J gradient calculation. Then it tells me:

Nuc. rep. gradient (SHARK) ... done ( 0.0 sec) HCore & Overlap gradient (SHARK) ... done ( 0.0 sec) ECP gradient (SHARK) ... done ( 0.3 sec) RI-J gradient (SHARK) ... ORCA finished by error termination in SCF gradient Calling Command: mpirun -np 4 /usr/local/orca_5.0.4/orca_scfgrad_mpi 00000032.scfgrad.inp 00000032 [file orca_tools/qcmsg.cpp, line 465]: .... aborting the run

The full output of the run can be found here.

I took out RI on from my input file, but the result is the same. Can anyone tell me what is happening?

Here's the inp file itself:

# (5-Fluoro-1H-imidazol-1-yl)zinc(II)
# Use B3LYP
# Use Becke-Johnson Dampening
# Use 4 CPU cores
# Run an iterative geometry optimization job
! B3LYP D3 PAL4 Opt 

%maxcore 5000 # Maximum memory in MB

%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
end

# Insert xyz coords
*xyz 1 1
Zn    -2.309328    1.771441    0.119755
N     -0.629170    0.310125    0.024646
C      0.513781    0.759697    0.026619
F      1.098001    1.986981    0.073661
C      1.289471   -0.447587   -0.041851
N      0.375729   -1.468533   -0.073964
C     -0.899807   -0.885708   -0.026106
H      2.354732   -0.504006   -0.061957
H     -1.793410   -1.522410   -0.040803
*

EDIT: Just found this in the docs:

"If you use RI you must specify an auxiliary basis set in the %basis section. Do not rely on the program to make an automatic choice for you."

Does this mean I need to pick an auxilliary basis set and specify it? How do I do that? Which one should I use?

EDIT: Question was answered, so I'm posting the full, working input file here.

# (4-Fluoro-1H-imidazol-1-yl)zinc(II)
# 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
%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
end

# Insert xyz coords
*xyz 1 1
Zn    -2.417420    1.345162   -0.167542
N     -0.805569    0.350705   -0.050917
C      0.425351    0.844144   -0.025052
C      1.287091   -0.231633    0.064757
F      2.634022   -0.243334    0.120886
N      0.504401   -1.345529    0.088678
C     -0.772569   -0.972550    0.017208
H      0.754077    1.892994   -0.064409
H     -1.609384   -1.639958    0.016391
*

PS: I ran into issues with other input files, where Iodine exists in an isosteric molecule (switch out F for I, essentially). So I need to use the aug-cc-pVDZ-PP basis set not just for Zn, but also for I, since aug-cc-pVDZ is not defined for elements after Krypton.

Answer 1

What the doc wants to say is that the program may make an automatic choice of the auxiliary basis set (typically def2/J for non-relativistic calculations and SARC/J for relativistic ones, if I'm not mistaken), but in some (not all) cases they may not be suited for your basis set. It is well-established that def2/J is suitable for basis sets that begin with def2 (at least when they do not carry diffuse functions; for def2 basis sets with diffuse functions, e.g. ma-def2-TZVP and def2-TZVPD, there seems to be some debate on whether def2/J is suitable for them), and SARC/J is suitable for all-electron relativistic basis sets for ZORA or DKH (again, at least when they do not carry diffuse functions). In other cases, and especially when the basis set has a different number of core electrons than the respective def2 basis sets (e.g. the aug-cc-pVDZ-PP basis set that you used, which has less core electrons than e.g. def2-SVP), the default def2/J auxiliary basis set may not be suitable.

To find a suitable auxiliary basis set, first look at the basis set list in the ORCA manual (somewhere near the beginning of the "Choice of Basis Set" subsection in the "Detailed Documentation" section), and see whether there are auxiliary basis sets that suit your orbital basis set, as suggested by the names of the auxiliary basis sets. For RI-DFT calculations, you should use basis sets that end with "/J". When in doubt, refer to the original references of the auxiliary basis sets to see if they are indeed designed to work with your orbital basis set.

To use the auxiliary basis set, either type its name in the line that begins with "!", e.g.

! B3LYP def2-SVP def2/J

or use the "NewAuxJGTO" keyword in the %basis block:

%basis
  NewGTO Pt "SARC-ZORA-TZVP" end
  NewAuxJGTO Pt "SARC/J" end
end

If you cannot find a suitable auxiliary basis set, you may search for such a basis set on Basis Set Exchange (BSE), and enter the definitions of the basis set into the ORCA input file (the manual contains examples of how to do this, I'll not reproduce them here).

If even the BSE does not contain a suitable basis set, you may use the AutoAux functionality of ORCA to automatically generate an auxiliary basis set. Simply add the AutoAux keyword in the line that begins with "!":

! B2PLYP aug-cc-pVTZ autoaux

or in the %basis block:

%basis
  NewGTO Pt "cc-pVTZ-PP" end
  NewAuxJGTO Pt "autoaux" end
end

The auxiliary basis sets generated by AutoAux are essentially always suitable for the orbital basis set that you specified (EDIT: as Susi Lehtola correctly pointed out, for double-zeta basis sets, and in some (but not all) cases, AutoAux gives inferior accuracy than hand-tuned basis sets. See, e.g. Table 5 of the AutoAux paper). However, they are usually larger than necessary (because they are not fine-tuned as e.g. the def2/J and SARC/J basis sets are) and are more prone to basis set linear dependency problems.