-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Harness for DFT-D3 Python API #341
Comments
I haven't thought through the possible stumbling blocks, but in general, I'd suggest deriving harnesses where we can (like classic vs. mctc gcp). Does it make sense for s-dftd3's harness to derive from dftd4? |
There are some, it boils down to the question whether we want a bug-compatible implementation or whether it is sufficient to get the same dispersion energies and gradients in the end. My greatest concerns are
Notably, there is a bug in QCEngine/qcengine/programs/dftd3.py Line 313 in bc1a161
which removes |
Oh dear. No need in principle to perpetuate my mistakes. I'd like to understand the trouble better. Since the original |
No worries, the resulting dispersion correction is correct, only the implementation has a bug that is not realized in any actual calculation due to performing the D3 calculation twice. There is actually a difference in naming between the two-body only variants, D3(*), and the ones that include three-body contributions, D3(*)-ATM. However, there was never a clear recommendation, which variant should be preferred with the original publications, but in practice we have been using mostly the ATM variants (AFAIK from the works I have seen since 2017). Basically this is our mess, which I would like to handle more gracefully going forward. We learned from this mistake and made a clear recommendation in the D4 publication. Another thing is that no damping function really defined a different ATM damping function, the D3M(0) would have been the best candidate to introduce the β parameter there as well, however most revised damping functions, like D3M, D3(op) and D3(CSO), didn't really discuss how the ATM should be handled. Nowadays we know that also rational damping functions work well with the ATM term. |
I created an initial draft for the DFT-D3 Python API harness in #343. Feedback is welcome. |
Is your feature request related to a problem? Please describe.
The
s-dftd3
project provides a reimplementation of the DFT-D3 method with native bindings to Python (API docs) since version 0.4.0, the bindings are similar to the Python API provided bydftd4
, which already has a harness inqcng
.Therefore, the implementation of a hardness should boil down to change the import from
dftd4
todftd3
and adapting the dashlevel logic.Describe the solution you'd like
Possible options are:
s-dftd3
(SDFTD3Hardness?)dftd3
and change to API call in case thedftd3
Python module is importableDescribe alternatives you've considered
Do nothing, there is already an interface to the reference
dftd3
implementation.Additional context
The text was updated successfully, but these errors were encountered: