Space Telescope Science Institute, Baltimore, MD 21218.
The Space Telescope Science Institute (STScI) has developed a new tool for the preparation of an observing program with NASA's Hubble Space Telescope (HST). This tool, called the Remote Proposal System Generation 2 (RPS2), provides the astronomical user with immediate feedback on important aspects of the observing program such as fundamental observing constraints and the detailed structure of the observations, allowing the user to detect errors and make informed trade-offs in observing plans. RPS2 was developed by "gluing" together several existing systems that are used in the day-to-day operations of the HST, and adding new components where necessary.
Unfortunately, submitting a Phase II proposal requires extremely detailed knowledge of HST and its capabilities. Observers need to understand what its instruments can and cannot do, and even how much time their internal mechanisms require. Specifying constraints such as observing windows and spacecraft orientation limits requires knowledge of when a given observation can and cannot schedule, which can only be derived from complex combinations of interacting restrictions. How could STScI provide observers access to this intricate technical knowledge without overwhelming them? This question lead to the development of RPS2.
Astronomers who have access to suitable computer equipment will prepare their proposals using the Remote Proposal System Generation 2 (RPS2). RPS2 is a new, distributed software system that was designed with the following goals in mind: 1. Help the user prepare proposals that are as free of potential problems as possible. 2. Give the user instant feedback on a) how observations are going to be altered due to science, engineering, or orbit-packing considerations, b) what scheduling constraints exist. 3. Simplify proposal preparation and processing by making observations "visit-based", where observations within a visit can be scheduled together as a unit. In order to achieve these goals, and to have the system ready under stringent time constraints, RPS2 was designed and implemented to make full use of pre-existing software systems that are used for proposal processing after submission to STScI. This also ensures that the users get information that is as close to the "real-thing" as possible. However, in order to make RPS2 easy-to-use, to provide a glue to integrate existing systems, and make its output products succinct, informative, and readily comprehensible, several new components had to be added "on top" of the existing systems.
.
Before RPS2, STScI provided astronomers with software called the Remote Proposal Submission System (RPSS). RPSS only checked the proposal for some syntax errors. The proposal was submitted to STScI, which used other in-house software systems to check the complete syntax, feasibility, and schedulability of proposals. Two important in-house systems are for Proposal Transformation (called TRANS [3]) and Long Range Planning and Schedulability Analysis (called Spike [6]). TRANS is used to obtain detailed observing plans from a proposal and analyze its feasibility. SPIKE is used to obtain long range estimates of HST schedules and analyze a proposal's schedulability.
STScI distributed hundreds of pages of instructions and Instrument Handbooks to give obervers the information they needed. Inspite (or perhaps because of) this voluminous documentation, problems with the contents of the proposal would often be detected when the proposal was received. For example, observations may have been laid out in such a manner that the data being read to tape would exceed the data-rate limit of the tape-recorder. Three other problems cropped up repeatedly:
To make proposal submission and processing more efficient, and to let astronomers have insight into how their proposals are processed in-house (which helps them better craft their proposals), a new software system, called RPS2 (Remote Proposal System - Generation 2), has been implemented. We gave RPS2 an easy-to-use graphical interface and made it portable enough to distribute to user's sites. It provides the user with instant feedback on various facets of their proposal, including syntax errors, details on the durations of observations and how much of the available target visibility they use up in each orbit, potential problems with the way certain observations are set up (called feasibility analysis), and the schedulability of each visit (called schedulability analysis). Client-server technology allows some of the more complex processes to be run at STScI for observers with insufficient computing resources.
RPS2 provides benefits to both the astronomers in preparing their proposals and to STScI in processing these proposals after submission. The easy-to-use interface with on-line help allows first timers to use the system correctly. Feasibility and schedulability analysis help in the early detection of potential problems, which can now be rectified before submitting, whereas before RPS2, these errors were detected much later in the processing (Figure 1). Explanations available with the diagnostics help users understand the exact nature of problems and provide suggestions on how to fix them. RPS2 allows proposers to divide their observations into independent "visits". This eliminates the division of observations into scheduling units which had been a source of confusion for observers. A graphical report lays out observations and overheads among target visibility windows, taking the guesswork out of crafting observations for efficient spacecraft use.
Figure 1: Proposal Submission Before and after RPS2
RPS2 can be used in either the graphical mode or the command-line mode. The graphical mode is much friendlier, so is recommended for users with access to the appropriate equipment (an X-windows display).
Figure 2: The Beginning RPS2 GUI Window
A proposal is chosen using the Select button. A listbox containing the names of all proposals with the valid extension comes up (Figure 3).
Figure 3: The Select Box to Enable Selection of a Proposal File
Once a proposal has been selected, processing can be started by clicking on the Process button. Multiple proposals may be processed by selecting and processing each one of them. When processing starts on a proposal, a bar comes up to indicate progress. This bar disappears when processing is complete. In Figure 4, we show two proposals (311 and 362) being processed at the same time.
Figure 4: Processing Bars Indicating Extent of Proposal Processing
The results of processing for a proposal can be viewed at any time after processing has started. Interactive viewing with point and click help facilities is selected by clicking on the Display Output button. Clicking on the Write PS Files button generates postscript files of the output. In the first case, when the reports are viewed with the Display Output option, the start-up screen obtained is shown in Figure 5. There are two reports that can be viewed. These are the Proposal Summary Report and the Visit Analysis Report.
Figure 5: The Start-up Screen for the DG
Figure 6: An Example of a Proposal Summary Report
The Help panels on the side are mouse-click sensitive, and when activated provide a description of the appropriate section of the report. For example, clicking on the Help panel adjacent to the Summary section results in the following window being displayed (Figure 7):
Figure 7: The Help WIndow for the Summary Section of the Proposal Summary Report
At the bottom of the Proposal Summary Report are the proposal-level diagnostics. Explanations are available for each diagnostic, and can be obtained by clicking anywhere on a diagnostic. An example of a diagnostic explanation is shown in Figure 8.
Figure 8: The Diagnostic Explanation for a Diagnostic from the Proposal Summary Report
Some other options available include:
Figure 9: An Example of a Visit Analysis Report
RPS2 comprises of several components that are shown in Figure 10. These components are: the User Interface, Controller and Router [4], Preprocessor [1], Validation [5], Transformation [3], Constraint Analysis and Spike Module [10], and the Description Generator [2]. Each of these components will be described in turn.
Figure 10: The major components of RPS2 and the data-flow among them
There are three main phases involved in processing the proposal, namely syntax checking, feasibility analysis, and schedulability analysis. It is not necessary to run all phases of RPS2 at the same time on a proposal. This feature is especially useful when processing long proposals for which running all of RPS2 would be time consuming. For example, the syntax problems could be ironed out before running the feasibility and schedulability portions.
It is possible to view the results of processing at any time from the GUI. When the appropriate option is selected, the GUI invokes the Description Generator (DG) that is responsible for presenting the results of processing in the form of succinct, easy-to-read, and interactive graphical reports. Hard copies of these reports can also be obtained by requesting postscript versions of the reports, and then printing them out on a postscript printer. Once the user is satisfied with the RPS2 reports on the proposal, he/she can mail it electronically to STScI.
The command-line version of RPS2 enables users who do not have access to an X-terminal to be able to run RPS2.
Most point-and-click functionalities of the GUI are provided through command-line options.
The Controller determines what RPS2 systems are to be run based on the RPS2 phases activated by the user. For example, if the user is interested only in syntax checking, the Controller determines that only the Preprocessor and Validation need to be run. For each system that needs to be run, the Router determines the location where it can be run. It does this through pre-encoded tables with information on the sites each system is available at. Each system is run through its server. A server is capable of handling multiple requests to run a system.
Validation (VAL) is the component of the original RPS system which checked syntax errors. In developing RPS2 we were faced with the prospects of either substantially enhancing the original validation system to catch new types of problems or re-writing it entirely. A hybrid approach was adopted instead. VAL is still used to perform syntax checking and generating data files for TRANS. Any new checking is performed by the PP. As the system matures, the PP will take over all the syntax checking and data file creation and VAL will be removed.
Different implementation languages have been used for different parts of RPS2. This is partly because some of the components involved, namely VAL, TRANS, CASM, were developed at different times over the last ten years and were originally designed as stand-alone components for specific tasks at STScI. The challenge in designing and implementing RPS2, was to come up with a scheme that would allow us to use these components, and add to their functionalities in a short time-span of approximately four months. There were three main functions to be added: 1) A convenient way for users to provide input, 2) a convenient way for users to obtain the desired reports, and 3) a "glue" to integrate the existing components into one system. [incr]Tcl/Tk [7], an object-oriented extension of Tcl/Tk[9], provided us with not only an object-oriented command language and shell from which to run the various components and integrate them together, but also a toolkit to develop graphics-based components for input and output. Hence, the new components (the GUI, Controller, PP, and DG) are all implemented in [incr]Tcl/Tk. The feasibility and schedulability tools (TRANS and CASM), which both use Artificial Intelligence techniques to do their processing, are implemented in LISP [11]. VAL was initially developed in 1984 and at that time, C was chosen as the implementation language since it provided necessary data structures and portability.
Several enhancements have been planned for the next version of RPS2. Work on an integrated, and perhaps semi-intelligent editor to enable the astronomers to create their proposal files from within RPS2 is planned to commence in March 1995. The PP will also be enhanced to take on all the syntax checking, some of which is currently performed by VAL. Enhancements are also planned for the output reports which will be partially redesigned to include more information, requiring changes in the DG.
There were several STScI staff involved with the design and implementation of RPS2. Some of their names are listed in Figure 11, which is part of the "About RPS2" screen.
Figure 11: The RPS2 "About" Screen