Unyt is using a truncated version of Avogadro's number?

[bc118]

It seems like Unyt is using a truncated version of Avogadro's number, being 6.0221e23. Is this the case? If so, I recommend the following.

The seemingly more accurate Avogadro's number is 602,214,141,070,409,084,099,072 and located here (https://www.americanscientist.org/article/an-exact-value-for-avogadros-number).

I recommend double-checking and adding the most accurate value of Avogadro's number above if this is indeed the issue.

[neutrinoceros]

Here's where the constant is hardcoded.

unyt/unyt/_physical_ratios.py

Line 103 in ec5b330

avogadros_number = 6.02214085774 * 10 ** 23

As you can see, it has a couple more digits than you were guessing. It's also stored as a float, which limits the precision with which we can write it
we could change it from
6.0221408577399995e+23 (effective current value)
to
6.022141410704091e+23
though this may qualify as a breaking change for other users. Personally I would agree to update it anyway, since it's technically a fix.

[neutrinoceros]

The downstream compatibility issue is akin to #144
However I don't think that avogadros_number is very likely to be used in yt.

[bc118]

Thank you for your quick response and information. I added by additional thought below.

The chemistry, chemical engineers, and molecular simulations people use Avogadro's number a lot as it is key to chemistry, so we have noticed the slight difference. Therefore, we believe it is vital to use the correct number.

When checking the accuracy of our Unyt calculations compared to manual checks, the manual constants must be modified to account for the error in the Unyt Avogadro's number, or other measures are taken (for example, using "isclose" to make the comparison).

At a minimum, I believe this error in Avogadro's number should be listed in the Uynt documents because it is likely to be noticed by others and will help them quickly find the discrepancy.

[neutrinoceros]

I understand. Do you use the constant directly or is it used under the hood of some application (unyt itself ?) that you have no control over ?
In the former case, we could also ship the more accurate value under a different name (and of course document it).

Whatever the situation, I'll make sure this matter is discussed and that we have a solution for the next release.

[bc118]

We use it in both cases. Users can use Unyt and put the values into our software, and/or under the hood of the software that we write and distribute.

[bc118]

While on the topic of Avagadro's number, I will bring up one other modification that the computational chemistry groups made to the Unyt conversions. We use Kelvin as energy sometimes and need to convert it to normal energy units "kcal/mol" or "kJ/mol".

This is fine using Unyt when Kelvin is the only unit; however, this is not possible in Unyt directly if trying to convert Kelvin/nm^2 to kcal/mol/nm^2, which is required in many situations. We have developed a workaround and wanted to share it in case it is helpful to your team or other users.

k_to_energy_with_other_units.zip

[jzuhone]

I think that we should update the value of Avogadro's number--I don't think it will cause a downstream issue. As constants are better known / change, their values should be updated and we should document these changes in our changelog.

@bc118 could you make a PR?

As far as the issue with converting from temperature to energy, it looks like you've already figured out the use of unit equivalences, but we could think about exploring uses of your example code.