Warn (or fail) on requested field-of-view too large for pupil sampling

[mperrin]

Issue by mmechtley
Monday Aug 22, 2016 at 19:27 GMT
Originally opened as mperrin/poppy#180

---

I ran into this the other day when making NIRCam PSFs with webbpsf, though the issue is generic to poppy rather than specific to webbpsf. I put in a stupid-large output size (60"), then realized I was getting aliasing problems when I saw multiple copies of the PSF in my output. I think the problem's cause and its solution won't be obvious to many users -- mostly non-PSF specialists using tools like webbpsf rather than poppy users directly, though see e.g. the same problem in issue #135. TinyTim handled this by just forcing a max size since it knew its pupil sampling, but obviously that doesn't work for a more flexible system like this.

At the simplest (logic-wise) level I guess this would involve something like checking lambda/D and the pixel sampling at the last pupil plane (at least for FFT-based propagation), but warning early before lots of computation would be ideal.

[mperrin]

Comment by mperrin
Monday Aug 22, 2016 at 20:00 GMT

---

This is actually the very first thing mentioned at the top of the "Known Issues" documentation section, but I know, nobody reads that. :-) http://pythonhosted.org/webbpsf/relnotes.html#known-issues
I agree it would be nice to have a more automated catch for this but it hasn't made it to the top of the priority list yet. Good suggestion for sooner or later though.

There is some chance that I will have a very high resolution pupil map available in the not so distant future for calculations that do need this size. On the other hand, at distances like 60" or beyond, incoherent scatter can matter as much as diffraction. We have models for that but it's a different set of physics than what webbpsf is currently set up to simulate.

[mperrin]

Comment by mmechtley
Monday Aug 22, 2016 at 20:53 GMT

---

Ok guilty as charged on not reading the webbpsf known issues. :x

re: NIRCam/JWST pupil maps specifically, the desire to go larger than ~30" was mostly cosmetic in our case. We were simulating some bright stars in candidate deep fields and the edge of the PSF image was obvious. So naturally I just tried going bigger, then ran into this issue.

As a PSF aficionado, modeling effects like incoherent scatter sounds interesting to me, but probably me alone. One day.

Note: for intermediately-bad sizes (this was 40" diameter) you get aliasing of diffraction spikes but it wasn't immediately obvious what was causing them (the bands in the background).

Then after a day or so thinking about it I tried making this bigger 60" one and it became clear it was an aliasing issue.

[mperrin]

Comment by mperrin
Monday Sep 26, 2016 at 03:43 GMT

---

I've made substantial progress in being able to model very large FOV PSFs, by now having a numerical representation of the JWST complex pupil geometry which I can evaluate on an arbitrary sampling. (I.e. I now have a version of the JWST pupil implemented as a poppy.AnalyticOpticalElement subclass). This will let you generate aliasing-free PSFs at very large angular separations - albeit at a cost of much, much slower calculations (but hey, that's what big computers are for!). Stay tuned for the next version of WebbPSF.

But it also lets me generate gray pixel versions of 1024 pixel pupils by binning down higher resolution pupils. This dramatically cuts down on the aliasing seen at the intermediate scales in your images above.

For comparison here are 3 PSFS calculated monochromatically at 2.1 microns, for a FOV=60 arcsec across.
First the result from the prior existing pupil file for comparison. This shows clearly the aliasing spikes:

Here's one from a pupil file with the same size but which was generated by binning down a 8192 pixel pupil. Way less aliasing, but it still shows up a bit in the corners.

Lastly a PSF generated directly from a 4096 pixel pupil. No aliasing at all visible at this angular scale.

I've tried computing a 120 arcsec PSF directly from the 8192 pixel pupil file, but my poor laptop can't handle it and Python's been chugging away for 20 minutes with 40 GB of RAM allocated on a machine with only 16 GB physical. Gonna have to run that on a bigger machine at the office.

[mperrin]

Comment by mperrin
Monday Sep 26, 2016 at 17:12 GMT

---

Hi @mmechtley I just added a check for requested FOVs that exceed the critical angle for Nyquist sampling of the input pupil. If the user requests too large a FOV, at the very start of the PSF calculation it will issue warnings like this:
UserWarning: For wavelength 1.855 microns, a FOV of 70.006 arcsec diameter exceeds the maximum spatial frequency well sampled by the input pupil. Your computed PSF will suffer from aliasing for angles beyond 29.630 arcsec radius.

This check is performed on a per-wavelength basis inside poppy.Instrument.calc_psf. It seems to be working OK in some basic testing here. Check if it works as desired for you? If so I think we can go ahead and mark this issue resolved.

[mperrin]

Comment by mmechtley
Monday Sep 26, 2016 at 20:56 GMT

---

Looks excellent! Warning provides exactly the information I'd want. I'd consider the issue resolved.
Note I tested using webbpsf, just adding the _check_for_aliasing call in the same place in the overridden SpaceTelescopeInstrument.calcPSF.

The large FoV PSFs above look great too. The NIRCam folks I'm working with will enjoy that. I assume with the AnalyticOpticalElement approach you don't get to use the OPD maps? Not a big deal for the aesthetics of simulated images of course.

[mperrin]

Comment by mperrin
Monday Sep 26, 2016 at 21:12 GMT

---

Argh - I was surprised you needed to make any changes in webbpsf, and have just realized to my horror that when we updated the API for calcPSF->calc_psf we never updated SpaceTelescopeInstrument. So I've been doing all my testing lately calling calc_psf which was just calling the parent Instrument.calc_psf. It turns out that has been working fine - so I'm now confused and can't remember why we overrode that function in SpaceTelescopeInstrument. Going to split this off as a separate issue.

My plan for the next release of webbpsf is the middle option above, gray pixel approximation on fixed sampling. That will play well with the OPDs easily. Of course I'm in the midst of regenerating all the OPDs too, from new data from Ball, and for those users who want really high res PSFs we could make a separate set of larger OPDs available. But that won't be the default because slow.

[mperrin]

Comment by josePhoenix
Monday Sep 26, 2016 at 21:13 GMT

---

Yep, I spotted the calc_psf / calcPSF issue but I didn't document it at the time because I didn't follow the whole rabbit hole down. Sorry about that... It needs some attention.