Why is the default simulated time set to the value it is set to?

Question: Why is the default simulated time in TRANSYT 15 set to 60 minutes and to 120 minutes in TRANSYT 12?  How is it related to the 60 minute period you are normally providing flows for?

Answer: The one-hour flow data specified is, of course, only a ‘flow rate’ shown in the units “PCU/hour” and notthe flow over a one hour period – It is the ‘simulated time’ that determines the modelled time period.

The simulated time takes account of the build-up of queues over the simulated time – It only affects the results when there is over-saturation within the network.  A simulated time of 60 minutes of a 60-second cycle will give the average values for 60 cycles of the network.  The simulated time in TRANSYT set to 120 minutes is neither correct nor incorrect.  It depends really on what you want to do in TRANSYT.  In TRANSYT 15 it was decided to switch the starting value to the more commonly required value, rather than the more conservative value used in TRANSYT 12.  It is not a ‘default’ to be left as it is – it should be ‘set for purpose’. It just so happens that 60 minutes is commonly used, and hence it is what TRANSYT 15 is set to, to start with.  For example, if you simply wish to obtain the average results for a 60 minute period, then 60 minutes is what you need.

Historically, in TRANSYT 12, if you had interest in the final queue lengths at the END of a 60 minute period for a heavily congested network (i.e. significant number of links over-saturated), then 120 minutes allowed you to see approximately the situation at the end of the 60 minute period.

This is because the TRANSYT results are an average over the modelled time period, and when the network is congested the queues will be made up mostly by random (due to cycle-to-cycle variation) and oversaturated components. To get an idea of the queue lengths at the end of the 60 minutes you needed to double the simulated time to 120 minutes (assuming that the average value will then equate to approximately the queues half-way through the time period.  This is not totally right of course, as the final queues also contain the uniform (due the typical cycle) queue component, but it will give a reasonable estimate of the value wanted.  The values affected by changing the simulated time are the delays, queue lengths, and PI values. It does not affect the optimisation process however, so the green times and offsets remain the same as do the degree of saturation values.   Note that in TRANSYT 15 there is additional outputs in the form of some EoTS (End of Time-Segment) results.  These negate the need to do any of this.