[Wien] ifort classic compiler now discontinued in one-api 2025.0 online repositories

Gavin Abo gabo13279 at gmail.com
Fri Dec 27 16:15:20 CET 2024 

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
>>>> 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
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20241227/2e1dd82a/attachment.htm>

More information about the Wien mailing list