Managed methods, feedback required

Developer News & Discussion
1

Greetings @crawdad, @sherrill, @deprince, @bozkaya,

I understand this forum category is to replace the mailing list and that all developers should “watch” it (dropdown next to “+ New Topic”).

In the course of driver renovations in the wavefunction_pass branch, I realized the extent of the problem of overlapping capabilities (e.g., TDC does ccsd, AEP does ccsd, UB does ccsd) and the contrived means by which they are accessed when not default (e.g., ccsd2, ri-ccsd, _ccsd). Also, there were variations in how conventional vs. density-fitted vs. Cholesky decomposed calculations were being accessed that could use smoothing over. Therefore, I have introduced “managed methods”, which you should read about
http://psicode.org/psi4manual/master/proc_py.html#managed-methods once they’ve built tomorrow (if the group fileserver is up to it; otherwise, https://github.com/psi4/psi4/commit/5450afa54b4f5861c0470c440bc85935145a0d2f for text and http://psicode.org/psi4manual/master/sowreap.html#id1 for table).

As authors of the managed methods, I need your answers to a few things (or we can discuss them Wednesday, just don’t go and start fixing things up in (either) master, as wavefunction_pass branch is where changes are at present.

  • @bozkaya Should your non-OO code be able to take RKS/UKS references?
  • everyone, that table in the docs above, look over your part (the blank (unavailable) vs. Y/D (available) marks and see if anything is inaccurate.
  • everyone, be prepared to debate any changes to D (default) marks in that table.
  • everyone, please certify to me whether your code is symmetry enabled or symmetry-tolerant (latter needs switching to c1 before running module and restoring symmetry after). I think it’s
    • detci and ccenergy (& co.): symmetry enabled
  • fnocc: symmetry tolerant (but run_fnocc seems to be using symmetry)
  • occ: symmetry enabled while fnocc symmetry tolerant?
  • @bozkaya do ccdl and ccsdl really belong in the energy() list as separate methods when they’re just running the lambda eqs after a normal method? are they ammenable to CD?
  • @crawdad I’d like to rename CONVENTIONAL in keyword CC_TYPE to CONV for consistency with MP2_TYPE that has had CONV and DF values for a while.
  • @bozkaya should ROHF DF MP2 gradients be there? get an error
  • @bozkaya I had to add psi4.set_local_option('DFOCC', 'CC_LAMBDA', 'TRUE’) to df-ccd gradient, as it seemed to need it
  • @deprince I don’t think you’re ever computing cid method. There’s nothing to distinguish it from cisd
  • @deprince need symmetry c1 handling for run_cepa?
  • doing DF <=MP2 and CONV >MP2. are these the proper defaults for calc type
  • @crawdad should ‘ccsd’ be in this list? https://github.com/psi4/psi4/blob/wavefunction_pass/lib/python/proc.py#L1836

Perusing the changes to the test cases https://github.com/psi4/psi4/commit/34054833235bd49d9f4b9f4d3917099805923ef9 may help to see the practice of using the new scheme.

2

Hi Lori,

  • Non-OO codes are not able to take RKS/UKS properly.
  • occ module symmetry enabled but dfocc module is not.
  • ccdl and ccsdl options were added for debugging purposes. They just mean to solve ccd/ccsd lambda amplitude equations after energy runs. Presently, they are inactive.
  • Presently, ROHF DF-MP2 gradients are not available. However, I will implement it when I find available time.
  • We need to psi4.set_local_option(‘DFOCC’, ‘CC_LAMBDA’, 'TRUE’) for ccd and ccsd gradients.

Best regards,
Ugur.

3

DETCI entries in table are fine except that I don’t want to default to DETCI for ROHF-based MP3 and MP4, since the algorithm it uses is an arbitrary-order one which will be very inefficient. We can just fail by default for these capabilities at present, but allow them to be run using DETCI if the user insists using set_qcmodule DETCI.

4

I’ve talked to Rob re. DFMP2:

  • energies: RHF/UHF/ROHF/RKS/UKS
  • gradients: RHF (not RKS)
  • is symmetry-tolerant (see below)

For general enlightenment, here are the modes of symmetry operation for modules. (I had thought there were only two, so others may be confused, too.)

  • symmetry-enabled: makes good (efficiency) use of molecular symmetry
  • symmetry-tolerant: makes no use of molecular symmetry but work from a reference wavefunction containing symmetry (does the conversion to C1 c-side)
  • symmetry-shunning: makes no use of molecular symmetry and needs its reference wavefunction to have no symmetry. needs use_c1 py-side, as in scf_helper(name, use_c1=True, **kwargs)
5

I’ve talked to Eugene re. FNOCC:

  • all methods are solely RHF
  • all methods available in conventional integrals
  • [fno-]ccsd & [fno-]ccsd(t) are additionally available DF & CD
  • all conventional integral methods are symmetry-tolerant
  • all DF & CD methods are symmetry-shunning
  • cid to be dropped for present b/c not quite set up right (py-side def.; c-side ?)
6

As of today, all the issues brought up in this thread are implemented. FNOCC and OCC have updated docs that you’re welcome to change up more. @bozkaya, thanks very much for your replies to this thread. The docs-building computer is down, but the changes to your chapter are here https://github.com/psi4/psi4private/commit/ee437f8102541ccb082c0049b66d577bce6d77d4 . Also, I dropped the ccdl and ccsdl method names, so I converted those test cases to plain ccd and ccsd.