package operations_research.math_opt

Get desktop application:
View/edit binary Protocol Buffers messages

Updates the auxiliary objectives of a Model, both for existing and new variables. Auxiliary objectives can be deleted, added, or modified in place.

Used in: ModelUpdateProto

• repeated int64 deleted_objective_ids = 1

  Removes auxiliary objectives from the model. Each value must be in [0, max(int64)). Values must be in strictly increasing order. Applies only to existing auxiliary objective IDs that have not yet been deleted.

• map<int64, ObjectiveProto> new_objectives = 2

  Add new auxiliary objectives to the model. All keys must be in [0, max(int64)), and must be greater than any ids used in the initial model and previous updates. All nonempty names should be distinct from existing names for the primary and other auxiliary objectives.

• map<int64, ObjectiveUpdatesProto> objective_updates = 3

  Updates existing auxiliary objectives in the model. All key IDs must be existing in the model and not included in `deleted_objective_ids`.

A combinatorial characterization for a solution to a linear program. The simplex method for solving linear programs always returns a "basic feasible solution" which can be described combinatorially by a Basis. A basis assigns a BasisStatusProto for every variable and linear constraint. E.g. consider a standard form LP: min c * x s.t. A * x = b x >= 0 that has more variables than constraints and with full row rank A. Let n be the number of variables and m the number of linear constraints. A valid basis for this problem can be constructed as follows: * All constraints will have basis status FIXED. * Pick m variables such that the columns of A are linearly independent and assign the status BASIC. * Assign the status AT_LOWER for the remaining n - m variables. The basic solution for this basis is the unique solution of A * x = b that has all variables with status AT_LOWER fixed to their lower bounds (all zero). The resulting solution is called a basic feasible solution if it also satisfies x >= 0.

Used in: ModelSolveParametersProto, SolutionProto

• optional SparseBasisStatusVector constraint_status = 1

  Constraint basis status. Requirements: * constraint_status.ids is equal to LinearConstraints.ids.

• optional SparseBasisStatusVector variable_status = 2

  Variable basis status. Requirements: * constraint_status.ids is equal to VariablesProto.ids.

• SolutionStatusProto basic_dual_feasibility = 3

  This is an advanced feature used by MathOpt to characterize feasibility of suboptimal LP solutions (optimal solutions will always have status SOLUTION_STATUS_FEASIBLE). For single-sided LPs it should be equal to the feasibility status of the associated dual solution. For two-sided LPs it may be different in some edge cases (e.g. incomplete solves with primal simplex). If you are providing a starting basis via ModelSolveParametersProto.initial_basis, this value is ignored. It is only relevant for the basis returned by SolutionProto.basis.

Status of a variable/constraint in a LP basis.

Used in: SparseBasisStatusVector

• BASIS_STATUS_UNSPECIFIED = 0

  Guard value representing no status.

• BASIS_STATUS_FREE = 1

  The variable/constraint is free (it has no finite bounds).

• BASIS_STATUS_AT_LOWER_BOUND = 2

  The variable/constraint is at its lower bound (which must be finite).

• BASIS_STATUS_AT_UPPER_BOUND = 3

  The variable/constraint is at its upper bound (which must be finite).

• BASIS_STATUS_FIXED_VALUE = 4

  The variable/constraint has identical finite lower and upper bounds.

• BASIS_STATUS_BASIC = 5

  The variable/constraint is basic.

The callback function input data. Note that depending on the event, some information might be unavailable.

• CallbackEventProto event = 1

• optional SparseDoubleVectorProto primal_solution_vector = 2

  if event == CALLBACK_EVENT_MIP_NODE, the primal_solution_vector contains the variable values of the primal solution for the current LP-node relaxation. In some cases, no solution will be available (e.g. because LP was infeasible or the solve was imprecise). if event == CALLBACK_EVENT_MIP_SOLUTION, the primal_solution_vector contains variable values for the newly found primal (integer) feasible solution. Otherwise, the primal_solution_vector is not available. Note that, because of variable filters, it is possible that when a solution is found, it is empty. The message will be set but left empty in this case, while it will be unset when no solution is available.

• optional google.protobuf.Duration runtime = 3

  Running time since the `Solve` call.

• optional CallbackDataProto.PresolveStats presolve_stats = 4

• optional CallbackDataProto.SimplexStats simplex_stats = 5

• optional CallbackDataProto.BarrierStats barrier_stats = 6

• optional CallbackDataProto.MipStats mip_stats = 7

Barrier stats. Only available during CALLBACK_EVENT_BARRIER.

Used in: CallbackDataProto

• optional int32 iteration_count = 1

• optional double primal_objective = 2

• optional double dual_objective = 3

• optional double complementarity = 4

• optional double primal_infeasibility = 5

• optional double dual_infeasibility = 6

MIP B&B stats. Only available during CALLBACK_EVENT_MIPxxxx events. When using CP-SAT, only primal_bound, dual_bound and number_of_solutions_found are populated.

Used in: CallbackDataProto

• optional double primal_bound = 1

• optional double dual_bound = 2

• optional int64 explored_nodes = 3

• optional int64 open_nodes = 4

• optional int64 simplex_iterations = 5

• optional int32 number_of_solutions_found = 6

• optional int32 cutting_planes_in_lp = 7

Presolve stats. Only available during CALLBACK_EVENT_PRESOLVE.

Used in: CallbackDataProto

• optional int64 removed_variables = 1

• optional int64 removed_constraints = 2

• optional int64 bound_changes = 3

• optional int64 coefficient_changes = 4

Simplex stats. Only available during CALLBACK_EVENT_SIMPLEX.

Used in: CallbackDataProto

• optional int64 iteration_count = 1

• optional double objective_value = 2

• optional double primal_infeasibility = 3

• optional double dual_infeasibility = 4

• optional bool is_pertubated = 5

The supported events during a solve for callbacks.

Used in: CallbackDataProto, CallbackRegistrationProto

• CALLBACK_EVENT_UNSPECIFIED = 0

• CALLBACK_EVENT_PRESOLVE = 1

  The solver is currently running presolve. This event is supported by SOLVER_TYPE_GUROBI only.

• CALLBACK_EVENT_SIMPLEX = 2

  The solver is currently running the simplex method. This event is supported by SOLVER_TYPE_GUROBI only.

• CALLBACK_EVENT_MIP = 3

  The solver is in the MIP loop (called periodically before starting a new node). Useful for early termination. Note that this event does not provide information on LP relaxations nor about new incumbent solutions. This event is fully supported for MIP models by SOLVER_TYPE_GUROBI only. If used with SOLVER_TYPE_CP_SAT, it is called when the dual bound is improved.

• CALLBACK_EVENT_MIP_SOLUTION = 4

  Called every time a new MIP incumbent is found. This event is fully supported for MIP models by SOLVER_TYPE_GUROBI. SOLVER_TYPE_CP_SAT has partial support: you can view the solutions and request termination, but you cannot add lazy constraints. Other solvers don't support this event.

• CALLBACK_EVENT_MIP_NODE = 5

  Called inside a MIP node. Note that there is no guarantee that the callback function will be called on every node. That behavior is solver-dependent. Disabling cuts using SolveParametersProto may interfere with this event being called and/or adding cuts at this event, the behavior is solver specific. This event is supported for MIP models by SOLVER_TYPE_GUROBI only.

• CALLBACK_EVENT_BARRIER = 6

  Called in each iterate of an interior point/barrier method. This event is supported for SOLVER_TYPE_GUROBI only.

Provided with a callback at the start of a Solve() to inform the solver: * what information the callback needs, * how the callback might alter the solve process.

• repeated CallbackEventProto request_registration = 1

  The events the solver should invoke the callback at. When a solver is called with registered events that are not supported, an InvalidArgument is returned. The supported events may depend on the model. For example registering for CALLBACK_EVENT_MIP with a model that only contains continuous variables will fail for most solvers. See the documentation of each event to see their supported solvers/model types.

• optional SparseVectorFilterProto mip_solution_filter = 2

  If CALLBACK_EVENT_MIP_SOLUTION is in `request_registration`, then the returned primal_solution information will be filtered according to this rule.

• optional SparseVectorFilterProto mip_node_filter = 3

  If CALLBCK_EVENT_MIP_NODE is in `request_registration`, then the returned primal_solution information will be filtered according to this rule.

• bool add_cuts = 4

  Dynamically add linear constraints that strength the formulation but do not exclude integer points during CALLBACK_EVENT_MIP_NODE events.

• bool add_lazy_constraints = 5

  Dynamically add linear constraints that exclude integer points during CALLBACK_EVENT_MIP_NODE and/or CALLBACK_EVENT_MIP_SOLUTION events.

Return value of a callback function.

• bool terminate = 1

  When true it tells the solver to interrupt the solve as soon as possible. It can be set from any event. This is equivalent to using a SolveInterrupter and triggering it from the callback. Some solvers don't support interruption, in that case this is simply ignored and the solve terminates as usual. On top of that solvers may not immediately stop the solve. Thus the user should expect the callback to still be called after they set `terminate` to true in a previous call. Returning with `terminate` false after having previously returned true won't cancel the interruption.

• repeated CallbackResultProto.GeneratedLinearConstraint cuts = 4

  Dynamically generated linear constraints to add to the MIP. See GeneratedLinearConstraint::is_lazy for details.

• repeated SparseDoubleVectorProto suggested_solutions = 5

  Use only for CALLBACK_EVENT_MIP_NODE. Note that some solvers (e.g. Gurobi) support partially-defined solutions. The most common use case is to specify a value for each variable in the model. If a variable is not present in the primal solution, its value is taken to be undefined, and is up to the underlying solver to deal with it. For example, Gurobi will try to solve a Sub-MIP to get a fully feasible solution if necessary.

Used in: CallbackResultProto

• optional SparseDoubleVectorProto linear_expression = 1

  This message encode linear constraints of the form lower_bound <= linear_expression <= upper_bound

• double lower_bound = 2

• double upper_bound = 3

• bool is_lazy = 4

  Two types of generated linear constraints are supported based on is_lazy: * The "lazy constraint" can remove integer points from the feasible region and can be added at event CALLBACK_EVENT_MIP_NODE or CALLBACK_EVENT_MIP_SOLUTION * The "user cut" (on is_lazy=false) strengthens the LP without removing integer points. It can only be added at CALLBACK_EVENT_MIP_NODE.

• FeasibilityStatusProto feasibility = 1

  The primal feasibility status of the model, as determined by the solver.

• optional ModelSubsetProto infeasible_subsystem = 2

  An infeasible subsystem of the input model. Set if `feasibility` is INFEASIBLE and empty otherwise. The IDs correspond to those constraints included in the infeasible subsystem. Submessages with `Bounds` values indicate which side of a potentially ranged constraint are included in the subsystem: lower bound, upper bound, or both.

• bool is_minimal = 3

  True if the solver has certified that the returned subsystem is minimal (the instance is feasible if any additional constraint is removed). Note that, due to problem transformations MathOpt applies or idiosyncrasies of the solvers contract, the returned infeasible subsystem may not actually be minimal.

A direction of unbounded improvement to the dual of an optimization, problem; equivalently, a certificate of primal infeasibility. E.g. consider the primal dual pair linear program pair: (Primal) (Dual) min c * x max b * y s.t. A * x >= b s.t. y * A + r = c x >= 0 y, r >= 0. The dual ray is the pair (y, r) satisfying: b * y > 0 y * A + r = 0 y, r >= 0 Observe that adding a positive multiple of (y, r) to dual feasible solution maintains dual feasibility and improves the objective (proving the dual is unbounded). The dual ray also proves the primal problem is infeasible. In the message DualRay below, y is dual_values and r is reduced_costs.

Used in: SolveResultProto

• optional SparseDoubleVectorProto dual_values = 1

  Requirements: * dual_values.ids are elements of LinearConstraints.ids. * dual_values.values must all be finite.

• optional SparseDoubleVectorProto reduced_costs = 2

  Requirements: * reduced_costs.ids are elements of VariablesProto.ids. * reduced_costs.values must all be finite.

A solution to the dual of an optimization problem. E.g. consider the primal dual pair linear program pair: (Primal) (Dual) min c * x max b * y s.t. A * x >= b s.t. y * A + r = c x >= 0 y, r >= 0. The dual solution is the pair (y, r). It is feasible if it satisfies the constraints from (Dual) above. In the message below, y is dual_values, r is reduced_costs, and b * y is objective value.

Used in: SolutionProto

• optional SparseDoubleVectorProto dual_values = 1

  Requirements: * dual_values.ids are elements of LinearConstraints.ids. * dual_values.values must all be finite.

