[evlatests] your mail (Antenna Wrapping)

Craig Walker cwalker at nrao.edu
Tue Mar 9 12:53:35 EST 2010


Vex has a slot for the wrap ("pointing sector") for each antenna in the 
SCHED block.  SCHED doesn't fill it in, but SCHED does know that 
information as a result of its slew calculations and could fill it in. 
Then it could be forced by subArray.setWrap().  That could be a fairly 
simple way to deal with predictable wraps.

Note that usually schedules were passed through Observe to check the 
setups.  I don't know if the EVLA will have some scheme for doing that.

Cheers

Craig


Adam Deller wrote:
> I am sure we can implement a scheme for the default pathway to
> configuring the EVLA for VLBI observations (via the vex files) which
> satisfies the requirement for predictable slew times.  I imagine this
> would involve enforcing (via a subArray.setWrap() in the control
> script which vex2script produces) that the array starts in the same
> wrap that SCHED assumes.  If people then want to create their own EVLA
> schedule for a VLBI experiment using the OPT, then they will have
> access to the full range of flexibility available to the OPT, but will
> have to beware potential pitfalls, too.
> 
> Cheers,
> Adam
> 
> On Mon, Mar 8, 2010 at 10:21 AM, Craig Walker <cwalker at aoc.nrao.edu> wrote:
>> That is my understanding too.  But are we sure the OPT will never be used,
>> such as when weird setups are required or we want to check schedules?  Just
>> because SCHED can write old VLA observe decks certainly did not mean that
>> those files weren't passed through Observe in many cases.  But also,
>> situations that might make it hard to follow a fixed schedule might exist in
>> the on-line system common to all schedules. That was certainly true in the
>> early VLBA days when the on-line system had a nice wrap optimizer that
>> minimized the time lost to wraps, but could not be predicted because of
>> variable factors in how it was run at observe time.  Those who really cared
>> - the geodesy community - wanted predictability over optimization and we
>> eventually reverted to a simple and predictable algorithm.
>>
>> Cheers,
>>
>> Craig
>>
>>
>>
>> Walter Brisken wrote:
>>> According to the plan that we (Adam and Matthias, mostly)  are coding to,
>>> the EVLA schedule for VLBI will be generated based on the vex file and will
>>> not use the OPT at all, so this is not relevant here.  Please correct me if
>>> I'm wrong!
>>>
>>> -Walter
>>>
>>> On Mon, 8 Mar 2010, Craig Walker wrote:
>>>
>>>> I'd just like to remind people that it needs to be possible to generate
>>>> a schedule that will do exactly what is requested in terms of scan
>>>> times.  This is required for VLBI where the schedule needs to be aligned
>>>> in time with what is being done at other telescopes.  With respect to
>>>> wraps, this means that either the scheduling program knows the algorithm
>>>> in use well enough to predict its behavior exactly (which is why we use
>>>> a simple algorithm on the VLBA rather than an optimized one), or that
>>>> the scheduling program can request specific wrap behavior.  A less good
>>>> option is to take your lumps (missing data) when a wrap happens in the
>>>> wrong place.  But scans cannot be adjusted when that happens in a VLBI
>>>> schedule.
>>>>
>>>> Cheers,
>>>>
>>>> Craig
>>>>
>>>>
>>>>
>>>>
>>>> Bryan Butler wrote:
>>>>> amended after some clarification from ken...
>>>>>
>>>>>
>>>>> Bryan Butler wrote, On 3/8/10 09:01:
>>>>>> David Harland wrote, On 3/8/10 08:49:
>>>>>>> Yes, the OPT allows the user to provide wrap hints for each scan.
>>>>>>> The scan's default is "No Preference"; the user may change this
>>>>>>> to CW or CCW.
>>>>>>>
>>>>>>> The script generation process sets the wrap for every scan, using
>>>>>>> -1 for CCW, +1 for CW, and 0 for no-preference.
>>>>>>>
>>>>>>> Questions:
>>>>>>>
>>>>>>> 1. Should we do as Ken suggested and suppress the
>>>>>>> subarray.setWrap cmd if the user expressed no preference?
>>>>>> seems to me the thing to do is:
>>>>>>
>>>>>> 1. do a subarray.setWrap(0) at the top of the script
>>>>>> 2. only do a subarray.setWrap(I) on a scan where it was changed
>>>>>>   from the default by the user in the OPT
>>>>> 3. on the subsequent scan, do a subarray.setWrap(0)
>>>>>
>>>>>
>>>>>> (this is probably what ken suggested...)
>>>>>>
>>>>>>
>>>>>>> 2. Is there any harm in sending the same setWrap cmd
>>>>>>> (eg, setWrap(-1)) on successive scans, as we do
>>>>>>> currently?
>>>>>> there is no harm as long as the behavior is as i just described above
>>>>>> (i.e., the setWrap() has the same parameter as the last scan in which
>>>>>> it
>>>>>> was specified).
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Bryan Butler wrote:
>>>>>>>> we have always in the past left it up to observers to figure out
>>>>>>>> whether it is important to them or not.  we may not be able to
>>>>>>>> continue to do that, but for now that is the working model.
>>>>>>>>
>>>>>>>> there is no place that the wrap choice is made outside explicitly
>>>>>>>> setting it in the OPT.  if you don't set it (or set it explicitly to
>>>>>>>> "don't care") then the executor makes the decision about which way to
>>>>>>>> turn the antennas (i believe the algorithm is a direct copy of what
>>>>>>>> was done on the modcomps).
>>>>>>>>
>>>>>>>> in the future, we can do all sorts of fancy things.  in the future...
>>>>>>>>
>>>>>>>>    -bryan
>>>>>>>>
>>>>>>>>
>>>>>>>> Steven T. Myers wrote, On 3/6/10 13:14:
>>>>>>>>
>>>>>>>>> If we are to not have issues like this for routine dynamic
>>>>>>>>> observing,
>>>>>>>>> then we at least need a way to make sure all antennas are in the
>>>>>>>>> same
>>>>>>>>> wrap (whatever the executor or scheduler decides at the time the
>>>>>>>>> wrap
>>>>>>>>> should be).  Where is it that the wrap choice (barring explict
>>>>>>>>> setting
>>>>>>>>> in the OPT) is made?
>>>>>>>>>
>>>>>>>>> Things are usually more deterministic if you observe (ie. get on
>>>>>>>>> source at least) a source that is well south of the zenith so it it
>>>>>>>>> guaranteed to not be the ambiguous wrap zones, but I don't know if
>>>>>>>>> we want to go as far as recommending this to observers.
>>>>>>>>>
>>>>>>>>> In the longer term, if we don't go to full dwell-time scheduling, it
>>>>>>>>> might be prudent to have a parameter like "min_dwell_on_source" that
>>>>>>>>> is passed to the
>>>>>>>>> scheduler so it can evaluate whether to execute a given schedule at
>>>>>>>>> a given
>>>>>>>>> LST or not (the moral equivalent of running OBSERVE and seeing if
>>>>>>>>> you get
>>>>>>>>> enough time on all the sources).  This at least might prevent the
>>>>>>>>> worst problems from slews and wrapping without requring the user to
>>>>>>>>> over-specify
>>>>>>>>> start times.
>>>>>>>>>
>>>>>>>>>  -s
>>>>>>>>>
>>>>>>>>> On Fri, 5 Mar 2010, Bryan Butler wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> the OPT definitely allows one to set the wrap if desired.
>>>>>>>>>>
>>>>>>>>>>    -bryan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ken Sowinski wrote, On 3/5/10 17:45:
>>>>>>>>>>
>>>>>>>>>>> On Fri, 5 Mar 2010, Vivek Dhawan wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> I just got done with a cursory look at the C55258.434 (AH1004)
>>>>>>>>>>>> chunk, it looks good on the targets; but the flux cal scan
>>>>>>>>>>>> 1331+3030
>>>>>>>>>>>> is fringeless on 6 (otherwise good) antennas even though it is
>>>>>>>>>>>> 4:15 long
>>>>>>>>>>>> and most antennas got 1:30 or so dwell time. This should be
>>>>>>>>>>>> repeated
>>>>>>>>>>>> with 1331 adequately scheduled, perhaps by moving it a bit later
>>>>>>>>>>>> in the
>>>>>>>>>>>> schedule
>>>>>>>>>>>>
>>>>>>>>>>> The fringeless antennas are clearly a wrap problem.  Whether
>>>>>>>>>>> it is an observer oversight or a loss of information in
>>>>>>>>>>> script generation I cannot tell.  The OPT allows wrap hints?
>>>>>>>>>>> The scripts in question had every scan marked as 'dont-care-
>>>>>>>>>>> about-wrap'.
>>>>>>>>>>>
>>>>>>>>>>> I suggest the script generator not include setWrap() calls
>>>>>>>>>>> unless the observer has supplied an explcit hint to the OPT.
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> |:| Steven T. Myers                      |:|  Tenured
>>>>>>>>> Astronomer       |:|
>>>>>>>>> |:| National Radio Astronomy Observatory |:|  Ph:  (575)
>>>>>>>>> 835-7294      |:|
>>>>>>>>> |:| P.O. Box O, Socorro, NM 87801        |:|  FAX: (575)
>>>>>>>>> 835-7027      |:|
>>>>>>>>> |:| http://www.aoc.nrao.edu/~smyers      |:|
>>>>>>>>> smyers at nrao.edu          |:|
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>
>> --
>> ---------------------------------------------------------------------
>>    R. Craig Walker            Array Operations Center
>>    cwalker at nrao.edu           National Radio Astronomy Observatory
>>    Phone  575 835 7247        P. O. Box O
>>    Fax    575 835 7027        Socorro NM 87801   USA
>> ---------------------------------------------------------------------
>>
>>
> 
> 
> 

-- 
---------------------------------------------------------------------
     R. Craig Walker            Array Operations Center
     cwalker at nrao.edu           National Radio Astronomy Observatory
     Phone  575 835 7247        P. O. Box O
     Fax    575 835 7027        Socorro NM 87801   USA
---------------------------------------------------------------------




More information about the evlatests mailing list