Quick SI Mode Assignment Guide

When you are on call, you will often have to assign SI modes to observations. Various reasons include: When this happens, you will follow the directions located on the SI_MODES and SACGS webpage:

Memos Webpage

This document is a quick overview of the high level process to follow. You are running through the SACGS procedures as detailed in

SACGS Short form Documentation

and you get to Step 2.3 - Check whether table update is needed. If a cat of obsreqs.cmd returns nothing, then you comtinue with the steps in the Guide.
But if obsreqs.cmd is not empty then SACGS cannot find an SI Mode that fits the requirements in the OCAT. From there you have two possibilities: If they are happy with the SI Mode you suggest, they modify the OCAT to conform to that parameter block and you run through the SACGS SI mode assignment procedure.

To find one that you might suggest, you use the SI Mode Finder tool:
SI_Mode finder

The important thing to remember about this tool is that it does not allow you to exhaustively specify all of the parameters that govern SI mode selection.

If no SI modes are suggested by the tool, you then have to build it. To do so you proceed to Step 3.1. - Run the script cmd2dat.

If some candidate SI modes result, you have to determine the differences between those candidates and the configuration as specified by the OCAT. To do this you use the script SIdiff.pl. This script will compare all the parameters in the candidate and required parameter blocks and list any differences.

Usage: SIdiff.pl [-r ACIS Tables rootnm] [-B]
(Use -B switch if you want to build tables for the comparison from a just created obsreqs.cmd.)

Where: IMPORTANT!!! DO NOT FORGET THE -B!!!

So if your root directory name is 04may_15647, then your SIdiff.pl command might look like:

SIdiff.pl -r 04may_15647 -B WT00B92014 WT00B8E014

In this example, WT00B92014 is the parameter block identified from obsreq.cmd and WT00B8E014 is the parameter block ID from your candidate SI Mode, suggested by SI Mode Finder.

You will get an output that looks like a Linux "diff" was done because.... a Linux "diff" was done. An example out put looks like:

Creating comparison tables 04may_15647.*...
3c3
< commandIdentifier = 13169
---
> commandIdentifier = 13148
6,7c6,7
< checksum = 44660
< parameterBlockId = 0x00b92014
---
> checksum = 28492
> parameterBlockId = 0x00b8e014
17c17
< subarrayRowCount = 773
---
> subarrayRowCount = 511


A difference in command identifier, checksum, and parameterBlockId are expected and irrelevant. However in this example, the OCAT requests a row count of 773 and this SI mode sports a row count of only 511. This is enough of a difference to reject this candidate mode. Experience will allow you to be able to judge whether a candidate SI mode is close enough to suggest using it.

Final Note - Number Systems

We in the ACIS Ops world use a zero based number system. Other groups do not. So for example, if the OCAT says that an observation subarray start row is 128, our paramter blocks will have 127 for that slot. When you are running the SACGS system and it fetches an observation from the OCAT, SACGS is smart enough to reconcile that numeric base difference by subtracting a 1 from any OCAT parameter that is affected. So if it finds an SI mode for you that will work, you will see our parameter block sporting a 127 where the OCAT will specify 128.

However, when you run SIdiff.pl, both sets of output values are zero based.

So let's assume that the OCAT specified a subarray start row of 125. Further assume we have no SI mode that has a subarray start row of 124. But suppose we DO have an SI mode with a start row of 127. You would ask the USINT if starting at row 128 is ok. If they say yes, then you ask them to modify the OCAT to say 128. When you run SACGS again, the SI mode will be found and assigned.