• optional SparseDoubleVectorProto quadratic_dual_values = 5

  Requirements: * quadratic_dual_values.ids are keys of ModelProto.quadratic_constraints. * quadratic_dual_values.values must all be finite. Note: Some solvers only return quadratic constraint duals when a solver-specific parameter is set (see go/mathopt-qcqp-dual#solver-specific).

• optional SparseDoubleVectorProto reduced_costs = 2

  Requirements: * reduced_costs.ids are elements of VariablesProto.ids. * reduced_costs.values must all be finite.

• optional double objective_value = 3

  TODO(b/195295177): consider making this non-optional Objective value as computed by the underlying solver.

• SolutionStatusProto feasibility_status = 4

  Feasibility status of the solution according to the underlying solver.

Effort level applied to an optional task while solving (see SolveParametersProto for use). Emphasis is used to configure a solver feature as follows: * If a solver doesn't support the feature, only UNSPECIFIED will always be valid, any other setting will typically an invalid argument error (some solvers may also accept OFF). * If the solver supports the feature: - When set to UNSPECIFIED, the underlying default is used. - When the feature cannot be turned off, OFF will return an error. - If the feature is enabled by default, the solver default is typically mapped to MEDIUM. - If the feature is supported, LOW, MEDIUM, HIGH, and VERY HIGH will never give an error, and will map onto their best match.

Used in: SolveParametersProto

• EMPHASIS_UNSPECIFIED = 0

• EMPHASIS_OFF = 1

• EMPHASIS_LOW = 2

• EMPHASIS_MEDIUM = 3

• EMPHASIS_HIGH = 4

• EMPHASIS_VERY_HIGH = 5

Problem feasibility status as claimed by the solver (solver is not required to return a certificate for the claim).

Used in: ComputeInfeasibleSubsystemResultProto, ProblemStatusProto

• FEASIBILITY_STATUS_UNSPECIFIED = 0

  Guard value representing no status.

• FEASIBILITY_STATUS_UNDETERMINED = 1

  Solver does not claim a status.

• FEASIBILITY_STATUS_FEASIBLE = 2

  Solver claims the problem is feasible.

• FEASIBILITY_STATUS_INFEASIBLE = 3

  Solver claims the problem is infeasible.

GLPK specific parameters for solving. Fields are optional to enable to capture user intention; if they set explicitly a value to then no generic solve parameters will overwrite this parameter. User specified solver specific parameters have priority on generic parameters.

Used in: SolveParametersProto

• optional bool compute_unbound_rays_if_possible = 1

  Compute the primal or dual unbound ray when the variable (structural or auxiliary) causing the unboundness is identified (see glp_get_unbnd_ray()). The unset value is equivalent to false. Rays are only available when solving linear programs, they are not available for MIPs. On top of that they are only available when using a simplex algorithm with the presolve disabled. A primal ray can only be built if the chosen LP algorithm is LP_ALGORITHM_PRIMAL_SIMPLEX. Same for a dual ray and LP_ALGORITHM_DUAL_SIMPLEX. The computation involves the basis factorization to be available which may lead to extra computations/errors.

Parameters used to initialize the Gurobi solver.

Used in: SolverInitializerProto

• optional GurobiInitializerProto.ISVKey isv_key = 1

  An optional ISV key to use. See http://www.gurobi.com/products/licensing-pricing/isv-program.

Used in: GurobiInitializerProto

• string name = 1

• string application_name = 2

• int32 expiration = 3

• string key = 4

Gurobi specific parameters for solving. See https://www.gurobi.com/documentation/9.1/refman/parameters.html for a list of possible parameters. Example text proto to set the Barrier Iteration Limit: parameters : [{name: "BarIterLimit" value: "10}] With Gurobi, the order that parameters are applied can have an impact in rare situations. Parameters are applied in the following order: * LogToConsole is set from CommonSolveParameters.enable_output. * Any common parameters not overwritten by GurobiParameters. * param_values in iteration order (insertion order). We set LogToConsole first because setting other parameters can generate output.

Used in: SolveParametersProto

• repeated GurobiParametersProto.Parameter parameters = 1

Used in: GurobiParametersProto

• string name = 1

• string value = 2

The options exposed by HiGHS. Use at your own risk, these are completely undocumented. Option names are given as strings in HighsOptions.h, see: https://github.com/ERGO-Code/HiGHS/blob/7421e44b09563f637dc6422ea461a8832b29e543/src/lp_data/HighsOptions.h Each member of HighsOptionsStruct has a corresponding OptionRecord with a string name (that appears to match the field name), use these as keys below.

Used in: SolveParametersProto

• map<string, string> string_options = 1

  Example keys: "presolve", "solver", "parallel"

• map<string, double> double_options = 2

  Example keys: "time_limit", "primal_feasibility_tolerance"

• map<string, int32> int_options = 3

  Example keys: "random_seed", "simplex_strategy"

• map<string, bool> bool_options = 4

  Example keys: "log_to_console", "allow_unbounded_or_infeasible"

Data for representing a single indicator constraint of the form: Variable(indicator_id) = (activate_on_zero ? 0 : 1) ⇒ lower_bound <= expression <= upper_bound. If a variable involved in this constraint (either the indicator, or appearing in `expression`) is deleted, it is treated as if it were set to zero. In particular, deleting the indicator variable means that the indicator constraint is vacuous if `activate_on_zero` is false, and that it is equivalent to a linear constraint if `activate_on_zero` is true.

Used in: IndicatorConstraintUpdatesProto, ModelProto

• optional int64 indicator_id = 1

  An ID corresponding to a binary variable, or unset. If unset, the indicator constraint is ignored. If set, we require that: * VariablesProto.integers[indicator_id] = true, * VariablesProto.lower_bounds[indicator_id] >= 0, * VariablesProto.upper_bounds[indicator_id] <= 1. These conditions are not validated by MathOpt, but if not satisfied will lead to the solver returning an error upon solving.

• bool activate_on_zero = 6

  If true, then if the indicator variable takes value 0, the implied constraint must hold. Otherwise, if the indicator variable takes value 1, then the implied constraint must hold.

• optional SparseDoubleVectorProto expression = 2

  Must be a valid linear expression with respect to the containing model: * All stated conditions on `SparseDoubleVectorProto`, * All elements of `expression.values` must be finite, * `expression.ids` are a subset of `VariablesProto.ids`.

• double lower_bound = 3

  Must have value in [-inf, inf); cannot be NaN.

• double upper_bound = 4

  Must have value in (-inf, inf]; cannot be NaN.

• string name = 5

  Parent messages may have uniqueness requirements on this field; e.g., see `ModelProto.indicator_constraints` and `IndicatorConstraintUpdatesProto.new_constraints`.

Data for updates to indicator constraints; only addition and deletion, no support for in-place constraint updates.

Used in: ModelUpdateProto

• repeated int64 deleted_constraint_ids = 1

  Removes indicator constraints from the model. Each value must be in [0, max(int64)). Values must be in strictly increasing order. Applies only to existing indicator constraint ids that have not yet been deleted.

• map<int64, IndicatorConstraintProto> new_constraints = 2

  Add new indicator constraints to the model. All keys must be in [0, max(int64)), and must be greater than any ids used in the initial model and previous updates. All nonempty names should be distinct from existing names and each other.

Selects an algorithm for solving linear programs.

Used in: SolveParametersProto

• LP_ALGORITHM_UNSPECIFIED = 0

• LP_ALGORITHM_PRIMAL_SIMPLEX = 1

  The (primal) simplex method. Typically can provide primal and dual solutions, primal/dual rays on primal/dual unbounded problems, and a basis.

• LP_ALGORITHM_DUAL_SIMPLEX = 2

  The dual simplex method. Typically can provide primal and dual solutions, primal/dual rays on primal/dual unbounded problems, and a basis.

• LP_ALGORITHM_BARRIER = 3

  The barrier method, also commonly called an interior point method (IPM). Can typically give both primal and dual solutions. Some implementations can also produce rays on unbounded/infeasible problems. A basis is not given unless the underlying solver does "crossover" and finishes with simplex.

• LP_ALGORITHM_FIRST_ORDER = 4

  An algorithm based around a first-order method. These will typically produce both primal and dual solutions, and potentially also certificates of primal and/or dual infeasibility. First-order methods typically will provide solutions with lower accuracy, so users should take care to set solution quality parameters (e.g., tolerances) and to validate solutions.

When a Solve() stops early with TerminationReasonProto FEASIBLE or NO_SOLUTION_FOUND, the specific limit that was hit.

Used in: TerminationProto

• LIMIT_UNSPECIFIED = 0

  Used as a null value when we terminated not from a limit (e.g. TERMINATION_REASON_OPTIMAL).

• LIMIT_UNDETERMINED = 1

  The underlying solver does not expose which limit was reached.

• LIMIT_ITERATION = 2

  An iterative algorithm stopped after conducting the maximum number of iterations (e.g. simplex or barrier iterations).

• LIMIT_TIME = 3

  The algorithm stopped after a user-specified computation time.

• LIMIT_NODE = 4

  A branch-and-bound algorithm stopped because it explored a maximum number of nodes in the branch-and-bound tree.

• LIMIT_SOLUTION = 5

  The algorithm stopped because it found the required number of solutions. This is often used in MIPs to get the solver to return the first feasible solution it encounters.

• LIMIT_MEMORY = 6

  The algorithm stopped because it ran out of memory.

• LIMIT_CUTOFF = 12

  The solver was run with a cutoff (e.g. SolveParameters.cutoff_limit was set) on the objective, indicating that the user did not want any solution worse than the cutoff, and the solver concluded there were no solutions at least as good as the cutoff. Typically no further solution information is provided.

• LIMIT_OBJECTIVE = 7

  The algorithm stopped because it either found a solution or a bound better than a limit set by the user (see SolveParameters.objective_limit and SolveParameters.best_bound_limit).

• LIMIT_NORM = 8

  The algorithm stopped because the norm of an iterate became too large.

• LIMIT_INTERRUPTED = 9

  The algorithm stopped because of an interrupt signal or a user interrupt request.

• LIMIT_SLOW_PROGRESS = 10

  The algorithm stopped because it was unable to continue making progress towards the solution.

• LIMIT_OTHER = 11

  The algorithm stopped due to a limit not covered by one of the above. Note that LIMIT_UNDETERMINED is used when the reason cannot be determined, and LIMIT_OTHER is used when the reason is known but does not fit into any of the above alternatives. TerminationProto.detail may contain additional information about the limit.

Updates to existing linear constraints in a ModelProto.

Used in: ModelUpdateProto

• optional SparseDoubleVectorProto lower_bounds = 1

  Updates ModelProto.linear_constraints.lower_bounds. Requirements: * lower_bounds.ids must be from ModelProto.linear_constraints.ids. * lower_bounds.values must be < infinity. * Unset values are unchanged.

• optional SparseDoubleVectorProto upper_bounds = 2

  Updates ModelProto.linear_constraints.upper_bounds. Requirements: * upper_bounds.ids must be from ModelProto.linear_constraints.ids. * upper_bounds.values must be > -infinity. * Unset values are unchanged.

As used below, we define "#linear constraints" = size(LinearConstraintsProto.ids).

Used in: ModelProto, ModelUpdateProto

• repeated int64 ids = 1

  Must be nonnegative and strictly increasing. The max(int64) value can't be used.

• repeated double lower_bounds = 2

  Should have length equal to #linear constraints, values in [-inf, inf).

• repeated double upper_bounds = 3

  Should have length equal to #linear constraints, values in (-inf, inf].

• repeated string names = 4

  If not set, assumed to be all empty strings. Otherwise, should have length equal to #linear constraints. All nonempty names must be distinct. TODO(b/169575522): we may relax this.

A sparse representation of a linear expression (a weighted sum of variables, plus a constant offset).

Used in: SecondOrderConeConstraintProto, SosConstraintProto

• repeated int64 ids = 1

  Ids of variables. Must be sorted (in increasing ordering) with all elements distinct.

• repeated double coefficients = 2

  Must have equal length to ids. Values must be finite may not be NaN.

• double offset = 3

  Must be finite and may not be NaN.

An optimization problem. MathOpt supports: - Continuous and integer decision variables with optional finite bounds. - Linear and quadratic objectives (single or multiple objectives), either minimized or maximized. - A number of constraints types, including: * Linear constraints * Quadratic constraints * Second-order cone constraints * Logical constraints > SOS1 and SOS2 constraints > Indicator constraints By default, constraints are represented in "id-to-data" maps. However, we represent linear constraints in a more efficient "struct-of-arrays" format.

Used in: SolveRequest

• string name = 1

• optional VariablesProto variables = 2

• optional ObjectiveProto objective = 3

  The primary objective in the model.

• map<int64, ObjectiveProto> auxiliary_objectives = 10

  Auxiliary objectives for use in multi-objective models. Map key IDs must be in [0, max(int64)). Each priority, and each nonempty name, must be unique and also distinct from the primary `objective`.

• optional LinearConstraintsProto linear_constraints = 4

• optional SparseDoubleMatrixProto linear_constraint_matrix = 5

  The variable coefficients for the linear constraints. If a variable involved in this constraint is deleted, it is treated as if it were set to zero. Requirements: * linear_constraint_matrix.row_ids are elements of linear_constraints.ids. * linear_constraint_matrix.column_ids are elements of variables.ids. * Matrix entries not specified are zero. * linear_constraint_matrix.coefficients must all be finite.

• map<int64, QuadraticConstraintProto> quadratic_constraints = 6

  Quadratic constraints in the model.

• map<int64, SecondOrderConeConstraintProto> second_order_cone_constraints = 11

  Second-order cone constraints in the model.

• map<int64, SosConstraintProto> sos1_constraints = 7

  SOS1 constraints in the model, which constrain that at most one `expression` can be nonzero. The optional `weights` entries are an implementation detail used by the solver to (hopefully) converge more quickly. In more detail, solvers may (or may not) use these weights to select branching decisions that produce "balanced" children nodes.

• map<int64, SosConstraintProto> sos2_constraints = 8

  SOS2 constraints in the model, which constrain that at most two entries of `expression` can be nonzero, and they must be adjacent in their ordering. If no `weights` are provided, this ordering is their linear ordering in the `expressions` list; if `weights` are presented, the ordering is taken with respect to these values in increasing order.

• map<int64, IndicatorConstraintProto> indicator_constraints = 9

  Indicator constraints in the model, which enforce that, if a binary "indicator variable" is set to one, then an "implied constraint" must hold.

TODO(b/183628247): follow naming convention in fields below. Parameters to control a single solve that are specific to the input model (see SolveParametersProto for model independent parameters).

Used in: SolveRequest

• optional SparseVectorFilterProto variable_values_filter = 1

  Filter that is applied to all returned sparse containers keyed by variables in PrimalSolutionProto and PrimalRayProto (PrimalSolutionProto.variable_values, PrimalRayProto.variable_values). Requirements: * filtered_ids are elements of VariablesProto.ids.

• optional SparseVectorFilterProto dual_values_filter = 2

  Filter that is applied to all returned sparse containers keyed by linear constraints in DualSolutionProto and DualRay (DualSolutionProto.dual_values, DualRay.dual_values). Requirements: * filtered_ids are elements of LinearConstraints.ids.

• optional SparseVectorFilterProto quadratic_dual_values_filter = 10

  Filter that is applied to all returned sparse containers keyed by quadratic constraints in DualSolutionProto and DualRay (DualSolutionProto.quadratic_dual_values, DualRay.quadratic_dual_values). Requirements: * filtered_ids are keys of ModelProto.quadratic_constraints.

• optional SparseVectorFilterProto reduced_costs_filter = 3

  Filter that is applied to all returned sparse containers keyed by variables in DualSolutionProto and DualRay (DualSolutionProto.reduced_costs, DualRay.reduced_costs). Requirements: * filtered_ids are elements of VariablesProto.ids.

• optional BasisProto initial_basis = 4

  Optional initial basis for warm starting simplex LP solvers. If set, it is expected to be valid according to `ValidateBasis` in `validators/solution_validator.h` for the current `ModelSummary`.

• repeated SolutionHintProto solution_hints = 5

  Optional solution hints. If the underlying solver only accepts a single hint, the first hint is used.

• optional SparseInt32VectorProto branching_priorities = 6

  Optional branching priorities. Variables with higher values will be branched on first. Variables for which priorities are not set get the solver's default priority (usually zero). Requirements: * branching_priorities.values must be finite. * branching_priorities.ids must be elements of VariablesProto.ids.

• optional ObjectiveParametersProto primary_objective_parameters = 7

  Optional parameters for the primary objective in a multi-objective model.

• map<int64, ObjectiveParametersProto> auxiliary_objective_parameters = 8

  Optional parameters for the auxiliary objectives in a multi-objective model. Requirements: * Map keys must also be map keys of ModelProto.auxiliary_objectives.

• repeated int64 lazy_linear_constraint_ids = 9

  Optional lazy constraint annotations. Included linear constraints will be marked as "lazy" with supporting solvers, meaning that they will only be added to the working model as-needed as the solver runs. Note that this an algorithmic hint that does not affect the model's feasible region; solvers not supporting these annotations will simply ignore it. Requirements: * Each entry must be an element of VariablesProto.ids. * Entries must be in strictly increasing order (i.e., sorted, no repeats).

Represents a subset of the constraints (including variable bounds and integrality) of a `ModelProto`.

Used in: ComputeInfeasibleSubsystemResultProto

• map<int64, ModelSubsetProto.Bounds> variable_bounds = 1

  Keys are variable IDs, and must be in [0, max(int64)). Values indicate which of the lower and upper variable bounds are included in the subsystem.

• repeated int64 variable_integrality = 2

  Variable IDs. Values must be in [0, max(int64)) and strictly increasing.

• map<int64, ModelSubsetProto.Bounds> linear_constraints = 3

  Keys are linear constraint IDs, and must be in [0, max(int64)). Values indicate which of the lower and upper bounds on the linear constraint are included in the subsystem.

• map<int64, ModelSubsetProto.Bounds> quadratic_constraints = 4

  Keys are quadratic constraint IDs, and must be in [0, max(int64)). Values indicate which of the lower and upper bounds on the quadratic constraint are included in the subsystem.

• repeated int64 second_order_cone_constraints = 5

  Second-order cone constraint IDs. Values must be in [0, max(int64)) and strictly increasing.

• repeated int64 sos1_constraints = 6

  SOS1 constraint IDs. Values must be in [0, max(int64)) and strictly increasing.

• repeated int64 sos2_constraints = 7

  SOS2 constraint IDs. Values must be in [0, max(int64)) and strictly increasing.

• repeated int64 indicator_constraints = 8

  Indicator constraint IDs. Values must be in [0, max(int64)) and strictly increasing.

Used in: ModelSubsetProto

• bool lower = 1

• bool upper = 2

Updates to a ModelProto.

• repeated int64 deleted_variable_ids = 1

  Removes variables from the model. Values must be in strictly increasing order. Apply only to existing variable ids that have not yet been deleted. The ids of deleted variables should not appear in other fields (e.g. variable_updates, objective_updates, linear_constraint_matrix_updates).

• repeated int64 deleted_linear_constraint_ids = 2

  Removes linear constraints from the model. Values must be in strictly increasing order. Apply only to existing linear constraint ids that have not yet been deleted. The ids of deleted linear constraints should not appear in other fields (e.g. linear_constraint_updates, linear_constraint_matrix_updates).

• optional VariableUpdatesProto variable_updates = 3

  Updates properties of existing variables. Should not contain any deleted variable ids.

• optional LinearConstraintUpdatesProto linear_constraint_updates = 4

  Updates properties of existing linear constraints. Should not contain any deleted linear constraints ids.

• optional VariablesProto new_variables = 5

  Add new variables to the model. All new_variables.ids must be greater than any ids used in the initial model and previous updates. All nonempty names should be distinct from existing names.

• optional LinearConstraintsProto new_linear_constraints = 6

  Add new linear constraints to the model. All new_linear_constraints.ids must be greater than any ids used in the initial model and previous updates. All nonempty names should be distinct from existing names.

• optional ObjectiveUpdatesProto objective_updates = 7

  Updates the primary objective, both for existing and new variables.

• optional AuxiliaryObjectivesUpdatesProto auxiliary_objectives_updates = 13

  Updates the auxiliary objectives, both for existing and new variables.

• optional SparseDoubleMatrixProto linear_constraint_matrix_updates = 8

  Updates the linear constraint matrix, both for existing and new variables/linear constraints. Requirements: * linear_constraint_matrix_updates.row_ids are linear constraint ids, either existing or new. * linear_constraint_matrix_updates.column_ids are variables ids, either existing or new. * Matrix entries are unchanged if the (constraint, variable) pair is existing and unset. * Matrix entries are zero if either the constraint or variable is new and the (constraint, variable) pair is unset. * Zero values delete existing entries, and have no effect for new entries. * linear_constraint_matrix.values must all be finite.

• optional QuadraticConstraintUpdatesProto quadratic_constraint_updates = 9

  Updates the quadratic constraints (addition and deletion only).

• optional SecondOrderConeConstraintUpdatesProto second_order_cone_constraint_updates = 14

  Updates the second-order cone constraints (addition and deletion only).

• optional SosConstraintUpdatesProto sos1_constraint_updates = 10

  Updates the general constraints (addition and deletion only).

• optional SosConstraintUpdatesProto sos2_constraint_updates = 11

• optional IndicatorConstraintUpdatesProto indicator_constraint_updates = 12

Bounds on the optimal objective value.

Used in: TerminationProto

• double primal_bound = 2

  Solver claims there exists a primal solution that is numerically feasible (i.e. feasible up to the solvers tolerance), and whose objective value is primal_bound. The optimal value is equal or better (smaller for min objectives and larger for max objectives) than primal_bound, but only up to solver-tolerances.

• double dual_bound = 3

  Solver claims there exists a dual solution that is numerically feasible (i.e. feasible up to the solvers tolerance), and whose objective value is dual_bound. For MIP solvers, the associated dual problem may be some continuous relaxation (e.g. LP relaxation), but it is often an implicitly defined problem that is a complex consequence of the solvers execution. For both continuous and MIP solvers, the optimal value is equal or worse (larger for min objective and smaller for max objectives) than dual_bound, but only up to solver-tolerances. Some continuous solvers provide a numerically safer dual bound through solver's specific output (e.g. for PDLP, pdlp_output.convergence_information.corrected_dual_objective).

Parameters for an individual objective in a multi-objective model.

Used in: ModelSolveParametersProto

• optional double objective_degradation_absolute_tolerance = 7

  Optional objective degradation absolute tolerance. For a hierarchical multi-objective solver, each objective fⁱ is processed in priority order: the solver determines the optimal objective value Γⁱ, if it exists, subject to all constraints in the model and the additional constraints that fᵏ(x) = Γᵏ (within tolerances) for each k < i. If set, a solution is considered to be "within tolerances" for this objective fᵏ if |fᵏ(x) - Γᵏ| ≤ `objective_degradation_absolute_tolerance`. See also `objective_degradation_relative_tolerance`; if both parameters are set for a given objective, the solver need only satisfy one to be considered "within tolerances". If set, must be nonnegative.

• optional double objective_degradation_relative_tolerance = 8

  Optional objective degradation relative tolerance. For a hierarchical multi-objective solver, each objective fⁱ is processed in priority order: the solver determines the optimal objective value Γⁱ, if it exists, subject to all constraints in the model and the additional constraints that fᵏ(x) = Γᵏ (within tolerances) for each k < i. If set, a solution is considered to be "within tolerances" for this objective fᵏ if |fᵏ(x) - Γᵏ| ≤ `objective_degradation_relative_tolerance` * |Γᵏ|. See also `objective_degradation_absolute_tolerance`; if both parameters are set for a given objective, the solver need only satisfy one to be considered "within tolerances". If set, must be nonnegative.

• optional google.protobuf.Duration time_limit = 9

  Maximum time a solver should spend on optimizing this particular objective (or infinite if not set). Note that this does not supersede the global time limit in SolveParametersProto.time_limit; both will be enforced when set. This value is not a hard limit, solve time may slightly exceed this value.

Used in: AuxiliaryObjectivesUpdatesProto, ModelProto

• bool maximize = 1

  false is minimize, true is maximize

• double offset = 2

  Must be finite and not NaN.

• optional SparseDoubleVectorProto linear_coefficients = 3

  ObjectiveProto terms that are linear in the decision variables. Requirements: * linear_coefficients.ids are elements of VariablesProto.ids. * VariablesProto not specified correspond to zero. * linear_coefficients.values must all be finite. * linear_coefficients.values can be zero, but this just wastes space.

• optional SparseDoubleMatrixProto quadratic_coefficients = 4

  Objective terms that are quadratic in the decision variables. Requirements in addition to those on SparseDoubleMatrixProto messages: * Each element of quadratic_coefficients.row_ids and each element of quadratic_coefficients.column_ids must be an element of VariablesProto.ids. * The matrix must be upper triangular: for each i, quadratic_coefficients.row_ids[i] <= quadratic_coefficients.column_ids[i]. Notes: * Terms not explicitly stored have zero coefficient. * Elements of quadratic_coefficients.coefficients can be zero, but this just wastes space.

• string name = 5

  Parent messages may have uniqueness requirements on this field; e.g., see ModelProto.objectives and AuxiliaryObjectivesUpdatesProto.new_objectives.

• int64 priority = 6

  For multi-objective problems, the priority of this objective relative to the others (lower is more important). This value must be nonnegative. Furthermore, each objective priority in the model must be distinct at solve time. This condition is not validated at the proto level, so models may temporarily have objectives with the same priority.

Updates the objective of a Model, both for existing and new variables.

Used in: AuxiliaryObjectivesUpdatesProto, ModelUpdateProto

• optional bool direction_update = 1

  Not set indicates no change, false is minimize, true is maximize.

• optional double offset_update = 2

  Not set indicates not change, otherwise the new offset.

• optional SparseDoubleVectorProto linear_coefficients = 3

  Updates ObjectiveProto.linear_coefficients. Requirements: * linear_coefficients.ids must be variable ids, either existing one (from ModelProto.variables.ids) or new ones (from ModelUpdateProto.new_variables.ids). * linear_coefficients.values must be finite * Unset values are unchanged. * The value 0.0 removes a variable from the linear objective. This value should only be used for existing variables.

• optional SparseDoubleMatrixProto quadratic_coefficients = 4

  Updates ObjectiveProto.quadratic_coefficients Requirements in addition to those on SparseDoubleMatrixProto messages: * Each element of quadratic_coefficients.row_ids and each element of quadratic_coefficients.column_ids must be a variable id, either an existing one (from ModelProto.variables.ids) or a new one (from ModelUpdateProto.new_variables.ids). * The matrix must be upper triangular: for each i, quadratic_coefficients.row_ids[i] <= quadratic_coefficients.column_ids[i]. Notes: * Unset values are unchanged. * The value 0.0 removes a quadratic term (i.e. product of two variables) from the quadratic objective. This value should only be used for existing quadratic terms appearing in the objective.

• optional int64 priority_update = 5

  Not set indicates no change, otherwise the new priority. If set, the value must be nonnegative. Furthermore, each objective priority must be distinct at solve time; this condition is not validated at the proto level, so models may temporarily have objectives with the same priority.

Solver-specific output for OSQP.

Used in: SolveResultProto

• bool initialized_underlying_solver = 1

  Field is true if the underlying OSQP++ object was initialized for the current solve, and false if the object was instead used incrementally. In more detail, this tracks: was osqp::OsqpSolver::Init called on the operations_research::math_opt::OsqpSolver::solver_ field at any point during the solve process?

This proto mirrors the fields of OsqpSettings in osqp_cpp/include/osqp++.h, which in turn (nearly) mirrors the fields of OSQPSettings in osqp/include/types.h. See also https://osqp.org/docs/interfaces/solver_settings.html for documentation and default values. This proto must be kept in sync with logic in osqp_solver.cc. LINT.IfChange

Used in: SolveParametersProto

• optional double rho = 1

  ADMM rho step. Must be > 0.

• optional double sigma = 2

  ADMM sigma step. Must be > 0.

• optional int64 scaling = 3

  Number of heuristic scaling iterations. Must be >= 0.

• optional bool adaptive_rho = 4

  Is rho step size adaptive?

• optional int64 adaptive_rho_interval = 5

  Number of iterations between rho adaptations; if 0, then automatically selected. Must be >= 0.

• optional double adaptive_rho_tolerance = 6

  Tolerance X for adapting rho: The new value must be X times larger or 1/X times smaller than the current value. Must be >= 1.

• optional double adaptive_rho_fraction = 7

  In automatic mode (adaptive_rho_interval = 0), what fraction of setup time is spent on selecting rho. Must be >= 0.

• optional int64 max_iter = 8

  Maximum number of iterations. Must be > 0.

• optional double eps_abs = 9

  Absolute error tolerance for convergence. Must be >= 0.

• optional double eps_rel = 10

  Relative error tolerance for convergence. Must be >= 0.

• optional double eps_prim_inf = 11

  Absolute error tolerance for primal infeasibility. Must be >= 0.

• optional double eps_dual_inf = 12

  Relative error tolerance for dual infeasibility. Must be >= 0.

• optional double alpha = 13

  ADMM overrelaxation parameter. Must be > 0 and < 2.

• optional double delta = 14

  Polishing regularization parameter. Must be > 0.

• optional bool polish = 15

  Perform polishing?

• optional int64 polish_refine_iter = 16

  Number of refinement iterations in polishing. Must be > 0.

• optional bool verbose = 17

  Print solver output?

• optional bool scaled_termination = 18

  Use scaled termination criteria?

• optional int64 check_termination = 19

  Interval for checking termination. If 0 or unset, termination checking is disabled. Must be >= 0.

• optional bool warm_start = 20

  Perform warm starting?.

• optional double time_limit = 21

  Run time limit in seconds. If 0 or unset, then no time limit. Must be >= 0.

A direction of unbounded improvement to an optimization problem; equivalently, a certificate of infeasibility for the dual of the optimization problem. E.g. consider a simple linear program: min c * x s.t. A * x >= b x >= 0 A primal ray is an x that satisfies: c * x < 0 A * x >= 0 x >= 0 Observe that given a feasible solution, any positive multiple of the primal ray plus that solution is still feasible, and gives a better objective value. A primal ray also proves the dual optimization problem infeasible. In the message PrimalRay below, variable_values is x.

Used in: SolveResultProto

• optional SparseDoubleVectorProto variable_values = 1

  Requirements: * variable_values.ids are elements of VariablesProto.ids. * variable_values.values must all be finite.

A solution to an optimization problem. E.g. consider a simple linear program: min c * x s.t. A * x >= b x >= 0. A primal solution is assignment values to x. It is feasible if it satisfies A * x >= b and x >= 0 from above. In the message PrimalSolutionProto below, variable_values is x and objective_value is c * x.

Used in: SolutionProto

• optional SparseDoubleVectorProto variable_values = 1

  Requirements: * variable_values.ids are elements of VariablesProto.ids. * variable_values.values must all be finite.

• double objective_value = 2

  Objective value as computed by the underlying solver. Cannot be infinite or NaN.

• map<int64, double> auxiliary_objective_values = 4

  Auxiliary objective values as computed by the underlying solver. Keys must be valid auxiliary objective IDs. Values cannot be infinite or NaN.

• SolutionStatusProto feasibility_status = 3

  Feasibility status of the solution according to the underlying solver.

Feasibility status of the primal problem and its dual (or the dual of a continuous relaxation) as claimed by the solver. The solver is not required to return a certificate for the claim (e.g. the solver may claim primal feasibility without returning a primal feasible solutuion). This combined status gives a comprehensive description of a solver's claims about feasibility and unboundedness of the solved problem. For instance, * a feasible status for primal and dual problems indicates the primal is feasible and bounded and likely has an optimal solution (guaranteed for problems without non-linear constraints). * a primal feasible and a dual infeasible status indicates the primal problem is unbounded (i.e. has arbitrarily good solutions). Note that a dual infeasible status by itself (i.e. accompanied by an undetermined primal status) does not imply the primal problem is unbounded as we could have both problems be infeasible. Also, while a primal and dual feasible status may imply the existence of an optimal solution, it does not guarantee the solver has actually found such optimal solution.

Used in: SolveStatsProto, TerminationProto

• FeasibilityStatusProto primal_status = 1

  Status for the primal problem.

• FeasibilityStatusProto dual_status = 2

  Status for the dual problem (or for the dual of a continuous relaxation).

• bool primal_or_dual_infeasible = 3

  If true, the solver claims the primal or dual problem is infeasible, but it does not know which (or if both are infeasible). Can be true only when primal_problem_status = dual_problem_status = kUndetermined. This extra information is often needed when preprocessing determines there is no optimal solution to the problem (but can't determine if it is due to infeasibility, unboundedness, or both).

A single quadratic constraint of the form: lb <= sum{linear_terms} + sum{quadratic_terms} <= ub. If a variable involved in this constraint is deleted, it is treated as if it were set to zero.

Used in: ModelProto, QuadraticConstraintUpdatesProto

• optional SparseDoubleVectorProto linear_terms = 1

  Terms that are linear in the decision variables. In addition to requirements on SparseDoubleVectorProto messages we require that: * linear_terms.ids are elements of VariablesProto.ids. * linear_terms.values must all be finite and not-NaN. Notes: * Variable ids omitted have a corresponding coefficient of zero. * linear_terms.values can be zero, but this just wastes space.

• optional SparseDoubleMatrixProto quadratic_terms = 2

  Terms that are quadratic in the decision variables. In addition to requirements on SparseDoubleMatrixProto messages we require that: * Each element of quadratic_terms.row_ids and each element of quadratic_terms.column_ids must be an element of VariablesProto.ids. * The matrix must be upper triangular: for each i, quadratic_terms.row_ids[i] <= quadratic_terms.column_ids[i]. Notes: * Terms not explicitly stored have zero coefficient. * Elements of quadratic_terms.coefficients can be zero, but this just wastes space.

• double lower_bound = 3

  Must have value in [-inf, inf), and be less than or equal to `upper_bound`.

• double upper_bound = 4

  Must have value in (-inf, inf], and be greater than or equal to `lower_bound`.

• string name = 5

  Parent messages may have uniqueness requirements on this field; e.g., see ModelProto.quadratic_constraints and QuadraticConstraintUpdatesProto.new_constraints.

Updates to quadratic constraints; only addition and deletion, no support for in-place constraint updates.

Used in: ModelUpdateProto

• repeated int64 deleted_constraint_ids = 1

  Removes quadratic constraints from the model. Each value must be in [0, max(int64)). Values must be in strictly increasing order. Applies only to existing quadratic constraint ids that have not yet been deleted.

• map<int64, QuadraticConstraintProto> new_constraints = 2

  Add new quadratic constraints to the model. All keys must be in [0, max(int64)), and must be greater than any ids used in the initial model and previous updates. All nonempty names should be distinct from existing names and each other.

A single second-order cone constraint of the form: ||`arguments_to_norm`||_2 <= `upper_bound`, where `upper_bound` and each element of `arguments_to_norm` are linear expressions. If a variable involved in this constraint is deleted, it is treated as if it were set to zero.

Used in: ModelProto, SecondOrderConeConstraintUpdatesProto

• optional LinearExpressionProto upper_bound = 1

• repeated LinearExpressionProto arguments_to_norm = 2

• string name = 3

  Parent messages may have uniqueness requirements on this field; e.g., see `ModelProto.second_order_cone_constraints` and `SecondOrderConeConstraintUpdatesProto.new_constraints`.

Updates to second-order cone constraints; only addition and deletion, no support for in-place constraint updates.

Used in: ModelUpdateProto

• repeated int64 deleted_constraint_ids = 1

  Removes second-order cone constraints from the model. Each value must be in [0, max(int64)). Values must be in strictly increasing order. Applies only to existing second-order cone constraint ids that have not yet been deleted.

• map<int64, SecondOrderConeConstraintProto> new_constraints = 2

  Add new second-order cone constraints to the model. All keys must be in [0, max(int64)), and must be greater than any ids used in the initial model and previous updates. All nonempty names should be distinct from existing names and each other.

A suggested starting solution for the solver. MIP solvers generally only want primal information (`variable_values`), while LP solvers want both primal and dual information (`dual_values`). Many MIP solvers can work with: (1) partial solutions that do not specify all variables or (2) infeasible solutions. In these cases, solvers typically solve a sub-MIP to complete/correct the hint. How the hint is used by the solver, if at all, is highly dependent on the solver, the problem type, and the algorithm used. The most reliable way to ensure your hint has an effect is to read the underlying solvers logs with and without the hint. Simplex-based LP solvers typically prefer an initial basis to a solution hint (they need to crossover to convert the hint to a basic feasible solution otherwise). TODO(b/183616124): Add hint-priorities to variable_values.

Used in: ModelSolveParametersProto

• optional SparseDoubleVectorProto variable_values = 1

  A possibly partial assignment of values to the primal variables of the problem. The solver-independent requirements for this sub-message are: * variable_values.ids are elements of VariablesProto.ids. * variable_values.values must all be finite.

• optional SparseDoubleVectorProto dual_values = 2

  A (potentially partial) assignment of values to the linear constraints of the problem. Requirements: * dual_values.ids are elements of LinearConstraintsProto.ids. * dual_values.values must all be finite.

What is included in a solution depends on the kind of problem and solver. The current common patterns are 1. MIP solvers return only a primal solution. 2. Simplex LP solvers often return a basis and the primal and dual solutions associated to this basis. 3. Other continuous solvers often return a primal and dual solution solution that are connected in a solver-dependent form. Requirements: * at least one field must be set; a solution can't be empty.

Used in: SolveResultProto

• optional PrimalSolutionProto primal_solution = 1

• optional DualSolutionProto dual_solution = 2

• optional BasisProto basis = 3

Feasibility of a primal or dual solution as claimed by the solver.

Used in: BasisProto, DualSolutionProto, PrimalSolutionProto

• SOLUTION_STATUS_UNSPECIFIED = 0

  Guard value representing no status.

• SOLUTION_STATUS_UNDETERMINED = 1

  Solver does not claim a feasibility status.

• SOLUTION_STATUS_FEASIBLE = 2

  Solver claims the solution is feasible.

• SOLUTION_STATUS_INFEASIBLE = 3

  Solver claims the solution is infeasible.

Parameters to control a single solve. Contains both parameters common to all solvers e.g. time_limit, and parameters for a specific solver, e.g. gscip. If a value is set in both common and solver specific field, the solver specific setting is used. The common parameters that are optional and unset or an enum with value unspecified indicate that the solver default is used. Solver specific parameters for solvers other than the one in use are ignored. Parameters that depends on the model (e.g. branching priority is set for each variable) are passed in ModelSolveParametersProto.

//////////////////////////////////////////////////////////////////////////// Parameters common to all solvers. ////////////////////////////////////////////////////////////////////////////

Used in: SolveRequest

• optional google.protobuf.Duration time_limit = 1

  Maximum time a solver should spend on the problem (or infinite if not set). This value is not a hard limit, solve time may slightly exceed this value. This parameter is always passed to the underlying solver, the solver default is not used.

• optional int64 iteration_limit = 2

  Limit on the iterations of the underlying algorithm (e.g. simplex pivots). The specific behavior is dependent on the solver and algorithm used, but often can give a deterministic solve limit (further configuration may be needed, e.g. one thread). Typically supported by LP, QP, and MIP solvers, but for MIP solvers see also node_limit.

• optional int64 node_limit = 24

  Limit on the number of subproblems solved in enumerative search (e.g. branch and bound). For many solvers this can be used to deterministically limit computation (further configuration may be needed, e.g. one thread). Typically for MIP solvers, see also iteration_limit.

• optional double cutoff_limit = 20

  The solver stops early if it can prove there are no primal solutions at least as good as cutoff. On an early stop, the solver returns termination reason NO_SOLUTION_FOUND and with limit CUTOFF and is not required to give any extra solution information. Has no effect on the return value if there is no early stop. It is recommended that you use a tolerance if you want solutions with objective exactly equal to cutoff to be returned. See the user guide for more details and a comparison with best_bound_limit.

• optional double objective_limit = 21

  The solver stops early as soon as it finds a solution at least this good, with termination reason FEASIBLE and limit OBJECTIVE.

• optional double best_bound_limit = 22

  The solver stops early as soon as it proves the best bound is at least this good, with termination reason FEASIBLE or NO_SOLUTION_FOUND and limit OBJECTIVE. See the user guide for more details and a comparison with cutoff_limit.

• optional int32 solution_limit = 23

  The solver stops early after finding this many feasible solutions, with termination reason FEASIBLE and limit SOLUTION. Must be greater than zero if set. It is often used get the solver to stop on the first feasible solution found. Note that there is no guarantee on the objective value for any of the returned solutions. Solvers will typically not return more solutions than the solution limit, but this is not enforced by MathOpt, see also b/214041169. Currently supported for Gurobi and SCIP, and for CP-SAT only with value 1.

• bool enable_output = 3

  Enables printing the solver implementation traces. The location of those traces depend on the solver. For SCIP and Gurobi this will be the standard output streams. For Glop and CP-SAT this will LOG(INFO). Note that if the solver supports message callback and the user registers a callback for it, then this parameter value is ignored and no traces are printed.

• optional int32 threads = 4

  If set, it must be >= 1.

• optional int32 random_seed = 5

  Seed for the pseudo-random number generator in the underlying solver. Note that all solvers use pseudo-random numbers to select things such as perturbation in the LP algorithm, for tie-break-up rules, and for heuristic fixings. Varying this can have a noticeable impact on solver behavior. Although all solvers have a concept of seeds, note that valid values depend on the actual solver. - Gurobi: [0:GRB_MAXINT] (which as of Gurobi 9.0 is 2x10^9). - GSCIP: [0:2147483647] (which is MAX_INT or kint32max or 2^31-1). - GLOP: [0:2147483647] (same as above) In all cases, the solver will receive a value equal to: MAX(0, MIN(MAX_VALID_VALUE_FOR_SOLVER, random_seed)).

• optional double absolute_gap_tolerance = 18

  An absolute optimality tolerance (primarily) for MIP solvers. The absolute GAP is the absolute value of the difference between: * the objective value of the best feasible solution found, * the dual bound produced by the search. The solver can stop once the absolute GAP is at most absolute_gap_tolerance (when set), and return TERMINATION_REASON_OPTIMAL. Must be >= 0 if set. See also relative_gap_tolerance.

• optional double relative_gap_tolerance = 17

  A relative optimality tolerance (primarily) for MIP solvers. The relative GAP is a normalized version of the absolute GAP (defined on absolute_gap_tolerance), where the normalization is solver-dependent, e.g. the absolute GAP divided by the objective value of the best feasible solution found. The solver can stop once the relative GAP is at most relative_gap_tolerance (when set), and return TERMINATION_REASON_OPTIMAL. Must be >= 0 if set. See also absolute_gap_tolerance.

• optional int32 solution_pool_size = 25

  Maintain up to `solution_pool_size` solutions while searching. The solution pool generally has two functions: (1) For solvers that can return more than one solution, this limits how many solutions will be returned. (2) Some solvers may run heuristics using solutions from the solution pool, so changing this value may affect the algorithm's path. To force the solver to fill the solution pool, e.g. with the n best solutions, requires further, solver specific configuration.

• LPAlgorithmProto lp_algorithm = 6

  The algorithm for solving a linear program. If LP_ALGORITHM_UNSPECIFIED, use the solver default algorithm. For problems that are not linear programs but where linear programming is a subroutine, solvers may use this value. E.g. MIP solvers will typically use this for the root LP solve only (and use dual simplex otherwise).

• EmphasisProto presolve = 7

  Effort on simplifying the problem before starting the main algorithm, or the solver default effort level if EMPHASIS_UNSPECIFIED.

• EmphasisProto cuts = 8

  Effort on getting a stronger LP relaxation (MIP only), or the solver default effort level if EMPHASIS_UNSPECIFIED. NOTE: disabling cuts may prevent callbacks from having a chance to add cuts at MIP_NODE, this behavior is solver specific.

• EmphasisProto heuristics = 9

  Effort in finding feasible solutions beyond those encountered in the complete search procedure (MIP only), or the solver default effort level if EMPHASIS_UNSPECIFIED.

• EmphasisProto scaling = 10

  Effort in rescaling the problem to improve numerical stability, or the solver default effort level if EMPHASIS_UNSPECIFIED.

• optional GScipParameters gscip = 12

• optional GurobiParametersProto gurobi = 13

• optional glop.GlopParameters glop = 14

• optional sat.SatParameters cp_sat = 15

• optional pdlp.PrimalDualHybridGradientParams pdlp = 16

• optional OsqpSettingsProto osqp = 19

  Users should prefer the generic MathOpt parameters over OSQP-level parameters, when available: * Prefer SolveParametersProto.enable_output to OsqpSettingsProto.verbose. * Prefer SolveParametersProto.time_limit to OsqpSettingsProto.time_limit. * Prefer SolveParametersProto.iteration_limit to OsqpSettingsProto.iteration_limit. * If a less granular configuration is acceptable, prefer SolveParametersProto.scaling to OsqpSettingsProto.

• optional GlpkParametersProto glpk = 26

• optional HighsOptionsProto highs = 27

• optional XpressParametersProto xpress = 28

Request for a unary remote solve in MathOpt.

• SolverTypeProto solver_type = 1

  Solver type to numerically solve the problem. Note that if a solver does not support a specific feautre in the model, the optimization procedure won't be successful.

• optional ModelProto model = 2

  A mathematical representation of the optimization problem to solve.

• optional SolverResourcesProto resources = 6

  Hints on resources requested for the solve.

• optional SolverInitializerProto initializer = 3

• optional SolveParametersProto parameters = 4

  Parameters to control a single solve. The enable_output parameter is handled specifically. For solvers that support messages callbacks, setting it to true will have the server register a message callback. The resulting messages will be returned in SolveResponse.messages. For other solvers, setting enable_output to true will result in an error.

• optional ModelSolveParametersProto model_parameters = 5

  Parameters to control a single solve that are specific to the input model (see SolveParametersProto for model independent parameters).

Response for a unary remote solve in MathOpt.

• oneof status_or

  Either `result` or `status` must be set. This is equivalent to C++ StatusOr<SolveResult>.

  • SolveResultProto result = 1

    Description of the output of solving the model in the request.

  • StatusProto status = 3

    The absl::Status returned by the solver. It should never be OK when set.

• repeated string messages = 2

  If SolveParametersProto.enable_output has been used, this will contain log messages for solvers that support message callbacks.

The contract of when primal/dual solutions/rays is complex, see termination_reasons.md for a complete description. Until an exact contract is finalized, it is safest to simply check if a solution/ray is present rather than relying on the termination reason.

Used in: SolveResponse

• optional TerminationProto termination = 2

  The reason the solver stopped.

• repeated SolutionProto solutions = 3

  The general contract for the order of solutions that future solvers should implement is to order by: 1. The solutions with a primal feasible solution, ordered by best primal objective first. 2. The solutions with a dual feasible solution, ordered by best dual objective (unknown dual objective is worst) 3. All remaining solutions can be returned in any order.

• repeated PrimalRayProto primal_rays = 4

  Directions of unbounded primal improvement, or equivalently, dual infeasibility certificates. Typically provided for TerminationReasonProtos UNBOUNDED and DUAL_INFEASIBLE

• repeated DualRayProto dual_rays = 5

  Directions of unbounded dual improvement, or equivalently, primal infeasibility certificates. Typically provided for TerminationReasonProto INFEASIBLE.

• optional SolveStatsProto solve_stats = 6

  Statistics on the solve process, e.g. running time, iterations.

• oneof solver_specific_output

  • GScipOutput gscip_output = 7

  • OsqpOutput osqp_output = 8

  • SolveResultProto.PdlpOutput pdlp_output = 9

Used in: SolveResultProto

• optional pdlp.ConvergenceInformation convergence_information = 1

Used in: SolveResultProto

• optional google.protobuf.Duration solve_time = 1

  Elapsed wall clock time as measured by math_opt, roughly the time inside Solver::Solve(). Note: this does not include work done building the model.

• double best_primal_bound = 2

  Deprecated in favor of ObjectiveBoundsProto.primal_bound found in TerminationProto.

• double best_dual_bound = 3

  Deprecated in favor of ObjectiveBoundsProto.dual_bound found in TerminationProto.

• optional ProblemStatusProto problem_status = 4

  The presence of problem_status in SolverStatsProto is deprecated in favor of the same ProblemStatusProto message found in TerminationProto.

• int64 simplex_iterations = 5

• int64 barrier_iterations = 6

• int64 first_order_iterations = 8

• int64 node_count = 7

This message contains solver specific data that are used when the solver is instantiated.

Used in: SolveRequest

• optional GurobiInitializerProto gurobi = 1

• optional XpressInitializerProto xpress = 3

This message is used to specify some hints on the resources a remote solve is expected to use. These parameters are hints and may be ignored by the remote server (in particular in case of solve in a local subprocess, for example). When using SolveService.Solve and SolveService.ComputeInfeasibleSubsystem, these hints are mostly optional as some defaults will be computed based on the other parameters. When using SolveService.StreamSolve these hints are used to dimension the resources available during the execution of every action; thus it is recommended to set them.

Used in: SolveRequest

• optional double cpu = 1

  The number of solver threads that are expected to actually execute in parallel. Must be finite and >0.0. For example a value of 3.0 means that if the solver has 5 threads that can execute we expect at least 3 of these threads to be scheduled in parallel for any given time slice of the operating system scheduler. A fractional value indicates that we don't expect the operating system to constantly schedule the solver's work. For example with 0.5 we would expect the solver's threads to be scheduled half the time. This parameter is usually used in conjunction with SolveParametersProto.threads. For some solvers like Gurobi it makes sense to use SolverResourcesProto.cpu = SolveParametersProto.threads. For other solvers like CP-SAT, it may makes sense to use a value lower than the number of threads as not all threads may be ready to be scheduled at the same time. It is better to consult each solver documentation to set this parameter. Note that if the SolveParametersProto.threads is not set then this parameter should also be left unset.

• optional double ram = 2

  The limit of RAM for the solve in bytes. Must be finite and >=1.0 (even though it should in practice be much larger).

The solvers supported by MathOpt.

Used in: SolveRequest

• SOLVER_TYPE_UNSPECIFIED = 0

• SOLVER_TYPE_GSCIP = 1

  Solving Constraint Integer Programs (SCIP) solver (third party). Supports LP, MIP, and nonconvex integer quadratic problems. No dual data for LPs is returned though. Prefer GLOP for LPs.

• SOLVER_TYPE_GUROBI = 2

  Gurobi solver (third party). Supports LP, MIP, and nonconvex integer quadratic problems. Generally the fastest option, but has special licensing.

• SOLVER_TYPE_GLOP = 3

  Google's Glop solver. Supports LP with primal and dual simplex methods.

• SOLVER_TYPE_CP_SAT = 4

  Google's CP-SAT solver. Supports problems where all variables are integer and bounded (or implied to be after presolve). Experimental support to rescale and discretize problems with continuous variables.

• SOLVER_TYPE_PDLP = 5

  Google's PDLP solver. Supports LP and convex diagonal quadratic objectives. Uses first order methods rather than simplex. Can solve very large problems.

• SOLVER_TYPE_GLPK = 6

  GNU Linear Programming Kit (GLPK) (third party). Supports MIP and LP. Thread-safety: GLPK use thread-local storage for memory allocations. As a consequence Solver instances must be destroyed on the same thread as they are created or GLPK will crash. It seems OK to call Solver::Solve() from another thread than the one used to create the Solver but it is not documented by GLPK and should be avoided. When solving a LP with the presolver, a solution (and the unbound rays) are only returned if an optimal solution has been found. Else nothing is returned. See glpk-5.0/doc/glpk.pdf page #40 available from glpk-5.0.tar.gz for details.

• SOLVER_TYPE_OSQP = 7

  The Operator Splitting Quadratic Program (OSQP) solver (third party). Supports continuous problems with linear constraints and linear or convex quadratic objectives. Uses a first-order method.

• SOLVER_TYPE_ECOS = 8

  The Embedded Conic Solver (ECOS) (third party). Supports LP and SOCP problems. Uses interior point methods (barrier).

• SOLVER_TYPE_SCS = 9

  The Splitting Conic Solver (SCS) (third party). Supports LP and SOCP problems. Uses a first-order method.

• SOLVER_TYPE_HIGHS = 10

  The HiGHS Solver (third party). Supports LP and MIP problems (convex QPs are unimplemented).

• SOLVER_TYPE_SANTORINI = 11

  MathOpt's reference implementation of a MIP solver. Slow/not recommended for production. Not an LP solver (no dual information returned).

• SOLVER_TYPE_XPRESS = 13

  Fico XPRESS solver (third party). Supports LP, MIP, and nonconvex integer quadratic problems. A fast option, but has special licensing.

Data for representing a single SOS1 or SOS2 constraint. If a variable involved in this constraint is deleted, it is treated as if it were set to zero.

Used in: ModelProto, SosConstraintUpdatesProto

• repeated LinearExpressionProto expressions = 1

  The expressions over which to apply the SOS constraint: * SOS1: At most one element takes a nonzero value. * SOS2: At most two elements take nonzero values, and they must be adjacent in the repeated ordering.

• repeated double weights = 2

  Either empty or of equal length to expressions. If empty, default weights are 1, 2, ... If present, the entries must be unique.

• string name = 3

  Parent messages may have uniqueness requirements on this field; e.g., see ModelProto.sos1_constraints and SosConstraintUpdatesProto.new_constraints.

Data for updates to SOS1 and SOS2 constraints; only addition and deletion, no support for in-place constraint updates.

Used in: ModelUpdateProto

• repeated int64 deleted_constraint_ids = 1

  Removes SOS constraints from the model. Each value must be in [0, max(int64)). Values must be in strictly increasing order. Applies only to existing SOS constraint ids that have not yet been deleted.

• map<int64, SosConstraintProto> new_constraints = 2

  Add new SOS constraints to the model. All keys must be in [0, max(int64)), and must be greater than any ids used in the initial model and previous updates. All nonempty names should be distinct from existing names and each other.

A sparse representation of a vector of basis statuses.

Used in: BasisProto

• repeated int64 ids = 1

  Must be sorted (in increasing ordering) with all elements distinct.

• repeated BasisStatusProto values = 2

  Must have equal length to ids.

A sparse representation of a vector of bools.

Used in: VariableUpdatesProto

• repeated int64 ids = 1

  Should be sorted (in increasing ordering) with all elements distinct.

• repeated bool values = 2

  Must have equal length to ids.

A sparse representation of a matrix of doubles. The matrix is stored as triples of row id, column id, and coefficient. These three vectors must be of equal length. For all i, the tuple (row_ids[i], column_ids[i]) should be distinct. Entries must be in row major order. TODO(user): consider CSR.

Used in: ModelProto, ModelUpdateProto, ObjectiveProto, ObjectiveUpdatesProto, QuadraticConstraintProto

• repeated int64 row_ids = 1

• repeated int64 column_ids = 2

• repeated double coefficients = 3

  May not contain NaN.

A sparse representation of a vector of doubles.

Used in: CallbackDataProto, CallbackResultProto, CallbackResultProto.GeneratedLinearConstraint, DualRayProto, DualSolutionProto, IndicatorConstraintProto, LinearConstraintUpdatesProto, ObjectiveProto, ObjectiveUpdatesProto, PrimalRayProto, PrimalSolutionProto, QuadraticConstraintProto, SolutionHintProto, VariableUpdatesProto

• repeated int64 ids = 1

  Must be sorted (in increasing ordering) with all elements distinct.

• repeated double values = 2

  Must have equal length to ids. May not contain NaN.

A sparse representation of a vector of ints.

Used in: ModelSolveParametersProto

• repeated int64 ids = 1

  Should be sorted (in increasing ordering) with all elements distinct.

• repeated int32 values = 2

  Must have equal length to ids.

This message allows to query/set specific parts of a SparseXxxxVector. The default behavior is not to filter out anything. A common usage is to query only parts of solutions (only non-zero values, and/or just a hand-picked set of variable values).

Used in: CallbackRegistrationProto, ModelSolveParametersProto

• bool skip_zero_values = 1

  For SparseBoolVectorProto "zero" is `false`.

• bool filter_by_ids = 2

  When true, return only the values corresponding to the IDs listed in filtered_ids.

• repeated int64 filtered_ids = 3

  The list of IDs to use when filter_by_ids is true. Must be empty when filter_by_ids is false. NOTE: if this is empty, and filter_by_ids is true, you are saying that you do not want any information in the result.

The streamed version of absl::Status.

Used in: SolveResponse

• int32 code = 1

  The status code, one of the absl::StatusCode.

• string message = 2

  The status message.

Configures if potentially bad solver input is a warning or an error. TODO(b/196132970): implement this feature.

• bool bad_parameter = 1

All information regarding why a call to Solve() terminated.

Used in: SolveResultProto

• TerminationReasonProto reason = 1

  Additional information in `limit` when value is TERMINATION_REASON_FEASIBLE or TERMINATION_REASON_NO_SOLUTION_FOUND, see `limit` for details.

• LimitProto limit = 2

  Is LIMIT_UNSPECIFIED unless reason is TERMINATION_REASON_FEASIBLE or TERMINATION_REASON_NO_SOLUTION_FOUND. Not all solvers can always determine the limit which caused termination, LIMIT_UNDETERMINED is used when the cause cannot be determined.

• string detail = 3

  Additional typically solver specific information about termination.

• optional ProblemStatusProto problem_status = 4

  Feasibility statuses for primal and dual problems. As of July 18, 2023 this message may be missing. If missing, problem_status can be found in SolveResultProto.solve_stats.

• optional ObjectiveBoundsProto objective_bounds = 5

  Bounds on the optimal objective value. As of July 18, 2023 this message may be missing. If missing, objective_bounds.primal_bound can be found in SolveResultProto.solve.stats.best_primal_bound and objective_bounds.dual_bound can be found in SolveResultProto.solve.stats.best_dual_bound

The reason a call to Solve() terminates.

Used in: TerminationProto

• TERMINATION_REASON_UNSPECIFIED = 0

• TERMINATION_REASON_OPTIMAL = 1

  A provably optimal solution (up to numerical tolerances) has been found.

• TERMINATION_REASON_INFEASIBLE = 2

  The primal problem has no feasible solutions.

• TERMINATION_REASON_UNBOUNDED = 3

  The primal problem is feasible and arbitrarily good solutions can be found along a primal ray.

• TERMINATION_REASON_INFEASIBLE_OR_UNBOUNDED = 4

  The primal problem is either infeasible or unbounded. More details on the problem status may be available in solve_stats.problem_status. Note that Gurobi's unbounded status may be mapped here.

• TERMINATION_REASON_IMPRECISE = 5

  The problem was solved to one of the criteria above (Optimal, Infeasible, Unbounded, or InfeasibleOrUnbounded), but one or more tolerances was not met. Some primal/dual solutions/rays be present, but either they will be slightly infeasible, or (if the problem was nearly optimal) their may be a gap between the best solution objective and best objective bound. Users can still query primal/dual solutions/rays and solution stats, but they are responsible for dealing with the numerical imprecision.

• TERMINATION_REASON_FEASIBLE = 9

  The optimizer reached some kind of limit and a primal feasible solution is returned. See SolveResultProto.limit_detail for detailed description of the kind of limit that was reached.

• TERMINATION_REASON_NO_SOLUTION_FOUND = 6

  The optimizer reached some kind of limit and it did not find a primal feasible solution. See SolveResultProto.limit_detail for detailed description of the kind of limit that was reached.

• TERMINATION_REASON_NUMERICAL_ERROR = 7

  The algorithm stopped because it encountered unrecoverable numerical error. No solution information is available.

• TERMINATION_REASON_OTHER_ERROR = 8

  The algorithm stopped because of an error not covered by one of the statuses defined above. No solution information is available.

Proto enum used in the unit tests of enums.h.

• TEST_ENUM_UNSPECIFIED = 0

• TEST_ENUM_FIRST_VALUE = 1

• TEST_ENUM_SECOND_VALUE = 3

Updates to existing variables in a ModelProto. Applies only to existing variables in a model, for new variables, see ModelUpdateProto.new_variables.

Used in: ModelUpdateProto

• optional SparseDoubleVectorProto lower_bounds = 1

  Updates ModelProto.variables.lower_bounds. Requirements: * lower_bounds.ids must be from ModelProto.variables.ids. * lower_bounds.values must be < infinity. * Unset values are unchanged.

• optional SparseDoubleVectorProto upper_bounds = 2

  Updates ModelProto.variables.upper_bounds. Requirements: * upper_bounds.ids must be from ModelProto.variables.ids. * upper_bounds.values must be > -infinity. * Unset values are unchanged.

• optional SparseBoolVectorProto integers = 3

  Updates ModelProto.variables.integers. Requirements: * integers.ids must be from ModelProto.variables.ids. * Unset values are unchanged.

As used below, we define "#variables" = size(VariablesProto.ids).

Used in: ModelProto, ModelUpdateProto

• repeated int64 ids = 1

  Must be nonnegative and strictly increasing. The max(int64) value can't be used.

• repeated double lower_bounds = 2

  Should have length equal to #variables, values in [-inf, inf).

• repeated double upper_bounds = 3

  Should have length equal to #variables, values in (-inf, inf].

• repeated bool integers = 4

  Should have length equal to #variables. Value is false for continuous variables and true for integer variables.

• repeated string names = 5

  If not set, assumed to be all empty strings. Otherwise, should have length equal to #variables. All nonempty names must be distinct. TODO(b/169575522): we may relax this.

Parameters used to initialize the Xpress solver.

Used in: SolverInitializerProto

• optional bool extract_names = 1

Xpress specific parameters for solving. See https://www.fico.com/fico-xpress-optimization/docs/latest/solver/optimizer/HTML/chapter7.html for a list of possible parameters (called "controls" in Xpress). In addition to all Xpress controls, the following special parameters are also supported: "EXPORT_MODEL"(string) If present then the low level Xpress model (the XPRSprob instance) is written to that file right before XPRSoptimize() is called. This can be useful for debugging. "FORCE_POSTSOLVE"(int) If set to a non-zero value then the low-level code will call XPRSpostsolve() right after calling XPRSoptimize(). If not set or set to zero then calling XPRSpostsolve() is delayed to the latest possible point in time to enable incremental solves. "STOP_AFTER_LP"(int) If set to a non-zero value then the solve will be stopped right after solving the root relaxation. This is the same as passing the ' l' (ell) flag to XPRSoptimize() and stops the process earlier than a limit like MAXNODE=0. Example use: XpressParameters xpress; xpress.param_values["BarIterLimit"] = "10"; Parameters are applied in the following order: * Any parameters derived from ortools parameters (like LP algorithm). * param_values in iteration order (insertion order).

Used in: SolveParametersProto

• repeated XpressParametersProto.Parameter parameters = 1

Used in: XpressParametersProto

• string name = 1

• string value = 2