-
Notifications
You must be signed in to change notification settings - Fork 69
Description
With Tarek we found a couple of issues with caching of trips in eqasim. The problem starts with the fact that we have three caches that can be simplified:
- There is the
AbstractTripRouterEstimator, which has the notion of "prerouted" modes. Whenever a trip is estimated that has already been routed with the same departure time, it is not routed again. This is nice, but not used. The list ofpreroutedModesis empty by default and hardcoded. This one should be activated and currently I'm working on integrating the following paper at that point in code:
Tchervenkov, C., Hörl, S., Balac, M., Dubernet, T., Axhausen, K.W., 2020. An improved replanning strategy for congested traffic conditions in MATSim. Procedia Computer Science, The 11th International Conference on Ambient Systems, Networks and Technologies (ANT) / The 3rd International Conference on Emerging Data and Industry 4.0 (EDI40) / Affiliated Workshops 170, 779–784. https://doi.org/10.1016/j.procs.2020.03.156
-
There is the
CachedTripEstimator, which follows almost the same pattern but is caching more things because it does not take into account the departure time of a trip along a chain. The current behaviour is hence to ignore varying departure times of the same trip (trip index + mode) and return the same travel time for every occurence of that trip in a chain. This may lead to inconsistencies, especially in public transport, where people may get stuck because the wrong connection was chosen for the end of the day. Tarek is currently adding the time constraint to this cache, we need to see how this affects simulation performance. In a second step, we could think of having a more intelligent caching approach (for instance, for public transport, always reroute if the new trip departs after the planned enter time of the agent in the currently cached route, and otherwise only if a certain threshold of difference in departure time is reached). -
There is the
CachedVariablePredictorwhich is simply weird, not sure what was the idea behind it. Basically, is only reacts if the same trip is requested twice one after another. I believe the idea behind was that if we call two timespredicton a car predictor, i.e. from the car utility predictor and the included cost model, the calculation should not be done twice. But it probably makes sense to solve this in the upstream code design (in the utility estimator, ...) and it probably does not any noticeable overhead! This one can be removed.