Inconsistent energy correction between executable, Python API, and VASP

[Andrew-S-Rosen]

I am getting some inconsistent energy corrections depending on how I fetch them. @tgmaxson, this looks far less notable than in https://github.com/dftd3/simple-dftd3/issues/68 but tagging in case you have some wisdom to share.

With s-dftd3 1.2.1:

s-dftd3 CONTCAR --bj pbe

returns -2.0077614201867E-01 Eh or -5.463397149451446 eV (-5.463397104953209 eV with CODATA 2014, the ASE default).

from ase.io import read
from dftd3.ase import DFTD3

atoms = read("CONTCAR")
atoms.calc = DFTD3(method="PBE", damping="d3bj")
e = atoms.get_potential_energy()
print(e)

returns -5.456782359427048. This difference of ~0.0066 eV is not resolved by setting alp=14.0 in light of https://github.com/dftd3/simple-dftd3/issues/150.

In VASP 6.5.1, it is using DFTD3 V3.0 Rev 1 and returning -5.46486 eV, which is closer to s-dtd3 but still different by 0.0015 eV.

CONTCAR.txt

OUTCAR.txt

[tgmaxson]

If I recall correctly with our original testing, VASP and this package may give slightly different values since the PBE parameter values are hard coded into VASP. It might be good to somehow verify they both use the same parameterization beyond just the simple PBE-D3(BJ).

For MLIPs, our solution was to always generate D3 using simple-dftd3 (or another d3 package) and keep the VASP as solely PBE.

[Andrew-S-Rosen]

@tgmaxson, thanks for the comment!

I can confirm that VASP is using the same s6, s8, a1, and a2 parameters as in s-dftd3, which are reproduced below:

https://github.com/dftd3/simple-dftd3/blob/442fbec1b0cf249359358ed247d90731d4da4b37/assets/parameters.toml#L48

There are also some other parameters reported in the OUTCAR, and I don't know what those are, so maybe those are different.

         DFTD3 V3.0 Rev 1
 DF pbe
 parameters
 k1-k3        =   16.0000    1.3333   -4.0000
 Edisp (eV)   -5.46486

 E6    (eV) :    -3.7180
 E8    (eV) :    -1.7468

The difference between the s-dftd3 and the ASE-based API is a fair bit larger, so there must be something else going on there.

For MLIPs, our solution was to always generate D3 using simple-dftd3 (or another d3 package) and keep the VASP as solely PBE.

Good suggestion. I agree.

[awvwgk]

Can you verify that the cutoff values used in VASP are matching the ones used in here? I am adding a feature in #154 to expose the cutoff values in the ASE calculator. In the Python API those can already be changed using set_realspace_cutoff method.

[Andrew-S-Rosen]

@awvwgk, thanks! That looks like the potential culprit.

VDW_RADIUS=50.0 VDW_CNRADIUS=21.167

I believe both of these numbers are different (lower) than s-dftd3.