allow jumping forward and backward to a breakpoint

eclipse-sumo / sumo

Eclipse SUMO is an open source, highly portable, microscopic and continuous traffic simulation package designed to handle large networks. It allows for intermodal simulation including pedestrians and comes with a large set of tools for scenario creation.

https://eclipse.dev/sumo

Eclipse Public License 2.0

2.58k stars 1.45k forks source link

allow jumping forward and backward to a breakpoint #10198

Open namdre opened 2 years ago

namdre commented 2 years ago

jumping forward to the first breakpoint is possible via reload+run
jumping backward to a breakpoint could be achieved by
1. saving state at that breakpoint (to a default file name or even a string buffer)
2. loading that state

both methods (forward and backward) could be triggered by using numeric hotkeys i.e. '1' jumps forward by 1 breakpoint, breakpoint, '2' jump forward by 2 breakpoints, etc and ctr+1 jumps backward by one breakpoint.

We would need a new option for saving breakpoint states (i.e. --save-breakpoint-states)

see also #2440, #2441, #2443

rjmaris commented 2 years ago

Regarding "reload+run": isn't it really doable to restart a simulation simply by setting the time counter and other stuff to the state immediately after reload? This should do in a fraction of a second, while reload could consume a few seconds, dependent on the size and complexity of a net.

namdre commented 2 years ago

@rjmaris. Yes. the loadState functionality keeps the net and only reloads the traffic (in release it was only available via TraCI but in dev it's also available from sumo-gui now). The same functionality can be used to reset the network to its begin-time state. (trivially by saving state at time 0). Using this to speed up reload is the topic of #2440. An open issue however is resetting the state of all the route file handlers (#7471)

rjmaris commented 2 years ago

It seems that flow feeds are not continued after a saved state is reloaded, which appears to be more apparent when an early state is saved.

General notice: should it be useful to maintain separate feature branches for features that may be prone to initial bugs due to complexity resp. potential effects on program usage? In this case, however, no effects on program usage are apparent because the loading capability is new at all.

namdre commented 2 years ago

We try to reduce the number of branches because it simplifies things. My goal is to have the flow-in-state thing fixed before the next release. I would use a branch if I do need to push a temporary regression but as you said, the new feature doesn't break anything old.