Observing the Planets with the VLA Bryan Butler (bbutler@nrao.edu) NRAO 24Apr2002 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, [webbed at: http://info.aoc.nrao.edu/~vlaops/OpsDoc.html], by Ken Sowinski and Jim Nieri) 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 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 _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, which is described in great detail at: http://www.cv.nrao.edu/~tbastian/VLAsolar/solobs/solobs.html 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: o Precession o Nutation o Parallax terms o Diurnal parallax o Annual parallax o Aberration terms (often called _planetary aberration_) o Light-time o Stellar aberration o Diurnal aberration o Annual aberration o Gravitational deflection term o Polar motion term o Refraction See the Explanatory Supplement to the Astronomical Almanac (2nd ed.), pp. 123-145 for an in-depth description of each of these corrections. Whether or not these terms are calculated and applied depends upon the epoch specification. If positions are specified in B1950 or J2000, the on-line system will calculate and apply the diurnal aberration and parallax, annual aberration, gravitational deflection, and nutation and precession terms to the positions. However, note that only the diurnal aberration and parallax terms are applied to the rates, i.e., after the annual aberration, gravitational deflection, nutation, and precession terms are applied to the position, the offset due to the rate is added, then the diurnal aberration and parallax are applied to that sum. So, the rates are presumed to be accurate for the IAT time specified on the _PM card_. For positions of date, only the diurnal parallax and aberration terms are calculated and applied. The annual parallax is never calculated by the on-line system, and should be included during the ephemeris generation (and is for all reasonable ephemeris generation programs). In all cases, the VLA makes no consideration for the light time from the object to the VLA. This must also be accounted for during ephemeris generation. The polar motion term is explicitly handled by the VLA in calculating the positions of the antennae, so should not be included in the supplied position. Atmospheric refraction is always calculated and applied by the on-line system. 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. 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_, the OFSC, and Ken Sowinski's guide to Q-band observing for details. The _FI card_ has the following format (from OFSC, and a memo 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 where nu is the true observing frequency, nu_A/B is an absolute frequency specified in MHz in columns 17-30 and 37-50, nu_rest is a line rest frequency specified in MHz in columns 51-65 and 66-80, nu_o is an offset frequency specified in MHz in columns 17-30 and 37-50, nu_v/z is a offset frequency calculated by using the offset velocity (in km/s) specified in columns 17-30 and 37-50, and nu_DOPSET is a doppler offset frequency calculated by taking into account the relative motions of the object and the observer. The method of calculating nu_DOPSET depends upon the value specified for the restframe (column 8): 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 Now, currently, if 'G', 'B', or 'L' are specified, and the object is a moving one (has a _PM card_), then the on-line system uses the fictitious midnight position in calculating nu_DOPSET (see above). This can obviously create large frequency errors for fast moving objects. Because of this, it is strongly recommended that absolute frequencies be specified in either of two ways: 1 - use f/v switch = 'F', i.e., explicit frequencies supplied on the _FI card_; 2 - use f/v switch = 'V' or 'Z', and restframe = 'T'. In either case, topocentric ephemeris values of the relative velocity between the VLA and the object are necessary. This creates some complexity, as the positional ephemeris (RA and DEC) should be geocentric ephemeris of date, while the velocity ephemeris should be topocentric ephemeris of date. (Note: this is going to be changed soon, so that the midnight position is no longer used, and the position used to calculate nu_DOPSET will be the one specified on the _source card_... 3/21/96, bjb) 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. 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: 1 - Hale-Bopp closest approach = 1.31521 AU max difference = 4.4 masec 2 - Venus closest approach = 0.2680 AU max difference = 19.8 masec 3 - Hyakutake closest approach = 0.10174 AU max difference = 52.3 masec 4 - 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 or, in FILLMese: TIME = 86400.0D0 * MCIATI / TWOPI - MCINTG / 19.2D0 + 0.01D0 TIME = DOFF + (TIME - DMOD(TIME, 10.0D0)) / 86400.0D0 where in the last step, I convert to fractional days (after adding it to the day offset), which is what I want in the PO table. 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 specify _PM_ cards, 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: FIXPO. 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!). The 'correct' ephemeris can either be calculated internally (for the planets, Sun, and Moon), or supplied as an external ephemeris (in the JPL Horizons format). This task is not part of the general AIPS release - contact me (bbutler@nrao.edu) if you are interested in using it.