Generate Commissioning PSFs from OPD and SUR

[laurenmarietta]

Once we have developed and merged the infrastructure for how to query a PSF from the new library, we need to develop an off-ramp of that to use for commissioning data.

At the moment, my idea is that we would provide an OPD (optical path difference) file to provide the telescope mirror state and a SUR (segment update request) file to provide the mirror moves for any given step of commissioning. These can be input to WebbPSF to generate PSFs from any possible telescope configuration.

When MIRAGE is generating NIRCam images from commissioning, we'll need to do this (or something like this!) in order to generate the huge diversity of PSFs that will result from a frequently-changing observatory state.

[mperrin]

There are several parts of this, with multiple axes of complexity.

• Simple case: An aberrated telescope in some slightly-misaligned state, which remains fixed during observations. (a relevant example: OTE-13 observations 5 through 9). In this case, we could use an appropriate OPD with WebbPSF in the PSF generation script to generate a small PSF library specific to this telescope state, and then tell MIRAGE to just use that PSF library. Relatively small code changes needed.
• More complicated along the time axis: telescope state changes during observations. (example: Image stacking or Fine Phasing) In this case we could either proceed as you describe above, providing an OPD and SUR to MIRAGE, or alternatively we could use those in a script to prepare a time series of PSF library files, one for each step in the mirror control. Then we would need a way to tell MIRAGE e.g. "here are 10 PSF libraries. Use each of them in turn for one of the 10 exposures in this visit".
• More complicated along the space axes: unstacked PSFs of varying sizes. The existing code should in theory flexibly handle larger PSFs for unstacked cases such as segment image array and global alignment. However, those get pretty big. The large image array fills 75% of an SCA, so it would be something like 1800 pixels on a side. Does the code scale up that large with acceptable performance?
  • Even more complicated along the space axes: In initial image mosaic, the PSFs will be wildly scattered, potentially tens of arc minutes across. Many NIRCam FOVs to encompass the full PSF. Probably doesn't make sense to treat this as single array - rather we would need to treat it as 18 separate smaller segment PSFs, with large vector offsets between them.
  • And then that whole pattern can get shifted around by boresight offsets, which will act to modify the apparent positions of stars across the whole FOV. We'll need some way to handle that as well.

On the other hand, it's not all bad: for these OTE commissioning cases we will almost never care about field dependence, so the PSF "library" could reduce down to just a single PSF per each SCA. And at minimal subpixel sampling as well.

[mperrin]

I've finally had time to read through your example notebook OTECommissioning_simulator_use_examples.ipynb

I hadn't realized that the calls to MIRAGE generate many YAML files at once from a given program but then only actually simulate one image at a time. Good to know! This suggests that it may not be so hard to handle telescope state changes during the observations, since each exposure within that observation will actually be done with a separate call to MIRAGE. Yes?

I can imagine a process something like:

• From the APT file, generate the observation list file and the individual parameter files per each exposure and per each detector.
• From the prior telescope state and the requested mirror moves, use WebbPSF to generate a PSF library file per each exposure. (Potentially with reduced subsampling or field points to save space, if those factors are not critical in a particular OTE program)
• For each observation, update the parameter file to reference the appropriate PSF library file.
• Then iterate over all the parameter files, generating the simulated images one at a time.

Does that approach sound about right to you, @laurenmarietta?

[laurenmarietta]

That approach definitely makes sense!

The main question I have is, if we would be generating one PSF library file per exposure, is it really worthwhile to generate the PSF libraries at all? Why not just generate the PSFs on-the-fly (since that would be already happening from a computational standpoint anyway)? Do you think we gain something by having that particular set of PSF library files to pull from in the future? I'm also thinking about how we might want to use MIRAGE to create, for example, multiple different versions of OTE-12, with the telescope at different states (different roles of the dice). So we would end up with a separate library not only for each commissioning step, but also for each specific telescope state for each commissioning step. What are your thoughts?

But besides the library v. on-the-fly question, I think this method sounds great. I would be happy to start playing around with the implementation, if I could access some OPD/SUR files?

[mperrin]

is it really worthwhile to generate the PSF libraries at all? Why not just generate the PSFs on-the-fly (since that would be already happening from a computational standpoint anyway)? Do you think we gain something by having that particular set of PSF library files to pull from in the future?

The main benefit might just be code simplicity: avoiding any need for multiple different interfaces inside MIRAGE for how it gets PSFs. It could just always read in PSFs via the library interface, rather than having to have separate interfaces for library and also on-the-fly. And for realistic scenes with more than one star in the FOV, you wouldn't want to redo the on-the-fly calculation for every individual star, so you'd need the on-the-fly interface to save them, which would end up in practice being a small library, right?

I completely agree with you that it wouldn't be likely we'd reuse that PSF library file in the future. Might be that we just create it, run MIRAGE, and then throw it away.

As for getting SURs, any of Keira, Chris, Marcio, Greg, or Tom should have lots of those they can give you from their ITM simulation runs. You can also create some manually in the WEx; there's a simple graphical interface for making them. They're just XML files listing a set of requested mirror moves. In webbpsf, you'll want to use the move_sur method in the OTE_Linear_Model_WSS class. Something like:

nrc = webbpsf.NIRCam()
ote, nrc = webbpsf.enable_adjustable_ote(nrc)
ote.move_sur('some_filename.xml')
psf = nrc.calc_psf()

[laurenmarietta]

Fair point - I hadn't really started to think about how a deviation from the current library infrastructure might be challenging....

Thanks for the WebbPSF example! I emailed Marcio and he sent me a directory with SURs that I can play with, so I'll start investigating this soon.

[laurenmarietta]

I made some preliminary PSFs from SURs that Marcio provided me with, and they are looking like this (ignoring the ones that are blank):

Particularly during Image Stacking, I would have expected the PSFs to look much more diffuse. (Though this could very well be a result of my incomplete understanding of what exactly a SUR is and how it works in WebbPSF.) Do they look like you would have expected?

Additionally, I receive an error if providing any SURs that include a command to the secondary mirror: SM not supported by move_seg_local. Use move_sm_local instead. It seems like this is a result of the changes you made in this commit. If we want to update this, I get the sense that it might be an easy thing to add an if statement to handle SM moves in the code for move_sur().

[mperrin]

This was implemented in #303.