ASC Technical Assessment Notes


 From Wed Oct 21 17:14:44 1998:

    3. ISIS/ASCDS interface: Dave Huenemoerder to review
       status of DM, UI, parser, ASCFIT in ISIS context.
    STATUS: DH has been having in depth technical discussions
    with Martin, Jonathan and ASCFIT folks and has others
    planned. I have asked David to prepare a summary of his
    findings to date by Monday for distrubution prior to a
    next meeting. A TI meeting with a specific agenda, as in
    Pepi's email, should also be considered but may be
    obviated by these smaller meetings.


DM: Data Model

The Data Model is an abstraction of AXAF astronomical and supporting data-types which provides a generic interface to diverse files. It is intended to hide format information from the user and developer, to provide "smart" assumptions about how the data are to be used, to package and apply descriptive information with the interface (such as coordinates), and to provide multi-dimensional filtering.

There are a few issues to investigate:

1 - Should DM be used for ISIS? (Is it the appropriate interface for the data ISIS is required to read and write?)

2 - Can it be incorporated into a "stand-alone" development environment and product (the ISIS prototype)? Is it portable? Is it modular (in terms of libraries: IRAF, CFITSIO, FITSIO)?

3 - Can/should it be emulated in a prototype, and interfaced later? If so, when?

Regarding item 2:

I have spoken to Jonathan McDowell (981016), regarding the "mechanical" issue of portability outside the ASCDS. The DM is portable between Sun-SPARC and Linux. It can, in principle, be used without IRAF libraries. It requires lex and yacc for its parser; it is bundled with CFITSIO. Currently, it requires ETOOLS, but this library is being truncated to the necessary minimum. Jonathan works in Clearcase, but also has a mini-ASCDS in which he can develop under Linux. There is no UI dependence. DM has its own parser for command-line and filter arguments (lex,yacc files).

Hence, the answer to 2 is probably "yes"; in principle, but not yet tested.

John Davis' exposure map development will make use of this DM "mini-release". We will gain experience independently of ISIS development.

Regarding item 1:

ISIS is not a generic data-analysis system which requires the manipulation of a large variety of diverse file types. Its data are primarily limited to:

a) atomic database

b) spectrum

c) response

d) models/measurements.

a) is being developed as FITS tables. b) is a Type I or Type II FITS file, an ASC standard product. Other possible inputs are: IRAF ".imh" files, or QPOE files. c) Responses are in OGIP ARF and RMF formats, as produced by other ASC software. d) is TBD.

Of these, QPOE are not supported by CFITSIO. This would be an case where DM would add value, if, for instance, one were to wish to analyze EUVE and AXAF spectra jointly. An alternative is to use a DM-tool to convert the QPOE file to FITS.

The models and measurements are an area for serious interface definition. They range from line-lists and line-fit parameters, to ASCFit model specifications (currently an ASCII script). DM does not include the the latter (ASCFit script) as one of its supported formats. Until products and formats are prototyped, it will not be clear whether the interface should be via file (e.g., exchange of products between ASCFit and ISIS), and whether DM functionality is required. Measurements are likely to be written as FITS bintables. They could also be function tables (DM does not support FITS embedded functions; that is an independent library).

Other DM features are probably not required: world-coordinate system support (our coordinates are the multi-dimensional atomic database parameters and wavelengths); filtering (CFITSIO has DM-like filtering on file read, if desired).

In conclusion: Data Model use is possible in the ISIS prototype development, but there is no clear advantage over the functionality given by direct use of CFITSIO. DM-added value may become apparent during development. Expertise on its use will come w/ exposure map development, and applicability to ISIS will become clearer in time.


Continue evaluation of DM via exposure map development. Continue prototype of ISIS with direct CFITSIO.


John Davis and I held a meeting with Aneta Siemiginowska and Malin Ljungberg (981021) to discuss ASCFit technical issues.

ASCFit provides an environment and library for inspecting, fitting, and modeling data. It needs to be closely coupled to ISIS either by file interfaces, or indirect communication by sharing the same libraries, or by actual communication between the programs. Details of exactly what data and models get shared are to be determined by the ISIS prototyping effort.

ASCFit has a parser which defines a syntax and command set for a command-line interface. Any unrecognized commands fall through to the UI. The underlying graphics packages are SM and SAOtng. Communication between applications uses Tooltalk (to SM) or XPA (for SAOtng). Tooltalk is being deprecated in favor of XPA.

The library design is not modular. In order to use, e.g., a gaussian fitting function, all these libraries are required: FITSIO, CFITSIO, XSPEC, Datamodel, TCDLIB, PSFLIB, and Numerical Recipes. (Datamodel currently also requires IRAF, but that is soon to be optional). The UI and SM libraries have been isolated.

This non-modularity makes exported use of libaries impractical, especially since most are not needed by ISIS.

However, modularity would be useful, since ISIS would eventually like to have some fitting capability (gaussian, lorentzian), and some source-model libraries (e.g., continuum). It also may wish to perform convolution by the instrument response.

The lack of modularity and the in-flux migration from Tooltalk to XPA makes immediate use impractical. Interface definition with ASCFit, however, is crucial.

Portability is important for beta-testing at external sites.


Define interfaces for file exchange between ASCFit and ISIS; Assess common functionality in modelling/fitting. Explore modularization of ASCFit libraries.

UI: User Interface

A meeting was held 10am Monday, 10/23, John Davis, David Huenemoerder, Antonella Fruscione, Mike Noble.

First, Mike and Antonella made one clarification: UI stands for "User Infrastructure", since they are responsible for more than an interface. The UI includes both a visulalization library, and an inter-process communication protocol.

The visualization library provides a common interface to plotting "engines". Currently, SM and SAOtng are supported, though the intent is to provide an interface which can support a variety of engines. A plotting meta-language is being defined and in a draft document . SM has been modified to provide a Tooltalk interface; Tooltalk is being replaced by XPM; XPM is undergoing modifications to allow non-X-windows use. The UI has a "native" mode, in which the user can bypass the parser and talk directly to the plotting engine, at the expense of the UI's knowledge of the state.

The command syntax itself is not specified, except by each application's parser, and by the Data Model filter specification. Any command not parsed by the application falls through to the UI, and is parsed against it's syntax and command list.

Data Model libraries are optional in the UI, but may become integrated into SM.

Many libraries are required to link to the UI. Among them are: errorlib, C-classes, motif wrappers (optional), strings and array libs, C++ Framework, WCS, CFITSIO, IRAF, and Data Model. The Data Model itself requires about 7 other libraries, and is constantly changing.

There is only a C++ API. There are no resources to produce a C API. C++ exceptions are also used, optionally. These are not generally portable, at least in a bug-free way, among C++ compilers. ISIS is written in C, and without a C API, it is impossible to link to the UI.

The sytem is currently complicated, fragile, and tricky to install on other systems.

It would be very difficult or impossible for ISIS to make use of the UI in a portable, stand-alone way. What ISIS could do is adopt a common syntax and dictionary. In this way, ISIS would look and feel similar, though its architecture would be different (pgplot, cfitsio, slang). ISIS could also have its own "native" mode in which one would use slang directly. Given the ISIS API and a common dictionary, it may be possible at some point to import ISIS functions into the UI. A value-added feature may be the provision of a PGPLOT interface which could also be imported into the UI.


Develop ISIS initially with the slang interface. Later, undertake "parallel" development by adding a "UI Mode" which uses a common syntax and dictionary (or subset of the UI meta-language). UI/ASCFit/DM should specify syntax, and dictionary.

ISIS development environment:

David P. Huenemoerder