Optimization models can result in infeasibilities for many reasons. Here are some common scenarios to help you track down and address sources of infeasibilities in your model.
Infeasibilities are one of the most common modeling challenges that Woodstock users face, and there is a myriad of different possible causes for them. While infeasibilities present a great opportunity to learn more about your model, they can also significantly slow down workflow, and can be especially stressful around tight deadlines. Learn about three common causes of infeasibilities we have seen while developing models or assessing client models.
The constraint portion of the Optimize section is the most obvious and intuitive place to start looking for the cause of an infeasibility. Constraints limit the model’s solution space, and when they impose limits that the model simply cannot stay within, the model becomes infeasible.
There are two main types of constraint inconsistencies that can cause infeasibilities:
Upper and/or lower bounds cannot be met
In this situation, the model has been constrained to either limit the maximum value, minimum value, or both, of a given output during one or more periods. A common example would be a model with minimum harvest volume constraints that cannot be sustained by its yields.
Two or more constraints in direct conflict
In this situation, each individual constraint in the model can be met alone, however, when run together, they conflict and become infeasible. There are countless ways in which this could happen, and below are two straightforward examples:
Minimum harvest volume in period 1, and 10% even flow constraint across all periods. If the period 1 harvest volume is set too high, the model’s yields cannot sustain the additional 10% even flow constraint. This could be solved by beginning the even flow in period 2 or by reducing the initial harvest volume constraint.
Minimum harvest volume in each period, and maximum percentage of harvest volume from clearcutting. In this case, the model has the yields to sustain the minimum harvest volume but cannot generate at least half of the harvest volume from alternative harvests – such as selection cuts and shelterwoods – as they do not produce as much volume as clearcuts do.
The best way to determine if constraint inconsistencies are causing an infeasibility would be to run the model without any constraints, and then gradually layer the constraints back in, either in small groups, or one at a time. Keep in mind that there may be interactions between constraints, so just because removing one constraint allows the model run, does not mean that that was the only constraint contributing to the infeasibility. Always think about how constraints may relate to one another.
Another great way to identify problematic constraints is the use of goals, which will be further explained in an upcoming blog post, stay tuned!
The LpSchedule, which forces Woodstock to perform specific actions at specific times, is another common, yet often unexpected source of infeasibilities. Given that its actions are manually imposed, there is no guarantee that its output production will adhere to constraints.
For example, in a model with minimum and maximum bounds on harvest volumes, the actions forced by the LpSchedule may produce more volume than these constraints allow. As a result, the constraints are broken, and the model becomes infeasible.
The most reliable way to see if the LpSchedule is responsible for an infeasibility is to deactivate the LpSchedule and re-optimize your model. You can further finesse this strategy by commenting out sections or specific lines of the LpSchedule to identify the problem. From there, you can adjust the LpSchedule or constraints to resolve the infeasibility.
Another approach would be to delete the existing Schedule and copy and paste the LpSchedule into the empty Schedule section. Then playback the model ( /F10) and examine the values of all outputs used in constraints. If some of these outputs have values that violate constraints, you have discovered your infeasibility.
Allocation Optimizer and Capacity Issues
A third common source of model infeasibilities are imbalances related to the supply chain (products and destinations). Models with Allocation Optimizer are subject to additional rules surrounding destination volumes and products. Below is a breakdown of five different types of capacity issues related to these rules.
1. Products/by-products that are not accepted at any destination
In this situation, a product is produced in a harvest unit or at a destination, however, there is no destination configured to accept this product. For example, a harvest unit produces douglas-fir, red cedar, and western hemlock logs, but the destinations in the model only accept douglas-fir and red cedar. If the model is forced to harvest such units, whether through the LpSchedule or through constraints, then the model will be infeasible. It is noteworthy that this issue may not result in an infeasibility, as the model may choose to bypass any units that produce unaccepted products. If the model chooses to ignore these units, it may then impact harvest volumes, causing a separate infeasibility.
2. Specific product source missing
If there is a destination that requires a certain volume of a specific product, but that product is not produced by the model, the model will become infeasible. This could stem from an error/omission in the yield data or in the Allocation Optimizer section where products are declared.
3. Crew Capacity
This instance only applies to harvest crew scheduling models that use Woodstock Scheduler. This would happen if harvest crew productivity values in the input data are too low to produce the amount of volume needed to meet destination demands. These values could be increased to test if this was the case.
4. Not enough destination capacity to handle woodflow demands
If a model is constrained to produce a minimum amount of volume over the planning horizon, but this volume exceeds the maximum capacity of all destinations combined, there will excess volume that cannot be accepted at destinations. This will make a model infeasible.
5. Not enough operable inventory to meet woodflow demands
This occurrence is the inverse to the previous capacity issue, where the cumulative total of all destination demands exceeds the amount of volume that the model can produce. Therefore, destination demands, which act as constraints, cannot be met, and the model is infeasible.
Remsoft employs a methodology to accommodate capacity issues 4 and 5 above, wherein the model includes an extra supply of all products (Reserve) and an extra destination accepting all products (Overflow). The Reserve and Overflow do not represent “real” product volume and destination capacity, they only exist to prevent infeasibilities caused by insufficient product inventory or destination capacity, respectively. Volume taken from Reserve or sent to Overflow is heavily penalized, so the model will only make this choice to prevent an infeasibility. Observing the volume coming from Reserve or being sent to Overflow provides a precise look at inventory and destination issues, which is far more informative than an infeasibility dialog.
There are many places to look when dealing with a troublesome infeasibility, some obvious, and some not. We hope that this information will help to advance your Woodstock expertise, and ensure your next infeasibility is a little less of a headache.