22170 is marked unsure about desisurveyops

[schlafly]

It looks to me like this was observed once with the fast sequencing mode on on 20220413, and then in a normal fine exposure on 20220414. At least 130095 needs to be marked bad. @araichoor , can you confirm that the "turbulence plot" shows the average offset of the positioners over the different petals, so that the weird performance here
https://data.desi.lbl.gov/desi/spectro/redux/daily/tiles/cumulative/22170/20220414/tile-qa-22170-thru20220414.png
reflects the fact that P3 dropped out of the 20220413 observation, and the rest of the petals were in both, and good in the second observation? That's what it looks to me like from the coordinates file? I don't know what to make of the weird GOODPOS entries.

[djschlegel]

Exposure 130095 on 20220413 needs to be marked bad. Exposure 130226 on 20220414 should be kept. Then this BRIGHT tile is about half-way completed.

[schlafly]

This looks like it was done, but there's an inconsistency now between tiles.csv and tiles-specstatus.ecsv that I don't understand. The former reports 95 s EFFTIME, while the latter reports OBSEND and 210 s EFFTIME. @sbailey?

[sbailey]

The inconsistency is due to post-facto removing 20220413/130095 by hand, and then having that propagate to tiles.csv but not automatically to tiles-specstatus.ecsv. I need to investigate the proper procedure for this case.

[sbailey]

I updated tile 22170 with:

desi_update_tiles_specstatus -s tiles-specstatus.ecsv -t $CFS/desi/spectro/redux/daily/tiles.csv --tileids 22170 --all

And verified that only one line changed before committing.

TILEID NEXP EXPTIME EFFTIME_SPEC OBSSTATUS   QA  
------ ---- ------- ------------ --------- ------
 22170    2  1509.8         95.5  obsstart unsure

I'm not sure if it is a bug or a feature that NEXP=2 given that one of those two is a rejected exposure, but at least EFFTIME_SPEC is now correct.

@schlafly if you are satisfied with this, please close ticket.

[schlafly]

Thanks. I went ahead and did the same procedure for 23108, which is the other case where I was aware of this happening. I then did it for all tiles just to see what got updated. There were too many updates for me to inspect (318 tiles; 217 main survey tiles; 198 non-backup main survey tiles). Focusing only on ones where the OBSSTATUS changed, there were only 2 main survey, non-backup tiles, 24668 and 25864. The latter is done but we haven't been QAing it because tiles-specstatus doesn't think it's done. I've now updated both of these as well.

I haven't tried to figure out more generally what the other 200 cases are where desi_update_tiles_specstatus wants to change main survey tile entries, and worry a little...