Summary of SSR phone meeting on 2000-06-07 16h UT
-------------------------------------------------

1 - Final status of Memo 293.

Memo 293 was reviewed early May.  I edited replies to all the
  comments; these comments were revised after the review and the memo
  itself was slightly revised to take into account the comments. It
  will be posted as a revised Alma Memo. The comment list will be
  available in the Computer group home page.

One comment that was mentioned is that there should be a way to
  execute OBs conditionally inside an observing project: do C only if
  A and B have been done ...

As a result a list of questions has been sent to the Project
  Scientists and the ASAC. They will discuss those issues.


2 - Summary of the work initiated in Arching in May 15-19 on Use
  Cases.


`The Mysterious Use Cases':

The ALMA joint software group as a whole has agreed to use the Unified
  Process to design software. This methodology makes use of the
  Unified Modeling Language (ML), in which the requirements are (at
  least partly) described in the form of Use Cases, which in my view
  are a (rather) formal way to express how the software should behave
  in both expected and [not too] unexpected cases.

So a group has been formed to express our requirements into Use Cases.
  Rein Warmers (EGO), Dirk Murders (BPI), Garth Harris (NRAO), and
  myself, with some help for GianLuca Chiozzi (ESO).
  
During a week we identified/drafted about 20 Use Cases; the work is
  continuing remotely and we plan to gather again at the end of July
  in Grenoble to have something that can be reviewed by the SSR.

Use Cases should not be identified with observing modes. They are at a
  much higher level and describe the functionalities of the software,
  though observing modes will at some points be described as Use Cases
  too.

I will post on the web an example and/or a link to existing Use Cases
  (e.g. from ESO).


3 - Requirement lists: status on each area.

We have draft lists on some areas: real-time control, pipeline,
  archiving.  This is an on-going process. drafted should be p[posted
  on the list and discussed freely.

On real-time control: we agreed to rename the Observation Table to
  Observation Descriptor: it is set set of parameters that fully
  describe the atom observation. We should make in it a distinction
  between astronomical input and technical parameters that are derived
  from them using quasi real-time setup commands.


4 - Discuss Mel's idea of test projects to validate the requirements
    (see his e-mail of 2000-05-09)

This is a very good idea. We should write a text description for each
  project: give observing modes and their main parameters, identify
  OBs, scheduling issues, reduction procedures, and so on.

I propose each of us send me a description for proposed projects and
  I'll put them on our Web page, so that we can make use of them in a
  uniform way. 
  
5 - Discuss the points raised earlier by Steve on blanking and
    flagging/ correlator data processing

. Blanking: would enable to lower the data rate by using longer
  integrations; we could blank bad tracking, bad LO lock ... The
  thresholds for these should be part of astronomer input in the
  proposal. We did not reach a definite agreement on this point.  With
  dynamic scheduling one should not observe at a too high frequency
  under windy conditions. On the other hand the low transparency
  useful time can be increased if we allow the use of some windy
  conditions ... Blanking has the advantage of clipping the bad
  tracking errors which may actually be distributed in a non-Gaussian
  way.

. Flagging: is more a consensus. We need it at the level of antennas
  for pointing errors, shadowing, phase locking problems, may be also
  for interference someday.  We may also need to erase (self-created)
  interference lines and thus flag some spectral channels in real
  time. 
  

. lag apodization window : The default should be reasonable. The width
  and the shape of the function used should be available to the
  experienced user.

. data compression: 
  
  - in time, some compression will be needed for high data rates like
  mosaics. It is not needed to use different integration times in a
  baseline-based way (short baselines will not be the vast majority in
  the foreseen configurations).

  - in frequency: unused frequency bands may be averaged, and only the
  average kept as a diagnostic; the cost of re-observing to examine
  those windows later has to be compared with the cost of a larger
  archive.


6- next phone meeting: Wed July 5th, 16h UT.