[mmaimcal] Dynamic Scheduling

[Min Yun]

Simon,

I think your question really has two separate aspects.  It is one
thing to measure the physical quantities needed, but how this
information is used is a rather different question.
Further, how the dymaical scheduling is implemented will have an
important impact on which information is required and in what form.

Opacity, phase fluctuation, and wind condition are the obvious primary
factors.  Fortunately, all these are relatively easily quantifiable
and thus easy to implement into any dumb or smart logic scheme,
albeit somewhat arbitrary (i.e. thresholds).  A next level of
complication arises if we want more than one stations where these
measurements are made (observing at the VLA last winter, the sky
above the control room was clear as one could hope, but the 
maintance crew on one of the arms reported a white-out condition
and were heading back by tracing along the railroad tracks!).

There is yet another dimension -- time.  Do we make instantaneous
decisions or try to make predictions based on past records?  What
is the shortest duration for a project that is sensible?  What
should be the fundamental time scale that dictates scheduling?
I would think the calibration requirements (on top of any other
bookkeeping and setup requirements) would set this time scale.
There is also a trade-off between having the projects and the conditions
perfectly matched versus having a nightmare of keeping track of all
fragmented data for various projects if we allow this time scale
to be very short.  This is an operational issue, but the scheduling
is mostly an operational issue.

Being a bit more specific, the decision on any particular radiometric
phase correction scheme may have further requirements that are 
relevant.  For example, the 183 GHz system requires some knowledge
of the vertical temperature and pressure profile, and this may also be
true for the 22 GHz radiometer and Welch-Staguhn amp cal system as
well.  Should a 60 GHz radiometer go into this "environmental monitoring"
package?

Lastly, who or what is going to be this "Son of Barry"?
So far as I know, all existing dynamic schedulers involve some form
of flesh and blood, and the inputs incorporated to the decision making
are minimal for various reasons.  Perhaps simplicity is not
a bad thing if we go with a silicon-based scheduler.  At least
operationally, this decision will have an enormous impact on
what information is gathered and how they are implemented.
This goes somewhat beyond the operational issue if the scheduler
demands some particular inputs in some particular forms.

One highly useful information that may not be easily implemented
into any kind of dynamic scheduler is the satellite images and
forecasts.  Most observers have become avid fans of weather
satellite WEB sites in recent years, and some even believe they
can predict the weather for at least up to 24-48 hrs in advance.
Is this something we want to teach the scheduler and be incorporated
into the decision making?  Unfortunately, this data can not be easily
quantified....




					-- Min