A way to increase traffic during physsim without using more actors in agentsim.

[nikolayilyin]

There is a problem with flowcapacity. Because we almost never simulate more than 0.1 of the population we are using a low value of flowcapacity. This leads to many problems according to rounding for small capacity nodes, in the end vehicles are using not the same roads as if we simulate full population.

There is an idea to create duplicates of PTE events during physsim.

[zneedell]

My initial thoughts--

What we're doing right now when we're simulating e.g. 10% of the population is that in physsim we are treating each vehicle as the equivalent of 10 vehicles when it comes to the amount of road capacity they take up. For highways this is probably fine, but for smaller links it pretty much means that there aren't many options between empty (with free flow speeds) and jammed (with very slow speeds), which makes the results noisy and makes it difficult for the network to relax.

I can think of three main ways in which we lose realistic diversity of traffic patterns:

1: Lack of OD diversity: We're only simulating 10% of all of the specific OD pairs, so there are probably a bunch of specific origins and destinations where there is significant sampling error. When aggregating up to the TAZ level this is probably fine, but there could be issues associated with some small feeder streets reaching capacity when in reality demand is more spread out. This also appears to be related to the problem Haitam is running into with charging demand, which should really be spread out over TAZs rather than all coming from the smaller discrete set of locations that are the result of our population sampling.

2: Lack of route diversity: For a given OD, if there are two reasonably good routes we should expect the traffic to be split between the two routes, but having a low sample size means that the assignment is more all-or-nothing, which will also make it harder to reach equilibrium.

3: Lack of time diversity: Even if there is only one good route for a given OD, we would expect the '10 cars' represented by a given agent to be spread out over some time rather than all departing at the same time. Spreading departures across time could also lead to less all-or-nothing congestion on small links.

In terms of solutions, I think that duplicating pathTraversal events for physsim and then modifying their departure time would address 3 but not the others. 2 could be solved either by loading multiple plans for every individual into physsim (which could get complicated) or using RoutingKit potentially. Addressing 1 would be especially hard.

[nikolayilyin]

The solution #1 for the problem will be the following:

• add configuration value for fraction of plans to duplicate/preprocess before physsim
• before physsim preprocess plans by adding duplicates of plans with car mode

[zneedell]

Sorry I missed standup but I agree that this might be worth trying now. I think a simple way of doing it is to have a configurable time window (e.g. 15 minutes) and a configurable scaling factor (potentially not even an integer), and we generate n different physsim trips with the exact same route, with a departure time sampled uniformly from that time window. This may not lead to enough route diversity to allow convergence, but it's simple enough that it could maybe work.

Happy to talk more about it either at tomorrow's standup or before

[nikolayilyin]

Approach with creating of PTE duplicates was implemented, it seems it is possible to increase population during physSim without increasing population of agentSim. The PTE duplicates has different departure time but the same route, and we are not sure this is the best approach.

Next steps:

1. figure out a better way to estimate physSim simulation correctness
2. try to create duplicates with changed start/end points within the same TAZ and different route (if it is possible)

[nikolayilyin]

There are different routers (CCH, GH) that might be used to create path traversal duplicates with different start/end points (within the same TAZ). Also CCHRoutingAssigment as PhysSim might be used to do physSim with duplicates faster, and, probably even without using router for path traversals (CCHRoutingAssigment might not require routes, only start/end point)