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.
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.
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
in the directory pub/fits.
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://heasarc.gsfc.nasa.gov/caldb/docs/.
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.
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.
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.
ad80003000g200170h.evt
Users can read the screened files into XSELECT and proceed immediately to extract images, light curves and spectra.
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://heasarc.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.
FITS files have:
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.
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.
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).
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).
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.
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.
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.
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.
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).