This page is now obsolete. Please see The XSELECT data analysis pages.






Notes on analyzing Chandra ACIS data.

(last modified 8/16/01)

These notes apply to the HEAsoft 5.1 and CIAO v2.1.3

Setting up

You will probably want to set up to run CIAO, HEAsoft and our local Chandra programs and scripts. To do so follow these instructions.

Basic filtering

The basic event data can be found in the primary sub-directory in the files *_evt1.fits and *_evt2.fits. The evt1 file is unfiltered while the evt2 file has some filtering done by the standard processing. Even if you start with the evt2 file you will need to do additional filtering.

Some basic filtering can be done on ACIS files before reading into xselect. The perl script /chandra/software/scripts/acisscreen runs fselect to throw away events with GRADE not equal to 02346, with PI equal to 0, 1, and 1024, with CHIPX any of 256, 257, 512, 513, 768, 769, with STATUS non-zero, and with CHIPX,CHIPY for a number of hot columns and pixels. The CHIPX rejections are made because these columns lie on the edges of read-out node areas and event selection will not operate correctly since the charge cloud will be split between 2 different read-out nodes. This filtering can reduce the size of your event file by an order of magnitude and will remove most of the linear structures seen in the FI chips.

The hot columns and pixels thrown away by acisscreen are all the ones that we have identified from observations and which have been listed by the CXC. There may be additional bad columns or pixels in your observation. A useful trick to find them is to make images from one chip at a time using CHIPX, CHIPY - any features with widths of one pixel will be due to problems with the chip. If you don't want to remove the hot columns and pixels then run acisscreen with the third argument "no". Note that the CIAO ARF and exposure map creation software use the bad pixel file that comes with your observation. If you remove additional bad pixels you may want to modify this file. See the CIAO updating the bad pixel list thread to see how to make the tools use a new bad pixel file.

Gain correcting

If you intend to work in PI space you may need to recalculate the PI if a new gain map has been released since your data was processed (this will almost certainly be the case for S3 data if you want to use the new FEFs released in August 2001). The script /chandra/software/scripts/acisgaincorr automates this process. It will check the file to see which gain file was used. If this is not the most recent release then the script will run the CIAO tool to recalculate PI.

Aspect correcting

It may be necessary to correct the aspect in for your data due to various bugs in the processing. Information summarizing various small errors and how to correct an 8 arcsec offset is available. A CIAO v2 thread explains how to correct for aspect offsets.

Running XSELECT

You can either read ACIS event files in or set up an observation catalog by specifying mission as AXAF and instrument as ACIS. The information displayed includes the DETNAM which lists which CCDs are operating (0-3 are I0-I3 and 4-9 are S0-S5). FIRSTROW and NROWS indicate whether windowing was used.

The default image coordinates are sky with a factor of 4 binning, which produces 2 arcsec pixels and a 16 Mbyte image. ACIS event files have a separate set of good time intervals (GTI) for each chip. If you do an extract at this point xselect will use the first set of GTI in the file. This is good enough just for looking at the image to see where interesting features lie.

To select data from a subset of chips and make a better calculation of the GTI you can use the select chip command. This takes as an argument a string of chip identifiers. These can be either numbers (0-9) or 2 character names (I0, I1, etc.). So, example selections are S3, for the main BI chip, or "0 1 2 3", for the four imaging chips. The select chip command creates a new file containing only the events on the selected chips with an appropriate GTI extension. If a single chip is selected then the GTI for that chip is copied to the new file. If multiple chips are selected then the GTIs for these chips are merged together and the result copied to the new file.

Making images

The select chip command also calculates the minimum and maximum values of X and Y in the selected event. It uses this to set the xycenter and xysize which the extract command uses as filters. This will probably mean a small enough section of the focal plane is selected that a full resolution image can be constructed. Do this by set xybinsize 1 1 and extract image.

If this image is still too large you can change xycenter and xysize to make it smaller or you can make a region file of the required area. When filtering with a region file you will need to add the fullimage=no argument to the extract command. This ensures that the image created is chopped down to a box encompassing the selected region.

Note that the default in xselect is now to plot images using ds9. This has the major advantage that regions can be given entirely in sky coordinates so you no longer have to worry about what binning factor was used to make the image. Writing regions in sky coordinates is not the default in ds9. To switch go to the Region pull-down menu, select the option "Save/List Coordinate System" and click on "Equatorial J2000".

An illustrative xselect run.

Making spectra, RMFs, and ARFs

Currently there seems to be confusion on whether it is best to extract PHA or PI spectra. If you are extracting a spectrum over a large region you should probably use PI. Anyway, both are supported within xselect. If you do use PI then when you save the spectrum you must give the group=no argument (or answer no to the question about grouping the spectrum).

Response matrices can only be calculated for multiples of 32x32 pixel sections of the chip. The size depends on the chip. For S3 the matrices are calculated on 32x32 pixel sections, for other chips the sections are larger. By default xselect now uses CHIPX and CHIPY with a binning of 32 as the WMAP coordinates. This means that each image bin in the WMAP gives the counts in a 32x32 pixel section on the chip so we can calculate a matrix for the source by summing matrices for each section and weighting by the number of counts in that section (strictly speaking this is not the right thing to do but it should be good enough for most purposes provided the region is not too large).

The script /chandra/software/scripts/acismakermf automates the calculation of RMFs. If you specify an ARF file or an energy specification string (eg "0.3:10.0:0.01") as the final argument then the script will run the CIAO tool mkrmf to build the RMFs and add them together. If you do not specify an ARF file and the chip is S3 then the script sums up pre-calculated RMFs (NB I have not recalculated these yet so don't use this option).

The creation of ARFs is not as automated yet. You will need to start by making an aspect histogram file from the aspect offset file in the standard distribution (this is the file acis*_aoff1.fits). You can do this by running the script /chandra/software/scripts/acisarfprep. The arguments are your event file and the aspect offset file. The script will only create an aspect histogram file if one does not already exist (it assumes the file has name acis*_aoff1_hist.fits). Under CIAO v1 this script also updated the ardlib.par file to use the QE non-uniformity maps to correct for some of the effects of radiation damage. Under CIAO v2 this is done automatically using the CALDB.

You can make an ARF file using the CIAO v2 tool mkarf. Note that the position required is in unbinned detector coordinates. Also, if you want to make an ARF file on the same energy grid as an RMF file, eg foo.rmf, you need to set the engrid parameter to "grid(foo.rmf[matrix][cols energ_lo, energ_hi])". The help file for this is incorrect.

Another illustrative xselect run.