RE: Mark IV data off by one day

[Thomas Droege <tdroege2@earthlink.net>]

Here is an attempt to look another way at the possibility that the Mark IV
data was off one day on 2543109.

We take a lot of data to try to make sure that there are no errors.  One
can never take enough.  I do keep log books and normally record computer
clock problems.  There were some a couple of years ago and they were
properly reported.  The log books do not show anything that could be
suspicious in April.  Today they are reading correctly, so the chances of a
1 day error are pretty small since nothing much has happened since April. 
Further, I normally use the GPS to make small corrections in the computer
clock.  I typically just jiggle the seconds to get the time right.  You all
recall that you have to move the mouse up to the calendar to change the
day, so the likelihood of moving the day by a bad mouse move is unlikely.

We record a lot of things.  The *.list file lists a bunch of things related
to the pointing of the telescope and the time.  The operating program
records in the fits headers where it estimates the telescope is pointing. 
This is recorded in the make_list.dat file and also as the *.list file that
is saved for each night's run.  When the data is reduced the program uses
the estimated pointing position to search a catalog for reference stars. 
These stars are used in a triangle search to attempt to match the stars in
the image to the catalog stars.  If this process is successful, then the
estimated positions in the *.list file are replaced with the actual
position for the center of the image.  The correct values are also put into
the .fits header.  This process is not always successful.  So if we look at
any night's run we will find images where the match failed.  This surely
happens at dawn and dusk abut it also occurs for clouds and other
conditions.  This leaves the estimated values in *.list for the failed
matches.  Since the operating mode is to track in RA while taking images at
various declinations, one might be able to find cases where while tracking
in RA a match was successful at one declination but failed at another.  I
have gone through he month of April looking for such instances.  This then
allows determining the error in the estimated pointing position by taking
the difference between an image where a match was successful and an image
where the match failed.  We note that an error in pointing of a day would
result in a change in this correction of nearly a degree.  

The table below shows the date and the correction that was made (in
degrees) to the RA estimate in order to match it to the catalog stars:

Day		Correction
2453096	-0.71
2453097	-0.72
2453098	-0.65
2453099	-0.48
2453100	-0.52
2453103	-0.73
2453105	-0.76
2453108	-0.67
2453109	-0.83  The Day in Question
2453112	-0.84
2453114	-0.36
2453118	-0.57
2453120	-1.05
2453121	-1.05
2453123	-1.13

There are some problems with this method.  An error of one day in the clock
would cause a jump in the correction of almost 1 degree.  This is what we
are looking for.  However, it is very likely that the match process would
fail if the estimated position was off by one degree.  As the telescope
moves in Declination there is an associated error in the RA.  Since there
are not very many failures to look at, the ones in the table above were
taken at different declinations.  Thus we do not see a fixed correction. 
Still, there does not seem to be anything happening on the day in question.

This exercise serves some use.  I realize that the program changes the
values in CRVAL1 and CRVAL2 in the fits header.  Had the old values been
put in the comments section of the header, this exercise would have been
much easier and I could have made a consistent check.  (Hint to Michael
Richmond)

I conclude that there is no evidence that the clock was one day off on the
day in question. 

Tom Droege