Model Creation and Modification#

Use the functions in this section to create models, populate or modify them with variables and constraints, and finally free them again.

int GRBloadmodel(GRBenv *env, GRBmodel **modelP, const char *Pname, int numvars, int numconstrs, int objsense, double objcon, double *obj, char *sense, double *rhs, int *vbeg, int *vlen, int *vind, double *vval, double *lb, double *ub, char *vtype, const char **varnames, const char **constrnames)#

Create a new optimization model, using the provided arguments to initialize the model data (objective function, variable bounds, constraint matrix, etc.). The model is then ready for optimization, or for modification (e.g., addition of variables or constraints, changes to variable types or bounds, etc.).

If your constraint matrix may contain more than 2 billion non-zero values, you should consider using the GRBXloadmodel variant of this routine.

Return value:

A non-zero return value indicates that a problem occurred while creating the model. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • env – The environment in which the new model should be created. Note that the new model gets a copy of this environment, so subsequent modifications to the original environment (e.g., parameter changes) won’t affect the new model. Use GRBgetenv to modify the environment associated with a model.

  • modelP – The location in which the pointer to the newly created model should be placed.

  • Pname – The name of the model.

  • numvars – The number of variables in the model.

  • numconstrs – The number of constraints in the model.

  • objsense – The sense of the objective function. Allowed values are 1 (minimization) or -1 (maximization).

  • objcon – Constant objective offset.

  • obj – Objective coefficients for the new variables. This argument can be NULL, in which case the objective coefficients are set to 0.0.

  • sense – The senses of the new constraints. Options are '=' (equal), '<' (less-than-or-equal), or '>' (greater-than-or-equal). You can also use constants GRB_EQUAL, GRB_LESS_EQUAL, or GRB_GREATER_EQUAL.

  • rhs – Right-hand side values for the new constraints. This argument can be NULL if you are not adding any constraint.

  • vbeg – Constraint matrix non-zero values are passed into this routine in Compressed Sparse Column (CSC) format. Each column in the constraint matrix is represented as a list of index-value pairs, where each index entry provides the constraint index for a non-zero coefficient, and each value entry provides the corresponding non-zero value. Each variable in the model has a vbeg and vlen value, indicating the start position of the non-zeros for that variable in the vind and vval arrays, and the number of non-zero values for that variable, respectively. Thus, for example, if vbeg[2] = 10 and vlen[2] = 2, that would indicate that variable 2 has two non-zero values associated with it. Their constraint indices can be found in vind[10] and vind[11], and the numerical values for those non-zeros can be found in vval[10] and vval[11]. Note that the columns of the matrix must be ordered from first to last, implying that the values in vbeg must be non-decreasing.

  • vlen – Number of constraint matrix non-zero values associated with each variable. See the description of the vbeg argument for more information.

  • vind – Constraint indices associated with non-zero values. See the description of the vbeg argument for more information.

  • vval – Numerical values associated with constraint matrix non-zeros. See the description of the vbeg argument for more information.

  • lb – Lower bounds for the new variables. This argument can be NULL, in which case all variables get lower bounds of 0.0.

  • ub – Upper bounds for the new variables. This argument can be NULL, in which case all variables get infinite upper bounds.

  • vtype – Types for the variables. Options are GRB_CONTINUOUS, GRB_BINARY, GRB_INTEGER, GRB_SEMICONT, or GRB_SEMIINT. This argument can be NULL, in which case all variables are assumed to be continuous.

  • varnames – Names for the new variables. This argument can be NULL, in which case all variables are given default names.

  • constrnames – Names for the new constraints. This argument can be NULL, in which case all constraints are given default names.

Important

We recommend that you build a model one constraint or one variable at a time, using GRBaddconstr or GRBaddvar, rather than using this routine to load the entire constraint matrix at once. It is much simpler, less error prone, and it introduces no significant overhead.

Example:
/* maximize    x +   y + 2 z
   subject to  x + 2 y + 3 z <= 4
               x +   y       >= 1
   x, y, z binary */

int    vars    = 3;
int    constrs = 2;
int    vbeg[]  = {0, 2, 4};
int    vlen[]  = {2, 2, 1};
int    vind[]  = {0, 1, 0, 1, 0};
double vval[]  = {1.0, 1.0, 2.0, 1.0, 3.0};
double obj[]   = {1.0, 1.0, 2.0};
char   sense[] = {GRB_LESS_EQUAL, GRB_GREATER_EQUAL};
double rhs[]   = {4.0, 1.0};
char   vtype[] = {GRB_BINARY, GRB_BINARY, GRB_BINARY};

error = GRBloadmodel(env, &model, "example", vars, constrs, -1, 0.0,
                     obj, sense, rhs, vbeg, vlen, vind, vval,
                     NULL, NULL, vtype, NULL, NULL);
int GRBnewmodel(GRBenv *env, GRBmodel **modelP, const char *Pname, int numvars, double *obj, double *lb, double *ub, char *vtype, const char **varnames)#

Create a new optimization model. This routine allows you to specify an initial set of variables (with objective coefficients, bounds, types, and names), but the initial model will have no constraints. Constraints can be added later with GRBaddconstr or GRBaddconstrs.

Return value:

A non-zero return value indicates that a problem occurred while creating the new model. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • env – The environment in which the new model should be created. Note that the new model will get a copy of this environment, so subsequent modifications to the original environment (e.g., parameter changes) won’t affect the new model. Use GRBgetenv to modify the environment associated with a model.

  • modelP – The location in which the pointer to the new model should be placed.

  • Pname – The name of the model.

  • numvars – The number of variables in the model.

  • obj – Objective coefficients for the new variables. This argument can be NULL, in which case the objective coefficients are set to 0.0.

  • lb – Lower bounds for the new variables. This argument can be NULL, in which case all variables get lower bounds of 0.0.

  • ub – Upper bounds for the new variables. This argument can be NULL, in which case all variables get infinite upper bounds.

  • vtype – Types for the variables. Options are GRB_CONTINUOUS, GRB_BINARY, GRB_INTEGER, GRB_SEMICONT, or GRB_SEMIINT. This argument can be NULL, in which case all variables are assumed to be continuous.

  • varnames – Names for the new variables. This argument can be NULL, in which case all variables are given default names.

Example:
double obj[] = {1.0, 1.0};
char *names[] = {"var1", "var2"};
error = GRBnewmodel(env, &model, "New", 2, obj, NULL, NULL, NULL, names);
GRBmodel *GRBcopymodel(GRBmodel *model)#

Create a copy of an existing model.

Note that pending updates will not be applied to the model, so you should call GRBupdatemodel before copying if you would like those to be included in the copy.

Return value:

A copy of the input model. A NULL return value indicates that a problem was encountered.

Arguments:
  • model – The model to copy.

Example:
GRBupdatemodel(orig); /* if you have unstaged changes in orig */
GRBmodel *copy = GRBcopymodel(orig);
int GRBcopymodeltoenv(GRBmodel *model, GRBenv *targetenv, GRBmodel **resultP)#

Copy an existing model to a different environment. Multiple threads can not work simultaneously within the same environment. Copies of models must therefore reside in different environments for multiple threads to operate on them simultaneously.

Note that this method itself is not thread safe, so you should either call it from the main thread or protect access to it with a lock.

Note that pending updates will not be applied to the model, so you should call GRBupdatemodel before copying if you would like those to be included in the copy.

For Compute Server users, note that you can copy a model from a client to a Compute Server environment, but it is not possible to copy models from a Compute Server environment to another (client or Compute Server) environment.

Return value:

A non-zero return value indicates that a problem occurred while copying the model. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to copy.

  • targetenv – The environment to copy the model into.

  • resultP – The resulting model copy.

Example:
error = GRBcopymodeltoenv(orig, env2, &copy);
int GRBaddconstr(GRBmodel *model, int numnz, int *cind, double *cval, char sense, double rhs, const char *constrname)#

Add a new linear constraint to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

Return value:

A non-zero return value indicates that a problem occurred while adding the constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new constraint should be added.

  • numnz – The number of non-zero coefficients in the new constraint.

  • cind – Variable indices for non-zero values in the new constraint.

  • cval – Numerical values for non-zero values in the new constraint.

  • sense – Sense for the new constraint. Options are GRB_LESS_EQUAL, GRB_EQUAL, or GRB_GREATER_EQUAL.

  • rhs – Right-hand side value for the new constraint.

  • constrname – Name for the new constraint. This argument can be NULL, in which case the constraint is given a default name.

Example:
int    ind[] = {1, 3, 4};
double val[] = {1.0, 2.0, 1.0};
/* x1 + 2 x3 + x4 = 1 */
error = GRBaddconstr(model, 3, ind, val, GRB_EQUAL, 1.0, "New");
int GRBaddconstrs(GRBmodel *model, int numconstrs, int numnz, int *cbeg, int *cind, double *cval, char *sense, double *rhs, const char **constrnames)#

Add new linear constraints to a model.

Note that, due to our lazy update approach, the new constraints won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

We recommend that you build your model one constraint at a time (using GRBaddconstr), since it introduces no significant overhead and we find that it produces simpler code. Feel free to use this routine if you disagree, though.

If your constraint matrix may contain more than 2 billion non-zero values, you should consider using the GRBXaddconstrs variant of this routine.

Return value:

A non-zero return value indicates that a problem occurred while adding the constraints. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new constraints should be added.

  • numconstrs – The number of new constraints to add.

  • numnz – The total number of non-zero coefficients in the new constraints.

  • cbeg – Constraint matrix non-zero values are passed into this routine in Compressed Sparse Row (CSR) format by this routine. Each constraint in the constraint matrix is represented as a list of index-value pairs, where each index entry provides the variable index for a non-zero coefficient, and each value entry provides the corresponding non-zero value. Each new constraint has an associated cbeg value, indicating the start position of the non-zeros for that constraint in the cind and cval arrays. This routine requires that the non-zeros for constraint i immediately follow those for constraint i-1 in cind and cval. Thus, cbeg[i] indicates both the index of the first non-zero in constraint i and the end of the non-zeros for constraint i-1. To give an example of how this representation is used, consider a case where cbeg[2] = 10 and cbeg[3] = 12. This would indicate that constraint 2 has two non-zero values associated with it. Their variable indices can be found in cind[10] and cind[11], and the numerical values for those non-zeros can be found in cval[10] and cval[11].

  • cind – Variable indices associated with non-zero values. See the description of the cbeg argument for more information.

  • cval – Numerical values associated with constraint matrix non-zeros. See the description of the cbeg argument for more information.

  • sense – Sense for the new constraints. Options are GRB_LESS_EQUAL, GRB_EQUAL, or GRB_GREATER_EQUAL.

  • rhs – Right-hand side values for the new constraints. This argument can be NULL, in which case the right-hand side values are set to 0.0.

  • constrnames – Names for the new constraints. This argument can be NULL, in which case all constraints are given default names.

int GRBaddgenconstrMax(GRBmodel *model, const char *name, int resvar, int nvars, const int *vars, double constant)#

Add a new general constraint of type GRB_GENCONSTR_MAX to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A MAX constraint \(r = \max\{x_1,\ldots,x_n,c\}\) states that the resultant variable \(r\) should be equal to the maximum of the operand variables \(x_1,\ldots,x_n\) and the constant \(c\).

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • resvar – The index of the resultant variable \(r\) whose value will be equal to the max of the other variables.

  • nvars – The number \(n\) of operand variables over which the max will be taken.

  • vars – An array containing the indices of the operand variables \(x_j\) over which the max will be taken.

  • constant – An additional operand that allows you to include a constant \(c\) among the arguments of the max operation.

Example:
/* x5 = max(x1, x3, x4, 2.0) */
int ind[] = {1, 3, 4};
error = GRBaddgenconstrMax(model, "maxconstr", 5,
                           3, ind, 2.0);
int GRBaddgenconstrMin(GRBmodel *model, const char *name, int resvar, int nvars, const int *vars, double constant)#

Add a new general constraint of type GRB_GENCONSTR_MIN to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A MIN constraint \(r = \min\{x_1,\ldots,x_n,c\}\) states that the resultant variable \(r\) should be equal to the minimum of the operand variables \(x_1,\ldots,x_n\) and the constant \(c\).

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • resvar – The index of the resultant variable \(r\) whose value will be equal to the min of the other variables.

  • nvars – The number \(n\) of operand variables over which the min will be taken.

  • vars – An array containing the indices of the operand variables \(x_j\) over which the min will be taken.

  • constant – An additional operand that allows you to include a constant \(c\) among the arguments of the min operation.

Example:
/* x5 = min(x1, x3, x4, 2.0) */
int ind[] = {1, 3, 4};
error = GRBaddgenconstrMin(model, "minconstr", 5,
                           3, ind, 2.0);
int GRBaddgenconstrAbs(GRBmodel *model, const char *name, int resvar, int argvar)#

Add a new general constraint of type GRB_GENCONSTR_ABS to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

An ABS constraint \(r = \mbox{abs}\{x\}\) states that the resultant variable \(r\) should be equal to the absolute value of the argument variable \(x\).

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • resvar – The index of the resultant variable \(r\) whose value will be to equal the absolute value of the argument variable.

  • argvar – The index of the argument variable \(x\) for which the absolute value will be taken.

Example:
/* x5 = abs(x1) */
error = GRBaddgenconstrAbs(model, "absconstr", 5, 1);
int GRBaddgenconstrAnd(GRBmodel *model, const char *name, int resvar, int nvars, const int *vars)#

Add a new general constraint of type GRB_GENCONSTR_AND to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

An AND constraint \(r = \mbox{and}\{x_1,\ldots,x_n\}\) states that the binary resultant variable \(r\) should be \(1\) if and only if all of the operand variables \(x_1,\ldots,x_n\) are equal to \(1\). If any of the operand variables is \(0\), then the resultant should be \(0\) as well.

Note that all variables participating in such a constraint will be forced to be binary, independent of how they were created.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • resvar – The index of the binary resultant variable \(r\) whose value will be equal to the AND concatenation of the other variables.

  • nvars – The number \(n\) of binary operand variables over which the AND will be taken.

  • vars – An array containing the indices of the binary operand variables \(x_j\) over which the AND concatenation will be taken.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Example:
/* x5 = and(x1, x3, x4) */
int ind[] = {1, 3, 4};
error = GRBaddgenconstrAnd(model, "andconstr", 5, 3, ind);
int GRBaddgenconstrOr(GRBmodel *model, const char *name, int resvar, int nvars, const int *vars)#

Add a new general constraint of type GRB_GENCONSTR_OR to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

An OR constraint \(r = \mbox{or}\{x_1,\ldots,x_n\}\) states that the binary resultant variable \(r\) should be \(1\) if and only if any of the operand variables \(x_1,\ldots,x_n\) is equal to \(1\). If all operand variables are \(0\), then the resultant should be \(0\) as well.

Note that all variables participating in such a constraint will be forced to be binary, independent of how they were created.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • resvar – The index of the binary resultant variable \(r\) whose value will be equal to the OR concatenation of the other variables.

  • nvars – The number \(n\) of binary operand variables over which the OR will be taken.

  • vars – An array containing the indices of the binary operand variables \(x_j\) over which the OR concatenation will be taken.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Example:
/* x5 = or(x1, x3, x4) */
int ind[] = {1, 3, 4};
error = GRBaddgenconstrOr(model, "orconstr", 5, 3, ind);
int GRBaddgenconstrNorm(GRBmodel *model, const char *name, int resvar, int nvars, const int *vars, double which)#

Add a new general constraint of type GRB_GENCONSTR_NORM to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A NORM constraint \(r = \mbox{norm}\{x_1,\ldots,x_n\}\) states that the resultant variable \(r\) should be equal to the vector norm of the argument vector \(x_1,\ldots,x_n\).

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • resvar – The index of the resultant variable \(r\) whose value will be equal to the NORM of the other variables.

  • nvars – The number \(n\) of operand variables over which the NORM will be taken.

  • vars – An array containing the indices of the operand variables \(x_j\) over which the NORM will be taken. Note that this array may not contain duplicates.

  • which – Which norm to use. Options are 0, 1, 2, and GRB_INFINITY.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Example:
/* x5 = 2-norm(x1, x3, x4) */
int ind[] = {1, 3, 4};
error = GRBaddgenconstrNorm(model, "orconstr", 5, 3, ind, 2.0);
int GRBaddgenconstrNL(GRBmodel *model, const char *name, int resvar, int nnodes, const int *opcode, const double *data, const int *parent)#

