Models can be built in a number of ways. You can populate the appropriate fields of the model struct using standard MATLAB 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 vector fields within the model variable must be dense vectors except for the linear part of the quadratic constraints and INDICATOR general constraints, all matrix fields must be sparse matrices, and all strings, names, etc. must be char arrays.
The following is an enumeration of all of the fields of the model argument that Gurobi will take into account when optimizing the model:
Commonly used fields
Quadratic objective and constraint fields
The Qc matrix must be a square matrix whose row and column counts are equal to the number of columns of A. There are two options to store the matrix: (i) in model.quadcon(i).Qc as a sparse matrix; (ii) through three dense vectors model.quadcon(i).Qrow, model.quadcon(i).Qcol, and model.quadcon(i).Qval specifying the matrix in triple format, with row indices, column indices, and values, respectively.
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 (sparse n-by-1 matrix). 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 fields
Multi-objective fields
Note that when multiple objectives are present, the result.objval field 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 arraysfrom 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 fields
The struct arrays 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 fields:
Each entry may have the following fields:
Each entry may have the following fields:
Each entry may have the following fields:
Each entry may have the following fields:
Each entry may have the following fields:
Each entry may have the following fields:
Each entry may have the following fields:
Each entry may have the following fields:
Each entry may have the following fields:
Each entry may have the following fields:
Advanced fields
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.A = sparse([1 2 3; 1 1 0]);
model.obj = [1 1 1];
model.modelsense = 'max';
model.rhs = [4; 1];
model.sense = '<>'