To start DynusT go to Windows© program menu and select DynusT. As shown below, the program is listed as “DynusT v2.0 Beta (with NEXTA)”. The other items in the DynusT program menu are for uninstalling the program and for the DynusT online help web page.
Network EXplorer for Traffic Analysis (NEXTA) is a graphical user interface system used to facilitate the preparation, post-processing, and analysis of simulation-based dynamic traffic assignment datasets. NEXTA is built on the DSPEd visualization framework, which was initially developed by ITT Industries Inc. for the Federal Highway Administration in 2004. Dr. Xuesong Zhou at the University of Utah has been maintaining and enhancing its capabilities since 2005.
Please note that NEXTA is the name of the graphical user interface (GUI) for DynusT. NEXTA has both data input and simulation animation/data analysis features. For input, NEXTA allows users to create new DynusT networks and datasets, modify existing datasets, import datasets from other planning models, specify traffic analysis scenarios, specify simulation run-time parameters, and execute the DynusT simulation engine. For output simulation animation features, NEXTA allows users to load existing datasets and simulation results, and conduct extensive post-simulation analysis. Further, NEXTA allows users to export simulation results to external text files, such as programs like Microsoft Excel©, which can be read for further analysis.
When selecting File → Open, users will be prompted to identify the intended *.dws file. The *.dws file is the project file which contains the network model the user will be working on.
The software will ask if the user wants to load the demand data (origin-destination table). For large networks, the demand file will take up a majority of the computer's memory. Loading the demand data is only necessary if the user will be adding or subtracting elements in the GUI. A user can use the File → View → OD Volume option to view the zonal OD volume or Project → Demand Data to change the entries of the OD table.
If the software detects that prior simulation output files exist in the folder, then the user will be prompted with the question of whether to load the simulation results or not. This feature allows users to directly load the simulation outputs without re-running the simulation.
The next question asked is whether the user wishes to load the vehicle trajectory data. Vehicle trajectory data is only utilized to play the animation of vehicle movements. This file can also be a large file (up to several GB in size) and may take a considerable amount of time to load. It is suggested that the user load the vehicle trajectory data with discretion if the network is large. Under the situation in which vehicle trajectory data is not loaded, only the vehicle movement will be left blank. Other animation features remain available. This will usually disable the GUI for a couple minutes, depending on the size of the results.
Finally, a successfully opened dataset will look similar to the network displayed in the following figure.
After successfully opening the dataset, as discussed in the previous section, the next steps to take are to create/arrange the demand, scenario, and simulation data. Fields needing attention will consist of Assignment/Simulation Settings, Scenario Data, Demand Data, Capacity Data, and Traffic Flow Model Data. All fields can be found in the NEXTA menu bar under Project.
The first field displayed under Project will be the Assignment/Simulation Settings which is essentially the system settings of the model in terms of simulation time, the type of simulation assignment, the method of loading vehicles, and simulation intervals as shown in the figure below.
In “Vehicle Generation Mode” the user has the capability to simulate vehicles in the network from an existing OD Demand Matrix which may contain multiple time-dependent trip matrices. This would typically be simulated to User Equilibrium/Optimal (UE). After the conclusion of the UE case, the user has the advantage of re-simulating the same network with many diverse scenarios, but with the same vehicles and their associated paths, departing at the same departure time.
The DynusT network traffic model is represented by a series of nodes, links, and traffic analysis zones (TAZ). Each property of the network can be created and edited in the NEXTA display screen. The following figure indicates the main functions used to create/edit nodes, links, control devices, and zone features within the NEXTA display screen.
Node ID is simply the ID of every node in the network and cannot be duplicated.
Zone ID is the ID of the zone that the interested node resides in. By clicking the Properties button next to Zone ID selection, the properties window of the zone indicated in Zone ID will open. Zone properties will be discussed later in the section. By checking the box Destination Node the node will be labeled as a destination of the zone in the OD based network assignment. The NEXTA GUI visually shows if a node is a destination node or not. Below is a screenshot showing the difference between the two. Node 1 is not a destination node, and Node 2 is a destination node.
If a node is a destination node, the symbol will be a square (2), instead of a circle(1).
Location describes the placement of the node according the X and Y coordinates which may not necessarily reflect the actual longitude and latitude as described in the import from a planning tool, but essentially translates the coordinates to the NEXTA format.
Under the Control Type portion of the node properties, the type of control for that node can be chosen. Enhancing the control type selected can be accomplished by clicking the Properties button next to the Control Type selection. The control types are listed and explained later.
The Turn Movement category describes the allowable movements from all possible approaches (upstream nodes) to that particular node (downstream node) by choosing the node in the Select Approach to Edit. When the network is initially converted, the turning movements are set from the latitude and longitude coordinates given in the shapefile. U-turns can be simulated by checking the box labeled U-Turn Allowed from Approach.
An important note about turning movements is after a network is converted/updated/etc., some nodes' turning movements might be wrong. This is due to a current bug in the NEXTA GUI. A quick way to fix this problem is to open up movement.dat and check the turning movements manually. This is especially helpful if the user has a large network:
icon on the NEXTA icon menu bar. A one-way/two-way link can also be created by clicking Project → One-way Link/Two-way Link. Maneuver the mouse arrow to the origin node and left-click, then maneuver the mouse arrow the the destination node and left-click. Right-click to exit the link creation function. PLEASE TAKE NOTE of the “Default Link Type” option on the NEXTA icon menu bar. Immidiately to the left of the select arrow box is the Default Link Type box. The default value is Freeway when NEXTA is opened. To change the default Link Type, click on Freeway and a drop down list will appear. This list includes the ten link types. Any of these can be chosen for the next link to be created. After one is selected, click on either One-Way or Two-Way link box. Then create the link. All links that are created will use the last selected Default Link Type. Before creating a new link, select the correct link type.
The link properties include Link Type, Name, Link ID, Length, the Number of Lanes, Left-Turns, Right-Turns, Speed Limit, Speed Adjustment Factor, Service Flow Rate, Saturation Flow Rate, the Traffic Flow Model, Grade Incline, Generation Link decision and associated Loading Weight, and are seen in the figure below.
Under the Link Properties dialog box, the Link Type can be classified as: Freeway, Freeway with Detector, On Ramp, Off Ramp, Arterial, HOT, Highway, HOV, Freeway HOT, or Freeway HOV. Each link can be given a name in the Name field. This will exhibit the name of the link on the NEXTA display of the network by clicking on the menu bar View → Link Attributes → Link Name.
Furthermore, each Link Type has its own default values for link properties. Below is a table that shows the two most varying properties:
|Link Type Identification||Default Values|
|DESCRIPTION||SPEED LIMIT||TRAFFIC FLOW MODEL|
|Freeway Segment with Detector (for Ramp Metering)||70||1|
Most of the other link properties have constant default values. These include:
The Link ID field will contain a default ID from either the import of the network or if the link was manually created. The Link ID is unique to the network and cannot be duplicated, but it can be changed if desired.
Length is the distance between the nodes in feet (ft). When the field is colored yellow the presented length may not be accurate to the length measure of the NEXTA coordinates displayed. The length may be the length from the planning tool that was imported. To represent the accurate length according to the NEXTA display, click the “Reset Length” button to the right of the Length field. If the Length field is red, this means that the link is less than the minimum length for DynusT. The program will not crash, but warning messages will be generated in warning.dat.
Also from this Properties menu the user can create left turn bays and right turn bays, change the speed limit, the service flow, the saturation flow rate from and the speed adjustment factors. A link may also be made into a generation link as discussed later.
Each link can be specified with a Traffic Flow Model number. By clicking on the Properties button, the Traffic Flow Model window shows up to allow the user to modify the parameters for each traffic flow model. There is no limit to how many traffic flow models can be specified. However, there are only two types - single or two regime modified Greenshield's - available for the user to select.
In the example shown below, the model number 1 is a two-regime model with density break point = 30 pc/ml, minimal speed = 6 mph, jam density = 180 pc/ml, and alpha term = 5.5.
In the example shown below, the model number 1 is a signle-regime model with minimal speed = 10 mph, jam density = 180 pc/ml, and alpha term = 5.5.
The use of these speed-density curves follows the Anisotropic Mesososcopic Simulation (AMS) model as described in the next section.
More details for calibrating the speed-density can be found in the Traffic Flow Model Adjustments section.
It is important to note that the “Number of Lanes” in the Link Properties window stands for the number of the full lanes in the link. However, different lane configuration at the section approaching the intersection requires respective setup in order to permit the correct capacity setting for each inbound approach for each intersection. Please note that this detailed setting is advised only if the user is concerned about the traffic flow and congestion at arterials in conjunction with signal phasing/movements (e.g., permitted left-turn signal versus protected left-turn signals). In other words, DynusT will still function properly with only the default setting during the network conversion.
In the figures listed below, LB stands for the number of left-turn bays to be specified in the Link Properties window, RB stands for the number of right-turn bays, and SFR stands for the per lane saturation flow rate value.
The general rule for calculating the Saturation Flow Rate to be specified in the Link Properties windows is: 1800*total number of through lanes at intersection/number of main lane
Take lane configuration (1) as an example: in this lane configuration, neither a left-turn bay nor a right-turn bay exit so LB = 0 and RB = 0. There are three through lanes (although 2 are shared) therefore the saturation flow rate is 1800*3/3 = 1800 veh/ln/hr. In configuration (7), there are two left-turn bays (including the dedicated left turn lane) but no right-turn bay exists, and there are two through lanes (one is shared); therefore, LB = 2, RB = 0 and the saturation flow rate = 1800*2/3 = 1200 veh/ln/hr.
The setting for the “T” intersection is slightly different from that for the typical 4-leg intersection. Please see figures demonstrated below for configuration illustrations.
DynusT adopts a new mesoscopic modeling concept that departs from the typical link-based, queue-server model, called the Anisotropic Mesoscopic Simulation (AMS), as was previously proposed (Y.-C. Chiu and L. Zhou, “An Anisotropic Mesoscopic Traffic Simulation Model: Basic Properties and Numerical Analysis,” presented at the 85th Annual Meeting of Transportation Research Board, Washington, D. C., 2006.)(Y.-C. Chiu and H. Song, “The Development and Calibration of the Anisotropic Mesoscopic Simulation Model on Uninterrupted Flow Facilities,” presented at the 86th Annual Meeting of TRB, Washington, D.C., 2007)(Y.-C. Chiu, “An Anisotropic Mesoscopic Traffic Simulation Model for Uninterrupted Flow Facilities: Part I: Basic Properties and Numerical Analysis,” Transportation Research Part B (under review), 2008).
The AMS model is built upon an intuitive concept that at any time, a vehicle’s prevailing speed is affected only by vehicles in front/ahead of it, including those in the (immediate) adjacent lanes. In other words, for any vehicle i, only those leading vehicles (in the same lane or in the adjacent lanes) present in vehicle i’s immediate downstream and within a certain distance are considered to be influential to vehicle i’s speed response. This is a similar concept to stimulus-response type of car-following models with the difference that the stimulus of a vehicle’s speed response is represented in a macroscopic form. As shown in the Figure below, for the modeling purpose, the Speed Influencing Region for vehicle i (SIRi) is defined as vehicle i’s immediate downstream roadway section in which the stimulus is significant enough to influence vehicle i’s speed response. The prevailing speed of vehicle i is determined by using a macroscopic v-k relationship based on the density in SIRi. Every vehicle retains its own speed according to traffic conditions in front/ahead.
The figure below shows the vehicle simulation trajectory, which exhibits realistic wave patterns.
In the previously reported publication (Y.-C. Chiu and H. Song, “The Development and Calibration of the Anisotropic Mesoscopic Simulation Model on Uninterrupted Flow Facilities,” presented at the 86th Annual Meeting of TRB, Washington, D.C., 2007), the analytical (e.g. compliance of LWR models and shockwaves) and numerical properties of AMS as applied on the uninterrupted flow facilities (e.g. mainly freeway or highways without signals) have been discussed in detail. Figure 6 depicts the space-time trajectories of AMS simulated vehicles on a freeway segment with bottleneck and temporary closure. The trajectory information clearly illustrates that AMS exhibits important fundamental traffic flow properties in characteristics, shockwaves and merging flows. Field collected data (e.g. NGSIM) were also used to calibrate the model. Satisfactory calibration results have been obtained in these studies (Y.-C. Chiu and H. Song, “The Development and Calibration of the Anisotropic Mesoscopic Simulation Model on Uninterrupted Flow Facilities,” presented at the 86th Annual Meeting of TRB, Washington, D.C., 2007).
The figure below shows the calibrated v-k curves using NGSIM data.
There are four main intersection control devices used in DynusT
Similar to the placement of a node, the distribution of control devices throughout the network model is simply done by clicking on the appropriate icon. Further discussion is found below for each control device.
* Considerations for Permitted Left versus Protected Left Signal Phasing The left-turn capacity under the permitted left-turn phasing situation is complicated due to a large amount of factors. DynusT adopts the methodology proposed by Chang, Chen and Perez (2007) (Chang, G.-L., Chen, C.-Y. and Perez, C (2007) “Hybrid Model for Estimating Permitted Left-Turn Saturation Flow Rate”, TRR, 2007.) to estimate the left-turn capacity for permitted-left turn situations. This method appears to provide reliable permitted left turn saturation flow rate.
Zones represent the geographical areas of what is described as the origins and destinations of the traffic volumes (OD Demand Tables) being used as input in the DynusT model. The creation of zones in the NEXTA display designates the existence of that zone, and the display is simply a geographical representation.
The Zone ID cannot be changed, so the IDs of the zones are determined in the order they were created or by the number given in the dataset import from the planning tool. The Loading Mode is either the Default Weight of User Weight. The Loading Weight is determined by the fraction of the total number of to-be generated vehicles in each simulation interval on each generation link. The Default Weight is proportional to the relative link capacities within a zone. The User Weight is defined under Link Properties. Also in the Zone Properties are the assignments of destination nodes and generation links for the zone. These portions show the available nodes and links in the zone.
The following windows may be found under the Projects→Systems Data window.
Assignment Simulation Setting
The assignment simulation setting allows the user to assign settings of the simulation from this window.
The planning horizon is the time in minutes that the simulation will run for. One shot simulation is if the user wants to use one iteration in the simulation model. This would be used to see the immediate congestions if a road is under construction or a bridge collapsed. Iterative means the simulation would run through numerous iterations to reach user equilibrium/optimal (UE). In the max number of iterations box the user can specify how many iterations the simulation will run through.
In the vehicle generation mode the user can specify if the vehicles are generated from the vehicle file only, from the OD demand matrix, or from both the vehicle and path files. If the vehicle file is selected the vehicles are randomly assigned paths, and if the vehicle and path files are both used then both the vehicles and the paths have already been assigned in the vehicle.dat and path.dat files.
The aggregation interval is the time interval over which the MOEs are averaged. This is used by the time-dependent shortest path algorithm to calculate the shortest path tree.
The assignment interval is the time interval for which the MUC solves the shortest path tree problem, and assigns vehicles generated within that interval to a path from this shortest path tree. The smaller the interval, the more accurate the MOEs. This will also require larger memory use. It is only applicable for the iterative consistent assignment procedure.
The total number of MUC threshold violations accumulated over all ODs for all departure time intervals. The lower this value is, the better traffic assignment results are.
The “Output Options” allows the user to choose which output files to create. The desired output files should be checked by the user. The output options files is explained in more detail in the Output Files Overview section of this manual.
When selecting a link and right clicking there are options for many short cuts. Below is what the right click drop down menu looks like.
Add Feature Point
Feature points are points placed in the model to make it look more realistic. By adding a feature point curves can be placed into a model without placing redundant nodes. The feature points show up as light blue dots on the simulation model. To move the feature point just select it and drag it to the desired location.
Remove Feature Point
By right clicking on a feature point on a link and choosing the remove feature point from the drop down menu, the feature point is removed from the model. A straight line attaches the remaining feature points or nodes.
Remove All Feature Points
By right clicking on a link and selecting remove all feature points from the drop down menu, all feature points are removed from the link and the nodes are connected by a straight line.
By right clicking on a link and selecting properties, a properties box is opened. Below is an example of this pop up window. This gives all the properties of the link. The link can be given a name, number of lanes, and turn bays for example.
Delete The delete selection in the drop down menu deletes the highlighted feature, or link.
Add a Contra Flow Link The Add a Contra Flow Link is a short cut for creating a two way link.
The following are selections from the right click drop down menu that will open the scenario data window under projects. This is explained in further detail in another section.
The simulation running screen shows a blue splash screen when it is calculating without error.
The Dynamic UO Assignment assigns a destination for the single occupancy vehicles (SOV). This is done before running the iteration for this assignment. The only iteration that runs without assignment is iteration 0. This screen continues until all destinations have assignments.
Following the assignment of the SOV's the screen shows the current iteration and the current time in minutes. This screen will continue through the total time of the simulation.
The simulation will continue calculating until it has run through each iteration designated in the model.
DynusT adopts a flexible and robust interface approach with all existing planning software packages. This section provides the appropriate stages of the process of importing a complete dataset for the network (links and nodes), demand (OD Data), and geographic coordinate data (coordinates for nodes, links, and TAZs) from an existing planning model.
First, an important aspect of the DynusT modeling scheme is the modification of centroids and centroid connectors. Therefore, IT IS NECESSARY to revise all centroids and centroid connectors from the dataset, either within the existing planning software from which the importing model originates or by carefully modifying these items from the Excel© conversion template. An explanation of the template modification is below under Direction. An overall explanation of the centroid methodology can be found here. An Excel© template is included in the software package located in the directory in which the software is installed (file name: GIS_Network.xls). The typical path to this folder is C:\Program Files\FHWA\DynusT\2.0\.
The general procedure for network conversion is as follows:
The ID column should be consistent with their association with the network links.
The Longitude and Latitude columns contain the nodes' location on the GUI. These are usually given from the planning model.
The TAZ column indicates each node's association with a TAZ. If for any reason a node does not have a TAZ, the user may place a “0”.
The CTRL_TYPE column refers to the type of control designated to that node. The table below describes each control type's identification record.
|Control Type Identification|
|3||4-Way Stop Sign|
|4||Pre-Timed Signal Control|
|5||Actuated Signal Control|
|6||2-Way Stop Sign|
The ID column is not necessarily used in DynusT; rather, it is a reference for the user.
The Length column contains the length of each link in feet.
The Dir column contains either a 0 or 1 value. This column is closely tied with the From_ID and To_ID columns, which are node IDs for the various links. When the Dynus-T conversion proceeds, the program will use these node IDs to create each link. This means that all links in Dynus-T are directional. So, through this Excel© template, one can easily change the direction of each link. A 1 designates the link as a one-directional link from the From_ID to the To_ID, while a 0 will designate this segment as a bi-directional link. Lastly, a -1 will create a link in the opposite direction, from the To_ID to the From_ID.
The Type column refers to the link's class or type. The table below describes each link type's identification record.
|Link Type Identification|
|2||Freeway Segment with Detector (for Ramp Metering)|
The Lanes column represents the number of lanes in each directional link. As stated earlier, all links in DynusT are directional links. Since many planning tools represent links by one link that is marked as bi-directional, the user must be diligent if creating a bi-directional link from one link listed. For example, if one link is going to be bi-directional, the Dir will be “0”, yet the number of lanes may be listed as “3”. DynusT cannot split this evenly or indicate 1 lane in one direction and 2 lanes in the other. If this occurs, please consider listing another link in the Excel© template with the opposite listing of the From_ID and To_ID. Towards the end of this Network Conversion section is a description of the possible warning message that DynusT may give in the eventual import of the Excel© template. TAZ, From_ID, and To_ID are simply the listing of the associated From and To Node IDs.
The TAZ column associates nodes with certain TAZ IDs.
The GRADE column contains the average grade of the link. These values are in (%).
The NAME column designates the name of the link.
The LEFTTURNBAY column contains the number of left turn bays. These are only for dedicated left turn bays, and do not allow through movements.
The LIMIT column has the speed limits in miles per hour (mph).
The ADJSPEED column contains the Speed Adjustment Factor. This value is usually either 0 or 5. This value adjusts the speed of vehicles on that link. For instance, if a link had a speed limit of 40 and a speed adjustment factor of 5, the vehicle's free-flow speed could be 35 or 45. This factor gives the user more freedom in microscopic modeling.
The SATURATION_FLOW_RATE column contains each link's saturation flow rate. This value is used for arterial links, because the saturation flow rate is measured at intersections. Dynus-T uses this value for all arterial links, and ignores the service flow rate.
The MAX_SERVICE_RATE column contains each link's maximum service flow rate (capacity) and is used for all links (i.e. arterial, freeway, HOT, HOV, etc). Dynus-T ignores the saturation flow rate on freeway-type links.
The RIGHTTURNBAY column delineates the number of right turn bays. Like the LEFTTURNBAY column, it is only for dedicated right turns.
When inputting zones from the excel spreadsheet, be sure to save a copy of the spreadsheet. When it is loaded to DynusT, closed and reopened, the zones will be reassigned if there were breaks in the numbers, i.e. from 80 to 200. The zone boundaries are not affected from the reassignment.
Once the Excel© file is prepared, the user can import this Excel© template file through the steps as shown in the following figure.
As mentioned previously pertaining to the indication of the number of lanes and bi-directional links, DynusT will ask the following question as a warning.
This statement refers to links in the spreadsheet that are labeled with Dir = 0, and whether the number of lanes for that link are for one direction or “split” the link evenly to create bi-directional links. Please refer to the lanes portion of the “Network Conversion” process above for possible remedy. In other words, answering 'Yes' imports the links as a 1, which is one-directional and answering 'No' imports the links as a 0, which is bi-directional.
The general procedure for demand conversion of SOV (Single-Occupancy Vehicle) is as follows:
If the demand data is not loaded correctly, it was likely not correctly entered in the format as shown. UltraEdit is a useful program to format the data. The “13” indicates the number of zones in the network. Please change this to the correct number. The “4” indicates the number of demand tables this importing demand file is going to represent. For example, if a demand table from the planning tool represents a 24-hour time period, and this table is being divided 24 times, there will be 24 demand intervals. The “5” represents the length of time in min that each demand interval represents. The last line gives the proportion of the original demand table that each demand interval will have.
Please note that if truck and HOV tables are available, they can be prepared through the same process as SOV. Import these tables one at a time.
Geographic features of nodes, links, and TAZs can be exported from planning software. These describe the coordinates of the curvature of links and TAZs. These “GEO” files are exported as .geo files. A Node GEO file is required for consistency of all described geographic features imported. These files are not necessary in terms of the modeling applications of DynusT; however, a potential issue without the zone boundary GEO file may be in the assignment of generation links and destination nodes if nodes and links were not assigned zones initially in the imported Excel© template as discussed earlier.
The general procedure for GEO file import is as follows:
This section lists the data used by DynusT. Note that some data are required and some are optional. The required basic data are highlighted with the parentheses.
A shapefile (*.shp, *.shx, *.dbf) from the planning model provides the following input information of nodes:
A shapefile (*.shp, *.shx, *.dbf) from the planning model provides the following input information of links:
(preferable but not required)
(for Evacuation Modeling, preferred but not required)
Zones may be created with an excel spreadsheet or by drawing them in the GUI. To use the Excel spreadsheet to draw the zones, the Geo files will be needed. If there are no generation links or destination nodes given the user may choose to assign generation links and destination nodes in the model.
Destination Nodes and Generation Links
In DynusT, vehicles leave and enter the network through two entities: destination nodes and generation links.
Generation links generate vehicles into the network. Vehicles are randomly rendered along the generation link. These vehicles are created based on the zone the link is assigned to. There are two ways to designate generation links in DynusT:
1. Right click on a zone and click “Assign Generation Links and Destination Nodes Automatically” from the menu as can be seen below. The zone selected is highlighted in pink.
2. The user may also manually assign a zone under the “link properties”. When the “Generation Link for Zone” box is checked, a zone can be input manually by clicking on the “c” to the right of it, as shown below.
Destination nodes are the entities in which the vehicles leave the network. These are also assigned to a zone to where the vehicles arrive. There are two ways to designate nodes as destination nodes in DynusT:
1. As with generation links, the tool “Assign Generation Links and Destination Nodes Automatically” can be used.
2. Another way to assign destination nodes is to bring up the node properties by either double-clicking on the node or right-clicking and selecting “Properties…” After the “Node Properties” window is brought up, click the check mark next to “Destination Node.” The drop-down box above determines which zone the vehicle's destination will be.
It is important for the user to check that the nodes are in the correct zones, that the generation links and destination nodes are correct in the model.
In DynusT, the assignment of generation links and destination nodes is very similar to planning models. However, planning models use centroids so that vehicles can enter and exit the network. This causes problems in DynusT because this program deals with traffic in a mesoscopic manner. When the user's network is converted, these centroids create havoc for DynusT.
One of the largest issues centroids cause is the incorrect assignment of the shortest path algorithm DynusT uses. Since centroid connectors are converted as bi-directional links, vehicles travel through along these links and through the centroid. This causes the simulated vehicles to bypass the actual network, which gives incorrect results. An example of this is below:
The picture below shows a small example of how vehicles can bypass a network. Here is the network setup:
As shown, there is a grid network with two external zones (TAZ2 & TAZ3) and one internal zone (TAZ1). All the links have the same attributes (i.e. class, length, traffic flow model, etc.). Also, the scenario was solved for the shortest path. This scenario has 1000 vehicles loaded from TAZ2 & 3 and no vehicles generated in TAZ1. The destinations are only at TAZ2 & 3.
From this rudimentary example, it can be shown that vehicles will bypass the actual network and only travel through the centroid and its connectors. This issue causes the network to be uncalibrated and incorrect. A screenshot of this scenario is below:
As shown above, the vehicles go through the centroid and do not pass through the network links. This is because the vehicles are looking for the shortest path possible. Since the centroid connectors are there, they allow the vehicles to travel through them.
Another issue with centroids is the destination of vehicles. In most planning models, the centroid is the destination node. From the previous example, it was shown that centroid connectors are detrimental to a network. They can also cause artificial congestion around the centroid. Generation of vehicles happens around the centroid, while simultaneously having vehicles exiting the network through the centroid. This concentration of traffic will give false outputs in DynusT.
The example network from the previous example will be used, but it will be modified. TAZ2 & TAZ3 will be still have the same OD pairs, but TAZ1 will be added as a destination zone with added demand. The link properties will be the same.
This example shows that the network is so laden with congestion that the vehicles will take a much longer route in order to take the shortest path possible. The vehicles travel around the destination node, through the network, and results in a higher travel time. Also, since the vehicles travel through the centroid connectors, the travel time increases as well.
However, planning models and DynusT do agree on how generation links are created. If vehicles are loaded into the network via an outside link, artificial congestion will not be an issue. This is the methodology used when DynusT networks are created.
All these issues have led to a methodology for fixing the centroid problem. This alleviates the issues the centroid causes while keeping the benefits of the generation links. Below is an example of how a network should look.
Notice that in this screenshot the centroid connectors are one-directional links, with the from node being the centroid. This allows the network to generate links on the centroid connectors, but does not allow vehicles to bypass the network through the centroid.
Furthermore, the destination nodes are set as the centroid connectors' “to nodes.” This is beneficial to the network for two reasons:
1. This method fixes the problem of artificially congested intersections. For instance, if TAZ destination were all set at intersections, it would cause all the vehicles to be drawn to these locations. This would cause longer delays throughout the network because of the intense volume increases around the intersections.
2. The vehicles are behaving in a realistic way, because they are allowed to move through the network. This method does not constrict the vehicles to leave at intersections. Also, the vehicles are leaving the network within the link, which is more consistent with actual network properties.
When importing a dataset the actuated control is the default control. The timing for the actuated controllers can be changed in the dataset in the signal sheet. Max Green, Min Green and Amber values need to be filled for the default values. When the dataset is imported to DynusT, individual traffic controllers can be changed. To do so, double click on a node and select the non-default control type. The timing can be changed for individual actuated controller in this way.
In addition to the NEXTA GUI that provides extensive data analysis capabilities for DynusT, DynusT installation package also comes with a number of utilities that can be used to facilitate the pre-process or post-process of input or output data. These utilities were written by the development team and other researchers who have used DynusT in several prior projects. These tools were mostly written in Python or Matlab computer language. Some utilities can be directly executed in the Windows© environment, some may need additional computing environment (e.g. Matlab). Below are the descriptions of a selected number of utilities that are released along with v2.0.
Depending on provided information, there are instances in which the O-D demand data is represented in disaggregated time periods. In other words, a 24 hour period would be depicted as daily ratios of 24 time aggregation intervals, thus having 24 separate demand matrices. If the user wishes to model a specific time period (e.g. AM peak, PM peak) from the given demand data, DynusT requires one demand file representing the entire planning period in the appropriate format.
Currently, DST only has the ability to convert a single demand matrix file into a multi-period demand file in the appropriate file format (demand.dat) by specifying the number and length of the aggregation intervals and each interval's ratio of the total matrix. Again, in the instance that a collection of time aggregation intervals are each in separate files (each representing a time-of-day ratio), this utility allows the user to “stitch” a number of separate time period files into a single demand file in the appropriate format for DST.
This tool requires the demand input data as a comma-delimited (CSV) file, and in the format of from_zone, to_zone, value. The setup file (demandSetup.txt) gives the necessary information from the user to the program to write demand.dat. Line 1 gives the number of zones, line 2 gives the number of aggregation intervals, line 3 gives the length of each aggregation interval (min), line 4 gives the demand type (1=SOV, 2=Truck, 3=HOV) followed by the names of each file being read for each demand type. The files must be in the correct order (e.g. timePeriod1.csv, timePeriod2.csv, timePeriod3.csv, etc.). All the working files, including this tool, must be in the same folder. Note that only one demand type at a time can be created with the tool. Either the user can create this simple .txt file, or the sample file provided with this tool can be edited.
The tool is activated by clicking the program called demandBuilder.py and the display window will appear giving the status of the program. After completion, the file “demand_new.dat” will be written to the file. Please review the file. In order to use this file within the DSP dataset files, please change the file name to “demand.dat”. If the demand type was either Truck or HOV, please edit the file name to “demand_truck.dat” or “demand_HOV.dat”, respectively.
The network cleaning tool is used to remove nodes and links that were originally placed in the TDM network dataset for curvature purposes. Models like TransCAD or VISUM use “shape points” or “feature points” to create curvature. These share points are considered to be actual nodes. TranPlan or TP+ users would add additional nodes to represent the curvature as shown below. These additional nodes and links negatively impact the DynusT computational efficiency since more memory needs to be allocated to keep these nodes and links. These redundant nodes and links can be removed by running the network cleaning tool described in this section.
Step 1: Copy the following input files from the dataset: Network.dat Xy.dat Zone.dat
Step 2: Double click on the program, the following messages will display.
The output files are: network_new.dat movement_new.dat control_new.dat xy_new.dat
Step 3: rename network_new.dat to network.dat, movement_new.dat to movement.dat, control_new.dat to control.dat, and xy_new.dat to xy.dat
Step 4: copy these renamed files back to the data folder
Upon the successful completion of the program, the redundant nodes and links are removed. The following two diagrams illustrate an example network before and after the cleaning. One can see that the nodes serving as intersections are not removed, but nodes and links serving as intermediate nodes and links are removed.
Some prior testing shows that the network cleaning tool results in 20%-30% reduction of network size.
Although DynusT provides default setting for signal timing, it is desirable to be able to interface with a signal optimization tool for both the current year and future year analysis and optimization. Two contributors have developed the Synchro to DynusT converter independently. These tools make migrating Synchro datasets to DynusT format much earlier. Their contributions are acknowledged at the end of this manual and the details of both tools will be made available online momentarily.