TimefoldAI / timefold-solver

The open source Solver AI for Java, Python and Kotlin to optimize scheduling and routing. Solve the vehicle routing problem, employee rostering, task assignment, maintenance scheduling and other planning problems.
https://timefold.ai
Apache License 2.0
960 stars 84 forks source link

Feat: Make time gradient calculation more flexible #1138

Open jason076 opened 2 weeks ago

jason076 commented 2 weeks ago

Is your feature request related to a problem? Please describe. Finding the right termination config for time gradient based algorithms like simulated annealing is pretty hard especially for benchmarks. If I configure a maximum solving time of 10 minutes and a unimproved seconds spent limit of 30 seconds the 30 seconds spent limit is influencing the progress of the time gradient. The same is true if I configure a best score limit. It is not possible to configure an unimproved seconds and best score spent limit without influencing the time gradient.

This is especially problematic for benchmarking. I want to determine how long my algorithm takes until it reaches a specific score and I want it to behave like the production environment. But if I define a best score limit this influences the time gradient and therefore the algorithm behaves different than without the limit.

Describe the solution you'd like I like to be able to configure a time based spent limit together with unimproved seconds or best score limit without effecting the time gradient. E.G. if I configure 10 minutes spent limit with 30 seconds unimproved spent limit, the time gradient should only depend on the progress of the 10 minutes. Maybe you could add a boolean flag to the termination configs to let the user decide if a termination criterion should be considered by the time gradient calculation.

Describe alternatives you've considered I don't know any working alternative.

triceo commented 1 week ago

Thanks for the report, @jason076!

We are aware that the time gradient makes Simulated Annealing painful to work with. It is one of the reasons why Late Acceptance is the default - I recommend using LA instead of SA, since tweaking SA is not on our roadmap at the moment.

Even when using LA though, time-based terminations are problematic because they aren't reproducible on different hardware etc. We're currently in the process of designing a termination that doesn't require a time at all.