dftd3 / simple-dftd3

reimplementation of the DFT-D3 program

Home Page:https://dftd3.readthedocs.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

pairwise analysis inconsistent in d3 forks

loriab opened this issue · comments

This is purely informative and for searchability; feel free to close right away.

I noticed in debugging sapt0-d3m in Psi4 that the pairwise analysis from classic dftd3 -anal and simple-dftd3 (at least the qcengine interface) differ by a factor of two. Below are the rms of the returned arrays (labels are <program>_<conda channel>), but I've checked the arrays per-element, too. s-dftd3 is closer to dftd4, so I'm assuming that it's classic dftd3 that's the inconsistent definition. Rather than perpetrating another variation in d3 versions out there, I'll compensate in Psi4.

rms(dftd3_psi4)    = 0.0008701284366337631
rms(dftd3_psi4 / 2)= 0.00043506421831688153
rms(sdftd3_cf)     = 0.00043506480394359256
rms(dftd4_psi4)    = 0.00015463675259706915
rms(dftd4_cf)      = 0.0001546367518179213

The pairwise dispersion energy must sum up to the total dispersion energy, if it does not I would consider this a bug. This behavior is enforced in s-dftd3 and dftd4:

call check(error, energy, sum(energy2) + sum(energy3), thr=thr)

Thanks. Yes, the list output of pairwise in classic dftd3 was misinterpreted in the harness when forming the full array. Fixed in MolSSI/QCEngine#385 at https://github.com/MolSSI/QCEngine/pull/385/files#diff-c2513a32098e0b14751980a1524320abc60b8cc1a883aacd76399e69949ebb0a

Seems to be resolved now.