Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

neso%oneapi build fails with intel-oneapi-mkl version 2023.1.0 #210

Open
matt-graham opened this issue Aug 29, 2023 · 2 comments · May be fixed by #215
Open

neso%oneapi build fails with intel-oneapi-mkl version 2023.1.0 #210

matt-graham opened this issue Aug 29, 2023 · 2 comments · May be fixed by #215

Comments

@matt-graham
Copy link

On trying to install NESO using Spack with adjusted package specification in spack.yaml

 - neso%oneapi ^nektar%oneapi ^intel-oneapi-mpi ^intel-oneapi-mkl^py-numpy%intel
   ^boost%intel ^py-cython%oneapi ^dpcpp ^scotch@6 ^[email protected]

which pins hdf5 package to v1.12.2 to address ExCALIBUR-NEPTUNE/NESO-Particles#37 (and pinning [email protected] when installing Intel compilers to avoid #183) I get a series of undefined reference errors in oneapi::mkl namespace when building neso package using Intel compilers

94      mesh-f9e32c.cpp:(.text+0x6615): undefined reference to `oneapi::mkl::dft::descriptor<(oneapi::mkl::dft::precision)36, (oneapi::mkl::dft::domain)32>::commit(cl::sycl::queue&)'
95      /usr/bin/ld: mesh-f9e32c.cpp:(.text+0x666c): undefined reference to `void oneapi::mkl::dft::compute_forward<oneapi::mkl::dft::descriptor<(oneapi::mkl::dft::precision)36, (oneapi::mkl::dft::domain)32>, std::complex<double>,
             std::complex<double> >(oneapi::mkl::dft::descriptor<(oneapi::mkl::dft::precision)36, (oneapi::mkl::dft::domain)32>&, cl::sycl::buffer<std::complex<double>, 1, cl::sycl::detail::aligned_allocator<char>, void>&, cl::sycl::buf
             fer<std::complex<double>, 1, cl::sycl::detail::aligned_allocator<char>, void>&)'
96      /usr/bin/ld: mesh-f9e32c.cpp:(.text+0x68a7): undefined reference to `oneapi::mkl::dft::descriptor<(oneapi::mkl::dft::precision)36, (oneapi::mkl::dft::domain)32>::commit(cl::sycl::queue&)'
97      /usr/bin/ld: mesh-f9e32c.cpp:(.text+0x68f6): undefined reference to `void oneapi::mkl::dft::compute_backward<oneapi::mkl::dft::descriptor<(oneapi::mkl::dft::precision)36, (oneapi::mkl::dft::domain)32>, std::complex<double>,
              std::complex<double> >(oneapi::mkl::dft::descriptor<(oneapi::mkl::dft::precision)36, (oneapi::mkl::dft::domain)32>&, cl::sycl::buffer<std::complex<double>, 1, cl::sycl::detail::aligned_allocator<char>, void>&, cl::sycl::bu
             ffer<std::complex<double>, 1, cl::sycl::detail::aligned_allocator<char>, void>&)'

With above package spec in which intel-oneapi-mkl is unpinned, currently version 2023.1.0 of intel-oneapi-mkl seems to be getting picked up. On the hunch that this might be causing the above errors I reran with the updated spec

 - neso%oneapi ^nektar%oneapi ^intel-oneapi-mpi ^[email protected] ^py-numpy%intel
   ^boost%intel ^py-cython%oneapi ^dpcpp ^scotch@6 ^[email protected]

with intel-oneapi-mkl version pinned and this seems to resolve above errors, with install completing successfully.

@cmacmackin
Copy link
Contributor

You need to use the same MKL version as oneAPI compiler version. The real underlying problem is #183.

@matt-graham
Copy link
Author

Given that using matching intel-oneapi-mkl and intel-oneapi-compiler versions resolved the issue that does seem at least partially to be the case, but this wasn't particularly obvious given that the Intel documentation suggests that oneAPI libraries should be backwards compatible with older compiler versions, though I guess here the issue is specifically that there is a difference in major version and so no guarantee of backwards compatibility.

More to the point, I would say there is a separate but related issue to #183 here as using the suggested fix there would still I think hit against the problem I described here as the intel-oneapi-mkl package version is not pinned in the updated spec there, which I assume means Spack will therefore get the latest available release which is compatible with the constraints in the spec which seems to currently be resolving to version 2023.1.0. In general it seems it would be useful to have CI set up to regularly test that NESO can be built using Spack with the latest versions of upstream packages that the spack.yaml manifest file gets concretized to so that issues like this one, #183 and ExCALIBUR-NEPTUNE/NESO-Particles#37 are automatically picked up, and/or more put more constraints in the spec and document the compiler versions which are currently supported.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants