PSORLab / EAGO.jl

A development environment for robust and global optimization
MIT License
140 stars 16 forks source link

How to display the optimality bounds [LBD, UBD] #57

Closed ShuhuaGao closed 3 years ago

ShuhuaGao commented 3 years ago

Hi, I am using EAGO to solve a nonlinear least squares problem. There are some issues that need your help.

After calling optimize!(model), the output information is

-----------------------------------------------------------------------------------------------------------------------------
|  Iteration #  |     Nodes    | Lower Bound  |  Upper Bound  |      Gap     |     Ratio    |     Time     |    Time Left   |
-----------------------------------------------------------------------------------------------------------------------------

First Solution Found at Node 1
UBD = 3.527847092443349e-5
Solution is :
    X[1] = 0.7607755418437602
    X[2] = 0.3230414037667083
    X[3] = 1.481190017639433
    X[4] = 0.03637683583967992
    X[5] = 0.53719735371654

However, I don't know the LBD and cannot tell the quality of the final solution from the above info. By contrast, another optimizer Couenne tells us both bounds and the gap. In addition, when checking the final status, I have the following result:

termination_status(model) = MathOptInterface.OPTIMAL
objective_value(model) = 3.527847092443349e-5

It seems that the minimum objective value reported by JuMP is just the above UBD. Nonetheless, by substituting the optimal solution (i.e., the five parameters) into the original objective function, I get a different result 2.527822e-05 that is smaller than the UBD. If fact, the value 2.527822e-05 is exactly what Couenne obtains with zero optimality gap between lower and upper bounds. Thus, even though EAGO managed to find the global optimal solution, the objective value reported was wrong.

Are there any options that control the display? Besides, I can post my code and data if needed. Thank you.

mewilhel commented 3 years ago

Thanks for reporting this issue! Also, thanks for the detailed description, I've got a pretty good idea of the underlying issue and the resolution should be quite easy.

A little background: We initially had a few issues due to rounding error resulting from the larger number of intermediate calculations used when computing relaxations than auxiliary variable approaches. This usually wasn't an issue but a number of users wanted to set fairly extreme tolerances. So we added a small tolerance to the upper bound (scaled an order of magnitude below the specified relative and absolute optimality tolerances to avoid spurious results). We never adjusted the algorithm to store the true value rather than this adjusted value. So EAGO should currently furnish the correct optimal point (but not the value corresponding to it). I'll push out a patch to EAGO to fix this in the next day or so.   

The console printing controls currently should allow you to inspect the solution quality (set by keyword arguments):

I'll also give some thought on how to report the lower bound in the final console output. That said, if the final solution is OPTIMAL it will satisfy a either a relative or absolute tolerance that are set by the following keyword arguments: