Building psi4 installation with intel oneAPI

How can I use oneAPI for building psi4 installation using CMake? I am trying to build this on my workstation with an intel octa-core processor. I want to use intel’s C/C++ compilers and MKL for psi4 and also link the same with numpy. Has anyone tried this before?

Depends on which oneAPI C/C++ compilers. If you get the Base Toolkit, that’ll provide icx and icpx. Maybe one person has built psi with these new compilers. The interest is there, but we haven’t devoted much attention to it. If you additionally install the HPC Toolkit, that’ll provide the classic compilers icc and icpc. No problem at all using these to build Psi4. I’ve done it plenty, and there’s no difference from Intel compilers gotten by other than oneapi means. It even comes with a conda environment for Py, numpy, etc. You can probably install psi4-dev pkg into there and use the usual psi4-path-advisor --intel to get a cmake configure line. Or use, the Intel, and the Deps cmake files to build your own line.

I have both the Base and HPC Toolkits installed, and now, I wonder if building psi4 with these compilers would be any different from the versions available on a conda environment. But, there seems to be some incentive with compilers(icx/icpx/dpcpp) provided by intel. (This is the nearest to a benchmark test that I could find online that compares different compilers: A Performance-Based Comparison of C/C++ Compilers | Colfax Research).

Just to get clarification on the last thing you’ve suggested, do you mean to use the following code in a .cmake with paths set to libraries in my oneAPI locations for the respective libraries?

set(LAPACK_LIBRARIES       "/opt/intel/oneapi/lib/libmkl_rt@SHLIB_EXT@" CACHE STRING "")
set(LAPACK_INCLUDE_DIRS    "/opt/intel/oneapi/include" CACHE STRING "")
set(OpenMP_LIBRARY_DIRS    "/opt/intel/oneapi/lib" CACHE STRING "")

Also, what be the best to way to make sure the installation has good threaded BLAS/LAPACK libraries ? Is there a way to check for that?

Recently, I ended up getting this error, that psi4 is linked to multiple copies of OpenMP.

OMP: Error #15: 

Initializing, but found already initialized.


Hint This means that multiple copies of the OpenMP runtime have been 
linked into the program. That is dangerous, since it can degrade performance
or cause incorrect results. The best thing to do is to ensure that only 
a single OpenMP runtime is linked into the process, e.g. by avoiding static 
linking of the OpenMP runtime in any library. 

As an unsafe, unsupported, undocumented workaround you can set the 
environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program 
to continue to execute, but that may cause crashes or silently produce 
incorrect results. 

For more information, 
please see

Aborted (core dumped)

I am guessing this is due to a clash between anaconda’s MKL and intel oneAPI toolkit.

Has anyone else seen this error?

This can happen when you compile with GNU compilers and link against MKL.
In the thread you wrote you wanted to compile with Intel compilers, then I am wondering how you end up with the GNU library (libomp). Or is this a OSX compilation with clang?

edit: This could also be due to the numpy BLAS backend not using the MKL.

No this is not on OSX, the default compilers on my machine are GNU compilers. But, when I need intel oneAPI, I initialise it every time with $ source /opt/intel/oneapi/

I wonder why I am seeing this, when I compiled my copy of psi4, I did make the necessary changes in psi4-dev/src/psi4DepsMKLCache.cmake to set them to oneapi.

It depends on how cmake did configure the build.

Did you use psi4-path-advisor --intel or set DCMAKE_CXX_COMPILER (and C/Fortran) yourself?

My original build was using the psi4-path-advisor --intel but, I have been trying a couple of things to figure out what went wrong. I tried to build another separate installation, where I set the compiler using DCMAKE_CXX_COMPILER but, I realized the inconsistency was with the conda environment, I created before I started my first build. I guess this might be relevant since psi4DepsCache.cmake sets variables for dependencies from anaconda.

Anyways, doing the following kept everything consistent and solved these problems:

  • A conda environment with everything intel, beginning with dependencies like numpy, scipy etc. This seems to avoid all kinds of mix up of dependencies.
  • After, having setup a conda-environment, using psi4-path-advisor --intel to get the arguments for cmake and editing psi4DepsIntelCache.cmake
    and psi4DepsMKLCache.cmake files provides cmake with oneAPI targets for different dependencies required for building psi4.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.