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
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
# altername names
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
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
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:
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.
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.