| Fast TOO Handling |
There are two classes of TOO's:
There are several "speeds" of TOO response:
There are 5 groups associated with processing TOO requests:
When a TOO request arrives, there are six stages of "Processing" that have to be gone through, in this order:
NOTE: In general, ACIS OPS CANNOT make a move in assigning an SI mode unless and until the OBSCAT parameters have been updated. An exception is a Fast PR TOO: most PR TOO's have already been assigned SI_MODES. In this case, the steps to be taken may skip steps 3,4 and go directly to 5, which leaves ACIS Ops out of the loop. For a DDT, there will always be a change, and ACIS ops does have to wait for notification from Arcops.
The CDO must evaluate and approve the TOO request. If the TOO request is accepted, CDO must inform the rest of the groups that the TOO has been approved and CDO must set those parameters in the Observation Catalog (OBSCAT) which only CDO should set. Once CDO completes those tasks, CDO should transfer the responsibility for the final configuration of the observation to USINT. The USINT scientist will then finalize the configuration with the Guest Observer (GO) and request OBSCAT changes be made by arcops.
When the OBSCAT parameters have been updated, and ACIS Ops informed of this fact, ACIS Ops will assign the SIMODE. Two pieces of information are required:
Once the SIMODE is assigned by ACIS Ops, it is entered into the OBSCAT, and ACISDUDE has annoounced that the assignment is complete, the USINT scientist will ask the GO to verify the final configuration of the observation. Once the GO agrees to a final configuration, SOT MP may extract the observation from the OBSCAT for the creation of the Observation Request (OR) to send to FOT MP. In the case of a Fast TOO, SOT MP may create the OR by hand in order to expedite the load generation process.
The details of each of these steps including the mechanism by which one group informs the other groups of a transfer of responsibility at the end of a stage can be found at:
SI modes need to be assigned ASAP.
RULE: NO SI modes are to be built for Fast TOO's. The Observer must adjust the parameters of the observation in order to use an existing one.
If the SACGS SI mode assignment procedure tells you that an SI mode has to be created, your first move is to go to the SI Mode Finder.
Enter the information based upon the OBSCAT and hit Submit Query.
Occasionally you will see that the SI mode parameter block ID that SACGS says you need (output of the OBSPARAMS command), actually does exist. This means that the SI mode is close but perhaps not updated after a recent change in general ACIS operation. For example, the FEP video offsets were recently changed and all SI modes for a few years were updated. However a FAST TOO needed an older SI mode that actually did exist but was not updated.
If you see this SI mode listed in the SI Mode Finder results, then run SIdiff.pl to determine the differences between the required SI mode parameters in your obsreq.cmd and the old version of the SI mode. If the changes are inconsequential then you can force the assignment of the old SI mode using the override procedure described in the man page for ocatByObsid. Be sure to be conversant with the mechanism for forcing the assignment of an SI mode over the objections of SACGS.
The SACGS SI Mode Finder does not allow entry of ALL parameters which define a parameter block. Therefore you might get a few suggested SI Modes which might fill the bill. SIdiff.pl might tell you if these are usable.
If they are not, then send email to USINT informing them that no SI mode exists. You should include the possibilities that the SI Mode Finder suggested IF you think they are close enough. An example might be that the Observer requested a sub-array, and it's size/location is so close to what the SI Mode Finder suggests that a reasonable substitution is possible.
The SI Mode Finder shows all modes in the ACIS Tables; many of the older ones will be inappropriate to use because of intervening global changes. At this writing, avoid CC modes with IDs lower than CC_00100. Also avoid TE modes for which the parameter block has a command sequence number lower than 10818.
You will also want to screen out modes which were 'hand built', rather than created via the SACGS ruleset. Since the SACGS ruleset process always updates the $SGPROD/data/te.dat or $SGPROD/data/cc.dat files, you can grep those files for the pblock id (in lower case); if the pblock is recorded there, it was not hand built, and the mode is available for observers.
When you have assigned SIMODEs for TOOs you MUST email:
Last updated: 08/15/12