CASM (Constraint Analysis Spike Module) - The core of STScI's Spike constraint software that has been configured separately to serve both RPS2 and Spike. Input files come from the PP and Trans. Output files contain information on the schedulability of each visit and are passed to the DG.
Controller - The brain of the Control System which determines the order in which services are run and starts them at the appropriate time.
Control System - The subsystem which facilitates the communication between the separate pieces that make up the RPS2 software system. It is composed of the Controller, the Dispatcher, the Router, and the Server wrappers for each service. The user interacts with the Control System via the User Interface.
DG (Description Generator) - The software which combines the output (descriptive and diagnostic) of the other RPS2 subsystems (PP, Validation, Trans, and CASM) into a set of reports that are easy to read, informative and not redundant. There are two types of reports: the proposal summary and visit analysis reports.
diagnostics - A generic name for the error, warning, and informational messages that the subsystems produce.
Dispatcher - A part of the Controller which communicates between the client and a server.
Orbit - The 96 minute HST orbit around the Earth. Do not confuse it with visibility which is the ~50 minute usable portion of an orbit (the part where the target is not occulted by the Earth).
PC (Program Coordinator) - The primary contact for the PI with STScI. 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.
PED (Proposal Editor) - This is the graphical editor for writing and editing HST Phase II proposals.
PP (Preprocessor) - This subsystem checks the syntax (and reports diagnostics to the DG) and then converts the RPS2 file into the files needed for Trans and CASM.
Proposal Summary Report - One of the end product reports from the DG. It summarizes the proposal visit by visit. It includes the target name, instrument and mode, number of orbits used, and diagnostic status. It also includes proposal-level syntax diagnostics, general proposal-level information, and a scheduling summary.
Router - The piece of the Control System that chooses which Server to use for a particular process. (If there are two computers running the CASM Server then it will choose which one to use.)
RPS2 file - File for specifying a Phase II proposal using the visit based syntax. The naming convention is <#>.prop where <#> is the proposal ID number.
RPS2 system - The proposal preparation software package which enables an HST observer to write and submit a Phase II proposal which is not only syntactically correct, but also feasible, schedulable, and makes optimal use of allocated orbits.
Server - A component of the Control System which serves as a "wrapper" to allow the other subsystems (like Trans, and CASM) to be run remotely without modification. There will be servers for each subsystem running at STScI. The server software for a subsystem must be running on a machine in order for that machine to be used for processing by that subsystem.
Service - The generic name for any of the subsystems (like Trans, or CASM) which is run remotely by the Control System.
Spike - The name for the STScI software that is used to determine schedulability and develop a long range plan of observations.
Trans - The name of the STScI software which determines feasibility and prepares the proposal to be executed on HST.
User Interface (UI) - The subsystem which allows the user to interact with the Control System. In addition to processing a proposal, the UI can be used to start the DG, start PED, and submit a proposal to STScI.
Visit - A group of observations of one or more closely located targets that should be observed together. Which exposures go into each visit will be determined by the observer using the RPS2 software.
Visit Analysis Report - One of the end product reports from the DG. There is one such report for each visit. It contains a summary of the visit by observation, Feasibility, Schedulability, and any diagnostics which are all presented in one report. This information is collected by the DG from the output of the other subsystems and compiled into a single report for each visit.