6.1 Conventions for Special Requirements

Special Requirements (e.g., BETWEEN, POS TARG) are generally used to restrict the scheduling of HST observations by various constraints. The Astronomer's Proposal Tool (APT) is used to enter the requirements into the proposal, using specific rules and conventions.

Expand/Collapse all...


On This Page

Format definitions

Boldface type indicates the name of an APT parameter or a value for a parameter.

(red star) Black text indicates an important note.

Magenta text indicates available but unsupported parameters (requires prior approval from STScI).

Red text indicates restricted parameters (for STScI use only).

Brown text indicates text file parameters.

Items in brackets - <value> - are required values.

Items in square brackets - [<value>] - are optional.

Introduction to Special Requirements: Syntax and Rules

Special requirements provide flexibility in specifying the scheduling requirements of observations. Many Special Requirements, directly or indirectly, restrict the times when observations can be scheduled. These should be used to provide the schedulers at STScI with enough constraints to ensure that the observations are properly scheduled. Special Requirements should not be used unless necessary to accomplish the scientific objectives of the program.

The Special Requirements are summarized in Supposed Formats for Visit-level Special Requirements and Supposed Formats for Exposure-level Special Requirements tables, and a detailed description of each requirement is provided.

Rules and Conventions

You should observe the following conventions and rules for Special Requirements:

  • Items inside angular brackets (< >) in the Special Requirement descriptions are to be replaced with the relevant information. All indicated items must be provided, except for items inside square brackets ([ ]), which are optional.
  • A <date> specification in a Special Requirement must either be a geocentric date expressed in Universal Time (UT) or a heliocentric Julian Date. A UT date must be entered in the form DD-MMM-YYYY:hh:mm:ss, where MMM represents the first three letters of the month name. Fractional seconds are not allowed and anything beyond the day specification is optional. For example, 14-DEC-2001:17:05:41 refers to 14 December 2001, geocentric UT 17H05M41S. Only the necessary precision need be employed (e.g., 14-DEC-2001 might be adequate). The SOGS day of the year format, YYYY.ddd:hh:mm:ss (where ddd is the day of the year from 001 to 365), is also accepted.

Julian Dates must be entered in the form JDnnnnnnn.nnn (e.g., JD2444123.4) and are legal only for the ZERO-PHASE special requirement. All Julian Dates will be interpreted as heliocentric.

  • You should select the units of all <time> specifications from a list provided to you. The options are: days (D), orbits (ORBITS), hours (H), minutes (M), or seconds (S).
  • A visit-level Special Requirement (Visit_Requirements) applies to ALL the exposures within that visit.
  • An exposure-level Special Requirement (Special_Requirements) applies ONLY to that exposure and any other referenced exposures within the same visit.

For text file

Additional Rules and Conventions for the Text Proposal File

If you are editing the Text Proposal File to modify your program, please observe these additional syntax rules:

  • Exposures must be referred to by their exposure numbers. <exposure> must be replaced by the number of a single exposure. An <exposure-list> must be replaced by a single range of exposure numbers separated by a hyphen (e.g. SEQ 2-5 NON-INT). Commas are NOT allowed in exposure lists.
  • Multiple Special Requirements must be separated by a semi-colon (;). Please note that separate lines are not sufficient to delimit items in a list. Do not use commas to separate Special Requirements items.

Expand/Collapse all...




Table of Contents


Change Log

None