There’s some difficulty that by default ‘cepa(0)’ through fnocc gives LCCSD (that’s linearized, not local) while through occ gives LCCD. I confirm that fnocc ‘cepa(0)’ with cepa_no_singles true results equal occ ‘cepa(0)’ (formerly ‘lccd’).
The situation is below. I don’t mind making lccd/lccsd aliases, but what should cepa(0) do? And should lccsd be preserved for local rather than being used for linear. Primarily, I want an energy('name') call with name to give the same answer regardless of module.
I’m fine with any proposed default behavior everyone else wants.
Molpro also has cepa(n), and their implementation includes the single excitations by default. This is the default behavior of my code. If we decide that cepa(n) should not include single excitations, this will affect a few methods for me [cepa(n=0,1,3)].
Ok, good to know cepa is functionally ambiguous wrt singles. fnocc is the main cepa module, levels-wise, so I’m not keen to change its calls. Whereas occ/dfocc has breadth of refs, integral types, and oo/non-oo. Will see what others think.
I am also fine with any proposal. However, we should decide on cepa(0) or lccd name. Because my conventional codes uses cepa0 and ocepa for non-oo and oo versions. But for DF/CD version I use df-lccd, df-olccd etc. So we need to make them more consistent. The reason why I switch to LCCD is that some other implementations include singles in cepa(0). Hence, I prefer to DF/CD-LCCD and DF/CD-OLCCD names for new implementations. However, if we want to preserve LCCD for local CCD rather than linearized CCD, then we need to find another way to prevent ambiguous usage of cepa(0). LCCD for linearized CCD is also commonly used. As a result, I am fine with any logical naming proposal.
Right, I already cleared up the mixed cepa0 and ocepa for CONV and lccd for for DF/CD by calling them (for the moment) all cepa(0)/ocepa(0) modulated by cepa_type. So it’s partially straightened out. I just introduced the new bit of confusion since cepa(0) can now be called by both occ & fnocc with different definitions. I guess @sherrill gets to be tiebreaker (not that there’s really opposing sides, since everyone’s being so agreeable).
After mulling it over, I think I’ll advocate for the table below. cepa(0) shall mean cepa w/singles. cepa(0) shall access only fnocc (conv, rhf) and needn’t be a managed method. lccd shall become a managed method, looking a whole lot like the managed cepa0 looks now, only it shall be careful to set no-singles when calling fnocc (so that lccd produces identical values in both modules). Similarly, ocepa(0) shall become olccd. For completeness, lccsd shall be available as an alias to cepa(0).
energy() call | occ/dfocc | fnocc | managed?
================|============|================|================|
lccd | lccd | lccd, w/o sing | yes
lccsd | - - - | lccd, w/ sing | no, fnocc only
cepa(0) | - - - | lccd, w/ sing | no, fnocc only
================|============|================|
olccd | olccd | - - -
One further issue that must be addressed is which *_TYPE variable shall govern the conv/df/cd of these methods. Right now it’s CEPA_TYPE, but that’s confusing it it’s now the cc[s]d notation primarily. How about dropping CEPA_TYPE and governing the lot with CC_TYPE?
This conversation went offline, but comment below from @crawdad frees lccd and lccsd for linear use, consistent with table above.
There are numerous local methods now that simply “L-CCSD” wouldn’t be sufficiently descriptive. I would tend to prefer “PAO-CCSD” for the Pulay-Saebo method, and, as you suggest, DLPNO-CCSD for Frank’s approach. So I would approve this naming convention.