Introduction

HST is able to point at and track solar system targets with sub-arcsecond accuracy. In order for target acquisition and tracking to succeed, planetary observers must specify positions for their targets in a precise and unambiguous manner. Therefore, it is imperative that the Solar System Target List (SSTL) be carefully and correctly completed. This section explains how to fill out the SSTL for any solar system target.

Ephemerides are generated using fundamental ephemeris information from NASA’s Jet Propulsion Laboratory (JPL). Ephemerides can be generated for all known types of solar system targets, including planets, satellites, comets, asteroids, surface features on planets and satellites, and offset positions with respect to the centers of all the above bodies. The following instructions demonstrate how to define solar system targets in a way that allows accurate ephemeris generation.

The body-axes definitions, body dimensions, directions of rotation poles, rotation rates, and the definitions of cartographic coordinates used by STScI are normally identical to the values adopted in the report of the “IAU Working Group on Cartographic Coordinates and Rotational Elements of the Planets and Satellites: 1982” (Davies, M.E., et al., Celestial Mechanics, 29, 309-321, 1983). In a few instances, the latter data have been updated due to new results obtained from the flyby spacecraft. Also, some new bodies have been added which were unknown at the time of the IAU report. For Jupiter and Saturn, the lambda(III) coordinate system is assumed, but lambda(I) or lambda(II) can be used. For Uranus and Neptune, coordinates follow the “Report of the IAU/IAG/COSPAR Working Group on Cartographic Coordinates and Rotation Rates of the Planets and Satellites” (Celestial Mechanics and Dynamic Astronomy, 46, 197, 1989). If you need further information on these, please contact your Program Coordinator.

One exception exists to the requirements outlined above. Observers for solar system Targets of Opportunity (e.g., a “new” comet or asteroid, a solar-wind disturbance reaching the Jovian magnetosphere, etc.), should complete the Generic Target List and the Visit and Exposure Specifications (to the extent possible) in time for the Phase II deadline. If and when a suitable target appears, the proposer must complete the Solar System Target List and update the Visit and Exposure Specifications. No target can be observed until the complete Phase II information is provided.

There are new rules introduced in 2020 that govern orbital visibility for Moving Targets. See explanation in the Special Requirement VISIBILITY INTERVAL NO GYRO BIAS UPDATE ON MOVING TARGET.

In this article, each heading has a description followed by a keyword in square brackets (e.g., [Target_Number]).

Target Identification

The following information is required to identify and classify each target.

Target Number [Target_Number]

Each target in your program will be assigned its own unique number (which can be changed by the user) by APT (they are base 10 and go from 1 to 999). Target numbers must be positive, monotonically increasing integers. You should define a different target whenever a different target position or timing description is required. For example, separate targets should be defined if you plan to take spectra of several different surface features on a planet, or if you plan to observe the same feature with different timing constraints.

Target Name [Target_Name]

The name is used to identify a target; all target names within a proposal must be unique. The target name can be selected from the STScI list of standard targets (see the list in 3.2.1 Solar System Standard Targets; explanations of “Level 1” and “Level 2” are given below), or a name can be defined by the GO. The use of standard names is encouraged whenever possible.

The following conventions should be followed in naming targets:

• The length of a target name can be anywhere from 2 to 31 characters.
• No blanks are permitted in target names. A hyphen should replace blanks that would normally be used to separate fields (e.g. IO-TORUS, COMET-BRADFIELD-1979X).
• Only letters and numerals are allowed in target names; punctuation (other than hyphens and + or –) is not permitted.
• Construct target names so they make sense for your observing program. For example, if your program consisted of consecutive observations of three surface features on Mars, then three appropriate target names might be: MARS-FEATURE1, MARS-FEATURE2, and MARS-FEATURE3.

Do not use just a standard name for a target when a specific portion of a body is being observed. For example, do not use “Saturn” as the target name for a feature or specific location that is defined relative to the position of Saturn as a standard target because this is confusing for the software that computes the positions of moving targets.

Target Description [Description]

The target description is used to sort the solar system targets by class and will be useful to archival researchers. The first word in any target description must be one of the keywords listed below. The keyword is then followed with text that depends on the target class as described below.

Table 3.14: Target Description Keywords

Target Extent [Extended] for COS Observations Only

This field is required for COS observations only. Both COS FUV and NUV observations of targets with FWHM larger than about 0.6 arcsec or radius larger than 0.35 arcsec should be considered as extended. “YES” should be selected for such targets and “NO” for targets of smaller angular extent. The field should be left blank if the target is not being observed by COS.

This definition is intended to provide an indication of whether or not the source extent might be large enough to affect the reliability of the default pipeline extraction algorithm. See COS ISR 2015-03 and Section 5.9 of the COS Instrument Handbook for further details.There are a number of other issues that should be considered when observing extended targets with COS, including the effects on spectral resolution and target acquisition. Please note that the exposure-level parameter EXTENDED has been deprecated and should not be selected for any Cycle 23 proposals or beyond.

Pointing HST - Target Position

The following information is required to properly point HST at your target.

Target Pointing Specification (TPS) and Levels

Three fields are used to describe the target’s position, referred to here as the Target Pointing Specification (TPS). The TPS has been defined using a hierarchical structure.

• "Target Position Level 1 [Level_1]"refers to a target in orbit about the Sun. Examples of Level 1 targets include planets, asteroids, and comets. When a Level 1 object is the desired target for observation, complete the Level 1 field and leave the other two target position fields blank.
• "Target Position Level 2 [Level_2]" refers to a target whose motion is normally described with respect to a Level 1 object. Examples of Level 2 targets include planetary satellites, surface features on planets or asteroids, and non-nuclear positions in the coma of a comet. When a Level 2 object is the desired target for observations, the Level 1 field contains information on the parent body, and the Level 2 field gives positions relative to this body. In this case, leave the Level 3 field blank.
• "Target Position Level 3 [Level_3]" refers to a target whose motion is normally described with respect to a Level 2 object. Examples are a surface feature on a planetary satellite or a pointing which is offset from the center of a planetary satellite. When a Level 3 object is the desired target for observation, then all three fields must be completed, with Level 1 giving the parent of the body described in Level 2, and Level 3 giving the position of the observed target with respect to the body in Level 2.

No more than three levels are allowed. If you believe that your target cannot be described in this form, contact your Program Coordinator.

Describing Targets

The targets specified in the target position fields can be described in up to four ways:

• By a name selected from a list of targets
• By orbital elements
• By coordinates with respect to another object
• Via target selection during a real-time observing session

Table 3.15 in Solar System Standard Targets gives the list of valid names for solar system targets. PIs are responsible for obtaining up-to-date orbital elements for bodies not in this table. Objects must be denoted by their IAU-adopted name. A good reference for object names can be found in the Astronomical Almanac, and in the Marsden comet catalog (Marsden, B. G., Catalog of Cometary Orbits, Enslow Publishers, Hillside, NJ, 1983). The Minor Body Name Resolver and Orbital Ephemeris Retriever may also be helpful. If you are uncertain whether or not your target can be referenced by name, contact your Program Coordinator.

In those cases where the target’s position is given with respect to one of the standard targets, the latest available data from JPL on the bodies’ physical dimensions, orientation, and rotation rates are used in calculating the target’s position. In those cases where all or part of the TPS for your target can be described using standard names, we strongly recommend that you do so. Generally, this will result in the most accurate ephemeris generation for your target.

Minor Body Name Resolver and Orbital Ephemeris Retriever

When specifying an asteroid or a comet as the target, APT provides an option to resolve the target name and download the orbital elements directly from the JPL Horizons system. Using this APT capability to communicate directly with Horizons avoids possible copy and paste errors.

Alternatively, the user may manually enter the target name and the orbital elements. In all cases, the observer retains the responsibility for the correctness of the orbital elements regardless of the source from which they are obtained.

Specifying Time

Wherever there is an entry involving time, the format for that entry must be:

DD-MMM-YYYY:hh:mm:ss.s,

where DD is the day of the month, MMM is the first three letters of the month name, YYYY are the full four digits of the Gregorian calendar year, hh is the hour, mm is the minute, and ss.s are the decimal seconds. Only the necessary precision need be specified. But the time after the colon must be completely specified or not at all.

Examples:

02-AUG-1993:13:04:31

15-JAN-1994

Two different systems of time are used in this document. TDB refers to Barycentric Dynamical Time and can be considered synonymous with ET (Ephemeris Time), which was used before 1984. UTC refers to Coordinated Universal Time. The precise interpretation of each time value depends on the context in which it is used.

Ephemeris Center [Ephem_Center]

