Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Intel Community
- Software
- Software Development SDKs and Libraries
- Intel® oneAPI Math Kernel Library
- Incosistent in-place and out-of-place results in mkl_dfti

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

Amir_S_

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-01-2014
08:25 AM

70 Views

Incosistent in-place and out-of-place results in mkl_dfti

Hi,

I am trying to transfer from out-of-place calculation to in-place using MKL 10.3.12. I don't see any problem when doing forward FFT. However in backward FFT, for dimensions larger than 4, I get inconsistent results for in-place and out-of-place calculations. This happens when I use backward scaling of 1.0 (which I need in my problem), and the issue is resolved when scaling of 1/(K1*K2*K3) is used instead!. I have attached a minimal code for reproducing the results. I compiled it with:

gfortran -fcray-pointer -I$myMKLINC main.f90 -L$MKLROOT/lib/intel64/ -L/opt/intel/composer_xe_2011_sp1.12.361/compiler/lib/intel64 -lmkl_intel_lp64 -lmkl_core -lmkl_sequential -lpthread -liomp5 -o amain

Thanks for any help

Amir

1 Solution

Dmitry_B_Intel

Employee

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-04-2014
12:03 AM

70 Views

Amir,

Backward C->R transform expects the input is conjugate-even symmetric. In your case it is not. Please make sure the input is CCE.

For instance, add the following fragment right after definition of C_matip

! SYMMETRIZE INPUT do k = 0, K3-1 do j = 0, K2-1 do i = 0, K1/2 if (i == mod(K1-i,K1)) then c1 = C_matip(i+(K1/2+1)*j+(K1/2+1)*K2*k) c2 = C_matip(i+(K1/2+1)*mod(K2-j,K2)+(K1/2+1)*K2*mod(K3-k,K3)) if (c1 /= conjg(c2)) then c3 = 0.5*(c1 + conjg(c2)) print '("Symmetrizing",3(I3),"("2G12.4")","("2G12.4")"," -> ","("2G12.4")")',i,j,k,c1,c2,c3 C_matip((i+(K1/2+1)*j+(K1/2+1)*K2*k)) = c3 C_matip(i+(K1/2+1)*mod(K2-j,K2)+(K1/2+1)*K2*mod(K3-k,K3)) = conjg(c3) endif endif enddo enddo enddo

Thanks

Dima

Link Copied

3 Replies

Zhang_Z_Intel

Employee

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-02-2014
09:40 AM

70 Views

Dmitry_B_Intel

Employee

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-04-2014
12:03 AM

71 Views

Amir,

Backward C->R transform expects the input is conjugate-even symmetric. In your case it is not. Please make sure the input is CCE.

For instance, add the following fragment right after definition of C_matip

! SYMMETRIZE INPUT do k = 0, K3-1 do j = 0, K2-1 do i = 0, K1/2 if (i == mod(K1-i,K1)) then c1 = C_matip(i+(K1/2+1)*j+(K1/2+1)*K2*k) c2 = C_matip(i+(K1/2+1)*mod(K2-j,K2)+(K1/2+1)*K2*mod(K3-k,K3)) if (c1 /= conjg(c2)) then c3 = 0.5*(c1 + conjg(c2)) print '("Symmetrizing",3(I3),"("2G12.4")","("2G12.4")"," -> ","("2G12.4")")',i,j,k,c1,c2,c3 C_matip((i+(K1/2+1)*j+(K1/2+1)*K2*k)) = c3 C_matip(i+(K1/2+1)*mod(K2-j,K2)+(K1/2+1)*K2*mod(K3-k,K3)) = conjg(c3) endif endif enddo enddo enddo

Thanks

Dima

Amir_S_

Beginner

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

12-08-2014
06:23 PM

70 Views

Thank you so much for quick replies.

First I did not know that besides the CCE storage for the results of R->C, the conjugate symmetry of the stored elements will also be checked which seems to be particularly important for i=0 and i=K1/2 when K1 is even.

The array that I used as input was in fact the resulting array after some manipulation of the result of the forward R->C transform. The reason that the symmetry in some of the elements , i.e. the elements with i=K1/2, was breaking was directly related to that manipulation in case of K1 even (which I was expecting it from the mathematical point of view). In practice, the transform in this case becomes a C->C transform, with the exception that the CCE storage (the fact that the elements that are not stored can be obtained by conjugate symmetry of the stored elements) is still valid! Interestingly, after performing the C->C backward, I noticed that the C->C and in-place C->R give identical real parts. In general, for my problem, the real part of the results were important. Nevertheless, the very nice suggestion of @Dmitry guaranteed both the C->R transform and the correct real parts.

Many thanks

Amir

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page

For more complete information about compiler optimizations, see our Optimization Notice.