Fix: Non-deterministic behaviour of SwissRailRaptor

[tkchouaki]

Hi @mrieser,

@sebhoerl and I noticed that some of our simulations were not determinstic (i.e, running the same simulation twice did not necessarily generate the same events and plans). After investigating we found out that there are at least 2 places in SwissRailRaptor that are not deterministic.

• DefaultRaptorStopFinder.findStops does not always return the same stops, we tracked this down to the initialization of the stops QuadTree in SwissRailRaptorData.create where stops are retrieved from a HashMap. We replaced it by a LinkedHashMap to always have the same order.
• After this fix, raptor still does not always return the same elements, we tracked this down to SwissRailRaptorCore.calcLeastCostRoute where some HashMap objects are also built then looped over, which we also replaced by LinkedHashMap.

This PR introduces a RaptorDeterminismTest class in ch.sbb.matsim with a unit test to uncover non-deterministic behaviour in SwissRailRaptor. Moreover, a DeterminismTest class is introduced in org.matsim.contrib.discrete_mode_choice to check that a whole simulation is deterministic.

The commits introducing the tests are separated from the ones introducing the fixes, so you can checkout each step and see what is being solved.

As some non-deterministic behaviour only appear in rare cases, we will incorporate some systematic checks on other simulation scenarios in our internal workflows and keep you updated if any other source of variability is identified.

Best,
Tarek Chouaki.

[steffenaxer]

Thanks for improving this. You spend probably some hours in investigating this issue!

[Janekdererste]

I would recommend adding a short comment, as the next person will otherwise re-replace the LinkedHashMap with a regular one, which tends to be faster.

[kainagel]

In general, in MATSim we replace HashMap by LinkedHashMap, since otherwise this too often leads to this non-determinism issue, and the LinkedHashMap seems to be only slightly slower. So the comment needs to be made if someone uses a HashMap, not a LinkedHashMap. :-) In the end, I guess we should in both cases make a comment. If I encounter a HashMap without a comment, I replace it by a LinkedHashMap.