Restrict back to back same location job

[jie31best]

Hi @sutirtha_kayal,

I haven’t tried out your implemented constraint, but I think a possible reason could be that the ruin phase breaks the constraint.

Your constraint controls the insertion phase and makes sure that (if all jobs are to be inserted, e.g., when building initial solution) AAB is not allowed (A and B indicate locations) while ABA is. However, in the ruin phase, it is possible that the B is ruined from ABA and it leaves AA for the insertion phase, which then inserts B after the second A so that cost is minimized and results in a sequence of AAB. Thus in the final solution your constraint is broken.

Some related posts can be found here:

When the ruin process breaks the constraints

To those who are interested, As we have discussed in the following two posts, for some constraints, the ruin process could break them and thus they might not apply in the final solution. At that time, we thought we would have to implement a custom ruin strategy to resolve this issue. Today when replying to a new post, I realize we do not need to do that. Instead, an InsertionStartsListener or a RuinListener will be good enough. In the listener, we will need to make sure that, when the inse…

Idea: hard constraints and ruin strategies

This is not a proposal at the moment, only an idea to think of. The problem with many of the hard constraints that ruin doesn’t honor them. The most common case when two or more jobs are interrelated by the constraint, because the ruin strategies removes the jobs individually. Detecting these inter-job relations can’t be fully automated (or not cost effective) because of the freedom of the constraint implementation. An easy solution would be if the hard constraint could do the detection itself…

Best regards,
He