Agents which are using PT GetStuckAndAbort

[ChristophTraf]

We are using MATSim to simulate of about 400 000 Agents and facing the problem that many agents which are using PT remain stuck at stop facilities. It seems they ‘are missing the vehicle (train, bus, subway) and wait until the end of the day for another one without changing their plan. The last two events of such agents look as following:

time="58497.0" type="waitingForPt" agent="agent1" atStop="atStop1" destinationStop="destStop1" time="108000.0" type="stuckAndAbort" link="link1" legMode="pt" person="agent1"

Is there any preplanning strategy in MATSim to avoid getting stuck? PT is simulated with SwissRailRaptor.

It would be nice if someone could help me with that. Thank you!

[tduberne]

This is the expected behavior. By defaults, agent in MATSim do not react to anything during the day: they stick to whatever is written in the plan, no matter how bad it is.

For public transport, the logic is that the agent will go to the stop, and wait for the next vehicle that serves the stop they want (if I remember well, it does not need to be of the same line/route as what the router found, but I did not double check). If there is no such vehicle, for instance because they missed the last service, they will indeed wait forever.

The idea is that this will result in a terrible score, leading plans with earlier departure times or other chosen modes to be selected in the long run.

Without more information about your setting, it is difficult to say more. In general, if this is really a big number of agents even at the end of the simulation, you probably need the following:

• make sure you have mode choice and/or departure time mutation enabled, otherwise your agents might not be able to find a good plan
• make sure you run enough iterations for the system to reach equilibrium. How much is enough depends on the scenario
• make sure "innovation" is disabled for the last few iterations. There is a "fractionOfIterationsToDisableInnovation" setting in the "strategy" config group, which you might want to set to something like 0.8 or 0.9 (meaning the agents will only use plans from memory after 80% or 90% of the iterations). Otherwise, mode choice and/or departure time mutation will always push agents to do "stupid" things, like taking PT after the last service or walking 50km.

[kainagel]

There is a switch setBoardingAcceptance in TransitConfigGroup. With that, one can switch from BoardingAcceptance.checkLineAndStop (= default) to checkStopOnly. In the second case it only checks if if the pt vehicle that is at the boarding stop serves the planned alighting stop, but not how. (Consequence may be that traveller picks a slow local train instead of a much faster express train coming shortly afterwards; this is why it is not switched on by default.)

It is currently only settable from code, not from xml. Can't say if this is a problem in the current situation. I guess we could be made settable from xml, but it would take some time until passed through the build system.

With the default setting, there is in particular a problem when transit schedules are fragmented, e.g. having different "lines" when there are several possible terminal stations, or different travel times between stops, etc. A typical situation in Berlin is that we have reinforcement lines, which sometimes operate only once per day during the peak period. So if the pt router finds one of those, and the agent misses it in the mobsim, then the agent is stuck forever. (I think that most of these could be encoded as different routes within the same line, but often this is just not the case.)

There is also the "common lines problem" in the literature, which is related to the problem here, and in some sense says that we will not be able to come up with a good answer without thinking really hard how we want to handle this. (One option would be to replan the transit route once the traveller has arrived at the stop, using real time information.)

Are you using matsim through IDE, or from config file? If through IDE, could you please change that config setting and report back?

[ChristophTraf]

@tduberne and kainagel: Thank you very much for your response! Our schedule is indeed very fragmented into several lines. In a small example we have moved transit routes from several lines into one common line. In that case, the agent used the vehicle, which arrived later at the stop.

Currently we are testing the new schedule with the entire population. We will run this simulation over the weekend and then test your suggested settings (We are using IntelliJ).

We are using the verion "0.11.0-2019w03" for MATSim and SBB

Our strategy settings are: ChangeExBeta: 0.7 ReRoute: 0.1 SubtourModeChoice: 01 cainBasedModes: car, pt, walk, bike

[ChristophTraf]

For the analysis of the transit schedule, we have simulated three scenarios based on following model-setups:

1.) baseScen: The base scenario is simulated based on the original transit schedule (fragmented transit schedule) 2.) StopOnlyScen: In this scenario, we used the same fragmented transit schedule but switched to “checkStopOnly” 3.) oneLineScen: For the last scenario, we have combined all transit routes into a single transit line and used the standard settings (checkLineAndStop)

Our strategy settings are: ChangeExBeta: 0.7 ReRoute: 0.1 TimeAllocationMutator_ReRoute: 0.1 SubtourModeChoice: 01 ->modes: car, pt, bike, walk; chainBasedModes: car

In scenario 1) many agents get stuck and abort. Compared to 1), the results of 2) and 3) show that fewer people get stuck, but also that generally less pt is used. The results for 2) and 3) are nearly the same. Please find attached the leg histograms for the iterations 0 and 8 for each scenario. Which settings from which scenario would you recommend for further model calibrations?

What also turns out is that agents from 24:00 got stuck and no arrivals occur. It is to be noted that the schedule includes departures also after midnight.

Thank you very much!!!

1) baseScen:

2) StopOnlyScen:

3) oneLineScen:

[mrieser]

scenario 2 and 3 should be very similar, as from an agent perspective the available PT is the same.

2) and 3) [...] but also that generally less pt is used

I can't reproduce this finding. The green line "en route" is lower in 2) and 3), but this is likely as much fewer agents are stuck. Looking at the number of departures (red) in the morning peak, the curves look very similar. In the evening peak, it's even higher in 2) and 3), likely due to fewer agents having been stuck in the morning peak and now able to travel in the evening.

[ChristophTraf]

Thank you, we misinterpreted the green curve. We will use settings from 2) for further calibrations. Hopefully this method does not have too many disadvantages (for example the use of a slow pt instead of a fast one).