Closed ambuehll closed 4 years ago
The simulation is deterministic when run with a fixed random seed (which you do). Insofar, random crashes are likely related to parallelization (which your config uses for routing).
Note, that the combination of <routing-algorithm value="CH"/>
with <device.rerouting.adaptation-interval value="3"/>
is a bad idea because CH algorithm performs expensive network-pre-processing at that interval (every 3 seconds) which is much slower then all the other routing algorithms.
Vehicles with disconnected routes would cause an error by default. Due to your use of option --ignore-route-errors, the vehicle is discarded with a warning. However, due to your use of option --no-warnings you are not seeing this.
If you can narrow down the conditions for the crash that would be a big help (I was not able to reproduce it).
Thanks. Let's ignore the crash for now, because I can't reproduce it either right now (it was run with random true). Thanks for the comment on "CH". It's from an other old setting where I recompute paths only every 6min for a very large network (Los Angeles). I guess then it makes sense, right?
On the second issue: Yes, I understand that the errors are not shown since I run it with ignore-route-errors. But the problem is not that the error is not shown, but that the vehicle is NOT discarded. It remains in the network causing spillback! This is not the case for most vehicles, but only some. Check vehicle 404427791 or 50555897.
I missed the fact that the --random option is set in the configuration you gave me. Most likely this is why I cannot reproduce your finding (the vehicles are not in the network). Please send me a specific random seed that shows the problem where a vehicle without proper route is still in the network.
Regarding CH, yes it does make more sense when only rebuilding every 6 min.
The file that I had put online when I edited the question has:
<random value="false"/>
<seed value="42"/>
see the screenshots of vehicle 404427791 not moving for substantial amount of time (it won't move at all, actually). This happens at junction 27731.
Now, I finally see it.
Checking again, I realize that the behavior is intended (sorry for the confusion). The main point of using ignore-route-errors is to enable simulations where the connectivity changes at runTime (e.g. rerouters or traci are used to block or unblock edges) and vehicles that are blocked should remain in the network to wait for these changes. If you want to discard invalid trips, do so by passing them through duarouter with the option --ignore-errors --write-trips. Or, even simpler, set the randomTrips option --validate which does this in the background.
I am sorry to update this, but the explanations in the doc somehow contradict what you point out: https://sumo.dlr.de/docs/Demand/Automatic_Routing.html I think this is generally confusing.
Whenever an error occurs on routing because no route can be found which includes all mandatory edges ("from", "to", and all stop edges in the correct order) and is connected (also respecting the vehicle class permissions) this is a fatal error and stops th simulation. This can be switched off by using --ignore-route-errors which will leave the route untouched in the error case. If the vehicle did not have a route yet (because it was defined using a trip) and cannot find one and --ignore-route-errors is used, it will not be inserted.
I found it: https://github.com/eclipse/sumo/issues/6650 I think the original implementation idea was that you can not inserted vehicles using disconnected TAZ because there is no obvious way to selected the source and destination edge from among the TAZ edges and thus the vehicle should be discarded. For micro behavior, it may be sufficient to correct the documentation. However, meso behavior is even stranger and now you know why the problem didn't manifest every time: it depends on the target edge conditions. I'm closing this ticket here because the other one is more succinct.
Checking again, I realize that the behavior is intended (sorry for the confusion). The main point of using ignore-route-errors is to enable simulations where the connectivity changes at runTime (e.g. rerouters or traci are used to block or unblock edges) and vehicles that are blocked should remain in the network to wait for these changes. If you want to discard invalid trips, do so by passing them through duarouter with the option --ignore-errors --write-trips. Or, even simpler, set the randomTrips option --validate which does this in the background.
Thanks very much. I use --validate to solve my questions.
Sumo v1_4_0+0691-356a361902: files there are many invalid routes as they are generated automatically from different TAZ. Vehicles that can't find a route in the network should be removed immediately. Some vehicles (still trying to find out which ones) seem to not be removed. Right now they cause congestion (until they get removed by teleport - if set). Check vehicle 404427791 (inserted at roughly 7500s) or 50555897 for example.
Thanks.