convert method fails for HST apertures

[Russell-Ryan]

I was trying to convert coordinates for the HST apertures, and pysiaf fails. This is what I did:

import pysiaf
hst=pysiaf.Siaf('HST')
uvis1=hst['IUVIS1']
uvis1.convert(1,1,'sci','det')

The traceback is very long, but the last stanza gives:

~/miniconda3/envs/astroconda37/lib/python3.7/site-packages/pysiaf/aperture.py in linear_transform_model(from_system, to_system, parity, angle_deg)
   2017     if type(angle_deg) not in [int, float, np.float64, np.int64]:
   2018         raise TypeError('Angle has to be a float. It is of type {} and has the value {}'.format(
-> 2019             type(angle_deg), angle_deg))
   2020 
   2021     # check for allowed system pairs

TypeError: Angle has to be a float. It is of type <class 'NoneType'> and has the value None

This is running:
pysiaf.version
'0.7.1'

I did this with the JWST apertures, and things seemed to work. Any advice here? Is this a issue with the HST reference files?

[Johannes-Sahlmann]

This is a missing functionality. In all my HST use cases so far I worked with Science pixels and did not convert to Detector pixels.

One would have to find out what the HST equivalent of DetSciAngle is and add it to _hst_to_jwst_keys in aperture.py. (This is also what the error refers to.)

[Russell-Ryan]

That might exist. What is the DetSciAngle physically? R On Apr 15, 2020, at 2:38 PM, Johannes Sahlmann <notifications@github.com<mailto:notifications@github.com>> wrote: This is a missing functionality. In all my HST use cases so far I worked with Science pixels and did not convert to Detector pixels. One would have to find out what the HST equivalent of DetSciAngle is and add it to _hst_to_jwst_keys in aperture.py. (This is also what the error refers to.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#145 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACGLBMCXLQJHLVC4JLOPXIDRMX5J7ANCNFSM4MIZPR7Q>.

[Russell-Ryan]

This is the data they have: http://www.stsci.edu/hst/instrumentation/focus-and-pointing/fov-geometry unfortunately, you have to actually scroll down and click on “WFC3”, and the last two columns are angles of the V3 axis. Is that the DetSciAngle? R On Apr 15, 2020, at 2:45 PM, Russell Ryan <rryan@stsci.edu<mailto:rryan@stsci.edu>> wrote: That might exist. What is the DetSciAngle physically? R On Apr 15, 2020, at 2:38 PM, Johannes Sahlmann <notifications@github.com<mailto:notifications@github.com>> wrote: This is a missing functionality. In all my HST use cases so far I worked with Science pixels and did not convert to Detector pixels. One would have to find out what the HST equivalent of DetSciAngle is and add it to _hst_to_jwst_keys in aperture.py. (This is also what the error refers to.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#145 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACGLBMCXLQJHLVC4JLOPXIDRMX5J7ANCNFSM4MIZPR7Q>.

[Johannes-Sahlmann]

I suggest to consult with @ColinRCox

[ColinRCox]

In the HST SIAF we did not really have any connection with the detector layout. We always worked with a set of image pixels which correspond to the displayed images. Unless anything else is known I would assume these frames are aligned with the detector. The DetSciAngle is the angle between the detector Y axis and the Science (or for HST the iraf) frame Y axis. For JWST this is almost always zero. We have a couple of cases where it is 180 degrees. I would assume for HST you can always assume zero.

[Russell-Ryan]

Hi Colin & Johannes, That’s very informative, thank you. I looked at the code a bit, but I’m not sure how to assume zero for HST. I guess I can hack the code to be if NoneType is encountered, use 0 instead. Is that what you had in mind , or was there an runtime option? Thanks again, Russell

…

Sent from my iPhone On Apr 16, 2020, at 4:55 PM, Colin Cox <notifications@github.com> wrote:  In the HST SIAF we did not really have any connection with the detector layout. We always worked with a set of image pixels which correspond to the displayed images. Unless anything else is known I would assume these frames are aligned with the detector. The DetSciAngle is the angle between the detector Y axis and the Science (or for HST the iraf) frame Y axis. For JWST this is almost always zero. We have a couple of cases where it is 180 degrees. I would assume for HST you can always assume zero. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#145 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACGLBMA2PRTLW7MD5IFPE2LRM5WFVANCNFSM4MIZPR7Q>.

[Johannes-Sahlmann]

You could try to insert

uvis1.DetSciParity = 1     
uvis1.DetSciYAngle = 0. 

before the call to .convert

[Russell-Ryan]

Perfect! I’ll give it a go. If it works, then I’ll fiddle with the numbers such that I reproduce a know image. I’ll report back. Thanks!! R

…

Sent from my iPhone On Apr 18, 2020, at 11:59 AM, Johannes Sahlmann <notifications@github.com> wrote:  You could try to insert uvis1.DetSciParity = 1 uvis1.DetSciYAngle = 0. before the call to .convert — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#145 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACGLBMA5BRIFMLGU5NYF7VDRNHE4NANCNFSM4MIZPR7Q>.

[jdavies-st]

I ran into this same issue.

I had to do the following to get det_to_tel to work:

uvis1.DetSciParity = 1
uvis1.DetSciYAngle = 0.
uvis1.XDetRef = uvis1.XSciRef
uvis1.YDetRef = uvis1.YSciRef