Enable MKL TPL but then CMake Reports BLAS Not Found #101

nmhamster · 2016-01-25T21:59:20Z

Probably not doing this correctly. I have enabled the MKL TPL but when CMake is busy configuring it then reports BLAS is not found. Given that MKL provides BLAS routines at good performance, should this error occur? Is correct to disable BLAS if I am using MKL?

Processing enabled TPL: MKL (enabled explicitly, disable with -DTPL_ENABLE_MKL=OFF)
-- Searching for libs in MKL_LIBRARY_DIRS='/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/lib/intel64'
-- Searching for a lib in the set "mkl_rt":
--   Searching for lib 'mkl_rt' ...
--     Found lib '/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/lib/intel64/libmkl_rt.so'
-- TPL_MKL_LIBRARIES='/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/lib/intel64/libmkl_rt.so'
-- Searching for headers in MKL_INCLUDE_DIRS='/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/lib/intel64'
-- Searching for a header file in the set "mkl.h":
--   Searching for header 'mkl.h' ...
--     Found header '/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/include/mkl.h'
-- Found TPL 'MKL' include dirs '/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/include'
-- TPL_MKL_INCLUDE_DIRS='/home/projects/x86-64-knl/intel/compilers/2016/compilers_and_libraries_2016.1.150/linux/mkl/include'
Processing enabled TPL: Pthread (enabled explicitly, disable with -DTPL_ENABLE_Pthread=OFF)
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
Processing enabled TPL: MPI (enabled explicitly, disable with -DTPL_ENABLE_MPI=OFF)
Processing enabled TPL: BLAS (enabled by TeuchosNumerics, disable with -DTPL_ENABLE_BLAS=OFF)
-- Searching for libs in BLAS_LIBRARY_DIRS=''
-- Searching for a lib in the set "blas blas_win32":
--   Searching for lib 'blas' ...
--   Searching for lib 'blas_win32' ...
-- ERROR: Did not find a lib in the lib set "blas blas_win32" for the TPL 'BLAS'!
-- ERROR: Could not find the libraries for the TPL 'BLAS'!
-- TIP: If the TPL 'BLAS' is on your system then you can set:
     -DBLAS_LIBRARY_DIRS='<dir0>;<dir1>;...'
   to point to the directories where these libraries may be found.
   Or, just set:
     -DTPL_BLAS_LIBRARIES='<path-to-libs0>;<path-to-libs1>;...'
   to point to the full paths for the libraries which will
   bypass any search for libraries and these libraries will be used without
   question in the build.  (But this will result in a build-time error
   if not all of the necessary symbols are found.)
-- ERROR: Failed finding all of the parts of TPL 'BLAS' (see above), Aborting!

-- NOTE: The find module file for this failed TPL 'BLAS' is:
     /home/sdhammo/git/trilinos-github-repo/cmake/tribits/common_tpls/FindTPLBLAS.cmake
   which is pointed to in the file:
     /home/sdhammo/git/trilinos-github-repo/TPLsList.cmake

TIP: One way to get past the configure failure for the
TPL 'BLAS' is to simply disable it with:
  -DTPL_ENABLE_BLAS=OFF
which will disable it and will recursively disable all of the
downstream packages that have required dependencies on it, including
the package 'TeuchosNumerics' which triggered its enable.
When you reconfigure, just grep the cmake stdout for 'BLAS'
and then follow the disables that occur as a result to see what impact
this TPL disable has on the configuration of Trilinos.

CMake Error at cmake/tribits/core/package_arch/TribitsProcessEnabledTpl.cmake:127 (MESSAGE):
  ERROR: TPL_BLAS_NOT_FOUND=TRUE, aborting!
Call Stack (most recent call first):
  cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake:1556 (TRIBITS_PROCESS_ENABLED_TPL)
  cmake/tribits/core/package_arch/TribitsProjectImpl.cmake:209 (TRIBITS_PROCESS_ENABLED_TPLS)
  cmake/tribits/core/package_arch/TribitsProject.cmake:93 (TRIBITS_PROJECT_IMPL)
  CMakeLists.txt:90 (TRIBITS_PROJECT)

The text was updated successfully, but these errors were encountered:

bmpersc · 2016-01-25T22:26:25Z

Disabling blas and lapack would be a bad idea. Instead when using a library like MKL that provides those libraries as part of a large set of tools you'll need to tell Trilinos that the blas and lapack libraries are included in that set. Unfortunately that often means setting up a few variables with very long strings to match what the MKL link helper recommends. I found an example from the Trilinos sampleScripts dir. I can't speak to if this snippet still works, but it should give you an idea on which variables you need to set and with which libraries or paths. I pulled this specific snippet from linux-eleanor-gcc-4.1.2-mpi-cmake, there are others in the sampleScripts dir that you may want to look at.

-D BLAS_LIBRARY_DIRS:STRING="/usr/local/intel/Compiler/11.1/064/mkl/lib/em64t;/usr/local/intel/Compiler/11.1/064/lib/intel64;/usr/lib64"
-D BLAS_LIBRARY_NAMES:STRING="mkl_intel_lp64; mkl_intel_thread; mkl_core; iomp5; pthread"
-D LAPACK_LIBRARY_DIRS:STRING="/usr/local/intel/Compiler/11.1/064/mkl/lib/em64t;/usr/local/intel/Compiler/11.1/064/lib/intel64;/usr/lib64"
-D LAPACK_LIBRARY_NAMES:STRING="mkl_intel_lp64; mkl_intel_thread; mkl_core; iomp5; pthread" \

jhux2 · 2016-01-25T22:51:27Z

Si,
I do pretty much what Brent suggested, and it works for me:

setenv BLAS_LIBRARY_DIRS /opt/intel/composer_xe_2013_sp1.4.211/mkl/intel64;/usr/lib64
setenv BLAS_LIBRARY_NAMES mkl_intel_lp64; mkl_intel_thread; mkl_core; iomp5; pthread
setenv LAPACK_LIBRARY_DIRS /opt/intel/composer_xe_2013_sp1.4.211/mkl/intel64;/usr/lib64
setenv LAPACK_LIBRARY_NAMES mkl_intel_lp64; mkl_intel_thread; mkl_core; iomp5; pthread

-D BLAS_LIBRARY_DIRS:PATH="${BLAS_LIBRARY_DIRS}"
-D BLAS_LIBRARY_NAMES:STRING="${BLAS_LIBRARY_NAMES}"
-D LAPACK_LIBRARY_DIRS:PATH="${LAPACK_LIBRARY_DIRS}"
-D LAPACK_LIBRARY_NAMES:STRING="${LAPACK_LIBRARY_NAMES}" \

nmhamster · 2016-01-25T22:59:38Z

Guys, thanks for your help I am modifying my scripts to do this but in general but I think this is something close to a usability bug. Can we not have MKL, ESSL/PESSL etc be resolved as the BLAS and LAPACK inputs?

mhoemmen · 2016-01-26T00:25:16Z

"MKL TPL" should really refer to the C / C++ API that MKL provides, not to the BLAS and LAPACK libraries (which come in through the linker, not through header files). Failure to detect MKL header files shouldn't disable the BLAS and LAPACK if CMake can find the latter, right?

nmhamster · 2016-01-26T00:43:50Z

I think if MKL is found it should set the BLAS and LAPACK flags unless I override them because that gives me the fastest code. I talked with Mike about how I should feedback these kind of issues, he had suggested that I put these in as bugs so we can have a conversation about possible fixes. If MKL isn't found then standard BLAS and LAPACK dependency checking should be performed. In the end, I want a build system that does the best thing for performance if we can get to that?

bmpersc · 2016-01-26T00:56:04Z

Mark, Finding (or not) MKL doesn't actually affect blas/lapack in anyway they are completely orthogonal in Tribits. The recommendation to disable blas came from Tribits which is trying to be useful here. When it detects that there is no blas library (in its narrow definition) it suggests a couple options, provide library paths or disable it. Clearly disabling isn't the right choice for blas though. However, on other TPLs this could be very good advice.

As for Si's suggestion of if MKL is found we should use that for blas and lapack. This is a good idea, however, in our current implementation very difficult. If we were to use CMake's find_package on blas and lapack it would be much easier to have logic like that. In fact it looks like the default cmake find logic for blas might already do this.

maherou · 2016-01-26T01:03:47Z

Si,

Thanks for being proactive and filing issues. This is the right approach. All of these messages become searchable and help us build a body of knowledge, in addition to clarifying misconceptions and resolving the issue at hand.

Mike

On Jan 25, 2016, at 6:56 PM, Brent Perschbacher [email protected] wrote:

Mark, Finding (or not) MKL doesn't actually affect blas/lapack in anyway they are completely orthogonal in Tribits. The recommendation to disable blas came from Tribits which is trying to be useful here. When it detects that there is no blas library (in its narrow definition) it suggests a couple options, provide library paths or disable it. Clearly disabling isn't the right choice for blas though. However, on other TPLs this could be very good advice.

As for Si's suggestion of if MKL is found we should use that for blas and lapack. This is a good idea, however, in our current implementation very difficult. If we were to use CMake's find_package on blas and lapack it would be much easier to have logic like that. In fact it looks like the default cmake find logic for blas might already do this.

—
Reply to this email directly or view it on GitHub.

ambrad · 2016-01-27T04:50:47Z

This might be an abuse of the *_LIBRARIES flags, but I've had success with this approach:

