Proposal Submission and Handling

Proposal submission has two sides: it should be easy and convenient for observers (including observers unfamiliar with the peculiarities of a given instrument) to write and submit proposals. From the ALMA side, it is important that proposals arrive in a form that makes it easy to store the relevant information and to process them - that includes screening for collisions with other proposals or already observed projects, checking for technical feasibility, and scientific reviewing. We try to combine these two requirements, and take a two step approach: basic requirements, which are features that the first version of the proposal preparation tool should have, and advanced features, which are convenient, but not necessary at first. However, the software should be written with these requirements in mind, and easily allow adding them.

Proposal submission will occur in two phases: phase one, in which the proposal is submitted for review; and phase two (after acceptance of the proposal), in which the necessary data for writing an observing script are submitted. Phase one requires that, beside the scientific justification, all the relevant technical informations to judge the feasibility of the proposal are present.

Basic requirements

• 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. This would be easiest if a web-based proposal preparation tool performed certain calculations, i.e. of 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.
• The technical data input for proposals should have several layers:
  • Basic interface for non-experts: input in terms of proposal goals
    • 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 changeable).

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

• Scientific justification could be postscript or pdf add-on. We don't think this needs to be computer parsable, if all the technically relevant data are available in digital form an electronically submitted anyway. People should be free to use their favorite text processing system to prepare the text and to include figures.
• 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. People shouldn't be wasting time on proposing things that have been done already.
• The proposal preparation tool should allow storing of intermediate stages to local disks, to enable trying out different parameter settings.
• Proposer should specify what is needed for real-time checking of data quality. In 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.
• The proposal should be detailed enough to judge technical feasibility and time, but does not need to go to all the detail necessary for observations. The observing script should be prepared after acceptance of the proposal with a tool that is a superset of the proposal preparation tool.

Advanced features

• 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. if one wants to map a source in HCN(4-3), one could use an already existing HCN(3-2) map as input), and easy-to-construct models by defining basic source components: disks, Gaussians, tori etc. One should aim at getting something like the NCSA Astronomy Digital Image Library for ALMA and linking this to the simulator tool. This depends on the policy for data archives to become publicly accessible.

• 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. It would be useful to use existing ALMA (or other) observations as an input data base for defining observations.
• There should be graphical tools for e.g. correlator setup, such as those in use at BIMA and 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.