Bugs: dmextract

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

The tool is shifting the value by one record of the DTF file.

If a bin exceeds the time range in the DTF file, the exposure values are incorrect as well.

Users can still do this analysis with dmextract if the DTF values are nearly constant. Any bins outside the boundaries of the file should be ignored.

When running dmextract with an exposure map and a large stack of source and/or background regions, the tool may fail with the error:

# dmextract (CIAO): dsDMBLOCKOPENERR -- ERROR: Failed to open the DM
data block in dataset '<exposure map>'. DM Error: 'No kernel
found for dataset <exposure map>'.

This is due to the tool running out of memory from opening the exposure map once per region.

Workaround:

Create smaller stacks and run dmextract more than once to analyse all the regions.

The effect is that instead of just selecting the DTF record that covers the lightcurve bin, it's incorrectly adding/averaging such that an extra DTF record's time on either side.

If the lightcurve time bins overlap one or more DTF boundaries, all is well. The problem only occurs when the lightcurve bin is entirely inside a DTF bin.

If a background exposure file is provided in the bkgexp parameter, the values in the output bg_exposure column are wrong.

The output COUNTS column will be NaN if the region encloses a NaN-value pixel. The tool checks for integer NULLs, but support for floating-point NaNs has not yet been added.