SATURN MANUAL (V10.

9)

Supplementary Programs

12. Supplementary Programs

12.1 Network Cordoning (SATCH)

The function of the network and/or matrix cordoning program SATCH is to

produce a sub-network and/or a sub-matrix of trips corresponding to a cordoned
area defined within a larger network.

12.1.1 Running SATCH

Figure 12.1 below indicates schematically how a cordon run may be incorporated
within a run of a larger network. Here the larger network is denoted by ‘net’ and
its trip matrix, by ‘trips’, while the sub-area or cordoned network and trip matrix are
‘cornet’ and ‘cormat’ respectively. File extensions follow standard conventions.

Thus the first step in the process is to run the full SATURN model for the ‘full’
network until convergence is reached in the normal way. If you wish to cordon a
sub-matrix the parameter SAVEIT should be T in the original network data file -
see note (11) in 12.1.4. SATCH then re-creates all routes used in the final
assignment and notes which trips pass through the cordon points defined in an
input file (denoted cordon.DAT in 12.1). These trips are then aggregated up to
form a cordoned trip matrix in which the zones correspond to either:

 ‘internal’ zones inside the cordon, or

 ‘cordon zones’ corresponding to exit and/or entry points about the cordoned
area

At the same time the program condenses the original network data file net.DAT so
that only those records corresponding to links ‘inside’ the cordon are retained.
The cordoned network file - denoted ‘cordon.DAT’ in 12.1 - may then be fed into
the network build program SATNET (either directly or, commonly, with additional
editing by the user), following which the iterative simulation/assignment loop can
be invoked using the cordoned trip matrix ‘cormat.UFM’.

Note that the (compulsory) control file, cordon.dat in Figure 12.1, is best prepared
initially using the mouse-based options in P1X in order to guarantee that the
cordon is ‘watertight’; see 11.13. However it may be necessary to ‘edit’ the
resulting file in order to select some of the other options described below. Indeed
most of the functions within SATCH may also be carried out within P1X; see
12.1.5.

5101396 / May11 12-1

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

Figure 12.1 - Use of SATCH

12.1.2 SATCH Files

Channel Number Remarks
1 An input SATURN UFS file containing data from a converged
run of the ‘full’ network. (Mandatory)
3 Input UFM trip matrix for the full network. (Optional - DOMAT
or PRINT= T)
4 Output UFM trip matrix for the cordoned network (Optional -
DOMAT = T)
5 A DAT file containing the control parameters; see 12.1.3.
(Mandatory)
6 An output LPC line printer file. (Mandatory)
7 Output KP file containing the data condensed from the file on
channel 8 for the cordoned network for input to SATNET.
(Optional - DONET = T)
8 Input DAT file containing the data from the original network as
input to SATNET. (Optional - DONET = T)

5101396 / May11 12-2

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

Channel Number Remarks

13 SATCH.HLP (Optional)
15/14 Terminal (output only) (Mandatory - unless MODET = 0)
24 $INCLUDE files called from the network .dat file (Optional).
UFC cost file for file 1 (optional - DOMAT=T)

12.1.3 SATCH CONTROL DATA INPUT

This input file (which is mandatory) contains all the “control” information required
by the program in addition to the network and matrix information which is input via
the network .ufs and matrix .ufm files.

RECORD 1 - SATCH NAMELIST OPTIONS (&PARAM) (MANDATORY)

Option Type Default Interpretation
MIDDLE Integer 0 A node number which is inside the cordon (in order
to distinguish ‘inside’ from ‘outside)
NOMAD Integer 1 The ‘matrix sub-level’ to be used if working with
MUC assignment if ALLUC = F ; see 12.1.6
MODET Integer 1 If ne 0 diagnostic messages are output to the
terminal
DEMAND Logical FALSE If TRUE any output trip matrix is in terms of ‘demand
flows’ (as is the input matrix); if FALSE the output
matrix is in ‘actual flows’. See 12.1.9.
DONET Logical TRUE If TRUE a network DAT file is output to channel 7
using data read from channel 8.
DOMAT Logical TRUE If TRUE a UFM trip matrix file for cordoned network
is output to channel 4.
PRINT Logical TRUE If TRUE print the cordoned trip matrix to the line
printer.
AZONE Logical FALSE If TRUE the zone numbers at the cordon points are
set equal to the ‘outer’ nodes which defined the
cordon link; see note 7, 12.1.4
SPINE Logical FALSE If TRUE a matrix of trips entering or leaving a ‘spine’
of nodes from NODES to NODEF is built.
NODES Integer 0 The ‘start’ node which defines a set of ‘spine’ links
and…..
NODEF Integer 0 The ‘finish’ node in a ‘spine’ – see note 6, 12.1.4
BULL Logical FALSE If TRUE a matrix of trips which turn at node MIDDLE
is built

5101396 / May11 12-3

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

Option Type Default Interpretation

ALLUC Logical TRUE If TRUE under multiple user classes a cordoned
matrix is produced separately for every user class. If
FALSE NOMAD defines a single user class. See
12.1.6
FURNES Logical FALSE If TRUE the output trip matrix is ‘furnessed’ to match
the assigned flows ; see 12.1.8
INTRAS Logical FALSE If TRUE intrazonal trips from the trip matrix are
included in the output trip matrix ; see note 14 ,
12.1.4

RECORDS 2: CORDON LINKS (OPTIONAL - SPINE AND BULL = F)

A separate record must be included for each link in the cordon surrounding the
inner network, format as follows:
Cols. 1-5 The A-node of the link
6-10 The B-node of the link

Notes:

a) The link can be either one-way or two-way; if two-way, it only needs to be

defined once.

b) Either node may be defined as the A-node, but the program will later
redefine the A-node as being the node which is ‘inside’ the cordon and the
B-node as being on the ‘outside’.

c) The links are those that are ‘cut’ by the cordon as opposed to a continuous
set of links that are themselves the cordon.

d) If DUTCH is TRUE in the input SATURN UF file then the nodes are defined
in columns 1-10 and 11-20.

e) Centroid connectors are not valid cordon links and are ignored by the
program in defining the cordoned network.

f) Either simulation or buffer links are permitted as cordon links.

RECORD 3 (MANDATORY) (OPTIONAL - AS 2)

99999 in columns 1-5 to signify the end of the cordon data records.

RECORD 4 MATRIX TITLE (OPTIONAL - DOMAT = T)

A title for the cordoned matrix in columns 1 to 72.

END OF THE CONTROL FILE INPUT

5101396 / May11 12-4

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

An example of a control file is given below:

&PARAM
MIDDLE=43,
&END
20 21
47 48
47 50
50 51
31 52
54 32
56 33
57 35
43 42
42 41
41 40
13 12
99999
NEW MATRIX TITLE

12.1.4 General Comments

1) In order to identify that section of the full network which is within the cordoned
area the program builds a ‘tree’ out from the node MIDDLE but not going
beyond any of the cordon links. In other words it tries to reach as much of the
network as it can starting at MIDDLE but without going through any cordon
links. At this stage network nodes and links will be either ‘inside’ or ‘outside’
the cordon. By definition the links forming the cordon are ‘inside’.

Note that in building the tree the program only uses ‘real’ links; i.e., centroid
connectors are excluded. Hence in defining the cordon the user need not
define any centroid connectors which apparently cross the cordon.

2) The process fails if there are any ‘holes’ in the cordon by which the tree can
escape from the cordon and thereby reach all (or most) nodes in the network.
This is indicated by the cordoned network being much bigger than expected.
Holes can be detected by analysing the printed set of ‘back-nodes’. If
therefore you start with a node which should definitely be outside the cordon
by tracing its path back to MIDDLE by looking up successive back-nodes it
should become obvious where that path crossed the desired cordon.

The tree is printed automatically if ALL nodes appear to be inside the cordon,
since in that case it is obvious that there must be a hole.

3) The tree is built using both simulation and buffer links (if both exist or else
clearly just the one type). The cordoned network includes both simulation and
buffer components as appropriate. It is, however, possible to cordon a
combined simulation/buffer network such that the cordoned network is either
all buffer or all simulation.

5101396 / May11 12-5

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

4) A zone in the full network will be ‘inside’ the cordon network if at least one of
its connected ‘real’ nodes can be reached from MIDDLE; it might therefore
‘straddle’ the cordon and have outside connections as well, but these will be
excluded.

5) In defining cordon links the A - and B-node may be in either order. However
once the tree from MIDDLE has been built the program re-defines their A and
B numbers so that the A-node is inside and the B-node outside. The cordon
zone is therefore connected to the B-node.

6) SPINE and BULL represent alternative and simpler methods to define

cordons than a full set of cut links. Thus under BULL it is assumed that the
cordon links are all those entering and/or leaving the node MIDDLE. Hence
the trip matrix created corresponds to turning movements at MIDDLE and so
this option is used to obtain turning flows at buffer nodes. Since under
SATURN 9 turning flows at buffer nodes are calculated directly (See 15.36)
the BULL option is largely redundant.

The SPINE option is used to isolate all trips entering or leaving a stretch of
road such as A-B-C-D-E-F in the diagram below. Here the line indicates
where the cordon is drawn so that nodes Z, H, J etc. all represent external
zones outside the cordon and a trip in the cordoned matrix from, say, J to S,
corresponds to a trip which enters the road at B and leaves at E. Information
of this nature might be useful if, say, A-F were a motorway.

7) Under the normal option it would be necessary to set MIDDLE to, say, D and
to specify a full set of cordon links Z-A, H-A, etc. However under the SPINE
option it is only necessary to specify the two nodes at either end of the ‘spine’,
in this case nodes A and F (which are set as NODES and NODEF
interchangeably). The program then uses the node co-ordinates in order to
‘interpolate’ nodes B, C, D and E as the most direct route between A and F;
see Section 15.18.

Under both options the parameters DOMAT and PRINT are automatically set
to TRUE since the only reason for using these options is to look at the trips,

5101396 / May11 12-6

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

and DONET is automatically set to FALSE since the network itself would be of
little interest.

8) New cordon zones are created at the outer end of each cordon link. If the
logical parameter AZONE is FALSE then their numbers start at the first
available multiple of 100 plus 1 above the highest zone number in the full
network. Thus if the full network had zones up to number 437 the cordon
zones would be numbered 501, 502, ...

Alternatively if AZONE is TRUE then the cordon point zone numbers are set
equal to the outer cordon node (the ‘B-node’ under note 5 above). This option
is very useful if you only wish to ‘look at’ the cordoned trip matrix, in which
case referring to a cordon point as, say, zone 21 if it was at node 21 is more
informative than referring to it as zone 501. However this option will create
severe problems if you wish to cordon both a matrix and a network to run
together in SATURN since the network will assume that the zones are sorted
in order of increasing zone number in the trip matrix whereas under AZONE
they need not be; hence cordon trips may enter/leave at the ‘wrong’ points
when assigned.

9) Having first identified all nodes which are inside the cordon, and if DONET is
TRUE, the program creates the cordoned network file by reading through the
network data records input on channel 8 and copies to the output data file on
channel 7:

(i) any ‘general’ records, e.g. the &PARAM cards;

(ii) Any records referring to internal nodes and/or links.

Users may therefore need to further edit the data file before input to SATNET.
In particular they will probably wish to change the network title (which is
copied verbatim by SATCH).

10) The network reduction ‘logic’ is not 100% perfect. For example, if you cordon
a joint simulation/buffer network so as to totally exclude the simulation
network you will (probably) get output records which include: 11111 99999
which would imply that simulation data is included (the 11111 card) but then
no data appears. SATNET might - with some justification - take umbrage at
this apparent thoughtlessness on your part.

11) Trips which follow routes that criss-cross in and out of the cordoned network
will appear as multiple trips in the cordoned matrix. For example, the trips
from S to T below would be counted as both S-A (internal zone to cordon
point), B-C (cordon to cordon) and D-T (cordon to internal zone) in the
cordoned matrix.

5101396 / May11 12-7

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

12) All routes used in the assignment are re-created and traced and the trips
added to the trip matrix appropriately factored. Thus, if the assignment
assigns 12% of the entire trip matrix to the free-flow routes, only 12% of Tij
would be included along these routes in the cordoned matrix.

Note that the original network file must have set the parameter SAVEIT to
.TRUE. so that a network UFC file would have been created so that SATCH
can re-create the trees built at each stage of the assignment.

13) Note that the ascii control file specifying, inter alia, the links in the cordon may
be conveniently created using mouse based options within P1X and that it is
possible using this facility to check visually for ‘holes’ in the cordon. See
Section 11.13.

14) If the input network .dat file contains $INCLUDE records referencing other
files the data from these files will be included as necessary in the output
cordoned .dat file but all within the file, not as externally referenced
$INCLUDE files.

15) Any intra-zonal cells in the “full” trip matrix are automatically included as intra-
zonals in the “cordoned” trip matrix if the parameter INTRAS = T. Clearly this
only applies to internal zones; external zones at cordon points may, in
principle, have intra-zonals but only if, in the original full network, paths would
have entered and left by the same link (thereby, in effect, executing a U-turn).

16) Bus routes in the “full” network are truncated such that only that portion of the
route which is within the cordon is retained. If FOZZY = T (so that
interpolation between non-adjacent nodes is permitted) then only those nodes
that are included within the full network definitions are included within the
cordoned route definitions (with the exception that any entry and exit points at
cordons are automatically included).

5101396 / May11 12-8

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

