test solid harmonic ordering runtime switchable

loriab commented 10 months ago

~currently atop #270~

[x] tl;dr Ignoring all the testing, libtool, pkgconfig, and docs stuff, this PR has only one important line: https://github.com/evaleev/libint/pull/271/files#diff-6b025276ef426b69c020c54935b3573f2983a24424bad15bcb5693d6ceeb719eR196
[x] add testing for printing configuration_accessor() (I missed compiling it in in #269). Add testing for switching the SHO in the built library. The main test is duplicated as test_g.cc so standard and gaussian orderings get accessed regularly. Alternate reference values added.
[x] Compared to c. Sept 2023 versions of this PR (and compared to #259) that used 3-letter codes for solid+cart+shell ordering (e.g. gss, sss (default), soo), this now uses 2-letter codes cart+shell (e.g., ss, oo) for configuration tagging. This is possible because:
- 269 made the first letter (s or g) configurable at runtime, so there's no need to label a built library for the ERI role. (was library-configuration-time, now library-runtime)
- https://github.com/evaleev/libint/commit/cdbb9f3 made spherical multipole ints non-configurable, so there's no need to record their ordering in the built library. (was generator-configuration-time, now inconfigurable)
[x] Compared to c.Sept 2023 versions of this PR (and compared to #259), new forms are used for cmake components.
- [x] eri_c4_dD_lL --> eri_hhhh_dD
- [x] eri_c3_dD_lL and impure_sh --> eri_hhL_dD and eri_hhl_dD
- [x] eri_c2_dD_lL and impure_sh --> eri_HH_dD and eri_hh_dD
- [x] onebody_dD_lL --> onebody_h_dD --> onebody_hh_dD
- [x] g12_dD_lL --> g12_h_dD --> g12_hhhh_dD
- [x] nothing --> multipole_h? --> multipole_hh_dD
[x] fix up libint.pc for the pkgconfig folks according to request in https://github.com/evaleev/libint/pull/205#pullrequestreview-853733407 . The existing pc file didn't look populated in the export, so I added a separate one. Fixed hard-coding of pc file installation, but one does still need to set both LIBINT2_INSTALL_LIBDIR and CMAKE_INSTALL_LIBDIR to co-locate the library, the cmake config files, and the pkgconfig files.
[x] enable default unity build for library (needs cmake 3.16). add a couple status variables to the libint2-config.cmake file. copy over a bit of the INSTALL.md from #259
[x] cherry-pick over some EFV commits that looked important from #205

closes #225 closes #230

~Downstream testing (still using `sss`, not `ss`)~

Downstream testing (now `ss`-based; mostly `dev1` -> `dev2`; Oct 30)

This PR has a sample library src export
It packages on Linux/Mac/Silicon/Windows here https://github.com/conda-forge/libint-feedstock/pull/22
It has a few conda packages for testing here https://anaconda.org/psi4/libint/files . install via ~conda install libint=2.8.0dev1 -c psi4/label/testing~ conda install libint=2.8.0dev2 -c psi4/label/testing
It works with psi4 here https://github.com/psi4/psi4/pull/3047

loriab commented 8 months ago

This is rebased and updated and ready for consideration, I think. I'm glad to make any changes.

loriab commented 8 months ago

I've updated the testing of downstream packaging and psi4 usage with the revised component names. Links are in the last section of the PR frontmatter. I might add a script for the generation of cmake components for the patch (I've been doing it by hand), but that can be a separate PR if this is otherwise in good shape.

evaleev commented 8 months ago

@loriab thank you, this looks great!!! The only thing I would consider changing make the encoding of angular momenta and derivatives into non-eri components more systematic and future-proof by replacing multipole_l -> multipole_ll_dD ... i.e. all compute types can have derivatives, and for all operator set types we can have arbitrary number of centers, e.g. 4-center (1-e) overlaps are useful, although those one can get via the eri route by tweaking the core integrals. Still, would be useful to keep things systematic. What do you think?

loriab commented 8 months ago

Great! I'm all for systematizing and future-proofing the components, but I may not be following the extent of what you're proposing. Were you thinking of <operator>_[<hh>|<HH>|<hhl>|<hhL>|<hhhh>]_d<D> for each operator in https://github.com/evaleev/libint/wiki/using-modern-CPlusPlus-API#create-an-integral-engine ? E.g., eri_* get renamed to coulomb_ and g12_ to cgtg_ (plus getting 2,3,4-center components)?

On one hand, this (a) would make the connection between build configuration arguments and integrals classes provided much clearer, (b) I don't see any limitation on the length of CMake lists, (c) in future, they're all substituted into the l2-config.cmake, so there's no added complexity https://github.com/loriab/libint/blob/new-cmake-2023-take2-b/cmake/libint2-config.cmake.in#L166-L168, and (d) it's especially useful in the libint2::supports function.

On the other hand, for a max-am-eri=5,4,3 (a) there's about 100 components for eri, so that's going to be excessive multiplied by all the operators and (b) there's a lot of redundancy (e.g., --enable-g12 provides cgtg, cgtg_x_coulomb, delcgtg2).

Am I thinking about this right? I don't prefer to have them diverge, but it might be that your proposal is right for l2::supports but not for the cmake components role.

loriab commented 8 months ago

Ok, I'm still not clear on your plan for the non-eri components. But since components aren't being used at all at the moment, perhaps rolling out eri now for a trial and revisiting the full set of non-eri later is ok? To that end, I made some edits so that the present components are consistent with the future expansion.

multipole gets 2-center and deriv, so now multipole_hh_dD
onebody gets 2-center, so now onebody_hh_dD
g12 gets 4-center, so now g12_hhhh_dD

Does that seem good, or do you want me to alias the operators in l2::supplies (e.g., user queries for yukawa_hh_d0, and fn looks up eri_hh_d0)?

I've added a little generation script for the components. Input is crude, but I didn't want it too fancy since it'll be fed by cmake later on.

I also tweaked some shorderings comments in engine.h

evaleev commented 8 months ago

multipole gets 2-center and deriv, so now multipole_hh_dD

onebody gets 2-center, so now onebody_hh_dD

g12 gets 4-center, so now g12_hhhh_dD

Does that seem good, or do you want me to alias the operators in l2::supplies (e.g., user queries for yukawa_hh_d0, and fn looks up eri_hh_d0)?

probably too much ... this functionality is for experts, who presumably will read the dox. Enough to state in the dox that eri implies general Boys function-based evaluation of integrals over distance-dependent 2-particle interactions and can be used to compute Yukawa, Slater, erf-attenuated Coulomb, etc.

I've added a little generation script for the components. Input is crude, but I didn't want it too fancy since it'll be fed by cmake later on. I also tweaked some shorderings comments in engine.h

Great, thank you!

I'll have one final lookover, but this is good to go in my opinion.

evaleev commented 7 months ago

~weird, the merge master, even though the branch built fine: https://github.com/evaleev/libint/commit/10ca429217977bc2baac78fdaf3ac8d4f8aa05d9~ nvm, code in https://github.com/evaleev/libint/pull/279 needs to be skipped (or updated) if Gaussian solid harmonic ordering is used

evaleev / libint