Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for departure-time based caching #126

Open
sebhoerl opened this issue Mar 29, 2022 · 0 comments
Open

Allow for departure-time based caching #126

sebhoerl opened this issue Mar 29, 2022 · 0 comments

Comments

@sebhoerl
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant