Closed stscijgbot-jp closed 1 year ago
Comment by Maria Pena-Guerrero on JIRA:
I downloaded the files from MAST and ran TSO3 on observation 29 without issue. I am using pipeline version 1.12.0. Are you still seeing any issues?
Comment by John Scott on JIRA:
Reproduced the failure with build 9.3.1 on August 30, 2023
Comment by Maria Pena-Guerrero on JIRA:
I just tested locally with build 9.3.1 and both CRDS contexts 1110 and 1130, and the TSO3 pipeline ran successfully on both. Was the data recently downloaded from MAST? I ran the TSO3 with the products directly from MAST, i.e. I did not do the whole reprocessing from uncal.
Comment by John Scott on JIRA:
Sorry for the confusion - the problem is still showing up for jw01550-c1001_20230830t034805_tso3_00001 while this ticket references jw01550-c1001_20230717t083335_tso3_00002. On Aug 30, this 00002 product ran just fine, while the 00001 product showed the out-of-bounds error.
for reference, jw01550-c1001_20230717t083335_tso3_00002 is the same thing as jw01550-c1001_20230830t034805_tso3_00001. they both are associations for product named "jw01550-c1001_t005_nircam_f356w-grismr-subgrism128" consisting of two observations 28 & 29. so the failure is for the same product.
the members in the association are:
"expname": "jw01550028001_03103_00001-seg001_nrcalong_calints.fits",
"exptype": "science",
"expname": "jw01550029001_03103_00001-seg001_nrcalong_calints.fits",
"exptype": "science",
"expname": "jw01550028001_02102_00001-seg001_nrcalong_cal.fits",
"exptype": "target_acquisition",
"expname": "jw01550029001_02102_00001-seg001_nrcalong_cal.fits",
"exptype": "target_acquisition", ```
the latest asn table file is attached. [Maria Pena-Guerrero](https://jira.stsci.edu/secure/ViewProfile.jspa?name=pena) did you run tso3 on this specific asn?
Comment by Maria Pena-Guerrero on JIRA:
no, I did not run it on that specific asn. I will try the one you uploaded. I used jw01550-o029_20230830t034805_tso3_00001_asn.json, which has these:
"expname": "jw01550029001_03103_00001-seg001_nrcalong_calints.fits",
"exptype": "science",
"exposerr": "null",
"asn_candidate": "('o029', 'observation')"
},
{
"expname": "jw01550029001_02102_00001-seg001_nrcalong_cal.fits",
"exptype": "target_acquisition",
"exposerr": "null",
"asn_candidate": "[('o029', 'observation'), ('c1001', 'group')]"
Comment by Maria Pena-Guerrero on JIRA:
ok, I am now able to reproduce the error, yay! Investigating
Comment by Howard Bushouse on JIRA:
Investigating the content of this tso3 ASN. The problem in the Cal pipeline is being caused by the fact that data from two different observations are being included in the tso3: obs28 and obs29. Looking at the APT for program 1550, obs28 and obs29 are essentially identical in that they observe the same target, both in the NIRCam Time-Series Grism mode, using the SUBGRISM128 subarray. The only difference between the two is that they use 1 vs. 4 readout amps, leading to different readout times. Furthermore, there is a Special Requirement (SR) attached to both observations: "Group Observations 28, 29, non-interruptible". I suspect this is the reason why they were given the same asn-candidate ID, which then leads to them getting included in the same tso3 ASN by the asn generator.
Comment by Howard Bushouse on JIRA:
Regarding the asn_candidate ID's, here are the entries from the tso3 asn file:
{
"expname": "jw01550028001_03103_00001-seg001_nrcalong_calints.fits",
"exptype": "science",
"exposerr": "null",
"asn_candidate": "[('o028', 'observation'), ('c1001', 'group')]"
},
{
"expname": "jw01550029001_03103_00001-seg001_nrcalong_calints.fits",
"exptype": "science",
"exposerr": "null",
"asn_candidate": "[('o029', 'observation'), ('c1001', 'group')]"
},```
As you can see, each science member has a unique "observation" candidate ID (o028 vs. o029), but they are both assigned the same "group" candidate ID (c1001). Hence they both end up in the same c1001_tso3 ASN file, which in turn leads to the failure in calwebb_tso3 processing, because the algorithms are not anticipating data spread across multiple observations (nor should they be).
Furthermore, given that the two observations use slightly different readout parameters, there's no way anyone would **want** the data from the two combined together into a single level-3 product. They should receive independent processing.
Comment by Howard Bushouse on JIRA:
So the ultimate solution to this error will likely be in the form of an ASN rule update, so that multiple TSO observations don't get included in a single level-3 ASN.
Comment by Howard Bushouse on JIRA:
I've download the jw01550 pool file from MAST and put it in the (newly created) data directory ██████████████████████████████████████████ so that it can be used for exploring ASN rule updates, if necessary.
Comment by Howard Bushouse on JIRA:
Jonathan Eisenhamer Given that the exposures from obs28 and obs29 are both assigned a c1001 group candidate ID, is it feasible to make some kind of update in the ASN rules to essentially just ignore the c1001 candidate (and hence not create a c1001 asn), and instead use only the o028 and o029 group candidate IDs to create individual observation-level asn's for each?
Comment by Tyler Pauly on JIRA:
I think it should be doable like this PR: https://github.com/spacetelescope/jwst/pull/6131/files
Is it true that no group candidates should ever be considered?
Comment by Howard Bushouse on JIRA:
Fixed by #7982 which modifies level-3 TSO ASN rules to no longer create any group-level ASN's for TSO's. So the c1001 tso3 asn that caused this problem won't get created anymore.
Issue JP-3308 was created on JIRA by Hien Tran:
processing of new nrc_tsgrism level_3 dataset jw01550-c1001_20230717t083335_tso3_00002 (consisting of observations 1550:28 and 1550:29) with b9.2.1 gave the following error