ACIS VFAINT Background Cleaning

Introduction

In ACIS very faint mode, there is a 5x5 pixel event island, instead of just a 3x3 event island (as in FAINT mode). Therefore, acis_process_events can use the pulse heights in the outer 16 pixels of the 5x5 event island to help distinguish between good X-ray events and bad events that are most likely associated with cosmic rays.

Due to the problem identified in the Elimination of Real Events section, the default for the chandra_repro script is check_vf_pha=no, (algorithm is not applied). Users should be careful when using this algorithm for all datasets with bright features.

Background Information

In VFAINT mode, there is the benefit of working with a 5x5 pixel event island, instead of just a 3x3 event island (as in FAINT mode). Therefore, acis_process_events can use the pulse heights in the outer 16 pixels of the 5x5 event island to help distinguish between good X-ray events and bad events that are most likely associated with cosmic rays. An event is considered to be a potential background event if one or more of those outer pixels is greater than a set split threshold. In that case, status bit 23 is set to one ("bad") for the event.

More information on this is available from the Reducing ACIS Quiescent Background Using Very Faint Mode page. The abstract from that page is included here:

ACIS particle background can be reduced significantly compared to the standard grade selection by screening out events with significant flux in border pixels of the 5x5 event islands. The particle background above 6 keV is reduced by a factor of 1.4 in the front-illuminated chips and ~ 1.25 in the back-illuminated chips. The background rejection is much better at soft energies - by a factor of 2 near 0.5 keV in FI chips and by a factor of 3 near 0.3 in BI chips. In the intermediate energies, 1-5 keV, the background is reduced by a factor of 1.1-1.15.

Running acis_process_events

Running acis_process_events with check_vf_pha=yes produces a new level=1 event file with possible background events flagged in status bit 23. By default, this is not enabled in the chandra_repro script Reprocessing Data to Create a New Level=2 Event File thread. Users can enable it by setting

unix% pset chandra_repro check_vf_pha=yes

or

unix% pset acis_process_events check_vf_pha=yes
unix% pset acis_process_events trail=0.027

The trail parameter

The amount of charge in the pixels above the center of the event island is due in part to a fraction of charge trailed from the other pixels (as a result of charge transfer inefficiency (CTI)). The trail parameter - set to the default value of 0.027 in this example - indicates what fraction of charge should be ignored when checking to see if the pixel is above the split threshold.

By default, the algorithm ignores 2.7% of the charge in the central pixels. This value comes from empirical data taken at the focal plane temperature of -110C. Those experiments have shown very little impact of trail parameter on the particle rejection efficiency. This is likely due to the fact that the CTI coefficient only affects testing of 1 or 2 of the 16 border pixels. Even if the value is far off, the rejection efficiency is degraded by 10% at most - that is, you reject 18% (instead of 20%) of the particles.

Elimination of Real Events

This caveat applies to both imaging and grating observations: in bright sources some percentage of real X-ray events are marked as potential background events. This can lead to true source events getting incorrectly flagged and result in an increase in statistical noise and lower the measured source flux.

To see if this is a problem in your data, create a file of the photons rejected by the check_vf_pha screening in acis_process_events. Here the filter is defined with status bit 23 marked as "bad" (1) and all other bits may be good or bad (x); note that the bits are counted from the right, starting at zero. This filter retains those events that have been flagged on account of the 5x5 screening:

unix% dmcopy "cleaned_evt1.fits[EVENTS][status=xxxxxxxx1xxxxxxxxxxxxxxxxxxxxxxx]" \
      acis_884_23bad.fits     

The image shows the reprocessed event file with background cleaning appled (left) and the events that were flagged as background (right). There are some source photons identified as background particles by acis_process_events; this is evident because the photons are clumped around the source location. In this case, you may decide to keep the photons (i.e. reprocess the file again with VFAINT background-cleaning turned off).

If the rejected photons are uniform across the field, then it is safe to filter out those events. There are more examples of this comparison on the Reducing ACIS Quiescent Background Using Very Faint Mode page.

Caveat: Running destreak to Remove Streak Events

When the background cleaning has been applied, the destreak tool will not be as efficient at detecting (and removing) streak events because of the large number of nonzero status bits set by the background-cleaning algorithm.

Running destreak with a custom mask setting ignores the status bit set by background cleaning (bit 23):

mask="[status=00000000x00000000000000000000000,grade=0,2:4,6]"

Even those events that have been flagged as background will be evaluated as possible streak events. This step is included in the chandra_repro script and in the Reprocessing Data to Create a New Level=2 Event File thread.