Bump version to 2022.05.001

[gdonval]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[gdonval]

@conda-forge-admin, please rerender

[awvwgk]

Thanks for your interest in (co-)maintaining this feedstock.

Looks like the preprocessing on OSX is causing issues again, it needs cpp which I previously sneaked in via gfortran:

elpa-feedstock/recipe/build.sh

Line 28 in 84cd3cc

export FORTRAN_CPP="${FC:-gfortran} -E -P -cpp"

[gdonval]

Thanks for this! I will fix it tomorrow, you've just saved me an hour of work. :)

I have also noticed (unrelated to this) that Elpa was the reason why one of my program segfaults on ivybridge.

If that is OK, I'll probably rework the build script to provide architecture-specific variants. Elpa does not seem do any function multiversioning and looking at the code, which is very "imperative-oriented" if that makes sense, introducing multiversioning would take a tremendous amount of time so I suppose providing variants and defaulting to the generic implementation makes sense.

[awvwgk]

Elpa doesn't provide any micro-arch cross-compiliation features as far as I know, so you have to decide ad hoc which kernels to include and which to set as default, while your kernel features are limited by the build machine micro-arch. As default the most sophisticated kernel is chosen, but can be changed on the user side. In principle you should be able to fallback to the generic kernel with any version of Elpa, at least that is my understanding.

[gdonval]

As default the most sophisticated kernel is chosen, but can be changed on the user side

Elpa literally segfaults on Ivybridge so there is either a bug or selection is done at compile time (skimming through the code, in the midst of a thousand conditions, it looks like this is what is done).

your kernel features are limited by the build machine micro-arch

Well, either compiled code is directly used at compile time to actively limit portability or no one ever cared to compile the kernels with the correct compiler flags. Either way, really nothing these days prevents micro-arch compilation: Openblas, FFTW and BLIS (to give relevant examples) all provide micro-arch-optimised kernels at runtime.

You saved me an hour of looking for things, I'll have a closer look at Elpa to get things work (if indeed uarch selection is a thing).