Telescope Time Review Board
The HST Telescope Time Review Board (TTRB) reviews requests to change accepted HST programs, duplicate observations, repeat observations, and other program alterations. This page also describes process for Hubble Operation Problem Reports (HOPRs), Program Change Requests (PCRs), and requests for Resolution of Data Duplications (RDDs).
How to Contact the TTRB
Web links for each type of TTRB request (HOPR, PCR, RDD) can be found on the Program Information page for the program in question.
There is no central link for the TTRB.
Policies of the TTRB
This document presents STScI policy for granting formal changes and additions to accepted HST programs, as well as repetitions of failed observations. Three types of requests may be made by a General Observer (GO), Instrument Scientist (IS), or Program Coordinator (PC). All are made using a web tool. The first type is an HST Operations Problem Report (HOPR), which describes an operational problem that occurred in obtaining data and which generally requests a repetition of all or part of the lost observation. The second type is a Program Change Request (PCR), which asks for specific alterations to upcoming observations that are significant enough to warrant TTRB approval (such as a change of instrument or a change to the orbit allocation). The third type is a request for Resolution of Data Duplication (RDD), which is a request to adjudicate an apparent duplication in use of HST or a conflict of data rights.
Overview of TTRB Operations
Changes to approved HST programs are evaluated, discussed, and reviewed by the Telescope Time Review Board (TTRB), which is composed of staff members from the STScI divisions and missions that schedule the telescope and support science observations. The TTRB exists to maximize the science return of HST within approved policy, but has limited latitude to deviate from established precedent.
The TTRB makes recommendations based on the policies in this document. TTRB recommendations are forwarded to the Head of the Science Policies Group (HSPG; Claus Leitherer) for approval. Once the approval is granted, the TTRB chair notifies the submitter of the result via email.
The Domain of the TTRB
Observing time on HST is allocated by the Director of STScI. Ordinarily this is done in one of three ways:
- Through a Call for Proposals, with review by a TAC;
- Following a submitted proposal for Director’s Discretionary Time, after suitable scientific review;
- Through an internal review of calibrations that are requested and defined by the Science Instrument (SI) groups and approved by the HST Mission Office.
Each of the above three ways leads from a submitted proposal to an approved program, with a specific allocation of HST time, ordinarily in units of orbits. Also, specific programs are approved to observe specific targets with particular instrument modes and parameters. After a proposal is approved, a detailed Phase II program must be created, which is then accepted for execution on the telescope.
Inevitably changes must be made in some programs after they are accepted, and the TTRB exists to review these and make recommendations to the HSPG, who may approve on behalf of the Director’s Office. Some of the reasons for changes include:
- Failure of an observation. The failure or anomaly may have occurred during program implementation, in the ground system, or on the spacecraft.
- Alteration of a program to use a different filter, grating, or instrument.
- Addition of a new target to a program or changing one target for another.
- Changes that result from knowledge of the SI or telescope that was not available at the time the proposal was written, potentially requiring additional telescope time to achieve the approved science goals.
Issues not covered by the TTRB
- Minor changes: some instrument changes and target switches are minor and need only the approval of an IS from an instrument team, but major changes to a program require TTRB approval. A list of what constitutes a major change is given in Section 4.
- Data access: requests to change the exclusive-access period (proprietary period) of a program are not handled by the TTRB but should be directed to the Science Policies Group (SPG). Contact information for SPG can be provided by the PC.
Reporting Mechanisms and Procedures
Matters come to the attention of the TTRB through a reporting mechanism that is invoked using a web page. The Principal Investigator (PI), or his or her designee, enters basic program information, an explanation of the nature of the action requested, and the reasons for the action. The web submission software adds additional program information from a database, and the members of the TTRB are notified that a new request has been submitted through automatic e-mail.
The Chair of the TTRB, in collaboration with the other members of the TTRB, reviews the request and prepares a recommendation. An IS and/or PC, and/or other STScI experts, may be consulted as needed during this review. After the appropriate consultation has taken place, the Chair may request further information or clarification from the PI. The TTRB recommendation reached through this process is communicated by the Chair to the HSPG for concurrence. In some cases, the HSPG may modify the recommendation. Upon concurrence, the Chair of the TTRB notifies the PI of the outcome.
Types of Issues Treated
All the issues treated by the TTRB are reported with the same web-based software, and at the time of submission are assigned a tracking number through the STScI JIRA system, of the form HOPR 12345, Duplication Report 12345, or Change Request 12345. A different form exists for each type of request. The web links for each type can be found on the Program Information page for the program in question (http://www.stsci.edu/hst/observing/program-information).
HST Operations Problem Report (HOPR)
HOPRs are filed to request repeats of failed observations. They describe the nature of the problem and its impact on the data. Policies and procedures for HOPRs are described below in Section 3.
Program Change Request (PCR)
Many changes to accepted programs are minor alterations, such as changing an exposure time, using a different filter or central wavelength setting. These types of changes may be approved by a CS or IS without further review, and some may be implemented by the PC. PIs can initiate minor change requests via email. At some point, however, a program change is clearly significant or has the potential to be. For such major changes, a Program Change Request should be filed, using the web tool. Policies and procedures for PCRs are described in Section 4.
Resolution of Data Duplication (RDD)
A GO, CS, IS, or PC can file an RDD whenever two separate observations in separate programs duplicate one another, or if there are conflicts in data rights that arise. Policies and procedures for RDDs are described in Section 5.
HOPR Policies and Procedures
A HOPR is submitted via a web page and is ordinarily submitted by the PI but may also be submitted by a Co-I, IS, CS, or PC. In any of these cases the HOPR will be considered to have been effectively submitted by the PI. A HOPR is submitted when a problem is found with the observation, either in the way the observation was (or was not) executed, or with the data received. A HOPR should clearly describe the type of problem (e.g. guidestar acquisition failure), the impact of the problem on the data (e.g. trailed images, empty exposures, low S/N spectra), and the repeat request (number of orbits to repeat).
A HOPR generally requests that all or part of an observation be repeated, but some failures are of a nature that makes a HOPR unnecessary. Failures are eligible for automatic repeat when visits are affected by a spacecraft or instrument anomaly, as long as the entire visit was lost and the program itself did not cause the malfunction. Such failed observations are identified immediately after the failure and are automatically rescheduled. They are made known to the TTRB for nominal review.
Policies for Granting Requested Repeats of Observations
Type of Observation
Repeats are not normally granted if the failed observation was a SNAP observation.
Completeness of Program
Repeats are not ordinarily granted if a program is already 90% complete. “Complete” here means that 90% or more of the orbits allocated to the program have been successfully executed at the time the HOPR is evaluated (not including the failed orbits). Scheduled observations that have not yet executed are not ordinarily counted as “complete,” although they may be in some circumstances as, for example, when the lifetime of an instrument is near an end and the remaining schedulable time is highly constrained.
The failure of observations in a program that is already >90% complete is not grounds for automatic rejection of a HOPR. However, a HOPR filed in this situation needs to indicate clearly why the repeated observations are essential to achieving the scientific goals outlined in the original proposal. The TTRB will adjudicate this request.
Incorrect Target Coordinates
PIs are responsible for generating target coordinate charts in APT and verifying the target being observed. (Charts for moving targets are generated at STScI and provided to the PI as they cannot be generated in APT.) Some targets (especially bright ones) may be difficult to evaluate on these charts, but in all cases the PI remains responsible for supplying complete and correct target coordinates in the proper units, and the source of those coordinates must be included as well. In the case of targets with significant proper motions, the PI is responsible for providing both the epoch of the coordinates and the proper motions in the correct units. Therefore, HOPR requests that involve incorrect target coordinates or proper motion values are not ordinarily approved.
Program Error by STScI
If the observation failed due to an error originating within STScI, repeats are ordinarily granted.
Program Error by PI
If the failure was caused by an error that can be shown to originate with the PI (or his or her designee), then a repeat will not be granted. This includes programs that fail due to bright object violations. STScI will attempt to detect observer error on a best-effort basis, but errors nevertheless remain the PI’s responsibility.
Some accepted programs are unusually difficult to implement or may face a higher-thannormal chance of failure. In these cases, the PI will be notified before the observations are obtained, and the observations are then executed on a shared-risk basis. This means that repeats will not ordinarily be granted if an observation fails. In some cases, high-risk programs may be brought before the TTRB before they are implemented.
Partially Failed Visits
HST visits may fail partially or completely. In the case of a partial failure, defined as a multiple-orbit visit in which only some orbits execute successfully, the TTRB will by default only approve a repeat of the failed portion of the observations. However, in some instances (e.g. observations of a planetary transit, or joint observations with another observatory), a failure of part of the visit will necessitate a full repeat, because all the observations must be taken contemporaneously. It is the responsibility of the PI to justify clearly which portion of the failed observations need repeating. Full repeats of partiallyfailed visits (or visit sequences) that are four or more orbits in length will be considered to be high-risk observations. In such cases, the TTRB will apply a one-repeat-only rule to avoid the possibility of multiple repeats of the same observations. The PI will be notified when this rule is applied.
Safe-Target Offset Visits
If a safe-target offset procedure (STOP) is included in a COS or STIS visit, and the safety of the target is not demonstrated within the specified time limit, then the visit will not be repeated. Otherwise, requests to repeat STOP visits will follow usual HOPR policies.
Scheduling of Repeat Observations
Repeats of failed observations will generally be scheduled on a best-effort basis by the planning and scheduling team, working with the PCs. If a PI wishes to request a repeat on a specific timescale, he/she must include a detailed scientific justification for this in the HOPR. This justification will be adjudicated by the TTRB. Repeats on short timescales (<1 month) involve substantial workload for the schedulers and typically cause observations from other programs to be postponed, and therefore need to be extremely well justified.
Release of Data
Under most circumstances, if a repeat is granted then the original (“failed”) observations will be made immediately available to the public in the archive. If a repeat is granted for an entire program, then all of the data acquired so far will be released. The intent is that if the observations are good enough to do the science that the PI proposed then they should not be repeated, and that a PI should not be given preferential access to duplicate observations. Therefore, if a repeat is given, the data are acknowledged to be inadequate for the original purposes and can be made freely available without impairing the PI’s science goals. The PI may request a repeat with no release of the original data, but compelling supporting arguments must be provided. The TTRB will adjudicate such a request.
Deadlines for HOPR
Submission and Program Resubmission HOPRs must be filed within 90 days of the date when the affected observations failed. A repeat will not be granted if this period is exceeded unless the PI can provide clear and compelling evidence of why it was impossible to file the HOPR within the 90 days. In cases where the end of an operating mode is imminent, a specific HOPR deadline may be imposed beyond which no HOPRs whatsoever for that instrument will be accepted simply because repeats cannot be scheduled. If a repeat has been granted, the PI has six weeks in which to supply a revised Phase II program. If no changes to the original observation are needed, a new submission is not necessary, but the PI must still contact the PC to let them know.
Change Requests Within HOPRs
A request to repeat an observation may also include a request to change the way in which the observation was obtained or the target observed. Such change requests after the fact are unlikely to be granted unless convincing arguments are presented that require the changes to be made to the observing plan (as opposed to changes that improve the observing plan). Change Requests should be filed well before observations are taken.
Program Change Request (PCR) Procedures
A PCR should be filed whenever an alteration to a program significantly changes its ability to be scheduled, if a limited resource is requested, or if a change might result in a data conflict or duplication issue. The following types of alterations ordinarily require a PCR:
- Increasing the allocation of primary or parallel orbits above the numbers allocated by the Director. Requests for increases in primary orbits will be rare and will require strong scientific justification.
- Contesting a mandatory comment made by the TAC.
- Adding a target to a program. Reallocation of time among an already-approved list of targets (specified in the Phase I Proposal) is at the discretion of the PC or IS. The IS may also approve the substitution of a target that was specified in the Phase I Proposal for one that was not, provided the new target does not create a duplication with other approved observations, and the observation of the new target does not alter the original science goals of the program.
- Changing instruments or a significant change of instrument mode (such as from STIS/CCD to STIS/FUV or WFC3/IR to WFC3/UVIS).
- Adding limited-resource Special Requirements that were not indicated in the Phase I proposal. These include CVZ, TOO, SHADOW, ORIENT, and LOW SKY.
- Adding other options, parameters, or Special Requirements that substantially increase the constraints on scheduling a program.
- Any change that requires an observation to be made outside of the nominal start or end times of the Cycle for which it is approved, or any request by a PI to start a program before the start, or after the end, of the Cycle. Multi-year programs are, by definition, pre-approved to extend beyond a single Cycle boundary.
STScI’s concerns are twofold. First, we wish to understand whether a change significantly alters our ability to schedule an observation. An instrument change or the use of limitedresource Special Requirements may impact schedulability. Second, the Institute needs to ensure that a change will not go beyond the scope of the program originally proposed and will not infringe on the science of another program.
For those PCRs involving Bright Object Protection or other instrument technical issues, the relevant Instrument Team will be consulted and may provide a recommendation to the TTRB on the resolution of the PCR.
Late Change Requests
A Change Request to a program must reach STScI at least four weeks before the first day of the planning window for that proposal. If a Change Request is received after this date and the observations then fail because the change was not implemented, no repeat will be given. Even if STScI agrees to attempt a late implementation of a Change Request, it is done on a best-efforts basis and the PI is still responsible for the error if problems arise.
Resolution of Data Duplication (RDD) Procedures
An RDD is the mechanism for bringing a duplication to the attention of the TTRB. An observation is a duplication of another observation if it is on the same astronomical target or field, with the same instrument, with a similar instrument mode, similar sensitivity, similar spectral resolution and similar spectral range. Full policies regarding duplications are given in the most recent HST Call for Proposals.
Duplications are generally identified before execution, but in rare cases duplicated datasets may be obtained. In such cases the TTRB will adjudicate proprietary rights and data access, and may recommend that the duplicated data remain embargoed until the proprietary period on the original data expires, to protect the interests of the PI of the original data.
GOs are expected to investigate other current-cycle programs that may duplicate their own, and report any issues via an RDD.
"Telescope Time Review Board (TTRB) Policies: Repeating HST Observations, Changes to Accepted HST Programs, and Resolution of Duplications" by Denise Taylor and David Soderblom, update by Andrew Fox, August 5, 2021 (PDF)