|
|
Bugs: mkacisrmf
A list of
bugs fixed in CIAO 4.0
is available.
Caveats
Lower limit on the energy bounds is 0.243 keV
The energy grid of the ARF and RMF files must be the same
for use in XSpec.
(25 Aug 2006)
ERROR: Max egridspec energy=10 above max FEF
energy=9.886
Bugs
Issue with the WMAP when the source is at a chip edge
The tool will overwrite files even if clobber=no
(01 Dec 2006)
# mkacisrmf (CIAO 4.0): WARNING: No files found matching CALDB search:
...
query=CTI_CORR.eq.NO.and.CTI_APP.eq.PPPPPSPSPP
(03 Mar 2008)
Caveats
-
Lower limit on the energy bounds is 0.243 keV
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.
-
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).
-
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])"
-
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 4.0): WARNING: Found "pixlib" library parameters
# dmhistory (CIAO 4.0): 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.
-
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
-
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.
-
The tool will overwrite files even if clobber=no
(01 Dec 2006)
Setting clobber=no does not prevent the tool from
overwriting existing files.
-
# mkacisrmf (CIAO 4.0): 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.
The following is a list of bugs that were fixed
in the CIAO 4.0
software release.
-
mkacisrmf generates incorrect RMF for non-standard channel
grid
(16 Aug 2006)
e.g. channel="69:128:1". An example of a standard
channel grid is channel="1:4096:1".
-
The tool may fail with messages of this form:
# mkacisrmf (CIAO 3.4): WARNING: 2 CALDB files found. Using the first
# mkacisrmf (CIAO 3.4): ERROR: do not find extension related to 'RESP_TWEAK'.
This occurs when the WMAP file is empty (i.e. all values
are zero). You can open the WMAP in ds9 to view it:
where src_pi.fits contains a WMAP block:
unix% dmlist src_pi.fits blocks
--------------------------------------------------------------------------------
Dataset: mkacisrmf_bgfile_src1.pi
--------------------------------------------------------------------------------
Block Name Type Dimensions
--------------------------------------------------------------------------------
Block 1: WMAP Image Int2(1024x1024)
Block 2: SPECTRUM Table 4 cols x 1024 rows
Block 3: GTI3 Table 2 cols x 3 rows
Block 4: GTI6 Table 2 cols x 1 rows
Block 5: GTI7 Table 2 cols x 1 rows
Block 6: GTI2 Table 2 cols x 3 rows
Block 7: GTI1 Table 2 cols x 1 rows
Block 8: GTI0 Table 2 cols x 2 rows
|
![[CIAO Logo]](../imgs/ciao_logo_navbar.gif){kind=logo}
![[New]](../imgs/new.gif)