Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NIRISS SUBSTRIP96 location is incorrect #362

Open
tapastro opened this issue Jan 10, 2025 · 4 comments
Open

NIRISS SUBSTRIP96 location is incorrect #362

tapastro opened this issue Jan 10, 2025 · 4 comments

Comments

@tapastro
Copy link

A refactor of NIRISS SOSS code in the jwst repository found a discrepancy with the subarray definition for SUBSTRIP96:
https://github.com/spacetelescope/jwst/pull/9000/files#r1909498841

@hover2pi Can you assist in correcting this entry?

<SiafEntry>
<InstrName>NIRISS</InstrName>
<AperName>NIS_SUBSTRIP96</AperName>
<DDCName>NIS_CNTR</DDCName>
<AperType>SUBARRAY</AperType>
<AperShape>QUAD</AperShape>
<XDetSize>2048</XDetSize>
<YDetSize>2048</YDetSize>
<XDetRef>94.00</XDetRef>
<YDetRef>850.00</YDetRef>
<XSciSize>2098</XSciSize>
<YSciSize>317</YSciSize>
<XSciRef>1980.00</XSciRef>
<YSciRef>258.00</YSciRef>
<XSciScale>0.06525472</XSciScale>
<YSciScale>0.06577458</YSciScale>
<V2Ref>-351.786079</V2Ref>
<V3Ref>-686.173172</V3Ref>
<V3IdlYAngle>0.56126717</V3IdlYAngle>
<VIdlParity>-1</VIdlParity>
<DetSciYAngle>180</DetSciYAngle>
<DetSciParity>1</DetSciParity>
<V3SciXAngle>-89.70138693</V3SciXAngle>
<V3SciYAngle>0.56126717</V3SciYAngle>
<XIdlVert1>-129.2904</XIdlVert1>
<XIdlVert2>7.7307</XIdlVert2>
<XIdlVert3>7.7314</XIdlVert3>
<XIdlVert4>-129.2957</XIdlVert4>
<YIdlVert1>-16.3352</YIdlVert1>
<YIdlVert2>-16.9581</YIdlVert2>
<YIdlVert3>3.8884</YIdlVert3>
<YIdlVert4>4.5345</YIdlVert4>
<UseAfterDate>2014-01-01</UseAfterDate>

@Witchblade101
Copy link
Collaborator

@tonysohn Can you double check this, when you have a chance? The highlighted entry above matches what I see from the last NIRISS update I can find (JSOCOPS-200).

@tonysohn
Copy link
Collaborator

@tonysohn Can you double check this, when you have a chance? The highlighted entry above matches what I see from the last NIRISS update I can find (JSOCOPS-200).

Sure, I'll check this and get back to you here.

@tonysohn
Copy link
Collaborator

I've consulted with @goudfroo who worked on the SIAF parameters and got answers as well as some useful info.

It turns out that the current NIRISS PRD SIAF is not the issue here. The SIAF parameters for the SOSS subarrays, including SUBSTRIP96 and SUBSTRIP256, are not so straightforward to interpret since they refer to the part of the detector for which the spectral traces on the sky are projected by the GR700XD grism (which has significant optical power as you know) onto the subarrays. This is also explained in the following j-docs page (see paragraph starting with "Note that..."):

https://jwst-docs.stsci.edu/jwst-near-infrared-imager-and-slitless-spectrograph/niriss-operations/niriss-apertures

I think the proper way to handle this issue is to not hard-code the 10 pixels Y-offset in the code, but to read in the parameters from the part of the PRD Subarrays file. These can be found in e.g., PRDOPSSOC-068/subarraysXML/subarraysXML/NIRISS_Subarrays.xml. I've copied and pasted the relevant parts for SUBSTRIP96 and 256 below:

SUBSTRIP96:
        <SubarrayCorners>
            <RowCorner>1</RowCorner>
            <ColumnCorner>151</ColumnCorner>
            <SciRowCorner>1803</SciRowCorner>
            <SciColumnCorner>1</SciColumnCorner>
        </SubarrayCorners>

SUBSTRIP256:
        <SubarrayCorners>
            <RowCorner>1</RowCorner>
            <ColumnCorner>1</ColumnCorner>
            <SciRowCorner>1793</SciRowCorner>
            <SciColumnCorner>1</SciColumnCorner>
        </SubarrayCorners>

Note that the subarray Y-corners are correctly defined with offsets of +10 for SUBSTRIP96 vs SUBSTRIP256 as @hover2pi mentioned.

Changing the code as suggested above will probably require working in the full-frame coordinates frame, and then converting back into the subarray coordinates, but this way, it wouldn't rely on the cryptic SIAF parameters.

@Witchblade101
Copy link
Collaborator

@tapastro Does Tony's proposed fix work for you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants