astropy / astropy/specutils

Have spectralcoord allow multi-dimensional rv/observer/target

Open
#634 0 comments 0 reactions 0 assignees View on GitHub
data objects enhancement
Dominant language
Python
Stars
204
Forks
134
Avg merge
12h 55m
Merged PRs (30d)
1

Description

(Note: this is the issue mentioned in https://github.com/astropy/specutils/pull/619#discussion_r400164276, which I went ahead and did in the process of merging, although @rosteen may have more to add)

While #619 implemented initial support for `SpectralCoord` in `SpectrumCollection`, right now it's restricted to *scalar* `radial_velocity`/`redshift` and `observer`/`target` coordinate objects. That's not ideal because for `SpectralCollection` it's not unreasonable that e.g. each element of the collection is a different `target` (and therefore also potentially different `redshift`). They could even be different `observer`s in principle (although I don't see an obvious use case for that offhand). So it shouldn't be restricted to scalars, but rather it should have a shape that's broadcast-able to the `SpectralCoord`'s shape.

One complexity: in principle in the `SpectrumCollection` one should check that the shape of the `SpectralCollection` is compatible with the `target`/`observer`/etc. But in other areas we've taken the philosophy that you dump whatever you like in there and only fail when someone does an operation that actually *requires* the broadcasting. So while `SpectralCoord` itself needs updating, for integration with `SpectrumCollection` it may be that we just need a test or two of a relevant case.

Contributor guide

Open the contributing guide

Research direction

Start by reading the SpectralCoord implementation and the SpectrumCollection integration from pull request #619. Trace how radial_velocity, redshift, observer, and target are currently restricted to scalars, then inspect the relevant collection tests. Done means these values can broadcast to the SpectralCoord shape and a collection case verifies the intended behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
data
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.