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. # mkwarf (CIAO 3.4): ERROR: Could not map response region to FEF region (21 Dec 2006)

Bugs

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

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 3.4): WARNING: Found "pixlib" library parameters
      
      # dmhistory (CIAO 3.4): 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. # mkwarf (CIAO 3.4): ERROR: Could not map response region to FEF region (21 Dec 2006)

   This error arises from a mkwarf change in CIAO 3.4: using single pixel resolution when evaluating the WMAP. It is generally a problem when the source is at the edge of a chip or if you are using the entire chip area in creating the WARF.

   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.

   Workarounds:

   1. The recommendation is to supply the aspect solution in the mkwarf asolfile parameter. The aspect shifts the coordinate transform back to where the pixels all map to good chip coordinates.

   2. If supplying the aspect solution file does not resolve the problem (or if this is not an option, e.g. running specextract), try increasing the resolution of the WMAP. For example, use det=4 instead of the usual det=8.

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.