Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.
7000 Discussions

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

al42and
Beginner
2,893 Views

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;
}

 

0 Kudos
1 Solution
ShanmukhS_Intel
Moderator
2,368 Views

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


View solution in original post

0 Kudos
15 Replies
ShanmukhS_Intel
Moderator
2,854 Views

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


0 Kudos
ShanmukhS_Intel
Moderator
2,809 Views

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


0 Kudos
al42and
Beginner
2,798 Views

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

0 Kudos
ShanmukhS_Intel
Moderator
2,737 Views

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





0 Kudos
al42and
Beginner
2,683 Views

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.

$ 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 -DMULT=1 -qmkl mkl.cpp -o mkl && ./mkl
out[150] = -28.8722

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;
}

 

0 Kudos
ShanmukhS_Intel
Moderator
2,670 Views

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

 

0 Kudos
al42and
Beginner
2,597 Views

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

0 Kudos
ShanmukhS_Intel
Moderator
2,613 Views

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


0 Kudos
ShanmukhS_Intel
Moderator
2,504 Views

Hi Andrey,


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


Best Regards,

Shanmukh.SS


0 Kudos
ShanmukhS_Intel
Moderator
2,458 Views

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


0 Kudos
ShanmukhS_Intel
Moderator
2,430 Views

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

 

0 Kudos
al42and
Beginner
2,416 Views

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

0 Kudos
ShanmukhS_Intel
Moderator
2,369 Views

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


0 Kudos
al42and
Beginner
2,362 Views

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

0 Kudos
ShanmukhS_Intel
Moderator
2,335 Views

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


0 Kudos
Reply