Rerouting event model

The rerouting algorithm discards the event if:

• The source path or at least one of the the destination paths are described through a set of streets not consecutive.
• The sequence of consecutive streets representing the event paths (source or destinations) do not correspond to a sequence of consecutive links on the assignment network.
• The turn between two consecutive links of the source or the destination path is disabled. Therefore, the path itself is considered invalid.

When a rerouting event is discarded, a message is logged in the log file LogFile_TRE.log.

The rerouting event policy is configured through three parameters:

• → Equilibrium parameters > Equilibrium parameters
• → Rerouting parameters > DoRerouting
• → Rerouting parameters > ReRoutingPeriodization

These parameters are used in two distinct phases:

1. Off-line equilibrium to get files to enable rerouting (TRE offline run).
2. Real-time rerouting (TRE real-time run).

To enable the rerouting event feature, run the procedure:

1. Define a dynamic traffic assignment to provide the baseline turn probabilities.

2. Run an equilibrium, setting the parameters:

   • AssignmentAlgorithm=1, to use the temporal layers assignment algorithm.
   • SaveReroutingData=true, to save on disk the rerouted data after satisfaction of the equilibrium conditions.

3. If DoRerouting=true, the value of DS_TPRB is ignored and destination turn counts stored in the binary files are used to:

   • Compute the node model splitting rates in case of no events.
   • Provide the base for handling rerouting events.

4. The equilibrium results are serialized into binary files:

   • <C:\optima>\TRE\<network_name>\Rerouting Data\<day_type_idno>\PositiveArcs.bin
   • <C:\optima>\TRE\<network_name>\Rerouting Data\<day_type_idno>\ReroutingData.bin

   Tip:  We have both files for each day type with an equilibrium associated

   

   Where:

   • <network_name>: is the name of the Visum network or the DB containing the optima model (usually named optima).
   • <day_type_idno>: is the identifier of the day type of the computed equilibrium.

   Tip:  If these files are produced on a computer different from the one where TRE real time runs, the directory <network_name> and its content must be copied in the TRE directory at installation time.

At each rerouting period (→ Rerouting parameters > ReRoutingPeriodization), for each event:

1. The flow that must be rerouted is computed as the flow on the first arc multiplied by the product of the turn probabilities of all the turns belonging to the source path.
2. The turn probabilities of the source and destination path(s) are updated according to this flow and the compliance value of each destination path.

The turn probability of each path turn (either on the source or a destination path) can be updated or not, depending on:

• The event validity time window.
• Its position along the path.

First turn

Therefore, the first turn is updated if the current instant (t_current) is greater than the start of the validity window (t_start) plus the travel time of the first link (tt₁) and smaller than the end time (<t_end) plus the travel time of the first link:

t_start + tt₁ <= t_current < t_end + tt₁

Second turn

t_start + (tt₁ + tt₂)< = t_current < t_end + (tt₁ + tt₂)

General formula

t_start + (Σ_j∈N tt_j)<=t_current< t_end + (Σ_j∈N tt_j)

Where:

Parameter	Description
tstart	Start of the validity window.
tend	End of the validity window.
ttj	Travel time associated to the link j, both for source neither destination paths.
tcurrent	The current time of the simulation.

In the graphic, you can distinguish:

t_start= Event start

t_end= Event end

The green line identify, for each turn, the time window of validity for the rerouting event.

In a Rolling Horizon simulation, a rerouting event can have an effect even when its validity window lies entirely before the start of the simulation: this happens if the path is sufficiently long for the affected flows to be still travelling the path during the simulation.

About performances and computation time of the rerouting algorithm, you can take in account some tested conditions:

• An additional ~100 s of computation time is required at midnight when change the day type.
• An additional ~2s of computation time can be expected for each DTA interval if there are rerouting events.
• Rerouting event handling execution time should be almost negligible when ReRoutingPeriodization is comparable with the result interval duration; while the execution time may increase if ReRoutingPeriodization is comparable with the simulation interval duration.
• Execution times depend weakly on the number of events, at least as long as events are in the order of one hundred.

The algorithm that reroutes the flows, given a rerouting event, is run independently for each event.

The amount of flow to be rerouted, from the origin to the destination path, is computed based on the offline assignment destination flows, not the current simulated flows.

If two rerouting event overlap with each other (they have some link in common on the origin or destination paths) the algorithm is run for each event independently from the others.

Therefore, inconsistencies may occur as the flow percentage to be rerouted is always computed with respect to the original offline assignment values, not considering that the flow may have been altered by another event.