Scaled opposite spin (SOS) not changing orbital-optimized MP2 (OMP2)

Hi all,

I’ve come across an issue with SOS-OMP2 (scaled opposite spin orbital optimized MP2) as implemented in PSI4.

In a single point calculation, I get identical energies (OMP2 total energy, scaled_SS energy, scaled_OS energy, SOS-OMP2 total energy, etc) using OMP2 as when I use SOS-OMP2. This is problematic, as the different scaling of the energy terms should be lead to PSI4 rotating the orbitals differently.

I couldn’t locate the source code for SOS-OMP2 to check whether it was a complete implementation (affecting density) or just a final scaling factor of the energy after performing OMP2 (certainly looks to be the case, even though do_sos is set to true).

I know it’s a rather niche method, but has anyone come across this, or any devs know how it’s implemented?

Thanks,
Ben

Hi. This sounds concerning.
First the basics: which psi4 version? Could you post the input (at least the methods part)?

The code is located in the the occ and dfocc modules/directories.

Hi Hokru,

Version is 1.3.2, and below is the input file.

memory 60 GB

molecule complex {
0 1
symmetry c1
C           -0.000000001327     0.000000002742    -0.566371032553
N            0.000000001055    -0.000000003205     0.602350938174
H            0.000000001134     0.000000011879    -1.625592062977
}


set {
    reference RHF
    e_convergence 1e-8
    d_convergence 5e-9
    basis aug-cc-pvtz
    do_sos true
    mp2_type conv
}

energy('sos-omp2')

Thanks,
Ben

do_sos true merely sets the values of the current energy and current correlation energy variables to the spin-component scaled values. This has no impact on the orbital optimization whatsoever. Psi4 version is irrelevant. (Use grep -inr "do_sos" . in occ if you want to check for yourself.)

The prospects for getting orbital optimized SOS-MP2 with conventional integrals are grim. The method is fairly easy, but the developer who wrote the code has lost interest in developments with the conventional integral code, and the code is so exceedingly difficult to work with that no other developers are likely to touch it.

I can confirm. Identical output for omp2, sos-omp2, scs-omp2
I opened an issue about it on github: https://github.com/psi4/psi4/issues/1751

A post was split to a new topic: How expensive/accurate is OMP2?