Astropy: Is astropy.units essential in more fields than just astronomy?

[JamesCropcho]

Greetings. Thanks for a great set of packages!

It's difficult to think of a broader use case than the one for which astropy.units was designed—for computation using physical quantities!

I am very new to this project and I don't want to step on any toes. Still, I can't help but wonder if astropy.units should be "advertised" as bigger than only astronomy. A subset of possible mechanisms for this includes moving the module outside the astropy namespace, and/or listing a variety of other domains for which it's a great fit in the documentation, and/or writing an official blog post (though I don't believe Astropy has a blog?).

Generally, What do you all think?

[bsipocz]

@JamesCropcho - By all means please advertize any of the functionality of astropy in the broader community. Many other parts of the package can be also seen as useful to non astromers, e.g. astropy.table is another example.

We are in the process of creating an "Astropy is used by" page, would you think a section of non astronomy examples be useful there?

[adrn]

I've always felt that it is generic enough that it could live somewhere beyond astropy. Since it subclasses and uses quite a bit of numpy machinery, that was always one thought. But I think they are hesitant about moving such a large chunk of code into the numpy codebase. I wonder if the concept of a numpy affiliated package is useful to think about or explore? I only have vague or incomplete thoughts on this because I can see arguments for and against moving out the units functionality! I do think @mhvk has had various conversations with numpy developers about related things - maybe he could chime in?

[JamesCropcho]

We are in the process of creating an "Astropy is used by" page, would you think a section of non astronomy examples be useful there?

Brigitta ( @bsipocz ), yes, I do believe that would be useful, if you do have non-astronomy examples. I figured you would not due to the chicken-and-egg problem here, of non-astronomers not being aware.

Perhaps the optimal collection of people to target as units users would be the "NumPy yes, AstroPy no" composite. If NumFOCUS' booth is still here at PyData NYC, maybe you can ask them in person if AstroPy may write a guest post on NumPy's blog (or some equivalent). The request would mean a lot more coming from a core contributor than I.

[astrofrog]

One idea I had at some point would be to create a package that contains no code but just imports from astropy.units - this would just help with the branding issue, but still use astropy behind the scenes ;)

[bsipocz]

One idea I had at some point would be to create a package that contains no code but just imports from astropy.units - this would just help with the branding issue, but still use astropy behind the scenes ;)

or just raise awareness that astropy is overall a useful package ;)

[mhvk]

Agreed, quantities should ideally not be in astropy, as it is clearly useful in every field! This is in part why I've tried to ensure we keep our implementation as isolated as possible from other aspects of astropy.

As for where it might go: the units part may be of interest to numpy, but from discussions so far they do not like our Quantity subclass of ndarray; they'd rather extend the dtype to be able to hold the units. There's definitely good reasons for that: the dtype already tells ufuncs how to calculate things, and units just add further information, but given that the ideas for those types of dtype have been around for multiple years, I must admit I'm quite happy we chose to just do it...

I thought myself that scipy is perhaps a more logical place; it already has a collection of constants. But I have not explored this.

[astrofrog]

I would argue that if we split it out it should just be a small independent package rather than being merged in to e.g. scipy (better to have an independent release cycle)

[mhvk]

@astrofrog - as a small independent package, I think it likely would not get used much beyond astropy. There are other units packages around, and I doubt (but have not checked) any has a large user community.

I do see your point about the release cycle, though scipy has become quite active again, and units has become quite stable.

Anyway, I don't think any of us are really up right now for what would be a fairly major effort...

[pllim]

Just for the record, in an older version of the astropy doc, it was stated that units was adapted from pNbody package. Stating this here in case it is useful to consider for discussion; It is now not mentioned anymore in the latest doc(s) because it has evolved so much since then.

[namurphy]

To follow up with the initial question, we're using astropy.units quite heavily in PlasmaPy and are very grateful for the hard work that has been put into this subpackage! SunPy also uses astropy.units.

[namurphy]

Come to think of it, I also use astropy.units.imperial really frequently while cooking, instead of having to remember the nonsensical unit conversions we have to deal with in the U.S.

I'll probably also use astropy.units if I ever write a vegan cookbook using horrible but surprisingly convenient units like barn-megaparsecs:

>>> from astropy import units
>>> (1*units.barn*units.Mpc).to(units.imperial.tsp)
<Quantity 0.6260350298930571 tsp>

[adrn]

Please move future discussion to #8210