9.1.1. Running Trans by itself

Use the Trans button in the Processing menu of the Toolbox.

If you want to run Trans from the command line, here are some examples. Remember to change the proposal number in both places and specifiy how many visits and/or targets you wish to Trans. (The dashes are produced by the word processing program, so leave those out if they appear in the examples below, everything is on one line.)

run-trans ops 9999 ':input "/data/implementation/proposals/" :output "/data/implementation/trans/9999/" :visits "01, 02"' :targets "1, 2"'

or

run-trans ops 9647 ':input "/data/implementation/proposals/" :output "/data/implementation/trans/9647/" :visits "01, 02"' :targets nil

Output will scroll to the terminal window, and the lisp environment in which Trans runs should exit and leave you back in your UNIX shell when Trans finishes running. You will need to check the trouble report in the Trans directory to see if there were any errors or warnings, see the next section. Running Trans from the command line will not update the database with the dates of the last Trans run. Since the Trans run dates are not updated in the database, you will need to use the "Directory" option under "Determine which entities to load" option. Or from the command line;

pmdb -load -driver=directory 

Everything else should proceed normally, until Flight Ready which will give you warnings about the visit change dates and the AF creation dates. You will need to waive these to set the visits flight ready.

9.1.2. Review the output files

The Trans output files are in the directory: /data/implementation/trans/9999/. There are many output files. To get a quick idea of how the proposal Transed, look at the trouble report and the catalog report.

The file 9999-trouble.rpt contains a summary of Trans diagnostics. Figure out which messages require a change in the proposal and which can be waived. There are three types of Trans diagnostics:

Health and Safety Errors: Health and safety errors must be eliminated from the program. If for some reason, there is a desire to override a health and safety error, commanding personnel must be consulted first. If health and safety errors are overridden in Trans, Trans will send mail to commanding personnel notifying them of the override; so it is best to talk to them before Trans does.

Errors: Errors must be reviewed and addressed during processing. In general, no program should be delivered to SPST for scheduling with outstanding Trans error messages. In the event that we must make such a program flight ready (i.e. special engineering programs, new capabilities) we must clearly document in the history file why the error exists and what manual fixups are anticipated to correct it. Unless it is an error that was anticipated (new capability) or has been handled in the recent past and you fully understand the source and remedy, you must receive advice from an SPST expert (like Merle Reinhart) or someone from commanding.

Warnings: Warnings must be reviewed and addressed during processing. No warnings are to be ignored such that the relevant lines are not investigated. Warnings may be waived by the PC but a record must be put in the history file. If you have any questions about the source or action required - ask for help from people in SPST(SMSB), or commanding. Do not simply assume it's probably not a real problem. If warnings are generated that the alignment is too long to fit the visibility, ensure that there is adequate visibility time sometime in the cycle and that you are able to create scheduling windows in SPSS.

Informational Messages: These are for informational purposes only and do not need to be evaluated unless you're looking for an answer that might be provided here. Informational messages generally include identification of overridden tunable constants, actions taken by Trans to maximize efficiency, parameters that have been reset by Trans as they were below/above their minimum/maximum value.

There is a nice on-line version of the diagnostic explanations . This is sometimes handier than the Trans Scripting Guide. It also includes the PI explanations (which are the ones that come up in APT).

The file 9999-catalog.rpt shows how Trans has structured the proposal into the building blocks used in scheduling the telescope. These building blocks are:

• Exposure
• Alignment - one or more exposures in the same aperture at the same pointing
• Obset (short for observation set) - one or more alignments that can use the same guide stars.
• Visit (also called SU for scheduling unit) - one or more obsets that can or should be scheduled together

It is rare, but sometimes it may be necessary to edit the proposal adding special implementation special requirements and re-Trans in order to obtain the proper structure.

9.1.3. If it is necessary to add implementation special requirements

Implementation special requirements are used to request non standard Trans processing of a proposal. For instance if a different alignment or obset structure is needed from what Trans would do by default, this is how you would do it.

There is a list of the implementation special requirements in the E version of the proposal instructions. Simply add the needed requirements to the proposal, and when you re-Trans the stucture should be what you have requested. Inform the PI that you have added these requirements to the proposal and they should not be removed when editing the proposal later on. Also remember to record the fact that you used implementation special requirements as well as the reason for doing so in the proposal history file in the "Progress, Notes, etc." section.

9.1.4. If it is necessary to override a Trans tunable-constant

Sometimes it is necessary to override a Trans tunable-constant. These files are named 9999-overrides.lisp and are kept in the /data/implementation/proposals/ directory. See other files in the proposals directory for examples. All files should contain only lines of the form:

(Override <constant-name> <new-value>)

Some commonly used commands are used for moving target proposals and include:

(Override MOSS-OVERRIDE-CYCLE-START  "1 Nov 2001")

(Override MOSS-OVERRIDE-CYCLE-END    "1 Aug 2002")

(Override Max-Moving-Target-Scan-Time 3200)

9.1.5. Print out and save reports (optional)

At first you may wish to keep a copy of the 9999-trouble.rpt and the 9999-catalog.rpt in the folder for each significantly different run. (Note that all the old information is overwritten.)

13.2.1. Using alternative guide star scenarios

Occasionally a visit will have insufficient guide star pairs returned. This will be obvious when reviewing the suitabilities in the next major section. Lack of guide star pairs can be due to sparse or crowded star fields. Scheduling limitations such as BETWEEN or ORIENT special requirements only make the problem worse because these limit the spacecraft rolls that can be used.

One option is to try looking for single guide stars. Changing to single guide star tracking degrades the pointing because roll is maintained by the gyros instead of a second guide star. In many cases it is acceptable to use single guide stars instead of pairs. Review with the CS (or si_csreview) and PI the roll errors associated with single guide star pointing to see if they are acceptable.

To request single guide stars, use the implementation special requirement GS ACQ SCENARIO SINGLE on the first exposure in the visit (or obset if there are multiple obsets). Now checkin, rerun Trans, reload, and re-request guide stars.

For more information on solving difficult guide star problems, see Procedures for Resolving Guide Star Problems. on line.

13.2.2. Bright object alert clearance

Bright Object Alerts (BOAs) are generated during GS request, and can be viewed by typing:

gs_request -status 09999:01:01

For FGS proposals, Denise Taylor and/or Bill Januszewski evaluates the BOAs. If you have tried to set something flight ready, and the waiver has not been filed, contact Denise or Bill.

For COS, STIS/NUV-MAMA, STIS/FUV-MAMA and ACS/SBC proposals all BOAs are cleared at the time of the CS review. The review sets the waiver in the database. If the proposal is re-loaded after the CS review, but has not changed in a way that would effect the BOA the PC can reset the Instrument Review complete date in the database Instrument Reviews tool.

There are no BOA concerns for ACS/WFC, STIS/CCD and WFC3.

19. Account for outstanding Trans errors and warnings

By this point you should know exactly why any outstanding Trans errors or warnings can be waived. If you haven't already, add an entry to the history file in the section called "Progress, Notes, etc." which contains the text of the errors and warnings from the Trans Trouble Report, and explain why the errors and warnings can be waived.

20. Update Visits

This will calculate scheduling windows, science instrument usage, and constraint and restriction overrides. Must be re-run if any of the above are changed.

You can manually set the SGD windows using the toolbox button. This is the time span through which a visit is prepped for execution. The default value is about a year, but a visit which contains MANY alignments (usually NICMOS) can take forever to process with large SGD windows. You can usually shrink the SGD windows for these observations to be around the plan window span. This cuts prep time, but means that if a visit is not scheduled within its plan window, it will have to be partially re-prepped for a different SGD window (rerun visit update and schedulability). You can use the Visit Update button in the tool box or type:

pmdb -update -type=su <SU ID> 

pmdb -update -type=su 0999901 

If a visit has Transformation errors, visit update will fail and indicate that the visit has been marked "dead" in the PMDB. If it is appropriate to waive the Transformation errors for the visit, use the visit status button in the PC Tool Box to mark the visit(s) undead, and then repeat the visit update.

schedulability <program ID> [visit1 visit2 ...]

schedulability 09999 01 

parameter: -ccl_name=

  default: <program ID>sch

 function: Name to be used by cclist -save.

parameter: -start_time=

  default: current date

 function: Start time to be used by cclist -create.

parameter: -end_time=

  default: current date + 1 year - a pad to keep within the orbit file

 function: End time to be used by cclist -create.

parameter: -verify_windows=<spike_cw | sgd>

  default: spike_cw

 function: Value passed to calopt -verify_windows qualifier.

parameter: -interval=

  default: determined by calopt from constraint_windows_ver_criteria

 function: Value passed to calopt -interval qualifier

parameter: -orbit_file=

  default: Latest orbit file.

 function: Value passed to cclist -create -orbit_file qualifier.

parameter: -handoff

  default: disabled

 function: calopt -handoff qualifier

parameter: -verbose

  default: disabled

 function: Display schedulability verbose messages.

parameter: -very_verbose

  default: disabled

 function: Will cause cclist -create and calopt to be run with

           -verbose qualifiers, and will display all LRP replan

           messages if a replan takes place.

parameter: -force_calopt

  default: disabled

 function: Forces calopt to be run.  Supersedes all other criteria for

           determining if calopt should be run including

           su_track.vcw_required field.

parameter: -noreplan

  default: disabled

 function: Surpresses normal Spike run after calopt in order to replan visits

           with new calopt output.

 /data/implementation/confirm-charts/9999/

confirm-chart [-chart_time=<SPSS format time>] <program ID> [target number list]

confirm-chart -id 9999 -targets 1 2 5 10 23

state-change.tcl 9999 01 status scheduling

Change Requests

At any point during this process you could receive a change request. It is not essentially different from the changes you have made all along in order to resolve problems that you or other reviewers found. The difference is that the change is initiated by the PI to enhance or correct the proposal. Discuss with your CS (or email si_change) if the change varies from the original Phase I proposal or will require much rework. Depending on the type of change, it may be necessary to do duplication checking again. A full treatment of our change request policy is available on the web.

If the proposal has already been marked flight ready, you will need to make sure that it's not on a flight calendar. You cannot yank a visit from a calendar without consulting with the calendar builders. Use the Update program to set the status back to implementation.

Monitoring

Special Processing for Special Programs

Important Notes:

1. 1. ISQL . Do not update the PMDB via direct ISQL unless you have completed training in ISQL. If you forget a ``where'' clause or mistype something, you could cause ground system down-time while restoring the DB to its correct state or; at worst, cause a safing or instrument damage. Any updates to the PMDB made outside of the standard tools must be done with care by qualified individuals. In such cases, database transactions must be used. Most non-standard PMDB updates can be done safely by anyone via the PFORMs. A listing of the PFORM's and a keyboard layout diagram are given in Appendix C .
2. 2. Leading zeros . In all of the subsystems prior to SPSS, an observing program ID number is represented by an integer. However, in SPSS and the PMDB, an observing program ID number is represented as a 5-character string. This means that in SPSS, observing program ID numbers less than 10000 begin with a leading zero. When running SPSS from the command line, the leading zeros must be included. Examples: pmdb -delete 07445, pmdb -update -type=obset 07445:01. When running SPSS from the PC Tool Box, the leading zeros are not needed because they are supplied by the Tool Box software.
3. 3. Non-Standard Options Not Shown . The syntax and examples given in this document use only the standard and required commands and qualifiers. Many commands have other optional qualifiers available. For more information on the details of an SPSS command, see SPSS on-line help.
4. 4. Processing Single and Multiple Entities . Most of the commands mentioned here can be used on either an individual entity or on multiple entities. Multiple entities can be specified either as a comma separated list on the command line or via an input file that contains the list of entities to be processed.

Examples:

Single Entity: gs_request 07445:01

Command Line List: pmdb -update -type=su 0744501,0744502,0744503

File Containing IDs: pmdb -delete -type=link %delete_me.dat

5. 5. Date Formats . In all cases where dates and times are specified, SPSS uses a time string in following format: YYYY.DDD:HH:MM:SS where YYYY is the year, DDD is the day of the year, HH is the hour, MM is the minute, and SS is the second. The full precision is not required. All times are Universal Time.
6. 6. Toolbox buttons . The PC Tool Box has buttons for most of the SPSS commands that a PC would use. In each step above, the applicable PC Tool Box button has been described in addition to the applicable UNIX command line syntax.

Other Useful Tools

There are many useful tools that are available, but were not discussed in the main body of this document:

500 series proposals - Each PC will be given at least two proposals in the 500's as their personal testing area. You can check a test proposal in and process it all the way into the PMDB and not touch the operational proposal. If you forget what your test proposal's numbers are you can get a list by typing isql at a terminal prompt and then:

1> select prop_id,pc from prop_track where prop_id > 499 and prop_id < 600

2> go

date convert - This is a graphical data conversion tool which can convert between calendar date, day of year, and Julian date. To bring it up use the DATE CONVERT button in the Other Tools menu of the Toolbox.

Orbital Visibility - This is a Spike tool which is available from the Reports menu of the Spike GUI. It allows you to input an RA and Dec and a time span and gives you a daily report of visibility for that target. (This is the same report as Viewing Time under the Target Reports menu, except the target does not already have to be in a loaded proposal.)

SMS Build Status - Available through the Other menu of the Toolbox, this utility shows the status of all the calendars currently being built by the schedulers and who is the calendar supervisor.

tkdiff - This is a slick tk graphical interface to the unix diff command. Given two files to compare this utility will display them side by side highlighting the different sections one at a time.

xprint - This is a graphical printing tool and is available by typing xprint at the unix prompt, or use the Xprint button in the Other menu of the Toolbox.

wisql - This is a graphical tool for creating a customized query and can be invoked from the command line. PCs generally should be able to get what they need from the Reports menu. If you need to do a "unique" query you can use wisql, but you should use it with care because database edit features are available. If you find that you are doing the same "unique" search many times, it may be time to create a regular report for the purpose.

Appendix B: TEST SCHEDULING

Test scheduling is automatically performed on all regular, external (non-SNAP) proposals via the Schedulability tool (CALOPT sub-function). For some proposals (moving targets, difficult internals, proposal with special commanding), it may useful to create a test calendar, manually test schedule the SU(s), and review the calendar output files.

Following are the basic steps required.

$ cclist -create [-nolink] <SU ID> 

$ cclist -save <ccl_name> [-description="description of C&CList"] 

$ cadlist -addsus <SU list> [opt. param.] 

$ candlist -delsus <SU list> 

$ calendar -addcand <0ppppss> <place> [-verbose] 

"0xxxxss, path, gap, t0, t1, order" 

$ calendar -addcand 0652203 ",,,1996.125:01,1996.127,A" 

$ calendar -addcand -verbose 0672504 "0612303,,,1996.200,,A" 

$ calendar -delcand <0ppppss> 

$ calendar -fbp <0ppppss> 

$ calendar -fbc <place> 

$ calopt -interval=86400 <ccl_name> 

pw (Planning Windows): 

$ calgraph 

$ sgs 

$ cclist -delete <cclist_id> 

Appendix C: PFORM'S

          PF   NAME OF PFORM                           RELATIONS INVOLVED

          --   -------------                           ------------------

          PROPOSAL

          --------

          PCM  COMMENTS DATA                           qppcomments

          PCP  CO-PROPOSERS                            qpcoproposer

          PGD  GENERAL DATA                            qpcoproposer,qpersonnel

          SCHEDULING UNIT

          ---------------

          SCM  COMMENTS DATA                           qsucomments,qsbranching

          SCR  CONSTRAINTS & RESTRICTION OVERRIDES     qsoverrides

          SDP  BRANCHING DEFAULT PATH                  qsbranching

       -> SGD  GENERAL DATA   (gives SGD windows)      qscheduling,qsbranching

          SIU  SCIENCE INSTRUMENT USAGE                qsinstrument

          OBSET

          -----

          BCM  COMMENTS DATA                           qbcomments

          BCR  CONSTRAINTS & RESTRICTION OVERRIDES     qboverrides

       -> BGD  GENERAL DATA  (gives BGD windows)       qbs_obset

       -> BWD  WINDOWS                                 qbwindows

          ALIGNMENT

          ---------

          ACM  COMMENTS DATA                           qacomments

       -> AGD  GENERAL DATA                            qalignment

       -> AID  SCIENCE INSTRUMENT DETECTORS            qasi_states

          AOF  REUSABLE OFFSET                         qaoffset

       -> APD  POSITION DATA                           qaposition

          ARD  READOUT DATA                            qreadout

          EXPOSURE

          --------

          ECM  COMMENTS DATA                           qecomments

       -> EEL  LOGSHEET DATA                           qelogsheet

       -> EGD  GENERAL DATA                            qexposure

          EPF  PODPS FLAGS AND INDICATORS              qexposure

       -> ESP  SCIENCE INSTRUMENT NAMES AND VALUES     qesiparm

          PARALLELS

          ---------

          PAD  PARALLEL ATTACHMENT DATA                qparallel

          LINK SETS

          ---------

       -> LST  TIMING LINK SET DATA                    qslink_info, qslink_timing

       -> LSO  ORIENTATION LINK SET DATA               qslink_info, qslink_orient

          TARGET

          ------

          TCD  CHARACTERISTICS DATA                    qtargets,qalignment

          TCM  COMMENTS DATA                           qtcomments,qalignment

       -> TEF  EPHERMERIS FILES (NON-JPL)              qtephemeris

          TPS  POSITION SPECIFICATION DATA             qtargets,qalignment

          TRD  ROTATIONAL DATA                         qtargets

          TSY  SYNONYM NAMES DATA                      qtsynonyms,qalignment

          APERTURES

          ---------

          APR  SI APERTURE DATA                        qaapertures

          GUIDE STAR

          ----------

       -> GAQ  ACQUISITION CRITERIA                    qbacqs

          GPS  PAIR SELECTION DATA                     wggs_pairs

          GSA  ACQUISITION SCHEDULING DATA             wgacquis

          GSP  PARAMETERS                              wggs_pairs,wguide_stars

          GSS  PAIR SELECTION/ACQ ORDER                qbgsp_select,wggs_pairs

          GSW  OBSERVATION SET WINDOWS                 wgreswnd

          IF   NAME OF IFORM                           RELATIONS INVOLVED

          --   -------------                           ------------------

          IAC  INSTRUCTION ACTIVITY DESCRIPTION        qexposure

          *** Some keys have 2 functions:

              HIT KEY TO USE TOP COMMAND

              USE GOLD, KEY TO USE BOTTOM COMMAND

       _______________________________________

       |      |  HELP  |  RETRIEVE | CLR FLD |

       |      |        |           |         |

       | GOLD |        |  ABSOLUTE |         |  Hitting GOLD, HELP will

       |      | KEYPAD |  APPEND   | CLR FORM|  bring up this diagram on 

       |______|________|___________|_________|  your screen.

       |      |SECTION |           |         |

       |SCAN  |        |  INS CHAR | REMOVE  |

       |      | SWITCH |           |         |

       |ZOOM  |  FORM  |  INSERT   | UNREMOVE|

       |------|--------|-----------|---------|

       |      |        |           | DEL CHAR|

       |FOR-  |REVERSE |           |         |

       |WARD  |PRIOR   |  GLOBAL   | INSERT  |

       |      | APPL   |  CLR FORM | HERE    |

       |------|--------|-----------|---------|

       |      |        |  COUNT    | COMMIT  |

       | LIST |        |           | (Append |

       |FORMS |DEL EOF |  SET      | or Mod- |

       |      |        |  DEFAULT  |   ify)  |

       |---------------|-----------|         |

       |   ADVANCE LINE|  QUALIFY  |         |

       |               |           |  DELETE |

       |       EXIT    |   RESET   |         |

       |--------------------------------------

       Other useful keys:

       RETURN       Move to start of next field  

       TAB          Move to start of next field  

       BACKSPACE    Move to start of prev field  

       DELETE       Rubout a character to left   

       LINE FEED    Rubout a word to the left    

       CTRL-R       Refresh the screen           

       GOLD, TAB    Field after scrolling region 

       GOLD, BCKSP  Field before scrolling region

       ESC-F        Write to intermediate file   

       ESC-K        Numeric keypad (toggle)      

       ESC-P        Write to attached printer    

Appendix D: ISQL Standards

IMPORTANT: Only PCs who have had specific ISQL training may implement special ISQL. If you have not been trained for this, go get the training or go get help from a PC who has been trained in ISQL. It's usally a good idea to get someone else who knows isql to look over it for errors. For SMOV proposals the reviewer is the PIT team, for instrument commanding, it should be someone from the commanding group.

