A Listener corruption with PlanningListVariable

[kentbill]

I have a question in Stackoverflow:
A Listener corruption with PlanningListVariable

I think I get the cause for this Listener Corruption exception. The shadow variable startTime changed without any change of its source - the PlanningListVariable in ProductionLine - ProductionLine.taskList. Because when a task's predecessor changed, its the shadow variable - startTime will be changed, but its genuine planning variable - ProductionLine.taskList never changed.

I have no idea how to mention timefold, when the predecessor changed. Does anyone have a suggestion? Thank you in advance!

[Christopher-Chianelli]

Predecessors are incredibly complicated to implement. The primary issue is that predecessors can form a cycle, causing their start time to be invalid. For instance, consider this scenario:

• Tasks B requires task A
• Employee Ann has the tasks in this order: B, A

This forms a cycle, since A start time depends on B end time (as A comes after B) and B start time depends on A end time (as B requires A). The proper solution to this involves finding a topological order of the variables.

We are currently working on a preview feature to make this significantly easier: declarative shadow variables (final naming to be determined). With it, you can say the start time depends on all its predecessors' end times (and do a different calculation if there are no predecessors). You also check if a particular Job is involved in a cycle.

[kentbill]

I am thinking that using TimeGrain pattern would make the model simpler for this scenario, but when length of the grain is too short, the problem size becomes huge.

[kentbill]

Thank you! @Christopher-Chianelli

excellent! Looking forward to the new features that can handle the scenario with the predecessor,

Yes, dealing with the predecessor problem often encounters cycles. I‘m trying a Move Filter to filter out the solutions that have cycles, but I think it may hurt the optimization, such as getting stuck in local optimization.

The approach I have come up with now is to define two shadow variables for the task instead of startTime - predecessorEndTime and prevoiusEndTime, and startTime = max (predecessorEndTime, previousEndTime).

In the method with @CascadingUpdatingShadowVariable, update the predecessorEndTime and previousEndTime. For predecessorEndTime, I also need to update the predecessorEndTime of all successor tasks.