Especially with scheduling models, solutions tend to differ widely from one run to the next. Often this is the case without a significant impact on the objective. See also: http://yetanothermathprogrammingconsultant.blogspot.com/2009/11/persistency-in-math-programming-models.html.
Currently I am involved in developing a MIP based scheduling tool for TV advertisements. It is interesting to see that the original home-brew scheduling software (I am supposed to “beat” this existing system) actually has facilities to achieve persistency (without using this term). The conclusion is: this is a problem real users observe and we better make sure this is also handled by our implementation.
This can be a particular issue when changes (such as shifts in a production schedule) cause stress to the system. The answer I used to suggest to classes was to add a change-cost term to the objective, so that you penalize deviation from current/recent practice (but not enough to prevent a switch to a truly superior solution). Of course, it can be a bit of a challenge to assess the weight to apply to the change penalty, but it seems better than ignoring the change cost.
ReplyDelete