You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to support long-term IFU cube building using 3D drizzle from MIRI LRS slit data, it would be helpful to add an intermediate slit-based coordinate frame analogous to that for the MIRI MRS. Instead of going directly from detector coordinates to v2,v3 coordinates, it would be possible to stop at this intermediate 'alpha-beta' coordinate frame (to use the MRS terminology) in which alpha is the angular position along the slit from the slit reference point, and beta is the across-slit position. By definition, beta will always be zero for LRS slit since there is just one slit.
This would be defined similarly for LRS slitless as well, although it does not make as much sense to actually use this functionality there given it has no strict slice footprint.
The text was updated successfully, but these errors were encountered:
Tagging Jane Morrison , Greg Sloan , and Sarah Kendrew . This will require discussion prior to moving forward, and testing to ensure that it doesn't accidentally cause any problems for regular LRS operations, but this should start the conversation.
Issue JP-3618 was created on JIRA by David Law:
In order to support long-term IFU cube building using 3D drizzle from MIRI LRS slit data, it would be helpful to add an intermediate slit-based coordinate frame analogous to that for the MIRI MRS. Instead of going directly from detector coordinates to v2,v3 coordinates, it would be possible to stop at this intermediate 'alpha-beta' coordinate frame (to use the MRS terminology) in which alpha is the angular position along the slit from the slit reference point, and beta is the across-slit position. By definition, beta will always be zero for LRS slit since there is just one slit.
This would be defined similarly for LRS slitless as well, although it does not make as much sense to actually use this functionality there given it has no strict slice footprint.
The text was updated successfully, but these errors were encountered: