Repository navigation
unit module: behavior of Gauss units #5736
Description
I am having some problem using the astropy unit module, in particular with the Gauss units (magnetic flux density).
Let me remind you that Gauss is a cgs unit: 1 Gauss =1 cm^(-1/2) g^(1/2) s^(-1).
Here is what I get when I define a B value:_
from astropy import units as u
B = 1*u.Gauss
print(B)
#1.0 G
print( B.cgs )
#1.0 G
...it looks like the G units are correctly assumed cgs.
Now I want to estimate the energy per particle, so I need to square and divide by the density:
n_e = 100 * u.cm**(-3)
E_mag = B**2/n_e # forget about 4pi factors...
print(E_mag)
# 0.01 cm3 G2
which is correct, but units should realy be g cm2 / s2… I guess it really likes using G!
But just to be check
print(E_mag.decompose())
1e-16 kg2 m3 / (A2 s4)
which is in MKS… Strange, for something that is defined in cos
(Gauss is cgs; corresponding MKS unit is Tesla).
Problems start if I add this energy density to another energy density, say
the kinetic energy of a proton at 100km/s, given by:
from astropy.constants import m_p
m_h = m_p.cgs
v_0 = (100 * u.kilometer/u.second).cgs
E_kin = 1/2. * m_h * v_0**2
print(E_kin)
#8.363108885e-11 cm2 g / s2
in cgs units, as expected. But if I add the two energies I get a dimensional error
print(E_kin + E_mag)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/robberto/anaconda/lib/python2.7/site-packages/astropy/units/quantity.py", line 295, in __array_prepare__
converters, result_unit = UFUNC_HELPERS[function](function, *units)
File "/Users/robberto/anaconda/lib/python2.7/site-packages/astropy/units/quantity_helper.py", line 290, in helper_twoarg_invariant
return get_converters_and_unit(f, unit1, unit2)
File "/Users/robberto/anaconda/lib/python2.7/site-packages/astropy/units/quantity_helper.py", line 284, in get_converters_and_unit
.format(f.__name__))
astropy.units.core.UnitConversionError: Can only apply 'add' function to quantities with compatible dimensions
Again, If I decompose
print(E_kin.decompose())
#8.363108885e-18 kg m2 / s2
print(E_mag.decompose())
#1e-16 kg2 m3 / (A2 s4)
I see that I am stuck with the Gauss behaving as a MKS unit. This seems to be an error, or at least a feature that is not well documented.
Activity
pllim commentedon Jan 24, 2017
Hmm. What Astropy version are you using? I can't even get the first part of your example to work.
mrobberto commentedon Jan 25, 2017
bsipocz commentedon Jan 25, 2017
@mrobberto - As you're on the LTS branch, could you try it with e.g 1.0.10 the latest version from there? I get the same error as @pllim using v1.3.
mrobberto commentedon Jan 25, 2017
I have just tried with v.1.1.2 and:
print (E_kin,E_mag)
(<Quantity 8.363108885e-11 cm2 g / s2>, <Quantity 0.01 cm3 G2>)
which should be correct if G is a cgs unit (as it should be), but cannot make the sum:
print (E_kin+E_mag)
UnitConversionError: Can only apply 'add' function to quantities with compatible dimensions.
I get this same error if I decompose:
print(E_kin.decompose()+E_mag.decompose())
UnitConversionError: Can only apply 'add' function to quantities with compatible dimensions.
pllim commentedon Jan 25, 2017
Yes, other than
B.cgsnot working in 1.3, the rest is pretty much the same. Not that it matters for this problem but I don't think.cgsis necessary forv_0calculation.@mhvk , do you know what is happening here?
jzuhone commentedon Feb 22, 2017
Hi all,
This issue was pointed out to me and I wanted to comment on it from the perspective of someone who has gotten bit by this same issue in a different context. I'm one of the yt developers and we have a similar symbolic units system to AstroPy, and last year I implemented a system for translating betweek different unit systems (e.g., MKS, cgs, imperial, etc.).
It is true that numerically speaking 1 G = 1.0e-4 T. However, they are actually not in the same dimensions, because the MKS unit system has current as a fundamental dimension and Tesla are defined in terms of it. cgs units do not have current:
1 G = 1 g^0.5 / (cm^0.5 ^ s)
1 T = 1 kg / (A * s^2)
I admittedly am not an expert in how the AstroPy unit code works, but I have used it and I suspect that what's happened here is that G has been defined in terms of T which means that it gets reduced to the second dimensional form above instead of the first. Strictly speaking, for symbolic unit systems like this G should not be formulated in terms of T if you want to keep the base dimensions consistent with their usual definitions.
For more information on how we handled this in yt, see the following document:
http://ytep.readthedocs.io/en/latest/YTEPs/YTEP-0028.html#special-handling-for-magnetic-fields
I'm not sure if this helps, but if it does that would be great.
mhvk commentedon Apr 12, 2021
closing in favour of #4359 - really, the user has to have a way to tell they are working in (one of the) cgs systems