Re: Agenda for Monday meeting.

[Peter Schilke <schilke@MPIfR-Bonn.MPG.de>]

Hi,

    I'm afraid I can't attend the telecon later today.  However, I have
made a few notes regarding proposal submission and handling.  The list
isn't very well ordered yet, and of course includes thoughts other
people have put forward in various discussions.

    Peter

--
Peter Schilke                           mailto:schilke@mpifr-bonn.mpg.de
Max-Planck-Institut f"ur Radioastronomie
Auf dem H"ugel 69                       Tel.   49-228-525-392
D-53121 Bonn                            FAX    49-228-525-229
Germany                                 http://www.mpifr-bonn.mpg.de/staff/schilke


Proposal submission and handling
--------------------------------

- Proposals should be submitted electronically.

- All technical input should be stored in a database, and should
  therefore be computer readable.  There should be enough information
  to provide the proposer (and the reviewer) with a detailed idea of
  the technical feasibility of the project.  

- Basic checking for conflicts against a database of already conducted
  observations should be done at time of submission to give instant
  feedback to the proposer.

- This database should also be accessible for interactive searching
  prior to proposal writing.  We don't want people to waste time on
  proposing things that have been done already.

- Scientific justification could be postscript or pdf add-on. I don't
  think this needs to be computer parsable, if all the technically
  relevant data are available elsewhere.

- The proposal preparation tool should run locally (to allow storing
  of intermediate stages, and playing around with various
  parameters). 

- Input data:
  Several layers:
  - Basic interface for non-experts: input in terms of desired results
	- angular resolution, largest structure <instead of
          configurations>, 
        - Source Flux and S/N or RMS <instead of observing time>,
        - Line frequencies and desired resolution in km/s <instead of
          correlator setup>, 
        - image fidelity needed <instead of specifying particular
          calibration strategies>.

     - This translates into observing mode, configurations, observing
       time, correlator setup, all of which should be checkable (and
       changable).

  - Expert interface: one should be able to override the basic mode
    and specify ALL parameters manually.

  - Links to databases like SIMBAD or NED should be available to
    define coordinates.

  - On the basis of a map (from survey databases, or from databases of
    previous observations) one should be able to define the area to be
    mapped interactively with a mouse.

  - There should be graphical tools for e.g. correlator setup, such as
    the one written by Merce Crosas for the SMA.  This should be
    linked to existing line surveys for a variety of sources, to be
    able to place correlator units visually at interesting regions, or
    to simulated spectra based on physical models.  This means a line
    database (such as the JPL catalog) should also be linked to the tool.
 
  - There should be a simulator (attached to the proposal preparation
    tool) to produce S/N, dirty beams and, for suitable source models,
    maps with the desired configurations.  There should be a database
    of real data as input (e.g. I want to map a source in HCN(4-3) and
    use an already existing HCN(3-2) map as input), and easy to
    construct models by defining basic source components: disks,
    Gaussians, tori etc.

   - Data bases: It would be handy to use existing ALMA (or other)
     observations as an input data base for defining observations.
     One should aim at getting something like the NCSA Astronomy
     Digital Image Library for ALMA and linking this to the simulator
     tool. This leads to the following

   - QUESTION to SAC or whoever decides these things: the data
     (including the automatically generated images) will be archived
     anyway, in how far (and after which period) should this archive
     be available to the public?

  - The proposal preparation tool should provide the proposer (and the
    reviewer) with a good idea of the technological feasibility of the
    project, i.e. time required under average conditions, fraction of
    time available at the site for the specified requirements
    (e.g. phase stability < xy degrees at a specific frequency), etc.
 
  - Proposer should specify what's needed for real-time checking of
    data quality. Im some cases, breakpoints could be defined, after
    which an observations is stopped and only resumed (possibly in
    modified form) after examination of the data obtained so far by
    the proposer.

  - Question: how detailed should the proposal be?  A very detailed
    proposal would produce a useable observing script already.
    Possibly it would be better to have a two-stage process: 
    - Proposal detailed enough to judge technical feasibility and time,
      but not going to all the detail necessary for observations.  
    - After acceptance preparation of an observing script based on the
      proposal.