[asac] SSR comments

[Al Wootten]

Our question: Is dynamic scheduling to be the default mode of
    scheduling, accepting the restricted interactivity implied by this
    mode ?
		
		My recollection is that this is stated in Chapter 2 of the Project
Book.
		
  2) Purpose of the pipeline
 
    The data flow ALMA Project Book, Chapter 2(III.5) will include a
    pipeline that may be used to  fulfill several purposes:
 
    a) check that the data obtained can be calibrated, with feed back to
      the observing process to use the optimal phase calibration cycle.
 
    b) give feed back to the dynamic scheduler by monitoring the
observed
      phase noise.
 
    c) produce calibrated uv data and maps of test quasars to check in
      real-time the quality of observations, with feed back to the
      dynamic scheduler.
 
    d) produce calibrated uv data and maps of the project source(s) to
      enable the PI to evaluate her/his data at the end of the observing
      session and to proceed with scientific interpretation when the
      project is finished (after improved reduction if needed), while
      incrementing the ALMA data archives.
 
    e) use calibrated uv data and maps of the project source(s) in order
      to derive simple quality parameters (noise level, signal to noise
      ratio) that may be used to define when the project goals are
      attained.
 
    f) use calibrated uv data and maps of the project source(s) in order
      to derive similar or more sophisticated parameters (source size,
      number of sources ... see examples in memo 293) to be fed back
      into the project's observing process, which may then take
      automatic decisions.
 
    While we believe that a, b, c and d should be implemented as
    baseline features, there is some concern that f) and maybe e) might
    be too ambitious goals (software has a cost too) or even may
    increase the distance between the astronomers and the instrument to
    an unwanted level.
 
  Our question: Which degree of sophistication should be set as a goal
  for the ALMA data pipeline ?
 
Through d) is necessary for widebased support of astronomers and should
be
a goal of the pipeline.  e) should be a goal, perhaps to be explored on
existing
arrays.  I think f) is probably too distant a goal for initial
implementation.
Data through d) should come back to the astronomer remotely in realtime
for
interaction.  e) can then be done semi-locally (i.e. data may exist on
his machine
or on the remote machine) at a breakpoint.  f) could be implemented
locally,
by the astronomer on his home workstation after receiving the
dataproduct;
probably the full dataproduct will not be deliverable over the net from
Chajnantor.
The project could then proceed after consideration, possibly at several
days
delay.

  3) Operational aspects
 
    For the specification of GUI (graphical User Interfaces) a clear
    description of the relative duties of the operators and local staff
    astronomers will be needed, in view of the following tasks
 
    - Allocation of antennas to simultaneous projects (e.g. a sub-array
      for calibration, a sub-array used for astronomy, some antennas in
      maintenance) ?
 
The operator controls dynamic scheduling and assignment of antenna
resources,
such as might occur at the VLA now upon advice of the astronomer runnung
the program,
or, in his absence, the local staff astronomer.

  4) Policy on data propriety:
 
    We are assuming, as is the usual practice in most observatories,
    that only the proposing team has access to the data during a limited
    proprietary period and that the data ultimately become public. The
    actual length of the propriety period can be probably be set later,
    but some policy questions may affect the software requirements, such
    as:
 
    4.1 is only the scientific data covered, or all header information
    including monitoring data, or some header information only
    (like coordinates and frequencies) ?
 
All data, particularly calibration data, should be available.  All
header information should be available so that a previous observer for
example could reconstruct the state of the array when his project
commenced.

Reprocessing of data should not commence a new propiertary period.

An audio channel would be useful.  The remote observer should have audio
contact with the operator or with the antenna channel also.