[Wien] ifort classic compiler now discontinued in one-api 2025.0 online repositories
Michael Fechtelkord
Michael.Fechtelkord at ruhr-uni-bochum.de
Sun Oct 27 22:12:47 CET 2024
Hello Peter,
I isolated the two subroutines causing the error.
Those are SUBROUTINE CHARGEF and subroutine KSum3, which are the two
longest subroutines ( 106 and 122 lines). All others are quite short and
compile without errors. I assume the length leads to the crashes.
I will try also another computer to exclude hardware issues.
Best regards,
Michael
Am 27.10.2024 um 20:04 schrieb Peter Blaha:
> charge.f is in SRC_Globals (in the other SRC_* dirs there should only
> be a softlink to it.
>
> charge.f contains several subroutines/functions. Maybe this fact or
> that there are too many may cause the problem.
>
> The way to debug is to split this charge.f into several files (maybe
> use "bisection") and compile each part individually until the problem
> can be located (or is gone).
>
> In SRC_Globals split it into two parts and
>
> mpiifx -O3 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -
> traceback -assume buffered_io -I/opt/intel/oneapi/mkl/2025.0/include -
> qopenmp -DParallel -c c1.f
>
> and
>
> mpiifx -O3 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -
> traceback -assume buffered_io -I/opt/intel/oneapi/mkl/2025.0/include -
> qopenmp -DParallel -c c2.f
>
>
> If a problem occurs, split further ...
> ---------------------------------------------
> SearchZ.F (was added by L. Marks)
>
> maybe one needs a "external RHOSTM" statement at the beginning.
>
> > call RTBIS(RHOSTM,X1,X2,XACC,CTarget,ISTM,RT)
> > ---------------------------^
>
> Rhostm is a function, passed into a subroutine ....
>
>
> Am 27.10.2024 um 19:17 schrieb Michael Fechtelkord via Wien:
>> Dear all,
>>
>>
>> the libxc problem does not longer exist. I used the newest ifx
>> version now. Most parts of WIEN2k compile without problems. Two
>> source files still make problems.
>>
>>
>> 1) charge.f (in different source directories, same error always)
>>
>> mpiifx -O3 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -
>> traceback -assume buffered_io -I/opt/intel/oneapi/mkl/2025.0/include
>> - qopenmp -DParallel -c charge.f
>> #0 0x000000000310cce1
>> #1 0x00000000031715d7
>> #2 0x0000000003171705
>> #3 0x0000148436a57980
>> #4 0x0000000002291d60
>> #5 0x00000000044a6048
>> #6 0x0000000002a7aa37
>> #7 0x0000000002a7a57c
>> #8 0x0000000002c4c4ca
>> #9 0x00000000029b8173
>> #10 0x00000000028743b2
>> #11 0x000000000260103c
>> #12 0x000000000260022d
>> #13 0x0000000002600181
>> #14 0x00000000029ddd62
>> #15 0x00000000025a617c
>> #16 0x00000000022e8064
>> #17 0x00000000022e7e89
>> #18 0x000000000225e401
>> #19 0x000000000225e131
>> #20 0x000000000237461a
>> #21 0x00000000023743f1
>> #22 0x00000000028924e9
>> #23 0x00000000030a9e9a
>> #24 0x00000000030a7bd7
>> #25 0x00000000030537eb
>> #26 0x000000000322f884
>> #27 0x0000148436a40eec
>> #28 0x0000148436a40fb5 __libc_start_main + 135
>> #29 0x0000000002e8a34e
>>
>> charge.f: error #5633: **Internal compiler error: segmentation
>> violation signal raised** Please report this error along with the
>> circumstances in which it occurred in a So
>> ftware Problem Report. Note: File and line given may not be explicit
>> cause of this error.
>> compilation aborted for charge.f (code 3)
>>
>> 2) SearchZ_tmp_.F
>>
>> ifx -O3 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -
>> traceback -assume buffered_io -I/opt/intel/oneapi/mkl/2025.0/include
>> -c SearchZ_tmp_.F
>> #0 0x000000000310cce1
>> #1 0x00000000031715d7
>> #2 0x000000000315cfda
>> #3 0x0000000003073fb6
>> #4 0x00000000030c411e
>> #5 0x00000000031063e6
>> #6 0x000000000310002f
>> #7 0x00000000030fe080
>> #8 0x00000000030fd24d
>> #9 0x00000000031bf819
>> #10 0x00000000031bfe05
>> #11 0x00000000031bcff8
>> #12 0x00000000031bf819
>> #13 0x00000000031bfe05
>> #14 0x00000000031c2909
>> #15 0x00000000031bf819
>> #16 0x00000000031bcc3e
>> #17 0x00000000031bf819
>> #18 0x000000000305397b
>> #19 0x0000000003053317
>> #20 0x000000000322f884
>> #21 0x000015481a240eec
>> #22 0x000015481a240fb5 __libc_start_main + 135
>> #23 0x0000000002e8a34e
>>
>> SearchZ_tmp_.F(114): error #5623: **Internal compiler error: internal
>> abort** Please report this error along with the circumstances in
>> which it occurred in a Software Prob
>> lem Report. Note: File and line given may not be explicit cause of
>> this error.
>> call RTBIS(RHOSTM,X1,X2,XACC,CTarget,ISTM,RT)
>> ---------------------------^
>> compilation aborted for SearchZ_tmp_.F (code 3)
>>
>>
>> Best regards,
>>
>> Michael
>>
>>
>>
>>
>> Am 27.10.2024 um 15:21 schrieb Michael Fechtelkord via Wien:
>>> Dear all,
>>>
>>>
>>> just a few new results and informatuion using the Intel ifx
>>> compiler. ELPA, FFTW, LIBXC and MPICH compile fine and also check
>>> procedure shows no errors.
>>>
>>>
>>> WIEN2k seems to have problems when using no explicit types for
>>> variables. A short summary of the errors all in libxc_mod.F:
>>>
>>> SRC_lapw0/compile.msg:libxc_mod.F(4): error #7002: Error in opening
>>> the compiled module file. Check INCLUDE paths. [XC_F03_LIB_M]
>>> SRC_lapw0/compile.msg:libxc_mod.F(9): error #6457: This derived type
>>> name has not been declared. [XC_F03_FUNC_T]
>>> SRC_lapw0/compile.msg:libxc_mod.F(10): error #6457: This derived
>>> type name has not been declared. [XC_F03_FUNC_INFO_T]
>>> SRC_lapw0/compile.msg:libxc_mod.F(22): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_FUNC_X]
>>> SRC_lapw0/compile.msg:libxc_mod.F(22): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_UNPOLARIZED]
>>> SRC_lapw0/compile.msg:libxc_mod.F(23): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_FUNC_C]
>>> SRC_lapw0/compile.msg:libxc_mod.F(25): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_POLARIZED]
>>> SRC_lapw0/compile.msg:libxc_mod.F(38): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_INFO_C]
>>> SRC_lapw0/compile.msg:libxc_mod.F(38): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_F03_FUNC_GET_INFO]
>>> SRC_lapw0/compile.msg:libxc_mod.F(39): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_INFO_X]
>>> SRC_lapw0/compile.msg:libxc_mod.F(40): error #6404: This name does
>>> not have a type, and must have an explicit type.
>>> [XC_F03_FUNC_INFO_GET_FLAGS]
>>> SRC_lapw0/compile.msg:libxc_mod.F(4): error #7002: Error in opening
>>> the compiled module file. Check INCLUDE paths. [XC_F03_LIB_M]
>>> SRC_lapw0/compile.msg:libxc_mod.F(9): error #6457: This derived type
>>> name has not been declared. [XC_F03_FUNC_T]
>>> SRC_lapw0/compile.msg:libxc_mod.F(10): error #6457: This derived
>>> type name has not been declared. [XC_F03_FUNC_INFO_T]
>>> SRC_lapw0/compile.msg:libxc_mod.F(22): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_FUNC_X]
>>> SRC_lapw0/compile.msg:libxc_mod.F(22): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_UNPOLARIZED]
>>> SRC_lapw0/compile.msg:libxc_mod.F(23): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_FUNC_C]
>>> SRC_lapw0/compile.msg:libxc_mod.F(25): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_POLARIZED]
>>> SRC_lapw0/compile.msg:libxc_mod.F(38): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_INFO_C]
>>> SRC_lapw0/compile.msg:libxc_mod.F(38): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_F03_FUNC_GET_INFO]
>>> SRC_lapw0/compile.msg:libxc_mod.F(39): error #6404: This name does
>>> not have a type, and must have an explicit type. [XC_INFO_X]
>>> SRC_lapw0/compile.msg:libxc_mod.F(40): error #6404: This name does
>>> not have a type, and must have an explicit type.
>>> [XC_F03_FUNC_INFO_GET_FLAGS]
>>>
>>> In addition Segmenation violation signals occur in several modules.
>>>
>>>
>>> Best regards
>>>
>>> Michael
>>>
>
--
Dr. Michael Fechtelkord
Institut für Geologie, Mineralogie und Geophysik
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