Bugs: acis_process_events

Caveats

1. Aspect files must be arranged in chronological order

2. CONTENT keyword value is set to "EVT1" (14 Feb 2007)

Bugs

1. Status bits in the input file are not reset when reprocessing data

2. If acis_process_events is run with apply_cti=no, running the tool again will never apply the CTI correction. (07 Jul 2009)

Caveats

1. Aspect files must be arranged in chronological order

   acis_process_events assumes that the aspect files given in the acaofffile and alignmentfile parameters are arranged in chronological order. If the files are not in order, the tool will exit with an error.

   If you have not altered the original filenames, a simple "ls" will put them in order, as the time is listed in the filename:

   unix% pwd
   /data/459/primary
   
   unix% ls -1 pcad*
   pcadf063874624N002_asol1.fits
   pcadf063875522N002_asol1.fits
   pcadf063902942N002_asol1.fits
   

   Otherwise, get the value from the TSTART header keyword:

   unix% dmkeypar pcad_1.fits TSTART echo+
   63875522.3455031
   

   and put the files in chronological order.

2. CONTENT keyword value is set to "EVT1" (14 Feb 2007)

   acis_process_events always sets the CONTENT keyword in the output file to "EVT1", regardless of whether the input is an evt1.fits or evt2.fits file. (Note that there are only specific cases in which an evt2 file may be used as input to acis_process_events.)

   Workaround:

   While the CONTENT value will not negatively affect any analysis downstream, users can change the value with dmhedit if they so choose.

Bugs

1. Status bits in the input file are not reset when reprocessing data

   When acis_process_events is used to reprocess event data, it does not unset status bits in the input data file. For example, acis_process_events does not recalculate the bad pixel status bits. If events have status bits set in the input event file, then the values are always copied to the same bits in the column STATUS of the output file. If the badpixfile is set to a value other than "NONE" (the default), then only additional status bits can be set in the output file. This limitation will be fixed in a future release.

   The exception to this is the VFAINT background cleaning (status bit 23). As of CIAO 4.0, previously set VFAINT status bits are unset before the check is done again.

2. If acis_process_events is run with apply_cti=no, running the tool again will never apply the CTI correction. (07 Jul 2009)

   This problem was fixed in CALDB 4.1.3 (07 July 2009). Download CALDB 4.1.3

   After acis_process_events is run with apply_cti=no, the CTI_APP keyword is correctly set to NNNNNNNNNN.

   Due to a problem in how the CALDB files are looked up, running acis_process_events on this file again with apply_cti=yes does not apply the CTI correction. The CTI_APP keyword will still be set to NNNNNNNNNN.

   Workarounds:

   1. The easiest workaround is to delete the CTI_APP keyword before running acis_process_events the second time:

      unix% dmhedit acis_evt1.fits filelist="" op=del key=CTI_APP
      

   2. It is also possible to explicitly set the value of the ctifile parameter such that the CTI correction file is selected and applied.

      There are two options:

      • CTI_APP=PPPPPNPNPP - parallel CTI applied to front-illuminated chips, no corrected applied to back-illuminated chips

      • CTI_APP=PPPPPBPBPP - parallel CTI applied to front-illuminated chips, parallel and serial CTI applied to back-illuminated chips

      To set the parameter:

      unix% pset acis_process_events ctifile="CALDB(CTI_APP=PPPPPBPBPP)"