Although relatively little used, semi-continuous variables are one of the most elegant integer programming constructs, and one which works very well. They provide a direct means of eliminating fiddly quantities from a solution, giving effect to the instruction: "either do something seriously or don't do it at all". This is particularly useful where the true cost of an activity is as shown in the graph, i.e. cost is generally proportional to the level of activity, but there are diseconomies of scale if a very small amount is used. The semi-continuous variable is used to exclude the region between 0 and 10 in which the diseconomies of scale apply. Figure 1: Semi-continuous Costs semi-continuous upper bound,
U'. This means that x takes the value 0 or any value between 1 and U'.
As a consequence, if you wish to change a continuous variable in your
model to be semi-continuous, you cannot simply specify a lower bound L
below which it becomes semi-continuous. Instead you must modify the
formulation to scale the variable x so that the semi-continuous lower
bound is 1.Another use of semi-continuous variables is in scheduling models. Here it enables you to ensure that a model incurs the fixed cost of carrying out an activity without going on to fit activities together in an optimum combination (as in a knapsack problem). Consider a problem where we are running a depot and must resupply it every so often. There are several options for how we resupply it, with economies of scale for the larger modes of transport. We are concerned primarily with the next month, but wish to ensure that we don't achieve an "optimum" solution for the forthcoming month at the expense of stoking up problems for the future. The continuous solution will be to resupply the depot using the largest mode of transport. If the depot's consumption is small, this will expressed as a fraction of a delivery. But either a delivery is being proposed within the next month or it is not. And if there is no delivery, the depot will run out. So there is a binary decision as to whether there should be a delivery or not. On the other hand, once the model has decided to make a delivery, there is a sensible interpretation which can be placed on a non-integer number of deliveries greater than 1, say r. It is that deliveries should be made that number of times per month, i.e. every 30/r days. Further, this is a more realistic solution than would be obtained if one were to seek a wholly integer solution. For in that case, the model might decide that 1 delivery by the largest (and most economical) mode of transport was insufficient but that 2 were too much. It might then propose 2 visits by a smaller mode of transport, which is a much less attractive solution. |

LP Training > 5. Integer Programming >