
Date: Tue, 8 May 2001 15:15:28 +0200 (MET DST)
From: Stefan Larsson <stefan@astro.su.se>
Subject: Re: AI18.11 REST data binning
To: Peter.Kretschmar@obs.unige.ch, sb@dsri.dk
Cc: nl@dsri.dk, oxborrow@dsri.dk, allan@dsri.dk, njw@dsri.dk, juhani.huovelin@astro.helsinki.fi, smaisala@astro.helsinki.fi
MIME-Version: 1.0
Content-MD5: WhM+xszb9MbZXiNvasduGA==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by uhuru.dsri.dk id PAA08912


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).
   
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
	
Concider Peter's illustration:

> user time bins:         |____|____|____|____|____|____|____|____|
> 
> restricted images:     |......|......|........|.....|.......|...
> 
> const. grey filter:   ===|=================|===|=======|========


In case A) our software will use the TIMEDEL info to make necessary
corrections (grey, deadtime) and store output data with one time bin
per restricted image.

In case B) our software will use the TIMEDEL info to make necessary
corrections (grey, deadtime) and after that rebin to specified
equal bins.

The question is: WHAT DOES THE OBSERVER WANT? Original bins or even bins?

Maybe it should be an option?

Best regards,

Stefan




>From Peter's reply to Sren on 3 May 2001
> 
> > I am again back to the
> > point about the keyword in the header with the timing accuracy
> > info needing to be a column.
> 
>   This is a good point and I have taken note to update the templates
> after discussion with the other instrument interfaces to make sure we
> all do similar things.  So for REST data this TIMEDEL column should
> be set to the length of image time interval given in the TM?
> 
> > If you are treating position and spectral data from res. im. and
> > there is a variation in the grey filter, then the effective/average
> > grey filter for that integration time must be calculated and that
> > will be valid for that period. The details about when the change
> > happened is used for that, but for treating the data all events in
> > one image are equal.
> > 
> 
>   This is the core of the discussion. Assume a user building a
> lightcurve for an individual source from REST data with user
> selected time bins not commensurate with the binning of the images.
> 
> user time bins:         |____|____|____|____|____|____|____|____|
> 
> restricted images:     |......|......|........|.....|.......|...
> 
> const. grey filter:   ===|=================|===|=======|========
> 
> 
> For normal events with real time information one calculates average
> correction factors over the time intervals set by the user and applies
> these to the binned events. For REST events, the correct way to go 
> would be to first calculate averaged factors and fluxes for each REST 
> image and then splitting them over the output bins. 
> 
>   If we decide that for REST events lightcurve and time resolved
> spectra temporal bins are always by the times of the images themselves
> (Stefan's proposal) then we avoid the splitting but leave the user
> little choices. Note that this is in conflict with an old software
> requirement about treating all events equally.
> 
>   My (somewhat sloppy) proposal was that if REST events got random
> times assigned - maybe only internally in the executables - then
> we could treat them just like other events for the rest of the processing
> without introducing a significant error. 
> 
>   So please let me know:
> - Is (internal) randomization of REST event times too sloppy to make sense?
> - Would you prefer to have the natural time bins of REST data instead of
>   the user defined ones possible for other event types?




