DM42 resets during program run

Post here to share useful tips and tricks, to ask questions about using your DM42 or to report software-related problems
prd6920766@gmail.com
Posts: 4
Joined: Fri Apr 16, 2021 6:07 am

DM42 resets during program run

Post by prd6920766@gmail.com »

I have a program that runs fine on many RPN platforms but causes the DM42 to reset and lose memory after several hours. Other platforms that run the program fine include Free42s (on IPad), DM41x, wp34s, and HP41c. Some of these platforms are not appropriate due to limited precision, excessive calculation times.

The program is a numerical solution to a lunar orbit. I'm doing a numerical solution because this is part of a n-body problem solution for which, of course, there is no closed-form simple analytic solution.

Abstract of the program

Starting constants and conditions:
GMe = 3.986004418E14
Rinit = 363,228,900 (meters, perigee of lunar orbit)
Vinit = 1082 (m/s, velocity of moon at perigee)
Oribit period = 2,416,890 (s) (to use as max time)
Delta time = 2.41689 (s)

Loop:
update radius for delta time
up acceleration vector for delta time
update velocity vector for delta time
update position vector for delta time
update accumulated time by delta time
End loop when accumulated time > orbital time

(Program is 111 lines long, has some intermediate outputs; position, velocity vectors stored in registers).

In this instance, intention is to run 1 million iterations.
What happens is program runs for several hours, usually up to accumulated time of maybe 1,500,000 simulated seconds, or about 650,000 iterations. When calc dies, memory is lost so I don't know these times exactly.
As program runs, I periodically monitor intermediate outputs--all values reasonable, no warnings, no indications of impending reset.

Then...eventually, it does reset, screen shows:
"DM Calculator Platform
DMCP v3.20 (IFC 0.315) BASE
...
Program Loaded DM42PGM
Version 3.16/2.5.20
Press Exit to continue.
"
This is 100% reproducible.

Physical status:
Calc is USB connected, known good cable, known good USB power supply.
Post crash (reset) battery indicator shows all bars (near 100% charge).
Calc is on fan-cooled bench, never gets warm (don't think? thermal shutdown is at play)

Other platforms:
DM41x same program runs to completion (though precision is not good enough).
Free 42s (IPad) same program has run up to 10 billion iterations, ie delta time = 0.000241689, (takes weeks and precision is not good enough).
HP41c(v,x) same program runs to completion (has run more iterations but requires weeks, AC power adapter; precision not good enough).
grsbanks
Posts: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: DM42 resets during program run

Post by grsbanks »

There have been several updates of the DM42 firmware since the one you're using. I would suggest that you bring yours up to date and try again.

viewforum.php?f=16
There are only 10 kinds of people in the world: those who understand binary and those who do not.
whuyse
Posts: 198
Joined: Thu Dec 21, 2017 1:23 pm

Re: DM42 resets during program run

Post by whuyse »

It would also help if you posted the program itself; I'd like to see what it is you're doing.
prd6920766@gmail.com wrote:
Wed Apr 21, 2021 11:58 pm
Free 42s (IPad) same program has run up to 10 billion iterations, ie delta time = 0.000241689, (takes weeks and precision is not good enough).
Do you mean that the precision of Free42 is not good enough? It is the same as in the (slower) DM42.
Or, that even after 10 billion iterations, the solution is still not accurate enough? Then, perhaps a calculator is not the right
tool ;-)

Cheers, Werner
41CV†,42S,48GX,49G,DM42,DM41X,17BII,15CE, DM15L
grsbanks
Posts: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: DM42 resets during program run

Post by grsbanks »

whuyse wrote:
Thu Apr 22, 2021 1:08 pm
Do you mean that the precision of Free42 is not good enough? It is the same as in the (slower) DM42.
There are two versions of Free42 for desktop/laptop computers. There is Free42 Decimal, which is the same as the version embedded in the DM42, but there is also Free42 Binary, which uses standard 64-bit(?) floating point.
There are only 10 kinds of people in the world: those who understand binary and those who do not.
Thomas Okken
Posts: 1100
Joined: Tue May 02, 2017 5:48 pm
Location: Netherlands
Contact:

Re: DM42 resets during program run

Post by Thomas Okken »

grsbanks wrote:
Thu Apr 22, 2021 5:34 pm
whuyse wrote:
Thu Apr 22, 2021 1:08 pm
Do you mean that the precision of Free42 is not good enough? It is the same as in the (slower) DM42.
There are two versions of Free42 for desktop/laptop computers. There is Free42 Decimal, which is the same as the version embedded in the DM42, but there is also Free42 Binary, which uses standard 64-bit(?) floating point.
True, but prd692etc mentioned insufficient precision in a test on their iPad, so that would have been the decimal version, unless they built Free42 Binary for iOS themselves. (This is possible, it's a simple matter of picking the "Free42 Binary" target in the Xcode project, but I don't publish the binary version for iOS or Android myself.)
prd6920766@gmail.com
Posts: 4
Joined: Fri Apr 16, 2021 6:07 am

Re: DM42 resets during program run

Post by prd6920766@gmail.com »

DM42, Another reset, loss of program, data, approx 80 hours into execution of SOrbit (attempted to post program earlier; post may have been too large, format wrong, ... it wasn't posted..); delta t set to 0.02416890, Tmax = 2,416,890 sec (in case it does get posted).
Can't see how to blame env., other calcs doing fine same setup.
Have not reflashed yet (don't know how on Linux, don't have Windows).
Don't have issues with Free42 runing on other platforms.
grsbanks
Posts: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: DM42 resets during program run

Post by grsbanks »

How to reflash the calculator is described in the manual on the website. It is done on Linux in exactly the same way as on Windows and MacOS.

https://technical.swissmicros.com/dm42/ ... date_guide

As for the previous post, I did not let through and had the forum send you an explanation. Basically, you had posted what looked like 4 or 5 times exactly the same thing concatenated together, so I asked you to edit it down so that there was only one copy of all the information.
There are only 10 kinds of people in the world: those who understand binary and those who do not.
prd6920766@gmail.com
Posts: 4
Joined: Fri Apr 16, 2021 6:07 am

Re: DM42 resets during program run

Post by prd6920766@gmail.com »

2nd attempt to post this.

Re-entered the Simple Orbit test program.
Ran the first test at 10E6 iterations. Executed completely in 84 minutes with expected results.
Started a second test at at 10E8 iterations. Approx 80 hours in, reset, loss of program, data.
(I Realize I'm way outside of normal use case envelope, but don't believe I'm misusing the product.)

RE this little test program, what it’s for: it’s a really stripped down simple Newtonian lunar orbit program meant to check on the errors in magnitudes (mostly of the radius vector between earth and moon) as a function of how fine the delta times used. In the complete model I’m building on a PC, I’m looking at errors in functions of order of magnitude jumps in delta time, so I’m doing the same thing here.

Sorry for the listing rather than a binary.

Orbit period of moon is taken to be 2416890 sec. Used as Tmax.
Desired #of iterations Delta T Expected error in x component of radius
10E6 2.41689 13758.3 meters
10E7 0.241689 1375.84 “
10E8 0.0241689 137.584 “
10E9 0.00241689 13.758 “
10E10 0.000241689 1.376 “
10E11 0.0000241689 0.138 “

Running program:
1. preload Reg 00 with # of iterations between display updates, say 100, or 1000.
2. program prompts for delta t (eg. 0.241689 sec – run time approx 14 hours)
3. program prompts for t max (for a single lunar orbit use 2416890)
(I’ve computed the 10E10 and 10E11 results on other platforms, they'd take too long on the DM42.)

Results for position vector will be Reg 04, 05; velocity vector Reg 06, 07.

01 LBL "SOrbit" 45 LBL 04 87 LBL 05
02 363,228,900 46 RCL 04 88 RCL 10
03 STO 04 47 x^2 89 "T="
04 1082 48 RCL 05 90 ARCL ST X
05 STO 07 49 X^2 91 AVIEW
06 0 50 + 92 RTN
07 STO 05 51 ENTER
08 STO 06 52 SQRT 93 LBL 06
09 STO 10 53 STO 01 94 RCL 08
10 "Delta T" 54 RDN 95 ST- 10
11 PROMPT 55 3.986004418e14 96 XEQ 05
12 STO 08 56 X<>Y 100 .END.
13 "T Max" 57 /
14 PROMPT 58 CHS
15 STO 09 59 STO 11
60 RTN
16 LBL 01
17 RCL 08 61 LBL 03
18 ST+ 10 62 RCL 11
19 RCL 09 63 2
20 RCL 10 64 /
21 X>Y? 65 RCL 08
22 GTO 06 66 X^2
23 XEQ 02 67 *
24 RCL 10 68 RCL IND 02
25 RCL 08 69 RCL 01
26 / 70 /
27 RCL 00 71 *
28 MOD 72 RCL IND 03
29 X=0? 73 RCL 08
30 XEQ 05 74 *
31 GTO 01 75 +
76 RCL 11
32 LBL 02 77 RCL 08
33 XEQ 04 78 *
34 4 79 RCL IND 02
35 STO 02 80 RCL 01
36 6 81 /
37 STO 03 82 *
38 XEQ 03 83 ST+ IND 03
39 5 84 RDN
40 STO 02 85 ST+ IND 02
41 7 86 RTN
42 STO 03
43 XEQ 03
44 RTN


So one of the questions: is DM42 the right tool?
Not for entire solar system model. But for checking bits and pieces, intermediate results, etc. – yes, it’s the best easy-to-use, program-in-an-instant, usually sufficiently accurate tool I know of.

Re: precision in quick estimates.
The g++ compilers I use on Linux and Raspberry PI support double double type variable definitions, but the double double types currently are no more precision than double types, 64 bits. IEEE requires only that double doubles be no less precise than doubles. (I’ve written all of my vector and tensor C++ libraries to use double doubles in hopes that the compilers will soon support additional precision.) Meanwhile, it's GMPL libraries. Changes the coding paradigm from “just-enter-the-equation” to “enter-long-sequence-of-function-calls.” Fine. Doing that anyway for the main solar system model. For quick checks, sanity checks, intermediate results, logic verifications, etc. the DM42 is ideal. Quick, efficient RPN entry, excellent precision. Handy! (BTW, I'm also using HP41C MLTI library on a couple of HP41CL's, not nearly so handy--glad someone developed it, but a little too complicated for my purposes.)

Sort of related: It’s really cool to switch between 64bits and 128 bits on the wp34s. Can leave your program in memory, run it at one precision, switch precision, re-run, compare. (Registers do get reorganized.)



































2nd attempt to post this.

Re-entered the Simple Orbit test program.
Ran the first test at 10E6 iterations. Executed completely in 84 minutes with expected results.
Started a second test at at 10E8 iterations. Approx 80 hours in, reset, loss of program, data.
(I Realize I'm way outside of normal use case envelope, but don't believe I'm misusing the product.)

RE this little test program, what it’s for: it’s a really stripped down simple Newtonian lunar orbit program meant to check on the errors in magnitudes (mostly of the radius vector between earth and moon) as a function of how fine the delta times used. In the complete model I’m building on a PC, I’m looking at errors in functions of order of magnitude jumps in delta time, so I’m doing the same thing here.

Sorry for the listing rather than a binary.

Orbit period of moon is taken to be 2416890 sec. Used as Tmax.
Desired #of iterations Delta T Expected error in x component of radius
10E6 2.41689 13758.3 meters
10E7 0.241689 1375.84 “
10E8 0.0241689 137.584 “
10E9 0.00241689 13.758 “
10E10 0.000241689 1.376 “
10E11 0.0000241689 0.138 “

Running program:
1. preload Reg 00 with # of iterations between display updates, say 100, or 1000.
2. program prompts for delta t (eg. 0.241689 sec – run time approx 14 hours)
3. program prompts for t max (for a single lunar orbit use 2416890)
(I’ve computed the 10E10 and 10E11 results on other platforms, they'd take too long on the DM42.)

Results for position vector will be Reg 04, 05; velocity vector Reg 06, 07.

01 LBL "SOrbit" 45 LBL 04 87 LBL 05
02 363,228,900 46 RCL 04 88 RCL 10
03 STO 04 47 x^2 89 "T="
04 1082 48 RCL 05 90 ARCL ST X
05 STO 07 49 X^2 91 AVIEW
06 0 50 + 92 RTN
07 STO 05 51 ENTER
08 STO 06 52 SQRT 93 LBL 06
09 STO 10 53 STO 01 94 RCL 08
10 "Delta T" 54 RDN 95 ST- 10
11 PROMPT 55 3.986004418e14 96 XEQ 05
12 STO 08 56 X<>Y 100 .END.
13 "T Max" 57 /
14 PROMPT 58 CHS
15 STO 09 59 STO 11
60 RTN
16 LBL 01
17 RCL 08 61 LBL 03
18 ST+ 10 62 RCL 11
19 RCL 09 63 2
20 RCL 10 64 /
21 X>Y? 65 RCL 08
22 GTO 06 66 X^2
23 XEQ 02 67 *
24 RCL 10 68 RCL IND 02
25 RCL 08 69 RCL 01
26 / 70 /
27 RCL 00 71 *
28 MOD 72 RCL IND 03
29 X=0? 73 RCL 08
30 XEQ 05 74 *
31 GTO 01 75 +
76 RCL 11
32 LBL 02 77 RCL 08
33 XEQ 04 78 *
34 4 79 RCL IND 02
35 STO 02 80 RCL 01
36 6 81 /
37 STO 03 82 *
38 XEQ 03 83 ST+ IND 03
39 5 84 RDN
40 STO 02 85 ST+ IND 02
41 7 86 RTN
42 STO 03
43 XEQ 03
44 RTN

One question was: is DM42 the right tool?
Not for entire model. But checking bits and pieces, intermediate results, etc. – it’s the best easy-to-use, program-in-an-instant, usually sufficiently accurate tool I know of.

Re: precision in quick estimates.
The g++ compilers I use on Linux and Raspberry PI support double double type variable definitions, but the double double types currently are no more precision than double types, 64 bits. IEEE requires only that double doubles be no less precise than doubles. (I’ve written all of my vector and tensor C++ libraries to use double doubles in hopes that the compilers will soon support additional precision.) Meanwhile, it's GMPL libraries. Changes the coding paradigm from “just-enter-the-equation” to “enter-long-sequence-of-function-calls.” Fine. Doing that anyway for the main solar system model. For quick checks, sanity checks, intermediate results, logic verifications, etc. the DM42 is ideal. What they call "elegant." Quick, efficient RPN entry, excellent precision. Handy! (BTW, I'm also using HP41C MLTI library on a couple of HP41CL's--not nearly so handy--glad someone developed it, but a little too complicated for my purposes.)

Sort'a related: On wp34s, it’s really cool to switch between 64bits and 128. Leave program in memory, run at one precision, switch precision, re-run, compare. (Registers do get reorganized.)
User avatar
Walter
Posts: 3070
Joined: Tue May 02, 2017 11:13 am
Location: On a mission close to DRS, Germany

Re: DM42 resets during program run

Post by Walter »

Thanks for your kind words about the WP34S.

Regarding your post: It consists of two halves which seem to be identical. If true, please edit your post (yes, you can!) and delete what's just repeated. TIA
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
User avatar
ijabbott
Posts: 253
Joined: Fri Dec 15, 2017 2:34 pm
Location: GB-MAN

Re: DM42 resets during program run

Post by ijabbott »

There is no such type as double double in C/C++. I think you mean long double?

GCC supports 128-bit floating point on some architectures, including x86 and AArch64/ARM64 using the _Float128/__float128 type and libquadmath.

(Also, your program listings are a mess. One instruction per line please!)
Post Reply