Used to support HST observations of the Moon and other close moving targets closer than 3.8 million kilometers. Ephemeris Center must have one of two possible values: EARTH or HUBBLE.

EARTH (default)

A geocentric target ephemeris is computed and provided to HST. HST’s on-board software then computes a correction for the parallax induced by the telescope’s orbit. This is the default method and will work for most cases. However, HST’s on-board parallax correction may be insufficient for a target closer than 3.8 million kilometers.

HUBBLE

An HST-centric target ephemeris is generated. In this case, no parallax correction is needed and none is performed. However, due to uncertainties in HST’s own ephemeris, an HST-centric target ephemeris will have sufficient accuracy for only about 4 weeks into the future. An HST-centric ephemeris should be specified only for very close targets such as the Moon.

Ephemeris Uncertainty [Ephem_Uncert]

The <value> for ephemeris uncertainty is the distance along its trajectory that the target is expected to be from its ephemeris position, in kilometers (KM), or seconds of time (S). The latter reflects the fact that in general, the least well known parameter in an ephemeris is the perihelion time. This parameter is required for any moving target used in an exposure with the REQuires EPHEMeris CORRection Special  Requirement.

A realistic estimate of ephemeris uncertainty is needed to schedule the time necessary to repoint the telescope to the improved position when it is known. It will not be possible for STScI to apply a correction larger than the specified uncertainty.

Acquisition Uncertainty [Acq_Uncert]

