Closed Enlil50 closed 10 months ago
could you please provide a reduced test case
most of the module is the matrix initialization and big comments, so you could just skip them. However deleting it gives obviously no matrix.
I removed all the useless subroutine from it and the CmakeLists.txt file is obviously needed. The main program is minimal.
If you need a different matrix I could spend some time to create a new one, without a few lines, but it doesn't change that much.
Let me know
P.S: I removed a hundred of lines or so by simplifying the matrix and removing some physics comments
forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PC Routine Line Source main_program_fort 0000000000F1D1C0 Unknown Unknown Unknown
Can you report stack with debug symbol? Or follow up the stack with gdb to chek if args passed at your side are the same as the ones that MLK see as inputs.
MKL: did you link using the exact options specified here https://www.intel.com/content/www/us/en/developer/tools/oneapi/onemkl-link-line-advisor.html, add wng-as-err at link time if possible, and, make sure to double-check cmake does indeed uses this exact expected link line (make VERBOSE=1
)? If not, the problem is likely a MKL one so you can close this issue. You'll find an example of using MKL here: https://github.com/opencollab/arpack-ng/blob/0eaf38bd51efd3046f0a7e61a08ddcd7ed1f1fcc/.github/workflows/jobs.yml#L153
I solved the issue. I created the triplet arrays locally and they were deallocated automatically when coming out from the scope.
I missed the fact that the sparse matrix still used them (and that's obvious, as no one would like to copy array internally)
It was a fault on my side. Thanks
Expected behavior
I don't know if it's the right place to ask this, but since this place is more familiar with arpack-ng (obviously) than mkl community, this is probably the best place.
I have a C++ project made with Spectra. A colleague of mine has done it on arpack-ng, fortran, with mkl and intel compilers. The eigenvalues differ from the 7th decimal value, for doubles.
I'm trying to use this library to make the comparison myself. I have my colleague project and, even if written differently, the sections which give me error are pretty much the same.
Actual behavior
I compared row_arr, col_arr and val_arr with the matrix printed from C++ and they are the same, so it should not be an issue in how i wrote the algorithm to initialize the matrix.
There is no issue warning until mkl_sparse_d_mv, so mkl_sparse_d_create_coo and dsaupd give no problems.
Where/how to reproduce the problem
CMakeLists.txt:
Main program:
My Module (Initialization, diagonalization):
Steps to reproduce the problem
Install mkl Install arpack-ng put your directory in CmakeLists.txt Read CMakeLists.txt comments (you need to compile mk_spblas.f90) run CMakeLists.txt with all the programs in the rihgt folders (or just change the paths, easy and clear)
Error message
forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PC Routine Line Source
main_program_fort 0000000000F1D1C0 Unknown Unknown Unknown main_program_fort 00000000007E59EE Unknown Unknown Unknown main_program_fort 000000000041C63B Unknown Unknown Unknown main_program_fort 00000000004144FF Unknown Unknown Unknown main_program_fort 0000000000413D56 Unknown Unknown Unknown main_program_fort 0000000000403124 Unknown Unknown Unknown main_program_fort 00000000004029A8 Unknown Unknown Unknown main_program_fort 000000000040259D Unknown Unknown Unknown main_program_fort 0000000000F13EDA Unknown Unknown Unknown main_program_fort 0000000000F15777 Unknown Unknown Unknown main_program_fort 0000000000402475 Unknown Unknown Unknown
To be fair there even is another one, I could add here, given the exact same subject:
ifort: warning #10315: specifying -lm before files may supersede the Intel(R) math library and affect performance ld: /opt/intel/oneapi/mkl/2024.0/lib/libmkl_core.a(mkl_memory_patched.o): in function `mkl_serv_set_memory_limit': mkl_memory.c:(.text+0x5d1): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking [100%] Built target main_program_fortran
This issue is quite strange, as -lm is the recommended compile flag from the intel advisory. My colleague uses make, instead of cmake. He says it gives him no problem if you add it after adding the file. I specified it as a compile flag, so it should not give me errors of any sort.