Mathematica kernel crashing after repeated use of NMinimize

Questions
, ,
1

I have quite an complicated function involving NIntegrate and special functions (see the attached file if interested in details) and I would like to minimize it with respect to 6 parameters. When I call NMinimize once, I get a result in about 3 minutes. However, I need to minimize the function for a set of parameters and whenever I try to call similar NMinimize procedure repeatedly, Mathematica kernel crashes without any specific warning message (I get sometimes warning messages regarding convergence of NIntegrate during the calculation, however, these are not correlated with the crashes).

I was trying first varying the parameters with Do cycles. I was told that there might be some memory issues, so I tried to add ClearSystemCache[] to each repetition, however, this did not help. I was also told that Mathematica is better suited for working with lists than with cycles, so I tried to put the different parameter choices into a Table, however, Mathematica crashed again.

I am using Mathematica 11.3 on my laptop and I also tried to run the code on a server with Mathematica 10.3 installed, there was no significant difference.

Doesn’t anyone have an idea how to avoid these problems so that I could let Mathematica run the code repeatedly for a longer time?

NMinimize_problems_sample_notebook.nb (19.3 KB)

2

Before actually working on your issue, I quickly run several sets of values to determine IntJ and IntI, they are very close to zero for most of time. And the min value your are looking at is way larger (like close to -1.6).

Manipulate[
 Plot[Cos[th0 + k*Sin[9*x + th1]]^2*Cos[8*x], {x, 0, 2 \[Pi]}, 
  PlotRange -> {-1, 1},
  PlotLabel -> 
   NIntegrate[Cos[th0 + k*Sin[2*x + th1]]^2*Cos[3*x], {x, 0, 2 \[Pi]},
     AccuracyGoal -> 5]],
 {k, -3, 3}, {th0, -\[Pi], \[Pi]}, {th1, -\[Pi], \[Pi]}]

4903res.PNG
4903res.PNG854Ă—598 48 KB

I do not see anywhere they are solely on the position of denominator. So you may want to try optimize HeffSinAns without these NIntegrate first.

3

Thank you for the response!

Actually, I am already aware of the fact that there is some room for omptimization because of the zero value of intI[m, n, th0, th1, K2,1] for certain values of m and n (see the attached file where I was checking exactly this and I even implemented this optimization when elaborating more on my problem). On the other hand, the value is not close to zero for all m and n, moreover, intI[m, n, th0, th1, K2,2] and intJ functions are usually not close to zero, so the simplification is not so dramatic.

Thank you in advance if you would be able to check further why Mathematica is crashing.

NMinimize_problems_sample_notebook.nb (98.6 KB)

4

Try eliminate th1 as a variable, it would not change the value of integration. Let’s first reduce the time for each optimization.

oscillationDetection.nb (3.37 MB)

5

Thank you, but in the notebook which I attached there is shown that for certain values of parameters, the integration in IntI depends on th1: Check, e.g.,

Plot[intI[1, 1, Pi/3, th1, 2, 1], {th1, 0, 2 Pi}]

or

Plot[intI[3, 2, Pi/3, th1, 2, 2], {th1, 0, 2 Pi}].
6

Maybe I should add that I believe that it’s indeed a memory issue. I tried to add

Print[MemoryInUse[]];

ClearSystemCache[];

Print[MemoryInUse[]];

in each cycle where NMinimize was performed for different values of the parameters and I am getting

running_nontebook.jpg
running_nontebook.jpg1198Ă—856 172 KB

i.e., one can see that the memory in use is growing with each repetition and ClearSystemCache[] does not release too much.

7

Maybe in your case the NIntegrate or NMinimize aborted internally due to the poor convergence with the default method.Good news is that I notice your functions are rather smooth and the target function is semi-quadratic. So you can use some built-in method to boost up computation speed

intI[m_ ...] := 1/(2 Pi)*Chop@NIntegrate[... , AccuracyGoal -> 5, Method -> "TrapezoidalRule"];
intJ[m_ ...]:= 1/(2 Pi)*Chop@NIntegrate[... , AccuracyGoal -> 5, Method -> "TrapezoidalRule"];

Use NMinimize or FindMinimum with specified methods:

Minima = ParallelTable[
  NMinimize[{HeffSinAns[1.2, 1.2, L, ValuesMN[[j, 1]], 
     ValuesMN[[j, 2]], ph0, th0, th1, K1, K2], -\[Pi] <= 
     th0 < \[Pi], -\[Pi] <= ph0 < \[Pi], -\[Pi] <= th1 < \[Pi]}, {L, 
    ph0, th0, th1, K1, K2}, 
   Method -> {"SimulatedAnnealing", 
     "PerturbationScale" -> 3}, MaxIterations -> 10], {j, 1, Length[ValuesMN]}]

I found this give you good approximations within 130 seconds for all cases on a 6-core i7 laptop

annealing.png
annealing.png913Ă—401 96.9 KB

8

Thank you very much! This indeed led to huge increase of speed and stability of the calculation!

9

I’m unsure mm “should crash” due to running out of memory though I know on earlier versions it did (the bug may not be in mm). It will crash if you have “code violations” in your code.

You can limit the memory use, and also (as you said), flush. But Cache I’m unsure. You want to flush Mathematica’s memory of past inputs (which can grow large quickly).

Did you say what OS you are using? That front end doesn’t look like Win10 or Mojave. Is it Linux? If so then, well.

A possible cause not mentioned above: Put. It puts expressions. Check your expressions and insure you are not feeding trash to Put because that would cause the kernel to quit instead of putting anything on disk (put evaluates everything before putting, and what is put must be … putable).

10

(note that kernel Quit[] is not the same as kernel crashing, quitting is a planned end when a program error is encountered)

I’m unsure mm “should crash” due to running out of memory though I know on earlier versions it did (the bug may not be in mm). It will crash if you have “code violations” in your code.

You can limit the memory use, and also (as you said), flush. But Cache i’m unsure. You want to flush mm’s memory of past inputs (which can grow large quickly)

Did you say what OSes you are using? That front end doesn’t look like Win10 or Mojave. Is it linux? If so then, well.

A well possible cause not mentioned above: Put[]. It puts Expressions. Check your Expr and insure you are not feeding (trash) to Put because that would cause the kernel to quit instead of putting anything on disk. perhaps put one expr at a time so you can locate what Put it Quits on or to see if infact Put is where it Quits.

11

Thank you, John, for your answer! I am not sure if it were indeed memory issues which were causing the kernel to crash, however, the calculation got a bit quicker after I’ve put $HistoryLength=0 and also the memory “consumption” decreased.

On the other hand, what really helped with the stability of the kernel, were the different options for NIntegrate and NMinimize suggested by Shenghui. In the same time, the memory “consumption” in each repetition decreased considerably.

To be honest, the results now have to be taken with a grain of salt, NMinimize sometimes does not end up in the global minimum and also NIntegrate does not give accurate results (sometimes the error is quite considerable, e.g., -0.6 instead of -1.3), however, from the physics intuition for the problem, it’s not hard to discover such suspicious results and make more precise calculations for some particular parameter choices.

Regarding the OS, I am running the code either on my laptop with Windows 10 or on a Unix server. But the “crashing properties” were quite similar.

And I was not using any Put in my code before it got stable, but thank you for the suggestion of where some problems could occur!

12

it’s not hard to discover such suspicious results

you are using inexact numbers and have to account for precision loss on every calculation - this is always true for inexact numbers in any application

on my laptop with Windows 10 or on a Unix server

(that’s not allowed unless you have 4 licenses, but whatever)

Put in my code before it got stable

i was not referring to Put[] with code that had been altered to not Quit[] or crash, as you know

thank you

13

For the “grain of salt” part: