Skip to content

Scenarios, Experiments, Results, and Replications

Aimsun Next simplifies and streamlines the many time-consuming tasks involved in transport modeling by keeping them within one traffic network document (the ANG file) and by making them as modular and flexible as possible. This reduces the need to repeat work or duplicate effort and improves consistency between scenarios. The principal means of doing this are provided by Aimsun Next scenarios, their experiments, results, and replications.

The diagram below illustrates the relationships between scenarios, experiments, results, and replications and is taken from the Project window of an Aimsun Next project.


Scenarios

The scenario object sets the main input and output objects for a simulation. It specifies the level of simulation and the traffic demand, transit plan, path assignment plan, master control plan and real data set for validation. Additionally, it can specify traffic management strategies and any alternative geometry configurations. Any API modules, required to extend Aimsun Next's capabilities for bespoke reasons can be activated here also.

Aimsun Next offers many different types of scenarios, including dynamic scenarios, static scenarios, and travel demand scenarios. The following screenshot of the Project menu illustrates most of the currently available scenarios and the first step of how to create one.


A scenario needs certain inputs. For example, the minimum requirements for a dynamic scenario are:

  • Base transport network
  • Traffic demand (vehicles and pedestrians entering and leaving the network via centroids)

The following screenshot shows the Main tab of a dynamic scenario.


You can also specify the outputs and output locations on the Outputs to Generate tab.


Experiments

An experiment is a means of testing and analyzing a scenario. It specifies the component models and assignment algorithms used in the simulation rather than the physical or infrastructural aspects of a project. You can add as many experiments to one scenario as you like.

The assignment approach defines the path and traffic assignment approach for the simulation. For dynamic models, if the Traffic Demand is coded with O/D Matrices and the modelled network provides routing alternatives, the definition and calibration of the route choice method plays a fundamental role in the validation of the model.

Aimsun Next provides two Dynamic Traffic Assignment (DTA) algorithms:

SRC calculates, at the end of each departure time interval (set by the user) of the running simulation, the least cost path, and distributes the vehicles between this path and the least cost paths calculated in previous intervals with a discrete choice function (Binomial, Proportional, Logit or C-Logit).

The path is assigned to each vehicle when it starts the trip; an option allows defining a proportion of enrouted vehicles, which repeat the route choice process while on-trip every time the costs are updated.

DUE is an iterative procedure aiming, for each O/D pair and each departure time interval (set by the user), that travel times experienced by vehicles departing during the same period are equal and minimal.

The progress towards a stable solution is measured by the Relative Gap (RGap), which is the relative difference between the total travel time actually experienced and the total travel time that would have been experienced if all the vehicles had had a travel time equal to that of the current shortest path.

The threshold of RGap that determines the achievement of convergence depends on the size of the network and on the level of congestion reached during the simulation period, but generally can be established between 5% and 10%.

In order to reduce the number of iterations to achieve convergence, and to achieve a better convergence the DUE process should be:

  • Started with an input path file produced, for example, with a macroscopic assignment; or
  • Run incrementally (i.e. increasing the demand and the number of alternative paths with the iterations).

The different assignment algorithms reproduce different levels of access to travel time information: DUE represents habitual drivers that base their routing decisions on historical knowledge of the conditions without real time information; SRC represents drivers that have access to pre-trip (non-enrouted) or on-trip (enrouted) information.

Aimsun Next allows providing to some of the vehicles in a one-shot simulation paths loaded from an input path file and paths manually defined, thus combining different route choice behaviors in the same simulation.

Which route choice algorithm to use and whether input path files should be calculated and re-used depends on the application of the model, on the amount of routing alternatives available in the modelled area and on observation of vehicle behavior. The table below provides some basic guidelines.

Model Type Route choice
Single junction or corridor with no route options Run SRC with fixed paths evaluated in free flow conditions
Route choice is available in the model but it is uncongested Run SRC with fixed paths evaluated at the end of the warm-up period
Route choice is available in the model, there is congestion, recurrent conditions are modelled Run DUE
Route choice is available in the model, there is congestion, recurrent conditions are modelled, the study requires to capture routing behavior of drivers who have access to pre-trip or on-trip travel time information Run DUE and save path file. Run one-shot in which drivers who have no access to travel time information use paths from the path file, drivers who have access to pre-trip information follow SRC paths and drivers who have have access to on-trip information are enrouted
Route choice is available in the model, there is congestion, non-recurrent conditions are modelled (e.g. accident or construction) Run DUE with a scenario representing recurrent conditions (e.g. no accident, no construction) and save path file. Run one-shot in which drivers who have no access to travel time information use paths from the path file, drivers who have access to pre-trip information follow SRC paths and drivers who have have access to on-trip information are enrouted. Use traffic management actions to divert vehicles from their habitual path (e.g. because they see a VMS)

In a dynamic experiment dialog you can specify:

  • Attribute overrides
  • Traffic demand warm-up
  • Pedestrian simulator
  • Pre-run and post-run scripts
  • Parameters for the microscopic and mesoscopic network-loading models
  • Reaction time
  • Arrivals
  • Parameters for dynamic traffic assignment
  • Traffic management policies

The following screenshot shows the Main tab of a dynamic experiment dialog with some preliminary parameters and settings in place.


You can find full descriptions of experiment parameters elsewhere in the user manual, for example in the topic Dynamic Experiment Editor.

To add a new experiment, right-click on the scenario and select New Experiment. When adding a new experiment to a scenario, the first decisions to make involve network loading and assignment approach. Network loading describes the granular level of simulation you want to run, which can be one of the following:


Results and Replications

For a dynamic experiment, a result or a replication is needed. This is sometimes known as a run. This object contains the random seed information for your simulation and then contains the outputs for this instance.

A replication object is used with SRC, and you can specify how many replications to run when adding it to the experiment. Each replication uses a unique random seed to produce and reflect variability. You can also choose to generate an optional average calculation to find the average outputs from a set of replications.

A result is used with DUE. Each result also uses a random seed to produce and reflect variability. You can also choose to generate an Incremental Result, which incrementally increases the demand over a set of iterations to allow the network to be incrementally loaded.

To add a replication to an experiment, right-click on the experiment below the scenario and select New > Replication:


To add a result to an experiment, right-click on the experiment below the scenario and select New > Result:


Example

A project seeks to analyze the impact of a new bridge in London, in 2022, across the AM period. It uses the following key elements:

  • Dynamic scenario London New Bridge 2022 AM (Main tab pictured below)
  • Traffic demand AM 2022 Traffic Demand
  • Geometry configuration London New Bridge 2022
  • Master control plan AM 2022 Control Plan
  • Transit plan AM 2022 Transit Plan
  • Real data set AM 2022 Real Data Set
  • Experiment London New Bridge Meso DUE Experiment
  • Experiment London New Bridge Micro SRC Experiment with 20 replications.


The first experiment is a meso DUE experiment which contains an attribute override of the new speed limit in the area around the new bridge. This produces one result with a random seed.

A second experiment, which is a micro SRC experiment, uses the paths from the first experiment for 20 replications that use different random seeds (Main tabs of both experiments pictured below.)


The following screenshot shows most of these elements in the Project window.


Static Experiments

Some scenarios and experiments don't use simulations named "Result" or "Replication" but instead use experiments named directly after the scenario because there is no stochasticity in the models for which a random seed is needed.

For example, for a generation/attraction scenario, you would right-click its experiment and select Run Generation/Attraction and, for a static assignment scenario, you would right-click its experiment and select Run Static Traffic Assignment.