Optimization termination criterion prematurely triggered with COBYLA algorithms
Summary
The introduction of the optimization termination criterion at GEMSEO level (i.e., the wrapped optimization algo is not anymore responsible of ending the optimization loop) leads in some specific cases to the premature ending of the optimization loop.
Gemseo version
GEMSEO 3.2.2
Platform info
Not dependent of the platform type.
Environment info
Not dependent of the environment.
Steps to reproduce
The following snippet enables to reproduce the issue:
from gemseo.problems.analytical.rosenbrock import Rosenbrock
from gemseo.api import execute_algo, configure_logger
from numpy import array
configure_logger()
rosen_problem = Rosenbrock(n_x=5, initial_guess=array([0., 0., 0., 0., 0.]))
rosen_problem.preprocess_functions()
res=execute_algo(rosen_problem, algo_name='NLOPT_COBYLA', max_iter=100)
What is the current bug behavior?
With the previous snippet, the optimization loop ends after the 6th call to the objective function, and without having converged.
What is the expected correct behavior?
NLOPT_COBYLA enables to converge to the absolute optimum in this case, as long as it is not stopped prematurely during its DoE phase.
Relevant logs and/or screenshots
INFO - 10:25:43: Optimization problem:
INFO - 10:25:43: Minimize: rosen(x) = sum(100*(x[1:] - x[:-1]**2)**2 + (1 - x[:-1])**2
INFO - 10:25:43: With respect to: x
INFO - 10:25:43: Design space:
INFO - 10:25:43: +------+-------------+-------+-------------+-------+
INFO - 10:25:43: | name | lower_bound | value | upper_bound | type |
INFO - 10:25:43: +------+-------------+-------+-------------+-------+
INFO - 10:25:43: | x | -2 | 0 | 2 | float |
INFO - 10:25:43: | x | -2 | 0 | 2 | float |
INFO - 10:25:43: | x | -2 | 0 | 2 | float |
INFO - 10:25:43: | x | -2 | 0 | 2 | float |
INFO - 10:25:43: | x | -2 | 0 | 2 | float |
INFO - 10:25:43: +------+-------------+-------+-------------+-------+
INFO - 10:25:43: Optimization: 0%| | 0/100 [00:00<?, ?it]
INFO - 10:25:43: Optimization: 5%|▌ | 5/100 [00:00<00:00, 32716.88 it/sec, obj=203]
INFO - 10:25:43: Optimization result:
INFO - 10:25:43: Objective value = 4.0
INFO - 10:25:43: The result is feasible.
INFO - 10:25:43: Status: None
INFO - 10:25:43: Optimizer message: Successive iterates of the objective function are closer than ftol_rel or ftol_abs. GEMSEO Stopped the driver
INFO - 10:25:43: Number of calls to the objective function by the optimizer: 6
INFO - 10:25:43: Design space:
INFO - 10:25:43: +------+-------------+-------+-------------+-------+
INFO - 10:25:43: | name | lower_bound | value | upper_bound | type |
INFO - 10:25:43: +------+-------------+-------+-------------+-------+
INFO - 10:25:43: | x | -2 | 0 | 2 | float |
INFO - 10:25:43: | x | -2 | 0 | 2 | float |
INFO - 10:25:43: | x | -2 | 0 | 2 | float |
INFO - 10:25:43: | x | -2 | 0 | 2 | float |
INFO - 10:25:43: | x | -2 | 0 | 2 | float |
INFO - 10:25:43: +------+-------------+-------+-------------+-------+
Possible fixes
A possible mitigation, which enables to avoid a patch, would be to slightly perturb the initial point.
In order to correct this behavior, the stop_crit_n_x
option should be accessible to the user, as it indeed not yet set in the NLOPT and PDFO algo grammars. Also, as safe default value for these algorithms could be to define this previous option as the size of the design space.