Getting Started

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 Creation: A node can be created either by clicking on the node icon in the NEXTA icon menu bar or by clicking Project → Node in the menu bar. Maneuver the node with the mouse arrow in the desired location, left-click to place the node, and right-click to exit the node creation function.

• Node Properties: Node properties can be viewed and modified by right-clicking on the node of interest and selecting Properties… from the display menu as indicated in the figure below, or by double-clicking on the node of interest.
  
  The node properties include Node ID, Zone ID related to the node, Destination Node identification, Location of X and Y coordinates, Control Type, and Turn Movements, seen in the figure below.

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:

• Link Creation: There are two types of link creation: one-way links and two-way links. Similar to the creation of a node, a link can be created by clicking on either the one-way link icon or the two-way link

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.

• Link Properties: There are two ways to view/modify the properties of a link: right-click on the link of interest and selecting Properties… from the display menu as indicated in the figure below, or by double-clicking on the link.
  

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:

Most of the other link properties have constant default values. These include:

• Number of lanes = 2
• Saturation Flow Rate = 1800 vphpl.
• Service Flow Rate (Arterials) = 1800 pcphpl
• Service Flow Rate (All other links) = 2200-2400 pcphpl.

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

• Stop Sign
• Yield Sign
• Pre-timed Signal
• Actuated Signal

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.

• Stop Sign Placement: Stop signs are manually entered by either choosing the stop sign icon from the NEXTA icon menu bar or clicking Properties → Stop Sign Control from the main menu. The placement of a stop sign can be either on an individual link's approach to apply only to that intersection's approach, or by placing the stop sign control on every intersection approach by placing the stop sign on the desired node. Another possible way of placing a stop sign at a node is from Node Properties. Node Properties are discussed in the previous section under Node and Link Attributes. In the Node Properties, under Control Type, click the drop down menu to choose the stop sign control device.

• Stop Sign Properties: DynusT also has the ability to accommodate for both two-way and four-way stops, depending on the node intersection. By default, the creation of a stop sign control will be four-way, but if the situation calls for a two-way stop intersection, the stop sign properties can be changed. Right-click on the node with the stop sign and select Properties…. Under Control Type the 4-Way Stop Sign will already be selected. Click the drop down menu to choose 2-Way Stop Sign. Next, click the Properties button to edit the 2-Way Stop Sign properties. Another window should appear with the selection of the major and minor approaches of the two-way stop sign intersection as shown in the figure below. In the Sign Properties window, choose the major approaches of the intersection. The two-way stop will be placed on the minor approach.
  

• Yield Sign Placement: Similar to the stop sign, placing a yield sign can be accomplished by either clicking the yield sign icon in the NEXTA icon bar, clicking Properties → Yield Sign Control in the main menu bar, or selecting the Yield Sign under Control Type in the Node Properties. The yield sign can only be placed in the direction of a link approaching the intersection. In other words, a yield sign cannot simply be placed on a node.

• Yield Sign Properties: Just like the two-way stop sign control properties, the exact procedure for placement of a yield sign for minor approaches of an intersection can be used. Under node properties, “Yield Sign” should be selected in “Control Type”. Click the “Properties” button next to “Control Type” and choose the major approaches of that intersection; the yield sign will be implemented to the minor approaches.

• Pre-timed/Actuated Signal Placement: The placement of a pre-timed signal control device and an actuated signal control device is similar to the stop sign and yield sign - either click the pre-timed signal icon [actuated signal icon] in the NEXTA icon menu bar, from the main menu bar click Properties → Pretimed Control [Actuated Control], or selecting “Pretimed Control [Actuated Control]” under “Control Type” in the node properties. The pre-timed/actuated signals are placed directly on the desired node.

• Pre-timed/Actuated Signal Properties: The properties of a pre-timed signal control device can be edited in the node properties window by clicking the “Properties” button next to “Control Type”. A display window will appear where the control device editing takes place. The figures below show the property windows for each pre-timed and actuated signal. Both property types are very similar in view. The distinct differences between the two are that the actuated signal requires a max and min green time, and the pre-timed signal control provides an “Offset Time” function. The “Turn Movements” portion describes the approaching movements to the intersection according to the movements in “Node Properties”. In “Phase Movements” the signal timings are placed for each directional movement, as shown in the below figures. The buttons titled “Set as Application Default” and “Load Application Default” are used if, for instance, it has been decided to apply “default” signal timings to the entire network (i.e. the signal timings in the figures below), the user can set the timings as a “default” by clicking “Set as Application Default”. Now when a new signal is created at another node, by clicking “Load Application Default”, the same signal timings will be placed. However, the “Turn Movements” still need to be manually selected. This “Default Application” can also be set far in advance when importing the network dataset from a planning tool, and can be further read about in the previous section titled Import Datasets from Planning Models.
  

* 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.

• Zone Creation: To create a zone the user can either select the zone icon from the NEXTA icon menu bar, or selecting Project→Zone from the main menu bar. Once selected, the zone is created by drawing the polygon shape of the zone. The zone is completed when the final point meets the first point.

• Zone Properties: To enter the properties of the zone, simply right click on the zone and chose Properties… in the display window. The association of zones to destination nodes and generation links can be appointed in the properties of the zone or in the node/link properties; although, it may be found advantageous to do this in the zone properties because the nodes or links that are within the geographical polygon of the zone will be listed. This can be seen in the figure below. The zone properties include Zone ID, Loading Mode, Destination Nodes, Generation Links, and Loading Weight.
  

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.

Output Options
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.

Properties
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.

• Link Pricing Data
• VMS Data
• Incident Data
• Work Zone Data
• Ramp Metering
• Sensor Data

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:

1. Export from the planning software the network (links and nodes) data to comma delimited (.csv) text files.
2. Copy the node/link information to the appropriate worksheet in the Excel© template. The Excel© template has the following worksheets:
   

• NODE:
  Contains the column's ID, Longitude, Latitude, Traffic Analysis Zone (TAZ) and CTRL_TYPE. All datum are available in the exported node layer data from the planning model.

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.

• LINK:
  Contains the columns ID, Length, Dir, Type, Lanes, TAZ, From_ID, and To_ID which are typically available in the exported link layer data. The other columns provided are filled at the user's discretion, or default settings will be applied to those column fields if not filled.

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.

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.

• ZONE:
  Contains two columns: ZONENO and TAZ. The ZONENO column must be in increasing consecutive numbers. The TAZ column should be filled with the actual TAZ numbers from the planning model. One should note that in a typical planning model, the TAZ number designation could be a sequence with skipped numbers not necessarily starting from TAZ 1. However, DynusT requires the zone number to start from 1 with consecutive numbers. This worksheet maintains the mapping between the DynusT zone number and the actual TAZ numbers from the planning model.

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.

• SIGNAL:
  Contains three columns MaxGreen, MinGreen, and Amber. As noted in the NODE worksheet, control devices can be placed on nodes. Because of the great possibility that the network is of a large, regional area, the size of the network may be too significant, as well as time consuming, to manually place signals for every intersection. It may be more realistic to indicate a “default” signal timing applied to the whole network from the start. This worksheet allows the user to quickly assign a default signal timing to actuated signal controls. After the conversion process, the user may manually change signal timings if desired. Please note, this is only applied to actuated signal controls.
  

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:

1. Export from the planning software the demand (OD) data to a comma delimited (.csv) text file.
2. Open the demand file in NotePad or other text editor.
3. Place the text in exactly the same format as below:
   

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.

1. Save the file as a text (.txt) file.
2. Once the .txt file is prepared, it is possible to import this file through the steps shown in the following figure.
   

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:

1. Export from the planning software the geographic coordinate data files of nodes, links, and TAZs to a GEO (.geo) file.
2. If not done already, title each file as “node.geo”, “link.geo”, and “zone.geo”, respectively.
3. Once the GEO files are prepared, the user can import them through the steps as shown in the following figure.
   

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:

• Node ID (required)
• Latitude (required)
• Longitude (required)
• TAZ association with nodes (suggested/optional)

A shapefile (*.shp, *.shx, *.dbf) from the planning model provides the following input information of links:

• From node (required)
• To node (required)
• Link length (required)
• Link direction ID (required)
• Functional class ID (required)
• Description of each functional class (required)
  • Functional classes may have different description from DynusT
• TAZ association with links (suggested/optional)
• Number of lanes per link (required)
• Free-flow speed or speed limit (optional)
• Grade (optional)
• Toll road locations (optional)
  • Toll scheme
  • Value of time for the region (autos/trucks)
• HOV road designations (optional)

• .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 ratios 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)

• .shp file of control locations (preferable but not required)
• Pre-timed signals (preferable but not required)
• Actuated signals (preferable but not required)
• 4-way stops (preferable but not required)
• 2-way stops (preferable but not required)
• Yield signs (preferable but not required)
• If .shp file not available, a description of their location (intersection names) is required Timing data for each of the Pre-timed and Actuated signals. (not required but desired)

• Location of Variable Message Signs (preferable but not required)

• Location of Ramp Meters and timing data (preferable but not required)

• Time-varying single-occupancy vehicle (SOV) OD tables
• Time-varying high-occupancy vehicle (HOV) OD tables
• Time-vary heavy Vehicle OD tables

• 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.

• Contra-flow highway scope and configurations
• Capacity increase on links
• Additional connectivity
• Prescriptive/descriptive scenario modeling
• Traffic flow rerouting plan
• Intelligent Transportation Systems (ITS) strategies
• Phased evacuation strategies
• Information provision strategies (pre-trip, enroute-DMS, enroute-navigation, etc.)
• Signal progress and optimization
• Transit strategies
• Ramp metering strategies
• Tolling scenarios

(preferable but not required)

• Scaled aerial photos of areas to be modeled (optional)

(for Evacuation Modeling, preferred but not required)

• .shp file of the follow locations
• Gas Stations
• Arenas (with capacity figures)
• Hotels (with capacity figures)
• Designated shelters (with capacity figures)
• Medical Facilities (with patient and capacity figures)

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.

Centroid Issues
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.

Centroid Solution
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.