NOTICE: This Legacy journal article was published in Volume 2, November 1992, and has not been updated since publication. Please use the search facility above to find regularly-updated information about this topic elsewhere on the HEASARC site.

	Version: 1992 Sept 14	OGIP Calibration Memo CAL/GEN/92-002

Summary

The approach and calibration file formats adopted by the OGIP for spectral analysis of X-ray PHA datasets are outlined and discussed.

1 Introduction

All calibration files within the High Energy Astrophysics Science Archive Research Center (HEASARC) will make use of the Flexible Image Transport System (FITS; e.g., see Wells et al. 1981, Griesen & Harten 1981), including all the recent enhancements of the original FITS formats. Specifically, wide use will be made of 'extensions' (Grosbol et al. 1988), 'ASCII tables' (Harten et al. 1988), and 'binary tables' (Cotton & Tody 1992).

Calibration files have been classified within the OGIP into 2 types:

• Basic Calibration Files (BCFs) containing all the basic calibration information for a given instrument. The BCFs will contain calibration information which is both independent of time (in most cases data originating from ground calibration measurements), and information which is expected to vary throughout the mission (mainly from in-orbit measurements). In many BCFs the data will be stored in the form of large n-dimensional arrays. A more detailed discussion of the general formats and organization of the BCFs can be found in OGIP Calibration Memo CAL/GEN/92-003 [1]

• Calibration Product Files (CPFs) are essentially rearrangements of a subset of the information within the BCFs suitable for a specific task within a given Data Analysis Package. The extraction of the necessary information from the BCFs and construction of CPFs is performed by 'Stage 2 Calibration s/w', with reference to HK data (e.g., observation date, instrument mode etc.) as necessary.

An overview of the relationship between the BCFs, CPFs and other elements within the generic calibration dataflow is given in CAL/GEN/91-001 (George 1992). Figure 1 shows schematically the inter-relationship between those elements within the dataflow relevant to the current discussion.

This document describes in detail the format adopted by the HEASARC for the calibration files required during the spectral analysis of (PHA) data.

Figure 1 A schematic representation of the calibration dataflow required prior to spectral analysis of a PHA data file. In the general case, the necessary calibration information is contained within two files: the RMF & ARF. The RMF maps the redistribution of photon energies between the PHA channels within the detector, whilst the ARF contains the remaining effects (as a function of photon energy). Both files are constructed by the Stage 2 Cal. s/w task BLDRSP, which selects and combines the calibration data contained with the BCFs on the basis of HK information supplied via the PHA file (or elsewhere) and algorithms supplied by the hardware team and/or project. By default the calibration data deemed most appropriate will be used by BLDRSP to construct the two o/p files. However, if desired, the User is alternatively able to select between various versions of the calibration data.

2 Overview

In the general case, spectral analysis of a PHA file (e.g., using XSPEC or equivalent Data Analysis Package) requires access to the following Calibration Product Files:

• A DETECTOR REDISTRIBUTION MATRIX FILE (RMF)
  
  • created by folding together individual components due to the:
    
    • Detector Gain
      
    • Detector Energy Resolution
      (including the response to a monoenergetic source e.g., escape peaks, partial charge tail etc.)
      
  • consisting of a compressed 2-d (energy vs PHA channel) FITS extension (Section 3).
    
  • and a second extension explicitly listing the nominal energy range of each PHA channel.
    

• AN ANCILLARY RESPONSE FILE (ARF)
  containing the summed contribution of efficiency components, i.e., those not involved in the redistribution of photons such as the:
  
  • Effective Area of the Telescope/Collimator (including vignetting),
    
  • Filter Transmission (if any)
    
  • Detector Window Transmission
    
  • Detector Efficiency
    
  • any additional energy dependent effects (e.g., correction factors for the p.s.f.)
    
• in a single 1-d (energy) FITS extension (Section 4).

It should be noted that the PHA channels used in all the i/p files to the spectral analysis package --- i.e., within the RMF, ARF & PHA files --- in all cases refer to raw detector channels. In the case of RMFs, the number of raw channels is given explicitly by the DETCHANS keyword within the MATRIX extension (see below). Any desired rebinning of the raw PHA data can be specified by the GROUPING flag within the PHA file (OGIP/92-007, Arnaud, George & Tennant 1992). The rebinning of the data is then performed within the spectral analysis package, along with appropriate rebinning of the calibration data supplied by the RMF & ARF.

2.1 Rationale

For many instruments, the Detector Gain & Energy Resolution do not vary significantly with detector coordinates or time (in particular not within an 'observation'). In such cases, only a single RMF can be constructed for a given observation and used in conjunction with the spectral analysis of ALL the sources in the field-of-view. Each of the individual PHA files associated with each source will thus have its own customized ARF. The spectral analysis package will then read in the PHA/ARF pairs along with the common RMF. (Situations in which the use of a common RMF is not possible are discussed in Section 6.)

Furthermore, the isolation of those components which are not concerned with the redistribution process, and hence are a simple function of energy for a given PHA file (i.e., given time, Detector position, mode etc.), into the ARF allows these components to be listed individually within the ARF if desired (see Section 4). It should be noted however that the product (Prod array below) of the components to the ARF will always be listed.

2.2 Reminders

'PI' channels (i.e., from a redistribution of the raw PHA channel data within a PHA file onto a scale appropriate for some 'standard' Detector gain setting etc.) should wherever possible NOT [2] be used: the inclusion of the Detector gain within the RMF provides the necessary PHA channel -> energy conversion.

In the case of (significant) gain changes during a given 'observation' (e.g., as often the case for the Einstein IPC) separate PHA & RMFs should be constructed prior to spectral analysis (and the PHAs analyzed in conjunction with their respective ARFs & RMFs either alone or simultaneously).

An RMF contains only information applicable to the redistribution process. The Effective area, Filter (if appropriate) & Window Transmissions are folded into the ARF. Any additional effects such as obscuration by the Window Support Structure, absorption due to deposits (e.g., water ice) upon the the Window surface etc. will also be folded into the ARF. Again this is in order to minimize the number of RMFs required for a given observation dataset (hopefully to one in many instances). Hence this provides a reduction in the requirements for disk-space, and facilitates any investigation Users may wish to perform into the effect on their spectral analysis of varying the contribution any such components.

3 The OGIP Standard RMF Format

The standard RMF format consists of a FITS file with a null primary array and two extensions:

• The Redistribution (MATRIX) extension
  
• an (EBOUNDS) extension containing the nominal energy bounds of each channel

3.1 The RMF Redistribution Extension

In order to minimize disk-space requirements, the RMF Redistribution Matrix will be in a compressed format in which all matrix elements below a given threshold (specified by the LO_THRES keyword below) are not stored. In fact the format is very similar to that used currently by the XSPEC *.RSP SF files.

3.1.1 Extension Header

The header must include the following (mandatory) keywords/values:

• EXTNAME (= MATRIX) - the name (i.e., type) of the extension
  
• TELESCOP - the"telescope" (i.e., mission/satellite name).
  
• INSTRUME - the instrument/detector.
  
• FILTER - the instrument filter in use (if any)
  
• RMFVERSN - the OGIP version number of the FITS format in use (in this case 1992a)
  
• CHANTYPE - whether the detector channels given in the matrix are uncorrected (i.e., as assigned by the detector electronics, CHANTYPE = PHA), or have been corrected (e.g., are "pulse invariant", CHANTYPE = PI).
  
• DETCHANS - the total number of raw detector PHA channels in the full (uncompressed) matrix.

• PHAFILE - name of PHA file for which this file was produced
  
• LO_THRES - lower threshold used to construct the matrix (matrix elements below this value are considered to be zero and are not stored)

• CCLS0001 (= CPF) - the OGIP-class of this calibration file.
  
• CCNM0001 (= MATRIX) - the (CIF) codename for this type of calibration dataset.
  
• CDTP0001 (=DATA) - the OGIP code for the form of the contents of the file ('real' data, a taskname and associated parameter inputs, etc.)
  
• CVSD0001 - the UTC date (in dd/mm/yy format) when this calibration data should first be used
  
• CVST0001 - the UTC time (in hh:mm:ss format) on the day CVSD0001 when this calibration data should first be used.
  
• CDES0001 - a string giving a brief descriptive summary of this dataset

In the general case, the organization of the data within this extension will be as follows (with the matrix x-axis = raw PHA channel, y-axis = Energy) with each row of the BINTABLE referring to a single energy range (thus the number of rows = number of energy bins) and consist of the following columns:

