# Multiple Scenarios#

When solving an optimization model, it is often useful to understand the sensitivity of the computed solution to changes in the inputs. How would profits be affected if the price of a particular raw material increased significantly? Would I still be able to satisfy customer orders if one of my machines broke down? The most general form of this problem would fall into the domain of stochastic or robust optimization, but those fields bring significant complexity with them. The Gurobi Optimizer includes scenario analysis features that have a much more modest goal: to allow the user to specify a set of scenarios, and to compute optimal solutions for all of these scenarios as quickly as possible. These solutions often provide significant insight into how the solution would change as inputs vary.

## Definition of a Multi-Scenario Model#

Before diving into the details of working with multiple scenarios, we
first need to explain exactly what we mean by the term. Let us start by
claiming that it only makes sense to consider a set of models as being
different scenarios for the same underlying model if they have a lot in
common. They should definitely share the same set of variables. They
should also have similar sets of constraints and similar objectives. In
our approach, scenarios are described as a set of changes from a single
`base`

model. More specifically, scenarios can only modify model
features that are present in the base model. We should add that other
modifications, including addition and deletion of variables or
constraints, can be achieved through the clever use of various
tricks. For now, though, it is best
to think of scenarios as being small variations on the same base.

What variations do we allow from this base model? Scenarios can differ in the following attributes:

Linear objective function coefficients.

Variable lower and upper bounds.

Constraint right-hand side values.

A single scenario can have multiple changes from the base, so for example you could change an objective coefficient, two variable bounds, and a right-hand side value in the same scenario.

After you have defined a set of scenarios (the specific mechanics for
doing so will be described shortly),
the next step is to find solutions for all of the scenarios. A single
call to the standard Gurobi `optimize`

method is all that is needed.
This will of course be much more expensive than finding an optimal
solution for a single model, but our goal is for it to be faster and
more convenient than formulating and solving separate models for each
scenario.

## Specifying Multiple Scenarios#

Your first step in building a multi-scenario model is to modify the
NumScenarios attribute to indicate how many scenarios you would
like to consider. Once you have changed this attribute, you can describe the
different scenarios by changing various scenario-related attributes (listed
below). When you later call `optimize`

on a multi-scenario model (a model
where NumScenarios is greater than 0), the solver will try to find
optimal solutions for all specified scenarios. Note that it will *not* try to
find a solution for the base model.

Variations in the different scenarios are expressed through a set of four attributes:

The first three are variable attributes, and the last is a linear constraint attribute. You can give each scenario a name through the ScenNName attribute (a model attribute).

You use the ScenarioNumber parameter to modify scenario
attributes for a specific scenario. Scenarios are numbered `0`

through
`NumScenarios-1`

. To give an example, to create a model where binary
variable \(x\) is fixed to `0`

and `1`

in two scenarios, you
would:

Set the NumScenarios attribute to 2, to indicate that your model has two scenarios.

Set the ScenarioNumber parameter to 0, to indicate that you would first like to modify scenario attributes for scenario 0.

Set the ScenNUB attribute for variable \(x\) to 0 (to fix the binary variable to zero in this scenario).

Set the ScenarioNumber parameter to 1, to move on to scenario 1.

Set the ScenNLB attribute for variable \(x\) to 1 (to fix the binary variable to one in this scenario).

You query scenario attributes in a similar manner: set the ScenarioNumber parameter to choose the scenario you would like to query, and then use the appropriate attribute query routine to obtain the desired attribute values (consult our Attribute Examples for examples).

Note that unmodified scenario attributes take a special value of
`GRB.UNDEFINED`

. If you modified a scenario attribute and would like
to revert that modification, you can set the attribute back to
`GRB.UNDEFINED`

.

You can change the number of scenarios in your model as many times as you like (by modifying the NumScenarios attribute). When you increase the count, new empty scenarios are created (an empty scenario is a scenario with no changes from the base model). When you decrease the count, existing scenarios are discarded. When you set the count to zero, the model is no longer treated as a multi-scenario model.

We have extended the LP and MPS file formats, so writing a model with multiple scenarios to a file will capture those scenarios. Similarly, if you read a model file that contains multiple scenarios, then NumScenarios and the various scenario attributes will capture the scenarios stored in the file. See the file format section for details.

## Logging#

When solving a multi-scenario model, logging is somewhat different from standard MIP logging. You should consult this section for details.

## Retrieving Solutions for Multiple Scenarios#

Your first step in retrieving the solutions computed by an `optimize`

call
on a multi-scenario model is to query the Status attribute. A
status of OPTIMAL indicates that optimal solutions
were found (subject to tolerances) for all scenarios that have feasible
solutions, and that the other scenarios were determined to be infeasible. If
all scenarios were found to be infeasible, the status will be
INFEASIBLE. If any scenario is unbounded, the status
will be UNBOUNDED. An early termination status code
(e.g., TIME_LIMIT) indicates that the outcomes may
vary across the different scenarios, and you will have to look at individual
scenarios for more information.

Results for individual scenarios can be found in three attributes:

ScenNObjVal: The objective value for the solution for scenario number \(n\).

ScenNObjBound: The best known bound on the optimal objective value for scenario number \(n\).

ScenNX: The solution vector for scenario number \(n\).

The ScenNObjVal and ScenNObjBound attributes are model attributes, while ScenNX is a variable attribute. Again, use the ScenarioNumber parameter to select the scenario you’d like to query.

If your `optimize`

call terminated early, you should use the
ScenNObjBound attribute to interpret the results. This attribute
provides a bound on the optimal objective value for the selected scenario
(much like ObjBound provides a bound for a single model). For
example, if ScenNObjVal is 100 for a scenario and
ScenNObjBound is 90 (assuming minimization), then you have a
solution with a 10% optimality gap for that scenario.

You can also query the ObjVal and ObjBound attributes for a multi-scenario model. The former gives the best objective value for any solution found in any scenario. The latter provides a lower bound on the objective value for any solution that was not found.

Note that ScenNObjVal and ScenNObjBound are computed using the objective function for the corresponding scenario, which you may have changed from the base model.

If you query the ScenNX attribute and no feasible solution has been
found for that scenario, you will get a `DATA_NOT_AVAILABLE`

error.

## Tips and Tricks#

Through clever use of the features provided in the multi-scenario interface, it is actually possible to do a lot more than it may first appear.

### Adding or Deleting Variables or Constraints#

The multi-scenario interface provides no way to add or remove variables
or constraints in a scenario, but the same effect can be achieved by
changing variable bounds and constraint right-hand side values. To
remove a variable in a scenario, simply change its lower and upper
bounds to zero. To add a variable, set its bounds to zero in the base
model and change them to their true values in the scenario. To remove a
less-than constraint, change the right-hand-value in the scenario to
`GRB.INFINITY`

. To add one, set its right-hand side to
`GRB.INFINITY`

in the base model and change it to its true value in
the scenario.

Changing the sense of a constraint can also be done using similar
tricks. For example, you can transform an equality constraint in the
base model into an inequality in a scenario by splitting the equality
into a pair of inequalities. The right-hand side values for both
inequalities in the base model would be equal to the true value in the
equality. The right-hand side value on one of the two inequalities can
then be relaxed to `GRB.INFINITY`

in the scenario.

You can also change the type of a variable. For example, to transform an integer variable in the base model into a continuous variable in a scenario, you can add both variables in the base model, along with a split equality constraint that sets them equal to each other. That equality constraint could then be relaxed in the scenario (using the techniques just described).

This isn’t meant to be an exhaustive list of all of the ways that you can use supported multi-scenario features to achieve seemingly unsupported outcomes. The set of building blocks that we have provided can be assembled in a variety of different ways.

If all scenarios in your multi-scenario model are infeasible, your
`optimize`

call will produce an INFEASIBLE (or
INF_OR_UNBD) status code. While you can’t compute an
IIS on a multi-scenario model, you can extract individual scenarios as Gurobi
model objects using the `singleScenarioModel`

method (see below) and then
compute an IIS on each scenario individually.

### Solving The Base Model#

As noted earlier, an `optimize`

call on a multi-scenario model will
not solve the base model. If you’d like to solve that model too, include
an empty scenario among your scenarios.

### Extracting One Scenario#

If you’d like to extract one scenario from a multi-scenario model, you
can use the `singleScenarioModel`

method (in
`C`

,
`C++`

,
`Java`

,
`.NET`

, and
`Python`

).

### Performance Considerations#

While it may appear to be important to minimize the number of scenarios in your model, note that some scenarios are trivial to solve and thus have no impact on overall solution cost. The main thing to keep in mind is that, if (1) the solution for one scenario is feasible for another scenario, and (2) the bounds and right-hand side values for the first scenario are never tighter than the bounds for the other scenario, then the optimal solution for the first scenario is also optimal for the other scenario. This means that some scenarios won’t increase solution cost significantly.

## Limitations and Additional Considerations#

We should note a few additional considerations for solving multi-scenario models.

Nearly any model can serve as the base model in a multi-scenario model. The base model can be continuous or discrete, and it can contain quadratic constraints, general constraints, SOS constraints, semi-continuous variables, etc. One important exception is multiple objectives; a multi-scenario model can only have a single objective.

The IsMIP attribute will always be 1 for a multi-scenario model, even if the model is otherwise continuous.

Multi-scenario models can have lazy constraints, specified either through a user callback or through the Lazy attribute. Those that are provided through a callback must be valid across all scenarios. Those that are specified through the Lazy attribute can have different right-hand side values in different scenarios.

You can also add your own cutting planes to multi-scenario models through a user callback. Cuts must be valid across all scenarios.