CASM (Constraint Analysis Spike Module) - This is the core of STScI's Spike constraint software 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 - This is the brain of the Control System that determines the order in which services are run and starts them at the appropriate time.
CS (Control System) - This is the subsystem that facilitates the communication among the other pieces of the RPS2 software system. It includes 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) - This is the subsystem that combines the output (descriptive and diagnostic) of the other RPS2 subsystems (PP, Trans, and CASM) into a set of reports that are easy to read and informative. There are two types of reports: the proposal summary and visit analysis reports.
Diagnostics - This is a generic name for the error, warning, and informational messages that the subsystems produce.
Dispatcher - Thiss is part of the Controller which communicates between the client and a server.
Orbit - This is the 96 minute HST orbit around the Earth. Do not confuse this with the " visibility period " which usually is the ~50 minute usable portion of an orbit where the target is not occulted by the Earth.
PC (Program Coordinator) - The primary STScI contact for the PI. The PC will help the PI throughout the observing program preparation process. He or she will also process the program for scheduling on HST after it has been submitted to STScI.
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 - This is one of the DG product reports that 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 - This is the part 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 - This is the file that contains a Phase II proposal, hopefully in the proper "visit based" syntax. The naming convention is <#>.prop where <#> is the proposal ID number.
RPS2 system - This is the proposal preparation software package that helps 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 its allocated orbits.
Server - This is another part of the Control System that serves as a "wrapper" to allow the other subsystems (e.g., 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 - This is the generic name for any of the subsystems (e.g., Trans or CASM) which is run remotely by the Control System.
Spike - This is the STScI software that determines the schedulability of an observation and helps STScI develop a long range plan of observations on-board HST.
Trans - This is the STScI software (and a subsystem in RPS2) that determines the feasibility of a proposal. The files it generates are used to populate the STScI operational database, which in turn are used when preparing and scheduling visits for execution on HST.
UI (User Interface) - This subsystem allows the user to talk to 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 - This is a group of exposures that should be observed together. If a visit has more than one target, they should be located close together. The observer using the RPS2 determines what exposures go into each visit of their proposal.
Visit Analysis Report - From the output of other RPS2 subsystems, the DG assembles an analysis report for each visit. It contains a summary of the visit -- exposure by exposure -- its Feasibility, Schedulability, and any diagnostics.
PED, editing Data Distribution 35
PED, editing proposal information 31
PED, general information for all screens 28
Processing, reviewing the output 16
RPS2, accuracy and limitations 5
RPS2, possible configurations 8
RPS2, retrieving the software 10
RPS2, running remotely from xwindows 38
RPS2, running the command line version 38
Scheduling, in visit analysis report 21
Servers, bringing then up and down 13
Servers, shutting down from the command line 40
Servers, starting from the command line 40
| Abstract and Table of Contents | Previous Section |