Bus delays, scaling & Hermes

[gac55]

We are experiencing bus delays in a similar fashion to many previous users when running smaller sample simulations (e.g. this). We are also seeing similar manifestations of delays on links.

We have performed PCE scaling on the transit vehicles, as is normal. We have also experimented with flow and storage capacity tweaks (with limited results and the theory doesn't stack up either)

In 2017 a PR was applied where a pcuThresholdForFlowCapacityEasing was introduced to stop bus buses from waiting too long before entering the buffer in a sub-sampled scenario. However, this appears to be only for QSIM.

How does Hermes handle this issue?

[gac55]

Looking at the Hermes code I see ftns I do not understand, for example this

where:

            //downscaling of vehicles = Upscaling of PCUs

[michalmac]

//downscaling of vehicles = Upscaling of PCUs

I guess this means: downsampling vehicles = making each of them bigger (while keeping the links unchanged). This is different to how scaling is handled in QSim.

[gac55]

//downscaling of vehicles = Upscaling of PCUs

I guess this means: downsampling vehicles = making each of them bigger (while keeping the links unchanged). This is different to how scaling is handled in QSim.

Thanks @michalmac . Indeed, it does.

Yet the Hermes introduction here states similar behaviour to QSIM:

Hermes supports different vehicle types and PCUs. If PT is used on a congested network, the PCU equivalent for the transit vehicles should be defined in accordance with the sample size (i.e., for a 10% sample, a PT vehicle's PCUe should be set to 10%). For all other vehicles, an automatic scaling is performed.

I am misunderstanding something somewhere.

[kainagel]

Maybe the following is all clear, but just in case (for QSIM):

When you are running a 10% scenario, then you set flow and storage cap factor 0.1 and that is it for passenger cars. And one passenger car in that 10% simulation stands for 10 in reality.

However, if you have a bus every 10 minutes, you want to keep that bus every 10 minutes. So you do not have that one bus in the 10% scenario stands for 10 in reality, but each bus in the 10% simulation stands for 1 in reality. Accordingly, we recommend to make these buses smaller. Since buses are normally something like pce=3, it would be 0.3 (@ 10%).

Now one still gets that if there are two of these buses close to each other, then the second one has to wait rather long until it is allowed to leave that link. In order to improve this, the above-mentioned pcuThresholdForFlowCapacityEasing was introduced. It means that for each vehicle with PCE/PCU smaller than that value, it can leave the link despite the capacity restriction. Which then means those buses, since the normal vehicles have PCEs >= 1.

---

For HERMES: I think that what was discussed above is correct: there are no flow/storageCap factors for Hermes; you have to modify PCUs yourself. And the capacity easing presumably is not implemented at all.

[gac55]

Thanks @kainagel, that is clear.

Since we are performing the required steps it appears there may be a need to add capacity easing for Hermes

[andkay]

Thanks all for chiming in all. Hoping I can clarify a couple points.

We do maintain a scaled vehicles file, with the following parameters for buses:

<passengerCarEquivalents pce="0.28" />

First, the magnitude of delays on a single link can range above 500 minutes. The bus delays are symptomatic and provide quite a nice summary review of the performance -- but these delays impact car driving agents as well. The problematic links appear to have generally reasonable settings for flow capacity, length, and lanes.

It is definitely possible that private vehicles are getting stuck behind the transit vehicles (which are, themselves, stuck on these links), but we can see this happening both microscopically at the event level and in the experienced plans as well (exhibited by short car trips with unreasonable durations in the selected plans).

In terms of the problematic links -- there is a tendency for these be on the short side, but we have experimented with network alterations without success.

Things we have tried include:

• Lowering the pce for buses as far as 0.01. Helped a little bit, but results still a significant quantum of delays
• Setting a minimum link length in the network of 50 meters, which tended to make things worse (similar delays over longer distances).
• Increasing storage capacity, with and without a similar increase in flow capacity. As an experiment, a combined increase in flow/storage capacities up to 0.2 did help reduce some extreme delays, but did not solve this problem.

I'd also add to @gac55 's comments that similar problems exist in prior simulations of the same population using QSim -- although we have not tried the capacity easing.

[kainagel]

Seems to me that in this case the next logical step would be to re-run with QSIM and capacity easing and see if the problem persists.

Re the individual car travel times: Assume you have a link with capacity of 900/hr, i.e. 1veh/4sec. If you go to 10%, then it becomes 1veh/40sec. So if there is one vehicle immediately in front of you, you have to wait for 40sec until it is your turn. In consequence, with these downsampled simulations, there can be fairly large fluctuations of the travel time even from one iteration to the other.

[gac55]

Thanks @kainagel . We submitted a job with the capacity easing a few hours ago, we await results

[gac55]

We are struggling to follow your example.

Relevant part of controller:

Config config = buildConfig(configFilename, roadPricingFilename);
config.qsim().setPcuThresholdForFlowCapacityEasing( 0.3);

The error:

Exception in thread "main" java.lang.IllegalArgumentException: Module qsim of type org.matsim.core.config.groups.QSimConfigGroup doesn't accept unkown parameters. Parameter pcuThresholdForFlowCapacityEasing is not part of the valid parameters: [mainMode, trafficDynamics, usePersonIdForMissingVehicleId, timeStepSize, insertingWaitingVehiclesBeforeDrivingVehicles, useLanes, usingFastCapacityUpdate, snapshotStyle, vehicleBehavior, removeStuckVehicles, isSeepModeStorageFree, flowCapacityFactor, nodeOffset, linkWidth, storageCapacityFactor, startTime, vehiclesSource, seepMode, numberOfThreads, linkDynamics, snapshotperiod, isRestrictingSeepage, stuckTime, usingThreadpool, simStarttimeInterpretation, endTime, simEndtimeInterpretation]

We moved back to a 12.x tagged version of matsim, it must be this is not present in that version.

[kainagel]

If the command is there in code, then it is also implemented. Maybe you put it ALSO into the xml? There are options that exist in code but not in xml.

[jfbischoff]

In general, vehicle PCUs are, as @michalmac points out, upscaled with Hermes and the capacities are left as they are. This is an opposed approach to how QSim is handling it but will in most cases behave similarily.

Unfortunately Hermes doesn't have any exceptions programmed for Transit Vehicles as with the pcuThresholdForFlowCapacityEasing in Qsim. Adding it would probably be possible without too much effort, but requires a whole lof of testing.

(On a side note: We are running our public transport with the deterministic option, so it always runs on time, thus the problem never occured to us. )

[gac55]

Thanks to @akay-arup for this summary.

Just a small update on this to help close out this issue and record some of our findings for the community.

We've run a number of experiments and have identified some of the issues that were causing massive delays.

The delays do not appear to be related to any one factor, but some combination of the below:

• Some specific networking coding issues where capacities fluctuate along corridors. The complexity of our networks (national scale with high levels of detail) tend to make these a bit difficult to diagnose.
• Specifics regarding the plans in the synthetic population. In particular, introducing more spatial and temporal heterogeneity into the the input plans makes a significant difference.
• Scaling is generally a problem -- but tends to compound the above issues.

We've not eliminated unrealistic delays from our simulations yet, but tackling some of the demand and supply side inputs has helped quite a lot. We suspect that the remainder is related running 10% simulations and it may be necessary to increase that quite a bit.

While we initially suspected that the issue was related to transit vehicles issue because it's quite easy to identify the deviations from schedule -- in reality, it stems primarily from private vehicle trips. Essentially, we find extreme traffic jams that also cause unrealistic delays for buses.