• Gurobi Staff

Hi Sarath,

Could you post your definitions of $$\texttt{alpha}$$, $$\texttt{theta}$$, and the objective function?

Thanks,

Eli

Hi Eli,

alpha and theta are constants. alpha = np.full((2,2), 0.5)theta = 12, this is how i defined them. Regarding the objective function, I have defined a function which returns an equation, which is assigned to a variable (obj1), then used it in

m1.setObjective(obj1, GRB.MAXIMIZE)

Here's the function defined:

def revenue(w=40, delta=0.99, k=3):

W = w*(1-delta)

I = 0.2*W

#income
a = gp.quicksum(p_solo_1[i,j] * gp.quicksum(f_solo_1[i, j, k] for k in range(2)) for i in range(2) for j in range(2))

#costs
b = sum((-W)* x_1[i,j] for i in range(2) for j in range(2))

c = sum(I * x_1[i,i] for i in range(2))

return ((a+b+c))

obj1 = revenue()

m1.setObjective(obj1, gp.GRB.MAXIMIZE)

I have set the NonConvex parameter to 2 (m1.params.NonConvex = 2)

I don't know if the problem is my code or the jupyter notebook version mismatch. The code is giving solution for some values of (theta) but for other, it is giving the error.

I also have a doubt, is there a difference in (m1.setObjective(obj1, gp.GRB.MAXIMIZE)) and (m1.setObjective(obj1)) i.e., explicitly using "gp.GRB.MAXIMIZE" seems to give different results compared to when it is not called. Thanks!

• Gurobi Staff

Hi Sarath,

By default, Gurobi will try to minimize the objective function. So the solution/behavior will be different if you tell Gurobi to maximize with $$\texttt{gp.GRB.MAXIMIZE}$$.

I could reproduce this issue. I will open a ticket for you in our support portal so we can investigate this further. Thanks!

Eli

• Gurobi Staff

Hi Sarath,

Thanks for letting us know about this. This behavior will be fixed in the next major/minor release of Gurobi.

Best,

Eli

Hi, I was hoping to jump on this thread as well, as I am having a similar issue. I am running Gurobi 9.1.2, Python 3.8.5, and Jupyter notebook on Windows 10, and solving a blending optimization problem similar to the Food Manufacture I example. I have the model running in a for loop so I can observe solution changes as input parameters (e.g. prices or minimum recycled content) change. For most values the model runs fine, but for others it does not and I get the same "Kernel has died unexpectedly" issue as above. As an example, the kernel died when using prices 90% of baseline, but was fine at 80% or 91%. I have no way to know which input parameters could cause the issue.

In my understanding it appears to be a memory issue, and I have tried to limit memory usage using the model.dispose() function at the end of each call. The model output when the kernel survives is:

Gurobi Optimizer version 9.1.2 build v9.1.2rc0 (win64)Thread count: 2 physical cores, 4 logical processors, using up to 4 threadsOptimize a model with 126516 rows, 116899 columns and 1594970 nonzerosModel fingerprint: 0x0b6969b9Model has 278 piecewise-linear objective termsVariable types: 116899 continuous, 0 integer (0 binary)Coefficient statistics:  Matrix range     [5e-03, 1e+02]  Objective range  [0e+00, 0e+00]  Bounds range     [0e+00, 0e+00]  RHS range        [5e-06, 1e+06]Presolve removed 124121 rows and 103915 columnsPresolve time: 0.84sPresolved: 2541 rows, 13322 columns, 101337 nonzerosVariable types: 13256 continuous, 66 integer (66 binary)Root relaxation: objective 2.039568e+08, 5602 iterations, 0.26 seconds    Nodes    |    Current Node    |     Objective Bounds      |     Work Expl Unexpl |  Obj  Depth IntInf | Incumbent    BestBd   Gap | It/Node Time     0     0 2.0396e+08    0   66          - 2.0396e+08      -     -    1sH    0     0                    2.909430e+08 2.0396e+08  29.9%     -    1s     0     0 2.0424e+08    0   33 2.9094e+08 2.0424e+08  29.8%     -    1s     0     0 2.0951e+08    0   31 2.9094e+08 2.0951e+08  28.0%     -    2s     0     0 2.0951e+08    0   30 2.9094e+08 2.0951e+08  28.0%     -    2s     0     0 2.0951e+08    0   26 2.9094e+08 2.0951e+08  28.0%     -    2s     0     0 2.0951e+08    0   24 2.9094e+08 2.0951e+08  28.0%     -    2sH    0     0                    2.095149e+08 2.0951e+08  0.00%     -    2s     0     0 2.0951e+08    0   23 2.0951e+08 2.0951e+08  0.00%     -    2sCutting planes:  Implied bound: 5  Relax-and-lift: 9Explored 1 nodes (5928 simplex iterations) in 2.55 secondsThread count was 4 (of 4 available processors)Solution count 2: 2.09515e+08 2.90943e+08 Optimal solution found (tolerance 1.00e-04)Best objective 2.095149096507e+08, best bound 2.095149096507e+08, gap 0.0000%
And below is what I get when the kernel dies:
Gurobi Optimizer version 9.1.2 build v9.1.2rc0 (win64)Thread count: 2 physical cores, 4 logical processors, using up to 4 threadsOptimize a model with 126516 rows, 116899 columns and 1594970 nonzerosModel fingerprint: 0x28958759Model has 278 piecewise-linear objective termsVariable types: 116899 continuous, 0 integer (0 binary)Coefficient statistics:  Matrix range     [5e-03, 1e+02]  Objective range  [0e+00, 0e+00]  Bounds range     [0e+00, 0e+00]  RHS range        [5e-06, 1e+06]
Please let me know if there is anything I can do!
• Gurobi Staff

I'll open a ticket for you in our online support portal so we can take a closer look at this model.

• Gurobi Staff

Thanks for reporting this issue, John. The issue will be fixed in the next Gurobi release.

Hey

I encountered a similar problem while solving a quadratic optimization problem (facility location problem) with linear constraints using gurobipy matrices. Main parameters of the problem are 2208 no_clusters, 1120 no_pot_sites and 259 ambulances, k=2. The objective is to maximize the demand across the demand sites (2208) and across 8 scenarios. A screenshot of the entire model is below:

When I try to optimize, even though the memory is not fully utilized, it gives a kernel restart error.

In addition I have tried reducing the thread count and NodefileStart parameter.

Kindly help with this!!!

• Gurobi Staff

Thanks for the report, Shayesta. We will investigate this further in our online support portal.

Thanks for the help Eli. I upgraded the software to version 9.1.2, ran in Interactive Shell and the window closed automatically. Below is the snap of the result.

• Gurobi Staff

Hi Shayesta,

Gurobi 9.5 was recently released. Included in this release is a fix for the bug you observed when solving a large MIQP with ~1.5B quadratic nonzero objective terms. Please note that Gurobi does not support solving quadratic programming problems with more than 2B quadratic nonzeros objective terms.

We hope this fix works well for you. Thanks for reporting this bug and please let us know if you see any other issues in the future.

Best regards,

Maliheh

• Gurobi Staff

Hi John,

Gurobi 9.5 was recently released. Included in this release is a fix for the bug you observed when solving a model containing piecewise-linear functions and when Gurobi internally separates the model into connected components. There is no need to set any parameter and this works fine now under the default setting.

We hope this fix works well for you. Thank you for reporting this bug and please let us know if you see any other issues in the future.

Best regards,

Maliheh