Heuristic phase slow to make steps with custom move factory

[crispzendisc]

Hello,

We are working on a scheduling problem using version 1.21 where we allow activities to be unassigned. Activities left unassigned are penalized with a MEDIUM penalty based on the activity's priority.

We have also implemented a custom move factory. Our model has groups of activities in which each activity should only be assigned a time if every other activity in the same group is also assigned a time, and otherwise none of them should be assigned. Our move factory therefore only creates moves where all activities within a given group are assigned, and doesn't create ones where they are only partially assigned.

We would like help understanding the behavior of the heuristic phase in our approach, and how we could improve it. In one example, we start with 10 groups of activities, with 4 activities in each group. Our heuristic phase uses a PooledEntityPlacerConfig configured with our move factory, and runs for 5 seconds. We see the solver iterate through moves where each once assigns a group and decreases the overall MEDIUM penalty, improving the score. Each group is assigned at some point. However, after the 5 seconds have passed, we see this kind of message: DefaultConstructionHeuristicPhase terminated early with step count (2). The solution may not be fully initialized. The local search phase begins with most groups still being unassigned. There is no obvious reason why assigning any particular group should not be accepted--they do not break hard constraints by being assigned, and only improve the score.

Why would the heuristic phase not be accepting more steps and fully assigning all groups sooner? What is the correct way to make the solver step quicker? One approach we tried was using a forager config with FIRST_NON_DETERIORATING_SCORE. In this case, we had the problem where the same move kept being accepted over and over because it left the score unchanged, and the heuristic phase essentially got stuck. There doesn't appear to be a "first improving" move option to choose from in v1.21, although that seems like the kind of behavior we want.

Any insight you could provide would be appreciated!

[Christopher-Chianelli]

Can you post your solverConfig.xml or the code that creates the SolverConfig via the programmatic API?
You might get better results by using your custom moves in a Custom Phase (https://docs.timefold.ai/timefold-solver/latest/optimization-algorithms/overview#customSolverPhase) before you run Construction Heuristics.
You can see the moves the Solver tries by setting the logging level of timefold.solver to TRACE (DEBUG shows accepted moves only) (https://docs.timefold.ai/timefold-solver/latest/using-timefold-solver/running-the-solver#logging).

With only ~40 entities, the CH should be able to finish within 5 seconds unless the score calculation speed is extremely slow.
However, it is hard to offer additional advice without seeing the current SolverConfig, custom move generator, or the logs.