Incorrect Planck mass

[musoke]

• unyt version: 1.0.7
• Python version: 3.7.2
• Operating System: Ubuntu 16.04

Description

I am doing some calculations with Planck units.

What I Did

Python 3.7.2 (default, Dec 29 2018, 06:19:36)
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import unyt
>>> unyt.m_pl.to('kg')
unyt_quantity(2.17650925e-11, 'kg')

I expected to get a value of 2.177e-8 kg.
See for example https://physics.nist.gov/cgi-bin/cuu/Value?plkm, http://scienceworld.wolfram.com/physics/PlanckMass.html

The correct value is calculated in unyt/_physical_ratios.py but it seems to be used incorrectly somewhere in unyt/_unit_lookup_table.py.

[ngoldbaum]

So the value we have does round to the value you're expecting at the precision you're quoting. It is a little bit different from the CODATA values in the fourth decimal place, although I believe our value is within the quoted uncertainty. It is slightly different from the value quoted in MathWorld, although they don't cite where they get their values from.

I suspect that almost all of the difference is due to uncertainty in Newton's constant and indeed if I change our definition of Newton's constant in _physical_ratios.py to the value in CODATA, I get exactly the value they quote for the planck mass.

Looking deeper, it looks like we're using the 2010 CODATA value. Therefore I think the fix is to update our definition of G to the most recent CODATA value.

[ngoldbaum]

See #84

[musoke]

Thank you for the quick response! I was actually more concerned that the values are different by a factor of 1000.

[ksunden]

I will note ,the PR in #84, didn't actually address the issue, that was fixed in version 2.0.0, previously m_pl had units of "g" rather than "kg" ,though the number was the correct number for kg, resulting in the factor of 1000.

[ksunden]

This was actually fixed in #65, which was a relatively large PR (and the one that made the major version bump to 2.0)

It was not the goal of the PR, but the result was that this particular incorrect value (and maybe others) were fixed by the overall code reorganization involving these constants.

(specifically, commit 374175c)

[ngoldbaum]

Ah sorry, I missed that you were using an old version.

[musoke]

Ah, perfect. Thank you @ksunden and @ngoldbaum!
For some reason github wasn't showing me the newer releases and I couldn't see an issue or pull request addressing it so assumed that it wasn't fixed. I'll try this out.

[ngoldbaum]

Ah that’s because I don’t really use the github release interface, I just upload things to pypi. The only reason we have one for 1.0.7 is because JOSS asked for it.