ObsCore for velocity cubes

[Dempsey, James (IM&T, Black Mountain)]

Hi Alberto,

At CASDA we support cutouts of velocity spectral line cubes.

We currently require the user to provide a BAND or CHANNEL parameter to the SODA service which is translated by the service to the velocity frame of the target cube. This works, but requiring conversions on both the client and server side isn’t ideal. Likewise, in our ObsCore implementation only the em_ucd indicates the cubes are in velocity but it would certainly be useful to have full velocity information for data discovery!

The extension you outline looks like it would work nicely for the same use case in CASDA. However I think we should add the following to fully describe the velocity axis (as opposed to its translation into wavelength for the base obscore).

  *   v_resolution – value of CDELT3 or CDELT4
  *   v_unit – although this should always be m/s

Another consideration is that a lot of our users tend to use velocity to interact with frequency cubes. So even for these frequency cubes we might end up filling in velocity metadata if the fields were defined. Tools such as CARTA tend to automatically show the spectral axis as velocity where it can, such that many users would assume the cubes are in velocity not frequency.

Cheers,
James Dempsey
Senior Developer  |  CSIRO
james.dempsey at csiro.au<mailto:james.dempsey at csiro.au>  |  02 6214 2912


From: dal <dal-bounces at ivoa.net> on behalf of alberto micol <amicol.ivoa at googlemail.com>
Date: Thursday, 16 February 2023 at 12:02 am
To: dal at ivoa.net <dal at ivoa.net>
Subject: ObsCore for velocity cubes
Dear ObsCorers,

I have received with much interest the ObsCore extension for RADIO data, thanks for that very clear document.

Would it be possible to have a similar extension for cubes with velocity as third axis (the other two being the usual spatial ones)?
Let me call them “velocity cubes”...

Here my use case…

At ESO we need to support cutouts of velocity cubes.

Up to now our SODA interface supported spectra, images, and wavelength cubes;
to provide the user with the SODA input parameters and their possible MIN/MAX values
we query ivoa.ObsCore.

Now with the introduction of velocity cubes, we would like to get the necessary SODA input params also from ObsCore.
We can certainly do so by extending our own ObsCore table (ObsCore allows to extend the table), but I was wondering
if others have similar needs, and see if we can agree with a common ObsCore extension.

Velocity cubes should come in a FITS format as described by Greisen et al, 2006, so-called Paper 3.
Shortly summarised, the velocity can be either:

     *   a radio (VRAD),
     *   an optical (VOPT),
     *   a relativistic velocity (ZOPT),
     *   a generic apparent velocity (VELO).
The RESTFRQa (RESTWAVa) keyword conveys the necessary reference frequency (wavelength) to transform velocity into frequency or wavelength.
The velocity unit is m/s.

SODA cutouts on the velocity axis are usually formulated by passing cuts already expressed in velocity
though it must be possible to perform the conversions to and from frequency/wavelength.

What would then be needed in ObsCore is:

v_min
v_max

but also, in case of radio velocity cube:
f_min
f_max (getting these from the RADIO extension)
f_rest = RESTFRQ

and, in case of a optical or relativistic velocity cube
em_rest = RESTWAV
(we already have em_min, em_max)

The em_resolv_power should then be set to:
 lambda                    freq                     c
 ———————  =  ————— = —————
 delta lambda           delta freq       2 * delta_v

where delta_v is the CD3_3 in the cube (in the example of a cube with the velocity on the third axis);
but I would also likely accept a v_pixel_scale (= delta_v).

The UCD for the velocity should then be:

spect.dopplerVeloc.opt

spect.dopplerVeloc.radio
unsure what it should be for the relativistic case.

This would allow us at ESO to implement SODA on top of ObsCore (as already done for all other parameters)
and would allow astronomer to search the velocity cubes with certain characteristics using ObsCore.

What do you think?
Is that doable? I think at ESO we will simply start implementing the above extra ObsCore parameters (unless you suggest different names for that),
while waiting to see if there is more interest to build a proper standard.

Eager to know what you think,
Cheers,
Alberto

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20230215/52bfe39f/attachment-0001.htm>