[evlatests] Troubles with long slews

[Bryan Butler]

rperley at nrao.edu wrote, On 12/19/10 16:48 PM:
> Bryan:
>
> Some clarification below:
>
>> 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.
>>
> There's nothing odd with missing the subsequent scan.  The request was to
> go from Hercules A to 3C286, and when we get there, observe, in sequence,
> for 45 seconds each, L, S, C, and X bands.  The travel time was about 3.5
> minutes, the rest of the time for that first scan (4.2 min) was for the
> on-source L-band integration.  After that (with no antenna motion) was
> S-band.  But the shortage (nearly two minutes) was longer than the sum of
> the L and S band on-source dwells, so by the time we *should* have
> completed the S-band observation, the antennas were still moving to
> source.  The next observation was at C-band -- and this one got its full
> 30 seconds on-source.
>
> The oddity is how the executor thought that 2.5 minutes was sufficient for
> the move when any basic calculation, based on the distance to travel,
> shows that 3.5 minutes was needed.

the executor doesn't work that way.  it doesn't calculate time to source 
or anything like that.  you just say in the script what source to go to 
at what time, and the executor tells the antennas/correlator to do it at 
that time.  so either the script has a problem in the timing (which 
could come from the OPT or model2script), or the executor is 
misinterpreting somehow, or something is happening at the antennas.


>> 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.
>
> The program is TDEM0011.  I can't get the rest of the information at this
> time (people coming over for dinner, expected shortly ...).  I'll retrieve
> all this tomorrow.

OK - when you get the information that will help quite a bit.


>
> Rick
>>
>> -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
>>>
>>
>>
>