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

Mon Dec 30 20:15:03 CET 2024

Dear Laurence, it was -O2, see below.

Dear Laurence, Peter, dear all
for me it seems that there are only two or three smaller issues when using ifx
and there should be no need to switch off optimization.

There is no need to install the complete OneAPI package (base + hpc toolkits),
therefore I installed only the latest Intel cpp and fortran essentials 2025.0.1.27
(these include the MKL (both) and the MPI (fortran) libraries)
... and I did read the compiler manual at least partially.

I unpacked and used the downloaded Wien2k_24.1 (downloaded 09 July 2024) for the tests

Before compiling, I cleaned the SRC directories with the clean_SRC script from the ncm Version (with the rm lines commented/removed)
to avoid a little bit that old stuff sneaks in at least partially (see also remarks below).

siteconfig was used with entries in the OPTION file as given below,
- the only part that had problems with ifx was lapw5 independent on the optimization settings (-O0, -O, -O2)
- it is interesting to note that dstart gave troubles when using -O0 ???

A test on a system that I use regularly was running,
however, lapw0 did not run when compiled with -qopenmp and setting a number of threads
(OMP_NUM_THREADS or omp_global:) other than 1
I did not yet find the reason for the "Speicherschutzverletzung", seems not to be related to compiler switches.

The (not very systematic) timing behaviour of a complete scf run
(19 cycles to convergence) was determined for
   k-points:   364, aus (23 23 23)
   R-MT*K-MAX: 9.0
on a machine with 2 x Xeon(R) E5-2697 v4 (2x18=36 cores, Hyperthreading off) and OpenSuse Leap 15.5
W2k 23.2 OneAPI 2023.1 (ifort)
         time [m:s]
 cores   omp=1     omp=4
   8     10:50     7:10
  16     10:10     7:16
W2k 24.1 OneAPI 2023.1 (ifort); (with LIBXC)
  16     13:37     9:20
W2k 24.1 OneAPI 2025.0 (ifx)
         omp=1     omp=4 (lapw0 without omp)
   8     14:43     13:23
  16     14:50     13:00

cores is the # of cores used for k-parallel
Obviously Wien2k 24.1 was already slower than 23.2 with ifort
I have to search for the reason.
A test with Wien2k 23.1 showed that it is not needed to use more then 12 cores for k-parallel
for the present case using up to 72 cores on Xeon Platinum CPUs.

Hints:
- make sure that you use the correct libraries using ldd (e.g.: ldd lapw0)
  should be the same as in OPTIONS and LD_LIBRARY_PATH
- siteconfig is setting the MKL_TARGET_ARCH to "nicht"
  note that the latest OneAPI does not support 32 bit anymore and "intel64" is obsolete
  (somehow siteconfig does not recognize the link in the MKL lib directory ??)
- the switch -xHost works only on Intel CPUs; for AMD EPYC one may use -xAVX or -xAVX2 for example
  note (-xAVX2 overrides -xHost)
- there should be no need to recompile own libraries, those created with ifort and/or icc should be compatible
- "-fp-model=strict" may be replaced by "-fp-model=precise" (I did not test it up to now)

Remarks:
- "-standard-semantics" is used to test the compatibility with fortran standards
  it may be used as "-standard-semantics stand f90" to test compatibility with the Fortran 90 standard
  in case it does not, compilation will stop with an error message.
  it does not influence optimizations or other behaviour of ifx or icx.
  This is very helpful to find obsolete language features.
- the directory SRC_lapw0 contains an executable lapw0_mpi from 30.6.2022, that is copied into the Wien2k directory
  this is confusing as I did not ask siteconfig to produce any mpi version.
- parallel make (e.g. make -j 8 ...) is much faster

**** Error when compiling dstart with -O0:
     /ld: atom_read.o: in function `rholm_.t94p.t95p': ifxe5kO5x.i:(.text+0x27): undefined reference to `rholm_'
**** vanishes when using -O1 or -O2

**** Error when compiling lapw5 (independent on optimisation i.e. -O switch)
  SearchZ.F: REAL version extracted
  ifx  -free -O2 -fp-model=strict -DINTEL_VML -traceback -assume buffered_io -I/home/fecher/intel_2025/oneapi/mkl/2025.0 -c SearchZ_tmp_.F
          #0 0x0000564b13047b41
   ...
         #20 0x0000564b1316a704
         #21 0x0000145992bb424d __libc_start_main + 239
         #22 0x0000564b12dc519e
   SearchZ_tmp_.F(114): error #5623: **Internal compiler error: internal abort** 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.
                call RTBIS(RHOSTM,X1,X2,XACC,CTarget,ISTM,RT)
   ---------------------------^
   compilation aborted for SearchZ_tmp_.F (code 3)
**** did not vanish with other optimization switches(-O0, -O1, -xHost, -xAVX2)

copies from WIEN2k_OPTIONS
current:FOPT:-free -O2 -xHost -fp-model=strict -DINTEL_VML -traceback -assume buffered_io -I$(MKLROOT)
current:FPOPT:-O -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback -assume buffered_io -I$(MKLROOT)/include
current:OMP_SWITCH:-qopenmp
current:OMP_SWITCHP:-qopenmp
current:LDFLAGS:$(FOPT) -L$(MKLROOT)/lib -lpthread -lm -ldl -liomp5
current:DPARALLEL:'-DParallel'
current:R_LIBS:-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core
current:RP_LIBS:$(R_LIBS)
current:FFTWROOT:/usr/
current:FFTW_VERSION:FFTW3
current:FFTW_LIB:lib64
current:FFTW_LIBNAME:fftw3
current:LIBXCROOT:
current:LIBXC_FORTRAN:
current:LIBXC_LIBNAME:
current:LIBXC_LIBDNAME:
current:SCALAPACKROOT:
current:SCALAPACK_LIBNAME:
current:BLACSROOT:
current:BLACS_LIBNAME:
current:ELPAROOT:
current:ELPA_VERSION:
current:ELPA_LIB:
current:ELPA_LIBNAME:
current:MPIRUN:mpirun -np _NP_ -machinefile _HOSTS_ _EXEC_
current:CORES_PER_NODE:1
current:MKL_TARGET_ARCH:

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
________________________________________