Use this thread to request new features. I’ll start MM (I plan on working on this at some point as well).
I’d love to get SAPT(DFT) working!
There was recently a request for PBCs over at the public issues. Seemed apt to move it here.
SAPT(DFT) is in my list… Not at the top though, but I really do intend to get that working.
A vote for effective core potentials…
3 Likes
Analytical gradients for CC2 would be great, I don’t think any other free code does that. I am not sure how big the effort would be though, but maybe as CCSD gradients are present already, it might be not that involved?
I’m going to add a request for parallel finite difference of arbitrary functions taking and returning arbitrary types just because I almost have this working and then we can cross a feature request off…
…and now this can be checked off. My branch now has this feature.
1 Like
Another vote for effective core potentials.
I have a student working on this now, actually.
Restart option for SAPT will be helpful!!
Under what circumstances would we need a SAPT restart? Are we talking about SAPT0? Usually these run for a few minutes/hours (or if it’s really big, a few days) and complete, and all is good… The only time I can think that this would be helpful is if you’re running on a cluster with a strict time limit on the queue. But unless the code typically gets cut off in the same part of the calculation, writing general restart capabilities would be non-trivial.
David
I was doing SAPT0 calculations with 300 atoms and the calculation requires more than two weeks.
But the jobs were killed due to time limit in the slurm (queue system).
So it might be helpful to have restart option in sapt0.
UHF-QCISD(T), though of historical value, would be used to confirm pre-CCSD(T)-era computations.
CR-CCSD(T)(L) or CR-CC(2,3) would be an agreeable addition.
-drh
I would be also interested to have SAPT(DFT) in psi4 as well as TD-HF for E2disp and E2exdisp with without density fitting.
Google search shows that dft-sapt module was available in one of the previous beta-versions.
It would be also good if a user could tweak the existing functionals and create new ones. Currently all the available functionals are in binary format, aren’t they?
@leonidas SAPT(DFT) will be in the 1.2 patch; however, it will only be available with density-fitting.
If you wish to build a new functional with existing primitives (e.g. Slater exchange and VWN correlation) the capability current exists within psi4. If you are on the GitHub master branch see:
psi4/driver/procedures/dft_functional.pyECPs might be nice, but the worst deficiency IMHO is the lack of robust convergence accelerators. There’s DIIS and SOSCF, but the latter doesn’t seem to work with DFT.
I’d recomment implementing ADIIS [JCP 132, 054109 (2010)], it’s very easy to implement and is able to converge a lot of systems where DIIS fails.
Another worthwhile feature would be a gradient descent minimizer for cases where Roothaan-Hall does too jumps that are too big, or where degeneracies are an issue. I guess GDM [Mol. Phys. 100, 1713 (2002)] is still the best(?) method.
I need the non-DF version of SAPTs for my research and I really want to stay with psi4. There are some certain reasons for that. As I understand, it is not against the licence if I create my own fork with non-DF integrals?
Is SCF currently available only with DF?
To run plain SCF w/o density fitting, just set scf_type pk or any other non-df from here.
For SAPT, you can certainly use non-DF for the SCF part (same command as above). It looks like you can use exact integrals for all but dispersion through the open-shell SAPT code, if that would work for you. You’re perfectly welcome to fork Psi4 and develop it for your research (that’s how many of the developers work). We’d be delighted if you contributed your code back upstream after your research goals are met, but no ill-will (or license violations) if you don’t.
And it’s since done, yay!
I just learnt that the FCIQMC codebase NECI has recently been put under the GPL: https://github.com/ghb24/NECI_STABLE/commit/0c6c68f1be24d250ca1799ad27734e94694039cf
NECI is interfaced to MOLPRO and also PySCF (according to http://sunqm.github.io/pyscf/overview.html#features), might this be a good candidate for Psi4, or is it too Fortran-based?
Reference articles are G. H. Booth, A. J. W. Thom, and A. Alavi, J. Chem. Phys. 131, 054106 (2009) (Full FCIQMC), D. M. Cleland, G. H. Booth, and A. Alavi, J. Chem. Phys. 134, 024112 (2011) (i-FCIQMC) and G. H. Booth, D. M. Cleland, A. J. W. Thom, and A. Alavi, J. Chem. Phys. 135, 084104 (2011)