Figure: Data analysis environment. Original PostScript figure (128kB).
|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass96/conroym.html
Дата изменения: Tue Jun 23 21:14:23 1998 Дата индексирования: Tue Oct 2 02:15:47 2012 Кодировка: Поисковые слова: п п п п п п п п р п р п р п р п р п |
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
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
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.
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:
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).
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.
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.
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.
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.
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.
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