Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.naic.edu/~cima/bad_fits_1.txt Дата изменения: Thu Mar 1 19:02:26 2012 Дата индексирования: Mon Oct 1 21:44:50 2012 Кодировка: Поисковые слова: п п п п п п п п п п п п п п п п п п п п п п

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