Incorrect GTIs when time-filtering grating data with dmcopy opt=all

The CIAO team has identified a bug which affects all ACIS and HRC grating data analysis.

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.

Workaround

Run dmcopy without "opt=all" when applying any time filters. Then run dmappend to copy the grating REGION block to 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 are not reapplied to the output file, as explained in the dmappend caveat.

The chandra_repro script has been updated to include a workaround for this bug. The GTIs are calculated correctly for grating data with this workaround.