Skip to main content

Does assignment order matter?

Answered

Comments

4 comments

  • Maliheh Aramon
    Gurobi Staff Gurobi Staff
     
    Hi Taylor, 
     
    Problem constraints define the feasible search space and the order by which you implement them does not matter. 
     
    The two implementation above are the same. Can you please elaborate how the order by which constraints are implemented is going to make a difference in your application?
     
    You can also remove the variable \(\texttt{x[i, j]}\) from the LHS of the indicator constraints. For example, this constraint
    m.addGenConstrIndicator(x[i, j], True, x[i, j] * ordrs.loc[j,'ORDR_MI'] <= 1000)
    can be replaced by:
    m.addGenConstrIndicator(x[i, j], True, ordrs.loc[j,'ORDR_MI'] <= 1000)
     
    Best regards,
    Maliheh
    1
  • Taylor Bosier
    Gurobi-versary
    First Comment
    First Question

    Hi Maliheh,

    When does one typically use the x[i,j]* piece? I wonder if that's messing up my results...

    Best,

    Taylor Bosier

    0
  • Taylor Bosier
    Gurobi-versary
    First Comment
    First Question

    Additionally, I'm curious if my whole set up is incorrect for my constraints. I'm getting pretty bad results and I think it has to do with how the constraints are set up. 

     

    I think this is incorrectly set up. the for loop being outside the constraint makes me think it is creating a lot more constraints than necessary. 

     

    Here are some of them:

    # Add constraints
            # drvrs are assigned to at most 1 order
            for i in drvr_cd:
                m.addConstr(quicksum(x[i, j] for j in ordr_nbr) <= 1)
               
            # Ordrs are assigned to at most 1 driver
            for j in ordr_nbr:
                m.addConstr(quicksum(x[i, j] for i in drvr_cd) <= 1)    

            # Pickup appointment is obeyed
            # Drivers project time of availability must fall between 90 minutes before an order's pull time and up to the pull time
            for i in drvr_cd:
                for j in ordr_nbr:
                    m.addGenConstrIndicator(x[i, j], True,
                                            x[i, j] * drvrs.loc[i,'DRVR_PTA_INT'] >= ordrs.loc[j,'CRIT_PULL_INT']-90)
                    m.addGenConstrIndicator(x[i, j], True,
                                            x[i, j] * drvrs.loc[i,'DRVR_PTA_INT'] <= ordrs.loc[j,'CRIT_PULL_INT'])


         
    0
  • Maliheh Aramon
    Gurobi Staff Gurobi Staff
     
    Hi Taylor, 

    When does one typically use the x[i,j]* piece? I wonder if that's messing up my results

    Defining \(o_j\) to represent \(\texttt{orders.loc[j,'ORDD_MI']}\), the indicator constraint states:
    • If \(x_{ij}\) = 1, then \(o_j \leq 1000\)
    Therefore, there is no need to write the RHS as \(x_{ij} o_j\) because the RHS condition is only relevant when \(x_{ij} = 1\). 
     
    The constraints that you copied look good to me given their descriptions. 
     
    If by getting pretty bad results, you are referring to the performance of Gurobi on your model,
    you might consider using Gurobi parameter tuning tool to potentially find a set of parameters that improve the solver performance. 
     
    In case you are referring to getting solution values that do not make sense given your constraints, you can write your model into an LP format and investigate the constraints that are not satisfied to develop insights on what might be wrong. 
     
    Best regards,
    Maliheh
    0

Please sign in to leave a comment.