Modeling Applications

Scenario modeling refers to the “what-if” alternative scenario that differs from the baseline or existing-conditions. For instance, “what if an incident occurred on a freeway link”, or “what if the signal timing was different”? The scenario modeling framework from a DynusT perspective can be explained using the diagram below.

For an alternative scenario, the user shall first establish the existing conditions model. The best estimate of the existing conditions is the so-called User Equilibrium (UE) condition, in which all the routes chosen by trip-makers between the same origin-destination (OD) pair exhibit the same travel time. DynusT determines the UE condition with DTA.

Scenario comparison can be used to facilitate the decision making process. DynusT can be used to perform side-by-side comparisons that enables the user to compare results of scenarios with the baseline, or with any other differing scenario simultaneously in the NEXTA interface.

Modeling and analysis focus on examining the short and long-term impacts of work zones, incidents, or other trafficway modifications. The short-term impact analysis is aimed at capturing the congestion immediately (or up to a month) after the start of the modifications. During this period, motorists travel with their habitual routes and may experience severe congestion, as this route is directly impacted by the modifications.

The long-term impact is instead aimed at understanding the extent of motorists' change from their habitual route to another possible route. It is recognized that not all motorists may divert away from the area of impact. However, the diverted traffic may create congestion at other surface streets or arterials. Such an impact will be captured by the long-term impact analysis.

From a modeling standpoint, the short-term impact of the system is captured by sending vehicles down their User Equilibrium (UE) paths and imposing the work zone. Since the trip makers have not assimilated the work zone project, it is reasonable to project that there will be a significant amount of initial congestion. Trip makers will continue to adjust their driving behavior based on prior experience. In DynusT modeling, a one-shot simulation is utilized to simulate short term impact on the system.

On the other hand, modeling the long-term impact requires running the UE analysis until convergence with the reduced capacity. The newly equilibrated traffic patterns depict the new traffic pattern on the network in the vicinity of the work zone areas.

Dynamic Traffic Assignment (DTA) is a time-dependent methodology which captures traveler’s route choice behavior as they traverse from origin to destination. The objective function known as Dynamic User Equilibrium (DUE) is based on the idea of drivers choosing their routes through the network according to the travel cost experienced during the simulation. At a given point, after many iterations, travelers learn and adapt to the transportation network conditions.

DTA describes the process and outcomes of how motorists with different departure times find their respective experienced shortest (minimal-cost) path from origin to destination in response to roadway connectivity, capacity, or travel demand changes.

For more information on DTA, please download A Primer for Dynamic Traffic Assignment

When a new dataset is prepared from scratch or converted from a existing travel demand model, the random number seed is set to be zero and this would allow DynusT to retrieve a random number seed from the system clock each time it starts. Once a non-zero random number seed is set, DynusT can produce near-identical results, provided that the number of threads is set to 1 in the Advanced Parameter setting. Setting both the number of threads to 1 and specifying a non-zero random seed are required in order to use the same random number sequence and produce identical results. If multiple threads are specified, each thread may retrieve different random number from the sequence and it is impossible to guarantee that the same sequence will be drawn by multiple threads during run time. The only way to ensure that is to run DynusT in a single thread mode. For more information about setting up number of threads, please see the Advanced Parameter section.

There are currently three types of vehicle-generating modes:

1. OD demand matrix
2. Vehicle & path file
3. Vehicle file only

To get to these options in NEXTA, go to Project→Assignment/Simulation Settings. The “Vehicle Generation Mode” option is in the middle of the window.

“OD demand matrix” mode uses the time-dependent demand matrices. Typically, this mode is used when running the baseline network, or when new time-dependent demand matrices are produced.

“Vehicle & path file” mode is based on the completion and output of a DynusT run from “OD demand matrix” mode. From a completed DynusT run, information of the simulated vehicles are output to two files: output_vehicle.dat and output_path.dat. “output_vehicle.dat” describes the attributes of every vehicle simulated, and “output_path.dat” lists the last updated node-to-node route of every vehicle simulated. DynusT can use this output as input for alternative scenarios. By converting the “output_vehicle.dat” and “output_path.dat” to “vehicle.dat” and “path.dat” and using the “vehicle path file” mode, the simulation now will use the same list of vehicles from “vehicle.dat” and each vehicle's route from “path.dat”. NEXTA will convert the files from the “Assignment/Simulation Settings” window by switching the “Vehicle Generation Mode” to “Veh + Path File” and clicking on the “Copy Vehicle and Path Files” button.

The advantage to using this information is to have an “apples-to-apples” comparison between the baseline scenario and the alternative scenario. By using “vehicle & path file” mode removes the possibility of variability in simulation results stemming from different vehicle input. Say, for instance, the alternative case is evaluating signal timing changes, then the user can now “track” vehicle IDs and OD pairs for both the baseline scenario and alternative scenario to examine the impact to that vehicle knowing that the same vehicles and routes are simulated in both scenarios.

“Vehicle file only” mode is similar to “vehicle & path file” mode, except that the “path.dat” input is not used for vehicles in “vehicle.dat”, and the simulation will generate new paths for all vehicles. Change the “Vehicle Generation Mode” in the “Assignment/Simulation Settings” window to “Veh File”. The purpose for this mode is for the case that the alternative scenario changes the existing network by removing nodes and links or splitting existing links. As mentioned previously, routes in “path.dat” are node-to-node. So, if a route from “path.dat” is 1→2→3→4 and the alternative scenario changes the network such that link 2→3 is now 2→10→3, then the route in “path.dat” is no longer valid and simulation will not run.

DynusT adopts a behavioral response system which assigns drivers to different response classes based on the percent distributions defined by the user. These classes are referred to as Multiple User Classes (MUC). This can be found in Project → Scenario Data in the main menu bar, then under the tab MUC Distributions and Vehicle Percentages.

• Class 1 - Habitual
  This class of users does not respond to any information for quickest path. The driver continues on the same path assigned to them unless there is a Detour (DMS type 2) that all cars must take.

• Class 2 - System Optimal
  Travel path assignments are based on optimal system perspective, not on the individual drivers'. In this system a vehicle may be assigned a longer path in order for the majority of vehicles to leave the system more quickly. This is only available with iteration systems. This class of user will only respond to speed warnings or detour DMS types.

• Class 3 - User Equilibrium
  This class of users are assigned the paths that will reduce the travel time for the driver. Once the driver has reached user equilibrium the travel path is now the habitual path. This class is only available with an iterative system, and is the default setting for iteration.

• Class 4 - En-Route Info
  Two types of information are considered for this class:
  
  1) Radio type of information in which the incident or disaster location is presented to drivers at the pre-defined frequency (the time interval of each information broadcast can be changed in Advanced Parameter List). One can define a fraction of drivers to receive such information. Upon receiving the information, the driver will select a route to their destination based on their prior knowledge about the network condition as well as their speculation of the possible congestion around the incident area.
  
  2) GPS navigation devices that presents new route based on updated travel time retrieved from the base station. The driver decides on whether the new route is chosen based on the the boundedly rational behavior. The switching criteria are “Indifference Band” and “Threshold Bound” (see Scenario Data for detailed definitions). A driver considers switching routes whenever the en-route travel information is updated at each predefined interval. Note that this interval can also be changed in Advanced Parameter List.
  
  Also, note that in the event of disasters, in which all the roadways connecting to the a driver's destination are blocked, both the above en-route information will trigger the driver's decision in that (1) if the driver leaves the original prior to the occurrence of the event, he will return home as soon as he/she receive the closure information; (2) if a driver departs after the disaster occurrence, the trip will be canceled. Note that this rule applies to only non-evacuees. Those evacuate from the hot-zone will continue to their intended safe locations.

• Class 5 - Pre-trip Info
  Pre-trip best path information in modeling is equivalent to the driver knowing in advance that there is road work or a closure before leaving (VMS responsive), and so avoids the congestion by choosing an alternate route and/or departure time. DynusT simulates this scenario by assigning a class 5 vehicle the quickest path at the time that it is generated.

The following gives a detailed description of general network scenario setup under the “Scenario” Tab in the Scenario Data window.

• Indifference Band: This applies to the “Enroute Info” user class. This is the threshold representing the inertia for switching to a new route, beyond which the driver will consider the switch.

• Threshold bound (min): This applies to only the “Enroute Info” vehicle class. This is the threshold between the current selected travel time and newly recommended route travel time, beyond which the user will consider switch.

• Random Number Seed: If the user selects “system”, then each run will be assigned with a new seed by the system, otherwise the user can select a user-specified seed to fix the random number. The user-specified seed needs to be non-zero, preferably a large odd number.

• Fraction of compliance vehicles: This applies to “Enroute Info” vehicle class. This specifies the percent of drivers who will consider switching at each decision point, intersections along the route. A decision point is defined as the node along the route that has more than one possible outbound link (e.g. one-way).

• K-Shortest Path - Number of Shortest Paths to be Calculated: This applies to DMS. It allows the program to generate multiple routes upon diversion off the freeway.

• K-Shortest Path - Number of Minutes to Execute: This specifies the interval for each K-shortest calculation. Note that during the initial iteration of the DST (DynusT) run, vehicles are assigned with paths calculated from the K-shortest path algorithm calculated at the interval specified herein.

• Statistics: This specifies the interval within which the statistics are collected. Note that one can specify the start time to be non-zero to allow the simulation to “warm-up”.

• Advanced Parameter List: This contains a list of advanced parameters. These parameters are explained in the next section.
  

This file pertains to advanced user settings focused on network model development, testing, and calibration, as well as other modeling devices for enhancements. This file contains default settings which can be changed at the user's discretion. The Advanced Parameter List can be found under the main menu bar Project → Scenario Data. Under the “Scenario” tab is the button listed as “Advanced Parameter List”.

Currently, the parameters listing contains 29 fields. Primarily, all fields either are a given user value for the field or a binary switch to activate advanced modeling operations. For each field, the current value will be displayed in a small edit box near the top right corner of the display window. To edit the value, the user must change the value within the edit box and click Update to complete that change.

• Freeway SIR

Freeway = 800

This field gives the length (ft) of the Speed Influence Region (SIR) along a freeway link. More detail about the SIR can be found in the AMS model description. The default value is 800.

• Arterial SIR
  

Arterials = 800

This field gives the length (ft) of the SIR along an arterial link. More detail about the SIR can be found in the AMS model description. The default value is 800.

• On-Ramp SIR
  

On ramp = 500

This field gives the length (ft) of the SIR along an on-ramp link. More detail about the SIR can be found in the AMS model description. The default value is 500.

• Off-Ramp SIR
  

Off ramp = 500

This field gives the length (ft) of the SIR along an off-ramp link. More detail about the SIR can be found in the AMS model description. The default value is 500.

• PCE Reduction
  

Reduce PCE during 1st half of iterations. DF: 1.0 = 1.00

This field primarily is used for debugging very congested networks under intense gridlock. The given value is a percentage reduction in the size of the modeled vehicles being loaded into the network. This allows more vehicle movement without total gridlock of the network, still allowing the user to load the complete number of vehicles from the demand data, thereby determining network problems and continuity issues during the debugging process. It is important to reset the parameter to its default value of 1.0.

• Maximum Entry Volume Rate
  

Maximum entry volume rate per lane-mile = 10000

This parameter is provided as a debugging tool to either temporarily reduce or increase the entry volume rate along the generation links within the network. Please be aware of the delicate balance of either increasing or decreasing the entry volume rate; increasing the rate will possibly flood the link beyond capacity and cause gridlock, or decreasing the rate will cause a very large queue for entering vehicles and the correct number of vehicles will not be represented. This number has been recently changed due to a methodology in the assignment of generation links. The default value is 10000.

• Vehicle Position File
  

Interval for vehicle position info. 0 to number of iteration = 0

This is an integer value switch that allows the simulation tool to write vehicle position information to VehPos.dat from once during a complete run to the maximum number of iterations being simulated. Much like the vehicle trajectory (VehTrajectory.dat) file, this file is used to give vehicle position information but only for very large networks and/or very large, extended planning horizons. Loading such information may exceed the current GUI's capability in memory usage. This file is written in a particular format for a special case GUI which uses network and vehicle information from a database. This GUI is not provided in the software installation package. To request more information on the use of this GUI, please contact the DynusT Lab.

• Demand Multiplication Factor
  

Factor to adjust multi factor in demand.dat. Default: 1.0 = 1.00

This allows the user to set the overall multiplication factor applied to the OD demand data file.

• Vehicle Trajectory File Writeout
  

1 - vehtrajectory.dat written at the VehJO interval, 0: no = 1

This field is an integer-like switch that allows the simulation to write out VehTrajectory.dat (see Output Files).

• Mesoscopic Traffic Simulation Model Switch
  

0 - Original meso: 1- AMS = 0

This is a binary switch to use the original mesoscopic model (value of 0), or the AMS model (value of 1). Please see the section titled AMS model description (AMS) for further details of this model.

• Discarding Initial Path Assignments
  

0 - Keeps the initial path, 1- discard initial path = 0

This parameter is a binary switch (1=yes, 0=no) which discards the solved shortest paths from iteration 0 so the proceeding assignments do not consider those initial paths. The reason for this is that in the initial iteration (iteration 0) of a full UE run, the network assignment procedure is performed before simulation and the shortest path solutions are considered instantaneous with no regard to time-dependency and traffic conditions. Essentially, these initial shortest paths assigned in iteration 0 are carried through to simulation and the result is vehicle and path information, which in turn is fed into the next iteration's network assignment. However, iteration 0's solved shortest paths are still maintained in the next iteration's solution which do not reflect true DTA shortest paths. If this parameter is turned on, the user should plan to run the UE assignment for an additional iteration to compensate for the discarded iteration 0.

• Max Entrance Capacity for Generating Vehicles
  

1 - Max Percent of capacity filled by newly gen vehicles.

This parameter is primarily used as a debugging method which provides a capacity threshold in loading vehicles during simulation along network generation links. It is advised to reset this to the default value of 1 when the debugging process is complete.

• Network Connectivity
  

1 - Check network connectivity. 1: check, 0: no

This parameter is a binary switch (check network=1,do not check=0) which helps debug in the conversion process. When a simulation run is administered, the system will check for any network inconsistencies and discontinuities. Usually, the user will want to select 0 if the user is confident in the network, as checking will greatly increase the computational time of Dynus-T.

• Restoring PCE from Reduction
  

Ratio of number ite reduced mtnum will be restored.

This parameter pertains to the PCE Reduction parameter listed previously in the parameter listing; therefore, this should be used in conjunction with the PCE Reduction parameter. This gives the option of restoring the PCE reduction to the default value of 1. This is preformed by defining the ratio of total iterations it takes to fully restore PCE to 1. E.g., if there are 10 iterations and the ratio is chosen to be 0.5, then within half of the 10 iterations, being 5 iterations, the PCE will be restored. The default value is 1.00.

• Activate Jam (myopic) Switch Rule
  

1 - Activate jam switch rule; 0: no

This parameter is a binary switch (yes=1, no=0) that will activate a special case in conjunction with the class 4 enroute-switch vehicle classes. When this rule is activated, for an enroute-switch vehicle, it will take a new route when the driver sees the congestion level (link density) is higher than the threshold specified below (see Threshold for switch below). Without activating this rule, a enroute-switch vehicle will switch without considering the congestion at the downstream link. PLEASE NOTE: This is step 1 of 3 for this jam density switch rule; the remaining steps are found below. Default value is 0.

• Threshold for Jam Density Rule
  

Threshold for switch (% of jam density)

Step 2 of the Jam Density Rule is the conditional rule giving the percentage threshold by which the vehicles will divert to other paths. The threshold is the percentage of the downstream link's listed jam density beyond which the approaching driver will consider diverting. Step 2 will not be activated unless Step 1 above is activated. The default value is 0.95.

• Participation Rate of Jam Density Rule
  

Jam switch participation rate

Step 3 of the Jam Density Rule is the participation rate of approaching vehicles that will adhere to the Jam Density Rule. Step 3 will not be activated unless Steps 1 and 2 above are activated. This parameter is deactivated for now. The default value is 1.00.

• Dummy Parameter
  

IterSub

Dummy Parameter

• Dummy Parameter
  

GenCheck

Dummy Parameter

• Keep Same Vehicle Classes
  

keepcls. keep veh cls in vehicle.dat. 0: not keep, 1:keep

This parameter is a binary switch (keep=1, do not keep=0) that allows the user to keep the same MUC of each vehicle and not randomly distribute vehicles according to MUC proportions through simulation when running from the vehicle (vehicle.dat) and path (path.dat) files. When running the program from the vehicle and path files, the simulation will randomly distribute new MUC's to vehicles. In the instance that the user wishes to maintain the same exact MUC's for every vehicle, this switch must be turned on. More detail pertaining to MUC distribution is found here. If the user wants to run the network to UE, this value needs to be 0.

• Temporary Array Size
  

tmparysize - size of the temp arrays

This parameter gives a larger allowance of the temporary array size utilized within the modeling scheme if the user's machine has the capability. The default value is 1,000,000 (1 Mb).

• Vehicle Generation Buffer from Demand Files
  

nv_vebuffer

This parameter is a buffer for allocating additional memory when generating vehicles. Memory is allocated to the generation of vehicles based on the value given for each OD pair from the demand table. Due to the randomness of rounding demand values from real numbers (precision of 4) to discrete values, the memory allowance is buffered (Default buffer value is 1.05) to capture higher values then what is given in the OD pair value. This buffer is changed at the discretion of the user.

• Write Program Log Report
  

logout - flag to write to runlog.dat. 1: write

This parameter is a binary switch (yes=1, no=0) in which an additional output file titled “runlog.dat” is written. This file is primarily a debugging file that logs the activities executed by the program. If in the occurance the program crashes, this file should give a clue about what assignment/simulation process caused the program to crash.

• Write Additional Vehicle/Path Files
  

trajalt - flag to write AltPath.dat, AltTime.dat, AltEnQ.dat

This parameter is a binary switch (yes=1, no=0) in which two additional output vehicle/path information files will be written titled “AltTime.dat” and “AltEnQ.dat”. Currently, by default, the program writes “AltPath.dat”. The information provided in these files are mainly used for post-processing activities. Details of each file is given in the Output Files section.

• Change of Incident Behavior
  

IncClsFlag. 0: capacity reduction, 1: closure upstream node

This parameter is a binary switch (yes=1, no=0) in which the behavior of an incident is altered. When an incident is placed into the network, the occurance reduces the capacity of the link. This switch alters the behavior of an incident from reducing capacity to acting as a warning sign. For instance, in the case of a normal incident, vehicles may enter a link with capacity reduction which in turn creates a queuing. However, when this switch is activated, the incident will act as a warning sign and create a lane closure upstream, thus not allowing vehicles to enter the link. When this incident acts as the warning sign, the link's capacity is not altered which means that if there are vehicles present when the incident is activated, the vehicles will not be affected by any capacity reduction and will exit the link without any additional delay. Details pertaining to incident data can be found at here.

• Bay Length
  

Average bay length

This parameter changes length of the bay lengths if either left-turn right-turn bays are present in the network. Currently, the default length of bays is 300 ft.

• Left-Turn Saturation Flow Rate
  

Left-turn saturation flow rate

This parameter allows the user to alter the flow rate of left-turn movement within the network. The default value is 1800 veh/hr.

• Right-Turn Saturation Flow Rate
  

Right-turn saturation flow rate

This parameter allows the user to adjust the flow rate of right-turn movement at the intersection. The default value is 1800 veh/hr.

• Left-Turn Critical Gap
  

critical gap for left-turn vehicles (sec)

This parameter allows the user to change the critical gap for vehicles turning left when judging the gap allowance between oncoming traffic. The default value is 5.00 sec. This is the parameter used in the permission left-turn algorithm.

• Scaling factor for GFV assignment approach
  

Scaling factor for GFV assignment approach

This parameter allows the user to adjust the scaling factor for the Gap-Function Vehicle (GFV) based traffic assignment algorithm in DynusT. The higher the value is the more number of vehicles got swapped at each iteration. The default value is 2.00

• Max Assignment Fraction for Each Iteration
  

Max Assignment Fraction for Each Iteration

In GFV algorithm, each o,d,t triplet at each assignment iteration has its individual assignment fraction - percent of total flow between this o,d,t to be re-assigned to a new path - based on the GFV algorithm. However the actual fraction is also capped by the parameter setting specified herein. A higher value allows more vehicles to be updated, but may cause gap function fluctuation at the initial iterations.

• Assignment Algorithm
  

Switch for choosing MSA or GFV algorithm. 

This switch allows a user to use either the traditional MSA or the GFV algorithm. GFV algorithm performed much better MSA and only slightly slower than MSA in terms of convergence. The default value is 1.

• Switch for UE Travel Writing out Travel Time
  

Switch for writing UE Travel Time

This switch allows link travel time to be outputted at the convergence iteration. The default value is 0.

• Switch for UE Travel reading in Travel Time
  

Switch for reading UE Travel Time

This switch allows link travel time to be read at the initial iteration. The default value is 0.

• Shelter Information
  

Switch to read shelter.dat

Shelter.dat contains shelter information for evacuation modeling. Details of shelter.dat is available in the evacuation section.

• No. of Threads
  

This is the switch to run multiple threads. If the value 1 is used, then the program runs as a single-threaded version. 

Number of threads to run for the current run.

• Fuel Consumption
  

This is the switch to output fuel consumption. 

Further details can be found in this section.

The purpose of a Variable Message Sign (VMS) [AKA: Dynamic(DMS) or Changeable (CMS) Message Sign] is to inform drivers of any important traffic concerns along the trafficway, thus allowing a driver to make an informed travel decision. Such traffic concerns may include severe weather conditions, incidents, work zones, reoccurring congestion, and special events.

DynusT provides the ability to configure DMS-like information in the network model by three different types of messages to inform the vehicles driving along a link. The three types of DMS messages are described below:

Each DMS type is uniquely implemented on the user-specified link of interest. Neither the number of DMS placements in the network nor the number of DMS placements at various time frames on one link is limited within the allotted simulation time. The explanation and placement of each DMS type are further explained below. To place a DMS on a link right-click on the desired link and select DMS Data as shown in the figure below.

Additionally, implementing DMS on a specific link may be accomplished through the menu options. From the menu choose Simulation → Scenario Data. Next, the Scenario Data display window will appear with a series of tabs, one being the Dynamic Message Signs tab. As stated previously, there are three DMS types. They are further explained below in terms of the implementation of each:

When the Dynamic Message Signs tab is selected, a drop-menu will appear under the DMS Type column heading. The first option in the drop-menu will be the Speed Advisory (DMS Type 1). The column headings will be updated when the DMS type is selected.

The Speed Advisory is represented on the user-specified link by indicating the speed threshold, as well as the percentage change of the speed. The Speed Threshold is specified as either a positive or negative speed in mph. If indicated as positive (+) and the actual link speed is less than the threshold, the link speed will be increased to that specified Speed Threshold (i.e. if link speed is 30mph and the preferred Speed Threshold is +40mph, then “+40” would be entered). Conversely, if indicated as negative (–) and the actual link speed is higher than the threshold, the link speed will be decreased to that specified Speed Threshold (i.e. if link speed is 60mph and the preferred Speed Threshold is 40mph, then “–40” would be entered).

The Percent Change is defined as the percentage reduction or increase in the speed of the link on which the DMS is located. In other words, if the Speed Threshold is positive (+) and the Percent Change is 10 percent, then “10” would be placed in the field and the vehicles will increase the speed by 10 percent to reach the suggested Speed Threshold.

The last fields entered are the Start (min) and End Times (min) of the Speed Advisory. The Start Time and End Time are entered in minutes relative to the simulation time. All fields discussed for the Speed Advisory (DMS Type 1) are demonstrated on the figure below:

The percentage of vehicles that will respond to a speed advisory can be chosen in the MUC distributions window under Project → Scenario Data → MUC distributions (see MUC Traveler Information). The user class that responds is called DMS Responsive. A speed advisory (DMS type 1) gives MUC class 5 information that speed is reduced or increased on a link. This class of user will then find another best path to avoid the speed reduction, or if the speed is increased the vehicle path may change to include this link.

Below are step-by-step examples on how to create different DMS scenarios.

1. To insert a Dynamic Message Sign that will alert drivers to a decreased speed advisory, right click on the link that the speed is reduced on, and chose DMS. This will pull up the scenario data window under the project files. This can also be done by going to Project→Scenario data→DMS.
   
2. Choose the DMS type to be Speed Advisory. Chose the speed threshold. The start and end nodes of the link will be automatically added. Click OK and the link will show DMS in a blue box over it.
   
3. Repeat for as many links as needed.
   
4. Project→Simulation Assignment Settings: Click on the vehicle and path files. Determine the necessary number of iterations. Save the scenario in a new folder, then run the user equilibrium.
   

The following figure shows this scenario in side-by-side comparison with the base case, with the base case on the left and the new scenario on the right.

A mandatory detour is one in which all vehicles must use the detour. The link is closed for an accident or construction and the vehicles must follow the detour assigned by the user. DynusT will not assign the next shortest path.

1. To insert a Dynamic Message Sign that will alert all drivers that there is a mandatory detour, a detour path must be pre-determined. To create the detour click the series of links that will form the detour while holding the control key. Once all links in the path have been chosen right click and chose create path from the drop down window. Check to make sure the list of links are correct then click OK.
   
2. Once a path has been chosen choose the link previous to the congested link and right click. Choose DMS from the menu which will open the scenario data window. Chose Mandatory link from the DMS type box. The start and end nodes will be automatically added. In the percentage response box is 100%. This number cannot be changed because it is a mandatory detour so all vehicles must use it. The best path uses a binary value to determine whether the diverted vehicles will be assigned the current best path (1) or a random path among K-paths. This path assignment takes place starting from the downstream node of the DMS link. The start and end times are the times during which the DMS will be active. Click the box that says edit to edit the detour path. Choose the box labeled use path, and the path previously created (in the DMS type 1 explanation) will be shown. Click OK. The detour path can also be created by manually typing in the links in this window.
   
3. Project>Simulation Assignment and click on the vehicle and path files. Determine the necessary number of iterations. Save the scenario in a new folder, then run the user equilibrium.
   

The following figure shows this scenario in side-by-side comparison with the base case, with the base case on the left and the new scenario on the right.

A congestion warning is the one that warns drivers that there is upcoming congestion on approaching links or roadways. Some user-specified percentage of vehicles who travel through the DMS link will respond to the warning. The user has two options to assume how drivers will choose their alternative path to their destination. (1) Drivers choose their alternative route based on their prior experience about the network. Note that at this moment, unfamiliar drivers are not modeled in DynusT. All drivers are assumed to have some experience about the network; (2) perfect knowledge about the network traffic condition at time of decision. The first modeling option is a relatively more realistic behavior assumption. The second option can serve as the benchmark to examine the best performance of DMS. Using both options allows a user to obtain a sense of the range of DMS effectiveness.

To model the first behavioral option, the user needs to activate the “Read UE Travel Time” flag for the program to read the UE travel time into memory and be used for VMS modeling. The UE Travel Time is generated by any prior UE run and with the “Write UE Travel Time” flag turned on. How to activate the “Read UE Travel Time” and “Write UE Travel Time” flag can be seen in Advanced Parameter List. The second DMS route generation option is automatically turned on if the UE Travel Time is not read into memory.

1. To insert a Dynamic Message Sign that will give drivers a warning of congestion right click on the congested link and chose DMS. When the scenario data window opens chose congestion warning from the type of DMS box. The link will be automatically added in the first box.
   
2. Choose the percentage of vehicles that will respond to the congestion warning. Then click OK. The simulation software will determine the best detour to assign to this class of user. The start and end times are the times during which the DMS will be active.
   
3. Project>Simulation Assignment Settings: Click on the vehicle and path files. Determine the necessary number of iterations. Save the scenario in a new folder, then run the user equilibrium.
   

The following figure shows this scenario in side-by-side comparison with the base case, with the base case on the left and the new scenario on the right.

A work zone is an area of a trafficway with highway maintenance, construction, maintenance, or utility-work. Typically, work zones are marked by signs, channeling devices, barriers, pavement markings, and/or work vehicles. A work zone extends from the first warning signs or flashing lights on a vehicle or dynamic/variable message sign to the “End of Road Work” sign or last traffic control device. In addition, a work zone may be for short or long durations and may include stationary or moving activities.

Work zone implementation on DynusT requires the use of the two generated files from the basic UE scenario that contain the attributes of all generated vehicles, refer to previous sections for further details.

Implementation of a work zone scenario on the DynusT network model requires user-specified links that will encompass and be affected by the work zone area. A link can be defined as a work zone link by selecting it and then right clicking for the link properties (or scenario data) toolbox to appear on the screen. The work zone data option should then be selected. Refer to figure below.

The work zone tab within the scenario data toolbox contains the work zone link records that are to be simulated. A record is defined by Start time (min), End time (min), capacity reduction rate, reduced speed limit (mph) and queue discharge rate (vphpl). Capacity reduction refers to the reduction in physical storage capacity (lane miles) and is specified as a percentage (i.e. percentage of lane closure is specified to be 0.6, or 60 percent). Queue discharge rate refers to the maintained maximum flow rate of vehicles as they flow out of the work zone link. Multiple work zones (or work zones spanning more than a link) can be simulated. Once a work zone record has been defined and entered, a crew flagger icon will be displayed on the link specified with the work zone. Refer to the figures below.

Note that the detour-type Dynamic/Variable Message Signs (DMS/VMS), also found in the scenario data toolbox, are important for work zone operational management strategies; however, it need not be used in conjunction with a work zone. Vehicles will simply follow the detour sub-path irrespective of whether a work zone (or an incident) is present or not.

An incident is described as an occurrence or event, such as a car accident or some temporary special event, that impedes the trafficway thus causing a reduction in capacity. DynusT has the ability to model incidents in the network along any link. An incident is represented on a user-specified link by indicating the severity of the incident, as well as the Start and End Time. The Severity of the incident represents the fraction of the loss of the link’s capacity due to the incident. The number of incidents in the network is not limited, nor is the number of incidents at various time frames on one link limited within the allotted simulation time.

To place an incident on a link, right click on the link as indicated in the figure below and select Incident Data.

Additionally, implementing an incident on a specific link may be accomplished also through the menu options. From the menu choose Simulation → Scenario Data. Next, the Scenario Data display window will appear with a series of tabs, one being the Incidents tab as indicated in the figure below.

Specified in the Incident Data window is the Link, Start Time (min), End Time (min), and Severity of the desired incident. If the incident is being placed by right clicking on the desired link, it is not necessary to enter the link information. The Start Time and End Time are entered in minutes relative to the simulation time. As mentioned before, the Severity of the incident is entered as a decimal fraction of the loss of the link’s capacity (i.e. percentage of lane closure is specified to be 0.6, or 60 percent). If the incident is being placed by the menu options, it is necessary to enter the link information. The link information can actually be placed either from a drop-down menu that lists all links in the network in the link column, or the From → To node ID’s of the link can be manually entered. When the Start Time, End Time and Severity are entered and the Incident Data window is closed, a symbol will appear on the link to indicate an incident on the link as shown on the figure below.

To remove the incident from the network, the user can either right-click on that specific link or re-open the Incident Data window from the menu options. To the left of the link data is an empty button. When the button is clicked a black triangle will appear and the whole row will be highlighted. To erase the information of that incident, press the Del key on the keyboard.

Ramp metering is defined as the placement of a basic or two phase traffic light (green and red, no yellow) with a signal controller on an on-ramp to regulate/restrict traffic flow (number of vehicles) entering the freeway, temporarily storing traffic on this same ramp. The process is called access rate reduction. Utilizing gap acceptance information, the ramp meter allows vehicles to enter freeway mainlanes when its detectors sense gaps in the mainlane traffic stream, preventing traffic flows from exceeding the freeway's capacity, causing bottlenecks.

Ramp metering procedure in DynusT measures the flow on freeway mainlanes downstream of the ramp, and determines the remaining freeway capacity available based on occupancy values. Then the on-ramp flow rate is adjusted to meet the available capacity.

To place a ramp meter in DynusT right-click on the on-ramp link and select the Ramp Metering Data option from the link properties drop-down menu.

In the Ramp Metering tab in the Scenario Data, users will be asked to provide the following information: downstream link, detector start position (ft), detector end position (ft), metered ramp (link), meter parameter A (vehicles/lane/hr/percent time), meter parameter B (percent time), saturation flow (vpspl), start time (min) and end time (min). It is important to note that DynusT calculates average occupancy over a freeway section delineated by edges of the loop detector.

The following figure depicts the general format of the on-ramp, detector and link(s) layout.

The Meter Parameter A field is regarded as a control factor, which controls the number of vehicles entering the freeway via the on-ramp (occupancy-to-flow conversion rate in terms of vehicles/lane/hr/percent time). A high value of A corresponds to more vehicles able to enter the freeway. The Meter Parameter B field represents excess downstream capacity (maximum freeway occupancy in terms of percent time) available for entering vehicles. A high value of B represents more capacity available for entering vehicles.

DynusT provides an array of approaches for the modeling of value pricing scenarios. The specific available modeling capabilities are discussed in this section.

First, users needs to create the link(s) on which tolls are to be placed. Make sure the default link is HOT. Create a link that follows along the roadway that the toll will be placed on. This new link will be the toll lane. Right click on the new link.

After selecting the Link Pricing Data from the list, the value pricing dialog window will appear as shown below. Please note that through this procedure, the intended link will show up on the Link pull-down menu and the user does not need to select the link.

The pricing scenarios that can be modeled by DynusT include:

1. High-Occupancy Vehicle (HOV) lane - freeway
2. High-Occupancy Toll (HOT) lane - freeway
3. Truck restriction
4. Congestion Pricing

All of these scenarios can be easily coded through different ways of specifying toll rates for different vehicle classes.

To model the HOV scenario, one would select either Distance-based or Link-Based toll type. Put a high toll rate (suggested 10,000) on both SOV and Truck classes. Such a high toll rate will ensure that both SOVs and trucks will not go through the HOV lanes. Specify the time period over which the toll is imposed and the time value. The time value or (value of time) can be obtained from MPO. $20/HR for SOV and HOV and $45/HR are the values used in several prior projects in Texas.

Modeling SOV is similar to HOV with the difference in that the toll rates for SOV and Trucks will be the actual tolls instead of the suggested high toll rate.

This modeling approach also allows users to model truck restriction. To do so, simply assign a high toll for the Truck class while maintaining zero toll for both SOV and HOV vehicles.

In the congestion responsive tolling scheme, the toll rate is dynamically updated in response to congestion levels at both HOT and GP lanes. To enable the congestion responsive toll, one needs to first set up the HOT lanes as previous discussed. The initial price for SOV and trucks can be set as a $0 for SOV and $100 if trucks are restricted from using the HOT facility. If trucks are allowed to enter the HOT lanes, then the initial toll rate can be $0. Next, an additional input file “CongestionPricingConfig.dat” is needed as shown below. In this example, there are 2 pair of HOT-GP segments. Each pair is defined by either an area bounded by ingress-egress points (a), or by egress-ingress points (b). In CongestionPricingConfi.dat, each of the 2 HOT-GP lane pair is defined by three lines of entries. The first line of defines: dummy, HOT lane target speed, minimal rate ($/mile), maximum rate ($/mile), scaling factor, perception factor. In the shown example, the first segment has HOT target speed 50 mph, minimal rate $0.1, maximum rate $10.0 and scaling and perception factor 1.0 and 0.0 respectively.

The 2nd and 3rd lines defines the node sequence of HOT and GP lanes. The 2nd line is always for HOT lane and 3rd line is always for GP lane. The sequence of the entries is: segment ID, number of nodes in the HOT lane, node 1, node 2, node 3, etc. For example, the first segment show below has 4 nodes constituting the HOT lane segment. The node sequence is node number 1, number 2, number 3 and number 4. The GP lane is likewise defined by node 1 and 4.

A similar setting can be specified for the segment bounded by egress-ingress point. This is necessary only if a toll collection device is placed between node 3 to node 6. This way, vehicles choose not to exit the HOT lane at node 3 and continue to stay on HOT lane will be charged with tolls when traversing link 3-6. In the case that this segment is short and is serving as a buffer zone for vehicles to get in and out of the HOT lanes, this segment needs not to be specified in CongestionPricingConfig.dat. All the segment specified in this file would be subject to updates of toll rates considering the congestion levels at both HOT and GP lanes.

The methodology of the entire congestion responsive tolling algorithm will be made available online momentarily. In a nutshell, it is a throughput maximization formulation in a DUE framework that seeks for maximizing the throughput while maintaining the target HOT operating speed. It is a not an ad hoc heuristic rules that assign HOT flow based on a user-specified setting. It is based on how drivers would consider the trade-off between HOT and GP lanes considering the congestion levels and his/her value of time. The algorithm would be calculate the throughput maximizing toll that maintains the HOT target speed. It is important to note that DynusT needs to be set as the DUE iterative mode in order to properly activate the pricing calculation. In other words, this feature is not activated in the one-shot mode because it is necessary to go through iterations for a stable pricing solution. This feature, by its design, is well-suited for planning purposes. Further refinements are needed to extend the algorithm for real-time operation purposes.

Buses allows the user to insert buses and bus routes into the model. Below is an example of what the bus scenario window.

The following list of data is needed:

• Starting Link
• Start Time (min)
• Average Dwell Time (min)
• Route - the route may be chosen by holding down the control key and clicking on the links in the route in the simulation GUI.

Sensors
The window below may be used to add sensors into the simulation model.

• Chose the link(s) on which the sensor is desired.
• Decide on the sensor type: “Existing Point Sensor”, “New Point Sensor”, “Existing AVI Sensor”, or “New AVI Sensor”.
• Click the add button to add the sensor to the network. This can be repeated for as many sensors as needed.
• Then under “Time Intervals” enter a start time, an end time, and the number of time intervals

The modeling of value pricing is based on the assumptions that a tripmaker's route choice decision considers the joint effect of travel time and toll rates. Trip makers with a higher value of time will perceive the toll as having less impact on their trip, in comparison to those with a lower value of time. In other words, if the HOT lane exhibits considerably shorter travel time, those with a higher value of time will be likely to use it. DynusT aims to estimate the traffic and revenue for HOT/HOV scenario by equilibrating the generalized cost consisting of actual travel time and the equivalent travel time based on toll rates and value of time.

To separate a lane from the existing freeway link, the following procedure applies.

1. Reduce the number of lanes of the existing freeway by one (assuming the HOV/HOT takes one lane).
2. Use the GUI to add new links with one lane connecting the existing freeway via the intended HOV/HOT entry/exit points
3. Apply appropriate tolls to the newly generated links.

For HOV/HOT scenarios to function properly, users need to properly designate the vehicle class in the MUC Distribution and Vehicle Combination tab in the Scenario Data that can be reached from Project → Scenario menu.

After the simulation assignment modeling, the traffic statistics can be reviewed through the NEXTA GUI by selecting the options from the Editor drop-down menu within the tool bar. The revenue information can be accessed through the text file from drop-down menu Text Files → Output Files → Toll Revenue. MS Wordpad will pop up to display the content of this file. The file contains the revenue calculation by link and total for each DUE calculation iteration.

The outputs are contained in Tollrevenue.dat. The explanations of this file can be found at the toll revenue output file section.

To properly delete Work Zones, Incidents and Variable Message Signs (VMS) scenarios, go to the Scenario Data screen. Next, click on the corresponding scenario type to be deleted. Then, click the arrow directly to the left of the link of the scenario which is to be deleted. Last, press delete on the keyboard. Below are pictures to provide a step-by-step process to properly delete scenarios.

First, right click on the link with the scenario as shown below.

Next, click the arrow to the left of the scenario's link to be deleted. The arrow looks like a triangle pointing to the right. In this case it is (12810,12811). The entire row should then become highlighted in blue.

Finally, press delete on the keyboard. This deletes the scenario that was highlighted.

DynusT estimates fuel consumption by tracking individual vehicle driving condition (speed at each simulation interval) and its corresponding fuel economy rate corresponding to the driving distance and prevailing speed at each simulation interval. This eliminates the need to post-process the fuel consumption and yield more accurate estimate of fuel consumption considering both VMT and speed.

To enable fuel consumption, please change the corresponding switch to 1 from 0 in parameter.dat

The next step is to make sure the fuel_par.dat is placed in the working data folder. This file looks like:

This file provides the basic parameter inputs for fuel consumption calculation. In this example, there are two types of vehicles that would be specified with different fuel economy profiles. There is no limitation in how many types one can specify. However, in the following example, only two types (auto and trucks) are specified. The first line carries the following entries: vehicle type, average initial fuel level, standard deviation of initial fuel level, minimal capacity and maximum capacity, and minimal fuel level before refueling.

The next line indicates that there are 15 following fuel economy bin entries, each line carries, bin number, speed (mph) and corresponding fuel economy (miles per gallon). Similar entries are specified for trucks except that the fuel economy is worse than auto. The fuel economy information can be found from a number of sources including EPA

The outputs of fuel consumption can be found in fuel_out.dat, which looks like the figure below. In this figure, fuel consumptions for vehicles departing at different times are outputted, followed by the sum of fuel consumption for each specified vehicle type (gallons).

DynusT has unique capabilities that allow users to test both Descriptive and Prescriptive scenarios for disaster evacuation.

The Descriptive scenario refers to the emergency management context in which evacuee's origin-destination (OD) are not actively regulated. DynusT users are required to follow a three step process to analyze the evacuation scenario. First, users need to input the estimated OD information into the model. They then need to apply DynusT's one-shot or iterative simulation and assignment mode. Finally, the evacuation scenario can be evaluated with the analysis of the ouput/results produced by DynusT.

In the Prescriptive scenario, DynusT users first need to estimate the total number of evacuees. DynusT will automatically solve for the optimal destinations, departure time(s), route(s) and assignment decisions simultaneously in a computationally efficient manner. This Prescriptive modeling capability is the first of its kind and is considered similar to the class of DTA simulation models.

More details about both modeling capabilities are presented as follows.

DynusT can perform both the descriptive and prescriptive modeling and evaluation of various evacuation demand-supply conditions. Details are explained in the following section.

The descriptive capability means the use of the model to evaluate the outcome of the demand-supply conditions specified by the user. Contrary to the notion of “prescriptive” capability explained later, the descriptive capability is suitable for modeling “what-if” scenarios in which the user wishes to understand the outcomes by controlling how demand and supply conditions are specified.

The Prescriptive capability is aimed at simultaneously solving for the optimal evacuation destinations, routes and flow splits from evacuation zones to safe zones. This scheme allows all regular traffic analysis zones (TAZ) to be identified as either evacuation, intermediate or safe zones for the evacuation purpose. As shown in the figure below, while the evacuation and intermediate zone topology remains unchanged, all boundary nodes in all safe zones (could be one of multiple) will be designated as physical evacuation destinations considered as gateway nodes and which are connected to a hypothetical sink node. This hypothetical sink node serves as the single super virtual destination for all evacuation flows. The evacuation trip generation will be estimated based on the new topology and the flow assignment problem of interest is transformed into a many-to-all network flow problem.

Corresponding trip demand information needs to reflect the evacuation zone to safe zone evacuation direction. Multiple safe zones defined in the original topology need to be aggregated into one single zone for the OD demand matrix estimation purpose. This feature makes the trip distribution process simple and accurate since all the flow outbound of evacuation zones will just need to be pointed to this aggregated safe zone.

Next, the destination nodes are specified within the safe zones. Vehicles are considered safe upon arrival to these destination nodes. Destination nodes are those which are located at the perimeters of the boundary adjacent to evacuation zones or intermediate zones. By connecting these nodes to the virtual sink nodes, the evacuation flows will traverse only through these nodes to the virtual sink nodes. At this point, the modeling is completed and the optimal destination, routes and flow decision will be determined based on the modified topologies and associated OD trip information.

In the context of evacuation, DynusT allows the user to specify the background and evacuation demand separately. The background demand represents the traffic that is not affected by the disaster and still maintain certain regular activities. The evacuation demand represents the movement of traffic from the the disaster impact area (or hot zone) to the safe zones. The background demand can be reasonably estimated based on the existing OD table (the user may need to apply certain scaling factors or conduct certain adjustments if necessary). The evacuation OD, in the context of a prescriptive model, can be estimated and specified by the DynusT user. Since both the background and evacuation demand have distinct spatial and temporal patterns, they need to be specified separately.

The evacuation demand is specified through the Super Zone layer. A super zone is defined as an aggregated zone that contains one or more original zones. Normally, in a mass evacuation, the origin of the evacuation may cover a large area.

Furthermore, DynusT has the option to use a more realistic route choice behavior model in which each evacuee will consider the selection of routes based on the factors such as familiarity with the routes, preference toward freeways, etc. This route choice model is a multinomial logit-based approach that is documented in the following paper.( Chiu, Y.-C. and P. B. Mirchandani (2008). “Online Behavior-Robust Feedback Information Routing Strategy for Mass Evacuation.” IEEE Transaction on Intelligent Transportation Systems 9(2): 264-274 )

( Chiu, Y.-C. and H. Zheng (2007). “Real-Time Mobilization Decisions for Multi-Priority Emergency Response Resources and Evacuation Flows: Model Formulation and Solution.” Transportation Research Part E 43: 710-736. )	( Chiu, Y.-C. and P. B. Mirchandani (2008). “Online Behavior-Robust Feedback Information Routing Strategy for Mass Evacuation.” IEEE Transaction on Intelligent Transportation Systems 9(2): 264-274 )

Below are useful information that can be gathered and provide additional input as model parameters and data for the DynusT simulation of large-scale evacuation.

• .shp file of zones
• 24-hour Demand Table associated with the zone layer
• Hourly ratios to disaggregate 24 hour demand table into 24 hourly demand table (required starts from 24-hr table)
• Morning Peak Hour demand Table associated with the zone layer (optional)
• Afternoon Peak Hour demand table associated with the zone layer (optional)
• Separate Truck Demand Table (if it exists) + hourly ratios to disaggregate into 24-hourly demand tables
• HOV Demand Table (if it exists) + hourly rations to disaggregate into 24 hourly demand tables
• Ideally, the time-varying OD tables that are combined from various time-varying trip-purpose tables with appropriate hourly factors applied to individual trip-purpose tables are the most accurate demand input to DynusT because such data account for the directional of traffic at different time of the day.

• .shp file of zip code zones
• Number of households within each zip code(optional)
• Number of vehicles per household(optional)

• Number of household or populations in each zone (preferable but not required)
• Number of vulnerable groups and demographic in each zone (preferable but not required)
• Evacuation from zone – to zone (TAZ or zip code) (preferable but not required)
• Departure times and evacuation demand at each time (preferably (minimally) in 1 hour increments)
• Note that this information is usually processed/estimated based on demand estimation method. This is usually not available from typical data sources.

The figure below shows the original zone structure.

The figure below shows that there are three super zones used for evacuation. Zones 1 and 2 are aggregated into super zone 1, zone 3 becomes super zone 2. Zones 4 and 5 are aggregated into super zone 3.

The figure below shows how the user can edit or designate super zones by clicking on the Zone-Super Zone Mapping at the left window and type in the assigned super zone. Click on “edit” button.

An alternative way to generation super zones is to specify the number of intended super zones and then use the Auto Generation feature (see below). The program will automatically group the original zones into the specified number of super zone evenly. However, for evacuation modeling, since the super zone OD table represents the evacuee demand, the recommended practice is for the user to first decide on the origins or the evacuees (may cover several original zones or TAZ) then group them as one super zone. The user then needs to group all the safe zones into one or several super zones. The rest of the original zones can then be grouped into one super zone.

DynusT provides the user a platform for viewing and editing imported demand data, or creating new demand information for a network through the NEXTA interface. To reach this information, click on Project → Demand Data. The Superzone Properties tab will be the first to display.

• OD Table:
  The OD Table tab features each OD pair in a spreadsheet, and is used to view, edit, or enter demand information into the model, as seen below. With the ability to load and model time-varying OD tables, each table can be viewed by clicking on the start times of each OD table in the left-side column box. Each start time represents the time of each loading interval.
  • The Overall Multiplication Factor will multiply each OD pair of every time-varying OD table by that factor.
  • Start Time of Source Matrix is the time stamp of the beginning matrix.
  • The Multi. Factor is different than the Overall Multiplication Factor at the top. When creating a new matrix it is possible to multiply only that matrix by the multiplication factor, while still maintaining both temporal and spatial patterns.
  • Start Time of New Matrix allows the input of the next time stamp for a new matrix. Each time stamp in the left hand side column box must be equal. For example, the figure below displays time stamps 0.0, 30.0, 60.0, and 90.0. The first time stamp of 0 represent the demand from time 0 to time 29.9. The next represents time 30.0 to 59.9, and so on. The program recognizes that the time increases by thirty minutes so automatically puts 120.0 in the start time of the new matrix.
  • Add Copy creates a copy of the most recent demand matrix at the next time interval. The overall demand can be uniformly increased or decreased using the Multi. Factor or by manually changing OD pair values.
  • Add Blank creates a blank matrix for the next time interval so the user may manually enter demand values.
  • Delete deletes the current matrix in the table view.

The same process applies to the matrices for truck and HOV vehicles.

• Truck OD Table & HOV OD Table
  The Truck OD Table and HOV OD Table are meant to load only trucks and HOV into the network. The OD Table tab functions apply to the matrices for both truck and HOV demand. Although these files are required in the dataset, they may be left empty to specify that no truck or HOV demand are to be loaded. Truck demand or HOV demand may be loaded by specifying a fraction of the total vehicle demand. This method is explained in the Scenario Data section.

• Superzone Properties:
  This is the first tab of the Demand Data window. It provides the initializing procedures of utilizing superzone information and modeling applications. The further use of superzone modeling applications is explained in greater detail in the Modeling Application Area under evacuation.
  • Use Superzones is a check box that allows the use of superzones.
  • Zone → Super Zone Mapping is the column box that displays the mapping between normal TAZ's and the set of superzones being modeled. By default the mapping is set to every zone mapped to itself.
  • Super Zone Number is the edit window to change the superzone index value for each TAZ/superzone mapping pair.
  • Initialization resets the TAZ/superzone mapping pair values to default.
  • Number of Super Zones and Auto Generation will automatically assign all TAZ's to the number of superzones specified in the edit box.

• Superzone OD Table Evacuation Applications:
  This tab displays the demand data of the superzones. The functions in this window are similar to the functions of the OD Table tab described at the beginning of this section. The further use of superzone modeling applications is explained in greater detail in the Modeling Application Area under evacuation.

Timing Plans
The timing plans window gives the types of control on each node. It requires timing plan start times. Any phasing movement given in this file will work only if also specified in the movement.dat input file. Movement.dat will always be used instead of this window when there is a conflict between movements specified in control.dat and movement.dat files. An example of this window is given below.

Two Way Stop Capacity
The two way stop capacity window can be seen below. The simulation discharges vehicles at Two-Way Stop-Controlled (TWSC) intersections based on to three types of turning movements (LT, TH, and RT) and the flow rate of the major approach. For each simulation interval, the model checks the flow rate of the approach of a TWSC intersection and then gives the appropriate saturation flow rates for the given type of turning movement.

This technique is different than other simulation modeling software, that use the critical gap acceptance theory and car following techniques. DynusT can be calibrated to produce these type of results by adjusting the discharge flow rate for various traffic flow rates and turning movement combinations.

Four Way Stop Capacity
Below is an example of what a four way stop capacity window looks like. The simulation discharges vehicles at All-Way Stop-Controlled intersections based on the type of turning movement and degree of traffic conflict. For each simulation interval, the model checks the number of conflicting approaches of the all way stop intersection to determine the degree of conflict, and then assigns discharge rates for each type of turning movement.

Yield Capacity
The yield capacity window under the Project→Capacity data drop down menu is shown below. The simulation discharges vehicles at Yield Sign-controlled intersections according to the three types of turning movements (LT, TH, and RT), and the flow rate on the major approach. For each simulation interval, the model checks the major approach flow rate, and assigns saturation flow rates for the type of turning movement.

Yield signs are modeled in exactly the same manner as two way stop intersections, except that the user needs to give the discharge rates.

Traffic Flow Model
Below is an example of what the traffic flow model window looks like. Further information on this window is given in the section Node and Link Attributes.

Grade Length PCE
The Grade Length PCE window is shown below. It is based on the Highway Capacity Manual 2000. PCE values are for changing the physical capacity of links (arterials and freeways), and maximum service flow rate on freeways.