6.

PREPARATION OF A NETWORK DATA FILE

We describe here the complete network data structure for SATURN.

Although networks may be coded following the conventions below, we
would expect most new networks to be coded interactively using
P1X/PMAKE (see 5.6). Under these options, the formats described
become essentially invisible to the user since the correctly formatted files
are produced automatically.

The network data file input to SATNET (network.DAT in Fig. 3.1) may
be conveniently divided into 11 segments, the first 3 of which are
mandatory while the last 8 are optional (although clearly in order for a
network to be defined either the simulation or the buffer records must
exist):

1 - OPTION SPECIFICATION RECORDS

2 - NETWORK TITLE
3 - PARAMETER SPECIFICATION RECORDS
4 - THE SIMULATION NETWORK
5 - THE SIMULATION CENTROID CONNECTORS
6 - BUFFER NETWORK/LINK DATA
7 - RESTRICTED TURNS AND LINKS
8 - NODE AND/OR ZONE CO-ORDINATES
9 - FIXED ROUTES (E.G. BUSES)
10 - COUNTS OF LINK AND/OR TURNING VOLUMES
11 - GENERALIZED COSTS (Multiple User Classes)

In each case their presence is indicated by a code number given in

column 1 of the record preceding the first data record. Thus the
simulation network records are preceded by a 1, the centroid connectors
by a 2, etc. Moreover each segment of data input included is terminated
by a record with one or more 9’s commencing in column 1 (and
traditionally written as ‘99999’ in columns 1 to 5 although ‘9 ’ has the
same effect), and the complete data file must be terminated by a record
with a 9 in column 1. Further details are given under the appropriate
sub-sections below.

(N.B. For purely “aesthetic” reasons the single number, say 1, is

normally written as ‘11111’ so as to take the same number of columns as
the ‘99999’ terminators. Hence we refer to, e.g., the ‘33333 records’.)

With two exceptions each data segment appears only once and in
numerical order. The exceptions are segment 6, bus routes, and segment
7, link counts, which may appear more than once (but with the obvious
proviso that all such segments appear together and in the correct order).
1
 Segments 6 and 7 also differ from all others in that a “title” may be
included following the opening 66666 or 77777 text; see 6.9.3 and note
(3), 6.10.

Sub-Sections 6.1 to 6.11 give the format specifications for each of the 11
possible data segments, followed by an example of a network file in
6.14.

Note that in certain instances the required format differs if the “DUTCH”
option, which allows buffer node numbers of up to 8 digits, is invoked.
Places where the alternative format is applicable are indicated below but
the specification of the DUTCH alternatives is given fully in Section
15.20.

In common with other input data files any record commencing with a ‘*’
in column 1 is treated as a comment card; see Section 15-29. In addition
all data segments (apart from 2) may all refer to secondary files using the
‘$INCLUDE’ facility described in Section 15.30.

Supplementary Input Files

In addition to the “main” network data file it is possible (version 9.4) to

input certain supplementary network data in an extra data file referred to
as the X-file and defined by the parameter XFILE under Namelist
PARAM; see 6.3.4. For example link capacity indices or link-specific
parameters such as TAX may be defined in this way. The data which
may be added in this way is described in Section 6.13.

A slightly different form of supplementary data file is the GIS file (see
5.7) which may be also referenced under &PARAM, 6.3.4, and which is
used to provide extra network information for output and display
purposes.

In addition the trip matrix file to be used in later stages may also be
defined within the input .dat file (6.3.4). Although not used directly by
SATNET if present it is read in and checked at this stage for any
obvious incompatibilities with the network file being created (e.g.
different numbers of zones).

2
6.1 Option Specification Records (Mandatory)

This record* (or records) requests the major options available within
SATNET. The specification of options is via the FORTRAN namelist
facility. The user unfamiliar with this is referred to Appendix A.
Essentially namelist provides a form of free format input for defining
values of variables within the program. Parameters not explicitly
mentioned take a default value. Namelist input runs to as many records
as necessary but it must always be preceded by (in this case) &OPTION
and terminated by &END.

Note that repeated variables (i.e., the same name is defined more than
once) generate semi-fatal errors since it is not clear which of the two (or
more) definitions is the correct one.

The following six parameters may be defined by &OPTION; the first

four are all LOGICAL and default to .FALSE., the last two are character
variables which default to “blank”:

UPDATE TRUE if a new network is being built which is very similar

to a previous network, in which case the previous network
will be used to provide good initial estimate of flow-delay
parameters. See Section 15.3.

PASSQ TRUE if queues are to be passed over from a previous time

period. See Section 17.4.

PLOD If TRUE the assigned flows from an input SATURN UF file

are “Pre- LOaDed” as fixed flows onto this network. See
Section 15.5.

PLODFF If TRUE the pre-load data file uses free or CSV formats.
See Section 15.5.4.

UPFILE The name of the file which is to be used under the UPDATE
option. See 15.3.

PQFILE The name of the file which is to be used under the PASSQ
option. See 17.3.

PLDFIL The name of the file which is to be “pre-loaded”. See 15.5.

Thus the OPTION records might be specified by the following set of

records which explicitly sets UPDATE to .TRUE., PASSQ to .FALSE.

* Each "line" of the input file is referred to as a "record".

3
 and, by default, PLOD to .FALSE.:

&OPTION
UPDATE=T,
PASSQ=F,
UPFILE = ‘LASTNET.UFS’
&END

For users preparing a new network file the default values set for all of
these parameters are those required and therefore we need not be
concerned with them at this stage. Thus you need only include a ‘null’
namelist record:

&OPTION
&END

6.2 Network Title (Mandatory)

This record contains a network title of up to 80 characters which is

reproduced on all output from the model. This enables the user to
distinguish between various runs.

Additional lines of text may be inserted between the record containing

the network title proper and the start of the &PARAM records. Those
lines make up a “history file” which is saved as part of the .ufs file and
may be printed at later stages. It is a useful device for adding comments
when a .dat file is updated, etc.

6.3 Parameter Specification Records (Mandatory)

These records set user-defined model parameters for this run using the
FORTRAN namelist facility as described above for the OPTION
records, the one difference being that the namelist ‘name’ is &PARAM
instead of &OPTION. See Appendix A.

Some of the parameters defined here are used in the network build stage,
others are relevant to the (later) simulation or assignment stages; the
latter are set here and passed to the relevant programs via the SATURN
UFS/A files (where they may be re-set). In certain cases therefore full
documentation is deferred to later sections with appropriate pointers
being given here.

Note that repeated variables (i.e., the same name is defined more than
once) generate semi-fatal errors since it is not clear which of the two (or
more) definitions is the correct one.

4
 The parameters are grouped under LOGICAL, INTEGER, REAL and
CHARACTER variables and listed in alphabetical order.

The default values set are generally “good” choices. However in certain
instances, e.g., where a variable has been introduced at a late stage of
SATURN development and the “best” value would change the output
from existing .dat files, a “no change” default has been set. These are
indicated by an alternative “RECOMMENDED” value in addition to the
default.

As discussed in Appendices A and B variable names may be

“subscripted”, e.g. GONZO(2) instead of just GONZO. Generally the
subscript refers to the time period for which this variable definition
holds. However in certain limited cases, a subscript may be used to
refer, to, e.g., a particular user class. The latter variables (BETA,
POWER, MCUBC and MCGILL) are indicated by a (u) in the following
lists. Other variables, such as BUSPCU, () refer to “bus company” and
are denoted by a (b); see 6.9.3.

Alternative spellings are sometimes accepted, e.g. TIJFIL can be used

instead of FILTIJ, basically since both seem equally logical to me. But
there aren’t very many so if you want to be certain to set a parameter
correctly you need to be careful with its spelling. On the other hand
parameter names are case insensitive - any lower case characters are
translated into upper case.

The lists are long, many of the variables and their use are complicated
and the net effect on new users is definitely off-putting. For such mere
mortals the following subset of variables is suggested as reasonable
starting points where explicit choices need to be made; otherwise trust
the defaults:

LOGICAL: LEFTDR, SUZIE

INTEGER: LCY, LTP, MASL,LRTP
REAL: GAP, GAPM, GAPR, PPK, PPM
CHARACTER: FILTIJ

6.3.1 Logical Parameters

AMY If TRUE all assignments are carried out with “fixed”

travel times corresponding to free flow travel with no
speed changes. See Section 7.11.4.
Default - .FALSE.

ASHORT If TRUE assignment statistics by iterations are given in a

5
 table in the output line printer files rather than (at length)
per iteration.
Default - .TRUE.

ATLAS If TRUE all nodes in the 55555 data section are included
in the map network whether or not they are connected to
links. See 18.5.2 and note (9), 6-8.
Default - .FALSE.

AUTOK If TRUE any “Kombi” averaging of flows during the

assignment–simulation loops is controlled
AUTOmatically. See Section 9.3.1.
Default - .FALSE. (Recommended .TRUE.)

AUTOX If TRUE any uncoded external simulation nodes are

automatically coded using the best available data. See
Section 15.12.
Default - .TRUE.

AUTOZ If TRUE zones are automatically generated at each

external simulation node with the same number as the
external node. See Section 15.12.
Default - .FALSE.

BEAKER If TRUE any capacity index set for a simulation link (via
data input under the 33333 cards below) is automatically
associated with all turns out of that link.
Default - .TRUE. (Changed in 10.5)

BUSKER If TRUE a file containing full bus route data is output to

a file network.BUS so that, e.g., interpolated routes are
given with every node included. See 6.9.2.
Default - .FALSE.

COMPAS If TRUE links from a common buffer node are sorted so

that they appear in the listings in clockwise order
(counter -clockwise if LEFTDR=F).
Default - .FALSE.

DIDDLE If TRUE each assignment after the first commences with

the final set of flows from the previous assignment; if
FALSE it starts with an all-or-nothing load. See 9.4.
Default - .TRUE.

DUTCH If TRUE node numbers in the buffer network may have

up to 8 digits, otherwise they are limited to 5. (N.B. If

6
 TRUE certain input formats throughout the Suite are
altered - see Section 15.20.)
Default - .FALSE.

ERRYES(I) Controls the listing of error messages: if ERRYES(I)=T

then message I will be printed; if F it will be suppressed.
Range of I from 1 to 260. See Section 2.9.
Default - .TRUE.

ERTM (For Eastern Region Traffic Model). If TRUE then

negative elements in the trip matrix are assigned
(Definitely NOT recommended for normal use!) See
Note 4, Section 4.
Default - .FALSE.

EXPERT If TRUE the level of print out generally is such that only
an “expert” would fully appreciate it.
Default - .FALSE.

EZBUS (Pronounced EASY-BUS!) If TRUE the bus route data

on the 66666 data records (see 6.9.2) are in “free
format”; if FALSE they are in fixed column format.
Default - .FALSE.

FIFO If TRUE, if and when a data item appears twice, the first
data entry is discarded and the last one used; if FALSE
the first entry is always used. See 6.15.
Default - .TRUE.

FOZZY If TRUE the program will try to “interpolate”

unconnected nodes in bus routes. See Sections 6.9.2 and
15.18
Default - .FALSE. (RECOMMENDED .TRUE.)

FREDDY If TRUE an output .rgs file containing a listing of all

signal settings is created. See 11.9.14.
Default - .FALSE.

FREEKY If TRUE then the extra KNOBS data records in the

33333 records are input as “free format”; see 6.6.
Default - .FALSE.

FREEXY If TRUE then the supplementary node data in the 66666

records (i.e. X, Y co-ordinates) are input as “free

7
 format”; see 6.8.
Default - .FALSE.

ICING If TRUE elastic assignment uses a frozen trip matrix

(which may be defined here by FILICE). See 7.5.6.
Default - .FALSE.

ILOVEU If TRUE U-turns are allowed at external simulation

nodes; if FALSE they are (virtually) banned. See 18.9.
Default - .FALSE.

KERMIT (KilometERS and MInuTes!)

If TRUE the travel distances and times input on buffer
link records are assumed to be in units of kilometres and
minutes rather than metres and seconds. Outputs in P1X
assume the same units. (Useful for very large scale buffer
networks only.)
Default - .FALSE.

KINKY If .TRUE. the standard speed-flow curves used for both

the simulation and buffer networks have a “kink” or
discontinuity at V=C, above which they are linear and
below, “power law”. If KINKY = FALSE they are a
power law throughout. See 15.38.
Default - .TRUE.

KONAL If TRUE any KNOBS data is included at the end of each

333 buffer record rather than as an extra line; see 6.6.
Default - .FALSE.

LEFTDR If TRUE left-hand drive assumed. See Section 15.7.

Default - .TRUE. (or as set in SAT95KEY.DAT;
Appendix Y)

LIST If TRUE a complete listing of the input records is given

by SATNET in the LPN file.
Default - .FALSE.

NOXYC If TRUE then a ‘C’ is not necessary in the 55555 records

in order to identify a zone; see 5.1.6 and 6.8.
Default - .FALSE.

NO333C If TRUE then a ‘C’ is not necessary in the 33333 records

in order to identify a zone; see 5.1.6 and 6.6.
Default - .FALSE.

8
PARTAN If TRUE use the PARTAN option within single user class
Wardrop assignment; see 7.11.7.
Default - .FALSE.

PHILIP If TRUE use Phil Barrett’s suggested formula for the

flow reduction W-factor in link weaving; see 15.40.3.
Default - .FALSE.

PRINT If TRUE descriptions of the simulation, buffer and/or

assignment networks are printed by SATNET in the LPN
file.
Default - .FALSE.

PRINTF If TRUE flows are printed for the assignment network by

SATEASY.
Default - .FALSE.

PRSFD If TRUE SATSIM prints full flow-delay parameters for

each simulation turn.
Default - .FALSE.

QUEEN If TRUE blocking back calculations are based on the

value of the link QUEue at the ENd of the simulated time
period, if FALSE it is based on the average queue. See
8.5.
Default - .FALSE.

Q105 If TRUE certain new rules introduced in 10.5 for

calculating delays in highly congested circumstances will
be used; see 8.4.7.
Default - .TRUE.

RAGS “Random delays At Give-wayS” The additional delays

due to “random” effects are applied to “give-way” or
“minor” traffic movements as well as “major”; see 8.6.2.
Default - .FALSE.

REDMEN Elastic Assignment Parameter; if TRUE an initial

estimate of the road trip matrix (file FILRED) is used
under elastic assignment, see 7.5.3.2.
Default - .FALSE.

REFFUB If TRUE calculate buffer turn (geddit?) flows post

assignment (but only if SAVEIT = T)
Default - .FALSE.

9
 ROSIE If TRUE time-flow curves for turns in shared lanes are
calculated as a function of the total shared flow, not the
individual turning flow. See Sections 8.4 and 7.1.3.
Default - .FALSE.

SATOFF If TRUE signal offsets are optimised within SATALL; see

Section 15.31.4 and 9.12.2.
Default - .FALSE.

SATTIT If TRUE the standard supplementary data file

SATTIT.DAT is used to define DA code text names. See
15.21.
Default - .TRUE

SAVEIT If TRUE the link costs as used for each assignment tree
build are saved on a UFC file for subsequent analysis;
e.g., to create forests. See Section 15.23.
Default - .TRUE.

SECRET If TRUE the uf* files created will be "secret" in the sense
that the option in P1X (see 11.4.2) to recreate a .dat file
from a .uf* file will not be allowed.
Default - .FALSE.

SHANDY If TRUE the link distances input are checked against

crow-fly distances calculated from node co-ordinates;
significant discrepancies are noted and zero or blank
inputs are replaced. See 15.10.
Default - .TRUE. (Changed in 10.5).

SIGOPT If TRUE signal green splits are automatically optimised

within SATALL. See 15.31.4 and 9.12.2.
Default - .FALSE.

SOWHAT If TRUE a system optimal assignment is carried out as

opposed to a user optimal; See 7.11.9.
Default - .FALSE.

STUART If TRUE use Stuart Porter’s suggested formula for the

“Xf” factor in link weaving; see 15.40.3.
Default - .TRUE.

SUZIE If TRUE the assignment is based on Stochastic User

Equilibrium (SUE) assignment, if FALSE it is based on
Wardrop equilibrium assignment - see Sections 7.1 and
7.2.
10
 Default - .FALSE.

SUZIEQ If TRUE under the SUZIE option a parameter will be

calculated indicating the degree to which paths diverge
from true minimum cost paths.
Default - .TRUE.

UPBUS If TRUE then bus routes start/end at the top/bottom and

of simulation links. See 6.9.2.
Default - .FALSE.

WHATHO If TRUE, a system optimal assignment is carried out as

opposed to a user optimal; See Section 7.11.9.
Default - .FALSE.

WINDY If TRUE use the modern window-style terminal display

which does not “scroll”.
Default - .TRUE.

6.3.2 Integer Parameters

IBUSVC(b) The vehicle class corresponding to buses in company (b);

if unsubscripted it applies to all buses and/or companies.
See 5.8.2.
Default - 1

IFCC Defines whether the input centroid connector records in

the buffer network are assumed by default to be one-way
or two-way. A ‘1’ implies one-way and ‘2’ implies two-
way. See Note 3 under 6.6.
Default: 2

IFRL As IFCC but for the “real” buffer links as opposed to the
centroid connectors. See Note 3 under 6.6.
Default: 1

IROCKY By default the sector corresponding to a zone may be

derived by dividing the zone number by IROCKY (a very
bad spelling of HIERARCHY!). If 0 it does not apply.
See 5.1.7.
Default: 0

ISTOP Used in the test for convergence of the

assignment/simulation loops. The loops stop
automatically if ISTOP % of the link flows change by

11
 less than “PCNEAR” percent (default 5%) from one
assignment to the next. See Section 9.1
Default: 95 % (Changed from 90% in 10.5)

KNOBS Number of extra data fields included on the buffer data

records - see Sections 6.6 and 15.14.
Default: 0

KOB “Kontrol of Burrell” - sets the type of random link cost

distribution used under SUE: 0 - Rectangular 1 - Normal
2 - Modified Normal. See Section 7.2.3.
Default: 0

KOMBI After “KOMBI” assignment/simulation loops the

assigned flows are averaged with those from the previous
assignment in order to avoid oscillations. A value of 0
implies that averaging never takes place (the default).
See Section 9.3.
Default: 0

KORN “Kontrol of Random Numbers” - the seed value for the

series generation of random numbers used in SUE. See
Section 7.2.4.
Default: 0

KPHMIN Simulation link speeds and free flow speeds on…

KPHMAX buffer links with speeds outside the range KPHMIN to
KPHMAX generate warning messages in SATNET.
Defaults: 10 and 100 kph respectively.

LCY Duration of the common traffic signal cycle time in

seconds. See Section 8.1.
Default: 75 seconds.

LRTP Length of the “Random” Time Period as used for

calculating random delays at traffic signals and/or major
arms at priority junctions. See Section 8.6.
Default: 0

LTP Duration of the simulated time period (in minutes). See

8.1 and 8.4.5.
Default: 30 minutes.

MANOFF The signalised simulation node number used as the

reference point for all optimum offset set by SATOFF.
See 12.2.3.

12
 Default: 0.

MASL Maximum number of assignment/simulation loops. See

9.1.
Default: 15.

MASL F The number of simulation assignment loops over which

the input trip matrix is kept fixed under elastic
assignment; see 7.5.3.4.
Default: 0

MAXDTP Maximum “transient” delay (in minutes) permitted for a

simulated turn. See 8.4.1
Default: 10 (Changed from 0 in 10.5)

MAXQCT MAXimum Queue Clearance Time (in minutes) for

queued traffic at the end of a simulation time period. If
0, it is ignored. See 8.4.1
Default: 60 (Changed from 0 in 10.5)

MAXZN Maximum number or ‘name’ used to define a zone. See

5.1.6.
Default: 500.

MCCS Number of count fields input with the ‘77777’ data input.
See 6.10. (As in “Manual Classified Counts”).
Default: 1

MCGILL(u) Elastic assignment parameters to set the form of the

demand function for user class ‘u’ as follows (see 7.7.1
and 7.12.2):

0 = inelastic (fixed trip matrix)

1 = logit (incremental)
2 = power law
3 = exponential
4 = elastic exponential
10 = nested logit
11 = logit (shared)
Default: 0

MCUBC(u) Choice of distribution model for user class 'u'; see 7.10.2.
Defaults: 0

13
 MINLSF Minimum/maximum expected lane saturation flows;
MAXLSF Values outside these limits generate a warning message.
Defaults: 300, 3000

MINRED Used for data checking within SATNET. Any turning

movement at traffic signals with a distinct red phase of
less than MINRED seconds generates an error message.
Default: 10 seconds.

MINSAT Used for data checking within SATNET. Any turn

saturation flow below MINSAT generates a warning
message (which may be suppressed entirely by setting
MINSAT to 0).
Default: 500 pcu/hr.

MODET MODET (= MODE Terminal) determines whether (and

how much) information is output to a user terminal. If
MODET = 0 all information goes to the line printer file.
If MODET is non-zero ‘progress reports’ appear at the
terminal during the execution of the programs. (In
particular if MODET is negative reports appear at the
terminal only, if positive the same information is sent to
both the terminal and the line printer file.)
Default: 1

MYTVV Choice of the signal optimisation procedure 1 to 5; see

15.31.3
Default 1

NFT “National Film Theatre” for really great old films. Set,
e.g. NFT = 92 to get version 9.2. See 8.5.
Default: 95 (i.e. use the latest version)

NIPS Maximum number of signal optimisation “outer” loop in

SATALL. See 9.1.2.
Default: 0

NISTOP The number of successive loops which must satisfy the

“ISTOP” criteria in the test for convergence of the
assignment/simulation loops. See Section 9.1
Default: 4 (Changed from 1 in 10.5)

NITA Maximum number of assignment iterations. See 7.1.5 &.

7.2.2.
Default: 20

14
NITA_F The number of initial assignment iterations over which
the initial trip matrix is kept fixed under elastic
assignment; see 7.5.3.4.
Default: 0

NITA_M The minimum number of assignment iterations; see 7.1.5

and 9.5.1.
Default: 0

NITA_S The (maximum) number of iterations to be used in the

single post-convergence assignment under SAVEIT: If
zero, assume NITA. See 15.23.3.
Default: 0 (i.e. NITA)

NITS_M The minimum number of simulation iterations. See 8.1

and 8.3.2
Default: 0

NITS Maximum number of simulation iterations. See 8.1 and

8.3.2.
Default: 10

NOMADS Number of multiple user classes, e.g., cars, lorries, etc.,

to be assigned separately. Maximum 32. See Section 7.3.
Default: 1

NOPD A non-zero value suppresses all “Platoon Dispersion”

between successive junctions. See Section III-2 of
SATURN NOTES. (N.B. Dangerous parameter - best
ignored!)
Default: 0

NOPMAX Maximum number of internal iterations used by the

signal setting routines; see 15.31.3
Default: 1

NOTUK Used to set various “non-UK” rules of the road; see

Section 15.7.
Default: 0. (For British rules of the road)

NUC Number of time-units into which the cycle is divided in

the simulation (maximum value 25). See 8.1.
Default: 15

NUCMIN Minimum number of time-units into which the cycle is

15
 divided in the simulation (maximum value 25). See 8.1.
Lower input values are fatal errors.
Default: 1

6.3.3 Real Parameters

AFTERS Vehicles held in queues upstream of further queues are

assumed to encounter the final downstream queues
multiplied by a factor AFTERS in later time periods. A
sensible value is 1.0; the default is optimistic and chosen
for historical compatibility. See 17.6.2.
Default: 0.5

ALEX Average Length of a vehicle (EXternally) in a queue;

used to estimate the actual length of a queue from the
number of vehicles. See 8.5. Primarily used to model
blocking back.
Default: 5.75 (metres per pcu).

APRESV “Apres Vous” controls the “weight” assigned to merging

traffic in terms of the lane choice by the “major” traffic
for turn priority markers M - See Section 8.8.3.
Default: 1.0

BCRP “Buffer Capacity Restraint Power” - used to define

speed-flow curves in the buffer network - See Section
5.4.
Default: 5.0

BETA(u) Elastic assignment elasticity parameter (for user class

‘u’) as used under MCGILL = 1, 3 10 or 11. See 7.7.1
and 7.12.2.
Default: 0.1 (units of inverse generalised seconds)

BETA_2 (u)As BETA but for nested logit models. See 7.6.3 /7.6.4.
Default: 0.1

BETA_D (u) As BETA but for distribution models. See 7.10.2.

Default: 0.1

BETA_T (u) As BETA but for time-choice models. See .

Default: 0.1

BTKNOB(b,k) Bus Times (in seconds) per KNOB data field k for all
routes within bus company b. See 15.44.
Default: 0.0

16
BUSPCU(b) Factor to convert bus flows for company 'b' into P.C.U.’s.
See 6.9.1, and, in particular, 6.9.3 for subscripted values
of BUSPCU.
Default: 3.0

BUSSPK(b) Bus Stop Seconds Per Kilometre for all routes within bus
company b. See 15.44.
Default: 0.0

CAPMIN Minimum capacity to be expected for any (give-way)

turn; any junction with lower capacities will be factored
up to CAPMIN (pcu/hr). See 8.2.
Default: 30.0

COBAF Factor to be applied to link flows under the SATCOBA

facility. See 15.42.
Default 1.0

DEFCAP Default capacity per lane of a link which is “out-bound”

to an external simulation node.
Default: 1250 pcu/hr.

FISTOP Wardrop assignment stopping parameter monitoring the

fractional improvements in the objective function. See
7.1.5.
Default: 0.05%

FLPK Fuel consumption per pcu in litres per kilometre. See

15.32.
Default: 0.07

FLPH Fuel consumption per pcu in litres per hour. See 15.32.
Default: 1.2

FLPPS Fuel consumption per pcu in litres per primary stop. See
15.32.
Default: 0.016

FLPSS Fuel consumption per pcu in litres per secondary stop.

See 15.32.
Default: 0.005

FRED An initial estimate of the effect of elastic assignment on

the total number of trips (for incremental demand models

17
 only). See 7.5.3.2.
Default: 1.0

GAP Minimum gap (in seconds) accepted by a vehicle which

gives way at priority junctions or traffic signals. N.B.
This sets the universal default value which may be over-
ridden at individual nodes; see 6.4.1.
Default: 5.0 seconds

GAPM As GAP but for merging turns.

Default: 3.0 seconds

GAPR As GAP but for entry onto roundabouts.

Default: 4.0 seconds

(N.B. See Section 15.22 for further details on how to set the GAP-
parameters.)

GONZO (Gonzo the factor - not Gonzo the Great!) All elements
in the trip matrix assigned are factored by GONZO. See,
e.g., Sections 7.11.5 and 15.2.
Default: 1.0

PCNEAR Percentage change in flows judged to be “near” in

successive assignments. See 9.1.
Default: 5.0

PMAX Maximum value of the power used in the simulation

flow-delay curves. See 8.4.2.
Default: 10.0

POWER(u) Elastic assignment parameter giving the elasticity for

MCGILL = 2 or 4. See 7.7.1 and 7.12.2.
Default: 1.0

PPK Pence Per Kilometre - used to convert distances into

generalised costs. See Section 7.11.1.
Default - 0.0

PPM Pence Per Minute - converts times into generalised costs.

See Section 7.11.1.
Default - 1.0

SHADOW An assumed speed in kph for the “shadow network”

assignment option; see 7.11.10.
Default: 0.0

18
SUET Used to define the range of link cost variation in SUE
assignment - see Section 7.2.3.
Default - 0.2

TAX Number of X-coded pcus that can stack in the middle of

a signalised junction and clear after the end of the green.
See 6.4.2.2 and 8.2.2.
Default: 2.0 pcus.

TDEL Fixed “geometric” delay to allow for

acceleration/deceleration on minor arms at priority
junctions or at roundabouts. See 8.4.1.
Default: 3.0 seconds.

TIJMIN Any OD cells in the trip matrix which are less than
TIJMIN will be ignored.
Default - 0.0

UNCRTS Wardrop assignment stopping parameter monitoring the

parameter epsilon. See 7.1.5.
Default: 0.2%

VCPCU(v) The pcu value per vehicle in vehicle class v, or for all
vehicles in the trip matrix if unscripted.
Default: 1.0

WLMIN Minimum length for link weaving (in metres); see

15.40.2. (Aka DMWL)
Default - 300.0

WLMAX Maximum length for link weaving (in metres); see

15.40.3. (Aka DMWL2)
Default - 2000.0

XFSTOP Wardrop assignment stopping parameter for minimum

step length. See 7.1.5.
Default: 0.05%

XYUNIT Number of metres corresponding to an integer value of 1

as used to define node/zone co-ordinates. See 6.8.
Default: 1.0

19
6.3.4 Character Parameters

CINAME(i) The text name to be associated with capacity index i; see

5.1.9.
Default - blank. Maximum length: 20.

COINS The “smaller” unit used to define tolls; see 20.3

Default - ‘Pence’

CURNCY The “larger” unit used to define tolls; see 20.3.

Default - ‘Pounds’

FILGIS The “file name” of the GIS file associated with this
particular network; see Section 5.7.
Default - blank (i.e., no file)

FILTIJ The “file name” of the .ufm trip matrix file associated
with this particular network and which will be assigned
during the assignment.
Default - blank (i.e., no file defined at this stage)

FILCGH The “file name” of the cost matrix cOij to be used in the
distribution; see 7.10.3 and 7.12.3.
Default - blank

FILCIJ The “file name” of the .ufm cost matrix file to be used
within an elastic assignment cOij. See 7.7.1 and 7.12.3
(and 7.6.4 for its use with nested logit).
Default - blank (i.e. no file).

FILCKL The “file name” of the cost matrix to be used in the

“lower” level of the nested logit choice model; see 7.6.4
and 7.12.3.
Default - blank

FILICE The “file name” for frozen ij movements within elastic

assignment if ICING = T. See 7.5.6 and 7.12.3.
Default - blank (i.e. no file).

FILPEN The file name of the matrix used to define link tolls by
origin. (Not yet available.)
Default - blank

20
FILKNB The file name used to define link KNOBS data. See
15.14.5.
Default - blank

FILBMP The file name of the .bmp file used to define a

background display for P1X plots. See 11.3.6.
Default - blank

FILRED The “file name” of the input .ufm matrix containing the
initial estimate of the road trip matrix under elastic
assignment if REDMEN = T; see 7.5.3.2 and 7.12.3.
Default - blank (i.e. no file).

ROADIJ The “file name” of the output .ufm matrix containing the
elastic road trip matrix under elastic assignment. See
7.12.3.
Default - blank (i.e. no file).

UCNAME(u) The text name to be associated with user class u (5.8.1).

Default - blank. Maximum length: 40.

VCNAME(v) The text name to be associated with vehicle class v

(5.8.2).
Default - blank. Maximum length: 40.

XFILE Name of the supplementary X-file; see 6.13.

Default - blank (i.e. no file)

XYFORM The “format” used to define node X, Y co-ordinates

under the 55555 data records - see Section 6.8.
Default - 2I5.

N.B. Most namelist parameter names representing files

have alternative spellings so that, e.g., FILTIJ is also
recognised by TIJFIL, FILCIJ by CIJFIL etc.

21
6.4 Simulation Network

Data in this section must be preceded by a single record with a 1 in

column 1 (or, more usually, 11111 in columns 1-5) and terminated by a
single record containing 99999 in columns 1 to 5.

For internal nodes a complete description of the node, its links,

capacities of turns and signal timings (for traffic signals) must be given
on three sets of records:

1) Record type 1 - Node description (mandatory)

2) Records type 2 - Link description - One record (mandatory) for

each link in strict clockwise* order but starting with any
arbitrary link (plus, optionally, a second link record to describe
link speed-flow characteristics).

3) Records type 3 - Stage descriptions. Only required for type 3

nodes. i.e. traffic signals. One record per stage is input.

For external nodes only record types 1) and 2) are required. In addition
only the starred (*) variables below need be included on these records.

Nodes, whether internal or external, may be included in any order (i.e,

they need not be in numerical order).

All numerical data entries (bar one) are implicitly INTEGER and should
(for safety) be right justified; the speed flow power on record 2B
explicitly requires a decimal). However the following inputs may
optionally include a decimal within the designated columns in order to
provide greater accuracy: TIM on record 2, TFF and TCAP on record 2B
and STAGL and INTGL on record 3.

Coding instructions are given below and worked examples for each node
type appear in Section 16. The “NAME” column provides a convenient
shorthand for data entries and is not used elsewhere.

Historically coded simulation data ware be prepared by the user working

with their own editing system; however it is now possible to prepare .dat
files using the interactive network and node editing facilities within PIX
(see 5.6, 11.9 and 18). However some “fine tuning” using a text editor
will probably still be needed.

6.4.1 Node Data Formats

* Counter-clockwise under drive on the right.

22
***** RECORD TYPE 1 - NODE DATA *****

COLS. NAME DESCRIPTION

1-5 NODE* Node number

6-10 NIN* Number of links at the node
(Including one-way out-bound roads)
11-15 JTYPE* Node type:
0 for EXTERNAL NODES
1 for PRIORITY JUNCTIONS
2 for ROUNDABOUTS
3 for TRAFFIC SIGNALS
4 for A ‘DUMMY’ NODE
5 for a ROUNDABOUT with U-turns
16-20 JCIR Time to circle roundabout (in seconds).
(Roundabouts only)
or OR
NSTAG Number of stages - traffic signals only
21-25 OFFSET Relative offset - traffic signals only - see
6.4.3.;
or OR
RSAT Maximum roundabout capacity in pcus/hr -
see 6.4.7.
26-30 LCY Cycle time for this node (+)
31-35 NUC Number of time units per cycle (+)
36-40 GAP/GAPR Minimum gap in tenths of seconds for give-
way turns at priority (GAP) or roundabouts
(+)
41-45 GAPM Minimum gap in tenths of seconds for
merges(+)

(+) Generally left blank - 6.4.10.

23
 ***** RECORD TYPE 2 - LINK AND TURN DATA *****

1-5 STACK Link stacking capacity - see 6.4.11.

6-10 ANODE* Node at the ‘upstream’ end of the link
(which may be an external node)
11 QSTAR ‘*’ if a link speed-flow curve is required -
see 6.4.12
12-15 LANES* Number of entry lanes (plus weave and/or
bus lane indicators) for this link - see 6.4.9.
(0 if the link is one-way from ‘NODE’ to
‘ANODE’ or negative if it is a bus-only link
- See 6.4.4.)
16-20 TIM* Travel time for this link in seconds, or the
average link speed in KPH if SPEEDS = T
(See 6.4.5).
21-25 IDIST* Length of this link in metres

26-35 Data for the first possible turn from this link:

26-30 LSAT The saturation flow of the first turn from this
link in a clockwise direction in pcus/hr. See
6.4.6 and 6.4.8.
(0 implies that the turn is banned and a
negative value implies a bus-only turn - see
6.4.4.)
31 TPM The Turn Priority Marker for this turn - See
6.4.2.
32 TPMod Turn Priority Marker Modifier. See 6.4.2.
33 LANE1 First lane (counted from the nearside) used
by this turn - 6.4.9.
35 LANE2 Last lane used by turn.

36-45 Data for the second possible turn from this link:

36-40 LSAT Saturation flow, priority marker

41 TPM and lane definition for the next
42 TPMod turn in a
43 LANE1 clockwise direction
45 LANE2 etc., etc.
up to
75 LANE2 for the fifth turn (as required).

24
 (N.B. The following record, 2B, is only needed if a ‘*’ was coded in
column 11 above and LANES > 0, in which case an extra line
containing link speed-flow parameters is inserted. This option is
relatively rarely used. See 6.4.12.)

***** RECORD TYPE 2B - LINK SPEED FLOW DATA ******

11-15 TFF Link travel time at free flow (in seconds)

or (if SPEEDS = T)
Link travel speed at free flow (in kph)
16-20 TCAP Link travel time at capacity (in seconds)
or (if SPEEDS = T)
Link travel speed at capacity (in kph)
21-25 LCAPY Link capacity (pcu’s per hour)
29 S if speeds are used in 11-20, T if time; if
blank then SPEEDS decides. See 6.4.12.
36-40 N The power ‘N’ used in the speed-flow curve
with a decimal in column 39
43-45 INDEX A “link index” in the range 0-999; see 5.1.9

***** RECORD TYPE 3 - SIGNAL DATA ******

11-15 STAGL Stage duration (sec). See 6.4.3 and 6.4.13.

16-20 INTG Duration of following inter-green (Seconds).
See 6.4.3.
21-25 NGM The number of node entries which follow
as GNA(1), GNC(1), GNA(2) ...
GNC(NGM/2) (Since two entries are
required per green movement NGM is twice
the number of such movements.)
26-30 GNA(1) The A-node for the first green (i.e.,
permitted) movement
31-35 GNC(1) The C-node for this turn (i.e., The
movement ‘A-node’ to ‘NODE’ to ‘C-node’
is permitted in this stage).
36-40 GNA(2) Second A-node.
41-45 GNC(2) Second C-node. etc.
for all green movements up to
71-75 GNC(5) Fifth C-node (as required).

N.B. (i) If any C-NODE entry above is zero or blank it is assumed that
ALL turning movements from that A-NODE (except of course any
prohibited movements indicated by zero saturation flow) are allowed.

25
 (ii) If more than 5 movements are required they are continued onto a
second record with the 6th A-node appearing in cols. 26-30 of the
second record, etc.

6.4.2 Turn Priority Markers (TPM) and Modifiers

(N.B. For right-hand drive read left for right in this note and vice-versa.)

These describe which traffic flows oppose a turning movement.

Explanatory notes follow. The main TPM must be one of the following:

G - A turn which must give way (from a minor road) at a priority

junction.

X - Opposed right turn from a major road at a priority junction

which needs to cross the major flow in the opposite direction,
OR an opposed right turn at traffic signals which must cross the
major flow from opposite arms.

M - A turn which “merges” with another turning movement at a

priority junction.

F- A permanent filter at traffic signals with 100% green (generally

to the left but occasionally to the right).

W - A weaving movement between traffic entering and leaving

(typically) a motorway.

Q - A motorway merge; see Appendix Q.

BLANK - No opposing flow.

While the modifiers (which are used relatively infrequently) must be one
of:

C- To denote a “Clear” or reserved exit lane used after G or X;

D- A “Diamond Cross”, i.e., to convert hooked into non-hooked or

vice-versa; used after G or X;

E- Both C and D apply.

26
 Further Notes:

6.4.2.1 (G) The G priority marker indicates either a “give-way” or a “sharing”

manoeuvre whereby a turn marked G gives way to all “major” turning
movements (i.e. those without any priority marker or an X) but “shares”
with other give-way movements. The movements which affect a G-turn
are either those which it crosses or those with which it shares an exit;
these are determined by SATURN from the geometry of the junction.

W 0 E (Major Road)

Thus in the above figure if the

S turn S-O-E were coded G it would give
way to the major road flows W-O-E and E-O-W but would “share” with
movements N-O-S (crossing) and N-O-E (shared exit). On the other
hand it is unaffected by turn W-O-N which it neither crosses nor shares
an exit with.

If movement 1 “gives way” to movement 2 this means that the capacity

for movement 1 goes from its (otherwise) maximum value down to zero
as the flow on movement 2 increases from 0 to its capacity. See Figure
5.1. Movement 2 is unaffected by movement 1.

However if they “share” the capacity for movement 1 goes from its
maximum down to ONLY 50% maximum as movement 2 increases,
while movement 2’s capacity also goes from 100% down to 50% as
movement 1 increases. Hence sharing implies that both movements are
guaranteed 50% of their capacity plus another 50% depending on the
shared partner.

6.4.2.2 (X) Movements coded X at priority junctions must give way to opposing
major movements; for example W-O-S above (which turns right from a
major arm) would give way to the opposing straight ahead flow E-O-W.

27
 The same rule applies to X-turns at signals with the additional condition
that they are only opposed by flows which share the same green times,
not by movements which take place during other “phases”. In addition it
is assumed within the simulation routines that up to TAX pcus can
execute an X movement at the end of each green sequence. This allows
for vehicles stacking in their reserved lanes and discharging during the
amber phase.

Note that if the X-marker is placed on the “wrong” movement then the
consequences may be severe and not always easy for the program to
detect. For example, in the above diagram, if the X marker were assigned
to E-O-W rather than W-O-S then the straight ahead traffic would give
way to turning traffic and clearly the junction would behave in a quite
different manner. It may be, of course, that in certain circumstances that
is exactly the give-way behaviour that is required but, generally
speaking, such an allocation of X-markers should be regarded as highly
suspicious.

The above possibility was first identified in release 10.5 and assigned the
Serious Warning number 139. Previously it was identified only via
“warning 53” which, in the above example, would be due to the fact that
two “major” movements W-O-S and E-O-S both enter the same arm
without one having priority over the other.

6.4.2.3 (M) A “merging” turn coded M must give way to a single “major” turn
flow, the most obvious example of this being a slip road entering a
motorway and giving way to the straight ahead flow. In addition, it only
needs to find a gap in a single (nearest) lane.

Since a M turn only gives way to one lane of one movement it is less
restrictive than a G marker.

The following rule is used to determine the turning movement with which
a turn coded M merges. The opposing turn must (a) share the same exit
arm, and (b) be the first turn from an “off-side” link (in a counter-
clockwise direction for drive on the left) to do so. In virtually all cases
the turn marked M will be the first turn out of a link and will merge with
the second turn from the previous link; however more complicated
merges may also be modelled under the above rule. For example, a turn
may merge with a major “near-side” flow provided that no suitable “off-
side” flow is detected first. (A near-side merge is found by the program
working its way through off-side roads until it comes to the near-side;
hence the reason that there must be no off-side flows.)

Thus in the schematic diagram below (where all roads are one-way, A to
N, B to N and N to C) if turn B-N-C were coded M it would merge as

28
 the minor road with A-N-C as the major flow, i.e., on its “off-side”.
However, if A-N-C were coded as M it would be the minor arm merging
with B-N-C as the major arm on its near-side.

The merge facility can also be used to model “Y” junctions where two
streams of traffic with equal priority merge. Thus in the above diagram
both turns A-N-C and B-N-C would be assigned priority markers M and
both turns would suffer a reduction to their capacity and an increase in
their delay dependent upon the alternative flows. See 8.8.3 for a more
detailed discussion of how the lane choices would be modelled in this
situation. N.B. Y-merges are a new feature in SATURN 10.3 and, as
explained in 8.8.3, should not be used with certain lane configurations.

Alternatively, two one-way streets merging into a one-way street could

also be modelled by coding each turn as a G, but this would almost
certainly result in greater losses of capacity.

6.4.2.4 (F) Turns coded F at traffic signals “give way” (in the same way that G
movements give way) to traffic in their exit road but are assumed to have
100% green time and therefore they need not be mentioned explicitly in
the stage definition records. F turns would generally be expected to have
an exclusive lane, as illustrated in the diagram below, but this is not
absolutely compulsory. They may be either left or right turns (although
left - nearside - is most common) but must be either the first turn to left
or right.

29
6.4.2.5 (W) The “weave” priority markers first introduced in SATURN 9.4
typically represent a weaving section where traffic may both enter/leave a
motorway from/to an adjoining slip road. The “geometry” is illustrated
below (based on left hand drive).

D A
E

C B

Here A-E-D represents a 2-lane motorway and B-E-D a 2 lane parallel

slip road. Four turning movements are possible:

A-E-D Stay on the motorway

A-E-C Exit the motorway
B-E-D Join the motorway
B-E-C Stay on the slip road

30
 Lane allocations are not shown in the diagram and are of course set by
the user but for the sake of illustration we shall assume that the “straight
on” movements A-E-D and B-E-C can use both lanes while A-E-C may
only use the single nearside lane and B-E-D, the single offside lane.

Movements A-E-C and B-E-D are linked together via a weaving section
and both would need to be coded with a priority marker W. This
produces the following potential give-way and/or sharing rules.

A-E-D: Unopposed

A-E-C: Shares with its co-weaving movement B-E-D and gives way to
any B-E-C flow which uses the offside slip road lane.

B-E-D: Shares with its co-weaving movement A-E-C and gives way to
any A-E-D flow which uses the nearside motorway lane.

B-E-C: Unopposed

Notes

1. In addition to give-way and/or sharing reductions in capacity there

may also be reductions due to lane sharing: e.g. A-E-C and A-E-D
may both share the nearside lane.

2. W priority markers must always appear in pairs with, for fairly clear
reasons which are difficult to specify succinctly, certain geometrical
rules. Pragmatically this boils down to the rule that the W’s must
appear in the same column on two successive link records.

6.4.2.6 (C) An example of a turn with a “Clear Exit” - turn modifier C - is given
below:

Here the S to E movement, indicated by a and coded with a turn priority

marker G and a modifier C, has its own exclusive exit lane and therefore
need not give way to ‘b’ vehicles on the major road W-E. However they
do give way to the W-S vehicles (indicated by d) and the E to W
movements (indicated by c) since they must cross these movements.

Hence any movement with turn modifier C only gives way/shares with
31
 movements that it must cross but not with movements with which it
simply shares an exit.

In the above example had S-E only been coded as G it would have had to
give way to the W-E movements as well.

C markers may only follow an X or a G and may be used for any turn
except the first (since the first turn can only share its exit, by definition it
cannot cross any movements).

6.4.2.7 (D) Opposite pairs of right-turning G or X movements may either

“hook”, i.e. interfere, or not with one another depending on the road
geometry. The two possibilities - (a), not hooked; (b), hooked - are
sketched below:

The default situation is as set by NOTUK; hence with the “UK” default
value NOTUK = 0 interference as in (b) is assumed; coding a turn
priority modifier of D would convert the situation into no interference as
in (a). Equally if NOTUK = 1 or 3 (see 15.7) then the default is (a) and
a D for an individual turn converts to (b).

Hence the D modifier is essentially a “toggle” which switches between

the two possibilities.

Logically both turns should be coded as D’s or neither, but there is no

absolute requirement that this is coded.

6.4.2.8 (E) This indicates that both the C and D modifiers apply, e.g. a
hooked/unhooked movement with a clear exit lane.

32
6.4.3 Stage Definition, Duration, Inter-green and Offsets

The operation of signals is described by a series of stage times, inter-

green times and the movements that are green during each stage.

Since the definition of a “stage” as used within SATURN may possibly

differ from that used by other people we first define it. Thus a “stage” is
a period of time during which there is no change to any traffic signals
(with the exception of a red changing to amber which we model as
though it were continuously red) AND at least one movement has a green
signal. The “inter-green period” is the time period between the end of
one stage (i.e., when one green movement ceases) and the start of the
next (i.e., when another green movement begins).

The durations of the stage time and the inter-green period are defined in
fields 1 and 2 on Record Type 3, i.e., columns 11-15 and 16-20
respectively. See also 6.4.13 for how to define upper and lower limits on
the stage green times.

Under certain circumstances the inter-green period is set equal to zero.

For example, if on a particular arm a left filter arrow is displayed, say, 10
seconds after the “main” green phase begins this would be coded by
having one stage of length 10 seconds and zero inter-green followed by
another stage in which the left turn is added to the list of green
movements.

Zero-length inter-greens therefore imply that green movements in two

successive stages must be continuously green. The same also applies, in
general, to non-zero inter-greens. For example the inter-green period
might represent the gap between the display of straight-ahead and left
arrows and of straight-ahead and right arrows, in which case the straight-
ahead movement continues as green during the inter-green.

The general rule is therefore that movements which are green during two
consecutive stages are also green during the inter-green, with two
exceptions:

(i) If the signals have only one stage (in which case every
possible movement must be coded as green during that
stage) it is assumed that all movements are red during the
inter-green. This situation commonly occurs in the
representation of pedestrian signals at a node in the middle
of the block.
(ii) If the inter-green time is coded by a negative number, in
which case the absolute value gives the true inter-green time.
33
 This coding has been introduced to deal with the case of
pedestrian signals which have, say, TWO red periods during
the cycle time simulated.

Note that, as implied above, we do not explicitly model amber phases -

signals are considered to be either “red” or “green” - although it is
possible for the coder to allow for vehicles “stealing” a certain amount
(typically about 1 second) of the post-green amber phase by artificially
extending the green phase.

The input values for stage and inter green durations need not add up to
the total cycle time (LCY). If they do not, stage times will be factored
by the program so that the sum = LCY. Inter-green times, however,
remain as input on the assumption that they represent safety margins
between successive signals. Double cycles are coded by repeating the
single cycle inputs twice.

The offset refers to the time at which the first coded stage begins relative
to some absolute zero point for all signals in this system assuming some
form of signal co-ordination. If there is no co-ordination the offset is
essentially arbitrary and should probably be set to zero. In the event of
the stage lengths being factored as above the offset is unchanged.

6.4.4 Bus-only Roads and Turns

Bus-only roads, i.e., roads which are only used by buses in that direction
only, are identified by a NEGATIVE value of LANES on record 2 above.
Turn capacities should be coded in the normal way. The effect of this
coding change is that no car trips will be assigned to this link but the
effect of buses both entering and leaving the link on other traffic will be
modelled.

See 6.4.9 for how to code roads with exclusive lanes for both buses and
cars.

By contrast bus-only turns are turns out of a normal link from which cars
are banned. This is signified by coding a negative turn saturation value
(LSAT on Card 2) with the correct absolute value.

Note that it is not necessary to code bus-only turns out of a bus-only

road, although no harm is done by doing so, since once the road has been
coded as bus-only no vehicles will be assigned to it by the assignment
and hence no vehicles will reach the turns either.

Bus-only links and turns may also be coded using the banned turn/link
facility as described in Section 6.7 below (and in a number of respects

34
 this is a more natural way to do it).

The latter input MUST be used if one wished to code, say, a “bus plus
taxi” link since a negative value as above would ban taxis as well as
other vehicles.

6.4.5 Link Travel Times/Speeds and Distances

The link travel times input are the times required by a vehicle to traverse
the entire length of the link from stop line to stop line with no vehicles
queued at the exit stop line. Similarly the input cruising speed (if used)
is the speed under these conditions. Since this time or speed is taken as
fixed by the program independent of the flows assigned to this link it
should reflect the expected level of traffic flow on that link. However it
must be emphasised that a number of studies have shown that in urban
conditions cruising speeds on most roads are virtually independent of the
flows, depending far more, for example, on whether the road is
residential, shopping, divided highway, etc. This is not to say that
TOTAL travel times are independent of flows, but that the main
relationship between flows and delays occurs at intersections, and it is
these relationships that SATURN seeks to model in depth. Conventional
link-based speed-flow relationships are therefore generally not part of the
simulation network unless one explicitly uses the link speed flow facility
described in 6.4.12. (See also Section 15.13).

In most cases therefore the times or speeds may be thought of as “free-

flow” times or speeds. However an example of a case where they might
not be free-flow would be a motorway-style road with grade-separated
access and exit points where intersection delays would be minimal but
the effect of flow on cruising speeds might be significant. In such cases
observed speeds would probably be the most reliable input (unless of
course link speed-flow curves were used - 6.4.12).

Link distances should be coded from the centre of one junction to the
centre of the next (but coding them as entry to exit lines would make
virtually no difference).

35
6.4.6 Turn Saturation Flows

6.4.6.1 General Principles

Turn saturation flows refer to the maximum number of pcu’s per hour
which could make that particular turning movement PROVIDED there
were no other vehicles on the road, no red lights to oppose it, etc. Thus
the only restrictions to be taken into account in specifying the turn
saturation flow are the physical characteristics of the junction such as the
number of lanes, their widths, turn radii, give-way or not, etc. The model
then simulates the reductions to the turn capacities from all other effects.

N.B. Note the slightly different interpretation for roundabouts -

6.4.7.

Note, however, that the simulation model (see 8.2.1) may not necessarily
include all restrictions to vehicle movements. For example the
simulation includes the reduction in capacity due to minor road vehicles
giving way to major road vehicles but not giving way to pedestrians
since the latter are not explicitly represented within SATURN. In such
cases it is necessary for the user to introduce the extra effects by
modifications to the input data.

Generally speaking this is best done by reducing the saturation flow to

account for the “missing” effects such that, at the end of the ACCEPT
calculations (8.2.1) the correct capacity has been obtained. Thus if a
turn with a “purely geometric” saturation flow of 2000 pcu/h gives way
to a pedestrian crossing where, the user decides, there are pedestrians
25% of the time the saturation flow should be reduced to 1500 pcu/h.

Other coding methods may occasionally be used; for example, if the

impact of pedestrians at traffic signals is to effectively delay the start of a
green stage, e.g. the pedestrians tend to cross en masse at the start of a
particular green stage rather than at random throughout the green
stage(s), then this may be better reflected by reducing the length of the
relevant green stage.

See 15.17 for a discussion of why we refer to pcu’s rather than vehicles.

6.4.6.2 Setting Saturation Flows

Setting “correct” saturation flows is as much an art as a science and it

is not really the role of this Manual to supply precise numerical
formulae to apply since every area to be modelled will have its own
particular characteristics which will influence saturation flows.
However, in general terms, one can say that the following features

