Next: Filtering KPNO LaTeX Observing Proposals with Perl
Previous: The Sociology of Astronomical Publication Using ADS and ADAMS
Up: Proposal Processing
Table of Contents - Index - PS reprint - PDF reprint

---

Astronomical Data Analysis Software and Systems VI
ASP Conference Series, Vol. 125, 1997
Editors: Gareth Hunt and H. E. Payne

---

A Distributed System for ``Phase II'' Proposal Preparation

A. M. Chavan and M. A. Albrecht
European Southern Observatory, Karl-Schwarzschild-Str. 2, D-85748 Garching, Germany; E-mail: amchavan@eso.org

Abstract:

1. Introduction

In order to maximize the scientific throughput of the system, a complex and expensive observatory like ESO's VLT should let the most demanding observing programmes take advantage of the very best weather conditions. Traditionally, this has not been possible: observers have had to cope with the atmospheric conditions prevailing during the night assigned to them. ESO is experimenting with operating telescopes in service observing mode, whereby staff observers execute scientific programmes on behalf of the investigators (this mode of operation is also called queue observing).

To make service mode observing possible, scientific programmes must be described in great detail-a process commonly defined as Phase II proposal preparation. ESO is developing a Phase II Proposal Preparation system (P2PP) to collect detailed scientific programme descriptions, in the form of observation blocks (OB). The system is initially directed to support service mode observing (that is, a significant fraction of the VLT observations), but will eventually be used by ``classical mode'' observers as well: OBs will be the main input to the VLT's Data Flow System (Grosbøl & Peron 1997).

2. Observation Blocks

VLT observing programmes will be composed of several observation blocks, each coupling a target ( what should be observed) with a description of how the observation itself should be carried on; observation blocks represent a high level view of VLT operations. Several scheduling constraints may be specified for OBs, like worst acceptable seeing, absolute timing for transient phenomena, chaining of observations, maximum acceptable airmass, etc.

Targets (technically target packages) are described in terms of coordinates, proper motion, magnitude, color, and all other information which may be needed to acquire them and track them during exposure. This includes one or more guide stars.

The observation description is composed of series of standard operations, called templates: typical templates include target acquisition, science exposures, and calibration frames. For each template to be executed, astronomers need to specify a set of parameters, like filter names, exposure times, CCD readout mode, etc. These parameters specify a full instrumental configuration as well as execution details, like the pattern of images for a mosaic template.

Targets and observation descriptions can be shared among OBs, as shown in Figure 1, thus allowing astronomers to easily group related observations.

  
Figure: Targets TP1 and TP1 are observed in the same way, since observation blocks OB1 and OB2 share the same observation description, OD1. Conversely, TP3 is shared by two observation blocks, OB3 and OB4. The investigator wishes to observe the same target in two different ways: e.g., with an optical imager and with a spectrograph. Original PostScript figure (17kB).

3. A Distributed System

For privacy and reliability of information, observation blocks will be stored in a central repository at ESO. Other important services, like instrument simulators, data servers (Albrecht, Brighton, & Herlin 1997), and help pages, will be provided centrally by ESO as well. However, it is imperative that (a) P2PP can take advantage of the investigators' own computing facilities, and (b) astronomers can prepare their observations even when they are not connected to the Internet. These requirements dictate the design of a distributed, client-server system: ``lightweight'' clients interact with central servers, and can maintain a local cache of information.

3.1. Architecture

The P2PP system is therefore a collection of independent stand-alone modules, structured in a client/server relationship. The server modules run at ESO and handle centralized services, like database access for OB storage, exposure time calculation, etc., while client modules run on the OB's author's host.

Most client modules generate, display, and process part of an OB's information content: there is a module for describing targets, one for observations descriptions, etc. One special client module is used for global OB operations, like transfer of OBs to and from the central (ESO) database.

All modules offer a graphical user interface. The overall software architecture is shown in Figure 2. P2PP is being implemented in C++ and Tcl/Tk; it uses HTTP as the communication protocol between clients and servers.

  
Figure: P2PP architecture. Original PostScript figure (31kB).

4. P2PP and the VLT Data Flow System

ESO's Phase II Proposal Preparation system is an integral part of the VLT Data Flow System (DFS). Observation blocks are built on the basis of information collected by the Phase I Proposal Handling and Reporting System (Chavan 1995), and are fed downstream to the VLT Scheduling Tools (Chavan 1996)-which we are developing in cooperation with the Space Telescope Science Institute-and to the VLT Control Software.

All other subsystems of the DFS-including archiving, pipeline processing, and quality control-deal with observation blocks as well: OBs represent the basic quantum of information flowing through the VLT system.

5. Planning and Development

The first operational version of P2PP will support preparation of observations for the ESO's 3.5m New Technology Telescope, and will be made available in January 1997. The first VLT version of the system will be delivered in the spring of 1998.

The Web is already an important enabling technology. In the future, we hope to be able to use tools like the Java programming language to provide distributed tools that will run transparently on different hosts.

Acknowledgments:

We are grateful to the members of the ESO Data Flow Project Team for the long discussions during which the concepts described here were defined.

References:

Albrecht, M., Brighton, A., & Herlin, T. 1997, this volume

Chavan, A. M., & Albrecht, M. A. 1995, in Astronomical Data Analysis Software and Systems IV, ASP Conf. Ser., Vol. 77, eds. R. A. Shaw, H. E. Payne & J. J. E. Hayes (San Francisco, ASP), 58

Chavan, A. M., Johnston, M., & Albrecht, M. A. 1996, in ASP Conf. Ser., Vol. 87, New Observing Modes for the Next Century, ed. T. A. Boroson, J. K. Davies, & E. I. Robson (San Francisco: ASP)

Grosbøl, P., & Peron, M. 1997, this volume

Next: Filtering KPNO LaTeX Observing Proposals with Perl
Previous: The Sociology of Astronomical Publication Using ADS and ADAMS
Up: Proposal Processing
Table of Contents - Index - PS reprint - PDF reprint