generated on 2019-05-24 00:19:28.923080 from the wiki page for MESO for SUMO git
(Redirected from MESO)

From 30.000 feet

Starting with version 0.26.0 the mesoscopic model is available in the SUMO distribution (MESO has been developed alongside SUMO since 2002 but was not publicly available). MESO refers to a mesoscopic simulation model which uses the same input data as the main SUMO model. It computes vehicle movements with queues and runs up to 100 times faster than the microscopic model of SUMO. Additionally, due to using a coarser model for intersections and lane-changing it is more tolerant of network modelling errors than SUMO.

Purpose: Simulates a defined scenario
System: portable (Linux/Windows is tested); runs on command line
Input (mandatory):
A) a road network as generated via NETCONVERT or NETGENERATE, see Building Networks
B) a set of routes (as generated by DUAROUTER, JTRROUTER, DFROUTER, or ACTIVITYGEN, see also Definition of Vehicles, Vehicle Types, and Routes)
Input (optional): Additional definitions of traffic lights, variable speed signs, output detectors etc.
Output: SUMO allows to generate a wide set of outputs; visualization is done using SUMO-GUI
Programming Language: C++

Usage Description

The mesoscopic model uses the same input files and generates (almost) the same outputs as SUMO. To use MESO the option --mesosim <BOOL> must be set. Additional options are described at SUMO#Mesoscopic

Model Description

The simulation model is based on the work of Eissfeldt, Vehicle-based modelling of traffic. The original model was focused on motorway traffic. The current implementation contains significant extensions to support the simulation of heterogeneous urban traffic as well.

Longitudinal Model

Vehicles are placed in traffic queues with a maximum length specified by option --meso-edgelength. To accomplish this each edge is split into 1 or more queues of equal length. Generally a queue represents all lanes of an edge but at intersections with dedicated turning lanes, multiple queues are used. Vehicles generally leave the queues in the order in which they entered it. The core idea of the model is to compute the time at which a vehicle exits the queue according to the following criteria:

  1. the traffic state in the current and subsequent queue.
  2. the minimum travel time based on vehicle speed, and speed limit
  3. the state of the intersection for the last queue of an edge according to the configuration of the #Junction_Model

The first point is accomplished by classifying each queue as either jammed or free according to a traffic density threshold (configured with option --meso-jam-threshold). The minimum headway between vehicles is then computed differently for each of the four distinct possible cases. The behavior for each case is configured using the options

  • meso-tauff
  • meso-taufj
  • meso-taujf
  • meso-taujj

Backward-moving jams are possible due to the headway effects when meso-tauff is lower than meso-taujf.


For each queue (also called segment in the GUI) an occupancy threshold value determines whether that queue is jammed or free. The following nmerical values are supported for option --meso-jam-treshold <FLOAT>:

  • value = -1: Threshold is computed so that vehicles driving at the speed limit do not jam. This is the default behavior which is recommend to for networks with varying speed limits since the free-flow occupancy depends on speed.
  • value < 0: Threshold is computed as above but the free-flow occupancy is computed for (speedLimit * -value). As this value approaches 0 (from below) jamming is reduced. Values below -1 cause increased jamming
  • value > 0: The value is used directly as the threshold fraction for all queues (i.e. 0.4 means that above 40% occupancy the queue is jammed)
  • value = 1: Jamming is disabled

Further Congestion Effects

Another mechanism which creates a negative correlation between density and speed comes through vehicle (preferred)-speed distributions. At higher traffic densities the probability of being slowed down because a slow vehicle is ahead in the queue rises. This effect size can be controlled by changing the spread of the speed distribution. On multi-lane edges, overtaking can be enabled to reduce this slow-down effect.

Lateral Model

Lateral movement is not modelled explicitly. Vehicles may overtake each other (swap their position) if the option --meso-overtaking is enabled. This is a randomized process depending on vehicle speeds and density.

Junction Model

There are 3 basic options for modelling junction control

  1. --meso-junction-control false (the default): No junction control takes place. This should only be used for motorway scenarios.
  2. --meso-junction-control true: junctions are modeled as in the simplified microsim model (--no-internal-links true).
  3. true: No junction control takes place as long as the target queue is in the unjammed state (free). When trying to enter a jammed queue, junction control as in case 2 is used.

Additional options can be combined with any of the above options:

  • --meso-tls-penalty <FLOAT>: a time penalty is applied according to the average delay time (based on red phase duration) and the minimum headway time is increased to model the maximum capacity (according the the proportion of green time to cycle time). This takes precedence over any of the above --meso-junction-control settings for tls controlled intersections. FLOAT is used as a scaling factor that roughly corresponds to coordination (1.0 corresponds to uncoordinated traffic lights, 0 to perfect coordination).
  • --meso-minor-penalty <TIME>: a fixed time penalty is applied when passing an unprioritzed link (this is disabled when is set and junction control is active for that link)


Many of the output options of SUMO are supported but the resulting files differ somewhat:

  • No lane specific output is possible.
  • Induction loops write attributes that are similar to meanData output

The following outputs are not supported:

Limitations compared to SUMO

The following SUMO features are not supported:

  • TraCI (planned for the future)
  • Electric model
  • Wireless model
  • Opposite-direction driving
  • Sublane-model


The mesoscopic simulation can be observed with SUMO-GUI when running with option --mesosim. The difference between micro- and meso-simulation is not visible from isolated vehicles. Once there are multiple vehicles waiting in a queue it becomes more apparent due to differences in spacing between the vehicles. And from the fact that vehicles appear to jump in 100m increments (which is the default segment length). When right-clicking on vehicles or edges and selecting 'Show parameters' the set of values is different between the microscopic and mesoscopic model. For larger simulations the speed difference will also be noticable. Due to being based on edges rather than lanes, some of the visualization options are different when running the mesoscopic model as well.