Frozen core densities / dipoles

[bgpeyton]

currently, the density may be computed with ccdensity.compute_onepdm(. . ., withref = True), which is intended to include the reference (SCF) contribution to subsequent one-electron property calculations by adding twos along the diagonal of the occ-occ block. this is generally only used in the real-time code to compute dipoles which include the SCF contribution, rtcc.dipole(. . ., withref = True). while this works for all-orbital calculations, this is not correct in the case of frozen-core, as the SCF dipole should still be computed with all orbitals (only the correlated calculation freezes the core).

this can't be remedied by simply extending the density matrix for that one computation, since the MO-basis dipole integrals are stored on the wfn without the core as (NACT x NACT). we could either

1. pull the SCF dipole off the reference wfn (computed automatically in Psi) and store it on the ccwfn,
2. just pull it from the ref wfn if requested in rtcc.dipole, or
3. remove the withref option all together.

I'm in favor of the latter, but they're all pretty simple solutions.

luckily, this shouldn't have any impact on previous results, as generally we only use the induced dipole in RTCC, and this option isn't really used anywhere else. @lothian

as a side note, I came across this issue because I made the same mistake again in my CIS code I'm using for some real-time CI work. :)

[lothian]

This is all true. And if we decided to include the orbital response in our RT-CC calculations (something I've been pondering recently), then this would become more of an issue. In addition, I want to add analytic gradients to PyCC because we need a good reference implementation of that, and this issue plagues both the one- and two-electron densities for those.

I think that, for now, we should just remove the withref option from ccdensity.compute_onepdm() and make sure the documentation is clear that the code only produces the correlated contribution.