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

Using blanksky script

The blanksky script automatically locates the correct blanksky background files, reprojects them to match the observation, and and determines the proper scaling. The input event file should not be filtered on energy but should include any time filters.

unix% pset blanksky evtfile="acisf01838_repro_evt2.fits[ccd_id=7][@1838_c7_bg_deflare.gti]"
unix% pset blanksky outfile=1838_blank.evt
unix% pset blanksky tmpdir=./
unix% blanksky mode=h
Running blanksky
Version: 25 June 2020

Aspect solution file pcadf01838_000N001_asol1.fits found.

ACIS background file /data/chandra_caldb/ciao4.12/data/chandra/acis/bkgrnd/acis7sD2000-01-29bkgrnd_ctiN0002.fits found.

Calculated scale factor for 'weight_method=particle':
    ACIS-7: 0.05511728 written to the 'BKGSCAL7' header keyword.

The output 1838_blank.evt file is the background file to use for spectral and imaging analysis.

Extracting spectra from "blanksky" results

While the blanksky script will calculate scaling factors for each chip, which are stored by the BKGSCALn header keywords, what is extracted by dmextract/specextract is the unscaled background spectrum.

Since spectral analysis packages such as Sherpa and XSpec have no knowledge of these BKGSCALn keywords, the usual approach is to apply the scaling factor to either the EXPOSURE keyword or the AREASCAL keyword in the background spectrum file. It's one of the other. When the scaling is applied to the keyword, XSpec and Sherpa will automatically pick up the scaling factor and apply it to background model to be fitted so that the appropriate scaling can be accounted for while using the unscaled extracted background data.

If you intend to subtract the background from the source, then packages such as Sherpa and XSpec will automatically scale the background by exposure time (and a term that accounts for extraction region area), nominally by a factor of \(\frac{\mathtt{EXPOSURE}_{\mathrm{src}} \times \mathtt{BACKSCAL}_{\mathrm{src}}}{\mathtt{EXPOSURE}_{\mathrm{bkg}} \times \mathtt{BACKSCAL}_{\mathrm{bkg}}}\), before subtracting it from the source. The underlying software actually scales the background by \(\mathtt{AREASCAL}_{\mathrm{bkg}} \times \frac{\mathtt{EXPOSURE}_{\mathrm{src}} \times \mathtt{BACKSCAL}_{\mathrm{src}}}{\mathtt{EXPOSURE}_{\mathrm{bkg}} \times \mathtt{BACKSCAL}_{\mathrm{bkg}}}\), this scaling is also automatically applied to the defined background model. Standard extracted Chandra data products do not make use of the AREASCAL keyword, but since the OGIP format standard for PHA/PI files requires the inclusion of the keyword, it is just set to unity by the DM tools.

Starting with the CIAO contributed scripts package 4.13.1, BKGSCALn (n being the chip that your source falls on, or where the majority of the extraction region falls on) is copied over to the background spectrum's AREASCAL keyword by specextract so that the background model will be automatically scaled to match the extracted spectrum when read in by XSpec/Sherpa (although plotted background spectra may be displayed incorrectly scaled, for example with Sherpa's plot_bkg function), but this also means that if background subtraction is performed with the AREASCAL modified background spectrum, there will be a severe over-subtraction from the source spectrum. This can be resolved by resetting AREASCAL back to 1.0 in the background spectrum or interactively within Sherpa using the set_areascal function.

Another approach to obtain a scaled background spectrum—without the need to consider the header keywords or the need to scale the background model—is to extract a spectrum from the results of the blanksky_sample script, which takes a random sample of events from the unscaled blanksky background file to match the total number of events based on the calculated background scaling factor suitable for your observed data set. However, since there's a reduced number of background events in this sampled event file, you would lose the good statistics (i.e. smaller uncertainties) that come from having a large sample from the original tailored background files generated by 'blanksky'.

Using blanksky_image script

The blanksky_image scripts can be used to take the blank sky background event file created by blanksky and using the information stored in the header, to create a properly scaled blank sky image with matching WCS, dimensions, and using the same energies as are used in the input image file. The script also creates a background subtracted image.

unix% pset blanksky_image bkgfile=1838_blank.evt
unix% pset blanksky_image outroot=1838_blank
unix% pset blanksky_image imgfile=1838_c7_broad_thresh.img
unix% pset blanksky_image tmpdir=./
unix% blanksky_image mode=h clob+
Running blanksky_image
Version: 13 November 2019

The output images are named based on the background scaling method that was used. In this example the default particle method was used so the output images are the ones highlighted:

unix% ls -1 1838_blank*
1838_blank.evt
1838_blank_particle_bgnd.img
1838_blank_particle_bkgsub.img

The bgnd.img is the background image scaled to match the observation. The bkgsub.img is the background subtracted, net counts image.

This is the end of this thread. Users may want to review the Caveats (below). The rest of this thread shows the step-by-step instructions for creating the blank sky files that are used by blanksky and blanksky_image.

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_ctiN0005.fits
acis0D2005-09-01bgstow_ctiN0002.fits
acis0D2009-09-21bgstow_ctiN0002.fits
acis0iD1999-09-16bkgrndN0003.fits
acis0iD2000-01-29bkgrndN0004.fits
acis0iD2000-01-29bkgrnd_ctiN0006.fits
acis0iD2000-12-01bkgrndN0003.fits
acis0iD2000-12-01bkgrnd_ctiN0005.fits
acis0iD2005-09-01bkgrnd_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 file name 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_ctiN0002.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_ctiN0002.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_ctiN0006.fits
/soft/ciao/CALDB/data/chandra/acis/bkgrnd/acis3sD2000-01-29bkgrnd_ctiN0006.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_ctiN0006.fits,
/soft/ciao/CALDB/data/chandra/acis/bkgrnd/acis3sD2000-01-29bkgrnd_ctiN0006.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% 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_ctiN0002.fits,acis8sD2000-01-29bkgrnd_ctiN0002.fits" \
      merge_bg.fits 

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_ctiN0008.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. If they do not match, reprocess the background file with acis_process_events, specifying the exact gainfile that was used on the data.

N0007 vs. N0006

All of the early blank sky background files were created with the N0006 version of the detector gain calibration file. A new version of this file, N0007, was released in CALDB 4.6.9; however only the data for ACIS-5 (aka ACIS-S1) were updated.

The N0007 and N0006 files are otherwise identical and equivalent. There is no need to process the blank sky files through acis_process_events.

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_ctiN0008.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_ctiN0008.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 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=pcadf01838_000N001_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.

Subarray data

Some ACIS data are taken in subarray mode where only part of each CCD is used. For these observations, the fraction of the CCD used should be included when scaling the blank sky background. Users can check the number of rows used in the observations by examinging the NROWS header keyword:

unix% dmkeypar acisf01838_repro_evt2.fits NROWS echo+
1024

A value of 1024 indicates that the full CCD was readout. For values less than 1024, the background counts should be scaled by the ratio NROWS/1024.

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.