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.
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.
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-676Getting issue details...
MATSIM-685Getting issue details...
MATSIM-680Getting issue details...
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
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.
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
PAPER FORMAT AND SUBMISSION INSTRUCTIONS
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: https://edas.info/newPaper.php?c=23861&track=86364
- Submission Deadline: 30 June 2017
- Acceptance Notification: 25 July 2017
- Camera Ready Due: 10 August 2017
PROGRAM COMMITTEE CHAIRS
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
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.
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.otherrather 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
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 project “Carrier Agents and Interactions with Traffic Flows” funded by Deutsche Forschungsgemeinschaft (DFG), which deals with the agent-based simulation of freight transport using MATSim.
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: https://github.com/matsim-org/matsim/pull/63 .
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.