[evlatests] Troubles with long slews

[bbutler at nrao.edu]

the OPT doesn't really "pass" anything (in the normal sense) to
model2script.  the results of work in the OPT are put into the database
(that's the "model" part), which is then accessed by model2script at the
time the script needs to be run (the "script" part).

i'm confused by your example though, rick - i don't quite understand what
happened on those scans.  a 2m20s scan seems very odd when it should have
been ~4m10s, and not getting the following scan is odder still.  it sounds
like something funny with the executor, but that seems odd as well.

what was the name of the script that was run, and the database ID for the
stored model?  and what times (precisely, please!) were those odd scans? 
i can have a look at the generated script (or re-generate it myself) and
see if i see anything funky there with the timing.  i'll also have a look
at the executor log to see if something looks funny there.

-bryan


> 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.
>
> _______________________________________________
> evlatests mailing list
> evlatests at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
>