[Wien] ifort classic compiler now discontinued in one-api 2025.0 online repositories
Michael Fechtelkord
Michael.Fechtelkord at ruhr-uni-bochum.de
Sun Jan 5 12:33:55 CET 2025
LAPW0 works in my ifx compilation (currently 2024.2 because it still
contains ifort, gcc is 13.2). When I run the following configure for
fftw3 and compile:
FC=ifort F77=ifort CC=gcc CFLAGS="-O3 -march=native -mavx2" FCFLAGS="-O3
-xAVX2 -diag-disable=10448"\
./configure --prefix=/usr/local/ --enable-shared --enable-mpi
--enable-openmp --enable-threads --enable-avx --enable-avx2
there is no compilation error for 3ddens. Do I change to
FC=ifx F77=ifx CC=gcc CFLAGS="-O3 -march=native -mavx2" FCFLAGS="-O3
-xAVX2"\
./configure --prefix=/usr/local/ --enable-shared --enable-mpi
--enable-openmp --enable-threads --enable-avx --enable-avx2
I got the error for 3ddens in compilation:
/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
FFTW uses also a fortran part, except you switch it of with
--disable-fortran: Disables inclusion of legacy-Fortran wrapper routines
(see
Chapter 8 [Calling FFTW from Legacy Fortran], page 87) in the standard FFTW
libraries. These wrapper routines increase the library size by only a
negligible amount,
so they are included by default as long as the configure script finds a
Fortran
compiler on your system. (To specify a particular Fortran compiler foo,
pass F77=foo
to configure.)
So it is possible that the problem is due to different wrappers when I
specify ifort or ifx as particular Fortran compiler.
Best regards,
Michael
Am 05.01.2025 um 09:49 schrieb Fecher, Gerhard:
> Sorry, ifort was a typo, fftw3 is pure C++ library and does not need any Fortran compiler
> I used for fftw3 both the old icc and the new icx, without observing any remarkable difference during run-time..
> (I iused icx (instead of gcc) already since the 2023 OneAPI without problems)
> For ifx (or ifort) the Fortran wrappers for fftw are in the OneAPI include directories
> (for gnu you probably may need the switch --with-g77-wrappers in configure)
>
> I wonder why in your case 3ddens fails, but lapw0 succeeds (does it ?)
>
> 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: Samstag, 4. Januar 2025 19:49
> An: A Mailing list for WIEN2k users
> Cc: Michael Fechtelkord
> Betreff: Re: [Wien] ifort classic compiler now discontinued in one-api 2025.0 online repositories
>
> Dear Gerhard,
>
>
> thanks for all your hints, they showed no difference. The link error
> still occurred. But I saw that you used ifort, instead of ifx for
> compiling the fftw3 libraries. And that makes the difference.
>
> When I compile the fftw libraries with ifx and gcc the link error occurs
> for 3ddens. When I compile fftw3 with ifort and gcc, no error occurs in
> compilation of 3ddens.
>
> I have no idea where the difference is.
>
> In the 2025 oneapi version ifort and icc do not exist any longer and
> people cannot use it to compile the fftw3 library. So we have now to
> find out what ifort does different compared to ifx when it compiles the
> fftw3 code concerning intel threading.
>
>
> Thanks again for your help and happy new year!
>
>
> Best regards,
>
> Michael
>
>
> Am 31.12.2024 um 17:42 schrieb Fecher, Gerhard:
>> Dear Michael,
>> as I reported before all routines were successfully compiled using
>> current:FOPT:-free -O2 -xHost -fp-model=strict -DINTEL_VML -traceback -assume buffered_io -I$(MKLROOT)
>> or
>> current:FOPT:-free -w -O3 -xHost -fp-model=precise -DINTEL_VML -traceback -assume buffered_io -I$(MKLROOT)
>>
>> the only remaining problem (after updated some routines according to Preter and Gavin) that remained is tthat
>> lapw0 does not run (produces a segmentation fault) when setting OMP_NUM_THREADS other than 1, however setting of MKL_NUM_THREADS works
>> (this still remains when using the update of charge.f as suggested by Laurence)
>>
>> In my case 3ddens has no problems with fftw3
>> I suggest to use a local directory for it in your home directory, I had problems at runtime with fftw3 from the OpenSuse repositories installed in /usr/lib64
>> I also suggest to start with less optimization switches when making fftw3
>> I guess you better use only one of --enable-openmp --enable-threads and you should check that make uses intel threading
>> maybe your configure is not complete and you need also to set a correct LD
>> I compiled it with ifort and icc
>> I used at least something like
>> configure --prefix=/myhomepath/lib/FFTW3 \
>> CC=icc CFLAGS="-O3 -xHost -diag-disable=10441" \
>> --enable-shared --enable-openmp
>> and for mpi in addition:
>> MPICC=mpiicc --enable-mpi LDFLAGS=-L/path/to/mpi/libs CPPFLAGS=-I/path/to/mpi/include ...’
>>
>> check the available configuration switches using configure --help=short
>> If making different optimized versions, you can also give a version --comand-suffix=SUFFIX
>>
>> for lapw0 you can check wether you use the correct fftw3 using: ldd lapw0
>> is it the one you intended to be used ? Check also your LD_LIBRARY_PATH
>>
>>
>> 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: Dienstag, 31. Dezember 2024 13:05
>> An: A Mailing list for WIEN2k users
>> Cc: Michael Fechtelkord
>> Betreff: Re: [Wien] ifort classic compiler now discontinued in one-api 2025.0 online repositories
>>
>> 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<mailto: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<mailto:wien-bounces at zeus.theochem.tuwien.ac.at>] im Auftrag von Laurence Marks [laurence.marks at gmail.com<mailto: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><mailto: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><mailto: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
>> "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><mailto: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><mailto: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>
>> "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<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>
>> "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<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
>>
>>
>> --
>> 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<mailto: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
> _______________________________________________
> 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/
More information about the Wien
mailing list