Units, constants and configurations

[rieder]

A long standing issue is that our unit system is different than that of astropy.
We have working converter methods, but these result in 1 astropy year not being the same as 1 amuse year (because of different definitions).
Ideally, we want to adopt the astropy unit system in AMUSE, but we also would like to keep the current unit system (for historical/reproducibility reasons).

For this, we need a way to store settings, e.g. a ".amuserc" similar to how matplotlib does it.
I'm not sure if we already have something that can be used for this - if we do, it's not well documented.

What I think we need for this:

• At the time amuse.units is imported anywhere, check which unit system is to be used (from the amuserc, or a default value).
• This then needs to be consistently used.
• unit systems we need to have are:
  • 'classic' (current amuse units/constants)
  • 'astropy' (default astropy units/constants)
  • 'astropy-XXX' (a fixed set of astropy units/constants, since they also update these at times)

See also astropy/astropy#10194 and #170

[rieder]

@LourensVeen do you have any thoughts on this?

[LourensVeen]

I've been looking at the units system recently because of a curious issue in the test suite (two otherwise wildly unrelated tests were affecting each other through the units system), so I've seen a bit of how it works. I don't know about the astropy units system, but I think it may be possible to either make it so that AMUSE quantities can use astropy units interchangeably, or make AMUSE quantities and astropy quantities interoperate.

As for settings, there is an amuserc file that is generated by the build system I believe and then included in the package and installed along with everything else. The settings in this file are read by the options subsystem, and for example AbstractMessageChannel has a bunch of them .

I think this is intended to be user-modifiable, but package resources aren't the place to put such things, and it doesn't seem to be documented anywhere. The right way to do it would be to read it from the $XDG_CONFIG_HOME (~/.config usually), with maybe a fallback to ~/.amuserc and possibly even /etc/amuserc too if we ever do a Debian package.

That said, wouldn't it be nice if this were transparent at least for the units, with the user just being able to use them both interchangeably without having to think about it? A year is a year in the end, and a parsec a parsec.

For constants, that's a different story, but I think it should also be quite simple. If you import your constant from AMUSE you get the AMUSE version, and if you import it from astropy then you get the astropy one. As long as AMUSE and astropy quantities are interchangeable, it shouldn't matter?