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:

When migrating an optimization model from XPRESS to Gurobi, you may need to set certain Gurobi parameters to match the parameters you have modified in XPRESS. One important point we’d like to make is that you shouldn’t assume that you’ll need to find a matching Gurobi parameter for every XPRESS parameter you’ve changed. Gurobi and XPRESS use different strategies and algorithms. Gurobi strategy tuning may differ from the XPRESS tuning you’ve done, and often it may not be necessary at all. We recommend that you start with default settings, and only change parameters when you observe specific behavior that you’d like to modify.

The following table gives a high-level mapping for the most commonly used XPRESS parameters:

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.

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:

Once you have formulated your optimization model and set solver parameters, the last step is to compute a solution. You do this by calling GRBoptimize() in C, or GRBModel.optimize() in our object-oriented interfaces. The optimization will complete when one of your requested termination conditions (optimality gap, time limit, solution limit, etc.) are met.

You should always check the status of the optimization once it completes. Again, rather than providing dozens of get/set routines, we return the status as an attribute of the model. You query it with the appropriate attribute get routine.

For example:

The computed values for the decision variables are also attributes: