Skip to content

Add "extragalactic" and "galactic" unit systems #703

Closed
Closed
Add "extragalactic" and "galactic" unit systems#703
Labels
💤 Package-intermediateFeature Requestunits

Description

@eteq
eteq
opened on Jan 30, 2013

#579 added the to_system functionality to units. This provides an easy way to convert units between cgs and si. A nice addition would be to also support galactic and extragalactic unit systems. These systems would be like cgs, but with the natural length scale in kpc or possibly Mpc for extragalactic and pc for galactic, and with km/s the natural velocity scale.

This may require more work, because km/s is not an irreducible unit. But I haven't looked closely enough to know how one might do this with the to_system logic.

cc @mdboom

Activity

  1. ghost assigned
    mdboom
    on Sep 4, 2013

  2. mhvk commented on Jul 8, 2014

    @mhvk
    mhvk
    on Jul 8, 2014
    Contributor

    @eteq - do you still feel this would be useful? (am trying to go over really old issues so we can reduce the number of open issues, and feel that this is one of those that will just remain open forever until someone just implements it -- which would probably not be triggered by the issue).

  3. eteq
    added
    Low Priority
    on Jul 8, 2014
  4. eteq
    unassigned
    mdboom
    on Jul 8, 2014

  5. eteq commented on Jul 8, 2014

    @eteq
    eteq
    on Jul 8, 2014
    MemberAuthor

    @mhvk - Yes, I think this is still worth doing, but it is not a high priority. So I added the "low priority" tag.

    I also don't think it's bad to keep issues like this open: the intent of the "future" category is for things like this: ideas that are not high priority, but are relatively straightforward to implement when someone has time. I think this is useful for people who are looking for ways to contribute to Astropy, but aren't sure how (I get a few people asking about this, and I direct them either to the "easy" label, or "future", depending on how skilled the are in Python/programming). But it's also good to check on these from time-to-time, because sometimes they get outpaced by other developments. In this case I think it's worth keeping, though.

  6. adrn commented on Jul 8, 2014

    @adrn
    adrn
    on Jul 8, 2014
    Member

    Oo, I would use this -- can we agree on the systems though? To me,

    Galactic:

    • velocity : km/s
    • length : kpc
    • time : Myr
    • mass : M_sun (?)

    Extragalactic:

    • velocity : km/s (?)
    • length : Mpc
    • time : Gyr
    • mass : M_sun (?)

  7. mhvk commented on Jul 8, 2014

    @mhvk
    mhvk
    on Jul 8, 2014
    Contributor

    @adrn - your example makes me wonder how this would work: Wouldn't velocity necessarily be in length-unit / time-unit? Also, while the scales are reasonable, I might pick pc for length and Gyr for Galactic. Which suggests a bit of a problem: unlike si and cgs these are not defined by anybody. Do we really want to be setting standards? Or would it be sufficient to be able to do something like:

     (1./(10.*u.Gyr)).decompose((u.Mpc, u.km/u.s))

    (not currently possible, though it may get better with #2559)

    Anyway, clearly enough reasons to leave this issue open for now!

  8. astrofrog
    added
    package-intermediate
    on Jul 13, 2014

  9. mhvk commented on Jan 13, 2015

    @mhvk
    mhvk
    on Jan 13, 2015
    Contributor

    Just for the record: with #2559, the above (1./(10.*u.Gyr)).decompose((u.Mpc, u.km/u.s)) does not work (astropy version 1.0.dev11386)

  10. adrn commented on Jan 13, 2015

    @adrn
    adrn
    on Jan 13, 2015
    Member

    Sorry this totally fell off of my radar. It's something I deal with all the time, though long ago I just accepted it and adapted all of my code to work in the system (kpc, Myr, Msun). This lets me use decompose() everywhere, but it would be kind of cool if we had some kind of specialized support for decomposing into composite units, e.g.

    >>> (15*u.imperial.mi / u.s).decompose([u.km/u.s, u.kpc, u.Myr])
<Quantity 24.14016 km / s>

    Of course, the showstopper is the question of what to do with something like <Quantity 15.0 mi2 / s3>... I wonder if it would be useful enough to match on physical type of the decomposing system, and if no explicit match is found, take the base units? Something like:

    >>> (15*u.imperial.mi / u.s).decompose(bases=[u.kpc, u.Myr], composite_bases=[u.km/u.s])
<Quantity 24.14016 km / s>
>>> (15*u.imperial.mi**2 / u.s**3).decompose(bases=[u.kpc, u.Myr], composite_bases=[u.km/u.s])
<Quantity 1282330111.0449004 kpc2 / Myr3>

    (BTW @mhvk I was just found a copy of your thesis in my office...not sure what the universe is trying to tell me)

  11. mhvk commented on Jan 13, 2015

    @mhvk
    mhvk
    on Jan 13, 2015
    Contributor

    But then again, maybe adding too many bells & whistles is not good either...

    Funny how this habit of printing many copies of one's thesis influences things. And scary to think I still use optimal extraction code I developed at the time (which, who knows, may at some point enter specutils in a python incarnation...).

  12. adrn commented on Jan 13, 2015

    @adrn
    adrn
    on Jan 13, 2015
    Member

    @mhvk Totally agree -- oops, I didn't mean to imply that the above belongs in the core, just bringing it up for discussion!

  13. mhvk commented on Jan 13, 2015

    @mhvk
    mhvk
    on Jan 13, 2015
    Contributor

    Understood -- in principle, I think it would be good if the example I gave would work, i.e., one could decompose into any bases with which it is possible to construct the unit given.

  14. adrn commented on Dec 20, 2015

    @adrn
    adrn
    on Dec 20, 2015
    Member

    FYI: I implemented something that might help for this in one of my own packages as a trial implementation / demo of one possible way to deal with unit systems. In my UnitSystem object, you can override base unit combinations by specifying composite units. For example, this unit system would always convert down to combinations of base units:

    >>> usys = UnitSystem(u.kpc, u.Myr, u.Msun, u.radian)
>>> (15*u.km/u.s).decompose(usys)
<Quantity 0.015340682475805617 kpc / Myr>

    But this has a specified representation for 'speed'-like units, so it doesn't return kpc/Myr:

    >>> usys2 = UnitSystem(u.kpc, u.Myr, u.Msun, u.radian, u.km/u.s)
>>> usys2.decompose(15*u.km/u.s)
<Quantity 15.0 km / s>

    (note: I chose not to monkey-patch the .decompose() method on Quantity, thats why this special method call is on the unit system instead).

    The UnitSystem then acts like a dictionary for physical types (which, right now, are strings):

    >>> usys['speed']
Unit("kpc / Myr")
>>> usys2['speed']
Unit("km / s")

    If the (non-base) physical type wasn't specified on creation, it puts together the base units:

    >>> usys['pressure']

    Unit("solMass / (kpc Myr2)")

  15. jobovy commented on Jan 4, 2016

    @jobovy
    jobovy
    on Jan 4, 2016
    Contributor

    I'm looking into using the Units framework for galpy and stumbled on this issue; obviously having a galactic unit system would make that support much easier!

    I only glanced through the thread, but wouldn't many of the issues raised here be resolved by not having time as a fundamental unit (i.e., just have length and velocity; similar to WD_units in NEMO)? If you use kpc and km/s, the derived time unit would be ~Gyr.

    Also don't see how there can be any argument against kpc as the appropriate length unit for galaxies (there's fewer than 1 star / pc^3 near the Sun...). And Gyr is much closer to the dynamical time than Myr...

  16. pllim
    removed this from the Future milestone on Apr 8, 2021

  17. adrn commented on Apr 12, 2021

    @adrn
    adrn
    on Apr 12, 2021
    Member

    Closed to discuss the broader issue in #11525

  18. adrn
    closed this as completedon Apr 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    💤 Package-intermediateFeature Requestunits

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions