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, butmode=“slow_pt”
defined in the scoring section of the config file. Evidently, the code ran without problems, but used the pre-specified scoring parameters ofTransportMode.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" /> </parameterset>
Best wishes
Kai
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: