Bugs: dmextract

When extracting a lightcurve using opt=ltc1|ltc2, dmextract uses the information from the input file's GTI. ACIS data contains a separate GTI for each active CCD (up to 6); however, they are typically nearly identical except for a small time offset due to the how the CCDs are read-out. dmextract uses the last GTI it finds in the file. Since the GTIs are nearly identical (especially compared to the time resolution of the lightcurve) the difference in GTIs is usually irrelevant.

However, there are some ACIS observations where the GTIs are very different for each CCD. These are mostly due to very bright sources imaged with or with out the gratings that cause telemetry to saturate and results in dropped exposures. Since exposures from individual chips are dropped separately, the GTIs can be very different for different CCDs. For example OBS_ID=3505 has very different GTIs for each CCD due to a large number of dropped exposures.

% dmlist 3505/secondary/acisf03505_001N003_flt1.fits.gz blocks
 
--------------------------------------------------------------------------------
Dataset: 3505/secondary/acisf03505_001N003_flt1.fits.gz
--------------------------------------------------------------------------------
 
     Block Name                          Type         Dimensions
--------------------------------------------------------------------------------
Block    1: PRIMARY                        Null        
Block    2: FILTER                         Table         0 cols x 0        rows
Block    3: GTI7                           Table         2 cols x 1        rows
Block    4: GTI4                           Table         2 cols x 3566     rows
Block    5: GTI5                           Table         2 cols x 3981     rows
Block    6: GTI6                           Table         2 cols x 2826     rows
Block    7: GTI8                           Table         2 cols x 2748     rows
Block    8: GTI9                           Table         2 cols x 3998     rows

This may lead to an error in the lightcurve exposure values and thus in the count_rate if the user specifies an extraction region that is on a different CCD or one that spans multiple chips.

Workaround:

Users can specify a ccd_id filter to select a single CCD when they run dmextract. This will essentially select the correct GTI. Users who need to compute a lightcurve for multiple CCDs need to run dmextract separately for each CCD and then combine them together.

If the x and y columns are not associated as a "sky" vector, dmextract can't bin on them:

unix% dmextract infile="img.fits[bin (X,Y)=@ann.reg]" ...

# dmextract (CIAO): dsDMEXTRACTREGWCSWERR -- WARNING: Expected 2 dimensions for the sky descriptor. Skipping translation of region to WCS. 
or
# dmextract (CIAO): dsFINDCOLUMNERR -- ERROR: Column 'sky' was not found
in file 'HDU2'.

Workaround:

Edit the file header to create a sky vector.

unix% cat dmhedit.lis
#add
MTYPE1 = POS
MFORM1 = X,Y

unix% punlearn dmhedit
unix% dmhedit img.fits dmhedit.lis

There is a problem using the pgrid() stack syntax when making radial profiles.

unix% dmextract "image.fits[sky=pgrid(4096,4096,0:1000:100,30:60:30)]" sector.fits opt=generic

While the tool runs to completion, the output is not always correct.

Trying to bin on celestial coordinates can yield incorrect results

% dmextract "events.fits[bin cel=circle(150.57256,2.4995918,0.09')]" outfile=/tmp/test.fits op=generic

which may produce an incorrect radius column.

Users should only bin in physical or logical coodinates.