jawilson wrote:
> Any ideas on what might be causing this? Are there additional tests I
> can run with bench to ensure that the library is actually working
> correctly?

You can run e.g.:
            tests/bench -y r/8x10x4x6
to test correctness for a 4d real-input ("r") transform in
split-complex ("/") format.

If this passes, most likely you have some error in the strides etcetera
you are passing to FFTW. Figuring out how to deal correctly with
multi-dimensional array formats seems to take most people some time.

Hello,

I am working on getting fftw working, and I feel like I'm almost there,
but have run into a new problem. I am performing a dft in several loops
using the guru interface, where the input array is 4D, and the FFT is
taken on the last dimension. This seemed to be mostly working earlier
this week, but is now giving me problems; I'm not sure what I might
have changed to cause this.

I am using borland c++ on windows, and have compiled my own fftw
library, and have run the bench program on it to test that it works as
expected (as far as I can tell). I used:

bench -v1 --verify 64 128 4096 10000 100000

and did not get any errors.

I am using the guru split interface with a real to complex calculation,
ie:

plan = fftw_plan_guru_split_dft_r2c(1, dimsPre,
                                                3, howmany_dimsPre,
                                                xPre, outRe, outIm,
                                                FFTW_MEASURE);

xPre has been initialized and has values copied from another input;
outRe and outIm have been initialized with:

double *xPre, *outRe, *outIm;
...
outRe = new double[nSamples];
outRe = new double[nSamples];

(nSamples takes into account the fact that the output will have
nfft/2+1 samples per iteration, as does the howmany_dimsPre array).

When the plan is executed with:

fftw_execute_split_dft_r2c(plan, xPre, outRe, outIm);

the values in the outRe are reasonable, but the outIm values are in the
1E+/-300 range. I only want the magnitude, so I'm using:
sqrt(outRe[n] * outRe[n] + outIm[n]*outIm[n])

which obviously gives floating point overflow exceptions.

Any ideas on what might be causing this? Are there additional tests I
can run with bench to ensure that the library is actually working
correctly?

Thanks!
Adam