feat: a new scenario cutter without mode choice limitations

[tkchouaki]

Introduction

The existing RunScenarioCutter allows to focus on one small area of a large simulation by considering only the agents that travel in that area at some point during the simulation. The road network, the transit schedule as well as the plans of the concerned agents are 'cut' inside this area. outside activities are inserted in the agent plans when they enter or leave the area, and the whole activity sub-chains that take place outside are replaced with trips using the mode outside. This functionality allows, for instance, to study DRT systems on a small scale and perform fleet sizing simulations that take much less time than simulations of the whole area.

However, one limitiation of the the current functionalitty is the restriction introduced on the mode choice. To keep plans that are coherent on the global level, tours with an outside activity are not considered by the DMC model. In some cases, these can represent a large proportion of the overall tours. Which prevents from fully assessing the impact that a new service would have.

Functionality

In this PR, we trade this limitation against another one. We propose an approach that does not restrict the mode choice model but rather assume that the travel times outside the study area are not impacted by the new services that will be added later on.

The RunScenarioCutterV2 does not exactly cut the network, the transit schedule or the plans. Rather, the population is filtered to keep only the persons that travel in the study area, the same ones that would be left by the old functionality, with the difference that the plans remain intact. A first run of the overall simulation is required beforehand as the converged travel times need to be measured before being fixed outside the area of interest. In this version, we require the input config and the original simulation to use the VDF functionality available in Eqasim.

The resulting scenario will the same network and transit schedule, have a smaller population and a DMC model configuration that considers all tours. So a simulation of it will take longer than a simulation of a scenario resulting form the base cutter, but still faster than the original simulation.

Technical implementation

The tool, available in the org.eqasim.core.scenario.cutter.RunPopulationCutterV2, requires the following arguments, most of the arguments supported are also supported by RunPopulationCutter with the same meaning, these will not be elaborated further here:.

• --vdf-travel-times-path (required): A binary file, named vdf.bin by default, written by Eqasim and containing the travel times observed by the VDF module. The travel times recorded in this file will be the input of the VDF module in the resulting scenario for the first iteration. Moreover, the VDF module will be configured to update only the travel times that are inside the study area. For the rest of the network, the travel times recorded in this file will be used during the whle simulation.
• --flag-area-link-modes (optional): true or false. If true, the tool will tag the links inside the study area by adding allowed modes that are the same as the pre-existing ones prefixed with inside_. However, the subnetworks consisting of each of the new modes are cleaned to make sure they are fully connected (So not every link inside the study area will end up with inside_... modes).

A simple approach was adopted for the code implementation of this functionality. We basically call the exisitng RunScenarioCutter and then we process the original population and remove all persons with an ID that does not appear in the scenario resulting from the first cutter. This takes more time than necessary as the network, transit schedule and plans are processed whereas we only need to know which agents are in the area at some point during the day. Future works will simplify the code to speed-up the tool.

Unit test

This functionality is tested during the TestSimulationPipeline.testPipeline unit test. The cutter is executed on the output of a simulation using the VDF functionality. Then, a DRT simulations is performed with a service active only in the cut-out area. We make use of the flag modes added by the cutter to have a smaller DvrpTravelTime matrix.

First results

We tested this functionality on a simulation of ile-de-france, focusing on the area of Dourdan in the south of Paris, and simulating an intermodal DRT system enabled by the feederDrt module available in Eqasim. We compare the simulations of the whole Ile-de-France area with the whole population (with the intermodal DRT system available only in Dourdan), the simulation of the scenario resulting from the existing RunScenarioCutter, and the simulation resulting from the cutter proposed here. We measure the run times and the number of requests generated by the DMC model in each simulation.

The results show that this cutter is able to identify a demand close to the one that would be identified by a full simulation while still requiring much less time as shown in the table and figure below.

simulation	number of requests in the last iteration	run time (minutes)	number of requests compared to Full IdF	run time compared to Full IdF
Full IdF	2999	4086	100%	100%
Legacy cutter	1470	25	49.0%	0.6%
Proposed cutter	2975	98	99.1%	2.4%

Conclusion

This work is described in more details in a paper submitted for presentation at TRB2025 (Chouaki, T., Hörl, S. (2025) A method for efficiently assessing the impact of local mobility services in large-scale agent-based simulations).

In the following months, the code will be reworked and the process simplified as explained above. Moreover, further benchmarks of this functionality will be performed in the next months. A proper documentation on how to use it will also be written.

[sebhoerl]

Great :)