next up previous contents
Next: 3. GIS ISSUES Up: ASCA ABC Guide Previous: 1. INTRODUCTION   Contents

Subsections


2. DATA FILES

2.1 Introduction

The data files which contain events detected by ASCA have three key properties:

In ASCA data reduction, unwanted events are removed by screening, with files of the same type are merged together. The basic structure of the files is preserved, so that the data files input into an ascascreen session have the same structure as the single screened events list which ascascreen produces. To fully understand ASCA data reduction, it helps to be familiar with the basic structure. It also helps to know the names of the various columns which describe each event. This is what this chapter is about. Just as important are the filter files (called mkf files), also described here, which are used for screening based on the time history of various housekeeping parameters and derived parameters, such as elevation angle above the Earth.


2.2 FITS Files

2.2.1 Why FITS?

The format in which ASCA data are telemetered to the ground is very terse and compact. It is not intelligible without extensive documentation, nor is it machine independent. By contrast, files which conform to the The Flexible Image Transport System (FITS) standard are self-documenting and machine independent. For these reasons, the US ASCA Data Facility (ADF) converts the ASCA data it receives from ISAS into FITS as part of the initial processing. FITS is also a NASA-mandated standard which must be adhered to by NASA astrophysics missions.


2.2.2 FITS User's Guide

For newcomers to FITS, a helpful User's Guide is available in PostScript (users_guide.ps) and Tex formats (users_guide.tex) via anonymous FTP at

ftp://nssdc.gsfc.nasa.gov/

in the directory pub/fits.


2.2.3 OGIP Standard

The FITS standard is so flexible that conformance to it does not immediately guarantee that files are readily usable. To establish a multi-mission FITS format for high-energy astrophysics, the Office of Guest Investigator Programs (OGIP), including the ROSAT, ASCA, and RXTE GOFs, and the HEASARC, has established a FITS working group (OFWG). OFWG has defined common keywords and classes of formats applicable to high-energy astrophysics research (e.g. light curves, spectra), and has examined and approved specific formats to be used for archival and current missions. OFWG does not work alone, it works in conjunction with the wider FITS community, and is in regular contact with other high-energy astrophysics groups that are writing FITS files for community use. All OGIP standards are published, either in /it Legacy or as internal memos, as appropriate. These memos are also available via anonymous FTP at ftp://legacy.gsfc.nasa.gov/caldb/docs/.


2.3 Data Processing Versions

The original `pipeline processing' of ASCA data at GSFC is referred to as REV0 (symbolic for `revision 0'). Subsequently, more sophisticated and updated versions were developed, namely REV1 and REV1+, and as of June 1997, REV2 processing began. Full REV2 reprocessing is expected to take about a year. The processing team at GSFC endeavor to run all the archival data through the very latest processing revision. Users who have data which was run through an older processing revision, are strongly advised to obtain data processed with the latest revision from the ASCA archive. Details of all of the changes in the different processing versions can be found at the URL

http://adfwww.gsfc.nasa.gov/asca/processing_doc/proc/processing.html.


2.4 Three Levels of ASCA Data Files

Although all ASCA data files share the same structure, they exist with three different levels of processing, on tapes and in the archive. These are as follows.

  1. UNSCREENED These files are produced by merging raw files (obtained, for example, by running the program FRFread on the original telemetered data) which have the same instrument, mode and bit rate. A typical observation yields about a dozen unscreened files which, like the raw files, have not been screened. They have names like:

    ad80003000g200170h.unf

    The filename carries the sequence number of the observation (in this case 80003000), the instrument (s0, s1, g2 or g3) and the bit rate (l, m, h for LOW, MEDIUM and HIGH respectively). Users who wish to screen their own data can start with the unscreened files and run XSELECT, ascascreen or tkascascreen on them (see §5 and §6). Note that for SIS files the two digits immediately preceding the bit-rate letter have the following meaning.

    01	- FAINT mode
    02	- BRIGHT mode
    12	- BRIGHT2 mode
    

    See §4 for details of these different SIS modes.

  2. SCREENED For each unscreened file there is a screened file which has been subjected to the standard screening (see §5.5). They have the same names as the corresponding unscreened files, except that the filename extension is .evt, so that the screened file corresponding to the above example would be

    ad80003000g200170h.evt

    Users can read the screened files into XSELECT and proceed immediately to extract images, light curves and spectra.

  3. RAW The availability of these files is discontinued for data processing revisions later than REV0, and the use of these files is being phased out. However we describe these files here for historical purposes only. Users who have only RAW files should instead obtain the .unf files from REV1 or later from the archive at GSFC. The number of RAW files per observation were numerous and cumbersome because a new file was written each time the mode or bit rate changed. A typical observation yields about 100 RAW files which, as the name suggests, have not been subjected to screening. RAW filenames began with `ft' followed by digits identifying the date of the observation, instruments were identified with the strings S0, S1, G2, G3, while bit rates were identified with the letters L, M, H. The filename extension was .fits. Thus a typical name would be ft930920_0819_0630G200170M.fits

For more information about the files on an ASCA data tape, please consult the Getting Started Guide which is available via anonymous FTP at ftp://legacy.gsfc.nasa.gov/ in the directory asca/doc and called start_guide_v6_1.tex (Latex version) and asca/doc/start_guide_v6_1.ps (Postscript version). Alternatively, the HTML version can be found at the URL

http://adfwww.gsfc.nasa.gov/asca/processing_doc/GS/getting_started.html.


2.5 Basic File Structure

FITS files have:

  1. a primary header,

  2. a primary image array, and

  3. optional extensions, each with a header.

In the case of the ASCA FITS files, the primary header contains information about the mission, the instrument, the observation and the initial processing. As with all FITS headers, this information is in the form of keywords with assigned values. The primary image array in events files is blank, i.e., it contains no data. The first extension, which is in the form of a binary table, is called EVENTS, and contains complete descriptions of the events themselves in the form of a time-ordered list of photon attributes (e.g. time, position and pulse-height information).

In REV0 processing the events files contained two good-time-intervals (GTI) extensions, called ALLGTI and STDGTI. The idea was that these GTI arrays would initially be identical to each other, containing the start and stop times of periods during which the respective instruments were switched on and collecting data. In the course of data reduction and analysis by the user, the STDGTI intervals would change, reflecting the data selections performed by the user, but the ALLGTI table would preserve its initial values so that the user would not lose this important information. The ALLGTI values are important for such operations as correcting instrument deadtime.

Since the RAW events files have been phased out, the ALLGTI table is no longer in the events files, because, events lists created by XSELECT's extractor have only the STDGTI extension. However, the ALLGTI data will now be stored as an extension in the ASCA housekeeping (HK) files.

The structure of any FITS file can be displayed using the FTOOL fstruct, as in this example:

> fstruct ft940213_1039_0612G203870H.fits
  No. Type     EXTNAME      BITPIX Dimensions(columns)      PCOUNT  GCOUNT

   0  PRIMARY                 32     0                           0    1
   1  BINTABLE EVENTS          8     30(12) 2                    0    1
   2  BINTABLE STDGTI          8     18(3) 1                     0    1
   3  BINTABLE ALLGTI          8     18(3) 1                     0    1

More documentation is available on FTOOLS and on FITS files at the URL

http://heasarc.gsfc.nasa.gov/docs/software/ftools/ftools_menu.html.

It is a good idea to familiarize yourself with GIS and SIS events files by running the FTOOL fdump on typical files. Most of the keywords are self-explanatory - one of the raisons d'etre of FITS - but some column names in the EVENTS extension require further comment. More details are given below.


2.6 Important Keywords and Columns in ASCA FITS Events Files


2.6.1 RAWX/Y, DETX/Y, X/Y Columns and RA/DEC_NOM Keywords

For the GIS PH mode data, the RAWX and RAWY columns contain the position of events detected in the GIS gas cell as determined by the on-board electronics, and recorded in the telemetry. Processing at the ADF corrects for instrument distortions, using ground and in-flight calibrations to produce the linearized DETX and DETY focal plane coordinates and linearized X and Y sky coordinate data. The data in each pair of columns are in units of pixels (0.25 mm/pixel; 1.00 mm = 0.98 arc-minutes).

For the SIS FAINT, BRIGHT and BRIGHT2 modes (see §4) the SIS RAWX and RAWY columns give the discrete CCD pixel location of each event flagged and processed by the on-board electronics. Each SIS can have up to four adjacent CCD chips active at one time; accordingly, the number in the CCDID column (0-3) indicates in which CCD chip the event occurred. Processing at the ADF corrects for the instrument distortions using ground and in-flight calibrations to produce the linearized DETX and DETY focal plane coordinates and linearized X and Y sky coordinate data. The data in each pair of columns are in units of pixels (0.027 mm/pixel; 1.00 mm = 0.98 arc-minutes).

In all cases, the images are in `look up' orientation, with the Y-axis flipped relative to the spacecraft coordinate system, and follow the FITS image convention. The aspect solution is applied to the focal plane coordinates (i.e., DETX, DETY) to produce the sky coordinates (i.e., X, Y). Each event is projected back onto the sky on a tangent plane, and a binned sky image is formed with the X and Y axes oriented along RA and DEC, respectively. If no aspect solution is available for an event then it is assigned the sky coordinates (1,1).

Since each instrument has a unique pointing, and each telescope a unique optical axis, the mean instrument pointing is chosen as the common aspect point. This mean pointing is stored in all the headers as the values of the RA_NOM and DEC_NOM keywords.


2.6.2 TIME Column and TIMESYS, MJDREF, TSTART, TSTOP Keywords

For GIS PH mode, the time attached to each event, in the TIME column, is given in seconds after the reference time (midnight, January 1st, 1993). The reference time is specified by two keywords in the header of the EVENTS extension: TIMESYS, which gives the reference time in UT, and MJDREF which gives the same time in Modified Julian Days (i.e., 48988.0). The two keywords which give the start and stop times of the data in the file, TSTART and TSTOP, are also given in seconds with respect to the reference time. Note that the precision of the arrival times in the TIME column - i.e., the time resolution of the data - depends on the number of bits assigned to timing. This is described in more detail in §3 (GIS Issues).

The above applies also to the SIS, except that the meaning of the TIME column is different and depends on datamode (for explanations of the different SIS modes see §4).


2.6.3 GIS PHA, PI Columns

The PHA (Pulse Height Analyzer) column contains the spectral information associated with each event. Processing at the ADF corrects for the spatial and temporal variations of the detector gain to produce the data in the Pulse Invariant (PI) column. In the case of the GIS, the accumulation of events for spectral analysis should be done using the PI data (this has always been the default in XSELECT).


2.6.4 GIS RISE_TIME, RTI Columns

After entering the GIS through a Beryllium (Be) window, X-ray photons ionize Xenon atoms, and the photoelectrons are accelerated by a strong electric field to excite Xenon atoms. When the atoms de-excite, UV scintillations are produced with intensity proportional to the energy of the original X-rays. These scintillations are then detected by the position-sensitive phototube where the energy of the original photon is ultimately manifested as a pulse of charge.

Each electrical pulse has a characteristic rise-time, which is stored in the RISE_TIME column in the GIS science file. Rise-time has a small positional dependence on the detector, and the RTI (Rise Time Invariant) columns give the rise-time values after this position dependence is corrected.

High-energy particles also produce charges in the phototube, but because they interact with the detector differently from X-rays, they have different rise-times (usually shorter than those of X-rays). Using this fact, background particles can be rejected by applying a rise-time filter. The on-board RISE_TIME window, whose lower and upper boundaries do not depend on the position and PHA, was fixed early in the PV phase of the mission, and only events whose RISE_TIME values fall in the window are telemetered to ground. By applying a stricter, PHA-dependent RTI window in the course of data analysis, background events are more effectively rejected (this is a standard practice, and is carried out with the gisclean command in XSELECT).