Add a new general constraint of type GRB_GENCONSTR_NL to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A NL constraint \(r = f(x)\) states that the resultant variable \(r\) should be equal to the function value \(f(x)\) of the given function \(f\), provided as an expression tree as described in Nonlinear Constraints.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • resvar – The index of the resultant variable \(r\) whose value will be equal to the function value of the given function \(f\).

  • nnodes – The number of nodes in the expression tree, that is, the length of the input arrays opcode, data and parent.

  • opcode – An array containing the operation codes for the nodes.

  • data – An array containing the auxiliary data for each node.

  • parent – An array providing the parent index of the nodes.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Example:
/* Add nonlinear constraint x0 = sin(2.5 * x1) + x2 to the model */

int     opcode[6] = {GRB_OPCODE_PLUS, GRB_OPCODE_SIN, GRB_OPCODE_MULTIPLY,
                     GRB_OPCODE_CONSTANT, GRB_OPCODE_VARIABLE, GRB_OPCODE_VARIABLE};
double  data[6]   = {-1.0, -1.0, -1.0, 2.5, 1.0, 2.0};
int     parent[6] = {-1, 0, 1, 2, 2, 0};

error = GRBaddgenconstrNL(model, "nlconstr", 0, 6, opcode, data, parent);
int GRBaddgenconstrIndicator(GRBmodel *model, const char *name, int binvar, int binval, int nvars, const int *ind, const double *val, char sense, double rhs)#

Add a new general constraint of type GRB_GENCONSTR_INDICATOR to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

An INDICATOR constraint \(z = f \rightarrow a^Tx \leq b\) states that if the binary indicator variable \(z\) is equal to \(f\), where \(f \in \{0,1\}\), then the linear constraint \(a^Tx \leq b\) should hold. On the other hand, if \(z = 1-f\), the linear constraint may be violated. The sense of the linear constraint can also be specified to be “\(=\)” or “\(\geq\)”.

Note that the indicator variable \(z\) of a constraint will be forced to be binary, independent of how it was created.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • binvar – The index of the binary indicator variable \(z\).

  • binval – The value \(f\) for the binary indicator variable that would force the linear constraint to be satisfied (\(0\) or \(1\)).

  • nvars – The number \(n\) of non-zero coefficients in the linear constraint triggered by the indicator.

  • ind – Indices for the variables \(x_j\) with non-zero values in the linear constraint.

  • val – Numerical values for non-zero values \(a_j\) in the linear constraint.

  • sense – Sense for the linear constraint. Options are GRB_LESS_EQUAL, GRB_EQUAL, or GRB_GREATER_EQUAL.

  • rhs – Right-hand side value for the linear constraint.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Example:
/* x7 = 1 -> x1 + 2 x3 + x4 = 1 */
int    ind[] = {1, 3, 4};
double val[] = {1.0, 2.0, 1.0};
error = GRBaddgenconstrIndicator(model, NULL, 7, 1,
                                 3, ind, val, GRB_EQUAL, 1.0);
int GRBaddgenconstrPWL(GRBmodel *model, const char *name, int xvar, int yvar, int npts, double *xpts, double *ypts)#

Add a new general constraint of type GRB_GENCONSTR_PWL to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A piecewise-linear (PWL) constraint states that the relationship \(y = f(x)\) must hold between variables \(x\) and \(y\), where \(f\) is a piecewise-linear function. The breakpoints for \(f\) are provided as arguments. Refer to the description of piecewise-linear objectives for details of how piecewise-linear functions are defined.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • xvar – The index of variable \(x\).

  • yvar – The index of variable \(y\).

  • npts – The number of points that define the piecewise-linear function.

  • xpts – The \(x\) values for the points that define the piecewise-linear function. Must be in non-decreasing order.

  • ypts – The \(y\) values for the points that define the piecewise-linear function.

Example:
double xpts[] = {1, 3, 5};
double ypts[] = {1, 2, 4};
error = GRBaddgenconstr(model, "pwl", xvar, yvar, 3, x, y);
int GRBaddgenconstrPoly(GRBmodel *model, const char *name, int xvar, int yvar, int plen, double *p, const char *options)#

Add a new general constraint of type GRB_GENCONSTR_POLY to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A polynomial function constraint states that the relationship \(y = p_0 x^d + p_1 x^{d-1} + ... + p_{d-1} x + p_{d}\) should hold between variables \(x\) and \(y\).

A piecewise-linear approximation of the function is added to the model. The details of the approximation are controlled using the following four attributes (or using the parameters with the same names): FuncPieces, FuncPieceError, FuncPieceLength, and FuncPieceRatio. Alternatively, the function can be treated as a nonlinear constraint by setting the attribute FuncNonlinear. For details, consult the General Constraint discussion.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • xvar – The index of variable \(x\).

  • yvar – The index of variable \(y\).

  • plen – The length of coefficient array p. If \(x^d\) is the highest power term, then plen should be \(d+1\).

  • p – The coefficients for the polynomial function (starting with the coefficient for the highest power).

  • options – A string that can be used to set the attributes that control the piecewise-linear approximation of this function constraint. To assign a value to an attribute, follow the attribute name with an equal sign and the desired value (with no spaces). Assignments for different attributes should be separated by spaces (e.g. “FuncPieces=-1 FuncPieceError=0.001”).

Example:
/* y = 3 x^4 + 7 x + 3 = 3 x^4 + 0 x^3 + 0 x^2 + 7 x + 3 */
int plen = 5;
double p[] = {3, 0, 0, 7, 3};
error = GRBaddgenconstrPoly(model, "poly", xvar, yvar, 5, p, "");
int GRBaddgenconstrExp(GRBmodel *model, const char *name, int xvar, int yvar, const char *options)#

Add a new general constraint of type GRB_GENCONSTR_EXP to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A natural exponential function constraint states that the relationship \(y = \exp(x)\) should hold for variables \(x\) and \(y\).

A piecewise-linear approximation of the function is added to the model. The details of the approximation are controlled using the following four attributes (or using the parameters with the same names): FuncPieces, FuncPieceError, FuncPieceLength, and FuncPieceRatio. Alternatively, the function can be treated as a nonlinear constraint by setting the attribute FuncNonlinear. For details, consult the General Constraint discussion.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • xvar – The index of variable \(x\).

  • yvar – The index of variable \(y\).

  • options – A string that can be used to set the attributes that control the piecewise-linear approximation of this function constraint. To assign a value to an attribute, follow the attribute name with an equal sign and the desired value (with no spaces). Assignments for different attributes should be separated by spaces (e.g. “FuncPieces=-1 FuncPieceError=0.001”).

Example:
/* y = exp(x) */
error = GRBaddgenconstrExp(model, "exp", xvar, yvar, "");
int GRBaddgenconstrExpA(GRBmodel *model, const char *name, int xvar, int yvar, double a, const char *options)#

Add a new general constraint of type GRB_GENCONSTR_EXPA to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

An exponential function constraint states that the relationship \(y = a^x\) should hold for variables \(x\) and \(y\), where \(a > 0\) is the (constant) base.

A piecewise-linear approximation of the function is added to the model. The details of the approximation are controlled using the following four attributes (or using the parameters with the same names): FuncPieces, FuncPieceError, FuncPieceLength, and FuncPieceRatio. Alternatively, the function can be treated as a nonlinear constraint by setting the attribute FuncNonlinear. For details, consult the General Constraint discussion.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • xvar – The index of variable \(x\).

  • yvar – The index of variable \(y\).

  • a – The base of the function, \(a > 0\).

  • options – A string that can be used to set the attributes that control the piecewise-linear approximation of this function constraint. To assign a value to an attribute, follow the attribute name with an equal sign and the desired value (with no spaces). Assignments for different attributes should be separated by spaces (e.g. “FuncPieces=-1 FuncPieceError=0.001”).

Example:
/* y = 3^x */
error = GRBaddgenconstrExpA(model, "expa", xvar, yvar, 3.0, "");
int GRBaddgenconstrLog(GRBmodel *model, const char *name, int xvar, int yvar, const char *options)#

Add a new general constraint of type GRB_GENCONSTR_LOG to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A natural logarithmic function constraint states that the relationship \(y = log(x)\) should hold for variables \(x\) and \(y\).

A piecewise-linear approximation of the function is added to the model. The details of the approximation are controlled using the following four attributes (or using the parameters with the same names): FuncPieces, FuncPieceError, FuncPieceLength, and FuncPieceRatio. Alternatively, the function can be treated as a nonlinear constraint by setting the attribute FuncNonlinear. For details, consult the General Constraint discussion.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • xvar – The index of variable \(x\).

  • yvar – The index of variable \(y\).

  • options – A string that can be used to set the attributes that control the piecewise-linear approximation of this function constraint. To assign a value to an attribute, follow the attribute name with an equal sign and the desired value (with no spaces). Assignments for different attributes should be separated by spaces (e.g. “FuncPieces=-1 FuncPieceError=0.001”).

Example:
/* y = log(x) */
error = GRBaddgenconstrLog(model, "log", xvar, yvar, "FuncPieces=-1 FuncPieceError=0.001");
int GRBaddgenconstrLogA(GRBmodel *model, const char *name, int xvar, int yvar, double a, const char *options)#

Add a new general constraint of type GRB_GENCONSTR_LOGA to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A logarithmic function constraint states that the relationship \(y = log_a(x)\) should hold for variables \(x\) and \(y\), where \(a > 0\) is the (constant) base.

A piecewise-linear approximation of the function is added to the model. The details of the approximation are controlled using the following four attributes (or using the parameters with the same names): FuncPieces, FuncPieceError, FuncPieceLength, and FuncPieceRatio. Alternatively, the function can be treated as a nonlinear constraint by setting the attribute FuncNonlinear. For details, consult the General Constraint discussion.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • xvar – The index of variable \(x\).

  • yvar – The index of variable \(y\).

  • a – The base of the function, \(a > 0\).

  • options – A string that can be used to set the attributes that control the piecewise-linear approximation of this function constraint. To assign a value to an attribute, follow the attribute name with an equal sign and the desired value (with no spaces). Assignments for different attributes should be separated by spaces (e.g. “FuncPieces=-1 FuncPieceError=0.001”).

Example:
/* y = log_10(x) */
error = GRBaddgenconstrLogA(model, "loga", xvar, yvar, 10.0, "");
int GRBaddgenconstrLogistic(GRBmodel *model, const char *name, int xvar, int yvar, const char *options)#

Add a new general constraint of type GRB_GENCONSTR_LOGISTIC to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A logistic function constraint states that the relationship \(y = \frac{1}{1 + e^{-x}}\) should hold for variables \(x\) and \(y\).

A piecewise-linear approximation of the function is added to the model. The details of the approximation are controlled using the following four attributes (or using the parameters with the same names): FuncPieces, FuncPieceError, FuncPieceLength, and FuncPieceRatio. Alternatively, the function can be treated as a nonlinear constraint by setting the attribute FuncNonlinear. For details, consult the General Constraint discussion.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • xvar – The index of variable \(x\).

  • yvar – The index of variable \(y\).

  • options – A string that can be used to set the attributes that control the piecewise-linear approximation of this function constraint. To assign a value to an attribute, follow the attribute name with an equal sign and the desired value (with no spaces). Assignments for different attributes should be separated by spaces (e.g. “FuncPieces=-1 FuncPieceError=0.001”).

Example:
/* y = 1 / (1 + exp(-x)) */
error = GRBaddgenconstrLogistic(model, "logistic", xvar, yvar, "");
int GRBaddgenconstrPow(GRBmodel *model, const char *name, int xvar, int yvar, double a, const char *options)#

Add a new general constraint of type GRB_GENCONSTR_POW to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A power function constraint states that the relationship \(y = x^a\) should hold for variables \(x\) and \(y\), where \(a\) is the (constant) exponent.

If the exponent \(a\) is negative, the lower bound on \(x\) must be strictly positive. If the exponent isn’t an integer, the lower bound on \(x\) must be non-negative.

A piecewise-linear approximation of the function is added to the model. The details of the approximation are controlled using the following four attributes (or using the parameters with the same names): FuncPieces, FuncPieceError, FuncPieceLength, and FuncPieceRatio. Alternatively, the function can be treated as a nonlinear constraint by setting the attribute FuncNonlinear. For details, consult the General Constraint discussion.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • xvar – The index of variable \(x\).

  • yvar – The index of variable \(y\).

  • a – The exponent of the function.

  • options – A string that can be used to set the attributes that control the piecewise-linear approximation of this function constraint. To assign a value to an attribute, follow the attribute name with an equal sign and the desired value (with no spaces). Assignments for different attributes should be separated by spaces (e.g. “FuncPieces=-1 FuncPieceError=0.001”).

Example:
/* y = sqrt(x) */
error = GRBaddgenconstrPow(model, "pow", xvar, yvar, 0.5, "");
int GRBaddgenconstrSin(GRBmodel *model, const char *name, int xvar, int yvar, const char *options)#

Add a new general constraint of type GRB_GENCONSTR_SIN to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A sine function constraint states that the relationship \(y = sin(x)\) should hold for variables \(x\) and \(y\).

A piecewise-linear approximation of the function is added to the model. The details of the approximation are controlled using the following four attributes (or using the parameters with the same names): FuncPieces, FuncPieceError, FuncPieceLength, and FuncPieceRatio. Alternatively, the function can be treated as a nonlinear constraint by setting the attribute FuncNonlinear. For details, consult the General Constraint discussion.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • xvar – The index of variable \(x\).

  • yvar – The index of variable \(y\).

  • options – A string that can be used to set the attributes that control the piecewise-linear approximation of this function constraint. To assign a value to an attribute, follow the attribute name with an equal sign and the desired value (with no spaces). Assignments for different attributes should be separated by spaces (e.g. “FuncPieces=-1 FuncPieceError=0.001”).

Example:
/* y = sin(x) */
error = GRBaddgenconstrSin(model, "sin", xvar, yvar, "");
int GRBaddgenconstrCos(GRBmodel *model, const char *name, int xvar, int yvar, const char *options)#

Add a new general constraint of type GRB_GENCONSTR_COS to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A cosine function constraint states that the relationship \(y = cos(x)\) should hold for variables \(x\) and \(y\).

A piecewise-linear approximation of the function is added to the model. The details of the approximation are controlled using the following four attributes (or using the parameters with the same names): FuncPieces, FuncPieceError, FuncPieceLength, and FuncPieceRatio. Alternatively, the function can be treated as a nonlinear constraint by setting the attribute FuncNonlinear. For details, consult the General Constraint discussion.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • xvar – The index of variable \(x\).

  • yvar – The index of variable \(y\).

  • options – A string that can be used to set the attributes that control the piecewise-linear approximation of this function constraint. To assign a value to an attribute, follow the attribute name with an equal sign and the desired value (with no spaces). Assignments for different attributes should be separated by spaces (e.g. “FuncPieces=-1 FuncPieceError=0.001”).

Example:
/* y = cos(x) */
error = GRBaddgenconstrCos(model, "cos", xvar, yvar, "FuncPieces=-2");
int GRBaddgenconstrTan(GRBmodel *model, const char *name, int xvar, int yvar, const char *options)#

Add a new general constraint of type GRB_GENCONSTR_TAN to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A tangent function constraint states that the relationship \(y = tan(x)\) should hold for variables \(x\) and \(y\).

A piecewise-linear approximation of the function is added to the model. The details of the approximation are controlled using the following four attributes (or using the parameters with the same names): FuncPieces, FuncPieceError, FuncPieceLength, and FuncPieceRatio. Alternatively, the function can be treated as a nonlinear constraint by setting the attribute FuncNonlinear. For details, consult the General Constraint discussion.

Return value:

A non-zero return value indicates that a problem occurred while adding the general constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new general constraint should be added.

  • name – Name for the new general constraint. This argument can be NULL, in which case the constraint is given a default name.

  • xvar – The index of variable \(x\).

  • yvar – The index of variable \(y\).

  • options – A string that can be used to set the attributes that control the piecewise-linear approximation of this function constraint. To assign a value to an attribute, follow the attribute name with an equal sign and the desired value (with no spaces). Assignments for different attributes should be separated by spaces (e.g. “FuncPieces=-1 FuncPieceError=0.001”).

Example:
/* y = tan(x) */
error = GRBaddgenconstrTan(model, "tan", xvar, yvar, "");
int GRBdelgenconstrs(GRBmodel *model, int numdel, int *ind)#

Delete a list of general constraints from an existing model.

Note that, due to our lazy update approach, the general constraints won’t actually be removed until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

In addition, note that this function will return an error if you try to delete a general constraint that has been added to the model after the last call to one of these three functions above.

Return value:

A non-zero return value indicates that a problem occurred while deleting the constraints. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to modify.

  • numdel – The number of general constraints to remove.

  • ind – The indices of the general constraints to remove.

Example:
int first_four[] = {0, 1, 2, 3};
error = GRBdelgenconstrs(model, 4, first_four);
int GRBaddqconstr(GRBmodel *model, int numlnz, int *lind, double *lval, int numqnz, int *qrow, int *qcol, double *qval, char sense, double rhs, const char *constrname)#

Add a new quadratic constraint to a model.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

A quadratic constraint consists of a set of quadratic terms, a set of linear terms, a sense, and a right-hand side value: \(x^TQx + q^Tx \le b\). The quadratic terms are input through the numqnz, qrow, qcol, and qval arguments, and the linear terms are input through the numlnz, lind, and lval arguments.

Important

Gurobi can handle both convex and non-convex quadratic constraints. The differences between them can be both important and subtle. Refer to this discussion for additional information.

Return value:

A non-zero return value indicates that a problem occurred while adding the quadratic constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new constraint should be added.

  • numlnz – The number of linear terms in the new quadratic constraint.

  • lind – Variable indices associated with linear terms.

  • lval – Numerical values associated with linear terms.

  • numqlnz – The number of quadratic terms in the new quadratic constraint.

  • qrow – Row indices associated with quadratic terms. A quadratic term is represented using three values: a pair of indices (stored in qrow and qcol), and a coefficient (stored in qval). The associated arguments arrays provide the corresponding values for each quadratic term. To give an example, if you wish to input quadratic terms \(2 x_0^2 + x_0 x_1 + x_1^2\), you would call this routine with numqnz=3, qrow[] = {0, 0, 1}, qcol[] = {0, 1, 1}, and qval[] = {2.0, 1.0, 1.0}.

  • qcol – Column indices associated with quadratic terms. See the description of the qrow argument for more information.

  • qval – Numerical values associated with quadratic terms. See the description of the qrow argument for more information.

  • sense – Sense for the new quadratic constraint. Options are GRB_LESS_EQUAL, GRB_EQUAL, or GRB_GREATER_EQUAL.

  • rhs – Right-hand side value for the new quadratic constraint.

  • constrname – Name for the new quadratic constraint. This argument can be NULL, in which case the constraint is given a default name.

Example:
int    lind[] = {1, 2};
double lval[] = {2.0, 1.0};
int    qrow[] = {0, 0, 1};
int    qcol[] = {0, 1, 1};
double qval[] = {2.0, 1.0, 1.0};
/* 2 x0^2 + x0 x1 + x1^2 + 2 x1 + x2 <= 1 */
error = GRBaddqconstr(model, 2, lind, lval, 3, qrow, qcol, qval,
                      GRB_LESS_EQUAL, 1.0, "New");
int GRBaddqpterms(GRBmodel *model, int numqnz, int *qrow, int *qcol, double *qval)#

Add new quadratic objective terms into an existing model. Note that new terms are (numerically) added into existing terms, and that adding a term in row i and column j is equivalent to adding a term in row j and column i. You can add all quadratic objective terms in a single call, or you can add them incrementally in multiple calls.

Note that, due to our lazy update approach, the new quadratic terms won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

To build an objective that contains both linear and quadratic terms, use this routine to add the quadratic terms and use the Obj attribute to add the linear terms.

If you wish to change a quadratic term, you can either add the difference between the current term and the desired term using this routine, or you can call GRBdelq to delete all quadratic terms, and then rebuild your new quadratic objective from scratch.

Return value:

A non-zero return value indicates that a problem occurred while adding the quadratic terms. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new quadratic objective terms should be added.

  • numqnz – The number of new quadratic objective terms to add.

  • qrow – Row indices associated with quadratic terms. A quadratic term is represented using three values: a pair of indices (stored in qrow and qcol), and a coefficient (stored in qval). The three argument arrays provide the corresponding values for each quadratic term. To give an example, to represent \(2 x_0^2 + x_0 x_1 + x_1^2\), you would have numqnz=3, qrow[] = {0, 0, 1}, qcol[] = {0, 1, 1}, and qval[] = {2.0, 1.0, 1.0}.

  • qcol – Column indices associated with quadratic terms. See the description of the qrow argument for more information.

  • qval – Numerical values associated with quadratic terms. See the description of the qrow argument for more information.

Important

Note that building quadratic objectives requires some care, particularly if you are migrating an application from another solver. Some solvers require you to specify the entire \(Q\) matrix, while others only accept the lower triangle. In addition, some solvers include an implicit 0.5 multiplier on \(Q\), while others do not. The Gurobi interface is built around quadratic terms, rather than a \(Q\) matrix. If your quadratic objective contains a term 2 x y, you can enter it as a single term, 2 x y, or as a pair of terms, x y and y x.

Example:
int    qrow[] = {0, 0, 1};
int    qcol[] = {0, 1, 1};
double qval[] = {2.0, 1.0, 3.0};
/* minimize 2 x^2 + x*y + 3 y^2 */
error = GRBaddqpterms(model, 3, qrow, qcol, qval);
int GRBaddrangeconstr(GRBmodel *model, int numnz, int *cind, double *cval, double lower, double upper, const char *constrname)#

Add a new range constraint to a model. A range constraint states that the value of the input expression must be between the specified lower and upper bounds in any solution.

Note that, due to our lazy update approach, the new constraint won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

Return value:

A non-zero return value indicates that a problem occurred while adding the constraint. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new constraint should be added.

  • numnz – The number of non-zero coefficients in the linear expression.

  • cind – Variable indices for non-zero values in the linear expression.

  • cval – Numerical values for non-zero values in the linear expression.

  • lower – Lower bound on linear expression.

  • upper – Upper bound on linear expression.

  • constrname – Name for the new constraint. This argument can be NULL, in which case the constraint is given a default name.

Important

Note that adding a range constraint to the model adds both a new constraint and a new variable. If you are keeping a count of the variables in the model, remember to add one whenever you add a range.

Important

Note also that range constraints are stored internally as equality constraints. We use the extra variable that is added with a range constraint to capture the range information. Thus, the Sense attribute on a range constraint will always be GRB_EQUAL. In particular introducing a range constraint

\[L \leq a^T x \leq U\]

is equivalent to adding a slack variable \(s\) and the following constraints

\[\begin{split}\begin{array}{rl} a^T x - s & = L \\ 0 \leq s & \leq U - L. \end{array}\end{split}\]
Example:
int    ind[] = {1, 3, 4};
double val[] = {1.0, 2.0, 3.0};
/* 1 <= x1 + 2 x3 + 3 x4 <= 2 */
error = GRBaddrangeconstr(model, 3, ind, val, 1.0, 2.0, "NewRange");
int GRBaddrangeconstrs(GRBmodel *model, int numconstrs, int numnz, int *cbeg, int *cind, double *cval, double *lower, double *upper, const char **constrnames)#

Add new range constraints to a model. A range constraint states that the value of the input expression must be between the specified lower and upper bounds in any solution.

Note that, due to our lazy update approach, the new constraints won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

If your constraint matrix may contain more than 2 billion non-zero values, you should consider using the GRBXaddrangeconstrs variant of this routine.

Return value:

A non-zero return value indicates that a problem occurred while adding the constraints. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new constraints should be added.

  • numconstrs – The number of new constraints to add.

  • numnz – The total number of non-zero coefficients in the new constraints.

  • cbeg – Constraint matrix non-zero values are passed into this routine in Compressed Sparse Row (CSR) format by this routine. Each constraint in the constraint matrix is represented as a list of index-value pairs, where each index entry provides the variable index for a non-zero coefficient, and each value entry provides the corresponding non-zero value. Each new constraint has an associated cbeg value, indicating the start position of the non-zeros for that constraint in the cind and cval arrays. This routine requires that the non-zeros for constraint i immediately follow those for constraint i-1 in cind and cval. Thus, cbeg[i] indicates both the index of the first non-zero in constraint i and the end of the non-zeros for constraint i-1. To give an example of how this representation is used, consider a case where cbeg[2] = 10 and cbeg[3] = 12. This would indicate that constraint 2 has two non-zero values associated with it. Their variable indices can be found in cind[10] and cind[11], and the numerical values for those non-zeros can be found in cval[10] and cval[11].

  • cind – Variable indices associated with non-zero values. See the description of the cbeg argument for more information.

  • cval – Numerical values associated with constraint matrix non-zeros. See the description of the cbeg argument for more information.

  • lower – Lower bounds for the linear expressions.

  • upper – Upper bounds for the linear expressions.

  • constrnames – Names for the new constraints. This argument can be NULL, in which case all constraints are given default names.

Important

Note that adding a range constraint to the model adds both a new constraint and a new variable. If you are keeping a count of the variables in the model, remember to add one for each range constraint.

Important

Note also that range constraints are stored internally as equality constraints. We use the extra variable that is added with a range constraint to capture the range information. Thus, the Sense attribute on a range constraint will always be GRB_EQUAL.

int GRBaddsos(GRBmodel *model, int numsos, int nummembers, int *types, int *beg, int *ind, double *weight)#

Add new Special Ordered Set (SOS) constraints to a model.

Note that, due to our lazy update approach, the new SOS constraints won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

Please refer to this section for details on SOS constraints.

Return value:

A non-zero return value indicates that a problem occurred while adding the SOS constraints. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new SOSs should be added.

  • numsos – The number of new SOSs to add.

  • nummembers – The total number of SOS members in the new SOSs.

  • types – The types of the SOS sets. SOS sets can be of type GRB_SOS_TYPE1 or GRB_SOS_TYPE2.

  • beg – The members of the added SOS sets are passed into this routine in Compressed Sparse Row (CSR) format. Each SOS is represented as a list of index-value pairs, where each index entry provides the variable index for an SOS member, and each value entry provides the weight of that variable in the corresponding SOS set. Each new SOS has an associated beg value, indicating the start position of the SOS member list in the ind and weight arrays. This routine requires that the members for SOS i immediately follow those for SOS i-1 in ind and weight. Thus, beg[i] indicates both the index of the first non-zero in constraint i and the end of the non-zeros for constraint i-1. To give an example of how this representation is used, consider a case where beg[2] = 10 and beg[3] = 12. This would indicate that SOS number 2 has two members. Their variable indices can be found in ind[10] and ind[11], and the associated weights can be found in weight[10] and weight[11].

  • ind – Variable indices associated with SOS members. See the description of the beg argument for more information.

  • weight – Weights associated with SOS members. See the description of the beg argument for more information.

Example:
int    types[]  = {GRB_SOS_TYPE1, GRB_SOS_TYPE1};
int    beg[]    = {0, 2};
int    ind[]    = {1, 2, 1, 3};
double weight[] = {1, 2, 1, 2};
error = GRBaddsos(model, 2, 4, types, beg, ind, weight);
int GRBaddvar(GRBmodel *model, int numnz, int *vind, double *vval, double obj, double lb, double ub, char vtype, const char *varname)#

Add a new variable to a model.

Note that, due to our lazy update approach, the new variable won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

Return value:

A non-zero return value indicates that a problem occurred while adding the variable. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new variable should be added.

  • numnz – The number of non-zero coefficients in the new column.

  • vind – Constraint indices associated with non-zero values for the new variable.

  • vval – Numerical values associated with non-zero values for the new variable.

  • obj – Objective coefficient for the new variable.

  • lb – Lower bound for the new variable.

  • ub – Upper bound for the new variable.

  • vtype – Type for the new variable. Options are GRB_CONTINUOUS, GRB_BINARY, GRB_INTEGER, GRB_SEMICONT, or GRB_SEMIINT.

  • varname – Name for the new variable. This argument can be NULL, in which case the variable is given a default name.

Example:
int    ind[] = {1, 3, 4};
double val[] = {1.0, 1.0, 1.0};
error = GRBaddvar(model, 3, ind, val, 1.0, 0.0, GRB_INFINITY,
                  GRB_CONTINUOUS, "New");
int GRBaddvars(GRBmodel *model, int numvars, int numnz, int *vbeg, int *vind, double *vval, double *obj, double *lb, double *ub, char *vtype, const char **varnames)#

Add new variables to a model.

Note that, due to our lazy update approach, the new variables won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

If your constraint matrix may contain more than 2 billion non-zero values, you should consider using the GRBXaddvars variant of this routine.

Return value:

A non-zero return value indicates that a problem occurred while adding the variables. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new variables should be added.

  • numvars – The number of new variables to add.

  • numnz – The total number of non-zero coefficients in the new columns.

  • vbeg – Constraint matrix non-zero values are passed into this routine in Compressed Sparse Column (CSC) format. Each column in the constraint matrix is represented as a list of index-value pairs, where each index entry provides the constraint index for a non-zero coefficient, and each value entry provides the corresponding non-zero value. Each variable in the model has a vbeg, indicating the start position of the non-zeros for that variable in the vind and vval arrays. This routine requires columns to be stored contiguously, so the start position for a variable is the end position for the previous variable. To give an example, if vbeg[2] = 10 and vbeg[3] = 12, that would indicate that variable 2 has two non-zero values associated with it. Their constraint indices can be found in vind[10] and vind[11], and the numerical values for those non-zeros can be found in vval[10] and vval[11].

  • vind – Constraint indices associated with non-zero values. See the description of the vbeg argument for more information.

  • vval – Numerical values associated with constraint matrix non-zeros. See the description of the vbeg argument for more information.

  • obj – Objective coefficients for the new variables. This argument can be NULL, in which case the objective coefficients are set to 0.0.

  • lb – Lower bounds for the new variables. This argument can be NULL, in which case all variables get lower bounds of 0.0.

  • ub – Upper bounds for the new variables. This argument can be NULL, in which case all variables get infinite upper bounds.

  • vtype – Types for the variables. Options are GRB_CONTINUOUS, GRB_BINARY, GRB_INTEGER, GRB_SEMICONT, or GRB_SEMIINT. This argument can be NULL, in which case all variables are assumed to be continuous.

  • varnames – Names for the new variables. This argument can be NULL, in which case all variables are given default names.

int GRBchgcoeffs(GRBmodel *model, int numchgs, int *cind, int *vind, double *val)#

Change a set of constraint matrix coefficients. This routine can be used to set a non-zero coefficient to zero, to create a non-zero coefficient where the coefficient is currently zero, or to change an existing non-zero coefficient to a new non-zero value. If you make multiple changes to the same coefficient, the last one will be applied.

Note that, due to our lazy update approach, the changes won’t actually be integrated into the model until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

If your constraint matrix may contain more than 2 billion non-zero values, you should consider using the GRBXchgcoeffs variant of this routine.

Return value:

A non-zero return value indicates that a problem occurred while performing the modification. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to modify.

  • numchgs – The number of coefficients to modify.

  • cind – Constraint indices for the coefficients to modify.

  • vind – Variable indices for the coefficients to modify.

  • val – The new values for the coefficients. For example, if cind[0] = 1, vind[0] = 3, and val[0] = 2.0, then the coefficient in constraint 1 associated with variable 3 would be changed to 2.0.

Example:
int cind[] = {0, 1};
int vind[] = {0, 0};
double val[] = {1.0, 1.0};
error = GRBchgcoeffs(model, 2, cind, vind, val);
int GRBdelconstrs(GRBmodel *model, int numdel, int *ind)#

Delete a list of constraints from an existing model.

Note that, due to our lazy update approach, the constraints won’t actually be removed until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

Return value:

A non-zero return value indicates that a problem occurred while deleting the constraints. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to modify.

  • numdel – The number of constraints to remove.

  • ind – The indices of the constraints to remove.

Example:
int first_four[] = {0, 1, 2, 3};
error = GRBdelconstrs(model, 4, first_four);
int GRBdelq(GRBmodel *model)#

Delete all quadratic objective terms from an existing model.

Note that, due to our lazy update approach, the quadratic terms won’t actually be removed until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

Return value:

A non-zero return value indicates that a problem occurred while deleting the quadratic objective terms. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to modify.

Example:
error = GRBdelq(model);
int GRBdelqconstrs(GRBmodel *model, int numdel, int *ind)#

Delete a list of quadratic constraints from an existing model.

Note that, due to our lazy update approach, the quadratic constraints won’t actually be removed until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

In addition, note that this function will return an error if you try to delete a quadratic constraint that has been added to the model after the last call to one of these three functions above.

Return value:

A non-zero return value indicates that a problem occurred while deleting the quadratic constraints. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to modify.

  • numdel – The number of quadratic constraints to remove.

  • ind – The indices of the quadratic constraints remove.

Example:
int first_four[] = {0, 1, 2, 3};
error = GRBdelqconstrs(model, 4, first_four);
int GRBdelsos(GRBmodel *model, int numdel, int *ind)#

Delete a list of Special Ordered Set (SOS) constraints from an existing model.

Note that, due to our lazy update approach, the SOS constraints won’t actually be removed until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

In addition, note that this function will return an error if you try to delete an SOS constraint that has been added to the model after the last call to one of these three functions above.

Return value:

A non-zero return value indicates that a problem occurred while deleting the constraints. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to modify.

  • numdel – The number of SOSs to remove.

  • ind – The indices of the SOSs to remove.

Example:
int first_four[] = {0, 1, 2, 3};
error = GRBdelsos(model, 4, first_four);
int GRBdelvars(GRBmodel *model, int numdel, int *ind)#

Delete a list of variables from an existing model.

Note that, due to our lazy update approach, the variables won’t actually be removed until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

Return value:

A non-zero return value indicates that a problem occurred while deleting the variables. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to modify.

  • numdel – The number of variables to remove.

  • ind – The indices of the variables to remove.

Example:
int first_two[] = {0, 1};
error = GRBdelvars(model, 2, first_two);
int GRBsetobjectiven(GRBmodel *model, int index, int priority, double weight, double abstol, double reltol, const char *name, double constant, int lnz, int *lind, double *lval)#

Set an alternative optimization objective equal to a linear expression.

Please refer to the discussion of Multiple Objectives for information on how to specify multiple objective functions and control the trade-off between them.

Note that you can also modify an alternative objective using the ObjN variable attribute. If you wish to mix and match these two approaches, please note that this method replaces the entire existing objective, while the ObjN attribute can be used to modify individual terms.

Note that, due to our lazy update approach, the new alternative objective won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

Return value:

A non-zero return value indicates that a problem occurred while setting the alternative objective. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model in which the new alternative objective should be set.

  • index – Index for new objective. If you use an index of 0, this routine will change the primary optimization objective.

  • priority – Priority for the alternative objective. This initializes the ObjNPriority attribute for this objective.

  • weight – Weight for the alternative objective. This initializes the ObjNWeight attribute for this objective.

  • abstol – Absolute tolerance for the alternative objective. This initializes the ObjNAbsTol attribute for this objective.

  • reltol – Relative tolerance for the alternative objective. This initializes the ObjNRelTol attribute for this objective.

  • name – Name of the alternative objective. This initializes the ObjNName attribute for this objective.

  • constant – Constant part of the linear expression for the new alternative objective.

  • lnz – Number of non-zero coefficients in new alternative objective.

  • lind – Variable indices for non-zero values in new alternative objective.

  • lval – Numerical values for non-zero values in new alternative objective.

Example:
int ind[] = {0, 1, 2};
double val[] = {1.0, 1.0, 1.0};
/* Objective expression: x0 + x1 + x2 */
error = GRBsetobjectiven(model, 0, 1, 0.0, 0.0, 0.0, "primary",
                         0.0, 3, ind, val);
int GRBsetpwlobj(GRBmodel *model, int var, int npoints, double *x, double *y)#

Set a piecewise-linear objective function for a variable.

The arguments to this method specify a list of points that define a piecewise-linear objective function for a single variable. Specifically, the \(x\) and \(y\) arguments give coordinates for the vertices of the function.

For additional details on piecewise-linear objective functions, refer to this discussion.

Note that, due to our lazy update approach, the new piecewise-linear objective won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

Return value:

A non-zero return value indicates that a problem occurred while setting the piecewise-linear objective. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to modify.

  • var – The variable whose objective function is being changed.

  • npoints – The number of points that define the piecewise-linear function.

  • x – The \(x\) values for the points that define the piecewise-linear function. Must be in non-decreasing order.

  • y – The \(y\) values for the points that define the piecewise-linear function.

Example:
double x[] = {1, 3, 5};
double y[] = {1, 2, 4};
error = GRBsetpwlobj(model, var, 3, x, y);
int GRBupdatemodel(GRBmodel *model)#

Process any pending model modifications.

Return value:

A non-zero return value indicates that a problem occurred while updating the model. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to update.

Example:
error = GRBupdatemodel(model);
int GRBfreemodel(GRBmodel *model)#

Free a model and release the associated memory.

Return value:

A non-zero return value indicates that a problem occurred while freeing the model. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to be freed.

Example:
error = GRBfreemodel(model);
int GRBXaddconstrs(GRBmodel *model, int numconstrs, size_t numnz, size_t *cbeg, int *cind, double *cval, char *sense, double *rhs, const char **constrnames)#

The size_t version of GRBaddconstrs. The two arguments that count non-zero values are of type size_t in this version to support models with more than 2 billion non-zero values.

Add new linear constraints to a model.

Note that, due to our lazy update approach, the new constraints won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

We recommend that you build your model one constraint at a time (using GRBaddconstr), since it introduces no significant overhead and we find that it produces simpler code. Feel free to use this routine if you disagree, though.

Return value:

A non-zero return value indicates that a problem occurred while adding the constraints. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new constraints should be added.

  • numconstrs – The number of new constraints to add.

  • numnz – The total number of non-zero coefficients in the new constraints.

  • cbeg – Constraint matrix non-zero values are passed into this routine in Compressed Sparse Row (CSR) format by this routine. Each constraint in the constraint matrix is represented as a list of index-value pairs, where each index entry provides the variable index for a non-zero coefficient, and each value entry provides the corresponding non-zero value. Each new constraint has an associated cbeg value, indicating the start position of the non-zeros for that constraint in the cind and cval arrays. This routine requires that the non-zeros for constraint i immediately follow those for constraint i-1 in cind and cval. Thus, cbeg[i] indicates both the index of the first non-zero in constraint i and the end of the non-zeros for constraint i-1. To give an example of how this representation is used, consider a case where cbeg[2] = 10 and cbeg[3] = 12. This would indicate that constraint 2 has two non-zero values associated with it. Their variable indices can be found in cind[10] and cind[11], and the numerical values for those non-zeros can be found in cval[10] and cval[11].

  • cind – Variable indices associated with non-zero values. See the description of the cbeg argument for more information.

  • cval – Numerical values associated with constraint matrix non-zeros. See the description of the cbeg argument for more information.

  • sense – Sense for the new constraints. Options are GRB_LESS_EQUAL, GRB_EQUAL, or GRB_GREATER_EQUAL.

  • rhs – Right-hand side values for the new constraints. This argument can be NULL, in which case the right-hand side values are set to 0.0.

  • constrnames – Names for the new constraints. This argument can be NULL, in which case all constraints are given default names.

int GRBXaddrangeconstrs(GRBmodel *model, int numconstrs, size_t numnz, size_t *cbeg, int *cind, double *cval, double *lower, double *upper, const char **constrnames)#

The size_t version of GRBaddrangeconstrs. The argument that counts non-zero values is of type size_t in this version to support models with more than 2 billion non-zero values.

Add new range constraints to a model. A range constraint states that the value of the input expression must be between the specified lower and upper bounds in any solution.

Note that, due to our lazy update approach, the new constraints won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

Return value:

A non-zero return value indicates that a problem occurred while adding the constraints. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new constraints should be added.

  • numconstrs – The number of new constraints to add.

  • numnz – The total number of non-zero coefficients in the new constraints.

  • cbeg – Constraint matrix non-zero values are passed into this routine in Compressed Sparse Row (CSR) format by this routine. Each constraint in the constraint matrix is represented as a list of index-value pairs, where each index entry provides the variable index for a non-zero coefficient, and each value entry provides the corresponding non-zero value. Each new constraint has an associated cbeg value, indicating the start position of the non-zeros for that constraint in the cind and cval arrays. This routine requires that the non-zeros for constraint i immediately follow those for constraint i-1 in cind and cval. Thus, cbeg[i] indicates both the index of the first non-zero in constraint i and the end of the non-zeros for constraint i-1. To give an example of how this representation is used, consider a case where cbeg[2] = 10 and cbeg[3] = 12. This would indicate that constraint 2 has two non-zero values associated with it. Their variable indices can be found in cind[10] and cind[11], and the numerical values for those non-zeros can be found in cval[10] and cval[11].

  • cind – Variable indices associated with non-zero values. See the description of the cbeg argument for more information.

  • cval – Numerical values associated with constraint matrix non-zeros. See the description of the cbeg argument for more information.

  • lower – Lower bounds for the linear expressions.

  • upper – Upper bounds for the linear expressions.

  • constrnames – Names for the new constraints. This argument can be NULL, in which case all constraints are given default names.

Important

Note that adding a range constraint to the model adds both a new constraint and a new variable. If you are keeping a count of the variables in the model, remember to add one for each range constraint.

