[mmaimcal]Re: reconfiguring

[Bryan Butler]

i agree with john here.  adapting on that short a time scale
to proposal schedule is not a good idea, IMHO.

in my mind, the way to do it is come up with a decent scheme
(the best we can given current thinking), and test it out for
a long period (at least once through the complete cycle).

if it turns out to work, fine, we're done for a bit.

if it doesn't work, then we have to fix it, which may just be
tweaking, or may be a major overhaul.  for instance, we may
find that the astronomers don't like a continual reconfiguration,
and squawk about it enough, and we have to go back to burst
reconfiguration...  the fixing comes via input from operations
and the user community.

but, again, i think it would be a bad idea to start with the
idea of immediate response to proposal pressure.  that's
something that will come over time...


	-bryan


On 2002.12.11 11:41 John Conway wrote:
> 
> Hi,
> 
>  There is a question of how much flexibility in response
> to proposal pressure one wants.  I myself was never 
> a fan of changing the scheduling scheme on a week 
> to week basis in response to proposal pressure.
> In my memo 283 I present what I had in mind. I
> considered that there would be differnt types of
> expt, some requiring an exact resolution others with 
> looser requiements the more exacting ones would 
> be scheduled first. In this way in a zoom array you 
> could get the option of exactly the same resolution 
> at different line transitions  (which you didn't have 
> with fixed  arrays 2 or 3 apart in resolution). 
> The felxibility in sheduling was based on -WHEN-
> a experiment was scheduled in the move 
> schedled, NOT by changing the move schedule 
> itself.
> 
> I was thinking that one MIGHT  change the overall
> cycle scheme every cycle or two in response to 
> the statistics of proposals pressure, Thus if 
> after 9 months or 18months it seemed that the statitsics
> showed a   certain array size was less popular then 
> for the coming 9 month schedule one would schedule there 
> to be  2 moves days our of every 3 through 
> that array size rather than 1 out of every 3  
> - and then move slower through the popular arrays, while 
> maintaining the overall cycle time - something like that.
> Even in this scheme I did not envision allowing the whole 
> configuration cycle time to be ajustable in 
> reponse to proposal pressure. I think it would 
> be good to consider the overall cycling with repect to 
> seasons, try to optimise it and then keep it fixed
> no matter how much internal flexibilty is 
> introduced within the cycle.
> 
> Of course if people think it would be desirable to 
> have more interaction between proposal pressure and the 
> reconfiguration cycle- then I guess it can be built in but 
> it gets complicated fast.
> 
>    John
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, 11 Dec 2002, Mark Holdaway wrote:
> 
> > 
> > 
> > > > how can we make a reconfiguration scheme which will
> > > > be flexible enough to respond to changes in proposal pressure,
> > > > while maintaining certain properties we are happy with
> > > > (ie, seaonal cycling).
> > > 
> > > yep - this is the key.  but, i don't know that we have to make a scheme
> > > to begin with that is necessarily flexible intrinsically.  the
> > > flexibility is built into the pad layout, in many ways, which was
> > > the big reason (in my mind, at least) why the 'zoom-spirals' won out
> > > over the nested donuts...
> > > 
> > 
> > A principle which can guide flexibility:
> > 
> > to let the time spent in each configuration be proportional to observing
> > pressure (or high quality observing pressure).
> > 
> > We have two knobs to turn:
> > 	- speed of reconfiguration
> > 	- amount of time spent on end points
> > 
> > We start with OUR reconfiguration scheme (whatever that is), and
> > then adjust the two knobs in responce to proposal pressure, perhaps
> > in a week-by-week decision process (ie, if there is a large backlog
> > of projects, the site director could choose to slow down 
> > reconfiguration; if there are gaps in ALMA's use because there are no
> > projects at that LST and that resolution and those prevailing weather
> > conditions, it is time to move antennas faster).
> > 
> > If this flexible approach is chosen, then we have no reproducable cycling 
> > through seasons, it just comes out the way it comes out.... and we may
> > move faster through summer than winter.
> > 
> >    -Mark
> > 
> > 
> > _______________________________________________
> > mmaimcal mailing list
> > mmaimcal at listmgr.cv.nrao.edu
> > http://listmgr.cv.nrao.edu/mailman/listinfo/mmaimcal
> > 
> 
>