empirical disp updates

[loriab]

Description

Todos

• switch gcp interface to QCEngine
• add dftd4 interface calling QCEngine
• update types return for disp. engine can handle ndarray, so leave arrays as np and shaped rather than flat lists
• more tests -- psiapi, parameters extend func
• add docs
• note min qcng version, prob. v0.19
• this passes cleanly locally but that's with custom engine and dftd4, so several PRs ahead of this one
• allow doi as citations for dft
• note that for Mol.run_dftd4, func overrides parameters in keeping with dftd4 API behavior, whereas in dftd3, parameters extend or override func.

Questions

• @jeffschriber should fisapt grab 2-body disp analysis or total disp analysis
• a couple of the interface updates should be in v1.4 but d4 itself can be in v1.5. so this can get split after upstream settles down.

Checklist

• Tests added for any new features
• All or relevant fraction of full tests run

Aug 2021 Notes

• rebased. the only thing that's left of the original PR checklist is dftd4 itself. gcp and dftd3 updates were pulled in in empirical disp updates for qcng v0.19 #2180.
• note that it's not the dftd4 exe that this (that is, qcng) needs; rather, it's the dftd4 pymod that's needed.
• one can use the c-f dftd4-python conda package if you know how to set up your env to install both it and psi4 deps. But for linux only, I've prepared a dftd4 conda package (not in final build form) off -c psi4/label/dev.

Status

• Ready for review
• Ready for merge

EDIT: closes #1710

[lgtm-com]

This pull request fixes 5 alerts when merging 79d4582 into 59d998d - view on LGTM.com

fixed alerts:

• 2 for 'import *' may pollute namespace
• 1 for Unused local variable
• 1 for Module-level cyclic import
• 1 for Module is imported with 'import' and 'import from'

[lgtm-com]

This pull request fixes 5 alerts when merging 1e663e4 into 86700a9 - view on LGTM.com

fixed alerts:

• 2 for 'import *' may pollute namespace
• 1 for Unused local variable
• 1 for Module-level cyclic import
• 1 for Module is imported with 'import' and 'import from'

[lgtm-com]

This pull request fixes 5 alerts when merging 051af5c into 966d1bd - view on LGTM.com

fixed alerts:

• 2 for 'import *' may pollute namespace
• 1 for Unused local variable
• 1 for Module-level cyclic import
• 1 for Module is imported with 'import' and 'import from'

[lgtm-com]

This pull request fixes 5 alerts when merging f1483ae into b4a272f - view on LGTM.com

fixed alerts:

• 2 for 'import *' may pollute namespace
• 1 for Unused local variable
• 1 for Module-level cyclic import
• 1 for Module is imported with 'import' and 'import from'

[lgtm-com]

This pull request fixes 5 alerts when merging 97583a2 into d9d8477 - view on LGTM.com

fixed alerts:

• 2 for 'import *' may pollute namespace
• 1 for Unused local variable
• 1 for Module-level cyclic import
• 1 for Module is imported with 'import' and 'import from'

[JonathonMisiewicz]

A few documentation comments, but LGTM otherwise.

[JonathonMisiewicz]

Do you mean to run?

[JonathonMisiewicz]

What if this isn't supplied?

[loriab]

mol.run_dftd4(dashlvl="d4bj") throws a none is not an allowed value (type=type_error.none.not_allowed)

The validation for d4 isn't quite so thorough as d3 because the d4 program uses different precedence rules, so I couldn't reuse by d3 fn. But the testing isn't quite as stingy as it looks here at psi4: https://github.com/MolSSI/QCEngine/blob/master/qcengine/programs/tests/test_dftd3_mp2d.py#L1701-L1715

[JonathonMisiewicz]

Also, please grep for comments related to dftd3 in the code and update them as needed. proc.py::scf_helper certainly needs to be updated.

[PeterKraus]

This might be a good place to add at least the most common -D4 functionals to test_dft_benchmark.py.

[PeterKraus]

Is there any way to harmonise these two? The way I understand it, we do the same thing Psi4-side, but the behaviour of dftd3 and dftd4 differs when both func and dashparams are provided.

In any case, not Psi4's but rather qcng's problem...

I'm guessing the only problem might be when one wants to run, say, B3LYP (for which func values are defined) with a custom set of parameters - is this possible to do with dftd4?

[awvwgk]

See related discussion here: dftd4/dftd4#98

Short summary:

dftd4 does not provide the possibility to select a functional, say B3LYP and only change the s8, this is by design. Either the downstream user hands the responsibility over to dftd4 to select the correct parameters or provides all damping parameters.

If Psi4 requires full control over the parameter selection, it can't use the former mechanism, but has to always construct the set of damping parameters first (qcng knows how to do this for all supported functionals in dftd4).

Note that in the future dftd4 will most likely throw an error in case both functional name and an (incomplete) set of damping parameters are provided.

[PeterKraus]

Given your comment below, this is not true for dftd4.

[loriab]

I've revised the docstring, I hope truthfully. There were several principles that wanted to be followed here ((a) psi4 dft-d interface should be consistent, (b) qcengine harness should follow upstream project in keyword handling, (c) qcengine dash harnesses (dftd3, gcp, mp2d, dftd4) should be consistent, (d) Molecule.run_dftdN (aka psi4 -d interface) should be consistent), and I just couldn't make them all so. The Molecule.run_dftdN seemed like the least important one to sacrifice.

[PeterKraus]

Looks great, can't wait to use the functionals!