Important

Note also that range constraints are stored internally as equality constraints. We use the extra variable that is added with a range constraint to capture the range information. Thus, the Sense attribute on a range constraint will always be GRB_EQUAL.

int GRBXaddvars(GRBmodel *model, int numvars, size_t numnz, size_t *vbeg, int *vind, double *vval, double *obj, double *lb, double *ub, char *vtype, const char **varnames)#

The size_t version of GRBaddvars. The two arguments that count non-zero values are of type size_t in this version to support models with more than 2 billion non-zero values.

Add new variables to a model.

Note that, due to our lazy update approach, the new variables won’t actually be added until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

Return value:

A non-zero return value indicates that a problem occurred while adding the variables. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to which the new variables should be added.

  • numvars – The number of new variables to add.

  • numnz – The total number of non-zero coefficients in the new columns.

  • vbeg – Constraint matrix non-zero values are passed into this routine in Compressed Sparse Column (CSC) format. Each column in the constraint matrix is represented as a list of index-value pairs, where each index entry provides the constraint index for a non-zero coefficient, and each value entry provides the corresponding non-zero value. Each variable in the model has a vbeg, indicating the start position of the non-zeros for that variable in the vind and vval arrays. This routine requires columns to be stored contiguously, so the start position for a variable is the end position for the previous variable. To give an example, if vbeg[2] = 10 and vbeg[3] = 12, that would indicate that variable 2 has two non-zero values associated with it. Their constraint indices can be found in vind[10] and vind[11], and the numerical values for those non-zeros can be found in vval[10] and vval[11].

  • vind – Constraint indices associated with non-zero values. See the description of the vbeg argument for more information.

  • vval – Numerical values associated with constraint matrix non-zeros. See the description of the vbeg argument for more information.

  • obj – Objective coefficients for the new variables. This argument can be NULL, in which case the objective coefficients are set to 0.0.

  • lb – Lower bounds for the new variables. This argument can be NULL, in which case all variables get lower bounds of 0.0.

  • ub – Upper bounds for the new variables. This argument can be NULL, in which case all variables get infinite upper bounds.

  • vtype – Types for the variables. Options are GRB_CONTINUOUS, GRB_BINARY, GRB_INTEGER, GRB_SEMICONT, or GRB_SEMIINT. This argument can be NULL, in which case all variables are assumed to be continuous.

  • varnames – Names for the new variables. This argument can be NULL, in which case all variables are given default names.

int GRBXchgcoeffs(GRBmodel *model, size_t numchgs, int *cind, int *vind, double *val)#

The size_t version of GRBchgcoeffs. The argument that counts non-zero values is of type size_t in this version to support models with more than 2 billion non-zero values.

Change a set of constraint matrix coefficients. This routine can be used to set a non-zero coefficient to zero, to create a non-zero coefficient where the coefficient is currently zero, or to change an existing non-zero coefficient to a new non-zero value. If you make multiple changes to the same coefficient, the last one will be applied.

Note that, due to our lazy update approach, the changes won’t actually be integrated into the model until you update the model (using GRBupdatemodel), optimize the model (using GRBoptimize), or write the model to disk (using GRBwrite).

Return value:

A non-zero return value indicates that a problem occurred while performing the modification. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • model – The model to modify.

  • numchgs – The number of coefficients to modify.

  • cind – Constraint indices for the coefficients to modify.

  • vind – Variable indices for the coefficients to modify.

  • val – The new values for the coefficients. For example, if cind[0] = 1, vind[0] = 3, and val[0] = 2.0, then the coefficient in constraint 1 associated with variable 3 would be changed to 2.0.

Example:
int cind[] = {0, 1};
int vind[] = {0, 0};
double val[] = {1.0, 1.0};
error = GRBXchgcoeffs(model, 2, cind, vind, val);
int GRBXloadmodel(GRBenv *env, GRBmodel **modelP, const char *Pname, int numvars, int numconstrs, int objsense, double objcon, double *obj, char *sense, double *rhs, size_t *vbeg, int *vlen, int *vind, double *vval, double *lb, double *ub, char *vtype, const char **varnames, const char **constrnames)#

The size_t version of GRBloadmodel. The argument that counts non-zero values is of type size_t in this version to support models with more than 2 billion non-zero values.

Create a new optimization model, using the provided arguments to initialize the model data (objective function, variable bounds, constraint matrix, etc.). The model is then ready for optimization, or for modification (e.g., addition of variables or constraints, changes to variable types or bounds, etc.).

Return value:

A non-zero return value indicates that a problem occurred while creating the model. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:
  • env – The environment in which the new model should be created. Note that the new model gets a copy of this environment, so subsequent modifications to the original environment (e.g., parameter changes) won’t affect the new model. Use GRBgetenv to modify the environment associated with a model.

  • modelP – The location in which the pointer to the newly created model should be placed.

  • Pname – The name of the model.

  • numvars – The number of variables in the model.

  • numconstrs – The number of constraints in the model.

  • objsense – The sense of the objective function. Allowed values are 1 (minimization) or -1 (maximization).

  • objcon – Constant objective offset.

  • obj – Objective coefficients for the new variables. This argument can be NULL, in which case the objective coefficients are set to 0.0.

  • sense – The senses of the new constraints. Options are '=' (equal), '<' (less-than-or-equal), or '>' (greater-than-or-equal). You can also use constants GRB_EQUAL, GRB_LESS_EQUAL, or GRB_GREATER_EQUAL.

  • rhs – Right-hand side values for the new constraints. This argument can be NULL, in which case the right-hand side values are set to 0.0.

  • vbeg – Constraint matrix non-zero values are passed into this routine in Compressed Sparse Column (CSC) format. Each column in the constraint matrix is represented as a list of index-value pairs, where each index entry provides the constraint index for a non-zero coefficient, and each value entry provides the corresponding non-zero value. Each variable in the model has a vbeg and vlen value, indicating the start position of the non-zeros for that variable in the vind and vval arrays, and the number of non-zero values for that variable, respectively. Thus, for example, if vbeg[2] = 10 and vlen[2] = 2, that would indicate that variable 2 has two non-zero values associated with it. Their constraint indices can be found in vind[10] and vind[11], and the numerical values for those non-zeros can be found in vval[10] and vval[11]. Note that the columns of the matrix must be ordered from first to last, implying that the values in vbeg must be non-decreasing.

  • vlen – Number of constraint matrix non-zero values associated with each variable. See the description of the vbeg argument for more information.

  • vind – Constraint indices associated with non-zero values. See the description of the vbeg argument for more information.

  • vval – Numerical values associated with constraint matrix non-zeros. See the description of the vbeg argument for more information.

  • lb – Lower bounds for the new variables. This argument can be NULL, in which case all variables get lower bounds of 0.0.

  • ub – Upper bounds for the new variables. This argument can be NULL, in which case all variables get infinite upper bounds.

  • vtype – Types for the variables. Options are GRB_CONTINUOUS, GRB_BINARY, GRB_INTEGER, GRB_SEMICONT, or GRB_SEMIINT. This argument can be NULL, in which case all variables are assumed to be continuous.

  • varnames – Names for the new variables. This argument can be NULL, in which case all variables are given default names.

  • constrnames – Names for the new constraints. This argument can be NULL, in which case all constraints are given default names.

Important

We recommend that you build a model one constraint or one variable at a time, using GRBaddconstr or GRBaddvar, rather than using this routine to load the entire constraint matrix at once. It is much simpler, less error prone, and it introduces no significant overhead.

Example:
/* maximize    x +   y + 2 z
   subject to  x + 2 y + 3 z <= 4
               x +   y       >= 1
   x, y, z binary */

int    vars    = 3;
int    constrs = 2;
size_t vbeg[]  = {0, 2, 4};
int    vlen[]  = {2, 2, 1};
int    vind[]  = {0, 1, 0, 1, 0};
double vval[]  = {1.0, 1.0, 2.0, 1.0, 3.0};
double obj[]   = {1.0, 1.0, 2.0};
char   sense[] = {GRB_LESS_EQUAL, GRB_GREATER_EQUAL};
double rhs[]   = {4.0, 1.0};
char   vtype[] = {GRB_BINARY, GRB_BINARY, GRB_BINARY};

error = GRBXloadmodel(env, &model, "example", vars, constrs, -1, 0.0,
                      obj, sense, rhs, vbeg, vlen, vind, vval,
                      NULL, NULL, vtype, NULL, NULL);