Models#

Our Gurobi R interface enables you to express problems of the followingform:

Models are stored aslist variables, each consisting of multiplenamed components. The named components capture the different modelcomponents listed above. Many of these model components are optional.For example, integrality constraints may be omitted.

An optimization model may be loaded from a file (using thegurobi_read function), or it can be built by populating theappropriate named components of a model variable (using standardR constructs). We will discuss the details of how models are representedin themodel argument section.

We often refer to theclass of an optimization model. At the highestlevel, a model can be continuous or discrete, depending on whether themodeling elements present in the model require discrete decisions to bemade. Among continuous models…

• A model with a linear objective function, linear constraints, andcontinuous variables is aLinear Program (LP).

• If the objective is quadratic, the model is aQuadratic Program(QP).

• If any of the constraints are quadratic, the model is aQuadratically-Constrained Program (QCP). We sometimes refer to afew special cases of QCP: QCPs with convex constraints, QCPs withnon-convex constraints,bilinear programs, andSecond-Order ConePrograms (SOCP).

• If any of the constraints are non-linear (chosen from among theavailable general constraints), the model is aNon-Linear Program(NLP).

A model that contains any integer variables, semi-continuous variables,semi-integer variables, Special Ordered Set (SOS) constraints, orgeneral constraints, is discrete, and is referred to as aMixed IntegerProgram (MIP). The special cases of MIP, which are the discreteversions of the continuous models types we’ve already described, are…

• Mixed Integer Linear Programs (MILP)

• Mixed Integer Quadratic Programs (MIQP)

• Mixed Integer Quadratically-Constrained Programs (MIQCP)

• Mixed Integer Second-Order Cone Programs (MISOCP)

• Mixed Integer Non-Linear Programs (MINLP)

The Gurobi Optimizer handles all of these model classes. Note that theboundaries between them aren’t as clear as one might like, because weare often able to transform a model from one class to a simpler class.

Solving a Model#

Once you have built a model, you can callgurobi to compute asolution. By default,gurobi will use theconcurrent optimizer to solve LP models, thebarrier algorithm to solve QP models and QCP models with convexconstraints, and the branch-and-cut algorithm to solve mixed integermodels. The solution is returned as alist variable. We will discussthe details of how optimization results are represented when we discussthegurobi function.

Here is a simple example of a likely sequence of commands in theR API:

model<-gurobi_read('examples/data/stein9.mps')result<-gurobi(model)

Multiple Solutions and Multiple Objectives#

By default, the Gurobi Optimizer assumes that your goal is to find oneproven optimal solution to a model with a single objective function.Gurobi provides features that allow you to relax either of theseassumptions. You should refer to the section onSolution Pools for information on how torequest more than one solution, or the section onMultiple Objectives for information onhow to specify multiple objective functions and control the trade-offbetween them.These two features are also addressed in the examplespoolsearch.Randmultiobj.R, respectively.

Infeasible Models#

You have a few options if a model is found to be infeasible. You can tryto diagnose the cause of the infeasibility, attempt to repair theinfeasibility, or both. To obtain information that can be useful fordiagnosing the cause of an infeasibility, callgurobi_iis tocompute an Irreducible Inconsistent Subsystem (IIS). This method can beused for both continuous and MIP models, but you should be aware thatthe MIP version can be quite expensive. We will discuss the details ofhow IIS results are represented in thegurobi_iis functiondocumentation.

To attempt to repair an infeasibility, callgurobi_feasrelaxto compute a feasibility relaxation for the model. This relaxationallows you to find a solution that minimizes the magnitude of theconstraint violation.You will find more information about this feature in sectionRelaxing for Feasibility.

Managing Parameters#

The Gurobi Optimizer provides a set of parameters that allow you tocontrol many of the details of the optimization process. Factors likefeasibility and optimality tolerances, choices of algorithms, strategiesfor exploring the MIP search tree, etc., can be controlled by modifyingGurobi parameters before beginning the optimization.

Each Gurobi parameter has a default value. Desired parameter changes arepassed in alist variable. The name of each named component withinthis list must be the name of a Gurobi parameter, and the associatedvalue should be the desired value of that parameter. You can find acomplete list of the available Gurobi parameters in thereference manual. We will provide additionaldetails on changing parameter settings in theparams argument section.

Refer toparams.R for an example.

Monitoring Progress#

Progress of the optimization can be monitored through Gurobi logging. Bydefault, Gurobi will send output to the screen. A few simple controlsare available for modifying the default logging behavior. If you wouldlike to direct output to a file as well as to the screen, set theLogFile parameter to the name of your desiredlog file. The frequency of logging output can be controlled with theDisplayInterval parameter, and logging can be turned offentirely with theOutputFlag parameter. A detaileddescription of the Gurobi log file can be found in theLogging section of the reference manual.

Error Handling#

If unsuccessful, the methods of the Gurobi R interface will display anerror code and an error message. A list of possible error codes can befound in theError Code table in the referencemanual.

Environments and license parameters#

By default, the various Gurobi functions will look for a valid licensefile and create a local Gurobi environment. This environment exists foras long as the corresponding R API function is running, and is releasedupon completion.

Another option is to provide licensing parameters through an optionalparams argument (also through alist). This argument allows youto solve the given problem on a Gurobi Compute Server, on Gurobi InstantCloud, or using a Gurobi Cluster Manager. We will discuss this topicfurther in theparams argument section.

Gurobi will check the current working directory for a file namedgurobi.env, and it will attempt to read parameter settings from thisfile if it exists. The file should be inPRM format(briefly, each line should contain a parameter name, followed by thedesired value for that parameter).