I'm building abinit 8.10.2 with Intel Parallel Studio XE 2019. The configuration (intel env variables set by psxevars.sh) is:
Code: Select all
enable_debug="no"
enable_optim="yes"
enable_avx_safe_mode="no"
prefix="/usr/local/abinit"
CC="mpiicc"
CXX="mpiicpc"
FC="mpiifort"
FCFLAGS_OPENMP="-qopenmp"
FCFLAGS_OPTIM="-O1 -fp-model precise"
FCFLAGS_EXTRA="-heap-arrays"
enable_mpi="yes"
enable_mpi_inplace="yes"
enable_mpi_io="yes"
MPI_RUNNER="${I_MPI_ROOT}/intel64/bin/mpirun"
SERIAL_RUNNER="${I_MPI_ROOT}/intel64/bin/mpirun -np 1"
enable_gpu="no"
with_trio_flavor="psml+netcdf"
with_psml_incs="-I/usr/local/psml/include"
with_psml_libs="-Wl,--start-group /usr/local/psml/lib/libpsml.a /usr/local/xmlf90/lib/libxmlf90.a -Wl,--end-group"
with_netcdf_incs="-I/usr/local/netcdf/include -I/usr/local/hdf5/include"
with_netcdf_libs="-L/usr/local/netcdf/lib -L/usr/local/hdf5/lib -lnetcdf -lnetcdff -lhdf5_fortran -lhdf5_hl -lhdf5"
with_fft_flavor="fftw3"
with_fft_incs="-I${MKLROOT}/include"
with_fft_libs="-L${MKLROOT}/lib/intel64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl"
with_linalg_flavor="mkl+scalapack"
with_linalg_incs="-I${MKLROOT}/include"
with_linalg_libs="-L${MKLROOT}/lib/intel64 -lmkl_scalapack_lp64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -lmkl_blacs_intelmpi_lp64 -liomp5 -lpthread -lm -ldl"
with_math_flavor="gsl"
with_math_incs="-I/usr/gsl/include"
with_math_libs="-L/usr/local/gsl/lib -lgsl"
with_dft_flavor="libxc"
with_libxc_incs="-I/usr/local/libxc-3.0.1/include"
with_libxc_libs="-L/usr/local/libxc-3.0.1/lib -lxc -lxcf90"
enable_fallbacks="no"
enable_gw_dpc="yes"
enable_openmp="yes"
Everything compiles and builds OK and passes all tests except for four failures in the unitary tests, depending on choice of fft_flavor.
If fft_flavor = dfti or dfti threads (which define HAVE_FFT_DFTI), then tfftmkl_01-4 all fail. If fft_flavor = fftw3 or fftw3-threads (which define HAVE_FFT_FFTW3), then tfftfftw3_01-4 all fail. The only fft_flavor that doesn't fail any tests is fftw3-mkl (which defines HAVE_FFT_FFTW3_MKL).
I traced the errors to tests of the double precision version of dfti_c2c_* routines around line 1488 in src/53_ffts/m_fft.F90. The calls to fftw3_seqfourdp (for HAVE_FFT_FFTW3) or dfti_seqfourdp (for HAVE_FFT_DFTI) fail, but only for cplex=1. These end up calling fftw3_r2c_op & fftw3_c2r_op in src/52_fft_mpi_noabirule/m_fftw3.F90 and dfti_r2c_op & dfti_c2r_op in src/52_fft_mpi_noabirule/m_dfti.F90, respectively. The reason that fft_flavor=fftw3-mkl doesn't fail is just that it is not tested (doesn't set either HAVE_FFT_DFTI or HAVE_FFT_FFTW3).
There is a comment at the beginning of m_fftw3.F90 that says
This is followed by definition of DEV_RC_BUG, which shows up later in the code for fftw3_r2c and fftw3_c2r, where it looks like having DEV_RC_BUG defined would force them to fail. However, the definition of DEV_RC_BUG is commented out, so it tries to execute the code and yet it still fails. There is no corresponding comment or DEV_RC_BUG statements in m_dfti.F90.It seems that MKL wrappers do not like the advanced interfaces for
r2c and c2r transforms although they work fine if the true FFTW3 library is used.
This all leaves me wondering whether the errors I am seeing in these unitary tests are related to this comment about the MKL wrappers not liking the advanced interfaces for the r2c and c2r transforms. Is this an outstanding bug that was never resolved?
Should I worry about the unitary tests failing or just ignore them? Are the fftw3/dfti_r2c/c2r operations critical for abinit?