[asac] Questions from ALMA-SSR to ASAC
Al Wootten
awootten at NRAO.EDU
Fri May 26 11:48:02 EDT 2000
---------------------------------- D R A F T ----------------------------------
to ALMA Project Scientists and Alma Science Advisory Committee Members:
-----------------------------------------------------------------------
Object: Project-wide issues of specific interest to Science Software Requirements
During our past six months of work in the Science Software
Requirements Committee we have encountered several issues on which
we agree that further input on your side will be needed before our
work can be completed. Our preliminary report (ALMA memo 293) has
been recently officially reviewed and we take this opportunity to
raise the following questions. These are mainly issues related to the
way ALMA is operated as a whole. For each issue we would like to
have either a definite answer or a baseline/fall-back
alternative. The questions are given in order of decreasing importance.
1) Array Scheduling
We have been assuming that ALMA will be dynamically scheduled so
that each project is observed during weather conditions (seeing,
opacity, wind) that allow its objectives to be achieved. This
implies dynamic scheduling in near real time (Dynamic Scheduling) as
stressed in mma memo 164, and in ALMA Project Book, Chapter
2(III.4). This has implications on the feedback from the PI, on the
basis of calibration data and images produced by the pipeline: this
feedback can only be offered at the end of one transit (observing
session), assuming the project observations are divided into several
transits either due to schedule optimization (as high elevations are
preferred) or intentionally by the insertion of breakpoints. This
limitation on `interactivity' has to be realized. We believe it is a
small price to pay for the increase in productivity expected from
dynamic scheduling.
An alternate scheduling method is the traditional interactive
observing, which should be available since it can be useful for test
purposes and for special -- timely and unforeseen -- observations.
Our question: Is dynamic scheduling to be the default mode of
scheduling, accepting the restricted interactivity implied by this
mode ?
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 ?
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) ?
- Control on the dynamic scheduling process
- Communication with the PIs if needed
Our question: Can the relative duties of the staff in charge of
controlling the array be already outlined ?
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) ?
4.2 if public data is reprocessed in the pipeline by others, to search
for unforeseen scientific results, does this start a new proprietary
period ?
Our question: Can the proprietary data policy of ALMA be already
outlined ?
5) Special modes
Some specific observations (Sun, Pulsars, ...) may need very short
integration times, fast frequency changes, ... for which the exact
scientific software (and hardware ?) requirements need to be
investigated in detail. For these issues we would like having
specialized astronomers as correspondents, so that we may include
their contributions in our requirements, in a coherent manner.
6) Other details
- is an audio channel from the antenna cabins to the operator
planned ? (see comment 95)
- We assume, as DSB mode is clearly an option for some frequency
bands, that side band separation has to be handled by software for
interferometric work in those bands.
Robert Lucas,
on behalf of the Science Software Requirements Committee
More information about the Asac
mailing list