Closed beckermr closed 11 months ago
cc @rmjarvis
Before I go too far trying to understand your test, have you looked at this unit test that compares our fft commands with numpy?
https://github.com/GalSim-developers/GalSim/blob/releases/2.4/tests/test_draw.py#L1342
I have not. This is definitely due to the shifting of the center of the spectrum so I suspect it is a convention issue that won't effect drawing itself.
We do have the convention that the FFT image is centered in the center of the image, not at the corner (ie. kx,ky = 0,0). That's probably the source of disagreement. But we have functions like galsim.rfft2
that are meant to be drop in replacements of np.rfft2
, but using FFTW for the back end. (For many purposes, FFTW is a bit faster, but YMMV.) Anyway, looking at those routines might be helpful for teasing out the conventions.
Ahhhh thanks for the pointers! The test suite indeed had the right answer in it due to shifts etc. For the record, it is np.fft.fftshift(np.fft.rfft2(np.fft.fftshift(ximage.array)), axes=0)
that is needed above!
I very much hope I am wrong about this one, but I cannot figure out what is going on, so here we go.
Here is the test case
and the output
As you can see, the checkerboard pattern of -1/1 that is supposed to be removed remains.