For the purposes of this document, the SPSS Prepping Process is defined by the following steps:

1. Load the entities into the PMDB

        pmdb -load   

2. Obset update

        pmdb -update -type=obset -ready <ppppp:oo:vv>

3. Guide star processing

        gs_request

4. Visit update

        pmdb -update -type=su -pass <sssssss:vv>

Normally, obset update is done automatically as part of gs_request. However, when special ISQL is needed, it may be necessary to run just obset update, execute the ISQL, and then proceed with gs_request.

All ISQL written will be Sybase ISQL. All files containing ISQL will have the extension .isql. The ISQL files will reside in the Trans output directory for the program ($trans_output_dir/<pppp>). File names will be constructed as follows and must be all lower case.

pppp_<step>.isql

OR:

pppp_vv_<step>.isql

where

• pppp is the integer proposal id to which ISQL applies
• vv is the visit to which the ISQL applies
• <step> is the SPSS Prepping step after which the ISQL must be run. Do not proceed on to the next prepping step until after the ISQL is executed.

<step> can have any of the following values:

• load - ISQL gets run immediately after pmdb -load and before any further prep processing.
• obset - ISQL gets run immediately after obset update and before gs_request.
• gsreq - ISQL gets run immediately after gs_request. After the ISQL is run, gs_request -acq_only MUST be run. The ISQL in this case is patching the data returned by the request step, but is used as input to the acquisition step.
• gsacq - ISQL gets run immediately after gs_request. The ISQL in this case is patching the results of the acquisition process.
• su - ISQL gets run immediately after visit update.

The program coordinator may choose to use either the single ISQL file for the program or individual ISQL files for each visit which needs ISQL.

The single program file allows ISQL to be run just once rather than once for each visit, but it may have to be edited if a subset of visits need to be reloaded later. If this happens than the ISQL for those visits should be removed from the program level file and placed into individual visit files.

If individual visit files are used from the start, the ISQL will have to be run separately for each visit, but no editing will be needed if a subset of visits need to be reloaded later.

ISQL standards:

Each ISQL file should start with a comment header delimited by the comment delimiters /* and */ at the start and end. This header should explain what the ISQL is for, when it should be run (i.e. after what step in the prepping process), the date it was written/modified and by whom.

The ISQL itself should be arranged in visit and exposure order within the file with appropriate comments interspersed. The ISQL should not contain a use statement to point at a specific database.

To execute the ISQL, use the SPSS report command. For example, to run the file 7003_load.isql:

    report -isql -db=$SPSS_DB -output=/dev/tty $trans_output_dir/7003/7003_load.isql

Here is a good example that demonstrates the above principles (the file name is 7003_load.isql).

/*

   This ISQL implements the ITS exposure and fixes a Trans problem

   Run after pmdb -load

   Written by M. Reinhart,  8-Oct-1996

   Updated by G. Chapman,  23-Dec-1996 - Add insert of FGS qesiparm.

*/

/* Visit: 03 */

/* Line: 275 */

/* Setup ITS special instructions */

update qgactinst

  set instr_name = "EFGSITS"

 where proposal_id  = "07003"

   and obset_id     = "03"

   and alignment_id = "04"

   and exposure_id  = "01"

   and version_num  = "01"

go

insert into qesiparm

        (proposal_id, obset_id, alignment_id, exposure_id, version_num,

         si_par_name,

         si_par_value)

 values ("07003","03","04","01","01",

         "FGS",

         "2")

go

/* Perform the qreadout fixups */

update qreadout

  set eng_data_fmt = "FN",

      nom_data_rat = 32,

      def_data_rat = 32,

      max_data_rat = 32

 where proposal_id  = "07003"

   and obset_id     = "03"

   and alignment_id = "04"

   and exposure_id  = ""

   and version_num  = "01"

go

Note that formatting the ISQL statements in this fashion makes for very easy writing and checking.

Some other examples of isql and the associated Phase II proposal comments are available on line.

Glossary

When appropriate, entries are followed by hot links to relevant documents and/or web pages.

AF (Assignment File) - This is the main product of Trans. There is one AF for each visit and each target and one for general proposal information. The Links AF is created by CASM in a separate process from Trans. AFs are loaded into the PMDB.

Assist Database - This database is populated from most of the fields contained in the proposals in PLIB, as well as some of the values calculated by the PP for Trans. It also contains most of the tracking information for proposals and their visits. ( Schema )

Alignment - One of the building blocks of a processed proposal, an alignment is one or more exposures taken in the same science aperture at the same telescope pointing.

BOA (Bright Object Alert) - An alert generated by the guide star system when a particular telescope pointing will place a potentially dangerously bright object in a sensitive aperture.

CASM (Constraint Analysis Spike Module) - This is the core of Spike's constraint software and has been configured separately to serve both RPS2 and Spike.

CS (Contact Scientist) - The instrument scientist assigned to support a particular proposal.

Change Checker - Part of the PP which compares the new version of a proposal to the most recent previous version looking for targets and visits which have changed. Eventually the change checker will allow automated reprocessing of only the modified portions of a proposal.

CoI (Co Investigator) - Partners of the PI; additional scientists that are part of the team for a proposal.

Confirmation Chart - A confirmation chart is an image of the sky taken from a guide star survey plate with cross hairs superimposed on the pointing specified. They are used to confirm that the specified pointing is what the PI intended. The PI generates confirmation charts in APT (except for moving target confirmation charts). For an explanation on how to generate confirmation charts in APT, please see the following ( document. )

Create - This tool is used to enter brand new proposals into both PLIB and Assist.

CV-Desc (CASM Visit Description file) - This file is created by CASM to store the suitabilities for a proposal after they have been calculated so that they can be referenced easily to review schedulability or make a long range plan.

