Gurobi stops storing variable names to the MPS file for large models, which breaks my use case - uses place holder names instead
回答済みDear all,
In my application I use the names of the Gurobi variables and constraints to match them to objects in my program code, which I then use to display them to the user for interaction in a GUI. For example: a user can interactively introduce/remove predefined constraints through a GUI to manipulate the result of the optimal solution, which is then updated and shown in the GUI.
I mostly got this to work by doing the following:
1. I give a unique name to each Gurobi variable and constraint.
2. I use the name arguments of the Java API methods addVar and addConstr, when creating a variable. I make sure that the argument 'String name' is unique:
addVar(double lb, double ub, double obj, char type, String name)
addConstr(GRBLinExpr lhsExpr, char sense, double rhs, String name)
3. To query the state of variables and constraints I use these methods with the respective names:
getVarByName(String name)
getConstrByName(String name)
This works well for newly created models. I am now working on the ability to save and load models from disk, that were manipulated by the user. I am storing the model and solution to MPS and SOL files using model.write(...) and loading them from disk using GRBModel(GRBEnv env, String filename). This is where I ran into issues ...
For small models saving/loading works as expected, but for large models it stops working. The reason seems to be that the MPS file does contain the variable name for small models, but it does _not_ contain them for large models. This can be seen in these excerpts from the respective MPS files:
Excerpt from MPS file for small model:
E ContinuityConstraintAtT399_Id4062
E ContinuityConstraintAtT399_Id4063
E ContinuityConstraintAtT399_Id4064
E ContinuityConstraintAtT399_Id4065
E ContinuityConstraintAtT399_Id4066
COLUMNS
MARKER 'MARKER' 'INTORG'
MappingAtT0_HypAtT0Top190Bottom231_HypAtT1Top143Bottom186 OBJ -2.1306031942367554e-01
MappingAtT0_HypAtT0Top190Bottom231_HypAtT1Top143Bottom186 ExitConstraintAtT0_311356_Id3 1
MappingAtT0_HypAtT0Top190Bottom231_HypAtT1Top143Bottom186 PathBlockingConstraintAtT0_Id3 1
MappingAtT0_HypAtT0Top190Bottom231_HypAtT1Top143Bottom186 ContinuityConstraintAtT1_Id0 1
MappingAtT0_HypAtT0Top190Bottom231_HypAtT1Top190Bottom233 OBJ -3.1606477499008179e-01
MappingAtT0_HypAtT0Top190Bottom231_HypAtT1Top190Bottom233 ExitConstraintAtT0_311356_Id3 1
MappingAtT0_HypAtT0Top190Bottom231_HypAtT1Top190Bottom233 PathBlockingConstraintAtT0_Id3 1
MappingAtT0_HypAtT0Top190Bottom231_HypAtT1Top190Bottom233 ContinuityConstraintAtT1_Id1 1
MappingAtT0_HypAtT0Top190Bottom231_HypAtT1Top311Bottom356 OBJ 1.9833617210388184e+00
Excerpt from MPS file for large model:
E ContinuityConstraintAtT479_Id4952
E ContinuityConstraintAtT479_Id4953
E ContinuityConstraintAtT479_Id4954
E ContinuityConstraintAtT479_Id4955
E ContinuityConstraintAtT479_Id4956
E ContinuityConstraintAtT479_Id4957
COLUMNS
MARKER 'MARKER' 'INTORG'
B0(3) OBJ -3.1606477499008179e-01
B0(3) ExitConstraintAtT0_311356_Id2 1
B0(3) PathBlockingConstraintAtT0_Id1 1
B0(3) ContinuityConstraintAtT1_Id0 1
B1(3) OBJ 1.9833617210388184e+00
B1(3) ExitConstraintAtT0_311356_Id2 1
B1(3) PathBlockingConstraintAtT0_Id1 1
B1(3) ContinuityConstraintAtT1_Id1 1
B2(3) OBJ -2.1306031942367554e-01
B2(3) ExitConstraintAtT0_311356_Id2 1
B2(3) PathBlockingConstraintAtT0_Id1 1
B2(3) ContinuityConstraintAtT1_Id2 1
B3(5) OBJ 6.7840808629989624e-01
As you can see in the MPS file of the large model, the names were replaced with place-holder like "B0(3)" (note that the constraint names are maintained). I do not understand, why this is happening.
I found this discussion that describes the same issue: https://groups.google.com/g/gurobi/c/g-xZf_cuG-M
It suggests that the reason could be either having the "IgnoreNames" parameters set to "1" (described here: https://www.gurobi.com/documentation/9.5/refman/ignorenames.html) or having duplicate variable names.
I have confirmed that IgnoreNames is set to "0" (its default setting) and I cannot find any duplicate names (furthermore (as mentioned) everything works as expected for smaller models and I do not see how duplicate names could suddenly be introduced for larger models).
So are there other suggestions for what is going on here?
Does Gurobi try to reduce file-size by switching to markers (which are shorter than the full variable name) when there are "a lot" of variables?! (in that case, where is the lookup-table)
I would be very grateful for any suggestions on how to solve this!
Best regards and thank you,
Michael
-
正式なコメント
-
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 try Gurobot, our chatbot interface offering instant, expert-level support. -
-
-
Hi Michael,
Does Gurobi try to reduce file-size by switching to markers (which are shorter than the full variable name) when there are "a lot" of variables?! (in that case, where is the lookup-table)
No, if unique names are provided then Gurobi does not replace any user given names.
Could you please provide a minimal reproducible example showing this issue? It is not possible to upload files in the Community Forum, but we describe a way for sharing files in Posting to the Community Forum.
Best regards,
Jaromił0 -
-
Dear Jaromil,
to follow up on this issue: I was able to solve it. Indeed, the reason was the duplication of variable names. There was a bug in the code that caused this.
Best regards and thank you,
Michael
0 -
投稿コメントは受け付けていません。
コメント
3件のコメント