[Wien] ifort classic compiler now discontinued in one-api 2025.0 online repositories
Gavin Abo
gabo13279 at gmail.com
Fri Dec 27 17:04:22 CET 2024
The problem I've encountered with using -standard-semantics is that only
lapw0 and lapw1 don't compile with unreferenced errors (e.g., libxc).
Currently, a work around seems to be to recompile lapw0 and lapw1 with
-O0 without -standard-semantics.
I tried removing -pad but the segmentation error still happens:
username at computername:~/WIEN2k/SRC_dstart$ grep 'OPT =' Makefile
FOPT = -O -FR -mp1 -w -prec_div -pc80 -ip -DINTEL_VML -traceback
-assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCH)
FPOPT = -O -FR -mp1 -w -prec_div -pc80 -ip -DINTEL_VML -traceback
-assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCHP) $(OMP_SWITCHP)
username at computername:~/WIEN2k/SRC_dstart$ make
...
make dstart FORT=ifx FFLAGS=' -O -FR -mp1 -w -prec_div -pc80 -ip
-DINTEL_VML -traceback -assume buffered_io
-I/opt/intel/oneapi/mkl/2025.0/include -qopenmp '
make[1]: Entering directory '/home/username/WIEN2k/SRC_dstart'
...
ifx -O -FR -mp1 -w -prec_div -pc80 -ip -DINTEL_VML -traceback -assume
buffered_io -I/opt/intel/oneapi/mkl/2025.0/include -qopenmp -c charge.f
#0 0x0000615e21717b41
#1 0x0000615e2177c457
#2 0x0000615e2177c585
#3 0x0000071d83e45320
#4 0x0000615e2089cba0
#5 0x0000615e22ab0f28
#6 0x0000615e21089b27
#7 0x0000615e2108966c
#8 0x0000615e2125b59a
#9 0x0000615e20fc7253
#10 0x0000615e20e7e752
#11 0x0000615e20c0baac
#12 0x0000615e20c0ac9d
#13 0x0000615e20c0abf1
#14 0x0000615e20febfe2
#15 0x0000615e20bb0c1c
#16 0x0000615e208f2e94
#17 0x0000615e208f2cb9
#18 0x0000615e20869241
#19 0x0000615e20868f71
#20 0x0000615e2097f34a
#21 0x0000615e2097f121
#22 0x0000615e20e9c8a9
#23 0x0000615e216b4cfa
#24 0x0000615e216b2a37
#25 0x0000615e2165e64b
#26 0x0000615e2183a704
#27 0x0000071d83e2a1ca
#28 0x0000071d83e2a28b __libc_start_main + 139
#29 0x0000615e2149519e
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 Software Problem Report. Note: File and line
given may not be explicit cause of this error.
compilation aborted for charge.f (code 3)
...
Gavin
WIEN2k user
On 12/27/2024 8:37 AM, Laurence Marks wrote:
> Try removing -pad
>
> ---
> Emeritus Professor Laurence Marks (Laurie)
> www.numis.northwestern.edu <http://www.numis.northwestern.edu>
> https://scholar.google.com/citations?user=zmHhI9gAAAAJ&hl=en
> <https://scholar.google.com/citations?user=zmHhI9gAAAAJ&hl=en>
> "Research is to see what everybody else has seen, and to think what
> nobody else has thought" Albert Szent-Györgyi
>
> On Fri, Dec 27, 2024, 15:15 Gavin Abo <gabo13279 at gmail.com> wrote:
>
> As seen below, the timing of dstart looks like it got better using
> -O. I came across a comment that Intel Fortran does not default
> to -standard-semantics unless you ask for it at:
>
> https://fortran-lang.discourse.group/t/strange-issue-with-ifx-compiler-and-assume-recursion/7013/3
>
> Giving that a try, dstart compiled with -O.
>
> *_Timing with -O0_*
>
> username at computername:~/wiendata/TiC$ x dstart
> C T F
> DSTART ENDS
> 2.733u 0.006s 0:02.74 99.6% 0+0k 0+368io 0pf+0w
> username at computername:~/wiendata/TiC$ cd $WIENROOT/SRC_dstart
> username at computername:~/WIEN2k/SRC_dstart$ grep 'OPT =' Makefile
> FOPT = -O0 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML
> -traceback -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCH)
> FPOPT = -O0 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML
> -traceback -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCHP)
> $(OMP_SWITCHP)
>
> _*Segmentation compile error with -O*_
>
> username at computername:~/WIEN2k/SRC_dstart$ gedit Makefile
> username at computername:~/WIEN2k/SRC_dstart$ grep 'OPT =' Makefile
> FOPT = -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML
> -traceback -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCH)
> FPOPT = -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML
> -traceback -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCHP)
> $(OMP_SWITCHP)
> username at computername:~/WIEN2k/SRC_dstart$ make
> ...
> ifx -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback
> -assume buffered_io -I/opt/intel/oneapi/mkl/2025.0/include
> -qopenmp -c charge.f
> #0 0x00005d3831075b41
> #1 0x00005d38310da457
> #2 0x00005d38310da585
> #3 0x000005d840c45320
> #4 0x00005d38301faba0
> #5 0x00005d383240ef28
> #6 0x00005d38309e7b27
> #7 0x00005d38309e766c
> #8 0x00005d3830bb959a
> #9 0x00005d3830925253
> #10 0x00005d38307dc752
> #11 0x00005d3830569aac
> #12 0x00005d3830568c9d
> #13 0x00005d3830568bf1
> #14 0x00005d3830949fe2
> #15 0x00005d383050ec1c
> #16 0x00005d3830250e94
> #17 0x00005d3830250cb9
> #18 0x00005d38301c7241
> #19 0x00005d38301c6f71
> #20 0x00005d38302dd34a
> #21 0x00005d38302dd121
> #22 0x00005d38307fa8a9
> #23 0x00005d3831012cfa
> #24 0x00005d3831010a37
> #25 0x00005d3830fbc64b
> #26 0x00005d3831198704
> #27 0x000005d840c2a1ca
> #28 0x000005d840c2a28b __libc_start_main + 139
> #29 0x00005d3830df319e
>
> 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 Software Problem Report.
> Note: File and line given may not be explicit cause of this error.
> compilation aborted for charge.f (code 3)
> ...
>
> *_Compile with -O and -standard-semantics_*
>
> username at computername:~/WIEN2k/SRC_dstart$ gedit Makefile
> username at computername:~/WIEN2k/SRC_dstart$ grep 'OPT =' Makefile
> FOPT = -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML
> -traceback -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCH)
> -standard-semantics
> FPOPT = -O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML
> -traceback -assume buffered_io -I$(MKLROOT)/include $(OMP_SWITCHP)
> $(OMP_SWITCHP) -standard-semantics
> username at computername:~/WIEN2k/SRC_dstart$ make
> ...
> username at computername:~/WIEN2k/SRC_dstart$ cp dstart ../dstart
> username at computername:~/WIEN2k/SRC_dstart$ cp dstart_mpi ../dstart_mpi
> username at computername:~/WIEN2k/SRC_dstart$ cd ~/wiendata/TiC
>
> *_Timing with _**_-O and -standard-semantics_*
>
> username at computername:~/wiendata/TiC$ x dstart
> DSTART ENDS
> 0.732u 0.008s 0:00.74 98.6% 0+0k 0+368io 0pf+0w
>
> Kind Regards,
>
> Gavin
> WIEN2k user
>
> On 12/27/2024 1:59 AM, Peter Blaha wrote:
>> I'd expect this slow code is due to the switching off of
>> optimization (-O0), and not due to a general problem of ifx with
>> complex numbers.
>>
>> If you do -O0 globally, the code will obviously be MUCH slower,
>> exactly as you have found out.
>>
>> Compilation with ifx would need a "special" strategy, compiling
>> only the routines where optimization fails with -O0, all the rest
>> with -O, like:
>>
>> Makefile with -O
>> make
>> compile the routine where it fails by hand:
>> ifx -O0 .... -c failing_routine.f
>> make
>>
>> continue the 2 lines above until it finishes. As far as I
>> remember, -O0 was required only for non-time-critical routines.
>>
>> Obviously, this is only a solution for experts. I'll see if I can
>> come up with more specific Makefiles for ifx, where the
>> problematic routines are compiled automatically without
>> optimization.
>>
>> In any case, it would be interesting to see, if the code produced
>> by this scheme is (almost) as fast as the ifort code.
>>
>> Best regards
>> Peter
>>
>>
>>
>> Am 26.12.2024 um 12:10 schrieb Michael Fechtelkord via Wien:
>>> Hello all,
>>>
>>>
>>> thanks Gavin for your efforts concerning the ifx compiler and
>>> the complete compilation of the code.
>>>
>>>
>>> The compilation of the code with ifx is much faster, but the
>>> compiled WIEN2k code is much faster when compiled with ifort
>>> 2021.13.1.
>>>
>>> I have run a NMR calculation of KAlF4 with ifx and ifort
>>> compiled code and the ifort compiled code takes half of the time
>>> of the ifx compiled code (16 minutes vs. 28 minutes).
>>>
>>> This is due to the fact that the handling of complex data is
>>> still better done with ifort compiled code. I read a few
>>> postings concerning this fact and I think this is still valid
>>> for the current version of ifx.
>>>
>>>
>>> https://community.intel.com/t5/Intel-Fortran-Compiler/IFX-vs-IFORT-
>>> performance-difference/m-p/1472018#M165800
>>>
>>>
>>> Happy Christmas to all!
>>>
>>> Michael
>>>
>>>
>>> Am 21.12.2024 um 18:02 schrieb Gavin Abo:
>>>>
>>>> Thanks for the hint about using -O0 when using ifx 2025.0.4.
>>>>
>>>> I compiled WIEN2k 24.1 with it, and it built without errors. I
>>>> was even able to compile elpa with it.
>>>>
>>>> I documented the steps I used should others be interested in
>>>> them and put them in a file that should be at:
>>>>
>>>> https://github.com/gsabo/WIEN2k-Docs/blob/main/
>>>> WIEN2k24.1_Ubuntu22.04_Install_with_OneAPI(ifx).pdf
>>>>
>>>> The TiC example also ran fine. Screenshots of it are in
>>>> another file here:
>>>>
>>>> https://github.com/gsabo/WIEN2k-Docs/blob/main/
>>>> WIEN2k24.1%20TiC%20Example(ifx).pdf
>>>>
>>>> Gavin
>>>> WIEN2k user
>>>> On 10/30/2024 7:03 AM, Michael Fechtelkord via Wien wrote:
>>>>>
>>>>> I just compiled the WIEN2k code with ifx (2025.0.0) again,
>>>>> regarding Peter's recommendations .. and only a few errors
>>>>> remain now (all compiled without optimisation using -O0 flag) :
>>>>>
>>>>>
>>>>> SRC_3ddens/compile.msg:make: *** [Makefile:65: 3ddens] Fehler 1
>>>>> SRC_reformat/compile.msg:reformat.c:3:1: Fehler: Rückgabetyp
>>>>> ist auf »int« voreingestellt [-Wimplicit-int]
>>>>> SRC_reformat/compile.msg:make: *** [Makefile:40: reformat.o]
>>>>> Fehler 1
>>>>>
>>>>> SRC_3ddens
>>>>> ifx -o ./3ddens modules.o fft_modules.o 3ddens.o setfft2.o
>>>>> stern.o rotdef.o rotato.o rotat.o charge.o
>>>>> calculate_neighbours.o ylm.o radial.o sum.o interp.
>>>>> o gener.o vnorm.o latgen.o rotate.o reduc.o write_xsf.o
>>>>> write_stm.o primitive_cell.o read_struct.o atom_sphere_dens.o
>>>>> -L/usr/local/lib64 -lfftw3 -lfftw3
>>>>> _omp -O0 -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip
>>>>> -DINTEL_VML - traceback -assume buffered_io
>>>>> -I/opt/intel/oneapi/mkl/2025.0/include -DFFTW3 -DFFTW_OMP
>>>>> -I/usr/local/include -qopenmp
>>>>> -L/opt/intel/oneapi/mkl/2025.0/lib/ - lpthread -lm -ldl -liomp5
>>>>> /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/
>>>>> bin/ld: 3ddens.o: in function `dfftw_init_threads_.t1225p':
>>>>> ifx24sU4Q.i:(.text+0xf797): undefined reference to
>>>>> `dfftw_init_threads_'
>>>>> /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/
>>>>> bin/ld: 3ddens.o: in function `dfftw_plan_with_nthreads_.t1230p':
>>>>> ifx24sU4Q.i:(.text+0xf7b7): undefined reference to
>>>>> `dfftw_plan_with_nthreads_'
>>>>> make: *** [Makefile:65: 3ddens] Fehler 1
>>>>>
>>>>> SRC_reformat
>>>>> rm -f reformat.o
>>>>> cc -c reformat.c
>>>>> reformat.c:3:1: Fehler: Rückgabetyp ist auf »int«
>>>>> voreingestellt [- Wimplicit-int]
>>>>> 3 | main(argc,argv)
>>>>> | ^~~~
>>>>> make: *** [Makefile:40: reformat.o] Fehler 1
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Michael
>>>>>
>>>>> --
>>>>> Dr. Michael Fechtelkord
>>>>>
>>>>> Institut für Geologie, Mineralogie und Geophysik
>>>>> Ruhr-Universität Bochum
>>>>> Universitätsstr. 150
>>>>> <https://www.google.com/maps/search/Universit%C3%A4tsstr.+150?entry=gmail&source=g>
>>>>>
>>>>> 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 Geologie, Mineralogie und Geophysik
>>> Ruhr-Universität Bochum
>>> Universitätsstr. 150
>>> <https://www.google.com/maps/search/Universit%C3%A4tsstr.+150?entry=gmail&source=g>
>>>
>>> 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
>>>
>>
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20241227/cb4b4dca/attachment-0001.htm>
More information about the Wien
mailing list