Using the ACIS "Blank-Sky" Background Files

Naming scheme of the background files

The ACIS background datasets are stored in the CALDB at $CALDB/data/chandra/acis/bcf/bkgrnd/, arranged into different focal-plane temperatures, and divided by both aimpoint (i.e. ACIS-I or ACIS-S) and chip number:

unix% ls -1 $CALDB/data/chandra/acis/bcf/bkgrnd/
acis0iD1999-09-16bkgrndN0001.fits
acis1iD1999-09-16bkgrndN0001.fits
acis1sD2000-01-29bkgrndN0002.fits
acis1sD2000-01-29bkgrnd_ctiN0001.fits
acis1sD2000-12-01bkgrnd_ctiN0001.fits
acis236sD2000-01-29bkgrndN0002.fits
acis236sD2000-01-29bkgrnd_ctiN0001.fits
...

The naming scheme is for CTI-corrected data is:

acis<chip(s)><aimpoint>D<date>bkgrnd_ctiN<version>.fits

and for un-corrected data it is:

acis<chip(s)><aimpoint>D<date>bkgrndN<version>.fits

Finding the correct file(s)

If you are working with ACIS-S3 (chip 7), please read the Selecting a file for ACIS-7 (Chip S3) caveat before continuing.

To make finding these files easier, we provide the acis_bkgrnd_lookup script. If you give it an event file it will return a list of background files for those ACIS chips with events:

unix% acis_bkgrnd_lookup
Event file for which you want background files (): evt2_c7.fits
# pixlb (CIAO3.3): WARNING:  2 CALDB files found. Using the first

/soft/ciao/CALDB/data/chandra/acis/bcf/bkgrnd/acis7sD2000-01-29bkgrndN0003.fits

(here $CALDB is set to /soft/ciao/CALDB). The warning is explained in the Selecting a file for ACIS-7 (Chip S3) caveat.

Rather than parse the screen output of the script it is easier to get the list of background files from the outfile parameter. Here there is only one file:

unix% pget acis_bkgrnd_lookup outfile
/soft/ciao/CALDB/data/chandra/acis/bcf/bkgrnd/acis7sD2000-01-29bkgrndN0003.fits

The returned file contains, in this example, data for chip 7 only. We make a local copy of the background file for use in our analysis (since the background file contains events only for ACIS-S3 we can just copy the file rather than applying a "ccd_id" filter with dmcopy):

unix% cp \
  $CALDB/data/chandra/acis/bcf/bkgrnd/acis7sD2000-01-29bkgrndN0003.fits \
  bgevt2_c7.fits

The script can be given an event file with a Data Model filter - such as a spatial filter - to restrict attention to just those chips covered by the filter. So the previous example could have used "acisf01838N001_evt2.fits[ccd_id=7]". In the following example we use a large circular region - which covers several ACIS chips - to show how multiple files are returned:

unix% acis_bkgrnd_lookup "acisf01838N001_evt2.fits[sky=circle(4064.5,4232.5,1320)]"
# pixlb (CIAO3.3): WARNING:  2 CALDB files found. Using the first

/soft/ciao/CALDB/data/chandra/acis/bcf/bkgrnd/acis236sD2000-01-29bkgrndN0002.fits
/soft/ciao/CALDB/data/chandra/acis/bcf/bkgrnd/acis7sD2000-01-29bkgrndN0003.fits

and the oufile parameter contains a comma-separated list of files:

unix% pget acis_bkgrnd_lookup outfile
<path>/acis236sD2000-01-29bkgrndN0002.fits,<path>/acis7sD2000-01-29bkgrndN0003.fits

where <path> is $ASCDS_INSTALL/CALDB/data/chandra/acis/bcf/bkgrnd.

Note that it is not guaranteed that there will be one file per chip; this depends on how the ACIS background files have been created.

Do the gain files match?

Please note that the background files were probably processed using a different gain file than that of your data. See the gain caveat below for further information.

Explicitly giving the CCD list and aimpoint

