VISSIM - Scenario Management
Introduction
This time, we are going to focus on Scenario Management and provide some thoughts and tips, based on our experience of using the feature so far. We hope you find this useful.
What is Scenario Management?
Scenario Management was first introduced into VISSIM in Version 8 and is intended as a way of being able to undertake ‘whole project modelling’ within a single file.
The idea is that the modeller will develop the base model and then create any future year and/or testing models, all within the same instance of VISSIM. This is done through the use of Scenarios, which are themselves then made up of separate Modification files.
Different modification files can be created and linked to single or multiple Scenarios, to allow elements such as different flow-sets and network changes/improvements to be tested.
An example of this set-up is shown in Figure 1.
Figure 1 – Example Scenario Management Structure
Main Leaning Points Gained from the use of Scenario Management
Listed below are some of the things we have learnt whilst using Scenario Management, which have gone on to influence our overall modelling approach.
1) Keep things as simple as possible
When we first started out with Scenario Management, we had a plan to create different modification files for each of the different modelling elements (e.g. priorities, signals, flows etc.)
However, our experience of taking these models through external auditing has led to the refining of our approach, in order to keep things as simple as possible and to use as few modification files as is practically possible for each scenario. This makes things easier for both the modeller and anyone auditing the project, as they only have a handful of files to check.
2) When developing base year models, create your first peak model (e.g. AM peak) in the Base Network and then create a separate modification file for the second peak specific model changes (e.g. PM peak)
We have found that when developing base year models using Scenario Management, it’s best to build the network structure and add of the various elements (behaviours, vehicle characteristic, speeds, priorities, signals, routes, public transport, outputs) for the first peak model (e.g. AM peak) in the Base Network. This provides a fully complete model platform from which to develop your other scenarios and allows you to add modifications to a consistent base model.
When you are then developing your second peak model (e.g. PM peak), you just need to create a modification file that changes the associated inputs from AM to PM. This can include, but is not limited to; flow inputs, signal timings, public transport departure times and simulation parameter time settings.
An example of this set-up is shown in Figure 2.
Figure 2 – Example Base Model Structure Set-Up
3) When developing scenario test models (e.g. future year and/or mitigation test scenarios), plan out your likely modification files in advance and minimise the number of files created.
When developing your scenario test models, think about how many modification files you are likely to need in advance. For example, if you are creating a future year base model (e.g. future year 2026), you may only need two modification files – one modification file for adding the 2026 AM peak flows and one modification file for adding the 2026 PM peak flows. If you need to make further changes to account for the future year operation (e.g. signal timing changes), then make these changes within the same modification files (but make a log of what you have changed for auditing purposes).
If your future year modelling includes coding in a junction improvement or a series of improvements, then you are likely to need a separate modification file that codes in the improvement – links, connectors, priorities, speeds, signals etc. This can be added to your future year scenarios in advance of adding any modifications associated with any future year flows and other peak specific changes, allowing the physical changes to sit in one modification file which is then associated with both peak scenarios.
An example of this set-up is shown in Figure 3.
Figure 3 – Example Future Year Model Structure Set-Up
4) Always work in Modification files and NOT Scenarios
In our experience of working in Scenario Management, we would recommend always working and making changes to the model within the Modification files themselves, whilst only using the Scenarios to view the models running. If you work and make changes in the Scenarios, there is a risk that you can create a ‘<generated automatically>’ modification file, that includes all of the changes that you have made.
Whilst this might be ok for that specific scenario and be understood by the individual modeller responsible for creating the file, there are likely to be questions raised during external audits of the models as to what these files are and why they have been included. Therefore, it is better to work within modification files, which are clearly labelled and described, in order to avoid future confusion.
5) Use the Project Structure window effectively
We have found that taking the time to fill out the Project Structure window with names and suitable descriptions has been advantageous in our modelling and we would recommend filling this out to easily distinguish between the various files, to open the correct one and to understand how they relate to each other when added together for creating ‘Scenarios’.
It also has the advantage of providing an informal log of the model development (for auditing purposes), allows multiple users to use the same model (through an understanding of what the files consist of) and provides a guide should the modelling need to be revisited in the future.
An example of a detailed project structure is shown in Figure 4.
Figure 4 – Example with Detailed Project Structure
6) Be aware of who is auditing your model
It is likely that your models will need to be externally audited for the model to be approved for use.
If your model is being submitted outside of London, then there is a good chance that you will be able to submit the model as produced and as one file, including all of the Scenario Management features.
However, if your model is to be submitted to Transport for London (TfL) through the VMAP process, then the latest guidance (Traffic Modelling Guidelines, Version 4.0, dated September 2021) recommends that each scenario is submitted as a single *INPX output. The extract from TfL’s latest guidance is provided in Figure 5.
7) Take care when revisiting previous scenario management and testing
When revisiting scenario testing from a previous modelling exercise, we advise that you try to avoid amending earlier modification files, especially those which other modification files are ‘dependent on’.
Figure 5 – TfL Guidance on Scenario Management
If you do use this approach, then there is a risk that an error related to not being able to open one of the other medication files pops up when you try and open a scenario. This is often because later modifications (which rely on the original modification set-up and ordering) have conflicting network object numbers or link/connector structure. You can overcome this, but it’s likely to be a time-consuming exercise to update all of the network object numbers to unique values.
We would consider it better practice to create new modification files to undertake further revisions to scenarios and link these to previously created files.
Summary
We hope this post is useful and has helped to provide a bit of insight into how we use Scenario Management in VISSIM.
It is appreciated that everyone uses this feature differently, but we hope that some of the points raised from our own experience help you either with starting out using Scenario Manager or refining your way of working with Modification files and Scenarios.
Thanks for reading!