Gurobi solution created new variables with prefix name of MPS_Rg. What does this mean?
回答済みI am creating a new model, adding one new constraint at a time to make sure the model is working with each new constraint.
I just added a new constraint equation and ran the solution. Gurobi returned the solution, however, the solution contained a series of new variables which I did not create and are not in the MPS file that I generated for Gurobi to solve. These variables appear to be related to this newest constraint set, as they use the constraint equation name as part of the variable name. These variables all have the prefix MPS_Rg added to the front of the constraint name.
For example, I named a constraint row "R-R11_Q0". In the solution, I find a single variable named: "MSP_RgR11_Q0". In some cases this mystery variable is assigned a non-zero value by the solution, but most of them are assigned values of 0.
Why did Gurobi do this? What does it mean? How do I fix my constraint so that this variable does not get created?
My assumption is that there is something wrong with this new constraint I just added. The constraint is essentially:
sum( 5 to 10 variables ) <= 2
I have other similar constraints that don't exhibit this mystery variable creation.
Note that the overall solution is still valid. Note that if I remove the constraint, everything works as expected.
Thanks for any help or pointers on this problem.
-
正式なコメント
-
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?. -
-
So, I believe I have figured this out.
It appears that MPSRg*blort* is a dummy variable created by Gurobi for the constraint row named *blort*. It appears to add this variable in order to make the constraint row be treated as an "E" (Equals) constraint row, and then sets the value of the dummy variable so that the constraint is TRUE.
Curiously, my constraint row of R-R11_Q0 was defined as an "L" constraint. I had set both a Max and a Min for this constraint row, and Gurobi used the dummy variable to make the constraint always equal to the Max value.
When I removed the Min constraint, Gurobi stopped creating the dummy variable and allowed the constraint value to float around anywhere between 0 and the Max.
Unless I am missing something, it seems like the Gurobi solution should be the same whether I set a constraint row to have a Min of 0 and a Max of some positive value or I set that constraint row to have only a Max. That is, not to throw in the unexpected dummy variable in one case and not the other. My preference is not to have the dummy variable (I don't like it when things magically appear with no explanation--these dummy variables do not appear to be mentioned anywhere in the Gurobi documentation.)
At some point, I am sure I will need to use an upper and (non-zero) lower bound on a constraint row and will have to look at this dummy variable issue again.
I'd be happy to hear from anyone who can shed further light on this issue. Thanks.
0 -
-
-
It sounds like you are adding a "range constraint" to your model, which requires that the value of an expression lies within the specified range. Gurobi creates a new variable when modeling such constraints (e.g., see the documentation for GRBaddrangeconstr() in C or Model.addRange() in Python).
If you want to avoid the new variable, you can manually add two separate constraints for the lower and upper bounds. As an example in Python, instead of adding a range constraint with
m.addConstr(x + y == [0, 5], name="range0")
you can write
m.addConstr(x + y >= 0, name="expr_lb")
m.addConstr(x + y <= 5, name="expr_ub")1 -
-
Thanks for the pointers to the documentation, I understand what is happening and why the new variable was added, and how to make it operate the way that I want it to work!
0 -
投稿コメントは受け付けていません。
コメント
4件のコメント