JuliaSparse / Pardiso.jl

Calling the PARDISO library from Julia
Other
100 stars 27 forks source link

unable to create MKLPardisoSolver #83

Closed ric-cioffi closed 8 months ago

ric-cioffi commented 3 years ago

Hi, I have been trying to load Pardiso on a server (running julia 1.5.0), which already provides me with intel-mkl but I have been having issues creating the solver.

I fire up julia and immediately set ENV["MKLROOT"] to the right path. Then using Pardiso already gives me:

┌ Error: MKL Pardiso did not manage to load, error thrown was: could not load library "libgomp.so"
│ libgomp.so: cannot open shared object file: No such file or directory
└ @ Pardiso ~/.julia/packages/Pardiso/66TFF/src/Pardiso.jl:134

but the package seems to load just fine. In fact Pardiso.show_build_log() tells me

MKL Pardiso
=============
found MKLROOT environment variable, using it

However, when I try running ps = MKLPardisoSolver() I get:

ERROR: mkl library was not loaded, unable to create solver
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] MKLPardisoSolver() at /home/rcioffi/.julia/packages/Pardiso/66TFF/src/mkl_pardiso.jl:17
 [3] top-level scope at REPL[4]:1

The problem seems related to #21 and #22 but I couldn't figure out a solution.

Note: I read in a different issue the latest version is somehow not compatible with julia < 1.6 so I have been working with Pardiso v0.4.2

j-fu commented 3 years ago

libgomp.so is the gnu openmp library which comes with gcc. Did you install gcc on your system ?

ric-cioffi commented 3 years ago

Yes, gcc is also available (though I am not 100% sure julia knows where it is). Also, I might be wrong but I don't think libgomp is the problem because using Pardiso still works and the error I get when running MKLPardisoSolver() does not make any reference to libgomp.

j-fu commented 3 years ago

Yeah but it could be that " mkl library was not loaded" is a consequence of "could not load library libgomp". "using" the Julia package may seem ok even if loading of some library failed (this is an a priori assumption made without looking into the source).

You could try to force load libgomp using LD_PRELOAD or manage the LD_LIBRARY_PATH to help Julia to see the library. (see man ld.so).

KristofferC commented 3 years ago

Can you try run:

julia> Pardiso.load_lib_fortran("libgomp", 8)
Ptr{Nothing} @0x0000000004370080

julia> Pardiso.load_lib_fortran("libgomp", 9)
Ptr{Nothing} @0x0000000004370080

julia> Pardiso.load_lib_fortran("libgomp", 10)
Ptr{Nothing} @0x0000000004370080
ric-cioffi commented 3 years ago

Yeah but it could be that " mkl library was not loaded" is a consequence of "could not load library libgomp". "using" the Julia package may seem ok even if loading of some library failed (this is an a priori assumption made without looking into the source).

You could try to force load libgomp using LD_PRELOAD or manage the LD_LIBRARY_PATH to help Julia to see the library. (see man ld.so).

Fair point. I tried to understand how ld.so and ld-linux.so work bu couldn't figure out what I should be doing to let julia see libgomp.


Can you try run:

julia> Pardiso.load_lib_fortran("libgomp", 8)
Ptr{Nothing} @0x0000000004370080

julia> Pardiso.load_lib_fortran("libgomp", 9)
Ptr{Nothing} @0x0000000004370080

julia> Pardiso.load_lib_fortran("libgomp", 10)
Ptr{Nothing} @0x0000000004370080

In all three cases I get the following error:

ERROR: could not load library "libgomp.so"
libgomp.so: cannot open shared object file: No such file or directory
Stacktrace:
 [1] dlopen(::String, ::UInt32; throw_error::Bool) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Libdl/src/Libdl.jl:109
 [2] dlopen at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.5/Libdl/src/Libdl.jl:109 [inlined]
 [3] load_lib_fortran(::String, ::Array{Int64,1}) at /home/rcioffi/.julia/packages/Pardiso/66TFF/src/Pardiso.jl:78
 [4] load_lib_fortran(::String, ::Int64) at /home/rcioffi/.julia/packages/Pardiso/66TFF/src/Pardiso.jl:70
 [5] top-level scope at REPL[2]:1
KristofferC commented 3 years ago

Where is your gcc installed? Pardiso looks for it here: https://github.com/JuliaSparse/Pardiso.jl/blob/e0e08fcef1e4d8ff848b148cae31371360363037/src/Pardiso.jl#L76-L84.

It is very possible this detection could be improved..

KristofferC commented 3 years ago

Also, just pointing out. Pardiso.jl should work fine if you don't give MKL_ROOT by using the bundled MKL. Is there a reason you want to provide your own MKL?

ric-cioffi commented 3 years ago

Also, just pointing out. Pardiso.jl should work fine if you don't give MKL_ROOT by using the bundled MKL. Is there a reason you want to provide your own MKL?

When simply adding and using Pardiso without trying to provide it an MKLROOT I was getting:

ERROR: mkl library was not loaded, unable to create solver
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] MKLPardisoSolver() at /home/rcioffi/.julia/packages/Pardiso/66TFF/src/mkl_pardiso.jl:17
 [3] top-level scope at REPL[12]:1

which is why I was trying to provide my own, already available, MKL.


Ah I guess the problem is that my gcc location is slightly different: /usr/lib/gcc/x86_64-redhat-linux/, how can I let Pardiso read from there?

KristofferC commented 3 years ago

When simply adding and using Pardiso without trying to provide it an MKLROOT I was getting:

Maybe that was fixed in the most recent release (that only supports 1.6). Could you just try there to see how things work?

Ah I guess the problem is that my gcc location is slightly different: /usr/lib/gcc/x86_64-redhat-linux/, how can I let Pardiso read from there?

We would need to update Pardiso to handle that. Perhaps you can make a symlink in the meantime?

ric-cioffi commented 3 years ago

Maybe that was fixed in the most recent release (that only supports 1.6). Could you just try there to see how things work?

Yes, adding and using Pardiso works fine in 1.6.

We would need to update Pardiso to handle that. Perhaps you can make a symlink in the meantime?

Unfortunately it looks like I don't have the permissions to create a symlink there. Is there any other way to change gcc_path locally? I tried to dev Pardiso@0.4.2 but apparently I cannot specify a version when calling develop. Otherwise I guess I will have to try to update everything to 1.6

j-fu commented 3 years ago

Did you try to use LD_LIBRARY_PATH or LD_PRELOAD ? This should cirumvent the need for a symlink.

ric-cioffi commented 3 years ago

Did you try to use LD_LIBRARY_PATH or LD_PRELOAD ? This should cirumvent the need for a symlink.

I'm not sure how I should do it. I tried reading the man ld.so page but couldn't figure out exactly what to do

j-fu commented 3 years ago

You use it in the same way as you have used MKL_ROOT.

You can do:

LD_LIBRARY_PATH=$(LD_LIBRARY_PATH):/usr/lib/gcc/x86_64-redhat-linux/ julia 

or

LD_PRELOAD=/usr/lib/gcc/x86_64-redhat-linux/libgomp.so julia
KristofferC commented 3 years ago

I am not sure that will work since we are trying to open the library via an absolute path. Did you try it?

ric-cioffi commented 3 years ago

Just tried, neither of the two worked

ric-cioffi commented 3 years ago

I updated my packages to work with julia 1.6 so was able to load it directly with the bundled solver. Thank you both for your help.

I guess this issue can be closed now, unless you'd like to keep it open to reference the loading by absolute path.