[daip] CLCOR source position rounding bug?

[Walter Brisken]

For a pulsar astrometry project I'm applying source position updates to 
those calibrators with recently improved positions to simplify the 
accounting of true positions.  Based on some recent tests, I'm concerned 
about some internal rounding within CLCOR, but only in some circumstances 
that I cannot understand.

I have explored the effect on the first two epochs of an 8 epoch data set.  
The data are mostly similar.  Epoch 2 is the one showing behavior that is 
quite idicative of rounding, but Epoch 1 (which behaves like epochs 3 
throuh 8) does not.

I discovered the problem when using DBCON to concatenate databases from
two epochs.  A warning suggested that the coordinates differed.  I then
began investigating by looking at the SU table.  Note that tbout is needed
to print the source coordinates to sufficient precision. Since the effect
is the same whether UV data exists or not, I used tasav to duplicate the
database sans UV data to minimize the amount of data.  Note that I've only 
investigated the SU table issue.  I'm not sure if the changes to the CL 
correspond to the intended or the actual shifts reported in the SU table.

I made 5 copies of the TASAV "database" for each of epoch 1 and 2.  I used
CLCOR / ANTP with clcorprm(5) and (6) each set to 0.00001, 0.001, 1, 10
(arcsec) and saved the resultant SU table for checking.  For each, I
extracted RAEPO and DECEPO and computed the difference in picture plane
arcseconds between the new coordinates and original coordinates.  For
epoch 1, the results differed from the desired shift by 20%, but this has
been ascribed to the use of apparent coordinates and is not of concern
right now.  Note that even at the 10^-7 arcsecond (or 10^-13 of the
absolute angle) level the shift is linear in the input value with no signs
of rounding.

For epoch 2, a noise of about 10^-7 of the absolute angle is introduced (a
value possibly consistent with the use of a 32 bit floating point
somewhere internally).  Linearity is not observed until the 1 arcsec level
is reached.  The tables of numbers follow.

I wonder if at some place in the code, a conditional is executed (perhaps 
to subtract 2pi from an angle???) with 32 bit floats.

If looking at the particular datasets would be of use, you can find them
on my computer (parallax) aipsid 2179, disc 8, files epoch1.* and epoch2.*
The source name is J2052+3635 .

-Walter

Epoch 1  (normal)

Table        RA (deg)                Dec (deg)              Delta RA (arcsec) Delta Dec (arcsec)
tasav.su:    3.132168958166667E+02   3.659313894722222E+01  0                 0
10muas.su:   3.132168958201270E+02   3.659313894999956E+01  0.0000125         0.00000803
1mas.su:     3.132168961626927E+02   3.659313922495799E+01  0.001245          0.0008027
1asec.su:    3.132172418426647E+02   3.659341668299719E+01  1.24569           0.8027674
10asec.su:   3.132203560766177E+02   3.659591630500037E+01  12.45693          8.0276746

Epoch 2  (weird)

Table        RA (deg)                Dec (deg)              Delta RA (arcsec) Delta Dec (arcsec)
tasav.su:    3.132168958166667E+02   3.659313894722222E+01   0                 0
10muas.su:   3.132168240895452E+02   3.659313071063108E+01  -0.2073           -0.02965
1mas.su:     3.132168244321204E+02   3.659313098554775E+01  -0.2063           -0.02866
1asec.su:    3.132171701216848E+02   3.659340840144551E+01   0.79              0.9700
10asec.su:   3.132202844419903E+02   3.659590764379131E+01   9.794             9.9673