|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass94/schmidtd.html
Дата изменения: Sat Nov 4 01:46:26 2000 Дата индексирования: Tue Oct 2 02:46:51 2012 Кодировка: Поисковые слова: п п п п п п п р п р п р п р п |
73 kB PostScript reprint
D. Schmidt
Smithsonian Astrophysical Observatory, 60 Garden St., Cambridge, MA 02138
Last year, we put in place support for arbitrary actions using region descriptors. We discuss this architecture and its implications for opening up the use of regions. We then discuss the challenge of giving the subsystem an IRAF-independent interface.
Limiting attention to photons from specified source and background areas is a necessary part of astrophysical X-ray analysis. The IRAF/PROS X-ray analysis system provides the required masking capability through its regions subsystem, described by Mandel et al. (1993). The interface to the PROS regions subsystem is a language for constructing ASCII region descriptors. The language is based on a set of simple geometric shapes and a scheme for specifying complex shapes as combinations of the simple shapes. The regions subsystem supports a variety of coordinate systems, both celestial and pixel-based.
Anticipating two kinds of new requirements, we reconsidered the design of the PROS region descriptor processing subsystem. One class of new requirements would be for products other than spatial masks from region descriptors. The other new requirement would be to allow new tasks, within or outside of IRAF, to use the subsystem to generate masks or other products.
The primary function of a PROS region descriptor is to create an IRAF PLIO pixel mask to select photons for analysis. Certain secondary functions were already present in PROS and SAOimage:
Each of the secondary functions of region descriptor processing was implemented ad hoc, each in its own program with its own lexical analyzer and parser. Each parser defined the region descriptor language somewhat differently. Each parser had side effects, making it difficult to add or change functionality. There was no provision for defining new functions or novel combinations of existing functions, and the system was available only within IRAF.
We defined a set of requirements for a new implementation of the regions subsystem: (1) there should be a single language definition, and a single parser, (2) there should be a single entry to the descriptor-processing subsystem, (3) selection of functions and return of resultants should be through a simple, extensible control structure, (4) functions should be independent, so that any combination would be selectable in a single call to the parser, and (5) the interfacing of functions to the general language processing scheme should be modular, so that we could define recipes for adding and changing functionality.
We determined that the underlying metaphor of a software CPU, executing instructions compiled by the parser, remained a sound conceptual framework for the syntactic and semantic analysis of region descriptors. In this framework, we treat a descriptor like a program for a CPU that we emulate in software:
We retained xyacc as the language definition language. Using xyacc simplified generating a correct and reliable parser. The integral processing, with xyacc, from lexical analysis through compilation challenged flexibility that we wanted in using the lexical analysis and object program. We defined a uniform and extensible system of control flags to achieve the desired flexibility in using information at any stage of the linguistic analysis.
Figure 1 shows schematically how various applications use a uniform protocol to interact with the subsystem via a versatile parsing control structure, and how the underlying subsystem is structured to enable functions to access, as needed, any of the three stages of the linguistic processing.
Figure: The PROS regions subsystem program interface.
Original PostScript figure (10 kB)
This design prepared us for extending the regions subsystem's functionality and for making the subsystem available for use by programs in a more open environment. To make it easy for programmers to begin to exploit the new design, we created ``recipes'' for two ways of extending region descriptor functionality. Outlines of those procedures follow.
First, a recipe for processing a region descriptor: (1) call rg_open_parser(), to create a parsing control structure, (2) call one or more of the request setup routines, to create request/resultant structures and link them into the parsing control structure, (3) call the parser, rg_parse(), (4) retrieve the resultants through a set of macros provided, and (5) call rg_close_parser(), to release any request/resultant structures and the parsing control structure.
Second, a recipe for adding a new function: (1) define a request/resultant structure for the new option, and standard-format macros to access its fields, (2) create a slot for the new option in the parsing control structure, (3) create option setup and release routines, using standard templates, (4) integrate the option into the system of ``request set query'' routines and control flags, according to the processing required for the option, and (5) add the new functionality at one of four locations in the system, according to what form of the descriptor it uses. Full utilization of the new capabilities remains for future applications.
The redesign and re-implementation of the program interface to the IRAF/PROS regions subsystem has provided PROS programmers with a cleaner environment for developing new regions applications. It has been used successfully for more than a year. We anticipate greater benefit in the future, when applications outside of IRAF may make use of the new request/resultant protocol for much freer access to the functions of region descriptor processing.
This work was supported under NASA contract to the ROSAT Science Data Center (NAS5--30934).
73 kB PostScript reprint