TSIS and CORSIM

Did You Know?
Known Issues
Sample Data Files

Frequently Asked Questions

Is there a quick way of getting the average travel time through a network (i.e., from one entry node to another)?

If the network is entirely within NETSIM, you can define an aggregation consisting of all of the links from the entry node to the exit node, and CORSIM will report average travel time for the aggregation.  Note that the output file refers to aggregations as sections.  There is a table labeled NETSIM SECTION SPECIFIC STATISTICS.

In the more general case, if you have TSIS 6, you can use the Output Processor to get the Travel Time Total MOE for each link and the Vehicles Discharged
(FRESIM) or Trips (NETSIM) MOE for each link and then calculate the average by dividing travel time by trips.  The Output Processor will report the selected MOEs to an Excel spreadsheet or a file of some other format.

Note that in both cases the average will be based on all vehicles that traveled on the selected links, not necessarily vehicles that complete the entire trip from entry node to exit nod
e.

Is it possible for TRAFED to automatically combine two networks into one?

Version 6.0 can accomplish this by loading both TNO files, copying the link-node diagram from one of them, and then pasting it into the second one.  Any conflicts between node numbers and node coordinates will be automatically resolved.  After this, it might be necessary for the user to manually code one or more links, to allow vehicles to travel between the previously unconnected networks.  Versions 5.0 and 5.1 of TRAFED were not capable of automatically merging two TNO networks into one.

What causes Fatal Error - 6500 - Link (32, 369) defined on RT 19 does not belong to any freeway segment?

Fatal error 6500 is usually related to incorrect specification of link type, i.e. ramp versus mainline.  The basic rule is that there has to be a continuous path of mainline links from an exit or exit interface node to an entry or entry interface node.

The bitmap background image is not visible within TRAFVU.  Is there any size limitation for the bitmap background file?

Yes.  Bitmaps are stored on disk differently depending on the type of bitmap.  24-bit color bitmaps use 3 bytes per pixel, 256 color bitmaps use 1 byte per pixel, 16 color bitmaps use 2 pixels per byte, and black and white bitmaps use 8 pixels per byte.  So the size of the file can change dramatically based on the type of bitmap.  Depending on the image that is trying to be loaded and the purpose of the image, reducing a 24-bit color image to a 256 color image could buy a lot better resolution.  Orienting the image so the longer direction is vertical could allow a bigger bitmap than orienting it horizontally.  You can use Microsoft Paint, or other graphics programs, to reduce the amount of colors in the bitmap (by using File > Save As).  TRAFED can handle both JPG and BMP, but the current version of TRAFVU can only handle BMP files.  You can use graphics programs to save JPG files as BMP files, if needed.

Is it possible to specify freeway capacity per lane in FRESIM?

By default, freeway capacity is approximately 2200 vehicles per lane per hour (vplph) in FRESIM.  Highway Capacity Manual chapter 8 indicates that freeway capacities between 1700 vplph and 2600 vplph have been measured across the U.S.  By calibrating various settings, FRESIM can be made to simulate a wide range of freeway capacities.  Many of these freeway calibration settings can be coded in TRAFED, under Network > FRESIM Setup.  A sample input file called "Max Capacity.trf" illustrates capacities above 3000 vplph, even though such high capacities are unrealistic.  To access this sample file, click on the "Sample Data Files" link at the top of this page.  Although there is no explicit input parameter for freeway capacity, some of the input parameters potentially affecting freeway capacity include:

threshold speed and distance for anticipatory lane changing
global and link-specific car following sensitivity factor
minimum separation for vehicle generation
off-ramp warning sign distance
free flow speed distribution
vehicle lengths

Note that when conditions are oversaturated in the real world, multi-period simulation may be needed, to allow all input volumes to be served.  The beginning of the first time period should be undersaturated, and the end of the final time period should be undersaturated.

How can an exclusive, channelized right-turn lane with an island be coded?

