/ ciao / caveats / acis_shadow_badpix.html

Caveats about ACIS Frame Store Shadow Bad Pixels

Fixed in CIAO 4.14

This bug was fixed in CIAO 4.14.

Summary: ACIS "shadow" bad pixels not being included in responses in CIAO 4.12 and CIAO 4.13.

Introduction

In CIAO 4.12 together with CALDB 4.9.0 (also in standard data processing ASCDSVER=10.8.3) , the CXC started to include the bottom rows of each ACIS CCD in the standard bad pixel files . This is because the frame-store covering the readout part of the CCD casts an X-ray "shadow" on the bottom rows limiting the ability to properly calibrate those rows. The list of rows affected by the frame store shadow varies chip-to-chip and are listed here:

ACIS CCD_ID	Shadowed CHIPY
0	1-5
1	1-7
2	1-6
3	1-6
4	1-8
5	1-8
6	1-8
7	1-8
8	1-7
9	1-7

Events detected in these shadow regions are marked as bad pixels in the L1 event file (have STATUS bits 04 set) and are filtered out of the L2 event file. The "shadow" bad pixels are stored in the bad pixel file, bpix1.fits, and are tagged with a newly designated STATUS bit 17.

Problem

However, due to an oversight, the new status bit is not automatically recognized by the tools which create the instrument responses. Specifically those tools involved in computing the effective area:

Along with the contributed scripts which use those tools:

The new status bit is ignored by these tools and the detector efficiency is being computed as if these pixels were good. Therefore, the counts (events) have been filtered out but the effective area has not been corrected for the loss. This will affect the flux estimates for sources imaged at the bottom edges of the detectors. However, since Chandra dithers and the size of the dither pattern is much larger than the "frame store shadow", most sources will not be significantly affected by this error.

ciao-contrib v4.13.1 release has fixes for scripts

The CIAO contributed scripts release v4.13.1 (March 2021) includes updates to the scripts (specextract, srcflux, mktgresp, fluximage, flux_obs, and merge_obs) which corrects the handling of the "shadow" bad pixels. Users working with data near the edges of the detectors are encouraged to upgrade as soon as possible.

How to Check If Your Source is Affected?

Users who are unsure if their source is located near the frame store shadow can check the "CHIPY" values in the event file, for example with dmstat:

% dmstat "acisf20951_repro_evt2.fits[sky=circle(3742,5241,50)][cols chipy]"
chipy[pixel]
    min:    7            @:    156
    max:    80           @:    157
   mean:    33.573684211
  sigma:    17.060028448
    sum:    6379
   good:    190
   null:    0

Since the minimum chipy value is 7, this source is probably affected by the frame store shadow. Users can estimate the size of the error using the dither_region tool to compute the fraction of the area exposed in their region.

% acis_set_ardlib acisf20951_repro_bpix1.fits
% pset dither_region \
    infile='pcadf654520032N002_asol1.fits' \
    region='circle(3742,5241,46.161508)' \
    maskfile='acisf20951_000N002_msk1.fits' \
    wcsfile='acisf20951_repro_evt2.fits' \
    maxpix='4000'
% dither_region detsubsys='' outfile=dr_noshadow.fits 
% dither_region detsubsys='BPMASK=0x03ffff' outfile=dr_shadow.fits 
% dmdiff dr_noshadow.fits"[cols fracarea]" dr_shadow.fits"[cols fracarea]"

Examples

In Figure 1 we show an example of an ACIS-I observation. The events are shown as dots and the percent difference in the exposure maps created by including and omitting the frame store shadow regions is shown in color. The difference is isolated to areas at the bottom of each CCD. However, due to dither, there are events in this region which will be over-exposure-corrected yielding underestimates of the flux.

Figure 1. Exposure Map Comparison

[Thumbnail image: showin image of exposure map percent diff]

[Version: full-size]

[Print media version: showin image of exposure map percent diff]

Figure 1. Exposure Map Comparison

This image shows the percentage difference in the exposure map between when the frame store shadow bad pixel bits are include and excluded. The difference is isolated to the bottom edge of the CCDs; however, there are events in this area (drawn as dots) which will be over-exposure corrected.

The insert plot shows the projection of the red box at the edge of the detector. From this we can see that the difference is isolated to a ~20 arcsec band along the bottom of the CCDs. This is due to dither.

In Figure 2 we show an example of the effects on the ARF for a source located at the bottom edge of the detector. The difference in the ARF is ~15% but varies slightly with energy (while the geometric area is fixed, the pixels in that area have slightly different response vs. energy.)

Figure 1. ARF Comparison

[Thumbnail image: show src and comparing arfs]

[Version: full-size]

[Print media version: show src and comparing arfs]

Figure 1. ARF Comparison

(Left) Shows a source located at the bottom of ACIS-8. (Right) Shows the weighted ARF computed by including (red) and omitting (blue) the frame store shadow bit. The corrected ARF is ~15% lower than the uncorrected ARF but varies slightly with energy . Since the uncorrected ARF is over estimating the effective area, the flux will be under-estimated. The energy dependence in the difference here is small (~4%) so it will not likely cause a significant difference in fitted parameters.

These results are specific to this source in this observation. Other sources may have larger or smaller differences.

Work Arounds

The CXC is working on updates to the contributed scripts listed above and to the underlying code, ardlib, which processes t he bad pixel files.

In the interim users can manually create their response files: ARFs and Exposure maps, following the step-by-step sections of the various threads and include the additional BPMASK qualifier to the tools' detsubsys specification, ie

% mkarf ... detsubsubsys="ACIS-7;BPMASK=0x03ffff" ...

Alternatively users could remove the new shadow bad pixels from their badpixel lists by re-running acis_build_badpix with bitflag='00000000000000022221100020022222'

% acis_build_badpix ... calibfile=acis_repro_bpix1.fits \
  outfile=acis_repro_noshadow_bpix1.fits \
  bitflag='00000000000000022221100020022222' ...

Users would then need to reprocess their events files as described in the Customizing an ACIS Bad Pixel File thread.

Blank Sky and Stowed Background Event files

The ACIS blank sky files and the stowed background files do not have the events in the frame store shadow marked as bad pixels.

/ ciao / caveats / acis_shadow_badpix.html