Playground test failures

Dear MATSim community,

You have probably noticed that we have recently separated "matsim"+"contribs" on the one hand from "playgrounds" on the other hand.

This also means that the playgrounds are now tested separately both on travis and on jenkins.

Several people have, in the past, nudged people to repair playground test failures.  

I now want to announce that I essentially will no longer be one of these people.  I have just switched off my monitoring apps for these tests.  This means that if the system notifies me of a failure which I may have caused, I will still look at it, but if other people make the playgrounds fail, I will not act any more.

Maybe some other group in the community wants to self-organize to take this on.  An alternative, clearly, is that people who mostly want to monitor their own code, could pull out into a separate repository.  The matsim-example-project points the way for this.  The arguments in both directions in my view are:

  • playgrounds are a service from us to the community: they are included in refactorings.  Separate, individual repositories are in general not.
  • A downside of the playgrounds, however, is that if one of the playgrounds has a compile error, none of the playgrounds is tested.

In the longer run, our goal would be to get rid of playgrounds completely.  However, we are still refactoring our API, and as long as we are still doing this, we will keep them.

So maybe a group of people who want to keep their playgrounds functional wants to form and jointly make sure that the playground tests do not fail.  You could, for example, start self-organizing via "comment" posts under this blog entry.

Best wishes


Dear all, thank you for your contributions! The report for April-June is now online.  I got only very few contributions. I assume many of you are in "TRB writing mode" (Kay Axhausen's copyright). But if you missed the call for contributions, please have a look and let me know in case something needs to be updated. Happy writing!

Dear all, you are kindly requested to provide your contribution for the latest MATSim report until Friday, July 7th.

Thanks! Francesco

As announced, the playgrounds have moved to their own GitHub repository.

Tests are run by Travis and Jenkins – as before, Travis runs Tests, and Jenkins also runs Integration Tests.

A few integration tests are currently failing, probably because of file references to outside the repository. Please check.

Action required for those who have playgrounds:

We are moving them out of the matsim git repository into their own one. See e.g. MATSIM-676 - Getting issue details... STATUS  or MATSIM-685 - Getting issue details... STATUS  or MATSIM-680 - Getting issue details... STATUS for discussion.

This mostly means that you will have to check out this new repository separately, and put it next to the current repository into your (e.g.) Eclipse workspace. (Don't try to put it inside the current repository.) IDEs like Eclipse don't care much – they resolve dependencies within the same workspace on their own.

On the other hand, it means that if you are developing neither the core nor a contrib, you now probably need to check out only the playgrounds!

I plan to do this on 2017-06-29. I will briefly block pushes to matsim, create the new playgrounds repository, and re-open matsim. It will be easiest if you have everything committed by that time – though it should also be easy to transfer your changes to the newly checked-out playgrounds repository. After all, the directory structure is not going to change. 

In parallel to the still open position for MATSim modeling, the Swiss railway operator SBB is accepting applications for internship at university level. The offer can be found on the job portal of the SBB, under reference number 26261, or in this PDF (both in German).


                              IEEE MoD@ITSC 2017

                1st Workshop on Modelling, Analysis and Control of
                       Intelligent Mobility-on-Demand Systems            

                         co-located with IEEE ITSC 2017                       
                      October 16-19, 2017, Yokohama, Japan



After decades of little innovation, personal urban mobility is undergoing rapid transformations due to the introduction of disruptive technologies (e.g. connected and driverless cars), new IT applications (e.g. app-based services) but also due to changes in individual preferences and social behaviours, with a growing trend towards a shifting from car ownership to sharing. This gave new life to several mobility on demand (MoD) services which were ideated decades ago but never established themselves as viable mobility solutions and created new variations of them, such as ride-sharing, bike-sharing programs, car-pooling and car-sharing services, on-demand bus and delivery services, etc. The rapid growth and the forecasted (large) scale of these new mobility services is expected to radically change individual travel patterns, and conventional frameworks for the modelling, analysis, simulation and control of transportation systems are not appropriate any more. For instance, novel demand modelling tools are needed for measuring, modelling and predicting behavioural choice and individual preferences for the new mobility solutions, as well as forecasting the level of market uptake of the different mobility services. Similarly, new analytical models and simulation frameworks are required to accurately characterise the peculiar properties of MoD systems. Then, the insights obtained may serve as basic input to advanced optimization frameworks, which can provide decision tools for the planning and optimal operation of such systems. Key issues to address are infrastructure planning, fleet sizing and management, supply rebalancing, and efficient cooperation with other transportation modes (e.g. public transport).

The goal of this workshop session is to provide a forum to exchange ideas, discuss solutions, and share experiences from industry, researchers and the public sector. We solicit original papers covering different aspects of MoD systems, including modelling, optimisation, management systems, field applications and new paradigms.

Topics of interest include, but are not limited to:

- Data mining, machine learning, and data analytics for MoD systems
- Large scale simulation of agent-based models for MoD systems
- Modelling, analysis, and control of MoD systems
- On-demand mobility in Public Transport
- Cooperative Systems and Connected Vehicles for MoD services
- Autonomous driving for MoD services
- ITS technologies for MoD services
- Social and emergent behaviours for MoD services
- Travel behaviour and travel demand for MoD systems
- Discrete choice modelling for MoD systems
- Field tests and implementation of MoD services
- Cooperation between different modes of MoD
- MoD and Smart Cities
- Complex network theory for MoD systems
- Robotic MoD systems
- Electric MoD systems
- Operations research in MoD systems
- Drones as the new frontier for MoD

Submitted papers must be no longer than 6 pages, and should adhere to the standard IEEE conference proceedings format. Reviews will be single-blinded. Papers should neither have been published elsewhere nor being currently under review by another conference or journal.

Paper should be submitted via EDAS using the following link:


- Submission Deadline:        30 June 2017
- Acceptance Notification:    25 July 2017
- Camera Ready Due:         10 August 2017


Chiara Boldrini (IIT, Italian National Research Council)
Raffaele Bruno (IIT, Italian National Research Council)
Francesco Ciari (Institute for Transport Planning and Systems, ETH Zürich)
Hironori Kato (Dept. of Civil Engineering, The University of Tokyo)

The national Swiss railway operator is still searching for MATSim experts.

A new job offer (in german) is online, and can be found on the SBB Job platform, searching for reference number 26190.

Alternatively, the description is available as a PDF Document.

Feel free to forward this announcement to anybody who might be interested.


Just like last time, we quietly performed a release, triggered by the course we teach. This allows us to test it in this course. Bug-fixing, and possibly finishing half-done features, can happen in the v0.9.x branch, and we can do further v0.9.x releases whenever we like (suggestions welcome).

In the meantime, we could prepare a changelog and release notes, and then make the next v0.9.x release a more broadly advertised one.

If you can, please switch your non-playground code dependencies to this release version. If you cannot, remember to switch them to 0.10.0-SNAPSHOT as soon as master compiles again.

Any development which is done on v0.9.x should, of course, also be merged into master. The cleanest way to do this is to develop on a personal branch which is branched off master at some point before today, and, when you're finished, merge that branch into both v0.9.x and master. (Careful: Not the other way round.)

Update: Apparently, there are issues with (I would guess) Bintray's delivery network. Currently, Maven artifacts will sometimes only download on the second attempt, failing some builds. Let's see how this develops.

Dear community,

With a recent commit I changed the default for the scoring behavior.  

In the past, any mode encountered in the plans file that was not specified for scoring was treated as TransportMode.other, which had some default scoring parameters.

With the new version, such code will now throw an exception during scoring and then abort.

Reasons for this change:

  • The old behavior was automagic, and we are trying to move away from automagic.  The most recent problem that this one here caused was that someone had mode=“pt_slow” in the plans file, but mode=“slow_pt” defined in the scoring section of the config file.  Evidently, the code ran without problems, but used the pre-specified scoring parameters of TransportMode.other rather than the intended ones.
  • We would also say that the config structure should now be flexible enough to fully specify such situations, so the code does not have to hedge as much as before against plausible but not configurable use cases.

In config v2 format, you will need something like

		<parameterset type="modeParams" >
			<param name="constant" value="0.0" />
			<param name="marginalUtilityOfDistance_util_m" value="0.0" />
			<param name="marginalUtilityOfTraveling_util_hr" value="-6.0" />
			<param name="mode" value=“mySpecialMode" />
			<param name="monetaryDistanceRate" value="0.0" />

Best wishes



Just in case you did not hear yet about it. Not really playing in the same playground, but for sure we will hear again about them:

At our chair (Transport Systems Planning and Transport Telematics (VSP) at Technische Universität Berlin), there is an open position as research associate (Salary grade E13 TV-L).

We are looking for somebody who will work on the research pro­ject “Car­rier Agents and Inter­ac­tions with Traffic Flows” fun­ded by Deutsche Forschungs­ge­meinsch­aft (DFG), which deals with the agent-based sim­u­la­tion of freight trans­port using MAT­Sim.

Please find the call here and feel free to share this information with anybody who might be interested.

Michał and Joschka have added DRT (demand responsive transit) as a contrib: .

The Swiss national railway operator, SBB, published a job offer to consolidate its demand modeling team with a MATSim specialist.

The job description and contact details can be found in the following pdf files, both in German and in English. Alternatively, the job offer can be found on the SBB Job Offer Portal, with reference number 25894 (giving access to an online application form, in German).

Feel free to forward this information to whoever might be interested.

Dear all, thank you for your contributions! You can find the new report, which is now quarterly, here: Report 1 (January-March)