wB97X-D4BJ missing D4 gradients?

Hi there,

I just ran some calculation with the latest 1.7 (Git: Rev {HEAD} 6ce35a5) release (great work by the way), and it seems that something like

grad, wfn = gradient(‘wB97X-D4BJ/def2-TZVP’, return_wfn=True, dertype=‘gradient’)

does not return a proper DFT + D4 gradient (only DFT).

However,

grad, wfn = gradient(‘wB97X-D3BJ/def2-TZVP’, return_wfn=True, dertype=‘gradient’)

is doing so.

Best,

Udo

Please post the results of conda list, so we know which program you’re using to get the dispersion correction. The logic involving dispersion programs changed towards the end of the 1.7 development cycle, and this bug is likely a consequence of that…

I am using the latest 1.7 psi4conda install:

A quick guess from my side: maybe it is just a unit conversion issue relevant for the gradient only … ?

packages in environment at /home/udo/psi4conda:

Name Version Build Channel

_libgcc_mutex 0.1 main
_openmp_mutex 5.1 1_gnu
ambit 0.6 py39h53dec33_2 psi4
attrs 22.1.0 py39h06a4308_0
blas 1.0 mkl
brotlipy 0.7.0 py39h27cfd23_1003
ca-certificates 2022.10.11 h06a4308_0
certifi 2022.12.7 py39h06a4308_0
cffi 1.15.1 py39h5eee18b_3
charset-normalizer 2.0.4 pyhd3eb1b0_0
chemps2 1.8.11 hbe8a562_0 psi4
conda 22.11.1 py39h06a4308_4
conda-package-handling 1.9.0 py39h5eee18b_1
cryptography 38.0.1 py39h9ce1e76_0
dftd3 3.2.1 h84218bc_2 psi4
dftd4 v3.3.0 py39h758d17c_2 psi4
dkh 1.2 h173d85e_2 psi4
flit-core 3.6.0 pyhd3eb1b0_0
fockci 0.2.0 pyh681c21d_0 psi4
gau2grid 2.0.7 hd18ef5c_0 psi4
gcp 2.0.2 he991be0_2 psi4
gdma 2.2.6 h0e1e685_6 psi4
hdf5 1.10.6 hb1b8bf9_0
idna 3.4 py39h06a4308_0
importlib-metadata 4.11.3 py39h06a4308_0
importlib_metadata 4.11.3 hd3eb1b0_0
importlib_resources 5.2.0 pyhd3eb1b0_1
iniconfig 1.1.1 pyhd3eb1b0_0
intel-openmp 2021.4.0 h06a4308_3561
ld_impl_linux-64 2.38 h1181459_1
libecpint 1.0.7 hfebba4c_0 psi4
libefp 1.5.0 h117b10a_4 psi4
libffi 3.4.2 h6a678d5_6
libgcc-ng 11.2.0 h1234567_1
libgfortran-ng 7.5.0 ha8ba4b0_17
libgfortran4 7.5.0 ha8ba4b0_17
libgomp 11.2.0 h1234567_1
libint2 2.7.1 h2fe1556_15 psi4
libstdcxx-ng 11.2.0 h1234567_1
libxc 5.2.3 hfebba4c_0 psi4
mkl 2021.4.0 h06a4308_640
mkl-service 2.4.0 py39h7f8727e_0
mkl_fft 1.3.1 py39hd3c417c_0
mkl_random 1.2.2 py39h51133e4_0
mp2d 1.1.0 hfd86e86_0 psi4
msgpack-python 1.0.3 py39hd09550d_0
ncurses 6.3 h5eee18b_3
networkx 2.8.4 py39h06a4308_0
numpy 1.21.5 py39h6c91a56_3
numpy-base 1.21.5 py39ha15fc14_3
openssl 1.1.1s h7f8727e_0
optking 0.2.1 pyhbc12335_1 psi4
packaging 21.3 pyhd3eb1b0_0
pcmsolver 1.2.1.1 py39h92d4acf_3 psi4
pint 0.17 pyhd8ed1ab_0 psi4
pip 22.3.1 py39h06a4308_0
pluggy 1.0.0 py39h06a4308_1
psi4 1.7+6ce35a5 py39hb8090b1_1 psi4
psi4-rt 1.7 py39hf2a028a_0 psi4
psutil 5.9.0 py39h5eee18b_0
py 1.11.0 pyhd3eb1b0_0
py-cpuinfo 8.0.0 pyhd3eb1b0_1
pycosat 0.6.4 py39h5eee18b_0
pycparser 2.21 pyhd3eb1b0_0
pydantic 1.10.2 py39h5eee18b_0
pylibefp 0.6.1+cfbbac8 py39h4467fa1_4 psi4
pyopenssl 22.0.0 pyhd3eb1b0_0
pyparsing 3.0.9 py39h06a4308_0
pysocks 1.7.1 py39h06a4308_0
pytest 7.1.2 py39h06a4308_0
python 3.9.15 h7a1cb2a_2
pyyaml 6.0 py39h5eee18b_1
qcelemental 0.25.1 pyhd8ed1ab_1 psi4
qcengine 0.26.0 pyhd8ed1ab_0 psi4
readline 8.2 h5eee18b_0
requests 2.28.1 py39h06a4308_0
resp 1.0 pyh31278eb_0 psi4
ruamel.yaml 0.17.21 py39h5eee18b_0
ruamel.yaml.clib 0.2.6 py39h5eee18b_1
scipy 1.7.1 py39h292c36d_2
setuptools 65.5.0 py39h06a4308_0
simint 0.7 h642920c_1 psi4
six 1.16.0 pyhd3eb1b0_1
snsmp2 1.0.4 pyh0d22f2f_1 psi4
sqlite 3.40.0 h5082296_0
tk 8.6.12 h1ccaba5_0
toml 0.10.2 pyhd3eb1b0_0
tomli 2.0.1 py39h06a4308_0
toolz 0.12.0 py39h06a4308_0
tqdm 4.64.1 py39h06a4308_0
typing-extensions 4.4.0 py39h06a4308_0
typing_extensions 4.4.0 py39h06a4308_0
tzdata 2022g h04d1e81_0
urllib3 1.26.13 py39h06a4308_0
v2rdm_casscf 0.9 py39h04109d6_13 psi4
wheel 0.37.1 pyhd3eb1b0_0
xz 5.2.8 h5eee18b_0
yaml 0.2.5 h7b6447c_0
zipp 3.8.0 py39h06a4308_0
zlib 1.2.13 h5eee18b_0

