How do I best determine an observation's actual orientation?
When determination of position angles from HST images is critical, or in other
cases when accurate knowledge of HST orientation is important, users are advised
to perform the following check.
The science header keyword ORIENTAT is populated by adding the angle between the
HST V3 axis and the detector Y axis to what we will call the "commanded roll"
(North to V3 through East). The V3-detY angles that were relevant at a given
observation's epoch are given as a header keyword (beta_2) in the Observation Log
files (aka jitter files). The GO can obtain the observation logs by requesting them
from the archive.
The commanded roll can be determined by subtracting the beta_2 from ORIENTAT. If a
particular orientation was specified in the phase II (via ORIENT) this will be
equivalent to the commanded roll +180 by definition. Note that the science header
keyword PA_V3 is not equivalent to the commanded roll because PA_V3 is defined at
the V1 axis while the commanded roll and ORIENTAT are defined at the particular SI
aperture reference point. The science header keyword PA_APER is the commanded roll
plus the angle from V3 to a slit's Y axis, which may be slightly different than the
detector's Y axis. For long slit observations, this PA_APER can be of importance,
describing the position angle of the slit. But as mentioned these keywords are all
derived from some assumed "commanded roll", begging the question....
So how close is the actual orientation to the commanded?
Normally, in the absence of pointing or science header anomalies, the actual
initial roll achieved for a given HST observation is within ~0.003 degrees of
the commanded value. For context, the angle error that will put an object out of
the 52X0.1 STIS slit is 0.1 degrees (assuming an object centered at the slit
center and the other object at the end of the slit).
The GO should check the "_jif" jitter file's header keyword ROLL_AVG. This is
the angle from North to V3 measured at the aperture reference calculated by the
guidestars' locations in the FGSs. They should then check this value against the
c0h science header by performing the subtraction discussed in the first paragraph
to get the "commanded roll" assumed in the science data. The commanded roll and the
jitter file's ROLL_AVG should agree to within 0.05 degrees, usually better than
0.02deg. If this is the case, then the user should trust the science header's roll,
which when not affected by gross errors, is usually closer to what was actually
executed than the jitter file reports*. The commanded roll is used by the science
data processing to derive and populate the ORIENTAT, PA_APER and PA_V3 keywords,
as well as other keywords utilized by many STSDAS image measurement tasks.
If the two sources differ by ~0.05 deg or more, then the GO should contact us.
After some checks, we will usually be able to recommend a course of action:
1.) relying on the jitter file's measured roll if a problem is found either
with the science header population or with the execution of the commanded roll.
2.) dismissing the jitter file's roll calculation due to problems with it* and
verifying the science header roll.
See our "pointing calculations and sources of error" discussion for more details
of orientation, pointing, and the jitter files.
Also, for the current values of the aperture parameters, see the SI Aperture File page.
*There is always some zero point error in the jitter file's roll calculation
due to FGS misalignments and GSC catalog error. This will typically give 0.01
or 0.02 degree error in the jitter file's calculation. However depending on
the case specifics like geometry, spoiler or binary guidestars, FGS interferometric
anomalies such as false locks, or unusually high GSC catalog error, the jitter
file roll may occasionally be a good deal higher, perhaps close to 0.1 deg.
We can usually assess these errors from other clues in the jitter file.