
Date: Thu, 03 May 2001 11:39:12 +0200
From: Peter Kretschmar <peter.kretschmar@obs.unige.ch>
Subject: Re: AI18.11 REST data binning
To: Soren Brandt <sb@dsri.dk>
Cc: Westergaard Niels Jorgen <njw@dsri.dk>, Larsson Stefan <stefan@astro.su.se>, Oxborrow Carol Anne <oxborrow@dsri.dk>, Maisala Sami Petri <Sami.Maisala@astro.Helsinki.fi>
MIME-version: 1.0
Content-transfer-encoding: 8BIT
X-Accept-Language: de,fr


  Hi Sren,

Soren Brandt wrote:
> 
> I certainly don't like the concept of artificially assigning times
> to events, if these times are written to files. 

  OK, but we already assign individual times (though all events of an
Resrtricted Image get the same one) to the REST events, due to a
Software Requirement from the JEM-X team.

> It may be used
> internally in a routine as a tool to calculate averages.
> Downstream sw may then think they are real in the sense that the
> timing info is more accurate than it is. 

  I see the point, but consider the risk relatively low since any
downstream software must understand about the various event types
anyway to make sense out of our data. Nevertheless, you are right
that there would be the danger of confusion if we just stored
artificially smeared times for REST events.

> 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?

  Regards,
  Peter
