Potential Numerical Bug in MIP Solving
OngoingFor this instance https://gist.github.com/zxt5/dc43466d22ebdb82056796a35323a23a
Gurobi generates the optimal solution with the objective of 3754..
by default,
but generates a solution with the objective of 3759..
with parameters:
Presolve=2 BarCorrectors=1 ScaleFlag=1 NodeMethod=2 GomoryPasses=1
Is this inconsistency expected for this case?
I am using 12.0.2 on Ubuntu. The log:
gurobi_cl Presolve=2 BarCorrectors=1 ScaleFlag=1 NodeMethod=2 GomoryPasses=1 seed.lp
Set parameter Username
Set parameter LicenseID to value 2648392
Set parameter ScaleFlag to value 1
Set parameter BarCorrectors to value 1
Set parameter NodeMethod to value 2
Set parameter GomoryPasses to value 1
Set parameter LogFile to value "gurobi.log"
Set parameter Presolve to value 2
Using license file /home/x27zhou/gurobi.lic
Academic license - for non-commercial use only - expires 2026-04-07
Gurobi Optimizer version 12.0.2 build v12.0.2rc0 (linux64 - "Ubuntu 20.04.5 LTS")
Copyright (c) 2025, Gurobi Optimization, LLC
Read LP format model from file seed.lp
Reading time = 0.00 seconds
OBJ: 127 rows, 20 columns, 2540 nonzeros
Using Gurobi shared library /home/x27zhou/solvers/gurobi/gurobi1202/linux64/lib/libgurobi.so.12.0.2
CPU model: AMD Ryzen 9 7950X 16-Core Processor, instruction set [SSE2|AVX|AVX2|AVX512]
Thread count: 16 physical cores, 32 logical processors, using up to 32 threads
Non-default parameters:
ScaleFlag 1
BarCorrectors 1
NodeMethod 2
GomoryPasses 1
Presolve 2
Optimize a model with 127 rows, 20 columns and 2540 nonzeros
Model fingerprint: 0xf7b7c71d
Variable types: 12 continuous, 8 integer (0 binary)
Coefficient statistics:
Matrix range [1e-02, 1e+02]
Objective range [5e+00, 1e+02]
Bounds range [2e+02, 2e+02]
RHS range [8e+01, 5e+03]
Presolve time: 0.00s
Presolved: 127 rows, 20 columns, 2540 nonzeros
Variable types: 12 continuous, 8 integer (0 binary)
Root relaxation presolved: 127 rows, 20 columns, 2540 nonzeros
Root relaxation: objective 3.722155e+03, 45 iterations, 0.00 seconds (0.00 work units)
Nodes | Current Node | Objective Bounds | Work
Expl Unexpl | Obj Depth IntInf | Incumbent BestBd Gap | It/Node Time
0 0 3722.15470 0 8 - 3722.15470 - - 0s
H 0 0 3789.0149760 3722.15470 1.76% - 0s
0 0 3729.10656 0 8 3789.01498 3729.10656 1.58% - 0s
H 0 0 3783.0598033 3729.10656 1.43% - 0s
0 0 3729.10656 0 8 3783.05980 3729.10656 1.43% - 0s
0 2 3729.10656 0 8 3783.05980 3729.10656 1.43% - 0s
H 17 27 3774.5055277 3731.40208 1.14% 6.1 0s
H 20 27 3767.7824514 3731.40208 0.97% 6.1 0s
H 25 24 3759.2454608 3731.40208 0.74% 6.3 0s
Cutting planes:
Gomory: 4
Explored 148 nodes (703 simplex iterations) in 0.85 seconds (0.52 work units)
Thread count was 32 (of 32 available processors)
Solution count 5: 3759.25 3767.78 3774.51 ... 3789.01
Optimal solution found (tolerance 1.00e-04)
Best objective 3.759245460789e+03, best bound 3.759245460789e+03, gap 0.0000%
0
-
Hi Xintong,
I can reproduce this issue, and it does look like a bug.
I will open up a ticket so we can track this easier, you will receive an email shortly.
- Riley
0
Please sign in to leave a comment.
Comments
1 comment