Import Options

Prop File Import Options

An APT proposal can contain more information than an RPS2-style prop file. Some examples of that extra information are:

data specific to phase 1
submission history data
and orbit planner output data.

There are several open questions regarding how to deal with such data when importing an RPS2-style prop file into APT. The table below summarizes the available options for addressing those questions:

Option	Preserves Subexposure Data	OP Processing Preserved	Prop File Clear of Subexposure Data	Phase I and Submission Data Preserved	Development Effort	Notes
A	No	No	Yes	No	1 week	(1), (A1)
B	Yes	No	No	No	1 week	(1), (B1)
C	Yes	No	No	Yes	5 weeks	(1), (C1)
D	Yes	No	Yes	Yes	8 weeks	(1), (D1)
E	Yes	Yes	Yes	Yes	16-20 weeks	(E1), (E2)

Notes:

A user can always avoid unnecessary Orbit Planner reprocessing by making changes via the APT editor instead of a prop file. For global sorts of changes that are difficult to make via APT, most visits would be changed, so Orbit Planner reprocessing would be necessary regardless of editing method.

Option Descriptions

Option A

In this option, subexposure data would not be written to, or read from, prop files. (Prop files processed by operations would retain that data.) Importing a prop file would create a new proposal in APT that contained only the data specified in that prop file.

Notes:

This option is unacceptable because all subexposure customizations would be lost on import.

This will cause headaches with the change checker, esp. on executed visits.

Option B

In this option, subexposure data would be written to, and read from prop files. We would not expect or encourage the editing of that data. Importing a prop file would create a new proposal in APT that contained only the data specified in that prop file.

Notes:

With an additional 1w of effort, we could modify this option so that a user could export an APT proposal to a prop file that only contained subexposure data for subexposures whose durations had been customized. With this option, proposal that had no subexposure customization would have no subexposure data in their exported prop files.

Option C

In this option, subexposure data would be written to, and read from, prop files. Prop files would be imported into existing APT proposals.

The existing proposal would retain any data that cannot be specified by a prop file. All data that can be specified by a prop file would be cleared in the existing proposal and replaced by the prop file data.

Notes:

Due to its complexity, deciding which data to retain in the existing proposal will be error prone initially, and a source of ongoing maintenance costs indefinitely.

Option D

In this option, subexposure data would not be written to, or read from, prop files. (Prop files processed by operations would retain that data.) Prop files would be imported into existing APT proposals.

The existing proposal would retain any data that cannot be specified by a prop file. All data that can be specified by a prop file would be cleared in the existing proposal and replaced by the prop file data.

Notes:

Due to its complexity, deciding which data to retain in the existing proposal will be error prone initially, and a source of ongoing maintenance costs indefinitely.

Option E

In this option, subexposure data would not be written to, or read from, prop files. (Prop files processed by operations would retain that data.) Prop files would be imported into existing APT proposals.

The existing proposal would retain any data that cannot be specified by a prop file. All data that can be specified by a prop file would be cleared in the existing proposal and replaced by the prop file data.

The importer would detect which visits had changed and only force reprocessing for those visits.

Notes:

Due to its complexity, deciding which data to retain in the existing proposal will be error prone initially, and a source of ongoing maintenance costs indefinitely.

Due to its complexity, the change checking feature will be error prone initially, and a source of ongoing maintenance costs indefinitely.

Feature Descriptions

Orbit packing can be customized in APT via the "Orbit Number" and "Actual Duration" fields on subexposures. The "Actual Duration" field can be set indirectly by using the new "Auto-Adjust" feature in the Orbit Planner. Normally, when such customizations are made, the "Orbit Number" and "Actual Duration" of each subexposure is stored in the APT xml file.

Some of the mechanisms for importing prop files into APT preserve such customizations, while others discard them.

Discarding subexposure customizations not only forces those customizations to be redone, but also causes changes to the proposal which would be detected by the in-house change checker. These changes would be detected on every visit, regardless of whether or not that visit had been changed in the prop file.

OP Processing Preserved

When the Orbit Planner is run on a visit, and the APT proposal is saved, the Orbit Planner output is also saved.

The Visit Planner depends on output from the Orbit Planner, so saving the Orbit Planner data allows the Visit Planner to be run later at any time without having to reprocess the visit in the Orbit Planner. This cached Orbit Planner data also allows the Orbit Planner display to be viewed later without having to reprocess the visit in the Orbit Planner.

In order to preserve Orbit Planner output when importing a prop file, the prop file would need to be read into an existing proposal that had the Orbit Planner data for each visit. Then APT would need to determine which of the visits in the prop file were the same as those in the existing proposal. Only those visits could use the existing Orbit Planner output (i.e., only visits that hadn't changed would not need reprocessing).

The algorithm to determine which visits have changed will be difficult and time-consuming to implement.

Some of the mechanisms for importing prop files into APT preserve this Orbit Planner output, while other discard it.