2. How RPS2 Works

2.1 The Components of RPS2

The RPS2 system consists of six pieces of software held together by a seventh.

1. The User Interface (UI) is the front door to RPS2. Through it you can edit your proposal, process it and check for errors, display it and see how it schedules on the telescope, and submit it to STScI.

2. The Proposal Editor (PED) is a simple-to-use, graphical editor designed to help you write error-free proposals.

3. The Preprocessor (PP) checks for errors in your proposal and creates files used by other subsystems.

4. Transformation (Trans) takes the information generated by the PP and constructs a detailed plan for executing your proposal on HST.

5. The Constraint Analysis Spike Module (CASM) checks to see if and when your observations can be scheduled on HST.

6. The Description Generator (DG) collates the descriptions and diagnostics from the PP, Trans and CASM subsystems, and can display them as either on-screen or PostScript graphical reports.

7. The Control System (CS) handles communication among the other pieces of RPS2 and determines the order of processing.

To make RPS2 mirror actual scheduling on HST, its subsystems use much of the same software as STScI does to prepare a proposal for flight. When RPS2 processes a proposal, up to three subsystems can be used: PP, Trans, and CASM.

· The PP performs syntax checking and feeds information to Trans and CASM. PP is called the Syntax subsystem. (Note: The Proposal Editor uses the same syntax checking as the PP.)
· Trans takes input from the PP and calculates how much time each exposure will take (including spacecraft and instrument overhead times) and how the target visibility periods will be filled. Trans is called the Feasibility subsystem.
· CASM takes input from the PP (target information, requested special requirements, and so on) and Trans, and then calculates when each constraint can be met during the upcoming cycle. CASM is the heart of the Spike system, used for long range planning at STScI. CASM is called the Schedulability subsystem.

2.2 Possible Configurations

Precompiled binaries of RPS2 are available for several different unix platforms and configurations (see Available Configurations). For instructions on installing one of these configurations, see Installing RPS2

Available Configurations

Computer	OS	Full Configuration	Smaller Configuration
Sun	SunOS 4.x	not available	sun4-RPS2bin.tar.Z
Sun	Solaris 2.x	solaris-RPS2bin.tar.Z	available on request
DEC Alpha	Digital Unix	not available	alpha-RPS2bin.tar.Z
SGI	IRIX	not available	available on request
HP	HP/UX	not available	available on request

The Full Configuration ( solaris-RPS2bin.tar.Z for Solaris 2.x):

· This is the recommended configuration. It includes all of RPS2's subsystems and allows you to run all of RPS2 on your machine. It requires more disk space and is more computationally intensive when RPS2 is running (compared to the smaller configuration).
· After unpacking the code, it uses about 66 MB of disk space; after the archive file is deleted, it uses 47 MB. While the Feasibility and Schedulability program images are large, they can run on a Sparc IPX with 16MB of physical memory and 84MB of swap space.

The Smaller Configuration ( sun4-RPS2bin.ta for SunOS 4.x, alpha-RPS2bin.ta for DEC Alpha, otherwise available on request):

· This configuration includes the User Interface (UI), PreProcessor (PP), and Description Generator) DG subsystems, all of which will run locally. It does not include the Feasibility and Schedulability subsystems, which will run remotely on the STScI machines.
· In this configuration the Control System (CS) handles communications between the local and remote subsystems via the Internet. Consequently, there will be times when heavy network traffic will cause slow processing time.
· You need approximately 17 MB of disk space in order to retrieve and unpack this configuration of RPS2. After installation is complete, the archive file can be deleted, leaving only about 713MB on your disk.

In principle you should be able to run the smaller configuration of RPS2 on any unix system to which tcl/tk/tcl-dp/itcl has been ported. The source code for the smaller configuration is available, so if you would like to try compiling it on your own system, please contact your PC, who will put you in touch with the RPS2 development team.

At this time, the RPS2 software is available only as precompiled binaries on the platforms listed in Table 1. If you do not have one of these platforms, you can run RPS2 by one of the alternative methods described in Summary of Alternatives.

2.3 Client-server Systems

RPS2 is a client-server system. The user interacts with a "client" program which in turn communicates with one or more "server" programs. A server program can be on a local machine or on any machine accessible via the Internet. In RPS2 there are four separate servers. All four servers (PP, Trans, CASM and DG) are running at STScI and can be accessed through the Internet. In the full configuration of RPS2, all servers can be run locally on your computer. In the smaller configuration, only the PP and DG are run on your machine.

If the servers are not run locally, RPS2 will automatically access the servers at STScI. In addition to slower run times and potential network connection problems, there is a potential security risk. If the local servers are not started, the xhost command will need to be issued to allow a server at STScI to display windows to your screen. This allows access to your machine from outside. You should check with your system manager to see if this is acceptable for your institution.

2.3.1 Mix and Match Servers

When RPS2 is started, it attempts to bring up all the servers in your installed configuration. If the servers are already up, nothing happens. The servers will stay up until they are explicitly brought down or the system on which they are running is rebooted. (This should not be a problem; servers consume minimal resources when they are not being used.) Switches are available for controlling whether the servers come up automatically (See Configuring the Servers and Bringing Them Up and Down).

Servers started on one workstation can be accessed by people running RPS2 on a different workstation through the Internet. If you are running RPS2 on a different machine from the one on which RPS2 servers are running, you will have to execute the command:

xhost +<servername>

where <servername> is the name of the machine on which the RPS2 servers are running. This allows the machine running the servers to display XWindows on your machine. As mentioned earlier, this can pose a security risk.

Using these capabilities you can mix and match servers to optimize RPS2 for your situation. For example, after installing the full configuration, you find that running all the servers on your machine slows it down considerably. You may wish to turn off the Feasibility and Schedulability servers and change the default so they do not come up when you start RPS2.

Instructions on setting these preferences is in Configuring Your RPS2 Options. If you require any assistance deciding which options are best for your system, contact your PC.