Moving Targets Report

Moving Target Support in APT

Moving Targets Working Group

Rusty Whitman, Andy Lubenow, Tony Roman

Revision 1 - August 15, 2001

Introduction

The Moving Targets Working Group has completed an analysis of requirements for moving target support in APT. This paper presents the system level requirements and use cases for supporting moving targets in APT. The requirements for moving targets are aimed at providing users with improved response in the generation of ephemeris and target window information, and finder charts. Also presented are the results of a survey of PIs with Cycle 10 moving targets proposals, a proposed approach for an interface to Percy, an outline of a prototype client-server system, a list of identified risks and concerns, and recommendations.

Please note that none of the requirements presented here are in the current scope of the APT effort. The purpose of this study was to identify desired features and functions for moving target support in APT and to provide an estimate for implementing that support. Based on this information a determination may be made whether or not to add moving targets to APT.

Current RPS2 Process

RPS2 has no capability for determining targeting information for targets that are not Level 1 bodies and has no capability to determine timing information for any moving target. When the user submits a proposal, TRANS extracts the user-supplied information in the Solar System Target List and creates a Percy script file. This script file is manually run through Percy by a PC in order to generate the ephemeredes and window files for the targets. If there are scheduling problems associated with the targets the window files are emailed back to the user. The user places these files into the appropriate directory and re-runs RPS2 in order to obtain a schedulability report that includes their moving target constraints. This iteration between the user and the PC can take several cycles and many days.

Moving Target Requirements

An implicit requirement for the moving target support in APT is the use of an appropriate existing tool for the generation of ephemeris information. The tool chosen for consideration here is Percy (the executable portion of MOSS). Two other applications capable of providing ephemeris information were investigated, however neither provided the level of support required by both internal and external users for HST planning that is available in Percy. The JPL Horizon system and PDS Planetary Rings Node at Ames provide some, but not all, of the functionality of Percy. The Planetary Rings Node provides a web interface for obtaining ephemeris information and generating simple plots. Horizon provides ephemeris information but no graphical output. The interface to the Horizon system is through telnet, email, or a web page with the web page providing only a subset of the full complement of functions.

The proposed Moving Targets requirements listed below are taken from the draft APT System Requirements Document and were originally described in the document “Draft Requirements for handling Solar System Targets with APT”. The outline level of the requirements document has been maintained here for reference purposes.

Requirements from the APT System Requirements Document:

2.2.7 Moving Targets Tool (MTT)

The MTT provides the APT user with an interface to Percy, a program that provides ephemeris and geometrical event information about solar system objects.

2.2.7.1 The MTT shall support the conversion of proposal items in the Solar System Target List (SSTL) to a Percy input script.

2.2.7.1.1 The Percy input script shall be constructed as defined in the Trans Requirements Document Appendix J.

2.2.7.1.2 The MTT shall support the transmission of a Percy input script to Percy for execution.

2.2.7.2 The user shall be provided with the capability to specify the values for certain MTT parameters.

2.2.7.2.1 The user shall have the option of specifying the value for the BOUNDS parameter, the time bounds over which the Percy computations are to occur.

2.2.7.2.1.1 The default MTT value for the time bounds shall be from the beginning of the observing cycle for a proposal to the end of the observing cycle plus 3 months.

2.2.7.3 The MTT shall receive ephemeris and window files from Percy resulting from the execution of a Percy input script.

2.2.7.3.1 Ephemeris data from Percy shall be provided in the form of heliocentric tracking files (.trh files).

2.2.7.3.2 The MTT shall make Percy generated ephemeris and window files available for use by the APT Toolset.

2.2.7.4 Proposal items shall be checked for correct spelling and syntax before conversion to a Percy input format.

2.2.7.5 The MTT shall provide the user with the capability to display Percy window (.wnd) files.

2.2.7.6 Basic ephemerides for Level-1 bodies shall be made available for distribution with the APT.

2.2.7.6.1 Ephemeris data for Venus shall be provided.

2.2.7.6.2 Ephemeris data for Mars shall be provided.

2.2.7.6.3 Ephemeris data for Jupiter shall be provided.

2.2.7.6.4 Ephemeris data for Saturn shall be provided.

2.2.7.6.5 Ephemeris data for Uranus shall be provided.

2.2.7.6.6 Ephemeris data for Neptune shall be provided.

2.2.7.6.7 Ephemeris data for Pluto shall be provided.

2.2.7.6.8 The Level-1 bodies ephemeris files shall be provided as heliocentric tracking files (.trh files).

2.2.7.7 The system shall support the capability to process user-supplied ephemeris files of the supported types.

2.2.7.8 The system shall support the capability to process user-supplied target-local window files.

