5
$\begingroup$

I have made a bunch of calculations in ORCA to compare them to results from this paper. The original calculations from this paper were done in TurboMole. I tried to recreate the method as best I could using ORCA, but it seems that there is something in my calcs that does not match up to the method used by Rochus et al., since my energies seem to be consistently ~3 kJ/mol higher than those done by Rochus.

Here are the energies done by me and those done by Rochus: Rochus original calculations

And here are mine done with ORCA: My new calcs in ORCA

My suspicion is that the integration grid ("m5" in Turbomole) might be the reason for this deviation. There is no direct equivalent to the m5 grid in ORCA, from what I could find. Perhaps this m5 grid is just finer than the one I used in ORCA.

To test this theory, I wanted to, optimally, calculate the SCF energies again using a finer grid in ORCA, without rerunning the entire series of calculations. Is it possible to "reintegrate" ORCA results without doing the whole calculation all over again?

$\endgroup$

2 Answers 2

6
$\begingroup$

The standard solution is to run a new ORCA calculation with a larger grid, and read your current wavefunction (from the GBW files that you got) as initial guess:

! (level of theory etc...)
! DefGrid3 (if you are using ORCA 4.x, use something like Grid6 instead)
! MORead
%moinp "old_calculation.gbw"

This performs the SCF using the large grid until convergence, which may take a few cycles, hopefully no more than 10.

If you want to "reintegrate" the XC energy without changing the wavefunction, you can set the number of SCF cycles to 1 via:

%scf
maxiter 1
end

Or alternatively, set the SCF convergence threshold to extremely loose values. This way the calculation is much faster. It still wastes some time on evaluating the Coulomb and exact exchange contributions, but the evaluation happens only once (or maybe twice?) per calculation, and AFAIK it's impossible to avoid.

However, XC integration error is probably not the dominant reason for the discrepancy. Since XC integration is usually not the rate-limiting step of a SCF single point calculation, in most programs the default grid is large enough so that the SCF energy error is negligible. You can also see this from the integrated number of electrons, printed after the SCF section of the ORCA output file, which is usually on the same order of magnitude as the error of the XC energy. Usually it is only necessary to increase the grid during e.g. geometry optimization (where small numerical noise may prevent convergence), frequency analysis (where small numerical noise can turn a small real frequency into an imaginary one), and the calculation of certain properties that involve the wavefunction near nuclei (EPR hyperfine couplings, Mössbauer spectroscopy, etc.).

The following differences of the ORCA and Turbomole default settings may have greater contributions to the observed energy discrepancies than the grid differences:

  1. For hybrid functionals, ORCA (except for older versions) uses the RIJCOSX approximation by default (that is, RI for the Coulomb term and COSX for the exchange term), while Turbomole by default evaluates the Coulomb term by RI but the exchange term exactly. To reproduce the latter behavior, one should use the keyword "! RIJONX" in the ORCA input file. Turbomole also supports COSX, but it is called SENEX in Turbomole terminology and is turned off by default.
  2. The default RI auxiliary basis set of Turbomole is different for every orbital basis set, but the default auxiliary basis set of ORCA is mostly independent of the orbital basis set (def2/J for non-relativistic and ECP calculations, SARC/J for scalar relativistic calculations, with very few exceptions). Therefore, the RI auxiliary basis set that you used is probably different from the one used in Turbomole. In particular, the def2/J auxiliary basis set is designed for the def2 series of basis sets, and may or may not be suitable for aug-cc-pVDZ and aug-cc-pVDZ-PP.
$\endgroup$
2
  • $\begingroup$ So if I understand correctly, the geometry optimization and the wavefunction optimization are two separate processes and the above calculation will leave the geometry unaffected and only do multiple iterations to "optimize the wavefunction"? Isn't the geometry optimization usually the part that takes up like 90 % of the time? $\endgroup$
    – J.Doe
    Commented Nov 22, 2023 at 10:45
  • $\begingroup$ The geometry optimization is composed of many SCF calculations and SCF gradient calculations, and a SCF calculation is composed of many SCF iterations. So after you increase the grid, you have a few options: (1) do geometry optimization until convergence; (2) do one geometry optimization iteration; (3) only do the SCF part of one geometry optimization, but do the SCF to convergence; (4) only do the SCF part of one geometry optimization, and only do one SCF iteration for that SCF calculation. I assumed that you wanted either (3) and (4), but I may be wrong. $\endgroup$
    – wzkchem5
    Commented Nov 22, 2023 at 16:54
5
$\begingroup$

We have discussed the reproducibility of DFT calculations recently in J. Chem. Phys. 159, 114116 (2023). The calculations in J. Am. Chem. Soc. 145, 9273–9284 (2023) were carried out with the B3LYP functional in Turbomole, which does not match the B3LYP functional as published by Stephens et al in 1994, who used the RPA variant of the VWN correlation functional instead of the recommended version by VWN. I am not sure which variant ORCA implements, but it is entirely possible that the difference you see in absolute energies is caused by the discrepancy of the density functionals.

$\endgroup$
2
  • $\begingroup$ This is true. I think I have seen there are two version of B3LYP in Turbomole 7.x. One is B3LYP and another one is B3LYP (Gaussian). $\endgroup$
    – Pro
    Commented Nov 27, 2023 at 13:05
  • 1
    $\begingroup$ Orca has two versions as well: B3LYP (which should match Turbomole) and B3LYP/G (which should match Gaussian). sites.google.com/site/orcainputlibrary/… - not sure this is the reason $\endgroup$ Commented Nov 28, 2023 at 16:03

You must log in to answer this question.

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