Internal Technical Memorandum ITM-1999-07
Automation Cost Analysis of Rolling
Between NICMOS Coronagraphy Observations
in the Same Orbit
Andrew Gerb
October 14, 1999
ABSTRACT
There is scientific demand for being able to obtain NICMOS coronagraphic observations at two
different roll angles within the same orbit, but doing so is presently very labor-intensive. The reasons for this are examined and some alternatives to automate the process are explored. A specific
recommendation for a “two-visit” architecture is made.
1. Introduction
The NICMOS Group has concluded that there is a scientific case for the ability to execute two
coronagraphic observations in the same orbit using substantially differing orientations (as far apart
as 30 degrees). The nature of the science benefit for doing this is described in detail in Instrument
Science Report (ISR) NICMOS-99-006. The need for the differing orientation is driven by the
desire to subtract the two images to correct for diffraction spikes emanating from the coronagraphic hole. The need for the two observations to share an orbit is driven by the fact that the
coronagraphic hole is known to change its position relative to the field of view on a scale of hours,
so the accuracy of the subtraction is improved by reducing the intervening time interval.
Observations of this type have been successfully executed during the period in which NICMOS
was in use between the 1997 servicing mission and the depletion of cryogen. Unfortunately,
STScI’s proposal preparation software provides less automated support for exposures with differing roll in the same orbit than for other observations. This has resulted in a labor-intensive
implementation process for the Program Coordinator team.
This analysis was prepared at the request of Peg Stanley as a tool to help determine how best to
support orbits with more than one orientation. I list the sources of the labor-intensive nature of
implementing multiple orientations in the same orbit and identifies which of those would be amenable to automation via improved software. I also list the various possible solutions and their costs.
Finally, I provide a recommendation for which option would be most likely to provide optimum
use of available resources
1
Internal Technical Memorandum ITM-1999-07
1.1 Simplifying Assumptions
During discussions with Alex Storrs, one of the co-authors of ISR NICMOS-99-006, we identified
the following simplifying assumptions about the coronagraphy observations we would be
supporting:
• There will be no more than two different orients required in the same orbit, never three or
more.
• The roll between them will be limited to 30 degrees or less.
• The two sets of observations will have a target and FOV pointing sufficiently close to each
other so that they will not require different target visibility intervals or nominal orientations.
• It is equally acceptable from a scientific point of view for the two orientations to be in two
separate visits as it is for them to be in the same visit.
• The visit(s) involved will be wholly contained within a single orbit. I.e. no portion will continue into the next orbit or be continued from a visit in the previous orbit.
• The observations will not require an ORIENT FROM NOMINAL capability.
• The observations within the orbit will agree on their use of LOW SKY or CVZ. They will
not request scheduling within the earth’s shadow.
• Our software will not be required to verify or find scheduling opportunities where there are
“no large changes in attitude history immediately preceding the coronagraphic observations,” as recommended by the ISR.
The software estimates contained in this analysis are based on these simplifying assumption.
Relaxation of one or more will likely require higher estimates.
1.2 Disclaimer
The costs in this document are estimates. They are intended to be used for purposes of determining feasibility only. No detailed design work has been done for any of the software enhancements
mentioned. Therefore the costs estimates in this document should not be construed as a promise
to complete a development project within the costs given or as making any statement as to the
availability of development resources to do the work.
1.3 Complicating Factors
The next sections document the complicating factors which required labor-intensive work-arounds
during the implementation of these observations. These were compiled during discussions with
Doug Van Orsow who served as the Program Coordinator for all these observations and Ian Jordan
who assisted with developing plan windows for them. For each issue, I describe the problem as I
understand it, explain the cause and discuss possible solutions. I divide them into two basic categories based on the solution. The first three are amenable to automation using improved software,
whereas the last four are not.
2
Internal Technical Memorandum ITM-1999-07
2. Problems That Can Be Automated with Improved Software
2.1 No Information from RPS2 to Proposer when the Orbit Is Full
The Problem: In most situations, RPS2 lays out the exposures among occultations within orbital
visibility periods to allow the proposer to know how much science can be accomplished in the time
given. This is especially crucial for coronagraphic observations taken at different rolls, since the
intention is to execute them close together in time. However, RPS2 does not accurately provide
this capability for observations which are scheduled in separate visits in the same orbit. This
results in these quantities needing to be computed by hand to verify that all the affected observations will fit in a single visibility period.
The Cause: When Trans lays out orbits for RPS2, it works on one visit at a time, without knowledge of the structure of other visits in the proposal. Since coronagraphic observations with
different rolls have been implemented in separate visits, Trans is not aware that the second does
not have use of the full visibility interval because it cannot account for the time already taken up
by the first. Therefore it lays out the second visit as if it started a fresh visibility period, and does
not correctly determine when its exposures have run into occultation.
The Solution: This can be solved by feeding Trans the information about the use of visibility time
by the earlier visit when it processes the later one. Below I detail several ways of doing this.
2.2 Spike Plans Visits for Periods with Insufficient Visibility
The Problem: The plan windows generated by Spike for two visits in the same orbit may contain
weeks for which no orbit exists whose visibility is sufficiently long to schedule the visits. There
may even be cases where nowhere in the plan window can there be sufficient visibility found. This
results in substantial efforts on the part of the Program Coordinator to verify that the plan windows
offered by Spike will allow scheduling in SPSS. Typically the Program Coordinator runs SPSS
repeatedly to find orbits with sufficient visibility, then overrides Spike’s internal constraints so that
the visits involved will be planned for those orbits.
The Cause: The cause is similar to the previous item. Spike receives its information about the
amount of visibility a visit requires from Trans. Since Trans processes visits individually, it will
not have any knowledge of the full use of visibility by the two visits, only the amount of visibility
they individually use. When this smaller quantity is fed to Spike, it believes that very little visibility is needed by these visits and it may schedule them where the visibility duration is restrictive.
The Solution: As in the case of the previous item, this is solvable by feeding Trans information
about the use of visibility time by the previous visit when it processes the later one so Trans can
give accurate information to Spike.
2.3 Resource Information Given to Spike is Inaccurate
The Problem: Spike will allocate an entire orbit to each of the two visits which share a visibility
period, even thought they only require a single orbit between them. This results in the long range
plan developed by Spike being undersubscribed during time periods containing these visits.
The Cause: Spike currently has no concept of two visits sharing an orbit. Among the information
Trans feeds to Spike for each visit is the number of orbits that visit spans. Currently this number is
always an integer greater than or equal to 1, so two visits will always take up two orbits.
3
Internal Technical Memorandum ITM-1999-07
The Solution: This is solvable by modifying the software so that Spike receives an accurate total
of the number of orbits used by the two visits.
3. Problems Not Amenable to Automation with Improved Software
3.1 Orients Chosen that Did Not Have Guide Stars
The Problem: There were frequent occurrences when Spike scheduled these visits at an orientation for which no guide stars are available. This requires the Program Coordinator to run the New
Guide Star System by hand in order to find suitable orientations and then feed the orientation into
Spike. Typically this requires help from someone on the Science Planning and Scheduling Team.
The Cause: There is no clear consensus on what caused this problem and no analysis was done at
the time. Lacking the details now, we can only speculate on what might have caused it. Here are
some causes that have been offered as possibilities:
• This might have been caused by the use of the old Quicklook interface by Spike, and may
be attributable to differences between the way Spike and SPSS use the guide star system.
(Wayne Kinzel is skeptical about this one. Bill Workman devoted a lot of effort in ironing
out the differences between the two ways of using the guide star system, so that for recent
cycles they have been virtually identical.)
• Larry Kramer suggested that this may stem from a known bug in the way Spike handles relative orients, as documented in OPR 34298.
• Denise Taylor recalls that the orientation relationships were originally specified using the
ORIENT FROM NOMINAL special requirement which is not well supported by Spike.
The Solution: In the absence of accurate understanding of what caused this problem, software
changes to fix it would be premature. It would seem the best way to address this would be to note
in the Program Coordinators’ documented procedures that if such a problem is encountered, the
PC should immediately submit an OPR, even before all the details are known, so that investigation
into the cause is possible.
3.2 Proposal Changes Caused Rework
The Problem: The coronagraphic proposals which rolled within an orbit showed a far greater rate
of modifications than ordinary proposals. This made the effort to implement these visits many
times what it would have been had they remained stable.
The Cause: The nature of the orientation constraints was certainly a contributing factor. It was frequently necessary to make a change such as narrowing the intervening roll distance to satisfy these
constraints. Other factors which contributed were the evolving understanding of how best to use a
new instrument, and possibly even the style of members of the coinvestigator team.
The Solution: It is not likely that software will improve the rate of proposal changes. However
making guide star information available to the observers may mitigate the effort on the part of the
the Program Coordinator to process this information at STScI. Since this information is expected
to be available well before the reintroduction of the NICMOS in cycle 10, no further automation
effort is indication in response to this item.
4
Internal Technical Memorandum ITM-1999-07
3.3 EFF30 Must Be Used
The Problem: Normally, in situations where a visit has constraints that may make it difficult to
implement or schedule, that proposal’s use of visibility (called its EFF-level for historical reasons)
can be shortened to all the visit more flexibility on where to schedule. Typical visits are scheduled
at EFF30, meaning their use of visibility can be accommodated in at least 30% of the orbits
throughout the year. However RPS2 allows EFF-levels up to EFF100, where the amount of visibility the visit uses is available in every orbit, making scheduling easier. Ideally the coronagraphic
visits which roll within an orbit would have been given EFF100, however this was not possible.
This increased the effort needed to implement these visits by restricting the options the Program
Coordinator had to find places for them to schedule.
The Cause: The decision to use EFF30 for these visits arose from an agreement between the coinvestigator team for the coronagraphic proposal and Presto management that the proposal’s science
objectives merited the use of EFF30, and that the extra manual work involved was acceptable.
The Solution: This is primarily a scientific and policy issue, and is not amenable to a software
solution.
3.4 Use of Absolute Orients
The Problem: Most of the coronagraphic visits which required a roll within an orbit were not constrained as to their orientation. I.e. the two visits had to be separated by 30 degrees, but were
allowed any two orientations which allowed this separation such as 130D & 160D, 220D & 250D,
etc. A sizeable minority, however had absolute orientation requirements, meaning that each was
constrained to be at a specific orientation, limiting their schedulability to a few days over the year.
This resulted in far greater effort needed for the Program Coordinator to implement them.
The Cause: According to members of the NICMOS group, use of absolute orientation resulted
when science needs required certain objects within the field of view be clear of detector
irregularities.
The Solution: It is likely that access to guide star information by observers will allow them to
make trade-offs between fixing the orientation and making the observation schedulable. Therefore,
it is expected that this situation will improve without further changes to the software.
4. Software Solutions
Essentially, we have a choice between three courses of action:
1. Provide software modifications to ameliorate the labor involved to address the three
problems above that are amenable to automation.
2. Do not provide software automation, but support roll between observations in the same
orbit by devoting increased resources from the Program Coordinator Team to this science.
3. Do not support the ability for observers to request a roll within a single orbit, with the
knowledge that this will decrease the science return on NICMOS.
In this document, only item (1) above is considered. The Program Coordinator Team has been
tasked with analyzing (2), and (3) will be considered as a last resort only if the costs of (1) and (2)
each prove prohibitive.
5
Internal Technical Memorandum ITM-1999-07
Two basic architectures exist for automating solutions to the problems detailed above:
Two Visit: The observations before and after the roll are in different visits.
Single Visit: The observations before and after the roll are in the same visit. The roll occurs within
the visit.
These are the same two solutions identified by the ORIENTation working group during a preliminary study on this issue in May 1997. On that occasion, we opted against a more detailed analysis
pending a better understanding on the science benefits which has now been provided by the ISR.
The way these two architectures will be executed on the spacecraft will be substantially the same.
However, the similarity ends (or begins) there. Throughout the rest of the ground system, these
solutions are substantially different, each requiring widely differing changes to software componants. Each solves the three automatable problems in a significantly different way. For that
reason, each of these architectures is described and analyzed separately.
It is important to note that the cost of these software changes is independent of whether proposal
development is accomplished via RPS2 or through another tool, such as is being proposed as part
of the Astronomers Proposal Tools (APT). The three problems would each be solved by increasing
the quality of information available to Trans and Spike. Since both RPS2 and APT will rely on
Trans and Spike for proposal implementation information, the changes below will be necessary to
ensure that either of them present accurate data to observers.
4.1 Two-Visit Architecture
In the Phase 2 proposal, the Two Visit solution will typically consist of two visits sharing a relative
timing link, (SEQ WITHIN or AFTER BY) that constrains their order and their proximity, and
either a relative orient link (ORIENT FROM) between them or an absolute orient on both.
Trans
The chief technical challenge with the two visit architecture is to feed Trans enough information to
determine where during the visibility period the activities comprising the two visits will execute.
This is complicated by the concept of visit independence. When Trans processes a visit, it has no
knowledge of the structure of any other visit in the proposal. Visit independence has been an
important concept in making proposal implementation change-responsive. When a change is made
to a visit, we can be assured that its products can be delivered without impacting any other visit
that might have been delivered previously. However, in the case of two visits sharing an orbit, visit
independence becomes more of a hindrance than a help. When Trans is processing the later of the
two visits, it has no knowledge of how much visibility has already been used by the first. To implement the two visit architecture, we will need to provide Trans with that information as well as the
pointing of the last alignment in that visit and the magnitude of the roll so that Trans can calculate
the slew time.
The following is an accounting of the work needed in Trans to support the two visit architecture:
• Implement a mechanism to feed pointing, roll and visibility usage information from the
earlier visit into Trans when it is processing the later visit.
• Feed this information into the Trans model of orbital “path times” for an accurate representation of the start times of activities in the visibility interval.
• Pass this information to Spike and to the RPS2 Description Generator.
6
Internal Technical Memorandum ITM-1999-07
• Enforce the availability of this information to make sure Trans remains accurate. In practice this will probably mean to generate a warning message if the normal operation of the
RPS2 or OPS controller is overridden in such a way that Trans doesn’t receive it.
• Investigate the implications of this situational relaxation of visit independence to make sure
that no unintended consequences accrue.
Estimates for this Trans work are 4-6 weeks FTE. The logical time to implement the path times
improvement (the most work-intensive item above) would probably be during TransVERSE phase
9, at the same time the rest of the Trans path times are being redesigned.
Spike
Since Trans will be passing an enhanced visibility model into Spike for the later visit, it is likely
that no changes to Spike will be required to support accurate suitability for that visit based on the
amount of visibility it uses. Since it will be tightly linked to the earlier visit, the suitability of the
earlier visit based on orbital visibility will be accurate as well. A minor Spike modification will be
needed to account accurately for the number of orbits used by the two visits. Spike would need to
adjust from 2 down to 1 the number of orbits used by two visits that are tightly enough linked as to
require them to schedule in the same orbit. The Spike work in support of the two orbit architecture
is estimated at 1-2 weeks FTE.
Other SST Software
It will be necessary for the RPS2 Preprocessor to pass to Trans and Spike information identifying
the two as sharing an orbit and about the magnitude of the roll between the visits. This work is
estimated at less than half a week FTE. Furthermore, since the RPS2 Change-Checker determines
which visits are sent to be rerun through Trans, it needs to be enhanced to allow it to realize that
the later visit needs to be rerun when the earlier visit is changed. This work is estimated at 1 week
FTE.
Downstream Systems
The downstream systems have already demonstrated support for the ability to place a roll between
two visits in the same orbit. The interface between Spike and these systems has been sufficient to
select suitable rolls at which the visits can be scheduled, so no changes should be required to
NGSS or SPSS to support the Two Visit architecture.
4.2 Single-Visit Architecture
In the Phase 2 proposal, the Single Visit solution would appear as a new exposure-level special
requirement which allows the proposer to specify a roll between adjacent exposures within the
visit. Typically there will be an obset break between these two exposures when the exposures are
run through Trans.
Spike
Currently Spike supports only a single orientation on a visit. Allowing it to model orientation at
the obset level, instead of the visit level, would amount to a redesign of the section of Spike which
reasons about orientation. In addition there are likely to be substantial, as yet not understood
changes to the interface between Spike and SPSS that determines at which orientation visits will
be scheduled. In the absence of a more detailed requirements analysis, the Spike team has esti-
7
Internal Technical Memorandum ITM-1999-07
mated 5-9 weeks FTE. However they stipulate that this may grow far higher if a detailed analysis
indicates unforeseen problems.
Trans
Trans already supports a slew between two obsets in the same orbit. These rules will need to be
enhanced to allow Trans to compute accurately the duration of this slew when it is due in part to a
spacecraft roll. This work is not expected by the Trans team to take more than 1 FTE week.
Other SST Software
The RPS2 Preprocessor would need to implement the new special requirement which allows a roll
between two exposures in the same visit. The existence and details of this special requirement
would need to be communicated to Trans, Spike and the Assist database. The RPS2 team estimates
this work at 1 1/2 weeks.
Downstream Systems
NGSS and SPSS already support two obsets executed at different orientations in the same SU.
However, Spike communicates it selection of orientation to SPSS via the plan_orient relation. This
interface assumes that the orientation will be the same throughout the entire scheduling unit. There
is no way using this relation for Spike to specify differing orientation requirements for adjacent
obsets within a scheduling unit. Therefore, under the single visit architecture, this interface
between Spike and SPSS would need to be changed substantially. Bob Samson suggests the best
way to do this would be to add to the PMDB a way to encode relative orient relationships between
two obsets within the same scheduling unit and allow the CALOPT tool provide a solution that satisfies that constraint. He estimates this change at 2 months.
4.3 Other Software Changes
Presto and PST have been discussing the possibility of upgrading the ability of SPSS to schedule
relative orient links (like SAME ORIENT or ORIENT FROM). While it appears that the implementation of this project will have substantial benefit to the PC team by making it easier to
schedule relative orientation requirements in general, it does not appear to have any special application to those where the linked observations appear in the same orbit. Therefore this SPSS project
is not mentioned in the automation figures below.
5. Costs of Software Solutions
Because the general architectures are already understood, requirements definition for the Two Visit
architecture will involve only a few FTE days. For the One Visit architecture, it will be more complex, since new details of the interface between Spike and SPSS will need to be worked out. I
would need about 1 1/2 FTE work to fully define them. A similar dichotomy exists between the
testing effort for the two architectures. Karla estimates the Two Visit architecture would require
one FTE week to test, whereas the One Visit architecture would require two FTE weeks to test.
System
Requirements Analysis
PP, DG, Change Checker
Trans
Two-Visit Architecture
Single-Visit Architecture
1/2
1 1/2
1 1/2
1 1/2
4-6
1
8
Internal Technical Memorandum ITM-1999-07
System
Spike
Downstream Systems
Two-Visit Architecture
Single-Visit Architecture
1-2
5-9 or more
None
9
Testing
1
2
TOTAL
8-11
19-23
6. Recommendation
I recommend that we automate allowing a roll between coronagraphic observations sharing an
orbit by implementing the Two Visit architecture.
In addition to higher development costs, far more risk accrues with the Single Visit architecture.
The Two Visit architecture as been proven to work throughout the system resulting in successfully
executed science, whereas the Single Visit approach has not been validated operationally. Also the
development effort involved in implementing the Two Visit architecture tends to be well understood, and therefore bounded, whereas development of the Two Visit architecture in Spike and
SPSS remain somewhat open ended due to uncertainties in how they would be designed.
I believe the benefits of automating rolls within an orbit go beyond the effort they would save
among the Program Coordinator Team. The ability of RPS2 (or its successor tools) to model such
rolls accurately would decrease the amount of iteration required between observers and their PCs,
resulting in an improved experience for the observers involved in this type of science. I would suggest that even if the cost to implement this capability proves comparable to the efforts required by
the Program Coordinator Team to support this capability manually over the lifetime of NICMOS,
it still would be beneficial to proceed with the implementation.
7. Acknowledgements
Thanks go to Doug Van Orsow, Alex Storrs, Ian Jordan, Wayne Kinzel, Mark Giuliano, Larry
Kramer, Roberto Samson, Rob Douglas, Gary Curtis, Karla Peterson, David Elkin and Daniela
Calzetti for the information they provided during the preparation of this report.
9