FFT tests failing when linking against the MKL interface for FFTW
I was trying to link against the MKL interface for the FFTW routines, which configures and compiles fine, but then all of the tests involving the FFTW fail with large numerical errors. I also ran into similar failures when linking directly against the FFTW, although only with some compilers. For instance, I was able to build the FFTW and Nektar with GCC 10 and all the tests pass, while compiling with GCC 12 resulted in failing FFT tests. Also using the newer Intel oneAPI compilers caused the FFT tests to fail, while using the Intel classic 2019 compiler allowed all tests to pass. Any version of the MKL I tried linking against always resulted in the tests failing.
I found this post on the intel community forums about someone running into a similar problem when switching from FFTW to the MKL, albeit with no direct connection to Nektar; however, the problem seemed to be a case of using the FFTW routines in a manner which was not strictly compliant with the FFTW specification, but which the FFTW library generally handled anyway, while the MKL did not. This would seem like a plausible scenario for the behaviour I am seeing, where depending on what the compiler does can result in diverging outcomes, since using the library outside the specification would give no guarantees on the outcome. In particular, the failures seem to be occurring with the newer compilers, likely meaning better optimizations are causing the unspecified behaviour to change and exposing the incorrect usage.
I've included an example of the kind of output I am seeing for the failing tests (just for one test, since they are all of a similar nature). The tests seem to run correctly, but the errors are large.
372/620 Test #372: IncNavierStokesSolver_ChanFlow_3DH1D_FFT ..........................................***Failed 3.58 sec
Failed tolerance match.
Expected: 3.61998e-16 +/- 1e-06
Result: 0.129099
Failed tolerance match.
Expected: 2.815e-14 +/- 1e-06
Result: 0.816497
Failed tolerance match.
Expected: 1.88738e-15 +/- 1e-06
Result: 0.25
Failed tolerance match.
Expected: 1.4988e-13 +/- 1e-06
Result: 2
=== Output ===
=======================================================================
EquationType: UnsteadyNavierStokes
Session Name: ChanFlow_3DH1D_FFT
Spatial Dim.: 3
Max SEM Exp. Order: 3
Quasi-3D: Homogeneous in z-direction
Expansion Dim.: 3
Num. Hom. Modes (z): 20
Hom. length (LZ): 1
FFT Type: FFTW
Projection Type: Continuous Galerkin
Advection: explicit
Diffusion: implicit
Time Step: 0.001
No. of Steps: 1000
Checkpoints (steps): 1000
Integration Type: IMEX
Splitting Scheme: Velocity correction (strong press. form)
=======================================================================
Initial Conditions:
- Field u: 0
- Field v: 0
- Field w: 0
- Field p: 0
Writing: "ChanFlow_3DH1D_FFT_0.chk" (0.000678557s, XML)
Steps: 1000 Time: 1 CPU Time: 2.53552s
Writing: "ChanFlow_3DH1D_FFT_1.chk" (0.0014302s, XML)
Time-integration : 2.53552s
Writing: "ChanFlow_3DH1D_FFT.fld" (0.00121727s, XML)
-------------------------------------------
Total Computation Time = 3s
-------------------------------------------
L 2 error (variable u) : 0.129099
L inf error (variable u) : 0.25
L 2 error (variable v) : 0
L inf error (variable v) : 0
L 2 error (variable w) : 0
L inf error (variable w) : 0
L 2 error (variable p) : 0.816497
L inf error (variable p) : 2
=== Errors ===
As it turns out, I will most likely not be needing the FFTW functionality for my work, so this is not a critical issue for me, but I thought it worth flagging in case others run into similar issues and might be interested in exploring it further.