Future Developments and Features

[JetteSchumann]

This discussion is intended to be a collection of specific ideas for the further development of JuPedSim.

Please create a new comment for new aspects so that we can discuss each topic in a better structured way.

[JetteSchumann]

Documentation

JuPedSim has already been released with extensive documentation, consisting of an API reference, a Getting Started Guide and notebooks with simulation examples. Especially, the notebooks are currently a mix of basic introduction to the usage of JuPedSim and exemplary explanation of configuration features. This should be better separated from each other. Accordingly, basic documentation should be created on the following topics:

• Possibilites for creating a geometry
• Possibilites to spawn agents
• Usage of journeys
• Concept of implementing "triggers" / changing parameters during runtime

In addition, the following tutorials for advanced users would be a great asset to the community:

• Conditions for dxf geometry: How to create a large-scale geometry? What are common mistakes?
• Which (operational) model should I choose? How to calibrate it?
• How to implement a new model?

[JetteSchumann]

Validation Tests

Even though basic tests are already part of the CI they cover a limited scope only. An advanced automated test suite based on RiMEA or ISO standards for verification and validation of the software would boost the reliability of the software and prevent regressions.These tests, for example, ensure that no walls or obstacles are passed through, that different routes can be selected and check how congestions form in front of bottlenecks.

[JetteSchumann]

Extension to 2.5 D walkable area

Currently JuPedSim is designed for simulation in a single 2D area and the agents move in xy-plane only. Enhancements are required to examine scenarios with several floors, taking into account stairs and escalators, for example. Theoretically, it is possible to initialize several simulations for the different floors and to implement the transfer of agents between them manually. This requires a lot of implementation effort, is error-prone and difficult to use/modify. Therefore, the preferred way is to implement this as a new standard feature that enables several walkable 2D areas with interconnecting areas for movement on stairs or escalators (so-called 2.5 D).

This is a major add-on that requires changes to the core of the simulation as well as a new output format and thus also adapted visualization options.

[JetteSchumann]

Visualizer

JuPedSim already provides a tool for visualizing the simulation results. This was initally developed for troubleshooting and inspecting route calculations. With a couple of enhancements, it can be expanded into a very powerful tool for model development and verification. These enhancements include:

• Coloring of the agents based on their routes/goals or velocity
• Display actual size of the agents
• Display configuration options: starting positons, waypoints, exits
• Display information of agents (when clicked on): id, route, direction, current value for model parameters
• Display a map in the backround (OSM data, available plans etc.)

These advancements would not only support the development of new models and enable faster troubleshooting, they would also support in validating large-scale application scenarios as it helps to identify if the model was configured correctly and is working as expected.

[JetteSchumann]

Performance Optimization

Basically, there are two ways to reach a better performance:

• Parallization on GPUs: Since the runtime increases with the number of agents and the size of the geometry, it would be helpful to parallelize simulation calculations that are independent of each other (e.g. for congestion at different bottlenecks). This is quite a challenge because the conditions for independent computations can change, as the neighborhoods between agents and the location of congestion can change over time.

• Adaptions to the model: A second approach is to vary the time steps of the calculations or the algorithms - without compromising the accuracy of the models. A parameter study for increased time steps for the speed model has already been carried out and is documented here. Also, the routing only needs to be updated if conditions have changed - if agents are part of a congestion with very limited movement possibilities, their update process could be skipped/simplified (with maximum density of the model as a trigger for this). And vice versa: if they are in less crowded situations, updating the route is not always necessary. Basic ideas for optimizing the routing calculations have already been discussed here and must be reconsidered/implemented.

Improving the performance would also be a crucial benefit for the coupling with SUMO, as traffic simulation with SUMO usually run in real-time and are limited by integrated JuPedSim models.

[JetteSchumann]

SUMO-JuPedSim Documentation

The integration of JuPedSim into SUMO is already a part of the SUMO documentation, but details are hard to find and the users need to be familiar with the basic functionality (processes and parameters) of SUMO to look in the right places. In addition, there is the challenge of addressing both simulation worlds (traffic and crowds) with the documentation - accordingly, the documentation must be well designed and formulated.

To make the documentation easy to find, a separate and independent section of the SUMO documentation has been dedicated to the coupling and supplemented with tutorials (WIP, link will follow). However, not all functionalities are yet described and can therefore not be used by the community. The following tutorials should be added:

• Simulation example for boarding/alighting a train and bus
• Analysis of simulated trajetories (workflow with PedPy)
• How to choose and modify model parameters etc.
• Limitation of JuPedSim models (basic knowledge for the traffic simulation community explained with examples)

[JetteSchumann]

SUMO-JuPedSim API

After 1.5 years of working with and maintaining the C-API, it has become apparent that the integration of new models and the implementation of new features on the JuPedSim side has become very costly in terms of time/maintenance.

Furthermore, it is not absolutely necessary to make all JuPedSim models and functions available in SUMO, as they are not all relevant for a coupled traffic and pedestrian flow simulation. Therefore, an alternative approach for an interface to SUMO must be designed and implemented.