Figure 1: The RPS2 Control Flow.
Figure 1: PS 7 Kb
Next: The Changing Scene at NASA Headquarters
Previous: An Automated System for Receiving KPNO Proposals by Electronic Mail
Table of Contents --- Search ---
PS reprint
R. E. Douglas, Jr., R. E. Jackson1
Space Telescope Science Institute, 3700 San Martin Drive,
Baltimore, MD 21218
1Computer Sciences Corporation
The purpose of this paper is to describe the RPS2 (Remote Proposal Submission 2) system architecture that was recently used to support the Cycle 5 proposal preparation for the Hubble Space Telescope (HST). Now in its sixth year in space, the HST is still at the leading edge of astronomical research. The ground system for planning and scheduling observations has also evolved during this period. The current software used by an astronomer (PI) to specify observations for HST uses a Client/Server architecture to run the most up-to-date versions of the software systems which check the syntax, feasibility, and schedulability of his program.
In previous cycles, only a single module of what is now RPS2 was used in proposal preparation. Now there are several modules, but some of them only run under SunOS. Since not all PIs have access to this type of machines, RPS2 was created to remotely run those modules which can not be run on the PI's host machine.
The RPS2 control program consists of a Client and several Servers. The Servers are used to run software (called Services) on a machine that is capable of supporting them. Only the Client has to be made compatible across multiple platforms. The Client is written in Tcl/Tk, including the Tcl-DP, [incr Tcl], and TclX extensions, which is freely available on most UNIX platforms. Some of the Services are also written in Tcl/Tk, and these are also distributed, along with their Servers, but it is not required that they be run at the PI's site.
Figure 1 shows the flow of control over the principal components of the RPS2 architecture. There is a graphical front-end to the Client, which the PI uses to select the desired Services. The Client then contacts an appropriate remote machine's Server. The input files needed by the Service are transferred from the Client machine to the Server machine, and then the Server invokes the Service. The Service can communicate status to the Client through STDOUT, which is then passed back to the user. When the Service completes, the output files are transferred back to the Client machine. Communication between Services is through these files. Services may be run sequentially or in parallel, depending on whether or not they depend on the results of other Services.
Figure 1: The RPS2 Control Flow.
Figure 1: PS 7 Kb
The Client can contact a Server directly, or it can contact a Router to help spread out the machines that are used for Services. The Router is programmed with the knowledge of which machines are providing each Service. It then uses a random selection algorithm to pick the specific machine to provide the Service. Each Server also knows how many requests it has for Service, and this information is used by the Router's algorithm to help with load balancing.
There are currently five Services that are provided by RPS2. Each PI creates a `.prop' file, which describes his proposal for a set of observations. In this file, he describes his desired exposures. These are grouped by the PI into structures called Visits. A Visit is a group of exposures that look at a specific target. They are executed on the Telescope very closely together and in the order they appear in the proposal. Each Visit is independent, but the PI can decide to link two or more Visits by timing or orientation requirements. Visits may be flown on the Telescope in any order.
This file must first be run through a Preprocessor, which checks the syntax. Next, Validation completes the syntax check and generates input files for Transformation. The next Service to run is Transformation, which checks the feasibility of the proposal by laying the exposures down into an orbital time-line as they are likely to occur when the proposal is flown on the telescope, adding in overhead times to the exposures, and checking for legal interactions between exposures. CASM then determines the schedulability of each of the Visits during the coming year. It takes into account the constraints between Visits, the target, and many other factors. RPS2 can be configured to run CASM in parallel with Validation and Transformation, but this is not the default behavior. This is only useful when Transformation and CASM are run on different machines. The default behavior is to run all the Services on the PI's machine. After all the processing is done, the PI can call upon the Client to run the Description Generator. This is another Service, which takes the output from the other Services and reformats it. It lists any diagnostics found during proposal processing, summarizes the proposal content, and draws pictures of the orbital time-line and the schedulability of each Visit.
We have had very good results with RPS2. It was first used operationally at the beginning of cycle 5, which began January 1, 1995. Since then, it has been used to process over 300 proposals. At times, the load on the Internet caused some PIs to be frustrated with the file transfer times and connection timeout problems. Therefore, all of the Services are now available to anyone who would prefer to use his own computing power. Transformation and CASM are both large Lisp systems which are only available on SunOS 4.1.x and Solaris systems. Validation is written in C and the Preprocessor and Description Generator are written in Tcl/Tk, both of which are supported on the same platforms as the Client. Therefore, the last three Services are usually run on local machines, but Transformation and CASM are often still run at STScI. We were still able to handle the entire proposal pool with 3 dedicated server machines and with about 35 staff machines being used to handle overflow. The Router handled distributing the work load among the machines, but it only very rarely needed to use the overflow machines.
The RPS2 architecture could be used to run software on a platform which is not available to the user by creating a Server to provide the remote Service. It could also be used to provide a Service that cannot be distributed for other reasons to the users. Using the object system provided by [incr Tcl], Servers are instances of a generic Server class and Services are described to the control program by instances of a generic Service class, which makes it very easy to add new services. It is planned that additional Services will be offered by STScI, e.g., Guide Star availability checking using the GASP system, which is only available at STScI.
There are also extensions to be done in the Router. It currently uses a random ordering of machines in the list, and then tests each machine for its load to determine which machine should be used. This provides suboptimal load-balancing, but is quick and works in most cases. A more sophisticated algorithm could be necessary for a different application.
We would like to acknowledge the hard work and dedication of the entire RPS2 development team.
Durkin, M. P., et al. 1994, ``RPS2 System Architecture'', APSB Technical Report
Douglas, R. & Rose, M. 1994, ``Design for the RPS2 Control System'', APSB Technical Report
Jackson, R. , Johnston, M., et al. 1988, Goddard Conference on Space Applications of Artificial Intelligence, (Greenbelt: NASA), 107
McLennan, M. J. 1993, Tcl Workshop
Miller, G., & Johnston, M. D. 1991, American Institute of Aeronautics and Astronautics, 1
Osterhout, J. K. 1994, Tcl and the Tk Toolkit, (New York: Addison-Wesley)