Guide to Observing the Planets with the VLA

Bryan Butler (bbutler@nrao.edu)

INTRODUCTION

When preparing to do observations of solar system objects with the VLA (sun, planets, asteroids, comets, etc...), special care must be taken in the construction of the OBSERVE file. This is the file read by the on-line system at the VLA site, and used to actually control the operation of the array. The lines in the OBSERVE file contain information on where to point the telescopes, what frequency to tune the array to, what bandwidth/channelwidth to use, and other necessary information. Each of the lines in the OBSERVE file are referred to as "cards", for obvious historical reasons. A typical OBSERVE file will contain instructions to observe one or more target sources, interspersed with observations of one or more calibrators. Each of these separate source scans is denoted by a source card in the OBSERVE file. Each source card may then be followed by several modifying cards, including the Local Oscillators card (LO card), the Fine Tuning card (FI card) and the Data Select card (DS card). See Jim Nieri and Ken Sowinski's writeup SYSTEM FILES/OBSERVE FILE SOURCE CARDS (OFSC) for more detail. For objects which move appreciably in right ascension (RA) and declination (DEC) during a source scan, an additional modifying card is necessary, the Planetary Motion card (PM card). This card contains information regarding the rates of movement in RA and DEC, the time when the position specified in the source card is correct, and the distance to the object of interest. Specifically, the PM card has the following format (from the OFSC):

     COLS  1-4   '//PM' identifies the card as a PM card.
     COLS 11-20  F10.0  dRA/dt, in seconds of time per day.
     COLS 21-30  F10.0  dDEC/dt, in seconds of arc per day.
     COLS 32-33  I2     hours of IAT time.
     COLS 35-36  I2     minutes of IAT time.
     COLS 38-39  I2     seconds of IAT time.
     COLS 41-50  F10.0  Equatorial Horizontal Parallax (EHP) in 
		        seconds of arc.

So, a source card with it's modifying PM card might look like:

MARS        1 18 02 00 19 04 20.2316 -23 39 23.033D    XX       0000
//PM        201.2071   293.989 19 18 18      3.795

(for an X-band continuum [50 MHz] observation of Mars on Dec. 19, 1995). The positions, rates, and distance (the distance is: D = 8.794148 / EHP, see e.g., p. E43 of the Astronomical Almanac) must be obtained from some accurate ephemeris source (see later).

The standard way of producing an OBSERVE file is currently through the jobserve program (or, it's deprecated ancestor, observe). jobserve nominally supports the use of PM cards, but has no mechanism for reading in an ephemeris file, and just produces a template PM card for each source for which one is desired. The actual numbers for both the planetary position (on the source card) and the rates and distance (on the PM card) must then be typed in by hand (or via some other automated procedure). For this reason, those of us who commonly observe solar system bodies have each developed our own software to create the appropriate OBSERVE file for each observing run. The solar radio community has come up with its own VLA scheduling tool, called SOLOBS.

TYPE OF EPHEMERIS NEEDED

An accurate ephemeris is mandatory, in order to calculate the positions and rates of the planets, or other solar system bodies. The positions needed in this ephemeris are different for different specifications of the epoch in the source card. The epoch is specified in column 51, and has four possible values:

     blank -> standard equinox of 1950.0 (B1950)
         D -> apparent position of date
         Y -> standard equinox of year in columns 52-55
         C -> standard equinox of 2000.0 (J2000)

In the above example for Mars, column 51 is 'D', indicating that the position supplied in the PM card is an apparent position of date.

There are several possible corrections which the on-line system may make to the positions supplied on the source card and the rates supplied on the PM card, to turn the supplied positions and rates into actual coordinates at which to point the antennas and phase center as a function of time:

• Precession
• Nutation
• Parallax terms
• Diurnal parallax
• Annual parallax
• Aberration terms (often called planetary aberration)
• Light-time
• Stellar aberration
• Diurnal aberration
• Annual aberration
• Gravitational deflection term
• Polar motion term
• Refraction

Because the diurnal aberration and parallax terms are always calculated and applied, geocentric positions should always be supplied on the source card. Because of the inconsistency in the way the precession and nutation are applied to the positions and rates, I also strongly recommend that positions and rates of date be used.

A fantastic source for ephemerides for solar system bodies is the JPL Horizons website. Select the proper object, in the "Observer Location" section, use Code 500 (for geocentric positions), select the proper time range in the "Time Span" section, and select elements 2 and 20 in the "Output Quantities and Format" section (they're the only ones you'll need). If you are doing spectral line observations, you'll also need a topocentric ephemeris for the velocities - use all the same selections as above, but use observing location Code -5 (for the VLA) in the "Observer Location" section.

OBSERVATIONS OF SPECTRAL LINES

When doing observations of a spectral line, accurate velocity information is also needed in the ephemeris. The type of velocity needed depends upon what the on-line system is told to do in the FI card. See A Guide for VLA Spectral Line Observers, or the OFSC for details. The FI card has the following format (from the OFSC, and an email from Ken Sowinski dated July 25, 1994):

     COLS  1-4   '//FI' identifies the card as a FI card.
     COL     5   synthesizer setting code, with possible values:
	         'N' -> set the Flukes to the same frequency they 
		        were at for the last scan
	         'R' -> set A, B, C & D frequencies to 100, 200,
		        -250, & -150.
	         ' ' -> same as 'R'
	         'C' -> set A, B, C & D frequencies to:
		         100 + (50 - BW)/2, 200 + (50 - BW)/2,
		         -250 + (50 - BW)/2, -150 + (50 - BW)/2,
		        where BW is the bandwidth.
	         'S' -> interpret following fields to find frequencies
	         Note that if column 5 is anything other than 'S',
	         then the following columns/fields are all ignored.
     COL     6   frequency/velocity switch, telling how the Fluke 
	         frequencies are calculated, with possible values:
	         'F' -> absolute Fluke frequency
	         'O' -> rest frequency and frequency offset will be 
	                supplied, both in MHz
	         'V' -> rest frequency will be supplied in MHz, and 
		        velocity offset will be supplied in km/s,
		        to be applied using the "radio" convention
	         'Z' -> rest frequency will be supplied in MHz, and 
		        velocity offset will be supplied in km/s,
		        to be applied using the "optical" convention
	         anything else -> same as 'F'
     COL     7   frequency centering switch, with possible values:
	         'T' -> the sky frequency arrived at in all cases is
		        to be assigned to the center of the band
	         anything else -> the sky frequency arrived at in all 
		        cases is to be assigned to the DC edge of the
		        band
     COL     8   rest frame for DOPSET calculations, with possible
	         values:
	         'T' -> restframe is topocentric
	         'G' -> restframe is geocentric
	         'B' -> restframe is barycentric
	         'L' -> restframe is LSR
	         anything else -> same as 'T'
     COL     9   LO tracking switch, with possible values:
	         'T' -> track LO every 10 seconds
	         anything else -> don't track LO's
	         [THIS IS NOT CURRENTLY IMPLEMENTED!!! 3/13/96]
     COL    10   fluke set select, 1 or 2.  [FOR OPERATOR USE ONLY!!!]
     COL    16   BD IF frequency/velocity switch.  If this column is
	         blank, then column 6 applies to both the AC and BD
	         IF pairs.  If this column is not blank ('F', 'O',
	         'V', or 'Z'), then column 6 applies only to the AC
	         pair, and the value from this column (16) is used
	         for the BD pair.
     COLS 17-30  Fluke A frequency/velocity (MHz or km/s)
     COLS 37-50  Fluke B frequency/velocity (MHz or km/s)
     COLS 51-65  Fluke A line rest frequency (MHz)
     COLS 66-80  Fluke B line rest frequency (MHz)

So, there are several options for specifying the frequency/velocity switch (column 6) and the restframe (column 8), which determine what type of velocity ephemeris is needed. The following is a guide:

    f/v switch value          frequency
	'F'                    nu = nu_A/B
	'O'                    nu = nu_rest + nu_o
     'V' or 'Z'                nu = nu_rest + nu_v/z + nu_DOPSET

     restframe    motions accounted for in calculating nu_DOPSET
	'T'                   none (nu_DOPSET = 0.0)
        'G'                       Earth rotation
	'B'                  Earth rotation and orbit
	'L'                     all Earth motions

FAST SWITCHING

The fast-switching mode, useful for high frequency observations in many cases (see VLA scientific memos 169 and 173), will not work with a PM card. This is because as soon as the system switches to the "other" source, all information on the rates is lost. There is currently a test version of the on-line system to get around this restriction, but it is still being tested, and is not recommended for general users. For more information on this test mode, contact me (bbutler@nrao.edu) or Ken Sowinski (ksowinsk@nrao.edu).

SOLAR OBSERVATIONS

Observations of the Sun require special care when preparing the OBSERVE file. Please contact Tim Bastian at NRAO (tbastian@nrao.edu) for help in setting up such files. There is a guide for the brave.

HOW THE ON-LINE SYSTEM REALLY CALCULATES THE POSITIONS, AND WHAT IS RECORDED ON THE ARCHIVE TAPE

Given the position and the rates for a scan, the on-line system first calculates the position at previous IAT midnight. Then, at each 10 second interval during the scan, the system knows the elapsed time since IAT midnight, and uses that time, applied to the rates, to calculate the offsets to apply to the midnight position to get the correct position at that time. These positions are then corrected for diurnal parallax and diurnal aberration. (Note: this may be changed soon, so that the midnight position is no longer used, and the default position and time will be those specified on the source card and PM card... 3/13/96, bjb) The rates supplied on the PM card are linear, and there will therefore be some amount of error in the calculated positions for all times other than the exact time specified in the PM card. This error obviously depends on the size of the second (and higher) order terms in the RA and DEC motion. Scan durations should therefore be limited to a length of time over which this error is small. Because of this consideration, I recommend supplying an IAT time on the PM card which is near the center time of the scan. This usually minimizes the maximum position error in the scan.

More detail:

What is called "Apparent RA now (Radians)" and "Apparent Dec now (Radians)" in the archive literature [section 2.2 on the SDA - Subarray Data Area] are the exact topocentric positions which are calculated at each 10 second tick by the on-line system. These "exact" positions are calculated given the exact geocentric position, the time, and the rates (on the source and //PM cards). The time at which it was calculated (the previous 10 second tick time) is supposed to be recorded in "IAT for Geometry Calculations (Radians)" (but see comments below on why this is not quite true).

Anyway, at each 10 s. tick, the online system calculates "exact" topocentric coordinates: alpha_t0 = T(alpha_0 + alphadot * deltat0) dec_t0 = T(dec_0 + decdot * deltat0) where alpha_t0 and dec_t0 are the topocentric positions (written to the archive tape), alpha_0 and dec_0 are the midnight positions (found from running the supplied positions on the source card back to midnight, given the time on the //PM card), and deltat0 is the elapsed time since midnight. T() is the topocentric position, so for this to be exact, you want alpha_0, alphadot, dec_0, and decdot to be geocentric. Now, for times after the 10 s. tick, and previous to the next 10 s. tick, topocentric positions are effectively calculated via: alpha_t = alpha_t0 + alphadot * deltat dec_t = dec_t0 + decdot * deltat where deltat is the elapsed time from the 10 s. tick to the center of the integration time (actually, it is more complicated for integrations > 10 s.), and alphadot and decdot are exactly as above. So, for this to be exact, you want alphadot and decdot to be topocentric - which is inconsistent with above, where you wanted them to be geocentric.

It appears that there is no way to extract the rates (alphadot and decdot) from the information on the archive tape. This is because the positions which are recorded on the tape are "exact" topocentric, so if they are used to derive the rates, what will come out will be the exact topocentric rates, which probably won't be what was specified on the source card (because you want the "exact" coordinates at the 10 s. tick intervals to be right, you should specify geocentric rates).

So, the only way to get the exact phase center position for each integration is to either have the OBSERVE file (from which you can retrieve the rates on the PM card), or to have specified the rates as topocentric (which, isn't the right thing to do, as discussed above).

The thing to consider is whether the derived rates, which will be topocentric, are good enough, i.e., what is the maximum positional error at the end of 10 seconds if you use topocentric rates rather than geocentric rates? Let's test this for 4 classes of objects:

• Hale-Bopp
  closest approach = 1.31521 AU
  max difference = 4.4 masec
• Venus closest approach = 0.2680 AU max difference = 19.8 masec
• Hyakutake closest approach = 0.10174 AU max difference = 52.3 masec
• 1988 EG closest approach = 0.03179 AU max difference = 161.3 masec

So it looks like the difference in rates roughly scales linearly with distance, with the maximum being some few hundred milliarcseconds.

Even more detail:

It turns out that the quantity on the archive tapes which is referred to as 'IAT for Geometry Calculations (Radians)' in computing memos 186 & 188 (which is supposed to be the precise IAT time for which the "Apparent RA now (Radians)" and "Apparent Dec now (Radians)" positions were calculated) is not correct. The way that the recorded time interacts with what is supposed to be written on tape depends on the integration time specified for observing. Very careful tests (done in the fall of 2001) show that the following correction to what is written on tape will yield the right values:

• convert 'IAT at end of Integration Interval' to seconds
• subtract 'Integration Time (19.2 Hz interrupt counts)' (after converting to seconds - note that what you now have is effectively 'IAT at start of Integration Interval', which is not recorded on tape [because it's redundant with the other 2 quantities])
• add a tiny amount to prevent precision problems in the next step
• round down to the nearest 10 second interval

      TIME = 86400.0D0 * MCIATI / TWOPI - MCINTG / 19.2D0 + 0.01D0
      TIME = DOFF + (TIME - DMOD(TIME, 10.0D0)) / 86400.0D0
   

One more thing - the "w-term" (wave curvature) correction:

Some solar system objects may be so close that the assumption that the incident e-m wave is plane-parallel breaks down. In fact, the wave is curved, and this introduces an additional delay term. This is called the "w-term" because the amount of delay is directly related to the magnitude of W (in U,V,W). This correction was put into the online system in October of 1992. Prior to this, there was no such curvature correction done.

HOW OFTEN QUANTITIES ARE CALCULATED AND UPDATED

The phases of the antennas are calculated accurately every ten seconds. Also calculated are the first and second derivatives of phase with respect to time. Once every 1.25 seconds, the interpolated values of phase and its first derivative are sent to each antenna to control the lobe rotator. The phase error due to this linear interpolation thus accrues over 0.625 seconds. The exact ten second values take into account the partial derivatives of phase with respect to dRA/dt and dDEC/dt.

The absolute pointing of the antennas (as opposed to the pointing of the phase center) is updated every 10 seconds. Throughout the 10 second interval between updates, the antennas track sidereally, i.e., azimuth and elevation rate terms are used to update the pointing 10 times per second, assuming sidereal motion. For solar system sources, which have a PM card, this will cause some reduction in flux density, since the object will not be centered in the primary beam for the entire 10 seconds. As an example, consider an object which moves at an arcsecond of plane-of-sky distance per second of time relative to background sources (e.g., comet Hyakutake). In this case, there will be a few percent reduction in the flux density at the highest VLA frequencies due to the motion of the object (the primary beam is at about .93 * maximum for an offset of 10 arcsec at 43 GHz). There is currently no way around this reduction.

HOW AIPS HANDLES MOVING SOURCES

Modifications have been made to FILLM so that it will recognize moving sources, and attach appropriate position tables for these sources. The attached table is a 'PO' table, and has entries of: time, RA, DEC, and distance. The distance is currently set to 0, since there is no distance information written on the archive tape.

There is currently only one task which will read in these PO tables and actually do anything with them: MODPO. This task has the capability of doing any of the following:

• perform phase adjustments to the data based on incorrect ephemeris (keeping in mind the inaccuracies in the recorded positions noted above);
• adjust phases to "stop" background sources (and not track the moving source any more);
• readjust phases to track the moving source again;
• wave curvature correction (for observations before October 1992);
• add proper distance information (not tested well!).