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

[Tien]

Hi John,

I wasn't aware of this package. It certainly does almost everything I want to do, and can convert between astropy.units and its own data type (although it looks a bit clunky? Say if I want to use plasmapy functions for calculating quantities, I'll have to do unyt -> astropy.units -> input into plasmapy -> convert back into unyt).

From a user perspective, if I only care about doing simulations, then unyt seems like a good library. But then if I want to use astropy and its other utilities, I'll have to manually handle (kind of redundant) conversions between unyt types and astropy types. Wouldn't it still be good to have native support in astropy?

Additionally, here's a thought as I type this: in space physics, spacecraft data are often explored interactively (which is why manually handling units and conversions are tedious). But in a simulation library, data are explored more procedurally since they are often saved in local storage (so unit conversions can be handled via whatever library or manually - they are all a few lines of code away). What I want is to make both processes more interactive and the transition between the two more seamless.

P/s: I don't particularly like the "unyt" name, but I will consider more of this library.

-- T

-------- Original Message --------
On 1/24/24 07:54, John Zuhone  wrote:

> Also, if you're particularly concerned about simulations, unyt has a natural units system (a couple of versions of it, with the ability to define more), and was originally designed for simulations:
>
> unyt.readthedocs.io
>
>> On Jan 24, 2024, at 9:39 AM, J Vickroy <jgv.home at gmail.com> 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 anastropy.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
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at python.org
>> https://mail.python.org/mailman/listinfo/astropy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/astropy/attachments/20240124/2e2ec671/attachment-0001.html>