
Date: Wed, 09 May 2001 09:33:45 +0200
From: Soren Brandt <sb@dsri.dk>
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Kretschmar <peter.kretschmar@obs.unige.ch>
CC: Stefan Larsson <stefan@astro.su.se>, nl@dsri.dk, oxborrow@dsri.dk, allan@dsri.dk, njw@dsri.dk, juhani.huovelin@astro.helsinki.fi, smaisala@astro.helsinki.fi
Subject: Re: AI18.11 REST data binning
Content-Transfer-Encoding: 8bit

Peter,

Everybody prefers even bins.... if possible.
However we may also keep an eye on the context of resticted imaging.
It will/should mainly be used in cases where you are observing a fairly
bright source (otherwise you would use full imaging). There may then be
additional weaker sources present as well (this is the reason to prefer
res. imaging over non-imaging formats). Once you have analysed the 
res. imaging observation you will have lightcurves for all significant
sources in the FOV with slightly variable binning. It may the be
convenient
to resample these on an even scale, but you loose information, no way
around it. So to preserve the maximum info the binning is uneven.

Next step is the clever analysis of variations on shorter time scales
than the res. image integration time. That is where the count rate data
with 1/8 sec (even) sampling come in. If you see a significant increase
in
the image lightcurve for one (the brightest) source, you may then
present
arguments derived from the count rate data about the finer details.
The good example I can think of is the detection of an X-ray burst from 
one of the sources. The shape of an X-ray burst is then clear from the
countrate data and the identification of the suspect is done from the
imaging. 
But this "clever" analysis should be left to the user, who can then
extract the maximum possible information from the data. If the user
is served resampled lightcurves he will have to redo everything himself.

Sorry, if this was just repeating obvious facts.

Sren
  

Peter Kretschmar wrote:
> 
> Stefan Larsson wrote:
> >
> > So, its time for REST again!  (REST data binning that is).
> >
> > I'd like to adress again the following points:
> >
> > 1) From Peter's and Srens mails I conclude that adding a TIMEDEL
> >    column to the restricted event data (JMXi-REST-PRP i guess) is a solution
> >    we can all accept?  (it is what I was asking for anyway).
> >
>   It is acceptable but will mean quite a bit of changes here which I first
> need to get accepted by the CCB (Configuration Control Board) of ISDC.
> So please do not yet rewrite your code to depend on this! Also it will
> be some time before we have test data with this column set.
> 
> => Please deliver your tools without including access to this column,
>    and note the possible problems for REST data as a known bug. We can
>    see if we get this sorted out in June, otherwise it will be corrected
>    later. We anyway have several more months to correct bugs and other
>    problems, once we have a complete analysis chain.
> 
> > 2) The second point is the time binning of output data. Either,
> >         A) Original (= raw data),         => non-even sampling
> >         or
> >         B) Rebinned into equaly long bin  => even sampling
> >
> > The question is: WHAT DOES THE OBSERVER WANT? Original bins or even bins?
> >
>   I prefer even bins.
> 
> > Maybe it should be an option?
> >
>   Probably. Again we should most probably _not_ start to implement this
> right now.
> 
>   regards,
>   Peter

-- 
 ------------------------------------------------------------
| Soeren Brandt                     Tel.:      +45 3532 5710 |
| Danish Space Research Institute   Secretary: +45 3532 5700 |
| Juliane Maries Vej 30             Fax :      +45 3536 2475 |
| DK-2100 Copenhagen Oe             E-mail:     sb@dsri.dk   |
| Denmark                                      www.dsri.dk   |
 ------------------------------------------------------------
