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.