BLAS (MKL) not found in Trilinos

[davydden]

CMake Error at cmake/tribits/core/package_arch/TribitsProcessEnabledTpl.cmake:127 (MESSAGE):
  ERROR: TPL_BLAS_NOT_FOUND=TRUE, aborting!

i don't know the internals, but perhaps there should be some ENV variable with blas linking flags.

p.s. i do have MKL=ON in project-deal.II.cfg.

[davydden]

doing something like BLAS_LAPACK="-L${MKLROOT}/lib/intel64  -lmkl_rt -lpthread -lm" in project-deal.ii.cfg and then using it -DTPL_BLAS_LIBRARIES=${BLAS_LAPACK} solves the issue.

I don't know how to do complex logic in bash script, but ideally one would check if environment variable is set and if so, provide -DTPL_BLAS_LIBRARIES during trilinos config.

[tjhei]

Agreed. What kind of system are you on and do you want to use MKL with gcc?
There is a blob in dealii-prepare.package:

if [[ ${MKL} == ON ]]; then
  TRILINOS_CONFOPTS=" \
  ${TRILINOS_CONFOPTS} \
  -D BLAS_LIBRARY_NAMES:STRING='mkl_core;mkl_sequential' \
  -D LAPACK_LIBRARY_NAMES:STRING=mkl_intel_lp64 \
  "
fi

[davydden]

i do ./candi.sh deal.II/platforms/supported/linux_cluster.platform and it skips dealii-prepare.package, hm 😄 , perhaps it shouldn't.

I am trying to compile on this cluster. The have CentOS and only MKL. I try compiling with OpenMPI (by gcc) and MKL so far as the the whole script is tested with GCC only.

[davydden]

It seems one has to set up BLAS_DIR and LAPACK_DIR in project-deal.ii.cfg and then Trilinos picks up MKL.

I still have a lot of undefined symbols, but perhaps the local MKL is somewhat incomplete

Linking CXX executable Amesos2_klu2_simple.exe
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `zgetri_'
../../../../../epetra/src/libepetra.so.12.2.1: undefined reference to `dgerfs_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `zgemm_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `dorm2r_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `sormqr_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `cgemv_'
../../../../../epetra/src/libepetra.so.12.2.1: undefined reference to `sdot_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `sgebak_'
../../../../../epetra/src/libepetra.so.12.2.1: undefined reference to `slarft_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `zgetrs_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `claswp_'
../../../../../epetra/src/libepetra.so.12.2.1: undefined reference to `dgeequ_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `ztrexc_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `sgbequ_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `zgeqrf_'
../../../../../epetra/src/libepetra.so.12.2.1: undefined reference to `sormhr_'
../../../../../epetra/src/libepetra.so.12.2.1: undefined reference to `sgeevx_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `dlatrs_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `dggev_'
../../../../../epetra/src/libepetra.so.12.2.1: undefined reference to `dgeqrf_'
../../../../../epetra/src/libepetra.so.12.2.1: undefined reference to `daxpy_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `zgemv_'
../../../../../epetra/src/libepetra.so.12.2.1: undefined reference to `dgehrd_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `zgehrd_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `zlarfg_'
../../../../../teuchos/numerics/src/libteuchosnumerics.so.12.2.1: undefined reference to `zgetrf_'
../../../../../epetra/src/libepetra.so.12.2.1: undefined reference to `idamax_'
(and many more...)

[davydden]

i wiped trilinos building dir and it seemed to work.
I guess for a moment the best way is to add a note around MKL=ON that BLAS_DIR and LAPACK_DIR have to set accordingly.

[koecher]

The MKL functionality was implemented by @Rombur never tested this personally.
Indeed, you have to call deal.II-prepare, since I have moved out code from the deal.II configure file into that. Note "skip" is the correct way, since it does not install anything or create folders.
Somewhat unhandy but coming without any additional notation.

[Rombur]

@davydden yes, when you are on a cluster you need to set BLAS_DIR and LAPACK_DIR, this is true even if you don't use MKL. The problem is that Trilinos can never find blas and lapack on a cluster (or at least I have never had the chance to work with a cluster where it worked). MKL=ON just select the right flags for the compiler.