Note, however, that if a route exits the cordoned network and later on re-enters
the cordon only the first segment of the route is included. (Unlike routes used by
the assigned trip matrix; see note 10 above.

12.1.5 Running SATCH within PIX

SATCH is basically a “batch” program; however most of the functions available

within SATCH are also available within PIX, in addition to the ability to define a
cordon as mentioned in note 12, Section 12.1.4.

Thus having defined a cordon in PIX options exist (see 11.13) to:

 Produce an output cordon.dat network file as under the DONET option within
SATCH.

 Produce an output cordoned .ufm trip matrix, analogous to DOMAT (but

probably with smaller limits on the maximum number of output zones).

12.1.6 Multiple User Classes within SATCH

With SATURN 10.1 the parameter ALLUC = T (in conjunction with DOMAT = T)
outputs a stacked .ufm trip matrix with one level per user class.

The number of levels is fixed independently of how the original trip matrix defined
trips by user class. For example, the original might have been a single-level
square matrix with user class matrices defined as fractions of the basic matrix
within the 88888 records (see 6.11). However, since the routes used by each
user class will (presumably) be different, so too will their cordoned matrices be
different; hence it is no longer possible to express them as fractions of a single
cordoned matrix.

Furthermore, if an original user class were defined as a fraction of a full matrix

then that fraction is included directly in the cordoned matrix. Thus if the original
full matrix contained 10 trips in an ij cell with 30% allocated to user class 2 then
the cordoned matrix for class 2 would contain 3 trips in the appropriate cordoned
cell (assuming of course that those trips went through the cordon).

This has further implications for the way in which the 88888 records are defined in
the cordoned network.dat file since each user class must now be allocated to its
numerically equal level in the stacked matrix with a fraction of 1.00. Thus, in the
example above of user class 2 being 30% of a full matrix, in the full network.dat
file it might have been assigned to level 1 with a fraction 0.30; in the cordoned .dat
file the equivalent values would be 2 and 1.00.

Some caution on the part of users is required here since the changes to the 88888
records may or may not be carried out automatically depending on whether or not
the network and matrix are cordoned at the same time. Thus in SATCH if DOMAT
= T, DONET = T and ALLUC = T then the program will "know" to make the

5101396 / May11 12-9

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

changes in the 88888 records; otherwise, and this includes all cordon operation in
P1X, it will not know whether you want those changes done.

As a final point of confusion note that if ALLUC = F and only a single user class
matrix as set by NOMAD is output then the class specific factor is not applied and
the 888 records do not need amending. Nonetheless it would then be up to the
user to produce a full set of class-specific cordoned trip matrices, to add/stack
them together as desired and to set the 888 records accordingly. A potential mine
field which the use of ALLUC is designed to deal with. Its use is therefore highly
recommended.

Pre-Selecting Individual User Classes on the Command Line

Post 10.9.24 it is possible to over-ride the choice of the user classes matrices to
be output by setting a single user class on the command line (12.1.10); e.g.,

SATCH net control ftij ctij NOMAD 2

requests that the only a single square cordoned matrix for user class 2 be output,
independent of which values have been set for ALLUC and NOMAD within
control.dat. In addition the filename of the output matrix will have 2 appended to it;
e.g., the output matrix will be ctij2.ufm, not ctij.ufm.

In addition, if NOMAD > 1, then no output network .dat file is created on the
assumption that the option is being used within SATCH_MC so that an output
network .dat file is only created once when SATCH is called with NOMAD = 1.

The main reason for adding this option is so that several runs of SATCH may run
simultaneously using different processors, one per user class, as controlled by the
batch file SATCH_MC. See 12.1.10 and 15.53.2.6. Since each run produces a
separate square matrix ctij1.ufm, ctij2.ufm, … these may be stacked into a single
MUC matrix at the end.

12.1.7 Factored Trip Matrices (E.g., GONZO)

If the input trip matrix has been factored prior to assignment due to either: (a)
GONZO ne 1.0 or (b) a user-class specific factor having been set under the 88888
network .dat file records, then the output trip matrix will implicitly include these
factors.

For example, if GONZO = 1.5 and the total origin trips in the input trip matrix from
a zone inside the cordon equal 100 then the actual flow assigned from that origin
will be 150. Thus in the cordoned matrix the origin flows for that zone will be 150,
not 100. It follows that, in the above example, GONZO will need to be set equal to
1.0 in the cordoned network .dat file, otherwise the assigned flows from that origin
will be 150 x 1.5 = 225 rather than 150. Thus SATCH (post 10.6) will
automatically re-set GONZO to 1.0 in the output network (.kp) file (although it is
worth the user checking that has been correctly done).

5101396 / May11 12-10

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

Similarly any further user-class specific factors implied by the 88888 records will
also be re-set to 1.0 in the output file and the factor included in the appropriate
level of the stacked cordoned matrix. See also 12.1.6 above. This problem occurs
frequently if the input trip matrix (level) represents vehicles/hr and the 88888
factor converts to pcus/hr.

12.1.8 Furnessing the Output Trip Matrix

If the parameter FURNES = T (and DOMAT = T as well) the program, having

calculated a cordoned trip matrix, checks whether the origin / destination flows in
the cordoned matrix correspond to the assigned flows in the full network. For
example, the origin flows at a “cut link” entering the network should equal the
original network flows on that link. Differences between the two may be due to
errors in re-tracing the assignment routes (see 15.23).

The output trip matrix is corrected by a process known as “Furnessing”, whereby

the matrix row and column totals (origin and destination flows) are progressively
factored to balance the required totals until a satisfactory degree of convergence
has been achieved. Statistics detailing the level of changes made and the
convergence achieved are printed by the program.

If DEMAND = F, i.e., if the output trip matrix is based on “actual flows” (see
12.1.9), then it is not possible to simultaneously satisfy both row and column totals
due to the possibility of trips being queued inside the cordoned network so that the
summation of the actual flows leaving the cordoned network may be less than the
summation of those entering the network. In this case the output matrix is “singly
constrained” to match the actual origin flows and convergence is not an issue.

Note, therefore, that if DEMAND = F and FURNES is “on” we would not

necessarily expect the destination total flows in the cordoned trip matrix to match
the actual flows at the cordon points (see Tables 1 and 2 in the .LPC file). There
are two reasons for this: (a) errors in retracing the original path flows and, (b),
ignoring any flow metering due to queues between the cordon origins and
destinations.

12.1.9 Demand vrs Actual Trip Matrices (DEMAND = T/F)

If the namelist parameter DEMAND is set to T the trips which are included in the
output trip matrix will always be based on the demand flows in the full network as
opposed to the actual flow. For example, if a particular OD path has been
assigned a flow of100 pcu/hr but that flow will have been reduced to 80 pcu/hr by
the time it reaches a cordon cut link (i.e., a new zone in the cordoned network)
due to queues en route in the full network then, if DEMAND = T, 100 trips will be
added to the cordoned matrix; otherwise, if DEMAND = F, 80 are added.

In general, therefore, for most applications of cordoning DEMAND = F is the most

natural choice since it provides a better estimate of the “true” flows for subsequent
re-assignment to the cordoned network. However, for certain applications, the full
demand trip matrix may be of interest.

5101396 / May11 12-11

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

We note that the cordoned trip matrix will always be treated as a “demand” matrix
when SATURN is run on the cordoned network whether or not DEMAND = T or F
when it is created in the sense that all trips in the matrix will be assigned starting
at their origins. Hence the (current) choice of DEMAND = F as the default (but,
N.B., prior to 10.9 the default was T for largely historical reasons).

12.1.10 SATCH Batch Files

SATCH may be run using one of two “off the shelf” batch files: SATCH.bat and
SATCH_MC.bat (thee Multi-Core version see 15.53.2.6). For full details use the
Help facilities in SATWIN.
Command Example / Comment
SATCH To run SATCH call:
SATCH fnet cnet (ftrips ctrips QUIET NOMAD n
Where:
fnet.UFS Input network UFS file
fnet.DAT Input .DAT file for fnet.UFS (Optional)
cnet.dat Input control file
cnet.LPJ Output line printer file
ftrips.UFM Input trip matrix file (optional)
Ctrips.UFM Output cordoned trip matrix (optional)
Cnet.KP Output data file for cordoned network
NOMAD Output matrix for user class n only
QUIET Runs in the background without any
windows

12.2 Optimum Offsets (SATOFF)

12.2.1 The Role of SATOFF

The relative offsets between intersections can be readily set on-line in response to
traffic conditions. In practice, this needs flows to be continuously monitored and
optimal solutions updated. On the other hand, the problem is more difficult in
modelling for a future year or an altered network since there are no observable
flows on which to base signal settings. The central hypothesis is that optimum
network offsets can be determined which, to a good approximation, are
independent of any resulting changes in flow. This assumes the selection of an
offset which minimises total vehicle delay through an intersection. The position of
this minimum (and indeed of a range of minima), when total delay is compared to
potential offsets, is expected to have a fixed location since offsets are essentially
determined by the travel time from the upstream intersection.

5101396 / May11 12-12

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

This is not to say that the offset is constant for all of the approaches to an
intersection, but that a re-assignment of traffic flows will cause an adjustment of
flows to support the offset that has been selected. Increasing the flow on an
approach due to an improved offset may lead to a demand for more green time
but this should not affect the offset since travel times remain constant.

The conclusion is that an iterative sequence of assignment and offset optimisation

will converge to give a well-defined set of offsets which can be used with
confidence to model a network.

SATOFF is based on the above hypothesis as proposed by:

 B.G. Heydecker Transport Studies Group University College, London

 D. Van Vliet Institute for Transport Studies University of Leeds

 T. Van Vuren Institute for Transport Studies University of Leeds

For more detailed information copies of the paper ‘Optimal Signal Offsets for
Traffic Assignment Networks’ presented at the Engineering Foundation
Conference on Traffic Control Methods, Santa Barbara, 1989 by the above
authors is available on request from D. Van Vliet.

12.2.2 Running SATOFF

The order of running programs with SATOFF incorporated is illustrated in Figure

12.2. Thus starting with a ‘base network’ net.DAT in which the offsets are set to
some arbitrary values a full run of SATURN is carried out, resulting in a file
net.UFS containing the ‘best’ set of assigned link flows. This file is then input into
SATOFF which calculates optimum offsets consistent with the assigned flows and
incorporates those new values into an output file net.UFA.

5101396 / May11 12-13

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

Figure 12.2 - Use of SATOFF

(The box denoted by SATASS / SATSIM is, in current versions of SATURN,

simply an application of the single program SATALL which carries out both
assignment and simulation.)

At this point two alternative ‘loops’ may be used: The ‘inner’ loop involves re-
running SATSIM immediately in order to obtain a better overall simulation of the
network flows which may in turn, by repeating SATOFF, lead to a slightly different
set of offsets.

By contrast the ‘outer’ loop returns the new offset to a full re-run of SATALL,
resulting in a new set of both assignments and simulations. This in turn may
result in new optimum offsets, but the central feature of the hypothesis above is
that relatively stable offsets may be obtained after a single optimisation (with or
without possible repetitions of the inner loop). We note that the outer loop is
virtually identical to a single “NIPS” loop within SATALL internally; see 9.12.2.

Note that the ‘outer’ loop requires SATSIM to be run prior to SATALL in order to
update the cost-flow curves output from the simulation, otherwise the first
assignment within SATALL will simply give the same flows as the last assignment
of the previous SATALL and it will converge immediately. (Indeed with the latest
10.5 versions of SATOFF it is possible to include the re-simulation within SATOFF

5101396 / May11 12-14

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

itself such that an updated and re-simulated .ufs file is produced directly; see
12.2.4.)

Hence the ‘final’ set of results is obtained after the repeated run of SATALL with
the optimised offsets.

The above sequence could be run using individual program “dos” commands as
illustrated by:

Satnet net

Satall net trips

Satoff net

Satsim net

Satall net trips RESTART

Where we note that the RESTART option is used in order that the second run of
SATALL takes its input from the file net.ufs rather than, as in the first run, a file
net.ufn. It may be usful to rename the output .ufa file each time SATOFF is run as,
say, net2.ufa etc.

To produce a network .dat file containing the updated signal offsets (since
SATOFF only produces updated .uf files) use the network edit options within P1X;
see 9.11.13.2. Equally one may wish to make use of an output .rgs file (see
9.11.14) to transfer the optimised offsets between networks.

It must be stressed that SATOFF and the associated operating rules are new and
that therefore some caution in its use is to be recommended. However
experience to date does suggest that it can produce stable and realistic offsets
and that therefore it can be used with some confidence to overcome the problem
of evaluating future and/or alternative networks within which the offsets are
indeterminate.

12.2.3 MANOFF: Master Node for OFFsets

An added feature of SATOFF introduced with SATURN 10.4 allows the offset of a
particular signalised node to be fixed and all other offsets taken relative to that
node’s definition. Note that, since the “zero point” for all offsets is arbitrary, fixing
one particular offset has no effect on the overall simulation.

The offset for the master node “MANOFF” is that defined in the original network
.dat file and need not be zero (although it might make more sense if it were). At
the end of every run of SATOFF if the offset of the master node has been
changed from 0 to, say, 15, then every offset in the network is reduced by 15
seconds (with the appropriate “wrap around” if that makes an offset negative).

5101396 / May11 12-15

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

MANOFF may be quite useful when comparing two slightly different networks to
judge the “true” differences between offsets.

MANOFF is defined as part of the &PARAM inputs (6.3) to the network and
cannot be over-written within SATOFF since SATOFF does not (at the moment)
have any input control files. A value of MANOFF = 0 (the default) implies that the
offsets are allowed “to float”.

If the offsets are being optimised within P1X it is possible to re-set MANOFF at
that point. The definition of MANOFF – and its fixed offset – is retained within the
various network .uf* files.

WARNING. Using MANOFF when there is a range of cycle times between

different signalised nodes is not recommended since nodes with different cycle
times cannot, as far as the modelling assumption within SATURN are concerned,
be properly co-ordinated; the concept of a relative offset in those circumstances is
not well defined. Therefore, post 10.9.22, only signalised nodes with the same
cycle time as MANOFF have their offsets adjusted.

12.2.4 Including an Automatic Re-simulation within SATOFF

In SATURN Version 10.5 the batch file satoff.bat and the program itself have been
modified so that a “command line” of the form:

SATOFF net1 net2

Will (a) output a file net2.ufa from SATOFF rather than net1.ufa, and (b) run
SATSIM with net2.ufa as input and net2.ufs as output in order to automatically
carry out the necessary steps for either the inner or outer loops in Figure 12.2.

12.2.5 Alternative Offset Optimisation Procedures

We note that virtually identical results to SATOFF may be obtained using a “batch
procedure” SIGOPT (see 15.31.6) which has certain advantages, e.g., it can also
simultaneously optimise stage timings and it can work over a selected subset of
nodes. For example, in Figure 12.2, we could substitute SIGOPT for SATOFF but
we would need an appropriately set control file in order to select the same basic
steps as in SATOFF

12.2.6 SATOFF Technical Specifications

(A) SATOFF FILES
Channel Remarks
1 An input UFS file. (Mandatory)
2 An output UFA file containing new offsets to be passed to
SATSIM. (Mandatory)
6 An output LPF line printer file. (Mandatory)

5101396 / May11 12-16

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

15/14 Terminal (output only) (Mandatory - unless MODET= 0)

(B) SATOFF DATA INPUT: None required

12.3 Direct Examination of UF Files (DALOOK)

DALOOK is essentially designed for the use of programmers to debug programs.

It enables the user to interactively determine the value of any individual item in a
binary UF file. For example it could tell you that the 325th element in the array
coded 4503 on a UFS file (which contains assigned link flows) is 1324.56 - what it
does not tell you is which link this volume corresponds to (although by looking at
other elements in the file this information could be determined). For ‘normal’
users the same information is much more conveniently supplied by SATDB which
will not only give values for all items in an array such as the link volumes in 4503
but also lists it in a table along with the link A-node and B-node. On the other
hand DALOOK is more convenient to examine the contents of ‘non-link-based’
data arrays.

To run the program using standard procedures type:

DALOOK LIVNET

or

DALOOK I

to run fully interactively.

12.4 Direct Comparison of UF Files (DACHEX)

DACHEX enables users to compare two UF files element by element and to print
out summary statistics of which elements differ and by how much. Like DALOOK
it is essentially a programmer’s tool used, for example, to see whether or not
making a change to a program has any effect upon the output.

Users may find useful applications for it but, to a large extent, the same functions
are catered for by other programs; e.g. MX compares two matrix files element by
element and produces more ‘user friendly’ output statistics.

12.5 Transferring UF files (DADUMP and DALOAD)

DADUMP and DALOAD are two short complementary programs which are
intended to enable users to transfer binary or UF files (e.g. network or matrix files)
between computers. Thus DADUMP transfers the contents of a UF file into a card
image or text file while DALOAD converts a text file into a UF file.

To transfer a file run DADUMP on the ‘donor’ computer, transfer the resultant text
file to the ‘recipient’ computer and re-build the UF file using DALOAD. The use of

5101396 / May11 12-17

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

the intermediary text file is necessary since generally speaking it is very difficult to
transfer binary files between different computer systems and/or operating systems
(although not necessarily impossible - if you can do it that way, do it in preference
to using DADUMP/DALOAD).

Using the standardised control procedures type:

DADUMP LIVNET

on the donor followed by (on the recipient computer):

DALOAD LIVNET

The intermediate file will be named LIVNET.KP.

Note that the .KP file is almost certainly much larger than the base UF file.

The procedure is generally satisfactory for the transfer of files, say, from a fast
mainframe processor to a PC for the further analysis of results, e.g., in P1X. If,
however, further iterations are to be performed on the recipient computer the KP
transfer process may result in a loss of accuracy due to rounding errors.

12.6 SATPIG: Generating Route Flows

SATPIG is a relatively ad hoc program designed to produce a file of origin-

destination route flows from a SATURN assignment, in particular to facilitate
interfaces with micro-simulation network analysis programs such as DRACULA
which require as input a file describing the number of ij trips per distinct route as
opposed to a trip matrix which gives total trips independent of route. It follows the
general principles for re-constructing routes using the SAVEIT option as described
in 15.23.

To run SATPIG use a command line such as

SATPIG net trips (KR control

Where: net.ufs Input post-assignment network file;
trips.ufm Input trip matrix
net.LPG Output line printer file
net.trp Output route file (TRPFOR = T)
or
net.kp Output route file (TRPFOR = F)
control.dat Input control file (Default: satpig0.dat)

The control file contains a standard Namelist &PARAM input set with six control
parameters: four LOGICAL parameters TRPFOR, CSVFOR, NAMES and ALLOD

5101396 / May11 12-18

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

(Default = T, F, T and F respectively), one integer parameter NOMAD (default 0)

and 2 real parameters FPHMIN and PODMIN (default 0.01 and 0.1 respectively)
whose functions are explained next.

TRPFOR

The route flow data is embedded within the .kp/.trp files with one set of records
per O-D pair with positive flow ordered by increasing destination within increasing
origin. The format (and extension) used is determined by the LOGICAL
parameter TRPFOR such that:

 If TRPFOR = F each set of records consists of:

RECORD 1:
Cols 1-10 Origin zone (name)
11-20 Destination zone (name)
21-25 User class number (NOMADS>1)
26-30 Route number 1, 2, 3 for the O-D pair
31-40 Route flow (pcu/hr) in format F10.2 (i.e. decimal in
column 38)
41-50 Number of nodes in the route

RECORD(S) 2:

The series of nodes making up the route in format I10, i.e. up to eight nodes per
line, 10 columns each.

 TRPFOR = T each set of records is output using the .trp format conventions
adopted by DRACULA such that:

RECORD 1:
Cols 1-10 Origin zone (name)
11-20 Destination zone (name)
21-25 User class number (NOMADS>1)
26-35 Route flow (pcu/hr) in format F10.2 (i.e. decimal in
columns 33)
36-45 Fractional route flow in format F10.6

RECORD(S) 2:

The series of nodes making up the route is in free format and enclosed within
leading and trailing % symbols. I.e., each node is separated from its neighbour by

5101396 / May11 12-19

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

a space with up to 80 characters per record; multiple records are used if

necessary.

CSVFOR

If .TRUE. the output data contains the same basic data entries as per TRPFOR =
T but with one variable-length record per path in CSV format.

N.B. CSVFOR and TRPFOR cannot both be T at the same time; if both are T then
TRPFOR takes precedence and CSVFOR = F.

NAMES

If .TRUE. all output files use node “names” as opposed to sequential numbers.

ALLOD

If .TRUE. all O-D pairs are included even if they have zero trips in the trip matrix
cell, in which case the FPHMIN criterion below can never be satisfied. However if
their nominal fraction of use exceeds PODMIN (see below) they are included.

If none of the nominal routes satisfy PODMIN and/or FPHMIN the “best” single
route – as defined by having the maximum usage - is always included unless
PODMIN is negative (see below).

FPHMIN

Any route flows less than FPHMIN are ignored in the .lpg and/or .trp outputs.

PODMIN

Any routes with fractional flow greater than PODMIN of the total flow are included
whether or not the FPHMIN criterion is satisfied or not. Thus the criterion for
inclusion is an either/or rule of both absolute and fractional flows.

Note. However, that if PODMIN is set negative then it is never invoked and
whether or not a path is included in the output file is determined purely by the
ALLOD and FPHMIN rules.

NOMAD

If positive NOMAD specifies the particular user class to be analysed for a network
with multiple user classes; if zero all user classes will be analysed.

Notes:

5101396 / May11 12-20

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

1) Under method (i) the origin and destination zone names are included as the
first and last entries in the route names under record 2, but under (ii) only the
“real” nodes are entered under record 2.

2) If there is only one route used per ij pair then the route number on record 1 is
simply 1; otherwise it increases by 1 each set.

3) Route flow records are terminated by a blank line.