When standard bit-assignment is changed to increase time resolution (section 3.2.1), rise-time information may not be available. In this case, RTI based screening is not available, which slightly changes detector efficiency. In spectral analysis, this effect is taken into account by ascaarf to create ARFs which match the efficiency without the RTI screening. It is also important to use the background spectra without RTI screening in this case.


2.6.5 GIS MPC Mode Files

For GIS MPC mode, a non-imaging mode used only for bright sources, there are no PHA and PI columns. Instead, the primary extension, which is called SPECTRUM rather than EVENTS, contains the columns TIME, X, Y, and PHAS. The TIME column is defined in the same way as for PH mode, while the X and Y columns contain only zeroes, since MPC mode has no position information. (Nevertheless, MPC mode data files have X and Y columns lest future software require them, say, to perform a statistically based positional gain correction). For the same reason, MPC mode files do not have RAWX/Y nor DETX/Y columns. For each time bin, the PHAS column contains the integrated 256-channel PHA spectrum, or histogram. The values in the PHAS column are not corrected for the positional dependence of the gain. MPC mode data is much like traditional proportional-counter data.


2.6.6 SIS PHA, PHAS, GRADE, PI Columns

The meaning of the SIS PHA (pulse height analyzer) column depends on the datamode.

Like the GIS, the SIS also has a PI (Pulse Invariant) column for gain-corrected PHA values, but only for BRIGHT and BRIGHT2 mode. In REV0 data files, the PI column is present, but not filled. In REV1 and later data files, however, the PI column is filled. See §4.5.2 (SIS Issues), for more about SIS PI.


2.7 MKF Files

The mkf file (produced by the program mkfilter or mkfilter2 at the ADF) summarizes critical housekeeping, orbit and attitude information, as well as derived parameters such as Earth elevation angle. These files have a .mkf extension and comprise, in a more compact form than the HK files, most of the information needed for screening data. This information is stored in a binary table extension of the mkf file in the form of a time-ordered list of rows. When given a screening criterion, e.g., elevation angle $>$ 10 degrees, XSELECT will go through the mkf file to find all the good time intervals (GTI) which satisfy the criterion. We recommend that users familiarize themselves with their mkf files - at least the headers and the first few rows - by running fdump on them.

The mkfilter program underwent a revision between REV0 and REV1, becoming mkfilter2. The new version yields mkf files with the following important changes and enhancements:

      -----------------------------------------------
                           mkfilter         mkfilter2
      -----------------------------------------------

      Used for             REV0              REV1
      Input files          FRF               HK
      Elevation column     ELV_MIN           ELV
      Rigidity column      COR_MIN           COR
      Units of Sn_PIXLm    counts/readout    counts/s
      ANG_DIST present     no                yes
      -----------------------------------------------

The meanings of these parameters are fully explained in §5 and $ 6.


2.8 Housekeeping Files

The ASCA housekeeping files have names that end with HK.fits. Note that text summaries of the GIS housekeeping files are provided in the aux directories in the ASCA archive and on PIs' data tapes. They have names like:

ft930916_0218_1611G3HK.txt

GIS housekeeping files include monitor counts which may be used to study time variations of bright sources. The FTOOL ghkcurve is used to create a FITS light curve of the L1 monitor count in a housekeeping file. The particular advantage of this is that one can make proper light curves for telemetry-saturated data from very bright sources.

Currently, SIS and `Common' HK files, which include housekeeping information for the SIS and the satellite respectively, are not used in the ASCA data analysis because the critical information has been copied to the mkf file. An exception is the ALLGTI binary table extension which is now carried in the HK files of both SIS and GIS (see §2.5).


next up previous contents
Next: 3. GIS ISSUES Up: ASCA ABC Guide Previous: 1. INTRODUCTION   Contents
Michael Arida 2002-10-22