Bugs: mkwarf

Users trying to run this tool with old versions of data products, those created with ASCDSVER less than version 8.4.2, may see warnings like

# mkwarf (CIAO): WARNING: The pbkfile parameter is no longer used. The information required for the Dead Area calibration will be extracted from wmap.

# mkwarf (CIAO):  WARNING: Could not find keyword SUM_2X2 in file wmap. The dead area calibration will not be included in the response.

Users should reprocess their data or use the r4_header_update script.

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.

The preferred WMAP will be in TDET coordinates so this will not be a problem.

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. The follow message may be printed at verbose >0.

# mkwarf (CIAO): ERROR: Could not map response region to FEF region

Users should be sure to supply an aspect solution file.

If a weighted ARF is being created for a large region, on order of a full chip (or larger), mkwarf may hit the intrinsic memory limit of a 32-bit application.

Workaround:

There is a parameter in sky2tdet, bin - that specifies the binning of the WMAP, which is used as input to mkwarf.

If you encounter this bug, increase the bin value to create a coarser WMAP.

The issue is that the conversion from detector coordinates (i.e. those used to create the WMAP) to chip coordinates needs the SIM_Z values. In reality, SIM_Z varies with time, but as we have an image (hence no time information) and the SIM_Z variations are usually small, a single value stored in the image header is used for the transformation.

This means that there's actually some ambiguity in the mapping from the WMAP to chip location. In reality this isn't a concern, since we already bin on larger scales than introduced by the SIM_Z variation (i.e. we are only concerned with 32x32 pixel regions on the chip). However, it does mean that those pixels close to the chip boundaries can end up as apparently not falling on a chip. In this case, we issue the warning shown and ignore the counts from this pixel in the WMAP.

If the ignored counts are small compared to the total signal in the WMAP, as in the vast majority of situations, then it's not a problem. It can be a problem if most of the counts in the WMAP end up being ignored. In reality, this situation is unlikely to occur; two possible situations would be where the source region is narrow and lies along the chip boundary (this is a truly extreme case) or if you are using mkwarf to calculate "point source" responses near chip boundaries.