Nonzero gap at optimality?

I'm running Gurobi 9.5 through the python API to solve a small MIP and am noticing this strange behavior: my model is being solved to optimality but the results from model.objVal and model.ObjBound differ greater than my tolerance. I conjecture this is because a heuristic solution is being found, but would like some confirmation.

I can provide the exact model to replicate, but here's a snippet of code and the traceback I'm seeing:

model = call_model_optimize()
print('-' * 64)
print('Status: %s | ObjBound: %.03f | objVal %.03f' % (model.Status, model.ObjBound, model.objVal))

Which yields this traceback:

Gurobi Optimizer version 9.5.0 build v9.5.0rc5 (linux64)

Thread count: 4 physical cores, 8 logical processors, using up to 8 threads

Optimize a model with 5 rows, 983 columns and 1967 nonzeros


Model fingerprint: 0xed05bdde

Variable types: 982 continuous, 1 integer (1 binary)

Coefficient statistics:

  Matrix range     [4e-10, 5e+00]

  Objective range  [8e-03, 4e-02]

  Bounds range     [6e-01, 6e+00]

  RHS range        [1e-06, 3e+00]

Presolve removed 1 rows and 961 columns

Presolve time: 0.00s

Presolved: 4 rows, 22 columns, 27 nonzeros

Variable types: 21 continuous, 1 integer (1 binary)

Found heuristic solution: objective -0.2150999



Explored 0 nodes (0 simplex iterations) in 0.01 seconds (0.00 work units)

Thread count was 8 (of 8 available processors)



Solution count 1: -0.2151 



Optimal solution found (tolerance 1.00e-04)

Best objective -2.626314110670e-02, best bound -2.150998966824e-01, gap 719.0182%

----------------------------------------------------------------

Status: 2 | ObjBound: -0.215 | objVal -0.026

I should also note that I can compute this particular MIP in a closed-form way and can verify that the correct answer really should be the one returned by objVal.

Any insight here would be greatly appreciated!

Matt Jordan

February 16, 2022 17:06

Gurobi Support escalated this to a support ticket and we resolved these issues. To summarize:

>This unexpected behavior is caused by numerical issues during the solution process and turning off presolve (Presolve=0) or turning up Gurobi's numerical awareness (NumericFocus=2 or 3) solves the issue.

The root cause of my numerical issues came from many small coefficients that caused unexpected behavior. Increasing numerical focus works, but is ill-advised. It was recommended that I rescale my model, or follow other strategies listed here: https://www.gurobi.com/documentation/9.5/refman/guidelines_for_numerical_i.html

Nonzero gap at optimality?

Comments

Didn't find what you were looking for?