[Wien] ifort classic compiler now discontinued in one-api 2025.0 online repositories
Fecher, Gerhard
fecher at uni-mainz.de
Sun Jan 5 09:49:23 CET 2025
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
More information about the Wien
mailing list