SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
17.
Multiple Time Period Modelling in SATURN
INTRODUCTION
This section describes the manner in which over-capacity queues are “passed”
between time periods enabling SATURN to be used as a “quasi-dynamic” model.
Methods for modelling time-dependent matrices, e.g. models of peak spreading
are also included.
17.1
Treatment of Over-Capacity Junctions: General Principles
In order to describe how SATURN copes with the problems of flows in excess of
capacity at junctions it is perhaps useful to first outline the type of problems which
occur in conventional assignment models. Consider the very simple stretch of
road shown below with four junctions, A to D:
Let us further imagine that each junction has a capacity of 1,000 pcu/h and that
the trip matrix to be assigned consists of an hourly demand of 2,000 pcu/h from
left to right (i.e. from A to D) with no alternative routes and no other traffic. (We
might well question at this point what we actually MEAN by the trip matrix. We
shall assume that the hourly demand of 2,000 implies that 2,000 pcus arrive
uniformly at A during the hour to be modelled, even though clearly less than half
will actually complete their trip during the hour. Whether this picture of the demand
is realistic is not a question that is normally resolved during the assignment stage,
but one which needs to be more closely considered elsewhere in the overall
modelling procedures.)
What would clearly happen under these circumstances is that a queue would
develop at A such that the 2,000 pcus would require 2 hours to clear. The
average delay at A would be somewhat in excess of 30 minutes (since the first
pcu to arrive would suffer only a small delay and the last pcu to arrive would
queue for an hour with a linear increase in between), and a proper flow-delay
relationship should give this value. However there should be no comparable
queues building up at any of the 3 remaining junctions and they would operate at
capacity over the next two hours. Hence their average delays would be relatively
small, i.e., much less than 30 minutes.
Conventional assignment models would assign an hourly flow of 2,000 to all four
junctions and therefore, if they are to model the delay at A correctly, calculate
delays of 30 minutes at B, C and D as well. They, therefore, “double-count” the
queuing delays downstream of the “actual” queues.
In SATURN terms these problems do exist in the buffer network but – as we shall
see in the next sub-section – are dealt with by the simulation. (Although the
problems may be reduced in buffer networks via the UNIQUE option; see 15.48.)
5120257 / Mar 14
Section 17.docx
17-1
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
Conventional / buffer network assignment models are therefore faced with two
problems:
17.2
♦
The realistic definition of delays at over-capacity junctions which allows for
long delays where queues do form but also avoids the problem of “doublecounting”.
♦
The spreading of queued traffic over a longer time period than that implied by
the input trip matrix.
Actual and Demand Flow in SATURN Simulation
Both problems are overcome within the simulation stage in that the simulated
traffic leaving each junction (i.e. the OUT flow for each turning movement) must
be within the capacity for that turn. Thus in the above example SATURN would
correctly predict an average arrival rate of 2,000 pcu/h and an average departure
rate of 1,000 pcu/h at A; all others have an arrival and departure rate of 1000
pcu/hr and therefore junctions B to D would operate exactly at capacity. It would
also correctly predict that a “permanent” queue 1 would build up at A at the rate of
1,000 pcu/h.
We therefore define “flow” in SATURN in two distinct ways:
1)
As the “assigned” or “demand” flow. This is the flow given by the assignment
stage and corresponds to the total demand independent of when the flow
arrives, i.e., the 2,000 pcu/h at all junctions in the above example.
2)
The “actual” or “simulated” flow which corresponds to the actual flow during
the time period simulated. Thus in the above example the actual flow
arriving at A would be 2000 pcu/hr whereas the actual flows (both arriving
and departing) on links AB, BC and CD would be 1000 pcu/hr.
For turns in the simulation network we may further sub-divide the actual flows into
the “actual arriving” flows and the “actual departing” flows. The difference
between these two corresponds to the rate at which the queue left at the end of
the time period for over-capacity turns builds up. Thus at A above the actual
arriving flow would be 2000 pcu/hr, the actual departure rate would be 1000
pcu/hr and the queue would build up at an “actual” rate of 1000 pcu/hr.
Note that the number of pcus in the queue depends not only on the rate of queue
build up but also on the length of the time period modelled. If, in the above
example, LTP = 30 there would be 500 pcus in the queue after 30 minutes; if LTP
= 15 it would be 250, etc etc. It is this queue which is “passed” to a subsequent
time period under the PASSQ option (see 17.3).
The difference between the assigned and actual arriving flows corresponds to
those pcus which wish to use a particular link or turn but are prevented from doing
so by queues upstream. They may therefore be thought of as a form of
“suppressed” demand. By definition these suppressed trips must constitute part
of the ‘queued at a junction’ flows at some point upstream.
1
N.B. We differentiate here between “permanent” queues at over-capacity junctions and
“transient” queues which build up and dissipate, for example during the red cycle at traffic signals.
5120257 / Mar 14
Section 17.docx
17-2
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
Within the assignment stage the problems of traffic queued upstream and delay
double counting are overcome by using a ‘queue reduction factor’ (QRF)
calculated within the simulation. Thus if an assignment link has a QRF of 0.9 this
implies that only 90% of the total number of trips wishing to use that link will
actually arrive during the time period simulated and therefore the delays are
calculated corresponding to 90% of the assigned or demand flows.
17.2.1
Actual and Demand Flows by User Class
We note that the same distinction between actual and demand flows applies
equally to user-class specific flows as to total flows. Actual user class flows are
obtained by applying the same single link-specific factor as obtained for total flows
to user-class demand flows.
Note that this is only an approximation to the “correct” values which would be
obtained if the assigned O-D routes for each user class were reloaded but with the
route flows reduced every time an over-capacity simulation link was encountered.
However it should be a reasonably good approximation, particularly if the overall
differences between actual and demand flows are not great.
Equally actual user class link flows at individual simulation junctions may violate
Kirchoff’s Rule, i.e. total flow in does not equal total flow out, in particular if there
are multiple entries and exits in which case the estimation of the turning flows is
“under specified”. But if, for example, you have two entries and two exits and
therefore four “unknown” actual flows you also have four constraints on the total
in-bound and out-bound flows so the problem does not arise. However the
demand-based user-class flows must always satisfy Kirchoff’s Rule as will the
total demand flows.
The above considerations apply ONLY to simulation networks, NOT to buffer
networks for which the reservations expressed above concerning conventional
assignment models still apply. Thus in the buffer network demand and actual
flows are one and the same.
17.3
Linked Time Periods (The PASSQ Option)
17.3.1
Basic Principles
A “quasi” dynamic element can be introduced into runs of SATURN by modelling
successive time periods with differing characteristics e.g., with changes in the
network or level of demand. This can be particularly useful when pronounced
peaks of demand exist, and one wants to study a period during which queues
form and dissipate.
For example, if we wished to study a total time period of two hours within which
the demands for O-D travel vary continuously as illustrated in Figure 17.1, then we
would divide the 2 hours into a discrete number of sub-periods (say 4 of 30
minutes), each with its own “rectangular” demand profile. Each sub-period is the
modelled individually as described below.
The ability to model a time period whose initial conditions (including the presence
of queues in the system) correspond to the final state of a previous time period, is
controlled by the logical parameter PASSQ in the &OPTION namelist input to
5120257 / Mar 14
Section 17.docx
17-3
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
SATNET on the network data file. If PASSQ is TRUE the initial state is set
according to that recorded on the output file from the previous time period.
If two successive periods were to be modelled, the following procedure would
apply:
1) Run SATURN in the usual way for the first time period. For this run
PASSQ =.FALSE. in the initial network data file. (N.B. This is its default
value so that no mention need be made of PASSQ, as indicated in
Section 6.1.) Thus using the SATURN procedure one might command:
SATURN network1 tripod1
2) Set up a new network file (e.g. network2.DAT) in which PASSQ is set to
.TRUE. and run SATURN for the next time period using the revised
network and/or OD information. The final UFS file from run 1 is used in
this second run to (a) set up the queues, but also (b) to provide extra
information which is used to minimize the number of iterations (see note
(d) below).
1) This may be most conveniently done using the extended SATURN
procedure described in Section 14.4.1 with a command such as:
SATURN network2 tripod2 PASSQ network1.
2) or by
SATURN network2 tripod2
where the name of the “passq’ed” file is defined under &OPTION, see
6.1; e.g. UPFILE = ‘network1.ufs’.
The effect of the above procedure on the second time period is as
follows:
5120257 / Mar 14
Section 17.docx
♦
The residual queues at the end of the first time period and the
“suppressed traffic” (as defined above in 17.2) are calculated from
the input UFS file.
♦
The suppressed trips are then added by SATNET as “fixed” link
and turn flows in the second time period equal to the differences
between demand and actual flows. This means that the routes to
be used by these trips are the same as those chosen in the
previous time period so that they may be thought of as “fixed” flows
in the same sense that bus routes constitute fixed flows.
♦
In addition the residual queues per turn (which are in pcus) are
converted into an “effective” fixed flow (in pcus/hr) equal to Q/LTP
which is added to the link “downstream entry flow” for the purposes
of the assignment (see 15.16.2).
♦
The residual queues from the previous time period are also taken
into account in the delay calculations for the current time period for
those specific turning movements.
17-4
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
♦
In addition (but only if UPDATE = F; see 15.3), the network build
program SATNET also takes the final set of flow-delay parameters
from the previous time period as initial estimates for this time
period, rather than starting “cold” with default values. This has the
advantage that the number of simulation-assignment loops in the
second time period may be considerably reduced with obvious
savings in terms of CPU times. N.B. If both PASSQ and UPDATE
are T then the flow-delay data is taken from the update file, not the
passq file.
♦
Information on the total number of “PASSQ’ed” trips and their
precise locations may be found in the .LPN files produced by
SATNET.
If further time periods are to be modelled, step 2) is repeated using the previous
output file as input; e.g.: setting
SATURN network3 tripod3 PASSQ network2
Thus if we look at the “permanent” queue of traffic on a single link over several
time periods it might resemble that sketched in Figure 17.1
Figure 17.1 - Growth and decay of over-capacity queues
Thus starting from zero queue at the start of time period 1 it grows linearly over
the first time period, continues to increase in the second, stays constant in the
third and disappears during the fourth.
FURTHER NOTES:
1)
The networks defined in different time periods need not be identical.
Thus it is permissible to introduce, say, tidal flow schemes or new traffic
control settings. Suppressed flows on link A-B in one time period are
transferred to a link A-B in the next time period; if A-B does not exist then
no flow is transferred.
Thus problems may exist if, say, A-B is divided into two links A-C and CB in the second time period; the solution here is to ensure that node C
exists in all networks, even if sometimes it is only a dummy node
2)
5120257 / Mar 14
Section 17.docx
Equally the trip matrices may differ as well, although how this is done is
left to the user.
17-5
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
Given the difficulties of getting “good” trip matrices for even one time
period we would recommend that, unless peak spreading models are
being applied, trip matrices for successive time periods be set by simply
multiplying a “master” trip matrix by a uniform profile determined, for
example, by the average of observations at several sites. This may be
done using the FACTOR option in MX or, much more conveniently, the
parameter GONZO may be used to factor the matrix to be assigned; the
end effects are identical. See 17.4.3)
17.3.2
3)
The above procedure does not apply at all to the buffer network which of
course is treated in the conventional manner without queues and without
fixed flows.
4)
The value (s) of LTP refers to the individual time periods, not the total
time period modelled. Thus to model a 2-hour period subdivided into four
half-hour sub-periods the value of LTP should be 30, not 120. (This is not
to say that each sub-period should be of the same duration; different
values of LPT may be set in different time periods.)
Choice of Time Periods
Defining the time period(s) to be modelled involves choices of:
♦
the total time period to be modelled;
♦
its subdivision into distinct time periods or “slices”.
The first choice is generally straight-forward. Although in theory one could set up
linked SATURN models to run over the full 24 hours most studies consider
separate time periods such as the morning peak, inter-peak and evening peak.
The second question is how to divide, say, a 2-hour morning peak period into a
number of time slices. The most critical issue here is how rapidly travel conditions
change within the full period. If flows are reasonably constant then there is a
strong case for ignoring time slices and modelling a single time period; very often
inter-peak models do this.
On the other hand if the flows exhibit a strong “peak within a peak” then, in order
to correctly model the duration and the length of the resulting queues, sub time
periods are called for. The sharper the peaking, the smaller the time period that
will be called for.
There is however a competing requirement that the time slices should not be very
much shorter than the duration of trips within the simulation network, otherwise
the basic SATURN simulation assumption that trips are essentially loaded
simultaneously throughout the network tends to fall apart. In practical terms this
means that if, say, it takes 30 minutes for trips to travel from one side of the
network to the other then 30 minute time slices should be fine. 15 minutes is
probably still OK but 5 minutes would be cutting it a bit fine. On the other hand if
the network were only 5 minutes “wide” then 2 minute time slices might be
acceptable in some respects, although defining demand levels to that level of
detail might be questionable.
5120257 / Mar 14
Section 17.docx
17-6
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
There is also no requirement that each time slice must be of equal duration. A 2hour period might be divided into 30 minutes, 4 15 minutes and a final 30 minutes
if most of the flow variability were concentrated in the central hour.
So, final recommendation for those who can’t make up their own minds: not less
than 15 minutes, no more than 1 hour. And please remember point (4) in 17.3.2
as regards how to define LTP.
17.4
Running Multiple Time Periods Using PASSQ: Simple Procedures
This section describes a number of methods for running multiple time periods
using PASSQ which are simpler than the somewhat long-winded “one step at a
time” approach described in 17.3.1 (although the end effect is the same). They
appear in historical order of development as well as ease of use. Thus the
SATTPX method described in 17.4.3 in conjunction with SATSUMA (17.5) is the
recommended technique; the first two sections only need to be consulted if you
need to take a more do-it-yourself approach.
In fact .PS files and the SATTP procedure are now longer included in the most
recent releases of SATURN; only SATTPX is available. However, if, for some
reason, users can see an application for either they could be resurrected and
therefore the documentation is still included in the next two sections
17.4.1
The Use of “PS” Files
The procedures for running linked time periods may be somewhat simplified by
making use of special input control files to SATNET known as “.PS” files.
Basically the .PS file is read after a full network .dat file and, using a namelist
input convention, can “overwrite” the following two network parameters:
PASSQ and GONZO
This allows you to use the same .dat file for, say, time periods 1 and 2 but for time
period 2, where the parameter PASSQ must be set to TRUE, this may be altered
with a PS file:
&PARAM
PASSQ = T
GONZO = 1.2
&END
as opposed to copying and editing the original .dat file to include an entry ‘PASSQ
= T’.
Thus the command:
SATNET network PS tp2
reads the basic network data from file ‘network. DAT’ but overwrites the values for
PASSQ and/or GONZO from a file ‘tp2.PS’ as illustrated above.
The reason for allowing a .ps file to over-write GONZO is to allow you to use the
same basic trip matrix for all time periods but to introduce time period-specific
factors set by GONZO.
5120257 / Mar 14
Section 17.docx
17-7
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
17.4.2
The SATTP Procedure
A special .bat produced under DOS, SATTP.BAT, provides a simple method of
running multiple time periods making use of .PS files. Thus the command:
SATTP network trips post 4
assumes a basic network file ‘network.DAT’ and a basic trip matrix file ‘trips.UFM’
which are to be assigned over 4 time periods (set by the final parameter), where
*
files in the different periods are denoted by suffixes A, B, C and D respectively.
Thus a set of files networkA.UFS etc. are produced in time period 1, networkB.ufs,
in the time period 2, etc., etc.
The user is required to produce 4 separate ‘.PS’ files, postA.PS ... postD.PS
where all 4 files may (if they wish) define values for GONZO, ie. trip matrix factors
for each time period, and files postB.PS ... postD.PS MUST set PASSQ=T.
The .BAT file works by copying network.dat into time-period specific data files
networkA.DAT, ..., etc., and running the full SATURN procedure for all 4 time
periods with the PASSQ option invoked in time periods 2 to 4. The file structure is
illustrated in Figure 17.2.
Figure 17.2 - File Structure for Multiple Time Period Assignments
17.4.3
The SATTPX Procedure: Defining Trip Matrices
The principle of running multiple time periods has been further extended within the
batch procedure SATTPX - the strongly recommended technique - which runs
multiple time periods automatically and offers three different methods for defining
time-dependent trip matrices.
The first uses a fixed “base” trip matrix with global time-dependent GONZO factors
set by the additional namelist facility described in Appendix B whereby parameters
appropriate to different time periods may all be contained in a single .dat file by
*
N.B. Under DOS this requires that the "name" of the base network file must be 7 characters or less
in order that the suffixes A, B, C etc may be added and still be 8 characters or less.
5120257 / Mar 14
Section 17.docx
17-8
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
the use of subscripts. Thus if a network.dat file contains &PARAM definition
records:
TIJFIL
GONZO(1)
GONZO(2)
GONZO(3)
= ‘TRIPS.UFM’
= 0.8
= 1.2
= 0.9
this defines GONZO values of 0.8, 1.2 and 0.9 for time periods 1, 2 and 3 as
factors applied to base matrix trips .ufm. (N.B. Recall that all trip matrices are
defined as rates in pcus/hr, not as absolute trips, so that the GONZO values
should be of the order of 1.0, not, say, of the order of 0.25 if a time period is being
divided into 4 sub-periods.)
Secondly individual time-period specific trip matrices may be defined in the .dat
files under &PARAM using subscripts; e.g.:
TIJFIL(1)
TIJFIL(2)
TIJFIL(3)
=
=
=
‘TRIPS1.DAT’
‘TRIPS2.DAT’
‘TRIPS3.DAT’
Specific file names are required whenever they are not multiples of a common trip
matrix as occurs, for example, with peak spreading models (17.12).
Finally a single (i.e., not subscripted) trip matrix may be defined in the .dat file but
it must be a “blocked” matrix; i.e. one in which individual trip matrices per time
period (as in method 2 above) have been combined together into a single .ufm file
following the principles described in 10.2.5. Thus the .dat file might include:
TIJFIL = 'TRIPS123.DAT'
where trips123.dat is a “blocked” matrix from trips1.dat etc.
Note that methods 2 and 3 would not normally include GONZO factors since any
factoring would already have been included in creating the .ufm files.
To run this network for the three time periods for which data is provided use the
command:
SATTPX network 3
where 3 indicates the number of time periods to be run.
In this case there is no need to prepare explicit .ps files for each time period - a
standard .ps file which merely serves to turn on PASSQ is provided. The timeperiod specific data is all contained in the single network.dat file.
Note as well that the parameter PASSQ should be set to .FALSE. in the file
network.dat; it of course needs to be .FALSE. for the first time period and
thereafter the batch procedure SATTPX ensures that it is re-set to .TRUE. for the
later time periods.
SATTPX is therefore a far more flexible method than that described in 17.4.2 so
that SATTPX effectively supersedes SATTP and the use of time-period subscripts
in data files also supersedes the need for users to set up specific .ps files. (.ps
files are still used - they are merely invisible to the user.) The file structure under
SATTPX is identical to that under SATTP as illustrated in Figure 17.3.
5120257 / Mar 14
Section 17.docx
17-9
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
Note that, with later releases of the bat file (10.4 onwards?), SATTPX also
explicitly runs SATSUMA (see 17.5 next) at the end of multiple time period runs in
order to save the user having to call another bat file.
17.4.4
Multiple Time Period Network .Dat files: The use of Subscripts
The use of subscripts has been mentioned above in connection with the definition
of different trip matrices per time period and different LTP values; the procedure is
in fact general and may be applied to almost all parameter values set under
&PARAM in a network .dat file. See Appendix B.
17.5
The SATSUMA Program
Having simulated each individual time slice the final necessary step is to combine
together all the data in files networkA.ufs, networkB.ufs, etc into a single file. This
is the function of a special program SATSUMA as illustrated in Figure 17.3.
To invoke SATSUMA after a run of SATTPX type:
SATSUMA network 3
(where the parameter 3 defines the same number of time periods as under
SATTPX) to create a single output file:
network.uft
which has the same basic function as a .ufs file but which contains not only data
from each time period but also suitably aggregated data over all time periods. For
example a .uft file contains not only the flows in each individual time period but
also the average flow over all time periods. .Uft files may be input into P1X,
SATDB etc and both aggregate and/or disaggregate data displayed.
Note, however, that the .bat file SATTPX explicitly calls SATSUMA as its final
step (see 17.4 above) so that generally there is no need for a separate additional
call to SATSUMA – although there is no harm in doing so.
In addition to aggregating link/turn data SATSUMA also aggregates summary
statistics so that one may use a .uft file to display total vehicle hours, total vehicle
kms, etc over the full time period. The advantage of using SATSUMA as opposed
to a “DIY” approach is that it avoids problems of “double counting” since flows
which are passed as queues from, say, time period 1 to time period 2 tend to
appear in statistics for both time periods.
Depending on the type of data involved SATSUMA will either:
♦
Average, as with flows or times (with appropriate weighting factors).
♦
Add, as with fuel consumption which is stored in absolute terms, not as rates.
♦
Take data from the final time period, as in queue at the end of the time period.
In addition time - independent data such as link lengths are only stored once in
order to save space.
However, partly in order to save space, .uft files do not store full simulation data
such as cyclical flow profiles from each time period so it is not possible for
5120257 / Mar 14
Section 17.docx
17-10
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
example, to edit and re-simulate individual nodes. Neither is the SAVEIT option
valid within .uft files so it is not possible to recreate routes from individual time
periods. For detailed analysis of these sorts the individual files networka.ufs etc
must be accessed.
Within standard bat files “T” and “UFT” may be used in virtually the same way that
“S” and “A” or “UFS” and “UFA” are used. See 14.2.2. For example you may use:
SATLOOK network UFT
Or
SATDB net1 UFT T 2 net2
17.6
The Definition and Calculation of Queues and Delays
17.6.1
General Principles
The distinction between the delays associated with transient and over-capacity
queues and delays (see also 8.4.1 and 8.4.8) within this time period and in later
periods is illustrated in figure 17.3. This plots the number of pcus queued at an
over-capacity junction over the first and following time periods, from which the
delays are directly calculated.
Figure 17.3 - Queuing Components over Successive Time Periods
Thus in the first time period (0<t<LTP) Q t represents an average transient queue
(see 8.4.8) while the permanent or over-capacity queue grows from O to Q 1 (so
that the average over-capacity queue would be Q 1 /2). Note that the growth of this
queue may be limited by blocking back, in which case the queue effectively
continues to grow on the preceding link(s) and, possibly, on inbound centroid
connectors. However in this case those delays are associated with the preceding
link(s), not the link at the “head” of the queue.
During the second time period, as illustrated here, the newly arriving flow is less
than capacity so that the permanent queue declines (line AC) but has not gone to
5120257 / Mar 14
Section 17.docx
17-11
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
zero by the end of the second period. If however we just consider the Q 1 pcus
present at the start of the second period they decrease linearly (line AB) at a rate
equal to the capacity such that at time t x they have all passed through.
The delays experienced by the traffic arriving on this link in time period 1 may
therefore be subdivided into four components.
1)
Transient delays in time period 1, with total pcu-hrs given by the area (1),
the product of Q t and LTP.
2)
Permanent queuing delay in time period 1 represented by the triangular area
(2) equal to Q 1 x LTP / 2.
3)
The time spent by the Q 1 pcus in the permanent queue in the next time
period, triangle (3), plus....
4)
....the time spent in the transient queue in the next time period, rectangle
(4)**
The situation becomes more complicated in the second time period where not
only do we have queued traffic from the first time period but also newly arrived
traffic from the second period. Their delays are represented by areas (5) and (6)
with the possibility of extra delays in even later time periods. And to further
complicate matters the newly arrived traffic may be partly made up of traffic from
time period 1 which was caught up in queues upstream and arrivals later on in the
time period. Thus a portion of the over capacity queue (5) and the transient
queue (6) in the later time period(s) may be associated with queued-up traffic from
time period 1. Section 17.6.2 elaborates further on this topic.
Queue lengths are converted into delays by dividing by an appropriate flow generally the capacity for over-capacity movements or the arrival/departure flow
otherwise.
However in defining delays we may need to differentiate between the delays
experienced by traffic originating and/or arriving within that time period (part of
which may take place in later time periods) and delays purely within a single time
period (to include previously queued traffic).
Different functions may require subtly different definitions. Thus for assignment
purposes - where we are concerned with establishing routes for the new traffic on
the network - the relevant definition of delay per turn would need to consider:
Delays to newly arriving traffic (as opposed to traffic in queues at the end of the
previous time period).
Delays incurred in later time periods by the newly arrived traffic (if there are
queues at the end of this time period).
For the purposes of assignment the most relevant delay is that experienced by the
traffic generated within that time period since that determines their route choice.
However for simulation purposes a more relevant definition of delay would include
**
For ease of illustration we have shown the transient queues in time periods 1 and 2 to be
equal; they need not be.
5120257 / Mar 14
Section 17.docx
17-12
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
both the new traffic and the previously queued traffic. For further discussion on
this point please see sections 17.8 and 17.10.
Note however that these problems only occur with over-capacity queued turning
movements and not with transient queues.
17.6.2
Downstream Queues Encountered by Queued Traffic: The AFTERS
Parameter
As explained above over-capacity traffic queued at one junction in, say, time
period n complete their journey in time period n+1. Part of their residual route
may go through downstream links which were also over capacity and the question
arises as to how long the downstream queues will be at the time the upstream
queued traffic arrives. With reference to Figure 17.4 the question is what is likely
to happen to the end of the queue in the next time period, i.e. the line AC. Thus if
arrivals equal capacity then the queues experienced by the upstream flows will
equal Q 1 (AC remains horizontal), if arrivals exceed capacity then the queues will
be greater then Q 1 and if arrivals are less than capacity the queue will be less.
The latter situation is likely to arise if the period in question is a peak period
followed by lower flows post-peak.
Historically (i.e. pre 9.4) SATURN took a neutral but generally optimistic view that
future queues would equal the average queues in the current time period. In the
case of the first time period as shown in Figure 17.4 that would imply a queue
equal to half of Q 1 . 9.4 introduced a new parameter AFTERS such that the
expected queue in time period n+1 is given by:
Q n+1 = AFTERS • Qe n
where Qe n is the queue at the end of time period n.
AFTERS may be set under &PARAM in the network .dat file or later and, for
historical continuity, defaults to 0.5.
However a more realistic value for AFTERS should be 1.0 which assumes that the
queue remains at its final value into the foreseeable future, which is probably a
more truly “neutral” assumption than 0.5. It is also the theoretically correct value
for situations where the upstream queue is directly blocked back by the
downstream queue and therefore the queue is “continuous”.
Values of AFTERS greater than 1.0 might be appropriate for situations where the
queues are relatively long distances apart and the demands in the next time
period are liable to increase; e.g. modelling a pre-peak period in a large network.
17.7
Junction-based Summary Statistics
Details of both the queued traffic and the suppressed traffic at individual junctions
are included in the standard simulation node “flow and delay” summary tables, a
“typical” example being given on the next page. The following points may help in
an interpretation of this output:
1)
5120257 / Mar 14
Section 17.docx
‘AVERAGE DELAY’ is the average delay in seconds to pcus during the time
period (LTP) modelled. In the case of turns with permanent queues at the
beginning and/or the end of the time period the delay varies within the time
17-13
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
period but the average time spent in the queue is included within AVERAGE
DELAY. It includes both newly arriving traffic plus queued traffic; thus areas
(3), (4), (5) and (6) for time period (2) in Figure 17.4. (It does not, however,
include any possible delays arising from capacity-restraint curves on the link
(8.4.4); it may help to think of it as “stop-line delay”.)
2) The ‘ASGND FLOW’ is the assigned or demand flow as given by the
assignment while the ‘QUED UP’ flow is the suppressed flow due to queues
upstream from the current node. The difference of these two gives the
‘ARRIVE FLOW’ which reaches the node. ‘QUED HERE’ gives the rate at
which a permanent queue develops, so that subtracting this from the previous
column gives the ‘ACTUAL FLOW’ leaving the node. Note that these are all
given in pcu/h; i.e. they are rates, not absolute figures.
3)
For turns, links and/or nodes with permanently queued pcus present at the
end of the time period the “tail back” at the beginning and end of the time
period is given in brackets on the line following that in which the ‘queuing rate’
is given. Thus in the above example a permanent queue builds up for turn
48-22-23 such that at the end of the time period (here 30 minutes) a tail back
of 47.0 pcus would have formed, with no permanent queue present at the
start of the time period.
4)
The delays totalled for each link and for all turns at the node are “weighted”
averages where the weight for each turn is the arriving flow. The “total
capacity” given for each link is the sum of the individual turn capacities on
links where there is no lane sharing, but is less than their sum when there is
lane sharing in order to avoid any “double counting” of spare capacity in
lanes. For a full discussion of how turn and link capacities are defined please
see 8.9.
5)
Various text characters - +, & etc., - may appear in the output tables to
indicate certain properties of a particular turn or link. For example a ‘*’
following the delay indicates that the cycle times are different at the upstream
node and that therefore any signal co-ordination will have been lost (which
may, in turn, affect the delay calculations).
Similarly at the end of the line:
♦
♦
♦
♦
5120257 / Mar 14
Section 17.docx
* indicates blocking back,
% indicates mid-link capacity restraint,
! indicates weaving and
+ denotes the fact that there are extra queues waiting on in-bound
centroid-connectors.
17-14
SATURN MANUAL (V11.2)
Multiple Time Period Modelling in SATURN
Table 17.1 – Node 22 – Delays and Flows for Each Turn
Ave.
Delay
(secs)
Fixed
Flow
Assgnd
Flow
QUEP
UP
Arrive
Flow
Actual
Flow
Capacity
V/C %
0.0
0.0
1321.4
0.0
500.0
0.0
500.0
5087.8
9.8
0..1
258.6
0.0
248.6
963.8
26.8
758.8
0.2
758.6
0.0
758.6
5163.8
14.7
0.0
180.0
0.0
180.0
0.0
180.0
1200.0
15.0
0.0
0.0
338.0
0.0
338.0
0.0
338.0
5390.0
6.3
71
7.0
0.0
0.0
0.0
0.0
0.0
0.0
556.8
0.0
23
0.0
0.0
517.9
0.0
517.9
0.0
517.9
5400.0
9.6
48
21
5.7
0.0
442.3
183.2
259.1
0.0
259.1
998.7
25.9
G
48
71
10.5
30.0
30.0
12.4
17.6
0.0
17.6
466.6
3.8
G
48
23
319.4
0.0
725.9
300.7
425.2
93.9
331.3
331.3
128.3
G
44.0
From
To
From
To
21
71
0.0
0.0
0.0
0.0
0.0
21
23
0.0
0.0
500.1
0.1
21
48
7.4
0.0
258.7
Totals
21
2.5
0.0
23
48
0.0
23
21
23
Totals
Qued
Here
TPM
All values in pcus-hr
X
From
X
From
(TAILBACKS 0.0 TO 47.0 PCU’S)
Totals
48
195.9
30.0
1198.2
496.2
701.8
93.9
607.9
1595.0
70.4
30.0
2474.9
496.6
1978.4
93.9
1884.5
12159
16.3
From
Overall
(TAILBACKS 0.0 TO 47.0 PCU’S)
5109341 / Dec 12
Section 17.docx
17-15
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
17.8
Network-based Simulation Summary Statistic
SATURN gives total summary statistics from the simulation network which
differentiate between travel which is judged to take place DURING the time period
simulated and that which is judged to take place in LATER time periods due to
over-capacity queuing.
A sample print-out of simulation summary statistics is given in Table 17.2 with
each total divided into, e.g., pcu-kms in the simulated time period, in the next time
period (or, strictly speaking, in all later time periods if it takes a trip more than 1
period to reach its destination) and in total.
The division of pcu hrs between “this” and the “next” time period is based on the
areas illustrated in Figure 17.4. Thus the pcu-hrs in the first time period is made
up of areas (1) and (2) while that in the next time period is made up of that from
queued traffic on that link (areas (3) and (4)) plus that portion of areas (5) and (6)
that is made up of traffic currently queued upstream.
In terms of distance travelled the assumption is made that the queue is “vertical”
such that all vehicles which arrive during a time period (independent of whether or
not they depart) travel the full length of the link during that arrival time period. By
contrast the vehicles queued upstream travel the full distance in later time periods.
Hence in the statistics described below any pcu-kms in later time periods can only
arise from pcus queued upstream.
Note that the “next time period” statistics are, of necessity, only estimates since a
model based on, say, the half hour from 8:00 to 8:30 has no way of knowing what
traffic conditions will be like after 8:30. The estimates of future queues are
controlled by the parameter AFTERS as described in 17.6.2. A more correct set
of figures may be obtained if you are using the PASSQ option, see Section 17.3,
in which case the summary statistics for the PASSQ flows in the next time periods
may be substituted as done by SATSUMA.
Similar tables are produced, in addition to those for total pcu flows, at a more
disaggregate level either by flow (e.g. by user class) and/or capacity index/TfL
traffic borough/zonal grouping. See 11.11.4.
N.B. In order for data disaggregated by capacity index to include delays per
turning movement in addition to pure link-based totals make sure that the
parameter BEAKER is set to .TRUE. in your original network .dat file, otherwise
the indices defined by link do not get extended to the downstream turns. See
5.1.9.
5109341 / Mar 12
Section 17.docx
17-16
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
Table 17.2 - Simulation Network Absolute Totals
Measure
This Time
Period
Next Time
Period
Total
(Units)
TRANSIENT QUEUES
41.5
7.3
48.8
pcu. hrs.
OVER-CAPACITY
QUEUES
114.7
30.0
144.7
pcu. hrs.
(ON LINKS
57.7
29.0
86.7
pcu. hrs.
ON CENTROIDS
57.0
1.1
58.1)
pcu. hrs.
LINK CRUISE TIME
70.6
10.3
80.9
pcu. hrs.
(FREE FLOW
67.4
9.3
76.6
pcu. hrs.
DELAYS
3.3
1.0
4.2)
pcu. hrs.
TOTAL TRAVEL TIME
226.9
47.6
274.5
pcu. hrs.
TRAVEL DISTANCE
2341.2
220.3
2651.5
pcu. kms.
OVERALL
SPEED
10.7
4.6
9.7
kph
501.3
93.9
595.2
litres
AVERAGE
FUEL CONSUMPTION
An explanation of the terms used follows:
♦
TRANSIENT QUEUES: The time spent by vehicles in queues which, in the
case of signals, clear during a single cycle, as opposed to ...
♦
OVER-CAPACITY QUEUES: the extra time spent in queues at over-capacity
junctions waiting for the cycle in which the vehicle exits (subdivided into
queues on the links and, if there are any, queues on centroid connectors due
to blocking back (see 8.5))
♦
LINK CRUISE TIME: Time which would be spent travelling on links,
subdivided into free-flow speeds and the flow-specific extra travel time on
those links with link speed-flow curves (see 8.4.4).
♦
TOTAL TRAVEL TIME: The sum of both link and junction times.
♦
TRAVEL DISTANCE: Vehicle or pcu-kms on simulation links.
♦
OVERALL AVERAGE SPEED: Defined by (total distance) / (total time)
♦
FUEL CONSUMPTION: As estimated by time, distance and the number of
primary and secondary stops (see 15.32).
See Section 17.11 for a more detailed explanation of the formulae used to
calculate these statistics.
5109341 / Mar 12
Section 17.docx
17-17
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
17.9
Combined Simulation and Buffer Total Statistics
17.9.1
Simulation Network Totals
The absolute simulation network totals described in 17.8 may also be combined
with absolute totals from a buffer network to give total statistics for the whole
network. A sample print out is given in Table 17.3.
Table 17.3 - Simulation (S), Buffer (B) and Buffer Centroid Connectors (BCC)
Total Travel Statistics
Absolute Totals:
This Time Period
Next Time Period
Total
Transient Queues
(pcu-hrs)
(pcu-hrs)
(pcu-hrs)
(S)
41.5
7.3
48.8
(B)
3.3
0.3
3.6
(T)
44.8
7.6
552.4
Over-Capacity Queues
(pcu-hrs)
(pcu-hrs)
(pcu-hrs)
(S)
114.7
30.0
144.7
(B)
256.6
234.7
491.3
(T)
371.3
264.7
636.1
(S)
70.6
10.3
(B)
98.1
98.1
(BCC)
35.4
35.4
(T)
204.1
10.3
214.4
Total Travel Time
(pcu-hrs)
(pcu-hrs)
(pcu-hrs)
(S)
226.9
47.6
274.5
(B)
358.0
235.0
593.0
(BCC)
35.4
Link Cruise Time
80.9
35.4
(T)
620.3
282.6
902.9
Travel Distance
(pcu-kms)
(pcu-kms)
(pcu-kms)
(S)
2431.2
220.3
2651.5
(B)
2462.3
2462.3
(BCC)
490.0
490.0
(T)
5383.5
220.3
5603.8
Average Speed
(km/h)
(km/h)
(km/h)
(S)
10.7
4.6
9.7
(B)
4.2
4.2
(BCC)
13.8
13.8
(T)
8.7
6.2
Here absolute totals, e.g. pcu-hrs, are subdivided by link type - simulation (S)
which here includes queues on simulation centroid connectors, buffer links (B)
and buffer centroid connectors (BCC) - and by this time period / later time periods.
Thus the simulation-based totals are not as disaggregate as those in Table 17.2
but are similar to those defined in the buffer networks.
5109341 / Mar 12
Section 17.docx
17-18
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
In the buffer network link times are divided into three components to provide
comparability to simulation statistics:
♦
free flow = cruise times (t o )
♦
“transient queues” (AVn or ACn if V>C)
♦
over-capacity queues (B*(V-C)/C)
where the equations refer to equations (5.1) in Section 5.4.
In the buffer network pcu hrs in later time periods only result from those buffer
links where the demand (= actual) flow exceeds the capacity. Thus, with
reference to Figure 17.4, the transient queues in this/next time period correspond
to areas (1) and (4) respectively while the over-capacity queues similarly refer to
areas (2) and (3). Buffer distance is flow times distance. Again assuming a
vertical queue neither link cruise time nor distance can spill over into later time
periods; hence certain “next time period” entries in Table 17.3 are deliberately left
blank rather than being entered as zero.
The totals associated with “penalty times” refer to those “time” penalties as input
within the 44444 network data records (6.7) factored by the relevant flows on
those links or turns and converted into pcu-hrs. As with the previous measures
they are disaggregated by link type and by within/next time periods.
The toll totals are similar to the penalties although the tolls may be set either
within the 44444 records or via KNOBS inputs; both are included here.
Finally “total trips loaded” refers to the sum of all outbound trips which depart from
origin zones within that time period, in effect the sum of all trips in the (demand)
trip matrix. However it excludes any trips associated with unconnected o-d pairs
(e.g., where a zone has only in-bound centroid connectors in the network but has
out-bound trips in the trip matrix) and all intra-zonal trips. It is also the “demand”
total as opposed to the “actual” total which might be calculated as the sum of all
actual flows on in-bound centroid connectors to destination zones. Equally it does
not include any flows assigned under PASSQ. Finally under elastic assignment it
represents the final trips which are assigned to the road network and should
therefore be identical with the total number of trips in the output road trip matrix.
The data given in Table 17.3 are, in general terms, the “best” statistics to use for
overall network performance since they include all network components - buffer,
simulation, centroid connector - at the equivalent levels. They supersede - and
should be used in preference to - the “assignment network statistics” available
within SATLOOK which do not differentiate sufficiently clearly between demand
and actual totals, i.e. totals within this and later time periods.
17.9.2
Averaged Statistics over Multiple Loops
Aggregate data such as that in Table 17.3 is obtained from the link times, flows
etc. calculated on the final iteration of the assignment-simulation loops within
SATALL. They should therefore represent the best available information in the
sense of being most highly converged. However, despite this, if oscillations are
seen to occur in the data from loop to loop it could be argued that more reliable
5109341 / Mar 12
Section 17.docx
17-19
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
results which would reduce the “noise” inherent in imperfectly converged solutions
could be obtained by averaging the data over, say, the final 4 loops.
This, post version 10.3, may be achieved as an option within SATLOOK (either on
its own or accessed from within P1X) through option 3 which allows both
averaging over the final n (user set) loops and/or printing of data (in the form of
Table 10.3) from a particular loop, not necessarily the final loop. The necessary
data from each loop (up to a certain maximum) is accumulated within SATALL
and included within the output .ufs files; see 9.7.
It has to be said that I have certain misgivings about this practice. In particular I
cannot see any advantage to using averaging data while the numbers being
averaged are consistently changing in one direction. For example, if the total
travel times on the final 4 loops were 102.0, 101.0, 100.5 and 100.0 then I would
much prefer to take 100.0 as my “best” answer than the average of the 4, 100.9.
On the other hand if the final 4 numbers were, in order, 101.0, 100.0, 102.0 and
100.5 then I can see the case for using 100.9. It’s up to the users to make up
their own minds! Printing the data from several final iterations may certainly help
you decide.
17.10
Delay-based Arrays in .UFS Files: Definitions
There are a large number of “Dirck Access” arrays stored on .ufs files which refer
to delays and/or travel times in different contexts. This section attempts to explain
the precise definitions used in each case.
The following table lists the DA code plus explanation. Those denoted * are
defined only for simulation links and those with a † are for simulation turns; all
others refer to assignment links which include both simulation links and turns as
subsets.
5109341 / Mar 12
Section 17.docx
363*
-
TIM: Simulation link (cruise) time, either the free-flow time on links
without speed-flow curves or, post assignment, the flow-dependent
time on links with speed flow (6.4.12). (To obtain the "free flow" times
on simulation links use array 1803.)
1513*
-
DELRD: The average turn delay per vehicle (pcu) on a simulation link
weighted by turning flows plus any delays on the link from link
capacity constraints. The turn delays are based on those in 1633.
N.B. Both transient and queuing delays from V>C are included.
1543*
-
TLQT: The total pcu-hrs of delay per link within the current time
period, e.g., areas (1) and (2) in fig. 17.3 for an initial time period on
areas (3) to (6) for later time periods, plus any delays on simulation
links with speed-flow curves.
1633†
-
DEL: The turn delay per simulation turn including both transient and
over-capacity queuing effects but excluding any delays associated
with link capacity-restraint curves.
1653†
-
DEL_TR: The “transient” delay per simulation turn; i.e. excluding any
delays associated with over-capacity queuing.
1803
-
FTIME: The “free-flow” time on all links within the assignment
network. For simulation turns (which have zero distance by definition)
this represents the delay for arrival flows approaching zero but with
17-20
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
all other flows (opposing or lane sharing) at their current value; it
therefore represents the minimum possible values for total turn delays
in, say, 1633 or 4003 and it is definitely considered as a delay. On
the other hand for all other assignment links which have a distance
(i.e., including simulation links) 1803 represents the cruise time at the
maximum link speed and in these cases should not be considered as
a “delay” component.
17.11
1853
-
DATC: The delay at capacity, i.e. the difference in travel times
between flow=capacity and flow=zero.
This may be used to
“parameterise” the flow-delay equations: see ??
4003
-
Assignment Time: The times for each assignment link as calculated
during the assignment process as given by equations (8.5) (or, strictly
speaking, their more complex forms (8.11)).
4013
-
Simulation Time: As 4003 but with the times for simulation links or
turns updated according to the simulation which follows the
assignment; i.e. using the data in 363 and 1633.
4023*
-
Simulation Time by link: Identical to 363.
Formulae for Calculating Totals
This section gives the definition of each component of, e.g., total pcu-hrs as listed
in various standard output tables and gives equations by which these numbers
may be calculated externally by users using, e.g., spreadsheets. It is divided into
three sub-sections to cover (a) simulation networks, (b) buffer networks and (c)
bus-only lanes within simulation networks.
WARNING: Whilst the formulae described below provide the basic calculations for
reproducing the simulation statistics outside SATURN, we recommend that
SATURN should always be used to estimate them. This is particularly important
for more complex examples involving networks using the PASSQ option.
17.11.1
Simulation Network Totals
The table below lists, in symbolic form, the absolute totals statistics within the
simulation network as illustrated in numerical form in Table 17.2.
TIME PERIOD:
THIS
NEXT
TOTAL
Transient Queues (pcu/hrs)
TQ.1
TQ.2
TQ.3
Over-Capacity Queues (pcu/hrs):
CQ.1
CQ.2
CQ.3.
On Links
CQL.1
CQL.2
CQL.3
On Centroids
CQC.1
CQC.2
CQC.3
LT.1
LT.2
LT.3
(Free Flow)
LTF.1
LTF.2
LTF.3
(Delays)
LTD.1
LTD.2
LTD.3
Total Travel Time (pcu-hrs)
T.1
T.2
T.3
Travel Distance (pcu-kms)
D.1
D.2
D.3
Stops (Primary)
PS.1
PS.2
PS.3
Link Cruise Time (pcu-hrs):
5109341 / Mar 12
Section 17.docx
17-21
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
TIME PERIOD:
THIS
NEXT
TOTAL
Stops (Secondary)
SS.1
SS.2
SS.3
Fuel Consumption (litres)
FC.1
FC.2
FC.3
The totals above may be calculated from the formulae given below, thus rendering
all output statistics totally transparent to the users. It also makes it possible for
users to calculate statistics for, e.g., a subset of links or for a particular user class.
Elements such as X1653, X4513 refer to the data contained in DA arrays 1653,
4513 etc, parameters such as LTP and AFTERS refer to standard namelist
parameters described in 6.3 and the numerical values such as 3600 and 60 are
necessary to convert, e.g. seconds into hours. Division by 2 is sometimes used
(e.g., in CQL.1) to calculate an average queue which is half the final queue.
WARNING: The formulae given implicitly assume that multiple time periods and
PASSQ are not being used such that the queues at the start of the time period
are zero. In particular this affects the queuing statistics CQ.1 etc. and other
formulae, e.g., fuel consumption, that make use of them. In principle it would be
possible to write down the correct formulae but it would be complicated!
In addition they do not include any contribution from buses on reserved lanes
which must be added some (not all) of these categories. A separate set of
equations is given in 17.11.3.
To calculate any of the quantities below it is necessary to first read the required
DA arrays into, say, SATDB or an equivalent spread sheet, calculate new data
columns following the formulae given and then sum individual link values over a
certain subset. Thus to calculate TQ.1, transient queues in “this” time period, first
read in DA arrays 1643 (turn capacity), 1653 (transient delay per pcu) and 4513
(actual flows), perform the calculation indicated and sum over all simulation turns.
Note that in certain cases not all simulation turns or links should be included but
an extra condition needs to be applied; e.g. that there is a permanent queue
greater than zero on that link or turn, as with CQL.2. The select rules are given on
the far right.
In addition certain sums, e.g. CQL.2, are best calculated via certain “intermediate”
variables. Thus Q represents the number of queued pcus at the end of a time
period.
Quantity
5109341 / Mar 12
Section 17.docx
Formula
TQ.1
X1653/3600 * min( X4513, X1643 ) * LTP/60
TQ.2
TQ.3 - TQ.1
TQ.3
X1653/3600 * X4503 * LTP/60
CQ.1
CQL.1 + CQC.1
CQ.2
CQL.2 + CQC.2
CQ.3
CQL.3 + CQC.3
CQL.1
X1483 * (LTP/60) /2
Sum Over
Sim Turns
Sim Turns
Sim Links
17-22
Select
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
Quantity
CQL.2
Formula
V * Q / X1663
Sum Over
Select
Sim Turns
Q>0
2
Sim Links
X1393>0
2
Sim Links
X1393 >0
Q = (X4513 - X1643) * LTP/60
V = 0.5*Q + AFTERS*(X4503 - X4513)*LTP/60
CQL.3
CQL.1 + CQL.2
CQC.1
(X1403-X1393) * {LTP/60} / 2
CQC.2
{(X1403-X1393) * LTP/60} / 2(X1393 * X1673)
CQC.3
CQC.1 + CQC.2
LT.1
X4013 * X4513 * (LTP/60) / 3600
LT.2
LT.3 - LT.2
LT.3
X4013 * X4503 * (LTP/60) / 3600
Sim Links
LTF.1
X1803 * X4513 * (LTP/60) / 3600
Sim Links
LTF.2
LTF.3 - LTF.1
LTF.3
X1803 * X4503 * (LTP/60) / 3600
LTD.1
LT.1 - LTF.1
LTD.2
LT.2 - LTF.2
LTD.3
LT.3 - LTF.3
T.1
TQ.1 + CQ.1 + LT.1
T.2
TQ.2 + CQ.2 + LT.3
T.3
TQ.3 + CQ.3 + LT.3
D.1
X1893 * X4513 * (LTP/60) / 1000
D.2
D.3 - D.2
D.3
X1893 * X4503 * (LTP/60) / 1000
KPH.1
D.1 / T.1
KPH.2
D.2 / T.2
KPH.3
D.3 / T.3
PS.1
X1523
Sim Turns
PS.2
X1523 * (X4503 - X4513) / X4513
Sim Turns
PS.3
PS.1 + PS.2
SS.1
X1533
Sim Turns
SS.2
X1533 * Q / (X1663 * LTP/60)
Sim Turns
Q = max [ {(X4513 - X1643) * LTP/60}, 0.0]
V = 0.5*Q + AFTERS*(X4503 - X4513)*LTP/60
5109341 / Mar 12
Section 17.docx
17-23
Sim Links
Sim Links
Sim Links
Sim Links
Q>0
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
Quantity
17.11.2
Formula
Sum Over
SS.3
SS.1 + SS.2
FC.1
FLPK * D.1 + FLPH * (TQ.1 + CQ.1) + FLPPS *
PS.1 + FLPSS * SS.1
FC.2
FLPK * D.2 + FLPH * (TQ.2 + CQ.2) + FLPPS *
PS.2 + FLPSS * SS.2
FC.3
FC.1 + FC.2
Select
Formulae for Calculating Buffer Totals
The formulae in 17.11.1 apply only to quantities within the simulation network; a
more limited set of statistics apply to buffer network summations, for example
“Transient Queues (B)” as illustrated in numerical form in Table 17.9.
We therefore provide here the equivalent formulae for CQB.1 and CQB.2 (overcapacity buffer queues within the time period and within the next time period
respectively). Note that the summations must be over selected links: (a) which
are buffer and (b) where V > C (X4503 > X1833).
CQB.1 =
0.5 ∗ ( X 4503 − X 1833) ∗ ( LTP / 60 )
2
CQB.2 =
0.5 ∗ ( X 4503 − X 1833) ∗ ( LTP / 60 )  / X 1833
2
Thus, referring to Figure 17.3, CQB.1 is represented by triangle 2 and is equal to
one half the height ((V-C) in pcu/hr multiplied by LTP in hours) times the base
(equal LTP in hours). Hence the units are pcu-hrs.
Similarly CQB.2 is represented by triangle 3 with the same height as above but
with base equal to the queue at the end of the time period divided by its capacity
(X1833).
To obtain the equivalent summations for transient queues (TQB.1 and TQB.2) it is
easiest to first calculate (for the same selected links as above) the transient queue
(in seconds) per (over capacity) buffer link I as the difference between the total
delay (equals total time 4003 less free flow time 1803) and the over-capacity delay
component:
TQ
=
X 4003 − X 1803 − 0.5 ∗ ( X 4503 / X 1833) − 1.0  ∗ ( LTP / 60 ) ∗ 3600
i
Then, sum the product of TQ i and the length of the over-capacity queue at the end
of the time period LTP over the same over-capacity buffer links as above to
obtain:
TQB.2 =∑ TQi ∗ ( X 4503 − X 1833) ∗ ( LTP / 60 ) / 3600
i
N.B. Division by 3600 converts from pcu-sec to pcu-hr.
and: TQB.1=  X 4003 ∗ X 4503 ∗ ( LTP / 60 )  / 3600 − TQB.2 − CQB.1 − CQB.2
5109341 / Mar 12
Section 17.docx
17-24
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
Where the first term above (which gives the total vehicle delay in pcu-hr) must be
summed over all buffer links, independent of whether or not they are over
capacity. Again division by 3600 is necessary to convert pcu-sec to pcu-hr.
17.11.3
Totals for Reserved Bus-only lanes
Buses which are allowed to bus exclusive bus-only lanes within the simulation
network are not explicitly included in the formulae listed in Section 17.11 although
they are included within certain (not all) elements in, e.g., Table 17.3.
The following set of equations indicate, using the notation at the start of Section
17.11.1, which elements include bus-only lanes and the equations necessary to
calculate the bus-only contribution. These should be calculated separately before
being added to the relevant simulation totals.
TQ.1 / TQ.3
X1803 * X2033 / 3600
Sim turns
D.1 / D.3
X1893 * X2033 / 1000
Sim links
LT.1 / LT.3
X4013 * X2093 / 3600
Sim links
LTF.1 /LTF.3
X1803 * X2033 / 3600
Sim links
Note the bus lane modeling assumes no difference between actual and demand
(i.e., scheduled) bus flows so that all the “next time period” totals TQ.2 etc. are
zero. And, in addition, there are no bus lanes coded within the buffer network.
5109341 / Mar 12
Section 17.docx
17-25
SATURN MANUAL (V11.3)
Multiple Time Period Modelling in SATURN
17.12
Version Control
JOB NUMBER: 5120257
Revision
Purpose / Description
1
Re-formatted (Final to DVV)
3
Upgrade to V2 Templates
Originated
Checked
Reviewed
Authorised
Date
TF / BG
NS
IW
IW
06/05/06
IW
22/06/06
3.2
Web release – Sept 06
DVV
NP
IW
IW
08/09/06
3.3
Web release – Jan 07
DVV
NP
IW
IW
04/01/07
3.4
SATURN v10.7 Release
DVV
NP
IW
IW
12/03/07
v10.7.10 Release
DVV
NP
IW
IW
24/04/07
3.5
Web release – Jan 07
DVV
NP
IW
IW
19/07/07
3.6
SATURN v10.8 Release
DVV
NP
IW
IW
09/02/08
3.7
Web release – Jul 08
DVV
NP
IW
IW
07/07/08
3.8
Web release – Dec 08
DVV
NP
IW
IW
12/12/08
3.8.21
Web release – Feb 09
DVV
NP
IW
IW
16/02/09
3.8.22
Web release – Jun 09
DVV
NP
IW
IW
16/06/09
10.9.10
SATURN v10.9 Release
DVV
DG
IW
IW
04/09/09
10.9.12
SATURN v10.9 Release (Full)
DVV
DG
IW
IW
22/10/09
10.9.17
Web release – Jun 10
DVV
DG
IW
IW
22/06/10
10.9.22
Web release – Dec 10
DVV
AG
IW
IW
06/12/10
10.9.24
SATURN v10.9 Release (Full)
DVV
AG
IW
IW
06/05/11
11.1.09
SATURN v11.1 Release (Full)
DVV
AG
IW
IW
31/03/12
11.2.01
SATURN v11.2 Beta Release
DVV
JS
IW
IW
07/12/12
11.2.05
SATURN v11.2 Release (Full)
DVV
JS
IW
IW
17/03/13
11.3.03
SATURN v11.3 Release
DVV
EN
IW
IW
28/03/14
3.4.1
5109341 / Mar 12
Section 17.docx
DOCUMENT REF: Section 17.doc
17-26