solid harmonics ordering: runtime switchable L2, build-time switchable psi

[loriab]

Description

User API & Changelog headlines

• Psi4 can use a standard ordering Libint2 build. But not one that's in upstream master for now. If you really want, you can switch the internal spherical harmonics ordering Psi4 uses.
• Psi4 works with next-gen Intel compilers icpx and now uses c++17 standard throughout.

Dev notes & details

• Prepare to use a L2 that can be initialized into gaussian or cca ordering for Operator::nuclear. In practice, this means we can use the same built L2 as other open-source projects. cmake harness, 2023 edition evaleev/libint#259
• Make it easy to experiment with gss or sss ordering combinations with a build-time setting in psi psi4_SHGAUSS_ORDERING
  • successor to change solid harmonic ordering from gaussian to standard #2537 . no plans to transition to sss though. grab the fchk changes from that PR so it can be closed unmerged. fchk changes can be a follow-up PR.
  • need to transform cmake var from str to int
  • need to print gau/std to output file
• only Linux CI expected to pass, as that's the only conda package built with the new L2. unedit docs-cf, two azure files, and one ecosystem file
• removed all the LGTM_SRC stuff since it's defunct and all the "CHOOSE" stuff, since a master L2 won't work anymore b/c need the shg order switching.
• finishes the job of fully C++17 from c++17 #2392 . Newest Intel compilers from 2023.0 oneapi (versions icpc 2021.8 and icpx 2023.0) are ok with Libint2 and C++17. For older Intel, there's a keyword psi4_CXX_STANDARD_Libint2 that can be reset to 14.
• pull together accumulated xhost changes (hiccup here is that icpx can take -xHost but icx can't, and our option_with_flags routine tries both so it throws an unnecessary warning. not a must for this PR).
• the linux L2 is my local c-b, but mac and windows are from c-f staged-recipes. apparently any Hessian ERIs cause the Windows build to hang longer than the 6h Azure allows, so the W package is hessin-ints-less for TEI (I kept the onebody 2der). This isn't too debilitating since only HF and SVWN have analytic hessians anyways, so when an incapable L2 is detected (imagine that -- we can ask L2 what it can do!), it falls back to FD. That would be easy enough except the tests check too tightly for 3-pt FD to match analytical refs. So I've added a d2ints label to ctest and pytest to allow not running. This should probably convert to a skipif someday. Most of the tests I've checked individually and they would pass if findif points=5.
• You notice a "new" boost-cpp dependency. Compiling against the header-only L2 C++11 interface (as psi4 does) requires a select few boost headers. In building the L2 package, one can either ask L2 to copy those few files in to include/libint2/boost/ (that is, vendor boost) or not, effectively passing the problem along to the consumer (psi). In my own conda packages for L2, I did the former, so psi didn't need any boost. For the c-f L2 packages, I figured it was better practice to not vendor, hence the "new" dep. It's header-only, not boost::python or any of the boost compiled libs, so not too much trouble, I think.

Questions

Can look at the libmints files to form an opinion on these.

• libint2::initialize() was called three times, but libint2::finalize() only once. I added two more, but should I have?
• Also, since we need to set the ordering, should the init be centralized in core.cc, or is it fine as is?
• technically, ordering could be set at runtime. that seemed hard to reliably prevent mixing of scratch files so I stuck with the restricted build-time case.

Checklist

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

Status

• Ready for review
• Ready for merge

[JonathonMisiewicz]

the linux L2 is my local c-b, but mac and windows are from c-f staged-recipes. apparently any Hessian ERIs cause the Windows build to hang longer than the 6h Azure allows, so the W package is hessin-ints-less for TEI (I kept the onebody 2der).

Is this going to be a long-term state of affairs? I'd love to add more analytic hessians.

[loriab]

the linux L2 is my local c-b, but mac and windows are from c-f staged-recipes. apparently any Hessian ERIs cause the Windows build to hang longer than the 6h Azure allows, so the W package is hessin-ints-less for TEI (I kept the onebody 2der).

Is this going to be a long-term state of affairs? I'd love to add more analytic hessians.

It's likely to be semi-permanent for Windows. (Resolution would involve partitioning the 2nd deriv ERIs to a separate build group with lower optimization (as JMT does) and some good luck that they still compile quicker. Or petitioning to upload a hand-built package instead of relying on their CI build services, and I wouldn't like to do that before the L2 code is properly upstream.)

But none of this is a block to new analytic hessians. Linux and Mac or anyone building L2 from source (with proper settings) is able to take adv of anal. H. And any new ones won't need extra work-around code, only a label for their tests.

[maxscheurer]

@loriab Regarding the first two "questions": It'd be great if the init were centralized... Currently each integral "type" has its own initialize (one-body, ERIs, and three-center overlap... I had to add the last one during the transition of 3c ovlp to L2 after endless debugging because I thought initialize was always called 😂) So if you can give the centralized initalize a try, that could be quite helpful and prevent weird behavior in the future.

[loriab]

Thanks, @maxscheurer, centralized L2 initialize/finalize seems to work just fine. Now the orderings toggles only effect core.cc (L2 init), solidharmonics.cc (sh ordering), and points.cc (g2g ordering).