How to Penalize Long Wait Times in DRT?

[MayuriAnn]

Hi,

Based on the output from the São Paulo pipeline, the corsica_drt example, and adapt configs for drt and feeder, we built a scenario to simulate DRT/feeder+DRT (here are the configuration and running script for feeder+DRT). After completing the simulation, we noticed a large number of rejections with the cause "no_insertion_found."

We plan to run a few tests to address these rejections by:

1 - Enabling the RejectionConstraint.
2 - Turning off rejections by setting the rejectRequestIfMaxWaitOrTravelTimeViolated parameter to false.

In the latter case, it is likely that many requests will result in long wait times. To prevent this, we want to penalize the utility of requests with long wait times in the DiscreteModeChoice (DMC) module, encouraging agents to select other modes.

Looking at the Eqasim code, it seems that the parameter modeParameters.drt.betaWaitingTime_u_min controls the disutility of waiting time. However, we are unsure where this parameter (and other similar parameters) is being set for the DRT mode, other than default (zero) values found in ModeParameters.

So our questions are:

How can we set this parameter to penalize long wait times (either in the code or through the configuration file)?
Would this be a valid approach to mitigating rejections?

Thanks in advance.

[sebhoerl]

Hi, in SaoPauloModeParameters you have the function buildDefault which sets the default values when running the simulation. So there you can set the parameters just like parameters.drt... = .... As an alternative, you can also set them via the command line when starting the simulation by passing --mode-parameter:drt.betaWaitingTime_u_min -0.123123 to RunSimulation.

Handling rejections is indeed a tricky topic, and I think there are multiple philosophies on how to interpret them. We had a brief discussion in this paper here, including yet another approach:

Tarek Chouaki, Sebastian Hörl, Jakob Puchinger. Control-based integration of rejection rates into en-
dogenous demand ride-pooling simulations. 8th International Conference on Models and Technologies
for Intelligent Transportation Systems (MT-ITS 2023), Jun 2023, Nice, France.

[MayuriAnn]

Thanks for your response.

Since you mentioned that I should use buildDefault to set the DRT utility parameters, I was curious about the default values I was using in my simulation. To investigate, I ran the simulation in debug mode and placed a breakpoint at the utility calculation step. I discovered that all DRT parameters were set to zero:

As such, if I understand correctly, the final DRT utility was zero while the other modes had negative utilities. This likely explains why the simulation had so many DRT requests and rejections, correct?

I then reran the simulation, this time setting the DRT parameters in buildDefault to match those of public transport (pt). This reduced the mode share of DRT from 18% to 8%, and almost all rejections were eliminated.

Now, my questions are: is using the same parameter values as pt an appropriate approach? Also, do you have any theoretical guidelines (e.g., books or papers) on how to select the values for DRT utility parameters?

Again, thanks in advance.

[sebhoerl]

Hi, there are various sources. The best is to look for stated choice experiments about on-demand mobility services. There are also a lot of them that focus on autonomous taxis. But using the PT parameters is a sensible approach to begin with. See for instance here for autonomous vehicles:

Hörl, S., Becker, F., Axhausen, K.W., 2021. Simulation of price, customer behaviour and system impact for a cost-covering automated taxi system in Zurich. Transportation Research Part C: Emerging Technologies 123, 102974. https://doi.org/10.1016/j.trc.2021.102974