Appendix B: response table

[bkhelifi]

With the current preliminary proposal, there is already an issue in the definition of the collumns resp_s_ra and resp_s_dec.
They are not pertinant for instruments like HAWC, SWGO, LHAASO, KM3NeT, IceCube. These intruments are not pointing instruments, ie they are fixed and looking at the zenith or the anti-zenith. So, Ra/Dec has just no meaning!
These 2 columns should be optional.

[loumir]

or can be NULL if not applicable .

[iannevans]

I have to agree with Bruno, but for different reasons ;-). Ra and dec generally have nothing to do with response functions, other than that they typically apply to a specific location in detector coordinates (and pulse height, time, ... ) that will map to an ra and dec, assuming the instrument is following the sky. But if telescope was pointing at the same Alt/Az on the sky some time latter and everything else was time invariant (which we know it isn't but let's pretend) then the response functions would be unchanged but the ra and dec would be different. That is why I have tried to point out that the columns needed for the response functions are really telescope/instrument (and perhaps atmosphere) dependent, and also depend on the type of response function.

[loumir]

If s_ra and s_dec are not applicable to response function in general, and more related to the instrument configuration, then it is definitely a bad candidate to be exposed in the ivoa.obscore table where a common frame in terms of units, and axes is made mandatory.
Taking into account the variability of configurations among projects, we can then focus the search for response by the obs_id or obs_publisher_did , and the response table can be very short.

[iannevans]

If s_ra and s_dec are not applicable to response function in general, and more related to the instrument configuration, then it is definitely a bad candidate to be exposed in the ivoa.obscore table where a common frame in terms of units, and axes is made mandatory.

Not exactly. Here we need to differentiate between response functions in a generic sense and response functions applied to a specific dataset.

Let me try to illustrate this in terms of the Chandra point spread function (this is fully generalizable but the psf example is fairly straightforward).

The Chandra psf varies strongly with off-axis, theta, and azimuthal angle, phi, (which are defined relative to the telescope optical axis and spacecraft +Z axis) across the field of view, and also with energy and (much more slowly) with epoch. For simplicity let's consider the monochromatic point spread function for a given energy and epoch. If you want to independently identify the psf that applies at a particular location in the field of view of the detector, then you would need to compute the (theta, phi) of that location in the field of view, and search for a psf that matches that (theta, phi). That psf will apply (remember we're assuming a given energy and epoch here) to that (theta, phi) for all observations, irrespective of the actual (ra, dec) that maps to (theta, phi). The (ra, dec) that maps to (theta, phi) will vary depending on the pointing and roll angle of the telescope.

However, if I apply that psf to a specific observation, then there will be a specific (ra, dec) that maps to (theta, phi) and so one can define the ivoa.obscore spatial information for the psf in that case.

Now if I remove the constraints of a monochromatic psf for a given energy and epoch, for Chandra things get more complex. In this case, since the psf varies with energy, the actual psf in a defined energy band (such as 500 eV to 2 keV) depends on the spectrum of the source being observed and also on the variation of the effective area of the telescope/instrument/detector with energy (the ARF). The latter varies across the field of view and is a much stronger function of epoch. Because of this additional complexity, for Chandra we explicitly compute psfs for each energy band for each detection within each observation. This means that we can uniquely identify the relevant ivoa.obscore spatial/spectral/temporal information for each psf and can in principle query psfs based on those properties. (Given the one-to-one mapping between a detection in a given energy band in a given observation and the psf one could also use DataLink to an appropriate other product to serve the psf - and in fact that is probably what we will end up doing.)

If we didn't have that additional complexity, however, then we could use the same psf for any observations at the appropriate (theta, phi).

Historically, response functions may have been less well determined. In which case one might serve a single response function that could be applied to multiple datasets (and those response functions will mostly depend on the telescope/instrument properties). However, as instruments have become more sophisticated and computing power has increased, response functions these days tend to be computed explicitly for the conditions of a single observation (and a single location within the observation when needed). In these cases there will be a one-to-one mapping that allows the responses to be tied to specific ivoa.obscore spatial/spectral/temporal values. But because of that one-to-one mapping the benefit of using an ivoa.response table is much less in this case.