Problem in Understanding the difference between the two approaches (1. accessing a list value directly for comparison in constraint. 2 assigning the list values to a variable and then comparing it in a constraint
AnsweredHello,
I want to understand the difference between the two approaches (1. accessing a list value directly for comparison in constraint. 2 assigning the list values to a variable and then comparing it in a constraint).
I have a python list: Vul: [2.1, 3.4, 4.5..........]
I have defined a variable named vulvar with obj value as the Vul lists: vulvar=m.addVars(len(Vul), vtype=GRB.CONTINUOUS, obj=Vul,name="vul")
I have a second variable Vpredicted = m.addVars(len(Vul), vtype=GRB.CONTINUOUS,name="vp")
Now in a loop My Vpredicted is defined like this: Vpredicted[j]=LinExpr((Rl[j]*0.09824401+ Rm[j]*0.1181632 +Rh[j]*0.125712+(0.3646754))
While optimization
When I am using this constraint : m.addConstr(Vplist[j]<=Vul[j]) (1)
This is what I get as result: Solved with barrier
Solved in 0 iterations and 0.43 seconds
Infeasible model
Encountered an attribute error
Where as ,when I am using this as a constraint : m.addConstr(Vpredicted[j]<=vulvar[j]) (2)
I am getting a solution.
Can you help me why it is so: What I think is that when I have defined vulvar with obj values than the list values: are assigned to the variable. I looked in the various examples: like facility example where demand values (List) are assigned to the variable and while optimizing the values of the list are the actual range of values considered during optimization.
Regards,
Vaibhav

Hi Vaibhav,
First, I'll clarify a few general concepts related to optimization. The line
vulvar=m.addVars(len(Vul), vtype=GRB.CONTINUOUS, obj=Vul,name="vul")
adds a number of nonnegative continuous variables to your model (one for each element in the Vul list). The obj argument sets the objective coefficients for these variables, per the documentation. For example, consider the following code:
myObj = [1, 5, 10]
vulvar = m.addVars(range(3), obj=myObj, name="vul")In this case, we introduce three nonnegative continuous variables. These variables show up in the objective function with the corresponding coefficients from myObj:
>>> m.getObjective()
<gurobi.LinExpr: vul[0] + 5.0 vul[1] + 10.0 vul[2]>Note that we did not assign any values to the variables. It is up to Gurobi to assign values to these variables during the optimization process such that i) the variables satisfy all of the constraints, and ii) the objective function value is as good as possible.
Also, the demand values are never assigned to a variable in the facility.py example. Perhaps you're referring to this line:
m.addConstrs((transport.sum(w) == demand[w] for w in warehouses), "Demand")
The idea here is that the sum of goods transported from all plants to a particular warehouse must satisfy the demand at that warehouse. I.e., this line generates the following constraints:
trans[0,0] + trans[0,1] + trans[0,2] + trans[0,3] + trans[0,4] == 20
trans[1,0] + trans[1,1] + trans[1,2] + trans[1,3] + trans[1,4] == 15
trans[2,0] + trans[2,1] + trans[2,2] + trans[2,3] + trans[2,4] == 18
trans[3,0] + trans[3,1] + trans[3,2] + trans[3,3] + trans[3,4] == 14Any feasible solution to this problem must satisfy the above constraints.
Next, I'll make a few comments about your example. When you define Vpredicted[j] with
Vpredicted[j]=LinExpr((Rl[j]*0.09824401+ Rm[j]*0.1181632 +Rh[j]*0.125712+(0.3646754)))
you replace your references to the vp variables with the linear expression, so the vp variables do not actually show up in the constraints that you subsequently define. To define an equality relationship between the Vpredicted variable and an expression, you can use the following:
m.addConstr(Vpredicted[j] == Rl[j]*0.09824401+ Rm[j]*0.1181632 +Rh[j]*0.125712+(0.3646754))
It's unclear from your example what Rl, Rm, and Rh are. If these are numbers instead of variables, then you are setting Vpredicted[j] to some fixed value. Also, I'm not sure what Vplist in (1) is. Maybe this should be Vpredicted? If so, the issue could be that there exists some j for which Vpredicted[j] > Vul[j]. Both of these are fixed values, so you are adding a constraint like (e.g.)
8 <= 3
There is no possible assignment of values to vulvar that would make this relationship true, since the statement is always false. As such, Gurobi reports that the model is infeasible. Every constraint should have a variable in it.
In contrast, with (2) you add constraints that provide lower bounds on all of the vulvar variables. A solution to the problem is only considered feasible if the vulvar variables have values at least as large as the corresponding values in the Vpredicted list.
It might be useful to look at the documentation to see an example of the relationships between decision variables, constraints, and the objective function in an optimization model. I hope this helps!
Eli
0 
Hi Towle,
Thanks for the reply.
Rl,Rh and RM are variables. And Vplist is a typing mistake it has to be Vpredicted. So how do I compare my Vpredicted with a parameter because I want something like this in my constraint.Vpredicted[I]<=( a parameter whose value is known)
To handle this I tried both the ways. Now as you have said there has to be a variable in the constraint, how do I define this statement. Do I need to define Vpredicted as a variable?
Regards,Vaibhav
0 
Hi Vaibhav,
Okay, thanks for the clarification. With (1), there are still variables in the constraint, because the Vpredicted linear expression includes the Rl, Rm, and Rh variables.
It seems that your model is infeasible. (2) is only feasible because the solver can make the values of vulvar sufficiently large such that the constraints are always satisfied. As I mentioned, the obj attribute is not used to fix variables. In (1), the values of Var are parameters that cannot be changed by the solver.
To visually inspect the model, you can write it to an LP file. This may help you verify that your constraints are being written correctly. To do this, simply use
m.write("model.lp")
Additionally, Gurobi can find which constraints in your model are inconsistent (i.e., result in an empty feasible region when considered together). To output a socalled "irreducible inconsistent subsystem", you can use
m.computeIIS()
m.write("model.ilp")after the call to optimize(). The generated model.ilp file stores the group of constraints cannot be satisfied together. For more information on this, see the documentation.
Eli
0
Please sign in to leave a comment.
Comments
3 comments