DD (Director's Discretionary) Proposal - The STScI Director has a small percentage of the orbits that he can award outside of the TAC process. A proposal that has been approved by the Director using these orbits is call a DD proposal.

FTP (File Transfer Protocol) - This utility is available on both the Unix computers. It allows for easy transfer of files between different computers.

Galley Proof - A proposal listing and summary of changes that is sent to the PI.

GASP (GSSS Astrometric Support Program) - This software consists of functions to retrieve and process data from the guide star survey plates and the GSC. GASP can be used to measure target positions relative to the guide star coordinate system.

GO (General Observer) - A scientist who is awarded telescope time.

GSC (Guide Star Catalog) - All the guide stars used by HST are in the GSC which was constructed from several different surveys. The stars in the GSC are generally brighter than 14th magnitude.

GSSS (Guide Star Selection System ) - The software that chooses appropriate guide stars from the GSC for an observation.

GTO (Guaranteed Time Observer) - A scientist who was part of one of the instrument definition teams and has therefore earned time on the telescope.

GUI (Graphical User Interface) - Programs that you interact with graphically instead of from the command line. Examples of our GUIs (pronounced gooey) are: RPS2, PED, and the PC Toolbox.

HOPR (HST Observation Problem Report) - A HOPR provides a mechanism for observers to inform STScI when a problem has occurred with the implementation, scheduling, execution, or data processing of their observations. It is also the means by which the PI makes a request for failed observations to be repeated. ( Home Page )

IM (Instruction Management) - The commanding group maintains the spacecraft commands that proposals must be translated into.

INS (Instruments Division) - This organization is divided into groups each of which supports the calibration and data reduction for a single instrument. ( Instruments Page )

IS (Instrument Scientist) - The scientists in SSD who specialize in a particular instrument. The person responsible for the CS review since these are (in general) not done by the CS.

LRP (Long Range Plan) - The LRP is an execution plan for a large pool of Visits over a long period of time. Spike uses the CV-Desc files for the available Visits, balances the individual proposal constraints with the overall time and resources available, and comes up with plan windows for each Visit (typically 8 weeks in length).

MOSS (Moving Object Support System) - This is the hardware and software for planning moving target observations. ( Home Page )

OPR (Operations Problem Report) - OPRs are the way to formally file software problems as well as requirements for new capabilities. There is an e-mail mechanism for OPR submission ( How To ), or you can use the web interface .

OPS Tool Set- The Operational Tool Set, runs Trans, MOSS, PMDB Load, GS Request, SPIKE, Visit Update, Schedulability, and Confirm Chart.

OPUS (OSS/PODPS Unified System) - This is the group which performs many of the duties formally performed by the Observation Support System (OSS) and the Post Observation Data Processing System (PODPS). This includes routine monitoring of spacecraft telemetry, receiving data downlinked from the spacecraft and pipeline data reduction for the archive.

Obset (Observation Set) - One of the building blocks of a processed proposal, an obset is one or more alignments that can use the same guide stars.

Phase I - Phase I is the annual process of accepting and reviewing thousands of applications (called Phase I proposals) for time on the telescope. SMO coordinates all aspects of Phase I.

Phase II - If a Phase I proposal is given time by the Director (the TAC actually recommends proposals to the Director) it becomes a Phase II proposal. Technically it is still a "proposal" because it is contingent on successful construction of a feasible observing sequence (the APT file) but we interchange the words proposal and program loosely through the entire post Phase I part of the process.

PC (Program Coordinator) - This person is one of two primary contacts for a PI with a Phase II proposal. (The other is the CS.) The PC will help the PI throughout the observing program preparation process. The PC will also run the software to implement the program after it has been submitted by the PI.

PI (Principle Investigator) - The lead scientist for a proposal is called the PI.

PLIB (Proposal Library) - This is the name for the place where the proposals are stored as well as the subsystem which handles the storage and retrieval of proposals. It initiates the execution of the QM on newly entered or updated proposals.

PMDB (Proposal Management Database) - This is the database portion of SPSS. All elements of a proposal which have been loaded are stored as fields in the relations of the PMDB.( Schema )

Plan Windows - These are scheduling windows (generally up to 8 weeks from beginning to end) for scheduling a visit. They are determined by the LRP group using Spike.

RCAT - A program that retrieves entries from the GSC based on a pointing and a tolerance. (There is now an interface to this program on the web.)

SCS (Science Commanding System) - This is the software that translates the various instrument requests into actual spacecraft commands.

SMO (Science Mission Office) - This is the team that coordinates the Call for Proposals for HST, manages the TAC, informs proposers of their allocations, and reports the results to the Director and NASA.

SMS (Science Mission Specification) - A set of commands that completely specifies all visits that will be executed by the spacecraft during a period of time (generally a week).

SMSB (Science Mission and Scheduling Branch) - This is the team that is composed of the Short Term Scheduling (STS) and Long Range Planning (LRP) groups. ( SMSB Home Page , LRP Home Page )

SOGS (Science Operations Ground System) - This name is used to describe both the software and hardware of the ST ground system. The PMDB is sometimes referred to as SOGS, and the secure computer network that it runs on is called SOGS.

SPSS (Science Planning & Scheduling System) - This is the software that is used to prep a proposal in the PMDB as well as schedule proposals for flight.

SQL (Structured Query Language) - This is the language used to store and retrieve data in a Sybase database. It can be used interactively or imbedded in software. Both Assist and PMDB are Sybase databases.

SU (Scheduling Unit) - An SU (also called a visit) is a group of observations on one or more closely located targets that should be observed together. What should be observed together is determined by the PI using RPS2.

Spike - This is the software that is used to determine Visit schedulability and create and maintain the long range plan. ( Home Page )

TAC (Telescope Allocation Committee) - This is actually a bunch of different committees which meet once a year to peer review Phase I proposals and choose proposals to recommend to the Director for telescope time.

TIC (Trans Into CASM file) - This file gives the CASM module of Spike information about how Trans structured a proposal.

Toolbox - Tony Roman's graphical user interface to most of the PC tools.

Trans (Transformation) - This is the software which determines feasibility and creates the file used to populate the PMDB (the AF). There is a special mode of execution that just determines feasibility of proposals for use in APT.( Home Page , Users Manual)

USC (User Specified Constraint) - USCs provide a way to constrain when a visit can schedule without actually modifying the proposal. USCs are stored in the Assist database.

TTRB (Telescope Time Review Board) - This is a group with representatives from both INS and OED. They make recommendations to the Director's office on policy interpretations for the proposals (is this a duplication, can the PI change targets, will this failed observation be repeated).

Visit - A visit is identical to an SU (a group of observations on one or more closely located targets that should be observed together). What goes into a visit is determined by the PI using the APT software.