RPS2 is composed of six pieces of software held together by a seventh. In order to make the results of processing a proposal with RPS2 reasonably mirror what can actually occur on the spacecraft, the subsystems of RPS2 use much of the software used at STScI to prepare a proposal for flight. You do not have to be too concerned with the details, but a brief overview will allow you to take advantage of shortcuts and reduce processing time.
The pieces of RPS2 are the User Interface (UI), Proposal Editor (PED), Preprocessor (PP), Transformation (Trans), Constraint Analysis Spike Module (CASM), Description Generator (DG), and the Control system. The UI handles requests from the user. The Control system handles all communication among the other pieces.
When a proposal is processed, up to three subsystems are run (PP, Trans, and CASM). The PP handles syntax checking and feeds information to the other two subsystems. 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. CASM takes input from the PP (target information, requested special requirements, etc.) 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. The DG can collate the descriptions and diagnostics from these subsystems into either on-screen or PostScript graphical reports.
Within the RPS2 system, PP is called the Syntax subsystem, Trans is called the Feasibility subsystem, and CASM is called the Schedulability subsystem.
The syntax checking performed in the proposal editor (PED) is identical to that in the PP..
RPS2 is now supported with precompiled binaries on several unix platforms. (See table on next page.) The recommended full configuration includes all the subsystems and allows you to run all of RPS2 on your machine. The smaller configuration runs only the UI, PP, and DG subsystems locally, and the other subsystems run at STScI. If the smaller configuration is chosen, the Control system will handle communications between these subsystems via the Internet. Options for people who do not have one of these platforms are listed in See Alternate Ways to Run RPS2
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 Internet. In RPS2, there are four separate servers. All four servers 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 the DG are run on your machine.
If the servers are not run locally, RPS2 will automatically access the servers at STScI. In addition to generally 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 will allow access to your machine from outside. You should check with your system manager to see if this is acceptable for your institution.
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 See Bring the servers 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:
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 above, this can pose a security risk.
Using these capabilities you can mix and match servers to optimize RPS2 for your situation. Here are two examples:
Documentation for setting all these preferences appears in See How to configure RPS2 options If you require any assistance in deciding which options are best for your system, contact your PC.