CompositeJK Bonus: J-Only SCF_TYPE Specification for DFT #3001
Conversation
davpoolechem
force-pushed
the
dpoole34/compositejk-scftype
branch
from
b606940 to
07ee3ba
Compare
loriab
left a comment
loriab
left a comment
There was a problem hiding this comment.
Since this is real trouble if a K-needing method doesn't get a K, maybe add a test of scf_type=dfdirj parametrized over BP86 and B3LYP that checks that the former runs and the latter errors informatively.
psi4/src/psi4/libfock/jk.cc
Outdated
| bool is_composite = jk_type.find("+") != std::string::npos; // does SCF_TYPE contain +? | ||
| is_composite = is_composite || options.get_str("SCF_TYPE") == "DFDIRJ"; // is SCF_TYPE equal to DFDIRJ? |
There was a problem hiding this comment.
This is starting to look piecemeal. Is there a clean c++ for is_composite = any([piece in options.get_str("SCF_TYPE") for piece in {"DFDIRJ", "COSX", "LINK"}])
There was a problem hiding this comment.
Just added a new implementation for is_composite that uses std::any_of to handle it more elegantly! It will technically evaluate true if SCF_TYPE is set to COSX or LINK (i.e., without DFDIRJ in front of it), but those are never accessible options via SCF_TYPE normally anyway. Still worth testing for those cases, too, to make sure the code throws right.
Yeah, I can do that! |
|
This is great! Another big advantage is that one can use the smaller J fitting basis sets ( |
Co-authored-by: Lori A. Burns <[email protected]>
davpoolechem
force-pushed
the
dpoole34/compositejk-scftype
branch
from
5136adb to
ca7df3a
Compare
You're welcome! I think the new tests should be good to go now.
Thank you! What you describe should already be doable in Psi4 v1.8. This PR just makes the specification of |
4 participants
Description
The idea here was suggested by @CDSherrill, and implemented in this PR.
What is this "idea"? Currently, CompositeJK methods are accessed through
SCF_TYPEoptions of the formJ_algo+K_algo, withJ_algoandK_algobeing the respective composite J and K build algorithms to be used for the calculation. Meanwhile, one notable benefit of the CompositeJK class is that, for DFT calculations that use non-hybrid functionals, composite methods can be used to specify an algorithm specifically optimized for J matrix construction, in contrast to general algorithms which need to also account for the K matrix. Since non-hybrid DFT calculations only require the J matrix, CompositeJK can lead to speedups in such cases. But in those cases where only the J algorithm is needed, the currentSCF_TYPEspecification for CompositeJK has a problem - the composite K algorithm that must be specified, is unnecessary and unused.This PR allows for the specification of CompositeJK algorithms via only the J algorithm for cases such as non-hybrid DFT, where only the J matrix is needed. If CompositeJK is called without a K algorithm in cases where a K algorithm is needed, such as HF or hybrid DFT, an exception is thrown. Additionally, if the
J_algo+K_algoSCF_TYPEspecification for CompositeJK is used in conjunction with a non-hybrid functional, a note is given to the user, letting them know that the K algorithm won't be used.User API & Changelog headlines
SCF_TYPEoption,DFDIRJ, for usage in non-hybrid DFT calculations.Dev notes & details
SCF_TYPEkeyword. This can be useful in non-hybrid DFT calculations, where the K matrix is unnecessary.SCF_TYPEnotation is used when the K matrix is not required, a note is given to the user.Questions
Checklist
Status