Is ROHF-BCCD(T) possible?

Dear PSI4 developers,

I was hoping to find a program to do ROHF-BCCD(T) calculations (energy only) and it seemed on the surface that PSI4 would be the answer since the manual says that at least ROHF-CCSD(T) is possible. After building the program and testing out a simple open-shell case, it appears this is not the case after all:
An error has occurred Py-side
<type ‘exceptions.RuntimeError’>:
Fatal Error: ROHF-CCSD(T) is not yet available

What are the odds this is in the works? I did read somewhere on this forum that Daniel has as ROHF-CCSD(T) energy code in the works…


-Kirk Peterson

Indeed, works as-is with energy('ccsd(t)') but not with 'bccd(t)', though indicates it ought. Perhaps because BCCD(T) isn’t semicanonicalized in, while CCSD(T) is in (actually, how is the latter never calling psi4.cctriples() anymore)? @crawdad, please advise any conciliation you’d like me to make in driver and docs.

I haven’t thought about this in quite a while, but here are a couple of points:

(1) We can most certainly compute ROHF-CCSD(T) energies. These are handled using semi-canonical ROHF orbitals, and all non-Brillouin terms are included, as they should be.

(2) A “conventional” open-shell B-CCD(T) calculation could start from either an ROHF or UHF reference, but it’s not clear to me that the final orbitals would be different. That is, isn’t a standard spin-orbital-basis B-CCD open-shell wave function uniquely defined? Furthermore, the resulting orbitals would be spin polarized, regardless of whether a proper ROHF determinant was used as the initial guess. (Note that difference would occur if core orbitals were frozen, however.)

(3) @loriab’s question about the Python driver is very much worth investigating, as it may simply be a matter of making sure the semicanonicalization occurs for the B-CC cases. I’d be interested to see if my recollection that ROHF- and UHF-guess B-CC are the same (sans frozen core).

(4) Some years ago I published an alternative “RB-CCD(T)” method that maintains the spin-restricted nature of the Brueckner orbitals based on a symmetric spin-orbital formulation. I didn’t carry this over to PSI4, but it wouldn’t take too much effort to make it work, if there’s interest.

(5) @loriab, the cctriples code is called from within ccenergy, I believe rather than by the Python driver.


Yesterday I did a U-BCCD(T) calculation in G09 on CN, which has a very large spin contamination with UHF. The program actually prints out an S^2 value for the final BCCD wavefunction and it goes from about 1.153 at the UHF level to 0.764 with BCCD. That was with the 1s orbitals frozen. Hopefully I won’t get into any trouble with Mike Frisch, but the U-BCCD energies between G09 and PSI4 compared very well, but the (T) contribution differed by more than 1 mEh, which points perhaps to a semi-canonicalization difference perhaps.

I would be very interested in trying that calculation myself, Kirk, as I’d like to make sure there are no bugs in our (T) code. Can you email me the input file(s)?


The PSI4 one or G09?


The G09 one is super simple:


BD(T)/aug-cc-pVDZ OldFCBD

CN test

0 2
N 1 r


I don’t have a definitive answer yet, Kirk, but there is clearly a difference of some sort in the (T) correction between the two codes. I also ran the calculation using CFOUR, but for some reason it won’t accept my semicanonicalization input (ORBITALS=SEMICANONICAL is being ignored). Nevertheless, when I correlate all electrons (just to make sure there’s no problem with the definition of the impact of the correlation on the core, I get the following for your test case (Hartrees, tight convergence on all codes):

PSI4: -92.490464318569110
CFOUR: -92.490464318574
G09: -92.490464320

PSI4: -92.508367325562773
CFOUR: -92.508235366529
G09: -92.507549629

Also, CFOUR will accept either a UHF or ROHF reference as the starting guess for the Brueckner procedure, and it converges to exactly the same result regardless of which you choose. My best estimate right now is that PSI4 is right – I’m certain we’re keeping all the non-Brillouin terms and we semicanonicalize the orbitals – but I can’t prove it.


Never mind! I figured out what was wrong with my CFOUR input file, and now I have it using the ORBITALS=SEMICANONICAL keyword (as long as I also set REF=ROHF). Now the B-CCD(T) energies compare well, with PSI4 starting from a UHF reference and CFOUR starting from an ROHF reference:

PSI4: -92.508367325562773
CFOUR: -92.508367325561

I believe that PSI4’s B-CCD(T) energies are correct.

Sweet! I’ve been exchanging emails with John Stanton about CFour’s implementation and initially everything I ran hung until I switched back to the old version 1.0. I hadn’t tried ROHF yet with the older version. Very cool that both ROHF and UHF give the same Brueckner orbitals. PSI4 is preferable to us since one can do DK3 (which matches our new basis sets for actinides and lanthanides).

I should walk back my statement about UHF and ROHF initial guesses giving the same result, because the error in my CFOUR input file prevents me from being certain. Nevertheless, the fact that CFOUR and PSI4 give identical results suggests that my conclusion is likely still correct.


When I run UHF and ROHF in CFour I do get the exact same BCCD energy, it’s just that the (T) is different since it ignores the semi-canonical command in the UHF case. I’ve now bugged John about this (also CFour does the (T) at every Brueckner iteration, which seems a little silly).

@Kirk, ROHF-BCCSD(T) should be fixed now after . It should be available in source currently and in binary tomorrow.

Fantastic, thanks much!

Actually I should have asked - how do I install this patch? Is there a straightforward way to do a git pull ?

Probably. But it depends on how you got Psi4 in the first place.

  • Are you running the binary (acquired through miniconda)?
  • Are you using a tarball from sourceforge or github?
  • Did you git clone psi4 from GitHub before ~15 Feb 2016?
  • ditto after ~15 Feb?
  • Do you have non-trivial modifications to the source?

Once I know any “yes” answers to the above, I can help you better.

I just got a tarball from GitHub on Feb. 15th. I have not made any mods to this source.

Ok, well with a tarball, there isn’t an easy way to update. You could try applying a diff ( or patch (, but I’ve never done that, and I don’t know if your source is up-to-date enough for it to work.

I’d recommend instead that you do git clone as discussed here ( You’ll have to recompile, but then in future, you can git pull and get any new changes easily and have minimal recompile.

Ok, this is what I feared. I’ll go ahead and do a git clone since that will make things much simpler in the future. It just takes an amazingly long time to build with gcc

Yes, with Boost and high AM integrals it does take a while, sorry. Parallel builds work nicely, if that helps.

make -j`getconf _NPROCESSORS_ONLN`