メインコンテンツへスキップ

Why the following model showing infeasible in gurobipy when the same is solved optimally by MIP python open source solver? What am I missing ? Is it the operation between arrays and guobi variables the issue? How to find out?

回答済み

コメント

6件のコメント

  • 正式なコメント
    Simranjit Kaur
    • Gurobi Staff Gurobi Staff
    This post is more than three years old. Some information may not be up to date. For current information, please check the Gurobi Documentation or Knowledge Base. If you need more help, please create a new post in the community forum. Or why not try our AI Gurobot?.
  • Alison Cozad
    • Gurobi Staff Gurobi Staff

    First, I suspect  that you may have an index error in the following constraints:

    o.addConstr((grb.quicksum(r[k]* y[k,j] for jj in b if jj <=j)) >= (grb.quicksum(( grb.quicksum (q[i][k]* x[i,jj] for i in a )for jj in b if jj <=j))))

    I think you meant to use \(\texttt{y[i,jj]}\) rather than \(\texttt{y[i,j]}\)  in the first quicksum.  When I make this change, your model is feasible.  I found this after reviewing your IIS results file, "guro11w.ilp", to narrow my search to the second, third, and fourth set of constraints.

    If this is not what you intended, then I recommend plugging in the solution from the open-source solver into the Gurobi model?  You could try doing this as a MIPStart or by fixing the upper and lower bound of each variable to the solution.

    0
  • Gnanadeepan D
    • Gurobi-versary
    • First Comment
    • First Question

    Thank you Alison.

    Yes, i corrected that blunder mistake, now its feasible and now the issue is when the input of d=[11,1,1,1,1,1,1,1,1,1] and s=[12,9,6,6] as I commented in the code, the solver taking too much time ( more than 2 hours, i didn't see the solution) but it has only 282 variables and 154 constraints. Why is that? How to simplify it to solve quickly?

    0
  • Alison Cozad
    • Gurobi Staff Gurobi Staff

    I am guessing you meant to set the following:

    s = [11,1,1,1,1,1,1,1,1,1]
    d = [12,9,6,6]

    When I run this problem, Gurobi solves it quite quickly (<1 second).  What version of Gurobi are you using?

    It might help if I could see the log file from your long solve.  Could you pass along this log file?  Fore tips on sharing files, please see Posting to the Community Forum > Sharing files.

    0
  • Gnanadeepan D
    • Gurobi-versary
    • First Comment
    • First Question

    Hi Alison, I missed an important point in the previous query, i have changed two constraints according to my model which elapsed the solver time, its been more than 2 hours, I'm waiting for the solution. Following is the code for that. Any way to solve quickly?

    import random
    import gurobipy as grb
    import math
    q=[[4,5,0,2],[3,2,1,0],[0,1,4,5],[3,2,0,1],[2,1,3,2],[4,3,2,1],[3,4,2,0],[5,0,3,1],[0,4,3,3],[4,0,4,1]] 
    s=[11,1,1,1,1,1,1,1,1,1]
    #s=[20,0,0,0,0,0,0,0,0,0]
    r=[6,8,4,7]
    a=range(0,10)
    b =range(0,20)
    c = range(0,4)
    d =[12,9,6,6]
    #d=[14,13,0,6]
    o = grb.Model()
    x = {}
    for i in a:
    for j in b:
    x[i,j] = o.addVar(vtype=grb.GRB.BINARY, name='x'+str(i)+'_'+str(j))
    y = {}
    for k in c:
    for j in b:
    y[k,j] = o.addVar(vtype=grb.GRB.BINARY, name='y'+str(k)+'_'+str(j))
    g=o.addVar(vtype=grb.GRB.INTEGER,name='g')
    h=o.addVar(vtype=grb.GRB.INTEGER,name='h')
    for i in a:
    o.addConstr((grb.quicksum(x[i,j] for j in b)) == s[i])
    for j in b:
    o.addConstr((grb.quicksum(x[i,j] for i in a)) == 1)
    for k in c:
    o.addConstr((grb.quicksum(y[k,j] for j in b)) == d[k])
    for j in b:
    for k in c:
    o.addConstr((grb.quicksum(r[k]* y[k,jj] for jj in b if jj <=j)) >= (grb.quicksum(( grb.quicksum (q[i][k]* x[i,jj] for i in a )for jj in b if jj <=j))))
    for j in b:
    o.addConstr((grb.quicksum( grb.quicksum(r[k] * y[k,jj] for k in c) for jj in b if jj <= j)) - (grb.quicksum(grb.quicksum( grb.quicksum (q[i][k]* x[i,jj] for i in a) for k in c) for jj in b if jj<=j)) <= g)
    for j in b:
    o.addConstr((grb.quicksum( grb.quicksum(r[k] * y[k,jj] for k in c) for jj in b if jj <= j)) - (grb.quicksum(grb.quicksum( grb.quicksum (q[i][k]* x[i,jj] for i in a) for k in c) for jj in b if jj<=j)) >= h)
    objective = (g-h)
    o.ModelSense = grb.GRB.MINIMIZE
    o.setObjective(objective)
    o.update()
    o.write('guro11.lp')
    o.optimize()
    if o.status == grb.GRB.OPTIMAL:
    print('Optimal objective: %g' % o.objVal)
    elif o.status == grb.GRB.INF_OR_UNBD:
    print('Model is infeasible or unbounded')
    sys.exit(0)
    elif o.status == grb.GRB.INFEASIBLE:
    print('Model is infeasible')
    sys.exit(0)
    elif o.status == grb.GRB.UNBOUNDED:
    print('Model is unbounded')
    sys.exit(0)
    else:
    print('Optimization ended with status %d' % o.status)
    sys.exit(0)
    for v in o.getVars():
    print('%s %g' % (v.varName, v.x))
    0
  • Alison Cozad
    • Gurobi Staff Gurobi Staff

    Gurobi has a number of tuning parameters that can affect solver performance.  While it may be daunting to sort through each parameter individually, there is an automatic Parameter Tuning Tool built into Gurobi. This helps with some of the heavy lifting of trying to select the right levels of the many parameters that affect Gurobi performance.

    Additionally, it may be useful to be more aggressive with flow cover cuts.  You can do this by setting FlowCoverCuts to 2.

    0

投稿コメントは受け付けていません。