GRBVar objects behaviour (and other questions)
AnsweredHi, I have a few questions about Gurobi 9.5 API. I mainly use the Java API, so I will use its syntax in my questions (but sometimes I also use the Python API, so please specify which answers are specific to Java).
1) Is the GRBVar type mutable or immutable? E.g., suppose I get a reference V to an instance of GRBVar (via model.getVar(...) or model.getVars(...)), next I run model.optimize() and after it completes I run V.get(GRB.DoubleAttr.X). What do I get? The final value of variable V or its initial value? In other words, are GRBVar instances just an immutable snapshot of the state of a variable when it is retrieved or a living representation of the variable "internal" state?
2) More broadly, does all Java objects returned by Gurobi API behave in the same way as in the answer to question (1)?
3) How the index of a variable is determined (i.e., the value to be used in model.getVar(int index))? Does it correspond to the order in which variables are added to the model?
4) Does the order of variables in the array returned by model.getVars() coincide with the order in which variables are added to the model?
5) Inside my editor (VSCode) I see that GRBModel also has a getVarByName(String name) method, but (apparently) it is not documented. Should I use it?
6) In general, what is the recommended way to retrieve variables? By index with model.getVar(int index) or by name with model.getVarByName(String name).
7) Can I increase (or decrease) the number of threads that Gurobi can use while model.optimize() is running? I would like to set this parameter inside a callback. If this is not possible, I suppose that the only other way is to terminate() the current optimization process, set the new number of threads and restart model.optimize(). Is there a better way?
8) Another Gurobi user told me that the solution passed to the setSolution(...) method inside a callback may not be used immediately (even if you call useSolution()), but the evaluation of the new solution may be delayed even for a few minutes. Is it (still) true?
Side question: if I will ever need in future to post a similar "batch" of questions, do you prefer all of them in a single post, or one post for each question?
Thank you in advance for your answers!
-
Official comment
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 Lorenzo,
I'll try and answer these.- They are not constant. If you look at the examples: Mip1.java it is very easy to see this use. I'm not sure these objects would be very useful otherwise.
- Same for other GRB constructs: constraints, linear expressions, ...
- I think so, you can also query the index: GRBVar.index().
- I think so, but I would keep them locally and query them individually to make sure.
- It is documented: GRBModel.getVarByName(). VSCode probably only picks up the docstrings in the classpath which are not up-to-date.
- Same as 4. It will be more performant if you are going to query them often. But maybe getVarByName as it is a bit safer.
- Not allowed to change parameters in a callback, as you say, you can terminate and restart: How do I change parameters in a callback?
- Yes, this is still the case. At some points of the solution process, Gurobi can just be busy with something that is incompatible (different algorithms, cut generation, ...). But if you use GRBCallback.useSolution it is processed asap after, this could well be immediate. Please note that the solution may be discarded if it is worse than the ones already found. Also, see: GRBCallback.setSolution().
Hope this helps.
Cheers,
David0 -
Side question: if I will ever need in future to post a similar "batch" of questions, do you prefer all of them in a single post, or one post for each question?
I am happy with this format as some of these are related :)
But maybe it is better for searching purposes to have them split into different questions, but I guess it is entirely up to you!
Cheers,
David0
Post is closed for comments.
Comments
3 comments