1. Sanity checking the solution
Understanding that each problem we model in PuLP has its own unique set of circumstances, in this lesson we review a strategy for evaluating the validity of our model's solution.
2. Sanity checking strategy
After solving the PuLP model, here we lay out a process for sanity checking our model's solution. In the process described, there are two questions. The first looks if PuLP found an optimal solution to our model. The second asks if that solution is within a reasonable range. So, let's review these questions.
3. Check the model status
In a previous lesson we discussed how to print the model status and the meaning of the different status types. However, at this point when reviewing the status, anything besides a status of Optimal is likely a red flag that we do not have a valid solution to the model.
Knowing the meaning behind each status will allow us to focus our efforts to improve models which are not optimal. For example, a status of Infeasible suggest that we should take a closer look at our constraints. It is possible there was an error in the data, in the type of constraint applied, or just a simple coding error.
Pay special attention to models with an Undefined status, because this may be the best solution available. For relatively simple problems the models can be solved Optimally. However, there are some problems which take too long to solve optimally, and heuristics are used which do not guarantee an optimal solution. For these situations the model status is likely to be Undefined. We should carefully check that we are correctly modeling the problem. For example, modeling a decision variable as an integer when it should be continuous can cause an Undefined model status.
4. Check if results are within expectations
After we have reviewed the model status then we should check that the values of the decision variables and objective are within their expected ranges. This is more of an art than exact science. The expected range is built on our knowledge and understanding of the problem we are modeling.
If the decision variables and objective are in their expected range then we are done and we can consider our results a valid solution.
If not, then we should review our modeling process. Tracking down the source of the issue can sometimes be difficult. Areas to review should include our Python code, and data. For example, if our Python code overlooks including all of the costs for the objective function, because the coding was complex, then it's possible our objective value will be outside of the expected range.
In addition to reviewing the Python code and data we can review the PuLP model specifications.
5. Write LP
The PuLP writeLP method will write the model specifications to a file. You just need to provide a filename.
It will output in an easy to read form, the name of the problem you gave when you first initialized the model, the objective function we are maximizing or minimizing, the models constraints, and decision variables.
6. Code example
This is an example output of the writeLP method applied to get a simple production planning problem for two products over three months. We first see the objective function we are minimizing and the model constraints.
Next, listed under Bounds we see the constraint of our decision variables.
Lastly, we see our list of decision variables. This information can be useful in tracking down problems.
7. Summary
In summary, we looked at a strategy for checking our model. It includes checking the model status and that the solution is inside the expected range. Finally, if needed we can use writeLP to check the model specification.
8. Practice time!
Practice time!