Overview

When a replan causes one or more obsids with dropped chips to be unscheduled, arcops rules require that the simode field in the Obervation Catalog be nulled out. It then becomes necessary to determine whether the dropped chip count should remain, or be set back to zero, and to update the simode accordingly. Given the time constraints of replans, this should be done in the most expeditious possible manner.

What follows is an accounting of the proper order of events to ensure a timely restoration of the simode and droppedChipCount fields under these circumstances, together with a description of the script scanDropHist.pl used to check for dropped chips in the interrupted load.

In overview, ACIS ops has the main responsibility for tracking dropped chip status, and for sending out emails reminding other parties of what they need to do.

And what's needed? From FOTMP, ACIS needs an early estimate of the rough start time of any TOO replan. We would also like to have, once the MCC for the replan is run, an indication for each re-scheduled obsid whether it continues to require a dropped chip.

NOTE: Thus far, the FOT's practice has simply been to continue with the assumption that any dropped chip will continue to be dropped if the obsid in question remains in the replan at all. Brent has indicated that it would not be difficult to modify FOT scripts to double check that assumption, and he will put it on the FOT's to-do list. Installing those modifications will be appreciated, but there's no need for the FOT to treat it as an urgent change.

From SOTMP, the only requirement is that they wait for an ACIS email indicating that simodes and dropped chip counts have been updated, before asking arcops to mark the replanned obsids as 'scheduled'.

Finally, it turns out that arcops is already doing everything it needs to do in these situations.

The scanDropHist.pl script

scanDropHist.pl will check the dropped chip history file (/data/acis/LoadReviews/chipDrops.hst) against an interrupted ACIS-LoadReview.txt, and indicate what obsids with dropped chips, if any, occur in the load after the interrupt.

• If the interrupt occurs during the dropped-chip obsid, it does get reported.
• If an obsid has previously had a chip dropped for the week in question, which was subsequently undropped, it will show up in the report with the '0' dropped chip count indicated.

At least one of the following messages will appear when the script is run:

<obsid> with drop count 0 is in replanned portion of load.
<obsid> with drop count 1 is in replanned portion of load.
No dropped chips in replanned portion of <MMMDDYY>
No dropped chips in <MMMDDYY>

The third message appears when there was were dropped chips in the load, but all the affected observations have already been completed.

The script is called as follows:

% scanDropHist.pl -l <load> -t <interrupt time of replan>

% scanDropHist.pl -l DEC1808 -t 2008:357:00:14:00.00

It's not very forgiving about its parameters. It wants the full interrupt time string, and will interpret the last two characters of the loadname as a year. The output messages appear on stdout.

Sequence of events for a replanned load

1. ACIS determines the load interrupt time. In practice, all that's needed is to know the last obsid before the interrupt.
   • For SCS-107 replans: the email message from MTA will contain an exact interrupt time
   • For fast TOO replans: Upon receipt of email indicating the director's acceptance of the TOO, ACIS should send email to the FOT asking which obsid will be the last one before the load break.
2. ACIS ops runs the scanDropHist.pl script. The script will determine what dropped chip observations, if any, are in the affected part of the load.
3. ACIS sends email to FOTMP, SOTMP, and arcops indicating the results of the script run. Were there any dropped chips in the interrupted portion of the load?
   • If not, the email simply advises of that fact, and the sequence of events is complete.
   • If so, the email reminds SOTMP that it must wait for a further ACIS email before archiving (step 9), and asks FOTMP for the results of step 4.
4. FOT runs MCC, producing the 1PIN1ATor 1PDEAT plots. At some point, FOTMP scripts will be updated to generate additional plots without dropped chips, to learn which of the relevant obsids would still overheat, and immediately forward the results to ACIS. Until the FOT script update is ready, ACIS will assume the answer is "retain the dropped chips on all obsids which are not postponed." In any case, FOTMP will advise of any dropped chip obsids which are now to be rescheduled for a later week.
5. In parallel with step (4), SOTMP sends a request to arcops, which unschedules the obsids in the remainder of the interrupted load.
6. Arcops automatically sends email to interested parties, including acisdude, indicating which obsids are unscheduled.
7. ACIS runs ocatByObsid to update the dropped chip counts and simodes for each item in the remainder of the interrupted load for which there had been a dropped chip. This is necessary whether the dropped chip count changes or not. For any obsid to be rescheduled in a later week, set the dropped chip count to zero.
8. ACIS sends an all clear email to SOT MP and arcops.
9. SOTMP requests archival, and arcops marks the obsids in the replan as 'scheduled' again.