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()

Matthias Miltenberger

Gurobi Staff

April 06, 2023 09:41

Hi Lorenzo!

This is certainly not expected behavior. Could you please share a minimal working example?

Thanks,
Matthias

Lorenzo Moreschini

April 06, 2023 10:10

Hi Matthias, I prepared a MWE here:
https://drive.google.com/file/d/1Nmop5bxuBb9xsKskHhoKEbqpsDj2m9TG/view?usp=sharing

The 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.

April 06, 2023 11:26

We will handle this in an internal ticket and post the resolution here at a later point in time.

Marika Karbstein

April 06, 2023 11:31

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

April 06, 2023 11:39

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.)

Unexpected MIP_SOLCNT value

Comments

Didn't find what you were looking for?