The Elixir System includes several types of data abstraction. The Elixir configuration system (Configuration System) represents one level of abstraction: parameters needed by Elixir programs may have values defined in the configuration system which depend on other parameters. Another data abstraction is performed by the photcode system, which is described in some detail in elsewhere (Photometry Calibration).

FITS keyword abstractions

One critical type of data abstraction is the abstraction of the FITS header keywords needed by any Elixir program. It is a common problem in astronomical data analysis systems that FITS keywords used by one telescope & camera are rarely the same as used by another. Even the most basic of keywords, such as the keyword for the exposure time, are extremely inconsistent. In this case, the following keywords have all been used: EXPTIME, EXPOSURE, OPENTIME, ETIME, and certainly many more. A program which needs to read an image header and meaningfully use the exposure time needs to have a way of distinguishing these keywords.

The Elixir programs achieve this goal by abstracting the concept of the exposure time and using the configuration system to define the appropriate keyword for given camera or telescope system. In this particular case, the configuration system includes an entry for the EXPTIME-KEYWORD. The associated value of this keyword is defined as EXPTIME for cfh12k, EXPOSURE for suprime, etc. In this way, any Elixir program which needs to interpret the exposure time simply looks up the value of EXPTIME-KEYWORD and then looks in the header for the keyword defined by this entry.

This same mechanism is used for all keywords which need to be abstracted. In some cases, the value of the defined FITS keyword requires some additional explanation, in which case configuration entries for the additional information are also provided. An excellent example is the keyword used to identify the date in a FITS header. Often the date is stored with a keyword such as DATE-OBS. However, the value associated with DATE-OBS may be a date in the American format MM/DD/YYYY, or the European format DD/MM/YYYY, or potentially in signficance order YYYY/MM/DD. In addition to an Elixir configuration entry for DATE-KEYWORD, there is also an entry for DATE-MODE which defines the format of the DATE.

Filter Name Abstractions

A somewhat more complex data abstraction problem arises from the variety of filter names. Frequently the filter names listed in the image headers are unique and descriptive. This is helpful for the observer to know exactly which filter was being used, but can cause endless confusion for software. For example, the Kron-Cousins R filter used by CFH12K may have the name 'R', while the one used by KPNO may have the name 'KPNO-R', while that used at Subaru may have an entirely different name.

The Elixir system clears up this confusion by providing a flexible abstraction of filter types with a variety of possible filter names. This is done with a simple text configuration file which lists all possible names for filters for the configuration. One of the names is the reference names Elixir uses for that filter. A program, 'filtname', and an associated set of C APIs allows other programs to look up the Elixir reference name for a given filter name.

An example configuration file would look like the following:

 # default filter names
 1 R
 2 V
 # altername names
 1 R-KPNO
 1 R1.CFHT
 2 V-KPNO
 2 V2.CFHT
 

The filtname program has several options. If called with one of the filter names, it will return the default version of the filter. Thus, in the above example, the command 'filtname V2.CFHT' will return `V'. Alternatively, the -list and -all options may be used to return a list of only the default filter names or a list of all possible names. C API equivalents to these commands are available for C programs which need to distinguish the possible filters.

Camera Configuration

A variety of parameters are needed to describe the layout of a mosaic CCD camera. These parameters include the number of ccds, the extention numbers or some other id associated with each chip, the relative position of the different ccds in the array, the bias and data areas for each chip (which may vary from chip to chip), and so forth. Many, if not all, of these parameters can be determined from CCD headers if they are defined according to the NOAO specifications. However, some programs need to know this information in the absence of any image, and it is necessary to have a backup method for cameras which do not provide sufficient information. Furthermore, if a random camera implements a different strategy to define these parameters in the header, it is inconvenient to write new code to interpret each scheme. Therefore, Elixir uses an abstraction of the camera configuration, allowing these parameters to be selected automatically.

The scheme used by Elixir for the camera configuration is similar to the method used for the filters: a text configuration file with a specific program which accesses the data. The configuration file has the following kinds of information:

 NCCD 12
 NX 6
 NY 2
 
 CCD.0 00 ...
 

The program 'cameraconfig' provides tools to access the values in this config file. The different elements are accessed with different command-line options. For example, with the flag -Nccd, the value 12 is returned. With the flag -ccds the list of CCD IDs is returned. MORE EXAMPLES.

Elixir Configuration and Data Abstraction

The Elixir configuration system makes it easy to manage these different types of data abstractions. The text files which contain these abstractions are specified by the configuration system. These can either be included in the camera-specific config file or in the CONFIG-specific config file. In either case, elixir programs which need to know about the details of the filters or the cameras will search the appropriate abstraction file.