# How to make NMinimize stop running when EvaluationMonitor gets stuck

I have a some optimisation problem (though gmmobjg is a bit complicated to reproduce it here, I've posted of git).

The code for optimization is:

NMinimize[gmmobjg[test], list, Method -> "NelderMead", AccuracyGoal -> 6, PrecisionGoal -> 6,
EvaluationMonitor :> {Print[gmmobjg[test]]}]


I need to observe progress, so use EvaluationMonitor. I get some fine results printed, but at some point 'EvaluationMonitor' gets stuck forever while the code keeps running. Moreover, launched with last achived parameters values, it allows to minimize further (with the same algo).

I could Abort Evaluation but what are gentle ways to make it to stop running if we do not know ex ante how long the whole optimization and each evaluation cycle could take?

Edit

TimeUsed[] seems to be a proper way.

• – corey979 May 26 '18 at 15:41
• Is this helpful? Sorry, but I won't be inventing an MWE to play with. – corey979 May 26 '18 at 16:11
• There's a cycle of evaluation: obj[test], then EvaluationMonitor, if a step then StepMonitor, then repeat. It cannot get stuck at EvaluationMonitor while the code keeps running. I think you reach a value of test for obj[test] is taking an extremely long time. – Michael E2 May 26 '18 at 22:40
• @MichaelE2, may be ‘stuck’ is not a good term here, but why may this happen? If I relaunch the cycle with last found value of test, it proceeds to diminish obj value until next ‘very long’ lock in. I do not know what happens behind the scene. That is why I decided to check it with ‘TimeUsed’ and relaunch manually. – garej May 27 '18 at 7:10
• I don't know how to tell without the code for obj. Since Nelder-Mead keeps n+1 points, you need to restart with those values or it is not following the same next step, which might explain why it runs for a while. It could be a bug in NMinimize, but that seems much less likely. – Michael E2 May 27 '18 at 12:24