In TRAFED there is no automated technique for coding a channelized right-turn lane with an island, so one must code a couple of extra surface nodes to define the channelized right-turn link.  At that point, curvature of the channelized right-turn could be coded by making the link length longer than the distance between node coordinates, and adjusting a few settings on the Link Properties > Graphics tab.

How can I simulate a two-way left-turn lane?

Two-way left-turn lanes are easily modeled by coding a node with left-turn pockets at any location along the link where left-turns can be made.

How can I code or model an acceleration lane taper on the freeway?

There is no way to taper a lane in CORSIM, and CORSIM does not consider tapers.  TRAFVU draws a taper for aesthetic purposes only.  The auxiliary lane ends abruptly in all cases.  In CORSIM, vehicles can only be in one lane, and there is no provision for partial lanes, or to be in two lanes at once.  There is no such thing as a lane position of half way in between one lane and another.  Users are supposed to end the lane to be dropped at the point where two vehicles can no longer comfortably fit side-by-side.  That way there won't be more storage on the lane to be dropped than there is in real life.

What causes numerous instances of warning message 720?

This is usually caused by the lane drop warning sign distance.  The warning sign for a lane drop should never be at a location with only one lane.  The warning sign location is really the point at which vehicles respond to the object associated with the warning sign. If there is only one lane at the point, or only one lane usable by certain vehicles, the warning sign will be ignored.

Why do I observe incorrect traffic-actuated phase operations in conjunction with passage or pulse detectors?

Passage detectors work properly, but sometimes people use them for actuated control, and they're not very good for that. Passage detectors only detect a vehicle once when it crosses the detector. If a vehicle is standing over the detector, a passage detector is not aware of it. Because of this, actuated signals that don't work with passage detectors often simulate correctly with presence detectors. Input data files that use passage detectors for surveillance purposes seem to work correctly.

Why does the CORSIM output file show many instances of the following warning messages:
"Vehicles Missed destinations-Vehicle Number.........(and so forth)", and
"Computed leader..........(and so forth)"

The message about Missed Destinations states that a vehicle was unable to get to its freeway off-ramp and missed its destination. It will be rerouted to the next off-ramp downstream. This will change the percentages of vehicles exiting at those off-ramps. You should try to determine why so many vehicles are missing their destinations. Consider off-ramp warning sign locations, and any messages from CORSIM about vehicles not having acceptable candidate lanes to travel in. The other message ("Computed leader...") indicates that the FRESIM lane change logic broke down, possibly because of incorrectly specified connections between freeways.

What is causing unusual or unrealistic traffic assignment results in NETSIM?

Unrealistic traffic assignment results will occur at actuated signals, because no methodology is present for estimating the average green times.  The traffic assignment logic also requires that all signalized or uncontrolled intersection approaches actually have vehicle volume on them.  Note that traffic assignment cannot be performed for CORSIM files containing FRESIM links.

What causes an actuated phase in NETSIM to terminate right after the minimum green time, even when volumes are heavy?

Some techniques for avoiding premature actuated phase termination in NETSIM are as follows:
1.  The gap reduction code should be '0' instead of '2'.
2.  The maximum initial interval should be equal to the minimum green.
3.  Min recall should be activated to avoid phase skipping, if phase skipping is not desired.
4.  The minimum gap should be 2.0 seconds or higher.

What causes: WARNING 725 - While traveling on lane 1 on link (2,3), vehicle 4 no longer has a candidate lane on which to travel.  If this leads to unacceptable numbers of missed exits, reassigned vehicles or unreasonable delays, the user can check incident, lane drop, and other off-ramp warning signs for placement and eliminate contradictions. Currently, vehicle 4 will continue on its current lane.

Some possible causes include:

