• Flow-based visualization. The current network visualization is based on density and speed. Although it is intuitive, they are strongly correlated, so it is not very informative.
• Explicit support for mulitlane traffic
• Vehicle trajectory tracking in network using GUI

The current model assumes that all links are 1 lane. Furthermore, the reaction time of all drivers are the same. These mean that all links have more or less the same capacity. It is not possible to model multi-lane links that have 2 or 3 times the capacity of 1-lane links. This is a theoretical limitation of the underlying model.

I plan to implement multi-lane with FIFO (no overtaking) in the future.

Workarounds for the current model:

• Create multiple links between same node pair; each link corresponds to each lane between the nodes. This is a reasonable solution. However, the analysis becomes tedious.
• Reduce capacity_out parameter of Link. In this way, we can place a bottleneck to the end of a link, so that capacities of links can vary significantly. However, it only reduce the capacity. Also, the jam propagation speed becomes too fast or slow.

Several Python scripts within the demos_and_examples directory are failing due to a TypeError related to hashability. Specifically, the scripts attempt to use a list as a key in a dictionary, which is not permitted in Python as lists are mutable and thus unhashable.

Affected Files:

1. example_08_signal_reactive_control.py
2. example_08en_signal_reactive_control.py
3. example_11en_signal_4legged_intersection_reactive_control.py

Steps to Reproduce:

1. Execute the scripts individually or through a test runner like pytest.
2. Observe the TypeError that occurs when attempting to use a list as a dictionary key.

Expected Behavior:
The scripts should run without errors, managing signal control as designed.

Actual Behavior:
When running the scripts, they fail with the following error output:

TypeError: unhashable type: 'list'

The error is thrown in the following context for each script:

• In example_08_signal_reactive_control.py and example_08en_signal_reactive_control.py at line 37:

  vehicles_per_links[l.signal_group] = l.num_vehicles

• In example_11en_signal_4legged_intersection_reactive_control.py at line 45:

  vehicles_per_links = {l.signal_group: 0 for l in II.inlinks.values()}

Error Log:

For example_08_signal_reactive_control.py:

simulation setting:
...
simulating...
      time| # of vehicles| ave speed| computation time
       0 s|        0 vehs|   0.0 m/s|     0.00 s

Traceback (most recent call last):
  File "/path/to/example_08_signal_reactive_control.py", line 37, in <module>
    vehicles_per_links[l.signal_group] = l.num_vehicles
TypeError: unhashable type: 'list'

Similar errors are observed for the other affected files.

Suggested Fix:
A review and potential redesign of the data structure used to track vehicles per link is needed. If l.signal_group is indeed a list and meant to be used as a key, one could consider converting it to a tuple, which is hashable, provided the list's contents are also hashable. Otherwise, restructure the code to avoid using a list as a dictionary key.

After some benchmarks, I discovered the route_search_all takes up a majority (~80% of runtime) in my simulation. This feature request proposes optimizing the route search algorithm, specifically by replacing the current implementation with a more efficient algorithm suited for sparse graphs that are often encountered in real-world road networks.

Issue:
The Floyd-Warshall algorithm, while comprehensive in determining the shortest distances between all pairs of vertices, does not inherently provide the immediate next step in the shortest path from one node to another. The manual computation of this next matrix, especially in a graph of this scale and sparsity, is inefficient and time-consuming, as indicated by execution timings: next matrix computed in 19.861 sec.

Proposed Solution:
Adopt Dijkstra's algorithm, with a priority queue, for the computation of shortest paths. Dijkstra's algorithm is more suited to sparse graphs and inherently provides the immediate next node on the shortest path as part of its output, thus eliminating the need for the currently cumbersome post-processing step.

Technical Justification:

• Efficiency in Sparse Graphs: Dijkstra's algorithm scales better with sparse graphs, operating at (O((V + E) \log V)) complexity, where (V) is the number of vertices and (E) is the number of edges. This is a significant improvement over the Floyd-Warshall’s (O(V^3)) complexity, making Dijkstra's algorithm particularly suitable for our graph's sparse nature.
• Direct Path Reconstruction: Unlike Floyd-Warshall, Dijkstra’s algorithm directly provides the next node in the shortest path from the source to every other node. This feature simplifies the routing module by eliminating the need for additional calculations to determine the next steps in paths.
• Optimization Potential: Shifting to Dijkstra's algorithm with a priority queue not only addresses the current bottleneck but also opens up opportunities for further optimizations, including potentially leveraging parallel computations for running Dijkstra's from multiple sources simultaneously.

