STIS Calibration Proposal Procedures

1. Createpro (usually run for you).

Generally, one of the members of the STIS group at STScI requests a particular calibration program. If it has been (or will be) approved by the TTRB, the calibration manager, currently Denise Taylor, assigns a proposal number and creates the skeleton phase II. Denise informs the PC that a STIS/CAL proposal number has been assigned. You should see a submission of a proposal within a "reasonable" amount of time.

What is "reasonable?" If a proposal has not been submitted within a week of the assignment of the proposal number, contact the PI and ask when he or she intends to submit the proposal.

2. Create a history file and start a folder.

3. SPEC COMmanding exposure lines.

Review all STIS/CAL proposals for the SPECial COMmanding exposure special requirement. This special requirement is used whenever standard processing through Transformation does not support the instrument commanding required by a calibration proposal. The PI should have inserted comments describing what he or she would like to do with the instrument in the exposures that need special commanding.

The PC should contact one of the members of the commanding group (usually Vicki Balzano) and give them a formatted copy of the proposal having special commanding requirements. The commanding group will tell you if any changes need to be made to the proposal and if any additional comments need to be inserted into the exposure comments. These comments describe any "special" processing of the proposal after it is loaded into the PMDB.

For STIS calibrations the SPECial COMmanding special requirement comes in two flavors:

(a) When the "normal" commanding instructions cannot be used, the special commanding requirement is placed in a separate S/C (SpaceCraft) exposure line with the appropriate special processing comments. (Note: Special processing of the PMDB is accomplished using isql command files described later section -- item 14)

(b) The normal commanding instructions can be used, but the transformation does not populate the PMDB correctly in order to meet the special commanding requirements. One example of this is when the PI wants to use more than one TUNGSTEN calibration lamp in an exposure. This also requires special processing of the PMDB using isql command files (See item 14).

As a general rule, all S/C lines with the SPEC COM requirement should be forced into the same alignment as the following (or preceding) instrument exposure line using the SAME ALIGNMENT <list> special requirement. If there are more than two special commanding S/C lines within a visit, it's probably best (well ... simpler is better, isn't it?) to force the entire exposure sequence within the visit into the same alignment. There may be cases where the entire visit should not be forced into the same alignment, in which case each S/C exposure line must be dealt with separately. See proposals 7944 and 7969 for examples.

In some cases, forcing a S/C exposure line into the same alignment as a STIS exposure line can result in transformation merging rule errors. The following merging rule errors are OK and can be waived:

• - BREAK STIS EXPOSURES USING CALIBRATION LAMPS
• - BREAK STIS ACQ EXPOSURES

The errors will make the visit dead and you will have to UNDEAD them using the PC toolbox. If you are unsure that a trans merging rule violation is OK, check with one of the commandos (Vicki Balzano, Ron Pitts or Dean Zak).

When the "normal" commanding instructions cannot be used, the special commanding requirement is placed in separate S/C (SpaceCraft) exposure lines with the appropriate special processing comments. (Note: The special processing of the PMDB is accomplished using isql command files described in Section.14)

4. Check the Phase II into PLIB and review the syntax diagnostics

Some of the calibration proposals will generate errors about illegal combinations of detector/aperture/filter. Normally, these are ok, but the PC should always check with the PI about these errors.

5. Run PIP.

If your proposal has external targets, you should run PIP as usual. If your proposal has only internal targets you don't need to run Quicklook. The toolbox will notice this and turn it off by default, but it's a good idea to check.

6. Review the output of PIP and BOAs.

A proposal generating Bright Object Alerts requires a Phase B review by the Contact Scientist. Since the PI is sometimes the CS for calibration proposals, contact the PI and he or she will get someone to conduct the phase B review.

You should review the trans diagnostics and the schedulability using either the ####-trouble.rpt and Spike, or the DG. If a visit has no external targets then it should be schedulable everywhere.

7. Verification is unnecessary.

After checking in the initial submission, set the LRP state to "ready" using the Update Tool, otherwise, the LRP state will remain "not_ready." The TTRB will allocate the number of orbits for the calibration proposals, and the PC needs to check that the proposal is within this time allocation.

8. Confirmation Charts.

