10

I'm trying to define a variable with the value of the thermal constant $V_T$. The value of the thermal constant is given in Volts as $V_T = \frac{k T}{q}$, where $k$ is the Boltzmann constant and $q$ is the charge on an electron.

Why am I getting different results from the following two inputs:

k = Quantity["BoltzmannConstant"];
q = Quantity["ElementaryCharge"];
T = UnitConvert[Quantity[25, "DegreesCelsius"], "Kelvin"];
Subscript[v, t] = UnitConvert[(k T)/q, "Volts"]

Which is returning the expected value of Quantity[0.0256926, "Volts"].

k = Quantity["BoltzmannConstant"];
q = Quantity["ElementaryCharge"];
T = Quantity[25, "DegreesCelsius"];
Subscript[v, t] = UnitConvert[(k T)/q, "Volts"]

Which is returning the unexpected value of Quantity[0.590610, "Volts"].

The only difference between the two is that in the first one I convert the from Celsius to Kelvin; however, the inherent physical value is not changing. So when I convert to Volts, shouldn't I get the same result from both inputs?

sgdsgyhetwaraw
  • 489
  • 2
  • 9
  • @march I might not be understanding what you are saying correctly, but it seems that Mathematica does know the difference between an absolute and non-absolute unit, because when I do UnitConvert[Quantity[25, "DegreesCelsius"], "Kelvin"] I get 298.15 K. If it wasn't able to differentiate between absolute and non-absolute wouldn't I just get 25 K? – sgdsgyhetwaraw Jan 28 '19 at 18:07
  • Hmm. I take back my comment! When I run your code on my own copy of Mathematica, I get the same result for both. Try quitting the kernel and trying again. If it still give you the wrong answer, then perhaps this is a bug. What version are you using? – march Jan 28 '19 at 18:10
  • @march I just tried again and I'm still getting the different answers. I even tried restarting my computer and nothing changed. I'm on Mathematica 11.3. I will submit a support ticket and see what they say. Thanks for testing it. – sgdsgyhetwaraw Jan 28 '19 at 18:21
  • And sorry to call into question your understanding of absolute temperature! If we can get some confirmation from other members of the community or from Wolfram, then we can add the bugs tag to this question. – march Jan 28 '19 at 18:23
  • 3
    Never use Celsius when doing physics, it only leads to trouble. Physical units cannot deal with offsets, and the conversion between temperature units is a kludge: the system has to guess somehow whether you mean an absolute temperature (take offset into account) or a temperature difference (don't take offset into account). – Roman Jan 28 '19 at 19:33
  • @march I can confirm that I get the same as OP (11.3 on MacOS). If I change the 25C to 0C, I get an answer of 0V. It seems like maybe it's doing the multiplication first and then applying the conversion factor to the result or something? Roman I agree that working in Kelvins is easier, but MMA does actually have "KelvinsDifference" and "DegreesCelsiusDifference" in order to differentiate from "Kelvins" and "DegreesCelsius", so you would think it should be able to tell the difference if you really want it to.. – MassDefect Jan 28 '19 at 20:29
  • @Roman The reason I wanted to use Celsius was because I wanted to use "room temperature". If I would have wanted to use Kelvin, I would have had to convert it anyways. My reasoning was not have Mathematica convert it for me in order to avoid calculation mistakes on my end. It seems like that would be the whole point of having a units system in the program. – sgdsgyhetwaraw Jan 28 '19 at 20:38
  • 1
    I would also check this out: http://reference.wolfram.com/language/tutorial/TemperatureUnits.html – chuy Jan 28 '19 at 21:25
  • @MassDefect I'm aware of the "KelvinsDifference" and "DegreesCelsiusDifference" units and would still strongly recommend against using them, they invite more trouble than they are worth. If at all, use them (and "DegreesCelsius") once in the definition of a quantity and immediately convert everything to "Kelvins" to remove doubts (as in the first usage, T = UnitConvert[Quantity[25, "DegreesCelsius"], "Kelvin"];). All equations from physics assume that quantities are in Kelvins. – Roman Jan 28 '19 at 21:33
  • @chuy I think the link you give is a good illustration of why I never use any units other than "Kelvins". Just count the number of warnings and pitfalls listed there. – Roman Jan 28 '19 at 21:46
  • What to discuss here? Erroneous application UnitConvert[] gives an erroneous result. – Alex Trounev Jan 29 '19 at 00:46
  • After all of this (especially the warnings on that page), I would suggest that it's not a bug. It's not clear what it even means to make an affine transformation of a base unit inside a derived unit, which is why it's best to convert to absolute temperature first. Mathematica doesn't seem to scan the expression first, so it compute the numbers and then converts the units, which is the wrong way to go. – march Jan 29 '19 at 01:10
  • This is definitely a bug. It's documented syntax. What you are doing is 100% correct. – b3m2a1 Jan 29 '19 at 18:55
  • @b3m2a1. Can you show me where in the documentation? The page linked by chuy above makes the point that UnitConvert and Times are non-commutative operations for quantities with units of temperature, which is exactly why many people are suggesting to UnitConvert first. Otherwise, an expression involving products of Quantitys inside a UnitConvert needs to be scanned first to convert the temperature quantities before converting units. And what do you do if you multiply all of the quantities first, save it to a variable, and then UnitConvert? There's no way to get that right. – march Jan 30 '19 at 00:03
  • @march if you're going to write a function called UnitConvert it had better correctly convert units. WRI simply mis-implemented this function. If it has to scan the expression to work properly then it has to scan the expression to work properly. It's good to know why this bug happens, but this is still a bug. Sure the correct way might be slower, but that's where you use heuristics and Options to allow people to speed it up rather than leaving gotchas and bugs for users to fall into – b3m2a1 Jan 30 '19 at 02:26

2 Answers2

1

Correct Temperature Conversion Code

k = Quantity["BoltzmannConstant"];
q = Quantity["ElementaryCharge"];
T1 = UnitConvert[Quantity[25, "DegreesCelsius"], "Kelvins"];
Subscript[v, t] = UnitConvert[k T1/q, "SI"]

(*Quantity[2.56926, "Centivolts"]*)
Alex Trounev
  • 44,369
  • 3
  • 48
  • 106
  • 3
    Can you say exactly how the OP is using UnitConvert incorrectly? – Jason B. Jan 29 '19 at 14:43
  • @JasonB. I showed how to use correctly. And how to use incorrectly showed OP. He did not specify in which unit system the conversion is performed. See tutorials: UnitConvert[quantity, targetunit] attempts to convert the specified quantity to the specified targetunit. A targetunit specification can also be one of the following unit systems: "SIBase", "SI", "Imperial", or "Metric". When using heterogeneous units, it is necessary to specify the unit system. – Alex Trounev Jan 29 '19 at 15:08
  • 2
    You showed that both you and OP are using documented syntax for UnitConvert, and you claim that yours is correct while his is incorrect. So where on the documentation page for UnitConvert does it say that you must use a unit system rather than a target unit when using heterogeneous units? – Jason B. Jan 29 '19 at 17:06
  • See Scope UnitConvert[{Quantity[3., "Feet"], Quantity[8., "Inches"], Quantity[3., "Pounds"], Quantity[8., "Ounces"]}, "SI"] – Alex Trounev Jan 29 '19 at 17:32
  • How does that example show that OP's syntax is incorrect? – Jason B. Jan 29 '19 at 17:40
  • @JasonB. I'd poke people inside to at the very least send out a Message when converting products of "TemperatureUnit" that aren't in "Kelvins". That's clearly the way to go since it'd be hard to convince them to revert the behavior to work correctly. – b3m2a1 Jan 30 '19 at 02:30
  • @JasonB. For me it is obvious that if there is an expression with different Quantity[] we must specify unit system to correctly calculate the expression. – Alex Trounev Jan 30 '19 at 12:17
  • 2
    There is something weird going on, because 2.15 mV is the incorrect value. The correct value is 25.7 mV. So both your methods agree with eachother, but they return the wrong value. Also, according to the link you posted, the default for the second parameter on UnitConvert is SIBase, so I wouldn't expect it to make a difference whether it is implied through the defaults or explicitly added. – sgdsgyhetwaraw Jan 31 '19 at 16:19
  • @w1res You're right, I added the code – Alex Trounev Jan 31 '19 at 17:53
1

I contacted support and they said they were "able to reproduce the issue." It seems like this is unintended behavior and will be fixed.

sgdsgyhetwaraw
  • 489
  • 2
  • 9