High Resolution Spectroscopy
HETG/ACIS-S Observations
Analysis Guide
It is possible to analyze any Chandra gratings dataset almost straight out of the box (only response files need to be created). However, to get scientifically accurate results, there are a number of data processing questions that should be considered. When Chandra data goes through Standard Data Processing (SDP, or the pipeline), the most recently available calibration is applied to it. Since this calibration is continuously being improved, one should check whether there are currently newer files available. Similarly, some science decisions are made during SDP; every user has the option to reprocess the data with different parameters.
For gratings observations, there is the additional question of whether the source spectrum extracted during SDP corresponds to the source of interest to the user, and if so, whether the source location was correctly determined.
The chandra_repro reprocessing script runs all the data processing threads for grating data. Everything in the reprocessing data steps of this guide are automated by the script. Refer to "ahelp chandra_repro" for more information.
Using TGCat, the Chandra Gratings Catalog and Archive: If the user is analyzing archival data, and furthermore is satisfied with the source position and the choices made for SDP, essentially all steps described here can be avoided by using the gratings catalog, TGCat, and downloading the pre-computed spectral products (i.e., spectra and response files). The user can then proceed to the "Simple spectral analysis" threads.
Background: Users may also want to review the Analysis of HETG Background Rate memo which finds that: The HETG background rate is less than 1.0 count/ Ms / FWHM / 4 arcsec, with about 10% uncertainty.
This analysis guide gives an overview of a subset of the CIAO threads pertaining to HETG/ACIS-S data analysis. They take the user through the analysis of a single source from a single observation. By following the threads, the user can determine for an HETG/ACIS-S dataset:
- whether the location of the extracted source was correct,
- whether the data should be reprocessed and filtered before starting the data analysis stage,
- how to create response files for the gratings spectrum, and
- how to begin a simple spectral analysis.
The following threads are referenced:
- Determining source position
- Reprocessing data
- Creating response files
- Simple spectral analysis
The threads should be run in the order in which they are presented below.
Thread: Correcting a Misplaced Zero-order Source Position
When tgdetect, the CIAO tool for locating zero-order position of an observed source, is run in the pipeline, it uses the observer-specified target coordinates from the file header to locate the center of the box in which to search for zero-order sources.
However, if tgdetect is run as a stand-alone tool with the zero order positions, zo_pos_x and zo_pos_y, set to their default values, the tool uses hard-wired numbers to locate the center of the box in which it searches for zero-order sources. If the source is outside of the default search area (400 square pixels for ACIS),the tool will not locate it, regardless of how prominent it is.
This thread shows how to re-run tgdetect with the correct source positions for the search. Zero-order positional problems of this type, however, are a less common occurence than those described in the next thread, "Source Position for Grating Data with a Piled or Blocked Zero Order". Most users wishing to correct the zero-order position will begin with that thread instead.
Thread: Source Position for Grating Data with a Piled or Blocked Zero Order
The tgdetect tool is used to find the centroid of the zero-order image in a grating event list. If the zero-order source is piled, there is the potential for the centroid to be incorrect due to the "hole" created in the data.
When observing a bright source (e.g. Cygnus X-2, ObsID 1102), the proposer may choose to have the zero-order region blocked via on-board software to avoid telemetry problems.
Either of these situations may result in a misplaced zero order, which affects event order sorting and will lead to incorrect wavelength scales. This thread discusses how to determine the correct source position for a grating observation with piled or blocked zero order, and how to extract new spectral data with the updated source position.
Most users wishing to correct the zero-order position will begin with this thread.
Thread: Customizing an ACIS Bad Pixel File
acis_build_badpix is a tool that can be used to customize an observation-specific bad pixel file. It is possible to remove selected types of bad pixels from the bad pixel file (i.e. to retain these events in the event file). It is also possible to remove or add individual bad pixels or columns.
This is a more advanced analysis thread that most users will not need to follow.
Once a custom bad-pixel file has been created, it is necessary to reprocess the data with acis_process_events in order to apply the new bad pixel file. This is included in the section: "Reprocessing Data to Create a New Level=2 Event File".
| Threads: | Reprocessing Data to Create a New Level=2 Event File |
| HETG/ACIS-S Grating Spectra |
The Reprocessing Data to Create a New Level=2 Event File thread generates a new level=1 event file for all possible grating and detector combinations. If a new bad pixel file was created, it is applied as part of the reprocessing.
The HETG/ACIS-S Grating Spectra thread begins at that level=1 event file. The source positions are determined using the tgdetect tool. If one of the above "Determining source-position" threads has been run, this step of the thread would have already been performed. (When using the tg_findzo.sl tool described in the "Source Position for Grating Data with a Piled or Blocked Zero Order" thread, it is usually not a problem to determine source position using either the level=1 or level=2 Standard Data Products, even if one later creates new, reprocessed level=1 and level=2 event files.)
The thread then takes the user through the process of identifying the image regions along the directions of the gratings arms (using tg_create_mask), and of assigning gratings events to spectral orders (using tg_resolve_events). Once these two steps have been performed, a grade and status filter are applied, using dmcopy to create a new level=2 event file. At this point, the user might also want to apply other filters, e.g., a time filter.
Spectra are then created using the tgextract tool.
Thread: Setting the Observation-specific Bad Pixel Files
Although the majority of the calibration files are now contained within the Chandra Calibration Database (CALDB), the observation-specific bad pixel list must be set by the user. This file will be used by many of the CIAO tools, such as mkarf, mkgarf, and mkinstmap. Setting the bad pixel file ensures that the most accurately known bad pixel list for any observation will consistently be used in the data processing.
It is very important that you know what files are set in your ardlib.par. If you do not set the bad pixel file for your observation, the software will use a generic detector bad pixel file from the CALDB; pixels that are flagged as bad in a specific observation will not get filtered out when using this map. The criteria for a pixel to be flagged are described in the badpix dictionary entry.
Remember to "punlearn" or delete your ardlib.par file after completing analysis of this dataset to ensure that the proper bad-pixel maps are used the next time that ardlib.par is referenced by a tool.
Thread: ACIS-S Grating RMFs
This thread shows how to use the mkgrmf tool to generate a grating RMF (gRMF) appropriate for spectral analysis of grating observations. The tool can be used either to create a standard gRMF with the most up-to-date calibration or to calculate a gRMF using non-standard grids.
For HETG/ACIS-S observations, users will typically make gRMFs for the positive and negative first orders of the MEG and HEG (i.e., four gRMFs in total). Typically only very bright sources and/or very long observations will have sufficient counts in higher order spectra that warrant creating higher order responses.
Thread: HETG/ACIS-S Grating ARFs
This thread shows how to use the fullgarf script to create a grating ARF for a particular order and grating of an observation. While the mkgarf tool will create a grating ARF for an individual chip given an aspect histogram, this script creates ARFs for each chip, creating aspect histograms as necessary. The script then combines the individual ARFS into one for the full array.
For HETG/ACIS-S observations, users will typically make ARFs for the positive and negative first orders of the MEG and HEG (i.e., four gratings ARFs in total). Typically only very bright sources and/or very long observations will have sufficient counts in higher order spectra that warrant creating higher order ARFs. Such ARFs are also useful for analyzing first order gratings spectra of bright sources with pileup. For those cases, one typically creates second and third order ARFs as well. (See the appendix of Nowak et al. 2008.)
Thread: Grouping a Grating Spectrum
In order to use Gaussian statistics to fit a model to a dataset it is often necessary to "group" the data - i.e. combine channels until you have enough counts - before fitting. Since it is not possible to group all the rows in a PHA2 spectrum file at once, the individual spectra first need to be "split" from the file with dmtype2split. Then the dmgroup tool is used to perform the desired grouping.
Note that this thread is only relevant to users analyzing their data with XSPEC. Those using Sherpa or ISIS can group their data during spectral analysis.
Thread: Measuring Line Parameters with an HETG/ACIS-S Spectrum
After having created or downloaded a set of PHA2 and response files (RMFs and ARFs), for an HETG/ACIS-S observation, perform a simple fit to one of the line features present in the spectrum. This thread takes the user through a calculation of the error bars on the line normalizations, positions, and widths, and shows how to calculate the line equivalent widths.