dftd3 / simple-dftd3 Goto Github PK

mstore's executables also aren't used.
Is this an unnecessary check in cmake?

This is probably a cmake question, but I have no idea how to do it.

I'm trying to compile simple-dftd3 with cmake and ninja in a computer that doesn't allow connections to the outside world. Therefore, I've had to copy the sources of mctc-lib and compile them myself. I have already compiled mctc-lib, and trying to compile simple-dftd3 tells me that it can not find mctc-lib because of missing mctc-lib_DIR:

How can I specify mctc-lib_DIR?

Thanks!

Add support for optimized power damping scheme as proposed in https://pubs.acs.org/doi/10.1021/acs.jctc.7b00176.

Potential issues

• only twelve functionals are parametrized
• for four of the functionals the power parameter is 6 and the damping equivalent with rational damping

They both have current changes, but this one has a higher latest version.

See also: https://gitlab.kitware.com/cmake/cmake/-/issues/25426

OMP vector reduction(s) in ncoord.f90 ncoord_dexp() causes a seg fault for larger problems.
s-dftd2 0.5.1 tested via DFTB+ main (input in https://gist.github.com/bhourahine/50fe58099d434919a452390ae6694259 ).

Hi 😄

I'm experiencing result disaccordance between binary s-dftd3 and result from python API dftd3.interface, at least for D3-BJ with PBE0.

Results run on my computer are:

Difference between python (prebuild param) and other results is somehow large. Difference between s-dftd3 and python (user param) may be a result of different Angstrom->Bohr conversion constant, which is not important.

I'm not acustomed to ffi workflow, thus I havn't hacked why this happens 🥲

Steps to reproduce python (prebuild param) and python (user param)

To reproduce python (prebuild param), I shamelessly borrow the code from test code of simple-dftd3 😂
https://github.com/awvwgk/simple-dftd3/blob/4c6c7825ba25288d62047a1ecf8edaccecd7061a/python/dftd3/test_interface.py#L179-L204

To reproduce result of python (user param), substiuting RationalDampingParam(method="pbe0") by RationalDampingParam(s6=1, s8=1.2177, s9=0, a1=0.4145, a2=4.8593, alp=14) should work.

Steps to reproduce original dftd3 and simple s-dftd3

Coordinate file is defined as tm.xyz:

16
tm.xyz
H   1.47785865  2.02673935 -1.47792345
H  -0.75909124  0.22976202  2.93087098
C  -1.72653772 -1.3263511  -0.82885635
B   1.13534314 -0.46989888 -1.18849251
H  -2.27669551 -2.08300829 -0.2589304
P   0.03232026 -2.02393313 -1.17653739
O   0.21785459  0.30748145  2.94674769
Cl  2.33559684  2.07710454  1.36507466
Al  0.70755099  0.7418772   1.04528377
P   1.63167935  0.91293665 -2.34248821
B  -1.59995106  0.02348594 -0.14624446
H   0.59007699 -0.5165691   3.30980685
F   0.32776684  1.15309591 -3.28767134
P  -1.41550502  1.58846245  0.55584146
H  -2.18646012 -1.23947453 -1.82225432
P   1.50819301 -1.40171049  0.375773

Then run

$ s-dftd3 run --bj pbe0 tm.xyz
$ dftd3 tm.xyz -bj -func pbe0

I'm new to dftd3/4, so hope these scripts are the correct D3-BJ with PBE0 🥲

Hi!

Is there a way (maybe by setting an environment variable) to parallelise the evaluation of the dispersion when using the python-API (via the ASE calculator) ?

I'm compiling this project with python interface enabled by

meson setup _build -Dpython=true 
meson configure _build --prefix=/home/wsr/s-dftd3
meson install -C _build

The compilation is ok, but I got an error when import dftd3.pyscf

Traceback (most recent call last):
  File "/home/wsr/s-dftd3/lib/python3.10/site-packages/dftd3/library.py", line 25, in <module>
    from ._libdftd3 import ffi, lib
ModuleNotFoundError: No module named 'dftd3._libdftd3'

I check the location of _libdftd3 and find it's in lib64, so the library.py in lib cannot import it

wsr@yoga:~/simple-dftd3> ls ~/s-dftd3/lib64/python3.10/site-packages/dftd3/
_libdftd3.cpython-310-x86_64-linux-gnu.so
wsr@yoga:~/simple-dftd3> ls ~/s-dftd3/lib/python3.10/site-packages/dftd3/
ase.py       interface.py  parameters.py  pyscf.py     test_ase.py        test_library.py     test_pyscf.py
__init__.py  library.py    __pycache__    qcschema.py  test_interface.py  test_parameters.py  test_qcschema.py

Can this be fixed by some meson setting? I've tried change meson configure _build --prefix=/home/wsr/s-dftd3 to meson configure _build --prefix=/home/wsr/s-dftd3 --libdir=lib, but it doesn't work.
Or, can we change the way importing _libdftd3 so that its location does not matter?

Would it be possible to set the default (2-body) cutoff to 94.8683 a.u. as in the reference implementation as opposed to 60 a.u. right now?

The parameters file for dftd3 has three-body scaling all defaulting to s9=0.0 or off, https://github.com/dftd3/simple-dftd3/blob/main/assets/parameters.toml#L5-L9 , and that's what gets returned from a get_all_damping_params call. But the docs and interface file show the three-body as s9=1.0 or on, https://github.com/dftd3/simple-dftd3/blob/main/python/dftd3/qcschema.py#L50 , and on is what gets computed in a qcschema run without param_tweaks being specified.

Is this an inconsistency, or am I missing something? In switching over psi4, I was prepared for three-body on, then pleasantly surprised (for consistency's sake with "classic" executable dftd3) to find it off, and now uncertain. I can make it work psi4-side either way, but I thought I'd check in for guidance. Thanks!

Currently Python wheels are only built for Linux using mesonpep517, since the conda-forge distribution already covers MacOS and Windows this seems like only minor issue. However, if there is sufficient interest and/or somebody is willing to contribute the respective additions to the wheel building workflow the distribution can be expanded.

Preferably we can also build Python wheels for MacOS and Windows against the conda-forge API like done in the Linux case.

Cannot find ninja when running meson from mesonpy build backend.

This projects seems stable enough to leave the 0.x version series. This issue tracks whether there is anything that should be done prior to making the first release in the 1.x version series.

In the GMTKN55 study zero damping parameters for several functionals were published which are currently not available automatically in this implementation. For details see https://doi.org/10.1039/C7CP04913G and the supporting information for the full list (https://www.rsc.org/suppdata/c7/cp/c7cp04913g/c7cp04913g1.pdf in table S4).

Recently, I'm using simple DFT-D3 and VASP with ASE interface because some DFT-D3 parameters are not set as default in VASP. Here is part of my script:

from dftd3.ase import DFTD3
from ase.calculators.vasp import Vasp
from ase.calculators.mixing import SumCalculator
from ase.io import read, write
from ase.optimize import LBFGS, BFGS, GPMin

atoms = read('CONTCAR')
d3 = DFTD3(method='PBE', damping='d3bj')   
vasp_pbe.set(label='PBE', directory='PBE', xc='PBE') # check whether the energy is consistent with the default one in VASP
vasp_pbe_d3 = SumCalculator([d3, vasp_pbe])
del atoms.constraints
atoms.set_calculator(vasp_pbe_d3)
dyn=LBFGS(atoms)    #优化器
dyn.run(fmax=0.03)

To verify the scheme, I used CO adsorption energy as a criterion and compared the difference between simple DFT-D3 and default one in VASP. I found that the absolute energy for a specific structure is different, while the targeted adsorption energy is quite close.

However, I'm still worried about the reliability of such a scheme and do you have any suggestions?

Currently, only 3D periodic boundary conditions are support. To support 2D or 1D periodic boundary conditions the lattice point generation has to be adjusted to account for those cases (all other code is boundary condition agnostic):

https://github.com/awvwgk/simple-dftd3/blob/6393e1ec9102b7604991cf285852b2f8cbf80e56/src/dftd3/cutoff.f90#L53-L78

The dispersion energy is currently only added to the nuclear repulsion, however PySCF provides with the scf_summary dictionary in the mf object a way to record the individual contributions. It would be useful for if the PySCF wrapper could record the dispersion energy in scf_summary["dispersion"].

I'm trying to implement B97-3c (https://aip.scitation.org/doi/10.1063/1.5012601) in PySCF with help of this lib. But it seems B97-3c is not in parameters.toml. Could it be added?

Thanks for the work on this!

We are bit in a dead-lock now, since there exists 3 different libraries which all say do the same thing? :)
So which one should we support :)

