SATURN MANUAL (V10.

9)

Preparation of a Network Data File

6. Preparation of a Network Data File

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

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

1) OPTION SPECIFICATION RECORDS

2) NETWORK TITLE

3) PARAMETER SPECIFICATION RECORDS

4) THE SIMULATION NETWORK

5) THE SIMULATION CENTROID CONNECTORS

6) BUFFER NETWORK/LINK DATA

7) RESTRICTED TURNS AND LINKS

8) NODE AND/OR ZONE CO-ORDINATES

9) FIXED ROUTES (E.G. BUSES)

10) COUNTS OF LINK AND/OR TURNING VOLUMES

11) GENERALIZED COSTS (Multiple User Classes)

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

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

(N.B. For purely “aesthetic” reasons the single number, say 1, is normally written
as ‘11111’ so as to take the same number of columns as the ‘99999’ terminators.
Hence we refer to, e.g., the ‘33333 records’.)

5101396/May11 6-1
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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).

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.

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).

5101396/May11 6-2
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

6.1 Option Specification Records (Mandatory)

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

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

The following 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”:

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
UPDATE
to provide good initial estimate of flow-delay parameters. See
Section 15.3.

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

PASSQ
See Section 17.3.

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

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

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

If TRUE 3 fields (A, B and C with C = 0) are required to define a link

PLFF3 as opposed to a turn for a free format pre-load data file. See
Section 15.5.4.

If TRUE the assignment uses a “Warm Start” on its first

WSTART
assignment. See Section 22.3.

If TRUE and the file named under UPFILE does not exist then
DIADEM setting either UPDATE or WSTART to T does not result in a semi-
fatal error. See 15.51.

If TRUE the internal CASSINI steps to over-ride various settings

CASINI within SATNET are invoked. See 15.54. N.B. (Note that 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

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

5101396/May11 6-3
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

characters.)

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

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

The name of the network (.ufs) file which is to be “pre-loaded”. See

FILPLD
15.5

FILERL The name of the input .ERL file used to monitor errors. See 15.58.

The name of the CASSINI Control file defining the convergence strategy
FILCAS
to be applied. See 15.54.6.

The name of the ASCII CSV file reporting the convergence of the demand
FILGAP
model. See 15.54.6

The CASSINI file which specifies the type of demand model used and
CASTXT the 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

5101396/May11 6-4
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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. 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.

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.

5101396/May11 6-5
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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
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.
Default – TRUE. (.FALSE. prior to 10.9)
AUTONA If TRUE “optimum” values of NITA and/or UNCRTS are calculated at
each separate assignment within SATALL. See Section 9.5.4.
Default – .TRUE. (.FALSE. prior to 10.9)
AUTOX If TRUE any uncoded external simulation nodes are automatically coded
using the best available data. See Section 15.12.
Default – TRUE

5101396/May11 6-6
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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 - .FALSE.
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.
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
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 (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.

5101396/May11 6-7
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.
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.
FIFO If TRUE, if and when a data item appears twice, the first data entry is
discarded and the last one used; if FALSE the first entry is always used.
See 6.15.
Default - .TRUE.
FOZZY If TRUE the program will try to “interpolate” unconnected nodes in bus
routes. See Sections 6.9.2 and 15.18
Default - .FALSE. (RECOMMENDED .TRUE.)
FREDDY If TRUE an output .rgs file containing a listing of all signal settings is
created. See 11.9.14.
Default - .FALSE.
FREEKY If TRUE then the extra KNOBS data records in the 33333 records are
input as “free format”; see 6.6.
Default - .FALSE.
FREEXY If TRUE then the supplementary node data in the 66666 records (i.e. X,
Y co-ordinates) are input as “free format”; see 6.8.
Default - .FALSE.
FREE77 If TRUE counts under 77777 are read as free format. See note 12), 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.

5101396/May11 6-8
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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 (KilometERS and MinuTes!)
If TRUE the travel distances and times input on buffer link records are
assumed to be in units of kilometres and minutes rather than metres and
seconds. Outputs in P1X assume the same units. (Useful for very large
scale buffer networks only.)
Default - .FALSE.
KINKY If .TRUE. the standard speed-flow curves used for both the simulation
and buffer networks have a “kink” or discontinuity at V=C, above which
(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.

5101396/May11 6-9
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

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

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 in order to
identify a zone; see 5.1.6 and 6.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.

5101396/May11 6-10
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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. (Recommended .TRUE.)
Default - .FALSE.
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
Sections 8.4 and 7.1.3.
Default - .FALSE.
RTP108 If TRUE random delays (LRTP > 0) are set by “estuary” rather than by
“river”. See 8.6.3.

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

SATOFF If TRUE signal offsets are optimised within SATALL; see Section 15.31.4
and 9.12.2.
Default - .FALSE.
SATTIT If TRUE the standard supplementary data file SATTIT.DAT is used to
define DA code text names. See 15.21.
Default - .TRUE
SAVEIT If TRUE the link costs as used for each assignment tree build are saved
on a UFC file for subsequent analysis; e.g., to create forests. See
Section 15.23.
Default - .TRUE.
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.

5101396/May11 6-11
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.
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
matrix to be assigned are zero; else F is preferable. See 7.11.12.
Default - .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.
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.

5101396/May11 6-12
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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 - .FALSE. (but recommended .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 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
IFRL As IFCC but for the “real” buffer links as opposed to the centroid
connectors. See Note 3 under 6.6.
Default: 1

5101396/May11 6-13
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

IPERT Control of perturbation mode under path-based and OBA assignment. 1

– Perturbation used; 0 – Not. See 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 5%) from one assignment to the next.
See Section 9.1
Default: 95 % (Changed from 90% in 10.5)
KDF(u) Choice of a cumulative density function under KOB = 3 for User Class u.
See 7.3.2.3.
Defaults: 1
KLUNK Choice of method for variable speeds under CLICKS. 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.
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).
See Section 9.2.3
Default: 0
KORN “Kontrol of Random Numbers” – the seed value for the series generation
of random numbers used in SUE. See Section 7.2.4.
Default: 0
KPHMIN / Simulation link speeds and free flow speeds on buffer links with speeds
KPHMAX outside the range KPHMIN to KPHMAX generate warning messages in
SATNET.
Defaults: 10 and 100 kph respectively.

5101396/May11 6-14
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

LCY Duration of the common traffic signal cycle time in seconds. See
Section 8.1 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 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.
Default: 15.
MASL F The number of simulation assignment loops over which the input trip
matrix is kept fixed under elastic assignment; see 7.5.3.4.
Default: 0
MAXDTP Maximum “transient” delay (in minutes) permitted for a simulated turn.
See 8.4.1
Default: 10 (Changed from 0 in 10.5)
MAXQCT MAXimum Queue Clearance Time (in minutes) for queued traffic at the
end of a simulation time period. If 0, it is ignored. See 8.4.1
Default: 60 (Changed from 0 in 10.5)
MAXZN Maximum number or ‘name’ used to define a zone. See 5.1.6.
Default: 500.

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

5101396/May11 6-15
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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
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)

5101396/May11 6-16
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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
Default: 4 (Changed from 1 in 10.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)
NITA_S The (maximum) number of iterations to be used in the single post-
convergence assignment under SAVEIT: If zero, assume NITA. See
15.23.3.
Default: 99
NITS_M The minimum number of simulation iterations. See 8.1 and 8.3.2
Default: 5
NITS Maximum number of simulation iterations. See 8.1 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)

5101396/May11 6-17
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

NUC Number of time-units into which the cycle is divided in the simulation;
global value (maximum value 25). See 8.1 and 15.15.2.
Default: 15
NUCJT(j) NUC value for simulation junction type j (e.g., 3 for signals). Maximum
125. See 15.15.2.
Default: all 0
NUCMIN Minimum number of time-units into which the cycle is divided in the
simulation (maximum value 25). See 8.1. 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.
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 “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.
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)

5101396/May11 6-18
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

BETA_2 (u) As BETA but for nested logit models. See 7.6.3 /7.6.4.
Default: 0.1
BETA_D (u) As BETA but for distribution models. See 7.10.2.
Default: 0.1
BETA_T (u) As BETA but for time-choice models. See .
Default: 0.1
BTKNOB(b,k) Bus Times (in seconds) per KNOB data field k for all routes within bus
company b. See 15.44.
Default: 0.0
BUSPCU(b) Factor to convert bus flows for company ‘b’ into P.C.U.’s. See 6.9.1,
and, in particular, 6.9.3 for subscripted values of BUSPCU.
Default: 3.0
BUSSPK(b) Bus Stop Seconds Per Kilometre for all routes within bus company b.
See 15.44.
Default: 0.0
CAPMIN Minimum capacity to be expected for any (give-way) turn; any junction
with lower capacities will be factored up to CAPMIN (pcu/hr). See 8.2.
Default: 30.0
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 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, 8.2.5.2 and 8.2.6.
Default: 2.0

5101396/May11 6-19
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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)
GAPM As GAP but for merging turns.
Default: 3.0 seconds (NB: historical default value)
GAPR As GAP but for entry onto roundabouts.
Default: 4.0 seconds (NB: historical default value)
(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 and 15.2.
Default: 1.0
PCNEAR Percentage change in flows judged to be “near” in successive
assignments. See 9.1.
Default: 5.0
PMAX Maximum value of the power used in the simulation flow-delay curves.
See 8.4.2.
Default: 10.0
POWER(u) Elastic assignment parameter giving the elasticity for MCGILL = 2 or 4.
See 7.7.1 and 7.12.2.
Default: 1.0
PPK Pence Per Kilometre - used to convert distances into generalised costs.
See Section 7.11.1.
Default - 0.0

5101396/May11 6-20
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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 (and (and
QVCMIN in 6.3.3).
Default 226
QVCMIN Minimum V/C ratio at which delays are applied to Q-turns. See Appendix
Q (and QVDMAX in 6.3.2).
Default 0.75
SHADOW An assumed speed in kph for the “shadow network” assignment option;
see 7.11.10.
Default: 0.0
STPGAP Critical gap value (IN %) used to terminate assignment-simulation loops
when KONSTP = 1. 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 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 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

5101396/May11 6-21
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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 – 01. (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
XFSTOP Wardrop assignment stopping parameter for minimum step length. See
7.1.5.
Default: 0.05%
XYUNIT Number of metres corresponding to an integer value of 1 as used to
define node/zone co-ordinates. See 6.8.
Default: 1.0

6.3.4 Character Parameters

CINAME(i) The text name to be associated with capacity index i; see 5.1.9.
Default - blank. Maximum length: 20.
COINS The “smaller” unit used to define tolls; see 20.3
Default - ‘Pence’
CURNCY The “larger” unit used to define tolls; see 20.3.
Default - ‘Pounds’
FILGIS The “file name” of the GIS file associated with this particular network;
see Section 5.7.
Default - blank (i.e., no file)
FILTIJ The “file name” of the .ufm trip matrix file associated with this particular
network and which will be assigned during the assignment.
Default - blank (i.e., no file defined at this stage)
FILCGH The “file name” of the .ufm cost matrix cOij 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
assignment cOij. See 7.7.1 and 7.12.3 (and 7.6.4 for its use with nested
logit).

5101396/May11 6-22
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.
Default - blank (i.e. no file).
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 file name of the .bmp file used to define a background display for
P1X plots. See 11.3.6.
Default – blank
FILRED The “file name” of the input .ufm matrix containing the initial estimate of
the road trip matrix under elastic assignment if REDMEN = T; see
7.5.3.2 and 7.12.3.
Default - blank (i.e. no file).
ROADIJ The “file name” of the output .ufm matrix containing the elastic road trip
matrix under elastic assignment. See 7.12.3.
Default - blank (i.e. no file).
FILVSD The “file name” of the input text file containing CLICKS values
disaggregated by Capacity Index and Vehicle Class. See 15.47.2
Default - blank (i.e. no file).
UCNAME(u) The text name to be associated with user class u (5.8.1).
Default - blank. Maximum length: 40.
VCNAME(v) The text name to be associated with vehicle class v (5.8.2).
Default - blank. Maximum length: 40.
XFILE Name of the supplementary X-file; see 6.13.
Default - blank (i.e. no file)
XYFORM The “format” used to define node X, Y co-ordinates under the 55555
data records - see Section 6.8.
Default - 2I5.

N.B. Most namelist parameter names representing files have alternative spellings
so that, e.g., FILTIJ is also recognised by TIJFIL, FILCIJ by CIJFIL etc. etc.

5101396/May11 6-23
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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 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 PIX (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.

5101396/May11 6-24
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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:
0 for EXTERNAL NODES
1 for PRIORITY JUNCTIONS
2 for ROUNDABOUTS
3 for TRAFFIC SIGNALS
4 for A ‘DUMMY’ NODE
5 for a ROUNDABOUT with U-turns
16-20 JCIR Time to circle roundabout (in seconds)
(Roundabouts only)
OR
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 - 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.
(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.

5101396/May11 6-25
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

(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 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.)

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)
21-25 LCAPY Link capacity (pcu’s per hour)
29 S if speeds are used in 11-20, T if time; if blank then SPEEDS
decides. See 6.4.12.
36-40 N The power ‘N’ used in the speed-flow curve with a decimal in
column 39 (by default – see 2.8.3)
43-45 INDEX A “link index” in the range 0-999 (where 0 or blank implies a
“non” index); see 5.1.9

5101396/May11 6-26
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

RECORD TYPE 3 – SIGNAL DATA

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

N.B.

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

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

(iii) 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:
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).

5101396/May11 6-27
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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
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
5101396/May11 6-28
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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. This allows for vehicles stacking in their reserved lanes
and discharging during the amber phase. See 8.2.4.

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).

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)

5101396/May11 6-29
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

5101396/May11 6-30
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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;

(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.

5101396/May11 6-31
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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 the
exists 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.

5101396/May11 6-32
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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

5101396/May11 6-33
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

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 15.40 and 15.40.7 in particular for
a discussion of the differences (and similarities) between the two methods

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.

5101396/May11 6-34
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

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.

5101396/May11 6-35
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

6.4.3 Stage Definition, Duration, Inter-green and Offsets

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

and the movements that are green during each stage.

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

The durations of the stage time and the inter-green period are defined in fields 1
and 2 on Record Type 3, i.e., columns 11-15 and 16-20 respectively. See also
6.4.13 for how to define upper and/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.

5101396/May11 6-36
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

(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
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.

5101396/May11 6-37
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

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
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

5101396/May11 6-38
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

5101396/May11 6-39
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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

6.4.6.2 Setting Saturation Flows

Setting “correct” saturation flows is as much an art as a science and it is not really
the role of this Manual to supply precise numerical formulae to apply since every
area to be modelled will have its own particular characteristics which will influence
saturation flows. However, in general terms, one can say that the following
features 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”.

5101396/May11 6-40
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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:

 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
5101396/May11 6-41
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

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

5101396/May11 6-42
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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!

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.

5101396/May11 6-43
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

In addition the allocation of turns to lane is also defined at the point where the
flare begins. In the above diagram the ahead ‘A’ movement would be allocated to
lanes 1 and 2 whereas the right-turn ‘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:

 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

5101396/May11 6-44
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

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.

5101396/May11 6-45
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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!

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.

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.

5101396/May11 6-46
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

(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 ahead movements.

(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 ahead movements and make use of
the FLAREX etc. facilities above.

By coding a single shared lane the potential for X-turns to block straight ahead
movements 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. See
Serious Warning 165.

Similarly coding two outside lanes both of which are shared between X-turners
and straight ahead movements is strongly not recommended on the grounds that
it implies internal weaving of traffic. See Serious Warning 162.

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

5101396/May11 6-47
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data 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

Indeed much of the time the stacking capacity may just as well be left blank since
STACK is only used to model blocking back - see Section 8.5. As long as the
default value exceeds the queue on a link it has no affect whatsoever on the
simulation. However, if it does enter into blocking back calculations, it may be
important to set a “true” value; see 8.5.7.

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. 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.

To do so you must first insert a ‘*’ in column 11 of the link data record (type 2),
indicating that an extra record (type 2B) is to be inserted before the next link data

5101396/May11 6-48
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

record, containing speed-flow data. (N.B. Do not include a * if LANES = 0, ie.,

columns 12-15 are blank or zero, and the link is therefore one-way outbound.
This can sometimes be forgotten if an in-bound link is converted to out-bound
only.)

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 t0 in seconds / free flow speed in kph

2) the time at capacity tC in seconds / capacity speed in kph

3) the link capacity C (sometimes referred to as the “pinchpoint” capacity)

4) An ‘S’ or ‘T’ to indicate speeds or times above

5) A “power” n

6) A “link index” or “capacity index” (optional – 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) = tC. For V > C the time is
constant, tC.

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

Note that 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.

5101396/May11 6-49
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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

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

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.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:

Tmin < T

&

T > Tmax

The rationale behind using a < symbol for “minimum” and > for “maximum” is that
otherwise an input field such as 20<30 could either be interpreted as a green time
of 20 seconds with a maximum of 30 or as a green time of 30 with a minimum of
20. Thus 20<30 implies that a minimum stage length is being set (Tmin = 20; T =

5101396/May11 6-50
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

30) whereas a maximum stage length would need to be written as (somewhat

counter intuitively) as 20>30 (Tmax = 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 and FLAREF

Post release 10.9.20 it is possible to use Link record 2B to define various link
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).

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.

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:

(a) 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. Nor is it case sensitive.

(b) 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.)

(c) 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.

(d) 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.
5101396/May11 6-51
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

(e) 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,

(f) 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.

(g) Recall that both FLAREX and FLAREF are defined in units of PCUs, not
metres. And that TAX is also defined in units of PCUs.

(h) 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.

6.4.15 Link-specific TAX values

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.

5101396/May11 6-52
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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 A-node on the first connected simulation link
11 -15 B-node on the first connected simulation 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.

5101396/May11 6-53
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

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.)
RECORD 1
Cols. Description
1 A ‘C’ if the following node refers to a zone or a ‘D’ if this is a default speed-
flow curve; see (8) and (13).
2 -5 The A-node for the link.
6 A ‘C’ to indicate a zone number following.
7 -10 The B-node for the link.
11 -15 The link time (in seconds) or speed (in kph) under free-flow conditions.
16 -20 The link time (in seconds) or speed (in kph) at capacity.
21 -25 The one-way link capacity (in pcus per hour)
28 A one-way/two-way indicator - see note (3).
29 An ‘S’ if speeds were defined above; otherwise times are assumed.
31 -35 The link distance (in metres).
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).
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,
5101396/May11 6-54
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

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

5101396/May11 6-55
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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 DCSV = F or T.

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

10) Note that when the second KNOBS records are required it is quite easy
to forget and leave a record out, in which case the 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 = F in &PARAM which implies that any “node”
whose number in less than or equal MAXZN is a zone. This may be a
useful option in converting data sets obtained from other suites although
its long-term use is not recommended.

14) Methods exist to change the input formats to user-set conventions; see
15.36.

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.

5101396/May11 6-56
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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. Turns in the buffer network CANNOT be restricted as they do not
exist!

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

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

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

by the inclusion of either a $ or & symbol preceding the numerical value.
The absence of either implies a (possibly 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
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.

5101396/May11 6-57
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.12 for an annotated example.

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

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. Note that it is
also possible to redefine the SATURN input format (see note (6) below) to
accommodate different data sources.

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

(N.B. A different format is required under the DUTCH Option - see Section 15.20
or if FREEXY = T - see note (10) below.)
Cols. Description
1 A‘C’ if columns 2 to 5 contain a zone number;
or ‘S’ to denote a sector; otherwise blank or part of the node number to

5101396/May11 6-58
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

denote a “real” node.

2 -5 The node, zone or sector number; see note 7)
6 -10 Its X co-ordinate (as an integer); see note 6)
11 -15 Its Y co-ordinate (as an integer)
16 -20 (a) For zones, its corresponding sector number
(b) For nodes, no extra data is currently processed

NOTES:

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

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

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

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

3) The units used for co-ordinates are arbitrary but their “size” in metres
should be specified by XYUNIT. E.g., if XYUNIT = 10 then it is assumed
that an increment of 1 in a co-ordinate 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 the parameter IROCKY has been used
to define “default” sector names any data given here “over-rides” that
definition. If the sector field is left blank however the value given using
IROCKY is assumed.

5) In addition to defining the sectors associated with zones this data section
is also used to explicitly define X, Y co-ordinates for sectors. Sectors not
explicitly defined have their co-ordinates set to the arithmetic mean of
their zones.

6) The precise columns (beyond column 5) occupied by the node X,Y co-
ordinates and their format may, in fact, be re-defined by the user via the
namelist parameter “XYFORM”. Thus using 5 columns each with no
decimal corresponds to the FORTRAN “format” 2I5; if XYFORM = 2F10.2
then the X co-ordinate would be contained in columns 6 to 15 with a
decimal in column 13, while the Y co-ordinate would be in columns 16 to
25, decimal in column 23. See also 15.35 and note 10). In all cases the
first (left hand) column in each field is the one in which a ‘C’ or an ‘S’ is
inserted. These are not explicitly mentioned in the format. (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
uses all 6 available columns.)
5101396/May11 6-59
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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) 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 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 interpreted as a zone. This
may be useful in converting data from external data sets although its long
term use is not recommended.

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

5101396/May11 6-60
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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

Bus routes are “seen” by SATURN as fixed loads to be added to the “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.

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;
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. Alternative conventions for specifying
nodes are given in 6.9.2 while 6.9.5 describes how to include “timing points”

6.9.2 Route Definitions and Formats

1) 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.

5101396/May11 6-61
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

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).

5101396/May11 6-62
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

 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.

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

The R option allows one to code a 2-way route which differs marginally in
the two directions. Thus if the “out” direction is A… IJL…Z and the "in"
direction is Z… LKI… A then one may code it using R as A… IKL… Z;
i.e., the same as the out direction apart from one node.

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

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

9) If a single bus routes uses more than 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.

5101396/May11 6-63
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.)

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.

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.

5101396/May11 6-64
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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
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.

5101396/May11 6-65
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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 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 pcus per hour (see note 13).
Cols. 21-25 The second volume ...
Cols. 26-30 up to MCCS volumes.

NOTES:

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

2) Each set of 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.

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

5101396/May11 6-66
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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+ (26+ if DUTCH = T) are read as “free format” (e.g., CSV)
rather than in fixed columns.

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.

5101396/May11 6-67
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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
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)
21 -25 Value of distance in pence per kilometre (Assumed decimal point in
Column 23)
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) and (8). 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;
5101396/May11 6-68
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

 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
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) 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.)

5101396/May11 6-69
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

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

5101396/May11 6-70
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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 existing warnings, serious warnings and/or non-fatal errors may
be 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.

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.

5101396/May11 6-71
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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 may be defined.

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

XFILE = ‘netplus.dat’

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

(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

5101396/May11 6-72
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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, 2 ...). N.B. Not fully operational yet.
NFLX
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 and /or NFLX have been defined in order to input link-based
values for TAX, RBKS, Capacity Index and/or Flare-X 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.

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.

5101396/May11 6-73
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

6.13.5 X-File Turn Records

These appear as 33333 records provided that NFGAP have been defined. The
records are formatted as followed.
Cols. 1-5 The A-node, A
6-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

5101396/May11 6-74
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

22222 * Commences simulation C.C data

1 59 45
2 60 46
3 61 62
4 63 49 49 63
(Remainder of simulation centroid connector data)
99999
33333
3 2 28 56 2500 1 100 3.1
1978.00 * Extra (KNOB) data
29 2 21 42 1250 2 90
1983.00 * field, presumably
2 3 28 56 3750 2 100 3.1
1983.00 * some sort of date
C 2 59
9999.00 * with a default of
C 3 60
9999.00 * 9999 for centroid
C 4 61
9999.00 * connectors
(Remainder of the buffer network/link data)
99999
44444 * Banned links/turns
4 5 -1 0 30 * Link banned to UC 1, open to UC 2,
* 30 seconds penalty to UC 3
34 6 0 -2 * Open to UC 1 but banned to 2 and 3.
31 32 0 -1 0 * Banned to UC 2 only
46 51 50 10 -2 * 10 second penalty to UC 1, banned
* turn for classes 2 and 3.
16 17 18 -2 * Banned turn for all UC - therefore
* presumably a bus-only turn.
99999
55555 * Co-ordinates
1 17 53
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

5101396/May11 6-75
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network 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.

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.

5101396/May11 6-76
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

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 functionality
of TOPUP please read Section 6.15.3 in conjunction with 6.15.2.

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:

(i) Set TOPUP = T within &PARAM;

(ii) 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);

(iii) 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.

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.
5101396/May11 6-77
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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 then any
distinction between data in the main 11111 segment and 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 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.

5101396/May11 6-78
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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)
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)

5101396/May11 6-79
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

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.

5101396/May11 6-80
10_09_24_Section 6.doc
SATURN MANUAL (V10.9)

Preparation of a Network Data File

6.17 Version Control

JOB NUMBER: 5101396 DOCUMENT REF: Section 6.doc

Revision Purpose / Description

Originated Checked Reviewed Authorised Date

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

2 L4L DVV 28/05/06

3 Upgrade to V2 Template IW 22/06/06

3.1.4 STPGAP etc. added DVV 02/07/06

3.2 Web release – Sept 06 DVV NP IW IW 08/09/06

3.3 Web release – Jan 07 DVV NP IW IW 04/01/07

3.4 SATURN v10.7 Release DVV NP IW IW 12/03/07

SATURN v10.7 Patch #3 DVV NP IW IW 18/06/07

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

3.6 SATURN v10.8 Release DVV NP IW IW 19/03/08

3.7 Web release – Jul 08 DVV NP IW IW 07/07/08

3.8 Web release – Dec 08 DVV NP IW IW 12/12/08

3.8.21 Web release – Feb 09 DVV NP IW IW 16/02/09

3.8.22 Web release – Jun 09 DVV NP IW IW 16/06/09

10.9.10 SATURN v10.9 Release DVV DG IW IW 04/09/09

10.9.12 SATURN v10.9 Release (Full) DVV DG IW IW 22/10/09

10.9.17 Web release – Jun 10 DVV 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 DG IW IW 31/05/11

5101396/May11 6-81
10_09_24_Section 6.doc