NIRSpec TSO filenames may be missing the slitname

[stscijgbot-jp]

Issue JP-3702 was created on JIRA by Tyler Pauly:

DMS Ops reported a data product has had its filename change:

https://stsci.slack.com/archives/C9KF4MVEV/p1722348421168879

I just noticed an issue where a JWST observation that had been included in a DOI was no longer available in the MAST portal. The original observation was:
jw02512-o008_t007_nirspec_f290lp-g395h-s1600a1-sub2048
and the observation that I think is equivalent is:
jw02512-o008_t007_nirspec_f290lp-g395h-sub2048

It looks like work completed for JP-3233 may have altered behavior for NIRSpec TSO data - it was not given the new product name generation, and the change to _get_opt_element removed the slit name from the concatenated list of elements.

Work should include new test coverage of NIRSpec BOTS - this should have been caught by regressions.

[stscijgbot-jp]

Comment by Melanie Clarke on JIRA:

PR for the fix is here: #8699 ](#8699 full details, but I will summarize here as well.

This issue primarily impacted BOTS mode, which has a FXD_SLIT defined, but does not get planned for the spec3 pipeline with Asn_Lv3NRSFSS rules. BOTS data are planned for tso3 with Asn_Lv3TSO rules. But it may also have impacted background targets for fixed slit, planned with Asn_Lv3SpecAux rules.

The issue was that in JP-3233, association rules were changed for fixed slits to allow S200A1 and S200A2 targets to be reduced together in spec3. Part of this change removed a check for the fixed slit as one of the 'opt_elem' fields in the filename. This had the unintended effect of removing the fixed slit from the name for BOTS and auxiliary NIRSpec data.

The fix here is to restore the check for FXD_SLIT in all level3 product names that might apply to NIRSpec data and add the value to the filename if present.

It looks like this regression was reported in the regression tests for JP-3233, but it was buried in some other expected changes. There are also some unit tests for level3 product names, but they were not specific enough to catch this regression.  I have updated the unit tests to catch this case specifically, and verified that they fail on the main branch and pass with this PR branch. I think the regression tests should be sufficient as is.

[stscijgbot-jp]

Comment by Melanie Clarke on JIRA:

Fixed by #8699

[stscijgbot-jp]

Comment by Tyler Pauly on JIRA:

Tested with 1.17.1 and confirmed that the slitname is present in the output for jw06456-o001, which shows the regressed behavior in MAST archived products:

!Screenshot 2025-01-09 at 9.19.03 AM.png|thumbnail!