Switching from XPRESS

Any program that uses optimization must start by building an optimization model. While the exact details of how models are built depend on the programming language, the general concepts are similar in all of our supported languages. We’ll focus on the concepts, and provide details when appropriate. The first two steps in describing an optimization problem in Gurobi are to create an environment and a model. These are objects in our object-oriented interfaces, created using the GRBEnv and GRBModel constructors, respectively. They are pointers in our C interface, returned by our GRBloadenv() and GRBnewmodel() routines. XPRESS programs start in a similar way, but with slightly different terminology. In XPRESS, you initialize the optimizer (using XPRSinit/XPRBinit), and then create a problem (XPRScreateprob()/XPRBnewprob()). The next step is generally to list your decision variables. This is done using the GRBaddvar() routine in C, and the addVar() method in our object-oriented interfaces. You can add one variable at a time, or you can add multiple variables (using GRBaddvars() or addVars()). We generally find it more convenient to add one variable at a time, and there is no performance penalty for doing so, but you may want to add multiple variables if your Xpress program already does so. One difference between Gurobi and XPRESS is that we use a “lazy update” approach. After making changes to a model, you need to call GRBupdatemodel/GRBModel.update in order for those changes to be visible. To be more specific, you’ll need to call “update” after adding variables to the model, in order to use those variables in constraints. Our lazy update approach makes it easier and more efficient to build or modify a model, since you have complete control over when the actual changes take place. However, this difference between our interface and the XPRESS interface is something you’ll need to remember. Decision variables have a number of attributes, including variable type (continuous, binary, etc.), lower bound, upper bound, etc.. You have two choices for specifying these. The first is to input the desired attribute values when you create the variable (i.e., as arguments to addVar()). The second is to modify the attributes after the variable has been added to the model, using one of the various Gurobi set routines (e.g., GRBsetintattr() in C, GRBVar.set() in C++). Attributes are an important concept in the Gurobi interface. Rather than providing dozens of different routines for accessing and modifying the various attributes of a model, as is done in XPRESS, we handle them through a single interface. To give an example, below is the command, shown in a range of languages, you would use to change the upper bound on variable x to 1.0:

Similarly, to change the lower bound:

Again, this is just a partial list of the parameters you might be using in XPRESS. If you are modifying a parameter that isn’t on this list, we encourage you to browse the list of Gurobi parameters in our Reference Manual

View the Manual

Once you know which parameters you would like to change, the code required to change them is straightforward. In C, you call GRBsetintparam/GRBsetdblparam/GRBsetstringparam. In our object-oriented interfaces, you call the set() method on the GRBEnv object. One point that sometimes trips people up when migrating from XPRESS to Gurobi is that Gurobi gives each model its own copy of a Gurobi environment, thus allowing each model to have its own parameter settings. In XPRESS, all models use the same parameter values. The simplest approach to managing this is to set parameters for a model as follows:

The computed values for the decision variables are also attributes: