STScI Logo

Hubble Space Telescope
Use of ORIENT, PATTERN-ORIENT, and POS TARG

Observational Use of ORIENT, PATTERN-ORIENT, and POS TARG Requirements

May 20, 1997

There is much confusion about the use and interaction of the ORIENT
visit-level special requirement, the PATTERN-ORIENT exposure-level
optional parameter, and the POSition TARGet exposure-level special
requirement. This advisory is intended to clarify the use and
relationship between these requirements. Observers who use the
PATTERN-ORIENT and POS TARG requirements on the same exposure should
be aware that there is a bug in RPS2, that executes the latter in 
the frame of the former. This bug should be fixed in the next release
of RPS2, so these observers can either use version 7.1.1 when it
comes out in June, or rely on STScI to reprocess with the updated
software. POS TARGs will be done in the frame of the detector.

Observers should note that the RPS2 description generator has an
"FOV Tool" which can be of use in interpreting what the system will
do with your observations. The tool draws a scaled picture with a
coordinate system indicated, for each exposure which uses a PATTERN.
The numbers indicate the center of the fields of view in a pattern,
as well as their order in the sequence of the pattern. These are
circumscribed either by a square (if the orientation of the camera
is known in the given coordinate system) or a circle (which shows
the union of the possible orientations of the camera in use, if the
it is not constrained).

One source of confusion is due to the different philosophies used
in defining the PATTERN and POS TARG requirements. The former moves
the field of view (FOV) of the camera on the sky, while the latter moves
the sky in the field of view of the camera. Thus a pattern move of the
FOV in +X and +Y direction is equivalent to a POSition TARGet in the -X,
-Y direction. This is demonstrated on pages 148-151 of the NICMOS
instrument handbook. Observers using a combination of these parameters
should double-check to make sure they are getting what they want. It is
best to describe what is wanted in a comment as well.

The interaction between ORIENT and PATTERN-ORIENT is not always clear.
The default for PATTERN-ORIENT is DETECTOR, so that the dithering
and/or chopping patterns are done in the row/column frame of the camera.
If no ORIENT is specified as well, the positions of the second and sub-
sequent positions on the sky are arbitrary, and depend on when the
observations are scheduled (called the "nominal roll" at a given time).
Specifying an ORIENT (but not a PATTERN-ORIENT) will constrain where
the offset fields are on the sky, as well as the directions of the
rows and columns of the detectors on the sky, but will also constrain
the time the observations can be scheduled. Thus use of ORIENT is
strongly discouraged. PATTERN-ORIENT is the recommended flexible alter-
native if the position of the offset fields on the sky must be defined.
While it constrains the position of the offset observations, it does
not constrain the orientation of the telescope and hence the direction
of the camera rows and columns with respect to the sky.

Note that PATTERN-ORIENT=0 is not the same as the default (PATTERN-
ORIENT=DETECTOR)! Non-default values of PATTERN-ORIENT can lead to odd
amounts of overlap among adjacent fields in the pattern. The detector
rows and columns may not be parallel or perpendicular to the pattern
offset motions if a non-default PATTERN-ORIENT is used.

To clarify, the PATTERN-ORIENT requirement specifies the orientation,
North through East on the sky, of the +Y direction of the PATTERN. This
is different from the +Y direction of the camera if PATTERN-ORIENT is
not the default. For example, using the XSTRIP-DITH pattern with PATTERN-
ORIENT=0 will move the FOV from East to West on the sky, while PATTERN-
ORIENT=45 will move the FOV from Southeast to Northwest, regardless of
which way the detector Y (column) axis is pointing. YSTRIP-DITH 
with PATTERN-ORIENT=0 will track from South to North. Note that the
example in the NICMOS handbook p. 152 has this backwards.

Thus if you just want to map an unconnected series of fields (e.g. for
background measurements) you probably only need to specify PATTERN-
ORIENT. If you are mapping a series of contiguous fields, however, and
want to have a specific overlap between adjacent images, you may have
to use the ORIENT requirement. You can improve the schedulability of 
the observations by using PATTERN-ORIENT instead, and CHOP- and DITH-
SIZE chosen so that the distance between adjacent field centers is
0.5sqrt(2) times the camera dimension. This will cover the whole area
at least once, and much of it twice. Note that the SPIRAL-DITH pattern
is symmetric and should rarely require an ORIENT, and should only need
a PATTERN-ORIENT if you are using a SPIRAL-DITH-CHOP pattern.

Whatever you are doing, you are strongly urged to document it with a
comment.