Units: use IAU 2009 System of Astronomical Constants?

[rieder]

Related to #170: It's not completely clear what the origin is for the units as defined in units.py. Some (like units.AU) deviate (very slightly) from their definition in the IAU 2009 System of Astronomical Constants (http://maia.usno.navy.mil/NSFA/IAU2009_consts.html), probably because they were defined before this was released?

Astropy also deviates from these definitions for some units, though not all the same as Amuse...

I think we should certainly (somewhere) cite the origin of constants and units currently used, and maybe allow the use of a specific definition (i.e. do something like from amuse.units.iau2009 import constants).

[ipelupessy]

not sure, some of them where reviewed at some point (G for example, for some problems its quite sensitive to use consistently the same value )...

[rieder]

Just changing constants would be a terrible idea - many simulations would probably be non-reproducible. But it would be nice to be able to specify which definition of units is to be used. Many non-SI units may change as they are measured more accurately. These changes will be small, but for full compatibility with e.g. Astropy-based scripts it would be good to be able to use the exact same values for units (and constants). And I think it's important to specify which definition of units we currently have, even if it's just as comments in the units.py file. I see that constants are taken from http://physics.nist.gov/constants.

[rieder]

(deleted earlier comment as it was incorrect)

[rieder]

AMUSE deviates from defined units in some instances (since most of these were defined after the units were added to Amuse, it makes sense to see deviations):

• AU: Amuse uses 149597870691 * m, but AU is now defined as

exactly 149597870700 metres, in agreement with the value adopted in IAU 2009 Resolution B2

• parsec also deviates, both derived from AU and from its own definition. It is defined as exactly 648000/pi AU (IAU 2015 Resolution B2), but it is AU / numpy.tan(numpy.pi/(180*60*60)) in Amuse.

For Sun, Jupiter and Earth-based units (LSun, MSun etc) I would expect to see deviations (these aren't well defined), but we should make clear where we got the numbers. As is, the numbers deviate from what I find on the NASA website (https://nssdc.gsfc.nasa.gov/planetary/factsheet/sunfact.html, https://nssdc.gsfc.nasa.gov/planetary/factsheet/jupiterfact.html).

[ipelupessy]

I don't think its a problem to change the values to IAU values exactly (or maybe indeed some way of selecting a definition set) but maybe wait for input from some more people (can you make a pull? Is it possible to gather the values semi-automatically (like the the nist constants))

[rieder]

I'll work on a amuse.units.constants-astropy (name to be decided) module, which will always use the same constants as astropy.

[rieder]

This (and the related #170) came up during the AMUSE discussion at MODEST-18 as a thing we should definitely fix.

[rieder]

Assigning this to a milestone as it is a good idea to get this fixed.

[rieder]

Bumping this long-standing issue as it was relevant again recently with the new Mesa interface (Mesa uses the IAU standard year = julianyr in AMUSE).

I think one way to solve this but keep compatibility is the following (needs to be worked out but I think it can work).

Currently, units are imported from amuse.units.units, usually as from amuse.units import units (but also often via from amuse.lab import *, ugh), meaning amusers mostly use units.pc etc rather than pc directly. This is something we should want to keep. I propose that we do the following:

• move amuse/units/units.py to amuse/units/legacy.py
• create a new amuse/units/iau.py, which follows the IAU style for units (https://www.iau.org/publications/proceedings_rules/units/)
• create a setting in amuserc (e.g. "system" in section [units]) that can (currently) be set to "legacy" or "iau" (and perhaps also "si"). Depending on this setting, amuse.units.units would use the "new" settings (IAU) or the current default (or purely the SI units). This should of course be made clear, and if it is not set at all, we should display a warning and use 'legacy'.

For the constants, it should be analogue to the above for units, but we may need more options there as constants get revised (e.g. add the year of the standard, defaulting to the latest if it is not set).

I think this could also help with making *MUSE less "polluted" with non-used units.

@ipelupessy what do you think?

[ipelupessy]

sounds good..I wouldn't maybe call it legace just units_amuse_2010.py or something and the new unit set units_iau.py etc I think its ok to make the default something else than the old set btw if there are good reasons to change (if you want to reproduce something older result you have to careful on many aspects anyway..)