Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Small Discrepancy between Real and Fourier Space Shift #1231

Closed
EiffL opened this issue Jul 22, 2023 · 4 comments · Fixed by #1234
Closed

Small Discrepancy between Real and Fourier Space Shift #1231

EiffL opened this issue Jul 22, 2023 · 4 comments · Fixed by #1234
Labels
numerics Involving details of the numerical algorithms for performing some calculation(s)
Milestone

Comments

@EiffL
Copy link
Member

EiffL commented Jul 22, 2023

While working on porting new features to jax-galsim, we noticed that the GalSim phase shifts are not exactly equivalent to the real domain equivalent.

Here is an example of what I mean:

import galsim

gal = galsim.Gaussian(sigma=1.).shift([5,5]).withFlux(200)

real_im = gal.drawImage(nx=128, ny=128, scale=0.2, method='real_space')

fft_im = gal.drawImage(nx=128, ny=128, scale=0.2, method='fft')

image

notebook

So, it's definitely small, but not a nice pattern...

My guess... is that it might have something to do with this:

// 1/|z|. Since z ~= 1, 1/|z| is very nearly = |z|^2^-1/2 ~= 1.5 - 0.5|z|^2.

because when we use the exact expression in jax-galsim we recover perfectly the same answer as drawing the image in real space.

Just wanted to report this to see if this is known/not a big deal. Feel free to close this issue if this is the case :-)

@rmjarvis rmjarvis added the numerics Involving details of the numerical algorithms for performing some calculation(s) label Aug 9, 2023
@rmjarvis
Copy link
Member

rmjarvis commented Aug 13, 2023

I couldn't reproduce the exact result you had. On my laptop, this results in the following:
junk

A little bit smaller residuals, and a different pattern. Apparently the rounding behavior on my laptop is somewhat different than on collab. If you use double precision though, the differences are ~1.e-15.

So I think this isn't a problem with the method per se. Just single-precision floating point errors accumulating. But they are a fair bit higher than the single-precision epsilon value, so I switched the code to use double precision for the phases, which basically fixed it. cf. #1234

@rmjarvis rmjarvis added this to the v2.5 milestone Aug 13, 2023
@EiffL
Copy link
Member Author

EiffL commented Aug 13, 2023

Hum interesting, I wouldn't have guessed platform-specific discrepancies at that level. But ok, if you recover 1e-15 using double precision then you are right it's not related to an approximation in this formula used to compute the phase.

@rmjarvis
Copy link
Member

The first equation is nominally exact, but can have rounding errors. The line you pointed to was intended to get back to |z|=1, which it does to the accuracy of the data type. So the errors are just that numerical rounding errors can add up, maybe semi-coherently, rather than purely randomly. And apparently differently on different systems. That surprised me too, FWIW.

@rmjarvis
Copy link
Member

Done. #1234

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
numerics Involving details of the numerical algorithms for performing some calculation(s)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants