search

jbrea / BayesianOptimization.jl

Bayesian optimization for Julia
Other
91 stars 17 forks source link

InterruptException from `optimizemodel!` #23

Closed fredcallaway closed 3 years ago

fredcallaway commented 3 years ago

I have occasionally been getting this error:

InterruptException:                                                                                                                  
optimizemodel! at /usr/people/flc2/.julia/packages/BayesianOptimization/poykT/src/models/gp.jl:72                                    
optimizemodel! at /usr/people/flc2/.julia/packages/BayesianOptimization/poykT/src/models/gp.jl:42 [inlined]                          
macro expansion at /usr/people/flc2/.julia/packages/TimerOutputs/ZmKD7/src/TimerOutput.jl:190 [inlined]                              
boptimize! at /usr/people/flc2/.julia/packages/BayesianOptimization/poykT/src/BayesianOptimization.jl:150

~My guess is that this is an NLopt thing.~ (see edit) Unfortunately, I'm not able to reproduce this reliably—even given the same function it will sometimes happen and sometimes not depending on the random seed.

It might be relevant that I don't put bounds on the kernel parameters. But my thinking is that an easy (and reasonable) thing to do is to wrap the call to NLOpt in a try-catch block and print a warning if there's an exception. Given that optimizing the model parameters is not essential to the completion of the algorithm, I think this would be preferable to letting the error terminate the optimization process, which could have been going for hours.

EDIT: Looking at the code, I see that you intentionally throw an InterruptException, so I guess you disagree that letting the optimization continue is the best course of action. Could we add a flag that determines what to do in this case? Or am I incorrect that you could reasonably continue after hitting that error?

jbrea commented 3 years ago

You're totally right: interruption doesn't make much sense in this case. I replaced it by a warning for now and tagged a new minor release. Adding a flag for more user-control sounds like a good alternative. I'll have a look at this when I find the time to give this package a bit of love :) Feel free to open a pull request, if you have something specific in mind.