Bugs: dmextract
Table of Contents
Caveats
Bugs
Caveats
ACIS: Multiple GTIs
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.
Bugs
dmextract requires a "sky" vector to bin on x and y
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
Problem with pgrid() stack syntax
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.
Binning on celestial coordinates
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.
Bugs fixed in CIAO 4.14
The following is a list of bugs that were fixed in the CIAO 4.14 software release.
When extracting a lightcurve with opt=ltc1|2, dmextract is using the LAST GTI in the files subspace instead of the first.
Most users will not see a significant difference due to this problem. However, if there are significant difference in the good time intervals for different CCDs then the effect on the exposure and derived quantities such as count rate may be significant.
Users can use dmlist to check if there are significant different in the good time intervals. Checking the ONTIME keywords will give you a quick check. For example
% dmlist acisf00635N004_evt2.fits keys,clean | grep ONTIME ONTIME 101971.118154570 [s] Sum of GTIs ONTIME3 101971.118154570 [s] Sum of GTIs ONTIME2 101971.118174480 [s] Sum of GTIs ONTIME1 101974.359244420 [s] Sum of GTIs ONTIME0 101974.359124730 [s] Sum of GTIs ONTIME6 101974.359134730 [s] Sum of GTIs % dmlist acisf06122N004_evt2.fits.gz keys,clean | grep ONTIME ONTIME 32165.3751822410 [s] Sum of GTIs ONTIME7 32165.3751822410 [s] Sum of GTIs ONTIME2 29950.6343590320 [s] Sum of GTIs ONTIME5 32204.2670757770 [s] Sum of GTIs ONTIME6 30130.0288070440 [s] Sum of GTIs ONTIME3 30142.9928573670 [s] Sum of GTIs ONTIME8 30311.5253468450 [s] Sum of GTIs
In the first dataset, the ONTIME values are approximately the same for each CCD. In the second dataset, the ONTIME values vary significantly from chip to chip.
Workaround:
To work around the problem, users should explicitly specify which CCD the source is located on.
% punlearn dmcoords % dmcoords acisf06122N004_evt2.fits.gz op=cel ra=19:15:33.3048 dec=-24:10:46.063 celfmt=hms % pget dmcoords chip_id 7 % dmextract acisf06122N004_evt2.fits.gz"[ccd_id=7,sky=region(ds9.reg),energy=500:7000]" src.lc op=ltc1