Apply the ACIS CTI Correction

New CTI header keyword: CTI_APP

Prior to CIAO 3.4 and DS 7.6.10, the CTI_CORR header keyword was used to record whether the CTI correction had been applied to a dataset. The value of the keyword was a boolean: "TRUE" (or "1") if the CTI had been applied and "FALSE" (or "0") if it hadn't:

unix% dmkeypar acis_1838_evt2_yes.fits CTI_CORR echo+
1

unix% dmkeypar acis_1838_evt2_no.fits CTI_CORR echo+
0

The updates to CTI support in the CIAO 3.4 and DS 7.6.10 releases include a new, more descriptive header keyword, CTI_APP. The value of this keyword is a ten-character string which records the CTI applied to each of the ACIS chips (0-9, left to right). Allowed character values are:

• N: no CTI correction applied
• P: parallel CTI correction applied only (expected value for FI chips)
• S: serial CTI correction applied only (currently not a possible case)
• B: both serial and parallel CTI correction applied (expected value for BI chips)

Here are some examples:

• Standard CTI correction to FI and BI chips:

  unix% dmkeypar acis_evt2.fits CTI_APP echo+
  PPPPPBPBPP
  

• Only FI chips corrected for parallel CTI:

  unix% dmkeypar acis_evt2.fits CTI_APP echo+
  PPPPPNPNPP
  

• No CTI correction applied:

  unix% dmkeypar acis_evt2.fits CTI_APP echo+
  NNNNNNNNNN
  

Note that all ten spaces in the value are always populated, even though there are only a maximum of six chips on at a time.

The CTI_CORR keyword is retained in the output for backward-compatibility, but all CIAO tools have been updated to use the value of CTI_APP when checking for the CTI correction.

Related acis_process_events threads

There are other threads that should be considered, since they may affect how acis_process_events is run. The Create a New Level=2 Event File thread shows how to combine all of these options into a single run of acis_process_events.

• Apply the Time-Dependent ACIS Gain Correction
• Remove Pixel Randomization
• Apply/Remove PHA Randomization
• Clean ACIS Background in VFAINT Mode

Determine the eventdef parameter

The eventdef parameter specifies the names and data types of the columns in the output event data file. Two relevant predefined strings are included in the parameter file for acis_process_events:

As explained in How the Data is Affected, it is necessary for the PHAS column to exist in the input file. This column is not created for observations taken with the data mode GRADED, so this thread can only be run on FAINT or VFAINT mode data. If you are unsure of the event mode of your observation, the information can be found in the READMODE and DATAMODE values stored in the file header:

unix% dmkeypar acisf01838_000N001_evt1.fits READMODE echo+
TIMED

unix% dmkeypar acisf01838_000N001_evt1.fits DATAMODE echo+
FAINT

This is a timed exposure faint observation, so the proper eventdef parameter is "stdlev1." The full parameter syntax of each eventdef string may be found in plist acis_process_events.

If you are working with VFAINT mode data and wish to perform the background cleaning as well, make sure to read this caveat before continuing.

Optional Step: when the parameters to apply the CTI correction are set (see the next section), the values of the column PHAS are adjusted and saved in a column named PHAS_ADJ. If you are interested in the PHAS_ADJ column to be present in the output file, you must define a custom eventdef string which includes "f:phas_adj". For example, modifying the "stdlev1" string:

unix% pset acis_process_events eventdef="{d:time,s:ccd_id,s:node_id,i:expno,s:chip,s:tdet,f:det,f:sky,s:phas, f:phas_adj,l:pha,f:energy,l:pi,s:fltgrade,s:grade,x:status}"

The only effect of doing this is that the extra column will be written to the output. Otherwise all the calculations are done, then the column is omitted from the final event file. In the interest of reducing the output file size you can choose to not to keep the PHAS_ADJ column. In this thread, the unaltered "stdlev1" event definition is used.

Run acis_process_events

Running this tool with the SDP level=1 event file as the input will produce a new level=1 event file that has the latest CALDB applied. This means that the newest gain map will be picked up as well.

Since the event grades, energy, and PI values are all affected by the values in the PHAS column, they need to be recalculated using the PHAS_ADJ values; by default the doevtgrade and calculate_pi parameter values are set to "yes", so they do not need to be changed.

