Setting OptimalityTol does not affect precision of solution

進行中

Ondřej Toman

• 2024年08月15日 10:51

Hello,
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

0

• 

  David Torres Sanchez

  Gurobi Staff

  • 2024年08月15日 11:08

  You can also set the BarConvTol (or BarQCPConvTol) to a small value, even 0.

  Cheers, 
  David

  1
• 

  Ondřej Toman

  • 2024年08月15日 11:19

  

  

  Thanks, that worked. But why setting the OptimalityTol does not work?

  0

サインインしてコメントを残してください。