Unexpected MIP_SOLCNT value
回答済みI am experimenting an unexpected behaviour of the callback value MIP_SOLCNT, which should print the number of feasible solutions found so far (I am solving a MIP problem).
As you can see from the log below, the value of MIP_SOLCNT is a huge number, but the Gurobi log table says that there is no incumbent solution, how is it possible?
Gurobi Optimizer version 10.0.1 build v10.0.1rc0 (win64)
CPU model: Intel(R) Xeon(R) Gold 6140M CPU @ 2.30GHz, instruction set [SSE2|AVX|AVX2|AVX512]
Thread count: 16 physical cores, 16 logical processors, using up to 16 threads
Optimize a model with 809170 rows, 199670 columns and 4032144 nonzeros
Model fingerprint: 0x6fa72fa0
Variable types: 0 continuous, 199670 integer (199043 binary)
Coefficient statistics:
Matrix range [1e+00, 3e+03]
Objective range [1e+00, 1e+00]
Bounds range [1e+00, 1e+00]
RHS range [1e+00, 8e+03]
Presolve removed 23194 rows and 89959 columns (presolve time = 5s) ...
Presolve removed 23360 rows and 89959 columns (presolve time = 10s) ...
Presolve removed 23360 rows and 89959 columns (presolve time = 15s) ...
Presolve removed 40666 rows and 90624 columns (presolve time = 21s) ...
Presolve removed 40723 rows and 90624 columns (presolve time = 25s) ...
Presolve removed 42181 rows and 91408 columns
Presolve time: 28.00s
Presolved: 766989 rows, 108262 columns, 3634243 nonzeros
Variable types: 0 continuous, 108262 integer (107691 binary)
Deterministic concurrent LP optimizer: primal simplex, dual simplex, and barrier
Showing barrier log only...
Root relaxation presolved: 108262 rows, 875251 columns, 3742505 nonzeros
Root barrier log...
Ordering time: 0.17s
Barrier statistics:
Free vars : 63
AA' NZ : 1.181e+06
Factor NZ : 1.467e+06 (roughly 400 MB of memory)
Factor Ops : 2.635e+08 (less than 1 second per iteration)
Threads : 13
Barrier performed 0 iterations in 49.63 seconds (21.39 work units)
model solved by another algorithm
Concurrent spin time: 1.09s (can be avoided by choosing Method=3)
Solved with dual simplex
Root relaxation: objective 3.988500e+04, 23717 iterations, 9.94 seconds (3.22 work units)
Total elapsed time = 57.49s
Total elapsed time = 62.13s
Nodes | Current Node | Objective Bounds | Work
Expl Unexpl | Obj Depth IntInf | Incumbent BestBd Gap | It/Node Time
0 0 39885.0000 0 4749 - 39885.0000 - - 70s
MIP solcnt: 597329432
0 0 46712.4099 0 776 - 46712.4099 - - 112s
MIP solcnt: 1872235719
0 0 47039.5447 0 427 - 47039.5447 - - 121s
MIP solcnt: 1872235719
0 0 47328.0000 0 384 - 47328.0000 - - 132s
MIP solcnt: 1872235719
0 0 47328.0000 0 397 - 47328.0000 - - 142s
MIP solcnt: 1872235719
I am using python 3.11 on Windows 10 and Gurobi 10 (from anaconda).
I would like not to disclose the model (plus its not trivial), but I think its not relevant here.
Here is my callback function that prints the lines above (currently I reach the 1200 second time limit when no solution has been found, but `solcnt > 0` is true nevertheless).
def model_callback(model, where):
if where == GRB.Callback.MIPNODE:
solcnt = model.cbGet(GRB.Callback.MIP_SOLCNT)
if solcnt > 0:
print("MIP solcnt: ", solcnt)
if solcnt > 0 and model.cbGet(GRB.Callback.RUNTIME) > 1200:
print("Ask Gurobi to terminate")
model.terminate()
-
Hi Lorenzo!
This is certainly not expected behavior. Could you please share a minimal working example?
Thanks,
Matthias0 -
Hi Matthias, I prepared a MWE here:
https://drive.google.com/file/d/1Nmop5bxuBb9xsKskHhoKEbqpsDj2m9TG/view?usp=sharingThe link is protected, so when you open it I will receive an access request and I will grant it to you (or anyone from the gurobi.com domain).
As you can see from the log file I made it on MacOSX 10.13.6 using Gurobi 10.0.0 rc2 and the same behaviour occurred.
0 -
We will handle this in an internal ticket and post the resolution here at a later point in time.
0 -
Hi Lorenzo,
If you are in the MIPNODE callback, you also need to call MIPNODE_SOLCNT and not MIP_SOLCNT.
It should then work.Cheers,
Marika0 -
Thank you all.
(If I had to make a lucky guess, it seems like the memory area where the MIP_SOLCNT value should be placed is not initialized to 0 at the beginning and, if accessed before the first feasible solution has been found, there is just a random value.)
0
サインインしてコメントを残してください。
コメント
5件のコメント