If your proposal has external targets you should make confirmation charts and send them to the PI as usual.

9. Phase A and B reviews.

Phase A reviews are not done for calibration proposals.

If there are bright object alerts, a phase B review is required for STIS calibrations only, see item 6.

10. Plan Windows.

After the initial check-in of a proposal having an external target, someone in the LRP group (usually Ian or Bill) has to be told about it. The LRP software does NOT automatically assign plan windows. If a proposal is changed subsequent to the initial check-in (and has plan windows), the LRP software beast will adjust or add plan windows (to new visits) if necessary.

For proposals that are purely internal, you must ask Denise Taylor to assign plan windows. The plan windows for these internal visits are only contained in the baselined LRP (released weekly) so if you want to review them using the Report tool you must specifically choose Current Baselined LRP.

11. Re PIP proposal (if necessary).

12. Review Open OPRs as usual.

13. Load AFs as usual.

14. Creation and Review of isql to implement SPECial COMmanding requirements:

After the proposal has been loaded into the PMDB, the PMDB must be updated for the special commanding requirements. This is accomplished through the execution of isql (Interactive Structured Query Language) files. This is the same language that Transformation uses to populate the PMDB with its assignment files.

After the PC has consulted the commanding group about the special commanding requirements, the PC should create a file with the extension .isql in the UNIX directory $planning/8000/8### (for proposal numbers in the 8000 series). On the VMS side the equivalent directory name is spss_data_dk3:[planning.8000.8###]. Examples of "typical" special commanding isql files can be found in $planning/7000/7673.

The following remarks about isql command files are from a particular user's point view. I am not an isql programming expert and don't want to be one. So, caveat emptor :

The isql you are writing and using should always begin with some comments about the proposal being modified, the PC's name, and the date the file was last modified. All isql should start with "begin transaction" statement and "go" statements, and end with "commit" and "go" statements.

Modification of the PMDB is accomplished with either an "update <relation>" statement (to change the value of a field that already exists in a database relation), or an "insert into <relation>" statement (for new fields such as a new input parameter for a special instruction). All "insert" and "update into" statements include the name of the database relation, the name of the field being modified, and the appropriate programmatic numbers (proposal, obset, alignment, exposure, and version numbers). Although it's not required, these statements should end with a "go" statement. The "go statement in isql serves as a command line terminator.

You can copy the isql code from another proposal doing similar things, but make sure that the proposal number, visit numbers, alignment numbers, command names, spectral elements, etc. are correct for your proposal. You can edit the files you create in the UNIX directory with your favorite editor. These files will be read-only by default for everyone but the person who created the file.

You may find that using the Printpro button on the tool box to print a formatted version of the proposal, and copies of the ####-catalog.rpt (printed in landscape) and ####.summ files from the trans directory helpful in editing the isql files. See for example 7673-catalog.rpt and 7673.summ and compare these with the isql file, 7673_special_may8.isql .

After the isql has been written, give copies of the isql, the formatted proposal, the catalog file, and the summary file to Merle Reinhart (SPST) and Vicki Balzano (CMD) for their review.

Leave the paper copies with Merle. When Merle has finished reviewing the files and returned them, (and you have made any needed changes) you need to make an appointment to review them with Vicki. She will want to keep a copy of the three documents listed above, so make an extra copy for your own files.

Make any changes requested.

15. Execution of the isql.

Generally, I log onto the VMS Planning account. Change to the correct directory by typing the following command (with your proposal number):

 
set def spss_data_dk3:[planning.8000.8###]

To execute an isql file (on the VMS side) (replace <filename> with the name of your .isql file):

 
isql/input=<filename>

for each .isql file. During the execution of the command file, you should see messages scrolling on your screen indicating that PMDB records are being changed. Make sure that no errors occur, and that the correct number of records are reported as having been affected.

On the UNIX side the equivalent directory name is (for 8000 series proposals)

 
/vms/spst_prep_planning/8000/8###

To execute an isql file on the UNIX side:

 
isql < <filename>

16. SPSS Processing.

Normal SPSS processing is done for proposals with external targets. For proposals with internal targets, only run Obset Update, Visit Update and Prep Done (skip Guide Star processing).