ALMA Science Software Requirements (SSR) -- Step 1

[jschwarz <jschwarz@eso.org>]

- A joint (Europe-US) Science Software Requirements (SSR) committee is
being formed and your active participation as a member would make an
important contribution to the success of the ALMA project.  Though
this committee is not yet officially set up, we would like to start
discussing matters informally by e-mail. 

- An e-mail exploder for the SSR group has been set up with the
imaginative name: ALMASSR@eso.org. 

- The task of this committee is to prepare the high-level
scientific/operational requirements (as well as their priorities) to
be used as input to the Analysis and Design phase of software
development.  This committee will be advisory to the heads of the
Software Group (Brian and Gianni).

- The first draft of the high-level requirements should be made
available for reviewing by late January.

- We need to have an observatory-wide operations concept before we can
talk about the requirements for the software itself. Once the first
principles are agreed upon, we can prepare a 1-2 page document
presenting an operational concept for ALMA software. This document
should be ready before the meeting at ESO on 27 - 28 October, so that
it can be discussed by those present at this meeting; naturally this
document 
will also have to be discussed by the Science Group members. 

- The main topics which should be addressed include:

   1) Astronomer Input at proposal submission
     . Who are the "customers"? What support will they need?
          a) Experienced radio astronomers
          b) Newcomers with little or no previous radio observing
             experience
     . Probably two levels of complexity : standard projects / more
             sophisticated

   2) Description of observing modes
     . Interferometry: single field / mosaics / on-the-fly mosaics
     . Total power: on the fly maps / on-off  

   3) Real-Time Software
     . Antenna control, receiver tuning & LO settings, correlator
control,
          general synchronisation: what are the constraints that should
be set                     by astronomical needs ?

   4) Flexible Scheduling

   5) On line (automatic) data reduction:
     . Calibration and data evaluation
     . Mapping 
     . interface with flexible scheduling

   6) Off line data reduction 
     . What do we assume about the needs of offline users?
         a) They will use only what we provide them?
         b) They may all have their favorite reduction packages (AIPS++,
                GIPSY, GILDAS, IDL, IRAF, ...). If so, what will they
have to                 do to access ALMA data from within their
preferred software?

   7) Data formats and Archiving 
     . Should we use FITS all the way ? If so, do we need to get
           extensions to the standard approved?
     . Do we need a specific format for raw data?
     . How much data will need to be archived? Where will this be done?
     . What access is to be provided to the community--all data via the
net?            only catalogs? snapshots?

- The first thing to do is probably to consult existing work:

        - LSA/MMA feasibility study 
        - MMA Computing Working Group Report 
        (http://www.mma.nrao.edu/memos/html-memos/abstracts/abs164.html)

        - MMA Computing (Project Book)
(http://www.tuc.nrao.edu/~demerson/project_book/chap12/chap12.html)
        - MMA memo 167 (Mark Holdaway) 
        (http://www.mma.nrao.edu/memos/html-memos/abstracts/abs167.html)

        - see http://www.jach.hawaii.edu/~rpt/mmaswg, for flexible
scheduling
        - Spike: http://www.stsci.edu/spike/index.html

        - other -- suggestions?

Any and all suggestions concerning this way of proceeding will be
welcome.

Robert Lucas (IRAM) and Joseph Schwarz (ESO).



Date: Thu, 27 Jan 2000 11:40:33 +0100 (MET)
To: lucas@iram.fr
From: Majordomo@web3.hq.eso.org
Subject: Majordomo file: list 'alma-sw-ssr' file 'alma-sw-ssr.000104'

--