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)
Could I easily add analytic DFT? The only new thing would be the cubic overlap RIJ tensor, I think. Would it be accessible?
A recent paper on effective-core potentials is JCP 147, 074102 (2017).
IR intensities would be helpful for educational purposes. The integration of PSI4 with WebMO lacks this feature to aid with the PSI4Education project.
1 Like
Any plans to upgrade to LibXC 4.0?
As of a week and a half ago, the developer opinion was that some of Psi4’s current functional manipulation capabilities will be lost if we switch from 3.0 to 4.0, so we’re stuck at 3.0 for the time being.
@cembry There have been some issues upgrading to 4.0, but they may have been worked out. Which feature of LibXC 4.0 are you interested in out of curiosity?
Primarily SCAN+rVV10, possibly some other new functionals.
@cembry Ah, as a note rVV10 is not in LibXC and would have to be programmed separately. We have VV10 so the changes would be minor, but could take some time.