Next: Implementation Design of the ASC Data Model
Previous: Data Format for the NOAO Mosaic
Up: AXAF
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

---

ASC Data Analysis Architecture

M. Conroy, W. Joye, J. Herrero, S. Doe
AXAF Science Center, Smithsonian Astrophysical Observatory, 60 Garden Street, Cambridge, MA 02138

A. Mistry
AXAF Science Center, TRW, 60 Garden Street, Cambridge, MA 02138

Abstract:

1. Introduction

The ASC must develop, distribute, and support a portable data analysis package to provide observers world-wide with the ability to analyze AXAF data. The ``open architecture'' approach adopted for the ASC Data Analysis System allows maximum reuse of existing software, while providing an environment that can be customized and adapted for user-specific or future project needs. The architecture defines loosely coupled interfaces to facilitate customization of the environment by replacement of components.

2. Data Analysis Environment

A diagram of the data analysis environment appears in Figure 1.

  
Figure: Data analysis environment. Original PostScript figure (128kB).

The components of the environment can be categorized as follows:

• Control Mechanisms A Graphical User Interface (GUI) and a simple command line interface (CLI) are required for data analysis tools and applications; this allows both interactive and batch mode control of the components. The Pipeline Controller provides a mechanism for configuring the components for automated processing and monitoring.

• Tools and Applications. Tools constitute the core of the data analysis system. They are built using layered libraries, and are used in many roles by the ASC. For automated pipeline processing, they are configured in pipeline profiles and invoked by the pipeline controller. They can be run interactively by the user from the command line or built into simple shell scripts or user-defined pipelines. Analysis applications, are built from the basic tool-box but are provided with interactive visualization and control features to facilitate the complex operations.

• Visualization components consist of image display, plot (line graphics) display, and browser displays. The Data Browser and Observation Browser provide the standard browsing capabilities and provide both ASCII screen displays and 1-D, 2-D, and 3-D image and line graphic representations.

• Infrastructure components provide the mechanisms to connect the components to each other and to the user. Inter Process Communication (IPC) is used to pass messages between tools and applications in the environment. Helper tools encapsulate IPC calls to provide command-line access to services and status information in the applications. The SAO IRAF compatible parameter interface provides a flexible mechanism for invoking tools either interactively or in batch mode. The traditional parameter interface has been extended to recognize and interpret both stand-alone tools that compute parameter settings and IPC commands and dataset parameters that allow tools and applications to share common parameter settings.

3. Data Model

The data model provides a high-level application interface (API) through which all tools and applications can interact with the data. The Data Products layer defines the data API for the tools and applications. The data products consist of the standard high-energy astrophysics data products such as event-lists, spectra, and light-curves. This interface is independent of the physical storage formats (Herrero, Oberdorf, & Conroy 1997). Figure 2 shows the layered architecture of the Data API, the data model, and the dynamic data formatting(DDF).

  
Figure: ASC Data API and Data Model. Original PostScript figure (5kB).

4. Tool Architecture

The tools represent stand-alone executables that perform single functions. Each tool is invoked with user-specified parameters and transforms input data into output data. They are designed using an ``open architecture,'' and are built using layered libraries (Conroy et al. 1996). The SAO Parameter Interface provides the mechanism by which these tools may be configured into the analysis environment when desired. The parameter values may be specified directly or via helper tools that invoke IPC calls to other parts of the environment or to a shared dataset parameter file. In this way, it is possible for a tool to perform analysis on an image region indicated by the Data Visualizer. Similarly, user scripts and pipelines can produce PostScript graphics plots when running in a batch environment, by accessing services without user interaction.

5. Visualizer Architecture

The visualization architecture also employs a layered approach which allows the graphics API to be defined independently of the image and graphics engines used to implement the functions. This layered design will allow the Data Visualizer to be built with either public domain display engines or commercially licensed engines, depending on the availability of the products. For instance, SAOtng (Mandel & Tody 1995) is the targeted public domain imaging engine, whereas IDL represents a popular commercial product that could be linked to the Data Visualizer.

The visualization component provides support for the standard types of displays: 2-D and 3-D image plots, 2-axis scatter plots, histogram (1-D line) plots, strip-plots, predicted/actual/residual plots, contour plots, and sky-grid plots with catalog overlays. The Data Visualizer must also provide the interactive ability to draw markers such as circle, ellipses, contours, masks, polygons and boxes, and to display cursor coordinate read-outs in any of the support World Coordinate Systems (WCS). The IPC mechanism coupled with the SAO parameter interface can be used to communicate these selections to the analysis tools.

6. Application Architecture

The Modeling/Fitting Application (Doe et al. 1997) is an example of a high-level application that provides access to the model building, fitting, and visualization tools in an interactive application. One of the motivations for building this application is to allow graphical monitoring of the progress of the fitting process. The modeling portion of the application is controlled via a mini-language that provides natural language constructs to define the model components, operations, and the interrelationship between the modeling parameters.

7. Control Architecture

Navigator provides a graphical user interface (GUI) to the entire ASC system. The Data Analysis GUI represents the components of the Navigator that interact with the portable Data Analysis system. The GUI provides a powerful and intuitive interface for interactive analysis. The command-line interface allows access to the analysis components via a simple interface. This is particularly important to support semi-automatic user processing through scripts. The pipeline controller is the third control component. It can be invoked on pre-defined or user-defined pipeline profiles that execute complex sequences of operations.

Acknowledgments:

This project is supported by NASA contract NAS8-39073 (ASC). We also gratefully acknowledge the many fruitful conversations with the other members of the ASC Data System and Science Data System.

References:

Conroy, M., Doe, S., & Herrero, J. 1996, in Astronomical Data Analysis Software and Systems V, ASP Conf. Ser., Vol. 101, eds. G. H. Jacoby and J. Barnes (San Francisco, ASP), 285

Doe, S., Sieminginowska, A., Joye, W., & McDowell, J. 1997, this volume

Herrero, J., Oberdorf, O., & Conroy, M. 1997, this volume

Mandel, E., & Tody, D. 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), 15

Next: Implementation Design of the ASC Data Model
Previous: Data Format for the NOAO Mosaic
Up: AXAF
Table of Contents - Index - PS reprint - PDF reprint