Plus42: incorrect behaviour in equation using temperature UOM

[Marco Polo]

I am starting using Plus42 more seriusly and found a glitch regarding the temperature handling in UOM.
Let's take the usual equation for calculating the LMTD of a heat exchanger:

Code:

'LMDT:LMDT=(DThot-DTcold)/LN(DThot/DTcold)'

Solving for LMDT having, for example

Code:

DThot = 9_°C
DTcold = 6_°C

it shall give 7.3989_°C, as it happens in 48/50 series.
On Plus42 the result is incorrectly -265.751_°C

Apparently 273.15 is subtracted to the correct result expressed in °C.

This behaviour is present in Plus42 v.1.1.11

Cheers
Marco Polo

[ht003]

(05-27-2024 01:32 PM)Marco Polo Wrote:  I am starting using Plus42 more seriusly and found a glitch regarding the temperature handling in UOM.
Let's take the usual equation for calculating the LMTD of a heat exchanger:

Code:

'LMDT:LMDT=(DThot-DTcold)/LN(DThot/DTcold)'

Solving for LMDT having, for example

Code:

DThot = 9_°C
DTcold = 6_°C

it shall give 7.3989_°C, as it happens in 48/50 series.
On Plus42 the result is incorrectly -265.751_°C

Apparently 273.15 is subtracted to the correct result expressed in °C.

This behaviour is present in Plus42 v.1.1.11

Cheers
Marco Polo

On an IPAD (IPadOS 17.4.1) PLUS42 V. 1.1.11 delivers the correct result:
7,398910387129295058023730205472203 °C
Best
Dieter (ht003)

[Marco Polo]

(05-27-2024 03:16 PM)ht003 Wrote:  On an IPAD (IPadOS 17.4.1) PLUS42 V. 1.1.11 delivers the correct result:
7,398910387129295058023730205472203 °C
Best
Dieter (ht003)

Thank you for your feedback.

I checked more deeply and found that the correct result is obtained using the solver in direct mode, while numeric mode gives the wrong result.
Imho, definitively a bug.

[Thomas Okken]

This is indeed a bug.

When the numeric solver calls the function to be solved and receives a return value with an attached unit, it needs to get rid of the unit before being able to use the return value in the root finding iteration algorithm. This unit removal needs to be done in a way that gives consistent results, even if the function can return results with different units at different iterations. (Of course the units returned by the function must always be consistent between iterations: returning m in one iteration and ft in another is fine, but returning m in one iteration and m^2 in another is not.)

The current implementation performs this consistent unit removal using UBASE and then UVAL. This works fine in most cases, except with °C and °F, because of the offset introduced when UBASE converts those to K.

This could be fixed by remembering the unit returned by the first successful call of the function to be solved, and converting all subsequent return values to that initial unit using CONVERT, and then using UVAL to get the scalar. Or maybe °C and °F should be handled completely separately and not be considered compatible with anything, even each other.

[Albert Chan]

(05-27-2024 04:21 PM)Thomas Okken Wrote:  The current implementation performs this consistent unit removal using UBASE and then UVAL. This works fine in most cases, but not with °C and °F, because of the offset introduced when UBASE converts those to K.

Perhaps we can add delta temperature unit? Δ°C = Δ°K, Δ°F = Δ°R, without offset

(9_Δ°C - 6_Δ°C) / LN( 9_Δ°C / 6_Δ°C )
= (9_Δ°K - 6_Δ°K) / LN( 9_Δ°K / 6_Δ°K )
= 3_Δ°K / LN(1.5)
= 3_Δ°C / LN(1.5)

We always convert to Kelvin, do math, then restore.
If 2 temperatures are plain Celsius, we get this instead.

(9_°C - 6_°C) / LN( 9_°C / 6_°C )
= ((9+273.15)_°K - (6+273.15)_°K) / LN( (9+273.15)_°K / (6+273.15)_°K )
= 3_Δ°K / LN(282.15/279.15)
= 3_Δ°C / LN(282.15/279.15)

Sum of temperatures make no sense. But with delta temp units, it does.

1_°C + 2_Δ°C = 3_°C      → 274.15_°K + 1_Δ°K = 275.15_°K

[Thomas Okken]

Plus42 handles subtraction of temperatures by assuming both inputs are absolute, and returning a relative result, and it handles addition of temperatures by assuming the first (level 2 or Y) is absolute, the second (level 1 or X) is relative, and the result is absolute. You can see this at work by comparing the results of 1_°C 1_°F + and 1_°F 1_°C +.

In the case of the numerical solver trying to deal with returned values with °C or °F units, it has no way to know whether those values represent relative or absolute temperatures, so it looks like the only safe thing to do is introduce the requirement that functions called by the numerical solver must either always return °C or never; and must either always return °F or never, so the conversion issues with those two units can be avoided.

The HP-48 series avoids these ambiguities by not allowing addition and subtraction of temperatures at all, or at least not using the + and - operators, but I chose a more permissive approach in Plus42, based on the idea that users just have to know what they are doing. But users are intelligent while SOLVE is not, so this needs fixing. I'll try to release a fix tomorrow.

[Marco Polo]

After a little bit of analysis i think the bug relies on how the "zero" is treated during iterations.
When converting any temperature to absolute, the "zero" becomes 273.15 K and the solver found the convergence considering 273.15 instead of zero

[Marco Polo]

(05-27-2024 06:32 PM)Thomas Okken Wrote:  I'll try to release a fix tomorrow.

I just tested the release 1.1.12 just released on Google Play.
The problem seems solved.
I could not yet try the Windows version as the antivirus used by my company needs some hours to validate new executables.

Chapeau for the outstanding response time :-)

EDIT: tested also Windows version. It seems ok, too.