The ACIS "Blank-Sky" Background Files

Download the background files

The ACIS "blank-sky" background files are not included in the main CALDB download file, due to the substantial filesize. If you have not already installed them, you must download the background files tarfile from the CALDB Download page and install it before continuing with this thread.

The background files are installed in the $CALDB/data/chandra/acis/bcf/bkgrnd/ directory.

Download the scripts

This thread uses the acis_bkgrnd_lookup and lc_clean.sl scripts. The plotting capabilities of lc_clean.sl have not yet been replaced in CIAO 4.0, because they require significant updates to use the new version of ChIPS. Run this thread in CIAO 3.4 if you require plotting.

unix% grep Id `which acis_bkgrnd_lookup`
% Id: acis_bkgrnd_lookup,v 2.0 2007/04/25 16:43:34 egalle Exp 

unix% grep Id $ASCDS_CONTRIB/share/slsh/local-packages/lc_clean.sl
% Id: lc_clean.sl,v 1.10 2007/04/05 13:04:21 egalle Exp 

Please check that you are using the most recent version before continuing. If you do not have the scripts installed or need to update to a newer version, refer to the Scripts page.

Naming scheme

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

unix% ls -1 $CALDB/data/chandra/acis/bcf/bkgrnd/
acis0D2000-12-01bgstow_ctiN0004.fits
acis0iD1999-09-16bkgrndN0002.fits
acis0iD2000-01-29bkgrnd_ctiN0005.fits
acis0iD2000-01-29bkgrndN0003.fits
acis0iD2000-12-01bkgrnd_ctiN0004.fits
acis0iD2000-12-01bkgrndN0002.fits
acis1D2000-12-01bgstow_ctiN0004.fits
acis1iD1999-09-16bkgrndN0002.fits
acis1iD2000-01-29bkgrnd_ctiN0005.fits
...

The naming scheme for CTI-corrected data is:

acis<chip><aimpoint>D<date>bkgrnd_ctiN<version>.fits

For uncorrected data, the naming is:

acis<chip><aimpoint>D<date>bkgrndN<version>.fits

The files which have "bgstow" in place of "bkgrnd" in the filename are particle-only background files created from data taken when the HRC was in the focal plane (e.g. ACIS was "stowed"). There is no ACIS-S/ACIS-I distinction for these data, so an "<aimpoint>" is not included in the filename.

Using acis_bkgrnd_lookup

The acis_bkgrnd_lookup script makes it easy to find an ACIS background file that matches your data. The script takes an input event file and returns a list of background files for all the ACIS chips in the file that have events on them:

unix% acis_bkgrnd_lookup evt2_c7.fits
/soft/ciao/CALDB/data/chandra/acis/bcf/bkgrnd/acis7sD2000-01-29bkgrnd_ctiN0001.fits

This file only has data on ACIS-7 (ACIS-S3), so a single file is returned. The path reflects where the CALDB is installed on your system; here, $CALDB is set to /soft/ciao/CALDB.

In addition to being printed to the screen, the list of background files is also stored in the outfile parameter:

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

The input file can include a Data Model filter as long as the resulting file is still a table with a ccd_id column, such as "acisf01838N001_evt2.fits[ccd_id=7]". In this example, we use a spatial region to filter the original event file. The resulting background file(s) will be chosen to match the CCDs that are covered by the circle:

unix% acis_bkgrnd_lookup "acisf01838N002_evt2.fits[sky=circle(6072.5,4632.5,320)]"
/soft/ciao/CALDB/data/chandra/acis/bcf/bkgrnd/acis1sD2000-01-29bkgrnd_ctiN0005.fits
/soft/ciao/CALDB/data/chandra/acis/bcf/bkgrnd/acis3sD2000-01-29bkgrnd_ctiN0005.fits

Two files are returned, so the outfile parameter contains a comma-separated list:

unix% pget acis_bkgrnd_lookup outfile
/soft/ciao/CALDB/data/chandra/acis/bcf/bkgrnd/acis1sD2000-01-29bkgrnd_ctiN0005.fits,
/soft/ciao/CALDB/data/chandra/acis/bcf/bkgrnd/acis3sD2000-01-29bkgrnd_ctiN0005.fits

No matching file and identical lookup cases

There are a number of known cases where acis_bkgrnd_lookup cannot find a background file for the dataset and exits with this error:

# acis_bkgrnd_lookup: ERROR: Unable to find an ACIS background file to match <filename>

There are no background files for:

• non-CTI-corrected data on ACIS-1

• any data on ACIS-4

• CTI-corrected data on ACIS-9

• ACIS-0 data, when ACIS-S is in the focal plane (a SIM_Z limit is exceeded)

There are also a few cases that result in identical lookup results:

• For the front-illuminated (FI) chips, there is no difference between:

  • CTI_APP = PPPPPNPNPP
  • CTI_APP = PPPPPBPBPP

  since the parallel CTI-correction is applied to all FI chips either way.

• For the back-illuminated (BI) chips, there is no difference between any of these:

  • CTI_APP = NNNNNNNNNN
  • CTI_APP = PPPPPNPNPP
  • CTI_CORR = YES
  • CTI_CORR = NO

  since no CTI correction is applied to BI chips for any of those configurations.

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 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 in Figure 1 and listed below:

[Version: full-size]

Figure 1: Source regions overlaid on the image

The regions defined in region file sources.reg overlaid on the image img8_c7.fits in ds9.

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 this example, we do not apply any energy filter to the lightcurve; 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.

The dmextract tool is used to create the lightcurve of the selected region. First, get the GTI interval from the event file:

unix% dmlist evt2_c7_bg.fits"[GTI7]" data

------------------------------------------------
Data for Table Block GTI7
------------------------------------------------

ROW    START                STOP

     1  84245789.1549994648  84253741.1550068706

These times will be used as the lower and upper limits for extracting the lightcurve. The same binning as the background dataset - 259.28 seconds - is used, so the filter is:

[bin time=84245789.155:84253741.155:259.28]

The filter could also be defined as "[bin time=::259.28]", in which case the TSTART and TSTOP header values are used for the endpoints. This approach is valid, though it will probably create some empty bins in the output lightcurve, since that time range is longer than the good time interval.

Run dmextract to create the lightcurve:

unix% punlearn dmextract
unix% pset dmextract infile="evt2_c7_bg.fits[bin time=84245789.155:84253741.155: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=84245789.155:84253741.155: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

The S-Lang script lc_clean.sl selects those regions of the lightcurve that 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 script must be loaded into slsh before it can be run (this step is only necessary once per session):

unix% slsh
slsh version 0.8.2-0; S-Lang version: 2.1.3
Copyright (C) 2005-2006 John E. Davis <jed@jedsoft.org>
This is free software with ABSOLUTELY NO WARRANTY.

slsh>  () = evalfile( "lc_clean.sl" );

The verbose flag to 1 to produce screen output. All other parameters are left at the default values.

slsh> lc->verbose = 1;                
slsh> lc_clean( "evt2_c7_bg.lc" );
Version of code: 1.10
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   = 31
Max length of one bin                = 255.997 s
Num. bins with a smaller exp. time   = 1
Number of bins with a rate of 0 ct/s = 0

Calculated an initial mean (sigma-clipped) rate of 0.50264 ct/s
Lightcurve limits use a scale factor of 1.2 about this mean
Filtering lightcurve between rates of 0.418866 and 0.603168 ct/s
Number of good time bins = 29
Mean level of filtered lightcurve = 0.501744 ct/s

In order to create a GTI file, we need to specify an output filename; here we use "evt2_c7_bg.gti", then re-run the filtering:

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

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

Calculated an initial mean (sigma-clipped) rate of 0.50264 ct/s
Lightcurve limits use a scale factor of 1.2 about this mean
Filtering lightcurve between rates of 0.418866 and 0.603168 ct/s
Number of good time bins = 29
Mean level of filtered lightcurve = 0.501744 ct/s

Creating GTI file
Created: evt2_c7_bg.gti

slsh> 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 "acisf01712N003_evt2.fits[energy=500:7000,ccd_id=7]" evt2_flare.fits

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)

unix% punlearn dmextract
unix% pset dmextract infile="evt2_flare.fits[exclude sky=region(exclude.reg)][bin time=77379634.145:77407432.550: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):

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% slsh
slsh version 0.8.2-0; S-Lang version: 2.1.3
Copyright (C) 2005-2007 John E. Davis <jed@jedsoft.org>
This is free software with ABSOLUTELY NO WARRANTY.

slsh> () = evalfile( "lc_clean.sl" ); 

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

Calculated an initial mean (sigma-clipped) rate of 2.01956 ct/s
Lightcurve limits use a scale factor of 1.2 about this mean
Filtering lightcurve between rates of 1.68296 and 2.42347 ct/s
Number of good time bins = 3
Mean level of filtered lightcurve = 2.12893 ct/s

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

By creating a histogram of the rate, it was determined that the mean rate is close to 0.7 count/s; we re-run lc_clean(), fixing the mean to this value:

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

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 = 12
Mean level of filtered lightcurve = 0.739918 ct/s

slsh> quit;

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.

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+
7851.3069951925

unix% dmkeypar evt2_c7_clean.fits EXPOSURE echo+
7339.3133136346