36
 should be considered in setting saturation flows:

i) Number of lanes
ii) Lane widths
iii) Position of lanes (e.g., nearside vrs offside)
iv) Junction type (e.g., roundabout vrs priority etc.)
v) Major/minor arm (at priority junctions)
vi) Inclination (on hills)
vii) Visibility
viii) Turning angle (e.g., straight ahead vrs 90 right or left,
sometimes measured in terms of a “turning radius of curvature”)

We would strongly recommend organisations to set up their own sets

of tables and/or formulae, cross-classified by one or more of the
above criteria, such that a modeller, having “measured” the essential
parameters above, may simply look up / calculate the appropriate
saturation flow.

One major advantage of having standard procedures as above is that

two different coders, given the same junction to code, will come up
with saturation flows which, if not identical, will at least be close.

6.4.6.3 Consistent Saturation Flows by Lane

Of the various factors listed under 6.4.6.2 above all are effectively
independent of the individual turn being considered apart from viii), the
turning angle (or turn radius). Qualitatively one would expect that the
saturation flow for vehicles going straight ahead would be greater than,
say, for vehicles turning at right angles either to the left or to the right. It
is, however, difficult to specify the exact form of the relationship;
different modellers will have their own personal or in-house rules. It
follows that it is very difficult for a computer program to say that if a
straight ahead saturation flow has been coded as 2,000 pcu/hr then a turn
saturation flow of only 500 for a 90 turn out of the same lane is
“wrong”.

Nevertheless it is important to be able to at least warn users when input

values appear to be inconsistent. In order to do so SATURN adopts the
arbitrary formula that a turn through an angle  (where  = 0 implies
straight ahead) will have its saturation flow reduced by cos (/2) relative
to straight ahead. Thus the saturation flow for a right angle turn is
reduced by a factor of cos(45) = 0.707.

SATNET applies a consistency check by:

37
 (a) Calculating a saturation flow per lane for each turn equal to its input
saturation flow divided by by the number of lanes;
(b) Converting that to an “effective” straight ahead saturation flow by
dividing it by cos (/2);
© Comparing the minimum and maximum effective saturation flows per
lane for each individual lane and for the entry arm as a whole.

If the ratio of maximum to minimum is (arbitrarily) greater than 1.5

overall or 1.4 in an individual lane then a “Serious Warning 137” is
generated.

This rule was first introduced in release 10.5 and clearly contains a
number of arbitrary assumptions. Indeed there is no overwhelming
reason why the warnings generated are “correct”; there may well be
other perfectly valid reasons why the user has chosen a particular set of
input saturation flows. On the other hand coding errors are not exactly
rare and it is to be hoped that the above procedures will be able to
identify “real” errors more often than not.

6.4.6.4 References

TRRL SR 582 for priority junctions, or Webster and Cobbe (Road

Research Technical Paper 56, 1966) for traffic signals may be consulted;
however more up-to-date publications are clearly to be preferred. I
suggest you look on the web!

38
6.4.7 Roundabout Saturation Flow

Turning movements at roundabouts are not considered as individual

turns. All turns from the same entry arm are simulated as a single flow
so that in effect each entry arm is modelled as a priority T-junction with a
single left turn. Therefore all turn saturation flows should equal the
saturation flow for that arm as a whole, and they should all be equal. (If
they are not equal the computer will apply the maximum value to all
turns. Banned turns, i.e., turns into entry-only arms, are indicated in the
normal way by a zero saturation flow.)

Reference: TRRL SR 942.

The maximum roundabout flow coded on Record Type 1 represents the

circulating flow at which the entry flow from any arm goes to zero (or,
strictly speaking, to the minimum value set by CAPMIN). It should be
greater than the saturation flow from any entry arm (i.e., the maximum
value of all turn saturation flows); if not it is replaced by the maximum
value. See 8.7.

Section 15.22 explains how the values of the arm saturation flows, the
roundabout capacity and the minimum gap may be set so that the
SATURN results are compatible with those from the TRRL roundabout
simulation package ARCADY.

6.4.8 The Order of Turns

Turning movements from each arm must be specified in strict clockwise

order starting with the first turn on the left (*). If this rule is not adhered
to serious errors can result. Given the geometrical complexities of
networks it is generally difficult to check whether this rule is complied
with and, if not, where the error occurs. One check carried out by
SATNET is to determine whether a series of sharp left turns from each
arm returns to the same starting point, since one would expect that these
movements should trace out a closed loop on a map.

The test breaks down when the network contains overpasses where two
links may cross one another without there being an intersection. Any
possible errors reported by this check should be studied on a map.

(*) Or counter-clockwise and on the right for right-hand drive

applications. The general rule is that the turns are given from the
“nearside” to the “offside”.

39
6.4.9 Lane Definition

The number of lanes defined for each input arm corresponds to the
“effective” number of lanes at the stop line, not the number of lanes
along the road itself. By “effective” we mean that a link which, say, has
only one lane marked but is sufficiently wide that vehicles can squeeze
by on the nearside when a vehicle is queued on the offside should be
coded as two lanes, not one. Otherwise SATURN will over-estimate the
blocking effect of queued vehicles and underestimate capacities.
Similarly it may be advisable to include an extra “artificial” lane for
offside turning traffic if the flow is relatively light and queued traffic can
be accommodated in the centre of the junction without impeding other
movements on the same arm. In case of doubt - code extra lanes!

The problem is most acute when one or more turns give way and
therefore may block any unimpeded traffic in the same lane. Hence a
single lane is “OK” for major arms at priority junctions (although
unlikely to occur in real life), but not otherwise. Single lanes which
include both give-way and non give-way movements are a major
problem for convergence (9.5).

Note that SATURN lane numbers are counted from the nearside or kerb-
side out so that lane 1 is the “innermost” lane nearest to the kerb-side
and the highest lane is the “outermost” lane nearest to the centre of the
road.

Successive turns (starting with the left turn for drive-on-the-left, right for
drive-on-the-right, and progressing clockwise/counter-clockwise) must
obey certain fairly basic traffic engineering rules. Thus there can be no
empty lanes. Equally (drive on the left) a right-turn cannot use lanes 1
and 2 while the straight-ahead can only use lane 2 since that would imply
that the right turns from lane 1 would need to “cut-across” straight ahead
traffic in lane 2.

Bus Lanes

It is also possible to include bus-only lanes as part of the link simulation

record by including one or more B’s within columns 12-15; see Section
15.39 for full details of how bus-only lanes are modelled in SATURN.

Briefly a bus-only lane is defined to be a “full-length” lane from the

upstream entry to the downstream stop lane exclusively used by buses
(where “buses” in fact includes any form of public transport vehicle as
coded on the 66666 records; 6.9.1). Thus at the moment bus lanes with
set-backs cannot be explicitly modelled.

40
 To define, say, a road with a total of three lanes, two for normal traffic
and the nearside lane reserved for buses, columns 12-15 should be coded
‘ B2’; if the bus lane were down the centre of a 2-way road (e.g. a tram
line) or in the offside lane of a 1-way road then it would be coded ‘ 2B’.
Similarly ‘ B2B’ would represent four lanes total with bus lanes in both
the nearside and offside of the roadway.

Weaving Segments

In addition to one or more B’s in columns 12 to 15 a ‘W’ may be

included to indicate that this link is part of a “weaving segment” as
defined in Section 15.40. Note that the W may appear in any of the 4
allocated columns, i.e., either before or after the number of lanes.

6.4.10Node-Specific Parameters

The input parameters referred to as LCY, NUC, GAP/GAPR and GAPM

are used to over-ride the parameters of the same name set as, in effect,
“global” parameters under &PARAM. If the input value is zero - or
much more simply left blank - then the global value is taken. See Section
15.15. (N.B. columns 36-40 refers to either GAPR or GAP depending
on whether the node is a roundabout or not.)

Note that turn-specific values of GAP (for priority junctions and traffic
signals, not roundabouts) may also be set using the X-file; see 6.13.

Note also that all gaps are input as integers representing tenths of
seconds so that if 15 were input this would be interpreted as 1.5 seconds.
It is not possible to input, say, 1.53 within the 5 columns provided in
order to obtain extra precision although the extra precision is possible
when the gap is either defined globally through namelist or turn-specific
in the X-file

41
6.4.11 Link Stacking Capacity

The link stacking capacity is defined as the number of pcus which would
cause a queue to extend into the previous junction. If left blank or zero
the stacking capacity is calculated by:

STACK = LANES * IDIST/ALEX (6.1)

Indeed much of the time the stacking capacity may just as well be left
blank since STACK is only used to model blocking back - see Section
8.5. As long as the default value exceeds the queue on a link it has no
affect whatsoever on the simulation.

If ALEX is zero, implying infinite capacity, then STACK is, in effect,

infinite, although the actual value stored will be zero. Hence setting
ALEX to zero totally suppresses blocking-back and in this case there is
no real need to define STACK at all.

The position of STACK on the record is clearly rather strange; logically

the A-node number should come first. The reason for this is historical as
early versions of SATURN did not include STACK. However, since in
most cases the “stack field” can be left blank, the ANODE will appear
first.

6.4.12Simulation Link Speed Flow Curves and Capacity-Restraint

Generally speaking, simulation links have fixed travel times, assumed

equal to their free flow or cruise travel times; see 6.4.5. However it is
possible to define link speed-flow curves for simulation links in the same
way that one may define link speed-flow curves for buffer links. Equally,
explicit capacities may be defined on simulation links themselves (as
opposed to capacities set by downstream junctions).

To do so you must first insert a ‘*’ in column 11 of the link data record
(type 2), indicating that an extra record (type 2B) is to be inserted before
the next link data record, containing speed-flow data. (N.B. Do not
include a * if LANES = 0, ie., columns 12-15 are blank or zero, and the
link is therefore one-way outbound. This can sometimes be forgotten if a
in-bound link is converted to out-bound only.)

42
More specifically the extra record gives:

(1) the free flow travel time t0 in seconds / free flow speed in kph
(2) the time at capacity tC in seconds / capacity speed in kph
(3) the link capacity C (sometimes referred to as the “pinchpoint”
capacity)
(4) an ‘S’ or ‘T’ to indicate speeds or times above
(5) a “power” n
(6) a “link index” or “capacity index” (optional); see 5.1.9.

such that link travel time as a function of flow V is defined by:

t(V) = t0 + A * Vn V < C (6.2)

where the parameter A is chosen such that t(C) = tC. For V > C the time
is constant, tC.

This data has two effects: (1) it determines the travel time/speed on the
link itself; and (2) it may reduce the turn capacities at the downstream
junction. See Section 8.4.4 for further details.

Note that by leaving entries (1) through (4) blank but coding a capacity
index allows one to use a “default” speed-flow curve as defined within
the 33333 buffer records. See 15.9.4.

The use of the single characters S or T in column 29 to denote “Speeds”

or “Times” is new in 10.5. If column 29 is left blank then the choice is
set by the parameter SPEEDS as on the normal simulation link records.
Previously SPEEDS was always used.

We may note therefore that the same data columns and conventions are
used in the 11111 simulation link speed-flow curves as in the 33333
buffer network link records (although certain entries in the 33333 records
such as the A-node and the B-node are ignored here), making it simple to
transfer 33333 data directly into the 11111 records.

We also note that if (and only if) the link is to an external simulation
node then the same information may also be input via the 33333 buffer
records; see 15.13. If both occur for the same link then FIFO (see 6.15)
decides which to select. However, it must be stressed that in such cases
it is strongly recommended that the users themselves make that decision
by either removing the data within the 11111 or the 33333 records to
avoid any ambiguity as to the required link properties.

43
 We repeat that the above problem does not arise with internal simulation
links where the 11111 data always takes precedence over 33333 data.

6.4.13Minimum and Maximum Stage Green Times

Post 10.4 it is now possible to define minimum and maximum times for
each green stage which will be applied during the signal optimisation
procedures (see 15.31). The data is input under simulation node Record
Type 3 (6.4.1) in the “first” data field, i.e., the columns up to and
including column 15. The full data format is of the form:

Tmin < T > Tmax

Or, alternatively:

Tmin < T < Tmax

Where the first version is, for reasons given later, the “standard” version
although the second may appear more intuitive. E.g., 10<20>30 or
10<20<30 would both imply a stage length of 20 seconds with a
minimum of 10 and a maximum of 30.

If, on the other hand, only a single minimum or maximum stage time is to
be set the correct formats are respectively:

Tmin < T

and:

T > Tmax

The rationale behind using a < symbol for “minimum” and > for
“maximum” is that otherwise an input field such as 20<30 could either
be interpreted as a green time of 20 seconds with a maximum of 30 or as
a green time of 30 with a minimum of 20. Thus 20<30 implies the latter
and the former would need to be written as (somewhat counter
intuitively) as 20>30.

The obvious error checks such as minimum time less than green time and
maximum greater than green time are made on input and, in the case of
any violations the min/max inputs are ignored.

44
6.5 Simulation Centroid Connector Data

Data for the simulation centroid connectors (as opposed to centroid

connectors in the buffer network) are preceded by a single record with a
2 in column 1 (or 22222) and terminated by a single record with 99999
in columns 1 to 5.

At least one connector must be specified for each centroid and no more
than six. Centroids need not be input in numerical order as the program
automatically sorts them.

For further information on centroid connectors please see 5.1.6, 5.1.8

and 16.6.

Note as well that use of the AUTOZ option (see 15.12) allows the data
input here to be either reduced or eliminated altogether.

Cols. Description

1 -5 Zone or centroid number or ‘name’

6 -10 First or A-node on the connected simulation link
11 -15 Second or B-node on the connected link
16 -20 A-node for the second connector (if present)
21 -25 Second B-node Etc.

NOTES:

(1) It is not necessary to include both an A-node and a B-node. If

one if missing, i.e. blank or 0, the following rules apply:

(2) If only the A-node is given then the zone is connected to all
links FROM A; i.e., the blank B-node is treated as a “wild card”
representing all possible values of B.

(3) If only the B-node is given then the zone is connected to all
links TO B; i.e., the blank A-node is treated as a “wild card”
representing all possible values of A.

(4) If A = B then the zone is connected to all links both TO and

FROM A; i.e., situations (2) and (3) combined,

45
 (5) However if either the single A-node or B-node is an external
simulation node then the connections are made to all links from
A/B to internal nodes. Since in most cases external simulation
nodes are only connected to a single internal node the only
information really required by the program is the external node
and including a second node is largely redundant.

6.6 The Buffer Network/Link Data

These records have a dual purpose: (i) to define the structure and
properties of the link-based buffer network; and (ii) - generally a
secondary objective - to define extra link-based data for simulation links
(as described in Sections 15.13 and 15.14).

The data is preceded by a single record with a 3 in column 1 (or 33333

in cols 1 - 5) and terminated by a record with 99999 in columns 1 to 5.

Each link in this section, whether ‘real’ or ‘centroid connector’, is

described by either a single record (if KNOBS = 0) or two records (if
KNOBS > 0 and KONAL = F; see Section 15.14) with the following
format:

(N.B. An alternative format applies under the DUTCH option - see

Section 15.20.)

RECORD 1

Cols. Description

1 A ‘C’ if the following node refers to a zone or a ‘D’ if

this is a default speed-flow curve; see (8) and (13).
2 - 5 The A-node for the link.
6 A ‘C’ to indicate a zone number following.
7 -10 The B-node for the link.
11 -15 The link time (in seconds) or speed (in kph) under
free-flow conditions.
16 -20 The link time (in seconds) or speed (in kph) at
capacity.
21 -25 The one-way link capacity (in pcus per hour)
28 A one-way/two-way indicator - see note (3).
29 An ‘S’ if speeds were defined above; otherwise times
are assumed.
31 -35 The link distance (in metres).

46
 36 -40 The power to be used in the link flow-delay curve.
(FORMAT - F5.1 -therefore a decimal point must
appear in column 39.)
43 -45 A “link index” in the range 0-999; see 5.1.9.
46 - 80 (Optionally) up to KNOBS extra data items - see note
(9).

RECORD 2 (optional); see notes (9) to (11).

Cols. Description (FREEKY = F; FORMAT 8F10.2)

1-10 First piece of extra data for link A-B

11-20 Second piece of extra data
etc., etc. with decimal points in columns 8, 18, etc.

NOTES:

(1) If either the capacity time or the capacity is zero (or blank) it is
assumed that the travel time is fixed. A capacity of zero - or
blank - is assumed to imply infinite capacity - actually recorded
as 9999 pcu/hr. It is further assumed that all centroid
connectors have fixed travel times and an infinite capacity, i.e.
9999.

(2) Link capacities in the buffer network are not the equivalent of
saturation flows in the simulation network in that link capacities
take into account the reduction in capacity due to traffic signals
at the down-stream junction, give-ways, etc., whereas
simulation saturation flows are based purely on road geometry
and ignore all such factors as above.

(3) If column 28 contains a 1 this implies that the link (or centroid
connector) is one-way from A-node to B-node; a 2 implies that
it is two-way. If column 28 contains any other number - or
more commonly if it is left blank - then the value is taken as that
defined by IFRL and IFCC (See 6.3 above). Hence by default
all input real links are assumed to be one-way (since IFRL = 1)
and centroid connectors are two-way (IFCC = 2). If two-way,
all link properties are assumed to be the same for both
directions.

(4) If columns 36-40, the link flow-delay power, is left blank - and
capacity restraint is indicated - then the default value defined by
BCRP is assumed.

47
 (Note that it is not 100% essential that the decimal point falls in
column 39; FORTRAN READ statements are forgiving and will
correctly read a decimal in any of the 5 columns. This means
that you are not restricted to a single figure after the decimal
point.)

(5) The possible uses and applications of the link index in columns
43-45 are explained in Section 5.1.9. See in particular note (8)
below. If the parameter BEAKER is TRUE then the index is
also associated with all (simulation) turns out of the link.

(6) If either the A-node or the B-node is an internal simulation node

this link will not be added to the buffer network. (This happens
very commonly when a network is originally set up with buffer
links defined under 3333 which are then re-defined as
simulation nodes and added to the 11111 records). However a
buffer link can join a pure buffer node to an external simulation
node or two external simulation nodes.

(7) Excluded simulation links - as defined above - are not totally

ignored in that if A-B has previously been coded as a simulation
link the capacity index, as well as any extra data input on
Record 2, is associated with the simulation link. See Section
15.14 for further details. Equally certain data for out-bound
external simulation links may be defined as well - see Section
15.13.

(8) An option introduced in SATURN 8.5 allows “default” speed-flow

curves parameters (speeds, capacity and power) to be
associated with a capacity index and to “replace” blank values
on input cards. These are indicated by a D in column 1. See
Section 15.9.4 for full details.

(9) KNOBS data may be included within the 33333 records either as an
extra formatted record following each link record or as free-
format data at the end of the normal link buffer data (i.e.,
columns 46 and beyond) depending on whether KONAL = F or
T. Note that with KONAL = T no data need appear, in which
case it is assumed that all values equal zero, whereas with
KONAL = F the second record must always appear (and a
blank second record would equally be interpreted as all KNOBS
data equal zero). See Section 15.14 for further information on
the use of KNOBS data.

(10) Note that when the second KNOBS records are required it is
quite easy to forget and leave a record out, in which case the

48
 next link record will be read as though it were a KNOBS record
and the buffer link will be ignored. Various error checks are
included to try to detect this happening and to print appropriate
warning messages. This may result in a FORTRAN reading
error which is semi-fatal.

(11) If the parameter FREEKY is set to .TRUE. then data from the
second KNOBS data records (if used, i.e., KONAL = F) is read
as “free format”, e.g., it may be input as CSV (Comma
Separated Variables).

(12) The two input values for times/speeds and for distances (i.e.,
columns 11-15, 16-20 and 31-35) are implicitly integers but may
explicitly include decimal points if greater accuracy is required.

(13) The requirement to use a ‘C’ in columns 1 or 6 to indicate a

zone may be relaxed by using NO333C = F in &PARAM which
implies that any “node” whose number in less than or equal
MAXZN is a zone. This may be a useful option in converting
data sets obtained from other suites although its long-term use is
not recommended.

49
6.7 Restricted Turns and Links

Links and/or turns may be banned to certain classes of vehicles or else

“penalised” (in either the sense that a HGV might take longer to make a
turn than a car would or a monetary toll would be levied on HGV’s).
The term “restricted” applies to both. See 5.1.5.

Restricted links/turns are input one per record (but see note (7) below)
preceded by a 4 in column 1 and terminated by 99999 in columns 1 to 5:
(N.B. Different format under the DUTCH Option - See Section 15.20.)

Cols. 1 -5 The A-node, A

Cols. 6 - 10 The B-node, B
Cols. 11 - 15 The C-node, C (blank or 0 in the case of a link)
Cols. 16 - 20 The ban/penalty/toll indicator for user class 1,
Cols. 21 - 25 Ditto, for user class 2,
Cols. 26 - 30 etc. for as many user classes as specified by
NOMADS.

NOTES:

(1) Include the third node C in order to specify a turn A-B-C;

otherwise link A-B is assumed.

(2) Centroid connectors cannot be restricted, but links in both the

simulation and buffer networks plus turns in the simulation
network may be included. N.B. Turns in the buffer network
CANNOT be restricted as they do not exist!

(3) A banned link or turn is indicated by a negative indicator, 0

implies no effect while a positive number is taken to be a
penalty in either time or monetary units as explained next.

(4) A “toll” (i.e., a monetary penalty) is differentiated from a pure

time penalty by the inclusion of either a $ or & symbol
preceding the numerical value. The absence of either implies a
(possibly nominal) time penalty whose units are assumed to be
seconds. Note however that penalty times are not included with
“real” times in terms of output statistics of total times or speeds
but are listed separately. Tolls are assumed to be given in units
of, say, pence rather than pounds so that a toll of five pounds
would be indicated by £500 (or $500). For further information
see Section 20.

(5) Buses and other “fixed” flows which follow pre-defined routes
are not affected by restrictions. Hence banning a turn or link to
all classes is equivalent to defining it as a bus-only turn/link.
50
(6) If you have multiple vehicle classes (NOMADS > 1), a banned
indicator of -1 refers only to a single user class, whereas values
of -2 or less are taken to imply that the ban applies equally to
all following user classes. For example if you wish to ban a
turn for all user classes -2 in columns 16 to 20 (31 to 35 under
DUTCH) would suffice. (Presumably in this case the turn
would be bus only.)

(7) Under the usual option of a single user class only columns 16-
20 (31-35 under DUTCH) are required to specify the
ban/penalty.

(8) If there are more than 10 user classes more than one record is
required per link or turn such that each record contains 10
entries in columns 16-65 (31-80 under DUTCH). Columns 1 to
15 (30) on subsequent records are left blank. Note that this
applies whether or not the subsequent record contains nothing
but zeros (or blanks) following a -2 entry.

(9) See Section 6.12 for an annotated example.

(10) Total output statistics of, e.g., total pcu-hrs for time penalties
and total pcu-pounds for tolls may be viewed via the
simulation/buffer outputs under SATLOOK; see 11.11.4 and
17.9.

51
6.8 Node and Zone Co-ordinates/Supplementary Data

This data section, preceded by a record with a 5 in column 1 and

terminated by a 99999 in columns 1 to 5, contains both co-ordinates for
zones and/or nodes as well as - optionally - certain supplementary data:
specifically sector numbers for zones. The role of co-ordinates is
described in Section 5.1.9.

Very often co-ordinate data may be obtained directly from other data
sources, e.g. GIS systems, and “converted” into the appropriate
SATURN format. Note that it is also possible to redefine the SATURN
input format (see note (6) below) to accommodate different data sources.

Data for both simulation and buffer nodes and zones are input, one per
record, according to the following format:

(N.B. A different format is required under the DUTCH Option - see

Section 15.20 or if FREEXY = T - see note (10) below.)

Cols. Description

1 A ‘C’ if columns 2 to 5 contain a zone number;

or ‘S’ to denote a sector; otherwise blank or part of
the node number to denote a “real” node.
2-5 The node, zone or sector number; see note 7)
6 -10 Its X co-ordinate (as an integer); see note 6)
11 -15 Its Y co-ordinate (as an integer)
16 -20 (a) For zones, its corresponding sector number
(b) For nodes, no extra data is currently processed.

NOTES:

1) All input co-ordinates should be positive since nodes whose co-

ordinates have not been defined are given negative values in
order to identify them.

2) If a node is not assigned co-ordinates the program attempts to

“extrapolate/interpolate” its co-ordinates from those of its
neighbours. Users should check the co-ordinates so assigned
and, if happy with them, edit them into the .dat file. (The output
format in the LPN file should be compatible with the required
input format.)

3) The units used for co-ordinates are arbitrary but their “size” in
metres should be specified by XYUNIT. E.g., if XYUNIT = 10
then it is assumed that an increment of 1 in a co-ordinate

52
 corresponds to 10 metres “on the ground”. However, see
15.43.2, it is strongly recommended that a system based on
Ordinance Survey (or equivalent) conventions is adopted.

4) Section 5.1.7 defines sectors. If the parameter IROCKY has

been used to define “default” sector names any data given here
“over-rides” that definition. If the sector field is left blank
however the value given using IROCKY is assumed.

5) In addition to defining the sectors associated with zones this

data section is also used to explicitly define X, Y co-ordinates
for sectors. Sectors not explicitly defined have their co-
ordinates set to the arithmetic mean of their zones.

6) The precise columns (beyond column 5) occupied by the node

X,Y co-ordinates and their format may, in fact, be re-defined by
the user via the namelist parameter “XYFORM”. Thus using 5
columns each with no decimal corresponds to the FORTRAN
“format” 2I5; if XYFORM = 2F10.2 then the X co-ordinate
would be contained in columns 6 to 15 with a decimal in column
13, while the Y co-ordinate would be in columns 16 to 25,
decimal in column 23. See also 15.35 and note 10).

In all cases the first (left hand) column in each field is the one in
which a ‘C’ or an ‘S’ is inserted. These are not explicitly
mentioned in the format.

7) With the (default) format as given zones are restricted to four

digits (to accommodate the C in the first column of five),
although there are ways to allow five digits. Nodes however
may use the full five columns (since they do not need an
indicator) and have up to five digits. But see note (10) for
alternative formats.

8) Note that data described above as being in columns 16-20

strictly speaking must occur in the 5 columns immediately
beyond those used for X,Y and therefore depend on the format
used.

53
 9) Nodes within this section which have not already appeared in
the simulation or buffer networks are, by default, ignored and
generate warnings. Thus you may apply a set of coordinates for
a full network to a cordoned sub-network and the extra nodes
are excluded. However if the parameter ATLAS (6.3.1) is set to
TRUE all nodes in the 55555 data set are recorded as part of the
map network so that they may be used, e.g., as part of network
editing within P1X; see 18.5.2.

10) If the parameter FREEXY=T (see 6.3.1) then all the data
records are given in “free format”, i.e. no fixed columns and
with each data entry distinguished from its neighbours by either
a blank and/or a comma (but with the C or S only in column 1).
This has several advantages:
i) node and zone numbers may be of any number of digits
(independent of DUTCH);
ii) ditto the X, Y values which may also contain decimals;
iii) communication with other data base systems (e.g.
spreadsheets or GIS) is made easier.

11) The requirement to use a C in column 1 to identify zones may

be relaxed by setting NOXYC = F in &PARAM, in which case
any “node” number less than or equal MAXZN is automatically
interpreted as a zone. This may be useful in converting data
from external data sets although its long term use is not
recommended.

54
6.9 Fixed Routes (E.g. Buses)

6.9.1 General Principles and Format

Routes in SATURN are defined by a fixed sequence of nodes through

either the simulation or buffer networks and may represent either:

i) Bus routes (or other transit services such as trams), or

ii) Routes to be used for later analysis, e.g. timed routes from
moving car observer surveys.

The second use is (effectively) new in SATURN 9.5. The two are
differentiated by assigning a frequency of zero (columns 7-10 below) to
non-bus routes.

Bus routes are “seen” by SATURN as fixed loads to be added to the

assignment flows. One bus per hour is equivalent to ‘BUSPCU’ pcus per
hour.

Route data records are preceded by a record with 6 in column 1 and

terminated by a record with 99999 in columns 1 to 5. A route is defined
on one or more records as follows:

(N.B. A different format applies under the DUTCH Option - see Section
15.20 and/or under the EZBUS Option - see 6.9.2, note (6).)

Cols. 2 - 5 The “name” of the route (which may, SATURN 9.1,

be alpha-numeric as opposed to pure numbers).

Col. 6 ‘T’ if the route is two-way and the node order is

exactly reversed (in which case the reverse route need
not be coded);
‘R’ if the route is defined in “reverse order”, i.e.
starting at the last entry;
otherwise leave blank; See note (7) in 6.9.2.

Cols. 7 - 10 The route frequency in buses per hour (which could

be zero; see 6.9.4.

Cols. 11 - 15 The number of nodes through which the route passes

(i.e., the number of node entries following); optional -
see 6.9.2, note (6).

Cols. 16 - 20 The first node on the route

55
 Cols. 20 - 25 The second node on the route etc. up to column 80
(i.e., up to 13 nodes per line, 6 under DUTCH).

The list of nodes may be continued on a second, third, fourth, etc record
(up to a maximum of 20 records - see 6.9.2, note (9)) starting in column
16 and leaving columns 1-15 blank. Alternative conventions for
specifying nodes are given in 6.9.2 while 6.9.5 describes how to include
“timing points”.

6.9.2 Route Definitions and Formats

(1) Bus routes which begin or terminate on links inside the

simulation network must do so in exactly the same way as flows
to or from zones if UPBUS = F(its default); i.e., they commence
at the downstream end of their first link and terminate at the
upstream end of their last link. For example a bus route through
nodes A, B, C, ... X, Y, Z (with all nodes being internal
simulation nodes) would first appear as a fixed volume on turn
A-B-C and last appear on turn X-Y-Z. Hence there is no flow
on either link A-B or Y-Z.

If, however, UPBUS = T then the buses are deemed to start at

the first upstream simulation node and to terminate at the last
downstream simulation node. Hence, in the above example,
there would be a bus flow on both A-B and Y-Z.

(2) If, however, A and Z were external simulation nodes then the
first and last flows would always be on links A-B and Y-Z since
centroid connector flows are allowed to terminate at external
nodes (independent of UPBUS).

(3) The above restrictions only apply to the ends of routes within
the simulation network; they do not apply to sections of route
through the buffer network.

(4) Missing node numbers are allowed in the sense that blanks may
appear in the list of nodes and will be ignored by the program.
This is a useful facility if it is known in advance that new nodes
are to be inserted in some future networks; without blanks file
editing by insertion can be a problem. Strictly speaking,
therefore, cols 11-15 (if used) give the position of the LAST
node to be read.

(5) If FOZZY is TRUE and co-ordinates have been defined for all
nodes, then if two successive nodes do NOT constitute a link,
the program will “interpolate” the set of nodes which lie nearest
56
 to a direct line between those nodes (see 15.18). Thus if a route
follows a straight line (more or less) then it is not necessary to
define every node along the line, only the first and last nodes.
Hence in addition to the first and last nodes in a route it is only
essential to define nodes at any “kinks” in the route.

This is a very useful facility and its use is strongly

recommended. However please note that in order to use it you
must first have defined node co-ordinates.

Note that the interpolated routes take one-way streets into

account. This means, for example, that a route which is defined
to be two-way (T in col. 6) may have a different set of
interpolated nodes in the two directions.

(6) If EZBUS is TRUE then the nodes through which the route
passes may be defined in a “free format” whereby:

(i) Cols 1-10 remain the same (i.e., fixed column format).
(ii) 1-15 are ignored; i.e., leave them blank.
(iii) Cols 16-80 contain a list of nodes, not necessarily in
fixed columns, but separated by one or more spaces or
commas (CSV).
(iv) If there is insufficient space to include all nodes on the
first line further continuation lines may be used,
identified by blanks in columns 1-15 followed by the
node numbers in columns 16-80.

Note that this option may be combined with the FOZZY option
so that the nodes need not be consecutive; in fact this is
certainly the easiest way in which to define routes.

If, however, EZBUS is FALSE (the default although not

recommended) then the entry in columns 11-15 is necessary to
specify the number of nodes which will follow or, strictly
speaking, the number of LINES which follow. Thus, for
example and assuming a maximum of 13 node entries per line
with DUTCH = F, any number between 14 and 26 will imply
that two lines are to be read but, since blank node entries are
ignored, the first line might contain only 6 entries and the
second, 4, in which case the total number of nodes entered is
10. If, however, you had entered 10 in columns 11-15 only one
line and therefore 6 nodes would have been read.

Generally speaking data prepared under the “fixed column”

57
 rules will also be correctly read under free format provided that
there are no 5-digit node numbers which “run into one another”.

(7) If Col 6 = 'T' and the nodes list is A… Z then a second route is
assumed with node list Z… A; i.e., the reverse direction. If
however col 6 = ‘R’ then only one route is assumed but one
whose nodes are Z… A.

The R option allows one to code a 2-way route which differs

marginally in the two directions. Thus if the “out” direction is
A… IJL…Z and the "in" direction is Z… LKI… A then one may
code it using R as A… IKL… Z; i.e., the same as the out
direction apart from one node.

(8) If either EZBUS or FOZZY is TRUE then a complete “dump” of the

route definitions with every node included in fixed columns is
obtainable as an output file ‘network.bus’ if the parameter
BUSKER is set to .TRUE.

(9) If a single bus routes uses more than 20 records any records beyond
the 20th are ignored unless EZBUS = T. In that case the
program attempts to “compress” the input records by merging
together very short records which contain, e.g., only 1 or 2
nodes into single records. This is not (yet) possible with
EZBUS = F since the data compression ignores any fixed
column conventions.

58
6.9.3 Bus Companies

Multiple sets of route records initiated by a 66666 and terminated by a

99999 may appear and the routes within each set are referred to as being
members of a specific “bus company”. Note that this term need not
have anything to do with ownership or organisation; the different sets
may be used, for example, to distinguish double-decker, single deck and
mini buses. Output bus statistics are presented both “in toto” and
disaggregated by company.

Each bus company may have a specific value of the BUSPCU factor
input under &PARAM, see 6.3.3, as indicated by a subscript. Thus
BUSPCU (2) = 1.5 would assign a pcu factor to bus company 2. Unless
otherwise set an input value of BUSPCU (or its default unsubscripted)
applies to all companies.

Each “company” may be assigned an alpha-numeric title by including it

after column 5 on the 66666 record and to a particular vehicle class
(5.8.2) by IBUSVC( ).

6.9.4 “Other” Routes

It is possible to define routes for purposes other than defining bus flows,
for example to define a standard route used by moving car observers so
as to facilitate comparisons with modelled travel times post assignment.
Such routes are defined in the normal way but with a frequency equal to
zero.

Note that the term “bus company” also applies to sets of pure routes, i.e.
those with frequency zero. It would seem sensible for the user to
include non-bus routes as a separate “company” within a distinct 66666
block.

59
6.9.5 Route Timing Points

A “timing point” is defined to be an input time (in seconds) to travel from

the start of a route to a particular node in that route. The precise
definition of where the timing point is taken is of course up to the user
but it is recommended that they represent the time to cross the stop line
as opposed to the time to reach the back of the queue. They would
therefore include any delayed time at that intersection. Their application
for validation studies is described in 11.7.2.

Timing points are entered as integer values enclosed in brackets after the
node to which they refer appears. They may only be entered when in
“free format mode”, i.e. EZBUS = T. Thus the node sequence

52 54 55(72) 56……

indicates that the time to reach node 55 is 72 seconds. Note that not all
nodes need to have timing points and that it is not valid to associate one
with the first node in a sequence (which, by definition, is zero). Spaces
between the node number and ( or within ( ) are ignored.

Timing points are recorded on the .uf* files as part of the route definitions
and may be analysed later; see 11.7.2.

In addition a second input value within brackets indicates the “range” of

observed timing points. Thus

52 54 55 (72, 16) 56 …

would imply 72 + 16 seconds to reach node 55. If the second figure is

omitted it is taken as zero.

60
6.10 Counts of Link and/or Turning Volumes

Specified values of volumes on certain links and/or turns may be input as

follows, preceded by a 7 in column 1 and terminated by 99999 in
columns 1 to 5:

Cols. 1 -5 The A-node, A

Cols. 6 - 10 The B-node, B
Cols. 11 - 15 The C-node, C (blank or 0 in the case of a link)
Cols. 16 - 20 The first specified volume in pcus per hour.
Cols. 21 - 25 The second volume ...
Cols. 26 - 30 up to MCCS volumes.

NOTES:

(1) Unlike other data input sections the ‘77777’ initialisation record
may be repeated more than once, so that more than one “set” of
counted links may be defined. Each set commences with a
‘77777’ card and is terminated by a ‘99999’ card.

(2) Each set of counts is identified by consecutive numbers 1, 2,

3 ... which may be referred to within subsequent programs.
Thus a particular set of counts might be associated with a
particular “screen line” or cordon. Note the same link/turn may
not occur in different count sets; multiple values must be
handled using MCCS.

(3) In addition an informative title may optionally be included on

the 77777 record following the 7's giving, e.g., a screen line
name to be associated with the count set to follow.

(4) Turn volumes as specified by nodes A-B-C may only be defined

for turns within the simulation network; links specified by A-B
may exist in either the simulation or buffer networks.

(5) Volumes on centroid connectors may not be defined.

(6) Counts on simulation links should refer to the “actual mid-link”

flows - see Section 15.16.

61
 (7) It is generally assumed that any counts input here refer to
TOTAL vehicle flows, although in certain circumstances
elsewhere in the Suite flows for a particular class of vehicles
(e.g., cars, HGV’s, etc.) are required; see, for example, Section
13.4. The MCCS different set of counts might therefore be used
to define flows by vehicle class. Alternatively the program-
specific flows may need to be input separately to that particular
program.

(8) The count field MAY be left blank (or set to zero) if the count
records are being used solely to define a set of links for later
analysis. Zero-count records are ignored with certain
applications, e.g., a PIJA analysis for input to SATME2.

(9) MCCS is specified under &PARAM (6.3.2) and by default is 1.

Values of MCCS>1 might be used to represent, e.g., multiple
counts on the same links or counts for different user or vehicle
classes.

62
6.11 Generalised Costs and/or Matrix Weights for Multiple User Classes

This data section, which is mandatory for NOMADS>1, defines for each
user class:

i) The associated vehicle class (see 5.8);

ii)The associated “level” within the trip matrix (see 7.3.2.1);
iii)
Weights or factors to be applied to trip matrices;
iv)Its generalised costs (see 7.3.2.2), i.e. the criteria which
determines its “minimum cost” paths in the assignment stage;
v) User-class specific values of SUET.

These are set by a series of records preceded by an 8 in column 1 and

terminated by 99999 in columns 1 to 5, formatted as follows:

Cols. Description

1-5 User class number (in the range 1 to NOMADS)

6-7 The vehicle class for this user class (see 5.8)
8 -10 Number of the “stacked” matrix level which contains the
trips for this user class (see 7.3.2.1).
11 -15 Factor by which the above trip matrix is to be multiplied
in the assignment stage; see 7.3.2.1 and note (9) below.
16 -20 Value of time in pence per minute (N.B. Decimal point in
Column 18)
21 -25 Value of distance in pence per kilometre (N.B. Decimal
point in Column 23)
26 -30 Value associated with first extra data field input on buffer
link data records in units of pence per “KNOB unit”.
Decimal in column 28 (F5.2). See note (5).
31 -35 Ditto for the second data field, etc., etc.
and/or
26 -30
User-class SUET value with a decimal in column 28
(F5.2). See note (6).

NOTES:

(1) From SATURN 9.4 the 88888 section is mandatory under multiple
user classes, i.e. NOMADS>1. Previously it was optional but it
does not seem to make much sense to have multiple user classes if
they all share the same trip matrix and cost definitions.

63
 (2) This data section is not normally required in the “standard” case of
a single user class UNLESS some of the extra (KNOBS) link data
are used to define costs. Parameters PPM and PPK fully specify
generalised cost.

(3) For further details on all the above inputs please see Section 7.3.
Annotated examples are given in Section 6.14 below.

(4) The following default values apply to all user classes not explicitly
defined on these records:

(a) Vehicle class 1;

(b) Stacked matrix level 1;
(c) Factored by 1.00;
(d) Pence per minute equal to PPM as defined under the
&PARAM input or by default;
(e) Pence per kilometre similarly defined by PPK;
(f) Global value of SUET (6.3.3).

(5) Equally if columns 16 onwards are left blank, i.e., if there is no cost
definition provided, the default PPM and PPK values are assumed
to apply to this user class.

(6) If, say, the first KNOB field were in units of seconds, then the
weighting value defined in columns 26-30 would be in units of
pence/second. If it were in units of pence already, e.g., it were
being used to represent link charges, then its weighting factor would
simply be 1.0. In either case the KNOB field is being treated only
as a contributor to the total generalised cost and would not be
interpreted explicitly as a time or charge in terms of, e.g., total
summary tables. See 7.11.2.

(7) If however the KNOB data field is intended to represent a monetary

charge explicitly such that it is both included in the definition of
generalised cost and is to be included in the summary tables of total
revenue etc. then it is necessary to include either a $ or £ symbol
(the $ may be less keyboard sensitive) somewhere within the 5
columns. Thus $1.0 indicates that a KNOB field represents a charge
in units of pence, $2.0 would indicate that the field is in pence but
that particular user class, say, pays twice the basic toll. A $ or £ on
its own is equivalent to an implied weight of 1.0 as default. See
20.3.

(8) A user-class specific value of the stochastic assignment variable

SUET (see 7.3.3) may also be set on this record in the final 5
columns following the last KNOBS weight. If - normally - KNOBS

64
 = 0 then this will be in columns 26 - 30 with a decimal in column 28
(Format F5.2).

(9) We refer here to the warning at the end of 7.3.2.1: use factors
different from 1.0 with caution! For example, if you intend to carry
out elastic multiple user class assignment (7.9) use one stacked level
per user class from the network build stage.

*******************************************************
N.B. The full data file must be terminated by a 9 in column 1
- or 99999 in columns 1 -5. Thus the final TWO records
both must contain 9 or 99999, the first to terminate the
last data section and the second to terminate all data.
*******************************************************

65
6.12 Fatal Errors and NAFF UFN Files

Within SATNET there are two levels of “fatal” errors, full and semi-fatal
error. See 2.9. Thus a semi-fatal error is one which would prevent the
assignment-simulation stages in SATALL from running properly but
would not prevent a network map description being created which would
be sufficient for P1X to display. A (full) fatal error prevents both
SATALL and P1X from running properly.

An output .ufn file from SATNET which contains some semi-fatal but no
fatal errors is referred to as a NAFF file - Not Assignment Fully Fit - and
will be rejected by SATALL and most other programs apart from P1X.
The intention is that the editing facilities within P1X (see Section 18)
may then be used to correct the semi-fatal errors by producing a
corrected .dat file.

Full fatal errors, on the other hand, need to be corrected by manually

editing the .dat file. They may be relatively trivial, e.g. a letter appears
where numerical input is required and must be changed by the user, or
they be sufficiently complex that not even the deductive abilities of
SATNET can work out what the user is asking for.

Note that semi-fatal errors in SATNET will be referred to as fatal errors

within P1X; the (full) fatal errors will, as explained above, never manage
to get that far.

Semi-fatal errors and NAFF files were first included in SATURN 10.1.

66
6.13 Extra Input Network File (the X-File)

6.13.1General Principles

The use of an extra input data file to specify additional network

information was first introduced in SATURN 9.4 to get over problems
associated with “congestion” in the existing network data file formats
where basically there were virtually no spare fields to add additional
data items.

In particular the X-file is used to define certain parameters such as TAX

or GAP at a more disaggregate level, for example using an X-file allows
the user to set link-specific values of TAX as opposed to a single
universal value (6.3.3). In addition extra link capacity indices may be
defined.

To define an extra file the user must first specify a file name using the
namelist parameter name XFILE under &PARAM (6.3.4) in the main
network file; e.g.

XFILE = ‘netplus.dat’

X-files consist of (up to) four data sections.

1. A set of namelist parameters.

2. Node-based data contained between 11111 and 99999 delimiters
following standard SATURN conventions.
3. Link-based data under 22222.
4. Turn-based data under 33333.

Of these the namelist records are mandatory and the three data sections
are optional depending on parameters set under namelist. (And in fact at
the time of writing there are no options which use the 11111 node
records but they will no doubt appear in time.)

6.13.2X-File Namelist Parameters

The following variables, all INTEGER, may be defined under the

namelist title &PARAM:

NFTAX The position of the TAX data on the link records. (0, 1, 2…)
Default - 0

NFRBKS The position of the RBKS data on the link records. (0, 1,
2…); See 8.7.2.

67
 Default - 0

NFCI The position of the capacity index data on the link records.
(0, 1, 2…)
Default - 0

NFGAP The position of the GAP data on the turn records. (0 or 1)

Default - 0

6.13.3X-File Node Records

These appear as 11111 records. At the moment however they are

unused.

6.13.4X-File Link Records

These appear as 2222 records provided one or more of the parameters

NFTAX, NFRBKS and NFCI have been defined. The records are
formatted as followed.

Cols. 1 - 5 The A-node, A

6 - 10The B-node, B
16 - 80Data items in “free format”.

The number and order of the data items per link are determined by the
numerical values of NFTAX etc. Thus if NFTAX = 1, NFRBKS = 0 and
NFCI = 2 this implies that the first data item is a TAX value and the
second is a capacity index (CI); RBKS values are not used.

Since the data is in free format it may appear in any columns (although
the use of fixed columns in widths of either 5 or 10 is highly
recommended) and may be real or integer (with or without a decimal).
(Although indices should logically be integers.) Multiple entries must be
separated by at least one blank column.

N.B If DUTCH = T then the A-node and B-node entries occupy 10

columns, not 5, as is standard; see 15.20. The data items start in column
31.

68
6.13.5X-File Turn Records

These appear as 33333 records provided that NFGAP have been

defined. The records are formatted as followed.

Cols. 1 - 5 The A-node, A

6 - 10The B-node, B
11 - 15The C-node, C
16 - 80Data items in “free format”.

As above the number and order of the data items per link are determined
by the numerical values of NFTAX etc although at the moment only
turn-specific GAP values may be set in this way so that the only relevant
parameter is NFGAP which can only take the value 1 (unless of course it
is zero and no turn GAP values are on the X-file).

Note that turn-specific GAP values only apply to traffic signals and
priority junctions, not to roundabouts where GAP’s are defined at the
node level only.

Since the data is in free format it may appear in any columns (although
the use of fixed columns in widths of either 5 or 10 is highly
recommended) and may be real or integer (with or without a decimal).

N.B As with link records above, if DUTCH = T then the A-, B- and C-
nodes occupy 10 columns each, not 5, as is standard; see 15.20. The
data items start in column 31.

69
6.14 Specimen File

Various comments are given on the right hand side below, commencing
with a *.
&OPTION
&END
SATURNVILLE CITY CENTRE (18/1/80)
&PARAM
MASL=6,
NITS=2,
LIST=T,
NOMADS=3,
KNOBS=1, &END
11111
1 3 3 2 63
58 3 0 140 1870 1 1 3900 1 3
2 2 9 82 3400 1 2 0 0 0
26 3 17 150 3000F 1 2 1500 3 3
24 7 6 58 2 58 26 26 58
36 7 6 2 26 2 58 26 58
2 3 1
1 2 9 82 2500 1 2 1600X 2 2
3 3 27 248 2400 1 2 3000 2 3
29 1 20 130 900G 1 1 1600G 1 1

(Remainder of simulation network data)

99999 * Terminates simulation link data

22222 * Commences simulation C.C data
1 59 45
2 60 46
3 61 62
4 63 49 49 63

(Remainder of simulation centroid connector data)

99999
33333
3 2 28 56 2500 1 100 3.1
1978.00 * Extra (KNOB) data
29 2 21 42 1250 2 90
1983.00 * field, presumably
2 3 28 56 3750 2 100 3.1
1983.00 * some sort of date
C 2 59
9999.00 * with a default of
C 3 60
9999.00 * 9999 for centroid
C 4 61
9999.00 * connectors

(Remainder of the buffer network/link data)

99999
44444 * Banned links/turns
4 5 -1 0 30 * Link banned to UC 1, open to UC 2,
* 30 seconds penalty to UC 3
34 6 0 -2 * Open to UC 1 but banned to 2 and
3.
31 32 0 -1 0 * Banned to UC 2 only
46 51 50 10 -2 * 10 second penalty to UC 1, banned
* turn for classes 2 and 3.
16 17 18 -2 * Banned turn for all UC - therefore
* presumably a bus-only turn.
99999
55555 * Co-ordinates
1 17 53

70
 2 17 62 * Node 2 (either simulation or
buffer)
* co-ordinates
C 24 36 48 * Zone 24 co-ordinates
C 20 39 29

(Remainder of co-ordinates)

99999
66666
400 11 7 66 12 13 14 15 16 17
401 3 7 18 45 53 52 31 32 33
500 7 9 18 17 16 15 14 41 13 12 66
600 8 9 66 12 13 14 15 16 17 18 19
601 8 10 25 26 24 23 22 21 20 19 18 17

(Remainder of bus route data)

99999
77777 * Link and turn observed flows
1 58 1252 * Link volume (N.B. uni-directional)
58 1 779 * “ ” (in the opposite
direction)
45 53 52 826 * Turning volume
99999
88888 * Matrix and generalised cost
definitions
* for each user class (UC):
1 1 0.20 1.00 1.00 * UC 1 forms 20% of matrix level 1
* and defines cost = 1.0*time + 1.0*dist
2 1 0.40 0.00 1.00 * UC 2 forms 40% of matrix level 1
* and is distance minimizing (cost =
dist)
3 1 0.40 1.00 3.00 * UC 3 forms 40% as well and defines
* cost = time + 3.0*dist
99999
99999 * N.B. 2 99999 records to end data file

71
6.15 FIFO – Options for Repeated Data Input

It is possible for various inputs to appear more than once, either within
the same data section or, alternatively, within two different data sections.
In such cases it is necessary to decide which data entry to accept as
definitive. The Namelist parameter FIFO (“First In, First Out”) is
instrumental in such decisions: if FIFO = T then the first entry is rejected
and the last entry used, and vice-versa if FIFO = F.

The problem occurs in the following situations:

(1) X,Y co-ordinates are repeated for the same node within the 55555
data set.

(2) Speed-flow data is coded for a simulation link leading into an

external simulation node coded within the 11111 data records but an
entry for the same link subsequently occurs within the 33333 buffer
data (and which would normally be used to define a speed-flow curve
for that link). See 6.4.12.

(3) Link capacity indices may be defined either on simulation link speed-
flow records, on buffer links or on an X-file.

For example, if the same node appears twice (or more) under 55555 with different
co-ordinates each time, then if FIFO = T the second (last) set will be used; if FIFO
= F, the first record will be used. Clearly if the co-ordinates are the same it does
not matter too much which one is used, although there may be problems with
editing X,Y co-ordinates since only one record (not sure which!) will be updated.

One situation where FIFO is not used is that where a default speed-flow record for
the same capacity index in the 33333 data appears more than once; the first record
is always used.

In addition the rules have been changed in version 10.5 such that case (2) above is
no longer controlled by FIFO. Thus the 11111 data is always used in preference to
the 33333 data, on the assumption that if a user has gone to the bother of explicitly
adding an extra data line under 11111 they must definitely want that data to be
used.

It is strongly recommended that all situations where FIFO is applied (or not
applied as in the previous two cases) are checked by the user and the redundant
data removed. Check your .lpn for occurrences of FIFO.

72
6.16 SATNET Files

Channel Remarks

1 An output UFN file suitable for input to SATALL.

(Mandatory)

2 An input UFS file containing data from a previous run to

be used for updating. (Optional - UPDATE = T)

5 A “DAT” file containing the control parameters and

network data; see 6.1 to 6.11.
(Mandatory)

6 An output LPN line printer file. (Mandatory)

9 An input UFS file containing pre-loaded flows; see 15.5

(Optional - PLOD = T)

15/14 Terminal (output only)

(Optional - MODET ne 0)

17 File “SATTIT.DAT” which contains default array names

for the various data records stored on the output UFN
file.
(Optional - SATTIT = T)

19 A scratch file used to input GIS/BMP/UNION files as

required.
(Optional -)

20 A scratch UFX file used for both input and output.

(Optional - UPDATE or PASSQ = T or a buffer network
included)

21 A text file used to input supplementary KNOBS data.

(Optional -)

22 A scratch UFX file used for both input and output.

(Mandatory)

23 The input “X-file”; see 6.13

(Optional)

24 An input “PS” file - see Section 15.2.3

73
 (Optional)

27 An input UFS file containing data from a previous run to

be used under PASSQ. (Optional - PASSQ = T)

K:\…\dvv\saturn99\sect-6
Version: 12 February 2019

74