Bugs: dmcopy

The CIAO team has identified a bug which affects all ACIS and HRC grating data analysis. This bug was introduced 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 or 4.4 is affected.

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, e.g.

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.

For example:

unix% dmcopy acis.img"[bin x=::5,y=::6]" acis5x6.img

Using the same value for both axes works correctly:

unix% dmcopy acis.img"[bin (x,y)=::5]" acis5.img

Workarounds:

1. Use a CIAO tool in place of the FTOOL that created the BLANK keyword, e.g. instead of chimgtyp, try

   unix% dmcopy input.fits"[opt type=i4,null=-9999]" output.fits 
   

   changing the opt type as appropriate.

2. Delete the BLANK keyword before passing the file to dmcopy or any other CIAO tool.

For example:

unix% dmcopy acis.fits"[spectrum]" spectrum.fits
unix% dmlist spectrum.fits blocks 
 
--------------------------------------------------------------------------------
Dataset: spectrum.fits
--------------------------------------------------------------------------------
 
     Block Name                          Type         Dimensions
--------------------------------------------------------------------------------
Block    1: WMAP                           Image      Int2(1024x1024)
Block    2: SPECTRUM                       Table         5 cols x 1024     rows
...

Here we expected to only get the SPECTRUM block, not the as WMAP well.

Workaround:

There is an odd sort of workaround:

unix% dmtcalc acis.fits spectrum2.fits expr="(1==1)"
unix% dmlist spectrum2.fits blocks 
 
--------------------------------------------------------------------------------
Dataset: spectrum2.fits
--------------------------------------------------------------------------------
 
     Block Name                          Type         Dimensions
--------------------------------------------------------------------------------
Block    1: PRIMARY                        Null        
Block    2: SPECTRUM                       Table         5 cols x 1024     rows
...

The number of bins that dmcopy creates is different than the input specification:

unix% dmcopy acis_evt2.fits"[bin x=3482:4708:#122,y=3406:4630:#122]" test.fits

unix% dmlist test.fits blocks
....
Block    1: EVENTS_IMAGE                   Image      Int2(123x122)
...

The DM first checks the file's world read/write permissions. If permissions are not read and write, then it checks the group permissions. However, the process group ID and the file group ID must be the same in order for it to check for read and write permission. When they are different, it moves on to check owner permissions.

Workaround:

Be sure that you are running dmcopy as the same group as the file to be overwritten.