Models can be built in a number of ways. You can populate the appropriate named components of the model list using standard R routines. You can also read a model from a file, using gurobi_read. A few API functions ( gurobi_feasrelax and gurobi_relax) also return models.
Note that all matrix named components within the model variable can be dense or sparse. Sparse matrices should be built using either sparseMatrix from the Matrix package, or simple_triplet_matrix from the slam package.
The following is an enumeration of all of the named components of the model argument that Gurobi will take into account when optimizing the model:
Commonly used named components
Quadratic objective and constraint named components
The Qc matrix must be a square matrix whose row and column counts are equal to the number of columns of A. It is stored in model$quadcon[[i]]$Qc.
The optional q vector defines the linear terms in the constraint. It can be a dense vector specifying a value for each column of A or a sparse vector (should be built using sparseVector from the Matrix package). It is stored in model$quadcon[[i]]$q.
The scalar beta is stored in model$quadcon[[i]]$rhs. It defines the right-hand side value for the constraint.
The optional sense string defines the sense of the quadratic constraint. Allowed values are <, = or >. If not present, the default sense is <. It is stored in model$quadcon[[i]]$sense.
The optional name string defines the name of the quadratic constraint. It is stored in model$quadcon[[i]]$name.
SOS constraint named components
Multi-objective named components
Note that when multiple objectives are present, the result$objval named component that is returned in the result of an optimization call will be a vector of the same length as model$multiobj.
A multi-objective model can't have other objectives. Thus, combining model$multiobj with any of model$obj, model$objcon, model$pwlobj, or model$Q is an error.
Computing an IIS
When computing an Irreducible Inconsistent Subsystem (IIS) for an infeasible model, additional model attributes for variable bounds, linear constraints, quadratic constraints and general constraints may be set in order to indicate whether a corresponing entity should explicitly included or excluded from the IIS:
Possible values for all five attribute of listsfrom above are: to let the
algorithm decide,
to exclude the corresponding entity from the IIS, and
to always include the corresponding entity in the IIS.
Note that setting this attribute to 0 may make the resulting subsystem feasible (or consistent), which would then make it impossible to construct an IIS. Trying anyway will result in a GRB_ERROR_IIS_NOT_INFEASIBLE error. Similarly, setting this attribute to 1 may result in an IIS that is not irreducible. More precisely, the system would only be irreducible with respect to the model elements that have force values of -1 or 0.
General constraint named components
The list of lists described below are used to add general constraints to a model.
Mathematical programming has traditionally defined a set of fundamental constraint types: variable bound constraints, linear constraints, quadratic constraints, integrality constraints, and SOS constraints. These are typically treated directly by the underlying solver (although not always), and are fundamental to the overall algorithm.
Gurobi accepts a number of additional constraint types, which we collectively refer to as general (function) constraints. These are typically not treated directly by the solver. Rather, they are transformed by presolve into constraints (and variables) chosen from among the fundamental types listed above. In some cases, the resulting constraint or constraints are mathematically equivalent to the original; in others, they are approximations. If such constraints appear in your model, but if you prefer to reformulate them yourself using fundamental constraint types instead, you can certainly do so. However, note that Gurobi can sometimes exploit information contained in the other constraints in the model to build a more efficient formulation than what you might create.
The additional constraint types that fall under this general constraint umbrella are:
Please refer to General Constraints section in the reference manual for additional details on general constraints.
Each entry may have the following named components:
Each entry may have the following named components:
Each entry may have the following named components:
Each entry may have the following named components:
Each entry may have the following named components:
Each entry may have the following named components:
Each entry may have the following named components:
Each entry may have the following named components:
Each entry may have the following named components:
Each entry may have the following named components:
Each entry may have the following named components:
Advanced named components
If any of the mandatory components listed above are missing, the gurobi() function will return an error.
Below is an example that demonstrates the construction of a simple
optimization model:
model <- list()
model$A <- matrix(c(1,2,3,1,1,0), nrow=2, byrow=T)
model$obj <- c(1,1,1)
model$modelsense <- 'max'
model$rhs <- c(4,1)
model$sense <- c('<', '>')
You can also build A as a sparse matrix, using
either sparseMatrix or simple_triplet_matrix:
model$A <- spMatrix(2, 3, c(1, 1, 1, 2, 2), c(1, 2, 3, 1, 2), c(1, 2, 3, 1, 1))
model$A <- simple_triplet_matrix(c(1, 1, 1, 2, 2), c(1, 2, 3, 1, 2), c(1, 2, 3, 1, 1))
Note that the Gurobi R interface allows you to specify a scalar value for most of the array-valued components. The specified value will be expanded to an array of the appropriate size, with each component of the array equal to the scalar (e.g., model$obj <- 1 would be equivalent to model$obj <- c(1,1,1) in the example).