@loriab, I think this one is for you.

There are, to my knowledge, at least 2 versions for wB97X-D4. One for the original wB97X plus added D4 and one where the V in wB97X-V is replaced by D4. Which one was your target?

The one that gives a lower overall error on the GMTKN55 data set, which in my understanding is the latter. Like the “wB97X-D3BJ” definition in psi4 , that returns

wB97X-V - vdW_DFT + D3BJ

So to be consistent with that definition, one might assume that “wB97X-D4BJ” is doing the same computation with D3BJ replaced by D4BJ?

Unfortunately psi4 automatically combines the old wB97X with added D4. Grimme made parameters for it. I added Goerigk’s -D3 versions for the (w)B97X/M-V functionals manually but not yet the -D4 variants. It requires manually definition like so:

You can add the functional dictionary directly into the input file: DFT: Density Functional Theory

Btw, I could not reproduce your error with my development version.

# molecule name is "s4di" in this example
gradD4, wfn1 = gradient('wB97X-D4BJ', return_wfn=True, dertype='gradient',molecule=s4di)
grad, wfn2 = gradient('wB97X', return_wfn=True, dertype='gradient',molecule=s4di)
E, G = s4di.run_dftd4('wB97X', 'd4bj')
d_grad=grad.np-gradD4.np
compare_values(-G, d_grad, 8, 'D4 grad test1')

Thanks a lot for the working resolution provided.

To put things into a somewhat broader perspective:

Our statistical analysis revealed, that ORCA:wB97X-D4, ORCA:wB97X-D3BJ and PSI4:wB97X-D3BJ all give very similar results for the gradient vectors, but PSI4:wB97X-D4 does not, so the latter gradient vector is always a clear outlier in the overall set. The source of this is now sufficiently explained with the above comments.

I also assume from the above that ORCA has implemented some kind of consistent D4 model in combination with wB97X-V that can be directly used (and trusted), even if there is no published version by Grimme yet.

For current users, that do not perform (or do not want to perform) quantitative inter-QC-code comparison and just simply type the respective keywords the discussed inconsistency might be a source of systematic error in their results.

Afaik, Goerigk is ORCA developer and put his D3/D4 versions into ORCA first. So that’s the reference for those functionals. We are catching up with the implementations.

I am not sure how ORCA implements D4 but i do expect it links Grimme’s code with a library rather than a re-implementation. That should agree with what we do (using a python API to the library).

That 2 different functional names have different parameters of the functional and/or dispersion correction is not the first time :frowning:
Not sure what the solution on psi4’s side could be. Goerigk’s version is preferred i think and will get into psi4.

Thanks again for the additional information.

I see your point of certainly having some ambiguity here with respect to the proper naming/selection of the DFT functional and the corresponding D3/D4 dispersion model. :weary: