full cmake 2/N: integral classes and AM configuration #309
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
currently atop #299 . here's the diff of the new stuff: loriab/libint@extras...loriab:libint:intconfigeri_ffff_d0
cmake components. This imitates logic that in L2 lives in build_libint.cc. The component-constructing machinery has been reworked for the new component format, and it wasn't too hard to keep it in cmake and avoid a Python dependency. This makes configuration-gen.py redundant.The only trouble here is that originally I had used both
--with-max-am=N
&--with-max-am=N0,N1,N2
in layers as defaults for ints classes. Whereas I'm pretty sure now that the latter has no role in defaulting (other than setting its max to LIBINT_MAX_AM) and is entirely directed at eri3. So the cmake components printed reflect this layered defaulting and likely not the true ints available. (Given the pattern, the cmake components are underpromising, not underdelivering, at least.) I've left this for now in case I'm mistaken again or in case you prefer this defaulting scheme, but probably it should be ripped out in the end to conform strictly with configure.ac/build_libint.cc .WITH_ONEBODY_[MAX|OPT]_AM
with per-derivN0,N1,N2
option is stated in the current docs and parsed by configure.ac intoONEBODY_MAX_AM_LIST
/ONEBODY_OPT_AM_LIST
and those defines are processed in build_libint.cc. But there's a handoff missing ininclude/libint2/config.h.in
where the LIST never got defined. I've added them in to both the libtoolconfig.h.in
and the WIP cmakeconfig.h.cmake.in
.May 2024 additions
GHA example
part of cmake printout
compare _AM lines in libtool-generated and cmake-generated config.h
empty
MPQC4
c-f/psi4 "basic" for windows
Note that literal translation throws an error: "Invalid value for WITH_MAX_AM (6;5). Highest ENABLE_ derivative (2) requires list length 3, not 2." Input isn't technically wrong since list WITH_MAX_AM likely only relevant for ERI3. But in the interest of catching user slips, I'm leaving the check in and adjusting the input to
WITH_MAX_AM="6;5;5"
.This is an example of how the current CMake defaulting uses the list WITH_MAX_AM to default other classes rather than only using scalar WITH_MAX_AM for defaulting and reserving list WITH_MAX_AM for ERI3 paired: ONEBODY shows max_am=6 for ene and =5 for grad rather than 6 for both. For now, though, this inconsistency is only going to affect the cmake components, not the config.h (comparison below has only the deliberate LIBINT_MAX_AM_LIST difference) or the library.psi4 trial "bigAM" for linux
stress max-am int (new, so REVISED)
stress max-am empty (new, so REVISED)