[evlatests] Troubles with long slews

[rperley at nrao.edu]

Gents:

This is an important problem which needs timely resolution.  I'm quite
willing to whip up an observing script (and look at the results in close
to real time) to test any changes that might be imposed.

For amusement -- the system is acting as though it thinks the actual
antenna slew rates are about that of the ALMA antennas ...  :)

Rick

> On Sun, 19 Dec 2010, Rick Perley wrote:
>
>>    The problem does not appear to lie with the OPT.  I examined the
>> OPTs calculations of time moving and 'sitting' -- and these are always
>> in excellent agreement with what I expect given the distance to be
>> traversed.
>>    An example should help clarify the problem:
>>             At one particular moment, we needed to move from Herc A to
>> 3C286.  The azimuths and elevations were at that time:
>>             Herc A:  Az = 118   El = 42
>>             3C286:   Az = 252   El = 79
>>
>>    With azimuth slew speeds of 40 deg/min, and elevation speeds of 20
>> deg/min, it's obvious that more than 3 minutes will be needed to cover
>> that distance.  The OPT states the time required would be 3m 26s.
>> Adding in my requested 45 seconds 'on source' time, the scan observation
>> time for 3C286 in this instance should be a little over 4 minutes.  And
>> indeed, this is what the OPT says will be provided.
>>    But it's not what happened.  In fact, the length of that scan was 2m
>> 20s -- nearly 2 minutes short.  So not only was that calibration scan
>> missed, but so was the subsequent one (same source, different band).
>>
>>    Further evidence of the problem lies with the total length of the
>> observation.  The OPT claims the total length of the observation is 8h
>> 0m.  (Indeed, I constructed the file to fit this time window).  But the
>> *real* observation length was 7h 47m -- the 23 minutes differential is
>> the sum of the all travel time miscalculations.
>>
>>    This is a significant problem, especially to those programs which
>> have many long slews -- like the 'flux densities/calibration scale'
>> run.  Fortunately, this program was not run this weekend, due to poor
>> weather.
>
> It is clear that the script generated and used for this
> observation contains the faults that rick describes.  If
> the OPT is calculating and reporting the correct information
> to Rick, the problem must lie in what it passes to m2s, or
> what m2s does with that information.
>