Skip to the navigation links
Last modified: 20 July 2010

URL: http://cxc-newtest.cfa.harvard.edu/ciao4.2/bugs/mkacisrmf.html

Bugs: mkacisrmf


Caveats

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

Bugs

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

  2. The tool will overwrite files even if clobber=no (01 Dec 2006)

  3. # mkacisrmf (CIAO 4.2): WARNING: No files found matching CALDB search:
    ...
    query=CTI_CORR.eq.NO.and.CTI_APP.eq.PPPPPSPSPP (03 Mar 2008)


Caveats

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


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. The tool will overwrite files even if clobber=no (01 Dec 2006)

    Setting clobber=no does not prevent the tool from overwriting existing files.

  3. # mkacisrmf (CIAO 4.2): WARNING: No files found matching CALDB search:
    ...
    query=CTI_CORR.eq.NO.and.CTI_APP.eq.PPPPPSPSPP (03 Mar 2008)

    Some CTI-corrected data have CTI_CORR=yes in the header, but no CTI_APP keyword. In this case, mkacisrmf incorrectly uses "CTI_CORR.eq.NO" in the CALDB query, as shown in the warning message, when it should be "CTI_CORR.eq.YES". The ACIS CTI Correction why topic explains the difference between the CTI_CORR and CTI_APP keywords.

    Workaround:

    Run acis_process_events, e.g. by following the Reprocessing Data to Create a New Level=2 Event File thread, so that the CTI_APP keyword is added to the header.

    mkacisrmf will run correctly on the reprocessed data.


Last modified: 20 July 2010