Day-to-day dynamics handler could be added.

It would be a very useful feature for me to be able to estimate and record travel times of trips in UXsim.

• Estimate the expected travel time based on the current state of the network.
• Record the final travel time a trip took.

The first one can be used to make decisions on (for agents making a mode choice for example), the second can be usefull as metric / KPI.

I would find it very useful to be able to add a basemap in to the animations created by network_anim(). The basemap could be generated by contextily, and then added to each frame.

I also did some benchmarks using example_04en_automatic_network_generation.py (440 links, 12100 platoons, 1440 timesteps) and surprised that Vehicle.record_log takes long time (~50% of simulation) considering its simple task. I suspect too many use of append is the reason.

Since I won't be able to work on it for a while, I'll keep a record of it for later update.

with record_log

without record_log

It seems like the docs page deployment hasn't been triggered in some time: https://github.com/toruseo/UXsim/deployments/github-pages

Is this expected behavior? Or should it run on each push to main, or each release?

I noticed that the time step size (DELTAT) is directly linked to the platoon size (DELTAN) through the reaction time (REACTION_TIME), as shown in the initialization DELTAT = REACTION_TIME * DELTAN.

I'm curious why this is modelled this way, could you clarify the rationale behind this direct linkage between time step size and platoon size?

When attempting to install uxsim using pip install . or pip install -e ., the installation process fails during the phase where pip tries to get the requirements to build the wheel. This issue arises because the setup.py script indirectly imports the uxsim package, which in turn imports external dependencies such as numpy. Since these external dependencies are not yet installed at the point when setup.py is executed to determine the installation requirements, this results in a ModuleNotFoundError.

Steps to Reproduce

1. Clone the uxsim repository or download the source code.
2. Ensure that the environment does not have the dependencies (numpy, matplotlib, etc.) already installed.
3. Run pip install . or pip install -e . from the root directory of the uxsim project.

You can also directly run:

pip install -U -e git+https://github.com/toruseo/uxsim@main#egg=uxsim

Expected Behavior

The pip install command should successfully install the uxsim package along with its specified dependencies without requiring them to be installed beforehand.

Actual Behavior

The installation process fails with a ModuleNotFoundError, indicating that one of the external packages (numpy is mentioned specifically) could not be found. This error is traced back to an import statement in the uxsim package that is executed as part of the setup.py script's execution.

Impact

This issue prevents the package from being installed in environments where the dependencies are not already present. It affects both development environments and end-users attempting to install uxsim for the first time, potentially limiting the adoption and usability of the package.

Workaround

A temporary workaround involves manually installing the dependencies listed in INSTALL_REQUIRES from the setup.py file before attempting to install uxsim. However, this approach is not ideal as it circumvents the automated dependency resolution and installation process provided by pip.

Suggested Fix

To resolve this issue, it is recommended to refactor the setup.py script and the package initialization process to avoid importing the package or any modules that require external dependencies. Instead, consider one of the following approaches:

• Directly specify the version and other metadata in setup.py without importing them from within the package.
• Use a separate file to store the version and other metadata that can be read by setup.py without executing import statements that depend on external packages.
• Utilize a build-time dependency management tool that supports dynamic versioning without requiring the package itself to be imported during installation.

Additional Information

This issue persists even when the dependencies are installed beforehand, indicating that the version fetching mechanism is inherently flawed and requires attention regardless of the installation environment.

You can see the full error message also here: https://github.com/EwoutH/UXsim/actions/runs/8110064753/job/22166521983

Related:

• #19

Currently, a vehicle in UXsim just travel from A to B and disappear. This is like a private owned vehicle.

In the future, in order to model taxi and shared mobility, specific vehicles can travel through a network by passing through specific nodes that are dynamically updated.

I was curious if it's possible to import a road network from OSMnx.

For the links, the start_node, end_node, length, free_flow_speed could all be determined from OSMnx itself. Then, you could add a function to infer jam_density based on the number of lanes, maximum speed and road type.

For the nodes x and y could be determined from the OSMnx graph, while the signal could be inferred from the intersection type (or left to default).

Modern packaging needs to be implemented instead of setup.py