Hello,
there are distinct issues at play in your scenario.
1) you network has the wrong connections where the extra lane is added. A typical connection patterns would connect the lanes as follows
0 -> 0
0 -> 1
1 -> 2
Guessing from your screenshot you also have 1 - > 1. This creates a conflict where two different lanes have the same target (visible in the half-grey line in sumo-gui) and vehicles on lane 0 avoid the conflict by only moving to lane 0 on the 3-lane segment.
2)
Usually, a lane drop in sumo is modeled by having one lane that has no connections (forcing a lane change).
Vehicles in sumo can "spot" such a lane drop from a long way off (they are presumed to know the network layout ahead) and tend to avoid (under free-flowing traffic conditions) the lane which does not continue.
Adding a zipper merge solves this problem as no lane is a dead-end or otherwise disadvantaged. You could also use vType attribute lcStrategicLookahead to shorten the foresight distance.
I advise to make the following zipper connection pattern
0 -> 0
1 -> 0
2 -> 1
3)
You will only see congestion if the inflow rate on the upstream side is higher than the outflow at the downstream side.
However, your inflow is 2 lanes and a zipper is highly efficient at merging vehicles so that it fully saturates the capacity of the 2-lane outflow.
The only way to see congestion at the lane reduction is to make the 3-lane section long enough so that the distribution of desired speeds can create enough variation in vehicle density.
A quick experiment gave the following results depending on the length of the 3-lane section (where the speed limit is 33m/s):
200 -> min speed 13
500 -> min speed 8
1000 -> min speed 0.2
regards,
Jakob
