1. Continuity loads with the same name as Review load or with a different load letter than is pointed to by .../ofls.
2. Full load (science + vehicle commands) where only the vehicle commands are enabled.

1. Load Letter for the continuity load

To fix these problems you now MAY apply a load letter to the continuity load. You would do this under these two circumstances:

1. Continuity load has the same name as the review load, but is an earlier load letter
2. Continuity load has a differnt name but for some reason the continuity load used by MP is not the one pointed to by the .../ofls soft link

For the first possibility, we can now issue the following lr command: lr SEP2021B SEP2021A

The second possibility has not happened yet but it may. Here is a possible scenario:

There is an OCT0122 A, B and C load

OCT0122B was uplinked to the spacecraft and run

OCT0822A load comes out for review and the Continuity load is therefore OCT0122B

Therfore the command you should issue is: lr OCT0822A OCT0122B

You don't need to specify the continuity load letter under normal circumstances.

2. Full loads (science + vehicle commands) where only the vehicle commands are enabled

1. JAN1722 vehicle-only-enabled
2. OCT2821 vehicle-only-enabled

Handling this situation requires a new switch to the lr command: --VO (Vehicle Only).
There are two acceptable values for the switch:

• "VOR" - Vehicle Only Review
• "VOC" - Vehicle Only Continuity.

VOR - Vehicle Only Review

All other lr switchology remains the same (e.g. -T, -B, --nolucky, --nomodels etc).

Under the hood, what happens is that lr will save the CR*.backstop
file to ORIG_CR*.backstop and then copy the ....vehicle/VR*.backstop
into CR*.backstop and the review done by lr is on the "new" CR file. The
benefit of this is that when the review load becomes the continuity
load the next week, lr and the thermal models will automatically
process the correct commands.

VOC - Vehicle Only Continuity

The LR command would be:

lr --VO VOC Review-load Continuity-load

This will cause lr to use the .../vehicle/VR*.backstop file in the Continuity directory for assembling a history used by lr and the thermal models.

All other lr switchology remains the same (e.g. -T, -B, --nolucky, --nomodels etc).

Special Cases

The FEB0724 load was interrupted with an SCS-107 due to high Solar Radiation. There was some talk of postponing the Resumption to Science
load until after Sunday. The approved FEB1224 load had already been uplinked. If the resumption load wasn't going to begin until after FEB1224 began, only the FEB1224 vehicle load would have been activated. This did not subsequently happen but if it did, the handling of the LR switches for the following Science Resumption Load reviews takes some care.
This discussion informs you how to handle that situation if it did occur.

Assuming it did happen, the situation, graphically, would have looked like this:

The FEB0724 load was interrupted at 2024:041:03:23:00.00, via an SCS-107. This means that the Vehicle-Only portion of the FEB0724 load continues to execute, but the Science Load stops (as indicated by the vertical red line through the FEB0724 load).

The FEB1224 load was reviewed and approved prior to the shutdown. It was uplinked to the satellite. If the start time of the Science Resumption Load occurs AFTER the start of the of the FEB1224 load, some commands in the the vehicle-only portion of the FEB1224 load will execute.

This means that the Science Resumption Load is interrupting the FEB1224 load just like a TOO load interrupts an executing load. The
command line should look like this (assuming the Science Resumption Load is FEB1424A):

lr --VO VOC -b FEB1424A FEB1224

Your responses to the LR questions will inform LR that this should be treated as a TOO (i.e. HRC-S was not inserted into the focal plane).

The VOC switch must be included because only the Vehicle-Only commands of the FEB1224 load were activated (in this scenario) so only the vehicle commands should be include in the assembled history.

Ok but what about the SCS-107 cut time? We never specified that to the system because the FEB1224 load was run as Normal. This is now handled by a change in LR. When it detects the situation like the one we have here: we've specified that the continuity file (and if you did so - the Review load) should be run as VO and you have called this a TOO, it will ask you something like this:

Ok this review load: FEB1124A ... is interrupting the FEB1224 as a TOO interrupt
but I also notice that the continuity load, MAY1524, is to be treated as vehicle Only.

Was the FEB1224 reviewed as a NORMAL load before its continuity load was interrupted by an SCS-107 (either 107-only or Full Stop)
and they uplinked FEB1224 as VO just to keep the spacecraft maneuvering until a Return to Science load could be  approved? [y/n]
 

Scripts Used

a. acis-backstop.pl - Does the majority of the checks.
b. saa_checker.pl - reports the solar array angle for forward sun and tail sun observations.
c. LRHS - python script to just test health and safety.
d. run_PSMC.pl - executes the python PSMC model.
e. mk_pscm_html.pl - adds the PSMC output to our PSMC webpage.
f. bright-source - looks for bright X-ray sources too close to our FOV.
g. earth-acis-FOV - reports the solid angle of the earth in the radiator's FOV.
h. plot_FOV_data.pl - plots the data from earth-acis-FOV.
i. backstop_comp.sh - compares the vehicle command backstop with the combined command backstop to check for descrepancies.
j. show_web_lr.pl - Creates a colorized html version of the load review text, and copies it to https://cxc.cfa.harvard.edu/acis/lr_texts/yyyy/MMMddyyV_lr.html

Script Descriptions

The ACIS Load Review

1. ACIS-LoadReview.txt - Reviewed by ACIS Operations Team
2. saa_check.txt - Reviewed by ACIS Operations Team
4. ACIS-Tables.txt - Reviewed by ACIS Operations Team
5. ACIS-History.txt - To be used in the next load
6. ACIS-FPHIST.dat - Used in ACIS orbital fluence monitor
7. ACIS-GRATHIST.dat - Used in ACIS orbital fluence monitor
8. ACIS-OBSHIST.txt - Used in ACIS Real-Time Engineering Web Page
9. ACIS-TLMHIST.txt - Used in ACIS Real-Time Engineering Web Page
10. ACIS-TSCHIST.txt - Used in ACIS Real-Time Engineering Web 11. ACIS-STORED-HIST.txt - Used for next load
12. ACIS-LoadReview_HandS.txt - Health and Safety check load review
13. ACIS-Perigee.txt - information on last perigee
14. output_psmc - directory containing the output for the PSMC review
15. _angles.txt - output earth solid angles versus time
16. _angles_idl.ps - output earth solid angle plot
17. violations.txt - output bright source violations
Page

• the SI mode in OCAT is consistent with the SI mode in the load
• the ACIS observing parameters stipulated in the OCAT are consistent with that of the parameter block being used in the observation
This consists of checking:

• that the chips selected in OCAT are the ones being selected in the parameter block
• that any sub-array defined in OCAT (start row, number of rows, alternating exposures, frame time) is consistent with the parameter block
• that the ACIS exposure mode and event telemetry format OCAT entries are consistent with the parameter block
• that the ACIS CCD "power-on" (ie, WSPOW****) is appropriate for the chip selection specified in OCAT
• that if a z-sim offset is specified, that it is specified in the load
• that the command load translates the SIM to the appropriate instrument (ACIS-I or ACIS-S) for that observation
• that for every ACIS observation there is "power-down" of all the video boards, a dump of the system configuration and Huffman tables, prior to the ACIS start science command
• that the appropriate gratings are inserted (or retracted) for that observation
• that the correct window block is used if one is specified
• that any unique observing parameters such as on-chip summing, an event filter range, changes to dither, or forced bias, are also defined in the parameter block that is used in the command load
• that the integration time is consistent with the integration time remaining according to OCAT
• the commanding for an ACIS diagnostic measurement is correct and as requested
• prior to perigee, that all video boards are powered down, and the system configuration and Huffman tables are dumped
• for HRC observations greater than 5 ks in duration, that ACIS is obtaining useful calibration data
• there is no significant "dead time" between stop of science observations and onset of calibration measurements on ingress and similarly egress of perigee
• that an OBSID change occurs prior to the start of the next science run
• ensure that the automatic tests have been done correctly
• examine the thermal check output html files for violations (listed as "NOT OK" at the top of the page, and investigate any issues flagged.

1. Automatic SIM and radiation zone tests

• check that there are ORBITAL EVENTS in the load (apogee/perigee, predicted radiation belt entry and exit times)
• ensure that there is a 10 kilo second (ks) pad time on entry to the rad zone (defined as pad = {time of radiation belt entry} - {time of RADMON disable})
• ensure that no SIM translation occurs during the entry leg pad time.
• ensure that the RADMON disable command is issued at least 10 ks before entry into the radiation belt but no earlier than 15 ks
• ensure that no SIM translation occurs during the radiation zone transit
• ensure that no SIM translation occurs during the exit leg pad time
• ensure that there is no SIM translation during an ACIS science run
• ensure that the RADMON enable command is issued at least 10 ks after exit from the radiation belt but no later than 15 ks
• ensure that there is a 10 ks pad time on exit form the radiation zone (defined as pad = {time of RADMON enable} - {time of radiation zone exit})
• Coupled with 2 of the above tests, the script ensures that the RADMON disable occurs before radiation zone entry and that RADMON enable occurs after radiation zone exit.
2. Automatic ACIS tests

• ensure an OBSID change occurs at least 3 minutes after a stop science
• check that there are at least as many occurrences of OBSID changes as there are ACIS start science commands
• check that there is at least one WSVIDALLDN for every start science
• check that there is at least one RS_0000001 for every start science
• check that there is at least one RH_0000001 for every start science
• check that there is at least one ACIS stop science command for every ACIS start science command
• check to see if the instrument is in format (FMT) 2 if ACIS is in the focal plane. (the observatory runs in format 2 when ACIS is in the FP and format 1 when HRC is in the FP)
• check to see that we are in FMT 2 when doing a CTI measurement
• check to see that we are in the HRC-S position prior to radiation belt entry
3. Gratings tests

• ensure that there is a low energy transmission grating (LETG) retraction for every LETG insertion
• ensure that there is a high energy transmission grating (HETG) retraction for every HETG insertion

Fast TOO Replan Reviews

• 1. Re-Open: If an entire week is re-scheduled for a TOO, after that week's load has been approved, but before it has begun to execute: i.e. we are still executing the previous load. Note: if the load under review interrupts the executing load (or the approved load after it begins to execute), use Case 2 below.
  
  
  The Example Setup:
  
  
  - MAR1714 load aboard and executing.
  
  - MAR2414A load approved but not uploaded.
  
  But because of the TOO, the planners will create:
  
  - MAR2414B TOO load containing the TOO, some or all of the MAR2414 load
  (Note: one or more observations had to be removed from either the MAR2414 load to make room for the TOO).
  
  
  The Steps: Run lr using the simple form, followed by history-files.pl: The script will ask if the replan load is another iteration of an already approved load, in which case, you answer yes. This will preserve the continuity of the history files once the TOO replan has been approved (see step 2 below).
  
  
  run: lr {current load} {previous load}
  after loads are approved: history-files.pl -too******************** {time} {status-array} It is the prior approval, not the loading of the schedule onto the spacecraft, which requires history-files.pl to be run. This case includes loads the FOT builds as "Re-Open schedules". Here {time} is taken from the load review announcement e-mail as the time of first command. Use:
  
  "Time of First Command: 2014:087:19:25:00.000"
  
  The {status array} is the final status taken from the MAR1714 ACIS-LoadReview.txt file.