The script can still be run using the pre-CIAO 3.0 syntax by giving the three arguments (CCD list, aimpoint, and event file name) on the command line:

unix% acis_bkgrnd_lookup 7 s evt2_c7.fits
# pixlb (CIAO3.3): WARNING:  2 CALDB files found. Using the first

/soft/ciao/CALDB/data/chandra/acis/bcf/bkgrnd/acis7sD2000-01-29bkgrndN0003.fits

When run in this mode the parameter file is NOT used; this means that the outfile parameter will not contain the list of background files once the script has finished.

Users of this script should upgrade to the new method - where only an event file is needed, with Data Model filters to restrict the range of CCDs used - since support for the old calling syntax is likely to be removed in the future.

Remove bright sources

The background fields were filtered using a maximum rate that is 20 percent higher than the quiescent background level. It is therefore necessary to remove any bright sources from your dataset. For this example we have chosen to select the regions to exclude by eye, using ds9 and the image img8_c7.fits, saving the file in CIAO format. The resulting region file - sources.reg - is shown on the image here  and listed below:

unix% cat sources.reg
# Region file format: CIAO version 1.0
circle(4072.5,4252.5,400)
circle(4604.5,4804.5,48)

If any flux is left from the source, you should reduce the max_scale parameter of lc_clean() to account for this residual flux: for example, compare the expected background rate from the background files with those of your dataset within the same spatial region.

Now we create a copy of the event file, excluding the sources, using the DM filtering syntax:

unix% dmcopy "evt2_c7.fits[exclude sky=region(sources.reg)]" evt2_c7_bg.fits

Create the lightcurve

Note: in the example below we do not apply any energy filter to the lightcurve, so we use the full energy range of the dataset (0.3-10 keV here). This is not necessarily the optimal energy band to use for your observation. In particular, the period C background files released in CALDB v2.17 (i.e. those files with names matching acis*D2000-01-29bkgrndN0002.fits) were created using the following energy ranges (see Maxim's Cookbook for more information):

• BI chips are cleaned using the 2.5-7 keV band and use a bin size of 1037.12.

• FI chips are cleaned using a wider band of 0.3-12 keV (since most flares in FI chips have hard spectra). A bin size of 259.28 was used for these files.

Note: when the energy band for S3 filtering was changed to 2.5-7 kev, the bin size was changed from 259.28 to 1037.12. The larger time bin was required due to the small number of photons in that range. The following examples have not yet been updated to use the new BI-chip binning.

We use the dmextract tool to create the lightcurve of the selected region. Since the background datasets were created using a bin size of 259.28 seconds, we use the same:

unix% punlearn dmextract
unix% pset dmextract infile="evt2_c7_bg.fits[bin time=::259.28]"
unix% pset dmextract outfile=evt2_c7_bg.lc
unix% pset dmextract opt=ltc1
unix% dmextract
Input event file  (evt2_c7_bg.fits[bin time=::259.28]):
Enter output file name (evt2_c7_bg.lc):

The file evt2_c7_bg.lc contains the lightcurve for the data. You can check the parameter file that was used with plist dmextract.

Run the lc_clean.sl script

We use the S-Lang script lc_clean.sl to select those regions of the lightcurve do not contain flares. The algorithm used is taken from the lc_clean program created by Maxim Markevitch, and is different from that used by the analyze_ltcrv.sl script in the Filtering Lightcurves thread.

The S-Lang script must be loaded into ChIPS (or Sherpa) before it can be run (this step is only necessary once per ChIPS/Sherpa session):

chips> () = evalfile( "lc_clean.sl" )

or by loading the code using the --slscript option:

unix% chips --slscript lc_clean.sl

Here we use the default parameter values, except that we set the verbose flag to 1 to produce extra screen output:

chips> lc->verbose = 1
chips> lc_clean( "evt2_c7_bg.lc" )
Version of code: 1.9
Parameters used to clean the lightcurve are:
  mean      = NULL
  clip      = 3
  max_scale = 1.2
  max_sigma = NULL
  minfrac   = 0.1
  outfile   = NULL
  verbose   = 1

Total number of bins in lightcurve   = 38
Max length of one bin                = 255.997 s
Num. bins with a smaller exp. time   = 9
Number of bins with a rate of 0 ct/s = 7

Calculated an initial mean (sigma-clipped) rate of 0.489577 ct/s
Lightcurve limits use a scale factor of 1.2 about this mean
Filtering lightcurve between rates of 0.407981 and 0.587492 ct/s
Number of good time bins (drawn in green) = 29
Mean level of filtered lightcurve = 0.488992 ct/s

chips> print postfile evt2_c7_bg.eps

The "print postfile" command creates a postscript version of the ChIPS display window, as shown here . The green dots (upper plot) and line (lower plot) indicate those regions considered to be "good" by the algorithm. For this observation the background rate appears stable.

In order to create a GTI file, we need to specify an output filename; here we use "evt2_c7_bg.gti" (and reset the verbose tag to reduce the amount of information printed to the screen), then re-run the filtering:

chips> lc->verbose = 0
chips> lc->outfile = "evt2_c7_bg.gti"
chips> lc_clean( "evt2_c7_bg.lc" )
Total number of bins in lightcurve   = 38
Max length of one bin                = 255.997 s
Num. bins with a smaller exp. time   = 9
Number of bins with a rate of 0 ct/s = 7

Calculated an initial mean (sigma-clipped) rate of 0.489577 ct/s
Lightcurve limits use a scale factor of 1.2 about this mean
Filtering lightcurve between rates of 0.407981 and 0.587492 ct/s
Number of good time bins (drawn in green) = 29
Mean level of filtered lightcurve = 0.488992 ct/s

Creating GTI file
Created: evt2_c7_bg.gti

chips> quit

Since we specified an output file, the lc_clean() function has run dmgti, using the calculated range, and created the file evt2_c7_bg.gti. You can check the parameter file that was used with plist dmgti.

An example of a strong flare

The previous example showed an essentially stable background level. ObsID 1712, which is also used in the Filtering Lightcurves, contains a major flare event. First we create a lightcurve of the background of this observation:

unix% dmcopy "acisf01712N002_evt2.fits[energy=300:10000,ccd_id=7]" evt2_flare.fits

unix% punlearn dmextract
unix% pset dmextract infile="evt2_flare.fits[exclude sky=region(exclude.reg)][bin time=::259.28]"
unix% pset dmextract outfile=flare.lc
unix% pset dmextract opt=ltc1
unix% dmextract
Input event file  (evt2_flare.fits[exclude sky=region(exclude.reg)][bin time=::259.28]):
Enter output file name (flare.lc):

where

unix% cat exclude.reg 
# Region file format: CIAO version 1.0
rotbox(4200.3328,4137.9892,1129.5056,74.07019,24.22333)
circle(4076.5,4088.5,316)
circle(4296.5,5024.5,48)

When lc_clean() is run on this lightcurve, the routine finds that the filtered lightcurve contains less than 10 percent of the original exposure, and so stops (this limit can be changed by setting the variable lc->minfrac to something other than 0.1):

unix% chips --slscript lc_clean.sl

Welcome to ChIPS, version CIAO3.3
Copyright (C) 1999-2003, Smithsonian Astrophysical Observatory

chips> lc_clean("flare.lc")
Total number of bins in lightcurve   = 118
Max length of one bin                = 255.997 s
Num. bins with a smaller exp. time   = 12
Number of bins with a rate of 0 ct/s = 10

Calculated an initial mean (sigma-clipped) rate of 1.66018 ct/s
Lightcurve limits use a scale factor of 1.2 about this mean
Filtering lightcurve between rates of 1.38348 and 1.99221 ct/s
Number of good time bins (drawn in green) = 4
Mean level of filtered lightcurve = 1.51955 ct/s

** ERROR **
 Fraction of bins that are good is below limit of 0.1

 lc_clean("flare.lc");

which produces this plot .

We can use ChIPS commands to manipulate the plots to examine the lightcurve in more detail. In the following we switch to the first (i.e. top) plot and zoom in on the y axis (between 0 and 2 count/s) and then the histogram (plot 2) and filter on the same range in x:

chips> d 1 limits y 0 2
chips> d 2 limits x 0 2

The resulting plot looks like this .

The histogram of the rates suggest that the mean rate is close to 0.7 count/s; we re-run lc_clean(), fixing the mean to this value:

chips> lc->mean = 0.7 
chips> lc_clean("flare.lc")
Total number of bins in lightcurve   = 118
Max length of one bin                = 255.997 s
Num. bins with a smaller exp. time   = 12
Number of bins with a rate of 0 ct/s = 10

Using a fixed mean rate of 0.7 ct/s
Lightcurve limits use a scale factor of 1.2 about this mean
Filtering lightcurve between rates of 0.583333 and 0.84 ct/s
Number of good time bins (drawn in green) = 58
Mean level of filtered lightcurve = 0.693829 ct/s

The resulting plot looks like this .

See the comments in the lc_clean.sl file for more information on changing the filtering scheme used by the routine. Maxim Markevitch's Cookbook contains advice on filtering lightcurves with strong flares.

Exit ChIPS before continuing:

chips> quit

Filter the event list

We now filter the event list using the new GTI information, and check to see how the exposure time has changed

unix% dmcopy "evt2_c7.fits[@evt2_c7_bg.gti]" evt2_c7_clean.fits

unix% dmkeypar evt2_c7.fits EXPOSURE echo+
7854.4664748687

unix% dmkeypar evt2_c7_clean.fits EXPOSURE echo+
7229.7978514176

The lc_clean() function handles "end" bins slightly differently to the lc_clean tool, which can result in differences in the exposure time of order of the bin size (i.e. ~ 260 s for this dataset).

Using the background files with specextract

While it is possible to use the ACIS "blank-sky" background files as input to the specextract script, the older files in the CALDB do not work correctly "as-is". It is necessary to follow the workaround in the specextract bugs page in order to use these files with the script.

For more information on specextract, see the Using specextract to Extract ACIS Spectra and Response Files thread.

Selecting a file for ACIS-7 (Chip S3)

There are currently two files included in the CALDB for the -120C periods. For the period 2000-01-29 to 2000-12-01:

acis57sD2000-01-29bkgrndN0003.fits
acis7sD2000-01-29bkgrndN0003.fits

and for the period 2000-12-01 to the present:

acis57sD2000-12-01bkgrndN0002.fits
acis7sD2000-12-01bkgrndN0002.fits

Currently, acis_bkgrnd_lookup will return only the acis7s...fits files, not the acis57s...fits files; when doing so, it issues this warning:

# pixlb (CIAO3.3): WARNING:  2 CALDB files found. Using the first

The acis7s...fits file is a larger data set, and much preferable as a default file, for both the 2000-12-01 and 2000-01-29 periods.

The acis57s files include identical data sets for both S1 and S3. They have fewer events and poorer statistics for the S3 chip than do the acis7s files, particularly in the 2000-12-01 period case. If you wish to have matched background sets between ACIS-5 and ACIS-7, you must select the acis57s file by hand:

For ObsIDs taken in the 2000-01-29 through 2000-12-01 period, select the file $CALDB/data/chandra/acis/bcf/bkgrnd/acis57sD2000-01-29bkgrndN0003.fits. For the 2000-12-01 through the present period, select $CALDB/data/chandra/acis/bcf/bkgrnd/acis57sD2000-12-01bkgrndN0002.fits.

CTI correction

Here are some guidelines on how to use the ACIS background files with CTI-corrected data:

1. As of version 2.21, there are CTI-corrected background files available in the CALDB. These files were created with the correct gain file (see the GAINFILE header keyword), so do not re-run acis_process_events to apply a gain file.

   It is not currently possible to reprocess the background files in the CALDB with the Apply the ACIS CTI Correction thread because they don't have the necessary columns.

2. Don't forget to run reproject_events.

3. When extracting spectra and responses, do the steps manually. Do not use psextract or acisspec. Read the Creating response files caveat for more information.

TGAIN correction

Background files with the time-dependent gain (TGAIN) correction applied are available from the ACIS background page. These files are not yet available in the CALDB.

Note that it is not possible to reprocess the background files in the CALDB to apply the TGAIN correction because they don't have the columns required by acis_process_events.

Creating response files

If you are just going to subtract the background spectrum (i.e. not fit it), then you do not need a separate RMF and ARF for the background spectrum. You may simply use dmextract to create the spectrum.

If you do need RMF/ARF files for the background region, use acis_fef_lookup to find the FEF file, giving it the source event file (not the background file) as the infile parameter.

For weighted cases, use chipid=none; for point sources, find the coordinates of the source in chip coordinates (see the Step-by-Step Guide to Creating ACIS Spectra for Pointlike Sources thread for an example of how to do this). This filename should be used (including any DM filter) for the feffile parameter in mkwarf (i.e. instead of "CALDB") and the infile parameter of mkrmf.

Soft galactic flux and nH

The background datasets are constructed from a set of observations which are spread out across the sky. There is therefore no guarantee that the background at the position of your observation will match that in the background maps. An external check on the background can be made using the ROSAT All-Sky Survey R4-R5 band images. The Cookbook discusses these issues further.

Gain files

The background files were generated using a gain file that may not match the one used for your observation, or be the most up to date. The GAINFILE keyword in the header of the background files should match that of your source file - eg:

unix% dmkeypar \
      $CALDB/data/chandra/acis/bcf/bkgrnd/acis7sD2000-01-29bkgrndN0003.fits GAINFILE echo+
/soft/ciao/CALDB/data/chandra/acis/bcf/gain/acisD2000-01-29gain_ctiN0001.fits

unix% dmkeypar acisf01838N001_evt2.fits GAINFILE echo+
/soft/ciao/CALDB/data/chandra/acis/bcf/gain/acisD2000-01-29gainN0001.fits

unix% dmkeypar acisf01838N001_evt2.fits CALDBVER echo+
1.4

The two gain files should have the same date and version number in the filename. If the GAINFILE keywords do not match exactly, reprocess the background file with a newer gain map. There is one exception to this rule: since version 3 (N0003), the multiple -120 degree gain files in the CALDB contain identical data even though the dates are different. If both -120 gain files are the same version (whether N0003, N0004, or N0005), there is no need to reprocess the background file. This characteristic will persist until CALDB 4.0.0.

In the case where you need to reprocess the background file, simply follow the Apply an ACIS Gain Map thread.

Filter name and CALDB lookups

Some of the background files have the FILTER header keyword set to a value of NONE, whereas the correct value for Chandra files is -. In most cases this does not cause any problems, however it can if the CALDB is searched to find the appropriate effective area information. If tools such as mkwarf return an error similar to

# mkwarf (CIAO3.3):
WARNING: No files found matching CALDB search: 
tel=chandra 
inst=acis 
det=ACIS-3 
filt=NONE 
product=QE 
start_date=2000-02-23T06:31:59 
start_time=06:31:59 
stop_date=2000-08-04T11:37:49 
stop_time=11:37:49 
query=- 

 ***ARDLIB error: calRetrieve failed to retrieve acis QE file. 
# mkwarf (CIAO3.3): ERROR: Problems getting QE for ACIS-3

then edit the header of the background file (e.g. bg.fits below) to change NONE to -:

unix% dmkeypar bg.fits filter echo+
NONE
unix% punlearn dmhedit
unix% dmhedit bg.fits none add FILTER -
unix% dmkeypar bg.fits filter echo+
-

Bad pixel maps

The background files were created using a more conservative list of bad pixels than the early processing of the data, however the reprocessed data should match more closely. The bad pixel mask used for a particular observation is stored in the bpix1 file in the secondary/ directory of the data distribution. As discussed in the cookbook, it is mainly the masked columns which should match.