The apply_cti parameter indicates that the CTI correction will be applied. Note that the CTI correction is on by default (apply_cti=yes); the pset command is used for emphasis in this example:

unix% punlearn acis_process_events
unix% pset acis_process_events infile=acisf01838_000N001_evt1.fits
unix% pset acis_process_events outfile=acis_1838_new_evt1.fits
unix% pset acis_process_events badpixfile=acis_1838_new_bpix1.fits
unix% pset acis_process_events eventdef=")stdlev1"
unix% pset acis_process_events stop=none
unix% pset acis_process_events apply_cti=yes
unix% acis_process_events
Input event file or stack (acisf01838_000N001_evt1.fits): 
Output event file name (acis_1838_new_evt1.fits): 
aspect offset file ( NONE | none | <filename>) (NONE): 

It is important to note the unusual syntax of the eventdef parameter; the tool will not access the predefined string if the leading ")" is missing (see example 6 of ahelp parameter). If you are using a custom string to retain the PHAS_ADJ column, use the pset command given in the Determine the eventdef parameter section.

You may see a warning about the number of event islands that contain one or more bad pixels:

# acis_process_events (CIAO 3.4): The following error occurred 26941
  times: dsAFEBADPCNTERR -- WARNING: Event island contains 1 or more bad pixels.

It is explained in this FAQ and may be ignored.

The content of the parameter file may be checked using plist acis_process_events.

Apply grade/status filters

Filter for bad grades (using ASCA grades) and for a "clean" status column (ie all bits set to 0):

unix% punlearn dmcopy
unix% dmcopy "acis_1838_new_evt1.fits[EVENTS][grade=0,2,3,4,6,status=0]" \
      acis_1838_flt_evt1.fits

Apply GTI filters

The Good Time Intervals (GTIs) supplied by the pipeline now need to be applied. Simultaneously, an unnecessary column is eliminated from the output:

unix% punlearn dmcopy
unix% dmcopy "acis_1838_flt_evt1.fits[EVENTS][@acisf01838_000N001_flt1.fits][cols -phas]" \
      acis_1838_evt2.fits 

Be sure to include the @ symbol in the filter expression; the command will not be executed properly if it is omitted.

A common warning message

While running this thread, users may see the following warning:

# acis_process_events (CIAO 3.4): WARNING: No files found matching CALDB search:
        tel=CHANDRA
        inst=ACIS
        det=-
        filt=-
        product=CTI
        start_date=1999-08-20T00:07:44
        start_time=00:07:44
        stop_date=1999-08-20T02:26:38
        stop_time=02:26:38
        query=-
# acis_process_events (CIAO 3.4): WARNING: PROBLEM READING CTIFILE, CTI ADJUSTMENT WILL NOT BE APPLIED.

The most common cause for seeing this warning is that the observation does not contain -120C data. Since the CTI correction is only calibrated for this focal place temperature, it is not possible to use it on other observations. Note that this is not an error; if no CTI file is found, acis_process_events continues running as if apply_cti=no and produces a valid output file that has not been CTI-corrected.

Reapplying or removing the CTI correction

If the input file has already been CTI-corrected and "apply_cti=yes", the CTI correction is recalculated. It is not, however, applied on top of the first correction; since the PHAS column remains unadjusted, the new correction will start from there to redetermine the PHA, ENERGY and PI values.

If the input file has already been CTI-corrected and "apply_cti=no", the CTI correction is removed (PHA, ENERGY and PI values are recomputed using the original, pre-CTI-corrected data).

Frame times, subarrays, and CC mode

The CTI adjustment has been fully tested and calibrated on -120 C observations in TIMED mode with frame time of 3.2 s. The calibration group knows that the CTI process is slightly different in modes which have longer or shorter frame times, such as subarrays. This is because different amounts of cosmic ray and other background charge can partially fill traps. They expect that CTI-corrected data will still be an improvement, and will be as accurate as our calibration base allows at the present time. Please let us know (via Helpdesk) if you have evidence of specific discrepancies due to different frame times.

In CC mode there is also a change in parallel transfer rate; the rate for TE mode is 40 microsec/row, and for CC mode it's 2.8 millisec/row. Different traps become more or less important for the different transfer rates. There is very little calibration data in this mode, so it is suggested that CTI correction be compared with uncorrected data, and the results carefully considered for reasonableness.