Generalizing user-facing spectral tools to be able to operate on a broader set of data

[astrofrog]

I'm not sure if this is the right place to open this but I couldn't think of a better one as it is a meta-issue covering several different packages and I wanted to make sure this didn't get lost in the meeting notes

At the 2023 coordination meeting, there was a discussion about the fact that there are several different efforts to develop spectral-related tools/data containers, even within the astropy ecosystem (specutils, sunpy, spectral-cube). I won't try and re-hash the whole conversation, but one thing I thought was interesting/problematic that @Cadair mentioned is that specutils as it is right now is not really suitable to use with multi-dimensional cubes that have other world dimensions - for instance a cube with celestial and spectral axes or a cube with celestial, spectral, time, and stokes axes shouldn't really be subclasses of Spectrum1D or other classes in specutils because there is no reason the spectral axis is 'special' compared to other axes, say time. Because of this, sunpy can't really use any of the spectral functionality being developed by the Astropy Project.

This suggests that perhaps we should consider developing a lot of the spectral analysis utilities as functions that can operate on any NDData object with an APE-14 WCS of which Spectrum1D is a subset, rather than restricting them to Spectrum1D. In fact, a lot of functionality in specutils is already in functions instead of methods, such as, e.g., gaussian_fwhm or find_lines_threshold, and so we could generalize all such functions without actually breaking the current API, just expanding the type of data that can go in. This would make all the analysis functions more suitable for use by e.g. SunPy or other projects that might have n-dimensional cubes with a spectral axis.

In fact, we could even not necessarily require the base object to be NDData but something that looks like NDData, so that it could even be used in packages like spectral-cube that don't subclass NDData. We could then work with developers of other spectroscopic packages to ensure compatibility even if they do not inherit NDData. If we wanted to do this we could write a short APE describing the protocol of what the objects should look like, and we could even have that APE be more general than just spectral and also mention time and celestial coordinates as we could also try and develop time-related functionality in the same way.

We could add helpers to the core astropy package to be able to easily identify the time, spectral, or celestial axes in n-dimensional datasets to minimize boilerplate code across analysis utilities.

@keflavich @Cadair do you have any thoughts on this from the spectral-cube and SunPy sides?

also cc @astropy/specutils-maintainers

[keflavich]

I would very, very much like to have spectral-cube be compatible with specutils. Having both wrap nddata seems like a great way to go. In theory, I have a student thesis project lined up to work on radio-astro-tools/spectral-cube#694. We will need help.

On the APE side - sure, this might be a solution, I'm not sure. It worked for WCS?

Is there someplace the fundamental incompatibility is spelled out? From what you said, I only see a problem with the naming, not the functionality. What is the problem with treating the spectral axis as special?

[astrofrog]

To clarify my comment about the spectral axis not being special, I meant in terms of subclassing. I don't think e.g. a celestial+time+spectral cube should inherit from Spectrum1D any more than it should inherit from a time-related or celestial image class. I think that n-dimensional datasets should simply subclass NDData (or e.g. NDCube) and the WCS is what gives information about axes.

But we would still develop analysis utilities that treat some of the dimensions as special and use the WCS to decide which dimensions to operate on.

Does that make sense?

[pllim]

So is the next outcome a new APE proposal?

[astrofrog]

@pllim i think that might be sensible but only if the main parties involved are generally on board - I'm happy to lead or co-lead the APE

[pllim]

Who are the main parties? We should ping them here.

[pllim]

Did the APE every happen? Is this issue still relevant? If so, should probably cross-post on the #spectroscopy channel on Astropy Slack. Several spectroscopy proposals are approved for Cycle 4.

[kelle]

@tepickering , @kbwestfall - thoughts on this?

[tepickering]

i wholeheartedly agree with this! it also ties in with our discussions at the last couple coordination meetings about supporting the Array protocol.

[kelle]

@hpparvi: FYI. Not sure if this issue should be moved elsewhere.