Setting OptimalityTol does not affect precision of solution
OngoingHello,
while solving my model, I came across a strange behavior of the gurobi. I am testing this problem on an instance that is solvable analytically. The optimal solution is exactly 8. Gurobi found a solution with a cost of 7.99999806, which is within the default accuracy of 1e-6. However, when I set FeasibilityTol and OptimalityTol to 1e-9 the solution is still the same. What could be the problem? Did I understand the meaning of FeasibilityTol and OptimalityTol correctly? Is there anything else I need to set?
I am using unofficial rust API (https://crates.io/crates/gurobi) but the API seems to work correctly as the console output prints the specified tolerances.
Set parameter Username
Academic license - for non-commercial use only - expires 2025-03-08
Set parameter FeasibilityTol to value 1e-09
Set parameter OptimalityTol to value 1e-09
Gurobi Optimizer version 11.0.3 build v11.0.3rc0 (linux64 - "Arch Linux")
CPU model: AMD Ryzen 7 5700X 8-Core Processor, instruction set [SSE2|AVX|AVX2]
Thread count: 8 physical cores, 16 logical processors, using up to 16 threads
Optimize a model with 16 rows, 28 columns and 40 nonzeros
Model fingerprint: 0x51fc3bec
Model has 8 quadratic constraints
Coefficient statistics:
Matrix range [1e+00, 1e+00]
QMatrix range [1e+00, 1e+00]
Objective range [1e+00, 1e+00]
Bounds range [0e+00, 0e+00]
RHS range [3e+00, 3e+00]
QRHS range [5e-01, 5e-01]
Presolve removed 8 rows and 8 columns
Presolve time: 0.00s
Presolved: 12 rows, 24 columns, 28 nonzeros
Presolved model has 8 second-order cone constraints
Ordering time: 0.00s
Barrier statistics:
AA' NZ : 3.600e+01
Factor NZ : 7.800e+01
Factor Ops : 6.500e+02 (less than 1 second per iteration)
Threads : 1
Objective Residual
Iter Primal Dual Primal Dual Compl Time
0 1.10717674e+01 0.00000000e+00 2.24e+00 1.27e-01 5.02e-01 0s
1 3.29839276e+00 9.14863342e-01 1.19e+00 1.40e-07 1.19e-01 0s
2 8.95566627e+00 7.42050647e+00 1.06e-01 1.54e-13 8.42e-02 0s
3 7.99751005e+00 7.99917368e+00 8.75e-04 4.00e-15 1.33e-04 0s
4 7.99999806e+00 7.99999909e+00 8.36e-07 1.11e-14 1.65e-07 0s
Barrier solved model in 4 iterations and 0.00 seconds (0.00 work units)
Optimal objective 7.99999806e+00
status: Optimal
-
You can also set the BarConvTol (or BarQCPConvTol) to a small value, even 0.
Cheers,
David1 -
Thanks, that worked. But why setting the OptimalityTol does not work?
0
Please sign in to leave a comment.
Comments
2 comments