Handle when VISP observations are aborted or cancelled on summit
Fraser Watson
Branch: handle_summit_abort
handle_summit_abort
Branch: main
main
Merged
#69 · Created  · Last updated
Merged pull request
Merged in handle_summit_abort (pull request #69)
2895bc5·Author: Fraser Watson·Closed by: Arthur Eigenbrot·2022-06-14
Description
As the number of aborted observations being sent to the DC are increasing over time, we need to be able to handle the data that is sent in this case. There are two possibilities:
there is one single scan which was aborted and so the map number is right but the number of scan steps needs to be reduced to match the number of scan steps actually recorded
there are multiple maps and the abort occurred during the last map. In this case, the last map should be discarded and the complete maps used to create L1 data.
This is accomplished by the removal of the PickyMapBud which caused the pipelines to fail during parse, and changing the NumMapScansBud and TotalRasterStepsBud to work out how many should be used in the L1 reduction.
The new map and raster scan numbers are also added to the relevant L1 data under the appropriate SPEC-214 keywords.
As the number of aborted observations being sent to the DC are increasing over time, we need to be able to handle the data that is sent in this case. There are two possibilities:
there is one single scan which was aborted and so the map number is right but the number of scan steps needs to be reduced to match the number of scan steps actually recorded
there are multiple maps and the abort occurred during the last map. In this case, the last map should be discarded and the complete maps used to create L1 data.
This is accomplished by the removal of the
PickyMapBudwhich caused the pipelines to fail duringparse, and changing theNumMapScansBudandTotalRasterStepsBudto work out how many should be used in the L1 reduction.The new map and raster scan numbers are also added to the relevant L1 data under the appropriate SPEC-214 keywords.