INTEGRAL Science Data Centre (ISDC)
===================================
http://www.isdc.unige.ch/integral
Known issues
============
Package: OSA
Version: 10.2
Rel. Date: 10-Dec-2015
-------
General
-------
1. Values of parameters of "real" type with more than 7 digits are
handled badly by the Graphical User Interface (GUI). 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 each time you have to reopen this window.
2. The "spe_pick" executable combining spectra of several science
windows does not properly write the source position in the header
of the resulting file.
----
IBIS
----
ISGRI
*****
1. Systematic uncertainties of 1% should be added to ISGRI counts,
fluxes.
2. In the mosaic built 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. The maximum number of sources handled by ii_spectra_extract is 200
but it is strongly recommended to only fit spectra of the sources
that are effectively active (visible, detectable) during the
Science Window.
4. With OSA10.2, updated calibration files have been produced
including a correction for the variation of gain across the entire
mission. The secular drift observed in all bands over the mission
life-time is known and due to the evolution of gain: this effect is
accounted for by the set of ARFs available in the IC tree. However,
on single revolution time scale, a drift in counts is still
observed. For the latest part of the mission, spectra extracted at
the beginning and end of a same revolution can therefore show a
difference in counts of instrumental origin.
5. The position of the low-energy threshold is increasing with time.
A safe lower limit for the response is 18 keV until revolution
848. Between revolutions 848-1090, we recommend to ignore data
below 20 keV. From revolutions 1090 on, we recommend the user to
ignore data below 22 keV.
6. 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=1 or 2, the applied correction should be OK. If
TIMECORR=3 you should better not use these data. 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 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.
8. ii_pif will crash if the input catalog inCat contains more than
500 sources.
9. At large off-axis angles the IBIS response is not well known and
strongly energy dependent. Therefore, the user should be careful
when analyzing observations performed at large off-axis angles,
above ~12 degrees, since systematic flux variations might be
introduced. The systematic flux variations are energy dependent,
and therefore the user should be careful both with photometric and
spectral analysis of sources at large off-axis angles.
10. In a few isolated cases, for bright sources with an energy
spectrum different from a power-law and bright sources, a tension
between the SPI and IBIS spectra can be noticed, especially in the
late part of the mission and for the energy range below ~50 keV.
This is mainly due to an evolution of the instrument energy
redistribution, which is currently under investigation.
PICsIT
******
1. The spectra extraction with the 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.
3. Different instrumental responses are now included in our system,
characterizing SPI before, between, and after, the detector 2, 17,
5, and 1 failures. The spi_science_analysis pipeline cannot
currently handle a time variable response. The easiest is to
analysis the possible cases independently (our software then selects
automatically the appropriate response), and to combine the results
later on. It is possible however, to analysis 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). The spimodfit analysis can instead handle multiple
responses which are appropriately used during the data processing.
The final response accounts for the multiple responses accordingly.
4. The "spiros" imaging software is quite a complex tool with many
different options and parameters. Not all possible cases have been
fully scientifically validated. The best tested modes include
"imaging" and "spectral extraction". Other modes such as "timing"
and "spectral timing" and other background methods are being further
tested and validated. The spimodfit software is an on-going project
which has now reached a stable configuration, but not all the
features have been scientifically tested.
5. 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.
6. The "spiros" lightcurve production has shown some crashes when
running large data-sets and a time binning of one ore more days is
selected. The program handles correctly a resolution of one Science
Window, however, so the user is encouraged to use this finer time
binning and merge the results afterwards in case he/she finds
similar problems during the analysis of a long data-set.
7. "spimodfit" handles time variability through the use of splines.
The spline order can be 0 to 5, 0 corresponding to a piecewise
constant function (with one scaling parameter per interval) and 3
corresponding to cubic splines. In many cases, when using n-order
splines (with n equal or greater than 1), the fitting algorithm
fails to find the optimal parameters. This is thought to be due to
over-parametrized time variability because of the additional
parameters of the splines. In addition, crashes of "spimodfit" have
been reported when using a large dataset, with about 1000 pointings
or more, their origin is still unclear and is under investigation.
-----
JEM-X
-----
1. The JEMX lightcurves are deadtime corrected. DEADC in the
lightcurve files are set to 1.0 (for XRONOS compatibility). s(but
see also Issue no. 7).
2. Due to changes of the on-board configuration, the detection
efficiency has changed significantly several times during the
mission history. In particular for pointings between revolutions 26
to 45, 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/cm^2/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 temporarily shut down for e.g. 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://outer.space.dtu.dk/users/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@space.dtu.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. 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 (but see also
point 8 below).
6. Lightcurves from weak sources may be contaminated with counts from
stronger sources in the FOV. 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. In OSA 7.0 and later, the source position reported in columns
RA_OBJ and DEC_OBJ of JMXi-SRCL-RES will always be the one found by
j_ima_iros. Columns RA_CAT and DEC_CAT 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.
9. Light curve extraction is unchanged in OSA 10 compared to previous
versions 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.
10. It has been noticed that in mosaics of JEM-X images a plus-like
depression in the background around certain sources can occur.
This can happen for sources that are too weak to be noticed in the
search for sources in the individual science windows. The cleaning
process excludes (known) source areas. It operates horizontally
and vertically since the systematics are strongest in these
directions. However, adding many images can amplify the effect of
an unnoticed source since the distribution of position angles is
quite narrow, in particular for the sources near the galactic
center, which is also where the probability to find a source in
the depression caused by a neighboring source is highest. If a
source is situated in such an indentation its peaksize is reduced
accordingly, whereas there is no change for the source causing the
feature. This is solely an image feature so j_ima_iros flux
determinations are unaltered.
11. A count-limiting mechanism, the grey filter, is actived when
sources corresponding to more than 0.75 Crab on-axis are in the
field of view. The grey filter is adjusting itself automatically,
according to the rate of events accepted as X-rays and the filling
level of the onboard telemetry buffer. Ideally, a grey filter
should randomly reject events. However, the mechanism implemented
is only pseudo-random. Therefore some care should be taken in
interpreting power spectra of arrival times of events from very
bright sources with a very significant grey filter, as QPO
artifacts may show up. Normally, the automatic grey filter is
varying over a science window. This fortunately has the effect of
"averaging" out power spectra artifacts, as they are specific to
a particular grey filter setting. Therefore, if noticing transient
features in the power spectra of very strong sources it should be
checked if this is limited to a period of a specific grey filter
setting. Please check the User Manual for further explanations.
12. Since December 2015 (OSA10.2), there is a new instance of the
Instrument Model Group (IMOD files version 25) produced by the JEM-X
Team. The usage of these new IMOD files is highly recommended, and
will be automatic upon update of your copy of the Instrument
Characteristics files. The data (and in particular the countrates)
are fully reliable between 3-20 keV after 2003-08-11 (rev 100), and
in the range 5-20 keV for earlier observations.
13. For the time being it is not trustable to extract spectra of strong
sources with "mosaic_spec" from images obtained with the PIF option.
14. The flux of a given source can be obtained either with the "standard"
extraction or with mosaic_spec. In cases when the fluxes obtained
with the two methods differ, it is advised to consider the one
obtained from the standard extraction (SPE level).
15. When analysing very-Near Real Time data (i.e. within a few hours from
the data transmission to ground, and well before the entire
revolution is completed) JEM-X gain calibration might fail. This
happens when there are not enough data collected as yet to describe
the gain evolution for the current revolution. In this case we
suggest to run the analysis with parameter "COR_gainModel=2" to force
the use of a simplified fitting model. The default model
(COR_gainModel=-1) can be used again at revolution completion.
---
OMC
---
1. The automatic extraction of fluxes and magnitudes produce
reliable results only for point-like sources.
2. 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.
3. 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.
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.
|
