Hello chandra-users,
[This is the same issues which was included in the Chandra Electronic
Announcement #69 earlier today.]
The CIAO team has identified a bug which affects all ACIS and HRC
grating data analysis. This bug is new in CIAO 4.3.
When a time filter is applied to a level=1.5 (evt1a.fits) or level=2
(evt2.fits) grating file *and* the dmcopy opt=all option is used, the
GTI block in the output file is not updated to reflect the correct
time range.
Time-related header keyword values - such as ontime, livetime, and
exposure - will be incorrect because they are calculated from the time
ranges in the GTI block.
This time-filtering is one of the standard reprocessing steps for
grating data, so anyone that has reprocessed a grating dataset in CIAO
4.3 is affected.
Workaround:
Run dmcopy without "opt=all" when applying any time filters. Then run
dmappend to copy the grating REGION block onto the filtered output
file.
In this example, the time filter is an flt1.fits file from the
Archive. The filter might also be supplied as a GTI file created with
the dmgti tool, an ASCII table, or a range specified on the command
line.
Standard syntax:
unix% dmcopy "evt1a.fits[EVENTS][@flt1.fits]" evt2.fits opt=all
Workaround syntax:
unix% dmcopy "evt1a.fits[EVENTS][@flt1.fits]" evt2.fits
unix% dmappend "evt1a.fits[region][subspace -time]" evt2.fits
The subspace filter is necessary so that the GTIs aren't reapplied to
the output file, as explained in the dmappend caveat:
http://cxc.harvard.edu/ciao/bugs/dmappend.html
Note that grating data reprocessed with the chandra_repro script is
also affected by this bug. We are working on a patch to the script
which will incorporate this workaround.
If you have any questions on the bug or this workaround, contact the
CXC HelpDesk for assistance:
http://cxc.harvard.edu/helpdesk/
This archive was generated by hypermail 2b29 : Tue Feb 12 2013 - 01:00:12 EST