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.
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:
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.
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_DOPSETwhere 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 motionsNow, 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 (see below), 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)
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 (firstname.lastname@example.org) or Ken Sowinski (email@example.com).
Observations of the Sun require special care when preparing the OBSERVE file. Please contact Tim Bastian at NRAO (firstname.lastname@example.org) for help in setting up such files. There is a guide for the brave.
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.
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:
So it looks like the difference in rates roughly scales linearly with distance, with the maximum being some few hundred milliarcseconds.
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:
TIME = 86400.0D0 * MCIATI / TWOPI - MCINTG / 19.2D0 + 0.01D0 TIME = DOFF + (TIME - DMOD(TIME, 10.0D0)) / 86400.0D0where 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.
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.
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.
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: