alternate Libint2

[loriab]

Comment:

tl;dr I've got a Libint that has been more fully configured and has some code extensions, but it's (1) unlikely to get merged into master soon and (2) needed to add another package to conda-forge. I hope to come to some arrangement where it can be supported without interfering with this feedstock and its dependents too much.

Hi @felipeZ, thanks for working on this project. For background, I've been packaging Libint1 and Libint2 for several years for the psi4 channel and project (packages: https://anaconda.org/psi4/libint2/files ; recipe: https://github.com/psi4/psi4meta/tree/master/conda-recipes/libint2). As you're familiar, different libint consumers need different minimum integrals classes, AM, and derivative settings, and worse, different libint consumers need different integrals orderings (evaleev/libint#190). Psi4 has been one of those outliers that can't use default orderings. Sporadically, I've been working on some cmake upgrades at evaleev/libint#259 and have also added some functionality so that orderings-wise at least all open-source projects consuming libint can use the same built library. With this, Psi4 has a chance to be on conda-forge. Prof. Valeev approves of all this in principle -- some of the PR is his work, and we also discussed next steps in person last year -- but he's so busy that I don't think he'll get to reviewing and merging it in the months timeframe.

The library source code is generated with the following conditions. Summarized, all orderings are standard, ints through second derivative are included for onebody and for 4-, 3-, and 2-center ERIs, ints through first derivative are included for F12 methods, ERIs are through AM=5 for energies, AM=4 for gradients, and AM=3 for Hessians. This has been a reasonable configuration for distribution for a couple years. It builds on CI in 2.5/2/6 hours for L/M/W.

    -D LIBINT2_SHELL_SET=standard 
    -D LIBINT2_CARTGAUSS_ORDERING=standard 
    -D LIBINT2_SHGAUSS_ORDERING=standard 
    -D ERI3_PURE_SH=OFF 
    -D ERI2_PURE_SH=OFF 
    -D ENABLE_ERI=2 
    -D ENABLE_ERI3=2 
    -D ENABLE_ERI2=2 
    -D ENABLE_ONEBODY=2 
    -D ENABLE_G12=1 
    -D DISABLE_ONEBODY_PROPERTY_DERIVS=ON 
    -D MULTIPOLE_MAX_ORDER=4 
    -D WITH_G12_MAX_AM=4 
    -D WITH_ERI_MAX_AM="5;4;3" 
    -D WITH_ERI3_MAX_AM="6;5;4" 
    -D WITH_ERI2_MAX_AM="6;5;4" 
    -D WITH_MAX_AM="6;5;4"

I've got a PR at staged-recipes going with Linux, Mac, and Windows builds (conda-forge/staged-recipes#22060).

Putting these packages on conda-forge at all is questionable because the source isn't on upstream master. But I'm going to propose it anyways. I can think of two routes: (1) Use the project name "libint2" and merge the PR from staged-recipes into a separate feedstock. (2) Have a different branch in this repo so that both branches build and produce packages. I'd have to put a fake and old version on it so that the solver isn't tempted to use it in preference to your packages. Ultimately, I expect the cmake and ordering changes to be merged into Libint, and then psi4 can use a future version of this repo, after all downstreams reach an agreement on a useable configuration.

So, sorry for the long description. I wanted to consult with you early so as to not step on your toes as maintainer. Any opinions, preferences, questions? Thanks for considering!

[awvwgk]

Would it make sense to have a build variant defined by conda_build_config.yaml specially for psi4?

# conda_build_config.yaml
libint:
- default
- psi4

This allows to use selectors # [libint == 'psi'] as well as conditionals {% if libint == 'psi4' %} in the meta.yaml to handle the difference between the variants. The build variant could be included in the meta.yaml in the package string:

build:
  string: {{ libint }}_h{{ PKG_HASH }}_{{ PKG_BUILDNUM }}
  run_export:
    - {{ name }} * {{ libint }}_*

And packages can pin it via libint=*=*psi4* similar to how MPI and Cuda currently work on cf. If one variant should be preferred it would be possible to increase the build number artificially for the default variant for example (as done with the nompi_* variant in MPI enabled packages).

[loriab]

The scheme you proposed would likely work, @awvwgk . Wouldn't it need a mutex, too?

I was trying to avoid something that elaborate when the libraries have so few material differences. If it weren't for the not-official-upstream problem, the two downstream libint deps (horton and votca) could easily be relinked to the psi4-compatible one.

I guess calling calling the psi4-compatible on v1.7.3-alpha is a possibility, too. https://conda-forge.org/docs/maintainer/knowledge_base.html#pre-release-builds

[felipeZ]

Hey @loriab I'm very open to changes in the current feedstock. Since I have departed from academia, it makes more sense that someone closer to the community takes over this feedstock

[loriab]

Hi @felipeZ, thanks, I'd be glad to be a maintainer on this feedstock, especially if you're not so actively using its products :-)

I suppose I'm currently favoring the second branch w/i this repo that builds a 2.7.3.alpha, as that keeps the recipes separate, won't solve for the "psi4" one ahead of the stable one, doesn't falsely advertise a fake version, and doesn't promote non-upstream-minted source on the main c-f channel.

[awvwgk]

The scheme you proposed would likely work, @awvwgk . Wouldn't it need a mutex, too?

Since you have the same package name but a different build string it wouldn't need a mutex, two packages pinning different libint2 build strings would automatically conflict.

Only if you would change the package name for the psi4 variant to say libint2-psi4 you would need to create mutex.

[loriab]

When you have a chance, @felipeZ, I think #17 is ready for review. Thanks!