SPIHIST problem in OSA 3.0 (SPR 3416)

last update of this page: February 4, 2004

We recently found a severe problem in the SPI Instrument Specific Software (ISSW). The problem has been described in the Software Problem Report SPR 3416. As the effects of this problem are not always easy to see, I give a detailed description of what happens in some cases, how to see whether your analysis went okay, and how to avoid the problem.

The problem
Since OSA 3.0 the pointing step works properly. SPIPOINT is now able to identify cases, where the pointing was not stable. The tolerance value hardcoded in the spi_science_analysis script is 1 arcmin. When the attitude during a pointing changes by a value greater than 1 arcmin, SPIPOINT splits this pointing up into sub-pointings. In the output SPI.-OBS.-PNT data structure you will then find 2 or more lines for the same pointing ID. An example is one pointing from the Crab observation in revolution 102, pointing number 010200190010.001
The following steps in the SPI ISSW (COR, GTI, DEAD) work fine with this sub-pointings and create the correct data structures.
SPIHIST however does not handle this cases correctly. It therefore sorts the counts in the output data structure SPI.-OBS.-DSP wrong, so that from the split pointing onwards the attitude information will be wrong. Obviously this affects the image reconstruction and leads to wrong results, though the software may run without any error message until the end. In case there is no bright source in the field of view, you will not even get a strange looking output map.

How to identify the problem
If you have already done an analysis with OSA 3.0, you can easily check whether this problem affected your processing. Check the event output file (usually spi/evts_det_spec.fits / data structure SPI.-OBS.-DSP). If the last rows show no counts at all, this is a hint that this problem occured. In this case check the pointing output file spi/pointings.fits. If you have in the first column the same PTID_ISOC twice, then your processing will not have given the correct results.
Another hint that your analysis ran into this problem is a crash after the BIN_I level with the error message:
Error_2: kISDCTASKFAILED : Error occurred when attempting to run a task Error_2: Task spi_science_analysis terminating with status -35606

You can still correct the problem in this case without having to start it all over again. Do the following:

Identify the rows in your spi/pointings.fits file which show duplication of PTID_ISOC.
Remove the first row of the two (using in fv 'Edit', 'Delete', 'Rows'). Remember the row number (ROW) you deleted.
Change the header keywords ISOC_NUM and PT_NUM to the correct value
Remove in spi/dead_time.fits, spi/gti.fits, spi/back_model.fits the lines number [(ROW*19) - 18] up to [ROW*19]. Change also in those files the keywords ISOC_NUM and PT_NUM.
Remove in spi/evts_det_spec.fits the last 19 empty rows (if you removed one pointing).
Remove the SPIROS outputs (see the last point on the SPIROS tricks page) and re-run the IMA step.

How to avoid the problem

Install the new spihist 3.1.2. Read this FAQ to learn how to update a component in your installation

OR (if you do not want to install the new spihist for any obscure reason)

After og_create, run the analysis only up to the POIN level (chose startLevel = endLevel = POIN).
Check the pointing output file: fv spi/pointings.fits
If you see in the first column a PTID_ISOC twice, delete one of them. Then correct the header keywords ISOC_NUM and PT_NUM. You can also remove the pointing from your list of DOLs and re-run og_create.
Continue with spi_science_analysis with startLevel = GTI

In case of questions and comments: contact me.