Analysing the ACIS Background with the "Blank-Sky" Files

Naming scheme

The ACIS background datasets are stored in the CALDB at $CALDB/data/chandra/acis/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/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 1838_c7_clean.fits
/soft/ciao/CALDB/data/chandra/acis/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/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 "acisf01838_repro_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 "acisf01838_repro_evt2.fits[sky=circle(6072.5,4632.5,320)]"
/soft/ciao/CALDB/data/chandra/acis/bkgrnd/acis1sD2000-01-29bkgrnd_ctiN0005.fits
/soft/ciao/CALDB/data/chandra/acis/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/bkgrnd/acis1sD2000-01-29bkgrnd_ctiN0005.fits,
/soft/ciao/CALDB/data/chandra/acis/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 for:
infile=<filename>
CCD_ID=<N> 

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.

Working with VFAINT data

When working with observations performed in very faint (VFAINT) mode which have had the ACIS background cleaning performed, a similarly-filtered blank-sky background file may be used.

The period D background files are composed of VFAINT mode observations and have the "potential background event" status bit set to 1 (status bit 23). As no other status bits are set in the background files, it is simple to filter out these events:

unix% dmkeypar evt2_clean.fits DATAMODE echo+
VFAINT

unix% dmcopy "bg.fits[status=0]" bg_cleaned.fits

OsbID 1838 was taken in FAINT mode, so this step is not necessary:

unix% rory-ciao44: dmkeypar 1838_c7_clean.fits DATAMODE echo+
FAINT

Analysing datasets with multiple chips

The background data files are divided so that there is one chip per file. This is 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 

A new dmmerge merging rule was introduced in CIAO 4.3 which recalculates the time-related header keywords in the output file from the time subspace. This enhancement resolves the caveat about the time keywords in merged headers.

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 1838_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. You will also need to 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 pix_adj=NONE \
      gainfile=$CALDB/data/chandra/acis/det_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.

Add the PNT header keywords

The pointing (PNT) header keyword values in the background files are set to zero:

unix% dmlist bgevt2_c7.fits header |grep PNT
0058 RA_PNT                                  0           Real8        Pointing RA
0059 DEC_PNT                                 0           Real8        Pointing Dec
0060 ROLL_PNT                                0 [deg]     Real8        Roll (fake)

These values indicate where the optical axis was during the observation. Having zero-values will cause the CIAO tool dmcoords to produce incorrect results when run with the background file.

To avoid this problem later in the analysis, the PNT values from the event file are copied into the background file header. This is done by creating a file of the event file header keywords with dmmakepar, extracting the PNT values, then adding them to the background file header with dmreadpar:

unix% dmmakepar 1838_c7_clean.fits event_header.par

unix% grep _pnt event_header.par > event_pnt.par

unix% cat event_pnt.par
ra_pnt,r,h,278.38657206626,,,"Pointing RA"
dec_pnt,r,h,-10.589269915682,,,"Pointing Dec"
roll_pnt,r,h,266.80752046013,,,"Pointing Roll"

unix% chmod +w bgevt2_c7.fits
unix% dmreadpar event_pnt.par "bgevt2_c7.fits[events]" clobber+

It is necessary to specify the "[events]" extension of the background file, or the keywords will be added to the NULL block header. The "clobber+" setting tells dmreadpar to overwrite the existing (zero) header PNT values.

Reproject the background data

The reproject_events tool can handle the special case of reprojecting a file which does not have an input time column, such as the ACIS background file. The tool takes the time range covered by the aspect solution of the observation and intersects it with the GTIs from the match file (1838_c7_clean.fits), which means that the output file will only contain events for those chips contained in the match file.

ObsID 1838 has only one aspect solution 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=0 parameter setting tells the tool to apply a random aspect solution to each background event, thus sampling the dither of the observation.

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

You can check the parameter file that was used with plist reproject_events. Note that:

• A random time within the range of the background data was selected and assigned to the event for the reprojection. The time is used only for the reprojection; the output file does not have a TIME column in it.

• reproject_events does not alter the duration of the background file in any way in this process. The time-related header keywords (e.g. TSTART, TSTOP) are identical in the input and output files. This preserves the original background count rate, regardless of what observation is matched.

Scaling the exposure time

Once you have created a background spectrum or image, you may wish to use the high energy data (above 10 keV) to see how the particle background normalization differs between your observation and the background. Absolute measurement of the unresolved cosmic X-ray background in the 0.5-8 keV band with Chandra by Hickox & Markevitch shows how to use the ACIS-stowed background for analysis of background-critical objects, including calculating a scaling factor based on high-energy flux measurements.

The ACIS background page includes a discussion of the time dependence of the background and how it affects spectra and spatial structure.

Imaging Analysis

If you have an exposure-corrected image, e.g. created by running fluximage, you also need to exposure-correct the background file for use in the analysis. After calculating the correct scaling factor based on the high-energy flux - e.g. see Hickox & Markevitch - or whatever other method you choose, then:

unix% get_sky_limits 2.3_bin2.emap
unix% set dmf = `pget get_sky_limits dmfilter`

unix% dmcopy "bgevt2.fits[energy=500:7000][bin $dmf]" 0.5-7.0_bin2.bgimg

unix% dmimgcalc infile="0.5-7.0_bin2.img,0.5-7.0_bin2.bgimg,2.3_bin2.emap" \
infile2= out=foo.img expr="imgout=((img1-xxxxx*img2)/img3)"

where "xxxxx" is the scale factor to account for the different exposure lengths and any variability of the background flux.

Spectral Analysis

Since the blank-sky background file comes from a different observation than your source observation, the exposure time may differ from that of your source. The spectral fitting programs, such as Sherpa or XSpec, properly account for the exposure times (and spectral extract region areas) when the background is subtracted from the source.

For example, in order to determine how many of the blank-sky background counts contribute to your source counts, the count rate of the background would be multiplied by the exposure time of the source:

src_counts - bg_counts*(src_exposure*src_backscal)/(bg_exposure*bg_backscal) 

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:

mkacisrmf should be used to make the RMF for any dataset which meets the requirements listed in mkacisrmf why topic.

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.

Particle background normalization

You may use the high-energy event data (above 10 keV) to see how the particle background normalization differs between your observation and the background file.