Bugs: specextract

A list of bugs fixed in CIAO 3.4 is available.

Caveats

1. The older ACIS "blank-sky" background files in the CALDB do not work correctly when input to this script "as-is". (16 May 2007)

2. Extraction regions near ACIS chip edges

3. Creating unbinned PHA spectra (01 Dec 2006)

Bugs

1. Calibration necessary for the script to choose mkacisrmf instead of mkrmf

Caveats

1. The older ACIS "blank-sky" background files in the CALDB do not work correctly when input to this script "as-is". (16 May 2007)

   This issue should be eliminated with the new ACIS blank-sky background files released in CALDB 3.4.0 (16 May 2007).

   Users will see a warning of this form:

   # mkwarf (CIAO 3.4): WARNING: No files found matching CALDB search: 
           tel=CHANDRA
           inst=ACIS
           det=-
           filt=-
           product=FEF_PI
           start_date=1998-01-01T00:00:00
           start_time=00:00:00
           stop_date=1998-01-06T18:53:20
           stop_time=18:53:20
           query=CTI_CORR.eq.NO
   
   # mkwarf (CIAO 3.4): WARNING: No files found matching CALDB search: 
           tel=CHANDRA
           inst=ACIS
           det=-
           filt=-
           product=FEF_PHA
           start_date=1998-01-01T00:00:00
           start_time=00:00:00
           stop_date=1998-01-06T18:53:20
           stop_time=18:53:20
           query=CTI_CORR.eq.NO
   

   The problem occurs because the older background files have junk TSTART and TSTOP header keywords:

   unix% dmkeypar acisiD2000-12-01bkgrndN0001.fits TSTART echo+
   0.0
   unix% dmkeypar acisiD2000-12-01bkgrndN0001.fits TSTOP echo+
   500000.0
   

   This is a result of how the files used to be constructed. The TSTART and TSTOP of this file put the observation in 1998, which is before Chandra launched. The start and stop date are given in the warning messages: start_date=1998-01-01T00:00:00 and stop_date=1998-01-06T18:53:20.

   Note that the newer files have valid TSTART and TSTOP header keyword values, and will therefore work with specextract right out of the CALDB:

   unix% dmkeypar acisiD2000-01-29bkgrndN0002.fits  TSTART echo+
   67670000.0
   
   unix% dmkeypar acisiD2000-01-29bkgrndN0002.fits TSTOP echo+
   68120000.0
   

   Workaround:

   In order to use the older files, it is necessary to edit the header to have sensible time keyword values. Our recommendation is that you change TSTART to match the value in the event file that you are using. Then add the EXPOSURE from the background file to determine a TSTOP value. You will also need to update the GTI extension of the background file with the new times.

   Here is an example of the process:

   1. Calculate the new TSTART and TSTOP

      unix% dmkeypar acis_evt2.fits TSTART echo+
      84280645.818566
      

      So we will use 84280650 as the start time (it doesn't need to match the event file exactly).

      unix% dmkeypar acisiD2000-12-01bkgrndN0001.fits EXPOSURE echo+
      500000.0
      

      Add the exposure time to the start time to get TSTOP: 84780650 .

   2. Edit the background file header

      Make a local copy of the relevant background file and add "write" permission. Then update the header values:

      unix% dmhedit infile=acisiD2000-12-01bkgrndN0001.fits filelist="" \
            operation=add key=TSTART value=84280650
      
      unix% dmhedit infile=acisiD2000-12-01bkgrndN0001.fits filelist="" \
            operation=add key=TSTOP value=84780650
      - WARNING: TSTART and TSTOP do not match GTIs in acisiD2000-12-01bkgrndN0001.fits[EVENTS]
      - TSTART:TSTOP =        84280650.0000:         500000.0000
      - GTIs         =               0.0000:         500000.0000
      

   3. Update the GTI block

      As indicated by the warning, we also need to change the GTI block of the background file.

      The CALDB version looks like

      unix% dmlist acisiD2000-12-01bkgrndN0001.fits"[GTI]" data
       
      ----------------------------------------------------------
      Data for Table Block GTI
      ----------------------------------------------------------
       
      ROW    start                stop
       
           1                    0             500000.0
      

      To edit the extension, use the cell-editing capability of Prism, described in the Cell Editing section of the Introduction to Prism thread, or any FITS file editing technique that you like. Afterwards, the file should look like

      unix% dmlist acisiD2000-12-01bkgrndN0001.fits"[GTI]" data
       
      ----------------------------------------------------------
      Data for Table Block GTI
      ----------------------------------------------------------
       
      ROW    start                stop
       
           1           84280650.0           84780650.0
      

   specextract should now run on the edited background file without problems.

2. Extraction regions near ACIS chip edges

   The mkwarf tool, which is used by specextract, is designed to represent the weighted ARF over a large region. If the exposure varies strongly over most of the extraction region, then the ARF may not fully account for this variation. This is mainly of concern for regions at the edge of an ACIS chip.

3. Creating unbinned PHA spectra (01 Dec 2006)

   The default PHA binning used by dmextract, one of the tools called by specextract, is "1:4096:2"; refer to the defaults parameter in ahelp dmextract for more information. If you intend to finish your analysis in XSpec, you must set "channel=1:4096:2", so that the spectrum and RMF have the same binning. Sherpa does not require that the spectrum and response be binned the same.

   If you want an unbinned PHA spectrum (e.g. 1:4096:1), you will have to run dmextract independently of specextract. Setting "channel=1:4096:1" in specextract will produce an RMF and ARF appropriate for use with the unbinned PHA spectrum.

Bugs

1. Calibration necessary for the script to choose mkacisrmf instead of mkrmf

   When determining whether to use mkrmf or mkacisrmf, the script does a CALDB lookup to compare the calibration applied to the event file and the most recent file available in the CALDB. This means that the data needs to have been processed with very newest calibration, not just a "good enough" version; that is, even if the new calibration will have a minimal effect on your data, specextract requires that it be applied for the "use mkacisrmf" switch to be triggered.

   Users who don't wish to reprocess can still use specextract, but run mkacisrmf afterwards to create new RMF files.

Bugs fixed in CIAO 3.4

The following is a list of bugs that were fixed in the CIAO 3.4 software release.

1. specextract currently does not check for the existence of the input files before beginning the processing.

   To avoid the script failing halfway through, be sure that the input filenames and paths are correct before running. Note that if the script does fail, any output files already written out are complete and may be used in the analysis.