2025 SunPy Coordination Meeting Running Notes

Wednesday

Hack: Map NDCube Refactor

Discussion: [Project Roadmap](SunPy Roadmap Draft)

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.

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
• 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 - 2027&frameworkProgramme=43108390&destinationGroup=45355232

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