Proposal Development Process

The APT will provide users with considerable flexibility in the order in which the proposal development steps are carried out. For example, a Phase 2 user could begin proposal development by building a target list in the Visual Target Tuner. The user could then go on to create visits and then exposures. The APT will allow a user to create visit and exposure templates for each target while in the process of creating a target list in the Visual Target Tuner. The templates could be subsequently applied to the proposal. As another example, users could specify exposures before visits in the spreadsheet view. The exposures could be grouped into visits later.

The interactive nature of the tools enhances this flexibility. For example, once Qwik-Trans is available, a user could interactively work at the level of a single exposure at a time, from its specification to its orbit layout.

The APT will impose few constraints on the order of specifying the elements of the proposal (targets, visits, exposures, and patterns). Of course, checks will need to be in place to ensure that all elements are consistent with each other. This checking will be carried out during batch processing (which must precede submission).

The overall APT Phase 2 processing can be viewed as 3 steps.

1.

Create/edit proposal. This is an interactive stage which includes the use of visual and textual (possibly tables, spreadsheets, or forms) tools. In this category are specifying

(a)

the general proposal information by means of a forms editor (object editor)

(b)

targets

i.

Standard fixed target: Visual Target Tuner (with Starview option)

ii.

Target Spreadsheet

iii.

Target Editor

iv.

Target Tree (tree with targets at root)

(c)

visits

i.

Standard fixed target: Visual Target Tuner (with Starview option)

ii.

Visit Spreadsheet

iii.

Visit Tree

iv.

Visit Editor

v.

Orbit Planner (Qwik-Trans)

vi.

Visit Planner (Spike)

vii.

Batch Checker

(d)

exposures

i.

Standard fixed target: Visual Target Tuner (with Starview option)

ii.

Standard fixed target: Bright Object Checker

iii.

Exposure Spreadsheet

iv.

Exposure Tree

v.

Exposure Editor

vi.

Exposure Time Calculator

vii.

Orbit Planner (Qwik-Trans) (e.g., stretch exposure)

viii.

Visit Planner (Spike)

(e)

patterns

i.

Pattern Editor

ii.

Pattern Spreadsheet

2.

Global batch check of proposal. This includes

(a)

Preprocessor for checking the completeness and correctness of overall proposal (e.g., all specified targets are used).

(b)

Observation feasibility checks (now done in Trans).

(c)

Schedulability of the entire proposal (Spike).

(d)

Guide star availability checks

3.

Proposal submission

(a)

generate RPS2 file

(b)

email RPS2 file to STScI

In addition, the user can at any time save a session or generate a report on the proposal. The report tool will produce a summary of all proposal elements (similar to the RPS2 Description Generator), including graphical displays of orbits and visits.

Some of these global checks (step 2) will be moved into the interactive step (step 1) if tools are sufficiently fast. Iteration between steps 1 and 2 can take place, but hopefully most iteration will take place in the interactive tools.

In step 2b, the full Trans will be run. But users will not see the orbit timing results of running the full Trans. So they will not see the difference between the Trans and Qwik-Trans orbit visibility times. The requirements for Qwik-Trans call for orbit visibility times within 5 minutes of full Trans.

Step 2, batch processing, will be the equivalent of another tool that can be run used on a visit (or multiple visits selected together). All the batch functions would be options on the batch tool that could be turned off to allow the user to iterate through what they really need to work on (such as removing diagnostics before using Spike), as can be done now in RPS2. The user does not have to worry about how to make the tools communicate (such as saving any files manually).