• the original dftd3 implementation https://www.chemie.uni-bonn.de/pctc/mulliken-center/software/dft-d3/
• @aradi (intentional ping here ;)) did this one: https://github.com/dftbplus/dftd3-lib
• and this one?

I see you are involved in both dftb and Grimme's group.
What I would like to see is that there is one preferred version to be used? If that means archiving one of the packages, then good! :)

Add support for the CSO damping scheme proposed in https://pubs.acs.org/doi/10.1021/acs.jctc.5b00400.

Potential issues:

• only eight functionals are parametrized with this scheme
• unclear how D3(CSO)-ATM would work

Are there are plans for a Python API as for the new DFTD4? I have an interface to the old DFTD4 in ᴍᴏʀғᴇᴜs using both the D3 and the D4 calculators. I am now considering (a) dropping D3 support and only giving D4 (b) still providing interface for users who would do a manual install of the simple-dftd3 Python interface.

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

Include damping parameters for the DM21 function (see https://www.science.org/stoken/author-tokens/ST-218/full), which are equivalent to the B3LYP ones.

Hi,
I installed the s-DFTD3 successfully by pip using:

pip install dftd3

however, I tested the code by following the lines:
python -c "from dftd3.ase import DFTD3"
I got the error like this:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'dftd3.ase'; 'dftd3' is not a package

I am sure I have ASE installed because I can import ASE successfully.

Is there any idea why I got the importing error?

Thank you very much

Best,
Geng

This DFT-D3 reimplementation has become somewhat stable now. Going forward I'm looking for contributors and maintainers to ensure the project remains healthy and available for the computational chemistry community.

Current status

• fpm, meson and CMake build system support
• compatible with GCC >=5, Intel >=18, NAG >=7
• C and Python bindings
• integrated with DFTB+, tblite, DFT-FE, QCEngine (WIP), Siesta (WIP)

Dependencies

• grimme-lab/mctc-lib
  • jacobwilliams/json-fortran (optional)
• grimme-lab/mstore (testing)

Project assets

• readthedocs: https://dftd3.readthedocs.io
• gh-pages: https://dftd3.github.io/simple-dftd3
• conda-forge feedstocks:
  • https://github.com/conda-forge/simple-dftd3-feedstock
  • https://github.com/conda-forge/dftd3-python-feedstock
• PyPI project: https://pypi.org/project/dftd3
• spack package: https://github.com/spack/spack/tree/develop/var/spack/repos/builtin/packages/simple-dftd3

This was a command line feature in the original dftd3 which allowed to create dispersion energies for all pairs in the system. An implementation is available in dftd4 which could be adapted for this library as well. Special care should be taken periodic systems and for calculating the pairwise representation of the ATM contribution.

Related: dftd4/dftd4#81
Patch: dftd4/dftd4#82

Currently the PySCF wrapper can only load parameters from the internal storage of the library and has no option to override parameters when setting up the dispersion correction.

Recently we found pytorch pollutes openmp symbols. DFTD3 returns wrong results after the pollution. While some packages are not affected. I guess that is because the current pypi version (v1.0.0) is using the recent version (gomp_5.0) of libgomp. It is not an issue with the recent openmp, but it would be convenient to have a serial version at the same time.

pytorch/pytorch#109446 (comment)