1.  The default off-ramp warning sign distance (2500') extends beyond the boundaries of the FRESIM network, and must be shortened.
2.  A combination of high travel speeds and short deceleration lane length makes it difficult for vehicles to switch into the
deceleration lane.
3. 
CORSIM can get confused when multiple geometric objects are located at exactly the same location.  For example, a lane drop located directly on top of a node can cause CORSIM to have trouble maintaining leader follower chains in that area.  Once a chain gets corrupted it can cause a wide variety of errors, including vehicles in non-existent lanes (fatal error 6710) and logic getting stuck in infinite loops (simulation not finishing).  Moving the lane drop 1 foot away from the upstream node may allow the simulation to run without error.
4.  There are too many anticipatory lane changes, and eliminating them can eliminate the warning messages. 
Anticipatory lane changes can be eliminated by right clicking on the appropriate freeway link in TRAFED, selecting the "Lanes" tab, and then setting the anticipatory lane change parameters to 1 mph and 1 foot, respectively.

How can I code "split phasing" for actuated controllers?

Suppose that split phasing needs to be coded in the east-west direction; all eastbound movements, followed by all westbound movements.  East-west actuated control involves dual ring phase numbers 3, 4, 7, and 8.  However, phases 3 and 7 are designed to run simultaneously, because these phases are typically used to represent the leading and overlapping left-turns.  Phases 4 and 8 must also time concurrently.  Coding all of the eastbound movements in phase 3, and all of the westbound movements in phase 4, would achieve split phasing.  The other option would be to code all of the eastbound movements in phase 7, and all of the westbound movements in phase 8.

How can I code an entry node volume greater than 9999 vehicles per hour?

The limit for standard coding at a single entry node is 9999 vph.  There are a couple of ways around that limitation.  One would be to create two or more entry nodes using 9999 vph each, and then funnel that traffic onto the entry link.  Another way would be to specify the entry volume in terms of vehicle counts.  This allows 9999 vehicles to be specified as a vehicle count, and allows counts as often as every minute.  Therefore the maximum that could be entered is 9999 vehicles per minute, although there is an internal limitation of 1500 vehicles per minute, so the absolute maximum for one entry node is 90000 vehicles per hour.

Overall vehicular demand in the network is such that queues from downstream intersections are blocking upstream intersections.  This is having the effect that traffic cannot cross from the side streets and network-wide gridlock quickly occurs as the queues build back to subsequent intersections.  In reality, the city has implemented a "Do Not Enter" policy, where traffic is supposed to wait until vehicles clear the intersection before they proceed.  Is it possible to include the "Do Not Enter" condition in the model?

In TRAFED, you can select Network > NETSIM Setup > Spillback, to calibrate the probability of vehicles joining spillback.

Why do uncontrolled left-turners from the major street yield to sign controlled vehicles?

Sometimes when no vehicles are allowed to go thru, the user does not specify the thru receiving link.  Because the thru receiving link is not specified, CORSIM doesn't check to see if there are any vehicles on it that would block the left-turners.  The conflict checking logic and the spillback checking logic in CORSIM need to know all of the receiving links, even when no vehicles will turn onto one or more of those receiving links.

Why does the link node diagram sometimes disappear when working in TRAFED?
Why does the software sometimes say "Parse Error: not well-formed"?

There is a known problem concerning non-standard characters.  The XML parser in TRAFED can only process the standard character set, which includes all ASCII codes less than or equal to 127.  The extended character set, which includes all ASCII codes greater than 127, is not supported.  For example, when an input file contains the special character û, when it is replaced with a standard u the problem is eliminated.

What causes fatal errors 6197 and 6198?

Fatal error messages 6197 and 6198 are often caused by a missing record type 25.  Off-ramps are defined by record type 25.  For the mainline link, record type 25 must be coded to indicate which node receives off-ramp traffic.  Without record type 25, CORSIM cannot locate the off-ramp destination node.  When all of the necessary record type 25's are entered, this allows the origin-destination inputs on record type 74 to function properly.

In the TRAFVU animation module, why does there appear to be an abnormal spacing of vehicles between two certain links, or, why do vehicles appear to be stacking on top of one another between two certain links?

This usually indicates a mismatch between the link length input to CORSIM (which is the distance from the upstream stopbar to the downstream stopbar) and the link length calculated by TRAFVU (which uses node coordinates and the location of other links to determine where the stopbars are located).  That mismatch forces TRAFVU to stretch or compress the link, in order to be consistent with the node coordinates.  Since it draws vehicles the same size (for each vehicle type) it sometimes appears that the vehicles are farther apart, and it sometimes appears that they are overlapping each other.

The solution is to enter consistent link lengths and node coordinates.  TRAFVU locates the node at the point where the left curbs intersect.  The location of the stopbars is then determined by the way the links connect and the number of lanes on the links.  Read section 3.3.2 in the TRAFVU User's Guide for more details.

The node to node distance is not necessarily equal to the link length.  The link length is the stopbar to stopbar distance.  The intersection width needs to be added to the node to node distance. 
Select the link in TRAFVU and right click the mouse.  Select Geometric Data, and compare "TRAFVU calculated length" to "Length".  Those numbers should be the same, or nearly the same.  If they are different, take the TRAFVU calculated length and use it as the link length.

What causes the error message that says: A FATAL ERROR WAS DETECTED IN THE LEADER - FOLLOWER CHAIN.

There are multiple possibilities for the leader-follower error:

There is a known geometry that can cause a leader-follower error.  The geometry involves a cloverleaf where a vehicle in searching for a leader can follow a path that leads to itself as its leader.  There is a work around that involves breaking the path so that a vehicle will not find itself as its leader.  One way to accomplish this is to break the loop by adding a small NETSIM link in one of the loops of the cloverleaf.  Another solution is to break one of the full auxiliary lanes between connectors into an acceleration lane followed by a deceleration lane with at least on foot separation between the two.  The NETSIM link solution is probably the cleanest of the two because you can maintain the cloverleaf geometry better.  This problem is more likely to occur with networks that have very few vehicles but can occur in any network that has a continuous cloverleaf.

Short link lengths can cause a corruption in the leader-follower chain.  When the link is short enough, and the free flow speed is high enough, it becomes possible for a vehicle to completely jump over the short link during a one-second time step.  When this happens, CORSIM's vehicle processing logic completely breaks down, and the result is usually leader follower errors.  CORSIM sends red-colored warning messages to the TSIS output window, when it detects links that are short enough to cause modeling problems.

Although the most common cause of problems with the chain is circular geometries, the second most common would be freeways that split into two branches and then rejoin downstream. Vehicle positions, which are measured from the end of the freeway, can be inconsistently calculated if there are two separate paths to get to the end of the freeway. Incorrect positions can cause errors in determining leaders and followers. Once a branch splits off from a freeway it should go to an exit node and not go back onto the freeway that it branched off of. NETSIM links may be required where the branch rejoins the freeway.

CORSIM can get confused when multiple geometric objects are located at exactly the same location.  For example, a lane drop located directly on top of a node can cause CORSIM to have trouble maintaining leader follower chains in that area.  Once a chain gets corrupted it can cause a wide variety of errors, including vehicles in non-existent lanes (fatal error 6710) and logic getting stuck in infinite loops (simulation not finishing).  Moving the lane drop 1 foot away from the upstream node may allow the simulation torun without error.

Correcting link free flow speeds can solve the problem.  FRESIM links connected to an interface node should have the same free flow speed as NETSIM links on the opposite side.

A problem with the leader follower chain can be caused by a 2.0 second lane change interval and lane drop that has a warning sign only 1 foot upstream from the lane drop.  The warning sign location should always be far enough upstream so that vehicles can stop before hitting the lane drop if they can't make a lane change.  Vehicles hit the end of the lane and then other vehicles behind them pile up onto them.  Somewhere in that pile up the leader follower chain gets corrupted.

How can I force more vehicles to use the (left most, right most) lane in NETSIM?
Can vehicles move into their "goal lane" several intersections in advance of making their turning movement?

There are a few things you can try in order to better control vehicle paths and lane selection in NETSIM.

1.  Channelization codes.  NETSIM can be calibrated to produce the correct lane utilization by using special channelization codes. In order for this to work, it is necessary to select a channelization code for a turn movement (usually diagonal) that does not exist.  Just apply the diagonal channelization code to a particular lane, assign a percentage of turns to that diagonal movement, and then specify the correct left-turn, through, or right-turn receiving node for that diagonal movement.

2.  Turning movements that feed the downstream through node, sometimes used in conjunction with a dummy node.  This is a coding technique that encourages a certain percentage of vehicles to move into the outer most lanes.

3.  Conditional turning movements.  This input specification prevents vehicles from making consecutive unrealistic turn movements.

4.  Distance over which drivers will perform a lane change.  Setting it to a larger distance causes the goal lanes to be set farther upstream.  The default is only 300 feet.  Essentially the logic uses that distance times the required number of lane changes to determine how far upstream to set goal lanes for each vehicle.

5.  Driver familiarity with path distribution.  By default 90% of drivers know their goal lane, so some users change this to 100% so that drivers will make better decisions in advance.

6.  Interchanges.  Origin-destination data may be specified between nodes containing paths with 10 links or fewer.

7.  Driver cooperation.  The percentage of cooperative drivers can be increased.  The default is 50%.

What does "Network Did Not Reach Equilibrium" mean?

CORSIM networks contain no vehicles at the beginning of a run.  As the first seconds are simulated, vehicles are emitted onto the network from entry and source nodes.  The time required to fill the network with traffic is referred to as the initialization period.  Since the initialization period does not accurately represent the conditions to be modeled, no statistics are gathered during this period.  A check is made at the end of every time interval for equilibrium, i.e. the end of initialization.  Equilibrium is assumed when the number of vehicles in the network is within 8% of the number of vehicles in the network during the previous time interval, and within 12% of the number of vehicles in the network during the second previous time interval.  In the CORSIM output file, this information is reported in the section called "Initialization Statistics".

Is there a way to input the volumes of weaving and non-weaving vehicles between an on-ramp and an off-ramp?

Specify origin-destination information.  The user can specify an origin node and the percentage of vehicles that will exit at each destination node that can be reached from that origin.  Be careful, because this input overrides the coded off-ramp exiting vehicle fractions.

How can I model a major merge or diverge of freeways?  How can I model a simple highway-to-highway connection?

The basic rule is that there has to be a continuous path of mainline links from an exit or exit interface node to an entry or entry interface node.  If a freeway branch is defined, the existing convention calls for one branch to be defined as the mainline, and for the other to be defined as the ramp.  Therefore, major merge or diverge sections must usually be modeled by defining "dummy" interface nodes and NETSIM links between the freeway sections.  If a dummy upstream mainline section is coded, NETSIM links may not be needed.  Sample files "freewaysplit.trf" and "splitmainline.trf", which can be downloaded from the McTrans web site, illustrate these techniques.  To access these sample files, click on the "Sample Data Files" link at the top of this page.

Highways can be directly connected using FRESIM ramp links.  For a simple highway-to-highway connection an off-ramp from the first highway may connect to an on-ramp onto the next highway.  However, there are limitations that sometimes require the use of NETSIM links.  When using FRESIM only, it is not possible to have a ramp that splits into two ramps, and it is not possible to have two ramps that merge into one.

How can I specify metric input and output in CORSIM?

The metric option in NETSIM is currently disabled.  FRESIM never had that option, and when they were combined, it was removed from NETSIM rather than added to FRESIM.  HCS and TRANSYT-7F can accept metric unit inputs and automatically perform unit conversion when generating CORSIM input files.

How do I prevent vehicles that have just exited the freeway from immediately re-entering the freeway?  Specification of turning movement percentages doesn't prevent this behavior.

In NETSIM, you can use conditional turn movements to prevent undesired movements.  In FRESIM, you can use origin-destination percentages to prevent undesired movements.