[cmake] use wfn91's linear algebra discovery modules

[evaleev]

No description provided.

[wavefunction91]

@evaleev This passes all CI except for Travis + clang (which is not a problem in the build, it's a problem in the Ubuntu packages). Do we want to fix the Travis build, or take Gitlab as being indicative of it working?

[evaleev]

@wavefunction91 I think this is ready. I'm pretty sure my updates of the dox (INSTALL.md) are not 100% correct (does your kit respect BLA_STATIC?), but are mostly there

[wavefunction91]

We have BLAS_PREFERS_STATIC, but I can add a BLA_STATIC compatibility if you'd prefer

[wavefunction91]

We don't use BLA_VENDOR, we set a priority list BLAS_PREFERENCE_LIST which will have the same effect as BLA_VENDOR when set to a single item. We do this to decouple LAPACK/BLAS (e.g. in the case of BLIS + NETLIB / BLIS + FLAME), but due to the hierarchy discovery, allowing full discovery (e.g. setting BLAS_PREFERENCE_LIST="IntelMKL" and letting FindLAPACK satisfy the FindBLAS dependency and recognize that it contains a LAPACK linker) will do the right thing.

We could add a BLA_VENDOR <-> BLAS_PREFERENCE_LIST compatibility, or you propagate in the VG CMake kit, which ever you prefer

[evaleev]

I think it is least surprising to emulate Find{BLAS,LAPACK} as much as reasonable, no?

[evaleev]

i.e. I think it's reasonable to read same input vars as those, i.e. read BLA_{VENDOR,STATIC}

[wavefunction91]

I suppose that is the least surprising behaviour, I'll patch that today

[wavefunction91]

This would be covered by BLAS_PREFERS_STATIC

[wavefunction91]

@evaleev Kitware compatibility is added in wavefunction91/linalg-cmake-modules@510b928 , we should just need to bump the version in vg-kit. This will allow for BLA_STATIC -> {BLAS,LAPACK,ScaLAPACK}_PREFERS_STATIC emulation. Same goes for BLA_VENDOR, but as we've discussed offline, this generally leads to ambiguity in the cases where BLAS/LAPACK interoperability is desired

The following are the allowed specs for XXX_PREFERENCE_LIST:

XXX=BLAS

• ReferenceBLAS (NETLIB)
• IntelMKL
• IBMESSL
• BLIS
• OpenBLAS
• Accelerate

XXX=LAPACK

• ReferenceLAPACK (NETLIB)
• FLAME

[evaleev]

@wavefunction91 OK, thanks, will do

[evaleev]

@evaleev Kitware compatibility is added in wavefunction91/linalg-cmake-modules@510b928 , we should just need to bump the version in vg-kit.

done

The following are the allowed specs for XXX_PREFERENCE_LIST:

XXX=BLAS

• ReferenceBLAS (NETLIB)
• IntelMKL
• IBMESSL
• BLIS
• OpenBLAS
• Accelerate

XXX=LAPACK

• ReferenceLAPACK (NETLIB)
• FLAME

Does the user need to specify {LAPACK,ScaLAPACK}_PREFERENCE_LIST in the case BLAS_PREFERENCE_LIST= IntelMKL? I.e. does the latter imply that only IntelMKL will be considered when searching for LAPACK and ScaLAPACK?

[wavefunction91]

@evaleev The user should not have to specify {Sca,}LAPACK_PREFERENCE_LIST for MKL. Take ScaLAPACK for example (since its the highest up on the stack) - if unguided discovery is used, then it will go like

1. FindScaLAPACK -> no ScaLAPACK_LIBRARIES are set, so it looks for LAPACK
2. FindLAPACK -> no LAPACK_LIBRARIES are set, looks for BLAS
3. FindBLAS -> no BLAS_LIBRARIES are set, goes through BLAS_PREFERENCE_LIST, finds IntelMKL, propagates IntelMKL_LIBRARIES to BLAS_LIBRARIES. Because ScaLAPACK was requested, it also tacks on the BLACS/ScaLAPACK MKL linker (+ MPI), which is non-trivial (which is why it's important to ask for the highest level of the stack desired so it can propagate down to Find<VENDOR> if need be)
4. FindLAPACK -> recognizes that it found BLAS, checks for LAPACK linker in BLAS_LIBRARIES, this will be successful for MKL and will propagate BLAS_LIBRARIES (and associated variables) to LAPACK_LIBRARIES
5. FindScaLAPACK -> recognizes that it found LAPACK, checks for ScaLAPACK linker in LAPACK_LIBRARIES (which will work for MKL) and propagates to ScaLAPACK_LIBRARIES, etc.

[evaleev]

@wavefunction91 sorry for wasting your time ... since the proper thing will be to interpret BLA_VENDOR rather than just passing it on as BLAS_PREFERENCE_LIST it's probably best to just use your kit's vars directly ... only realized this after seeing what happens when BLA_VENDOR used with standard CMake module is used with your kit: https://gitlab.com/ValeevGroup/tiledarray/-/jobs/1291849639#L538 ... I propose we avoid the use of BLA_VENDOR to avoid these kinds of issues.