Bugs: mkwarf

Caveats

1. The energy grid of the ARF and RMF files must be the same for use in XSpec. (25 Aug 2006)

2. ERROR: Max egridspec energy=10 above max FEF energy=9.886

3. Extraction regions near ACIS chip edges

4. ARF over bad columns and node boundaries (12 Dec 2007)

Bugs

1. Issue with the WMAP when the source is at a chip edge

2. Failure on 0th order grating source (15 May 2008)

3. # mkwarf (CIAO 4.0): ERROR: Could not map response region to FEF region (04 Jun 2008)

Caveats

1. The energy grid of the ARF and RMF files must be the same for use in XSpec. (25 Aug 2006)

   Sherpa allows you to use different energy grids for your ARF and RMF files, but XSpec does not. Note that XSpec will still run if the grids do not match, but it issues a warning and sets all values in the ARF to unity (1).

   There are two approaches to creating an ARF-RMF pair with the same gridding.

   1. Create the RMF first

      Since mkacisrmf can change the requested grid to match the calibration data, create the RMF first and then use it to define the energy grid when creating the ARF. This will work for both mkarf and mkwarf:

      unix% pset mkarf \
            engrid="grid(sources_ciao.wrmf[cols ENERG_LO,ENERG_HI])"
      
      or
      
      unix% pset mkwarf \
            egridspec="grid(sources_ciao.wrmf[cols ENERG_LO,ENERG_HI])"
      

   2. Match an existing ARF

      If the specextract, psextract or acisspec scripts were used, you already have an ARF file for the data. Rather than remake both the RMF and ARF, get the grid information from the history in the ARF file:

      unix% dmhistory acis_src1.warf tool=all
      # dmhistory (CIAO 4.0): WARNING: Found "pixlib" library parameters
      
      # dmhistory (CIAO 4.0): WARNING: Found "ardlib" library parameters
      
      mkwarf infile="acis_src1.[WMAP]" outfile="acis_src1.warf" weightfile="acis_src1.wfef" 
      spectrumfile="" egridspec="0.3:9.5:0.01" threshold="0" feffile="CALDB" 
      mskfile="" mirror="HRMA" detsubsysmod="" ardlibpar="ardlib" geompar="geom" 
      clobber="no" verbose="2"  
      

      Your file may have been created with mkarf instead of mkwarf; the dmhistory tool=all will show the tool used in either case.

      Use the egridspec value (or engrid in the mkarf case) as input for the energy parameter in mkacisrmf:

      unix% pset mkacisrmf energy="0.3:9.5:0.01"
      

   The mkacisrmf analysis thread has information on creating the RMF file.

2. ERROR: Max egridspec energy=10 above max FEF energy=9.886

   mkwarf is required to compute and write a "weightfile" output file which contains FEF regions for use by mkrmf. If the energy range in the input RMF is greater than that in the FEF files, you get an error like:

   ERROR: Max egridspec energy=10 above max FEF energy=9.886
   

   Although the comparison to the FEF files is unnecessary in this case, there is currently no way to turn it off (e.g. set the weightfile to "NONE").

   Workaround:

   In order to avoid the error, it is necessary to define an energy range for mkacisrmf that falls within the boundaries of the FEF files, i.e. approximately 0.28 - 9.8 keV. See the Creating an RMF to match an extracted spectrum section of the mkacisrmf analysis thread for an example command.

3. Extraction regions near ACIS chip edges

   The mkwarf tool 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.

4. ARF over bad columns and node boundaries (12 Dec 2007)

   The combination of the TDET and single pixel changes in CIAO 4.0 causes mkwarf to skip bad pixels. This is a problem if the observation is over a bad column or node boundary, in which case the ARF is significantly over-estimated.

Bugs

1. Issue with the WMAP when the source is at a chip edge

   If the observation has large dy & dz offsets in the aspect solution file and they are quite variable during the observation, the tool will fail with a CALDB error. The large (and varying) offsets cause the mapping from DET to CHIP coordinates to fail and the tool cannot determine which response calibration file to use in creating the RMF.

2. Failure on 0th order grating source (15 May 2008)

   When operating on grating data, mkwarf accesses the grating efficiency information once for every non-zero pixel in the WMAP file. This creates a huge number of header records; if the number of records reaches 1e6, the tool crashes.

   Workaround:

   Create a smaller WMAP by increasing the binning factor, e.g. [bin det=16] instead of [bin det=8].

3. # mkwarf (CIAO 4.0): ERROR: Could not map response region to FEF region (04 Jun 2008)

   This issue is often related to a mkwarf change in CIAO 3.4: using single pixel resolution when evaluating the wmap. The edge of the wmap (in detector coordinates) ends up getting mapped to chip coordinates at 1024.5 which is rounded to 1025. It then tries to find the FEF region that converts chipy=1025 (for which there are none) and thus fails.

   Workaround:

   Supply the aspect solution in the asolfile parameter when running mkwarf. The aspect shifts the coordinate transform back to where the pixels all map to good chip coordinates.