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
Currently, the mode choice components have either normal or cached estimators (configurable via config per mode). If cached, a trip is not rerouted when examining all the possible trip chains for a tour of an agent. This means if the same combination of (person index, trip index, mode) is encountered, an already computed route is used to perform the estimation of travel time and others.
Usually, this makes sense, because the departure time of a trip is mainly defined by the preceding activity end time. However, we can have edge cases when, for instance, a preceding trip takes so long that the following activity end time is exceeded.
Therefore, it might be useful to optionally also perform the caching by departure time, i.e. only if the new departure time of a trip is within a certain range from the cached departure time, the cached item will be used. This functionality needs to be implemented in CachedTripEstimator, but requires some additional refactorings, because currently each DiscreteModeChoiceTrip is an individual object for which the departure times are set on the fly during the trip chain exploration using the setDepartureTime method. This information would need to be passed to the estimator.
The text was updated successfully, but these errors were encountered:
Currently, the mode choice components have either normal or cached estimators (configurable via config per mode). If cached, a trip is not rerouted when examining all the possible trip chains for a tour of an agent. This means if the same combination of (person index, trip index, mode) is encountered, an already computed route is used to perform the estimation of travel time and others.
Usually, this makes sense, because the departure time of a trip is mainly defined by the preceding activity end time. However, we can have edge cases when, for instance, a preceding trip takes so long that the following activity end time is exceeded.
Therefore, it might be useful to optionally also perform the caching by departure time, i.e. only if the new departure time of a trip is within a certain range from the cached departure time, the cached item will be used. This functionality needs to be implemented in
CachedTripEstimator
, but requires some additional refactorings, because currently eachDiscreteModeChoiceTrip
is an individual object for which the departure times are set on the fly during the trip chain exploration using thesetDepartureTime
method. This information would need to be passed to the estimator.The text was updated successfully, but these errors were encountered: