Add module to use SkyCoord for SPICE computations

[ayshih]

At the recent DASH meeting, there was a lot interest expressed in having SunPy support SPICE kernels at some level. The now-archived astrospice package covered a little of what people use SPICE for, but is still missing many things.

This PR wraps the SPICE computations using the API of our coordinates framework (i.e., using SkyCoord). Here's an example using Solar Orbiter's predicted set of SPICE kernels:

>>> import astropy.units as u
>>> from astropy.coordinates import SkyCoord

>>> from sunpy.coordinates import spice

# Load the meta-kernel and create lots of frames
>>> spice.initialize('solo_ANC_soc-pred-mk.tm')
...
INFO: Installing SOLO_STIX_ILS CK frame (-144851) as 'spice_SOLO_STIX_ILS' [sunpy.coordinates.spice]
...
INFO: Installing SOLO_EUI_FSI_ILS CK frame (-144211) as 'spice_SOLO_EUI_FSI_ILS' [sunpy.coordinates.spice]
...
INFO: Installing SOLO_HEE_NASA dynamic frame (-144982) as 'spice_SOLO_HEE_NASA' [sunpy.coordinates.spice]
...
INFO: Installing SOLO_GSM dynamic frame (-144962) as 'spice_SOLO_GSM' [sunpy.coordinates.spice]
...

# Use SPICE to get the location of Solar Orbiter in a particular SPICE frame
>>> solo = spice.get_body('SOLO', '2024-01-01', spice_frame='SOLO_HEE_NASA')
>>> solo
<SkyCoord (spice_SOLO_HEE_NASA: obstime=2024-01-01T00:00:00.000): (lon, lat, distance) in (deg, deg, km)
    (-17.54823605, 4.15617429, 1.42506511e+08)>

# Transform the location to a different SPICE frame
>>> solo.spice_SOLO_GSM
<SkyCoord (spice_SOLO_GSM: obstime=2024-01-01T00:00:00.000): (lon, lat, distance) in (deg, deg, km)
    (73.47437224, 26.6713468, 45577871.53062959)>

# Retrieve the instrument line-of-sight (boresight) for STIX
>>> stix_ils = SkyCoord(0*u.deg, 0*u.deg, frame='spice_SOLO_STIX_ILS', obstime='2024-01-01')
>>> stix_ils
<SkyCoord (spice_SOLO_STIX_ILS: obstime=2024-01-01T00:00:00.000): (lon, lat) in (deg, deg)
    (0., 0.)>

# Transform the STIX boresight to the instrument frame of EUI FSI
>>> stix_ils.spice_SOLO_EUI_FSI_ILS
<SkyCoord (spice_SOLO_EUI_FSI_ILS: obstime=2024-01-01T00:00:00.000): (lon, lat) in (deg, deg)
    (-0.03, 0.035)>

TODO for this PR:

• Better document the existence of to_helioprojective()
• Write a unit tests for get_fov()
• Write a unit test for to_helioprojective()
• Add more implementation-approach details so that other developers can actually understand and maintain this
• Add a way to install a built-in SPICE frame (install_frame())

Deferred to future PRs:

• Create custom test SPICE kernels rather than downloading "live" ones so that at least some of the tests can be run offline
• Figure out whether the transformation of velocities is consistent with how Astropy does it
• Add support for elliptical FOVs (I'd like a "live" instrument kernel that actually defines such an FOV)

[hayesla]

this is very nice

[dstansby]

Given SPICE is used by a wider set of people (/ communities) than just solar physics, I think it's worth having a conversation about whether putting this in sunpy is the best way forward, compared to a separate package or in astropy core. In particular, having a separate package might encourange a wider set of contributors and eyes on the code from different research communities.

(I appreciate astrospice is archived, but that doesn't stop someone forking it and continuing development)

[Cadair]

First off, this is awesome.

astrospice also has helpers for getting kernels etc from the net iirc, which is probably useful additional functionality to go along with this? We could resurrect astrospice if we think that's the best place for this to live, but I am not sure I know enough about SPICE and how hard all this is going to be to maintain that I can make a very qualified decision.

[ayshih]

In the long term, a mature version of this bridging module should probably live in Astropy core. I feel that it is too few code lines and too integrated into the coordinates framework to separate out to its own package (e.g., astrospice). (Downloading SPICE kernels should probably always be a separate package, regardless of where this bridging module lives.)

In the short term, I think maturing this module in SunPy core is the most effective approach. Development can be agile while also automatically distributing the module to the community where the module will have the most impact, and thus get the relevant feedback. Solar missions are the special nexus where scientists both are actively using the SkyCoord API (which planetary folks aren't really yet) and are actively using SPICE kernels (which the non-solar astrophysicists aren't really yet).

[dstansby]

In the long term, a mature version of this bridging module should probably live in Astropy core.

If that's the case, isn't it worth PR'ing this to astropy to get eyes on it from the start from the developers of where we want it to end up? Short term it might be easier for us (sunpy develoeprs) to quickly put something in sunpy, but since this is a major new feature I think it's worth putting the effort in to have design decisions with people outside the solar physics community before jumping in, or putting this in another package that is not mature and constrained to a release cycle like sunpy is that would actually allow for faster iteration and development.

[dstansby]

Discussed briefly on the weekly call, and consesnus was to go ahead and put this in sunpy core

[Cadair]

Other than a few coverage gaps (primarily get_body with an observer by the looks of it) I think this looks good to go.

[Cadair]

Random aside, but we are making heavy use of this method in sunpy, should we open a PR to astropy to make it not private?

[ayshih]

Well, not exactly "heavy use", as this would be the first time that we actually use the method in sunpy. (We needed our minimum Astropy dependency to be 5.0, and I didn't want to start refactoring until transformations.py to turned private.)

[Cadair]

oh maybe I am getting confused between your geo frames PR and the merged code lol. Either way, I think that if we are going to rely on it we should ask astropy to mark it as public, mainly so someone doesn't change it somehow thinking that's a safe thing to do?