cleansis

We have seen a few cases of observations of bright sources using Suzaku where running cleansis creates a hole in the image. Part of the problem is running with too high a log probability parameter but there is also a subtle error when iterating. Pixels which are already identified as bad and have their counts set to zero are still included when calculating the local background. This artificially lowers the estimated background hence increases the probability that a pixel will be flagged as bad.

I changed the algorithm so that pixels flagged as bad in previous iterations are ignored when calculating the local background. This change has been checked into the development version.

Suzaku AO4 on WebSpec

I've updated WebSpec with Suzaku AO4 files. The HXD background files supplied had a total exposure of 3e6 seconds. The recommended procedure is to have a background file with the same exposure as the source file. This assumes that statistical errors on the background are Poisson and the systematic error can be represented by changing the total normalization (using corfile). I modified the standard background files to change them from COUNTS to RATE so an input background file could be created for a given exposure time just by changing the EXPOSURE keyword.

Note that fakeit with a background file creates a simulated source spectrum with the exposure requested and a simulated background spectrum with the same exposure as that of the input background file. A useful enhancement for fakeit would be to control the exposure of the simulated background file - one possibility would be to allow commands such as
XSPEC12> fakeit inbackground.pha 50000

UPDATE 11/04/08: Fixed an error on the energy ranges for the PIN. The input background spectrum is only valid up to 75 keV. Also, use an background exposure time of 10 x that of the source for the PIN as recommended by the HXD team.

CHANTYPE problems

The Suzaku HXD PIN files use a CHANTYPE of PI_PIN. Strictly speaking this is a violation of the standard however it seems too limiting to just allow CHANTYPE the values of PHA or PI. xspec currently generates a spurious error message about mismatched CHANTYPE when reading the HXD spectrum and response. I've put a temporary workaround in RealResponse.cxx which suppresses the spurious warning however we need a more general solution.

Bug fix in xselect for suzaku

When I added the support for 5x5 to 3x3 conversion I missed the case of the user already having done an extract events. If this has happened then the event file to be used has a different name. Checked in a fix to this and was a bit cleverer about jumping out of the 5x5to3x3 routine if we don't need to run it.

suzaku xis response generation

Enabled the automated response generation in xselect for Suzaku XIS spectra. I'm still waiting for a decision from the XIS team on what default energy and channel binning to use in the response matrix. Ishisaki-san has suggested that the correct estepfile option for xissimarfgen is "medium" so the response generation uses this.

Currently using a "medium" binning scheme which produces 2048 channels. Spectra extracted from xselect are binned using this scheme whether or not the automated response generation is used.

Note that I also modified the MDB code to allow trailing wild cards eg XIS* will match to any of XIS0, XIS1, XIS2, or XIS3.

Also, updated addascaspec so it runs correctly if there is no ARF used.

suzaku xis 5x5 and 3x3 files

Checked in a change to xselect so that when there is a mix of 5x5 and 3x3 suzaku xis files read in then, when doing an extract, xis5x5to3x3 is used to create a temporary 3x3 file. This was requested by the xis team and ensures that doing an extract event creates a correct output 3x3 file. At the moment we aren't doing anything with the extra information in the 5x5 file.

Suzaku XIS response generator

Checked in xsl_suzaku_xis_makeresp, an automated script to build the XIS rmf and arf by calling xisrmfgen and xissimarfgen. Three speed options (fast, medium, slow) use different channel and energy binning schemes as well as different accuracies in the xissimarfgen run. The accuracies probably need a little more tweaking.

The point source option assumes that the source is in the center of the WMAP. Other possibilities here are to use ftstat on the WMAP to get the pixel with the highest value or the centroid of the map. It's not clear which is the best thing to do.

I would like to be able to use the algorithm found by Randall and implemented in xissmooth. This requires turning xissmooth into a general purpose ftool.

bad channels in the Suzaku XIS

Koji just spotted that xselect sets the channels 1-81 bad for the Suzaku XIS and this ought to be 0-81. Checked in a fix to xselect.mdb.