APT Two-Gyro Options

Last Updated:  09/14/2004

This document discusses three possible ways to implement two-gyro processing in APT.  We recommend option A due to it's lower cost and lower complexity (complexities noted in "Cons" for options B and C).  The lower cost and complexity results from the fact that option A most closely matches APT's implementation of other user input fields.

The work estimates include design, implementation and integration efforts, but do not include independent testing efforts.  We expect the independent testing effort to be similar to the development effort for each option.

A.  User-Specified Proposal-Level Two-Gyro Flag

B.  User-Specified Global Two-Gyro Flag in APT

C.  User-Specified Global Two-Gyro Flag in APT w/Hidden Proposal Flag

 

A.  User-Specified Proposal-Level Two-Gyro Flag

FTE Estimate:  15 days

In this option, a new boolean property, called something like "Two-Gyro Proposal", would be added to the proposal information block.  APT would handle this flag in a way similar to how it handles other proposal information properties such as "Pure Parallel Proposal" and "Proposal Category".  Those flags values only apply to the proposal containing them, and changes to those values automatically render previous  orbit planner and visit planner processing out-of-date.

The Orbit Planner and Visit Planner would use the proposal's "Two-Gyro Proposal" flag to determine which type of processing to perform.

This approach would require the following development actions:

  1. 1d - Add the "Two-Gyro Proposal" flag to the proposal information block in APT.  The value would default to "false".  APT would still be able to read old proposals, but edited and newly created proposals would all be saved with the flag.

  2. 2d - Modify the PP and APT's text file import/export mechanism to support the optional Proposal_Information keyword Two_Gyro_Proposal, whose legal values would be "Yes", "No" and blank.  Again, unspecified values for the keyword would be treated as "false".  The PP should pass that value through to Trans via the tdf file in case Trans wants to use the value to drive what type of processing to do, or for error checking if Trans' gyro mode is specified elsewhere in the ground system.

  3. 1d - Change the proposal instructions to mention the "Two-Gyro Proposal" flag for both APT and text format proposals.

  4. 0.5d - Update APT's help tags to point to the new proposal instructions for that property.

  5. 1d - When the Orbit Planner processes a visit, it should do so based on the value of the proposal's Two-Gyro flag.  

  6. 0.5d - When the Two-Gyro flag is changed on a proposal, Orbit Planner processing for all visits in the proposal should be marked as *not* up-to-date.

  7. 1d - When the Visit Planner processes a visit, it should do so based on the value of the proposal's Two-Gyro flag.

  8. 0d - When the Two-Gyro flag is changed on a proposal, Visit Planner processing for all visits in the proposal should be marked as *not* up-to-date.  This is no work, because when the Orbit Planner marks the visits *not*  up-to-date, the visits are automatically not up-to-date with respect to the Visit Planner. 

  9. Output reports:

    1. 1d - pdf

    2. 1d - listpro

  10. Assist processing: 

    1. 1d - adf loader

    2. 1d - add field to assist

  11. 1d - The Visit Planner should display suitability.

  12. 3d - The Visit Planner should display new summary reports from Spike.

 

Pros:

Cons:

 

B.  User-Specified Global Two-Gyro Flag in APT

FTE Estimate:  17 days

In this option, APT would have a global boolean flag called something like "Two-Gyro Mode".  The proposals themselves would not store any notion of which mode was used to prepare them.

The Orbit Planner and Visit Planner would refer to this flag to know how to process their visits.  When the value of the flag changes and when a proposal is loaded, the Orbit Planner and Visit Planner would have to decide whether any existing processing for a proposal's visits should be marked *not* up-to-date.

This approach would require the following development actions:

  1. 2d - Add a global flag, "Two-Gyro Mode", to APT.  The value should be clearly displayed and editable on the main APT screen.  The value should be persistent across APT invocations (i.e., it should be saved as an APT preference).

  2. 2d - Help should be added for that flag.

  3.  1d - When the Orbit Planner processes a visit, it should do so based on the value of APT's Two-Gyro flag.  

  4. 5d - The Orbit Planner should make sure that any visit loaded in APT is marked *not* up-to-date if it's Orbit Planner processing was not done in the same mode as specified by the global flag.

  5. 1d - When the Visit Planner processes a visit, it should do so based on the value of APT's Two-Gyro flag.

  6. 0d - When the Two-Gyro flag is changed on a proposal, Visit Planner processing for all visits in the proposal should be marked as *not* up-to-date.  This is no work, because when the Orbit Planner marks the visits *not*  up-to-date, the visits are automatically not up-to-date with respect to the Visit Planner.

  7. - Output reports:

    1. 1d - pdf

    2. 1d - listpro

  8. 1d - The Visit Planner should display suitability.

  9. 3d - The Visit Planner should display new summary reports from Spike.

 

Pros:

 

Cons:

 

C.  User-Specified Global Two-Gyro Flag in APT w/Hidden Proposal Flag

FTE Estimate:  21 days

This option is the same as User-Specified Global Two-Gyro Flag in APT except that the proposal will retain a record of which mode was used during proposal creation. 

This approach would require the following development actions:

  1. 2d - Add a global flag, "Two-Gyro Mode", to APT.  The value should be clearly displayed and editable on the main APT screen.  The value should be persistent across APT invocations (i.e., it should be saved as an APT preference).

  2. 2d - Help should be added for that flag.

  3. 1d - When a proposal is saved, it should be saved with a record of the current value of APT's Two-Gyro flag.

  4.  1d - When the Orbit Planner processes a visit, it should do so based on the value of APT's Two-Gyro flag.  

  5. 3d - The Orbit Planner should make sure that any visit loaded in APT is marked *not* up-to-date if it's Orbit Planner processing was not done in the same mode as specified by the global flag.

  6. 1d - When the Visit Planner processes a visit, it should do so based on the value of APT's Two-Gyro flag.

  7. 0d - When the Two-Gyro flag is changed on a proposal, Visit Planner processing for all visits in the proposal should be marked as *not* up-to-date.  This is no work, because when the Orbit Planner marks the visits *not*  up-to-date, the visits are automatically not up-to-date with respect to the Visit Planner.

  8. 2d - Modify the PP and APT's text file import/export mechanism to support the optional Proposal_Information keyword Two_Gyro_Proposal, whose legal values would be "Yes", "No" and blank.  Again, unspecified values for the keyword would be treated as "false".  The PP should pass that value through to Trans via the tdf file in case Trans wants to use the value to drive what type of processing to do, or for error checking if Trans' gyro mode is specified elsewhere in the ground system.

  9. 1d - Change the proposal instructions to mention the "Two-Gyro Proposal" flag for text format proposals.

  10. - Output reports:

    1. 1d - pdf

    2. 1d - listpro

  11. - Assist processing: 

    1. 1d - adf loader

    2. 1d - add field to assist

  12. 1d - The Visit Planner should display suitability.

  13. 3d - The Visit Planner should display new summary reports from Spike.

 

Pros:

Cons: