[AstroPy] Implementing a versatile natural unit system with astropy?

[Tien]

Hello,

Yes, I recall deciding against using pint and pint-xarray for data analysis at some point (can't remember the exact reason why; I think it's due to robustness? But having an attrs["units"] entry for data storage and converting xarray to astropy Quantity for the calculations that need hairy conversions achieved the intended use so I was good with using astropy.units).

-- T

-------- Original Message --------
On 1/24/24 07:39, J Vickroy  wrote:

> Hello Tien. Have you considered [pint](https://pint.readthedocs.io/en/0.23/index.html)? /jv
>
> ---------------------------------------------------------------
>
> From: AstroPy <astropy-bounces+jgv.home=gmail.com at python.org> on behalf of Tien via AstroPy <astropy at python.org>
> Sent: Wednesday, January 24, 2024 6:55 AM
> To: astropy at python.org <astropy at python.org>
> Cc: Tien <tvo.email at proton.me>
> Subject: [AstroPy] Implementing a versatile natural unit system with astropy?
>
> Hi all,
>
> I work on heliospheric plasmas and have used astropy intensively in both spacecraft data analysis and numerical simulations. The workflow usually involves converting back and forth between measurements with physical dimensions (as motivation for simulation upstream conditions) and numerical results (as discussion for relevance or importance for observations).
>
> As such, I've written many iterations of code that help moving between astropy quantities and natural units (for example, background magnetic field = light speed = vacuum permittivity = particle mass = 1). And I'm finally motivated enough to think about a more well-structured extension for astropy with natural units. I think this will be beneficial to simulators in plasma (and really any other field of) physics who also work closely with experimental results (like most helio-/space physicists). And only recently when I started looking into this that I found out astropy.units was adapted from [a package to analyze astrophysical N-body simulation data](https://github.com/pynbody/pynbody) (which in theory is very similar to simulation data in plasma - particle trajectories or hydrodynamics quantities)! So I think my intentions are well-justified.
>
> So I want to survey your thoughts on how this extension may be implemented: (1) as an astropy sub-module or (2) as an affiliated package?
>
> (1) A straightforward thing to do would be to open a pull request for an  astropy.units.natural​ module where, for example, natural_length = u.def_units("natural_length", 0.1 * c.si.R_earth, ...)... so on and so forth for other fundamental dimensions (time, mass, charge). Then a user may be able to convert between astropy.units.si (physical measurements) to astropy.units.natural (for simulations) via UnitBase.to_system.
>
> However, a module organized like this is particular for some narrow class of simulations. In plasma physics (both experiments and simulations), we often like to convert between ion scale (fluid; for example natural_length = ion inertial length) and electron scale (kinetic), or to meso-driving scales (sub-ion scale) in turbulence, etc, or to global scales (like the size of the Earth or some fractions of an AU). Surely other areas of physics would also have a diverse range of natural units they'd like to work in. So perhaps this could be a larger package (2), which offers such flexibility.
>
> Within plasma physics, this would be a great connection between astropy and plasmapy, which already implemented many quantity-aware common functions. So a simulation setup does not need to re-define, say, what a gyroradius is, and instead just calls plasmapy formulary functions.
>
> I'd love to hear your thoughts on this. Feel free to offer comments.
> -- Tien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/astropy/attachments/20240124/47336413/attachment.html>