Closed sbailey closed 1 month ago
I should look more, but I suspect that this is the issue
desi_fit_cte_night -n 20231028 -c a01456789 -e 202529,202530
which I take to mean that you have explicitly requested that desi_fit_cte_night not compute CTE corrections for petals 2 and 3. This then leads to problems applying CTE corrections to petal 3 (petal 2 doesn't have any CTE).
We do have offcols in DESI_SPECTRO_CALIB for that night, so we do expect preproc to want to find corrections and desi_fit_cte_night to compute them, unless it is explicitly told not to compute them.
@schlafly thanks for reading the command correctly and noticing that the long camword string was missing "2" and "3". It is then an upstream problem for why the pipeline didn't ask for CTE corrections for those cameras even though it did ask it for other cameras that don't need a correction. I think the intension was for the pipeline to give desi_fit_cte_night the superset of cameras on the night and let desi_fit_cte_night pick which ones actually need a correction, but perhaps we have a union vs. intersection bug in camera bookkeeping.
I did look briefly at that night and I suspect it's a case where something like the P2 and P3 are problematic at the beginning of the night and were marked to be masked. But then later in the night we no longer mask them. If that's right there's some mess about needing to get some cals from earlier nights, etc..
But I'm going to take your comment as absolving me of responsibility for this particular issue---at least for the moment---can you assign someone else? :-)
Blocking factor for processing Jura night 20231028
The jura prod ran CTE corrections with:
This generated calibnight/20231028/ctecorr-20231028.yaml with CTE corrections for z1C and z7B.
However, all arc jobs failed while preprocessing z3 with error messages like:
@schlafly can you track down whether 20231028 z3C needs a CTE correction or not, and why desi_fit_cte_night and desi_preproc seem to disagree about that?