2.2.7.9 The system shall support the capability to process user-supplied orbital elements.

2.2.7.9.1 The system shall generate a coordinates report for each target with user-supplied orbital elements.

2.2.7.10 The system shall provide the capability to generate finder charts for a user specified time and selected SSTL targets.

2.2.7.10.1 The system shall provide the capability to display finder charts.

Survey Results

A survey was emailed to the dozen Cycle 10 GO and SNAP moving target proposers to solicit comments on the current RPS2 support for moving targets and suggestions for improvements that could be incorporated into APT. Three responses were received in time to be included in this report. Four questions were provided as a guideline in answering the survey. These questions and a summary of the responses appear in the table below.

Question	Summary of Responses
What aspects of the current proposal preparation process do you find difficult with regards to defining moving target observations?	The current proposal preparation process was difficult to use for our purposes.
	Determining slit orientation, and its variations w.r.t. target body north as a function of time, was tricky and time-consuming. I also needed to determine how close a slit on Io could get to Jupiter, to assess bright-object protection requirements for STIS, and had to resort to paper, pencil, and ruler to do this.
What kinds of tools would be useful to you in the preparation of your moving target observations?	· Generate an object ephemeris for the entire year. · Plot the position of the object for a range of dates. · Ability to estimate ephemeris uncertainties.
	Preview graphics showing slit or other aperture positioning with respect to both the target body and other nearby objects, as a function of date, with dates constrained to those that meet the other requirements specified for the observation.
Do you use the STScI Percy application (also known as MOSS) or some other application for planning your observations?	We did not use MOSS because it seemed quite difficult to obtain and install, and from the descriptions on the web it was not clear that it would be able to perform the functions we needed.
	No, left up to the SC and PC.
	No- I wrote some IDL code of my own, and also used the graphical ephemerides at the PDS Planetary Rings Node at Ames Research Center
If you make use of graphical displays of your target, what information do you like to see in a graphical display?	Ability to plot our object's position on the sky for a range of dates and to plot all nearby bright stars to check for contamination.
	Albedo maps of surface markings would be great but probably too much to ask. Would settle for lat/lon grids, terminator, rings, any other shadows.

One thing clear from the survey responses is that most users are unfamiliar with the capabilities of Percy. This appears to be due to a lack of information on the Percy web page and the difficulties imposed on the user in obtaining a copy of Percy for use.

Moving Targets Tool Use Cases

The MTT is envisioned as being a supporting tool that would be invoked from within other APT tools. The use cases presented below illustrate some of the scenarios for use of the MTT in conjunction with the APT Visit Planner.

UC – MTT.1

Title:	PI Runs Proposal Through MTT
Actors:	PI, Percy
Precondition:	Phase 2 Program File with SSTL loaded into APT Orbit structure defined
Trigger:	PI enables MTT from the Visit Planner
Success End Condition:	PI views Percy output files
Failure End Condition:	Percy is unable to process request
Information exchanged:	- PI selects proposal for processing - APT provides status on MTT processing - APT provides Percy output products
Description of steps:	- PI selects proposal and starts the Visit Planner - PI enables MTT processing - PI initiates processing of proposal - APT creates Percy script from SSTL in proposal - APT sends Percy script to Percy for processing - APT provides progress and status information to PI - APT receives Percy output products (.trh, .wnd) - PI reviews Percy output products
Optional Situations:	None

UC – MTT.2

Title:	PI Supplies Orbital Elements
Actors:	PI, Percy
Precondition:	Phase 2 Program File loaded into APT
Trigger:	PI selects MTT tool
Success End Condition:	PI views Percy output files
Failure End Condition:	Percy is unable to process request
Information exchanged:	- PI selects proposal for MTT processing - PI supplied orbital elements - APT provides status on MTT processing - APT provides Percy output products
Description of steps:	- PI selects proposal for processing - PI enters orbital elements through spreadsheet - PI initiates MTT processing - APT creates Percy script from SSTL in proposal - APT sends Percy script to Percy for processing - APT provides progress and status information to PI - APT receives Percy output products (.trh, .wnd) including ephemeris file generated from PI supplied orbital elements - PI reviews Percy output products (including coordinates report)
Optional Situations:	None

UC – MTT.3

Title:	PI Requests Finder Charts
Actors:	PI, Percy
Precondition:	Phase 2 Program File loaded into APT
Trigger:	PI selects MTT tool
Success End Condition:	PI views Percy output files
Failure End Condition:	Percy is unable to process request
Information exchanged:	- PI selects proposal for MTT processing - PI selects visit - PI selects date and time - APT provides Percy output products
Description of steps:	- PI selects proposal for processing - PI selects visit - PI selects option to generate finder charts - PI initiates MTT processing - APT creates Percy script from selected visit in proposal for specified date and time - APT sends Percy script to Percy for processing - APT provides progress and status information to PI - APT receives finder charts for each exposure - PI reviews plots
Optional Situations:	None

UC – VPT.1

Title:	PI Checks Schedulability of Visit Containing Moving Targets
Actors:	PI, Percy
Precondition:	Phase 2 Program File loaded into APT
Trigger:	PI selects VPT tool
Success End Condition:	PI views schedule information
Failure End Condition:	Unable to produce schedule information
Information exchanged:	- PI specifies proposal for VPT processing - PI receives schedule information
Description of steps:	- PI selects proposal for processing and initiates VPT processing - APT checks to see if moving target information must be updated, if yes then generate new ephemeris and window files. - Check schedulability using ephemeris and window files - APT displays schedulability information - PI reviews schedule information, iterates as needed.
Optional Situations:	None

Proposed Approach for APT-Percy Integration

Those functions not provided directly by the APT are implemented through interfaces with servers. APT currently implements interfaces with a number of different systems that provide support services such as catalog lookup (NED, SIMBAD, GSC), image download (NED, DSS), and in later releases, with services directly related to proposal processing (Transverse and Spike). The APT-Percy integration will continue this client-server relationship.

At a minimum, a version of Percy hosted on an STScI system must be available to service requests from APT clients. In addition, Percy could be included with the APT distribution and run directly at the user site for those users with the required system configuration.

Three approaches to the implementation of a client-server interface with Percy have been considered. These are summarized in the table below and depicted in figures 1 and 2.

Server Type	Description	Pros	Cons
Multi-threaded server	Serves multiple concurrent users with single application.	Reduced resource overhead	Requires massive re-write of Percy.
Singly-threaded server	Serves one user at a time with single application	Reduced resource overhead	Requires substantial modifications to Percy. For STScI server, single queue means potentially a long wait if multiple concurrent users.
Server front-end controls multiple application sessions	Serves multiple concurrent users each with their own copy of the application	Only minor modifications to Percy required. Simple implementation Follows the current method for remote Trans and Spike access.	For STScI server, resource usage scales linearly with each concurrent user.

Running Percy as a server removes the overhead associated with Percy initialization and would improve the response time, however the modification of Percy to run as a server will likely involve major architectural changes to Percy. Percy was designed as a single user system and is written almost entirely in Fortran 77. Even with a complete rewrite, interactive response times are, for all practical purposes, unattainable due to the nature of the computations performed by Percy. While in most cases the computations performed by Percy should complete in tens of seconds, it is possible for a user to ask for data that will take hours to compute.

Since it is unlikely that there will be more than a couple of concurrent Percy users (moving targets make up a small percentage of STScI proposals) the third approach offers a viable path. The modifications required to Percy are limited and consist of the following:

1. Support for PNG format graphics output (or possibly a format compatible with a Visual Target Tuner overlay)

2. Provide progress information to front-end in a usable form

3. Provide better error management (e.g. provide warnings and continue processing where possible rather than throwing a fatal error and stopping)

4. Provide error and status information to front-end in a usable form

Item 1 is estimated to require approximately 3 weeks of effort and items 2-4 another 2 weeks for a total of 5 weeks.

In RPS2 the function to generate the Percy script file is incorporated into Trans. This function could be split out as a separate application or carried over into the implementation of Transverse. From the point of view of APT it makes no difference. Whichever way it is implemented the function to generate the Percy script file must be modified to undo one of the effects of OPR 36155, namely the removal of the TRACK command from the script as created by Trans. For APT use, it is necessary to use TRACK rather than CHEBY for performance reasons. For operations use the CHEBY command is used. Therefore, the function to generate the Percy script file must take an input parameter to control whether .trh or .cby files are to be generated.

Figure 1 Percy as Server

Figure 2 Front-end Server to Percy Sessions

Percy Interface Prototype

This prototype will provide users some early experience with interacting with the system. This prototype is the application server approach described in the previous section with the exception that the prototype requires no modifications to Percy in order to be implemented.

The prototype consists of two pieces, the Percy front-end server and the standalone Percy client.

The Percy front-end server will:

1) Accept incoming client connections

2) Accept a Percy script file from a client

3) Create a temporary directory for input and output files

4) Start a Percy session passing the script to Percy for processing (since Percy initialization can take 20-30 seconds it may be desirable to have a Percy session queued up at all times ready to accept input)

5) Provide the resulting output files to the client

6) Notify the client when processing is complete

7) Terminate the Percy session

8) Cleanup temporary files

The Percy client will:

1) Connect to the Percy front-end server

