Skip to the navigation links
Last modified: 27 Oct 2010
Where are the PDFs?

Reprocessing Data to Create a New Level=2 Event File

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:

[New] 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:




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

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.

Proceed to the next section.



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:

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:

  1. 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
    
  2. 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:

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:

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:

  1. 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
    
  2. 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:

  1. 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
    
  2. 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:

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

Return to Threads Page: Top | All | Data Prep

Where are the PDFs?
Last modified: 27 Oct 2010