Notes on Antenna Manager Position Handling

Introduction

This is a quick description of the processing performed in the GBT antenna manager to transform sky-based positions into observed az/el.

The GBT supports a number of command coordinate systems, outlined in the table below:

Name DescriptionSorted ascending
B1950 FK4 with a Besselian epoch of 1950.0, see note 1 and section 2.1 of GBT Astronomical Position Handling.
CableWrap/Encoder az/el like system, but in terms of the servo encoders. Used for stowing etc.
J2000 FK5 with an Julian epoch and mean equator of 2000.0
Galactic Galactic Coordinates
ApparentRaDec Geocentric apparent Ra/Dec
HaDec Geocentric Hour-angle/Declination
RaDecOfDate Same as JMEAN. Julian epoch at date specified by observer
AzEl Topocentric az/el

Coordinate conversions

The GBT antenna manager follows the coordinate conversion pipeline described by Wallace in the Starlink project's Sun/67. Richard also describes the pipeline in GBT Astronomical Position Handling.

The processing pipeline differs slightly for each coordinate system. The general method for J2000 is as follows:
  1. The routine SLA_MAPPA() is used to calculate a number of star-independent parameters to be used in converting a mean catalog position into geocentric apparent. The values for this routine are 2000.0 for the epoch of mean equinox, and the date/time of the scan midpoint.
  2. The routine SLA_MAPQKZ() is then used to convert J2000 ra/dec positions into geocentric ra/dec in real-time. This routine accounts for light deflection, annual abberration, and precession/nutation. (Parallax and proper motions are assumed to be zero in this routine.)
  3. The local apparent sidereal time is calculated, based on methods described in the Explanatory Supplement to the Astronomical Almanac, and examples from Rick Fisher.
  4. The geocentric ra/dec is converted to geocentric ha/dec by a rotation of the current sidereal time. (i.e. HA=LST-RA)
  5. The geocentric ha/dec is converted to a topocentric az/el position, by correcting for diurnal abberration, site location, and polar motion. The technique is identical to the relevant steps in the SLA_AOPQK() routine.
  6. The topocentric az/el position is then compensated for refraction using methods described in PTCS memo 35.2. The result is "Observed Az/El".

Variations for other coordinate modes is described below:
  • For B1950 coordinates, values are first converted to J2000 using SLA_FK45Z(), which assumes zero parallax, and zero proper motion. (Note: this step is missing in the code!)
  • For Galactic coordinates, values are first converted to J2000 using the SLA_GALEQ() routine.
  • For RaDecOfDate (i.e. JMEAN) the epoch specified by the user (e.g. 2002.234) is used instead of 2000.0, as input to the SLA_MAPPA() routine. (Note: I am not sure if this is correct. Perhaps SLA_PREC() should be used to convert to J2000 first? )

So in summary, the GBT code (with exceptions noted below) uses the following procedures to convert between coordinate systems:
Coordinate System Coordinate System Considers Starlink/SLALIB function
Galactic to J2000 rotation of axes SLA_GALEQ()
JMEAN, any epoch to J2000 precession SLA_PREC()
B1950 to J2000 FK4 to FK5, no proper motion or E-terms SLA_FK45Z(), note 1
J2000 to geocentric apparent light deflection, annual abberration, precession/nutation SLA_MAPPA(), SLA_MAPQKZ(), note 2, note 3
Geocentric/Apparent Ra/Dec geocentric Ha/Dec Earth rotation, site location TimeKeeper class, note 4
Geocentric Ha/Dec to topocentric az/el diurnal abberration, the geode and site elevation, polar motion derived from SLA_AOPQK()
Topocentric az/el to observed az/el refraction PTCS memo 35.2
Notes:
  1. When converting between FK4 and FK5 systems, proper motions and E-terms are considered to be zero. See also section 2.1 of GBT Astronomical Position Handling.
  2. The two functions SLA_MAPPA() and SLA_MAPQKZ() are complementary in that SLA_MAPPA() calculates a matrix of values which is saved and used repeatedly by the SLA_MAPQKZ() function. The matrix is updated once for each sub-scan. The time used is the midpoint time of the sub-scan.
  3. The SLA_MAPQKZ() assumes zero parallax and proper motion.
  4. The Timekeeper class was derived from a number of sources, including work by Rick Fisher (astrtime.cc), and packaged into a class which linerarly interpolates polar-motion, and DUT (UT1-UTC) throughout the course of a day. (Predicted values for these quantities are obtained from the IERS on a weekly basis.)

Offset Coordinates

The GBT has the option to specify a primary and offset command position in difference reference frames. The method in which this is processed is that the primary position is first transformed into the offset reference frame, the offset in then added in, and the result is then transformed into observed az/el. The methods used are the same as those used for coordinate conversion for primary to observed without an offset. An item of note is that when an offset is combined, it may optionally be divided by the cosine of the minor primary axis position.

User-defined Coordinates

Although not commonly used, users can specify a rotation matrix (optionally as a function of time) on top of the processing pipeline. The has been used to define a coordinate system to track asteroids and planets. The order of operations is to first transform the input position by the rotation matrix, then the normal processing steps are used to convert the result into observed az/el.

Implementation Differences Noted

As noted above I noted two possible implementation differences while reviewing the code and these documents. The first is that when the RaDecOfDate (i.e. JMEAN) system is used, coordinates are not precessed from the specified epoch into 2000.0, they are directly processed by the sla_mappa()/sla_mapqkz() by specifying the user-epoch and the current date (as opposed to specifying 2000.0 and the current date). I assume this is a minor detail. Certainly it doesn't affect pointing runs since the RaDecOfDate coordinate reference is not used in pointing runs. Is this an error?

The second difference is that B1950 positions are not transformed into J2000, they are mistakenly converted directly to geocentric apparent ra/dec. So in essence they are 'J1950'. I assume this should be fixed to first use the FK4 to FK5 conversion. Oddly enough, if a primary coordinate mode of B1950 is used with an offset coordinate mode of J2000, the correct FK4 to FK5 step is performed. Again, I doubt this affects pointing since J2000, not B1950 is most commonly used.

GBT Site Location

The current Geodetic values of the GBT site are (38.433121N, 79.839835W). The elevation axle has a height of 824.551 meters NAV (776.335m ellipsoid height) + 48.216m (height of elevation axle above the track). Frank Ghigo reported a refined position (from the "TIES" run in 2002, which linked the 20meter with the GBT) as 38.433129N, 79.839840W and 824.363 meters (above the ellipsoid)/855.46m (above the geoid). I am not sure of the impact of the difference, but the new data have not been integrated into the system.

  Latitude Longitude Height
Site Data Currently in use 38.433121N 79.839835W 824.551 meters, NAV 83
Site Data from TIES-2002 38.433129N 79.839840W 824.363 meters above ellipsoid, 855.46m above the geoid

-- JoeBrandt - 17 May 2007
Topic revision: r3 - 2007-05-18, JoeBrandt
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback