## 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
rprosperi
Posts: 1118
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

### Re: DM42 resets during program run

prd6920766@gmail.com wrote:
Mon Apr 26, 2021 7:39 pm

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.

I can't fathom any real-world reason to run ANY calculation that long (you quoted 80 hours), but different strokes for different folks. IMHO, if world peace were at stake, it should be discussed, but even then, not a certain yes.

Since Free42 runs hundreds (maybe thousands at this point) of times faster on probably every other platform it runs on, and several of those are equally portable, I'd say use one of those.

That said, if a bug can be isolated and easily reproduced, it's reasonable to expect SM to fix it, but if takes 80 hours of run-time to have it occur, I would consider it 'not a bug'.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
whuyse
Posts: 143
Joined: Thu Dec 21, 2017 1:23 pm

### Re: DM42 resets during program run

Code: Select all

00 { 174-Byte Prgm }
01▸LBL "SOrbit"
02 363228900
03 STO 04
04 1082
05 STO 07
06 0
07 STO 05
08 STO 06
09 STO 10
10 "Delta T"
11 PROMPT
12 STO 08
13 "T Max"
14 PROMPT
15 STO 09
@
@  main loop
16▸LBL 01
17 RCL 08
18 STO+ 10
19 RCL 09
20 RCL 10
21 X>Y?
22 GTO 06
23 XEQ 02
24 RCL 10
25 RCL 08
26 ÷
27 RCL 00
28 MOD
29 X=0?
30 XEQ 05
31 GTO 01
@
@
32▸LBL 02
33 XEQ 04
34 4
35 STO 02
36 6
37 STO 03
38 XEQ 03
39 5
40 STO 02
41 7
42 STO 03
43 XEQ 03
44 RTN
@
@  init R01 and R011
45▸LBL 04
46 RCL 04
47 X^2
48 RCL 05
49 X^2
50 +
51 ENTER
52 SQRT
53 STO 01
54 R↓
55 3.986004418ᴇ14
56 X<>Y
57 ÷
58 +/-
59 STO 11
60 RTN
@
@  base calculation
61▸LBL 03
62 RCL 11
63 2
64 ÷
65 RCL 08
66 X^2
67 ×
68 RCL IND 02
69 RCL 01
70 ÷
71 ×
72 RCL IND 03
73 RCL 08
74 ×
75 +
76 RCL 11
77 RCL 08
78 ×
79 RCL IND 02
80 RCL 01
81 ÷
82 ×
83 STO+ IND 03
84 R↓
85 STO+ IND 02
86 RTN
@
@  output
87▸LBL 05
88 RCL 10
89 "T="
90 ARCL ST X
91 AVIEW
92 RTN
@
@  previous output
93▸LBL 06
94 RCL 08
95 STO- 10
96 XEQ 05
97 END
Without understanding for now how it works, I applied some optimisation, most noticably in LBL 03, the innermost:

Code: Select all

00 { 158-Byte Prgm }
01▸LBL "SOrbit"
02 363228900
03 STO 04
04 1082
05 STO 07
06 0
07 STO 05
08 STO 06
09 STO 10
10 "Delta T"
11 PROMPT
12 STO 08
13 "T Max"
14 PROMPT
15 STO 09
@
@  main loop
16▸LBL 01
17 RCL 08
18 STO+ 10
19 RCL 09
20 RCL 10
21 X>Y?
22 GTO 06
23 XEQ 02
24 RCL 10
25 RCL 08
26 ÷
27 RCL 00
28 MOD
29 X=0?
30 XEQ 05
31 GTO 01
@
@
32▸LBL 02
33 XEQ 04
34 4
35 STO 02
36 6
37 STO 03
38 XEQ 03
39 5
40 STO 02
41 7
42 STO 03
43 XEQ 03
44 RTN
@
@  init R01 and R011
45▸LBL 04
46 RCL 04
47 X^2
48 RCL 05
49 X^2
50 +
51 SQRT
52 STO 01
53 -3.986004418ᴇ14
54 LASTX
55 ÷
56 STO 11
57 RTN
@
@  base calculation
58▸LBL 03
59 RCL IND 03
60 RCL 11
61 RCL 08
62 ×
63 RCL IND 02
64 RCL 01
65 ÷
66 ×
67 STO+ IND 03
68 2
69 ÷
70 +
71 RCL 08
72 ×
73 STO+ IND 02
74 RTN
@
@  previous output
75▸LBL 06
76 RCL 08
77 STO- 10
@
@  output
78▸LBL 05
79 RCL 10
80 "T="
81 ARCL ST X
82 AVIEW
83 END
with 1E7 iterations in Free42 on my iPhone I get R04 - 363228900 = 1369.2559, in about 200 seconds.

I see nothing out of the ordinary here though.. must be some sort of memory bleed.
Cheers, Werner
42S #3249S01123
DM42 #00345
DM41X #01215
whuyse
Posts: 143
Joined: Thu Dec 21, 2017 1:23 pm

### Re: DM42 resets during program run

BTW, solving the orbital equations using my Cash-Karp Runge-Kutta ODE program (not yet published.. will come), it seems the orbital period should be 73 seconds shorter. I needed only 1000 sample points to get 10 accurate digits, 29 seconds on my USB-DM42.

in:
t: 0
w: [ (363228900,0) (0,1082) ]
STEP: 2416.89
N: 1000

result
w(t): [ (363228891.887, 79293.1656) (-0.221404, 1081.99997583) ]
err: [ (2.6e-9, 9.7e-7) (1.2e-11,3e-14)

so it seems we have gone 79km too far.
and 79293/1082 = 73.28.. seconds

running it with 10000 steps did not change the first 10 digits

Cheers, Werner
42S #3249S01123
DM42 #00345
DM41X #01215
prd6920766@gmail.com
Posts: 4
Joined: Fri Apr 16, 2021 6:07 am

### Re: DM42 resets during program run

Apologies for the listing mess. (Seemed from the editing frame the multi column approach was working.)
And for apparently trying to operate too far outside sensible use case envelope for the calculator.

I flashed DMCP v3.21 Version 3.18/3.0.2. Same result: calc reset, lost program, all data at about 110 hours.

Free42S running on IPad will do this easily. Just finished a run of 10 billion iterations, with resultant error of 1.918 meters. Same alg in C++ at 256bit precision gives error of 1.3758.

I am corrected on the long double. Long double is what I meant. (I'm using a vector lib where double double is macro'd to long double).

Yes for this program Runge–Kutta methods would have worked. Many thanks to Jean-Marc Baillard and to Angel Martin for massive, well-documented contributions (ie. Elliptic Functions ROM). Don't know how they do it.
But my progression through the solar system n-body problem is to progressively add bodies. The bookkeeping of orders, indicies, and registers would get out of hand with too many (very good) numerical solution methods. I'm reminded of Delaunay’s (1860-67)
expression for the moon’s longitude as a trigonometric series in the angles of 460 terms covering 53 pages. It took him 10 years to derive, 10 years to check, it contained 3 errors that were't discovered until the advent of early CAS in the 1970's.
Anyway, my approach is super simplistic, but scalable. Bodies and their parameters are kept in a vector; I can add and remove bodies at will Again, the program here is only meant to be an aid in verifying error bounds--I start it, scoot it to the corner of my desk, work on other parts of the problem, and check the calc when it's finished.

Recommendation to use Free42 on other platforms is taken. (Most other platforms take more desk space than a DM42.)

I don't know that I'll be posting again.
Consensus seems to be I'm too far out of bounds in too many ways to be useful.
I'll check to see if there are specific questions after a while.
As far as I'm concerned, this entire thread can be removed.
Meanwhile thanks greatly to all readers, responders, to the hard working community in general.
Thomas Okken
Posts: 922
Joined: Tue May 02, 2017 5:48 pm
Location: United States
Contact:

### Re: DM42 resets during program run

prd6920766@gmail.com wrote:
Mon May 03, 2021 7:57 pm
I don't know that I'll be posting again.
Consensus seems to be I'm too far out of bounds in too many ways to be useful.
I hope you keep posting! You're certainly pushing the Free42 / DM42 platform harder than most people, but I don't think there's anything wrong with that. If the DM42 crashes are due to a memory leak in the DM42 firmware then I hope that will get fixed eventually. There were stability issues with long-running programs in earlier DM42 firmware revisions and those were addressed as well.

(And of course if you get Free42 to crash, even if it's with huge amounts of data or very long run times, I would like to hear about that as well. As long as you stay below 2 gigabytes of RAM usage, the app should be stable, and if it's not, I'd consider that a bug and try to fix it.)
rprosperi
Posts: 1118
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

### Re: DM42 resets during program run

There is a confirmed memory leak in Free42 v3.0.2, which occurs if you are using some of the new commands introduced in the most recent versions (3.01/3.02), perhaps that is the cause? If using these, I would have guessed that the problem would occur well before 100+ hours of run-time, but I don't follow the logic, so maybe that code path is only used rarely.

A new version of DM42 will likely be released next week with fixes for those issues, so I recommend you wait for the new version and then try it again.

Also, I have not examined the logic involved, but can the task be somehow broken down into smaller 'chunks' so that you could run the initial phase for perhaps 48 hours, then the following phase, etc. and see if things remain stable? I've not heard of any other person/app attempting to run for 100+ consecutive hours, so possibly there is an issue under those circumstances that has never been seen before.

Some other things to consider:

Does the external USB power remain on 100% of the time? Is this powered by a PC which may be going to sleep (or being restarted?) and the power is shut off when that happens? If so, try using a dedicated wall power brick for the USB power.

After each crash, are you reloading a known-good state file? While not likely, it's possible the state file is being corrupted by the crash, and when trying again with the same state file, the problem may still be lurking

Good luck and let us know the results of trying the techniques in these suggestions.
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
whuyse
Posts: 143
Joined: Thu Dec 21, 2017 1:23 pm

### Re: DM42 resets during program run

prd6920766@gmail.com wrote:
Mon May 03, 2021 7:57 pm
Yes for this program Runge–Kutta methods would have worked. Many thanks to Jean-Marc Baillard and to Angel Martin for massive, well-documented contributions (ie. Elliptic Functions ROM). Don't know how they do it.
But my progression through the solar system n-body problem is to progressively add bodies.
My general embedded Runge-Kutta 4/5 core routine (that works with Fehlberg, Cash-Karp or Dormand-Prince, or any other 4/5 schema) needed no change at all to add the sun to the equation, for instance.
Just a new 'ODE definition program', with now a 4x1 complex vector with the position and velocities of earth and moon, respectively, as input. Could conceivably be made completely dynamic for n bodies.
I don't know that I'll be posting again.
Consensus seems to be I'm too far out of bounds in too many ways to be useful.
What consensus? All I saw for now was Robert Prosperi stating that, if it takes 80 hours for a single run to fail, don't count on it being fixed, which is entirely reasonable. Apart from that, we (well, I) welcome all things 'far out'. And it gave me yet another 'real world' example of differential equations to test my routines with -;)

Cheers, Werner
42S #3249S01123
DM42 #00345
DM41X #01215