The first element of `mvfftw_r2c(fftplanopt = 1L)` could always be 0 on some operating systems

[dipterix]

fftwtools::mvfftw_r2c(..., fftplanopt = 1L) initializes data before planning.

I was recently developing a signal toolbox until I encountered a weird issue when set fftplanopt=1L. On some platforms (mainly ubuntu), the data gets centered automatically and the first element of the results are always 0+0i.

After some researches, I found the following documentation:

https://www.fftw.org/fftw3_doc/Planner-Flags.html

Important: the planner overwrites the input array during planning unless a saved plan (see Wisdom) is available for that problem, so you should initialize your input data after creating the plan. The only exceptions to this are the FFTW_ESTIMATE and FFTW_WISDOM_ONLY flags

When fftplanopt=0L, the plan is using FFTW_ESTIMATE, hence we obtain the correct result. However, when fftplanopt=1L, the plan uses FFTW_MEASURE. Since the data is NOT initialized after creating plans, the program result in unexpected behavior.

Depending on the operating systems, fftplanopt=1L might lead to inconsistent results. For example, on Ubuntu 20.04.3, I was able to obtain the correct results; but on osx, I got inconsistent results.

See Github Action check here

https://github.com/dipterix/ravetools/runs/3968492814?check_suite_focus=true

b coincides with results from stats::fft, while d is generated by fftwtools::mvfftw_r2c(x, 1, 1), with fftplanopt=1L.

The difference is the first element. d[0] is zero, meaning the data is centered somewhere. However, that's not true.

[krahim]

Please let me know if you come across any fixes.

[dipterix]

This is my workaround:

https://github.com/dipterix/ravetools/blob/e59d135b20c0a30f0bc0e5d8c41eca4cb489f9c3/src/ffts.cpp#L118-L122