Post Reply 
Plus42: incorrect behaviour in equation using temperature UOM
05-27-2024, 01:32 PM
Post: #1
Plus42: incorrect behaviour in equation using temperature UOM
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
Find all posts by this user
Quote this message in a reply
05-27-2024, 03:16 PM
Post: #2
RE: Plus42: incorrect behaviour in equation using temperature UOM
(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)
Find all posts by this user
Quote this message in a reply
05-27-2024, 03:25 PM
Post: #3
RE: Plus42: incorrect behaviour in equation using temperature UOM
(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.
Find all posts by this user
Quote this message in a reply
05-27-2024, 04:21 PM (This post was last modified: 05-27-2024 04:58 PM by Thomas Okken.)
Post: #4
RE: Plus42: incorrect behaviour in equation using temperature UOM
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
05-27-2024, 05:15 PM
Post: #5
RE: Plus42: incorrect behaviour in equation using temperature UOM
(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
Find all posts by this user
Quote this message in a reply
05-27-2024, 06:32 PM
Post: #6
RE: Plus42: incorrect behaviour in equation using temperature UOM
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
05-28-2024, 07:41 AM
Post: #7
RE: Plus42: incorrect behaviour in equation using temperature UOM
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
Find all posts by this user
Quote this message in a reply
05-28-2024, 07:54 AM (This post was last modified: 05-28-2024 10:09 AM by Marco Polo.)
Post: #8
RE: Plus42: incorrect behaviour in equation using temperature UOM
(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.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: