@Carl Love I tried fliping sign of the three vector (momentum) compenent and that works. Some how my 'boostTo' is getting the sign of momentum wrong...

This should not be to hard to figure out, unlike the mem leak problem...

@Traruh Synred @Carl Love I think that one workded. 'insert contents'..I was still short one button push...

@Carl Love I hit the green up arrow and try to follow what it says, but I must be missing something...

Download boostTo.mw

@Carl Love I may have forgotten to push the final button. Trying again.

BTW, I've not figure out how to stop mem leaking, but kind can work around it. It is in any case tno it's not big enough to cause crash (monitoring it with 'Task Manger').. Something else must be going on.

@Traruh Synred  @Carl Love @Joe Riel

I had some more crashes with memory tracking on. Could it be other programs grapping memoery? Starting with same seed crash occurs at different events...

I shut down everything I could and go through 200+ events w/o a crash. Ran faster too. 

I'm watching mememor in task manger, but it never got to be more than 1/2. I shut off some task and kept it  below 1/2 despite steady growth.

Could it be that crashs when some other task demans a lot of memory? I started setting seed to be the same and crashes still occur at different points...

I think that by dealing in a little memory mangement of my own, I may be able to get somethings done, but clearly not a viable long term solution.

I saw a complaint about memory leaks in Maple 2018 (my version), but it is expensive to upgrade.

@Carl Love @Joe Riel

I've gone back to running my basic double B decay loop rather just 'ProbDStarLNu'. 

With memory checks use your 'MemUse()' it does not crash with 1st 100 events as it did before. I disabled 'MemUse()' (made it to just turn 1) it crashes in the generation of the second decay on event 73. If I turn 'MemUse()' back on and using the same random number seed it no longer crashes, but gets through all 100 events.

I do find all 'proc's seem to leak pretty much regardless of how simple they are, but it's not enough to explain crashes. I ran standalone 'ProbDStarLNu' to much higher memory usage w/o any problems, so accumulation from typical growth does not explain the crashes.

Reminds me of when 'memory management' was introduced into the interactive control program for an experiment I was working on at Fermilab. It was spending more time managing the memory than it was reading and writing out the data I told my bosses "Don't manage memory, buy it!" </;-_). 

I guess I'll try a longer run with memory tracking on...

@Traruh Synred  @Carl Love @Joe Riel

èI’ve run >9K ‘ProbDStarLu’ iterations w/o a crash. I think this many more than before the crash occurs running full decay generator ‘bDecay’. That is less than 100 calls to ‘bDecay’ each of which maybe calls “ProbDStarLNu’ ~10 times on average. There must be something else going on.

èThis steady leak rate from such a simple ‘subroutine’ baffles!

@Joe Riel @Carl Love

Even if I strip everything out of my loop counting and calls to 'MemUse()' it still leaks. Not as bad.

Maybe it's because I still use Maple 18 which my former employer provided me. I see some chatter about leaks and possible coming fixes. The first part of the nest empty loop is below. Every 10th entry is much lower all the way out to 100 and when I was printing every 10th the overall leak rate was lower. It seems even 'print' is leaking. Debugging a leak is pretty hopeless.

@Carl Love @Joe Riel

Maple proc ProbDStarLNu men usage

Compare

forget(sin, forgetpermanent = true)

forget(cos, forgetpermanent = true)

in various locations

With forget on for sin and cos in loop just before call to ‘ProbDStarLNu’

"count=", 100, " memProb=", 61748, " memSum=", 5.435964*10^6

W/o forgot.

"count=", 100, " memProb=", 23508, " memSum=", 2.105284*10^6

èIt does better w/o forgot sin, cos.

With forgot in ProbDStarLNu

"count=", 100, " memProb=", 61324, " memSum=", 5.877444*10^6

èAlso worse with forget on inside. About the same

Forget outside loop

"count=",same.., " memProb=", 23304, " memSum=", 2.120680*10^6

 ==>Better. Almost as good when not forgetting at all..

è100 interactions do not cause a crash but that is many fewer than would occur when ‘ProbDStarLNu’ is inside the reject/accept alg in the generator.

-->In all cases mem usage goes down in the 1st few iterations! Weird!

@Joe Riel @Carl Love

Carl's is much simpler. In principle I sum over all the 'kernalopts[memusage]' values but I do it in loop explicitly doing the sum myself. Carls 'MemUse()' and my 'memUsed()' don't give the same results, but perhaps it is accounted for by mine creating more variables. 

I planned some control that would allow me to select what to sum, but didn't get around to it. It's very confusing that Maple routines to count memory use contribute to memory use themselves.

As it stands both Carl's and mine differ from each other as well as from 'MemoryInUse()'.

@Carl Love I have run the full generation many times is a row and it never gets to a 100 w/o crashing.

I've run the proc I thought I isolated as the cause10 20 times in a row, using brackiting it with MemoryInUse() and internally (separating the trig calls from the algebra (which seems to call linear Algebra routines though it just arithmetic (Profile)). Most of the memory growth seems to come from the algebra which seems odd. It's just some hp probabilities. It's also very small.

Here is the output (after about 20 steps, executed by hand):

memBefProb := 15079252 <==MemoryInUse call just before proc 'ProbDStarLNu' is executed.

"memStart:", 15085224 <==1st line in proc (the growth happens here, but does not go away).
"memFin:", 15083340 <==last line i proc
 "ProbDStarLNu: memTrig-memStart=", -2200 <==after the trig calls (yes it goes down
"ProbDStarLNu: memSum1-memTrig=", -124 <==memSum1 is the next line after mTrig (nothing done).
 "ProbDStarLNu: memFin-memTrig=", 316 <== contribution of Algeba
"ProbDStarLNu: memFin-memStart=", -1884 <==Net memory growth during call (it's negative)
               "ProbDStarLNu: memFin=", 15083340
                 Prob := 0.37096322013533596659

I change the angles in the arguments before each call to ProbDStarLNu. If I don't pattern is somewhat different. 

memProb:= 6368 <-- net memory  growth by this call. it's positive!

I will try to do 100 interactions maybe even make plots, but I think I need to get your version of MemoryInUse working first. The standard one is too slow and I don't entirely trust it. 

If I don't resolve the leak pretty soon I'll have to change to something else to continue --Python, C++, or CERN's ROOT package (that has all the plotting tools I need).

@Carl Love Calling mine twice in a row in a proc 'ProbDStarLNu] esults in a fixed increase on the second call. I do declare the variable corresponding to the kernalopts list  'local' but not in line like your version. I'll give yours a try.

Thanks

I add the 63-word array that 'kerneloptos(memoryuse)' creates. 'MemoryInUse' doesn't do that. 

Why doesn't the array get deleted when it goes 'out of scope'? What's the point of keeping it? It adds to the leaking...

@Joe Riel I should have just given it the proc not called the proc! Thanks, again.

@Joe Riel Thanks. Somehow in the example the '-' appears as if an underscore had been applied.