Natural orbitals

[vvp-nsk]

Hi!

By design, to compute energy, both the CR-CC(2,3) and CCT3 methods solve the lambda equations, i.e., the left-hand side eigen-equation and the right-hand side one. Would it be possible to produce natural orbitals and total electronic density in MO basis then?

Thank you in advance!

With best regards,
Victor

[edeustua]

Hey!

Yes, it is possible. We have not implemented it here though. We are working on a new suite, ccpy, which will have this option available. I'll let you know when we have something usable. In the mean time you can check that project under the Piecuch group GitHub.

Thanks for your interest!

Best,
E.

[vvp-nsk]

Hi again!

Sounds great. I will put my eye on repo and be waiting for the next release.

Just a general question. Previously, I have used the GAMESS-US to perform completely renormalized CC calculations, and only recently I realized that such calculations are doable using PSI4. Just in case, which implementation is most trustable?

Thank you in advance!

With best regards,
Victor

[kgururangan]

Sorry for the (very) late response, but just in case this is still useful:

All calculations performed with CCQ, Psi4, and GAMESS, including the completely renormalized corrections of the CR-CC(2,3) and CC(t;3) types, will match each other and are fully trustable. The only difference is that the corrections implemented in GAMESS are more efficient in terms of memory usage, so if you are going to be working on large systems and have no need for the high-level methods including quadruples included in CCQ or the additional functionality offered by Psi4, then you may prefer GAMESS. In addition, for CR-CC(2,3) calculations, GAMESS provides RHF non-orthogonally spin-adapted codes that reduce CPU and memory requirements relative to its open-shell counterpart implemented CCQ and Psi4 by a factor of 2-3. If you prefer to use CCQ or Psi4, and want to tackle larger systems, then we can certainly update the triples correction codes to adopt the low-memory scheme implemented in GAMESS.

Best,
Karthik

[vvp-nsk]

Hi!

I have got some discrepancy in CR-CC(2,3) energies between PSI4 and GUS. Probably, it is a problem of my local installation. The main limitation of GUS is a lacking of high (l>5) angular momentum basis functions in both ECP and DKH2 integral engines. The PSI4 is free from such limitations, and it also supports X2C. Another issue is such that GUS utilizes single core only, and it is a bit annoying when it comes to a medium-sized problem (~300 orbitals, and ~50 electrons). Is it possible by chance to compile CR-CC in GUS with shared memory support for the case of open-shell ROHF reference?

With best regards,
Victor

[kgururangan]

The GAMESS developers are planning on extending the existing CR-CC(2,3) code to develop versions that support shared- and distributed-memory parallelism as well as GPU-offloading, however that is working in progress. If you'd like a shared-memory version, it could be as simple as adding an OpenMP directive above the parent loop over i<j<k in the CR-CC(2,3) correction routine. I can look into this to see if it works.

It's certainly possible that GAMESS has limitations on high angular momentum shells in ECP and DKH2 cases. If this is true, then I would suggest going with the CR-CC(2,3) results obtained with Psi4. It would be surprising if the Psi4 plug-in and GAMESS differed in their CR-CC(2,3) numbers for any system. Could you please provide us with an input for an example that reproduces this error? Small discrepancies in CR-CC(2,3) could be caused by simple things like mismatching basis sets between Psi4 and GAMESS or rotations among orbitals [the most complete CR-CC(2,3) correction, labelled variant "D" is not invariant with respect to orbital rotations]. The latter point, in particular, can manifest when comparing results between codes that adopt different ROHF canonicalization schemes. GAMESS uses the Davidson canonicalization as a default, whereas most other codes (Psi4 included, I believe) will use Guest-Saunders.

Thank you,
Karthik

[vvp-nsk]

Dear Karthik,

let me try to reproduce the discrepancy first. I just recently installed a new stable version of PSI4. Hopefully, I can check the issue next week.

It is good that there is a plan to parallelize CR-CC(2,3) in GUS. To my experience, CR-CC approaches always surpasses CCSD(T) for my systems involving 3d transition metals. Of course, CC(t;3) does an even better job. However, the high-order post-(T) CC energy corrections might be very important. By this, CCSDtq, and CCSDTq methods might very useful.

Let me ask you something. To my best understanding, CR-CC(2,3) is invariant with respect to reference WF. In other words, one can pass any set of orthonormalized orbitals to CR-CC(2,3), in principle. Does it make any sense then to perform CR-CC(2,3) calculations on top of oo-ROMP2 (or, even better, oo-REMP2). Or, alternatively, the GVB orbitals might get more accurate results?

With best regards,
Victor

[kgururangan]

Yes, please let me know if you have an input that we can use to debug.

We're glad to hear that you have had a positive experience with the CR-CC methods. Indeed, they belong to the CC(P;Q) moment expansion hierarchy based on a series of nonperturbative corrections toward full CI, and are thus more robust than conventional perturbative corrections, such as CCSD(T) or CCSD(TQ)/CCSD(TQ_f), especially in situations characterized by stronger T3 and T4 correlations. I agree that including T4 will very likely be required for a high-accuracy description of transition-metal systems, so the methods from the active-orbital-based CC(P;Q) hierarchy that account for both T3 and T4, including CC(t;3,4), CC(t,q;3,4), and CC(q;4) are wise choices. CCQ is likely your best option.

Regarding orbital and reference invariance of the CR-CC methods, we should recall that no approximate CC method is rigorously invariant with respect to the choice of reference wave function. That being said, CC approaches that treat T1 clusters fully are highly insensitive to the reference due to the Thouless theorem. The CR-CC(2,3) approach and its higher-order extensions belong to this category, therefore, I suspect that the invariance you are observing is a numerical invariance of this type, which is an advantage of CC approximations in general. What you are suggesting regarding the use of optimized or GVB orbitals is interesting. Again, due to the Thouless theorem, using a set of non-HF orbitals obtained from some MCSCF-type procedure should not significantly change the energetics obtained the standard HF-based CC calculation. An exception might be in scenarios where there is a discontinuity in the HF solution (e.g., torsion of ethylene), resulting in a cusp in the energy curve, however, these numerical artifacts tend to be suppressed by increasing the level of correlation. Therefore, orbital optimization is a sound strategy for improving lower levels of theory (MBPT(2), CCD, etc.), but loses its effectiveness for higher levels. Nonetheless, it could certainly be worth trying, and it would only require feeding in a transformed set of integrals in the onebody.inp and twobody.inp files.

Best,
Karthik