Support natural units (hbar = c = 1)

[robinro]

In relativistic physics it's common to set hbar = c = 1. This relates meter to second and Joule to second.
Similarly k_b = 1.

I'd like to see support for this together with an explicit warning about the use of natural units.

Results could then be
1 ns -> m = 0.299792 m (assuming c=1)

1 fm-> 1/GeV = 0.806554 GeV⁻¹ (assuming hbar=c=1)

[sharkdp]

Thank you for the feedback!

I see two ways how this could be implemented

• Introduce a new mode (enable natural_units) which completely switches the behavior of insect where it basically introduces combinations of c, h_bar and k_B in the background in order to convert between units that can otherwise not be unified. If the user enters 1 ns -> m, insect would calculate 1 ns * c -> m and show the result 0.299792 m (potentially with some warning about c=1).
• Introduce a new set of units m_nat, s_nat, eV_nat, ... that is unrelated to the SI-set of units but shows the expected conversion behavior, i.e. 1 ns_nat -> m_nat would result in 0.299792 m_nat

To be honest, I'm not particularly fond of either of those options. Especially since it is already possible to do similar calculations with a minimal overhead:

>>> 1 ns * c -> m

  1 ns × c ➞ m

   = 0.299792 m

>>> 1 fm / (h_bar * c) -> 1/GeV

  1 fm / (h_bar × c) ➞ 1 / GeV

   = 5.06773 GeV⁻¹

What do you think?

(did you set h=1 instead of h_bar=1 in your fm -> GeV⁻¹ calculation?)

[sharkdp]

@robinro Closing this as there is no further feedback and I don't see a huge benefit.

[jhrmnn]

I have the same request, so I'm writing to a closed issue. Note that there are different sets of natural units. The one OP seems to be after, and me as well, are Hartree atomic units.

I think that the task of adding full support for these can be split in two parts:

1. Add any conventional units. For Hartree atomic units, it would be 1 hartree (Ha) = 27.211386245988 eV (hartree) and 1 bohr = 0.529177210903 angstrom. Or add full support for user-defined units as discussed in Dummy Units #136 (with the help of Add configuration command  #107 perhaps).

2. Add support for "unit reduction". Say I get a result that is polarizability, which has the units of charge^2 length^2 / energy, let's say I get it in coulomb^2 angstrom^2 / eV. Now I want to be able to say -> [Hartree atomic units], which would mean that 1 coulomb -> 1.602176634e-19 [unit_charge], 1 angstrom -> 1/0.529177210903 [unit_length = bohr], and 1 eV -> 1/27.211386245988 [unit_energy = hartree].

@sharkdp What do you think?

[sharkdp]

Thank you for the feedback!

1. Add any conventional units. For Hartree atomic units, it would be 1 hartree (Ha) = 27.211386245988 eV (hartree) and 1 bohr = 0.529177210903 angstrom. Or add full support for user-defined units as discussed in Dummy Units #136 (with the help of Add configuration command  #107 perhaps).

Definitely sounds like a sensible feature request.

It's not quite clear to me how we would deal with the conflict between unit names and constants. For example: we already have elementaryCharge as a constant. Do we want to add a unit with the same name? With a different name?

Or do we want to somehow support a special conversion "to constants", which would basically just divide by that quantity and make sure that the result is a scalar. For example:

1 MeV/c^2 -> electronMass

could be executed as: "make sure that both sides of the arrow have matching units (otherwise, print an error). Then, print the result of 1 MeV/c^2 / electronMass".

2. Add support for "unit reduction". Say I get a result that is polarizability, which has the units of charge^2 length^2 / energy, let's say I get it in coulomb^2 angstrom^2 / eV. Now I want to be able to say -> [Hartree atomic units], which would mean that 1 coulomb -> 1.602176634e-19 [unit_charge], 1 angstrom -> 1/0.529177210903 [unit_length = bohr], and 1 eV -> 1/27.211386245988 [unit_energy = hartree].

Interesting idea. This is related to #184 which looks for a way to say: convert this quantity to base SI units.

Conversion to some natural system of units would involve one additional step where Insect would basically divide by an appropriate product like unit_charge^2 bohr^2 hartee^(-1), similar to how the conversion example above would work.

[jhrmnn]

It's not quite clear to me how we would deal with the conflict between unit names and constants.

In a way, there is no semantic difference between a unit name and a constant. A physical unit is a constant. 1 hartree is equivalent to 1*E_h, E_h being the Hartree energy, a constant. 1 m is just 1*(a length constant called meter). Does Insect treat internally units and constants differently?

In atomic units, elementaryCharge (a constant) is basically the unit of charge, and it doesn't have a name besides "elementary charge".

Or do we want to somehow support a special conversion "to constants"

This would make perfect sense, and given what I wrote above, it's actually equivalent to #184. Expressing something in the base SI units is in fact just dividing the results by the "SI constants" (m, kg, s) and making sure the results is a scalar.

[Vectornaut]

Seconding what @jhrmnn said! A physical constant is a unit, so Insect should be able to convert to, as well as from, units like the speed of light, the elementary charge, and Planck's constant.

>>> 4e4 km/s -> c

  40000 km / s ➞ c

   = 0.133426 c

>>> 0.2 nA * 0.8 ns -> elementaryCharge

  0.2 nA × 0.8 ns ➞ elementaryCharge

   = 0.998642 elementaryCharge

>>> 0.03 fJ * 0.2 fs -> h_bar

  0.03 fJ × 0.2 fs ➞ h_bar

   = 56.8951 h_bar

Since the Kelvin has officially been redefined as a unit of energy, Insect should also be able to convert between Kelvin and other units of energy.

>>> 77 K -> J

  77 K ➞ J

   = 1.0631e-21 J

>>> 1e-24 BTU -> K

  1e-24 BTU / 1e+24 ➞ K

   = 76.4174 K

[sharkdp]

In the follow-up project for Insect, a lot of this is now possible. Users can define their own physical units (and dimensions). We also support some unit systems like Planck units, Stoney units (use units::stoney), and Hartree atomic units (use units::hartree).

Issue sharkdp/numbat#116 has some more details and open points.

In any case, I would be glad to get some feedback on Numbat. Having the possibility for users to define their own units was one of the main reasons that I completely rewrote Insect from scratch.