MATSim vs. ...

Questions keep coming up how MATSim compares to other traffic simulation systems.  Comparing them is not easy, since this is software, and since all of our softwares are Turing machines, they are all Turing-equivalent.  It is just that some things are harder to implement than others with a certain software design. 

Maybe let us start with some categories (sub-headings in the following).

I tried to keep the material somewhat short.  We should provide references to more extensive material; most if not all of this is covered in the MATSim book (http://matsim.org/the-book).

Also see http://matsim.org/docs/userguide/terminology .

Demand description

MATSim

MATSim demand is given by plans.  Each plan is a sequence of activities (home, work, leisure, ...), together with locations and (typically) end times. Activities at different locations are connected by legs.  Trips are constructed from multiple legs; for example "home - walk - bus - train - walk - work" is seen as a multi-modal "walk-bus-train-walk" trip.

Network loading

MATSim

Each agent has several plans.  One of them is "selected" (see "choice" below).  During the network loading (called "mobsim" or "synthetic reality" in MATSim), each synthetic traveller synthetically executes her plan.  This essentially means: starting at the first activity given in the plan, departing at its pre-determined activity end time, following the travel description in the plan including possibly being stuck in congestion or not being able to enter a bus, eventually arriving at the second activity and staying there until its end-time, etc.  For within-day re-planning see below.

The MATSim mobsim is a model that treats all entities (persons, vehicles, links, intersections, signals, ...) individually (i.e. a "microscopic" simulation), but apart from that often at a not very high level of detail (which would make the vehicular dynamics a "mesoscopic" model).  Within these constraints, it attempts to be fast – typically simulating 24h of with several millions of travellers in about a minute (using a 1% sample) or in about 10 minutes.

The vehicular dynamics is a queue model; recent versions include full kinematic waves (with piecewise linear fundamental diagrams) obtained from a double-ended queue.

Public transit is fully schedule-oriented, i.e. there are pt vehicles have (possibly automatic) drivers which follow their pt plans, loading and unloading passengers as they go.


Iterative procedure

The MATSim approach allows to decompose into choice set generation, and choice. Not all models can be decomposed in this way, though, which is why there is this rather monolithic section.

MATSim

Choice set generation

Heuristic, over the iterations.  Agents are randomly selected for re-planning; during re-planning a new plan is added to their choice set.  Normally by selecting an already existing plan and modifying it.  The innovation dimensions are configurable; typical innovation dimensions are: new routes (typically approximate best reply to previous network loading), new activity end (= departure) times (typically random variation from existing times), new modes (typically random variation of existing mode).

Again, it is important to stress that this adds to the choice set; it does not perform choice.  (Although, clearly, agents can only chose what was added to the choice set before.)

Choice

Choice is based on a two-step procedure:

  • Scoring.  After plans were executed in the network loading (called "mobsim" or "synthetic reality" in MATSim), they are given a score.  The score is similar to what we know from random utility models, but is valid for the full simulation period (typically a day).  It gives positive score contributions to activities, and (typically) negative score contributions to travel.
    Scoring is fully configurable (can be programmed in Java).
  • Choice.  Choice is essentially just a plain multinomial logit model, between all plans in an agent's choice set, based on the score.

Non-iterative (= within-day re-planning) capabilities

MATSim

MATSim primary design goal was fast iterations while keeping the composing elements microscopic, and within-day re-planning, albeit clearly important, was not fully consistent with that design since it makes the network loading slower.  In the meantime, it has evolved to something that is actively used, for example for the simulation of autonomous vehicles.  The approach is that the mobsim "asks" the person certain things at certain points in time, e.g.:

  • Which link is next? (at an intersection)
  • Do you want to arrive here? (on a link)
  • Do you want to board this bus? (to passenger waiting at bus stop)
  • Do you want to get off this bus at this stop here? (to passenger in bus)
  • ...

In the default implementation, these questions are answered by looking into the plan (see above).  However, the default implementation can be replaced, and then these questions can be answered by other means, e.g. from computations performed while the agent is under way.