Bugs: mkacisrmf

Significant improvements to mkacisrmf were released in the CIAO 3.2.2 patch (23 June 2005); all users are strongly encouraged to upgrade to CIAO 3.2.2. A list of mkacisrmf bugs fixed in CIAO 3.2.2 is available at the end of the page; see the release notes for more information

Caveats

• mkacisrmf checks the energy bounds among the user's input grid, response file and gain file and then picks the output grid that fits all of them. Since the current calibration file does not extend below 0.243 keV, it is not possible for mkacisrmf to create an RMF with bounds lower than that energy.

• 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).

  Since mkacisrmf can change the requested grid so as to match the calibration data, the suggested method is to create the RMF first and then use it to define the energy grid when creating the ARF. This applies to both mkarf and mkwarf (the syntax is identical for both tools):

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

  If the psextract or acisspec scripts were used, it is necessary to re-run the mkarf/mkwarf step independently to create an ARF file with matching grid.

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

• 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.

Bugs

• If the WMAP file is empty (i.e. all values are zero), the tool will fail with messages of this form:

  # mkacisrmf (CIAO3.2): WARNING:  2 CALDB files found. Using the first
  
  # mkacisrmf (CIAO3.2): 
  ERROR: do not find extension related to 'RESP_TWEAK'.
  

• Case of the chantype parameter

  If the chantype parameter is given as lowercase in the parameter file (e.g. "pset mkacisrmf chantype=pi"), mkacisrmf retains the case in the CHANTYPE keyword, using "pi" rather than "PI". This works fine in Sherpa, but confuses XSpec.

  Workarounds:

  • always use uppercase when setting the chantype parameter:

    pset mkacisrmf chantype=PI
    

  • use dmhedit to change the header after the fact:

    unix% dmhedit infile=rmf.fits filelist='' operation=add key=CHANTYPE value=PI
    

mkacisrmf bugs fixed in CIAO 3.2.2

The following is a list of bugs that existed in CIAO 3.2 and 3.2.1, but have been fixed in the CIAO 3.2.2 software release. It is provided for those users who do not wish to upgrade their software at this time.

• SegV for ACIS-1 on node-1

  Making an rmf on ACIS-1 on node-1 (chipx=256:511) will result in the tool crashing. The cause is a bug that is triggered with the negative shift value combined with the starting channel in the calibration file.

  Even if the tool finishes successfully, the output may be corrupt. If you are working on ACIS-1, node 1, it is suggested that you run rmfimg on the output from mkacisrmf and visually inspect. If the RMF is corrupt, it would most likely be manifested as large-amplitude noise.

  Workaround: use mkrmf instead of mkacisrmf.

  The gain files for the Phase I RMFs (mkrmf) and Phase II RMFs (mkacisrmf) are different. So to be fully consistent, a user would need to reprocess the data for that chip with the correct gainfile; see the mkacisrmf why topic for more information. If the event data and the RMF have inconsistent gain files, the user should notice a systematic energy shift.

• Grid limitation

  If the user creates a PI matrix with a grid other than 1:1024:1 then they can run into problems (e.g. memory corruption or an error).

• Energy grid outside data bounds

  A warning that the requested energy grid is outside of the data bounds is only printed when verbose=5. This will be changed so that the warning is printed at lower verbosity levels as well.

Calibration problem fixed in CALDB 3.0.3

The following problem was fixed in CALDB 3.0.3, released on 9 May 2005; download the patch to obtain the updated calibration.

• Sorting errors in the mkacisrmf response CalDB file

  We have learned from the ACIS calibration team that a problem exists with several (21) regions of data in the scattering matrix for certain FI chips. The cells can be identified by the region number (REGNUM) in the CalDB file used by mkacisrmf (acisD2000-01-29p2_respN0002.fits, located in the $CALDB/data/chandra/acis/cpf/p2_resp/ directory). They are as follows:

  REGNUM	CCD_ID	chipx_lo	chipx_hi	chipy_lo	chipy_hi
  7	0	1		256		193		224
  18	0	1		256		545		576
  30	0	1		256		929		960
  39	0	257		512		193		224
  93	0	513		768		897		928
  144	1	1		256		481		512
  146	1	1		256		545		576
  221	1	513		768		897		928
  272	2	1		256		481		512
  274	2	1		256		545		576
  295	2	257             512             193             224
  349	2	513		768		897		928
  400	3	1		256		481		512
  402	3	1		256		545		576
  423	3	257             512             193             224
  477	3	513		768		897		928
  528	6	1		256		481		512
  530	6	1		256		545		576
  551	6	257             512             193             224
  573	6	257             512             897             928
  605	6	513		768		897		928
  

  In these 21 regions, the SC_MATRIX data (block 4 of the file) are not sorted properly by PHA (energy). The resulting RMF is incorrect, with values of zero over a large part of the bandpass. Used individually, such an RMF would produce obviously incorrect results. When used in a weighted average, however, the result is less obvious. In fact, it will reduce the amplitude of the forward-fitted response and cause overestimates of the normalization (hence the source flux) from a user's fits. A user can only tell if any of these regions were accessed in a mkacisrmf run by looking at the standard output of the tool or by checking the log file if the logfile parameter is used.

  A repaired version of the p2_resp file has been built by sorting the fourth block of the currently-released one on PHACHAN. Once the results have been verified, it will be released to the public.

  If your data are affected by these regions, use the mkrmf tool until the repaired calibration file is available. Again, you can see which regions are accessed from the screen output of the tool or by using a logfile to capture the tool output.

  Note that when the data are corrected for the sorting error, the resulting RMFs will be accurate below PHA=2562 (10 keV), but will be truncated above this value; that is to say, the RMF is meaningless above 10 keV for these 21 regions. The reason is that for these regions the tabulated SC_MATRIX data include some repeated or very nearly the same datapoints rather than giving a more extensive grid in PHA space. Sorting the file only corrects the ordering, not the extent of the grids.

  Long Term Solution: a new scattering matrix dataset has been generated by the ACIS calibration team, and is currently in testing at the CXC. This new file has not only the proper sorting, but a more extensive PHA grid, and the same grid is used for all regions (tiles) of ACIS. This calibration is expected to be released early this summer.