ObsCore for velocity cubes

[Arnold Rots]

FWIW, this all would have been simpler if the redshift and spectral
coordinates has been retained in the coordinate system model.
Just an observation...

Arnold H Rots

Research Associate

SAO/HEAD

Center for Astrophysics | Harvard & Smithsonian

Email: arots at cfa.harvard.edu

Office: +1 617 496 7701 | Cell: +1 617 721 6756

60 Garden Street | MS 69 | Cambridge, MA 02138 | USA


cfa.harvard.edu | Facebook <http://cfa.harvard.edu/facebook> | Twitter
<http://cfa.harvard.edu/twitter> | YouTube <http://cfa.harvard.edu/youtube>
| Newsletter <http://cfa.harvard.edu/newsletter>


On Wed, Feb 15, 2023 at 9:10 PM Andreas Wicenec <andreas.wicenec at uwa.edu.au>
wrote:

> 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  |  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/98ec3016/attachment-0001.htm>