Next: The Gemini Quick Look System
Up: Data Pipelines
Previous: The Client Server Design of the Gemini Data Handling System
Table of Contents - Subject Index - Author Index - Search - PS reprint - PDF reprint

Jaeger, S., Dunn, J., Cockayne, S., Gaudet, S., & Hill, N. 1999, in ASP Conf. Ser., Vol. 172, Astronomical Data Analysis Software and Systems VIII, eds. D. M. Mehringer, R. L. Plante, & D. A. Roberts (San Francisco: ASP), 159

Interfacing with the Gemini Data Handling System

Shannon Jaeger, Jennifer Dunn, Steve Cockayne, Séverin Gaudet, Norman Hill
National Research Council Canada/Herzberg Institute of Astrophysics, 5071 West Saanich Rd. Victoria, B.C. Canada V8X 4M6

Abstract:

The Gemini Telescopes Data Handling System (DHS), developed by the Canadian Astronomy Data Centre, consists of eight server programs, a graphical user interface (GUI) and a tool for displaying images. The DHS GUI controls and monitors the entire DHS by communicating with only two of the eight DHS server programs. This paper describes the communication model used by the DHS GUI.

1. DHS Overview

The role the DHS plays within the Gemini systems is that of the the data controller. DHS is data-driven, acting on any data it receives from any Gemini principal system. DHS is responsible for maintaining a permanent data store, creation of archivable media, data processing, and displaying data for quality control. These tasks are performed by the eight server programs described below and in more detail in Hill et al. (1999b).

Command Server: is the command interface between DHS and external software, including the DHS GUI.
Status Server: is the interface between DHS and the outside world for outgoing status information. It also monitors resource usage, such as disk and database space.
Data Server: accepts bulk data from other Gemini systems, and informs other DHS servers when data is available. It is the data manager for the DHS (Dunn et al. 1999a).
Quick Look Server: (Hill et al. 1999a) and Quick Look Tool together are responsible for displaying selected data within the DHS in a timely and useful manner.
Storage Server: is responsible for the creation of media. This server shares source code and concepts with the European Southern Observatory's ASTO system, (Dunn et al. 1999b).
History Server: collects time-stamped history records from all Gemini systems and stores them in a database.
On-line Data Processing Server: processes data collected by the Gemini Telescopes. The processed data is then archived and/or sent to the Quick Look Server for display.
Synchronous Data Processing Server: performs data processing tasks for other Gemini Systems. The server returns processed results to the Gemini system which initiated the task.

The DHS will run at both the base and summit facilities for both Gemini Telescope locations: Cerra Pachon, Chile and Mauna Kea, Hawaii. It is expected that some subset of the set of DHS servers will run at each facility.

2. DHS GUI Overview

**Figure 1:** DHS GUI/DHS server communication model.
$\begin{figure} \epsscale{.5} \plotone{jaegersd1.eps} \end{figure}$

The primary functions of the DHS graphical user interface (GUI) are to display the current status of the DHS and to provide a means of controlling the DHS. Status information is displayed textually and graphically on the various components of the GUI. The DHS is controlled through various commands, which are typically requested from the GUI by selecting buttons.

The DHS GUI behaves like an application which is external to DHS, despite being the controller and monitor of the DHS. The GUI communicates directly to two of the eight servers described above: the Status and Command servers. Figure 1 shows the channels of communication between the DHS and the DHS graphical user interface.

The entire DHS GUI was written in Tcl/Tk (Ousterhout 1994) and uses the OCSWish (Walker & Gilles 1998) interpreter. The OCSWish Tcl/Tk interpreter was provided by the Gemini International Project Office, Software and Controls group. One facility the OCSWish interpreter provides are mechanisms for sending commands to DHS servers and for the reception of status information. The status information may be received from an Experimental Physics and Industrial Control System (EPICS) database or directly from the DHS Status server. The GUI also uses the object oriented facilities provided by the [incr Tcl]/[incr Tk] Tcl/Tk extension to encapsulate some of its components. The ESO GUI guidelines (Ballester & Comin 1993) were used to determine the general layout and design of the GUI.

The main window of the DHS console is shown in Fig. 2. This window is the only window shown when the Console is initially displayed. On the main window there are buttons that send commands to the entire DHS, such as a shutdown command. The main window also displays the current DHS status and the resource usage.

Each DHS subsystem server can be controlled from its subsystem window. A subsystem's window is displayed when the appropriate button is selected in the ``Subsystem Overview'' panel on the main window. The subsystem window also displays status information which pertains only to the particular subsystem. An example of a subsystem window is shown in Fig. 3, the Storage Server's subsystem window. The Storage Server is one of the more complex subsystem windows. The top half of the window is the same for all subsystems - standard status information plus buttons for executing the standard commands. The bottom half is a series of buttons which control the creation of media, see Dunn (1999a) for more details.

**Figure 2:** DHS GUI main window.
$\begin{figure} \center \epsscale{.70} \plotone{jaegersd2.eps} \end{figure}$

**Figure 3:** DHS GUI Storage server subsystem window.
$\begin{figure} \center \epsscale{0.9} \plotone{jaegersd3.eps} \end{figure}$

3. Design Critique

As with all design models there are advantages and disadvantages. One of the most obvious advantages is the minimization of connections. There are only two connections the user interface must maintain; one to the Status Server and one to the Command Server.

A second advantage is the ease with which the command interface and status interface have each been encapsulated into a single module/object. This was easy to implement since each has a single contact point. External software, such as the Console, should not be forced to have full knowledge of the DHS design in order to interface with it, and by having only two servers to be concerned with this is achieved. Also, the encapsulation makes maintenance and debugging of the DHS Console software easier.

The third advantage to the design is the DHS Console is able to monitor and control multiple server programs instead of using a separate GUI for each server. Screen real-estate is a precious commodity, and by having an single GUI for the entire system the real-estate required is drastically reduced.

The minimization of connections is also a disadvantage. If anything goes wrong with the status server the GUI will stop reporting status information for the entire DHS. Similarly, if the command server stops processing commands the GUI can no longer control the DHS. Having a single point of failure is an undesirable situation but the advantages of this design outweigh this disadvantage.

References

Ballester, P. & Comin, M. 1993, ESO Graphical User Interface Common Conventions (GEN-SPE-ESO-00000-0266) (Garching: ESO)

Dunn, J., Cockayne, S., Gaudet, S., Jaeger, S., & Albrecht, M. 1999a, this volume, 265

Dunn, J., Jaeger, S., Hill, N., Gaudet, S., & Cockayne, S. 1999b, this volume, 167

Hill, N., Gaudet, S., Dunn, J., Jaeger, S., & Cockayne, S. 1999a, this volume, 163

$\ibid$ , 1999b, this volume, 155

Ousterhout, J. K. 1994, Tcl and the Tk Toolkit (Reading: Addison-Wesley)

Walker, S. & Gillies, K 1998, OcsWish Technical Manual
(ocs.ocs.015-OcsWishTechnical/02, Gemini Project)

adass@ncsa.uiuc.edu