• Ehigh, a 4-byte REAL scalar for each row containing the lower energy bound of the energy bin.
  The FITS column name is ENERG_LO.
  The recommended units are keV.
  

• Ehigh, a 4-byte REAL scalar for each row containing the upper energy bound of the energy bin.
  The FITS column name is ENERG_HI.
  The recommended units are keV.
  

• Ngrp, a 2-byte INTEGER scalar for each row containing the number of 'channel subsets' for for the energy bin (see below).
  The FITS column name is N_GRP.
  (unitless).
  

• Fchan, a (fixed- or variable-length) INTEGER vector (array, each element within which is 2-byte) for each row containing the channel number of the start of each 'channel subset' for the energy bin.
  The FITS column name is F_CHAN.
  (unitless).
  

• Nchan, a (fixed- or variable-length) INTEGER vector (array, each element within which is 2-byte) for each row containing the number of channels within each 'channel subset' for the energy bin.
  The FITS column name is N_CHAN.
  (unitless).
  

• Mat, a (fixed- or variable-length) REAL vector (array, each element within which is 4-byte) containing all the response values for each 'channel subset' for the energy bin.
  The FITS column name is MATRIX.
  (unitless).
  

Table 1 OGIP format (1992a) for storing photon redistribution matrices within an RMF

3.1.3 Points to Note & Conventions

• The ordering of the columns is of course arbitrary, however that used here is strongly recommended.

• Values of both Elow & Ehigh are given in each row (j) for clarity, and to ease access & use. The order should be sequential, and it is suggested starting from the lowest value. In no case should there be any overlap between consecutive energy bins, i.e., Elow(j) >= Ehigh(j-1), (although note that in all currently known cases, Elow(j) = Ehigh(j-1)).

• The concept of 'channel subsets' is included to minimize the RFM storage requirements for instruments for which the 2-d matrix consists of non-zero values in two or more (unconnected) regions of channel--energy space. A channel subset therefore consists of a number (Nchan) of contiguous raw channels for which the matrix elements are above the threshold specified by the value of the LO_THRES keyword. Thus, using the above notation, then a given row the Mat array contains the elements appropriate to

     channels     Fchan(1)  ->  (Fchan(1) + Nchan(1) - 1)
     followed by  Fchan(2)  ->  (Fchan(2) + Nchan(2) - 1)
     followed by  Fchan(3)  ->  (Fchan(3) + Nchan(3) - 1)
        ...	...
     etc.	etc.
  
     followed by Fchan(Ngrp) -> (Fchan(Ngrp) + Nchan(Ngrp) - 1)
  
  

• In the general case, columns 4, 5 & 6 (containing Fchan, Nchan and Mat arrays) will be FITS variable-length arrays (Cotton & Tody 1992). Thus the number of elements within each vector varies between rows (clearly the number of elements within the Nchan array on a given row, for example, is equal to the value of Ngrp (column 3) for that row). However, if the maximum number of elements within such an array (over all rows) is less than or equal to three (i.e., if Ngrp 3 for all rows), it is more efficient in terms of both disk storage requirements[3] and speed of access[4] to designate that array as fixed-length format. This criterion has been adopted as the general policy of all files containing arrays of variable length within the HEASARC calibration database. Thus, with specific regard to RMFs, the following guidelines should be adhered to:
  • All RMFs for a given instrument, should employ the same format.
    
  • in most cases the Fchan & Nchan columns will be fixed-length integer arrays, since for most instruments from which there is data currently in the HEASARC archives Ngrp 3.
    Note, in all cases the Fchan & Nchan columns contain the same number of elements, thus should both either be in fixed- or variable-length array format.
    
  • Due to the greater read-efficiency, the Mat column is also in fixed-length format unless this leads to a significant increase (say 1.5) in disk-space requirements.
    
  • Unused elements within an array should be padded with 'null data' values.

  It should be emphasized, however, that the choice of fixed or variable-length arrays should make no difference to downstream s/w (e.g., XSPEC) as the two formats look identical when using FITSIO interface (Pence 1992).

• If a column contains a constant value in every row, then the column is deleted from the table and transformed into a keyword value. The downstream s/w should then first look for a keyword value; if the keyword is not found, then the s/w will look for a column with that name.

• Each row within the RMF matrix will be normalized to 1 detected photon, i.e., each element of Mat will contain the probability of a detected photon within the appropriate energy range giving rise to a signal in that PHA channel. Effects due to detector efficiencies <100%, absorption by mirrors, filters & the detector window etc. are included within the ARF. However, due to the finite probability of a photon being registered as either below or above the PHA discriminator thresholds, and when the value of LO_THRES > 0.0, the sum of the values within the Mat array for a given row may be less than unity.

This extension lists the (nominal) energy boundaries of each of the (raw) detector channels within the redistribution matrix given above. In some senses, this information is already contained within the redistribution matrix itself (being the energies corresponding to the maxima in the matrix for the lower and upper channel boundaries), and thus can be calculated from the matrix. (It should be stressed that these energies are not the same as those given in the ENERG_LO & ENERG_HI columns of the MATRIX extension above.) This information is required by spectral analysis packages when (say) the results of spectral analysis (PHA data and best-fitting model) are required to be displayed as a function of photon energy, rather than detector channel. Since the number of raw channels in the matrix of many detectors is large, clearly a great saving in processing time during such spectral analysis tasks is offered if this information is provided explicitly by the RMF.

The format described here is relatively straightforward, being a simple 1-dimensional list (as a function of raw detector PHA channel) listing the appropriate energy boundaries.

3.2.1 Extension Header

For clarity, the header must include the same mandatory keywords as the RMF extension, namely:

• EXTNAME (= EBOUNDS) - the name (i.e., type) of the extension
  
• TELESCOP - the "telescope" (i.e., mission/satellite name).
  
• INSTRUME - the instrument/detector.
  
• FILTER - the instrument filter in use (if any)
  
• RMFVERSN - the OGIP version number of the FITS format in use (in this case 1992a)
  
• CHANTYPE - whether the detector channels given in the matrix are PHA or PI channels (see above).
  
• DETCHANS - the total number of raw detector PHA channels in the full (uncompressed) matrix.
  

• PHAFILE - name of PHA file for which this file was produced

3.2.2 Data Format

A BINTABLE FITS format has been chosen whereby each each row refers to a single detector channel. The number of rows is thus the number of (raw) detector channels and must correspond exactly to the channels within the PHA file and hence also to the value of the DETCHANS keyword in the RMF MATRIX extension described above. Thus, we have

• Chan, a 2-byte INTEGER scalar giving the raw channel number for each row.
  The FITS column name is CHANNEL.
  (unitless)
  

• Emin, a 4-byte REAL scalar for each for each row containing the nominal energy corresponding to the lower boundary of the detector channel.
  The FITS column name is E_MIN.
  The recommended units are keV.
  

• Emax, a 4-byte REAL scalar for each for each row containing the nominal energy corresponding to the upper boundary of the detector channel.
  The FITS column name is E_MAX.
  The recommended units are keV.
  

3.2.3 Points to Note & Conventions

• The ordering of the columns is if course arbitrary, however that used here is strongly recommended.
  
• Emin and Emax should never be confused with Elow and Ehigh within the RMF extension.
  
• Emin and Emax should be used with extreme care. Inexperienced users/programmers are reminded that the pulse-height analyzer vastly oversamples the true spectral response in most X-ray detectors. Thus there is no guarantee that an incident X-ray with an energy between Emin and Emax will be detected in the corresponding channel (hence the requirement of the RMF in the first place).

4 The OGIP Standard ARF Format

The ARFs are relatively straightforward, consisting of a simple 1-dimensional list (as a function of energy) of the product of the various components required for spectral analysis not involved in the photon redistribution process (see Section 2.1).

4.1 The ARF Extension

4.1.1 Extension Header

The header must include the following (mandatory) keywords:

• EXTNAME (= SPECRESP) - the name (i.e., type) of the extension
  
• TELESCOP - the "telescope" (i.e., mission/satellite name).
  
• INSTRUME - the instrument/detector.
  
• FILTER - the instrument filter in use (if any)
  
• ARFVERSN - the OGIP version number of the FITS format in use
  

• PHAFILE - name of PHA file for which this file was produced

4.1.2 Data Format

The general HEASARC standard for ARFs also makes use of the BINTABLE FITS format, and thus the data again resides in a single extension of a FITS file (though generally NOT the RMF) with a null primary array. As in the case of the RMFs, each row of the BINTABLE refers to a single energy range. The number of rows hence equals the number of energy bins and must directly correspond to those in the corresponding RMF. In all cases the following columns are included (preferably as the first 3 columns within the table):

• Elow, a 4-byte REAL scalar for each row containing the lower energy bound of the energy bin.
  The FITS column name is ENERG_LO.
  The recommended units are keV.
  

• Ehigh, a 4-byte REAL scalar for each row containing the upper energy bound of the energy bin.
  The FITS column name is ENERG_HI.
  The recommended units are keV.
  

• Prod, a 4-byte REAL scalar for each row containing the product of all the components (effective area, filter transmission, correction factors etc.) specific to a given PHA file (i.e., the spectral response of the instrument as a whole).
  The FITS column name is SPECRESP.
  The recommended units are cm².
  

Table 3 summarizes the organization of an ARF.

Table 3 OGIP format (1992a) for ARFs

4.1.3 Points to Note & Conventions

• The ordering of the columns is of course arbitrary, however that used here is strongly recommended.

• Values of both Elow & Ehigh are given in each row (j) for clarity, and to ease access & use. The order should be sequential, and it is suggested starting from the lowest value, and should be identical to those in the corresponding RMF. In no case should there be any overlap between consecutive energy bins, i.e., Elow(j) Ehigh(j-1), (although note that in all currently known cases, Elow(j) = Ehigh(j-1)).

• The dimension of the data within the Prod column will be length^2 (due to the inclusion of the effective area).

5.1 The Stage 2 Cal. s/w task BLDRSP

A Stage 2 Cal s/w task (BLDRSP) is currently under development, loosely based on the existing XANADU VIMAT task. All the code necessary to produce an RMF & ARF for a given instrument will be in separate modules spawned from the main program. All the source code, including any associated subroutine libraries, will of course be freely available to users. The BLDRSP will be driven via XPI using a PHA file as the input, and will contain options that allow Users to specify/choose

• between the various versions of calibration data contained within the relevant portion of the OGIP calibration (BCF) database,
  
• whether both an RMF & ARF, or only an ARF is written (see Section 6).
  
• whether all or none of the components of the Prod array (Section 4) are written into the ARF.
  
• (in early releases of BLDRSP only) whether an old-style XSPEC SF *.RSP file, or standard (FITS) RMF and/or ARFs are written.
  

In the case of present & future missions, supply of the BCFs (including any updates and algorithms) to the HEASARC is the responsibility of the instrument h/w team and GOF. In the case of previous missions, the HEASARC will attempt to locate the necessary information.

Further details of the operation of BLDRSP can be found in George, Arnaud & Ruamsuwan (1992). It is intended that successive modules of BLDRSP will be released as the BCF calibration data, necessary algorithms etc. for successive instruments becomes available.

5.2 The Spectral Analysis Packages

Currently existing Spectral Analysis Packages will undoubtedly have to modified slightly to accept the new formats. This can easily be achieved using FITSIO. Reasonable attempts to maintain backward compatibility will be made in the case of OGIP-supported packages (e.g., XSPEC). To this end, ARFs are optional: If the User doesn't provide an ARF to XSPEC, then XSPEC will assume that all the response components are contained within the RMF (which is equivalent to providing an ARF Prod array filled with 1's).

XSPEC version 8.2 upwards will be compatible with the RMF/ARF and PHA formats described here and in Arnaud, George & Tennant (1992). It is intended that all new spectral calibration and PHA files created by the OGIP will conform to this standard in the near future.

6 Usage: Typical Scenarios

For non-imaging devices (with a time-stable Detector Gain etc.) a User extracts a PHA file, runs BLDRSP and constructs a RMF & ARF. These are read into their favorite Data Analysis Package (e.g., XSPEC) along with the PHA file, and spectral analysis attempted. Should the User then wish to investigate the effect of alternate calibrations, BLDRSP can be run again/spawned. The User then specifies the desired calibration, and a new ARF written. Spectral analysis could continues using the original PHA file & RMF in conjunction with the new ARF. In some cases a single RMF may be applicable to several contiguous observational datasets within the HEASARC archive.

For imaging instruments (with a time- and position-stable Detector Gain etc.) a User performs an almost identical set of actions as above for each PHA file extracted (i.e., from each source in the image). Each PHA file therefore has an associated ARF file, which the User creates and/or customizes using BLDRSP. However all the PHA files share a single RMF.

For imaging instruments (with a time-stable Detector Gain etc., but which varies with detector position) a User has to construct both a RMF & ARF for each PHA file extracted (i.e., from each source in the image). Users will obviously be able to customize the individual ARFs as desired.

For instruments (of any type) for which the Detector Gain etc. is not stable with time (i.e., significantly varies over the course of a pointing), the observational dataset should be broken-down into a series of periods for which all Detector-related quantities are considered sufficiently time-stable. Separate PHA files, RMFs and associated ARFs can then be constructed for each of these periods (with each RMF obviously containing the matrix constructed using the gain setting appropriate to its time-window). Spectral analysis is then performed on these files either individually or simultaneously.

7 Special Cases

It should be stressed that the spectral response matrix of instruments for which either:

• it is necessary to assume a PHA channel -> PI channel conversion has been performed on the PHA data[5]; and/or
  

• the components of the matrix are unavailable in a suitable format, thus requiring the Prod array to be folded into the RMF,
  

If no ARF is specified within the PHA file (via the ANCRFILE keyword -- see OGIP/92-007, Arnaud, George & Tennant 1992), then the Spectral Analysis Package should assume that the instrument spectral response (i.e. the Prod array from Table 3) has been folded in with the redistribution matrix (Mat from Table 1), and this information is what is stored in the RMF extension. In this case the following changes to the list of mandatory keywords/values given in Section 3.3.1 are necessary to the header of the (new) RMF extension:

• EXTNAME (= SPECRESP MATRIX) - the name (i.e., type) of the extension
  
• CCNM0001 (= SPECRESP MATRIX) - the (CIF) codename for this type of calibration dataset.

8 Example FITS Headers

As an example, below we list the keywords from the BBXRT RMF. Note that due to the calibration data currently available, the spectral response of this detector has been folded in with the redistribution matrix (see Section 7).

8.1 BBXRT RMF

8.1.1	Primary Header

SIMPLE  =                    T / file does conform to FITS standard
BITPIX  =                  -32 / number of bits per data pixel
NAXIS   =                    0 / number of data axes
EXTEND  =                    T / FITS dataset may contain extensions
CONTENT = 'RESPONSE'           / file contains response matrix
DATE    = '21/09/92'           / date this FITS file was created (dd/mm/yy)
ORIGIN  = 'BBXRT/GSFC'         / organization which created this file
END


8.1.2	RMF Extension


XTENSION= 'BINTABLE'           / binary table extension
BITPIX  =                    8 / 8-bit bytes
NAXIS   =                    2 / 2-dimensional binary table
NAXIS1  =                 2018 / width of table in bytes
NAXIS2  =                 1024 / number of rows in table
PCOUNT  =                    0 / size of special data area
GCOUNT  =                    1 / one data group (required keyword)
TFIELDS =                    6 / number of fields in each row
TTYPE1  = 'ENERG_LO'           / label for field   1
TFORM1  = 'E       '           / data format of the field: 4-byte REAL
TUNIT1  = 'keV     '           / physical unit of field
TTYPE2  = 'ENERG_HI'           / label for field   2
TFORM2  = 'E       '           / data format of the field: 4-byte REAL
TUNIT2  = 'keV     '           / physical unit of field
TTYPE3  = 'N_GRP   '           / label for field   3
TFORM3  = 'I       '           / data format of the field: 2-byte INTEGER
TTYPE4  = 'F_CHAN  '           / label for field   4
TFORM4  = '2I      '           / data format of the field: 2-byte INTEGER
TTYPE5  = 'N_CHAN  '           / label for field   5
TFORM5  = '2I      '           / data format of the field: 2-byte INTEGER
TTYPE6  = 'MATRIX  '           / label for field   6
TFORM6  = '500E    '           / data format of the field: 4-byte REAL
EXTNAME = 'MATRIX  '           / name of this binary table extension
TELESCOP= 'BBXRT   '           / mission/satellite name
INSTRUME= 'A0      '           / instrument/detector
FILTER  = 'none    '           / filter information
RMFVERSN= '1992a   '           / OGIP classification of FITS format style
CHANTYPE= 'PHA     '           / Type of channels (PHA, PI etc)
DETCHANS=                  512 / Total number of detector PHA channels
LO_THRES=              0.10000 / Lower energy threshold for matrix
EFFAREA =              1.00000 / Area scaling factor
CCLS0001= 'CPF     '           / OGIP class of calibration file
CCNM0001= 'SPECRESP MATRIX'    / CIF type of calibration file
CDTP0001= 'DATA    '           / OGIP code for contents (DATA, TASK)
CVSD0001= '02/12/90'           / Calibration start date
CVST0001= '06:49:01'           / Calibration start time (UTC)
CDES0001= 'BBXRT response matrix (TEST18)' / Brief description of dataset
OFFAXISA=                1.000 / Off-axis angle (arcmin)
COMMENT
COMMENT    BBXRT Response Matrix file
COMMENT    Derived from test18 matrix
COMMENT
END     

8.1.3	EBOUNDS Extension



XTENSION= 'BINTABLE'           / binary table extension
BITPIX  =                    8 / 8-bit bytes
NAXIS   =                    2 / 2-dimensional binary table
NAXIS1  =                   10 / width of table in bytes
NAXIS2  =                  512 / number of rows in table
PCOUNT  =                    0 / size of special data area
GCOUNT  =                    1 / one data group (required keyword)
TFIELDS =                    3 / number of fields in each row
TTYPE1  = 'CHANNEL '           / label for field   1
TFORM1  = 'I       '           / data format of the field: 2-byte INTEGER
TUNIT1  = 'channel '           / physical unit of field
TTYPE2  = 'E_MIN   '           / label for field   2
TFORM2  = 'E       '           / data format of the field: 4-byte REAL
TUNIT2  = 'keV     '           / physical unit of field
TTYPE3  = 'E_MAX   '           / label for field   3
TFORM3  = 'E       '           / data format of the field: 4-byte REAL
TUNIT3  = 'keV     '           / physical unit of field
EXTNAME = 'EBOUNDS '           / name of this binary table extension
TELESCOP= 'BBXRT   '           / mission/satellite name
INSTRUME= 'A0      '           / instrument/detector
FILTER  = 'none    '           / filter information
RMFVERSN= '1992a   '           / OGIP classification of FITS format style
CHANTYPE= 'PHA     '           / Type of channels (PHA, PI etc)
DETCHANS=                  512 / Total number of detector PHA channels
CCLS0001= 'CPF     '           / OGIP class of calibration file
CCNM0001= 'EBOUNDS '           / CIF type of calibration file
CDTP0001= 'DATA    '           / OGIP code for contents (DATA, TASK)
CVSD0001= '02/12/90'           / Calibration start date
CVST0001= '06:49:01'           / Calibration start time (UTC)
CDES0001= 'BBXRT (TEST18) channel energy boundaries' / Brief description of
data
COMMENT
COMMENT    BBXRT Response Matrix file
COMMENT    Derived from test18 matrix
COMMENT    EBOUNDS extension
COMMENT
END        

Acknowledgements


We thank the numerous people, both inside and outside the OGIP, who have
contributed ideas and suggestions.  In particular we thank Alan Smale and Mike
Corcoran.


References


Arnaud, K.A., George, I.M. & Tennant, A., 1992. Legacy, 2, 65
(OGIP/92-007).

Cotton, W.D. & Tody, D., 1992. In preparation.

George, I.M., 1992. Legacy, 1, 56, (CAL/GEN/91-001).

George, I.M., Pence, W. & Zellar, R. 1992. OGIP Calibration Memo
CAL/GEN/92-008.

George, I.M., Zellar, R. & Pence, W., 1992. OGIP Calibration Memo
CAL/GEN/92-011.

George, I.M., Arnaud, K.A. & Ruamsuwan, L., 1992. In preparation,
(CAL/SW/92-004).

Griesen, E.W. & Harten, R.H., 1981. Astron. Astrophys. Suppl.,
44, 371.

Grosbol, P., Harten, R.H., Greisen, E.W. & Wells, D.C., 1988.  Astron.
Astrophys. Suppl.,  73,365.

Pence, W., 1992.  Legacy,  1, 14..

Wells, D.C., Griesen, E.W. & Harten, R.H., 1981.  Astron. Astrophys.
Suppl., 44, 363.

Proceed to the next article

Return to the previous article

Select another article