Weighting ARFs and RMFs: multiple sources

CALDB 3.3.0.1 patch

The CALDB 3.3.0.1 patch, released on 02 February 2007, corrects an indexing problem that may affects users of this thread. Read the Caveat: ACIS -120C FEF for CTI-corrected ACIS data for details.

Make sure that this patch has been installed in your CALDB before continuing:

unix% dmlist "$CALDB/docs/chandra/caldb_version/caldb_version.fits[cols caldb_ver,ciao_ver]" data 
...
    52 3.2.4     CIAO3.3.0.1  
    53 3.3.0     CIAO3.4      
    54 3.3.0.1   CIAO3.4 

This file is automatically updated each time the CALDB is upgraded on your system, so the final row always indicates the current version.

Using Consistent Calibration: mkrmf vs mkacisrmf

The tool mkacisrmf, available since CIAO 3.2, represents an entirely new method for creating ACIS imaging response matrices. Details on the tool are available in the Creating ACIS RMFs why topic. This thread uses the older tool mkrmf to create the RMF files.

Users who wish to take advantage of the improvements in mkacisrmf may use it in place of mkrmf. The Creating ACIS RMFs with mkacisrmf thread shows how to run the tool.

It is especially important to read the caveat on Matching the number of energy bins if you intend to use mkacisrmf.

The ACIS dead area correction

There is a fractional area loss per unit time due to cosmic ray flux incident on the ACIS detector. Calibration to account for this ACIS "dead area" was included in CALDB 3.3.0 on 15 December 2006. The correction is non-zero for the 8 front-illuminated ACIS chips; the effect is not detectable for the BI chips, so the nominal calibration value is 0.0. The resulting chipy-dependent reduction in the EA will be approximately 2.2% at the readout, and 4.0% at the top of the chip. Refer to the ACIS Dead Area Correction why topic for technical details.

In CIAO 3.4, the application of the dead area correction is turned off by default. However, users may opt to include it in the analysis by setting the pbkfile and dafile parameters in the mkwarf step. Refer to the mkwarf help file for details on these parameters.

If you wish to include the correction when running this thread, set the pbkfile and dafile parameters:

unix% pset mkwarf pbkfile=acisf052379707N002_pbk0.fits dafile=CALDB

A. Using dmextract

To create a WMAP block in a PHA file, dmextract must be given a binning specification for its wmap option. As the WMAP must be in detector coordinates, and the suggested binning factor is 8, we have

unix% punlearn dmextract
unix% pset dmextract infile="sources.evt2[bin pi]"
unix% pset dmextract outfile=sources.pi 
unix% pset dmextract wmap="[bin det=8]"
unix% dmextract
Input event file  (sources.evt2[bin pi]): 
Enter output file name (sources.pi): 

The file sources.pi contains both the source spectrum and WMAP. You can check the parameter file that was used with plist dmextract.

Note that dmextract allows additional filters to be specified for the wmap parameter. This means that you can filter the WMAP on energy - e.g. the 0.5 to 2.0 keV band - without having to have a separate WMAP:

unix% pset dmextract wmap="[energy=500:2000][bin det=8]"

Running dmlist on the output file shows the WMAP block:

unix% dmlist sources.pi blocks
 
--------------------------------------------------------------------------------
Dataset: sources.pi
--------------------------------------------------------------------------------
 
     Block Name                          Type         Dimensions
--------------------------------------------------------------------------------
Block    1: WMAP                           Image      Int2(1024x1024)
Block    2: SPECTRUM                       Table         4 cols x 1024     rows
Block    3: GTI7                           Table         2 cols x 1        rows
Block    4: GTI5                           Table         2 cols x 2        rows
Block    5: GTI2                           Table         2 cols x 7        rows
Block    6: GTI3                           Table         2 cols x 7        rows
Block    7: GTI8                           Table         2 cols x 4        rows
Block    8: GTI6                           Table         2 cols x 5        rows

B. Using dmcopy

If we use dmcopy directly, we are free to choose any energy range for the WMAP. Here we use the soft band (0.5 to 2.0 keV), which effectively count-weights the averaging of the responses, whereas use of harder energies, where the background dominates, would use area-weighting. As with the dmextract option, we use the detector coordinate system with a binning factor of 8:

unix% dmcopy "sources.evt2[energy=500:2000][bin det=8]" sources.wmap8

This command creates a WMAP image in detector coordinates:

unix% dmlist sources.wmap8 blocks
 
--------------------------------------------------------------------------------
Dataset: sources.wmap8
--------------------------------------------------------------------------------
 
     Block Name                          Type         Dimensions
--------------------------------------------------------------------------------
Block    1: EVENTS_IMAGE                   Image      Int2(1024x1024)
Block    2: GTI7                           Table         2 cols x 1        rows
Block    3: GTI5                           Table         2 cols x 2        rows
Block    4: GTI2                           Table         2 cols x 7        rows
Block    5: GTI3                           Table         2 cols x 7        rows
Block    6: GTI8                           Table         2 cols x 4        rows
Block    7: GTI6                           Table         2 cols x 5        rows

A. Using the WMAP from a PHA file

Unlike mkarf, mkwarf must be given an energy grid that lies within the range of energies of the FEF file. An easy way to find the allowed range is to run mkwarf with an energy range that definitely extends outside the allowed values - we use 0.01 to 11 keV here. Further information on the FEF files can be found in the Chandra CALDB pages (in particular the "Calibration Data" section).

In this run, the WMAP created with dmextract (sources.pi) is used:

unix% punlearn mkwarf
unix% pset mkwarf infile="sources.pi[WMAP]"
unix% pset mkwarf outfile=sources.warf
unix% pset mkwarf weightfile=sources.wgt
unix% pset mkwarf egridspec=0.01:11:0.01
unix% mkwarf
Input detector WMAP (sources.pi[WMAP]): 
Output weighted ARF file (sources.warf): 
Output FEF weights (sources.wgt): 
Input Spectral weighting file (<filename>|NONE) (): 
Output energy grid [kev] (0.01:11:0.01): 
# mkwarf (CIAO 3.4): The following error occurred 175 times:
        ERROR: Min egridspec energy=0.01 below min FEF energy=0.277

# mkwarf (CIAO 3.4): The following error occurred 175 times:
        ERROR: Max egridspec energy=11 above max FEF energy=9.886

Using the energy range 0.28 to 9 keV, re-run mkwarf:

unix% pset mkwarf egridspec=0.28:9:0.01
unix% mkwarf
Input detector WMAP (sources.pi[WMAP]): 
Output weighted ARF file (sources.warf): 
Output FEF weights (sources.wgt): 
Input Spectral weighting file (<filename>|NONE) (): 
Output energy grid [kev] (0.28:9:0.01): 

The output from mkwarf is a weighted ARF (sources.warf) and a weights file (sources.wgt). You can check the parameter file that was used with plist mkwarf.

Error messages are given if the infile is erroneously given without the "[WMAP]" block designation and the tool will fail:

...
Couldn't determine chip position for pixel: (1013.000000,0.000000) with value=1.000000. Skipping pixel
Couldn't determine chip position for pixel: (1014.000000,0.000000) with value=1.000000. Skipping pixel
...
# mkwarf (CIAO 3.4): ERROR: No valid response regions could be created.

In this case, the "pixel" locations will be the spectral bins of the PHA or PI spectrum to which the WMAP is usually attached.

B. Using an image as a WMAP

Since we used the WMAP within the PHA file as the value for the infile parameter in the previous mkwarf run, we had to specify the extension name of the block containing the WMAP data (i.e. the "[WMAP]" DM filter). Here we use a similar filter to avoid seeing several warning generated by ardlib; it is not required that you specify the block. Remember that now we are using the WMAP created with dmcopy (sources.wmap8).

Since the energy range was determined in the previous example, it is not necessary to run the tool twice:

unix% punlearn mkwarf
unix% pset mkwarf infile="sources.wmap8[EVENTS_IMAGE]"
unix% pset mkwarf outfile=sources_img.warf
unix% pset mkwarf weightfile=sources_img.wgt
unix% pset mkwarf egridspec=0.28:9:0.01
unix% mkwarf
Input detector WMAP (sources.wmap8[EVENTS_IMAGE]): 
Output weighted ARF file (sources_img.warf): 
Output FEF weights (sources_img.wgt): 
Input Spectral weighting file (<filename>|NONE) (): 
Output energy grid [kev] (0.28:9:0.01): 
# mkwarf (CIAO 3.4): WARNING: Input image name was "EVENTS_IMAGE" instead of "WMAP".  Will attempt to use.

A few notes on warning messages:

• The warning message seen above can be ignored in this case, since we know that sources.wmap8 was created as a WMAP image (i.e. the detector coordinate system was used).

• If you do not specify the extension for the infile, you may see warnings of this form:

  ***ARDLIB warning: Filename sources.wmap8 does not specify an extension.
     Assuming the first "interesting" extension.
  

  The warnings may be ignored as they do not adversely affect the output.

• If your source is near a chip boundary, then mkwarf may not be able to determine the chip location of every pixel in the WMAP (this has to do with the lack of SIM info in the image); details are available in this FAQ. This will lead to warnings such as:

  Couldn't determine chip position for pixel: (3884.500000,3588.500000) with value=1.000000. Skipping pixel
  Couldn't determine chip position for pixel: (3884.500000,3596.500000) with value=5.000000. Skipping pixel
  

  In the vast majority of cases, the number of counts ignored (i.e. the sum of the "value" of each ignored pixel) is much smaller than the total signal in the WMAP. However, this may not be the case for small regions near chip boundaries. dmstat may be used to determine the sum of all pixels in the WMAP for comparison to the sum of the ignore pixel values.

C. Which FEF was Used by mkwarf

Unlike mkarf, mkwarf does not need to be told the FEF file to use, as it can query the CALDB to find the matching file (see "ahelp caldb" for more information on the syntax of the CALDB tool interface). To find out which FEF file it used, either set verbose=2 before running the tool (it gets printed out during execution), examine the FEFFILE keyword in the file header, or use the acis_fef_lookup script (available from the Scripts page), specifying a chipid of none. We show examples of these methods here (the output assumes that the $CALDB environment variable is set to /soft/ciao/CALDB):

unix% mkwarf verbose=2
...
Mapping response regions to FEF regions
FEF File: /soft/ciao/CALDB/data/chandra/acis/cpf/fefs/acisD1999-08-13fef_phaN0002.fits
Mapping response regions to FEF regions. Done
...

and

unix% dmkeypar sources.wgt FEFFILE echo+
/soft/ciao/CALDB/data/chandra/acis/cpf/fefs/acisD1999-08-13fef_phaN0002.fits

and

unix% acis_fef_lookup sources.evt2 none 1 1
/soft/ciao/CALDB/data/chandra/acis/cpf/fefs/acisD1999-08-13fef_phaN0002.fits[FUNCTION]