Reprocessing Data to Create a New Level=2 Event File
![[CXC Logo]](../../imgs/cxc-logo.gif)
CIAO 4.2 Science Threads
Overview
Last Update: 27 Oct 2010 - added information on DS 8.3.3 in "do I have to run this thread?" section
Synopsis:
A reprocessing script for ACIS and HRC imaging
data: the chandra_repro script runs the data
processing steps in this thread for ACIS imaging data. To use the
reprocessing script, install the contrib
tarfile. Refer to "ahelp
chandra_repro" for more information.
The structure of this thread is presented as a series of questions and answers, the latter of which are links that take you further down the analysis tree. Following this thread from the top down will not produce correct results.
Purpose:
To generate a new level=2 event file (evt2.fits) for all possible grating/detector combinations. This thread may be run on any Chandra observation.
Read the "do I have to run this thread?" section to see what software versions should be reprocessed and to learn how to check the software version used in processing your data.
Related Links:
- Analysis Guide: ACIS Data Preparation
- Analysis Guide: HRC Data Preparation
Contents
Do I have to run this thread?
To find the software version that was used on the data, check the ASCDSVER keyword in the header:
unix% dmkeypar acis_evt1.fits ASCDSVER echo+ 6.5.1
-
If the ASCDSVER is DS 8.3.3 or higher: stop and think before you run this thread. The calibration applied in standard data processing is newer than the calibration available in CIAO 4.2; reprocessing will apply older calibration files. (CIAO 4.3 will have access to the same calibration files that are being used in the pipeline.)
-
If the ASCDSVER is lower than DS 7.6.7: yes, you definitely have to run this thread. Or you may run the chandra_repro script to reprocess your data with the newest calibration.
Note that the version numbering changed after version R4CU5UPD14 to the "DS" system, starting with DS 6.0.0. Any versions that start with R4 are very old.
-
If the ASCDSVER is DS 7.6.7 or higher: you may not have to run this thread. Reprocessing III started with DS 7.6.7. Read the "exceptions to the version check" section or simply run the chandra_repro script to reprocess your data and be confident it has the newest calibration applied.
Exceptions to the version check
A number of new calibrations have been released since Repro III began. Even if your data was processed with DS 7.6.7 or higher, you need to run this thread if you want to apply any of the following changes:
- Newest ACIS TGAIN calibration for -120 C data
- ACIS TGAIN calibration for -110 C data
- ACIS CTI calibration for ACIS-S1 and S3
- HRC-S TGAIN calibration
- HRC-I TGAIN calibration
- Newest ACIS TGAIN calibration for -120 C data
-
The ACIS time-dependent gain (TGAIN) calibration files for -120 C focal plane temperature are frequently updated in the calibration database (CALDB). If your data were taken recently - even if the ASCDSVER is DS 7.6.7 or higher - newer TGAIN file may be available for your dataset.
The Improvements in Calibration section of the TGAIN why topic lists the updates by date and CALDB version. The observation date and focal plane temperature are recorded in the header of the event file:
unix% dmkeypar acis_evt1.fits DATE-OBS echo+ 2008-01-19T20:41:39 unix% dmkeypar acis_evt1.fits FP_TEMP echo+ 153.60722351
If there is a new TGAIN calibration for your data, run this thread to apply the new calibration.
- ACIS TGAIN calibration for -110 C data
-
ACIS time-dependent gain (TGAIN) calibration files for -110 C focal plane temperature were released in CALDB 3.4.3 (31 March 2008).
This calibration applies only to -110 C data taken on the back-illuminated chips S1 (ACIS-5) or S3 (ACIS-7). Note that there is not a CTI correction available for this data, only TGAIN.
The focal plane temperature and detector name are recorded in the header of the event file:
unix% dmkeypar acis_evt1.fits FP_TEMP echo+ 163.952042 unix% dmkeypar acis_evt1.fits DETNAM echo+ ACIS-456789
Run this thread to apply the TGAIN correction to chips S1 and S3. The remaining front-illuminated (FI) chips in the file will be reprocessed as usual during the run.
- ACIS CTI calibration for ACIS-S1 and S3
-
The CTI calibration (both parallel and serial) for the back-illuminated chips (ACIS-S1, S3) was released in CALDB v3.3.0 (18 December 2006). The majority of Repro III was already done by December 2006, so this calibration was not applied to all data.
This calibration applies to -120 C data taken on the back-illuminated chips S1 (ACIS-5) or S3 (ACIS-7).
The focal plane temperature, detector name, and CALDB version are recorded in the header of the event file:
unix% dmkeypar acis_evt1.fits FP_TEMP echo+ 153.952042 unix% dmkeypar acis_evt1.fits DETNAM echo+ ACIS-456789 unix% dmkeypar acis_evt1.fits CALDBVER echo+ 3.2.1
For this file, S1 and S3 were used during the observation, but the CALDB version is lower than CALDB 3.3.0. Run this thread to apply the CTI correction to chips S1 and S3.
- HRC-S TGAIN calibration
-
A time-dependent gain map for HRC-S data was released in CALDB 4.2.0 (15 December 2009). The HRC-S gain is now roughly half what it was at the beginning of the mission. This gain map must be applied if users wish to use the HRC-S/LETG pulse-height filter that was also released in CALDB 4.2.0.
These calibrations updates were added to SDP at version DS 8.3.
The gain map and pulse-height filter were previously available as the "ADDSPI and SPIFILTER" contributed software.
- HRC-I TGAIN calibration
-
A time-dependent gain map for HRC-I data was released in CALDB 4.2.0 (15 December 2009). These new gain maps are based on the scaled sums of the three nearest amplifier signals to the event location, which results a more accurate gain correction.
Proceed to the next section to begin.
Get Started
Since this thread is meant to represent the most generic case, it is not written with a specific ObsID. Files are referred to by the detector and type - acisf01843_000N001_evt1.fits becomes acis_evt1.fits, hrcf01557_000N001_std_flt1.fits becomes hrc_std_flt1.fits, and so on.
Furthermore, it is assumed that all relevant files are in the same working directory.
ACIS or HRC?
Question 1: which detector was used for your observation? (It does not matter yet whether or not a transmission grating was also used.)
ACIS Observations
Running acis_process_events produces a new level=1 event file that has the latest calibration applied:
- the latest charge transfer inefficiency (CTI) correction
- the latest time-dependent gain adjustment
- the latest gain map
- a new bad pixel file
- PHA randomization
- pixel randomization
- background cleaning for very-faint mode data
- continuous clocking mode times of arrival (be sure to read the data caveats)
Determine the eventdef
The eventdef parameter specifies the names and data types of the columns in the output event data file. Four definitions are included in the parameter file for acis_process_events:
READMODE | DATAMODE | event mode | eventdef string |
---|---|---|---|
TIMED | (V)FAINT | timed exposure (very) faint | stdlev1 |
TIMED | GRADED | timed exposure graded | grdlev1 |
CONTINUOUS | CC(33)_FAINT | continuous clocking (3x3) faint | cclev1 |
CONTINUOUS | CC(33)_GRADED | continuous clocking (3x3) graded | ccgrdlev1 |
The event mode of an observation can be found in the READMODE and DATAMODE values stored in the file header:
unix% dmkeypar acis_evt1.fits READMODE echo+ TIMED unix% dmkeypar acis_evt1.fits DATAMODE echo+ FAINT
This is a timed exposure faint observation, so the proper eventdef parameter is "stdlev1."
Set the parameters
-
If you created a new bad pixel file by running the New ACIS Bad Pixel File: Identify ACIS Hot Pixels and Cosmic Ray Afterglows thread or the Customizing an ACIS Bad Pixel File thread, use that file in this analysis. Otherwise, use the bpix1.fits file from the Archive.
The "[cols -status]" filter on the infile filename ensures that the status bits in the output are recalculated from the bad pixel file.
-
In many cases, there will be more than one aspect solution file (pcad_asol1.fits) for an observation. All the files must be input to the acaofffile parameter in chronological order; the time is in the filename, so "ls" lists them in order. The files may be provided as a comma-separated list or as a stack. Here a stack is used:
unix% cat pcad_asol1.lis pcadf063874624N002_asol1.fits pcadf063875522N002_asol1.fits pcadf063902942N002_asol1.fits
- The parameters for VFAINT background cleaning (check_vf_pha) and calculating the continuous clocking mode times of arrival (calc_cc_times) are set. The tool will ignore these parameters if your observation was not taken in either of those modes.
unix% punlearn acis_process_events unix% pset acis_process_events infile="acis_evt1.fits[cols -status]" unix% pset acis_process_events outfile=acis_new_evt1.fits unix% pset acis_process_events badpixfile=acis_new_bpix1.fits unix% pset acis_process_events acaofffile=@pcad_asol1.lis unix% pset acis_process_events eventdef=")stdlev1" unix% pset acis_process_events check_vf_pha=yes unix% pset acis_process_events calc_cc_times=yes
Run the tool
unix% acis_process_events Input event file or stack (acis_evt1.fits): Output event file name (acis_new_evt1.fits): aspect offset file ( NONE | none | <filename>) (pcad_asol1.fits):
A number of possible warning messages are explained in the Common acis_process_events Warnings section.
Question 2: is your observation imaging or grating data?
Imaging Observations
Remove Streak Events
Next is the option to run destreak on the ACIS-S4 chip (ccd_id=8), which can improve the quality of your data. For details on how the tool works, see the Destreaking ACIS Data why topic and "ahelp destreak".
A custom status bit filter is used in the mask parameter so that events flagged by the VFAINT background cleaning are also evaluated as possible streak events. (For non-VFAINT-mode data, this mask is the same as using the tool's default mask [status=0,grade=0,2:4,6].)
unix% punlearn destreak unix% pset destreak infile=acis_new_evt1.fits unix% pset destreak outfile=acis_dstrk_evt1.fits unix% pset destreak mask="[status=00000000x00000000000000000000000,grade=0,2:4,6]" unix% destreak Input dataset/block specification (acis_evt2.fits): Output dataset/block specification (acis_dstrk_evt2.fits):
Filter on Grade, Status, and Good Time
There are two filtering steps for ACIS imaging observations:
-
Filter for bad grades and for a "clean" status column (i.e. all bits set to 0):
unix% punlearn dmcopy unix% dmcopy "acis_dstrk_evt1.fits[EVENTS][grade=0,2,3,4,6,status=0]" \ acis_flt_evt1.fits
-
The Good Time Intervals (GTIs) supplied by the pipeline now need to be applied; these are stored in the acis_flt1.fits file. Simultaneously, unnecessary columns are eliminated from the output:
unix% punlearn dmcopy unix% dmcopy "acis_flt_evt1.fits[EVENTS][@acis_flt1.fits][cols -phas]" \ acis_repro_evt2.fits
Be sure to include the @ symbol in the filter expression; the command will not be executed properly if it is omitted.
The thread is now complete. acis_repro_evt2.fits is a level=2 event file with the latest calibration products applied.
Grating Observations
There are CIAO threads that deal specifically with generating a level=2 event file for an ACIS grating observation. Follow the appropriate one, depending on which transmission grating was used:
Single source:
Multiple sources:
- Grating Spectra for Multiple Sources - ACIS (applies to both HETG and LETG)
Once you leave this thread, you do not need to return to complete any further steps.
Common acis_process_events Warnings
It is important to remember that the following messages are warnings, not errors. The tool may print one of these messages, but will still create a valid event file.
- WARNING: problem reading ctifile, cti adjustment will not be applied.
-
# acis_process_events (CIAO 4.2): WARNING: problem reading ctifile, cti adjustment will not be applied. Changing apply_cti=yes to apply_cti=no.
This warning may also be triggered by product=T_GAIN.
The most common cause for seeing this warning is that the observation does not contain -120C data. Since the CTI and TGAIN is only calibrated for this focal place temperature, it is not possible to use it on other observations.
Since no file is found, acis_process_events continues running as if apply_cti=no or apply_tgain=no and produces a valid output file that has not been CTI-corrected or had the TGAIN applied.
- The CTI correction cannot be performed on a graded mode event list.
-
# acis_process_events (CIAO 4.2): WARNING: The CTI correction cannot be performed on a graded mode event list. # acis_process_events (CIAO 4.2): WARNING: Although the keyword TGAINCOR is false or missing, the column PHA_RO exists. The values in this column are assumed to be the unadjusted pulse height values.
The CTI correction requires that a PHAS column exist in the input file. This column is not created for observations taken with the data mode GRADED, so this warning is produced.
In this case, acis_process_events continues to reprocess the data as if apply_cti=no and produces a valid output file that has not been CTI-corrected.
- The parameter check_vf_pha=yes, but the DATAMODE key does not indicate a very-faint mode observation.
-
# acis_process_events (CIAO 4.2): WARNING: The parameter check_vf_pha=yes, but the DATAMODE key does not indicate a very-faint mode observation. Changing to check_vf_pha=no.
ACIS very-faint background cleaning can only be performed on observations that were taken in VFAINT mode. If the check_vf_pha parameter is set to "yes" but the data has a DATAMODE other than VFAINT, acis_process_events continues to reprocess the data as if check_vf_pha=no and produces a valid output file that does not have the background cleaning applied.
HRC Observations
Running hrc_process_events produces a new level=1 event file that has the latest calibration applied:
- the new time-dependent gain correction (available for both HRC-S and HRC-I)
- AMP_SF correction
- degap correction
Determine the "instrume" parameter
The instrume parameter, which specifies the instrument with which the data was collected, first needs to be determined:
unix% dmkeypar hrc_A_evt1.fits detnam echo+ HRC-I unix% dmkeypar hrc_B_evt1.fits detnam echo+ HRC-S
The instrume value is hrc-i for file A and hrc-s for file B.
Determine the RANGELEV value
The header keyword RANGELEV must be present in order to apply the AMP_SF correction:
unix% dmkeypar hrc_evt1.fits RANGELEV echo+ # dmkeypar (CIAO 4.2): ERROR: Keyword 'RANGELEV' was not found in file 'hrc_evt1.fits'.
In this case, it is necessary to add the keyword; the value is determined by the DATE-OBS keyword:
unix% dmkeypar hrc_evt1.fits DATE-OBS echo+ 2001-03-09T03:02:44
Now choose the appropriate RANGELEV value from this table:
DATE-OBS | Detector | RANGELEV value |
before 1999-12-6 | HRC-I & HRC-S | 90 |
after 1999-12-6 | HRC-I | 115 |
after 1999-12-6 | HRC-S | 125 |
and add it to the header:
unix% dmhedit infile=hrc_evt1.fits filelist=none operation=add key=RANGELEV value=<value>
Set the parameters
-
In many cases, there will be more than one aspect solution file (pcad_asol1.fits) for an observation. All the files must be input to the acaofffile parameter in chronological order; the time is in the filename, so "ls" lists them in order. The files may be provided as a comma-separated list or as a stack. Here a stack is used:
unix% cat pcad_asol1.lis pcadf062419415N003_asol1.fits pcadf062461940N003_asol1.fits pcadf062492182N003_asol1.fits
-
Set the instrume parameter (here, hrc-s) to the correct value for the dataset.
unix% punlearn hrc_process_events unix% pset hrc_process_events infile=hrc_evt1.fits unix% pset hrc_process_events outfile=hrc_new_evt1.fits unix% pset hrc_process_events badpixfile=hrc_bpix1.fits unix% pset hrc_process_events acaofffile=@pcad_asol1.lis unix% pset hrc_process_events badfile=NONE unix% pset hrc_process_events instrume=hrc-s unix% pset hrc_process_events do_amp_sf_cor=yes
Run the tool
unix% hrc_process_events input level 0 event file/stack (hrc_evt1.fits): output level 1 file (hrc_new_evt1.fits): bad pixel file ( NONE | none | <filename>) (hrc_bpix1.fits):
A number of possible warning messages are explained in the Common hrc_process_events Warnings section.
Question 2: is your observation HRC-S imaging, HRC-I imaging, or grating data?
HRC-S Imaging Observations
There are two filtering steps for HRC-S imaging observations:
-
Apply the status filter that is specific to HRC-S observations; a value of 0 demands that the bit be flagged as "good", a value of x indicates that either status (0/1) is acceptable. The PI filter removes about 20% of the background with no X-ray losses:
unix% punlearn dmcopy unix% dmcopy \ "hrc_new_evt1.fits[pi=0:300,status=xxxxxx00xxxx0xxx0000x000x00000xx]" \ hrc_flt_evt1.fits
-
The Good Time Intervals (GTIs) supplied by the pipeline now need to be applied; these are stored in the hrc_std_flt1.fits file. Simultaneously, unnecessary columns are eliminated from the output:
unix% punlearn dmcopy unix% dmcopy \ "hrc_flt_evt1.fits[EVENTS][@hrc_std_flt1.fits][cols -crsu,-crsv,-amp_sf,-av1,-av2,-av3,-au1,-au2,-au3,-raw,-sumamps]" \ hrc_repro_evt2.fits
Be sure to include the @ symbol in the filter expression; the command will not be executed properly if it is omitted.
Computing Average HRC Dead Time Corrections
The average HRC deadtime correction is computed using the tool hrc_dtfstats to ensure the accuracy of the deadtime statistics. (The deadtime should be recomputed after any time filtering is applied to an HRC dataset, e.g. applying GTIs or filtering background flares.)
unix% punlearn hrc_dtfstats unix% pset hrc_dtfstats infile=hrc_dtf1.fits unix% pset hrc_dtfstats outfile=hrc_dtfstats_new.fits unix% pset hrc_dtfstats gtifile=hrc_repro_evt2.fits"[gti]" unix% hrc_dtfstats Input file (hrc_dtf1.fits): Output file (hrc_dtfstats_new.fits): File containing GTI to filter on (<filename>|NONE) (hrc_repro_evt2.fits[gti]):
In this example, the new dtfstats file has a value of DTCOR=0.35535:
unix% dmlist hrc_dtfstats_new.fits"[cols DTCOR]" data,clean # DTCOR 0.35535140943668
The ONTIME header value is multiplied by the new DTCOR value, and the LIVETIME and EXPOSURE header keyword values are updated with dmhedit. The commands in general are:
unix% dmkeypar hrc_repro_evt2.fits ONTIME echo+ ONTIME * NEWDTCOR = NEWTIME unix% dmhedit hrc_repro_evt2.fits filelist="" op=add key=LIVETIME value=NEWTIME unix% dmhedit hrc_repro_evt2.fits filelist="" op=add key=EXPOSURE value=NEWTIME unix% dmhedit hrc_repro_evt2.fits filelist="" op=add key=DTCOR value=NEWDTCOR
The following commands use example values to illustrate:
unix% dmkeypar hrc_repro_evt2.fits ONTIME echo+ 2189.40009910 2189.40009910*0.35535140943668 = 778.00641103599186717498 unix% dmhedit hrc_repro_evt2.fits filelist="" op=add key=LIVETIME value=778.0064110 unix% dmhedit hrc_repro_evt2.fits filelist="" op=add key=EXPOSURE value=778.0064110 unix% dmhedit hrc_repro_evt2.fits filelist="" op=add key=DTCOR value=0.35535140943668
The thread is now complete; hrc_repro_evt2.fits is a level=2 event file with the latest calibration products applied.
HRC-I Imaging Observations
There are two filtering steps for HRC-I imaging observations:
-
Apply the status filter that is specific to HRC-I observations; a value of 0 demands that the bit be flagged as "good", a value of x indicates that either status (0/1) is acceptable:
unix% punlearn dmcopy unix% dmcopy \ "hrc_new_evt1.fits[status=xxxxxx00xxxx0xxx00000000x0000000]" \ hrc_flt_evt1.fits
-
The Good Time Intervals (GTIs) supplied by the pipeline now need to be applied; these are stored in the hrc_std_flt1.fits file. Simultaneously, unnecessary columns are eliminated from the output:
unix% punlearn dmcopy unix% dmcopy \ "hrc_flt_evt1.fits[EVENTS][@hrc_std_flt1.fits][cols -crsu,-crsv,-amp_sf,-av1,-av2,-av3,-au1,-au2,-au3,-raw,-sumamps]" \ hrc_repro_evt2.fits
Be sure to include the @ symbol in the filter expression; the command will not be executed properly if it is omitted.
Computing Average HRC Dead Time Corrections
The average HRC deadtime correction is computed using the tool hrc_dtfstats to ensure the accuracy of the deadtime statistics. (The deadtime should be recomputed after any time filtering is applied to an HRC dataset, e.g. applying GTIs or filtering background flares.)
unix% punlearn hrc_dtfstats unix% pset hrc_dtfstats infile=hrc_dtf1.fits unix% pset hrc_dtfstats outfile=hrc_dtfstats_new.fits unix% pset hrc_dtfstats gtifile=hrc_repro_evt2.fits"[gti]" unix% hrc_dtfstats Input file (hrc_dtf1.fits): Output file (hrc_dtfstats_new.fits): File containing GTI to filter on (<filename>|NONE) (hrc_repro_evt2.fits[gti]):
In this example, the new dtfstats file has a value of DTCOR=0.35535:
unix% dmlist hrc_dtfstats_new.fits"[cols DTCOR]" data,clean # DTCOR 0.35535140943668
The ONTIME header value is multiplied by the new DTCOR value, and the LIVETIME and EXPOSURE header keyword values are updated with dmhedit. The commands in general are:
unix% dmkeypar hrc_repro_evt2.fits ONTIME echo+ ONTIME * NEWDTCOR = NEWTIME unix% dmhedit hrc_repro_evt2.fits filelist="" op=add key=LIVETIME value=NEWTIME unix% dmhedit hrc_repro_evt2.fits filelist="" op=add key=EXPOSURE value=NEWTIME unix% dmhedit hrc_repro_evt2.fits filelist="" op=add key=DTCOR value=NEWDTCOR
The following commands use example values to illustrate:
unix% dmkeypar hrc_repro_evt2.fits ONTIME echo+ 2189.40009910 2189.40009910*0.35535140943668 = 778.00641103599186717498 unix% dmhedit hrc_repro_evt2.fits filelist="" op=add key=LIVETIME value=778.0064110 unix% dmhedit hrc_repro_evt2.fits filelist="" op=add key=EXPOSURE value=778.0064110 unix% dmhedit hrc_repro_evt2.fits filelist="" op=add key=DTCOR value=0.35535140943668
The thread is now complete; hrc_repro_evt2.fits is a level=2 event file with the latest calibration products applied.
Grating Observations
There are CIAO threads that deal specifically with generating a level=2 event file for an HRC grating observation. Follow the appropriate one, depending on which detector was used:
Single source:
Multiple sources:
- Grating Spectra for Multiple Sources - HRC (applies to both HRC-S and HRC-I)
Once you leave this thread, you do not need to return to complete any further steps.
Common hrc_process_events Warnings
It is important to remember that the following messages are warnings, not errors. The tool may print one of these messages, but will still create a valid event file.
- mjd_obs keyword is missing in infile. value from computation.
-
# hrc_process_events (CIAO 4.2): WARNING: mjd_obs keyword is missing in infile. value from computation.
Some older event files do not have the MJD_OBS header keyword. In this case, the tool uses the DATE-OBS and MJDREF values to compute the correct MJD_OBS.
- Out of sequence events discovered in hrc_evt1.fits.
-
# hrc_process_events (CIAO 4.2): The following error occurred 2482 times: dsHPEEVENTSEQERR - WARNING: Out of sequence events discovered in hrc_evt1.fits.
There are occasional events that appear in the telemetry stream with time tags that make them seem to have occurred out-of-sequence. One special case where this occurs has been documented (see the Out-of-sequence HRC Time Tags memo); other occurrences are most likely to be caused by hiccups in the HRC or by double-bit errors in telemetry (single-bit errors are corrected).
This warning may be ignored in most cases, as long as the number of events flagged as out-of-sequence is a small fraction of the total number of events in the file; see this FAQ for more information.
History
22 Dec 2004 | updated for CIAO 3.2: minor changes to parameter files; use ACIS bad pixel file (badpixfile parameter) |
12 Jan 2005 | grating sections now include links to multiple-source analysis threads |
01 Feb 2005 | added note about "Event island contains 1 or more bad pixels" warning to acis_process_events section |
20 Jun 2005 | CIAO 3.2.2 patch: minor acis_process_events parameter change (default value of threshfile is CALDB instead of NONE) |
12 Dec 2005 | updated for CIAO 3.3: the CTI and time-dependent gain corrections may be applied to CC-mode data (see the Continuous Clocking Mode why topic for details); parameter file updates for destreak |
01 Dec 2006 | updated for CIAO 3.4: CIAO version in errors and warnings |
08 Feb 2008 | updated for CIAO 4.0: links point to why topics and dictionary entries instead of other ACIS and HRC threads, which have been deprecated |
31 Mar 2008 | updated for CALDB 3.4.3: new -120 C TGAIN files and first -110 C TGAIN file: both changes made in Do I have to run this thread? section |
16 Jun 2008 | added CTI correction for back-illuminated chips to Do I have to run this thread? section |
07 Jan 2009 | updated for CIAO 4.1: acis_process_events no longer prints the "Event island contains 1 or more bad pixels." warning when verbose=0; other warnings were updated |
18 Dec 2009 | updated for CIAO 4.2: new ACIS TGAIN, HRC-I TGAIN, and HRC-S TGAIN released in CALDB 4.2.0 |
28 Dec 2009 | additional updates for CIAO 4.2: HRC imaging - "pha=0:254" filter is replaced by "pi=0:300" |
20 Jan 2010 | linked to Customizing an ACIS Bad Pixel File thread; include "[cols -status]" when running acis_process_events |
18 Feb 2010 | added the MJD_OBS hrc_process_events warning |
01 Jul 2010 | the chandra_repro reprocessing script automates data processing for ACIS imaging data |
02 Sep 2010 | incorporated ACIS very-faint background cleaning into this thread; destreak mask parameter updated for VFAINT data |
27 Sep 2010 | added "Computing Average Dead Time Corrections" section for HRC data |
27 Oct 2010 | added information on DS 8.3.3 in "do I have to run this thread?" section |