Giters

GPflow / GPflowOpt

Bayesian Optimization using GPflow

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unnecessary calls to _optimize_models

icouckuy opened this issue · comments

commented

It seems that with scaling=True the BayesianOptimizer will optimize the initial model twice.

In the CTor of BayesianOptimizer a call to acquisition.enable_scaling will optimize the model(s), while BayesianOptimizer._optimize() optimizes the model(s) again.

If I read this correctly I think we should try to minimize the number of unnecessary model optimizations. To avoid future control flow problems like this we might want to reduce the places where models are optimized, if possible.

commented

As design principle, I followed that at any point the acquisition should hold optimized models. As a consequence the optimize rules are extremely simple:

  • in the constructor
  • when scaling is enabled
  • when set_data is called

Thats it. Some potential things we can do:

  • Do not call set_data when no points are added in _update_model_data. This solves the issue you report, unless an initial design is specified.
  • Add enabling of the scaling to set_data and pass the domain as optional argument there. If the scaling isn't enabled this can be enabled there. This feels a bit hacky.
  • Abandon the principle of having models optimized all the time and delay _optimize_models to setup() (would have to check if this is possible given the setup/optimize relations). This might mostly concern users that do not use the BayesianOptimizer.

In general: how bad is this problem? If called twice, the second optimization starts in the optimum so ends very quickly. I agree it is more expensive when MCMC is used.

commented

There is however another problem I was unaware of until yesterday. setup()'s are also run multiple times which is a big problem if a setup function is expensive (i.e., in case of PES it would). This is much more severe than the duplicate optimizes.

After a conversation with @icouckuy , it seems that we should make the optimization/setup cycle lazy instead of automated on any change over the underlying data. I started the work and I'll probably try to test it on the flight home.