Better handling of `pause-simulation-during-tuning` in combination with new tuning interval mechanic
- Dominant language
- C++
- Stars
- 52
- Forks
- 17
- PR merge metrics
- No merged PRs in 30d
Description
**Is your feature request related to a problem? Please describe.**
It is sometimes useful to perform a tuning phase with the simulation frozen:
1. Whilst, for tuning purposes, the difference in a scenario between iterations is largely negligible, so you can use tuning iterations to progress the simulation, when generating data to compare different configurations, you potentially want to really make sure that you are comparing the exact same scenario.
2. You may want to make an "Oracle" full search run, where you trial all configurations so that you can see if tuning strategies select results that match the "Oracle" runs. Here, you potentially care less that the configurations are being compared on exactly the same data, but your tuning phase length might be less than the tuning interval.
Previously, a `pause-simulation-during-tuning` flag was added to md-flexible so that the simulation remained fixed during the tuning phase. However, at the time of development, AutoPas' tuning interval dictated the number of iterations after a tuning phase had concluded.
Now, AutoPas' tuning interval dictates that tuning phases begin on multiples of the tuning interval. I am fully in favour of this, but it causes issues in combination with `pause-simulation-during-tuning`. This means that the number of iterations you are advancing the simulation is now tuning interval minus tuning phase length. In the case of Full Search, this is somewhat awkward to calculate if you want to ensure you are advancing the simulation by a fixed number of iterations between tuning phases (together with load balancing intervals in line with this).
In the case of something other than Full Search, this is straight-up impossible to calculate. However, both scenarios described above just require full search so I'm not sure we need a solution for other tuning strategies.
**Describe the solution you'd like**
Two possible solutions, of which I don't really have a preference:
1. Add an internal AutoPas mechanic that fixes AutoPas' iteration counter whilst still progressing the tuning phase counters. I would suggest a separate setter to toggle this feature. This will cause loggers to assume the iteration remains the same, but personally, I don't care about this. If you see an issue with this, please comment.
2. Have md-flexible handle this by calculating how long the tuning phase will take (potentially with a helper function from AutoPas) and adding this to the tuning interval passes to AutoPas as well as the load balancing interval. This will only work in the case of a strategy with a fixed tuning interval length like full search.
I prefer the 1st, assuming there are no issues with this that I am not aware of. I feel like (2) is more work, harder to maintain, and a potential source of confusion/is more misleading.
Contributor guide
Assessment
This issue has not been assessed yet.