Infer FITSOpticalElement planetype from header keywords when not given

[mperrin]

Issue by josePhoenix
Friday Jun 12, 2015 at 16:07 GMT
Originally opened as mperrin/poppy#97

---

FITSOpticalElements are allowed to be initialized with a planetype of None, which confused the logic to look up the pixel scale from a header keyword. This PR changes it to set the planetype based on whether PUPLSCAL or PIXSCALE are found in the FITS header, with the amplitude/transmission header taking precedence.

This also includes a fix and test case for a typo in poppy.Instrument, where the spectra cache was not being exercised (masking a NameError from a typo'ed variable name).

---

josePhoenix included the following code: https://github.com/mperrin/poppy/pull/97/commits

[mperrin]

Comment by josePhoenix
Friday Jun 12, 2015 at 16:12 GMT

---

This fixes an API problem where outside-POPPY uses of FITSOpticalElement could not specify the planetype explicitly, resulting in pupil plane maps being treated as image plane maps for the purposes of determining pixel scale. I ran into this with WFIRST, when I created a new pupil image that included scale information instead of supplying it as an argument and POPPY tried to look up 'PIXSCALE' from the header.

[mperrin]

Comment by josePhoenix
Friday Jun 12, 2015 at 16:24 GMT

---

It's unclear to me whether an initialized FITSOpticalElement should have a planetype by the time __init__ finishes. It would seem to make sense to me, but there are currently code paths where planetype is None until it's added to an optical system with addPupil or the like.

I could add a check for that for the cases where pixel scale is not supplied through one of the two usual header keywords (i.e. if it's a float or a custom keyword, ensure planetype is not None).