Part of PyHC's mission statement is to foster interoperability, and one of its strategic goals is to "Foster an open-source Python software ecosystem for heliophysics research and education".
For the last megasecond or so, I've thus been wondering about how best PyHC can achieve interoperability among the different packages.
There is a head start for interoperability between SunPy ☀️🐍 and PlasmaPy ✨🐍 because both packages prioritize interoperability with Astropy 🌌🐍. Both packages make use of astropy.units 🌡️ and astropy.constants ⚖️️; and SunPy also makes use of astropy.coordinates 🌐, astropy.wcs 🧭, astropy.time 🕐, astropy.vizualization 🖼️, astropy.logger 🪵, and astropy.io 📥. (Thank goodness for grep to help me figure this out!) In terms of scientific connections, SunPy/Astropy interoperability benefits studies on the solar/stellar connection, and PlasmaPy/Astropy interoperability benefits studies on plasma astrophysics. Consequently, it is important for both SunPy and PlasmaPy to maintain interoperability with Astropy.
To the best of my knowledge, there does not exist a actively maintained space physics package that has significant interoperability with Astropy, SunPy, and PlasmaPy. Such a package would be beneficial for studies that combine remote observations of the Sun with in situ observations of space plasmas — especially important now with Parker Solar Probe and Solar Orbiter. To achieve such a package, potential paths forward include:
Modify an existing space physics package to be interoperable with Astropy.
Create a new space physics package that is designed from the start to be interoperable with Astropy.
Modifying an existing package to be interoperable with Astropy would require a significant amount of effort, and would likely result in numerous breaking changes to that package. Modifying an existing package would require a significant time investment (∼6–12 person-months?). A linchpin is that this would require the maintainers of the existing package(s) to invest a lot of time into learning Astropy and applying it into their package.
Creation of a new package would likewise require a very significant amount of effort, but without necessitating any breaking changes. This also would likely take longer than a year. However, the new package could potentially be a front-end to existing packages (i.e., by providing access to functionality from existing packages but with an API that is interoperable with Astropy). If we take that approach, we could think of the new package as an interoperability layer (e.g., by importing magnetic field models and putting them in a format appropriate for astropy.modeling).
It would find it worthwhile to do a tradeoff analysis of these two approaches, get a better idea of the scopes of work, consider different potential paths forward for achieving interoperability, and look into funding possibilities. I also wonder if we could do a survey of users of PyHC packages, and follow up by interviewing people who have tried to combine remote and in situ observations to get an idea of what their software pain points are.
Part of PyHC's mission statement is to foster interoperability, and one of its strategic goals is to "Foster an open-source Python software ecosystem for heliophysics research and education".
For the last megasecond or so, I've thus been wondering about how best PyHC can achieve interoperability among the different packages.
There is a head start for interoperability between SunPy ☀️🐍 and PlasmaPy ✨🐍 because both packages prioritize interoperability with Astropy 🌌🐍. Both packages make use of
astropy.units🌡️ andastropy.constants⚖️️; and SunPy also makes use ofastropy.coordinates🌐,astropy.wcs🧭,astropy.time🕐,astropy.vizualization🖼️,astropy.logger🪵, andastropy.io📥. (Thank goodness forgrepto help me figure this out!) In terms of scientific connections, SunPy/Astropy interoperability benefits studies on the solar/stellar connection, and PlasmaPy/Astropy interoperability benefits studies on plasma astrophysics. Consequently, it is important for both SunPy and PlasmaPy to maintain interoperability with Astropy.To the best of my knowledge, there does not exist a actively maintained space physics package that has significant interoperability with Astropy, SunPy, and PlasmaPy. Such a package would be beneficial for studies that combine remote observations of the Sun with in situ observations of space plasmas — especially important now with Parker Solar Probe and Solar Orbiter. To achieve such a package, potential paths forward include:
Modifying an existing package to be interoperable with Astropy would require a significant amount of effort, and would likely result in numerous breaking changes to that package. Modifying an existing package would require a significant time investment (∼6–12 person-months?). A linchpin is that this would require the maintainers of the existing package(s) to invest a lot of time into learning Astropy and applying it into their package.
Creation of a new package would likewise require a very significant amount of effort, but without necessitating any breaking changes. This also would likely take longer than a year. However, the new package could potentially be a front-end to existing packages (i.e., by providing access to functionality from existing packages but with an API that is interoperable with Astropy). If we take that approach, we could think of the new package as an interoperability layer (e.g., by importing magnetic field models and putting them in a format appropriate for
astropy.modeling).It would find it worthwhile to do a tradeoff analysis of these two approaches, get a better idea of the scopes of work, consider different potential paths forward for achieving interoperability, and look into funding possibilities. I also wonder if we could do a survey of users of PyHC packages, and follow up by interviewing people who have tried to combine remote and in situ observations to get an idea of what their software pain points are.