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

Michael Fechtelkord Michael.Fechtelkord at ruhr-uni-bochum.de
Tue Dec 31 13:05:05 CET 2024


Dear all,


thanks for all the input concerning the new ifx compiler. The change of 
$omp simd" with "$omp parallel do" proposed by Laurence Marks did remove 
all the segmentation violation errors. As you can see I compiled the 
whole code with

-L/usr/local/lib64 -lfftw3 -lfftw3_omp -O3 -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

However I still get an error for the 3ddens module, linking fftw. (see 
below). This does not happen  when using ifort. C compiler is gcc 13.2

--------------------------

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 -O3 -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/13/../../../../x86_64-suse-linux/bin/ld: 
3ddens.o: in function `MAIN__':
ifxim7AOm.i:(.text+0x4fe9): undefined reference to `dfftw_init_threads_'
/usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld: 
ifxim7AOm.i:(.text+0x5004): undefined reference to 
`dfftw_plan_with_nthreads_'

make: *** [Makefile:65: 3ddens] Fehler 1

--------------------------------

I compiled fftw 3.3.10 using the following configure parameters (as root):

FC=ifx F77=ifx CC=gcc MPICC=mpigcc CFLAGS="-O3 -march=native -mavx2" 
MCFLAGS="-O3 -march=native -mavx2" FCFLAGS="-O3 -xAVX2"\
   ./configure --prefix=/usr/local/ --enable-shared --enable-mpi 
--enable-openmp --enable-threads --enable-avx --enable-avx2


Compilation of the libraries and check showed no errors.


Best regards,

Michael

Am 30.12.2024 um 19:38 schrieb Laurence Marks:
> At what level of optimization? Once I replaced the "$omp simd" with 
> "$omp parallel do" charge.f compiled fine with -O0-3 and with/without 
> -qopenmp.
>
> -c -xAVX2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback 
> -assume buffered_io -O3 (-qopenmp)
>
> N.B., simpler is probably to just comment out the $omp simd 
> completely, as it is not central to any time-sensitive code, charge.f 
> is intended to be accurate and well-conditioned instead.
>
> On Mon, Dec 30, 2024 at 12:24 PM Fecher, Gerhard <fecher at uni-mainz.de> 
> wrote:
>
>     I don't have troubles with charge.f, see my next mail
>     I just have to cook and eat my dinner first
>
>     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
>     Laurence Marks [laurence.marks at gmail.com]
>     Gesendet: Montag, 30. Dezember 2024 19:09
>     An: A Mailing list for WIEN2k users
>     Betreff: Re: [Wien] ifort classic compiler now discontinued in
>     one-api 2025.0 online repositories
>
>     Probably better to include a space after:
>     sed 's/ simd / parallel do /' charge.f_old > charge.f
>     N.B., I have not checked the accuracy. While dnrm2 is very
>     accurate, Intel's ddot is not for whatever reason.
>     ___
>     Emeritus Professor Laurence Marks (Laurie)
>     Department of Materials Science and Engineering, Northwestern
>     University
>     www.numis.northwestern.edu
>     <http://www.numis.northwestern.edu><http://www.numis.northwestern.edu>
>     "Research is to see what everybody else has seen, and to think
>     what nobody else has thought" Albert Szent-Györgyi
>
>     On Mon, Dec 30, 2024, 11:38 Laurence Marks
>     <laurence.marks at gmail.com<mailto:laurence.marks at gmail.com>> wrote:
>     Try this:
>
>     cd $WIENROOT/SRC_Globals
>     cp charge.f charge.f_old
>     sed 's/ simd / parallel do/' charge.f_old > charge.f
>
>     At least with my version of ifx (ifx (IFORT) 2021.1 Beta 20201113)
>     the "$omp simd" lines fail even without -qopenmp. However, when
>     they are converted to a straight parallel do they work fine. There
>     are some pages noting issues if you search for "ifx omp simd".
>
>     On Fri, Dec 27, 2024 at 11:49 AM Laurence Marks
>     <laurence.marks at gmail.com<mailto:laurence.marks at gmail.com>> wrote:
>     I will send a few variants of charge.f next week. The cleanest
>     solution is probably to add to relevant routines something like
>     #ifdef _IFX
>     $NOOPTOMIZE
>     #endif
>
>     I don't have access at the moment to the ifx docu to determine
>     what the right directives are.
>
>     ---
>     Emeritus Professor Laurence Marks (Laurie)
>     www.numis.northwestern.edu
>     <http://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, 16:04 Gavin Abo
>     <gabo13279 at gmail.com<mailto:gabo13279 at gmail.com>> wrote:
>
>     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
>
>     __________________
>     Wien mailing list
>     Wien at zeus.theochem.tuwien.ac.at<mailto: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
>
>
>     --
>     Emeritus Professor Laurence Marks (Laurie)
>     Northwestern University
>     Webpage<http://www.numis.northwestern.edu> and Google Scholar
>     link<http://scholar.google.com/citations?user=zmHhI9gAAAAJ&hl=en
>     <http://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
>     _______________________________________________
>     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
>
>
>
> -- 
> Emeritus Professor Laurence Marks (Laurie)
> Northwestern University
> Webpage <http://www.numis.northwestern.edu> and Google Scholar link 
> <http://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
>
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20241231/bd285743/attachment-0001.htm>


More information about the Wien mailing list