4) Multiple user classes are sorted such that all O-D records for class 1 come
first (with a 1 in column 25), followed by all class 2 records (2 in column 25),
etc. etc.

The program is still very basic; forward requests for extra facilities to DVV.

12.7 SATDYSK - Dynamic Time Skims

12.7.1 Introduction

SATDYSK skims minimum origin-destination times for a network run with multiple
time periods (e.g. using SATTPX and SATSUMA, see Section 17) with the
important property that the skims are taken at fixed intervals of either precise
arrival or departure time throughout the full time period modelled and the “on-path”
link travel times are calculated dynamically. It differs in several respects from the
skimming techniques available through SATCOST (15.27.4) which in turn uses
SATLOOK.

Thus if a network is modelled by four 30 minute time slices from 8:00 to 10:00
SATDYSK could be used to calculate the minimum travel times for vehicles
departing from their origins at, e.g. 8:00, 8:10, 8:20…., 9:50, 10:00. All 13 skims
are output to one matrix of dimension 13nZ rows x nZ columns (where nZ is the
number of zones). The 10 minute interval is user-set. By contrast SATCOST
could be used to skim four separate matrices of “representative” OD time for the
four separate time slices.

Another point of difference between the time skims and those in SATCOST is that
in SATDYSK the skims may be calculated backwards from the destination. Thus
the 8:50 O-D time skim could reflect the time taken for trips arriving at their
destination D at exactly 8:50, as opposed to a forward time skim when 8:50 would
represent the exact departure time from the origin O. (At the programming level
this has necessitated a new set of tree building routines which build “backwards”
as opposed to the traditional SATURN method of building trees “forward” from the
origin.)

A third difference is that, whether origin - or destination-based, the link times used
in the tree building are instantaneous dynamic times so that the travel time on link
a is a continuous function of the “clock time”. Thus, if building a set of shortest
paths (tree) for trips arriving at D at 8:50 and the tree algorithm has reached a link
which is 7 minutes “back” from the destination than the time assumed on that link

5101396 / May11 12-21

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

would be the time at 8:43 exactly, as opposed to the normally modelled average
link time in the 8:30 to 9:00 time slice.

One application of the program is to enable the derivatives of O-D travel times to
be estimated with respect to either arrival or departure times by taking the
differences in skimmed times between two successive times and to use that as
part of a peak-spreading model.

The “skims” are based on calculating minimum time routes independent of

whether or not the original assignment model was based on pure time or
generalised cost so the paths found are not necessarily those used by the original
model. In effect the original model is simply being used to generate a set of
dynamic link times and/or delays by clock time.

12.7.2 Instantaneous Link Travel Times

The instantaneous or dynamic estimates of link times as a function of clock time

are based on the sum of two components:

 Transient travel times (i.e., V < C)

 Queued delay (V >C)

Transient delays include both delays at junctions (turning movements) and

speed/flow delays on capacity-restrained simulation links plus all buffer links (if
any).

Queued delays, in this context, are only assumed to occur at simulation turns.
Without going into detail, queues in SATURN are assumed to increase or
decrease linearly over time as V > or < C so that, in theory at least, we know the
queue at any point in time; see 17.6.1. Knowing the queue length and the
departure rate (capacity) it is straight forward to calculate the time spent in the
queue as a function of arrival time clock time. (Note that as an added
“sophistication” if a vehicle arrives in one time slice but departs in another the
program allows the capacity to change as you move between time slices.)

Transient delays are assumed to be estimated by the original SATURN run at the
mid-point of each time slice, e.g., at 8:15, 8:45, 9:15 and 9:45 minutes in the
above example.

Intermediate times are then simply calculated by linear interpolation with two
exceptions: transient delays before the first mid-point (e.g. 8:15) are assumed
equal to the delay at that point, and delays after the last mid-point (9:45) are
similarly equal to that delay. Over-capacity delays are constrained in a slightly
different way in that they are assumed to be zero at the start of the first time slice
but may be positive at the end of the final time slice (although queues at the end
of the final time slice may indicate that the model is not covering the “full” peak
period and might need to be extended). These assumptions allow delays either
before or after the simulated period to be estimated as the sum of the two

5101396 / May11 12-22

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

components and included in the calculations, clearly necessary when we look at

arrival/ departure times near the end points when the trip must extend outside the
simulated period.

In both cases the functions of travel time/delay vrs. “clock” time are continuous,
although there will almost certainly be discontinuities in slope, e.g. at the mid-
points with transient delays.

It needs to be said that defining an instantaneous delay with such a fine precision
is probably pushing the bounds of realism within SATURN since it ignores all
considerations of day-to-day and minute-to-minute variability. Nonetheless it is a
strict application of the basic rules by which SATURN normally calculates average
delays and, if one wants to have a more precise model of time-varying travel
times, then that is the price to be paid.

The line printer file, contains inter alia, a table of time-specific link times for each
link at times 0, TOM, 2*TOM ... (NTOM-1)*TOM seconds. These need to be
checked for “realism”.

12.7.3 The Output Skimmed Matrix

The origin-destination travel time disaggregated by departure/arrival time are

output in the form of a stacked matrix which contains nZ x M rows where nZ is the
number of zones and M is the number of discrete departure/arrival times (variable
NTOM in &PARAM; see 12.7.5).

Thus, in the case of origin or departure time based skims, the first row in the
matrix contains the times from origin 1 to all destinations (columns) departing at
the earliest time skimmed, row 2 will contain the times from origin 1 of the second
departure time, row M+1 contains the earliest departure times from origin 2, etc,
etc.

Note, somewhat perversely and it probably should be changed, in the arrival-

based or backwards mode each row of the output matrix represents skimmed
times for a destination so that e.g., the Jth element in such a row would be the
time FROM origin J to that destination. In the other mode the row defines an
origin and the column a destination.

12.7.4 SATDYSK Files

The following files are used by the program for either input (I) or output (O).
Channel Extension Function
1 (I) .UFT Input network file for multiple time periods
2 (O) .UFM Output matrix of skimmed times
5 (I) .DAT Control file
6 (O) .LPV Line printer output file

5101396 / May11 12-23

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

12.7.5 The SATDYSK Control File

Similar to other control files it is based on namelist input (see App.A) with “name”
&PARAM. The following variables, with their type and default values may be set.
Variable Type Default Function
DEPART L T If T skims are based on departure times; if
F on arrival time
NTOM I 10 Number of arrival/departure skims
TOM I 600.0 Time in seconds between skims

E.g.:

&PARAM

TOM = 30

DEPART = T

&END

Note that the values of TOM and NTOM should presumably reflect the total length
of the time period modelled. Thus the defaults cover a range of departure times of
6000 seconds, 1 hour and 40 minutes. If the model were of three 30-minute time
slices then the last two skims would probably be redundant; if the model covered
2 hours then the range would probably need to be extended.

12.7.6 Running SATDYSK

To run the program you must first have run a multiple time period simulation; e.g.,

SATTPX net 4
SATSUMA net 4
followed by:
SATDYSK net
The bat file SATDYSK uses the following files:
net.uft Input network file
net.ufm Output skimmed matrix file
net.LPV Output line printer file
SATDYSK0.DAT Control file (12.7.5)

5101396 / May11 12-24

10_09_24_Section 12.doc
SATURN MANUAL (V10.9)

Supplementary Programs

12.8 Version Control

JOB NUMBER: 5101396 DOCUMENT REF: Section 12.doc

Revision Purpose / Description

Originated Checked Reviewed Authorised Date

1 Re-formatted (Final to DVV) TF / BG NS IW IW 06/05/06

3 Upgrade to V2 Templates 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

3.5 Web release – Jul 07 DVV NP IW IW 19/07/07

3.6 SATURN v10.8 Release DVV NP IW IW 26/01/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.22 Web release – Dec 10 DVV AG IW IW 06/12/10

10.9.24 SATURN v10.9 Release (Full) DVV DG IW IW 23/05/11

5101396 / May11 12-25

10_09_24_Section 12.doc