Caveats about ACIS Frame Store Shadow Bad Pixels
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.
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|
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.
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.
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]"
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
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
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.