spacetelescope / mirage

This code can be used to generate simulated NIRCam, NIRISS, or FGS data
https://mirage-data-simulator.readthedocs.io/en/latest/
BSD 3-Clause "New" or "Revised" License
39 stars 41 forks source link

Check on final griddedPSF libraries #357

Open bhilbert4 opened 5 years ago

bhilbert4 commented 5 years ago

This is just to make a place for notes relating to a final check on the gridded PSF libraries prior to uploading them to Box and making them public.

I grabbed the latest version of webbpsf and poppy after I saw that https://github.com/spacetelescope/webbpsf/pull/283 had been merged. So I think the libraries should have been created using the latest Zernike and focus updates.

The webbpsf version used is 0.8.0 and poppy is 0.9.0dev1387.dev1387

One issue I had forgotten about is the scaling of the data in the libraries. https://github.com/spacetelescope/webbpsf/pull/302 was merged several weeks ago, and changes how the gridded library data are scaled. PSFs should now be scaled to a value of the square of the oversampling factor (at the input pupil). This means that I need to remove that scaling from Mirage. See #356.

@mperrin

mperrin commented 5 years ago

WebbPSF version should be something higher than 0.8.0? Or have we not actually updated the version number of that in GitHub? Possibly an oversight on our part, probably so if you're sure you're using the latest.

Either #356 or #332 (duplicates, I think) should resolve the scaling factor thing.

bhilbert4 commented 5 years ago

The version number in webbpsf's setup.py file is still 0.8.0.

bhilbert4 commented 5 years ago

Another PSF-related thought I had. @juliengirard has been asking about coronagraphy observations in Mirage. I think the strategy would be to use gridded libraries from webbpsf for observations of the un-occulted source. For occulted sources, a stamp image from something like Pancake would have to be placed into the simulated image.

Thinking in terms of the un-occulted case, this would be functionally identical to an imaging observation, and so I imagine there's nothing different in the gridded PSF libraries, right? I can loop over the round and bar masks along with the applicable filters and this would make the libraries that we need? One question I had was how many positions across the detectors to use for the libraries? Do we have ground testing data at the same locations as in the imaging case?

Assuming this is all I'd need to do to create these libraries, I'm tempted to add them to the set of Mirage reference files now. Although I guess it wouldn't be hard to create them later and then put a switch into the downloader script for it to grab just the coronagraphy-related files.

mperrin commented 5 years ago

Coronagraphy is worthy of a separate discussion sometime. For PSFs that are not actually blocked by the coronagraphic occulters, there's not sufficient field dependence to have that be worth considering, in my opinion. PSFs that are sufficiently close to be partially blocked by the occulters are not straightforward to handle using the gridded PSF approach (since a regular grid isn't a good match for covering the geometry... And in any case, handling that tricky case rigorously is precisely what PanCAKE is for, so why try to duplicate the same functionality here?

My suggestion for rigorously handling coronagraphy would be to perhaps use a modified version of PanCAKE or some other similar not-MIRAGE tool to generate a seed image. Then input that seed image directly to MIRAGE to convert into a NIRCam ramp. By the time you're using PanCAKE to generate the occulted source you might as well use it for all the sources perhaps. That approach also naturally would allow users to fairly easily inject models of complex scenes such as circumstellar disks, which are otherwise probably not well suited to implementing in MIRAGE directly. Needs more discussion.

bhilbert4 commented 5 years ago

That makes sense to me. I'll put aside the idea of a coronagraphy PSF library until this can be discussed further.

juliengirard commented 5 years ago

@Marshall's suggestion is what we have been doing with @aliciacanipe (ETC or PanCAKE => seed => MIRAGE) at the sub-array level and it is indeed pefect for the couple arcseconds around the mask.

More and more we need to simulate full frame coronagraphic images with ~crowded fields (2 astrometric confirmation images of TA, some programs). For that it would be nice to have the MIRAGE/catalog (with APT) interface as for plain imaging and only substitute the ETC/PanCAKE input image at the right location of the corresponding subarray OR feed PanCAKE with larger FoV calculation with a complex scene from the catalog (seems slow and something MIRAGE handles well).

I agree the field dependence of the PSF (with coronagraphic optics) well away (>1.5") from the masks (typ. away from the ETC calculated scene) is not too important.