Portable libint

[susilehtola]

Hi,

it looks like libint2 can be compiled in Nsph x Ncart x Nshell_set = 2 x 5 x 2 = 20 different possible ways. Even though only 5 of these are currently used by major codes, this is a nightmare for distribution packaging, since there's no way we can ship 20 mutually incompatible copies of a library; I'm horrified about shipping even two since it takes forever to compile libint on the Fedora build system.

Would it be possible to modify libint so that the orderings for the cartesians, solid harmonics, and shell sets are set by some function, and libint does all the necessary shuffles behind the scenes? This would be a minimal solution to the problem, since one could still set the default orderings at configure time, thus avoiding any extra shuffles if the compiled ordering matches the wanted one.

[JensWehner]

I think fedora already has a libint2 package. https://fedora.pkgs.org/31/fedora-x86_64/libint2-2.1.0-10.fc31.x86_64.rpm.html

Otherwise I completely agree on this, because at the moment you have to get the package compilation information to understand what is happening. I would like this feature too

[susilehtola]

I think fedora already has a libint2 package. https://fedora.pkgs.org/31/fedora-x86_64/libint2-2.1.0-10.fc31.x86_64.rpm.html

I know, I'm the one who packaged it.

[JensWehner]

Thanks for your work, we are currently trying to get it into opensuse. Especially for CI purposes, having a distribution package really helps, but somehow all distribution packages should be guaranteed to have the same settings.

[loriab]

fwiw, should #148 be merged there would at least be selectors https://github.com/evaleev/libint/pull/148/files#diff-4cfbbb105ca3b371b7251a6e37a56f74R69 so at downstream build time (if building with cmake), a qc program could fend off unsuitable libint2 installations. but that doesn't help the multiple packaging problem.

[JensWehner]

I mean you can also just have a policy decision to say this is the standard ordering, which you get, unless you compile it yourself.

[evaleev]

@susilehtola Yes this can be done if you really think this is necessary. I was not aware of any non-CCA-based consumers of Libint in open-source world though ... are there any?

[loriab]

psi is non-standard for solid harmonic and probably precipitated this thread. (below is harvested from libint wiki notes.) small mercy is that psi differs in the one dimension that can be chosen at library build time, not generator build time.

#                    sh         cart       shell_set  used_by
#                    --------   --------   ---------  -------
#   sss - search for standard + standard + standard = mpqc4, cp2k
#   sso - search for                     + orca
#   sis - search for          + intv3    + standard
#   sio - search for                     + orca
#   sgs - search for          + gamess   + standard = gamess
#   sgo - search for                     + orca
#   sos - search for          + orca     + standard
#   soo - search for                     + orca     = orca
#   sbs - search for          + bagel    + standard = bagel
#   sbo - search for                     + orca
#   gss - search for gaussian + standard + standard = psi4
#   gso - search for                     + orca
#   gis - search for          + intv3    + standard
#   gio - search for                     + orca
#   ggs - search for          + gamess   + standard
#   ggo - search for                     + orca
#   gos - search for          + orca     + standard
#   goo - search for                     + orca
#   gbs - search for          + bagel    + standard
#   gbo - search for                     + orca

EDIT: added cp2k

[susilehtola]

I know cp2k are interested in libint2 too but I don't know which ordering they use.

[evaleev]

I think cp2k uses CCA, since they used libint1 until not too long ago ... perhaps @pseewald can confirm? @pseewald , does CP2K utilize CCA convention for Cartesian and solid harmonic Gaussians?

I see, psi indeed would be a problem then (it uses Gaussian solid harmonic ordering, @loriab ?)

[pseewald]

@pseewald , does CP2K utilize CCA convention for Cartesian and solid harmonic Gaussians?

Yes, CP2K uses the default ordering.

[susilehtola]

Would it be possible to change the ordering in Psi4? 😅

[loriab]

I see, psi indeed would be a problem then (it uses Gaussian solid harmonic ordering, @loriab ?)

Yes, Gaussian solid harmonic ordering. Psi used to do the reordering from libint1 internally, but @andysim has gleefully removed those hundreds of lines of code in the update to libint2.

@susilehtola is the recipe for fedora libint2 publicly accessible? I poked around a bit and failed. Even apart from solid harmonics, I'm curious and concerned about AM levels for derivatives. The generated source tarballs published from GH are energy-only, iirc. It's not final, but I'm building with the below for psi4 now.

        -DLIBINT2_SHGAUSS_ORDERING=gaussian \
        -DLIBINT2_CARTGAUSS_ORDERING=standard \
        -DLIBINT2_SHELL_SET=standard \
        -DENABLE_ERI=2 \
        -DENABLE_ERI3=2 \
        -DENABLE_ERI2=2 \
        -DWITH_ERI_MAX_AM="6;6;5" \
        -DWITH_ERI3_MAX_AM="6" \
        -DWITH_ERI2_MAX_AM="6" \
        -DERI3_PURE_SH=OFF \
        -DERI2_PURE_SH=OFF \

[susilehtola]

@susilehtola is the recipe for fedora libint2 publicly accessible? I poked around a bit and failed. Even apart from solid harmonics, I'm curious and concerned about AM levels for derivatives. The generated source tarballs published from GH are energy-only, iirc. It's not final, but I'm building with the below for psi4 now.

Fedora is free, so yes: https://src.fedoraproject.org/rpms/libint2/blob/master/f/libint2.spec

The annoyance in libint2 is the need for very up to date compilers and libraries, which is why I generate the sources by hand with the script https://src.fedoraproject.org/rpms/libint2/blob/master/f/generate-sources.sh

../configure --enable-shared --disable-static \
  --enable-eri=2 --enable-eri3=2 --enable-eri2=2 \
  --with-eri-max-am=7,5,4 --with-eri-opt-am=3 \
  --with-eri3-max-am=7 --with-eri2-max-am=7 \
  --with-g12-max-am=5 --with-g12-opt-am=3 \
  --with-g12dkh-max-am=5 --with-g12dkh-opt-am=3 \
  --disable-unrolling --enable-generic-code --enable-contracted-ints \
  --with-cxx-optflags="$OPTFLAGS" \

which might be overkill.. but still this is much less than what I used for libint1

--with-libint-max-am=10 --with-libint-opt-am=6 \
--with-libderiv-max-am1=6 --with-libderiv-max-am2=5 \
--with-libr12-max-am=5 --with-libr12-opt-am=4

[andysim]

If Psi4 is the only outlier here, there are a couple of options we can consider. The first would be to use some simple reordering code inside Psi4's Libint2 wrapper, which would leave the conventions unchanged to our end users and allow the "standard" ordering to be used within Libint2. This is a good solution, as long as the reordering step is fast enough (it should be). If that proves to be too slow, we can definitely consider changing the convention used for spherical harmonics - it would be a small change to our cart->spherical transformation code. The latter approach must be done slowly though, as we have a number of users that have developed plugins to interface to all kinds of different codes and some of them will surely depend on the convention used in some way.

[evaleev]

The solids case is easy: we can make the ordering of solids to be specified as an argument to libint2::initialize. There is no need to reorder anything, since the order is specified when transformation matrices from cartesians to solids are precomputed.

The cartesians case is harder because there will be necessarily reordering. How about we just leave this case as is since no open-source packaged code uses non-CCA cartesians?

Ditto for am shellset order (only ORCA needs the nonstandard order).

[andysim]

That sounds like a great solution to me :)

[loriab]

• Thanks for the future SH toggle, @evaleev, that sounds like a wonderful solution. I can adapt the Libint2Config.cmake for one fewer choice when that's ready.

• Thanks for the Fedora formulation, @susilehtola, I think Psi4 can largely work with that. For the largest production build (Linux only), we're going with eri=7;7;4 and eri3=eri2=7;7;5 to cover the internal library for energies and gradients and up to QZ for conv & df Hessians. Notes on acceptable smaller packages are here.

• Collected notes on building Libint2 for Psi4 are here that may be useful for others.

[mbanck]

I think this would be great; Bagel will be the free software outlier then, but (i) the open source version is pretty much abandoned and (ii) all or at least all the unique functionality works fine without libint2.

It would still be nice for people building e.g. gamess not having to rebuild libint2, but standardizing on one configuration for psi4, cp2k and mpqc4 would go a long way.

[mbanck]

Any update on this? Psi4-1.5 came out and (AFAICT) is no longer supportable on Linux distributions due to the non-default libint2 it requires.

[loriab]

Any update on this? Psi4-1.5 came out and (AFAICT) is no longer supportable on Linux distributions due to the non-default libint2 it requires.

@mbanck, correct, psi4 has never worked out-of-the-box with a master libint2 (so not since the libint1 -> 2 transition late 2020). But if it's just the cmake components detection, one can toggle a few cmake lines in psi4 and use a master libint2 if properly configured. I think this is what Susi does for Fedora. The worse problem of psi needing an incompatible configuration from every other open-source QC project remains, but there's new hope on that front.

[mbanck]

My current state is that psi4 detects the system libint2 fine, but then later fails to build like this:

-- Found Libint2 :  (found version 2.7.1)
[...]
-- Configuring done
-- Generating done
[...]
[ 15%] Building CXX object src/psi4/libmints/CMakeFiles/mints.dir/integral.cc.o
cd /build/psi4-3Flsys/psi4-1.5/builddir/psi4-core-prefix/src/psi4-core-build/src/psi4/libmints && /usr/bin/c++ -DDATADIR=\"/usr/share/libint/2.7.1\" -I/build/psi4-3Flsys/psi4-1.5/psi4/include -I/build/psi4-3Flsys/psi4-1.5/psi4/src -isystem /usr/include/eigen3 -g -O2 -ffile-prefix-map=/build/psi4-3Flsys/psi4-1.5=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -g -DNDEBUG -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fopenmp -std=c++14 -MD -MT src/psi4/libmints/CMakeFiles/mints.dir/integral.cc.o -MF CMakeFiles/mints.dir/integral.cc.o.d -o CMakeFiles/mints.dir/integral.cc.o -c /build/psi4-3Flsys/psi4-1.5/psi4/src/psi4/libmints/integral.cc
In file included from /build/psi4-3Flsys/psi4-1.5/psi4/src/psi4/libmints/integral.cc:28:
/usr/include/libint2/cgshell_ordering.h:64:12: error: expected unqualified-id before ‘int’
   64 | inline int INT_NCART(int am) { return ((am + 2) * (am + 1)) >> 1; }
      |            ^~~~~~~~~
/usr/include/libint2/cgshell_ordering.h:64:12: error: expected ‘)’ before ‘int’
[...]

I assumed this was the present issue; if I read your comment right, there should be a way to make cmake work (well it does work), but building against a system libint2 is hopeless?

[loriab]

@mbanck, what are "system libint2"'s configuration characteristics? I may have met your error above before and found it needed an extra set of parenthesis in the l2 header. But unless your system libint2 has these characteristics, psi4 may build, link, and run beautifully and still generate garbage. So not hopeless, but possibly a good deal of work to correct niggling details that won't be long in use. I'd either vendorize l2 within the psi4 package (i.e., use the tarball psi suggests and ship the special l2 with psi) or wait for psi and l2 release and default ordering reconciliation. If need to get into more psi-side technical details, perhaps should move to psi issue.

[susilehtola]

Fedora is still waiting for Psi4 to be ported to the standard shell indexing.

[loriab]

@mbanck , I have now met your psi4 + current libint2 error from #190 (comment) in person. It's fixed in psi4 at psi4/psi4#2413. I wouldn't suggest full-speed-ahead on any particular psi+libint branch combo yet, though.

[loriab]

fwiw, Psi4, as of Wednesday, is now running on #233 (c. 2022) rather than #148 (c. 2019) for Linux, macOS, Windows. This fixes the INT_NCART issue Michael brought up, as well as various dependency detection issues found in the latter by Susi and others. Psi4 at this point is still using gss ordering, not sss (the main point of this issue). #233 hasn't had a chance to be fully endorsed by EFV yet, but I feel it's in pretty good shape (update guide). With that caveat, if anyone wants to try it, I'm glad to start getting reports of CMake problems now. @ryanmrichard I was told you might be interested in a pure CMake L2, so here's a ping.

[loriab]

The strategy suggested in #190 (comment) has been implemented in #259 so that all open-source libint consumers can use the same built library. Psi4 will be adopting this upon psi4/psi4#2861 before the May v1.8 release. There's a library source tarball at https://github.com/loriab/libint/releases/download/v0.1/libint-2.7.2-post1-5-4-3-6-5-4_mm4f12ob2_1.tgz if anyone wants to play around. Please ping me with any problems.

[loriab]

To update any thread readers, the strategy suggested in #190 (comment) has been implemented (without additional cmake changes) in #269 and merged. This allows all open-source libint consumers to use the same built library with standard orderings.

@evaleev, are there any thoughts of tagging a Libint release in the next couple days with or without #273 ? (Tarballs not needed for my part.) It'd be a great relief to get a Psi4 release using a Libint release for the first time since 2019. Thanks for considering.