Clean running trials

Motivation

You do not have to specify the number of trials in study.optimize. Then you can stop the optimization with “KeyboardInterrupt”. When your optuna is connected to a DB the trail you interruped will stay in status “running” for ever. I am not sure what this means for the optimizer but my guess is that it is not good when you restart the optimization. This is because optuna thinks that a 2nd process is running on the DB and has not ended.

Description of the new feature

What about a new parameter in the optuna.create_study function called clean_running with Falseas default. When you set it to True it removes all running trials when opening the DB. If you set it to True the load_if_exists also has to be True.

Alternatives (optional)

I don’t know.

[hvy]

I personally find the KeyboardInterrupt signal handler approach to be cleaner, trying to reduce zombie trials in the first place. I guess that it on the other hand requires quite a bit of work (incl. writing exhaustive tests). So, it could be tackled at a later time.

[sile]

Thank you for the swift response!