- Installing SolverTable
- Uninstalling SolverTable
- An example file
- Running SolverTable
- SolverTable Difficulties

**Figure 1**

**Figure 2**

The next dialog box, shown in Figure 3, requires you to specify the
input cell, the input values (which are assumed to be in regular increments),
the output cells, and a location for the table. Note that range names can
be used if they exist. The add-in checks your entries in this dialog box
for "obvious" errors. For example, the input cell should not contain a
formula or a label, the output range should not contain the input cell,
the table location shouldn't write over existing values (unless you say
it is OK to do so), and so on. However, we won't guarantee that it checks
for *everything*, so be careful when making these entries. Be especially
careful that you choose a location for the table that doesn't write over
any information you don't want to lose (even though you'll be warned if
you try to do so).

**Figure 3**

The table itself appears in Figure 4. (We've added the heading in row
1 manually.) The small red triangles are Excel comments that SolverTable
automatically adds to a number of cells. For example, the comment in cell
I4 reminds what the input cell is (in this case, D21). The comments in
column J are the Solver messages you normally see after running Solver.
For this example, they all contain the message you *hope *to see:
"Solver found a solution. All constraints and optimality conditions are
satisfied." However, if there is no feasible solution, say, then the comment
will alert you to this. Note that unlike an Excel data table, SolverTable
does not put *formulas* at the top of the table (in row 3 of the figure),
because this wouldn't make sense. However, it does put the cell addresses
of the output cells. This way, you can remember which outputs are being
reported.

**Figure 4**

**Figure 5**

SolverTable then creates as many tables as there are output cells (in a vertical direction), as shown in Figure 6. Note that each cell in a table corresponds to a Solver run. For example, we see that when there are 4000 labor hours available and the wage rate is $4 per hour, the optimal profit is $25,200 (top table) and all 4000 labor hours are used (bottom table). Again, there are comments in selected cells. For example, the comments in cells I13 and J12 remind you that the input cells are D11 and B4. The comments in the body of each table report the Solver message, exactly as with one-way tables.

**Figure 6**

As with all Solver models, it is a good idea to take a close look at the answers and see whether they make sense. For example, in Figure 6 we see all zeros in column L. Does this make sense? Yes, it probably does. When the labor rate is $12 per hour and all other monetary inputs stay constant, labor is evidently too expensive for the company to make a profit. So it produces nothing!

**Figure 7**

We can now do a one-way sensitivity analysis on this change factor, using the settings in Figure 8. The corresponding table appears in Figure 9.

**Figure 8**

**Figure 9**

As another example, suppose you want to keep track of a *function*
of several cells in the model. For example, suppose you want to keep track
of the maximum number of frames of any single type produced, that is, the
maximum of the changing cell values. You can't select this as an output
*directly* because it doesn't appear anywhere in the model. But the
solution is simple: Create a formula for it in some unused cell, and then
specify this cell as an output cell.

SolverTable automatically checks for this error message. If Solver gives
it, then SolverTable *reruns* Solver (for this problem) with the Assume
Linear Model box *unchecked* and reports the result. However, to let
you know that all of this happened, the corresponding cells of the table
are colored yellow, and the comments in these cells describe the problem.
An example we encountered appears in Figure 10. This model is indeed linear.
However, when we formed the one-way table, Solver thought the model was
*not *linear for input values of 0.80 and 1.00, even though it agreed
that it was linear for input values of 0.90 and 1.10. Similarly, for the
two-way table, it thought the model was not linear for 2 of the 16 input
combinations. This is clearly strange behavior, but it happens fairly frequently.
At least, SolverTable provides a solution (using a nonlinear algorithm)
rather than the annoying "conditions for linear model are not satisfied"
Solver message.

**Figure 10**