There was a bug from commit abd3b02 and earlier in release v1.0.0 where on-ECP type two integrals were screened based on orthogonality between the spherical harmonics on the ECP and the GaussianShell; see from
|
if (data.A_on_ecp && data.B_on_ecp) { |
onwards.
This works if the Gaussians are themselves spherical, but results in incorrect Cartesian contributions on the diagonals (e.g. xx, yy, zz for L=2).
I have patched this out in 59ab088 but this results in a slowdown by up to 50% for on-ECP integrals. While this typically represents a very small fraction of the overall number of integrals, it would be worth writing a new Radial::Type2 routine for this special case, so that off-diagonal Cartesian entries can still be ignored.
There was a bug from commit abd3b02 and earlier in release v1.0.0 where on-ECP type two integrals were screened based on orthogonality between the spherical harmonics on the ECP and the GaussianShell; see from
libecpint/src/lib/ecpint.cpp
Line 384 in abd3b02
This works if the Gaussians are themselves spherical, but results in incorrect Cartesian contributions on the diagonals (e.g. xx, yy, zz for L=2).
I have patched this out in 59ab088 but this results in a slowdown by up to 50% for on-ECP integrals. While this typically represents a very small fraction of the overall number of integrals, it would be worth writing a new Radial::Type2 routine for this special case, so that off-diagonal Cartesian entries can still be ignored.