[Wien] ifort classic compiler now discontinued in one-api 2025.0 online repositories
Fecher, Gerhard
fecher at uni-mainz.de
Tue Dec 31 17:42:34 CET 2024
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/
More information about the Wien
mailing list