[evlatests] Troubles with long slews

[Joseph P. McMullin]

Hi Bryan,
The script that ran is at:
/home/mchost/evla/scripts/opt/2010/12/TDEM0011_sb2831326_1.evla
It ran between roughly 1235 LST and 2135 LST on the 16th.
Joe

On Sun, Dec 19, 2010 at 4:16 PM, <bbutler at nrao.edu> wrote:

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


-- 
Dr. Joseph P. McMullin
EVLA
Ph: +1 575 835 7315
E-mail: jmcmulli at nrao.edu
http://science.nrao.edu/evla/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listmgr.nrao.edu/pipermail/evlatests/attachments/20101219/83c32f7d/attachment.html>