ObsCore for velocity cubes

[Andreas Wicenec]

Hi James,

that is a good suggestion. The usage of velocity vs. frequency is mostly use case/user driven. The original measurements are in frequency and in some cases the conversion from one to the other is not straight forward, again mostly dependent on the use case, in which case we end up having 'pure' velocity cubes. Thus encoding both might work for some, but not for others. The other thing to consider is the rest-frame, since quite often these velocity cubes are used for studies of local dynamic effects, like galaxy rotation curves, in which case the zero point is set to some estimate of the galaxies cosmological velocity (RESTFREQa). Now, obviously all of this is limited to just radial velocities, while in fact we are dealing with velocity vectors. To cover that we are using proper motion and parallax to describe apparent and intrinsic velocity on the sphere and in addition line-of-sight velocity to capture the intrinsic and apparent radial movement. Taken together, we end up in a set of vectors and probably frames. For a naive user the proposed description is probably sufficient, for actual scientific use of multiple of such cubes, quite a bit more information is required. Thus probably just a good start....

Cheers,
Andreas
________________________________
From: dal <dal-bounces at ivoa.net> on behalf of Dempsey, James (IM&T, Black Mountain) <James.Dempsey at csiro.au>
Sent: Thursday, 16 February 2023 7:20 AM
To: Alberto Casa Micol <amicol at eso.org>; dal at ivoa.net <dal at ivoa.net>
Subject: Re: ObsCore for velocity cubes


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/20230216/c4d273e8/attachment-0001.htm>