# 2025 SunPy Coordination Meeting Running Notes

Video recordings of the meeting: https://www.youtube.com/playlist?list=PLOWSPnooGuj0sPNNQ_a6DVkk_FbIajzzs

## Wednesday
### Hack: Map NDCube Refactor
### SunPy Roadmap
#### Discussion

What's the purpose of a roadmap? Why do we want one? (For project as a whole, not just core.)
* Canned list of things to do when a call for funding comes along.
* Astropy used theirs to write SSI grant proposal.
* Can be used by individuals writing proposals as justification of the impact of their proposed work.
* What about maintenance? Will this undermine a proposal of something that isn't included on the roadmap? Especially if the roadmap is out-of-date?
* Shouldn't be too granular. Should have timelines. Not about specific versions of sunpy delivered by when.
* What is the process for updating it?
* Nabil: Path to goals on roadmap needs to be outlined in a specific proposal. Danny: The visionary goals are still useful for justifying tasks in a proposal, even if path not on roadmap.
* Laura: A shorter-term roadmap would be useful as well as a longer term roadmap would be useful.
Alisdair: Should be a living document. Should be able to add stuff via PR whenever.
Stuart: Once a year group meeting has a higher bar for concensus. This is desireable.
* Albert: Would be useful to have a way of delineate between short-term achievability, e.g. by a single proposal, and larger scale aspiration. It would be useful for applying for OSTFL, for example?
* Will: A hierarchy of tasks.
* Stuart: More complexity makes the roadmap harder to maintain. More likely to fall out of date.

What is the process for updating the roadmap?
* Decide this later, once we know how it looks.

#### Roadmap Draft

##### Documentation / Learning

* Project wide gallery
* Project wide search
* Tutorials and training materials
* More examples for not-core
* Examples of building non-FITS WCS (i.e. gwcs) for solar cases
* e.g. overlappograms
* time varying WCSes

##### Improved Support for Spectral Data

* Calculate moments
* Support for X-ray spectral fitting: sunkit-spex
* Irregular coordinate grid support in NDCube/ExtraCoords
* Coordinate bin edges in NDCube/ExtraCoords
* Support for atomic databases fitting templates (astropy models) (i.e. expected line positions)
* Documenting how to serialize models (e.g. to asdf)
* Address needs of in situ spectra

##### World coordinate specific API on NDCube

* Rewrite maputils to support NDCube objects with at least 2 celestial axes
* Perform operations which require spatital axes on a higherD cube, like draw_limb on a SPICE cube.
* Access world coordinate specific metadata (such as reference_coordinate) on higherD cubes.
* Example use case: be able to treat a space-space slice of an IRIS cube like a Map.
* Extract 1-D paths or regions through world space into a 1-d NDCube.
* Provide views into the cube where all the other pixel dimensions are flattened (i.e. fitting all spectra or tracing a SkyCoord through all non-celestial axes)

##### Other things

* Time-varying WCSes (dkist -> gwcs?)
* Drop world axes in ndcube slicing while a pixel axis exists (i.e. ignore degenerate dimensions)
* i.e a 2D cube from a rastering spectrograph (sliced at a wavelength) doing a pixel_to_world still needs time.

###### affiliated package work
* Generalized package for doing inversions
* i.e. **sunkit-dem** but generalized to more complicated coupling of axes, e.g. inverting overlappograms
* sunkit-dem...
* radiospectra
* More extrapolation methods in sunkit-magex
* Proper support for spectral data
* Accurately represents the data/wcs
* spectral fitting support
* SST and VISP support
* Make all WCS-based data classes backed by NDCube.
* No NDCube subclasses - Replace all data classes with a single class
* Richer world coordinate specific API on NDCube
* SM - load any dimension cube into a sunpy class and have the existing ndcube methods work (ref pixel, rebin, draw limb, etc.)
* Agreed upon vocabularly for instrument-specific metadata classes
* Metadata is instrument-specific mixin
* Coronagraph focused tools (e.g. PUNCH + Proba3 + Metis onboard Solar Orbiter)

## Thursday
### Discussion: Sustainability & Governance
### Metadata for Map, NDCube etc.

#### The Future of Metadata handling and SunPy Data Classes

* Last discussed at Dublin coordination meeting.
* Since then, `ndcube.NDMeta` has been released: provides axis-aware, sliceable `dict`-like metadata.
* Metadata objects in the future can replace instrument-specific functionality of data classes, e.g. `AIAMap` -> `GenericMap` + `AIAMeta`.
* For this, we need a hierarchy of designated names for specific pieces of metadata.

#### Proposed Metadata Structure

from ndcube.meta import NDMetaABC


class ObsMetaABC(NDMetaABC):
    @property
    @abc.abstractmethod
    def detector(self) -> str:
        pass

    @property
    @abc.abstractmethod
    def instrument(self) -> str:
        pass

    @property
    @abc.abstractmethod
    def observatory(self) -> str:
        pass

    @property
    @abc.abstractmethod
    def processing_level(self) -> str:
        """
        The level to which the data has been processed.
        """

    @property
    @abc.abstractmethod
    def observer_coordinate(self) -> SkyCoord:
        """
        Coordinate of observatory location based on header info.
        """

    @property
    @abc.abstractmethod
    def date_reference(self) -> Time:
        """
        The base time from which time axis values are measured.

        Often the same or very similar to date_start.
        """

    @property
    @abc.abstractmethod
    def date_start(self) -> Time:
        pass

    @property
    @abc.abstractmethod
    def date_end(self) -> Time:
        pass

    @property
    @abc.abstractmethod
    def version(self) -> str:
        """
        The data version.
        """