-D TPL_ENABLE_MKL=ON \
-D MKL_LIBRARY_DIRS="$MKL_LIB/intel64" \
-D TPL_ENABLE_BLAS=ON \
-D TPL_ENABLE_LAPACK=ON \
-D TPL_BLAS_LIBRARIES='-mkl' \
-D TPL_LAPACK_LIBRARIES='-mkl' \

mhoemmen · 2016-02-19T19:37:18Z

If we were to use CMake's find_package on blas and lapack it would be much easier to have logic like that.

Hi Brent! It looks like you're saying that if CMake finds the BLAS and LAPACK, and finds out that they are the MKL, then CMake should look for the MKL header files and other libraries, and enable the MKL TPL if it exists. Is that right?

bartlettroscoe · 2016-03-18T23:04:07Z

This might also be resolved if the FIND_PACKAGE(BLAS) default could be fixed (see TriBITSPub/TriBITS#89). Changing any default behavior for Trilinos (if it is to fix things) becomes very hard given the large number of customers that depend on existing behavior.

mhoemmen · 2016-03-19T05:20:16Z

Changing any default behavior for Trilinos (if it is to fix things) becomes very hard given the large number of customers that depend on existing behavior.

Easy fix (@nmhamster would this help?): If MKL is detected but BLAS / LAPACK not, configure should error out. That prevents surprise. What do you think?

SWMANGO-FACE · 2016-07-09T21:23:56Z

open; TribitsProcessEnabledTpl.cmake
move to, end of script:

# Assert that the TPL correctly defined all of these varaibles.
ASSERT_DEFINED(TPL_${TPL_NAME}_INCLUDE_DIRS)
ASSERT_DEFINED(TPL_${TPL_NAME}_LIBRARIES)
ASSERT_DEFINED(TPL_${TPL_NAME}_LIBRARY_DIRS)
# ToDo: Make TPL_${TPL_NAME}_LIBRARY_DIRS go away.  It is not needed for
# anything.

ENDIF()

ENDFUNCTION()
)
)

after make and make install, a new problem arises.

mhoemmen · 2017-10-22T19:03:44Z

@nmhamster I think this got auto-closed; would you consider this fixed? If so, I'll leave it.

nmhamster mentioned this issue Feb 19, 2016

KokkosKernels,Tpetra: Plug in TPLs (MKL, cuSPARSE, ...) for sparse matrix-vector multiply #147

Closed

jhux2 added impacting: configure or build The issue is primarily related to configuring or building type: enhancement Issue is an enhancement, not a bug Framework tasks Framework tasks (used internally by Framework team) labels Mar 3, 2016

dridzal mentioned this issue Jun 24, 2016

ROL: Reduce cost of BASIC pre-push test suite a little #462

Closed

jgfouca mentioned this issue Jul 6, 2016

Panzer stk conversion2 #486

Merged

william76 closed this as completed in f22b914 Oct 20, 2017

trilinos-autotester mentioned this issue Nov 4, 2021

Trilinos Master Merge PR Generator: Auto PR created to promote from master_merge_20211030_000551 branch to master #9887

Closed

trilinos-autotester mentioned this issue Nov 23, 2021

Framework: Initial infrastructure for weaver PR build #9946

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enable MKL TPL but then CMake Reports BLAS Not Found #101

Enable MKL TPL but then CMake Reports BLAS Not Found #101

nmhamster commented Jan 25, 2016

bmpersc commented Jan 25, 2016

jhux2 commented Jan 25, 2016

nmhamster commented Jan 25, 2016

mhoemmen commented Jan 26, 2016

nmhamster commented Jan 26, 2016

bmpersc commented Jan 26, 2016

maherou commented Jan 26, 2016

ambrad commented Jan 27, 2016

mhoemmen commented Feb 19, 2016

bartlettroscoe commented Mar 18, 2016

mhoemmen commented Mar 19, 2016

SWMANGO-FACE commented Jul 9, 2016

mhoemmen commented Oct 22, 2017

Enable MKL TPL but then CMake Reports BLAS Not Found #101

Enable MKL TPL but then CMake Reports BLAS Not Found #101

Comments

nmhamster commented Jan 25, 2016

bmpersc commented Jan 25, 2016

jhux2 commented Jan 25, 2016

nmhamster commented Jan 25, 2016

mhoemmen commented Jan 26, 2016

nmhamster commented Jan 26, 2016

bmpersc commented Jan 26, 2016

maherou commented Jan 26, 2016

ambrad commented Jan 27, 2016

mhoemmen commented Feb 19, 2016

bartlettroscoe commented Mar 18, 2016

mhoemmen commented Mar 19, 2016

SWMANGO-FACE commented Jul 9, 2016

mhoemmen commented Oct 22, 2017