Improving the EOP Used on the VLBA Correlator

As described earlier, when the VLBA correlator job generator is working properly, the EOP values used are usually rapid service values from Bulletin A. Those values are far better than the predicts that got used while the EOP bug was in effect, but they can be based on data as little as 18 hours old, so they should be considered preliminary. Between 1 and 2 months after a given date, the ``final'' values are also published in Bulletin A and put in the data base. These are better values, but the recording media really need to be recycled before the final values are available.

A quick scan of some old Bulletin A issues on the archive at the USNO site show that the changes from the rapid service values to later, nominally better, values are on the order of a several tens of microseconds for UT1-UTC and a tenth of a milliarcsecond for the pole positions. These offsets are probably well below the errors in the data from other effects such as atmosphere, so the use of rapid service values should not be limiting most observations.

The standard scheme of acquiring EOP from the Bulletin A will start to give poor values (predicts) more often as we try to shorten turnaround times to support Mark 5 recording system deployment. If an observation is at the right time of the week, it can end up with at least one day with predicted, rather than measured, EOP if the jobs are made as much as 9 days after the observations. Recall that the jobs contain 3 days of EOP data from after the observations. Now it is possible to correct such projects after correlation, but it is still undesirable to use poor EOP data.

An enhancement in the process of being implemented is to switch to using a ``daily'' file as the source of EOP for the correlator. The usno_finals.erp file recommended above for corrections will be used. Any changes to the EOP values are very small after a few days after real time, so the daily file, for which all days' data are updated to the latest available each day, would give very close to final values for most correlations. If we switch to a daily file, which has decent, if not final, measurements for the day before the file is made, jobs made more than 4 days after the observations will be based entirely on measured values. This could be significant for fast turn-around. In recent days, the correlator has been running closer to real time than typical in the past and the need for better EOP has been apparent.

A related change that should be made is to rationalize the determination of which EOP values are used on the correlator. The current situation where the job scripts contain a variable number of EOP rows and the correlator uses the first 5, no matter what days those are for, is not very satisfactory. Either the correlator should select rows based on date, not just the first 5, or the job script writer should only put out 5 rows.

If we update the EOP values in the correlator every day, the probability that we could end up with different job scripts (time ranges) for a project having different EOP are increased. We will need to be careful to avoid such situations. Typically now all job scripts are made at the same time, and that will protect us against variable EOP in the future. This is actually an old issue related not just to EOP, but source and station positions etc. You don't want any to vary between jobs for a given project. Ideally the job generator would have a mechanism to guarantee that this doesn't happen, but realistically the software support is not available to do this and we will need to continue to rely on the vigilance of the analysts.