Additional Issues

In the process of debugging the CLCOR corrections, it was found that there is a misunderstanding about the Greenwich Sidereal Time that is recorded in the AN table in AIPS. That value is passed from the correlator. It is used in many places in CLCOR and probably elsewhere in AIPS, not just for EOP corrections, for calculating hour angles. For that purpose, the value needed is the Greenwich Apparent Sidereal Time. But in files from the VLBA correlator, the AN table contains the Greenwich Mean Sidereal Time. The differences are on the order of of a few tenths of a second of time. For most purposes, this is not significant. Even for calculating the EOP corrections, it is not significant because the same value is used for calculating both the before and after delays and the impact on the difference is small. But this trap for the unwary should be fixed.

Also while working on the EOP corrections, it was noted that CLCOR modified the geometric delay column in the CL table when doing some types of correction (source and station positions and axis offsets) and not others. In the interests of having the geometric delay reflect what has actually modified the phases, we decided not only to not add the EOP correction to that column, but to make CLCOR not add any other correction either since it does not actually modify data phases. Later, while thinking about the impact of the EOP error on the spacecraft tracking project, we were reminded that the data path to the totals that we delivered to JPL depended on CLCOR making modifications to the geometric delay. So we have broken the spacecraft tracking data path. We are now considering what to do about this, with the likely outcome being to add a user option to decide whether or not to alter the geometric delay column.

Users should be warned that the EOP correction as implemented in CLCOR is specific to the VLBA correlator. This is because CLCOR must be able to reproduce the values of the EOP used on the correlator. Since the parameters change by significant amounts every day -- on the the order of a millisecond of time for UT1-UTC in recent years -- some sort of interpolation must be done between the daily values. CLCOR has code adapted from the CALC model calculator used on the VLBA correlator to do this interpolation. Other correlators may use different code and so may get somewhat different results. Also the choice of which EOP values to use for the interpolation, especially after crossing a day boundary may be different. And finally, other correlators may not provide the required CT table data. So CLCOR probably won't even run for data from other correlators, and, if it does, may get results that are not quite right. But if it does run and there are no oddities like steps in the data, the results may not be too bad.

Note that the need for EOP corrections will rise in the future if eVLBI becomes popular. Fundamentally, an eVLBI correlator will be using predicted EOP values so making corrections after the fact will probably have to become a routine processing step. On the other hand, Non-VLBI instruments, like the VLA, have less stringent accuracy requirements and can use predicted EOP without degrading the vast majority of observations.