topic Re:1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3 in Intel® oneAPI Math Kernel Library

1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3

al42and — Wed, 21 Dec 2022 12:59:26 GMT

Hello!

The code below worked fine with oneAPI 2022.3 release but fails now with 2023.0:

$ icpx --version Intel(R) oneAPI DPC++/C++ Compiler 2023.0.0 (2023.0.0.20221201) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /opt/tcbsys/intel-oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm Configuration file: /opt/tcbsys/intel-oneapi/2023.0.0/compiler/2023.0.0/linux/bin-llvm/../bin/icpx.cfg $ icpx -qmkl mkl-cpu.cpp -o mkl-cpu && ./mkl-cpu Error calling DftiCommitDescriptor(dsc): Intel MKL DFTI ERROR: Inconsistent configuration parameters # On the same machine, loading a different environment: $ icpx --version Intel(R) oneAPI DPC++/C++ Compiler 2022.2.0 (2022.2.0.20220730) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /opt/tcbsys/intel-oneapi/2022.3.0/compiler/2022.2.0/linux/bin-llvm Configuration file: /opt/tcbsys/intel-oneapi/2022.3.0/compiler/2022.2.0/linux/bin/icpx.cfg $ icpx -qmkl mkl-cpu.cpp -o mkl-cpu && ./mkl-cpu Success!

It looks like setting DFTI_INPUT_DISTANCE is what triggers the error.

Is there any workaround available? I could not find anything related in the "Known issues" section of the release.

mkl-cpu.cpp:

#include <cstdlib> #include <iostream> #include <mkl_dfti.h> #include <mkl_service.h> #include <mkl_types.h> void checkStatus(MKL_LONG status, const char *cmd) { if (status != 0) { std::cout << "Error calling " << cmd << ": " << DftiErrorMessage(status) << std::endl; std::exit(-1); } } #define CHECK(v) checkStatus(v, #v) int main() { MKL_LONG ny = 15, nx = 18, nyc = 8, status; DFTI_DESCRIPTOR *dsc; CHECK(DftiCreateDescriptor(&dsc, DFTI_SINGLE, DFTI_REAL, 1, ny)); MKL_LONG stride[2]; stride[0] = 0; stride[1] = 1; CHECK(DftiSetValue(dsc, DFTI_PLACEMENT, DFTI_INPLACE)); CHECK(DftiSetValue(dsc, DFTI_NUMBER_OF_TRANSFORMS, nx)); CHECK(DftiSetValue(dsc, DFTI_INPUT_DISTANCE, 2 * nyc)); CHECK(DftiSetValue(dsc, DFTI_INPUT_STRIDES, stride)); CHECK(DftiSetValue(dsc, DFTI_OUTPUT_DISTANCE, 2 * nyc)); CHECK(DftiSetValue(dsc, DFTI_OUTPUT_STRIDES, stride)); CHECK(DftiCommitDescriptor(dsc)); std::cout << "Success!" << std::endl; return 0; }

Re:1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3

ShanmukhS_Intel — Fri, 23 Dec 2022 13:45:18 GMT

Hi Andrey,

Thanks for posting on Intel Communities.

We have compiled and executed the shared source code as per the mentioned versions in your earlier thread and were able to reproduce the issue at our end. We will get back to you soon with an update.

Best Regards,

Shanmukh.SS

Re:1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3

ShanmukhS_Intel — Thu, 29 Dec 2022 18:56:48 GMT

Hi Andrey,

Could you please update your code snippet to DFTI_NOT_INPLACE as mentioned below?

CHECK(DftiSetValue(dsc, DFTI_PLACEMENT, DFTI_NOT_INPLACE));

More details regarding the usage is mentioned under the below link.

https://www.intel.com/content/www/us/en/develop/documentation/onemkl-developer-reference-c/top/fourier-transform-functions/fft-functions/configuration-settings/dfti-input-distance-dfti-output-distance.html

Best Regards,

Shanmukh.SS

Re: Re:1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.

al42and — Thu, 29 Dec 2022 20:32:09 GMT

Hi Shanmukh.SS!

Switching to the out-of-place transform avoids the problem. But I don't see why in-place should not work. From docs:

For in-place transforms (DFTI_PLACEMENT=DFTI_INPLACE ), the configuration set by DFTI_OUTPUT_DISTANCE is ignored when the element types in the forward and backward domains are the same. If they are different, set DFTI_OUTPUT_DISTANCE explicitly (even though the transform is in-place). Ensure a consistent configuration for in-place transforms, that is, the locations of the data sets on input and output must coincide.

We have different forward and backward domains here, so "a consistent configuration" must be set. Could you please clarify why the configuration in the example code was considered consistent in 2022.3, but is not consistent in 2023.0?

Best,

Andrey

Re:1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3

ShanmukhS_Intel — Wed, 04 Jan 2023 15:04:36 GMT

Hi Andrey,

Ensure a consistent configuration for in-place transforms, that is, the locations of the data sets on input and output must coincide.

>>Distances are in units of elements in the input or output domain. This is a real transform, so input and output are different domains, one real and one complex.

For the data locations of input and output to coincide, they must have different distance values,

e.g. 2*nyc for input and nyc for output for a forward transform. This example is setting both distances to the same value (2*nyc), so the datasets on input and output won't coincide. This is an incorrect usage. It wasn't supported in 2022.2 either, but the change in the 2023.0 release was to check for it and return the error to make the code more user-friendly.

Best Regards,

Shanmukh.SS

Re: Re:1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.

al42and — Mon, 09 Jan 2023 16:44:44 GMT

Thanks, Shanmukh.

I see now. I missed this part in the docs.

However, it seems that the meaning of DFTI_OUTPUT_DISTANCE changed between oneAPI 2022.3 and oneAPI 2023.0.

Let's look at an out-of-place transform (code below) for simplicity.

That's fine, DFTI_OUTPUT_DISTANCE=nyc produces correct results. But to get the correct behavior with 2022.2, we need to use DFTI_OUTPUT_DISTANCE=2*nyc:

$ icpx --version Intel(R) oneAPI DPC++/C++ Compiler 2022.2.0 (2022.2.0.20220730) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /opt/tcbsys/intel-oneapi/2022.3.0/compiler/2022.2.0/linux/bin-llvm Configuration file: /opt/tcbsys/intel-oneapi/2022.3.0/compiler/2022.2.0/linux/bin/icpx.cfg $ icpx -DMULT=1 -qmkl mkl.cpp -o mkl && ./mkl out[150] = -24.7429 $ icpx -DMULT=2 -qmkl mkl.cpp -o mkl && ./mkl out[150] = -28.8722

Unfortunately, I cannot find the documentation for older releases of oneMKL on the Intel website, but I don't see anything relevant in the release notes.

Code:

#include <cstdlib> #include <iostream> #include <mkl_dfti.h> #include <mkl_service.h> #include <mkl_types.h> #include <vector> void checkStatus(MKL_LONG status, const char *cmd) { if (status != 0) { std::cout << "Error calling " << cmd << ": " << DftiErrorMessage(status) << std::endl; std::exit(-1); } } const float inputdata[500] = { -3.5, 6.3, 1.2, 0.3, 1.1, -5.7, 5.8, -1.9, -6.3, -1.4, 7.4, 2.4, -9.9, -7.2, 5.4, 6.1, -1.9, -7.6, 1.4, -3.5, 0.7, 5.6, -4.2, -1.1, -4.4, -6.3, -7.2, 4.6, -3.0, -0.9, 7.2, 2.5, -3.6, 6.1, -3.2, -2.1, 6.5, -0.4, -9.0, 2.3, 8.4, 4.0, -5.2, -9.0, 4.7, -3.7, -2.0, -9.5, -3.9, -3.6, 7.1, 0.8, -0.6, 5.2, -9.3, -4.5, 5.9, 2.2, -5.8, 5.0, 1.2, -0.1, 2.2, 0.2, -7.7, 1.9, -8.4, 4.4, 2.3, -2.9, 6.7, 2.7, 5.8, -3.6, 8.9, 8.9, 4.3, 9.1, 9.3, -8.7, 4.1, 9.6, -6.2, 6.6, -9.3, 8.2, 4.5, 6.2, 9.4, -8.0, -6.8, -3.3, 7.2, 1.7, 0.6, -4.9, 9.8, 1.3, 3.2, -0.2, 9.9, 4.4, -9.9, -7.2, 4.4, 4.7, 7.2, -0.3, 0.3, -2.1, 8.4, -2.1, -6.1, 4.1, -5.9, -2.2, -3.8, 5.2, -8.2, -7.8, -8.8, 6.7, -9.5, -4.2, 0.8, 8.3, 5.2, -9.0, 8.7, 9.8, -9.9, -7.8, -8.3, 9.0, -2.8, -9.2, -9.6, 8.4, 2.5, 6.0, -0.4, 1.3, -0.5, 9.1, -9.5, -0.8, 1.9, -6.2, 4.3, -3.8, 8.6, -1.9, -2.1, -0.4, -7.1, -3.7, 9.1, -6.4, -0.6, 2.5, 8.0, -5.2, -9.8, -4.3, 4.5, 1.7, 9.3, 9.2, 1.0, 5.3, -4.5, 6.4, -6.6, 3.1, -6.8, 2.1, 2.0, 7.3, 8.6, 5.0, 5.2, 0.4, -7.1, 4.5, -9.2, -9.1, 0.2, -6.3, -1.1, -9.6, 7.4, -3.7, -5.5, 2.6, -3.5, -0.7, 9.0, 9.8, -8.0, 3.6, 3.0, -2.2, -2.8, 0.8, 9.0, 2.8, 7.7, -0.7, -5.0, -1.8, -2.3, -0.4, -6.2, -9.1, -9.2, 0.5, 5.7, -3.9, 2.1, 0.6, 0.4, 9.1, 7.4, 7.1, -2.5, 7.3, 7.8, -4.3, 6.3, -0.8, -3.8, -1.5, 6.6, 2.3, 3.9, -4.6, 5.8, -7.4, 5.9, 2.8, 4.7, 3.9, -5.4, 9.1, -1.6, -1.9, -4.2, -2.6, 0.6, -5.1, 1.8, 5.2, 4.0, -6.2, 6.5, -9.1, 0.5, 2.1, 7.1, -8.6, 7.6, -9.7, -4.6, -5.7, 6.1, -1.8, -7.3, 9.4, 8.0, -2.6, -1.8, 5.7, 9.3, -7.9, 7.4, 6.3, 2.0, 9.6, -4.5, -6.2, 6.1, 2.3, 0.8, 5.9, -2.8, -3.5, -1.5, 6.0, -4.9, 3.5, 7.7, -4.2, -9.7, 2.4, 8.1, 5.9, 3.4, -7.5, 7.5, 2.6, 4.7, 2.7, 2.2, 2.6, 6.2, 7.5, 0.2, -6.4, -2.8, -0.5, -0.3, 0.4, 1.2, 3.5, -4.0, -0.5, 9.3, -7.2, 8.5, -5.5, -1.7, -5.3, 0.3, 3.9, -3.6, -3.6, 4.7, -8.1, 1.4, 4.0, 1.3, -4.3, -8.8, -7.3, 6.3, -7.5, -9.0, 9.1, 4.5, -1.9, 1.9, 9.9, -1.7, -9.1, -5.1, 8.5, -9.3, 2.1, -5.8, -3.6, -0.8, -0.9, -3.3, -2.7, 7.0, -7.2, -5.0, 7.4, -1.4, 0.0, -4.5, -9.7, 0.7, -1.0, -9.1, -5.3, 4.3, 3.4, -6.6, 9.8, -1.1, 8.9, 5.0, 2.9, 0.2, -2.9, 0.8, 6.7, -0.6, 0.6, 4.1, 5.3, -1.7, -0.3, 4.2, 3.7, -8.3, 4.0, 1.3, 6.3, 0.2, 1.3, -1.1, -3.5, 2.8, -7.7, 6.2, -4.9, -9.9, 9.6, 3.0, -9.2, -8.0, -3.9, 7.9, -6.1, 6.0, 5.9, 9.6, 1.2, 6.2, 3.6, 2.1, 5.8, 9.2, -8.8, 8.8, -3.3, -9.2, 4.6, 1.8, 4.6, 2.9, -2.7, 4.2, 7.3, -0.4, 7.7, -7.0, 2.1, 0.3, 3.7, 3.3, -8.6, 9.8, 3.6, 3.1, 6.5, -2.4, 7.8, 7.5, 8.4, -2.8, -6.3, -5.1, -2.7, 9.3, -0.8, -9.2, 7.9, 8.9, 3.4, 0.1, -5.3, -6.8, 4.9, 4.3, -0.7, -2.2, -3.2, -7.5, -2.3, 0.0, 8.1, -9.2, -2.3, -5.7, 2.1, 2.6, 2.0, 0.3, -8.0, -2.0, -7.9, 6.6, 8.4, 4.0, -6.2, -6.9, -7.2, 7.7, -5.0, 5.3, 1.9, -5.3, -7.5, 8.8, 8.3, 9.0, 8.1, 3.2, 1.2, -5.4, -0.2, 2.1, -5.2, 9.5, 5.9, 5.6, -7.8, }; #define CHECK(v) checkStatus(v, #v) int main() { MKL_LONG ny = 15, nx = 18, nyc = 8, cx = 10, status; DFTI_DESCRIPTOR *dsc; CHECK(DftiCreateDescriptor(&dsc, DFTI_SINGLE, DFTI_REAL, 1, ny)); MKL_LONG stride[2]; stride[0] = 0; stride[1] = 1; CHECK(DftiSetValue(dsc, DFTI_PLACEMENT, DFTI_NOT_INPLACE)); CHECK(DftiSetValue(dsc, DFTI_NUMBER_OF_TRANSFORMS, nx)); CHECK(DftiSetValue(dsc, DFTI_INPUT_DISTANCE, ny)); CHECK(DftiSetValue(dsc, DFTI_INPUT_STRIDES, stride)); CHECK(DftiSetValue(dsc, DFTI_OUTPUT_DISTANCE, MULT * nyc)); CHECK(DftiSetValue(dsc, DFTI_OUTPUT_STRIDES, stride)); CHECK(DftiCommitDescriptor(dsc)); std::vector<float> in(cx * 2 * ny, 0); std::copy(inputdata, inputdata + cx * 2 * ny, in.begin()); std::vector<float> out(cx * 2 * ny); CHECK(DftiComputeForward(dsc, in.data(), out.data())); std::cout << "out[" << cx * ny << "] = " << out[cx * ny] << std::endl; return 0; }

Re: 1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3

ShanmukhS_Intel — Wed, 11 Jan 2023 11:10:46 GMT

Hi Andrey,

Unfortunately, I cannot find the documentation for older releases of oneMKL on the Intel website, but I don't see anything relevant in the release notes.

>>Thanks for the feedback. We will provide your feedback to the relevant team.

As your issue was resolved, Could you please let me know if we could help you with any other information?

Best Regards,

Shanmukh.SS

Re:1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3

ShanmukhS_Intel — Thu, 19 Jan 2023 15:18:18 GMT

Hi Andrey,

A gentle reminder:

As your issue was resolved, Could you please let me know if we could help you with any other information?

Best Regards,

Shanmukh.SS

Re: 1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3

al42and — Fri, 20 Jan 2023 15:24:53 GMT

Hi!

My issue is not resolved. My first example was indeed malformed, but my second example shows that even valid values of DFTI_INPUT_DISTANCE are interpreted differently in 2022.3 and 2023.0. So, the issue is not simply in plan creation function being more strict now. It is about changing the meaning of DFTI_INPUT_DISTANCE, and the previously valid code now behaving differently.

Best regards,

Andrey

Re:1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3

ShanmukhS_Intel — Tue, 31 Jan 2023 17:43:11 GMT

Hi Andrey,

We are discussing your issue internally. We will get back to you soon with an update.

Best Regards,

Shanmukh.SS

Re:1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3

ShanmukhS_Intel — Tue, 07 Feb 2023 14:12:41 GMT

Hi Andery,

We were able to reproduce the issue at our end and we have informed our developer team regarding the same. We will get back to you soon with an update. Thanks for all the details!!!

Best Regards,

Shanmukh.SS

Re: 1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3

ShanmukhS_Intel — Thu, 09 Feb 2023 11:31:48 GMT

Hi Andrey,

The former version's default complex storage and complex-conjugate-even packed format settings were still "DFTI_CONJUGATE_EVEN_STORAGE=DFTI_COMPLEX_REAL" and "DFTI_PACKED_FORMAT=DFTI_CCS_FORMAT" respectively, in oneMKL 2022.2. Unless these configuration settings are explicitly set otherwise, these prior default values mean that the strides and distance were (implicitly) counted in the "number of real floating-point values" in the backward domain when using oneMKL2022.2

The new and current default settings for complex storage and complex-conjugate-even packed format are "DFTI_CONJUGATE_EVEN_STORAGE=DFTI_COMPLEX_COMPLEX" and "DFTI_PACKED_FORMAT=DFTI_CCE_FORMAT", respectively. Unless these configuration settings are explicitly set otherwise, these default values now mean that the strides and distance are (implicitly) counted in the "number of complex floating point values" in the backward domain when using oneMKL2023.0

As per your statement, the distances are not interpreted similarly in either version, unless the configuration settings "DFTI_CONJUGATE_EVEN_STORAGE" and "DFTI_PACKED_FORMAT" are explicitly set.

Please find your source code modified (below for your reference). Regardless of the chosen value for MULT, the configuration settings "DFTI_CONJUGATE_EVEN_STORAGE" and "DFTI_PACKED_FORMAT" are explicitly set in the example.

You could execute it in both the MKL versions mentioned by you and check the results.

#include <cstdlib>
#include <iostream>
#include <mkl_dfti.h>
#include <mkl_service.h>
#include <mkl_types.h>
#include <vector>

void checkStatus(MKL_LONG status, const char *cmd) {
if (status != 0) {
std::cout << "Error calling " << cmd << ": " << DftiErrorMessage(status)
<< std::endl;
std::exit(-1);
}
}

