NIRISS SOSS SUBSTRIP96 flux drop

[stscijgbot-jp]

Issue JP-3745 was created on JIRA by Aarynn Carter:

BACKGROUND: For NIRISS SOSS data, the extract1d step of the pipeline uses (by default) the ATOCA algorithm, which is an optimal spectral extraction routine that disentangles the signals from the overlapping order 1 and order 2 traces. For the SUBSTRIP256 both orders are captured, but for the SUBSTRIP96 order 2 is only partially captured. 

PROBLEM: When using the SUBSTRIP96 subarray, we have identified a characteristic "flux drop" at ~1.5 micron in extracted order 2 spectra that is not observed in comparable SUBSTRIP256 datasets, and is not consistent with the expected astrophysical spectra. This issue was initially coupled with an erroneous wavelength calibration that has been resolved by JP-3588, but it is now clear it has an alternative origin. The current thinking of the SOSS team is that when using SUBSTRIP96 the default ATOCA extraction algorithm is biased by the partial capturing of the order 2 spectrum, or an interaction with the subarray padding, and produces the flux drop. 

An example of this can be seen for program GO-3596. 

[stscijgbot-jp]

Comment by David Law on JIRA:

Just to get some context: JP-3588 is implementing the PASTASOSS approach that does a better job of matching real trace locations using adjustments based on PCWPOS, after which the ATOCA algorithm is applied as usual but at the updated locations.  This ticket is reporting a different issue with uncertain origin that persists even after the PASTASOSS change, potentially with the ATOCA algorithm itself or some other effect.  Is that about accurate?

[stscijgbot-jp]

Comment by Aarynn Carter on JIRA:

Hi David Law, that's right. From our testing this week the new JP-3588 implementation is looking good, but didn't resolve this issue, which was observed prior to the JP-3588 changes.