[daip] Re: NOT a TVFLG bug -- cal. pos'n changes between fast-switching scans

[Michael Rupen]

Hi Ken,

  from your note I gather that the position recorded by AIPS is most
likely correct, and that that position does indeed change.  If so I would 
much prefer AIPS to do exactly what it does now -- issue a warning message 
in FILLM, change the name to something unique, and record the actual 
positions that were used during the observations.  This seems to me a 
feature rather than a bug on AIPS' part.  For the on-line system, this
won't matter except for very precise referencing, and there the observer 
will have to look at the position recorded with the data anyhow.

  I'm assuming that the *reported* position at observe time, the one
recorded on the data tape, is accurate to a milliarcsecond or better.
Is that correct?

  Cheers,

             Michael

>
> This certainly looks like it is my fault and I 
> think that I can offer an explanation.  
> 
> The explanation hinges on the precision of floats
> and requires that scans with different program
> sources use the same calibrator and that the 
> calibrator be the secondary (given on the //OF card)
> source.  When the scan is initialized, the two positions, 
> represented as doubles, are differenced and the result 
> saved as a float.  Later while nodding, the secondary
> position(double) is computed as 
> primary-position(double) - difference(float).
> The precision of a float is such that I expect errors
> of a few milli-arc-sec if the difference is a few degrees.
> 
> When I analyzed this ages ago I reasoned that errors of that
> magnitude are irrelevant and are repeatable.  However I
> neglected to consider the case of different program source
> positions.
> 
> Is it a reasonable solution to ask AIPS to put a little fuzz
> in the source position comparison?  The real solution is to
> represent the difference internally as a double rahter than 
> float.  That however means recompiling most programs in the
> Modcomps.  That could be done, but is tedious and I worry
> about any omissions.  Shall we talk about the possibilities
> this week?
> 
> Ken
>