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.
