Additional Functionalities

Currently, DynusT v2.0 is available with different versions for different Windows© platforms:

1. Windows© XP, 32- and 64-bit,
2. Windows 2003 Server, 32- and 64-bit, and
3. Windows Vista© 32-bit only.
4. Windows 7 32- and 64-bit.

For the 32-bit version, the size of the number of network nodes is limited to 65,000. There is no size limit for the 64-bit version. The XP and 2003 Server versions are cross-platform compatible, but Windows XP and Windows Vista versions are not 100% compatible. The user is advised not to perform cross-platform installation.

For each platform, both single-threaded and multi-threaded versions are available. The multi-threaded version is noticeably beneficial only when running a large network on a multi-core computer.

DynusT was developed using Intel-Based CPU and may have contained specialized CPU instructions. Although the software has been fully tested on both Intel and AMD-based systems, if experiencing run-time exceptions, please contact Dr. Yi-Chang Chiu or Mr. Eric Nava for assistance.

DynusT is implemented with the OpenMP-enabled multi-threading x86 and x64 architecture. This means that a user can specify how many threads for the program to use on a multi-core PC to best suit the problem at hand. It is recommended that if the computer is a dedicated to DynusT run, then the number of threads is set to similar to the number of cores of the host PC. If the user needs to use the same computer for other tasks, then the number of threads should be set as less than the number of CPU cores in order to retain CPU time for the other tasks of interest. Tests on a 8-core PC/server show about 70% simulation time reduction, compared to a single-thread computation. To specify the number of threads to use, please access the advanced parameter setting under the Project→Scenario→Scenario.

DynusT v2.0 runs on Windows© operating system environment. DynusT v2.0 comes with both 32- and 64-bit versions. The 32-bit version can access up to 3GB of memory and the 64-bit version does not have specific memory limitation. For a 32-bit computer, to access up to 3GB of memory, modify the boot.ini file following the instructions below:

Modify the Boot.ini file in the Windows XP graphical user interface (GUI):

1. Click Start, click Control Panel, click Performance and Maintenance, and then click System.
2. On the Advanced tab, click Startup and Recovery, and then click Settings.
3. Under System Startup, click Edit.
4. Save changes, and then click OK.
5. Click Start, click Run, and then type msconfig to start the System Configuration utility.
6. Click the Boot.ini tab.

Add the /3GB flag as follows:

    boot loader
    timeout=30      default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
    [operating systems]
    multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional 3GB" /fastdetect /3GB
    multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect

More information can be found on http://support.microsoft.com/kb/833721

DynusT provides both Fortran and C DLL allowing ramp metering and signal control logic to be modified by users. Sample source codes are also provided for a user to modify. The source codes also include the data structures that are exposed through the DLL interface. Currently, the ramp metering DLLs include:

• Fixed-rate metering
• Simple feedback metering
• Intersections controls with available DLLs include:

The below DLL features are being tested and are expected to be available in future releases.

• Stop control
• Yield control
• Two-way stop control
• Pre-timed signalized control
• Actuated signalized control

Another parallel development is to access DynusT functions through external API calls. This feature allows a user to write a main program to run and control the behavior of DynusT simulation loops, giving the user the maximal control of DynusT.

This section will soon be expanded with more details regarding DLL API in the coming future.

The DynusT research team developed an unique computational technique called MIVA (Method of Isochronal Vehicle Assignment), which allows DynusT to perform assignment for long time period with given computational resource limit (e.g. computer memory). Performing 24-hour or multi-day simulation assignment become possible for DynusT in desktop computers with 2-6GB memory. Both 32-bit and 64-bit versions are available and the 64-bit version is recommended for modeling a large network. For a mid- to small-size network, even the simulation period may be long, with MIVA, the assignment does not increase memory usage regardless the simulation period.

To work with MIVA, one would place a file called epoch.dat into the data folder. Without this file, the default setting applies (1 epoch for the entire planning horizon). The following figure shows the default setting, in which the first number in the first line stands for the number of epochs for the planning horizon. The 2nd number of the first line varies from 0.9 to 1.0. The default value is 0.9. Prior numerical testing shows that 0.90 or 0.95 yields the best computational performance. The 1st number of the 2nd line stands for number of epochs in which the assignment would be skipped. This is applicable when one of the epochs spans over a time period in which traffic is light and in a free-flow condition; as such, no assignment is needed and can be skipped.

The following figure illustrate the significant computational gain of MIVA. The assignment procedure takes 1.8GB memory on a El Paso network with 558 zones, 2837 nodes, and 6871 links. With MIVA set at 24 epochs, the memory usage for assignment reduces to about 600MB from 1.8GB. The memory usage for simulation remains unchanged. The following figure also demonstrates that the relative function gap for 1, 6 and 24 epochs cases are very similar, indicating that MIVA accomplishes significant memory saving without sacrificing assignment solution quality.

The next figure illustrates a situation in which 24 epochs are specified. In a case of 24-hour planning horizon, where the simulation starts at mid-night, each epoch is in length of one hour. In this example, there are 8 epochs to skip as it is determined that traffic in these 8 hours are light and no need to performance assignment. In the prior testing experience, if a network is of more than 10k links, the optimal epoch length is about 2 hours to be computationally optimal. That is, for example, for a 12-hour planning horizon, the number of epochs would be set to be 6 in order to yield epoch to be 2 hours in length. For a large network, setting up epoch is the key to reduce memory usage and enable long-period simulation assignment, particularly if the computer memory is limited. However, MIVA may not be needed if the planning horizon and network size are both small or the user has ample computer memory. Nonetheless, MIVA also brings forth improvement in computational time for the assignment procedure. A numerical example performed on Twin Cities network, MN with about 3000 nodes, 7000 links, 550 zones, 300 min planning horizon and 1.3 million vehicles, the 5 epochs requires the least amount of computation time. At this moment, the algorithm to automatically determine the optimal number of epoch for the problem at hand is under development.

This section discusses several useful data analysis tools that can be accessed via the Tools pull-down menu from the GUI.

MOE Statistics can be reached by clicking on a link and then going to the tools Menu Bar→Plot MOE Time Series. This can also be done by double clicking on a link, as discussed previously in the MOE Windows section.

To adjust the departure time pattern, the user must go to the tools drop down menu and select Adjust Departure Time Pattern. As can be seen below the planning horizon and the length of the intervals of departure times may be changed.

In the window below the user can adjust the number of vehicles departing at each time.

The node-to-node static shortest path shows the shortest path from the chosen node to the destination node. The first step is to choose Find Node-to-Node Static Shortest Path from the Tools drop down menu. Next enter the node in question into the pop up window shown below.

The simulation highlights the node in question in green and the destination node in red. It highlights all the possible paths in yellow and the node-to-node static shortest path in red. It also shows the time for this path in the upper left hand corner as shown below.

Choose Menu → Tool → Add Distance-Based Tolls along the selected path.

First, define the origin and destination nodes to find a path, and then select the path from the path combo box in the toolbar.

After clicking on menu item “Add distance-based tolls alone the select path”, the user can specify the start time and end time (in min) of the time interval to be tolled, and provide the toll value ($/mile) for different vehicle and occupancy types.

After the OK button is clicked, NEXTA will generate toll data based on the link length of each link along the selected path. The user can verify the generated toll data in the toll page through Menu → Project→ Scenario Data → Pricing page.

Generate Diagnosis Report
In the below diagnose network file, the top line refers to the length of links. If a link is not as long as DynusT default says it should be it shows up in this file. These links will have highlighted yellow boxes for the link length in the link properties window.

Choose Menu → Tools→ Diagnose Network Data and Generate diagnosis report A text report will be generated by checking two potential problems in network data.

(1) The user-input link length of a link is significantly different from the default length calculated based on geometric distance. The following information is printed out.

• From Node ID
• To Node ID
• Default Length
• User-Input Length
• Ratio of Length / Default Length

(2) A generation link has no outgoing links. In this case, vehicles generated from this link cannot find any paths to a destination zone.

Correct Link Length
By running this diagnosis the length of the links will be automatically set to the default length. Choose Menu → Tools→ Diagnose Network Data → Reset Link Length

Reset link length if the input link length is 50% different from the default length

Remove Generation Links Without Outgoing Links
Choose Menu → Tools→ Diagnose Network Data → Remove Generation Links without Outgoing Links
Remove generation links without outgoing links