联系我们
如果您需要帮助，请与我们联系。
电话：(800) 226 - 1013
电子邮件：mctrans@ce.ufl.edu
为了更好地帮助您，请准备好您的TSIS版本号或激活号码。您可以通过选择“Help”，然后点击“About TSIS”找到。如果方便，请分享输入或项目文件，这将有助于我们解决您遇到的问题。
提示和常见问题
以下是我们最常被问及的问题。
Actuated Control and Detectors
Make sure fully actuated signal controllers have detectors set at all appropriate link approaches. Independent detectors should be set for each lane used by the corresponding signal phases.
How to Model Turn Movements at urban intersections?
For every node, the user needs to specify the turning movements for every upstream node ID (highlighted). A destination node is assigned for each movement and the upstream node. The receiving node for any turn cannot be the same as the upstream node. Also, turning demands should be specified, in total demand or percentage. Note that percentages must add up to 100, approximately. Turning volumes also need to be defined for nodes to/from entry/exit nodes, in which case the only movement is the through movement, and the percentage is always 100%
Is it possible for TSIS to automatically combine two networks into one?
Version 6 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 TSIS were not capable of automatically merging two TNO networks into one.
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 TSIS, 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 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 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 can an exclusive, channelized right-turn lane with an island be coded?
In TSIS 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 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.
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 TSIS, you can select Network > NETSIM Setup > Spillback, to calibrate the probability of vehicles joining spillback.
Can FRESIM simulate interior auxiliary lane drops?
Yes, but it is necessary to code the auxiliary lanes in a specific sequence. If you right-click on a freeway link and select Edit > Lanes, you must code the acceleration lane first (on top), and then the full auxiliary lane. This coding technique is illustrated in the interiorauxlanedrop.trf sample network (click on the Sample Data Files link on the right side of this page).
What is the best way to simulate U-turns?
It is possible to specify that the downstream node number of the U-turn receiving link is the same as the upstream node number of the subject link. Assuming right-hand drive, the left-diagonal receiving link may then be used as the left receiving link if both U-turns and left-turns are desired. Vehicles that are performing the U-turn will in fact use left-turn logic for gap acceptance and positioning on the receiving link when the turn is completed. This type of U-turn can be done with any type of signal control, including sign control and uncontrolled, although actuated control may be preferable in some situations (see below).
Turn pockets can only be used to serve one type of turn movement, so U-turners and left-turners cannot both use turn pocket lanes. Therefore in some situations it may be preferable to define a full-length, channelized turn lane to model a turn pocket that serves both U-turns and left-turns. In other cases, left-turn pocket lanes could be used as U-turn lanes, and the adjacent full lanes could be channelized for left-diagonal turns.
When U-turns and left-turns share the same lane at a signalized intersection, it is best to simulate this by defining an actuated controller. To handle shared lane U-turns and left-turns at a pre-timed controller, it is preferable to code the signal as actuated, but specify max recall to emulate pre-timed operation. Similarly, when U-turns and left-turns move during the same signal interval, actuated control should be used.
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 to better control vehicle paths and lane selection in NETSIM.
- Channelization codes. NETSIM can be calibrated to produce the correct lane utilization by using special channelization codes. 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.
- 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.
- Conditional turning movements. This input specification prevents vehicles from making consecutive unrealistic turn movements.
- 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.
- 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.
- Interchanges. Origin-destination data may be specified between nodes containing paths with 10 links or fewer.
- Driver cooperation. The percentage of cooperative drivers can be increased. The default is 50%.
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.
It seems that incidents can only be specified for the first time period in CORSIM. Is it possible to set up incidents for the following, subsequent time periods?
Incidents can occur in any time period. Input coding must occur in the first time period, but the onset time of the incident can be any time during simulation.
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 website, 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.
What is the best way to use vehicle type off-ramp exit multipliers? It seems difficult to achieve the correct number of off-ramp exiting vehicles for each vehicle type, even when vehicle type off-ramp exit multipliers are used.
The easiest way to achieve the correct off-ramp exit volume for each vehicle type is to specify that zero vehicles continue onto the mainline link, and that 100% of vehicles exit at the off-ramp. After the vehicle type multipliers are used, vehicles that didn’t exit at the off-ramp will continue onto the mainline link. For example, if you want 1830 vph on the mainline and 1253 vph on the off-ramp for vehicle type 1, specify 1253/(1253+1830) = 41% as the multiplier for vehicle type 1. Simulated volumes may not be exactly right due to precision issues, but they should be close.
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.
Why does the link node diagram sometimes disappear when working in TSIS?
Why does the software sometimes say “Parse Error: not well-formed”?
There is a known problem concerning non-standard characters. The XML parser in TSIS 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.
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.
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 “TRAFVU Executable Image has encountered a problem and needs to close”?
This is usually caused by a bitmap filepath that exists in the TRF file, but does not exist on the target computer. The problem can usually be solved by deleting the bitmap background path data at the bottom of the TRF file, or by deleting the filepath (in which case the bitmap background file must reside in same folder as the TRF file), or by fixing the bitmap background filepath. In other more rare cases, where a TRAFVU crash is unrelated to the bitmap background filepath, it may be best to send your TRF file to McTrans for further testing.
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.
Under the output processing screen (in the Object window), how can I automatically select all links from Object categories such as Link_Surface and Link_Freeway?
Select an Object category (e.g., Link_Surface), right-click and select “Check All”. Repeat the process for other Object categories such as Link_Freeway, if desired.
Why does the simulated percentage of off-ramp exiting vehicles differ from the input coded percentage of off-ramp exiting vehicles?
Possible causes for the unexpected exit volumes may include stochastic randomness, surface street queue spillback, or interference from interface nodes. Regarding stochastic randomness, exit fractions might become more accurate after averaging the results from multiple runs with different random number seeds. Regarding surface street queue spillback, this sometimes prevents vehicles from exiting the freeway. Regarding interface nodes, FRESIM has trouble predicting the number of vehicles entering from those locations. When this happens, exit percentages can be adjusted to give better results.
How is it possible to have HOV violators, when the HOV violation percentage is set to zero?
After a vehicle has crossed the warning sign for its exit, it is allowed to use any HOV lane that leads to the exit, even if it doesn’t qualify to use the HOV lane.
I have a ramp meter that does not function properly. Cars do not move when the ramp meter turns green, and the green duration is very short. What could be causing this behavior?
The green phase of a FRESIM ramp meter often lasts 1 second; but the first vehicle in queue, or the first two if “two per green” is enabled, is allowed to proceed and then ignore the signal. In some cases the problem is a lane drop warning sign, which is located directly on top of the node where the ramp meter is located. It will work if the warning sign is moved 1 foot downstream to allow vehicles to respond to the ramp meter and then respond to the lane drop, instead of trying to respond to both of them at the same point. In other cases, Startup Delay should be changed on the ramp metering link. For example, a Startup Delay of 0.1 seconds will sometimes produce much higher capacities than a Startup Delay of 1.0 seconds.
What is causing unusual or unrealistic traffic assignment results in NETSIM?
The traffic assignment logic requires that all signalized or uncontrolled intersection approaches actually have vehicle volume on them. Also note that traffic assignment cannot be performed for CORSIM files containing FRESIM links.
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.
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:
- The gap reduction code should be ’0′ instead of ’2′.
- The maximum initial interval should be equal to the minimum green.
- Min recall should be activated to avoid phase skipping, if phase skipping is not desired.
- The minimum gap should be 2.0 seconds or higher.
Is there a quick way of getting the average travel time through a network (i.e., from one entry node to another)?
You can use the Output Processor to get the Travel Time Per Vehicle MOE for each link in either NETSIM or FRESIM. The Output Processor will export the selected MOEs to an Excel spreadsheet, or a file of some other format. The Travel Time Per Vehicle link MOEs can be summed to get the average travel time from the start node to the end node. This method will include travel times for turning vehicles as well as through vehicles on all links. To get a better estimate of the travel time it is possible to get the Travel Time Per Vehicle by turn movement and use the appropriate MOE for each link in the path. Note that the average will be based on all vehicles that traveled on the selected links, not necessarily vehicles that complete the entire trip from first node to last node.
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”.
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.
Should I be concerned about warning message 252; which says the flow rate is zero, but the percentage of trucks or carpools is not zero?
If you are using “flow rate variations within a time period” for a given link, then the warning message is nothing to worry about for that particular link. If you are using flow rate variations within a time period for a given link, then the flow rate will not be zero for that particular link.
When a warning message is reported in the output such as “100 VEHICLES BACKED UP BEHIND NODE 8001″, are vehicles essentially waiting for their opportunity to get on the network if circumstances allow for that? Or, are those vehicles lost, such that you would end up with fewer vehicles being simulated?
There is a software queue for each entry node. Vehicles are put into the queues based on the volume inputs and are ordered by their assigned time of entry. When the simulation reaches the entry time of the vehicle at the front of the queue that vehicle will enter the network. If it is unable to enter the network it remains the first vehicle in that queue, and it will try to enter on every successive time step until it is able to. No vehicles are lost, but some may still be in queue when the simulation ends. If so, volume would be reduced by the number of vehicles still in queue.
What does the following warning message mean: NODE 1 DESTINATION VOLUME SPECIFIED BY ENTRY VOLUMES AND TURN PCT IS 19.0…THE OD CALIBRATED DESTINATION VOLUME IS 31.0
FRESIM was unable to generate a balanced O-D table using your inputs. The CORSIM Reference Manual discusses that issue in the Overview for RT 74. You may need to adjust your inputs as described in that overview to get a better balanced table.
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:
- The default off-ramp warning sign distance (2500′) extends beyond the boundaries of the FRESIM network, and must be shortened.
- A combination of high travel speeds and short deceleration lane length makes it difficult for vehicles to switch into the deceleration lane.
- 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.
- 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.
- Off-ramp warning signs are not located where at least one lane leads to the off-ramp, or warning signs are located where they would reduce the number of usable lanes to zero. For example, if a vehicle crosses an off-ramp warning sign indicating that the only acceptable lane is lane 1, and then it crosses a lane drop warning sign that indicates that lane 1 cannot be used, there will be no lanes for that vehicle to use. If that occurs, the vehicle will ignore what the warning signs have indicated and just stay in the current lane. In that case the off-ramp warning sign should have been placed downstream from the lane drop. There are many variations of that concept with different types of geometries.
What causes Fatal Error – 6500 – Link (xxxx, yyyy) 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.
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 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.
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.
Another known geometry that can cause a leader-follower error involves a freeway that branches (diverges) and then branches (merges) back onto itself. The result is that there are two separate paths from the downstream end of the freeway to the upstream end. That causes inconsistencies in locations calculated for vehicles on those two paths. If the paths have different lengths, a vehicle may appear to be downstream of the subject vehicle when in reality it is upstream. When the two vehicles merge onto the same path, the follower is ahead of the leader. Whenever a freeway branches and then branches back onto itself the two paths must be broken into two segments; which can be done by adding dummy exit and entry nodes, or by inserting a NETSIM section into one of the ramps.
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 to run 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.
What might be causing ” ***** FATAL ERROR – 2233 – Station 1 exists in station sequence for route 2 but the link it occupies does not appear in link sequence for route 2. Check Record Types 187 and 188 for route 2 “?
This might indicate that the bus station numbers are out of sequence on record type 188. Apparently the station number sequence (on record type 188) needs to be consistent with the order in which stations would be encountered by a bus driver.
For step-by-step instructions on how to download and activate TSIS-CORSIM, please visit here.
