sub-optimal insertion flow with departLane="best"

[namdre]

the current lane choice code has a bug which causes occupied lanes to be picked instead of unoccupied lanes, thereby reducing insertion capacity.

[namdre]

The effect size is more pronounced on long edges (i.e. 75% of the possible flow at 5000m versus 95% at 500m). So there is hope, not too many simulations were affected.

[rjmaris]

Makes a huuuuuge difference!
In one simulation scenario the full simulation duration ran 10901 seconds (feed duration default 1 hour). That simple
if (!upper) is really a game changer in scenarios with unidirectional streets with two lanes compared to bidirectional streets with single lanes. As such my simulation is truly affected, but also more in line with expectations. Just some figures of two different city topologies (with departs and arrivals outside of a city ring):

release  | bidirectional city ring | unidirectional city ring
1.12.0   |         4594            |     7340
0340     |         4346            |     7424
0456     |         4574            |    10901
0457     |         5052            |     5205
0649     |         5052            |     5205

I'm wondering a bit about the fact that this lane insertion issue also can result in worsening of simulation duration.

[namdre]

@rjmaris for scenarios with congestion, there are two relevant metrics that must be considered: departDelay and timeLoss.

• timeLoss is only recorded for vehicles that have entered the simulation
• If vehicles cannot be inserted into the simulation due to lack of road space (or due to bugs such as sub-optimal insertion flow with departLane="best" #10137) they collect 'departDelay'
• by improving insertion, the balance is shifted towards less departDelay and more timeLoss

Further changes in scenario performance are due to work on #8507

[rjmaris]

@namdre Thanks for clarification,

Indeed, congestion is a sort of root cause of the long time of simulation after the feed of vehicles had stopped. Indeed I observed insertion inhibition because of lack of road space. From the viewpoint of the total image, a hugely increased departDelay might have overweighted timeLoss. The congestion itself adds to simulation time undoubtedly, I'd suggest that it's also related to the fact that congestion on main streets also result in sclerotic situations in residential streets - which may worsen the situation on junctions.
Hence: the bug fix simply leads to a just "no congestion" situation.

Regarding the slightly worse figures now in the bidirectional case: Apparently departLane is not affected, but some more time loss could explain it, together with - anyhow - modified lane usage in twin lane street sections of this model (I'm not sure whether the part of the total flow that is defined by individual routes via build.bat (routes criss-cross through the model - OSM-related project) might be responsible for indirect departLane-rooted delay, e.g. if their getting into occurrence on "best" lane would hinder other vehicles (from the defined flows) behind them.

Thanks for the hint to #8507. One of my headaches also is emergency braking. For that reason, I halved the simulation time step. This only resulted in somewhat less emergency braking.