You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 of preroutedModes is 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 CachedVariablePredictor which 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 times predict on 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.
The text was updated successfully, but these errors were encountered:
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:
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 ofpreroutedModes
is 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: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
CachedVariablePredictor
which 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 timespredict
on 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.The text was updated successfully, but these errors were encountered: