INTEGRAL Science Data Center (ISDC)
===================================
http://www.isdc.unige.ch/integral
Known issues
============
Package: OSA
Version: 8.0
Rel. Date: 31-Aug-2009
-------
General
-------
1.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 values will be truncated if, after you edited the fields,
you close and reopen the hidden parameter window. Therefore, in
case you want to enter accurate time constraints, make sure you
reenter the timeStart and timeStop values eachtime you have to
reopen this window.
----
IBIS
----
ISGRI
*****
1.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.
2.Secondary lobes of strong very-off-axis sources are sometimes
not fully corrected/cleaned in reconstructed images.
3.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.
4.In general, a safe lower limit for the response is 18 keV.
5. A problem on-board IBIS causes event times to be shifted by 2
seconds under some circumstances (this is rare). The software
tries to correct the data. The keyword TIMECORR found in the
event files (*-*-ALL or *-*PRP extensions), indicates whether the
correction was done. If you are doing an accurate timing analysis
and your data contains TIMECORR>0 please take great care: If
TIMECORR=3D1 or 2, the applied correction should be OK. If
TIMECORR=3D3 you should better not use these data. If
TIMECORR=3D4 contact ISDC
6.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 there is a
minimum usable time bin. The time bin must be such that the
total number of maps in the file isgr-corr-shad does not exceed
2 GB worth of disk space. The product of the number of time bins
in a science window, and the number of energy bands must be less
than about 9942.
7.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.
8.ii_pif will crash if the input catalog inCat contains more than
500 sources.
9.When extracting spectrum with very fine bins (~1 keV) there
could be artificial wiggles created by a suboptimal interpolation
of the energy dependance of some corrections. Next OSA will fix
this issue. For the time being you have to limit yourself to bin
compatible with energy resolution (~ 2keV).
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. A further one will be delivered in the next
release to cope with failure of detector 5. The
spi_science_analysis pipeline 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). Another option is the use of spimodfit_analysis
which correctly handles different response files.
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. The spimodfit_analysis pipeline underwent severe
failures when staring pointings are included in the analysis, we
therefore suggest to avoid their inclusion.
5.Using the new spimodfit_anlysis, if a pointing list has about
one thousand entries, we sometimes experienced a software crash
with the default parameters. The crash is due to a failure in
the convergence of the fitting routines. In these cases the user
should try to reduce the number of free parameters by
e.g. changing the setting of background multipliers or the
background time variability scale.
-----
JEM-X
-----
1.The JEMX lightcurves are deadtime corrected. DEADC in the
lightcurve files are set to 1.0 (for XRONOS compatibility). (but
see also Issue no. 7).
2.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.
3.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.
4.The source coordinates found by j_ima_iros may deviate a little
from the true positions and this can occasionally cause
inaccurate flux reconstructions. 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.
5.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. This is
not true anymore for spectral extraction, whatever the method
used.
6.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
7.Light curve extraction is unchanged in OSA 8 compared to OSA 7
in order to allow the easy generation of short-bin light
curves. However, long-term stability is not assured in this case;
the user interested in long-term light curves or who doesn't need
time bins shorter than the length of a science window is advised
to generate light curves from the imaging step, as explained in
the cook book.
8.j_ima_iros may occasionally exit with a floating point
exception when there are too few photons in the
shadowgram. Normally, increasing the size of energy bins or
lengthening the duration of the user GTIs (if possible) should
solve the problem.
---
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.
|