The <value> for acquisition uncertainty is the uncertainty in the position of the target in a direction perpendicular to the line of sight, in kilometers (KM) or arcsec (").

A realistic estimate of ephemeris uncertainty is needed to schedule the time necessary to repoint the telescope to the improved position when it is known. It will not be possible for STScI to apply a correction larger than the specified uncertainty.

Observing Windows [Windows]

The observability of solar system targets is often constrained by various geometrical conditions (e.g. satellites observed at greatest elongation from their parent planet), or the desirability of coordinated observations (e.g. the observation of a planetary system at the same time as a spacecraft encounter with the system). The Window field is provided to allow the proposer to define geometric and timing constraints. The proposer should specify any constraints necessary to achieve the scientific objectives of the programs. However, care should be taken in specifying constraints, since they can render the observations difficult or impossible to schedule.

Flux Data [Flux and Other_Fluxes]

Flux information must be provided for all targets, and there can be more than one entry for a given target. STScI uses flux information to check for over-illumination of sensitive detectors. All entries are values as observed at the Earth, rather than intrinsic values.

COS, ACS/SBC and STIS/MAMA proposals cannot be implemented without flux information for all targets because of the critical requirements to protect the detectors from damage by excessively bright objects. Note that all objects in the field need to be checked, and there is a Bright Object Tool in APT to support that checking.

The flux information is provided in two separate fields:

• Flux in V Magnitude with an uncertainty. This is required for targets observed by the FGS, STIS/FUV-MAMA, STIS/NUV-MAMA, COS and ACS/SBC. For all other instrument configurations, it’s optional.
• Other Fluxes (separated by commas), which is entered in free text.

In the “Other Fluxes” field, the spectral type and reddening could be provided if you think it’s important. As many additional flux values as appropriate for the requested exposures should be provided. For example, ultraviolet or emission-line fluxes should be given if the target is to be observed in the ultraviolet or through a narrow-band filter, or several magnitudes might be provided if the target is a variable star to be observed at various brightness levels. In some cases (Targets of Opportunity, variable objects, etc.) the estimated flux data may be very uncertain, but the best available estimates should nevertheless be given, along with appropriate uncertainties and comments.

It may be important to specify the flux of a background source as well as the target flux. For example, a globular cluster in M87 may be seen against the bright background of the galaxy. The suffix –BKG should be appended to a background flux specification in this case (e.g. SURF-BKG(B) = 20 +/– 0.2 mag/arcsec2). Use a comma to separate entries if more than one flux value is given.

General Guidelines on What Flux Data to Include

The following summary provides general guidelines for what flux information could be included in three general areas.

Target Flux

1. Magnitudes: V magnitude (point source), V surface brightness (extended source), or J magnitude (IR source).
2. Flux: flux at specified wavelength.
3. Color: B-V, U-B, J-K, etc.
4. Reddening: E(B-V). If no entry for E(B-V) is given, E(B-V) = 0 will be assumed.
5. Spectral type (point source).

Background Flux

1. Non-dispersive spectral element: Broad-band surface brightness or surface brightness at specified wavelength; BKG must be specified in the name of the flux parameter. For IR sources, this refers to the astronomical background and not the thermal background.
2. Dispersive spectral element: Surface brightness of continuum; -BKG must be specified in the name of the flux parameter. For IR sources, this refers to the astronomical background and not the thermal background.

Surface Flux

1. Non-dispersive  spectral  element:  Flux  (point  source)  or  surface  flux (extended source) in wavelength range of observation.
2. Dispersive spectral element: Continuum (point source) or surface (extended source) flux at wavelength of observation and size of the region specified,
   or
   Line flux (point source), line surface flux (extended source), and line width of brightest emission line in the wavelength range of observation.

Details of how the above flux information was derived should be given in the Observing Description or Target Comment, as appropriate. If any of the required flux data cannot be provided or are deemed to be unnecessary, these points must also be explained in that section. Incomplete flux information may delay the implementation of your proposal, especially in the case of ACS/SBC, COS and STIS/MAMA observations.

Comments [Comments]

This field should include in words what you are trying to define by coordinates and windows in the other fields. For example, for Target No. 3 on the sample form the TPS and Window fields define mathematically the location of the target and the valid observation times, but the Comments field is probably much more useful in helping an observation planner determine the proposer’s objectives.

Examples of Target List Blocks

The sample targets defined in this section are provided as examples of completed forms using the syntax described in these instructions. This collection does not provide an example for every type of keyword but does give a good overall representation of the types of target selections that can be accommodated. Numerical data in these examples is fictional.

• Example 1: In this example the proposer wants to perform spectroscopy of a volcano on Io. The position of the target is given in planetographic coordinates. The proposer also wants to observe the target when it lies close to the central meridian and, thus, uses CML to specify the allowable range of the central meridian longitude.

  Target_Number:	1
  Name:	IO-VOLCANO
  Description:	FEATURE IO
  Level_1:	STD = JUPITER
  Level_2:	STD = IO
  Level_3:	TYPE = PGRAPHIC, LONG = 310, LAT = 13
  Window:	CML OF IO FROM EARTH BETWEEN 280 340
  Flux:	SURF(V) = 5 +/– 0.5, SURF-CONT(2300) = 5.2 +/– 0.2 E–14, SIZE = 1.0
  Comments:	Observe IO volcano Loki when it is near the central meridian.

• Example 2: In this example the proposer wants to perform spectroscopy of the western ansa of the Io torus when Io is near greatest eastern elongation. The elongation condition is specified using the OLG keyword.

  Target_Number:	1
  Name:	IO-TORUS
  Description:	TORUS JUPITER
  Level_1:	STD = JUPITER
  Level_2:	TYPE = TORUS, LONG = 90, LAT = 0, RAD = 4.3E5
  Window:	OLG OF IO BETWEEN 90 100
  Flux:	SURF-LINE(1304) = 1 +/– 0.5E–13, W-LINE(1304) = 2 +/– 1, SIZE = 1
  Comments:	West ansa of IO Torus when IO is at greatest eastern elongation.

• Example 3: In this example the proposer wants to perform spectroscopy in the tail of comet Halley near the time of the Giotto spacecraft encounter. The latest orbital elements for the comet have been supplied by the proposer and these will be used for the ephemeris generation. The POS_ANGLE target reference system is used to specify the tailward pointing.

  Target_Number:	3
  Name:	COMET-HALLEY-TAIL
  Description:	OFFSET COMET HALLEY
  Level_1:	TYPE = COMET, Q = 0.5871167, E = 0.9672815, I = 162.2397156, O = 58.144397, W = 111.8489075, T = 09-FEB-86:11:01:04, EPOCH = 01-MAR-86, EQUINOX=B1950
  Level_2:	TYPE = POS_ANGLE, RAD = 30, ANG = 180, REF = SUN
  Flux:	SURF(V) = 12 +/– 1, SURF-LINE(1216) = 3.1 +/– 0.5E10, W-LINE(1216) = 0.1 +/– 0.5, SIZE = 1
  Comments:	30 arcsec into tail of Halley during Giotto encounter. New orbital elements based on recent observations are provided.

Related Links

3.1 Fixed Targets
3.3 Generic Targets

Change Log