[Wien] Error in MKL 2024.2 during NMR integration
Michael Fechtelkord
Michael.Fechtelkord at ruhr-uni-bochum.de
Tue Nov 4 17:23:43 CET 2025
Hello Peter,
I will check your suggestions and also send you struct and clmsum file
separatly by mail. As it is Analcime (NaAlSi2O6H2O) it is not a metal. I
am focussing currently on the proton chemical shift. Maybe here is the
problem. I will also send the nmr input file.
Best regards,
Michael
Am 04.11.2025 um 16:58 schrieb Peter Blaha:
> Interesting. Do you have a metal ???
>
> You could add the switch -noxi, then case.xim should not be
> calculated (usually the contribution is small anyway).
>
> You could also use -coreonly to get the core contribution (also to
> xim) or -xionly (just for testing if in this case case.xim would be ok).
>
> Then one needs debugging what causes the NANs in case.xim (which is
> created in the current step).
>
> If your case is not too big, you could send me the struct (and clmsum)
> file, and I can try to verify the problem on my computer.
>
> Peter
>
>
> Am 02.11.2025 um 21:45 schrieb Michael Fechtelkord via Wien:
>> /The output was not on the screen, but in the case.outputnmr_integ
>> file:/
>>
>> The value of tmptens is NaN NaN
>> NaN NaN NaN
>> NaN NaN NaN NaN
>> INFO of DGEEV in integrate_current.f -4
>>
>>
>> /NaNs started already here, with NaNs in the xim file:/
>>
>> :WALLTIM sph_sub_pw_2 1726.5
>> :WALLTIM get_moments_ylm 0.0
>> :WALLTIM resample_int 0.0
>> :WALLTIM get_ps_charge 2.8
>> :WALLTIM sph_sub_pw_1 0.0
>>
>> Orbital part of magnetic susceptibility read from file=
>> Analcime_NaAlSi2O6H2O.xim
>> NaN NaN NaN
>> NaN NaN NaN
>> NaN NaN NaN
>>
>>
>> :NMRSPH001 ATOM: Na 1 NMR (sphere/ppm) TENSOR =
>> 596.8308 -0.0000 -0.0000 ---> Bext inX
>> :NMRSPH001 ATOM: Na 1 NMR (sphere/ppm) TENSOR =
>> -0.0000 559.3414 58.6537 ---> Bext inY
>> :NMRSPH001 ATOM: Na 1 NMR (sphere/ppm) TENSOR =
>> 0.0000 58.6537 559.3414 ---> Bext inZ
>>
>> :NMRTOT001 ATOM: Na 1 NMR (total/ppm) TENSOR
>> = NaN NaN NaN ---> Bext inX
>> :NMRTOT001 ATOM: Na 1 NMR (total/ppm) TENSOR
>> = NaN NaN NaN ---> Bext inY
>> :NMRTOT001 ATOM: Na 1 NMR (total/ppm) TENSOR
>> = NaN NaN NaN ---> Bext inZ
>>
>>
>> and so on...
>>
>>
>> If there is any interest I can send the whole /case.outputnmr_integ
>> file/
>>
>> /
>> /
>>
>> /Best regards,/
>>
>> /Michael/
>>
>> /
>> /
>>
>> Am 31.10.2025 um 18:38 schrieb Peter Blaha:
>>> print *, tmpdens
>>>
>>> just before the line call dgeev
>>>
>>> It will give you 9 values on the screen (or stdout)
>>>
>>> Am 31.10.2025 um 18:26 schrieb Michael Fechtelkord via Wien:
>>>> I have not used mpi in that run
>>>>
>>>>
>>>> It was already a sequential run.
>>>>
>>>>
>>>> How can I catch tmpdens array before it is erased?
>>>>
>>>> Am 31.10.2025 um 18:11 schrieb Peter Blaha:
>>>>> Hmm.
>>>>>
>>>>> Then the next step is to print out the array tmpdens just before
>>>>> the call to dgeev.
>>>>>
>>>>> If this contains NaNs, then one has to search where they come from.
>>>>>
>>>>> PS: x_nmr -mode integ is fast, one could run it without mpi and
>>>>> check if the same happens.
>>>>>
>>>>> Am 31.10.2025 um 17:45 schrieb Michael Fechtelkord via Wien:
>>>>>> Thanks Gerhard for your remarks!
>>>>>>
>>>>>>
>>>>>> I now compiled WIEN2k completely without using intel things,
>>>>>> using gfortran, gcc (15.2.1), openblas with openmp and only
>>>>>> sequential runs (no mpi). The result of the calculation is very
>>>>>> similar to the one with MKL but contains much more information:
>>>>>>
>>>>>> EXECUTING: /usr/local/WIEN2k/nmr -case Analcime_NaAlSi2O6H2O
>>>>>> - mode integ -green
>>>>>>
>>>>>> ** On entry to DGEBAL parameter number 3 had an illegal value
>>>>>> ** On entry to DGEHRD parameter number 2 had an illegal value
>>>>>> ** On entry to DORGHR parameter number 2 had an illegal value
>>>>>> ** On entry to DHSEQR parameter number 4 had an illegal value
>>>>>> STOP DGEEV in integrate_current.f
>>>>>>
>>>>>> stop
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> Am 30.10.2025 um 21:36 schrieb Fecher, Gerhard:
>>>>>>> Both, dgeev and dgebal are lapack routines,
>>>>>>> Did you try to use the original routines from netlib.org ? Or
>>>>>>> any other precompiled versions found in the linux distributions
>>>>>>> instead of mkl ?
>>>>>>>
>>>>>>> Ciao
>>>>>>> Gerhard
>>>>>>>
>>>>>>> DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
>>>>>>> "I think the problem, to be quite honest with you,
>>>>>>> is that you have never actually known what the question is."
>>>>>>>
>>>>>>> ====================================
>>>>>>> Dr. Gerhard H. Fecher
>>>>>>> Institut of Physics
>>>>>>> Johannes Gutenberg - University
>>>>>>> 55099 Mainz
>>>>>>> ________________________________________
>>>>>>> Von: Wien [wien-bounces at zeus.theochem.tuwien.ac.at] im Auftrag
>>>>>>> von Michael Fechtelkord via Wien [wien at zeus.theochem.tuwien.ac.at]
>>>>>>> Gesendet: Donnerstag, 30. Oktober 2025 18:52
>>>>>>> An: A Mailing list for WIEN2k users
>>>>>>> Cc: Michael Fechtelkord
>>>>>>> Betreff: Re: [Wien] Error in MKL 2024.2 during NMR integration
>>>>>>>
>>>>>>> Thanks Peter for your help!
>>>>>>>
>>>>>>>
>>>>>>> I tried both I changed it from 12 to 24 and also to 100. The error
>>>>>>> remains and recompiled the nmr module of WIEN2k. Intel oneMKL
>>>>>>> ERROR:
>>>>>>> Parameter 3 was incorrect on entry to DGEBAL. But the referring
>>>>>>> to DGEEV
>>>>>>> is now missing (INFO of DGEEV in integrate_current.f -1
>>>>>>> DGEEV in integrate_current.f) does not show up anymore.
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>> Am 30.10.2025 um 17:16 schrieb Peter Blaha:
>>>>>>>> Just a short analysis:
>>>>>>>>
>>>>>>>> in integrate_current.f some 3x3 matrix is set up and
>>>>>>>> diagonalized in
>>>>>>>> dgeev.
>>>>>>>>
>>>>>>>> I guess Intel may violate the dimensions of the WORK vector (some
>>>>>>>> empty working space for this subroutine), which in the doku has a
>>>>>>>> value of 4*N, i.e. 12
>>>>>>>> This is what we supply.
>>>>>>>> I remember that we had some problems with some mkl
>>>>>>>> diagonalization in
>>>>>>>> lapwso at some point, which we fixed by larger work-arrays than
>>>>>>>> "necessary".
>>>>>>>>
>>>>>>>> So if you want to try to fix it, I'd change 2 lines in
>>>>>>>> integrate_current.f:
>>>>>>>>
>>>>>>>>
>>>>>>>> real*8 :: WR(3),WI(3),VL(3,3),VR(3,3),work(12)
>>>>>>>> and
>>>>>>>> call
>>>>>>>> dgeev('N','V',3,tmptens,3,WR,WI,VL,3,VR,3,work,12,info)
>>>>>>>>
>>>>>>>> to
>>>>>>>> real*8 :: WR(3),WI(3),VL(3,3),VR(3,3),work(24)
>>>>>>>> and
>>>>>>>> call
>>>>>>>> dgeev('N','V',3,tmptens,3,WR,WI,VL,3,VR,3,work,24,info)
>>>>>>>>
>>>>>>>> 24 is just a guess. Since this is tiny anyway, you can also put
>>>>>>>> 100 or
>>>>>>>> so.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Peter
>>>>>>>>
>>>>>>>> Am 30.10.2025 um 14:46 schrieb Michael Fechtelkord via Wien:
>>>>>>>>> The origin of the problem is in integrate_current.f
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> calling DGEEV .. and it happens currently only for the nmr
>>>>>>>>> calculation of analcime.. (currently using MKL 2025.3 and ifx,
>>>>>>>>> gcc
>>>>>>>>> 15.2.1)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> EXECUTING: mpirun -np 4 -machinefile .machine_nmrinteg
>>>>>>>>> /usr/local/ WIEN2k/nmr_mpi -case Analcime_NaAlSi2O6H2O -mode
>>>>>>>>> integ
>>>>>>>>> -green
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Intel oneMKL ERROR: Parameter 3 was incorrect on entry to DGEBAL.
>>>>>>>>>
>>>>>>>>> ..
>>>>>>>>>
>>>>>>>>> Intel oneMKL ERROR: Parameter 3 was incorrect on entry to DGEBAL.
>>>>>>>>> INFO of DGEEV in integrate_current.f -1
>>>>>>>>> DGEEV in integrate_current.f
>>>>>>>>>
>>>>>>>>> ===================================================================================
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
>>>>>>>>> = RANK 1 PID 3335 RUNNING AT localhost
>>>>>>>>> = KILLED BY SIGNAL: 9 (Killed)
>>>>>>>>> ===================================================================================
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 24.09.2025 um 11:59 schrieb Peter Blaha:
>>>>>>>>>> Hard to help.
>>>>>>>>>> The subroutine dgebal is not called directly by the nmr
>>>>>>>>>> program of
>>>>>>>>>> wien2k.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Am 23.09.2025 um 17:07 schrieb Michael Fechtelkord via Wien:
>>>>>>>>>>> Hello all,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I experienced an error during executing integratin of the NMR
>>>>>>>>>>> Current due to the Intel MKL library. I use ifort 2024.2, MKL
>>>>>>>>>>> 2024.2, gcc 15 15.2 and LINUX Kernel 6.16.7-1 for open Suse
>>>>>>>>>>> Tumbleweed. Integration was done in sequential mode.
>>>>>>>>>>> Parallel still
>>>>>>>>>>> does not work because of the glibc error.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> EXECUTING: /usr/local/WIEN2k/nmr -case
>>>>>>>>>>> Analcime_NaAlSi2O6H2O -
>>>>>>>>>>> mode integ -green
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Intel oneMKL ERROR: Parameter 3 was incorrect on entry to
>>>>>>>>>>> DGEBAL.
>>>>>>>>>>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>>>>>>>>>>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>>>>>>>>>>>
>>>>>>>>>>> stop error
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Has someone an idea how to fix it?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>>
>>>>>>>>>>> Michael
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> --
>>>>>>> Dr. Michael Fechtelkord
>>>>>>>
>>>>>>> Institut für Geowissenschaften
>>>>>>> Ruhr-Universität Bochum
>>>>>>> Universitätsstr. 150
>>>>>>> D-44780 Bochum
>>>>>>>
>>>>>>> Phone: +49 (234) 32-24380
>>>>>>> Fax: +49 (234) 32-04380
>>>>>>> Email: Michael.Fechtelkord at ruhr-uni-bochum.de
>>>>>>> Web Page:
>>>>>>> https://www.ruhr-uni-bochum.de/kristallographie/kc/mitarbeiter/
>>>>>>> fechtelkord/
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Wien mailing list
>>>>>>> Wien at zeus.theochem.tuwien.ac.at
>>>>>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>>>>> SEARCH the MAILING-LIST at: http://www.mail-archive.com/
>>>>>>> wien at zeus.theochem.tuwien.ac.at/index.html
>>>>>>> _______________________________________________
>>>>>>> Wien mailing list
>>>>>>> Wien at zeus.theochem.tuwien.ac.at
>>>>>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>>>>> SEARCH the MAILING-LIST at: http://www.mail-archive.com/
>>>>>>> wien at zeus.theochem.tuwien.ac.at/index.html
>>>>>>
>>>>>
>>>
>> --
>> Dr. Michael Fechtelkord
>>
>> Institut für Geowissenschaften
>> Ruhr-Universität Bochum
>> Universitätsstr. 150
>> D-44780 Bochum
>>
>> Phone: +49 (234) 32-24380
>> Fax: +49 (234) 32-04380
>> Email:Michael.Fechtelkord at ruhr-uni-bochum.de
>> Web
>> Page:https://www.ruhr-uni-bochum.de/kristallographie/kc/mitarbeiter/fechtelkord/
>>
>>
>> _______________________________________________
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>> SEARCH the MAILING-LIST at:
>> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>
--
Dr. Michael Fechtelkord
Institut für Geowissenschaften
Ruhr-Universität Bochum
Universitätsstr. 150
D-44780 Bochum
Phone: +49 (234) 32-24380
Fax: +49 (234) 32-04380
Email: Michael.Fechtelkord at ruhr-uni-bochum.de
Web Page: https://www.ruhr-uni-bochum.de/kristallographie/kc/mitarbeiter/fechtelkord/
More information about the Wien
mailing list