The Problem

Astrometric observations that involve phase-referencing a target source with a calibration source are usually limited by small errors in the correlator atmospheric model. The VLBA correlator uses a seasonally averaged model that does not use surface weather data. The total zenith delay for the neutral atmosphere is typically about 200 cm of path length (ie, delay divided by speed of light) and the error in the model is about 5 cm. For the highest astrometric accuracy, as well as the best imaging, it is important to determine this delay and correct the data for it.

The ionosphere also adds a delay and the correlator model has no ionospheric term. Typically this zenith path delay is about 0.7 cm at 43 GHz and scales as the inverse-square of the frequency. An approximate correction for the ionosphere can be made using the VLBAUTIL procedure VLBATECR in AIPS.

A Solution

A simple and effective way to solve for the error in the VLBA correlator atmospheric model is to observe many "QSOs" spanning a large range of source elevations (called "geodetic blocks"). These geodetic blocks should be made with the maximum possible spanned bandwidth (eg, 500 MHz). Multi-band delays from these observations typically can yield a measurement accuracy of about 0.1 nsec (3 cm of path delay). Since the atmospheric delay has a sec(ZA) signature, one can separate a zenith atmospheric delay for each station from clock offsets. Observing about a dozen QSOs within about 30 minutes can yield station zenith path delays accurate to about 1 cm (1-sigma).

We are using a program that tries large numbers of quasi-randomly generated geodetic blocks and finds nearly optimum blocks that can be inserted in observing schedules. A library of geodetic blocks can be found here. There is a block for start times every 10 minutes; the start times are given in Pie Town local sidereal time (PT_LST). Each block requires about 30 minutes of observing time on the VLBA. The files are named "geoblock_hhmm.out", where hhmm is the start time. These blocks assume an on-source observing time of one minute (DWELL=60).

Since these blocks observe sources down to low elevations, it is important that they start very close in time to the indicated PT_LST time. If you use these, be sure to check that the source elevations (listed in the files) are close to what the VLBA scheduling program (SCHED) gives!

The library of geodetic blocks used a list of ICRF "QSOs" which is needed by the VLBA SCHED program. These QSOs were selected to have more than 1000 ICRF observations, little source structure, and positions accurate to better than 1 mas. They generally work well at 8 GHz and higher observing frequencies. Each block has an associated file, eg, src_catalog_0610.out, which gives the source coordinates in SCHED format for the associated geoblock.


As mentioned above, a typical geodetic block observed with a spanned bandwidth of 500 MHz with the VLBA at say 12 GHz will yield a zenith delay accuracy of about 1 cm. One could use longer or shorter geodetic blocks and this will change the typical accuracy. Here is a plot of expected accuracy versus time dedicated to a geodetic block.
Accuracy of atmospheric zenith delays from VLBA observations of geodetic blocks as a function of time dedicated to the observations. The accuracies are based on simulations and assume multi-band delays with uncertainties of 3 cm of path length (0.1 nsec delay). For blocks shorter than about 25 minutes, it is hard to find a wide range of source elevations at all 10 VLBA stations, and the accuracy degrades rapidly. For blocks longer than 30 minutes the accuracy increases slowly as the inverse square-root of time.

Fixing Data in AIPS

In order to correct VLBA data for atmospheric delays, one needs to do the following:

1) Apply a "manual phase-calibration", using a single QSO observation to all the others. This should be done for a scan that has strong signal at all stations.

2) Use FRING to solve for multi-band delays.

3) Solve for the atmospheric delays with DELZN or some other program

4) Apply the corrections with CLCOR.

We strongly recommend checking that this procedure works by re-FRING'ing after correction and resolving with DELZN. The new corrections should be very close to zero.