Description

The data model (DM) is a library which lets our software access a variety of file formats. For the user, the most obvious interaction with the DM is the virtual file syntax (type 'ahelp dmsyntax'). This section is a primer to help the user understand the basics underlying the DM.

The DM supports different file formats and maps them to a common view of the data.

The most common kind of data file X-ray astronomers work with is a list of photon events. When working on archival data, this will be in the form of a FITS binary table file (not to be confused with the simpler FITS image format). An event binary table in a FITS file will be preceded by a `null primary header', and followed by a GTI (good time intervals) table. The number of columns in the event table is determined from the TFIELDS keyword. We want our software not to care about implementation differences like these (and there are hundreds of such implementation details). We'd also like to later support other file formats which may do things yet another way.

Because of this, the DM tools give a view of the data which is at a higher level than programs like FTOOLS. To the DM, the file's `header' contains only the header keys which don't represent file implementation details. Thus, for example, FITS's TFIELDS and CRPIX aren't visible to the user as DM keys. The information they contain is provided at a higher level, as the number of table columns and the coordinate system information respectively.

Similarly, we avoid FITS-specific terminology like 'HDU' and 'extension' in favor of more generic words like 'block'.

The basic DM object is a dataset, which is usually but not necessarily a single disk file. This dataset contains one or more blocks, and there are two kinds of blocks - tables and images. For instance, a FITS image file is a dataset with one image block.

It's important to remember the difference between tables and images. Some tools only work on one or other kind of block, and you'll get an error or a meaningless result if you feed them the wrong kind. For example, the dmtcalc tool, which performs arithmetic on table columns, won't work if you give it an image.

Having said that, if you have a program which wants an image, you can give it a table instead. What happens? The DM will do its best to automatically make an image from the table. By default, it will look for columns X and Y in the table and bin on them. (The table may have its own ideas about how it would like to be binned, which may override this default). The possible snag is that for some files the resulting image may be very large and steal all your swap space, so be careful about using this feature.