mperrin
commented
6 years ago 
4b: Yup, it breaks the FQPM_FFT_aligner, even after I fixed input_wavefront as noted in 4a.
Edit: wait, maybe never mind? All the FQPM tests fail, but looking more closely at the errors I think it's related to something else entirely, in that how the MIRI._addAdditionalOptics function works is being broken by the presence of the additional pupil planes in the optical system. So there is a problem, but it's probably not the FQPM_FFT_aligner
Well. Getting all the coordinate systems in
webbpsffor pupil plane and image plane orientations, etc. to match the reality of the SIs has proven to be much more complicated than I had expected, and is leading to wide-ranging follow-on changes throughoutwebbpsfandpoppy… Right now this is all just in local changes on my machine, and is not ready for prime time, but I wanted to sound the alert. Major changes coming, potential large hassles ahead.(This post is a wall of text, but I need to write this all down right now while I think I've got the details mostly right in my head)
1) exit pupil orientation: As pointed out in an email last week, with Randal's help I figured out something I should have taken into consideration long ago: image planes are inverted relative to the pupil, for exactly the same reason that e.g. the human eye forms an inverted image on the back of your retina, or a simple Newtonian telescope creates an upside down image. In practice for JWST, the science instrument focal plane projected on sky is in fact “right side up” relative to V2V3 because it’s a second image plane after reimagine by the tertiary - but the price of that is the OTE exit pupil is now upside down.
(I thought briefly about trying to hide all this behind the scenes from users, but following the general Python wisdom ‘explicit is better than implicit’ I think we need to make it clear to users that this flip is taking place. Likewise I thought about making the inversion an automatic property of the transform between planes in poppy - but that’s a monstrously back-incompatible change in poppy, and we actually don’t want that behavior in many cases. So I think users need to explicitly include the coordinate flips as a plane in their OpticalSystem if so desired.)
2) JWST pupil orientation conventions The canonical depiction of the JWST primary is the “as seen head on looking in” orientation, not the exit pupil orientation or even the “looking out at the sky” uninverted orientation. This is how the primary is depicted in the WAS wavefront error maps, the WEx MSDB actuator display, all the other Ball Aerospace figures etc. There’s value in having our primary mirror display consistent with this in terms of which segment is where - but that means that we have a different handedness for the display of the entrance pupil, “looking in”, then flip around and use “looking out” for all the other subsequent planes. We have to choose here: webbpsf can either display the OTE pupil consistent with all other common depictions, or it can use a consistent orientation for all of its optical planes internally - but it can’t do both.
3) SI wavefront map orientation: As discussed in various emails, we want to add the SI wavefront error after the SI-internal image and pupil planes for cases where the
image_maskplane is right near the SI pickoff mirror (e.g. NIRCam and MIRI) but before the MSA focal plane for NIRSpec. In either case these are after the OTE exit pupil which is inverted given the above.4) Source Offsets with Inverted Pupils: Annoyingly, adding the axes inversions breaks the source offset capability, in the sense that a source will now move in the opposite direction from what’s expected. My intuition is that the source_offset options should apply to the source position in the final image plane in the system, i.e. at the detector. This is what users expect - “offset up” means “offset up in the coordinate system of the output image”, never mind that the tilt of the wavefront in the entrance pupil is opposite that. This means we need to change the sign in the poppy_core code that applies the tilts to input wavefronts. However we really only want to do this for optical systems which do include the coordinate inversion as an explicit part of the propagation.
5) Breaks Semi-Analytic Coronagraph Method: Meanwhile, the fast semi-analytic coronagraph method code makes inflexible assumptions about the number and ordering of input wavefronts. As soon as we add a coordinate inversion we’ve broken that, never mind adding SI WFE as an extra optical plane at the end. I fear this will require a complete overhaul of the semi-analytic method - in some sense we want a hybrid that can do “regular” poppy propagation for some of the planes, then use the semi analytic method just for the subset of planes with the coronagraph optics. Ugh, what a pain.
6) Possible Defocus Sign Error: Related to poppy issue 164 (https://github.com/mperrin/poppy/issues/164), I suspect that yes, we do indeed have the sign of the ThinLens wavefront error backwards, and this has until now been cancelled out by having the OTE exit pupil oriented the wrong way around. Need to double check this with the orientations of actual NIRCam weak lens data.
7) Detector and field position handling in the JWST classes: The lookup for SI wavefront error maps from the ISIM CV data requires knowing the mapping between pixel coords (SCI frame) and V2V3 angular coordinates (TEL frame). So I'm reactivating all of that code which I commented out in #94), and partially overhauling it. In particular I'm taking much of the detector and detector_position machinery from
WFIRSTInstrumentand promoting it up toSpaceTelescopeInstrument, so we'll end up with a consistent API between JWST and WFIRST for handling this.