Section 6

SATURN MANUAL (V11.
3)
Preparation of a Network Data File
6. Preparation of a Network Data File

INTRODUCTION
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).
5120257 / Apr 15 6-1

Section 6
SATURN MANUAL (V11.3)
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.
FIXED COLUMN CONVENTIONS

Note that most of the data segments follow “fixed column conventions” as
described in section 2.8.1 but that greater flexibility as regards the number of
decimal points and/or range of values for the input of “real” variables is available;
see 2.8.3.
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.
Alternatively extra data may be input from a “KNOBS file” which an external text
file providing various forms of link-based data, e.g., tolls. See Sections 6.6,15.14
and 20.3.
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).
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.
* Each "line" of the input file is referred to as a "record".
5120257 / Apr 15 6-2

Section 6
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 parameters may be defined by &OPTION; the first eight of which are
all LOGICAL and default to .FALSE., the last set are all character variables
(mostly file names) 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. N.B. If you wish to set WSTART
= T then UPDATE should also be set to T. See Sections 15.3 and 22.3.
PASSQ .TRUE. if queues are to be passed over from a previous time period. See
Section 17.3.
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.
PLFF3 If .TRUE. 3 fields (A, B and C with C = 0) are required to define a link as
opposed to a turn for a free format pre-load data file. See Section 15.5.4.
WSTART If .TRUE. the assignment uses a “Warm Start” on its first assignment. N.B.
If WSTART = T then UPDATE should also = T. See Sections 21.3 and
22.3.
DIADEM If .TRUE. and the file named under UPFILE does not exist then setting
either UPDATE or WSTART to T does not result in a semi-fatal error. See
15.51.
CASINI If .TRUE. the internal CASSINI steps to over-ride various settings within
SATNET are invoked. See 15.54 and 15.54.6.1 for a full list of the
Namelist variables which may be over-written. (N.B. the variable name
CASINI has only a single S in order to confirm with the rule that all
namelist variables have to have 6 or fewer characters.)
UPFILE The name of the network (.ufs) file which is to be used under the UPDATE
and/or WSTART options. See 15.3 and 21.3.
PQFILE The name of the network (.ufs) file which is to be used under the PASSQ
option. See 17.3.
FILPLD The name of the network (.ufs) file which is to be “pre-loaded”. See 15.5
FILERL The name of the input .ERL file used to monitor errors. See 15.58.
FILCAS The name of the CASSINI Control file defining the convergence strategy
to be applied. See 15.54.6.
FILGAP The name of the ASCII CSV file reporting the convergence of the demand
model. See 15.54.6
CASTXT The CASSINI file which specifies the type of demand model used and the
5120257 / Apr 15 6-3

Section 6
file format (and other operations) that CASSINI will expect. See 15.54.6.
Thus the OPTION records might be specified by the following set of records which
explicitly sets UPDATE to .TRUE., PASSQ to .FALSE. 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
Note that both UPDATE and PASSQ allow initial estimates of the cost-flow curves
to be extracted from a previous run; see 15.3. However if both are set to T the
data is taken from UPFILE in preference to PQFILE. UPFILE and PQFILE are
totally separate files, either/both needs to be defined as required by
UPDATE/PASSQ and they cannot both be the same file.
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 (see
11.8.4.10). 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.
5120257 / Apr 15 6-4

Section 6
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 (SUET, 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
INTEGER: LCY, LTP, MASL, NITA, 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 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.
AUTNUC If .TRUE. values of NUC are set automatically for certain junctions. See
15.15.2
5120257 / Apr 15 6-5

Section 6
Default: .TRUE. (.FALSE. prior to 10.9)

AUTOK If .TRUE. any “Kombi” averaging of flows during the assignment–
simulation loops is controlled AUTOmatically. See Section 9.3.1.
AUTONA If .TRUE. “optimum” values of NITA and/or UNCRTS are calculated at
each separate assignment within SATALL. See Section 9.5.4.
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.
BANKER If .TRUE. an ascii (text) file containing a full set of banned turns is output
to a file network.BNT.
Default: .FALSE.
BB109 If .TRUE. the new rules for blocking back as introduced in release 10.9
(see 8.5.5 and 8.5.6) are invoked
Default: .TRUE. (was .FALSE. but recommended .TRUE. prior to 11.2)
BEAKER If .TRUE. any capacity index set for a simulation link (via data input
under the 33333 records 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.
BYGRUP If .TRUE. disaggregate summary statistics are calculated in SATALL
using traffic boroughs or “groups” (e.g., under TFL or FILN2G) rather
than capacity indices. See 11.11.4 and 15.59.2.
Default: .FALSE.
BYCAPI If .TRUE. disaggregate summary statistics are calculated in SATALL
based on link capacity indices (if any) but only if BYGRUP = F (which
takes precedence). See 11.11.4 and 15.59.2.
Default: .FALSE.
CLIMAX(n) If .TRUE. for user class n any input values of CLICKS represent a fixed
maximum speed rather than a fixed time penalty. See 15.47.3
Default: .FALSE.
5120257 / Apr 15 6-6

Section 6
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.
CROWCC If .TRUE. buffer centroid connectors with an input distance of zero are
replaced by a crow-fly distance. See 15.10.3.
Default: .FALSE.
DCSV If .TRUE. default speed-flow curves under 33333 (i.e., those with a D in
column 1; see 6.6 and 15.9.5) may be defined as free format (CSV)
rather than fixed columns.
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.
DOUBLE If .TRUE. and TOPUP = T certain rules for “over-writing” data apply. See
6.15.3.
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 .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 499. By
convention ERRYES(I:J) = T sets all values in the range I to J to T. See
Sections 2.9 and 6.12.2.
Default: .TRUE.
ERRNO(I) If ERRNO(I) = T then Warning/Serious Warning/Non-fatal Error I is
upgraded to a Semi-Fatal error. See 6.12.3.
Default: .FALSE.
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 6, Section 4.3.
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.
5120257 / Apr 15 6-7

Section 6
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 6.4.3.5 and 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 55555 records (i.e. X,
Y co-ordinates) are input as “free format”; see 6.8.
Default: .FALSE. (but recommended TRUE)
FREE77 If .TRUE. counts under 77777 are read as free format. See note 13),
6.10.
Default: .FALSE.
FREE88 If .TRUE. PPM etc. weights per user class under 88888 are read in a
free format as opposed to fixed columns. See 6.11.
Default: .FALSE.
FREEKN If .TRUE. the link data contained in an external KNOBS data file FILKNB
are entirely in free format, i.e., node specification as well as data. See
15.14.5.
Default: .FALSE.
FUNNEL If .TRUE. turns coded with a single Priority Marker M are assumed to
“funnel” into a single exit lane with their “major” turn. See 6.4.2.3 and
8.8.4.
Default: .TRUE.
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 .FALSE. U-turns are allowed at external simulation nodes; if .TRUE.
they are (virtually) banned. See 18.9.1. N.B. Earlier versions of the
documentation had the T/F definitions confused and reversed; see
Appendix E.4
Default: .TRUE.
KERMIT (KilomEtRes and MInuTes!)
If .TRUE. the travel distances and times input on buffer link records are
5120257 / Apr 15 6-8

Section 6
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
(V>C) they are linear and below (V<C), “power law”. If KINKY =
.FALSE. they are a power law throughout. USE WITH CAUTION! 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.
LCR108 If .TRUE. the “choke factors” applied to turn capacities are calculated in
a better way, introduced in 10.8, to remove possible discontinuities. See
8.4.4 and note 3, App. D.17.5.
Default: .TRUE.
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.
MINDER If .TRUE. (and FOZZIE = T) routes are interpolated using a minimum
distance algorithm if the “directional” method fails. See 15.18.
Default: .FALSE.
MONACO If .TRUE. the number of pcus which are required to “sit at the head of a
blocked queue” is set to TAX + 1. See 6.4.9.5 and 8.2.5.1.
M108 If .TRUE. the rules for M Priority Markers are per Release 10.8. See
6.4.2.3 and 8.8.4.5.
Default: .TRUE.
MULTIC If .TRUE., SATURN will undertake the path-building and loading using
the MULTI-Core version of the assignment algorithm (if available). See
15.53.4.1.
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 (or in KNOB
files, 15.14.5.1) in order to identify a zone; see 5.1.6 and note 13) in 6.6.
5120257 / Apr 15 6-9

Section 6
Default: .FALSE.
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. (In fact, post
10.9, the default value of T is always taken,)
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. (Recommended .TRUE.)
RB106 New rules for the simulation of roundabouts as introduced in 10.6 are
applied; see 8.7.3. In fact, post 10.9, the default value of T is always
taken,)
Default: .TRUE. (.FALSE. pre 10.8)
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. (Recommended .TRUE.)
REFFUB If .TRUE. calculate buffer turn (geddit?) flows post assignment (but only
if SAVEIT = T)
Default: .FALSE.
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
8.4.3 and 7.1.3.
5120257 / Apr 15 6-10

Section 6
Default: .FALSE. (Use .TRUE. with caution; see 7.1.3)

RTP108 If .TRUE. random delays (LRTP > 0) are set by “estuary” rather than by
“river”. See 8.6.3.
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.1.
Default: .TRUE.
SAVUFO If .TRUE. (and SAVEIT = T as well) a .UFO file describing the assigned
O-D routes is generated under Frank-Wolfe assignment. See Sections
22.5.3 and 22.5.7.
Default: .FALSE.
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 purely 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.1.
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.
SIM109 Choice of the original numerical ordering of nodes for simulation (F) or
the newer topological ordering (T). See 8.3.4.
Default: .TRUE.
SIM111 New simulation-based options introduced in release 11.1 are enabled;
e.g. random queues (8.6.5).
Default: .FALSE.
SOWHAT If .TRUE. a system optimal assignment is carried out as opposed to a
user optimal; See 7.11.9.
Default: .FALSE.
SPARSE Controls the system whereby SATALL stores internal trip matrices.
SPARSE = T is more efficient if more than 50% of the cells in the trip
5120257 / Apr 15 6-11

Section 6
matrix to be assigned are zero; else F is preferable. See 7.11.12.

Default: .TRUE.
SPARTA If .TRUE. use the PARTAN option within multiple user class Wardrop
SAVEIT assignment; see 7.11.7 and 15.23.4.
Default: .FALSE. (but recommended .TRUE.)
SPEEDS If .TRUE. travel speeds (in kph) rather than travel times (in seconds) are
input on the (simulation) link records. (N.B. SPEEDS does not refer at
all to buffer records which can contain either speeds or times.)
Default: .FALSE.
SPIDER If .TRUE. create and use an “aggregated network” or “spider web”
representation of the assignment network. See 15.56.
Default: .FALSE.
STOLL If .TRUE. road charges (tolls) are set stochastically. See 20.6
Default: .FALSE.
STUART If .TRUE. use Stuart Porter’s suggested formula for the “Xf” factor in link
weaving; see 15.40.3.
Default: .FALSE.
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.
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.
TFL If .TRUE. the rules for hierarchical node and zone numbers as used in
TfL networks are assumed to operate. E.g., the first two digits in a 5-digit
zone or node number give its traffic borough. See 5.1.7, 6.8,10.5.2 and
11.11.4.
Default: .FALSE.
TOPUP If .TRUE. a node coded within one 11111 data segment will “over-write”
one within a separate data segment which follows. See 6.15.2.
Default: .FALSE.
UFC109 If .TRUE. the output .UFC files are constructed (a) exactly from the
assignment rather than from an extra SAVEIT assignment and (b), for
multiple user classes, in shorter files. See 15.23.3.
Default: .TRUE. (was .FALSE. but recommended .TRUE. prior to 11.2)
UFC111 Replaces function b) above for UFC109; i.e., if T creates shorter time-
only .UFC files for multiple user classes independent of the value of
UFC109. See 15.23.3.2.
5120257 / Apr 15 6-12

Section 6
Default: .TRUE.
UNIQUE If .TRUE. only a single queue is allowed to form on a set of over-
capacity buffer links which are in series. See 15.48
Default: .FALSE.
UPBUS If .TRUE. then bus routes start/end at the top/bottom and of simulation
links. See 6.9.2 and 11.7.2.1.
Default: .FALSE.
USEUFO If .TRUE. analysis programs such as P1X, SATCH and/or SATLOOK
use .UFO files in preference to .UFC by default (if they exist – see
SAVUFO above). See 22.5.3.
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.
WRIGHT If .TRUE. certain warnings etc. are upgraded to semi-fatal errors. See
6.12.2.
Default: .TRUE.
ZILCH If .TRUE. no trip matrix is assigned prior to carrying out a one-off
simulation. See 9.12.13
Default: .FALSE.
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
IEPSG Defines the coordinate system upon which the SATURN coordinate
system is based. The EPSG code is an internationally accepted
standard identifying the system, and for British Ordnance Survey
National Grid at metre level is 27700. See 6.8.
Default: 27700
IFRL As IFCC but for the “real” buffer links as opposed to the centroid
connectors. See Note 3 under 6.6.
5120257 / Apr 15 6-13

Section 6
Default: 1
INKS_S The number of incremental assignment steps to be applied at the start of
a SAVEIT assignment as opposed to a single all-or-nothing. See
7.11.13, 15.23.2 and 15.57.6.
Default: 0
IPERT Control of perturbation/Warm Start mode under path-based and OBA
assignment. 1 – Perturbation used; 0 – Not. See 21.3 and 21.7.
Default: 0
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 less
than “PCNEAR” percent (default 1%) from one assignment to the next.
See also RSTOP which now effectively replaces ISTOP: any integer
values of ISTOP which are explicitly input are automatically converted to
real values of RSTOP. Section 9.1.2, 9.2.5 and 9.2.6.
Default: 98 % (Changed from 90% in 10.5 and 95% in 11.3)
IXSHFT Adjustment used in converting from SATURN coordinate system to
EPSG system. See 6.8.
Default: 0
IYSHFT Adjustment used in converting from SATURN coordinate system to
Default: 0
KANGA A “wild card” number used within bus routes to enable a route to exit
from one (coded) network node and re-enter at another node. See note
12, 6.9.2.
Default: 9999
KARL Maximum number of certain repeated error messages (e.g., coded
distances different from cow-fly distances) which are printed, after which
they are suppressed.
Default: 50
KDF(u) Choice of a cumulative density function under KOB = 3 for User Class u.
See 7.2.3.3.
Defaults: 1
KLUNK Choice of method for variable speeds under CLICKS with values 0, 1 or
2. See 15.47.2
Default: 0
KNOBS Number of extra data fields included on the buffer data records – see
Sections 6.6 and 15.14.
5120257 / Apr 15 6-14

Section 6
Default: 0
KOB “Kontrol of Burrell” – sets the type of random link cost distribution used
under SUE: 0 – Rectangular 1 – Normal 2 – Modified Normal 3 – Input
density function. See Section 7.2.3.1.
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
KONSTP “KONtrol of SToPping Criteria”. The stopping criteria for assignment –
simulation loops are based on either: ISTOP (KONSTP = 0); %GAP
value (1); CPU time (2); ISTOP and/or CPU (3); %GAP and/or CPU (4);
%GAP and ISTOP (5); %GAP or %ISTOP (6). See Section 9.2.3
Default: 5 (Changed from 0 in 11.3)
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 buffer links with speeds
KPHMAX 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.2 and 15.15.3.
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.1.
Default: 0 (But positive values are recommended, e.g., equal to LTP)
LTP Duration of the simulated time period (in minutes). See 8.1.2 and 8.4.5.
Default: 30 minutes.
MANOFF The signalised simulation node number used as the reference point for
all optimum offsets set by SATOFF. See 12.2.3.
Default: 0.
MASL Maximum number of assignment/simulation loops. See 9.1 and/or 9.2.3.
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
MASL_M The minimum number of assignment-simulation loops to be undertaken
5120257 / Apr 15 6-15

Section 6
within SATALL; see 9.2.3.

Default: 1
MAXDTP Maximum “transient” delay (in minutes) permitted for a simulated turn.
See 8.4.1.
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.
MAXSPA The maximum number of arms for an (aggregated) node to be further
aggregated under SPIDER = T. See 15.56.3.
Default: 15 (Was 30 prior to version 11.3.12, April 2015)
MAXZN Maximum number or ‘name’ used to define a zone. See 5.1.6.
Default: 500.
MCALG Algorithm used by multi-core assignments. See 15.53.4.1.

Default: 1
MCNUM The number of cores available on a multi-core processor. See 15.53.4.1.
Default: 0 (use all available cores)
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
MET METhod used for assignment: 0 – Link-based; 1 – Path-based; 2 – OBA.
See Section 21.
Default: 0
MINLSF/ Minimum/maximum expected lane saturation flows; Values outside
5120257 / Apr 15 6-16

Section 6
MAXLSF 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 (But recommended 5)
NFT “National Film Theatre” for really great old films. Set, e.g. NFT = 103 to
get release version 10.3. See 8.5.
Default: 108 (i.e. use the latest version)
NIPS Maximum number of signal optimisation “outer” loops in SATALL. See
9.12.2.
Default: 2
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.2 and 9.2.5.
NITA Maximum number of assignment iterations. See 7.1.5, 7.2.2 & 9.5.2.
Default: 20
NITA_C The maximum number of iterations stored in a .UFC file when UFC109 =
T. See 15.23.3
Default: 256
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 (But recommended as a small non-zero value)
NITA_M The minimum number of assignment iterations; see 7.1.5 and 9.5.1.
Default: 3 (or 1 under OBA)
5120257 / Apr 15 6-17

Section 6
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.4.
Default: 99
NITS_M The minimum number of simulation iterations. See 8.1.4 and 8.3.2
Default: 5
NITS Maximum number of simulation iterations. See 8.1.4 and 8.3.2.
Default: 20 (Upgraded from 10 in 10.9.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 Sections 6.4.2.7 and
15.7.1.
Default: 0. (For British rules of the road although there may be a strong
case for a default value of 1, even in the UK; see 15.7.1)
NUC Number of time-units into which the cycle is divided in the simulation;
global value (maximum value 25). See 8.1.2 and 15.15.2.
Default: 10 (Prior to 11.1 the default was 15.)
NUCJT(j) NUC value for simulation junction type j (e.g., 3 for signals). Maximum
125. See 15.15.2.
Defaults: all 0
NUCMIN Minimum number of time-units into which the cycle is divided in the
simulation (maximum value 25). See 8.1.2. Lower input values at
individual nodes 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.
5120257 / Apr 15 6-18

Section 6
Default: 0.5
AK_MIN Minimum value for averaging flows under AUTOK. See 9.3.2.
Default: 0.0 (i.e., does nothing although a value of 0.20 is tentatively
recommended)
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 default “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.1. Link-specific values may be set later; see 6.4.14
and/or 6.13.4.
Default: 1.0
BBKING Minimum queue/stack ratio at which blocking back is applied (Blocking
Back Kicks IN – Geddit?) See 8.5.6. (N.B. Only applied if BB109 = T.)
Default: 1.0
BCRP “Buffer Capacity Restraint Power” – used to define a default “power” for
speed-flow curves in the buffer network – See Sections 5.4 and 6.6, note
(4).
Default: 5.0
BETA(u) Elastic assignment elasticity parameter (for user class ‘u’) as used under
MCGILL = 1, 3 10 or 11. N.B. Units of inverse seconds. See 7.7.1 and
7.7.6.
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 App-V.
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
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
5120257 / Apr 15 6-19

Section 6
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
CLICKS(n) Maximum free-flow speed in KPH for user class n. See 15.47.
Defaults: 0.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 %
FLAREF The default number of PCUs which, by default, are able to queue in an
extra near-side (Filter) flared lane at either signals or priority junctions if
an F is coded in the lane field. See 6.4.9.3, 6.4.14 (for link-specific
inputs), and 8.2.6.
Default: 2.0
FLAREX The default number of PCUs which, by default, are able to queue in an
extra off-side flared (X-) lane at either signals or priority junctions if an F
is coded in the lane field. See 6.4.9.3, 6.4.14 (for link-specific inputs),
8.2.5.2 and 8.2.6.
Default: 2.0
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 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 (NB: historical default value)
5120257 / Apr 15 6-20

Section 6
GAPM As GAP but for merging turns.

GAPR As GAP but for entry onto roundabouts.
(N.B. See Section 15.22 for further details on how to set the GAP-
parameters rather than accepting the historical default values.)
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, 12.1.7
and 13.1.14.
Default: 1.0
PCNEAR Percentage change in flows judged to be “near” in successive
assignments. See 9.1.
Default: 1.0. (Changed from 5.0 in 11.3).
PMAX Maximum value of the power used in the simulation flow-delay curves.
See 8.4.2.
Default: 10.0 (Recommended smaller values, e.g., 5.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
QDMAX Maximum delay in seconds used by Q-turns. See Appendix Q.
Default: 226
QVCMIN Minimum V/C ratio at which delays are applied to Q-turns. See Appendix
Q.
Default: 0.75
RSTOP Used in the test for convergence of the assignment/simulation loops.
The loops stop automatically if RSTOP % of the link flows change by
less than “PCNEAR” percent (default 1%) from one assignment to the
next. See also ISTOP. Section 9.1.2, 9.2.5 and 9.2.6..
Default: 97.5 % (Changed from 94.5% in 11.3)).
SHADOW An assumed speed in kph for the “shadow network” assignment option;
see 7.11.10.
Default: 0.0
5120257 / Apr 15 6-21

Section 6
STPGAP Critical gap value (IN %) used to terminate assignment-simulation loops

when KONSTP = 1 or 5. See 9.2.3.
Default: 1.0 %
STPCPU Critical CPU time (in seconds) used to terminate assignment-simulation
loops when KONSTP = 2. See 9.2.3.
Default: 1,000 seconds
SUET(u) Used to define the range of link cost variation in SUE assignment for
(optionally) user class u – see Section 7.2.3.
Default: 0.2
TAX Default 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,
6.4.14 (for link-specific inputs) and 8.2.4.
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 and 9.2.3.
Default: 0.05 % (Changed from 0.20% in release 10.9)
VCPCU(v) The pcu value per vehicle in vehicle class v, or for all vehicles in the trip
matrix if unscripted. See 5.8 and 15.17.2.
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
W32D Minimum difference in distances on reverse directions on simulation
links to trigger Warning 32 (See Table 1, Appendix L)
Default: 0.001 (i.e., zero)
W32T Minimum relative difference in times on reverse directions on simulation
links to trigger Warning 32 (See Table 1, Appendix L)
Default: 0.10 (i.e., 10%)
W32KPH Minimum difference in speeds on reverse directions on simulation links
to trigger Warning 32 (See Table 1, Appendix L)
Default: 1.5 kph
5120257 / Apr 15 6-22

Section 6
XFSTOP Wardrop assignment stopping parameter for minimum step length. See
7.1.5.
Default: 0.05 %
XYFACT Adjustment used in converting from SATURN coordinate system to
Default: 1.0
XYUNIT Number of metres corresponding to an integer value of 1 as used to
define SATURN node/zone co-ordinates. See 6.8.
Default: 1.0
6.3.4 Character Parameters

Note that the alphanumeric values defined for all character parameters need to be
set inside two single apostrophes; e.g. XYFORM = ‘2F10.2’. Otherwise they will
not be recognised as Character Parameters and be rejected as invalid Namelist
entries. See Note 7, Appendix A.
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)
O
FILCGH The “file name” of the .ufm cost matrix c ij to be used in the “incremental”
distribution model (MCUBC = 1); 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
O
assignment c ij . 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 the .ufm matrix of frozen ij movements within elastic
assignment if ICING = T. See 7.5.6 and 7.12.3.
5120257 / Apr 15 6-23

Section 6

FILN2G The file name for a “N2G” file which defines “groups” (e.g., sectors, traffic
boroughs, etc.) for each network node. See 11.11.4.
FILPEN The file name of the .ufm matrix used to define link tolls by origin. (Not
yet available.)
Default: blank
FILKNB The file name used to define link KNOBS data. See 15.14.5.
Default: blank
FILBMP The name of the .bmp file/folder used to define a background display for
P1X plots. See 11.3.6 and 15.43.
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.
FILRGS The file name of an input .RGS file containing a set of signal timings
which will over-write those on the input .dat file. See 6.4.3.5 and
11.9.14.
ROADIJ The “file name” of the output .ufm matrix containing the elastic road trip
matrix under elastic assignment. See 7.12.3.
FILVSD The “file name” of the input text file containing CLICKS values
disaggregated by Capacity Index and Vehicle Class. See 15.47.2
FILN2G The “file name” of the input text file which associates a “group name”
(e.g., a traffic borough) with each network node. See 5.1.7
UCNAME(u) The text name to be associated with user class u (5.8.1).
VCNAME(v) The text name to be associated with vehicle class v (5.8.2).
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
fixed column data records - see Section 6.8.
Default: 2I5. (N.B. Not a particularly useful default – only still there for
historical compatibility – and only necessary if FREEXY = F, which is
5120257 / Apr 15 6-24
Section 6
itself not recommended either.)
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. etc.
6.4 Simulation Network: the ‘11111’ Records

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:
♦ Record type 1 - Node description (mandatory)
♦ 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 (2B) to describe link speed-flow
characteristics).
♦ 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 were 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 P1X (see 5.6, 11.9 and 18).
However some “fine tuning” using a text editor will probably still be needed
* Counter-clockwise under drive on the right.
5120257 / Apr 15 6-25

Section 6
6.4.1 Node Data Formats
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 (see 5.1.1):
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 permitted
16-20 JCIR Time to circle roundabout (in seconds)
(Roundabouts only)
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/GA Minimum gap in tenths of seconds for give-way turns at priority
PR (GAP) or roundabouts (+)
41-45 GAPM Minimum gap in tenths of seconds for merges(+).Generally left
blank - 6.4.10.
RECORD TYPE 2 - LINK AND TURN DATA

1-5 STACK Link stacking capacity (PCU) - 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 and/or extra link parameters are
required - see 6.4.12 and/or 6.4.14
12-15 LANES* Number of entry lanes (plus weave, flare and/or bus lane
indicators) for this link - see 6.4.9.1.
5120257 / Apr 15 6-26

Section 6
(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).
In addition (post 10.9) the five data columns following directly on from the last
possible set of turn data (e.g., columns 76-80 if there were 5 turns) may contain a
value for TAX for that link; see 6.4.14 for precise formatting conventions.
(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
and/or other parameters is inserted. This option is relatively rarely used for short
links in central area but may be extremely useful for modelling motorway-type
links. See 6.4.12 and 6.4.14 for how to include extra data such as flares on
record 2B.)
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
or (if SPEEDS = T) Link travel speed at capacity (in kph)
5120257 / Apr 15 6-27

Section 6
21-25 LCAPY Link capacity (pcu’s per hour)

29 S if speeds are used in 11-20, T if time; D if extra delays; if
blank then SPEEDS decides. See 6.4.12, 6.4.12.2 for D.
36-40 N The power ‘N’ used in the speed-flow curve with a decimal in
column 39 (by default – see 2.8.3)
43-45 INDEX A “Link Capacity Index” in the range 0-999 (where 0 or blank
implies a “non” index); see 5.1.9. The index may also be used
to define default speed-flow curves which replace the data in
columns 11-40; see 15.9.5.
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.
♦ 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
♦ 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
♦ STAGL and INTG (stage duration and inter-green) are normally input as
integer seconds but it also permissible to define them as real quantities
(i.e., 16.84 as opposed to 17) as long as the numbers fit within the
allocated column limits. See 2.8.3.
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:
5120257 / Apr 15 6-28

Section 6
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 downstream 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.
FURTHER NOTES:
6.4.2.1 Giveways (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.
Thus in the above figure if the 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
5120257 / Apr 15 6-29

Section 6
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 Opposed Right Turn (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.
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/phase. This allows for vehicles stacking in their reserved
lanes and discharging during the amber phase. See 8.2.4.
N.B. Post release 11.1 the above rule has been modified such that if an X-turn at
signals only appears in phases which are terminated by a stage in which the X-
turn is unopposed (e.g., by a late cut-off) then the extra allocation of TAX pcus is
not allocated. The rationale is that if the stacked vehicles are allowed to clear
during the late cut-off then there it will not be possible for additional traffic to stack
and clear at the end of the extra stage. (Further releases may further amend this
rule such that if, say, TAX = 3.0 and the final stage allows 2.0 PCUs then the
difference of 1.0 PCU will be allowed under TAX.) See 8.2.4.1.
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 Merge (M)
A “merging” turn coded M at a priority junction (only) 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 on the motorway. In addition,
it only needs to find a gap in a single (nearest) lane (see below for the choice-of-
lane rules).
5120257 / Apr 15 6-30

Section 6
Since an M turn only gives way to traffic in one lane of one movement it is less
restrictive than a G marker.
Merge markers may occur either on their own (a “single-M merge) or in pairs for
two turning movements from different junction arms (a “double-M” or Y-merge).
The distinction is explained in the next two sub-sections.
The detailed modelling of merges is discussed further in Sections 8.2.2, 8.8.3 and
8.8.4. Appendix M discusses some of the issues involved in modelling merges
while the Q-marker is closely related to merges on motorways (see Appendix Q)
SINGLE-M MERGES: DEFINITION OF THE “MAJOR” TURN

We consider here the situation where only one turning movement has been
assigned an M priority marker and the question of how to determine the
movement into which it merges. The most common example of this situation
would be that of a slip road – D-B in the diagram below – merging into a major
road A-B-C so that the turn D-B-C would be assigned a marker M.
The following rule is used to determine the “major” 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. Thus, in
the above diagram, D-B-C marked M is the first turn out of D-B and it merges
(“near-side”) with the second turn A-B-C out of link A-B.
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 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.
5120257 / Apr 15 6-31

Section 6
If, given the one-way roads in the above figure, the M-marker is on B-N-C then the
lane into which B-N-C would merge would be the inside lane on A-N. However, it
is possible to use an M-marker on B-N-C if B-N were two-way and there were a
left-hand turn A-N-B. In this situation the choice-of-lane rule is modified so that B-
N-C merges with the inside lane used by A-N-C. So if A-N-B had an exclusive
inside lane the merge would be with traffic in the second lane on A-N.
Prior to release 10.8 merges into outside lanes were NOT correctly recognised
and so the above configuration would have resulted in strange results. See Note
12 in Appendix E-4.
Y-MERGES (DOUBLE-M MERGES)

The merge facility can also be used to model “Y” junctions where two streams of
traffic with equal priority merge. For example, this might occur if two “equal”
motorways merge together, in which case the merge occurs between the nearside
lane of one and the offside lane of the other, both of which are assumed to
merge/funnel into a single exit lane. (Equal, in this sense, implies that neither
motorway can be assumed to be the “major” flow and that, say, both have equal
number of lanes. However the double-M may also be used with “unequal”
motorways, for example a single-lane ramp merging into a multi-lane motorway
where, at the point of merging, both flows have equal priority.)
In the diagram immediately above 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 and 8.8.4 for a more detailed discussion of how the lane choices and
capacities would be modelled in this situation. N.B. Y-merges, as explained in
8.8.3.2, 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.
FUNNELLING AND LATERAL MERGES (POST 10.8)

In physical terms it is possible to envisage of two extreme physical forms of
“merges”:
(1) The two lanes that merge “funnel” into a single lane which therefore restricts
the total number of vehicles which may enter from both streams;
5120257 / Apr 15 6-32

Section 6
(2) The merging operation is more a question of two parallel streams being
brought into lateral contact without any significant restriction on total exit flow.
This distinction – and possible consequences – are discussed in greater detail in
Section 8.8.4.
Thus, with a “funnel”, there is a definite presumption that (all) the traffic from the
turn marked with the M and the single lane of traffic from the “major” turn with
which it merges both exit the junction via the same single lane Into which they are
“squeezed” or “funnelled”. Thus, in the above example of a slip road onto a major
road, both the slip road traffic and the inner lane of the major road should exit onto
the inner lane. If not, e.g., if the M-turn has an exclusive exit lane, then an M
marker may not be appropriate.
The choice of two forms of options was first introduced in release version 10.8
Several parameters are available to distinguish between funnel and lateral
merges. Thus set the “global” &PARAM FUNNEL to T to set all merges to funnels
(default F). Alternatively the C priority modifier (see 6.4.2.6) defines a merge as a
lateral merge (C = “clear exit”) independent of FUNNEL. And, finally, setting M108
= F ignores the distinction totally and the modelling of merges reverts back to pre
10.8 calculations.
Finally, note that the choice may not be made purely and simply on the physical
configuration of the merge but on how the user wishes to model it. For example,
the capacity restriction effects of a funnel may also be modelled by creating a “Q-
node” or a “stopper node” immediately downstream of the merge point, in which
case defining the merge as a funnel could be effectively double-counting.
6.4.2.4 Filters at Signals (F)
Turns coded F at traffic signals “give way” (in the same way that G movements
give way) to traffic in their exit road (during those stages where there is other
traffic into the 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.
5120257 / Apr 15 6-33

Section 6
6.4.2.5 Weave Areas (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 at the same node. The “geometry” is illustrated below (based
on left hand drive).
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
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
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.
5120257 / Apr 15 6-34

Section 6
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
Weaving may also take place between two junctions, e.g., on a motorway, which
are separated by a finite distance; see Section 6.4.9.4 for coding inputs and
Section 15.40 - and 15.40.7 in particular - for a discussion of the differences (and
similarities) between the two methods. Note that both are indicated by a W marker
but in different locations.
6.4.2.6 Clear Exits [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 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 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).
In addition, post 10.8, they may also follow an M-marker to indicate that the turn
has a clear exit and does not “funnel”; see 6.4.2.3. Plus, post 10.9, they may also
follow a F priority marker at signals indicating that the filter turn has its own clear
exit lane and does not have to merge with or give-way to other traffic entering the
same link at the same time.
A further post 10.9 feature is that SATNET checks whether, given the number of
(downstream) lanes on an exit arm and the number of entry lanes used by turns
entering that arm, there appears to be available lanes for a clear exit. For
example, in the above diagram, there are two exit lanes to E but the turn W-E only
has one lane at its entry, suggesting that there is one lane available to S to enter
the exit to E. Had there been just one lane to E this would not be the case.
Warning 98 detects such instances and prints appropriate messages. N.B.
Warning 98 is only a suggestion, nothing more.
5120257 / Apr 15 6-35

Section 6
6.4.2.7 Hooks / Non-Hooks (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 (apart from Serious Warning 167 resulting).
Users should be made aware that situation (a), no interference, is preferable in
the sense that it makes overall convergence easier. Therefore, if the situation is
likely to occur at one or more junctions, it is worth checking that it has been
coded, e.g., by the use of markers X and D. Warning 97 prompts.
6.4.2.8 Hooked & Clear Exit Lanes (E)
This indicates that both the C and D modifiers apply, e.g. a hooked/unhooked
movement with a clear exit lane.
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).
5120257 / Apr 15 6-36

Section 6
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/or lower limits on the stage green times.
6.4.3.1 Continuous Green Movements
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 movements which are green in two
successive stages must be continuously green over both stages.
The same also applies, in general, to two successive greens with non-zero inter-
greens. For example the inter-green period might represent the gap between the
display of straight-ahead and left arrows in the first stage and of straight-ahead
and right arrows in the second, 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 certain 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) Similarly at junctions with only two arms (e.g., pedestrian crossings again)
but multiple stages all inter-green periods are red for all movements. This
allows for pedestrian signals to be “double-phased”.
(iii) Right turners which are coded with an X priority marker but are (unusually?)
green in every stage are assumed to be red during every (positive) inter-
green period.
(iv) If the inter-green time is coded by a negative number, in which case the
absolute value gives the true inter-green time. This facility is introduced to
deal with any possible ambiguities.
Criteria (ii) and (iii) were first introduced in release 10.6.
6.4.3.2 Amber Phases
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 or 2 seconds) of
the post-green amber phase by artificially extending the green phase.
6.4.3.3 Stage Times
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
5120257 / Apr 15 6-37

Section 6
assumption that they represent safety margins between successive signals.

Double cycles are coded by repeating the single cycle inputs twice.
Note that, if desired, stage times may be defined as real values (i.e., with a
precision of greater than 1 second) but that integer input times are normally
sufficiently precise. However they are stored as real values and, if factored as
above, are likely to end up as non-integer values.
6.4.3.4 Offsets
The offset refers to the time at which the first coded stage for a particular node
begins relative to some absolute zero point for all signals in the system assuming
some form of signal co-ordination (e.g., to produce “green waves”). If there is no
co-ordination the offset is essentially arbitrary and should probably be set to zero.
For example, if node A has an offset of 10 and its neighbour B has an offset of 20
this means that the first coded stage at B begins 10 seconds after the first coded
stage at A (provided, of course, that signals A and B are working on a common
cycle time). If the cycle times at A and B differ then signal co-ordination between
the two is not possible and their offsets are essentially arbitrary - unless, of
course, A and B are co-ordinated with other neighbouring nodes with a common
cycle time.
Note, therefore, that the offset depends on the choice of which stage has been
coded first at each node which is essentially arbitrary (stages must be coded in
the correct order but the starting point is arbitrary). If, for whatever reason, the
first stage at B was moved to the end of the coded stages, the offset at B would
have to be advanced accordingly.
In the event of the stage lengths being factored as above the offset is unchanged.
The choice of offsets has an influence on the delays modelled within the
simulation as discussed in Section 8.2.7. The optimisation of offsets is discussed
in Sections 15.31 and 12.2 under SATOFF.
6.4.3.5 RGS Files
Note that a text “.RGS” file containing full data on the signal settings as defined by
the particular network .dat may be output by SATNET if a parameter FREDDY = T
under &PARAM. See 11.9.14 for full details on the function of .RGS files which
may be used to transfer signal settings between networks, including their use as
an input to SATNET using the &PARAM parameter FILRGS.
Thus if FILRGS is set then the signal timings are read from that file and over-write
the signal timings set on the normal input .dat file. See 11.9.14. Note that if the
timings for a specific node are not included in the input .RGS file then the data
from the .dat file is used.
Note that .RGS files may also be created interactively within P1X (11.9.2) or within
the batch procedure SIGOPT (15.31.6), both presumably following steps which
optimise and/or otherwise update the traffic signals.
5120257 / Apr 15 6-38

Section 6
6.4.3.6 Pedestrian (2-arm) Crossings

A pedestrian crossing which is signal-controlled should normally be coded as a
(presumably) two-arm junction with fixed cycle time and a single red/green stage
even though, in practice it may not operate with such fixed cycles. However the
main objective of the coding is to correctly predict the capacity which, ignoring
more complex factors such as blocking back or mid-link capacity restraint, is
simply the saturation flow times the fractional green time per arm.
Pedestrian crossings which are not signal controlled (i.e., zebra crossings) are
most conveniently modelled as though they were signalised with the cycle time
and red/green split chosen so as to best correspond to the frequency and duration
of pedestrian priority, again with the primary objective of getting the capacity
correct.
We may note, however, that it may be simplest all round to exclude pedestrian
crossings as separate simulation nodes and to include their impact on traffic as
part of a link speed-flow capacity-restraint curve; see 6.4.12.3.
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.2 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
Record 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 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
5120257 / Apr 15 6-39

Section 6
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).
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.
5120257 / Apr 15 6-40

Section 6
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 should be considered in setting saturation flows:
♦ Number of lanes
♦ Lane widths
♦ Position of lanes (e.g., nearside vrs offside)
♦ Junction type (e.g., roundabout vrs priority etc.)
♦ Major/minor arm (at priority junctions)
♦ Inclination (on hills)
♦ Visibility
♦ 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:
5120257 / Apr 15 6-41

Section 6
♦ Calculating a saturation flow per lane for each turn equal to its input
saturation flow divided by by the number of lanes;
♦ 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 (E.g., extra lanes may
have been coded – see 6.4.9.1 – to avoid problems of lane sharing without a
comparable increase in the saturation flow.). 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!
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.
Note that the arm saturation flows do not need to be the same for all entry arms
and the expectation would be, given similar design standards for all arms, that the
saturation flow per arm would be proportional to the number of lanes per arm.
Significant differences between the saturation flow per lane for different arms are
detected by Serious Warning 138, first introduced in Version 10.9.13.
5120257 / Apr 15 6-42

Section 6
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”.
6.4.9 Lane Definition

6.4.9.1 General Principles
The principles by which lanes are defined within a simulation network may be
differentiated according to whether or not the network data coding makes use of
flared lanes. Or, to put it another way, whether the model was set up pre or post
release version 10.9.20. N.B. This is not to say that networks must be coded
differently post 10.9.20, only that different options exist which users may wish to
take advantage of.
LANE DEFINITIONS WITHOUT USING FLARES (PRE 10.9.20)

Traditionally (pre 10.9.20), the number of lanes defined for each input arm
corresponds to the “effective” number of lanes at the stop line, not necessarily
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.
(Although the effect may also be adequately modelled by using the TAX and
MONACO options; see 8.5.)
The problem is most acute when one or more turns give way (e.g., are coded as
X) 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).
In case of doubt - code extra lanes!
5120257 / Apr 15 6-43

Section 6
LANE DEFINITIONS MAKING USE OF FLARED LANES (POST 10.9.20)

Post 10.9.20, it has become possible to explicitly define and model additional
flared lanes, i.e., short sections of roadway added at the stop line to
accommodate specific turning movements. The geometry of a flared right-turning
lane and the (shared) lane from which it diverges is illustrated below:
(Note: the above layout represents the use of the right turn FLAREX lane but also
equally applies to the left-turn FLAREF lane).
A represents the ahead movement in the “main lane” while F represents the flared
movement which diverges from the main lane into the flared lane.
With flared lanes (nearside and/or offside) defined the position on the link at which
lanes are defined has shifted upstream away from the stop line such that the
number of lanes defined for each input arm should equal the number of upstream
lanes at the point where the flare(s) begin. Thus, in the above diagram, the link
would be defined as having two lanes, not three as at the stopline.
In addition the allocation of turns to lane is also defined at the point where the
flare begins. In the above diagram the ahead movement would be allocated to
lanes 1 and 2 whereas the F movement would be allocated to lane 2 only (the
offside lane).
Thus a flared lane is definitely modelled as an added lane at the stop lane but one
which does not go the full length of the link as opposed to modelling flared lanes
as being definitely present at the stop line but subtracted at some point
upstream. The reason for choosing this (somewhat arbitrary) definition of the
number of lanes and the allocation of lanes by turn is to be able to correctly model
the choice of lanes by turns and the capacity reduction effects within shared
lanes.
In part, flared lanes deal with the problems of cars “squeezing around” blocked
lanes even if an extra lane is not explicitly marked “on the ground”. Using flared
lanes the potential need to code “artificial” extra lanes (as recommended pre
10.9.20; see above) has therefore become less acute. Thus the post 10.9 advice
is not to code extra lanes when in doubt but to code explicit flares.
Users should also note that:
5120257 / Apr 15 6-44

Section 6
♦ Shared ahead lanes: straight-ahead movements are not permitted

from the (extra) flared lane. In these cases, the full lane should be
modelled with a mid-link capacity constraint introduced if necessary;
and
♦ Length of the flared lanes: practical testing has shown that if the
length of the flared lane is more than 10 pcus, a full lane should be
coded.
The methods by which flared lanes are defined within a network .dat file are
described in sections 6.4.9.3 and 6.4.14
LANE NUMBERING
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
(equal to the number of lanes as defined above) is the “outermost” lane nearest to
the centre of the road. Note, therefore, that any flared lanes are not explicitly
assigned extra lane numbers, their lane numbers are defined at the point of
flaring.
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.
Less urgently one should not have, say, a right-hand turn and a left hand turn
both assigned to lanes 1 and 2 since that would mean there could be traffic
turning right from the left hand lane having to weave with traffic turning left from
the right hand lane.
Violations of the former rule result in a Semi-Fatal Error whereas the latter is only
a Serious Warning.
6.4.9.2 Bus Lanes (B, S or T)
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.
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 total entry lanes with bus lanes in both the nearside and offside of the
roadway.
5120257 / Apr 15 6-45

Section 6
Therefore the numerical number of lanes, i.e., 2 in the above examples,

represents the number of lanes available to “normal” traffic; adding the number of
B’s to that gives the total number of lanes on the road.
Alternatively the letters ‘S’ and ‘T’ may also be used to indicate special “bus” lanes
where T represents a tram-only lane and S represents a tram+bus lane. In
modelling terms there is no distinction between B, S and T, the only difference
being that P1X graphics plots them in three different colours.
6.4.9.3 Additional Flared Lanes (F)
In the same way that a B (/S/T) may be used to indicate extra bus lanes an ‘F’ in
columns 12 to 15 may be included to indicate the presence of additional flared
lanes either nearside or offside depending on whether the F precedes or follows
the number of lanes. Thus F2 would indicate a nearside flared lane with two
“normal” lanes (whereas 2F would indicate that the flare is on the offside).
The length (in PCUs) of the flared segment is taken, by default, to be the value set
by the &PARAM parameter FLAREF or FLAREX (nearside or offside).
Alternatively the value may be subsequently set by defining an explicit flared
length on the second link record (if present); see 6.4.14. Indeed flares may be
defined either by an F in the lanes field or by an entry on the second record or
(belt’n’braces and recommended) both.
N.B. The length of flared segments is always defined in units of PCUs, not
metres.
Note that a flared lane may not (currently) be used at a roundabout, dummy node
or external simulation node; i.e., only at a priority or signalised junction.
See Section 8.2.6 for an explanation of the modelling principles applied.
WARNING! Whereas, at the point of release in 10.9.22, the input coding
conventions for flared lanes are well established and “stable” the modelling rules
for flares are certainly at an advanced but not necessarily a final stage of
development: minor improvements may be expected in the future. Thus, while the
added impact of flared lanes seems to be “sensible” in the majority of situations
tested to date there will almost certainly be unlikely combinations of
circumstances arising at some point in the future which will lead to unrealistic
results and which will necessitate changes to the modelling.
The release of 10.9.24 introduced some major revisions to the internal
calculations to improve the stability of the simulation.
Users are strongly encouraged to include flares in their data coding – but please
monitor the results with care!
No significant changes were introduced with 11.1.
6.4.9.4 Weaving Segments
In addition to one or more B’s etc. in columns 12 to 15 a ‘W’ may be included to
indicate that this link is part of a “weaving segment” between multiple junctions 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.
5120257 / Apr 15 6-46

Section 6
Note that the use of a W in columns 12 to 15 to denote “weaving” is distinct from

the use of a W as a priority marker (section 6.4.2.5) which applies to weaving
between a pair of internal turns at a single simulation node as opposed to
weaving between multiple simulation nodes.
6.4.9.5 Defining lanes for X-Turns at Signals (Flared Lanes)
A common problem in terms of lane definition is how to treat X-turns at signals
where, even if “on the ground” there is an outside lane which is shared between
straight ahead and right turning (X = offside) traffic, it is possible for a certain
number of straight ahead vehicles to proceed from that lane even if the X-turners
are blocked.
Traditionally many users have coded such a configuration by adding an extra
“pseudo” lane for right turners with or without a shared lane in order to allow both
movements to proceed at the same time. However, our current advice would be to
code a single lane but to make maximum use of some of the newer modelling
options now available in 10.9. In particular:
(1) Use a link-dependent TAX (which may now be either directly coded on the
link record – see 6.4.15 – or on a second line record – see 6.4.14) to set
the number of pcus which can sit mid-junction and clear at the end of the
green phases.
(2) Set MONACO = T (see 8.2.5.1) in order to allow an increased number of
straight ahead movements to clear at the head of the queue.
(3) Use an offside flared lane (FLAREX, see 6.4.14 and 8.2.5.2) in
conjunction with MONACO to allow extra X-turners to queue before the
lane is blocked to straight ahead traffic.
In addition, if a flared lane is provided on the ground for X-turners, our advice
would be:
(1) Code it as a “full” lane available to right-turners only if the flared section is
sufficiently long that it is unlikely that the queue of right turners will stretch
beyond the flare and potentially block straight aheads.
(2) However, if the flare is relatively short (say less than 5 pcus), then do not
code it as an extra X-turn only lane but code it as an outside lane which is
shared between X-turns and straight aheads and make use of the
FLAREX etc. facilities above.
By coding a single shared lane the potential for X-turns to block straight aheads
will be emphasised and, in effect, the lane definition is that which occurs
immediately upstream of the start of the flared section.
Finally we note that coding 2 available lanes for X-turners with the inside lane
shared and the outside lane X-turns only is not recommended on the grounds that
(a) it represents highly questionable traffic engineering practice and (b) it leads to
convergence problems when the exclusive lane goes over-capacity and the inner
lane therefore goes over-capacity as well in a very discontinuous fashion and
blocks the shared traffic. See Serious Warning 165.
5120257 / Apr 15 6-47

Section 6
N.B. Serious Warning 165 is no longer applied (post release 11.3.05) if the traffic
in the shared lane has alternative (further inside) lanes that it may use if it is
being blocked in the shared lane.
Similarly coding two outside lanes both of which are shared between X-turners
and straight aheads is strongly not recommended on the grounds that it implies
internal weaving of traffic. See Serious Warning 142 which, see Section 6.12.2,
may be converted to a NAFF error under WRIGHT = T.
6.4.9.6 Shared Lanes
Following on from the last point in the previous sub-section if two different turning
movements share two or more lanes (e.g., left-turners are allocated to lanes 1 and
2 and so are right-turners) then this implies that a right-turner from lane 1 would
have to cross in front of a left-turner from lane 2 in order to exit and vice-versa.
The lane allocation is permitted within SATURN but it does not represent good
engineering practice so therefore it is flagged as Serious Warning 142 or 162
(depending on whether or not X-turns are involved).
Thus a single lane may be shared between two or more turning movements (and
clearly this is very common); the problem only occurs when two adjacent lanes
are shared between two or more turns.
The problems become more acute when one of the lanes feeds into a flare since
in that case you might have the situation where a vehicle in lane 1 is trying to
cross over to the flare in (effectively) lane 3. Errors of this sort are flagged by
Serious Warnings 179 and 180 which default to NAFF errors under WRIGHT = T.
6.4.10 Node-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
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:
Equation 6.1
STACK = LANES *IDIST / ALEX
5120257 / Apr 15 6-48

Section 6
with the direct addition of any nearside or offside flares, i.e., FLAREX + FLAREF
(see 6.4.14).
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 effect whatsoever on the
simulation. However, if it does enter into blocking back calculations, it may be
important to set a “true” value, see 8.5.7, or to consider possible “corrected”
values to deal with possible intrinsic problems with the modelling logic; e.g., see
8.5.5.6.
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.
We may also note that a negative stacking capacity may be input in order to
indicate one particular property, which is that a “link chain” (see 5.1.12) can not
be extended through this link. This has particular applications for blocking back
(see 8.5.5). If a negative value is input the absolute value defines the true stacking
capacity and a separate note is made of the negative input. Note that normally
negative stacking capacities would only be applied at 2-arm nodes where chains
are feasible although more complex nodes may also feature in chains.
6.4.12 Simulation 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) and, in effect, infinite capacities.
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).
This facility is extremely useful for modelling long motorway-style links where
delays tend to be dictated by conditions on the link itself as opposed to junction
properties. Indeed speed-flow curves may be the only way to adequately model
such links. It may also be useful in urban conditions where, e.g., on–link parking
or width restrictions may severely restrict the flow of traffic mid-link such that it
becomes lower than that at the stop-line.
However it is also possible to abuse the facility as noted below, 6.4.12.1.
To define link capacity restraint 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. Format conventions
(fixed columns etc.) for data on 2B records are given in 6.4.1. (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 an in-bound link
is converted to out-bound only.)
5120257 / Apr 15 6-49
Section 6
Note that the additional link record 2B may also be used to define parameters
such as TAX, FLAREF and FLAREX; see 6.4.14.
More specifically the extra record gives:
1) the free flow travel time t 0 in seconds / free flow speed in kph / free flow
delays in seconds
1) the time at capacity t C in seconds / capacity speed in kph / delays at
capacity
2) the link capacity C (sometimes referred to as the “pinchpoint” capacity)
3) An ‘S’, ‘T’ or ‘D’ to indicate speeds, times or delays above
4) A “power” n
5) A “link index” or “capacity index” (optional – default is 0); see 5.1.9.
such that link travel time as a function of flow V is defined by:
Equation 6.2
t (v) =
t0 + AV n v<c
where the parameter A is chosen such that t(C) = t C . For V > C the time is
constant, t C .
This data has two effects: (1) it determines the flow-dependent (cruise) 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 the time/speed defined in columns 16-20 of the link record 2 is
disregarded if an extra speed-flow record is used. However a warning is
generated if a non-zero link time/speed does not fall within the upper and lower
limits set by the speed/flow times/speeds at free flow and capacity.
Note that by leaving entries (1) through (4) blank but coding a (positive) capacity
index allows one to use a “default” speed-flow curve as defined within the 33333
buffer records. See 15.9.5.
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 (so that some care may be needed with pre 10-5 network data
files). A third choice, D (see 6.4.12.2), was added in 11.2.10 in 2013.
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.
5120257 / Apr 15 6-50

Section 6
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.
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.12.1 Mixing Mid-link Capacity Restraint with Junction Capacity Restraint (SW 157)
A not uncommon error that occurs with the use of mid-link capacity-restraint or
speed-flow curves is to use curves that implicitly assume some capacity reduction
due to downstream junction effects and therefore define a capacity that is lower
than the genuine mid-link capacity. In this case the model will potentially double-
count the impact of the downstream junction capacity reductions and/or delays.
For example, the COBA-10 curves described in Section 15.9.3 almost certainly
include junction effects, particularly for urban areas. Care should therefore be
exercised that such curves are not included by default on virtually every link in a
network. See also the advice in Section 15.9.4.
A check for whether a mid-link capacity appears to be significantly different (either
very much greater or very much less) from the “average” downstream saturation
flow(s) is included as Serious Warning 157 within SATNET. We note that the
warning is at best an “educated guess” as to whether the problem occurs since
the average downstream saturation flow, which may be flow dependent, can only
be estimated.
6.4.12.2 Defining Mid-link Travel Times by Delays
If column 29 on the link speed-flow record is set to D (for Delays as opposed to S
for Speeds or T for Times) then the data input in columns 11-15 (“TFF”) is an
additional delay at free-flow which must be added to the link cruise time as
defined on the first link record in order to give the free-flow time on the link.
Similarly, the data input in columns 16-20 (“TCAP”) is the extra delay on the link
when the mid-link flow is at its capacity.
For example, the delays might be associated with “minor” junctions (e.g.,
pedestrian crossings) mid-link whose delays are flow-dependent and were not
taken into account in the coding of the link which reflects primarily what is
happening at the downstream stop line of the “main” junction.
Further suggestions as to how to deal with mid-link pedestrian crossings is given
next.
6.4.12.3 Dealing with Mid-link Pedestrian Crossings via Link Capacity Restraint
A pedestrian crossing situated in the middle of a “major” simulation link may be
included as a distinct simulation node with appropriate saturation flows, signal
timings (if required) etc., etc. (see 6.4.3.6) but very often the extra effort to do so is
not worth the presumed improvement in model “realism”. An alternative approach
is to include their impact on traffic within a link capacity-restraint curve.
Thus if we have a “major” link from node A to node B with a mid-link pedestrian
crossing at (tentatively) node C we may calculate from first principles what a full
5120257 / Apr 15 6-51

Section 6
simulation of node C would give in terms of: (a) the capacity for turn A-C-B, (b) its
delay given the current flow, (c) its delay at zero flow and (d) its delay at capacity,
from which we could calculate a speed-flow curve for use in the assignment
following the same principles as outlined in Section 8.4.2. Alternatively we could
use that data in order to calculate total link travel times from A to B (i.e., excluding
stop-line delays at B) at the current flows, at free-flow and at capacity, from which
we could construct a speed-flow curve which would combine both any speed-flow
relationships along the link itself plus any additional impacts from C.
As an example of how to estimate delays at a pedestrian crossing consider a
simple red-green sequence such that the crossing is “red” to car traffic for r
seconds followed by a green stage of g seconds. (Hence a total cycle time c = r +
g.) A basic saw-tooth model of queues gives us:
The delay at zero flow = r2/2c
The delay at capacity flow = r/2.
The capacity equals S x g / c (where S is the saturation flow)
If there is more than one crossing along a link then the total delays at free
flow/current/capacity flows are simply the sum of the individual crossings whereas
the “effective” capacity is the minimum of all the individual capacities
6.4.13 Minimum and Maximum Stage Green Times

Post 10.4 it is 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:
T min < T
&
T > T max
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 that a minimum stage length is being set (T min = 20; T =
5120257 / Apr 15 6-52
Section 6
30) whereas a maximum stage length would need to be written as (somewhat

counter intuitively) as 20>30 (T max = 30; T = 20)
The obvious error checks such as minimum time less than green time (as in 30 <
20) and maximum greater than green time (as in 20 > 30) are made on input and,
in the case of any violations, the min/max inputs are ignored (with non-fatal errors
256 or 257 generated).
6.4.14 Free-Format Data Input on Link Record 2B: TAX, FLAREX, FLAREF and
APRESV
Post release 10.9.20 it is possible to use Link record 2B to define various link-
specific parameters in addition to link speed-flow data (6.4.12): specifically TAX
for the number of pcus which may stack in the centre of the junction plus FLAREX
and FLAREF to represent PCUs in extra flared lanes (6.4.9.3) and APRESV to
control lane choice at merges. All these parameters are assigned global default
values set via &PARAM Namelist inputs.
In order to do so a * must be coded in column 11 of Link Record 1 and the extra
link parameters are defined using a combination of keywords and numerical
values in a free format. For example
1234* 2 60 200 ...
TAX 3.0 60 120 2000 2.5 12 FLAREX 2.5
would indicate that the link from Anode 1234 requires a second line in order to
define link speed-flow properties (thus free-flow time of 60 seconds, capacity time
of 120 seconds, capacity 2000, power 2.5 and capacity index 12) but that, in
addition, its TAX value would be 3.0 and it has an offside flared lane (FLAREX) of
length equivalent to 2.5 PCUs. Text “APRESV” signifies values for APRESV to
follow and “FLAREF” for FLAREF.
In this example the values 60 ... 12 must appear in their normal fixed columns,
i.e., between column 11 and 45 (see 6.4.1), while the keyword+value sets may
appear anywhere in columns 1 – 10 or beyond 45.
Further notes:
The keyword used to designate TAX is, strictly speaking, any set of characters
beginning with a T and ending with an X; e.g., TX, TAX, TyrannosorusreX, etc.
etc. Ditto FX or FLAREX, FF for FLAREF or AV for APRESV. Nor is it case
sensitive.
Keywords may also use columns 11 to 45 as long as those columns are not being
used for speed-flow data. (What happens is that the line is first scanned for
keyword+values which are then replaced by blanks and then the speed-flow data
is read as per normal.)
It is also possible to use Record 2B only to define TAX, FLAREX etc., i.e., with no
speed-flow or capacity index defined for that link.
Extra link parameters TAX etc. do not apply to links to external simulation nodes
although link speed-flow curves may be used for such links.
5120257 / Apr 15 6-53

Section 6
Defining FLAREX and/or FLAREF on link Record 2B may be either an alternative

to coding an F in the lane field on Record 2A (6.4.9.3) or a supplementary data
source. Thus if an F is used in the lane field in Record 2A but FLAREX/F does not
appear on Record 2B then the length of the flare is assumed to be set by the
default parameter FLAREX/F defined under &PARAM. If FLAREX/F appears
explicitly on Record 2B then that value is used,
A flared lane may also be included if FLAREX/F appears on Record 2B even if an
F did not appear in the lane field on Record 2A. It is, however, recommended to
use both methods “belt’n’braces”; i.e., code an F on record 2A and set an explicit
flare length on record 2B.
Recall that both FLAREX and FLAREF are defined in units of PCUs, not metres.
And that TAX is also defined in units of PCUs.
If either FLAREF or FLAREX appears to be abnormally long – defined as either
greater than 100 m or greater than the apparent link length – then a Serious
Warning 175 is generated. If the flare length is correct you should probably
consider using mid-link capacity restraint instead and/or defining an extra lane at
the stop-line (which would be assumed to be full-length along the link).
Note that link-specific values of TAX, FLAREX/F and APRESV may also be set
using an external X-File; see 6.13.4.
All flare lengths, whether nearside or offside, are automatically added to the
default link stacking capacity (Equation 6.1, 10.9.11). N.B. No change of units is
required since both flares and stacks are expressed as PCUs.
6.4.15 Link-specific TAX values set on Record 1

Post release 10.9 it is also possible – though no longer particularly recommended!
- in addition to the extra-line facilities described in 6.4.14, to include a link-specific
TAX value associated with an X-turn at signals (see 6..4.2.2 and 8.2.4) in the final
5 columns at the end of an individual link record (6.4.1) where the precise location
of the last 5 columns depends on the number of turn data sets. Thus if a node has
3 arms and hence two possible turns per link the data records for those two turns
will occupy columns 26-35 and 36-45 and the extra TAX data will be in columns
46-50. With 4 arms they would be in columns 56-60, etc. etc.
The convention to indicate that those 5 columns do contain a value of TAX is that
the first column must contain either ‘T’ or ‘X’ and the remaining 4 columns contain
the numerical value in essentially free format, i.e., it may be an integer, it may
contain a decimal point, etc. etc.
If the final turn on a link is not coded with an X priority marker or if the junction is
not signalised then any possible TAX data is ignored, Conversely if there is an X
marker at signals and a link-specific TAX value is not coded then the link will take
its TAX value either from the global default – TAX in 6.3.3 – or via an X-file (see
6.13.4).
N.B. Users will probably find it much simpler to set TAX using the “extra line”
convention of 6.4.14 rather than the “end of line” convention described here. Both
were added in 10.9 but, in retrospect, the extra line method is a much better idea
and the end of line method is likely to be withdrawn.
5120257 / Apr 15 6-54

Section 6
6.5 Simulation Centroid Connector Data: the ‘22222’ Records

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. In
particular, note that the method of connection differs between connections to
“internal” and “external” simulation links.
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,
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) It is also possible – although not recommended – to attach zones to the
simulation network via an intermediate buffer node, in which case the
connectors are contained within the 33333 data records. See 16.6.3.
5120257 / Apr 15 6-55

Section 6
7) Since a maximum of 6 input node pairs per record are allowed the final
column which may be used is column 65; any text beyond 65 is flagged
as a potential error, particularly if it is numerical (which might indicate that
it was intended to be a 7th input connector).
6.6 The Buffer Network/Link Data: the ‘33333’ Records

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
– or a “Do It Yourself” format may be set – see Section 15.35.)
RECORD 1
Cols. Description
1 A ‘C’ if the following node refers to a zone (see note (13)), a ‘D’ if this is a
default speed-flow curve (see note (8)) or a ‘V’ to indicate a maximum
vehicle speed under CLICKS (see note (16).
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).
36 -40 The power to be used in the link flow-delay curve. (FORMAT - F5.1 –
therefore, by default, the decimal point should appear in column 39 but
see note (4).)
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).
5120257 / Apr 15 6-56

Section 6
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) A capacity of zero - or blank - is assumed to imply infinite capacity -
actually recorded as 99999 pcu/hr – and fixed times/speeds as set at free
flow (so that the capacity time/speed is ignored). It is further assumed
that all centroid connectors have fixed travel times (set by the free-flow
field) and an infinite capacity, i.e. 99999. (If the free flow and capacity
times are set equal with a finite capacity then the times are fixed but only
up to capacity, beyond which point they increase linearly as per equation
(5.1.b))
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. (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. See 2.8.3)
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.
5120257 / Apr 15 6-57

Section 6
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 subsequent input
records. These are indicated by a D in column 1. See Section 15.9.5 for
full details. Note that their format may be either fixed column or free-
format (CSV) depending on whether the &PARAM Namelist parameter
DCSV = F or T, and if fixed column must match the normal columns in
use on link records (ie are subject to DUTCH = T if set).
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, in particular on the (highly recommended) input of KNOBS
data from an external text file (FILKNB) as an alternative to including
them on the 33333 data records as described here.
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 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. The main requirement is
that the data is entirely contained within the same columns. See 2.8.3.
13) The requirement to use a ‘C’ in columns 1 or 6 to indicate a zone may be
relaxed by using NO333C = T 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.
14) Methods exist to change the input formats to user-set conventions; see
15.35.
5120257 / Apr 15 6-58

Section 6
15) The two input values of speed/time, the capacity and the power are used
to define a link speed-flow curve as specified in Section 5.4.
16) Similar to a D in column 1 a V in column 1 is used to indicate a record
which defines a maximum speed under CLICKS for a particular
combination of vehicle type and capacity index; see Section 15.47.2.3 for
the full specification.
6.7 Restricted Turns and Links: the ‘44444’ Records

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 (or more usually ‘44444’) 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. In general turns in the buffer network CANNOT be restricted as
they do not explicitly exist in the assignment network although, post
Release 11.1, they may be effectively banned and/or penalised if
SPIDER = T; see 15.56.7.3.
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 notional) time penalty whose
units are assumed to be seconds. 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) “Time” penalties may represent virtually anything the user may wish them
to represent. For example, they may be purely notional times designed to
5120257 / Apr 15 6-59
Section 6
deter non-local drivers from using a local rat-run, or they may be “real” in
that they represent the extra time for a lorry to drive down a windy road.
Under certain circumstances, see 15.24.4, options exist to include them
or exclude them with “normal” time. However, in terms of output statistics
of total times or speeds, penalty times are not included with “real” times
but are listed separately.
6) 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.
7) 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.)
8) Under the usual option of a single user class only columns 16-20 (31-35
under DUTCH) are required to specify the ban/penalty.
9) 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. See
Section 6.14 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.
6.8 Node and Zone Co-ordinates/Supplementary Data: the ‘55555’

Records
This data section, preceded by a record with a 5 in column 1 (or more usually
‘55555’) 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. The source
and conversion method should be recorded using the parameters IEPSG,
IXSHFT, IYSHFT and XYFACT (see note (12) below). 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.)
5120257 / Apr 15 6-60

Section 6
Cols. Description
1 A ‘C’ if columns 2 to 5 contain a zone number (but see note 11);
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 (by default as an integer); see notes 6) and 10)
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 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 with co-ordinates defined to the nearest metre (so that XYUNIT
= 1.0).
4) Section 5.1.7 defines sectors. If either the parameters IROCKY or TFL
have 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 and/or TFL 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. (Note that
formats such as F6.0 are much better given as I6 since the former
“wastes” one column by including a final decimal point while I6 potentially
5120257 / Apr 15 6-61
Section 6
uses all 6 available columns.). See also note 10) below for alternative
“free formats”.
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.
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; recommended) 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:
♦ node and zone numbers may be of any number of digits

(independent of DUTCH);
♦ ditto the X, Y values which may also contain (any number of)
decimals;
♦ 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 firstly interpreted as a zone
but then, if it cannot be identified as a zone number, it is interpreted as a
node (a new rule under 11.2.06; previously all numbers <= MAXZN were
assumed to be zones). This may be useful in converting data from
external data sets although its long term use is not recommended.
12) To meet the requirements for SATURN coordinates, it is often necessary
to "convert" from the external source data. The style of the source and
conversion can (and should) be stored in the network for future use.
There is an international body that maintains an EPSG 1 dataset of
geodetic systems, which holds the referencing of common systems (like
1 The European Petroleum Survey Group created a dataset of geodetic parameters in 1985 for internal use of its
members. In 1993 the dataset was made public as reference data to the then Petrotechnical Open Software
5120257 / Apr 15 6-62

Section 6
the British National Grid) to the actual location on Earth. Having the
EPSG code and being able to deduce the corresponding external
coordinates means that we can have all the necessary information to plot
SATURN over mapping backgrounds.
The parameters used to do this are:
♦ IEPSG gives the EPSG code for the USER system. The default
27700 corresponds to OSGB 1936 / British National Grid at metre
level.
♦ IXSHFT, IYSHFT give the X and Y shifts used in the conversion.
♦ XYFACT gives the factor used.

Using Xe,Ye to represent the external/EPSG coordinates, and Xs,Ys the
SATURN ones, then the parameters correspond to the calculation:
Xs = (Xu - IXSHFT) / XYFACT
Ys = (Yu - IYSHFT) / XYFACT
The defaults for XYFACT, IXSHFT and IYSHFT allow the SATURN
coordinates to be identical to the source system.
6.9 Fixed Routes (E.g. Buses): the ‘66666’ Records
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:
♦ Bus routes (or other transit services such as trams), or
♦ Routes to be used for later analysis, e.g. timed routes from moving
car observer surveys
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 “fixed”
assignment flows (see 5.5.3.). One bus per hour is equivalent to ‘BUSPCU’ pcus
per hour. Indeed, as note in 5.5.3, it may be possible / convenient to define bus
flows as pre-loaded flows (15.5.5 or vice-versa. For example, if you have a very
large number of low-frequency bus routes it may be simpler to simply aggregate
all their individual flows by link and input them as fixed pre-loaded flows.
Corporation data model (POSC has since rebranded as Energistics). In 2005 the European Petroleum Survey
Group was reformed as the Surveying and Positioning Committee of the International Association of Oil and
Gas Producers (OGP). Maintenance of the geodetic parameter database now resides with OGP Surveying and
Positioning Committee's Geodetic Subcommittee. For continuity reasons the dataset name remains as the EPSG
Geodetic Parameter Dataset, or in short the EPSG Dataset.
5120257 / Apr 15 6-63

Section 6
Route data records are preceded by a record with 6 in column 1 (or more usually
‘66666’) 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).)
The “name” of the route (which may be alpha-numeric as opposed to
Cols. 1 - 5
pure numbers); maximum length 4 characters.
‘T’ if the route is two-way and the node order is exactly reversed (in which
Col. 6
case the reverse route need not be coded);
‘R’ if the route is defined in “reverse order”, i.e. starting at the last entry;
‘D’ for a “route deletion record”; see 6.9.6;
‘F’ for a “frequency editing” record; see 6.9.6;
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.)
The number of nodes through which the route passes (i.e., the number of
Cols. 11 - 15
node entries following); optional - see 6.9.2, note (6).
Cols. 16 - 20 The first node on the route
Up to 13 nodes may be specified per record with the 13th node appearing in
columns 76-80. The list of nodes may be continued on a second, third, fourth, etc
record / row (up to a maximum of 78 records - see 6.9.2, note (9)) - starting in
column 16 and leaving columns 1-15 blank.
An alternative (and highly recommended) convention for specifying nodes without
using fixed columns (EZBUS) is given in note 6), 6.9.2 while 6.9.5 describes how
to include “timing points”
6.9.2 Route Definitions and Formats

1) If UPBUS = F (its default) 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 – see 5.1.8; i.e., they are assumed to commence
at the downstream end of their first link and to terminate at the upstream
end of their last link. Thus they contribute to both the entry/exit flows on
their first/last links. 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 as well as on the relevant first/last turns.
See also 6.9.4 on “zero-flow” routes where, in effect, the presumption is
that UPBUS = T.
5120257 / Apr 15 6-64

Section 6
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 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.
In addition, post 10.9, if the “direct line” method fails and MINDER = T, a
path is generated based on the minimum distance path between the two
unconnected nodes.
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:
♦ Cols 1-10 remain the same on the first record (i.e., fixed column
format).
♦ Cols 11-15 are ignored; i.e., leave them blank.
♦ Cols 16-80 contain a list of nodes, not necessarily in fixed columns,

but separated by one or more spaces or commas (CSV).
♦ 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.
5120257 / Apr 15 6-65

Section 6
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” rules will also
be correctly read under free format provided that there are no 5-digit
node numbers which “run into one another”.
7) Column 6 may optionally contain various (normally upper case) letters to
denote various options. Thus if Col 6 = 'T' (for “Two-way”) and the nodes
list is A… Z then a second return route will be added with node list Z… A;
i.e., the reverse direction. If however col 6 = ‘R’ (for “reverse”) 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.
Similarly a D or an F may be used to denote “route deletion” or
“frequency editing” respectively; see 10.9.6 for further details.
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 78 records / rows any records
beyond the 78th 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.
Equally, under BUSKER, if the “fixed column” output format would require
more than 78 records the data is output in a compressed free format
(with a single space between each node) in order to fit within 78 records.
10) Routes are allowed to execute U-turns at all nodes, whether simulation or
buffer, roundabout or otherwise (provided, of course, that the entry/exit
road is two-way). Such turns are effectively “free turns” in the sense that
they contribute zero delay to the total route travel time. Explicitly banned
turns in the simulation network are, of course, never allowed in routes.
(This feature is commonly used to represent the “terminus” for a bus
route if the complete round-trip route is coded rather than as two
separate sections.)
5120257 / Apr 15 6-66

Section 6
11) Routes are also allowed to exit the network from one “stub node” and re-
enter at another. This may happen if the network has been cordoned and
part of the actual route lies outside the coded section. As with U-turns no
extra time or distance is added in these cases.
12) In addition routes are also allowed to exit the network from one node and
re-enter at another (non-adjacent) node by inserting a “wildcard” node
number between the two nodes. The wildcard number is defined by the
&PARAM Namelist parameter KANGA (signifying a “jumper”), default
9999. Thus a sequence of nodes A B C 999 F G H would imply that the
route left the coded network at C and reappeared at F; for example it
might be using relatively minor roads which are not included in the coded
network
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. They may also
include information on “timing points” as described in 6.9.5 below.
Zero-flow routes differ from ordinary “bus” routes in that they are always (post
release 10.9.24) to start and end at the first and last coded links; i.e., they always
behave as if UPBUS = T as explained in note 1) in 6.9.2. Thus, for example, a
timing point at the final node will always be recognised.
Note that the term “bus company” also applies to sets of pure routes, i.e. those
with frequency zero. It would therefore seem sensible for the user to include non-
bus routes as a separate “company” within a distinct 66666 block
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
5120257 / Apr 15 6-67

Section 6
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
and therefore their value should depend upon which exit turn is to be taken next,
i.e., the next node in the sequence. Their application for validation studies is
described in 11.7.2.
The starting point (zero time) for cumulative times is assumed to be the same
point at which a vehicle (bus) on the route would enter the network. Thus – see
note 1) in 6.9.2 – this would be the downstream end of the first link if UPBUS = F
or the upstream end (i.e., the first coded node) if UPBUS = T. However, if the flow
on the route is zero (which is the natural value for pure timing routes) then timing
always starts at the upstream (first) node and equally ends at the final simulation
node. See 11.7.2.2 for an application within Validation.
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 .ufs 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 a “plus-minus 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. The definition of the “range” is deliberately loose since, at the
moment, it is only really used to provide a vertical bar on time v distance plots to
give an indication of the likely spread of route timings.
6.9.6 The Use of Delete and Frequency Records to Edit Routes

If the first (and, in this case, only) record of a route definition contains a normal
route name in columns 1 to 5 followed by the character D in column 6 (and
nothing thereafter) then this implies that when and if a route with the identical
name appears later on in the same 6666 data segment then that route will be
ignored. In effect it is “deleted”.
Similarly if an F appears in column 6 followed by a numerical frequency in
columns 7-10 then when and if a route with the identical route name appears later
on then the original frequency is used, not the (second) value where the actual
route definition appears.
Both these facilities may therefore be used to “edit” existing 66666 data sets by
including extra records at the start of the segment (or, strictly speaking, before
the route which they modify). For example, if you had the same set of bus routes
for the AM, Inter-peak and PM but with different frequencies then a common data
5120257 / Apr 15 6-68

Section 6
set could be used to define the nodes within each route but three different sets of
initial records could be used to define the three different frequencies.
To replace an existing route by another with the same name but with, say, a
slightly different structure but without removing the original records from the data
file(s), one should (a) include a delete record before the records which are to be
replaced and (b) insert the new route definition records after the old records. Thus
the “delete” instruction is cancelled as soon as it is acted upon.
We note that the edit record must always be input before the full record that it
modifies, independent of whether one is part of a $INCLUDE file and the other is
in the main .dat file, etc. etc.
Furthermore edit records only apply within a single bus company, i.e., set of
66666 records. Thus at the end of each set of 66666 records the list of
modifications is wiped clean and a new edit list must be created with each new
66666 set.
6.10 Counts of Link and/or Turning Volumes: the ‘77777’ Records

Specified values of volumes on certain links and/or turns may be input in fixed
columns (see note (13) for alternative free format inputs) as follows, preceded by
a 7 in column 1 (or more usually ‘77777’) 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 (INTEGER) pcus per hour (see note 13).
Cols. 21-25 The second volume ...
Cols. 26-30 up to MCCS volumes (where the different volume fields might refer to,
e.g., different vehicle types, different time periods etc. etc.).
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’ record and is
terminated by a ‘99999’ record. The maximum number of such sets is
now (10.7) 120.
2) Each set of 77777 counts is identified within SATURN 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 the same count set although, post 10.7, counts may be repeated 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.
5120257 / Apr 15 6-69

Section 6
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 are assumed to refer to the “actual mid-link”
flows - see Section 15.16.
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) In any case the counts should always be given in units of pcus/hr. Or, at
any rate, the same units as all the other flow components such as trip
matrices, saturation flows, etc., which, if desired, could be in
vehicles/hour. See 15.17.
9) Strictly speaking counts are stored as “reals” and may therefore be input
as reals (e.g., 654.0 instead of 654) although, generally, they are input as
integers on the assumption that it is difficult to define a flow to a precision
of better than 1 pcu/hr. See 2.8.3
10) 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.
11) 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.
12) Links which cannot be identified for whatever reason (e.g., node not
identified or a non-existent link between two correct nodes) by default
generate a Semi-Fatal Error 437. However this can be downgraded to a
Serious warning (269) if ERRYES(437) = F (see 2.9); this allows the file
to proceed to the assignment stage. Versions10.7 and later only.
13) If a parameter FREE77 is set to .TRUE. under &PARAM the counts in
columns 16+ (31+ if DUTCH = T) are read as “free format” (e.g., CSV)
rather than in fixed columns. This also means that they be written in
either an “integer” or “real” format (i.e., with or without decimals). Plus,
post release 11.3, the whole record including the node definitions is
read as free format, not fixed columns, so that it is now essential that a
value of zero is explicitly included when A-B denotes a link.
14) There are, however, two exceptions to the above rule that the C-node
must always be explicitly included under FREE77, even if it is zero. (1) If
there are only three items in total on the record then it is assumed that
they must be: A-node, B-node plus (single) count. (2) If the first two items
5120257 / Apr 15 6-70

Section 6
are integers (A-node and B-node) and the third entry is real (i.e., has a
decimal) then it is assumed to be the (first) count. Both cases therefore
define a link A-B but, under (1), there can only be one count whereas
under (2) there may be multiple counts. (Rule added 04/09/14 in release
11.03.07.)
15) Alternatively, even if FREE77 = F and the counts should be in fixed
columns, the counts are also read as free format and the two sets of data
compared and any differences are noted as a Serious Warning 189. This
provides a useful check for formatting errors – which most commonly
occur when the counts are in REAL format, i.e., with decimals. (Added
post release 11.3.6.)
16) Finally we note that $INCLUDE files (see 15.30) may be used to define
the 77777 data rather than explicitly including the data within the main
network .dat file and that there are obvious advantages to doing it this
way. In this case the data in each $INCLUDE file must follow the
formatting conventions defined above.
17) If you wish to input multiple $INCLUDE count files then they may be
defined in order within a single 77777/99999 pair of records. However it
may be more “natural” to define each file within a separate 77777/99999
set for ease of identification later on (e.g., in SATPIJA; see notes 2 and 3
and 13.2.1).
6.11 Generalised Costs and/or Matrix Weights for Multiple User Classes:
the ‘88888’ Records
This data section, which is mandatory for NOMADS>1, defines for each user
class:
♦ The associated vehicle class (see 5.8);
♦ The associated “level” within the trip matrix (see 7.3.2.1);
♦ Weights or factors to be applied to trip matrices;
♦ Its generalised costs (see 7.3.2.2), i.e. the criteria which determines
its “minimum cost” paths in the assignment stage;
♦ User-class specific values of SUET.

These are set by a series of records preceded by an 8 in column 1 (or more
usually ‘88888’) and terminated by 99999 in columns 1 to 5, formatted as follows
(but see Note 12) for an alternative free-format input):
Cols. Description
1–5 User class number (in the range 1 to NOMADS; see 5.8.1)
6–7 The vehicle class for this user class (see 5.8.2)
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
5120257 / Apr 15 6-71

Section 6
stage; see 7.3.2.1 and note (10) below.

16 -20 Value of time in pence per minute (Assumed decimal point in Column 18
but see point 11) below)
21 -25 Value of distance in pence per kilometre (Assumed decimal point in
Column 23 but see point 11) below)
26 -30 Value associated with the first extra “KNOB” data field in units of pence per
“KNOB unit”. See 15.14.3. Assumed decimal in column 28 (F5.2). See
notes (6), (7), (8) and (13). Set as zero (or leave blank) if the KNOB data
field is not part of a generalised cost but is simply additional data as
described in 15.14.2.
31 -35 Ditto for the second data field, etc., etc.
and/or
26 -30 User-class SUET value with an (assumed) decimal in column 28 (F5.2).
See note (9).
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.
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:
♦ Vehicle class 1;
♦ Stacked matrix level 1;
♦ Factored by 1.00;
♦ Pence per minute equal to PPM as defined under the &PARAM input
or by default;
♦ Pence per kilometre similarly defined by PPK;
♦ Global value of SUET (6.3.3).

5) Equally if columns 16 onwards are left blank, i.e., if there are no cost
definitions 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 (in
which case presumably the correct factor would be PPM/60.0). If it were
5120257 / Apr 15 6-72

Section 6
in units of pence already, e.g., it is 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 of pcu-hrs. 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 (for that user class)
which is already given 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.
8) A $ or £ on its own in a KNOB data field with the remainder of the field
blank is equivalent to a toll with an implied weight of 1.0 as default. See
20.3. However, if the $ / £ is followed by an explicit zero, e.g., ‘£0.00’
then the assumption is that this does not represent a toll (at least for the
present user class) and the field is treated as if it were totally blank – no
contribution to generalised cost.
9) 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 = 0 then this will be in
columns 26 - 30 with a decimal in column 28 (Format F5.2). If, say,
KNOBS = 3, then it would be in columns 41 – 45.
10) We refer here to the warning at the end of 7.3.2.1: use trip matrix factors
different from 1.0 with caution! For example, if you intend to carry out
elastic multiple user class assignment (7.9) or a matrix update with
SATME2 (Section 13.1.4) we strongly recommend using one stacked
level per user class from the network build stage. On the other hand, if
you have, say, an observed car matrix which you wish to uniformly split
into a set of sub-matrices, each of which has a different definition of
generalised cost, it is a simple matter to use the factors to define the
fraction of car trips in each user class. (In which case one would expect
the factors for a specific level to sum to 1.0.)
11) Users who may wish to input either rather large or rather small values of,
say, PPM or PPK should note that the” assumed” decimal places referred
to above are not fixed and that large degrees of flexibility are available
while still keeping within 5 columns; see Section 2.8.3.
12) Alternatively the restriction to a maximum of 5 columns per “real”
parameter may be avoided by setting a parameter FREE88 to .TRUE.
under &PARAM, in which case all numerical values from the matrix factor
onwards are read as free format; i.e., all values explicitly included but
separated by either a blank or a comma. Note that in this case a symbol
$ or £ to denote monetary toll cannot be separated by a space from its
numerical value.
5120257 / Apr 15 6-73

Section 6
13) Note that negative weights for KNOBS data are (post release 11.2.3) no
longer permitted and will be converted to a positive value. If you wish a
KNOB data item to be used as a negative cost (e.g., to encourage the
use of certain routes) then the data should be set negative, not the
coefficient. See 7.11.2 and 15.14.3.
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 must both contain 9 or 99999, the first to
terminate the last data section and the second to terminate all data.
6.12 Fatal Errors and NAFF UFN Files
6.12.1 General Principles

Within SATNET there are two levels of “fatal” errors, full and semi-fatal. 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. On the other hand this is not always
possible and users may have to manually edit the .dat file, although P1X may
conceivably be used to make the cause of the error more obvious.
Full fatal errors, on the other hand, must 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 may 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.
There are several methods for examining the full set of errors detected by
SATNET in a particular network. Firstly a list appears near the end of the .LPT file;
secondly, a list may be displayed by P1X under information. Alternatively a full list
of all error numbers used appears in the auxiliary file SATTIT.DAT as well as
Appendix L.
6.12.2 Upgrading Warnings etc to NAFF: The WRIGHT Parameter

In 10.7 a new &PARAM parameter WRIGHT was introduced such that if WRIGHT
= T then certain (pre-defined) existing warnings, serious warnings and/or non-fatal
errors are upgraded to semi-fatal (NAFF) on the basis that there is no conceivable
reason that could explain these errors even though SATURN can manage to run
with them included in the network coding without crashing.
5120257 / Apr 15 6-74

Section 6
The default for WRIGHT is .TRUE. but it may be turned off by setting it to
.FALSE.; - clearly not recommended. As a form of compromise, users may wish to
undertake an initial run with WRIGHT = T in order to highlight the NAFF errors
and, if they disagree with any errors which have been thus upgraded, they may
correct those that they do agree with, leave the others uncorrected and then re-set
WRIGHT = F for “production runs”.
Alternatively. by setting ERRYES(n) = F for a particular error which is
otherwise to be upgraded to semi-fatal, that error is still reported but not
upgraded.
N.B. ERRYES(n) may also, strictly speaking, be used to “turn off” Fatal
and/or Semi-Fatal errors by setting n > 300 but the practice is definitely NOT
recommended: there is a reason why certain errors are Fatal!
For 10.7, only a small number of Serious Warning (i.e., 119-123, 139 and 140)
and Non-Fatal Error 227 were identified. However the number will continue to
increase with new releases. Thus, in 10.8.15, Serious Warnings 141, 142 and 143
have been added as well as Non-Fatal Errors 226, 236, 263 and 271. Serious
Warning 105 and Non-Fatal Error 239 have been added in 10.8.16. Additional
errors 13 (now 165), 105, 234, 273, 275, 277 and 278 have been added since (up
to 10.9.13).
Post 10.9.16 those (relatively few) Warnings messages that did generate Semi-
Fatal errors were re-designated and renumbered as Serious Warnings.
(Specifically 13 became 165, 17 to 169, 76 to 176 and 77 to 177). Thus only
selected Serious Warnings and Non-Fatal Errors may now be upgraded to Semi-
Fatal.
At the same time Serious Warnings 104, 108, 117, 127, 158, 165 and 166 and
Non-Fatal errors 201, 204, 212, 218, 223, 224, 225, 264 and 265 were all added
to the list of (potential) Semi-Fatal errors.
Non-fatal errors 217 and 240 were upgraded for release 10.9.17.
See Appendix L for a full list of errors and an explanation of what each one refers
to.
6.12.3 ERRNO: Defining extra WRIGHT = T errors

Other warnings etc., apart from those internally specified under WRIGHT = T and
listed above, may also be upgraded to Semi-fatal by setting the Namelist
parameter ERRNO(n) = T where n – in the range 1 to 299 – defines a particular
error number. In effect ERRNO allows the user to define their own additional set
of WRIGHT = T errors. Its default values are clearly all F.
If error n occurs – and ERRNO(n) = T – then an additional Semi-Fatal error
490/491/492 (corresponding to Warning/Serious Warning/Non-fatal Error) is
generated and will therefore, for example, prevent a .UFN file being carried
forward into SATALL.
ERRNO is a new “beta” feature in 11.1 and we recommend caution in using it.
5120257 / Apr 15 6-75

Section 6
6.13 Extra Input Network File: the X-File
6.13.1 General 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, flare lengths and APRESV may also 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:

(i) A set of namelist parameters.
(ii) Node-based data contained between 11111 and 99999 delimiters following
standard SATURN conventions.
(iii) Link-based data under 22222.
(iv) 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.
Finally we note the similarities between inputs within SATNET using X-files and
within P1X using global data fields; see 11.9.17.
6.13.2 X-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.
Default: 0
NFCI The position of the capacity index data on the link records. (0, 1, 2…)
Default: 0
The position of FLARE-X (flared PCUs for X-turns) on the link records (0, 1,
NFLX
2 ...). N.B. Not fully operational yet.
5120257 / Apr 15 6-76

Section 6
Default: 0
The position of FLARE-F (flared PCUs for nearside turns) on the link records
NFLF
(0, 1, 2 ...). N.B. Not fully operational yet.
Default: 0
The position of APRESV on the link records (0, 1, 2 ...). N.B. Not fully
NFAPV
operational yet.
Default: 0
NFGAP The position of the GAP data on the turn records. (0 or 1)
Default: 0
6.13.3 X-File Node Records

These appear as 11111 records. At the moment however they are unused.
6.13.4 X-File Link Records

These appear as 2222 records provided one or more of the parameters NFTAX,
NFRBKS, NFCI, NFLX, NFLF and/or NFAPV have been defined in order to input
link-based values for TAX, RBKS, Capacity Index, Flare-X, Flare-F and/or
APRESV respectively.
The records are formatted as followed.
Cols. 1-5 The A-node, A
6-10 The B-node, B
11-80 Data 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, NFCI = 2 and all other link pointers are
zero this implies that the first data item is a TAX value and the second is a
capacity index (CI); RBKS etc. values are not used.
Since the data is in free format it may appear in any columns beyond column 10
(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.
Note that all the above link-specific values may also be defined: (a) either as
global values via &PARAM or (b) link-specific values using the second link records
(6.4.14).
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 21.
6.13.5 X-File Turn Records

These appear as 33333 records provided that NFGAP have been defined. The
records are formatted as followed.
5120257 / Apr 15 6-77

Section 6
Cols. 1-5 The A-node, A

6-10 The B-node, B
11-15 The C-node, C
16-80 Data 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.
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
5120257 / Apr 15 6-78

Section 6
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
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
6.15 FIFO, TOPUP and DOUBLE – 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 – or whether the
repetition should lead to an error. Three logical parameters, FIFO, TOPUP and
DOUBLE, control the decision in different circumstances.
5120257 / Apr 15 6-79

Section 6
6.15.1 FIFO – First In First Out

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 and beyond 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.
6.15.2 TOPUP
The parameter TOPUP allows the user to define simulation network data file in
terms of changes to a basic network in conjunction with the use of $Include files
within the 11111 (simulation node) and 22222 (simulation centroid connectors)
data segments (only).
N.B. After its first introduction in 10.8.16 the functionality of TOPUP was extended
in 10.9.15 by defining an auxiliary parameter DOUBLE = T, whose use is now
strongly recommended. However, for reasons of historical order, the description of
TOPUP that follows assumes DOUBLE = F. If you do wish to use the
recommended functionality of TOPUP please read Section 6.15.3 in conjunction
with 6.15.2.
5120257 / Apr 15 6-80

Section 6
Thus, if a base network has been set up in which all (or possibly most) of the
11111 data is held in one or more $Include files and the user wishes to create an
alternative network which differs only with respect to minor changes to one or two
simulation nodes (e.g., by changing the signal settings) then they proceed as
follows:
Set TOPUP = T within &PARAM;
Include the full data records for the modified simulation nodes at the top of the
11111 data records in the network .dat file, i.e., before any $INCLUDE records
appear (but if DOUBLE = T, see below, either the “main” 11111 data records or
the $INCLUDE file may come first);
Reference the complete base network data coding by one or more $INCLUDE
records which follows the modified data.
If the nodes included under (ii) are also included within the subsequent
($INCLUDE) file(s) then the node data records under (iii) are ignored and those in
the “main” .dat file are accepted. I.e., it is effectively a case of LIFO discipline –
Last In, First Out.
Note that if TOPUP = F (its default) then the fact that certain nodes are coded
twice would be treated as a semi-fatal error. The advantage of TOPUP = T is that
the user does not need to explicitly delete the old node records and, if the
$Include file is being continually updated, those updates (apart from the
duplicated nodes) will be automatically taken on board in the changed network(s).
Note that the “correct” node coding must always appear at the top of the 11111
data segment (i.e., before $INCLUDE) and the ignored coding can only be within
a $INCLUDE file (but not if DOUBLE = T – see below). If data for the same node
appears twice in the same file it is a semi-fatal error.
Deleting Simulation Nodes
As a variation on the above theme it is possible to “delete” a simulation node in a
later data set by including a single node record in an earlier data set which
consists only of a negative simulation node number in columns 1 to 5 (or, in the
case of a 5-digit node number, in columns 1 to 6), in which case the node will be
“ignored” (i.e., “deleted”) if it appears later.
Application to 22222 Centroid Data
The same “LIFO” principle may also be applied under the 22222 simulation
centroid connector data; if a zone record appears before a $Include record any
references to that zone in the $Include file are ignored. Note, however, that it is
not possible to “delete” a zonal centroid connector by inputting a negative zone
number first.
TOPUP was first introduced in SATURN 10.8.16.
6.15.3 DOUBLE
A more forgiving version of TOPUP is provided by setting a subsidiary parameter
DOUBLE = T in &PARAM. If both TOPUP = T and DOUBLE = T (defaults = F and
T respectively) then any distinction between data in the main 11111 segment and
5120257 / Apr 15 6-81

Section 6
in $INCLUDE files is dropped and duplicated simulation node data may appear in
either the main .dat file or in one or more $INCLUDE files independent of the
order. The first version of the node data encountered always becomes the
accepted version and all later versions are skipped over.
In addition with DOUBLE = T it is not necessary to have any “proper” node data
within the main 11111 segment; it may simply reference a string of $INCLUDE
files. For example, the following sequence would be an acceptable – and probably
very sensible – method for progressively defining “scenarios”:
11111
$INCLUDE do_something.dat
$INCLUDE do_minimum.dat
$INCLUDE base_year.dat
99999
Thus the do minimum .dat file would over-write certain data defined in the base
year and do-something could in turn over-write data coded in either the do
minimum or base year scenarios.
A (Semi) Fatal Error 421 still results if data for the same node appears more than
once in the same data segment (main or $INCLUDE). Equally semi-fatal errors
result if a negative (delete this node) number appears more than once or if the
negative node number appears after the node data which it is intended to delete.
DOUBLE was first introduced in SATURN 10.9.15 with a default value of .FALSE.,
largely for historical compatibility, but its default was changed to the
recommended value of .TRUE. in the release version 10.9.22.
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 Aa 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)
10 An input trip matrix .ufm file for checking purposes
(Optional – if FILTIJ has been defined)
11 Output .ERL file used to store sorted node-based error messages
12 Scratch file used to store error messages for the output .ERL file
13 Input .ERL file defined by FILERL in &OPTION
(Optional)
5120257 / Apr 15 6-82

Section 6
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)
18 An input UFS file containing pre-loaded flows; see 15.5
(Optional – PLOD = 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 and/or count data
from FILMCC. See 15.14.5.
(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
(Optional)
27 An input UFS file containing data from a previous run to be used under
PASSQ. (Optional - PASSQ = T)
29 A scratch file used to input BMP/CDF/UNION files as required.
5120257 / Apr 15 6-83

Section 6
6.17 Version Control
JOB NUMBER: 5120257 DOCUMENT REF: Section 6.doc
Revision Purpose / Description
Originated Checked Reviewed Authorised Date
10.9.10 SATURN v10.9 Release DVV DG IW IW 04/09/09
10.9.12 SATURN v10.9 Release (Full) DVV DG IW IW 22/10/09
10.9.17 Web release – Jun 10 DVV NP IW IW 22/06/10
10.9.22 Web release – Dec 10 DVV AG IW IW 06/12/10
10.9.24 SATURN v10.9 Release (Full) DVV AG IW IW 23/05/11
11.1.09 SATURN v11.1 Release (Full) DVV AG IW IW 31/01/12
11.2.01 SATURN v11.1 Beta Release DVV JS IW IW 07/12/12
11.2.05 SATURN v11.2 Release (Full) DVV JS IW IW 17/03/13
11.3.03 SATURN v11.3 Release DVV SN IW IW 31/03/14
11.3.07 SATURN v11.3.07 Release DVV DAS IW IW 26/09/14
5120257 / Apr 15 6-84

Section 6

Section 6

Uploaded by

Copyright:

Available Formats

You might also like

Section 6

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Section 6

Uploaded by

Copyright:

Available Formats

SATURN MANUAL (V11.

Preparation of a Network Data File

6. Preparation of a Network Data File

5120257 / Apr 15 6-1

Preparation of a Network Data File

FIXED COLUMN CONVENTIONS

SUPPLEMENTARY INPUT FILES

6.1 Option Specification Records (Mandatory)

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

5120257 / Apr 15 6-2

Preparation of a Network Data File

5120257 / Apr 15 6-3

Preparation of a Network Data File

6.2 Network Title (Mandatory)

6.3 Parameter Specification Records (Mandatory)

5120257 / Apr 15 6-4

Preparation of a Network Data File

The parameters are grouped under LOGICAL, INTEGER, REAL and

6.3.1 Logical Parameters

5120257 / Apr 15 6-5

Preparation of a Network Data File

Default: .TRUE. (.FALSE. prior to 10.9)

5120257 / Apr 15 6-6

Preparation of a Network Data File

5120257 / Apr 15 6-7

Preparation of a Network Data File

5120257 / Apr 15 6-8

Preparation of a Network Data File

assumed to be in units of kilometres and minutes rather than metres and

5120257 / Apr 15 6-9

Preparation of a Network Data File

5120257 / Apr 15 6-10

Preparation of a Network Data File

Default: .FALSE. (Use .TRUE. with caution; see 7.1.3)

5120257 / Apr 15 6-11

Preparation of a Network Data File

matrix to be assigned are zero; else F is preferable. See 7.11.12.

5120257 / Apr 15 6-12

Preparation of a Network Data File

6.3.2 Integer Parameters

5120257 / Apr 15 6-13

Preparation of a Network Data File

5120257 / Apr 15 6-14

Preparation of a Network Data File

5120257 / Apr 15 6-15

Preparation of a Network Data File

within SATALL; see 9.2.3.

MCALG Algorithm used by multi-core assignments. See 15.53.4.1.

5120257 / Apr 15 6-16

Preparation of a Network Data File

MAXLSF these limits generate a warning message.

5120257 / Apr 15 6-17

Preparation of a Network Data File

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

6.3.3 Real Parameters

5120257 / Apr 15 6-18

Preparation of a Network Data File

5120257 / Apr 15 6-19