detection limit

[Douglas Tody]

Hi Francois -

I have always thought it was important to have this attribute; for 
global/multiwave use cases it is more important than exposure time for
example, although it serves a similar purpose.  However it can be
complex to provide, similar to converting photometric magnitudes to
fluxes.

Calling this the "resolution" of the observable axis is ok I guess.
Note it is closely related to the RMS of the background and is often
expressed that way instead.  We would want to define how these two
are related.  Unit probably Jansky.

I think it should be a "should" attribute (i.e., optional), due to the
difficulty of computation.  However it is highly desirable for many
data discovery use cases.

 	- Doug


On Thu, 7 Apr 2011, François Bonnarel wrote:

> Hi all,
> Going on with searching what kind of initial ObsTap driver use cases
> could have been forgotten I exhumated use case 3.1 and 5.2.  which
> requires some estimation of the detection limit. after discussing with
> Mireille, I decided to  ask everybody:
>
> For datasets we must be talking of "signal"  detection limit measured on
> the Observable axis, which cannot be confused with the detection limit on 
> sources
> magnitudes (or line flux) which implies flux integration on the flux area 
> convolved
> with the psf (lsf).
> The signal detection limit or inverse sensitivity for a given observation is
> defined as the minimal detectable difference of measured quantities
> along the observable axis. In case we are measuring a flux-related
> observable, it is the minimal detectable flux density difference,
> limited by the noise. In term of signal theory this is exactly the flux
> resolution.
>
> The utype attached to this attribute could then logically be:
> Char.observableAxis.resolution.refval, and the name o_detection_limit
>
> It will be sometimes difficult for  data managers to provide this field.
>
> QUESTION: do we implement this field as optional ? Will be described in 
> Annex
> in that case
>
> Cheers
> François
>
>