Feat: Make time gradient calculation more flexible

[jason076]

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]

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.

[triceo]

(My apologies for the noise, the above notifications were in error.)

[jason076]

Thanks for your answer. Unfortunately late acceptance did not deliver good results in our use case. We have a very uncommon use case which only worked well with SA. We already talked to some timefold experts about our use case but it seems that there is no better approach. So maybe we have to work with SA but I will try LA again. Maybe our custom moves will make it usable.

I am really looking forward to new termination settings. I think in some use cases it is a bad UX to let the user decide when to stop the planning and letting the planning always run for e.G. 10 minutes is also bad if a simple problem is maybe solved in seconds. Hence the seconds spend limit was at the moment the best fit from UX perspective. I am curious what you will come up with.