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

[Nick Murphy]

Thank you for bringing this up, and also the very insightful responses!

Over in PlasmaPy, I've started to work on classes for representing
normalizations of different systems of equations, building on astropy.units.
The idea is to create normalization objects which contain attributes with
the normalizations for length, time, and other physical types. My goal is
to enable operations like:

dimensionless_object = dimensional_object / normalizations_object
dimensional_object = dimensionless_object * normalizations_object

where dimensionless_object and dimensional_object could be single or
compound Quantity objects.  One of the main purposes would be to facilitate
comparisons between simulations and physical systems.

I've been meaning to get back to an old pull request to add an
MHDNormalizations prototype <https://github.com/PlasmaPy/PlasmaPy/pull/1029>
as a first step, based on the normalizations for the MHD equations. The
idea is to provide MHDNormalizations with three quantities representing
different types (e.g., length, magnetic field, & number density), and then
(for example) get the normalization for time from the time attribute.  This
is still a work in progress, so I'd be happy to talk more about this and
learn more from you about your perspective.

Thank you again!

On Wed, Jan 24, 2024 at 2:38 PM John ZuHone <jzuhone at gmail.com> wrote:

>
>
> > On Jan 24, 2024, at 2:19 PM, Tien via AstroPy <astropy at python.org>
> wrote:
> >
> > 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?
>
> Yep, I agree that it would be a nice thing to have. I use both unyt and
> astropy.units in my work, usually in different contexts (and also where the
> former isn’t guaranteed to be installed), but they are both excellent
> implementations. If there’s any way I could help with an astropy
> implementation I’d be happy to.
>
> The main reason the connecting tissue between the two is somewhat kludgey
> is simply because they use different machinery under the hood—unyt uses
> sympy to handle all of its symbolic unit operations whereas astropy has
> rolled its own implementation, so we wouldn’t be able to marry them
> trivially.
> _______________________________________________
> 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/4de5837b/attachment.html>