class RemoteSensorMetaABC(MetaABC):
    @property
    @abc.abstractmethod
    def radius_sun(self) -> u.Quantity[u.physical.length]:
        """
        Solar radius set by observation to be used in coordinate transformations in units of length.
        
        Equivalent to rsun_ref in FITS standard.
        """

    @property
    @abc.abstractmethod
    def radius_sun_angular(self) -> u.Quantity[u.physical.angle]:
        """
        Solar radius set by observation to be used in coordinate transformations in angular units.
        
        Equivalent to rsun_angular in FITS standard.
        
        This could be part of a category of metadata that's not implemented but dynamically calculated from other metadata.
        """

    @property
    @abc.abstractmethod
    def distance_to_sun(self) -> u.Quantity[u.physical.length]:
        """
        Distance to Sun center from observatory.
        
        Valid for in-situ. Should be moved up in the hierachy?
        
        Is this needed at all? This info should be accessible through observer_coordinate?
        
        This could be part of a category of metadata that's not implemented but dynamically calculated from other metadata.
        """
        
        
class ImageMetaABC(MetaABC):
    @abc.abstractproperty
    def filter(self) -> str:
        """
        The name of the filter(s) used to make the observation.
        """

    @abc.abstractproperty
    def automatic_exposure_control_on(self) -> bool:
        """
        Whether automatic exposure control was on during observations.
        """
        
    @abc.abstractproperty
    def detector_area(self) -> u.Quantity[u.physical.area]:
        
    
    @abc.abstractproperty
    def effective_area(self) -> u.Quantity[u.physical.area]:
        
    
class SpectralMetaABC(MetaABC):
    pass

    
class StokesMetaABC(MetaABC):
    pass

    
class SlitSpectrographMetaABC(RemoteSensorMetaABC):
    @property
    @abc.abstractmethod
    def spectral_window(self):
        pass

    @property
    @abc.abstractmethod
    def observing_mode_id(self):
        """
        Unique identifier for the observing mode.

        Often referred to as OBS ID.
        """

    @property
    @abc.abstractmethod
    def observer_radial_velocity(self):
        """
        Velocity of observatory in direction of source.
        """
    
####### Instrument-specific Metadata ######

class AIAMeta(RemoteSensingMetaABC, ImageMetaABC):
    pass

class IRISMeta(SlitSpectrographMetaABC):
    pass
    
class DKISTMeta(RemoteSensingMetaABC, ImageMetaABC, SpectralMetaABC, StokesMetaABC):
    pass

* Do people agree?
* If so, what metadata names do we need? What ABCs do we need?

#### Notes
* These properties should have setters so you can change the metadata as part of the operation
* Subclasses of NDMeta need a dispatch mechanism whereby the Meta recognises that an operation has been done to the cube, and what if anythong needs to be changed in the metadata.
* Stuart: We need to be able to do something like this:

@ndmeta_from_key("FOV")
def field_of_view(self) -> u.Quantity[u.arcsec]:
    """this is the field of view"""

* We should be able to support arbitraliy complex underlying implementations, not just dict-like.
* Shane: We should consdier building on or mimick IVOA's control vocabulary where applicable e.g. [ObsCore](https://ivoa.net/documents/ObsCore/20170509/REC-ObsCore-v1.1-20170509.pdf)
* What of these should be required vs. encouraged? Advantage, we can code against them if they are required as we can rely on them being there, but may be annoying extra overhead if that metadata is not relevant.
* Laura: Why not have a Metadata class with all propoerties returning `None`, and then have instrument-specific classes overwrite that implementation? Guarantees all properties are present, but will be messy for users using tab-complete.
* This should be a Python API as well as a metadata API. So we should be defining the output type.
* Could we have a validater function that confirms whether all metadata is consistent, e.g. DSUN_OBS vs. distance of observer_coordinate.
* Will: Does this clash witrh solar net spec? Stuart: No. Solar net is a solar FITS spec on top of basic FITS standard. It's complimentary.
* Laura: It would be great to have docs discussing the translation between the FITS/Solarnet spec and this API would be useful. (https://arxiv.org/pdf/2011.12139) and also https://solarnet-metadata.readthedocs.io/en/v3.0.0/
* Need a way to have documented this key is documented from these set of keys
* Stuart: We need to write a similar spec for FITS-WCS-like transform. This is to allow the map-like fixing of the metadata and also would allow us to define setters for a nicer API for methods like rotate to be able to set the `rotation_matrix` and have the WCS update rather than having to modify FITS keys. That implementation would also allow rather than having the WCS backed by a FITS header could be backed by a gwcs or something else as long as it uses the FITS-WCS transform.

## Friday
### 🧩 Discussion, Q&A, Roadmap & Mission Statement

it was decided go use xarray and zarr instead

### Lightening talks
- Shane - STIXpy
- how do we better light travel correction? we have a different ways to faciliate this?
- Challenges with astropy flexibility, modelling Nd data (rather than treating it as 1D)
- Life-cycle of astropy is very long for releases, can be management challenges with this.

Laura's slides on engagement and community:

https://docs.google.com/presentation/d/1Bbsz9kBhoQDZyiEXgy1iml61Sz-VFR0L3vPqmAUMWq8/edit?usp=sharing
EU funding links: https://ec.europa.eu/info/funding-tenders/opportunities/portal/screen/opportunities/calls-for-proposals?order=DESC&pageNumber=1&pageSize=50&sortBy=startDate&isExactMatch=true&status=31094501,31094502,31094503&programmePeriod=2021%20-%202027&frameworkProgramme=43108390&destinationGroup=45355232

NLFFF from Karla's talk: https://hinode.isee.nagoya-u.ac.jp/nlfff_database/