Brian Glendenning has mentioned by e-mail that the software
group has been assumed to agree on the conclusions of ALMA
memo 331 (the phase tracking center is kept fixed within a scan
in an OTF mosaic).
Any strong objection should be written down, circulated in
the next few days, and brought to the attention of ASAC
How does the Scheduler deals with Sub-arrays ?
Joe Schwarz raised the point of the scheduling
complexities that are implied by the possible simultaneous
scheduling of programs using subarrays (see his email).
We noted that most projects will use as many antennas as
possible for obvious sensitivity and image quality reasons; and that
an efficient scheduling process is a very strong requirement for the
efficiency of the instrument.
We agreed that, for the software analysis in progress, the
baseline plan for the scheduler is to schedule one research
project at a time, using all available antennas while some
antennas have been taken out by the staff as one or several
calibration subarrays. The research projects to be scheduled must
specify e.g. a minimum required number of antennas.
We remind that scheduler studies are to be started; one of
their goals should be to investigate whether more sophisticated
subarray scheduling behaviour is indeed feasible while keeping a
reasonably simple system.
Should we mention quality control and associated software ?
This issue came up during the Analysis Group meeting in
Socorro. We should mention in our requirements that poorly
functioning or broken hardware detected in pipeline data processing
must in some way be handled at the observatory level in order to:
allow triggerring the repairing actions
inform the scheduler that projects relying on this hardware
must be e.g. put to a hold state
Also the requirements on operator's interface were omitted in
the current version of requirements.
Actual contents and release date of our second report
The report will contain:
Short introduction
The requirement list
Use Cases (General and Observing Modes)
Operating assumptions or questions as prepared by Joe
Schwarz (if available)
The goal is to issue the report mid-january. For this we
must iterate on the Observing Modes Use Cases. We set a deadline to
December 20th for each one to communicate comments and
corrections to the authors of each UC. These comments should be sent
to the e-mail list (we want these to be discussed openly since the
consistency of the use cases is an important issue). The authors
will have till the next phone meeting (2001 Jan 15th) to update the
Use Cases so that they are incorporated in the report.
Next phone meeting: Monday January 15th, 16h UT.
Next face-to-face meeting: March 1 & 2 or 5 & 6 in
Grenoble (Please give me your preferences if any).
Action Items
R. Lucas to phrase requirement on quality control, and operator
interface.
Analysis group to update General Use Cases in the BSCW (in progress)
Each one to carefully review the observing modes use cases ( link
to the BSCW
area) and send comments and corrections to
the e-mail list before December 20th.
After December 20th, the author of each use case will edit it and
upload it to the BSCW area.
A. Wootten to restart the matter of special observing modes.
