discuss: modechoice/replanning long repetition series - fix needed?

[wrashid]

reproduce easily: high intercept for walk_transit, but have no transit capacity.

=> should replanning have memory to avoid repetitions?

[michaz]

If I understand this correctly, you found out that this happens when people replan a lot.

But that would still mean that the root cause of the duplicated link IDs is not that they replan a lot, but that we have a kind of off-by-one error or fencepost error when we construct the big trip from the small (attempted) trips, right? I mean, traversing the same link n times without anything in between just can't happen, no matter how often I replan.

Is the patch in the construction of the PathTraversalEvents already the solution? (Could be, I don't know.. maybe that's literally the only place this matters, but maybe not: For instance, perhaps we let time pass corresponding to several traversals of the link, etc.)

[michaz]

(Or is this not related to the duplicate link IDs and I made that up? :-) )

[wrashid]

link ids repetition and this issue seem to be separate. the patch is not completed yet - that was more debugging

[michaz]

Okay thanks, got you.

So what do we think would be behaviorally correct? I see an overcrowded bus. I wait for the next one, but not for much longer.

Something like a probability to wait for the nth bus that decreases with n?

(This is an actual modelling issue, not so much a technical problem of replanning often, right?)

[wrashid]

I would be fine with any of the following behaviors which is easy to implement to avoid the loop, e.g. take a different mode if unsuccessful with a mode or take bus occupancy into consideration during choice from the beginning or probability based waiting approach as suggested above or something else. At the moment it can get stuck in a loop where it selects walk transit over and over again (there is no info available to agent that buses are full at this time of the day).

[sfwatergit]

If I were in such a situation, I'd probably check once in a while to see if ridehail were a better option. As a learning behavior, I'd probably avoid taking such a full bus again... In BEAM, some PersonAgents might not have that luxury, in which case, they'd better hope that when urbansim hooks up w/ BEAM future years will bring enough development/growth in income that they won't have to walk 20 miles to work or wait around for a non-full bus every day 😬 (or, perhaps, hope that somehow the city buys more buses/sends them more frequently...)

[michaz]

I'd probably check once in a while to see if ridehail were a better option

I think they're doing that, they are just deciding with never-diminishing optimism that the next non-overcrowded bus will come any time now, so ridehail fails to appear as the better option.

Sounds like "keep replanning, but add a rising penalty to PT for every time I've seen an overcrowded bus" to me..

[michaz]

(Or aren't they? Ahhh, maybe they stay locked on the PT mode once they decided, and only replan the PT route..)

[sfwatergit]

No... actually it looks like they do try RideHail repeatedly if replanning (according to ChoosesMode)

[colinsheppard]

I've temporarily averted this issue with a hard cap on number of replanning attempts per trip. For now it's set to 2 attempts and then sent straight to WALK.

But this is one that we should solve more robustly in the future. I like the idea of penalizing the failed mode in the next choice. ~$1 per failure should do it.