INACCURATE POSITIONS RECORDED IN ARECIBO FITS-HEADERS Data affected between 2004-Sep-16 to 2004-Nov-15 ===================================================== A new version of FITS-headers for spectral line data coming from the WAPPs at Arecibo was introduced 16 September 2004. An interpolation routine was added as part of the upgrade that would interpolate telescope position parameters so that these parameters would correspond to the exact time when the data was taken. Unfortunately, it turned out that there were bugs present in this routine. As a result, a number of FITS-header keywords dealing with calculated telescope position information contains erroneous values. The magnitude of the error is usually of the order of 10 arcseconds or less, however occasionally, the error could be as large as several degrees. This problem affects all FITS-files generated between 16 September and 9 November 2004. A corrected interpolation routine was installed 15 November 2004. It is important to note that the problem was with a routine writing the telescope positions to the FITS-header, not with the telescope pointing itself. The FITS-headers do contain uninterpolated and thus undisturbed positional information of where the telescope was pointing in the form of the azimuth and zenith angle as read out by the telescope encoders. The keywords are ENC_AZIMUTH and ENC_ELEVATIO. The read-out time is also available as the keyword ENC_TIME. From this information it is thus possible to recalculate the true values for the affected keywords. We are currently in the process of writing a small program that will do these recalculations and replace the incorrect values in the FITS-headers. This utility will be available to everyone who would like to correct their data files. DETAILED DESCRIPTION -------------------- AFFECTED KEYWORDS: The affected keywords are: CRVAL2A and CRVAL3A (beam position on sky in RA/Dec) CRVAL2B and CRVAL3B (beam position on sky in Az/ZA) CRVAL2G and CRVAL3G (beam position on sky in l/b) CROFF2 and CROFF3 (map center offset in RA/Dec) CROFF2B and CROFF3B (map center offset in Az/ZA) BEAM_OFFRAJ and BEAM_OFFDECJ (total beam offset in RA/Dec) PARA_ANG (parallactic angle) All the above-mentioned keywords are based on the telescope position calculated as the commanded position with the tracking error offset added to it. The problem has been with the calculation of the interpolated offset. The total values may thus at first glance look reasonable, while they in fact always suffer from the addition of a more or less random offset. The offset is often much less than an arcminute but is also rather frequently larger than one degree, especially at the beginning of a scan. Instead of interpolating the tracking errors, the routine made extrapolations of them, thereby inflating small changes in the tracking errors into large offsets. It is not uncommon that errors that should have been a few arcseconds have been magnified up to offsets of several degrees. This is typically worse during the first 10-20 seconds of a scan since there are usually larger changes in the tracking errors to inflate when a scan starts. An additional problem was the fact that the routine often was not using the proper values for the calculations but instead using tracking errors that were valid 10 seconds earlier (for example while the telescope was still slewing to the source). This was done randomly, thus causing a jitter in the affected parameters. There was also another random effect caused by an incorrect floating point to integer conversion which adds a jitter by extrapolating in one direction or the other. One effect of the way the extrapolation worked is that the errors should be smaller for observations taken early in the day (local time) and larger for observations made just before midnight. Apart from the described problems, there is also another problem that has affected the above-mentioned keywords. The effect is more severe, causing several of the parameters to be represented as Not-A-Number. However, it only affects a single 1-second dump and typically occurs only once every few hours. This problem has been caused when tracking offsets for a certain second has not been sent to the program writing the FITS-files - instead the offsets for the previous second have been repeated. This has been corrected so that the missing information is extrapolated from the tracking errors recorded during the seconds preceding the missing information. The reason why tracking data for the preceding second is sent twice is currently being investigated. What is known is that these repetitions follow an exact 899 second cycle, although a repetition does not necessarily happen at every cycle (i.e. the time between two incidents is often more than 899 seconds but it is always a multiple of 899 seconds). In fact most of the cycles are OK - there are typically between 20-25 repetitions in total during one full day. They are not evenly spaced but occur more frequently for a few hours and are then absent for another few hours. It has been verified by looking into old log files that this behaviour has existed since at least early June 2004 and presumably much longer than that. The problem is not related specifically to the WAPPs since it originates in the telescope control system. Mikael Lerner Arecibo, 18 November 2004