deadlock when lane-changing close to lane end

[ZoltanBaksa]

similar to #3079, but only one vehicle needs to change lanes to continue the route. The 'locked' vehicle stands on the middle lane in a 3 laned road near or after the end of the lane, and cannot change lane even if there is free space on the right lane, because the 'other' vehicle is far or stops to let it in. The locked vehicle stays there till it is finally teleported. used version is 1_1_0+0499-1019569a8c

[namdre]

I don't quite understand the role of the 'other' vehicle. If

the other vehicle is far or stops to let it in

than this should enable lane-changing. Could it be that the blocked vehicle has an lcAssertive value > 1 ?

Can you provide a sample scenario?

[ZoltanBaksa]

the other vehicle is also on the same route, only it could change the lane before. I have a larger scenario, i try to reproduce it in an example and send it.

[ZoltanBaksa]

here is a simple scene updated, sorry vTypes left out junctDeadlock.zip

[ZoltanBaksa]

I tried the scene with Krauss, but the issue not occurred. Probably related to IDM only

[namdre]

I tried with the latest development version but could not find a deadlock only congestion. When running with --time-to-teleport -1 the simulation completes as below (it should not complete if there is a deadlock):

Vehicles: Inserted: 4990 (Loaded: 7500) Running: 9 Waiting: 2510 Emergency Stops: 39 Statistics (avg): RouteLength: 125.02 Duration: 32.02 WaitingTime: 3.30 TimeLoss: 22.19 DepartDelay: 1526.06 DepartDelayWaiting: 2511.50

[ZoltanBaksa]

The deadlock is meant for the 'locked' vehicle only. Because there is time to teleport, the simulation runs through. The problem is, that in our simulation there are many places, which could have the effect in the same time, and the congestion could result a full simulation jam. Since we want to simulate the real world, which is more-or-less fluent, we need to increase the already given demand, which is jamming... Because of aboves, if we switch off the time to teleport, it is deadlock for the whole simulation.

[namdre]

This is what I meant: I my simulation there is no locked vehicle. I disabled teleporting and it completes anyway. If you tell me the simulation step and vehicle ID I can look at that particular vehicle and check for wrong behavior. After our recent merge of the 'parallel simulation branch' the random number generation is different so you also need to specify the exact sumo version because we won't see the same traffic otherwise.

[ZoltanBaksa]

sumo version was in the first post written 'used version is 1_1_0+0499-1019569a8c'

[namdre]

I was finally able to reproduce teleports.

• most of them are related to counter-lanechange (two vehicles standing next to each other and would have to swap positions to continue their route). This is a known issue if vehicles have little space to perform the lane change and traffic is very dense. A good mitigation is described at http://sumo.dlr.de/wiki/Simulation/Motorways#Combined_On-Off-Ramps. When modifying the network this way there were no more teleports, no emergency stops and almost no emergency braking

• I also saw a deadlock as described in the first post where vehicles in the rightmost lane fail to open a gap for a vehicle on the centerlane. I will investigate this further

[ZoltanBaksa]

Hello Jakob, This issue has ocurred again, this time in a British network. There are street segments with two lanes, the leftmost lane is bus lane. To allow the turn-to-left, I have created a small lane segment with all enabled road vtypes. The issue raises, when there is a vehicle, that wants to turn left from the middle lane, but because the bus lane is occupied by a bus, it cannot change lane in time and slowly reaches the lane end. The length of the small lane is unfortunately big enough for the rest of the traffic, and they overtake on the right until there is another vehicle that wants to turn left, and there is no space to overtake. Are there any lane change parameter combinations that could reduce the effect? Currently I use v1_5_0+0966-5d73fbc2da

[namdre]

Hi Zoltan, can you show a screenshot, or even better, attach a sample scenario? The easiest solution is probably to add another connection so that either of the blocked vehicles can move along.

[ZoltanBaksa]

Hi Jakob, the problem occurs mostly in jamming situations. I tried to add additional connections, but it did not solve the problem. I have created a share for you, I send you the link privately. The first occurrence is at about 02:20:00 at junction 227722, when Bus_q6_020000.5 tries to turn right, and Car_q6_021500.3 tries to turn left. One additional issue occurs, probably because I use 600 secs for teleport time (to be able to find and monitor such issues, a kind of debuging method), that the GUI crashes after some time, without any reason. I'm not able to run debug version from Visual Studio, some sort of setting is wrong at my setup.

[namdre]

Your scenario is affected by #6904 but this is unrelated to the deadlock.

[namdre]

The deadlock is caused by a combination of bugs:

• When slowing down to prevent lane-change-deadlock, other speed advice is ignored. (The lane change would have succeeded much earlier otherwise)
• IDM has sloppy computation for stopping on point. This causes the slowing-down-to-prevent-lane-change deadlock to fail by about 8cm.

[namdre]

I cannot reproduce the deadlock anymore. Let me know if you catch it again.

[ZoltanBaksa]

I managed to try out your changes in today's latest development version v1_5_0+1181-3a283f7789 I did not see the issue any more in the second scene. The network contains the additional connections, which were added previously as workaround. I will also do a simulation without those to check the original setups, both in lefthand and righthand scenes. I'll send you updated status afterwards

[behrisch]

Any updates here or can this be closed?

[behrisch]

see also #1124