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

WebbFieldDependentAberration optic clips primary mirror corners #667

Open
LouisDesdoigts opened this issue May 9, 2023 · 2 comments
Open

Comments

@LouisDesdoigts
Copy link

So I've been playing around building the dLux JWST module and it looks like the WebbFieldDependentAberration optic amplitude actually clips the primary mirror amplitude in the corners.

MWE:

niriss = webbpsf.NIRISS()
planes = niriss.get_optical_system().planes

aper = planes[0].amplitude # webbpsf.opds.OTE_Linear_Model_WSS  object
circ = planes[2].amplitude # webbpsf.optics.WebbFieldDependentAberration object

diff = aper - (aper * circ)
print(np.sum(diff != 0))
> 72

So there are 72 pixels that get changed via applying the WebbFieldDependentAberration plane.

If we plot the diff we can see this corners of the mirror are being clipped:

plt.figure(figsize=(20, 16))
plt.imshow(diff)
plt.colorbar()
plt.tight_layout()
plt.savefig('diff')

diff


So this might seem like a small change, but in my testing if this effect is not accounted for the peak psf residuals go from machine precision (~5e-17) to ~1e-7, which is significant for precision psf calibration.

I'm curious if this is intentional. As far as I'm aware these field dependent aberrations account for the projected secondary mirror aberrations plus any other non-common paths across the full FoV. I would have guessed that the secondary mirror was built with enough tolerance as to not clip any light from the primary, so I suspect this is a bug.

Anyway would love your thought!

Louis

@mperrin
Copy link
Collaborator

mperrin commented May 9, 2023

Not intentional, no, so yes I think you are correct this can be considered a bug. But in practice I would expect this is going to be inconsequential - I trust you appreciate that real PSFs in practice on sky do not have sufficient SNR to be sensitive to 1e-7 variations on the psf peak (or maybe I'm misunderstanding the numbers you're stating?)

After some investigation, this is due to handling of partially illuminated pixels at the outer edge of the aperture. In detail: the aperture in the WebbFieldDependentAberration calls the poppy function compose_opd_from_basis to make an OPD from Zernikes, and leaves the aperture unspecified so it defaults to a unit circle filling the array. This unit circle is implemented (within poppy.zernike.zernike_basis_faster) using calculations on the central coordinates per pixel, neglecting any consideration of partially illuminated pixels. (i.e. it just checks if the central coords of the pixel have radius <=1, as a binary threshold for in/out of the aperture). In contrast the JWST aperture was implemented with careful attention to sub pixel sampling and partial illumination.

Specifically the pixels that you've identified have central coordinates just slightly greater than the radius of the circumscribing circle, so in the binary circle version of the pupil they end up "outside".

In principle this is straightforward to fix by explicitly passing an aperture to the compose_opd_from_basis function. In fact there's already an option to do that, via the include_oversize parameter to WebbFieldDependentAberration, which invokes code to try to model the actual physical hard stop that exists within some of the instruments. This is off by default for performance reasons. We could modify the default path to also include passing in a slightly larger aperture to ensure these pixels are included in the Zernike OPD. The relevant area is about 3e-5 of the total aperture, so I'm not surprised that you say the total effect in the PSF is small, like you say.

At the same time, though, I want to urge thinking physically, and being cautious about aiming at potentially unrealistic levels of precision. At the level of aiming for better than 1e-7 precision on the PSF peak there is a LOT of physics that's being left out, or is not within the precision or spatial frequency coverage of the in-flight wavefront sensing, etc. Which doesn't mean don't try, just, be aware of the challenges.

Thanks for reporting this interesting little puzzle :-)

@LouisDesdoigts
Copy link
Author

Yeah cool, I thought this was the case. Yeah I think my original comparison may have been a little confusing, since we are essentially treating the webbpsf models as the 'true' models with the goal of getting a machine precision match as form of verification.

With peak psf values normalized to 1, the absolute residuals go to ~2.5e-5, which is definitely pushing towards some of the contrast limits we are looking to reach for some high-contrast measurements.

example


Yeah from a physics perspective this is likely 'chasing our own tail' in terms of actual achievable precision. However with our goal of machine precision match to webbpsf as a form of validataion, it would make a lot of sense to remove this effect.

I'm happy to author a PR into the main repo since this will help us in the long run. Simplest option is probably defaulting the inculde_oversize to True, but I'm open to other fixes. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants