DRT Estimation and Teleportation #3160
Conversation
How this estimator may be used.
|
Hi Chengqi, this looks nicely extensible. In our discrete-choice-based simulations we always need to estimate the expected wait times and other things to make the decisions, so this is quite useful! Right now, we basically do what the Pessimistic estimator seems to be doing in this package, which, indeed, may be too simplistic and pessimistic :) I'll have a closer look for the review asap! |
When no DRT suitable DRT is found, the route will be null. We need to be able to handle this situation.
| // @Parameter | ||
| // @Comment("Decay of the exponential moving average.") | ||
| // @Positive |
There was a problem hiding this comment.
We want to have this only available via code and not in the config for now, because it is not a stable API yet.
There was a problem hiding this comment.
I see. I think you can still keep @Positive (and @PositiveOrZero for the other field) uncommented.
| modalMapBinder(DvrpRoutingModuleProvider.Stage.class, RoutingModule.class).addBinding( | ||
| DvrpRoutingModuleProvider.Stage.MAIN) | ||
| .toProvider(new DefaultMainLegRouterProvider(getMode()));// not singleton | ||
| // this seems to bind an enum. maybe more heavyweight than necessary? |
There was a problem hiding this comment.
For each dvrp mode, we have a stage (egress, main, access) to routing mapping. The key is an enum and not a string, because we want to limit it to these 3 options only.
|
|
||
| boolean teleportEstimate = drtCfg.getDrtEstimatorParams().isPresent() && drtCfg.simulationType == DrtConfigGroup.SimulationType.estimateAndTeleport; | ||
|
|
||
| if (teleportSpeedup) { |
There was a problem hiding this comment.
Maybe the new approach could replace the old drt speedup (at least at some point)? Do you have any plans wrt the DRT speedup?
There was a problem hiding this comment.
You are right, we also think the old drt speedup might be replaced altogether. But we are not heavy users of that functionality and don't want to break it for now. The only conceptual difference is that estimators are updated in speed-up, by performing a "full simulation". It should not be very difficult to also add this to our approach, but right now that was not our priority, and we have not tested that.
| @@ -216,6 +218,15 @@ public enum OperationalScheme { | |||
| @Comment("Store planned unshared drt route as a link sequence") | |||
| public boolean storeUnsharedPath = false; // If true, the planned unshared path is stored and exported in plans | |||
|
|
|||
|
|
|||
| public enum SimulationType { | |||
There was a problem hiding this comment.
As mentioned, @michalmac, could that not be merged with the speed-up functionality, i.e. just "teleportation" could be a third option in this enum which refers to the speed-up approach.
| if (simulationType == SimulationType.estimateAndTeleport) { | ||
| Verify.verify(drtSpeedUpParams == null, "Simulation type is estimateAndTeleport, but drtSpeedUpParams is set. " + | ||
| "Please remove drtSpeedUpParams from the config, as these two functionalities are not compatible."); |
There was a problem hiding this comment.
See above, the two are exclusive. For the sake of consistency, maybe it also makes sense to rather activate estimate+teleport via the presence of the corresponding parameter set?
There was a problem hiding this comment.
We really prefer not to activate it implicitly. I also think this is not very good solution in drt speed up.
As you suggested, adding a third enum would be a solution. However, this would require drt speed up users to set this new enum and effectively break their old config. I don't have a strong opinion about this, I'm also ok with adding an additional enum.
# Conflicts: # contribs/drt-extensions/src/main/java/org/matsim/contrib/drt/extension/estimator/run/DrtEstimatorConfigGroup.java # contribs/drt/src/main/java/org/matsim/contrib/drt/run/DrtConfigGroup.java
Background and Motivation: The service quality of DRT is highly sensitive to the number of users. In the conventional MATSim approach, we usually force a certain number of agents to try out new modes. For the scenarios with limited DRT supply (i.e., limited fleet size), overloading may happen. When overloading happens, the service quality of DRT system suffers a significant drop. This leads to agents having false memory about DRT service. One way out is to avoid this is to reduce the innovation rate until overloading does not happen. But doing so will increase the number of iterations needed for the model to converge, and that can be a major problem for larger scenarios.
**Solution provided by this PR: ** In this PR, we implement a new way to perform simulation with DRT, namely estimate and teleport. Here we first come up with a DRT estimation model, based on real-world data (when available) and/or quantitative simulations (i.e., DRT simulations with fixed demands). In the MATSim iterative process, the DRT estimation model will generate individual estimated trip information for each agent (e.g., waiting time, ride duration, ride distance, probability of getting rejected). Then the agents will be teleported to the destination according to the estimated trip information. By doing so, we do not need to worry about the overloading problem, even with relatively high innovation rate.
To make this model work, we need to make sure the estimator is accurate. First, we will need to have an idea of what level of service quality the DRT system can achieve. When adequate real-world data is available, then we can develop a distribution model based on the real-world data and used it for the simulation. Otherwise, we will need to first define the targeted service quality. After the MATSim simulation, we can perform post-simulation, where DRT is explicitly simulated based on the output DRT trips (which are fixed) from the MATSim simulation. With that, all the KPIs of DRT system can be acquired. Furthermore, the post-simulation can also be used to validate the DRT estimator. If the estimator is too far-off from the performance in the post-simulation, then we may adjust the DRT estimator or DRT operational strategy.