use findif for ccsd(t) conv gradients most of time

[loriab]

Description

@lothian, the primary files to look at are procedures/proc.py, cc.rst, preview_capabilities_ccenergy.rst, and (for example) cc13b/input.dat

User API & Changelog headlines

• Conventional ccsd(t) gradients will now proceed as finite-difference calculations, which are much more memory efficient. If you still want to access the analytic gradients, add set qc_module ccenergy.

Dev notes & details

• the main change is disabling default conv rhf/uhf ccsd(t) analytic gradients through ccenergy in proc.py . they're still accessible by setting qc_module=ccenergy explicitly
• changes to tests so that we're still testing the gradients
• changes to the capabilities auto-documentation that starts with stdsuite, gets stored in samples/stdsuite_psi4.txt, and gets processed into docs tables, a viz preview of which are stored in sphinxman/source/.
• simpler docs-building environment!

Checklist

• Tests added for any new features
• All or relevant fraction of full tests run

closes #2913

Status

• Ready for review
• Ready for merge

[lothian]

I wonder if it's the syntax qc_module="ccenergy" is confusing since that's the name of the CC energy code, but it's signaling to compute gradients analytically. I'm not sure what I'd prefer, but I don't think this will be obvious to most users.

[loriab]

I wonder if it's the syntax qc_module="ccenergy" is confusing since that's the name of the CC energy code, but it's signaling to compute gradients analytically. I'm not sure what I'd prefer, but I don't think this will be obvious to most users.

I agree there's not a great name for the cc suite. Only alternative I've seen is cc*. cc alone seems too generic.

It looks like the qc_module=ccenergy came about for this role between beta5 and v1.0: https://github.com/psi4/psi4archive/blob/1.0.x/src/bin/psi4/read_options.cc#L165-L168 . So it's longstanding, though probably little used. If you think of a preferred alias, it'd be easy enough to re-route, I suspect.

[lothian]

I wonder if it's the syntax qc_module="ccenergy" is confusing since that's the name of the CC energy code, but it's signaling to compute gradients analytically. I'm not sure what I'd prefer, but I don't think this will be obvious to most users.

I agree there's not a great name for the cc suite. Only alternative I've seen is cc*. cc alone seems too generic.

It looks like the qc_module=ccenergy came about for this role between beta5 and v1.0: https://github.com/psi4/psi4archive/blob/1.0.x/src/bin/psi4/read_options.cc#L165-L168 . So it's longstanding, though probably little used. If you think of a preferred alias, it'd be easy enough to re-route, I suspect.

OK, then let's go ahead.

[TiborGY]

When I see the word "scaling" in this context I think of CPU-time, not RAM requirement. If the main problem with the current implementation is the amount of RAM required, I think something along the lines of "but the amount of RAM required scales steeply with system size." would get that point across better.

[loriab]

Memory is what the output files show running out. But if I recall old conversations correctly, it's N^9 scaling, not the expected N^8.

[lothian]

I don't think it's N^8 or N^9. It should be N^7, but the prefactor is terrible in my implementation.

[loriab]

eek, yes, N^8 instead of N^7 is what I meant to write. Good to know that the issue is actually prefactor.

If anyone wants to clarify the message, the document_capabilities.py file is the single source. Any edits can get propagated to the tables in a future docs build.