VS Code/CMake cannot locate MKL libraries

[wbsteinMSFC]

First issue!

When installing via VS code/CMake, it could not locate MKL libraries eventhough they have been installed (via previous instructions) and have been properly sourced.

Is there a command/area of the cmake that can be hot-wired so that cmake can find it?

[wbsteinMSFC]

I will qualify this with "I'm installing this on a M1 Mac, so the paths maybe different". But following the linux instructions, I get the following error:

[cmake] -- libiomp5.dylib [cmake] -- MKL_INTERFACE_LIBRARY = MKL_INTERFACE_LIBRARY-NOTFOUND [cmake] -- MKL_SEQTHR_LIBRARY = MKL_SEQTHR_LIBRARY-NOTFOUND [cmake] -- MKL_CORE_LIBRARY = MKL_CORE_LIBRARY-NOTFOUND [cmake] -- MKL_TBB_LIBRARY = [cmake] -- MKL_OMP_LIBRARY = /opt/intel/oneapi/compiler/latest/mac/compiler/lib/libiomp5.dylib [cmake] CMake Error at /opt/local/share/cmake-3.24/Modules/FindPackageHandleStandardArgs.cmake:230 (message): [cmake] Could NOT find MKL (missing: MKL_LIBRARIES MKL_INCLUDE_DIRS [cmake] MKL_INTERFACE_LIBRARY MKL_SEQTHR_LIBRARY MKL_CORE_LIBRARY) [cmake] Call Stack (most recent call first): [cmake] /opt/local/share/cmake-3.24/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE) [cmake] cmake/FindMKL.cmake:237 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) [cmake] CMakeLists.txt:213 (find_package)

So far everything else has worked fine!

[jasonmeverett]

Have you tried updating your LD_LIBRARY_PATH environment variable to include the OneAPI lib directory before running CMake? Not sure how to do this through VSCode though

[wgledbetter]

This happens because VSCode spins up a new terminal instance each time it executes CMake. You have a couple options.

1. You could put source /opt/intel/oneapi/setvars.sh into your .bashrc or .zshrc or the config file for whatever default terminal you're using. This is the simplest answer, but it's not my favorite because it pollutes any terminal you open on your machine.
2. You can do what you suggested and hot-wire VSCode to automatically source this file when it calls cmake. I stole this solution from https://stackoverflow.com/a/64462451.

Create a file scripts/mklCmake.sh with the following contents:

#!/bin/bash
source /opt/intel/oneapi/setvars.sh
cmake "$@"

Then put

{
  "cmake.cmakePath": "scripts/mklCmake.sh"
}

into /wherever/you/cloned/asset/.vscode/settings.json

[wbsteinMSFC]

Hey man!

No. I added it to my zsh, no dice (various versions of the mkl path). I did figure out and then directly modify the CMakeCache.txt file. Added:

//Path to a library. MKL_CORE_LIBRARY:FILEPATH=/opt/intel/oneapi/mkl/2023.0.0/lib/

//Path to a file. MKL_INCLUDE_DIR:PATH=/opt/intel/oneapi/mkl/2023.0.0/include

//Path to a library. MKL_INTERFACE_LIBRARY:FILEPATH=/opt/intel/oneapi/mkl/2023.0.0/interfaces

//Path to a library. MKL_OMP_LIBRARY:FILEPATH=/opt/intel/oneapi/compiler/latest/mac/compiler/lib/libiomp5.dylib

//Path to a library. MKL_SEQTHR_LIBRARY:FILEPATH=/opt/intel/oneapi/mkl/2023.0.0/lib/

Now it seems happy, er. Something else broke. but that's not unexpected since I'm on an M1.

[wbsteinMSFC]

Thanks! That makes sense.

[jasonmeverett]

After working on Docker implementation w/ conda's MKL and MKL Headers, another option is to set MKLROOT before running CMake. As per FindMKL.cmake, this is the environment variable used to find MKL.

Into .bashrc or equivalent:

export MKLROOT=/path/to/MKL

[jasonmeverett]

Also, should this issue be closed?

[wbsteinMSFC]

I dunno. I just figured Mac/M1 would be very niche and a low priority. Until there is an easy path where clang/etc supports the architecture in the sameway that was intended by the developers, I’m not sure there is a way forward.

If you’d like to repopen it feel free. You guys are the boss :D

    William Stein
    Mission Analysis and Optimization Tech Fellow
    Jacobs Space Exploration Group | ESSCA Contract
    (256).961.1437 (o)
    ***@***.***

From: jasonmeverett @.> Reply-To: AlabamaASRL/asset_asrl @.> Date: Sunday, January 8, 2023 at 11:25 AM To: AlabamaASRL/asset_asrl @.> Cc: William Stein @.>, Author @.***> Subject: [EXTERNAL] Re: [AlabamaASRL/asset_asrl] VS Code/CMake cannot locate MKL libraries (Issue #5)

Also, should this issue be closed?

— Reply to this email directly, view it on GitHubhttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAlabamaASRL%2Fasset_asrl%2Fissues%2F5%23issuecomment-1374886168&data=05%7C01%7Cwilliam.b.stein%40nasa.gov%7Caf93a1051cc747c58d6d08daf19d4825%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638087955072251297%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YpbXbIk8YhR0aVXt5xu3YajDtPVMKfxg9Wqh9v2qsDk%3D&reserved=0, or unsubscribehttps://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FA5B453FJD264BTKUYX2LTK3WRLZ6VANCNFSM6AAAAAATP2SHCA&data=05%7C01%7Cwilliam.b.stein%40nasa.gov%7Caf93a1051cc747c58d6d08daf19d4825%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638087955072251297%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XamjSOMyzmL1Odt9S1kTSr4U2ifBQ2AtiW%2FxeuyYiSU%3D&reserved=0. You are receiving this because you authored the thread.Message ID: @.***>

[jasonmeverett]

@jbpezent what kind of effort would it be to build an OpenBLAS implementation or equivalent to dodge MKL dependency?

[jbpezent]

@jasonmeverett , Enormous. We are using MKL PARDISO as the symmetric-indefinite linear solver inside the optimizer. From our testing it was significantly faster than the other freely available alternatives that could use an alternative BLAS backend(ex: MUMPS and MA-27). MA-57 and MA-86 are supposed to have similar performance but have weird licensing requirements for non-academic users. So we cant really replace MKL PARDISO without either incurring a significant performance loss or requiring users to acquire commercial/licensed software.

A long term goal is to write our own replacement symmetric-indefinite linear solver that uses Eigen as its BLAS backend with the option to also use MKL or OpenBLAS. This would also liberate us from x86 processors, and allow asset to run on Arm and M1 Macs. However, significant R&D would be required to develop something that even comes close to being as fast as MKL PARDISO.