We should generalize CMake for BLAS/LAPACK use

[mathomp4]

In the LDAS, namely landpert, we have:

if (NOT CMAKE_Fortran_COMPILER_ID MATCHES "NAG")
   target_compile_definitions(${this} PRIVATE MKL_AVAILABLE)
endif ()

This should be better generalized. In the future, we might move to, say, Flang for Fortran and there is no MKL interface to Flang like there is for GNU.

Also, in landassim code we have:

! use intel mkl lapack when available
#ifdef MKL_AVAILABLE
#include "lapack.f90"
#endif


module enkf_general
  
#ifdef MKL_AVAILABLE
  use lapack95, only: getrf, getrs
#endif

This isn't even dependent on MKL, just LAPACK (though I guess, LAPACK95). This should also be cleaned up.

I think this shouldn't be too hard, but I'll need to try things out. I'm guessing we can go off of BLA_VENDOR but I'm not sure.

[gmao-rreichle]

@mathomp4, @weiyuan-jiang : I just merged #162 based on your approval. Does #162 address this older issue (158)? If so, we should close the issue. If not, maybe @weiyuan-jiang could take a crack at resolving the outstanding CMake issues. Thanks

cc: @amfox37

[mathomp4]

@gmao-rreichle I mean, I guess it does. I defer to @weiyuan-jiang and you as to whether this is okay? I wasn't sure if trying to run without MKL would just "not work". That is:

1. Do we need to always have lapack to run? If so, we should always have LAPACK around. For non-Intel/GNU compilers, I usually build OpenBLAS.
2. Do we require MKL to run? For example, in random_fields.F90 we have:

! use intel mkl fft when available
#ifdef MKL_AVAILABLE
#include "mkl_dfti.f90"
#else
#define NR_FALLBACK
#endif

but NR_FALLBACK is never used anywhere. So I wasn't sure if we'd just "fail" without MKL.

[weiyuan-jiang]

I think GEOSldas has been run on MKL for a very long time. I don't know if it can run without MKL. Event it does, it would be inefficient

[gmao-rreichle]

Thanks, @mathomp4 and @weiyuan-jiang. I think MKL or LAPACK is only needed when the GEOSldas run includes the ensemble-based land analysis. If we only run a single replicate of the Catchment model without perturbations, MKL/LAPACK is probably not needed. I'm ~99% sure. But I don't know if it's worth pursuing a refinement of this. It may or may not be useful in practice to put in the effort and make GEOSldas build and run without MKL or LAPACK in single-member, model-only config.

Unless I'm hearing otherwise, we may want to leave this alone and focus on other priorities.

cc: @amfox37