Add new module shift with gravitational redshift function

[tiagopereira]

Here is a suggestion to add a new module shift.py inside specutils.manipulation. This can serve as a place to put functions to perform changes in the spectral axis.

As a first function I added gravitational_redshift, to calculate the redshift due to gravity of a distant object. This is relevant for precision spectroscopy when comparing synthetic and observed spectra. The function assumes an observer on the surface of Earth, as I suspect it is of limited usefulness to make it general. But this should be straightforward to change, if needed. Currently the function only returns a scalar, but one can in the future write an interface for Spectrum1D or similar.

[eteq]

@tiagopereira - thanks for your idea here! One clarification before more review: this is certainly useful but it looks more like it's about computing the redshift/velocity shift, not actually manipulating spectra. I wonder if this means it's general enough to belong in core astropy? That is, the astropy.coordinates package has some functionality related to this already (e.g. the barycentric correction). Perhaps this should go there (or be integrated into the existing functions) and we should implement manipulation tools that work with that?

[tiagopereira]

Hi @eteq , you raise a good point. I didn't notice the coordinates module already had some tools for radial velocity corrections. The current code just gives a Doppler shift, which could easily be converted to line-of-sight velocity. I think this would be general enough for core astropy, but I'm not sure how to best include it in astropy.coordinates. While the gravitational redshift depends on the coordinates of the remote and observing bodies, it is a GR effect that results in photons gaining/losing energy. So this is not really a velocity correction, but more relevant for absolute wavelength calibration.

The current function does not manipulate spectra, but the idea is to have this (and other functions) manipulate the wavelength axis of spectra or the spectral intensity. For example, you can calculate a synthetic spectrum from a model atmosphere. To compare it with an observed spectrum, you need to add the star's gravitational redshift so that both spectra match. You can either transform the synthetic wavelength scale to account for the redshift, or you can keep the same wavelength array and interpolate the spectral data for the new positions. So the point of the shift.py module in specutils.manipulation was to have a place for such tools.

I'm happy to move the gravitational redshift part somewhere else if you think it's useful. Just let me know which location works best. Maybe something like SkyCoord.gravitational_redshift?

[nmearl]

@eteq, @tiagopereira was there ever consensus on where this should live? Currently, specutils's manipulation module is more concerned with manipulating spectral data, instead of dispersion information, which biases me (slightly) toward this being part of astropy.coordinates. However, I could be convinced either way.

[tiagopereira]

@nmearl I don't really mind. To me, it logically makes more sense in specutils since this is dealing with a wavelength calibration of spectra. But on the other hand, having it inside astropy seems better because it is more mature and more widely available.

It also seems that I accidentally deleted the fork where this was coming from (it's been so long that I forgot). Honestly, I've been reluctant to contribute more towards specutils because of the time it takes until the code is made widely available. My last PR was merged into master in February and it still hasn't been put into a release. It is too much work to ask students and collaborators to manually install from git, and so it just doesn't get used.

[nmearl]

@eteq is this still something we should attempt to put up in astropy proper?