2) Send a pre-existing user specified Percy script file to the server

3) Accept output files from the server and store them locally

4) Notify the user when processing is complete

It is estimated that the prototype as described above will require approximately 6 weeks of effort.

Once the APT Proposal Editor is far enough along to permit the creation of moving target observations we can look at integrating moving target client capabilities into APT. This would involve automating the Percy script file generation, adding support for Percy configuration parameters, and adding the required GUI and display features to APT. Depending on the status of the required changes to Percy itself this integration with APT would either take the form of an extension of the prototype or a beta version of the moving targets support.

Alternative Approach

An alternative to integrating Percy with the APT is to provide the user sufficient information to be able to use Percy directly. As some users indicated in the survey there is currently insufficient information available on the capabilities of Percy (or this information is unknown to the users). Scripts could be provided to assist the user in the generation of graphics products such as finder charts and for the generation of ephemeris and window files. This is essentially transferring work currently done by the Program Coordinators to the user but providing the user with the information and tools necessary to do the work themselves. There is no guarantee that the users would embrace this and the Program Coordinators might wind up with more work as a result of fielding questions on the use of Percy.

This approach requires no additional APT work but might require that Percy be supported under Windows in addition to Solaris in order to broaden the potential user community.

Risks and Concerns

· Schedule

o The integration of support for moving targets in APT is not included in the current APT schedule. This raises the issue of available resources for this work as well as any impact the moving targets integration might have on other APT segments, such as the Visit Planner. The Visit Planner work is just getting underway so a decision on moving target support should be made relatively soon.

· Support for Percy

o The use of Percy for APT is predicated on a commitment of continued support for Percy. Percy consists of two main pieces: the JPL provided SPICELIB, a library of routines providing ephemeris data and a wide assortment of geometry, math, and utility modules (with some STScI customizations); and the user interface and I/O code for interpreting user commands, and modules for generating reports and graphics. Percy is mostly Fortran 77 code with some C code for handling the display of data. Percy currently uses the Fortran 77 version of SPICELIB although there is a C version available. While Percy could conceivably continue to be used as is, some consideration should be given to converting the application to C (e.g. by the f2c utility). Conversion to C (and use of the C version of SPICELIB) would expand the pool of programmers capable of providing support as well as open up the possibility of more easily porting Percy to platforms other than the Sun.

· Cost/Benefit

o The number of proposals with moving targets is a small percentage of the total number of proposals accepted each Cycle. The chart below shows the percentage of the total number of proposals (excluding archive and engineering proposals) with moving targets for each Cycle since Cycle 1. On average, about 10% of all proposals contain moving targets. For Cycles 8, 9, and 10 the average is closer to 6% although it is trending higher. Still, HST accepts a higher percentage of proposals for solar system objects than other major observatories. For comparison, of the 319 proposals scheduled for the NOAO 2001 observing season (KPNO, CTIO, GEMINI) only 7 (2%) involved moving targets.

o Moving Target proposals are typically some of the harder proposals to process due to the constrained nature of the observations, comparable to highly constrained fixed target proposals. So while there are a small number of such proposals they account for a large fraction of the time invested by the PCs. Iterating on moving target proposals involves numerous email messages between the PCs and the proposers. Automating the generation of the ephemeredes and target window files would relieve the PCs from having to perform this task and would significantly improve the turn-around time to the proposer.

Recommendations

Percy is a valuable and powerful application with no true counterpart. Whether or not it is decided to proceed to integrate Percy with the APT the Percy web page and policy regarding access to Percy should be improved.

· Improvements to Percy web page.

a) The Percy web page should be updated to provide substantially more information on the capabilities and use of Percy than currently exists. Samples of Percy text and graphics output should be provided.

b) A Percy script library should be created with examples of scripts to perform typical operations. This library should be available as a link off the Percy web page.

c) Obtaining the Percy application should be a simple matter of downloading an installation package from the STScI. Few potential users will want to deal with their own institutional bureaucracy in order to get a signed license agreement for a piece of software they may use only once. No commercial software package requires a signed license agreement these days. This is always handled through some sort of implied license agreement tied to the use or installation of the software (e.g. “click on OK if you agree to the terms and conditions . . .”).

d) Consideration should be given to making Percy an optional download from the APT download page. This would increase the visibility of Percy.

· Percy Integration With APT

It is recommended that at a minimum the Percy application should be integrated with the APT in order to support the automated generation of ephemeredes and target window files. An initial release could be completed without requiring any modifications to Percy itself. This would reduce the resources required to 6 weeks (essentially the prototype). It should be possible to realize some code re-use with APT in the area of the client-server interface. This should reduce the required effort somewhat.