The Chandra X-ray Observatory has an excellent analysis and data reduction package in CIAO. Like all software, it has bugs, and many reported bugs are not listed in the official bug pages.
Some of these are of course obscure problems that will only affect using doing something more complex than the rather simple analysis the average user does.
These pages are my unofficial, selective and incomplete, list of bugs that affect my work in analysing faint diffuse emission from star-forming galaxies. These are mainly persistent issues that tend to plague several versions of Ciao, e.g. region area calculations have been a mine field full of a variety of bugs since Ciao 2.0.
Affects: Everything that uses acis_set_ardlib and expects it to run without command line parameters. The purpose of acis_set_ardlib is to correctly set the ardlib.par parameter file for the current observation being processed. For years now it has simply been run without any command line arguments and finds the appropriate pitpix etc files in the current directory. Now in version 3.3 you must supply the bitpix file name your self. What frigging genius made this change? They could have made it an optional parameter, preserved existing functionality while adding the option to use a new bitpix file as an optional parameter, but no, they have to break every frigging script that uses acis_set_ardlib. Very clever.
Work-around (a): Switch back to using the tried and tested Ciao 3.2. At least I knew where all the bugs were.
Work-around (b): Replace all (sigh) calls to acis_set_ardlib with a call to a new script that finds the badpix file and then calls acis_set_ardlib, i.e. does what acis_set_ardlib should do. Luckily I only have to alter 56 scripts...
Affects: There is a bug in dm image filtering such that when a region and a range filter are applied to an image at the same time, the range filter is ignored. This bug was not present in Ciao 2.x versions.
For example the range filter (#1 etc) in "dmstat infile=my_image.fits[sky=region(my_region.reg),#1=34:35] centroid=no" is ignored. See the DM bug list for more info and solutions/explanation.
Work-around: To get around this we're forced to dmcopy and filter the images with the region filter first, setting non-used pixels to NaN (e.g. dmcopy infile='my_input_image.fits.gz[sky=region(my_region.reg)][opt null=NaN,full]' outfile=tmp.fits.gz). Then use the range filter on this temporary image. This appears to work accurately.
Affects: Very large images, specifically 8192x8192 pixel images. dmstat will run on such a large image, although incredibly slowly. However trying to use a region file on such an image will result in an error.
See Chandra bug 7203 and the DM bug list for more info and solutions/explanation.
Work-around: Don't use x=::1,y=::1 binning syntax, bin on sky=1 instead. I have not tested this style on binning in other situations.
Affects: Any area calculated with dmextract, i.e. pha spectra BACKSCAL values, fits tables extracted from events files or images, with some, but not all, non-trivial regions.
See helpdesk ticket 7151. See also the Ciao 3.2 watch-out page.
Work-around: Always calculate areas using dmstat on a finely-binned image, and then correct values, e.g. the BACKSCAL values of pha spectra. However, watch out for the next bug.
Affects: The area ("good" pixels) calculated by dmstat within some, but not all, non-trivial regions, on images with existing region subspaces.
See helpdesk ticket 7243. See also the Ciao 3.2 watch-out page.
Work-around: Don't run dmstat on an image with a region subspace created by dmextract or dmcopy - wipe the subspace or dont have one at all.
Affects: All gzipped fits files. An unrelated bug with dmhedit is that it does not allow the removal of DM-related header keywords.
dmhedit can not edit the header keywords of gzipped fits files, and fails without warning when such an operation is attempted. This is due to a CFITSIO "feature" of not allowing the modification of an existing gzipped fits file - you can write, read, and overwrite gzipped fits files but not open them for read/write access. Worse still, it does not give a non-zero return code to the shell when having failed in this fashion, so scripts can not detect such an error.
Note that the FTOOL fmodhead also does not allow the modfication of fits header keywords in gzipped files, but at least it gives an error message and returns an error code to the shell when this happens.
Work-around: The work around is to wrap dmhedit in a script that gunzips any gzipped file, runs dmhedit, then gzips the file if it was originally gzipped.