Where should Redshift/RV be stored on Spectrum objects, and how to transform between different forms - RV(opt)/RV(rad)

[SaOgaz]

original card by @keflavich

[stscijgbot]

This ticket is now being tracked at JDAT-7

[ibusko]

To implement this without solving the idiom issue at #455 probably means we should do it in a top-level function in the spectrum1d.pymodule. We can later move it to wherever we decide the redshift/rv info should be stored.
The conversion will certainly be using the already existing Spectrum1D parameters rest_value and velocity_convention. What are these exactly? Is rest_value a scalar or a 1-D array? Is velocity_convention just a way to tell the difference between frequency and wavelength definitions? I bet there is more than that. What doppler_relativistic means in this context?

[nmearl]

rest_value is the wavelength used in the velocity conversions (e.g. wavelength -> velocity conversions will result in dramatically different dispersions depending on which wavelength is considered the rest wavelength).

Is velocity_convention just a way to tell the difference between frequency and wavelength definitions?

No, velocity_convention defines which of the three velocity conventions to use in a dispersion conversion (radio, optical, relativistic). Each uses a different formula.

[ibusko]

Aren't radio and optical essentially the same conversion? The differences in between the formulae of these two have to do with spectral axis units, but for the non-relativistic approximation, the formulae perform the same operation. Or am I missing something?

Maybe we need a clarification on the purpose of this translation. Is it meant to generate a velocity axis in velocity units, against which the spectrum data can be paired? Is it meant to generate a rest spectral axis in wavelength/frequency units? Or something else?

This discussion would probably benefit from work done under #455

[keflavich]

No, the optical and radio conventions use different equations:
http://docs.astropy.org/en/stable/api/astropy.units.equivalencies.doppler_optical.html
http://docs.astropy.org/en/stable/api/astropy.units.equivalencies.doppler_radio.html
http://docs.astropy.org/en/stable/api/astropy.units.equivalencies.doppler_relativistic.html

[nmearl]

Aren't radio and optical essentially the same conversion?

No. The differences in the formulas should be obvious below:

Radio:

Optical:

Relativistic:

The differences in between the formulae of these two have to do with spectral axis units

I don't know what you mean by this; all of the formulas expect a dispersion in frequency (or wavelength) space and produce a spectral axis in velocity space.

The purpose of the velocity convention is how to convert the spectral axis from frequency or wavelength space to one in velocity space (or the reverse). Depending on your needs and the characteristics of the observation, you'll use a different convention. E.g. Optical velocities are commonly used for (Helio/Barycentric) extragalactic observations; (LSR) radio velocities are typical for Galactic observations.

[ibusko]

OK, thanks for the references, it's clearer now. Do you guys agree that a top-level function is the way to go for now? I envision a function that has as input a (properly initialized) Spectrum1D object, and returns the velocity vector, a numpy Quantity array.

Are there use cases where one would benefit with the reverse translation as well (velocity->w/f/e)?

[nmearl]

I'm not sure what you mean. Specutils already supports converting to velocity space by simply calling my_spectrum.velocity. This internally uses the defined velocity convention. The rest value is already stored on the Spectrum1D object, and velocity convention can be changed by calling the with_velocity_convention method. However, the reverse is currently not implemented: i.e. you can't initialize a spectrum object with a velocity dispersion and have my_spectrum.wavelength/my_spectrum.frequency convert from it.

The only thing specutils does not handle currently is redshifting.

[ibusko]

Ah, OK, I was confused because I was looking at the code in spectrum1d.py, while the relevant machinery already exists in spectrum_mixin.py

[ibusko]

I assume from the title that this is supposed to handle both redshift (a-dimensional), and radial velocity (quantity with velocity units). Any ideas on how to implement the distinction in a user friendly way?
I though initially that a single redshift_rv keyword parameter in the Spectrum1D constructor would suffice. The user would provide either a float or a Quantity to tell apart one from the other. But it has the drawback of being error-prone, in the sense that users would often forget to create a proper Quantity instance when intending to use radial velocity, and that would result in weird results (and not an error or exception).

[eteq]

Note: I think the direction that things are going to go for this is to have the spectral_axis be a SpectralCoord object, which is something we've realized needs to live in astropy because it's also needed in WCS's. There already are rules for doing this translation that apply in the wcs context, and we want to be sure we use the same machinery in specutils as we do elsewhere.

That said, we can still keep this issue open for the specutils side of things. Once the SpectralCoord has this implemented we might decide we want to add some conveniences to make it a bit easier on the user side like what @ibusko is suggesting. (E.g. Spectrum1D.redshift_rv could be a property that defers to Spectrum1D.spectral_axis.redshift or similar) and this issue would still track that.

[nmearl]

SpectralCoord has been implemented with appropriate handling for redshifting and radial velocities.