CMake/LAPACK/BLAS: removed customized/diverged standard modules

[hfp]

• Related: f9dca07, cmake: removed standard modules #890
• Changes like picking the correct OpenBLAS threading layer must be upstreamed (CMake).
• It can be considered micro-management to prevent inconsistent choices/pickup.
• Spack solves this with threads=openmp variant and prevents inconsistency.
• Current CMakeFile, standard modules, and Spack are "good enough".

[alazzaro]

unrelated question:
@hfp do we need to make a new release of DBCSR for the new CP2K?

[hfp]

unrelated question: @hfp do we need to make a new release of DBCSR for the new CP2K?

I think so. Perhaps @oschuett can shed some light on the timeline? I think CMake and Spack packages can still use a bit more time. For instance, I started polishing Spack packages for DBCSR and CP2K. Regarding CMake, I think CP2K's custom modules for all LAPACK/BLAS shall go away for same reasons like this PR. While I am nearly complete with Spack packages, I have only started today with the mentioned removal for CP2K.

[hfp]

RPM builds are failing because of:

rm cmake/FindBLAS.cmake cmake/FindLAPACK.cmake
rm: cannot remove 'cmake/FindBLAS.cmake': No such file or directory
rm: cannot remove 'cmake/FindLAPACK.cmake': No such file or directory

This seems to be specified in dbcsr.spec, which is outside of this repository.

[hfp]

@dev-zero FYI, I will soon PR a revised Spack recipe for LIBINT. Would you be so kind and review it as well?

[hfp]

@alazzaro let's get this reviewed on a finite timeline. On an alternative path, you can pre-release DBCSR in anticipation of an upcoming release of CP2K.

@alazzaro @oschuett I think, this sort of coupling can drop going forward as soon as the build systems consolidate in CP2K (gmake vs cmake), and as soon as Spack adoption is covering the classic Toolchain.

On a side note, I am working on Spack recipes for CP2K and DBCSR as well as important dependencies like LIBINT and LIBXC to ensure performance and satisfaction carries forward from GNU Make and Toolchain.

[alazzaro]

@alazzaro let's get this reviewed on a finite timeline. On an alternative path, you can pre-release DBCSR in anticipation of an upcoming release of CP2K.

Given the current schedule for the next CP2K release (cp2k/cp2k#4249 (comment)), it would be impossible to make a new release and validate it in CP2K in a week. On the other hand, DBCSR is now an external dependency so we will make a new release at our convenience.

Considering this PR, I would like to understand if the concerns in #890 are now solved?

[hfp]

My concerns are solved in the sense that the local CMake modules were rapidly aging. For instance, they did not deal correctly with Intel oneMKL, but I think this was only the first sign.

The remaining concern, raised with #890, was about linking an incorrect OpenBLAS library flavor, i.e., Pthread based instead of OpenMP. This was originally raised perhaps by bug report(s) with user environments having "some" OpenBLAS library installed.

Even CP2K's toolchain (building the desired OpenBLAS flavor and linking it) as well as Spack based builds explicitly ensure the desired combination. I think starting from a custom/user environment puts people on their own road and we do not have to provide or maintain fixes for such cases (especially since there are many more traps and issues like inconsistent choices).

I don't know if is worth checking what CMake's BLAS module does in the current release like supporting a correct choice. What we can do is testing DBCSR build on Alps to make a sane choice say with respect to libsci. I think we test this for DBCSR when used with CP2K like Alps CI but not by ourself. @alazzaro Maybe we should have CI on Alps for DBCSR?

[hfp]

Given the current schedule for the next CP2K release (cp2k/cp2k#4249 (comment)), it would be impossible to make a new release and validate it in CP2K in a week. On the other hand, DBCSR is now an external dependency so we will make a new release at our convenience.

Maybe let's put this PR aside wrt CP2K release. It would be still good to include changes since last release of DBCSR given the legacy build system is present for another version of CP2K. How about a minor release of DBCSR?