Analysing datasets with multiple chips

In CALDB 3.4.0, the background data files were divided so that there is one chip per file. This was done so that a unique background file is returned for each chip that contains data in the event file.

In order to make a background event file that contains more than one chip, it is necessary to run dmmerge to combine the files. For example:

unix% dmmerge \
      "acis6sD2000-01-29bkgrnd_ctiN0005.fits,acis7sD2000-01-29bkgrnd_ctiN0001.fits,acis8sD2000-01-29bkgrnd_ctiN0001.fits" \
      merge_bg.fits 

Be sure to read the caveat about the time keywords in merged headers, and correct your file.

Then continue with the Matching calibration to the event data step.

Matching calibration to the event data

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

unix% dmkeypar evt2_c7_clean.fits GAINFILE echo+
acisD2000-01-29gain_ctiN0006.fits

unix% dmkeypar bgevt2_c7.fits GAINFILE echo+
acisD2000-01-29gain_ctiN0006.fits

The two gain files should have the same date and version number in the filename, as shown here. If they do not match, reprocess the background file with acis_process_events, specifying the exact gainfile that was used on the data.

Also, create a custom event definition that does not contain a time definition (e.g. take the standard eventdef and remove "d:time"). If the time specification is left in, acis_process_events will create a column where every event has a time equal to TSTART; this will cause problems later in the analysis.

unix% acis_process_events infile=bgevt2_c7.fits outfile=bgevt2_c7_newgain.fits \
      acaofffile=NONE stop="none" doevtgrade=no apply_cti=yes apply_tgain=no \
      calculate_pi=yes \
      gainfile=$CALDB/data/chandra/acis/bcf/gain/acisD2000-01-29gain_ctiN0006.fits \
      eventdef="{s:ccd_id,s:node_id,i:expno,s:chip,s:tdet,f:det,f:sky,s:phas,l:pha,l:pha_ro,f:energy,l:pi,s:fltgrade,s:grade,x:status}"

unix% dmkeypar bgevt2_c7_newgain.fits GAINFILE echo+
acisD2000-01-29gain_ctiN0006.fits

acis_process_events will print several warnings that may be ignored. Read the acis_process_events ahelp file for more details on using this tool.

CTI and TGAIN Calibration Files

The calibration files used to apply the CTI and time-dependent gain corrections should also match in the event and background data. In practice, though, it is not currently possible to apply newer CTI and TGAIN correction the background files in the CALDB; they lack some columns required by acis_process_events.

The error introduced by this mismatched calibration should not be very significant for the faint, extended objects for which people use these backgrounds.

Reproject the background data

The aspect solution of the observation is applied to the background dataset - bgevt2_c7.fits - by reproject_events, which fills in the SKY column of the background file. ObsID 1838 has only one asol file, which we assume to be in the current working directory. It is possible to use multiple asol files by using a stack for the aspect parameter; see this FAQ for more information.

The random parameter is set to a value other than -1. This tells the tool to apply a random aspect solution to each background event, thus sampling the dither of the observation.

The GTIs used are taken from the match file (i.e. the cleaned event file, evt2_c7_clean.fits), which means that the output file will only contain events for those chips contained in the match file.

unix% punlearn reproject_events
unix% pset reproject_events infile=bgevt2_c7_newgain.fits
unix% pset reproject_events outfile=bgevt2_c7_reproj.fits
unix% pset reproject_events aspect=pcadf084244404N001_asol1.fits
unix% pset reproject_events match=evt2_c7_clean.fits
unix% pset reproject_events random=0
unix% reproject_events
Input dataset/block specification (bgevt2_c7_newgain.fits):
Output dataset/block specification (bgevt2_c7_reproj.fits):
Match file (evt2_c7_clean.fits):

You can check the parameter file that was used with plist reproject_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 an RMF file for the background region:

For -120 data with the CTI correction applied, mkacisrmf should be used to make the RMF.

For all other data, use mkrmf. First run acis_fef_lookup to find the FEF file, giving it the source event file (not the background file) as the infile parameter. 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 infile parameter of mkrmf.

The same FEF filename and filter should be used for the feffile parameter in mkwarf (i.e. instead of "CALDB").

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.

Bad pixel maps

The background files were created using a more conservative list of bad pixels than the early processing of the data, but reprocessed Chandra data should match more closely.

The total area of the detector covered by hot pixels is very small, so different pixel filtering is not a concern, unless a bright hot pixel is left in the user's data. Bad columns are more important and ideally, the same bad pixel and column list should be applied to the data and the background, and also used for making the exposure maps. This excerpt was taken from the bad pixels and columns section of the Cookbook; refer to that document for more details.