There seems to be quite a bit of confusion around using temperature units in Mathcad. When we describe the implementation and the proper way to use temperature units, the question of *“**Why on earth would you do it like that?**” *often arises. Allow us to explain…

## Simple units conversion

In most cases, unit conversions are simple: Converting a quantity, say length, from one unit (e.g. inches) to another (e.g. meters) involves multiplying the quantity by a factor (namely 0.0254). This is very convenient because the following calculations can be done without any ambiguity:

Why am I even writing about this? This stuff is trivial.

## A paradox with temperature units

Well, when it comes to temperature, things get a bit tricky. Consider a set of similar equations involving temperatures in degrees Kelvin and Celsius. Define

The result of subtracting the two will depend on interpretation of what these quantities mean. For example, if T_{1} represents the air temperature of 0°C, then the expression T:=T_{1}-T_{2} would indicate the result of temperature change by 10°C, yielding air temperature of -10°C. Expressing this *temperature* in different units will yield 263.15K, 14°F, etc.

However, if we look at the expression ΔT:=T_{1}-T_{2}, and interpret it to mean the *temperature difference* of air (at the temperature of 0°C) and a heating element (at temperature of 10°C), then the *temperature differential* would be -10°C. Expressing this *temperature differential *quantity in other units will yield -10K, -18°F, etc.

Something is not adding up here! We assigned the same values to T_{1} and T_{2}, and got different results for the difference T_{1}-T_{2} when expressed in K, °F, etc., because we stored the first result as an *absolute temperature* value and the second result as a *temperature differential.*

Perhaps another example will clarify the matter. Consider the case of a hot summer day. At noon, the temperature is T_{1}:=100°F. The forecast predicts the temperature will drop by 30°F by sunset, so intuitively, we might set T_{2}:=30°F. Now, also intuitively, we might define T:=T_{1}-T_{2} and expect to get 70°F for the temperature at sunset. When we implement this calculation in Mathcad using *absolute temperature* values for both T_{1} and T_{2}, we don’t exactly get 70°F:

But, if we define T_{2} as a *temperature difference*, then our sunset temperature is what we intuitively expected:

The apparent paradox lies in the fact that there are two different conversions between degrees Kelvin and degrees Celsius/Fahrenheit depending whether we are referring to the *absolute temperature* of an object or a substance or a *temperature difference*.

When converting from °C to K, if we interpret a quantity as the *absolute temperature* of an object or a substance, we use conversion K = °C + 273.15. However, if the quantity represents a *temperature difference*, the conversion factor is 1. Thus in K, the above equations from the very first example would look like:

The second example would look like:

## Is there a problem?

Before I go into how to resolve the ambiguity in temperature conversions, is this a problem? Usually not if doing calculations by hand or using only degrees Kelvin. However, if one wants to use a calculation tool to do such calculations and automatic conversions, the tool needs to know what the author had in mind. This is useful to automate the process of conversion enabling the author to display results in desired units, or to catch the possible errors.

When communicating with engineers in different countries, it’s important to enable conversions to a unit system that is most commonly used. This makes documents easier to read. The units should always be explicit, i.e. never say temperature is 10, as this is guaranteed to cause errors.

## Resolving the ambiguity

If we look closely at the examples above, the hints to interpret T_{1}, T_{2} and the result were subtle. In one case, I used ** T** to name the result, implying it is a temperature of an object or piece of matter. And in the other I used

**to hint that the result was a**

*ΔT**temperature difference*. That’s too subtle and it would not work in situations like T+(T

_{1}-T

_{2}).

## Algebra of temperatures and temperature differences

One approach comes from an observation that it (almost – see below) never makes sense to add two temperatures together. Using ** T** for temperature and

**for temperature difference, we can derive the following simple algebra:**

*ΔT*** T_{1}** +

**yields**

*T*_{2}*an error*

** T_{1}** –

**yields**

*T*_{2}

*ΔT*** ΔT_{1}** +

**yields**

*T*_{2}

*T*** ΔT_{1}** –

**yields**

*T*_{2}*an error*

** T_{1}** +/-

**yields**

*ΔT*_{2}

*T*** ΔT_{1}** +/-

**yields**

*ΔT*_{2}

*ΔT*Such system would still require declaring some of the quantities as either a temperature or temperature difference, but would help catch mistakes. It also has a drawback in not allowing temperatures to be added in computing an intermediate result such as average temperature.

## A new unit for temperature difference

An alternative approach takes directly from the difference in converting from degrees Celsius to Kelvin when talking about a temperature and a temperature difference. Specifically, one can define two units:

°C – for the temperature in degrees Celsius, and

Δ°C – for the temperature difference in degrees Celsius

Thus we can define T_{2} as either:

Note that, for degrees Kelvin, this distinction is not necessary. With this system we can disambiguate the example above:

Assuming that T_{2} is a temperature difference,

And assuming T_{2} is a temperature (not a temperature difference),

This solves the problem, but requires the engineer to be careful in specifying different units for temperatures and temperature differences – something that we don’t normally worry about. It is mathematically correct, but it is also tricky…

Visit our dedicated page focused on engineering unit conversion.

Would be nice to be able to specify base unit for temperature in Mathcad (K, C or F). Then we would get rid of this mess, but have no conversion between different temperature scales. Would be nice to have base units for temperature in Mathcad, and a convertTemp function if you needed to convert between different temperature scales.

See please http://communities.ptc.com/docs/DOC-3251

We don’t normally worry about delta temperatures because it is something built into our various languages. When I say there will be a 5° drop in temperature tonight, everyone knows that it is a delta. The only reason that your example using Kelvin works is because Kelvin is “absolute zero”-based. But you don’t really mean 10K in the example, I think. If I saw that written and didn’t know the context, I’d think “Man, that’s cold!” But if I saw 10 deltaK, I’d know what that means. This whole discussion is really triggered by units in computing engines. Were I programming in, say, MATLAB, I’d not use units, and no one would be the wiser. If my readers caught me on a good day, I might even have defined some MATLAB variable as ExhaustGasDeltaK. No confusion. I’d do the same in Mathcad, but because I can use units here, I’d have to take care to use the appropriate delta_T unit.

I /can/ say that there will be a 5K drop in temperature tonight, and then when I say

T_now:=20°C

T_change:=-5K

I can then say

T_later:=T_now + T_change

Mathcad handles all the temperature conversions well, but I don’t see a way to get around using deltaT unless we all agree to switch to K for all our engineering (and maybe social) temperatures. That’s a big step for the planet. We have not made a number of simpler changes to a more convenient form, so this is not gonna happen in my lifetime. It’s not really necessary, is it? If we already have a language construct that handles temperature differences, then surely deltaT is just a mechanical implementation of that construct.