-
Notifications
You must be signed in to change notification settings - Fork 167
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
fixed-type tuple error for level_3 tso data #7666
Comments
also seeing this for jw02158-o001_20230528t222142_tso3_00001 Directory Path: /ifs/archive/ops/jwst/info/owl/logs/owlmgr_jw02158-o001_20230528t222142_tso3_00001_1685438395.977274 ALOG_1685438945_repro_level_3_jw02158-o001_20230528t222142_tso3_00001.out
|
same problem seen for jw02508-o001_20230527t034736_tso3_00001, which is a MIR_LRS-SLITLESS tso3. so the problem seems to be connected to time series for all different inst/modes |
another case, jw02488-o001_20230528t230213_tso3_00001, which is a NRS_BRIGHTOBJ tso |
many failure cases (exited = 1) for 2512, but some also succeeded (exit code 0). these are all nrs_brightobj tso. don't see any obvious differences between them, except the failure seems occur for those asns with more than 6 science input members
|
Comment by Howard Bushouse on JIRA: Logs show that failure is occurring during the white_light step, after having successfully completed all steps through extract_1d. |
Comment by Michael Ridgaway on JIRA: We are also seeing this error occur for program 1201 data. Logs can be found here: /ifs/archive/ops/jwst/info/owl/logs/owlmgr_jw01201-o002_20230612t154303_tso3_00001_1686632977.502441 |
latest failure for jw02512-c1005_20230603t201124_tso3_00001, a 18-science member nrs_brightobj tso3 with sub2048 array
|
Comment by John Scott on JIRA: a list of affected datasets (cleaning these out of the pipeline for now) jw01274-o004_20230531t014455_tso3_00002 jw01224-o002_20230528t111952_tso3_00001 jw02512-o009_20230603t201124_tso3_00001 jw02512-o008_20230603t201124_tso3_00001 jw02488-o001_20230528t230213_tso3_00001 jw02508-o001_20230527t034736_tso3_00001 jw02512-c1003_20230603t201124_tso3_00001 jw01633-o005_20230601t145410_tso3_00001 jw02149-o002_20230528t221201_tso3_00001 jw01952-o001_20230602t204759_tso3_00001 jw01633-o004_20230601t145410_tso3_00001 jw02512-c1004_20230603t201124_tso3_00001 jw02512-c1002_20230603t201124_tso3_00001 jw02512-c1006_20230603t201124_tso3_00001 jw02158-o001_20230528t222142_tso3_00001 jw01274-o003_20230531t014455_tso3_00002 jw01274-o002_20230531t014455_tso3_00002 jw01274-o001_20230531t014455_tso3_00002 jw01201-o002_20230612t154303_tso3_00001 jw02512-c1005_20230603t201124_tso3_00001 jw02512-o010_20230603t201124_tso3_00001 jw02512-o017_20230603t201124_tso3_00001 jw02159-o001_20230706t061547_tso3_00001 jw02512-c1003_20230603t201124_tso3_00001 |
Comment by Tyler Pauly on JIRA: Quick investigation with a successful tso3 run, using a truncated input association, indicates that the ASDF extension takes up more memory than the other ~6098 extract1d extensions. Sending to ASDF experts - Brett Graham maybe? |
Comment by Brett Graham on JIRA: Tyler Pauly do you have an easily sharable link to the hopefully similar and successful tso3 run? I can take a look at the file. My first concern would be that the extensions are being duplicated again for some reason (similar to asdf-format/asdf#1232 |
Fixed by spacetelescope/stdatamodels#178 |
Comment by Howard Bushouse on JIRA: Fixed by spacetelescope/stdatamodels#178 Will be included in final release candidate for B9.3 (jwst 1.11.2, B9.3rc3). |
Comment by John Scott on JIRA: another case
|
Comment by John Scott on JIRA: jw02965-o003_20230709t121734_tso3_00001 is another case. |
Comment by John Scott on JIRA: another jw01185-o010_20230715t193546_tso3_00002 |
Comment by John Scott on JIRA: More (maybe some duplicates) /ifs/archive/ops/jwst/info/owl/logs/owlmgr_jw02084-o005_20230724t181148_tso3_00001_1690242142.899445/ALOG_1690554631_repro_level_3_jw02084-o005_20230724t181148_tso3_00001.err |
Issue JP-3277 was created on JIRA by Michael Ridgaway:
During build reprocessing following the install of JWST DMS Build 9.2.1 the following error was seen during Level 3 processing of program 1224 and 2149 data. "ValueError: invalid shape in fixed-type tuple: dimension does not fit into a C int."
Logs can be found here:
/ifs/archive/ops/jwst/info/owl/logs/owlmgr_jw01224-o002_20230528t111952_tso3_00001_1685490152.276564
/ifs/archive/ops/jwst/info/owl/logs/owlmgr_jw02149-o002_20230528t221201_tso3_00001_1685336491.324613
This is the same error seen in JP-2900 that was fixed for nrc_wfss data.
The text was updated successfully, but these errors were encountered: