Summary of the meeting at AOC (NRAO, Soccorro) on 13-14 Jan 2000 ---------------------------------------------------------------- Attended by: Barry Clark (NRAO) Steve Scott (OVRO) Mel Wright BIMA) Jeff Mangum (NRAO) Robert Lucas (IRAM) Francois Viallefond (Obs.Paris) Koh-Ichiro Morita (NRO) Brian Glendenning (NRAO) Joe Schwarz (ESO, by phone) Brian Butler (NRAO) G. Harris (NRAO) M. Rupen (NRAO) Min Yun (NRAO) 0) Introduction --------------- - review of the main conlusions of the MMA computing working group by S. Scott. (cf memo 164, see PDF file on Web page) - presentation by P. Napier on the status of ALMA 1) - Real time operations ------------------------- We started by a series of presentations on the command languages and mode of operations at various sites: - BIMA (M. Wright) (*) - OVRO (S. Scott) (*) - VLT data flow (J. Schwarz) (*) - Nobeyama (Koh-Ichiro Morita) (*) - Plateau de Bure (R. Lucas) (*) (*) copies of the slides/presentations are/will be on our Web page. Then B.Clark of his specs (see his email); A general discussion followed; I attempt here to summarize the conclusions. The basic need is an underlying set of software primitives that control the hardware [and quasi-real time software]. For development and engineering tests we need to be able to access these primitives by corresponding commands in a script language. This script language needs the following main features: - loops - variables and arrays - conditional tests - built-in astromical functions - procedures with input parameters Other desirable features are: a simple syntax, the possibility to interrupt a running script and restart it, .... The general observer will not directly use that script language but a GUI (Graphic User Interface), which will be used to specify a set of parameters forming one or a set of observation blocks. These will make possible the standard observation and calibration modes. Whether the GUI produces a script to control the interface remains to be decided. 2) Dynamic scheduling --------------------- Mel Wright presented his experience with dynamic scheduling at BIMA which he presented in ALMA memo 282. This experience was a technical success but was not well accepted by the users. On the opposite this works at the VLT and to some degree at Plateau de Bure (though not automated). This shows the need to introduce this feature as soon as possible in the life of ALMA. Optional check-points, typically in the middle of some projects, could be used to introduce some user response to the first observing results obtained. 3) Pipeline processing ---------------------- Ideas were presented by F. Viallefond. (see slides) Mel Wright proposes to introduce systematically a short observation of a nearby point source (typically the second-choice as a calibrator) to enable an automated evaluation of the data validity. This would produce a small time overhead only (except may be for fast phase switching, if the time spent on the calibrator is not negligible compared to the time spent on source). 4) Data format and archiving ---------------------------- The monitor data (engineering, weather) should be archived with the data There should be a versatile tool to plot parameters one vs another, any parameter vs time, data vs monitor data ... Observation logs and pipeline logs should be achived with the data version of software used to obtain and process the data should be archived with the data. The archive should include the raw data, the information needed to calibrate it (calibration curves), and images produced by the pipeline. A tool will be available to produce calibrated data on-the-fly from the archive. We have to find out if the FITS-IDI format is complete enough for our needs (probably not) and list the extensions we need. See also the AIPS++ memo on measurement sets. 5) Proposal submission ---------------------- We discussed the ideas presented by P. Schilke in an email message. The consensus was that at Phase I, the use of a Web based sensitivity calculation tool should be required, but a full image simulation tool would be optional. 6) Operator interfaces ---------------------- Monitoring data at all levels should be available through the network. Therse interfaces include also the interfaces to the staff astronomer(s) in charge of the scheduling and the pipeline. 7) Plans for the following weeks -------------------------------- For a draft report the deadline is set to Feb 29th. This report will take the shape of an ALMA memo to be widely distributed, in particular to the ASAC. The outline will be: 1. Introduction R. Lucas (general requirements, list of tools) 2. Draft of requirements in each area: 2.1. Real time operations 2.1.1 Script Language (language functionalities, active primitives) B. Clark 2.1.2 Graphical User Interface S. Scott 2.1.3 Various templates/OBs present one sample template (single field int.) J. Richer ? 2.2 Operator's interfaces J. Mangum 2.3 Dynamic Scheduler M. Wright 2.4 Pipeline F. Viallefond 2.5 Archiving M. Wright/D.Crutcher 2.6 Proposal preparation tool(s) P. Schilke We should not forget to mention the interfaces between the various software components. Each part should be about 2 pages long, so that the report not too heavy and is actually read by many people. We should have each part ready by early February, so that the whole report can circulate and be reviewed among us. 8) Next meetings ---------------- The idea now is to have a face to face meeting of the whole committee about two months after the draft report is released, and if possible after an ASAC meeting, in order to digest the reactions. A convenient place would be Paris around end April, beginning of May. The date will be fixed soon by e-mail exchanges. Though it was not actually discussed, I think it would be wise to have a phone meeting around Feb 15th for quasi-final exchanges about the draft report.