Subject: Re: Thoughts on an improved spectral extraction procedure


   Hi Niels,

   thanks for the extensive discussion, here are a few quick comments
from my side more on 'structural' matters as usual:

Niels Lund wrote:
> [...]
> So, to extract the spectrum from a given source, we will as before 
> need to extract a source count spectrum and a background spectrum 
> from each science window, but in addition we will need to calculate
> a response function corresponding to the specific position of the
> source for this science window. This response function need to be
> carried along in the analysis and combined with response functions
> from other science windows where this source has been observed.
> 
   As long as the "response function" can be expressed as effective
area (ARF) this is fully supported by existing software. The original
design was indeed to write out one 'aperture reponse function' per
source and Science Window and all the framework exists. Currently
it is just filled with a default ARF everywhere as for Stefan's
treatment of the problem it worked finally better to correct the
spectra instead.

   The tricky problem to solve is to calculate these ARFs correctly
instead of just multiplyin an on-axis ARF with a single vignetting
factor as we did in the beginning.

   In my opinion the calculation of this function should be possible
in the SPE(ctral extraction) step, independently of the image analysis.

> [...]
> 
> The response functions for the different science windows must be added
> with a weight factor for each function corresponding to effective
> observation time for the associated science window. The response
> functions can include the effective number of cm2 illuminated by the
> specific source, or the response functions can be normalized to unity
> and the number of cm2 must then be carried as a separate parameter.
> 
   Again, this exists already, with spe_pick summing ARFs weighed by
EXPOSURE (from memory). ARFs are by OGIP standards in cm^2. We should
keep to the standards even if it is a bit less elegant for us. One
of the mistakes I've made in the past (we all did) is to favor a
'nicer' programming interface over a structure in terms widely known
to users.

   One caveat is that I'm not sure what you are writing does not
indicate we need a different _RMF_ for each source and Science Window.
In this case we would need to discuss how to store these and have
them added correctly and efficiently. It's surely doable but thre
would be more work ahead.


> *** Consequenses for sky images
> 
> [...] 
> At the present time we have delivered 51 different vignetting maps 
> corresponding to 51 different radius selections. This is probably
> an overkill - 99 % of the users will never even consider to change
> the radius limits from their default values.
> 
> So we can probably reduce the number of radius values to maybe 8 and 
> then introduce 12 energy bands (making for 8x12 maps). [...]

   Playing the "unfriendly advisor" Soren tells me to be :-)
it seems to me that these numbers are rather arbitrary.
What was the motivation for having 51 radii? How would one spread
the 8 values - why 8 and not 10 or 6? My feeling is, btw, that
if users play with the radius they would do so ina range of 3-5 degrees,
so maybe that range needs finer sampling than very small values.
Is there any sort of study ongoing to motivate the choice of
intervals and radius ranges?

   Let's keep the ball rolling ...
   Peter