i INTEGRAL Science Data Center (ISDC) =================================== http://isdc.unige.ch Known issues ============ Package: OSA Version: 7.0 Rel. Date: 15-Sep-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 currently archived data. 2.Values of parameters of "real" type with more than 7 digits are handled badly by the GUIs. This can lead to errors when the analysis scripts are run. In particular, using the JEM-X GUI, if the user wants to enter timeStart and timeStop values through the GUI, the precision is not sufficient. To avoid this problem, the user can save the parameters with the "Save" button of the GUI, edit the parameters file to enter the real values with the desired precision and run the script from the command line. This is a ROOT problem which will be solved in a future OSA release. 3.The 64-bit port should be treated as a beta because the testing of the 64-bit is not as extensive as the 32-bit one. The 32-bit will run correctly on a 64-bit system. ---- IBIS ---- ISGRI ***** 1.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). 2.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. 3.Secondary lobes of strong very-off-axis sources are sometimes not fully corrected/cleaned in reconstructed images. 4.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. 5.In general, a safe lower limit for the response is 18 keV. 6.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 7.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 8.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. 9.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. --- 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 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 8.The flux determination in j_ima_iros of OSA7 is not satisfactory and users are urged to get the flux from the images by the mosaic_spec tool. 9.In the OSA7 version of j_ima_iros the reported source position in JMXi-SRCL-RES in columns RA_OBJ and DEC_OBJ will always be the one found by j_ima_iros. There are columns (from OSA7) RA_CAT and DEC_CAT that reflect the catalog position if a user catalog has been defined. The SPE and LCR levels will read the RA_OBJ and DEC_OBJ columns and do the extraction using those. In order to force the use of the catalog positions -- which is recommended -- the JMXi-SRCL-RES table must be manipulated e.g. by an ftool, to update columns RA_OBJ and DEC_OBJ. --- 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. From OSA 6.0 onwards these adjacent sub-windows can be correctly analyzed by using IMA_wcsFlag=yes (default in OSA 7.0). In this case, o_src_get_fluxes creates a virtual 11x11 pixel sub-window inside the whole area centred at the source position. After that, OSA works on this new sub-window and ignores the previous sub-windows mosaic. This is an internal software trick, these virtual sub-windows do not exist as standard sub-windows (o_ima_build, for example, will not create these virtual sub-windows as 11x11 pixel images). Note that with IMA_wcsFlag=no, these adjacent sub-windows will not be analyzed correctly as the software treats each box individually. 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.