const float inputdata[500] = {
-3.5, 6.3, 1.2, 0.3, 1.1, -5.7, 5.8, -1.9, -6.3, -1.4, 7.4, 2.4,
-9.9, -7.2, 5.4, 6.1, -1.9, -7.6, 1.4, -3.5, 0.7, 5.6, -4.2, -1.1,
-4.4, -6.3, -7.2, 4.6, -3.0, -0.9, 7.2, 2.5, -3.6, 6.1, -3.2, -2.1,
6.5, -0.4, -9.0, 2.3, 8.4, 4.0, -5.2, -9.0, 4.7, -3.7, -2.0, -9.5,
-3.9, -3.6, 7.1, 0.8, -0.6, 5.2, -9.3, -4.5, 5.9, 2.2, -5.8, 5.0,
1.2, -0.1, 2.2, 0.2, -7.7, 1.9, -8.4, 4.4, 2.3, -2.9, 6.7, 2.7,
5.8, -3.6, 8.9, 8.9, 4.3, 9.1, 9.3, -8.7, 4.1, 9.6, -6.2, 6.6,
-9.3, 8.2, 4.5, 6.2, 9.4, -8.0, -6.8, -3.3, 7.2, 1.7, 0.6, -4.9,
9.8, 1.3, 3.2, -0.2, 9.9, 4.4, -9.9, -7.2, 4.4, 4.7, 7.2, -0.3,
0.3, -2.1, 8.4, -2.1, -6.1, 4.1, -5.9, -2.2, -3.8, 5.2, -8.2, -7.8,
-8.8, 6.7, -9.5, -4.2, 0.8, 8.3, 5.2, -9.0, 8.7, 9.8, -9.9, -7.8,
-8.3, 9.0, -2.8, -9.2, -9.6, 8.4, 2.5, 6.0, -0.4, 1.3, -0.5, 9.1,
-9.5, -0.8, 1.9, -6.2, 4.3, -3.8, 8.6, -1.9, -2.1, -0.4, -7.1, -3.7,
9.1, -6.4, -0.6, 2.5, 8.0, -5.2, -9.8, -4.3, 4.5, 1.7, 9.3, 9.2,
1.0, 5.3, -4.5, 6.4, -6.6, 3.1, -6.8, 2.1, 2.0, 7.3, 8.6, 5.0,
5.2, 0.4, -7.1, 4.5, -9.2, -9.1, 0.2, -6.3, -1.1, -9.6, 7.4, -3.7,
-5.5, 2.6, -3.5, -0.7, 9.0, 9.8, -8.0, 3.6, 3.0, -2.2, -2.8, 0.8,
9.0, 2.8, 7.7, -0.7, -5.0, -1.8, -2.3, -0.4, -6.2, -9.1, -9.2, 0.5,
5.7, -3.9, 2.1, 0.6, 0.4, 9.1, 7.4, 7.1, -2.5, 7.3, 7.8, -4.3,
6.3, -0.8, -3.8, -1.5, 6.6, 2.3, 3.9, -4.6, 5.8, -7.4, 5.9, 2.8,
4.7, 3.9, -5.4, 9.1, -1.6, -1.9, -4.2, -2.6, 0.6, -5.1, 1.8, 5.2,
4.0, -6.2, 6.5, -9.1, 0.5, 2.1, 7.1, -8.6, 7.6, -9.7, -4.6, -5.7,
6.1, -1.8, -7.3, 9.4, 8.0, -2.6, -1.8, 5.7, 9.3, -7.9, 7.4, 6.3,
2.0, 9.6, -4.5, -6.2, 6.1, 2.3, 0.8, 5.9, -2.8, -3.5, -1.5, 6.0,
-4.9, 3.5, 7.7, -4.2, -9.7, 2.4, 8.1, 5.9, 3.4, -7.5, 7.5, 2.6,
4.7, 2.7, 2.2, 2.6, 6.2, 7.5, 0.2, -6.4, -2.8, -0.5, -0.3, 0.4,
1.2, 3.5, -4.0, -0.5, 9.3, -7.2, 8.5, -5.5, -1.7, -5.3, 0.3, 3.9,
-3.6, -3.6, 4.7, -8.1, 1.4, 4.0, 1.3, -4.3, -8.8, -7.3, 6.3, -7.5,
-9.0, 9.1, 4.5, -1.9, 1.9, 9.9, -1.7, -9.1, -5.1, 8.5, -9.3, 2.1,
-5.8, -3.6, -0.8, -0.9, -3.3, -2.7, 7.0, -7.2, -5.0, 7.4, -1.4, 0.0,
-4.5, -9.7, 0.7, -1.0, -9.1, -5.3, 4.3, 3.4, -6.6, 9.8, -1.1, 8.9,
5.0, 2.9, 0.2, -2.9, 0.8, 6.7, -0.6, 0.6, 4.1, 5.3, -1.7, -0.3,
4.2, 3.7, -8.3, 4.0, 1.3, 6.3, 0.2, 1.3, -1.1, -3.5, 2.8, -7.7,
6.2, -4.9, -9.9, 9.6, 3.0, -9.2, -8.0, -3.9, 7.9, -6.1, 6.0, 5.9,
9.6, 1.2, 6.2, 3.6, 2.1, 5.8, 9.2, -8.8, 8.8, -3.3, -9.2, 4.6,
1.8, 4.6, 2.9, -2.7, 4.2, 7.3, -0.4, 7.7, -7.0, 2.1, 0.3, 3.7,
3.3, -8.6, 9.8, 3.6, 3.1, 6.5, -2.4, 7.8, 7.5, 8.4, -2.8, -6.3,
-5.1, -2.7, 9.3, -0.8, -9.2, 7.9, 8.9, 3.4, 0.1, -5.3, -6.8, 4.9,
4.3, -0.7, -2.2, -3.2, -7.5, -2.3, 0.0, 8.1, -9.2, -2.3, -5.7, 2.1,
2.6, 2.0, 0.3, -8.0, -2.0, -7.9, 6.6, 8.4, 4.0, -6.2, -6.9, -7.2,
7.7, -5.0, 5.3, 1.9, -5.3, -7.5, 8.8, 8.3, 9.0, 8.1, 3.2, 1.2,
-5.4, -0.2, 2.1, -5.2, 9.5, 5.9, 5.6, -7.8,
};

#define CHECK(v) checkStatus(v, #v)

int main() {
MKL_LONG ny = 15, nx = 18, nyc = 8, cx = 10, status;
DFTI_DESCRIPTOR *dsc;

CHECK(DftiCreateDescriptor(&dsc, DFTI_SINGLE, DFTI_REAL, 1, ny));

MKL_LONG stride[2];
stride[0] = 0;
stride[1] = 1;
CHECK(DftiSetValue(dsc, DFTI_PLACEMENT, DFTI_NOT_INPLACE));
DftiSetValue(dsc, DFTI_CONJUGATE_EVEN_STORAGE, DFTI_COMPLEX_COMPLEX);
CHECK(DftiSetValue(dsc, DFTI_NUMBER_OF_TRANSFORMS, nx));
CHECK(DftiSetValue(dsc, DFTI_INPUT_DISTANCE, ny));
CHECK(DftiSetValue(dsc, DFTI_INPUT_STRIDES, stride));
CHECK(DftiSetValue(dsc, DFTI_OUTPUT_DISTANCE, MULT * nyc));
CHECK(DftiSetValue(dsc, DFTI_OUTPUT_STRIDES, stride));

CHECK(DftiCommitDescriptor(dsc));

std::vector<float> in(cx * 2 * ny, 0);
std::copy(inputdata, inputdata + cx * ny, in.begin());

std::vector<float> out(cx * 2 * ny*MULT);
CHECK(DftiComputeForward(dsc, in.data(), out.data()));

for(int i=ny*(cx-1); i<ny*cx; i++)
{
std::cout << "in[" << i << "] = " << in[i] << std::endl;
}

for(int i=MULT*(cx-1)*8; i<=MULT*(cx)*8; i++)
{

std::cout << "out[" << 2*i << "].real = " << out[2*i] << "; out[" << 2*i+1 << "].imag = " << out[2*i+1] << std::endl;

}

return 0;
}

Best Regards,

Shanmukh.SS

Re: 1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3

al42and — Thu, 09 Feb 2023 13:22:44 GMT

Hi Shanmukh!

Thanks for your reply!

@ShanmukhS_Intel wrote:

The new and current default settings for complex storage and complex-conjugate-even packed format are "DFTI_CONJUGATE_EVEN_STORAGE=DFTI_COMPLEX_COMPLEX" and "DFTI_PACKED_FORMAT=DFTI_CCE_FORMAT", respectively. Unless these configuration settings are explicitly set otherwise, these default values now mean that the strides and distance are (implicitly) counted in the "number of complex floating point values" in the backward domain when using oneMKL2023.0

The documentation for 2023.0 says that DFTI_COMPLEX_REAL is the default (https://www.intel.com/content/www/us/en/develop/documentation/onemkl-developer-reference-c/top/fourier-transform-functions/fft-functions/configuration-settings/dfti-complex-real-conj-even-storage.html

DFTI_CONJUGATE_EVEN_STORAGE: storage scheme for a conjugate-even domain

The

Intel® oneAPI Math Kernel Library

FFT interface supports two configuration values for this parameter:
DFTI_COMPLEX_REAL
(default) and
DFTI_COMPLEX_COMPLEX
.

The documentation warns about possible troubles with DFTI_COMPLEX_REAL and that it will be deprecated in the future but does not mention that the defaults have been changed. Shall I assume that the documentation is not up-to-date?

Best,

Andrey

Re:1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3

ShanmukhS_Intel — Tue, 14 Feb 2023 17:49:40 GMT

Hi Andrey,

but does not mention that the defaults have been changed. Shall I assume that the documentation is not up-to-date?

>> Yes. We regret to inform you that the document was not completely updated. We have shared the information with the concerned team as well. If this resolves your issue, Could you please let us know if we could close this at our end?

Best Regards,

Shanmukh.SS

Re: Re:1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.

al42and — Tue, 14 Feb 2023 19:12:45 GMT

Yes, thank you for your help. The issue can be closed now.

Re:1D R2C FFT: "Inconsistent configuration parameters" with 2023.0, but not with 2022.3

ShanmukhS_Intel — Thu, 16 Feb 2023 07:37:48 GMT

Hi Andrey,

Thanks for the confirmation. If you have any other queries, please post a new question as this thread will no longer be monitored by Intel.

Have a great day!

Best Regards,

Shanmukh.SS