VISSIM - Merge Modelling
Introduction
Welcome to the latest Modelling Group blog post.
This time, we are going to focus on modelling Merges and provide some thoughts and tips, based on how we model these in VISSIM. We hope you find this useful.
Background
In our previous ‘Flares’ blog post, we went through the traditional and updated methods for modelling flares (link) and this same set-up can be applied to merges.
An example of the updated method using the 0.1m lane for a merge is shown in Figure 1.
‘Merge’ Driving Behaviour
Figure 1 – Example of Updated Merge Method – Link/Connector Set-Up
When establishing the merge driving behaviour, the main element to consider is the nature of the merge. Is it in an urban area, where the speeds are low and vehicles are driving closer together, or is it on a motorway or dual carriageway where the speeds are higher but vehicles are generally spaced further apart?
If you have both types of merges in your model, then you should consider developing two different behaviours to account for the different merge characteristics.
Merge – Urban Areas
If the merge is in an urban area where speeds are lower and vehicles drive closer together, the key parameters that we recommend reviewing and adjusting (from the default ‘urban (motorised)’ behaviour) to make the merge more realistic include:
Following - see Figure 2.1
Look ahead/back distance (min) – PTV’s help file recommends increasing this distance from 0m where several vehicles can overtake within a lane. There is also a specific mention for urban areas, where a distance of 20-30m may be more suitable.
Number of interaction vehicles – This value can be reduced, as vehicles do not need to react to as many as the default 99 vehicles for ‘urban (motorised)’ behaviour. This could realistically be as low as 2-3 vehicles.
Lane Change - see Figure 2.3
Safety distance reduction factor – This value can be reduced to encourage vehicles to be more aggressive when changing lanes. From the ‘Inside merge’ example within the Examples Training folder, a value of 0.3 is suggested as an alternative.
Maximum deceleration for cooperative braking – By increasing this value, this leads to stronger braking and a greater probability of changing lanes. We have discussed this with PTV and it should be noted that this is the maximum value and the actual required deceleration is usually much lower because the leading vehicles wouldn’t enforce such a high deceleration onto the trailing vehicle. PTV confirmed that this value used to be -9m/s² internally (the same as gravitational acceleration) before the parameter was available to be edited. As a result of this, we would suggest values in the range of -3 to -9m/s². It is also worth mentioning here that vehicles will still always obey their individual acceleration and deceleration function profiles (see base data -> functions) and we recommend that these values are left as default.
Lateral - see Figure 2.4
‘Observe adjacent lanes’ – ticked. This allows vehicles to take account of the position and lateral orientation of other vehicles on adjacent lanes. This prevents vehicles moving across too late when there is not enough space.
‘Default behaviour when overtaking vehicles on same or adjacent lane’ – For ‘overtake right’, this value can be reduced to encourage vehicles to change lanes at higher speeds where the lateral distance is lower. Values of 0.3-0.5m are suggested.
An example behaviour that could be used as a starting point is shown in Figure 2. The highlighted changes are those made from the default ‘Urban (motorised)’ behaviour.
Figure 2.1 – ‘Merge – Urban’ Driving Behaviour – Parameter Changes
Figure 2.2 – ‘Merge – Urban’ Driving Behaviour – Parameter Changes
Figure 2.3 – ‘Merge – Urban’ Driving Behaviour – Parameter Changes
Figure 2.4 – ‘Merge – Urban’ Driving Behaviour – Parameter Changes
Merge – Motorway Areas
If the merge is on a motorway where speeds are higher and vehicles are a bit more spaced out, the key parameters that we recommend reviewing and adjusting (from the ‘Merge – Urban’ behaviour) to make the merge more realistic include:
Following - see Figure 3.1
- Number of interaction vehicles – As with the ‘Merge – Urban’ behaviour, this value can be reduced as vehicles do not need to react to as many as the default 99 vehicles for ‘urban (motorised)’ behaviour. However, this is not likely to be as low as 2-3 vehicles for urban merging and the range of 4-5 vehicles may be more suitable to account for the additional lanes and higher vehicle speeds.
Car Following Model - see Figure 3.2
- Change of behaviour from Wiedemann 74 to Wiedemann 99 – At higher speeds, the desired safety distance is smaller for Wiedemann 74 than 99, which is why 99 is more suitable for motorway merge sections. In 99, the desired safety distance increases linearly with the speed and uses time-step oscillations to control the car following and lane changing model.
Lane Change - see Figure 3.3
- Cooperative lane change – This should be ticked to allow a behaviour whereby vehicles will look to change lanes themselves if they observe other vehicles in adjacent lanes also wanting to change lanes. This helps to facilitate lane changing and reduce instances of ‘stopped’ vehicles in merge sections.
Lateral - see Figure 3.4
- ‘Default behaviour when overtaking vehicles on same or adjacent lane’ – Similar to the ‘Merge – Urban’ behaviour, for ‘overtake right’, this value can be reduced to encourage vehicles to change lanes at higher speeds where the lateral distance is lower. Values of 0.5-0.7m are suggested.
An example behaviour that could be used as a starting point is shown in Figure 3. The highlighted changes are those made from the default ‘Merge - Urban’ behaviour.
Figure 3.1 – ‘Merge – Motorway’ Driving Behaviour – Parameter Changes
Figure 3.2 – ‘Merge – Motorway’ Driving Behaviour – Parameter Changes
Figure 3.3 – ‘Merge – Motorway’ Driving Behaviour – Parameter Changes
Figure 3.4 – ‘Merge – Motorway’ Driving Behaviour – Parameter Changes
Summary
We hope this post has helped to provide a bit of insight on we model merge behaviours.
However, we are keen to stress that we have developed these settings and understanding of the functionality through trial and error on multiple projects and time invested in internal development. They do not represent a ‘one-size fits all’ approach and it may be that some adjustments to the parameters are needed for your own model calibration/validation purposes.
Despite this, we wanted to share our learning and hopefully there are some elements you can apply to your own models.
Thanks for reading!