INTEGRAL Science Data Center (ISDC) =================================== http://isdc.unige.ch Known issues ============ Package: OSA Version: 6.0 Rel. Date: 15-Jan-2007 ------- General ------- 1.In addition to the time correlation corrections listed in Walter et al, 2003 (A&A 411, L25) a new correction should be added on data taken between 20th August 2003 (rev. 104) and 29th June 2004 (rev. 209) . All UTC (IJD) time stamps derived from on board time should be increased by 385 microsec. This correction is taken into account in the currenlty archived. ---- IBIS ---- ISGRI ***** 1.The gain and offset corrections on the measured pulse amplitude and rise time need to be corrected for the effect of radiation damage. This has been calibrated up to revolution 300. A new calibration file will be delivered soon to cover later revolutions. 2.The SPSF (System Point Spread Function) fit may fail (does not converge) during the sky image generation when there are close sources (within 15-20 pixels from the target source). 3.In the mosaic build with the option spread=1 the source flux is slightly reduced (~ 10 %) compared to the weighted average of the fluxes measured in the Science Window. 4.Secondary lobes of strong very-off-axis sources are sometimes not fully corrected/cleaned in reconstructed images. 5.The maximum number of sources handled by ii_spectra_extract is 100 but it is strongly recommended to only fit spectra of the sources that are effectively active (visible, detectable) during the Science Window. 6.In general, a safe lower limit for the response is 22.5 keV. It is related to insufficient knowledge/modelling of the energy calibration and of low thresholds at low energy and their variations with time. 7.A problem on-board IBIS causes event times to be shifted by 2 seconds under some circumstances. The software corrects for it. The keyword TIMECORR found in *-*-ALL or *-*PRP structures of a Scw group, indicates whether the correction was done somewhere in this Scw. The algorithm is the following: (1) detect if there could be a possible 2 sec jump (2) if (1) then look if there was indeed a jump. (3) if (2) then correct, if not (2) then don't correct (4) if we cannot determine either (2) or not (2) then flag. As a result, the TIMECORR keyword can have the following values: 0: no possible jump 1: possible jump, jump indeed exists, corrected 2: possible jump, jump did not take place, not corrected 3: possible jump, cannot decide if jump took place, not corrected 4: possible jump, algorithm has a problem, to be investigated If you are doing absolute timing and your data contains TIMECORR>0 take great care. If TIMECORR=1 or 2 it should be OK. If TIMECORR=3 you should better not use it. If TIMECORR=4 contact ISDC 8.The lightcurve extraction (ii_lc_extract) is performed by building shadowgrams for each time and energy bin. It potentially takes a large amount of CPU time and moreover there is a limit on the minimum duration of the time bins for a given number of energy bins and the duration of the given Science Window. The time bin for the light curve must be such that the total number of maps in the file isgr-corr-shad does not exceed 2 Gig worth of disk space. Since 3 maps (intensity, variance, efficiency) are created per image and each image takes 130*134*4 bytes or 24 fits blocks, plus one fits block for the header, for a total of 3*25*2880=216000 bytes, the product of the number of time bins, per each science window, and the number of energy bands must be less than about 9942, assuming that no images are left from image and spectral analysis. Example: assuming Nim+Nsp=30 shadowgrams already created for images and spectra, for a Tscw=3000 s science window duration, 4 light curves in Ne=4 energy bands can be created (for a total of Nlci=9942-(Nim+Nsp)=9912 light curve images) with the minimum time bin Tbin given by Tbin = Ne x (Tscw/Nlci) = 4 x 3000/9912 = 1.2 s 9.Version 12 of XSPEC cannot read the isgri spectra extracted per ScW in "isgri_spectrum.fits" beyond the first extension. In case you want to study the ScW by ScW spectra of a given source, you may either use XSPEC 11 or use "spe_pick" to extract the spectra in PHA2 format ("single=y" option), which can be read by XSPEC 12. 10.ii_pif will crash if the input catalog inCat contains more than 500 sources. PICsIT ****** 1. The spectra extraction with PIF method is not reliable for the moment (executable ip_spectra_extraction). The user should extract the spectra from images (count rates from intensity maps and errors from significance maps) and then convolve them with the RMF/ARF. 2. The value of FLUX_ERR column in the file pics_sky_res.fits is not correct. The error can be calculated from the DETSIG column (SPR 4642). 3. In the first energy band (203-252 keV), when PICsIT cannot find any evident source, the software catches the first source in the catalog (SPR 4638). Obviously this has no physical meaning. --- SPI --- 1.SPI is a complex Gamma ray instrument almost always dominated by background contributions. The scientific validation of the SPI data analysis going on at ISDC and at different instrument team sites is as of today far from complete. Users are encouraged to look critically at any result obtained with the ISDC software, and to use external comparisons and simulations when possible. Spurious results can be derived, for example, when using a wrong set of parameters and/or an incorrect background modeling. 2.The SPI instrument is equipped with a Pulse Shape Analysis (PSD) electronic which carries out a parallel processing of the single detector events in order to provide additional information about their pulse shape. The PSD information was intended to help reducing the background. Unfortunately, the in-flight background conditions are such that even the best experts have failed to achieve significant improvements with the PSD. Consequently, all the PSD related processing is currently disabled in the analysis pipeline. PSD events are simply used as standard single events. The basic user choice is then to analyze only single (+PSD) events specifying detector list of 0-18 in the analysis, or to consider double and triple detector interaction with pseudo detectors 19-84. Also be aware that the RMF response available for XSPEC spectral fitting is only valid for single events. As a consequence, we recommend to use only single events (i.e., a detector list 0-18 in your analysis parameters), at least for all point source analyses below 1 MeV. 3.Three instrumental responses are now included in our system, characterizing SPI before, between, and after, the detectors 2 and 17 failures. The analysis system cannot currently handle a time variable response. The easiest is to analyze the three possible cases independently (our software then selects automatically the appropriate response), and to combine the results later on. It is possible however, to analyze different mixtures of different data together using one of the three responses as they are not too different. Great care should be taken in this case anyway to avoid possible biases (see the Tips and Tricks section of our documentation). 4.At least in one case, a long (staring) pointing which is split up into several science windows in the ISDC system is not handled correctly in the SPI data analysis. It concerns: ScWs 008200220010.001 008200220020.001 008200220030.001. Only the first pointing is properly included in the analysis, while the subsequent ones are ignored. Please report if you find any other such cases. ----- JEM-X ----- 1.The JEMX lightcurves are deadtime corrected. DEADC in the lightcurve files are set to 1.0 (for XRONOS compatibility). 2.Due to changes of the on-board configuration, the detection efficiency has changed significantly several times during the mission history. This means that the measured fluxes of stable sources -- in particular at low energy -- will strongly depend on the time when the data was taken. These changes are not corrected for in flux units (counts/dm2/s in the given energy interval) but taken into account in spectral responses. 3.The JEM-X detector gain varies significantly for a few hours after the instrument has been switched on. This mostly affects the beginning of each revolution but can also happen if the instrument was shut down, e.g., for solar flares. The pattern is very similar each time and modeled in the gain correction step even in complicated cases. Nevertheless, it could in principle fail, in which case linear-interpolation gain correction values would be used, which could lead to distorted spectra. Users are advised to check this possibility in case of highly unusual source spectra e.g. by consulting http://www.spacecenter.dk/~oxborrow/sdast/GAINresults.html. 4.If the gain correction step fails then take a look at the gain history table. Gain correction failure is often signaled by all corrected events having a non-zero STATUS value due to bad gain determination (64). If the gain history for your revolution shows multiple switch on/offs, this may be confusing j_cor_gain. Then remove all gain history values up to the switch on/off just before your SCW being analyzed. For help fitting data in these complicated revolutions contact Dr. Carol Anne Oxborrow at oxborrow@dnsc.dk. 5.The source coordinates found by j_ima_iros may deviate a little from the true positions and this can occasionally cause inaccurate flux reconstructions from j_src_spectra or j_src_lc. If a good source position is available, it is better to force these coordinates by use of a user catalogue. An example is given in the cookbook. 6.Spectra and lightcurves from weak sources when there is one or more strong sources in the FOV may be contaminated with counts from these strong sources. This happens because the source extraction does not take into account the presence of the other sources. 7.If detection is forced for more sources than the maximum number of sources passed to j_ima_iros by the parameter 'maxNumSources', j_ima_iros will be confused and will produce random results. 8.There is no tool in OSA6 to detect sources in JEM-X mosaics. There exists, however, an offline tool "j_ima_src_locator" in a beta version that can be obtained from ISDC or from N.J.Westergaard (njw@dsnc.dk) that will perform the task. 9.If you mix FULL and REST data then be sure to give chanMin/Max that match REST channel limits, for example: chanMin: 64 128 160 192 chanMax: 127 159 191 223 10.The hidden timeStart and timeStop parameters (that allow the user to defined a subset of data for a given ScW) can not be properly set using the GUI. The GUI rounds the parameter settings to the second decimal. The user should set them running the scripts in command line. 11.When generating rebinned response matrices with 'rbnrmf', you may get the following error message: > ** rbnrmf 4.5.3 > ** Memory Alloc Verification Warning: Upper, inner guard > element modified > ** 272696 4 256 1 > ERROR - rbnr_comp 3.2.4: Failed to deallocate Dynamic Memory > ERROR - rbnrmf 4.5.3: returning from rbnr_comp > ERROR - rbnrmf 4.5.3: INCOMPLETE EXECUTION > ** rbnrmf 4.5.3 stop > rbnrmf 4.5.3 : FAILED (Details may differ slightly). In spite of the error message, a response file is produced, which is very close to the correct rebinned matrix, but not identical. For all practical purposes, the response matrix generated is good enough. However, a fix exists and will be included in the next HEADAS release. In the mean time, the overly cautious may download a patched version of 'rbnrmf' from: http://isdc.unige.ch/?Soft+download --- OMC --- 1.The automatic extraction of fluxes and magnitudes produce reliable results only for point-like sources. 2.If the source coordinates are inaccurate by more than 2 OMC pixels (~35"), the software analysis will not be able to re-centre the target and the derived fluxes and magnitudes obtained with default analysis parameters will not be correct. 3.For extended sources or high energy source counterparts with large uncertainties in their position, the OMC planning assigns multiple adjacent sub-windows to cover the whole area. In that case, multiple boxes are found with different ranks but with the same OMC_ID. These adjacent sub-windows will not be analyzed correctly by using the default analysis parameters as the software treats each box individually. The photometric extraction has to be done off-line, setting the corresponding analysis parameters to force the use of the WCS position in the centroiding algorithm. The flux will be extracted at the source position given in the OMC Input Catalogue. 4.If another star is within a few pixels of the source of interest, it can introduce systematic errors in the derived fluxes and magnitudes. The strength of this effect can be different for different pointings, since the relative position in the sub-windows will slightly change for different rotation angles. 5.Since OSA 4.0, the detection of saturated sources has been improved significantly. However, some of the bright sources slightly saturating one or few pixels might not be detected as saturated sources. As a consequence, their derived magnitudes are not correctly computed. The observer should check whether the source might be saturating the CCD for a given integration time, and reanalyze the data rejecting the shots with the longest integration times. 6.Due to thermoelastic deformations, the alignment of the OMC optical axis with the S/C attitude reference (after correcting the OMC misalignment) may diverge by up to 30" (~2 pix). From OSA 5.0 onwards, the derived coordinates are corrected at the time of computing the WCS support by using the photometric reference stars, giving an accuracy better than 2" in most cases.