SATURN v11.3.12 Manual (Main) PDF

SATURN MANUAL (V11.
3)
Contents
Simulation and
Assignment of
Traffic in
Urban
Road
Networks
Manual - Version 11.3

April 2015
Version 11.3.12
5120257 / Apr 15 i
Master Main Document
SATURN MANUAL (V11.3)
Contents
Contents
Section Page
1. Introduction 1-1
1.1 The Function of SATURN 1-1
1.2 Hardware / Software Requirements 1-3
1.3 Documentation 1-5
1.4 Distribution of SATURN 1-5
1.5 Contents of the Suite 1-6
1.6 Version Control 1-7
2. The SATURN Suite – An Overview 2-1
2.1 The Structure of Assignment Models 2-1
2.2 Trip Matrices in SATURN 2-3
2.3 Networks in SATURN 2-4
2.4 Route Choice in SATURN 2-5
2.5 Analysis in SATURN 2-6
2.6 General Advice on Using SATURN 2-6
2.7 Getting Started; Example Files 2-7
2.8 Text Files, Fixed Columns, Text Editors and Word Processors 2-8
2.9 Errors and Warnings: Fatal, Non-Fatal and Serious 2-10
3. The Basic SATURN Model 3-1
3.1 The Network Model Structure 3-1
3.2 Data Requirements 3-4
3.3 File Name Conventions 3-5
3.4 32-Bit SATURN Versions 3-8
3.5 Running Programs Under DOS (or Command Prompt) 3-8
3.6 Running Programs under WINDOWS: SATWIN10 and SATWIN11 3-9
3.7 SATWIN10 User Interface 3-10
3.8 SATWIN11 User Interface 3-26
4. Creating an Origin-Destination Matrix File 4-1
4.1 Trip Matrices using M1 or MXM1 4-1
4.2 Important Trip Matrix Definitions 4-3
4.3 Further Notes on Trip Matrices 4-4
4.4 Alternative Matrix Formats using M1/ MXM1 4-5
5. Network Coding – A General Description 5-1
5.1 Simulation Networks 5-1
5.2 Buffer Networks 5-14
5.3 Defining the Buffer Network 5-15
5120257 / Apr 15 ii
Contents
5.4 Capacity Restraint in the Buffer Network 5-16

5.5 Assignment and Map Networks 5-18
5.6 Building Networks: The Beginner's Guide 5-21
5.7 Geographical Information System (GIS) Data 5-26
5.8 User and Vehicle Classes 5-31
6. Preparation of a Network Data File 6-1
6.1 Option Specification Records (Mandatory) 6-2
6.2 Network Title (Mandatory) 6-4
6.3 Parameter Specification Records (Mandatory) 6-4
6.4 Simulation Network: the ‘11111’ Records 6-25
6.5 Simulation Centroid Connector Data: the ‘22222’ Records 6-54
6.6 The Buffer Network/Link Data: the ‘33333’ Records 6-56
6.7 Restricted Turns and Links: the ‘44444’ Records 6-59
6.8 Node and Zone Co-ordinates/Supplementary Data: the ‘55555’ Records 6-60
6.9 Fixed Routes (E.g. Buses): the ‘66666’ Records 6-63
6.10 Counts of Link and/or Turning Volumes: the ‘77777’ Records 6-69
6.11 Generalised Costs and/or Matrix Weights for Multiple User Classes: the ‘88888’ Records 6-71
6.12 Fatal Errors and NAFF UFN Files 6-74
6.13 Extra Input Network File: the X-File 6-75
6.14 Specimen File 6-78
6.15 FIFO, TOPUP and DOUBLE – Options for Repeated Data Input 6-79
6.16 SATNET Files 6-82
7. Assignment – The Role of SATEASY/SATALL 7-1
7.1 Wardrop Equilibrium Assignment 7-1
7.2 Stochastic User Equilibrium (SUE) Assignment 7-9
7.3 Multiple User Class Assignment 7-15
7.4 Joint Equilibrium Assignment and Variable Demand Models 7-18
7.5 SDM Assignment: 7-30
7.6 More Complex Elastic Assignment Models 7-43
7.7 Elastic Demand Functional Forms 7-49
7.8 Defining the Reference Trip and Cost Matrices 7-55
7.9 Multiple User Class Elastic Assignment 7-65
7.10 Combined Distribution and Assignment Models 7-66
7.11 Miscellaneous Assignment Procedures 7-69
7.12 Running SATEASY: A single elastic run 7-80
7.13 SATEASY: Technical Specifications 7-83
8. Simulation – The Role of SATSIM 8-1
8.1 Cyclical Flow Profiles 8-1
8.2 Accept Profiles and Capacities 8-5
8.3 Internal Simulation Iterations and Convergence 8-14
8.4 Simulation Delays, Queues and Flow-Delay Curves 8-17
5120257 / Apr 15 iii

Contents
8.5 Blocking Back 8-29

8.6 Random Delays and Queues (LRTP) 8-38
8.7 Modelling Roundabouts 8-42
8.8 Lane Choice Modelling 8-44
8.9 Simulation Network Capacities 8-52
8.10 SATSIM: Technical Specifications 8-60
9. Assignment / Simulation Loops – The Role of SATALL 9-1
9.1 General Principles 9-1
9.2 Monitoring Convergence 9-3
9.3 Averaging Flows: The Use of KOMBI and AUTOK 9-10
9.4 Continuing a Previous Assignment (The DIDDLE Option) 9-13
9.5 Making Convergence Easier 9-14
9.6 Elastic Assignment/Simulation Loops 9-19
9.7 SATALL: General Functions 9-20
9.8 SATALL Run-time Convergence Statistics 9-21
9.9 SATALL Convergence Statistics: Full Line Printer Listings 9-22
9.10 Elastic Assignment within SATALL 9-25
9.11 Multiple User Class Assignment within SATALL 9-26
9.12 Special SATALL Extensions 9-26
9.13 The SATALL Batch Procedure 9-29
9.14 The SATURN Batch Procedure 9-30
9.15 SATALL: Technical specifications 9-30
10. MX: Interactive Matrix Manipulation 10-1
10.1 Synopsis 10-1
10.2 Matrix Files: General Properties 10-4
10.3 MX File Structure 10-11
10.4 Copy/Transpose/Re-code an Input UFM File; Re-defining Zones 10-13
10.5 Matrix Input and/or Updating from a .DAT File 10-18
10.6 Select Options 10-27
10.7 Matrix Factoring 10-28
10.8 Matrix Manipulation 10-36
10.9 Statistical Analysis 10-40
10.10 Viewing and/or Editing Matrix Elements 10-41
10.11 Viewing Row and Column Totals 10-43
10.12 Matrix Graphics 10-43
10.13 Printing a complete matrix to a line printer 10-44
10.14 Printing/Dumping Row and Column Totals 10-44
10.15 Dumping a Matrix to an ASCII .DAT (Text) File 10-45
10.16 Output UFM Matrices 10-48
10.17 Stacking and Unstacking Matrices 10-51
10.18 Matrix Demand Calculations 10-51
10.19 The MX Box of Clever Tricks 10-52
5120257 / Apr 15 iv
Contents
10.20 Useful Matrix Batch Files 10-54

11. P1X: Interactive Analysis of Results 11-1
11.1 Introduction 11-1
11.2 Network Plotting (P1X): The Master Menu 11-1
11.3 System/device Definitions 11-2
11.4 P1X External File Control 11-9
11.5 The Network Window 11-13
11.6 Basic Network Display 11-16
11.7 Validation Options 11-37
11.8 P1X Analysis and Information Functions 11-43
11.9 P1X Editing Facilities 11-59
11.10 SATDB: Data Base Facilities 11-77
11.11 SATLOOK: Interactive Text Outputs 11-98
11.12 Node Editing and Graphical Display (SATED) 11-105
11.13 Graphical Network Cordoning 11-109
11.14 Pure Matrix Graphics 11-112
11.15 Convergence Statistics 11-113
11.16 P1X: Technical Specifications 11-114
11.17 SATLOOK: Technical Specifications 11-115
11.18 SATDB: Technical Specification 11-116
12. Supplementary Programs 12-1
12.1 Network Cordoning (SATCH) 12-1
12.2 Optimum Offsets (SATOFF) 12-13
12.3 Direct Examination of UF Files (DALOOK) 12-17
12.4 Direct Comparison of UF Files (DACHEX) 12-18
12.5 Transferring UF files (DADUMP and DALOAD) 12-18
12.6 SATPIG: Generating Route Flows 12-19
12.7 SATDYSK - Dynamic Time Skims 12-22
13. Deriving O-D Matrices from Traffic Counts (SATME2) 13-1
13.1 Introduction to SATME2 13-1
13.2 Matrix Estimation Data Requirements 13-16
13.3 Advice on Using SATME2 and Extra Options 13-26
13.4 Updating Multiple User Class O-D Matrices 13-38
13.5 Matrix Estimation with Aggregated Zones 13-46
13.6 SATME2 Technical Specifications 13-49
13.7 SATPIJA - Technical Specifications 13-50
13.8 SATU2 - Selected Link Matrices 13-53
13.9 “ME2” Output Files 13-54
14. Control Procedures (DOS Batch Files) 14-1
5120257 / Apr 15 v
Contents
14.1 Introduction to Control Procedures / Command Lines 14-1

14.2 File Specification within Control Procedures 14-2
14.3 The ‘SATURN’ Procedures 14-4
14.4 Extended SATURN Procedures 14-6
14.5 “LOG”, “KEY” and “VDU” Files: Running Interactive Programs “Off-line” 14-8
14.6 Namelist Parameters Set on the Command Line 14-18
14.7 Command Line Options and Batch Procedures 14-19
14.8 Extended Command Line Files: Using .XCL Files 14-19
14.9 QUIET Command Lines 14-20
14.10 QUICK Command Lines 14-21
14.11 Create Your Own BATCH Files: A Beginners’ Guide 14-21
15. Special Options and Facilities 15-1
15.1 Network Aggregation and Simplification within Intermediate Bands 15-1
15.2 Preferences files 15-6
15.3 Network Updates (The Update Option) 15-7
15.4 Updating the Trip Matrix (The Re-start Facility) 15-8
15.5 Pre-Loading Fixed Flows (The “Plod” Option) 15-10
15.6 Comparing Assigned and Observed Flows: GEH Statistics 15-12
15.7 Use of SATURN Outside the U.K. 15-14
15.8 Using SATURN as a Conventional Assignment Model 15-15
15.9 Converting Conventional Speed-Flow Curves into SATURN Curves 15-18
15.10 The use of Crow-Fly Distances (The SHANDY Option) 15-27
15.11 Coding Combined Buffer and Simulation Networks 15-29
15.12 Automatic Network Coding (The AUTOX and AUTOZ Options) 15-30
15.13 Supplementary Data for Simulation Links Using Buffer Network Inputs 15-32
15.14 Extra Link Data (Knobs) 15-32
15.15 Node-Dependent Parameters: GAP, GAPM, NUC and LCY 15-36
15.16 Simulation Link Flows and Centroid Connectors 15-39
15.17 Pcu’s, Cars, Buses and Vehicles 15-41
15.18 Interpolating Routes 15-42
15.19 Select Link Analysis (SLA) 15-43
15.20 The Dutch Option (Long Node Numbers) 15-44
15.21 Referencing Data Arrays Via Dirck Access Codes 15-46
15.22 Choice of Gap Parameters 15-48
15.23 Re-constructing Assignment Routes: The SAVEIT Option and UFC Files 15-49
15.24 Alternative Link Costs and/or Times for Tree Building 15-59
15.25 Stochastic Trees 15-62
15.26 Trees, Forests and Arboreta 15-63
15.27 Skimming Trees and/or Forests 15-63
15.28 Variable Program Dimensions 15-74
15.29 Comment Cards and Blank Records in Data Files 15-75
15.30 The Use of Sub-Files within Data Files: $INCLUDE 15-75
15.31 Setting “Optimum” Stage Green Times 15-77
15.32 Determining Fuel Consumption 15-83
5120257 / Apr 15 vi
Contents
15.33 Determining Emission Statistics 15-84

15.34 Estimating Primary and Secondary Stops 15-86
15.35 Altered Data Formats in .DAT Input Files 15-86
15.36 Turning Flows at Buffer Nodes 15-87
15.37 Repeated Assignments: Modelling Cold Starts, etc. 15-88
15.38 Non-discontinuous Speed-Flow Curves: the Kinky Option 15-88
15.39 Bus-only Lanes 15-89
15.40 Motorway Weaving Segments 15-91
15.41 SATTUBA 15-98
15.42 SATCOBA 15-102
15.43 Bitmaps within SATURN 15-107
15.44 Defining Extra Bus Travel Times (BUSSPK and BTKNOB) 15-112
15.45 Representing Walk / Pedestrian Networks 15-112
15.46 DBDUMP & P1XDUMP: Dumping Link Data to Text Files 15-113
15.47 CLICKS: Variable Free Flow Speeds by User Class 15-115
15.48 UNIQUE: Combined Queues within the Buffer Network 15-120
15.49 SATURN Summary Statistics Reporting Tool (SATSTAT) 15-121
15.50 SATMECC – Marginal Economic Consumer Costs 15-131
15.51 Running SATURN within DIADEM 15-136
15.52 Running SATURN in Parallel 15-137
15.53 SATURN Multi-Core Applications 15-140
15.54 SATURN CASSINI 15-146
15.55 QUIET & QUICK Options via SATWIN 15-154
15.56 Network Aggregation (SPIDER) 15-155
15.57 Residual (Incorrect) Path Flows and Restricted Frank-Wolfe Algorithms 15-169
15.58 Error Listing (ERL) Files 15-172
15.59 Disaggregate Network Summary Statistics 15-174
15.60 Node and/or Zone Aggregation Files 15-176
16. Simulation Network Coding Example 16-1
16.1 Traffic Signals 16-1
16.2 Roundabouts 16-3
16.3 Priority Junctions 16-5
16.4 External Nodes 16-7
16.5 Dummy Nodes 16-8
16.6 Simulation Centroid Connectors 16-9
16.7 Motorway Links 16-13
17. Multiple Time Period Modelling in SATURN 17-1
17.1 Treatment of Over-Capacity Junctions: General Principles 17-1
17.2 Actual and Demand Flow in SATURN Simulation 17-2
17.3 Linked Time Periods (The PASSQ Option) 17-3
17.4 Running Multiple Time Periods Using PASSQ: Simple Procedures 17-7
17.5 The SATSUMA Program 17-10
5120257 / Apr 15 vii

Contents
17.6 The Definition and Calculation of Queues and Delays 17-11

17.7 Junction-based Summary Statistics 17-13
17.8 Network-based Simulation Summary Statistic 17-15
17.9 Combined Simulation and Buffer Total Statistics 17-17
17.10 Delay-based Arrays in .UFS Files: Definitions 17-19
17.11 Formulae for Calculating Totals 17-20
18. Structure and Editing: PMAKE 18-1
18.1 Network data base structures 18-1
18.2 Network Editing 18-3
18.3 PMAKE - Network Building from Scratch 18-6
18.4 PMAKE: Editing Existing Networks 18-8
18.5 Node Editing within PMAKE 18-8
18.6 Link Editing within PMAKE 18-11
18.7 Simulation Centroid Connector Editing within PMAKE (11.9.4) 18-13
18.8 Capacity Indices on “New” Links 18-13
18.9 U-Turns at External Simulation Nodes 18-14
18.10 Disconnected Assignment Networks 18-16
19. Running SATURN Programs Interactively 19-1
19.2 Graphics and Text Mode 19-1
19.3 Menus 19-1
19.4 Banner Menus 19-3
19.5 Menu Bars (P1X only) 19-4
19.6 Text Menus 19-5
19.7 Windows List Boxes 19-6
19.8 Setting Variables 19-6
19.9 Windows Screen Edit and Edit Box Inputs 19-7
19.10 Output Text Windows 19-7
19.11 The Help Facility 19-8
19.12 Mouse-based Inputs 19-8
20. Modelling Road User Charges in SATURN 20-1
20.2 The Role of Tolls in SATURN Modelling 20-1
20.3 Input of Charges (Tolls) in SATURN 20-2
20.4 Calculating and Reporting Charge/Toll Statistics 20-5
20.5 Examples of Charging Systems in SATURN 20-6
20.6 STOLL: Modelling Stochastic Values of Times of Tolls 20-7
21. Alternative Network Data Structures and Assignment Methods: Origin Based
(OBA) and Path Based Assignment 21-1
5120257 / Apr 15 viii

Contents
21.1 Network Data Structures 21-1

21.2 Advantages and Disadvantages of OBA and Paths 21-2
21.3 Perturbation Assignment (WSTART and/or IPERT) 21-3
21.4 Storing O-D Path Files: UFO and UFQ 21-5
21.5 Practical Restrictions within SATURN 21-6
21.6 Additional OBA Output Files 21-6
21.7 Practical Considerations 21-7
21.8 Examples of OBA Applications 21-8
21.9 Further Information 21-11
22. Kick Starts: Updating, Warm Starts and Continuation Techniques 22-1
22.1 Introduction to Kick Starts 22-1
22.2 Review of Traditional Kick Start Options 22-2
22.3 Warm Starts (WSTART = T) 22-4
22.4 WSTART with Topologically Identical Networks and Matrices 22-6
22.5 WSTART with Altered Networks and/or Matrices: UFO Files 22-7
22.6 Warm Starts with Elastic Assignment 22-12
22.7 Advantages of Kick-Starts 22-12
23. Linking SATURN and Geographical Information Systems (GIS) 23-1
23.2 Exporting SATURN data to GIS Systems 23-1
23.3 Importing data from GIS Systems into SATURN 23-2
23.4 The Atkins MapInfo Tools 23-2
23.5 SATURN GIS Creator 23-21
24. INDEX 24-1
5120257 / Apr 15 ix
Introduction
1. Introduction
1.1 The Function of SATURN
SATURN (Simulation and Assignment of Traffic to Urban Road Networks) is a
suite of flexible network analysis programs developed at the Institute for Transport
Studies, University of Leeds and distributed by Atkins Limited since 1982. It has
six basic functions:
i) as a combined traffic simulation and assignment model for the analysis of
road-investment schemes ranging from traffic management schemes over
relatively localised networks (typically of the order of 100 to 200 nodes)
through to major infrastructure improvements where models with over 1000
junctions are not infrequent;
(ii) as a “conventional” traffic assignment model for the analysis of much larger
networks (e.g., up to 7,500 links in the smallest standard PC version,
200,000 in the largest)
(iii) as a simulation model of individual junctions;
(iv) as a network editor, data base and analysis system;
(v) as a matrix manipulation package for the production of, e.g., trip matrices.
(vi) as a trip matrix demand model covering the basic elements of trip
distribution, modal split etc.
As a combined simulation and assignment model - its original function - SATURN
is most suitable for the analysis of relatively minor network changes such as the
introduction of one-way streets, changes to junction controls, bus-only streets, etc.
(which can be loosely categorised as “traffic management measures”) and whose
evaluation requires a detailed analysis of traffic behaviour at junctions.
However from its starting point as a combined simulation and assignment model,
SATURN has been extended in both directions so that it can function both as a
conventional traffic assignment model and as a pure junction simulation model.
As a “conventional” traffic assignment model (with or without simulation) SATURN
can deal with large conurbation, regional or even national models.
These may then interface with smaller localised models using the greater
precision of the junction simulation models.
With both simulation and conventional network representations SATURN provides
a wide range of assignment options such as generalised cost, all-or-nothing,
Wardrop equilibrium, Burrell multiple-route assignment (SUE) and, more recently,
demand-responsive (elastic) assignment to deal with induced traffic. All these are
founded on theoretically consistent modelling frameworks and convergent
algorithms reflecting the academic background of SATURN’s development.
Releases of “major” updates to SATURN occur on a roughly annual basis (see
Section 1.6 below for a list); the latest release, 11.3, first became generally
available in March 2014.
5120257 / Apr 15 1-1

Section 1
Introduction
Post release 10.9, SATURN includes options to carry out Origin-based

Assignment (OBA) as developed by Dr. Hillel BarGera while a PhD student at the
University of Illinois at Chicago in the late 1990’s. His work revolutionised traffic
assignment in that his methods solve for Wardrop Equilibrium solutions to an
accuracy limited only by the numerical accuracy of the computer and within
comparable CPU times to existing algorithms such as Frank-Wolfe. See Section
21. More recently, Dr Yanling Xiang of Atkins extended the theoretical framework
for use in Multiple User Class assignments.
Also post 10.9 SATURN includes further features facilities to undertake “warm
starts” to speed up one run of SATURN using data extracted – in several different
ways – from previous runs. See Section 22.
At the other extreme SATURN allows for the interactive simulation and editing of
individual junctions, so that the user is able to vary parameters such as flows,
saturation flows, signal settings, etc and to analyse one node in isolation.
SATURN, through module P1X, also possesses powerful graphical display
capabilities for network, junction and matrix-based data. Junction details including
link and turn data may be shown at both individual junction and network wide
levels. The wide range of options available also allows for on-screen cordoning,
select link reassignments, GIS-style background displays, animated queues, data
editing and tree building.
The interactive and graphical facilities of PIX may also be used to “edit” existing
networks on screen and/or to build networks from scratch on the screen. The
latter function may use an existing bitmap file (e.g. a normal road map which has
been scanned) as the background and to “trace” the SATURN network on top of
it.
In a related fashion SATURN may be applied to the analysis of network-based
data which need not be in any way related to traffic assignment problems. For
example, data relating to accident rates per link, or the last dates of road
resurfacings stored, etc may be input and analysed.
Through its general matrix manipulation program MX SATURN offers a full range
of interactive matrix operations as required by standard transport planning
applications, e.g. matrix building, editing, factoring, furnessing, transposing etc. It
also provides easy transfer between SATURN and other transport and
spreadsheet packages.
While originally conceived as a purely traffic assignment package with a fixed
user-defined trip matrix SATURN now also provides a number of standard
modelling steps for matrix estimation, e.g. modal split and distribution. These
models have been integrated with the assignment in a self-consistent mode to
provide a mathematically convergent form of “Variable Demand Modelling”.
A further long-standing example of matrix estimation within SATURN is the ME2
Model (Matrix Estimation from Maximum Entropy) developed at Leeds and
University College London by Dr. L.G. Willumsen, enabling O-D trip matrices to be
estimated directly from traffic counts, thus reducing significantly the survey costs
required to run an assignment model such as SATURN as well as increasing its
accuracy. In effect ME2 generates the ‘most likely’ trip matrix which is consistent
5120257 / Apr 15 1-2

Section 1
Introduction
with all available traffic information, including where possible any prior estimates
of the trip matrix.
Other important features of SATURN include:
♦ fully interactive analysis of results, including on-line help files
♦ optimum green splits for traffic signals
♦ traffic signal co-ordination modelled
♦ lane structure of intersections and choice of lane modelled
♦ the growth and decay of queues modelled quasi - dynamically
♦ facilities to “skim”, e.g., inter-zonal time, distance, etc. matrices
♦ bus routes, bus-only roads and bus-only lanes included explicitly
♦ both left-hand and right-hand drive accepted
♦ special features of Australian and New Zealand rules of the road have been
incorporated
♦ selected link analysis
♦ multiple User Class Assignment differentiating between, e.g., cars, taxis,

HGV’s, etc.
♦ full analysis of O-D routes generated by the assignment
♦ network and trip matrix cordoning for sub-areas.
♦ a SATURN to Tuba interface module (SATTUBA) to assist in the economic

evaluation of schemes within the UK.
♦ modelling tolls or road charges on specified links; and
♦ facilities to both “dump” SATURN data into ASCII files for input into, e.g.,
spreadsheets or other suites of transport programs and equally to re-input
data files from these external procedures
1.2 Hardware / Software Requirements

SATURN has historically been run on a wide range of platforms including
mainframe computers, workstations and micros as well as 16-bit Windows
Operating Systems. However, by far the majority of users run 32-bit versions of
SATURN under the various Windows operating system released over the last 10
or so years (i.e. Windows 2000/XP/Vista/7/8.1) and all non-Windows-based are
now discontinued.
SATURN does not require a particularly high-spec pc to run (although clearly for
large networks number-crunching speed becomes an issue and large-memory
high-speed machines are recommended). A typical lower-range specification for
a system to run SATURN 11.3 would include:
5120257 / Apr 15 1-3

Section 1
Introduction
♦ Core2Duo processor (2.6GHz or faster)

♦ 512 Mbytes RAM
♦ 6 Gbytes (or greater) hard disk
A typical higher-end machine would include:
♦ multi-core processor (1.6GHz or faster) either on Intel-based
Core2Duo/Quad, Core i3/i5/i7, Intel Xeon workstations or AMD-based
processors;
♦ up to 4Gb RAM; and
♦ 7200rpm SATA disk drives or Solid State Disks (SSD).
Experience has shown that SATURN is not particularly demanding on disk drives,
memory or graphics capabilities. The assignment process is the most intensive
and if users are considering purchasing a dedicated SATURN machine, it is
recommended that they focus on the performance of the processor.
SATURN can also take full advantage of multi-threaded processors (e.g. Intel
Core2Duo or QuadCore chips) through the additional purchase of the multi-core
version of SATURN (SATURN-MC) to take advantage of the additional
computation power available. SATURN-MC was released as part of SATURN
v10.8.22 in June 2009. See Section 15.52.
For PC versions executable code is supplied complete with a full set of
complementary batch files for all modules plus the SATWIN front-end which
provides a standardised Windows interface.
1.2.1 64-bit Operating Systems

The SATURN executables are developed as 32-bit Windows applications. Until
the release of Windows 7 in 2009, the overwhelming majority of users ran the
software under a 32-bit Operating System (OS) with the 64-bit OS limited to
specialist, ‘power’ users. With the introduction of Windows 7, both 32-bit and 64-
bit versions are available under the same licence and the use of 64-bit OS is
becoming more commonplace.
The existing SATURN (32-bit) executables will happily run under both versions of
the OS and they will produce the same results. The principle advantage for
SATURN when running within a 64-bit OS is the ability for the individual programs
to access (or ‘address’) more memory. The practical limit for 32-bit SATURN is
around 1.5Gb of RAM and this may be exceeded for very large OBA-based
models.
There is no 64-bit version of SATURN available due to limitations of the Salford
Fortran language (within which the majority of the SATURN source code was
written). These limitations include the absence of options to compile SATURN
code for 64-bit OS and multi-threaded environments. Some of these limitations
were overcome by the development of the SATURN Multi-core routines using an
alternative Intel Visual FORTRAN (IVF) compiler linked into the existing Salford
code.
5120257 / Apr 15 1-4

Section 1
Introduction
1.3 Documentation
Documentation for SATURN is available at a number of levels
♦ SATURN User Manual (this document)
♦ an On-line Help System
♦ reprints of Journal and Conference Articles
The needs of most users will be provided by the User Manual alone which is
available in both word processed and printed copy available from Atkins and
included on the SATURN Installation CD as standard Adobe PDF documents.
They may also be downloaded from the SATURN WEBSITE
http://www.saturnsoftware.co.uk; or see Appendix C for a list of various relevant
publications and background technical files, many of which are included within the
PDF Appendices.
1.4 Distribution of SATURN

SATURN is distributed exclusively by Atkins Limited as agents for Dirck Van Vliet
and Leeds University / Institute for Transport Studies and is available with full
technical support.
Charges for SATURN are divided into three main categories:
a) PROGRAM FEE - for the supply of the SATURN suite (normally as
executable code for Windows 2000/XP/Vista/7/8.1 PCs);
b) PURCHASE PRICE - for unlimited site use of the model (but without any
rights to re-sell).
c) MAINTENANCE - for the supply of any updates to the Suite at an annual
charge.
Charge a) is paid by all customers; educational institutions who wish to use
SATURN purely for teaching and/or research pay only a). Planning agencies,
consultants, etc. must pay b) while c) is optional.
In addition full support services are available from Atkins for staff training, advice
on installation and applications, etc. Prices for the above services vary depending
on the type and location of the purchasing organisation. For details, please
contact:
SATURN Team
Atkins Limited,
Epsom Gateway, Woodcote Grove, Ashley Road, Epsom KT18 5BW
or call: SATURN Support, Epsom +44 (0) 1372-756755 or, alternatively, via e-mail
at saturnsoftware@atkinsglobal.com.
5120257 / Apr 15 1-5

Section 1
Introduction
1.5 Contents of the Suite

As supplied to pc users on a set of disks the SATURN Suite consists of the
following types of computer files:
♦ FORTRAN program executables (.exe files);
♦ the SATWIN Windows-based interactive front-end
♦ various documentation files (including PDF version of this document);
♦ sample data files for checking purposes;
♦ .bat files plus associated .key files for the software operation; and
♦ help files.
5120257 / Apr 15 1-6

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

Section 1
The SATURN Suite – An Overview
2. The SATURN Suite – An Overview

INTRODUCTION
This section is intended, firstly, to introduce some of the functions and capabilities
of SATURN to new users and, secondly, to illustrate how this manual may be
used and where certain pieces of information are likely to be found.
It follows, roughly speaking, the authors’ standard “Introduction to SATURN”
presentation at meetings, courses etc., and - we would like to think - such
presentations may provide a slightly more user-friendly intro to SATURN than
meeting the documentation “cold”. Equally reading an article such as that in
Traffic Engineering and Control, 1980 (see reference 1 in Appendix C) may
provide an easier starting point.
Alternatively there are a number of introductory SATURN courses available within
the UK provided by Atkins – please either check on the SATURN website or
contact Atkins directly.
2.1 The Structure of Assignment Models

There are clearly lots of things that you can do with SATURN, some of which were
described in Section 1. However to most users SATURN is primarily a traffic
assignment model, the general structure of which is illustrated in Figure 2.1.
Thus there are two general inputs - the “trip matrix” T ij which specifies the number
of trips from zone i to zone j; and the “network” which specifies the physical
structure of the roads, etc. upon which trips take place. These may be thought of
as the “demand” and “supply” inputs; it is the job of the user to provide these
inputs.
Both the matrix and network are input to a “route choice” model which allocates
trips to “routes” through the network, as a result of which total flows along links in
the network may be summed and the corresponding network “costs” (e.g., times)
calculated. This is essentially where SATURN takes over, operating of course
under instructions from the user.
Once the assignment has been carried out the user may then “analyse” the
resulting flow pattern and, in effect, ask the SATURN programs for whatever
information they require.
5120257 / Apr 15 2-1

Section 2
Figure 2.1 General Structure of an Assignment Model
The above structure is of course perfectly general and may be applied to any suite
of network analysis programs, not just SATURN. What distinguishes different
suites is, e.g., the precise manner in which data must be prepared for input, the
options that are available to undertake route choice or to analyse the results, etc.
However one important common strand is to note that errors in the outputs can
arise from four general sources
♦ errors in the trip matrix,
♦ errors in the network specification,
♦ errors in the route choice model specification (e.g., the definition of

generalised cost), and
♦ errors in the numerical calculations (i.e., non-convergence).

Effectively the first 3 error types are down to the user to correct, whereas any
problem in the numerical solution of the problem specified by the user (i.e., non-
convergence) is largely the responsibility of SATURN. (Although – see Section 9.5
– there are a lot of things users can do to minimise problems of convergence.)
Clearly the programs should - and do - assist users to minimise input errors, while
the users should choose the appropriate options within the assignment routines.
5120257 / Apr 15 2-2

Section 2
The important point is that you should not necessarily blame the program if the
results are not to your liking - the universal computing principle of “Garbage in,
Garbage out” applies very much to the use of SATURN. This is not to say that the
SATURN programs are perfect - far from it, as you shall no doubt find out! - but it
is important to realise that there are a host of reasons why models fail and to learn
- from experience, largely - how to minimise them.
A second important point to appreciate is that the programs in the SATURN suite
are only tools capable of carrying out certain well-defined functions and it is the
user who must specify how these tools are to be used. If you treat SATURN as a
black box which operates in whatever default mode seems appropriate to us, the
designers, then it may very well not do what you want it to do. You are the boss
and the more you understand the underlying modelling principles which SATURN
follows then the better your results will be.
The following sections explain in greater detail how the various components in
Figure 2.1 are handled within SATURN and where relevant questions are treated
in the documentation.
2.2 Trip Matrices in SATURN

There are, in general, two distinct schools of thought related to trip matrices
♦ that they should be obtained (as far as possible) from direct observation such
as in-vehicle interviews or number-plate matching surveys;
♦ that they should be derived from some form of demand modelling process,
e.g. trip distribution, modal split etc
A related issue is how one obtains future year forecasts given a validated base
year matrix. Again there are two extreme solutions, simple growthing-up or
factoring methods or cost-related demand models (as discussed in Section 7.4).
In practice of course the techniques used in studies will incorporate elements of all
the above procedures.
Every organisation using SATURN must therefore develop their own procedures
for matrix estimation, e.g., from vehicle surveys, home interviews, and/or demand
models. This, it must be stressed, is never an easy task and may involve even
more resources, and possibly even more computing resources, than the network-
based tasks.
Facilities within the SATURN Suite may be used to a greater or lesser extent in
the estimation of matrices. At one extreme SATURN may be run with fixed trip
matrices derived totally independently of SATURN. On the other hand there are a
large number of matrix-based programs within SATURN which can assist in the
derivation of trip matrices. Thus the general matrix manipulation program MX
(see Section 10) contains virtually all the standard operations required to create
trip matrices, for example matrix factoring routines to model growth in particular
zones. In addition the SATME2 program, described in detail in Section 13, uses
link count data to estimate the “most likely” trip matrix. The elastic assignment
options (see Sections 7.4 and beyond) also allow the basic assignment function
within SATURN to be interfaced with more general demand models such that
SATURN can include, e.g., modal split or distribution facilities.
5120257 / Apr 15 2-3

Section 2
However for most users the creation of a trip matrix will involve the use of the
“matrix build” procedure M1 which converts a data file of individual o-d trips
prepared by the user into a file suitable for handling within SATURN. How to use
M1 in this manner is described in Section 4.
We note, in passing, that is important to remember that the recommended units
for flows in SATURN are pcus/hr, not vehicles/hr (although it is possible to use
vehicles if desired; see 15.17.1), so that it may be necessary to convert observed
vehicle trip matrices into pcu matrices prior to running SATURN.
Finally, let us re-emphasise the point made in 2.1 that errors in trip matrices can
have a significant effect on the overall accuracy of the full assignment procedure
and that they should not be either ignored or under-estimated
2.3 Networks in SATURN

Networks on the other hand are central to SATURN and the way in which they are
described and manipulated is one of the properties that distinguish SATURN from
other assignment models.
An example of a “typical” SATURN network (as output by program PIX) is given in
Figure 2.2.
Figure 2.2 - A Typical SATURN Network
Note firstly that SATURN networks may be coded at two levels of detail:
♦ as an “inner” or “simulation” network in which considerable junction-based

data in addition to road-based data must be provided by the user; and
5120257 / Apr 15 2-4

Section 2
♦ as a “buffer” network, normally surrounding the simulation network, which is

coded in the more conventional sense of only requiring data to describe the
roads as opposed to the junctions.
Thus in Figure 2.2 those nodes which are represented as hexagons, i.e. near the
outside of the network, are buffer nodes and the links connecting them constitute
the buffer network.
Junctions in the central area - rectangles, circles and squares - are the simulation
junctions; the different shapes denote different junction types (see 11.6.5.1)
Note as well the presence of “zones” or “centroids” represented by triangles which
are common to both the simulation and buffer networks.
Typically the simulation network is used to describe networks at the centre, say, of
a traffic management scheme where the impacts are crucial and large, while the
buffer network is used to describe, e.g., the inter-urban roads surrounding a town
where the impacts of traffic management schemes are less critical. Very often, as
in Figure 2.2, the full network resembles a “doughnut” with the simulation network
as the “jam" in the middle.
It is not, however, necessary for every network to use both a buffer and simulation
component. Large-scale studies of, say, inter-urban networks may only employ
buffer networks, while very localised studies may set up a pure simulation
network.
An early stage in any study is to decide upon the extent - and the type - of the
network to be modelled. Following this you will need to obtain the data required to
define the network(s) and to prepare appropriately formatted data files for entry
into the SATURN network build procedures (i.e. into program SATNET).
More complete details on how networks are described are given in Section 5; in
particular Section 5.6 provides a general introduction to the science - or art? - of
building networks. New users should read this in full before moving on to Section
6 which describes the detailed formatting conventions used in preparing a network
data file. You only need to read those parts of Section 6 which relate to your
particular data inputs; for example only look at Section 6.9 if you wish to code bus
routes.
Note as well that a lot of the drudgery associated with coding networks may be
minimised by making use of the interactive network building and editing facilities in
PMAKE; see Section 18. However, as with trip matrices, coding a network can be
a long and involved process and there are very few shortcuts.
2.4 Route Choice in SATURN

In contrast to the definition of the networks and trip matrices where the onus is
decidedly on the user to do hard work, the route choice in SATURN is handled by
the computer programs. However the user will still have several important
decisions to make; e.g
♦ whether to use an “equilibrium” or “stochastic” framework;
♦ how to define “cost”
5120257 / Apr 15 2-5

Section 2
♦ how many iterations, etc, to allow

Details on the options available and the theoretical background to the choices
available are contained in Section 7 of the Manual. It should, however, be
stressed that this documentation is not intended to provide a complete coverage
of assignment theory; for that users should consult standard text books such as
those written by Yosef Sheffi of M.I.T. or Roy Thomas of Salford
2.5 Analysis in SATURN

Once the assignment is complete - or indeed at any stage during the process -
there is a wealth of SATURN analysis programs designed to allow the user to
“interrogate” the system in order to discover not only WHAT the output values are
but also WHY they take the values they do. A central precept of SATURN is that
any internal processes should be transparent to the user.
The analysis programs may be used either to display information on the screen or
to send it to a “line printer” file for external printing or viewing. Screen output may
be either “alpha-numeric” output or, wherever possible, a “graphical display”.
Section 11 of the manual describes both the general features of the main
interactive program PIX plus certain specific features of sub- programs such as
SATDB or SATLOOK. However the best way to appreciate what can be done
and how is simply to “browse” through P1X, using the on-line “help system” when
the succinct menu entry does not fully convey the function of the option.
2.6 General Advice on Using SATURN

Firstly, SATURN is (obviously!) a suite of computer programs so users must
(obviously!) be able to use a computer. This is not to say that you have to be a
computer whizz kid in order to use SATURN - in fact you can get by with fairly
basic computer skills - but the more you know about computers, the better. For
example, you may be able to make the data input stages much simpler by using
spread sheets to code matrix data or CAD packages to digitise networks.
As a minimum you must understand how files are named, how to manipulate them
(e.g., to move files between different directories, etc.), how to use a text editor in
order to prepare data files and how to examine output files. You do not, on the
other hand, need to know anything about programming in order to run the
programs.
Sections 3.3 to 3.6 of the manual describe the basic computer conventions within
SATURN; read these at an early stage. Section 3 also includes an introduction to
SATWIN which should be the normal point of access to all things SATURN.
Secondly, it is very important to read the relevant sections of the manual before
embarking on any SATURN job. For new users finding their way around the
manual is not that easy but the Table of Contents at the beginning and an Index at
the end should make life a bit easier. Certainly Sections 1 to 5 should be read at
a very early stage, Sections 7, 8 and 9 (assignment, simulation and their
combination respectively), slightly later but certainly before you become involved
in any “serious” work. Equally read Section 19.1 and the relevant subsections in
11 before using any of the interactive programs such as P1X and remember to
use the “Help Facilities” with these programs.
5120257 / Apr 15 2-6

Section 2
Finally, you will find a slightly warped sense of humour and a knowledge of who’s
who on The Muppets to be useful assets! Oh yes, and don’t get upset by the
insults.
2.7 Getting Started; Example Files

New SATURN users, particularly those operating with only this manual as a
starting point, may find difficulties in establishing exactly what SATURN provides.
To assist them - and, indeed, all users - two “standard” data files are provided
♦ a network file “Epsom98net.dat”; and
♦ a matrix file “Epsom98mat.dat”.

Thus, having read in all the files and set up the appropriate directory structure
(which should be done for you by the Installation procedures) and wishing to run
a sample SATURN job, you must first create a trip matrix file (see Section 4). This
can be done through the Command Line (in SATWIN) by typing:
M1 Epsom98mat
followed by the command:

SATURN Epsom98net Epsom98mat
to assign the trip matrix to the Epsom98net network (see Section 3.1).
This process is also described in Section 3.6 where the facilities for running
SATURN modules from SATWIN are detailed.
When the above run is complete, you will find that a number of files have been
created, e.g., a file Epsom98net.lpn which is a line printer output file from the
SATURN program SATNET which converts the Epsom98net network data file into
a “binary file” Epsom98net.ufn and a Epsom98net.lpt output file from SATALL.
Line printer files may be either printed or viewed in a standard text editor. File
name conventions are described in Section 3.3.
All essential outputs from the assignment are now stored in the file liv97.ufs and
the results may be analysed by a set of analysis programs. To experiment try the
following commands
P1X Epsom98net
SATLOOK Epsom98net
MX Epsom98mat
Details on the functions of the above programs may be found elsewhere in the
manual.
Please note however that the Epsom98net file is NOT intended as an illustration
of good coding practice; merely an example of some network coding. Equally,
although superficially similar to the Epsom town centre from which it was derived,
the actual data is almost totally artificial.
5120257 / Apr 15 2-7

Section 2
2.8 Text Files, Fixed Columns, Text Editors and Word Processors
SATURN programs make extensive use of “ascii” or “text” files which users need
to prepare in order to run SATURN programs, e.g. the network .dat files used to
define network structure as input to SATNET.
2.8.1 Fixed Column versus Comma Separated Variables (CSV)

Very often SATURN data files are based on “fixed column field” conventions; i.e.,
a particular piece of input data MUST appear within particular columns of an input
record; if it appears in the correct order but outside the required columns it will be
misread. Specific column rules are documented throughout the Manual; see, in
particular, Section 6 for network .dat file conventions.
An alternative convention is that of CSV or “Column Separated Variables” where
the order of the variables is specified but the “width” of each is not and each
variable is separated and distinguished from its neighbours by a comma (or a
blank).
CSV is a more modern convention than fixed column and, while fixed columns is
generally the standard format throughout SATURN data files, CSV is very often
available as an alternative.
One advantage of fixed column inputs (DVV’s viewpoint!) is that it is much easier
to spot mistakes visually in files, e.g., if a value in a particular column is out of
range, whereas with a CSV file it is very difficult to distinguish the 5th from the 6th
variable on a particular line. Another is that a blank column or field is always read
as “zero” and need not be explicitly input as a zero whereas with CSV files all
values need to be explicitly included, if only by an extra comma; this allows data
fields to be “added” in unused columns at later stages of development whilst
maintaining upwards compatibility with “old” data files. On the other hand fixed
columns set limits on the “range” of values which may be input so that, for
example, it is not possible to define a value of 12345 in 3 fixed columns; with CSV
this is not a problem.
Note that in certain cases it is possible to redefine the fixed column input
conventions by setting your own “DIY” formats; see Section 15.35.
For you brought up in the Bill Gates era of MS Excel etc. etc. fixed column input
fields may well seem strange – get used to it!
2.8.2 Text Editors and Word Processors

Generally speaking it is NOT a good idea to prepare such files using “word
processing” facilities as opposed to “text editors”. The reason is that very often
word processors - for very good reasons as far as they are concerned! - insert
special, non-printing characters into files such as tab characters in order to give
the desired fixed-column appearance on the screen. Unfortunately, such
characters are virtually always misinterpreted by a FORTRAN read statement,
particularly when data files are in “fixed format”, i.e., data items must appear
within specific columns. Do not be misled by the fact that your file “looks” correct -
it aint! Fortunately, some Text Editors (but not MS Wordpad or MS Notepad) are
capable of removing these ‘hidden’ tab characters and replacing them with spaces
(eg UltraEdit and Textpad for example).
5120257 / Apr 15 2-8

Section 2
This is not to say that it is impossible to use a word processor to create a

SATURN data file, but you will have to choose your text specifications with care!
For example using MS Word you need, at a minimum, to use .txt outputs (which,
following SATURN conventions, should subsequently be renamed as .dat files).
Similarly, when exporting information from MS Excel, worksheets should be saved
as “Formatted Text (Space Delimited) (*.prn)” files with the appropriate column
widths. For example, a data file requiring data in columns 1 to 5 may be exported
in the correct format by setting the width of Column A in the worksheet to 5.0cm
(ie a one cm column is the equivalent of a single space in a text file).
2.8.3 FORTRAN Conventions for Reading “Real” Data Fields: Variable Decimal
Places
Within FORTRAN numerical variables may be either “integer” or “real”; e.g., 1, 2, 3
as opposed to 1.25, 3.14159, etc. etc. It is important in preparing SATURN .dat
files that when an integer-only variable is to be set, e.g., in a fixed range of
columns, that it is written as an integer (i.e., without a decimal), otherwise a
“FORTRAN Read Error” will result and, most likely, the program will terminate. For
example, writing 1.0 instead of 1 will cause such an error, even if it is within the
correct columns.
On the other hand the FORTRAN input conventions for real numbers are more
forgiving so that either 1 or 1.0 will be correctly read as “one” as long as it is within
the correct columns. In addition, the number of decimal places to be included is
generally defined within the program for a real input field but need not be strictly
adhered to. Thus a Fortran format of F5.2 would imply that a real value is required
within a block of 5 columns with 2 characters after the decimal point; e.g., 1.23,
not 1.234. And certainly if F5.2 were used as an output format 1.23 would always
be output, never 1.234. However if 1.234 were to be input under Format F5.2 the
third decimal place would be correctly read; equally 123.4 would be correctly read
even though it only has one decimal place, and 123 would be read as 123.0 even
though it doesn’t have an explicit decimal.
Note, however, that the field “width” must always be strictly adhered to so that, for
example, with F5.2 it would not be possible to input a value such as 123.45 which
requires 6 columns, or indeed any value greater than 99999.0.
In very old versions of SATURN which were supplied to users as source code for
the users to compile with their own compilers life was more complicated in that
certain compilers would require that, with a format F5.2, the decimal place must
appear in column 3 whereas others would be more forgiving as above. Therefore
the Manual tends very often to specify a fixed decimal place whereas, with
current .exe programs, the input formats are flexible as above.
In brief, you can input real numbers in virtually any format you like as long as you
stay within the correct “width” of the input field.
Finally we note that there are a number of instances of inputs which are generally
input as integers but which are stored as reals and therefore, strictly speaking,
may be input as either an integer or a real. For example, traffic signal stage times
(see Record Type 3, 6.4.1) are generally specified with sufficient precision as
integer seconds but may, if desired, be input as a real value in order to achieve
greater precision. Similarly counts, which are stored as reals, are generally input
5120257 / Apr 15 2-9

Section 2
as integers on the assumption that it is difficult to define a flow to greater than 1

PCU/hr.
Clearly, however, an input which defines, say, the number of data entries which
follow can only be input as an integer.
2.9 Errors and Warnings: Fatal, Non-Fatal and Serious

Error messages in SATURN have five levels; in order of decreasing severity these
are:
♦ Fatal errors.
♦ Semi-fatal
♦ Non-fatal errors.
♦ Serious warnings.
♦ Warnings.
Generally speaking these are applied to the processing and validation of input
data files such as network files but they are also used in interactive programs.
Fatal errors, as the name implies, cause the program to terminate abnormally.
This does not necessarily imply that the program itself cannot continue at that
point; it may be that at a later point in that program or even in another program life
would become impossible. In some situations a program may continue even after
a fatal error has been encountered; for example, SATNET will continue to process
data after a fatal error in order to detect other errors later on in data sets.
However it would not carry on to the very end.
Semi-fatal errors were first introduced in SATURN 10.1. They are applied to
errors in SATNET, which would prevent (or are expected to prevent) the
assignment - simulation procedures from running normally but would not prevent
the map network as required to P1X to be set up. Networks with semi-fatal errors
may therefore be processed within P1X and the errors corrected interactively so
that they may be processed by the assignment/simulation stages.
Non-fatal errors result from input which SATURN can handle without subsequent
numerical problems but which, in the program's opinion, is almost certain to
produce nonsensical results. Thus defining a free-flow speed of 0 kph would be a
fatal (or semi-fatal) error if it would ultimately cause a program to divide by zero; a
speed of 0.001 would be a non-fatal error since the program could cope
numerically.
Clearly all fatal errors need to be corrected before continuing, and all non-fatal
errors should at least be thoroughly checked and confirmed that they are
deliberate.
Certain Non-Fatal Errors (plus certain Serious Warnings – see below) are
optionally upgraded to Semi-Fatal status if a network parameter WRIGHT is set
equal to T. This convention is strongly recommended. See Section 6.12.2.
5120257 / Apr 15 2-10

Section 2
Serious warnings are similar to non-fatal errors, but less obviously bound to
produce nonsense, while warnings refer to input which looks strange but may be
OK. Verification of both is recommended but not, if you like, mandatory.
However, it is worth bearing in mind that a warning at any level may not reflect the
“true” error. For example, if a user wishes to define data for a link A,B and they
accidentally input A,C then this may generate a warning if the input does not make
much sense at C but simply correcting the input so that the data makes sense at
C does not correct the basic problem of having input the wrong node number.
Thus even warnings may be evidence of much more serious problems.
Summary statistics of all five types of errors are given at the end of each program
plus, in SATNET, at intermediate stages. The same information may also be
accessed within P1X under Information.
Note that non-fatal errors and warnings may be suppressed in SATNET by setting
a parameter ERRYES(n) to F in the &PARAM inputs to SATNET to suppress error
n. Alternatively, in a limited number of cases, setting ERRYES(n) = F may convert
a semi-fatal error into a serious warning; e.g., setting ERRYES(437) = F allows
unidentified links to appear in the 77777 count data without creating semi-fatal
errors.
A range of error messages may be set in a single Namelist statement by using a
colon; e.g., ERRYES(33:66) = F “turns off” all warnings in the range 33 to 66. See
Appendix A.
In addition a count of the number of each category of errors detected per
simulation node is included in the uf* files and may be displayed as part of the
node print outs or node graphics. For information on which error numbers are
which please see Appendix L (or, less conveniently, list the file SATTIT.DAT).
5120257 / Apr 15 2-11

Section 2
2.10 Version Control
JOB NUMBER: 5120257 DOCUMENT REF: Section 2.doc
Originated Checked Reviewed Authorise Date

d
10.9.17 Web release – Jun 10 DVV NP IW IW 22/06/10
11.1.09 Saturn V11.1 Release (Full) DVV AG IW IW 31/03/12
11.2.05 SATURN v11,2 Release (Full) DVV JS IW IW 17/03/13
11.3.03 SATURN v11.3 Release DVV SN IW IW 28/03/14
5120257 / Apr 15 2-12

Section 2
The Basic SATURN Model
3. The Basic SATURN Model

3.1 The Network Model Structure
3.1.1 The SATURN Network Modules

Conceptually the basic network model has seven main “functions” (in addition to a
wide range of supplementary network programs plus matrix manipulation), the first
three of which are concerned with getting traffic flows onto the network, and the
last four more generally with the analysis of loaded networks.
Originally each “function” was contained within a single program or module.
However in more recent versions (9.3 and beyond) the basic “functions” are
aggregated into single very large programs such as SATALL and PIX below that
carry out a wide range of functions.
Those which deal with loading traffic are:
♦ the Network Build program, SATNET, which checks network data input and
sets up the files required by:
♦ the combined simulation-assignment program SATALL whose functions were

originally provided by two separate programs:
♦ the Assignment, SATEASY, which assigns traffic on the basis of the delays
given by the simulation.
♦ the Simulation, SATSIM, which models in detail the passage of traffic through
the network and the resulting delays.
The ‘analysis’ and display programs comprise:
♦ the network general analysis and plot program P1X which displays link-based
data either to a terminal or on a hard-copy device (and includes virtually all
the functions contained in the following three original programs).
♦ the analysis program, SATLOOK, which enables a detailed description of

traffic conditions to be printed in text format.
♦ the node editing program SATED which allows nodes to be simulated on an

individual basis using interactive commands.
♦ the data base analysis program SATDB which allows an essentially free-
format manipulation and display of data.
Figure 3.1 and Figure 3.2 illustrate the inter-relationships of these functions
represented by discrete programs. Programs are enclosed by boxes and the files
passed between the programs and/or inputs to them are also indicated. Section
3.3 describes the file name conventions.
How to create the trip matrix file to be assigned, trips.ufm in Figure 3.1 and Figure
3.2, is dealt with in Section 4.
5120257 / Apr 15 3-1

Section 3
3.1.2 The Iterative Structure

A single ‘run’ of SATURN to achieve a loaded network will usually be
accomplished by a single call to a SATURN control file (see 14.3). Parameters
are used to indicate the network and (optionally) trip matrix file names; e.g.
SATURN Netname Tripname
This causes the network build module SATNET to be activated followed by

SATALL to perform the assignment and simulation functions, as illustrated in
Figure 3.1.
Historically SATURN made use of an automatic loop between two separate
programs SATASS (or SATEASY) and SATSIM (Figure 3.2) and this may still be
done - although not recommended in normal circumstances. The choice of the
external or internal loop is dictated by the procedure used: SATURN and
SATURN9 use SATALL, SATURN8 uses the explicit loop. See Sections 9.1 and
14.3.
SATNET checks all input data, outputs error messages and sets up the internal
structural networks as required by (a) the simulation and (b) the assignment. The
precise structure of these networks or of the .uf* files which are passed between
programs need not concern the normal user; a general description is given in
Section 5. Data format specifications are given in Section 6.
The primary objective of the simulation is to determine junction delays resulting
from a given pattern of traffic. A general description of the assumptions made and
the procedures followed is given in Section 8. The information on delays is input
to the assignment which selects appropriate routes through the network for each
element in the trip matrix, bearing in mind relationships between travel time and
flow as determined by the simulation. By default the model uses an ‘equilibrium’
technique based on an optimum combination of all-or-nothing assignments, so
that for a given O-D pair a range of routes is normally used but each has the same
minimum O-D cost. Alternative assignment techniques, e.g., all-or-nothing, Burrell
multiple-route, may also be used. Section 7 provides details.
The flows generated by the assignment model are then returned to the simulation
model which in turn re-calculates junction delays for re-input to the assignment.
The resulting iterative procedure is illustrated in Figure 3.1. While in principle the
loop can begin with either a simulation using default flow values or an assignment,
using default flow-delay relationships, in practice it is found to be better to start
with the assignment. The procedure terminates when the re-assignment of traffic
is sufficiently small or a (user-specified) maximum number of iterations (MASL) is
exceeded. Normally the sequence concludes with a run of the simulation.
In the case of “buffer-only” networks, i.e., networks coded without any simulation
network (see 5.3), it is not necessary to run the simulation, in which case
convergence is reached by running the assignment once and proceeding directly
to the analysis programs.
Apart from the iterative loops between the simulation and assignment stages there
are also internal iterative loops within both stages which need to converge.
Generally speaking users should allow a sufficient number of internal iterations
5120257 / Apr 15 3-2

Section 3
(as governed by the parameters NITA and NITS described in 6.3) for the
individual programs to converge.
3.1.3 The Analysis and Display of Results

The analysis programs P1X etc. (see Section 11) enable users to examine output
from the assignment or simulation using interactive commands.
In addition P1X/PMAKE also provides for on-line network editing. While not
shown in Figure 3.1 there are two “feedback” loops from P1X. Firstly, a new
network data file suitable for input to SATNET may be produced by P1X by editing
existing network files. Secondly an edited version of the .ufs file may also be
produced and fed directly back to SATALL.
In older versions of SATURN (Figure 3.1) the analysis functions of P1X were
contained in four separate programs, P1, SATLOOK, SATDB and SATED. The
latter three still exist as distinct programs and in certain situations are best run in
that mode rather than within P1X.
Figure 3.1 – Running the Basic Saturn Model using SATALL; the current methodology
5120257 / Apr 15 3-3

Section 3
Figure 3.2 – Running the Basic SATURN Model using separate programs; the original
methodology
3.2 Data Requirements

The input data to be prepared by the user consists of: (i) trip matrix data as
described in Section 4, and (ii) network data as described in Section 6.
Simulation network data requirements may be summarised as follows:
a) Universal parameters such as minimum gap acceptance, etc;
b) Junction data - type of junction (signals/priority/roundabout); co-ordinates;
c) Link data - distance, time or speed, number of lanes, stacking capacity
(optional);
d) Turn data - a saturation flow, lanes available, a priority marker indicating
give ways, etc;
5120257 / Apr 15 3-4

Section 3
e) Traffic signal data - stage lengths; offsets; cycle time

Thus all data input, with the exception of saturation flows which require some
degree of “engineering judgment”, are well defined parameters which may be
obtained by relatively simple observation.
Buffer network data consists of link-based data only, e.g., as under (c) above.
Additional network-based data is also contained (optionally) within both GIS files
(see 5.6) and network X-files (see 6.13).
Users who wish to re-code existing networks and matrices to run on SATURN
should refer to Section 15.8.
3.3 File Name Conventions

Running SATURN programs involves the creation and manipulation of a large
number of files. This section describes a recommended standard method for
handling file names
3.3.1 General Principles

Files may be classified in a number of different ways; e.g. by their computer-
based characteristics
♦ Input/output files,
1
♦ “Unformatted binary” vrs. “text” or “ascii”,
♦ Scratch/permanent or by function-based characteristics such as
♦ Network data,
♦ Trip matrices
The filename conventions should try to reflect these differences.
File names differ considerably between different computers and different
operating systems. SATURN follows standard DOS and WINDOWS conventions
whereby every file must have
♦ a “name” (or, more generally, a “pathname”, see 3.3.3 below)
♦ and an “extension” (with a maximum of 3 characters)

Typically the name indicates the network/matrix/etc., and the extension indicates
the process/program which has produced that particular file.
* As far as the normal user is concerned the essential difference between text and binary files is
that a text file may be created using the keyboard and/or viewed on the screen, (e.g., using a
standard edit program such as Notepad), whereas a binary file is passed between programs and is
only “intelligible” to a program. Thus if you try to “type” a binary file on the screen you will get - at
best - gobbledygook and - at worst - a “stalled” computer. You have been warned!
5120257 / Apr 15 3-5

Section 3
Thus a network “named” LIVNET might spawn a number of files with extensions
such as LPA denoting the Line Printer output from the Assignment, UFS indicating
the “Unformatted” output from the Simulation, etc. etc. The documentation
assumes the DOS/WINDOWS “dot” convention, e.g. LIVNET.UFS.
3.3.2 Extensions
The following rules govern the standard or “default” files extensions:
All unformatted binary files have extensions beginning with UF. In particular:
UFN An unformatted file output (only) by SATNET
UFS An unformatted file produced by SATSIM or SATALL
UFA “ “ “ “ SATEASY
UFM An unformatted matrix file
UFP A file containing “pija” factors as passed from SATPIJA to SATME2
UFT An unformatted file output by SATSUMA; see 17.5
UFX Scratch files.
UFC An unformatted file of costs used to re construct routes see 15.23.
“Text” files used as control or data files:
DAT All basic data or control files created by the user, e.g., using a text editor such
as Notepad or Wordpad (not MS Word) and used as input
KP A “card punch” file output by a program.
HLP Help files used by all interactive programs.
LOG A file containing a list of all terminal input commands from the run of an
interactive program; see 14.5.1.
KEY A “dummy” terminal file used to run an interactive program; see 14.5.1.
VDU A “dummy” terminal output file from an interactive program; see 14.5.1.
XY A supplementary node co
GIS A supplementary “Geographical Data” file; see 5.7.
MCC A supplementary file containing link counts.
BUS A supplementary file containing bus route data.
DBD A “Data Base Dump” file output/input by SATDB.
Conventionally, all the above files might be assigned the extension “.txt”, e.g. by a
word processor such as Microsoft Word.
All output line printer files have extensions “LP-” with the third letter/number
indicating the program that produced it as follows:
LPN SATNET
LPA SATEASY
5120257 / Apr 15 3-6

Section 3
LPS SATSIM
LPT SATALL
LPL SATLOOK
LPG SATPIG
LPP P1X
LPD SATDB
LPM SATME2
LPU SATU2
LPF SATOFF
LPC SATCH
LPX MX
The “standard” extensions above are used by the programs themselves to create
new files and/or to suggest extensions to the user on input. They are also
frequently used as a convenient shorthand to refer to files; e.g., the “LPN file”
would imply the line printer file produced by SATNET, a “DAT” file implies a
control file prepared by the user, etc. “UF files” refer in general to all UF*
unformatted files, while UFA/S refers to either UFA or UFS which may, in a
number of circumstances, be used interchangeably.
In addition there are a number of “system” files within the Suite itself which should
in some sense be inaccessible to users (i.e., they should not be accidentally
erased!). These will have conventional extensions as well as indicated below:
♦ FORTRAN source code files
♦ Executable code files (.EXE files)
♦ Procedures to run programs (.BAT files)
♦ Basic data files (.DAT files)
♦ Help files (Extension .HLP)
♦ Salford library files (Extension .DLL)

N.B. The extensions .DAT and .HLP are SATURN standards whereas extensions
such as .EXE and .BAT above are DOS standards; other operating systems will
therefore have their standard extensions for such files.
3.3.3 Pathnames
Every file has a full “pathname” associated with it. Thus the file net3.ufs on your
working directory may have the full name c:\SATURN\NEWTOWN\2005\net3.ufs.
In certain circumstances net3.ufs (or even net3 if SATURN expects the extension
.ufs) may be enough to identify it; in other circumstances the full pathname may
be required.
5120257 / Apr 15 3-7

Section 3
SATURN binary files store both filenames and pathnames and use both when
trying to open files.
Path/filenames may contain up to 256 characters. (Versions prior to 10.1 were
limited to 96.)
3.4 32-Bit SATURN Versions

PC versions of SATURN prior to 10.1 (9.5 and earlier) were all compiled as 16-bit
code which, in practical terms, meant that they needed to be run under MS-DOS
as opposed to “pure” MS Windows. Version 10.1 catered for both. By contrast
versions 10.2 and beyond are specifically designed for 32-bit applications and
may be run using the SATWIN Windows front-end program. Note, however that
the 32-bit versions may also be run under Command Prompt which may be
accessed through SATWIN.
The following two sections describe the two alternative methods in somewhat
general terms.
3.5 Running Programs Under DOS (or Command Prompt)

In order to run one program - or a linked set of programs - it is necessary for the
user to specify: (a) the program(s) and (b) the files to be used. Thus for every
individual program in the Suite there is a corresponding “procedure file” (e.g., a
.BAT file under DOS) with the same “name” as the program; e.g., SATLOOK.BAT.
Thus in order to run, say SATLOOK, the user types in “SATLOOK” followed by a
series of file names and/or key words. For example typing:
SATLOOK LIVNET
would run the program SATLOOK in order to analyse data for a “LIVNET”
network. To look at another network you would type:
SATLOOK EVERTON
The precise file to be analysed in the first case would be LIVNET.UFS, the
extension .UFS being implied. Output files are automatically created as
necessary with standard extensions as well. Thus the line printer output file
above would be LIVNET.LPL.
Note that simply typing the name of the program prints a brief “help file” to the
screen with instructions how to use that procedure:
In addition to .bat files that run individual programs there is also a set of “special
purpose” bat files (termed “batch procedures”, section 14.7) that perform specific
“one-off” functions. For example, the procedure SATCOST (15.27.4) uses the
program SATLOOK in order to produce a matrix of o-d costs. Similarly there are a
number of procedures based on the matrix manipulation program MX which, e.g.,
add two matrices together or factor a single matrix; see 10.20.
The big advantage of batch procedures is that they allow the user to run certain
standard “bread and butter” operations based on programs which are normally run
interactively but in a totally off-line or batch mode. In addition the user may then
create their own “super-bat” files which string together a sequence of calls to
individual .bat files in order to run a series of operations off-line (e.g., overnight).
5120257 / Apr 15 3-8

Section 3
Full instructions for running both styles of batch procedures are found in Section
14.
3.6 Running Programs under WINDOWS: SATWIN10 and SATWIN11

This section shows you how to install SATURN and, briefly, how to run the latest
version via SATWIN 10, SATURN Ten’s User-friendly Interface or the newer
SATWIN11.
SATURN 11.3 is the current release version and is the successor to all the
previous versions of SATURN. A much earlier release, 10.2, introduced the
(then) fairly revolutionary change to a 32-bit rather than a 16-bit suite; 10.3 to date
are straightforward evolutions in this respect. As a consequence, the latest
release builds on a strong existing base whilst offering significant enhancements;
see the latest sub-section in Appendix D of the documentation for a full list of
changes per release version.
3.6.1 The SATURN Install Procedures

As for earlier versions of SATURN Ten, a Windows style SETUP utility is supplied.
To install SATURN 11.3 load the CD and, if the CD does not auto-run the install
process, double-click on:
♦ Setup.exe
You will be led through a series of install screens which will allow you either to
accept the standard folder setup or to select your own.
With the release of SATURN v10.9, the installation may also be undertaken using
the Microsoft Installer (ie .MSI) package – these are available on request
From SATURN 10.2 onwards, users may, if they prefer, install SATWIN10 under
\Program files\ rather than the default \satwin folder. This, and indeed installation
under any folder containing a space, was previously prohibited but this limitation
has now been corrected.
However, once a suitable home has been chosen, program executables and
assorted DLLs, bat and control files, help and PDF-based documentation will be
automatically installed on your hard disk. You can then run SATURN as
previously from a Command prompt (remembering to set the Path to the directory
chosen for EXE and BAT file, \SATWIN\XEXES\ by default and check preferences
in SAT10KEY.DAT), or to use SATWIN10 which can be accessed through the
desktop icon.
If you have a previous version of SATURN, this will be overwritten during the
installation process. However, users can keep previous versions of SATURN
(before installing the current version) by renaming the existing XEXES folder. This
could be renamed to say “XEXES 10.7.10” (where 10.7.10 indicates the version
number).
If multiple versions of SATURN are detected when SATWIN10 is launched, the
dialog box below will appear, enabling you to select the version to use in the
current session.
5120257 / Apr 15 3-9

Section 3
From SATURN 11.2 onwards, the user also has the option to install the newer
SATWIN11 front-end in preference to SATWIN10 - SATWIN10 is described in
section 3.7 whilst information for SATWIN11 is available in section 3.8.
3.7 SATWIN10 User Interface
3.7.1 Overview
SATWIN10 is a front end for SATURN with six principle functions:
♦ to run a single Module, e.g., SATNET or P1X
♦ to set up a Batch run (to run modules successively)
♦ to run from a command line
♦ to run the test network
♦ to enable other standard Windows “tools” to be invoked
♦ to interactively access the Manual.

These are selected from the main screen as below
5120257 / Apr 15 3-10

Section 3
The File menu is used to exit from SATWIN, for consistency with other Windows-
based software.
3.7.1.1 SATWIN10 and Windows NT/2000/XP/Vista/7/8.1

If SATWIN10 is launched on a Windows NT (or later) when logged in as a user
without write-access to the drive where SATWIN10 is installed, the following error
could occur:
♦ Run-time error 75 - Path/File access error

SATWIN10 normally creates and updates some ASCII text files during use;
consequently, it needs to be able to write to the drive where it is installed as well
as to the drive (if different) where "Working Folders" are located.
To address this problem the user should ask the system administrator to provide
write-access to the folder where SATWIN10 is installed as well as "Working
Folders" or log in as administrator.
3.7.1.2 Setting Folders

The Settings menu is used to select four standard folders where SATURN files
are stored
♦ the “working folder”,
♦ the “Program folder” where the .exe and .bat files etc. are stored,
5120257 / Apr 15 3-11

Section 3
♦ the “Control Files folder” (e.g. SATALL0.DAT etc),
♦ the “Manual folder”.

These are set automatically to correspond to the folders set during installation,
either by default or by explicit choice. Any later changes made are “remembered”
by SATWIN10 the next time you use it.
The latter three folders probably never need to be re-set once they have been
initialised for your installation. However the first “working” folder, which defines
the folder from where, by default, current data files are selected, tends to be
changed frequently as users shift between different projects. The current working
folder is displayed on the main SATWIN10 screen at all times.
3.7.2 Running a Single Module

From the main screen (see below), select Module Run using the mouse, followed
by “SATURN” and the selection of a specific module:
A new module-specific template will be displayed allowing you to select the

necessary files. For example, if you select the module SATURN (which runs
SATNET followed by SATALL), the template allows you the basic selection of a
network .dat file and a matrix .ufm file as below plus, optionally, UPDATE and/or
PASSQ files.
5120257 / Apr 15 3-12

Section 3
Once files have been selected, click on Run and the module executes. Upon
completion you have the option to view the output LP file or to run further
modules.
You can also run modules directly from the Events log in one of three ways:
1) Click and existing command in the Events log to highlight it, then press the
F2 or Insert key to enter Edit mode, then type a new command or edit the
existing command and press the ENTER key to stop editing. (Alternatively,
click the command to highlight it, then click it again to enter Edit mode.
Note that this is not the same as double-click, there is a pause between
clicks).
2) Click the entry <Click Here To Select, Then Press F2 Key or Click
Again To Enter A New Command> in the Events Log to highlight it, then
press the F2 or Insert key to enter Edit mode, then type a new command
and press the ENTER key to stop editing. Alternative is similar to option 1
above.
3) Drag a batch file (from the Desktop, Windows Explorer, etc.) and drop it on
the Events log.
4) After entering a command you can Double-click it, click the Run Items(s)
button, or press the F4 key to run it
Note: the Events Log now indicates the Program Folder (see below, fourth
column) containing the version of SATURN used to execute a command (in
addition to the Working Folder where data files reside, see below third column).
5120257 / Apr 15 3-13

Section 3
The image above for examples shows the following:
♦ The current “Working Folder” is D:\TEMP\SATURN MULTI-CORE\DMB312
♦ The first command SATNET CNET uses CNET data file from “Working
Folder” C:\SATWIN\TEST\CORDONSRN and SATNET v10.8.22 from
“Program Folder” C:\SATWIN\XEXES 10.8.22.
♦ The second command SATURN LIV10 LIVTRIPS uses data files from
“Working Folder” C:\SATWIN\TEST and SATURN (i.e. SATNET/SATALL
v10.8.22) from “Program Folder” C:\SATWIN\XEXES 10.8.22.
♦ The third command SATURN LIV10 LIVTRIPS uses data files from “Working
Folder” C:\SATWIN\TEST and SATURN (i.e. SATNET/SATALL v10.9.10)
from “Program Folder” C:\SATWIN\XEXES 10.9.10.
♦ The last entry in the Event Log indicate the current “Working Folder” (i.e.
D:\TEMP\SATURN MULTI-CORE\DMB312) and “Program Folder” (i.e.
C:\SATWIN\XEXES 10.8.22. This means that any commands issued within
SATWIN will use data files and SATURN modules from the respective folders.
You can change “Working Folder” and “Program Folder” at any time via the
Settings/Folders menu option.
3.7.3 Preparing a Batch Run

The “Batch Run” menu option may be used to prepare, edit and execute a number
of modules in sequence. This is done using the ’Batch Run Setup’ Dialog box as
shown below.
5120257 / Apr 15 3-14

Section 3
Double-clicking a SATURN module category from the displayed list will reveal the
available modules, a subsequent click to the module will select it. The “Set Module
Parameters” and “Module Help” buttons will also be enabled.
Resting the mouse button inside the box with the list of SATURN modules will
provide a one line description of the selected module.
Clicking the “Set Module Parameters” button will set the required parameters for
the selected module with the “Module Help” button provide additional supporting
information on that module.
After setting the module parameters, the command line will be displayed in the
editable batch file contents box. Further modules may be manually added to the
batch file contents text box.
The ‘Run’ button will start the module(s) in the batch file contents text box whilst
the ‘Save’ button will save the contents to a batch file for later re-use. The ‘Edit’
5120257 / Apr 15 3-15

Section 3
button will open the batch file in Notepad and the ‘Clear’ button to remove
information from the text box.
Previously created batch files may also be used by selecting via the “Select Other
Batch Files” button.
Note: instead of using the Batch Run menu, you may also drag batch files or the
SATURN executables (from Windows Explorer) and drop them into the Events log
to run them automatically.
3.7.4 Running from Command Line

This is perhaps the nearest equivalent to running SATURN from a ‘traditional’
DOS-type command prompt.
SATURN commands can be typed directly into the command line box or individual
modules and input files may be selected from pull down menus using the Select
Command and Select Parameter buttons respectively. This approach can be used
for interactive runs of modules e.g. MX I
To get help on supported DOS commands, press the F2 key on the keyboard.
Help on a selected SATURN command is automatically displayed on a side box to
the right of the Command Line dialog box. Using the Hide button will conceal the
help box. Pressing the F2 key after selecting a command will display the
command’s help information in a separate Help dialog box. You can press the
up/down arrow keys on the keyboard to step through previous commands if the
cursor is on the command entry box or use the ‘Previous Commands’ button to
display the list of previously used commands.
3.7.5 Running the Test Network

Possibly the first thing you would want to do on loading SATURN and SATWIN10
would be to run the test network.
Choosing a test network from the Test Network menu presents you with the Test
Run Template below corresponding to the network.
Test Network 1 will run MXM1 to build trip matrix HAT, followed by SATNET,
SATALL and P1X for network HEADE, leaving you in P1X interactive mode.
5120257 / Apr 15 3-16

Section 3
Upon exit from P1X, the following screen will allow you to view any of the LP files
generated
Test Network 2 will run SATNET, SATALL and P1X for network N10, leaving you
in P1X interactive mode, which in this example will show a background bitmap of
the network.
3.7.6 Other Tools

SATWIN10 also allows access to Notepad editor or a command line prompt
through the toolbar as below.
If the full or demo version of DRACULA is included with SATURN, the menu
option DRACWIN will appear on the SATWIN menu bar (see above). This
provides access to DRACULA through its front-end program DRACWIN.
3.7.7 Other Features OF SATWIN10
3.7.7.1 Quick Access to Modules

SATURN modules may be accessed by right-clicking on the event log.
(if PT-SATURN or DRACULA is installed from previous versions of SATURN
these options will also appear in SATWIN 10)
5120257 / Apr 15 3-17

Section 3
3.7.7.2 Selective Deletion of Event Log Runs
When several runs are displayed on the event log, you can delete selected runs.
The options are available to remove all commands in the log or a set of cursor
selected commands. Individual commands can also be deselected as above.
3.7.7.3 Batch Runs from modules selected in Event Log

You can also select modules or commands from the event log and run them in
batch mode. Simply hold down the CTRL key, click the modules you wish to run in
batch mode, then click RUN ITEM(S) or press the F4 key. You will have the option
to save your selection as a batch file before the run proceeds. This provides the
opportunity to be able to re-run the batch file again later if necessary.
3.7.7.4 Changing Working Folder

Double-click the Working Folder display bar to change folders. You can also type
in or copy and paste a folder in the folder display bar.
5120257 / Apr 15 3-18

Section 3
3.7.7.5 Editor of choice

SATWIN uses NotePad or WordPad to view LP files by default. You may specify a
different default editor by clicking Set Default Editor from Settings menu. The
default editor is used automatically when viewing LP files through SATWIN. The
editor can be accessed through the Tools menu
3.7.7.6 SATURN Manual

An Index to and Individual Chapters from the SATURN User Guide can also be
accessed directly from SATWIN.
3.7.7.7 SATURN Version Information

SATURN version information can be found on the bottom left of SATWIN 10
window as illustrated below.
Detailed SATURN version information (shown in the dialog box below) is available
through “SATURN Version Info” from the Help menu or by double-clicking the
version information area indicated above.
5120257 / Apr 15 3-19

Section 3
If the user wishes to Detailed SATURN version information (shown in the dialog
box below) is available through “SATURN Version Info” from the Help menu or by
double-clicking the version information area indicated above.
If “Version Unknown” appears in the selection box, SATWIN 10 was unable to
identify the specific version (eg a version of SATURN previously installed under
the XEXES directory).
5120257 / Apr 15 3-20

Section 3
The reference to the “SATURN Version Unknown” may be removed by the user
by:
♦ Determining the SATURN version and level in use. This may be readily
achieved by viewing any output Line Printer file using the executables – the
version and level in use will be reported at the top of the file (eg Version
‘10.5.12’ and Level ‘N3’); and
♦ Creating a new text file called “SATURN.VER”, in the same directory as the
executables, containing at least one line of text that says “SATURN <version>
Level <level>” – for example “SATURN v10.5.12 Level N3”
5120257 / Apr 15 3-21

Section 3
3.7.7.8 Using Other Programs from SATURN DOS Command Shell

Access to other non-SATURN (user) programs from the SATURN DOS Command
Shell is possible by specifying the full paths containing the user programs via
“SATURN DOS Command Shell Paths” from the Settings menu.
This will bring up the dialog box below. You can add paths containing other
programs you wish to have access to in the “Paths Containing User Programs”
text box by copy and paste or selecting a path through “Add Path” button.
5120257 / Apr 15 3-22

Section 3
3.7.7.9 Recent Event Log Commands

You can access the previous 15 commands issued on the Events Log via the File
menu.
The list can be cleared via the “Settings/Clear Recent Command List” menu
option
5120257 / Apr 15 3-23

Section 3
3.7.7.10 Save Events Log Commands for Later Use

Select the commands you wish to save from the Events Log, then click “Save
Item(s)” button on the Toolbar or “Save EventLog” from the File menu. The
commands are saved to a file you specify with the file extension .CMD. If you click
“Save Item(s)” without selecting a command, all the commands currently on the
Events Log will be saved.
To use previously saved commands, load an Events Log file via “File/Open
Eventlog File” menu option or drag and drop the file onto the Events Log.
3.7.7.11 SATURN File Associations

SATURN data files can be associated to SATURN modules including a
description of each file type when viewed in Windows Explorer via
“Settings/SATURN File Association” menu option. When active, a tick appears
next to the menu item. You can deactivate the association by clicking the menu
option.
Screen shot of a “Working Folder” C:\SATWIN\TEST in Windows Explorer with no

file association
5120257 / Apr 15 3-24

Section 3
Screen shot of a “Working Folder” C:\SATWIN\TEST in Windows Explorer with

SATURN file association.
5120257 / Apr 15 3-25

Section 3
LIV10L.UFS for example is described as “SATURN Loaded network binary file”

and is associated with P1X as indicated by icon. Unlike the description of UFS file
in screen shot without association.
When file association is active, double-clicking on a UFS or UFM file for example
will automatically open the file with P1X and MX respectively.
3.8 SATWIN11 User Interface
3.8.1 Overview
SATWIN11 provides an updated front end for SATURN, replacing the existing
time honoured SATWIN10 application.
SATWIN11 enables the user to undertake the following tasks:
♦ Easily access and discover categories of modules, e.g. Matrix Manipulation

or Conversion;
♦ Quick search for any module, e.g., SATNET or P1X by name or by keyword;
♦ Start a command prompt;
♦ Run the test networks;
♦ Starting standard Windows ’tools’;
♦ Access the SATURN Manual (either PDF or online);
♦ Manage error logs from SATNET; and
♦ Search for and launch your own Batch files.

SATWIN 11 also provides a new way of working with SATURN modules by
introducing a new concept of a ‘model-centric workspace’ called the ‘Model
Complex’.
3.8.2 The ‘Model Complex

A Model Complex can be saved, reopened and shared.
The Model Complex keeps track of the user’s working folders, the SATURN
version and their own tool folders (specifically batch files created by the user) as
well as keeping a log of the commands that have been executed while using the
given Model Complex.
At the end of a session the user will be asked if the user wishes to save changes
to the model complex – if they select ‘no’, the Model Complex will not be updated,
however any activity in the session will be saved in a last session log file that can
be opened next time SATWIN11 is used. This file is overwritten every time
SATWIN is closed.
5120257 / Apr 15 3-26

Section 3
3.8.3 Running SATWIN11
3.8.3.1 Starting SATWIN (‘Quick Start’)
The first time SATWIN is started you will see the Quick Start menu prompting you
to:
1) Restore the last session (using the auto saved session model complex
from the previous use)
2) Open the last used Model Complex (will be different to above option if the
user did not save at the end of last session).
3) Open an existing Model Complex. Let the user browse to a previously
saved Model Complex.
4) Create a new Model Complex with default values (same as clicking X).
The user can tick a box to automatically start the next SATWIN session where it
was left on last exit. This will mean that the quick start menu is not displayed. This
setting can be changed in the Tools tab.
3.8.3.2 Setting Folders and Properties for the Model Complex

The user may specify a name and a description for their Model Complex
5120257 / Apr 15 3-27

Section 3
The Settings menu is also used to select two standard folders where SATURN
files are stored:
♦ Model Working Folder – used for specifying data locations; and
♦ Program Folder – the path for the.EXE and .BAT files related to the SATURN
version.
Two other folders are automatically updated:
♦ Control Files folder (e.g. SATALL0.DAT etc) is automatically configured as

the \DAT under the SATWIN 11 install directory,
♦ Manual Folder – automatically set to the \DOCS folder under the SATWIN 11
install directory,
These are defined during the initial installation routine either by default or by
explicit choice. Any later changes made are “remembered” by SATWIN 11 the
next time it is used.
The current working folder is displayed on the main SATWIN 11 screen at all
times as is the current SATURN version.
3.8.4 Running a Single Module

From the ‘Home’ tab, click SATURN to start that specific module or alternatively
use the Search box on the Home tab to find the module to be run:
5120257 / Apr 15 3-28

Section 3
A new module-specific template will be displayed allowing the user to select the
necessary files. For example, if the module SATURN (which runs SATNET
followed by SATALL) is selected, the template enables the user to select the
network .dat file and a matrix .ufm file as shown below (plus, optionally, UPDATE
and/or PASSQ files if required).
Once files have been selected, click on Run and the module executes.
Each Module parameter window has options to keep the command prompt open
and apply either Quick and/or Quiet options. By default, the forms will remember
the previously selected files.
This behaviour may be changed – select the Tools  User Interface  Clear
Parameters check box. To clear the parameters, click the reset button.
5120257 / Apr 15 3-29

Section 3
All the Module Parameter forms have a feedback button allowing the user to share
their ideas with the SATURN development team via email. All the feedback
received will assist in the development of the future releases.
Upon completion of the module, the user has the option to view the output LP file
or to run further modules.
The user may need to refresh the file list before the newly created LP files are
available. To view the selected file in the user-defined text editor, click Show. To
review the errors in the Error Manager, click the exclamation icon.
3.8.4.1 Using the Command Log View to re-launch commands

The user may also run modules directly from the Command Log viewer by double
clicking an existing command in the list
To enter the Edit mode, right click on the Command Log entry  Edit Copy or 
Edit Task Description & Command Parameters. Then type a new command or
edit the existing command and press OK
The image above for examples shows the following:
5120257 / Apr 15 3-30

Section 3
♦ The current ’Working Folder’ is C:\SATWIN\Test; and
♦ The first command ‘SATNET Epsom98Net’ uses the Epsom98Net.DAT data

file from current Working Folder and the version of SATNET in the current
Program Folder.
The user may change the ’Working Folder’ and ’Program Folder’ at any time via
the Folder Settings menu option.
3.8.5 Running the Test Network

Once the initial installation has been completed, the user may wish to run one of
the SATURN test networks. The Test networks are located in the ‘Support’ tab
(i.e. Support Tab  Installation Checks  Test Networks ) and then either:
♦ the Headingley Test will run MXM1 to build trip matrix HAT, followed by
SATNET then SATALL and finally P1X for network HEAD leaving the user in
the P1X interactive mode; whilst
♦ the Epsom Test will repeat the same process for the N10 Network but this
time with a background bitmap of Epsom.
3.8.5.1 Other Tools

SATWIN11 also allows access to Notepad editor or a command line prompt
through the toolbar as below.
3.8.6 Other SATWIN 11 Features
3.8.6.1 Selective Deletion of Event Log Runs

The user may delete either some or all of the previous runs stored in the Event log
simply highlighting and deleting them.
3.8.6.2 Changing Working Folder

To change the working folder, click the Browse button next to the Working Folder
display bar to Change the Working Folder via a standard Windows folder menu.
Alternatively the user may type or copy/paste a folder in the folder display bar.
Note that the Up and Down arrows will enable the user to move through
previously used paths - this is a good example where it makes sense to have a
separate Model Complex for each working session). If the folder does not exist a
red frame will highlight the folder display bar.
3.8.6.3 Setting the Preferred Text Editor

By default, SATWIN 11 uses Notepad to view SATURN LP files but the user may
specify a different default editor by clicking Set Default Editor from the Settings
menu. The default editor is used automatically when viewing LP files through
SATWIN 11. The default editor may also be accessed through the Tools tab.
5120257 / Apr 15 3-31

Section 3
3.8.6.4 SATURN Manual

The SATURN manual may be accessed at all times from the SATWIN 11 interface
using the icons located in the upper-right corner. Clicking on the icons in this area
will enable the users to view the individual sections and appendices. The latest
documents may also be viewed online via the Support tab too.
3.8.6.5 SATURN Version Information

SATURN version information can be found just under working folder display as
illustrated below.
More detailed information about the SATURN version (as shown in the dialog box
below) is available either through Support tab  Support Info  SATURN
Version Info or by hovering the mouse over the SATURN Version in the settings
panel.
5120257 / Apr 15 3-32

Section 3
If the selection box states Version Unknown’, SATWIN 11 was unable to identify
the specific version (e.g. a version of SATURN previously installed under the
XEXES directory but without the SATURN.VER being created). The reference to
the ‘Version Unknown’ may be removed by the user by:
♦ Identifying the SATURN version and Level in use by viewing any of the output
Line Printer file using the executables. The SATURN Version and Level in
use will always be reported at the top of the text file (e.g. Version ‘10.9.24’
and Level ‘N3’); and then
♦ Creating a new text file called SATURN.VER in the same directory as the
executables, containing at least one line of text that says ‘SATURN <version>
Level <level>’ – for example ’SATURN v10.9.24 Level N3’
3.8.6.6 Using Other Programs via the SATURN DOS Command Shell
Access to other non-SATURN (user) programs from the SATURN Command Shell
may be undertaken by specifying the full paths containing the User programs via
SATURN Command Shell Paths from the Tools tab. Once selected, the dialog
box will enable the user to add extra path(s) containing other programs to be
used. They may be added to the Additional User Programmes Paths area by
selecting the path(s) via the ’Browse ...’ button.
3.8.6.7 Saving the Events Log Commands for Re-use

Command(s) in the Events Log area may be saved by selecting the command(s)
then either clicking ‘Save Item(s)’ button on the Toolbar or ’Save EventLog’ from
the File menu. The commands are saved to a user-specified file with the file
extension .CMD. If the user clicks on the ’Save Item(s)’ without selecting a
particular command(s), all the commands in the Events Log are saved.
To re-use previously saved commands, load an Events Log file via the ’File/Open
Eventlog File’ menu option or drag and drop the file onto the Events Log.
5120257 / Apr 15 3-33

Section 3
3.8.6.8 Changing P1X0.Dat preference file

In SATURN default behaviour of certain programs are determined by what is
known as preference files (see SATURN manual 15.2). One such preference file
is the P1X0.DAT file governing the default settings for P1X. This file is editable for
the user and it also may change slightly from version to version.
The file can be replaced as described in 11.2.3 or you can use the VersionsP1X
Preference File Version tool in SATWIN 11.
The tool works on the assumption that the current P1X0.DAT file is located in the
<program folder>\DAT\ folder and that other versions of the P1X0.DAT file is
found in the <program folder>\DAT\P1X0\ with a file naming convention like this:
P1X0_*.DAT where * is the unique title identifying the file to the user.
On selecting a file in the list that file is copied to the DAT folder overwriting any
previously used P1X0.DAT file
In short store your library P1X0.Dat files using the DAT\P1X0\P1X0_*.DAT pattern
and use the SATWIN 11 tool to set the default.
5120257 / Apr 15 3-34

Section 3
3.9 Version Control
11.1.09 SATURN v11,1 Release (Full) DVV AG IW IW 31/03/12
11.2.01 SATURN v11,2 Beta Release DVV JS IW IW 07/12/12
5120257 / Apr 15 3-35

Section 3
Creating an Origin-Destination Matrix File
4. Creating an Origin-Destination Matrix File

INTRODUCTION
Trip matrices used in SATURN are held as unformatted binary “UFM” files
(10.2.1), i.e., their standard filename extension is UFM. For example the input trip
matrix in Figure 3.1 is a UFM file. A comprehensive matrix manipulation program
MX is included with SATURN and is described in Section 10; full documentation
on matrices is given there.
The UFM trip matrix file may be created in a number of different ways; for example
using a wide range of input data formats from ascii/text files to MX as described in
Section 10.5, or using SATME2 as described in Section 13 to create it from
observed link flows. The “traditional” method using MX ascii input is described
next.
4.1 Trip Matrices using M1 or MXM1

This section describes the simplest procedure to create a trip matrix, illustrated in
Figure 4.1 below, based on an input ascii “.DAT” file with complete O-D data plus
certain other information to MX via the command:
MXM1 trips
or (more simply):
M1 trips
where MXM1 or M1 are simply .bat files which run the program MX in a particular
way. (Previously M1 was a separate program.)
By default the extension of the input file is assumed to be “.dat”; i.e., in the above
example the input file would be trips.dat as illustrated in Figure 4.1. However it is
possible to use other extensions (the modern trend would be to use .txt) by
commands such as:
MXM1 trips.txt
The ASCII file (TRIPS.DAT etc.) is formatted (see 10.5.1) as zone-to-zone flows
ordered (as is usual) first by origin and second by destination. However preceding
this data are four (sets of) header records:
1) RUN runname
2) &PARAM NROWS=nc,NCOLS=nc,MPNEXT=T, &END
3) TRIPS PCUH
4) matrixname
5120257 / Apr 15 4-1

Section 4
Figure 4.1 - Obtaining a .UFM Trip Matrix from a .DAT file
TRIPS.DAT
M1
TRIPS.UFM
Note:
♦ Capital letters above denote mandatory input; lower case letters denote
inputs which must be chosen by the user.
♦ Record (1) begins in col 1; runname should be chosen by the user and
begins in column 5.
♦ Record (2) is an example of an input record which uses the “Namelist”

facility to explicitly define certain variable values by name; see Appendix A.
“nc” is the number of zones in the network. This record may be divided up
into several lines rather than 1; see the example below.
♦ Record (3) must begin in col. 1 and have three blanks between the S and
the P. This record defines the matrix as a trip matrix in units of pcus per
hour.
♦ Record (4) begins in col 1; “matrixname” should be chosen by the user.
♦ Full details of the above “standard” format are given in Section 10.5.1,
although certain alternative formats, described in 4.4 below, were introduced
in SATURN 10.6.
Following the header records, each individual cell in the O-D matrix is given (by
default – see below) with up to 15 entries on each record in cols 1-5, 6-10, ...., 71-
75. (Fortran format 15I5). A new record is begun for each origin. The first entry
for each new origin, i.e., cols. 1 to 5 on the first record, contains the “name” of that
zone, followed by nc entries for trips to destinations 1, 2, 3,..nc. Hence the first
record contains trips for up to 14 destinations, whereas subsequent records
contain up to 15 destination trips, starting in cols. 1 to 5. The origin records MUST
appear in order of increasing zone names; i.e., the lowest origin first, the second
lowest next, etc., etc.
5120257 / Apr 15 4-2

Section 4
A fuller description of what is meant by “zone names” is given in 5.1.6 and 10.2.2.
An alternative “long” format is also available under which the matrix elements are
specified as real’s; see 10.5.1 for details.
In fact virtually any input format is acceptable by the program MX using interactive
commands; see Section 10.5.2 to 10.5.6. For example, the data may be contained
in a CSV-formatted file as produced by a Windows program such as EXCEL. In
addition, post release 10.6, the “batch” procedures M1 and MXM1 will also accept
various alternatively formatted files including CSV as explained in Section 4.4.
Hence transferring matrices from other suites of programs should not constitute a
problem.
The following sample file lists the beginning of the trip file for a network with 10
zones (so that only one record per origin zone is required).
RUN SECOND SATURNVILLE O-D RUN
&PARAM
NROWS=10,
NCOLS=10,
MPNEXT=T, &END
TRIPS PCUH
SATURNVILLE O-D
1 0 0 0 0 0 0 0 0 3
3
2 3 0 0 3 0 3 0 0 3
0
3 112 5 19 6 22 24 34 6 2
0
4.2 Important Trip Matrix Definitions

Note that the trip elements are given in pcus PER HOUR, independent of the
length of time period to be simulated. In other words they are specified as a rate
and the program itself will convert them into actual numbers proportional to the
length of the time period simulated, LTP.
Note also that, strictly speaking, the matrix can be either in terms of vehicles or
pcus, although the latter is generally more realistic and highly recommended.
The important point is to ensure that all network capacities, counts, etc. etc., are
defined in similar units to the trip matrices, i.e., pcus per hour or vehicles per hour.
For simplicity all documentation refers to pcus/hr as the recommended units. See
Section 15.17.
If, therefore, a separate trip matrix representing, say, HGVs is required it is the
responsibility of the user to ensure that the matrix is suitably defined in terms of
pcus/hr, not vph. If, as is generally the case, the originally provided HGV matrix
were constructed from a survey of vehicles or a demand model based on vehicles
it is equally the responsibility of the user to decide on suitable PCU factors in
order to convert vph (i.e., HGV/hr) into pcus/hr.
5120257 / Apr 15 4-3

Section 4
4.3 Further Notes on Trip Matrices

1) In general matrix files contain a single matrix T(I,J) of trips from zone I to J
although in certain circumstances, described in greater detail in Section 7.3,
it is possible to create a single “stacked” matrix file which contains more than
one trip matrix, e.g., a car and an HGV matrix, in order to carry out Multiple
User Class assignments. See 10.2.4.
2) If a series of time-dependent trip matrices is required to represent
successive time periods (using the PASSQ option, Section 17.3) and if these
matrices differ only by time-dependent factors then there are two labour-
saving options to avoid coding a separate data file for each time period: (a)
using the FACTOR options within MX to create a set of separate UFM matrix
files from one original file (10.7); or (b), using the GONZO parameter as
input to SATNET to factor the single matrix at the assignment stage (Section
6.3).
3) GONZO is much simpler and is therefore recommended but only for
relatively simple one-off “quick’n’dirty” tests. Thus when later analyses
require an explicit matrix, e.g. for comparison purposes, or if the matrix is to
be altered in connection with elastic assignment or SATME2 (13.1.10) then
using GONZO tends to lead to confusion as to whether or nor it is included
in the output matrices. Similar considerations also apply to cordoning (see
12.1.7).
4) An alternative method to factor the as - read trip matrix file is available under
multiple level user class assignment where a particular user class matrix
may be defined as a fraction of a “full” matrix. See 6.11. The same caveats
as expressed above with respect to GONZO apply here as well; i.e. if the trip
matrix is likely to be referred to explicitly or altered in any way then it is best
to create it with the appropriate factors in the first place.
5) In the assignments trip matrix cells less than a critical value TIJMIN (a user
definable parameter - see 6.3.3) are ignored as being irrelevant.
6) Thus any negative cells will always be ignored during the assignment,
although it is possible to over-ride this rule by setting a parameter ERTM to
.TRUE (see 6.3.1). Quite why one would want to do so I do not know and if
you do try it and find the computer crashes and erases half your hard disk
when it tries to take the square root of a negative number or whatever then
don’t blame me! A Serious Warning 172 is generated if any negative cells
are detected in a trip matrix to be assigned.
5120257 / Apr 15 4-4

Section 4
4.4 Alternative Matrix Formats using M1/ MXM1

Following release 10.6 it is now possible to use various alternative formats for the
“cell data” (as opposed to the header records) but still use either M1/MXM1 to
build a .ufm matrix from an input ascii text file.
For example, the input “.dat” file may contain the standard header records up to
and including the matrix title followed by the cell values formatted as described in
Section 10.5.4, i.e., CSV with one record per origin row.
1) The choice of data format is given by an integer parameter KROPT defined
under the &PARAM Namelist inputs; the “full” list of possible values consists
of:
2) Standard SATURN-formatted input file
3) User-defined format (with all O-D data included)
4) Non-zero elements only with I-J indicators (one record per cell)
5) Spreadsheet or Comma Separated (CSV) Format (one record per row)
6) EMME/2 Format
7) Tuba Format 1
8) Tuba Format 2
9) Tuba Format 3
where the default is 1. Further details of each individual format are given in
Sections 10.5.2 to 10.5.6
N.B. At the moment not all the above options have been implemented; in fact, only
KROPT = 4, CSV formats, and KROPT = 6, Tuba Format 1 (basically the same as
CSV) are currently available. The full set will become available if, as and when
users need them. All requests to either DVV or Atkins.
5120257 / Apr 15 4-5

Section 4
4.5 Version Control
5120257 / Apr 15 4-6

Section 4
Network Coding – A General Description
5. Network Coding – A General Description

INTRODUCTION
Section 2.3 introduced the distinction between simulation and buffer networks.
Section 5.1 following gives further information on how simulation networks are
specified, 5.2, 5.3 and 5.4 carry out a similar function for buffer networks, while
5.5 describes how, for certain functions the two are combined together into
“assignment” and “map” networks.
Section 5.6 gives very general advice on how users should - or could - create
networks, either starting from scratch or from existing data sources.
A “supplementary” form of network data, the “GIS file”, is described in 5.7.
5.1 Simulation Networks

This section provides a series of explanatory notes on how simulation networks
are coded. Specific coding details are given in Section 6.
Some of the information in this section also applies to buffer networks, e.g., node
numbers, but other sub-sections, e.g., 5.1.4 on turns, is specific to simulation
networks. Extra information on buffer networks is given in Sections 5.2 to 5.4.
5.1.1 Junctions/Nodes
Each junction is represented by a node in the simulation network. These are sub-
divided into ‘internal’ and ‘external’ nodes.
Internal simulation nodes must be specified in full as described in 6.4.1. They may
be further subdivided into 4 “types”: traffic signals, priority junctions, roundabouts
and ‘dummy’ nodes. Traffic signals should be self-explanatory and includes
pelican crossings. A ‘priority’ junction includes all form of ‘give-way’ junctions
including, for example, merges and uncontrolled junctions. Roundabouts are sub-
divided into two sub-types: those where U-turns are explicitly allowed (type 5) and
those where they are not (type 2).
5.1.1.1 Dummy Nodes

Dummy nodes require further explanation. Traffic flows through dummy nodes
are unrestricted (except for banned turns and U-turns) and without delay.
Basically they represent a ‘quick-and-dirty’ node coding and THEIR USE IS
GENERALLY NOT RECOMMENDED.
They do, however, have their uses. Dummy nodes need to be defined where
there would otherwise be two distinct links between the same two nodes in order
that the two links have separate identities. This occurs, for example, where an
exclusive bus lane is to be distinguished from the normal link. They may also be
used to identify the access point of a centroid connector more precisely, e.g., on a
very long link, or to represent points where new intersections are to be introduced
in modified networks.
5120257 / Apr 15 5-1

Section 5
They are also often used to indicate intermediate points on curved links (a
previous recommendation) but the use of the GIS files (see 5.7) to describe link
shapes is highly preferable.
Further information on how dummy nodes are simulated is given in 8.1.1 and how
they are used in conjunction with link capacity-restraint curves in Section 8.4.4.
5.1.1.2 External Simulation Nodes

External simulation nodes represent intersections on a cordon surrounding the
simulation network and may be further broken down into two categories:
(i) “true boundary nodes” which are connected directly to an external zone at
the edge of the network, and
(ii) “internal” joint buffer-simulation nodes which represent those points in the
network where the level of coding detail changes from simulation to buffer
(see 5.2 below).
In the first case they essentially identify points at which trips enter and/or leave the
(simulation) network from the outside world and may therefore be purely notional
intersections. In the second they normally represent “real” intersections which
have a “dual nationality” as part of both the simulation and buffer networks.
(Similarly there may be true boundary nodes at the edge of the network which are
defined within the buffer network only but those nodes are not otherwise
distinguished from other buffer nodes.)
In principle an external node could have both functions, i.e., it could be connected
to an external zone and continue into the buffer network but such a representation
may lead to problems and should be avoided; see Section 15.11 for further
details.
Links from an internal to an external simulation node have no delays calculated at
downstream stop-line (i.e., at the external node itself) as part of the simulation,
although link-based speed-flow curves may be defined for ”out-bound” external
links which give an equivalent delay - see Section 15.13. Indeed if the external
simulation link does lead into the buffer network a speed-flow curve is strongly
recommended. (On the other land “in-bound” simulation links from an external
node do not necessarily require a speed-flow curve since delays are calculated for
each turning movement at the internal simulation node.)
Less input information is required for external nodes - only the starred data (*) in
6.4 and indeed using the AUTOX option (Section 15.12) they need not be
explicitly coded at all.
External nodes need not be ‘physically’ external - for example, an internal parking
lot might be represented by an external node as illustrated in Section 16.6.6.
5.1.2 Node Numbers

Nodes, whether internal or external, are identified by node numbers. In SATURN
node numbers need not be strictly sequential, i.e. 1, 2, 3 ..., but may take any
values desired by the user; indeed some form of hierarchical or informative node
numbering system is highly recommended.
5120257 / Apr 15 5-2

Section 5
Node numbers must (normally) be in the range 1 to 99998, i.e. up to 5 digits.

(99999 is excluded as a valid node number since it is commonly used to signify
the end of data sets.) However the use of 4-digit simulation node numbers
(maximum) is strongly recommended – unless, of course, the total number of
nodes is so large that 5-digit numbers are unavoidable.
Note that, if a parameter DUTCH is set equal to T in &PARAM in a network data
file (see 15.20) then node numbers may be up to 8 digits long.
In addition to the numerical identification nodes may also be given an “alpha-
numeric” name, e.g., node 1513 might be “Hyde Park”. These names are
contained within the GIS file (optionally) associated with each network file. See
Section 5.7 for general details and Appendix Z for specific format details.
5.1.3 Roads
Roads between intersections are represented by “links”, which are numbered
sequentially in a clockwise direction about successive nodes. The actual link
numbers are calculated by the computer and remain largely invisible to the user,
to whom a link is specified by the nodes A and B at its upstream and downstream
ends respectively (A-node and B-node). However the user must ensure that the
links at each junction are correctly input in clockwise order (or counter-clockwise if
drive on the right - Section 15.6); otherwise largely uncheckable errors result.
As with nodes links may also have “alpha-numeric” names, e.g., link (1512,1513)
might be “Grosvenor Terrace”. These names are contained within the GIS file
(optionally) associated with each network file. See Section 5.7 for general details
and Appendix Z for specific format details.
Both directions of a “road” must be coded, even if the road is one-way. One-way
links are represented by specifying zero lanes (LANES below) to the non-existent
direction. For example a one-way road from node A to node B must be included
as a link at A from B (with positive lanes) and also as a link at B from A (with zero
lanes).
Generally speaking travel times on simulation links are assumed to be fixed at
their “free flow” values and link capacities, to be, in effect, “infinite”; i.e. much
greater than the junction capacities at their downstream end. However this
assumption may be relaxed and link speed-flow curves and explicit link capacities
modelled; see 8.4.4.
The minimum data required by the simulation stage for a road (e.g. times,
distances) is coded on the “Link Description Records”, Section 6.4. However note
that additional link data, e.g., a capacity index, which is not needed for the
simulation may also be defined using the buffer data records described in Section
6.6. See Sections 15.13 and 15.14 for a more complete description.
5.1.4 Turns
In addition each potential turning movement (including banned turns - see below)
is explicitly represented in the (simulation) network. Turns are assigned sequential
numbers which, like link numbers, are essentially invisible to the user who refers
to turns by a sequence of three node numbers A-B-C. It is essential that turns be
defined in strict clockwise order from each link, starting with the first turn to the left
5120257 / Apr 15 5-3

Section 5
(or counter-clockwise starting with the first turn to the right for drive on the right -
see Section 15.7.2).
The user must define a saturation flow (6.4.6) for each simulation turn; banned
turns are therefore coded by setting this turn capacity to 0.
U-turns are generally banned at simulation nodes and therefore need not be
explicitly coded EXCEPT for roundabouts coded as junction type 5 where they are
automatically generated. N.B. U-turns may also crop up in the slightly different
context of the border between simulation and buffer networks as explained in
Sections 18.9.1 and 16.6.4.
Unlike links turns have flow-dependent delays and flow-dependent capacities
determined by the simulation process. Further details may be found in Section 8.
Turning movements which must give way to other streams of traffic, for example
turns from a minor road giving way to the major arms at priority junctions, are
indicated by a series of ‘priority markers’. The degree to which these turns are
impeded depends on both the ‘major’ flow and the ‘acceptance gap’ defined by
the user. Detailed equations are given in Section 8.2.2. The main features of the
relationship between the ‘minor’ and ‘major’ flows are qualitatively illustrated in
Figure 5.1 which plots the minor road capacity C as a function of the major road
flow V for two different GAP values.
Figure 5.1 – Minor Road Capacity C versus major road flow V
SAT is the ‘saturation flow’ from the minor arm with zero opposing traffic. Clearly
as traffic on the major arm increases the flow from the minor arm decreases, and
as the required gap increases the minor arm capacity decreases as well.
5.1.5 Restricted and/or penalised movements

Roads and/or turns may be restricted to certain “user classes” of traffic (see 5.8.1
with other user classes banned). In particular roads or turns may be set as “bus
5120257 / Apr 15 5-4

Section 5
only”; i.e. buses following fixed routes may use these turns/links but the vehicles
which are assigned routes within the assignment may not.
For detailed coding instructions please see 6.4.4 for bus-only restrictions or 6.7
(the 44444 data) for more general restrictions within simulation networks which
include bus-only as a special case.
Restrictions also include “penalties” where a penalty is an extra perceived cost
associated with using a particular link or turn and applied to the definition of
generalised cost within route choice. Penalties may be either “notional”, e.g. an
extra cost levied on uninformed drivers using a non-signposted rat run, or “real” in
the sense of a monetary toll imposed on drivers or an extra time added to lorries
travelling down a windy road. As with bans they are very often user-class specific.
In addition penalties may either be defined in pure time units (seconds) or in
monetary units (e.g., pence), in which case they represent tolls imposed on
(certain classes of) drivers as with road charges; see section 20. In either case
they are included as an element within the “fixed” link costs for assignment
purposes as opposed to the variable “time” component. Time penalties are
converted into generalised cost units as and when necessary using PPM
(although, since most of the time, generalised cost works in units of generalised
seconds, no explicit conversion is required). See 7.11.1.
Under certain circumstances it may be desirable to explicitly include time penalties
as part of “normal” time, e.g., for the purposes of skimming O-D times (15.27). On
the other hand, if the penalty times are more “notional” than “real”, they may be
excluded from, e.g., time skims. See 15.24.2 and 15.24.4.
5.1.6 Centroids / Zones

In addition to the “real” network nodes and links the user must also define
centroids and centroid connectors. (Although the use of the AUTOZ option as
described in Section 15.12 may reduce the actual input required.)
Centroids are often referred to as zones and the terms are virtually
indistinguishable.
The conventions used within SATURN may differ somewhat from those used in
other suites. Firstly, centroid or zone numbers or “names” do not need to be
numbered sequentially; as with nodes any numbers may be used. In addition
nodes and zones may have the same numbers; i.e., you may define a zone 15
and a node 15 without fear of confusion within SATURN (although the user might
well be confused!). The general convention adopted within SATURN programs to
distinguish “real” nodes from zones in input files is to include the character “C” in
the first input field; see, for example, 6.8.
Since zone “names” are not sequential the maximum zone “name” may be greater
than the number of zones. A parameter MAXZN, set by the user under &PARAM
(6.3.2), defines the maximum zone name (or an upper limit) used although its
value may be over-ridden by the network inputs. Thus if you explicitly define
MAXZN = 100 but later define a zone numbered 150 within either the simulation or
buffer network data then MAXZN is changed to 150. It is therefore not a
particularly critical parameter.
5120257 / Apr 15 5-5

Section 5
There is, however, (post SATURN 10.3) one exception to this rule which is when
the user sets NO333C and/or NOXYC = T in &PARAM. In these cases MAXZN is
used to distinguish when a node number used within, respectively, the 33333 or
55555 data records is a zone or a node and therefore the value defined in
&PARAM must be correct in the first place. See 6.8, note 11).
Zone numbers may normally have up to 5 digits (i.e., be numbered up to 99999)
although the use of 5 digits is not normally recommended. It may, for example,
create problems with certain data input fields (see 6.8) where a C followed by the
zone number is used to distinguish between zones and nodes and the complete
field must be contained within 5 columns (although these problems are not
insurmountable). In addition the matrix manipulation program MX generally uses
5-column fields for the input of zone numbers and in output formats. With buffer-
only networks with DUTCH = T (implying 8-digit node names) 8-digit zone names
may, strictly speaking, also be accepted within network programs but matrix
manipulation would still be extremely difficult.
Zero or negative zone numbers are definitely not allowed in networks (fatal errors)
although, strictly speaking, it may be possible to introduce them into matrices.
However the practice is certainly not recommended and will be made fatal ASAP;
see 10.2.2.
The total number of zones is limited to, e.g., 400 (see 15.28) within certain matrix
programs although the main simulation-assignment programs are not restricted in
this way.
Zone numbers or “names” must also be defined on the trip matrix data input
described in Sections 4 and 10.2.2. Thus if the lowest zone number is 5 this
information should be included as the first input number for the first row.
Clearly it is best if both network and matrix adopt the same system of either
sequential or named zones to avoid any possible confusion. However SATURN
programs which use both a network and a trip matrix (e.g., SATALL) will overlook
certain differences but not all.
For example, it is permissible to have “names” in one and sequential numbering
in the other (as long, of course as the number of zones is the same in both);
SATURN assumes that the two sets correspond one-to-one. Equally, it is (just)
acceptable for both to have “names” but a different “system” of names in each
case (e.g., 1, 3, 5 in one, 10, 20, 30 in the other) - although highly questionable
and it should provoke a Serious Warning at least.
However, a Fatal or Semi-Fatal error will result if the same zone name appears in
different positions in both network and matrix. For example, if the network zones
are 1,3,4,5 … and the matrix zones are 1,2,3,5… then zone 3 appears as either
the 2nd or the 3rd zone. Highly suspicious! And new in 10.6.
It is possible to change the zone names in a trip matrix to match those in a
network by using MX as explained in 10.3.3.
As with nodes zones may also be given an “alpha-numeric” name, e.g., zone 5
might be “Mayfair”. These names are contained within the GIS file (optionally)
associated with each network file. See Section 5.7 for general details and
Appendix Z for specific format details.
5120257 / Apr 15 5-6

Section 5
It is also possible to define the geographical boundaries of zones as “polygons”

within GIS files although as yet this information is not directly used in any outputs
or analyses.
5.1.7 Sectors, Traffic Boroughs and/or Groups (including TfL rules)
5.1.7.1 Sectors
A further optional level of zonal definition, “sectors” which are aggregates of
zones, was introduced with SATURN 8.2 and later extended, by implication, to
apply to nodes as well. Although the number and hence the size of the sectors is
arbitrary the basic intention is that they should NOT be “large” such that the study
area should be divided into 10 or fewer sectors. With more than 12 sectors it is
sometimes difficult to print full sector-to-sector matrices on terminal screens.
Unlike nodes or centroids in SATURN sector values of 0 are permitted (and, see
below, is used as a default). The normal program array limits permit sector
numbers in the range 0 to 20; hence a total of 21 sectors but not sector 21 itself.
Sectors may be defined most easily if you use a “hierarchical” zone numbering
system, e.g. such that zone 680 is by definition in sector 6, zone 564 in sector 5,
etc. Thus a single parameter IROCKY (pronounced “hierarchy”!) - 100 in the
above example - is sufficient to define the conversion of sector to zones. Note
here that, e.g., zone 50 would be in sector 0.
Otherwise the correspondence may be explicitly defined using either the ‘555’
network data records - see Section 6.8 - or the GIS file - see Section 5.7.
In either case all zones whose sectors have not been explicitly defined will be
assigned the default sector of zero. This may cause some confusion if you are
explicitly assigning sector 0 to some zones since the explicit and default settings
may be confused; this practice is not recommended and generates a warning
message in SATNET.
As with zones, sectors cover both buffer and simulation networks - and indeed are
independent of the level of network definition. The only explicit property
associated with sectors, apart from their constituent zones, are co-ordinates - see
6.8. These are used by P1X in plotting sector row and column totals.
Note as well that the concept of sectors applies to both network and matrices so
that the matrix program MX may also use sector definitions for both display and
manipulation, e.g. factoring; see 10.2.5. In addition the use of both TFL rules
and/or IROCKY may be applied to both network and matrix files.
5.1.7.2 Traffic Boroughs: TfL Node and Zone Numbering Conventions

From release 11.2 a further “global” conversion logical parameter TFL was
introduced such that if TFL = T in either network or matrix .dat files (see 6.3.1 and
10.5.2.4) then the hierarchical rules used in Transport for London networks are
assumed to apply.
Thus in a 5-digit zone number the first digit defines the sector and the first two a
“traffic borough”; e.g., zone 22341 is in sector 2 and in “traffic borough” 22 (but
see below for the precise rules used to extract traffic boroughs from zone/node
5120257 / Apr 15 5-7

Section 5
numbers). Similar rules apply to node numbers with 5 or more digits. (It is
assumed that if a zone/node has less than 5 digits then the TfL rules do not apply
and that zone/node would be allocated to borough/sector 0.)
We further note that traffic borough numbers are grouped together in sets of two
thousand, i.e., node/zone numbers 10xxx and 11xxx are both in the same traffic
borough 1, the City of London, (since there should be no node numbers less than
10,000), as are 12xxx and 13xxx in traffic borough 2, Westminster, etc. etc. Thus,
in total, there are 45 possible traffic boroughs with numbers in the first ranging
from 10,000 to 11,999, in the second from 12,000 to 13,999, etc., and in the last
(45th) from 98,000 to 99,999..
In general traffic boroughs should be geographically “self-contained” in that nodes
in any particular borough should: (a) only be connected to other nodes in the
same borough or (b), if they lie on the boundary, to at least one other “interior”
node in addition to their external connections. Thus a node which is entirely
surrounded by nodes in different traffic boroughs has (probably) been numbered
incorrectly.
A similar error may arise with zones which are in traffic borough N (according to
their first two digits) but which are entirely connected to nodes which lie in different
traffic boroughs.
Traffic boroughs may be used either to automatically aggregate zonal trip matrices
to a borough-to-borough matrix (see 10.4.4, 10.16.2 and 10.20.24) or to output
network summary statistics disaggregated by borough (see 11.11.4 and 15.59.1).
5.1.7.3 Groups of Zones and/or Nodes

The term “groups” is used to apply to any aggregation system of nodes and/or
zones. Thus both sectors and traffic boroughs are examples of “groups” but more
general user-set definitions are allowed. In general these are defined by files
referenced by parameter names such as FILN2G or FILZ2G.
See Section 10.2.5 for application of groups of zones within matrices and 15.59
for applications of groups of nodes and/or links within networks.
5.1.8 Simulation Centroid Connectors

Within the simulation network centroid connectors are connected to links, not to
nodes as in most conventional assignment suites. Thus if zone 7 is connected to
link (67, 80) this is taken to imply that trips into zone 7 do so by exiting the link
directly FROM node 67 at the upstream end of the link. Similarly trips out of zone
7 are assumed to enter the network at the downstream - node 80 - end of the
link, again as though they had parked on the link. In effect, they may be thought of
as parking somewhere between 67 and 80 (and in that direction) although their
contribution to flows on that link entering and/or leaving are ignored.
Diagrams in Sections 15.16 and 16.6.1 illustrate the geometry envisaged.
We note that simulation centroid connectors are not the only source of “entry
flows” and “exit flows” on simulation links: bus flows (see 6.9.2) and flows passed
from a previous time period under PASSQ (see 17.3.1) may also contribute. See
15.16.2.
5120257 / Apr 15 5-8

Section 5
Centroid connectors are uni-directional so that, for example, two connections

would be necessary to represent vehicles parking on both sides of a link. The
effect is similar to attaching centroids to ‘dummy’ nodes in the middle of links, a
common practice in conventional models, but of course here it is not necessary to
include an extra mid-link node.
The one exception to these rules is where the link defined is an “external” or
“cordon” link, i.e., a link in which one node is an external node. In these cases
trips are assumed to both enter and leave the network at the “external” node, e.g.,
at the network cordon. Examples of these coding conventions are shown in
Sections 16.6.2 and 16.6.3 - in both these cases the connector IS two-way (unlike
the internal connectors described above) so that only a single link needs to be
specified to allow for both in-bound and out-bound traffic. (Though clearly if the
external link is one-way only the appropriate movement will be coded.)
Equally clearly external zones will not need to be included at external nodes when
the network continues into a buffer network - see Section 5.3.
5.1.8.1 Spigot Centroid Connectors

If desired, users may code all simulation centroid connectors via external zones
and external simulation links by creating artificial “spigot links” which connect an
(extra) external node to an (extra) internal node created in the middle of the
simulation link with the zone attached to the external node (as shown in Section
16.6.2).
The (perceived) advantage of spigot simulation connectors as above is that the
flow(s) on the simulation link are more unambiguously defined (see 15.16). The
disadvantage is that it requires two extra simulation nodes to be defined, with
consequent increases in RAM and cpu requirements, and may, arguably, make
the network plots look less realistic. (N.B. Centroid connectors, whether internal or
external, are represented by dashed lines in network plots which may be
optionally suppressed if desired to improve the appearance of plots (see section
11.6.4, note 7).
In terms of actual assigned flows there may be very little difference between the
two methods since, in topological terms, both methods force flow leaving an origin
zone to appear at the downstream end of a simulation link where it may then
choose one of the alternative turns. And similarly with exit flows. On the other
hand, if a zone has more than one centroid connector, the choice between them
may be influenced by the precise method of coding.
Some users prefer to define all internal simulation centroid connectors via spigots,
others do not. It is very much a question of personal preference. My own (DVV)
view is that all forms of centroid connectors from zones which represent a
dispersed area (as opposed to, e.g., point source zones such as car parks or
specific connections from self-contained developments) are approximations which
almost inevitably distort the locally assigned flows and, as such, there is no point
in trying to be overly sophisticated. I.e., connect to links; there are lots of other
issues to worry about in network coding.
5120257 / Apr 15 5-9

Section 5
5.1.8.2 Centroid connector properties

Under most circumstances simulation centroid connectors are purely “notional”
links and therefore have no time or distance associated with them and, in effect,
infinite capacities. The one exception to these rules are centroid connectors to
links which block back and a portion of the blocked back queue is transferred onto
the centroid connector; see 8.5.2.
On the other hand centroid connectors within the buffer network (defined under
33333) may have a time, distance or toll associated but any time is considered as
fixed, i.e., it cannot have a speed-flow curve associated.
5.1.9 Link Capacity Indices

Every “link” in a SATURN network, whether a simulation or a buffer link, may have
a numerical “capacity index” associated with it. The term “capacity” is probably
somewhat misleading since, as we see below, the indices used may have very
little to do with capacity per se. However historically they were originally used in
conjunction with capacities and the name has stuck.
Capacity indices are used to distinguish groups of links with some common
attribute which might be, e.g., either geographical or physical. For example, they
might be used to define a “jurisdiction code” based on location or else a “link type”
(e.g., motorway/A-road/B-road); the definition and the system of indices used are
purely at the discretion of the user.
Indices have several applications. For example network summary statistics may
be printed disaggregated by index, or they be used in P1X to define which links
are to be displayed and which suppressed. Equally they may be used to define
link colours and widths on P1X graphical output.
The index is usually defined within columns 43-45 of the ‘33333’ data records,
usually associated with buffer links, but in this case equally applicable to
simulation links; see Section 6.6. It may also be defined directly for simulation
links using the added mid-link capacity restraint record, or the network X-file; see
6.13.
Indices may also be associated with the (simulation) turns out of a link so that the
summary statistics above include turn delays in addition to link-based delays. To
request this option set the parameter BEAKER to TRUE. See 17.8.
In general the value of an index does not directly affect the way in which a link is
modelled, one possible exception being where capacity indices are used to define
“default” speed-flow curves for either simulation or buffer links as described in
Section 15.9.5. The default values “replace” blank values on input cards and
therefore set link characteristics.
Indices must be in the range 1 to 999 but are generally limited to a maximum of
199 used values. In addition each index may be assigned a “text” name of up to
20 characters (CINAME - see 6.3.4). Links which have not been assigned an
index have a default value of zero such that, for example, summary statistics may
be printed for “Capacity Index 0”.
5120257 / Apr 15 5-10

Section 5
5.1.10 Node Co-ordinates

Each node or zone in the network is assigned a geographical X,Y co-ordinate
where X represents its east-west position and Y, its north-south. Strictly speaking
co-ordinates are optional but, given the wide use of graphical outputs with
SATURN, they are virtually essential for most applications.
Co-ordinates are input as part of the basic network .dat files using the rules given
in section 6.8.
The choice of the system used to define the co-ordinates, i.e., where is the 0,0
origin located and what scale is used, is essentially arbitrary and up to the user to
decide. However we strongly recommend that for all “realistic” networks (i.e., not
a network of 4 nodes created for demonstration purposes) some form of “rational”
system be adopted. In particular we would recommend the use of a system based
on Ordnance Survey (OS) or equivalent conventions, not least to enable the
transfer of data to and from other data sources such as GIS systems.
The “units” used to define co-ordinates are again arbitrary although the use of
metres (or 10’s/100’s etc. of metres) is equally strongly recommended. Note in
particular that if the co-ordinates defined in the network .dat files are in units of
10’s of metres than the parameter XYUNIT should be set equal to 10.0, or 100.0 if
the units are 100’s of metres, otherwise certain features of the graphical displays,
e.g., the apparent widths of roads, may be out of scale by a factor of 10 or 100.
Note that the same set of co-ordinates is also used to define the location of
“bitmap” images which may be used to provide a background to P1X network
plots and, generally speaking, this is much easier using a co-ordinate system
based on OS. See 15.43.
5.1.11 Flow Metering and Blocking Back

Two of the most important properties of simulation networks (which help
differentiate SATURN from other traffic assignment models) are the way in which
the simulation models “flow metering” and “blocking back”.
Thus “flow metering” refers to the phenomenon whereby, if a flow V enters a link
with capacity C where V > C (so that the link is a “bottleneck”), then the exit flow
(rate) must equal C which will therefore be less than the total “demand flow V”.
And, equally, all further links downstream along those O-D paths used by the
flows caught in the bottleneck will suffer reduced flows. See Sections 8.2.7 and
17.2 for more complete explanations of the process.
By contrast, “blocking back” works in the reverse sense in that if a queue forms on
a link which is physically longer than the length of that link then that queue will
spill back into the junction upstream and reduce the capacity of traffic to enter the
blocked link. Clearly blocking back on one link may then cause further blocking
back on one or more links upstream with potentially much wider impacts on delays
and hence route choice. See 8.5 for a more detailed explanation.
We note that neither of these effects is properly catered for within buffer networks
as described next.
5120257 / Apr 15 5-11

Section 5
5.1.12 Link Chains of Continuous Sub-links

A common coding practice in SATURN, for good reasons or bad, is to sub-divide
a “real” road between two “real” junctions A and Z into a series of sub-links by
including one or more intermediate 2-arm (typically dummy or priority) nodes
B, C, D ... as illustrated in Fig 5.2a). One reason for coding intermediate
nodes is to give a link its correct “shape” in network plots – whereas, as all
good users know, a much better way to provide a link shape is to use GIS
files (see 5.7.1). Better reasons are to represent sub-sections of the link
which include bus lanes, reduced lanes due to near-side parking or flared
lanes.
Figure 5.2 – Examples of Link Chains
We refer to such a string of sub-links as a “link chain”, the essential property of

which being that traffic entering at Z must proceed directly to A with no chance of
any exit or entry traffic en route (and, generally but not necessarily, no delays at
intermediate nodes).
Including such sub-links may solve particular problems for the user but they may
also create additional problems for the modelling of delays and capacities. For
example, we would expect that a queue which forms at the head of a chain would
queue back “seamlessly” into the preceding sub-links so that it would be most
natural to treat that queue as a single queue between Z and A rather than as a
series of individual link queues. Equally it would be best to represent the delays
associated with that queue as a single delay on one link rather than trying to
subdivide them into a set of shorter delays per sub-link (in the pious hope that the
sum of the sub-delays would correctly equal the total delay).
The intermediate nodes B, C, D etc. may be junction type signals, priority and/or
dummy simulation nodes but not roundabouts (why would one code a roundabout
with 2 arms?) while externals would also not be permitted for reasons of
geometry.
There can be more complicated examples of the same basic phenomenon. For
example, Figure 5.2(b) represents a link with a central bus lane between D and B
which has been coded as a set of two links D-C and C-B in parallel with the “main”
road.
5120257 / Apr 15 5-12

Section 5
Figure 5.2(c) illustrates a 2-way link into a roundabout which, near the point of
entry, has been split into two short one-way links to represent the physical
separation of the entry and exit points at the roundabout. In this case Z-B-A
represents a chain as does R-B-Z.
Figure 5.2(d) a 4-arm junction at B which basically boils down to two straight-
through chains A-B-D and C-B-E.
In addition combinations of all the above examples may be created “in series” to
create sets of “super-chains”.
Note that chains are always a set of directional links even if the individual links
themselves are not one-way. Thus in Figure 5.2(a) we could have one chain from
Z to A and another from A to Z if all the links were 2-way (having a combination of
1-way and 2-way links between A and Z would be a fatal error). Note also that a
chain may not have any centroid connectors to intermediate links.
5120257 / Apr 15 5-13

Section 5
In order to help identify such possible adverse modelling conditions post 10.9 a
routine has been included within the network build program SATNET to identify in
advance any presumed occurrences of chains so that they may be consistently
handled within the later simulation and assignment phases of the model. A list of
all chains located is included within the .LPN file.
Applications of chains to blocking back are referred to in Section 8.5.5 and to
random delays in 8.6.4. Chained links may be displayed as a link data item via
P1X.
5.1.12.1 Breaking Chains

Post 10.9.18 a new rule has been introduced to allow asset of links which would
not normally be defined as a chain to be “broken” by defining a negative link
stacking capacity (see 6.4.11). Thus, in Fig 5.2.(a) above, if the stacking capacity
on link D-C were input with a negative value then C becomes a “genuine” node
through which a chain cannot proceed. So in this case links Z-D and D-C would
be one chain, C-B plus B-A would be another.
This mechanism is often useful if the capacity at C is likely to be less than that A,
for example if the link goes from 3 lanes down to 2, or if some other form of “flow
metering” is being applied.
See Section 8.5.5 for an application to blocking back.
5.2 Buffer Networks

The buffer network facility allows the user to define a much larger network than
would normally be done using a simulation network. For example the user might
wish to study traffic management schemes in one small area of a large city, but to
take into account possible implications of local measures on the traffic flow in the
city as a whole. In order to do so the network is divided into two regions:
An “inner” or “simulation” network coded in great detail; and
An “outer” or “buffer” network coded in much less detail.
The resulting network may therefore be thought of as a doughnut with the
simulation network in the middle. The essential difference is that the simulation
network has both junction and link data; the buffer has only link data. In
topological terms this means that simulation nodes are “expanded” to include
turning movements as sub-links within the assignment network (see Fig. 5.3),
buffer networks contain only “road” links.
An alternative, and much less convenient, method to test network-wide impacts of
local schemes would be to use a large-scale network to test the long-range
effects, and then to cordon off a sub-matrix of trips for the central area and to
“simulate” this network. Apart from obvious problems with differences between
the two networks this method can be both time consuming and complex. The
buffer network removes such problems.
It is also possible to use SATURN to model purely link-based networks by totally
excluding the simulation network. This option might be of interest to users wishing
to model very large networks, even say national road networks, where the specific
5120257 / Apr 15 5-14

Section 5
properties of junctions are relatively unimportant. Section 15.8 illustrates the

network coding.
A further potential use of a buffer networks is to describe a network of “walk links”,
e.g., in a pedestrianised area. In this case the trips might represent ultimate
destinations such as shops and the trips would reach these trips via routes which
would take them through the simulation network to an external node
(representing, for example, a car park) through a section of so-called buffer
network, the links of which represent walking links and are coded with appropriate
travel times.
Note as well that the data input used to define the buffer network may also be
used to define additional data for simulation links - see Sections 15.13 and 15.14 -
as well as providing a useful starting point for re-defining buffer nodes as
simulation nodes - see Section 11.9.2.
5.3 Defining the Buffer Network

The buffer network data required by SATNET consists of link-based data only
without any node-based data. Note that there is no provision for coding banned
turns or turn-specific delays (although they may be effectively included by certain
coding “tricks”).
In addition centroid connectors are defined from zones to nodes as opposed to
the simulation network where they are (optionally) coded to links (5.1.8).
More specifically the data associated with a buffer link - and hence the data that
must be incorporated in the input .dat file - may be summarised as follows. Each
link requires:
♦ An “A-node” (the upstream end of the link)
♦ A “B-node” (the downstream end of the link)
♦ The link distance
♦ The link capacity
♦ The travel time (or speed) under free-flow conditions
♦ The travel time (or speed) at capacity
♦ A “power” n for the cost-flow curve - see 5.4
♦ A capacity index (optional)

See Section 6.6 for format details.
The buffer network is integrated with the simulation network as a single
assignment network; see 5.5.1. O-D routes are based on the assignment network
and therefore can use both buffer and simulation links.
The simulation and/or buffer networks share a single zoning system. Thus it is
not, for example, permissible to have zones with the same names in the two
different sections. In addition the total number of zones defined in both sections
must equal the total number of zones defined in the trip matrix. Very often users
5120257 / Apr 15 5-15

Section 5
who have started with a conventional network and coded part of it as a simulation
network will find it necessary to “expand” the simulation zones into a series of finer
‘sub-zones’. In these cases it will also be necessary to “expand” the trip matrix for
these zones; this can be done using procedures within MX, see 10.16.3 and 10.4.
There are limits placed on the size of the buffer network which depend on the size
of the simulation network as well as the actual array dimensions within the
programs. If your network exceeds one of the limits this may be corrected most
easily by changing certain array dimensions within the program. See 15.28.
Problems may arise in coding a joint simulation/buffer network; further useful
information is contained in Section 15.11.
5.4 Capacity Restraint in the Buffer Network
5.4.1 Buffer Flow-Delay Curves

Capacity-restraint in the buffer network is handled by link-based flow-delay curves
whereby the travel time on a link is assumed to be a function of the flow on that
link (and that link alone). The analytical form of these flow-delay curves MUST
correspond to the “standard form” assumed for simulation turns in SATURN (see
Section 8.4.2); i.e., it must follow an equation of the form:
Equation 5.1
t=
AV n + t0 V ≤C (a)
t AC + t0 + B (V − C ) / C
= n
V ≥C
(b)
where
to is the free-flow travel time (in seconds),
C is the link capacity (in pcu/hr; see 15.17.1), and
B is a constant worked out by the program equal to one half the time
period being modelled.
(Numerically: B = 30*LTP where LTP is in minutes and B in seconds.)
(But see 15.38 for an option to allow the “power law” segment of the curve to
apply over the full range of link volumes.)
For turning movements A and n are calculated by the program (see 8.4.2); for the
buffer network n is defined for each individual link, either input directly on the link
record or indirectly via the default value of BCRP (Note 4, section 6.6). A and t o
are calculated from the free-flow and capacity travel times input by the user. In
fact t o exactly equals the free-flow travel time and A is chosen so that the curve
passes through the capacity travel time when flow equals capacity. (For a more
technical discussion of the “units” of A please see 8.4.2.1.)
Travel times and capacities are reasonably well-defined variables, but the role of
the power n may be less well understood. Its purpose is essentially to control the
rate at which congestion affects travel time. Thus if a large number is chosen, say
5, travel times remain near their free-flow limit until flow approaches capacity, at
5120257 / Apr 15 5-16

Section 5
which point they increase rapidly to the congested values. On the other hand with
a low value of n, say 1 or 2, the transition is much more gradual. In general terms
high values of n are appropriate to high-capacity links without junctions at the end
to limit capacity, e.g., motorways, while lower values are more appropriate to low-
capacity urban roads where the effects of congestion are mainly associated with
the junctions. It should also be stressed that the choice of n values can strongly
influence the assignment results and that some care should be exercised in
setting them.
While the above relationship is essentially a link-based curve there is no reason
why it should not reflect delays at intersections as well, in so far as that it is
possible using a power curve. Thus the travel times input should include the
times to traverse the junction at the end of each link in addition to the link travel
time. (They therefore differ in that respect from the link travel times defined for
simulation links.) In addition the shape of the curve above capacity is specifically
set to represent the queuing behaviour on an over-capacity link, assuming that the
queue builds up linearly over the time period (LTP) simulated.
Section 15.9 describes ways in which existing speed-flow curves may be
converted into the “best” values of n.
We note that the V<C component of the cost-flow curve, eq. (5.1a), may also be
written in a “parametric” form as:
t(V) = t o + (t c – t o ) (V/C)n (5.2)
where t c = t o + ACn is the travel time at capacity. This form is sometimes easier
for user manipulation since it uses only basic variables and removes the necessity
to calculate the value of the coefficient A.
5.4.2 Queues and Bottlenecks in Buffer Networks

Buffer networks differ from simulation networks in the manner in which they model
flows which are in excess of capacity. Thus in simulation networks, as described
in 5.1.11, flows downstream of “bottlenecks” are reduced to take account of the
maximum flow that can get through the bottleneck, while queues at bottlenecks
can equally “block back” to reduce capacities upstream. Neither effect is
represented adequately within buffer networks.
Thus, if a link in the buffer network has been assigned a “demand” flow V in
excess of its capacity C, then it is assumed that a permanent queue forms on that
link and increases its length at a rate V – C. The consequent delay to traffic is
represented by the last term in Equation 5.1(b). However, the flow downstream of
that bottleneck is not reduced and, if the next link downstream has the same
capacity C, then a second identical queue and delay will be modelled on that link
as well.
Hence, within buffer networks, there is a danger of V>C delays being “double-
counted” such that the total delays / travel times in the buffer network may be
significantly over-estimated. (Indeed this is a problem which all “conventional”
assignment models face and, generally speaking, fail to deal with adequately.)
Clearly the problem only manifests itself in assignment problems where there are
flows in excess of capacity so that, for relatively uncongested networks, a buffer
5120257 / Apr 15 5-17

Section 5
network level of detail may be perfectly adequate. However, for heavily congested
networks (or for heavily congested sections of network), the simulation approach
is recommended.
The problem of double-counting may be reduced, though not completely removed,
by the use of the “UNIQUE” parameter described in Section 15.48. UNIQUE was
first introduced in release 10.7.
5.5 Assignment and Map Networks

This section describes two levels of network representation within SATURN
which, although not directly coded or accessed by users, are central to many
operations within SATURN and a general appreciation of their structure may be
useful
5.5.1 The Assignment Network

For the purpose of assigning origin-destination trips the simulation and buffer
networks are amalgamated together into a single “assignment network” which, in
topological terms at least, is a simple network made up of nodes and directional
links connecting them. Assignment network nodes consist of:
♦ zones (whether simulation or buffer)
♦ buffer nodes
♦ one node at either end of each simulation link

The assignment links consist of:
♦ centroid connectors
♦ buffer links
♦ simulation links
♦ simulation turns
Thus within the simulation network each simulation node is “expanded” in order to
create a set of “mini links”, one per permitted turning movements, which connect
the assignment node at the end of the entry link to the assignment node at the
head of the exit link. See Figure 5.2 where 8 “mini-nodes” are created at a 4-arm
node with (up to) 12 “mini-links”. Only the 3 turning movements (assuming no U-
turns) from arm A are illustrated.
Banned simulation turns therefore do not appear within the assignment network.
Various arrays and/or procedures exist in order to map assignment nodes and
links with their counterparts in the simulation network and vice-versa.
5120257 / Apr 15 5-18

Section 5
Figure 5.3 – A 4 arm node N and its expanded assignment network representation
By contrast in the buffer network there is a one-to-one correspondence between

buffer nodes and links and assignment nodes and links. In fact the buffer network
only exists as part of the assignment network whereas the simulation network has
“dual nationality”.
External simulation nodes are treated as a sort of halfway house between internal
simulation nodes and buffer nodes where a limited expansion takes place as
illustrated in Figure 18.2(B), Section 18.9
Listings based on assignment links occur at various points within SATURN, e.g. in
the SATDB outputs or the SATNET .lpn files. See 11.10.4 for an explanation as
to how they may be interpreted.
5.5.2 The Map Network

A further network description is created in order to deal, primarily but not
exclusively, with graphical displays in PIX. Like the assignment network the map
network is a simple topological network consisting of nodes connected by links.
Map nodes consist of:
♦ Zones
♦ Buffer nodes
♦ Simulation nodes (i.e. the junctions themselves, not expanded forms)
5120257 / Apr 15 5-19

Section 5
while each map link joins two map nodes. They therefore correspond to the
“lines” plotted on a PIX network and represent roads and centroid connectors
directly.
For technical reasons all map links are two-way whether or not the road they
represent is one-way or not. Various matching arrays are also included within the
map definitions in order to provide the correspondence between map links and
assignment links and vice versa. Map links may therefore be matched to
simulation links via the assignment network.
Note that simulation turns are not directly included within the map network
although clearly if, say, a route is traced in the map network from nodes A to B to
C then it is possible to identify the simulation turn A-B-C.
SATURN map networks may be “dumped” into text files consisting of node and
link data for potential transfer into other model systems; see 11.4.2.2 and
11.4.2.3.
5.5.3 Fixed Flows

Although the main function of SATURN is to assign trips from a trip matrix to O-D
paths in order to obtain (assignment network) link flows there are other
components of link flows which are effectively “fixed” independent of network or
trip matrix conditions. Fixed flows may arise from (and are the sum of) any or all of
the following
♦ Pre-loaded flows (15.5);
♦ Bus flows (6.9.1);
♦ PASSQ flows (17.3.1)

In general an assignment starts with the link flows as given by the fixed flows (if
any) and, if none, from zero flow. Note that it is sometimes necessary to carefully
distinguish between fixed and assigned flows, for example, when defining target
link flows to be matched by assigned link flows from a trip matrix under SATME2
(see 13.1.4) which should, by definition, exclude any fixed flows.
Since the fixed flows as seen by the assignment are simply the sum (in terms of
pcus/hr) of all the above three contributions it may be possible/convenient to
define bus flows as pre-loaded flows or vice-versa (15.5.5). 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. However, as noted below, bus flows may have certain properties that
distinguish them from other flows, e.g., bus lanes.
Note as well that bus flows may be further sub-divided into buses that use the
same lanes as “normal” traffic and buses that are assigned to bus-only lanes. The
latter flows are, in effect, totally distinct from “normal” link flows and there is no
interaction between the two. For example, buses on bus-only links do not make
any call on the modelled link capacities nor do they affect link travel times,
whereas other bus flows (and, indeed, all other fixed flows) do. See 15.39 for
further details.
5120257 / Apr 15 5-20

Section 5
5.5.4 Network and/or Trip Matrix Connectivity

In general one would expect that in any “real” road network it should be possible
to travel from any one node to any other node in the network; if this is not possible
then it is more likely to be an error in the network coding rather than a genuine
property of the network. (N.B. There are certain exceptions to this rule: e.g.,
“origin-only” or “destination-only”l zones which are connected by one-way links to
the network proper and which, by definition, are not accessible to/from all other
parts of the network or banned turns designed to prohibit entry to certain sections
of the network.)
SATURN therefore contains various checks for a lack of connectivity in input
networks and trip matrices. These exist at two levels: (a) checks on the network
topology and (b) checks on the trip matrix.
Under (a), SATNET performs two separate but similar sets of checks based on:
(1) the “map network” (see 5.5.2 above) in which all one-way links and banned
turns are ignored and (2) on the assignment network in which they are included. In
both cases a “tree” is constructed from zone 1 in order to determine whether there
are any points in the network which cannot be reached. If there are any under (1)
then a non-fatal error 278 is generated which, if WRIGHT = T, is upgraded to a
semi-fatal error. Under (2) any examples generate a warning message 47 only
since a lack of connectivity may simply be due to one-way streets and/or banned
turns although they may sometimes be symptomatic of more serious coding
problems.
Under (b) SATNET attempts to build a path from origin to destination for every
non-zero cell in the trip matrix over all user classes in order to detect any positive
cells for which no permitted path exists. Any such occurrences generates non-
fatal error 277 which, if WRIGHT = T, is upgraded to a semi-fatal error. In this test
one-way links and banned turns are taken into account. If the trip matrix has not
been defined within SATNET then the same test is repeated within the first
assignment carried out within SATALL.
5.6 Building Networks: The Beginner's Guide
5.6.1 Getting Started

By now it should at least be clear that there are two essentials for running
SATURN, a network and a trip matrix. There are many variations on each of
these, of course, but at their simplest both network and matrix will be for a single
class of vehicle. So how should you go about setting these up? Here we try to
answer this question.
The network and matrix together represent a scenario, which may be a Base case
or a “What if” type of test where either or both of the network and matrix are
assumed to change from the Base. In starting a new project and defining
appropriate networks and matrices, you can work either from existing versions of
each (if available), or from scratch. With the latest versions of SATURN, the
procedures to follow in each case are designed to be similar, with a strong
emphasis on interactive and graphical editing, particularly of networks. Our
approach is described below
5120257 / Apr 15 5-21

Section 5
5.6.1.1 Network Building and Editing

In early versions of SATURN, network building was simply a case of settling down
with a network plan and coding, in strict ASCII style using a text editor, a series of
nodes and links which described the structure and detail of the network. The
format for such a coding procedure is described in full in Section 6 of this manual.
Happily, there is now an easier alternative using P1X, which allows the user to
input network detail through a graphical editor on the screen and to see the
network develop progressively. Although a single philosophy underlies the
procedures for both creating networks from scratch and for editing existing
networks, it will be helpful to start by describing the first of these on its own.
5.6.1.2 Starting from Scratch

To start the network editor without a prior network, type:
PMAKE newnet
Where newnet.DAT will become your new network file on exit from PMAKE. (Just
to confuse you, PMAKE will actually take you into P1X but PMAKE is used to
differentiate the commands between building from scratch and modifying existing
networks - see also later.)
You will be asked to define maximum and minimum screen co-ordinates and
whether you wish to import a bitmap as a back-screen to network building, or just
proceed with a blank screen. Continue takes you to the network building screen.
Here you can set both &Option and &Param parameter values (Section 6.3) which
will control the operation of the model and subsequent runs. More importantly, you
can start to build your network.
The philosophy adopted in SATURN network building is for the structure to be
defined initially at Buffer level, where nodes exist only as places at which links
join, with detail for nodes added subsequently by converting them from Buffer to
Simulation. Both activities are accomplished using PMAKE/P1X, but we must as a
first step define the structure of the network purely in terms of node positions and
their connectivity.
Click on Node Edits in the banner. The choice will be to define Nodes or (Buffer)
Zones. Choosing nodes allows you to position nodes with a single click. Active
options are shown in capitals in the banner, and you may switch between user
defined node names and the Auto-definition of names as required. A further option
allows links to be defined automatically between successive nodes, but see also
link definition options below.
Clicking on the Zone option in the banner allows the placement of zones in an
identical fashion. If you now continue, you will find that further options are now
open to you, including the ability to delete, re-number and re-position nodes and
zones. You will also be able to add further areas of network in future sessions
using these tools.
5.6.1.3 Defining Links

Return to the Master Menu and select Link Edits. Links are defined by clicking on
successive pairs of nodes until the network is complete. Further options exist to
5120257 / Apr 15 5-22

Section 5
delete and change link directions. Splitting links is possible from both link and
node sub-menus.
5.6.2 Editing Existing Networks

Once a network structure has been defined as above, you are in the same
position as if you had entered P1X with an existing network and Continue takes
you to the usual Master Menu of P1X. The options include those to change files,
devices, window and displays, as well as SATLOOK and SATDB choices.
Here we are concerned foremost with the EDIT Banner option. Click on this and
the options shown below are revealed.
5120257 / Apr 15 5-23

Section 5
Two options, in particular, are of interest. The first, conVert buffer, allows any of
the already defined nodes to be converted into simulation and applies equally to
networks just constructed in PMAKE as it does to imported networks. The second
allows structural changes to be made using the node and link definition and edit
options described above as part of PMAKE. The operations available under each
option are described below.
5.6.3 Converting Nodes

Selecting the Convert Buffer Nodes option leads you to a menu which asks you to
choose a buffer or external simulation node. You do this by clicking on the node
on the screen. Your node will be displayed, ready for editing.
External nodes mark the boundary of the simulation network, and as such are a
special type of simulation node. Where externals are connected to both simulation
and buffer nodes, they can be converted to buffer as the simulation area is
extended. Note that in such a case, the adjacent buffer nodes will themselves be
required to become external nodes, a process which can be automated through
setting namelist AUTOX =T.
Once selected, you are asked to choose the type of node you want. The example
below follows the creation of a signalised junction, the first screen involving the
choice of a stage time for the movements to be defined next. In this example, a
30 second first stage is defined. An inter-green time will also be requested.
Allowed movements within each stage are defined by moving the mouse over the
relevant turning movement in the right-hand banner, the movement being shown
on the junction display as a bold red arrow. Clicking the mouse will place the
highlighted movement in the stage box at top left. Other movements are added
5120257 / Apr 15 5-24

Section 5
until the stage is defined, whereupon following stages can be defined. If a mistake
is made, stages can be edited once input is complete.
Once all stages have been defined, continue and you will be faced by the node-
editing menu in the banner. Here, you can select to edit node variables, such as
minimum gaps and modelling steps, link values, such as distance or number of
lanes, or turn details, such as lane allocations, priority markers and saturation
flows. Where links or turns are involved, the active one is always shown
highlighted on the junction plan in centre-screen, as shown below.
When complete, Quit and Save the node data (remembering also to Save the
node to an internal data file) and continue to the next. Note that by clicking on
Print you can view the node coding at any time.
5120257 / Apr 15 5-25

Section 5
5.6.4 Structural Changes in PMAKE

The edit functions in PMAKE are designed to allow structural changes to be made
to a network. Once selected, the network edit options allow the user to edit Nodes,
Links and (simulation) Centroid Connectors. Further choices include the
modification of Namelist control Parameters.
Under Node Edit, the user can choose to Add or Delete Nodes, Split Links (ie.
Add a new node between two existing nodes), Renumber and move nodes.
Within the Link Edit facility, users can Add and Delete Links, change properties
(both Buffer and Simulation) and split links. Where new links are created into
junctions (changing, for instance, the number of arms at a junction), the user is
prompted to review the junction coding and input the necessary changes to
ensure its correct functioning, from turn allocation to lanes to signal phases and
timings.
Centroid connectors may also be changed interactively, with the options to add,
delete or modify all available
5.6.5 Completing the Edit Session

At the end of your editing session, continue to exit the node edit section and, in
the banner, save the file as a .dat ready for use in SATNET. You are also allowed
to save as a UFS file at this stage, but we strongly recommend that the additional
safety checks built into SATNET be used before progressing to assignment. From
a command line prompt, type:
SATNET netname
where netname.dat is the name of the saved network data file. The most likely
thing to go wrong at this stage is that, with new simulation nodes created, you will
have connections straight from buffer nodes to simulation nodes without
intervening Externals. The easy way round this, as described earlier, is to set
AUTOX = T in the PARAM namelist section at the head of the netname.dat file.
Once a successful network build has been achieved, you are ready to assign your
trip matrix, although creating the trip matrix may be a bit more complicated than
simply drawing on the screen.
5.7 Geographical Information System (GIS) Data
5.7.1 General principles
GIS files (where GIS stands for Geographical Information Systems *) are
supplementary files which contain essentially “background” data to be included,
for example, in network plots. Thus GIS files describe both “topological” data
such as political boundaries, geographical features such as rivers, railway lines,
* GIS files in SATURN should not be confused with “proper” GIS files as in MAP - INFO or ARC-
INFO. In fact a more accurate, if less impressive, acronym would be something like BIF for
Background Information File.
5120257 / Apr 15 5-26

Section 5
stations, etc. and “text” data such as names to be associated with nodes or links.
Their use enables plots to more closely resemble actual maps rather than
idealised representations of road networks - and hence more acceptable for
presentations.
The precise definition and specification of what GIS files contain is still somewhat
fluid but certain broad principles have been established. Thus:
♦ GIS files refer to areas, not to specific networks. You do not need to create a
new GIS file each time you add a new link to your network or change from a
“do nothing” to a “do something”.
♦ The data in GIS files is applicable to matrices as well as to networks, e.g., the
alpha-numeric zone names.
♦ GIS files are “text” or “ascii” files as opposed to “binary” files. It follows that
data can also be “translated” from other data sources by essentially “re-
formatting” without going through a SATURN program.
♦ Data has a “hierarchical” structure which controls the order in which the data
is displayed in P1X plots. Hence text is displayed AFTER in-filled areas so
that the name of a zone will over-print the coloured area.
Although primarily intended to be used by P1X the data within a GIS file is also
relevant to a number of other programs; thus SATLOOK, SATED, SATDB and
MX can all access GIS files.
More precisely the following sets of data can be included within a GIS file (such
that (a) is at the bottom of the hierarchy and is plotted first);
a) Closed “polygons” which enclose an area; e.g. a zone
b) Sets of contiguous straight lines - “polylines” - used to represent rivers or
railways, etc;
c) “Ikons”, i.e. standard symbols such as the BR symbol to represent a
railway station;
d) Text;
e) Alphanumeric link, node, zone and sector “names”;
f) Polyline data to display links as “curves” or as “arcs” of a circle rather than
straight line segments (see 5.7.3);
Node co-ordinates (which are also stored on network files but are included on GIS
files partly for convenience and partly so as to be accessible for matrix
applications).
Data sets (a) to (d) have certain “characteristics” associated with them. Thus they
have a choice of colour, areas can be in-filled or not, lines can have a width
(defined either in mm on the screen or in metres “on the ground” which is
translated into an equivalent width “on the screen” when displayed), and ikons and
text can have a size and colours. And of course all of them have spatial
coordinates. All of these are set by the user on the GIS file.
5120257 / Apr 15 5-27

Section 5
GIS files are “formatted” - thus fixed columns are used to define each
characteristic; the current conventions are specified in Appendix Z.
The filename of the GIS file to be associated with a network may be defined within
the network or matrix .dat file using the Namelist parameter FILGIS and that name
is then carried forward on the UF* files. Thus those programs which require data
from the GIS file can open the file automatically. Alternatively interactive
programs allow a GIS file to be defined from the Files Menu.
Within P1X the GIS data to be included in the plot may be selectively requested
(11.6.10); e.g., you can have the polygons but not the polylines, but you then get
all the polygons.
5.7.2 Creating/Editing GIS Files

A GIS file, being an ascii data file, can be created either from scratch using an
editor or by re-formatting other data sources, e.g., geo-coded zonal boundaries.
Starting from scratch and following the formatting conventions given in Appendix Z
is NOT recommended - hard work! Re-formatting existing data sources is
sometimes a very good idea, particularly when a lot of very precise data is
required, as with zonal boundaries. It should, for example, be relatively simple to
extract data from “proper” gis systems such as mapinfo, etc. and to reformat as
required by SATURN GIS files.
However a mouse-based option to create or edit (augment) a GIS file is provided
within the edit functions of PIX (11.9). This is particularly recommended for
operations such as adding alpha-numeric names for either nodes or zones -point
to the node and type in a name; precise co-ordinates are not needed.
A typical GIS display used with network annotation (a forest of routes from origin
zone to destination zone) in P1X is shown below.
5120257 / Apr 15 5-28

Section 5
5.7.3 Curvature Poly-lines, Arcs and Circles

“Curvature” refers to any method by which a link from A to B is not represented by
a straight line but by a curved line. There are two basic methods by which this
may be done:
a) The link is defined as a “poly-line” of 1 or (generally) more intermediate
points between A and B; or
b) As the “arc” of a circle such that both A and B lie on the circle
Under (b) it is only necessary to define the co-ordinates of the centre of the circle,
the program then, in effect, creates a poly-line which follows the arc from A to B.
(Geometrically the centre of the circle must lie on the “right bisector” of the line A-
B, i.e., the line which runs at right angle to A-B and passes through their mid point.
This ensures that both A and B lie on the circle. If the centre is a long way from A-
B then the arc will be relatively flat; if the centre is near the mid-point of A-B the
curvature will be very pronounced.)
A variation on (b) is that of a “full circle” where all links in a closed loop are
individually defined as arcs with the same centre of curvature so that the closed
loop is plotted as a circle. The most obvious application of this is when a
roundabout has been broken down into a series of sub-nodes (e.g., essential for a
large and/or signalised roundabouts) and it is desired to plot each sub-link as part
of a circular roundabout.
The two sample plots below demonstrate an expanded roundabout with the four
sub-links on the roundabout plotted as straight lines (bottom) and with the links as
part of a GIS circle (top). Link flows are being annotated as bandwidths. Note that
the plot could be further improved by introducing curvature to some of the other
links, e.g., the entry links onto the roundabout.
5120257 / Apr 15 5-29

Section 5
When curved links are created interactively within P1X three options are provided:
poly-lines, (single) arcs and circles.
5120257 / Apr 15 5-30

Section 5
5.8 User and Vehicle Classes
5.8.1 User Classes

Multiple user classes (MUC) are used within the assignment to refer to trips which
differ with respect to either
♦ vehicle type;
♦ their criteria for route choice;
♦ network restrictions;
♦ demand characteristics (e.g. elasticities)

For example, lorries and cars would constitute different classes as would
cars/drivers seeking minimum time routes and minimum distance routes. Equally
cars and taxis would be different classes if there were taxi-only links. MUC
assignment is therefore the problem of assigning a number of different user
classes to the same road network.
Restrictions in this context may include class-specific bans but also class-specific
time penalties or monetary tolls so that one may use user classes to distinguish
various groups of drivers paying different parking charges, for example.
♦ Similar problems may also arise within the demand (elastic) models
interfaced with SATURN assignments where (7.9) we may wish to distinguish
between two or more groups of trip makers who respond differently to costs in
terms of whether to travel by road or not but who may be identical in terms of
route choice.
♦ The number of user classes is set by the parameter NOMADS with the default
value of 1 for a single user class and an upper limit of 32. Their rules for
route choice are specified within the network specifications, e.g. sections 6.7
(link restrictions) and 6.11 (generalised costs).
Note that user classes, although normally referred to by their sequential numbers
1, 2, 3… NOMADS, may also have short (up to 40 character) text names
associated with them via the namelist parameters UCNAME ( ) input to SATNET
(6.3.4). These are used in, e.g., output LP files.
User class specific link flows may be displayed, e,g., within P1X, by using the
normal menus. They may also be obtained by using a “trick” involving DA codes
such as 3808; see Section 15.21.4.
5.8.2 Vehicle Classes

The concept of a “vehicle class” was first introduced into SATURN 9.5 but, at the
time of writing, is still relatively little used.
Vehicle classes are defined purely with respect to the physical characteristics of
the vehicle and are unrelated to the driver characteristics. Examples would be
petrol cars, diesel cars, heavy lorries (HGVs), single-decker buses etc. Cars
driven by, e.g. time minimisers and distance minimisers would be the same
vehicle class although different user classes.
5120257 / Apr 15 5-31

Section 5
Vehicle classes may be defined for each user class (within the 88888 network
data records; see 6.11) or bus company (see IBUSVC, 6.9.3) and multiple user
classes may be assigned to the same vehicle class. For example, if a user has
defined 5 user classes – say, cars (resident), cars (non-resident), taxis, LGVs and
HGVs then it might be natural to define 3 vehicle classes where class 1 would
include both car user classes plus taxis, class 2 would include (and be
synonymous with) LGVs and class 3 would be HGVs. Buses could be included
with either of the 3 vehicle classes above or assigned their own vehicle class
(e.g., class 4)
The number of vehicle classes used is not defined by an input parameter - as are
user classes by NOMAD - but is determined by the highest value used (up to a
maximum of 32). Like user classes they may be given text names - VCNAME( ) in
6.3.4 - of up to 40 characters to be used within outputs.
The long-term intention is that different vehicle classes will have different emission
and fuel consumption characteristics and some development work on the former
is now included in SATURN; see 15.33. Equally they may be used in the
calculation of tolls - see 20.4.1 – and in the updating of matrices within SATME2 –
see 13.4.6.
Note that it is not possible to have more than one vehicle classes per user class.
For example, if all car drivers are assumed to be identical in terms of their
generalised cost but drive a mix of vehicles then, in terms of assignment, it is most
efficient to define them as a single user class. On the other hand, in order to
model the different emission characteristics of different vehicles, it would be useful
to be able to split them into different vehicle classes. However, disaggregation into
vehicle classes may be only done by disaggregating the user classes as well -
which is not particularly efficient in terms of assignments. A compromise solution
would be to define car drivers as a single vehicle class but to define their emission
and fuel consumption coefficients by an appropriate weighted average.
Vehicle classes (and hence, indirectly, user classes) may also be assigned PCU
factors VCPCU (see 6.3.3 and 15.17.2), i.e., the values of pcu’s per vehicle which
are used as required to convert flows in pcu’s per hour into vehicles per hours.
[Recall that all trip matrices and therefore link flows in SATURN are defined in
units of pcu’s or pcu/hr so that VCPCU is used to convert them to vehicles when
required] VCPCU values are used, for example, in the calculation of total toll
revenues from pcu flows since, one assumes, tolls are levied per vehicle rather
than per pcu; see 20.4.1.
We note that the same PCU factors should also have been used if trip matrices
originally obtained in units of vehicles per hour had been factored into matrices of
PCUs per hour; see 4.3
5120257 / Apr 15 5-32

Section 5
5.9 Version Control
JOB NUMBER: 5120257 DOCUMENT REF : Section 5.doc
5120257 / Apr 15 5-33

Section 5
Preparation of a Network Data File
6. Preparation of a Network Data File

INTRODUCTION
We describe here the complete network data structure for SATURN. Although
networks may be coded following the conventions below, we would expect most
new networks to be coded interactively using P1X/PMAKE (see 5.6). Under these
options, the formats described become essentially invisible to the user since the
correctly formatted files are produced automatically.
The network data file input to SATNET (network.DAT in Fig. 3.1) may be
conveniently divided into 11 segments, the first 3 of which are mandatory while
the last 8 are optional (although clearly in order for a network to be defined either
the simulation or the buffer records must exist):
1) OPTION SPECIFICATION RECORDS
2) NETWORK TITLE
3) PARAMETER SPECIFICATION RECORDS
4) THE SIMULATION NETWORK
5) THE SIMULATION CENTROID CONNECTORS
6) BUFFER NETWORK/LINK DATA
7) RESTRICTED TURNS AND LINKS
8) NODE AND/OR ZONE CO-ORDINATES
9) FIXED ROUTES (E.G. BUSES)
10) COUNTS OF LINK AND/OR TURNING VOLUMES
11) GENERALIZED COSTS (Multiple User Classes)
In each case their presence is indicated by a code number given in column 1 of
the record preceding the first data record. Thus the simulation network records
are preceded by a 1, the centroid connectors by a 2, etc. Moreover each segment
of data input included is terminated by a record with one or more 9’s commencing
in column 1 (and traditionally written as ‘99999’ in columns 1 to 5 although ‘9 ’
has the same effect), and the complete data file must be terminated by a record
with a 9 in column 1. Further details are given under the appropriate sub-sections
below.
(N.B. For purely “aesthetic” reasons the single number, say 1, is normally written
as ‘11111’ so as to take the same number of columns as the ‘99999’ terminators.
Hence we refer to, e.g., the ‘33333 records’.)
With two exceptions each data segment appears only once and in numerical
order. The exceptions are segment 6, bus routes, and segment 7, link counts,
which may appear more than once (but with the obvious proviso that all such
segments appear together and in the correct order).
5120257 / Apr 15 6-1

Section 6
Segments 6 and 7 also differ from all others in that a “title” may be included
following the opening 66666 or 77777 text; see 6.9.3 and note (3), 6.10.
Sub-Sections 6.1 to 6.11 give the format specifications for each of the 11 possible
data segments, followed by an example of a network file in 6.14.
Note that in certain instances the required format differs if the “DUTCH” option,
which allows buffer node numbers of up to 8 digits, is invoked. Places where the
alternative format is applicable are indicated below but the specification of the
DUTCH alternatives is given fully in Section 15.20.
In common with other input data files any record commencing with a * in column 1
is treated as a comment card; see Section 15-29. In addition all data segments
(apart from 2) may all refer to secondary files using the ‘$INCLUDE’ facility
described in Section 15.30.
FIXED COLUMN CONVENTIONS

Note that most of the data segments follow “fixed column conventions” as
described in section 2.8.1 but that greater flexibility as regards the number of
decimal points and/or range of values for the input of “real” variables is available;
see 2.8.3.
SUPPLEMENTARY INPUT FILES

In addition to the “main” network data file it is possible (version 9.4) to input
certain supplementary network data in an extra data file referred to as the X-file
and defined by the parameter XFILE under Namelist PARAM; see 6.3.4. For
example link capacity indices or link-specific parameters such as TAX may be
defined in this way. The data which may be added in this way is described in
Section 6.13.
Alternatively extra data may be input from a “KNOBS file” which an external text
file providing various forms of link-based data, e.g., tolls. See Sections 6.6,15.14
and 20.3.
A slightly different form of supplementary data file is the GIS file (see 5.7) which
may be also referenced under &PARAM, 6.3.4, and which is used to provide extra
network information for output and display purposes.
In addition the trip matrix file to be used in later stages may also be defined within
the input .dat file (6.3.4). Although not used directly by SATNET if present it is
read in and checked at this stage for any obvious incompatibilities with the
network file being created (e.g. different numbers of zones).
6.1 Option Specification Records (Mandatory)
This record * (or records) requests the major options available within SATNET.
The specification of options is via the FORTRAN namelist facility. The user
unfamiliar with this is referred to Appendix A. Essentially namelist provides a form
of free format input for defining values of variables within the program.
* Each "line" of the input file is referred to as a "record".
5120257 / Apr 15 6-2

Section 6
Parameters not explicitly mentioned take a default value. Namelist input runs to
as many records as necessary but it must always be preceded by (in this case)
&OPTION and terminated by &END.
Note that repeated variables (i.e., the same name is defined more than once)
generate semi-fatal errors since it is not clear which of the two (or more)
definitions is the correct one.
The following parameters may be defined by &OPTION; the first eight of which are
all LOGICAL and default to .FALSE., the last set are all character variables
(mostly file names) which default to “blank”:
UPDATE .TRUE. if a new network is being built which is very similar to a previous
network, in which case the previous network will be used to provide good
initial estimate of flow-delay parameters. N.B. If you wish to set WSTART
= T then UPDATE should also be set to T. See Sections 15.3 and 22.3.
PASSQ .TRUE. if queues are to be passed over from a previous time period. See
Section 17.3.
PLOD If .TRUE. the assigned flows from an input SATURN UF file are “Pre-
LOaDed” as fixed flows onto this network. See Section 15.5.
PLODFF If .TRUE. the pre-load data file uses free or CSV formats. See Section
15.5.4.
PLFF3 If .TRUE. 3 fields (A, B and C with C = 0) are required to define a link as
opposed to a turn for a free format pre-load data file. See Section 15.5.4.
WSTART If .TRUE. the assignment uses a “Warm Start” on its first assignment. N.B.
If WSTART = T then UPDATE should also = T. See Sections 21.3 and
22.3.
DIADEM If .TRUE. and the file named under UPFILE does not exist then setting
either UPDATE or WSTART to T does not result in a semi-fatal error. See
15.51.
CASINI If .TRUE. the internal CASSINI steps to over-ride various settings within
SATNET are invoked. See 15.54 and 15.54.6.1 for a full list of the
Namelist variables which may be over-written. (N.B. the variable name
CASINI has only a single S in order to confirm with the rule that all
namelist variables have to have 6 or fewer characters.)
UPFILE The name of the network (.ufs) file which is to be used under the UPDATE
and/or WSTART options. See 15.3 and 21.3.
PQFILE The name of the network (.ufs) file which is to be used under the PASSQ
option. See 17.3.
FILPLD The name of the network (.ufs) file which is to be “pre-loaded”. See 15.5
FILERL The name of the input .ERL file used to monitor errors. See 15.58.
FILCAS The name of the CASSINI Control file defining the convergence strategy
to be applied. See 15.54.6.
FILGAP The name of the ASCII CSV file reporting the convergence of the demand
model. See 15.54.6
CASTXT The CASSINI file which specifies the type of demand model used and the
5120257 / Apr 15 6-3

Section 6
file format (and other operations) that CASSINI will expect. See 15.54.6.
Thus the OPTION records might be specified by the following set of records which
explicitly sets UPDATE to .TRUE., PASSQ to .FALSE. and, by default, PLOD to
.FALSE.:
&OPTION
UPDATE=T,
PASSQ=F,
UPFILE = ‘LASTNET.UFS’
&END
For users preparing a new network file the default values set for all of these
parameters are those required and therefore we need not be concerned with them
at this stage. Thus you need only include a ‘null’ namelist record:
&OPTION
&END
Note that both UPDATE and PASSQ allow initial estimates of the cost-flow curves
to be extracted from a previous run; see 15.3. However if both are set to T the
data is taken from UPFILE in preference to PQFILE. UPFILE and PQFILE are
totally separate files, either/both needs to be defined as required by
UPDATE/PASSQ and they cannot both be the same file.
6.2 Network Title (Mandatory)

This record contains a network title of up to 80 characters which is reproduced on
all output from the model. This enables the user to distinguish between various
runs.
Additional lines of text may be inserted between the record containing the network
title proper and the start of the &PARAM records. Those lines make up a “history
file” which is saved as part of the .ufs file and may be printed at later stages (see
11.8.4.10). It is a useful device for adding comments when a .dat file is updated,
etc.
6.3 Parameter Specification Records (Mandatory)

These records set user-defined model parameters for this run using the
FORTRAN namelist facility as described above for the OPTION records, the one
difference being that the namelist ‘name’ is &PARAM instead of &OPTION. See
Appendix A.
Some of the parameters defined here are used in the network build stage, others
are relevant to the (later) simulation or assignment stages; the latter are set here
and passed to the relevant programs via the SATURN UFS/A files (where they
may be re-set). In certain cases therefore full documentation is deferred to later
sections with appropriate pointers being given here.
Note that repeated variables (i.e., the same name is defined more than once)
generate semi-fatal errors since it is not clear which of the two (or more)
definitions is the correct one.
5120257 / Apr 15 6-4

Section 6
The parameters are grouped under LOGICAL, INTEGER, REAL and

CHARACTER variables and listed in alphabetical order.
The default values set are generally “good” choices. However in certain
instances, e.g., where a variable has been introduced at a late stage of SATURN
development and the “best” value would change the output from existing .dat files,
a “no change” default has been set. These are indicated by an alternative
“RECOMMENDED” value in addition to the default.
As discussed in Appendices A and B variable names may be “subscripted”, e.g.
GONZO(2) instead of just GONZO. Generally the subscript refers to the time
period for which this variable definition holds. However in certain limited cases, a
subscript may be used to refer, to, e.g., a particular user class. The latter
variables (SUET, BETA, POWER, MCUBC and MCGILL) are indicated by a (u) in
the following lists. Other variables, such as BUSPCU, () refer to “bus company”
and are denoted by a (b); see 6.9.3.
Alternative spellings are sometimes accepted, e.g. TIJFIL can be used instead of
FILTIJ, basically since both seem equally logical to me. But there aren’t very
many so if you want to be certain to set a parameter correctly you need to be
careful with its spelling. On the other hand parameter names are case insensitive
- any lower case characters are translated into upper case.
The lists are long, many of the variables and their use are complicated and the net
effect on new users is definitely off-putting. For such mere mortals the following
subset of variables is suggested as reasonable starting points where explicit
choices need to be made; otherwise trust the defaults:
LOGICAL: LEFTDR
INTEGER: LCY, LTP, MASL, NITA, LRTP
REAL: GAP, GAPM, GAPR, PPK, PPM
CHARACTER: FILTIJ
6.3.1 Logical Parameters

AMY If .TRUE. all assignments are carried out with “fixed” travel times
corresponding to free flow travel with no speed changes. See Section
7.11.4.
Default: .FALSE.
ASHORT If .TRUE. assignment statistics by iterations are given in a table in the
output line printer files rather than (at length) per iteration.
Default: .TRUE.
ATLAS If .TRUE. all nodes in the 55555 data section are included in the map
network whether or not they are connected to links. See 18.5.2 and note
(9), 6-8.
Default: .FALSE.
AUTNUC If .TRUE. values of NUC are set automatically for certain junctions. See
15.15.2
5120257 / Apr 15 6-5

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

AUTOK If .TRUE. any “Kombi” averaging of flows during the assignment–
simulation loops is controlled AUTOmatically. See Section 9.3.1.
AUTONA If .TRUE. “optimum” values of NITA and/or UNCRTS are calculated at
each separate assignment within SATALL. See Section 9.5.4.
AUTOX If .TRUE. any uncoded external simulation nodes are automatically
coded using the best available data. See Section 15.12.
Default: .TRUE.
AUTOZ If .TRUE. zones are automatically generated at each external simulation
node with the same number as the external node. See Section 15.12.
Default: .FALSE.
BANKER If .TRUE. an ascii (text) file containing a full set of banned turns is output
to a file network.BNT.
Default: .FALSE.
BB109 If .TRUE. the new rules for blocking back as introduced in release 10.9
(see 8.5.5 and 8.5.6) are invoked
Default: .TRUE. (was .FALSE. but recommended .TRUE. prior to 11.2)
BEAKER If .TRUE. any capacity index set for a simulation link (via data input
under the 33333 records below) is automatically associated with all turns
out of that link.
Default: .TRUE. (Changed in 10.5)
BUSKER If .TRUE. a file containing full bus route data is output to a file
network.BUS so that, e.g., interpolated routes are given with every node
included. See 6.9.2.
Default: .FALSE.
BYGRUP If .TRUE. disaggregate summary statistics are calculated in SATALL
using traffic boroughs or “groups” (e.g., under TFL or FILN2G) rather
than capacity indices. See 11.11.4 and 15.59.2.
Default: .FALSE.
BYCAPI If .TRUE. disaggregate summary statistics are calculated in SATALL
based on link capacity indices (if any) but only if BYGRUP = F (which
takes precedence). See 11.11.4 and 15.59.2.
Default: .FALSE.
CLIMAX(n) If .TRUE. for user class n any input values of CLICKS represent a fixed
maximum speed rather than a fixed time penalty. See 15.47.3
Default: .FALSE.
5120257 / Apr 15 6-6

Section 6
COMPAS If .TRUE. links from a common buffer node are sorted so that they
appear in the listings in clockwise order (counter–clockwise if
LEFTDR=F).
Default: .FALSE.
CROWCC If .TRUE. buffer centroid connectors with an input distance of zero are
replaced by a crow-fly distance. See 15.10.3.
Default: .FALSE.
DCSV If .TRUE. default speed-flow curves under 33333 (i.e., those with a D in
column 1; see 6.6 and 15.9.5) may be defined as free format (CSV)
rather than fixed columns.
Default: .FALSE.
DIDDLE If .TRUE. each assignment after the first commences with the final set of
flows from the previous assignment; if .FALSE. it starts with an all-or-
nothing load. See 9.4.
Default: .TRUE.
DOUBLE If .TRUE. and TOPUP = T certain rules for “over-writing” data apply. See
6.15.3.
Default: .TRUE.
DUTCH If .TRUE. node numbers in the buffer network may have up to 8 digits,
otherwise they are limited to 5. (N.B. If .TRUE. certain input formats
throughout the Suite are altered – see Section 15.20.)
Default: .FALSE.
ERRYES(I) Controls the listing of error messages: if ERRYES(I)=T then message I
will be printed; if F it will be suppressed. Range of I from 1 to 499. By
convention ERRYES(I:J) = T sets all values in the range I to J to T. See
Sections 2.9 and 6.12.2.
Default: .TRUE.
ERRNO(I) If ERRNO(I) = T then Warning/Serious Warning/Non-fatal Error I is
upgraded to a Semi-Fatal error. See 6.12.3.
Default: .FALSE.
ERTM (For Eastern Region Traffic Model). If .TRUE. then negative elements in
the trip matrix are assigned (Definitely NOT recommended for normal
use!) See Note 6, Section 4.3.
Default: .FALSE.
EXPERT If .TRUE. the level of print out generally is such that only an “expert”
would fully appreciate it.
Default: .FALSE.
EZBUS (Pronounced EASY-BUS!) If .TRUE. the bus route data on the 66666
data records (see 6.9.2) are in “free format”; if .FALSE. they are in fixed
column format.
Default: .FALSE.
5120257 / Apr 15 6-7

Section 6
FIFO If .TRUE., if and when a data item appears twice, the first data entry is
discarded and the last one used; if .FALSE. the first entry is always
used. See 6.15.
Default: .TRUE.
FOZZY If .TRUE. the program will try to “interpolate” unconnected nodes in bus
routes. See Sections 6.9.2 and 15.18
Default: .FALSE. (RECOMMENDED .TRUE.)
FREDDY If .TRUE. an output .rgs file containing a listing of all signal settings is
created. See 6.4.3.5 and 11.9.14.
Default: .FALSE.
FREEKY If .TRUE. then the extra KNOBS data records in the 33333 records are
input as “free format”; see 6.6.
Default: .FALSE.
FREEXY If .TRUE. then the supplementary node data in the 55555 records (i.e. X,
Y co-ordinates) are input as “free format”; see 6.8.
Default: .FALSE. (but recommended TRUE)
FREE77 If .TRUE. counts under 77777 are read as free format. See note 13),
6.10.
Default: .FALSE.
FREE88 If .TRUE. PPM etc. weights per user class under 88888 are read in a
free format as opposed to fixed columns. See 6.11.
Default: .FALSE.
FREEKN If .TRUE. the link data contained in an external KNOBS data file FILKNB
are entirely in free format, i.e., node specification as well as data. See
15.14.5.
Default: .FALSE.
FUNNEL If .TRUE. turns coded with a single Priority Marker M are assumed to
“funnel” into a single exit lane with their “major” turn. See 6.4.2.3 and
8.8.4.
Default: .TRUE.
ICING If .TRUE. elastic assignment uses a frozen trip matrix (which may be
defined here by FILICE). See 7.5.6.
Default: .FALSE.
ILOVEU If .FALSE. U-turns are allowed at external simulation nodes; if .TRUE.
they are (virtually) banned. See 18.9.1. N.B. Earlier versions of the
documentation had the T/F definitions confused and reversed; see
Appendix E.4
Default: .TRUE.
KERMIT (KilomEtRes and MInuTes!)
If .TRUE. the travel distances and times input on buffer link records are
5120257 / Apr 15 6-8

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

seconds. Outputs in P1X assume the same units. (Useful for very large
scale buffer networks only.)
Default: .FALSE.
KINKY If .TRUE. the standard speed-flow curves used for both the simulation
and buffer networks have a “kink” or discontinuity at V=C, above which
(V>C) they are linear and below (V<C), “power law”. If KINKY =
.FALSE. they are a power law throughout. USE WITH CAUTION! See
15.38.
Default: .TRUE.
KONAL If .TRUE. any KNOBS data is included at the end of each 333 buffer
record rather than as an extra line; see 6.6.
Default: .FALSE.
LCR108 If .TRUE. the “choke factors” applied to turn capacities are calculated in
a better way, introduced in 10.8, to remove possible discontinuities. See
8.4.4 and note 3, App. D.17.5.
Default: .TRUE.
LEFTDR If .TRUE. left-hand drive assumed. See Section 15.7.
Default: .TRUE. (or as set in SAT95KEY.DAT; Appendix Y)
LIST If .TRUE. a complete listing of the input records is given by SATNET in
the LPN file.
Default: .FALSE.
MINDER If .TRUE. (and FOZZIE = T) routes are interpolated using a minimum
distance algorithm if the “directional” method fails. See 15.18.
Default: .FALSE.
MONACO If .TRUE. the number of pcus which are required to “sit at the head of a
blocked queue” is set to TAX + 1. See 6.4.9.5 and 8.2.5.1.
M108 If .TRUE. the rules for M Priority Markers are per Release 10.8. See
6.4.2.3 and 8.8.4.5.
Default: .TRUE.
MULTIC If .TRUE., SATURN will undertake the path-building and loading using
the MULTI-Core version of the assignment algorithm (if available). See
15.53.4.1.
Default: .FALSE.
NOXYC If .TRUE. then a ‘C’ is not necessary in the 55555 records in order to
identify a zone; see 5.1.6 and 6.8.
Default: .FALSE.
NO333C If .TRUE. then a ‘C’ is not necessary in the 33333 records (or in KNOB
files, 15.14.5.1) in order to identify a zone; see 5.1.6 and note 13) in 6.6.
5120257 / Apr 15 6-9

Section 6
Default: .FALSE.
PARTAN If .TRUE. use the PARTAN option within single user class Wardrop
assignment; see 7.11.7.
Default: .FALSE.
PHILIP If .TRUE. use Phil Barrett’s suggested formula for the flow reduction W-
factor in link weaving; see 15.40.3.
Default: .FALSE.
PRINT If .TRUE. descriptions of the simulation, buffer and/or assignment
networks are printed by SATNET in the LPN file.
Default: .FALSE.
PRINTF If .TRUE. flows are printed for the assignment network by SATEASY.
Default: .FALSE.
PRSFD If .TRUE. SATSIM prints full flow-delay parameters for each simulation
turn.
Default: .FALSE.
QUEEN If .TRUE. blocking back calculations are based on the value of the link
QUEue at the End of the simulated time period, if .FALSE. it is based on
the average queue. See 8.5.
Default: .FALSE.
Q105 If .TRUE. certain new rules introduced in 10.5 for calculating delays in
highly congested circumstances will be used; see 8.4.7. (In fact, post
10.9, the default value of T is always taken,)
Default: .TRUE.
RAGS “Random delays At Give-wayS” The additional delays due to “random”
effects are applied to “give-way” or “minor” traffic movements as well as
“major”; see 8.6.2.
Default: .FALSE. (Recommended .TRUE.)
RB106 New rules for the simulation of roundabouts as introduced in 10.6 are
applied; see 8.7.3. In fact, post 10.9, the default value of T is always
taken,)
Default: .TRUE. (.FALSE. pre 10.8)
REDMEN Elastic Assignment Parameter; if .TRUE. an initial estimate of the road
trip matrix (file FILRED) is used under elastic assignment; see 7.5.3.2.
Default: .FALSE. (Recommended .TRUE.)
REFFUB If .TRUE. calculate buffer turn (geddit?) flows post assignment (but only
if SAVEIT = T)
Default: .FALSE.
ROSIE If .TRUE. time-flow curves for turns in shared lanes are calculated as a
function of the total shared flow, not the individual turning flow. See
8.4.3 and 7.1.3.
5120257 / Apr 15 6-10

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

RTP108 If .TRUE. random delays (LRTP > 0) are set by “estuary” rather than by
“river”. See 8.6.3.
SATOFF If .TRUE. signal offsets are optimised within SATALL; see Section
15.31.4 and 9.12.2.
Default: .FALSE.
SATTIT If .TRUE. the standard supplementary data file SATTIT.DAT is used to
define DA code text names. See 15.21.
Default: .TRUE.
SAVEIT If .TRUE. the link costs as used for each assignment tree build are
saved on a UFC file for subsequent analysis; e.g., to create forests. See
Section 15.23.1.
Default: .TRUE.
SAVUFO If .TRUE. (and SAVEIT = T as well) a .UFO file describing the assigned
O-D routes is generated under Frank-Wolfe assignment. See Sections
22.5.3 and 22.5.7.
Default: .FALSE.
SECRET If .TRUE. the uf* files created will be “secret” in the sense that the option
in P1X (see 11.4.2) to recreate a .dat file purely from a .uf* file will not be
allowed.
Default: .FALSE.
SHANDY If .TRUE. the link distances input are checked against crow-fly distances
calculated from node co-ordinates; significant discrepancies are noted
and zero or blank inputs are replaced. See 15.10.1.
Default: .TRUE. (Changed in 10.5.)
SIGOPT If .TRUE. signal green splits are automatically optimised within SATALL.
See 15.31.4 and 9.12.2.
Default: .FALSE.
SIM109 Choice of the original numerical ordering of nodes for simulation (F) or
the newer topological ordering (T). See 8.3.4.
Default: .TRUE.
SIM111 New simulation-based options introduced in release 11.1 are enabled;
e.g. random queues (8.6.5).
Default: .FALSE.
SOWHAT If .TRUE. a system optimal assignment is carried out as opposed to a
user optimal; See 7.11.9.
Default: .FALSE.
SPARSE Controls the system whereby SATALL stores internal trip matrices.
SPARSE = T is more efficient if more than 50% of the cells in the trip
5120257 / Apr 15 6-11

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

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

Section 6
Default: .TRUE.
UNIQUE If .TRUE. only a single queue is allowed to form on a set of over-
capacity buffer links which are in series. See 15.48
Default: .FALSE.
UPBUS If .TRUE. then bus routes start/end at the top/bottom and of simulation
links. See 6.9.2 and 11.7.2.1.
Default: .FALSE.
USEUFO If .TRUE. analysis programs such as P1X, SATCH and/or SATLOOK
use .UFO files in preference to .UFC by default (if they exist – see
SAVUFO above). See 22.5.3.
Default: .FALSE.
WHATHO If .TRUE., a system optimal assignment is carried out as opposed to a
user optimal; See Section 7.11.9.
Default: .FALSE.
WINDY If .TRUE. use the modern window-style terminal display which does not
“scroll”.
Default: .TRUE.
WRIGHT If .TRUE. certain warnings etc. are upgraded to semi-fatal errors. See
6.12.2.
Default: .TRUE.
ZILCH If .TRUE. no trip matrix is assigned prior to carrying out a one-off
simulation. See 9.12.13
Default: .FALSE.
6.3.2 Integer Parameters

IBUSVC(b) The vehicle class corresponding to buses in company (b); if
unsubscripted it applies to all buses and/or companies. See 5.8.2.
Default: 1
IFCC Defines whether the input centroid connector records in the buffer
network are assumed by default to be one-way or two-way. A ‘1’ implies
one-way and ‘2’ implies two-way. See Note 3 under 6.6.
Default: 2
IEPSG Defines the coordinate system upon which the SATURN coordinate
system is based. The EPSG code is an internationally accepted
standard identifying the system, and for British Ordnance Survey
National Grid at metre level is 27700. See 6.8.
Default: 27700
IFRL As IFCC but for the “real” buffer links as opposed to the centroid
connectors. See Note 3 under 6.6.
5120257 / Apr 15 6-13

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

Section 6
Default: 0
KOB “Kontrol of Burrell” – sets the type of random link cost distribution used
under SUE: 0 – Rectangular 1 – Normal 2 – Modified Normal 3 – Input
density function. See Section 7.2.3.1.
Default: 0
KOMBI After “KOMBI” assignment/simulation loops the assigned flows are
averaged with those from the previous assignment in order to avoid
oscillations. A value of 0 implies that averaging never takes place (the
default). See Section 9.3.
Default: 0
KONSTP “KONtrol of SToPping Criteria”. The stopping criteria for assignment –
simulation loops are based on either: ISTOP (KONSTP = 0); %GAP
value (1); CPU time (2); ISTOP and/or CPU (3); %GAP and/or CPU (4);
%GAP and ISTOP (5); %GAP or %ISTOP (6). See Section 9.2.3
Default: 5 (Changed from 0 in 11.3)
KORN “Kontrol of Random Numbers” – the seed value for the series generation
of random numbers used in SUE. See Section 7.2.4.
Default: 0
KPHMIN / Simulation link speeds and free flow speeds on buffer links with speeds
KPHMAX outside the range KPHMIN to KPHMAX generate warning messages in
SATNET.
Defaults: 10 and 100 kph respectively.
LCY Duration of the common traffic signal cycle time in seconds. See
Section 8.1.2 and 15.15.3.
Default: 75 seconds.
LRTP Length of the “Random” Time Period as used for calculating random
delays at traffic signals and/or major arms at priority junctions. See
Section 8.6.1.
Default: 0 (But positive values are recommended, e.g., equal to LTP)
LTP Duration of the simulated time period (in minutes). See 8.1.2 and 8.4.5.
Default: 30 minutes.
MANOFF The signalised simulation node number used as the reference point for
all optimum offsets set by SATOFF. See 12.2.3.
Default: 0.
MASL Maximum number of assignment/simulation loops. See 9.1 and/or 9.2.3.
Default: 15.
MASL_F The number of simulation assignment loops over which the input trip
matrix is kept fixed under elastic assignment; see 7.5.3.4.
Default: 0
MASL_M The minimum number of assignment-simulation loops to be undertaken
5120257 / Apr 15 6-15

Section 6
within SATALL; see 9.2.3.

Default: 1
MAXDTP Maximum “transient” delay (in minutes) permitted for a simulated turn.
See 8.4.1.
MAXQCT MAXimum Queue Clearance Time (in minutes) for queued traffic at the
end of a simulation time period. If 0, it is ignored. See 8.4.1.
MAXSPA The maximum number of arms for an (aggregated) node to be further
aggregated under SPIDER = T. See 15.56.3.
Default: 15 (Was 30 prior to version 11.3.12, April 2015)
MAXZN Maximum number or ‘name’ used to define a zone. See 5.1.6.
Default: 500.
MCALG Algorithm used by multi-core assignments. See 15.53.4.1.

Default: 1
MCNUM The number of cores available on a multi-core processor. See 15.53.4.1.
Default: 0 (use all available cores)
MCCS Number of count fields input with the ‘77777’ data input. See 6.10. (As
in “Manual Classified Counts”.)
Default: 1
MCGILL(u) Elastic assignment parameters to set the form of the demand function
for user class ‘u’ as follows (see 7.7.1 and 7.12.2):
0 = inelastic (fixed trip matrix)
1 = logit (incremental)
2 = power law
3 = exponential
4 = elastic exponential
10 = nested logit
11 = logit (shared)
Default: 0
MCUBC(u) Choice of distribution model for user class ‘u’; see 7.10.2.
Defaults: 0
MET METhod used for assignment: 0 – Link-based; 1 – Path-based; 2 – OBA.
See Section 21.
Default: 0
MINLSF/ Minimum/maximum expected lane saturation flows; Values outside
5120257 / Apr 15 6-16

Section 6
MAXLSF these limits generate a warning message.

Defaults: 300, 3000
MINRED Used for data checking within SATNET. Any turning movement at traffic
signals with a distinct red phase of less than MINRED seconds
generates an error message.
Default: 10 seconds.
MINSAT Used for data checking within SATNET. Any turn saturation flow below
MINSAT generates a warning message (which may be suppressed
entirely by setting MINSAT to 0).
Default: 500 pcu/hr.
MODET MODET (= MODE Terminal) determines whether (and how much)
information is output to a user terminal. If MODET = 0 all information
goes to the line printer file. If MODET is non-zero ‘progress reports’
appear at the terminal during the execution of the programs. (In
particular if MODET is negative reports appear at the terminal only, if
positive the same information is sent to both the terminal and the line
printer file.)
Default: 1
MYTVV Choice of the signal optimisation procedure 1 to 5; see 15.31.3
Default 1 (But recommended 5)
NFT “National Film Theatre” for really great old films. Set, e.g. NFT = 103 to
get release version 10.3. See 8.5.
Default: 108 (i.e. use the latest version)
NIPS Maximum number of signal optimisation “outer” loops in SATALL. See
9.12.2.
Default: 2
NISTOP The number of successive loops which must satisfy the “ISTOP” criteria
in the test for convergence of the assignment/simulation loops. See
Section 9.1.2 and 9.2.5.
NITA Maximum number of assignment iterations. See 7.1.5, 7.2.2 & 9.5.2.
Default: 20
NITA_C The maximum number of iterations stored in a .UFC file when UFC109 =
T. See 15.23.3
Default: 256
NITA_F The number of initial assignment iterations over which the initial trip
matrix is kept fixed under elastic assignment; see 7.5.3.4.
Default: 0 (But recommended as a small non-zero value)
NITA_M The minimum number of assignment iterations; see 7.1.5 and 9.5.1.
Default: 3 (or 1 under OBA)
5120257 / Apr 15 6-17

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

convergence assignment under SAVEIT: If zero, assume NITA. See
15.23.4.
Default: 99
NITS_M The minimum number of simulation iterations. See 8.1.4 and 8.3.2
Default: 5
NITS Maximum number of simulation iterations. See 8.1.4 and 8.3.2.
Default: 20 (Upgraded from 10 in 10.9.10)
NOMADS Number of multiple user classes, e.g., cars, lorries, etc., to be assigned
separately. Maximum 32. See Section 7.3.
Default: 1
NOPD A non-zero value suppresses all “Platoon Dispersion” between
successive junctions. See Section III-2 of SATURN NOTES. (N.B.
Dangerous parameter – best ignored!)
Default: 0
NOPMAX Maximum number of internal iterations used by the signal setting
routines; see 15.31.3
Default: 1
NOTUK Used to set various “non-UK” rules of the road; see Sections 6.4.2.7 and
15.7.1.
Default: 0. (For British rules of the road although there may be a strong
case for a default value of 1, even in the UK; see 15.7.1)
NUC Number of time-units into which the cycle is divided in the simulation;
global value (maximum value 25). See 8.1.2 and 15.15.2.
Default: 10 (Prior to 11.1 the default was 15.)
NUCJT(j) NUC value for simulation junction type j (e.g., 3 for signals). Maximum
125. See 15.15.2.
Defaults: all 0
NUCMIN Minimum number of time-units into which the cycle is divided in the
simulation (maximum value 25). See 8.1.2. Lower input values at
individual nodes are fatal errors.
Default: 1
6.3.3 Real Parameters

AFTERS Vehicles held in queues upstream of further queues are assumed to
encounter the final downstream queues multiplied by a factor AFTERS
in later time periods. A sensible value is 1.0; the default is optimistic and
chosen for historical compatibility. See 17.6.2.
5120257 / Apr 15 6-18

Section 6
Default: 0.5
AK_MIN Minimum value for averaging flows under AUTOK. See 9.3.2.
Default: 0.0 (i.e., does nothing although a value of 0.20 is tentatively
recommended)
ALEX Average Length of a vehicle (Externally) in a queue; used to estimate
the actual length of a queue from the number of vehicles. See 8.5.
Primarily used to model blocking back.
Default: 5.75 (metres per pcu).
APRESV “Apres Vous” controls the default “weight” assigned to merging traffic in
terms of the lane choice by the “major” traffic for turn priority markers M
– See Section 8.8.3.1. Link-specific values may be set later; see 6.4.14
and/or 6.13.4.
Default: 1.0
BBKING Minimum queue/stack ratio at which blocking back is applied (Blocking
Back Kicks IN – Geddit?) See 8.5.6. (N.B. Only applied if BB109 = T.)
Default: 1.0
BCRP “Buffer Capacity Restraint Power” – used to define a default “power” for
speed-flow curves in the buffer network – See Sections 5.4 and 6.6, note
(4).
Default: 5.0
BETA(u) Elastic assignment elasticity parameter (for user class ‘u’) as used under
MCGILL = 1, 3 10 or 11. N.B. Units of inverse seconds. See 7.7.1 and
7.7.6.
Default: 0.1 (units of inverse generalised seconds)
BETA_2 (u) As BETA but for nested logit models. See 7.6.3 /7.6.4.
Default: 0.1
BETA_D (u) As BETA but for distribution models. See 7.10.2.
Default: 0.1
BETA_T (u) As BETA but for time-choice models. See App-V.
Default: 0.1
BTKNOB(b,k) Bus Times (in seconds) per KNOB data field k for all routes within bus
company b. See 15.44.
Default: 0.0
BUSPCU(b) Factor to convert bus flows for company ‘b’ into P.C.U.’s. See 6.9.1,
and, in particular, 6.9.3 for subscripted values of BUSPCU.
Default: 3.0
BUSSPK(b) Bus Stop Seconds Per Kilometre for all routes within bus company b.
See 15.44.
Default: 0.0
5120257 / Apr 15 6-19

Section 6
CAPMIN Minimum capacity to be expected for any (give-way) turn; any junction
with lower capacities will be factored up to CAPMIN (pcu/hr). See 8.2.
Default: 30.0
CLICKS(n) Maximum free-flow speed in KPH for user class n. See 15.47.
Defaults: 0.0
COBAF Factor to be applied to link flows under the SATCOBA facility. See
15.42.
Default: 1.0
DEFCAP Default capacity per lane of a link which is “out-bound” to an external
simulation node.
Default: 1250 pcu/hr.
FISTOP Wardrop assignment stopping parameter monitoring the fractional
improvements in the objective function. See 7.1.5.
Default: 0.05 %
FLAREF The default number of PCUs which, by default, are able to queue in an
extra near-side (Filter) flared lane at either signals or priority junctions if
an F is coded in the lane field. See 6.4.9.3, 6.4.14 (for link-specific
inputs), and 8.2.6.
Default: 2.0
FLAREX The default number of PCUs which, by default, are able to queue in an
extra off-side flared (X-) lane at either signals or priority junctions if an F
is coded in the lane field. See 6.4.9.3, 6.4.14 (for link-specific inputs),
8.2.5.2 and 8.2.6.
Default: 2.0
FLPK Fuel consumption per pcu in litres per kilometre. See 15.32.
Default: 0.07
FLPH Fuel consumption per pcu in litres per hour. See 15.32.
Default: 1.2
FLPPS Fuel consumption per pcu in litres per primary stop. See 15.32.
Default: 0.016
FLPSS Fuel consumption per pcu in litres per secondary stop. See 15.32.
Default: 0.005
FRED An initial estimate of the effect of elastic assignment on the total number
of trips (for incremental demand models only). See 7.5.3.2.
Default: 1.0
GAP Minimum gap (in seconds) accepted by a vehicle which gives way at
priority junctions or traffic signals. N.B. This sets the universal default
value which may be over-ridden at individual nodes; see 6.4.1.
Default: 5.0 seconds (NB: historical default value)
5120257 / Apr 15 6-20

Section 6
GAPM As GAP but for merging turns.

GAPR As GAP but for entry onto roundabouts.
(N.B. See Section 15.22 for further details on how to set the GAP-
parameters rather than accepting the historical default values.)
GONZO (Gonzo the factor – not Gonzo the Great!) All elements in the trip matrix
assigned are factored by GONZO. See, e.g., Sections 7.11.5, 12.1.7
and 13.1.14.
Default: 1.0
PCNEAR Percentage change in flows judged to be “near” in successive
assignments. See 9.1.
Default: 1.0. (Changed from 5.0 in 11.3).
PMAX Maximum value of the power used in the simulation flow-delay curves.
See 8.4.2.
Default: 10.0 (Recommended smaller values, e.g., 5.0)
POWER(u) Elastic assignment parameter giving the elasticity for MCGILL = 2 or 4.
See 7.7.1 and 7.12.2.
Default: 1.0
PPK Pence Per Kilometre – used to convert distances into generalised costs.
See Section 7.11.1.
Default: 0.0
PPM Pence Per Minute – converts times into generalised costs. See Section
7.11.1.
Default: 1.0
QDMAX Maximum delay in seconds used by Q-turns. See Appendix Q.
Default: 226
QVCMIN Minimum V/C ratio at which delays are applied to Q-turns. See Appendix
Q.
Default: 0.75
RSTOP Used in the test for convergence of the assignment/simulation loops.
The loops stop automatically if RSTOP % of the link flows change by
less than “PCNEAR” percent (default 1%) from one assignment to the
next. See also ISTOP. Section 9.1.2, 9.2.5 and 9.2.6..
Default: 97.5 % (Changed from 94.5% in 11.3)).
SHADOW An assumed speed in kph for the “shadow network” assignment option;
see 7.11.10.
Default: 0.0
5120257 / Apr 15 6-21

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

when KONSTP = 1 or 5. See 9.2.3.
Default: 1.0 %
STPCPU Critical CPU time (in seconds) used to terminate assignment-simulation
loops when KONSTP = 2. See 9.2.3.
Default: 1,000 seconds
SUET(u) Used to define the range of link cost variation in SUE assignment for
(optionally) user class u – see Section 7.2.3.
Default: 0.2
TAX Default number of X-coded pcus that can stack in the middle of a
signalised junction and clear after the end of the green. See 6.4.2.2,
6.4.14 (for link-specific inputs) and 8.2.4.
Default: 2.0 pcus.
TDEL Fixed “geometric” delay to allow for acceleration/deceleration on minor
arms at priority junctions or at roundabouts. See 8.4.1.
Default: 3.0 seconds
TIJMIN Any OD cells in the trip matrix which are less than TIJMIN will be
ignored.
Default: 0.0
UNCRTS Wardrop assignment stopping parameter monitoring the parameter
epsilon. See 7.1.5 and 9.2.3.
Default: 0.05 % (Changed from 0.20% in release 10.9)
VCPCU(v) The pcu value per vehicle in vehicle class v, or for all vehicles in the trip
matrix if unscripted. See 5.8 and 15.17.2.
Default: 1.0
WLMIN Minimum length for link weaving (in metres); see 15.40.2. (Aka DMWL)
Default: 300.0
WLMAX Maximum length for link weaving (in metres); see 15.40.3. (Aka
DMWL2)
Default: 2000.0
W32D Minimum difference in distances on reverse directions on simulation
links to trigger Warning 32 (See Table 1, Appendix L)
Default: 0.001 (i.e., zero)
W32T Minimum relative difference in times on reverse directions on simulation
links to trigger Warning 32 (See Table 1, Appendix L)
Default: 0.10 (i.e., 10%)
W32KPH Minimum difference in speeds on reverse directions on simulation links
to trigger Warning 32 (See Table 1, Appendix L)
Default: 1.5 kph
5120257 / Apr 15 6-22

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

Note that the alphanumeric values defined for all character parameters need to be
set inside two single apostrophes; e.g. XYFORM = ‘2F10.2’. Otherwise they will
not be recognised as Character Parameters and be rejected as invalid Namelist
entries. See Note 7, Appendix A.
CINAME(i) The text name to be associated with capacity index i; see 5.1.9.
Default: blank. Maximum length: 20.
COINS The “smaller” unit used to define tolls; see 20.3
Default: ‘Pence’
CURNCY The “larger” unit used to define tolls; see 20.3.
Default: ‘Pounds’
FILGIS The “file name” of the GIS file associated with this particular network;
see Section 5.7.
Default: blank (i.e., no file)
FILTIJ The “file name” of the .ufm trip matrix file associated with this particular
network and which will be assigned during the assignment.
Default: blank (i.e., no file defined at this stage)
O
FILCGH The “file name” of the .ufm cost matrix c ij to be used in the “incremental”
distribution model (MCUBC = 1); see 7.10.3 and 7.12.3.
Default: blank
FILCIJ The “file name” of the .ufm cost matrix file to be used within an elastic
O
assignment c ij . See 7.7.1 and 7.12.3 (and 7.6.4 for its use with nested
logit).
Default: blank (i.e. no file).
FILCKL The “file name” of the cost matrix to be used in the “lower” level of the
nested logit choice model; see 7.6.4 and 7.12.3.
Default: blank
FILICE The “file name” for the .ufm matrix of frozen ij movements within elastic
assignment if ICING = T. See 7.5.6 and 7.12.3.
5120257 / Apr 15 6-23

Section 6

FILN2G The file name for a “N2G” file which defines “groups” (e.g., sectors, traffic
boroughs, etc.) for each network node. See 11.11.4.
FILPEN The file name of the .ufm matrix used to define link tolls by origin. (Not
yet available.)
Default: blank
FILKNB The file name used to define link KNOBS data. See 15.14.5.
Default: blank
FILBMP The name of the .bmp file/folder used to define a background display for
P1X plots. See 11.3.6 and 15.43.
Default: blank
FILRED The “file name” of the input .ufm matrix containing the initial estimate of
the road trip matrix under elastic assignment if REDMEN = T; see 7.5.3.2
and 7.12.3.
FILRGS The file name of an input .RGS file containing a set of signal timings
which will over-write those on the input .dat file. See 6.4.3.5 and
11.9.14.
ROADIJ The “file name” of the output .ufm matrix containing the elastic road trip
matrix under elastic assignment. See 7.12.3.
FILVSD The “file name” of the input text file containing CLICKS values
disaggregated by Capacity Index and Vehicle Class. See 15.47.2
FILN2G The “file name” of the input text file which associates a “group name”
(e.g., a traffic borough) with each network node. See 5.1.7
UCNAME(u) The text name to be associated with user class u (5.8.1).
VCNAME(v) The text name to be associated with vehicle class v (5.8.2).
XFILE Name of the supplementary X-file; see 6.13.
Default: blank (i.e. no file)
XYFORM The “format” used to define node X, Y co-ordinates under the 55555
fixed column data records - see Section 6.8.
Default: 2I5. (N.B. Not a particularly useful default – only still there for
historical compatibility – and only necessary if FREEXY = F, which is
5120257 / Apr 15 6-24
Section 6
itself not recommended either.)
N.B. Most namelist parameter names representing files have alternative spellings
so that, e.g., FILTIJ is also recognised by TIJFIL, FILCIJ by CIJFIL etc. etc.
6.4 Simulation Network: the ‘11111’ Records

Data in this section must be preceded by a single record with a 1 in column 1 (or,
more usually, 11111 in columns 1-5) and terminated by a single record containing
99999 in columns 1 to 5.
For internal nodes a complete description of the node, its links, capacities of turns
and signal timings (for traffic signals) must be given on three sets of records:
♦ Record type 1 - Node description (mandatory)
♦ Records type 2 - Link description - One record (mandatory) for each

link in strict clockwise * order but starting with any arbitrary link (plus,
optionally, a second link record (2B) to describe link speed-flow
characteristics).
♦ Records type 3 - Stage descriptions. Only required for type 3 nodes;

i.e. traffic signals. One record per stage is input.
For external nodes only record types 1) and 2) are required. In addition only the
starred (*) variables below need be included on these records.
Nodes, whether internal or external, may be included in any order (i.e, they need
not be in numerical order).
All numerical data entries (bar one) are implicitly INTEGER and should (for safety)
be right justified; the speed flow power on record 2B explicitly requires a decimal).
However the following inputs may optionally include a decimal within the
designated columns in order to provide greater accuracy: TIM on record 2, TFF
and TCAP on record 2B and STAGL and INTGL on record 3.
Coding instructions are given below and worked examples for each node type
appear in Section 16. The “NAME” column provides a convenient shorthand for
data entries and is not used elsewhere.
Historically coded simulation data were prepared by the user working with their
own editing system; however it is now possible to prepare .dat files using the
interactive network and node editing facilities within P1X (see 5.6, 11.9 and 18).
However some “fine tuning” using a text editor will probably still be needed
* Counter-clockwise under drive on the right.
5120257 / Apr 15 6-25

Section 6
6.4.1 Node Data Formats
RECORD TYPE 1 - NODE DATA

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

1-5 STACK Link stacking capacity (PCU) - see 6.4.11.
6-10 ANODE* Node at the ‘upstream’ end of the link (which may be an
external node)
11 QSTAR ‘*’ if a link speed-flow curve and/or extra link parameters are
required - see 6.4.12 and/or 6.4.14
12-15 LANES* Number of entry lanes (plus weave, flare and/or bus lane
indicators) for this link - see 6.4.9.1.
5120257 / Apr 15 6-26

Section 6
(0 if the link is one-way from ‘NODE’ to ‘ANODE’ or negative if

it is a bus-only link - See 6.4.4.)
16-20 TIM* Travel time for this link in seconds, or the average link speed in
KPH if SPEEDS = T (See 6.4.5).
21-25 IDIST* Length of this link in metres
26-35 Data for the first possible turn from this link:
26-30 LSAT The saturation flow of the first turn from this link in a clockwise
direction in pcus/hr. See 6.4.6 and 6.4.8.
(0 implies that the turn is banned and a negative value implies
a bus-only turn - see 6.4.4.)
31 TPM The Turn Priority Marker for this turn - See 6.4.2.
32 TPMod Turn Priority Marker Modifier. See 6.4.2.
33 LANE1 First lane (counted from the nearside) used by this turn - 6.4.9.
35 LANE2 Last lane used by turn.
36-45 Data for the second possible turn from this link:
36-40 LSAT Saturation flow, priority marker
41 TPM and lane definition for the next
42 TPMod turn in a
43 LANE1 clockwise direction
45 LANE2 etc., etc.
up to
75 LANE2 for the fifth turn (as required).
In addition (post 10.9) the five data columns following directly on from the last
possible set of turn data (e.g., columns 76-80 if there were 5 turns) may contain a
value for TAX for that link; see 6.4.14 for precise formatting conventions.
(N.B. The following record, 2B, is only needed if a ‘*’ was coded in column 11
above AND LANES > 0, in which case an extra line containing link speed-flow
and/or other parameters is inserted. This option is relatively rarely used for short
links in central area but may be extremely useful for modelling motorway-type
links. See 6.4.12 and 6.4.14 for how to include extra data such as flares on
record 2B.)
RECORD TYPE 2B - LINK SPEED FLOW DATA

11-15 TFF Link travel time at free flow (in seconds) or
(if SPEEDS = T) Link travel speed at free flow (in kph)
16-20 TCAP Link travel time at capacity (in seconds) or
or (if SPEEDS = T) Link travel speed at capacity (in kph)
5120257 / Apr 15 6-27

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

29 S if speeds are used in 11-20, T if time; D if extra delays; if
blank then SPEEDS decides. See 6.4.12, 6.4.12.2 for D.
36-40 N The power ‘N’ used in the speed-flow curve with a decimal in
column 39 (by default – see 2.8.3)
43-45 INDEX A “Link Capacity Index” in the range 0-999 (where 0 or blank
implies a “non” index); see 5.1.9. The index may also be used
to define default speed-flow curves which replace the data in
columns 11-40; see 15.9.5.
RECORD TYPE 3 – SIGNAL DATA

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

turning movements from that A-NODE (except of course any prohibited
movements indicated by zero saturation flow) are allowed
♦ If more than 5 movements are required they are continued onto a second
record with the 6th A-node appearing in cols. 26-30 of the second
record, etc
♦ STAGL and INTG (stage duration and inter-green) are normally input as
integer seconds but it also permissible to define them as real quantities
(i.e., 16.84 as opposed to 17) as long as the numbers fit within the
allocated column limits. See 2.8.3.
6.4.2 Turn Priority Markers (TPM) and Modifiers

(N.B. For right-hand drive read left for right in this note and vice-versa.)
These describe which traffic flows oppose a turning movement. Explanatory
notes follow. The main TPM must be one of the following:
5120257 / Apr 15 6-28

Section 6
G A turn which must give way (from a minor road) at a priority junction.
X Opposed right turn from a major road at a priority junction which needs to
cross the major flow in the opposite direction, OR an opposed right turn at
traffic signals which must cross the major flow from opposite arms.
M A turn which “merges” with another turning movement at a priority junction.
F A permanent filter at traffic signals with 100% green (generally to the left but
occasionally to the right).
W A weaving movement between traffic entering and leaving (typically) a
motorway.
Q A downstream motorway merge; see Appendix Q.
BLANK No opposing flow.
While the modifiers (which are used relatively infrequently) must be one of:
C To denote a “Clear” or reserved exit lane used after G or X;
D A “Diamond Cross”, i.e., to convert hooked into non-hooked or vice-versa;
used after G or X;
E Both C and D apply.
FURTHER NOTES:
6.4.2.1 Giveways (G)
The G priority marker indicates either a “give-way” or a “sharing” manoeuvre
whereby a turn marked G gives way to all “major” turning movements (i.e. those
without any priority marker or an X) but “shares” with other give-way movements.
The movements which affect a G-turn are either those which it crosses or those
with which it shares an exit; these are determined by SATURN from the geometry
of the junction.
Thus in the above figure if the turn S-O-E were coded G it would give way to the
major road flows W-O-E and E-O-W but would “share” with movements N-O-S
(crossing) and N-O-E (shared exit). On the other hand it is unaffected by turn W-
O-N which it neither crosses nor shares an exit with.
If movement 1 “gives way” to movement 2 this means that the capacity for
movement 1 goes from its (otherwise) maximum value down to zero as the flow
5120257 / Apr 15 6-29

Section 6
on movement 2 increases from 0 to its capacity. See Figure 5.1. Movement 2 is

unaffected by movement 1.
However if they “share” the capacity for movement 1 goes from its maximum down
to ONLY 50% maximum as movement 2 increases, while movement 2’s capacity
also goes from 100% down to 50% as movement 1 increases. Hence sharing
implies that both movements are guaranteed 50% of their capacity plus another
50% depending on the shared partner.
6.4.2.2 Opposed Right Turn (X)
Movements coded X at priority junctions must give way to opposing major
movements; for example W-O-S above (which turns right from a major arm) would
give way to the opposing straight ahead flow E-O-W.
The same rule applies to X-turns at signals with the additional condition that they
are only opposed by flows which share the same green times, not by movements
which take place during other “phases”. In addition it is assumed within the
simulation routines that up to TAX pcus can execute an X movement at the end of
each green sequence/phase. This allows for vehicles stacking in their reserved
lanes and discharging during the amber phase. See 8.2.4.
N.B. Post release 11.1 the above rule has been modified such that if an X-turn at
signals only appears in phases which are terminated by a stage in which the X-
turn is unopposed (e.g., by a late cut-off) then the extra allocation of TAX pcus is
not allocated. The rationale is that if the stacked vehicles are allowed to clear
during the late cut-off then there it will not be possible for additional traffic to stack
and clear at the end of the extra stage. (Further releases may further amend this
rule such that if, say, TAX = 3.0 and the final stage allows 2.0 PCUs then the
difference of 1.0 PCU will be allowed under TAX.) See 8.2.4.1.
Note that if the X-marker is placed on the “wrong” movement then the
consequences may be severe and not always easy for the program to detect. For
example, in the above diagram, if the X marker were assigned to E-O-W rather
than W-O-S then the straight ahead traffic would give way to turning traffic and
clearly the junction would behave in a quite different manner. It may be, of course,
that in certain circumstances that is exactly the give-way behaviour that is
required but, generally speaking, such an allocation of X-markers should be
regarded as highly suspicious.
The above possibility was first identified in release 10.5 and assigned the Serious
Warning number 139. Previously it was identified only via “warning 53” which, in
the above example, would be due to the fact that two “major” movements W-O-S
and E-O-S both enter the same arm without one having priority over the other.
6.4.2.3 Merge (M)
A “merging” turn coded M at a priority junction (only) must give way to a single
“major” turn flow, the most obvious example of this being a slip road entering a
motorway and giving way to the straight ahead flow on the motorway. In addition,
it only needs to find a gap in a single (nearest) lane (see below for the choice-of-
lane rules).
5120257 / Apr 15 6-30

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

We consider here the situation where only one turning movement has been
assigned an M priority marker and the question of how to determine the
movement into which it merges. The most common example of this situation
would be that of a slip road – D-B in the diagram below – merging into a major
road A-B-C so that the turn D-B-C would be assigned a marker M.
The following rule is used to determine the “major” turning movement with which a
turn coded M merges. The opposing turn must (a) share the same exit arm, and
(b) be the first turn from an “off-side” link (in a counter-clockwise direction for drive
on the left) to do so. In virtually all cases the turn marked M will be the first turn
out of a link and will merge with the second turn from the previous link. Thus, in
the above diagram, D-B-C marked M is the first turn out of D-B and it merges
(“near-side”) with the second turn A-B-C out of link A-B.
However more complicated merges may also be modelled under the above rule.
For example, a turn may merge with a major “near-side” flow provided that no
suitable “off-side” flow is detected first. (A near-side merge is found by the
program working its way through off-side roads until it comes to the near-side;
hence the reason that there must be no off-side flows.)
Thus in the schematic diagram below (where all roads are one-way, A to N, B to N
and N to C) if turn B-N-C were coded M it would merge as the minor road with A-
N-C as the major flow, i.e., on its “off-side”. However, if A-N-C were coded as M it
would be the minor arm merging with B-N-C as the major arm on its near-side.
5120257 / Apr 15 6-31

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

The merge facility can also be used to model “Y” junctions where two streams of
traffic with equal priority merge. For example, this might occur if two “equal”
motorways merge together, in which case the merge occurs between the nearside
lane of one and the offside lane of the other, both of which are assumed to
merge/funnel into a single exit lane. (Equal, in this sense, implies that neither
motorway can be assumed to be the “major” flow and that, say, both have equal
number of lanes. However the double-M may also be used with “unequal”
motorways, for example a single-lane ramp merging into a multi-lane motorway
where, at the point of merging, both flows have equal priority.)
In the diagram immediately above both turns A-N-C and B-N-C would be
assigned priority markers M and both turns would suffer a reduction to their
capacity and an increase in their delay dependent upon the alternative flows. See
8.8.3 and 8.8.4 for a more detailed discussion of how the lane choices and
capacities would be modelled in this situation. N.B. Y-merges, as explained in
8.8.3.2, should not be used with certain lane configurations.
Alternatively, two one-way streets merging into a one-way street could also be
modelled by coding each turn as a G, but this would almost certainly result in
greater losses of capacity.
FUNNELLING AND LATERAL MERGES (POST 10.8)

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

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

Section 6
6.4.2.5 Weave Areas (W)

The “weave” priority markers first introduced in SATURN 9.4 typically represent a
weaving section where traffic may both enter/leave a motorway from/to an
adjoining slip road at the same node. The “geometry” is illustrated below (based
on left hand drive).
Here A-E-D represents a 2-lane motorway and B-E-D a 2 lane parallel slip road.
Four turning movements are possible:
A-E-D Stay on the motorway
A-E-C Exit the motorway
B-E-D Join the motorway
B-E-C Stay on the slip road
Lane allocations are not shown in the diagram and are of course set by the user
but for the sake of illustration we shall assume that the “straight on” movements A-
E-D and B-E-C can use both lanes while A-E-C may only use the single nearside
lane and B-E-D, the single offside lane.
Movements A-E-C and B-E-D are linked together via a weaving section and both
would need to be coded with a priority marker W. This produces the following
potential give-way and/or sharing rules.
A-E-D: Unopposed
A-E-C: Shares with its co-weaving movement B-E-D and gives way to any B-E-C
flow which uses the offside slip road lane.
B-E-D: Shares with its co-weaving movement A-E-C and gives way to any A-E-D
flow which uses the nearside motorway lane.
B-E-C: Unopposed
NOTES
In addition to give-way and/or sharing reductions in capacity there may also be
reductions due to lane sharing: e.g. A-E-C and A-E-D may both share the
nearside lane.
5120257 / Apr 15 6-34

Section 6
W priority markers must always appear in pairs with, for fairly clear reasons which
are difficult to specify succinctly, certain geometrical rules. Pragmatically this boils
down to the rule that the W’s must appear in the same column on two successive
link records
Weaving may also take place between two junctions, e.g., on a motorway, which
are separated by a finite distance; see Section 6.4.9.4 for coding inputs and
Section 15.40 - and 15.40.7 in particular - for a discussion of the differences (and
similarities) between the two methods. Note that both are indicated by a W marker
but in different locations.
6.4.2.6 Clear Exits [C]
An example of a turn with a “Clear Exit” - turn modifier C - is given below
Here the S to E movement, indicated by a and coded with a turn priority marker G
and a modifier C, has its own exclusive exit lane and therefore need not give way
to ‘b’ vehicles on the major road W-E. However they do give way to the W-S
vehicles (indicated by d) and the E to W movements (indicated by c) since they
must cross these movements.
Hence any movement with turn modifier C only gives way/shares with movements
that it must cross but not with movements with which it simply shares an exit.
In the above example had S-E only been coded as G it would have had to give
way to the W-E movements as well.
C markers may follow an X or a G and may be used for any turn except the first
(since the first turn can only share its exit, by definition it cannot cross any
movements).
In addition, post 10.8, they may also follow an M-marker to indicate that the turn
has a clear exit and does not “funnel”; see 6.4.2.3. Plus, post 10.9, they may also
follow a F priority marker at signals indicating that the filter turn has its own clear
exit lane and does not have to merge with or give-way to other traffic entering the
same link at the same time.
A further post 10.9 feature is that SATNET checks whether, given the number of
(downstream) lanes on an exit arm and the number of entry lanes used by turns
entering that arm, there appears to be available lanes for a clear exit. For
example, in the above diagram, there are two exit lanes to E but the turn W-E only
has one lane at its entry, suggesting that there is one lane available to S to enter
the exit to E. Had there been just one lane to E this would not be the case.
Warning 98 detects such instances and prints appropriate messages. N.B.
Warning 98 is only a suggestion, nothing more.
5120257 / Apr 15 6-35

Section 6
6.4.2.7 Hooks / Non-Hooks (D)

Opposite pairs of right-turning G or X movements may either “hook”, i.e. interfere,
or not with one another depending on the road geometry. The two possibilities -
(a), not hooked; (b), hooked - are sketched below:
The default situation is as set by NOTUK; hence with the “UK” default value
NOTUK = 0 interference as in (b) is assumed; coding a turn priority modifier of D
would convert the situation into no interference as in (a). Equally if NOTUK = 1 or
3 (see 15.7) then the default is (a) and a D for an individual turn converts to (b).
Hence the D modifier is essentially a “toggle” which switches between the two
possibilities.
Logically both turns should be coded as D’s or neither, but there is no absolute
requirement that this is coded (apart from Serious Warning 167 resulting).
Users should be made aware that situation (a), no interference, is preferable in
the sense that it makes overall convergence easier. Therefore, if the situation is
likely to occur at one or more junctions, it is worth checking that it has been
coded, e.g., by the use of markers X and D. Warning 97 prompts.
6.4.2.8 Hooked & Clear Exit Lanes (E)
This indicates that both the C and D modifiers apply, e.g. a hooked/unhooked
movement with a clear exit lane.
6.4.3 Stage Definition, Duration, Inter-green and Offsets

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

Section 6
The durations of the stage time and the inter-green period are defined in fields 1
and 2 on Record Type 3, i.e., columns 11-15 and 16-20 respectively. See also
6.4.13 for how to define upper and/or lower limits on the stage green times.
6.4.3.1 Continuous Green Movements
Under certain circumstances the inter-green period is set equal to zero. For
example, if on a particular arm a left filter arrow is displayed, say, 10 seconds after
the “main” green phase begins this would be coded by having one stage of length
10 seconds and zero inter-green followed by another stage in which the left turn is
added to the list of green movements.
Zero-length inter-greens therefore imply that movements which are green in two
successive stages must be continuously green over both stages.
The same also applies, in general, to two successive greens with non-zero inter-
greens. For example the inter-green period might represent the gap between the
display of straight-ahead and left arrows in the first stage and of straight-ahead
and right arrows in the second, in which case the straight-ahead movement
continues as green during the inter-green.
The general rule is therefore that movements which are green during two
consecutive stages are also green during the inter-green, with certain exceptions:
(i) If the signals have only one stage (in which case every possible movement
must be coded as green during that stage) it is assumed that all movements
are red during the inter-green. This situation commonly occurs in the
representation of pedestrian signals at a node in the middle of the block.
(ii) Similarly at junctions with only two arms (e.g., pedestrian crossings again)
but multiple stages all inter-green periods are red for all movements. This
allows for pedestrian signals to be “double-phased”.
(iii) Right turners which are coded with an X priority marker but are (unusually?)
green in every stage are assumed to be red during every (positive) inter-
green period.
(iv) If the inter-green time is coded by a negative number, in which case the
absolute value gives the true inter-green time. This facility is introduced to
deal with any possible ambiguities.
Criteria (ii) and (iii) were first introduced in release 10.6.
6.4.3.2 Amber Phases
Note that, as implied above, we do not explicitly model amber phases - signals are
considered to be either “red” or “green” - although it is possible for the coder to
allow for vehicles “stealing” a certain amount (typically about 1 or 2 seconds) of
the post-green amber phase by artificially extending the green phase.
6.4.3.3 Stage Times
The input values for stage and inter green durations need not add up to the total
cycle time (LCY). If they do not, stage times will be factored by the program so
that the sum = LCY. Inter-green times, however, remain as input on the
5120257 / Apr 15 6-37

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

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

Section 6
6.4.3.6 Pedestrian (2-arm) Crossings

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

Bus-only roads, i.e., roads which are only used by buses in that direction only, are
identified by a NEGATIVE value of LANES on record 2 above. Turn capacities
should be coded in the normal way. The effect of this coding change is that no
car trips will be assigned to this link but the effect of buses both entering and
leaving the link on other traffic will be modelled.
See 6.4.9.2 for how to code roads with exclusive lanes for both buses and cars.
By contrast bus-only turns are turns out of a normal link from which cars are
banned. This is signified by coding a negative turn saturation value (LSAT on
Record 2) with the correct absolute value.
Note that it is not necessary to code bus-only turns out of a bus-only road,
although no harm is done by doing so, since once the road has been coded as
bus-only no vehicles will be assigned to it by the assignment and hence no
vehicles will reach the turns either.
Bus-only links and turns may also be coded using the banned turn/link facility as
described in Section 6.7 below (and in a number of respects this is a more natural
way to do it).
The latter input MUST be used if one wished to code, say, a “bus plus taxi” link
since a negative value as above would ban taxis as well as other vehicles.
6.4.5 Link Travel Times/Speeds and Distances

The link travel times input are the times required by a vehicle to traverse the entire
length of the link from stop line to stop line with no vehicles queued at the exit stop
line. Similarly the input cruising speed (if used) is the speed under these
conditions. Since this time or speed is taken as fixed by the program independent
of the flows assigned to this link it should reflect the expected level of traffic flow
on that link. However it must be emphasised that a number of studies have shown
that in urban conditions cruising speeds on most roads are virtually independent
5120257 / Apr 15 6-39

Section 6
of the flows, depending far more, for example, on whether the road is residential,
shopping, divided highway, etc. This is not to say that TOTAL travel times are
independent of flows, but that the main relationship between flows and delays
occurs at intersections, and it is these relationships that SATURN seeks to model
in depth. Conventional link-based speed-flow relationships are therefore generally
not part of the simulation network unless one explicitly uses the link speed flow
facility described in 6.4.12. (See also Section 15.13).
In most cases therefore the times or speeds may be thought of as “free-flow”
times or speeds. However an example of a case where they might not be free-
flow would be a motorway-style road with grade-separated access and exit points
where intersection delays would be minimal but the effect of flow on cruising
speeds might be significant. In such cases observed speeds would probably be
the most reliable input (unless of course link speed-flow curves were used -
6.4.12).
Link distances should be coded from the centre of one junction to the centre of the
next (but coding them as entry to exit lines would make virtually no difference).
6.4.6 Turn Saturation Flows

6.4.6.1 General Principles
Turn saturation flows refer to the maximum number of pcu’s per hour which could
make that particular turning movement PROVIDED there were no other vehicles
on the road, no red lights to oppose it, etc. Thus the only restrictions to be taken
into account in specifying the turn saturation flow are the physical characteristics
of the junction such as the number of lanes, their widths, turn radii, give-way or
not, etc. The model then simulates the reductions to the turn capacities from all
other effects.
N.B. Note the slightly different interpretation for roundabouts - 6.4.7.
Note, however, that the simulation model (see 8.2.1) may not necessarily include
all restrictions to vehicle movements. For example the simulation includes the
reduction in capacity due to minor road vehicles giving way to major road vehicles
but not giving way to pedestrians since the latter are not explicitly represented
within SATURN. In such cases it is necessary for the user to introduce the extra
effects by modifications to the input data.
Generally speaking this is best done by reducing the saturation flow to account for
the “missing” effects such that, at the end of the ACCEPT calculations (8.2.1) the
correct capacity has been obtained. Thus if a turn with a “purely geometric”
saturation flow of 2000 pcu/h gives way to a pedestrian crossing where, the user
decides, there are pedestrians 25% of the time the saturation flow should be
reduced to 1500 pcu/h.
Other coding methods may occasionally be used; for example, if the impact of
pedestrians at traffic signals is to effectively delay the start of a green stage, e.g.
the pedestrians tend to cross en masse at the start of a particular green stage
rather than at random throughout the green stage(s), then this may be better
reflected by reducing the length of the relevant green stage.
See 15.17 for a discussion of why we refer to pcu’s rather than vehicles.
5120257 / Apr 15 6-40

Section 6
6.4.6.2 Setting Saturation Flows

Setting “correct” saturation flows is as much an art as a science and it is not really
the role of this Manual to supply precise numerical formulae to apply since every
area to be modelled will have its own particular characteristics which will influence
saturation flows. However, in general terms, one can say that the following
features should be considered in setting saturation flows:
♦ Number of lanes
♦ Lane widths
♦ Position of lanes (e.g., nearside vrs offside)
♦ Junction type (e.g., roundabout vrs priority etc.)
♦ Major/minor arm (at priority junctions)
♦ Inclination (on hills)
♦ Visibility
♦ Turning angle (e.g., straight ahead vrs 90° right or left, sometimes
measured in terms of a “turning radius of curvature”)
We would strongly recommend organisations to set up their own sets of tables
and/or formulae, cross-classified by one or more of the above criteria, such that a
modeller, having “measured” the essential parameters above, may simply look up
/ calculate the appropriate saturation flow.
One major advantage of having standard procedures as above is that two different
coders, given the same junction to code, will come up with saturation flows which,
if not identical, will at least be close.
6.4.6.3 Consistent Saturation Flows by Lane
Of the various factors listed under 6.4.6.2 above all are effectively independent of
the individual turn being considered apart from viii), the turning angle (or turn
radius). Qualitatively one would expect that the saturation flow for vehicles going
straight ahead would be greater than, say, for vehicles turning at right angles
either to the left or to the right. It is, however, difficult to specify the exact form of
the relationship; different modellers will have their own personal or in-house rules.
It follows that it is very difficult for a computer program to say that if a straight
ahead saturation flow has been coded as 2,000 pcu/hr then a turn saturation flow
of only 500 for a 90° turn out of the same lane is “wrong”.
Nevertheless it is important to be able to at least warn users when input values
appear to be inconsistent. In order to do so SATURN adopts the arbitrary formula
that a turn through an angle θ (where θ = 0 implies straight ahead) will have its
saturation flow reduced by cos (θ/2) relative to straight ahead. Thus the saturation
flow for a right angle turn is reduced by a factor of cos(45°) = 0.707.
SATNET applies a consistency check by:
5120257 / Apr 15 6-41

Section 6
♦ Calculating a saturation flow per lane for each turn equal to its input
saturation flow divided by by the number of lanes;
♦ Converting that to an “effective” straight ahead saturation flow by

dividing it by cos (θ/2);
♦ Comparing the minimum and maximum effective saturation flows per

lane for each individual lane and for the entry arm as a whole.
If the ratio of maximum to minimum is (arbitrarily) greater than 1.5 overall or 1.4 in
an individual lane then a “Serious Warning 137” is generated.
This rule was first introduced in release 10.5 and clearly contains a number of
arbitrary assumptions. Indeed there is no overwhelming reason why the warnings
generated are “correct”; there may well be other perfectly valid reasons why the
user has chosen a particular set of input saturation flows (E.g., extra lanes may
have been coded – see 6.4.9.1 – to avoid problems of lane sharing without a
comparable increase in the saturation flow.). On the other hand coding errors are
not exactly rare and it is to be hoped that the above procedures will be able to
identify “real” errors more often than not.
6.4.6.4 References
TRRL SR 582 for priority junctions, or Webster and Cobbe (Road Research
Technical Paper 56, 1966) for traffic signals may be consulted; however more up-
to-date publications are clearly to be preferred. I suggest you look on the web!
6.4.7 Roundabout Saturation Flow

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

The maximum roundabout flow coded on Record Type 1 represents the circulating
flow at which the entry flow from any arm goes to zero (or, strictly speaking, to the
minimum value set by CAPMIN). It should be greater than the saturation flow
from any entry arm (i.e., the maximum value of all turn saturation flows); if not it is
replaced by the maximum value. See 8.7.
Section 15.22 explains how the values of the arm saturation flows, the roundabout
capacity and the minimum gap may be set so that the SATURN results are
compatible with those from the TRRL roundabout simulation package ARCADY.
Note that the arm saturation flows do not need to be the same for all entry arms
and the expectation would be, given similar design standards for all arms, that the
saturation flow per arm would be proportional to the number of lanes per arm.
Significant differences between the saturation flow per lane for different arms are
detected by Serious Warning 138, first introduced in Version 10.9.13.
5120257 / Apr 15 6-42

Section 6
6.4.8 The Order of Turns

Turning movements from each arm must be specified in strict clockwise order
starting with the first turn on the left (*). If this rule is not adhered to serious errors
can result. Given the geometrical complexities of networks it is generally difficult
to check whether this rule is complied with and, if not, where the error occurs.
One check carried out by SATNET is to determine whether a series of sharp left
turns from each arm returns to the same starting point, since one would expect
that these movements should trace out a closed loop on a map.
The test breaks down when the network contains overpasses where two links may
cross one another without there being an intersection. Any possible errors
reported by this check should be studied on a map.
(*) Or counter-clockwise and on the right for right-hand drive applications. The
general rule is that the turns are given from the “nearside” to the “offside”.
6.4.9 Lane Definition

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

Traditionally (pre 10.9.20), the number of lanes defined for each input arm
corresponds to the “effective” number of lanes at the stop line, not necessarily
the number of lanes along the road itself. By “effective” we mean that a link
which, say, has only one lane marked but is sufficiently wide that vehicles can
squeeze by on the nearside when a vehicle is queued on the offside should be
coded as two lanes, not one. Otherwise SATURN will over-estimate the blocking
effect of queued vehicles and underestimate capacities.
Similarly it may be advisable to include an extra “artificial” lane for offside turning
traffic if the flow is relatively light and queued traffic can be accommodated in the
centre of the junction without impeding other movements on the same arm.
(Although the effect may also be adequately modelled by using the TAX and
MONACO options; see 8.5.)
The problem is most acute when one or more turns give way (e.g., are coded as
X) and therefore may block any unimpeded traffic in the same lane. Hence a
single lane is “OK” for major arms at priority junctions (although unlikely to occur
in real life), but not otherwise. Single lanes which include both give-way and non
give-way movements are a major problem for convergence (9.5).
In case of doubt - code extra lanes!
5120257 / Apr 15 6-43

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

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

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

from the (extra) flared lane. In these cases, the full lane should be
modelled with a mid-link capacity constraint introduced if necessary;
and
♦ Length of the flared lanes: practical testing has shown that if the
length of the flared lane is more than 10 pcus, a full lane should be
coded.
The methods by which flared lanes are defined within a network .dat file are
described in sections 6.4.9.3 and 6.4.14
LANE NUMBERING
Note that SATURN lane numbers are counted from the nearside or kerb-side out
so that lane 1 is the “innermost” lane nearest to the kerb-side and the highest lane
(equal to the number of lanes as defined above) is the “outermost” lane nearest to
the centre of the road. Note, therefore, that any flared lanes are not explicitly
assigned extra lane numbers, their lane numbers are defined at the point of
flaring.
Successive turns (starting with the left turn for drive-on-the-left, right for drive-on-
the-right, and progressing clockwise/counter-clockwise) must obey certain fairly
basic traffic engineering rules. Thus there can be no empty lanes. Equally (drive
on the left) a right-turn cannot use lanes 1 and 2 while the straight-ahead can only
use lane 2 since that would imply that the right turns from lane 1 would need to
“cut-across” straight ahead traffic in lane 2.
Less urgently one should not have, say, a right-hand turn and a left hand turn
both assigned to lanes 1 and 2 since that would mean there could be traffic
turning right from the left hand lane having to weave with traffic turning left from
the right hand lane.
Violations of the former rule result in a Semi-Fatal Error whereas the latter is only
a Serious Warning.
6.4.9.2 Bus Lanes (B, S or T)
It is also possible to include bus-only lanes as part of the link simulation record by
including one or more B’s within columns 12-15; see Section 15.39 for full details
of how bus-only lanes are modelled in SATURN.
Briefly a bus-only lane is defined to be a “full-length” lane from the upstream entry
to the downstream stop lane exclusively used by buses (where “buses” in fact
includes any form of public transport vehicle as coded on the 66666 records;
6.9.1). Thus at the moment bus lanes with set-backs cannot be explicitly
modelled.
To define, say, a road with a total of three lanes, two for normal traffic and the
nearside lane reserved for buses, columns 12-15 should be coded ‘ B2’; if the bus
lane were down the centre of a 2-way road (e.g. a tram line) or in the offside lane
of a 1-way road then it would be coded ‘ 2B’. Similarly ‘ B2B’ would represent
four total entry lanes with bus lanes in both the nearside and offside of the
roadway.
5120257 / Apr 15 6-45

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

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

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

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

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

The input parameters referred to as LCY, NUC, GAP/GAPR and GAPM are used
to over-ride the parameters of the same name set as, in effect, “global”
parameters under &PARAM. If the input value is zero - or much more simply left
blank - then the global value is taken. See Section 15.15. (N.B. columns 36-40
refers to either GAPR or GAP depending on whether the node is a roundabout or
not.)
Note that turn-specific values of GAP (for priority junctions and traffic signals, not
roundabouts) may also be set using the X-file; see 6.13.
Note also that all gaps are input as integers representing tenths of seconds so
that if 15 were input this would be interpreted as 1.5 seconds. It is not possible to
input, say, 1.53 within the 5 columns provided in order to obtain extra precision
although the extra precision is possible when the gap is either defined globally
through namelist or turn-specific in the X-file
6.4.11 Link Stacking Capacity

The link stacking capacity is defined as the number of pcus which would cause a
queue to extend into the previous junction. If left blank or zero the stacking
capacity is calculated by:
Equation 6.1
STACK = LANES *IDIST / ALEX
5120257 / Apr 15 6-48

Section 6
with the direct addition of any nearside or offside flares, i.e., FLAREX + FLAREF
(see 6.4.14).
Indeed much of the time the stacking capacity may just as well be left blank since
STACK is only used to model blocking back - see Section 8.5. As long as the
default value exceeds the queue on a link it has no effect whatsoever on the
simulation. However, if it does enter into blocking back calculations, it may be
important to set a “true” value, see 8.5.7, or to consider possible “corrected”
values to deal with possible intrinsic problems with the modelling logic; e.g., see
8.5.5.6.
If ALEX is zero, implying infinite capacity, then STACK is, in effect, infinite,
although the actual value stored will be zero. Hence setting ALEX to zero totally
suppresses blocking-back and in this case there is no real need to define STACK
at all.
The position of STACK on the record is clearly rather strange; logically the A-node
number should come first. The reason for this is historical as early versions of
SATURN did not include STACK. However, since in most cases the “stack field”
can be left blank, the ANODE will appear first.
We may also note that a negative stacking capacity may be input in order to
indicate one particular property, which is that a “link chain” (see 5.1.12) can not
be extended through this link. This has particular applications for blocking back
(see 8.5.5). If a negative value is input the absolute value defines the true stacking
capacity and a separate note is made of the negative input. Note that normally
negative stacking capacities would only be applied at 2-arm nodes where chains
are feasible although more complex nodes may also feature in chains.
6.4.12 Simulation Link Speed Flow Curves and Capacity-Restraint

Generally speaking, simulation links have fixed travel times, assumed equal to
their free flow or cruise travel times (see 6.4.5) and, in effect, infinite capacities.
However it is possible to define link speed-flow curves for simulation links in the
same way that one may define link speed-flow curves for buffer links. Equally,
explicit capacities may be defined on simulation links themselves (as opposed to
capacities set by downstream junctions).
This facility is extremely useful for modelling long motorway-style links where
delays tend to be dictated by conditions on the link itself as opposed to junction
properties. Indeed speed-flow curves may be the only way to adequately model
such links. It may also be useful in urban conditions where, e.g., on–link parking
or width restrictions may severely restrict the flow of traffic mid-link such that it
becomes lower than that at the stop-line.
However it is also possible to abuse the facility as noted below, 6.4.12.1.
To define link capacity restraint you must first insert a ‘*’ in column 11 of the link
data record (type 2), indicating that an extra record (type 2B) is to be inserted
before the next link data record, containing speed-flow data. Format conventions
(fixed columns etc.) for data on 2B records are given in 6.4.1. (N.B. Do not
include a * if LANES = 0, ie., columns 12-15 are blank or zero, and the link is
therefore one-way outbound. This can sometimes be forgotten if an in-bound link
is converted to out-bound only.)
5120257 / Apr 15 6-49
Section 6
Note that the additional link record 2B may also be used to define parameters
such as TAX, FLAREF and FLAREX; see 6.4.14.
More specifically the extra record gives:
1) the free flow travel time t 0 in seconds / free flow speed in kph / free flow
delays in seconds
1) the time at capacity t C in seconds / capacity speed in kph / delays at
capacity
2) the link capacity C (sometimes referred to as the “pinchpoint” capacity)
3) An ‘S’, ‘T’ or ‘D’ to indicate speeds, times or delays above
4) A “power” n
5) A “link index” or “capacity index” (optional – default is 0); see 5.1.9.
such that link travel time as a function of flow V is defined by:
Equation 6.2
t (v) =
t0 + AV n v<c
where the parameter A is chosen such that t(C) = t C . For V > C the time is
constant, t C .
This data has two effects: (1) it determines the flow-dependent (cruise) travel
time/speed on the link itself; and (2) it may reduce the turn capacities at the
downstream junction. See Section 8.4.4 for further details.
Note that the time/speed defined in columns 16-20 of the link record 2 is
disregarded if an extra speed-flow record is used. However a warning is
generated if a non-zero link time/speed does not fall within the upper and lower
limits set by the speed/flow times/speeds at free flow and capacity.
Note that by leaving entries (1) through (4) blank but coding a (positive) capacity
index allows one to use a “default” speed-flow curve as defined within the 33333
buffer records. See 15.9.5.
The use of the single characters S or T in column 29 to denote “Speeds” or
“Times” is new in 10.5. If column 29 is left blank then the choice is set by the
parameter SPEEDS as on the normal simulation link records. Previously SPEEDS
was always used (so that some care may be needed with pre 10-5 network data
files). A third choice, D (see 6.4.12.2), was added in 11.2.10 in 2013.
We may note therefore that the same data columns and conventions are used in
the 11111 simulation link speed-flow curves as in the 33333 buffer network link
records (although certain entries in the 33333 records such as the A-node and the
B-node are ignored here), making it simple to transfer 33333 data directly into the
11111 records.
We also note that if (and only if) the link is to an external simulation node then the
same information may also be input via the 33333 buffer records; see 15.13. If
both occur for the same link then FIFO (see 6.15) decides which to select.
5120257 / Apr 15 6-50

Section 6
However, it must be stressed that in such cases it is strongly recommended that

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

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

Post 10.4 it is possible to define minimum and maximum times for each green
stage which will be applied during the signal optimisation procedures (see 15.31).
The data is input under simulation node Record Type 3 (6.4.1) in the “first” data
field, i.e., the columns up to and including column 15. The full data format is of
the form:
Tmin < T > Tmax
Or, alternatively:
Tmin < T < Tmax
where the first version is, for reasons given later, the “standard” version although
the second may appear more intuitive. E.g., 10<20>30 or 10<20<30 would both
imply a stage length of 20 seconds with a minimum of 10 and a maximum of 30.
If, on the other hand, only a single minimum or maximum stage time is to be set
the correct formats are respectively:
T min < T
&
T > T max
The rationale behind using a < symbol for “minimum” and > for “maximum” is that
otherwise an input field such as 20<30 could either be interpreted as a green time
of 20 seconds with a maximum of 30 or as a green time of 30 with a minimum of
20. Thus 20<30 implies that a minimum stage length is being set (T min = 20; T =
5120257 / Apr 15 6-52
Section 6
30) whereas a maximum stage length would need to be written as (somewhat

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

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

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

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

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

Data for the simulation centroid connectors (as opposed to centroid connectors in
the buffer network) are preceded by a single record with a 2 in column 1 (or
22222) and terminated by a single record with 99999 in columns 1 to 5.
At least one connector must be specified for each centroid and no more than six.
Centroids need not be input in numerical order as the program automatically sorts
them.
For further information on centroid connectors please see 5.1.6, 5.1.8 and 16.6. In
particular, note that the method of connection differs between connections to
“internal” and “external” simulation links.
Note as well that use of the AUTOZ option (see 15.12) allows the data input here
to be either reduced or eliminated altogether:
Cols Description
1-5 Zone or centroid number or ‘name’
6 -10 First or A-node on the connected simulation link
11 -15 Second or B-node on the connected link
16 -20 A-node for the second connector (if present)
21 -25 Second B-node Etc
NOTES:
1) It is not necessary to include both an A-node and a B-node. If one if
missing, i.e. blank or 0, the following rules apply:
2) If only the A-node is given then the zone is connected to all links FROM
A; i.e., the blank B-node is treated as a “wild card” representing all
possible values of B.
3) If only the B-node is given then the zone is connected to all links TO B;
i.e., the blank A-node is treated as a “wild card” representing all possible
values of A.
4) If A = B then the zone is connected to all links both TO and FROM A; i.e.,
situations (2) and (3) combined,
5) However if either the single A-node or B-node is an external simulation
node then the connections are made to all links from A/B to internal
nodes. Since in most cases external simulation nodes are only
connected to a single internal node the only information really required by
the program is the external node and including a second node is largely
redundant.
6) It is also possible – although not recommended – to attach zones to the
simulation network via an intermediate buffer node, in which case the
connectors are contained within the 33333 data records. See 16.6.3.
5120257 / Apr 15 6-55

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

These records have a dual purpose: (i) to define the structure and properties of
the link-based buffer network; and (ii) - generally a secondary objective - to define
extra link-based data for simulation links (as described in Sections 15.13 and
15.14).
The data is preceded by a single record with a 3 in column 1 (or 33333 in cols 1 -
5) and terminated by a record with 99999 in columns 1 to 5.
Each link in this section, whether ‘real’ or ‘centroid connector’, is described by
either a single record (if KNOBS = 0) or two records (if KNOBS > 0 and KONAL =
F; see Section 15.14) with the following format:
(N.B. An alternative format applies under the DUTCH option - see Section 15.20
– or a “Do It Yourself” format may be set – see Section 15.35.)
RECORD 1
Cols. Description
1 A ‘C’ if the following node refers to a zone (see note (13)), a ‘D’ if this is a
default speed-flow curve (see note (8)) or a ‘V’ to indicate a maximum
vehicle speed under CLICKS (see note (16).
2 -5 The A-node for the link.
6 A ‘C’ to indicate a zone number following.
7 -10 The B-node for the link.
11 -15 The link time (in seconds) or speed (in kph) under free-flow conditions.
16 -20 The link time (in seconds) or speed (in kph) at capacity.
21 -25 The one-way link capacity (in pcus per hour)
28 A one-way/two-way indicator - see note (3).
29 An ‘S’ if speeds were defined above; otherwise times are assumed.
31 -35 The link distance (in metres).
36 -40 The power to be used in the link flow-delay curve. (FORMAT - F5.1 –
therefore, by default, the decimal point should appear in column 39 but
see note (4).)
43 -45 A “link index” in the range 0-999; see 5.1.9.
46 – 80 (Optionally) up to KNOBS extra data items - see note (9).
5120257 / Apr 15 6-56

Section 6
RECORD 2 (OPTIONAL); SEE NOTES (9) TO (11).

Cols. Description (FREEKY = F; FORMAT 8F10.2)
1-10 First piece of extra data for link A-B
11-20 Second piece of extra data etc., etc. with decimal points in columns 8, 18,
etc.
NOTES:
1) A capacity of zero - or blank - is assumed to imply infinite capacity -
actually recorded as 99999 pcu/hr – and fixed times/speeds as set at free
flow (so that the capacity time/speed is ignored). It is further assumed
that all centroid connectors have fixed travel times (set by the free-flow
field) and an infinite capacity, i.e. 99999. (If the free flow and capacity
times are set equal with a finite capacity then the times are fixed but only
up to capacity, beyond which point they increase linearly as per equation
(5.1.b))
2) Link capacities in the buffer network are not the equivalent of saturation
flows in the simulation network in that link capacities take into account
the reduction in capacity due to traffic signals at the down-stream
junction, give-ways, etc., whereas simulation saturation flows are based
purely on road geometry and ignore all such factors as above.
3) If column 28 contains a 1 this implies that the link (or centroid connector)
is one-way from A-node to B-node; a 2 implies that it is two-way. If
column 28 contains any other number - or more commonly if it is left
blank - then the value is taken as that defined by IFRL and IFCC (See 6.3
above). Hence by default all input real links are assumed to be one-way
(since IFRL = 1) and centroid connectors are two-way (IFCC = 2). If two-
way, all link properties are assumed to be the same for both directions.
4) If columns 36-40, the link flow-delay power, is left blank - and capacity
restraint is indicated - then the default value defined by BCRP is
assumed. (Note that it is not 100% essential that the decimal point falls in
column 39; FORTRAN READ statements are forgiving and will correctly
read a decimal in any of the 5 columns. This means that you are not
restricted to a single figure after the decimal point. See 2.8.3)
5) The possible uses and applications of the link index in columns 43-45 are
explained in Section 5.1.9. See in particular note (8) below. If the
parameter BEAKER is .TRUE. then the index is also associated with all
(simulation) turns out of the link.
6) If either the A-node or the B-node is an internal simulation node this link
will not be added to the buffer network. (This happens very commonly
when a network is originally set up with buffer links defined under 3333
which are then re-defined as simulation nodes and added to the 11111
records). However a buffer link can join a pure buffer node to an external
simulation node or two external simulation nodes.
5120257 / Apr 15 6-57

Section 6
7) Excluded simulation links - as defined above - are not totally ignored in

that if A-B has previously been coded as a simulation link the capacity
index, as well as any extra data input on Record 2, is associated with the
simulation link. See Section 15.14 for further details. Equally certain
data for out-bound external simulation links may be defined as well - see
Section 15.13.
8) An option introduced in SATURN 8.5 allows “default” speed-flow curves
parameters (speeds, capacity and power) to be associated with a
capacity index and to “replace” blank values on subsequent input
records. These are indicated by a D in column 1. See Section 15.9.5 for
full details. Note that their format may be either fixed column or free-
format (CSV) depending on whether the &PARAM Namelist parameter
DCSV = F or T, and if fixed column must match the normal columns in
use on link records (ie are subject to DUTCH = T if set).
9) KNOBS data may be included within the 33333 records either as an extra
formatted record following each link record or as free-format data at the
end of the normal link buffer data (i.e., columns 46 and beyond)
depending on whether KONAL = F or T. Note that with KONAL = T no
data need appear, in which case it is assumed that all values equal zero,
whereas with KONAL = F the second record must always appear (and a
blank second record would equally be interpreted as all KNOBS data
equal zero). See Section 15.14 for further information on the use of
KNOBS data, in particular on the (highly recommended) input of KNOBS
data from an external text file (FILKNB) as an alternative to including
them on the 33333 data records as described here.
10) Note that when the second KNOBS records are required it is quite easy
to forget and leave a record out, in which case the next link record will be
read as though it were a KNOBS record and the buffer link will be
ignored. Various error checks are included to try to detect this happening
and to print appropriate warning messages. This may result in a
FORTRAN reading error which is semi-fatal.
11) If the parameter FREEKY is set to .TRUE. then data from the second
KNOBS data records (if used, i.e., KONAL = F) is read as “free format”,
e.g., it may be input as CSV (Comma Separated Variables).
12) The two input values for times/speeds and for distances (i.e., columns
11-15, 16-20 and 31-35) are implicitly integers but may explicitly include
decimal points if greater accuracy is required. The main requirement is
that the data is entirely contained within the same columns. See 2.8.3.
13) The requirement to use a ‘C’ in columns 1 or 6 to indicate a zone may be
relaxed by using NO333C = T in &PARAM which implies that any “node”
whose number in less than or equal MAXZN is a zone. This may be a
useful option in converting data sets obtained from other suites although
its long-term use is not recommended.
14) Methods exist to change the input formats to user-set conventions; see
15.35.
5120257 / Apr 15 6-58

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

Links and/or turns may be banned to certain classes of vehicles or else
“penalised” (in either the sense that a HGV might take longer to make a turn than
a car would or a monetary toll would be levied on HGV’s). The term “restricted”
applies to both. See 5.1.5.
Restricted links/turns are input one per record (but see note (7) below) preceded
by a 4 in column 1 (or more usually ‘44444’) and terminated by 99999 in columns
1 to 5: (N.B. Different format under the DUTCH Option - See Section 15.20.)
Cols.1 – 5 The A-node, A

Cols.6 - 10 The B-node, B
Cols.11 - 15 The C-node, C (blank or 0 in the case of a link)
Cols. 16 - 20 The ban/penalty/toll indicator for user class 1,
Cols. 21 - 25 Ditto, for user class 2,
Cols. 26 - 30 etc. for as many user classes as specified by NOMADS.
NOTES
1) Include the third node C in order to specify a turn A-B-C; otherwise link A-
B is assumed.
2) Centroid connectors cannot be restricted, but links in both the simulation
and buffer networks plus turns in the simulation network may be included.
N.B. In general turns in the buffer network CANNOT be restricted as
they do not explicitly exist in the assignment network although, post
Release 11.1, they may be effectively banned and/or penalised if
SPIDER = T; see 15.56.7.3.
3) A banned link or turn is indicated by a negative indicator, 0 implies no
effect while a positive number is taken to be a penalty in either time or
monetary units as explained next.
4) A “toll” (i.e., a monetary penalty) is differentiated from a pure time penalty
by the inclusion of either a $ or & symbol preceding the numerical value.
The absence of either implies a (possibly notional) time penalty whose
units are assumed to be seconds. Tolls are assumed to be given in units
of, say, pence rather than pounds so that a toll of five pounds would be
indicated by £500 (or $500). For further information see Section 20.
5) “Time” penalties may represent virtually anything the user may wish them
to represent. For example, they may be purely notional times designed to
5120257 / Apr 15 6-59
Section 6
deter non-local drivers from using a local rat-run, or they may be “real” in
that they represent the extra time for a lorry to drive down a windy road.
Under certain circumstances, see 15.24.4, options exist to include them
or exclude them with “normal” time. However, in terms of output statistics
of total times or speeds, penalty times are not included with “real” times
but are listed separately.
6) Buses and other “fixed” flows which follow pre-defined routes are not
affected by restrictions. Hence banning a turn or link to all classes is
equivalent to defining it as a bus-only turn/link.
7) If you have multiple vehicle classes (NOMADS > 1), a banned indicator
of -1 refers only to a single user class, whereas values of -2 or less are
taken to imply that the ban applies equally to all following user classes.
For example if you wish to ban a turn for all user classes -2 in columns
16 to 20 (31 to 35 under DUTCH) would suffice. (Presumably in this
case the turn would be bus only.)
8) Under the usual option of a single user class only columns 16-20 (31-35
under DUTCH) are required to specify the ban/penalty.
9) If there are more than 10 user classes more than one record is required
per link or turn such that each record contains 10 entries in columns 16-
65 (31-80 under DUTCH). Columns 1 to 15 (30) on subsequent records
are left blank. Note that this applies whether or not the subsequent
record contains nothing but zeros (or blanks) following a -2 entry. See
Section 6.14 for an annotated example.
10) Total output statistics of, e.g., total pcu-hrs for time penalties and total
pcu-pounds for tolls may be viewed via the simulation/buffer outputs
under SATLOOK; see 11.11.4 and 17.9.
6.8 Node and Zone Co-ordinates/Supplementary Data: the ‘55555’

Records
This data section, preceded by a record with a 5 in column 1 (or more usually
‘55555’) and terminated by a 99999 in columns 1 to 5, contains both co-ordinates
for zones and/or nodes as well as - optionally - certain supplementary data:
specifically sector numbers for zones. The role of co-ordinates is described in
Section 5.1.9.
Very often co-ordinate data may be obtained directly from other data sources, e.g.
GIS systems, and “converted” into the appropriate SATURN format. The source
and conversion method should be recorded using the parameters IEPSG,
IXSHFT, IYSHFT and XYFACT (see note (12) below). Note that it is also possible
to redefine the SATURN input format (see note (6) below) to accommodate
different data sources.
Data for both simulation and buffer nodes and zones are input, one per record,
according to the following format:
(N.B. A different format is required under the DUTCH Option - see Section 15.20
or if FREEXY = T - see note (10) below.)
5120257 / Apr 15 6-60

Section 6
Cols. Description
1 A ‘C’ if columns 2 to 5 contain a zone number (but see note 11);
or ‘S’ to denote a sector; otherwise blank or part of the node number to
denote a “real” node.
2 -5 The node, zone or sector number; see note 7)
6 -10 Its X co-ordinate (by default as an integer); see notes 6) and 10)
11 -15 Its Y co-ordinate (as an integer)
16 -20 (a) For zones, its corresponding sector number
(b) For nodes, no extra data is currently processed
NOTES:
1) All input co-ordinates should be positive since nodes whose co-ordinates
have not been defined are given negative values in order to identify them.
2) If a node is not assigned co-ordinates the program attempts to
“extrapolate/interpolate” its co-ordinates from those of its neighbours.
Users should check the co-ordinates so assigned and, if happy with
them, edit them into the .dat file. (The output format in the LPN file
should be compatible with the required input format.)
3) The units used for co-ordinates are arbitrary but their “size” in metres
should be specified by XYUNIT. E.g., if XYUNIT = 10 then it is assumed
that an increment of 1 in a co-ordinate corresponds to 10 metres “on the
ground”. However, see 15.43.2, it is strongly recommended that a
system based on Ordinance Survey (or equivalent) conventions is
adopted with co-ordinates defined to the nearest metre (so that XYUNIT
= 1.0).
4) Section 5.1.7 defines sectors. If either the parameters IROCKY or TFL
have been used to define “default” sector names any data given here
“over-rides” that definition. If the sector field is left blank, however, the
value given using IROCKY and/or TFL is assumed.
5) In addition to defining the sectors associated with zones this data section
is also used to explicitly define X, Y co-ordinates for sectors. Sectors not
explicitly defined have their co-ordinates set to the arithmetic mean of
their zones.
6) The precise columns (beyond column 5) occupied by the node X,Y co-
ordinates and their format may, in fact, be re-defined by the user via the
namelist parameter “XYFORM”. Thus using 5 columns each with no
decimal corresponds to the FORTRAN “format” 2I5; if XYFORM = 2F10.2
then the X co-ordinate would be contained in columns 6 to 15 with a
decimal in column 13, while the Y co-ordinate would be in columns 16 to
25, decimal in column 23. See also 15.35 and note 10). In all cases the
first (left hand) column in each field is the one in which a ‘C’ or an ‘S’ is
inserted. These are not explicitly mentioned in the format. (Note that
formats such as F6.0 are much better given as I6 since the former
“wastes” one column by including a final decimal point while I6 potentially
5120257 / Apr 15 6-61
Section 6
uses all 6 available columns.). See also note 10) below for alternative
“free formats”.
7) With the (default) format as given zones are restricted to four digits (to
accommodate the C in the first column of five), although there are ways
to allow five digits. Nodes however may use the full five columns (since
they do not need an indicator) and have up to five digits. But see note
(10) for alternative formats.
8) Note that data described above as being in columns 16-20 strictly
speaking must occur in the 5 columns immediately beyond those used for
X,Y and therefore depend on the format used.
9) Nodes within this section which have not already appeared in the
simulation or buffer networks are, by default, ignored and generate
warnings. Thus you may apply a set of coordinates for a full network to a
cordoned sub-network and the extra nodes are excluded. However if the
parameter ATLAS (6.3.1) is set to .TRUE. all nodes in the 55555 data set
are recorded as part of the map network so that they may be used, e.g.,
as part of network editing within P1X; see 18.5.2.
10) If the parameter FREEXY=T (see 6.3.1; recommended) then all the data
records are given in “free format”, i.e. no fixed columns and with each
data entry distinguished from its neighbours by either a blank and/or a
comma (but with the C or S only in column 1). This has several
advantages:
♦ node and zone numbers may be of any number of digits

(independent of DUTCH);
♦ ditto the X, Y values which may also contain (any number of)
decimals;
♦ communication with other data base systems (e.g. spreadsheets or

GIS) is made easier.
11) The requirement to use a C in column 1 to identify zones may be relaxed
by setting NOXYC = F in &PARAM, in which case any “node” number
less than or equal MAXZN is automatically firstly interpreted as a zone
but then, if it cannot be identified as a zone number, it is interpreted as a
node (a new rule under 11.2.06; previously all numbers <= MAXZN were
assumed to be zones). This may be useful in converting data from
external data sets although its long term use is not recommended.
12) To meet the requirements for SATURN coordinates, it is often necessary
to "convert" from the external source data. The style of the source and
conversion can (and should) be stored in the network for future use.
There is an international body that maintains an EPSG 1 dataset of
geodetic systems, which holds the referencing of common systems (like
1 The European Petroleum Survey Group created a dataset of geodetic parameters in 1985 for internal use of its
members. In 1993 the dataset was made public as reference data to the then Petrotechnical Open Software
5120257 / Apr 15 6-62

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

Using Xe,Ye to represent the external/EPSG coordinates, and Xs,Ys the
SATURN ones, then the parameters correspond to the calculation:
Xs = (Xu - IXSHFT) / XYFACT
Ys = (Yu - IYSHFT) / XYFACT
The defaults for XYFACT, IXSHFT and IYSHFT allow the SATURN
coordinates to be identical to the source system.
6.9 Fixed Routes (E.g. Buses): the ‘66666’ Records
6.9.1 General Principles and Format

Routes in SATURN are defined by a fixed sequence of nodes through either the
simulation or buffer networks and may represent either:
♦ Bus routes (or other transit services such as trams), or
♦ Routes to be used for later analysis, e.g. timed routes from moving
car observer surveys
The two are differentiated by assigning a frequency of zero (columns 7-10 below)
to non-bus routes.
Bus routes are “seen” by SATURN as fixed loads to be added to the “fixed”
assignment flows (see 5.5.3.). One bus per hour is equivalent to ‘BUSPCU’ pcus
per hour. Indeed, as note in 5.5.3, it may be possible / convenient to define bus
flows as pre-loaded flows (15.5.5 or vice-versa. For example, if you have a very
large number of low-frequency bus routes it may be simpler to simply aggregate
all their individual flows by link and input them as fixed pre-loaded flows.
Corporation data model (POSC has since rebranded as Energistics). In 2005 the European Petroleum Survey
Group was reformed as the Surveying and Positioning Committee of the International Association of Oil and
Gas Producers (OGP). Maintenance of the geodetic parameter database now resides with OGP Surveying and
Positioning Committee's Geodetic Subcommittee. For continuity reasons the dataset name remains as the EPSG
Geodetic Parameter Dataset, or in short the EPSG Dataset.
5120257 / Apr 15 6-63

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

1) If UPBUS = F (its default) bus routes which begin or terminate on links
inside the simulation network must do so in exactly the same way as
flows to or from zones – see 5.1.8; i.e., they are assumed to commence
at the downstream end of their first link and to terminate at the upstream
end of their last link. Thus they contribute to both the entry/exit flows on
their first/last links. For example a bus route through nodes A, B, C, ...
X, Y, Z (with all nodes being internal simulation nodes) would first appear
as a fixed volume on turn A-B-C and last appear on turn X-Y-Z. Hence
there is no flow on either link A-B or Y-Z.
If, however, UPBUS = T then the buses are deemed to start at the first
upstream simulation node and to terminate at the last downstream
simulation node. Hence, in the above example, there would be a bus
flow on both A-B and Y-Z as well as on the relevant first/last turns.
See also 6.9.4 on “zero-flow” routes where, in effect, the presumption is
that UPBUS = T.
5120257 / Apr 15 6-64

Section 6
2) If, however, A and Z were external simulation nodes then the first and
last flows would always be on links A-B and Y-Z since centroid connector
flows are allowed to terminate at external nodes (independent of
UPBUS).
3) The above restrictions only apply to the ends of routes within the
simulation network; they do not apply to sections of route through the
buffer network.
4) Missing node numbers are allowed in the sense that blanks may appear
in the list of nodes and will be ignored by the program. This is a useful
facility if it is known in advance that new nodes are to be inserted in some
future networks; without blanks file editing by insertion can be a problem.
Strictly speaking, therefore, cols 11-15 (if used) give the position of the
LAST node to be read.
5) If FOZZY is .TRUE. and co-ordinates have been defined for all nodes,
then if two successive nodes do NOT constitute a link, the program will
“interpolate” the set of nodes which lie nearest to a direct line between
those nodes (see 15.18). Thus if a route follows a straight line (more or
less) then it is not necessary to define every node along the line, only the
first and last nodes. Hence in addition to the first and last nodes in a
route it is only essential to define nodes at any “kinks” in the route.
This is a very useful facility and its use is strongly recommended.
However please note that in order to use it you must first have defined
node co-ordinates.
In addition, post 10.9, if the “direct line” method fails and MINDER = T, a
path is generated based on the minimum distance path between the two
unconnected nodes.
Note that the interpolated routes take one-way streets into account. This
means, for example, that a route which is defined to be two-way (T in col.
6) may have a different set of interpolated nodes in the two directions.
6) If EZBUS is .TRUE. then the nodes through which the route passes may
be defined in a “free format” whereby:
♦ Cols 1-10 remain the same on the first record (i.e., fixed column
format).
♦ Cols 11-15 are ignored; i.e., leave them blank.
♦ Cols 16-80 contain a list of nodes, not necessarily in fixed columns,

but separated by one or more spaces or commas (CSV).
♦ If there is insufficient space to include all nodes on the first line

further continuation lines may be used, identified by blanks in
columns 1-15 followed by the node numbers in columns 16-80.
Note that this option may be combined with the FOZZY option so that the
nodes need not be consecutive; in fact this is certainly the easiest way in
which to define routes.
5120257 / Apr 15 6-65

Section 6
If, however, EZBUS is .FALSE. (the default although not recommended)

then the entry in columns 11-15 is necessary to specify the number of
nodes which will follow or, strictly speaking, the number of LINES which
follow. Thus, for example and assuming a maximum of 13 node entries
per line with DUTCH = F, any number between 14 and 26 will imply that
two lines are to be read but, since blank node entries are ignored, the
first line might contain only 6 entries and the second, 4, in which case the
total number of nodes entered is 10. If, however, you had entered 10 in
columns 11-15 only one line and therefore 6 nodes would have been
read.
Generally speaking data prepared under the “fixed column” rules will also
be correctly read under free format provided that there are no 5-digit
node numbers which “run into one another”.
7) Column 6 may optionally contain various (normally upper case) letters to
denote various options. Thus if Col 6 = 'T' (for “Two-way”) and the nodes
list is A… Z then a second return route will be added with node list Z… A;
i.e., the reverse direction. If however col 6 = ‘R’ (for “reverse”) then only
one route is assumed but one whose nodes are Z… A.
The R option allows one to code a 2-way route which differs marginally in
the two directions. Thus if the “out” direction is A… IJL…Z and the "in"
direction is Z… LKI… A then one may code it using R as A… IKL… Z;
i.e., the same as the out direction apart from one node.
Similarly a D or an F may be used to denote “route deletion” or
“frequency editing” respectively; see 10.9.6 for further details.
8) If either EZBUS or FOZZY is .TRUE. then a complete “dump” of the route
definitions with every node included in fixed columns is obtainable as an
output file ‘network.bus’ if the parameter BUSKER is set to .TRUE.
9) If a single bus routes uses more than 78 records / rows any records
beyond the 78th are ignored unless EZBUS = T. In that case the program
attempts to “compress” the input records by merging together very short
records which contain, e.g., only 1 or 2 nodes into single records. This is
not (yet) possible with EZBUS = F since the data compression ignores
any fixed column conventions.
Equally, under BUSKER, if the “fixed column” output format would require
more than 78 records the data is output in a compressed free format
(with a single space between each node) in order to fit within 78 records.
10) Routes are allowed to execute U-turns at all nodes, whether simulation or
buffer, roundabout or otherwise (provided, of course, that the entry/exit
road is two-way). Such turns are effectively “free turns” in the sense that
they contribute zero delay to the total route travel time. Explicitly banned
turns in the simulation network are, of course, never allowed in routes.
(This feature is commonly used to represent the “terminus” for a bus
route if the complete round-trip route is coded rather than as two
separate sections.)
5120257 / Apr 15 6-66

Section 6
11) Routes are also allowed to exit the network from one “stub node” and re-
enter at another. This may happen if the network has been cordoned and
part of the actual route lies outside the coded section. As with U-turns no
extra time or distance is added in these cases.
12) In addition routes are also allowed to exit the network from one node and
re-enter at another (non-adjacent) node by inserting a “wildcard” node
number between the two nodes. The wildcard number is defined by the
&PARAM Namelist parameter KANGA (signifying a “jumper”), default
9999. Thus a sequence of nodes A B C 999 F G H would imply that the
route left the coded network at C and reappeared at F; for example it
might be using relatively minor roads which are not included in the coded
network
6.9.3 Bus Companies

Multiple sets of route records initiated by a 66666 and terminated by a 99999 may
appear and the routes within each set are referred to as being members of a
specific “bus company”. Note that this term need not have anything to do with
ownership or organisation; the different sets may be used, for example, to
distinguish double-decker, single deck and mini buses. Output bus statistics are
presented both “in toto” and disaggregated by company.
Each bus company may have a specific value of the BUSPCU factor input under
&PARAM, see 6.3.3, as indicated by a subscript. Thus BUSPCU (2) = 1.5 would
assign a pcu factor to bus company 2. Unless otherwise set an input value of
BUSPCU (or its default unsubscripted) applies to all companies.
Each “company” may be assigned an alpha-numeric title by including it after
column 5 on the 66666 record and to a particular vehicle class (5.8.2) by
IBUSVC( )
6.9.4 “Other” Routes

It is possible to define routes for purposes other than defining bus flows, for
example to define a standard route used by moving car observers so as to
facilitate comparisons with modelled travel times post assignment. Such routes
are defined in the normal way but with a frequency equal to zero. They may also
include information on “timing points” as described in 6.9.5 below.
Zero-flow routes differ from ordinary “bus” routes in that they are always (post
release 10.9.24) to start and end at the first and last coded links; i.e., they always
behave as if UPBUS = T as explained in note 1) in 6.9.2. Thus, for example, a
timing point at the final node will always be recognised.
Note that the term “bus company” also applies to sets of pure routes, i.e. those
with frequency zero. It would therefore seem sensible for the user to include non-
bus routes as a separate “company” within a distinct 66666 block
6.9.5 Route Timing Points

A “timing point” is defined to be an input time (in seconds) to travel from the start
of a route to a particular node in that route. The precise definition of where the
timing point is taken is of course up to the user but it is recommended that they
5120257 / Apr 15 6-67

Section 6
represent the time to cross the stop line as opposed to the time to reach the back
of the queue. They would therefore include any delayed time at that intersection
and therefore their value should depend upon which exit turn is to be taken next,
i.e., the next node in the sequence. Their application for validation studies is
described in 11.7.2.
The starting point (zero time) for cumulative times is assumed to be the same
point at which a vehicle (bus) on the route would enter the network. Thus – see
note 1) in 6.9.2 – this would be the downstream end of the first link if UPBUS = F
or the upstream end (i.e., the first coded node) if UPBUS = T. However, if the flow
on the route is zero (which is the natural value for pure timing routes) then timing
always starts at the upstream (first) node and equally ends at the final simulation
node. See 11.7.2.2 for an application within Validation.
Timing points are entered as integer values enclosed in brackets after the node to
which they refer appears. They may only be entered when in “free format mode”,
i.e. EZBUS = T. Thus the node sequence
52 54 55(72) 56
indicates that the time to reach node 55 is 72 seconds. Note that not all nodes
need to have timing points and that it is not valid to associate one with the first
node in a sequence (which, by definition, is zero). Spaces between the node
number and ( or within ( ) are ignored.
Timing points are recorded on the .ufs files as part of the route definitions and
may be analysed later; see 11.7.2.
In addition a second input value within brackets indicates a “plus-minus range” of
observed timing points. Thus
52 54 55 (72, 16) 56 …
would imply 72 + 16 seconds to reach node 55. If the second figure is omitted it is
taken as zero. The definition of the “range” is deliberately loose since, at the
moment, it is only really used to provide a vertical bar on time v distance plots to
give an indication of the likely spread of route timings.
6.9.6 The Use of Delete and Frequency Records to Edit Routes

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

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

Specified values of volumes on certain links and/or turns may be input in fixed
columns (see note (13) for alternative free format inputs) as follows, preceded by
a 7 in column 1 (or more usually ‘77777’) and terminated by 99999 in columns 1 to
5:
Cols. 1 - 5 The A-node, A
Cols. 6 - 10 The B-node, B
Cols. 11-15 The C-node, C (blank or 0 in the case of a link)
Cols. 16-20 The first specified volume in (INTEGER) pcus per hour (see note 13).
Cols. 21-25 The second volume ...
Cols. 26-30 up to MCCS volumes (where the different volume fields might refer to,
e.g., different vehicle types, different time periods etc. etc.).
NOTES:
1) Unlike other data input sections the ‘77777’ initialisation record may be
repeated more than once, so that more than one “set” of counted links
may be defined. Each set commences with a ‘77777’ record and is
terminated by a ‘99999’ record. The maximum number of such sets is
now (10.7) 120.
2) Each set of 77777 counts is identified within SATURN by consecutive
numbers 1, 2, 3 ... which may be referred to within subsequent
programs. Thus a particular set of counts might be associated with a
particular “screen line” or cordon. Note the same link/turn may not occur
in the same count set although, post 10.7, counts may be repeated in
different count sets; multiple values must be handled using MCCS.
3) In addition an informative title may optionally be included on the 77777
record following the 7's giving, e.g., a screen line name to be associated
with the count set to follow.
5120257 / Apr 15 6-69

Section 6
4) Turn volumes as specified by nodes A-B-C may only be defined for turns
within the simulation network; links specified by A-B may exist in either
the simulation or buffer networks.
5) Volumes on centroid connectors may not be defined.
6) Counts on simulation links are assumed to refer to the “actual mid-link”
flows - see Section 15.16.
7) It is generally assumed that any counts input here refer to TOTAL vehicle
flows, although in certain circumstances elsewhere in the Suite flows for
a particular class of vehicles (e.g., cars, HGV’s, etc.) are required; see,
for example, Section 13.4. The MCCS different set of counts might
therefore be used to define flows by vehicle class. Alternatively the
program-specific flows may need to be input separately to that particular
program.
8) In any case the counts should always be given in units of pcus/hr. Or, at
any rate, the same units as all the other flow components such as trip
matrices, saturation flows, etc., which, if desired, could be in
vehicles/hour. See 15.17.
9) Strictly speaking counts are stored as “reals” and may therefore be input
as reals (e.g., 654.0 instead of 654) although, generally, they are input as
integers on the assumption that it is difficult to define a flow to a precision
of better than 1 pcu/hr. See 2.8.3
10) The count field MAY be left blank (or set to zero) if the count records are
being used solely to define a set of links for later analysis. Zero-count
records are ignored with certain applications, e.g., a PIJA analysis for
input to SATME2.
11) MCCS is specified under &PARAM (6.3.2) and by default is 1. Values of
MCCS>1 might be used to represent, e.g., multiple counts on the same
links or counts for different user or vehicle classes.
12) Links which cannot be identified for whatever reason (e.g., node not
identified or a non-existent link between two correct nodes) by default
generate a Semi-Fatal Error 437. However this can be downgraded to a
Serious warning (269) if ERRYES(437) = F (see 2.9); this allows the file
to proceed to the assignment stage. Versions10.7 and later only.
13) If a parameter FREE77 is set to .TRUE. under &PARAM the counts in
columns 16+ (31+ if DUTCH = T) are read as “free format” (e.g., CSV)
rather than in fixed columns. This also means that they be written in
either an “integer” or “real” format (i.e., with or without decimals). Plus,
post release 11.3, the whole record including the node definitions is
read as free format, not fixed columns, so that it is now essential that a
value of zero is explicitly included when A-B denotes a link.
14) There are, however, two exceptions to the above rule that the C-node
must always be explicitly included under FREE77, even if it is zero. (1) If
there are only three items in total on the record then it is assumed that
they must be: A-node, B-node plus (single) count. (2) If the first two items
5120257 / Apr 15 6-70

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

These are set by a series of records preceded by an 8 in column 1 (or more
usually ‘88888’) and terminated by 99999 in columns 1 to 5, formatted as follows
(but see Note 12) for an alternative free-format input):
Cols. Description
1–5 User class number (in the range 1 to NOMADS; see 5.8.1)
6–7 The vehicle class for this user class (see 5.8.2)
8 -10 Number of the “stacked” matrix level which contains the trips for this user
class (see 7.3.2.1).
11 -15 Factor by which the above trip matrix is to be multiplied in the assignment
5120257 / Apr 15 6-71

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

16 -20 Value of time in pence per minute (Assumed decimal point in Column 18
but see point 11) below)
21 -25 Value of distance in pence per kilometre (Assumed decimal point in
Column 23 but see point 11) below)
26 -30 Value associated with the first extra “KNOB” data field in units of pence per
“KNOB unit”. See 15.14.3. Assumed decimal in column 28 (F5.2). See
notes (6), (7), (8) and (13). Set as zero (or leave blank) if the KNOB data
field is not part of a generalised cost but is simply additional data as
31 -35 Ditto for the second data field, etc., etc.
and/or
26 -30 User-class SUET value with an (assumed) decimal in column 28 (F5.2).
See note (9).
NOTES:
1) From SATURN 9.4 the 88888 section is mandatory under multiple user
classes, i.e. NOMADS>1. Previously it was optional but it does not seem
to make much sense to have multiple user classes if they all share the
same trip matrix and cost definitions.
2) This data section is not normally required in the “standard” case of a
single user class UNLESS some of the extra (KNOBS) link data are used
to define costs. Parameters PPM and PPK fully specify generalised cost.
3) For further details on all the above inputs please see Section 7.3.
Annotated examples are given in Section 6.14 below.
4) The following default values apply to all user classes not explicitly defined
on these records:
♦ Vehicle class 1;
♦ Stacked matrix level 1;
♦ Factored by 1.00;
♦ Pence per minute equal to PPM as defined under the &PARAM input
or by default;
♦ Pence per kilometre similarly defined by PPK;
♦ Global value of SUET (6.3.3).

5) Equally if columns 16 onwards are left blank, i.e., if there are no cost
definitions provided, the default PPM and PPK values are assumed to
apply to this user class.
6) If, say, the first KNOB field were in units of seconds, then the weighting
value defined in columns 26-30 would be in units of pence/second (in
which case presumably the correct factor would be PPM/60.0). If it were
5120257 / Apr 15 6-72

Section 6
in units of pence already, e.g., it is being used to represent link charges,

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

Section 6
13) Note that negative weights for KNOBS data are (post release 11.2.3) no
longer permitted and will be converted to a positive value. If you wish a
KNOB data item to be used as a negative cost (e.g., to encourage the
use of certain routes) then the data should be set negative, not the
coefficient. See 7.11.2 and 15.14.3.
N.B. The full data file must be terminated by a 9 in column 1 or 99999 in columns
1 - 5. Thus the final TWO records must both contain 9 or 99999, the first to
terminate the last data section and the second to terminate all data.
6.12 Fatal Errors and NAFF UFN Files

Within SATNET there are two levels of “fatal” errors, full and semi-fatal. See 2.9.
Thus a semi-fatal error is one which would prevent the assignment-simulation
stages in SATALL from running properly but would not prevent a network map
description being created which would be sufficient for P1X to display. A (full)
fatal error prevents both SATALL and P1X from running properly.
An output .ufn file from SATNET which contains some semi-fatal but no fatal
errors is referred to as a NAFF file - Not Assignment Fully Fit - and will be rejected
by SATALL and most other programs apart from P1X. The intention is that the
editing facilities within P1X (see Section 18) may then be used to correct the semi-
fatal errors by producing a corrected .dat file. On the other hand this is not always
possible and users may have to manually edit the .dat file, although P1X may
conceivably be used to make the cause of the error more obvious.
Full fatal errors, on the other hand, must be corrected by manually editing the .dat
file. They may be relatively trivial, e.g. a letter appears where numerical input is
required and must be changed by the user, or they may be sufficiently complex
that not even the deductive abilities of SATNET can work out what the user is
asking for.
Note that semi-fatal errors in SATNET will be referred to as fatal errors within
P1X; the (full) fatal errors will, as explained above, never manage to get that far.
Semi-fatal errors and NAFF files were first included in SATURN 10.1.
There are several methods for examining the full set of errors detected by
SATNET in a particular network. Firstly a list appears near the end of the .LPT file;
secondly, a list may be displayed by P1X under information. Alternatively a full list
of all error numbers used appears in the auxiliary file SATTIT.DAT as well as
Appendix L.
6.12.2 Upgrading Warnings etc to NAFF: The WRIGHT Parameter

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

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

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

Section 6
6.13 Extra Input Network File: the X-File

The use of an extra input data file to specify additional network information was
first introduced in SATURN 9.4 to get over problems associated with “congestion”
in the existing network data file formats where basically there were virtually no
spare fields to add additional data items.
In particular the X-file is used to define certain parameters such as TAX or GAP at
a more disaggregate level, for example using an X-file allows the user to set link-
specific values of TAX as opposed to a single universal value (6.3.3). In addition
extra link capacity indices, flare lengths and APRESV may also be defined.
To define an extra file the user must first specify a file name using the namelist
parameter name XFILE under &PARAM (6.3.4) in the main network file; e.g.
XFILE = ‘netplus.dat’
X-files consist of (up to) four data sections:

(i) A set of namelist parameters.
(ii) Node-based data contained between 11111 and 99999 delimiters following
standard SATURN conventions.
(iii) Link-based data under 22222.
(iv) Turn-based data under 33333
Of these the namelist records are mandatory and the three data sections are
optional depending on parameters set under namelist. (And in fact at the time of
writing there are no options which use the 11111 node records but they will no
doubt appear in time.
Finally we note the similarities between inputs within SATNET using X-files and
within P1X using global data fields; see 11.9.17.
6.13.2 X-File Namelist Parameters

The following variables, all INTEGER, may be defined under the namelist title
&PARAM:
NFTAX The position of the TAX data on the link records. (0, 1, 2…)
Default: 0
NFRBKS The position of the RBKS data on the link records. (0, 1, 2…); See 8.7.2.
Default: 0
NFCI The position of the capacity index data on the link records. (0, 1, 2…)
Default: 0
The position of FLARE-X (flared PCUs for X-turns) on the link records (0, 1,
NFLX
2 ...). N.B. Not fully operational yet.
5120257 / Apr 15 6-76

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

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

These appear as 2222 records provided one or more of the parameters NFTAX,
NFRBKS, NFCI, NFLX, NFLF and/or NFAPV have been defined in order to input
link-based values for TAX, RBKS, Capacity Index, Flare-X, Flare-F and/or
APRESV respectively.
The records are formatted as followed.
Cols. 1-5 The A-node, A
6-10 The B-node, B
11-80 Data items in “free format”.
The number and order of the data items per link are determined by the numerical
values of NFTAX etc. Thus if NFTAX = 1, NFCI = 2 and all other link pointers are
zero this implies that the first data item is a TAX value and the second is a
capacity index (CI); RBKS etc. values are not used.
Since the data is in free format it may appear in any columns beyond column 10
(although the use of fixed columns in widths of either 5 or 10 is highly
recommended) and may be real or integer (with or without a decimal). (Although
indices should logically be integers.) Multiple entries must be separated by at
least one blank column.
Note that all the above link-specific values may also be defined: (a) either as
global values via &PARAM or (b) link-specific values using the second link records
(6.4.14).
N.B If DUTCH = T then the A-node and B-node entries occupy 10 columns, not 5,
as is standard; see 15.20. The data items start in column 21.
6.13.5 X-File Turn Records

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

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

6-10 The B-node, B
11-15 The C-node, C
16-80 Data items in “free format”.
As above the number and order of the data items per link are determined by the
numerical values of NFTAX etc although at the moment only turn-specific GAP
values may be set in this way so that the only relevant parameter is NFGAP which
can only take the value 1 (unless of course it is zero and no turn GAP values are
on the X-file).
Note that turn-specific GAP values only apply to traffic signals and priority
junctions, not to roundabouts where GAP’s are defined at the node level only.
Since the data is in free format it may appear in any columns (although the use of
fixed columns in widths of either 5 or 10 is highly recommended) and may be real
or integer (with or without a decimal).
N.B As with link records above, if DUTCH = T then the A-, B- and C-nodes occupy
10 columns each, not 5, as is standard; see 15.20. The data items start in column
31.
6.14 Specimen File

Various comments are given on the right hand side below, commencing with a *.
&OPTION
&END
SATURNVILLE CITY CENTRE (18/1/80)
&PARAM
MASL=6,
NITS=2,
LIST=T,
NOMADS=3,
KNOBS=1, &END
11111
1 3 3 2 63
58 3 0 140 1870 1 1 3900 1 3
2 2 9 82 3400 1 2 0 0 0
26 3 17 150 3000F 1 2 1500 3 3
24 7 6 58 2 58 26 26 58
36 7 6 2 26 2 58 26 58
2 3 1
1 2 9 82 2500 1 2 1600X 2 2
3 3 27 248 2400 1 2 3000 2 3
29 1 20 130 900G 1 1 1600G 1 1
(Remainder of simulation network data)
99999 * Terminates simulation link data
22222 * Commences simulation C.C data
1 59 45
2 60 46
3 61 62
4 63 49 49 63
(Remainder of simulation centroid connector data)
99999
33333
3 2 28 56 2500 1 100 3.1
5120257 / Apr 15 6-78

Section 6
1978.00 * Extra (KNOB) data

29 2 21 42 1250 2 90
1983.00 * field, presumably
2 3 28 56 3750 2 100 3.1
1983.00 * some sort of date
C 2 59
9999.00 * with a default of
C 3 60
9999.00 * 9999 for centroid
C 4 61
9999.00 * connectors
(Remainder of the buffer network/link data)
99999
44444 * Banned links/turns
4 5 -1 0 30 * Link banned to UC 1, open to UC 2,
* 30 seconds penalty to UC 3
34 6 0 -2 * Open to UC 1 but banned to 2 and 3.
31 32 0 -1 0 * Banned to UC 2 only
46 51 50 10 -2 * 10 second penalty to UC 1, banned
* turn for classes 2 and 3.
16 17 18 -2 * Banned turn for all UC - therefore
* presumably a bus-only turn.
99999
55555 * Co-ordinates
1 17 53
2 17 62 * Node 2 (either simulation or buffer)
* co-ordinates
C 24 36 48 * Zone 24 co-ordinates
C 20 39 29
(Remainder of co-ordinates)
99999
66666
400 11 7 66 12 13 14 15 16 17
401 3 7 18 45 53 52 31 32 33
500 7 9 18 17 16 15 14 41 13 12 66
600 8 9 66 12 13 14 15 16 17 18 19
601 8 10 25 26 24 23 22 21 20 19 18 17
(Remainder of bus route data)
99999
77777 * Link and turn observed flows
1 58 1252 * Link volume (N.B. uni-directional)
58 1 779 * “ ” (in the opposite direction)
45 53 52 826 * Turning volume
99999
88888 * Matrix and generalised cost definitions
* for each user class (UC):
1 1 0.20 1.00 1.00 * UC 1 forms 20% of matrix level 1
* and defines cost = 1.0*time + 1.0*dist
* and is distance minimizing (cost = dist)
3 1 0.40 1.00 3.00 * UC 3 forms 40% as well and defines
* cost = time + 3.0*dist
99999
99999 * N.B. 2 99999 records to end data file
6.15 FIFO, TOPUP and DOUBLE – Options for Repeated Data Input
It is possible for various inputs to appear more than once, either within the same
data section or, alternatively, within two different data sections. In such cases it is
necessary to decide which data entry to accept as definitive – or whether the
repetition should lead to an error. Three logical parameters, FIFO, TOPUP and
DOUBLE, control the decision in different circumstances.
5120257 / Apr 15 6-79

Section 6
6.15.1 FIFO – First In First Out

The Namelist parameter FIFO (“First In, First Out”) is instrumental in such
decisions: if FIFO = T then the first entry is rejected and the last entry used, and
vice-versa if FIFO = F.
The problem occurs in the following situations:
1) X,Y co-ordinates are repeated for the same node within the 55555 data
set.
2) Speed-flow data is coded for a simulation link leading into an external
simulation node coded within the 11111 data records but an entry for the
same link subsequently occurs within the 33333 buffer data (and which
would normally be used to define a speed-flow curve for that link). See
6.4.12.
3) Link capacity indices may be defined either on simulation link speed-flow
records, on buffer links or on an X-file.
For example, if the same node appears twice (or more) under 55555 with different
co-ordinates each time, then if FIFO = T the second (last) set will be used; if FIFO
= F, the first record will be used. Clearly if the co-ordinates are the same it does
not matter too much which one is used, although there may be problems with
editing X,Y co-ordinates since only one record (not sure which!) will be updated.
One situation where FIFO is not used is that where a default speed-flow record
for the same capacity index in the 33333 data appears more than once; the first
record is always used.
In addition the rules have been changed in version 10.5 and beyond such that
case (2) above is no longer controlled by FIFO. Thus the 11111 data is always
used in preference to the 33333 data, on the assumption that if a user has gone to
the bother of explicitly adding an extra data line under 11111 they must definitely
want that data to be used.
It is strongly recommended that all situations where FIFO is applied (or not
applied as in the previous two cases) are checked by the user and the redundant
data removed. Check your .lpn for occurrences of FIFO.
6.15.2 TOPUP
The parameter TOPUP allows the user to define simulation network data file in
terms of changes to a basic network in conjunction with the use of $Include files
within the 11111 (simulation node) and 22222 (simulation centroid connectors)
data segments (only).
N.B. After its first introduction in 10.8.16 the functionality of TOPUP was extended
in 10.9.15 by defining an auxiliary parameter DOUBLE = T, whose use is now
strongly recommended. However, for reasons of historical order, the description of
TOPUP that follows assumes DOUBLE = F. If you do wish to use the
recommended functionality of TOPUP please read Section 6.15.3 in conjunction
with 6.15.2.
5120257 / Apr 15 6-80

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

Section 6
in $INCLUDE files is dropped and duplicated simulation node data may appear in
either the main .dat file or in one or more $INCLUDE files independent of the
order. The first version of the node data encountered always becomes the
accepted version and all later versions are skipped over.
In addition with DOUBLE = T it is not necessary to have any “proper” node data
within the main 11111 segment; it may simply reference a string of $INCLUDE
files. For example, the following sequence would be an acceptable – and probably
very sensible – method for progressively defining “scenarios”:
11111
$INCLUDE do_something.dat
$INCLUDE do_minimum.dat
$INCLUDE base_year.dat
99999
Thus the do minimum .dat file would over-write certain data defined in the base
year and do-something could in turn over-write data coded in either the do
minimum or base year scenarios.
A (Semi) Fatal Error 421 still results if data for the same node appears more than
once in the same data segment (main or $INCLUDE). Equally semi-fatal errors
result if a negative (delete this node) number appears more than once or if the
negative node number appears after the node data which it is intended to delete.
DOUBLE was first introduced in SATURN 10.9.15 with a default value of .FALSE.,
largely for historical compatibility, but its default was changed to the
recommended value of .TRUE. in the release version 10.9.22.
6.16 SATNET Files

Channel Remarks
1 An output UFN file suitable for input to SATALL. (Mandatory)
2 An input UFS file containing data from Aa previous run to be used for
updating. (Optional - UPDATE = T)
5 A “DAT” file containing the control parameters and network data; see
6.1 to 6.11.
(Mandatory)
6 An output LPN line printer file. (Mandatory)
9 An input UFS file containing pre-loaded flows; see 15.5
(Optional - PLOD = T)
10 An input trip matrix .ufm file for checking purposes
(Optional – if FILTIJ has been defined)
11 Output .ERL file used to store sorted node-based error messages
12 Scratch file used to store error messages for the output .ERL file
13 Input .ERL file defined by FILERL in &OPTION
(Optional)
5120257 / Apr 15 6-82

Section 6
15/14 Terminal (output only)

(Optional - MODET ne 0)
17 File “SATTIT.DAT” which contains default array names for the various
data records stored on the output UFN file.
(Optional - SATTIT = T)
18 An input UFS file containing pre-loaded flows; see 15.5
(Optional – PLOD = T)
19 A scratch file used to input GIS/BMP/UNION files as required.
(Optional -)
20 A scratch UFX file used for both input and output.
(Optional - UPDATE or PASSQ = T or a buffer network included)
21 A text file used to input supplementary KNOBS data and/or count data
from FILMCC. See 15.14.5.
(Optional -)
22 A scratch UFX file used for both input and output.
(Mandatory)
23 The input “X-file”; see 6.13
(Optional)
24 An input “PS” file – see Section 15.2.3
(Optional)
27 An input UFS file containing data from a previous run to be used under
PASSQ. (Optional - PASSQ = T)
29 A scratch file used to input BMP/CDF/UNION files as required.
5120257 / Apr 15 6-83

Section 6
5120257 / Apr 15 6-84

Section 6
Assignment – The Role of SATEASY / SATALL
7. Assignment – The Role of SATEASY/SATALL

INTRODUCTION
The assignment procedure accepts as input a trip matrix and a network and
assigns those trips to routes through the network based on the current cost-flow
relationships, either user-input or derived from the simulation. It’s essential
outputs are flows per link, including turns in the simulation network.
The same procedures are included within the stand-alone assignment program
SATEASY as well as within the combination program SATALL. The
documentation given here applies to both (apart from Section 7.12). Extra
features specific to SATALL are documented in Section 9.
Historically SATEASY replaced the former assignment program SATASS,
although initially its main function was to add an elastic assignment capability
whereas SATASS worked only with a “fixed” trip matrix. Certain facilities of
SATASS were transferred elsewhere, in particular PIJA analysis (now done by
SATPIJA, see 13.1.2), and the comparison of counts and assigned flows which is
available both within P1X/SATLOOK (11.7.1, 11.11.13) and SATDB (15.6).
Currently all functions of SATEASY are embedded within SATALL so, except for
very specific applications, the use of SATALL is recommended for assignment
purposes, even for buffer-only networks.
Sections 7.1 through 7.3 assume fixed trip matrices independent of the resulting
travel costs. Sections 7.4 through 7.11 extend the discussion to include elastic or
variable demand models where both route choice and trip matrices are modelled.
A further extension to "quasi-dynamic" assignment over multiple time periods is
described in Section 17.
Users who would like to know more about the details of the theory underpinning
the assignment algorithms in SATURN should consult Dirck Van Vliet for
additional material.
Note that throughout this section we assume that the link cost-flow curves c a (V a )
are “fixed”, as would occur with buffer networks or on a particular assignment
iteration within the assignment simulation loop. The precise mathematical form of
the cost-flow curves used in SATURN is described in Section 5.4. The extra
complications which arise from “variable” cost-flow curves are dealt with in Section
9.
7.1 Wardrop Equilibrium Assignment

This section describes equilibrium assignment with a fixed trip matrix and a single
user class. Extended models are described later - see 7.3 for multiple user
classes and 7.4 for variable trip matrices. The alternative general principle of
stochastic assignment is covered in 7.2.
5120257 / Apr 15 7-1

Section 7

The default assignment procedure within SATURN is based on Wardrop’s
Principle of traffic equilibrium, which may be stated as:
Traffic arranges itself on congested networks such that the cost of travel on all
routes used between each O-D pair is equal to the minimum cost of travel and all
unused routes have equal or greater cost.
Note that the cost of travel referred to above is that calculated after all traffic has
been loaded onto the network based on the total assigned traffic per link and the
assumed cost-flow curves. Thus a Wardrop Equilibrium solution allows for the
effect of congestion (via the cost-flow curves) on route choice and for the
“feedback” effects of congestion on route choice. (See 7.2 for the inclusion of
individually perceived costs.)
A major advance in assignment theory was the recognition that the set of flows V a
satisfying Wardrop’s Principle could also be obtained by finding the set of flows
which minimised a certain “objective function”:
Equation 7.1
Va
Z = ∑ ∫ C ( v ) dv
a
a
0
This equivalence is extremely useful in that it enables one to establish algorithms

which, by minimising Z, guarantee finding an equilibrium solution.
(Under certain circumstances it is more convenient to “normalise” Z by dividing by
the total number of trips in the trip matrix, so that Z/T is expressed in terms of
generalised cost units (seconds) per trip. It is not however particularly useful to
compare this cost to other average costs; it is simply a device to print Z values in
units which are broadly similar across the whole range of network sizes modelled
in SATURN.)
7.1.2 The Frank-Wolfe Algorithm

The standard algorithm employed by SATEASY uses the following iterative
sequence (technically the “Frank-Wolfe Algorithm”):
1. Assign all trips to O-D paths to produce an initial set of “feasible” link
flows V a (n) where n = 1. Conventionally the first assignment is an all-
or-nothing assignment with the link times set to their “free-flow”
values. (But see 7.11.6 and 7.11.13 for alternative starting points).
2. Alter the link times in accord with the current flows V a (n); i.e., set: c a (n)
= c a (V a (n)).
3. Build a new set of shortest paths based on c a (n) and assign all T ij to
them to produce a set of “auxiliary” all-or-nothing flows F a (n).
4. Generate an “improved” set of link flows V a (n+1) as a linear combination
of the old and the auxiliary flows:
5120257 / Apr 15 7-2

Section 7
Equation 7.2
Va ( n +1) =
(1 − λ )Va( n ) + λ Fa( n )
where λ (0 < λ < 1) is chosen so that the “new” flows V a (n+1) minimise
the objective function. (See 7.1.3 below for the precise equation used
to calculate λ.)
5. Return to step (2) unless some convergence criterion is satisfied; for
example the maximum number of loops as specified by NITA has
been exceeded (see 7.1.5).
What distinguishes equilibrium assignment from other similar, more empirical
capacity-restrained techniques is the choice of “optimal” proportions based on the
concept of minimising an objective function.
In effect at each stage of the algorithm we calculate a new set of routes for all ij
and shift a certain proportion λ of all previously assigned trips onto these routes.
Thus the averaging in equation 7.2 may be viewed either at the level of individual
ij path flows or at the aggregate link-flow level. Hence after, say, 5 iterations we
will have up to 5 different routes for each ij pair (allowing for the same route to be
chosen more than once) with certain fixed proportions of trips assigned to each.
See the papers in Appendix H for a more path-based description of Frank-Wolfe.
At the conclusion of the algorithm the final solution is made up of a weighted
average of each of the n individual all-or-nothing solutions / sets of path flows
where the weight assigned to each solution/set is calculated iteratively according
to the following equation:
αa λ
= j i= j +1 ∏ n (1 − λ i ) (7.2b)
where α j is the proportion of the final solution contributed by iteration j and λ i is

the value of λ chosen on the ith iteration. Thus solution j is initially assigned a
fraction λ j but this is then consistently reduced by factors of (1 - λ) on each
subsequent iteration.
The proportion of trips α j allocated to the routes found at each iteration are printed
at the end of the assignment; e.g.
ITERATION FRACTION
1 0.6000
2 0.2201
3 0.0349
4 0.1172
5 0.0279
Thus 60% of all trips use the routes identified in iteration 1, 22.01% follow those
from iteration 2, etc. etc.
5120257 / Apr 15 7-3

Section 7
Wardrop Equilibrium may also be achieved using slightly different algorithms; see,
for example, ROSIE in 7.1.3, Partan in 7.11.7 and MSA in 7.5.8 as well as by
either path-based algorithms or origin-based assignment (See Section 21).
7.1.3 Wardrop Equilibrium using the Rosie Option

Assignment with ROSIE = T differs from that with ROSIE = F (the default) in that
the link costs are calculated, in the case of simulated turns which share lanes
within “rivers” (see 8.8.2), as a function of the total weighted flow in those lanes
as opposed to a function of the flow for that turn alone. See Section 8.4.3. All
other types of links and non-sharing turns have their delays calculated as per
normal.
Thus, instead of the cost c a on link a being calculated as a “separable” function of
its own flow:
C a = c a (V a )
it is calculated as a “non-separable” function of a weighted sum of link flows:
C a = C A (Σ w b V b ) + d a
where the links b ε A all share lanes with link a and are said to constitute a “river”.
The additive term d a distinguishes between the different turning movements within
the river.
In the case of simulation turns, weights are related to the “difficulty” in making a
turn; e.g., if an unopposed straight-ahead movement and a heavily opposed left-
turner share the same lane then the left-turning traffic would be assigned a much
heavier weight than the straight-aheads.
With non-separable cost-flow relationships, as introduced under ROSIE, the
Wardrop Equilibrium problem can no longer be represented as a minimisation
problem, since the objective function (7.1) may no longer be uniquely defined
(due, technically, to the presence of “off-diagonal” elements in the matrix of cost-
flow partial derivatives). It may, however, be considered in the more general guise
of a Variational Inequality as proposed independently by Mike Smith of the
University of York and Stella Dafermos of Rutgers University around 1980.
However, it turns out (see Van Vliet, D. (1987), The Frank-Wolfe Algorithm for
Equilibrium Traffic Assignment Viewed as a Variational Inequality. In: Transportation
Research 21B, pp 87-89) that the Frank-Wolfe algorithm may equally well be
interpreted in the framework of a Variational Inequality with the result that all the
steps described in 7.1.2 may be retained with only a marginally different step 3)
where a lambda value is calculated to decide how much traffic is allocated to the
latest route.
Thus, under ROSIE, we still calculate an “optimum” value of lambda but
“optimum” in a certain Variational Inequalities sense, not minimisation. In both
cases we solve for λ via the same equation (9.4):
∑ c ( λ ){V
a a − Fa } =
0
5120257 / Apr 15 7-4

Section 7
The only difference between Frank-Wolfe and ROSIE is that in the former case
c a () is a separable function of V a whereas in the latter it is non-separable as
defined above. Indeed there are very strong theoretical parallels between ROSIE
and AUTOK as discussed in Section 9.3.2.
Empirically this modified algorithm is observed to converge to a Wardrop
Equilibrium at virtually the same rate as the more theoretically correct version.
What is “sacrificed” by using ROSIE is the ability to calculate certain convergence
measures such as epsilon which rely upon the minimisation framework; however
other measures such as delta may still be evaluated.
The (it is devoutly hoped!) advantage of the solution found with ROSIE = T is that,
by incorporating part of the interaction terms in the simulation of delays (see
Section 9.1), i.e., the contribution of lane sharing, directly within the assignment it
will improve the overall rate of convergence of the assignment/simulation loops.
Preliminary tests have been encouraging and, in certain – but not all! - networks,
it can make the difference between convergence and non-convergence.
On the other hand setting ROSIE = T is not a universal cure-all for all problems of
assignment convergence and indeed in most networks its convergence properties
are no better or even worse than setting ROSIE = F. Thus our advice is to set
ROSIE = T only as an experiment if there appear to be convergence problems
otherwise and never set it T initially or by default.
ALTERNATIVE APPLICATIONS
In principle, the basic ideas of ROSIE, i.e., assigning different weights to different
streams of traffic in order to calculate times, could be applied in different
situations. For example, on motorway links one (user/vehicle) class of traffic could
be assigned a different “weight” from other (user/vehicle) classes in calculating the
total flow as used to determine the travel time from speed-flow curves. These
weights could be additional to any user/vehicle class PCU factor and could be
either greater than or less than 1.0. This facility might then be used to define
variable PCU-factors by link or link-type so that, for example, HGVs might be
assigned a (presumably) higher PCU factors for links with an incline.
Alternatively, and also on motorways, traffic entering from a slip road might be
assigned a greater PCU factor on the first link downstream as a way of
representing a greater ‘impedance’ associated with (initially slower moving) joining
traffic.
7.1.4 The Delta Function to Monitor Wardrop Equilibrium

The relative “success” in achieving a Wardrop Equilibrium may be monitored by
the so-called “Delta or gap function” defined by:
Equation 7.3
δ=
∑T (c pij pij − cij∗ )
∑T c ∗
pij ij
Where T pij is the flow on route p from origin i to destination j

T ij is the total travel from i to j
5120257 / Apr 15 7-5

Section 7
c pij is the (congested) cost of travel from i to j on path p

c ij * is the minimum cost of travel from i to j (calculated with current congested
costs)
Thus if traffic uses a particular route pij (so that T pij > 0) then (c pij - c ij *) is the
“excess cost” of travel on that route relative to the minimum cost of travel for that ij
pair. Hence delta measures the total cost of excess travel, with the denominator
introduced so that the measure is given in relative rather than absolute terms.
Indeed delta is most generally expressed as a percentage.
As a rule of thumb delta values less than 1% should be taken as acceptable levels
of convergence (in practical terms) while values in excess of 5% should be viewed
with concern (and probably indicate that you should increase the parameter
NITA). The argument here is that, in real life, drivers themselves find it difficult to
choose routes that are within 5% of the “true” minimum cost so it is not essential
for the model to do much better.
On the other hand (and more importantly), there are great practical advantages of
having a well-converged assignment model that gives a single well-defined
solution in all cases so that one should always strive to achieve delta values which
are as low as possible (i.e. much less than 1% and ideally less than 0.25% if
practicable). See Section 21 for a discussion of Origin Based Assignment, an
alternative to Frank-Wolfe, which can reduce delta values to effectively zero.
See also Sections 9.2.4 and 9.5.3 for further discussion on “optimum”
convergence.
Finally, we should note that, although delta has the advantages of being relatively
easy to understand and relatively easy to calculate for a wide range of assignment
algorithms (i.e., not just Frank-Wolfe), it also has certain disadvantages as a
convergence parameter.
Thus it is not necessarily guaranteed to always decrease from one iteration to the
next. Indeed it may typically vary by factors of two between successive iterations.
Thus, if you set a target of 1.0% which is first reached, say, on iteration 10 there is
no guarantee that the 11th and/or later iterations will also be below 1.0%. The
epsilon parameter described in the next section has the advantage of being non-
increasing and is therefore recommended in preference to delta as a convergence
parameter.
7.1.5 Stopping and/or Convergence Criteria for Wardrop Equilibrium

The Frank-Wolfe sequence is carried out for a variable number of iterations until
one or more convergence criteria are satisfied, i.e., until it looks as though any
further iterations will not be cost-effective. This section briefly describes these
criteria.
5120257 / Apr 15 7-6

Section 7
The “Delta Function”, along with its disadvantages, has been described above. A
second method of monitoring convergence is to consider the objective function
directly which, as mentioned above, the Frank-Wolfe algorithm seeks to minimise.
It may be shown that a lower bound to the ultimate objective function, Z*, can be
calculated at the n-th iteration by the formula
Equation 7.4
Z (n) ∑ Tpij (C pij − Cij* )
Z lb (n) =− (a)
At convergence Z and Z lb meet at the minimum value, Z*. Figure 7.1 illustrates
the “typical” behaviour of Z and Z lb as a function of the iteration number n.
Note that Z lb does not necessarily increase on every iteration, e.g. on iteration 5,
so that a better lower bound on Z* may be obtained by taking the maximum lower
bound achieved to date; i.e., set:
= =
Z lbmax (n) max ( Zlb (i), i 1, n ) (b)
Figure 7.1 - Assignment Objective Function (Z) and Lower Bound Z lb )
41000
Z
39000
37000
Zlb
35000
0 1 2 3 4 5
iterations
We may now define the “uncertainty” in the objective function by a parameter

epsilon defined by:
Equation 7.5
ε (n) ( Z (n) − Z lbmax (n)) Z (n)
=
Note that the numerator in epsilon is effectively the same as that used to define
the delta function, eqn. (7.3): both are measures of the differences in current and
minimum total vehicle costs (compare the second term in eqn. 7.4(b) and the
numerator in eqn (7.3)). They also differ in that delta is “normalised” by dividing by
the total vehicle cost and epsilon, by the current objective function (which, as an
integral of cost vrs. flow, is an underestimate of total flow times cost).
In practice epsilon values are broadly similar to delta but have one great
advantage over delta in that they are guaranteed non-increasing (i.e., they can
only decrease / stay the same from one iteration to the next). This, therefore,
makes epsilon far more attractive convergence parameter than delta and is the
5120257 / Apr 15 7-7

Section 7
reason that epsilon is used as a stopping criteria in SATURN assignments, not

delta.
A further measure of the effectiveness of the n-th step of the iteration is therefore
how much it reduces Z relative to ε. We define a fractional rate of improvement on
the n-th iteration by:
Equation 7.6
( Z (n) − Z (n − 1) ) ε (n) =
F ( n) = ∆Z (n) ε (n)
Note that all of the above convergence measures may only be calculated AFTER
the next iteration in the Frank-Wolfe sequence; i.e., after the all-or-nothing flows
for a given set of V a (n) are calculated. The iterative loops terminate after the n-th
iteration if any of the following conditions are satisfied
(i) n ≥ NITA
(ii) λ(n) ≤ XFSTOP
(iii) F(n-1) ≤ FISTOP and F(n-2) ≤ FISTOP

(iv) ε (n) < UNCRTS (as a percentage)
In addition a minimum number of assignment iterations may also be specified
using the parameter NITA_M. This is useful if, for one reason or another, the
assignment converges too rapidly. By default NITA_M equals 3 for Frank-Wolfe
assignment, 1 for OBA; set it to 0 or 1 to “disable it”.
Note that since the relative improvement F can only be calculated AFTER the
following load condition (iii) is given in terms of F(n-1) instead of F(n); hence an
additional ‘combination’ of flows occurs when this condition is strictly satisfied. It
must also be satisfied on two successive iterations since, from experience, a small
improvement on one iteration is very often followed by a large improvement on the
next.
Of the four conditions used the test on ε is, in a sense, the “best” in that it is based
on an absolute measure of the “distance” between the current and the ultimate
solution. F and λ are more measures of “progress” and indicate whether or not
the algorithm has become “stuck” or is progressing only very slowly, not
necessarily the same thing as being “near” the correct solution.
All five stopping parameters, NITA, NITA_M, XFSTOP, FISTOP and UNCRTS
may be set as namelist parameters within either SATNET or the assignment
programs (SATEASY or SATALL). The default values are 20, 3, 0.05%, 0.05%
and 0.05% respectively. To effectively cancel one or more of the above stopping
conditions set its critical value to zero (or, in the case of NITA, to a very large
value).
We may also note here that NITA may not necessarily be a constant value but
may be “optimised” by SATALL at each stage of the assignment-simulation loop
as governed by a parameter AUTONA described in greater detail in 9.5.4.
5120257 / Apr 15 7-8

Section 7
7.1.6 Uniqueness of Wardrop Equilibrium Solutions

In general the link flows V a generated by a perfectly converged Wardrop
Equilibrium assignment are unique. (Strictly speaking only the equilibrium link
costs c a and the O-D costs c ij * are unique but, unless the link cost-flow curves are
flat at the equilibrium, the link flows are also unique.)
However the path flows T pij which make up the solution are, in general, not unique
and, under certain conditions, this may cause problems. See, for example,
sections 15.23.7 and note (7) in 15.27.6 where we note that the average O-D
times, distances etc. (as frequently used for economic evaluation purposes or for
feedback to demand models) are not unique.
For example, consider the very simple case of two links connecting the same two
nodes with, at equilibrium, flows of 500 pcu/hr on both links. Let the total flow of
1,000 be generated at two different origins, each of which provides 500 pcu/hr.
The “most likely” equals “most obvious” solution is for each origin to have a flow of
250 pcu/hr on each link. However, it is also possible to obtain the identical
equilibrium link flows by assigning all the 500 pcu/hr flow from origin 1 to one link
and all from origin 2 to the other – or vice versa. And clearly any other split of
origin 1 flows between 0 and 500 are equally valid as equilibrium solutions as long
as the overall 500:500 split between the two links is maintained.
In general Frank-Wolfe “tends” towards the equi-split solutions but not always.
The issue becomes important if, say, one link is tolled and the other is not and we
wish to avoid the anomalous situation where all trips from origin 1 are apparently
using the tolled link and no trips from origin 2 are. The total toll generated is
unique; the ambiguities only arise at more disaggregate levels.
A similar situation may also occur with multiple user classes (see 7.3) where, in
the above example, the question is whether user class 1 or user class 2 uses the
tolled link. Again, the solution algorithms used in SATURN, tend to avoid the
problem by spreading trips equally between origin/user class/etc
7.2 Stochastic User Equilibrium (SUE) Assignment

An alternative definition of a “stochastic” state of user equilibrium (SUE) may be
written as:
Traffic arranges itself on congested networks such that the routes chosen by
individual drivers are those with the minimum PERCEIVED cost; routes with
perceived costs in excess of the minima are not used.
The important difference between these two formulations is that Wardrop
Equilibrium implicitly assumes that all users perceive travel cost in an identical
manner - which is to say the definition of travel cost set by the modeller - whereas
SUE allows different users to have different perceptions of what actually
constitutes travel cost to them.
Stochastic models are set up by assuming that the cost as defined by the model is
the “correct” average cost but that there is a distribution about the average as
5120257 / Apr 15 7-9

Section 7
perceived by individuals. The perceived cost of a route may therefore be

simulated by selecting a cost at random from the perceived distribution of costs on
each link.
Algorithms designed to reflect the resulting flows are generally referred to in the
UK as “Burrell assignment models”.
A variant of stochastic assignment, STOLL which is used to represent the
variability in users’ evaluation of tolls, is described in Section 20.6.
7.2.2 Solution Algorithms: The Method of Successive Averages

The problem with standard formulations of Burrell assignment is that they tend to
assume flow-independent costs - or more definitively they give no precise method
as to how to take congestion into account.
However, Yosef Sheffi of M.I.T. has shown that the following “Method of
Successive Averages” produces, in the limit, a set of self-consistent SUE flows.
(Y. Sheffi and W. Powell; A comparison of stochastic and deterministic traffic
assignment over congested networks. Transportation Research 15B, 53-64,
1981. See Van Vliet and Dow, TEC June 1979, for a discussion of what
constitutes a “self-consistent SUE solution”.)
Step 0. Assume some form of the distribution of link costs about the mean; see
7.2.3.
Step 1. Set all link costs to their “free flow value” and a counter n to 0.
Step 2. Carry out a Burrell-style assignment with the current costs in which for
each origin we: (a) generate random link costs and (b) assign all trips to their
minimum (random) cost routes to produce a set of “all-or-nothing” flows, F a (n).
Step 3. Average the all-or-nothing flows from step 2 with the previous flows using
the equation
(1 − 1 n)Va( n ) + Fa( n ) n
Va( n +1) =
where V a (n) are the average flows after n iterations.`

N.B. On the first iteration simply set V a (1) = F a (0).
Step 4. Adjust the link costs (times) to correspond to V a (n+1).
Step 5. Increment n by 1 and return to step 2 unless n exceeds some pre-set
value (NITA).
The reason for choosing the “averaging factor” 1/n in step 3 is that it ensures that
after n iterations the total flow is equally divided between all n sets of routes
generated to date; hence the name “method of successive averages”.
To carry out SUE assignment using SATURN simply set the parameter SUZIE to
TRUE and set values for KOB, KORN, NITA and SUET. All other options within
SATEASY may still be invoked.
N.B. SUE assignment converges much more slowly than Wardrop equilibrium. In
addition, it is much more difficult to monitor the convergence. You are therefore
5120257 / Apr 15 7-10

Section 7
advised to set a large value of NITA, the number of loops in the MSA algorithm, in
order to assure a reasonable level of convergence; for example, values of 20 or
30 would not be unreasonable (unless cpu time is a constraint). See 7.2.5 for
further information
7.2.3 The Choice of Link Cost Distributions (KOB and SUET)

The assumed distribution of link costs may take one of four forms
1) A rectangular distribution such that there is an equal probability of the link
costs being in the range C1 to C2, with the mean (C1+C2)/2 being equal to
the calculated link cost C. SUET defines the maximum spread such that (C2
- C) = (C - C1) = SUET*C.
2) A normal distribution whose mean equals C and whose standard deviation =
SUET*C; i.e., SUET is the coefficient of variation.
3) A normal distribution whose mean equals C and whose variance = SUET*C;
i.e., SUET is the coefficient of dispersion, and therefore has units of ‘cost’.
4) Generalised user-set distribution defined by a “cumulative density function”
set in an external data file.
The rectangular distribution is used if KOB = 0 (the default) and the normal is used
if KOB = 1 or 2. While the normal distribution is more satisfactory from a number
of theoretical points of view it also involves considerably more effort in terms of
increased cpu; hence the default choice of the rectangular option.
Theoretically KOB = 2 is preferred to KOB = 1 since it means that the properties of
two links ‘in series’ are identical to the properties of a single combined link; this
arises from the fact that the variance of normal distributions is additive, not the
standard deviation. It also brings the SATURN stochastic procedure closer to the
procedures recommended by the UK Department of Transport.
7.2.3.2 Cumulative Density Functions (KOB = 3)

The fourth alternative, set by KOB = 3 and new in SATURN 10.5, allows the user
to specify any generalised form of distribution numerically. The distribution is
defined in terms of its “cumulative density function” (CDF) – or, strictly speaking,
the inverse of a cumulative density function. Thus, a CDF y = F(x) defines the
probability that a random variable is less than x where 0<= y <= 1; the inverse x =
F-1(y) defines x as a function of the cumulative probability y.
In this case x represents a random number which is used to factor the link cost,
i.e.,
C ′ = x.C
where C is the current link cost and C’ its randomised value. Hence we are talking
about the distribution of a random variable x whose “mean” value is near 1.0 as
opposed to the actual distribution of costs on a specific link. Hence x is unitless.
5120257 / Apr 15 7-11

Section 7
Suitably randomised x values are generated by, firstly, randomly generating a

uniformly distributed value y in the range (0,1) and then, secondly, calculating the
corresponding value of x.
The inverse CDF function F-1() is numerically set by defining a set of x values
corresponding to equal increments of y. For example, if 11 values of x are input
they are assumed to correspond to y = 0.0, 0.1, 0.2, … 1.0 (where, as above, we
might expect that the sixth value, corresponding to y = 0.5, would be
approximately 1.0).
CDF functions are defined by text (ascii) files with, by default, the file extension
“.cdf”. Each such file may contain more than one CDF; for example a file
containing the records:
0.1, 0.9
0.5, 0.95
1.0, 1.0
1.5, 1.05
2.0 1.10
Would define two CDF’s, the first one representing a very wide spread of random
multipliers in the range 0.1 to 2.0 while the second represents a much “tighter”
distribution in the range 0.0 to 1.10. The different functions may be used for
different user classes – see 7.2.3.3 below.
In the above example with 5 lines of input the three intermediate values represent
”quartiles”; i.e., the lowest 25% of values for the first function are in the range 0.1
to 0.5, the next 25% are in the range 0.5 to 1.0, etc. Intermediate values are set
by linear interpolation.
To define a function with maximum numerical precision the maximum number of
inputs must be used, with an upper limit of 101 points (which therefore define the
CDF at intervals of 0.01).
The filenames for CDF’s are set using the Namelist character parameter FILCDF
under &PARAM. N.B. At present there is no way that it may be defined on the
Command Line unlike, say, trip matrix filenames. Also it may only be defined
within the inputs to SATNET, not as an input to SATALL where it is actually used.
CDF’s allow users complete flexibility in defining random number distributions. For
example, a CDF may represent a skewed distribution such as a gamma or log-
normal which is a “natural” form of distribution to use when dealing with perceived
values of road charges; see 20.6 for an application under STOLL.
The advantage of using a .cdf file (i.e., KOB = 3 rather than one of the other
values) is that it allows complete flexibility in the randomisation of the link costs.
7.2.3.3 Choice of Cumulative Density Functions (KDF)

With more than one user class and more than one input cumulative density
function it is possible to select a different CDF for each user class. This is done
via the Namelist input parameters (under &PARAM in .dat files) KDF(); thus
KDF(2) = 2 indicates that user class 2 uses the second input CDF.
5120257 / Apr 15 7-12

Section 7
Thus you may define one user class with a very small spread in perceived costs
and another with a large spread.
7.2.4 The Generation of Random Numbers (KORN)

Let us first describe very briefly how random numbers are generated on a
computer. In fact they are not truly “random” in that they constitute a series of
numbers which appear, from a statistical point of view, to be random; but are in
fact set in a totally deterministic fashion starting from an initial “seed value”.
The equation used to generate the (n+1)th number X(n+1) given the value X(n) of the
nth is generally of the form:
X ( n +=
1)
( A + BX ( n ) ) mod C
where A, B and C are extremely large numbers. (Mod C implies you divide A +
B*X by C and take the remainder.) Thus by choosing a certain value for X(0) the
user can guarantee reproducing exactly the same random numbers at any stage.
KORN is therefore just such a seed value X(0) so that running the assignment
twice with identical values of KORN gives identical results. Change KORN and
you obtain different flows, although as NITA is increased two different runs should
approach one another “statistically”.
However there are complications (aren't there always?). Thus a highly desirable
property of an assignment is the ability to reproduce the routes generated by the
assignment at a later stage (see 15.23 for a discussion of these merits), in which
case it is essential to be able to reproduce the random numbers generated at
each iteration of the assignment. For this reason a new sequence of random
numbers is initiated with each different origin-based tree-building operation using
a seed value ISEED defined by:
ISEED = KORN+NOMAD+10*NASS+100*NITER+3000*IORIG
Thus P1X, for example, can build exactly the same O-D routes as were used in
SATEASY or SATALL.
7.2.5 The Convergence of Stochastic Assignment

The convergence of a stochastic assignment process based on the Monte Carlo
principles of the continuous generation of random numbers is notoriously difficult
to measure. It has to converge with respect to both the effects of congestion (as
with Wardrop) plus the effects of random perceptions. Unlike Wardrop equilibrium
there are no parameters which definitely reduce to zero at perfect convergence -
even if two successive iterations give identical results this could simply be the
result of a freak set of random numbers (indeed it certainly would be, even at
convergence).
SATURN therefore terminates a stochastic assignment only after the maximum
number of iterations, NITA, has been executed, never before. Thus the user
always has total control over the stopping criteria.
However to help in monitoring the level of convergence SATURN stochastic
assignment routines print out a number of global statistics
5120257 / Apr 15 7-13

Section 7
The total pcu-cost at the end of each iteration:
( )
C ( n ) = ∑ Va( n ) ca Va( n )
a
where the costs are those evaluated after the assignment.

At convergence the total costs might be expected to randomly fluctuate about the
“true” value; therefore a consistent increasing or decreasing trend in C(n) is
indicative of a lack of convergence.
At convergence both measures approach zero but, for the reasons noted above,
will never exactly equal zero.
In both cases convergence may appear to have been achieved, but this may be
an artefact of the Method of Successive Averages algorithm whereby the changes
in flows on the nth iteration are strictly limited by the use of the factor 1/n in
combining flows. Thus, for example, RMS differences tend to zero whether or not
true convergence has been achieved.
The best advice we can offer to users is to choose a value of NITA which (a)
appears to stabilise C(n) and (b) does not use excessive cpu times. Alternatively
one could monitor for convergence using the MSA algorithm for Wardrop
Equilibrium (see 7.11.8) and then allow as many terations for the stochastic plus,
say, 10.
7.2.6 The Choice of Technique: Wardrop or Stochastic

In principle there are 4 very general categories of assignment techniques
available within SATURN:
(i) All-or-nothing assignment;
(ii) Pure stochastic (with costs fixed);
(iii) Wardrop Equilibrium;
(iv) Stochastic User Equilibrium
as determined by the parameters SUZIE and AMY. Of these methods 1 and 2
(where AMY = T) may be generally disregarded since they are only applicable to
very lightly loaded networks with very little congestion; clearly such conditions do
occur but not in the sort of “problem” networks that SATURN users are likely to
encounter.
However with increased congestion it becomes essential to account for the effects
of capacity restraint upon route choice so that the real choice boils down to
whether or not to choose the Wardrop Equilibrium (also referred to as “User
Equilibrium”, UE) or Stochastic User Equilibrium (SUE). Here a good case may
be made for SUE, given that it takes into account, albeit in a somewhat
approximate fashion, the differences in route choice BETWEEN different drivers.
However for highly congested networks it is probably safe to ignore stochastic
effects and to use an equilibrium model; various studies have shown that the
differences in modelled flows between UE and SUE at high flows are relatively
small (compared, e.g., to the inherent modelling errors).
5120257 / Apr 15 7-14

Section 7
On the other hand for “intermediate” levels of congestion SUE becomes

preferable to UE since the congestion effects are not sufficient to cause a realistic
spread of drivers between competing routes. (And the same argument applies to
the rare cases of very lightly congested networks.)
The question therefore is how to distinguish between intermediate and high levels
of congestion. One useful measure of congestion is the “epsilon-2” parameter
calculated by the assignment which is the ratio of the excess travel costs due to
congestion (total vehicle-hours at congestion less total vehicle hours at free flow)
relative to the total vehicle costs under free flow conditions. As a rule of thumb if
epsilon-2 is less than 25% use SUE; if over 25% use Wardrop or UE. In case of
doubt two or more methods should be tested in order to determine the sensitivity
of the results to the assumptions made.
This is, however, only a rule of thumb and there are other factors which influence
the choice of method. Thus, a major disadvantage of SUE is that the results are
statistically uncertain, which is one reason why many modellers will use Wardrop
Equilibrium even in relatively lightly congested networks. In fact, one should not
really speak of “rules” at all - “engineering judgement” is what counts!
7.3 Multiple User Class Assignment
7.3.1 The Definition of User Classes

Multiple user classes* (MUC) refer to trips which differ with respect to either:
a) vehicle type, or
b) their criteria for route choice, or
c) network restrictions
For example, lorries and cars would constitute different classes as would
cars/drivers seeking minimum time routes and minimum distance routes. Equally
cars and taxis would be different classes if there were taxi-only links. MUC
assignment is therefore the problem of assigning a number of different user
classes to the same road network.
The number of user classes is set by the parameter NOMADS with the default
value of 1 for a single user class and an upper limit of 32. The interaction
between different user classes can be based either on a Wardrop Equilibrium or a
Stochastic Equilibrium principle, i.e.
At equilibrium all routes used are PERCEIVED as being minimum cost routes
by individuals within each user class (as well as being permitted routes).
or
At equilibrium all routes used by a particular user class are minimum cost
routes as defined by that user class while all other (permitted) routes have
equal or greater cost.
* See Section 5.8 for a description of the distinction between user and vehicle classes.
5120257 / Apr 15 7-15

Section 7
Note that the term “permitted” above allows different sets of banned links or turns
by user class, while the stochastic definition allows for variations in perceived cost
WITHIN each user class. The choice between the two options is controlled by the
parameter SUZIE as with normal single-class assignment. A more complete
explanation of MUC assignment theory is given in Van Vliet et al (1986); see
Appendix C for a full listing (.PDF version only).
See Section 5.8 for a description of the distinction between user and vehicle
classes.
7.3.2 Implementing MUC Assignment

To carry out MUC assignment the user must specify:
a) a trip matrix for each class,
b) cost definitions by class, and
c) any network restrictions for each class.
Specifications (a) - in part - and (b) - in full - involve data input to SATNET under
the 88888 data records (see Section 6.11) which is therefore compulsory.
Further data specifying the form of the demand model(s) will be required under
elastic/variable demand models; see 7.9. Within this section we assume fixed trip
matrices.
7.3.2.1 MUC Trip Matrices

The trip matrix for a user class (UC) can be defined either as a fraction of a larger
matrix or as a matrix in its own right. For example, a travel survey might pick up
two different heavy lorry and car matrices but, based on other surveys, it might be
desired to divide the single car matrix, say, 70:30 between minimum time and
minimum distance route choosers. In this case only two trip matrices would be
required although there would be three user classes.
If more than one trip matrix is to be assigned the user must first “stack” the
required matrices into a stacked matrix file as explained in Section 10.2; hence 4
nxn matrices would be stacked into a 4n x n matrix file which is input into
SATEASY. The first matrix input into a stacked matrix is referred to as the “Level
1” matrix, the second as “Level 2”, etc.
Since MX can only stack up to 10 individual matrices in a single run if, unusually,
you wish to have more than 10 stacked matrices (N.B. matrices, not user classes)
you will need to stack them “in stages”. For example, with 15 matrices first stack
matrices 1 to 5 into a 5n x n stacked matrix and then 6 to 10 and 11 to 15 into
similar matrices. Finally stack all 5n x n matrices into a single 15n x n stacked
matrix.
Individual sub-matrices or levels must be set up as unformatted matrix files in the
normal way prior to stacking them together, and may be updated using SATME2
as described in Section 13.4.
The ‘88888’ input records for SATNET specify, inter alia, (a) which level of matrix
is relevant for each user class; and (b) whether the matrix is to be multiplied by
5120257 / Apr 15 7-16

Section 7
some factor (e.g., by 0.7 or 0.3 as above). The default values assume level 1 with
a factor of 1.0 so that the “standard” case of a single user class requires a
standard n x n “unstacked” trip matrix with no additional factoring. The sample
‘88888’ data records given in Section 6.14 are reproduced here:
88888 * Matrix and generalised cost definitions
* for each user class (UC):
* and defines cost = 1.0*time + 1.0*dist
* 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
For a matrix with three explicitly stacked levels the data might appear as:
88888
1 1 1.00 1.00 1.00
2 2 1.00 0.00 1.00
3 3 1.00 1.00 3.00
In general we would strongly recommend that if any of the user class sub-matrices
are likely to be independently manipulated at some stage, e.g., through elastic
assignment, ME2 matrix estimation, cordoning, etc., etc., then it is best to define
them explicitly as stacked levels without any factoring from the beginning,
otherwise problems may be created later on.
7.3.2.2 MUC Cost Definition

Each user class may have a different combination of time and distance specified
as its generalised cost; user-class specific values of PPM (pence per minute) and
PPK (pence per kilometre) are also defined on the ‘88888’ records as above.
In addition one can include the extra (“KNOBS”) data arrays as generalised costs
and/or tolls. Thus for a user class who were primarily concerned with scenic
routes one might input an extra data field giving a link “scenic index” (whereby
scenic links would have a low index and “ugly” links a high index) and give that
quantity a relatively high coefficient in the definition of generalised costs. See
Sections 7.11.2 and 6.11.
7.3.2.3 MUC Network Restrictions

Banned links and turns as specified on the ‘44444 records’ input to SATNET can
also be made user-class specific so that, for example, a turn can be banned to
HGV’s or a link reserved for taxis and buses. In the same way special time
penalties may be added to links in order to represent, for example, the fact the
certain roads may have very different travel speeds for different vehicle types.
See the example in 6.14
7.3.3 Multiple User Class Algorithms

The algorithms implemented within SATURN to carry out multiple user class
assignment mirrors very closely those described above for either Wardrop
Equilibrium (7.1.2) or Stochastic Equilibrium (7.2.2) with the one exception that
instead of a single all-or-nothing assignment being carried out at each iteration a
complete set of all-or-nothing assignments is carried out, one for each user class.
5120257 / Apr 15 7-17

Section 7
Note that costs are therefore only updated AFTER all user classes have been re-
assigned.
Thus in the Frank-Wolfe algorithm the combination of the old and auxiliary (all-or-
nothing) flows is the same for all classes. Hence at the end of the algorithm the
fraction of trips assigned to each iteration’s routes is identical across all classes.
(There is one exception to this rule - if a user class is assigned to “fixed cost”
routes, e.g., minimum distance, it is assigned once and only once to that route in
iteration 1 and thereafter disregarded.)
Similarly with the Stochastic Multiple User Class Assignment the MSA algorithm
assigns equal flows to each iteration over all classes. Note that the values of
SUET may differ by user class as defined via subscripted values of SUET under
&PARAM; e.g., SUET(2) = 0.5 defines SUET for user class 2 specifically, SUIET =
0.5 defines it for all user classes. See also 6.11.
7.4 Joint Equilibrium Assignment and Variable Demand Models
7.4.1 General Principles of Supply-Demand Equilibrium

Previous discussions have assumed that the trip matrix to be assigned is “fixed”
independent of the road costs that emerge from the assignment process. A more
general modelling approach is to assume that the road trip matrix (or matrices)
depends on the (generalised) cost of travel; traditional model forms include, e.g.,
distribution or modal split models where the choice of destination and/or mode
depends on the road (plus other) costs. We refer to these as “variable demand
models” and we can write in very general terms
Equation 7.7
T = d (C )
where T is a general vector representing all o-d movements to be assigned and c

represents all o-d costs (by road). Traditional 4-stage models fall into this
category.
Equally the assignment procedure for a fixed trip matrix T may be thought of as a
process, one output of which will be o-d travel costs by road. These costs will
depend, via the levels of congestion, on the input trip matrix. We can therefore
think of the assignment as a network “supply” or “performance” model and write:
Equation 7.8
C = s (T )
In such a joint modelling approach we require that the demand and supply
processes are not only internally consistent but are also consistent between
themselves such that, using * to denote joint equilibrium.
Equation 7.9
T * = d (c* ) (a)
and
c* = s (T * ) (b)
5120257 / Apr 15 7-18

Section 7
In other words, given a set of network travel costs c*, the demand model produces
a set of trip matrix (road) demands T* and, if we assign T* to the road network, the
resulting o-d travel costs are again c*. The demand and supply models are
therefore in “equilibrium”.
The general form of the demand and supply models is as sketched in Figure 7.2
indicating that demand decreases as travel costs increase and that travel costs
increase (congestion) as demand increases. The equilibrium we seek is at the
intersection of the two curves.
Figure 7.2 - Supply/Demand Equilibrium
Figure 7.2 is of course highly simplified and in two dimensions; in “real” models
both costs and trips are n z xn z matrices (with even further disaggregation possible
by, e.g. user class or time period). However the general principle of an
equilibrium intersection point still holds.
Note also in Figure 7.2 that a “fixed” trip matrix would correspond to a demand
curve which would simply be a vertical line. Equally the nearer the demand curve
(in this diagram) is to the horizontal the more sensitive are the demands to the
costs (and, as we shall see below, the more difficult it is likely to be to solve for the
joint equilibrium).
(Certain people may prefer to have costs along the X-axis and trips along the Y-
axis and, indeed, when considering demand curves on their own, this is probably
more natural. The concept of equilibrium holds either way; take your pick!)
In addition, provided we specify that the assignment or route choice must satisfy
the Wardrop Equilibrium conditions (7.1.1), the resulting model may be thought of
as being in “double equilibrium” such that both route and wider (e.g. whether to
travel by road) choices are in equilibrium with the resulting road costs.
5120257 / Apr 15 7-19

Section 7
SDM AND VDM MODELS: TERMINOLOGY

Demand models may be conveniently sub-divided into two categories:
♦ those where the number of trips by road for a specific ij movement T ij only
depends on costs by road for that ij pair; and
♦ those where T ij depends (directly or indirectly) on all costs.

An example of 1) would be modal split where the choice between road and public
transport for a single ij pair is a function only of the relative ij road and PT costs
but the choice of destination is fixed. An example of 2) would be a constrained
distribution model where, if the value of one T ij cell is reduced, then those trips will
be re-assigned to another cell.
We may also describe these two categories as being “separable demand” or “non-
separable demand” models in the sense that the cost-dependence in type 1) may
be separated by ij cell but not with type 2). Alternatively one can speak of type 1)
as an “own-cost” demand model. It has also become common to speak of type 1)
demand models as being “simple”.
For both these reasons our current (post January 2006) preference is to use the
shorthand abbreviations SDM and VDM to distinguish between types 1) and 2)
models respectively: DM for “Demand Models”, S for either “Simple” or
“Separable” and V for “Variable”.
Unfortunately there is a lot of alternative terminology for demand models in
common circulation and some confusion is virtually inevitable, even within the
SATURN Manual.
Thus originally SATURN allowed only for type 1) (SDM) models and these
became widely known as either “elastic” or sometimes “SATEASY” models.
However, on its own, elastic is not a particularly useful definition since (a) in a
sense all demand models are elastic in that they allow the trip matrices to be
“stretched”, and (b) there is a specific form of SDM known as Constant Elasticity
(7.7.1). In addition elasticity is a standard and well-defined economic concept
(7.7.5) which applies to all demand models. Despite these objections, and in
deference to past common usage, the documentation will use the terms “elastic
assignment” or “elastic equilibrium assignment” in addition to, or sometimes even
instead of, SDM.
In general the internal “elastic assignment algorithms” available within SATURN
apply only to separable demand models, although they have also been extended
– primarily as a demonstration of a general principle - to one particular form of a
variable demand model (singly constrained distribution; see Section 7.10). Thus
Sections 7.5 to 7.9 refer only to SDM models. However SATURN may also be
used in conjunction with a whole host of external VDM as described in Section
7.4.5.
The demand models available within SATURN generally require one or more
“other” costs rather than simply the costs by road. For example a modal split
model may need to have a matrix of ij costs by the public transport mode.
Sometimes, as in the case of incremental demand models (7.8), these may be
generated by other SATURN runs; however other times, as in the case of public
5120257 / Apr 15 7-20

Section 7
transport cost matrices, these will need to be generated by other models and
converted (as required) into SATURN matrix format.
We may also note at this point the general principles outlined above apply equally
well to multiple user class assignment where, potentially at least, each user class
may be modelled according to a different form of variable demand model or the
same form but with different parameters. See 7.9 for detailed instructions.
7.4.2 Equivalent Optimisation Formulations: Separable Demand Models

Thus far we have only specified the solution to the joint assignment and variable
demand problem as the point of intersection between (multi-dimensional) demand
and supply curves as illustrated in Figure 7.2. However it turns out that, subject to
certain restrictions on the properties of the supply and demand curves, the
solution point also has the property that it minimises a certain convex function.
This in fact simply extends the equivalence of Wardrop equilibrium assignment to
a minimisation problem as discussed in Section 7.1.1.
In particular, the restrictions on the form of demand curves are most easily
satisfied by separable demand functions although they may be further extended to
certain – but definitely not all – forms of variable demand functions. In other words
objective functions may be applied to SDM but not, in general, VDM.
The advantage of being able to represent joint assignment/demand problems as
minimisation problems is that it enables strictly convergent solution algorithms to
be developed, in the same way that the Frank-Wolfe algorithm (see 7.1.2) solves
for Wardrop Equilibrium. In fact the algorithms used in SATURN for joint
assignment/demand problems are basically extensions of the Frank-Wolfe
algorithm.
In very general terms the combined objective function may be written as:
Equation 7.10
T T
=Z ∫0
s (t )dt − ∫ d −1 (t )dt
0
where d-1(T) represents the “inverse” demand curve; i.e. if T = d(c) then c = d-
1
(T)*.
The first term in (7.10) is equivalent to the standard Wardrop Equilibrium objective
function (7.1); the second term represents the negative of the “area” underneath
the demand curve from 0 up to T. Both are illustrated individually in Figures 7.3a
and 7.3b respectively and, as they would appear at the equilibrium, in Figure 7.4.
-1
* Note that in our diagrams there is no difference between the curves d(c) and d (T); they differ only
in terms of which variable or axis is thought of as being the “independent” variable.
5120257 / Apr 15 7-21

Section 7
Figure 7.3 (a) - The supply-side objective function
(b) - The demand-side objective function
Note that in Figure 7.4 the area under the supply curve (represented by the
horizontal hatching) is positive while that under the inverse demand curve (the
vertical hatching) is negative. Hence at equilibrium the supply contribution is
exactly “cancelled out” by part of the demand contribution, leaving a “net” negative
contribution as illustrated in Figure 7.5.
Thus the problem of minimising the objective function (7.10) may be interpreted
geometrically as making the negative area in Figure 7.5 as large - in absolute
terms - as possible. Which, if you think about it long enough, implies taking T as
the point of intersection in Figure 7.5. (The “negative” area keeps increasing as
we go from 0 up to the point of intersection but if we go beyond the intersection
point the negative contribution from the demand curve is now below the positive
contribution from the supply curve - a bad thing from the point of view of
minimisation.)
A further, somewhat technical, implication of having both positive and negative
components in the objective function is that the final optimum value may turn out
5120257 / Apr 15 7-22

Section 7
to be either positive or negative or even near zero. We need to bear this in mind
when considering stopping criterion based on relative changes in the objective
function such as, see 7.1.5.
Figure 7.4 - The combined supply (horizontal lines) and demand (vertical lines)
objective functions at equilibrium
Figure 7.5 - The “net” (negative) objective function at equilibrium
7.4.3 Solution Algorithms

Almost all algorithms for solving the combined variable demand/assignment are
highly iterative in nature, involving not only “internal” iterations within the
assignment and/or demand models but also more “external” loops between the
sub-models themselves. It is the latter on which we shall focus here.
As illustrated in Figure 7.2 we need to find a (n-dimensional) point of intersection
between two sub-models. The most straight forward method, but not necessarily
convergent nor efficient, is to follow a “cobweb” technique where starting, say,
with an assumed set of link costs c(1) and hence o-d costs we iteratively:
5120257 / Apr 15 7-23

Section 7
Solve for the corresponding trip matrix (demand)

Assign that trip matrix to the network to obtain a new set of link flows plus costs
(supply) and return to step (1).
In more algebraic terms we may represent the process by:
Cijn → Tij( n ) → Va( n ) → ca( n ) → cij( n +1) →
We could equally start the iterative process with an assumed trip matrix T(1) such
that the first model carried out is supply (assignment), not demand.
However we start, the process may be terminated when (and if) the trip matrices
(or cost matrices, link flows, etc) are sufficiently close on two successive
iterations.
Diagrammatically, and in one dimension, the procedure is as illustrated in Figure
7.6 where, starting with assumed costs c(1) and the corresponding demand T(1)
represented at point A, step (2) above (supply) is represented by the vertical line
from A to B and step (1) (demand) by the horizontal line from B to C. Here
successive applications of the supply and demand sub-models take us through
successive points A, B, C, D, E, which spiral in towards the ultimate point of
intersection - equilibrium.
Figure 7.6 - A (convergent) cobweb set of demand/supply iterations
However convergence need not occur and the “cobweb” may spiral out in a non-
convergent fashion just as easily as inwards, as illustrated in Figure 7.7.
5120257 / Apr 15 7-24

Section 7
Figure 7.7 - A non-convergent cobweb set of demand/supply iterations
In fact it may be shown that (in one dimension) the cobweb converges (locally at
least) as long as:
∂s ∂d −1
−
∂T ∂T
and diverges otherwise. (Technically these are Lifschitz conditions.)
Convergence occurs, for example, if costs are relatively insensitive to the flows ( ∂
s/ ∂ T → 0), as would occur in an uncongested network, or if the demand is
relatively insensitive to the costs (- ∂ d-1/ ∂ T>>0), as would occur if the trip matrix
is fixed or nearly fixed and the demand curves are near to the vertical in our
diagrams.
In summary, cobweb techniques are relatively easy to apply but unreliable in
terms of their convergence properties. In the next section we consider some
simple modifications to the “pure” iterative cobweb.
7.4.4 “Damped” Cobweb Iterations

Clearly, in either Figure 7.6 or Figure 7.7, if, when we adjust the costs from A to B
or the demand from B to C, we could have selected the “correct” equilibrium cost
or demand which would be somewhere between A and B or between B and C
respectively then we would converge immediately. This, in a nutshell, is what
algorithms based on minimising the objective function (7.10) attempt to do. Thus,
instead of changing the trip matrix from its current estimate to the new estimate
based on the current costs (i.e. from B to C or from D to E), an intermediate or
averaged solution is generated. We may also refer to this as a “damped cobweb”.
In algebraic terms we may represent the averaging or “damping” of the demand
matrix on iterations n → n+1 by:
(1 − λ )T ( n ) + λ d (c ( n ) )
T ( n +1) =
5120257 / Apr 15 7-25

Section 7
as opposed to the “pure” demand change

T ( n +1) = d (c ( n ) )
The averaging parameter λ is, within an optimisation framework, chosen such that
the objective function (7.10) is minimised. This procedure is both efficient and
convergent, independent of whether the condition on derivatives is satisfied.
Alternatively it is possible to formulate “damped” cobweb algorithms whereby the λ

values above are generated according to some heuristic rule, e.g. λ = 0.5. The
most frequently used heuristic rule – although almost certainly not the most
efficient - is the “method of successive averages” where λ = 1/n (see also 7.2.2).
Other methods are described below.
Algorithms of this nature may be either “internalised” in the sense that all the
calculations are done within a single program or “externalised” in the sense that
the averaging and/or optimum calculations are carried out outside the assignment
programs with some degree of user intervention.
The cobweb algorithms used within SATALL and/or SATEASY are all internalised
based on the concept of minimising an objective function; they therefore require
no further user intervention as regards the choice of λ. Most of the documentation
in section 7 describes this methodology in some detail. However we give next a
short section describing alternative methods in which SATURN is linked to an
external demand model where more empirical cobweb methods must be followed.
7.4.5 External Supply-Demand Iterations for VDM
7.4.5.1 VDM Shells

We consider here the (not uncommon) situation where SATURN is being used
purely as a fixed trip matrix traffic assignment tool within a much larger modelling
framework which includes complex VDM demand model specifications which
cannot be included within the restricted set of demand models provided internally
within SATURN. The DIADEM model sponsored by the UK Department of
Transport (see also Section 15.51) is one such example but there are many more
examples of complex demand models which have been set up either as “DIY
projects” or within other transport modelling packages such as EMME.
Alternatively, the matrix manipulation facilities within MX may also be used to
carry out the basic matrix-based operations of demand models.
Such procedures may be said to embed the assignment within an iterative
external VDM “shell” as illustrated below in Figure 7.8.
5120257 / Apr 15 7-26

Section 7
Figure 7.8 – Schematic of a VDM-Shell
Thus the demand model generates a trip matrix (or matrices) based – in part – on
the cost matrix (or matrices) output by the assignment while the assignment or
supply model uses the matrix/matrices input from the demand model. (N.B. For
generality we refer here to cost matrices as output from the assignment to allow
for the possibility that, as discussed in Section 7.8.6, the demand model may
require several distinct matrices of, e.g., time and distance rather than just a
single minimum cost O-D matrix. Similarly we talk about trip matrices to allow for,
e.g., separate public transport assignment)
The implied iterative process is very similar to other processes within SATURN, in
particular the loop between the assignment and simulation sub-modules as
illustrated in Fig 9.1. To avoid confusion as to which set of iterations we are talking
about we shall refer to supply-demand “cycles” as opposed to assignment-
simulation “loops” and Frank-Wolfe “iterations” within an assignment.
The basic concept of an equilibrium between supply and demand models as
described in 7.4.1 still holds in Fig 7.8: the demand trip matrices generated by the
cost matrices must, when assigned, generate the identical cost matrices. However
the methods to achieve that equilibrium may need to be more empirical than the
algorithms used within SATURN, primarily since an equivalent objective function
formulation no longer applies. (But see reference 13 in Appendix C, Bates et al
(1999), for a discussion of situations where objective functions may be extended
to include more complex demand formulations.)
7.4.5.2 External VDM Cobweb Algorithms

Within Fig. 7.8 there are clearly options as to how the trip matrices passed from
the demand model to the assignment model are created. Thus it is possible for
5120257 / Apr 15 7-27

Section 7
users to set up their own versions of cobweb iterations (damped or otherwise) to

define the latest trip matrices.
We have already described two very common “damped” cobweb algorithms; i.e.,
the straightforward “averaging method” where λ = 0.5 and the “method of
successive averages” where λ = 1/n (see also 7.2.2). There are, however, several
alternative strategies which have been proposed over the years, the objective of
all of them being to achieve an acceptable degree of equilibrium in the shortest
possible time.
Thus the simplest method is not to damp the cobweb iterations at all so that, in
effect, λ = 1.0. Empirically this method appears to be most successful if the
demand model is relatively insensitive to assignment costs (low elasticity).
DIADEM uses a method known as “Algorithm 1” which basically starts with an
initial arbitrary value of λ , e.g., 0.5, and continues with the same value as long as
an “objective function” (a measure of convergence) continues to decrease. If,
however, the gap increases the value of λ is halved until a decrease in the gap is
obtained. For further details we refer you to the DIADEM Manual. The
convergence properties of Algorithm 1 with realistic demand and supply models is
a subject of some debate but there is evidence that beyond a certain point it tends
to “stick”.
Another technique is the “Fixed Step Length” Algorithm (FSL) whereby, as the
name suggests, an initial value is set for λ and that value fixed throughout all
supply-demand iterations. Thus the averaging method where λ = 0.5 and the pure
cobweb where λ = 1.0 are both examples of FSL. It has been shown by Hillel
BarGera and Dave Boyce (Solving a non-convex combined travel forecasting
model by the Method of Successive Averages with constant step sizes,
Transportation Research Part B, 40, 5, 351-367, (2006).) that FSL is guaranteed
to converge as long as a small enough value of λ is set.
Empirical work by DVV has suggested a formula λ = 1.0 / (1.0 + Ɛ) where Ɛ is a

global measure of elasticity in the demand model.
7.4.5.3 Reducing CPU time: “Relaxed” SATALL Convergence Criteria

One of the problems associated with external VDM models as opposed to
combined assignment-demand models based on minimising an objective function
is that the extra series of cycles between the demand model and the assignment
model inevitably leads to increased CPU time, generally – but not always – due to
the time taken by the assignment model.
One obvious answer to this problem is to minimise the number of external cycles
by designing a “clever” cobweb algorithm but this is somewhat outside the scope
of SATURN.
An alternative strategy to reduce total CPU time, which does involve SATURN, is
to recognise that there is very little point carrying out a very highly convergent and
accurate assignment within SATALL using a particular trip matrix if that trip matrix
is going to be significantly altered by the next cycle of the demand model. This
suggests that one should try to set easy (relaxed) assignment convergence
criteria for early loops of the demand-supply cycle but to tighten the convergence
5120257 / Apr 15 7-28

Section 7
criteria for the assignment as the overall convergence improves. (The same basic
idea is applied to the simulation-assignment loops within SATALL by using the
AUTONA option to set variable values of NITA dependent upon the overall gap
value; see Section 9.5.4).
Thus parameters such as MASL, ISTOP etc. etc. which control the overall
assignment-simulation convergence of a run of SATALL may need to be reset by
the cobweb “driver” at each repeated run of SATURN, as indeed may parameters
such as NITA which control the convergence of the assignment. There may be a
good case here for using KONSTP = 1 and setting a critical Gap value in STPGAP
as determined by the latest gap value achieved by the demand model.
The decision as to which parameters and how to select ”optimum” values is up to
the user, being essentially external to SATURN. In terms of a “mechanism” for
inputting those values into a new run of SATURN there are several possibilities.
For example, they could defined within a $INCLUDE file within &PARAM which
the controlling program could overwrite. Equally they could be set in a control file
for SATALL.
In a similar vein it may be possible to simplify each intermediate run of SATALL by
excluding certain options that are only required once the final trip matrix has been
obtained. For example, the SAVEIT option may only be necessary on the final run
(unless – see below – you are using WSTART).
Clearly best practice will only become clearer after considerable experimentation.
One example of such experimentation is the CASSINI program described in
15.54.
USING UPDATE AND WSTART WITH VDM

One should also note that making the maximum use of facilities such as update
and warm starts at every re-run of a SATURN assignment is strongly
recommended in order to reduce run times, particularly when changes in the trip
matrix from one external cycle to the next are relatively small. See sections 22.5.5
and 22.6.
However we strongly advise that warm starts should only be undertaken in
conjunction with OBA due to the extra overheads incurred by Frank-Wolfe to carry
out the extra SAVEIT assignment at the end of one cycle and the initial re-
assignment at the start of the next assignment cycle.
7.4.6 The Final Trip Matrix and Routes

At the end of a variable demand assignment a final estimate of the road trip matrix
T ij will have been obtained and assigned to give link flows V a. The link flows are
stored on the output .ufs file in the normal way and the trip matrix is output as a
separate .ufm file (see 7.12.1 and 7.12.3). The total number of trips within that
matrix are reported both within the lp files and also saved within the output .ufs file
where they may be printed via SATLOOK output options (11.11.4 and 17.9).
With respect to the output trip O-D file we note that any intra-zonal trips in the
input trip matrix are neither assigned nor subject to demand calculations.
Essentially therefore their output values are indeterminate. However, in order to
avoid losing them entirely, the input intra-zonal values are (post SATURN 10.4)
5120257 / Apr 15 7-29

Section 7
copied directly to the output trip matrix file. Similar considerations may also apply
to inter-zonal cells which, for one reason or another, are unconnected; see 7.5.7.
Unlike the normal fixed trip matrix procedures, elastic assignment does not (for
various technical reasons) record any information on the precise routes used to
relate V a to T ij as normally saved if SAVEIT = T.
However, in the case of VDM/elastic assignments, the routes may be estimated
by carrying out a final fixed trip matrix assignment using standard algorithms and
recording the routes used via a .ufc file (see 15.23). It is these routes and the
output trip matrix T ij which will be used in any post-assignment analyses, e.g.
select link analysis (11.8.1).
We may further note, as discussed further in 15.23, that the routes found in this
manner will not be 100% identical to those implied by the original elastic
assignment, nor equally will the flows produced in the final assignment be
identical to V a (although a very good approximation). It is therefore the V a
obtained from the elastic assignment which are retained as the “correct” link flows.
Finally we note, as also mentioned in 15.23, that the number of assignment
iterations used to calculate the final routes, strictly speaking NITA_S, may be
different from the number used in the assignments proper, NITA. Thus, and in
particular if you have set a relatively small value of NITA in order to reduce overall
cpu time, a better estimate of the final routes should be obtained by defining
NITA_S > NITA.
7.4.7 Further Recommended Reading

The notes given in this manual are not intended as a fully comprehensive guide to
either simple or variable demand modelling and users who wish to carry out such
modelling steps are strongly advised to read more widely. For general information
see, for example, “Modelling Transport” by J. de D. Ortuzar and L.G. Willumsen,
John Wiley and Sons. For a much more detailed analysis with particular
reference to logit models try Norbert Oppenhem’s “Urban Travel Demand
Modelling”, also John Wiley and Sons.
UK-based modellers may wish to refer to advice available on-line via WebTAG:
https://www.gov.uk/transport-analysis-guidance-webtag.
7.5 SDM Assignment:

We consider here the restricted or simple form of variable demand assignment, to
be referred to as “elastic” or SDM assignment, where the number of (vehicle) trips
from origin i to destination j is a ‘demand’ function of the cost (i.e., generalised
time) of (vehicle) travel between i and j only; hence:
Equation 7.11
Tij = f (cij )
This demand form corresponds most closely with a modal split model whereby ij
trips are selecting either road or public transport modes but the destination is
5120257 / Apr 15 7-30

Section 7
fixed. However, it could also be thought of as representing the decision as to

when to travel (departure time choice), whether to travel or not (frequency) or
whether to go as a passenger (occupancy). It does not, for example, fit into a
model of trip distribution where the choice of whether to travel from i to j is a
function of the costs to ALL destinations.
A “typical” example of a demand function might be a “power law” relationship
where the ratio of costs is raised to an "elasticity" parameter p:
Tij = Tij0 (cij / cij0 ) p (a)
Note that when c ij = c ij 0 then T ij = T ij 0; hence T ij 0 may be interpreted as the

expected number of trips if the costs are c ij 0. Generally c ij 0 would be taken as
equal to current (minimum as opposed to “forest”; see 7.8.1) costs, whereas T ij 0
could be a growthed up version of the current trip matrix; see 7.8.
INCREMENTAL VRS SHARE MODELS

Equation (7.11a) may also be described as “incremental” in that the solution point
(T ij 0, c ij 0) may be thought of as, say, the present-day or base year situation and
incremental changes in T ij away from T ij 0 are generated by incremental changes
in c ij away from c ij 0 . (Although the same equation might arise from a quite
different interpretation).
Other forms of demand equations within the general form of (7.11) may be better
described as “share” models; e.g. the classical logit model of mode choice
between road and public transport may be written:
T=
ij (
TijA exp(− β cij ) exp(− β cij ) + exp(− β cijPT ) ) (b)
where T ij A represents the total number of trips from i to j choosing between car
travel - cost c ij - and (fixed) public transport - cost c ij PT.
Slightly different algorithmic approaches are adopted within SATURN for
incremental and shared elastic models although the underlying basic principles
are the same. The two forms of demand models have different ranges of MCGILL
values: 1 - 4 for incremental, 10 and above for shared.
It must also be stressed that the choice of incremental vrs shared is very often a
question of convenience rather than implying fundamental differences. For
example the same logit model may be expressed as either an incremental or a
share model - the choice would be based on which method is most compatible
with the form of data provided; a method for converting between the two is
described in section 7.8.2.
On the other hand other forms of SDM models such as the constant elasticity
model - equation (7.30b) - are more difficult to interpret as share models since
there is no natural upper limit on the total number of trips; T ij goes to infinity as
costs go towards zero.
FURTHER PROPERTIES
Other functional forms and/or interpretations are of course possible; see Section
7.7.1. In particular, see 7.5.5, it is possible to subdivide the cells in the matrix into
5120257 / Apr 15 7-31

Section 7
those that obey the elastic demand equation and those that are fixed independent
of the cost. The latter cells are termed either “inelastic” or “frozen”.
As mentioned in 7.4 the problem in elastic equilibrium assignment is to determine
both a self-consistent set of route choices and demand choices.
Elastic assignment is of most use in the assessment of future year networks
where, say, a simple extrapolation of the current trip matrix leads to an extremely
congested network with extremely high travel costs. Elastic assignment provides
a method for keeping the trip matrix - the demand - within behaviourally realistic
limits.
The elastic assignment algorithms within SATURN were developed as a joint
project between the Institute for Transport Studies and WS Atkins, funded by DTp
and administered by TRL. The reports produced for this study provide a
comprehensive review of theory, algorithms and applications; copies are available
from DVV.
7.5.2 Solution Algorithms

This section describes the specific algorithms used by the SATURN programs
SATEASY and SATALL. Both incremental and share models are based on the
general principle of minimising an objective function as outlined in Section 7.4.2
and the iterative structure of 7.4.3. The precise details differ slightly between both;
see 7.5.4.
7.5.2.1 Excess Trip (Pseudo Link) Algorithms

For incremental models it essentially follows the “excess trip” formulation, but with
one or two new wrinkles introduced. Thus for every ij pair in the network an
additional “pseudo” link is introduced in order to carry the traffic that is excess to
the road network. This is illustrated in Figure 7.8.
Figure 7.9 - The “Pseudo Link” Representation of Elastic Assignment
For each origin-destination pair ij the maximum number of trips that might possibly
use the road network, T ij max, is calculated (see 7.5.3.1). These trips may then
choose either to travel through the "real" network or via the ij - specific “pseudo”
link. We denote these flows by T ij and E ij respectively. Hence T ij will become the
"actual" road trip matrix (although, in the algorithms used by SATURN, T ij is not
explicitly stored but may be calculated, when needed, as T ij max - E ij ).
5120257 / Apr 15 7-32

Section 7
Each pseudo link has a cost associated with it which depends on the flow
assigned to it, hence a pseudo cost-flow curve whose form is derived
mathematically from the inverse of the ij demand function.
The algorithm then, in effect, follows the Frank-Wolfe approach as with traditional
equilibrium assignment but with an extended network and a “fixed” trip matrix
T ij max. As with simple equilibrium models it works by minimising an “objective
function” which is calculated as the sum of the “standard” contribution from the
road network plus an extra contribution from the pseudo links; see 7.7.4.
It should be stressed that the pseudo links are only artefacts introduced by the
algorithm in order to solve the problem systematically; they have no precise
physical interpretation. They may also be thought of as a “pseudo matrix” whose
principle function is to define the number of trips on the road network (which
perversely they do by storing the number of trips which do not travel!)
7.5.2.2 Share Model Algorithms

For “share” models such as the logit model (7.11b) a slightly different approach is
used whereby a total ij trip matrix T ij A covering all possible choices is defined and
the demand for road travel T ij is stored more explicitly. A “shared” elastic model
may be seen more as a “hyper network” problem where the demand or choice
element may be represented by a component in series with the road network as
opposed to the pseudo-link representation where the added link is in parallel.
This is illustrated in Figure 7.9 where a contribution to an overall objection function
is calculated at point D and which depends on the share of a total demand T ij A
which chooses to use the road network T ij .
Figure 7.10 - Section of a “hyper network” for “shared” elastic assignment
Note that T ij A as used in the share model and T ij max as used in the pseudo-link
model are not the same thing; T ij A represents all possible ij trips including, e.g., all
modes whereas T ij max represents the maximum number by road. See Figure
7.10.
7.5.2.3 Notation
The notation adopted is as follows:
a road link
ca cost on link a
c ij minimum cost from i to j via the road network
c ij 0 a “reference” cost from i to j via the road network, e.g., the present day
cost
c ij FF c ij assuming free flow costs (hence a minimum cost)
d ij “cost” on an excess link ij
5120257 / Apr 15 7-33

Section 7
E ij “Excess” or “Pseudo” flow from i to j

F ij Excess flow from i to j (auxiliary solution)
f ij elastic demand function expressing trips as a function of costs
T ij = f ij (c ij )
g ij the inverse of f ij :
c ij = g ij (T ij )
ij pseudo link connecting origin i to destination j
T ij road trips from i to j
T ij o input “reference” trip matrix as used in the demand function
max
T ij maximum possible trips from i to j; hence the “fixed” trip matrix to be
assigned
Va flow on link a (averaged)
Wa flow on link a (auxiliary solution)
7.5.2.4 The Basic Pseudo Link Algorithm

We describe here the “pseudo link” algorithm as applied to incremental elastic
demand models explicitly. The variations necessary to deal with share models
are given in 7.5.4.
Step 1 Set all link costs to their free flow values and the iteration counter n = 1.
For each origin i:
1a) Calculate the minimum cost tree to each destination j; c ij FF represents
the minimum cost to j.
1b) For each destination j determine the maximum number of road trips
possible for that ij pair by solving:
Equation 7.12
Tijmax = fij (cijFF )
1c) Determine the number of trips to be loaded onto the road network:
Tij(1)
1d) Load T ij (1) onto the road network, accumulating the total link flows to
obtain the first set of road flows, V a (1).
1e) ‘Load’ the excess flow:
=
E (1)
ij Tijmax − Tij(1)
onto the excess link
ITERATIVE LOOPS
Step 2 Calculate the ‘current’ link and pseudo link costs:
5120257 / Apr 15 7-34

Section 7
Equation 7.13
ca( n ) = ca (Va( n ) ) (a)
=
dij( n ) gij (Tijmax − Eij( n ) ) (b)
Step 3 For each origin i:

3a) Calculate the minimum cost tree to each destination j - costs c ij (n).
3b) Calculate and load the auxiliary road trips for this iteration: Tij( n +1) to
obtain link flows Wa( n +1)
3c) and load the remaining flow

n +1)
Fij(= Tijmax − Tij( n +1)
onto the pseudo link
Step 4 Combine the previous ‘solution’ flows with the ‘auxiliary’ flows found in
Step 3 according to the equations:
Equation 7.14
(1 − λ )Va( n ) + λWa( n +1)

Va( n +1) = (a)
(1 − λ ) Eij( n ) + λ Fij( n +1)

Eij( n +1) = (b)
where λ is chosen to minimise the objective function Z(λ).

Step 5 Check for convergence; if not reached increment the iteration counter and
return to Step 2; else, stop.
7.5.3 Variations on the Basic Pseudo Link Algorithm

Each note refers to a particular step, or sub-step, in the algorithm 7.5.2.2:
7.5.3.1 The Maximum Number of ij Trips; 1b)

T ij max represents the maximum possible number of ij trips which will use the road
network and, from this point on, the algorithm may be viewed as a standard
assignment of a fixed trip matrix - T ij max - to a network which includes an extra
“pseudo” link for each ij pair.
Since T ij is a decreasing function of c ij , and the costs can never be less than their
free flow values c ij FF (assuming non-decreasing cost-flow curves) f ij (c ij min) with
c ij min = c ij FF must be an upper bound.
By “maximum” we refer specifically to the maximum number of ij trips which could
ever occur on the road, not to be confused with the maximum number of trips
over all modes, say, or the intercept of the demand curve with the c=0 vertical
axis. The different definitions of trips are illustrated in Figure 7.10 following
5120257 / Apr 15 7-35

Section 7
equation (7.11b), the logit model. The x-axis represents the cost of travel by road
such that when the cost by road equals the cost by public transport (including any
modal-specific constants) then the road demand equals half the total demand.
Figure 7.11 - A logit demand curve with critical points noted
If, as illustrated, the free flow road costs are less than the public transport costs
A
then T ij max will be somewhere intermediate between Tij / 2 and T ij A; if c ij FF > c ij PT
A
then T ij max < Tij / 2 . (Clearly the former will be more likely in practice.)
T ij max is basically an artificial value designed to keep the total number of trips
within the algorithm within realistic bounds and to limit the absolute values of the
resultant objective functions.
In theory one might be able to devise even lower bounds on T ij if we could predict
in advance the lowest values that c ij would take during the course of the algorithm.
However, since the values of c ij are themselves related to T ij max there does not
appear to be an easy solution. Possibly an area for further research.
7.5.3.2 The Initial Trip Matrix: REDMEN and FRED; 1c)

Under the strict application of standard Frank-Wolfe the “zeroth” iteration loads the
fixed trip matrix T ij max all-or-nothing onto either the pseudo ij link or the minimum
cost ij path. Hence:
=Tij(1) T=max
ij , Eij(1) 0 or vice-versa
However, all that is really required is that the starting point be “feasible”, i.e. that
all the trips in T ij max be loaded onto either the pseudo links or the real network.
Hence, if we already have an idea “T ij '” of what T ij will turn out to be and, more
importantly, a good idea therefore of the number of trips E ij = T ij max - T ij ' to be
eventually assigned to the pseudo links - we could start by assigning our
estimates of T ij and E ij onto the minimum cost paths in the “real” network and onto
the pseudo links respectively.
Empirically it appears that a “split” assignment to begin with leads to a much
improved overall convergence and it is therefore always used. The choice of T ij (1)
may be made in two ways:
5120257 / Apr 15 7-36

Section 7
If REDMEN = T then it is taken from an input trip matrix which represents a prior
estimate of T ij , for example from a previous assignment. The estimated trip
matrix may be defined by the Namelist parameter FILRED under &PARAM in
the network .dat file.
Otherwise (for incremental models only) it is set from the equation:
Tij(1) = Tij0 .FRED
where T0 represents the ‘inelastic’ or ‘reference’ trip matrix as used in the demand
function - see 7.7.1, equations (7.30a) to (7.30d).
If REDMEN = T it must be stressed that the input trip matrix (FILRED) need only
be an estimate but that the closer it is to the eventual output trip matrix, the better.
Equally if it is a very poor estimate there must come a point where using this
option turns out to be counter-productive. However, to date we have no empirical
evidence to suggest where the cut off point comes. Note that, in this context,
REDMEN may be regarded as a form of “kick start”; see 22.2.4.
N.B. See 7.5.6 for advice on using the REDMEN option in conjunction with
“frozen” cells (ICING = T).
If REDMEN = F then FRED is a uniform factor chosen to estimate the expected
growth or reduction (but usually the latter) in the final trip matrix relative to the
inelastic trip matrix. For example if you think elastic effects remove 5% of the trips
in T0 ij from the network then set FRED = 0.95. The default value of FRED is 1.0.
N.B. FRED is applied to incremental models only (MCGILL < 10).
Our advice would be, if feasible, to set REDMEN = T and to define an input matrix
FILRED; FRED would be a second choice.
7.5.3.3 Pseudo Link Costs; 2)

The calculation of the link costs c a follows the standard formulae as determined by
the flow-delay curves (user-set for buffer link, simulated for simulation turns) while
the pseudo link costs are related to the definition of the elastic demand function.
The functional forms for the 4 equations as used in SATURN are given in 7.7.3.
Note the pseudo link costs, as with all other costs used within elastic assignment,
are generalised costs and that furthermore they are expressed in units of
generalised time seconds.
7.5.3.4 The Iterative Road Trip Matrix: NITA_F and MASL_F; 3b)
Similar considerations to those given under 1c) apply here as well. Thus a “strict”
interpretation of Frank-Wolfe rules would lead to an all-or-nothing situation:
Equation 7.15
( n +1)
Tijmax cij( n ) 〈 dij( n )
Tij =
0 cij( n ) 〉 dij( n )
5120257 / Apr 15 7-37

Section 7
cij( ) 〈 dij(
n)
0 n
( n +1)
Fij =
Tij
max
cij( n ) 〉 dij( n )
Hence the maximum number of trips is assigned to either the pseudo link or to
the road network minimum cost route.
However, the pseudo/road split may be substantially relaxed by recognising that
the underlying principle of Frank-Wolfe is to increase the flow on the current
cheapest route. Hence, if the pseudo route is currently cheapest, i.e.,
Equation 7.16
cij( n ) > dij( n ) (a)
then we require more trips on the pseudo link:

Fij( n +1) > Eij( n ) (b)
and fewer trips on the network proper:
Tij( n +1) < Tij( n ) (c)
with the converse being true if the pseudo route is more expensive.
We can in fact guarantee that this condition is satisfied by setting
Tij( n +1) = fij (cijn ) (d)
i.e. set the road trips equal to the equilibrium demand corresponding to the current
minimum road costs. Thus:
n +1)
Fij(= Tijmax − Tij( n +1) (e)
That equation (7.16d) guarantees (7.16c) may be seen by reference to the fact
that by definition the current road trips T ij (n) and the current pseudo link costs are
“in equilibrium” in the sense that:
Tijn = fij (dij( n ) ) (f)
Thus, since T ij is a decreasing function of c ij , (7.16c) must hold if (7.16a) holds.

Two further parameters, NITA F and MASL F, extend the concept of a “good”
initial estimate of the trip matrix by retaining:
Tij( n ) = Tij(1)
(i) for assignment iterations n = 1 up to and including NITA_F.

for all assignment iterations for assignment-simulation loops 1 through MASL_F.
Both options are still experimental but early indications are that a judicious choice
of one or both variables may improve convergence rates. By default neither
option is invoked although we would recommend their judicious use.
5120257 / Apr 15 7-38

Section 7
OPTIMUM STEP LENGTH; 4)
In order to choose the optimum value of λ one may either use a routine which
explicitly minimises Z as a one-dimensional function of λ or - much more
conveniently - one may use a routine to find the “root” of the equation:
Equation 7.17
dZ =0
dλ
(The identical 2 options occur with the Frank-Wolfe inelastic assignment
algorithm). The equation for the derivative of Z with respect to λ may be written:
Equation 7.18
dZ
=
dλ
∑ C (λ )(W
a
c a
( n +1)
− Va( n ) ) + ∑ dij (λ )( Fij( n +1) − Eij( n ) )
ij
where:
(
ca ( λ ) =ca (1 − λ )Va( n ) + λWa( n +1) ) (a)
And
dij (λ ) =dij (1 − λ ) Eijn + λ Fij( n +1) (b)
Functional forms for d ij ( ) are given in 7.7.3; c a ( ) are the cost-flow curves as
defined by the user (or calculated by the simulation) for links in the road network.
7.5.4 Variations under Shared Demand Algorithms

The main difference between the algorithm used for incremental and share-based
demand functions is that the former explicitly defines pseudo links and pseudo link
flows which, in effect, define the current road trip matrix by subtraction from T ij max
whereas, with share-based functions, the road trip matrix and any other trip
matrices involved are stored directly.
In both cases the trip matrices assigned to the roads at iteration n corresponds to
the matrix consistent with the current o-d costs - equation (7.16d). The optimum
lambda value at each step follows the same principle of minimising an objective
function. Whereas the pseudo-link flows are averaged, equation (7.14b), the
share algorithms average trip matrices directly.
The parameters REDMEN, NITA_F, MASL_F, etc. described in 7.5.3.2 and
7.5.3.4 apply to both approaches. On the other hand FRED applies only to
incremental demand models.
7.5.5 Convergence Measures and Stopping Criteria

Convergence of the elastic algorithm may be monitored in precisely the same
manner as with the inelastic Frank-Wolfe (with the obvious proviso that any
summations over links must also include pseudo links). In addition a number of
other measures may be formulated which refer more specifically to either road or
pseudo links.
5120257 / Apr 15 7-39

Section 7
The order of the parameters, and their abbreviations, given below corresponds to
the columns in the elastic summary tables.
♦ The “normalised gap or delta function” as defined in 7.1.4 for inelastic

Wardrop Equilibrium and here extended to include pseudo links. The gap G is
the difference between current and minimum costs BEFORE division by the
total cost; DELTA is normalised by dividing by total cost.
♦ The uncertainty in the objective function ‘ε‘, “EPS” in the LP tables. See
equation (7.5), 7.1.5.
♦ The objective function Z (including pseudo links).
♦ FDZ, the percentage improvement in Z per iteration relative to Z.
♦ FIMP, the % improvement in Z relative to the uncertainty in the objective

function.
♦ Total road/pseudo trips
♦ A necessary condition for convergence is that the total number of trips on the
“real” network and the total number on the “pseudo” network reach stable
values - although clearly this is not a sufficient condition since changes in
individual ij values may be masked by an apparent stability of the total.
♦ DELTA-R, the delta function as evaluated only for trips through the real
network and therefore a measure of how near the current path flows are to
Wardrop Equilibrium (and therefore ignoring how near they are to demand
equilibrium).
♦ TIJ-AAD - the average absolute difference between the current road trips and
the number given by the demand function for the current costs, i.e.:
Equation 7.19
∑T
ij
n
ij − fij (cij( n ) )
♦ This is normalised by dividing by the total number of trips and expressed as a

percentage. It therefore monitors “demand equilibrium”.
♦ TIJ-AD - as 8) but with actual differences, not absolute differences.
♦ TxCij-AAD – as 8) but with each ij element weighted by its cost and then
normalised by the total vehicle-costs. (N.B. This is the equivalent of the
“%Gap” as used in the demand-supply equilibration program DIADEM.)
♦ Total travel cost over the real road network expressed in veh-hrs.
At convergence measures 1), 2), 4), 5), 7), 8), 9) and 10) should all tend to zero.
Stopping criteria are based on the same criteria as those for Wardrop Equilibrium
with a fixed trip matrix as listed in 7.1.5. Thus the user-set parameters NITA,
XFSTOP, FISTOP and UNCRTS all apply.
5120257 / Apr 15 7-40

Section 7
Note that all these convergence measures are internal to the assignment; i.e.,
they do not take into account any changes in costs introduced by the assignment-
simulation loops as within SATALL. For convergence of the loops please refer to
Section 9.9.1.
It is noted that to achieve satisfactory convergence of an elastic assignment often
requires many more iterations than an inelastic one; rather higher values of NITA
may therefore need to be used.
7.5.6 Frozen or Inelastic Trip Cells

A common problem in elastic assignment is that, if the network has been
‘cordoned’ at its outer boundaries, the ‘external trips’ which enter or leave at the
cordon points will experience large proportions of their actual travel costs outside
the network being modelled. This creates problems in using a single demand
function for both internal and external trips. One solution is to divide the matrix up
into two or more ‘user classes’ and define different functional forms and/or
parameters for each; see 7.9.
A simpler solution is to “freeze” certain cells within the trip matrix, e.g. external
trips, such that for those cells the trips are fixed according to:
Tij = Tij0
and are therefore, in effect, inelastic.

Frozen trips are defined by an input .ufm matrix where a cell value of 0 implies
that that cell is inelastic or frozen and any non-zero value (1.0 recommended)
implies that it is elastic.
N.B.In former versions of the documentation the definition of frozen/unfrozen cell
values was wrong and the 0’s and 1’s were reversed. Please check that if you
are using an “old” matrix to set frozen zones that the correct definition is being
used.
To invoke the frozen cells option you must (a) set the parameter ICING to true and
(b) define the frozen cell matrix (FILICE - see 7.12.3). Both may be most
conventionally done using &PARAM namelist input in the network .dat file.
Alternatively (and this is not highly recommended) the frozen cell matrix may be
set using the FREEZE option in the SATALL batch file (9.13). If both FILICE and
FREEZE are used (definitely not recommended!) then the file set by FREEZE
takes precedence.
If there are multiple user classes (NOMADS > 1) then the frozen cell matrix must
have the same stacking levels as all the other matrices, i.e., the parametric trip
matrix FILTIJ, the cost matrix FILCIJ, etc. etc.
We note that the frozen cell option may be applied to both incremental and
shared demand models, although in the latter case we recommend caution. Thus
in a shared model the output cell value T ij is set equal to the input trip matrix value
T ij 0 for frozen cells whereas for the un-frozen cells T ij 0 is “shared” between the
output T ij and the “other” choices; hence T ij 0 potentially has two roles – car trips
and total trips - and it may be easy for the user to confuse the two. An alternative
5120257 / Apr 15 7-41

Section 7
approach may be to use a multiple user class approach where the two roles are
explicitly differentiated.
By contrast in an incremental model T ij 0 should represent a good “central” value
for car trips such that freezing them at that value should not present conceptual
problems.
USING REDMEN AND ICING TOGETHER

If both the REDMEN (prior estimate of a trip matrix) and ICING options are used
simultaneously then, logically, the cell values set in the input prior matrix should
equal the values which will be set as fixed for the frozen cells; i.e., T ij R = T ij 0 .
Problems occur if the two values differ, in which case SATALL uses the frozen
values in preference to the prior estimates and prints statistics of the absolute
differences between the two.
N.B. This potential problem was not spotted prior to release 10.4.
“FROZEN” USER CLASSES

Note that, with multiple user classes, it may be desired to freeze (i.e., fix) an entire
user class. This could be done (although it is certainly not recommended) using
the ICING option by setting all the cells within the appropriate “STACKING level”
of the frozen matrix for that user class to 0. Alternatively, and much more simply,
one could set the appropriate value of MCGILL to 0; e.g., MCGILL(2) = 0
effectively freezes all trips for user class 2 by defining it as inelastic. See 7.9.
Note that the “belt and braces” approach of doing both together, i.e., setting
MCGILL(2) = 0 and defining frozen cells, results in a Serious Warning message in
the .lpt file but does not otherwise affect the results
7.5.7 Unconnected O-D Cells

It is possible that certain O-D cells will have positive values in the input trip matrix
but no route can be found, for example because the origin zone has no out-bound
centroid connectors or the destination has no in-bounds. Clearly such a situation
is not very realistic but when did realism ever have much to do with the way
networks and/or trip matrices are formulated? The question is what does
SATURN do in such situations.
In the case of origins which have (some) trips but no out-bound connectors the
input cell values are simply copied verbatim to the output T ij cells (as are any
intra-zonal cells, see 7.4.6). Clearly, however, such trips are not assigned. Note
that with incremental demand models (MCGILL < 10) this may be a reasonable
course of action; however with share demand models where the input trip matrix
represents, say, trips which are to be divided between road and public transport
this will clearly over-estimate road trips.
In the case where the lack of a connection occurs either at the destination or
somewhere en route there is a difference between incremental and share models.
In the former case the output T ij equals the input T ij (as above) but in the latter
case (based on the assumption that the O-D road costs are effectively infinite) the
output value of T ij is set equal to zero.
5120257 / Apr 15 7-42

Section 7
You may wish to quibble with these rules and want it done other ways; the point is
that this situation should never really arise in the first place.
7.6 More Complex Elastic Assignment Models
7.6.1 Basic Logit Models

Logit choice models are widely used in transport modelling for a range of
situations, e.g. choice of mode, choice of travel time etc. At its simplest level the
logit model of choice between car and public transport can be represented
diagrammatically in Figure 7.11 and by the equation:
Equation 7.20
Tij=
R
( )( ( ) (
TijA exp − β cijR / exp − β cijR + exp − β cijPT )) (a)
( ( (
TijA 1 + exp β cijR − cijPT
= ))) (b)
Figure 7.12 – A Simple Logit Model: Choice of 2 Modes
where T ij A represents the total number of trips from i to j choosing between road
(R) and public transport (PT), costs c ij R and c ij PT respectively. β represents a
“sensitivity” parameter. A very small value of β implies that travellers are relatively
insensitive to the differences in costs between the two modes; a higher value of β
implies that they are very sensitive and small changes in costs can lead to large
shifts in mode choice. [Note that in form given here β is assumed to take on
positive values.]
Note that, in principle, either or both costs could include “modal penalties” in
addition to the “real” network costs. In practice, if included the modal penalty
would consist of a fixed positive cost (independent of ij) to be added to the public
transport costs. It would also, as with all other “costs” used within SATURN, have
units of generalised seconds. See 7.6.5 for a more detailed discussion of cost
definitions.
Logit models of this form may be considered as “standard” and their applications
in SATURN are described further in 7.7.1; see equations (7.30a) and (7.30f)
where To is equivalent to TA/2 and TA respectively and co is cPT ij in both. Two
5120257 / Apr 15 7-43

Section 7
forms of extended logit model, which may also be represented within SATURN,
are described next.
7.6.2 Multinomial Logit Models

A multinomial logit model extends the choices in the simple logit model to two or
more choices but all “at the same level” as represented by Figure 7.12 and the
equation:
Equation 7.21
TijA exp ( − β cij1 ) / ∑ exp ( − β cijn )

N
Tij1 =
n =1
where the choices 1….N have costs c ij 1 … c ij N and, we assume, arbitrarily, that
choice 1 represents car travel.
Figure 7.13 - A Multinomial Logit Model
We further assume that the cost of travel by car is a function of the number of car
trips but that all other choice costs are fixed. Given these assumptions we may
transform equation (7.21) into a form equivalent to (7.20) by defining a “composite
cost” of all the other non-car modes ~cij by:
Equation 7.22
exp ( − β cij =
) ∑ exp ( − β c )
N
n
ij
(a)
n=2
1  N 

c
Or ij =
− ln  ∑ exp ( − β cijn )  (b)
β  n=2 
so that in equations (7.20) we substitute cij for cij .

PT
Thus a multinomial logit problem within SATURN may be transformed into a

simple logit model by first transforming the N-1 alternative cost matrices into a
single composite alternative cost matrix. To do so use the FORTRAN equations
options within MX(10.8.1) and apply the methods described in 7.7 with MCGILL =
11.
5120257 / Apr 15 7-44

Section 7
7.6.3 Nested Logit Models (General)

A nested logit model is one in which a series of choices are made in succession,
the set of available choices at one “level” being contingent upon the choice made
at the preceding “upper level”. The general structure for two levels is illustrated in
Figure 7.13.
Figure 7.14 - A Nested Logit Choice Model
For example the upper level choice might be one of mode - say, public transport,
car or walk - and the lower choice might be between peak and off-peak. Thus T ij12
would represent trips by car in the off peak (car = choice 1 in the upper level, off
peak = 2 in the lower level); T ij21 would be public transport in the peak, etc, etc.
The “nested” probability of choosing mode m at the upper level 1 and time period t
at the lower level 2, P mt may be written as (dropping the ij subscripts)
Equation 7.23
Pmt = Pm Pt
m
Where:
Pm = probability of choosing mode m
Pt = probability of choosing period t having already picked mode m

m
Starting at the bottom of the nest, time choice, we may write, as with previous logit
models (7.20) or (7.21):
Equation 7.24
exp ( − β 2 cmt ) / ∑ exp ( − β 2 cmt ′ )
Pt =
m t′
However at level 1 - mode choice - we now need to calculate “composite” costs

for the different modes available which are defined as “log sums” of the costs at
the next level down. Thus
Equation 7.25
 
( −1/ β 2 ) ln  ∑ exp ( − β 2cmt ) 
cm∗ =
 t 
Equation 7.26
5120257 / Apr 15 7-45

Section 7
exp ( − β1cm∗ ) / ∑ exp ( − β1cm′∗ )

Pm =
m′
Note that we use different β values at the two different levels, β 1 β 2 , associated
with mode and time respectively. For various theoretical reasons logic dictates
that β 1 must be less than β 2 , otherwise the “order” of the nest should be reversed.
Thus starting with the “real” o-d travel costs c tm calculated by mode and time
period, which we use directly at the lowest level, we proceed in stages to higher
levels where the costs used in the choice processes are composites of the costs
further down. If we had a model with three levels of choices, e.g. if car travel in
each time period were further subdivided into car driver/car passenger, then the
same principles of calculating the composite costs at each level from the
(composite) costs at the next level down would still apply.
At the level of “real” network costs these may be either “fixed” or “flow dependent”.
For example costs of travel by public transport modes are generally assumed to
be independent of the number of passengers per service as well as independent
of the levels of congestion on the road. On the other hand travel costs by road
are generally assumed to be dependent on the number of vehicles on the road -
and hence on the choice process. Models of any level of complexity and
interactivity may of course be constructed and algorithms for their solution
constructed from the basic SATURN building blocks in the same way that a
multinomial logit model (7.6.2) can be transformed into a simple logit model. For
the moment we will concentrate on one very basic form of nested logit model.
7.6.4 The Basic Nested Logit Model

Consider therefore a model of two levels, which we shall call “mode” and “time
period” but clearly could be anything you wish, with two choices within each level -
car/public transport and peak/off-peak. Further assume that we are specifically
concerned with a model of cars in the peak and that the costs of the other three
choices are fixed. This immediately simplifies the model in that the composite
cost for mode choice public transport is also fixed as it is the log sum of fixed
public transport costs in the peak and off peak. Denote car choice by 1, public
transport by 2 and peak/off peak by 1/2.
The choice model is as represented in Figure 7.14 with, and in what follows, the ij
subscripts dropped.
5120257 / Apr 15 7-46

Section 7
Figure 7.15 - The Basic SATURN Nested Logit Model
Costs are indicated as car/peak, c 11 , car/off peak, c 12 , and (composite) public

transport, c 2 . The relevant equations are now as follows:
Equation 7.27
c1∗ ( −1/ β 2 ) ln ( exp ( β 2 c11 ) + exp ( − β 2 c12 ) )
c1 ==
Equation 7.28
T1 = T exp ( − β1c1 ) / ( exp ( − β1c1 ) + exp ( − β1c2 ) ) (a)
(
T / 1 + exp ( β1 ( c1 − c2 ) )
= ) (b)
T2= T − T1 (c)
Equation 7.29
T11= T1 exp ( − β 2 c11 ) / ( exp ( − β 2 c11 ) + exp ( − β 2 c12 ) ) (a)
(
T1 / 1 exp ( β 2 ( c11 − c12 ) )
=+ ) (b)
T12= T1 − T11 (c)
Thus c 1 and/or c 1* is the composite car cost, T 1 is the total car trips and T 11 is the
total car trips in the peak period. Given that all the other costs are fixed, as
opposed to c 11 which depends on the peak car flows, we therefore have a “simple”
elastic demand model for car trips in the peak of the form given by equation
(7.11), i.e. T 11 is a function of “variable” costs c 11 only.
NOTATION
In order to minimise the number of parameter names used and to retain some
level of comparability with other forms of demand models (logit or otherwise)
SATURN makes certain compromises in the notation used when dealing with
nested logit models in what follows.
5120257 / Apr 15 7-47

Section 7
Thus at the lower level we introduce a parameter BETA_2 to represent β 2 and a

cost matrix “name” CKLFIL (/FILCKL) to represent c 12 , the alternative costs at the
second level. No problems there. We do however use c2 instead of c 12 to denote
that cost matrix in the equations from now on.
At the upper level we use the name BETA and the symbol β instead of β 1 and
denote the alternative cost matrix at this level by “name” CIJFIL (/FILCIJ) and
symbol co. This is in line with the other functions used which only require one
sensitivity parameter β and one alternative cost matrix. Apologies for any
confusion!
7.6.5 Generalised Cost Definitions: Logit vrs. Assignment

By definition the cost c ij R that is used in the logit models (or, indeed, any other
form of demand model) is the equilibrium O-D cost that is calculated within the
traffic assignment and is therefore based on the definition of cost, as used by the
assignment, i.e., as set by PPM and PPK to weight time and distance. However, it
may happen that the time/distance weights as calibrated by the demand model
may differ or that other components of road costs may need to be included. On
the one hand this may indicate basic inconsistencies in the model, i.e., that drivers
consider the definition of road costs along one route when they are deciding
whether to drive or take the bus but when they get behind the wheel they make
quite different route-choice decisions. On the other there may be rational
explanations.
For example, a logit-based mode choice analysis might indicate that the utility of
car travel increases with increasing distance. In terms of costs, this would imply
that costs decrease with distance, hence that PPK should take a negative value
and that drivers would prefer to use maximum distance routes (not very sensible
in terms of assignment!). However this may also indicate that the disadvantages
of public transport travel are positively correlated with distance in ways that cannot
be explained by other properties of the public transport service, e.g., in-vehicle
time, fares, etc. In this case the positive utility of distance for car travel is actually
due to a negative utility for public transport and should therefore not be used as a
component of route choice.
The solution in this situation may therefore be to treat the distance component as
fixed within the demand model – which, in the above case, would mean including
a positive distance cost component within the public transport cost matrix – and to
carry out the assignment using pure time (i.e., PPM = 1, PPK = 0). Alternatively, if
it is desired to do the assignment with weighted time and distance but the
“weights” are different in the logit model, then the situation would be more
complex in that the public transport distance component would have to be
“corrected” to allow for the fact that the car costs returned from the assignment
would also include a distance component. I leave it to you people to work out the
equations!
Users who are confused at this point should take expert advice: if you don’t know
what you’re doing, don’t do it!
It also needs to be stressed that the road costs are always in units of generalised
seconds (or “real” seconds in the case of time-only assignment) and that therefore
5120257 / Apr 15 7-48

Section 7
all other cost matrices must be converted into the same units. Equally all beta
values etc. must be in units of inverse (generalised) seconds.
7.7 Elastic Demand Functional Forms

This section lists the alternative demand and other related simple elastic formulae
as specified by the parameter MCGILL. All ij subscripts are dropped below; hence
T refers to T ij , c to c ij , etc. (Note that the default value of MCGILL, i.e., 0, defines
an inelastic or fixed trip matrix.)
7.7.1 Elastic Demand Functions

The following equations relate the number of trips T to the (minimum) cost of
travel on the road network c:
Equation 7.30
MCGILL = 1: Logit (Incremental Form)
(
T =2T 0 / 1 + exp β ( c − c 0 ) ( )) (a)
MCGILL = 2: Power Law or Constant Elasticity
T = T 0 ( c / c0 )
p
(b)
MCGILL = 3: Exponential
(
T T 0 exp − β ( c − c 0 )
= ) (c)
MCGILL = 4: Elastic Exponential

=T T 0 exp p ( c / c 0 − 1) ( ) (d)
MCGILL = 10: Nested Logit (see 7.6.4)
(
T 0 / 1 + exp β ( c1 − c 0 )
T1 = ( ))
(
T1 / 1 + exp β 2 ( c − c 2 )
T= ( )) (e)
(
( −1/ β 2 ) ln exp ( − β 2c ) + exp ( − β 2c 2 )
c1 = )
MCGILL = 11: (Shared) Logit (see 7.6.1)
(
T 0 / 1 + exp β ( c − c 0 )
T= ( )) (f)
where T0 and c0 (and c2) are user-specified reference or ‘parametric’ where T0 and
c0 (and c2) are user-specified reference or ‘parametric’ trip and cost matrices and
β, β 2 and p are “elasticity” parameters.
Note that in equations 7.30a to 7.30b if c = c0 then T = T0. Hence the point (c0, T0)
definitely lies on the demand curve; these demand forms are therefore essentially
“incremental” curves and (c0, T0) could therefore be interpreted as the “existing
situation”. Equally T0 may be thought of as the “inelastic” demand since if the
5120257 / Apr 15 7-49

Section 7
costs do not change or if T is independent of c then again T = T0. See 7.8 for
further advice as to how to define T0 and c0.
By contrast equations 5 and 6 are “absolute” or “share” demand form equations in
which T0 represents a total number of trips, from which a given “share” winds up
on the road network. Thus, typically, To as used for share models will be larger
than that used by the incremental - e.g. twice as big if the “average” share is 0.5.
See 7.5.1.
Note therefore that MCGILL = 1 and MCGILL = 11 both effectively represent
exactly the same logit demand model but 1 is expressed in an incremental form
and 11 as a share model. In the latter case the input trip matrix T0 would be twice
as big.
N.B. The above equations assume that ‘normally’ p will be a negative number and
β positive. If the input values have the ‘wrong’ sign, e.g., a positive POWER, then
the ‘correct’ sign is automatically used.
See sections 7.12.2 and 7.12.3 for the definitions of the Namelist “names” used to
set β, c0 etc within SATURN.
Box-Cox Transformations
An alternative form of simple elastic demand model using what is known as a Box-
Cox transformation has been coded into elastic assignment with MCGILL = 5 but
its use is highly experimental. Most of the work was carried out by an MSc student
Pete Kidd in the 1990’s for his dissertation (indeed an excellent dissertation!) and
then incorporated by DVV into the code proper. So blame me for any mistakes!
What follows is probably a highly unreliable description of what Box-Cox does
based on faulty memory, Wikipedia and an interpretation of the code.
Basically a Box-Cox transformation is a continuous transformation of a variable x
between, at one extreme, the linear function x and, at the other, log(x). More
precisely we transform c into c’ via:
C’ = (c** λ – 1) / λ c**( λ-1)
Where λ varies between 0 and 1.0 and in SATURN is defined by the namelist
parameter BETA2
What we do in elastic assignment is to substitute a Box-Cox transformation for the
OD costs c and c0 in the logit demand equation 7.30a. If BETA2 = 1 c and c0
remains as is the model remains a pure logit model but if BETA2 = 0 c and c0 are
transformed into log(c) and log (c0) and mathematically equation 7.30a becomes:
T = 2 T0 / (1 + c**β / c0**β)
= 2 T0 / (1 + (c/c0)** β)
In other words T() is now a function of the relative change in costs rather than the
absolute change in costs as per the logit model and therefore much nearer (but
not identical) to the power law or constant elasticity model, equation 7.30b.
Therefore what Box-Cox enables one to do is to move continuously between a
model based on absolute cost changes to relative cost changes. Which, to my
5120257 / Apr 15 7-50

Section 7
mind, is a major advantage since basically I don’t believe that trip makers perceive
compared costs in an absolute sense, more in a relative sense. But what do I
know? See 7.8.5.1.
7.7.2 Inverse Demand Functions

For every demand function there is an inverse function giving the costs as a
function of the road trips.
Equation 7.31
c = g (T )
1)
 (
c 0 + ln ( 2T 0 / T ) − 1  / β
c=
 ) (a)
c = c 0 (T / T 0 )
1/ p
2) (b)
3) c c 0 +  ln (T 0 / T )  / β
= (c)
4) c c 0 + ( c 0 / p ) ln (T / T 0 )
= (d)
5) Not available in simple form (e)
6)
 (
c 0 + ln (T 0 / T ) − 1  / β
c=
 ) (f)
7.7.3 Pseudo Link Cost-Flow Functions

These relate the cost d on the pseudo link to its flow E (which is itself related to
the flow T on the road network by the equation E = Tmax - T). In general terms we
have:
Equation 7.32
d ( E ) g (T max − E )
=
1)
 ((
d =c 0 + ln 2T 0 / (T max − E ) − 1  / β
 ) ) (a)
2) d c (T (
− E)/T 0 )
1/ p
= 0 max
(b)
3)
 (
c 0 + ln T 0 / (T max − E )  / β
d=
 ) (c)
4) d= (
c 0 + ( c 0 / p ) ln (T max − E ) / T 0 ) (d)
5) Not available in simple form (e)

6) c 0 +  ln ( E / T 0 − E )  / β
d= (f)
7.7.4 Pseudo Link Objective Functions

The total objective function (7.10) which the elastic algorithm seeks to minimise
may be written as a sum of terms from “real” links a and “pseudo” links ij:
5120257 / Apr 15 7-51

Section 7
Equation 7.33
=Z ∑ Z (V ) + ∑ Z ( E )
a
a a
ij
ij ij
The functional forms Z a (V a ) are as in standard Wardrop Equilibrium assignment.

(See 7.1.1)
The equations for the contribution to Z from an individual ij pair, i.e. Z ij (E ij ), are
given below. To simplify the equations for the incremental models (MCGILL
equals 1 to 4) we shall make use of the flow on the road network, T, as defined by
Equation 7.34
=
T T max − E
1) Z ( E ) = c 0 E +  h (T ) + h ( 2T 0 − T ) − h (T max ) − h ( 2T 0 − T max )  / β (a)
where h ( x ) = x log x
2) Z ( E ) c ( (T ) ) (T ) − T  / q
0 −1 p max q
= 0 q
(b)
 
where =
q ( p + 1) / p
but for p = −1
Z ( E ) = c 0T 0 ln (T max / T )
3) Z ( E ) = c 0 E +  E + T max ln (T 0 / T max ) + T ln (T / T 0 )  / β (c)
4) Z (E) =c 0 E − ( c 0 / p )  E + E ln T 0 + T ln T − T max ln T max  (d)
For share models the objective functions are calculated directly as functions of T,
the flow on the road network, plus, in the case of the nested logit model, the flow
allocated to the alternative choice at the lower level, denoted by T 12 (see equation
(7.29c)). Hence in the latter case T and T 11 are synonymous, and we use T 11 by
preference.
5)
(
Z (T11 , T12 ) = T12 c 2 + T2 c 0 + T11 log (T11 / T1 ) + T12 log (T12 / T1 ) β 2 + T1 log (T1 / T 0 ) + T2 log (T2 / T 0 ) / β )
(e)
where T=1 T11 + T12

T=
2 T 0 − T1
( )
6) Z (T ) = T − T c + T ln T / T
0 0
 ( 0
) + (T 0
( )
− T ) ln (T 0 − T ) / T 0  / β
 (f)
5120257 / Apr 15 7-52

Section 7
7.7.5 Elasticities
The ‘elasticity’ of trip demand with respect to changes in cost is defined by
Equation 7.35
e = ( dT / T ) / ( dc / c )
where dT represents the change in the number of trips T in response to a change

in costs of dc in c. Since T is a decreasing function of c e must be negative
although it is not uncommon for non-economists to refer to its absolute values (the
reason why SATURN allows positive values of POWER and BETA but converts
them into negative).
With the simple power law function the elasticity is a constant over all ij pairs and
equal to the parameter POWER; with the other functions elasticity is a function of
both T ij and c ij and the following functions apply:
1) ( )( (
− β c exp β ( c − c 0 ) / 1 + exp β ( c − c 0 )
e= )) (a)
− β c ( 2T 0 − T ) / 2T 0
=
2) e= p (b)
3) e = −β c (c)
4) e = pc / c 0 (d)
5) e e1 (T11 / T1 ) + e2
= (e)
where e 1 and e 2 are the elasticities in the upper and lower levels respectively and
may be given by equations such as (7.35a) or (7.35f). For the definitions of T 11
and T 1 see section 7.6.4.
6) ( )( (
− β c exp β ( c − c 0 ) / 1 + exp β ( c − c o )
e= )) (f)
− β c (1 − T ) / T 0
=
The alternative versions of equations (7.35a) and (7.35f) which use trips T (or,
strictly speaking, proportions of trips choosing car travel) in addition to costs are
based on standard results from logit theory and are certainly easier to work with
then those based entirely on costs.
7.7.6 Empirical Elasticities

Elasticities may also be calculated empirically. In SATEASY/ SATALL this is
done (pre-assignment and - see below - post-assignment) by calculating the total
numbers of trips with the cost matrix c ij = c ij 0 and with c ij = 1.01c ij 0; the difference
in total number of trips provides a measure of dT in equation (7.35). In the case of
multiple user classes the empirical elasticities may be disaggregated by user
classes (11.11.7). The values are printed within the .lpt/lpa output files.
In the case of the power law or constant elasticity model (MCGILL = 2) the
empirical elasticity should correctly equal the input value (POWER), in which case
5120257 / Apr 15 7-53

Section 7
there is very little point in carrying out the calculations. However for other model
forms the relationship between, say, BETA values and the elasticity is not direct
and the empirical values can be a useful guide (see also the final paragraph in this
section).
Note however that for all cases apart from MCGILL = 2 the elasticities are not
constant but depend on the point on the demand curves where the calculations
are made, i.e., on the road costs and/or number of road trips. Ideally one would
probably prefer the elasticities to be calculated using the actual output costs and
trips from the elastic assignment. However the first set of values reported by
SATALL are those that would apply if the costs of travel by road equal c0 which
are not necessarily all that close to the output costs.
In the case of (most) incremental models those costs are probably fairly close to
the final costs given the manner in which they would have been defined and the
reported elasticities should be good estimates. However for the various forms of
logit choice models (MCGILL = 1, 10 or 11) the costs c0 may represent costs, say,
by public transport, in which case they may be a long way away from the “true”
road costs and any elasticity calculated at those costs need to be taken with a
large pinch of salt.
For this reason for MCGILL = 10 or 11 (i.e, shared demand models) the empirical
elasticities are also calculated after the assignment has taken place and using the
minimum ij road costs in place of c0. These elasticities are therefore more realistic
and may differ considerably from those reported pre-assignment. They are also
reported within the lpt/lpa files.
It should also be remembered that elasticities vary by od cell (except of course for
the constant elasticity form). Elasticities may, in principle, be calculated cell by cell
using the equation editor in MX based on the “correct” costs and/or road trips and
trip-weighted averages obtained.
In order to detect consistent differences in elasticities by trip length (with logit-
based models elasticities increase with cost; see equation 7.35a) the reported
empirical elasticities are disaggregated by cost bands expressed in terms of
generalised costs in minutes – new in 10.8.20. These are printed within the .LPT
files. Note that the differences, especially with logit models, may be significant and
users may wish to consider this in their choice of: (1) the form of the demand
model and (2) the calibration parameters.
The calculated empirical elasticities are stored within the output .ufs files and may
also be accessed within the network parameters printed by SATLOOK. In the
case of MCGILL = 10 or 11 the values stored are those calculated post
assignment as explained above.
We note again that POWER is very closely associated with elasticity (and exactly
equal for MCGILL = 2) and therefore (a) is assigned very similar values of the
order of, say, -0.5, and (b) is unitless. By contrast BETA is only a parameter which
defines elasticity in part and (a) has units of inverse generalised cost and (b) takes
values which bear no direct relationship to the value of the intended elasticities.
If the empirical elasticity is extremely high (in absolute terms), e.g., -10.0, then
SATALL may refuse to run on the grounds that: (a) it may fail due to problems
with numerical underflow or overflow and (b) it is most unlikely that this is what the
5120257 / Apr 15 7-54

Section 7
user actually wanted to do. The two most common causes of extreme elasticities
(either very high or very low) are: (a) users confusing BETA and POWER and
therefore setting BETA to an appropriate value of POWER or vice-versa, or (b)
defining BETA values in the wrong units (e.g., inverse minutes rather than inverse
seconds).
7.8 Defining the Reference Trip and Cost Matrices

The first point to be made is that the choice of a functional form for the demand
function and of the files and parameters necessary to specify it is entirely up to the
user. Elastic assignment is very much a situation where the user must tell the
model/program what to do, not the other way round. The purpose of this section
is therefore purely to offer advice to users who (of course!) know what they want
to do but (naturally!) may be a little uncertain on the way to go about it.
The second point is that the use of a superscript 0 to define T ij 0 and C ij 0 should not
be taken as implying that they necessarily represent a “base point”, e.g. a do-
minimum scenario in year zero. They are parametric or reference matrices used
to define a demand function; in some situations they may be conveniently defined
as a base point, in others not. In certain situations they may also depend on the
scenario; e.g. a “do something” land use scheme may affect growth factors for
certain O’s and D’s and hence influence the definition of T ij 0.
It is also important to remember that cost matrices must be defined as generalised
costs with units of seconds. Care must therefore be exercised when importing
cost matrices (e.g., public transport cost matrices) from other suites of programs.
Their interpretation also differs in some respects between the incremental model
forms (MCGILL = 1 to 4) and the shared forms (MCGILL = 10 or 11); we consider
these separately.
7.8.1 Incremental Models

In general terms the elastic demand function represents a situation where, all
other things being equal, the number of trips is expected to decline when costs
increase although the precise mechanism (change of travel time, change of mode
etc.) is not specified. A common property of all the 4 incremental demand
functions in these cases is that if the ij costs = c0 ij then the ij flow = T0 ij ; this
defines one point on the demand curve. This is illustrated in Figure 7.15.
5120257 / Apr 15 7-55

Section 7
Figure 7.16 - An “incremental” demand curve in the base year
The most obvious example of finding a point on the demand curve is the base
year where the trip matrix is known (by whatever means) and the corresponding
costs are obtained by running SATURN for that base year. Hence T ij o is the base
year trip matrix and the reference cost matrix c0 is obtained by skimming the
minimum* costs from the base year; e.g run:
SATURN basenet basetij
and
SATCOST basenet basecij
(where the procedure SATCOST is described in section 15.27.7). By implication

the point (c0, T0) also lies on the “supply curve” for that network as sketched in
Figure 7.2.
Note that in this situation only the one point on the demand curve (c0, T0) can be
observed directly since that is the only point which actually exists; the rest of the
demand curve can only be constructed indirectly by asking questions such as:
“What would happen to demand if costs increased by 10%”. Thus we have a
demand curve for the base year d B(c).
We should also note that although (c0, T0) may be the only point that actually
exists it is not necessarily the only point that may be used to define the demand
curve in mathematical terms. Thus with the simple constant elasticity demand
curve (7.11a) we could obtain exactly the same demand curve by replacing T0 by
2T0 and c0 by c0 21/P. Here (c0 21/P, 2T0) equally lies on the demand curve and
may be used just as easily to define the curve. In some respects this is a useful
property for a demand curve and one to which we return below (7.8.5).
For certain types of scenario tests we only need to have the base year demand
curve. For example if you need to know the effect of implementing road tolls or
* Note that the costs defined in this way should always be minimum costs as opposed to average
costs as taken over the "forest" of used routes.
5120257 / Apr 15 7-56

Section 7
changing traffic signals now (which effectively alter the supply curve) then you
require the new equilibrium point between the new supply curve and the existing
demand curve. Thus, Figure 7.16, if we shift the supply curve from S1 to S2 we
change the equilibrium point from (T 1 *, C 1 *) to (T 2 *, C 2 *)
Figure 7.17 - New Supply Curves: A New Equilibrium
In this case (since S2 is above S1 implying higher costs) we have both increased
the equilibrium costs (C 2 * > C 1 *) and decreased the demand for trips (T 2 * < T 1 *).
Note that had we modelled the new scenario with fixed trips we would have
wound up at the equilibrium (T 1 *, C 2 F) which would imply higher costs than in the
“correct” equilibrium state.
FUTURE YEARS
For future years the demand curve must also allow for exogenous growth, e.g
through increased housing, employment or car ownership via growth factors which
implicitly assume that travel costs do not change. Thus we might predict a
uniform 10% growth in the trip matrix by some future year if there is no change in
congestion. We may therefore construct a future year demand curve dF(c ) from
the base year demand curve dB(c) by simply applying a factor of 1.1 to all demand
values on the curve. See Fig. 7.17. Thus the point (c0, 1.1T0) should definitely lie
on the new demand curve.
5120257 / Apr 15 7-57

Section 7
Figure 7.18 - Base Year and Future Year Demand Curves (dB and dF) plus Alternative
Supply Curves S1 and S2.
However, this is not to say that the point (c0, 1.1T0) is a valid forecast of some
future scenario since it does not take into account the extra congestion generated
by the extra 10% traffic demand which will alter the costs. It simply says that if
the costs remain as they are in the base year then trips will grow by 10%. Elastic
assignment introduces the effect of added congestion.
Thus in Figure 7.17 if point A - (c0, T0) - represents the base year equilibrium point
E represents the future year scenario - (c0, 1.1T0) - if costs remain fixed. However
if the network continues to operate according to supply curve S 1 we would wind
up at point B in the future year with: (a) higher costs than c0 and (b) fewer trips
than 1.1T0. In this case the elasticity effects are suppressing trips.
Equally if we consider alternative network scenarios as represented by supply
curve S 2 in Figure 7.17 then the future year equilibrium would be represented by
point D - in this case fewer trips and increased costs relative to point B.
Note therefore that points E, B and D all lie on the future year demand curve and
that all three represent equally valid forecasts of future year traffic levels given
certain assumptions about what the costs will be.
To define the future year demand curve using as input a reference cost matrix and
a reference trip matrix you are recommended to use the base year cost matrix c0
for the future year as well but the future year reference trip matrix would be the
base year matrix factored by 1.1; use MX to do this. (The alternative use of
GONZO = 1.10 is feasible but not recommended since if you start to compare
future year elastic and inelastic trip matrices it can be very confusing trying to
remember whether they include a GONZO factor or not).
5120257 / Apr 15 7-58

Section 7
7.8.2 Base Year Logit Models

Another, more explicit, application of SDM elastic assessment is to model modal
split, e.g via a logit equation of the form:
(
Tij= TijA exp ( − β cijR ) / exp ( − β cijR ) + exp ( − β cijPT ) ) (a)
( (
TijA / 1 + exp β ( cijR − cijPT ) )) (b)
where the superscripts R and PT represent road and public transport and T ij A
represents the total number of ij trips. See 7.6.1. As noted in 7.5.1 the public
transport costs could include a (positive) perceived modal penalty.
Logit models may be represented either in an incremental or shared form - and in
some respects the latter formulation, discussed in 7.8.4, is more “natural”. The
following considers it primarily in the incremental form (MCGILL = 1).
Comparing equation (7.20b) with the incremental logit equation (7.30a) it can be
seen that c0 is equivalent to cPT and T ij A to 2T0. Hence in this case the reference
trip matrix refers to public transport costs and would need to be obtained from a
public transport assignment program such as SATCHMO. Equally we would need
to define T0 ij = TA ij /2.
Note that in this case the necessary reference matrices T ij 0 and c ij 0 should
certainly not be interpreted as a base point for road traffic since they do not
correspond to any “real” observed values of road trip matrices or costs - except in
the most unlikely case of all road costs being identical to public transport costs
and the modal split therefore being 50:50.
However, in the event that we know the base-year road trip matrix and road costs,
which we will denote by Tb and cb, and we know the total number of trips TA (e.g. if
we know the “share” of road trips) then we can work out the (unknown) public
transport cost matrix cPT = c0 by the matrix transformation (e.g., use MX):
Equation 7.36
(
cb − (1/ β ) ln (T A − T b ) / T b
c0 = )
The logit demand curve is sketched in Figure 7.18 where both the base year point
(cb, Tb) and the reference point (c0, T0) lie on the curve. Note that to specify the
precise form of this demand function a single point on the function (plus a value
for β) is not enough, we need extra information to specify TA.
5120257 / Apr 15 7-59

Section 7
Figure 7.19 - A (base-year) logit demand curve
The extra information might be obtained totally exogenously through a knowledge

of the “share” at Tb, i.e., the share of car trips in the base year for each ij cell. In
these cases, since we “know” cb, TA and Tb in the base year, we can obtain the
required matrix c0 by matrix manipulation. Note that, if the share of car trips is
greater than 50% (poor public transport competition), then c0 > cb; but if the share
is less than 50% (strong competition) then c0 < cb. Indeed, if the car share is very
small then c0 may go negative and some care may need to be taken that the cost
matrix is not constrained to non-negative values.
On the other hand it is of course quite possible to use a logit demand model as a
“pure” incremental model in which case T0 and C0 may be taken to be the base-
year road trip matrix and its associated costs respectively. In this there is an
implied assumption that the current matrix is 50% of some total trip matrix.
However from a more empirical point of view, and in particular given the fact the
“active” part of the demand curve is very likely to be that in the vicinity of (c0, T0)
(i.e. costs of zero are not possible so the demand is never likely to get anywhere
near 2T0), then we can think of equations such as (7.30a) purely as convenient
analytical forms allowing the number of trips to decrease or increase as costs
increase or decrease.
What is important to realise is that the incremental logit equation (7.30a) does not
“tie” the user to an implied 50:50 share model. As explained earlier other forms,
using matrix transformations, are possible.
7.8.3 Forecast Year Logit Models

Extrapolating a base-year logit curve to a future year logit curve follows the same
principles as in 7.8.1 if we assume that road demands increase by, say, 10%
across the whole range of possible road costs and if the alternative mode (public
transport) costs remain fixed. Thus the reference cost matrix remains the same
as in the base year while the reference trip matrix T0 in equation (7.30a) is
factored by 1.1.
5120257 / Apr 15 7-60

Section 7
Note, from a purely technical point of view, that it may be possible to factor a base
year trip matrix by setting GONZO = 1.1 (say). However, this is not
recommended.
7.8.4 Share Models

With the share models, MCGILL = 10 or 11, the interpretation of the input trip and
cost matrices is more constrained since they represent a simple (2-level, 2-choice)
nested logit model and a basic logit model respectively.
Hence T ij 0 in equations (7.30e) and (7.30f) represents the total number of trips
between i and j with certain (user-defined) choices to be made. Hence it is the
equivalent of TA in Figure 7.6, not T0. In the base year this might represent an
observed matrix (aggregated over all choices); in an alternative/future year
scenario it could represent the base year matrix suitably growthed up either
uniformly or by origin or destination to represent specific local schemes.
The interpretation of the alternative or “parametric” cost matrix (or matrices with
nested logit) is also more constrained since it/they must represent the cost(s) by
well-defined alternative choices. Hence they are not base-year road costs
(although, as with equation (7.36) they may be inferred from road costs given
sufficient extra information.
Since the alternative costs are not road related their values in future years will
need to be determined by the user. Thus if c0 represents costs by public transport
it may be necessary to calculate them based on future year levels of service, fares
etc.
7.8.5 Choice of Demand Function

The most important single consideration in establishing a demand function is to
get the right degree of sensitivity of demand to costs, the best single measure of
which is elasticity. At a global level, i.e. in terms of the total number of trips by
road, it is possible, by a judicious choice of β and/or p parameters, to make all
demand functions “look” very similar as long as the costs do not diverge too much
from their “base” levels. However if we look at the different functions at a more
disaggregate level, e.g. origin or o-d level, then marked differences do appear
between the different functions as discussed below.
7.8.5.1 Absolute vrs Relative

The logit and exponential demand functions - (7.30a) and (7.30c) - are functions
of absolute differences in costs while the power law and elastic exponential forms
- (7.30b) and (7.30d) - depend on the relative differences or cost ratios. Thus in
the latter case there is no difference between costs which change from 10 to 11
minutes or from 100 to 110 minutes. With an absolute function 100 to 110
minutes would have (effectively) 10 times the impact as 10 to 11.
This implies that absolute models will tend to have a greater effect on long
distance trips than short simply because long distance trips include more links
which can contribute to cost differences. However this may depend on the type of
policy being tested. For example if the cost changes are due to tolls on a single
link or a cordon which is crossed only once then all trips will experience the same
5120257 / Apr 15 7-61

Section 7
increase in cost (or zero), in which case, relatively speaking, short distance trips
will be greater affected with a relative model.
This is not to say that absolute models are better than relative or vice-versa;
beauty is in the eye of the beholder and you need to make up your own mind.
But, at the very least, be aware of possible differences.
7.8.5.2 Limiting Values

The functions differ further in how they behave in the limits of very high and very
low costs. Thus at zero cost the power law demand goes to infinity whereas all
other models approach finite values. This may seem a fairly “academic”
distinction in that zero-cost trips do not exist in real life, at any rate between zones
by car. However they may well crop up in models.
Thus in network models it is certainly not unusual for two zones to be attached to
the same node, in which case their o-d costs are likely to be “modelled” as zero.
Alternatively they may be connected at opposite sides of a single simulated turn
with a delay of very near zero, in which cases any changes at that node which
lead to finite delays (e.g. converting a priority junction to signals) may lead to very
large and presumably very unrealistic changes in the demand.
This should not be seen as a reason why not to use power law functions; however
it is a factor that the user needs to be aware of and to guard against.
Equally at very high costs the exponential functions will tend to go to zero more
rapidly than the power functions although, since the absolute numbers of trips will
be near zero in either case, the differences will be less pronounced.
7.8.5.3 Base Independence

All the elastic demand functions in 7.7.1 may be written in the general form:
T = T 0 f ( c, c 0 )
where, by definition, f(c0, c0) = 1. The point (T0, c0) may be thought of as a “base”
or “pivot point” through which the demand function must pass. It turns out that
some, but not all, of the functions in 7.7.1 have the additional property of being
“base independent” in that any point on the demand curve may be chosen as the
base point and the identical function is produced.
For “base dependent” functions (T0, c0) has a more precise definition so that, in
practical terms more care is needed on the part of the user to specify them.
To illustrate, consider the constant elasticity form (7.30b):
T = T 0 ( c / c0 )
P
(
T = T 0 / ( c0 )
P
)c P
T = X 0c P
In this case we need only one value X0 to specify the form of the demand function
(assuming the elasticity p to be specified separately), not two separate values of
5120257 / Apr 15 7-62

Section 7
T0 and c0. It also follows that X0 may be obtained from any other point on the
demand curve, say (T1, c1) since
X 0 = T 1 / c1P
Similarly, equation (7.30c), may be written:
(
T T 0 exp − β ( c − c 0 )
= )
=T T 0 exp ( β c 0 ) exp ( − β c )
=T X 0 exp ( − β c )
such that any point on the curve is sufficient to define X0.

However the logit equation (7.30a) cannot be rewritten as above, i.e. with the
dependence on c separated from the dependence on T0 and c0. Hence it is base
dependent. Similarly the elastic exponential (7.30d) and the nested logit (7.30e)
are base dependent.
If we refer to (T0, c0) as the base scenario A for some future year we may, with
base independent functions, use the T0 and c0 matrices as the base to carry out
an elastic assignment for scenario B with, e.g. a changed network. If we then
wish to consider another scenario, C, then we may use either the matrices from
scenario A or from scenario B as our starting point; both will give the same
results*. This would not be true with a base dependent function.
In practical terms base independent functions give the user a bit more flexibility. If
you accidentally delete the matrices from scenario A above but still have those
from scenario B then you are OK. On the other hand if you are the sort of person
that goes around deleting important files then you are probably the sort of person
who could accidentally use a trip matrix from scenario B and a cost matrix from
scenario C as the base for scenario D and wind up with totally the wrong result
whether your basic function is base independent or not.
On balance there is no substitute for being careful and base
dependence/independence should not be seen as favouring one functional form in
preference to another.
7.8.6 The Definition of “Cost” within Demand and Supply Models

In our general discussion of the equilibrium between supply (i.e., assignment) and
demand models in Section 7.4.1 it was implicitly assumed that the “cost” as
defined within the assignment model is identical to the cost as defined within the
demand model. (Or, strictly speaking, we assume that the route-dependent
components of the cost are the same in both models.) However it is not
* Strictly speaking both will converge towards the same results but since they are likely to start from
different initial conditions they may yield slightly different results since they will be converging along
different paths.
5120257 / Apr 15 7-63

Section 7
uncommon for combined VDM models to be formulated in which this rule is not
adhered to.
For example, the cost as used in the demand model may include components
such as vehicle operating costs which are based on an average speed of travel
between O and D which, in turn, depends upon the route(s) used but which,
cannot be calculated as a straightforward sum of individual link components along
the route(s); i.e., we cannot define an additive operating cost per link. Equally the
demand model may use the same components of cost as the assignment model,
i.e., time and distance, but use different weights. Or, frequently, the demand
model may use a different level of disaggregation into user classes (with,
generally, more user classes in the demand model than in the assignment
model).
In all such cases there is a strong possibility that the combined supply-demand
model will not converge to a unique equilibrium solution (either it will become
stuck in infinite loops or there may be multiple equilibria, one of which will be
arbitrarily reached). The basic problem is that the two models are “pulling in
opposite directions”.
Note that the problem does not occur if the demand model includes cost
components which do not feature in the route choice models as long as those cost
components are totally independent of the routes chosen. For example, modal
split models frequently add a notional penalty to the O-D costs by public transport
but these costs have no effect on the choice of an O-D route by either road or
public transport. Similarly, if area licensing is being modelled such that a trip with
both origin and destination within the charge area automatically pays a toll but that
toll is fixed independent of the route chosen, it is not necessary to include that toll
within the assignment model; it can be subsequently added to the O-D cost matrix
for those cells as a pure matrix operation. By contrast including, as above, a
vehicle operating cost based on speed is clearly route-dependent.
A more practical consideration is that, in order to calculate an average O-D speed
or to set up cost matrices based on different time/distance weights, etc. etc., it
becomes necessary to build skimmed (“forest”) matrices of O-D time and distance
from the assignment model. However this leads to a number of practical
difficulties (see 15.27.6):
(a) Considerable CPU overheads involved in skimming time, distance, etc.
matrices compared to calculating a minimum cost matrix (in addition to the
extra CPU overheads involved in carrying out the extra SAVEIT assignment
in the first place);
(b) Problems of differences between the SAVEIT and “master” assignments
(15.23.2) and
(c) Problems associated with the non-uniqueness of route flows and therefore
the non-uniqueness of skimmed time etc. matrices (7.1.6, 15.23.8 and
15.27.6).
By contrast a demand model which is based on minimum cost matrices from the
assignment requires a single tree build per origin to build a cost matrix, is based
on the final set of (unique) equilibrium link costs and is, therefore, also unique.
5120257 / Apr 15 7-64

Section 7
While clearly we would not wish to prevent users from setting up demand models
which involve different definitions of O-D costs if they wish to do so, it is not,
however, a practice that we (DVV) would particularly recommend. From a
behavioral point of view, it does not make much sense to me to assume that
drivers react in one way to road costs when evaluating route choice but in a
different way when evaluating, say, destination choice. Caveat emptor!
Our strong recommendation is, therefore, to use the minimum cost O-D matrices
from the road assignment as the costs input to the demand model unless there
are compelling reasons for doing otherwise.
In terms of the various standard batch files to calculate cost matrices as described
in Section 15.27.7 our recommendation is to use SATCOST in preference to
SATC_AV – option 14 in preference to option 9 in SATLOOK.
Finally we note that very similar considerations apply to linkages between
SATURN and economic evaluation models such as TUBA (15.41.1); i.e., life
becomes considerably simpler if the evaluation framework only requires a
minimum cost O-D matrix as opposed to a breakdown by time, distance, etc. etc.
7.8.7 Conclusions
To reiterate the first point made in this section - the choice and definition of the
demand function is entirely up to the user. All this section contains is advice,
albeit very sound advice!
Thus, at its simplest, elastic assignment may involve nothing more than uniformly
factoring up an existing trip matrix by 10 or 20% as the “new” base point and using
a present-day cost matrix. On the other hand the demand process may be part of
a much more involved multi-stage process. The choice is yours. If you
understand what your demand model represents and how to specify it then you
should have no problems; if you are not sure what you are doing then our advice
would be to keep it as simple as possible.
Finally, whether you are an expert or a beginner, it is a very good idea to check at
least once that the outputs from an elastic assignment model are indeed
consistent with your demand model. Thus having run an elastic model and
produced an output road trip matrix T ij use SATCOST (15.27.7) to calculate the
new cost matrix c ij . You should then be able to use the FORTRAN equation editor
in MX to independently calculate T ij from the input matrices T ij 0, c ij 0, and c ij (use
the equations in 7.7.1). If the two versions of T ij are "near" one another, e.g. +1%
per o-d element then your method is probably sound; if not, check your process
carefully. Do not expect 100% agreement which will only occur for perfect
convergence.
7.9 Multiple User Class Elastic Assignment

Multiple User Class Elastic Assignment combines the concepts of multiple user
classes (see 7.3) and of cost-sensitive trip matrices (see 7.5.1) so that each of the
NOMADS user classes has a different demand function; hence:
Equation 7.37
Tijm = fijm ( cijm )
5120257 / Apr 15 7-65

Section 7
where the additional subscript m refers to a different user class.

Alternatively the demand functions may be the same but the definition of
generalised cost (6.11) may differ between user classes, e.g., via tolls.
Running MUC elastic assignment requires that the extra trip and cost matrices,
both input and output, i.e., c ij 0, T ij ' and T ij are “stacked” matrices with a distinct
level for each user class. Strictly speaking the “reference” input trip matrix T ij 0
need not be stacked so that two different classes may “share” the same trip matrix
but with different factors (see the definition of a "matrix level" in 6.11) but to avoid
confusion and to facilitate the comparison of input and output matrices it is
probably best to “stack” To ij ; see the warning at the end of 7.3.1.2.
The same condition applies to the frozen trip matrix (FILICE) if ICING = T and,
indeed, any other input matrices; i.e., that it is “stacked” with a distinct level for
each user class.
Class specific demand functions may be specified by defining individual values of
MCGILL (which sets the functional form) and BETA/POWER etc (which set the
elasticities). See 7.12.2. Thus it is possible to model two different classes of
drivers, one of which has a very high elasticity (i.e., is very sensitive to changes in
travel costs) and one of which has a low elasticity (i.e., tends to travel independent
of the costs).
Note the parameters MCGILL, BETA and POWER are “subscripted” variables
here; i.e., rather than setting MCGILL = 1 you will need to set MCGILL(1) = 1 for
user class 1. However it is also possible to set a “universal” value of MCGILL for
all user classes by including a definition of the form MCGILL = 1 but no definitions
of the form MCGILL(1) = 1. Similar considerations apply to BETA and POWER.
It is possible - and not infrequent - to carry out a “mixed” elastic/inelastic MUC
assignment in which certain classes are assigned as fixed trip matrices while
others are elastic. To do so simply set the user-class specific value of MCGILL to
zero; e.g. set MCGILL(1) = 2 and MCGILL(2) = 0 to have user class 1 elastic and
class 2 fixed.
It is equally feasible to use either incremental or shared demand functions (see
7.5.1) but it is not possible to “mix” them between classes. Thus MCGILL(1) = 2
and MCGILL(2) = 11 is not a permitted combination.
For further information on multiple user class elastic assignment please refer to
Appendix C.
7.10 Combined Distribution and Assignment Models

Two forms of distribution models are available within SATURN, both of which are
“origin-constrained” and both of which are based on the logit formulation:
5120257 / Apr 15 7-66

Section 7
1. Incremental:
Equation 7.38
=
Tij AT 0
(
i ij exp − β ( cij − cij )
0
)
2. Absolute or shared:
Equation 7.39
=Tij Ai exp ( − β cij )
where in both cases the balancing factors A i are chosen such that:
Equation 7.40
∑T
j
ij = Oi
where O i = the number of trips originating from i as calculated from the origin
sums in the “base” matrix T ij o.
Clearly the incremental model requires two additional input files to define a “base”
trip matrix To ij and a "base" cost matrix co ij . Less clearly the absolute model (7.39)
also requires an input trip matrix which is used only to define origin trip ends
(although it would not be too complicated to input the trips ends directly if
required; apply to DVV!)
In both cases an equivalent optimisation representation of the problem is available
such that the combined distribution plus assignment problem may be solved using
very similar algorithms to those used to solve “simple” elasticity problems; see
7.5.2.
Note that distribution may be run either “on its own”, i.e., as a model of combined
distribution and assignment, or in combination with further demand stages such as
modal split. See 7.10.4.
7.10.2 Control Parameters

The choice of distribution model is controlled by the parameter MCUBC (7.12.2)
where:
MCUBC = 0 No distribution (default)
MCUBC = 1 Incremental
MCUBC = 2 Absolute
The “sensitivity” parameter β in equations (7.38) and (7.39) is set by parameter

BETA_D (7.12.2).
Both MCUBC and BETA_D may be either set via the original network .dat file
input to SATNET (see 6.3) or in the control files input to SATEASY or SATALL;
see 7.12.2 and 9.15.2 respectively.
5120257 / Apr 15 7-67

Section 7
7.10.3 Files
The file structure using distribution is identical to that for SDM models as
described in 7.12.1 and 7.12.3 with the exception that the “base” cost matrix
required under incremental distribution, co ij in (7.38), is defined by the file
"FILCGH". The trip matrix T ij 0 in (7.38) is set by the “name” FILTIJ (7.12.3).
7.10.4 Joint Distribution and Elastic Assignment (e.g. modal split)

In order to run a demand model in which the number of trips per ij pair in the road
network is determined firstly through a distribution model and secondly through a
further (elastic) choice process (e.g., modal split) it is necessary to select non-zero
values for both MCUBC and MCGILL. Thus MCUBC may be either 1 or 2 but
MCGILL must be chosen to be either 10 or 11, i.e. the elastic component must be
based on a “share” model (which further restricts it to a logit model).
The joint procedure may be seen as a form of nested logit choice model where the
total number of trips from origin i first choose a destination j and then - via a
single choice if MCGILL = 11 or a sequence of two further nested choices if
MCGILL = 10 - whether to choose travel by road and/or within a certain time
period.
(N.B. The alternative choice order whereby the choice of, say, mode precedes
that of destination is not yet available although the same principles would apply in
both situations. Equally a “destination constrained” version of a distribution model
is not yet available.)
Thus in terms of trips the total number of trips from origin i to destination j, T ij , is
determined by either equations (7.38) or (7.39) as appropriate and these values,
in effect, become the T ij 0 values in models (7.30e) or (7.30f) depending on
MCGILL. In terms of costs the values of c ij as used in equations (7.38) or (7.39)
will be “composite” logsums (see 7.6.3).
Note that the values of the β parameters used in the distribution and elastic
equations are distinct (BETA_D in the distribution, BETA and BETA_2 in the
elastic model) and that these values should logically follow the standard rule that:
BETA_D < BETA < BETA_2
As with distribution and elastic demand models on their own the combined
problem may be represented as a convex minimisation problem - the objective
functions for each sub-problem being essentially added together - and a variant
on the standard Frank-Wolfe algorithm used to solve for the joint equilibrium.
7.10.5 Multiple User Class Distribution

At the moment combining distribution with multiple user classes is not available.
The principles are not any more complex but the programming is. Requests to
either DVV or Atkins.
7.10.6 Historical Perspective

The distribution-based models described above were developed in the late 1990s
as part of the IEM (Improved Elasticity Models) research project sponsored by DfT
and undertaken by MVA and John Bates (with minor inputs from DVV). The
5120257 / Apr 15 7-68

Section 7
options introduced into SATURN at that time were intended primarily to

demonstrate the feasibility of programming integrated supply-demand models
based on the principle of minimising an objective function that went beyond simple
elastic or separable demand models. Therefore the number of options introduced
at that time was strictly limited.
Since then very little extra work has been carried out on these options within
SATURN, primarily since the DfT preferred to have supply-demand models set up
as two distinct but linked sub-models (as is done, for example, in DIADEM). And
indeed the MCUBC = 2 option above, absolute distribution, is no longer supported
as it no longer works as originally intended.
If any users are interested in pursuing the use of linked distribution models, or
indeed are interested in the original theoretical work from the IEM project, please
get in touch with DVV.
7.11 Miscellaneous Assignment Procedures
7.11.1 Generalised Cost Assignment: Time and Distance

All assignment techniques within SATURN assume that individual drivers seek to
minimise their travel cost, with “travel cost” being defined in one of three different
ways under normal usage (but see 7.11.2 below):
(i) As pure time, or
(ii) As pure distance, or (most commonly)
(iii) As “generalised cost” which is a linear combination of time, distance and
monetary charges (e.g., tolls) defined by:
Equation 7.41
=
C PPM ∗ T + PPK ∗ D + M
Where:
C is the cost in units of pence,
T is time in units of minutes (including any 44444 time penalties),
D is distance in kilometres,
M is monetary charge in pence,
PPM is a user-defined parameter specifying “Pence Per Minute”,
PPK specifies “Pence Per Kilometre”.
The “type” of cost desired is specified by the user’s choice of PPM and PPK, the
default values being 1.0 and 0.0 respectively which therefore equate cost to time.
Although the parameters are specified as “per minute” and “per kilometre” the
actual units used by SATURN for time and distance are seconds and metres;
appropriate conversion is handled by the program.
In fact, when generalised cost is requested, the assignment actually works in
terms of “generalised time”, defined by adding terms proportional to the link
distance and/or monetary charge to the link travel time, such that:
5120257 / Apr 15 7-69

Section 7
Equation 7.42
T + D ( PPK / PPM ) + ( M / PPM )

Ct =
Hence all assignment convergence statistics are always expressed in terms of

time with units of seconds (so that additional factors to correct for units are added
to the ratio PPK/PPM and to PPM above).
Links representing turning movements in the simulation network are assumed to
have zero length so that their times are unchanged by the definition of
generalised cost.
Note that “penalties” (Section 6.7) on restricted links may be expressed either in
time units as seconds and added directly onto the link generalised times used in
the assignment or as monetary costs which are, for assignment purposes,
converted to seconds. See Section 20 for more information on the ways in which
monetary costs may be defined.
We further note that the definitions of generalised costs may also differ between
multiple user classes, either in terms of the “weights” (e.g., PPM and PPK) per
component or in terms of the components themselves (e.g., penalties/tolls may be
user class specific).
In addition, within the assignment algorithms, “cost” is very often divided into
“fixed costs” and “variable costs” where fixed costs include not only the obvious
fixed costs such as distance, tolls and penalties but also the minimum travel time
per link (t 0 in equation (8.5)). The variable cost is then associated solely with the
flow-dependent component of time. Fixed costs may therefore also be thought of
as the cost at zero flow.
One reason for distinguishing fixed from variable costs is that the fixed cost
component of the objective function (7.1) may be easily calculated as the product
of the flow times fixed cost whereas the variable component requires a more
complex integration formula. Equally changes in the objective function are very
often best evaluated relative to the variable component rather than the fixed or
total value.
7.11.2 Generalised Cost Assignment: Multiple Link Data Fields

A “more general” form of generalised cost may also be specified by making use of
the extra or KNOBS data fields in the buffer/assignment network - see Section
15.14. In its most general form the generalised cost is given by:
Equation 7.43
= PPM * T + PPK * D + M + ∑ PPU ( i ) * DATA ( i )

Cost
i
where DATA(i) refers to the ith data input field, i = 1, ... KNOBS and PPU(i) refers
to the “Pence Per Unit” associated with that data field.
For example, DATA(1) might be a link scenic index and PPU(1) a weight to
convert scenic value into pence. The required values of PPU(i) are specified on
the ‘88888’ records input to SATNET - Section 6.11 - and may differ for different
5120257 / Apr 15 7-70

Section 7
user classes. Note that, by definition, all DATA values are fixed independent of
flows.
As with simple generalised costs the programs actually work in terms of
“generalised seconds”.
Note that values of DATA(I) are allowed to be negatives (see 15.14.3) but only if
the total fixed link costs (i.e., the sum of all components in Equation 7.43
excluding time) does not go negative for any individual links. Negative link costs
may pose problems for the tree-building algorithms which construct minimum cost
O-D paths since they may lead to cycles of links with a summation of negative
costs which cause infinite loops.
7.11.3 All-or-Nothing Assignment

All-or-nothing assignment can be requested by setting NITA, the maximum
number of assignment iterations, to 1. A single assignment is carried out based
on the free-flow travel times (costs), followed by a speed change to change the
travel times according to the assigned flows if AMY = F, or no speed change if
AMY = T. See 7.11.4 below.
There is one additional set of circumstances under which an all-or-nothing
assignment is carried out and that is when minimum distance is requested, i.e.
PPM = 0 and PPK ne 0, and SUZIE is FALSE so that there are no stochastic
variations in the perceived link distances. This is done independent of the value
assigned to NITA (although clearly the logical value to give it is 1).
Note that all-or-nothing assignments may also be carried out within SATDB
(11.10.7.3) with, possibly, greater flexibility.
7.11.4 Assignment with Fixed Travel Times (AMY = .TRUE.)

Setting the parameter AMY to .TRUE. requests that the assignment be carried out
with “fixed” travel times, i.e., no speed changes, with the travel times set to their
free-flow values.
The AMY option allows users to carry out more than one assignment iteration, and
is particularly intended to allow users to carry out more than one iteration of a
Stochastic or Burrell Assignment (SUZIE = T) using as-input travel times.
7.11.5 Assigning a Flat Trip Matrix (Negative GONZO)

It is sometimes useful to be able to carry out an assignment without having a trip
matrix available by simply assigning a fixed number of trips to each ij cell. This
can be done either by creating a “flat” matrix using MX or, much more simply, by
setting a negative value for the network input parameter GONZO, in which case
SATEASY will NOT require an input trip matrix but will assign the absolute value
of GONZO to each ij pair.
Note that this option is very much a short cut to deal with a highly artificial
situation and is not something that users should contemplate using in “real”
applications.
5120257 / Apr 15 7-71

Section 7
7.11.6 Continuing a Previous Assignment (The DIDDLE and WIDDLE OPTIONS)

As mentioned in 7.1.2 the Frank-Wolfe algorithm normally starts with an all-or-
nothing assignment based on free-flow link costs. However an alternative starting
point is to use the final assigned flows from the previous assignment, assuming
that one is after the first assignment simulation loop. This has the advantage that
the previous flows are likely to be “nearer” to the desired flows on this assignment
than is an all-or-nothing solution so that starting with them should reduce the
number of internal iterations required. This option is selected by setting the
parameter DIDDLE to .TRUE.
Tests with DIDDLE = T have shown significant improvements, not only in the rate
of convergence within a single assignment (which is to be expected) but also in
the rate of convergence of the assignment/simulation loops (see 9.4). Its use is
generally to be recommended and its default has therefore been set to T under
version 9.5.
We note that DIDDLE is only applied for assignments after the very first
assignment in the assignment-simulation loops where there is indeed a previous
assignment to fall back on. A similar technique, WSTART, is now (10.6) available
for the very first assignment; see Section 22.3.
WIDDLE
DIDDLE, as described above, only operates within simulation-assignment loops,
i.e. for networks with a simulation component. An alternative version of the same
principle, WIDDLE, applies to buffer only networks and effectively allows one
assignment to continue from the end of another.
Consider the following sequence of dos commands:
SATNET net1
SATALL net1 trips
COPY net1.ufs net2.ufn
SATALL net2 trips &PARAM WIDDLE T
The first two simply assign matrix trips.ufm to (assumed buffer-only) network
net1.dat to produce net1.ufs. This is then copied (in effect renamed) into net2.ufn
(ufn since SATALL expects a .ufn file as input) and the final step runs SATALL
with WIDDLE = T such that the initial flows in the net2 assignment are the final
net1 flows. In effect having done NITA assignments on net1 the second
assignment can carry out (up to) NITA extra assignments to achieve, e.g.
improved convergence.
A key requirement in using WIDDLE is that the initial flows are consistent
(technically “feasible”) with the trip matrix being assigned. In the example above
this is guaranteed by using the same matrix in both assignments. An alternative
application of WIDDLE would be to the situation where two network.ufs files have
had their flows averaged to produce a new (.ufn) file while their respective
matrices have also been averaged to produce a new trip matrix. This should
guarantee that the new initial flows and matrix and trips are self-consistent.
If this is not the case - and no check is made - then the assignment outputs will be
unreliable.
5120257 / Apr 15 7-72

Section 7
Note that SAVEIT cannot be used with WIDDLE = T since the majority of paths
will have been effectively generated by the first assignment(s). Equally, and in
addition to being buffer-only, WIDDLE currently only applies to fixed trip matrix
assignment and a single user class.
In many respects WIDDLE is the buffer-only equivalent of the SATALL loop
continuation facility described in 9.12.1.
WIDDLE is available within both SATALL and SATEASY. It may only be defined
either within an input control file or, equivalently, via a command line parameter as
in the above example. For (hopefully!) obvious reasons it cannot be set once and
for all within the original network .dat file and carried through to SATALL via the
binary network files. Its default is FALSE.
7.11.7 Partan Assignment

PARTAN (short for parallel tangent) is a variation on the Frank-Wolfe algorithm for
solving Wardrop Equilibrium with a single user class which tries to speed up its
convergence by introducing an extra line search in the algorithm. Within SATURN
it is (normally) invoked by setting a logical namelist parameter PARTAN to TRUE,
either as part of the network data input to SATNET or the control file input to
SATEASY or SATALL.
See “Restrictions” below for further details as to when the PARTAN option is and
is not applied (e.g., differences between SUC and MUC).
For full details we refer to the paper “A Full Analytical Implementation of the
PARTAN/Frank-Wolfe Algorithm for Equilibrium Assignment” by Y. Arezki and D.
Van Vliet, Transportation Science 24, 1, 58-62 (1990) – reproduced in Appendix C
- and to references therein.
Basically it introduces a new step into the Frank-Wolfe algorithm described in
Section 7.1.2 between steps (4) and (5) whereby (on iterations n>2) the flows
V a n+1 at the end of step (4) are combined with the second previous solution:
Equation 7.44
Va(
n +1)
(1 − τ n )Va( n+ ) + τ nVa( n− )
=
1 1
where τn is chosen to minimise the objective function.

Unlike the combination parameter λ used in the conventional Frank-Wolfe
algorithm τn can in fact assume negative values down to a certain lower limit,
where negative values correspond to a decreased weight being given to early
iteration routes and an increased weight to those in the last two iterations. This
has the potential advantage that the weighted contribution from earlier (less good)
iterative solutions may be reduced to zero (when τn goes to its lower limit), thus
improving convergence as well as eliminating possible problems associated with
“residual flows” (see 15.57.6)
At the end of the full algorithm the final flows will still be weighted sums of the
different iterations, although the formulae used to calculate the weights are now
more complex functions of λ and τ. However this means that SAVEIT may still be
5120257 / Apr 15 7-73

Section 7
used and post-assignment analysis, e.g., building forests etc, can still be
undertaken.
Full details of the values of τ chosen on each step and the resultant improvements
in the objective function are given in the line printer output file.
Empirical use in SATURN networks has generally shown that PARTAN can speed
up the internal rate of convergence within the assignment but, perversely, it
sometimes makes the convergence of the simulation-assignment loop worse.
Possibly the assignment is now “too good” and the method is picking up the small
change in successive iterations with greater precision. This is an interesting area
for further research. More immediately users are encouraged to try PARTAN if
they are trying to decrease cpu times but do not expect miracles!
On the other hand it may be much more beneficial for buffer-only networks where
the above problem will not arise.
7.11.7.1 PARTAN Restrictions

In its original form PARTAN could be used only for a single user class
assignment (SUC), not MUC. In addition, it is always used during the SAVEIT
SUC assignment step (see 15.23.4) whether or not PARTAN = T or F; i.e., the
parameter PARTAN only controls “normal” assignments.
Post release 11.2 a MUC version of PARTAN was introduced but only for the
SAVEIT assignment, not “normal” assignments. This option is controlled by a
parameter SPARTA = T for SAVEIT + PARTAN assignments, F for normal Frank-
Wolfe during SAVEIT. Hence, prior to 11.2, SPARTA was effectively F and MUC
assignments were always based on the basic Frank-Wolfe algorithm.
An important benefit of using PARTAN/SPARTA within SAVEIT is that, by
reducing the number of Frank-Wolfe iterations required to produce a SAVEIT
solution, all subsequent analysis steps that use UFC files (e.g., SATPIJA, SLA,
etc.) will become correspondingly faster. In addition, by potentially removing early
iterations by setting their ultimate weights to zero, a PARTAN solution may reduce
residual flows (15.57.6).
7.11.8 Wardrop MSA

A Wardrop Equilibrium assignment may also follow the Method of Successive
Averages as described in Section 7.2.2 without any link cost randomisation by
setting: (1) SUZIE = T and (2) SUET = 0.0. This carries out ‘NITA’ iterations of
MSA with similar statistics to those normally calculated under stochastic
assignment but with the delta function (section 7.1.4) reported as well.
A similar MSA Wardrop option is also available with multiple user classes.
While the MSA Wardrop will almost certainly not converge as well as the Frank-
Wolfe algorithm it is useful to indicate the minimum number of iterations which
may be required by stochastic assignment; see 7.2.5.
7.11.9 System Optimal Assignment

A “system optimal” (SO) assignment is one which minimises the total cost of travel
in a network, in contrast to a Wardrop Equilibrium (or “user optimal”) assignment
5120257 / Apr 15 7-74

Section 7
which seeks to minimise the travel cost of each individual driver. Mathematically
system optimal assignment minimises:
Equation 7.45
Z so = ∑ Va ca (Va )
a
rather than the Wardrop objective function Z given by (7.1)

It can be shown that minimising Z SO may be achieved by minimising the “marginal
cost” of travel for each individual driver, where, when link costs/times are strict
“separable” functions of link volumes (e.g., in buffer networks), the marginal cost
of travel on link a is given by
Equation 7.46
∂c
a (Va )
c= ca (Va ) + Va a
∂Va
For the particular form of link cost-flow equations used in SATURN assignments,
see equation (5.1), we obtain (N.B. change t o to c o below:
t0 + ( n + 1) AVan Va 〈Ca (a)

ca (Va ) = 
t0 + ACa + B ( 2Va − Ca ) / Ca Va 〉 Ca (b)
n
where c o represents the free-flow travel cost equal to the sum of the free-flow
travel time t o plus the fixed costs (e.g., distance; see 7.11.2) on the link. Note that
the contribution of the fixed costs is the same to both the actual and the marginal
costs (since they are fixed!).
In terms of purely marginal time t~ a we may write:
t~ a = n A Van Va < Ca (7.47a)
= B Va / Ca Va > Ca (7.47b)
Given that SO assignment may be viewed as the minimisation of individual
marginal costs the standard Frank-Wolfe algorithm may be used to solve the SO
problem with the one change that marginal costs are used throughout rather than
actual costs.
To invoke SO assignment within SATURN a logical parameter either SOWHAT or
WHATHO - see below - must be set to .TRUE, either (and preferably) within the
original network .dat file or within the control file to SATALL or SATEASY (both
allow SO assignment).
It needs to be appreciated that SO assignment is not based on logical
behavioural principles and that therefore it should only be used under very
specialised circumstances, e.g. to determine how much a network might be
improved by optimal routing. It is still very much a research tool, not a practical
tool.
Note that problems may arise due to the fact that the marginal cost curves defined
by equation (7.19) have a discontinuity at V=C so that it is possible for the
5120257 / Apr 15 7-75

Section 7
marginal costs to decrease as V goes from just below to just over C. This can
lead to convergence problems and/or multiple equilibria.
One way around this problem is to combine SO with the KINKY option which - see
15.38 - can be set to .FALSE. in order to remove the discontinuities in the cost-
flow curves at V=C. With KINKY = F equation (7.19a) holds for all values of V and
the discontinuity disappears - to be replaced by the problem that continuing the
power law curve for flows in excess of capacity may lead to unrealistically large
travel times. Take your pick!
A further problem is that in simulation networks, where the cost-flow curves are
applied to individual turning movements, no account is being taken in the above
marginal cost curves of the “interactions” between turning flows in shared lanes.
Thus increasing the flow on one particular turning movement may not only
increase the travel costs for all the current flows making that turn, it may also
increase the travel times on all other flows which share a lane with that turn. Not
to mention, of course, the impact that one turning movement may have, via gap
acceptance, blocking back, etc., on flows on totally different links. A technique
known as SATMECC deals with these issues; see Section 15.50 of the Manual,
Note that parameters WHATHO and SOWHAT have ostensibly the same effect
although there are subtle differences in the algorithms used. SOWHAT was
introduced first and explicitly uses marginal costs instead of “real” cost whenever it
is required in a Frank-Wolfe algorithm. WHATHO, introduced later, uses the much
simpler approach of factoring the parameter A by (n + 1) BEFORE entering the
assignment algorithms (and returning to its original values after). It is therefore
only applied under equation (7.19a) but, if you are using KINKY = F as
recommended above, then this does not matter as equation (7.19b) is never
invoked anyway.
Our recommendation then is to use WHATHO in preference to SOWHAT if KINKY
= F. It is also probably somewhat more robust to be used in conjunction with, e.g.,
elastic assignment or multiple user classes.
CONCLUSIONS:
System optimal assignment is of both theoretical and, increasingly nowadays,
practical importance. However the developments in SATURN are still at a very
early stage and further developments will require both extra theory and extra
programming efforts. See, for example, Section 15.50 on SATMECC which
generalises the calculation of marginal cost to include “interactions” associated
with the simulation.
7.11.10 Shadow Networks

The principles of shadow network assignment are best explained in “The use of
shadow networks in the determination of limits to traffic growth in heavily-
congested networks” by Tom van Vuren and Richard Davies in Traffic Engineering
and Control, pp425-428, July/August 1992.
It is, in essence, an alternative simplified form of elastic assignment. Roughly
speaking all OD trips in the input trip matrix are assigned in full to the network as
long as their speed exceeds a certain minimum, e.g. 10 kph, but if their speed
drops below that minimum than some or all of those O-D trips are diverted to the
5120257 / Apr 15 7-76

Section 7
“shadow network” which is a replica of the original network but with constant
minimum speeds.
More accurately the diversion to the shadow networks is based on costs where for
each O-D pair a minimum distance route is built -which at fixed speeds also
minimises time and cost - and the corresponding generalised cost of that route
stored. Any route with greater cost than that will be diverted to the shadow
network.
In terms of elastic assignment the shadow network demand function has the very
simple form sketched below where c ij s represents the shadow network cost. It
may therefore be thought of as a “quick and dirty” form of elastic assignment and
for that reason is not entirely to be recommended to SATURN users. However it
does have its supporters.
Currently shadow network assignments may only be carried out within SATALL,
not SATEASY. To invoke the facility it is only necessary to set a parameter
SHADOW to a non-zero (positive) value in the network .dat file, and to define a
filename for the output “actual” road trip matrix, ROADIJ in 6.3.4.
Furthermore shadow networks are only available for a single user class, not
multiple classes. In principle the ideas could be extended to multiple user
classes, however the necessary programming extensions have not been carried
out.
7.11.11 Supply Elasticity

The “strength” of the relationship between travel times and the demand for travel
(a.k.a. speed/flow) can be of critical importance in assessing network changes
under variable demand / elastic assignment (see 7.4). In particular TAG Unit M2
Variable Demand Modelling recommends the use of a measure of “supply
elasticity” defined by:
∑V (t − t )
a
101
a
100
a
Es = 100 a
∑V t
a
100
a a
5120257 / Apr 15 7-77

Section 7
Where t a 101 represents the travel time on link a with the trip matrix increased by
1%;
And t a 100 represents the “base” travel time on link a.
Analytically we may write:
 dT   V 
Es =   
 dV   T 
So that, given the general form of t(V) in SATURN, equations (8.5a) and (8.5b),
we have:
E=
s nAV n / ( AV n + t0 ) V 〈C
=Es ( BV / C ) / t (V ) V 〉C
Where B = 30 LTP (assuming LTP is in minutes and t(V) is in units of seconds).

In either case E S may take on values well in excess of 1. For example, if LTP =
30, V/C = 1.1 and t(V) = 180 (made up equally of 90 seconds delay at capacity
plus 90 seconds in over capacity queues) then E S = 5.5.
The greater the value of E S , the greater will be the changes in network times (and
costs) following a change in the trip matrix, and equally the greater will be the
reaction of the demand model. VADMA (Appendix 4A, paragraph 4A11) uses E S
(denoted by g) to help assess whether or not variable demand models are
necessary to assess individual schemes.
Supply elasticities are calculated at the end of the final assignment within
SATALL and are reported within the .lpt files. Equally they are reported as part of
the network “Convergence etc.” statistics available within either SATLOOK or P1X
(11.11.8 or 11.8.6).
An alternative measure is reported under Select Link Analysis (11.8.1.4) whereby
the summation is taken not over all links but as a flow-weighted sum over those
links used by the selected link(s).
A similar measure which measures the elasticity of generalised cost as opposed
to time is also generated within SATALL. To the extent that generalised costs
include non-time components which are fixed – and therefore “inelastic” – the
supply cost elasticity will be (numerically) lower than the time elasticity.
7.11.12 Internal Storage of Trip Matrices: Parameter SPARSE

There are essentially two different methods which SATALL (and SATEASY) use
to store the input trip matrix for use in assignment routines: either “internally” in
RAM or “externally” as a .UFM file. In the latter case, which is less efficient in
terms of CPU, each time the program needs to assign trips for a particular origin it
has to read that matrix row from the external .ufm file. In the former case the
complete matrix is always available in internal RAM.
Internal storage is preferable (and, for some options, mandatory) but it relies on
there being sufficient RAM available to store the full trip matrix, including stacked
5120257 / Apr 15 7-78

Section 7
levels for multiple user classes. Internal storage requirements may be reduced by
using two alternative schemes depending on whether the trip matrix to be
assigned is “sparse” or not.
Thus if the trip matrix is “sparse”, i.e., it has a small fraction of non- zero T ij cells
(as typically occurs with observed trip matrices) which are not assigned, then
explicitly recording both the destination j and the cell values Tij for positive T ij only
requires less RAM than recording every single T ij value with the origin/destination
implied by the position of a variable within its (ordered) arrays. However if more
than 50% of the cells are positive then the alternative method of recording every
cell value (with the origin/destination implied) is more efficient.
Prior to release 10.9.22 the assumption was that the majority of trip matrices
encountered by SATURN were sparse so only the first method was provided.
However modern models seem to rely much more heavily on synthetically in-filled
trip matrices so, post 10.9.22, both methods are available with the choice being
controlled by an &PARAM namelist parameter SPARSE – T (the historical default)
for the original methodology.
For most current networks our recommendation is to set SPARSE = F. Advice is
also printed in the .LPT files as to whether SPARSE = T or F would use less RAM
for a particular trip matrix.
If there is insufficient RAM available to store the matrix internally (by whichever
method is chosen by SPARSE) then storage reverts to “external mode” with all
inputs direct from the .ufm file. Note, however, that in this case certain assignment
options will no longer work, in particular OBA (Section 21) and multi-core
assignment (Section 15.53). The only remaining option in these cases is to shift to
a version with larger array dimensions (see 15.28).
Furthermore, at the present time, OBA will only accept trip matrices stored
internally in the traditional SPARSE = T format. It is hoped that this will be rectified
in future releases.
7.11.13 Incremental Assignment

An alternative to starting a Frank_Wolfe assignment with a single all-or-nothing
assignment to free-flow routes (see step 1), 7.1.2) is to use an “incremental
assignment”. Thus an incremental assignment with, say, 4 increments assigns
25% of the total trip matrix all-or-nothing to free-flow routes, calculates the new
link costs, assigns the next 25% of the trip matrix to the latest minimum cost
routes, etc. etc. until the full trip matrix has been assigned, following which the
normal Frank-Wolfe iterations take over as per normal. Thus the incremental
assignment is simply creating an alternative “feasible” initial solution for Frank-
Wolfe to improve upon.
Note that after the initial incremental stages each all-or-nothing assignment has
equal weights, unlike the same number of initial Frank-Wolfe steps where the
weights would be chosen according to optimisation principles. Thus the basic
principle of assigning final weights to each individual all-or-nothing solution,
equation 7.2b) continues to hold for both methods.
Both Frank-Wolfe and Incremental Assignment are trying to achieve Wardop
Equilibrium but incremental assignment is a purely empirical method with no
5120257 / Apr 15 7-79

Section 7
convergence guarantees. However, under certain circumstances, it may avoid

certain problems that the initial Frank-Wolfe solutions may create, e.g., the
“residual flows” described in 15.57; see 15.57.6 in particular.
Note as well that there is no point in using incremental assignment in conjunction
with the DIDDLE procedures described in 7.11.6; incremental assignment is only
ever useful when starting from a complete “clean sheet”: for example, during a
“Saveit Assignment”, see 15.23.2. (Indeed, at the moment, the option to use an
incremental assignment is only available as part of a Saveit Assignment.)
7.12 Running SATEASY: A single elastic run
7.12.1 File Structure: Inputs and Outputs

The files required for a single run of SATEASY with elastic assignment are
illustrated below:
Thus a number of input files need to be set up:

A network UFS file from SATNET/SATSIM;
A reference trip matrix UFM file which supplies the values T ij 0 for each I,J in the
demand function;
A reference cost matrix UFM file; this defines values for the c ij 0; see 7.8.
Additional cost matrices as required for nested logit and/or distribution models.
If REDMEN = T an initial estimate of the trip .UFM file T ij ’;
A “frozen cell” UFM matrix to specify fixed cells (optional; ICING = T). See 7.5.6.
A “control” file, control.dat, to specify various parameters, options, etc. (optional)
Output files include:
A network UFA file (suitable for input to SATSIM)
The “actual” road trip matrix TIJ.UFM
A line printer .LPA file
5120257 / Apr 15 7-80

Section 7
The input files are most conveniently defined within the original network .dat file as
illustrated in 7.12.4, although they may also be specified via the .bat procedure
(7.12.5).
7.12.2 Selecting Options and/or Parameters

There are a number of options available for applying elastic assignment, and
these may either be set up previously within the original network .dat file and
passed via the input .ufs file (strongly recommended) or set up in the ‘control.DAT’
file. An example of the former is given in 7.12.4.
The options are specified in the usual ‘namelist’ format for SATURN parameters
and are as follows:-
1) Choosing the form of the “elastic” demand function; see 7.7.1. Set:
MCGILL = 0 inelastic equilibrium
MCGILL = 1 logit (incremental)
MCGILL = 2 power law
MCGILL = 3 exponential
MCGILL = 4 elastic exponential
MCGILL = 10 nested logit
2) Choosing the form of the distribution model:
MCUBC = 0 No distribution
MCUBC = 1 Incremental distribution; see 7.10.1
MCUBC = 2 Absolute distribution; see 7.10.1
3) Specifying the elasticity parameter:
BETA for MCGILL = 1, 3, 10 or 11 (β in 7.7.1)
POWER for MCGILL = 2 or 4 (p in 7.7.1)
BETA_2 for MCGILL = 10 (β 2 in 7.7.1)
BETA_D for MCUBC = 1 or 2 (β in 7.10.1)
Note that POWER is dimensionless but BETA parameters have units of inverse
generalised seconds; their absolute values are therefore quite different. E.g.,
POWER might equal 0.5, BETA, -0.001.
4) Specifying whether an initial estimate of the actual trip matrix is supplied;
see 7.5.3.2:
REDMEN = F no initial estimate (the default)
REDMEN = T an initial estimate to be read in as a trip matrix. UFM file
T ij '
5) An Estimated Elastic Trip Factor
5120257 / Apr 15 7-81

Section 7
FRED Default 1.0; see 7.5.3.2

6) Specify whether the frozen cell option (7.5.6) is invoked or not
ICING = T/F Default F.
respectively
7) Special control parameters including:
MASL_F Default 0; See 7.5.3.4
NITA_F Default 0; See 7.5.3.4
7.12.3 Elastic Assignment File Names

The extra input files necessary to run elastic assignment may also be set within
the Namelist inputs to either SATNET or SATEASY/SATALL and are as follows:
FILTIJ The “parametric” trip matrix T0 (7.8.1).

FILCIJ The “parametric” cost matrix c0 as used in all elastic demand
functions (7.8.1) including the upper level of the nested logit (7.6.4).
FILCKL The alternative cost matrix c2 used in the second (i.e., lower) level
of the nested logit model (7.6.4).
FILCGH The alternative cost matrix used within distribution, c0 in equation
(7.38).
ROADIJ The output trip matrix.
FILICE The 0/1 matrix used to define frozen cells; see 7.5.6.
FILRED The initial trip matrix used with REDMEN = T; see 7.5.3.2.
Note that all cost matrices must have the dimensions of generalised time defined
in units of generalised seconds.
7.12.4 An Elastic Network DAT file

As mentioned earlier all the necessary parameters and filenames may be set
within the original .dat file and this method is certainly the simplest way to
proceed. This is equally true if the elastic assignment is carried out within
SATALL; see 9.10.
Thus the relevant section of the &PARAM records might contain.
&PARAM
MCGILL = 2
POWER = -0.5
FILTIJ = ‘TIJ0.UFM’
ROADIJ =‘ELASTIC.UFM’
FILCIJ =‘BASECOST.UFM’
ICING =.TRUE.
FILICE =‘HAGENDAZ.UFM’
5120257 / Apr 15 7-82

Section 7
7.12.5 The SATEASY.BAT Procedure

The program SATEASY may be run by the command:
SATEASY network matrix COST filcij REDMEN filred TIJ
roadij ICE filice KR control
Where:
network.UFS is the input network file, from SATNET/SATSIM

network.UFA is the output UF file for input to SATSIM
network.UFC is the output file containing the iteration costs under SAVEIT.
network.LPA is the line printer file containing convergence data, etc.
matrix.UFM is the reference matrix of O-D flows T ij 0
(Optional: If used it must be the second input argument.)
filcij.UFM is the matrix of reference costs c ij 0
filred.UFM is the matrix of initial estimates of the actual O-D flows if
REDMEN = T; see 7.5.3.2
roadij.UFM is the output actual O-D matrix, as estimated by the elastic
assignment
filice.UFM is the matrix defining frozen cells; see 7.5.6.
control.DAT is the control file, specifying values for the assignment
parameters.
If the words ‘KR control’ are omitted from the command line, then SATEASY
expects to find the parameters in the default control file SATEASY0.DAT.
Note that all .UFM file definitions are optional and that, generally speaking, it is
much simpler and highly preferable to set them using the namelist parameters
input to SATNET; see 7.12.4. For example FILTIJ may be used instead of
MATRIX.UFM, FILCIJ instead of filcij.UFM etc as illustrated in 7.12.3.
7.13 SATEASY: Technical Specifications
7.13.1 SATEASY FILES

Channel
Remarks Status
Number
1 The input UFS or UFN file from either SATSIM or Mandatory
SATNET
2 The output UFA file containing the assigned and
passed to SATSIM.
3 An output “UFC” file containing the costs as used Optional (SAVEIT = T)
on each iteration for SAVEIT; See 15.23.
5 The control file specifying the options and Mandatory
5120257 / Apr 15 7-83

Section 7
parameters for this run of SATEASY plus any

additional data as specified below
6 The output LPA line printer file. Mandatory
8 A scratch file used for both input and output under Optional (SAVEIT = T)
SAVEIT
9 Input UFM file containing the trip matrix being Mandatory. (Unless
loaded (or the “reference” trip matrix Tij0 for elastic GONZ0 is negative)
assignment).
10 Scratch UFX files used for both input and output
11 under multiple user class and/or elastic
assignments
12 if there is insufficient internal memory Optional
15/14 Terminal (output only) Optional unless
MODET ne 0
19 Input cost matrix “FILCGH” used under incremental Optional
distribution (MCUBC = 1)
20 Input cost matrix “FILCKL” used at the lower level Optional
of a nested logit model (MCGILL = 10)
0
21 Input “base” cost UFM matrix c ij used under Elastic Mandatory under
Assignment Elastic Assignment
22 Input initial trip UFM matrix used under Elastic Optional under Elastic
Assignment Assignment (REDMEN
=T)
23 Output trip UFM matrix used under Elastic Mandatory under
Assignment: trips by road Elastic Assignment
24 Input frozen cell matrix Optional under Elastic
Assignment.
28 Input matrix of tolls per link under tolled-equilibrium Optional
assignment. (Not yet available)
29 Input .UFS network file under UPDATE and/or Optional
WSTART
7.13.2 SATEASY Control Input On Channel 5
RECORD 1 - NAMELIST &PARAM (MANDATORY)

This record is used to define values for certain control-type variables used in the
assignment procedure. All parameters (with two exceptions, TITLE and REGO,
see below) will have had values set within the network building program SATNET
either by default or within the &PARAM namelist input there. &PARAM here over-
rides these defaults.
The following parameters, with the defaults from SATNET, may be set.
LOGICAL: AMY, ASHORT, AUTONA, BB105, DIDDLE, ERTM, EXPERT,
5120257 / Apr 15 7-84

Section 7
ICING, ILOVEU, KINKY, LCR108, MONACO, PARTAN,

QUEEN, Q105, RAGS, RB106, REDMEN, REFFUB, ROSIE,
RTP108, SAVEIT, SAVUFO, SOWHAT, SUZIE, SUZIEQ,
USEUFO, WHATHO and ZILCH.
REALS: AFTERS, ALEX, APRESV, BETA, BETA_2, BETA_D, CAPMIN,
CLICKS, FISTOP, FRED, GONZO, PCNEAR, POWER, SUET,
TAX, TDEL, TIJMIN, UNCRTS and XFSTOP.
INTEGER: ISTOP, KORN, KOB, KOMBI, LRTP, MASL, MASL_F,
MAXDTP, MAXQCT, MCGILL, MCUBC, MET, MODET, NIPS,
NISTOP, NITA, NITA_F, NITA_M, NITA_S, NITS, NITS_M,
and NFT.
CHARACTER: TIJFIL, CGHFIL, CIJFIL, CKLFIL, ICEFIL, ROADIJ and
FILRED.
In addition the logical parameter REGO = .TRUE. sets all iteration counters to
zero as required by the RESTART option; see Section 15.4. Its default value is
.FALSE.
Network Title
A new descriptive network title may be set by either:
A character namelist parameter of the form:
TITLE = ‘nettitle’
A namelist designation of a logical variable:

TITLE = T
in which case the new network title is contained on the record immediately
following the namelist records (i.e. following &END) and occupies columns 1 to
76.
5120257 / Apr 15 7-85

Section 7
5120257 / Apr 15 7-86

Section 7
Simulation – The Role of SATSIM
8. Simulation – The Role of SATSIM

INTRODUCTION
As noted later in section 9.1 the basic function of the simulation is: (a) to calculate
delays, capacities, queues, etc. at the level of individual turning movements given
a certain pattern of link and turn flows specified by the assignment; and (b) to
calculate new cost-flow curves to be returned to the next assignment. This
section gives a brief description of the steps thus involved.
The simulation may be carried out either within a separate program SATSIM (in
which case it would need to be run in conjunction with the separate assignment
program SATEASY) or, much more usually, within SATALL. The discussion in
this chapter applies to both. Some technical information on SATSIM specifically is
given in 8.10; more general information on SATALL is given in Section 9.
Further information on the basic principles of simulation within SATURN may be
found in the original papers published in Traffic Engineering and Control in 1980
and 1982 and reproduced as PDF text in Appendix C.
8.1 Cyclical Flow Profiles
8.1.1 Basic Principles

In modelling the actual movement of vehicles in a network there is usually a need
to compromise between level of detail and execution time, in particular, as the
simulation may have to be performed a large number of times during a run of the
complete model. Thus the modelling of individual cars (which has, more recently
become available within so-called “micro-simulation” models) would give
extremely detailed results but unacceptably high running times for large networks.
Equally purely analytical equations, while quick, may fail to take adequate account
of certain important features of traffic such as signal co-ordination between
junctions, choice of lanes, etc.
SATURN therefore adopts an “intermediate” level of detail with certain features of
micro-simulation combined with certain more “macroscopic” equation-based
features.
SATURN makes two basic assumptions:
♦ That traffic flows are approximately constant over time periods of the order of
30 minutes (or the value set by LTP);
♦ That traffic signals operating with fixed cycle times of the order of, say, 90
seconds impose a pattern of “cyclic flow profiles” within the longer time frame.
Thus the main building block in SATURN is the cyclic flow profile (CFP), the flow
of traffic past a certain point as a function of time. For example, we assume that if
one were to stand downstream from a set of traffic signals operating at a fixed
cycle time of 75 seconds one might observe a pattern of flow as illustrated in
Figure 8.1.
5120257/ Apr 15 8-1

Section 8
Figure 8.1 - Cyclical Flow
In other words there would be cyclical surges of traffic corresponding to the green
period at the lights and periods of minimal flow corresponding to the reds. Each
75-second CFP would be identical to every other over the full 30 minutes
simulation period, thus enabling us to simulate only one, in this case, 75 second
cycle rather than the full 30 minutes with consequent reductions in computation
time.
The basic principles of cyclic flow profiles are well tried and tested, for example in
the TRANSYT program. (Robertson, D.I. (1974) Cyclic flow profiles. T.E.C. 15
pp.640-1).
8.1.2 Basic CFP Parameters: LTP, LCY and NUC

In order to simulate flows within this framework the user must define several
parameters. Firstly the length of the period of constant flow (e.g., 30 minutes) is
set by LTP (in units of minutes).
Secondly the length of the shorter cycle is set by the parameter LCY (in
seconds).
Finally each cycle is sub-divided into a number of time units (as specified by the
user-input parameter NUC, see 15.15.2), typically 10 to 20, so a CFP can be
represented in the computer as an array, the elements of which represent the flow
in each discrete time unit of length LCY/NUC seconds (as opposed to being a
continuous function such as illustrated in Fig. 8.1) A typical time unit duration is
around 5 seconds and represents the time resolution of flow within SATURN
[Note however that traffic signals in SATURN are effectively defined with a
resolution of one second since signal phases may begin or end in the “middle” of
individual time units.]
While LTP is set universally it is possible to define node-dependent values for
both LCY and NUC; see Section 15.15.2 and 15.15.3
8.1.3 The 5 Basic CFP’s within the Simulation

CFP’s in SATURN are based on turning movements, thus allowing for banned
turns, separate turn phases at signals, etc. and also for the fact that, for example,
the expected delay to a right turner is usually greater than that for a left turner.
Each turn from link i to j has associated with it four CFP’s, as illustrated in Figure
8.2; viz:
♦ the IN pattern, the flow profile at the upstream end of link i;
♦ the ARRIVE pattern, the profile at the downstream end of i;
5120257/ Apr 15 8-2

Section 8
♦ the ACCEPT pattern, the pattern of traffic which can actually make the turn;
♦ the OUT pattern, the flow at the upstream end of link j.

Note that the IN and ARRIVE profiles are similar in shape (but not absolute
magnitude) for all turning movements whereas ACCEPT and OUT are turn
specific. The profiles are related as follows:
The IN profile is set, essentially, by the assigned flows at the upstream end of the
link, although its precise size/shape/profile is determined by the OUT profiles at
the upstream node and may be less than the assigned flows (in to) by virtue of
flows queued upstream (see 8.2.8).
The ARRIVE pattern is derived from the IN using platoon dispersion, a well-
established traffic engineering technique (and also allowing for traffic that departs
at the upstream end of the link, e.g., to zones or terminating bus flows, and/or
joins at the downstream end, e.g., from zones or buses).
Figure 8.2 - The location of the 4 basic cfp’s
The ACCEPT pattern is derived independently and is based essentially on

capacities, signal timings and conflicting traffic; clearly this is a critical part of the
process and occupies a large proportion of the programming required. See
Section 8.2 for further information.
The OUT pattern of a turn is based on the ARRIVE and ACCEPT patterns
whereby the ACCEPT pattern functions essentially as a “filter” on the ARRIVE’s to
determine how much traffic can cross the stop line at each point during the cycle.
OUT profiles then combine to determine the total IN pattern of succeeding turns.
In addition there is a 5th CFP, the QUEUE profile, representing the number of
vehicles (pcus) queued at the stop line at any point in the cycle, which is important
in it allows one to calculate the average delay per vehicle; see 8.4.1 and 8.4.8.
Thus, at a signalised junction, the QUEUE profile might resemble the classic “saw
tooth” pattern as the queue grows during the red periods and declines in the
green. At priority junctions or roundabouts it might be virtually flat representing the
5120257/ Apr 15 8-3

Section 8
average number of vehicles waiting for a suitable gap to appear. For further
details see Section 8.4.8.
The best way to appreciate the definition of and the interaction between the
various cyclical flow profiles is to use the node analysis functions within P1X
(and/or SATLOOK) to examine actual simulation nodes; see 11.1.1 and 11.12.
8.1.4 The “Movement” of Traffic via OUT/IN CFPs: NTS and NITS_M
As the OUT pattern from one junction generates the IN profiles for the next
junction traffic, in effect, “moves” through the network.
Since the IN profile at the upstream of link A,B is derived from the various OUT
profiles at A node B cannot be fully simulated until A (and all of B’s other upstream
nodes) have been simulated. Similarly A cannot be fully simulated until all its
upstream nodes have been simulated as well. Thus starting at node B we can
follow the simulation backwards until we wind up at node B again. Simulation is
therefore an iterative process in which we iterate over each node in turn (generally
in numerical order but see 8.3.4 for alternative strategies) until convergence is
achieved as explained further in 8.3.
The parameter NITS sets the maximum number of internal simulation iterations
(default of 20) while NITS_M (which defaults to five) sets the minimum.
Note that the average level of cyclical flow is essentially determined by the
assignment but the shape of the profile is determined by the simulation.
We further note that if the modelled cycle time LCY differs at the “upstream” and
“downstream nodes” then any “shape” associated with the OUT CFPs is
effectively lost at the point of flow transfer so that, in that situation, the IN profile is
assumed to be flat but with the correct level of flow. By contrast, if the two nodes
have different values of NUC, the shape of the IN CFP’s is retained but suitably
averaged per IN time unit. For further details please see Section 15.15.3.
8.1.5 Simulation of CFPs at Dummy Nodes

While in general terms the simulation of “dummy” nodes (see 5.1.1.1) follows the
same structure as “normal” nodes in terms of the various CFP profiles there are
important differences in their exact treatment.
The basic property of a dummy node is that it presents no restrictions whatsoever
to through traffic – in effect, therefore, the ACCEPT CFP at a dummy node is
infinite. ARRIVE profiles are obtained from IN profiles in the standard way using
platoon dispersion (8.1.3) but the OUT profiles are identical to the ARRIVE
profiles (allowing of course for turning proportions). Thus any “shape” in the IN
profiles is directly transferred to the OUT profiles so that any degree of, say, signal
co-ordination between the entry and exit nodes is retained at dummy nodes.
By contrast any queues on an exit arm from a dummy node are not carried
through to any entry arms and therefore blocking back is not transmitted through
dummy nodes; see note b), section 8.5.2.
5120257/ Apr 15 8-4

Section 8
Turning delays at dummy nodes, are by definition, always zero although there
may be link delays if capacity-restraint curves are used on the in-bound arms; see
8.4.4.
We repeat the advice in Section that 5.1.1.1 that the use of dummy nodes is
strongly discouraged except in certain very precise circumstances
8.2 Accept Profiles and Capacities
8.2.1 General principles

Since the ACCEPT profile is particularly important in that the sum of the ACCEPT
values per time unit establishes the capacity for the turn, we describe in
somewhat greater detail how it is obtained.
In essence the process starts by assuming saturation flow and then reduces it in a
sequential manner to obtain the final ACCEPT profile. More specifically:
♦ Set the ACCEPT value for each time unit equal to its turn saturation flow; see
6.4.6.
♦ If the exit link is blocking back (i.e. the queue on that link exceeds its stacking
capacity) reduce the value per time unit by a uniform “blocking back factor”;
see Section 8.5.
♦ If traffic signals reduce it to zero during the red phases (such that if the phase
change occurs in the middle of a time unit an appropriate adjustment is
made).
♦ If the turn is coded as a give-way movement, factor down the current

ACCEPTs by the probability of there being a gap in the opposing traffic
flow(s). See 8.2.2. N.B. In order to avoid problems with turns being
completely blocked by the apparent absence of any gaps a lower limit is set
on the capacities at this stage allowing minor arms to “push in” to major arms
as set by the user-defined parameter CAPMIN. See 15.22.
♦ Reduce it further to allow for lanes shared with other turning movements.
See 8.9.2 for interactions with traffic on the same arm and 8.8.3.3 for the
interactions with traffic on other arms (which only occurs with merging
movements).
♦ For X-turns at signals (i.e., right turners which are opposed by straight ahead
vehicles in the opposite direction during the green stages) allow a maximum
of TAX vehicles to clear at the end of each green stage from the centre of the
junction (where TAX is user defined and may be link-specific (6.13); default
2). See 8.2.4.
♦ In the case of “blocked” and “unblocked” movements sharing the same lane
at signals (e.g. a lane where straight ahead vehicles can go on green but
right-turners have to wait) a certain number of unblocked vehicles are allowed
to go at the “head of the queue”, their number being determined by their
relative proportion (based on a probabilistic argument as to where in the
queue the first blocked vehicle will occur). See 8.2.5.
5120257/ Apr 15 8-5

Section 8
♦ If flared lanes have been explicitly coded add extra capacity for those turning
movements which may use them directly and/or for turns in lanes which have
been “relieved” by the flares. See 8.2.6. (N.B. New in 10.9.22)
♦ If the link has been coded as a “capacity restrained” simulation link and the
total capacity at the junction exceeds that of the link then the ACCEPT values
of every turn are factored down in order to equal the mid-link capacity. See
6.4.12 and 8.4.4.
The turn capacity is then determined by summing the individual ACCEPT's per
time unit.
We further note the point made in 6.4.6 that if there are additional effects which
influence the capacity but which are not included in the above set (e.g. the effect
of pedestrian crossings) then it is essential that the user incorporates these
additional effects within the input data, e.g. by reducing the saturation flow.
8.2.2 Gap Acceptance

Gap acceptance is used in SATURN to represent the manner in which “minor”
vehicles give way to “major” flows, e.g. at priority junctions or roundabouts. The
approach is based on the probabilities of there being a gap at any point in time in
all of the opposing flows (where, see 6.4.2.1, the opposing flows are those which
are either crossed or share the same exit as determined by the junction
geometry). The basic equation may be written as:
Equation 8.1
C = S × P1 × P2 × ...
where:
C is the entry capacity
S is the (minor) saturation flow (with zero cross traffic)
P i is the probability of a gap in opposing stream i.
The individual probabilities P i are calculated from formulae such as:
Equation 8.2
GS
 Vi 
P=
i 1 − 
 Si 
where :
V i is the opposing major flow
S i is the saturation flow for the major movement
G is the gap parameter
Hence P goes from a maximum of 1 at V i = 0 down to P = O at V i = S i (but see
CAPMIN below) with a power defined by G.S i . This formula would be applied in
5120257/ Apr 15 8-6

Section 8
the case of an “absolute” give way, e.g. for minor arm traffic at a priority junction
giving way to major flows.
However variations are used to represent other less clear-cut situations. For
example, consider two minor arms at a priority junction, both of which feed into the
same exit or else cross and for which there is no well-established priority rule. In
such cases SATURN assumes that the two movements “share” and that the
probability of one finding a gap in the other is given by:
Equation 8.3
GS
 V 
Pi =0.5 + 0.5 1 − i 
 Si 
and vice versa. Hence each movement receives at least 50% of the available
time and must look for gaps in the remaining 50%.
8.2.2.1 Gap Acceptance for Merges

Another variation can occur with merge-style situations where the SATURN rule is
that the merging traffic needs to find a gap in one lane only of the major turn (as
opposed to traffic crossing a major road which needs gaps in all lanes).
For “simple” merges, e.g., an entry ramp onto a motorway, equation (8.2) is still
applied but the flow and saturation flows are those in one lane only, i.e., on the
inner lane of the motorway. Pragmatically this means that V i /S i is the same but
the power G S i is reduced by a factor equal to the number of lanes, hence giving a
higher probability of a gap. See 6.4.2.3 for the rules for defining the “major” turn
and the single lane within which the merge takes place and 8.8.3.1 for the lane
choice rules and further possible reductions in the ACCEPT patterns.
For “Y-merges”, i.e., situations where a M-marker appears for two turns which
share an exit as with two motorways merging, equation 8.3 is applied to both
turns. Hence, in effect, both turns have a “guarantee” of 50% of the available
capacity and have to “fight” for the remaining 50%. Lane choice rules are
described in 8.8.3.2.
Note that further capacity restrictions may be applied to both types of merges to
account for the limited physical capacity of the exit lane; see 8.8.3.3 and 8.8.3.4.
8.2.3 CAPMIN
Finally, in order to prevent the entry capacity going to zero whenever V i = S i a
minimum capacity CAPMIN may be specified. CAPMIN represents the fact that
as major flows reach capacity they also tend to travel at very low speeds such that
minor road vehicles can force their way in. Therefore the ultimate capacity is the
maximum of either CAPMIN or equation (8.1).
(N.B. Prior to 10.6 CAPMIN was applied at the level of the cycle; i.e., if the total
capacity as summed over each individual time unit were less than CAPMIN then
they were factored up to equal CAPMIN. In 10.6 the rule is applied at the level of
the TIME UNIT; i.e., if the capacity per time unit were less than CAPMIN it would
be factored up. If the flows are relatively flat, i.e., if there is no pronounced
platooning due to traffic signals in the vicinity, then the differences are very small;
5120257/ Apr 15 8-7

Section 8
but, if there is significant platooning, the overall capacity may be somewhat

greater than CAPMIN.)
The decision as to which rule is applied and to which movements is based on
geometrical considerations and the definition of the various turn priority markers
and modifiers as outlined in 6.4.2.
8.2.4 Stacked Vehicles Clearing at the end of Green; Link-Specific TAX Values
As mentioned above (note 6, 8.2.1) up to ‘TAX’ vehicles can clear at the end of
each green phase for X-coded turns at signals in order to represent the behaviour
of vehicles which “stack” in the centre of the junction and only clear once the
green phase has ended.
Originally TAX was a universal parameter; with SATURN 9.4 it became a link-
specific parameter which may be set either using the X-file facility (6.13) or (post
10.9) on individual link data records (see 6.4.14 and 6.4.15). Thus links with very
wide junctions or with multiple stacking lanes may be assigned a much larger TAX
value than more constricted junctions. Users will probably find that, post 10.9, the
“extra line convention” described in 6.4.14 will be the most convenient method to
define link-specific TAX values.
Note that TAX refers to the total number of stackable pcu’s, not the number per
lane.
TAX plays a further role in allowing unblocked vehicles to pass in a lane shared
with an X-turn; see 6.4.9.5 and 8.2.5.1 below.
8.2.4.1 TAX contributions from late cut-offs

Post release 11.1 the “tax” rules have been modified such that if an X-turn at
signals appears in a green phase which terminates with a stage in which the X-
turn is unopposed (i.e., a late cut-off) then the extra allocation of TAX pcus is not
allocated on the assumption that any stacked vehicles will proceed during the late
cut-off.
There is, however, a problem with this rule in that if an X-turn has more than one
phase and those phases include both types of final stages (i.e, some unopposed,
some not) then the non-allocation of TAX applies to all phases. This is flagged by
Serious Warning 187. It is planned to correct this anomaly at some future point
(post release 11.3).
8.2.5 Unimpeded (Green) Vehicles at the Head of a Queue

Imagine a queue of traffic made up of multiple vehicle streams making different
turning movements in a single lane at traffic signals. At the point in time where
the lights go green the situation may arise whereby one or more streams may be
able to go while others are “blocked”. For example the lights may be showing a
filtered green signal to selected streams only or else certain cross-flow streams
may have green but are blocked by opposing flows.
The most common, but not the only, example of this occurs with X-turns where the
(right) turning traffic coded X is blocked by opposing flow but the straight-ahead
traffic in the same lane is unblocked.
5120257/ Apr 15 8-8

Section 8
In these cases if the vehicle at the head of the queue is “unblocked” it will
proceed; if blocked, it will not and all vehicles in the queue behind will have to wait
until the head vehicle can go. Clearly if the head vehicle does go then the same
situation occurs with the next vehicle in the queue, etc. etc.
It may be shown that the average number of unblocked vehicles at the head of the
queue is given by:
p
n=
(1 − p )
where p is the probability (fraction) of unblocked vehicles. Thus if 3/4 of vehicles
in the queue are unblocked on average 3 will proceed.
SATURN therefore adds the equivalent of n vehicles to the ACCEPT profiles of
the unblocked turns at the start of the green phase.
8.2.5.1 The MONACO Option: The TAX contribution

A variation of the above rule has been introduced in 10.8 whereby, if a parameter
MONACO (think tax-free!) in &PARAM is set to .TRUE., then the number of
blocked vehicles required to completely block the lane becomes TAX+1, not 1,
where TAX is the number of pcus which are able to clear at the end of a green
phase by queuing in the centre of the junction (8.2.4). In effect, the assumption
becomes that there is physical space for TAX pcus to wait in the middle of the
junction and that, while the blocked vehicles are waiting, other traffic can pass by
on the inside, and will continue to do so until the (TAX+1)th pcu arrives and finally
blocks the head of the lane.
A simple mathematical model shows that the average number of non-blocked
pcus that can pass is (TAX + 1) p / ((1-p); i.e., the original value of n above
multiplied by TAX+1.
8.2.5.2 MONACO: The Contribution from X-Flared Lanes

The basic concept of MONACO, i.e., an increase in the number of initial straight
ahead vehicles at the start of a green phase, may be extended to include the
impact of an explicit offside flared lane. In this situation potentially queued X-
turners most fully occupy both the centre of the junction (represented by TAX)
and the flared lane space (represented by FLAREX) before they prevent a straight
ahead vehicle with green from proceeding.
Thus if FLAREX pcus can queue in a flared lane plus TAX in the middle of the
junction then the average number of non-blocked pcus that can pass is (TAX +
FLAREX + 1) p / ((1-p).
Once the initial “head of queue” ACCEPT profile has been reached then the
capacity of the straight ahead vehicles may be reduced by lane sharing with the
X-turners as per normal.
Note that contribution of a flared lane to the “head of queue” capacity is only
included if MONACO = T.
5120257/ Apr 15 8-9

Section 8
We may also note that the presence of a flared lane will also clearly increase the
capacity for X-turners but this affect is discussed in the next section; the above
contribution applies only to straight ahead capacities.
The main difference between TAX and FLAREX, as far as the X-turners are
concerned, is that the TAX pcus are allowed to clear at the end of a green phase
whereas any vehicles remaining queued in the flared lane must wait until the next
green phase to clear.
8.2.6 Added Capacity due to Flared Lanes

Post release 10.9.20 flared lanes may be added on a link at either a signalised or
priority junction in order to increase the capacities of either the extreme nearside
or offside turn which can use the flare as well as to increase the capacities of
those turns which share the inside and/or outside lanes and which are “relieved”
by the flares. The approach differs depending on whether the flare diverges from a
shared or an unshared lane as well as on junction type.
Coding instructions are given in Section 6.4.9.3 and 6.4.14.
8.2.6.1 Flares from Shared Lanes

The geometry of a flared 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. The length of
the flare can stack up to X PCUs. Let Q A and Q F represent the length of the
queues at the stop line at any point in time for movements A and F respectively.
PRIORITY JUNCTIONS
We consider first the case of priority junctions which are somewhat simpler than
traffic signals although most of the modelling principles apply to both. Extra rules
for signals are dealt with below.
Thus, at a priority junction, we may envisage four different scenarios:
5120257/ Apr 15 8-10

Section 8
Both Q A and Q F < X

Both Q A and Q F > X
Q A > X but Q F < X
Q A < X but Q F > X
Thus in case (1) both lane queues are shorter than the flare and there is no direct
interference between either turn and they should both experience their “normal”
accept profiles at the stop line (i.e., allowing for saturation flows, give-ways,
red/green signals etc. etc.) subject to the constraint that their total capacity cannot
exceed the normal combined capacity from a single lane.
In case (2), where both queues stretch the full length of the flare and beyond the
point of divergence, the capacity is determined primarily at the point of
divergence. Thus, if there are just two turning movements, ahead and flare, we
calculate both their “downstream” or “stopline” capacities, where they each occupy
a single lane and do not interfere with one another, plus their “upstream”
capacities at the entry point to the flare where they do restrict one another. The
movement with the maximum ratio of upstream to downstream capacities is
judged to be the “most restricted” or “major” flow and its capacity equals its
downstream capacity. The capacity of the other or “minor” term is then equal to
its upstream capacity factored down by the downstream to upstream ratio of the
“major” flow.
In simpler terms this means that the “minor” capacity C m = F m x C M / F M where F
represents flow, C is capacity and subscripts m/M represent minor/major.
For more than 2 turning movements the same principles apply although the
equations are slightly more complicated.
In case (3) the accept profile for A is set by what happens at the stop line but the
accept profile for F is limited by the amount of traffic that can enter the flared lane
upstream. This in turn equals the OUT profile for movement A factored down by
the ratio VF / (VF + VA); i.e., each time an A vehicle moves up what is the
probability that the next vehicle in the queue is an F which can freely enter the
flared lane?
Case (4) is simply the reverse of case (3).
Case (2) gives minimum capacity, case (1) the maximum with cases (3) and (4)
intermediate. The final accept profile / capacity is a probabilistically weighted sum
of the four cases such that as the flare length increases the best-case scenario (1)
becomes increasingly more likely relative to the worst, (2), and the overall
capacity increases.
In order to calculate probabilities per case the model is sub-divided into signalised
junctions and priority junctions, the distinction being that in the former we model
queues deterministically so that we “know” at any time unit during the cycle which
“case” is active, whereas in the latter we use a probabilistic model to determine
the probability distributions of queues at any point during the cycle and therefore
the probability splits between the 4 cases.
5120257/ Apr 15 8-11

Section 8
SIGNALISED JUNCTIONS
Signalised junctions differ primarily in that the queue profiles are “deterministic”
rather than “stochastic” although the general principle of determining whether the
“shoe pinches” either upstream or downstream still applies.
An additional factor, however, at signals is that during the red phase it is assumed
that both A and F vehicles will build up queues in their distinct lanes and that there
is therefore a fixed “reservoir” of traffic which can exit at the stopline capacity once
the lights go green independent of any restrictions at the point of entry to the flare.
The stopline capacity continues to apply as long as there are vehicles left in the
reservoir which is continuously modelled by subtracting those vehicles which can
exit at the stopline while adding the maximum (restricted) entry flow at the flare
entry.
8.2.6.2 Flares from Unshared Lanes

The situation where the flared lane diverges from an unshared lane for which only
a single turning movement is allowed – and must therefore be the turn which also
uses the flared lane – is considerably simpler in modelling terms. Thus if a single
unshared lane flares into two its accept profiles and capacity is (normally but not
always – see next) doubled, two unshared lanes into three is factored by 1.5, etc.
etc.
But, for example, if a give-way turn at a priority junction has its per lane capacity
reduced from its saturation flow by a factor of 0.3 to account for give-ways its total
capacity would be increased to 0.6 times its saturation flow if it has a flare. On the
other hand if the reduction factor were 0.6 then the combined normal lane plus
flare would not have a capacity of 1.2 times its saturation flow, only its saturation
flow as set by the maximum throughput from a single lane at the point of
divergence into the flare.
Similar upper limit considerations apply to signalised junctions with unshared
flares where the fraction of green times reduces the capacity by factors greater or
less than 50%.
8.2.6.3 Extra Capacity for Adjacent Lanes and Turns

Flares, in addition to increasing the capacity of the flared turn, may also increase
the capacity for turning movements in adjacent lanes.
For example, from the diagram in 8.2.6.1, it is possible that if there is not enough
straight ahead A flow in lane 2 (i.e., the lower lane from which the flare diverges)
to take advantage of the extra stopline capacity available in lane 2 then Ahead
traffic from lane 1 may choose to divert into lane 2 beyond the point at which the
flare diverges if there is space available. Hence the flare is not only increasing the
Ahead capacity in lane 2 but also the Ahead capacity in lane 1.
In turn, this may lead to “knock-on” effects in lane 1 in that if there were also, say,
left-turning traffic (L) in lane 1 then its capacity would also be increased due to the
switch of Ahead traffic from lane 1 into lane 2, allowing extra stopline time to L.
Note that these additional capacities only apply if there is a “residual” queue of
traffic waiting to clear so that it can take full advantage of the extra stopline
5120257/ Apr 15 8-12

Section 8
saturation flow. Thus at the start of a green phase we assume that the “stacking
space” in lane 2 beyond the flare is full and that the queue will (a) decrease by the
saturation flow at the stopline and (b) increase (at a slower rate) as traffic enters
the stacking space. Once the queue goes to zero the capacity is determined by
the maximum rate at which traffic can enter into (and depart from) the stacking
space.
In addition changes in capacities due to the flare may lead to changes in lane
choice (and equally the lane capacities are affected by lane choice so an iterative
“balancing” algorithm is required).
Note that the extra capacity allocated to A was only added in Release 11.2.8 while
the extra “knock-on” impact on L was only included in Release 11.3.6.
8.2.7 Co-ordinated Signals

One of the advantages of using cyclical flow profiles as the basic building block
within SATURN is that it enables one to model the effect of co-ordinated signals.
For example, let us suppose that the CFP depicted in Fig 8.1 represents the
arrival pattern of traffic at a signalised junction with the peak of the arrivals during
the middle of each 75-second cycle; this profile will presumably have resulted
from the timing of a signalised junction upstream which releases traffic at fixed
times within the same 75-second cycle. If, furthermore, the green phase of the
current junction is also timed to occur during the middle of the cycle that junction
will be co-ordinated with those upstream which generated the arrival profile. On
the other hand if the green phase were set to occur nearer to the start/end of the
cycle when arrivals fall off then the signals would not be co-ordinated.
Clearly the resulting delays - and queues - would be less with good co-ordination
and more with poor (although, in general, the co-ordination would not affect the
actual capacity).
The degree of co-ordination, or otherwise, is determined by (a) the shape of the
arrival pattern, (b) the stage definitions and (c) the offsets.
Note that co-ordination can only be modelled within SATURN if the cycle times of
the upstream and downstream junctions are identical. This is explained further in
Section 15.15. If they are not SATURN assumes that the arrival profile is flat, in
which case the delays are independent of exactly when during the cycle the green
phases occur. Thus in order to model co-ordinated signals within an area it is
essential that all junctions within that area (including non-signalised junctions and
dummies) are coded with a common cycle time. This may be achieved by
ensuring that the global parameter LCY (upon which the ‘cycle times’ of non-
signalised junctions are universally set) reflects the cycle time of the co-ordinated
traffic signals.
Section 15.31 discusses the various options available within SATURN to optimise
signal settings (stage times and offsets). See also Section 12.2 for information on
SATOFF for offset optimisation on it own.
Finally we may note that improved signal co-ordination tends to improve the
overall convergence of the assignment-simulation loops; see note 9) in Section
9.5.1.
5120257/ Apr 15 8-13

Section 8
8.2.8 Flow Metering

Another feature of the use of CFP’s is that it enables the simulation to cope with
the effects of “flow metering” whereby the flow downstream of an over capacity
junction or other pinch point is reduced accordingly. A detailed description is given
in Sections 17.1 and 17.2 where we differentiate between “demand flow” and
“actual flow”.
Basically the phenomenon arises since the OUT CFP can never exceed the
ACCEPT CFP so that if a turning movement is in excess of capacity the total of
the OUT flow profile will equal the capacity and be less than the sum of the
ARRIVE’s. Hence the subsequent IN profile (and all downstream flow profiles) will
be based on actual rather than demand flows.
8.3 Internal Simulation Iterations and Convergence

At any point where traffic streams meet there is usually some interaction; for
example, at a simple crossroads right turners from the south are restricted by
ahead traffic from the north, which in turn may be limited by right turners from the
north whose flow is dependent on the ahead flow from the south, and so on.
Rather than modelling this in detail, the same cycle is simulated iteratively, the
ACCEPT patterns on the n-th iteration being derived from the conflicting flows in
the (n-1)-th. Convergence is considered to have been reached when all OUT
patterns are effectively unchanged by further iterations.
The convergence of the simulated OUT profiles can be thought of as arising from
both “between-” and “within-junction” effects. The between convergence arises
primarily as the IN profiles at each junction are affected by the OUT profiles of the
previous (upstream) junction; as these change so too does the simulation of the
next junction and hence its OUT patterns. Similar effects can also occur in the
opposite direction; for example, if the blocking back characteristics of a
downstream exit link change (see 8.5), then the ACCEPT profiles at the upstream
simulation node will also change.
On the other hand the “within” or “internal” convergence arises from the fact that
OUT profiles of one turn can affect the ACCEPT profiles of other turns at the
same junction, e.g., via giving way or lane sharing.
The next two sections describe parameters which are used to monitor either both
effects combined (8.3.2) or the between effects on their own (8.3.3).
8.3.2 Convergence of Out Profiles

The basic parameter used to monitor the convergence of OUT profiles per node is
the average change in individual components of all OUT patterns expressed in
units of pcu’s per hour. These are then averaged to give a “global” convergence at
the end of each simulation iteration.
Thus at the end of each iteration over all nodes the line printer file contains a
message such as:
ITERATION 3 - AVER. ABS. CHANGE = 13.464 PCU/HR
5120257/ Apr 15 8-14

Section 8
Convergence is assumed if the above value is sufficiently small or if the maximum

number of iterations NITS is exceeded (subject, as well, to the minimum number
NITS_M which defaults to 5).
Note that the definition of “sufficiently small” may depend upon the overall
convergence of the assignment-simulation loop so that the critical limit is
(generally) proportional to the GAP value. Thus if the loops are poorly converged
there is no strong reason to have a well converged simulation since the simulation
inputs will vary significantly on the next loop; on the other hand, if the loops are
converging nicely we do not wish to introduce extra “noise” due to a badly
converged simulation stage.
LPT and LPS files list the internal convergence statistics (defined as above in
terms of OUT profiles) for each simulation node in order to identify possible “badly
behaved” nodes; e.g.:
OUT CONVERGENCE PARAMETERS PER NODE
NODE CC NODE CC NODE CC
1 0.04 2 0.00 17 0.00
20 0.06 21 5.62 22 0.03
25 0.00 26 0.00 27 0.00
30 0.00 31 0.00 32 0.00
47 0.77 48 0.05 49 0.01
would indicate major convergence problems at node 21, possibly minor problems
at node 47, but none elsewhere.
The internal convergence - or lack of it - can cause certain apparent
inconsistencies in the outputs from the analysis programs such as SATLOOK
which, by re-simulating junctions with the IN patterns fixed, allows for changes in
the local OUT profiles which can, in turn, alter turn capacities, etc. However,
generally speaking, such problems are rare.
8.3.3 Convergence of In Profiles

In addition, the “between junction” convergence is monitored separately by
measuring the average absolute change in the IN profiles on each in-bound arm in
units of pcu’s per hour.
Note that the IN and OUT convergence measures are evaluated differently (the
former is averaged over links, the latter over turns) which means that they are not
strictly “additive”; i.e., one cannot obtain a precise measure of the within-junction
convergence by subtracting IN from OUT. Nonetheless if the IN convergence is
zero and the OUT is positive then all the convergence problems are internal.
Equally if both are significantly greater than zero it probably means that the main
source of convergence problems arises from between-junction effects (e.g.,
changes in blocking back) rather than internal.
The IN convergence values are printed along with the OUT’s in a table that lists
the 10 worst converged nodes in order of their OUT values. Both may also be
obtained and printed for individual nodes in a variety of ways (e.g. within P1X
Information/Nodes and Convergence).
5120257/ Apr 15 8-15

Section 8
8.3.4 The Order of Node Simulations (SIM109)

Traditionally SATURN has adopted a very simple iterative strategy for the order in
which individual nodes are simulated by simply starting with the lowest numbered
node and working numerically upwards through all nodes. However we note that if
a node B has only one entry arm from node A then the IN profiles at B are
determined only by the OUT profiles at A and therefore it makes good sense to
simulate B after A, in which case the IN profiles are always up to date. Thus the
numerical strategy above “works” if B has a higher node number than A but not
the other way round. Of course most nodes have several input arms and it is not
strictly possible to simulate all the upstream nodes prior to simulating B but it may
be possible to identify the “major” contributors to flow into B.
Nonetheless, as a general principle, it seems sensible that the order in which
nodes are simulated should try to follow the major directions of flow.
With this in mind release 10.9.17 introduced a topologically-based order whereby
the first nodes simulated were at the outside of the simulated network (or, strictly
speaking one link in from external nodes) and the order then worked inwards on
the basis that this should be the main direction of flow during a morning peak
hour. No doubt more sophisticated rules may be and shall be developed after
further experimentation. However it does appear that the simple strategy above
does indeed reduce simulation CPU.
The choice between the original numerical ordering and the topological ordering is
controlled by a parameter SIM109 set in the network .dat file; if T the newer
topological order is used. Default = T. Note that SIM109 equally governs the
distinction between “suns” and “moons” described next.
8.3.5 Suns and Moons: Link-based Simulations

A second rule (included automatically with the order of node simulation rules
above when SIM109 = T) was also introduced in 10.9.17 whereby certain
simulated nodes were designated as “moons” relative to neighbouring “suns” so
that node simulations could be separated into individual link simulations.
Thus, if node N has 3 entry arms from A, B and C but has no “internal between-
arm” interactions, i.e., the simulation of traffic from A is not affected by entry traffic
from B or C (e.g., there are no give-ways for turns out of A) then the only
commodity that determines the simulation of turns from link A-N will be the IN
profiles at the upstream node A.
Thus, immediately after simulating node A and obtaining updated IN profiles on
link A-N, we carry out a “mini” or “link-specific” simulation of node N in which we
only simulate traffic on the single link A-N. CFP’s at all other turns at N are held
constant. Equally we simulate traffic on B-N and C-N immediately after B / C has
been simulated.
So in this sense node N may be considered as a “moon” of nodes A, B and C and
therefore it need not be directly included in the topological list of simulated nodes
which only consists of “suns”, i.e., those nodes where there is some form of
between-arm interaction
5120257/ Apr 15 8-16

Section 8
There is one qualification to this which is that if one or more arms at a node are
blocking back then the simulation is also influenced by affects “downstream” and
therefore that node may no longer be considered as a “moon” and must be
included within the main topologically ordering. Thus the order of node simulation
is not necessarily fixed over simulation iterations.
Those simulation nodes which are considered as moons may be displayed as
“selected nodes” within P1X; see Section 11.6.5.3.
8.4 Simulation Delays, Queues and Flow-Delay Curves
8.4.1 Simulation Delays

Having calculated the profiles for each turn as explained above the program may
now use the queuing profile to calculate the average delay per vehicle based on
the average number of vehicles (pcus) in the queue (see 8.4.8).
Delays (and queues) may be subdivided into two main components:
♦ “transient” or “under capacity” delays and
♦ “queuing” or “over capacity” delays

where, for example at traffic signals, the transient delays correspond to the time
spent queuing during the red phase by vehicles which then depart during the
green phase, whereas the queuing delays only occur for turning movements in
excess of capacity where a permanent queue builds up which is unable to clear in
a single cycle.
Depending on the circumstances the transient delays may be further subdivided
into a number of components:
♦ the “geometric delay” term TDEL applied to all give-ways at priority junctions
and roundabout turns;
♦ the time spent in the queues given as cyclical flow profiles (DA code 1628;
see App. J.3.);
♦ the “random delays” described in 8.6 (DA code 1658; see App. J.3.);
♦ the time spent in circulating a roundabout.

The transient delay is the sum of all four (DA code 1653; see App. J.3.).
With respect to over-capacity delays, since SATURN assumes constant arrival
rates over the time period, the simulated permanent queues (and delays) increase
linearly from a zero initial queue to a maximum at the end of the time period (see
Fig. 17.3). In this case the average time spent in a permanent queue per arriving
vehicle is given by:
Equation 8.4
( LTP / 2 ) ∗ (V − C ) / C
Note that a vehicle which arrives at the start of the time period would suffer no
extra delay (since the queue is zero) whereas a vehicle arriving at the end of the
5120257/ Apr 15 8-17

Section 8
time period (i.e., LTP) suffers the maximum delay equal to twice that given by
(8.4).
Clearly LTP is a critical parameter in determining delays (in particular for over-
capacity turns where the queuing delays can far exceed the transient delays. Its
role is discussed further in 8.4.5.
(The case of multiple time periods is more complicated since the initial queue
need not be zero and permanent queues may either increase or decrease but the
distinction between transient and queue delays still holds; see 17.6.)
Note that with queuing delays (assuming as above that the queue increases over
the time period) part of the time the arriving vehicles spend in a permanent queue
will be outside (later than) the time period simulated. Normally this component of
delay is included in the definition of the average delay per turn. However in
certain simulation summary statistics a distinction is made between the vehicle-
hours spent in permanent queues within the time period and in later time periods;
see Section 17.8.
See section 8.4.6 for a discussion of extremely long simulated delays being
calculated.
8.4.2 Flow-Delay Curves

In addition to calculating the “actual” delay a very important function of the
simulation is to calculate a “flow-delay curve” for each turning movement which
specifies the (approximate) relationship between the delay for a turn and the flow
on that turn. This is then used by the assignment in order to assign trips to routes.
The general equation is of the form:
Equation 8.5
t=
AV n + t0 V <C (a)
t AC + t0 + B ∗ (V − C ) / C
= n
V ≥C
(b)
where:
t o is the free-flow travel time (in seconds),
C is the turn capacity (in pcu/hr), and
B is a constant worked out by the program equal to one half the time period being
modelled. (Numerically B = 30*LTP where LTP is in minutes and B in seconds.)
(See equation (8.11) for a more complex form of the same basic equation
appropriate to turns which share lanes.)
Note that the mathematical form of the equation is identical to that used by buffer
links (see 5.4) so that we can refer to it as the “standard form”.
The general form of the relationship is shown in Figure 8.3.
5120257/ Apr 15 8-18

Section 8
Figure 8.3 - Flow Delay Curves and their Fitting Points
For turning movements A and n are calculated by the program simulating three
different delays: that at zero flow, that at the current assignment flow and that at
capacity as illustrated in Figure 8.3. If the current flow is either too high (over
capacity) or too low (near zero) then a suitable arbitrary flow is used to determine
the middle point (20% or 80% of capacity).
The “power” n is restricted to be in the range 0 to PMAX, where PMAX is a user-
set parameter (6.3.3) which defaults to 10.0; calibrated values in excess of PMAX
are replaced by PMAX. Note that very high values of n, e.g., 10, correspond to a
curve which is effectively a right angle: a flat horizontal segment for V < C with a
vertical segment at V = C. As such it is probably not very realistic (as well as
making life difficult for the assignment to converge) such that setting lower values
of PMAX, e.g., 5, may be worth considering.
Warnings occur if problems occur, for example if the simulated delays decrease
with increases in flow or if the best-fit value of n exceeds an upper limit. However
if problems do occur the flow-delay curve always goes through the “actual” point
in order to ensure consistency between assignment and simulation.
8.4.2.1 The Units of A

Note that the parameter A not only has rather strange and indeterminate units
since it must convert pcu/hr raised to a power n into seconds but it may also,
potentially, take on rather extreme numerical values. To take an improbable but
not impossible example of an “upper limit”, if a link has a capacity of 10,000
pcu/hr, a power n = 10 and capacity delay of 10 seconds then A must equal 10 to
the power –39. At the lower limits, say capacity = 1 pcu/hr, then A = the time at
capacity independent of n. This can create computational problems in calculating
and storing A, particularly of underflow.
5120257/ Apr 15 8-19

Section 8
To avoid such problems, internally SATURN numerically defines V and C as used

in the first terms in equations (8.5a) and (8.5b) in units of hundreds of pcu/hr; i.e.,
it factors them by 0.01 before raising them to the power n. Thus, in the above
example, A would equal 10-19. This avoids the problems of underflow at high
volumes without introducing the opposite problem of overflow at low flows. (It also
means that, at a more technical level, care must be taken in using the values of A
as stored in DA code 1813; see 15.21. An alternative is to use the “parametric”
form of the V<C segment as given by equation (5.2).)
8.4.2.2 Permanent (V>C) Queuing Delays

The final term in the equation (8.5b) for V>C corresponds to the “permanent
queuing delay” mentioned in 8.4.1 and 17.6. (And, since flows appear in both the
numerator and denominator, the question of the units used to define V and C is
not relevant.) See section 8.4.6 for restrictions on the upper limits of queued
delays for simulation turns.
It is possible, see 15.38, to make the equation (8.5a) extend over the full range of
turning volumes from zero to infinity via the parameter KINKY.
8.4.3 Flow-Delay Curves under ROSIE

An alternative form of flow-delay curve is also calculated under the ROSIE option.
This has the same algebraic form as equations (8.5) but in this case the quantity V
is the total weighted flow of all turning movements which share lanes with one
another (or, technically, are within the same “river”; see 8.8.2). Once again the
parameters A, n and C are estimated by calculating delays at three different flows
and fitting the curve to pass through these points. Note as well that the
parameters are turn-specific so that delays need not be equal for a given total flow
V (although the delays for turns sharing the same lanes will be very similar to one
another).
The “weighted flow” is defined by:
Equation 8.6
V = ∑ aiVi
Where:
V i is the flow for turn i, and
a i is a weight proportional to the inverse of the capacity of that turn “at the
stop line”.
Hence heavily impeded turns (e.g. due to give-ways) are assigned a greater
weight than unimpeded turns.
Which flow-delay curve is used in the assignment is determined by the value of
ROSIE at that point - see Section 7.1.3 where a different assignment algorithm is
employed with ROSIE = T.
We may also note that the method by which turning flows at roundabouts are
added together and modelled as total entry arm flows (see 8.7.1) is an implicit
5120257/ Apr 15 8-20

Section 8
example of ROSIE. In this case, however, the weighting factors are all 1 and the
treatment is applied whether or not ROSIE = T.
8.4.4 Simulation link speed-flow curves and capacity-restraint

Generally speaking, simulation links have fixed travel times, assumed equal to
their “free flow travel times”, and, in effect, zero additional delays. In addition they
have, effectively, infinite capacities. However it is possible to define link speed-
flow curves for simulation links in the same way that one may define link speed-
flow curves for buffer links. Equally, explicit capacities may be defined on
simulation links themselves (as opposed to capacities set by downstream
junctions). This information is included within the network .dat file as detailed in
Section 6.4.12.
This facility is extremely useful for modelling relatively 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. For short urban links speed-flow curves are generally not
required on the presumption that the limiting capacity and the main delays occur
directly at the junction stopline.
Thus the link travel time on a restrained simulation link is assumed to be a
function of flow V is defined by the “standard” form
Equation 8.7
t (v) =
t0 + AV n V <C (a)
where the parameters t o , A etc. are defined via the .dat file. C is interpreted as
the “link capacity”.
For flows in excess of capacity it is assumed that the link travel time remains fixed
at t C = t o + A * Cn. The reasoning behind this assumption is as follows.
The link capacity C should be interpreted as the limiting capacity of the link itself,
generally a function of the minimum road width along the link, as opposed to the
“junction capacity” C j set at the downstream end. Generally speaking on most
urban roads, “case (a)”, C j < C and therefore the question of what happens to the
link speeds when flows are in excess of C j is not highly relevant since the travel
times on the links are almost certain to be “swamped” by the queuing delays at
the junction.
However for some sorts of links, in particular motorway-style links, “case (b)”, the
above reasoning does not hold since the “junction” and “link” capacities are
effectively one and the same thing. Flows in excess of capacity, in a very strict
sense, cannot exist, although in SATURN flows in excess of capacity are allowed
to enter a link if there is sufficient capacity upstream. We would, however wish
them to be simulated as having travel times in excess of t C . How this is done is
explained next.
In either case an extra condition is imposed on the capacities of the turns at the
downstream end of speed-flow links which is that their “total” capacity C j must be
less than or equal to the link capacity C. If it is less - case (a) above - no further
5120257/ Apr 15 8-21

Section 8
action is taken; if greater - case (b) - the individual turn capacities are factored
down such that C j = C.
In the event of V > C and C < C j the turn capacities will be reduced (“choked”)
such that queuing occurs at the turns. As flows increase beyond C there will be
no increase in their “link” travel times, fixed at t C , but there will be a rapid increase
in their junction queuing times. Hence on motorway-style links the total travel
time - link plus turn -- is an increasing function of flow, even though one
component, the link time, has an upper limit. In effect the extra link travel time is
now associated with a queue at the junction.
It also follows that if queues do form due to the mid-link capacity then the exit
flows from the downstream junction will be limited to the mid-link capacity C, i.e.,
“flow metering” (8.2.8) occurs, and, equally, blocking back may occur at the
upstream junction
N.B. The reduction in junction capacities, flow metering and/or blocking back do
not apply if the downstream junction is a dummy node (5.1.1.1), in which case
the turn capacities at the dummy node remain, in effect, at infinity and their delays
at zero. On the other hand changes to the cruise speeds do apply to capacity-
restrained links approaching a dummy node.
An important side-effect of this modelling framework is that the effects of blocking
back and/or flow metering along motorways may now be simulated and will be
determined either by the explicit capacity of the link or by the junction, whichever
is the lesser.
Finally we note that any “delays” on the link due to capacity-restraint curves are
distinct from the queuing delays “at the stop-line” and are modelled quite distinctly.
One obvious difference is that the capacity-restraint delays are the same for all
traffic on the link whereas the stop-line delays may differ for individual turning
movements.
8.4.4.1 Display of “Choke Factors”

If a junction turn capacity is reduced due to link capacity restraint it is done via a
“choke factor” < 1.0 which is applied to all ACCEPT CFP’s to reduce the total link
capacities to equal the link capacity. Choke factors may be viewed (post 10.7) in a
number of ways:
(1) The SATLOOK table of flows and delays indicates by a % those turns
whose capacity is reduced but the value of the choke factor is not given.
(2) The SATLOOK option 16 to display capacity-restraint link data contains a
list of choke factors by turn and/or link.
(3) The SATLOOK master option 12 which prints all over-capacity links
indicates by a ‘b’ when a link’s capacity is by its speed-flow curve.
(4) P1X link annotation options include “active” mid-link capacities; i.e., those
instances of mid-link capacities which “choke” the stop-line.
5120257/ Apr 15 8-22

Section 8
8.4.4.2 Display of Delays

It is important to appreciate when viewing output statistics that the definition of
“delay” may refer to either link or stop-line or, in certain circumstances, to the sum
of the two (thus “total” delay). Hopefully the outputs will make it clear which is
which (although, it has to be said, prior to 10.6 it was not always as clear as it
should have been).
8.4.5 The Role of LTP

LTP (the length of the time period modelled) plays a crucial role in determining the
over-capacity queues and delays and its chosen value needs to be carefully
considered by the user.
Thus we note from equation (8.4) that the over-capacity delay is directly
proportional to LTP: double LTP and (assuming that the flows are unchanged, see
below) you double the delays and the length of queues.
Figure 8.4 - The “rectangular” simulation demand profile vs the “true” profile
The fundamental assumption within SATURN is that flows remain constant (i.e.,
the profile is flat) over the time period LTP at the rate specified by the trip matrix.
Clearly this must be seen as an approximation to what happens in real life where
flow rates change in a continuous fashion over time. As illustrated in Figure 8.4,
SATURN approximates the (real life) continuous profile by a flat profile such that
the total flow within the time period modelled is the same (or should be the same)
in both cases. In this example SATURN slightly underestimates the flow during
the “peak of the peak” and correspondingly overestimates the flow during the
shoulder; clearly the “flatter” the true profile is, the better the approximation.
If the “structure” of the observed flow profile does not fit nicely into the rectangular
assumption illustrated in Figure 8.4 then the user may need to consider modelling
multiple time periods as discussed in Section 17.3.
If flows are in excess of capacity in a large number of links across the network the
over-all time spent in over-capacity queues can be a significant component of the
total travel time and it becomes highly important for scheme evaluation to get
those numbers correct. Which, in turn, means that it is highly important to get LTP
5120257/ Apr 15 8-23

Section 8
“right” so that taking simple arbitrary values such as 30 or 60 minutes may not be
all that useful. Indeed LTP should be regarded as a base-year “calibration”
parameter which needs to be carefully considered.
It should also be pointed out that the traditional default value used in SATURN for
LTP, i.e., 30 minutes, is probably not a very sensible default for modelling peak
conditions since in real life most peaks persist for longer than 30 minutes. You
have been warned! And a warning message is generated in SATNET if LTP is not
explicitly set in the network .dat file, (On the other hand 30 minutes may quite a
reasonable default for use with multiple time periods.)
In addition users may need to consider changing the value of LTP in future year
forecasts if it is felt that growth in the future is not going to be uniform over time of
day but that some form of “peak spreading” is likely to occur whereby peak flows
do not so much increase “vertically” but tend to spread “horizontally”. Thus an
alternative to assuming that the trip matrix grows by, say, 2% per annum may be
to assume that LTP grows by 2% per annum. Clearly this may introduce a
number of other problems such as how to evaluate and compare flows over 60
minutes in the base year with flows over 70 minutes in the future; in practice
SATURN users are unlikely to vary LTP from base-year values, but the possibility
needs to be considered as do the base-year calibration issues.
We may also note that the simple rule that delays are proportional to LTP is not
necessarily strictly correct since, as you increase LTP and therefore increase the
delays on over-capacity links/routes, more traffic will divert to alternative routes.
The rate of increase may therefore be less than linear. Hence the choice of LTP
also has an impact on assigned flows as well as delays and equally has an impact
on blocking back (8.5).
8.4.6 Upper Limits on Turning Delays: MAXQCT and MAXDTP

In certain rare circumstances the methods used within SATURN to calculate
either transient or queuing delays within the simulation network can give
unrealistically long delay estimates. Therefore upper limits to both may be set by
the parameters MAXDTP and MAXQCT respectively
Basically unrealistic delays may occur when a procedure that is valid for “normal”
flows is applied under highly “abnormal” flow conditions such as a straight-ahead
movement of 1,000 pcu/hr sharing a lane with an assigned right-turning flow of
0.001 pcu/hr which is totally blocked by opposing traffic. As long as the long
delays are coupled with very low flows, as is virtually guaranteed by the
assignment finding alternative routes, the effect on total vehicle hours is likely to
be negligible. However such situations can have a potentially serious impact on
certain convergence rates and are, at the very least, undesirable.
In order to remove such situations, and to effectively provide a safety valve on
delay calculations, from version 9.2 onwards two extra parameters, MAXDTP and
MAXQCT, were introduced to set upper limits on the transient and queuing delays
respectively. Thus no transient delay can exceed MAXDTP (in minutes) nor can a
queuing delay beyond the simulated time period exceed MAXQCT (in minutes).
Realistic values might be MAXDTP = 10 and MAXQCT = 60.
N.B. Note that MAXQCT in particular should be seen as a temporary stop-gap
only since its use may indicate more serious errors in network coding or in trip
5120257/ Apr 15 8-24

Section 8
matrices. Users should therefore, as part of their network calibration and

validation procedures, investigate all occurrences of MAXQCT with a view to
removing them.
From version 10.5 onwards MAXQCT is also used by the assignment model.
Thus the over-capacity queued component of the flow-delay curves as used in the
assignment, i.e., the final term in equation (8.5b), has been re-defined so as to
incorporate an upper limit of MAXQCT (in minutes). The revised curve is
illustrated in Figure 8.5. At a delay equal to half MAXQCT the revised curve starts
to divert from the linear curve and approaches the upper limit of MAXQCT (as
represented by the dashed horizontal line) exponentially.
Figure 8.5 - Revised queued delays as a function of flow with an upper limit of
MAXQCT
The upper time limit MAXQCT may also be interpreted in terms of an upper V/C
limit. We may see what this is by solving an equation:
=
MAXQCT ( LTP 2) * (V C − 1)
Thus if MAXQCT = LTP then the upper limit in Fig 8.5 corresponds to V/C = 3; if
we take the default values of MAXQCT = 60 and LTP = 30 then V/C = 5.
We may therefore see that MAXQCT only “kicks in” at V/C ratios which are much
higher than would be normally be expected in most networks. However, given that
initial stages of the assignment very often generate extreme solutions with
abnormally high V/C ratios, it is possible that the upper delay limits will at least
have some bearing on the pattern of assignment convergence.
8.4.7 New delay rules in SATURN 10.5: Q105

Partly as a result of an increased awareness of the potential impacts of MAXQCT
(se 8.4.6 above) a number of possible flaws in the calculation of delays within
SATURN were identified. In particular these arose when one or more of the
following circumstances occurred:
5120257/ Apr 15 8-25

Section 8
♦ Very high PASSQ flows (i.e., initial queues well in excess of the capacity of
the subsequent time period);
♦ Very high V/C ratios (such that MAXQCT would come into play);
♦ Lane sharing;
♦ Insufficient capacity for traffic from external zones to enter the simulation
network.
The resulting problems were characterised by extremely poor convergence
between the simulation and the assignment.
As a result the methods used to calculate flow-delay curves and/or lane sharing
were “tightened up” to remove the problems and to provide much more robust
solutions.
It needs to be stressed that these changes only really affect networks which are
very heavily overloaded for one reason or another so that, for the vast majority of
tested networks, the effects will be minimal. Therefore, in order to assist users
who wish to replicate previous results using SATURN 10.5, a new logical
parameter Q105 (set under &PARAM in network .dat files) has been introduced. If
Q105 = T (its default) the new rules are used; if Q105 = F the old rules are used.
Users are strongly advised to keep Q105 = T. Even if Q105 is F it does not
guarantee that old results will be replicated since, inevitably, there are a number
of other new features in 10.5 which cannot be removed and which will also give
potentially slightly different results.
N.B. From release 10.9 onwards Q105 is always assumed to be T, i.e., setting to
F has no effect.
8.4.8 The Calculation and Display of Queues

This section describes in somewhat greater detail how queue profiles, average
and maximum queues are calculated and displayed within SATURN.
As with delays queues may be subdivided into two components:
♦ ”transient” or “under capacity” queues and
♦ “permanent” or “over capacity” queues

where, for example at traffic signals, the transient queues correspond to the time
spent queuing during the red phase by vehicles which then depart during the
green phase, whereas the over-capacity queues only occur for turning movements
in excess of capacity where a permanent queue builds up which is unable to clear
in a single cycle.
8.4.8.1 Transient Queues

Transient queue cyclical flow profiles (CFP) for each turning movement are
calculated by the simulation as part of the process whereby the ARRIVE profiles
are converted into OUT profiles (see 8.1.3). It represents the number of pcu’s
5120257/ Apr 15 8-26

Section 8
which are estimated to be queued at the downstream stop line during each of the
NUC time units into which the basic cycle is divided.
In the simplest situation if there are 2 “ARRIVE” pcu’s and 1 “OUT” pcu (e.g.,
during a green phase at signals) then the QUEUE increases by 1. Equally during
a red phase at signals the queue increases with every pcu that arrives since there
can be no departures.
The calculations, however, becomes more complicated with gap-acceptance at
priority junctions or roundabouts where probabilistic arguments come into play;
e.g., if an acceptable gap appears in the major flow we need to know the
probability that there is at least one vehicle in the queue which can accept it.
Therefore we need to know the probability distribution of the number of vehicles in
the queue which is related, via a sub-model within the simulation, to the average
queue length. Thus, if the average queue length is, say, 1 it does not necessarily
follow that there is always a vehicle available to accept a gap: an average queue
of 1 could result if there were a 25% probability of no queue, a 50% probability of
1 pcu and a 25% probability of 2 pcu’s (hence a 75% probability that the gap will
be accepted), as opposed to 100% probability that there is always exactly 1 pcu in
the queue which also gives an average queue of 1 but a 100% probability of the
gap being accepted. Essentially the greater the average queue length, the
greater the probability that there will be 1 or 2 more queued pcu’s available to
accept a gap.
Additional technical information on the probability distribution of queued vehicles,
etc. etc. is contained in the technical file notes as referred to at the end of
Appendix C. Copies are available either from DVV or from Atkins.
8.4.8.2 Over-Capacity Queues

Over-capacity queues are described in greater detail in 17.6.1 and illustrated in
Fig. 17.3.
The basic principle is that if the (permanent) queue at the start of the modelled
simulation period (LTP) is zero and during each cycle (LCY) the number of pcu’s
that arrives exceeds the number that can depart by x then by the end of the time
period the permanent queue will have increased linearly from 0 up to x * LTP/LCY
(or, strictly, 60 LTP/LCY since LTP is defined in minutes and LCY in seconds).
(Note the linear growth model is based on the fundamental SATURN assumption
that flows are constant throughout the time period modelled.)
If there is a permanent queue at the start of the time period associated with
PASSQ (see 17.3) then the linear increase is added on to that initial queue.
Although, clearly, if you start with an initial queue but the capacity exceeds the
arrival flow in that time period (V<C) then the permanent queue will decrease
linearly and might, potentially, be reduced to zero at some point before the end of
the time period.
8.4.8.3 Average Queues

Average queue lengths may be calculated either as the transient average (i.e.,
averaged over the cycle) or the over-capacity queue averaged over the time
period (generally the average of the initial and final queues unless, using PASSQ,
5120257/ Apr 15 8-27

Section 8
the permanent queue goes to zero part way through the time period) or as the
sum of the two.
In general the term “average queue”, if not specifically modified as in “average
transient queue”, is assumed to refer to the sum of the two. For example, in P1X
annotations, “average queue” always refers to the total queue.
8.4.8.4 Maximum Queue Lengths

We may define maximum queues for either transient or permanent (V>C) queues
separately or as their sum.
Thus the maximum transient queue length is the maximum reached during a
single cycle (which, generally speaking, only differs significantly from the average
transient queue at signalised junctions where the maximum queue tends to occur
at the start of a green stage).
The maximum over-capacity queue will occur either (most commonly) at the end
of the time period if V > C and the queue is increasing or, otherwise, at the start of
the time period as determined by PASSQ. In the simplest case of V>C and no
PASSQ the maximum (final) queue is twice the average.
The absolute maximum queue is therefore the sum of the two.
Note that the “maximum transient queue” is more like the “average maximum
queue per cycle” than the “longest queue length reached during the time period” –
where the latter is likely to occur when, at random, a particularly heavy surge of
traffic arrives some time during the time period and/or there is a particularly heavy
surge of traffic on a major arm which reduces the available gaps. In real life it is
probably more realistic to think in terms of a probability distribution of maximum
queue lengths; however this is the sort of detail that only a true micro-simulation
model is capable of providing whereas SATURN can only work in terms of
averages. Clearly one would expect that the SATURN average would be an
under-estimate of the “worst case scenario”.
8.4.8.5 Queue Units and Queues per lane

In general queues are represented in units of pcu’s (as opposed to a length in
metres back from the stop line) and aggregated over all lanes. However, in
principle at least and since SATURN “knows” the distribution of turning flows per
lane, it is possible to calculate transient, over-capacity and maximum queues by
lane.
8.4.8.6 Display of Queues

The (transient) queue profiles per turn may be displayed numerically within the
SATLOOK node display menu (option 4). In addition SATLOOK node display
may also display the maximum and the average transient queues, the average
over-capacity queue and the total average queue, all disaggregated by either link,
turn or lane (option 17).
Over-capacity queues by link and aggregated by node are also listed as
“tailbacks” in the node display menu as illustrated in Table 17.1.
5120257/ Apr 15 8-28

Section 8
The total (i.e., transient plus over-capacity) average queue length per simulation
link is included as an array (DA code 1433) within every .ufs file and may be
displayed as a link property using P1X (along with various other definitions of
queues such as the V>C queue at the end of the time period). As mentioned
above this array is in units of pcu’s aggregated over all turns and all lanes.
Similarly maximum transient queues per turn and per link are also stored as DA
codes.
8.4.8.7 Comments
Finally we note that the queuing model used in the SATURN simulation is
somewhat simplified. For example, it is basically a “vertical” queue model in which
vehicles arriving at the downstream stopped line are added to the queue. It
therefore ignores the fact that the vehicles actually arrive at the end of the queue
a bit further back on the link and therefore spend a bit longer in the queue than in
“cruise mode” (although the total travel time on the link is unaffected). It also
ignores the phenomenon whereby, at traffic signals, the queue continues to
progress backwards at the start of a green phase until the “start wave” meets up
with the “arrival wave” (in terms of shock wave theory).
This, along with other sources of error in calculating flows and capacities, means
that any queue lengths calculated by SATURN need to be taken with a large
pinch of salt. For example, it is not very realistic to expect the modelled queue
lengths to closely reproduce observed queue lengths (however they are defined);
at best one might hope to classify a link into very broad bands such as “well below
capacity”, “roughly at capacity”, etc., etc. and hope that at this level modelled and
observed queue lengths match.
8.5 Blocking Back

“Blocking back” refers to the situation where the queue of vehicles on a link from A
to B extends back as far as the upstream junction A and reduces the flow of
vehicles entering A-B. Blocking back is modelled in the simulation network but not
in the buffer network. More precisely it occurs on a simulation link if either the
average or the maximum (see 8.5.2 (h) below) queue over the time period
simulated exceeds the link stacking capacity; if so, a “blocking-back factor” - BBF -
is applied as a uniform reduction factor to the capacities of ALL turns entering A-B
at A and (potentially - see note b), 8.5.2) to all centroid connectors entering that
link. The size of BBF is chosen such that the average/maximum queue (see 8.5.2
(f)) resulting from the reduced entry exactly equals the stacking capacity. (N.B.
Note that the flows in question are always actual, not demand.)
The blocking-back factor is applied to capacities, not to actual entry flows, and its
value is in fact primarily determined by the V/C ratios of the feeder turns, not the
degree of over-saturation of the link itself. For example, imagine a link which is fed
by a single turn with an (actual) flow of 500 pcu/hr and a capacity of 1,000 pcu/hr,
and that the entry flow of 500 pcu/hr causes a queue which marginally exceeds
the stacking capacity S but that reducing it by 1 pcu/hr would yield a queue
exactly equal to the stacking capacity (i.e., Q(499) = S, Q(500) > S). Here BBF
would need to be 0.499 in order to reduce the capacity and the flow to 499 pcu/hr,
despite the fact that the queue was only marginally over-capacity. Had the
5120257/ Apr 15 8-29

Section 8
capacity been 500 the blocking back factor would only have been 499/500 =
0.998.
Generally speaking, if a blocking back factor is applied on a link A-B then there
must be one or more turning movements into A-B for which the flow exceeds
capacity and therefore for which over capacity queues (8.4.8.2) and V>C delays
(8.4.2.2) result. There is, however, one exception to this rule as described in note
g), 8.5.2.
8.5.2 Specific Properties of Blocking Back

The following specific points regarding the operation of blocking back deserve
mention:
a) Blocking back is only applied (downstream) at traffic signals and priority
junctions, not to roundabouts, dummies or external simulation nodes. The
reason why roundabouts are excluded is that the capacities of exit arms at
roundabouts are not modelled at present, only the capacities of entry arms.
Dummies are excluded because, by definition, no restrictions are applied
there (but see the discussion in 8.5.5 regarding “chains”), while turning
movements are not simulated at external nodes.
Note that this restriction does not apply to blocking back upstream from
roundabouts so that a long queue which builds up at the entry to a
roundabout can block the upstream junction (unless, of course, the
upstream junction is also a roundabout). However a long queue back from,
say, a signalised junction to a roundabout would have no effect.
b) Blocking back also applies to any centroid connector flows entering the
blocked link. For example, if a link A-B has an upstream entry flow of 500
and a downstream centroid entry flow of 500 as well and the exact capacity
and stacking capacity of A-B is such that a flow of 600 would block the link
upstream then both the upstream and the zonal entry flows are reduced pro
rata to 300. (Normally simulation centroid connectors are assumed to have
an “infinite” capacity – numerically 99999; this is the one exception.)
The queued traffic on the centroid connector is treated in the same manner
as any other permanent queues at turns; i.e. the actual flows downstream
would be reduced and, in the case of running a subsequent time period
under PASSQ, the “missing” flows would be “passed over” as fixed flows.
The existence of blocking back on a centroid connector is indicated by a
finite capacity (which is related indirectly to BBF) as stored in DA code 1383.
(Previously (pre 9.3) centroid connector flows were, in effect, given priority on
blocked links. Hence, in the above example, the centroid entry flow of 500 was
allowed in full but the BBF would have been set so as to reduce the upstream
entry flow to 100. This could lead to potentially extreme situations where, if the
zonal flow exceeded the maximum permissible flow on its own, the upstream
entries would be reduced to near zero.)
c) Blocking back can extend over several junctions; e.g., a queue at A can
cause blocking back at B, the reduction in capacity at B can cause queues
which block back to C, etc., etc. (Note however that if B were a dummy link
in the middle of link C-A the queue would only progress as far as B and
5120257/ Apr 15 8-30

Section 8
there would be no queue on C-B; in such cases it would be preferable to

represent B as a priority junction where the effect of blocking back would be
included.)
d) Stacking capacities are generally determined by the parameter ALEX (See
6.4.11) so that if ALEX is set to 0.0 all blocking back calculations are
suppressed.
e) The level of convergence of blocking back is monitored within the simulation
by printing the number of links where the queue is: (a) too high, (b) about
right, and (c) too low (but where a blocking back factor is still applied) plus
figures of the total absolute differences in pcus.
BLOCKING BACK CONVERGENCE STATISTICS:
3 LINKS WITH QUEUE GT STACK - TOTAL EXCESS PCUS 59.62
0 LINKS WITH QUEUE LT STACK - TOTAL SPARE PCUS 0.00
0 LINKS WITH QUEUE EQ STACK (TO +- 0.1 PCU)
3 LINKS WITH BLOCKING BACK; SUM OF ABSOLUTE
DIFFERENCES BETWEEN QUEUES AND STACKS 59.62 PCUS.
f) The queue length used to determine whether blocking back occurs includes
both the (average) transient queue length and the over-capacity component
(for which two options exist as explained in note h) below). However, a
further condition is that, in order for blocking back to be applied from a
downstream link into its upstream link(s), there must be at least one over-
capacity turn out of the downstream link. This is to avoid possible problems
with very short links (e.g., where a pedestrian crossing node has been
included a few metres away from a signalised junction) where the average
transient queue on its own may exceed the stacking capacity.
If the transient queue does exceed the stacking capacity on its own but
none of the turns downstream are over capacity then it is assumed that the
queue may “temporarily” spill back into the upstream link(s) without
necessarily causing any blocking back on those links. For example, the
“saw-tooth” queue which is typical of signalised nodes may extend into the
upstream link during the “red” part of its cycle when the queue is at or near
its maximum length but not during its “green” phase. In this case we make
the assumption that the capacities of the upstream links are not
systematically reduced by a blocking back factor.
g) There is, however, one rider with respect to the (relatively infrequent)
situation where transient queues exceed the stacking capacity but there are
no downstream turns where V>C. For example, considering the link A-B with
the numerical values given in 8.5.1 above, imagine that an entry flow of 500
gives a transient queue at B which exceeds S but for which there are no
V>C queues at B. If, furthermore, a minimum entry flow of 750 would be
required in order to create a V>C queue at B then a blocking back factor of
0.75 is applied to reduce the upstream entry capacity to 750. Which, given
the current entry flow of 500, will not limit the flow entering A-B and which
will not create permanent queues at A. However, by creating a capacity of
750, it will at least “discourage” any future assignment from assigning a flow
in excess of 750 to A-B.
5120257/ Apr 15 8-31

Section 8
On the other hand if the minimum entry flow at which V>C at B were above
1,000 then no blocking back factor would be applied to A-B.
h) The choice between basing blocking back on average or maximum queues
is determined by the logical parameter QUEEN (see 6.3.1), FALSE or TRUE
respectively. Setting QUEEN=FALSE, average queues, is probably
recommended for models of a single time period (no PASSQ) where the
over-capacity queues start by definition at zero and grow linearly so that the
maximum is always at the end of the time period and the average over-
capacity queue is therefore half the maximum. This therefore reduces the
onset of blocking back which, from the point of view of convergence, is
probably a good thing.
However for multiple time periods there are distinct advantages in setting
QUEEN=TRUE, maximum queues, since one might expect that the
maximum queue, once formed, would continue to block back at the same
level over several time periods until it dissipated. This also minimises
problems of oscillating queue lengths. However, we note that this option is
very rarely used with user feedback suggesting that the resulting levels of
congestion in the subsequent time periods were too high. Further feedback
from user’s applications would be welcome.
8.5.3 Blocking Back, Gap Acceptance and Yellow Box Discipline

Blocking back, as modelled in SATURN, effectively assumes that “yellow box
discipline” occurs at blocked junctions. For example, if link A-B feeds directly (i.e.,
in a straight line) into link B-C and link B-C blocks back into A-B then it is assumed
that vehicles on A-B wait at their stop line until there is space for them to enter B-
C. This implies, therefore, that they do not, for example, restrict traffic which
crosses B at right angles to A-B-C without having to give way.
It also implies that, for traffic which does have to give way, there will be gaps in
the movement A-B-C. For example, traffic from C-B which turns across and gives
way to A-B-C (right turners for drive on the left, left turners for drive on the right)
will not be totally blocked. (These turns would be assigned a priority marker X.)
Thus equations such as (8.2) will continue to apply with the “major” flow V 1 (i.e.,
A-B-C) being the restricted flow due to blocking back and therefore less than the
saturation flow S 1 .
However, prior to SATURN 10.4, the yellow-box give-way rules only applied to
priority junctions, not when junction B was signalised. Thus, at signals, if the
turning traffic out of C-B were coded as priority marker X, it was assumed that
(during those stages when both movements had green) the “major” flow across A-
B-C would be continuous and that there would be no gaps available. Thus the
only way that X-turners could cross A-B-C would be as “TAX” vehicles at the end
of each green phase (or, clearly, during any stages when the crossing traffic had
its own exclusive green signal).
In 10.4, however, the yellow-box rules were extended to also cover the above
situation. This meant that signalised X-turners were given a greater capacity at
blocked back junctions than they would have had in earlier versions. N.B. The old
situation may be retained by setting NFT = 103 or less (although in the initially
5120257/ Apr 15 8-32

Section 8
released version 10.4.10 this facility was not included and the new rule was
effectively “hard-wired in”).
8.5.4 Additional Blocking Back Restrictions in 10.5

Blocking back rules were extended in version 10.5 as follows. (N.B. Some of
these rules have been modified under 10.9 with BB109 = T; see Section 8.5.5
below. Read both together!)
Firstly, if, in a simulation link (A,B), A is not an external node (in which case there
would be no blocking back on the link for the reasons as explained above in 8.5.1)
but is connected directly to an external node by one or more intermediate two-arm
nodes then there is no blocking back on (A,B). In other words, as illustrated in
Figure 8.6(a), if A is some form of “artificial” node that has been inserted in what is
essentially a single road from an external node X to B then full set of links
between X and B are modelled as a single link.
Figure 8.6(a)- A 2-arm node A connecting an internal and external simulation nodes (B
and X)
Similarly, if A is a 2-arm node between two “proper” simulation nodes S and B as

illustrated in Figure 8.6(b), then the stacking capacity used to judge whether or not
queues on (A,B) are actually blocking back through A and all the way back to S is
the sum of all the stacking capacities between S and A.
Figure 8.6(b) A 2-arm node A connecting two internal simulation nodes (B and S)
A common example of the above geometry occurs when A represents a

pedestrian crossing in the middle of (S,B). Frequently A may be very near to be B,
say 10 metres or less, in which case the stacking capacity of A-B may only be one
5120257/ Apr 15 8-33

Section 8
or two pcu’s and blocking back can occur very easily and with unrealistically high
impacts upstream. The new rule prevents this happening.
However, there is one exception to the second rule which is when link (A,B) has
more lanes than (S,B), e.g., there is a flared segment at the end of (S,A). In that
case link (A,B) may block back directly into (S,A) and we treat A as a “genuine”
node.
N.B. This rule does not apply post 10.9 under BB109 = T (see 8.5.5 below) where
alternative rules are introduced to identify genuine mid-link nodes which “break”
chains.
In release 10.8 the above rule was extended to work in a “downstream” sense as
well as “upstream”. Thus, in the above diagram, assuming that A-B did not have a
sufficient queue to block back on its own but S-A did (e.g., A was very near to S
rather than near to B) then the stacking capacity considered for S-A would be the
sum of S-A and A-B.
8.5.5 Blocking Back along “Continuous Chains”

The situation depicted in Fig. 8.6(b) has been extended in SATURN Version 10.9
to apply to all “link chains” (see 5.1.12) where a “real” road between two “real”
junctions has apparently been coded, for good reasons or bad, by including one or
more intermediate “artificial” nodes. Thus links S-A and A-B constitute a chain as
would B-A plus A-S. The new rules apply if parameter BB109 = T as set under
&PARAM in the network .dat file (default = T post 11.2, previously F but
recommended T).
Thus, if a series of links is judged to be a “chain” which commences with a link A-
B and terminates with link Y-Z, then the relevant stacking capacity is the sum of
the “normal” (i.e., distance-based or explicit input; see 6.4.11) individual link
stacking capacities from A-B to Y-Z and the queue length is calculated primarily at
Z (although contributions from intermediate links are sometimes included). If the
total queue exceeds the total stacking capacity then a blocking back factor is
calculated for the upstream link A-B in order to restrict entry flow into A-B. The
objective, therefore, is to create a (downstream) queue at Y-Z which will stretch
back precisely to (upstream) node A.
In addition, if the chain blocks back, each internal link within the chain blocks back
into its upstream feeder link so that queues on internal links within the chain
should equal their individual stacking capacities. Thus Y-Z blocks back into X-Y,
X-Y into W-X etc. etc. until the upstream link A-B has been reached.
If, on the other hand, the total queue along the chain does not exceed the total
chain stacking capacity then there is no “internal” or “intra-chain” blocking back
modelled either. For example, referring to Fig. 8.6(b), if Q AB + Q SA < S AB + S SA
then (a) there is no blocking back at S but (b) neither is there blocking back at A
even if Q AB > S AB ,
The purpose of this rule is to reduce the overall application of blocking back to
“major” junctions so as to minimise any convergence problems which may be
created by blocking back on very short “internal” links.
5120257/ Apr 15 8-34

Section 8
STOP PRESS: Post release 11.1.9 the “internal” blocking back as described
above has been removed in order to improve convergence so that currently the
full queue is allocated to the most downstream link (i.e., Y-Z above), the blocking
back is applied at the upstream link (A-B above, so no change there) and there is
no blocking back and/or queues on any of the intermediate links.
We note that the definition of when a series of links constitutes a chain is set in
the network build stage by SATNET whereas, pre 10.9, the identification of
intermediate nodes was carried out entirely within the simulation. 10.9 has also
extended the definition of a chain to several alternative configurations as depicted,
for example, in Figure 5.2 (b), (c) and (d).
8.5.5.2 Dummy Nodes in Chains

The definition of a chain in 10.9 for the purposes of adding stacking capacities
also differs from that applied previously (i.e., as described in 8.5.4) in that a 10.9
chain allows 2-arm dummy nodes (junction type 4) to be part of a chain whereas
previously they were excluded. For example, in Figure 8.6(b), if A were a dummy
node then the stacking capacities of B-A and A-S would not have been added
together while in 10.9 they would be. Therefore, for the purposes of upstream
blocking back, queues are allowed to “jump over” dummy nodes.
On the other hand there is no explicit blocking back through dummy nodes, either
in 10.9 or 10.5. Thus, again referring to Fig. 8.6(b), turning movements entering S-
A would be restricted by blocking back if the (total) queue on S-B were greater
than its (total) stacking capacity but there can never be any restrictions on traffic
passing from S-A to A-B through dummy node A. (The basic property of a dummy
node is that it effectively has infinite capacities and traffic entering on one arm
passes unimpeded to its exit arm.)
8.5.5.3 Lane Changes within Chains

In addition, any restrictions in 10.5 associated with the number of lanes increasing
or decreasing along a “chain” (see 8.5.4) have now been dropped with BB109 = T.
However users may explicitly allow for the effect of lane reductions etc. by the use
of certain coding “tricks” as explained next.
8.5.5.4 Breaking Chains: Negative Stacking Capacities

Post 10.9.18 it is possible to “break” a chain by including a negative value for the
stacking capacity defined in field 1, columns 1-5, on a simulation link data record.
Thus, referring to Fig. 8.6.(b) above, if the stacking capacity of link S-A were input
with a negative value then the chain from S to B would not be extended through A
and links S-A and A-B would be treated as independent links as far as blocking
back is concerned. (The same as would have happened under 10.5 if B-A had
more lanes than S-B)
Thus if the queue on A-B exceeded the stacking capacity on A-B then the capacity
for turn S-A-B would be suitably reduced. Similarly if the queue on S-B exceeded
its stacking capacity entry traffic into S-A would be reduced. So neither, one or
both could block back depending on the Q vrs. S values on each individual link.
5120257/ Apr 15 8-35

Section 8
This situation has been found to occur on entry ramps onto a motorway where a
signalised junction at A controls the flow entering the motorway at B by the choice
of percentage green time at A.
8.5.5.5 Q / S Ratios on Chained Links

Due to the way in which “intra-chain” blocking back is or is not modelled (see
8.5.5.4 above) it is possible, when the chain as a whole does not block back, that
the queue at the most downstream link in the chain may exceed its own individual
link stacking capacity without any blocking back mechanism being introduced in
order to bring its ratio down to 1.0. In such cases for reporting purposes we treat
the stack for the individual link as though it were the summed stack for the chain
so that the reported Q/S ratio will be less than 1.0, consistent with there being no
blocking back.
8.5.5.6 Modelling “Partial” Stacking Chains at Y-junctions

It is possible that a Y-configuration of 3 links – a stem plus two arms, all one way
– may lead to a mis-representation of stacking capacities along the exit arms if
the two arms have exclusive entry lanes on the stem which may provide extra
storage space for individual queues. Consider junction B as illustrated in Figure
8.7 below where the entry arm from A has two lanes, one of which exclusively
feeds the exit to C and the other exclusively feeds D.
Figure 8.7 - A “Y Diverge”
Imagine that the queue on B-D exceeds the normal stacking capacity on that link
and extends backwards into link A-B. Under normal SATURN rules this would
mean there would be blocking back on A-B which would reduce the exit capacity
to both exits C and D.
However what might happen “on the ground” is that the queue from B-D only
blocks back into and is contained within its own outside lane on A-B and that the
turning movement A-B-C and its exclusive inside lane are unaffected. We could
therefore think in terms of two “partial chains” – B-D plus the outside lane on A-B,
B-C and the inside lane on A-B – for which we would like to define increased
stacking capacities.
A pragmatic solution to this problem would be to increase the stacking capacity on
B-D to include the additional stack from the outside lane on A-B, ditto with B-C
and the inside lane. If the queue on either B-D or B-C then exceeded the
increased stack then blocking back would be correctly(?) applied to both exits.
5120257/ Apr 15 8-36

Section 8
At the moment the pragmatic solution proposed above is not automatically

invoked within SATNET but two Serious Warnings (76 and 77) flag the problem so
that the user may manually adjust stacking capacities to take on board the
possible increases in stacking capacities. Any such adjustments should also take
into account how far back along the link the exclusive lanes operate. For example
if a link were 1 km long but the exclusive lanes were only operative over the last
50 metres then any increasing in stack should be based on 50 m, not 1,000.
Increasing stacking capacities in this way may seem a bit over-elaborate and a bit
unnecessary – and in most networks there are probably very few examples in the
first place and, for those that there are, blocking back is not an issue – but there
are certain circumstances in which doing nothing may lead to extreme problems of
convergence.
In one particular case the Y-junction B depicted above was at a point, say, 10
metres back from a signalised junction at D and the link B-C was a short slip road
which enabled traffic to turn left without going through the signals proper (so
effectively a filter/flare). In this case the stacking capacities on both B-C and B-D
were relatively small, e.g., less than 5 PCUs, and the transient queues at D were
normally well in excess of 5 PCUs, This situation then led to extreme flip-flops in
capacities and flows. If the approach B-D were slightly over capacity the link
would block back and effectively close off the slip road; the overall reduction in
capacity would then cause the flows to revert to under capacity conditions on the
next iteration and the blocking back would disappear. End result: the whole model
failed to converge quite spectacularly. Take note!
For this reason the Serious Warnings are sub-divided into 76 and 77 depending
on whether or not one or both of the exit arms had stacking capacities below 5.
8.5.6 Phased-in Blocking Back (BB109 and BBKING)

Version 10.9 introduced a new – and hopefully very useful – concept of “phased in
blocking back” whereby, if the queue on a link is “almost” equal to its stacking
capacity, then a blocking back factor is introduced but reduced in scale depending
on the degree of under-saturation.
The new rules are applied if &PARAM namelist parameters (a) BB109 = T (default
= T) and (b) BBKING < 1.0. Thus BBKING (Blocking Back Kicks IN Geddit?) = 0.8
implies that if the queue is less than 80% of the stacking capacity – Q/S < 0.8 -
then no blocking back factor is applied; however if BBKING < Q/S < 1.0 then a
blocking back factor is calculated as though S = Q but then increased towards 1.0
in proportion to (1.0 - Q/S) / (1.0 – BBKING). So if, for example, Q/S = 0.95,
BBKING = 0.8 and the initial blocking back factor with S = Q were 0.6 then it
would be increased to 0.7. If Q/S = 0.81 it would be 0.98. (Recall that a blocking
back factor of 1.0 implies no blocking back capacity reduction upstream.)
8.5.7 Blocking Back and Convergence Problems

Blocking back, particularly if it extends over two or more successive links, is a
possible cause of convergence problems, both within the simulation itself and also
within the simulation-assignment loops.
The worst cases very often arise on very short links where the stacking capacity
(particularly if it is calculated by default using ALEX and the link length; see
5120257/ Apr 15 8-37

Section 8
6.4.11) is very small and a very small change in assigned and/or simulated flow
can have a very large impact on blocking back factors. A not infrequent example
is a pedestrian crossing slightly displaced from a signalised junction which is
coded as a separate node with a connecting link of, say, 2 metres. In this case the
stacking capacity may be less than 1 pcu and almost any over-capacity queue will
create severe blocking back. Other examples occur at signalised roundabouts
which are coded (quite legitimately) as a series of separate signals with very short
links and, again, very small stacking capacities.
In principle, the “sum of stacks” rules described in 8.5.4 and 8.5.5 may adequately
deal with the problems; however, this may not always be the case.
In such situations it is very often good practice to explicitly define stacking
capacities on the link records which reflect the “full” stacking capacity of that link
and its immediate predecessor(s) in order to prevent unstable blocking back
patterns. One such example has already been described in 8.5.5.6.
As a general principle it is probably preferable to have a model which converges
well but which fails to detect certain potential occurrences of blocking back than to
have a model which detects all possible blocking back situations but converges
badly. (Although ideally one would like to have both; unfortunately this may not be
always achievable within time constraints, etc. etc.)
Tables showing the (up to) 10 worst links in terms of changes in their blocking-
back factors from one simulation to the next are given in the SATALL .lpt files
(see 9.9.1) and may also be viewed interactively within P1X.
8.6 Random Delays and Queues (LRTP)
8.6.1 General Principles: “Major Arms”

The basic theory of cyclical flow profiles described in 8.1 assumes that the same
pattern of movement is repeated every, say, 90 seconds so that the same number
of vehicles arrive at a junction during each 90 seconds. In reality this is not of
course true and some variations about the mean are to be expected, not only from
one cycle to the next but also from one day to the next or from one week to the
next. The effect of this random element is generally to increase delays and/or
queues (see 8.6.5), particularly when a junction is near to its capacity, as random
fluctuations in the arrivals may cause temporary over-saturation which may
require several cycles to dissipate.
The effects of random arrivals are explicitly accounted for in the SATURN
treatment of delays to give-ways at roundabouts and minor arms at priority
junctions. However at major arms at priority junctions and all arms at traffic
signals delays are explicitly divided into two components - a “uniform delay”
calculated from the queuing cyclical flow profile (Section 8.1.3 above) plus a
“random delay” component which is calculated from the following formula as used
in the traffic simulation model TRANSYT:
Equation 8.8
=(d ) { 1/ 2
(T / 4q ) ( q − s ) + ( 4q / T ) 
2
}
+ (q − s)
5120257/ Apr 15 8-38

Section 8
where:
(d) = the average random delay per vehicle
T = the time period over which:
q = the arrival rate is q (in pcu/hr), and
s = the capacity (in pcu/hr).
which in the limit of q = s, i.e., capacity flow, reduces to:
( d ) = ( T / 4q )
0.5
For over-capacity turns, q> s, random delays are “capped” at the maximum value
calculated for q = s. In addition the definitions of q and/or s may be affected by
lane choice and/or blocking back; see 8.6.3 to 8.6.6 below.
As an example for a flow equal capacity of 1800 pcu/hr with LRTP = 30 (minutes)
<d> would be 30 seconds. For LRTP = 60 minutes it would be 42.4 seconds or
with flow and capacity doubled it would reduce to 21.2 seconds. At 90% of
capacity (q = 1620, s = 1800, LRTP = 30) <d> would be 9.16 seconds.
Hence the contributions from the random delay components are not particularly
large and, in terms of modelling “realism”, are probably preferable to assuming
zero or near zero delay for flows right up to capacity. The latter affect occurs in
particular with major arms at priority junctions where, unlike signals, there is no
cause of delays (apart from possibly small perturbations in the arrive profiles due
to platooning from traffic signals which can cause temporary periods of over-
saturation to occur during the simulated cycle). The introduction of a random
delay component is therefore generally to be recommended by setting LRTP > 0.
Note that in calculating <d> in SATURN the time period T need NOT be identical
to the time period simulated - in fact the value of T used is given by the parameter
LRTP (Length of the Random Time Period) as opposed to LTP. There are two
essential reasons for this:
♦ By setting LRTP = 0 the user can effectively suppress all random delays since
in this case <d> = 0 (not recommended; see below);
♦ The random delays calculated for, say, two successive 15 minute time
periods will not be the same as the delay calculated for a single 30 minute
time period. Thus LRTP should be chosen to approximately equal the length
of time since the flow became equal to q, e.g., the beginning of a peak period.
This distinction, however, is probably only critical to users who are using
SATURN to look at successive time periods, not those who are modelling a
single time period.
As a rule of thumb we would recommend that, for single time period models,
LRTP should be set equal to LTP. For multiple time periods LRTP should probably
be longer than the LTP-values for single time periods but possibly less than the
total time period modelled.
However, whichever value is chosen for LRTP, we would also strongly
recommend that it not be left at its default value of zero since:
5120257/ Apr 15 8-39

Section 8
a) the additional delay contribution is probably realistic and (b) by making delay
a “smoother” function of flow it makes both assignment and assignment-
simulation convergence easier.
b) applies particularly to major arms at priority junctions where, if LTRP = 0, it is
possible to have zero delay from zero up to capacity flow followed by a
sharp (discontinuous) transition to linear over-capacity delays; see 9.5.1.
8.6.2 Random Delays at Give-way Movements (RAGS)

From version 10.5 onwards random delays may also be applied to turning
movements which are “give-way” (i.e., from minor arms at priority junctions, filter
turns at signals or all entries at roundabouts) if the parameter RAGS = T, using
equation (8.8) but with one important distinction.
Thus with give-way movements the quantity “s” in (8.8) is interpreted as the
saturation flow rather than the capacity. Generally speaking at give-way turns the
capacity will be less than - possibly considerably less than - the saturation flow
due, in particular, to the reduction due to gap acceptance in major arms’ cross
traffic. Equally delays are high. However, if (unusually) there is zero cross traffic
then capacity C equals saturation flow S and delays will be virtually zero for all
flows up until C (i.e., S). Setting RAGS = T introduces extra delays as V
approaches C (i.e., S) which, it could be argued, are more realistic.
On the other hand, if the cross traffic is significant and the capacity C is (much)
less than S then the delays calculated by equation (8.8) will be small and the
additional delays generated by setting RAGS = T will equally be insignificant.
In most situations the latter case is most common and it is therefore expected that
setting RAGS = T will have a relatively small impact on total network performance.
Although the default value of RAGS is .FALSE. (see 6.3.1) this is largely for
reasons of compatibility with previous versions and a value of .TRUE. is generally
recommended.
8.6.3 Random Delays with Shared Lanes: River and/or Estuary

Random delays calculated for turning movements which share lanes with other
turning movements are calculated using flows and capacities (i.e., q and s in
equation 8.8) aggregated over all movements with common lanes, generally
referred to as “rivers”; see 8.8.2. Thus all turns within the river will experience an
identical random delay.
However, the definition of which precise turns are combined together into a
particular river depends on the modelled lane choice and is not necessarily fixed;
these may lead to certain problems of “discontinuity” in calculating random delays.
For example, consider a 2-lane road in which left turns may only use lane 1, right
turns may only use lane 2 and straight-ahead traffic can use either lane 1 or lane
2. If the straight-aheads actually use both lanes then all three turns will be in the
same single river and they will have the same random delay. However, if the
straight-aheads only use lane 1 then there will be two separate rivers with distinct
random delays.
5120257/ Apr 15 8-40

Section 8
The problem which this introduces is that the random delays may jump in a
discontinuous fashion with changes in flow as the lane choice shifts between
shared lanes and a single lane. This, in turn, creates problems of convergence
between assignment and simulation.
This problem may be overcome if the random delays are based on “estuaries”
rather than “rivers” where an “estuary” is defined to be a river assuming that all
available lanes are used by all turns. Thus, in the above example, all three turns /
both lanes would always be in the same estuary independent of the actual lane
choice. If, therefore, we always use the estuary to define the aggregate flows and
capacities for random delay calculations there cannot be any discontinuities in the
calculation.
To use the estuary definition rather than the river definition a logical parameter
RTP108 must be set to .TRUE, under &PARAM in the network .dat file. N.B. The
default value for RTP108 was changed to T from F in release 10.9.
8.6.4 Random Delays on Link Chains (10.9)

The concept of “link chains” has been described in section 5.1.12 whereby a
single “real” link is (presumably artificially) subdivided into a continuous set of sub-
links, e.g., with intermediate 2-arm nodes. In such cases we presume that the
queue should form primarily on the (sub-) link at the (downstream) head of the
chain and, therefore, that is only appropriate to associate a random delay with just
that one link. Thus, version 10.9 and beyond, an extra rule has been introduced
such that any links which are part of a chain upstream do not have any random
delay calculated but the downstream “end of chain” link will (provided, of course,
that the other necessary conditions described above are satisfied).
The one exception to this rule is where an intermediate node is signalised, e.g., if
it is a pelican crossing, in which case random delays are applied as per normal.
N.B. There is no parameter provided to turn this new rule “off” or “on: it is always
on.
8.6.5 Random Queues

Following the release of Version 11.1 it is possible to increase the queue length
predicted on a link in proportion to the random delays generated – provided that
the new parameter SIM111 = T as set under &PARAM. Thus the average extra
queue <q> is calculated by the formula:
<q> = <d> x q
Where <d> is given by equation (8.8) and q, as before, is the arrival rate.
Note the same restrictions set by LRTP, RAGS, etc. etc. control where and when
random queues are generated in the same way that they control random delays.
Clearly the end effect of introducing random queues will be not only to increase
queue lengths but also to increase the incidence of blocking back. However by
making the relationship between queue lengths and flows smoother (e.g., there is
less of a discontinuity at V = C) it is to be hoped that it will also improve
convergence.
5120257/ Apr 15 8-41

Section 8
8.6.6 Random Delays and Blocking Back

Post 10.9 the “capacity” used in equation (8.8) to calculate random delay does not
include any reduction from any blocking back on the upstream exit link. The
rationale behind this change is that, since the turn will already be over capacity by
definition since it is being blocked, there is no need to model extra delays due to
the turn going temporarily over capacity.
It also removes a possible discontinuity when the link downstream goes from a
state of blocking back to not blocking back or vice versa.
8.7 Modelling Roundabouts

Roundabouts in SATURN are modelled in effect as a series of 3-way T-junctions
with priority to traffic on the roundabout. Thus equations (8.1) and (8.2) may be
applied to give the capacity C for each entry arm as:
Equation 8.9
C S m (1 − VM / S M )
=
GS M
where:
S m is the saturation flow for that entry;
V M is the on-roundabout flow crossing that entry;
S M is the maximum roundabout capacity as defined on the node data record
RSAT (6.4.7);
G is the gap parameter (GAPR).
(N.B. strictly speaking (8.9) is applied to each individual time unit so that the
ACCEPT or capacity profile may vary over the basic cycle time as the circulating
flows vary.)
This is a somewhat simplified model in that no distinction is made between the
different possible exits from each entry arm or of the possible allocation of
different exit movements to different lanes. Nor does the on-roundabout flow
distinguish between vehicles which are taking the next exit (and might therefore
be expected to be at the “outside” of the circulating lanes and therefore impeding
entry flows the most) and those going on to later exits (on the inside and
interfering least).
In fact turning flows from the same entry arm at a roundabout may be seen as
implicit examples of “rivers” as explained in 8.8.2.
This implies that in fact the values of the first and last lanes used per turn on
roundabouts (see 6.4.1) are ignored and set equal to 1 and the number of lanes
respectively, and equally that the saturation flows per turn must all be equal to the
total saturation flow for the arm as a whole. No turn priority markers are necessary
- the give-way rules are implicit.
The maximum roundabout capacity is also the same for all entry arms and
logically should be greater than or equal to the saturation flow for any input arm
5120257/ Apr 15 8-42

Section 8
(or, strictly speaking, the saturation flow per arm should be less than or equal to
the circulating capacity).
Delays, whether within the simulation or the assignment, are calculated for each
individual entry arm separately based on the total arrival flow on that arm, its
capacity, the probability of gaps, etc. etc. and applied equally to all turning
movements from that arm. (But see the next paragraph for additional turn-specific
delays.) If an arm is over capacity then the nominal capacity per turning
movement is allocated in proportion to their flows.
Note that an extra delay is also added to each turning movement at roundabouts
to reflect the proportion of the total circulating time on the roundabout as defined
in columns 16-20 of the 11111 node data records (6.4.1). Thus if the circulating
time on a 4-arm roundabout is 3 seconds then the circulating time to the second
exit arm would be 1.5 seconds.
We may note that the treatment of delays and flow-delay curves at roundabouts is
an example of the ROSIE option for combining flows in shared lanes; see 8.4.3.
U-turns on 2-way arms are automatically included for roundabouts coded as
junction type 5 but not 2. Since logically U-turns should always be possible on
roundabouts (although not necessarily widely used) it follows that roundabouts
should always be type 5, not 2. Type 2 only really exists for historical continuity.
8.7.2 K s Factors: Modelling the Effect of Entry Flows

As shown in equation (8.9) entry capacity from an arm is a function only of the
circulating traffic at that point. It is possible to extend that definition such that the
total opposing flow V M in (8.9) may be written as:
VM + K s Eij
where E i is the exit flow on that arm (and which therefore exits before traffic
enters). Clearly for a one-way inbound arm E i is zero.
The K s factors may only be defined on a link-by-link basis using the network X-file
facility; see 6.13. There is therefore no universal parameter which may be set as,
for example, with TAX. (In effect the universal default value is zero).
8.7.3 RB106 – Modifications in 10.6

Under extremely rare conditions it is possible for the roundabout simulation to
assign zero capacity to an entry arm without CAPMIN cutting it off at a finite value.
However, in order for this to happen, conditions have to be just right and it took 25
years for the first occurrence!
The correction, introduced in 10.6, involves applying CAPMIN at each time unit
rather than over a full cycle.
Pre 10.9 the new check could be removed by setting RB106 = F in &PARAM; post
10.9 RB106 is ignored and the new methods are always used (so that, in effect,
RB106 = T).
5120257/ Apr 15 8-43

Section 8
8.8 Lane Choice Modelling

The choice of a lane is very often of critical significance in the modelling of turn
capacities. For example, consider the case of a single lane at a priority junction
which is shared between straight ahead traffic and right turners (assuming drive
on the left) where the straight ahead movements are otherwise unimpeded, but
the turning traffic must find gaps in the opposing traffic. If there is heavy opposing
traffic and few gaps the turning capacity will be low and equally, since a straight
ahead vehicle cannot go if there is a stationary turner ahead, the straight ahead
capacity will be low as well. Clearly in this case if there were alternative lanes
available to the straight ahead traffic then they would use them in preference to
the shared lane but even so they would still lose the saturation flow from the
unused (and blocked) lane.

Lane choice in SATURN begins with the definition of available lanes per turn on
the network link data records (see 6.4.9). If there is no lane sharing then traffic is
divided equally amongst its allocated lanes. If two or more movements share then
the lane choice is determined on the basis of, in effect, a Wardrop Equilibrium
Principle (see 7.1.1) whereby:
All lanes used by a particular turning movement have equal ‘stop line delays’
and all unused lanes have equal or greater stop line delays.
Stop line delay is defined in a very similar way to normal delay except that it
includes an element of “clearance time” at the stop line equal to the inverse of the
saturation flow. It is a function of the total flow within each lane.
Further details of the allocation process may be found in SATURN Notes; for the
moment it is sufficient to say that it uses an algorithm very similar to but much
simpler than the Frank-Wolfe algorithm for solving Wardrop Equilibrium
assignment (7.1.2).
We note that lane choice is not fixed but is flow dependent, not only directly on the
arrival rates per turn on one junction arm but also, potentially and more indirectly,
on the flows on other arms which (via give-ways) affect the stop-line delays on
other arms. It is therefore one of the sources of problems for internal simulation
convergence (8.3)
8.8.2 Rivers
For certain modelling purposes turning movements and/or lanes are aggregated
together into “rivers” where a river consists of a set of movements where each
member shares lanes with at least one other member. For example, if a left turn
uses lane 1, straight ahead turns use lanes 1 and 2 and right turns use lane 2
then the left and right turns are in the same river even though they do not have a
lane in common.
Note that the definition of a river is based on “usage”, not purely on lane markings
so that, in the above example, if straight ahead traffic were allowed to use lanes 1
and 2 but (due, say, to heavy right turning traffic) only used lane 1 then the left
and straight ahead traffic would be in one river and the right turners in another.
5120257/ Apr 15 8-44

Section 8
If one member of a river is over capacity then all members are and they have
equal V/C ratios and discharge, in effect, as a single queue. The same principle
applies equally to individual lanes. This has implications for the way in which the
over-capacity delays are calculated, particularly under the ROSIE option (see
7.1.3 and 8.4.3).
Information on actual lane choice, the grouping of turns into rivers, various
definitions of capacities etc may be found using the numerical output tables option
within SATLOOK (11.11.1). An explanation of the tables used is given in the next
section.
We may also note that all turning movements from the same entry arm at a
roundabout are implicit examples of rivers since they are assumed to potentially
share all available lanes. See also 8.7.1.
8.8.2.1 Rivers on Capacity-constrained Links

Finally, rivers may also be created – but very infrequently – on simulation links
with capacity constraints (speed-flow curves) when the arrival flow exceeds the
mid-link capacity and all the exit turns are judged to form a single V>C queue mid-
link. If, however, there is only one exit turn or if the existing turns are already part
of a river (i.e., their lanes overlap) then no extra changes are made to the existing
models of lane choice, queues, delays, etc.
8.8.3 Lane Choice in the Presence of Merges

In general in SATURN the allocation of traffic to lanes on one entry arm is
independent of the allocation of traffic on all other entry arms except in so far as
opposing traffic affects delays via, e.g., gap acceptance.
There is, however, one exception to this rule which is that traffic which merges
(turn priority marker M) from a “minor” arm onto a “major” arm can affect the lane
choice on the major arm based on the (sometimes highly dubious!) concept that
drivers on the major arm will shift away from the lane(s) where merging takes
place in order to make life easier for the merging traffic. The same effect is also
considered on “Y-merges” or “double-M merges” between two equal-priority turns.
The following two sub-sections describe the principles of lane choice for single-M
and double-M merges; section 8.8.4 describes further possible capacity
reductions due to limited space on the exit lanes.
8.8.3.1 Single-M Merges; E.g., Entry Ramps on Motorways (APRESV)

For example, Figure 8.8 illustrates a situation typical of an entry ramp onto a
motorway or other major road where junction B is coded as a priority junction and
turn D-B-C only is assigned a turn priority marker M (i.e., A-B-C has no priority
marker). Assume 2 lanes on A-B, one on D-B. Prior to 10.3, traffic on A-B would
be equally divided between lanes 1 and 2 and the merging traffic would have to
find a gap in the single inside lane carrying 50% of the major traffic. With 10.3
more traffic on A-B would be allocated to the outside lane (i.e., the bottom lane in
the diagram) in order to make the merge easier.
5120257/ Apr 15 8-45

Section 8
Figure 8.8 - Merging traffic onto a Main Road
The amount of traffic transferred between lanes is calculated using the (assumed)
principle that each lane of the “major” arm A-B carries equal flow including the
flow D-B-C allocated to the merging lane (in this case lane 1) but factored by a
parameter APRESV (as in “apres vous”) which indicates the willingness of drivers
to accommodate merges. Thus if APRESV = 0 no preference is given to merging
traffic whatsoever, if APRESV = 1.0 they are effectively given equal weight.
Mathematically we could write:
Equation 8.10
(1) ( 2)
VAB + VDBC ∗ APRESV =
VAB
where the superscripts denote lanes.

Note that APRESV may be set either as a global default parameter in &PARAM
or, post 11.1, as a link-specific value (6.4.14 or 6.13.4).
This allocation is independent of: (a) how many lanes there are on the merging
arm D-B and (b) how many lanes there are downstream of B (except in so far as if
there were 3 lanes downstream of B then D-B-C should probably not have been
coded as a merge in the first place). Similarly, if there were three lanes on A-B
then the same basic principle would apply with equal total (weighted) flow on all
three lanes.
In some circumstances, e.g., heavy merging traffic, light major traffic, it may not be
possible to exactly balance the flows, in which case there might be no major traffic
allocated to the merge lane and the (weighted) traffic in the merging lane would
exceed that in the other major lanes. (It follows that there would therefore be no
traffic for the minor flow to merge with and hence no delay or capacity loss to the
merging traffic).
Clearly the end effect of the new lane choice mechanism is to increase the
capacity for the merging traffic and to reduce its delay with the effect being greater
with increasing values of APRESV.
Note that, with merges (including Y-merges described next), an extra line is added
to lane-choice tables such as 8.1a or 8.2a (see 8.9.1) to indicate the flow of
merging traffic which contributed to the final lane choice.
8.8.3.2 Double-M “Y” Merges

The same principle also applies in the case of a “Y-merge” (Figure 8.9) where two
streams of traffic, both coded M, merge into one with equal priority, as happens
5120257/ Apr 15 8-46

Section 8
commonly when two motorways merge together. In this case BOTH arms will
have their lane choices adjusted such that for both arms the underlying principle
of equal flow per lane (including the “other” merging traffic in the central lane) will
be established.
Figure 8.9 - A “Y Merge”
Note that in the case of a Y-merge the implicit assumption is that there is always
one and only one central shared merging lane independent of the number of lanes
on the two merging arms and on the number of arms downstream. Thus our
model is one of 2 + 2 lanes into 3 or 3 + 3 into 5 even if the downstream arm had,
say, 4 lanes in both cases. (The presumption is that 2 + 2 into 4 would not have
been coded as a Y-merge in the first place.)
There is therefore a strong implication that both arms will have more than one
lane, most likely the same number, and indeed this was the presumption when T-
merges were first introduced into SATURN, However, since then, it has become
evident that Y-merges can also be applied perfectly happily at “asymmetric”
junctions (i.e., a different number of lanes on both arms), of which entry ramps
onto motorways are the most common example.
Our current “best advice” is therefore that double-M merges should be used in
preference to single-M merges in asymmetric situations such as motorway entries
where entry priority is in some sense “shared” between the two flows, even if, in
practice, the on-motorway traffic may have a slightly “higher priority” than the entry
traffic. A potential problem in coding a motorway entry ramp with an M on the
ramp only is that if the flow on the main motorway nears or exceeds capacity the
probability for gaps on the entry ramp nears zero and the entry capacity goes to
zero (or, strictly speaking, CAPMIN).
Note that this advice (post January 2012) contradicts previous advice to use
a single-M coding for motorway entry ramps.
If one arm has only one lane (e.g., a single lane ramp) and the other has multiple
lanes then clearly it is no longer possible to adjust flows on the single lane. Indeed
a Y-merge where one arm has one lane and the other has multiple lane leads to a
“Serious Warning” (131/132) since it is possible for the multi-lane approach to
significantly block the entry capacity for the single lane;
Note that the case of a single lane on both entry arms of the Y is accepted
although possibly unusual in practice.
5120257/ Apr 15 8-47

Section 8
Note that, prior to release 11.1, in the case of a Y-merge the parameter APRESV
was not used as both merging streams were given equal weight with the flows
into which they are merging: in effect APRESV = 1.0 here and no “voluntary” lane
shifting took place. However under release 11.1 traffic flows on both arms are
allowed to change lanes upstream of the Y-merge as reflected by their (link-
specific) APRESV values. By reducing traffic in the shared lanes this increases
the capacity for both movements.
8.8.4 Further Capacity Reductions at Merges (“Funnelling”)
8.8.4.1 “Lateral” and “Funnel” Merges

Section 6.4.2.3 describes the two extreme physical forms of “merges”:
(1) The two lanes that merge or “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.
For example, referring to Figure 8.8, if the motorway has 2 lanes on A-B and 2
lanes on B-C and there is no elongated slip road area for the single lane entry
from D then the merge operation would be a “funnel”. If, on the other hand, there
were a definite slip road that eventually leads to a section of 3 lanes on B-C then
the merging would be more “lateral”. And there will, of course, be intermediate
layouts.
The distinction between a “funnelled” and “lateral” merge can, in certain
circumstances, influence the manner in which capacities are calculated as
discussed below.
In both cases SATURN models the capacity loss due to the “minor” arm seeking
gaps in the “major” arm via the same equation. Thus the capacity C m for a “minor”
turn coded as M is, combining Figure 8.1 and Figure 8.2, given by:
Equation 8.11
Cm S m (1 − VM S M )
=
GS M
We note the critical role played by G S M . Figure 8.10 illustrates graphs of C m vrs
V M under three possible situations where: (a) G S M < 1, (b) G S M =1 and (c) G S M
> 1. Thus, under (a), C m is relatively insensitive to the major flow V M until it
approaches capacity whereas with (c) C m decreases much more rapidly as a
function of V M .
5120257/ Apr 15 8-48

Section 8
Figure 8.10 – Relationship between C M and V M

Curve A Curve B Curve C
Sm 1.0
0.8
0.6
Cm
0.4
0.2
0.0
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
VM SM
The distinction between a funnel and a lateral merge could be partially

represented by the choice of the gap G (i.e. GAPM) Thus a “lateral merge” would,
generally speaking, require a low gap value such that G S M < 1 which would
therefore have a relatively minor impact on capacity; a “funnelling merge” which
represents a greater capacity reduction, would require a larger gap value. Thus
curve (a) in Figure 8.10 might be typical of lateral merging and (c), of funnelling.
However there may be certain conditions under which the explicit capacity of the
exit lane implied by a funnel-merge can further restrict capacities; the various
possibilities are discussed in the following three sub-sections.
8.8.4.2 Minor Arm Capacity Reductions for Single-M Merges

We consider here the possibility of further capacity reductions above and beyond
equation (Equation 8.11) in the case of a single-M merge, as illustrated in Figure
8.8, where the merge is judged to “funnel”. In this case the capacity restrictions on
the exit link may be written as:
Equation 8.12
(Vm + VM ) Sx < 1
where S X is the saturation flow (assumed equal to capacity) of the exit lane. In
general, within SATURN, we will not have the value of S X specified, particularly if
it is at the upstream end of a simulation-coded link. However, if we assume that
the physical characteristics of the exit lane will not be that different from those of
the two entry lanes, we can approximate (Equation 8.12) as:
Equation 8.13
Vm Sm + VM S M < 1
5120257/ Apr 15 8-49

Section 8
or
Equation 8.14
Vm ≤ Cm ≤ S m (1 − VM S M )
Equation 8.14 therefore imposes a second restriction on C m such that the final
capacity will be the minimum of Equation 8.11 and Equation 8.14. Note that
Equation 8.14 is identical to that represented by case (b) in Figure 8.10 where
GS M = 1. Thus Equation 8.14 only sets a lower capacity C m in case (a) in Figure
8.10 when GS M < 1 or G < 1 / S M . In other words the capacity restrictions due to
funnelling place a lower limit on the effective value of the gap for merging, G (i.e.,
GAPM) = 1 / S M .
If the critical gap is greater than 1 / S M or the merge is not considered to funnel
then no further capacity restrictions above and beyond Equation 8.11 are
considered.
8.8.4.3 Major Arm Capacity Reductions for Single-M Merges

A further consequence of a “minor” arm merging into a “major” arm, as illustrated
in Figure 8.8, is that the capacity of the major flow is reduced by the amount of
minor traffic that is permitted to enter; i.e., the capacity of A–B-C is reduced by the
flow on D-B-C. Physically this represents the limited space on the exit arm into
which both streams of traffic must “squeeze” or “funnel”.
More specifically, the capacity is removed from the lane on the major arm where
merging occurs, i.e., the inside lane for a “normal” near-side merge. The “post-
squeeze” capacity of the merging lane on the major arm C M is given by:
Equation 8.15
CM CM (1 − Vm S m )
=
where V m and S m are the (actual) flow and the saturation flow of the minor
merging turn and C M ’ is the “pre-squeeze” capacity of the major arm lane (subject
to the restriction that C M > CAPMIN).
Note that the actual minor-arm flow V m is restricted to be less than its capacity
calculated after gap acceptance and/or funnelling, i.e. Equation 8.11 and
Equation 8.14, which, in turn, depend on the flow on the major arm. Hence there
is a state of “equilibrium” between the two movements
In general this reduction in capacity should not be sufficient to convert the major
movement A-B-C from under capacity to over capacity on the basis that, if A-B-C
were near to capacity, then there would be relatively few gaps available to D-B-C
to enter and the traffic that would be allowed to enter would be less than V ABC –
V DBC . However, it may be possible with very small GAPM values for this to
happen.
Note that the reduction in capacity takes place whether or not APRES equals
zero.
5120257/ Apr 15 8-50

Section 8
8.8.4.4 Capacity Reductions at Y-Merges

The principles of “funnelling” described above for “single-M” merges are equally
applied to Y-merges where it applies to both arms. Thus, if the minimum gap
(GAPM) is very small (< 1/S) and total V/S ratio for the two exit flows after gap
acceptance has been applied initially exceed 1 then the capacities of both arms
need to be further restricted. There is, however, an added proviso that both arms
are “guaranteed” 50% sat flow capacities as per “shared” movements (see
equation (8.3)).
In addition the principles of allocating any “space” unused by one turn to the other
as applied for shared lanes (see 8.9.2) are also applied to Y-merges.
N.B. Versions 10.8 and beyond always apply the principles of funnelling to Y-
merges whether or not the parameter Funnel = T and/or clear exit priority
modifiers are used (see 8.8.4.5). The thinking is that “funnelling” (i.e., setting an
upper limit on the amount of traffic that enters a single exit lane at a Y-merge) is a
fundamental property of that configuration and that a “lateral” Y-merge is not a
good modelling concept.
Note that the new “rules” for Y-merges introduced in 10.8 and applied when M108
= T (see 8.8.4.5) produce different (possibly significantly different) results from
those prior to 10.8, although the general principles applied are broadly similar. It is
felt that the new rules are more realistic and are therefore recommended although
it is appreciated that users may wish to preserve the old results from well-
calibrated networks by setting M108 = F (i.e., not the default value).
8.8.4.5 Parameters to Control Merge Capacity Reductions: M108 and FUNNEL

The choice of whether or not capacity reductions due to funnelling are
incorporated into individual merges is governed by two &PARAM parameters:
M108 and FUNNEL, plus the use of the Priority Marker C.
Thus if M108 = F then the rules for (and interpretation of) merges are those
applied prior to the release of version 10.8. In particular this means that the
possible capacity restrictions described under 8.8.4.2 do not apply, i.e. the
“funnelling” effect of the exit lane is ignored. On the other hand the capacity
reductions to major arms at single-M merges and to both arms at Y-merges are
still applied as they were in 10.7.
If M108 = T and FUNNEL = F then the situation is also equivalent to that
described for M108 = F for single-M merges – no funnelling is applied. However, if
M108 = T and FUNNEL = T, then the capacity reductions under 8.8.4.2 apply
unless a Priority Modifier C has been used after a Priority Marker M to imply a
“clear exit”, i.e., no funnelling.
On the other hand, for Y-merges, as noted in 8.8.4.4 above, funnelling restrictions
are always applied independent of whether FUNNEL = T or F and/or whether a
priority marker C is used as long as M108 = T.
Finally, it should be pointed out that if GAPM is sufficiently large, i.e.,> 1/S M in all
possible cases, then none of the capacity restrictions mentioned above due to
funnelling affect the results and the values used for M108, FUNNEL and C-
modifiers are irrelevant.
5120257/ Apr 15 8-51

Section 8
In summary, capacity restrictions on a single-M exit arm only come into play when
M108 = T, FUNNEL = T, a C-modifier has not been used and GAPM < 1/S M .
8.9 Simulation Network Capacities

This section concentrates on the definition of capacities within the simulation
network for turns, links and nodes, with particular reference to how these are
affected by lane sharing. Note that these capacities are obtained as the
summations of ACCEPT profiles; therefore the application of, e.g., the capacity-
sharing rules for shared lanes is via the ACCEPT profiles.
We note that capacities may be defined in several different ways depending on
the circumstances for which they are being used. Section 8.9.1 considers the
most common and, hopefully, the most practical single definition; others follow,
e.g., in 8.9.3.
8.9.1 Definitions and Display

Capacities in the simulation network are defined at several different levels,
including:
♦ The capacity available to a particular turning movement in a particular lane,
♦ The total capacity of a lane,
♦ The total capacity for a turn,
♦ The total capacity for a river,
♦ The total capacity for a link, and
♦ The total capacity at a node.

Capacities at the lowest level of disaggregation can be displayed using the lane
distribution option in SATLOOK as illustrated in Tables 8.1a and 8.1b for link 68 to
18, taken from the standard test run. We first describe how these numbers are to
be interpreted before describing how, in general terms, they are calculated below
Table 8.1 - Lane distribution of stop line arrivals for traffic on link 68 to 18
Lanes
Turn To 1 2 Total
19 248 (241) 0 (-1) 248 (241)

45 130 (126) 459 (448) 589 574
Totals 378 (368) 459 (448) 837 (816)
V/C 1.03 1.03 1.03
Note: All flows in pcus per hour. Figures in brackets are capacities
Thus we see that lane 1 above is shared by two turns with a flow of 248 pcu/hr
turning to node 19 and 130 pcu/hr to node 45. Their respective capacities within
5120257/ Apr 15 8-52

Section 8
this lane are 241 and 126 pcu/hr. Lane 2 on the other hand is reserved for the
second turn only with a flow of 459 pcu/hr and a capacity of 448. The -1 under
lane 2 for the turn capacity into 19 indicates a banned movement from that lane.
A value of 0 would indicate an allowed movement but no capacity.
The numbers on the far right give the total flow and total capacity for each turning
movement. Those at the bottom give the total flows and capacities per lane.
Totals for the link as a whole are given lower right. V/C ratios are also given by
lane and in total.
Note that in this case the capacities per turn and per lane are additive but this is
solely due to the fact that the lanes are over-capacity and not a general rule. See
8.9.2.
Table 8.1 (b) - Comparison of turn capacities with lane sharing included vrs. turn
capacities with lane sharing excluded
Turn Capacity Ratio River River-based Capacities

Incl. Excl. Ex-Cap River QCAP Disp.
68 18 19 241 336 0.718 1 241.2 815.6 229.1 672.0
68 18 45 574 896 0.641 1 574.4 815.6 566.2 896.0
The second table illustrates how much capacity is lost through the presence of
other vehicles in shared lanes. Thus the column headed CAPACITY EXC gives
the capacity for each turn calculated as though there were no other movements
present on the link, while the CAPACITY INCL gives the actual capacity with such
effects included. Thus the presence of vehicles making turn 68-18-45 reduces the
capacity of turn 68-18-19 from 336 to 241 pcu/hr, a ratio of 0.718.
We return to the definition of a “river” (8.8.2) and the alternative river-based
definitions of capacities (8.9.3.4) below.
8.9.2 Shared Lanes and Capacities

Let us now consider how capacities such as those above are calculated in the
presence of lane sharing. If turns have exclusive lanes their capacity is assumed
to be equally shared between the permitted lanes (but see 8.8.3 for an exception)
and the problems of defining and calculating lane capacities do not arise; lane and
turn capacities are identical.
So let’s assume shared lanes.
We start at the most “disaggregate” level of turn capacities per shared lane. These
are calculated in two different ways, depending upon whether the lane is under
capacity or over capacity (as in Table 8.1).
UNDER-CAPACITY LANES
For under capacity lanes the rule is that each turning movement in that lane has a
capacity equal to its actual flow plus an additional capacity reflecting the spare
capacity in that lane.
5120257/ Apr 15 8-53

Section 8
The problem which emerges here is that the “spare capacity” may differ for
different turning movements if they have different saturation flow rates. If, for
example, we had a left and straight ahead movement in the same lane they might
have been assigned saturation capacities of 1200 and 1500 pcu/hr per lane. (The
saturation capacity of a lane for a given turn is assumed to be the user-input turn
saturation flow divided by the number of lanes; e.g., the ahead movement above
might have been coded with a capacity of 3000 pcu/hr and 2 lanes.) If the lane is
judged to carry, say, 400 lefts and 500 aheads (one third of their respective
saturation flows in both cases) then we assume that, in total, the lane is two thirds
full, and that the remaining one third capacity could accommodate either an
additional 400 lefts or 500 aheads. Hence their total capacities in that lane would
be 800 and 1,000 respectively.
To assign a total lane capacity we cannot simply add up the constituent turn
capacities since in the above case this would give us the unrealistic figure of
1,800 pcu/hr; we would be, in effect, counting the spare capacity twice. We
therefore define the lane capacity to equal the total flow plus a “weighted” average
of any spare capacity. In the above case the actual flow is 900 pcu/hr, the “spare”
capacity is one third of a weighted average of 1200 and 1500 pcu/hr, with the
weights determined by the relative flows. The weighted average saturation flow is
therefore:
(400/900) x 1200 + (500/900) x 1500 = 1367
giving therefore a total capacity of:
900 + 1367/3 = 1355.5
These capacity calculations are in fact carried out separately for each individual
time unit and summed, whereas the above example applied strictly speaking only
to the case of uniform flows over the time period simulated (i.e., “flat” profiles).
OVER-CAPACITY LANES
If however the lane is over capacity then the individual turn capacities are
proportional to their flows. Thus if one turn contributes 75% of the flow to an over-
capacity lane it is allocated 75% of its capacity for that lane. This implies that all
turns in a lane have equal V/C ratios.
In this case the total capacity for a lane is simply the sum of its individual turn
capacities per lane since the complication of spare capacity does not, by
definition, arise.
TOTAL CAPACITIES
The total capacity for a turn is the sum of its individual capacities in each lane,
while the total capacity of the link is the sum of its individual lane capacities
calculated as above. Therefore the total link capacity is not equal to the total of its
individual turn capacities, again because the latter sum may “double count” any
shared spare capacity.
Finally the total capacity at a node is obtained by summing up the link capacities
of its entry arms.
5120257/ Apr 15 8-54

Section 8
EXAMPLES
To further illustrate the principles involved Tables 8.2a and 8.2b show data for link
68 to 18 with the flows reduced by 50% so that the link is now under capacity.
Table 8.2 (a) - Lane distribution stop line arrival for traffic on link 68 to 18.
Lanes
Turn To 1 2 Total
19 120 (273) 0 (-1) 120 (273)
45 86 (292) 213 (448) 299 (740)
Totals 206 (375) 213 (448) 419 (823)
V/C 0.55 0.47 0.51
Note: All flows in pcus per hour. Figures in brackets are capacities
Table 8.2 (b) - Comparison of turn capacities with lane sharing included vrs. turn
capacities with lane sharing excluded
Turn Capacity Ratio River River-based Capacities

Incl. Excl. Ex-Cap River QCAP Disp.
68 18 19 273 336 0.811 1 217.9 823.4 272.6 672.0
68 18 45 740 896 0.826 1 605.4 823.4 740.0 896.0
We may note several differences from the previous results in Table 8.1:
1) While the turn to 45 still uses both lanes 1 and 2 the V/C ratios per lane are
not equal (although the measure of their stop line delays are; see 8.8.1)
2) The proportional split of turning traffic to turn 45 is split 459:130 = 78:22% in
the over-capacity case but 213:86 = 71:29% in the under-capacity case
implying that the lane choice is different in the two cases.
3) The lane capacity in lane 1 – 375 - is not the sum of the two turning
capacities due to the fact that the spare capacity has not been double
counted. Thus the spare capacity in lane 1 as seen by the turn to node 19 is
273 - 120 = 153, to node 45 it is 292 - 86 = 206 while combined it is 375 -
206 = 169. The differences per turn are explained by different saturation
flow across the stop line.
4) Note as before, however, that turn capacities are additive by lane; e.g. 740 =
292 + 448, as are the totals: 375 + 448 = 823.
The implications of comparing Tables 8.1b and 8.2b are discussed below.
8.9.3 Turn Capacities for Assignment Purposes

Yet further complications arise with the capacities C as used in the simulation-set
time-volume relationships (8.5) in the presence of shared and over-capacity lanes.
5120257/ Apr 15 8-55

Section 8
8.9.3.1 Queue Capacities

What is required in equation (8.5) is that the point of transition from “under
capacity” flow, (8.5a), to “over capacity” flow (8.5b) should occur at that flow for a
particular turning movement at which queues should start to form assuming that
all other turning movements in that link remain at their current level. Defining a
“queue capacity” in this manner can lead to different values than those defined
above and, in certain situations, as we shall demonstrate below, the “queue
capacity” may actually be zero.
Consider a lane with two movements 1 and 2 with saturation flows of 1800 and
1200 pcu/hr respectively and no further restrictions. If, case (i), V 1 = 900 and V 2 =
600 then the lane has a V/C ratio of 1.0 and the queue capacities would be 900
and 600. These equal the “normal” capacities as defined above.
If, case (ii), V 1 = 1200 and V 2 = 800 (i.e. both equal to 2/3 of their saturation flows)
then the combined V/C ratio would be 4/3 or 1.33. Hence the “normal” capacities
would be 50% of the saturation flows, again 900 and 600. (50% since both flows
have equal V/S ratios). However, if V 1 is fixed at 1200, 2/3 of S 1 , then queues
would form whenever V 2 exceeds 1/3 of S 2 ; hence the queued capacity of
movement 2 would be 400, and similarly that for movement 1 would be 600.
Finally, case (iii), consider the case where either movement on its own would be
over capacity; e.g. V 1 = 2000, V 2 = 1500. Here, the queue capacity, by definition,
would be zero for both movements. [If, say, V 1 = 2000 but V 2 = 600 then only
movement 2 would have zero queue capacity, not both.]
The example shown in Table 8.1 fits into case (ii) above where neither turn is over
capacity in lane 1 on its own but together they are. Hence the capacities listed
under QCAP are lower than the normal capacities. Note that this only arises from
the shared movements in lane 1; in lane 2, which has only one turn, the
contributions to QCAP and to the normal capacity are identical.
8.9.3.2 Queue Dispersion Capacities

A problem related to that of determining the flow (by lane by movement) at which
permanent queues start to form is the rate at which the queue disperses. In the
simple case of a single unshared movement if, say, the capacity is 1,000 pcu/hr
then if the arrival flow exceeds 1,000 then a permanent queue begins to form
which disperses at a rate of 1,000 pcu/hr from the stop line. With shared over-
capacity movements the rate at which the queue disperses is more complicated.
Thus it may be shown that the rate S d at which a shared queue disperses is given
by the weighted harmonic mean:
Equation 8.16
S d = 1/ ∑ Pi / Si
i
where P i is the proportion of turning movement i S i is the saturation flow of turn i

(or, strictly speaking, the “stop line saturation flow” which is defined to be the rate
at which vehicles cross the stop line equal to the “true” saturation flow, reduced
by, e.g., gap acceptance).
5120257/ Apr 15 8-56

Section 8
For example in all three cases given in 8.9.3.1 above the queue dispersion rate
would be 1500 pcu/hr (equal to the average of 1200 and 1800 but only by
coincidence, not a general rule) which exceeds any of the individual turn
capacities. Note equally that in tables 8.1b and 8.2b that the dispersion capacities
also exceed individual capacities.
Note that (8.10) refers to the full queue made up of all turning movements which
share; the rate at which individual movements disperse may differ.
8.9.3.3 “Modified” Assignment Cost-Flow Curves

The above considerations affect the way in which we must define assignment
cost-flow curves for each simulation turn in order to retain the fundamental
principle that the predicted delay for any specified flow for that turn must assume
that the flows for all other turns with which it shares are fixed. This requires that:
♦ the “transition point” C in equations (8.5a) and (8.5b) should be the queue
capacity;
♦ the C in the numerator of the second term in (8.5b) should also be the queue
capacity;
♦ the C in the denominator of the second term in (8.5b) should be a (turn-

specific) dispersion capacity.
Thus we re-write (8.5) by
Equation 8.17
t=
t0 + AV n V ≤ CQ
(a)
t0 AC + B (V − CQ ) / CD
t =+ n
Q V > CQ
(b)
where B as before is half the time period which is being modelled. The
parameters t o , A and n are again evaluated by the simulation. Figure 8.11
sketches the qualitative differences between the two sets of equations (assuming
queued conditions with the current flows). Note that the delay at the current flow
V is identical with both equations.
5120257/ Apr 15 8-57

Section 8
Figure 8.11 - The basic and modified cost-flow curves for over-capacity simulation
turns.
Note that since C Q may be zero in heavily loaded cases equation (8.11a) may
never apply and the minimum delay term t o will need to include both a transient
delay to vehicles once they reach the stop line plus a normal over-capacity delay
component in order to reach the stop line.
We may further note that equations (8.5) (assuming C = the “normal” turn
capacity) and 8.11 both go through the same point defined by the current turn flow
and simulated delay, the difference being that the modified curve has a lower
slope reflecting the fact that mathematically the dispersion capacity must be
greater than any individual turning capacity. This is illustrated in Figure 8.10.
Our definition of the assignment cost (or time) vrs flow curve does not therefore
have any impact on the simulation outputs (e.g. total vehicle hours) but is only
introduced in order to make the calculated delays in the assignment into better
predictors of what a subsequent simulation would produce. Their function is
therefore primarily to improve the convergence between assignment and
simulation sub-models. We should reach the same answers whether we use
equations (8.5) or (8.11) but (8.11) should get us there more quickly.
8.9.3.4 Life gets worse: Rivers

In fact life is even more complicated than that described in 8.9.3.3 which, strictly
speaking, is couched in terms of a single lane. The concept of a “river” has been
noted in 8.8.2 where a particular property of a river is that, if one turn which is a
member of a river is over capacity, then all turns in that river must be over
capacity and indeed they must have the same V/C ratio.
A consequence of this is that the dispersion capacity to be used in (8.11b) must
be calculated with reference to all flows and saturation flows within that river. This
further implies that the dispersion flow for each turn in a river may be different
5120257/ Apr 15 8-58

Section 8
(see tables 8.1b and 8.2b) since it depends on the number of lanes which they
use.
Note that the capacity of a river is simply the sum of the lane capacities of its
constituent lanes. Or, in the highly infrequent case of a river being created on a
capacity-restrained link (see the final sub-section within 8.8.2), then the river
capacity equals the mid-link capacity set by its speed-flow curve.
8.9.4 Simulation Link Capacity

The capacity of a link in the simulation network is defined in SATURN to be the
sum of its individual lane capacities which, as we have seen above, are not
determined purely by saturation flows and other geometric properties, but also by
the actual flows on that link. Thus, as explained in 8.9.2, any unused capacity on
a link is not double counted by turn but suitably averaged.
Note that it is possible for a link as a whole to have a V/C ratio less than 1
(indicating a lack of queue) but for individual turns on that link to have V/C > 1.
This arises if the spare capacity of one turn is unavailable to another (and may be
indicative of poor engineering design).
Similar considerations apply to total node capacities where the node as a whole
may have less flow than capacity but individual links and/or turns may be over-
capacity.
8.9.5 Capacity DA Codes in .UFS Files

We list here the codes for those DA arrays in .ufs network files which refer to
capacities and explain their differences. Section 17.10 performs a similar function
for time-based arrays.
1393 Capacity for entry flows from simulation centroid connectors to the
upstream end of simulation links (see 15.16) N.B. Only relevant if
blocking back on a link extends to entering flows from a zone (see
8.5, note (b))
1473 Simulation link capacities as per 8.9.4.
1643 Simulation turn capacities as per 8.9.1 and tables 8.1a and 8.2a.
1833 Capacity of an assignment link as used in the cost-flow curves; thus,

for simulation turns, C Q as defined by 8.9.3.3.
1843 The “reverse capacity” of an assignment link; thus, for simulation

turns, 1/C D as defined in equation (8.11b).
1863 The “practical capacity” of an assignment link: for simulation links and
turns identical to 1473 and 1643 and thus as defined in 8.9.1; for
buffer links it is the “normal” capacity.
5120257/ Apr 15 8-59

Section 8
8.10 SATSIM: Technical Specifications
8.10.1 SATSIM Files
Channel Remarks
Number
1 An input UFA file from SATEASY (Mandatory)
2 An output UFS file containing new flow-delay relationships to

be passed to SATEASY. (Mandatory)
5 An input “DAT” file containing the control parameters as

described in 8.9.2 below; (Mandatory)
6 An output LPS line printer file. (Mandatory)
15/14 Terminal (output only) (Optional - MODET ne 0)
8.10.2 SATSIM Control Data Input
RECORD 1 - NAMELIST PARAMETERS (&PARAM) (MANDATORY)

The parameters which may be defined here constitute a sub-set of those
described in Section 6.3, more precisely those which are relevant to runs of
SATSIM, viz:
LOGICAL: EXPERT, LCR108, PRSFD, QUEEN, RAGS, RB106 and

ROSIE
REAL: AFTERS, ALEX, APRESV, CAPMIN, TAX and TDEL
INTEGER: ISTOP, LRTP, MASL, MAXDTP, MAXQCT, MODET, NITS,

NITS_M, NOPD and NOTUK
with default values taken from the input UFA file, plus a single additional logical
parameter TITLE, default value FALSE, such that if TITLE is TRUE record 2 - see
below - is to be input.
Alternatively the network title may be redefined by an alphanumeric namelist
parameter of the form:
TITLE = ‘new title’
RECORD 2: NETWORK TITLE (OPTIONAL - TITLE = T)

This record contains a descriptive network title starting in Col. 1.
End of Input.
5120257/ Apr 15 8-60

Section 8
In order to run SATSIM as part of the normal iterative sequence shown in Figure
3.1a a “dummy file” SATSIM0.DAT is required, the “standard” version of which is
as follows:
&PARAM
&END
5120257/ Apr 15 8-61

Section 8
5120257/ Apr 15 8-62

Section 8
Assignment / Simulation Loops – The Role of SATALL
9. Assignment / Simulation Loops – The Role of

SATALL
INTRODUCTION
This section describes the general principles which underpin the assignment-
simulation loop which is necessary for networks with a simulation component. It
covers both the use of separate programs (the original method) plus the use of the
single program SATALL (the strongly recommended technique).
9.1 General Principles
9.1.1 Assignment-Simulation Loops

The iterative loops between simulation and assignment have already been noted
in Section 3.1 and are illustrated again in Figure 9.1 below. Thus the assignment
sub-stage supplies the link flows which are needed by the simulation which in turn
supplies the flow-delay curves for simulated turning movements which the
assignment requires.
This loop may exist either as a loop between two distinct programs SATEASY and
SATSIM or, in versions of SATURN from 9.1 onwards, within a single combined
program SATALL. In both cases the basic principles are the same although, in
certain respects, there is greater potential for flexibility within the one program
SATALL. The use of SATALL is now virtually universal.
Figure 9.1 - The Simulation-Assignment Loop
9.1.2 Why Loops are Necessary

The reason why the loops are necessary is essentially due to the fact that the
turn-based flow-delay curves used by the assignment are only approximations in
that they ignore the “interactions” between links in the determination of delays. To
5120257 / Apr 15 9-1
Section 9
illustrate a very simple case, consider a T-junction with one minor (give-way) arm
and one major arm. Here the delay on the minor arm will depend both on the flow
along the minor arm as well as the flow on the major arm (and indeed the latter
effect will probably dominate). However the flow-delay relationship set by
simulation only includes the effect of the minor arm flow - the implicit assumption
is that the major flow is fixed throughout the assignment. If the flow does remain
constant on two successive assignments then the assumption is correct; if it does
not then the routes generated by the assignment are, to a greater or lesser extent,
inconsistent with the simulated delays.
There are a considerable number of other sources of “interaction” between links,
for example, shared lanes, blocking back, signal optimisation and co-ordination,
merging and weaving, etc. etc. These interactions may be highly asymmetric and
sometimes much stronger than the “intra-link” effects which means that, from a
theoretical point of view, the ultimate convergence of the process has very few
mathematical guarantees.
In order to deal with the interactions SATURN loops between assignment and
simulation until (reasonably) steady flows are obtained, at which point the model is
judged to be “self-consistent” or “in equilibrium”; i.e., the flows that go into the
simulation produce delays which in turn produces the same flows on assignment.
(Technically this approach is known as the “diagonalisation method”).
The (main) parameter used to monitor the rate of convergence is the percentage
of link flows which vary by less than, say, 5% (the parameter PCNEAR) between
loop n and loop n-1. If this exceeds the (integer) parameter ISTOP then the
process is judged to have converged satisfactorily. If the criteria are satisfied on
NISTOP successive loops then the process is terminated (where, from release
11.3 in March 2014, the default has been upgraded from 1 to 4 in order to conform
with DfT advice).
Note that with release 11.1 the critical integer value ISTOP has been converted
into an equivalent real value RSTOP such that the actual stopping tests use
RSTOP, not ISTOP; see 9.2.6.
In addition a number of alternative convergence criteria (e.g., the “gap” parameter)
have been introduced at a later stage of SATURN development and these are
described further in section 9.2.3.
Alternatively the procedure will always terminate if a maximum number of loops
(the parameter MASL) has been reached.
Whether or not convergence will be achieved by this method is hard to determine
in advance. Essentially the process works well when the “interaction” effects
referred to above are relatively weak, but when they are strong problems of
oscillations can occur. For example, networks with a large number of give-ways
may create problems. See 9.5.
Clearly good convergence is highly desirable; poor convergence means that the
results are imprecise / “in error”. A more precise description of the statistics used
to monitor convergence is given in 9.2 and advice on how to achieve good
convergence (or, conversely, how to avoid poor convergence) is given in 9.5. On
the other hand, poor convergence is not the only source of error in the model
outputs (cf. data input errors, section 2.1) and good convergence generally
5120257 / Apr 15 9-2
Section 9
requires longer run times so that, in practice, the target level of convergence will
represent a compromise between accuracy and run times.
9.1.3 SATALL: General Features

The program SATALL, first introduced with SATURN 9.1, in effect combines the
programs SATASS/SATEASY and SATSIM into a single program and carries out
a full assignment/simulation convergence loop internally. Thus, as shown in
Figure 3.1, taking as input a .ufn network file built by SATNET, it both assigns and
simulates so as to produce an output .ufs file containing converged assigned flows
plus the corresponding simulated delays.
It may also carry out additional post-loop calculations and produce additional files,
in particular an extra final (SAVEIT) assignment in order to facilitate future
analyses of the assigned path flows; see 15.23.2
In addition to the final flows, travel times etc., the output .ufs files also contain a
wide range of convergence plus selected aggregate statistics from each individual
assignment/simulation loop which may accessed via SATLOOK and/or P1X. The
aggregate statistics from several loops may also be averaged; see 17.9.2.
By combining two programs into one SATALL should be both faster and,
ultimately, “more clever” in terms of the steps that can be introduced in order to
improve the rates of convergence. For example it can combine the DIDDLE
option with elastic assignment which is otherwise impossible; see 9.10. All the
various distinct options for assignment and/or simulation that can be invoked with
the separate programs SATEASY and SATSIM may now be carried out within
SATALL. Indeed, as with the elastic DIDDLE (what a great name!) mentioned
above, there are extra options only available with SATALL; see 9.12.
9.1.4 Assignment-Simulation Control Procedures

The traditional ‘control procedure’ to automatically run the loops between the
distinct assignment and simulation programs, SATURN8, is described in Section
14.3. The equivalent and current standard procedure, SATURN, which runs
SATALL is described in Section 9.14.
9.2 Monitoring Convergence

The rate of convergence of the assignment/simulation loops can best be
monitored using 2 tables of convergence statistics which are (a) included within
the .lpt files but (b) may also be viewed interactively using either option 8 of
SATLOOK or under P1X Information and/or Convergence Options.
9.2.1 Table 1 Convergence Statistics by Sub-Module and Loops

The contents of Table 1 may vary depending on the precise assignment algorithm
being applied. In the case of standard Wardrop Equilibrium the output plus
interpretation is as given below:
♦ Assignment - Delta Function (%) / Number of iterations
♦ Simulation - Final Average Absolute Change in OUT CFP (PCU/HR) / Number

of Iterations
5120257 / Apr 15 9-3

Section 9
♦ A/S Step - Step length used per loop / Simulation repetitions
♦ Assignment/ Simulation Loop - % Link flows differing by < 1% between

successive assignments
♦ Assignment/Simulation Loop - % Turn delays differing by < 1% between the

assignment and subsequent simulation
♦ Variational Inequality % - should be > 0
♦ Wardrop Equilibrium % Gap Function

N Assignment Simulation % Flows % Delays % V.I. % GAP
1 0.109/9 0.008/5 51.3 16.488
2 0.356/9 0.672/5 71.0 79.0 0.002 5.798
3 0.229/9 0.522/5 72.9 86.6 -0.001 0.222
4 0.351/9 0.379/5 92.8 87.4 0.000 0.332
5 0.399/9 0.305/5 93.5 93.3 0.000 0.230
6 0.327/9 0.508/5 96.9 94.1 0.000 16.488
7 0.300/6 0.522/5 60.4 95.0 0.045 5.798
Thus column 1 monitors the “delta function” which is internal to the assignment
and measures the degree to which the routes assigned traffic are minimum cost
routes; see section 7.1.4 If, as a rule of thumb, these figures are much in excess
of 1% then you should consider increasing the parameter NITA to obtain better
internal convergence. Otherwise the “uncertainty” in each assignment may be
adversely affecting the overall convergence. (For an alternative point of view see
9.5.4.)
See 7.1.4 for more information on delta.
Similarly column 2 monitors the successive internal convergence of each
simulation using the parametric measure discussed in 8.3. Again, as a rule of
thumb, if these figures are much in excess of 1.0 you should consider increasing
NITS.
Columns 1 and 2 also give the numbers of assignment and simulation internal
iterations undertaken (for which NITA and NITS set upper limits).
Column 3 reports the factor used to average successive assignment flows
between loops under KOMBI or AUTOK (see 9.3) and, in the case of AUTOK, the
number of internal repetitions of the simulation in order to calculate the optimum
weights (9.3.2).
The remaining 4 columns all monitor the convergence of the
assignment/simulation loops and should, roughly speaking, tell a similar story.
Firstly “% FLOWS” reports the fraction of assignment links whose assigned flows
changes by less than 5% (or, strictly speaking, less than PCNEAR%) from one
simulation-assignment loop to the next. This is a somewhat arbitrary function but
one which has been used in SATURN from the beginning and has thereby
5120257 / Apr 15 9-4
Section 9
acquired a certain historical momentum. It is (by default, see 9.2.3) the “main”
convergence parameter in that it is used to stop the loops once the figure exceeds
the parameter ISTOP (or RSTOP; see 9.2.6); typical values for ISTOP are 90,
95% or 98% (the current default value since release 11.3). ISTOP and/or RSTOP
are set in &PARAM; see 6.3.2. See also 9.2.3 for alternative stopping criteria.
(N.B. If both the flows being compared are less than 1.0 pcus/hr then the fit is
considered to be “OK”; i.e., the percentage difference is ignored for very low
flows.)
“% DELAYS” is similar to “% FLOWS” but is based on the fraction of simulation
turns whose delays change by less than 1% (i.e. PCNEAR%) from those
calculated by the previous assignment. Note that the simulation turns are a sub-
set of the assignment links; hence the latter measure is based on a different - and
larger - “sample” than the former. % DELAYS has no effect on stopping the loops.
These two measures, while generally similar, can present different viewpoints
under certain circumstances. Thus in highly congested networks, where delays
are a very sensitive function of flows, it is quite possible for the flows to settle
down (high %FLOWS) but for the delays to fluctuate wildly (low %DELAYS).
Alternatively if the delay-flow relationship is very “flat” it is possible that the delays
will be stable (high %DELAYS) but for the flows to wander (low %FLOWS). Thus if
only 1 of these measures is high it probably implies that your overall convergence
is acceptable even though either flow or delay is uncertain.
“% V.I” is more complicated to explain. In essence it compares the costs on the
currently assigned routes using the current simulated delays to the costs on the
previously assigned routes using the same delays. One should therefore expect
the current routes to be “cheaper” if we are getting nearer to Wardrop equilibrium;
if %VI is positive this is true, if negative, then the former routes are actually
cheaper than the current routes. This situation arises if the flow pattern has
changed too drastically from one loop to the next - one solution is to use the
KOMBI or AUTOK parameters to “dampen down” the changes in flow. Thus if
%VI goes strongly negative on, say, loop 6 then that is a strong argument for
setting KOMBI to 6. We return to this question in Section 9.3 below.
Finally the “% GAP” is a generalisation of the delta function - column 1 - to include
the interaction effects within the simulation. It is, firstly, the difference between the
current total vehicle costs on the assigned routes and the total vehicle costs if all
drivers were to use minimum cost routes with the costs FIXED. This measure is
then “normalised” by dividing by the total vehicle costs and expressing it as a %.
It is therefore the same as equation (7.3) for delta (Section 7.1.4) except that the
costs are calculated after the simulation rather than after the assignment.
Generally speaking the GAP values will be greater than the DELTA values since
the routes chosen based on the assignment cost estimates will tend to be slightly
worse when the costs are further changed by the simulation. The difference
between GAP and DELTA is therefore an indication as to how far the assignment
and simulation stages “disagree” on the calculation of delays; for further statistics
on the level of disagreement and the turning movements which may be causing it
please see Section 9.9.1.
5120257 / Apr 15 9-5

Section 9
As with delta (7.1.4) a gap of under 1% may be regarded – at least for some
purposes – as satisfactory. For example it is much better than the ability of
drivers in real life to choose “true” minimum cost routes which may be categorised
as around 5%. However, for other modelling purposes, significantly lower GAP
values need to be achieved and, indeed, should be achieved. A GAP value of
under 0.1% or even 0.01% should be regarded as a suitable target. See 9.2.4 for
a more complete discussion and 9.5 for advice on improving convergence.
Note that the latter two measures assume that the assignment is trying to assign
all trips to minimum cost routes. As this is not true under stochastic assignment %
VI and % GAP are not reported there.
9.2.2 Table 2
The second table contains a set of extra convergence statistics relating to the
progress of the assignment-simulation loops:
ASS-HRS The total time pcu-hr/hr from the buffer + simulation networks
calculated by the assignment (N.B. Time here is “true” time, not
generalised cost expressed in time units. It equals the product of
total demand flow multiplied by average travel times summed
over all assignment links. Since it uses demand flows it includes
both pcu-hrs within the current simulation time period and in
future time periods.)
CHANGE % Change in ASS-HRS between successive loops
SIM-HRS Total time pcu-hr/hr from the simulation network only and from
within the simulated time period only (i.e., travel time in future
time periods due to queued traffic is excluded.)
SIM-KMS Total pcu-km/hr from the simulation network only (this time
period only)
GEHBAR Mean GEH Statistic comparing link demand flows between two
successive assignments
AAD Average Absolute Difference in link demand flows between two
successive assignments (PCU/HR)
RAAD % Relative Average Absolute Difference in Link flows
XMSD % Relative Standard Deviation in link flows
SAD Mean Absolute difference in delays between the assignment and
simulation (seconds)
RSAD % Relative Mean Absolute Difference in ASS/SIM delays
Certain of the above measures are those recommended by the DfT for monitoring
the degree of convergence of any ‘congested assignment model’ as set out in
section 3.3 of TAG Unit M3.1.
Please note that the measures included in Table 2 are essentially arbitrarily
selected from a very large number of potential convergence statistics. For
5120257 / Apr 15 9-6

Section 9
example, we report on SIM-HRS within the simulated time period as opposed to

including time within the “next” time period due to queued traffic.
9.2.3 Terminating the Loops: Alternative Convergence Criteria

The simulation-assignment loops terminate under the following conditions:
1) The number of loops exceeds MASL;
Or
2) The number of loops does not exceed MASL and;
a) %FLOWS exceeds ISTOP / RSTOP on NISTOP successive loops,
b) GAP is less than STPGAP on NISTOP successive loops.
c) The total CPU time exceeds STPCPU,
d) Various and/or combinations of the above 3 criteria.
3) A minimum number of loops, MASL_M, is satisfied (added in 11.1).
The choice between which of conditions 2 is applied is set by the parameter
KONSTP which may (post release 11.1) lie in the range 0 to 6. All five control
parameters KONSTP, ISTOP/RSTOP, NISTOP, STPGAP and STPCPU are set
under &PARAM in SATNET (or SATALL) and default to 0, 98/97.5, 4, 1.0 and
1000.0 respectively.
The allowed values of KONSTP have the following interpretation:
0 – ISTOP/RSTOP only is required
1 – GAP only is required
2 – Total CPU time is used as the sole stopping criterion.
3 – ISTOP/RSTOP with an upper limit on the total CPU time
4 – GAP with an upper limit on the total CPU time
5 – Both GAP and ISTOP/RSTOP must be satisfied (independent of CPU)
6 – Either GAP or ISTOP/RSTOP must be satisfied
Note that tests based on GAP are not always available, depending on the exact
form of assignment algorithm used. Thus GAP is not calculated under Stochastic
Assignment or Multiple User Class Elastic Assignment.
Historically SATURN used %FLOWS as its stopping criteria (in addition to MASL)
– so that KONSTP = 0 - although it is a fairly simplistic measure with very little
theoretical pedigree. For example, having a fixed cut-off between “OK” and “not
OK” means that it fails to distinguish links that fail marginally and links that fail by
a large amount. Essentially it was introduced at a very early stage of program
development when a rule was needed and it just hung about until it was so deeply
entrenched it was difficult to get rid of! On the other hand, in its favour, it is easy to
5120257 / Apr 15 9-7

Section 9
calculate and understand and works in all possible situations, not just Wardrop-
based models.
A further problem with the use of %FLOWS as the stopping criterion is that it may
depend on the “accuracy” of the assignment method used. Thus if one uses an
extremely accurate assignment such as OBA (see Section 21) the true difference
in link flows between loops n-1 and n will be obtained (to a good approximation)
whereas with a less accurate technique, such as the default Frank-Wolfe
algorithm, there is less scope for the assignment in loop n to move away from the
assignment in loop n-1 (which is used as its starting point, assuming of course
that DIDDLE = T as it should be); hence the differences in link flows tend to be
reduced and %FLOWS measure increased. Hence, despite being a better
assignment method with better convergence properties, OBA may perversely
appear less convergent than Frank-Wolfe in terms of %FLOWS.
On the other hand, GAP does have a definite theoretical interpretation, does
differentially weight “good” and “bad” fits and is easy to compare between
networks of wildly different shapes and sizes. It is also more “neutral” with respect
to the problem of assignment accuracy discussed above.
On balance, therefore, our current “best buy” for a stopping criterion is the GAP
(set KONSTP = 1 or 4) although we recognise that there is a strong case for
carrying on with %FLOWS for historical continuity and the default, since release
11.3, is both %FLOWS and GAP (KONSTP = 5) in order to conform with DfT
recommendations (see TAG Unit M3.1, Table 4).
However, whichever stopping criterion users choose, they should always view
GAP as their most important single indicator of overall convergence.
N.B. If STPGAP is used as the stopping criterion for assignment-simulation loops
then it is also recommended that the parameter UNCRTS which sets (one of) the
stopping criteria for the assignment stage on its own should be less than
STPGAP, otherwise the overall convergence will be restricted by the assignment
convergence. Alternatively setting AUTONA = T (see 9.5.4) allows the program
itself to correct for too high values of UNCRTS during each assignment loop.
9.2.4 Convergence Criteria: What is “Good Enough”?

We consider here the question of what sort of values are “acceptable” for the
various stopping criteria used not only in the assignment-simulation loops (ISTOP
etc.) but also in the assignment and simulation sub-stages themselves.
Such questions are intimately connected with the purposes for which the model is
being run. For example, if you wish to do a very broad-brush “quick and dirty”
estimate of what traffic conditions may look like in 20 years time the results will, of
necessity, be very inexact and there is no point in imposing very strict
convergence criteria. On the other hand calibrating a present-day network where
you have extremely good data may justify very strict criteria.
One particular case where very good convergence – and therefore very strict
criteria – is absolutely required is the comparison of “with” and “without” scheme
networks where the differences are likely to be relatively small and can only be
accurately measured if both sets of results are extremely accurate. Otherwise the
differences will simply get lost in the “noise”.
5120257 / Apr 15 9-8
Section 9
It can be argued that, as a very general rule of thumb, the reduction in total
vehicle-costs due to the “scheme” should be ten times larger than the “noise” in
the model (as outlined in TAG Unit M2 Variable Demand Modelling, Section 6.3).
This implies that if a scheme reduces total travel cost by, say, 1%, then you
require a GAP value of 0.1% or better to achieve a satisfactory evaluation.
It might also be argued that there is no such thing as a “minimum
acceptable” level of convergence and that modellers should always try to
reduce GAP values to the absolute minimum values which are technically
possible, limited only by practical considerations of time and/or money.
Section 9.5.3 gives general advice as to how to achieve “extremely good”
convergence.
9.2.5 Guidance on Convergence

9.2.5.1 TAG Unit M3.1
The current guidance from the Department for Transport is provided in its
Transport Appraisal Guidance (TAG) Unit M3.1 (formally TAG Unit 3.19) and
recommends that a more stringent set of standards should be used than
previously advised. The guidance notes that different levels of convergence may
be required through the course of the study. For example, a more relaxed
convergence level may be appropriate to ensure sufficient number of loops of
matrix estimation may be practically undertaken whilst more stringent criteria
would be applicable for economic appraisal.
Type Convergence Measure Suggested Values
Less than 1% or at least stable with

Proximity Delta (or %GAP for SATURN) convergence fully documented and
all other criteria met
Percentage of links with flow Four consecutive iterations (SATALL
change (P1) < 1% loops) greater than 98%
Percentage of links with cost Four consecutive iterations (SATALL

Stability
change (P2) < 1% loops) greater than 98%
Percentage change in total user Four consecutive iterations (SATALL
costs (V) loops) less than 0.1% (SUE only)
Source: TAG Unit 3.19, Table 4
Thus, in the above table, “four consecutive iterations” implies NISTOP = 4,

“greater than 98%” implies ISTOP = 98 / RSTOP = 98.0 and PCNEAR = 1% as
recommended values.
In all circumstances, the onus remains on the SATURN user to ensure that
their assignment is converged to an appropriate level.
9.2.6 ISTOP vrs RSTOP

In release 11.1 an alternative form of the ISTOP stopping criteria, RSTOP, has
been introduced. Basically RSTOP performs the same function as ISTOP, the one
difference being that ISTOP may take only integer values whereas RSTOP may
take real values (e.g., 96.7 vrs 96 or 97).
5120257 / Apr 15 9-9

Section 9
In effect ISTOP has always been treated as a real variable rounded down from its
integer value; e.g., ISTOP = 97 was effectively 96.5. The reason for this was that if
the percentage of OK links had been 96.6 then, when it was compared to ISTOP,
it would be rounded up to the nearest integer, i.e., 97%, and compared to the
integer value ISTOP, e.g., it would satisfy ISTOP = 97. Equally 96.4 would be
rounded down to 96% and would not pass ISTOP = 97. Hence the effective critical
value would be 96.5 in “real” terms. So whether we round ISTOP down to a half-
integer value to be compared with the exact (real) OK value, or round the OK
value to the nearest integer, the end effect is the same.
Thus in Version 11.1 the comparison is always done using real values where the
critical stopping criteria RSTOP may either be defined directly by including a
variable RSTOP under &PARAM or, if RSTOP is not explicitly set, then RSTOP =
ISTOP – 0.5.
Note that this should have no impact on re-running old networks if RSTOP is not
defined since the stopping criteria is effectively unchanged.
9.3 Averaging Flows: The Use of KOMBI and AUTOK

Clearly non-convergent flows are undesirable. One way of trying to deal with the
problem is to average the assigned flows over successive loops. Thus if after n
assignment-simulation loops the link flows are V a (n) and we carry out a further
assignment (using whatever assignment method -- Wardrop, Stochastic, etc) to
obtain flows F a (n+1) then we take a strict 50:50 average of the two flows to obtain:
Equation 9.1
=
Va
( )
n +1
(F( a
n +1)
+ Va(
n)
)/2
or (post-SATURN 10.4) a Λ-weighted average :
Equation 9.2
Va( n +1) (1 − Λ ) Va( n ) + ΛFa( n +1)
The first method is associated with the KOMBI parameter and the second with
AUTOK as explained below. If neither is used then:
Equation 9.3
Va( n +1) = Fa( n +1)
Empirically such methods appear to improve the convergence of “badly behaved”

networks, in effect by damping down flows which otherwise may oscillate wildly
over successive loops. On the other hand the averaging may actually slow down
convergence for “well behaved” networks.
9.3.1 Use of KOMBI

The loop at which 50:50 averaging first occurs is set by the parameter KOMBI;
thus setting KOMBI = 3 allows 3 assignments with the “normal” method before
averaging is introduced. If, of course, convergence (relative to ISTOP) is
achieved within KOMBI loops then no averaging takes place.
5120257 / Apr 15 9-10

Section 9
Provided that convergence does occur naturally then there are strong reasons for
not invoking KOMBI (see below). Our advice to users is to first test networks with
KOMBI = 99 (or 0, the effect is the same) and if convergence is seen to be
proceeding happily enough (see 9.2) then leave well enough alone. If however
the flow-convergence is seen to decrease, say, after loop 5 then consider setting
KOMBI to 5.
Alternatively use AUTOK which should be an improvement!
9.3.2 Use of AUTOK

The AUTOK facility (AUTOmatic Kombi) was first added in SATURN 10.4 as a
method for automatically determining (a) at which point averaging should be
introduced and (b) the appropriate Λ-weights so that the user would not need to
make such decisions as to appropriate values of KOMBI via a process of trial and
error. Its theory is very similar to that used under the ROSIE option, 7.1.3.
Thus if AUTOK = T (the default is F) then after each assignment a full simulation
is carried out using the latest assigned flows (i.e., without any averaging), at which
point a test is carried out on %Φ (as described qualitatively in 9.2.1 and defined
more precisely below, equation (9.5)) to test whether averaging would improve
convergence. If %Φ is positive then no further action is taken; if, however, %Φ is
(significantly) negative then the flows are averaged as per equation (9.2) with an
“optimum” value of Λ.
The criterion on which the optimum value of Λ is derived from the same optimising
rule as applied within the Frank-Wolfe algorithm for networks with “separable”
cost-flow curves; see 7.1.3. This in turn is based on a 1987 paper by one Dirck
Van Vliet (“The Frank-Wolfe Algorithm for Equilibrium traffic Assignment Viewed
as a Variational Inequality”, Transportation Research 21B, 87-89) which in turn
was based on “Viewing Wardrop Equilibrium as a Variational Inequality” (Smith,
1979). Thus the Frank-Wolfe rule for combining the current assigned flows V a with
the latest all-or-nothing assigned flows F a may be written as the solution to:
Equation 9.4
∑ c ( λ ){V
a a − Fa } =
0
where c a (λ) represent the link costs with the flows averaged as per equation (7.2).
We may think of the (negative) costs as representing a “Social Force Field” which
is pushing the current solution V a in the direction of the cheaper routes
represented by F a . The solution (9.4) represents the point at which the social force
field has shifted such that the all-or-nothing routes are no longer the cheapest
routes (because they have been allocated extra traffic and the original routes less)
and the force field is now at right angles (“normal”) to the direction of flow change.
The equivalent rule when applied to two successive sets of fully assigned flows
from assignments n and n+1 would be to require that:
Equation 9.5
∑ c ( Λ ) {V ( ) − F ( ) } =Φ ( Λ ) =0
a a
n
a
n +1
5120257 / Apr 15 9-11

Section 9
where now the costs c a (Λ) are those derived from simulation n+1 based on Λ-
averaged flows. Again we may think of the costs as a force field pushing the
solution from V a (n) towards F a (n+1) and that the simulation is changing the direction
of the force field by calculating different costs.
If, as mentioned above, Φ(1) > 0 then a step-size of 1 is used and no averaging
takes place. N.B. This is the most frequent result; see below. Alternatively, if Φ (1)
< 0, then equation (9.5) is solved by a heuristic method of successive
interpolations.
Thus we first calculate Φ(0); this may be done, in fact, immediately after
simulation n where the simulated costs are, in effect, c a (0). In theory Φ(0) > 0
(although it is possible that lack of assignment convergence and/or rounding
errors might drive it marginally positive) so that our first estimate of the optimum
Λ 1 is simply based on a linear interpolation between Φ(0) and Φ(1):
Equation 9.6
Λ1 = Φ ( 0 ) / ( Φ ( 0 ) − Φ (1) )
and we carry out another simulation with weighted flows and obtain the “correct”
value for Φ(Λ 1 ).
If Φ(Λ 1 ) is zero, or very near zero, then we terminate. If, however, Φ(Λ 1 ) is
significantly different from zero we may estimate an improved value Λ 2 by
approximating Φ(Λ) as a quadratic function using the three points we have already
simulated at Λ = 0, Λ 1 and 1. If, having carried out a further simulation with Λ =
Λ 2 , Φ(Λ 2 ) is not sufficiently near zero then the process of quadratic
approximations and re-simulation continues using the last three estimated points
until the zero-point is obtained with sufficient accuracy. Empirically it would appear
that the solution is obtained “most of the time” with a simple linear interpolation or
a small number of quadratic steps.
9.3.2.1 Accelerated Factoring of Λ
If an optimum value of Λ is not obtained after, say, 2 or 3 iterations and the same
behavior is noted consistently over several assignment-simulation loops then it
may be possible to “accelerate” the estimation of Λ by introducing an additional
empirical factor based on the ratio of the final Λ value to the initial linear
interpolation given by equation 9.6. Thus if we consistently observe that the final
value is 0.5 times the initial value then it may well save time (by reducing the
number of repeated simulation steps) if on the next application of AUTOK we
reduce the initial estimate by a factor of somewhere between 0.5 and 1.0.
This factor is referred to as the “AUTOK AVERAGE STEPS FACTOR” in the .LPT
output files and is not a constant but varies throughout based on the most recent
experiences.
This “fix” was first introduced in 10.9.17 and has been found to marginally reduce
the number of repeated simulations and therefore reduce CPU time.
5120257 / Apr 15 9-12

Section 9
9.3.2.2 The Role of Λ: The Use of AK_MIN

Post 10.9 a minimum value may be imposed on Λ by setting a Namelist &PARAM
parameter AK_MIN in the network .dat file with a default value of 0.0 (which
means it will never be applied). The rationale behind setting a minimum value of Λ
is that a value near zero implies that we virtually retain the previous flows and are
therefore making very little progress towards convergence, due, most likely, to
some sort of “quirk” in the simulation. A small value of AK_MIN may therefore
provide a little “impetus” for the model to converge. A value of 0.10 has been
found to be appropriate in one particular network which was frequently generating
values of (virtually) 0.0 but little comprehensive empirical testing has been done.
It should, however be noted that, again empirically, that in many networks
averaging is never required and that in the remaining networks averaging is only
required on a small fraction of the loops. Whether or not averaging is needed is
essentially down to how much “interaction between links” is being introduced by
the simulation as described in 9.1. If it is very strong then averaging may be
necessary to “dampen it down”.
Somewhat perversely it also appears empirically that averaging is required more
often if the assignments are extremely well converged internally, e.g., if you are
using OBA assignment or PARTAN. This may be interpreted as being due to a
poorly converged assignment not taking you very far from the current solution and
therefore not as far as the “correct” solution. However a more accurate
assignment may actually cause you to “overshoot” the correct solution, in which
case the averaging is effectively bringing you back towards the previous solution.
Information on the Λ-weights used to average assigned flows and the number of
internal loops used to calculate those weights on each loop are displayed within
the standard table of assignment-simulation convergence statistics (see 9.2.1) as
printed within the .lpt files or as displayed by request by P1X or SATLOOK.
9.3.3 Possible Problems with KOMBI or AUTOK

One minor reason for NOT using KOMBI is that, if you are using link-based
assignment (the default), any SAVEIT-based analysis of the route pattern AFTER
the end of the loops, for example a PIJA analysis, printing a forest or cordoning a
trip matrix, becomes approximate although, see 15.23, it should be a very good
approximation. However if using KOMBI is the price that has to be paid for
achieving good convergence then it is a price well worth paying - the problems
introduced by an approximate “SAVEIT” are relatively minor.
The same problem does not arise with AUTOK as long as averaging was not
applied on the final assignment - simulation loop.
However this objection does not apply if you are using either path-based or origin-
based assignment where the path information is preserved exactly.
9.4 Continuing a Previous Assignment (The DIDDLE Option)

As mentioned in 7.1.2 the Frank-Wolfe algorithm normally starts with an all-or-
nothing assignment based on free-flow link costs. However an alternative
starting point is to use the final assigned flows from the previous assignment (on
loops after the first). This has the advantage that the previous flows are likely to
5120257 / Apr 15 9-13
Section 9
be “nearer” to the desired flows on this assignment loops than is an all-or-nothing

solution so that starting with them should reduce the number of internal iterations
required and/or lead to a more accurate solution. This option is selected by
setting the parameter DIDDLE to .TRUE.
DIDDLE is a relatively new SATURN option but it has proved to be highly effective
both in terms of reducing the number of internal assignment iterations and
improving the assignment/simulation convergence loops. With version 9.3 (and
later) DIDDLE also works with elastic assignment when the loops are within
SATALL (but not with SATEASY). It will not however function with stochastic
assignment.
An earlier problem that SAVEIT could not be used in conjunction with DIDDLE no
longer applies as (see 15.23) the route flows are estimated at the end of a full
assignment whenever DIDDLE is in effect. As with KOMBI (last paragraph in 9.3),
the use of DIDDLE introduces an element of approximation into the saved routes
but these problems are minor compared to problems of convergence.
Given the intrinsic advantages of using DIDDLE its default value is set to .TRUE.
9.5 Making Convergence Easier
9.5.1 Improved Convergence

Unfortunately there are no precise rules for what to do if your network does not
converge as well as you might expect or require (see 9.2.4). “All happy networks
are alike but an unhappy network is unhappy after its own fashion”. The following
are therefore only suggestions as to what you might try; if they work, fine - if they
don’t, keep on trying!
This section is primarily concerned with networks which appear to be converging
slowly and/or irregularly between the assignment and the simulation; e.g., their
%FLOWS reach 90% but fail to progress much further. The next two sections
provide advice on what to do with (a) really badly converged networks and (b)
very well-converged networks.
1) Check all warnings generated by SATNET, particularly Serious Warnings
and Non-fatal Errors. Coding errors are the single most common cause of
convergence problems. For example multiple turning movements
sharing a single lane can cause severe convergence problems; see
6.4.9. N.B. The easiest way to detect and correct coding errors is to use
the facilities to P1X to “highlight” nodes with specific errors and to
automatically loop over those nodes within node graphics; see 11.6.5.4.
2) Check the “Parameter Examination” advice as provided interactively
under P1X / Information and/or listed in .LPN and .LPT files. Many of the
checks included there also appear below.
3) Use the various “10 Worst Converged” lists available in P1X /
Convergence (see 11.15) in order to identify particular trouble spots in
the network which may require corrective action. The lists of “worst”
locations may be supplemented by the option to “highlight” (see 11.6.5.4)
the locations of the nodes where they occur, following which the option
“Hilite Nodes Loop Graphix” allows the user to automatically “loop” over
5120257 / Apr 15 9-14
Section 9
those nodes in order to demonstrate, using node graphics, potential

problems. Note, in particular, all error messages at such nodes even if
they may not be the direct cause of the convergence problems.
4) Check that the global levels of network congestion “look right”. Highly
congested networks tend to converge erratically so if, for example, there
are too many trips in the trip matrix the resulting congestion may
adversely affect convergence. (So, possibly, you need to consider elastic
assignment.)
5) Check that individual assignment and simulation sub-stages are
converging during the later loops at least; if not, increase NITS and/or
NITA (but see point 6 below and 9.5.4 re NITA). (Poor convergence on
early loops may not be a problem if they eventually come right.)
6) Increase MASL - after a large amount of wandering about in the
wilderness you may strike it lucky!
7) Use (strongly recommended!) AUTOK (Section 9.3.2) in preference to
KOMBI, AUTONA (Section 9.5.4) and – definitely - DIDDLE (9.4)
8) When using DIDDLE there is a strong case for reducing the maximum
number of internal iterations per assignment, NITA, but increasing the
number of assignment/simulation loops, MASL, since the total number of
all-or-nothing assignments used in the final solution is the product of the
two. Introducing more frequent updates of the cost-flow curves via the
simulation may possibly reduce the total cpu time required to converge.
See 9.5.4 below and also see NITA_S, 15.23.3. On the other hand it may
sometimes happen with DIDDLE that the overall convergence is impeded
not by the lack of convergence between the simulation and the
assignment but by the fact that assignment terminates after only 1 or 2
loops and does not allow sufficient change in the assigned flows. This
may be corrected either by reducing the stopping criteria parameters
FISTOP, XFSTOP and/or UNCRTS or, more straightforwardly, by setting
the minimum number of assignment iterations (NITA_M) to, say, 3. See
also 9.5.3. N.B. UNCRTS may be adjusted automatically by the program
under AUTONA = T; see 9.5.4.
9) Check the stage times and offsets at signalised nodes in order to identify
possibly badly coded signals since poor coding may lead to certain
stages becoming (incorrectly) heavily overloaded which in turn may lead
to poor overall convergence. Thus you may need to consider the use of
SIGOPT and/or SATOFF parameters within your network so that signal
optimisation is carried out internally within SATALL or else consider the
use of signal optimisation externally. See Sections 12.2 and 15.31. (Note
that optimising stage times generally has a much greater impact on
convergence than offset optimisation.)
10) Increase the dependence of cost on distance (i.e. increase PPK) since
distance (clearly) is fixed and does not vary between loops as does time
so that the assigned routes are less sensitive to time changes. (Although
your choice of PPM and PPK may well be constrained by other factors
such as evaluation.)
5120257 / Apr 15 9-15

Section 9
11) Make sure that LTRP > 0 as this helps to reduce “discontinuities” in cost-
flow curves, particularly at V = C for major arms at priority junctions
where there are very few other causes of below-capacity delays; see
8.6.1. Equally set RTP108 = T; see 8.6.3.
12) The basic reason why networks do not converge is because of the
interaction effects between flows and delays; reducing the level of
interaction may therefore help (but on the other hand it may make your
network representation less precise!). Therefore you could try to:
− Reduce the number of give-way turns (i.e. remove turn priority

markers);
− Reduce the critical gap values (the default values are, in all
likelihood, to be too high);
− Reduce lane sharing (and/or introduce flaring);
− Do not use blocking back (set ALEX to zero but not recommended);
− Check all simulation nodes where MAXQCT is invoked.
− Do not use blocking back (set ALEX to zero but not recommended);
13) (Repeat of 1!). Check the error messages in your .lpn file and/or use the
Highlight facility in P1X – most of the time that’s where the problem lies!
The next section illustrates one or two possible extreme cases.
9.5.2 Very, Very Bad Convergence: What to do

Inevitably there are certain networks whose convergence behaviour can only be
described as “terrible”. For example, their %FLOWS figures get to the mid 80’s
and then suddenly shoot back to the 70’s.
The main cause for such instabilities is, almost always, blocking back, aided and
abetted by coding “peculiarities”. For example, if a simulation link has been given
a link distance of, say, 10 metres and one lane then its default stacking capacity
will be less than 2 pcus. In this case if the exit turns go from V/C ratios of 0.99 to
1.01 then the link will start to block back, the blocking back factor may be
extremely low in order to reduce the queue to under 2 pcus and the resulting
queue may extend backwards through a long series of links. If V/C drops back
from 1.01 to 0.99 then the queues disappear. In this case the modeller has to ask
whether or not a link distance of 10 metres is realistic. (In some cases, of course,
it may be, but it may also well be that the link was simply added as some sort of
pseudo-link, 10 might be a typo for 100, etc., etc.).
Instabilities in blocking back may be detected from the table which displays the 10
links whose blocking back factors change most over a single assignment-
simulation loop. In particular look for any links whose stacking capacity is low.
Any link with a stacking capacity of less than, say, 5 pcus is an accident waiting to
happen and should be carefully vetted.
The converse situation may also occur, i.e., the link distance and stacking
capacity are correct but the queue is unrealistically long due to coding errors at
5120257 / Apr 15 9-16

Section 9
the junction leading to very low capacities. To illustrate the point from one
(anonymous!) network: a priority T-junction on a major road into town was coded
such that the X-marker which was meant to indicate that right-turning traffic
leaving town had to give way to traffic entering town was inadvertently coded on
the opposite arm which meant that the major traffic into town had to give way to
right-turning traffic from the other direction. As a result the capacity for traffic into
town was reduced from what should have been its saturation flow of 1800 down to
100 or 200, the resulting queue stretched back for 10 km and the whole model
became highly unstable. (The coding error, by the way, is now detected as
Serious Warning 137 in SATNET).
The morale of the story is that even very small errors in network coding can lead
to very large network problems and, unfortunately, users have to: (a) be very,
very careful in their coding and (b) look very, very carefully at their outputs.
9.5.3 Very, Very Good Convergence: How to Get It!

Most networks, provided that most of the coding “funnies” have been removed,
should be capable of converging to a very high degree; e.g., gap values of 0.01%
or better, %FLOWS of 100%, etc., etc. However, in order to achieve such
convergence levels, three conditions have to be satisfied:
♦ The assignment must be very well converged;
♦ The simulation must be very well converged; and
♦ The assignment-simulation loops must be very well converged.

The first may be achieved most easily using origin-based assignment (OBA,
Section 21) which can reduce the assignment convergence (i.e., Delta 7.1.4) to
(effectively) zero, the second is generally just a question of setting sufficiently tight
simulation convergence criteria (described next), while the third is best obtained
by making use of AUTOK (9.3.2).
In addition there is almost always a fourth condition which is that the network must
be well coded such that, even if there are no fatal or semi-fatal errors detected by
SATNET, certain Serious Warnings and/or Non-Fatal Errors (mostly involving X-
turns at signals) are removed.
To obtain extremely good simulation convergence it is normally sufficient to
specify the minimum number of simulation iterations, NITS_M, to, say, 5.
Otherwise, as one nears global convergence and the flows being simulated are
relatively stable, the normal simulation convergence criteria will be met after
possibly 2 or 3 iterations and, to go beyond that, extra iterations are required.
It may also be useful, if not using OBA, to set NITA_M, the minimum number of
assignment iterations to, say, 3 or 4, otherwise the assignment may stop after a
single iteration which does not allow a sufficient improvement in the assigned
flows to take place.
Finally, use of AUTOK guarantees optimum combinations of successive assigned
flows and the most rapid approach to global equilibrium.
5120257 / Apr 15 9-17

Section 9
Currently, it is probably safe to say, most networks are not run to anywhere near
their potential convergence levels – all it needs is a bit of ambition, confidence and
application of the above rules. Go for it!
9.5.4 Reduced CPU

Various “tricks” exist to try to minimise the cpu time required by SATALL to reach
the required level of assignment-simulation convergence, particularly for “large”
networks where run times become a practical consideration. Most of these
methods are based on the empirical observations that, certainly for large
networks, the assignments take much more cpu than the simulations (since the
number of assignment calculations is roughly speaking proportional to zones
times links whereas the simulation is proportional to links only).
(1) Increased MASL, decreased NITA - The first suggestion is, by using the
DIDDLE = T option to continue one assignment from the end point of the
previous assignment loop (see 9.4), the full assignment is made up of (in
effect) NITA * MASL all-or-nothing iterations with the simulation introduced
after every NITA iterations in order to update the cost-flow curves. By
decreasing NITA and increasing MASL in proportion the same number of total
iterations may be achieved in roughly the same cpu time (any increases in
cpu will be due only to the extra simulations) and with - hopefully! - the same
overall convergence. Thus instead of setting, say, NITA = 50 and MASL = 20
we would recommend using NITA = 10 (or even 5) and MASL = 100 in the
hope that convergence would be achieved in far fewer than 100 loops.
(2) Use of UPDATE - Alternative suggested methods of improving cpu are to
make greater use of the UPDATE facility (see 15.3) or to use the perturbation
techniques available within the path-based algorithms (see 21.3).
(3) Sliding Convergence Criteria - UPDATE may be particularly effective in
situations where one basic network is being continuously edited (calibration,
validation, etc.) and one version is much the same as the previous version.
One useful “trick” here is to gradually “tighten up” the convergence criteria as
the network nears its final state. For example, start with ISTOP = 80% and
gradually increase in steps of, say, 5% as your network coding gets better
and better. There is no point in carrying out a very long, very accurate
assignment to a network which still has glaring coding errors. A similar
principle is also used by CASSINI in order to minimise CPU time for supply-
demand feedback loops; see 15.54.
(4) AUTONA – Setting a parameter AUTONA = T (default F) in &PARAM in
the network .dat file allows SATALL to select “optimum” values of NITA
and/or UNCRTS at each assignment based on: (a) the best GAP value to
date and (b) the “history” of how delta and/or epsilon varied with iteration
number in the previous assignment. The idea is that if, say, the current best
GAP value is 1.0% then there is probably very little point in having a highly
accurate assignment down to delta/epsilon values of, say, 0.001% since, as
soon as we change the cost-flow relationships with the following simulation,
the GAP value will increase over Epsilon. A more realistic objective is to set a
“target” of, say, Epsilon = 0.01% for the assignment which is one tenth the
value of the current GAP. By analysing the “history” from the previous
assignment we can estimate how many iterations should be required to reach
5120257 / Apr 15 9-18

Section 9
this value and set NITA accordingly (subject to the requirement that is <= the
global maximum value of NITA and >= NITA_M). Empirically using AUTONA
= T has been found to significantly reduce CPU times.
In 10.9 AUTONA also automatically controls the assignment stopping criterion
UNCRTS (see 7.1.5) in addition to NITA by reducing it to a value comparable
to the current best GAP value. (The effect of reducing UNCRTS is generally
to increase the number of assignment iterations in order to achieve a
sufficiently well converged assignment).
The same principles of “relaxed convergence” are also used by CASSINI in order
to minimise CPU time for supply-demand feedback loops; see 15.54.
Note that AUTONA cannot be used with any form of elastic assignment.
9.6 Elastic Assignment/Simulation Loops

If the assignment is based on an elastic demand matrix as opposed to a fixed trip
matrix (see 7.4), the same principle of looping between assignment and simulation
as illustrated in Figure 9.1 still applies, the only difference is that the assignment
not only changes the link flows, it also changes the trip matrices. However the
same loop convergence criteria as listed in 9.2.1 still apply - if the link flows from
one loop to the next (or equivalently the cost-flow curves) are unchanged then the
process has converged.
SATALL therefore proceeds in a virtually identical fashion with elastic assignment
as with inelastic. Details of the changes required are given in 9.10.
Whether or not an elastic loop will converge better than an inelastic loop is difficult
to say in advance; it is probably a question of “horses for courses”. Thus including
trip matrix variability probably complicates matters; however the lower level of
congestion to be expected with elastic assignment probably simplifies matters.
Experience to date is limited.
For completeness we briefly consider here the alternative "DIY" approach of
explicit loops between SATEASY and SATSIM as illustrated below with additional
input and output files (although, see below, the use of SATALL is strongly
recommended.
5120257 / Apr 15 9-19

Section 9
Net.DAT
SATNET
Net.UFN
Cijø.UFM Control.DAT
Tijø.UFM SATEASY Tij′.UFM
Net.UFA
Tij′.UFM
SATSIM
Net.UFS
Thus starting from a network data file net.dat fed through SATNET the process
starts with an initial elastic assignment using SATEASY. This requires input
reference matrices c ij 0 and T ij 0 in order to define the demand function (best
defined within net.dat; see 7.12.3). An initial estimate of the road trip matrix, T ij ’,
may or may not be available. However on subsequent iterative loops the output
trip matrix T ij .ufm may be “re-cycled” back to the subsequent elastic assignment
with REDMEN = T.
SATSIM is run in order to update the link flow-delay curves based on the elastic
link flows and loops through the elastic assignment. Parameters MASL, ROSIE
and KOMBI (but not DIDDLE or AUTOK) may be used to control convergence.
The DIY nature of this approach is further reflected in the fact that there are no
dos-style bat procedures available to simplify the loops. This is left to your
ingenuity!
However it needs to be strongly emphasised once again that an elastic
assignment loop is much better undertaken using SATALL as described in
Section 9.10, which is run as a single program and does not require any complex
DIY procedures.
9.7 SATALL: General Functions

The program SATALL, first introduced with SATURN 9.1, in effect combines the
programs SATASS/SATEASY and SATSIM into a single program and carries out
a full assignment/simulation convergence loop internally. Thus, as shown in
Figure 3.1, taking as input a .ufn network file built by SATNET, it both assigns and
simulates so as to produce an output file containing converged assigned flows
plus the corresponding simulated delays.
5120257 / Apr 15 9-20
Section 9
By combining two programs into one SATALL should be both faster and,
ultimately, “more clever” in terms of the steps that can be introduced in order to
improve the rates of convergence. For example it can combine the DIDDLE
option with elastic assignment which is otherwise impossible; see 9.10. All the
various distinct options for assignment and/or simulation that can be invoked with
the separate programs SATEASY and SATSIM may now be carried out within
SATALL. Indeed, as with the elastic DIDDLE (what a great name!) mentioned
above, there are extra options only available with SATALL; see 9.12.
9.8 SATALL Run-time Convergence Statistics

The rates of convergence of the assignment-simulation loop as well as the internal
convergence of both the simulation and assignment sub-stages are displayed
during run time in three parallel “windows”. In all three cases, more complete
convergence statistics are given within the .LPT file; see 9.9. The statistics
provided within each “window” are as follows:
9.8.1 Assignment - Simulation Convergence

(i) The “loop” number.
(ii) The percentage of links whose flows differ by less than 1% (or, strictly
speaking, PCNEAR %) between successive assignments; see 9.2.
(iii) The average GEH parameter (see 15.6) indicating the differences in
demand flows per link between successive assignment loops.
Note that both measures (i) and (ii) are used to determine stopping criteria; (iii) is
provided for information only. Convergence is reached as (ii) goes to 100% and
(iii) goes to zero.
9.8.2 Assignment Convergence

The statistics displayed depend on the precise assignment option used. For
Wardrop-based assignment the window displays:
(i) iteration number;
(ii) the lambda or step-length value (see 7.1.2);
(iii) the delta function (see 7.1.4).
Of these only i) and ii) determine stopping conditions; iii) goes to zero as one
approaches convergence.
For stochastic-based assignments (see 7.2.5):
(i) iteration number;
(ii) total pcu-costs on each assignment;
(iii) the root mean squared differences in flows between successive
assignments.
Only i) is used as a stopping criteria; ii) stabilizes and iii) goes to zero at
convergence.
5120257 / Apr 15 9-21
Section 9
9.8.3 Simulation Convergence

The simulation statistics include:
(i) the iteration number;
(ii) the average absolute change in OUT profiles in pcu/hr (see 8.3);
(iii) the number of simulation junctions simulated;
where, under iii), junctions are only simulated on a particular iteration if there has
been a “significant” change in the flow profiles into that junction. A decreasing
number of simulated junctions implies convergence.
Statistics i) and ii) determine the simulation stopping criteria; see 8.3. At
convergence ii) approaches zero.
9.9 SATALL Convergence Statistics: Full Line Printer Listings

The line printer (.LPT) output file contains fully comprehensive statistics illustrating
the convergence of both the individual assignment and simulation stages plus the
loops and includes all the “window” data described in 9.8. To reduce the size of
the file these are given in tables as far as possible.
9.9.1 Assignment - Simulation Loop Convergence

At the end of each simulation a number of different loop convergence indicators
are listed. A further summary table giving a sub-set of these statistics by iterative
loop number is given at the end of the complete set of loops and may also be
obtained as part of the convergence statistics output by SATLOOK (11.11.8)
and/or P1X.
1. The percentage of links “PCOK” whose (demand) flows differ by less than 1%
(or, strictly speaking, PCNEAR%) between successive assignments; see
9.2.1. The distribution of PCOK for a standard set of (in effect) PCNEAR
values from 0.5% up to 50% is also given. In addition Table L(9) – see below -
lists the 10 “worst” links.
2. Further comparison statistics of flow differences per link between the last two
assignments, e.g.:
MEAN GEH STATISTIC = 0.83
MEAN ABSOLUTE DIFFERENCE = 15.96 %
RELATIVE MEAN ABS DIFFERENCE = 3.65 %
RELATIVE MEAN STANDARD DEVIATION = 7.37 %
3. Compare the turn delays as estimated by the assignment with the ‘correct’
delays calculated by the simulation; at convergence the two should be
identical, e.g.:
MEAN SIMULATED TURN DELAY = 31.75 secs
MEAN ABS. DIFF. IN ASS/SIM DELAYS = 19.38 secs
RELATIVELY = 61.03%
5120257 / Apr 15 9-22

Section 9
NUMBER DIFFERING BY < 5.0% OR 1 96

SECOND =
RELATIVELY (PCOK) = 78.05%
The distribution of PCOK above as a function of the critical % is also

given here while the 10 “worst” turns are listed separately in Table L(8) –
see below.
4. The assignment/simulation gap function; see 9.2.1.
5. The assignment simulation variational inequality measure; see 9.2.1. NB:
Measures 4) and 5) do not appear under certain options, eg stochastic or
elastic assignment, where they are not relevant.
6. Eight standard simulation summary statistics between two successive
iterations, as illustrated below.
CONVERGENCE OF BASIC SIMULATION TOTALS:
Previous Current
Difference %
Iteration Iteration
PRIMARY STOPS 14733.07 14164.58 568.49 4.01
SECONDARY STOPS 7805.46 6488.73 1316.74 20.29
TRANSIENT DELAYS 86.03 83.19 2.84 3.41
QUEUING DELAYS 231.75 217.65 14.10 6.48
CRUISE TIMES 136.83 135.99 0.84 0.62
TOTAL TIME 454.61 436.83 17.78 4.07
PCU-DISTANCE 4834.87 4816.13 9.74 0.39
SPEED 10.64 11.03 -0.39 -3.54
Note that whereas certain global statistics such as the pcu-distance may
appear to stabilize rapidly others, such as those related to delays and
stops, are considerably more variable.
7. List of the (up to) 10 largest changes in Blocking Back Factors used on the
current and previous loops plus an r-squared value comparing the same
factors.
9.9.2 Disaggregate Measures (10 Worst Tables)

Assignment-simulation statistics may also be calculated and displayed at the level
of individual nodes, links or turns: for example, the difference in turn delay as
calculated from the flow-delay curves on the previous assignment with that from
the latest simulation.
Further disaggregate measures include “gap”, capacity and flow differences. The
“Gap” is defined to be difference between the assigned and simulated delays (as
above) multiplied by the demand flow. It is therefore similar, but not strictly
identical, to the route-based contributions to the assignment delta values (Eqn.
5120257 / Apr 15 9-23

Section 9
7.3, section 7.1.4) and/or simulation-assignment gap function (9.2.1). Capacity

differences are simply the differences in turn capacity as calculated on two
successive simulations (with an assignment stage in between) while flow
differences are the differences between two successive assignments.
Two SATALL tables which relate to the convergence of the assignment –
simulation loops at a disaggregate level are given in slightly different locations in
the .lpt files.
Firstly, at the end of each simulation Table L(8) lists, in decreasing order, the 10
turning movements whose current simulated delays differ most from those
calculated from the time-flow curves used in the previous assignment (as given in
aggregate terms under (3) above). These differences indicate where the
assignment and the simulation “disagree” in terms of how to define delays even
though the demand flows are identical; this “disagreement” is the main cause of
“gap” values which exceed the “delta” values; see 9.2.1. To help in identifying the
likely cause of these differences the current and previous capacities plus the
(demand) flows are listed.
Secondly, at the end of each assignment stage, Table L(9) lists the 10
(assignment) links whose (demand) flows differ most in terms of GEH statistics
between the latest assignment and that on the previous loop.
The same two tables may also be displayed interactively within P1X (see 11.15)
which also optionally offers two additional “10 worst” tables in terms of (a) “gaps”
and (b) capacities.
In addition the various turn-based convergence statistics, e.g., delays, gaps, etc.
may be generated and displayed within P1X as either turn or link annotation data
which may, in turn, be saved as SATDB data columns. In the latter format they
may be displayed in a window with the data ordered by, say, decreasing absolute
value so that it becomes possible to view not just the 10 worst examples but the
full list of worst examples.
Finally disaggregate convergence statistics may also be displayed per simulation
node within the standard node text tables within SATLOOK (11.11.1).
9.9.3 Assignment Convergence

A summary table is given at the end of each assignment, the precise contents of
which depend on the assignment technique used (e.g. Wardrop vrs Stochastic,
elastic vrs fixed trip matrix, etc). For the simplest case of Wardrop Equilibrium the
following measures are given for each iteration:
♦ LAMBDA: The “step length” at each Frank-Wolfe step; see 7.1.2.
♦ FRACTION: The ultimate fraction of trips assigned to this iteration; see 7.1.2.
♦ C1: The total cost associated with the current flows and the current costs.
♦ C2: The total cost if all trips could be assigned to the current minimum cost
routes.
♦ DELTA = (C1 - C2)/C2; see 7.1.4.
5120257 / Apr 15 9-24

Section 9
♦ Z: Current value of the objective function;
♦ DZ: The improvement to the objective function in this iteration.
♦ FDZ = DZ/Z (as a %), the fractional improvements in the objective function.
♦ ZLB: A lower bound on the objective function; see 7.1.5.
♦ ZULB: The upper lower bound on the objective function; see 7.1.5.
♦ EPS: Epsilon, the current “uncertainty” in the objective function; see 7.1.5.
♦ FIMP: The improvement in Z relative to epsilon; see 7.1.5.
9.9.4 Simulation Convergence

A standard summary table is given at the end of each simulation, listing for each
iteration:
CC average absolute change in the OUT profiles; see 8.3.

NO SIM number of nodes simulated
NO BB Numbers of links which block back;
SUM Sum of absolute differences between queues and stacking
capacities
NO > links with queue greater than the stacking capacity
SUM > total excess PCUs
NO < Links with queue less than the stacking capacity
SUM < total spare PCUs
NO = Links with queue equal to the stacking capacity (to +- 0.1 PCU)
ABBC The average absolute change in blocking back factors
Thus “No BB” has been subdivided into 3 categories, “NO = ”, “NO
<” and “NO >”, as has “SUM”.
9.10 Elastic Assignment within SATALL

Elastic assignment within SATALL is carried out in much the same way that it is
carried out in SATEASY with the obvious proviso that it is part of the outer
simulation/assignment loop, not an isolated elastic assignment.
Thus the same control parameters are used; eg MCGILL >0 designates the form
of elastic demand function. BETA and POWER are elasticity - related
parameters, etc. Similarly the share-based demand functions, the extended logit
models (7.6) and the distribution models (7.10) may all be invoked within
SATALL. All these and the necessary file names may be set either in the original
.dat file - highly recommended, 7.12.3 - or input/re-defined in the SATALL control
file.
5120257 / Apr 15 9-25

Section 9
There are, however, certain differences between SATALL and SATEASY as

listed below.
On loops after the first SATALL always uses the REDMEN option of starting the
latest elastic assignment with the estimate of the trip matrix from the previous
assignment. The reasons for doing so are (a) it almost certainly helps
convergence and (b) the previous trip matrix is already stored internally so no user
intervention to define the matrix is required.
Hence if REDMEN = T and an estimated trip matrix is set in the original .dat file
(or otherwise) this is only used on the very first elastic assignment. (NB. This is
not a reason not to invoke REDMEN since using a good estimate of T ij on the first
assignment is still a very good thing).
SATALL can use the DIDDLE option such that, if DIDDLE = T, any inelastic
assignment after the first will commence with the initial set of link flows equal to
the flows from the previous assignment. This is very similar to the REDMEN
option, the difference being that REDMEN specifies, in effect, the initial flows on
the pseudo links while DIDDLE specifies the flows on the real links. Empirically
using DIDDLE appears to improve convergence significantly.
9.11 Multiple User Class Assignment within SATALL

Multiple user class assignment within SATALL is essentially no different than with
the separate assignment steps within SATEASY. Follow the instructions in 7.3.
Note that a separate set of assignment/simulation flow convergence statistics is
given for each user class; i.e. items (1) and (2) as described in 9.9.1.
The same applies for elastic multiple user class assignment; see 7.9.
9.12 Special SATALL Extensions

We describe here a set of special “extensions” to the standard assignment -
simulation procedures within SATALL.
9.12.1 Continuation Runs with SATALL

It is a frequent problem that having run a network through SATALL over, say, 20
assignment - simulation loops, you find that what you really wanted was to do 21
loops. An obvious solution is to change the convergence parameters in the
original file, e.g. MASL to 21, and re-run but on large networks this is potentially
very time consuming.
Alternatively the command
SATALL net MASL 1
will take the file net.ufs (which has been through 20 loops, say) and carry out one
more simulation-assignment loop. The output file will also be named net.ufs and
therefore over-writes the input file.
Using a parameter MASL 5 will run (up to) 5 extra loops; the actual number may
be less if the loops terminate on the ISTOP criteria rather than MASL. It will,
however, always carry out one additional loop even if the original ISTOP criterion
5120257 / Apr 15 9-26

Section 9
was satisfied. One may circumvent this “problem” by using both a MASL
parameter and the KR parameter to define a new control file which increases the
ISTOP value. Alternatively one can edit the network .ufs using P1X (11.9.11) to
change parameter values such as ISTOP prior to the continuation run.
Strictly speaking the MASL n option increments the existing value of MASL by by
n; it does not guarantee that exactly n extra loops are run since, as mentioned
above, the number of loops may be terminated by other criteria such as ISTOP.
For example, if the original value of MASL was 20 but the loops stopped after 10
due to ISTOP, then using MASL 5 on the command line and resetting ISTOP to a
higher value may actually result in 15 extra loops since the new value of MASL
will be 25. In principle it should be possible to set up the continuation option such
that “MASL 5” implies “run exactly 5 extra loops” or that it means “set MASL equal
to the current number of loops plus 5”. But it doesn’t do that – it does what it says
on the tin!
Note that in this case the output network file, net.ufs, has the same name as the
input network file, i.e. it overwrites it. This creates a problem since both versions
of the file need to co-exist at the same time so, to avoid this, the input file is first
copied into net.ufn and that file is used as input. A consequence of using this
option is that an existing net.ufn file will itself be over-written.
Clearly this facility depends on the network having a simulation component; a
similar continuation option for buffer-only networks is described under WIDDLE in
7.11.6.
9.12.1.1 SAVEIT within Continuation Runs

If a network for which a continuation run has been initiated and which has SAVEIT
= T then, in addition to the MASL extra simulation-assignment loops, one might
also expect that a new .UFC file would be created. However, this is not altogether
desirable since, very often, the CPU time required for the final SAVEIT
assignment can be much longer than that required for MASL extra iterations.
Moreover it is quite straightforward to create a new .UFC if desired later on using
SATUFC (see 15.23.2).
Thus, post 11.3, the default option with a continuation run is not to create a .UFC
file via the extra SAVEIT assignment unless it is explicitly requested by including
a keyword SAVEIT on the command line. Thus:
SATALL net MASL 1 SAVEIT
would take net.ufs through one further assignment-simulation loop followed by an
extra SAVEIT assignment and .UFC file creation.
9.12.2 Outer Signal Optimisation Loops (NIPS, SATOFF and/or SIGOPT)

Prior to version 10.5 signal settings (either stage times if SIGOPT = T or offsets if
SATOFF = T) could be continuously optimised during the assignment / simulation
loops; i.e., once per loop. However, as explained in 15.31.1, this is almost
certainly not a very realistic procedure for setting green times since it almost
certainly leads to an overly optimistic view of network performance, nor is it very
efficient in terms of cpu time.
5120257 / Apr 15 9-27

Section 9
Thus in 10.5 an option has been introduced such that the optimisations only occur
at the end of a fully converged simulation / assignment sequence, e.g., at the end
of MASL loops. At this stage the stage times and/or offsets are optimised and the
simulation /assignment loops re-started until convergence is again achieved. The
“outer-outer” loop is repeated NIPS times, where NIPS is a parameter set under
&PARAM in the original network .dat file.
Generally speaking it is recommended that NIPS should be a small number, e.g.,
1 or 2, since a very large value will simply repeat the problems noted earlier. If
NIPS = 0 the original method of continuous optimisation is followed. N.B. The
original default value of 0 was chosen primarily to retain upwards compatibility and
was not particularly recommended; post 10.9 the default was changed to 2.
We note that, if the optimisation changes are relatively small (as is generally to be
expected) then subsequent should converge very quickly. There is a good case,
therefore, for reducing MASL in proportion to NIPS (or, strictly NIPS+1). For
example, to carry out a maximum of 60 simulation/assignments with NIPS = 2,
then set MASL = 20 as that will give 20 loops followed by the first optimisation, 20
more followed by the second and 20 more to follow – a total of 60.
9.12.3 Assigning a Nil Matrix: The ZILCH Option

A new option, first included in version 10.6, allows the user to run SATALL without
actually assigning any trips. In this case the only network flows will be those
included as “fixed flows”, e.g., bus routes, pre-load flows, etc.
To request this option set the parameter ZILCH = T either within &PARAM in the
network .dat file or within the SATALL control file.
If ZILCH = T SATALL basically runs through a single loop with, in effect, no
assignment stage apart from a load of the fixed flows followed by a single
simulation. In effect MASL = 1. Clearly no feedback is necessary since the
simulated delays have no impact on the flows.
At first glance this may seem a bit of a silly option – why have an assignment
model that doesn’t actually do any assignment? However there are a number of
circumstances in which it could be useful.
For example, one might wish to cordon off a segment of a network (via SATCH)
and run the simulation with the identical flows as in the “master” network since
extracting and re-assigning a cordoned trip matrix (a) takes time and (b) is not
guaranteed to give identically assigned flows. To do this the master network must
be introduced as a pre-load network (see 15.5) to the cordoned network (with
some care being taken that any bus flows etc. are not double-counted – more on
that one later). Note as well that the pre-load flows for a cordoned network must
be loaded via a text file, not a .ufs file, since the network structure will have
changed under cordoning; see 15.5.4.
Equally one might wish to simulate traffic flows extracted from a different suite of
programmes entirely within SATURN and transferred as a text file. (Recall the use
of text files to define pre-load flows, not just .ufs files; 15.5.4.) Or, similarly, one
might wish to test the effect of “pre-scheme” flows on a “with-scheme” network so
that the network may have been altered but the link flows themselves remain
unchanged.
5120257 / Apr 15 9-28
Section 9
Another application would be to do a genuine zero load in order to calculate

delays at zero flow in order to accurately measure the effects of “congestion”. (For
example, traffic signals always give some delays even with zero flows because of
the finite red times so one might wish to subtract these delays from the “actual”
delays.)
Note that because no assignment takes place certain options such as SAVEIT
etc. are ignored and there will be no route information output. Equally any form of
elastic assignment is ignored. On the other hand if there are multiple user classes
flows (if any are input via pre-load) are retained.
9.13 The SATALL Batch Procedure

The program SATALL may be run by typing:
SATALL network trips KR control COST cost REDMEN tij1
TIJ tij2 FREEZE ice MASL n RESTART
where:
Network.UFN Input network UF file from SATNET

Network.UFS Output network file
Network.UFC Output costs per Frank-Wolfe iteration under SAVEIT (15.23.1)
Network.LPT Output line printer file
trips.UFM Input trip matrix file (Optional)
control.DAT Ascii Control file (Default: SATALL0.DAT)
Files used for elastic assignment:
cost.UFM Input cost matrix C0 ij

tij1.UFM Estimated road trip matrix (REDMEN = T)
tij2.UFM Output road trip matrix
ice.UFM Input frozen cell matrix (ICING=T)
MASL n Re-run with n more assignment/simulation loops (see 9.12.1)
RESTART Input the previous network.ufs file; see 15.4
(N.B. Use of M 21 cost/M 22 tij1/M 23 tij2/M 24 ice also works)
If the KR option is not invoked on the command line, then SATALL expects to find
the parameters in the default control file SATALL0.DAT. (See 9.15.2.)
Note that the input file has the “new” extension .UFN and that the output file is
always .UFS whether or not the network is pure buffer or not. If network.UFN
does not exist but network.UFS does then it is renamed.
5120257 / Apr 15 9-29

Section 9
9.14 The SATURN Batch Procedure

The special DOS .bat file, SATURN (also known as SATURN9), has been
provided to run the complete set of network building (SATNET) plus
assignment/simulation (SATALL) operations in sequence.
In the simplest case, where the trip matrix and all other file names have been
defined within the network .dat file (recommended), use:
SATURN network
In more general terms to invoke a complete run use:

SATURN network trips UPDATE net1 PASSQ net1 PS post
Files:
network.DAT Input SATURN network data file

trips.UFM Input unformatted trip matrix file
(Optional - not necessary if defined within network.DAT see 6.3.4)
network.UFN Output SATURN UF file from SATNET

network.UFS Output SATURN UF file from SATALL
network.UFC Output route cost file
network.LPN Output line printer files from SATNET...
network.LPT and SATALL
net1.UFS Input SATURN UFS file for UPDATE or PASSQ (Optional)
post.PS Over-write file for input to SATNET; see 17.4.1. (Optional)
Further details of the SATURN .bat procedure are given in Section 14.3 and
special extensions thereto are described in Section 14.4.
9.15 SATALL: Technical specifications
9.15.1 SATALL Files

Channel
Remarks
Number
1 The input UFN network file from SATNET. (Mandatory)
2 The output UFS file containing the assigned flows and simulated
delays. (Mandatory)
3 The output UFC file containing the link costs by iteration number.
(Optional: SAVEIT = T)
4 The output UFO file
5 The control file specifying the options and parameters for this run of
SATALL as specified below. (Mandatory)
6 The output LPT line printer file. (Mandatory)
5120257 / Apr 15 9-30

Section 9
8 A scratch UF file to temporarily store iteration costs under SAVEIT.

(Optional: SAVEIT = T)
9 Input UFM file containing the trip matrix being loaded (or the
0
“reference” trip matrix T ij for elastic assignment). (Mandatory)
10 Scratch UFX files used for both input and output if …
11 … insufficient RAM to store the trip matrix under ..
12 ….multiple user class and/or elastic assignment
13 A further scratch UFX file used under MUC
15/14 Terminal (output only) (Optional (MODET ne 0))
19 Input cost matrix “CGHFIL” used under incremental distribution
(MCUBC=1) (Optional)
20 Input cost matrix “CKLFIL” used at the lower level of a nested logit
model (MCGILL=5) (Optional)
0
21 Input “reference” cost UFM matrix c ij used under Elastic Assignment
(Mandatory under Elastic Assignment)
22 Input initial trip matrix estimate used under Elastic Assignment
(Optional under Elastic Assignment (REDMEN = T))
23 Output road trip UFM matrix used under Elastic Assignment: trips by
road (Mandatory under Elastic Assignment)
24 Input “freeze” matrix indicating which cells in an elastic assignment
are to be frozen (ICING=T); see 7.5.5. (Optional)
28 A scratch UF file used under OBA plus AUTOK or KOMBI
29 Input update .UFS file used under Warm Starts
9.15.2 SATALL Control File Data Input

Input consists only of a set of Namelist Parameters associated with the name
&PARAM and an optional new network title.
The parameters which may be defined here constitute a sub-set of those
described in Section 6.3, more precisely:
1) Parameters relevant to the simulation:
AFTERS, ALEX, CAPMIN, LRTP, MAXDTP, MAXQCT, MYTVV, NFT, NITS,
NOPD, NOPMAX, NOTUK, QUEEN, SIGOPT, TAX and TDEL.
2) Parameters relevant to the assignment:
AMY, ASHORT, DIDDLE, ERTM, EXPERT, FISTOP, GONZO, KINKY, KOB,
KORN, MCALG, MULTIC, NITA, PARTAN, ROSIE, SAVEIT, SHADOW,
SOWHAT, SUET, SUZIE, SUZIEQ, TIJMIN, UNCRTS and XFSTOP
3) Elastic assignment parameters described in 7.12.2.
BETA, BETA_2, BETA_D, FRED, ICING, MCGILL, MCUBC, MASL_F, NITA_F,
NITA_S, POWER and REDMEN
5120257 / Apr 15 9-31

Section 9
4) Parameters relevant to the simulation/assignment loop:

ISTOP/RSTOP, KOMBI, MASL, NIPS, NISTOP and PCNEAR
5) Miscellaneous parameters:
MODET, TITLE (see below) and WINDY
6) Filenames:
FILCGH, FILCIJ, FILCKL, FILICE, FILRED, FILTIJ, ROADIJ
Network Title
A new descriptive network title may be set by either:
1) A namelist parameter of the form:
TITLE = ‘nettitle’
1) A namelist designation of a logical variable:
TITLE = T
in which case the new network title is contained on the record immediately
following the namelist records (i.e. following &END) and occupies columns 1 to
76.
Default File
The default control file SATALL0.DAT is as follows:
&PARAM
&END
5120257 / Apr 15 9-32

Section 9

d
10.9.24 SATURN V10.9 Release (Full) DVV AG IW IW 06/05/11
5120257 / Apr 15 9-33

Section 9
MX: Interactive Matrix Manipulation
10. MX: Interactive Matrix Manipulation

10.1 Synopsis
MX is a flexible interactive matrix manipulation program which incorporates
virtually all matrix operations required by SATURN users. It includes options to
build matrices, change them (e.g. by factoring) and analyse them. The flexibility
means, for example, that users can carry out their own trip matrix demand model
procedures involving e.g., trip distribution (constrained or otherwise), modal split,
park and ride etc using the facilities within MX, even if those procedures are not
explicitly included within MX (as some are; see 10.20).
Although MX has been constructed as a perfectly general matrix manipulation
program clearly its primary use will be based on SATURN and transport planning
applications. Indeed the vast majority of matrices which MX handles will be origin-
destination trip matrices. This is very often reflected in the language used in the
documentation; for example “row” and “column” are used interchangeably with
“origin” and “destination” and sometimes cell values are referred to explicitly as
“trips”, e.g. when discussing distribution models. Equally “O-D” and “I-J” will be
used interchangeably when referring to individual cell locations.
MX includes all the facilities previously provided in earlier SATURN versions by
the separate programs M1 through M7 plus many new ones. The original
historical program names tend to live on within, e.g., batch files names and some
internal options within MX. See 10.9.2, 10.20 and Appendix W.
MX operates essentially on a single “internal” matrix stored in RAM although
operations involving up to 10 “external” matrices are also permitted. More details
are given in 10.3.
In operational terms MX is an interactive menu-based program, largely but not
exclusively text-based (see 19.6), and the general principles outlined in Section
19.3 apply.
10.1.1 Uses of MX
A more detailed description of each of the main options listed in the “Master
Menu” follows. These may be subdivided into:
♦ Input
♦ Changing matrices
♦ Analysis
♦ Output
10.1.1.1 Input
1) FILES MENU
The FILES option allows the user to define new input matrices (10.3.1), to request
basic information on these files (e.g. matrix title) and to introduce a supplementary
5120257 / Apr 15 10-1

Section 10
network UFS or GIS file (10.3.3) to supply, e.g., sector definitions (10.2.5.3) or
zone names (10.3.3) and to declare a matrix as following TfL zone name
conventions (5.1.7).
2) COPY/TRANSPOSE/RE-CODE AN INPUT .UFM FILE; REDEFINE
ZONES
Transfer an external input matrix into the internal memory where it can be
manipulated, analysed, etc., etc. The matrix may be either read “as is” or
transformed in various ways, e.g. by adding new zones or aggregating existing
zones. Using a simple “trick” this also allows the zonal structure of the internal
matrix to be edited.
3) BUILD/UPDATE THE INTERNAL MATRIX FROM A .DAT FILE
Construct a matrix from an external ascii data file. This may be either in a
“standard” SATURN format or in one set by the user, e.g., to facilitate matrix
transfer from other suites of programs or from a spreadsheet program. In
particular this function may be used in conjunction with the “dump” facility under
13 below to transfer a SATURN matrix file into, say, EXCEL, edit it and re-read it
within MX.
Under “Update” the matrix may be only partially set, e.g. within a selected area,
from the input .dat file or an existing matrix may be “incremented”.
10.1.1.2 Matrix Changes

1) SELECT
Certain options, such as factoring, may be applied only to selected “areas” or cells
of the matrix - this option defines those areas.
2) FACTORING
These options include not only simple factoring of all (or part) of the matrix but
also Furness factoring by row or column totals (both singly and doubly
constrained). Factor definitions may be either interactive or read in from pre-
prepared “control files”.
3) MATRIX MANIPULATION; E.G. USING FORTRAN EQUATIONS
This option allows for a very general matrix manipulation by defining, via
equations based on FORTRAN syntax, the new matrix to be created. For
example to average two matrices the user would type:
0.5 ∗ ( X 1 + X 2 )
while more complex matrix operations are possible, for example:
e −0.23 X1
transforms an input matrix into its corresponding negative exponential.
5120257 / Apr 15 10-2

Section 10
10.1.1.3 Analysis
1) STATISTICS (UNIVARIATE OR COMPARISON)
Compare two matrices, obtain a set of standard univariate statistics (mean, range,
etc.) for one matrix, or obtain a trip length distribution.
2) VIEW/EDIT MATRIX ELEMENTS
A flexible set of options to view the current internal matrix on the terminal. Cursor
control keys may be used to “move” through the matrix and more than one matrix
may be viewed simultaneously. In addition the values of cells in the internal
matrix may be “edited” using an interactive screen editor or window.
3) VIEW ROW AND COLUMN TOTALS
Display row and/or column totals interactively.
4) MATRIX GRAPHICS
Frequency and trip length distributions may be displayed graphically.
10.1.1.4 Output
1) PRINT MATRIX CELLS/SECTORS TO THE LP FILE
Produce a “standard” matrix listing to the line printer file intended for later
analysis.
2) PRINT/DUMP ROW AND COLUMN TOTALS
Produce a listing of row and column totals to either the line printer or a file.
3) DUMP MATRIX/SECTOR DATA TO A .DAT FILE
Output matrix file (in toto) to an external ascii (e.g. .dat) file. This may be either in
the standard SATURN format or in a format set by the user, e.g., so as to be able
to “export” a matrix to a spreadsheet. See also 3 above for the reverse operation.
4) DUMP/RE-CODE THE INTERNAL MATRIX TO A UFM FILE
The internal matrix file may be output (in to) to an external binary .UFM file for use
in other SATURN programs. This is the normal way to “save” a new matrix. As in
option 2 the matrix file may be output “as is” or transformed in various ways (e.g.
by recoding zones).
5) STACKING AND UNSTACKING .UFM FILES
A set of externally input square matrices may be combined together and output as
a single “stacked” matrix file (see 10.2.4) or, alternatively, if the internal matrix is
itself a stacked matrix it may be split into a full set of output individual matrices or
a single matrix from a single level.
6) MATRIX DEMAND CALCULATIONS
A prototype set of “formal” transport demand model steps such as
distribution or modal split are carried out using a combination of input
5120257 / Apr 15 10-3

Section 10
trip and cost matrices. These parallel the standard elastic demand
options within SATEASY (see sections 7.4 to 7.10) and demand
calculations by time period (see 17.12).
10.1.2 Launching MX from a Command line / Batch file

To invoke MX to “look at” a matrix file mat.ufm use a batch / command line (see
14.1):
MX mat
or to enter without any specific files in mind (e.g., to create a new .ufm matrix from
a text file; see 10.5) use:
MX I
To look at multiple matrix files mat1.ufm, mat2.ufm, … it is easiest to use the

MXX batch file in preference to MX. E.g.,
MXX mat1 mat2 mat3 mat4
Selected input and/or output filenames may also be set via the command line
by using “key words” such as OUT, KP and KR; type “MX” for a full list and for
name conventions.
In addition note that a Command Line with more than 10 “words” may be
accommodated via the XCL option described in Section 14.8.
10.2 Matrix Files: General Properties
10.2.1 .DAT and .UFM Files

Within the SATURN Suite matrix data exists in essentially two forms: first, as “raw”
data in ascii or text files, and secondly as “processed” or binary data in
unformatted files. These are most easily identified by their standard file
extensions .dat and .ufm respectively.
With the exception of MX when used to “build” matrices by converting a .dat file
into a .ufm file all programs which involve matrices access them in their .ufm
format. Thus, for example, the trip matrix file input for assignment must be a .ufm
file.
.Ufm files include not only all the cell values for the matrix but also a certain
number of “header records” which record, for example, basic matrix data such as
the number of rows and columns in the matrix but also relevant filenames,
information on sectors and (post 11.3) details of any zone-to-group aggregations
which may have been specified via .Z2G files (see 10.2.5.5).
For virtually all transport-based applications the matrices are square (number of
rows equals number of columns) and the rows/columns are associated with
zones. SATURN follows the general convention that rows are associated with
origins and columns with destinations. Thus in a trip matrix the seventh element
in the third row represents the number of trips from zone 3 to zone 7. Each row is
stored in a separate record within a .ufm file.
5120257 / Apr 15 10-4

Section 10
Note that with SATURN 9.5 matrix .ufm files are held in a “zipped” format which is
invisible to the user and whose objective is to minimise the size of the files. For
example if a matrix row consists entirely of zeros the zipped format records this
with a single marker rather than n (number of columns) distinct values. A number
of other similar “tricks” are employed. This means that, for example, an observed
trip matrix, 95% of whose cells might be zero, only requires marginally more than
5% of a “full” matrix.
In theory MX can handle both square and non-square matrices; however, for the
reason above, MX is very seldom used in practice with non-square matrices so
some caution is advised if you do wish to work with non-square. The exception is
“stacked matrices” - see 10.2.4 - which are in effect a set of multiple square
matrices and are therefore standard.
10.2.2 Zonal Sequential Numbers, Numerical Names and Zone Titles

Each row and column of a (square) SATURN matrix has an external numerical
“name” associated with it. Thus if the matrix represents a zone-to-zone trip matrix
the name associated with the Ith row is the (numerical) name of the Ith zone. The
“sequential” numbers are determined by the external zone names in increasing
order; i.e., the first row corresponds to the lowest numbered zone, the second to
the next lowest number, etc. Since zone numbers need not be sequential in
SATURN (i.e., 1,2,3,...) the name of the Ith zone may be much larger than I. The
basic advantage of having a non-sequential numbering system is that the user
can associate informative and fixed numerical names with each zone,
independent of which other zones are included in the network or matrix.
In addition (see 5.1.6) zones may have alphanumeric or text names associated
with them as stored on the associated GIS files. For example sequential zone 6
might be named (numerically) 27 and have a text title of “West Ham”.
As a convenient shorthand we refer to ‘titles’, ‘names’ and ‘numbers’ as opposed
to ‘alphanumeric names’, ‘numerical names’ and ‘sequential numbers’.
The same system of “sequential” and “external” zone numbers is also used in
SATURN networks and is described in greater detail in section 5.1.6. Note, in
particular, that zone “names” are restricted to 5 digits (i.e., numbers up to 99999)
although a maximum of 4 is recommended (in order, for example, not to fill up the
maximum 5-column input fields as used in certain standard file formats (10.5.1)) .
Clearly networks and matrices based on the same set of zones will have exactly
the same correspondences between sequential and external numbers.
Logically zone names should be positive non-zero numbers and, whereas
exceptions to this rule will be fatal errors in network building, it is just about
possible to have zone names equal to zero in matrices although the practice is
certainly not recommended and will almost certainly be made a fatal error ASAP.
It is essential that users be aware of the differences between a zone’s name and
its sequential number. In all SATURN network-based programs the external
names are always used in input or output. However in most matrix operations it is
possible to refer to either the sequential numbers or the external names; in
general options exist to “toggle” between the two systems.
5120257 / Apr 15 10-5

Section 10
For square matrices rows it is assumed that the same set of numerical names
and/or titles applies to both rows and columns.
For stacked (multiple-level) matrices, if zone names are applied to rows in the
“basic” square matrix (see 10.2.4) it is generally assumed that the same zone
names will be applied to upper levels as well, although this is not mandatory. For
example, if the row names are identical to sequential row numbers then this would
not be the case.
10.2.3 Matrix Dimensions and Units

Since it is expected that SATURN matrices will include a large number of different
“types” of matrices, e.g., trip matrices, distance matrices, cost matrices, it is very
useful for the user to define the sort of elements held in the matrix file. For
example it makes the output much more legible when totals from a trip matrix are
clearly marked “trips”, costs are shown as being in pounds, etc. etc. This is done
within SATURN by defining a series of “parameters” which specify the elements
stored on each matrix file.
Thus we store information on:
♦ the “dimensions” of the elements, e.g., whether they are times, distances,
costs, etc.;
♦ their “units”, e.g., minutes, miles, pounds, etc.

These are either defined on the input data files (10.5.1) as up to 8 characters or
may be interactively defined within MX (under Matrix Manipulation 10.8 or UFM
Output 10.16.7).
10.2.4 Stacked Matrices: Levels and Blocks

Stacked matrices are special forms of matrix files in which, say, four square
matrices of size 20 by 20 are stored together as a single matrix file.
Stacking may take place either “vertically” or “horizontally”. Thus in the former
case the combined matrix would consist of 80 rows and 20 columns. Rows 1 to 20
correspond to matrix 1, 21 to 40 to matrix 2, etc. In the latter case the combined
matrix would consist of 20 rows and 80 columns such that columns 1-20 consist of
matrix 1, 21-40 matrix 2. These are illustrated in Figure 10.1a and 10.1b
respectively.
5120257 / Apr 15 10-6

Section 10
Figure 10.1 - Stacked matrices
We use the term “level” to refer to the different sub-matrices when stacked
vertically and “block” when stacked horizontally. We also use the term “base
matrix” to refer to the basic square matrix from which the levels and/or blocks are
built up and whose length/width dimension would normally correspond to the
number of zones in a corresponding network.
Stacked matrices by level are only used within the multiple user class assignment
options of SATURN so that the four matrices above might correspond to four
separate user classes. See Section 7.3.2 for further details.
Horizontally stacked matrices by block are used to represent multiple time periods
as used within SATURN's dynamic assignments (see 17.4.3).
At the moment it is not possible to stack by both levels and blocks at the same
time, e.g. to create a single trip matrix file which is both multiple user class and
multiple time period. But it will come!
For some operations in MX, e.g. displaying elements or row/column totals, it is
possible to optionally treat stacked matrices as though they were ‘interleaved’; i.e.
row 1 of level 1 is followed by row 1 of level 2 and row 1 of level 3 etc. etc. all
followed by the row 2’s. See 10.10.2.
N.B. Stacking by blocks was introduced in SATURN 10; previous versions may
only employ levels.
See Section 10.20 for various useful standard procedures (e.g., MXSTACK,
UNSTACK, etc.) for manipulating stacked matrices.
5120257 / Apr 15 10-7

Section 10
10.2.5 Zonal Aggregations: Groups, Sectors, Traffic Boroughs etc.

It is very often convenient with matrices based on zones (of which there can be
very many) to represent them using “aggregated” spatial areas. For example, with
a national model one might wish to combine all zones within a county into a single
spatial entity in order to obtain matrices where each cell corresponds to county-to-
county movements.
Most commonly aggregation is based on geographically self-contained areas for
which several standard terms may be applied. Thus we use “groups” as the most
general terms but “sectors”, “traffic boroughs”, and ”districts” are commonly used
as well with certain general assumptions as to their size. Thus sectors are
generally very large – and few in number – whereas at the other extreme districts
may contain, say, only 4 or 5 zones each.
Very often the different aggregates may sit inside one another, like Russian dolls,
although this is not essential. Thus a group of adjacent zones might be
aggregated into districts, adjacent districts into boroughs and adjacent boroughs
into sectors.
However aggregates of zones need not be entirely spatial; one might also wish to
define groups based on common characteristics, e.g., all zones which are
predominantly industrial, all high household income zones, etc. etc.
The following sections described the properties generally ascribed to groups,
sectors etc. followed by a discussion of how the “mapping” from one level to
another is set within SATURN.
10.2.5.2 Groups
“Group” is the most general term applied to any user-set aggregation of zones and
may be used at any level of aggregation; e.g., 5,000 zones could be aggregated
into 5 groups or 500 into 250.
As with nodes and zones, groups have numerical “names” which need not be
sequential although in some applications there may be an upper limit, e.g., 999,
on the maximum group name. Again, as with nodes and zones, a “proper” group
cannot have a name of zero, although if a zone has not been allocated to an
explicit group then it is assigned to group 0 – which in certain applications will
result in a fatal error.
10.2.5.3 Sectors
Sectors play a very traditional role within SATURN and have fairly restricted
properties. They represent a very high level of zonal aggregation as described in
section 5.1.7 such that the maximum number of zones is 20 (or, strictly 21 since
sector 0 is regarded as a valid sector number unlike nodes, zones, groups etc.)
Sectors are common to both matrices and networks.
Like the alphanumeric zone names sector definitions may be obtained
“externally” from either:
an associated GIS file (see Block 8, App. Z),
5120257 / Apr 15 10-8

Section 10
a network .ufs file (see 6.8),

an explicit “zone-to-sector” (.Z2S) file (10.2.5.5 below),
“hierarchy” rules based on either TfL conventions or by a parameter IROCKY (see
5.1.7 and Table 10.1 in 10.5.2 below), or
alternatively, set within MX using a sub-option of the Files menu.
Generally speaking the number of sectors should be small enough that the entire
sector-to-sector matrix may be viewed within a single screen or page so that an
intuitive “feel” for the matrix may be obtained. Looking at individual cells in, say, a
200 x 200 matrix provides very little useful information.
Most options within MX may be applied either at the basic zone-to-zone cell level
or - provided that sectors have been defined - at the sector-to-sector level.
At present only one set of sector definitions is allowable within MX at any one
time, i.e. multiple “groups” are not allowed. They could however be handled,
somewhat awkwardly, by creating more than one GIS file which defines the
sectors (10.3.3) and swapping between them.
10.2.5.4 Traffic Boroughs

Traffic Boroughs – or simply boroughs – are largely a London-based concept
where traditionally the administrative boroughs within and around London may
have been split into one or two traffic boroughs (eg Wandsworth within Central
London, separated from the rest of Wandsworth), with further definitions for areas
outside London being aggregates of (non-London) boroughs (e.g., the whole of
the North of England and Scotland might constitute a single traffic borough).
Within the current TfL (Transport for London) SATURN models, there are currently
45 boroughs numbered sequentially from 1 to 45, with numbers 1 to 33
representing the 33 administrative sub-areas of Greater London on a one-to-one
basis (no splits), 34 to 40 adjacent or near counties, and the rest large regions
further afield.
N.B. Like groups there should be no borough 0.
10.2.5.5 Z2G (Zone to Group) etc. Mapping Files

A set of filename conventions has been drawn up in order to identify ASCII text
files which define the “mapping” of one set of zonal aggregates into another. Thus
a file with extension .Z2G will contain data which specifies which Groups are to be
associated with each Zone, .Z2S maps Zones into Sectors, G2S maps groups into
sectors, etc. etc.
The following letters may be used: Z for zones, D for districts, B for boroughs and
S for sectors (plus, more generally, N for node where the files are being used in
networks as in FILN2G; see 5.1.7). In addition T represents “text” so that a .G2T
file would consist of a series of group names followed by a text description of that
group; e.g., “1 Otley”.
All such files (except the "to text" .?2T files) have the same general, very simple
format described as follows:
5120257 / Apr 15 10-9

Section 10
They consist of a series of text records (terminated by a 99999 record) where

each record consists of two integers in free format (i.e., including CSV) specifying
a zone followed by its group (where we use the terms “zone” and “group” to
denote the first and second quantities as in a Z2G file but the same specifications
apply equally to all such files).
Note that numerical “names” must always be used for both the zone and the
group - not sequential numbers (although very often names are in fact
sequential).
Records need not be in numerical order of zones, i.e., the first number given does
not have to be always increasing, although this is generally the most convenient
way to create such files.
Duplication (i.e., assigning the same zone to two different groups) is not allowed
(although it may not always be checked).
A hyphen in front of a zone name (negative numbers) may be used to indicate a
“range” of zones. Thus two successive records:
9 1
-19 2
would indicate that all zone names in the range 10 through 19 would be assigned
to group 2 (and that zone 9 would be assigned to group 1).
Note that 19 need not necessarily be a valid zone name itself, it simply represents
an upper limit, in which case the “true” upper limit would be the maximum zone
name lower than 19. The lower value of the range is the previous upper limit plus
one. If a negative number is used to indicate an interval the absolute value of the
negative number must be greater than the absolute of the previous number in the
list. If, as above, a positive number is used (e.g., 9) to set the previous line that
zone name must exist.
Therefore it is recommended that you use either all intervals (negative numbers)
or include all zone names in the Z2* file using the philosophy that the point of
using intervals is for the process not to fail and the point of using a zone by zone
list is that you want the process to warn you about missing elements by failing.
Errors occur and are noted if a record does not consist of two integers, if a zone
cannot be identified (excluding negative values above) and if some zones are not
assigned to groups. These may or may not result in the operation being rejected.
Blank records are allowed and ignored as are comments, i.e., records with a * in
column 1.
In order to process a Z2G file the zone names (and their number) must already be
known within MX but the set of group names and their total number are only
known and fully specified after the Z2G file has been processed.
Note that the Z2G format also corresponds to a simplified version of the
Records 2 used by the batch file MXM5; see Appendix W.3.
5120257 / Apr 15 10-10

Section 10
10.2.5.6 Z2G Data within .UFM Files

Once a .Z2G file has been set and processed data such as the zone-to-group
mappings, the names of the groups etc. are included within the header records of
any output .UFM files such that any future applications of those .UFM files will
allow immediate access to the zone-to-group information which in turn allows
certain operations such as aggregation to groups to be carried out automatically.
See, for example, MXZ2G, section 10.20.22.
10.2.6 Z2G etc. Filenames, Extensions and Folders

It is clearly simplest if a file containing zone-to-group mappings has an extension
.Z2G to indicate its function and if a Z2G filename is given (e.g. on a command
line) without an extension .Z2G will be added automatically. However, for
example, a namelist parameter record “FILZ2G = ‘my_z2g_file.dat’” is perfectly
acceptable. And “FILZ2G = ‘my_z2g_file’” would have .Z2G added,
A .Z2S file may be defined by the parameter FILZ2S in a matrix .dat file (see
10.5.2) as may a Z2G file via FILZ2G so that these filenames are then embedded
within the .UFM files and need not be redefined when needed. All other files,
however, would need to be user-set when and as required.
As a matter of good practice and common sense, it is proposed – although this is
not a rigid requirement in SATURN – that all Z2G etc. files should (a) have the
same “root” filename and (b) be stored in the same folder. In other words, files
such as mapping.z2g, mapping.z2s, mapping.g2s, etc. would all be stored in the
same folder and therefore have a common root pathname as well as a common
filename. The advantage of this is that the user need not define all the possible
mapping files since a SATURN program could logically infer a file/path name
when necessary.
In particular this facility is routinely used with text descriptor files of the form .G2T
whereby if the predicted file mapping.g2t can be found it is used to add text
names to groups; if not group text names are simply ignored.
10.2.7 Matrix Title

Every .ufm matrix file has a text title of up to 76 characters associated with it.
Generally speaking this is defined by the user at creation (e.g. record 4 under
10.5.1) although in some circumstances the title will be created automatically
using “standard” titles; e.g. when two matrices are added together the title might
be “2 matrices added together”!
10.3 MX File Structure
10.3.1 Matrix Files

The matrix files in MX can be divided into three components:
1) One or more (maximum 10) input .UFM files stored in the “external”
memory, i.e., on the “hard disk”;
2) An “internal” matrix stored entirely in core memory (RAM);
5120257 / Apr 15 10-11

Section 10
3) A single output .UFM matrix copied (at the user's request) from the internal
matrix to the “hard disk”.
These are illustrated in Figure 10.2 where the external files used for input are
denoted X1, X2, etc. up to Xn, the matrix in internal memory is denoted by Y and
the output matrix is Z. Thus, for example, two input matrices X1 and X2 may be
added to create a new internal matrix Y which is then “dumped” to the output file
Z. See 10.8.1.
By default, when one or more .ufm files are input, then initially the first input matrix
is copied directly into the internal RAM. Thus the command “MX mat” would
cause the matrix file mat.ufm to be read into the internal memory.
“Changes” are applied only to the internal matrix whereas the majority of “viewing”
or “analysis” operations can use both internal and external files.
10.3.2 Control Files

In addition to the matrix files described above certain options within MX may make
use of external input data and/or control files, e.g. to define the row and/or column
totals to Furness a trip matrix. While this data may be defined interactively it is
very often easier for the user to prepare large data sets “off line” with an editing
program. External data sets once created may be used for repeated operations of
the same program.
In a slightly different sense the MX preferences file, MX0.DAT, may also be
viewed as a control file. A new version may be created from within the Files
Menu.
Figure 10.2 - MX File Structure
Note that a single run of the program may use more than one input control file -
each file is “opened” and “closed” as and when needed by the program. Equally
the input .UFM files are not fixed and may be redefined during a run and more
than one output file may be created (but at any one time only one exists).
10.3.3 “Other” Input Files

MX also allows the user (via the Files Menu) to define as an input a network .ufs
or a .gis file (5.7) which may provide useful extra zonal information on the matrix
5120257 / Apr 15 10-12

Section 10
(matrices) being examined. Thus either may supply the necessary sector
definitions which (see 5.1.7 or 10.2.5.3) are originally set within the node co-
ordinate data sets on a network .dat file or the .gis file. Equally text names for
zones are only given within gis files.
A further application of an input network file is to define the zone “names” (see
10.2.2) when they have not been predefined as part of an input .ufm file. This
option is particularly useful when the matrix is being input from a .dat file and the
zone names are not known a priori (see 10.5). Post 11.1 the zone names are
applied to rows within all levels of a stacked matrix (previously they were only
applied to rows in the base matrix).
Alternatively, to transfer network zone names into a matrix: (1), read the matrix
into MX so that it becomes the internal matrix, (2) input the network .ufs file, (3)
choose to transfer the network zone names into the internal matrix (if the network
has the same names the choice is never presented) and (4), dump the internal
matrix into a .ufm file.
10.3.4 Output Data Files

Certain options allow data (in relatively large quantities) to be “dumped” to
external ascii files created by the program. For example row and column totals
may be dumped in this way or the entire matrix cell by cell. Various “formats”, e.g.
the style required by spreadsheets such as EXCEL, may be selected.
Generally speaking the output ascii files are assigned the extension .kp by default
(as set by the Namelist Parameter KPEXT in SAT10KEY.DAT; see Appendix Y)
although, for subsequent inputs, they may need to be re-christened as .dat files.
Note, however, that the default value of KPEXT, and therefore the default
extensions used within MX, may be user-set either within SAT10KEY or the
Preferences File MX0.DAT. Post 10.7 it is conventional to set the default
extension to .txt within SAT10KEY.DAT.
10.3.5 The Output .LPX File

As with other SATURN programs an output “line printer” file is continuously
produced in order to (a) keep a permanent record of “useful” screen output and (b)
store outputs which are too lengthy to conveniently output to the screen.
10.4 Copy/Transpose/Re-code an Input UFM File; Re-defining Zones

These options allow one to read an external .ufm file into the internal matrix, either
(i) “as is”
(ii) as its transpose (T ij becomes T ji )
(iii) as a compressed/expanded/recoded matrix whereby zones are transformed
(iv) as an aggregated version of a stacked input matrix (i.e., with all levels
summed to create a single square matrix)
(v) as a single level from an input stacked matrix
5120257 / Apr 15 10-13

Section 10
(vi) by “pasting” an external square matrix into a single level of an internal

stacked matrix
Some, but not all, of these options may also be applied to the internal matrix. In
effect the internal matrix is first copied to a “scratch” external matrix, from which
the internal matrix is re-created according to the various options above.
Options (i) and (ii) are self-explanatory; indeed case i) is what happens
automatically when one or more input .ufm matrix files are initially defined in a run
of MX; see 10.3.1.
Case (iii) requires further explanation since it is the main mechanism within MX by
which the structure of the zones may be “edited”, i.e. the number of rows and
columns may be altered as opposed to “editing” individual cells. It also differs
from, i) and ii) in that the changes may be applied to each level of a stacked
matrix whereas the first two methods apply only to “square” matrices.
Cases (iv) to (vi) apply to various operations involving stacked matrices as
described in more detail below, Section 10.4.3.
10.4.2 General Zonal Editing

Zonal editing must (generally) start with an external .ufm file which, once the
mapping of old zones into new has been fully defined, is copied into the
appropriate cells of the new internal matrix. It is, however, also possible to edit
the internal matrix “in situ”, in which case the program automatically copies the
internal matrix into temporary external .ufm file, from whence it is recopied/edited
into the new internal matrix.
Thus, with respect to the original zone definitions on the input .ufm file, the new
matrix may:
1) delete old zones (in both rows and columns);
2) create totally new zones (whose sequential position is determined by their
“name”);
3) compress the existing zones into larger zones (i.e. aggregate or add zones
together);
4) rename existing zones (and therefore potentially change their sequential
position);
5) split (i.e. disaggregate) and/or copy old zones into new zones
In greater detail these five sets of fundamental operations may be described as
follows:
1) Deletion is straightforward - both the row and the column corresponding to
the zone selected are removed. Alternatively a range of zones, e.g. all
external zones, may be removed.
2) New zones are added in the rows/columns corresponding to the sequential
position of the new zone numbers. The cell values to be inserted in these
elements may be either defined uniformly by row and column (e.g. set all
row elements to 1 and all column elements to 2) or they may be copied
5120257 / Apr 15 10-14

Section 10
(and/or factored) from an existing zone’s row and column cells. Thus you
may create a new zone in a trip matrix which “looks like” an existing zone or,
under “copy”, the new elements may be the sum of multiple zones, an
average of multiple zones or a weighted sum of multiple zones. Alternatively,
the cell values in the new rows and/or columns may be set either (a) from an
external data source via the “update options” described in Section 10.5.1.2,
(b) via matrix manipulation equations (to selected rows/columns, 10.8.2)
described in 10.8.1 or (c) by screen editing (10.10.4).
3) Compression aggregates two or more existing zones (i.e. rows and
columns) into a single larger zone (“many to one”) by adding cell elements
together whereas renaming basically copies one zone into another with a
different name (“one to one”). Since compression is essentially similar to
that of defining sectors to be aggregates of zones it may sometimes be more
convenient to perform this step via sector definition; for example, with
sectors it is possible to view both the zonal and the sectoral matrices within
the same run.
4) The zones to be compressed may either be in a block of sequential zone
numbers (e.g. zones 4, 5, 6 and 7) or “mixed” (e.g. zones 1, 5, 7 and 8).
They may either be aggregated into a zone with a completely new number
(e.g. zones 4 to 7 go into zone 40) or an existing zone (e.g. zones 4 to 7 all
go into zone 4, in which case the original zone 4 effectively stays where it
was).
Renaming is straight forward - the row and column elements are moved to
the new sequential positions. In effect “renaming” is an alternative form of
compression, the difference being that with renaming a single zone is
converted into another single zone; with compression several zones are
converted into one. Renaming and compression are therefore included
within the same menu structure with the first two (many into one) being
effectively compression and the next two (one into one) being effectively
renaming.
5) The “Split” function may be used to divide a single zone into a set of 2 or
more sub-zones with separate factors by row and column. Normally at the
end of the process the old zone has been deleted. However the new sub-
zones may in fact contain the original zone number, so that this function
effectively duplicates renaming - split a zone 100% into a different zone -
and copying - split a zone 100% into itself and 100% into the new zone. Use
whichever seems most convenient. Note that certain options plus factors
leave the total number of elements in the matrix unchanged so that these
operations are suitable for matrices such as trip matrices but probably not
for matrices such as distance matrices where, if a block of zones were to be
aggregated together, one would wish to average the cell elements, not add
them together. Thus if you wanted to aggregate four zones from a trip
matrix choose factors of 1.0; if it were a distance matrix choose 0.25.
To a large extent the above functions mirror those available under “M5” (see
Section 10.16.3) and as a distinct batch file MXM5 (see 10.20.20) which dump the
internal matrix to an output .ufm file. Thus to aggregate a matrix from zones into,
say, “districts” one could either aggregate on input (as here) and produce a new
.ufm by simple output, or else read in the zonal matrix and aggregate to districts
5120257 / Apr 15 10-15

Section 10
on output. One difference is that the input options use only interactive input
commands whereas the outputs use control files. (Although through the use of
key files both can be run equally well in a purely batch mode.)
From version 10.7 it is possible to save the instructions input interactively (e.g.,
which zones to copy, which to delete, etc.) in the form of a “control file” as
required by the MXM5 procedure; see 10.20.20 and Appendix W.3.
10.4.3 Editing Stacked Matrices

If either the input .ufm matrix or the internal matrix (assuming it has already been
created) are “stacked”, i.e., contain multiple levels of a basic square matrix (see
10.2.4), then various additional operations become possible.
Thus, firstly, a square internal matrix may be created by summing together all the
various sub-matrices contained in the stacked .ufm matrix file. (The same
operation may also be carried out using an external procedure mxagg; See
10.20.21.)
Secondly, and similarly, a square internal matrix may be created from a single
level of the input stacked .ufm file.
Thirdly, if the internal file is a stacked matrix but the nominated input .ufm matrix is
square, that matrix may be used to “over-write” or “paste” a particular internal sub-
matrix (without any changes being made to any of the other sub-matrices). The
paste operation may often be usefully combined with the “cut” operation (see
10.16.6) whereby a square matrix is extracted from a stacked matrix, edited in
some fashion and then pasted back into the original matrix.
10.4.4 Pure Zonal Aggregation (Compression) into Groups

A matrix which is defined in terms of zone-to-zone cells may be “compressed” (or
“aggregated”) into a matrix of group-to-group cells by adding together all the
appropriate zonal cells. Mathematically:
𝑇𝐼𝐽 = � � 𝑇𝑖𝑗
𝑖∈𝐼 𝑗∈𝐽
where I and J represent the rows and columns of an aggregated matrix, i and j are
zonal rows and columns and i ∈ I denotes the fact that zone i is contained within
group I.
Note that this form of aggregation is appropriate for, say, a matrix of trips where it
is natural to add trips together but it would not be appropriate to a matrix of, say,
zone to zone distances where ideally the group-to-group distance should be some
form of weighted average of the zone-to-zone distances.
The rules for compression/aggregation may be specified via a number of different
formats: (1) an explicit mapping of zones into groups, (2) hierarchical numerical
rules and (3) specific TfL numbering conventions for traffic boroughs. These are
described in further detail below.
The conversion from zones into groups may be either set explicitly by an external
“Z2G” file or by pre-defined zone-to-group data.
5120257 / Apr 15 10-16

Section 10
Hierarchical aggregation uses two parameters, NBASE and IROCKY, to create

new aggregated zones based on the current set of zone names by applying the
formula: “new” = NBASE + old/IROCKY. Generally speaking IROCKY will be 10 or
some power of ten on the basis that the first digit in a zone name equals a “sector”
of some sort. NBASE, generally 1, is included so that a new zone name of zero is
not permitted (whereas the very similar use of IROCKY to define sectors explicitly
does not use NBASE since a sector 0 is permitted).
The specific aggregation of a TfL SATURN matrix from zones to traffic boroughs
follows the rules used by TfL (see 5.1.7.2) to include the definition of a traffic
borough within a zone number, specifically using the first two digits.
Note that the MXZ2G (and similar) does include any intra-zonal trips in the
aggregation.
10.4.5 Expanding a Matrix (Groups to Zones)

A matrix which has previously been compressed from zones into, say, groups may
be transformed back into a zonal matrix but with very specific rules which differ
from the rules applied for compression or aggregation (10.4.4).
Thus under compression zonal cells are added to create group cells; by contrast
under expansion all zone-to-zone cells take the same corresponding group-to-
group cell value, i.e. group-to-group values are replicated. Mathematically:
𝑇𝑖𝑗 = 𝑇𝐼𝐽 ∀ i∈I, j∈J, i≠j
𝑇𝑖𝑗 = 0 ∀ i=j
This could logically be applied to a matrix of, say, OD costs or factors but not to a
trip matrix where the group-to-group trips would need to be factored down when
disaggregated to a zonal level.
Note that MXG2Z sets the intra-zonal trips to zero. This may have implications in
later calculations if your original zonal matrix had values in the intra-zonals as
MXZ2G would have included these in any intra-sector totals.
10.4.6 Reboot: Returning to the Original Matrix

If the zone structure has been transformed using any of the above options then
the original matrix/matrices are effectively “lost” having been replaced by the new
structure. The reboot command allows the original command line to be re-
processed and the original matrix/matrices to be restored (at the cost of losing the
“new” restructured matrix data).
The idea is that if you input a zonal matrix and then compress it to a group matrix
(10.4.4) in order to “view” the matrix in terms of group-to-group you may return to
the original zone-to-zone version. This therefore gets around a “feature” of MX
whereby you cannot store a zonal matrix and a group matrix in internal memory at
the same time; now you may swap between them.
(By contrast sector-to-sector versions of the basic matrix may be stored at the
same time as the full version and both may be viewed within the same program;
however there are severe restrictions on the size of sectors.)
5120257 / Apr 15 10-17

Section 10
10.5 Matrix Input and/or Updating from a .DAT File

The internal matrix may be built in whole or in part (see Updates below) by
reading data from an input ASCII data file (for which the default extension is .dat).
The input .dat file must be ‘formatted’ with a set of possible options ranging from
the traditional SATURN format as described in 10.5.1 to a set of newer, more
flexible, formats where, to a certain extent, the users may define their own format.
The latter facility is intended to simplify the transfer of matrix data from other
suites of programs such as EXCEL into SATURN.
The format selection is made from the following choices:
♦ Standard SATURN-formatted input file
♦ User-defined format (with all O-D data included)
♦ Non-zero elements only with I-J indicators (one record per cell)
♦ Spreadsheet or Comma Separated (CSV) Format (one record per row)
♦ EMME/2 Format
♦ Tuba Formats 1, 2 and 3

These are defined more precisely in Sections 10.5.1 to 10.5.6 respectively and
correspond closely to the “dump” formats in 10.15.
A further option allows the user to have a preliminary look at the input file prior to
selecting a format option or defining sub-options.
Note that these options are part of the standard interactive matrix building
procedures within MX whereby an input data file is nominated, various options are
selected and subsequently an output .ufm file is created as described in 10.16.
Alternatively .ufm matrices can be built from data files using the more “batch-
like” procedure MXM1 as described in section 4. Note, however, that the
formats of the input data files – 1) to 6) above - are the same in both cases.
We may further note that, if an “all-new” matrix is to be built interactively from data
inputs (i.e., without any existing .ufm matrices being involved), then it will be
necessary to initiate a run of MX using the command line:
MX I
which (see 10.1) calls $mx.exe without a (normal) initial matrix.
10.5.1.1 The Numbers of Rows and/or Columns

Before matrix cells can be input it is necessary to know in advance the number of
rows and columns (generally the same) in the matrix so that the values can be
stored in their correct cell positions as they are read in. A similar problem is to
establish the zonal names in advance – see below.
With SATURN formats (1 above) this information is contained in the initial
Namelist records (see 10.5.1). With other formats this information must be
supplied interactively by the user (in some cases a “pre-read” of the data file
establishes the “names”; see below).
5120257 / Apr 15 10-18

Section 10
10.5.1.2 Updates
It is also possible to use input from an ascii file to “update” all or part of the current
internal matrix (presumably read from an existing .ufm matrix) rather than writing it
“from scratch”. The choice between “build” and “update” is made immediately on
entering the top menu under Build/Update.
Matrix update data may use only some of the standard data input format
conventions described below; i.e., user-defined records (10.5.3), individual cell
records (10.5.4) and spreadsheets (10.5.5). Thus the standard SATURN format is
not available as an update option since, by construction, it must contain all cell
values.
The data set read need not contain all ij cell values but may be only a subset
which, in the case of user-defined and spreadsheet formats, must constitute a
“rectangle” within the matrix as defined by upper and lower row and column
numbers.
An update may either “replace” the existing cell value by the value which is read in
or “increment” it (i.e., add the existing and the input cell values together).
An advantage of updating an existing .ufm matrix rather than creating one totally
from scratch is that with updates the number of rows and columns plus any
“names” (see below) are pre-defined, only (certain) cell values are set.
10.5.1.3 Sequential / Numerical Zone Names

The data read from an input .dat file may be based on either sequential or
numerical zone names (10.2.2) or indeed both as is the case with the standard
SATURN - formatted data files (10.5.1). With other formats (e.g. spread-sheet,
10.5.5) there is no explicit mention of either row or column numbers but they are
implied by the position of the entry within the data file.
Note that in certain cases it may be possible to “pre-define” the numerical zone
numbers before reading in the .dat file. Thus if the .dat file updates an existing
input .ufm matrix the zone names will already have been obtained from the .ufm
file. Alternatively the names may be obtained from a corresponding network .ufs
file (10.3.3). If the names are pre-defined this allows the input .dat file to use
those names instead of sequential numbers which may be more convenient for
the users.
Within 3) and 5) above it is possible to establish the zone names by carrying out a
preliminary “pre-pass” through the .dat file.
10.5.1.4 Matrix Units

In converting matrices from one suite into another it is important to remember that
different suites may have different conventions as regards units. In particular
recall that SATURN prefers to define trip matrices in units of pcus/hr whereas
other suites may use vehicles/hr. Thus it may be necessary, having read an input
data file into MX, to undertake some further factoring to correct for units. Cost
matrices, which might be in monetary units or generalised time units, are another
case in point.
5120257 / Apr 15 10-19

Section 10
10.5.2 Standard (SATURN) Format Matrix Data Files

MX can read in a trip matrix from a “standard” ascii .dat file using a standard
format described formally in Section 4. The detailed specification is as follows:
1) RUN CARD (Optional)
Cols. 1 - 3 ‘RUN’
Cols. 5 - 80 A title associated with the run.
If omitted a default run name is used.
2) NAMELIST PARAMETERS (&PARAM) (Mandatory)
See appendix A for a description of Namelist input.
Table 10.1 – Namelist Parameters
Parameter Type Default Interpretation
NROWS INTEGER 0 Defines the size of the matrix to be built
NCOLS INTEGER 0 Defines the size of the matrix to be built

KROPT INTEGER 1 Defines the formats for the matrix elements,
records 5) below. 1 signifies SATURN
formats, either “long” or “short”. See 4.4 for
the (currently limited) alternatives: 4 for CSV
and 6 for TUBA 1.
IROCKY INTEGER 0 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.
LONG LOGICAL F T – The ‘long’ input formats apply- see ‘the
matrix element’ records below
MPNEXT LOGICAL F T – Matrix parameters are given on the

following record
TFL LOGICAL F T - The rules for hierarchical node and zone
numbers as used in TfL networks are
assumed to operate. E.g., the first digit in a 4-
digit zone number gives its sector. See
5.1.7.2 and 6.8
GISFIL TEXT ‘’ The filename of the GIS file associated with
this matrix (5.7)
FILZ2S TEXT Blank The filename of a file listing the sectors per
zone; see 10.2.5.3.
FILZ2G TEXT Blank The filename listing groups per zone (see
10.2.5.5).
3) THE “MATRIX PARAMETER” RECORD (optional - MPNEXT=T)
5120257 / Apr 15 10-20

Section 10
Cols. 1 - 8 - The “units” of the matrix elements; e.g., time

Cols. 9 - 16 - The “dimensions” of the elements, e.g. minutes
(See Section 10.2.3 for a more complete explanation of these terms. If MPNEXT
is .FALSE. they are set to blank by default.)
4) MATRIX TITLE RECORD (Mandatory)
Cols. 1 - 76 A title for the SATURN matrix; see 10.2.6
5) MATRIX ELEMENTS (Mandatory)
Two different “standard” input formats are allowed depending on the value of the
LOGICAL parameter LONG. (But, see 4.4, further “non-standard” alternatives also
exist, e.g., CSV.)
LONG = FALSE (its default): (FORMAT 15I5)
1ST CARD(S) - The “name” for row 1 in cols. 1 to 5, followed by the NCOLS
elements in cols. 6-10, 11-15, etc., using the subsequent cards as necessary.
Thus the first record contains the name plus 14 elements, the second record
contains elements 15-29 with the 15th element in cols. 1-5.
2ND CARD(S) - As above for the second row. Etc..Etc..
(b) LONG = TRUE:
1st CARD(S) - The ‘name’ for row 1 in cols. 1 to 5, followed by the NCOLS
elements in cols. 6 - 15, 16 - 25, ... up to column 75, starting with cols. 6 - 15 on
any subsequent records, written as F10.3; i.e., the decimal points must (normally)
lie in columns 12, 22,...62.
2nd CARD(S) - As above for the second row. Etc..etc..
In either case the ‘names’ must be in strictly increasing order, but not necessarily
sequential; see Section 10.2.2.
END OF THE DATA INPUT
10.5.3 User-Defined Format Matrix Data Files; All O-D Elements

N.B. This option is rarely used.
Under non-standard input but with all O-D elements included, data must be
ordered by destination within origin; i.e., a complete set of destination data for
origin 1 on one or more records, followed by the records for origin 2, etc., etc. All
NROWS*NCOLS elements must be included. User-set sub-options allow:
a) A fixed number of initial records to be skipped before origin 1 data,
e.g., to allow for header records;
b) A fixed number of initial numerical data entries within each origin set
to be skipped, e.g., to allow for zone names, purpose codes, etc.
c) A FORTRAN-style Format of the origin data sets, e.g., 10I5 for 10
INTEGER data entries per record, 5 columns each.
5120257 / Apr 15 10-21

Section 10
d) The number of rows and columns (i.e., zones) if not already specified.
An example of such a data file with two header records, 8 rows and a single
column header entry per origin and format 6I5 might be:
Jonesville observed trips
15 January 1993
5 0 6 2 3 1
0 1 5
10 6 0 2 3 1
0 1 5
…
Thus the first zone is zone 5 with I-j elements (0.6…5), the second is zone 10 with
elements 6, 0…5). Whether or not the numerical entries are “real” or not (i.e.
have decimals or not) is determined by the format which follows standard
FORTRAN rules.
10.5.4 Non-zero matrix elements only, one O-D cell per record
*
Here each non-zero O-D entry occupies a single line or record giving some
(possibly all) of the following:
(i) sequential row and column numbers;
(ii) low and column zone names;
(iii) the matrix level (in the case of a stacked matrix);
(iv) the block (if stacked by blocks);
(v) the cell value.
Of these either i) and ii) (or both) are mandatory, iii) and iv) are generally not used
and v) is mandatory. Choices for the contents are defined interactively by the
user prior to input.
The records may either be read “formatted” (i.e. in pre-defined fixed columns) or
“free format/CSV” (i.e. with each record separated from its neighbours by one or
more spaces and/or commas). Note that fixed column data may also be read as
though it were free format (provided that there is always at least one space
between adjacent entries) but the converse is not true. It is strongly recommended
that the free format input option is selected. (With 10.6 it is now the default.)
Note that the form and contents of the input data must be fully and correctly
specified by the user interactively prior to reading in the data, otherwise input
errors will almost certainly result.
*
Although, optionally, more than one record per ij pair may appear and the inputs are added
together. This may be useful for, eg aggregating survey data.
5120257 / Apr 15 10-22

Section 10
For the moment header records, etc. cannot be explicitly included with single
records although, if they do appear, they will cause non-fatal read errors which do
not affect the final output matrix.
10.5.4.1 Free Format / CSV Inputs

Under CSV format with only items i) and v) included, the data might consist, for
example, of records:
1,2,12.0
1,3,13.0
3,2,32.0
…
Indicating that cell (1,2) has a value 12.0, etc. etc. Alternatively, using spaces and
fixed columns, the same data might appear as:
1 2 12.0
1 3 13.0
…
And both data sets could be happily read as “free format”. Note that in this case
we are assuming that only sequential row and column numbers are given, not
their zone names (i.e., i) above but not ii)).
Alternatively, if the zone names for sequential zones 1,2,3 were 10,20,30, then
only names, not sequential numbers, (method ii) could be used, as in:
10,20,12.0
10,30,13.0
30,20,32.0
…
Finally, belt and braces, both sequential and zone names could be used as in:
1,2,10,20,12.0
1,3,10,30,13.0
3,2,30,20,32.0
…
Clearly in this case one would have to be careful that a sequential 1 was always
followed by the “name” 10 (whether input as a row or a column).
10.5.4.2 Formatted Inputs

Under formatted input (to repeat, NOT RECOMMENDED) three standard options are
provided with default formats as follows:
Options Format:
1. SEQUENTIAL ROWS AND COLUMNS ONLY 2I5, FI5
2. NAMED ROWS AND COLUMNS ONLY 2I6, FI5.6
3. BOTH SEQUENTIAL AND NAMED ZONES 2I5, 2I6, F15.6
For example under option 2 a line:
5120257 / Apr 15 10-23

Section 10
11 22 6.00
would imply a cell element of 6.00 for row (origin) 11 and column (destination) 22,
both 11 and 22 being zone “names” which would need to be converted into
sequential numbers.
Under option 1 the same line would imply the cell would be the 22nd column in the
11th row without any reference to the associated zone names.
Under option 3 the same cell might be specified by:
11 22 61 94 6.000000
where sequential row 11 is zone 61 and sequential column 22 is zone 94. This
method clearly requires “internal consistency” such that sequential row/column 11
is always associated with zone 61 etc.
10.5.4.3 Reading a Stacked Matrix by Single Records

A stacked matrix (10.2.4) be input via single records by either explicitly using the
correct sequential row number or by including both the name of the O-D zones
and the level. The input format must, however, be free-format.
For example, if a network of 100 zones has a trip matrix with three purposes (i.e.,
levels) then the sequential row numbers in the stacked matrix would go from 1 to
300. If the 5th and 6th sequential zones, say, had names 511 and 512 then an O-D
trip record of 23.6 trips from 511 to 512 for purpose/level 3, could, using purely
sequential notation, be written as:
215,6,23.4
Or, using both zone names plus a level, as:

5,6,3,23.4
However users may find it less complicated to input multiple-level trip matrices as
a series of simple square, one-purpose matrices created one at a time and then to
stack the resulting .ufm matrices into one large stacked matrix.
10.5.5 Spread-Sheet/CSV Format; One record per origin

A CSV (Comma Separated Variables) or spread-sheet format is defined to be one
where:
♦ There is one record per origin row containing n elements for each of n
columns (plus, optionally row and/or zone names; see below).
♦ Each cell value is separated by a ‘,’ from the next value.
♦ Cell values may be written as integers or with a variable number of decimal

places (see 10.15.2).
♦ No blanks (but see below).

Essentially the spreadsheet format is free format with commas rather than fixed
columns used to distinguish individual cell values. It is the format regularly used
5120257 / Apr 15 10-24

Section 10
by Windows programs such as EXCEL and therefore it is frequently used by

SATURN users to transfer files to and from EXCEL.
(N.B. Fixed column input files may be processed as CSV files as long as there is
at least one space between successive values, or both commas and/or spaces
may be used. However there may be certain instances where spaces are not
recognised as CSV-compatible so that the use of “pure” CSV formats is
recommended.)
Note that zero cell values must be included as must rows which are all zeros.
However, an input record may have fewer cells than the standard number of
columns, in which case the missing cells “on the right” default to zero.
If desired each record may contain either n+1 or n+2 elements by including the
sequential row number and/or the “name” of the zone at the start of each record to
assist in the identification of each row.
One potential technical problem with spreadsheet style formats is that, with all
elements per row held in a single record, the record length may become too long.
It is partly for this reason that, as discussed further in Section 10.15, a
spreadsheet file may contain only a subset of the columns which limits the size of
each record. In such cases the transfer of matrix data to and from external
programs must take place in stages, a necessary evil to overcome the problem of
record lengths.
Stacked matrix files may also be input using the CSV format (post 10.8), in which
case the user must first interactively define the number of rows, columns and
levels (where the number of columns equals the number of zones and the product
of columns/zones times levels should equal the number of rows). The
presumption is that the first N r records contain the first level, the second N r
records contain the second level, etc. etc.
If “zone names” are explicitly included on stacked CSV records they should be
identical within each level although, strictly speaking, they are ignored after the
first level has been read in. On the other hand sequential row numbers, if
contained, should go right the way through from 1 to the total number of rows.
N.B. CSV formats may also be used as inputs to MXM1; see 4.4.
10.5.6 EMME Format

EMME input formats follow the rules laid down by the package of that name for
“punched” output files and consist of (in our version at least):
♦ (variable) number of header records
♦ a set of cell records, each including values from a single origin (row) plus one
or more destinations (columns).
On input the header records are ignored by SATURN. They are identified by
having an alphabetic character (normally ‘c’, ‘a’, or ‘t’) in the first character
whereas the data records which follow may be identified by having blanks in their
first characters per record.
The cell records consist of:
5120257 / Apr 15 10-25

Section 10
♦ The row number/name (see below) in columns 1-5;
♦ Up to 10 pairs of numbers written as:

destination zone: cell value
For example:
1 2 : 76.2 3 : 0.8 5 : 16 ….
would define the cell values for ij pairs (1,2), (1,3), (1,5)…. Any “missing” values
(1,1), (1,4) etc would be assigned default values of zero. In addition spaces may
be allowed between the “:” and the cell values, and the cell values may be either
integer or real.
Note the zones may be referenced either by their sequential number or by their
numerical name (see 10.2.2) as an option selected by the user. The standard
EMME/2 default is to use zone names, not sequential numbers.
Due to EMME conventions only matrices which are “square” may be processed by
EMME; i.e., stacked matrices may not be created using an EMME format.).
10.5.7 TUBA Formats

Tuba input formats follow the rules laid down by the evaluation package TUBA
(see 15.41 and Appendix C of the TUBA User Manual) where three separate
formats are specified:
1) One record per origin, CSV;
2) One record per cell, CSV: Origin, Destination, Cell value;
3) One record per cell, fixed columns, user class plus multiple time periods.
Thus Tuba Format 1 is very similar to that of “CSV” described in Section 10.5.5
while 2 and 3 are similar to that in 10.5.4.
Note that Tuba Format 3 is presumably intended to deal with multiple time periods
whereas, as implemented in SATURN, only one cell value is generally output. It
may, therefore, not be much use as of yet to “serious” Tuba users but it could be
extended as and when required.
10.5.8 Creating a “Flat” Matrix

An option exists within MX to create a “flat” or “uniform” matrix, i.e. one in which all
cells have the same value.
This is done by entering the program in a purely interactive mode, i.e. with no
input .dat or .ufm file, most easily done by a command line:
MX I
The first menu, in addition to offering the option to define an input .dat or .ufm
matrix file, allows one to set a flat matrix with user-set numbers of rows and
columns
5120257 / Apr 15 10-26

Section 10
10.6 Select Options

Certain options within MX, for example matrix comparison or matrix manipulation
(10.8), operate either on the whole matrix or, optionally, on certain “selected” cells.
The select facility defines those cells.
Selection is based on:
♦ “Location”, e.g. select rows 1 to 5 and/or
♦ “Value”, e.g. select only those cells whose value is greater than 10.
10.6.1 Selection by Location

Location selection essentially defines a rectangular “area” defined by lower and
upper rows and/or lower and upper columns where everything in between is either
“in” or “out”. Alternatively if sectors have been defined the limits for both rows and
columns may be defined by sector numbers; e.g. you may select origins (rows) in
sector 1 to all destinations (columns) in sectors 2 to 6.
Post release 10.8 with “stacked” matrices (e.g., multiple user class matrices) the
“selected area” definitions may be further refined to either apply to all levels
separately or to a particular level. In these situations one has to be careful in
specifying areas to distinguish between sequential row/column numbers and zone
names.
Suppose, for example, that you have a basic 10x10 matrix with 3 levels so that the
full matrix has 30 rows and 10 columns, and that the zone names are simply 1 to
10. You might, using sequential numbers, select all rows from 5 to 25, even
though rows 5 and 25 both have the same zone “name”, i.e., 5, but clearly they
are in different levels. Alternatively you could define row limits by zone name,
e.g., zones 5 to 7, in which case this could either be applied to all levels to include
sequential rows 5 to 7, 15 to 17 and 25 to 27, or you could choose to apply it only
to a single level, e.g., level 2, rows 15 to 17 only.
In addition with levels it is possible to select either a single level in its entirety or
else a range of levels in their entirety. So that, in the above example, if you were
to select level 2 only this would be equivalent to selecting rows 11 through 20 but
with no further selection rules. I.e., if you select level 2 then there is no possibility
to add extra restrictions on columns.
A slightly different form of location definition is to select intrazonal or diagonal
cells.
Alternatively you may select cells “outside” the defined locations. For example
you may select an area, perform an operation on those cells only, return to Select
and “toggle” to select the outside cells and perform a different operation on those
cells.
10.6.2 Selection by Value

Selection by value requires the user to define:
♦ A matrix, which could be the internal matrix or an external .ufm file.
5120257 / Apr 15 10-27

Section 10
♦ An “operation”, e.g. “less than”, “greater than or equal” etc.
♦ A critical value.
Thus you could select cells in the second input trip matrix whose values are > 10.
Note that tests such as EQ or NE also imply equality within some plus/minus limits
which also need to be specified. The principles apply equally to link selection
within P1X or SATDB; see 11.6.1 for further details.
Note that selection by value is not “permanent” when applied to the internal
matrix. Thus if you select all internal matrix cells > 10.0, factor just those cells by
0.5, and then carry out another operation “with selection by value” the cells to be
selected in the second operation will be those whose current value is 10.0, i.e.
those cells who were originally > 20.0. In order to “fix” a selection by value using
the internal matrix you should copy it into a .ufm file (and add it as an input matrix)
and base your selection on that file so that the values do not change.
N.B. This is the opposite of link selection in SATDB, P1X etc where links, once
selected, are permanently “branded”.
10.6.3 Output of a Selected Matrix

Note that it is possible to create an output .ufm matrix (see 10.16.7) which records
the current state of cell selection. Thus (by default) an output value of 1 indicates
that that cell is selected, 0 that it is not. This may be useful as a means of creating
“fixed” or “frozen” matrices for input to SATALL or SATME2.
Note that the 0/1 definitions may optionally be reversed if desired such that non-
selection equals 1 and selection equals 0.
10.7 Matrix Factoring

Three general forms of matrix factoring are allowed and operate only on the
internal matrix:
1) Factoring Individual Cells within Selected Areas:
Tij = fTij
where f is a user-defined factor and the cells which are factored may either
constitute the entire matrix or a selected subset (i.e. an “area”)
2) Row or Column Specific Factoring:
Tij = AT
i ij
or
Tij = B jTij
where A i /B j are row/column specific factors set by the user.
5120257 / Apr 15 10-28

Section 10
3) Singly - or Doubly-Constrained Furnessing:
Tij = Ai B jTij
where the row and/or column balancing factors are chosen such that
∑T
i
ij = Dj
∑T
i
ij = Oi
where the row and column sums O i and D j are user input. (Under a singly -
constrained model only one set of constraints is applied as under 2); under doubly
- constrained, both are. Note that singly constrained Furnessing is effectively
equivalent to row/column factoring, the only difference being that the required trip
ends are defined under Furness as opposed to the trip end factors; e.g. O i as
opposed to O i / o i .)
All three forms are available through a combination of interactive commands
and/or data from external ascii control files. The choice of the form and the mode
of control is made both in the “top” menu within FACTOR and in the next sub-
menu; e.g. if you choose Furness at the top menu the choice of single/double
constraints and/or input mode is made at the next menu.
Note as well that, under doubly-constrained Furness, it is implicitly assumed that
the sum of all the row totals should equal the sum of all the column totals. If this
condition is not satisfied various options to correct are offered; e.g., factoring up
all row constraints so that they equal the column totals
Since factoring in transport applications is mostly applied to trip matrices the
documentation below refers for simplicity to ‘origins’ and ‘destinations’ and ‘trip
ends’ instead of ‘row totals’ or ‘column totals’, although the actual factoring
operations are applicable to any type of matrix.
10.7.1.1 Zero-sum Rows and/or Columns

Note that if a row and/or column of the matrix to be factored contains all zeros
then equally the factored matrix row/column will also be all zeros (under both
singly and doubly constrained).
However confusion may arise if a row/column contains a very small number of
very small valued cells (e.g., 0.0001). This may arise as a combination of rounding
errors or if one matrix is subtracted from another. The problem is that the
row/column sum may be printed as 0.00 (rounding down) which is therefore
difficult to distinguish from a “true” 0.00 and, in this case, the factored row/column
will not contain all zeros.
In release 10.9, (a), row/column sums less than 0.01 are printed with extra
decimal places (e.g., 0.000012 rather than 0.00) and, (b), warning messages are
printed under Furness to warn of very small row/column sums.
5120257 / Apr 15 10-29

Section 10
10.7.2 Selected Area Cell Factoring: Interactive Control

The user needs to define interactively:
♦ A factor
♦ An “area” of the matrix over which the factor is to be applied

where the area to be factored is defined via the SELECT procedures - see 10.6.
Note that the “area” may actually be defined in terms of cell values so that it need
not be a “block” of cells.
By default the selected area to be factored will be the entire matrix, so that in the
case of a stacked matrix all levels are included by default.
However a “short cut” select procedure may also be used with stacked matrices
whereby a single square “level” and/or “block” of the full matrix is directly pre-
selected to be factored, as opposed to the more long-winded but equivalent
process of explicitly identifying the row and column limits associated with a
specific level/block. Note that having nominated a particular sub-matrix the
selection may be further refined by setting, e.g., internal zone limits and/or cell
value conditions as “AND” conditions.
Note that a single level may equally be selected for factoring using the LEVEL
parameter in the batch file MXFACTOR; see 10.20.3.
10.7.3 Selected Area Cell Factoring: Input Control File

The Selected Area Factoring option within MX factors an area defined by an upper
and lower row (i.e., origin) plus a left-hand and right-hand column (i.e.,
destination) by a specific factor. They therefore define a “rectangular” sub-area
within the full matrix “square”. (And indeed it may help users to draw a “map” of
the matrix and its sub-areas, a bit like a Venn diagram, in order to help visualise
what is included in each sub-area, whether there are overlaps (allowed), etc. etc.)
The external control file defines areas plus factors formatted as follows, one
record per area to be factored:
Cols. 1- 5 Upper row
Cols. 6 - 10 Lower row
Cols. 11 - 15 Left-hand column
Cols. 16 - 20 Right-hand column
Cols. 21 - 30 Factor - decimal normally in column 28 (Format F10.2)
Certain options for the definition of the row and column factors may be selected
interactively before the file is processed. (N.B. Mixing interactive and file input
control is not ideal but it works and given how infrequently this method is probably
used it doesn’t seem worth introducing major changes; requests to DVV!)
Thus, rows and columns may be defined as either names or sequential numbers
via an option set interactively prior to processing the file. Names are then re-set
to the equivalent sequential values.
5120257 / Apr 15 10-30

Section 10
Similarly for stacked matrices the row and column numbers may be based either
on the full matrix or for a particular level within the stacked matrix. For example, if
one had 3 10x10 matrices stacked (so that the internal matrix has 30 rows and 10
columns) and one wished to factor rows 3 to 5 of level 2 then one could either
specify them as (sequential) rows 13 to 15 if a level were unset or rows 3 to 5 if
the level were pre-defined as 2.
Note that if the option to use zone names rather than sequential numbers has
been pre-selected then the only way to define rows within levels other than the
first is to pre-define the level.
Row or column numbers left blank (or equal to zero) are assumed to be either 1 or
the maximum row/column number as appropriate. Hence all blanks in columns 1
to 20 implies the whole matrix is to be factored.
To terminate the file put 99999 in columns 1 to 5 - or, strictly, any number or name
greater than the number of rows.
Alternatively the input data may be free format - again, a user-set option - in which
case each of the five inputs must be separated by blanks or commas.
10.7.3.1 Factoring Based on Sectors Etc.

A modification of the above procedure uses SECTORS in place of ZONES to
define the area to be factored. To use this option put ‘S’ in column 1 of a record if
the entries in columns 2 to 20 refer to sectors rather than zones. Again missing
input fields are assumed to refer to the lowest or highest sector number as
appropriate.
Clearly the sector option is only possible in those cases where a supplementary
network or GIS file has been input in order to define sectors. It will not work with
free-format inputs.
‘Mixed’ zone and sector files are also permitted; records without an S in column 1
are assumed to be based on zones. However zones and sectors cannot be mixed
on the same line.
An alternative method for applying factoring at a sector-to-sector level is to create
a .UFM matrix of the sector-to-sector factors and then use Option 13 under UFM
Outputs (see 10.16.2) plus a .z2s file to “copy” those factors into a zone-to-zone
.UFM file which may then be used to multiply the internal matrix (e.g., using a
Fortran equation, 10.8.1). Note that this method is in fact potentially much more
general in that the level at which the factoring is applied is not restricted to sectors
as pre-defined for the internal matrix but may be based on any level of
aggregation, e.g., by traffic borough, district, etc. etc. through the use of an
appropriate .z2s aggregation file.
10.7.4 Row and Column Specific Factoring

These options are in fact specific examples of selected area factoring where the
area in question is either a complete row or column. A complete set of row or
column-specific factors needs to be defined. These may be either set interactively
by screen editing or they may be taken to be the row/column totals from an input
matrix (the most common example of the latter being to multiply rows in a matrix
5120257 / Apr 15 10-31

Section 10
of probabilities by origin totals or columns of probabilities by destination totals; see

10.19.1).
If the matrix is stacked, e.g., for multiple user classes, then the screen edit format
sub-divides the data displayed on the screen by level (if all levels are being edited
together). Alternatively it is possible to set row/origin factors for Level 1 and then
apply the same factors to all levels or to set factors and apply them to rows for a
single level only. The latter options are new in release 10.8 while the former
correct potential pre-10.8 errors.
Finally options were added in 10.9.23 to apply column factoring to a single
selected level from a stacked matrix.
At the moment there are no options to read in factors from an external .dat file
although this can be done with only slight inconvenience using selected area
factoring (10.7.3). For example a control file:
1 1 0 0 1.50
2 2 0 0 1.75
0 0 1 1 1.20
1 1 0 0 1.50
would factor row 1 by 1.50, row 2 by 1.75, column 1 by 1.20, etc.
10.7.5 Matrix Furnessing: Trip Ends Set Interactively

New trip ends (i.e. row and column totals) may be set interactively in three basic
ways:
1) En masse via screen editing.
2) Individually using keyboard inputs.
3) From another matrix.
Under 1) the new totals may in turn be defined in three different ways:
a) As new absolute values;
b) As incremental changes,
c) As factors.
In addition these may be set by zones or by sectors (if defined). Thus if one is
using factors by sector an input value of 1.1 for sector 1 origins would factor the
origin (row) totals for all zones in sector 1 by 1.1. In all three cases the defaults
are no change (current values, change = 0, factor = 1 respectively).
Keyboard input is longer and more laborious than screen editing but is fine for
changing one or two totals or for subsequent use with key files.
Finally trip ends from one of the external matrices may be used to set trip ends for
the internal matrix, an application of which is given in 10.19.1.
5120257 / Apr 15 10-32

Section 10
10.7.6 Matrix Furnessing - Trip Ends Set from a Control File

Trip Ends for the MX Furness option may also be read from an external ascii .dat
file defined in one of three different ways:
1) As absolute origin and/or destination totals,
2) As (additive) changes to the existing totals,
3) As factors to the existing totals.
where the “existing totals” are derived from the current trip matrix, i.e., the matrix
currently within the internal MX memory.
All three types of data are defined within a single data file and are distinguished in
the normal SATURN way of appearing in ‘11111’, ‘22222’, etc. data sections
following a (very limited) set of namelist parameters. Not all data sections need
appear.
In addition the data may be defined either for individual zones or for “sectors”, i.e.
aggregates of zones, if these are defined elsewhere. Sector factors are applied to
all zones equally; new sector totals and/or differences are applied pro rata to
constituent zones based on the totals in the current trip matrix.
Note that the definition of the new row and column totals is “progressive” in that a
new row total may be defined under data set 1, incremented under 2 and factored
under 3. Such a situation would probably be very unusual; in practice it is
expected that users would use only one of the three basic methods.
The precise file format is as follows:
RECORD SET 0 - NAMELIST PARAMETERS (OPTIONAL)
These consist of a header record &PARAM, a record defining two possible logical
parameters NAMES and CSV plus an &END record.
Here NAMES =.TRUE. if the following records use zone “names” as opposed to
sequential row/column numbers. Default: .TRUE.
If CSV = .TRUE. the data records which follow are input as “comma separated
variables”, i.e., with the zone name/number and new total etc. in any columns as
long as they are separated by a comma or by one or more spaces. If CSV =
.FALSE. the fixed columns (with decimal points) specified below must be used.
Default: .TRUE. (post 10.7)
N.B. Where the specification indicates that a decimal “normally” appears in, say,
column 13 out of columns 6-15 this is not a rigid requirement. In fact the decimal
may appear in any column as long as the whole number is contained within the
columns specified. Thus, in the above case, the user would not be restricted to a
maximum of 2 decimal places in the input field.
RECORD SET 1 – ABSOLUTE ORIGIN TOTALS (OPTIONAL)

Record 1A - ‘11111’ in columns 1 - 5 followed by:
5120257 / Apr 15 10-33

Section 10
Records 1B: One record per row constraint formatted as:

Col.1
‘S’ if the record (cols 2-5) applies to a sector
Cols.1 - 5 The row/origin zone name or sequential

number (NAMES = T or F)
Cols.6 - 15 The required new total (CSV = F: include a

decimal point, normally in col. 13)
terminated
by:
Record 1C - 99999 in columns 1-5.
RECORD SET 2 – ABSOLUTE DESTINATION TOTALS (OPTIONAL)
Records 2B: One record per column constraint formatted as:
Col. 1 ‘S’ if the record (cols 2-5)applies to a sector
Cols.1 - 5 The column/destination zone name or

sequential number (NAMES = T or F)
Cols.6 -15 The required new total (CSV = F: include a

decimal point, normally in col. 13)
terminated
by:
Record 2C - 99999 in cols 1-5.
RECORD SET 3 - CHANGES TO ORIGIN TOTALS (OPTIONAL)
Records 3B: One record per row and/or column constraint formatted
as:
Cols.1 – 5 The row/origin zone name or sequential

Cols.6 -15 The difference of the new total from the

current value (CSV = F: include a decimal
5120257 / Apr 15 10-34

Section 10
point, normally in col. 13)
Terminated
by:
RECORD SET 4 - CHANGES TO DESTINATION TOTALS (OPTIONAL)

Cols.1 – 5 The column/destination zone name or

sequential number (NAMES = T or F)
Cols.6 -15 The difference of the new total from the

current value (CSV = F: include a decimal
point, normally in col. 13)
Terminated
by:
RECORD SET 5 - ORIGIN/ROW FACTORS (OPTIONAL)

Record 5B: One record per row constraint formatted as:
Cols.1 – 5 The row/origin zone name or sequential

Cols.6 -15 The ratio of the new total to the current

value (CSV = F: include a decimal point,
normally in col. 13)
Terminated
by:
RECORD SET 6 - DESTINATION/COLUMN FACTORS (OPTIONAL)

5120257 / Apr 15 10-35

Section 10
Cols.1 – 5 The column/destination name or number

(NAMES = T or F)
Cols.6 -15 The ratio of the new total to the current

value (CSV = F: include a decimal point,
normally in col. 13)
Terminated
by:
RECORD 7 (MANDATORY)
A final ‘99999’ record.
10.8 Matrix Manipulation

A number of options are available to create a new version of the internal matrix
using some or all of the data currently available. They are:
1) General manipulation via an equation.
2) Transposition.
3) Screen editing (by cell or by sector).
4) Addition of two cost skim matrices.
5) Log-sum addition of two or more (cost) matrices.
6 Copying individual rows or columns.
7) Manipulation of the intra-zonal cells only.
The manipulation may be applied to the whole matrix (by default) or to selected
areas (see 10.6).
10.8.1 Manipulation via FORTRAN Equations

This option allows for a very general matrix manipulation by defining, via
equations based on FORTRAN syntax, the new matrix to be created. Both the
current internal matrix plus all input (and ouput) .UFM files may be involved.
For example to average two matrices the user would type:
0.5 ∗ ( X 1 + X 2 )
while more complex matrix operations are possible, for example:
e −0.23 X1
5120257 / Apr 15 10-36

Section 10
transforms an input matrix into its corresponding negative exponential.

In these equations the external .ufm files used for input are denoted by X1, X2,
etc, the internal matrix by Y and the output .ufm matrix by Z as shown in Figure
10.2. For example, typing:
0.5 ∗ (Y + Z )
would take the average of the (current) internal matrix and the (latest) output .ufm
file and store those values as the new internal matrix Y.
The equation can not only use the standard arithmetic operations - add, subtract,
multiply, divide and exponentiate - they can also use a number of standard
functions, e.g. EXP as illustrated above. The following functions are available:
♦ Exp (X)
♦ Log (X) - natural log
♦ SQrt (X)
♦ Sin (X)
♦ Cos (X)
♦ Tan (X)
♦ Abs (X)
♦ Int (X)
♦ MAX (X, Y, …)
♦ MIN (X, Y, …)
♦ RR (X, Y) - Uniformly distributed random variable whose mean is X and

with range X (1-Y) to X(1+Y)
♦ RN (X, Y) - Normally distributed random variable whose mean = X

and whose variance = Y.
The upper case letters above indicate the minimum number which must be used
to denote a function; thus E(X), EX(X) once EXP(X) all have the same affect.
Note that numerical values may be used within the equation written either as
“integers” or “reals”, i.e. without or with decimal points.
Open and close brackets may be used as part of the expression (always in pairs!)
and follow standard FORTRAN syntax rules. They may be used to clarify the
“order” of calculation which again follows standard FORTRAN rules; e.g.
operations within brackets always precede operations outside. For example in the
expression:
( X1 + X 2 )
X3
5120257 / Apr 15 10-37

Section 10
the variables X1 and X2 are always added together prior to exponentiation. This
would not be the same as
X1 + X 2 X3
Users are advised, if in doubt, to carry out several steps with very simple
equations which create temporary data columns. For example by first calculating
X1 + X 2
which might be stored in data column 4 followed by
X 4 X3
would have the same effect as above (although the final result might not be in the
same data column).
10.8.2 “Partial” Manipulation over Selected Areas

The use of selected sub-areas of the matrix may be very usefully applied in this
context. Suppose you wish to add 50% of the trips for origin 6 from the second
input .ufm file to the internal matrix. To do so first use the select procedures to
select row 6 (all columns), then use the equation:
Y + 0.5 X 2
The selection of single rows and/or columns may also be very usefully applied to
setting the row/column values for newly created zones; see 10.4.2.
10.8.3 Using Row and/or Column Totals

Equations may also make use of the row and column totals in either the (current)
internal matrix or any of the external .ufm files. Thus the equation:
ROW (1) ∗ COL (1) / Y
would imply that each new cell element equals the product of the row and column
totals of the first input .ufm file divided by its current internal matrix value.
Syntax rules are that either ROW or ROW(0) implies the row total from the internal
matrix. ROW(n) is the total from the n’th .ufm input matrix. Ditto COL, COL(0)
and COL(n).
10.8.4 Matrix Transposition

Very simply the (I, J)th cell in the internal matrix becomes the (J, I)th and vice-
versa.
Note however a special case of matrix transposition whereby a matrix stacked by
blocks (10.2.4) may be transposed “by block” rather than by cell. Thus the sub-
matrices in Figure 10.1(b) would be moved into the positions in Figure 10.1(a).
5120257 / Apr 15 10-38

Section 10
This is a useful “trick” since at the moment MX is better equipped to display

information relating to sub-matrices by level rather than by block; e.g. printing cell
values or row/column totals interleaved.
10.8.5 Screen Editing

On-screen editing of individual cell values follows the same procedures as
described under 10.10.4.
Alternatively screen editing can be performed at the sector-to-sector level, there
being two options for “converting” a sector-to-sector cell value into its constituent
zone-to-zone cells:
Tij = TIJ
Tij ∀TIJ
where ij refers to zones within sectors I and J.

Thus under 1) all ij cell values equal the sector IJ values; this would be
appropriate if the matrix elements are, e.g. costs, which apply equally to all cells
within a sector.
Under option 2) ij cells are factored by a sector-to-sector constant F IJ such that the
new ij elements sum to the new IJ values. This would be more appropriate for,
e.g., trip matrices where the elements are “additive”.
10.8.6 Adding Cost Skims via a “Park ‘n’ Ride” Zone

A transport-specific matrix problem is to calculate the cost from zone i to zone j via
some intermediate zone k (where, e.g., k represents a park ‘n’ ride site) so that:
T=
ij Aik + Bkj
A ik therefore represents the cost from the origin to the park and ride zone, and B kj
the subsequent cost to get from k to the final destination.
10.8.7 Log-sum Addition of Cost Matrices

A common operation within logit models is to combine two or more sets of o-d
cost matrices at a common “level” in a hierarchical demand model into a single
composite perceived cost matrix via a “log sum”. See, for example, equation
(7.27) in section 7.6.3. In principle a log sum of two or more matrices may be
achieved by using the Fortran Equation options above although the equations
tend to be rather long-winded and easy to mistype; hence the need for an explicit
option.
To carry out a log sum the user must (a) identify those matrices to be combined
(presumably cost matrices but no explicit check is possible) and (b) a value for the
parameter beta. The composite matrix is created as the internal matrix.
5120257 / Apr 15 10-39

Section 10
10.8.8 Copying Individual Rows and/or Columns

Options here allow the user to copy cells from one row or column into another row
or column with options for factoring and/or furnessing the newly created
rows/columns.
10.8.9 Manipulation of Intra-zonal Cells

Two options are currently available for the manipulation of intra-zonal cells;
specifically:
Setting a fixed value for all intra-zonal cells
Creating intra-zonal values based on the minimum of all other cells in a row.
More specifically option (2) has been created in order to set intra zonal costs
equal to 0.5 times the minimum cost from that origin to any destination (excluding
those O-D cells which have zero cost).
10.9 Statistical Analysis

Three separate forms of statistical analysis are described below. They may be
applied either at the cell-by-cell or sector-by-sector level. For more complicated
analysis users are advised to “dump” the matrix/matrices into ascii files (10.15)
and to transfer the data into “proper” statistical packages such as SPSS or SAS or
into spreadsheets such as EXCEL.
10.9.1 Univariate Analysis of a Single Matrix

This option produces a set of standard unvariate statistics (mean, standard
deviation, etc) of either a set of individual cells or else a set of row and column
totals. These may be based on either the internal matrix or any of the external
ufm files. Equally they may refer to the whole matrix or selected sub-areas; see
10.6.
The same set of univariate statistics per matrix may also be printed in a table
covering all external .ufm matrices plus, optionally, the internal matrix or, equally,
a table of univariate statistics covering all levels of a single matrix may equally be
displayed.
10.9.2 Comparison of Two Matrices (M2)

These options compare two matrices, either cell by cell, row total by row total or
column total by column total (or combinations thereof) and print copious
comparison statistics and tables (e.g. of absolute differences) to the line printer file
(LPX) with summary statistics to the screen.
Various options are provided:
1) You may list all elements whose absolute differences exceed a specified
value; the list appears in the LPX file.
2) You may list the 10 largest absolute differences; this appears both on screen
and in the LPX file.
5120257 / Apr 15 10-40

Section 10
3) You may analyse the whole matrix or selected portions of it.

4) The matrices used may be either external ufm files (either input or output) or
the internal matrix, but clearly you need at least two available matrices
before this option will appear.
5) In addition, if the internal matrix is “stacked”, i.e., it contains multiple basic
square matrices, then the comparison may be made between any two of the
internal levels.
6) Graphical scatterplots of one matrix vrs the other are available.
In earlier versions of SATURN this function was provided by a separate program
M2, hence the name. Note that this function is also available through a standard
batch file MXM2; see 10.20.2.
10.9.3 Trip Length Distributions

A trip length distribution (TLD) calculates the number of trips from one (trip) matrix
within length bands defined by another matrix. “Length” here refers to any one of
properties such as distance, time, generalised cost, etc, and should more properly
be referred to by the generic title “cost”. Thus if “length” or “cost” is a time matrix
then the TLD lists the number of ij trips in the time band 0 - 20 seconds, 20 - 40
seconds, etc. where the “width” of each band is user-set.
The output appears in the line printer (.LPX) file both as a tabular distribution plus
average “lengths” per origin and various totals.
Graphical plots of a trip length distribution can be obtained either here or under
the Matrix Graphics options - see 10.12.
10.10 Viewing and/or Editing Matrix Elements

Elements in either the internal matrix and/or any of the external .ufm matrices may
be displayed on the screen in a number of basic formats:
(i) A “block” of cells, i.e. covering a range of rows and columns to fill the screen.
(ii) All elements in a single row or column.
(iii) As a complete aggregated sector-to-sector matrix (if sectors have been
defined)
10.10.1 Viewing a Block of Cells

Depending on the options selected this option displays on the screen all matrix
cell values from a “block” covering approximately 15 rows (down the screen) and
7 columns (across the screen).
Within this option it is possible to “move around” within the matrix by using either
the cursor keys or the keys U, D, L and R (for Up, Down, Left and Right). The
Home and End keys move up to “upper left” or “lower left”.
The above options all move the “upper left hand corner” of the display.
Alternatively the cell in the upper left hand corner may be explicitly set via a
“location sub-menu”.
5120257 / Apr 15 10-41

Section 10
If the area currently on screen includes the “bottom” and/or the “right hand side” of
the matrix column and/or row sums will be included (space permitting). Equally
the total of all cells appears in the extreme lower right hand corner. Options are
provided such that the row and column totals always appear on the screen
display.
Two format “modes” are provided: the default prints all cells with two decimal
places, the alternative prints integers (and, because each column is narrower,
more columns are printed at a time). Alternatively under a “select mode” all non-
selected cells are left blank on the screen.
Not that each “screen” that appears is also sent to the output line printer (LPX) file
as a permanent record.
10.10.2 Viewing Multiple or Stacked Matrices

It is possible to print two or more matrices simultaneously by a set of multiple lines
for each matrix row. For example the first row prints cell elements in the internal
matrix, the second could print cell elements for the first input .ufm matrix file, etc.
etc. On screen these appear as different colours.
Similarly with stacked matrices the different “levels” may be displayed
“interleaved” as above, as opposed to having the top level displayed first with
lower levels beneath it. Alternatively a single level of a stacked matrix may be
selected for display only.
Post 11.1.14 buttons have been added to the menu bar to allow the display to
jump to the next level up or down (in addition to the existing “Up” and “Down”
navigation buttons that move the display immediately up or down).
10.10.3 Viewing Single Rows and Columns

This format lists, e.g., all elements in row 1, all elements in column 6, etc, with, at
the end, both row and column totals for that particular zone; i.e. printing row 1 will
give both the total of all elements in row 1 plus the total of all elements in
column 1.
As under 10.10.2 more than one matrix can be printed simultaneously but it is not
possible to print, say, row 1 from matrix 1 with row 2 from matrix 2. Nor can I think
of any reason why you should want to!
10.10.4 Screen Editing the Internal Matrix

Under screen editing all elements in the current “block” of the internal matrix are
“dumped” to the screen and may be altered as desired.
On exit from the screen edit cell values in the internal matrix are replaced by those
on the screen.
Instructions as to how to use screen editing - different between 16 - and 32-bit
versions - are given in Section 19.9. Note in particular under 32-bit that the
screen constitutes a formatted data set so that changing the position of any data
item on a line or adding/deleting lines may lead to cells being mixed up on return.
5120257 / Apr 15 10-42

Section 10
Note as well that under 32-bit the row and column integer headers are for
information only and may not be “edited”.
10.10.5 Viewing Sector-to-Sector Matrices

This display is similar to viewing a block of cells except that aggregate sector-to-
sector cells are displayed. Options allow either sector numbers of sector titles to
appear over rows and columns. On exit from the screen edit cell values in the
internal matrix are replaced by those on the screen.
Instructions as to how to use screen editing - different between 16- and 32-bit
versions - are given in Section 19.9. Note in particular under 32-bit that the
screen constitutes a formatted data set so that changing the position of any data
item on a line or adding/deleting lines may lead to cells being mixed up on return.
Note as well that under 32-bit the row and column integer headers are for
information only and may not be “edited”.
10.11 Viewing Row and Column Totals

Basically this option lists all row and column totals, the grand total of all cells plus
the total of the intrazonal (diagonal) cells to the screen with a series of options as
below:
1) alphanumeric text names are available they may be included.
2) a from more than one matrix may be included, e.g. from one or more of the
external .ufm files, in which case they appear in different colours. See
10.10.2.
3) and column totals from stacked matrices may be shown “interleaved”, e.g.
the row totals for row 1 for level 1, level 2, etc. etc. are given together as
opposed to appearing on lines 1, n+1, 2n+1, etc.
Alternatively the grand totals (plus intras) may be displayed on their own (faster if
this is all you wish to see).
Intrazonal cells, normally identified by row equals column in a square matrix, are
also identified in stacked and/or blocked matrices where the “local” row equals the
“local” column, i.e., both represent the same zone.
10.12 Matrix Graphics

Graphical facilities in MX, unlike P1X, are relatively new and in fact do little more
than duplicate facilities already in P1X (see 11.6.7.2). Essentially two options are
available:
1) Frequency Distributions.
2) Trip Length Distributions
plus a parameters sub-menu that services both. Users who require more
sophisticated graphical displays are advised to dump the matrix/matrices into, e.g.
EXCEL (10.15) and use the facilities there. (But please advise DVV of any display
forms that you would regard as essential and/or specific to transport planners.)
5120257 / Apr 15 10-43

Section 10
The trip length distribution (TFD) option is only available if you have two or more
matrices including the internal matrix; one defines the “trips” and the other the
“costs” although there are no checks whether or not the matrices you select are
indeed trips and costs. (Recall that cost matrices are generally obtained using
SATLOOK; see 15.27). It is also possible to print trip length distributions from two
different input trip matrices simultaneously (in which case at least two external
.ufm files plus a different internal matrix are required).
See also 10.9.3 for non-graphical methods to calculate TFDs.
MX can plot either to the screen or to other external devices defined in
GRAF.DAT. The screen image may also be dumped to a bitmap file (11.3.5) by
entering ‘X’ when the image is on the screen.
10.13 Printing a complete matrix to a line printer

This option prints a full listing of the cells in either the internal matrix or an external
.ufm file to the line printer (LPX) file. The format includes pagination and header
records and therefore is intended essentially for “viewing” or printing, not for
transfer to another program such as a spreadsheet; in the latter case option 13
should be used (see 10.15). If defined sector to sector matrices may also be
printed.
10.14 Printing/Dumping Row and Column Totals

This option prints the row and/or column totals either to the line printer (LPX) file
or to an (ascii) data file with either a SATURN-based format or a CSV-based
format.
In the SATURN-based output the row and column totals are formatted as per that
required for a trip ends control file as specified in Section 10.7.5 for matrix
Furnessing; i.e. a namelist record followed by 11111 (row totals) and 22222
(column totals) data sets.
CSV-formatted files contain one record per zone with options to include or not: (a)
sequential row numbers, (b) zone names per row, (c) level numbers per row, (d)
row totals and/or (e) column totals. In addition an extra header record may be
included with titles for each column included. CSV output is probably preferable if
the user wishes to “manipulate” the data, for example using a spreadsheet, as
opposed to simply printing data or transferring it elsewhere within MX.
Various options include whether or not to print zone names or sequential numbers
(see 10.2.2), the source of the matrix (internal or external ufm), whether or not
zero values are included and whether (in the case of stacked matrices) whether
row/column totals from a single level or from the full matrix are output.
A further option allows the sum of all elements in the matrix to be output as a
single line to an ascii file, in which case the data line may be “appended” (i.e.
added) to an existing file. The append option is useful, e.g., as part of a set of
runs over several forecast years when it is desired to create a file for input to a
spreadsheet containing matrix totals by forecast year.
5120257 / Apr 15 10-44

Section 10
Note that if the output file has the extension .CSV (the default) then the output
format is automatically in CSV such that commas are added at the end of each
numerical field.
10.15 Dumping a Matrix to an ASCII .DAT (Text) File

This option writes the cell values of the internal matrix into a user-specified ASCII
(text) file. It is used typically to “transfer” matrix data between suites or from
SATURN into, say, a spreadsheet such as EXCEL.
The output ASCII file may be either defined interactively by the user or else set as
a command line parameter (see 10.1.2) using the keyword KP as in:
MX matrix KP tijdata.txt
Note that the KP option may be usefully used to set the filename when a matrix is
“dumped” using a KEY (or KEY + VDU) file to generate the necessary commands
as in:
MX matrix2 KP tij2data.txt KEYVDU dump
10.15.1 Output Formats

The output data file may be written in a number of different formats:
1) Standard SATURN format (2 varieties).
2) A user-defined format.
3) Non-zero values only, one line per record.
4) A spreadsheet (comma separated CSV) format.
5) EMME/2 format.
6) TUBA formats 1, 2 and 3.
In addition under formats 2), 3) and 4) above the output may be based on either:
(i) the entire matrix or,
(ii) a selected subset of cells.
N.B. These formats mirror the matrix input formats described in Section 10.5.
10.15.1.1 SATURN Formats

In case (1) the user may choose one of the two “standard” SATURN formats
(LONG = T or F) which effectively differentiate between an output with three
decimal places per cell or output with no decimals (i.e. integer). In both cases the
zone “name” is included as the first element in each block. Full specifications are
given in 10.5.1.
10.15.1.2 One Cell per Record

In case (3), one record per non-zero cell, each line contains, optionally, the
sequential row and/or column numbers, their corresponding zone names and the
5120257 / Apr 15 10-45

Section 10
cell values with a large number of decimals for maximum accuracy. In addition,
with stacked matrices, the level and/or block value may also be included, e.g. as
the third value on a record if only the sequential row/column numbers/names are
included, the fifth if both numbers and names are given.
Single-line records may be either “formatted” (i.e., output within fixed columns” or
free format/CSV (i.e., output with each item separated by a comma). The “fixed”
column widths are set large enough that spaces will certainly exist between each
item so that the formatted output may be effectively re-read in MX (see Section
10.5.4) as though it were free-format. At this stage, therefore, and as far as
subsequently re-inputting files back into MX goes, the choice is not particularly
important (although, for inputs, the free-format choice is strongly recommended;
10.5.4).
In Release 10.8.20 an extra option has been provided to suppress the final record
which, by default, consists of 99999 and which can be “awkward” if the ascii file is
being input to other suites of programs.
10.15.1.3 EMME/2 Formats

Output in EMME/2 format follows the conventions specified in 10.5.5. In particular
two header records are included consisting of:
1) ‘t matrices’
2) ‘a matrix = mf0n’ followed a short (6 character) matrix title with n in column 6
followed again by a longer (40 character) SATURN matrix title (record 4
under 10.5.1).
The numerical value of ‘n’ in record 2 above is user set with a default value of 1.
Note that zero-value cells are not output but that otherwise all cells in the matrix
are considered.
Due to EMME conventions only matrices which are “square” may be processed by
EMME; i.e., stacked matrices should not be output using an EMME format.).
10.15.1.4 CSV Outputs

Alternatively users may define their own format or choose a CSV or “spreadsheet-
style” format where all the elements in a row are output to a single record with
individual elements separated by commas; see 10.5.5. This option is provided
primarily for users who wish to dump a SATURN matrix into, e.g., EXCEL. Note
however that a spreadsheet may be “clever enough” to read alternative SATURN
outputs and that, if you do try to use a spreadsheet, there may be limits to the
maximum number of columns which may be input, in which case you may need to
work with a “strip” of columns as described next.
Subsets of the matrix are selected as a “rectangle” within the full matrix defined by
upper and lower row and column numbers. You may, for example, choose to
output all rows but only a “strip” of columns such that the width of each record per
row does not get too long for other packages to handle. In such cases it might be
preferable to dump, say, a 200 x 200 matrix as 10 200 x 20 strips, each as
5120257 / Apr 15 10-46

Section 10
separate files. (Although clearly it is much more convenient to deal with one
rather than 10 files, so only use this as a last resort.)
Note that the number of decimal places used in CSV outputs may be an issue for
both numerical precision and record lengths; see 10.15.2 below. More precisely,
the maximum record length allowed is 16384 characters. If the required length
exceeds this the output record is truncated and produces a Non-fatal Error
message in the .LP file which may escape your notice
10.15.1.5 TUBA Formats

TUBA (the current standard UK software for evaluation) provides three different
text formats for matrices, all three of which were added in release 10.5 and
enhanced under release 10.6. For example, the number of decimal places can
now be user-set under all 3 formats and the latest value stored within the
preferences file (as NDPS). However the output “units” are “fixed” so that, e.g., a
matrix of distances is always output as kilometres (whereas SATURN would
normally use metres).
Note that TUBA format 1, (CSV format) is effectively the same as that output
under option 4) above and the same caveats apply. Formats 2 and 3 are very
similar to the SATURN single record outputs, option 3). Under formats 2 and 3
zone names are automatically used as opposed to sequential numbers. (N.B. if
the input matrix .ufm file does not contain the correct zone names, only sequential
numbers, the zone names must be added from a network .ufs file; see 10.3.3.)
In addition, post 11.1, cells with zero values may optionally be output under Tuba
3. By default they are excluded and including them is definitely not recommended
– it may create extremely large files – but there may be circumstances under
which it is necessary.
10.15.1.6 Automatic Matrix Dumping

Note that the output options effectively mirror the input options described in
section 10.5 so that data may be conveniently “dumped” under these procedures
and re-input (“undumped”?). See 10.20.13 and 10.20.14 for a list of useful batch
procedures to dump/undump.
10.15.2 Output Options: The number of decimal places

Under certain options, the user has the choice of the number of decimals to be
used and whether or not the data is output in decimal format or E-formats (e.g.,
1.23 as opposed to 0.123E+01). These choices relate to questions of “precision”
and/or “rounding errors”.
Problems of a loss of precision may arise if an insufficient number of decimal
places are not used due to rounding errors. For example, a trip matrix cell value
10.12345 would be output as 10.12 if the output format specifies 2 decimal places;
in effect 0.00345 trips are lost. If the number of decimals were 5 no trips would be
lost. The losses may become significant in very large matrices where a large
number of cells have been “in-filled” with very small values.
Thus extra decimal points may be needed for extra precision, although this may
also depend both on the format used and on the “units” of the matrix. For example
5120257 / Apr 15 10-47

Section 10
(assuming “decimalised” outputs) if a matrix contains inter-zonal travel times

which are of the order of 30 minutes in units of seconds 2 decimal places may
give ample precision (30 minutes would be output as 1800.00 seconds), but if the
units were hours then 30 minutes becomes 0.50 on output and any O-D cell less
than, say, 0.01 hours (36 seconds) might be rounded down and output as 0.00
under 2 decimals. Increasing the number of decimals avoids such problems.
On the other hand using a large number of decimal places may create problems in
certain circumstances, e.g., CSV outputs (see above), where the length of an
individual record may exceed 16384 characters and be truncated. Compromises
on the number of decimals may sometimes be necessary.
However we note that trailing zeros (and/or the decimal point) are truncated. Thus
10.10 becomes 10.1 on output as CSV, 10.00 becomes simply 10 etc. etc. Thus
increasing the number of decimal points does not necessarily increase the size of
the CSV output records proportionately.
Note that the default number of decimal places is now 5 but it may be re-set via
the namelist parameter NDPS used in the MX preferences file mx0.dat.
10.15.2.1 E- Formats
E-formats avoid problems when matrix cells contain both very large and very
small values. For example, take 2 cells with values 12345.67 and 0.0001234567.
Under E-formats (with 7 decimal places) they would be output as 0.1234567E+06
and 0.1234567E-03, whereas under decimal outputs they would become
12345.670000 and 0.0001235. In this case decimal outputs lose precision with the
smaller outputs while E-formats do not.
For maximum precision, minimum loss of accuracy it is recommended that users
choose E-formats with 7 decimal places as this corresponds roughly to the
numerical precision of single-precision real variables on the computer. Lack of
precision may be a serious problem if a matrix is being dumped to text in order to
export it to, say, EXCEL, manipulate it and then return it to MX. For “one-way”
transfers precision may be less of an issue.
10.15.3 Sector to Sector Outputs

Sector-to-sector data may also be output in the same manner as individual O-D
cells.
10.16 Output UFM Matrices

To “save” the internal matrix, output it to a binary .ufm matrix file. This is the
normal procedure by which a .ufm matrix file is created. Thus the M1 (or MXM1)
procedure described in Section 4 uses this output option after reading a .dat file
(10.5). The output matrix, referred to as Z in Figure 10.2, may then be further
used within the program.
The filename of the new .ufm matrix may either be set interactively at the time of
output or pre-defined using the “OUT” keyword on the MX command line (see
10.1.2).
5120257 / Apr 15 10-48

Section 10
A number of different options, numbered 1 through 15 in the UFM Outputs sub-

menu and described below, control the form of the outputs.
10.16.2 Basic Outputs

The most basic output is to copy the internally stored matrix data to a .ufm file “as
is” (the usual option, menu option 1).
Alternatively the internal matrix may be output as its “transpose”, i.e., T j.i is output
in cell i,j (option 2), although it is probably preferable to use methods described in
10.4 and/or 10.8.4 to transpose the matrix internally prior to output.
10.16.3 Outputs Based on Transformed Zonal Structures

Alternatively the output matrix may be based on a different pattern of zones by
compressing/expanding/re-coding the zones and the corresponding cells in the
internal matrix (options 3 to 10).
Note that the options described below closely parallel those described in Section
10.4 for the transformation of the internal matrix. Thus, alternatively, the matrix
may be first transformed internally and then output “as is”. For complex
transformations, e.g., not a straightforward compression, it may be preferable to
undertake the transformation before output as it may be easier to check what is
happening.
Zonal re-coding options were originally handled by the SATURN programs M3,
M4 and M5. M3 and M4 were basically simplified versions of M5 which would not
work with, e.g., stacked matrices so that they have now been effectively phased
out (and have been given option numbers at the bottom of the list to reflect this
fact). In all three cases the specifications for the new zone structure must be pre-
coded on an input data file whose formats follow the previous M3/M4/M5
conventions given in Appendix W.
Option 3 (M5) represents the most general form of zonal transformations in that it
allows for zones to be added together (“compressed”), renamed, sub-divided into
new zones or deleted as defined in the control file as documented in App W.3. To
a large extent M5 duplicates the interactive options described in Section 10.4.2 for
editing zones internally.
10.16.4 Outputs Based on Compression

Options 4 through 8 are based on simpler forms of zonal transformation – either a
pure compression/aggregation from zones to “groups” or, conversely, a pure
expansion from groups to zones. They follow the basic principles described in
Section 10.4.4 and 10.4.5 and effectively perform the same functions but with
outputs directly to an external .ufm file as opposed to the internal matrix.
Thus option 4 and 5 aggregate zones into groups defined either (option 4) via an
input .Z2G file, or (option 5) using a pre-defined zone-group mapping as “carried”
by the .ufm file or as previously introduced within this particular run of MX. For
example the .Z2G file might have been set by the parameter FILZ2G during the
matrix build (see Table 10.1 in section 10.5.2) and the necessary information
stored in the .ufm file.
5120257 / Apr 15 10-49

Section 10
Option 6 aggregates zones to groups using a hierarchical set of rules based on

zone numbers plus parameters IROCKY and NBASE (see 10.4.4) while option 7
aggregates zones to sectors following the current definitions of sectors.
Finally option 8 – first introduced in release 11.2.9 – outputs a compressed or
aggregated matrix but following a specific set of rules within the TfL SATURN
zone naming conventions; see 5.1.7.2. Thus the output matrix is aggregated into a
traffic borough to traffic borough format. Note that in order to make use of this
option the internal matrix must be recognised as a TfL-based matrix, most easily
done by toggling option 16 within Main Menu 1 (10.1.1.1) although it is also
possible to declare a matrix as a TfL matrix at the point of its creation (see the
parameter TFL in Table 10.1 in 10.5.2).
10.16.5 Outputs Based on Expansion (Groups to Zones)

Options 9 and 10, introduced in 11.2.6, allow an “aggregated” matrix (e.g., a
matrix which has been defined at the level of, say, group-to-group cells) to be
expanded (“disaggregated”) into a matrix of “zone-to-zone” cells where the
relationship between “groups” and “zones” may either by set by a .Z2G file or –
preferably - via the existing zone-group mappings. Note that, in this case, the
zone-to-group mapping is used “in reverse” in order to define which zones are
within each group.
We note that under expansion the value in an individual group-to-group cell is
copied into each and every corresponding zone-to-zone cell so that the sum of all
the zone-to-zone cells will be considerably greater than the sum of the group-to-
group cells. Hence this option is not suitable for a matrix of “quantities” such as a
trip matrix whereas it would be suitable for a “qualitative” matrix of, say, group-to-
group distances or group-to-group factors.
N.B. The use of the terms “group” and “zone” above is purely nominal, they are
simply referring to two different levels of (spatial) aggregation. The same
procedures could equally well be used to transform a matrix defined in terms of
“boroughs” into one defined by “districts” or from “boroughs” into “zones”, etc. etc.
See Section 10.2.5 for a discussion on different levels of aggregation and their
“names”.
10.16.6 Output Options for Stacked Matrices

If the internal matrix is stacked with multiple “levels” a single level may be dumped
as a square output .ufm file, an operation referring to as “cutting” a matrix (option
11 along with 12 and 13 to set the level/block). See 10.4.3 for the reverse
procedure to “paste” a square input matrix into a single level.
The same option, plus others, is also available as described in 10.17.
10.16.7 Miscellaneous .UFM Output Options

Options to change the matrix dimensions and units (10.2.3) and the title are
available (#15).
Option 14 allows a matrix of 0/1 cell values to be output to represent the current
state of “cell selection” (10.6). Thus 0 represents non-selection, 1, selection.
5120257 / Apr 15 10-50

Section 10
10.17 Stacking and Unstacking Matrices

A matrix may be “stacked” from two or more square input .ufm files either into the
internal matrix for internal analysis, modification etc, or else directly into an output
.ufm file. The “levels” in the stacked matrix must correspond to the order of the
input matrix files although, optionally, not all the input matrix files need be stacked.
Note that it is not possible to directly include the internal matrix as one of the
matrices to be stacked, although this may be done indirectly by first outputting the
internal matrix to a .ufm file and including it as an input .ufm file (in which case it
will appear as the lowest level).
The output stacked .ufm file may be stacked either in “levels” or in “blocks” as
selected by the user; see 10.2.4.
A procedure to stack matrices using a pre-prepared .bat file, MXSTACK, is
Conversely, if the internal matrix is itself a stacked matrix with L “levels” it may be
subdivided into a set of L individual square .ufm output matrix files. For example
an internal matrix of 40 rows and 10 columns could give 4 10 x 10 output
matrices, one per level. Alternatively, post 10.9.20, a single level may be selected
for output as a square matrix, an operation referring to as “cutting” a matrix. See
10.4.2 for the reverse “paste” procedure to input a single level.
In Version 10.7 an option has been added to allow the output “unstacked”
matrices to take their filenames from a “root” filename. Thus, if the root filename
were mat.ufm then the output files are mat1.ufm, mat2.ufm, etc. etc. This is a
slightly more convenient procedure than having to explicitly define a filename for
each output matrix.
The same convention is also used by a bat file UNSTACK (see 10.20.12) and it is
also used by the reverse procedure STACK (10.20.11) to stack a set of square
matrices mat1.ufm, mat2.ufm etc. etc. into a stacked matrix mat.ufm.
We also note here (although strictly it should be included within 10.4) that if a
stacked .ufm matrix is input to MX options exists to read only a single level into an
internal (square) matrix or to sum all the levels into a single aggregate square
matrix. Use the latter option, e.g. to obtain a total trip matrix from a set of stacked,
say, trip purpose matrices.
10.18 Matrix Demand Calculations

Matrix-based demand models allow the user to carry out, e.g. mode split or
distribution calculations, provided that all necessary cost and trip matrices are
input along with essential parameter values. The result of these calculations is
always a trip matrix.
Different models require different “shapes” of trip matrices, i.e. square or stacked
by blocks, and these are described separately.
10.18.1 Square Matrices

The matrix demand models included within MX effectively mirror those models
that are included under the elastic or variable demand assignment models for a
5120257 / Apr 15 10-51

Section 10
single user class described in Sections 7.4 to 7.10. They also use the same
parameter names, for example setting MCGILL = 2 (see 7.7.1) in the demand
model sub-menu requests an incremental power law model of the form
Tij = Tij0 ( cij / cij0 )

P
where three input .ufm matrices must be defined, T ij o, c ij and c ij o, and the power p
set. These are also defined within the sub-menu with the matrices being equated
to external input files 1, 2, 3 etc.
Once all the necessary parameters have been defined choose “1- Do It Now!” to
perform the calculations. The resulting T ij values are stored in the internal matrix;
use main menu option 14 to permanently store them in a .ufm matrix file if desired.
Similarly to carry out a singly constrained trip distribution model set MCUBC = 1;
see 7.10.2.
Note that these functions are not applicable directly to multiple user class models
where the matrices are not square but stacked by levels to represent the different
user classes. To undertake demand calculations by user class it is necessary to
treat each user class separately with its own square matrix.
10.18.2 Blocked Matrices

Matrices which are stacked by blocks - see 10.2.4 - are currently only used to
represent multiple time periods and therefore the demand calculations available
within MX reflect this. Thus the one model available is the incremental logit model
of time period choice as described in Section 17.12 and 10.20.7.
10.19 The MX Box of Clever Tricks

The section lists a number of matrix operations which can be carried out using MX
but which may not be readily apparent.
10.19.1 Basic Trip Distribution Models using Furness

We demonstrate here how MX may be used to run a basic doubly constrained trip
distribution model of the form:
Tij = Ai B j Oi D j e − β C
where A i and B j are row and column balancing constraints to satisfy the row and
column totals O i and D j .
It requires as input a skimmed cost matrix ufm file, say input as the first matrix file
plus (optionally but most conveniently) an existing trip matrix as the second file;
the latter is used below as a convenient method of obtaining the trip ends O i and
Dj.
Thus first create the cost matrix C ij as the internal matrix (which it will
automatically become if the first input .ufm matrix is the cost file). Then transform
it into the negative exponential (assuming β = 0.01) via the matrix manipulation
equation (see 10.8.1).
5120257 / Apr 15 10-52

Section 10
e(
−0.01Y )
Next enter the matrix factoring option and choose, first, option 3 to factor all rows
by factors you select to be the row totals (i.e. origins O i ) from the trip matrix ufm
file; see 10.7.4. Thus the internal matrix now becomes:
( −0.01Cij )
Oi e
Repeat with option 4 to factor all columns by the column totals D j to give:
( −0.01Cij )
Oi D j e
Alternatively, and probably more conveniently, the above three steps could be
reduced to a single step via the FORTRAN equation:
ROW ( 2 ) ∗ COL ( 2 ) ∗ e(
−0.01Y )
assuming as above that the input trip matrix is the second .ufm file.
Finally choose the matrix Furnessing (10.7.5) and set the trip ends again from the
second .ufm input file. Requesting the doubly constrained Furness option solves
the original equations.
Goodness of fit statistics comparing the distributed trip matrix (the internal matrix
Y) to the assumed observed trip matrix (X2) may be obtained under the Statistics
Option and a calibration exercise carried out by trial and error.
10.19.2 Economic Evaluation: Rule of a Half

The classical rule of a half for calculating the consumer benefit of network/trip
matrix 1 compared to network/trip matrix 2 may be written as:
Equation 10.1
∑ 2 (T + Tij2 )( Cij2 − Cij1 )

1
C.S . = 1
ij
ij
This may be calculated by inputting the 4 relevant trip matrices – T1, T2, C1, C2 –
as input files 1 to 4 respectively (recalling that cost matrices may be calculated as
described in Section 15.27.4) and then creating the internal matrix via the
equation:
0.5 ( X 1 + X 2 )( X 4 − X 3 )
The consumer benefits may then be viewed per cell, per origin/destination or in to
using master options 8 and 9.
Note that to “dump” the total benefit into an external file, e.g. as part of a iterative
process involving forecasts for a series of future years, you may make use of the
facilities described in 10.14.
More simply the R.O.H. calculations are available as part of a standard batch file;
see 10.20.8.
5120257 / Apr 15 10-53

Section 10
10.20 Useful Matrix Batch Files

As explained in Sections 3.5, 14.5 and 14.7 it is possible, via the use of command
line options, to set up standard “batch procedures” using interactive programs
such as MX to carry out certain standard “bread and butter” operations such as
adding two matrices together in an “off-line” or “batch mode” without having to use
MX interactively.
This section lists a number of such procedures which are provided as part of the
standard SATURN installation.
10.20.1 MXM1 (M1): Build a Matrix

MXM1 mat
Using as input an ascii (text) file mat.dat in standard SATURN format it outputs a
file mat.ufm in binary format.
10.20.2 MXM2: Compare 2 Matrices

MXM2 mat1 mat2
Carries out the full set of standard statistical comparisons between 2 .ufm matrix
files mat1.ufm and mat2.ufm and outputs the statistics to a line printer file
mat1.lp2. See 10.9.2.
10.20.3 MXFACTOR: Factor a matrix

MXFACTOR mat1 mat2 X (LEVEL n
Factors the input matrix file mat1.ufm by X to output file mat2.ufm; ie
Tij2 = XTij1
If a level n is defined for a stacked matrix then the factoring is applied to that
level only; otherwise the factor is applied to the entire stacked matrix. N.B.
Similar to the interactive process to select a single level; see 10.7.2.
10.20.4 MXADD2: Add 2 Matrices

MXADD2 mat1 mat2 mat3
Adds matrices mat1.ufm and mat2.ufm together to produce an output file mat
3.ufm; i.e.:
Tij=
3
Tij1 + Tij2
10.20.5 MXAVER2
MXAVER2 mat1 mat2 mat3
Takes a 50:50 average of two matrix files mat1.ufm and mat2.ufm to produce an
output file mat3.ufm where:
T=3
ij (T 1
ij + Tij2 ) / 2
5120257 / Apr 15 10-54

Section 10
10.20.6 MXMSA
MXMSA mat1 mat2 mat3 n
Use the “Method of Successive Averages” to combine together two matrices

mat1.ufm and mat2.ufm to produce an output matrix mat3.ufm where:
(1 − 1/ n ) Tij1 + (1/ n ) Tij2

Tij3 =
The rationale behind the method of successive averages is explained in Section

7.2.2.
10.20.7 MXKK
MXKK TIJO CIJO CIJ TIJ BETA
Produces a new multiple time period trip matrix TIJ.ufm based on the incremental
logit model formulation of KK Chin. See 17.12.
Note that each matrix above must be “blocked” by time periods; see 10.2.4.
10.20.8 MXROH: Rule of a Half

MXROH TDN TDS CDN CDS BEN
Calculates the economic benefits according to the “rule of a half” (see 10.19.2)
from a do-something scenario with trip matrix TDN.UFM and minimum cost matrix
CDS.UFM compared with the do-nothing scenario represented by the trip matrix
TDN.UFM and cost matrix CDN.UFM. The outputs are a matrix BEN.UFM and a
one-line text file BEN.DAT.
Note that MXROH works equally well with multiple user class networks.
10.20.9 MXSTACK: Stack a Set of Matrices (vertically)

MXSTACK mat mat1 mat2 mat3….
Outputs a “stacked” matrix mat.ufm, built from the input matrices mat1.ufm,
mat2.ufm, etc. etc. in order. The list of input matrices may contain up to 8 inputs
(and clearly must have at least two in order to make sense).
N.B. The matrices are stacked “vertically” in levels, as appropriate for user
classes; cf MXBLOCK.
To stack more than 8 matrices see either STACK (10.20.11) or UFMSTACK
(10.20.17).
10.20.10 MXBLOCK: Stack a Set of Matrices (horizontally)

MXBLOCK mat mat1 mat2 mat3….
mat2.ufm, etc. etc. in order. The list of input matrices may contain up to 8 inputs
(and clearly must have at least two in order to make sense).
N.B. The matrices are stacked “horizontally” in blocks, as appropriate for time
periods; cf MXSTACK.
5120257 / Apr 15 10-55

Section 10
10.20.11 STACK: Stack a Set of Matrices (with sequential filenames)

STACK mat
mat2.ufm, etc. etc. The number of sub-matrices n to be stacked depends on the
maximum existing matrix file matn.ufm and, unlike MXSTACK, isnot otherwise
restricted.
STACK differs from MXSTACK only in so far as the matrices to be stacked are not
explicitly named on the command line but are implied by their “root” name (i.e.,
“mat”). The converse of STACK is the UNSTACK procedure which creates a set of
sub-matrices based on a “root” filename.
STACK and UNSTACK may be conveniently used if you wish to perform the same
operation (e.g., editing the zone structure) on each level of a stacked matrix.
10.20.12 UNSTACK: Unstack a Stacked Matrix (using sequential filenames)

UNSTACK mat
“Unstacks” a “stacked” matrix mat.ufm into its various components mat1.ufm,

mat2.ufm, etc. etc. up to the number of sub-matrices stacked in mat.ufm. The
sub-matrices may be re-combined into a stacked matrix using STACK above
10.20.13 MXSUB2: Subtract one matrix from another

MXSUB2 mat1 mat2 mat3
Subtracts matrix mat2.ufm from mat1.ufm together to produce an output file mat
3.ufm; i.e.:
Tij=
3
Tij1 − Tij2
10.20.14 MXWEIGHT: Weighted Average of Two Matrices

MXWEIGHT mat1 mat2 mat3 X1
Takes a weighted average of two matrix files mat1.ufm and mat2.ufm to produce
an output file mat3.ufm where:
Tij3= x1Tij1 + (1 − x1 ) Tij2
(As opposed to MXAVER2 which takes a fixed 50:50 average.)
10.20.15 UFM2…: Dump UFM Matrices to Text Files

E.g.:
UFM2CSV mat text
dumps a “binary” matrix mat.ufm into a csv-formatted text file ‘text’ – or, if the
second parameter is not included, into a default value mat.txt. It therefore follows
(automatically) the procedures described in 10.15.1 (option 4).
A number of varieties of UFM2... exist, essentially one for each of the various
output options described in 10.15.1. Thus:
5120257 / Apr 15 10-56

Section 10
♦ UFM2SATL – dumps in SATURN “long” format
♦ UFM2SATS – dumps in SATURN “short” format
♦ UFM2LINE – dumps single records for non-zero cells
♦ UFM2CSV – dumps as CSV (Comma Separated Variables)
♦ UFM2EMME - dumps in EMME/2 format
♦ UFM2TBA1/2/3 – dumps in Tuba 1/2/3 formats

By default the output text files use decimal formats with 2 decimal places
(10.15.2). To change either it is necessary to change the parameters EFORM and
NDPS respectively in the preferences file MX0.DAT.
These procedures are designed to make life easier for users who wish to transfer
SATURN matrices into other suites of programs, e.g., EXCEL, in order to make
use of particular facilities. To transfer them back into SATURN a complementary
set of procedures CSV2UFM, etc. are also provided; see 10.20.14 below
N.B. These procedures only work with release 10.6 and beyond of SATURN
although the .ufm files used and/or created will work with previous releases (within
reason).
10.20.16 …2UFM: Re-build UFM Matrices from Text Files

E.g.:
CSV2UFM mat
re-creates the “binary” matrix mat.ufm from a csv-formatted text file mat.txt. It
therefore follows (automatically) the procedures described in 10.5.5 but with the
proviso that the file mat.ufm already exists so that it is “updating” rather than
“building”. Thus the “new” version of mat.ufm takes all its “structure”, i.e., the
number of rows and columns, the zone names etc., from the “old” mat.ufm but re-
sets all its cell values as read from the .txt file.
Note, therefore, that these procedures are essentially “restore” or “rebuild” rather
than “build from scratch”. If you do wish to create an entirely new .ufm from a .csv
data file you should follow the interactive procedures outlined in Section 10.5,
preferably entering the program MX via the “batch file” command (see 10.1):
MX I
At a future date the ..2UFM batch files may be made sufficiently “clever” to detect
when a .ufm matrix does not pre-exist and must be built totally from scratch.
Essentially the …2UFM procedures are the reverse of the UFM2… procedures
described above; the latter converts a .ufm file into text, the former converts a text
A number of varieties of …2UFM procedures exist:
♦ LINE2UFM
♦ CSV2UFM
5120257 / Apr 15 10-57

Section 10
♦ EMME2UFM
♦ TBA12UFM
♦ TBA22UFM
♦ TBA3AUFM
following the conventions described in 10.20.13.
Specifying formats and/or decimal places is less important in reading from text
files than in writing to them (see 10.20.13 above) since, in general, the input
routines can detect whether a field is, say, E-formatted and deal with it as
appropriate.
Note that there are no procedures SATL2UFM or SATS2UFM as these are
effectively covered by the standard matrix build procedure MXM1 (See 4.1).
10.20.17 UFMSTACK: Stack a Set of Matrices based on a Control File

UFMSTACK control QUIET
Outputs a “stacked” matrix using a set of filenames read from a text file “control”.
More specifically the first record in control gives the name of the output matrix to
be stacked while each following record lists a sub-matrix to be stacked. The
number of matrices to be stacked is therefore dictated only by the number of
records in the file. Thus it is not otherwise restricted by the number of matrices (8)
that MX can store internally (unlike MXSTACK, 10.20.9) since each matrix to be
stacked is read, copied and then closed immediately.
If the second parameter is ‘QUIET’ then the program runs in quiet mode; see 14.9.
10.20.18 UFMUNSTACK: Unstack a Matrix based on a Control File

UFMUNSTACK control QUIET
Unstacks a matrix into a set of sub-matrices using a set of filenames read from a
text file “control”.
As with UFMSTACK the first record in “control” gives the name of the .ufm matrix
to be unstacked while each following record lists a sub-matrix. The number of sub-
matrices should be equal to the number of levels in the stacked matrix but is not
otherwise restricted.
If the second parameter is ‘QUIET’ then the program runs in quiet mode; see
14.9.Clearly UFMUNSTACK is the converse of UFMSTACK and the same control
file may be used for both.
10.20.19 MXDOT2: Take the “dot” product of two matrices

MXDOT2 mat1 mat2 mat3
Takes the “dot product” of matrices mat2.ufm and mat1.ufm together to produce
an output file mat 3.ufm; i.e.:
5120257 / Apr 15 10-58

Section 10
Tij3 = Tij1.Tij2
I.e., each cell element in matrix 1 is multiplied by the corresponding cell in matrix 2
so that if, say, matrix 1 is a trip matrix (pcus/hr) and matrix 2 is a skimmed time
matrix (hrs) then the resultant matrix is a matrix of pcu-hrs/hr.
N.B. This is not the normal mathematical definition of matrix multiplication but one
that is probably far more commonly used by network modellers.
10.20.20 MXM5: Matrix Compression, Expansion and/or Reordering

MXM5 mat 1 mat2 control
Outputs a new matrix file mat2.ufm based on the input matrix mat1.ufm but with a
different set of zone definitions. Thus the existing zones may be combined
together (aggregated), split (disaggregated), names changed, factored, etc. etc.
according to the instructions in the control file control.dat. See Appendix W.3 for
the formatting of control.dat.
Similar operations may be carried out interactively as described in Section 10.4.2
and in 10.16.3.
10.20.21 MXAGG: Aggregate Matrix Levels into a Square Matrix

MXAGG mstack msquare L1 L2
Outputs a “square” matrix msquare.ufm from a stacked matrix mstack.ufm by

aggregating together all levels from L1 to L2. If L1/L2 are not explicitly included
then all levels are aggregated. See 10.2.4 and 10.4.2.
10.20.22 MXZ2G: Aggregate a Zonal Matrix into a Group-to-Group Matrix

MXZ2G matz matg (FILZ2G
Compresses a “zone-to-zone” matrix matz.ufm into a “group-to-group” matrix

matg.ufm according to the grouping of zones into “groups” defined either by the
optional file FILZ2G or using the pre-defined zone-to-group mapping in matz.ufm.
See 10.2.5.5 and 10.16.4.
10.20.23 MXZ2B: Aggregate a TFL Zonal Matrix into Traffic Boroughs

MXZ2B matz matb
Compresses a “zone-to-zone” matrix matz.ufm into a “borough-to-borough” matrix

matb.ufm whereby the grouping of zones into “traffic borough” follows the naming
conventions used by TfL. See section 5.1.7.2 and 10.2.5.4.
10.20.24 MXG2Z: Expand (De-compress) a “group” matrix back to a zonal matrix

MXG2Z matg matz FILZ2G
Expands (de-compresses) a “group-to-group” matrix matg.ufm into a “zone-to-

zone” matrix matz.ufm based on the the grouping of zones into groups defined
either by the file FILZ2G (optional) or using the pre-defined zone-to-group
mapping in matg (recommended). The assumption is that matg.ufm has
5120257 / Apr 15 10-59

Section 10
previously been compressed from a zone-to-zone matrix using MXZ2G according

to the same zonal groupings in FILZ2G.
Note: MXG2Z sets all intrazonals to zero. See also 10.2.5.5 and 10.16.5.
10.20.25 MXDIVIDE: Divide one matrix by another cell by cell

MXDIVIDE mat1 mat2 mat3
Divides each cell in mat1.ufm by the corresponding cell in mat2 and outputs file
mat3.ufm; i.e.:
𝑇𝑖𝑗1
𝑇𝑖𝑗3 =
𝑇𝑖𝑗2
If T ij 2 = 0 then the output value is always taken as 1.0.

MXDIVIDE may be used, for example, to establish the growth factors of one trip
matrix relative to another.
5120257 / Apr 15 10-60

Section 10
5120257 / Apr 15 10-61

Section 10
P1X: Interactive Analysis of Results
11. P1X: Interactive Analysis of Results

11.1 Introduction
The SATURN network analysis program P1X combines together the functionality
of four original analysis programs, P1, SATLOOK, SATDB and SATED, plus extra
functions such as network cordoning (SATCH), signal optimisation (SATOFF) and
network building (SATNET) into a single multi-purpose network analysis program.
In brief SATLOOK caters for alpha-numeric output and analysis of .ufs files, P1
provides graphical analysis and network editing, SATED edits simulation nodes
and SATDB provides spreadsheet-like facilities. Since the four basic functions
are relatively distinct it is often useful to refer to them by separate program names.
SATLOOK and SATDB (plus, strictly, SATED although it has been largely phased
out) exist as separate programs although they may also be accessed directly
through the top menu in P1X.
P1X (plus SATDB and SATLOOK) runs primarily in an “interactive mode”, i.e.,
with all requests for options, etc. input directly via menus as opposed to the “batch
mode” with instructions pre-set in a control file. Basic principles are described in
Section 19. However all these programs can also be run in a “quasi-batch” mode
by setting up a “key” terminal input file with the desired responses in the correct
order (See 14.5).
Function-specific information is given in Sections 11.2 to 11.15 and technical
specifications in 11.16 to 11.19. These sections are fairly general in nature since
the programs are designed to be “self-documenting” in that the menus should be
self-explanatory and these in turn are backed up by a “help system” as explained
in 19.11.
To run any of these programs under DOS or Command Prompt simply type the
program name followed by one or more “command line” parameters to request
certain network files, e.g.
P1X LIV93
to examine the network file LIV93.UFS. For full format instructions type P1X etc.
on its own. (See also 14.1)
Note that all interactive programs automatically produce “line printer” files which
contain a permanent record of most of the interactive steps, relevant inputs and
outputs etc. plus (since release 11.2.11) a full listing of the “LOG” file generated
during execution (see 14.5.1)
11.2 Network Plotting (P1X): The Master Menu

The graphics program P1X contains virtually all the analysis functions provided
within SATURN, including those functions previously available only in SATED,
SATDB and SATLOOK as well as the cordoning program SATCH. The SATDB
and SATLOOK sub-modules, which are text - as opposed to graphics-based - are
entered from the main P1X menu; documentation for them is found in sections
11.10 and 11.11 respectively. SATED-style node graphics options are entered
either from the top menu or from within network editing.
5120257 / Apr 15 11-1

Section 11
On first entry to a run of P1X and on subsequent returns the “master menu” allows
access to a large set of sub-menus which may be classified into (with further
information given in the sections noted):
1) System/device definitions; 11.3.
2) File control; 11.4.
3) Network Windowing; 11.5.
4) Basic network display (including GIS, 5.7.1); 11.6.
5) Validation options; 11.7.
6) Analysis Options; 11.8.
7) Information Options; 11.8.4
8) Convergence statistics, 11.15
9) Edit options (including both network, GIS and PMAKE); 11.9.
10) SATDB-based facilities; 11.10.
11) SATLOOK-based facilities; 11.11.
12) Node graphics (SATED) display; 11.12.
13) Network cordoning (SATCH); 11.13.
14) (Pure) Matrix graphics; 11.14.
Certain of these facilities may also be accessed at points in the program other
than the “master” menu by commands in the menu bar. For example you may
change the network window, the network display options and (some) system
parameters from most locations within P1X. See 19.5. In addition a number of
other functions are only available through the menu bar; see, for example, 11.5.3.
To return to the master menu from any sub-menu within P1X click on “Master
Menu” under “Back” in the Menu bar and further select any of the 13 standard
“top” menus listed above (or the master menu itself) via the sub-list.
11.3 System/device Definitions
11.3.1 The Graphics Device Definition file GRAF.DAT

Users of 32-bit SATURN need probably not read this sub-section as under e.g.
WINDOWS 98 or NT, output to graphical devices makes use of WINDOWS
drivers which, thankfully, are largely self-sufficient. Thus output goes either to the
“screen” or the “printer” (the “alternative” device), whose essential properties are
available through the operating system. Hence the file graf.dat becomes largely
optional. However a certain amount of “fine tuning” in graf.dat may be useful for
SATURN users, e.g. to control the size of output text-note (v) below.
Before P1X (or any other graphics program) can produce graphical output it
requires certain minimal information about the device(s) to which the output is
directed. For example, it may need to know the device dimensions in order to
5120257 / Apr 15 11-2

Section 11
correctly scale the plot. This information is contained in a supplementary file with
the standard name ‘GRAF.DAT’ which contains all the information necessary to
“tell” the program about the output devices available to it. It is therefore
installation-specific.
The following data needs to be supplied for each potential device:
(i) Whether it is a vdu screen or a hard copy device. (A “screen” is any device
for which column 30 on the first record for that device contains a 1 or greater
whereas a “printer” contains a zero.)
(ii) Its maximum X and Y dimensions, both in physical millimetres and in
(device) pixels.
(iii) The number of “pens” (/colours) available (SATURN programs assume 16
but the output device may have fewer, in which case it is necessary to “map”
the 16 SATURN colours into the smaller set.)
(iv) “Pen mappings”, either for the above reason or if, say, you wish to have
output in red when SATURN thinks it is outputting in green.
(v) Various universal scaling parameters to, for example, make the output text
characters bigger or smaller.
For a full description of the contents of GRAF.DAT, its format etc the reader is
referred to the file itself which, after the initial data set, contains documentation.
A standard version of GRAF.DAT is supplied with SATURN with a number of
standard device definitions; users may well need to modify this file to suit their
own available devices. If for any reason a SATURN program cannot locate
GRAF.DAT an internal default set of device definitions is used. This contains
specifications for common device types - the screen and printer under 32-bit as
mentioned above - and should therefore be sufficient for most users’ applications.
11.3.2 The Primary and Alternative Devices (Screen and Printer)

P1X (and any other programs that use graphics) define two “active” devices, a
“primary” and an “alternative” or “secondary” device. Output is directed initially to
the primary device which, logically, must be the monitor screen. However output
may also be sent to the alternative device which, equally logically, must be a
printer or other hard copy device (or a file destined for hard copy); see 11.3.5.
On entering the program the first two devices in the GRAF.DAT list or its internal
default become the primary and alternative devices. The default makes them
“screen” and “printer”. Either may be changed within the System/Device menu -
see 11.3.3 - although the primary device must always be a terminal (so little
choice there) but the alternative device will need to be changed as output is to be
directed to a different device.
To send output to the alternative device use the “Print Graphics” option under
Files in the menu bar (or, very occasionally, select the appropriate option in the
banner, generally either A for Alternative or P for Print).
5120257 / Apr 15 11-3

Section 11
Another form of “alternative” output is output to bitmap files or the clipboard

(11.3.6), the difference being that in these cases the “device” being used is fixed,
not user set.
11.3.3 The System/Device Menu

Having initialised the primary and alternative devices and their characteristics the
System/Device Menu allows one to either select other devices (primary or
alternative) or to redefine certain properties of the current devices. Under 32-bit
SATURN only the latter functions are generally relevant as the default devices -
screen and printer - are fine for most purposes.
The choices within the System/Device menu may be summarised as follows:
(i) Definition of the primary and alternative devices (11.3.2).
(ii) Parameters for the primary and/or alternative device. (11.3.4)
(iii) General properties of the “pens” or colours; e.g. choice of the background
colour. (11.3.7)
(iv) Colours/pens used in the banner. (11.6.9)
(v) Choice of the “root” filenames used by bitmap files (11.3.6)
(vi) Choice between mouse and keyboard control (19.4).
(vii) Left vrs. right-hand drive (available elsewhere as well).
Note that a reduced version of this menu - with the device choices removed - is
available under “Show” in the menu bar (32-bit version).
11.3.4 Device Parameters

The parameters submenu controls the interface between the commands issued by
the program and what appears on the screen/printer. It is, for example, most
useful if the characters on the screen appear to be too large or too small or if the
size of, say, node shapes are disproportionately too small or too large.
Separate menus for the primary and alternative devices are provided.
The following “parameters” are (potentially) relevant to both:
(i) the physical width and height of the device (in mm)
(ii) the maximum “shrinkage” acceptable for characters (e.g. 0.5 implies that
characters may be reduced in size by 0.5 in order to fit the space provided
before they are likely to become indecipherable.)
(iii) The desired standard height of characters (in mm).
(iv) A correction factor (which ideally should be 1.0 but often needs to be 1.35)
for all character sizes.
(v) The ratio of character width to height.
(vii) The pixel resolution of the device being used
5120257 / Apr 15 11-4

Section 11
(viii) A “rotational shift” to empirically correct problems with annotation which is

rotated from the horizontal or vertical.
(ix) The standard pen definitions (11.3.7)
(x) Font controls including “DIY” fonts (11.3.8)
11.3.4.1 Device Height and Width

Height and width values are important so that the program “knows” if it is sending
output to, e.g., an A4 or an A0 device. For example, if a program wishes to draw
a box 20mm wide and it “thinks” the device is 200mm wide it draws it as 10% of
the width; if the actual width were 400mm then the box will come out as 40mm.
Getting the dimensions right is therefore most critical with “non-standard” devices
such as A0 plotters.
To help in getting the dimensions right (for the secondary device, e.g., printer)
users may alternatively define the device “size”, i.e., A0, A1, etc., plus whether or
not it is “landscape” or “portrait” (although it is quite likely that the Windows driver
itself will decide which way a plot best fits an output device). The program then
supplies the appropriate standard width and height automatically.
11.3.4.2 Character Heights and Sizes

The standard character height (5mm by default) and the correction factor play
similar roles in that both can change the size of characters plotted. Our advice
would be to set the standard height to whatever you do want and then, if the
resulting characters are too large or small, correct via the correction factor (see
below).
The ratio of width to height should be adjusted if, say, the node numbers within a
node shape are the right height but are too wide/not wide enough.
11.3.4.3 Correction Factor

A common situation, illustrated below, is that characters in the banner are too
large and may both overlap vertically as well as not fitting horizontally into the
(nominal) 40 mm width of the banner; in this situation the correction factor needs
to be reduced. Alternatively (not illustrated) the characters in the banner may be
too small, in which case the correction factor needs to be increased.
5120257 / Apr 15 11-5

Section 11
The correction factor compensates for poor communication between the programs
and the device drivers and is related to the device/screen resolution. Ideally the
correction factor should be 1.0; however, empirically, a value of 1.35 appears to
be required for the majority of screen settings to which SATURN is applied and
that is therefore (currently) the default.
Generally the problem of over-sized characters occurs with low-resolution screen
settings; therefore one solution to the problem may be to increase your screen
resolution. If this is not feasible or does not work the only alternative is to adjust
the correction factor within P1X. From the menu enter “Primary dev”, select
Correction Factor and input a new value. Some trial and error testing may be
necessary.
Since the default value, i.e., the 1.35 above, is read from the graf.dat control file
users may also wish to change graf.dat. This may however be a bit difficult with
networked computers if the same central version of graf.dat is being used by a
number of different machines.
The same considerations apply to the alternative (i.e., printer) devices if output
characters are universally over- or under-sized; either change the correction factor
for the secondary device interactively prior to printing or (preferably) ensure that it
is changed in graf.dat. Unlike terminal screens, however, a default value of 1.0 is
probably fairly safe.
11.3.4.4 Rotational Shift

The “rotational shift” parameter is provided as an empirical fix to a problem which
may occur with certain devices (both screen and printer) when annotating text at
5120257 / Apr 15 11-6

Section 11
an angle (e.g. annotation along a link in P1X). Thus you may observe that the link
annotation, which should appear “just above” or “just below” the line may, be
shifted away/towards the line. The rotational shift parameter (defined as fractions
of character heights) moves the text up or down depending on the sign. N.B. It
has no effect on either horizontal or vertical annotation where the problem does
not occur.
A more drastic solution to the same problem is to use a set of SATURN “DIY”
fonts as described in 11.3.8.
11.3.4.5 Pixel resolution

The pixel resolution should, in theory, be for information only since a clever
computer plus program should be able to work it out for itself. It is provided on the
basis that if nothing else works then changing the pixel resolution may improve
your outputs. Use with caution!
Changes made here should probably be made “permanent” for your installation by
editing them into your version of GRAF.DAT; otherwise you may need to repeat
the changes every time you enter P1X.
11.3.5 Hard Copy and/or File Outputs

Hard copy output from SATURN graphical programs may either go “directly” to a
device such as a printer or plotter which is connected “on line” or “indirectly” via a
file which is subsequently spooled to an appropriate device. Clearly in the latter
case multiple copies may be created as desired.
Hard copy output is selected using “Print Graphics” under File in the Menus Bar
which then brings up a standard Windows Printer Dialog Box. Use this to select,
e.g., whether the output is to go directly to a file or to a device; in the latter case
you may need to nominate the device if more than one is available.
The “characteristics” of the hard copy device are set by default within GRAF.DAT
but may be over-written within the program (11.3.4). In particular, note the
importance of defining the physical width and height of the device correctly as
they may affect the “quality” of the output.
Hard copy output normally includes everything that appears on the screen
although if the output device is bigger than the terminal screen you may get more
numbers annotated because there is more space available. However, optionally,
using a parameter set within the Banner Display Menu (11.6.9), the menu choices
displayed within the banner may be excluded from the output hardcopy/file.
Certain problems may occur with hard copy outputs to printer; see 11.3.9 for
further details.
11.3.6 Bitmap Files: Output and Input

Salford FTN77 compilers include options to “dump” the screen image into an
external “bitmap” file. These files may then be re-read by certain programs and
re-displayed on the screen. For example they may be accessed by the
“paintbrush” program with Windows and by Harvard Graphics and, if necessary,
re-directed to hard copy devices via these programs.
5120257 / Apr 15 11-7

Section 11
Equally bitmap files may be used as inputs to P1X and displayed, e.g. as
“background” to SATURN plots. A “default” bitmap file may be defined via the
parameter FILBMP under &PARAM network parameters in the network .dat file;
see 6.3.4 and 15.43.
Alternatively, (post release 11.3.11), FILBMP need only define the folder in which
the required bitmap files are located. Thus FILBMP = ‘C:\bitmaps\’ defines a
folder, FILBMP = ‘C:\bitmaps\one.bmp’ defines an individual file. The advantage of
setting the folder is that it makes much easier to search for bitmap files
interactively.
Bitmap files open up all sorts of interesting applications, for example directly
inserting SATURN graphics into word-processed documents or putting your own
logo onto a SATURN plot. However there are restrictions as to the type of files
which FTN77 can import and export so that SATURN is effectively restricted to
“pcx” and “bmp” files and screen images sent to and from the clipboard.
To create an output bitmap file choose either pcx, bmp, jpg (post release 10.8.20)
or clipboard through the menu bar (under Files). If pcx, a file with extension “.pcx”
is then created. The initial part of the “pathname” is composed from a “root” which
may be set within the Systems/device menu (11.3.3) and a sequential number.
Thus, if your root name is “harry”, the output files are, in succession, harry1.pcx,
harry2.pcx, etc. Similarly, if bmp, the output files will be harry1.bmp, etc etc.
Optionally, using a parameter set within the Banner Display Menu (11.6.9), the
menu choices displayed within the banner may be excluded from the output
bitmap file.
SATURN also allows bitmap files to be read as input files and displayed on the
screen so that they may be used as a “background” to a P1X plot. Thus you may
superimpose P1X plots on, e.g., OS-style plots of the same area. See Section
15.43 and under PMAKE, section 18.
Note that, at the moment (release 10.8.20), only .bmp and.or .pcx files may be
input, not .jpg. It is hoped that jpg inputs will be made available shortly.
11.3.7 Pen/Colour Definitions

SATURN plots normally use 16 colours (defined with standardised palettes) and
each plotted element uses one of the 16. It is possible for users to select different
colours in two different ways:
♦ global changes;
♦ individual applications.
Thus under global pen changes it is possible to “map” one pen into another. For
example if the standard pink pen (#13) is very faint on your device it may be
mapped into, say, the red pen (#4) using the Pen Definitions menu under
System/Device.
Alternatively if one particular application uses a colour you don’t like, for example
the pen colour used to annotate nodes on link plots, then there are menus where
particular pen definitions may be changed without making that change global. In
5120257 / Apr 15 11-8

Section 11
particular, the “background colour” of the plots (which defaults to white) may be
re-set within this menu.
11.3.8 Alternative Fonts

Generally speaking the “fonts” used to display alpha-numerics to the screen or
printer are those supplied by the device driver as activated via the program using
Salford FTN77 commands. These are largely outside the control of the user.
However it has been found that with certain hard copy devices (apparently only
those larger than A4) annotation which is being written “at an angle” (i.e. neither
on the horizontal or vertical) sometimes (not always and not always consistently!)
appears in the wrong position with the wrong orientation. And nobody in Salford
can explain why! Part of the problem may be solved using the Rotational Shift
(11.3.4) but empirically this is not fool-proof.
To deal with this problem an empirical fix has been added (Version 10.3) which
uses an alternative set of character fonts for hard-copy annotate-at-an-angle only.
These fonts are based on relatively simply DIY principles of drawing characters as
a sequence of short lines so that they lack the sophistication of “proper” fonts.
However they do at least appear where they are meant to appear and at the
correct orientation and are damn sight better than the alternative!
To select the DIY font for the secondary device “toggle” the appropriate option
within the menu Parameters: Second dev. under the System/Device menu. Note
that the option does not appear for the primary device since the problem does not
occur there.
By default the characters drawn by the DIY font are one pixel wide which, for most
devices, is rather faint. Therefore a finite “thickness” may be set to improve
legibility; generally speaking values of the order of 0.3 mm should be sufficient.
11.3.9 Problems with Hard Copy Outputs

Certain problems may arise when plotting to the printer (PrintGraphics under Files
in the Menu Bar). For example, sometimes (at random) instead of giving you a
dialog box it, in effect, returns Cancel and nothing gets plotted. Empirically this
appears to happen more frequently in certain specific situations, e.g., trying to
print select link flows.
We have put in an empirical fix so that once you have been through the printer
dialog box once if, subsequently, an erroneous return of Cancel occurs the
program goes ahead and plots using the same plotter parameters as previously
set. So, e.g., you cannot select a different plotter without the dialog box.
The only problem is that you may get the Cancel return the first time you ask for a
plot, in which case there is nothing to go back to. The solution is to do at least
one plot to your desired device as early as possible to make sure that the device
is correctly recorded. If it returns Cancel keep trying until you do get a dialog box.
You might need to exit the program and re-run it but as far as I know nobody has
had to go that far yet.
With an A0 output device this may mean producing one large plot that you don't
need. One way around this (untried as far as I know) is to send the output to a
5120257 / Apr 15 11-9

Section 11
file, rather than the A0 device directly, and only spool those print files that you
really need. But quite how you spool printer (.prn?) files later on I have no
experience with.
11.4 P1X External File Control

The choice and control of external files within P1X is largely handled within the
“files sub-menu” 1 which in turn is sub-divided into inputs and outputs.
Under 32-bit the “top” files menu also allows one to set the “default” definition of
bitmap files - pcx, bmp or the clipboard; see 11.3.6.
11.4.1 Input Files

Input files include at least one network .ufs(/ufa/ufn/etc) file (“network 1”) which
determines the basic display plus, optionally, up to three further network files.
Typically the latter files could represent alternative scenarios of the same basic
road network and therefore they may differ either topologically (i.e. more or fewer
links) or by attribute (i.e. different flows).
Of these only “network 2” can be directly used in the actual network plot; for
example you may ask for the plot to be a “union” of networks 1 and 2, in which
case any extra links in network 2 which do not appear in network 1 appear on the
plots as links with a different colour; see also 11.6.4.
However data from all 3 (as defined) alternative networks may be accessed using
the SATDB-based sub-options within P1X and their attributes viewed “indirectly”
by the P1X graphical and annotation displays. See 11.6.2.3.
Further (optional) input files include:
a) Two matrix files associated with the network(s) plus a further matrix file
which is the trip matrix used in the network assignment. Initially, by default,
matrix 1 is also the trip matrix, but it is perfectly possible to have up to three
separate matrices defined within a single run.
b) The original .dat file from which network 1 was created in SATNET is also
read in (if possible) and copied into an internal direct access file for editing
purposes; see 11.9.2.
c) A “.xy” file containing updated co-ordinates. (Node co-ordinates are
generally obtained from the input network 1 file but they may also be over-
written by inputting a .xy file. See 11.9.7. Thus it may be much simpler for
users to work with “temporary” .xy files with updated co-ordinates than to
have to continually revise the original .dat files and to re-run a complete
SATURN procedure before re-entering P1X.)
d) A GIS file (see 11.6.10).
1 Certain options may either read or create external files on an “open-and-close” basis; the files
referred to here generally exist throughout the program.
5120257 / Apr 15 11-10

Section 11
e) A bitmap or pcx file which may be used as a background to the network plot
(see 11.3.6).
f) A “.wxy” file which contains old plot window definitions; see 11.5.2.
11.4.2 Output Files

The following files (in addition to plot files) may all be output from P1X via the
“Files Menu” (or elsewhere):
1) An (updated) network .ufs file; see 11.9.2.2
2) An (updated) network .dat file; see 11.9.2.1
3) An (updated) preference file (P1X0.DAT; see 11.4.3)
4) A file of (updated) X,Y co-ordinates (11.9.7);
5) A text (ASCII) file of all links in all (bus) routes;
6) A “re-created” version of the original network .dat file obtained from the data
contained in the input .uf* file; see 11.4.2.1.
7) A text (ASCII) file containing, one record per real node (i.e., excluding zones),
the node “name” and its internal sequential map number; see 11.4.2.2.
8) A text (ASCII) file containing, for every “map” link AB (i.e., the lines that
appear on the network plot from, node A to node B), a single record in the
format specified for 33333 .dat files; see 11.4.2.3.
In addition various forms of ASCII sub-files, .ufm matrix files etc. may be output
during the course of various sub-options within the program.
11.4.2.1 Recreating Network .dat files

Recreating a .dat file, option 6 above. is basically useful when the original .dat file
has been “lost”. It is possible to prevent this option being available, for example if
you are intending to “lend” a .uf* file to a colleague but don’t want them to have
the .dat file information, by setting the network input parameter SECRET (6.3.1) to
.FALSE.
Clearly if the original .dat file is available to the user/P1X then the value of
SECRET is immaterial. For example, setting SECRET = T will not prevent a user
dumping a .dat file as part of the Network Editing options but this option is only
available if P1X has access to the original .dat file in the first place.
Option 6) should be used with great care since it is difficult to re-create the exact
form of the .dat file used in the original input to SATNET just working from .ufs file.
For example, it is never very clear whether a variable which is equal to the default
value has been explicitly defined in the correct location in the .dat file or whether it
was left blank/zero and the default value substituted. Equally any comment
records and insertions in the original file are lost using this option.
The difference between options 2) and 5) is that option essentially copies an input
.dat file – and includes any editing changes – whereas option 5) effectively starts
with a blank sheet of paper.
5120257 / Apr 15 11-11

Section 11
11.4.2.2 Lists of Map Nodes

Creating a list of map nodes, option 7) above, is most useful when there are two
input network files and the map displayed is a “union” of the two networks such
that the output file contains a reference to all nodes which occur in either file
(11.4.1). In turn this may be used as an input to SATCOBA (15.42.6) where it is
desired to create a COBA file which contains a common node numbering system
for two networks.
11.4.2.3 Lists of Map Links

Option 8) creates an output text file which contains a record for every directional
“map” link AB (i.e., a line appears on the network plot from node A to node B) in
the format specified for 33333 .dat files (Section 6.6). Thus if AB is a two-way link
then there will be separate records for A to B and for B to A.
Options exist to select either all map links (including centroid connectors) or a
subset. One may select/de-select simulation links, buffer links, simulation centroid
connectors and/or buffer centroid connectors. As per the network Namelist
variable NO333C one may opt to either include a C before every zone number or
exclude it (NO333C = F or T respectively)
Furthermore one may choose to output full link data such as link distance, free
flow time, capacity index etc. etc. in the formats specified in 6.6 or to simply output
the A-node and B-node.
Map link listings are useful for converting SATURN networks into a form that might
be suitable for creating an equivalent network using a GIS system such as
MAPINFO or ARCINFO (and for which a dump of node co-ordinates would also
be extremely useful). See Section 23.2. They may also be used to convert
simulation centroid connectors into a form that could be used with a buffer
network definition; see SATCCS in Section 15.8.3.
The identical output option is also available within Network Editing; see 11.9.2.6.
11.4.2.4 Lists of (Bus) Routes

Option 5) creates a text file with one record for every link and for every route and
is, at the time of creation (September 2014 for release 11.03.07), in very much an
ad hoc format. Thus each record per link per route contains 4 items:
1) The text name of the route,
2) The sequential link number within that route,
3) The A-node of the link and
4) Its B-node
11.4.3 P1X Preferences file: P1X0.DAT

P1X requires a “preferences” or an “initialisation” control file P1X0.DAT in order to
set default values for various parameters which control for example, the size of
arrows in node graphics.
5120257 / Apr 15 11-12

Section 11
The general principles are described in 15.2. Thus if you wish to permanently
change arrow dimensions you must use the appropriate menus to change the
values within that particular program run; then, at some later stage of the same
run, output an updated version of the preferences file such that the new parameter
values become the defaults.
Note that some care is needed with file management here in that a new output
preferences file is, by default, stored in your current sub-directory whereas the
default file read on input may be stored in another specific sub-directory. You
must therefore either explicitly create the new file in that sub-directory or else copy
your output file into it after the program run.
The preferences file P1X0.DAT is rather long and what the parameter “names”
represent is not always obvious. Version 10.5 has added short explanations as
“comments” on the right-hand side of each definition record but the list is still only
partial. All queries to either Atkins or DVV.
11.4.4 P1X Resume File: LAST_P1X0.DAT

In addition to the main preferences file P1X0.dat each run of P1X automatically
produces a “quasi” preferences files last_p1x0.dat which contains a full list of the
current parameter choices, including the full set of windows co-ordinates, at the
conclusion of that run. By choosing the option “Resume Last” at the start of the
subsequent run of P1X the conditions at the end of the previous run are
reproduced exactly, including the final window.
Equivalently the “resume last” option may also be invoked by including the key
word “RESUME” on the command line.
Note that the resume file also contains all the saved windows from the previous
run, including any which have been saved in a .WXY file.
11.4.5 P1X KEY Files: Initiated Internally

As documented in Section 14, P1X may be run in a quasi-batch mode using an
input “KEY” file to define a pre-prepared sequence of commands. Following
release 11.2.10 it is also possible to start a run of P1X in the normal interactive
mode but to shift to the KEY file mode during execution. The option is selected
from the Files Menu which then requires the user to select the appropriate KEY
file.
The objective is to allow users to set up a series of “mini” KEY file operations that
they may run as and when required and in any order.
11.5 The Network Window
11.5.1 The Main Window

P1X plots a rectangular area or “window” of the network, the precise definition of
which may be determined in several different ways, e.g.:
1) The entire network is plotted.
2) A “central” node plus radius.
5120257 / Apr 15 11-13

Section 11
3) The “corners” are set by direct manipulation, e.g. by moving the window or by
defining them with the mouse.
The choice of the initial window (by default the full network) is described in Section
11.5.6 below.
Once set up the “window” may be moved or re-defined using a range of options
described next.
At the simplest level the window may be shifted UP, DOWN, LEFT and RIGHT by
standard amounts or expanded/reduced (PAN/ZOOM) by key commands (Note
that “Pan” is used as the opposite of “Zoom”.)
A new form of shifting the window, denoted by MOVE, has been introduced in
10.8. MOVE allows the window to be shifted in any direction and by a variable
degree. The direction of shift is determined by the position of the mouse relative to
the centre of the plot and the amount of overlap by its distance from the centre. By
contrast, LEFT, RIGHT, etc. can move in four directions only by fixed amounts.
The “BOX” option allows the user to set a sub-window within the current window
by first clicking on a corner with the mouse and then clicking on the opposite
corner. The new boundaries are displayed as “rubber bands”. Selecting outside
the current window is not permitted.
5120257 / Apr 15 11-14

Section 11
“DRAGing” is accomplished by first selecting a node on the current plot (point and
click) and then clicking on a new point within the current window for that node to
be moved to. This is particularly useful when a bitmap background map is being
used and you wish to correctly locate the plotted map on the background.
In a similar way the “SCALE” option allows two nodes to be located at their
desired position, in which case the plot is not only shifted but scaled up or down
as well.
In all cases the (user) co-ordinates of the four corners of the plotted window are
held in variables Xmin, Xmax, Ymin and Ymax where X refers to the horizontal
and Y to the vertical. For more precise positioning these variables may be set
explicitly (useful for selecting the same area as in a different run, although see
11.5.2 below for an alternative method).
11.5.1.1 “Full” vrs “Part” Screens

In general the window is contained within an outer rectangle with the banner to the
right or top as requested. However in the case of, say, a long narrow window this
will not use the full screen so an option exists such that the rectangle plus banner
use the full width/height of the screen and the network plot is centered within the
available space. This is selected by “toggling” between “full screen” and “part
screen”.
Alternatively if the network plot does not occupy the “full” window “fill screen”
extends the X, Y boundaries to fill the space available.
11.5.2 Recording Windows and .wxy Files

Once defined up to 10 window definitions in terms of Xmin etc. may be “saved”
internally within the current run of P1X so that the user may return to them at a
later stage. Choices on offer include the original window, the immediately
previous window or any other saved window.
Each “saved” window may also have a text “name” added (up to 32 characters) to
help in identifying that window at later stages.
In addition the current set of “saved” windows (co-ordinates plus text) may be
permanently saved by “dumping” them to an external ASCII file whose standard
file extension is wxy. Wxy files may also be input to other runs of P1X (11.4.1)
such that a useful window created in one run can be repeatedly accessed in the
future.
11.5.3 Returning to Previous Windows

As an alternative to explicitly remembering selected windows P1X automatically
records the previous 10 windows so that the option “lasT window” will return you
to the previously defined window. However any windows beyond 10 are not
saved, hence the potential need to “save” them as per 11.5.2.
11.5.4 The Auxiliary Network Plot

In addition to the main “window” plotted an “auxiliary” network plot may also be
displayed by clicking “Aux.Net.Graph” under Show in the menu bar. The auxiliary
5120257 / Apr 15 11-15

Section 11
network plots either the entire network or an area with the current main window at
its centre (depending on which one is smaller) at a reduced scale in the lower right
hand corner and with only links displayed as straight lines; i.e., no annotation,
node information etc.
The useful bit however is that the current main window is illustrated as a red
rectangle within the plot, thus showing you where the current window is located
within the full network. See below.
If the window is changed in any way then the “new” auxiliary plot will appear
automatically. However if any other operation is requested the auxiliary plot is
minimised.
The auxiliary network plot also functions within node graphics (11.12.3), in which
case the currently selected node is marked as the centre of a red rectangle within
a larger section of the network.
11.5.5 Navigation Options in the Menu Bar and On-screen

The basic “shift the window” operations may be requested not only via selections
from the standard banners on the right-hand side of the plot but also via a series
of “navigation” options included within the Menu Bar at the top of the screen. Thus
clicking on Nav-R shifts the window to the right, Nav-D shifts it down, etc. etc.
Alternatively by clicking on the small green arrows in the middle of each face the
window may be shifted up, down, etc. Equally small arrows in the corners allow
shifting at 45 degrees and 2 small red circles with +/- signs zoom in/out.
5120257 / Apr 15 11-16

Section 11
Users should find these facilities simpler and more intuitive than operating through
the banner or via the pull-down options under Window simply because the mouse
does not move after the click-request so that if, for example, you wish to
continually zoom in more than once it is simply a question of locating the mouse
over Nav-Z and clicking repeatedly to zoom in continuously.
Note that it is normally quite helpful to turn on the auxiliary network plot (see
11.5.4) whilst re-defining the window as this gives an instant indication as to
where the current window is in relation to the full network.
11.5.6 Setting the Initial Window

By default the initial window set on first entering P1X will be the full network.
However there are two alternatives which may be set via the Command Line:
(1) If RESUME is set on the Command Line (see 11.4.4 above) then the initial
window will be the final window set on the last run of P1X;
(2) If the Command line contains a numerical node number (e.g., P1X net 177)
then the initial window is centered about that node. Alternatively, if a zone
number is input, then the window is centered about that zone (with the proviso
that if a zone and a node have the same number then the node’s co-ordinates
take precedence).
11.6 Basic Network Display

A “basic” (see below) network plot requires (up to) ten sets of information to be
specified.
a) Data which restricts the links which are to be displayed, the “select links”
procedure
b) The choice of link based data to be annotated
c) Parameters to control the annotation of link data
d) Link-specific display parameters
e) Parameters to control the display of nodes (including “highlighting”; see
11.6.5.4);
f) Parameters to control the annotation of turn-based data;
g) Parameters to control the display of matrix data;
h) General display parameters.
i) Parameters to control the contents and format of the “banner”
j) GIS background information.
k) Bitmap background options.
These are described within the following sub-sections 11.6.1 through 11.6.11.
By “basic” above we refer to the network display which always appears, although
with some options extra information will be added. For example information
5120257 / Apr 15 11-17

Section 11
relating, e.g., to trees or select link flows will be superimposed on to the basic
network plot but disappears once that option is completed.
11.6.1 Link Selection
11.6.1.1 Selection by (Numerical) Attribute

The Select facility allows the user to restrict the links to be displayed and/or further
analysed by specifying conditions which must be satisfied. For example one
might wish to plot only those links where the flow (in either direction) exceeds,
say, 500 pcu/hr. This could be done by, firstly, selecting the variable FLOW from
the menu, next specifying the condition as ‘GT’ and finally specifying the critical
value as 500. In this case links where the flow (in both directions) was less than
500 would not appear at all and the selected links would appear as per normal.
Once selected a link remains within the “selected” sub-set of links until the link
selection rules are changed, e.g., cancelled.
Alternatively one may “highlight” selected links, e.g., by drawing them as thicker or
wavy lines, in which case the other links remain as part of the map. The
conditions which the highlighted lines must satisfy are specified as above.
It is also possible to select links that satisfy more than one condition by specifying
further conditions. These may be either in the form of “AND” conditions, e.g.,
FLOW GT 500 AND SPEED LT 30
so that the plotted links would need to satisfy BOTH conditions, or “OR”
conditions; e.g.,
FLOW GT 500 OR SPEED LT 30
in which case any link satisfying either of the above conditions would be
“included”.
In addition to GT and LT tests further numerical conditions include “EQ” and “NE”,
in which case an additional “plus-minus” parameter needs to be specified. Thus
12.05 is not, strictly, equal to 12 in the sense of 12. 0000 but it is equal to 12 in the
sense of 12 + 0.5. By default equality or non-equality is based on rounding off
both quantities to the nearest integer, i.e. + 0.5, but tighter (or even looser) limits
may be specified.
Tests such as GT or LT also require numerical values such as 500 or 30 in the
above examples. However it is also possible to specify a test as “GT 0” directly
without specifying both GT and 0.
Ranges may also be selected, for example, all speeds in the range 20.0 to 40.0.
Less obvious conditions are the “Top Ten” and “Bottom Ten” whereby those links
which have the 10 maximum or 10 minimum values in some sense are selected.
For example, you may select the 10 worst converged links (as also printed by
SATALL, see (1) in 9.9.1.2) using the GEH convergence as the link attribute and
Top Ten as the criteria.
5120257 / Apr 15 11-18

Section 11
The link attribute used in the tests may also be specified as either its actual or its
absolute value.
11.6.1.2 Alternative Selection criteria

Other criteria may also be used to select links. If two networks are being
examined a “MATCH” option can, say, select links which exist in network 1 but not
in network 2, in other words to highlight where changes in the network structure
have been carried out. Again all these types of requests may be added as
additional AND/OR conditions.
Equally links may be selected as part of the network cordon process such that, for
example, all links inside the cordon but excluding the “cut” links may be treated as
selected; see 11.13.2.
Finally, a new addition in 10.3, the links to be selected may be nominated by
pointing and clicking on them with the mouse. A link thus identified is either
selected in both directions (if two way) or only in the direction implied by the
mouse position depending on whether the option is entered with either the 2-way
or 1-way toggle selected.
11.6.1.3 Selection in P1X and SATDB

Note that the system used to record selected links for display purposes in P1X is
synonymous with the system used within SATDB; see 11.10.2. Thus any
selection made within SATDB will affect what is seen on the P1X graphical
displays and vice-versa.
11.6.1.4 “Selection” by Capacity Index

It is also possible, post 10.3, to select those links (where “links” here includes both
real links and centroid connectors) to be plotted by virtue of their capacity index.
For example, you may permanently exclude all links with capacity index 0.
Selection of indices is done via a window whereby each index used may be
toggled “on” or “off” via a radio button.
Note that this is not “selection” in the full sense described in 11.6.1.3 in that it
applies only to which links appear in the plot, not those links which are
selected/not selected for SATDB operations (11.10.2). Equally any form of
“highlighting” does not apply. In this sense the selection is much more similar to
the “link inclusion” options as described in note 6 of 11.6.4 and indeed menu
access to this option is available both under Link Selection and Link Display.
However I suspect most users would be inclined to look for an explanation within
this section of the Manual
By default all capacity indices are “on” although it is possible to set the default to
“off” by setting a negative width for the capacity index within the preferences file
P1X0.DAT; see note 4 in 11.6.4.
11.6.1.5 “Temporary” Link Selection

Links may also be “selected for display” in a slightly different “temporary” context
by other options within P1X. Thus, for example, an O-D tree display selectively
displays only those links on the shortest path while bus information displays all
5120257 / Apr 15 11-19

Section 11
links on a bus route. However these displays are only being temporary and the
links thus selected are not part of the “permanent” selection described above
11.6.2 Annotated Link Data
11.6.2.1 Choice of Annotated Link Data

Each (directional) link may have one or more data values (e.g. speed, flow)
associated with it and these data values may then be displayed (“annotated”) in
the network plots in a variety of formats. The annotated data may be generated in
a number of different ways.
Data may be chosen either from: (a) a list of “names”, e.g., “DISTANCE”,
“ACTUAL FLOW”, etc.; (b) more generally via a Dirck Access array number (see
15.21 or App. J) or (c) from data columns previously created and stored within the
data base.
The list of “names” is divided into (up to) 5 sub-lists corresponding to:
♦ General properties such as link distance, number of lanes etc.;
♦ Flows;
♦ Time and/or speed-based variables;
♦ Bus data (including bus flows);
♦ Emission data.
The precise contents of each depend on the input network so that, for example,
“LANES” would not apply to a buffer-only network.
There is also a choice of a “full” list including all items under (a) to (e) above but,
generally speaking, the full list is long and unwieldy.
A full list of all possible data items in the standard lists is given in Appendix I.1with
an explanation of what each contains plus, where applicable, their equivalent DA
code.
In general and where appropriate the flows listed explicitly differentiate between
actual and demand flows but in the case of five “sub-flows” - bus flows, pre-loaded
flows, passq flows, (total) fixed flows and entry flows from centroids - there is an
explicit 3-way choice under Options to request either demand, actual or queued
upstream flows to be created.
Equally annotated link data may be generated via, for example, Select Link
Analysis (11.8.1), tree building (11.8.3), etc. etc. Bus routes are annotated by
writing the number of the route along the constituent links.
A further form of link annotation - which must be “text” - is that of link “names” as
available under GIS displays. See 11.6.10.
11.6.2.2 Handling Annotated Link Data

Once created, link data is either displayed directly (effectively once and only once)
- the “pick‘n’plot” mode - or displayed and stored in the permanent data base (in
5120257 / Apr 15 11-20

Section 11
which case, see below, they are displayed on every subsequent plot until
cancelled).
We note that P1X and SATDB share a common internal data base (see Section
11.10.1) such that data selected for display under non Pick’n’Plot is added to the
data base exactly as though it had been generated within SATDB. Conversely this
means that the analysis options from SATDB may therefore be accessed from
within P1X, e.g., the ability to create new data columns via FORTRAN equations
or to look at the data numerically on the screen.
Note that “link data” selected by P1X does not only refer to data to be annotated
on links by P1X since a number of the items also apply to simulation turns, e.g.,
link flows, in which case if the data is stored as a data base column the turn data
is also there to be viewed and/or manipulated via SATDB.
By default all data items in the permanent data base (independently of how they
were created) are displayed in all network plots although under the
“housekeeping” options plotting may be suppressed.
More than one variable may be annotated at once, although with numerical
display the program checks whether or not enough space is available and
suppresses any figures that would “over-run” the link. However before
suppressing any numbers the program first tries to “compress” the annotation by
writing smaller numbers; the system parameter SHRINK (set under the “current
device parameters” sub-menu within the system/device menu; 11.3.4) sets a limit
to the compression, so that if SHRINK = 0.7 the smallest permitted characters are
70% of the normal size.
11.6.2.3 Annotating Multiple Networks

If a second network file “NET2” is defined it is possible to create and annotate
data from either NET1 or NET2 separately, both together, their differences or their
ratios. This is very useful, for example, to illustrate the differences in link flows
between two networks.
Nine options are provided:
1) Annotate data from NET1,
2) Annotate data from NET2,
3) Annotate the differences (defined as NET2 minus NET1),
4) Annotate data from both networks together (or, if there are more than 2 input
network files, data from all networks),
5) Annotate the relative differences as a percentage - defined as (NET2 minus
NET1)/NET1,
6) The ratio NET2/NET1 expressed as a per cent,
7) The absolute difference between NET2 and NET1,
8) The GEH statistic for the difference between Net1 and NET2 expressed as
an absolute value,
5120257 / Apr 15 11-21

Section 11
9) The GEH statistic as 8) but with a + or – sign.

It is not essential that the files on NET1 and NET2 have identical network
structures. NET1 defines fully the link/node structure plotted, but where a link in
NET1 also appears in NET2 data from both (or either) files may be displayed. A
match is also possible between ‘buffer’ links in one network and the equivalent
‘simulation’ link in the other.
On the other hand links in NET2 which are not “matched” by a link in NET1 cannot
be annotated on a network plot.
Note that the “sense” of the operation implied by options 3, 5 and 6 above can be
reversed; i.e., you may also choose to plot NET1 - NET2. In addition, using the
SATDB-style data manipulation options you may create any other “difference
statistics” you wish and involve link data from networks 3 and 4 as well.
Figure 11.1 - Bandwidth Plot of Flow Differences (Option 3 above)
11.6.2.4 Unmatched Links in Multiple Networks

If a (directional) link occurs within the first network defined in P1X but not in the
second (/third/fourth) then the “difference” statistics 3, 5 and 6 defined above are
not, strictly speaking, well defined. However it is possible (post 10.5) to define a
“default” value for the missing entries, the most obvious value being zero. Thus, if
you are plotting the differences in flows between a “do-something” and “do-
nothing” networks, then it is logical to assume that the flow on a newly created link
is 100% growth (i.e., the previous flow was zero). On the other hand it is difficult to
compare the speed on a new link to an obvious reference point.
5120257 / Apr 15 11-22

Section 11
11.6.2.5 Annotating Multiple User and/or Vehicle Classes

In a network with more than one user class up to the first three user class flows
are explicitly listed. Alternatively there are options available under “Options” to
either take data for a single “nominated” user class or for all user classes, in
which case a set of NOMADS data (up to a maximum of 4) is created. Changing
the option changes the text messages that appear in the lists.
Thus, in order to display data for user class 4 or beyond, set that user class as the
nominated class.
The same principles apply, post 10.9, to annotating flows by vehicle classes (i.e.,
summations of user class flows).
11.6.3 Link Annotation Display Options

These options control how link data, once selected, “appears” in the plots.
Note that these options apply to all annotated link data, i.e., not just link data as
selected via the “Choice of Annotated Link Data”, 11.6.2.1, but also other options
for creating link data such as Select Link Analysis, Trees, etc. etc.
11.6.3.1 Display Modes

Link annotation can either be via:
♦ numerical values - the default - printed along the line;
♦ numerical values entered horizontally in a “box” attached to the middle of the

(directional) link, or
♦ “geometrical” shapes which represent in some sense the values of the

variable(s).
In all cases the data appears on the “correct” side of the link in the sense of “drive
on the left” (or on the right if LEFTDR = F).
11.6.3.2 Geometrical Display Modes

Four geometrical options are available:
1) “Bandwidth blocks” with the full link as a base and the width proportional to
the value;
2) Bands of fixed width along the full link but with a variable degree of
“intensity” (see 11.6.3.8);
3) Blocks of fixed width whose (absolute) length along the link is proportional to
the annotated value.
4) Blocks of fixed width whose (relative) length along the link is proportional to
the annotated value.
All geometric options can display more than one set of data entries at a time and
use different colours for each (see 11.6.3.4 below). In addition positive and
5120257 / Apr 15 11-23

Section 11
negative numbers are plotted as different colours. This is very useful when, for
example, displaying the differences in flows, etc., between two different networks.
Each option has a corresponding proportionality parameter which may be
changed whether or not that option is currently invoked; for example, under (1)
above a parameter value of 100 units/mm would imply that a link whose data
value was 376 would have a band of width 3.76 mm displayed.
The different geometric options are useful in different circumstances. Thus

options (1) and (2) are useful to display characteristics such as flows or speeds
which have a constant “intensity” anywhere along the link, but less useful for
displaying travel times since the long links would automatically tend to be most
prominent. Generally the bandwidths “look better” than the variable intensities.
Option (4) is best used to represent queues, in particular with the variable “Q/S”
(average total queue length divided by the stack) and the proportionality constant
set to 100.0. Thus if the queue takes up the full stacking capacity of the link, so
that Q/S = 100%, the solid block will extend the full length of the plotted link; if Q/S
= 50% the block extends 50% of the link length, etc. Thus a link with, say, an
average queue of 20 vehicles and a single lane would have a longer block than a
link with 20 vehicles spread over 4 lanes.
Equally option (3) can also be used to display queues but in this case it should be
an absolute queue that is plotted, e.g. QUEND or QBAR, not a relative queue. It
can also be usefully used to display delays.
Values for the proportionality constants in all cases should be chosen with regard
to the probable absolute values to be displayed; thus if the values are large, so
should be the constants, in order to keep the lengths/widths to a reasonable size.
5120257 / Apr 15 11-24

Section 11
MINIMUM / MAXIMUM / FIXED BANDWIDTHS

Post release 11.2.4, extra features have been added to bandwidths (option 1
above) to allow:
a) fixed width in (mm) to be added to all bandwidths;
b) a minimum width for all bandwidths; and
c) a maximum width.
Thus adding a fixed width enables very low / zero values to become more
apparent, while having a minimum width has a similar impact. The maximum
prevents artificially large values (e.g.,99999) from “swamping” the display.
By default the fixed added width is 0.0 and neither minimum nor maximum limits
apply.
11.6.3.3 Numerical Selection

Numerical selection rules allow the user to display only values within a certain
range. For example you may wish to suppress the printing of very low data values,
in which case a “lowest value” is set and the “maximum value” is either set to a
very large value or, more easily, left “unset”. If the data consists of both positive
and negative values (e.g., differences in flows) the test can be based on absolute
values rather than actual. Selection applies to both numerical and geometrical
displays.
Similarly the numerical values displayed may be “rounded off”, e.g., to the nearest
units of 10’s or 100’s etc.
11.6.3.4 Colour and/or Range Definitions

The colours (or pens) which are used to display geometrical link data (but not
numerical link annotation) may be set in a number of different ways:
♦ At the simplest level all annotation uses a single colour.
♦ Alternatively, if more than one item of link data is being displayed, each item
may have a different colour.
♦ Different colours may denote positive and negative entries per data item.
♦ The colours may depend on “range bands” such that, e.g., all data values in
the range 0 to 100 are plotted in red, 100 to 200 in blue, etc. etc. with different
pen colours/ranges for different data sets (see 11.6.3.6).
♦ Alternatively the colours of each individual data item may be defined by the
range bands of another single “master” data item (see 11.6.3.7).
The most basic choice is between basic pen definitions which depend only on
data item plus positive/negative and those which are range-based. The default is
the former with pen choices which differ by both data item and by
positive/negative, although these may be changed by the user to be based more
on single uniform colours.
5120257 / Apr 15 11-25

Section 11
Colour choices in P1X are made by entering “Pen and/or range defs” under Link
Annotation Display Options where the following basic options are presented:
♦ Basic positive/negative pen definitions per data item (11.6.3.5);
♦ The choice of range bands or single colours per data item (11.6.3.6);
♦ The precise definition of pen colours and range bands
♦ The definition of range bands only
♦ The choice of a “master” data item to define colour bands for all data
(11.6.3.7).
11.6.3.5 Single (Uniform) Colours per Data Item

By default each data item is assigned a single colour for positive values and a
different colour for negatives. Thus data item one is represented by pen 1 (blue)
for positive values and pen 2 (green) for negative values; data item two uses pens
3 and 4 (cyan and red), etc. etc. These definitions may be changed interactively
within the program.
11.6.3.6 Defining Colour-based Ranges

Range definitions used to define the colour of annotation (principally bandwidth
annotation) may be further subdivided into:
a) uniform bands, and
b) explicitly defined bands
Thus under (a) the user defines a minimum starting value (generally zero) and an
increment. If they are, say, -50 and 100 respectively then this would set the first
band (i.e. first colour) to be all data values up to and including -50, the second
band would be from -50 to +50, the third from 50 to 150, etc. etc.
Under (b) the user may explicitly define each of the “break” points which may not
follow equal increments; e.g. 0-100 could be one colour, 100 to 500 another, 500
to 5000 a third, etc. etc.
In either case each band is associated with a colour/pen which is user set (or
taken from defaults – see 11.6.3.9), the maximum number of bands is 10 and the
bands are “open ended” in that all possible values less than the first value are
included in band 1 (i.e. minus infinity up to that value) and all values greater than
the final value are included in the last band. (Which implies in fact that the 10th
break point is irrelevant since all values above the 9th must lie in the final band.)
To set range definitions select “Range bands or uni-colours by data set:” from the
“pen and/or range options” menu. Thus, for each data item displayed there is a
basic choice between display by a single colour (or 2 colours for +/-) or display by
multiple colours set by bands; if the latter there are further choices between
“uniform bands” or “explicitly set bands”, options a) and b) above, and all the
necessary parameters may be input interactively.
5120257 / Apr 15 11-26

Section 11
Once set the current colours and/or range limits may be displayed along with the
plot via the A-Z banner (11.6.9).
Note that they may be preserved for future applications by storing them on a new
preferences file – see 11.6.3.9.
11.6.3.7 Defining (Transferring) Colours from Another Data Column

It is also possible to “transfer” colours by range from one item of data to another.
For example, you might wish to display the flow (data set 1) as multiple-colour
bandwidths but using colours determined by ranges of the V/C ratio (data set 2).
To do this, nominate data set 2 (V/C) as the “master” set and define the
appropriate range bands for that set: both data items will then have the same
colour on each link. (The presentation may well be improved if the master item,
i.e., the V/C ratios in the above example, is not displayed so that you have flows
only plotted in colours determined by their V/C ratios.)
Selecting bandwidth colours by using speed as the controlling variable is another
very common example; i.e, link data is displayed as bandwidths with different
colours for different speed bands. A further application using speed is described
next.
11.6.3.8 Fixed Width, Variable Colour Link Bars

It is sometimes very useful to be able to indicate links whose, e.g., speeds are
within a certain range by a set of colours. This can be done by combining the
“variable intensity” display option - (2) under 11.6.3.2 - with the colour/range
definitions in 11.6.3.6.
Thus, under variable intensities, if the proportionality constant is set to zero, all
link data will be displayed at maximum intensities and therefore appear as solid
rectangles of fixed width. This, therefore, provides very little useful information
UNLESS the colours of the rectangles are variable (see 11.6.3.6), in which case
different ranges of link data properties will appear as different colour bars.
11.6.3.9 Storing Range/Colour Details on the Preferences File

It is sometimes useful, having set up a complicated system of range bands and
colours, to be able to store that data for later use, e.g., on a different network. This
may be done by creating a new preferences file since the final (optional) data
segment on a preferences file, headed by a record beginning “PEN-RANGES”
stores all the necessary data, both universal parameters and parameters
applicable to individual data sets.
Documentation on the structure of these records is given by “comment cards” at
the head of the data segment.
11.6.3.10 Averaged and/or Summed Link Data

The basic link data to be annotated is always stored in a “directional” sense, i.e.,
the data for link (A,B) is distinct from that (B,A) on two-way links. However it is
possible to display link data as either the average or the sum of both directions
(where for one-way links both average and sum are interpreted as the value for
the existing direction).
5120257 / Apr 15 11-27

Section 11
In the case of bandwidth notation averaged data appears (equally) on both sides
of two-way links and on the “correct” side of one-way links. For summed data the
bandwidths always “straddle” the link whether it is one-way or two-way.
For all other display modes, i.e., numerical presentation and geometrical options
(2) to (4) under 11.6.3.2, averaged data appears as per bandwidths but summed
data on 2-way links appears on one side of the link only (where the choice of side
is decided by link numbers).
11.6.4 Link Display Options

By default a link is represented as a straight line joining its A-node and B-node
(generally) in black on a white background. However several variations are
possible:
1) The default pen colour may be altered to any other standard pen colour.
2) The links may be plotted either as lines or as in-filled “blocks” of a finite
width.
3) Similarly the width and/or colour of a link may optionally be determined by its
link capacity index; e.g., motorway links may appear as solid blue lines, etc.
Default widths/colours may be entered in the default parameter file
P1X0.DAT or edited interactively using a screen edit window.
4) Negative link widths by capacity index may also be used to remove certain
links from the plot; i.e., any link whose capacity index has a negative width is
never plotted, independent of whether or not the option to set by capacity
index is invoked.
The effect is equivalent to using the capacity index to de-select links
(11.6.1.4) for display. One advantage of this method is that it can be made
semi-permanent by using the parameter file P1X0.DAT to set default
negative widths.
5) “Selected” links (11.6.1) may be highlighted, e.g. by the use of “zig-zag”
lines or by solid in-filled bands whose width, position and colour are user-
set.
6) Links may be drawn as “curves” as opposed to straight lines using data
contained in the GIS file such that links are drawn as “polylines”, i.e., straight
line segments linking a series of intermediate points between the A-node
and B-node. If these points are sufficiently frequent the line approaches a
smooth curve. Polylines are selected by a sub-option within either the
General Display Menu or the GIS menu. See section 5.7.2 for instructions
as to how to create polyline data.
7) Centroid connectors may be excluded from plots (or, less usefully, only
centroid connectors may be plotted); by default both “real” links and centroid
connectors are included. Equally links and/or centroid connectors may be
excluded from the plots by virtue of their capacity indices; see also 11.6.1.3.
8) Links in the simulation network may be drawn - as an alternative to options 2
and 3 above - with the number of lanes in each direction explicitly marked
and with bus lanes marked in red. This is indicated by “Kerbs marked” in the
5120257 / Apr 15 11-28

Section 11
banner. (If the lanes appear too large or too small by a factor of 10 it
probably means that the parameter XYUNIT has been incorrectly defined.)
It is logical to combine this form of link representation with the representation
of simulation nodes by lane-based diagrams; see 11.6.5.1 (4) below.
Note that, if lane display is “on” the width of the lane, which defaults to 3.75
metres “on the ground”, may be re-set to provide more or less “width” as required
9) One-way links are (by default) indicated by arrows at the mid-point in the
appropriate direction; the length of the “barb” may be adjusted or, in the limit,
set to zero in order to suppress the arrows totally.
11.6.5 Node-Based Annotation
11.6.5.1 General Node Display Options

Information relating to nodes or junctions may be included within network plots via
one of five “main modes” which display a variety of numerical and/or geometric
information:
1) Single numbers representing node properties such as the node number, V/C
ratio, etc. and/or shapes representing junction types;
2) “Bandwidth” circles with radii proportional to node data and/or variable
colours (11.6.5.2).
3) Boxed data”, i.e. one or more data values contained inside a box.
4) “Tubies” representing turning data (but only if turn data has been selected,
see 11.6.6).
5) Diagrams representing lanes and lane markings.
N.B. All the above are annotated “at the point”, i.e., centered at the intersection.
In addition node numbers may be written “offset” from the actual intersection point
and node “names” from the GIS file (11.6.10) may be annotated above the node
position.
NODE SHAPES
Under option (1) above (ONLY!) different junction types are represented by
geometric shapes and/or colours. Thus simulated roundabouts are represented by
circles, traffic signals by squares, priority junctions by rectangles, external nodes
by pentagons while dummy nodes are either (post 10.8) given by a number only
or by a star. In the buffer network all “real” nodes are represented by a hexagon.
Zones, whether in the simulation or buffer networks, are represented by triangles.
In addition each shape can have its own unique colour and be either “solid” (i.e.,
in-filled) or “open”. If, however, numerical node data is included then the shape
must be open in order to accommodate that data; see below.
Various options are provided to: (a) suppress node shapes altogether; (b), to use
a single pen colour for all node types and/or to distinguish different node types by
5120257 / Apr 15 11-29

Section 11
different colours; (c) to distinguish zone sectors by distinct colours; and (d) to
factor the size of the shapes up or down by a user-set factor (default 1.0).
NUMERICAL NODE DATA

Under option (1) above numerical values are written inside the shapes (if they
exist). The most obvious node property to annotate is its number; however it is
also possible to substitute a wide range of node “input properties” such as the
offset or cycle time at signalised nodes as well as a wider range of “output” node
data, e.g. V/C ratios, and total through flow. These may be selected from a
standard list (with certain elements available for simulation nodes only) or
extracted from the node data base (11.10.5) where you may have previously
created your own node data sets. See Appendix I.3 for a full list of available node
data.
The same numerical data may also be represented by in-filled circles, option (2),
whose radius is proportional to the value of the particular node’s data with a
proportionality constant set by the user. Bandwidth displays require a
“proportionality” factor to be defined to convert the value “at the node” into a
radius. For example, if you are displaying %V/C you may wish to define a 1 mm
radius to equal a %V/C value of 10. In addition the colour used in the circle may
be determined by the value being annotated (see 11.6.5.2 below).
Bandwidths may be either “background” or “foreground” depending on whether or
not the lines representing the links are plotted over the node shapes or, in effect,
underneath.
An example is shown below with a single colour used.
5120257 / Apr 15 11-30

Section 11
“BOXED” NODE DATA

Option (3), data in boxes, can, unlike the other four options, display more than one
set of node data at a time BUT the data to be displayed must first be set up with
the SATDB node data base; see 11.10.1.
GEOMETRIC NODE DISPLAYS

Options (4) and (5) are based on the detailed node graphics routines described in
11.12.2, but here are plotted (at a much smaller scale) for each simulation junction
(only) in the plot. Unlike options (1) to (3) neither (4) nor (5) display node data
values.
Option (4) annotates a selected turn variable, e.g., turning flows or delays, as
“tubies” or curved bandwidths of proportional width. To a large extent this option
duplicates the turn-based options described in the following section and relies on
data selected there. The main difference is that here the data is displayed “within”
the node; under 11.6.6 it is displayed “along” the entry link.
Option (5) produces line diagrams for each simulation junction, similar to those
produced for individual junctions but at a much reduced scale as illustrated below.
(If the scale is clearly wrong it probably means that the parameter XYUNIT has
been incorrectly defined.) It is logical to combine this form of node representation
with the representation of simulation links by lane-based diagrams; see 11.6.4 (7)
above.
Note that, if a link entering a node has been described in the GIS data as a
“curved” link (see 5.7.1) then the angle of the exit arm in the node drawing reflects
the initial angle of the curved link, rather than the direct “crow-fly” direction to the
adjacent node.
5120257 / Apr 15 11-31

Section 11
11.6.5.2 Node Bandwidth Colours

The colours used to depict node data via bandwidths may be determined by a
variety of rules. The simplest is to use a single colour (or, strictly speaking, a
single colour for positive values and another for negative). Alternatively, as with
node shapes, a bandwidth colour specific to the junction type may be set.
Alternatively the colour may be determined by the annotated value using range
bands with either fixed and equal increments or with variable ranges set by the
user. Thus, in the former case, if the fixed increment is 100, all nodes with
(absolute) values 0 to 100 will be displayed in pen 1, all with values in the range
100 to 200 in pen 2, etc. etc. In the latter case the user could stipulate that all
values below 50 would be in pen 1, all values between 50 and 90 in pen 2, 90 to
100 in pen 3 etc. etc.
Note that with the fixed increment option it is the absolute value of the node data
that is used to set the colour; in the case of user-set ranges the sign of the data
value is taken into account and the range values may similarly be either positive
or negative.
11.6.5.3 Node Selection

Node annotation may be “selected” (i.e. to appear or not to appear) in two basic
ways:
♦ whether space permits
♦ whether the node satisfies certain criteria.

Both may be applied simultaneously. Rule ii) may also be applied to turn-based
annotation (11.6.6).
The space rules are based purely on whether or not there is sufficient space
between a node and all of its neighbours and/or boundaries to allow node
annotation without overlap. If not the notation may be “shrunk” to a certain
minimum, below which it is excluded. Selection in this sense therefore depends
very much on the “size” of the output device and may appear differently on the
screen or on the printer. However selection by criteria is device-independent.
The criteria may in turn be specified in several ways:
a) By the type of junction;
b) By numerical tests on the node data to be displayed;
c) By selecting inside/outside a range of node and/or zone numbers;
d) By selecting inside/outside the current plotting window;
e) By selecting with the mouse;
f) By comparing nodes between network 1 and network 2.
g) By reading node numbers from a text (ASCII) file.
5120257 / Apr 15 11-32

Section 11
h) By selecting those nodes which are retained in a “spider web network” (see
15.56.2)
i) By selecting those simulation nodes which may be treated as “moons” in
terms of the order in which simulation nodes are simulated (see 8.3.5)
j) By selecting simulation nodes which have been converted to Fixed Cost
Function (FCF) operation; see 15.1.6.
In addition the selections may be built up as a sequence of “AND” or “OR”
conditions; e.g. you may select nodes which are both traffic signals AND have
entry flows of more than 1000.
Thus under a) one might select only signalized simulation nodes, all junctions
excluding zones etc.
Option b) can select, e.g. nodes where the delay is greater than x seconds, etc. In
this case the “property” on which the test is applied may be:
♦ (most commonly) the node data currently annotated (if there is one),
♦ a data field in the node (SATDB) data base, or
♦ a newly selected data item from the standard list of node data.
The numerical criteria on which the test may be based are similar to those used
for link selection by numerical attribute; see 11.6.1.1. Thus not only may they
include “GT 30”, “LT 0” etc. they may also include “Top Ten” so that one might
select the 10 worst converged simulation nodes.
Option c) simply tests on the basis of numbers; e.g., select those nodes whose
numbers are between 100 and 200.
Option d) provides a somewhat crude “select by location” using the definition of
the current plotting window to “cordon off” a set of nodes/zones. A more
sophisticated selection may however also be done using the cordon options
proper within P1X as accessed from the master menu (11.13).
Option e) allows the user to select nodes by point-and-click with the mouse which
may be extremely convenient if a small number of nodes are to be selected and/or
the basis for their selection is otherwise difficult to specify.
Option f), network comparison, may either work at the rather crude level of
selecting nodes which, e.g., appear in network 1 but not in network 2, etc. It may
also use a more precise system of selecting common nodes by identifying
simulation nodes which are coded differently between the two networks.
Note that the node selection rules in P1X are, effectively, identical with those
applied within the SATDB node data base (11.10.5) so that selections made here
will affect, e.g., the node data tables as printed by SATDB and vice-versa.
11.6.5.4 Highlighted Nodes

A slightly different form of node annotation consists of “highlighting” certain
selected nodes where the nodes are indicated by a small red circle at the node. In
5120257 / Apr 15 11-33

Section 11
particular this technique is used to highlight nodes where certain errors have been
detected while building the network in SATNET.
Thus one may opt to highlight all those nodes where, e.g., one or more Serious
Warnings have occurred – or, in greater detail, one may display only nodes where
one particular Serious Warning occurred. The objective of the exercise is to make
it easier for users to identify where errors have occurred and, hopefully, to correct
them.
Similarly data from .ERL files (see 15.58) may be used to highlight nodes where
certain forms of coding errors have been detected, the difference in this case
being that not necessarily all errors detected by SATNET are displayed, only
those that are suitably identified within the .ERL file as controlled by the user. Full
details are given in 15.58.2.
The highlight options may be entered either by clicking on “Highlight Errors”, “1st
ERL Field” etc. under Display Options in the Menu Bar or on “highlight Errors” etc.
in the banner under Display Options. In either case the user is prompted with a
menu to select, e.g., all Serious Warnings, one particular Serious Warning by
number, etc. etc.
A further highlighting option selects those simulation nodes where there are
differences in the coding between networks 1 and 2, e.g., different signal timings.
This is a useful option to identify where changes have been made to a network,
e.g., by an over-zealous colleague when you are away on holiday! A full listing of
differences may also be obtained within SATLOOK; see 11.11.18.
This option is extremely useful for network debugging in that it enables the user to
quickly identify where in the network particular errors have occurred rather than
trying to identify particular error messages in a .LPN file and locating the
corresponding nodes using P1X.
Note that having identified a sub-set of nodes displaying a particular error it is then
possible to automatically “loop” over those nodes in order to view the source of
the error via node graphics. In addition, the same “loop” may be invoked under
Network Editing in order to be able to correct any coding errors immediately and
to produce a corrected .dat file.
Similarly nodes may also be highlighted (and looped over) within the Convergence
Menu “10 worst” options (11.15) so that, for example, the locations of the nodes
where the 10 biggest discrepancies in delays calculated by the simulation and
assignment sub-models have occurred are highlighted. This is also an extremely
useful tool in quickly identifying potential trouble spots in terms of assignment-
simulation convergence and correcting them. (Note, however, that the source of
the convergence problem may not be as immediately obvious or as easy to
correct as it might be with specific coding errors.)
11.6.6 Turn-Based Annotation

Turn data such as turning flows or delays may be selected from lists and
displayed either as a sub-option of the node-based display (option 2 under 11.6.5
in which case the data appears “within” the node) or alternatively “along” the in-
bound links to every node. A full list of the data available may be found in
Appendix I.2.
5120257 / Apr 15 11-34

Section 11
In the latter case, described here, there are two “main” display modes:
a) data such as turning flows; or
b) banned turn indicators
(plus a third choice, the default, of no turn display)
Under a) turn data may be displayed in one of three distinct modes:
(i) As arrows drawn parallel to the link with the arrowhead in the direction of the
exit link and with numerical values at the end of the shaft;
(ii) As “tubies” - in-filled curved bandwidths whose widths are proportional to the
turn data displayed;
(iii) As “boxed data” with the values for each exit turn from a link printed
horizontally within a box attached to the relevant link.
Note that only simulation junctions have turn data associated with them. The data
to be displayed is chosen from a menu. It may also be “selected” based on the
selection rules for nodes (11.6.5.3).
Under b) an arrow with a perpendicular bar at the end is used to indicate all
banned turns.
(N.B. Prior to release 10.7 “Banned turns” in the context used here referred only
to turning movements coded with a zero saturation flow under 11111; they did not
include any turns which have been banned via the 44444 data inputs, primarily
since in the latter case the ban or bans may be user-class specific. However, post
10.7, turns which have at least one user class banned under 44444 are also
included.)
11.6.7 Matrix Display (Spatial)

As mentioned in 11.4.1 P1X may read from one or more matrix .ufm files
associated with the network, most commonly the trip matrix file. These may be
displayed either “spatially”, i.e. making use of the spatial position of the zones, or
as “general matrix graphics”, essentially as in MX. The latter functions are
described in Section 11.14.
11.6.7.1 Row and/or Column Totals

Matrix row and column totals (i.e. origins and destinations in the context of trip
matrices) may be displayed either numerically or as bandwidth rectangles whose
height is proportional to their value and with their base at the location of the
relevant zone. When both rows and columns are displayed the row totals are on
the left and both are equally displaced from the zone position. The choice of
whether row totals, column totals or both are given and whether or not the network
map appears at the same time is controlled by the matrix menu “display mode”.
The vertical scale of the rectangles is determined by a proportionality constant
“UPMM” - ‘x’ units of totals become x/UPMM mm. on the screen.
A lower bound may also be set (see Options below) which suppresses the display
of small row/column totals.
5120257 / Apr 15 11-35

Section 11
11.6.7.2 Matrix Selection

Facilities exist to select certain “sub areas” within the matrix by nominating a
range of origin zones (rows) and/or destinations (columns). For example if we
had a 100 zone trip matrix we could choose origins 60 to 69 (inclusive) and
destinations 70 to 89, in which case the only matrix elements to be considered in
the row/column summations would be those in the “rectangle” containing the 10
origins and 20 destinations (200 o-d pairs). Selection therefore changes the
values of the numerical values displayed.
An alternative option allows us to use the same o/d ranges to define a “cross”
whereby all trips from origins 60 to 69 would be included (a horizontal strip) plus
all trips to destinations 70 to 89 (a vertical strip). In this case the row totals for
origins 60 to 69 would be the same as for the complete matrix as would the
destination totals 70 to 89, but all others would be potentially reduced.
In either case if the display mode were set to be origins only then the outputs
would be the totals of the elements within the rectangle/cross.
In the limit, by selecting a single origin or row from a trip matrix the corresponding
destinations are displayed so that one can examine individual cell values.
Indirectly selection may also “control” the zones which appear in the plots since a
zone with a row/column total of zero (or less than the lower bound) does not
appear; however its main purpose is to select the o-d cells which go into the
summations.
11.6.7.3 Desire Lines

An alternative method of looking at individual cells is to plot desire lines, i.e., lines
directly linking an origin and destination whose width is proportional to the trip
matrix element. Options also exist to direct the lines via an intermediate point so
that desire lines for a trip matrix representing trips through a road side interview
(RSI) station will actually pass through that point.
Note that there is an upper limit of 502 o-d pairs which can be displayed as desire
lines at any one time in order to prevent “information overload”. If there are more
than 502 pairs eligible (i.e., selected and value above the lower bound) then the
502 pairs with the maximum (absolute) matrix values are selected. For most
matrices, e.g., those with more than 25 or 30 zones, this rule would be in force.
Note, however, that the same restriction would not apply to sector-to-sector desire
lines (see next) and therefore these give a more complete (and aggregated)
picture.
With desire lines selection directly controls which o-d cells are displayed and
clearly the values associated with those o-d cells are fixed independent of how the
selection is done. This contrasts with the row and/or column totals where
selection affects the values displayed.
11.6.7.4 Sector Displays

Finally, for networks where sectors are defined, it is equally possible to display
row/column totals or desire lines by sector rather than by zone. Recall that sector
X,Y co-ordinates are set in the input .dat file to SATNET (6.8).
5120257 / Apr 15 11-36

Section 11
Indeed, given the vast amount of data contained in individual o-d cells and even
row and column totals, displaying matrix data via sectors can often be far easier to
digest.
11.6.7.5 Miscellaneous Options

Other options include comparing two different input matrices as well as viewing
one “slice” of a stacked matrix file.
Note, in addition, the “lower bound” parameter which may be used to suppress the
display of small row/column totals or of small desire lines as appropriate.
11.6.8 General Display Parameters

These parameters control features such as
♦ Whether or not a blank border surrounds the plot
♦ The width of an extra blank border down the left-hand side (useful for
reports).
♦ Whether annotation is allowed to spill over inside the borders.
♦ The pen colours used for general drawing, e.g. link colours, the legend etc.
♦ Grid lines and their spacing.
♦ Access to general SATURN display parameters (e.g. the number of vertical

lines on the screen).
♦ XYUNIT (which, if incorrectly set in the original network file, is a pain to reset
without rerunning the entire network).
♦ An option to suppress the exterior lines enclosing the window which may be
useful for plots to be transferred into reports.
♦ An option to use either the full available screen or to reduce the window to fit
the network window plotted.
In short, any parameters that don’t fit conveniently anywhere else go here!
11.6.9 Banner and/or Title Display

Banners in SATURN refer to the strip which appears (by default) to the right of the
network and/or node graphics plots.
They serve a dual purpose: to display a menu of choices and/or to provide
information as to what is currently being plotted. The former is the most common,
the latter in its purest form is provided by an “A-Z banner” which contains not only
file names but also, e.g. a list of the link variables which are currently annotated.
The A-Z banner is provided under Show within the Windows menu.
In certain circumstances both functions are combined, e.g. a select link analysis
banner may display the total number of trips assigned as well as listing a set of
options to follow.
5120257 / Apr 15 11-37

Section 11
The banner control sub-menu allows the user to select:
♦ where the banner appears (essentially on the right, on the top or not at all);
♦ whether inputs are via the mouse or the keyboard;
♦ whether and where a title appears on the main plot;
♦ whether the banner menu choices are included or not in output plots to the
alternative device or to bitmap files (11.3.5 and 11.3.6);
♦ choices as to what appears in the A-Z banner, e.g. whether or not you want
the WS Atkins/ITS logo to appear;
♦ the pen colours and standard character height as used in the banner.
11.6.9.1 Removing the Banner

There are circumstances when one does not want the banner display to appear
on a plot, e.g. for transfer to an external document. However removing the banner
does create the problem that the information on the next input menu choices is
also removed. For this reason deleting the banner under mouse control is not
allowed (there would be nothing to point to!). Under keyboard control you will
need to “navigate blind” until the banner is restored, i.e. remember the sequence
of key inputs which you will need to execute next, presumably winding up back in
the banner control menu where an input of ‘B’ will toggle the banner back on.
11.6.10 Choosing the GIS Display

The constituent elements of a GIS file (see 5.7 for a general description) may be
toggled off or on within the P1X GIS menu. The components (in the order in
which they are plotted) are:
♦ Polygon
♦ Lines
♦ Icons
♦ Text
♦ Node names
♦ Link names
♦ Curved/straight links
Note that while the “names” set in a GIS file are normally titles such as “Hyde
Park” or “M62” they are essentially just text so that you may use this facility to
include comments such as “New Signals” or “Congested” on the plots.
By default all GIS displays are “off” but the default settings are in fact stored within
the P1X preferences file (11.6.10) such that if you turn, say, curved links “on” and
then store a new preferences file then curved links will be the default from, then
on. More specifically the Namelist “names” associated with the 8 options above
5120257 / Apr 15 11-38

Section 11
are of the form GIS1, GIS2, … GIS8; i.e. an entry of the form: GIS8 = T sets
curved links to “on”.
11.6.11 Background Displays

As discussed in section 15.43 it is possible to use an input bitmap (.bmp) file as
the “background” upon which the network plot is overlaid in a similar fashion to
using SATURN-set GIS data as background. Bitmap backgrounds have the
advantage of being “proper” map displays (assuming of course that they are
obtained from “proper” maps”.
The default is a blank screen.
11.7 Validation Options

The validation options within P1X are based on the premise that there are two
basic methods by which modellers can validate a network model by comparing
model outputs with observations:
♦ By comparing observed and modelled flows.
♦ By comparing observed and modelled travel times.

These facilities are described within the next two sub-sections.
In both cases the “base” data against which the modelled data is compared may
be taken either from the .UFS file (using count/route data input at the network
build stage) or from new ASCII text files. The latter therefore allows data to be
input post assignment.
There are of course other validation methods available, for example comparing
predicted O-D routes with observed or expected routes but these analysis
methods are mostly contained within section 11.8.
11.7.1 Count Validation

Goodness of fit statistics between modelled and observed flows may be obtained
in a number of different locations within SATURN and in a number of different
ways as explained in 15.6. Under P1X Validation both numerical statistics and
graphical scatterplots may be obtained with the full set of possible options and
level of disaggregation.
Count comparisons in P1X Validation may be applied either with (a) the set of link
flows input under the 77777 records of a network .dat file (see 6.10) or (b) using
counts input directly from an external file. See Section 11.11.13 for similar
methods based on SATLOOK (within which only method (a) is available). An
alternative method for introducing new count data into a network file which has
already been assigned using a “warm start” is described in Section 22.4.)
If more than one 77777 set has been included, than the analysis may be done on
each set individually (“disaggregation”) and/or on the combined data set.
Alternatively (new in 10.5) only a single data set may be nominated under
disaggregation.
5120257 / Apr 15 11-39

Section 11
If more than one count field per link has been used (MCCS>1) than one particular
field may be used. Finally the analysis may be applied to links only, turns only or
(the default) all input records.
The modelled flow may be defined in a number of different ways, i.e. actual vrs.
demand flows, bus flows included or excluded and one/all user classes.
Full numerical output statistics are included in the .lpp file; summaries are
(optionally) sent to the screen. Optionally validation criteria as recommended by
the UK Department of Transport are set out; these include:
1) For flows > 700 pcu/h the percentage of modelled flow within + 15% of the
count.
2) For flows <700 pcu/h the percentage of modelled flows within + 100 of the
count.
3) The percentage of counted links where the GEH statistic (15.6) is less than
5.0.
In all 3 cases the Department’s recommendation is that 85% of the counts should
satisfy the above criteria. (N.B. The flow split between 1) and 2) in SATURN is
based on flow units of PCU/h, not VEHICLES/h as strictly used by DETR.)
The scatterplots plot modelled vrs observed flows and (again, subject to options)
best fit lines of the form y = a + bx, y = bx and y = x with plus/minus GEH limits
included. Thus if you ask for y = a + bx only and GEH error = 5 then the linear
plot is given with upper and lower curves corresponding to modelled flows which
would be within a GEH value of +5.
5120257 / Apr 15 11-40

Section 11
Note that the same set of options may also be invoked under option 13 of
SATLOOK, 11.11.13.
Points in the scatterplot are plotted as small squares; optionally the count
“number” (as it appears in the full list of counts) may appear above and to the right
of the squares. Although probably not legible in a mass of points near the 45
degree line they are useful for quick identification of outliers.
11.7.2 Travel Time Validation: Time vrs. Distance Charts

The comparison of observed and modelled travel times along routes may only be
invoked if timing points have been included either within the 66666 route data
input section - see 6.9.5 – or within a new set of routes input from a file.
This facility is primarily intended to be used in conjunction with standard moving
car observer surveys whereby a car follows a fixed route (generally more than
once) and the times to reach certain locations (in the limit every junction) are
recorded. By analysing the same route(s) in SATURN with the equivalent timing
point information generated by the modelled speeds/delays an estimate of how
well the model is estimating travel time (as opposed to pure flows) may be
obtained.
Alternatively the observed travel times may be obtained by aggregating travel
times on individual links obtained from GPS sources and which include
contributions from stop-line delays on each link. Such information is arguably
much easier to obtain than moving car surveys but, the flip side, is less compatible
with the manner in which modelled travel times are estimated in P1X which
includes specific turning movements at each junction which may not be
accurately represented by average turn delays. However it is possible (see
11.7.2.1 below) to use average turn delays per link in the modelled route times.
11.7.2.1 The Definition of Times and Timing Points

Note, as already specified in 6.9.5, that timing points are assumed to be
measured as the vehicle crosses the stop line, as opposed to reaching the end of
the queue. Thus they include the delay time associated with the particular turning
movement and therefore, if a route follows A-B-C, the assumed time to reach B is
dependent upon C.
There is, however, one possible exception to the above rule. If the final link in a
route is an internal simulation link where there is, by definition, no exit node
defined then the cumulative modelled time includes the cruise time on the final link
but – traditionally prior to 10.9.16 - no turn delay contribution; i.e., it is effectively
the time to reach the end of the queue, not the stop-line. However, post 10.9.16, it
is possible to include the average turning delay at the downstream stop line by
setting a parameter ADEL = T. ADEL may be set interactively within the joyride
options or pre-set within the preferences file p1x0.dat; its default is T.
Average vrs Actual Turn Delays
We may also note here that it is also possible to use average turning delays
throughout the entire route by a toggle option in the banner menu (Average turn
delays = T or F). see 11.8.2.2.
5120257 / Apr 15 11-41

Section 11
Added CLICKS Times

If a network includes CLICKS (i.e., reduced speeds for certain vehicle/user
classes on certain links; see 15.47) it is possible to include the extra delays
associated with CLICKS in the definition of modelled travel times. This may be
done either by specifying a particular user class to which the observed times refer
and those extra CLICKS delays will be added to the modelled times or,
alternatively, the user may specify the times to be averaged travel times, weighted
either by PCU or vehicle flows (see 15.47.4). The latter is a useful option when the
“observed” times are not necessarily based on car speeds but on speeds/times
which are averaged per vehicle or PCU.
This option was first introduced in version 11.3.7, September 2014.
11.7.2.2 Timed Route Displays

The outputs are not dissimilar to those produced by the Joy Ride or Bus Route
analyses (see 11.8.2.1). For example the routes may be displayed one link at a
time with cumulative data in the banner or the whole route may be displayed in
one go. The main difference here is that at those nodes where a timing point has
been provided a box appears on the plot with both the timing point and the
cumulative modelled time displayed top and bottom respectively. The same
information is also included as a more permanent record in the .lpp file.
Note that when a timed route begins within the simulation network, e.g. with nodes
A-B-C…, then the cumulative modelled times will either include or exclude the
travel time on the first link A-B depending on whether or not the parameter
UPBUS = T or F respectively or – post.10.9.24 – whether the coded route
frequency was zero or positive (see 6.9.5).
Clearly UPBUS and/or frequency should be set to coincide with the convention by
which the input timing points are measured. The most “natural” assumption is that
the timing would begin at node A above, in which case UPBUS = T is preferable.
However, the value of UPBUS as set in the original network .dat file (see 6.9.2)
may well also be influenced by its application to “true” (positive frequency) bus
routes and indeed its default value is F. It is for that reason that the extra rule
(see 6.9.5) was introduced that if the route frequency is zero (which is natural for a
pure timing route) then timing always begins at point A independent of UPBUS.
Note that the value of UPBUS may also be changed interactively within P1X and
that if the route begins/ends at buffer nodes then none of these complications
occur.
11.7.2.3 Time vrs Distance Plots

At the end of each route traced a “time vrs distance” plot may be produced
(optionally) with the modelled time in minutes to each node plotted against the
distance in kms to that node. Travel time “on the link” and “in queues” (at
simulation nodes only) is displayed by plotting queued time as a vertical line; i.e. it
is assumed that no distance is travelled while the vehicle is delayed at the
junction. The queuing delay is of course average and specific to the turn (so that
at each link the delay depends on the next link chosen).
5120257 / Apr 15 11-42

Section 11
Also plotted is the observed time vrs distance plot. Note that this is assumed to
be the time to the stop line so it should be compared to the upper point at
simulation nodes.
The observed times may also contain “error bars”, i.e. vertical lines at each point
representing the spread of measured values if more than one observation run has
been undertaken (as should be highly recommended in practice). Spreads are
(optionally) input in the second input field within brackets in the network 66666
records (see 6.9.5).
Optionally the node annotation at each point may be displayed, in exactly the
same way that they are currently displayed in the network plots, for example as a
node shape with its node number offset. Similarly an option to include annotation
along each link, again as it currently appears in the network plots, will be
introduced “soon”.
Equally a short line whose slope represents the mean route speed (to the nearest
integer kph) is plotted in the lower right hand corner in order to provide a scale.
11.7.2.4 Summary Statistics

If there are more than one route containing timing point data a summary table may
be produced (see Routes/Options) which gives, for all timed routes, the final
(only) input timing point, the comparable modelled time plus the absolute and
percentage errors.
5120257 / Apr 15 11-43

Section 11
The table also tests whether or not the modelled times satisfy the standard DfT
criterion of being within either 1 minute or +-15% of the observed times. The total
number of “OK” observations is also recorded.
11.7.2.5 Summary Statistics per Link

The aggregate error statistics per route as described above may also be
associated with each individual link within a route and four fixed sets of data
stored within standard SATDB data columns for further analysis and display. The
4 data sets include:
(i) the absolute error per route;
(ii) the percentage error per route;
(iii) the number of routes per link; and
(iv) the last route found per link.
If a link has been included in more than route the errors (1) and (2) are averaged
over all routes.
The data items thus created may be annotated on each individual link in order to
give an overall impression as to the goodness of fit within different areas of the
network. By default, once the “Link TP data to DB column” option has been
selected, the percentage error is automatically selected for display using the
current settings to display link data (e.g., numerical display).
Note that a particularly appropriate display format may be selected, code name
“Hallmark”, which uses a bandwidth presentation with a fixed width but with
colours dependent upon the level of percentage error. Thus errors below -30% are
in red, -30% to -15% in orange, -15% to 0% in green, 0% to 15% in light green,
15% to 30% in blue and above +30% in black.
11.8 P1X Analysis and Information Functions

P1X contains a large number of network analysis operations, the majority of which
are best carried out using the mouse. These are entered from the ‘top’ menu;
subsequent choices are indicated by the menu in the banner.
In particular the user may:
♦ request select link assignment (SLA) (11.8.1);
♦ define joy rides (11.8.2);
♦ display minimum cost trees, forests, etc (11.8.3);
♦ request link, bus or node-based etc. information for display in a text window;
ditto network-based information (11.8.4);
♦ Review output statistics from a run of SATME2 (11.8.5).

Further details are given in the above mentioned sub-sections.
5120257 / Apr 15 11-44

Section 11
In certain of these operations the link data created, e.g. forests, may be
permanently stored within the internal data base for later further analysis or
display.
Since certain of the analysis options may – dependent upon the network
configuration – use either UFC or UFO options (see 15.23.6) to reconstruct OD
routes and/or use aggregated (SPIDER) networks (see 15.56) for analysis options
are provided at the level of the top Analysis menu to choose between these
options. For example, see 11.8.1.12.
11.8.1 Select Link Analysis (SLA)
11.8.1.1 Basic P1X SLA Options

Select Link Analysis within P1X may calculate and display graphically those O-D
flows which are assigned to:
♦ a single link (the simplest case);
♦ a centroid connector (a special case of (i);
♦ through a series of (up to 19) nodes;
♦ a “screen line” of several links (see 11.8.1.9 and 11.8.1.10);
♦ a selected origin or destination zone;
♦ a set of “multiple” links (i.e., a set of repeated single links) (11.8.1.11).

Note that the “series of nodes” is, in effect, an “AND” test in that to be selected a
route must pass through all the nodes in the correct sequence; whereas the
“screen line” is an “OR” test in that, in order to be selected, a route may go
through ANY of the selected links (but see 11.8.1.10 for alternatives to the latter
rule). Use three nodes in succession to identify a turning movement.
Note that the same basic calculations (but with slightly fewer options) may also be
carried out within SATDB; see 11.10.7.5. See also 15.19 for a more general
discussion of SLA and alternative approaches.

Basically any O-D trips which use paths which satisfy the selection rules (e.g.,
pass through the single selected link) are re-loaded and the total assignment
pattern of those trips (normally both before and after they pass the selection point
but see 11.8.1.13 for alternatives) is displayed. See Sections 15.19 and 15.23 for
a more detailed discussion of the principles involved.
In particular please note the caveats in 15.23.2 that the routes which are
reconstructed in order to carry out a select link analysis do not necessarily
correspond exactly to those used within the actual assignment (e.g., if elastic
assignment or KOMBI or DIDDLE is invoked). Therefore the information
generated by the SLA may only be a first approximation to the “true” SLA: in
general the higher degree of overall convergence in the model, the better the
approximation will be. Please refer to the displays which list the SAVEIT Accuracy
for further information (See 11.8.4.7).
5120257 / Apr 15 11-45

Section 11
On the other hand it is always worth remembering that the precise route flows
generated by a Wardrop equilibrium assignment (and indeed for stochastic
assignment as well) are not unique, therefore neither is an SLA. Furthermore any
output data at this level of disaggregation should always be taken with a large
pinch of salt. We therefore recommend treating any SLA outputs as
“representative” rather than precise estimates.
In addition please bear in mind that the SLA flows arise only from the trip matrix
assigned and that they therefore exclude, e.g., bus flows or other fixed flows.
Hence SLA flows are very often significantly lower than the “total” flows - a
perennial source of confusion!
11.8.1.3 Matrix vrs. Flow Outputs

The output from a select link analysis may be in one of two forms: (i) either the link
flows as above or (ii) a matrix of the “selected” O-D trips saved as an output .ufm
matrix, in which case the flows on the links are not explicitly calculated or
displayed. The “Matrix - Yes” / “Matrix - No” option toggles between them.
Link flow data may be saved in the internal (SATDB) data base, either
automatically or optionally once created.
We note in this respect that there is a “Repeat SLA” option which is useful in the
situation where you require both flows and a matrix. Thus having defined and run
the “SLA” for, say, flows toggle to Matrix - In and simply repeat to avoid having to
redefine the links.
Users need to be aware of potential problems in simply trying to re-assign a SLA
matrix; see 11.10.7.7.
11.8.1.4 Full Statistics

Having carried out an SLA further details are available on screen (and reprinted in
the LP file) under “Full stats”. For example, the average travel time and distance
of all the selected trips is calculated plus (see 7.1.1.11) the flow-weighted supply
elasticity over those links used. In addition, if sectors have been defined, a
summary table of sector-to- sector movements using the selected links is
provided.
Furthermore, unless the SLA were based on a screen line of multiple links, a table
of disaggregated entry-exit demand movements is provided giving the flows from
each possible entry point at the first node to each possible exit point from the last
node.
11.8.1.5 Flow Definition

If the network contains a simulation network the flows may be defined in one of
three ways:
(i) demand flow
(ii) actual flows
(iii) queued flows
5120257 / Apr 15 11-46

Section 11
Thus under i) the flow considered to cross the selected link(s) is the full flow
demand flow as given by the input trip matrix whereas under ii) if the routes pass
through over-capacity links or turns it is the actual (reduced) flow which reaches
the selected link that is monitored. Note that any reduction to SLA flows is only
applied to over-capacity turns between the origin and the selected link; what
happens to those flows after the selected link is not relevant.
Queued flow is essentially the difference between the demand and the actual
(expressed in units of pcus/hr).
The same flow definitions also apply to SLA matrices (11.8.1.3). Thus, for
example, an actual trip matrix for a particular link represents those flows that,
starting from their origins, actually reached that link; i.e., any flow reductions after
the link are not considered.
11.8.1.6 Multiple User Classes

If the network contains multiple user classes options exist to select an individual
class for analysis or all classes combined. However any flows arising from “fixed
flows”, e.g., bus flows, are excluded from the analysis (although the fixed flow on
a single selected link may be displayed).
Under matrix output with multiple user classes either the matrix for a single user
class will be output or, if all classes have been selected, a “stacked” matrix for all
classes will be created.
11.8.1.7 Multiple Networks

If more than one network has been input the select link analysis may be carried
out on any one of them provided that the network is structurally identical to the
“base” network 1. The choice is made from the main menu. Thus if you use
network 2 the route proportions are taken from the .UFC (/.UFO etc.) file for that
particular network.
11.8.1.8 Multiple Trip Matrices

By default the trip matrix used to carry out a SLA is the trip matrix associated with
network 1. However it is possible to redefine the matrix if desired, subject to the
obvious constraint that the matrix must have the same number of zones, user
classes etc. as the network being analysed.
Note that changing the network does not automatically change the trip matrix to
that used by the new network; it must be explicitly user set.
11.8.1.9 Defining SLA Screen Lines

A “screen line” simply consists of a set of more than one links, traditionally
speaking a set of links which cross some form of geographical line; e.g., bridges
over a river. However screen lines as used within SLA could equally well
represent a “cordon” of links which surround a sub-area of the network, the set of
all links which are tolled, etc. etc. It is up to the user.
5120257 / Apr 15 11-47

Section 11
By default, to be “selected” as part of a screen line SLA, an O-D path must use at
least one of the links within the screen line – although there are variations if a path
crosses more than one link as explained in 11.8.1.10.
SLA screen lines may be defined in one of five ways:
1) by selecting links interactively using the mouse;
2) via a set of links input under the 7777 records;
3) those links currently “selected” (in the sense of 11.6.1);
4) via an external ASCII or text file; or
5) as a set of 666 combined constraints defined by a .ME2 file.
Under options (2) and (3) turns may also be included. In all five cases links are
“directional”.
The external file consists simply of a set of individual records, each containing a
link A-node and B-node. The format is “free” in that the 2 nodes must be
separated either by a comma or a space. Thus standard “fixed 5-column”
SATURN link records (e.g., 6.10) are acceptable unless 5-digit node numbers are
used, in which case it is possible that column 6 will not be blank. The file is
(preferably) terminated by a 99999 record.
Options (2) and (3) are also available within SATDB (see 11.10.7.5).
11.8.1.10 Multiple Crossings on Screen Lines

With screen lines it is quite possible for a single path to cross more than one link
in the screen line whereas for single links, single turns etc. it is not. There are
therefore options available within screen line SLA to select only those trips that,
say, cross two or more links or that cross two links exactly. These options were
first introduced in Version 10.5.
Two parameters may be set: (a) the “logical” choice between a minimum number
of crossings or an exact number; and (b) the number of crossings. Prior to 10.5
the rule was to include if the path crossed any of the selected links, i.e., minimum
and one above.
Information on the number of trips which are multiple crossings may be obtained
from the “Full Stats Table” by comparing the TOTALS of the SLA FLOW DEMAND
with the summation of the individual link demand flows.
For example, consider a screenline made up of two links, A-B and C-D, such that
the total flow is 1,000 on A-B and 2,000 on C-D with 500 which use both. The Full
Stats Table would contain:
A B 1000.00
C D 2000.00
TOTALS: 2500.00
Thus the totals is made up of 500 O-D trips which use A-B only, 1500 which use
C-D only and 500 which use both. The sum of the reported link flows, 3,000, less
the totals, 2,500, equals (in this case) the flow 500 which uses both. (N.B. This is
5120257 / Apr 15 11-48

Section 11
not a general rule since if one had more than 2 links in the screen line as would be
normal then there are all sorts of permutations and combinations of multiple
crossings to be considered and the difference between totals and sum would be
increased.)
If the Minimum Crossings had been set to 2 in the above example then only the
500 trips that use both would be picked up and the Full Stats Table would give:
A B 500.00
C D 500.00
TOTALS: 500.00
So that the sum of A-B and C-D less the totals still gives 500 – but again this is
not a general rule.
Note that if one chooses to output a matrix rather than link flows then the total
number of trips in the matrix should equal the number given under TOTALS.
N.B. Setting Minimum Crossings, etc. only works for analyses based on .UFC
files, not .UFO (as produced by OBA, for example).
11.8.1.11 Multiple Links SLA

Selecting a set of “multiple links” for SLA is effectively the same as selecting a
number of single links in succession, the main difference being that the SLA
calculations are carried out simultaneously with a corresponding increase in
efficiency. Thus carrying out an SLA on, say, 10 links may take only 10% more
CPU than that required to carry out an SLA on any single link; i.e., it is virtually 10
times faster per SLA.
Unlike a single link SLA flows from multiple links are stored directly into individual
columns in the SATDB data base where they may be accessed and processed in
the normal way. (N.B. The total link flows summed over all multiple links –
ignoring any possible double counting – is also calculated and displayed on the
network plot immediately after the SLA has been carried out.)
There are strong similarities between Multiple Links and Screen Line SLAs in
terms of inputs. Thus both may define their particular sets of links either one at a
time using the mouse, from an input file, from pre-set 77777 data or from currently
selected links (see 11.8.1.9). However
11.8.1.12 SLA based on Spider Networks

Select Link Analysis may also be carried out using an aggregated or “Spider Web”
network definition; see 15.56.7. The process is only (optionally) available if the
original network was built and assigned with SPIDER = T plus it is only applicable
to a certain sub-set of SLA options. Thus, at the time of writing, it may only be
applied to multiple links or to single links (i.e., not yet screen lines).
A menu-based option exists to choose between using the spider-based algorithms
and the original network-based algorithms prior to entering SLA. Alternatively a
parameter USESPI in the preferences file P1X0.dat (default = T) may be set to F
in order to select the non-spider methods by default.
5120257 / Apr 15 11-49

Section 11
As with other applications of Spider Aggregated Networks the main advantage is

one of greatly reduced CPU time.
Note that the algorithm employed by P1X to carry out SLA plus SPIDER makes
use of the “trick” of eliminating all those links which have zero assigned flow (see
15.56.5.3) and therefore can never contribute to positive SLA flows.
11.8.1.13 SLAs which distinguish Upstream and Downstream Flows

Prior to release 11.1 once a OD path had been “selected” (by whatever criteria) its
flow was loaded over the full O-D path. Post 11.1 it is possible to distinguish flows
which are:
• Upstream of the link (i.e., between origin and link)
• On the link
• Downstream of the link (i.e., link to destination)

Each of these 3 components may then be optionally included or excluded from the
calculated SLA flows using “toggle parameters” within the banner menu. By
default all 3 are included.
Thus it is now possible to carry out an SLA on, e.g., only links which are
downstream of a selected link and which, therefore, would be the link flows
affected if the link in question were, say, blocked by an accident. This facility has
applications to studies of re-routing and incidence analysis as covered in Section
15.19.
11.8.1.14 SLA “In a Basket”

Post release 11.3.03 an option has been added to allow the user to undertake
SLA calculations in, effectively, a semi-batch mode.
Basically the user interactively selects a set of SLA’s which are added to a
“basket” and, at the end of the SLA selections (select RETURN from the banner),
the full set of calculations is carried out “in the background” (i.e. there are no
screen updates), at the end of which the program either terminates or, optionally,
returns to full interactive mode.
All normal options continue to apply, e.g., demand or actual flows, origin or
destination side only, etc. etc., and may be set differently for each SLA in the
basket. In particular one may select the output to be either link flows or a matrix
(where the matrix filename is nominated after each SLA link (or whatever) is
selected). Thus the method is very useful for producing multiple SLA matrices for
a long set of SLA links etc.
If the output is in the form of link flows, not matrices, then the flows will never be
directly annotated in a link plot but an option allows them to be output in the form
of a standard text file with the basic format A-node_B-node C-node followed by
the complete set of SLA flows for that link. The text file may then be re-input into
P1X for further examination, exported to Excel, etc.
The standard summary statistics (e.g., total flows, total pcu-kms, etc. etc. per SLA)
are output to the .LPP file.
5120257 / Apr 15 11-50

Section 11
It is intended, at a future date, to produce a fully batch mode version where a

control file which specifies the full list of SLA links and the required options is
prepared by the user and input to P1X.
Ideal to set up a long weekend run on Friday afternoon!
11.8.2 Joy Rides

A “joy ride” traces a trip through a specified set of nodes selected using the mouse
and keeps a running sum of time, distance, etc. Cumulative totals of, e.g. time,
distance and speed, appear in the banner (see below) but are also contained in
the line printer listings for subsequent analysis. Equally basic properties (time,
distance, etc.) of the current link and/or turn are displayed.
The nodes selected need not be consecutive, the program “interpolates” the most
direct sequence of nodes as necessary (see 15.18). In the case of non-
consecutive nodes the “route” may either “jump” directly to the next node selected
with the appropriate cumulative totals displayed or alternatively the route may be
stepped through to each intermediate node.
WARNING: If two successive nodes in a joy ride are some distance from one
another and there are multiple possible routes, interpolation may not necessarily
find your desired route; the solution in this case is to select nodes which are much
nearer together and for which the route to be interpolated is unambiguous.
It is also possible to use this option to “select” - in the sense of section 11.6.1 -
those links in the route for subsequent analysis.
11.8.2.1 Cumulative Joyride Data

As a joyride progresses the graphics banner displays cumulative totals of:
(overall) time (with the possible addition of CLICKS times; see 11.8.2.3), delay,
distance, speed and generalised cost where “delay” is defined to be the difference
between actual “congested” time and the minimum time (i.e. the time under free
flow conditions) on links and/or turns. It might therefore be better referred to as
“additional delay”.
Generalised cost, denoted as “Fcost” for “Final cost” represents cost in time units
composed of both weighted distance etc. plus the final times (i.e., after the final
simulation). It is therefore, with multiple user classes, dependent on the specific
weights for the nominated user class.
In the event that the joyride route contains “penalties” - as defined under the
44444 records - then these too are recorded as cumulative totals. If there are also
multiple user classes then a single user class to which the penalties apply must be
nominated. Note that the penalties are further disaggregated into “time” penalties
or “tolls” as appropriate.
At the termination of the joyride a plot of the time along the route vrs the distance
along the link may be requested; see 11.7.2.
11.8.2.2 Averaging turn delays

By default if a joyride goes through successive nodes A, B and C then the turning
delay recorded at node B would be that for turn A-B-C. However it is possible to
5120257 / Apr 15 11-51

Section 11
use an alternative definition whereby the additional delay added at the end of link
A-B would be the average delay for all turns out of A-B. While this may not make
much sense in terms of analysing a particular route it does have the advantage
that if the available comparison data for calibration (e.g., from GPS systems) only
records the average delay at the end of a link, not for a particular movement.
11.8.2.3 Additional CLICKS Times

By default if a network includes CLICKS (i.e., reduced speeds for certain
vehicle/user classes on certain links; see 15.47) it is possible to include the extra
delays associated with CLICKS in the definition of cumulative travel times along
the joyride. This may be done either by specifying a particular user class to define
the added times or, alternatively, the user may specify the times to be averaged
travel times, weighted either by PCU or vehicle flows (see 15.47.4).
This option was first introduced in version 11.3.7, September 2014.
11.8.3 Trees, Forests and Arboreta

In order to display tree-based information it is first necessary to define: (a) and
origin and (b) - optionally but normally - a destination. If a destination is not
defined then the number of options available is limited to essentially building a full
tree (i.e., the set of all minimum cost paths from the origin).
MAIN DISPLAY OPTIONS

Assuming both the origin (O) and destination (D) are set you may display either:
a) the minimum cost route (“tree”) from O to D (generally, but not necessarily,
using the same criteria employed by the assignment);
b) the complete tree from O to all nodes (including all zones);
c) the complete tree from O to all zones (with any zones that cannot be
reached, e.g., due to a disconnected network, indicated by a large X);
d) the minimum cost route as (a) but as a “joy ride”, i.e., link by link;
e) the complete set of O-D routes from an iterative FW assignment plotted
iteration by iteration (with either the screen cleared between each route or
in “overlay” mode where they are superimposed on one another);
f) the complete set of O-D routes plotted as a “forest”;
g) the full set of distinct routes, an “arboretum”;
h) as origin-based “isochrones” - see 11.8.3.3;
i) the set of least well converged O-D routes – see 11.8.3.4;
j) splitting factors as calculated under OBA – see 22.5.2;
k) link-specific gap / delta values – see 11.8.3.5.
5120257 / Apr 15 11-52

Section 11
See Section 15.26 for further explanations of the concepts. Note that not all the
above options, e.g., e) and g), may appear under OBA where explicit paths may
not be stored (see 22.5.2).
A summary banner which displays, e.g., the cumulative (“skimmed”) time, distance
etc. associated with the displayed route is included when appropriate. See Section
11.8.2.1 under Joyrides for further explanation of the data displayed.
With certain options, e.g. forests, it is possible to “store” the link data generated as
an extra column in the link (SATDB) data base, e.g., for further analysis.
Trees may also be displayed “in reverse”, i.e. into a destination as opposed to out
of an origin. However the destination-based options are limited essentially to
building “full trees” from all nodes since specific O-D tree information is provided
only within the origin-based menu.
11.8.3.1 Tree Build Options

By default the O-D trees are built using identical criteria to those set for the
assignment; however these criteria may be adjusted to illustrate the effect of using
different criteria. Thus the “cost” used to define minimum-cost routes may be re-
defined or you may toggle to and from stochastic assignment, etc.
In the event of multiple user classes a single class must be nominated and the
trees etc. for that class are displayed. Note that at the moment it is not possible to
select “all” user classes to produce an automatic loop over all classes; this needs
to be done manually.
It is also possible when building a single O-D route to display the time vrs distance
plot for that route after the tree has been plotted, either automatically by setting a
5120257 / Apr 15 11-53

Section 11
parameter under options or, effectively as an after-thought, through the post-tree

display menu.
11.8.3.2 Trees and/or Forests using Alternative Networks

When more than one input network file is being used it is possible, under certain
circumstances, to view the routes as generated by, say, network 2 as opposed to
network 1 (which is the default). However this is generally only feasible when the
two networks are structurally identical (such that a link in network 2 will appear in
the correct location when displayed on a network 1 map).
This facility only applies to those options which display the routes as built during
the assignment, i.e., arboreta and the complete sets of O-D routes. However, with
forests the comparisons may be taken further such that it is possible to construct
link data equal to, e.g., the difference in the forest values between networks 1 and
2, or to plot both simultaneously, etc.
11.8.3.3 Isochrones
A related display, still very much under development, shows “isochrones” of equi-
cost bands from the origin as overlapping in-filled coloured bands. These are
based not just on the costs from the origin to discrete points along the road but to
any point in the 2-dimensional space within the network by the additional
assumption of a “walking speed”. Thus the cost to reach any point (X, Y) is made
up of the cost to get to the “nearest” point on the road network plus the extra
time/cost to “walk” from the road (assuming the minimum crow fly distance).
Parameters to be set include:
♦ The definition of “cost” (e.g., minimum time, distance, generalised cost, etc.
etc.)
♦ the number of bands
♦ the “width” (in generalised seconds) of each band
♦ the walking speed in kph.

Destination-based isochrones may also be displayed with similar choices.
N.B. “Walking speed” may equally well be interpreted as “driving speed on minor
roads”, in which case a default value considerably greater than the default walking
speed of 3.6 kph should be set; e.g., 20 kph. (Change the namelist parameter
WALKPH in P1X0.DAT.)
5120257 / Apr 15 11-54

Section 11
DISPLAYING ISOCHRONES AS NODAL DATA

It is also possible to display isochrones in terms of the minimum “cost” to every
node (or, similarly, every zone) in the network from the origin / to the destination.
In this case the cost is indicated by a variable coloured circle at each node/zone
such that all nodes in the same cost band have the same colour.
SAVING ISOCHRONES AS NODE DATA

New options introduced in 10.7.8 allow the calculated minimum costs to each
node (as above) to be stored either: (a) to an external ASCII (text) file, or (b) to an
internal SATDB node data column.
Under (a) the output file consists of 4 data items per record:
(1) Node number
(2) Its X (horizontal) co-ordinate
(3) Its Y (vertical) co-ordinate
(4) Its minimum cost
and this could then be fed into a “proper” GIS system which could then produce
“proper” line contours in whatever format is desired.
Under (b) the node data could be manipulated internally as desired; see 11.10.5.
For example, the node minimum costs could be displayed using any of the
standard node display options (11.6.5). Alternatively, one could do things such as
calculating the isochrone minimum cost to several zones representing, say,
5120257 / Apr 15 11-55

Section 11
hospitals so that taking the minimum over several data columns would then give
you the (minimum) cost from every node to the nearest hospital.
11.8.3.4 Worst O-D Routes

These options allow one to identify which O-D paths are “furthest” from being in
Wardrop Equilibrium; i.e., those (positive flow) paths P ij where c pij – c ij * is
maximised.
The first option “All O-D Pairs” produces a table of the 10 worst paths by origin
such that for each origin zone the single worst O-D path is selected and then
worst paths are ranked by origin. For each origin the table lists the single
destination to which the worst path was found and the difference in costs for the
worst path.
The second option identifies the 10 worst paths for the current origin and, in this
case, lists the particular destinations plus total O-D flows (i.e. T ij , not T pij ).
Note that in neither of the first two options is the exact volume of traffic T pij on the
worst paths taken into account (as long as it is positive). Thus it may well be that
the worst paths identified may not be necessarily all that important in terms of the
overall lack of convergence (see eqn. 7.3 for delta) since the maximum value of
c pij – c ij * may be associated witb a very small path flow T pij which the assignment
algorithm is doing its best to reduce to zero. The link delta values described in the
following section are superior in this respect in that they are flow-weighted.
Costs per link – and hence by path – may be set either as calculated at the end of
the last assignment or as calculated at the end of the following simulation. In the
former case we identify those paths which make the maximum contribution to the
delta function; in the latter case it is the contribution to the combined gap function
which, in turn, may be used to indicate where the overall simulation-assignment
convergence is weakest.
11.8.3.5 Link-specific Gap and/or Delta Values

The contribution made by an individual link (A,B) to the delta/gap functions may
be calculated by the following equation:
δ AB = Σ pij∈AB T pij (C A * + C AB - C B *)
Where C A/B * is the minimum cost from origin I to node A / B
C AB is the cost on link (A,B)
T pij is the flow on path p from origin I to destination j
pij∈AB denotes those paths that use the link (A,B)
The “cost” term in the brackets represents the extra cost above and beyond a
minimum cost path that a vehicle from I to j would incur by using link (A,B) and is
therefore a measure of its departure from Wardrop Equilibrium. Under perfect
equilibrium if the cost term is positive then T pij should be zero; if T pij is positive then
the cost term should be zero.
We may note that summing δ AB over all links would give us the same numerator
as the equation (7.3) for Delta (Section 7.1.4)
5120257 / Apr 15 11-56

Section 11
Link delta values may be further disaggregated by, e.g., only considering a single
origin. Equally we could produce an origin-specific delta value by summing over
all links with the origin i fixed.
The banner provides several options for calculation and display. Thus we may
calculate δ AB for the single selected origin or summed over all origins. (The former
is generally recommended for large networks since the cpu time required to sum
over all origins is roughly equivalent to carrying out a full assignment and, if you
choose an origin whose trips cover most of the network it should pick out those
links which have problems of convergence.)
Note that link delta values are set by assignment links which therefore, in the
context of a simulation network, contain both simulation roads and turns. In order
to view the full set they may be stored as a data base column and viewed
normally.
However, once set, link delta values are automatically displayed as link annotation
but, in this case, the value displayed for a simulation link (A,B) will have been
incremented by (a) all delta values for its exit turns (i.e., A-B-C) and (b) by all its
entry turns. The reason for this is that the turn values – which may well be more
significant than the pure link values – are otherwise not obvious. Large delta
values on, say, links A-B and B-C probably indicate a large contribution to both
from the turn A-B-C.
The times used in the calculation of generalized cost above may be either taken
post-assignment or post-simulation. In the former case δ AB is comparable to the
delta function (7.1.4); in the latter case it is comparable to the gap function (9.2.1).
11.8.4 Information Options
11.8.4.1 General Options

These options provide, firstly, basic data interactively on:
♦ Links
♦ Nodes
♦ Zones
♦ (Bus) routes
♦ Bus routes through a link (“Select Link Analysis”)
♦ X,Y co-ordinates
Secondly, a range of options as otherwise provided by SATLOOK:
♦ Network parameters
♦ Simulation and/or buffer summary statistics

And, thirdly, various miscellaneous pieces of information:
♦ Flows making U-turns at external simulation nodes
5120257 / Apr 15 11-57

Section 11
♦ An assessment of the validity of the network parameters chosen
♦ Accuracy estimates under SAVEIT
♦ CPU time etc. statistics
♦ A list of all errors encountered in SATNET
♦ A full listing of the “history file” (see 6.2)
♦ A list of the “must have” or essential files in order to run this network.
These are described in sub-sections 11.8.4.2 to 11.8.4.11.
11.8.4.2 Interactive Information: Links, Nodes, Zones and (Bus) Routes

The user may, for example, select a specific link and a text window displays a set
of the most relevant statistics describing that link, e.g. distance, flows, speed etc.
A full listing of all bus routes through that link is also included (see below). Data
related to individual nodes and/or zones are displayed in a similar manner.
Two basic options are available with routes (where “routes” include both “bus
routes” with a positive frequency and “timing point routes” where the frequency is,
generally, zero; see 6.9.1).
Firstly, individual routes are displayed using both numerical data (in the banner)
and a link-by-link graphical (“joy ride”: section 11.8.2) display (see the figure
below). Secondly, all bus routes which pass through an individual link (a form of
“Select Link Bus Analysis”) are displayed by simply “marking” all other links used
by the selected services. (More complex data display formats could be provided
relatively easily; e.g., annotate the total bus flows per link, names of the bus
routes, etc. etc.; requests to DVV.)
In addition it is possible to select certain subsets of routes either:
(a) by nominating a “bus company” or
(b) by selecting a certain class of routes, e.g., only routes with timing points, only
routes with positive bus frequencies, etc.
All these functions are “look only”, i.e. no editing is possible.
5120257 / Apr 15 11-58

Section 11
11.8.4.3 X,Y Monitoring

X,Y monitoring allows the user to identify the user co-ordinates with points within
the plotted window by simply moving the mouse within that area; the
corresponding user co-ordinates appear within the banner. This facility is useful,
for example, in “calibrating” the corners of a .bmp file (see 15.43). To terminate
“monitoring” click the mouse at any point.
11.8.4.4 SATLOOK-style Network Statistics

Several of the options traditionally available within SATLOOK to provide network-
wide or aggregate information may also be accessed (in a window display format)
from within the P1X Information options. Specifically:
♦ Network parameters (e.g., numbers of nodes and links plus selected

parameter values);
♦ Simulation and/or buffer summary statistics
♦ Convergence plus error statistics

For more information see 11.11.7, 11.11.4 and 11.11.8 respectively.
Note that some of these options give less data than provided by SATLOOK, for
example simulation/buffer statistics disaggregated by user class, capacity index
etc. However (new with 10.5) the table which compares simulation statistics over
multiple networks is available in window format.
5120257 / Apr 15 11-59

Section 11
11.8.4.5 Parameter Examination

This option assesses all current standard Namelist parameters (i.e., those
described in 6.3) and displays a list of warnings where the Grand High SATURN
Judges/Executioners feel that you may be doing something just a tiny bit stupid.
Or indeed very stupid.
11.8.4.6 U-turns at External Simulation Nodes

This option prints (to a window and to the .lpp file) a list of all external simulation
nodes where U-turns are possible and an estimate of the total flow making such
U-turns. See 18.9.
11.8.4.7 Accuracy of SAVEIT

The O-D routes re-constructed by P1X are not necessarily identical to those
generated by the assignment; this option outputs a table of goodness-of-fit
statistics as described further in 15.23.2.
11.8.4.8 CPU Time Etc. Statistics

This lists total cpu times split by network building/assignment/simulation stages
plus various other useful parameters and/or outputs such as elasticities that do
not naturally fit any place else.
11.8.4.9 List of Warnings etc. within SATNET

This option lists both the number of times each individual Warning, Serious
Warning, etc. etc occurred within SATNET with a one-line description of the error
(whereas the same numbers but with potentially longer descriptions are given in
.LPN files) plus the breakdown into 11111, 22222 etc. segments.
11.8.4.10 List of the History File

This option lists the full contents of the “history file” as input via the original
network .dat file; see Section 6.2.
11.8.4.11 List of “Must Have” Files

This option lists all those files which are essential to running the network, e.g., the
name of trip matrix file, along with a full list of all the $INCLUDE files referenced
within the .dat file. This provides a useful cross-check when sending a complete
set of files to other people.
11.8.5 ME2 Data File Analyses

Following SATURN 10.5 SATME2 now outputs a “ME2” data file (see 13.8) which
P1X may read and carry out further analyses. Within P1X the user may either:
♦ display selected data fields from the .me2 file, or
♦ print summary statistics, or
♦ select links from combined constraints set directly or,
5120257 / Apr 15 11-60

Section 11
♦ once selected, a combined constraint set may be analysed as a screenline

under SLA (in order, primarily, to detect multiple crossings).
The data fields include both inputs to SATME2 such as the counted flows and
outputs such as the post-ME2 flows, the X a balancing factors, etc.
The summary statistics consist of Tables 4b and 5b as contained within the .lpm
output files and giving goodness of fit statistics between the updated matrix and
the target counts.
11.9 P1X Editing Facilities

P1X may edit either:
♦ the network; and/or
♦ the associated GIS data (5.7.2).

(P1X may also produce data-specific ASCII sub-files where, for example, one can
edit the co-ordinates in order to produce a file containing only the new X,Y co-
ordinates. However these applications are being progressively discontinued as
their functions are subsumed within the standard network and/or GIS editing
options.)
11.9.1 Network Editing

A full discussion of network editing is given in Section 18 and there is a
considerable degree of overlap between this section and 18. In particular Section
18 explains how network editing in P1X may be sub-divided into:
1) Changes to “properties” of the existing network, e.g. link capacities.
2) Changes to the network “topology”, i.e. additions or deletions of nodes, links
or turns.
Topological changes are handled by a routine within P1X referred to as PMAKE
as well as by option (2) below. These functions are described in Section 18.
Within this section we concentrate primarily on changes to properties.
Within the main edit menu options are provided to:
1) edit existing simulation nodes (as in SATED)
2) edit simulation centroid connectors (strictly speaking, topological changes)
3) edit existing buffer links
4) edit penalised or restricted links
5) change XY co-ordinates
6) edit (bus) routes
7) edit counts
8) edit the generalised cost definitions
5120257 / Apr 15 11-61

Section 11
9) update namelist parameters/options

10) convert buffer nodes to simulation
11) make (global) changes to traffic signals including:
a) optimise all signalised green stage times and/or offsets
b) transplant signal settings between networks
c) update stage times and offsets (which might have been altered within
SATALL, for example)
12) screen edit segments of the internal .dat file.
13) Edit “data fields”, e.g., link distances over all simulation links, using data input
from external data files.
Note that options (1) to (8 above correspond with data sections 11111 to 88888 as
defined in the data files input to SATNET (6.1) while (9) edits the namelist-based
records (6.1) and (6.3). Option (10) essentially adds to the 11111 records (while
effectively removing records from the 33333 buffer records). Options (11) over-
write the signal timings within the 11111 records.
These are described in sub-sections 11.9.3 to 11.9.17.
Note, finally, that PMAKE may also be entered directly from the master edit menu
(see 18.1) in order to make topological changes as may the GIS-edit option.
Finally various options to output (save) new files as described in 11.9.2 may be
accessed.
All changes made are continuously recorded to a .dat file which is stored as an
internal “direct access” file which initially is copied from the original .dat file from
which the main network was built in SATNET. That filename 2. At the end of the
program run, once all the editing changes have been carried out, the internal
direct access file may be copied (“dumped”) to a new output .dat file (see 11.9.2),
from which a new network may be built by running SATNET. This is the
recommended option. See also 18.2.2.
Thus, as stressed in section 18.1, the main function of editing within SATURN is
to produce a revised .dat file from which new assignment and analysis runs may
be initiated.
11.9.2 Saving Edit Changes to Output Files

Network edit operations may be preserved in a variety of formats by producing:
♦ an updated .dat network file;
♦ an updated .ufs file;
2 The .dat file name should be recorded within the .ufs file and therefore opened automatically,
but, if not, the user must supply the correct file.
5120257 / Apr 15 11-62

Section 11
♦ a new .ufn file as (re-)built from the .dat file;
♦ sub data text files, e.g., .RGS and .XY (see 11.9.14 and 11.9.7 respectively);
♦ a (text file) network description based on the map-based link structure;
♦ an updated .dat network file with data sub-sets created as $INCLUDE files.
Please note that none of the new file formats above are automatically created but
must be specially requested by the user (see the output options within the edit
banner menu). The following sub-sections describe each of the above options in
greater detail.
11.9.2.1 Saving an Updated Network .dat File

A new network .dat file may be created at any point during editing as a direct copy
of the input network .dat file plus any changes made during the edit. Although
generally this option would be invoked at the end of an edit run once all changes
have been made it is probably good practice to take frequent copies of .dat files
during editing to avoid accidents. (Users are prompted at the end of an editing
session if a .dat file has not been created.)
Section 11.9.2.6 describes a variant on the above method where a complete new
network .dat file is created but with each individual 11111 etc. data segment
created as a free-standing file referenced via as $INCLUDE. 11.9.2.7 describes
how existing $INCLUDE files in the input .dat file are treated.
Note that an updated .dat file may only be created if there were an input .dat file
to be used as the “template” for further changes.
11.9.2.2 Saving an Updated .UFS File

New .ufs files are built partly as a direct copy of the old .ufs file (network 1) but
with some arrays updated in accordance with editing changes made during P1X.
However there are restrictions as to when they can be produced and what “new”
data may be included.
Thus a .ufs file may only be output if there have been no changes to the network
“topology”, i.e. no nodes/links added or deleted, only changes to “properties”.
Secondly, not all the possible editing steps described below affect the .ufs output
file. At the moment only the XY updates, editing of existing simulation nodes,
optimised stage times and/or offsets and (optionally) namelist parameters
(11.9.11) are included 3.
11.9.2.3 Saving an Updated .UFN File

Ufn files are commonly “re-built” during editing in order to check for errors in the
current data and to update the linkages between the various network components
(e.g., the simulation and assignment networks); detailed documentation is
3 Note that certain options within P1X re-read simulation data from the input .ufs file and therefore over-
write any internal simulation data that has been modified; for example re-assignment options under
SATDB (11.10.7) based on networks other than network 1. Therefore if you wish to save an updated
.ufs file you are advised to do so immediately after editing.
5120257 / Apr 15 11-63

Section 11
contained in 18.2.4. The effect is equivalent to dumping the updated network as a

.dat network file and processing it through SATNET.
11.9.2.4 Saving Network Data Sub-files

It is also possible to save data “sub-files” such as the updated signal settings in
the form of a .RGS file (see 11.9.14) or node co-ordinates in a .XY file (see
11.9.7).
11.9.2.5 Creating a Network Based on Map Links

An output text file describing the structure of the links in the map network may
also be created with a 33333 format as described in Section 11.4.2.3.
11.9.2.6 Saving network data as $INCLUDE files

Similar to 11.9.2.1 an updated network .dat file may also be created but with each
individual data segment created as a separate sub-file which is referenced by a
$INCLUDE record within the main network .dat file (See 15.30). Thus a file
newnet_11111.dat would contain all the 11111 simulation network data and the
11111 data set within newnet.dat would contain a single record: $INCLUDE
newnet_11111.dat.
Note that this option may usefully be invoked to transform an existing network .dat
file into a set of $INCLUDE files in a purely non-editing context by simply entering
Network Editing and going straight to the Output options.
11.9.2.7 Editing and Saving (input) $INCLUDE Files

If the original network .dat file contained references to one or more external data
files via a $INCLUDE record it is possible that the particular section of data which
the user wishes to edit is not in the “master” input .dat file but in an included file.
To allow for this the $INCLUDE files are explicitly copied into the internal .dat file
where they may be edited in the normal fashion.
If the original network file does contain included files, there is a choice of output
formats where either:
(a) “new” $INCLUDE file(s) are created with the same filename as before which
over-write the originals or
(b) they may continue to be explicitly incorporated within the new .dat file.
In the latter case references to the old $INCLUDE file names are retained but
commented out with a * in column 1. The user may manually recreate new
$INCLUDE files by using a text editor to cut’n’paste from the new .dat file or
simply leave them within the new .dat file. If the network editing proceeds by a
series of small steps it is very often easier to leave the $INCLUDE data within the
main .dat files and only re-create the final new $INCLUDE files at the end of the
process.
Unfortunately the user is not always given the explicit choice between methods (a)
and (b) and more often than not it is the programme that decides. For example,
we note that the automatic network editing procedure SIGOPT – see 15.31.6 –
5120257 / Apr 15 11-64

Section 11
which optimises the stage times and/or offsets automatically using P1X by default
uses method (b); i.e., it incorporates all the old sub-files within the new .dat file.
N.B. The above material applies equally to files which are created using either of
the methods described in 11.9.2.1 or 11.9.2.6. Thus, in the latter case, a newly
created $INCLUDE sub-file may contain internal references to other $INCLUDE
files if they were referenced in the original network .dat file.
11.9.3 Editing existing simulation nodes

The simulation nodes to be edited may be selected either, individually, using the
mouse and/or keyboard input (node number) or as part of an automatic loop over
all nodes which have been either: (a) selected or (b) highlighted on the screen
(see 11.6.5.4). They may also be selected individually in certain situations by
double-clicking on the node in a network plot or by clicking on an adjacent A-node
number in a node plot.
Highlighting is very useful for correcting all nodes which exhibit, say, a common
error or a problem in terms of convergence. Note that, in the latter case, loops
may be initiated directly within this menu, e.g., by looping over the 10 worst delay
nodes, as opposed to having highlighted nodes prior to entering the node edit
options.
Once selected a simulation node is “displayed” as per standard node graphics
(11.12) and its various “non-topological” input properties such as lane definitions,
saturation flows, signal settings, etc., may be altered interactively.
The changes requested are recorded both within the internal simulation arrays
(from whence they would be dumped into a new .ufs file) as well as into a “mini”
dat file which contains the node, link and/or signal data for that node only as
described in Section 6.4. The mini data file is normally extracted from the “full” .dat
file but if, for some reason, it cannot be found in that file a “temporary” version is
created. At the end of editing the “mini” dat file may be re-inserted into the full .dat
file (unless you wish to “quit” the edit) which, as mentioned above, may itself be
saved as an external file at the conclusion of all editing steps.
The screen display is updated at the same time as the stored data and the current
contents of the mini .dat file may be directly viewed under “List” or a standard
“interpreted” print-out on screen of the node data may be obtained under “Print”.
Data alterations are subdivided under node, link, turn and signal (if appropriate)
headings within the banner menu or, alternatively, data edits for an individual link
may be accessed directly by clicking on the “box” at the end of each arm. Once a
link has been selected turns may be selected by clicking on the box at the end of
the appropriate exit arm.
(Note that the data which may be edited also includes certain “non-input”
properties such as actual flows. Editing these will have no impact on the node’s
data base but are included so as to allow a certain degree of “experimentation” as
mentioned in 11.12.4 and 11.12.5.)
At any point the node may be re-simulated and the effect of the changes viewed
as under SATLOOK (11.11.1).
5120257 / Apr 15 11-65

Section 11
The “Error Listing” gives a list of those errors which would be detected within
SATNET if the current net node coding were input there, including errors to the
signal definitions (separately available within the signals sub-menu).
Current errors are also noted under the Print option where the numbers of
warnings, non-fatal errors etc originally detected at this node by SATNET are also
listed (but not the explicit messages); some of these may of course have been
corrected by the current editing. Note however that certain errors found in
SATNET may not be detected within the node graphics if they are only detected
as the result of the coding of two or more simulation junctions. For such errors the
.lpn listing from SATNET will need to be consulted.
11.9.3.1 Banned Turns

Editing, i.e., adding or deleting, banned turns allows topological changes at the
simulation node and the mini .dat file to be updated accordingly. However once
such changes are made the node is “re-created” as an additional node at the end
of the normal simulation nodes such that any further changes are no longer
applied to the .ufs data. For this reason editing banned turns are not permitted
within the “normal” node graphics (11.12).
Once changes have been made to banned turns (either additions or deletions) it
will no longer be possible to output the revised network as a .ufs file, only as a .dat
file.
11.9.3.2 Screen Editing

The screen editing option within simulation node editing allows the “mini” .dat file
associated with that node to be edited directly on-screen via a standard Windows
edit box and any changes made therein to be re-incorporated back into the
internal node definitions. In a sense screen editing is the converse of the normal
editing steps described above where changes requested interactively are applied
directly to the internal memory and the program itself then edits the .dat file; here
the changes to the .dat file drive the editing process.
Screen editing may also be used to add “comment cards” to the node data set by
inserting records which commence with a *. By convention any comment cards
which immediately precede a node record are considered to be part of that node’s
records and are therefore included in the “mini” dat file extracted from the main
network .dat file. Clearly these records may also be edited and/or extended using
screen editing.
Note that the same general “relationship” holds with all the following segments
where direct editing of data file is permitted.
11.9.4 Editing Simulation Centroid Connectors

N.B. All the edit options described herein are “topological” in that all changes
made to the 22222 data records result in changes to the centroid connectors.
Strictly speaking therefore they are more akin to PMAKE than to, say, node
editing but they are documented here (as well as in 18.7) since they are accessed
from the same menu as node editing.
5120257 / Apr 15 11-66

Section 11
Centroid connectors within the simulation network (as defined by the network
22222 records, 6.6, and distinct from those in the buffer network) may be altered
in seven ways:
(i) By modifying an existing zone record (i.e. one that already exists within the
22222 records);
(ii) By deleting an existing 22222 zone record;
(iii) By adding a new 22222 record (from a zone currently connected within the
buffer network);
(iv) By creating a new zone plus simulation centroid connectors;
(v) By replacing an existing centroid connector to a link with a “stub” connection
to a new dummy node created mid-link (11.9.4.1);
(vi) By screen editing;
(vii) By deleting any “duplicate” zones which have identical centroid connectors
and aggregating them into a single zone (where the remaining zone is the
zone with the lowest number).
In cases i) to iii) zones are neither created nor removed (this must be done using
PMAKE); thus with ii) the zone should presumably remain connected within the
buffer network while iii) is more a question of transferring an existing zone from
the buffer to the simulation network.
However invoking any of the options above will change the location of the centroid
connectors and hence the definition of the map network “topology”. Hence this
option is like PMAKE in respect to topology such that, once changes are made
here, certain restrictions on what further steps may be taken in P1X come into
force. Clearly iv) is also topological in that it creates both zones and connectors.
Under i) a listing of the current zone record appears on the plot as the “legend”
and is continually updated as changes are made. Under iii) once a new zone is
selected for addition a new blank record is created and option i) is automatically
entered. Those changes affect both the .dat file and the map network but not the
structure of either the assignment or simulation networks.
11.9.4.1 Creating ’Stub’ Connectors

A “stub” connector (also referred to as a “spigot” connector) in this context refers
to a zone which is connected to an external simulation node which itself is
connected to a node in the middle of an internal simulation link as illustrated below
using the example used in Section 16.6.
5120257 / Apr 15 11-67

Section 11
Thus if the existing network were coded as in the upper diagram with zone 5
connected to simulation link (3,5) option v) would create two new nodes, 6 and 7
in the lower diagram and connect the zone to zone 7. Here node 6 would be a 3-
arm priority junction with all three arms being coded as “major”; clearly further
editing of that node would be desirable.
The node numbers (i.e., “names”) allocated to the two new nodes would be (as in
the above example) n + 1 and n + 2 where n is currently the highest node number
used.
Stub creation may be applied either to individually selected zones or, with some
caution, to all internal simulation zones. It does not however apply to “external”
simulation zones.
Note that stub/spigot connectors are prime candidates for “network aggregation”
as described in Section 15.56.2.3.
11.9.5 Editing Buffer Links

“Editing” here refers only to editing the properties of existing buffer links;
topological changes to buffer links (i.e. adding or detecting) can only be done
under PMAKE. (See 18.6.)
Thus after selecting a buffer link the appropriate record from the original .dat file is
accessed and displayed within the normal plot legend (default at the bottom of the
screen). The user is then presented with an edit box to make changes to the
time(s), distance, etc.
5120257 / Apr 15 11-68

Section 11
Note that link properties which are “added” within SATURN, such as flows or the
speeds/times at those flows, cannot be edited at this stage, only the input
properties as defined under 6.6.
Two further procedures are also optionally provided under buffer link editing:
1) An option to delete all “second line” KNOBS data records; see 15.14.7
2) An option to correct all duplicated link records by deleting the second
occurrence of a repeated A,B record (if any exist).
11.9.6 Editing Penalised/Restricted Links

Facilities here are similar to those provided to edit counts (11.9.9) in that links
and/or turns may have their “ban/penalty indicators” (see 6.7) either added,
deleted or edited. The modified data set is then re-inserted into the internal .dat
file.
If there is more than one set of 444 records a particular sub-set needs to be
selected.
As with simulation node editing a screen edit option is also available.
Note that there is an upper limit of 399 44444 data records which may be edited at
any one time. This upper limit may be partially circumvented by dividing the full set
of 44444 data records into a number of smaller $INCLUDE files, only one of which
may be edited at any one time.
11.9.7 Editing Node Co-ordinates: .XY Files

Node (and/or zone) co-ordinates may be altered by selecting the node with the
mouse and pointing to the new position. These co-ordinates then apply through
the remainder of that program run.
They may be subsequently saved either within full .ufs or .dat files or by outputting
a new .xy sub-file which contains a complete list of all nodes, zones and sectors in
text format.
By default the output co-ordinates are in the same format as that specified for the
input .dat file (see 6.8) but, post 10.9.14, alternative formats may be set
interactively. Thus the number of (fixed) columns per X or Y may be increased or
a CSV format chosen (FREEXY = T). Alternatively the co-ordinates may be
multiplied by the implicit factor XYUNIT so that they are in metres (as strongly
recommended; see 15.43.2)
Such a file may be “edited” or “$included” into a network .dat file. See 11.4.2.
Indeed it is quite useful to create a standard data file containing co-ordinates
which can be “$included” within a large number of networks since it is common
practice for all networks within a particular study area to share a common
definition of nodes and co-ordinates. This saves the need to edit a wide range of
.dat files.
5120257 / Apr 15 11-69

Section 11
Note that a supplementary “.xy” sub-file may also be an input file to P1X. Any
value read in over-writes the current value as read from the .ufs input file. See
11.4.1.
11.9.8 Editing (Bus) Routes

Recall from Section 6.9.1 that “routes” may include both “bus routes” - the most
common application - and routes with zero frequency which may be used under
validation. Both may be edited here. Note however that any changes made here
will only be saved as .dat file - they have no effect on an output .ufs file.
Routes may be either:
1) added,
2) deleted
3) edited (i.e., for currently existing routes)
4) copied and edited to create new routes.
When added under (1) the new route is defined by using the mouse to identify a
number of “key” junctions along the route (as under the interpolation option
described in 15.18) plus parameters such as a route name and frequency. Each
route thus defined is added to the internal .dat file.
Equally when a route is deleted its records are removed from the internal .dat file.
Editing an existing route (or equally a route which has been copied from an
existing route and renamed) has several sub-options which may be further sub-
divided into: (a) changes to the sequence of nodes which define the route, and (b)
changes to its various properties.
Under (a), the sequence of nodes:
1) The route may be extended at either end by adding new nodes;
2) The route may be shortened by removing nodes at either end;
3) A mid-section of the route may be removed and re-routed via a new set of
nodes
Under (b) the user may redefine, e.g., the text name of the route, its frequency,
etc.
The changes requested under (a) or (b) above are then reflected by changes to
the entries in the .dat file which describe the route. The records in that file may be
either listed to the screen or, as an alternative to (a) and (b) above, they may be
screen edited to introduce the same sort of alterations. (But, BE WARNED, screen
editing may also introduce coding errors which may go undetected!)
A further editing alternative, which sits somewhere between (a) and (b), is to
editing the “timing point” information associated with nodes along the route. See
6.9.5. Again timing points may be added, deleted or modified.
5120257 / Apr 15 11-70

Section 11
11.9.9 Editing Counts

Counts (whether on links or turns) may be either:
a) Added
b) Deleted
c) Edited.
In addition they may be grouped into “count sets” which may equally be edited as
necessary.
Under additions new counts are set by (a) pre-selecting either links or turns, (b)
defining the link or turn and (c) defining a “count” (or “counts” if NMCC > 1) whose
units are assumed to be in pcus/hr. This information is then added as a new
record to the internal .dat file under the format required for 77777 data input to
SATNET (section 6.10).
Deletion follows steps (a) and (b) above with the proviso that only links/turns
which already have counts may be deleted, whilst editing also first selects an
existing count but then re-defines the count(s).
At any time the above operations are only applied to the “current” count set which
may be changed (if more than one set already exists) or new count sets may be
created (which then clearly should have new counts added).
Screen editing, using a standard Windows edit box, may also be used to update
entries for the current count set, in which case the new text is inserted directly into
the internal .dat file.
Note that there is an upper limit of 399 77777 data records which may be edited at
any one time within PMAKE. This upper limit may be partially circumvented by
dividing the full set of counts into a number of smaller $INCLUDE files, only one of
which may be edited at any one time.
11.9.10 Editing Generalised Cost (MUC) Data

The generalised cost records as held under the 88888 data set records on
network .dat files (see 6.11) are edited using specially created Windows edit
boxes in which the user changes values on screen and the new values are saved
in the internal .dat file. Alternatively changes may be invoked either by screen
editing the full 88888 records or by explicitly setting new values in a single (user
class) line.
11.9.11 Namelist Changes

Menus here allow the various parameters defined under &OPTION and &PARAM
in the network .dat files (see 6.1 and 6.3 respectively) to be modified for output to
a new network .dat file.
By default the changes only apply to the output .dat file, not to the current network
settings within P1X or any output .ufs file. Thus changing a simulation-based
parameter such as LTP will not change the manner in which simulation nodes are
modelled anywhere within P1X. However, post 10.5, the changes may also be
5120257 / Apr 15 11-71

Section 11
applied internally and would therefore be included on an output .ufs file; a “toggle”
is provided within the relevant P1X banner. This may be useful if, for example,
one wished to change, say, ISTOP before doing a continuation run of SATALL
(9.12.1).
As in Section 6.3 the variables are subdivided into Logical, Integer, Real and
Character.
An “examination” option is also provided to check for any current parameter
settings – or combinations of parameter settings – which are likely to create errors
of some description within SATNET. You are not, however, obliged to change
them.
11.9.12 Converting Buffer Nodes to Simulation
11.9.12.1 Basic Principles

An existing buffer node may be re-coded as a simulation node such that the
maximum amount of information is taken from the existing buffer network, e.g. the
numbers of the adjacent nodes, the link distances, one-way links etc, and the
minimum additional data supplied by the user.
The buffer nodes to be converted may be selected either: (a) interactively by the
user or (b), post 10.8, an external file may be input containing a list of all nodes to
be converted and their simulation junction type. File input is described further in
11.9.12.4 below.
Under the interactive mode, the user will first be required to define:
♦ a junction type (priority, signalised, etc.);
♦ whether or not link capacity restraint data is to be added by default (new in

10.5);
♦ banned turns;
♦ the number and layout of lanes;
♦ saturation flows (for roundabout arms)
♦ basic stage definitions (signals only)

Once this minimal data is provided further node editing, following standard node
graphics procedures as covered in 11.9.3, may optionally be applied in order to
define, e.g. priority markers, etc.
Note that default values for all the above node properties are set by the program
and, if unchanged, will appear in the output .dat file in the correct positions in the
data records. However it needs to be stressed that the default values are only
“intelligent guesses” at best, e.g. saturation flows are set equal to buffer link
capacities and are probably therefore underestimates. Users are strongly advised
to cross check these values and edit as necessary.
In particular adding link capacity restraint data – which basically reproduces the
buffer link’s speed-flow curve – is seen as a “quick and dirty” technique. It may
5120257 / Apr 15 11-72

Section 11
lead to a “double counting” and over-estimation of delays if the buffer speed-flow

curve (correctly) took into account junction delays and further junction delays are
introduced by the coding of the new simulation junction. If this option is used it
may be best to initially code the junction as a priority junction with all arms as
“major” arms so that there will be no junction delays (apart from over-capacity
queues). Using dummy nodes in this situation is not recommended. When the
junction is “properly” coded the link capacity restraint curves should be removed.
At the conclusion of all editing a correctly coded node description will be
incorporated into the internal network direct access file for subsequent dumping
as an external .dat file (11.9.2) (N.B. This is not automatic, it must be requested
as “save this data”.)
This option works by adding the converted buffer node as an “extra” temporary
simulation node at the end of the normal simulation arrays. It may therefore not
be available if the simulation network dimensions are only marginally less than the
maximum provided by your program version. See 15.28. It is not possible to add
new simulation node data into an output .ufs file.
Those buffer nodes which have been converted may be identified on network
plots in that they are assigned a different node type colour from normal buffer
nodes. Thus the node display should have the options for, say, node shapes and
multiple colours turned on.
11.9.12.2 Extra Centroid Connectors

If the buffer node converted to simulation is connected to zones which are not
already connected to simulation nodes (NB: this should be the case since
simulation and buffer connections from the same zone do not “mix well”.) then
extra simulation centroid connector entries for that zone(s) are automatically
created within the 2222 data record segment of the new .dat file. These will be of
the format described under note 4 in section 6.5 where the buffer node is entered
as both A - and B - node.
Note that the new connectors appear only within the .dat file; no changes are
applied to the current map structure arrays which will display the zone and
centroid connectors as though they are still buffer connections, nor are they
deleted from the 33333 data segment. (The latter is not necessary since, once
they appear under the 22222 records, SATNET will ignore any entries from that
zone under the 33333 records.)
11.9.12.3 Extra Node Conversion

It is possible as a result of converting one buffer nodes into a simulation node that
its adjacent nodes will also need to be modified. This works in two ways.
Firstly, if the converted buffer node B is totally “isolated” from any other simulation
nodes than all the buffer nodes which are connected to B must also become
external simulation nodes, in addition to being buffer nodes. However this does
not mean that they needed to be coded within the 11111 records since if the
parameter AUTOX = T (see 15.12) then they will be automatically recognized as
external nodes by SATNET. It is therefore assumed that AUTOX will be T and no
extra entries are added under 11111.
5120257 / Apr 15 11-73

Section 11
Secondly, however, if one of the buffer nodes A connected to the new node B is
already an external simulation node, e.g. if A has another neighbour C which is an
internal simulation node as sketched below, and A has no other connections.
Then leaving A as an external simulation node leads to fatal errors in the
assignment network (see 18.8). Under these circumstances A is automatically
converted into a priority node and either added to the 11111 data records or
suitably modified if it already exists there.
11.9.12.4 Buffer Node Conversion from File Input

The set of buffer nodes which are to be converted may also be specified from an
input text file which contains, one record per node, the number (i.e., “name”) of the
buffer node to be converted plus the junction type (e.g., 1 for priority) into which it
is to be converted. The format is free format; i.e., the two entries may be in any
columns as long as they are separated by either a space or a comma.
This option may usefully be combined with the data field editing procedures
11.9.13 Global Changes to Signals

These options allow changes to be made and saved to all signals as opposed to
changes to individual junctions as under 11.9.3. Options include:
♦ stage time optimisation,
♦ offset optimisation,
♦ re-simulation (following either stage or offset optimisation),
♦ “import/export” of signal timings via .rgs files (i.e., from another network)
♦ direct updates of all stage times and offsets on the .dat file.
These are described in the following sub-sections and in 11.9.14 (.rgs files).
Note that the “stand-alone” procedure SIGOPT described in Section 15.31.6 uses
the P1X options as described below but in a “batch format”.
11.9.13.1 Signal Optimisation

Signal optimization includes:
♦ optimising green splits (stage times)
♦ optimising the offsets

at either all simulation nodes or at a selected subset (see 11.9.13.2) as opposed
to optimising a single set of signals via node editing. Either or both may be
selected in the above order.
Note that a further option then allows for a full network re-simulation since that
may in turn affect the signal optimisation and an iterative loop between
5120257 / Apr 15 11-74

Section 11
optimisation and simulation may be followed manually which, empirically, appears

to converge reasonably quickly. Note that this is not the same as allowing for a
full re-assignment (plus simulation) of traffic (see 15.31.1) where the feedback
effects may be more severe.
The green-split option follows that described in Section 15.31.2 to calculate and
save optimum green times for every green stage at every signalised node. The
new times are automatically recorded within the internal .dat file (and saved
externally if requested) and will be included within an output .ufs file.
The offset option follows the SATOFF procedures described in 12.2. Note that
the re-simulation loop described above essentially follows the “inner loop” of
Figure 12.2.
11.9.13.2 Signal Optimisation at Selected Nodes

A further option within both green splits and offsets permits optimisation to only be
carried out for selected nodes where the procedures for selecting nodes within
SATDB are described in 11.10.5. Alternatively – and probably very useful in this
context – one could select a subset of nodes by using the cordon procedures
(11.13.3). Thus in very large networks one could mimic the affect of a locally
optimised set of signals.
11.9.13.3 Signal .dat File Updates

Since signal stage times and/or offsets may be updated elsewhere within
SATURN other than P1X, for example, offsets in SATOFF (see 12.2.2) or stage
times and/or offsets in SATALL, but only saved within network .ufs files it is useful
to be able to transfer the new data from a .ufs file into an updated .dat file. The
“update” option simply transfers all current stage times and offsets as read in from
a .ufs file onto the (internal) .dat file, from which they may be later dumped into an
external .dat file. See also 15.31.5.
Note that the same basic operation may also be accomplished by “dumping” a full
.dat file (see 11.4.2) from a .ufs file but the Update operation above is to be
strongly recommended since it preserves the full data structure of the original .dat
file with the sole exception of the stage times and offsets.
A further alternative method to transfer updated signal settings is to make use of
the .rgs files by (a) dumping the settings to a .rgs file from P1X network editing
and then (b) transferring the .rgs file data to any other network. This method is to
be preferred if it is necessary to transfer the same set of optimised signals to more
than one network.
11.9.14 Signal Transplants: .rgs files

Signal settings, i.e., cycle times, green splits, offsets, etc., may be transferred from
one network to another via “.rgs” files. Thus a file with extension .rgs is firstly
created by “dumping” all the relevant signal setting data from a particular network
- in effect it extracts all the relevant data records from its .dat file. This may either
be done either as (a) a “files output” option within P1X (11.9.2), (b) at the network
build stage within SATNET by setting FREDDY = .TRUE. under &PARAM (see
6.3.1 and 6.4.3.5) or (c) using the batch procedure SIGOPT (15.31.6).
5120257 / Apr 15 11-75

Section 11
Once created a .rgs file may be read either by P1X and its signal settings used to
replace those in the current network or (post 11.3.11) by SATNET, in which case
the timings on the .rgs file replace those read in from the network .dat file (see
6.4.3.5). (In a sense a .rgs file is a bit like a $INCLUDE file in that it includes a
specific sub-set of network data.)
Thus, if you have, say, an AM and a PM network which differ only in terms of their
signal settings and you edit the link data in the AM network it is normal to wish to
transfer those same changes into the PM network but retaining the PM signal
timings. This can be accomplished by simply copying the “new” AM network file
into a “new” PM network file, processing the new PM network through SATNET
and then using the signal transplant option within P1X to copy over the signal
settings from the “old” PM network and to create a new output .dat file for the PM
network.
Or, more simply post release 11.3.11, the “new/revised” PM network .dat file as
copied from the AM file may contain the namelist parameter FILRGS which
specifies the old PM signal timings and those timings will be retained with the new
network structure.
Note that transplanting is only possible if the nodes have the same topology in
both networks. Thus if a node has been re-coded from a 3-arm signalised junction
into a 4-arm the old signal data will no longer be applicable and in this case the
changes will probably best be done “manually”.
The format of .rgs files has been changed in version 10.5 such that the cycle time,
in addition to the offset, is also stored per node. Older versions of .rgs files may
also be read by 10.5 but the converse is not true; i.e., a 10.5 .rgs file cannot be
read by the 10.4 version of P1X.
11.9.15 Comparing Two Networks

The simulation nodes as coded in two networks may be compared data item by
data item and all points of differences established. For example if a node is
identically coded in networks A and B apart from having a different offset in
network B this difference will be detected and the information listed in a table of
differences.
Differences may exist at different “levels”. Thus at the highest level a node in
network A may not exist in network B, in which case clearly it is not possible to
detect any further differences. Lower levels include node data, link data, turn data
and signal data - corresponding roughly to record types 1, 2 and 3 in the
simulation node data formats (6.4.1).
Differences at one level may preclude checking for differences at another level.
For example, if a node exists in both networks but has a different number of arms
it is still feasible to check for differences (such as the offset) on the “node record”
but not for differences between turns.

Screen editing in this context allows the user to transfer data directly from the
internal .dat file (by specifying the first line and number of lines) into a standard
5120257 / Apr 15 11-76

Section 11
Windows edit box where it may be edited as desired and, if saved, replace the
existing data.
Note that the editing here is only applied to the .dat file and is NOT processed by
the program itself. For example, if you add an extra line within the 333 data
records to add an extra buffer link that link will not appear on the plot or be
accessible to buffer link editing. However, by rebuilding the .dat file into a .ufn file
(see 11.9.2) the changes will then be incorporated into the network as viewed on
the screen and indeed screen editing in this context is most usefully applied in
conjunction with rebuilding.
We may further note here a distinction between screen editing the .dat file as a
whole and screen editing individual lines (or collection of lines) as may generally
be done within the specific data editing routines described in Section 11.9.2 to
11.9.10. Thus if you screen edit, e.g., the subset of link counts these are read by
the program and included within its internal “memory”.
11.9.17 Editing “Data Fields” via ASCII Text Files and/or Internal Data Base Columns

With release 10.8 an extra option has been added whereby data for one particular
“data field”, e.g., the distance per simulation link as recorded within the 11111
data section, may be set “en masse” for any or all simulation links. This differs
from the normal editing of simulation nodes whereby any individual data item
associated with an individual node may be edited; this facility enables one to edit
a single data “field”, e.g., link distance as above, over all simulation nodes. In
effect the editing is “vertical” rather than “horizontal”.
11.9.17.2 Input Data Formats

The data to be added may be defined in one of three formats:
1) from an external ascii file or
2) from an internal data base column, or
3) as a single fixed “universal” value.
In case (1), for example, the input file might consist of a number of records of the
form “A B Distance” so that the value of “Distance” for simulation link A,B would
be recorded in the proper location on the link data record A,B under 11111. This
facility enables data to be transferred en masse from, e.g., external GIS data
bases into SATURN .dat files with minimal user intervention.
In case (2) the data would be created by manipulation using the standard SATDB
options before it is ready for transfer. For example, to change the cruise speed for
all simulation links with, say, capacity index 5 to 44 kph one would create a new
data column with a global value of 44, then do a link selection by simulation link
AND index 5 and finally transfer that data column into the simulation link field
“time”.
Case (3) might be used, for example, to set the speed on all simulation links (or a
selected subset) to a fixed value, say 45 kph. This method is therefore simpler
than having to set an extra list of all desired links with the attribute 45.
5120257 / Apr 15 11-77

Section 11
Alternatively, the data may be created by a combination of methods (1) and (2)
whereby “raw” data is read into the internal data base and then manipulated
internally before it is added to the internal .dat file. See below for an example of
how to create turn saturation flows in this way.
The input data files may refer to either simulation nodes, links or turns and their
format must reflect the differences. Thus a node data file would be of the form “N
data1 data2 …” where N is a simulation node number, link data would be of the
form “A B data1 …” and turn data “A B C data …”. In all cases the “data” may
contain several different fields (e.g., link distance, link speed, etc. etc.) and the
user must then define each individual data item in the list.
Similarly node data must be transferred from the SATDB node data base
(11.10.5) but both link and turn data are accessed from the link data base.
11.9.17.3 Data Restrictions

If desired the changes may only be applied to a subset of nodes, links, etc. by
using the standard link or node selection rules within SATDB. This is particularly
useful with the global option, case (3) above, if the single value is not intended to
be applied to be all nodes, etc.
At the present time “data field editing” applies only to 11111 simulation data, e.g.,
not to 33333 buffer data, etc. etc. although it is planned to extend its range of
application in the future.
11.9.17.4 Available Data Fields

For simulation nodes (whether input is from an external or an internal file) the
following data fields may be updated:
♦ Junction type (integer 0 to 5)
♦ Roundabout circle time (seconds)
♦ Roundabout circulating capacity (pcu/hr)
♦ Signal offset (integer seconds)
♦ Cycle time (LCY) (integer seconds)
♦ Number of time units (NUC) (integer)
♦ GAP – Minimum gap at priority junctions and/or roundabouts (In “real” units of
seconds, not integer tenths of seconds as per normal .dat files)
♦ GAPM – Minimum gap for merges (ditto re units)

Similarly under link editing the following fields may be updated:
♦ Link distance (metres)
♦ Link cruise time (seconds)
♦ Link cruise speed (kph)
5120257 / Apr 15 11-78

Section 11
♦ Number of lanes
♦ Stacking capacity (pcus)
♦ Capacity Index (as stored on the second link record unlike the first five which
are all on the “main” link record)
For turns the available data fields include:
♦ Saturation flow (pcus/hr)
♦ Turn priority marker (Integer 1 – 12 where 1 = blank, 5 = X (Priority), 6 = F, 7

= X (Signals), 8 = G, 9 = M, 10 = Q, 11/12 = W)
♦ Inside lane (Integer 1 - 7)
♦ Outside lane (Integer 1 – 7)

Note that with some input data fields additional data items within the .dat records
may be updated. For example, if one inputs link lanes and the number of lanes on
a particular link is increased then the last lane entries for each turn on that link are
also increased if appropriate. Equally turn saturation flows are factored to match
any changes in lanes.
11.9.17.5 Discussion
Note that there are strong similarities within the use of X-Files to input data
directly under SATNET and indeed the same files might be used in either context;
see Section 6.13.
11.10 SATDB: Data Base Facilities
11.10.1 Introduction
The program SATDB brings together many elements of statistical analysis
packages, file editing systems, spread sheets and data bases in ways which are
particularly convenient for the specific task of analysing road networks.
Nowadays it may perhaps be best thought of as a poor man’s version of EXCEL!
The functions within SATDB may be accessed by either running SATDB as a self-
contained program or as a sub-program within P1X. The former is useful for
operations that do not require any graphical network plots or for jobs which are
being run in an essentially batch or off-line mode. When run within P1X there is a
certain overlap of functions; for example select link analysis can be done either
within P1X or SATDB, the main difference being the way in which the choices are
made.
At the heart of SATDB (and, equally, P1X) is the concept of an “internal data
base” which may be thought of as a matrix of rows and columns as illustrated
below:
(link) A B C D1 D2 D3 ...
1 a1 b1 d11 d12
2 a2 b2 c2 d21 d22
5120257 / Apr 15 11-79

Section 11
...
L
In the case of the “link” data base (as distinguished from the node data base, see
11.10.5) each row corresponds to an “assignment link”, the most basic level of
network definition within SATURN (see 5.5.1). These in turn may be sub-divided
into: simulation links (often referred to as “roads” to distinguish them from links
which correspond to the missing direction of a one-way road:), buffer links,
simulation turns and centroid connectors in both the buffer and simulation
networks. Thus “L”, the total number of rows, represents the total number of
assignment links.
The three “fixed” columns denoted A, B and C above identify links by node
numbers where C is only used in the case of a turn, or for a simulation centroid
connector where the zone is connected to a link. The letter C in front of a number
distinguishes a zone from a “real” node. (See 11.10.4 for more precise
definitions.)
The remaining data columns D1, D2, etc. are created by the user either by
reading directly from the input .uf* file(s) or by a wide range of alternative options.
For example data column D1 might represent link flows and D2, link times. Hence
entry d 11 would be the flow on link 1, d 12 the time on link 1 etc. A third data
column to represent, say, veh-hrs could be created as the product of columns 1
and 2.
By default the links are ordered such that all centroid connectors come first
followed by simulation links (plus turns) and buffer links. However the order may
be changed such that, for example if one data column contains flows the display is
ordered such that the link(s) with the maximum flow appear at the head of the
display.
Once created the data base may be viewed either interactively from the terminal
screen or “dumped” to an external file. In addition a number of very important
options are provided to select the lines that are displayed, for example you can
choose to look only at data from links whose V/C ratio exceeds 1.1, or only at
simulation turns, etc. etc.
Data is displayed either in an integer format - no decimal - or a “real” format - 2
figures after the decimal. In addition certain data values may be “missing” in
which case they are displayed by an “m”; for example a data field which refers,
say, to simulation turn saturation flows would yield missing values for centroid
connectors. If desired, lines which contain all missing values may be suppressed
in the listings; See 11.10.11.
The basic idea therefore is to give the user complete control over what data is
displayed and the manner in which it is displayed.
An extension to the link-based data described above, introduced in SATURN 9.4,
has been to add an alternative node-based data base in which each row
corresponds to a junction (including zones) and the data columns consist of node
data, for example average delay. In this case the first three “fixed” columns A, B
and C may be reduced to just one, the node or zone number. The subsequent
5120257 / Apr 15 11-80

Section 11
options available to the node data base closely parallel those available to links.
Section 11.10.5 gives further details.
11.10.2 SATDB Options

To illustrate the available options within SATDB let us look at the options available
from the Master Menu (recognising of course that many more options become
available in turn within the various sub-menus). Further documentation is
contained in the sub-sections.
1) FILES MENU
This option allows the definition and replacement of (up to 4) input files as
well as printing out basic file parameters (numbers of nodes, etc.). Note that if
the input files have different topologies then links in networks 2 to 4 are
“matched” to those in network 1 with the same Anode – Bnode so that data
from the same link in multiple networks appears in the same record.
Conversely, if a link in networks 2 to 4 is “unmatched” data for the link cannot
be stored in the data base. See also 11.4.1 and 11.6.2.3.
2) ENTER THE LINK SELECTION PROCEDURE
Link selection allows you to control the data that is printed. For example, you
can select only links whose flows exceed 2,000 vph, only simulation turns,
etc., etc. Note that selections made under SATDB apply equally to P1X and
vice-versa; see 11.6.1.
3) CANCEL THE CURRENT LINK SELECTION (I.E., INCLUDE ALL LINKS)
Display all links from now on.
4) READ LINK BASED DATA FROM THE UF FILE(S)
Read data from the input network file(s) which relates to the properties of
“links” (e.g., flows, times, queues, etc.) directly into data columns in the data
base based on DA codes (15.21). The analogous operations under P1X are
described in 11.6.2. Data created by SATDB from within P1X are
automatically displayed.
If the input data is based on a sub-set of the full set of assignment links (e.g.,
simulation link or simulation turn data) then the non-defined links are, by
default, assigned a “missing value” or, alternatively, default values such as
zero may be assigned.
In addition (post 10.8), the input link sub-set may be automatically included
within the “link selection rules”.
5) READ NODE BASED DATA FROM THE UF FILE(S)
Read data from the input network file(s) which relates to the properties of
“nodes” as opposed to “links”, e.g., the cycle time at traffic signals. For a link
A to B the data entry may optionally refer to the property of either node A or
B.
6) READ MISCELLANEOUS DATA INPUT (11.10.6)
5120257 / Apr 15 11-81

Section 11
The “Special Menu” offers a range of functions for inputting new data columns
from either uf* or other files, including:
♦ Link counts;
♦ Links on bus routes;
♦ Restricted links (i.e., banned or penalised movements);
♦ Alpha-numeric link names (from a GIS file);
♦ Data read from an external ASCII (.txt) data file.
♦ (XY,Y) co-ordinates for each link’s A- and B- node.
♦ Link costs by iteration as read from a .ufc file (see 15.23).
♦ “Unpacked” link or turn data, e.g., lane allocations
♦ Bus lane flows

7) ASSIGNMENT/TREE BUILDING OPTIONS (11.10.7)
These include:
♦ Trees and/or forests for selected O-D pairs; (see also 11.8.3)
♦ All-or-nothing assignment;
♦ Full multiple route re-assignments;
♦ Select link assignment. (See also 11.8.1);
♦ “One song to the tune of another”.

8) CREATE NEW DATA COLUMNS FROM EXISTING COLUMNS (11.10.8)
This option allows the user to create new data columns, either via an algebraic
expression involving existing data columns or by invoking the time-flow curves
within SATURN to calculate the link times corresponding to flows in an existing
column.
For example to create a new data column which is the sum of, say, columns 1
and 2 the user would type in:
X1 + X2
Very similar procedures are available to create and manipulate new matrices
as described in 10.8.1.
Further options allow data to be “reversed” in the sense that the data for link
A-B appears for link B-A. This in turn allows, for example, the calculation of
two-way link flows from one-way.
9) EXTERNAL DIRECT INPUT AND/OR EDITING
Essentially an indirect method to “screen edit” the existing data. The user
“dumps” the entire internal data base to a scratch file, temporarily exits from
5120257 / Apr 15 11-82

Section 11
SATDB in order to use a local edit program to change the scratch file, and
then re-enters SATDB in order to re-read the file and replace the old data
base. (But see Option 15 below.)
10) STATISTICAL ANALYSIS
Two forms of analysis are available: either a univariate analysis of a single
data column (mean, standard deviation, etc) or a comparison of two columns
(mean difference, etc.) Output is normally numerical but graphical options are
available (e.g. scatter plots).
N.B. The statistical facilities within SATURN are essentially BASIC, e.g. to
calculate the mean difference between modelled flows and counts. If you
want to do more complex statistical operations such as analysis of variance
you are advised to use SATDB to gather together the data you require and
then dump them to an external file for transfer to SPSS or EXCEL for
example.
11) REMOVE ONE (OR ALL) DATA COLUMNS
To reduce the size of the data base: useful, for example, since only a
maximum of six columns may be printed at once.
12) PRINT THE FULL DATA BASE ON THE LINE PRINTER
Spools the full (selected) set of link data records to the LPD file with suitable
column headers and pagination.
13) DUMP THE FULL DATA BASE TO AN ASCII FILE (11.10.9)
Spools the full (selected) set of link data records to an ASCII file. These
outputs differ from those under 12 in that they do not contain column headers
or pagination. These files, edited if desired, may be read back into SATDB
under option 6.
14) BASIC HOUSEKEEPING OF DATA BASE HEADER RECORDS (See
11.10.10)
Each data column has an alpha-numeric title associated with it; these may be
modified as desired. Equally display formats, whether to print/plot or not etc.
may be modified.
15) DISPLAY/EDIT THE DATA BASE ON SCREEN (11.10.11)
This option enters an “edit-like” environment whereby the user may “browse”
through the internal data base with a “window” equal to the terminal screen
which may be moved up or down through the data base. The order of printing
may also be changed so that, for example, it is “sorted” according to one
column.
A “screen-edit” environment is also provided such that the values stored in
the data base may be altered on screen. To a large extent this renders option
9 above obsolete (except, for example, if multiple edits are to be performed).
16) CREATE A NEW SATURN UF FILE (See 11.10.12)
5120257 / Apr 15 11-83

Section 11
Having created new data columns within the internal data base you may
preserve this data in a new .ufs file.
17) SATURN GENERAL PARAMETERS MENU
This contains parameters such as the number of lines on the terminal screen
and which do not fit conveniently anywhere else.
18) ENTER THE NODE-BASED DATA BASE (11.10.5)
Or, if you are currently within the node data base, option 18 returns you to the
link data base.
11.10.3 Hints for Using SATDB

We give here a series of brief “hints” for various uses of SATDB which may not be
immediately obvious to new users. Note that all of these are not only available in
SATDB as a free-standing program but also within P1X invoking SATDB as a
sub-module. In addition a number of SATDB-based options are described in
greater depth elsewhere in the documentation; see 15.37.
1) SATDB allows you to create “new” data arrays from the basic data stored on
the input UF file(s). For example, UF files contain link time and distance but
not speed. You may use SATDB to work out link speeds (option 8) and then
“dump” them as part of an “extended” UF file created by the program (option
16). Thus you may set up “customised” UF files to contain special pieces of
data that you need but are not “standard”. See 11.10.12.
2) Furthermore you may make use of the “KEY” options within the standard
SATDB procedure (see Section 14.5) to make the process fully automatic;
i.e., at the end of every SATURN run you would run a standard SATDB
“macro” to create your own extra data arrays.
3) SATDB may also be used in a wide variety of ways to carry out non-
standard modelling steps. For example it has been used to introduce road
user charges into SATURN by taking an output .ufn file from SATNET and
adding user-defined charges (converted to equivalent generalised seconds)
to the relevant DA cost records before running SATALL. Equally SATDB
may be used as a “post processor” to analyse, e.g., total revenue from the
charges. The SATURN .bat files can be modified to make processes such
as the above fully automatic.
4) Note that when internal SATDB data columns are “dumped” to a UF file then
any missing values (11.10.1) are essentially undefined and must be given a
user-defined default numerical value. Two values in particular are
appropriate: 0 for obvious reasons and -9876 since that value is interpreted
by programs such as P1X to which the new data may be passed as missing
values. Thus if you create a new data array containing counts, say, it is
clearly important that P1X can differentiate between “real” counts and
“default” values; the convention of using -9876 satisfies this requirement.
Generally speaking missing values and/or - 9876 are handled automatically
by the program and the user will be blissfully unaware of them. However in
certain circumstances they may surface unannounced.
5120257 / Apr 15 11-84

Section 11
5) One of the “create new data column” options allows you to “transfer” data
either from a link to its exit turns or from all turns to a link, e.g., to aggregate
turn data and to store it as link data. Thus one could aggregate primary
stops per turn to produce total primary stops per link, or divide link flow
between its turns. This opens up a range of operations which previously
could only be done by “programming”. See also 11.10.8.
6) SATDB provides the main mechanism within SATURN for the transfer of
network data to and from other suites of programs. Thus option 13 creates
selected data files in standard ASCII format which may be accessed by
other suites, while option 6 permits data input to SATURN. “Other suites”
could encompass not only the obvious example of other transport models
but also GIS models, pollutant dispersion models, etc. See also 11.10.9.
11.10.4 Interpreting SATDB Link Listings

The output listings from SATDB specifying the individual link or turn information in
the first three data columns employ certain conventions which may not be
immediately obvious. Similar listings occur in the output SATNET .lpn files. The
following table illustrates a number of “typical” representations. (The numbers on
the left are included for reference only.)
SIM A / BUF B NODES C
1. C 1 58 ( 1)
2. C 20 ( 48 ) 47
3. C 20 ( 47 ) 48
4. C 20 ( 52 ) 31
5. 27 ( 28 ) C 24
6. 58 1 26
7. 1 58
8. 2 3
9. 6 C 23
Link 1 corresponds to a centroid connector from zone 1 (C for centroid) to

simulation link 58 to 1 with the traffic appearing at node 58. Here the second 1 is
in brackets since its main purpose is to define the direction of the link. In this
case, since the traffic appears at the UPPER end of the link, that link must be an
external link and node 58 must be an external simulation node. Note that both a
zone and a node have the same numerical “name”, 1.
By contrast link 2 is also a centroid connector into the simulation network but in
this case traffic joins link 48-47 at the node downstream 47 end; this therefore is
an example of a centroid connector to an internal simulation link. Link 3 is
connected to the same “street” but in the opposite direction, so that traffic enters
at node 48. Link 4 is another internal centroid connector in the simulation
network, from the same zone as link 3 but to a different simulation link.
Finally link 5 is an example of a centroid connector going OUT of the simulation
network; in this case it represents traffic leaving internal link 27-28 to zone 24.
Again 28 is in brackets to indicate the direction of the link since the actual point of
departure is assumed to be at node 27.
If you are still confused the diagrams in Section 16.6 may help!
5120257 / Apr 15 11-85

Section 11
Link 6 corresponds to the turn 58 to 1 to 26 in the simulation network whereas link

7 is the road from 1 to 58 in the simulation network.
Finally link 8 is the link in the buffer network from node 2 to 3 while link 9 is a
centroid connector in the buffer network from node 6 to zone 23.
11.10.5 The SATDB Node Data Base

The node data base within SATDB operates in very much the same fashion as
the link data base with the obvious difference that each row in the data base
corresponds to a node (or zone) and the data columns contain data related to that
node, for example the average delay at that node, total in-bound flow etc. For
obvious reasons the first three standard columns are reduced to a single column
containing the node/zone name.
Technically the set of nodes in the node data base consists of the nodes
represented in the map network, i.e. zones, simulation nodes (all types) and buffer
nodes. Thus simulation nodes are single entries, not “expanded” as in the
assignment network.
Otherwise most of the standard options available to the link data base are
available to the node data base. For example, you may create new data columns
via FORTRAN-style equations on existing columns, carry out basic statistical
analysis, select a sub-set of nodes, etc. One exception is that there are no
assignment-based options since their outputs are essentially link-based.
Note that node selection may also be carried out within the cordoning options
(11.13.3) or by direct input from ASCII data files containing a list of the nodes
and/or zones to be selected.
Data input from one or more network files is by selection from a list of named
parameters (delay, flow etc) rather than via DA codes as is the norm with link
data. Appendix I.3 gives the full list. A much greater range of data parameters
apply to simulation as opposed to buffer nodes, given the extra data both input
and modelled at simulation-nodes. Data for zones is even more limited.
Alternatively, as with the link data-base columns, data may be read from external
Ascii files (under Miscellaneous Data Input in the node master menu).
It is also possible to create node data arrays by aggregating data from the link
data base. For example if you have created a link array of, say, select link
analysis flows, you may create an array in the node data base which adds
together all the link flow entering each node. A choice can be made on to whether
link data for link (A, B) is aggregated at node A or node B; turn data for A-B-C is
always aggregated at node B. See 11.10.8.4.
There are close connections between the creation and manipulation of data within
the SATDB node data base and their display or annotation within P1X (see
11.6.5), in that data created within SATDB may be annotated within P1X. The
system of node selection (11.6.6.3) is common between the two.
5120257 / Apr 15 11-86

Section 11
11.10.6 Miscellaneous Data Inputs within SATDB

The following options provide various methods for reading “non-standard” link-
based data from the input network file(s) (as opposed to the standard inputs under
option 4) as well as from SATURN GIS files and external data files.
The data read will generally be numerical but in 2 cases below, bus routes and
link names, the data is alphanumeric text. A restricted set of miscellaneous data
inputs is also available within the node data base (11.10.5).
11.10.6.1 Link Counts

The link counts input are those defined on the 77777 network data records (6.10).
In the event of multiple count fields (MCCS>1) then one or all may be input. If
more than one 77777 data set was included one count set or all count sets may
be included. Links for which no counts have been defined are assigned “missing
values”.
11.10.6.2 (Bus) Routes (Alphanumeric)

The user is prompted to choose one route from those coded on the 66666
network data records (6.9); the corresponding route name (N.B. a 4-character
alphanumeric variable, not an integer number) is entered in the next DB column
for all links in the route. All other links are assigned missing values.
No distinction is made here between whether the route is a bus route or not (as
determined by its coded frequency; 6.9.2).
11.10.6.3 Restricted Links

This option yields the coded link penalty and/or ban data from the 44444 network
data records (6.7) plus the equivalent negative values for bus-only roads or turns
as read from the simulation node data records.
11.10.6.4 Link Names (Alphanumeric)

This option reads the alphanumeric street names as recorded on the network GIS
file (see Appendix Z) for either simulation or buffer links. All other links/turns are
assigned missing values.
11.10.6.5 External ASCII (.txt) Data Files

This option provides the best mechanism within SATURN for importing external
link data sets, e.g., from another suite of programs or - see 11.10.9 - re-importing
SATURN data which has in some way been edited externally. The data in
question is read from an external ASCII (text) file defined by the user, each record
of which identifies an “assignment link” (e.g. road, turn, centroid connector etc;
see 5.5.1) followed by one or more (numerical) data items to be added to new
columns in the data base.
Thus each record consists of two “parts”:
(i) Link identifiers
(ii) One or more data values
5120257 / Apr 15 11-87

Section 11
with the format for each specified independently.

Optionally part (a), the link identifier, may be dropped so that the file contains only
data, in which case the line number is assumed to equal the correct assignment
link number. This option should be used with some care and almost certainly only
when the data file has been generated by a SATURN program.
Following traditional SATURN conventions, the link identifier may consist of either
2 or 3 (for turns) node numbers in fixed columns plus C’s to identify zones as
explained in 11.10.4, See 11.18.2 for the precise format.
The link data that follows is read in “free format” (although it may of course be in
fixed column blocks as long as each data block is separated from its neighbours
by either a blank or a column). Link data under free format may be either integer
(no decimals) or real (explicit decimal points).
However the node information may also be read as “free format” where each item
is separated from its neighbours by either a blank or a comma (“comma
separated” CSV). Note that if the nodes are in free format the records must either
contain only links (2 nodes) or only turns (3 nodes) and that must be pre-specified
by the user. (Otherwise the program will not know whether the third entry
represents the C-node of a turn or the first data item). In addition centroid
connectors cannot be identified under free format (at the moment) since a
character C (or Z) cannot be recognized).
Links which are not included within the input data file are either assigned default
data values (e.g. zero) or identified as “missing entries” (see 11.10.1).
Note as well that this option may be used in conjunction with the main menu
option 13 (dump to an ASCII file) to transfer data from SATURN into a file which
may be edited externally and then re-input into SATDB. See 11.10.9.
11.10.6.6 X, Y Co-ordinates
X, Y co-ordinates are read from the input network UF file as originally defined
under the 55555 data records input to SATNET (see 6.8). For all “pure” links in
the SATDB data base (i.e. excluding turns) four columns are created containing
the X co-ordinate of the A-node (first node), the Y co-ordinate of A followed by X
and Y for the B-node.
This option is very useful if one wishes to transfer SATURN data to a GIS system
such as ARC-INFO where the node numbers as used in SATURN have no
significance, but the coordinates do. In these cases the “real” data to be
transferred e.g. flows, is added to extra data columns and the whole data base is
dumped to an external ASCII file (11.10.9).
11.10.6.7 Link Costs by Iteration

These costs are those used by each assignment iteration and saved on the
network .ufc file if SAVEIT = T. See 15.23.
11.10.6.8 (Un) Packed Link and Turn Data

In order to save RAM and reduce the size of UF* files certain integer properties of
simulation links and turns, for example the number of lanes, markers to indicate
5120257 / Apr 15 11-88

Section 11
bus-only roads, etc, are stored as “packed” variables with 5 or 6 within the same
DA array. The packed values appear meaningless; these two options allow
individual data items to be “unpacked” and entered in individual DB columns.
The full list of items (per turn) which may be unpacked includes:
♦ Priority markers (numerical or characters)
♦ Priority modifiers (numerical or characters)
♦ Shared lane indicators
♦ Bus lane indicators
♦ Nearside, offside and total number of lanes
♦ Number of green stages
♦ Junction type (e.g., 3 for signals, etc.)
♦ Saturation flow with a negative sign to indicate bus-only (as used in data input
conventions; 6.4.4)
and per link:
♦ Distance
♦ A link capacity restraint marker (0 or 1)
♦ A bus-only road marker (0 or 1)
♦ A lane-mixing marker (0 or 1)
♦ Major/minor (1/0)
♦ Total number of lanes
♦ Number of near/offside flared lanes
♦ Number of bus lanes: total, nearside or offside
♦ Number of lanes to include a negative sign for bus-only lanes (as used in data
input conventions; 6.4.4)
♦ Merge indicators
♦ Junction type of the downstream or upstream nodes
11.10.6.9 Bus (Lane) Flows

Bus flows in the simulation network may be selected from (up to) 15 sets of
disaggregated definitions. Thus at one level we distinguish bus flows:
♦ in nearside bus lanes;
♦ in offside bus lanes, and
5120257 / Apr 15 11-89

Section 11
♦ mixed with normal traffic.

Furthermore we may distinguish buses that enter or leave the network at the
upstream end of the link for all three “lane” classifications above, ditto entering or
leaving at the downstream end, and finally traffic on the link itself.
Note that of these only one set - bus flows on the link mixed with normal traffic - is
available elsewhere, either as the bus flow on its own or as a component within
total fixed flows or total (demand) flow.
Further note that all these flows are defined in units of pcu/hr, (not buses per hour)
and are demand flows, not actual.
11.10.7 Re-assignment and Tree Building Options in SATDB

The re-assignment and tree building options within SATDB offer the following
basic facilities. Note that many of these same operations may be done elsewhere
in P1X, mainly under the Analysis options (11.8.3), the main difference being the
methods used to specify the operations and the display.
A common feature of the following options which involve assigning a trip matrix is
that: (1) the matrix used need not be the original trip matrix file; (2) it may be
multiplied by random factors (a useful option to simulate day-to-day variability,
probably more an academic concern).
11.10.7.1 A Single Tree

A “TREE” refers to the set of shortest routes from one origin to one (or all)
nodes/zones in a network; see 15.26. The user must specify the origin zone
(/node - see below), the destination zone (if a single O-D route is required; else to
all zones/nodes) and the definition of link costs upon which the tree is to be
based. A value of 1.0 is stored in a DB column for all links in the tree, otherwise
0.0.
It is also possible to store DB columns containing the minimum cost from the
origin to (the downstream end of) each link or to “skim” an alternative property,
e.g. distance along a minimum time tree. See 15.27. By definition the minimum
and/or skimmed cost at the origin is always zero.
DESTINATION TREES
Alternatively one may build a single tree into a destination zone, in which case the
tree will consist of the set of all shortest routes from any zone/node in the network
to the nominated destination zone. A destination tree is built only if an origin is not
specified. (If both are specified then the minimum cost O-D route should be the
same whether it is built out of the origin or into the destination; in this case the tree
is always built in an outbound sense.)
STARTING POINT: NODES, LINKS OR ZONES

With 10.8 it is also possible to define the “root” or “origin” and/or “destination” of a
tree not only at a zone (which is the normal practice with traffic assignment
models) but also at a node or at either end of a link. Thus if one selects a buffer
node B then the tree is built outwards from B with the initial cost at the
5120257 / Apr 15 11-90

Section 11
origin/buffer node being set equal to zero. (Or, in the case of destination-based
trees, the tree is built into B.)
If a simulation node N is selected the tree starts with zero cost at any of the
expanded assignment nodes at the upstream ends of the exit simulation links;
e.g., from nodes B 1 ,C 1 etc. in Figure 5.2. For a destination-based tree then the
starting (zero cost) points would be the downstream ends of the entry links, e.g.,
A1, B2, etc. in Figure 5.2.
If a link is chosen then, in effect, routes are allowed to begin/end their journeys at
the end of a specific link rather than at a specific assignment node. If an “origin
link” A-B is chosen then the tree is built starting at (possibly) two assignment
network nodes: the node at the downstream end of A-B and also (if the two-way
option has been selected) at the (downstream) assignment node on B-A. If A-B is
a “destination link” then the tree is built inwards to the upstream ends of A-B
and/or B-A. Note that if A-B is a buffer link the start/end assignment nodes are the
same in both cases (i.e., the nodes at either end of the link) but if A-B is simulation
then the precise starting nodes differ since they are defined as expanded
assignment nodes.
However the starting point(s) are defined, they are always nodes within the
assignment network so there is no difference in the tree-building algorithms used.
LOADING O-D TRIP “VECTORS” ONTO TREES

A further option introduced into 10.8 allows not only a tree to be built (outwards in
the case of origins, inwards in the case of destinations) but also a “vector” of trips
to/from all zones to be loaded “all or nothing” in the reverse direction along the
minimum cost routes. Thus, for an origin, the “vector” is equivalent to a row in an
O-D trip matrix and, for a destination, a column.
Note that the loading can only start at zones, not at nodes or links, although the
“base” of the tree can be either a zone or a node or a link as above. This enables
trips to be loaded to/from points in the network where currently there is no zone
defined, as would be the case (as discussed below) with a new development
which generates/attracts extra trips but is not sited at an existing zone.
In order to invoke this option the “vector” must first be loaded into the SATDB
node data base (11.10.5), i.e., at least one node data column must exist. How this
is done is up to the user; for example they may input using the option to read from
an ascii file which would consist of characters: “C zone trips” (where the C in
column 1 is necessary to identify the number that follows as a zone, not a node).
MODELLING DEVELOPMENT TRAFFIC: DEVTRIPS

The option to “load trees” as described above was originally developed in co-
operation with the Greater Manchester Transportation Unit GMTU as part of their
“DEVTRIPS” procedures for modelling the distribution and routing of traffic
generated by relatively small new developments such as supermarkets. Here
SATDB is called (twice) within a much larger modelling framework.
The objective of DEVTRIPS is to give a very quick estimate of the origins and
destinations of the newly generated traffic and the routes used by drivers
travelling to and from the site, given information about the site’s location within the
5120257 / Apr 15 11-91

Section 11
network and the total number of trips generated by the site. It avoids the need to
add a zone to the network and matrix and, because it assumes that the
development traffic will not significantly affect routing, avoids the need to re-
converge the network – a process that may take several hours given the size of
the Greater Manchester network. The system is designed to be used by those
with little or no modelling expertise to predict, given the creation of a new
“development” (e.g., shopping centre) within a network which will generate a
certain number of new trips to and from the site, where those trips will appear on
the network.
In the first call to SATDB, therefore, the site is used to define the origin for a
single tree build to determine the travel costs from the site to the other the zones
in the network. The procedure is then repeated with a “destination” tree in order to
create a column of costs to the new site. These two sets of costs are then
dumped to an external file which GMTU uses with a catchment area technique to
determine the origin and destination zones of the generated trips, which are then
saved as two columns of data representing the number of trips beginning and
ending in each zone.
In the second call to SATDB the matrix (or columns) of trips generated above is
input to the node database and the tree-build options repeated (twice – both to
and from the site), but this time with the loading option invoked. This will produce
two link data base columns containing the in-bound and out-bound link flows
which may then be added to together to produce the total generated trips per link.
All three flows (or just the totals) may now be dumped as Ascii files and read by
other DEVTRIPS procedures to carry out supplementary analysis of the flows.
Alternatively, the flows can be displayed graphically within P1X by saving the
information in the database as a new UFN/UFS.
11.10.7.2 A Forest of Trees

A “FOREST” is an aggregation of all the trees from a single origin over all internal
assignment iterations, weighted by the fraction of the trip matrix as ultimately
assigned to each iteration. See 15.26.
11.10.7.3 All-or-Nothing Assignment

This option carries out a single all-or-nothing assignment of the trip matrix set next
based on user-set link costs or taken by default to be the generalised costs from
the input network. (N.B. In the case of a network which has been through an
assignment – the normal situation – the costs will be based on congested travel
times. The all-or-nothing assignment created here will therefore (probably) not be
the same as an all-or-nothing assignment carried out within SATALL – see 7.11.3
– which will have used free-flow travel times.)
In addition this option calculates a “delta” or “gap” function value for the
assignment as defined in 7.1.4 and/or 9.2 by comparing the total cost of travel for
the all-or-nothing assignment with that for the previously assigned flows
(correcting for the presence of “fixed” flows such as buses).
In networks with a simulation component the value calculated is more akin to a
gap value (9.2) since the times input to the generalised cost definition are taken
post simulation, whereas with a pure buffer network the measure is the delta value
5120257 / Apr 15 11-92

Section 11
as defined in 7.1.4 since all times/costs are post assignment. In either case of
course the assigned flows have been obtained from the assignment.
With multiple user classes the user may select only one of the user classes at a
time and therefore loop over all of them “manually”; there is not, as yet, an option
to automatically loop over all user classes and/or sum all user classes.
11.10.7.4 Full Multiple Route Re-Assignment (SATRAP)

The SATRAP (SATurn ReAssignment Program) duplicates the original
assignment in that it builds the identical trees at each iteration but the trip matrix to
be assigned need not be the same. See also 15.37 for further suggestions for
use.
Further options allow only “part” of each path to be loaded or only “part” of the
matrix.
The former option may be used to model, e.g. cold starts, by specifying that only
the first 1 kilometre of each path is to be loaded in order to produce a set of link
flows from “cold” vehicles. If a link lies between, say, 970 and 1070 metres from
the origin with a limit of 1,000 m then that link’s flow is factored by 0.3. An
alternative option (“warm running”) assigns beyond the first 1 km.
The latter allows a “sub-rectangle” of the full matrix to be assigned either by
specifying upper and lower zone limits for origins and/or destinations or, post 10.7,
by specifying upper and lower sectors. (More complex “selected” assignments
may be obtained by modifying the actual trip matrix to be assigned, e.g. using
MX).
Note that if, in the extreme, the user specifies a single origin zone and a single
destination zone then the loaded trips effectively constitute a forest (15.26). By the
same token specifying a single sector origin and destination provides a form of
sector-to-sector forest which may sometimes provide very useful information.
11.10.7.5 Select Link Assignment

Select link assignment (SLA) duplicates the original assignment in that it builds
the identical trees at each iteration but the O-D elements are only loaded if their
route goes through certain nodes and/or links. See 11.8.1 for the same functions
specified and displayed graphically (with some extra options) and 15.19 for a
more general description.
If the node-based or “chain” option is selected and a set of nodes A, B, C ...
nominated then an O-D pair is only loaded if its path goes through all nodes A, B,
C ... in that order. For example if A and B define a link then the flows added to the
data base are the flows from only those trips that use AB. Similarly A on its own
defines a node while ABC may define a turn.
Under the “screen line” option O-D pairs are loaded if their route uses ANY one of
the nominated set of links. Typically, but not necessarily, the links form a closed
screen line so that this option picks up all trips crossing that line, the normal use of
the term “screen line”. However any other set of links is allowed, for example a
chain of successive links in order to pick up all trips using all or part of a route or
the set of all links where interviews have been carried out, etc. etc.
5120257 / Apr 15 11-93

Section 11
The “screen line” may be defined in one of two ways: (i) as the set of all currently
selected links (11.6.1) or (ii) as the set of links within a 77777 input segment of the
original network .dat file. If neither of these two options exist the screen line
option is not available.
An essential difference between the “chain” and “screen line” options is that the
chains use an AND test - the route must go through every node - while the screen
lines (under SATDB) use an OR test - only one crossing is sufficient.
Note that the interactive P1X version of Select Link Assignment allows alternative
options for defining screen lines (11.8.1.9) and alternatives to the simple OR test
above for dealing with multiple crossings (11.8.1.10).
With multiple user classes the analysis may be performed for one particular user
class, for each of the n user classes in turn (in which case n new data columns
and/or n new .ufm matrices are created) or for all user classes summed together
(i.e., one new data column, one .ufm matrix).
See also One Song to the Tune of Another in Section 11.10.7.7 which carries out
similar functions
11.10.7.6 Turning Flows in the Buffer Network

This option has now been effectively made redundant by the introduction of the
parameter REFFUB which automatically calculates and stores all assigned turning
flows at buffer nodes. Briefly this option calculates the turning flows by
reassignment and enters them in successive data base column such that the first
column entry for a buffer link A,B gives the flow from A,B to the first (nearside) exit
link from B, the next column gives the turning flow to the next (nearside) exit etc,
etc.
So although all the numbers are there their interpretation within the data base is
less than obvious. Having calculated them however the user may then print out a
matrix of turning flows at selected buffer nodes as may also be done with
SATLOOK (11.11.2) provided REFFUB = T. Best stick with REFFUB and
SATLOOK!
11.10.7.7 One Song to the Tune of Another

This long-time favourite panel game has a slightly different interpretation within
SATDB. Here it enables one trip matrix to be assigned to a network using the
routes calculated on the same network (topologically speaking) but with a different
trip matrix. The main application is in the area of “perturbation assignment” where
one wishes to examine the impact of small matrix changes without having to go
through a full SATURN run and with minimum "noise" (where noise refers to the
well-known phenomenon whereby two extremely similar networks may wind up
with quite large differences due to following two different patterns of
convergence).
The trip matrix to be assigned is nominated by the user with the additional option
of nominating a “GONZO” factor, i.e., a uniform factor which applies to the entire
trip matrix. The assigned flows (which will be “demand” as opposed to “actual”)
are then assigned to the next available column in the data base. Optionally these
flows may then be used to derive new corresponding link travel times (see also
5120257 / Apr 15 11-94

Section 11
11.10.8) which, however, are not added as an extra data base column but
included in the output file (see below).
As with SATRAP (11.10.7.4) the assignment may either be based on full o-d
routes or a “partial-route” assignment may be carried out.
FULL V INCREMENTAL LOADS

The assignment may be either “full” or “incremental”. In the former case the
initial link flows are set equal to zero or to the network fixed flows (if any – DA
code 2093) and the newly assigned flows are added whereas in the latter case the
flows start from the full demand link flows from the current network (i.e., DA code
4503). It is therefore assumed that with “full” assignment the trip matrix assigned
is a “full” trip matrix of positive trips while with incremental assignment the
assigned trip matrix consists of the differences in o-d flows from the previous
network – in which case negative trip elements are allowed (but not under full).
N.B. No explicit check is made that the sums of the old plus new trip matrix cells
do not go negative, although link flows are prevented from going negative.
If “full” then the fixed flows (if any) are added explicitly to the assigned flows
whereas with “incremental” the fixed flows are already an implicit part of the base
flows which are being incremented.
OUTPUT .UFA NETWORK FILES

Finally a new output .ufa network file with the new flows (in DA array 4503) - plus
(preferably) updated assignment travel times (in DA array 4003) - is automatically
created by this option. In effect this operation performs a “pre-assignment” and
may usefully be run prior to SATALL in its “continuation mode” (see 9.12.1) or a
single run of SATSIM in order that the new assigned (demand) flows may be fully
translated into simulation-based data.
Note that only two DA arrays are updated by One Song: the demand flows in 4503
and the corresponding link times in 4003. Thus none of the simulation-based flows
and/or times are updated: these would require a further simulation to be carried
out on the output .ufa file; e.g., run SATSIM.
It may also be seen as an early form of “Warm Start” as described in Section 22.3
with, in this case, topologically identical networks but different trip matrices.
The procedures here overlap considerably with those in SATRAP; the main
distinction is that One Song produces an output .ufa file automatically and adjusts
travel times.
ONE SONG PLUS SLA

Note that “One Song” is not particularly useful in re-assigning a trip matrix which
has been obtained by Select Link Analysis (11.8.1.3) since it will not necessarily
re-create the original flows on the selected link(s). Why? Consider a single o-d
pair with 10 trips which uses two routes 50:50, 5 trips on each. If a select link
matrix is created for a link on just one route it will contain 5 trips for that o-d pair.
When that o-d trip element is re-assigned under “One Song” it will be split equally
5120257 / Apr 15 11-95

Section 11
between the two routes and hence the selected link will only be assigned 2.5 trips,
not the original 5.
11.10.8 Creating New Data Columns

This option allows the user to create new data columns, for example via an
algebraic expression involving existing data columns or by invoking the time-flow
curves within SATURN to calculate the link times corresponding to flows in an
existing column. The basic options are described within the following subsections.
For all basic options the “new” data may either be created in a totally new column
added at the end of the data base or it may over-write an existing column.
In addition the new calculations may be applied to all links within the data base or,
if a selection is in force (option 2, 11.10.2), only to those currently selected.
Further options then control what happens to the non-selected links; e.g., whether
they remain as they are (in the case of over-writing an existing column), are
assigned a default numerical value or are defined as “missing”.
11.10.8.1 FORTRAN Equations

For example to create a new data column which is the sum of, say, columns 1 and
2 the user would type in:
X1 + X2
Very similar procedures are available to create and manipulate new matrices as
described in 10.8.1; the syntax rules are the same in both cases.
In particular the “non-standard” function GEH which is used to compare link flows
(see 15.6.2) may be calculated directly by a statement such as:
GEH (X1, X2)
11.10.8.2 “Reverse” Directions

These options allow data to be “reversed” in one of three ways. Firstly, the new
data for link A-B may appear as the “old” data for link B-A. Secondly, the new
data column may be the sum of A-B and B-A to allow, for example, the calculation
of two-way link flows from one-way. Finally the new data may be the average of
both directions.
In either case further options exist as to what action is to taken if a link does not
have a reverse, e.g., if it is a one-way link, or if, for whatever reason, the reverse
exists but the data entry associated with it is “missing”. Thus the non-existent
reverse link can either be considered to have a value of 0.0 or to be considered as
missing.
In the case of summed or averaged data if the “missing” option is chosen then the
new data will also be “missing”; if the 0.0 option is chosen then the reverse data is
always taken as zero such that the sum will simply equal the value (e.g., flow) on
link A-B and the average will be half that value.
5120257 / Apr 15 11-96

Section 11
11.10.8.3 Calculating Travel Times

A further option calculates link travel times from a column of “flows” based on the
standard assignment time-flow relationships as described in section 5.4. Note
that within the simulation network these calculations are applied to both turns and
links separately. However note that the times are based on the equations as used
by the assignment stage as opposed to being re-simulated. This operation
effectively mimics the “calculate new costs” steps within the assignment
algorithms (7.10.2).
We further note that the nominated column of input flows should be demand
flows, not actual, since the internal routine will automatically factor down the flows
from demand to actual using the appropriate ratios from the input .ufs file.
11.10.8.4 Data Aggregation/Disaggregation

“Aggregation” refers to the process whereby, for example, a turn-based data field
is transferred to links such that the value for link A-B is the sum of all turn values
A-B-C or link values are aggregated to nodes.
By contrast “disaggregation” might associate a data value for link A-B with all its
exit turns A-B-C. For example the travel time on a link may be associated with
each turn at the end of a link and then (separately) added to the turn delays to
produce the total time to make a turn out of its entry link.
In the opposite sense turn properties, e.g. delays, may be associated with the link
from which they have come either by: (1) pure addition, (2) as a flow-weighted
average or (3) as the maximum/minimum value. Option (2) could be used to help
determine an appropriate average turn delay out of a link, while option (3) might
be used to calculate the maximum V/C ratio for a turn and set that as a link
property.
Note that under the node data base link data may be further aggregated into node
properties using either of the 3 options above. Hence turn data might be
aggregated by link and then further aggregated by node. Equally turn data may
also be aggregated directly into node data.
11.10.8.5 Replacing Missing Values

“Missing values” are used to indicate when a particular data entry for a particular
link does not exist, in the sense, for example, that turning flows are not defined for
centroid connectors. See 11.10.1. In certain situations it is desirable to assign
numerical values instead of missing values, e.g., when doing a numerical link
selection test. Option 6 allows numerical values to be substituted for missing
values in one or more data columns with a choice of the value used.
11.10.8.6 Mark Selected/Non-selected Links

If a selection is in force then this option simply writes one (user-set) numerical
value in all selected links and another value in all non-selected links. Most usually
the values used would be 1 and 0. For example, multiplying a full column of link
flows by a 1/0 column (using 11.10.8.1 and an “equation” such as X1*X2) would
create a data column containing flows for selected links only with zero entries
everywhere else.
5120257 / Apr 15 11-97

Section 11
11.10.9 Dumping to an ASCII (Text) Data File

The facilities included within option 13 of the Main Menu (Dump the full data base
to an ascii (e.g., .txt) file) allow users to transfer data from the internal data base
to an external ASCII (text) data file for, e.g. transfer to another suite of programs.
They mirror largely the options described under 11.10.6.5 to import data from
external data files. A more automatic batch file to do the same basic job is also
available; see dbdump, 15.46.1.
(Note as well the existence of Option 9 – External Direct Input and/or Editing –
which also outputs and/or inputs text files but which makes use of so-called “.dbd”
files. These facilities are similar to those under Option 9 but are now largely
redundant since the .dbd file format is a good deal more restrictive and SATURN-
specific than that for basic .txt files and its use is not recommended. The one
advantage of .dbd files is that, if they are dumped from SATDB, edited externally
and re-input, they retain their original “headers”.)
Thus, the output text file consists of one record per network link (with non-selected
links excluded) with each record split into two “parts”.
♦ A link(/turn) identifier
♦ Data values
Options specify how each part is formatted.
At the highest level the format choice is between full formatting into fixed columns
or “free” or “comma separated” CSV formats where each item in both a) and b)
appears separated by commas (best for transmission to spreadsheets such as
EXCEL).
Under CSV output turns must always be identified by three entries (A, B and C-
nodes) while, strictly speaking, links only require two entries, A and B. However,
since it is generally easier for whichever system is to read the data files to have a
fixed number of entries per record, an option is provided to include a third “blank”
entry for all links; in essence this means that an extra comma is inserted after the
B-node.
At a lower level the link identification may either follow the basic SATURN
conventions described in 11.10.4 and 11.18.2 or they may contain simply two
sequential node numbers as used internally within SATURN (useful for
transferring data to other suites which number nodes sequentially). Within the
data values integer variables appear without decimals, real variables have them.
The precise format of real variables is either as determined under “housekeeping”
(11.10.10) or they may all appear as high precision values using the FORTRAN E-
format.
Further options exist to include or not column headers and/or comment cards at
the head of the output file.
Unlike output to the screen there is effectively no limit to the “width” of each output
record so that up to 24 data columns (the internal limit) may be included in each
record.
5120257 / Apr 15 11-98

Section 11
The order of the data records is either sorted by link type as is the default within
SATURN (i.e., all centroid connectors either inbound or outbound appear first) or
in strict numerical order by assignment link numbers.
11.10.10 Basic Housekeeping Operations

The housekeeping options enable the user to set a number of parameters
associated with each existing data column:
♦ its DA code;
♦ its (40 character “long”) title;
♦ its print format;
♦ whether displayed within SATDB listings;
♦ whether annotated within P1X plots.

The uses of the DA code are explained further under 11.10.12; basically the code
is only really relevant for output to a new .ufs file.
The title appears at the head of the column listings and in addition to (but not
always) when the data base column number is referenced elsewhere.
The print format is based on standard FORTRAN conventions and determines:
♦ the “width” of the data, print outs (in terms of the number of characters);
♦ whether it is real or integer (i.e. with or without decimals);
♦ if real, the number of decimals.

Thus F10.2 fixes the output to 10 columns with 2 decimal places after the decimal
point.
The SATDB and P1X displays both toggle each data column between “on” and
“off”. Thus it is possible to exclude data columns from either the text listings within
SATDB or the link annotation within P1X by changing its print/plot status
respectively.
11.10.11 SATDB Screen Display/Edits

If the data base as a whole may be visualised as a (generally) very long rectangle
with one line per link then display mode is equivalent to a window of (typically) 19
lines which may be moved up and down the full rectangle.
Within this window a number of options are provided (as buttons under 32-bit, as
a set of key strokes under 16-bit):
♦ Quit (return)
♦ Up (move the window up 19 lines….
♦ Down (…or down)
♦ Home (move the window to the top
5120257 / Apr 15 11-99

Section 11
♦ End … or the bottom of the data base)
♦ Search (move the first line of data for a particular node)
♦ Select (Enter the select menu; see 11.10.2)
♦ Order
♦ Parameters
The last two require some extra explanation.
“Order” enables the user to change the vertical order of the links in the printed
data base, for example you may ask for them to be printed in descending order in
terms of the entries in column 2. Thus ordering requires: (a) a column: (b)
whether descending or ascending and (c) whether based on actual or absolute
values.
Parameters allow the user the choices of whether or not to print lines based on
centroid connectors (or zones under the node data base) and/or lines which
contain all missing values.
11.10.12 Creating a New Output .ufs File

A new .ufs might be created if you have changed the values of some existing
components of the input .ufs file or if you have created totally new data columns
which you wish to preserve permanently.
Thus for each column in the data base the user chooses whether to output or not.
If output it may, potentially, be stored as either assignment links, simulation routes
or simulation turns (see 5.5.1 and 11.10.1). The default is the current “link type”
for that column. Equally each output column may be assigned a new DA code
and/or a new “title”.
Generally speaking data columns which have been read directly from the input
network file and not changed need not be selected for “output” since they will,
however, be copied. If an input data column has been changed it should probably
be output with unchanged "parameters", e.g. the same code and title although the
contents will be different.
Where decisions need to be made is with the output of new columns which have
been created within SATDB; for example you may have applied a formula to
calculate emissions per link and you wish to save those calculations for future
reference. In this case you need to select:
♦ the DA code
♦ choose assignment link/road/turn
♦ set a title (up to 40 characters)

The third choice is straightforward, the second should be obvious from the type of
data (if what you calculated is only defined for simulation turns and all other links
are “missing” choose simulation turns) but the first requires some knowledge of
SATURN.
5120257 / Apr 15 11-100

Section 11
The general principles of DA codes are explained in 15.21; a list of those already
in use in a particular file may be obtained within Option 4 (link data input) or a full
list of general codes is given in Appendix J. Generally one needs to choose a
non-standard and unused code but also one less than 5003. Recommended /
“reserved” values are in the range 3003 to 3293.
11.11 SATLOOK: Interactive Text Outputs

The program SATLOOK is used to selectively examine results read from a
SATURN UFS/A file, generally the output UFS file from the full
simulation/assignment loop (e.g. from SATALL). In most cases the same outputs
are also available within other programs in the Suite - for example, summary
statistics from the simulation phase may be printed out by either SATALL or
SATSIM - and/or from elsewhere within P1X; e.g., option 1 is available within
node graphics.
The following menu lists the full set of options available within SATLOOK. Of
these options 1 to 14 only are also directly available within P1X.
1) EXAMINE INDIVIDUAL SIMULATION NODES
2) EXAMINE INDIVIDUAL BUFFER NODES
3) EXAMINE INDIVIDUAL ZONES
4) SIMULATION SUMMARY STATISTICS
5) ASSIGNMENT SUMMARY STATISTICS
6) BUS ROUTE SUMMARIES
7) NETWORK PARAMETERS FOR FILE n
8) ERROR, CONVERGENCE AND CPU SUMMARIES
9) SKIM “COST” MATRICES FROM FORESTS
10) PRINT COMPLETE SIMULATION NODE DATA
11) PRINT ALL ASSIGNED FLOWS AND TIMES ON THE LP
12) PRINT ALL OVER-CAPACITY LINKS
13) COMPARE MODELLED FLOWS WITH INPUT COUNTS
14) MINIMUM COST TREES AND/OR MATRICES
15) TAKE A JOY RIDE THROUGH THE NETWORK
16) GENERATE AN INTER-ZONAL CROW-FLY DISTANCE MATRIX
17) COMPARE TWO ARRAYS ELEMENT BY ELEMENT
18) COMPARE TWO FILES ELEMENT BY ELEMENT
19) LOOK DIRECTLY AT ELEMENTS ON UF FILE 1
5120257 / Apr 15 11-101

Section 11
20) COMPARE THE SIMULATION CODING BETWEEN NETWORKS 1

AND 2
The majority of these options and the menus therein are felt to be sufficiently self-
explanatory that no further detailed documentation is required here. However
some further notes are provided for specific options.
11.11.1 Simulation Nodes

This option re-simulates the selected node and allows full access to information as
to how the simulation of delays, queues etc. has progressed. For example one
may view full cyclical flow profiles (8.1), albeit in a somewhat dated computational
format, as well as full information on flows, queues, emissions, etc.
See Section 17.7 for an explanation of the tabulated delay plus flow data (option
2) and section 8.7 for a description of the lane choice output (option 12).
A new option in 10.5 prints the delays for each turning movement broken down
into its constituent components listed in 8.4.1 (i.e., fixed delay (TDEL), transient
(CFP) delay, random delay, circulating time at roundabouts and over-capacity
delay).
Further options include the ability to print delay and flow data (table 2) either as
originally constituted (if the node has been edited – table 22) or as contained in a
second input network file for comparison purposes (table 23). A further option
involving data from network 2 prints a full set of differences in the coding for that
node between networks 1 and 2 (introduced in 10.9, table 24). See 11.11.18 for
the same option over all simulation nodes.
Options 27 and 28 provide information on the convergence of the assignment-
simulation loops by, 27, comparing the times per turn by both methods (at
convergence they should be identical) and by, 28, a more extensive set of
convergence statistics such as changes in the blocking back factors from one loop
to the next. See 9.9.2.
Option 29 prints a full list of all data contained in the SATDB data base (if any)
relevant to this node, links and/or turns.
If any of the entry or exit links to the node have speeds which are limited by
CLICKS (15.47) then the relevant speeds/delays/etc. by link are displayed under
option 30 (added in Release 11.3.5).
In using SATLOOK to examine simulation nodes users may notice either slight
inconsistencies in the outputs (e.g., OUT flows in excess of the ACCEPT flows) or,
e.g., slightly different capacities from those printed elsewhere. These problems
are due to a lack of convergence in the simulation of that particular node since
SATLOOK actually creates the data by re-simulating the node. However, such
discrepancies should be small in virtually all cases; if not please notify DVV.
11.11.2 Buffer Nodes

Output, having selected a buffer node, consists of two standard tables giving
times, distances, flows etc for all buffer links into and out of that buffer node. See
also 11.8.4.2.
5120257 / Apr 15 11-102

Section 11
In addition, if REFFUB = T, it is possible to print all turning flows at that buffer

node as assigned within SATALL either to the .LPL file or to an external text file.
The turning flows may either be in a “matrix format” for all in and out links at a
particular buffer node or one record per every possible turn in the buffer network
in format A-B-C-Flow.
11.11.3 Zonal Information

Select a zone and (fairly limited) data on entry and exit flows plus times and
distances (often zero) are displayed. See also 11.8.4.2.
11.11.4 Simulation/Buffer Summary Statistics

This option prints network summary statistics, e.g. total pcu-hrs, pcu-kms etc, for
both the simulation and simulation plus buffer networks. See Sections 17.8 and
17.9 for an explanation of the tabulated data which is output. In addition the same
statistics but disaggregated by different flow definitions (e.g., bus flows, user class
flows, etc.) or by different sets of link groups (see Section 15.59) may also be
displayed.
These figures may be obtained in three basic ways:
1) Using the aggregate and/or link disaggregate data calculated within
SATALL (or SATSIM) and stored on the .ufs file (see 15.59.2);
2) Calculating the same totals explicitly here from, e.g. the basic flow and
time/distance per link arrays.
3) Using data from the .ufs file but not just taken from the “final” loop of the
assignment-simulation loops but, e.g., averaged over the final 4, from a
single previous loop, etc. See 17.9.
Note that both options 1 and 2 print more “tables” than option 3 (which basically
just reports the combined simulation and buffer total statistics as documented in
Section 17.9), although there should be more than enough numbers to keep most
users happy!
SUMMARY STATISTICS BY SUB-NETWORKS

For full network statistics the first two (as well as “final” results from method 3)
should give the same results (allowing for possible rounding errors). However the
second method may also be applied to sub-networks as defined using the link or
node selection facilities within P1X and/or SATDB (11.6.1). One interesting
application of the latter is to use the cordon facilities within P1X (11.13) to define a
sub-network whose links are selected and then using this option to obtain
summary statistics for that particular area. Another is to use the node-based
selection to produce statistics for, say, all signalized junctions.
DISAGGREGATED SUMMARY STATISTICS BY INDEX

With all options the outputs may optionally be disaggregated over either Capacity
Indices (if they exist within the network; see 5.1.9) or, post 11.2.9, by either TfL
traffic boroughs or a more general definition of “link/node groups”. E,g., you may
obtain total pcu-hrs by all links which have a Capacity index of 1, 2, 3 etc. etc.
5120257 / Apr 15 11-103

Section 11
(N.B. the Capacity Index of a turn A-B-C is considered to be the Index of the entry
link A-B. All links without a Capacity Index are judged to have an Index 0.)
Disaggregated statistics by TfL boroughs are output if both BYGRUP = T and TFL
= T as set in the original network .dat file. Alternatively, if BYGRUP = T but TFL =
F and a “node group” file has been defined as FILN2G, then the disaggregation
will follow the aggregation rules set in FILN2G.
It is also possible with option 2 to disaggregate the outputs by any integer link
variable defined within the SATDB link data base. For example, to disaggregate
output statistics into “traffic boroughs” it is first necessary to create a link data
base column containing integer Traffic Borough numbers (e.g., by inputting an
ascii file of the form A B Ntb where link A-B is “in” Traffic Borough Ntb). Then
select the menu option for Disaggregation by Data Base Column and the
appropriate column.
Further notes: It is not always easy to specify a data base column as integer
since the default, e.g., from text file input, is to assume “real” (decimalised) values
with a DA code ending in 3. It may therefore be necessary to use Housekeeping
to change a column header from 3 into 4.
Furthermore the option to disaggregate by a data column is not available within
“pure” SATLOOK, only within P1X where the facilities within SATDB and
SATLOOK may both be invoked together.
OUTPUT .CSV SUMMARY STATISTIC (HEADLINE AND/OR LINK) FILES

Options exist to output either the full (“headline”) set of summary statistics or the
equivalent statistics per individual (simulation) link to text files in CSV format. In
both cases the first record contains a set of (fairly succinct) column headers.
With full statistics each subsequent record corresponds to a different set of flows
(e.g., total flows, flows by user class, etc.) and/or a different level of
disaggregation by “index” as above. The data given corresponds to the entries in
the table as illustrated in Section 17.9.1. Under disaggregation by link each record
corresponds to an individual (simulation) link such that all appropriate data per exit
turn from that link is included within the link statistics (e.g. total time includes
delays per turn).
Clearly the purpose of dumping data in a .CSV format is to transfer the data into,
say, Excel for more detailed analysis. A further rationale for dumping data by link
is to enable, for example, more specific aggregations to be carried out (so that
aggregation by, say, traffic borough could be carried out within Excel as an
alternative to using the facilities within SATLOOK).
Note that, at the moment, the first record of column headers may or may not be
complete, depending on the permutations and combinations of network
parameters that determine the number of headline statistics included. If this
happens the easiest thing is to empirically determine the column contents by
comparing their numerical values to those output (and fully annotated) on the .LP
files.
5120257 / Apr 15 11-104

Section 11
Note as well that the precise order of the headline statistics also depends on the
permutations and combinations of network properties so that, for example, there is
no guarantee that total vehicle-kms always appears in column 8.
Please get in touch with DVV if any of the above creates problems.
11.11.5 Assignment Summary Statistics

These statistics provide measures of total pcu-hrs, pcu-kms, pcu-pence (using the
values of PPM and PPK at face value to define “pence”) and an average speed for
links in the “assignment network” which, see 5.1, includes all centroid connector,
simulation links and turns plus buffer links.
To a large extent these duplicate the numbers given by the simulation / buffer
summary statistics (11.11.4). However, since the latter also includes buffer totals
and differentiates between travel within the time period and beyond -which the
assignment statistics do not -, the assignment statistics option is somewhat
redundant; the simulation statistics should be more useful as well as being more
precisely defined. The assignment statistics do however include data on trips
crossing the simulation/buffer cordon which the simulation statistics do not.
11.11.6 Bus Summary Statistics

These statistics trace each bus route and sum total travel times and distances -
disaggregated into buffer and simulation (and further disaggregated into road and
junction times). These are split by company (if used).
Appropriate summary statistics, plus disaggregations by company, are provided.
Note that these are in units of, e.g. bus-kms as opposed to pcu-kms so they may
appear to differ from, e.g., simulation summary statistics which are based on pcu
flows.
Figures on the number of buses and bus-kms lost due to over-capacity queued
junctions in the simulation network are also calculated.
The over-capacity queuing referred to here relates ONLY to permanent queues
when V > C on a simulated turn and the bus frequency will be reduced
downstream from the queue. The % quoted is effectively calculated at the end of
the route so if, say, 10 buses per hour is the frequency at the start of the route
but, due to permanent queues anywhere along the route, the frequency at the far
end is down to 7 per hour then the queue reduction would be 30%. So that figure
does not depend on whether, say, the queue was on the first or the last link.
By contrast the bus-kms lost also refers to V>C queues but does depend on
exactly where the queue occurs since it sums up bus-kms downstream of the
queue up to the end of the route. So a 30% reduction on the first link in a route
would lead to many more bus-km lost than the same reduction on the final link.
CSV Output Files
From release 11.3.7 comprehensive route statistics such as travel times,
distances etc. are stored in an output .CSV file, one record per route. If the
filename is net.ufs the CSV file will be named net_BUS.CSV.
5120257 / Apr 15 11-105

Section 11
11.11.7 Network Information

Network information lists, for any one of the input network files, information such
as which program created that file and when, the file names of any associated
files such as the trip matrix, basic network dimensions (number of nodes, links
etc) plus values for most of the parameter values set on the input network .dat file
within SATNET.
It also includes selected output parameters, in particular for elastic assignment the
empirical estimates of the elasticities (7.7.5).
The same information may also be obtained within P1X under “Information” - see
11.8.5.
11.11.8 Convergence, Error, Assignment and CPU Summaries

These statistics may be divided into (up to) six sub-sections:
1) Error statistics listing the number of semi-fatal and non-fatal errors, serious
warnings and warnings (see 2.9) which occurred in SATNET and each
iteration of the assignment/simulation loops (independent of whether those
loops were within SATALL or part of a SATSIM/SATEASY loop).
2) Two tables of convergence statistics from the assignment /simulation loops:
effectively the same table which appears in the SATALL .lpt file and is
described in 9.2, plus that described in 9.9.1.1.
3) CPU times as recorded with SATNET and as totalled over all assignments
and simulations. Note that “cpu time” is not a strictly accurate term as what
is measured is actually elapsed time from the start to finish of an operation.
In a multi-tasking environment the two may be quite different.
4) Epsilon-2 statistics describing the degree of congestion in the network; see
7.2.6.
5) Supply elasticities (post 10.4) for the network as a whole; see 7.11.11.
6) SAVEIT accuracy statistics – see 11.8.4.7 and 15.23.2.
11.11.9 Skimming “Cost” Matrices from Forests

The procedures here extend those in 11.11.14 to obtain O-D “cost” matrices by
taking average skims over a forest of trees rather than extracting the O-D “costs”
from a single route tree (See 15.27.3). Two basic options are available.
The first option allows the definition of the “quantity” such as time or distance
which is to be skimmed (as opposed to the “cost” used to build the forest which is,
by definition, the cost used by the assignment). By default the skimmed quantity is
also the generalized cost as used within the assignment such that the output
matrix gives the average costs of O-D travel as generated by the assignment. By
defining a different quantity to be skimmed, e.g., time or distance, it is possible to
obtain the matrix of O-D times/distances averaged over all used routes.
Alternatively the quantity to be skimmed may be something entirely different using
data constructed by the user such as a measure of fuel consumption per link, rate
5120257 / Apr 15 11-106

Section 11
of emissions per link, reliability per link etc. etc, Thus any data which may be set
up by the user within a SATDB data column – including data read from an external
text file – may be skimmed. Thus, for example, if the link data is fuel consumption
per vehicle per link then the skimmed matrix will give fuel consumption per vehicle
per OD pair as possibly required by an evaluation model.
The second controls the output mode: by default output is to a .ufm file but it is
also possible to output the o-d skimmed data as ASCII text files, specifically in one
of the three standard formats required by the UK evaluation program Tuba (as
used by the SATURN procedure SATTUBA, see 15.41). Within text files there are
additional sub-options, e.g., to control the number of decimal places used.
Note that the default values for, e.g., output mode, may be user-set by making
changes to the preferences file, satlook0.dat.
Forest skimming is used by a number of batch files, e.g., SKIMDIST (see 15.27.7)
to produce matrices of average OD distances, tolls, etc. etc.
See also 15.27.8 which describes an optional parameter NUSKIM introduced in
10.9.17 which uses more CPU-efficient algorithms.
11.11.10 Complete Simulation Node Data

This procedure prints selected simulation node data similar to that available under
11.11.1 to either (optionally) the line printer or the terminal. Data may be listed for
all simulation nodes or a subset, e.g. traffic signals only.
11.11.11 Assigned Flows and Times to the LP

This duplicates the print options in SATEASY (PRINTF=T) by printing the
assigned flows and travel times on all assignment links. The link listings are as
described in 11.10.4. Travel times/delays on simulation links/turns are as
calculated by the final simulation.
11.11.12 Printing Over-Capacity Links

This is a good example of an “inflexible” listing in that it prints all those links (and
turns) where the volume exceeds the capacity as opposed to the more “flexible”
listings which may be obtained using SATDB where it is possible to print all links
where, e.g., the V/C ratio is greater than 1.2.
The listings are disaggregated into simulation and buffer links with (which is more
awkward in SATDB) suitable summary statistics printed.
11.11.13 Comparing Modelled Flows with Input Counts

This option compares the modelled assignment flows with those input on the
77777 network data input records (6.10). It mirrors the procedures under P1X
Validation; see 11.7.1 for full details.
The comparison statistics appear both on the screen and in the .LP files while a
further option allows them to be output in a “headline” format (i.e., one record per
count in .CSV format) to a separate file.
5120257 / Apr 15 11-107

Section 11
One point of difference between count comparisons in SATLOOK and P1X is that
in SATLOOK it is possible to alternatively read the count data from an input text
(ASCII) file rather than relying only on the original 77777 records. At the moment
this is not yet possible within P1X.
11.11.14 Minimum Cost Trees and/or Matrices

The tree information as provided here is partially redundant and, for simple
analysis and network validation, is much more conveniently catered for by the
pure graphics displays in P1X; see 11.8.3.
On the other hand this routine still provides the main mechanism by which
minimum cost and/or (simple) skimmed matrices may be obtained. See 15.27 for
a full explanation of the processes involved and the terminology used. For
example this option is used by the SATCOST procedure (15.27.4) to generate
minimum-cost O-D matrices.
N.B. The skimming facilities within this option must be treated with some caution;
see the warnings in 15.27.6.
11.11.15 Joy Rides in SATLOOK

Again, the purely numerical Joy Ride options within SATLOOK mirror (and pre-
date) the graphical routines in P1X (see 11.8.2) but are now essentially
redundant. They do not, for example, allow the joy ride to be specified by non-
adjacent nodes with the intermediate nodes being interpolated as may be done
graphically.
11.11.16 Interzonal Crow Fly Distance Matrix

This uses the input XY co-ordinate data to calculate the distance (in metres)
between each pair of zones using the Euclidean or crow-fly, distance. These are
then output to a .ufm file.
One possible application would be to calculate a crow-fly average speed by
calculating the actual travel time matrix and then using MX to divide one by the
other (with a suitable correction factor to account for units). Another might be to
take the ratio of actual travel distance to crow-fly, again using MX.
11.11.17 Direct Access Array Manipulation in SATLOOK

The role of the Dirck Access (DA) file structure within SATURN is explained within
15.21 and the role of the four DA-programs based on them are described in 12.3
to 12.5. The SATLOOK options provide very similar functions to those in
DALOOK etc and are intended primarily for the use of developers. They are only
available within SATLOOK as a freestanding program, not within P1X.
11.11.18 Comparison of Simulation Node Coding (P1X only)

This option (first introduced in 10.9) compares the simulation coding at each
individual simulation node and prints a list of all nodes with differences between
the two; e.g., differences in the signal timings between the two networks. This is
very often useful for finding out what differences have been introduced in an
5120257 / Apr 15 11-108

Section 11
updated network, particularly if standards of documentation are not as good as

they should be!
The list of nodes numbers may be extended to a complete list of specific
differences, e.g., that two nodes differ only in terms of the distance coded for one
specific A-node.
Note that the differences listed are not necessarily comprehensive but stop at the
first “level of differences” encountered. For example, if the node coded in network
2 has 4 arms as opposed to 3 in network 1 then the listings only record that fact,
not that a link from a common A-node has different distances.
The same comparison data may also be displayed for individual nodes – see
11.11.1. See also 11.6.5.4 where similar information is provided under Node
Highlighting.
11.12 Node Editing and Graphical Display (SATED)

Simplified junction diagrams for simulation nodes may be displayed within P1X or
(historically) via the distinct program, SATED. However, as a distinct program,
SATED was effectively discontinued from 9.5 onwards and removed totally with
the release of 10.9 in 2009.
11.12.1 Choice of Nodes

Within P1X the junction-display functions may be accessed either as “Node
Graphics” from the P1X master menu or, with slightly extended functions, through
the Network Editing routines. In the former case the emphasis is essentially on
the display of properties of simulation nodes (e.g. lane structure, simulated
delays, etc) as currently defined on the input .ufs file while in the latter the
emphasis is on altering the input properties such as the lane structure in order to
change the .dat file (see 11.9.3).
Within the main P1X menu nodes may be selected:
(1) using the mouse to select from the current network plot (click on mouse in the
banner and then “single-click” on the node);
(2) by numerically inputting the node number,
(3) by directly “double-clicking” on a node in the current plot (without a prior
choice from the banner) or
(4) by looping over all currently selected nodes.
The last option is particularly useful if the user wishes to look at all nodes with a
particular property in common, for example they may all have the same coding
error.
In addition, if you are already in node graphics (main menu), you can move to an
adjacent node by left-clicking on its node number.
5120257 / Apr 15 11-109

Section 11
11.12.2 Node Graphics Displays

Individual simulation junctions may be displayed graphically as a line-based
junction diagram occupying the full screen as illustrated below.
Thus at the centre of the plot is a diagrammatic representation of the junction with
the lanes and turn markers on each arm displayed approximately to scale
assuming that each lane is 3.75 m and that the distance to the end of each arm as
shown is 40 m.
A flared lane, either nearside or offside, is represented by an extra lane at the stop
line which is terminated at a representative distance back – where
“representative” implies halfway for a flare length of two PCUs, increasing up to ¾
of the length of the arm as the flare tends to infinity or to ¼ as it tends to zero.
If, as in the illustration above, the junction is signalized each entry arm has a stop
line included; at priority junctions major arms do not have a stop line, minor do.
Permitted turning movements per lane are represented by arrows within the lane,
generally coloured green but with the convention that: (a) turns with a priority
marker X are in red, (b) filter turns (F) are orange and (c) merges (M) are light red.
Along each entry arm a “kerb line” is plotted in light grey while the background of
each “block” is filled in dark grey; both are optional as are the colours used.
In this example V/C ratios (as %) have been annotated for each turn with arrows
to indicate which turns are which.
The street names are obtained from an input GIS file as the “name” of the junction
(lower left, main plot). The junction number is given lower right.
Links which are blocking back, either into or out of the central node, are indicated
by red bars across the entry/exit link with the “space” in the centre of the bar
5120257 / Apr 15 11-110

Section 11
indicating how much of the capacity is left after blocking back has been applied.
For example, if a link is severely blocking back such that it has a blocking back
factor of 0.2 – an 80% reduction in capacity – 80% of the bar will be red with 20%
blank in the middle.
At the top left hand corner the three sub-boxes represent the three stages of the
signals with the green movements in each stage depicted by a green “tubie”
arrow. In each box the number in the lower left is the (coded) green time and in
the lower right, the inter-green. The signal offset is written upper left in the first
box.
The numbers given upper right in each stage box represent the “factored stage
times” which differ from the “coded” green times since - in this particular case - the
cycle time has been set to 60 seconds but the sum of all the input green and inter-
green times is 90 seconds. Hence the stage green times are factored down such
that they sum along with the (unfactored) inter-greens to 60 seconds.
The banner (which in this case has been generated by “A-Z” as opposed to the
more normal list of available options) briefly summarises the contents of the plot.
11.12.3 Display Options

The ‘top’ banner or menu permits the following display options:
♦ Modify general display parameters, e.g. whether lane markings are included,
their width, etc.;
♦ Data displayed, e.g. turning volumes, general tables of link data; and its
“mode” (arrows, tubies, etc.);
♦ Animation option; e.g. to display signal stage sequences or the progression of

queues throughout the cycle;
♦ Print a summary table within the banner of the most important properties of
that node (“Information”);
♦ Print standard tables of node data such as appear in SATLOOK using either
a text or window-based mode, including “table 2” (flows and delays) as a
standard option plus the last table displayed as a further explicit menu option;
♦ To “print” the node description as it would appear within a network .dat file
input to SATNET; see 6.4;
♦ Editing options; * see 11.12.4;
♦ Re-define graphical system and/or device properties;
♦ Shift to another node, numerically either the next node up or down, or use the
mouse to “point” to a node at the end of an arm;
* (N.B. Within P1X node editing when accessed via “node graphics” is largely experimental in that
the changes are not saved; if you wish to save these changes on either a .ufs or .dat file you must
enter via network editing; see 11.9.3).
5120257 / Apr 15 11-111

Section 11
♦ Plot to other devices - bitmap files or to an alternative device;
♦ Display an “A-Z banner” detailing what is currently being displayed; see

11.15.
♦ Add an “auxiliary network plot”, i.e., a small network plot showing the location
of the node being displayed; see 11.5.4.
11.12.4 Node Editing (P1X)

P1X allows users to edit existing nodes in essentially two ways:
♦ They may interactively change data associated with existing simulation

junctions in a SATURN UFS file and examine their impact by re-simulating
that node in isolation.
♦ They may convert a buffer node as read from an input UFS file into a
simulation node.
Having edited one or more junction properties the node may be “re-simulated” and
the effect of the changes evaluated.
Note that in the “display mode” – as opposed to the “network editing mode”
(11.9.3) – any changes to node properties are not permanently stored in, e.g., a
network .dat file although they are stored temporarily. The menus, however, are
virtually identical.
The data to be edited may be selected in one of two basic “modes”. Thus,
originally, all choices were made through a series of banner menus such that if
one wanted to change, say, the distance on a particular link one would first select
“Link Data”, then nominate the link, then nominate distance and input the new
length.
Alternatively, post 10.9.20, the same operation may be affected by clicking a
“target box” at the end of an arm to select that link for editing and then clicking on
either Record 1 or Record 2 for that link in order to alter any of the standard basic
link properties such as distance, speed, number of lanes etc. using a standard
Windows “edit box”, or, equally, by clicking on a target box at the end of an exit
arm in order to edit turning properties such as saturation flow, lane choice etc. for
a particular turning movement..
11.12.5 Applications of Node Editing

Node editing is intended to be used in the following ways:
♦ Network calibration, whereby the user can determine interactively the most
appropriate data values for an individual junction. For example the user might
wish to examine a change to the saturation flow for an individual turn or to its
lane structure, etc., etc. An alternative procedure to (1) would be to make the
changes in the basic network DAT file input to SATNET, re-run the entire set
of SATURN programs and examine the effect of the changes - a somewhat
cumbersome and potentially expensive operation. Using node editing effects
can be seen immediately. The difference between editing a single node and a
full SATURN run is that editing does not allow for any re-assignment in
5120257 / Apr 15 11-112

Section 11
response to the changes; the flows remain at their assigned values (although
it is also possible to investigate the impact of changing the flows on a
particular link or turn).
♦ User “education”, by which I mean that the user can experiment with, e.g.,
different values of gap acceptances to see the effect that changes to a
variable have on results.
♦ Interactive data input.
♦ Simulation, testing and design of individual junctions without the need to go

through the full SATURN procedures. In this way SATURN can be used as a
simulation model of isolated junctions, i.e., with its assignment capabilities
totally removed.
♦ To aid in the conversion of networks coded as buffer networks into simulation

networks. The relevant buffer link based data is extracted from the UFS file
while the additional junction-based data is input interactively. (See also
11.9.11)
11.13 Graphical Network Cordoning

The cordon options within P1X duplicate most of the functions available within
SATCH (see 12.1); but in addition and more importantly assist the user to define a
“water-tight” cordon interactively specifying a set of “cut links” surrounding an area
of network. The cordon thus defined may be “dumped” into a control file as
required by SATCH.
The first menu within the cordon procedures specifies the cordon which may be
defined in five ways. The cut links may be defined either link-by-link, by “cut lines”
which join successive points and select the links they cross or by a rectangular
“box” which cuts selected links. It may also be set by a previously prepared
SATCH-input control file or via a “spine” - see 11.13.5. In either case the existing
set of cut links may be “edited” by either addition or deletion.
The next step in the definition is to nominate an “inside” node which is used to
distinguish the inside of the cordon from the outside; see the parameter MIDDLE
described in note 1 in 12.1.4. A “tree” is then built outwards from that node in
order to identify those nodes which are “inside” the cordon. The links which are
used in that tree are highlighted for information purposes only.
5120257 / Apr 15 11-113

Section 11
11.13.2 Cordoning Sub-Options

Having fully cordoned off a sub-area of the network the following sub-options
become available.
♦ Cordon corrections which checks for redundant links in the cordon,
♦ (i.e., those which are either totally inside or totally outside the cordon) and
removes them. If there are none no changes are made. The number of such
errors is reported in the banner.
♦ Further editing of the cordon, e.g. to add extra links to “plug” any holes.
♦ Output a control file for input to SATCH; see 12.1.3.
♦ Produce a network .dat file for the cordoned area suitable for input to
SATNET (analogous to DONET in SATCH).
♦ Produce a .ufm trip matrix and/or print the matrix for the cordoned network
based on the routes used in the full network (analogous to DOMAT in
SATCH); see 11.13.6.
♦ Produce a file specifying the assigned route flows inside the cordoned
network as per SATPIG (see 12.6); see 11.13.7.
♦ Define capacity indices within the cordoned network (11.13.4).
♦ Use the cordon to “select” either those links and/or nodes inside or outside for
further analysis with P1X; see 11.13.3.
5120257 / Apr 15 11-114

Section 11
♦ If there are “holes” in the cordon the “tree trace” helps to detect them by
tracing a path from “outside” to “inside”. Return via the edit option to correct
the cordon.
It is recommended that the cordon correction option be run (if necessary) prior to
any output files being produced as there may be spurious zones created at the
redundant links. Equally the options to create matrices, route files etc. will not
function if there are any errors in the cordon definition.
Note that if both a cordoned network file and a trip matrix are created it should be
feasible to do a full run of SATURN on the sub-network without any further
intermediate steps. However please note the cautionary advice in Section 12.1.4
that the logic of the cordoning procedures may not be 100% fool-proof with
respect to, e.g., bus route definitions, so that some manual editing and cross-
checking may be necessary.
11.13.3 Link-Node Selection via the Cordon

Cordoning may be used to select links and/or nodes which lie either:
♦ inside the cordon
♦ on the cordon itself
♦ outside the cordon

Both links and nodes are selected for both P1X display (11.6.1) and for
analysis/display within SATDB (11.11.4). The set of selected nodes may also be
used within signal optimisation (11.9.13.1).
11.13.4 Setting Capacity Indices via the Cordon

Cordoning may be used to define capacity indices for those links which lie either:
♦ inside the cordon
♦ on the cordon itself
♦ outside the cordon

The indices may or may not be extended to include turns and/or centroid
connectors which are, say, inside.
11.13.5 Cordons defined by a “Spine”

Cordons in P1X may also be defined via a “spine” which consists of a series of
consecutive links (in effect a “route” and selected as such) and the cordon cut
links consist of all those links which enter or leave the spine. The most common
example of a spine is a section of motorway with the cut links corresponding to all
exit and entry ramps along that section.
The most common application of a cordon spine is to produce and print a trip
matrix which therefore gives the table of all entry/exit movements within that
section from the existing assignment.
5120257 / Apr 15 11-115

Section 11
Spines in P1X are closely related to the SPINE parameter in SATCH (see note 6
in 12.1.4) but extend the idea such that in P1X the spine may be defined by more
than 2 nodes so that the spine can “go around corners”.
11.13.6 Cordoned Trip Matrices

The cordoned trip matrix (or matrices in the case of multiple user classes) is
calculated by tracing all routes in the original network and recording all trips from
their entry point to their exit and/or internal zones. The matrix thus obtained may
optionally be output as a .ufm matrix or (new with 10.3) printed to a window.
The matrix may be based on either demand flows (which take no account of trips
caught in over-capacity queues upstream of entering the cordon) or actual flows
(which do).
In addition the matrix may be “Furnessed” (see 12.1.7) such that any errors in the
stored O-D routes are corrected and the input and output flows at the new zones
created at the cut points are matched exactly to the assigned flows.
11.13.7 Routes File Output

A “routes file” for the cordoned area may be output using the standard “.trp” format
This therefore duplicates the function of SATPIG, except that here the routes and
associated flows are only those as used within the cordoned area whereas
SATPIG operates over a full network.
11.14 Pure Matrix Graphics

These routines - which are in fact referenced from the top menu in P1X as
opposed to being part of the network-based display options - produce a (limited)
number of pure matrix graphical displays such as frequency distributions which
have no connection with the spatial location of the zones. Spatial display of
matrices is described in 11.6.7.
The pure matrix graphics essentially duplicate functions which are also contained
within MX and we refer to section 10.12 for further information.
As mentioned in 11.4.1 P1X can handle up to three input matrix files; any of these
may provide the data-base for the graphical displays.
11.15 Convergence Statistics

The “Convergence” sub-menu provides a number of tables which indicate not only
the levels of convergence achieved both within the assignment and/or simulation
sub-models on their own but also the convergence within the simulation-
assignment loop. Generally speaking they duplicate information provided
elsewhere in .lpt files, SATLOOK outputs, etc. etc., but brought together into one
location. Most outputs are therefore described elsewhere within the manual.
A secondary objective of the Convergence options is to indicate where
convergence is not being obtained, e.g., to print out the 10 least well-converged
simulation nodes or the points where blocking back is changing most rapidly. The
intention is to help the user to discover how to improve convergence by tackling
the weak points.
5120257 / Apr 15 11-116

Section 11
The lists of “worst” locations may be supplemented by an option to “highlight” (see

11.6.5.4) the locations of the nodes where they occur, following which the option
“Hilite Nodes Loop Graphix” allows the user to automatically “loop” over those
nodes in order to demonstrate, using node graphics, potential problems.
The options included within Convergence are (assuming a simulation component
in the network):
♦ A summary of all important convergence statistics (from all networks if more

than one);
♦ Tables 1 & 2 summarising the simulation-assignment convergence statistics

(see 9.4.1 and 9.4.2);
♦ A list of the 10 worst nodes in terms of simulation convergence (8.3.3),

delays, “gaps”, capacities and assigned flows per simulation turn (9.9.1.2);
♦ A list of the 10 signalised nodes where signal optimisation can achieve

maximum improvements in V/C ratios (15.31.8);
♦ The 10 largest changes in blocking back factors (9.9.1.1);
♦ A list of all instances where MAXQCT and/or MAXDTP were applied (if any)
(8.4.6);
♦ “All (convergence) statistics” as printed within SATLOOK (11.11.8);
♦ “ISTOP Statistics” – basically Table 1 above in a slightly different format;
♦ A summary of the errors, warnings etc. (also available under Information)
♦ Accuracy statistics from the SAVEIT assignment
11.16 P1X: Technical Specifications
11.16.1 P1X Files

Channel Remarks
Number
1 The “MASTER” input network UFS/A/T file (Mandatory)
2, 3, 4 Further input network files (optional)
5 Various input ASCII files (Optional)
6 The output LPP line printer file. (Mandatory)
7 Output ASCII files (Optional)
8 A scratch UFX file (Optional; required for more than 1 input file)
9 Second matrix UFM input file(s) (Optional)
10 First matrix UFM input file(s) (Optional)
11 Plot file to be sent to a hard copy device (Optional)
12 The input graphical data file GRAF.DAT; see 11.3.1. (Mandatory)
5120257 / Apr 15 11-117

Section 11
13 P1X Help file (P1X.HLP) (Mandatory)

15/14 Terminal input and output (Mandatory)
16 Optional terminal
19 A GIS input file (Optional)
21 An input trip matrix file (Optional)
25 An output LOG file (Mandatory)
26 An Output UFS file (Optional)
28, 29, 30 Output UFM files (Optional)
31...34 Input UFC files for networks 1..4 (Optional)
37 Scratch direct access copy of the network.dat file (Optional)
38 Input network .dat file (Optional)
41...44 Scratch UFX files (Optional)
45 An input preferences file containing default parameter values
(P1X0.DAT); see 11.4.3.
48, 49 Scratch Direct Access GIS files (Optional)
11.17 SATLOOK: Technical Specifications
11.17.1 SATLOOK Files

Channel Remarks
Number
1 An input UFS/A file (Mandatory)
2 Second input UFS/A file
3 Third ditto
4 Fourth ditto (Optional)
5 A “preferences” file containing the control parameters as described in
11.17.2 below; (Mandatory)
6 An output LPL line printer file. (Mandatory)
7 An output ASCII KP file. (Optional)
8 A scratch UFX file used for both input and output when more than one
network file is input. (Optional)
13 SATLOOK.HLP Help File (Mandatory)
15/14 Terminal (both input and output) (Mandatory)
28 Output UFM files containing the inter-zonal
5120257 / Apr 15 11-118

Section 11
29 Skimmed matrices, e.g., time, cost, etc.,

30 or crow-fly distances. The first matrix is output to channel 28, the second
to channel 29 etc. up to a maximum of 3 matrices. (Optional)
31..34 Input UFC files for networks 1..4 (Optional)
40 4th skimmed output UFM matrix used by skim_all for 44444 time penalties
41 Scratch UFX file used for matrix skimming (Optional)
11.17.2 SATLOOK Preferences File (SATLOOK0.DAT)

For most current applications the preference or control file for SATLOOK should
be a “null” namelist file of the form:
&PARAM
&END
or, alternatively:
&PARAM
MODET = 1
&END
where MODET = 1 sets the interactive mode.

The full set of the “normal” parameters which may be set in satlook0.dat are listed
and annotated within the version of the file supplied with the release (or created
when you output a preferences file from SATLOOK). An explanation of each of
the parameters is given as a comment at the end of each record.
Other parameters are in fact available and may be used to run SATLOOK in a
batch mode but this is largely a historical application which is no longer
recommended. Documentation is given in Appendix X contained in the very old
ASCII manual files only (not to be confused with the current Appendix X).
11.18 SATDB: Technical Specification
11.18.1 SATDB Files

Channel Remarks
Number
1 An input UFS/A file. (Mandatory)
2,3,4 Further input UFS/A files. (Optional)
5 Input ASCII files; see 11.18. (Optional)
6 An output LPD line printer file. (Mandatory)
7 Output ASCII files (file type .dbd) (Optional, depending on whether any
ASCII “dump” options are invoked.)
8 A binary scratch file, both input and output (Optional) (required with >1
network file)
13 The SATDB help file (SATDB.HLP) (Mandatory)
5120257 / Apr 15 11-119

Section 11
15/14 Terminal (both input and output) (Mandatory)

21 An input trip matrix .ufm file (Optional)
26 An output UFS file (Optional)
28 An output select link trip matrix UFM file (Optional)
31 ... 34 Input UFC files for networks 1..4 (Optional)
42 A scratch randomised trip matrix UFM file used for both input and output
(Optional)
45 An input preferences file SATDB0.DAT; see 15.2 (Mandatory)
11.18.2 SATDB ASCII Data File Input

The option to read link data directly from an external .DAT file into SATDB is
described in 11.10.6.5. Under “standard” SATURN format these input files may
contain more than one data entry per record and the data is given in “free format”.
The input file must be formatted as follows, one record per link/turn:
Cols. 1 - 5 The link “A-node”
Cols. 6 - 10 The link “B-node”
Cols.11-15 The “C-node” if referring to a turn (0 or blank otherwise)
Cols.16 … The data value(s) in free format (i.e., the values may be either
INTEGER or REAL and separated only by spaces or commas).
If either entry A or B refers to a zone (centroid) this is indicated by a C in column 1

or 6.
Data is terminated by 99999 in cols. 1 - 5. Initial records containing text, e.g.
namelist records, or records which otherwise lead to formatting errors when input,
are ignored.
The “standard” format for link/turn definitions as used in a number of places
elsewhere in the Suite; e.g., the ‘66666’ count data input to SATNET, which
requires a single integer link data value in (fixed) columns 16 - 20 therefore
satisfies this specification.
N.B. The required format differs if DUTCH is TRUE whereby the node entries
occupy 10 columns, not 5, and the data values commence in Column 31; see
Section 15-20.
5120257 / Apr 15 11-120

Section 11
5120257 / Apr 15 11-121

Section 11
Supplementary Programs
12. Supplementary Programs

INTRODUCTION
12.1 Network Cordoning (SATCH)
The function of the network and/or matrix cordoning program SATCH is to
produce a sub-network and/or a sub-matrix of trips corresponding to a cordoned
area defined within a larger network.
12.1.1 Running SATCH

Figure 12.1 below indicates schematically how a cordon run may be incorporated
within a run of a larger network. Here the larger network is denoted by ‘net’ and
its trip matrix, by ‘trips’, while the sub-area or cordoned network and trip matrix are
‘cornet’ and ‘cormat’ respectively. File extensions follow standard conventions.
Thus the first step in the process is to run the full SATURN model for the ‘full’
network until convergence is reached in the normal way. If you wish to cordon a
sub-matrix the parameter SAVEIT should be T in the original network data file -
see note (13) in 12.1.4. SATCH then re-creates all routes used in the final
assignment (see 15.23.1) and notes which trips pass through the cordon points
defined in an input file (denoted cordon.DAT in 12.1). These trips are then
aggregated up to form a cordoned trip matrix in which the zones correspond to
either:
♦ ‘internal’ zones inside the cordon, or
♦ ‘cordon zones’ corresponding to exit and/or entry points about the cordoned
area
At the same time the program condenses the original network data file net.DAT so
that only those records corresponding to links ‘inside’ the cordon are retained in
full within the “cordon network”. Nodes at the outer end of cordon links are
converted into external nodes and, optionally (ADDXZ = T), the “cordon” zones
are added, both being within the appropriate data segments in the network file.
The cordoned network file - denoted ‘cordon.KP’ in 12.1 - may then be fed into the
network build program SATNET (either directly or, commonly, with additional
editing by the user plus a change of extension to .DAT), following which the
iterative simulation/assignment loop can be invoked using the cordoned trip matrix
‘cormat.UFM’.
Note that the (compulsory) control file, cordon.dat in Figure 12.1, is best prepared
initially using the mouse-based options in P1X in order to guarantee that the
cordon is ‘watertight’; see 11.13. However it may be necessary to ‘edit’ the
resulting file in order to select some of the other options described below. Indeed
most of the functions within SATCH may also be carried out within P1X; see
12.1.5.
5120257 / Apr 15 12-1

Section 12
Figure 12.1 - Use of SATCH
12.1.2 SATCH Files

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

Section 12
Channel Number Remarks

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

This input file (which is mandatory) contains all the “control” information required
by the program in addition to the network and matrix information which is input via
the network .ufs and matrix .ufm files.
RECORD 1 - SATCH NAMELIST OPTIONS (&PARAM) (MANDATORY)

Option Type Default Interpretation
MIDDLE Integer 0 A node number which is inside the cordon (in order
to distinguish ‘inside’ from ‘outside)
NOMAD Integer 1 The ‘matrix sub-level’ to be used if working with
MUC assignment if ALLUC = F ; see 12.1.6
MODET Integer 1 If ne 0 diagnostic messages are output to the
terminal
DEMAND Logical FALSE If TRUE any output trip matrix is in terms of ‘demand
flows’ (as is the input matrix); if FALSE the output
matrix is in ‘actual flows’. See 12.1.9.
DONET Logical TRUE If TRUE a network DAT file is output to channel 7
using data read from channel 8.
DOMAT Logical TRUE If TRUE a UFM trip matrix file for cordoned network
is output to channel 4.
DOFCF Logical FALSE If TRUE output an “edited” .UF network with
simulation nodes outside the cordon marked as
“fixed”. See 12.1.10.
PRINT Logical TRUE If TRUE print the cordoned trip matrix to the line
printer.
ADDXZ Logical TRUE If TRUE add external zones at the “outer” end of
each cordon link. See note 8), 12.1.8.
AZONE Logical FALSE If TRUE the zone numbers at the cordon points are
set equal to the ‘outer’ nodes which defined the
cordon link; see note 8), 12.1.4
SZONE Logical FALSE If TRUE all the zone numbers in the output cordon
network are numbered sequentially,i.e., 1, 2, 3 …
with the cordon point zones at the end. See note 8),
12.1.4.
INCLUD Logical FALSE If TRUE the output cordoned network file has each
5120257 / Apr 15 12-3

Section 12
Option Type Default Interpretation

data segment 11111, 2222, etc. etc. referenced by a
$INCLUDE file with one new file created per data
segment. See note 10), 12.1.4
SPINE Logical FALSE If TRUE a matrix of trips entering or leaving a ‘spine’
of nodes from NODES to NODEF is built. See notes
6) and 7) in 12.1.4.
USESPI Logical FALSE If TRUE (and the full network was built with SPIDER
= T) then the trip matrix calculations use a “hybrid”
spider network which is much faster. See note 13)
below and 15.56.7.2.
USEUFO Logical FALSE If TRUE matrix cordoning will use a .UFO file in
preference to .UFC if both are available (where the
default is that set on the input .UFS file). See
12.1.12.
NODES Integer 0 The ‘start’ node which defines a set of ‘spine’ links
and…..
NODEF Integer 0 The ‘finish’ node in a ‘spine’ – see note 6, 12.1.4
NODEM() Integer 0 The set of “intermediate” nodes in a spine between
NODES and NODEF. See note 7, 12.1.4.
NEWMU Logical FALSE If TRUE nodes at the “outer” ends of cordon cut
G links may be renamed within the new data file. See
12.1.10
ALLUC Logical TRUE If TRUE under multiple user classes a cordoned
matrix is produced separately for every user class. If
FALSE NOMAD defines a single user class. See
12.1.6
FURNES Logical FALSE If TRUE the output trip matrix is ‘furnessed’ to match
the assigned flows; see 12.1.8
INTRAS Logical FALSE If TRUE intrazonal trips from the trip matrix are
included in the output trip matrix; see note 16, 12.1.4
RECORDS 2: CORDON LINKS (OPTIONAL - SPINE = F)

A separate record must be included for each link in the cordon surrounding the
inner network, format as follows:
Cols. 1-5 The A-node of the link
6-10 The B-node of the link
Notes:
a) The link can be either one-way or two-way; if two-way, it only needs to be
defined once.
b) Either node may be defined as the A-node, but the program will later redefine
the A-node as being the node which is ‘inside’ the cordon and the B-node as
being on the ‘outside’.
5120257 / Apr 15 12-4

Section 12
c) The links are those that are ‘cut’ by the cordon as opposed to a continuous
set of links that are themselves the cordon.
d) If DUTCH is TRUE in the input SATURN UF file then the nodes are defined in
columns 1-10 and 11-20.
e) Centroid connectors are not valid cordon links and are ignored by the program
in defining the cordoned network.
f) Either simulation or buffer links are permitted as cordon links.
RECORD 3 (MANDATORY) (OPTIONAL - AS 2)

99999 in columns 1-5 to signify the end of the cordon data records.
RECORD 4 MATRIX TITLE (OPTIONAL - DOMAT = T)

A title for the cordoned matrix in columns 1 to 72.
END OF THE CONTROL FILE INPUT

An example of a control file is given below:
&PARAM
MIDDLE=43,
&END
20 21
47 48
47 50
50 51
31 52
54 32
56 33
57 35
43 42
42 41
41 40
13 12
99999
NEW MATRIX TITLE
12.1.4 General Comments

1) In order to identify that section of the full network which is within the cordoned
area the program builds a ‘tree’ out from the node MIDDLE but not going
beyond any of the cordon links. In other words it tries to reach as much of the
network as it can, starting at MIDDLE but without going through any cordon
links. At this stage network nodes and links will be either ‘inside’ or ‘outside’
the cordon. By definition the links forming the cordon are ‘inside’.
Note that in building the tree the program only uses ‘real’ links; i.e., centroid
connectors are excluded. Hence in defining the cordon the user need not
define any centroid connectors which apparently cross the cordon.
2) The process fails if there are any ‘holes’ in the cordon by which the tree can
escape from the cordon and thereby reach all (or most) nodes in the network.
This is indicated by the cordoned network being much bigger than expected.
5120257 / Apr 15 12-5

Section 12
Holes can be detected by analysing the printed set of ‘back-nodes’. If

therefore you start with a node which should definitely be outside the cordon
by tracing its path back to MIDDLE by looking up successive back-nodes it
should become obvious where that path crossed the desired cordon.
The tree is printed automatically if ALL nodes appear to be inside the cordon,
since in that case it is obvious that there must be a hole.
3) The tree is built using both simulation and buffer links (if both exist or else
clearly just the one type). The cordoned network includes both simulation and
buffer components as appropriate. It is, however, possible to cordon a
combined simulation/buffer network such that the cordoned network is either
all buffer or all simulation.
4) A zone in the full network will be ‘inside’ the cordon network if at least one of
its connected ‘real’ nodes can be reached from MIDDLE; it might therefore
‘straddle’ the cordon and have outside connections as well, but these will be
excluded.
5) In defining cordon links the A - and B-node may be in either order. However
once the tree from MIDDLE has been built the program re-defines their A and
B numbers so that the A-node is inside and the B-node outside. The cordon
zone is therefore connected to the B-node.
6) SPINE represents an alternative and simpler method to define cordons than a
full set of cut links. The SPINE option is used to isolate all trips entering or
leaving a stretch of road such as A-B-C-D-E-F in the diagram below. Here the
line indicates where the cordon is drawn so that nodes Z, H, J etc. all
represent external zones outside the cordon and a trip in the cordoned matrix
from, say, J to S, corresponds to a trip which enters the road at B and leaves
at E. Information of this nature might be useful if, say, A-F were a motorway.
7) Under the normal option it would be necessary to set MIDDLE to, say, D and
to specify a full set of cordon links Z-A, H-A, etc. However under the SPINE
option it is only necessary to specify the two nodes at either end of the ‘spine’,
in this case nodes A and F (which are set as NODES and NODEF
interchangeably). The program then uses the node co-ordinates in order to
‘interpolate’ nodes B, C, D and E as the most direct route between A and F;
see Section 15.18. (See also 11.13.5 in P1X where the concept of a “spine”
may be extended to allow a series of links which are not in a straight line.)
If the interpolation is likely to be “problematic” (i.e., the route from A to F does
not follow an obvious straight line) then a number of intermediate nodes
between NODES and NODEF may be defined. Note that NODEM is a
subscripted integer variable so that, for example, one would set NODEM(1) =
C, NODEM(2) = E to set C and E as intermediate nodes.
5120257 / Apr 15 12-6

Section 12
Under SPINE the parameters DOMAT and PRINT are automatically set to
TRUE since the only reason for using these options is to look at the trips, and
DONET is automatically set to FALSE since the network itself would be of
little interest.
8) If ADDXZ = T (its default) new cordon zones are created at the outer end of
each cordon link, for which there are various options for creating their zone
names.
(i) If the logical parameter AZONE is FALSE (its default) then their numbers
start at the first available multiple of 100 plus 1 above the highest zone
number in the full network. Thus if the full network had zones up to number
437 the cordon zones would be numbered 501, 502, ...
(ii) Alternatively if AZONE is TRUE then the cordon point zone numbers are
set equal to the outer cordon node number (the ‘B-node’ under note 5 above).
This option is very useful if you only wish to ‘look at’ the cordoned trip matrix,
in which case referring to a cordon point as, say, zone 21 if it was at node 21
is more informative than referring to it as zone 501. However this option will
create severe problems if you wish to cordon both a matrix and a network to
run together in SATURN since the network will assume that the zones are
sorted in order of increasing zone number in the trip matrix whereas under
AZONE they need not be; hence cordon trips may enter/leave at the ‘wrong’
points when assigned.
(iii) If SZONE = T (independent of the value of AZONE) then the cordoned
zones are numbered sequentially 1, 2, 3… with the internal zones numbered
first followed by the cordon point zones. Note that the order in which the
zones appear is the same as above; the only difference is in the zone names
used.
9) Having first identified all nodes which are inside the cordon, and if DONET is
TRUE, the program creates the cordoned network file by reading through the
network data records input on channel 8 and copies to the output data file on
channel 7:
(i) Any ‘general’ records, e.g. the &PARAM cards;
5120257 / Apr 15 12-7

Section 12
(ii) Any records referring to internal nodes and/or links within data segments
11111, 22222 etc. etc.
Note the 88888 data records which define generalised costs etc. are copied
verbatim to the output data file since their contents are not node/link specific.
10) If the Namelist parameter INCLUD = T the new 11111 etc. data segments are
not included directly within the new data file but in a series of $INCLUDE files.
Thus if the main output file is control.KP then the $INCLUDE files will be
named control_11111.dat up to control_77777.dat (the 88888 data records
are all within control.KP) and the 11111 segment within control.KP will contain
the single record $INCLUDE control_11111.dat etc. etc.
11) The network reduction ‘logic’ is not 100% perfect. For example, if you cordon
a joint simulation/buffer network so as to totally exclude the simulation
network you will (probably) get output records which include: 11111
immediately followed by 99999 which would imply that simulation data is
included (the 11111 card) but then no data appears. SATNET might - with
some justification - take umbrage at this apparent thoughtlessness on your
part.
Users may therefore need to further edit the data file before input to SATNET.
In particular they will probably wish to change the network title (which is
copied verbatim by SATCH).
12) Trips which follow routes that criss-cross in and out of the cordoned network
will appear as multiple trips in the cordoned matrix. For example, the trips
from S to T below would be counted as both S-A (internal zone to cordon
point), B-C (cordon to cordon) and D-T (cordon to internal zone) in the
cordoned matrix.
13) All routes used in the assignment are re-created and traced and the trips
added to the trip matrix appropriately factored. Thus, if the assignment
assigns 12% of the entire trip matrix to the free-flow routes, only 12% of Tij
would be included along these routes in the cordoned matrix.
5120257 / Apr 15 12-8

Section 12
Note that the original network file must have set the parameter SAVEIT to
.TRUE. so that a network UFC file would have been created so that SATCH
can re-create the trees built at each stage of the assignment.
If USESPI = T (and SPIDER = T for the original network) then the O-D routes
are re-created using a “hybrid network” formulation which uses both
aggregated and original network links where appropriate and which reduces
the (assignment only) CPU time by factors of around 10; see 15.56.7.2. At the
same time zero-flow spider links are eliminated from the path building and
tracing (15.56.5.3)
14) Note that the ascii control file specifying, inter alia, the links in the cordon may
be conveniently created using mouse based options within P1X and that it is
possible using this facility to check visually for ‘holes’ in the cordon. See
Section 11.13.
15) If the input network .dat file contains $INCLUDE records referencing other
files the data from these files will be included as necessary in the output
cordoned .dat file but all within the file, not as externally referenced
$INCLUDE files.
16) Any intra-zonal cells in the “full” trip matrix are automatically included as intra-
zonals in the “cordoned” trip matrix if the parameter INTRAS = T. Clearly this
only applies to internal zones; external zones at cordon points may, in
principle, have intra-zonals but only if, in the original full network, paths would
have entered and left by the same link (thereby, in effect, executing a U-turn).
17) Bus routes in the “full” network are truncated such that only that portion of the
route which is within the cordon is retained. If FOZZY = T (so that
interpolation between non-adjacent nodes is permitted) then only those nodes
that are included within the full network definitions are included within the
cordoned route definitions (with the exception that any entry and exit points at
cordons are automatically included).
Note, however, that if a route exits the cordoned network and later on re-enters
the cordon only the first segment of the route is included. (Unlike routes used by
the assigned trip matrix; see note 10 above.
12.1.5 Running SATCH within P1X

SATCH is basically a “batch” program; however most of the functions available
within SATCH are also available within P1X, in addition to the ability to define a
cordon as mentioned in note 14, Section 12.1.4.
Thus having defined a cordon in P1X options exist (see 11.13) to:
♦ Produce an output cordon.dat network file as under the DONET option within
SATCH.
♦ Produce an output cordoned .ufm trip matrix, analogous to DOMAT (but

probably with smaller limits on the maximum number of output zones).
5120257 / Apr 15 12-9

Section 12
12.1.6 Multiple User Classes within SATCH

With SATURN 10.1 the parameter ALLUC = T (in conjunction with DOMAT = T)
outputs a stacked .ufm trip matrix with one level per user class.
The number of levels is fixed independently of how the original trip matrix defined
trips by user class. For example, the original might have been a single-level
square matrix with user class matrices defined as fractions of the basic matrix
within the 88888 records (see 6.11). However, since the routes used by each
user class will (presumably) be different, so too will their cordoned matrices be
different; hence it is no longer possible to express them as fractions of a single
cordoned matrix.
Furthermore, if an original user class were defined as a fraction of a full matrix
then that fraction is included directly in the cordoned matrix. Thus if the original
full matrix contained 10 trips in an ij cell with 30% allocated to user class 2 then
the cordoned matrix for class 2 would contain 3 trips in the appropriate cordoned
cell (assuming of course that those trips went through the cordon).
This has further implications for the way in which the 88888 records are defined in
the cordoned network.dat file since each user class must now be allocated to its
numerically equal level in the stacked matrix with a fraction of 1.00. Thus, in the
example above of user class 2 being 30% of a full matrix, in the full network.dat
file it might have been assigned to level 1 with a fraction 0.30; in the cordoned .dat
file the equivalent values would be 2 and 1.00.
Some caution on the part of users is required here since the changes to the 88888
records may or may not be carried out automatically depending on whether or not
the network and matrix are cordoned at the same time. Thus in SATCH if DOMAT
= T, DONET = T and ALLUC = T then the program will "know" to make the
changes in the 88888 records; otherwise, and this includes all cordon operation in
P1X, it will not know whether you want those changes done.
As a final point of confusion note that if ALLUC = F and only a single user class
matrix as set by NOMAD is output then the class specific factor is not applied and
the 888 records do not need amending. Nonetheless it would then be up to the
user to produce a full set of class-specific cordoned trip matrices, to add/stack
them together as desired and to set the 888 records accordingly. A potential mine
field which the use of ALLUC is designed to deal with. Its use is therefore highly
recommended.
12.1.6.1 Pre-Selecting Individual User Classes on the Command Line

Post 10.9.24 it is possible to over-ride the choice of the user classes matrices to
be output by setting a single user class on the command line (12.1.12); e.g.,
SATCH net control ftij ctij NOMAD 2
requests that the only a single square cordoned matrix for user class 2 be output,
independent of which values have been set for ALLUC and NOMAD within
control.dat. In addition the filename of the output matrix will have 2 appended to it;
e.g., the output matrix will be ctij2.ufm, not ctij.ufm.
5120257 / Apr 15 12-10

Section 12
In addition, if NOMAD > 1, then no output network .dat file is created on the
assumption that the option is being used within SATCH_MC so that an output
network .dat file is only created once when SATCH is called with NOMAD = 1.
The main reason for adding this option is so that several runs of SATCH may run
simultaneously using different processors, one per user class, as controlled by the
batch file SATCH_MC. See 12.1.12 and 15.53.2.6. Since each run produces a
separate square matrix ctij1.ufm, ctij2.ufm, … these may be stacked into a single
MUC matrix at the end.
12.1.7 Factored Trip Matrices (E.g., GONZO)

If the input trip matrix has been factored prior to assignment due to either: (a)
GONZO ne 1.0 or (b) a user-class specific factor having been set under the 88888
network .dat file records, then the output trip matrix will implicitly include these
factors.
For example, if GONZO = 1.5 and the total origin trips in the input trip matrix from
a zone inside the cordon equal 100 then the actual flow assigned from that origin
will be 150. Thus in the cordoned matrix the origin flows for that zone will be 150,
not 100. It follows that, in the above example, GONZO will need to be set equal to
1.0 in the cordoned network .dat file, otherwise the assigned flows from that origin
will be 150 x 1.5 = 225 rather than 150. Thus SATCH (post 10.6) will
automatically re-set GONZO to 1.0 in the output network (.kp) file (although it is
worth the user checking that has been correctly done).
Similarly any further user-class specific factors implied by the 88888 records will
also be re-set to 1.0 in the output file and the factor included in the appropriate
level of the stacked cordoned matrix. See also 12.1.6 above. This problem occurs
frequently if the input trip matrix (level) represents vehicles/hr and the 88888
factor converts to pcus/hr.
N.B. Similar problems occur with SATME2; see Section 13.1.14.
12.1.8 Furnessing the Output Trip Matrix

If the parameter FURNES = T (and DOMAT = T as well) the program, having
calculated a cordoned trip matrix, checks whether the origin / destination flows in
the cordoned matrix correspond to the assigned flows in the full network. For
example, the origin flows at a “cut link” entering the network should equal the
original network flows on that link. Differences between the two may be due to
errors in re-tracing the assignment routes (see 15.23).
The output trip matrix is corrected by a process known as “Furnessing”, whereby
the matrix row and column totals (origin and destination flows) are progressively
factored to balance the required totals until a satisfactory degree of convergence
has been achieved. Statistics detailing the level of changes made and the
convergence achieved are printed by the program.
If DEMAND = F, i.e., if the output trip matrix is based on “actual flows” (see
12.1.9), then it is not possible to simultaneously satisfy both row and column totals
due to the possibility of trips being queued inside the cordoned network so that the
summation of the actual flows leaving the cordoned network may be less than the
5120257 / Apr 15 12-11

Section 12
summation of those entering the network. In this case the output matrix is “singly
constrained” to match the actual origin flows and convergence is not an issue.
Note, therefore, that if DEMAND = F and FURNES is “on” we would not
necessarily expect the destination total flows in the cordoned trip matrix to match
the actual flows at the cordon points (see Tables 1 and 2 in the .LPC file). There
are two reasons for this: (a) errors in retracing the original path flows and, (b),
ignoring any flow metering due to queues between the cordon origins and
destinations.
12.1.9 Demand versus Actual Trip Matrices (DEMAND = T/F)

If the namelist parameter DEMAND is set to T the trips which are included in the
output trip matrix will always be based on the demand flows in the full network as
opposed to the actual flow. For example, if a particular OD path has been
assigned a flow of 100 pcu/hr but that flow will have been reduced to 80 pcu/hr by
the time it reaches a cordon cut link (i.e., a new zone in the cordoned network)
due to queues en route in the full network then, if DEMAND = T, 100 trips will be
added to the cordoned matrix; otherwise, if DEMAND = F, 80 are added.
In general, therefore, for most applications of cordoning DEMAND = F is the most
natural choice since it provides a better estimate of the “true” flows for subsequent
re-assignment to the cordoned network. However, for certain applications, the full
demand trip matrix may be of interest.
We note that the cordoned trip matrix will always be treated as a “demand” matrix
when SATURN is run on the cordoned network whether or not DEMAND = T or F
when it is created in the sense that all trips in the matrix will be assigned starting
at their (cordon point) origins. Hence the (current) choice of DEMAND = F as the
default (but, N.B., prior to 10.9 the default was T for largely historical reasons).
12.1.10 NEWMUG: Alternative names for Cordon Cut Nodes

An option introduced in release 10.9 allows the nodes at the outer end of each
cordon cut link to be assigned a new node number and location. As normally
applied, if the cut link is A-B, then the outside node B is effectively redefined in the
cordon network as a node C which is located halfway between A and B.
The main objective of this option is to allow several cordoned sub-networks to be
created which “span” the full network so that a link A-B might be used to define
both a cordon “to the left” of A-B and also “to the right” of A-B, in which case A-B
(and its reverse B-A) would appear in both sub-networks. However by creating a
mid-link node C then links A-C/C-B would be in one sub-network and B-C/C-B in
the other.
The option was created for a specific application required by Atkins in 2010 and
has not therefore been fully documented. Interested users should therefore speak
to Atkins for further details.
12.1.11 DOFCF: Creating a FCF Binary file

The option when DOFCF = T whereby parts of the existing simulation network are
converted into fixed cost-flow curves for use in another network. See 15.1.4.
5120257 / Apr 15 12-12

Section 12
12.1.12 Tracing O-D Routes: Choice of .UFO or .UFC

The tracing of the originally assigned O-D routes in order to create the cordoned
matrix may use one of two methods: using a .UFO file or using a .UFC file. See
15.23.6 for a general description of the differences between the two methods.
UFO calculations are considerably faster than UFC but, clearly, require that a
.UFO file exists.
Note that the .UFO file will only exist if – under FW assignment - either SAVUFO =
T in the network .dat file or SATUFO has been called post SATALL or if OBA
assignment was used in the first place.
Provided that a .UFO file exists the choice of UFO or UFC is determined by the
namelist parameter USEUFO = T or F respectively where the default value of
USEUFO is set in the original network .dat file (6.3.1) but it may be over-written
within the SATCH control file (12.1.2).
12.1.13 SATCH Batch Files

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

The relative offsets between intersections can be readily set on-line in response to
traffic conditions. In practice, this needs flows to be continuously monitored and
optimal solutions updated. On the other hand, the problem is more difficult in
modelling for a future year or an altered network since there are no observable
flows on which to base signal settings. The central hypothesis is that optimum
5120257 / Apr 15 12-13

Section 12
network offsets can be determined which, to a good approximation, are

independent of any resulting changes in flow. This assumes the selection of an
offset which minimises total vehicle delay through an intersection. The position of
this minimum (and indeed of a range of minima), when total delay is compared to
potential offsets, is expected to have a fixed location since offsets are essentially
determined by the travel time from the upstream intersection.
This is not to say that the offset is constant for all of the approaches to an
intersection, but that a re-assignment of traffic flows will cause an adjustment of
flows to support the offset that has been selected. Increasing the flow on an
approach due to an improved offset may lead to a demand for more green time
but this should not affect the offset since travel times remain constant.
The conclusion is that an iterative sequence of assignment and offset optimisation
will converge to give a well-defined set of offsets which can be used with
confidence to model a network.
SATOFF is based on the above hypothesis as proposed by:
♦ B.G. Heydecker Transport Studies Group University College, London
♦ D. Van Vliet Institute for Transport Studies University of Leeds
♦ T. Van Vuren Institute for Transport Studies University of Leeds
For more detailed information copies of the paper ‘Optimal Signal Offsets for
Traffic Assignment Networks’ presented at the Engineering Foundation
Conference on Traffic Control Methods, Santa Barbara, 1989 by the above
authors is available on request from D. Van Vliet.
12.2.2 Running SATOFF

The order of running programs with SATOFF incorporated is illustrated in Figure
12.2. Thus starting with a ‘base network’ net.DAT in which the offsets are set to
some arbitrary values a full run of SATURN is carried out, resulting in a file
net.UFS containing the ‘best’ set of assigned link flows. This file is then input into
SATOFF which calculates optimum offsets consistent with the assigned flows and
incorporates those new values into an output file net.UFA.
5120257 / Apr 15 12-14

Section 12
Figure 12.2 - Use of SATOFF
(The box denoted by SATASS / SATSIM is, in current versions of SATURN,

simply an application of the single program SATALL which carries out both
assignment and simulation.)
At this point two alternative ‘loops’ may be used: The ‘inner’ loop involves re-
running SATSIM immediately in order to obtain a better overall simulation of the
network flows which may in turn, by repeating SATOFF, lead to a slightly different
set of offsets.
By contrast the ‘outer’ loop returns the new offset to a full re-run of SATALL,
resulting in a new set of both assignments and simulations. This in turn may
result in new optimum offsets, but the central feature of the hypothesis above is
that relatively stable offsets may be obtained after a single optimisation (with or
without possible repetitions of the inner loop). We note that the outer loop is
virtually identical to a single “NIPS” loop within SATALL internally; see 9.12.2.
Note that the ‘outer’ loop requires SATSIM to be run prior to SATALL in order to
update the cost-flow curves output from the simulation, otherwise the first
assignment within SATALL will simply give the same flows as the last assignment
of the previous SATALL and it will converge immediately. (Indeed with the latest
10.5 versions of SATOFF it is possible to include the re-simulation within SATOFF
5120257 / Apr 15 12-15

Section 12
itself such that an updated and re-simulated .ufs file is produced directly; see
12.2.4.)
Hence the ‘final’ set of results is obtained after the repeated run of SATALL with
the optimised offsets.
The above sequence could be run using individual program “dos” commands as
illustrated by:
Satnet net
Satall net trips
Satoff net
Satsim net
Satall net trips RESTART
Where we note that the RESTART option is used in order that the second run of
SATALL takes its input from the file net.ufs rather than, as in the first run, a file
net.ufn. It may be usful to rename the output .ufa file each time SATOFF is run as,
say, net2.ufa etc.
To produce a network .dat file containing the updated signal offsets (since
SATOFF only produces updated .uf files) use the network edit options within P1X;
see 9.11.13.2. Equally one may wish to make use of an output .rgs file (see
9.11.14) to transfer the optimised offsets between networks.
It must be stressed that SATOFF and the associated operating rules are new and
that therefore some caution in its use is to be recommended. However
experience to date does suggest that it can produce stable and realistic offsets
and that therefore it can be used with some confidence to overcome the problem
of evaluating future and/or alternative networks within which the offsets are
indeterminate.
12.2.3 MANOFF: Master Node for OFFsets

An added feature of SATOFF introduced with SATURN 10.4 allows the offset of a
particular signalised node to be fixed and all other offsets taken relative to that
node’s definition. Note that, since the “zero point” for all offsets is arbitrary, fixing
one particular offset has no effect on the overall simulation.
The offset for the master node “MANOFF” is that defined in the original network
.dat file and need not be zero (although it might make more sense if it were). At
the end of every run of SATOFF if the offset of the master node has been
changed from 0 to, say, 15, then every offset in the network is reduced by 15
seconds (with the appropriate “wrap around” if that makes an offset negative).
MANOFF may be quite useful when comparing two slightly different networks to
judge the “true” differences between offsets.
MANOFF is defined as part of the &PARAM inputs (6.3) to the network and
cannot be over-written within SATOFF since SATOFF does not (at the moment)
have any input control files. A value of MANOFF = 0 (the default) implies that the
offsets are allowed “to float”.
5120257 / Apr 15 12-16

Section 12
If the offsets are being optimised within P1X it is possible to re-set MANOFF at
that point. The definition of MANOFF – and its fixed offset – is retained within the
various network .uf* files.
WARNING: Using MANOFF when there is a range of cycle times between
different signalised nodes is not recommended since nodes with different cycle
times cannot, as far as the modelling assumption within SATURN are concerned,
be properly co-ordinated; the concept of a relative offset in those circumstances is
not well defined. Therefore, post 10.9.22, only signalised nodes with the same
cycle time as MANOFF have their offsets adjusted.
12.2.4 Including an Automatic Re-simulation within SATOFF

In SATURN Version 10.5 the batch file satoff.bat and the program itself have been
modified so that a “command line” of the form:
SATOFF net1 net2
Will (a) output a file net2.ufa from SATOFF rather than net1.ufa, and (b) run
SATSIM with net2.ufa as input and net2.ufs as output in order to automatically
carry out the necessary steps for either the inner or outer loops in Figure 12.2.
12.2.5 Alternative Offset Optimisation Procedures

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

(A) SATOFF FILES
Channel Remarks
1 An input UFS file. (Mandatory)
2 An output UFA file containing new offsets to be passed to
SATSIM. (Mandatory)
6 An output LPF line printer file. (Mandatory)
15/14 Terminal (output only) (Mandatory - unless MODET= 0)
(B) SATOFF DATA INPUT: None required
12.3 Direct Examination of UF Files (DALOOK)

DALOOK is essentially designed for the use of programmers to debug programs.
It enables the user to interactively determine the value of any individual item in a
binary UF file. For example it could tell you that the 325th element in the array
coded 4503 on a UFS file (which contains assigned link flows) is 1324.56 - what it
does not tell you is which link this volume corresponds to (although by looking at
other elements in the file this information could be determined). For ‘normal’
5120257 / Apr 15 12-17

Section 12
users the same information is much more conveniently supplied by SATDB which
will not only give values for all items in an array such as the link volumes in 4503
but also lists it in a table along with the link A-node and B-node. On the other
hand DALOOK is more convenient to examine the contents of ‘non-link-based’
data arrays.
To run the program using standard procedures type:
DALOOK LIVNET
or
DALOOK I
to run fully interactively.
12.4 Direct Comparison of UF Files (DACHEX)

DACHEX enables users to compare two UF files element by element and to print
out summary statistics of which elements differ and by how much. Like DALOOK
it is essentially a programmer’s tool used, for example, to see whether or not
making a change to a program has any effect upon the output.
Users may find useful applications for it but, to a large extent, the same functions
are catered for by other programs; e.g. MX compares two matrix files element by
element and produces more ‘user friendly’ output statistics.
12.5 Transferring UF files (DADUMP and DALOAD)

DADUMP and DALOAD are two short complementary programs which are
intended to enable users to transfer binary or UF files (e.g. network or matrix files)
between computers. Thus DADUMP transfers the contents of a UF file into a card
image or text file while DALOAD converts a text file into a UF file.
To transfer a file run DADUMP on the ‘donor’ computer, transfer the resultant text
file to the ‘recipient’ computer and re-build the UF file using DALOAD. The use of
the intermediary text file is necessary since generally speaking it is very difficult to
transfer binary files between different computer systems and/or operating systems
(although not necessarily impossible - if you can do it that way, do it in preference
to using DADUMP/DALOAD).
Using the standardised control procedures type:
DADUMP LIVNET
on the donor followed by (on the recipient computer):

DALOAD LIVNET
The intermediate file will be named LIVNET.KP.

Note that the .KP file is almost certainly much larger than the base UF file.
The procedure is generally satisfactory for the transfer of files, say, from a fast
mainframe processor to a PC for the further analysis of results, e.g., in P1X. If,
however, further iterations are to be performed on the recipient computer the KP
transfer process may result in a loss of accuracy due to rounding errors.
5120257 / Apr 15 12-18

Section 12
12.6 SATPIG: Generating Route Flows
12.6.1 Introduction
SATPIG is a relatively ad hoc program designed to produce a file of origin-
destination route flows from a SATURN assignment, in particular to facilitate
interfaces with micro-simulation network analysis programs such as DRACULA
which require as input a file describing the number of ij trips per distinct route as
opposed to a trip matrix which gives total trips independent of route. It follows the
general principles for re-constructing routes using the SAVEIT option as described
in 15.23.
12.6.2 The SATPIG batch file

To run SATPIG use a command line such as
SATPIG net trips KR control
Where: net.ufs Input post-assignment network file;
trips.ufm Input trip matrix (see 12.6.4)
net.LPG Output line printer file
net.trp Output route file (TRPFOR = T)
or
net.kp Output route file (TRPFOR = F)
control.dat Input control file (Default: satpig0.dat)
12.6.3 SATPIG Control Parameters

The control file contains a standard Namelist &PARAM input set with six control
parameters: five LOGICAL parameters TRPFOR, CSVFOR, NAMES, ALLOD and
UTURNS (Default = T, F, T, F and F respectively), one integer parameter NOMAD
(default 0) and 2 real parameters FPHMIN and PODMIN (default 0.01 and 0.1
respectively) whose functions are explained next.
TRPFOR
The route flow data is embedded within the .kp/.trp files with one set of records
per O-D pair with positive flow ordered by increasing destination within increasing
origin. The format (and extension) used is determined by the LOGICAL
parameter TRPFOR such that:
♦ If TRPFOR = F each set of records consists of:
RECORD 1:
Cols 1-10 Origin zone (name)
11-20 Destination zone (name)
21-25 User class number (NOMADS>1)
26-30 Route number 1, 2, 3 for the O-D pair
5120257 / Apr 15 12-19

Section 12
31-40 Route flow (pcu/hr) in format F10.2 (i.e. decimal in

column 38)
41-50 Number of nodes in the route
RECORD(S) 2:
The series of nodes making up the route in format I10, i.e. up to eight nodes per
line, 10 columns each.
♦ TRPFOR = T each set of records is output using the .trp format conventions
such that:
RECORD 1:
Cols 1-10 Origin zone (name)
11-20 Destination zone (name)
21-25 User class number (NOMADS>1)
26-35 Route flow (pcu/hr) in format F10.2 (i.e. decimal in
columns 33)
36-45 Fractional route flow in format F10.6
RECORD(S) 2:
The series of nodes making up the route is in free format and enclosed within
leading and trailing % symbols. I.e., each node is separated from its neighbour by
a space with up to 80 characters per record; multiple records are used if
necessary.
CSVFOR
If .TRUE. the output data contains the same basic data entries as per TRPFOR =
T but with one variable-length record per path in CSV format.
N.B. CSVFOR and TRPFOR cannot both be T at the same time; if both are T then
TRPFOR takes precedence and CSVFOR = F.
NAMES
If .TRUE. all output files use node “names” as opposed to sequential numbers.
ALLOD
If .TRUE. all O-D pairs are included even if they have zero trips in the trip matrix
cell, in which case the FPHMIN criterion below can never be satisfied. However if
their nominal fraction of use exceeds PODMIN (see below) they are included.
If none of the nominal routes satisfy PODMIN and/or FPHMIN the “best” single
route – as defined by having the maximum usage - is always included unless
PODMIN is negative (see below).
5120257 / Apr 15 12-20

Section 12
UTURNS
If .TRUE. only paths which pass through the same node twice (e.g. a U-turn) are
recorded on the output file.
FPHMIN
Any route flows less than FPHMIN are ignored in the .lpg and/or .trp outputs.
PODMIN
Any routes with fractional flow greater than PODMIN of the total flow are included
whether or not the FPHMIN criterion is satisfied or not. Thus the criterion for
inclusion is an either/or rule of both absolute and fractional flows.
Note. However, that if PODMIN is set negative then it is never invoked and
whether or not a path is included in the output file is determined purely by the
ALLOD and FPHMIN rules.
NOMAD
If positive NOMAD specifies the particular user class to be analysed for a network
with multiple user classes; if zero all user classes will be analysed.
Notes:
1) Under method (i) the origin and destination zone names are included as the
first and last entries in the route names under record 2, but under (ii) only the
“real” nodes are entered under record 2.
2) If there is only one route used per ij pair then the route number on record 1 is
simply 1; otherwise it increases by 1 each set.
3) Route flow records are terminated by a blank line.
4) Multiple user classes are sorted such that all O-D records for class 1 come
first (with a 1 in column 25), followed by all class 2 records (2 in column 25),
etc. etc.
The program is still very basic; forward requests for extra facilities to DVV.
12.6.4 The Role of the Trip Matrix in SATPIG: Restricted O-D Pairs
We note that the input trip matrix used within SATPIG need not necessarily be the
same trip matrix as that used during the assignment, although logically and
generally speaking it should be. Its role is essentially to define the total number of
trips to be divided between the various paths identified for each O-D pair.
However it has a possible secondary use which is to restrict the O-D pairs
analysed in that if an O-D cell in the trip matrix is zero – or if an entire row is zero
– then that O-D pair/origin is not analysed. Thus if you are only interested in
generating a representative set of paths rather than the complete set this may be
done by factoring the non-required areas of the trip matrix to zeros prior to running
SATPIG.
5120257 / Apr 15 12-21

Section 12
12.7 SATDYSK - Dynamic Time Skims
12.7.1 Introduction
SATDYSK skims minimum origin-destination times for a network run with multiple
time periods (e.g. using SATTPX and SATSUMA, see Section 17) with the
important property that the skims are taken at fixed intervals of either precise
arrival or departure time throughout the full time period modelled and the “on-path”
link travel times are calculated dynamically. It differs in several respects from the
skimming techniques available through SATCOST (15.27.4) which in turn uses
SATLOOK.
Thus if a network is modelled by four 30 minute time slices from 8:00 to 10:00
SATDYSK could be used to calculate the minimum travel times for vehicles
departing from their origins at, e.g. 8:00, 8:10, 8:20…., 9:50, 10:00. All 13 skims
are output to one matrix of dimension 13n Z rows x n Z columns (where n Z is the
number of zones). The 10 minute interval is user-set. By contrast SATCOST
could be used to skim four separate matrices of “representative” OD time for the
four separate time slices.
Another point of difference between the time skims and those in SATCOST is that
in SATDYSK the skims may be calculated backwards from the destination. Thus
the 8:50 O-D time skim could reflect the time taken for trips arriving at their
destination D at exactly 8:50, as opposed to a forward time skim when 8:50
would represent the exact departure time from the origin O. (At the programming
level this has necessitated a new set of tree building routines which build
“backwards” as opposed to the traditional SATURN method of building trees
“forward” from the origin.)
A third difference is that, whether origin - or destination-based, the link times used
in the tree building are instantaneous dynamic times so that the travel time on
link a is a continuous function of the “clock time”. Thus, if building a set of
shortest paths (tree) for trips arriving at D at 8:50 and the tree algorithm has
reached a link which is 7 minutes “back” from the destination than the time
assumed on that link would be the time at 8:43 exactly, as opposed to the
normally modelled average link time in the 8:30 to 9:00 time slice.
One application of the program is to enable the derivatives of O-D travel times to
be estimated with respect to either arrival or departure times by taking the
differences in skimmed times between two successive times and to use that as
part of a peak-spreading model.
The “skims” are based on calculating minimum time routes independent of
whether or not the original assignment model was based on pure time or
generalised cost so the paths found are not necessarily those used by the original
model. In effect the original model is simply being used to generate a set of
dynamic link times and/or delays by clock time.
12.7.2 Instantaneous Link Travel Times

The instantaneous or dynamic estimates of link times as a function of clock time
are based on the sum of two components:
♦ Transient travel times (i.e., V < C)
5120257 / Apr 15 12-22

Section 12
♦ Queued delay (V >C)

Transient delays include both delays at junctions (turning movements) and
speed/flow delays on capacity-restrained simulation links plus all buffer links (if
any).
Queued delays, in this context, are only assumed to occur at simulation turns.
Without going into detail, queues in SATURN are assumed to increase or
decrease linearly over time as V > or < C so that, in theory at least, we know the
queue at any point in time; see 17.6.1. Knowing the queue length and the
departure rate (capacity) it is straight forward to calculate the time spent in the
queue as a function of arrival time clock time. (Note that as an added
“sophistication” if a vehicle arrives in one time slice but departs in another the
program allows the capacity to change as you move between time slices.)
Transient delays are assumed to be estimated by the original SATURN run at the
mid-point of each time slice, e.g., at 8:15, 8:45, 9:15 and 9:45 minutes in the
above example.
Intermediate times are then simply calculated by linear interpolation with two
exceptions: transient delays before the first mid-point (e.g. 8:15) are assumed
equal to the delay at that point, and delays after the last mid-point (9:45) are
similarly equal to that delay. Over-capacity delays are constrained in a slightly
different way in that they are assumed to be zero at the start of the first time slice
but may be positive at the end of the final time slice (although queues at the end
of the final time slice may indicate that the model is not covering the “full” peak
period and might need to be extended). These assumptions allow delays either
before or after the simulated period to be estimated as the sum of the two
components and included in the calculations, clearly necessary when we look at
arrival/ departure times near the end points when the trip must extend outside the
simulated period.
In both cases the functions of travel time/delay vrs. “clock” time are continuous,
although there will almost certainly be discontinuities in slope, e.g. at the mid-
points with transient delays.
It needs to be said that defining an instantaneous delay with such a fine precision
is probably pushing the bounds of realism within SATURN since it ignores all
considerations of day-to-day and minute-to-minute variability. Nonetheless it is a
strict application of the basic rules by which SATURN normally calculates
average delays and, if one wants to have a more precise model of time-varying
travel times, then that is the price to be paid.
The line printer file, contains inter alia, a table of time-specific link times for each
link at times 0, TOM, 2*TOM ... (NTOM-1)*TOM seconds. These need to be
checked for “realism”.
12.7.3 The Output Skimmed Matrix

The origin-destination travel time disaggregated by departure/arrival time are
output in the form of a stacked matrix which contains n Z x M rows where n Z is the
number of zones and M is the number of discrete departure/arrival times (variable
NTOM in &PARAM; see 12.7.5).
5120257 / Apr 15 12-23

Section 12
Thus, in the case of origin or departure time based skims, the first row in the
matrix contains the times from origin 1 to all destinations (columns) departing at
the earliest time skimmed, row 2 will contain the times from origin 1 of the second
departure time, row M+1 contains the earliest departure times from origin 2, etc,
etc.
Note, somewhat perversely and it probably should be changed, in the arrival-
based or backwards mode each row of the output matrix represents skimmed
times for a destination so that e.g., the Jth element in such a row would be the
time FROM origin J to that destination. In the other mode the row defines an
origin and the column a destination.
12.7.4 SATDYSK Files

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

Similar to other control files it is based on namelist input (see App.A) with “name”
&PARAM. The following variables, with their type and default values may be set.
Variable Type Default Function
DEPART L T If T skims are based on departure times; if
F on arrival time
NTOM I 10 Number of arrival/departure skims
TOM I 600.0 Time in seconds between skims
E.g.:
&PARAM
TOM = 30
DEPART = T
&END
Note that the values of TOM and NTOM should presumably reflect the total length
of the time period modelled. Thus the defaults cover a range of departure times of
6000 seconds, 1 hour and 40 minutes. If the model were of three 30-minute time
slices then the last two skims would probably be redundant; if the model covered
2 hours then the range would probably need to be extended.
12.7.6 Running SATDYSK

To run the program you must first have run a multiple time period simulation; e.g.,
SATTPX net 4
SATSUMA net 4
followed by:
5120257 / Apr 15 12-24

Section 12
SATDYSK net
The bat file SATDYSK uses the following files:

net.uft Input network file
net.ufm Output skimmed matrix file
net.LPV Output line printer file
SATDYSK0.DAT Control file (12.7.5)
5120257 / Apr 15 12-25

Section 12
Originate Checked Reviewed Authorised Date

d
5120257 / Apr 15 12-26

Section 12
Deriving O-D Demand Data from Traffic Counts (SATME2)
13. Deriving O-D Matrices from Traffic Counts

(SATME2)
INTRODUCTION
13.1 Introduction to SATME2
This section explains the use of the program SATME2 in conjunction with the
supplementary program SATPIJA to estimate trip matrices from traffic counts. It
is based on the theoretical procedure generally referred to as ME2, although it
would be better represented as ME2, - Matrix Estimation from Maximum Entropy.
A full list of references is given in Appendix C; a condensed summary follows.

SATME2 essentially tries to improve the fit between modelled and observed flows
by selectively factoring individual cells of the input trip matrix. Thus, with
reference to Figure 13.1 which illustrates the general functions of an assignment
model and which is a slight variation on Figure 2.1, we note in particular that (a)
the trip matrix is one of the two main inputs and that (b) the main output of the
process is modelled flows.
Figure 13.1 – Structure of Assignment Models
5120257 / Apr 15 13-1

Section 13
Modelled flows may, in turn, be directly compared with (for the base year, at least)
observed flows obtained from, for example, automatic vehicle detectors.
As also noted in Section 2.1, there are three general sources of errors – trip
matrix, network coding and route finding - of which errors in the trip matrix are
probably the single biggest source of error. What the process known as ME2
attempts to do therefore is, by essentially working backwards through Figure 13.1,
to establish a trip matrix which, when assigned, will give the desired answer, i.e.,
will reproduce the observed flows.
Thus we seek a trip matrix T ij which satisfies, for each of the observed counts, the
following condition:
Equation 13.1
∑T P ij
ij ija = Vaobs
where:
T ij is the output matrix;
P ija is the fraction of trips from i to j using link a
V a obs is the observed flow (in pcu/hr) on counted link a
We may think of Equation 13.1 as a “constraint” on the trip matrix arising from the
observed flow on link a.
In addition we would like a trip matrix which is as “near” as possible (or as “least
different” as possible) from any existing estimate of the trip matrix. In more
mathematical terms we seek to minimize some “distance measure” │T – t│
between the updated trip matrix T and the “prior” trip matrix t = t ij . The entropy
maximising model differs from other forms of matrix-estimation models in the way
that it defines its measure of distance and, as a consequence, the resultant
equations for T.
Thus the ME2 “distance” definition used to update an existing trip matrix may be
written as:
Equation 13.2
D (T , t )
= ∑ (T
ij
ij log (Tij / tij ) − Tij + tij )
And the resulting equation giving the “maximum entropy” solution may be written:
Equation 13.3
Tij = tij ∏ X aPija
a
where:
t ij is the prior matrix,
X a is the ‘balancing factor’ associated with counted link a,
Π is the multiplicative equivalent to Σ for summations
5120257 / Apr 15 13-2

Section 13
SATME2 uses an iterative procedure to find a set of balancing factors X a for each
counted link to ensure that the assigned flows match the counts within certain
user-defined limits (See 13.1.8)
The procedure is in fact very similar to that used in the well-established Furness
matrix-balancing procedure with the exception that Furness constrains the flows
into or out of (all) zones as opposed to the flows on selected links. In fact zonal
constraints are just a special case of link constraints and as such may be input
directly to SATME2 (See 13.1.5 and13.3.2).
An alternative “distance” measure could be the well-known “sum of squares”:
Equation 13.4
D (=
T,t) ∑ (T − tij )
2
ij
ij
And indeed a large number of alternative matrix estimation models have been
constructed using this definition.
13.1.2 ME2 With and Without a Prior Matrix

SATME2 may be used in essentially two different ‘modes’. In the ‘update’ mode,
as discussed above, it takes an old or prior trip matrix and current traffic counts to
estimate the most likely trip matrix consistent with the information contained in the
counts and using the old trip matrix as a starting point.
In the second mode no ‘prior’ trip matrix is available and the model therefore
assumes that all trips are equally likely so that, in effect, it starts with a prior trip
matrix in which all elements are equal. (The model in fact chooses an appropriate
average constant value for all t ij in Equation 13.4 to start with.)
Note that the second mode is virtually never used in practical studies – nor should
it be! – Although it may have some useful applications in setting up purely
synthetic matrices for theoretical studies of small artificial networks.
Users are strongly advised to carefully read Section 13.3.5 regarding the correct
choice of a prior trip matrix.
13.1.3 Basic Program Structure

In order to update a trip matrix in SATURN two linked programs must be run as
illustrated in Figure 13.2: SATPIJA and SATME2.
5120257 / Apr 15 13-3

Section 13
Figure 13.2 – Estimating a Trip Matrix, SATPIJA plus SATME2
Thus SATME2 requires a “PIJA” file, each element of which represents the
proportion (P) of trips between a particular origin-destination pair (IJ) which uses
the counted link (A). The PIJA data are obtained through the program SATPIJA
following a SATURN assignment using the SAVEIT option (15.23).
More precisely SATPIJA analyses the output .ufs and .ufc/.ufo (see 13.3.14) files
from a full run of SATURN in order to produce a ‘.ufp’ file which contains the “PIJA
factors”. This information is then fed into SATME2, along with the prior trip matrix,
in order to produce an updated trip matrix.
Both SATPIJA and SATME2 require control data files as described in Section
13.2 below. The count data may either be included in the SATPIJA file or taken
from the 77777 data segment in the network .dat file originally input to SATNET
(see 13.2.1)
13.1.4 Count Definitions: Fixed Flows and Target (Demand) Flows

“Counts” may refer to either simulation or buffer links, turning flows within the
simulation network on to entry and exit flows from zones (but not on specific
centroid connectors). All of these are “links” in the sense of the assignment
network (5.5.1). The procedures work equally well on “pure” buffer networks with
no associated simulation network.
5120257 / Apr 15 13-4

Section 13
Note that, in common with all definitions of “flow” within SATURN (see 15.17), the
counts used in SATME2 must be defined in terms of pcus/hr (or, strictly speaking,
in the same units as all the other flows; see 15.17).
Several complications and/or extensions are introduced into the definition of the
constraint counts in SATME2 due to the level of sophistication inherent in
SATURN assignments.
13.1.4.1 Assigned and Fixed Flows

Firstly, within SATURN link flows are made up of two components - trips assigned
from the trip matrix and a fixed component set up by SATNET representing, for
example, bus routes on the link or PASSQ flows. By default it is assumed that the
‘observed’ count input corresponds to both these components together and that
what the user wishes to generate is the trip matrix which will correctly give a flow
equal to the observed flow less the fixed flow. Hence, by default, the fixed flows
are subtracted from the input counts (unless a parameter SUBFIX is set to
.FALSE.) N.B. this correction is not applied to zonal constraints – see 13.3.2.
(Alternatively only the PASSQ component of the fixed flows may be subtracted by
setting SUBPQ = T and SUBFIX = F; see also 13.3.1 and13.4.8.)
Note that if the fixed flows to be subtracted from the input counts exceed the
counts then the target is artificially set to zero and a non-fatal error is generated
since in this case there is no way that a correct trip matrix can be created. A fatal
error might be more appropriate.
(Technical aside: The total fixed and/or PASSQ flows which are subtracted within
SATME2 are actually read from the network .UFS file(s) within SATPIJA and
passed to SATME2 via the .UFP file. This is done automatically by SATPIJA
whether or not SATME2 will actually use them or not.)
13.1.4.2 Demand v Actual Flows: Upstream Flow Metering

Secondly, SATURN differentiates between “demand” flows and “actual” flows
within the simulation network. (See Section 15.1 for a discussion of the
distinction). We require that SATME2 produce a demand trip matrix which, when
assigned to the network, reproduces observed counts; but, if there are permanent
queues present in the network, the demand must be sufficiently increased so that
the required trips reach the observed links despite the queues upstream which
restrict the actual flow arriving at the count sites.
To account for this fact the “observed” counts have to be factored up into “target”
counts corresponding to the full demand for trip making. This conversion is done
automatically within SATPIJA and the demand count flows are then passed to
SATME2 via the .ufp files.
Upstream metering of flow may, in some cases, make it difficult / impossible to
achieve a demand matrix which satisfies the counts; see 13.1.10.
On the other hand there may be circumstances where the user may wish to ignore
the distinction between actual and demand flows and to treat the input counts as
demand flows. This, post release 11.2, may be down within SATME2 by setting
the Namelist parameter DEMAND to T, in which case the counts as used within
SATPIJA, either taken from the .ufs file or defined on an ASCII .dat file, are used
5120257 / Apr 15 13-5

Section 13
by SATME2 as demand flows and any corrections due to flow metering are
ignored.
Alternatively, if counts are “corrected” using the 11111 data segment within the
SATME2 control file (see 13.2.2), then it is assumed that the input flow is the
correct demand flow which will not therefore be factored up as it would be if it
were processed within SATPIJA. Some care may be necessary here if that is not
what you intend.
N.B. Table 1 within the SATME2 .LPM file prints both the original (actual flow)
counts plus the target or demand version of the flows.
13.1.5 Origin/Destination Zonal Contraints: Furness vrs ME2

In the same way that counted flows may be associated with individual links they
may also be associated with individual origins or destinations. Thus SATME2 can
make use of both zonal and link constraints at the same time (see the 22222 and
33333 set of data records in 13,2,2).
In this respect SATME2 replicates all or part of a singly- or doubly-constrained
Furness matrix model available within MX (10.7) which, in its full form, may be
stated:
Tij = Ai B j tij
where the row and/or column balancing factors are chosen such that
∑Ti
ij = Dj
∑T
j
ij = Oi
In the case of SATME2 the row and column sums O i and D j are user input as
zonal constraints.
Under Furness the balancing factors Ai and Bj are calculated using a “bi-
proportional” technique and they play a highly similar role to the Xa factors in ME2
(which are calculated by a “multi-proportional” technique). Note, however, that the
zonal balancing factors are not explicitly raised to a power of Pija as in Figure
13.3. (Although, since the flows to or from a zone are 100% to or from that zone
and no other, their effective Pija factors are 1 and we could think of the Ai and Bj
factors as being implicitly raised to a power of 1.)
In principle it would be possible to carry out a full Furness procedure using
SATME2 by inputting the complete set of origin and destination flows (and no link
counts) although this would not be particularly efficient. The equivalent techniques
available in MX (10.7) are preferable.
Post release 10.9 a table (11.c) is included in the output .LPM file from SATME2
listing all origin / destination zonal totals both before and after ME2 is applied,
their changes and (if appropriate) their constrained totals.
5120257 / Apr 15 13-6

Section 13
Note that there nay be significant advantages to running an MX Furness

procedure on the prior matrix in order to improve the prior matrix before running
SATME2 with the link constraints added. See Section 13.1.12.
(N.B. MX gives slightly different results to SATME2 when applied with O-D
constraints only due to a different convergence algorithm, but it is very difficult to
say whether or not one is “better” than the other.)
13.1.6 Fixing certain O-D movements (FRODO)

SATME2 produces a trip matrix which is in some way a best fit to available count
data while at the same time remaining as near as possible to the original trip
matrix. In normal operation the procedure does not take into account the fact that
some (count) information may be more reliable than others or that the matrix may
be more reliable for certain movements. This may be the case for example if a
recent partial O-D survey at a small number of interview stations has been
merged with an older trip matrix.
Whilst no method has yet been implemented to impose a measure of reliability
(possibly variance related) on count processing, a modification has been
implemented which enables specified cells or blocks of cells to be ‘frozen’ in the
output matrix; i.e., to maintain the values from the ‘prior’ matrix. The result is to
force changes in selected areas of the matrix only, where, for example, surveyed
information is of poor quality.
Frozen cells may be defined in several ways: (a) in terms of complete zones - in
which case all trips into and out of the nominated zones are frozen - or (b), more
precisely, in terms of a “rectangular area” within the matrix specified by a range of
origin and destination zones. See Records (4) and (5) under 13.2.2.
In addition, post 10.7, the frozen cells may be input via a matrix of frozen cells
whereby a value of 0.0 in a cell of the input matrix implies that that particular cell is
to be considered as “frozen”. See the namelist parameters FRODO and FILICE in
13.2.2 where FRODO = T implies that the .ufm matrix defined as FILICE specifies
the frozen cells. See also 7.5.6 where the same named matrix FILICE fulfils a
similar function within SATALL.
N.B. There are a number of alternative names which may be used in addition to
FILICE: ICEFIL, ME2ICE and ICEME2 work equally well and, indeed, in older
versions of SATME2 (prior to 10.7.8) only ME2ICE and ICEME2 were recognised.
See error 33 in Appendix E.4.
See Table 6 in the output .lpm for a summary of the total number of cells frozen
and Table 2 for the corrections due to frozen cells for each individual input count.
Note that if the flows on a link due to the frozen cells in the matrix exceed the
target count then it is not possible to satisfy the constraint by adjusting the non-
frozen cells. In this case a non-fatal error is generated and the target re-set to
zero – although, arguably, a fatal error might be more appropriate.
WARNING! Freezing a large number of cells – or, more correctly speaking,
freezing a large proportion of trips – may be dangerous since, in effect, it puts all
the pressure for change on the unfrozen cells and may result in severe distortion
to the that section of the trip matrix
5120257 / Apr 15 13-7

Section 13
13.1.7 Less Than and/or Greater Than Constraints

Traditionally the count information input is taken from observed link flows which
are considered to be absolute constraints on the model output. However there
are circumstances in which one might have information which specifies either an
upper or lower limit on the link flow; for example link capacities may be viewed as
upper limits, current day flows as a lower limit for a future year network.
It is also proposed in 13.3.10 that GT/LT constraints may be used to deal with less
reliable constraints.
In SATME2 it is possible to define counts as either:
♦ Strict equality constraints, in which case the “balancing factor” X a is chosen in

order to achieve equality; or
♦ Greater than/less than constraints, in which case the factor X a remains at 1.0
(no effect on the trip matrix) unless the constraint is violated, in which case
the constraint is treated as an equality and balanced exactly.
Note that with “less than” constraints X a factors can only be less than or equal 1
(in order to reduce the flow through that link), while with “greater than” constraints
they must exceed 1.
All counts input on the .ufp file are assumed to be of the same “constraint type” as
specified by the SATME2 Namelist parameter LEG (which stands for Less
than/Equal/Greater than) but it is possible to have mixed constraints by using the
“change of mind” input records described below.
The same concept of constraint types applies equally to zone origin and/or
destination constraints as input under the 22222/33333 data records in the
SATME2 control file (13.2.2).
There is, however, one major distinction between GT/LT constraints on zones and
on links which is that, with zones, it is possible to have both a LT and GT
constraint on the same zone O or D, in which case the constraints specify a range
of values. In this case at most one of the two constraints will be “active” depending
on whether all other constraints take the zone total above or below the appropriate
limit. Alternatively neither can be active if the total is otherwise within range.
Note that in order to set a zonal O/D range it is necessary to input two records
under 22222/33333: one with the LT constraint and the other with the GT
constraint. Obvious error checks are carried out to determine if the LT value is
indeed greater than the GT value.
Note that the definition of less than etc. constraints is only made on entry to
SATME2; the Pija calculations carried out by SATPIJA are the same no matter
what form of analysis is eventually carried out in SATME2.
13.1.8 Combining Multiple Constraints Together

It is possible; following SATURN 10.5, to combine a set of input counts input on
the .ufp file into a single constraint such that SATME2 assigns the same balancing
factor Xa to all the individual constraints in order to satisfy the sum of all the
individual flows.
5120257 / Apr 15 13-8

Section 13
This option may help to correct errors and/or inconsistencies introduced by the
assignment. It may also be used to satisfy the total flows measured crossing a
screen line or cordon.
An example of a potential inconsistency between the assignment and the counts
is illustrated below where there are two alternative (parallel) routes between
nodes A and B via K and L. Suppose that the counted flows on AK and AL are
2,000 and 1,000 respectively but that the assignment (for whatever reason) will
always assign more flow via L than via K. In this case it will be impossible for ME2
to find a trip matrix which can simultaneously satisfy both counts and assigned
proportions. However if the total flow between A and B is constrained to equal
3,000 then the precise split of trips between K and L is no longer a problem.
Note that the root of the inconsistency could be either the assignment or the
counts themselves, combining the counts dodges the issue. An alternative
solution would be to remove the counts altogether.
K
O ---------------A B------------ D
L
To use this option the individual links which are to be combined into a single
constraint are listed within a single set of 66666 records on the input SATME2
control file; see 13.2.2 (No specific advance action is required in SATPIJA except
that each individual link which is to become a member of a combined constraint
with its count must be defined as an input to SATPIJA.) The count which is to be
satisfied is the sum of all the individual counts while the PIJA factors are assumed
to be the sum of the individual PIJA factors.
Note that once an individual link count has been included within a combined count
it is no longer applied as an individual constraint, only as part of the combined
constraint.
13.1.8.1 Multiple Crossing: Pija > 1

Note that adding the PIJA factors together is correct as long as no od pairs use
two or more of the combined counts, i.e., that there are no double crossings. If
these conditions are not satisfied, i.e., if the summed PIJA factor > 1.0, then it is
re-set to 1.0 with Warnings and/or Serious Warning messages added as
appropriate. Essentially links to be combined should be “in parallel”, not “in
series”.
The condition is certainly satisfied if a set of turn counts out of the same link are
combined together. Equally it should be satisfied if two adjacent and parallel links
are combined together since a driver is highly unlikely to use one link and then
back-track in order to use the second. On the other hand a screen line which
consists of multiple nearly parallel links, e.g., bridges across a river, may allow
double-crossings in practice if the river is not particularly straight (think of the
Thames in London).
If counts with “double crossings” are combined the end effect is likely to be an
increase in the estimated trip matrix (although it is always difficult to say with
5120257 / Apr 15 13-9

Section 13
absolute certainty what a complicated system such as ME2 will do). For example,
if two links A,B and B,C in series both have counts of 1,000 and both are
(inadvertently) combined together then their combined screen line count constraint
will be 2,000. However if a particular OD pair has Pija factors of 1.0 on both then
the summed Pija factor of 2.0 will be reduced to 1.0. Since the “correct” solution in
this case should be a Pija factor of 1.0 and a count of 1,000 ME2 will therefore
produce extra trips by trying to create 2,000 trips on A to C, not 1,000.
Post 11.2.5 a summation is kept of all Tij * (Pija – 1) to quantify the extent of the
problem due to “capped” Pija factors. The information is printed to the .LPM files.
If the capped flows are less than, say, 1% of the total target flows then the
problem may not be serious in the overall ME2 procedures but if they exceed, say,
10% then the problem becomes serious.
We should also note that double/multiple crossings may still occur even when the
summed Pija factors are less than 1.0. For example, if two links are directly in
series and they are used by an OD pair with a Pija factor of 0.4 (i.e., 40% of the
trips from that OD pair use each of the two links in question) then their combined
Pija factor would be 0.8, no capping would take place and no error messages
would be generated. Hence the test on Pija > 1 is not guaranteed to detect all
multiple crossings, only the worst cases. If in doubt use the SLA screen line
crossing analysis in P1X (11.8.1.10) to test for multiple crossings.
13.1.8.2 Repeated Combined Counts

Note that an individual count may only appear in one combined set; if a count
appears in more than one 666 set a fatal error results.
13.1.9 The Interpretation of Xa Factors

The “balancing factors” X a as used in Equation 13.4 are critical in obtaining the
maximum entropy or “best” trip matrix and their interpretation is also important in
understanding what the model is doing. Their role is illustrated in Figure 13.3(a)
and Figure 13.3(b).
Thus these figures illustrate how the Equation 13.4 applies to a particular o-d pair
when there are three counts, represented by W1, W2, and W3. Note that 1 and 3
represent flows on links while 2 represent the flow on the “horizontal” turn at that
junction.
In Figure 13.3 (a) we assume that the assignment for this particular o-d pair is “all
or nothing”, i.e., along a single path that goes through all three counts. Hence P ija
= 1.0 at all three counts and the balancing factors X 1 , X 2 , and X 3 are all raised to a
power of unity: hence the equation as shown.
By contrast in Figure 13.3 (b) there are two routes used between o and d, 50% on
each. Hence P ija = 0.5 at counts 1 and 2 but 1.0 at count 3 where both paths
come together. Hence the balancing factors at points 1 and 2 are raised to a
power 0.5 (i.e., square rooted).
5120257 / Apr 15 13-10

Section 13
Figure 13.3 – (A) A single o-d path with three count sites
(B) A single o-d pair with two o-d paths and 3 count sites
If at count 1 the original modelled flow (assigned using t ij ) was less than the
observed flow W 1 then the balancing factor X 1 would (all other things being equal)
be greater than 1 in order to increase all the o-d pairs assigned to that link (in
either case). Similarly if count 2 were over-assigned W 2 would be less than 1 in
order to reduce the number of trips through it.
It is easy to see that the balancing factors are not unique. For example in Figure
13.3 (a), if all three counts were under-assigned by 50% and OD was the only trip
pair through all three count sites then setting one of the three W’s to 2.0 and the
5120257 / Apr 15 13-11

Section 13
other two to 1.0 would correctly double the flow on all three counts. Alternatively
setting all three to the cube root of 2 would have exactly the same effect.
As a general rule one would expect that counts which are under-assigned initially
would have a balancing factor greater than 1 and, conversely, if under-assigned
X a less than 1. Equally, the greater the difference in the original assigned and
modelled flows, the greater the difference of X a from 1.0.
However, given the interaction and non-uniqueness of the balancing factors noted
above, such simple rules do not always apply. Thus if X 1 >>1.0 in either Figure
13.3 (a) or (b) to correct for a large under-assignment at W 1 it may be that, if W 2
were only marginally under-assigned, then X 2 < 1.0 in order to counter-act the
large increases in path flows caused by X 1 .
We also note briefly at this point, and discuss it more fully under 13.3.1, that the
balancing factors X a are restricted to lie in the range (1/XAMAX, XAMAX) where
XAMAX is a user-set parameter. These restrictions are in place in order to
prevent the matrix from being “over-distorted” by ME2 trying to satisfy all counts
when, for many possible reasons, this is not possible. A value of X a equal to either
the minimum or maximum values is a strong indication that there may be
something funny going on at that particular count site.
For analysis purposes it is sometimes beneficial to transform the X a factors into
the alternative form X a ’ where:
X a′ =
X a − 1.0 X a > 1.0
− (1.0 / X a − 1.0 )
X a′ = X a < 1.0
Thus X a = 1 (no changes to the matrix elements using that counts ite) transforms
to X a ’ = 0, values of X a > 1 are positive and values of X a < 1 become negative.
The transformed values are particularly useful when being displayed in P1X (see
11.8.5) in that those values that increase the trip matrix are positive and in one
colour while those that decrease the trip matrix are negative and in a different
colour.
13.1.10 Convergence of Matrix Estimation and Assignment

Finally, the PIJA factors described above are not fixed, but are themselves
dependant on the trip matrix in a rather complex fashion. Thus if the trip matrix is
updated according to one set of PIJA factors when it is assigned it will be
assigned to different paths and/or different path proportions from the original
matrix and hence a new set of PIJA factors will result. This feed-back effect
introduces a convergence problem in that we seek to find a trip matrix which is
compatible with a set of PIJA factors such that those factors are themselves
compatible with the trip matrix plus assignment.
The normal (but not necessarily the only) procedure adopted within SATURN,
represented in flow chart form in Figure 13.2 above, follows an ad hoc iterative
algorithm whereby an assignment is used to derive the route choice/PIJA factors
which are in turn used to estimate a revised trip matrix. This is then reassigned
and the process continued until stable values are found. (Six such loops has
become a common empirical practice within the UK but whether convergence is
5120257 / Apr 15 13-12

Section 13
likely after six loops or whether people simply get fed up after six loops is hard to
judge.)
The iterative procedure commences with a full run of SATURN using an old trip
matrix. (If no such matrix is available then one should either create a purely
artificial trip matrix with ‘roughly’ correct elements in each cell or, preferably,
‘Furness’ a matrix using MX from either known or estimated origin and destination
totals). Subsequent runs of SATURN will use the latest updated trip matrix from
SATME2; considerable computer time may be used by taking advantage of the re-
start facility described in Section 15.4.
As noted earlier there is a potential problem within matrix estimation of finding a
solution whereby the trip matrix estimated is based on PIJA factors which in turn
are the same as those produced by assigning that trip matrix. This is a well-
known theoretical problem for which no (computationally feasible) guaranteed
solutions are available; the iterative loops shown Figure 13.2 are only heuristic
procedures and cannot be guaranteed to converge.
Highly congested networks, where route choice is very sensitive to the number of
trips to be assigned, generally present the most severe problems. One possible
solution method here may be to “soften” the changes in the trip matrix by
averaging successive trip matrices, e.g. by using a 1/n rule as in assignment (see
7.2.2) but applied to trip matrices, not flows.
The problem may also be associated with a small number of link counts, possibly
those that are inconsistent between themselves. Identifying and removing them
may improve the situation (see 13.3.4).
13.1.10.1 Problems due to Flow Metering

A further reason for non-convergence may be related to the distinction between
demand and actual flows at the count sites as described in 13.1.4 whereby the
reason that a particular count is being under-assigned may be due to the fact that
limited capacity upstream restricts the flow that can reach that particular link
independent of how much “demand” flow is contained in the trip matrix. In such a
situation convergence can never be achieved. An extreme example of this is a
bottleneck immediately upstream which strictly limits the flow downstream; see
13.3.7.
The above problem manifests itself by the total number of trips increasing each
time SATME2 is re-run within the loop. In fact increasing the demand matrix may
make it even more difficult to increase the actual flow at the count sites since
increasing flow can decrease total capacity (due, e.g., to gap acceptance),
increase the degree of flow metering and therefore, paradoxically, result in even
lower flows downstream. In such cases the problem may be neither due to errors
in the counts or in the prior trip matrix but to, say, too low saturation flows etc.
which unduly restrict flow.
Careful monitoring of both the trip matrices and network statistics (e.g., average
speed) at each step of such loops is ABSOLUTELY ESSENTIAL.
5120257 / Apr 15 13-13

Section 13
13.1.11 When to use SATME2; Initial Calibration Steps

It must be strongly emphasised that SATME2 should only be applied after all
other possible forms of validation on the network and original trip matrix have
been carried out. In effect ME2 attributes all differences between observed and
modelled counts to errors in the trip matrix and attempts to reduce these
differences by making changes to the matrix. If the differences are due to network
coding errors the process simply introduces additional “errors” in the trip matrix to
counter-balance those in the network. Only when the network errors have been
minimised as far as possible should ME2 be applied.
The changes introduced by ME2 should therefore be relatively minor and
incremental in nature rather than large scale changes which considerably distort
the prior trip matrix. It follows that the X a factors (Equation 13.1) should be not too
different from 1.0 (hence the introductions of an upper limit parameter XAMAX)
With respect to network calibration you should pay very close attention to the
routes being generated by the assignment model with the “unadjusted” prior trip
matrix, particularly those which go through your counted links (or possibly don’t go
through but maybe should). If they’re wrong then so too will be your updated trip
matrix. A very clear indicator of poor routing is having a counted link with zero
modelled flow but a positive count.
13.1.12 Calibrating the Prior Trip Matrix

Equally the prior trip matrix should be as “accurate” as possible. In particular the
use of the SEED parameter to deal with the problem of zero elements in the prior
matrix should be avoided as far as possible. It is recommended that, with trip
matrices derived directly from observation where a zero cell simply implies no
observations, some form of gravity model be applied in order to introduce suitably
low but non-zero values into the zero or missing cells rather than let ME2
introduce a global flat value via the SEED. The Furness routines within MX may
be useful in this regard, although no specific advice on the “smoothing” techniques
to be used are offered here.
You are therefore strongly advised to check Table 4a in the .lpm file for gross
discrepancies between the initial estimated modelled flows (i.e., those derived
using the prior trip matrix) and the target (as opposed to actual) counts.
Differences may of course be equally due to errors in the counts as much as
errors in the prior matrix; both need to be checked and corrections made prior to
running SATME2.
Note that flow differences in Table 4a – which are effectively differences at the
level of demand flows, not actual - may also be caused by problems in incorrectly
estimating the degree of flow metering upstream (i.e., incorrect capacities). Thus if
the flows estimated from the initial matrix are lower than the target flows the
explanation may be either that that the trip matrix was too small in the first place
or that the model is reducing the flow reaching the counted link due to capacity
constraints upstream whereas in reality no such flow metering takes place.
You should also check that your prior trip matrix gives total flows across the
counted links which are broadly correct; plus/minus 10% would be a good target
to aim for. See Table 5a in the output .lpm file for relevant statistics. If not, you
should probably think about some form of prior factoring. If the absolute
5120257 / Apr 15 13-14

Section 13
difference between the prior totals and the counted totals is greater than
10%/20%/50% the .lpm file will contain a Warning/Serious Warning/Extremely
Serious Warning message.
For example, if Table 5a gives a ratio of 2.0 of target counts to input modelled
flows the most obvious course of action is to simply factor your prior matrix by a
factor of 2.0. On the other hand it might be that all your counts are monitoring
flows in a north-south direction, in which case it might be more appropriate to
factor only north-south o-d pairs (hint: use sectors in MX) by 2.0 rather than the
full matrix. (This depends on what you “think” north-south counts are telling you
about east-west movements; it might be the case that previous east-west trips
have now “migrated” to north-south trips and that the east-west cells should
actually be factored down rather than up.).
Equally if you have either a complete or partial set of origin/destination counts you
may wish to consider using a Furness factoring procedure (see 10.7) to balance
the o-d counts prior to running SATME2 (see 13.1.5). Note that with a partial set
of O-D counts it will be necessary to expand this to a full set by, e.g.,
guestimating, the missing totals prior to Furnessing. As long as the estimated O-D
totals are a relatively small component of the total or may be estimated with some
reliability, then this approach has a lot to recommend it.
13.1.12.1 Negative Cells

Note that any negative cells in the prior trip matrix (which should not be there in
the first place!) are replaced by 0.0 during the ME2 calculations and are therefore
output as zero’s in the output trip matrix. Non-Fatal errors are generated within
SATME2 when this occurs.
13.1.13 Checking the Post-ME2 Trip Matrix

If the prior matrix is a good initial approximation of what the “true” trip matrix
should be it follows that the output trip matrix should not differ substantially from
the input prior matrix. Detailed statistics comparing the pre- and post-ME2
matrices at a cell by cell level as well as at more aggregate levels are given in the
.LPM files (with the most detailed statistics only given if M2 = T under &PARAM;
see 13.2.2).
If the total number of trips in the output trip matrix differs by more than 10% from
that input (refer to Table 15 in .LPM) then a Serious Warning message is
generated; if greater than 5% it is only a Warning.
13.1.14 GONZO and SATME2

Using GONZO to factor input trip matrices within SATALL and then running
SATME2 with the unfactored trip matrix as input is extremely dangerous,
basically because SATME2 will ignore the factoring implied by GONZO and
attempt to provide factors to correct the original matrix. This can lead to a form of
“double factoring”.
Warning messages are printed within SATPIJA where GONZO is known from the
input .ufs file but not in SATME2 where the .ufs file is not input.
5120257 / Apr 15 13-15

Section 13
Equally with multiple user classes (See 13.4) where more than one class may
share a single “level” of the “stacked” trip matrix then the expectation is that the
sum of the individual shares (i.e., the sum of the factors in columns 11-15 in the
8888 network data records, see 6.11) should equal 1, otherwise a form of GONZO
factor has been introduced. Again, warnings are printed within SATPIJA if this
happens.
N.B. Similar problems occur with SATCH; see Section 12.1.7.
13.1.15 Final Advice

If you are about ready to start running SATME2 then our final advice is: Wait! Re-
read sections 13.1.11 and 13.1.2, making sure that you have done all you possibly
can in terms of calibrating the network and the trip matrix.
Then, when you are convinced that there is nothing more that you can do there,
run SATME2 and look very, very carefully at the outputs, including the .lpm file.
Check which counts are being balanced with difficulty – maybe some of your
counts should be discarded as unreliable, maybe there are still problems with
some of your network routings, maybe the original trip matrix is wrong, etc. etc.
Make the appropriate changes and re-run.
AND NEVER, NEVER ACCEPT THE OUTPUTS FROM SATME2 WITHOUT DOUBLE-
CHECKING. It is easy to apply SATME2 but it is considerably more difficult to
update your matrix correctly.
Further (good) advice is available in TAG Unit M3.1 Highway Assignment
Modelling.
13.2 Matrix Estimation Data Requirements

In order to run SATPIJA to produce a PIJA file and then SATME2 to update the
original trip matrix two ascii DAT files - denoted Control Files A and B in Figure
13.2 - must be prepared.
13.2.1 SATPIJA Control Data Input

The SATPIJA control file contains the following information.
RECORD(S) 1. NAMELIST PARAMETERS (&PARAM)

UFFLOW LOGICAL F T. - Counted links are read from the
input network UF file; see note 1.
F.- Links read from this file
ALLIJ LOGICAL F T - Analyse all Tij pairs

F - Analyse only positive Tij pairs
See note 7.
DUTCH LOGICAL F T - Link/turn records 2 below are
formatted according to the
DUTCH options (15.20).
5120257 / Apr 15 13-16

Section 13

PIJAKP LOGICAL F T - Output an ASCII file containing
PIJA data
PREUFP LOGICAL F T – Carry out the data input and error
checks but no Pija calculations or
output .UFP file; see 13.3.3.2.
SET777(i) LOGICAL T T – Include the I’th set of 77777
count records from the input
network .UF file;
F – Exclude set i counts.
See notes 2 and 3. (Only relevant if
UFFLOW =T)
AVERK LOGICAL F T – Try to correct for any Kirchoff
violations identified by averaging
counts; see 13.3.3
TURBO LOGICAL F T – Used in conjunction with IVC to
update multiple levels of a stacked
matrix file in SATME2; See 13.4.6.
CHECKS LOGICAL F T – Carry out checks on the input
data only – no output .UFP file will be
produced
USEUFO LOGICAL F T – Use an input .UFO file in
preference to .UFC to define routes.
See 13.3.14
GROUPS LOGICAL F T – Calculate Pija factors based on
an aggregate (group-based) trip
matrix. See 13.5.2.
KLASS INTEGER 1 User class; see note 8 (a).
LEVEL INTEGER 1 “Level” of a stacked matrix to be
analysed; see note 8 (b).
IVC INTEGER 0 The “vehicle class” to be analysed;
see note 8 (c)
MCC INTEGER 1 “Count field” to be used from the
input network counts; see note 4
(Only relevant if UFFLOW = T)
IPART INTEGER 0 If NPART > 0 process the IPART’th
segment of origin zones; see 13.4.9.
NPART INTEGER 0 The origins are divided into NPART
segments for PIJA calculation; see
13.4.9.
PIJMIN REAL 0.0001 PIJ values less than PIJMIN are
ignored and are not included in
the output UFP file
(Optional, UFFLOW = F)
5120257 / Apr 15 13-17

Section 13
RECORD(S) 2 LINK / TURN RECORDS

One record for each turning movement or link for which counts are available
formatted as follows:
(N.B. This is essentially the same format by which counts are input to SATNET
except that only a single count is set; see 6.10. A different format is used under
the DUTCH option – see 15.20.)
Cols. 1 – 5 The A-node, A
Cols. 6 – 10 The B-node, B
Cols. 11 – 15 The C-node, C (for turning movements)
Cols. 16 - … The observed or counted flow in pcus per hour (essentially as free
format starting in column 16 or 31 under DUTCH)
The end of the observed counts is indicated by 99999 in columns 1 to 5.
N.B. Counts may refer to either simulation or buffer links, but to turns ONLY in the
simulation network. Centroid connectors are not allowed, nor are repeated entries
with the same A-B-C. In addition there is no way to split the counts into separate
sub-sets as with multiple 77777 records in network data files.
N.B. Alternatively you may use a $INCLUDE record to define an external data file.
See note 5 below.
END OF THE INPUT DATA
NOTES
1) The links or turns to be analysed within SATPIJA (and, by implication, within
SATME2) may be either: (a) those already stored on the input .ufs file (as
originally input to SATNET as 77777 data; see 6.10) if UFFLOW = T; or (b) an
entirely new set of links/turns included in the control file as Records 2 above if
UFFLOW = F.
2) If UFFLOW = T, in general, all input links/turns read from the .ufs file are used.
However, if they were input in SATNET as multiple sets of 77777 records
(see notes 1, 2 and 15 in 6.10), then you may select a sub-set of those sets by
using the SATPIJA subscripted logical parameters SET777. For example, if
you had two sets of 77777 data records then setting SET777(1) = F and
SET777(2) = T would mean that SATPIJA would only analyse those
links/turns in set 2.
3) If you had a large number of 77777 count sets of which only one or two are to
be used then the simplest method is to first include a namelist definition
‘SET777 = .FALSE.’ which will “exclude” all 77777 count sets and then
explicitly define, e.g., SET777(29) = T etc. if set 29 is to be included.
4) If UFFLOW = T and more than 1 count field was used in the original .7777
data sets (MCCS > 1; see 6.10), then the Namelist parameter MCC above
selects the relevant count field.
5120257 / Apr 15 13-18

Section 13
5) Alternatively, if UFFLOW = F and the counts are to be included on the control

file, then they may be set in an external ASCII file by using the convention
$INCLUDE filename – in which case $INCLUDE immediately follows &END
and is itself followed by a 99999 record. See 15.34.
6) As per the original input of counts to SATNET from a network .dat files link
counts may be repeated (but only in different count sets); repeated links are
ignored by SATPIJA.
7) If SATME2 will only update positive cells in a trip matrix, i.e., zero cells are
not seeded (SEED = 0.0), there is no point in producing Pija values for cells
where T ij = 0. If ALLIJ = F only positive cells will be examined and, in this
case, an input trip matrix is required and should (indeed MUST) be the same
base (i.e., prior) matrix to be input to SATME2. SATPIJA does not make use
of precise individual cell values, it only checks if they are positive.
8) In the event of multiple-user class assignment based on a stacked (multi-
level) .UFM matrix SATPIJA can consider either:
a) Only a single user class (set by KLASS) or,
b) All user classes based on the same “level” of the input stacked trip
matrix (set by LEVEL)
c) All user classes which share a common “vehicle class” (set by IVC)
In cases (b) and (c) the output PIJA factors are “weighted” averages of
the user classes within that level or vehicle class; see equations (13.5)
and (13.6) respectively. Under (a) the matrix level is effectively defined
by that used by the user class specified by KLASS.
Only one of these three parameters needs to be specified, otherwise a
Fatal Error may result. However, if the MUC assignment is structured so
that each user class corresponds to a separate level in the trip matrix
either KLASS or LEVEL may be used or, if both are used simultaneously,
they must be equal. If IVC is used neither KLASS nor LEVEL may be set.
See 13.4.2 for further details on updating MUC matrices.
13.2.2 SATME2 Control Data Input
RECORD1. OPTIONAL: THE RUN RECORD

Type Command Comment
Optional RUN runname Where ‘runname’ is a descriptive title in Cols. 5 to
80.
RECORD(S) 2. MANDATORY NAMELIST &PARAM INPUT (OPTIONAL)

Name Type Default Comment
PRIOR L T If TRUE, an ‘a prior’ trip matrix is input – if
FALSE no matrix is input and it is assumed that
all trips are equally likely.
5120257 / Apr 15 13-19

Section 13

STATS L F If TRUE the balancing factors are printed on
each iteration.
SUBFIX L T If TRUE any fixed flows are subtracted from the
input counts so that the program attempts to
match the flows assigned from the trip matrix
only. See 13.3.1 and, for MUC where the default
of SUBFIX = T is not recommended, 13.4.8.
INFIT L F If TRUE (and PRIOR = TRUE as well) a
complete statistical comparison of the goodness
of fit of the prior matrix to the input counts is
carried out. This may then be compared with
the goodness of fit statistics (automatically)
output for the output matrix.
SUBPQ L F If TRUE subtract PASSQ flows only from the
input counts; i.e., as SUBFIX but does not apply
to all fixed flows. See 13.3.1 and 13.4.8.
SUBSLQ L F If TRUE subtract flows associated with residual
PASSQ queues on links at the start of the time
period in addition to upstream PASSQ flows
under SUBPQ. See 13.3.1.
DEMAND L F If TRUE the count data as input to SATPIJA and
passed to SATME2 is assumed to be the
required demand flows and any factoring to
actual flows is ignored. See 13.1.4.2 above.
TOTALS L F T – Print the row and column totals of the output
matrix
PRINT L F T – Print the output matrix element by element
DUTCH L F T – Node input to define links/turns uses 10
columns rather than 5 – see 15.20
FREE6 L F T – Combined link data under 66666 is input as
free format, e.g., as CSV, rather than in fixed
columns.
ITERMX (*) I 30 Maximum number of iterations; see 13.3.1.
LEG I 2 Default constraint type for the counts input on
the .ufp file: (see 13.1.6)
1 – Less than
2 – Equality
3 – Greater than
SEED R 0.0 Seed value for ‘zero’ cells; see 13.3.1.
EPSILN(*) R 0.01 Convergence criterion
XAMAX R 5.0 Maximum balancing factor used to limit
excessive change to the old trip matrix. (N.B.
Minimum value is set by the inverse of XAMAX)
5120257 / Apr 15 13-20

Section 13

MODET I 1 Controls the output of messages to a terminal as
described in Section 6.3.2.
ODXMAX L F T – XAMAX is applied to O-D constraints as well
as links. See 13.3.1
ENCORE L F T – The prior trip matrix may come directly from
another run of SATME2. See 13.3.5
M2 L T T – Compare the prior and updated trip matrices
cell by cell a la M2
FRODO L F T – Include a matrix of “frozen” cells; see 13.1.6.
TLDBW R 60.0 The “bandwidth” used in trip length distributions
in (assumed) units of seconds; see 13.3.11.
FILICE Text Blank The pathname of the .ufm matrix file used to
define frozen cells when FRODO = T; see 13.1.6
FILTLD Text Blank The pathname of the .ufm cost matrix used to
define the trip length distribution; see 13.3.11.
(*) The program terminates if either ITERMX is reached OR all estimated and
observed link flows are either, in relative terms, within EPSILN of one another or
the upper/lower limits on their balancing factor limits are reached.
Additional data input follows the same general principle as used in the network
.dat files input to SATNET; i.e., each section is preceded by a 11111, 22222, etc.
record and terminated by a 99999 record. Data sections must be in increasing
numerical order and not all sections need to be included - indeed no additional
data need be included at all apart from records 7 and 8, the new matrix title.
The set of records must be terminated by a final 99999 record - and note that if no
data is included then a single 99999 record is still required.
RECORD(S) 1 CHANGE OF MIND RECORDS (OPTIONAL)

These records allow you to “over-ride” either the counts as input on the .ufp file or
else to re-define the type of constraint, e.g., to change an equality into a less than.
RECORD 1.1
Cols. 1-5 11111 start of the change of mind records
RECORD 1.2
One record for each link/turn count to be modified with format (if DUTCH = F):
Cols. 1 – 5 The A node
Cols. 6 – 10 The B node
Cols. 11 – 15 The C node
Cols. 17 The (new) constraint type:
5120257 / Apr 15 13-21

Section 13
L – Less than
E – Equality
G - Greater than
Or
X - Exclude from the calculations
Cols 18-25 The (modified demand) flow in pcus/hr
or, if DUTCH = T, 10 columns per node with constraint in col 32 and flow in cols
33-40.
The program will search the list of input counts on the .UFP file to find that one
with identical A- B- and C-node values and replace the constraint type and/or flow
with that specified. If the constraint type (col. 17) or the flow is left blank then no
change is made. An unmatched set of nodes results in a non-fatal error.
Note that the flow input is assumed to be the target demand flow, not an actual
flow as would be input into SATPIJA and potentially factored up to reflect flow
metering from queued junctions upstream. See 13.1.4.2.
The X or “exclusion” option is introduced so that if you find that one or more
counts are giving problems then they are removed without the potentially time-
consuming necessity of deriving a new set of PIJA factors.
Note that the definition of A, B and C are identical to that used as input to
SATPIJA (13.2.1 above) but the flow here occupies 8 columns not 5. Note
equally that if DUTCH = T a different format applies and each node occupies 10
columns, not 5; see 15.20).
RECORD 1.3
Cols 1- 5 99999 End of the change of mind records
One record for each link/turn count to be modified with format:
RECORD(S) 2 ORIGIN CONSTRAINTS (OPTIONAL)
RECORD 2.1
Cols 1- 5 22222 Start of the origin constraints
RECORD(S) 2.2
One record for each origin sum to be constrained with format:
Cols 1- 5 The zone name (N.B. NOT its sequential number)
Cols 7 The constraint type:
L - Less than
E – Equality
5120257 / Apr 15 13-22

Section 13
G - Greater than
Cols 8 – 15 The desired origin total flow in pcus/hr (as an integer)
If column 7 is left blank the default constraint type as specified by
the parameter LEG is assumed.
Note that if a range of zonal origin values is required (13.1.7) two
records are required with the same zone name in cols. 1-5.
RECORD 2.3
Cols 1- 5 99999 End of the change of origin constraints
RECORD(S) 3 DESTINATION CONSTRAINTS (OPTIONAL)
RECORD 3.1
Cols 1- 5 33333 start of the destination constraints
RECORD(S) 3.2
One record for each destination sum to be constrained with format:
Cols 1- 5 The zone name (N.B. NOT its sequential number)
Cols 7 The constraint type:
L - Less than
E – Equality
G - Greater than
Cols 8 - 15 The desired destination total flow in pcus/hr (as an integer)
(N.B. Destination flows must be factored up by the user into
“demand” flows as opposed to “observed” flows. See 13.3.2).
If column 7 is left blank the default constraint type as specified by
the parameter LEG is assumed.
RECORD 3.3
Cols 1- 5 99999 End of the change of destination constraints
RECORD(S) 4 ‘FROZEN ZONES’ (OPTIONAL)

Block definitions; i.e., specification of continuous blocks of zones for which all
associated movements (trips) are to remain unchanged by the estimation process.
Trips to, from and between these zones will be the same in the final and prior
matrices.
Note that it is also possible to define “frozen sectors”, i.e., aggregates of zones
(see 5.1.7), in which case it is necessary to insert an ‘S’ in column 1 under
Records 4.2 and to include the first and last sectors in columns 2-5 and 6-10.
5120257 / Apr 15 13-23

Section 13
Note that a second S is not necessary and, also, if the second sector is left blank
(or zero) it is assumed equal to the first.
RECORD 4.1
Cols 1- 5 44444 start of the frozen zone records
RECORD(S) 4.2
Cols 1- 5 Start zone name (not sequential)
Cols 6-10 Finish zone of block (greater than or equal to the start zone)
Record type 4.2 is repeated for each ‘frozen’ block of zones.
RECORD 4.3
Cols 1- 5 99999 End of the frozen zone records
RECORD 5 ‘FROZEN’ CELLS (OPTIONAL)

Cell list specification - for origin zone sequences a list of destination zones is
given. Trips in the defined cells remain unchanged by the program.
N.B. Both origin and destination zones are specified in terms of their zone names,
not by their sequential numbers.
As with the 44444 frozen zones cells may be defined at the sector level (5.1.7) by
inserting a S in column 1 under 5.2 below, in which case all entries on the line are
assumed to refer to sectors.
RECORD 5.1
Cols 1- 5 55555 start of the frozen cell records
RECORD(S) 5.2
Cols 1- 5 Start origin zone name (/sector if column 1 = S)
Cols 6-10 Finish origin zone name (> = start origin)
Cols 11-15 Number of destination zone pairs to follow
Cols 16-20 Start destination zone name (block 1)
Cols 21-25 Finish destination zone name (block 1)
Cols 26-30 Start destination zone name (block 2)
Cols 31-35 Finish destination zone (block 2)
etc. for further destination zone name pairs
Thus the number of entries to be read following column 15 will be twice the
number that appears in columns 11-15 up to a maximum of 12 per line.
5120257 / Apr 15 13-24

Section 13
If there are more than 6 “blocks” of destinations to be input then an appropriate

number of “continuation” records must be included with data input commencing in
column 16. Thus no data is read beyond column 75.
Record 5.2 is repeated for each set of origin zone sequences.
RECORD 5.3
Cols 1- 5 99999 End of the frozen cell records
RECORD(S) 6 ‘COMBINED CONSTRAINTS (OPTIONAL)

Combined constraints list 2 or more constraints which are to be considered as a
single constraint. See Section 13.1.8. Each different set of combined constraints
is input within its own “header” 66666 and “trailer” 99999 records in order to
accommodate multiple sets. Within each set it is only necessary to define the
links in terms of their A-node and B-nodes (plus C-nodes for turns), the individual
link counts must have been previously set.
If FREE6 = T then the nodes as input under Records 6.2 below are input in free
format rather than in the fixed columns.
N.B. The processing of the 66666 records and the creation of a “extended” .UFP
file including both single link constraints and combined constraints may be
particularly long-winded with large networks if locating individual link records in the
original .UFP file involves repeatedly re-winding the file. If, however, the individual
link records as input to SATPIJA are in the same order as the links referred to
under 66666 in SATME2 then the .UFP link data may be read essentially in a
single pass and the required CPU will be significantly reduced.
RECORD 6.1
Cols 1- 5 66666 start of a set of combined constraints (with any “title” following
66666 being displayed within the .LPM file)
RECORD(S) 6.2
Cols 1- 5 The A-node (In columns 1-10 etc. etc. under DUTCH = T or free
format if FREE6 = T))
Cols 6-10 The B-node
Cols 11-15 The C-node (if a turn)
RECORD 6.3
Cols 1- 5 99999 End of a set of combined constraints
RECORD 7 END OF THE OPTIONAL DATA INPUT (MANDATORY)

Cols 1- 5 99999 End of a set of combined constraints
5120257 / Apr 15 13-25

Section 13
RECORD 8 MATRIX TITLE (MANDATORY)

Cols 1 - 76 A title for the new output matrix.
END OF THE DATA INPUT

Thus an input data file might read:
&PARAM
SEED = 0.5
STATS = T
PRINT = T
&END
11111
58 1 779
10 65 X
32 33 1550
33 34 16 1600
45 53 52 G 300
46 47 L 100
99999
22222
12 = 800
14 L 400
4G 700
2L 400
24 E 900
20 1500
99999
33333
18 = 2700
1G 1400
5L 900
6G 300
7L 900
24 400
99999
44444
45
10 10
99999
55555
14 15 2 4 6 11 13
99999
55555
14
99999
99999
NEW TRIP MATRIX FROM SATME2
13.3 Advice on Using SATME2 and Extra Options

First of all it must be emphasised that the ME2 model and programs are still and
always have been to a certain extent experimental in nature rather than
standardised ‘black box’ procedures. It is therefore up to the users to decide upon
their own parameters and procedures in order to get the best results from the
programs. This section offers advice and explanations based on the previous
experience of the authors - suggestions for other points to be included here would
be very welcome.
5120257 / Apr 15 13-26

Section 13
In addition certain other options which may be invoked within SATME2 are
documented.
13.3.1 Choice of Parameters in SATME2

The full list of parameters which may be defined in SATME2 is given under 13.2.2
above. Perhaps the best advice is, when in doubt, use the default values.
However the following pointers may help:
ITERMX - The main factor here is run time which is roughly proportional to the
number of iterations. If you are not worried by this choose a large value. If you
are concerned perhaps the best policy is to try a run with a large value of ITERMX
- this should show that the rate of convergence slows rapidly with increasing
iterations, thus helping you to choose a value of ITERMX which represents a
suitable compromise between accuracy and cost for later runs.
Note that if ITERMX = 0 the program terminates before it enters the normal matrix
factoring steps – which may seem a silly choice but it is useful if one just wishes to
check the inputs or to view the goodness of fit statistics from the base matrix, etc.
etc. Thus it still produces a .ME2 file which may be viewed in P1X (see 13.9 and
11.8.5).
EPSILN - Same considerations apply here as with ITERMX.
SEED - If, equation (13.1), an input value of t ij = 0 than the output value T ij must
also equal 0. This is not necessarily what is required. Therefore zero - value cells
may be replaced by a “SEED” value. For example, a SEED value is set when it is
felt that the prior matrix contains an abnormally large number of matrix elements
equal to 0, and that these elements are due more to a restricted survey in which
relatively unlikely O-D movements were not picked up rather than to ‘true’ zeros.
The effect of setting a non-zero SEED is to produce a somewhat ‘smoother’ matrix
although the resulting goodness-of-fit statistics will probably not be very much
improved.
As described in Section 13.1.12 its use is only recommended “in the last resort”
and there are undoubtedly better, although almost certainly more complex ways to
deal with zero cells in a prior trip matrix.
In addition SEED should only be used for the simplest forms of matrix update,
e.g., with a single user class and a square trip matrix. A Serious Warning (which
may well be upgraded soon to a Semi-Fatal Error) results otherwise.
Note that SEED is not used when PRIOR = F since in that case all elements are
effectively seeded with an appropriate average value.
However, whether PRIOR = F or T, seeded values are only set for those IJ pairs
which pass through at least one of the counted links. Hence no adjustment at all
is made to elements in the trip matrix which are, in effect, ‘unobserved’. Equally
seeded values are not applied to matrix cells which are fixed or frozen; see 13.1.5
Note that if SEED = 0.0 and PRIOR = T, (i.e., updating a trip matrix with no
change to zero elements it may be worth setting the parameter ALLIJ in SATPIJA
to .FALSE. so that PIJA’s are not calculated for cells where T ij = 0; this may
5120257 / Apr 15 13-27

Section 13
considerably reduce the size of the UFP file if there are a large number of such
cells.
XAMAX - In general one would expect the link balancing factors (X a in equation
(13.1)) in the ‘update’ mode (PRIOR = T) to be somewhere near 1, and a
balancing factor very much different indicates that the corresponding count is very
different from what the original matrix would have given. This may therefore imply
that the count itself is unreliable. By setting maximum and minimum values on the
balancing factors we therefore limit the effect that any one count can have. On
the other hand with PRIOR = F one should probably allow larger values of XAMAX
since in this case we have much less reason to suspect that the initial ‘flat’ matrix
should give reasonable link flows.
It should also be borne in mind, see equation (13.1), that an individual ij pair may
use several counted links so that the maximum change possible in T ij could be
XAMAX to the power n, where n is the number of counted links, each at a factor
XAMAX. There is a case therefore for reducing XAMAX considerably, e.g., to a
value of 2.0 or even less, if you have a large number of counts that could be used
multiple times.
One useful strategy might be to start off with the default value of XAMAX but, if it
seems appropriate, to reduce it for later runs. There is a case for at least seeing
initially what size of X a factors are required and how many counts require the
maximum/minimum before enforcing a stricter criterion.
ODXMAX – By default (ODXMAX = T) the max/min factors set by XAMAX apply
to both link counts and o-d counts (if any). Setting ODXMAX = F effectively “de-
couples” o-d counts from link counts such that the o-d counts will always be
satisfied independent of the size of factor required to do so. Thus if the o-d counts
are a long way away from the equivalent sums in the prior trip matrix then an
exact balance will be achieved.
However, it should be noted, that if you do need to set ODXMAX = F then it
almost certainly means that you should have paid more attention to setting
realistic o-d totals in the input prior matrix yourself rather than passing the buck to
SATME2. Alternatively, it may be that the o-d counts and the link counts are
mutually incompatible and that the program is having difficulties in balancing both.
In either case you need to check your inputs carefully.
SUBFIX - In general this should be TRUE on the assumption that you wish to
update a full trip matrix and that the counts include both assigned and fixed
components. Exceptions to this rule include (a) updating a sub-matrix under MUC
assignment (see 13.4.8 below), in which case it should almost certainly be FALSE
on the assumption that the counts are specifically for one class of vehicles; and
(b) when there are no fixed flows, in which case the value of SUBFIX does not
matter.
SUBPQ – This is a special case of SUBFIX where only the PASSQ element of
the fixed flows is subtracted from the counts. Since the PASSQ flows arise from
queued elements of the trip matrix from the previous time period, not the current
trip matrix which is being updated from counts, they should not be included in the
update procedure. Hence we would recommend, if there are PASSQ flows, to set
SUBPQ = T if SUBFIX is not already set to T. See also 13.4.8.
5120257 / Apr 15 13-28

Section 13
SUBSLQ – This, in turn, is a special case of SUBPQ whereby if there is a residual

queue Q on a link (A,B) following a PASSQ assignment for the previous time
period then SATURN introduces an extra component of the entry flows equal to
Q/LTP (see 17.3.1). If SUBSLQ = T (default = F) and SUBPQ = T then this flow is
also subtracted from the target count, the presumption therefore being that the
count was taken at the stop line and would therefore include the traffic which was
in the initial queue as well as the “new” traffic for the current time period which
SATME2 is seeking to estimate. See also 13.3.4
13.3.2 Origin and Destination Constraints

It is very common in SATURN networks that observed counts correspond exactly
to the numbers of trips entering or leaving a specific zone, the most obvious
example being at cordon points where the ‘zone’ represents trips entering and
leaving the network at that point. In these cases the constraints may be defined
equally by specifying the link in the input to SATPIJA or by specifying the zone in
the input to SATME2, the mathematical treatment of the constraint being the
same in both cases. It is however recommended that such constraints be defined
as part of the input to SATME2, since in that case the redundant calculation of
PIJA factors is avoided. (Since it is clear that all IJ trips from a zone connected to
a single cordon link must use that cordon link.)
Note however that some care must be exercised in the definition of the origin or
destination constraints where there are ‘fixed’ flows in the network due, for
example, to bus routes. As mentioned above SATME2 subtracts any bus flows,
etc. from the link constraints since the trip matrix to be estimated only contributes
to the ‘un-fixed’ flows. However no such correction is made by the program for
zonal constraints, in which case users must supply their own corrections prior to
input. For example if a cordon link has an in-bound observed flow of 800 pcu per
hour, of which 60 are due to buses (e.g., 20 buses per hour with a BUSPCU factor
of 3.0) the correct input value as a link constraint to SATPIJA would be 800
whereas it would be 740 as an origin constraint to SATME2.
A second complication is that any constraints for flows into zones in the simulation
network must be converted by the user into “demand” flows to account for the fact
that the flow actually reaching that zone may be reduced by the presence of over-
capacity junctions in the network. Appropriate factors may be determined by
using the “selected zone” option in SATLOOK. These corrections do not apply to
origins, for which there is no restriction due to queuing, or to the buffer zones.
OD constraints are applied by choosing appropriate balancing factors X a in
equation (13.1) (by definition raised to the power P ija = 1) and should normally be
satisfied exactly since they are applied after all the link balancing factors are set
(unless there is some gross incompatibility between the origin and destination
totals). Note, however, the use of the parameter ODXMAX 13.3.1 which controls
whether or not min/max limits are put upon X a via XAMAX.
13.3.3 Inconsistent Observed Counts: Kirchoff’s Rule
13.3.3.1 Examples of Inconsistency

Problems can arise with ‘inconsistent’ observed flows, the simplest case to
visualise being the not infrequent case where the observed flows into a node do
5120257 / Apr 15 13-29

Section 13
not equal the observed flows out, in violation of “Kirchoff’s Rule” (as originally
applied to electrical circuits). However, more complicated situations may also
arise with two counts (or sets of counts) which are physically separated by
intervening links but where the assignment pattern is such that all flows using the
first count (set) must be routed through the second. A further example of
inconsistencies between counts and assignment was given in 13.1.8. Equally
frozen cells may create problems.
The common thread in all such cases is that it is not mathematically possible to
calculate a trip matrix which will satisfy all constraints.
Similar, but slightly less severe, problems may occur with counts that are, strictly
speaking, consistent in that trip matrices that satisfy equations (13.1) do exist but
which, given the assigned routes, frozen cells, etc., would involve severely
distorting the original matrix.
To a certain extent inconsistent counts as above may simply cancel one another
out. For example, if counts have been taken on the same road above and below a
pedestrian crossing node and they differ – so that Kirchoff’s Rule is violated at the
pedestrian crossing - the higher flow will continually attempt to increase the flow
through it by increasing its X a factor until it reaches the maximum allowed value
XAMAX while the lower flow will go in the opposite direction until its X a factor
reaches the minimum 1/XAMAX. The two multipliers will then cancel one another
out so that, in effect, the two counts have been removed. At more complex
intersections the end effect may not be that “simple”.
Inconsistent counts generally manifest themselves by problems of non-
convergence or very slow convergence within SATME2 whereby the loops are
terminated by the maximum number of iterations ITERMX rather than the EPSILN
criterion. They are also indicated by a large number of X a factors at either their
minimum or maximum values.
The obvious solution to these problems is to remove or modify the inconsistent
counts before carrying out the ME2 calculations but, clearly, this is easier said
than done. However, certain analyses and statistics output by SATPIJA and/or
SATME2 may help the user to detect the problems.
13.3.3.2 Violations of Kirchoff’s Rule

Thus, in SATPIJA post release 10.8.17, a series of calculations is carried out to
detect and print direct violations of Kirchoff’s Rule, i.e., flow in does not equal flow
out, using the counts as input to SATPIJA. (N.B. these are not necessarily the
same counts that will be used in SATME2 due to the possibility of “Change of
Mind Records” but they are certainly indicative of potential problems.)
Secondly, within SATPIJA, if a node has, counts on all its input arms and on all
but one output arm (or vice-versa) then the flow on that output arm is equally
constrained. In these cases SATPIJA compares the “implied” count with the
currently assigned link flow and reports as a Serious Warning those cases where
the differences between the two flows give rise to a GEH value greater than 5.0
and where, presumably, SATME2 would “struggle” to find a consistent solution.
5120257 / Apr 15 13-30

Section 13
An extreme example of an implied count – effectively a Kirchoff violation as above

– can occur if the implied count is negative; again, there are no possible matrix
solutions.
(The “geometry” used in these calculations is actually somewhat more
complicated in that the presence of banned and U-turns may allow more than one
set of “Kirchoff tests” to be carried out on different sub-sets of arms at the same
node. Equally, if a counted link has only one possible exit link then the count
constraint may be “extended” to the second and any subsequent links allowing a
wider range of consistency checks to be carried out.)
Note that the Kirchoff tests are carried out using the “assignment network
definitions” (see 5.5.1), i.e., with simulation nodes expanded and individual
assignment nodes at either end of simulation roads. This implies that flows to and
from zones are included in the summations of flow-in and flow-out.
N.B. It is possible to run SATPIJA in a “check-only” mode, i.e., so that it
processes the counts and checks for the obvious Kirchoff etc. errors above but
does not do any of the P ija calculations or output a .UFP file. To invoke this option
set the parameter PREUFP to .TRUE. in the control file; see 13.2.1.
Within SATME2 inconsistencies may sometimes be detected with full output
statistics (PRINT = T) by links which appear to be converging to values other than
the observed counts, or by a large number of link factors at either the minimum or
maximum levels, indicating that certain counts are trying to “pull” as hard as
possible in two different directions and not getting anywhere.
13.3.3.3 AVERK: Correction of Inconsistent Counts

Post release 10.8.20 an option is provided to automatically correct inconsistent
counts which violate Kirchoff. Thus, in SATPIJA, if the &PARAM parameter
AVERK = T, for every node where a Kirchoff violation has been identified the
average of the total in-bound flows and of the out-bound flows is calculated and all
counts are factored up/down to match the average. The updated flows, both “input
flows” and “target flows”, are included within the output .UFP files and will
subsequently be processed within SATME2.
Clearly simple factoring up/down Kirchoff violation flows does not help in the
situation where one of the counts is a “rogue” and the others are all genuine.
There are also potential problems of “interactions” whereby a single count might
be adjusted at both its upstream and downstream nodes and the two are
contradictory.
Nor does AVERK deal with problems whereby the inconsistencies arise from a
combination of the counts, the assigned OD routes and the prior matrix.
Ultimately it must be up to the user to detect problems and to adjust the counts to
more correct and consistent values.
13.3.3.4 FILKP: Output of Corrected Counts

If a filename FILKP is defined under &PARAM in SATPIJA and AVERK = T then
an output ascii file is created containing standard link identification (i.e., A B for a
link, A B C for a turn) plus the corrected counts.
5120257 / Apr 15 13-31

Section 13
13.3.3.5 Common Causes of Kirchoff Violations

From an examination of several real-life files in which examples of Kirchoff
violations were detected the following are (possible) explanations of the sources
of the problem.
1) Basic statistical variability in the counts. This arises if counts have been taken
on different days or even different years (and presumably factored to a
common year), in which case the degree of inconsistency is relatively small
(and corrections using AVERK will probably deal with it).
2) Link transcription errors. It may happen that a link count is attributed to the
wrong link, one example of this being a count that was taken on an on-ramp
leading to a motorway and mistakenly coded as a count on the motorway.
3) Count transcription errors. The count is transcribed incorrectly; one example
found being of a 2-arm node where the flow on one side was, say, 1165 and
the flow on the other was 118 – so most probably the final digit was lost.
4) Network coding errors. If a junction has, say, two links in and two links out
with flows of 500 on each there is no problem. If, however, one of the entry
links had been left out there will be a Kirchoff violation because we have an
entry flow of 500, an exit flow of 1,000 and no other entry arms to which the
missing flow of 500 can be attributed.
13.3.3.6 Order of Counts

One perhaps useful piece of empirical advice is to try to put the most ‘reliable’ or
‘important’ counts near the bottom of the input list since the last counted links are
balanced last in the iterative procedure.
13.3.4 Link (Centroid Connector) Entry Flows in the Simulation Network

It is important to appreciate that due to the method by which zones in SATURN
are connected to simulation links the flow on such links may be defined in three
distinct ways: (i) as the flow at the upstream end before the flow into the zone is
removed, (ii) as the flow along the link itself, and (iii) the downstream flow which
includes any flow entering from the zone. Somewhat arbitrarily SATPIJA
assumes that the count refers to the flow at the MID-POINT of the link, so that any
flows to or from zones are excluded. In defining input flows the user must take
into account how much flow is observed (or modelled) to enter and/or leave zones
and to reduce the “observed” flow by an appropriate amount.
Due to this potential ambiguity in the definition of flow it is perhaps advisable to
avoid counts on links with zones attached or, if this is important information, to
make sure that the zone connection is defined in more precise terms as described
in Section 16.6. Further details on counts to “bridged” links are given in Section
15.16.
Similarly, if the network for which trip matrices are being estimated is part of a
PASSQ multiple time period model, then any residual queues at the link stop-line
from the previous time period are also modelled as entry flows at the stop-line
(see 17.3.1). Hence they also create problems in unambiguously defining flows
and counts on links. It is possible, post 10.9 and using the parameter SUBSLQ
5120257 / Apr 15 13-32

Section 13
(see 13.3.1), to subtract the residual queues from the counts or not depending on
whether the count is assumed to be taken at the stop-line itself or mid-link
(upstream of any residual queues).
However, given these ambiguities there is a strong case for not including such
counts within ME2 on the basis that they are not actually adding information about
O-D travel patterns but simply confusing the issue. In addition, if the link continues
to queue in the current time period (or, strictly, is modelled to queue) then it could
be argued that the count is actually giving you more information about the link
capacity rather than flows and should be used to calibrate the link capacity (e.g.,
by adjusting saturation flows) rather than within SATME2.
N.B. None of the above problems apply to counts on turning movements where it
is assumed that the counts are taken at the junction. However see 13.3.8 for a
discussion as to the advisability of using turn counts in the first place.
13.3.5 Possible Confusion between ‘Prior’ and ‘Latest’ Matrices

When using SATME2 in the update mode (PRIOR = T) it is important to
differentiate between the matrix to be assigned at each stage and the matrix input
as the prior matrix to SATME2. The assigned matrix should always be the most
up-to-date matrix, i.e. from the latest run of SATME2, whereas the prior matrix is
always the same one. Allowing a matrix output from SATME2 to be re-input to
SATME2 introduces a basic inconsistency into the results in that correction factors
from several different runs will all appear in the final matrix.
From version 10.5 on it is a fatal error to use a prior .ufm matrix which was itself
created by a run of SATME2 – unless the namelist parameter ENCORE is
explicitly set to .TRUE, within the control file (13.2.2). (There is, as yet, no check
that the input prior matrix may have originally come from SATME2 but have been
modified by another program(s) in between.)
It is highly recommended that users make use of the ‘PRIOR’ option within the
SATME2 command line (see 13.7.2) to explicitly define the prior matrix each time
SATME2 is run since otherwise it is possible that, if PRIOR = T, the default is to
use the trip matrix as originally used in SATPIJA which, in turn, may have
defaulted to the trip matrix used in the .ufs file input to SATPIJA. Which is to say,
the last matrix used in an assignment which, as explained above, is not
necessarily what is desired. The “ENCORE” parameter may protect against this
happening but not necessarily.
13.3.6 Unobserved O-D elements

O-D pairs which do not use any of the counted links in the network can, in effect,
be given totally arbitrary values since these values will not affect the observed
counts. However the following assumptions are made by SATME2: (i) In the
update mode (PRIOR = T) any such elements retain their input value, and (ii) with
PRIOR = F they are set to zero. Hence in the latter case we make the implicit
assumption that an unobserved element is in fact an impossible trip.
13.3.7 The Effect of Bottlenecks on Downstream Counts

A not uncommon situation in SATURN is to have a counted link downstream of a
bottleneck whereby the actual flow on the link is controlled by the capacity of the
5120257 / Apr 15 13-33

Section 13
bottleneck rather than the demand trip matrix. This can lead to problems of
inconsistencies in SATME2 if, for example, you have a counted flow of, say, 1500
pcu/hr immediately downstream from a link whose (SATURN - estimated) capacity
is 1000 pcu/hr - either the count or the capacity is wrong. In fact this is an extreme
example of the effect of flow metering on counted flows (see 13.1.10) where, in
this case, the flow metering affects 100% of the traffic and occurs immediately
upstream.
The practical problem that this gives rise to in SATURN is one of potential
exponential growth in the demand trip matrix if one iterates between matrix
estimation and assignment. For example, in the above case imagine the
bottleneck and count are fed by a single OD pair whose initial cell value is 2000 -
of which 1000 will queue at the bottleneck and 1000 will reach the counted link.
Therefore on the first iteration only 50% of the demand reaches the count and
therefore the “demand target” is factored up from 1500 to 3000 - see 13.1.3. To
achieve this demand target the first run of ME2 increases the trip matrix to cell to
3000. However on reassigning the new matrix again only 1000 pcus -  of the
total - reach the count, so that the new demand target becomes 4500. Each
succeeding iteration continues to increase the trip matrix without ever satisfying
the count.
The short-term solution to the above problem is clear – either remove the count or
remove the bottleneck. The long-term solution may well be to enable the model to
recognise the situation and take appropriate action.
13.3.8 Turn vs. Link Counts

SATME2 will accept counts which correspond either to a “pure” road link or to
“turning movement” links (within simulation networks). Clearly if you have counts
on all exits from an in-bound link then you also have the total flow on the in-bound
itself. Equally clearly using both sets of count data – link plus turns - as inputs to
SATME2 is “double counting” since if the turning flow constraints are satisfied
then so too is the link constraint. In this case you need to use one or the other,
Turn counts have the advantage of containing extra information which may help
SATME2 in differentiating between different o-d pairs to be factored. On the other
hand the extra level of disaggregation in turn counts means that they are probably
less reliable, statistically speaking, in which case they may do more harm than
good.
Generally speaking, our advice would be, if you have the choice between using
links and/or turn data, to at least start by using the link data and then, if the
changes seem sensible, add the turn data. If the outputs seem “even more
sensible”, keep them in; otherwise go back to the pure link constraints. A warning
message appears in the output .lpj file from SATPIJA to warn you if both
simulation link and turn counts are used.
The SATPIJA control parameters SET777 (see 13.2.1) may provide a useful
mechanism in this context to include/exclude turn counts. Thus, if you put all link
counts within the first 77777 data set and all turn counts in the second, then
setting SET777(1) = T and SET777(2) = F will automatically include only link
counts in SATME2 but still leave you the possibility to use the turn counts for
other validation purposes.
5120257 / Apr 15 13-34

Section 13
Alternatively you could use the mechanism for combining counts together (13.1.8)
to aggregate turn counts into link counts but, given the extra effort of specifying
the combined constraints within SATME2, it is probably better to do it in other
ways.
13.3.9 Choice of Count Sites

The above discussion as to whether link counts should be used in preference to
turn counts may be broadened to the question of how many count sites should be
used and where they should be located. Unfortunately there is no simple or
unique answer to those questions and opinions probably differ widely between
different practitioners.
As a general rule it is probably best (if possible) to select sites which lie “in
parallel” rather than “in series”, for example, along well defined continuous screen
lines or cordons rather than both entry and exit links at a single junction. Thus a
cordon guarantees that all o-d pairs with an origin on one side of the cordon and a
destination on the other must cross at least one count site and each cordon point
contains a different set of O-d path flows.
By contrast, links which are “in series” give information on the same path flows
which is either repeated or contradictory. For example, if link A-B feeds directly
into B-C with no cross links then the same path flows use each and V A-B must
equal V B-C . If the counted flows on both are the same then there is no new
information in the second count; if they differ then there is clearly no possible
solution that will satisfy both. Having counts on a link and all its exit turns (13.3.8
above) is another example of the same phenomenon. A “warning” is generated in
SATPIJA if any examples of links “in series” are found and a list of the “middle
nodes” is given.
A random selection of sites is not recommended since they are neither likely to
include continuous cordons nor are they likely to exclude links in series
13.3.10 Selecting a Sub-set of Counts: Count Reliability

A not uncommon problem with matrix estimation is that of having too many counts
rather than too few, coupled with the problem that certain counts may be
statistically more reliable (and/or useful to the estimation process) than others.
Since there is no mathematical option within SATME2 for weighting different
counts according to their reliability (all constraints as embodied in equation (13.1)
are effectively equal) some method for selecting an optimum sub-set must
therefore be devised.
Thus, it may be best to start with a relatively small number of “good” counts and, if
no problems are encountered, to build up the number of counts as long as they
appear to be leading to an improved output matrix. The “shotgun” approach of
throwing in every single available count at the first opportunity should be avoided.
One obvious strategy, if the available counts have been obtained using different
methods (e.g., automatic counts versus manual classified counts) over varying
time periods such that, a priori, certain counts should be more reliable than others,
is to start with the most reliable counts. However there are also competing
considerations, e.g., that counts should be in parallel rather than in series as
discussed above (13.3.9) and that it is useful to have counts spread over the
5120257 / Apr 15 13-35

Section 13
whole network rather than, say, concentrated in a city centre where the most
reliable counting methods have been employed.
On the other hand, even if a count is deemed to be highly reliable, it may be
somehow inconsistent with the assigned paths and/or other counts (possibly
evidenced by a value of X a at its minimum or maximum value) and it is therefore
best to remove it.
There is also a reliability issue related to the “order” in which counts are input as
discussed in 13.3.3.6; essentially there is a case for putting the most reliable
counts at the bottom of the input lists so that they are more likely to be exactly
satisfied.
An alternative (and not necessarily highly recommended) strategy for dealing with
less reliable count constraints – or counts which are proving difficult to satisfy – is
to convert them into less than / greater than constraints (13.1.7). For example, if
one has a not very reliable link count of 1,000 which empirically appears to be
difficult to satisfy even with X a at the maximum value of XAMAX it may make
sense to replace it by a >=900 constraint. However the problem with replacing all
unreliable counts with GT/LT constraints is that: (a) one does not know a priori
which alternative should be selected and (b) the problem with a GT/LT constraint
is that even if ME2 can easily satisfy the exact constraint with a GT/LT constraint it
simply stops when it hits the upper/lower boundary.
Unfortunately removing and/or ordering and/or redefining constraints is more an
art than a science and users will need to deal with the problem manually on a
case by case basis. What is, however, virtually certain is that if some selection of
counts is not undertaken the resulting output trip matrices will be sub-optimal. If
you treat ME2 as a black box sausage machine you will wind up with egg on your
face (to mix culinary metaphors!).
13.3.11 Before and After Trip Length Distributions

Trip length distributions may be compared between the original (prior) and output
trip matrices by defining:
a) a .UFM matrix to define “length” FILTLD (e.g., cost, distance, time etc.); and
b) a “bandwidth” for the distribution BWTLD.
Both are set under &PARAM inputs in the control file (13.2.2). The output is the
form of a numerical table giving both the frequency and cumulative distributions
plus average trip lengths.
These outputs may inform the user as to whether the ME2 adjustments are
producing more short and/or long distance trips.
Note that trip length distributions may also be obtained independently using MX;
see 10.9.3.
13.3.12 Table 10: Count Sensitivity Statistics

A question of interest with ME2 is how much impact each individual count
constraint has on the final output trip matrix or, viewed in reverse, how sensitive
the trip matrix is to each count. Table 10 in the .LPM files, calculated after all the
5120257 / Apr 15 13-36

Section 13
ME2 calculations have taken place, lists a number of relevant statistics per
constraint and defines three different “sensitivity ratios” which may help to identify
“problem counts”.
However, it is not possible to define a single unambiguous measure of sensitivity
per constraint and the interactions between counts and output matrices are
complex. E.g., it is not possible to say that adding one extra pcu/hr to a given
count will generate X extra pcu/hr in certain cells in the trip matrix; there is a large
degree of overlap between the various counts as well as problems of non-
uniqueness (see 13.1.9).
The statistics provided and their interpretation is as follows:
LINK Flows IN / OUT / Diff (DF): The first two numbers give the total (demand)
flows assigned to the link using the original trip matrix and the output trip matrix.
Their difference, DF, represents the net impact of running ME2 on this link.
TIJS IN / OUT: This column gives the sum of all T ij which are assigned to the link
in question independent of the proportion assigned per path (i.e., the sum of T ij
where P ija > 0 whether P ija = 0.999 or 0.001). These numbers are always, by
definition, greater than those in the previous column by virtue of the fact that the
former are all reduced by, in effect, the P ija factors. The ratio of, say, Flows(IN) /
TIJS(IN) would represent a weighted average P ija factor for that link.
Their difference, DT, is a measure of how much the trips associated with link A
have been adjusted as a result of running ME2.
DT / DF: The ratio of DT to DF represents, in a certain sense, the “sensitivity” of
the changes in the trip matrix to the corresponding changes in link counts. Ideally
this should be as close to 1.0 as possible indicating that for every trip
added/subtracted on a counted link there has been a corresponding trip added to /
subtracted from the trip matrix. A ratio >> 1.0 indicates that major changes have
had to be made to the trip matrix in order to satisfy that particular constraint.
Equally a negative DT/DF ratio may be taken as an indication that the changes on
that link are “going against the flow” of all the other changes and that, possibly,
this count is inconsistent with the other counts.
However, a conceptual problem with DT, and therefore with DT/DF, is that DT
includes all T ij cells using a link without regard to their level of usage, i.e., P ija ; the
next two measures take usage into account.
Cumulative Changes to Tij : the summation of all changes to T ij throughout the
internal ME2 algorithm iterations each time X a is adjusted.
Changes to Tijs if XA = 1: the summation of all changes to T ij if X a were re-set to
1.0. This uses the formula:
∆T = Σ T ij (1 – X a –Pija )
Note that a negative value of ∆T indicates that (using) the count acts to reduce the
total trip matrix by this amount and, conversely, that a positive value indicates that
the count increases the matrix by this amount.
Arguably this represents the best measure available to assess the effect of using
the count but it does not tell us exactly what the effect of not using the count
5120257 / Apr 15 13-37

Section 13
would be. For example, in an extreme case, if we have the same count on two
consecutive links separated by a pelican crossing, it is essentially arbitrary which
count has an X a factor of 1.0 (i.e., is “inactive”) and which has an “active” X a
factor. If we remove the active count the second would become active and the
updated matrix would be the same.
Equally other counts may be actively factoring the same cells in an opposite
direction, thus negating the effects of this particular count. If we were to re-run
matrix estimation without the count then the factors for these other counts would
be slightly closer to 1.0 since they would not have to “work so hard” to counter the
effect of the count that had been removed.
In general one would expect that ∆T represents an over-estimate (in absolute

terms) of the effect of removing that count.
The ratios of both these statistics relative to DF provide similar “sensitivity
measures” similar to DT/DF and a similar interpretation might be applied. Thus
values >> 1 or negative values might indicate problems of consistency with the
counts.
13.3.13 Errors in SAVEIT Flows/Routes

Since, for Frank-Wolfe assignment at least, the analysis of PIJA factors is based
on the routes as calculated by the “SAVEIT assignment” as opposed to the
“proper” assignment there is a possibility that, due to a lack of proper convergence
between the two, the flows through the counted link identified by the PIJA factors
by SATPIJA will not agree with the actual assigned flows (see Section 15.23.2).
This means that SATME2 will subsequently be in error as it will be trying to match
the “wrong” flows.
Most of the time any errors due to this effect will be small compared to all the
other potential errors but, sometimes, they may prove to be significant.
Post release 10.8.20 the potential for such errors has been assessed in SATPIJA
by taking a GEH difference between the total actual assigned flows and the
SAVEIT assigned flows for each counted link. If GEH exceeds 5 this is identified
as a Serious Warning; if GEH exceeds 1 (but is less than 5) it is a Warning. The
total number of both Warnings and serious Warnings are included within the error
messages summary at the end of the .LPJ file which is also passed to SATME2.
We note, however, that post 10.9 the errors in the SAVEIT assignment may be
reduced to effectively zero by setting UFC109 = T in the network .dat file such that
the OD paths generated by the .UFC files are identical to those generated during
the assignment; see 15.23.3.1. In certain circumstances this has proved to be
extremely beneficial (although the downside is that it may increase the CPU time
required by SATPIJA).
13.3.14 The Choice of .UFC or .UFO Files to Generate OD Paths: USEUFO

OD paths from a Frank-Wolfe assignment may be, in effect, be recreated using
either a .UFC file – in which case the individual paths from each FW iteration are
rebuilt using the original costs and weights per iteration – or a .UFO file – in which
case the routes are recreated by “splitting factors”; see 15.23.6. UFO files enable
once-through algorithms to be employed and are therefore considerably faster
5120257 / Apr 15 13-38

Section 13
than .UFC files but, on the other hand, they may require extra CPU time to create
them in the first place; see 15.23.7.
If both a .UFC and a .UFO file exist for a particular network then either may be
used by SATPIJA; the choice is controlled by a Namelist parameter USEUFO
(13.2.1). The default is to use a .UFC file (on the basis that .UFC files are almost
always created by a SATURN assignment, .UFO less frequently); however, given
that the PIJA calculations are generally much, much faster using .UFO, the
recommendation is to set USEUFO = T.
Note that if a network has been run using OBA then the use of a .UFO file is
effectively mandatory since there is no .ufc file.
13.4 Updating Multiple User Class O-D Matrices
13.4.1 Basic Principles and Options

The procedures for estimating/updating trip matrices when following a Multiple
User Class (MUC) Assignment procedure, as described in Section 7.3, are similar
in principle to updates within a Single User Class Assignment but may be
somewhat more complicated in practice. Whilst the basic objective is still to
update matrices to satisfy count constraints as expressed by equation (13.1); the
difference is now that both the matrices and/or counts may be disaggregated by
user class.
As noted in 7.3.2.1 there are several ways in which MUC trip matrices may be
specified.
The first and simplest – though least common – situation is to have a single
(square) trip matrix where each user class OD flows are a fixed proportion of the
total flows as specified within the 88888 data records on the network .dat file (see
Section 6.11).
The second situation- at the other extreme and probably the most common – is
where each user class has its own distinct trip matrix.. In this case, each of these
trip matrices are “stacked” into “levels” in a single .UFM file. Further details may
be found in sections 13.4.3 and 13.4.4 respectively.
The third, intermediate situation is a combination of the previous two whereby the
some user classes share the same sub-matrix/level whilst others have their own
exclusive matrix/level. For example, a 5-UC model might consist of three matrix
levels
♦ the first matrix level representing car trips split by fixed proportions into three
purposes (say, Work, Education and Other);
♦ the second matrix level representing LGVs only; and
♦ the third matrix level representing HGVs only.

Ideally vehicle classes (see 5.8.2 and 6.11) should be defined for each of the five
user classes to distinguish cars, LGVs and HGVs (see 13.4.4 and 13.4.5).
Alternatively, we could, in the above example, have three separate stacked matrix
levels for car trips instead of the single one, say Work, Education and Other,
5120257 / Apr 15 13-39

Section 13
which are not simple proportions of a common car trip matrix. However, assuming
that we could only observe total car flows, only the sum of the three matrices may
be updated, not the individual matrices (see 13.4.6).
Similar levels of aggregation/disaggregation must also apply to the constraints.
For a single un-stacked trip matrix divided into user classes by fixed proportions
we require a single set of counts aggregated over all user classes. If each user
class has a separate trip matrix then ideally we need a set of observed counts per
user class. If this is not possible; alternative methods are available (see 13.4.6 for
more details).
In order to apply ME2 in the above 5-UC three-matrix example we would need
observed link counts disaggregated by car/LGV/HGV; each separate set of counts
would be used to update the corresponding trip matrix level. But, unless we had
some way of distinguishing three separate purposes for observed car counts, it is
not possible to apply separate matrix estimation by purpose.
Equally, if we had three separate stacked matrices for car trips by Work,
Education and Other which are not simple factors of a common car trip matrix and
we can only observe total car flows, only the sum of the three matrices may be
updated, not the individual matrices (see 13.4.6 below).
Therefore, in terms of MUC ME2, we shall assume that we have a set of one or
more prior trip matrices, each one of which constitutes a separate level within the
assigned stacked trip matrix or is the sum of two or more UC/levels, and a
corresponding set of observed flows which we wish to use to produce improved
estimates of those matrices in order to satisfy equation (13.1).
The next section considers how SATPIJA identifies the sub-matrices to be
analysed for Pija factors while the following sections consider different options for
using SATPIJA and SATME2 together.
13.4.2 SATPIJA Options for Defining User Classes: KLASS, LEVEL and IVC
Within SATPIJA the set of one or more user classes for which Pija factors are
required are set using the three parameters KLASS, LEVEL and IVC:
a) A single user class (set by KLASS),
b) All user classes based on the same “level” of the input stacked trip matrix (set
by LEVEL)
c) All user classes which share a common “vehicle class” (set by IVC).
In cases (b) and (c) the output PIJA factors are “weighted” averages of the user
classes within that level; see equations (13.5) and (13.6) respectively. Under (a)
the value of LEVEL is effectively set by the matrix level used by user class KLASS
as defined in the .UFS network file.
Only one of these parameters needs to be specified; if the MUC assignment is
structured so that each user class corresponds to a separate level in the trip
matrix then either KLASS or LEVEL may be used (or, if both are specified, belt
and braces, they must be equal).
5120257 / Apr 15 13-40

Section 13
Option (a), to analyse a single user class KLASS, is not always appropriate since
it may be difficult to associate counts with a particular user class. For example, if
you had car trips split by purpose into separate sub-matrices, each with its own
level, it might not be possible to similarly disaggregate observed counts of cars by
purpose/level. However, this would not apply if, say, HGVs were specified as a
single user class / level and HGV counts could be easily identified separately.
Note that defining a single value KLASS is only possible if the trip matrix for that
user class is defined in a discrete level; if it “shares” its matrix level with other user
classes it is not possible to do a “partial” update of that level.
In the most common case of a single trip matrix all three parameters LEVEL,
KLASS and IVC are redundant; in effect, all three equal to 1.
13.4.3 Single Level Shared Trip Matrix

Let us first consider the simplest case where there is just a single “square” trip
matrix to be assigned and the various user classes are defined as shared
fractions (weights; see Section 6.11) of that matrix. Equally we have a single set
of observed counts corresponding to the total assigned flows. The problem is
therefore essentially identical to that of a single user class.
The procedure followed is therefore virtually identical to that described in Figure
13.2 for a single user class assignment. Within Control File A (input to SATPIJA)
set LEVEL to 1 (the default), KLASS and IVC to zero and specify counts
corresponding to TOTAL flows. The output .UFP file is then a weighted
summation of all O-D routes used by all user classes defined by:
Equation 13.5
= ∑ P ijaW
m m
P ija
m
where Pijam is the normal Pija factor for user class m and Wm is the “fraction” of
the trip matrix associated with user class m as defined within columns 11-15 of the
88888 data records within the original network .dat file
All matrix files shown in Figure 13.2 are simple square trip matrix files (i.e., not
stacked) and SATME2 updates that single trip matrix.
13.4.4 Multiple Level Stacked Trip Matrices: Updating Levels via Separate Matrices
In a more complicated case the trip matrix may contain several different sub-
matrices stacked by level with distinct user classes being defined as universal
factors of a single level (where the factors are input under the 88888 data in a
network .dat file). Most commonly a particular level will correspond to a single
user class, in which case the factor should be 1.0; less frequently a level will
contain multiple user classes, in which case the sum of the factors should be 1.0.
In the former case updating a level is fully equivalent to updating a single user
class.
The objective is therefore to update each separate level using a correspondingly
aggregated set of constraints. There are two basic ways to proceed: either:
5120257 / Apr 15 13-41

Section 13
a) Users may first unstack the trip matrix into individual square trip matrices,
update each sub-matrix/level individually and finally re-stack them; or
b) Users may (post 10.8) update an individual level within the full stacked matrix
while leaving the “other” levels unaltered.
Both cases require separate runs of SATPIJA to calculate PIJA factors and
SATME2 to update the matrix for the designated level; i.e., it is not possible to
produce multiple sets of Pija factors using SATPIJA and/or to update multiple
matrix levels within SATME2.
Case (a) is described in more detail below; case (b) in the following sub-section,
13.4.5.
In both cases SATPIJA is run in an identical fashion in order to calculate weighted
PIJA factors for all user classes within the nominated level using the selected links
within their chosen routes. See equation (13.5)
The level is identified by the value of LEVEL in Control File A as input to SATPIJA
(See note (5), 13.2.1). Note that if a level contains only one user class it is
equally possible to identify the level using the parameter KLASS.
The counts MUST refer to the total flows corresponding to that level or sub-matrix
(and thus SUBFIX should almost certainly be set to FALSE in SATME2 to avoid
subtracting fixed flows; see 13.4.8). For example, if you had stacked a Car and
an HGV matrix into a stacked two-level matrix file you could identify all car trips on
selected links and use that PIJA data plus car-specific counts to update the Car
matrix.
In this case the prior trip matrix input to SATME2 is the single-level un-stacked
car-only prior matrix, the matrix output from SATME2 is an updated car matrix
(also un-stacked) whereas the matrices input to SATURN and/or SATPIJA must
be stacked matrices (since in order to carry out the full assignment both matrices
are required). Thus it is necessary to insert one or two extra steps in the update
process:
♦ Prior to running SATME2 un-stack the full prior trip matrix to produce one or
more square sub-matrices for the level(s) to be updated (N.B. Not necessary
if the stacked prior matrix was itself built from sub-matrices in the first place);
♦ After obtaining a new Car matrix re-stack it with the (current) HGV matrix to
produce a new stacked matrix to use in SATURN.
Having updated the Car matrix to match the counts you could of course then carry
on to update the HGV matrix (with no doubt some extra problems of feedback and
convergence in addition to those described in 13.1.10 since updating the car
matrix may affect the routes taken by both cars and HGVs which will in turn affect
the ME2 HGV calculations!). The main point is that both steps must be carried out
separately.
13.4.5 Multiple Level Matrices: Updating Stacked Matrices Directly

Post version 10.8 it is possible to run SATME2 using stacked trip matrices for both
the input and output files and to update only one individual level at a time within
the stacked matrix without having to first unstack them as described in 13.4.4.
5120257 / Apr 15 13-42

Section 13
The end result is identical, the only difference is that the procedures described
below are easier to implement.
As with 13.4.4 first run SATPIJA to produce a .UFP PIJA file for the level of the
trip matrix to be updated and then run SATME2 to update that level.
SATME2 distinguishes between the updating of a square sub-matrix and updating
a stacked matrix purely by the properties of the input prior matrix. If the prior
matrix is square SATME2 follows the procedures described in 13.4.4; if the matrix
is stacked, it follows the procedures described here.
The value of the level to be updated is set by the parameter LEVEL as input to
SATPIJA and passed to SATME2 via the .UFP file.
The procedure is then repeated once per level (or once for each level which is to
be updated). N.B. As yet there is no automatic procedure to carry out a PIJA
analysis for all levels in SATPIJA and then to update all matrix levels with
SATME2. However it should not be difficult for clever users to set up their own
batch files to run the procedure automatically - further advice is available upon
request.
Note that one very good reason for not putting the complete procedure into a
single “black box” is the user needs to be making decisions after each run of
SATME2, for example whether to repeat the assignment immediately, whether to
repeat the run of SATME2 but with certain counts removed, etc. etc.
THE “COPY/UPDATE” TRIP MATRIX

There is one extra complication that arises in applying SATME2 to stacked
matrices: how to guarantee that the output trip matrix contains the most up-to-date
versions of all levels when each run of SATME2 only updates a single level.
For example, if we have a three-level matrix and we first apply ME2 to level 1 we
can create an output matrix which consists of the updated level 1 plus the original
levels 2 and 3 as copied from the prior matrix. However when we apply ME2 to
level 2 we will want the output matrix to contain the updated versions of both
levels 1 and 2. In order to do so we use the first output matrix as an input to the
second ME2 process, copy levels 1 and 3 from that matrix to the output and add
the updated version of level 2.
Hence for each run of SATME2 we need two input trip matrices – the prior matrix
(which should never change) and a “current” trip matrix from which we copy the
levels other than the one being updated. Clearly the output matrix from run n then
becomes the input update matrix for run n+1. (But note, as always, that the prior
matrix never changes.)
For the very first run of SATME2 the prior matrix may be copied into a “current”
trip matrix to be updated but thereafter the prior and update matrices should be
totally different files.
The filename of the copy/update matrix is specified via the Command Line using a
“key word” TIJUP; see 13.7.2. An example of the Command Lines would be:
5120257 / Apr 15 13-43

Section 13
For updating level 1:

SATME2 newod1 counts KR me2kr PRIOR priorod TIJUP newod0


where newod0.ufm might be a straight copy of priorod.ufm (but, N.B. it must have
a different filename).
13.4.6 Multiple User Classes Aggregated by Vehicle Class: IVC and TURBO
This section describes the situation where, say, you have three separate matrices
of car trips disaggregated by purpose – e.g., Work, Education and Other – each
stored as a separate matrix level for assignment purposes with, possibly, different
values of PPM, PPK etc. and therefore different route choices. In addition you
may have link counts and/or other constraints based on total cars, i.e., not
disaggregated by purpose.
In this case it is possible (post 10.8.13) to use SATME2 to update a prior matrix
which is the sum of all three car trip sub-matrices (and therefore a square matrix)
and to subsequently split the updated matrix back into separate matrices for Work,
Education and Other. (The method of splitting may either be left entirely up to the
user post SATME2 or done automatically within SATME2 by using an option
TURBO described below.).
Thus, with reference to equation (13.1) T ij is the total car trip matrix, P ija is the
probability that a car trip from origin i to destination j uses link a and V a is the total
car flow on link a. Thus P ija is a weighted sum over all purposes defined by:
Equation 13.6
= ∑ P ija P ij
m m
P ija
m
where P ij m is the probability (i.e., split) that a car trip from i to j is by purpose (user
class) m.
In order to calculate P ija within SATPIJA it is first necessary to ensure that the all
the sub-matrices (i.e., levels of the stacked matrix) which are to be treated
together have been grouped within the same “vehicle class” using the 88888 data
records of the network .dat file (see 6.11). The namelist parameter IVC identifies
the vehicle class to be used and must be invoked as the only option which
defines multiple levels within SATPIJA
13.4.6.1 Output Matrix: Using TURBO in Conjunction with IVC

While the matrix updating procedures within SATME2 are always applied to a
square trip matrix (internally) the updated (square) matrix may be either output
directly as a square matrix or proportionately divided between the matrix levels
and output as part of a stacked trip matrix depending on whether a parameter
5120257 / Apr 15 13-44

Section 13
TURBO was set to F or T within the SATPIJA &PARAM records. (TURBO =

turboprop – read on!)
Thus, if TURBO = F (its default), SATME2 requires as input a “square” prior matrix
which is the sum of all car trip matrix sub-levels and outputs an updated total car
trip matrix which is also square. Note that neither the prior nor the updated trip
matrices are used directly within the traffic assignment.
It is the responsibility of the user to (a) create the square prior matrix by
aggregating together the relevant sub-levels of the stacked trip matrix and (b)
splitting the output square matrix into sub-matrices by purpose and creating a new
stacked trip matrix prior to re-assignment ( the exact method for which is left to the
user).
On the other hand if TURBO = T then (a) the full stacked matrix is input into
SATME2 and the program automatically aggregates the appropriate sub-levels to
create a square prior matrix and (b), the updated square matrix is automatically
split by purpose/level and output as a stacked trip matrix. The constituent levels of
the output matrix are calculated proportionately via the equation:
T ij (m) = t ij (m) (T ij / t ij ) (13.7)
Where t ij (m = the input prior trips from I to j for matrix level m
T ij = the updated car trips from I to j
t ij = the prior total car trips from I to j
Clearly, in terms of user convenience, setting TURBO = T has much to
recommend it. The reason that its default value is F is simply that the method was
introduced in later SATURN releases than IVC (10.8.20 vrs. 10.8.15).
N.B. The value of TURBO has no affect within SATPIJA as the weighted Pija
factors are calculated in exactly the same way whether it is T or F; the differences
only occur within SATME2.
13.4.7 Auxiliary Matrices

“Auxiliary” input matrices such as FILICE used to define the frozen cells and
FILTLD used in the trip length distributions may also be used under MUC.
However, unlike the main trip matrices, they may be either simple square matrices
or stacked. If square it is assumed that it represents the UC/level required, if
stacked the appropriate level is read.
On the other hand all the main trip matrices, e.g., the prior matrix, the update
matrix, etc., must all have the same number of rows and columns and hence the
same number of levels.
13.4.8 SUBFIX and SUBPQ with MUC Assignment

Generally speaking, when SATME2 is being used to update a stacked MUC trip
matrix, e.g., one that contains both cars and HGVs, it would be expected that the
input counts would refer either to cars or HGVs on their own and that it would not
be necessary to remove, say, bus flows which had been included in the counts.
Hence the use of the SUBFIX option (13.1.4 and 13.3.1) should generally not be
5120257 / Apr 15 13-45

Section 13
necessary and SUBFIX should be explicitly set as F (i.e., changed from its default
of T).
On the other hand, if you are using PASSQ, it will be virtually impossible for the
counts to have differentiated between vehicles from this time period and previous
time periods, in which case there are very cogent reasons for making use of the
SUBPQ option in order to subtract the UC-specific PASSQ flows from the target
counts.
There is, however, a technical problem here in that the queued-up flows from the
previous time period as recorded under PASSQ are the TOTAL queued flows
and are not disaggregated by, e.g., user class. In order to correct for this problem
when one is updating only one particular level / user class in the stacked trip
matrix SATPIJA calculates the total PASSQ flow per counted links and then
factors it down by the ratio of the user class flow relative to the total flow on the
link in the previous time period. This information is then passed to SATME2 via
the .UFP file. Clearly this is only an approximation but, given the normally
relatively small contribution of PASSQ flows to total flows, it is felt to be justified.
A similar correction is also made to initial residual queues which are subtracted
from the target flow if SUBSLQ = T (see 13.3.1).
N.B. If, for some strange reason, the PASSQ-ed network had a different link
structure from the “current” network then, post 10.9.19, the flows are correctly
“translated” from the old structure into the new. Previously this was not possible:
SUBPQ was set to F in SATME2 and a Serious Warning generated.
13.4.9 Running Multiple SATPIJAs

It is possible to run SATPIJA in “segments” or “slices” such that each separate
run analyses PIJA values for only a particular sub-set of origin zones and outputs
a “sub-PIJA” file covering just those origins. Once created the sub-files may be
later combined by a final run of SATPIJA into a single full .UFP file which contains
data for the full set of origins as per normal.
The main purpose of this option is to allow SATPIJA to be run simultaneously in
separate cores of a multi-core computer in order to reduce CPU time. See
Sections 13.7.3 and 15.53.2.2 for further details on the distributed Multi-core
application SATPIJA_MC.
To invoke this option it is necessary to define: (a) the number of segments NPART
into which the origin zones are to be divided and (b) which subset IPART a
particular run will process (where 1 <= IPART <= NPART). For example, if a
network has 55 zones and NPART = 4 each segment processes 14 zones
(rounding up) such that the first segment (IPART = 1) contains zones 1 through
14, the second, 15 through 28, etc. etc. Note that the final segment may contain
fewer zones than the rest (13 in the above example). NPART and IPART are set
as Namelist parameters in the control file for SATPIJA or, alternatively, as
command line parameters (see 13.7.2). The process can be controlled from a
single batch file SATPIJA using n#N on the command line (see 13.7.2).
If, however, IPART = 0 but NPART > 0 then SATPIJA operates in an “aggregation
mode” such that all the sub-UFP files created by each zonal segment are read in
5120257 / Apr 15 13-46

Section 13
and copied into a single .UFP file which contains the PIJA data for all zones as
per normal.
Technically each sub .UFP is identified by a suffix _PART such that (see 13.7.2)
the standard filenames would be counts_1.UFP, counts_2.UFP … whereas the
aggregate .UFP file would be named counts.UFP.
13.5 Matrix Estimation with Aggregated Zones

Historically, SATURN-based Matrix Estimation (SATME2) was undertaken at the
zonal ij level, adjusting individual cells of the demand matrix to better match the
(resulting) assigned flows through target counts. Alternatively the same basic
calculations may be carried out at a more aggregate level where we wish to
estimate, say, sector-to-sector trips as opposed to zone-to-zone trips and then
factor the zonal trip matrix to match the aggregated matrix.
Notation: Lower class i and j represent zones either as origins or destinations,
upper case I and J represent aggregations of zones (e.g., sectors, traffic
boroughs, etc.) either as origins or destinations. Thus T ij represents a zone-to-
zone trip matrix, T IJ the (implied) same matrix but aggregated to, say, sector-to-
sector.
Working at an aggregated level has two potential advantages:
(a) A reduction in CPU time and
(b) A more “balanced” (and potentially more realistic?) solution.
Thus, under (a), if the matrix is reduced in size from, say, 1,000 zones to 100
groups then the number of (some, possibly most) internal iterations will be
reduced by a factor of 100 with a consequent reduction in CPU time in both
SATPIJA and (mostly) SATME2.
Under (b), we would expect that the zonal matrices output from a group-based
application of SATME2 would have fewer “extreme” differences in individual O-D
cells than a zonal-based application. The explanation is that since the group-to-
group cells contain many more trips than zone-to-zone cells the balancing factors
X a (or, more strictly speaking, X a **P IJa ) required to achieve the required
growth/decline in target link flows would be much nearer to unity. Hence the
growth factors applied to the zonal cells would be much nearer unity and therefore
the extreme changes to certain cells (a common “feature” of ME2 outputs) would
be avoided.
The extended facilities within SATPIJA and SATME2 are described in sections
13.5.2 through 13.5.4 below.
13.5.2 SATPIJA with Aggregated Matrices: GROUPS = T

The procedures for running SATPIJA with aggregated zones differ only slightly
from running with “normal zones”. Thus if
a) the trip matrix input (the second parameter on the SATPIJA command line) is
an aggregated matrix (e.g., it has been aggregated via MXZ2G or MXZ2B); and
5120257 / Apr 15 13-47

Section 13
b) a logical parameter GROUPS has been set T under Namelist (default F).
then SATPIJA will produce a .UFP file based on the groups or aggregated zones.
All other inputs, including Namelist parameters, are unchanged.
A fatal error results if only one of the above conditions is fulfilled (e.g., GROUPS =
T but the trip matrix has not been aggregated).
All the necessary information to map zones into groups for example will be
contained within the .UFM file.
In brief, the procedure works by tracing all OD routes per FW iteration at the
normal zonal level but then, instead of building up Pija factors at the zonal level,
accumulates for each count ‘a’ a matrix of total group-to-group trips T IJa . At the
conclusion of the procedure T IJa is divided by T IJ , the total group-based trip matrix,
to give the P IJa factors at the group level. (Where I and J represent group origins
and destinations, i and j zonal O’s and D’s.)
13.5.3 SATME2 with Aggregated Matrices

The value of the parameter GROUPS set in SATPIJA is “passed” to SATME2 via
the UFP file so that, if T, the standard ME2 procedures are followed but based on
aggregated rather than zonal matrices. Thus ME2 calculates the balancing factors
Xa to solve equation (13.3) and outputs a “new” trip matrix defined at the group
level.
N.B. All Namelist parameters in the SATME2 control file have the same
interpretation but any “supplementary” matrices, e.g., a cost matrix for trip length
distribution, must have been aggregated to “groups” rather than based on
network zones.
The assumption is then made that the “growth” factors F IJ = T IJ / t IJ , the
proportional growth in trips from group origin I to group destination J, will apply
equally to all zonal OD trips within those origin/destination groups. Carrying out
the required zonal factoring requires three additional steps post-ME2 which may
all be carried out using standard MX batch procedures. Thus:
i) Use MXDIVIDE (10.20.25) to divide the output ME2 group matrix by the
prior group matrix to yield a growth factor matrix F IJ ;
ii) Expand the group factor matrix (F IJ ) to zones (F ij ) using MXG2Z
(10.20.24);
iii) Factor the prior zonal trip matrix by the zonal factor matrix to produce the
final zonal trip matrix T ij = t ij . F ij using MXDOT2 (10.20.19).
13.5.4 Batch Files to Run an Aggregated Matrix Estimation

The following sequence of calls to batch files, with comments, illustrates the
necessary steps to update a trip using aggregated zones or “groups”.
CALL MXZ2G TIJ_Z TIJ_G FILZ2G
- Create an aggregated trip matrix TIJ_G.UFM from the current zonal trip matrix
TIJ_Z.UFM using the zone-to-group definitions in FILZ2G.Z2G
5120257 / Apr 15 13-48

Section 13
CALL MXZ2G PRIOR_TIJ_Z PRIOR_TIJ_G FILZ2G
- Ditto create an aggregate version of a prior trip matrix (if one is needed by
SATME2)
CALL SATPIJA NETWORK TIJ_G COUNTS
- Create a COUNTS.UFP file from NETWORK.UFS based not on zones but on

aggregate groups. The input trip matrix TIJ_G must be an aggregated matrix
and contains all the necessary information required by SATPIJA to swap
between zones and groups as necessary. It also identifies the filename for the
zonal trip matrix TIJ_Z.UFM. N.B. The file COUNTS.DAT must set GROUPS =
T.
CALL SATME2 TIJ_G_UP COUNTS KR CONTROL_ME2 PRIOR
TIJ_PRIOR_G
- Calculates an updated group-based trip matrix TIJ_G_UP.UFM based on the

group-based Pija factors in COUNTS.UFP.
CALL MXDIVIDE TIJ_G_UP TIJ_G FACTOR_G
- Divide the updated group-based trip matrix by the input group-based trip
matrix (here assumed to be TIJ_G but it could also be a prior matrix) to obtain
a matrix of group-based growth factors per IJ cell FACTOR_G.UFM.
CALL MXG2Z FACTOR_G FACTOR_Z
- Convert the matrix of group-based growth factors into a matrix of zone-to-zone

growth factors FACTOR_Z.UFM.
CALL MXDOT2 TIJ_Z FACTOR_Z TIJ_Z_UP
- Factor the input zonal trip matrix TIJ_Z (alternatively the prior trip matrix) by
the zonal growth factors to obtain the updated zonal trip matrix TIJ_Z_UP.
13.5.5 Advice on the Use of Aggregate Matrix Estimation

For advice on experience in having used aggregate matrix estimation please refer
to Atkins directly.
13.6 SATME2 Technical Specifications
13.6.1 SATME2 Files

Channel Remarks Status
Number
1 The input ‘old’ or ‘a priori’ O-D trip matrix UFM Mandatory unless
file; (N.B. Not necessarily the last trip matrix PRIOR = FALSE
assigned; see 13.3.5)
2 The output updated trip matrix (UFM) file Mandatory
3 The input UFP file containing the count Mandatory
definitions and their PIJA’s
5 Input DAT file. Mandatory
5120257 / Apr 15 13-49

Section 13
6 The output LPM line printer file Mandatory

7 The output “.ME2” summary data file; see 13.9. Mandatory
15/14 Terminal (output only)
22 Stacked trip .UFM matrix to be copied/updated Optional
23 Cost etc. .UFM matrix used for Trip Length Optional
Distributions
24 Frozen cell .UFM matrix Optional (FRODO = T)
37 Scratch DA file to store Integer PIJA data Optional – 66666 used
38 Scratch DA file to store Real PIJA data Optional – 66666 used
13.6.2 The SATME2 Batch Procedure

Command Example / Comment Status
SATME2 To run SATME2 call
SATME2 newod counts KR me2kr PRIOR priorod
FREEZE icefil TIJUP upfil
Where:
newod.UFM Output new ‘estimated’ trip matrix Mandatory
corresponding to the input counts.
counts.UFP Input UF file with PIJA factors from Mandatory
SATPIJA
newod.LPM Output line printer file Mandatory
newod.ME2 Output data summary file (“.ME2”); see Mandatory
13.9.
me2kr.DAT Input data file containing the control Optional: Default:
parameters. See 13.2.2 SATME20.DAT
priorod.UFM Input old or ‘a priori’ trip matrix (N.B. Not Optional
necessarily the last trip matrix assigned;
see 13.3.5)
Icefil.uFM Input matrix of frozen cells Optional
Upfil.UFM Input stacked trip matrix to be copied onto Optional
newod.ufm with stacked matrix inputs;
Notes:
(i) PRIOR is only used when the program is run in the “update” mode. Since the
default file SATME20.DAT sets the update mode if KR is absent then PRIOR
must be used in this case
5120257 / Apr 15 13-50

Section 13
13.7 SATPIJA - Technical Specifications
13.7.1 SATPIJA Files

Channel Remarks Status
Number
1 The input network UFS file Mandatory
3 The output UFP file containing the PIJA’s Mandatory

to be used by SATME2
5 Input control file (see 13.2.1). Mandatory
6 The output LPP line printer file Mandatory
7 An output KPP ASCII file (13.7.4) Optional (PIJAKP = T)
8 A scratch text file used to store error Mandatory
messages
9 The input trip matrix (UFM) file as used Optional (ALLIJ = F)
specifically to identify non-zero O-D cells
11 Scratch file to temporarily store Pija data Mandatory
12 Input “pre” network .ufs file under PASSQ Optional (PASSQ = T)
13 Scratch file to temporarily store Pija data Optional
for stacked matrices
15/14 Terminal (output only) Optional – MODET ne 0

18 Alternative text input file under $INCLUDE Optional
29 Scratch file to store overflow costs per FW Optional
iteration
13.7.2 The SATPIJA Batch procedure

SATPIJA To run SATPIJA call
SATPIJA network trips counts (QUIET n#N
Where:
network.UFS Input network UFS file Mandatory
network.LPJ Output line printer file Mandatory
trips.UFM Input (prior) trip matrix file – see note 4), Mandatory
13.2.1
counts.DAT Input ASCII control file containing Mandatory
(optionally) link and count data; see
13.2.1
5120257 / Apr 15 13-51

Section 13
counts.UFP PIJA file to be passed to SATME2 Optional

QUIET Runs in the background without any Optional
windows
n#N Process zone-based slice n of N Optional; See 13.4.9
0#N Aggregate all N sub .UFP files to create a
full .UFP file for all origins
13.7.3 The SATPIJA_MC Batch Multiple Processor Procedure

SATPIJA_MC To run SATPIJA_MC call
SATPIJA_MC network trips counts (passqnet
zonetrips QUIET
Where:
network.UFS Input network UFS file Mandatory
network.LPJ Output line printer file Mandatory
trips.UFM Input (prior) trip matrix file – see note 4), Mandatory
13.2.1
counts.DAT Input ASCII control file containing Mandatory
(optionally) link and count data; see
13.2.1
counts.UFP PIJA file to be passed to SATME2 Optional
passqnet.UFS Input PASSQ network (required if used in Optional
assignment)
From 11.3.10, the PASSQ information is
extracted from the network.UFS as per
single class version. For backward
compatability, the parameter can be given
but will be overriden.
zonetrips.UFM Input zonal level matrix (required if Optional
GROUP=T used) as used when
compressing to get grouped trips.UFM
QUIET Runs in the background without any Optional
windows
13.7.4 SATPIJA Output ASCII Files

If the parameter PIJAKP is set to T SATPIJA will output an ASCII “card punch” file
containing the same data as in the .ufp file but in a form by which the data may be
read by, e.g. a spreadsheet. The format is as follows.
Each counted link/turn contains a header record plus one or more pija records
where each record is in “comma delimited” format, i.e. each entry separated by a
comma from its neighbours with no spaces.
5120257 / Apr 15 13-52

Section 13
The header record contains 5 elements:
♦ A-node.
♦ B-node.
♦ C-node (blank if a link).
♦ The number of pija “pairs” to follow.
♦ The number of records to follow.

Each data records consist of up to 50 pairs of data entries where each pair gives:
♦ An ij value equal to j + n z (I-1)
♦ The P ija value (>PIJMIN)

where n z is the number of zones. Note the first entry is an integer, the second
real.
Thus if a particular link had 123 P ija “hits” it would occupy 4 records in total, the
header, 2 data records each containing 50 integers and 50 reals, plus a final
record with 23 of each.
13.8 SATU2 - Selected Link Matrices

WARNING: SATU2 has not been updated for a good ten years and, as of
November 2013, is effectively currently unavailable. In principle it could be
resurrected so that if any user is particularly interested in using it they are
advised to contact Atkins and/or DVV.
SATU2 is a purely interactive program which converts the data contained in a
UFP file and the trip matrix file into one or more link- or turn-specific trip matrices.
More precisely it produces a matrix T ija where:
Equation 13.7
Tija = Tij Pija
and Pija is the fraction of Tij trips which pass through link(/turn) a. Figure 13.4
illustrates the order of programs (cf. Figure 13.2).
Once produced the T ija matrix may be printed using MX or perhaps re-assigned
using SATDB. However given the probable “sparsity” of the matrix most users
probably prefer to aggregate the “zonal” trip matrix into, say, a “sector-to-sector”
matrix using MX.
SATU2 may produce more than one matrix in a single run, although the links or
turns need to be defined first via the input to SATPIJA (Figure 13.4).
5120257 / Apr 15 13-53

Section 13
Figure 13.4 – Producing a T ija matrix
13.8.1 SATU2 v SATDB

Note that the same trip matrices as produced by SATU2 may now also be
obtained using the Selected Link Analysis options within SATDB - see Section
11.10.7.5 and 15.19. In fact SATDB offers a better means of analysing selected
trip matrices in that:
♦ It allows the matrix to be aggregated and printed as a sector-to-sector matrix

immediately; and
♦ It also allows the user to determine the links used by the selected trips before
and after using the selected link.
Hence SATDB is generally recommended in preference to SATU2.
13.9 “ME2” Output Files

Following SATURN 10.5, SATME2 now automatically outputs an ascii/text file
which contains summary data from the ME2 calculations. The intention is that this
file may be input to other procedures, for example a spreadsheet or P1X (see
11.8.5), for further analyses of the results. The file takes its pathname from the
new trip matrix .ufm file but with extension .ME2; hence it is referred to as a “ME2”
file.
Currently ME2 files contain one record per input count with the following data per
count:
♦ The link A, B and C (if a turn) numbers;
5120257 / Apr 15 13-54

Section 13
♦ A single character L, = or G to indicate less than / equal / greater than

constraints (13.1.6);
♦ The input link count (as converted to demand; see 13.1.4);
♦ The “fixed” flow on that link;
♦ The (demand) target flow (i.e., with fixed flows etc. removed);
♦ The (demand) link flow prior to running ME2;
♦ The (demand) link flow after running ME2;
♦ The “balancing factor X a for that link (13.1.1);
♦ Various link sensitivity statistics as listed in Table 10 (13.3.12);
♦ The number of the 66666 data set if the link is part of a combined set
♦ Target flows etc. for combined sets (as above for single constraints).
The end of the data file is indicated by a final record containing (as is standard in
SATURN data files) 99999.
Note that it is very likely that the contents and precise format of the above file will
change over time as further needs for post-ME2 analysis are identified. For
example, the current files do not contain any information on zone constraints so
these may be added at a later date.
5120257 / Apr 15 13-55

Section 13
10.9.17 Web release – Jun10 DVV DG IW IW 22/06/10
10.9.22 Web release – Dec10 DVV AG IW IW 06/12/10
5120257 / Apr 15 13-56

Section 13
Control Procedures (DOS Batch Files)
14. Control Procedures (DOS Batch Files)

INTRODUCTION
This section describes how to run SATURN programs using .bat file procedures
(essentially) under dos or equivalent operating environments (e.g. Command
Prompt under Windows) and the conventions adopted (which are essentially
common to both environments).
To a large extent the batch mode of running SATURN programs has been
superseded by the introduction of the SATWIN front end which operates under
WINDOWS. However SATWIN itself uses .bat files (although essentially invisible
to the casual user) and there are facilities within SATWIN (see 3.6) for essentially
do-it-yourself .bat file creation. It also makes use of the same “command line”
conventions as the .bat files and, in effect, SATWIN generates the command line
for you. Thus, like the study of Latin, there are still advantages in knowing
something about .bat files!
14.1 Introduction to Control Procedures / Command Lines

On all computers there are a number of ways in which the same job may be run
with varying amounts of ‘job control language’ (JCL) being required of the user.
For example under DOS (or its equivalent “Command Prompt” under Windows)
the user can initiate a job by typing in a “command line” such as:
SATEASY network trips
from the terminal, where ‘network’ and ‘trips’ specify particular network and trip
matrix files which need not be further specified. Alternatively, under “pure”
Windows, one might select SATEASY as an icon or from a SATWIN list and then
select the files interactively. In the first case a ‘control procedure’ or bat file
‘SATEASY.BAT’ has been set up in order to remove most of the hard work.
For every program in the Suite there is an equivalent .bat file with the same
“name” as the .exe file (so that the SATEASY.BAT procedure runs the
$SATEASY.EXE program) and which requires a Command Line containing a
particular sequence of keywords and/or file names. The .bat files exist under both
DOS and/or Windows, although their functionality may differ within different
operating environments.
The main function of the bat file is to form a “bridge” between the user and the
program exe file such that file names etc get passed back and forwards between
the two. Previously under 16-bit “pure” dos this involved, to a greater or lesser
extent, logical checks and steps within the .bat file; with 32-bit programs and/or
Windows the emphasis has changed and the .bat file simply transfers the
command line into the program and the logic all takes place within the program.
This may make it more difficult for “users” to set up their own “clever” bat files to
control SATURN programs. But not impossible; see 14.11.
Command line parameters or “tokens” (e.g. “network” and “trips” in the above
example) may be divided into mandatory and optional with the mandatory
parameters coming first in a fixed order followed by the optional parameters in any
order. For example to run SATEASY there are two mandatory parameters as in:
5120257 / Apr 15 14-1

Section 14
SATEASY livnet livtrips
whereas an example of the use of the optional parameters might be:

SATEASY livnet livtrips KR choice
In the documentation mandatory input is separated from the optional by a single

opening bracket (which the user need not type).
The optional parameters may be divided into specific “keywords” such as KR
above which are fixed and “parameters” such as choice above (typically
filenames) which the user selects. Certain rules cover the order in which they
must appear. In the documentation keywords are given in upper case letters and
the parameters in lower case but, generally speaking, command line tokens are
case-insensitive. (Thus either KR or kr could be used above.)
A “help” facility is provided whereby if you type in simply the name of the
procedure without any further parameters, a brief description of the format of the
procedure appears on the screen. For example, typing simply “SATSIM” would
give condensed instructions as to how to use SATSIM.BAT.
Finally users should note that the .bat files supplied with SATURN are not “tablets
carved in stone” and may, unlike the .exe files, be modified by the users
themselves. Indeed, given the inherent flexibility of the SATURN programs, users
are positively encouraged to explore alternative and innovative ways of linking the
programs together, for which alternative .bat files can be extremely useful. Some
suggestions are given in 14.11.
14.2 File Specification within Control Procedures

In order to run a program, e.g. SATALL, all the individual input and output files
need to be specified. This may be done in three ways:
♦ Via the command line
♦ Via filenames included in other input files (primarily .dat files)
♦ Interactively via the terminal

or by combinations of all three. Thus the command:
SATALL net trips
specifies input files net.ufn and trips.ufm plus output files net.ufs and net.lpt
through the command line.
However the trip matrix name could also have been defined in the original data file
net.dat under &PARAM (see 6.3.4) via FILTIJ = ‘trips.ufm’ and passed to SATALL
via net.ufn - (option ii above), in which case the command line:
SATALL net
would be sufficient. Indeed this method is highly recommended, in particular

since it makes subsequent command procedures considerably simpler and more
fool-proof.
5120257 / Apr 15 14-2

Section 14
Interactive file specification is used as and when files not already defined under i)
or ii) are needed. Generally speaking this is most common with the purely
interactive programs such as P1X whereas the non-interactive programs such as
SATNET or SATALL should only use methods i) and ii).
Command line filename definitions may include the extension but it is not
essential; it may also be implied either by its position in the command line or by
keywords immediately before or after. For example:
P1X livnet.ufs
will run P1X on a file livnet.ufs. Alternatively

P1X livnet
will also input livnet.ufs where the extension .ufs is implied by default.
Alternatively either:
P1X livnet UFT
or
P1X livnet.uft
both define an input file “livnet.uft”. In the former case UFT is an example of a
keyword which appears after the filename it amplifies; in the latter case the
extension is explicit.
Note, however, that:
P1X livnet.uft UFT
would imply a file “livnet.uft.uft”, presumably not the required file.

Equally
SATEASY net trips REDMEN tijθ
implies an input file tijθ.ufm under the REDMEN option where here the keyword
REDMEN appears before the filename it describes.
Note that the “names” used in the command line may be based on either
“filenames” or “pathnames”. Thus either:
SATNET net
or
SATNET C:/JOB/DAT/net
could both be used to specify the file C:/JOB/DAT/net.dat, where the first definition
relies on the current home directory and/or “append” search definitions to locate
the file. SATURN uf* files store both a “filename” and a “pathname” to help locate
the required files at later stages.
14.2.2 Specifying Multiple Files plus Extensions

If, for example, the user wishes to examine 2 or more input files under P1X the
command:
5120257 / Apr 15 14-3

Section 14
P1X net1 net2
would imply the two input files net1.ufs and net2.ufs since net2 is neither a
standard extension nor keyword and .ufs is the default extension. Equally:
P1X net1.ufs net2.ufs
(or variants thereof) would have the same effect.

An alternative more complicated (and somewhat out of date) general method used
by several bat files to specify multiple files on command lines is via a 3-part
specification such as:
S 9 NET1
indicating that a file NET1.UFS is input/output on channel 9 - the extension .UFS

is implied by the S. Thus in the above example we would use:
P1X net1 S 2 net2
Other forms include:

A 11 NET2 ==> NET2.UFA on 11
M 3 FILE ==> FILE.UFM on 3
T 2 FILE ==> FILE.UFT on 2
Thus the initial letter - S, A, T or M - specifies the extension and must be one of
those 4, the second parameter is the channel number (with certain values being
invalid) while the third parameter gives the filename.
Two (or more) file specifications may be given, e.g., by:
S 1 NET1 A 2 NET2 M 10 MATRIX
14.2.3 Interactive File Control Procedures

Typing the program name followed immediately by the single parameter I runs
that program under the “file interactive mode” whereby the program itself requests
the names of all files, both input and output, to be entered via the
terminal/keyboard. For example:
SATLOOK I
runs SATLOOK “interactively” in terms of file definitions. This use is largely

historical and is not recommended.
Similarly the essentially “batch-style” programs SATCH and SATME2 may be run
in a form of “file interactive mode” via “SATCH I” or “SATME2 I” but equally this
usage is not recommended.
14.3 The ‘SATURN’ Procedures

This section describes how to run the iterative SATURN model illustrated in
Figure 3.1 using the ‘SATURN’ control procedures. Thus there are two essential
input files to be prepared by the user: (1) A network “DAT” file; and (2) A “UFM”
5120257 / Apr 15 14-4

Section 14
file describing the trip matrix to be assigned. Outputs include both binary UF* files
and ascii line printer files.
A basic distinction is whether or not the simulation/assignment loop is carried out
by one program, SATALL - the strongly recommended technique - or by two
programs, SATEASY and SATSIM, the original approach. Both are currently
available via, respectively, procedures SATURN and SATURN8; however
SATURN8 is effectively redundant but still, just about, available.
In order to run SATURN the user must issue a command of the form:
SATURN network
or, if the trip matrix filename trips.ufm is not defined in the network .dat file
(which it should be!):
SATURN network trips
The following files must already exist:
network.DAT the “ascii” file containing the network data.
trips.UFM the trip matrix.
while the following will be created:
network.UFN the network file produced by SATNET
network.UFS the UF file produced by SATALL or (SATURN8) the (final) run

of the simulation.
network.LPN the line-printer file output from SATNET.
network.LPT the line printer output from SATALL
or (SATURN8)
network.UFA the final UF file produced by an assignment
network.LPA the line-printer file produced by the last assignment.
network.LPS the line-printer file produced by the last simulation
This does not of course imply that the network file must have the name
‘network.DAT’ - the user can choose any filename for the input file, but it must
have the extension DAT. Similarly all other files have a user-supplied filename
but fixed extensions as defined above.
In the case of buffer-only networks under SATURN8 the simulation program
SATSIM is not run and therefore no UFS or LPS files are created directly;
however the final output .ufa file is renamed as a .ufs file to maintain consistency.
Equally with SATURN the output file from a buffer network is always .ufs.
5120257 / Apr 15 14-5

Section 14
14.4 Extended SATURN Procedures

The basic SATURN procedure may be extended to cope with various options by
specifying certain keywords, specifically PASSQ, UPDATE, PLOD and RESTART,
plus (optionally) file names. These are described below.
N.B. These particular options cannot only be run using special bat files; they may
also be activated by setting parameters plus file names in the original .dat file. In
fact this is probably a more convenient method to follow, given that if you need to
edit a .dat file to specify PASSQ=T you might just as well specify the extra
filename as well.
14.4.1 The PASSQ option: (See Section 17.3)

SATURN net2 trips PASSQ net1
executes a normal SATURN run, starting with the network ‘net2.DAT’, but any
queues detected by previously running SATURN on ‘net1’ are passed to ‘net2’. In
other words ‘net2’ represents the time period immediately following that simulated
by ‘net1’.
Logically, the &OPTION namelist record in ‘net2.DAT’ should define PASSQ = T
but, if not and a PASSQ file is defined, PASSQ is automatically set to T. In either
case file ‘net1.UFS’ must exist.
The alternative method to invoke PASSQ using just input to the net2 .dat file
would involve the following namelist specification:
&OPTION
PASSQ = T
PQFILE = ‘net1.ufs’
…
&END
In this case the command line would simply read:

SATURN net2 trips
as per normal.
Note that if, belt’n’braces, the PASSQ file is defined both under &OPTION and on
the command line then the file on the command line is always used.
14.4.2 The UPDATE option: (See Sections 15.3 and 22.2.1)

SATURN net2 trips UPDATE net1
executes a normal SATURN run but with the data input file ‘net2.DAT’ being an
improved version (and presumably representing the same time period) as a
previous run based on net1.
Logically, the &OPTION namelist record in net2.dat should define UPDATE = T
but, if not and an UPDATE file is defined via the SATURN command line,
UPDATE is automatically set to T within SATNET. In either case file ‘net1.UFS’
must exist.
5120257 / Apr 15 14-6

Section 14
Alternatively the update file may be specified using the UPFILE parameter under
&PARAM as per PASSQ in 14.4.1 above. Note that if, belt’n’braces, the UPDATE
file is defined both under &OPTION and on the command line then the file on the
command line is always used.
Note as well that a network can “update itself”; i.e., the command:
SATURN net trips UPDATE net
Would use the file net.ufs as the update file input to SATNET in order to
supplement the data in file net.dat. Ultimately, post SATALL, the original file
net.ufs would be over-written by the new version. This option enables the user to
edit the file net.dat without having to create a new filename for the file.
14.4.3 The RESTART option: (See Sections 15.4 and 22.2.2)

SATALL network trips RESTART
executes the normal iterative sequence of assignment and simulation but, instead
of starting with the default flow-delay curves from a .ufn network file as input from
the network build program SATNET, the procedure starts with flow-delay curves
from the file network.ufs which had previously been processed by SATALL. At
the end of the program the file network.ufs will have been over-written.
The RESTART option is useful either for continuing a SATURN run to obtain
improved convergence or, much more frequently, to re-run an existing network
with a new trip matrix, e.g., as obtained from the update program SATME2.
14.4.4 The PLOD option: (See Section 15.5)

SATURN net2 trips PLOD net1
executes a normal SATURN run with the data input file, ‘net2.DAT’, but with the
total assigned flows from a SATURN output file ‘net1.UFS’ being pre-loaded as
fixed flows onto net2.
Note that the extension of net1 above may be explicitly included in the command
line, e.g.:
SATURN net2 trips PLOD net1.ufa
But if no extension is included the extension “.ufs” is assumed and added.

Alternatively, if an extension which is not .ufs or .ufa is used, e.g., if the input
command line were:
SATURN net2 trips PLOD flows.dat
Then the fixed flows would be read from a text file flows.dat; see 15.5.4.
As above the &OPTION namelist record in net2.DAT should define PLOD = T but,
if not and if a PLOD file is defined in the command line, PLOD is automatically set
to T. In either case the pre-load file “net1.UFS”, “flows.dat” etc. must exist.
Alternatively the pre-loaded file may be defined via the parameter PLDFIL (6.1) in
net2.dat, in which case the PLOD specification above is unnecessary in the
command line.
5120257 / Apr 15 14-7

Section 14
Note that, unlike PASSQ and UPDATE above, if a pre-load file is defined both
within &OPTION and on the Command Line then the file set under &OPTION is
used.
14.5 “LOG”, “KEY” and “VDU” Files: Running Interactive Programs “Off-
line”
LOG FILES
All interactive programs automatically create a “log file” which contains a complete
record of all user inputs during the running of that program. “Inputs” include not
only keyboard responses, filenames etc. but also mouse operations. The “format”
of the file distinguishes between the different input styles; see 14.5.2 and 14.5.3
for details.
Post release 11.2.11 a full listing of the log file is given at the end of the relevant
.LP file which should make it simpler to re-create a particular job, particularly if the
LP file has been preserved but not the log file.
Log files have standard filenames based on the program names such as
P1Xn.LOG, SATDBn.LOG, etc. where the ”generation number” n is appended
each time a program is run (within that particular subdirectory). This feature is
provided to deal with multi-tasking but - N.B.!! - it requires frequent file cleaning on
the part of the user. The maximum generation number is 99.
KEY FILES
The main use of the LOG files is to create “KEY files” which are used to re-run
interactive programs such as SATDB, MX or P1X in an “off-line” or “quasi-batch”
mode whereby the normal commands which are supplied by the user via the
keyboard and/or mouse are instead taken (in sequence) from a “dummy terminal”
or “key” file. Thus the second key-based run of SATDB would follow exactly the
same series of instructions as the first, the difference being that the sequence of
commands is read from successive records in the key file rather than being
directly generated by the user. This means that, for example, having performed a
particular operation interactively on file-1 it is possible to automatically repeat the
identical operations on file-2 without having to laboriously repeat the same
sequence of keyboard operations.
More precise details as to how log/key files are constituted and applied are given
in sections 14.5.2 to 14.5.10.
A similar facility to KEY files is also available under command line options as
described in 14.7. Note however that KEY files are, from the point of view of a
SATURN user as opposed to the SATURN developers, far more flexible.
VDU FILES
In addition there is a further option available in conjunction with the KEY option
whereby the terminal output from an interactive program may be directed either to
a terminal screen or to a dummy “VDU” file. The latter is probably a “purer” form
of off-line or batch processing; the former is more useful in a sort of demonstration
5120257 / Apr 15 14-8

Section 14
mode where a program may be run apparently on-line but with the viewer only
having to hit the <return> key and/or click the mouse at each pause rather than
having to decide on the input.
(N,B. A very useful alternative to clicking the mouse in order to advance at each
stage of a graphical routine is to use Alt-F4!)
COMMAND LINE DEFINITION OF KEY AND/OR VDU FILES

In order to run, say, SATDB with a key file the standard command line should
(normally) contain the “keyword” KEY followed by a filename whose (implied)
extension is .key. Thus:
SATDB LIVNET KEY JAN16
runs SATDB on an input file LIVNET.UFS with terminal commands taken from a
file JAN16.KEY which has been copied (/renamed) from a .LOG file from a
previous, purely interactive run of SATDB.
The extension “.KEY” is implied and, prior to Version 10.9.21, was obligatory.
However, post November 2010, key files may either have an extension .key or
.log and may be set with or without the keyword KEY.
Thus a LOG file may be used directly as a KEY file without being renamed with its
extension changed. For example:
SATDB LIVNET KEY satdb16.log
would run SATDB with its terminal commands taken from a file satdb16.log,
presumably output as a LOG file from a previous run of SATDB.
Alternatively (post 10.9.22), the “pre-word” KEY is not an absolute necessity but
may be implied by the extension of a filename given on the command line such
that:
SATDB LIVNET JAN16.KEY
or
SATDB LIVNET satdb16.log
runs SATDB on an input file LIVNET.UFS with terminal commands taken from
JAN16.KEY or satdb16.log respectively.
The inclusion/exclusion of a VDU output file is determined in the “standard” high-
level procedures by a keyword VDU followed by a file name. Hence;
SATDB LIVNET KEY JAN16 VDU FRED
runs SATDB on LIVNET.UFS with terminal input from JAN16.KEY and terminal
output to FRED.VDU. Nothing therefore appears on the screen.
Alternatively (post 10.9.22) the keyword VDU may be dropped by simply entering
a filename with an extension .VDU as in:
SATDB LIVNET KEY JAN16 FRED.VDU
5120257 / Apr 15 14-9

Section 14
COMBINED KEY AND VDU DEFINITIONS

It is also possible to combine the KEY and VDU functions into a single command
line keyword KEYVDU such that:
SATDB LIVNET KEYVDU JAN16
is equivalent to:
SATDB LIVNET KEY JAN16 VDU JAN16
This is particularly useful when there are a large number of entries on the
command line since it saves, in effect, two words.
14.5.2 Simple KEY Files based on Keyboard Inputs; Macros

For programs such as SATLOOK, SATDB, etc. which are based purely on
keyboard (text) inputs (see 19.2) the key file contains a listing of those keyboard
inputs; more complicated structures, including inputs via the mouse, are dealt with
in 14.5.3
For example, the following key file “FUEL.KEY” creates, using SATDB, a data
array which is a linear combination of link time and distance representing fuel
consumption, and then creates a new “extended” UF file in which fuel
consumption is stored in DA array 4603. (N.B. the weighting parameters are
totally arbitrary!)
Note the use of comment lines commencing with a ‘*’ (see 14.5.7).
0
4
1893
4013
0
8
1
* Linear combination of distance (X1) and time (X2)
0.01*X1 + 0.0023*X2
FUEL CONSUMPTION IN MILLILITRES
4603
0
16
0
0
2
0
0
Y
Note that once an appropriate “KEY file” has been set up it may be used as part of
a standard “macro” to automatically repeat the same function but with different
network files. For example, you may automatically extend any .ufs network file
using FUEL.KEY with a standard procedural call such as:
SATDB NET S 11 NETX KEY FUEL VDU SCRATCH
which will extend NET.UFS to include fuel consumption in file NETX.UFS. The
terminal output responses would be stored in SCRATCH.VDU. (Although you
5120257 / Apr 15 14-10

Section 14
probably never need to look at this file; it is only there to make the procedure fully
“batch”.)
The procedure could be further implemented within a DOS batch (.bat) file called
by, e.g.:
DBFUEL net netx
which, at its very simplest, might consist of the single line file DBFUEL.BAT
call satdb %1 S 11 %2 KEY FUEL VDU scratch
14.5.3 Key files containing Mouse Commands etc.

Key files may contain “choices” which have been originally input in a variety of
different “formats” (as described in Section 19) including:
♦ normal keyboard inputs (key(s) followed by <enter>, 19.6)
♦ lines selected from the banner in P1X (19.4);
♦ an item selected from a menu bar (19.5);
♦ an item selected from a Windows list box (19.7);
♦ inputs from edit boxes and/or screen editing (19.9);
♦ “pure” mouse input (i.e., point and click on a particular point on the screen);
♦ etc. etc.
All of these appear within the log/key files in differing formats, the exact details of
which need not concern the casual user. Their primary purpose is to indicate to
the program which is “reading” the key file the precise form of the input command.
Note, however, that .log files generally do not include any inputs made within
“external Windows” operations. For example, within P1X network editing it is
possible at certain stages to request “screen editing” to edit segments of text. The
request to enter Screen Editing would be recorded in the .log file but any changes
made to the text under screen edit itself are Windows operations and will not be
recorded in the .log file. Similarly if you ask to print a file any options selected
within the standard Windows Print window are not recorded in the .log file. It is
therefore recommended that such Windows-based operations should be avoided
if the intention is to re-use the inputs as a key file. See Section 14.5.9 for further
information.
An example of a log file generated by a run of P1X which uses several different
forms of inputs, as well as comments, is given below:
1056 90 68 0 Display menu (Mouse pixels/status/Line) 6001
*
* Select the list of flow options and then choose Demand:
*
1051 72 67 0 Choice of (Mouse pixels/status/Line)
6002
1049 153 50 0 2-Flows (Mouse pixels/status/Line)
5 - Demand Flow Downstream
Menu bar: &Box 4040
5120257 / Apr 15 14-11

Section 14
376 440 1 (Mouse pixels + status)

565 279 1 (Mouse pixels + status)
1065 277 81 0 Q - Return (Mouse pixels/status/Line)
1052 278 66 0 SATDB Opts (Mouse pixels/status/Line)
4
0
4503
0
15
Menu bar: &Down
Menu bar: &Quit
0
1054 371 81 0 Quit = Exit (Mouse pixels/status/Line)
Yes OK to exit the program?
Thus the first choice made by the user was the line “Display menu” in the P1X
banner. 1056 and 90 indicate the precise pixel coordinates of the mouse when the
left hand button was clicked, 68 represents the ascii value of the character D (the
single highlighted character in that line), 0 gives a “status” (which is a bit too
complicated to explain and you don’t really need to know about it!) while “Display
menu” was the text in the selected banner line. Of these the only vital piece of
information is the ascii code 68 which is used by the program to “branch”
correctly.
The numerical value 6001 at the end of the record is a “menu check code”, i.e., a
code which may be used to uniquely identify the menu from which the choice
“display Menu” was selected (in this case the “Master Menu”). It may be
subsequently used as a check that when this record is processed from a KEY file
that it is indeed called from the Master Menu, otherwise the KEY file may be “out
of synch”. This facility was first introduced in October 2012 so that checks on KEY
files created before that date are not possible.
If you were to use this command line to run a job on a different computer with a
different screen resolution the pixel coordinates of the Display menu line might be
quite different – the critical thing is that a banner line with a highlighted character
whose ascii code was 68 (i.e., D) was selected.
The line “5 - Demand Flow Downstream” simply indicates that the 5th line from a
window containing various options was selected and that the text in that line was
as indicated. Again the vital piece of information is the 5.
The two lines following &Box indicate the precise pixel coordinates used to define
the position of the box (i.e., format (e) above). Problems may occur here if the job
is re-run on a machine with a different screen resolution and/or a different window
since, in that case, the pixel position (376,440) may point to a different position in
the network as displayed. They may however be used relatively reliably by using
full screen windows to create the log/key file and re-running on an identical
machine.
Note further down that, following the entry “SATDB Opts” where the input mode
becomes keyboard-based, the key file resembles that described in 14.5.2.
However, when within SATDB the user chose option 15, display to the terminal,
the commands “down” and “quit” were entered via the menu bar.
5120257 / Apr 15 14-12

Section 14
Running jobs with key files such as the one above is identical to running jobs with
“simple” key files as regards keyboard inputs (i.e., just hit <return>) but when a
mouse input is required the user must either click the left hand mouse button to
continue or, if a small window appears with the next instruction displayed, close
that window. On the other hand, if the VDU option is invoked, then the job will run
automatically without any user intervention.
(N,B. A very useful alternative to clicking the mouse in order to close the window
at each stage of a graphical routine is to use Alt-F4!)Creating standard “batch-
style” macros such as DBFUEL described in 14.5.2 becomes more difficult,
though not impossible, with mouse-based inputs. Thus a key file based on
SATDB is likely to be more reliable than one based on P1X.
14.5.4 Automatic Running of Interactive Programs (AUTO)

As a variation on the use of the KEY facility described above to run interactive
programs whereby the user needs to hit <return> in order to advance the program
from one (dummy) input command to the next, it is possible to run the same
programs under an “auto-timer” option such that the program pauses for a fixed
number of seconds each time an input is required before reading the input and
carrying on. Thus the program runs on the screen “unattended” so that this facility
is essentially intended to run demonstrations of SATURN programs.
In order to run programs automatically you must:
1) Type in the appropriate command line with a KEY file but ...
2) without any VDU request (otherwise the program will run in a “background”
mode) and ...
3) an extra first line inserted in the KEY file with:
(i) characters “AUTO” in columns 1-4 and
(ii) the number of (integer) seconds to pause in columns 6-7
Thus the demonstration KEY file listed in 14.5.2 would need to start:
AUTO 10
0
4
1893
etc.
in order to run with automatic pauses of 10 seconds between screens.
14.5.5 The “Break” Option in Key Files

It is possible to transfer from the “batch mode” using a KEY file to “interactive
mode” by including a “break command” within the KEY file. Thus you may
continue a previous run, for example using the first run (i.e. the KEY file) to set up
various standard default options in a similar fashion to a preferences file (15.2).
A break command can be included in one of two ways:
1) By the characters “break” or “BREAK” in columns 1 to 5 of lines which
normally contain numerical input; or
5120257 / Apr 15 14-13

Section 14
2) By the single character “b” or “B” in the first line in a KEY file which contains
the response “Y” to the question do you wish to terminate.
Use (2) would probably be more convenient for most applications.
A simple file is as follows:
0
4
1893
4013
0
VDU
8
1
0.01*X1 = 0.0023*X2
4603
0
16
0
0
2
0
0
B N.B. Previously Y)
To use a key file “setup.key” such as the above to “initiate” a run of, say, SATDB
one could use a command line such as:
SATDB net keyvdu setup
So that the commands in setup.key would run automatically in “background

mode”, terminating at the “break line” and leaving the user free to continue from
there.
14.5.6 Changing the Automatic Timer and/or VDU Options

It is possible to change the length of the ‘automatic pause’ under the KEY option
by including one or more further ‘AUTO’ records within the KEY file. For example
the following file starts with an automatic delay of 10 seconds but switches to 5
seconds after the input ‘4033’:
AUTO 10
0
4
1893
4003
AUTO 5
0
...
Any number of AUTO records may be included.

Note that a record of the form ‘AUTO 0’ or simply ‘AUTO’ cancels the automatic
delay and returns you to the normal KEY mode whereby the program pauses with
each input until a key is depressed.
In addition it is also possible to revert from the automatic to the normal KEY mode
by depressing the key ‘Q’ (or ‘q’). This can be done ‘on the spur of the moment’
5120257 / Apr 15 14-14

Section 14
from the terminal as opposed to inserting an ‘AUTO 0’ record in the KEY file which
must be done in advance.
Finally it is possible to change from the VDU mode (terminal output to a file) to the
normal terminal output to the screen mode by including a record VDU’ in the KEY
file; e.g.:
0
4
1893
4013
0
VDU
8
1
0.01*X1 + 0.0023*X2
4603
0
16
...
Thus in the above example the ‘terminal’ output would be initially directed to a file,
and thus be ‘invisible’ to the user, but would revert to the terminal part way
through. Use this option to skip over the ‘boring’ parts of a demonstration run.
Equally you can switch from terminal output back to file output by a VDU record
which is therefore a ‘toggle’ between the two modes. Note however that this
facility can only be used if you start with a VDU external file.
14.5.7 Comments in KEY Files

Comment records are indicated in KEY files by records with a ‘*’ in the first column
as illustrated below. When these are met by programs taking their input from a
key file they are copied verbatim to the screen until a “non-comment” record is
read.
.......
1
*
* Linear combination of distance (X1) and time (X2)
*
0.01*X1 + 0.0023*X2
4603
0
.........
Comments may either be inserted in a key file AFTER it has been produced by an
interactive run (i.e., into the LOG file) or else they may be directly included in the
log file by typing in records commencing with a ‘*’. Thus in the above example the
line ‘0.01*X1 ...’ is an equation which is required by the previous menu response
of 1; if the user had typed: *<enter>, * Linear .. <enter>, *<enter>, 0.01 .. <enter>
the log file would have appeared as above.
Comments are very useful for indicating the reason for the line following and are
often used within key files which are used as tutorials to demonstrate particular
features of SATURN programs since they appear directly on the screen. They are
5120257 / Apr 15 14-15

Section 14
also very useful in key files which are used within standard “macros”, just in case
later versions of SATURN have a different sequence of input commands (they
always do!) and old key files no longer work.
14.5.8 Using Key Files “Again”

A simple key-file option is provided under program bat files for P1X, SATDB,
SATLOOK and MX to repeat the immediately preceding run of that program via a
special keyword “AGAIN”. Thus the sequence:
SATDB net1
SATDB net2 AGAIN
runs SATDB on net2.ufs using the same sequence of commands as for net1. It
does this by copying the .log file from the first run into a temporary .key file (the
actual filename used is again.key but the user need not take any notice of this)
and using this as a normal “KEY file” in the second run. It is therefore equivalent
to:
SATDB net1
copy satdb.log repeat.key
SATDB net2 KEY repeat
The procedure could be repeated for further runs as in:

SATDB net3 AGAIN
as long as of course no other run of SATDB is executed in between.
14.5.9 Edit Box Operations in LOG/KEY Files

User inputs within SATURN may be sub-divided into “internally controlled” and
“externally controlled” operations, whereby externally controlled inputs occur, for
example, when a Windows edit box or a screen edit window (see 19.9) is created
and control is effectively passed to a Windows operation in order to change the
values set for certain variables and/or text.
The problem that externally controlled processes create for LOG files is that it is
no longer possible for SATURN programs to “know” exactly which keyboard and
mouse inputs have been invoked by the user and therefore it is not possible to
record the exact sequence within a LOG file as with “internally controlled” inputs.
On the other hand, and in principle, it is possible to compare the data that was
passed to the external process and returned in order “to infer” the inputs. Thus,
when possible, SATURN creates an entry in a log file containing the text “ Edit
Box:” in columns 1 to 10 followed by a stream of data values detailing the outputs.
For example, if an edit box is created to set values for 5 separate variables (e.g.,
saturation flow, lane choices etc. for a turn under node editing) then the returned
values of those 5 variables may be listed in the LOG file.
When a KEY file process encounters an Edit Box record it may then read the
following inputs and proceed accordingly.
Note that this option is not generally available with screen editing operations
where the data passed is generally much longer than can be stored on a single
record.
5120257 / Apr 15 14-16

Section 14
14.5.10 Opening Files within Key files: Potential Pitfalls

Programs which are run using KEY files (and equally the original interactive
program run that created the LOG/KEY file) very often open files interactively and
this may create certain problems as described next. N.B. These problems have
been largely eliminated from release 10.6.16 onwards.
For example, if the original program creates an output file “jim.dat” whose name is
set interactively (i.e., via a Windows dialog box) then the name of that file will
appear as a separate line within the LOG – and therefore the KEY – file. If jim.dat
were an existing file in the first place then the user would have been prompted
with the query “Do you wish to over-write jim.dat?”, to which the answer would
have been presumably Yes and the next line in the LOG/KEY file would be Y to
record that response. Thus the appropriate segment of the .log file might have
read:
0
jim.dat
y
0
On the other hand if the file jim.dat did not exist then the query to over-write would
not have existed and the LOG/KEY file would read:
0
jim.dat
0
Let us call the two alternative versions A and B respectively.

The first potential problem occurs if, at the time that the KEY file procedure is run,
the file jim.dat does not exist and version A above is being used in the key file. In
this situation the query about over-writing would not be relevant, the line
containing Y would not be needed and the “correct” version of the key file would
be B.
The second problem occurs in the reverse situation: jim.dat exists but Version B
(without the Y line) is incorrectly used as the KEY file. (Indeed it is this situation
which occurs most frequently when a new output file jim.dat is created in the initial
run and still exists when the KEY file run is executed, )
In older versions of SATURN the end effect was the same in both cases: the
program crashed.
1) However release 10.6.16 now solves both problems by checking the
instruction line following a file definition line. If it contains a Y which is not
needed the line is skipped; if it does not contain Y but a response is required
then an additional Y line is effectively added. Both situations are flagged as
Non-fatal errors.
2) (N.B. The latter case above assumes that the desired response is always Y,
over-write the file, although clearly a N reply (do not over-write, choose
another file) is also possible. However, it is somewhat “sloppy procedure” to
have a key file which defines the “wrong” file as implied by an N. Hence the
5120257 / Apr 15 14-17

Section 14
assumption is always that if a Y/N line is not provided then the desired
answer should be Y.)
3) Alternative Procedures. Alternatively, there are several ways around both
these potential problems (and, prior to 10.6.16., one of these would have
been necessary)
The first is to ensure that the “status” of all files prior to a KEY run is identical to
that prior to the original run. This could involve deleting any existing files which
are due to be created as new files.
A second is to manually edit in or out the required Y or N lines as required in the
KEY file (but even then you have to be careful that the edited KEY file is
consistent with the status of all relevant files every time you come to use it).
A third method, which has the advantage of simplicity, is to set the parameter
GO4IT (as described in Appendix Y) to .FALSE. in both the original and repeat
runs. In this case all existing files are automatically over-written, questions
regarding over-writing never occur and both the original .log file and the “correct”
key file will be as per the second data segment above, i.e., no line “y”.
There are several ways to ensure GO4IT = F. Firstly, it may be set interactively by
locating the menu containing the “General SATURN Parameters” menu and re-
setting GO4IT as necessary. Secondly, it may be set within the preferences files
P1X0.DAT etc. for all the main interactive programs: P1X, SATLOOK, SATDB
and MX. Finally, GO4IT may also be universally set within SAT10KEY.DAT but
this practice is not entirely to be recommended since it removes a useful general
safeguard; see Appendix Y.
14.6 Namelist Parameters Set on the Command Line

Within certain programs and their associated bat files it is possible to include
namelist parameter definitions as the final entries on the command line. For
example:
SATALL net &PARAM GONZO 1.2
runs SATALL on the file net.ufn but over-rides the existing value of GONZO to
1.2. The effect is the same as:
SATALL net KR control
where control.dat contains

&PARAM
GONZO = 1.2
&END
However for one-off parameter changes it is much easier to include the change on
the command line than to create a new control file.
Note that due to a quirk of DOS it is not possible to include equal signs on the
command lines; “GONZO = 1.2” is treated as “GONZO 1.2 1.2”. However since
namelist input does not require “=” (see Appendix A) this is not a problem.
5120257 / Apr 15 14-18

Section 14
It is possible to use both a control file containing namelist definitions and

command line definitions, in which case the control file is processed first and the
command line definitions over-ride as necessary. Thus the facility is not dissimilar
to the PS files used by SATNET (see 15.2.3)
The facility is at the moment provided only for the following programs and only for
namelist &PARAM although it may well be extended later:
SATALL, SATSIM, SATEASY and SATME2
It cannot be used with “composite” bat files such as SATURN which call a further
series of individual bat files, and it cannot be used with interactive programs such
as P1X or SATDB.
14.7 Command Line Options and Batch Procedures

In SATURN certain programs, e.g., MX, allow certain options to be specified on
the command line using a /option convention so that, e.g.
$MX trips /BUILD
implies that $MX.EXE will follow a pre-defined sequence of “build” operations in

order to create a .ufm file from an input file trips.dat.
The end result is very similar to using a key file, the main difference being that the
sequence of choices is not user-set but fixed. This is useful for certain “standard”
options such as matrix building. It has the further advantage that it does not use
key files which may become invalid with newer versions of SATURN.
The facility may be further extended and simplified (from the user’s point of view)
by creating standard “Batch Procedures” so that, for example, to dump a matrix
.UFM file TIJ.UFM into a CSV ascii formatted file (see 10.20.15) the user could
either type in directly:
$MX matrix TIJ /DUMP5
or use the as-provided batch procedure UFM2CSV:

UFM2CSV TIJ
where DUMP5 above is a special keyword which implies “dump into CSV format”.
The batch file UFM2CSV.BAT simply re-creates the previous command line in
order to run the program MX to carry out the same function.
A number of standard applications within MX based on this methodology are
described in Section 10.20. In addition further examples may also be found using
SATLOOK, SATDB and P1X.
14.8 Extended Command Line Files: Using .XCL Files

There is a DOS-imposed upper limit of 10 “tokens” (i.e., “words”) on a normal
command line which, in general, is sufficient for most applications but not all. For
example, a run of MX may need to input up to 9 .ufm files plus other options and
outputs and therefore exceed the above limit of 10 tokens.
5120257 / Apr 15 14-19

Section 14
Release 10.7 introduced an option to effectively extend the number of words on a

Command Line using so-called “.XCL files”. Thus the command:
MX mat1 XCL list
would open a text (ascii) file list.xcl and concatenate its contents to the right of
“mat1”. Thus, if list.xcl contained a single line:
mat2 mat3 OUT matnew
then, in effect, the complete Command Line would be:

MX mat1 mat2 mat3 OUT matnew
Alternatively a .XCL file may contain several lines (records) so that, for example,
the file list.xcl illustrated above might also be written:
mat2
mat3
OUT matnew
with the same effect.

There is no limit to the number of words which may be contained within a .XCL file
nor, therefore, to the number of words on the combined Command Line.
Currently the .XCL option is only available with MX (where it is most likely to be
needed) but, in principle, it could be used with any SATURN batch file. Requests
to DVV or Atkins for alternative applications.
Note that whenever XCL + filename are read on a command line then the
processing transfers to the new file immediately; i.e., any further tokens on the
original command line are ignored. Therefore any additional tokens should be
included within the continuation record(s).
14.9 QUIET Command Lines

In general when a program is run from a Command Line a window to hold
“terminal” output is created by the program and displayed on the desktop. For
certain programs, e.g., interactive programs such as SATLOOK, the terminal
window is essential; for others which, once initiated, essentially run without any
further user intervention, such as SATME2, the information displayed in the
terminal window such as listings of files used, etc. is provided simply to remind the
user what is happening and is not essential.
However, one of the problems with terminal windows is that they tend to “grab
focus”. Thus if, say, a user has set up a batch file to run a long sequence of
SATURN programs “in the background” and they wish to do something in Word
while the SATURN programs are running, each time a new program starts and a
new terminal window is created the user will have to minimise that window before
they can continue with Word. Not fatal but mildly annoying!
Note that this problem does not occur when interactive programs such as
SATLOOK are run with KEY + VDU modes in force since, in that case, no
terminal windows are set up.
5120257 / Apr 15 14-20

Section 14
In order to allow other programs to run “quietly” in the background as well a

special Command Line parameter QUIET has been set up such that, e.g., the
command:
SATALL net trips QUIET
will run SATALL without creating a terminal window or “grabbing focus”.

Presently the parameter QUIET is restricted certain programs only, specifically
SATNET, SATALL, SATSIM, SATEASY, SATPIJA, SATPIG, SATSUMA,
SATCH and SATME2 since these are the programs that users are most likely to
want to run in the background. Requests for the same facility in other programs to
Atkins.
Alternatively QUIET may be set to .TRUE. using a toggle provided within
SATWIN, in which case it will be applied automatically to all programs which
recognise the QUIET option (as listed above). See 15.55.
14.10 QUICK Command Lines

If a command line contains the keyword “QUICK” this signifies that the program is
to be run with the minimum number of iterations, loops, etc. etc. so that it runs
with minimal cpu time. For example (and indeed this is virtually the only example),
if a SATALL command line contains QUICK then MASL is set to 1, NITA and
NITA_M to 3, NITA_S to 2 and NITS and NITS_M to 5.
The basic objective of using QUICK is to test whether or not complicated batch
files which call a large number of programs and need to pass files between them
have been correctly set up before leaving them to run, say, over the weekend.
Alternatively QUICK may be set to .TRUE. using a toggle provided within
SATWIN, in which case it will be applied automatically to all programs which
recognise the QUICK option (as listed above). See 15.55.
14.11 Create Your Own BATCH Files: A Beginners’ Guide

Batch files – or .bat files to use their standard extension – are files which
individual SATURN users may create to run one or more SATURN .exe files
and/or other procedures. As such they may save considerable time and effort, in
particular for standard operations which are repeated multiple times, e.g. with
different networks and/or matrices each time. This is available through the DOS
Command Shell in SATWIN (see Section 3.6 et al)
Under 16-bit .bat files operated within the standard dos operating system; with 32-
bit they operate under Command Prompt. The latter appears to lack some of the
functionality of dos but, for simple operations, it is difficult to spot the differences.
As an example, to update a trip matrix file using SATME2 may require running
three programs in succession by commands such as:
SATALL net1 trips1
SATPIJA trips1 counts
SATME2 trips2 counts PRIOR trips1
5120257 / Apr 15 14-21

Section 14
where SATALL, SATPIJA and SATME2 are themselves .bat files which call the
equivalent .exe files.
The above three commands may themselves be subsumed into a single .bat file,
say UPME2 .bat, which could be written as:
CALL SATALL %1 %2
CALL SAPIJA %2 %3
CALL SATME2 %4 %3 PRIOR
so that typing:
UPME2 net1 trips1 Counts
would have the same effect as the original three commands. Note the use of %1,
%2 etc within the bat file to represent the successive arguments on the command
line; at execution net1 would be substituted for %1 in the call to SATALL etc
Note that .bat files may themselves call other .bat files (but see below for
problems under 32-bit Windows) which themselves call other .bat files to produce
a hierarchical structure.
Calls to standard dos functions may also be included, for example one file may be
copied into another so that UPME2 above might include a final line.
COPY %4.UFM LATEST.UFM
in order to save the “latest” trip matrix file with a standard name. Equally
temporary files may be deleted etc.
.Bat files may also include certain error checks and internal logic. For example
one may check whether or not an essential input file exists and take the
appropriate action if not, or the “convergence status” of a particular operation
monitored in order to terminate at the required level. Dos manuals may be
consulted for further information.
Within Windows, and Command Prompt, one particular problem arises which is
that Windows does not (apparently) wait for one program to terminate before
starting the next. Thus, in the above example, SATPIJA may begin before
SATALL has finished and therefore before the necessary file net1.ufs has been
created. A solution to this problem involves 2 “tricks”,
1) Use direct calls to exe files rather than to .bat files;
2) Use the command “start/W” as below.
Thus the UPME2.bat file above under Windows would become:
Start/W $SATALL %1 %2
Start/W $SATPIJA %2 %3
Start/W $SATME2 %4 %3 PRIOR %2
Empirically this guarantees that SATPIJA will only be initiated once SATALL has
terminated and all necessary files are available. For an example please look at
SATURN.bat.
5120257 / Apr 15 14-22

Section 14
There may of course be other “tricks” available within Windows to accomplish the
same ends.
5120257 / Apr 15 14-23

Section 14
JOB NUMBER: 5120257 DOCUMENT REF : Section14.doc
5120257 / Apr 15 14-24

Section 14
Special Options and Facilities
15. Special Options and Facilities

INTRODUCTION
This section contains a series of notes on special features of SATURN and is
intended to “explain” their use and/or interpretation rather than to describe the
nitty-gritty of how, for example, to set up input files.
15.1 Network Aggregation and Simplification within Intermediate Bands

N.B. This section, first created in September 2011, replaces a previous section on
“How Tutorials” which are no longer available.
15.1.1 General Principles of Network Simplification and/or Aggregation

SATURN networks are very often constructed in the shape of a “doughnut” (see
below) where the area of most interest in terms of scheme testing is at or near the
heart of the doughnut and the centre of the doughnut is coded as a simulation
network with the outside made up of a buffer network (see Section 2.3).
Typical Schematic Diagram of SATURN Network Types
The justification for using the less precise buffer network description is that, if one
is interested in analysing schemes at the centre of the network, the resulting
impacts within the distant buffer network will be minimal and the extra time and
effort required to code and run the full network as simulation cannot be justified.
A further advantage of a buffer network vis a vis a simulation network is that it has
better convergence properties due to the fact that it uses “separable” cost-flow
curves (see 7.1.3). Conversely simulation networks suffer potential problems of
non-convergence due to the fact that, by allowing for within junction interactions,
their cost-flow curves are non-separable. Very often this may introduce “noise”
into the solution which makes it difficult to accurately assess the impact of
relatively small schemes.
SATURN 11 has introduced the possibility of creating an intermediate network
band (referred to as the Peripheral Simulation Area in the diagram above) which
5120257 / Apr 15 15-1

Section 15
would lie, geographically, between the central “pure” simulation network and the
outer buffer network and which would be modelled at a simpler and/or more
aggregate level than the normal simulation but not necessarily as coarse as the
buffer network.
Two options are available for the intermediate region:
1) Conversion into a Fixed Cost Curve network (FCF);
2) Simulation to Buffer Transformation (SBT)
Fixed Cost Curves are described in Sections 15.1.2 to 15.1.6 below and the
Simulation to Buffer Transformation in 15.1.7. They are compared in 15.1.8.
15.1.2 Network Simplification using Fixed Cost Curves (FCF)

The FCF transformation retains the essential geometry of the simulation network
in that it distinguishes between separate turning movements at nodes but with
fixed - and therefore separable - “cost-flow” or “flow-delay” curves (FCF) for each
turning movement which should improve convergence and reduce “noise”. FCF
may be thought of as another form of “perturbation assignment” (see 22.2.6) or
“diagonalisation” (see 9.1.2).
The essential idea is that, in the intermediate FCF network, the flow-delay curves
for the simulation turns are “fixed” after a certain number of simulation-assignment
loops (see Fig. 9.1), presumably once a reasonably “good” level of convergence
has been reached. Thus, given the general flow-delay equation of the form (see
Section 8.4.2):
Equation 8.1 (reproduced)
t=
AV n + t0 V <C (a)
t AC n + t0 + B ∗ (V − C ) / C
= V ≥C (b)
The parameters t 0 , A, n and C are all treated as fixed for individual turns rather
than as variables calculated at the end of each new simulation.
A further property of an FCF (“Fixed Cost-Flow”) description is that the same
network properties may be applied to both a “do-minimum” and a “do-something”
network in order to minimise noise between the two.
Finally we note that the structure of the “assignment network” in which simulation
turns are represented by individual “links” is also unchanged under FCF; it is only
the nature of the cost-flow curves on these turn-links which has changed. This in
turn implies that a basic Frank-Wolfe assignment step will require roughly the
same CPU time with or without FCF – although we would expect a reduction in
overall CPU time with FCF due to a reduced number of assignment-simulation
loops.
15.1.3 Modelling FCF nodes within a Simulation Network

Those nodes which are designated as fixed cost-flow within a simulation network
are identified (and this is purely a technical detail) by an extra binary bit within an
5120257 / Apr 15 15-2

Section 15
array containing node properties (DA code 254 to be more precise). The following
two sub-sections describe how this may be accomplished; here we describe the
modelling differences – and similarities – between a “normal” simulation and an
FCF simulation.
Both styles of node simulation start with IN profiles on all input arms (see Section
8.1) and create OUT profiles along with delays. The difference is that the FCF
method is based purely and simply on the parameters in equation 8.5 (above and
section 8.4.2), rather than by a full simulation of interacting flows over short time
unit.
Thus, under FCF, the maximum OUT flow is determined by the minimum of (a) the
IN flow and (b) the (fixed) turn capacity (C in equation 8.5 above). The delay is set
by use of equation 8.5 for the current flows V.
Note that the modelling of IN/OUT flows ensures that the assigned flows are
correctly modelled within the FCF network and that any flow metering (reduced
flows downstream of V>C movements) is correctly retained as is the distinction
between “demand” and “actual” flows on all intermediate band links.
Equally any blocking back effects are retained under FCF in that the capacities C
used in equation 8.5 are the capacities post blocking back. However any
reductions due to blocking back are fixed and will not change as a result of any
flow re-assignment within the intermediate band.
On the other hand a lot of the detailed information that is provided by the normal
simulation, for example the “saw-tooth” style queue profiles at signals, lane
choice, blocking back factors etc. etc., are either no longer available or else retain
their values input at the point of “fixing”. Equally the most essential information
which is being passed from the simulation to the assignment, the flow-delay
curves, is, by definition, fixed rather than variable by loop. For this reason FCF
networks should only be set up once a reasonably stable set of cost-flow curves
have been obtained; i.e., that the simulation-assignment convergence is “good”.
15.1.4 Creating a FCF Network using SATCH

The first step in creating a “master” FCF network is to use the standard network
cordoning program SATCH to “add” FCF nodes to an existing well converged
network old_base.ufs; e.g.:
SATCH old_base control
To do so a new logical control parameter DOFCF is set to .TRUE. within &PARAM

in control.dat. All other inputs in control.dat, including the definition of the cut links
etc. etc. which define the innermost network, retain the same formats.
With DOFCF = T an additional output binary network file old_base.ufa is created -
with the (arbitrary) file extension .UFA - which retains the same network topology
as old_base.ufs but with three components – simulation, FCF and buffer – as
opposed to the two original components – simulation and buffer – in old_base.ufs.
See 12.1.11.
Thus the cordoned network (which is normally created as a separate self-
contained network by SATCH) defines the innermost pure simulation component
of old_base.ufa, the remainder of the former simulation network becomes FCF
5120257 / Apr 15 15-3

Section 15
and the buffer component (if any) is identical between old_base.ufs and
old_base.ufa.
Note that neither an output network data file control.kp which normally defines the
cordoned network nor a cordoned trip matrix are required in this operation; the
sole purpose of running SATCH in this fashion is to produce the new three-level
network .UFA file. (Therefore, to save unnecessary calculations and CPU, the
parameter DOMAT should always be set to .FALSE.)
To complete the first stage the file old_base.ufa should be renamed / copied as,
say, new_base.ufn and run through SATALL in order to create new_base.ufs.
(The reason for using the extension .ufn is that this is the extension required by
SATALL for an input network.) Provided that old_base,ufs was well converged in
the first place and the cost-flow curves for the fixed nodes are stable then the
differences between old_base.ufs and new_base.ufs should be minimal. And,
hopefully, new_base.ufs will converge much more rapidly.
15.1.5 Creating a FCF Scheme Network using SATNET

Having created a “master” network, e.g., new_base.ufs above, in which certain
simulation nodes have been designated as FCF, that information may be passed
to a new “do-something” network to be built by SATNET from a .dat file, say
scheme.dat, by making use of the UPDATE facilities.
Thus if UPFIL = ‘new_base.ufs’, UPDATE = T and also a new parameter UPFCF
= T under &OPTION then not only are all the normal network parameters in
scheme.ufn copied from new_base.ufs but equally any simulation nodes which
have been designated as FCF in new_base.ufs will also be so designated in
scheme.ufn. Plus the FCF flow-delay parameters in new_base.ufs (i.e., t 0 , A, n
and C) will also be passed as fixed parameters into scheme.ufn.
The expectation is therefore that the modified scheme network with its added FCF
nodes and, consequently, a reduced number of “proper” simulation nodes will
converge much better and therefore any comparisons between new_base.ufs and
scheme.ufs will have fewer problems with noise.
15.1.6 Viewing FCF Nodes within P1X

Nodes which have been converted to FCF operation may be viewed within P1X in
several different ways.
Firstly, they may be “selected” such that either only those nodes that have been
converted are displayed or vice-versa. See 11.6.5.3.
Secondly, they may be assigned a numerical “node data attribute”, 1 for converted
to FCF, 0 for not, and displayed as node data within P1X network plots and/or
processed as a node data column within SATDB. See 11.6.5.1 and/or 11.10.5.
Finally, the standard “print” listing of node properties includes a line to indicate
FCF operation for that node.
15.1.7 Simulation Buffer Transformation (SBT): Conversion to a Buffer Network

The second method to reduce simulation-based noise in an intermediate network
band is to convert that band from simulation into a pure buffer network format with
5120257 / Apr 15 15-4

Section 15
the inner segment remaining as simulation. So in this case we will still have the
traditional simulation/buffer “doughnut” but with an extended buffer component.
We refer to this method as SBT – Simulation to Buffer Transformation.
The SBT transformation may be accomplished by a combination of applications of
SATCH, SATBUF and SATCCS (12.1, 15.8.2 and 15.8.3 respectively) plus some
text file editing to produce a suitably updated network .dat file. Thus, assuming
that we start from old_base.ufs, we proceed as follows:
1) SATBUF old_base: to create old_base.buf with all simulation links in
old_base.ufs converted to buffer format;
2) SATCCS old_base: to create old_base.map with all simulation centroid
connectors converted to buffer format;
3) SATCH old_base control: where control.dat includes INCLUD = T in order to
produce $INCLUDE files control_11111,dat, control_22222.dat and/or
control_44444.dat to represent simulation data within the central cordoned
area.
At this stage we now have all the necessary components to create a new
network data file new_base.dat as follows:
4) COPY old_base.dat new_base.dat
5) Edit new_base.dat using a standard text editor, e.g., NOTEPAD, in which we:
a) Delete the existing 11111, 22222 and 44444 (if it exists) data segments
and ...
b) ... replace them by $INCLUDE references to control_11111.dat,
control.22222.dat and control_44444.dat.
c) Add 2 extra records “$INCLUDE old_base.buf” and “$INCLUDE
old_base.map” within the 33333 data segment (but do not delete any of
the existing 33333 data records).
Thus, at the end of the edit, we have a network .dat file in which the 11111, 22222
and 44444 data segments refer specifically to the central (cordoned) network
while the 33333 data segment has had extra data added in the appropriate format
to represent the (former simulation) links and centroid connectors in the
intermediate band.
We note that the two 33333 $INCLUDE segments added in step c) above will also
include the central simulation links and centroid connectors converted to buffer
format but since the same links etc. also appear in the new 11111 and 22222 data
sets they will be ignored by SATNET under 33333.
15.1.8 FCF vrs SBT

The two methods described above, FCF and SBT, have common objectives, that
is to reduce simulation noise in areas far removed from a particular scheme where
major changes would not be anticipated and to improve overall convergence and
CPU. They differ in the levels of aggregation applied within the intermediate
region.
5120257 / Apr 15 15-5

Section 15
Thus FCF retains the same basic geometry in the intermediate region whereby
each turning movement is still represented by a single link within the assignment
network with a (fixed) cost-flow curve and therefore, in terms of route choice,
different turning movements from the same entry link influence route choice. By
contrast with BCF the distinction between different turns has been removed.
In addition the FCF formulation permits flow metering to be modelled whereas
with SBT, as with any buffer network, there is no distinction modelled between
demand and actual flows.
We may also note that, to a first approximation, a network with a FCF conversion
gives the same results as the original simulation network. (In fact the first
assignment after the FCF transformation should give identical results to the next
assignment from the pure simulation network since the cost-flow curves are
identical; they only diverge thereafter to the extent that the simulated cost-flow
curves change). By contrast SBT networks give quite different results immediately
since the buffer-link representation is based on a quite different (and arguably less
realistic) network representation than the simulated turns.
Therefore, in terms of “realism”, FCF is preferable to SBT.
On the other hand in terms of CPU and convergence SBT is the winner in that the
reduced network size (roughly speaking including turns doubles or more the size
of the assignment network) leads to faster run times plus, arguably, faster
convergence.
Note that the original trip matrix is still valid for the transformed networks, whether
under FCF or SBT, since the zone structure has not been changed at all in the
new networks.
15.2 Preferences files

All interactive programs require a “preferences” or “initialisation” control file in
order to set default values for various parameters. The files are assigned
standard names such as P1X0.DAT, MX0.DAT, etc. (i.e. ‘program name + 0’.dat).
They consist of a set of namelist-based definitions of purely internal program
variables which control, for example, the size of arrows in node graphics. These
therefore are the variables whose values are changed by users via the standard
menus.
Formal definitions of the valid variable names in each file are not provided nor are
they necessary for users. An updated version of any preferences file may be
produced by the program via the files sub-menu and these will contain both the
input values plus the new values of any parameters changed by the user in that
session.
Hence users can “customise” a preferences file to their own individual
specifications and any subsequent program runs will use these specifications.
Preferences files exist for the following programs: P1X, SATED, SATDB, MX and
SATLOOK.
5120257 / Apr 15 15-6

Section 15
By default preferences files are stored in a specific sub-directory set by

SAT10KEY.DAT (see Appendix Y) but it is possible to select alternative
preference files using the “PREF” keyword in standard .bat files. For example:
PIX network PREF C:\DVV\PREFS\JIMBO
selects the preferences file JIMBO.DAT in subdirectory DVV\PREFS rather than

the default P1X0.DAT.
In certain cases variables which can be namelist-set in SAT10KEY.DAT may be
over-written by individual Preferences Files; e.g., GO4IT and KPEXT. In general
the values set in SAT10KEY.DAT might be thought to refer to values for an
“organisation” as a whole while values set in Preferences Files might be more
appropriate to individual users or jobs.
If, however, a program cannot locate a preferences file it is not the end of the
earth - or the program. In that case a standard set of default parameter values
are adopted.
Note that a slightly different way to customise the set up of an interactive program
is to use the “break” option in a key file (see 14.5.5) whereby the necessary
commands are contained in the key file which initiates the run but terminates on
“break” allowing the user to carry on as per normal from that point.
15.3 Network Updates (The Update Option)

It is very often the case in calibrating a network that successive test networks
differ only marginally from previous tests. It is possible to take advantage of this
fact by using the output from former runs to provide a realistic starting point for the
subsequent run. More specifically, values of the previous flow-delay parameters
(including values of the ratios of actual to demand flows, QRF – see 17.2) are
extracted by SATNET from an “update network” to set initial values for input to the
first assignment rather than starting “cold” with not very realistic default values.
This has the great advantage of (potentially) significantly reducing the number of
simulation-assignment iterations on the second run by making the initial
assignment far more realistic.
In addition, post 10.8, selected data relating to the simulation is also extracted
from the “update network” rather than setting default values in order to make the
first simulation more realistic.
In order to invoke the UPDATE option two steps need to be taken:
♦ Set UPDATE to TRUE on &OPTION in the new network DAT file.
♦ Input the UFS file from the previous sequence on channel 2 to SATNET
(which may most easily be done using the parameter UPFILE (see section
6.1) to define the filename).
We note that this procedure is very similar to the PASSQ option (17.3.1) which
also (if UPDATE = F) extracts flow-delay data from a previous network file (in this
case, the PASSQ file from the previous time period) The difference under
UPDATE = T is that only flow-delay information is extracted from the update file,
not the queues and suppressed traffic as with PASSQ.
5120257 / Apr 15 15-7

Section 15
Note that both UPDATE and PASSQ may be used at the same time but, if so,
they must use two different input .ufs files (parametric filenames UPFILE/FILUP
and FILPQ respectively). If only PASSQ is used then there is no option to cancel
the flow-delay updates.
The extended SATURN procedures may be used here - the command format is
illustrated in Section 14.4.2.
Further Notes:
1) The second network may in fact be structurally quite different from the first in
the sense that new nodes and new links or turns can be introduced. The
program is set up in such a way that only information on turns and links
common to both networks are carried over. For “new” turns default flow-
delay parameters are assumed. Clearly though, the more similar the two
networks are, the greater the savings in CPU time.
N.B. Both UPDATE and PASSQ (17.3.1) allow the “pre-network” to have a
different structure from the “main network” whereas – at the time of writing –
the pre-load option PLOD does not (see 15.5.1). This is likely to change in
the future.
2) Note that the UPDATE option as described here implies that only the
network is updated, although it is also permissible to introduce a different trip
matrix at the same time. If, however, one only wishes to change the trip
matrix then the appropriate steps are described under the Re-start Facility in
Section 15.4.
3) In order to ensure that the first assignment within the assignment-simulation
loop takes full advantage of the improved initial set of flow-delay curves the
maximum number of assignment iterations, normally set by the parameter
NITA, is set to the maximum of NITA, NITA_S and 25.
4) It is possible (post SATURN 10.6) for a file to, in effect, update itself in the
sense that an “old” UFS file, say net.ufs, may update a “new” network data
file net.dat. In other words it is not necessary to re-name the network every
time a minor change is made and the results from the previous incarnation
are used to the full.
Note as well that, if UPDATE is set to .TRUE., but the UFS file to be updated
has not been defined then it is assumed by default that the file to be updated
IS net.ufs (when the data file is net.dat).
This option is particularly useful when running multiple time periods using
SATTPX (17.4.3) since, in that case, each time period has a unique filename
(e.g., neta, netb, netc etc.) emanating from a single data filename (e.g.,
net.dat). The individual time-period filenames will be automatically and
correctly invoked if UPDATE = T in net.dat but no specific .ufs filename (e.g.,
net.ufs) is set.
5) The UPDATE option may be very usefully combined – under either path-
based or origin-based assignments - with the WSTART option which adds
additional information related to path flows and which improves the initial
5120257 / Apr 15 15-8

Section 15
assignment even more than just having improved cost-flow curves. See 21.3
for further details.
15.4 Updating the Trip Matrix (The Re-start Facility)

The re-start facility allows a user to carry out a full set of SATALL simulation-
assignment loops when the only difference between the current and a former run
is in the trip matrix, for example when SATME2 is used to estimate successive trip
matrices or when the assignment is part of an external demand-supply procedure,
possibly using MX.
If there are any other differences at all apart from the trip matrix, e.g., changes in
PASSQ flows, etc. etc., then a re-start in SATALL is not appropriate.
Re-start is effectively equivalent to UPDATE (Section 15.3), the main distinction
being that it is applied directly within SATALL whereas UPDATE is applied in
SATNET. It is also, under path-based or OBA assignment (MET = 1 or 2),
equivalent to WSTART = T; i.e., the first assignment uses the paths from the
previous assignment as a “perturbation” assignment (see 21.3).
The distinction between a normal run and a re-start is that the former must start
with the network build program SATNET before commencing the
assignment/simulation loops (see Figure 3.1) whereas the latter uses a previous
network and starts with the assignment directly. Subsequent
assignment/simulation loops are the same thereafter.
The first assignment requires (in effect) as input:
♦ The final UFS file from the previous sequence (This file contains the
necessary network specifications and parameters.)
♦ The latest trip matrix UFM file.

The command
SATALL network tripod RESTART
carries out a full simulation-assignment loop but taking its input from the
previously converged file network.ufs as opposed to network.ufn which comes
direct from SATNET.
Note that it is the presence of “RESTART” on the command line which initiates the
re-start sequence; i.e. no parameters within a .dat or control file need to be set.
However an alternative DIY method to set up re-start would be to copy a .ufs file
into a .ufn file yourself and create a control file for SATALL with the parameter
REGO = T; see 7.13.2. Not recommended!
The output version of network.ufs will over-write the original input version and will
include the new flows etc. If you wish to retain separate .ufs files from each step it
will be necessary to take a copy of each output .ufs file with clearly, different
names.
The main advantage of using the re-start facility, apart from being able to skip one
execution of SATNET, is that the new sequence starts with the flow-delay curves
and simulation profiles from the previous run. In the former sense RESTART is
5120257 / Apr 15 15-9

Section 15
therefore very similar to the use of UPDATE within SATNET, although the use of
old simulation profiles is exclusive to RESTART.
If the new trip matrix is not much different from the old then the final flow-delay
curves, etc. will not be much different either. Hence by starting with good
approximations the overall number of assignment/simulation loops can be sharply
reduced.
Section 22.2.2 contains further information on RESTART, including its relationship
with other similar “kick-start” techniques.
15.5 Pre-Loading Fixed Flows (The “Plod” Option)

The “pre-load” option was introduced at an early stage of SATURN development,
somewhat as a short-term measure, to deal with the problems of, say, assigning
heavy lorries separately from other vehicles. Indeed that particular application,
described in 15.5.1, has been largely superseded by the Multiple User Class
Assignment option which is more general and more flexible and generally
recommended in preference to PLOD (see 7.3). However, as discussed in 15.5.2
and beyond below, a number of other possible applications have emerged over
the years.
In simple terms pre-loaded flows are fixed flows introduced onto the network
before any assignment takes place but which contribute to the total flows used to
calculate costs (times) in the assignment. They are always defined in units of
pcus/hr and have no other properties such as being part of a particular user class
or vehicle class. However in terms of calculating their total pcu-hrs etc. it is
assumed that their travel times are as defined for user class 1.
Note that, in certain circumstances, pre-loaded flows may contribute to exit and/or
entry flows on simulation links (see 15.6.2). For example, if a flow of 100 pcus/hr
is preloaded on turn A-B-C but no flow is preloaded onto link A-B then a flow of
100 pcus/hr must be added as a downstream entry flow on A-B.
15.5.1 Pre-loading HGV’s

The procedure to be followed with heavies plus cars would be to:
♦ Set up a “heavies” network and carry out a full SATURN run assigning only a
matrix of heavy vehicles.
♦ Set up the “normal” network with the previous demand (i.e., not actual) flows
“pre-loaded” onto the network and treated as fixed flows in the same way that
buses are.
The second or “normal” network file would have PLOD = T in &OPTION (and,
preferably, the name of the pre-loaded file via PLDFIL) whereas the first would
have PLOD = F (the default).
In effect the PLOD option allows the heavy lorries to have the first choice of route
and implies that whereas lorries can affect the routes subsequently chosen by the
“normal” vehicles, the normal vehicles cannot in turn affect lorries. In some
circumstances this may not be a totally unrealistic assumption; however allowing
5120257 / Apr 15 15-10

Section 15
for interaction in both directions would no doubt be preferable and is provided by

Multiple User Class Assignment (Section 7.3).
While the lorry network can have different network properties from the “normal”
network, e.g., different link speeds, etc., both networks MUST be structurally
identical, i.e., have the same nodes, links and turns (unless a text file is used’ see
15.5.4). (N.B. PLOD differs from PASSQ and/or UPDATE in this respect: the
PASSQ/UPDATE networks may have a different structure from the main network;
see notes 1) in section 17.3.1 and section 15.3 respectively.) Hence, strictly
speaking it is not (yet) possible to introduce lorry bans by banning turns or
removing links in the lorry network. However lorry bans can in fact be introduced
by certain relatively simple tricks.
For example, you can effectively ban lorries from a link by giving that link an
extremely high travel time in the lorry network (assuming of course that there are
alternative routes available). Banned turns may be introduced by coding them as
bus-only turns even if there are no buses; the model response to a bus-only turn
is to prevent any elements in the trip matrix - in this case lorries - from using those
turns.
Some caution must be exercised when using PLOD so that other forms of fixed
vehicles are not loaded twice. For example, bus routes should not be coded as
part of the lorry network, only as part of the normal network, since any bus flows in
the lorry network will be automatically added as fixed flows to the normal network.
Clearly the same basic procedure is carried out with any combination of assigned
vehicles, not necessarily just lorries and cars.
15.5.2 Pre-loading Distance Minimisers

Another useful application of the PLOD option is to carry out a separate
assignment of a trip matrix of “distance minimisers” whose route choice is, by
definition, independent of other trips. How of course one defines such a trip
matrix in the first place is entirely up to the user. Again distance minimisers may
be treated as a separate user class.
It is also quite feasible to do several stages of pre-loading. For example, you can
start with the distance ‘minimisers’, pre-load them onto a lorry network - in which
case the output flows would consist of both lorries and distance-minimisers - and
then pre-load that network onto a normal network. Clearly some care is called for
here to choose the best order and to avoid double counting, etc.
15.5.3 Pre-Load Statistics

The assignment network statistics include totals for any pre-loaded trips
separately from the over-all totals, but - as of yet - no comparable breakdown is
available within the simulation network.
15.5.4 Pre-Loading from a (Text) Data File

It is also possible to input pre-loaded flows from a text-based data file as opposed
to a SATURN .ufs file (post version 10.4). For example, if you have extensive bus
flows but do not wish to code them as individual routes, only to represent their
total flow across the network, then it may be done by setting up a text file wherein
5120257 / Apr 15 15-11

Section 15
each record contains: (a) link identification (in standard or free (CSV) format; see
below) followed by (b) the corresponding flow in units of pcu/hr.
Alternatively if the pre-load file and the current file have a different network
structure and pre-loading from a .ufs file is not permitted (paragraph 4, 15.5.1),
then the relevant flows may be pre-loaded by first dumping flows from the pre-load
file into a text file; e.g., use SATDB (11.0.9).
SATURN differentiates between the two by looking it the extension of the input
file: if it is .ufs/ufa/etc. it assumes a SATURN file, if not it assumes a text data file.
See 14.4.4.
The format of the link identification may either follow standard SATURN input data
conventions, see, for example, 6.10, with node numbers in fixed columns followed
by a (single) link flow or both node numbers and flow may be input totally as “free
format” or CSV by setting a parameter PLODFF = T in the network &OPTION data
segment (see 6.1). By default PLODFF = F.
Note that pre-loaded “links” should normally include both “roads” and “turns” in a
simulation network. Including only “roads” will lead to discontinuities in flows at
simulation junctions.
Within free-format text files (PLODFF = T) a further &OPTION parameter PLFF3 =
T requires that each input record contains 4 fields – A, B , C and flow. Thus links
are distinguished from turns by always including an explicit third C-node field
which is equal to zero for a link and the turn C-node otherwise.; i.e., A,B,0,link-
flow(A,B) as opposed to A,B,C,turn-flow(A,B,C).
Alternatively, if PLFF3 = F, then link records require 3 fields (A and B followed by
the flow) whereas turn records require 4 fields in total (A, B, C and flow). By
default PLFF3 = F.
For fixed column input (PLODFF = F) PLFF3 does not apply since the fixed data
columns used for a C node will simply be blank (or zero) for a link and the flow
data is in the same (fixed) columns for both links and turns.
See Section 9.12.3 for suggestions as to how the pre-load facility may be used in
combination with the parameter ZILCH to carry out a 100% pre-load.
15.5.5 Pre-Loading Bus (PCU) Flows

As noted in Section 5.5.4 it may be possible / convenient to define bus flows as
pre-loaded flows 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/turn and input them as fixed pre-loaded flows rather than go through
the hassle of defining individual routes as per 6.9; the impact on the assignment
and (with some reservations) the simulation will be identical.
On the other hand, bus flows may have certain properties that distinguish them
from other flows, e.g., bus lanes. Equally coding buses as aggregate fixed flows
means that you cannot analyse individual route timings etc.
5120257 / Apr 15 15-12

Section 15
15.6 Comparing Assigned and Observed Flows: GEH Statistics
15.6.1 General Options

It is possible to obtain a number of goodness-of-fit statistics comparing the
modelled flows on both links and turns with observed counts in order to check the
performance of the model. This can be carried out in several ways:
The most comprehensive and flexible set of comparisons is available within P1X,
either under Validation (11.7.1) or SATLOOK (11.11.13). In these cases the
observed flows are taken from the input .ufs file as originally read as 77777
records in the network .dat file. The modelled flows may be defined in a number
of different ways in order to match the precise definition of the counts used; e.g.
demand or actual flows may be used (actual probably makes more sense in
general), bus flows may be included or excluded, a single user class flow may be
selected, etc. etc.
Note that Validation, being newer, provides more options than SATLOOK. On the
other hand SATLOOK is probably easier to run with a key file or as part of an
extended batch file.
Alternatively, both counts and flows may be read into SATDB and the standard
statistical options to compare two data columns invoked. Users may wish to
define their own difference measures based on the column- manipulation facilities
within SATDB. Within SATDB the user may select either actual or demand flows
as preferred.
Finally P1X can also display difference statistics graphically under link annotation.
Two standard items are “ABS ERRORS” which is the difference between counts
and actual flows and “REL ERRORS” which gives the relative differences as a
percentage.
15.6.2 GEH Statistics

With one exception the output comparison statistics are standard and
straightforward, the exception being what is referred to as “The GEH statistic”.
This is a statistic, first suggested to me by Geoff Havers of the Greater London
Council, which is useful in comparing two different values of flow on a link, V1 and
V2. It is defined by:
(V2 − V1 ) / ( 0.5 (V1 + V2 ) )

GEH =
2
It may most easily be thought of as the square root of the product of the absolute
difference, V2-V1, and the relative difference, (V2-V1)/VBAR where the “average
flow” VBAR = 0.5*(V1 + V2).
The reason for introducing such a statistic is the inability of either the absolute
difference or the relative difference to cope over a wide range of flows. For
example an absolute difference of 100 pcu/h may be considered a big difference if
the flows are of the order of 100 pcu/h, but would be totally unimportant for flows
of the order of several thousand pcu/h. Equally a 10% error in 100 pcu/h would
not be important, whereas a 10% error in, say, 3000 pcu/h might mean the
difference between building an extra lane or not.
5120257 / Apr 15 15-13

Section 15
Generally speaking the GEH parameter is less sensitive to such problems since a
modeller would probably feel that an error of 20 in 100 would be roughly as bad as
an error of 90 in 2,000, and both would have a GEH statistic of, roughly, 2.
The following table gives an indication of various levels of GEH values, both
qualitatively and quantitatively:
Value Comment Examples
GEH = 1.0 “Excellent” +/- 65 in 4,000 +/- 25 in 500
GEH = 2.0 “Good” +/- 130 in 4,000 +/- 45 in 500
GEH = 5.0 “Acceptable” +/- 325 in 4,000 +/- 120 in 500
GEH =10.0 “Rubbish!” +/- 650 in 4,000 +/- 250 in 500
Thus, as a rule of thumb, in comparing assigned volumes with observed volumes

a GEH parameter of 5 or less would indicate an acceptable fit to a traffic modeller,
whether it was a difference of 325 to 4,000 or 120 in 500, while links with GEH
parameters greater than 10 would probably require closer attention.
It needs to be noted that the GEH statistic is an “intuitive” and “empirical
engineering” measure, not necessarily a measure that a professional statistician
would recognise or deign to use. However, it should also be noted that the square
of the GEH parameter is not unlike the well-used chi-square measure of fit, and
would be the same if either V1 or V2 (whichever was the ‘observed’ flow) were
used in the denominator. (One reason for taking the average is to avoid possible
problems when either V1 or V2 equals zero.)
It is however not particularly useful to take the comparison too far, particularly
when comparing modelled to observed flows, since the sum of the GEH2 values
interpreted as a chi-square statistic will almost certainly indicate that the two are
significantly, indeed very highly significantly, different and that therefore the model
is ‘wrong’. From a pure statistical point of view virtually all transport ‘models’ are
wrong in that they fail to reproduce observations. What a transport modeller
wants is a model which, although not strictly correct, is adequate for the uses to
which it is applied.
A further distinction between GEH and chi-square is that the latter gives a
relatively greater weight to larger differences between flows, for example, to
“outliers”. For example, errors of 63 and 126 in 1000 pcu/hr give GEH values of
(approximately) 2 and 4 but chi-squared values of 4 and 16. GEH effectively says
that an error of 126 is “twice as bad” as 63, not four times as bad. These
differences are reflected in aggregate measures such as the average of all GEH
statistics from a set of counts.
With version 10.1 the GEH statistic comparing two database columns in
SATDB/P1X may be calculated as an explicit function; see 11.10.8.
15.7 Use of SATURN Outside the U.K.

Although SATURN has clearly been set up in the U.K. and with U.K. applications
in mind it has been programmed in a perfectly general manner so that with
minimal changes it could be applied in other countries, e.g. in Australia and New
5120257 / Apr 15 15-14

Section 15
Zealand using the NOTUK parameter and in countries where vehicles drive on the
right using LEFTDR.
15.7.1 The NOTUK Parameter

Setting NOTUK NE 0 in the &PARAM namelist input causes the model to make a
number of assumptions concerning priorities for turns coded with one of the
priority markers described in Section 6.4.2 which differ slightly from the
assumptions made in the U.K. They are as follows:
♦ Opposite right-turning vehicles, for example at traffic signals do not interfere

with one another, whereas in the U.K. it is assumed that they execute a
‘hooked’ movement.
♦ Right-turning vehicles at traffic signals (i.e. turns coded as X) have priority

over left-turning vehicles coming from the opposite direction.
The values allowed for NOTUK are:
♦ 0 - neither assumption (the default UK value);
♦ 1 - assumption (i) only (as in Australia apart from Victoria);
♦ 2 - assumption (ii) only;
♦ 3 - both (i) and (ii) (as for Victoria and New Zealand)
The “traditional” (i.e., dating back to the 1970’s) default value in SATURN is 0
implying that opposing right turns in the UK do hook and therefore interfere with
one another. However in the 21st Century UK the opposite is almost certainly the
norm and, paradoxically, a value of NOTUK = 1 would be recommended.
However, setting NOTUK = 1 on existing networks may not be a good idea if a
large number of individual turns have been given a Priority Modifier D which
reverses the definition of hooked/not hooked (see 6.4.2.7). I.e., if you set NOTUK
= 1 but do not change XD to X then all those turns will be assumed to hook.
15.7.2 Right-hand Drive: LEFTDR = F

Although clearly designed for British conditions with drive-on-the-left it is equally
easy to use SATURN for drive-on-the-right. To invoke drive-on-the-right set the
parameter LEFTDR to .FALSE either “universally by default” in SAT10KEY.DAT
(Appendix Y) or network-specific (6.3.1). Differences occur in the input in that
simulation links need to be input in strictly counter-clockwise order for right-hand
drive instead of clockwise.
More serious problems might arise with junction types and/or control strategies
which are radically different from those used in the U.K., or - more accurately -
cannot be represented properly by SATURN.
Output differences include writing “right hand” rather than “left hand” etc. in
messages and in annotating on the opposite (i.e. “correct”) side of the links in
graphical displays (where it is very important to have LEFTDR set correctly).
5120257 / Apr 15 15-15

Section 15
15.8 Using SATURN as a Conventional Assignment Model
15.8.1 Buffer-only networks

As mentioned in Section 5.2 it is possible in the limit to use SATURN as a
conventional assignment model by defining a network which consists entirely of a
buffer network with no simulation nodes. In such a case one would use SATNET
to build a network file and SATEASY to carry out the assignment. Given that there
are no simulation nodes there is no necessity to use the simulation stage SATSIM
and the assignment obtained from one execution of SATEASY is a convergent
solution within the limit of the convergence parameters set. Note that one could
also use SATALL instead of SATEASY; it carries out the identical assignment
procedures and is recommended.
There are a number of reasons why one might wish to use SATURN in this way.
For example users might wish to model large-scale interurban networks for which
junction modelling is not essential. Another example would be the user who
wishes to use the matrix update facilities within SATURN without necessarily
wishing to define all or part of his network in the detail required by SATURN. A
third example is the use of SATURN purely as a network data base.
The ASCII .dat file necessary to define such a network must commence with the
three mandatory input records (OPTION namelist, title and PARAM namelist) as
described in Section 6, immediately followed by a buffer network “header” record
of a 3 in column 1 and the buffer network description terminated by a ‘99999 card’
as specified in Section 6.6. Node co-ordinates, route flows etc. (optionally)
follow. The final card in the file must be another 99999 card.
The use of default speed-flow curves within the 333 records (15.9.5) may be
extremely useful in buffer-only networks.
Thus a “typical” file might read:
&OPTION
&END
THIS IS A PURE BUFFER NETWORK
&PARAM
BCRP=4.0,
LIST=T,
&END
33333
3 2 28 56 2500 1 100 3.1
29 2 21 42 1250 2 90
2 3 28 56 3750 1 100 3.1
C 2 59 10 50
C 3 60 10 25
...
99999
55555
..... Co-ordinate data
99999
99999
(End of file)
5120257 / Apr 15 15-16

Section 15
15.8.2 Converting Simulation Networks to Buffer (SATBUF)

For various applications it is sometimes useful to convert a network with a
simulation component (either entirely or in part) into a pure buffer network, e.g. to
carry out very simple sensitivity testing or to convert it for use in another suite of
programs (so, SATURN not good enough for you, eh?) Essentially this requires
that link cruise times plus junction delays are converted into the best equivalent
buffer speed flow curves which, since they cannot distinguish between different
turning movements, must of necessity be suitably weighted averages.
The averaging of delays may be carried out using routines within SATDB and
data for each simulation link dumped to an ASCII file. A special purpose .bat plus
.key file is provided to do this. Type
SATBUF net
to produce an ASCII file net.buf which contains for each simulation link (A,B) a
single record containing:
♦ Its A-node
♦ Its B-node
♦ The average free-flow time (in seconds)
♦ The average time at link capacity (in seconds)
♦ The distance (in metres)
♦ The link capacity (in pcu/hr)
♦ The weighted flow-delay power n.

The times above include both cruise time along the link plus a flow-weighted
average of the delays to each individual exit turn:
d = ∑ Vi di / ∑ Vi
where:
di = delay for turn i
Vi = simulated (actual) flow for turn i
Thus if you have a simulated right turn with a very long delay but (consequently) a
very low flow this will have relatively little effect on the delays which would be
modelled in the buffer network (so that in a buffer network representation you
could expect to overestimate that particular turning movement).
The capacity is that already calculated for each simulation link (see 8.9.4 for
further details) while the flow-delay power n is a weighted sum of individual turns
as with delays above.
Both the order and the format of the output variables is the correct order required
by buffer network input to SATNET (section 6.5). Thus the times, capacity and
distance are all output as “integers” although they are calculated as “reals”.
5120257 / Apr 15 15-17

Section 15
Note that SATBUF deals only with simulation links, i.e. the 11111 data input, and
that users must decide for themselves how to deal with simulation centroid
connectors - the 22222 data inputs. One very simple solution, which implies using
an editor, is to edit the 22222 records by
♦ inserting a C in every column 1
♦ deleting all records from column 11 onwards.

This has the effect of producing a correctly formatted set of buffer link records with
the zone as A-node and the first simulation node entered as its B-node. Whether
this is a good way to re-code centroid connectors is another question.
N.B. If DUTCH = T in the network being “bufferised” then an alternative version of
the batch file may be run thus:
SATBUF net DUTCH
in which case the new link A-nodes and B-nodes will appear in column blocks of
10, not 5 in the output file net.buf. (Added in version 10.9.15)
15.8.3 SATCCS: Converting Simulation Centroid Connectors to Buffer

An extra batch file introduced in Release 11.1, code-named SATCCS, performs
essentially the same job as SATBUF but operates on simulation centroid
connectors instead of simulation links. Thus the command:
SATCCS net
creates an output text file net.map with link data in the 33333 format for simulation
centroid connectors only.
Thus if a zone Z is connected to simulation link A-B then there will be a record A-Z
and another from Z-B with appropriate distances, times, etc. etc.
The intention would normally be that the file map.dat would be included within the
33333 section of a buffer-only network .dat file (either verbatim within the 33333
data segment or, perhaps preferably, as a $INCLUDE file. See 15.1.5 for such an
application.
The procedure uses the “dump map links” option within P1X (see 11.4.2.3) but in
a purely off-line batch mode and with only simulation centroid connectors
selected. No special KEY file is required (unlike SATBUF).
15.9 Converting Conventional Speed-Flow Curves into SATURN Curves

It is very often handy for users with existing networks coded in conventional detail
to convert their networks into a SATURN network by stages. Thus the first step
would be to code the existing network as a buffer-only network (presumably using
a computer program to carry out the necessary changes in format) with no
simulation network, as described in Section 15.8. Preliminary tests may now be
carried out with very little coding effort.
5120257 / Apr 15 15-18

Section 15
Certain problems may arise in converting existing speed-flow curves into the flow-
delay relationship as specified by SATURN for its buffer network, i.e., an nth order
power law for flows less than capacity and a linear relationship for flows above
capacity (see Section 5.4 and equation (5.1)). These problems may concern not
only the calculation of n – dealt with below – but also problems with the
interpretation of parameters such as capacity.
We consider first the range of flows less than capacity, V<C. Clearly if the existing
curves are already in the form of a power law then the problems here are minimal;
the user must simply ensure that the required value of n is set in BCRP if it is
constant for all links or is input for each individual link.
If however the existing curves are of a different form it will be necessary to define
power-law curves which, in some sense, give a “best fit” to the existing curves.
There are many ways in which this can be done, depending both on the definition
of “best fit” as well as on the shape of the existing curves.
Different countries may well have different recommended forms. We illustrate
here one method which may be used to convert curves of the form recommended
by the UK Department of Transport, currently referred to as DfT, but for historical
reasons also referred to as DTp.
15.9.2 DFT/DTp Advice Note 1A

DTp (“Advice Note 1A”) recommended curves have the following form:
t (V ) = d / S (V )
 S0 V ≤F

S (V ) =  S1 + ( S1 − S0 )(V − F ) / ( C − F ) F <V ≤ C

 S1 / (1 + S1 (V − C ) / 8dC ) V >C
Where:
t is the link time (in hours),
d is the link distance (in kilometres),
S is the link speed (in kph),
V is the link flow (in PCU per hour),
S0 is the “free flow” speed,
S1 is the speed at capacity,
F is the maximum flow at which free-flow conditions hold
C is the capacity
We wish to fit the above curve, in the range V < C, with a function:
t= t0 + aV n
The three unknowns, t 0 , a and n, are fitted from the following constraints:
1) Free flow times must be the same (hence t 0 = d/S 0 );
5120257 / Apr 15 15-19

Section 15
2) Capacity times must be identical, and

3) The “average” travel times must be the same.
Condition (3) is the critical one for determining n. We define the average travel
time to be:
C
∫ t ( v ) dv / C
0
Hence for SATURN the average time is given by:
t0 + aC n +1 / ( n + 1) C
t =
=
t0 + aC n / n + 1
t0 + ( t ( C ) − t0 ) / n + 1
=
Integration of the DTp curve gives:
t = t0 + (1 − F / C ) ( ln ( S0 / S1 ) / (1/ t0 − 1/ tc ) − t0 )
Hence:
( )
n = ( r − 1) / (1 − F / C ) ∗ ( r ln r / ( r − 1) − 1) − 1
=
where r S=
0 / S1 tc / t0
A section of FORTRAN code which does the above job is given below:
R = S0/S1
XN = 0.0
IF (R.GT.1.0) THEN
XBOT = (1.0 - F/C) * (R*ALOG(R)/(R - 1.0) - 1.0)
IF (XBOT.NE.0.0) XN = ((R - 1.0)/XBOT) - 1.0
END IF
and the following table gives values of n for ‘typical’ DTp parameters (where the
speeds are in kph and the flows/capacities in pcu/hr):
S0 S1 F C N
90 76 3600 5200 5.89
79 70 3200 4800 5.25

70 57 400 1800 1.76
63 55 400 1400 1.93
50 50 0 600 0.00
80 66 3400 4800 6.33
65 56 2800 4400 4.79
5120257 / Apr 15 15-20

Section 15
S0 S1 F C N
50 30 1200 2200 4.29
45 25 500 1000 3.96

35 25 350 600 4.40
25 15 250 500 3.81
67 47 0 4000 1.27
61 27 0 3400 1.72
For the range of flows above capacity, DTp and SATURN curves both have a
linear relationship, although the slope of the curve in SATURN is determined from
the length of the time period simulated (parameter LTP) while that for the DTp
curve is set by the parameter ‘8’ in the above equation which has units of 1/hours.
To set up the same slope in SATURN it is therefore necessary to set LTP = 15,
i.e., 1/4 of an hour since the slope equals 0.5*LTP.
Having set up the buffer network the user may now begin to code parts of the
network in the format and detail required for a simulation network, starting with
those nodes where the extra detail is most required and working outward as far as
may be required. Since any node that appears in both the simulation and buffer
networks is ignored in the buffer network nodes may be coded as simulation
nodes without having to remove them from the coded buffer network. One
advantage of coding SATURN networks in this way is that the user gains coding
experience by degrees and thereby makes fewer mistakes overall.
Note that in following this procedure the nodes which lie on the boundary between
the simulation and buffer networks at any stage MUST be included as external
nodes in the simulation network unless one uses the AUTOX facility as described
in Section 15.12.
15.9.3 COBA 10 Speed-Flow Curves

The form of the DfT-recommended speed-flow curves was replaced in the late
1980’s by the so-called “COBA-10 curves” with two sloping linear segments as
opposed to Advice Note 1A above which had a flat segment followed by a linear
slope. Figure 15.1 below illustrates the new form for flow V less than capacity C.
They are still in use to the present day (2007) although the specific numerical
values for individual curves are out-of-date.
N.B. The “x-axis” or flow-axis in Fig. 15.1 is specified in units of vehs/hour
whereas SATURN (see 15.17.1) generally works in terms of PCUs/hr; some
conversion may therefore be required if one wishes to fully translate COBA
curves for use in SATURN. See 15.9.4 below.
5120257 / Apr 15 15-21

Section 15
Figure 15.1 - COBA 10 speed vrs flow curves
The following equation describes the relationship:
 S0 + ( S1 − S0 ) * (V / F ) V ≤F

S (V ) =  S1 + ( S 2 − S1 )(V − F ) / ( C − F ) F <V ≤ C

 S 2 / (1 + S 2 (V − C ) / 8dC ) V >C
Where:
S 0 is the free flow speed
S 1 is the “intermediate” break point speed
S 2 is the speed at capacity C
A “best-fit” value of the power n may then be determined by the equation:
n= ( R1 ∗ R2 − 1) / ( B1 + B2 − 1) − 1
where:
B1 =
( F / C ) R1 log R1
( R1 − 1)
B2 =
(1 − F / C ) R1 ∗ R2 log R2
( R2 − 1)
R1 = S0 / S1
R2 = S1 / S 2
N.B lim ( R log R ) / ( R − 1) =

1
R →1
and “log” above refers to the “natural log”
5120257 / Apr 15 15-22

Section 15
Our thanks are due to Yazid Arezki for working out the above formula, thus
confirming earlier numerical values calculated by Devon County Council.
In previous versions of the manual, a set of calculated values of n for “standard”
UK road classifications were provided in a Table (often referred to as ‘Table 15.9’)
with a shorthand description of each road type.
With the release of 10.9.24, the table was withdrawn as its inclusion was only
intended to illustrate a range of ‘typical’ values of ’N’ which may result, using the
formulae above, from piece-wise linear curves. The values used in the table were
originally taken from COBA data sets of circa. 1990 and were not, in any sense,
recommended as up-to-date values for different road types In practice however,
users were applying the Table 15.9 curves without undertaking the necessary
critical review required for their specific application.
To assist users, an illustrative comparison of a ‘typical’ COBA piece-wise curve
and the equivalent SATURN Power curve is provided overleaf in Figure 15.2; The
data parameters used (listed below) and the best-fit value of N are for a (nominal)
dual 3-lane motorway with 15% HGVs. Figure 15.3 re-plots the same data as
delays versus flows (which is the form in which it is applied in assignment
models).
Further advice is provided to assist in converting curves into a form suitable for
SATURN in the following section.
The equivalent SATURN parameters for the curves illustrated above (with
various assumptions on the other COBA parameters required) are shown below.
S0 S1 S2 F C N Description
111.8 104.6 81.4 4410 6990 2.80 D3M
Note: speeds S 0 , S 1 and S 2 in km/h whilst breakpoint F and capacity flow C are in pcus/h
5120257 / Apr 15 15-23

Section 15
Figure 15.2 –COBA11 Piece-Wise v SATURN Power-Based Speed-Flow Curve (15% HGV)
Figure 15.3 – SATURN Dual 3-Lane Motorway Flow-Delay Curve
15.9.4 Conversion of existing speed-flow curves into SATURN

Extreme care should be exercised when speed-flow curves which have been
developed in a different context are “translated” into SATURN speed-flow curves.
We note, in particular, problems which have arisen in using COBA-10 curves,
5120257 / Apr 15 15-24

Section 15
whose basic application is within an economic evaluation package, not within an

assignment model.
Certain of these problems apply more to the use of link capacity-restraint curves
within the simulation network (6.4.12 and 8.4.4); most apply to both simulation and
buffer networks equally.
The first concerns the question as to whether or not the recommended “capacity”
for a link A-B takes into account the existence of (a) intermediate junctions
between A and B or (b) the junction at B. In a buffer network both (a) and (b)
should be included in the capacity used by SATURN; in a simulation network (a)
should be included but not (b) which is otherwise considered by the simulation of
junction B. The problem is therefore one of either double-counting or “zero-
counting”. See also 6.4.12.1.
The second problem is one of units. If, as in COBA-10, capacities are normally
specified in units of vehicles per hour there may be an assumed percentage of
HGV (or other) vehicles within the “vehicles”. Thus, given a link with a flow of
1,000 vehicles/hr of which 15% are HGVs (150 /hr) for which one would wish to
attribute a PCU factor of 2.0 PCUs/HGV, the equivalent flow in terms of PCUs/hr
would be 1,150.
The third question is what happens to speeds in excess of “capacity”. COBA
curves, for example, may assume that speeds above capacity do not reduce but
continue to be fixed at their capacity speed. SATURN assumes that flows in
excess of capacity lead to linearly increasing queues with a consequent linear
increase in travel time (/reduction in effective speed) as given in equation (5.1b).
Users need to bear this in mind in specifying link capacities (for both simulation
and buffer links).
In all three cases it is the responsibility of the user to decide how and by how
much to compensate for these effects before using these curves within SATURN.
15.9.5 Default Speed-Flow Curves

It is possible to define the speed-flow relationships on buffer links by defining
“default” speed flow curve parameters which apply to all buffer links which have
the same capacity index. To use this option within a network data file input to
SATNET you must:
♦ Define a set of default speed flow records within the ‘33333’ data records,
identified by a ‘D’ in column 1 and with entries for free-flow speed, speed at
capacity, capacity, the power ‘n’ and a (non-zero) capacity index in the
“normal” fixed columns; see 6.6 for the detailed format;
♦ For each buffer link to which the above parameters apply leave blank (or code
as zero) the free-flow speed/time, capacity speed/time, capacity and power
but include the distance and capacity index. The program then substitutes
the default speeds, etc. for the missing records. (In fact it is not even
necessary to code the distance if the SHANDY option is in effect; see 15.10.)
N.B. It is necessary to leave all four of the above entry fields blank/zero; if
one of them is included then it assumed that the other entries of zero are all
valid entries and the default option is not applied.
5120257 / Apr 15 15-25

Section 15
Thus all links with the same capacity index will have an identical speed-flow curve
plus capacity. Note that the actual times need not be identical since these will
depend as well on the distance which is coded separately for each link.
One advantage of this option is that you can make “universal” changes to the
speed-flow parameters for a set of links by simply changing a single record rather
than several. The option should also be extremely useful for networks which are
defined by graphical input in some form; here link distances can be calculated
from node co-ordinates so that the only input information required from the user
(apart from whether a link is one-way or two-way) is an index which determines
the remaining parameters.
An example of an input data file using these conventions is illustrated below
where “default” indices 1 to 14 are equivalent to the “typical” DfT parameters
defined above. Thus link 6-7 has a length of 90 metres but a capacity of 1400, a
free-flow speed of 63 kph, etc. as taken from the previous “D” record for capacity
index 4.
33333
D 90 76 5200 5.9 1
D 79 70 4800 5.2 2
D 70 57 1800 1.7 3
D 63 55 1400 1.9 4
D 50 50 600 0.0 5
D 80 66 4800 6.3 6
D 65 56 4400 4.7 7
D 50 30 2200 4.2 8
D 45 25 1000 3.9 9
D 35 25 600 4.4 10
D 25 15 500 3.8 11
D 67 47 4000 1.2 12
D 61 27 3400 1.7 13
D 56 20 1800 1.9 14
....
6 7 90 4
Further Notes:
1) The “D” records can appear anywhere within the 33333 records and can be
applied to buffer links that precede them.
2) By default (see note 4) below) the five required input data fields (free-flow
speed, speed at capacity, capacity, the power ‘n’ and capacity index) must
appear within the same fixed columns as “normal” buffer links; e.g., the free-
flow speed in columns 11-15. But, N.B., note that the required columns differ
under DUTCH = T; see 15.20.
3) Note that unlike standard buffer records where either speeds or times may be
used, the default speed-flow curves are only based on speeds. It is assumed
therefore that buffer records which make use of speed-flow curves have an ‘S’
in column 29 (39 under DUTCH = T).
4) Problems associated with fixed columns and differences between DUTCH = T
or F may be eliminated by setting a parameter DCSV = T under &PARAM in
the network .dat file, in which case the 5 necessary fields may appear in free
format following the D in column 1. I.e., they must appear in the correct order
and be separated by either spaces and/or commas.
5120257 / Apr 15 15-26

Section 15
3) It is quite possible that users would wish to set up curves with characteristics
identical except for the link capacity to represent say, dual 2 and dual 3 roads
with identical speeds, in which case distinct capacity indices should be used
for different lanes. The requirement for link rather than lane capacities should
be noted.
4) D records are good candidates for inclusion under $INCLUDE, see 15.30,
such that a standard set of default speed flow curves may be recorded in a
single file and applied to a wide range of networks.
5) Default speed-flow curves may also be applied to simulation links where
record 2B (see 6.4.1) excludes any time/speed and capacity data but refers
instead to a capacity index which, as with buffer links, defines the link speed-
flow curve.
15.9.6 Default Speed-Flow Curves: COBA-10 Formats

An option added in release 10.7 permits default speed-flow curves to be defined
directly in terms of COBA-10 speeds and flows such that the best-fit value of the
power n is calculated by SATNET rather than being input directly by the user.
To invoke this option the default speed-flow records must be altered as follows:
a) Write ‘ COBA’ in cols. 36-40 (in place of N) (46-50 under DUTCH = T)
b) Write the speed at the “breakpoint” S 1 in cols. 46-50 (56-60 under DUTCH =
T)
c) Write the breakpoint flow F in cols. 51-55 (61-65 under DUTCH = T)
The calculation of n then follows the equations as given in 15.9.3 where the
additional parameters S 0 , S 2 and C as given within the “normal” 33333 fields; see
6.6.
For the time being the option to directly calculate n from COBA-10 curves only
applies to Default speed-flow curves within the 33333 data records, not to
individual link records. However, there is no reason why it should not be extended
to individual records and, if no problems arise with the above method, it will no
doubt be included in the next release.
15.10 The use of Crow-Fly Distances (The SHANDY Option)

The SHANDY option (set SHANDY = .TRUE. in the input network .dat file) carries
out the following two steps for every input distance for either a simulation or a
buffer link:
♦ If a positive value has been input it checks this against the crow-fly distance
calculated from the input XY co-ordinates and prints a warning message
(WARNING 35) if they differ by more than 10 metres in absolute terms AND
by more than 5% in relative terms.
5120257 / Apr 15 15-27

Section 15
♦ If a zero (or blank) value has been input it substitutes the crow-fly distance
calculated from the input XY co-ordinates and prints a warning message
(WARNING 25).
Clearly these steps are only carried out for links where both the A-node and the B-
node have been correctly assigned X,Y co-ordinates.
The option works by “pre-reading” the co-ordinate data under the 55555 cards
before returning to read the simulation and/or buffer link records. Thus no
“interpolated” co-ordinates are available at this stage. If there are no co-ordinates
input then the option is cancelled.
In addition, if a GIS file is defined in the network data file (via FILGIS) and that file
contains curved link data under 77777 then the crow-fly distances as used to
compare against input link distances (SHANDY = T) are calculated point-by-point
along the curved links rather than end-to-end directly. See Appendix Z.
Note that this option may be usefully combined with the default speed-flow curve
facility described in Section 15.9.5 since the new distance is set BEFORE the
speeds are substituted. Thus the free-flow time is obtained from a crow-fly
distance divided by the free-flow speed. At a minimum therefore a buffer link
record need only contain an A-node, B-node and a capacity index.
It is also an integral part of the PMAKE network building options (see section 17)
when new links are created.
A summary table comparing actual and crow-fly distances is included near the
end of the line printer output file from SATNET.
15.10.2 Correcting XYUNIT

In addition an estimate is made of the “correct” value of XYUNIT by comparing
crow-fly distances as calculated from the node co-ordinates with the input
distances on the .dat file and printed near the end of the .lpn file. If, for example,
the crow-fly distances are consistently around 10 times shorter than the coded
distances then it is presumed that XYUNIT should be 10 times greater.
15.10.3 CROWCC: Zero Distance Buffer Centroid Connectors

The above rule for replacing an input buffer distance of zero by the crow-fly value
traditionally applied to both real buffer links and buffer centroid connectors.
However, while it may make sense to have a positive distance for “real” links, it
may be quite legitimate to have centroid connectors which are purely nominal and
therefore have zero distance (plus, presumably, zero time).
An option introduced in version 10.7 allows users the choice as to whether or not
buffer centroid connectors may be assigned a distance of zero. Thus, if CROWCC
= T (set in &PARAM of a network .dat file) and SHANDY = T a crow-fly distance
replaces buffer centroid connectors with an input value of zero. If CROWCC = F
an input distance of zero is accepted.
For most users CROWCC = F is likely to be the preferred option. However, the
default option prior to 10.7 was effectively T so, for upwards compatibility, the
5120257 / Apr 15 15-28

Section 15
default value of CROWCC was set to T at that point in time. Subsequently,

release 10.9, the default was changed to F.
We further note that setting CROWCC = T may have certain potentially negative
consequences for running SATTUBA; see 15.41.5.
15.11 Coding Combined Buffer and Simulation Networks

Problems may arise in coding a network which includes both a simulation and a
buffer network, in particular at the interface between the two. The following points
may help.
1) The simulation network is coded in the normal way with external nodes
defined at the edge of the network - either “explicitly” within the 11111 data
records or “implicitly” via AUTOX. If the external nodes represent “cordon” or
“stub” nodes where the network terminates then they would normally be
connected to “cordon” zones, i.e., zones representing all trips entering or
leaving the network at these points. These zones should then be included
within the 22222 data records (or implicitly via AUTOZ). The precise points of
zonal connection will be at the external nodes as described in 16.6.2.
(Alternatively the external connection to the zone may be made via an
external simulation link plus an isolated buffer node which is coded under the
33333 data records as described in 16.6.3. However this method is generally
not recommended as it leads, inter alia, to the same problems with U-turns as
described in Section 16.6.4 and 18.9.2.)
However, external simulation nodes may also represent points where the
simulation network connects continuously into the buffer network and, in this
situation, origin/destination zones at the boundary may be connected either
via the buffer or the simulation network. However, in the latter case, the effect
may not be what was desired.
For example, consider the following schematic network where E represents
both an external simulation node and a node which is part of the buffer
network, S is an internal simulation node and B represents one or more nodes
in the buffer network connected to E.
B -------------- E -------------- S
Let Z be a zone that is connected only via a 22222 record to the (two-way)
simulation link E-S and not at all via a 33333 buffer record. In this case trips
from the (origin) zone Z can only enter the network at E in the direction E-S
and, similarly, exit to the (destination) zone Z at E having come from S. They
cannot go directly to / come directly from B.
By contrast, if Z were connected to E as a 33333 buffer centroid connector,
then the origin trips would enter at E and have an immediate choice between
both B and S. Equally, the destination trips to Z would exit from E having
come from either B or S In general terms the latter is probably what the
user would prefer, in which case it is therefore better to define the centroid
connector from Z as a buffer connection to E rather than as a simulation
connection to E-S; i.e., it should be included within the ‘33333’ cards rather
than the ‘22222’ cards described in 6.5 and 6.6.
5120257 / Apr 15 15-29

Section 15
2) The external simulation nodes must also be included in the buffer network
with their “buffer-only” connections - i.e., those links to or from other nodes in
the buffer network. Thus links such as E-B above would be included under
33333.
3) In constructing the joint buffer/simulation network SATNET ignores an input
buffer link if either of the nodes has already been defined in the simulation
network unless both are external simulation nodes. This means that a user
progressively re-defining a section of a large network as a simulation network
does not need to remove simulation links from the buffer network input.
However some care needs to be exercised here that all “inner” nodes have
indeed be defined as simulation nodes since otherwise spurious buffer links
may creep into the middle of the simulation network.
4) On the other hand the “data” on an ignored buffer link, e.g., the time and
distance, is not totally ignored in that it is compared to the comparable
simulation data in order to check for self-consistency. In addition the buffer
link data may be used to supplement the simulation data as explained further
in Sections 6.6, 15.13 and 15.14.
5) We also note that problems may occur due to U-turns from the simulation
network at the simulation/buffer boundary as described in detail in Section
18.9.
15.12 Automatic Network Coding (The AUTOX and AUTOZ Options)

The AUTOX and AUTOZ options are essentially labour-saving devices which
remove the necessity for the user to code external simulation nodes explicitly or to
code zones at external simulation nodes which are cordon points.
Under AUTOX all nodes defined as simulation A-nodes (i.e., in cols. 5-10 of Card
Type 2 (see Section 6.4) but not explicitly defined as simulation nodes themselves
are automatically assumed to be external simulation nodes. Thus if node 99 were
defined as an A-node as part of the definition of node 22 and not defined
elsewhere then node 99 would be added as an external node with node 22 as an
A-node (as well as being connected to any other nodes where it was included as
an A-node).
The properties of the link from 22 to 99 are inferred from data coded for 22; thus
the travel time and distance are the same as those coded for link 99 - 22 (but with
default values of 100 metres and 7 seconds if 99-22 had zero capacity), while if
none of the turning movements coded at node 22 were into link 22-99 it is
assumed that the direction 22-99 does not exist. If however link 22-99 were
included as part of the buffer network definition (Section 6-6) then its time and
distance as coded there will be used in preference to any default values as
described above.
Alternatively, since release 11.3.2, if default values are required (i.e., the 100
metres and 7 seconds, as above) and SHANDY = T then the default distance is
calculated as the crow-fly distance and the time is calculated assuming a default
cruise speed of 51.42 KPH (32 mph).
It should be stressed that the AUTOX option can be somewhat dangerous to use
in that punching errors may go undetected and lead to extra external nodes being
5120257 / Apr 15 15-30

Section 15
erroneously added. Its use is recommended for very simple networks, for
example a network consisting of a single simulation node connected to ‘n’ un-
coded external nodes, set up to simulate an n-way junction in isolation, an
example of which is given below, or for networks set up from recoding existing
buffer networks or when coding using PMAKE (Section 18).
The AUTOZ option removes the need to explicitly define simulation centroid
connectors (6.5) to external simulation nodes by automatically attaching centroid
connectors to every link terminating at an external simulation node and assuming
that the zone has the same number as the external node. Thus, in the above
example where node 99 is an external node connected to internal simulation node
22, a zone numbered 99 would be created, attached to link 99-22 at node 99 in
exactly the same way as if a record ‘99 99 22’ were included in the ‘22222 data’
as described under Section 6.5. When using AUTOZ all connections as defined
under 22222 should be internal connections, otherwise there will be duplication,
and AUTOZ should only be invoked when ALL external nodes are pure cordon
points, not when they are links between the simulation and buffer networks. In
effect this restricts the AUTOZ option to pure simulation networks without a buffer
network.
AUTOX and AUTOZ can both be selected at the same time - and in fact the most
useful case for applying both is the case of coding a single simulation junction as
they remove the need to code ANY external simulation nodes or zones. An
example of coding a 4-way junction, node 44 (as illustrated in Section 16.1), is
given in full below. The coding implies that nodes 43, 55, 45 and 16 are external
nodes, each one of which is connected to an external zone, also numbered 43,
55, 45 and 16.
Note that the AUTOX option infers that the link 44-43 does not exist (i.e., is one-
way from 43 to 44) since there are no turns coded as entering it, and that the time
and distance on link 44-45 will be 7 seconds and 100 metres. Equally under
AUTOZ zone 43 is entry (or origin) only while zone 45 is exit (or destination) only.
&OPTION
&END
NODE 44 CODED ALL ITS OWN
&PARAM
AUTOX=T,
AUTOZ=T,
&END
11111
44 4 3 4 61 85 0 45
45 0 0 0
16 2 25 200 0 1700 1 1 1600X 2 2
5120257 / Apr 15 15-31

Section 15
43 2 40 300 1400 1 1 3000 1 2 1200 2 2

55 2 25 220 1400 1 1 2800 1 2
19 4 6 43 55 43 45 43 16
10 7 4 43 55 16 45
25 0 4 16 55 55 0
15 5 4 16 55 55 45
99999
99999
15.13 Supplementary Data for Simulation Links Using Buffer Network Inputs
In general all the necessary data for links in the simulation network is defined
within the ‘11111 data cards’ described in 6.4; e.g., the link travel time, link
distance and number of lanes. It is however possible to use the ‘33333 data
cards’ to define extra simulation link data which is not required by the simulation
proper but which might be useful under other circumstances. One example of this
is the link capacity index which is used to distinguish certain “classes” of links in
summary statistics. If a link A-B is included in the buffer network data with a
capacity index of, say, 5 but was previously defined as a simulation link, the
capacity index of 5 is assumed to apply as well to the simulation link A-B. Using
the BEAKER option - see 6.3.1 - the index may also be associated with turns out
of A-B; setting BEAKER to .TRUE. is highly recommended.
Similarly any extra “KNOBS” data defined for duplicates of simulation links are
also assumed to apply to those links. See Section 15.14.
A further important application concerns “external simulation links”, i.e., the
simulation link from an internal simulation node A to an external simulation node
B. By definition the travel time on the “in-bound” link B-A is fixed, being a
simulation link, with - in effect - infinite capacity; any additional delays or capacity
restraint on that link are associated with turning movements at A. On the other
hand assuming a fixed travel time and infinite capacity on the “out-bound”
direction A-B would not be entirely realistic since turning movements at B are not
included in the simulation.
It is thus possible to define flow-delay/capacity-restraint relationships on out-
bound external simulation links such as A-B above using exactly the same form of
link flow-delay curve as is applied to buffer links - see Section 5.4. In order to do
so the user must include A-B within the “33333 data cards”.
Note that for external links connected directly to cordon zones there is perhaps
not much point in worrying about flow-delay since all trips go to the external zone
regardless of conditions on the link. However the effect can be important on
external links between the simulation and buffer networks, as otherwise it could
lead to a situation where there is (effective) capacity restraint in the simulation
network and in the buffer network but not at their interface.
In addition if the AUTOX option is used to define external simulation nodes and
links - see 15.12 - and the link in question is 1-way outbound (A to B in the above
example) so that times and distances are given default values then these default
values are over-ridden by any data defined under the 33333 records.
5120257 / Apr 15 15-32

Section 15
15.14 Extra Link Data (Knobs)
15.14.1 Introduction to Knobs

SATURN allows a variable number of additional data items - referred to as
“knobs” - to be input for each link (buffer or simulation) using the ‘33333’ data
records (Section 6.6) and/or separate input files to SATNET. The data is then
stored on the SATURN UF files and may, for example, be later displayed using
SATDB for alpha-numeric output or P1X for graphical output.
Knobs, particularly post SATURN 10.3, have a number of possible applications.
Thus they may be used as components of generalised costs, in particular as tolls,
or they may be used to define extra travel times or delays to bus services (15.44).
These applications are described below.
Alternatively they may be used to store network data which has no direct impact
on traffic assignment, in which case SATURN is being used primarily as a network
data base - described next.
15.14.2 Data-Base Applications

There are many possible applications of such a data-base. For example one
might store the date at which a link was last re-surfaced and thereby produce
plots of all links re-surfaced in a given year or range of years using the SELECT
facility in P1X; equally one might store accident statistics for links. Indeed it is now
quite feasible to use SATURN purely as a network data-base by simply building a
network in which all the “standard” link variables such as time, etc. are ignored
and concentrating only on the “extra” data items. From the network build program
SATNET one could go directly to the display programs SATDB and P1X.
Once input certain basic algebraic manipulations may also be performed on the
data using SATDB. For example, if you input accident statistics and calculate link
flows you could then calculate and analyse accidents per vehicle.
It is hoped that this facility will encourage other types of SATURN users apart
from traffic engineers. For example it might allow identical networks to be used
for traffic analysis and the analysis of accidents rather, as often seems to be the
case with Local Authorities, for two different groups to set up different networks for
the same area.
15.14.3 Using Knobs within Generalised Costs

Section 7.11.2 and equation (7.43) describe how the generalised cost of travel as
used for traffic assignment may be defined as a linear combination of time,
distance and one or more knob data sets. The relative weights are set by PPM,
PPK and knob-specific weights specified within the 88888 record set (6.11)
As noted in 7.11.2 SATURN makes no further assumption as to what these extra
costs are really representing. They might, for example, represent nominal time
penalties in units of seconds associated with following a non-signposted route.
However the nominal charges will not be included in network statistics of total pcu-
hrs.
5120257 / Apr 15 15-33

Section 15
Note that it is possible to have negative values for Knobs data which contribute to
generalised cost but only if the total link fixed cost does not go negative. See
7.11.2. Negative Knobs values should be used with caution although they may
sometimes be useful, for example, to make certain links more attractive to traffic.
The weighting coefficient for KNOBS data defined within the 88888 data set (6.11)
is defined in the “normal” way as a positive number; i.e., it is not possible to create
a negative cost by having positive data with a negative weight.
Note that items of Knobs data which do not contribute to link generalised costs
(e,g., for applications as described in 15.14.2) should have their 88888 weights
input as zero (or blank) to avoid being confused with, e.g., tolls.
15.14.4 Using Knobs to Set Tolls (Road Charges)

A particular example of a knob field used to define generalised cost is when the
field directly represents monetary charges - tolls. As noted in section 6.11 tolls
are indicated by including either a $ or & symbol in the relevant columns of the
88888 records for that field. If the remaining columns are blank then the
assumption is that the knob entry is the “true” charge per link in units of pence but
if a numerical factor (apart from 1.0) is also included then the knob entry is
factored by that amount. This allows the user to define tolls in purely nominal
units, say 1.0 for all links, and then let the 88888 records define the specific toll.
In addition knobs which are explicitly defined as tolls, as opposed to the less well
specified effects under 15.14.12, are included in the output network statistics from
the assignment which report the total revenue generated by tolls in the same way
that total pcu-hrs and total pcu-kms are reported.
For further details as to how tolls are handled within SATURN please see Section
20.3.
15.14.5 Creating Knobs Data

In order to use this facility the user must first define the number of data items to be
input, the &PARAM namelist parameter KNOBS. Secondly, the link data itself
must be input to SATNET and that in turn may be in one of three forms:
1) as an additional second record for each buffer link with the required number of
data fields up to a maximum of 8; see Section 6.6.
2) as added data items at the end of the first (and only) buffer link data records;
3) as a separate free-standing input file (FILKNB).
Option 3), an external ascii file, is highly recommended for ease of use and for
avoiding possible errors.
The parameter KONAL (Knobs ON A Line) distinguishes between (i) and (ii):
KONAL = F and T respectively. Option (iii) is only used if a file is nominated by the
character variable FILKNB (or KNBFIL). If FILKNB is set it is assumed that no
Knobs data appears in the network .dat file itself (and KONAL is irrelevant).
Note that under (i) the extra record may be entirely blank, in which case it is read
as a string of zeros. See 15.29. Equally blank inputs under (ii) are also interpreted
as zero’s.
5120257 / Apr 15 15-34

Section 15
15.14.5.1 External KNOBS data files (FILKNB)

The designated file FILKNB (normally) has a standard SATURN format (e.g., as
for input counts, section 6.10) where each record contains the link/turn
identification in fixed column formats in columns 1-15 (1-30 under DUTCH)
followed by the knobs data for that link in, essentially, free format, e.g., comma
separated.
However, post release 11.2.4, the data records in a KNOBS file may be entirely
free format (e.g., CSV) by setting an &PARAM parameter FREEKN = T in the
network .dat file. In this case the link/turn numbers A, B and/or C do not need to
be in fixed columns but free format. Note that a third node C must always be
explicitly included for links either as 0 or, in the case of CSV by “’,,’”
15.14.5.2 KNOBS Data on Centroid Connectors

There is an important distinction between data input “internally” under options (i)
and (ii) above and “externally” under (iii). That is that the internal 33333 data may
only be defined for road links (whether in the simulation or buffer networks) plus
buffer simulation connectors whereas data input in an external file may also be
defined for all components within the SATURN assignment networks, e.g., turns
(by including 3 nodes) and simulation centroid connectors as well (defined by
including a ‘C’ in columns 1, 6 or 11 to identify the zone (columns 1, 11 or 21
under DUTCH)).
Thus to define an outbound centroid connector from a zone Z to node A – where
A is either a buffer node or an external simulation node – enter Z in columns 2-5
with a C in column 1 and A in columns 6-10. Reverse the two fields for an inbound
centroid connector.
Note that, post 11.1, the requirement to identify zones by a C in an appropriate
column may be relaxed by the use of NO333C = T whereby any input node
number which is less than or equal MAXZN is assumed to be a zone whether or
not a C has been included. This should make it easier to create KNOB files using
external packages – but clearly may create problems if zone and node numbers
overlap.
Centroid connectors to/from internal simulation links are more complicated and
users are advised to consider using Wildcard entries as described below which
only require the zone name (plus C) in an appropriate field. Otherwise, to define
an outbound centroid connector from Z to link (A,B), enter C+Z in columns 1-5, A
in columns 6-10 and B in columns 11-15. For an inbound centroid connector from
(A,B) to Z enter A in columns 1-5, B in columns 6-10 and C+Z in columns 11-15.
Post 10.9.5 the above rule has been relaxed so that an outbound centroid
connector from zone Z to link (A,B) may be defined by entering Z in columns 1-5
and B only in columns 6-10. This, after all, is how the centroid connector appears
on the network plots: a dashed line from Z to B. If there is then only one possible
link A,B which is so connected the value of A is inferred. However if there are
multiple centroid connectors between Z and B the method fails.
Similarly a two field entry A Z will correctly identify a (single) simulation centroid
connector from A to Z with the extra node B inferred.
5120257 / Apr 15 15-35

Section 15
Sound complicated? Stick to wildcard definitions!
15.14.5.3 Wildcard Inputs

In addition KNOBS data read from an external KNOBS file (FILKNB) may (post
10.8) define links using a “wildcard” principle whereby, if an A-node/zone is
defined but the B-node columns are left blank (or zero), then the program
assumes that the KNOBS data applies to all links out of the A-node/zone.
Similarly, if the A-node entry is blank (or zero) but the B-node is defined it applies
the data to all entry links.
In particular this facility is designed to enable users to set entry/exit tolls on zones
without having to precisely specify each individual centroid connector to or from a
zone. The wildcard principle applies to all forms of zones and centroid connectors,
i.e., not only zones connected to buffer nodes but also zones which are connected
to internal simulation links for which more explicit data inputs (see above) are
easy to get wrong.
Note the wildcard principle may also be used to define all entries/exits from a
buffer node although not from a simulation node.
In all three cases if data is not set for a particular assignment link that value
defaults to zero. Thus, in the case of a separate file, not all links need to be
included; missing links default to zero.
Note that if a link A-B is included in the 33333 buffer records but has already been
coded as part of the simulation network it will be ignored as a buffer link but the
‘KNOBS’ pieces of extra data will be associated with the simulation link. In this
respect the capacity index input in columns 43-45 is equivalent to extra data since
it too is associated with simulation links.
15.14.6 Storing Knobs: Dirck Access Codes

Once processed by SATNET (via whichever format) each “Knob” is stored on the
output .ufn file with Dirck Access Codes (Section 15.21): 2303 for the first data
field, 2313 for the second, etc. The data thus created may then be displayed using
either P1X or SATDB by referring to those DA codes
15.14.7 Transferring Internal Knobs Data to an External File

As noted earlier (15.14.5) we strongly recommend that KNOBS data be input via
an external ascii file “KNBFIL” rather than internally under the 33333 data. In order
to assist users who have data stored internally to transfer the data to an external
file two useful facilities are provided post 10.8.16.
Firstly, a procedure knobdump.bat, based on SATDB, has been created in order
to dump existing KNOBS data within a .UFS file (independent of how that data
was originally input) into an output ascii file with the correct format for re-input as a
KNBFIL.
Secondly, an option has been included within P1X Network Editing to delete all
existing “second line” KNOBS data from the 33333 data segment.
Thus, by following both the above processes and adding a reference to KNBFIL
within &PARAM, the KNOBS data is effectively transferred into a new format.
5120257 / Apr 15 15-36

Section 15
Note that if the data was originally stored at the end of every buffer record
(KONAL= T, method 2) in 15.14.5) it is not strictly necessary to delete it from the
33333 data since, if KNBFIL is set, the “end of line” buffer data will never be
processed.
15.15 Node-Dependent Parameters: GAP, GAPM, NUC and LCY

As explained in Section 6.4.1 there are four parameters - GAP, GAPM, NUC and
LCY - which can be set individually for nodes as opposed to using global default
values using data values input on the node record.
15.15.1 GAP and GAPM

GAP and GAPM require little further explanation; they should be used when it is
felt that due to the specific physical lay-out of an intersection, gap acceptance is
either easier or more difficult than at an “average” intersection. (Node graphics
editing within P1X may be used to help determine appropriate values.) See also
Section 15.22.
We also repeat the warning in Section 15.22 that the default values of both GAP
and GAPM are probably highly unrealistic and should be changed, if not on a
global basis than certainly on a node-by-node basis.
15.15.2 NUC
Different values of NUC should be used if it is desired to have greater or less
resolution of cyclical flow profiles at a particular junction. For example, if the entry
profiles to a roundabout are virtually flat there is no particular reason to divide the
cycle period into a large number of small time units which will be virtually identical
to each other. Here a small value of NUC gives the same results at less
computing cost. On the other hand traffic signals with a large number of relatively
short stages benefit from the extra resolution of short time units, i.e., a large value
of NUC.
Traditionally, and as a very general rule in SATURN, our advice has always been
to stick to the global values unless there is a very good reason for changing NUC
locally. However, post 2007, the benefits of increasing NUC under certain fairly
specific local circumstances have become better recognised and extra parameters
have been introduced in 10.8 to help deal with these issues.
In particular using larger values of NUC at complex signalised junctions may have
benefits for improved convergence.
Thus, for example, with X-turners at traffic signals which are partially blocked by
opposing traffic during a green phase, it is important for the simulation to be able
to accurately estimate the point during the phase at which gaps begin to appear in
the opposing traffic and the X-turns can begin to clear (albeit possibly very slowly).
This is particularly so if the green phase is relatively short compared to a time unit
and/or the lane is shared.
For example, if NUC is small and the basic time unit is, say, 15 seconds and the
duration of a blocked phase is only 10 seconds then the simulated results may
differ if the phase is entirely contained within a single 15-second time unit or if it
overlaps two time units. (N.B. The differences between the two may not look that
5120257 / Apr 15 15-37

Section 15
large in some respects but they may not be negligible either. For example if the
calculated delays were 40 and 45 seconds the “error” of 5 seconds may be small
compared to the differences between modelled and observed times; on the other
hand a sudden jump of 5 seconds may be relatively very important in terms of
convergence between simulation and assignment.)
Thus, for signals with X-turns, we now recommend that NUC should be large
enough so that the minimum-length stage time is greater than three time units.
E.g., if LCY = 100 seconds and the shortest stage time is 7 seconds then NUC
should be at least 43 (i.e. the basic time unit should be 7 / 3 seconds or 2.33
seconds and with LCY of 100, the value of NUC set should be equal to 100 / 2.33
or 43 rounded to the nearest integer).
Indeed, there is a strong case for setting NUC = LCY at signalised junctions with
X-turns so that the time unit corresponds to 1 second in order to achieve
maximum “resolution” and every stage transition occurs at an “integer” time unit;
see point 3) below under AUTNUC.
In versions of SATURN prior to 10.8 there was an upper limit of 25 on the value of
NUC both globally and at individual junctions; in 10.8 this has been increased to
125 for individual junctions or for junction types (i.e., NUCJT()) but the maximum
of 25 is still retained as the global default value. Other relevant changes in 10.8
include:
1) Warning 94 and/or Serious Warning 153 have been introduced to detect
values of NUC per node which are judged to be too small / seriously too
small.
2) A subscripted parameter NUCJT(j), j = 1,5, has been added to set a default
value of NUC for all simulation junctions of type j. NUC continues to function
as a global default which may be over-ridden by NUCJT for specific node
types.
3) If AUTNUC = T then, in processing a network .dat file, SATNET will
automatically choose an “optimum” value of NUC per node if the default value
is judged to be too low (up to the above-mentioned maximum of 125). Thus,
in extremis, AUTNUC will set NUC equal to the cycle time for that junction so
that one time unit equals one second.
N.B. Increasing NUC for all nodes may lead to problems with array dimensions
being exceeded and, indeed, this is one reason why in the past users may have
been forced to reduce NUC from the (former) default value of 15 down to, say, 10.
Indeed, post 11.1, the default value has been decreased to 10. There may
therefore be a strong case for using NUCJT to selectively set relatively low values
of NUC for, say, roundabouts and priority junctions (NUCJT(1) = NUCJT(3) = 5)
where resolution is not an issue but larger values for signals (NUCJT(3) = 25)
such that the overall space requirements are not increased.
Equally increased NUC values also increases the CPU time required to carry out
a simulation although, generally, this does not lead to significant increases in
overall run times since, particularly in large networks, it is the assignment that
takes up almost all the CPU time.
5120257 / Apr 15 15-38

Section 15
We may further note – see also the final paragraph in 15.15.3 - that having
different values of NUC at two adjacent junctions has no real effect on the transfer
of cyclic flow profiles between them since CFP profiles will be suitably
transformed.
Final thought: Low NUC values do not necessarily lead to “errors” in the
simulation; what they do do though is to introduce a certain level of “clunkiness”
into the simulation which may be counter-productive in terms of convergence.
Increasing NUC values in an existing validated network is unlikely to change it into
a non-validated network but it may improve convergence and it may produce
noticeable changes at a small number of turns.
15.15.3 LCY – Cycle time

The choice of LCY can however be more important. If all signals in the network
operate on the same cycle length then life is simple - all junctions should be
simulated using that cycle time and there is no need for any changes from the
default LCY. If however different signals operate on different cycle times then,
generally speaking, LCY at signals should be set to the local cycle time. Before
considering non-signals let us consider the effect of different cycle times.
If A and B are adjacent junctions with equal values of LCY then the OUT cyclical
flow profiles at A become the IN profile for link A-B and any “structure” in the
profiles is carried forward from A to B. This enables the effect of signal co-
ordination between A and B to be modelled. If on the other hand A and B were
both signals but on different cycles it follows that at certain times they would be “in
phase” and at other times “out of phase”. Rather than trying to model the whole
range of possibilities SATURN tries to model the “average” behaviour by
assuming that if A and B have different values of LCY the A-B IN profile is
perfectly flat regardless of what the OUT profiles were like. Clearly this is not a
perfect modelling assumption but it has the definite advantage of being easy to
implement!
Thus for non-signalised junctions we recommend, as a very general rule of thumb,
that LCY should be set equal to the value of the cycle time at the signalised
junctions which “most” effects conditions at that junction. This may sound vague -
it is intended to be! However most of the time the choice of LCY at non-signalised
intersections is unlikely to significantly affect the results so that if there appear to
be two “important” controlling signals choose one or the other and don‘t worry
about it.
At certain points in the standard node/link output table warnings are given if a
particular link has different values of LCY at its upstream and downstream nodes.
In particular the SATLOOK table of simulation node properties (11.1.1) contains a
line in the link properties which indicates such links. The output is in the form of *’s
where the higher number of *s, the greater the potential impact. Thus blank
implies equal values, * implies unequal with signals at neither end, ** is signals
upstream but not downstream, *** is signals downstream and **** is signals at
both ends. The logic is that profiles and co-ordination are most important at
signals and the number of *s reflects this.
5120257 / Apr 15 15-39

Section 15
In addition release 11.2.4 introduced a new test to detect a simulation node with,
say, LCY = 60 while all its immediate neighbours had LCY = 70. Serious Warning
183.
Note that having different values of NUC at two adjacent junctions has no real
effect on the OUT-IN transformation since an OUT profile evaluated with, say, 10
time units would be suitably expanded into an IN profile with, say, 15 units
provided of course that both junctions have the same LCY.
15.16 Simulation Link Flows and Centroid Connectors
15.16.1 Simulation Zone Connectors

Because of the way in which zones in the simulation network are connected to
links, not nodes, certain ambiguities may arise with respect to the definition of “link
flows”. The various possible definitions are illustrated below for a zone Z which is
connected to an internal simulation link AB. X and Y mark the “imaginary” points
along AB where trips leave and enter Z.
The “flow” on AB may, in theory, be defined in five different ways; i.e., the flow
along:
AX - the entry flow onto the link,
XZ - the exit flow to the centroid,
XY - the “mid-link” flow,
ZY - the entry flow from the centroid, and
YB - the arrival flow at the stop line at B
For uniformity throughout SATURN we assume that the “link flow” is always taken
to be the mid-link flow, i.e. the flow on the link once all traffic destined for the zone
has been removed and before any new traffic has joined from the centroid. Thus
as defined the link flow is probably lower than the flow that might be observed on
the link in reality, although the fact that the link has been connected to a zone
implies that the flow level probably does vary along the link.
This therefore is the definition of link flow as used, e.g., in comparing modelled
and observed flows (see Section 15.6) and is the (default) link flow as annotated
by program P1X. By contrast the “ARRIVE FLOW” or “Downstream Flow” as
printed out by the FLOW-DELAY tables and illustrated in Table 17.1 corresponds
to the stop-line flow, YB above.
5120257 / Apr 15 15-40

Section 15
15.16.2 Simulation Link Exit/Entry and/or Upstream/Downstream Flows

The previous section has described how flow may exit the network at the
upstream end of a simulation link and equally enter the network at the
downstream end of a simulation link using centroid connectors.
It is also possible for flows to exit/enter at either the upstream or the downstream
end of simulation links even if they are not explicitly connected to zones. This
possibility arises with bus routes which may originate/terminate at either end of
simulation links (dependent on UPBUS; see 6.9.2). It may also arise, less
obviously, with either pre-loaded or PASSQ flows (see 15.5 and 17.3.1
respectively) where the rule “flow in equals flow out” may be violated. Thus, in
effect, all simulation links are potentially bridged by exit/entry links, although only
those with explicit centroid connectors are shown as such on, e.g., P1X plots.
Please note that this possible ambiguity ONLY arises with links in the simulation
network and not at all to links in the buffer network where there is only one
possible definition of link flow.
Note as well that the distinction between “demand” and “actual” flows as
described in Section 17.2 also applies to all the different definitions of flows along
a simulation link. Thus the “actual” upstream exit flow on a link may be less than
the “demand” upstream exit flow due to queuing upstream.
15.17 Pcu’s, Cars, Buses and Vehicles

In theory the “units” used to describe traffic flow in SATURN can be anything the
user likes; e.g., the trip matrix can be units of cars, vehicles, pcu’s or whatever.
The only real restriction is that the link saturation flows and the trip matrix
elements must be defined in terms of the same units. In practice however it is
strongly recommended that trips and saturation flows be defined as pcu’s and
“most” printed text assumes this to be the case.
Strictly speaking, and for pure buffer networks, flows do not necessarily even
need to be defined per hour; they could be defined as, e.g., daily flows as long as
all appropriate commodities such as capacities are defined in the same units.
However moving away from hourly rates causes problems for the simulation
where the length of the simulated period LTP may only be defined in minutes and
the definite assumption is that the flows being simulated are hourly flows.
Note that the same rule also applies to all input counted flows (see 6.10 and
13.1.4); i.e., that they should always be in the same units as all other flows with
the presumption being that they are in pcus/hr. Equally it applies to all definitions
of capacities, e.g., as contained in buffer network speed-flow curves.
One partial exception to the above rule is buses where: (a) the network 66666
definitions of bus routes input frequencies (buses/hour) which are then factored by
BUSPCU to give bus flows as pcus/hr, and (b) output bus data is sometimes given
in terms of buses and sometimes, e.g., when giving total bus flows on links, in
terms of pcu’s. Hopefully the text should make it clear what is being printed.
5120257 / Apr 15 15-41

Section 15
In the case of Multiple User Classes – and stacked O-D trip matrices – it is further
assumed that all the various stacked matrix levels will be in the same units and
that their assigned flows may simply be added together.
Clearly it is vital for users, when importing data into SATURN from external
sources, to check the units of the external data and to adjust as necessary. For
example, this applies to the importing of trip matrices (which may be in vehicles/hr
as opposed to PCU/hr), speed-flow curves, etc. etc.
15.17.2 PCU Factors by Vehicle Class

SATURN 10.1 introduced an extra parameter VCPCU (disaggregated directly by
vehicle class and indirectly by user class if necessary; see 5.8) which is used to
convert pcu’s - on the recommended assumption that all trip matrices, capacities
etc. are defined in units of pcu/hr - into vehicles.
VCPCU is useful in circumstances such as vehicle emissions when it is more
natural to deal with parameters per vehicle rather than per pcu. It is also used in
the calculation of toll revenues (see 20.4.1) which are paid by vehicle rather than
by pcu.
Post 10.7 P1X has an option to annotate individual user class link flows in veh/hr
instead of pcus/hr (by factoring the assigned flows by 1/VCPCU). However it is
more difficult to apply the same option to, e.g., total flows where some of its
components, passq flows etc. may not be unambiguously identified with a single
user or vehicle class and hence pcu-factor.
Note that, by default, all VCPCU factors equal 1.0, in which case it has no direct
effect on any SATURN outputs.
15.18 Interpolating Routes

Several programs require that “routes” (e.g., bus routes, joy ride routes, etc.) be
defined as a sequence of consecutive nodes. For long routes this can be
laborious and therefore a simpler method is available if node co-ordinates have
been defined whereby the user defines the first and last nodes and the program
works out the sequence of nodes which most closely approximates to a straight-
line or crow-fly path between the two nodes. The principle can be extended to the
case where a route is defined by more than two nodes, the first and last plus any
intermediate nodes where there is a decided “kink” in the route.
More specifically if we wish to interpolate a path from node A to node Z we first
work out the angle from A to Z, then the angles from A to all its exit nodes B 1 ,
B 2 …. and choose the B-node whose exit angle is nearest to the A-Z angle. The
procedure is then repeated by taking the angle from B to Z and choosing the
“nearest” exit C. Exits more than 90º from the desired direction are excluded; it is
therefore possible for the algorithm to become “stuck” if there are no exits within
90º. In these cases the user will need to define more nodes within the path.
Alternatively, post 10.9, an alternative interpolation algorithm has been introduced
which finds the minimum distance route between A and Z if the first method fails.
This requires that a &PARAM parameter MINDER is set TRUE.
5120257 / Apr 15 15-42

Section 15
Depending on the particular application the interpolated nodes may either only
use “real” links - in the sense that one-way links are only used in one direction - or
non-directional links.
This facility is particularly useful in defining bus routes, not only in terms of
reducing the amount of data to be coded, but also because the route definitions
do not need to be altered if the network is changed so that nodes are inserted
and/or removed from the original network.
Note, however, that in order to use this facility node co-ordinates MUST be
defined (although, strictly speaking, only for those nodes which lie on the
interpolated path).
WARNING: If two successive nodes to be interpolated are some distance from one
another and there are multiple possible routes, interpolation may not necessarily
find your desired route; the solution in this case is to define nodes which are much
nearer together and for which the route to be interpolated is unambiguous.
Currently interpolated routes may be defined within the following programs:
♦ SATNET to define bus routes; See note (5), 6.9.2.
♦ SATCH to define a “spline” of links along which flows are to be cordoned;
♦ P1X to define bus routes, joy rides and GIS alphanumeric link names.
15.19 Select Link Analysis (SLA)

“Select Link Analysis” is a general term which refers to the identification of specific
routes and/or trips assigned to selected links (where in this context “links” may
refer to either “roads” or “turns” or “centroid connectors” or even “nodes”) and the
calculation of various properties associated with those trips. Thus the analysis
may identify, for example:
♦ the O-D pairs which use a particular link;
♦ the fraction of trips from each O-D on a link;
♦ the flows on all other links from the selected trips.

Other forms of analysis are of course feasible. However the central element in
select link analysis is the ability to trace the routes generated during the
assignment process and to select those that satisfy a particular criterion for further
scrutiny. How this is done within SATURN is described in Section 15.23.
Select link analysis is a very powerful tool not only for the analysis of schemes but
also for the validation of a base year network. In many respects it is the converse
of building trees in order to check on an assignment; trees tell you which links are
used by specified O-D pairs; select link analysis tells you which O-D pairs use
selected links.
Within SATURN it is possible to perform select link analysis within several
different programs and with slightly different outputs (although very often the same
information may be obtained from two or more programs). We therefore first
identify the options available:
5120257 / Apr 15 15-43

Section 15
1) SATPIJA may be used to undertake a “PIJA analysis” whereby the fraction of

trips “P” for each “I-J” movement assigned to link “A” is stored during an
assignment. The main purpose of this option is to provide the “PIJA or UFP
file” required by SATME2 and no print facilities are provided within this
program. More than one link or turn can be analysed within a single run.
2) Program SATU2 (13.7) can read a PIJA/UFP file and output a matrix of trips
(as a UFM file) using selected links. MX may then be used to print the trips
(with the option of aggregating zone-to-zone trips into sector-to-sector trips
and printing).
3) Both P1X (11.8.1) and SATDB (11.10.7.5) can repeat the assignments
carried out in the assignment and select trips which either:
a) pass through a selected node,
b) pass through a selected sequence of nodes in order, or
c) pass through one or more of a set of “screen line” links.
Option (b) includes the possibility of either identifying links - by specifying two
adjacent nodes - or turns - by identifying three nodes.
Option (c), further explained in (11.10.7.5), allows both conventional “screen
lines” in the sense of a closed set of links surrounding a town centre or, more
generally, any set of links. The screen lines may be defined either using the
link selection facility (11.6.1) or a set of 7777 input data records (6.10) in both
P1X and SATDB. P1X also offers two additional methods for defining screen
lines – interactively using the mouse or via an external data file (11.8.1.7).
Those trips which satisfy the selection rules are re-loaded and the total
assignment pattern of trips before and after they pass through the selected node
or nodes is displayed, graphically or as a data base table.
P1X and SATDB have further options which duplicate those in SATU2 to either:
♦ output a selected trip matrix UFM file (11.8.1.3);
♦ print a sector-to-sector trip matrix.

Generally speaking P1X is considerably easier to use than SATDB, firstly, through
the use of mouse-based link or node selection and, secondly, since the display of
the selected flows is MUCH easier to appreciate in a graphical format. On the
other hand SATDB may be easier to use in conjunction with key files.
SATU2 has effectively been superseded by P1X and/or SATDB and is less
convenient; its use is not recommended.
So the “best buy” recommendation is to use P1X in the first instance!
Finally we should note the caveat expressed in Section 15.23.2 that under certain
circumstances (e.g., elastic assignment) select link analysis (as with other similar
analyses) is based on an approximation and that the select link flows need not be
entirely consistent with the “true” flows. In these circumstances the select link
results should be viewed as “indicative” rather than exact. The difference statistics
5120257 / Apr 15 15-44

Section 15
generated within SATALL (based on the errors from all links) may be used as a
rough guide to the errors to be expected on any single link analysed.
15.20 The Dutch Option (Long Node Numbers)

The DUTCH option has been introduced to allow nodes with up to 8-digit node
numbers to be defined in buffer networks - so-called because it is common
practice in The Netherlands. The major effect of this option is to change a number
of the input formats so that node numbers in certain circumstances occupy 10
columns of data input as opposed to 5.
Note that simulation nodes are still restricted to 5 digits (although it is
recommended that a maximum of 4 be used so as to keep the formats “neat”).
Equally zone numbers are still effectively limited to a maximum of 5 digits (see
5.1.6).
More specifically formats in the following programs are altered as indicated below:
(A) SATNET - SEE SECTION 6.
(A.1) THE BUFFER NETWORK DATA CARDS-- SEE 6.6

Col. 1 A ‘C’ if the following node refers to a zone.
Cols.2 - 10 The A-node for the link
Col. 11 A ‘C’ to indicate a zone number following.
Cols.12 - 20 The B-node for the link
Cols.21 – 25 The link time (in seconds) or speed (in kph) at free-flow conditions
Cols. 26 - 30 The link time (in seconds) or speed (in kph) at capacity.
Cols. 31 - 35 The one-way link capacity (in pcus per hour)
Col. 38 A one-way/two-way indicator
Col. 39 An ‘S’ if speeds were defined above; otherwise times are assumed.
Cols. 41 - 45 The link distance (in metres).
Cols. 46 - 50 The power to be used in the link flow-delay curve
Cols. 53 – 55 A “link index” in the range 0-999
Cols. 56 – 80 (Optionally) up to KNOBS extra data items
(A.2) The Restricted Turns or Links - See 6.7.

Cols. 21 - 30 The C-node, C (blank or 0 in the case of a link)
Cols. 31 - 35 The ban/penalty indicator for user class 1,
Cols. 36 - 40 Ditto, for user class 2,
Cols. 41 - 45 etc.
5120257 / Apr 15 15-45

Section 15
(A3) NODE AND CO-ORDINATES - SEE 6.8

Cols. 1 A ‘C’ if columns 2 to 10 contain a zone number.
Cols. 2 - 10 The node or zone number.
Cols.11 - 15 Its X co-ordinate
Cols.16 - 20 Its Y co-ordinate
(A4) BUS ROUTES - SEE 6.9

Cols. 2 – 5 The “name” of the route (which must be numeric)
Cols. 6 ‘T’ if the route is two-way and the node order is exactly reversed (in
which case the reverse route need not be coded) ; otherwise leave
blank
Cols. 7 – 10 The route frequency in buses per hour
Cols.11 – 15 The number of nodes through which the route passes (i.e. the
number of node entries following
Cols.16 – 25 The first node on the route
Cols. 26 -35 The second node on the route, etc. up to 6 nodes, column 75
If the route passes through more than 6 nodes the list of nodes is continued on a
second (or even third) record starting in cols. 16 - 25.
N.B. The strict column formats do not apply if EZBUS = T independent of the
value of DUTCH.
(A5) LINK AND/OR TURN COUNTS - SEE 6.10.
Identical changes to (A2) above.
(B) SATPIJA - SEE SECTION 13.2.1.

Link and/or turn counts are specified as under (A.5) and (A.2) above.
Essentially the changes are made anywhere that it is possible that 8-digit buffer
node numbers MIGHT be input, but NOT in those areas where only simulation
node numbers may be used.
15.21 Referencing Data Arrays Via Dirck Access Codes

Certain programs, notably SATDB and P1X, allow the user to select data by
reference to a “Dirck Access Code” as opposed to referring to, say, free-flow
travel time by name (“Dirck Access” is a very egotistical pseudonym for “Direct
Access” which it tries to replicate). The precise details of Dirck Access files are
not important here - the most important point to appreciate is that each data field
5120257 / Apr 15 15-46

Section 15
stored on a SATURN UF file has a code associated with it; free-flow travel time,
for example, is coded as 1803 so that asking for free-flow travel time to be
annotated in P1X causes the program to “read” and annotate record 1803. The
same effect can be obtained by referring to 1803 directly.
Note that the final digit in a DA code indicates what “type” of data is stored. Thus
all “integer” variables are stored in codes ending with a 4 whereas all “real”
numerical data (i.e., numbers which may include a decimal place such as free-
flow travel time above) end with a 3 (e.g., 1803). Post 10.7 real arrays may also
end with an 8 (and, eventually, integer arrays with a 9).
A second point to note is that the coded data arrays refer to either: (a), simulation
links; (b), simulation turns; or (c), assignment network links (which include both (a)
and (b) plus all buffer links) so certain DA codes will not be relevant under certain
circumstances.
The main reason for introducing code numbers is to increase flexibility without a
massive increase in programming effort, particularly since certain data arrays are
optional whereas others are mandatory. Thus free-flow travel times are always
defined whereas the link flows for user class 4 may not be.
A full list of the Dirck Access codes used within a particular network (*UFS etc.)
file may be listed interactively using the auxiliary program DALOOK or partial lists
generated by P1X etc. See also Appendix J for a full list. Each array has a short
title associated with it which specifies its contents; these titles are defined in
SATNET either as default text or as read from an (optional) supplementary file
SATTIT.DAT which also gives very useful general information about how DA
codes are used.
Note that not all DA arrays will necessarily be useful to users, for example the
arrays containing “packed” data will be largely unintelligible (but see 11.10.6).
An explanation of the specific codes relevant to capacities is given in Section
8.9.5 and to times and delays in Section 17.10. See also Appendix J for a full list.
15.21.2 Creating your own DA codes in SATDB

Users may add their own data to .ufs files via SATDB referenced by a DA code of
their choosing (see 11.10.12) but care must be used not to over-write existing
essential DA codes.
This may sometimes lead to problems if the user selects a DA code for output
which is “available” in that particular network but which may be used either in
different “forms” of networks (e.g., simulation networks use arrays that do not
appear in buffer-only networks) or in future versions of SATURN. At the present
moment array codes in the range 3003 to 3293 are never used and will not
(barring acts of God, etc. etc.) be used in the future; they are therefore
recommended as being exclusively “reserved” for use by users.
15.21.3 Extended Dirck Access Codes

In SATURN versions 8.5 and beyond the coding conventions used to identify
Dirck Access arrays were “extended” to cope specifically with the problems
created by more than 10 user classes where, in effect, all available numerical
5120257 / Apr 15 15-47

Section 15
codes were used up. Thus class- specific flows were stored in arrays 3803, 3813,
3823, etc. for user classes 1, 2, 3, etc. up to 3893 for user class 10. 3903
however was reserved for something else so that an 11th user class could not be
accommodated.
The solution adopted was to add class-specific digits BEFORE the basic code so
that with 11 classes the DA flow codes became 3803, 103803, 203803, etc. up to
1103803. The effect was similar to having decimal codes such as 3803.0,
3803.1,3803.2 but retained the basic principle of integer codes.
At the moment such codes are used in networks with more than 10 user classes,
in .UFT files to store data from multiple time periods and, in addition, to extend
header records (e.g. 100104 adds extra data to 104) so that old SATURN UF files
have the same array lengths as the latest one (to ensure upwards compatibility).
15.21.4 DA Codes for Actual User Class Flows

Whereas there are two explicit DA codes used for total demand and total actual
flows (4503 and 4513) flows by user class are only stored by demand. Thus ( see
above) the demand flows for user class 1 are stored in DA code 3803, for user
class 2 in 3813, etc. etc. and there no arrays/DA codes within .ufs files which
directly store actual flows by user class.
However, it is possible, in certain circumstances, to use DA codes 3808, 3818,
etc. to obtain actual flows by user class 1, 2 etc. For example, SATDB will accept
such codes as a link data input definition (11.10.2) and they may also be used
with DBDUMP (15.46). What actually happens, however, if 3808 is requested is
that the actual array read in is 3803 (user class 1 demand flows) but the data is
immediately factored down by the global ratio of actual to demand flows. Thus, the
end effect is the same as though 3808 was explicitly stored in the .ufs file.
DA codes 3808, 3818, etc. etc. may also be used in P1X to create and annotate
data using a DA code but individual user class flows – both demand and actual -
may also be accessed using items in the “Flow” list. Note that, within this list, user
classes 1, 2 and 3 are always explicitly listed along with, if there are more than 3
user classes, a single “designated” user class for which the demand/actual flow
may be obtained. By changing the definition of the “designated” user class within
an Options sub-menu flows for any user class may be obtained, rather than
having to use, say, code 3858 to get UC 6 flows.
15.22 Choice of Gap Parameters

The choice of the parameters GAP, GAPR and GAPM can have a very strong
influence on the capacities and delays given by the SATURN simulation model
and some care should be exercised in their choice. In particular the user may
wish to set parameters such that the SATURN output is similar to that given by
other models, in particular models for isolated junctions such as the TRRL
programs ARCADY, PICADY and OSCADY. By a judicious choice of parameters
this can be achieved.
The role of the gap parameters in setting the capacity of a give-way movement is
explained in Section 8.2.2. In the simplest possible case of a minor arm opposed
by one major arm (e.g., at a T-junction or any arm at a roundabout) the capacity
C m of the minor arm is given by the equation:
5120257 / Apr 15 15-48

Section 15
Equation 15.2
Cm S m (1 − VM S M )
=
GS M
where S m is the saturation flow of the minor arm, V M and S M are the flow and
saturation flow of the major arm and G is the gap value.
Hence C goes from a maximum S m equal to its saturation flow at zero opposing
flows down to zero at V M = S M (or, strictly speaking CAPMIN; see 8.2.3)with a
power defined by G.S Mi . In general TRRL models predict a linear relationship
between C and V M so that in order to reproduce this same form in SATURN it is
necessary to set G = 1/V M , i.e., set the gap parameter GAP to the inverse of the
saturation flow of the controlling arm(s).
Very often the GAP values derived in this way seem small, particularly when
interpreted strictly as a gap in traffic that entry traffic would “accept”. For example
if the controlling saturation flow were 3,600 pcu/hr then GAP should be one
second.
It must however be appreciated that GAP is essentially a parameter fed into a
model. Such models are only approximations to reality and contain a number of
intrinsic errors (“specification errors”) which, to a certain extent, can be corrected
or counter-balanced by changes to the model parameters. For example, the gap
acceptance model in SATURN assumes random (Poisson) cross traffic (ignoring
for the moment cyclical effects) whereas in reality one knows that traffic tends to
come in surges, the effect of this being that the random model tends to under-
estimate capacity. Empirically, if we accept the TRRL relationships as “correct”,
then the best value to choose for GAP is 1/S M .
We may also note that the standard default value of GAP set by SATURN is 5.0
seconds which is almost certainly on the high side, causing the SATURN
simulation to under-estimate capacities. The reasons for choosing 5.0 as a
default in the first place are largely historical and arbitrary. The reasons for not
changing it since are (a) the fact that best values almost certainly vary from one to
another (hence it was made a junction-specific parameter in later versions of
SATURN); and (b) setting the default to a more reasonable value might
discourage users from deciding on more suitable values.
The same principles apply to the choice of GAPR and GAPM; i.e., that they are
first and foremost model parameters which should be interpreted only loosely as
acceptable gaps. However with priority junctions it is difficult to choose a single
value of GAP which makes the dependence on ALL major flows linear since each
major flow may have a different saturation flow.
15.23 Re-constructing Assignment Routes: The SAVEIT Option and UFC

Files

While the most important function of assignment is to obtain estimates of flows on
links it is very often equally important to be able to analyse in detail the O-D
routes used to obtain those flows.
5120257 / Apr 15 15-49

Section 15
Examples of analysis options which make use of O-D routes include:
♦ Building minimum cost routes in SATLOOK, SATDB and P1X.
♦ Repeating full loadings of complete trip matrices in SATDB (11.10.7.4).
♦ Select link assignments in SATDB and/or PIX (15.19).
♦ Cordoning matrices within a sub-network (SATCH, 12.1).
♦ Producing a PIJA file using SATPIJA (13.1.2)
♦ Producing a file of route flows (SATPIG, 12.6)
♦ Turning flows at buffer nodes (15.36).
♦ Producing cost and/or skimmed matrices (15.27)

In order to obtain the route flows necessary to carry out such analyses a
parameter SAVEIT must be set to .TRUE. in the final assignment in SATALL (or
SATEASY), most easily done by declaring it to be .TRUE. (its default) under
&PARAM in the .DAT file input to SATNET.
There are then three different methods by which the O-D route information is
preserved under SAVEIT dependent (mainly) upon the assignment method (MET)
used:
(1) Remembering the costs used on each Frank-Wolfe iteration and their weights
in order to be able to re-construct each individual route by re-building trees
(MET = 0 only);
(2) Explicitly storing flows per individual O-D route (path) (path-based assignment,
MET = 1 only);
(3) Storing a “bush” of splitting factors per individual origin/user class from which
individual O-D route flows may be calculated by a single pass (OBA and/or
Frank-Wolfe with extra steps added).
Methods (2) and (3) are generally considerably faster than method (1) in
terms of route flow analyses but may require extra memory to store the
required data and/or extra CPU to create them in the first place. The following
4 sub-sections, 15.23.2 through 15.23.5, deal exclusively with method (1); the
equivalent information for methods (2) and (3) is given, briefly, in 15.23.6 and,
in more detail, in Sections 21.4 and 22.5.2.
Under method (1), for every assignment iteration within the Frank-Wolfe algorithm
the complete set of link “costs” used to construct minimum cost routes is
preserved in a separate “UFC” binary file. These costs may be used later in order
to re-construct the specific “trees” from each iteration and thereby re-construct the
specific O-D routes from that iteration for further analysis.
The filename convention is that if the main network file produced by SATALL is
net.ufs then the cost file will be net.ufc. In addition the .ufc files record the
“weights” as used by each iteration in the final solution (see 7.1.2)..
5120257 / Apr 15 15-50

Section 15
Not creating a ufc file will not affect the normal analysis or use of the .ufs file,
except clearly, if .ufc does not exist, then none of the above mentioned analyses
may be invoked.
Note that .ufc files etc. are only used under the standard Frank-Wolfe link-based
algorithms (MET = 0; see Section 21).
Under method (3) the route information is stored within a “UFO” binary file; see
15.23.6.
15.23.2 SAVEIT/UFC as an Approximation: The SAVEIT Assignment

Under certain (fairly restricted) conditions the routes and costs stored in .ufc files
under SAVEIT will be identical to those used to carry out the actual assignment
within the assignment-simulation loops:
(1) a buffer network with a fixed trip matrix,
(2) post 10.9, a simulation network where MASL = 1 (i.e., SATALL has only been
through a single assignment and the routes/costs used on that assignment are
retained), or
(3) UFC109 = T and the total number of assignment iterations is relatively small
(see 15.23.3 below).
Otherwise – and very often the above conditions are not satisfied - an extra
“SAVEIT assignment” needs to be carried out by SATALL in order to re-create
route flows and to create the .UFC cost file.
Thus the SAVEIT assignment is a final complete Frank-Wolfe assignment stage
carried out at the end of the simulation-assignment loops using the final set of
speed-flow curves and starting, in effect, with a “blank sheet of paper”; e.g., the
initial all-or-nothing assignment uses free flow costs. The set of iterative costs and
weights stored in the .UFC file and used in the subsequent analyses will be those
derived from the “SAVEIT assignment” as opposed to those from the “true”
assignment. (Specifically under elastic assignment the final assignment uses the
fixed trip matrix generated by the final elastic assignment.)
Almost all options which may be used to “improve” the normal assignment within
the assignment-simulation loops may also be invoked by the SAVEIT assignment
– for example, an aggregated SPIDER network may be used under SAVEIT as
well as the normal assignments to reduce CPU – but there are also certain
“improvements” that are only feasible within SAVEIT. In particular, the “trick” to
eliminate zero-flow links within a SPIDER assignment (see 15.56.5.3) may be
used to great effect within a SAVEIT assignment.
In addition, post release 11.2, a SAVEIT assignment may use an Incremental
Assignment (7.11.12) to initialise Frank-Wolfe Assignment with the objective of
reducing the onset of residual paths. To invoke incremental assignment set the
parameter INKS_S in the network .dat file to, say, 4 to request 4 increments.
Empirical tests to determine whether or not the method is effective are under way
so it should be considered as an experimental option.
While, in principle, the SAVEIT assignment should converge to an identical
solution to the full assignment in practice, due to lack of convergence, etc. it is
5120257 / Apr 15 15-51

Section 15
only an approximation and the flows and assigned routes etc. differ. Although the
higher the level of assignment convergence, the better the approximation will be.
See 15.23.4 for a discussion as to how the parameters NITA_S and UNCRTS
may be set to ensure optimum convergence.
The differences between “true” and SAVEIT assignments can have important
implications for, e.g., skimmed matrices as used for economic evaluation or
variable demand models (see 7.8.6 and 15.27.6), Select Link Analysis (see 15.19)
or PIJA analysis (13.3.12). For example, the total flows on a link generated by a
select link analysis may not exactly equal those generated by the original
assignment.
However, it also needs to be borne in mind, that the “errors” associated with
SAVEIT are just one extra source of “noise” to be added to the non-convergence
errors from SATALL proper (see 2.1 and 9.5). Essentially the SAVEIT assignment
is an approximation to an approximation. Therefore, a “perfect” SAVEIT
assignment is not a guarantee of an “error-free” economic evaluation although it
may help.
15.23.2.1 Comparison Statistics: SAVEIT vrs Original Assignment

In order to assess the consistency of the two different assignments a set of
difference statistics is generated and printed at the end of the SAVEIT assignment
comparing the SAVEIT link flows with the “true” assigned link flows. These
include:
♦ The average GEH difference statistic comparing the as-assigned flows and
the SAVEIT flows;
♦ The mean average absolute difference between the flows (expressed as a

percentage);
♦ The relative standard deviation (%);
♦ The average absolute difference in pcu/hr;
♦ The percentage difference between the total pcu-hrs calculated using the
assigned and SAVEIT flows;
♦ Ditto using distance instead of time;
♦ Ditto using assignment cost instead of time.

The last three statistics (new in 10.6) may be thought of as “weighted” differences
of the link flows, weighted by time, distance or cost.
If the two assignments are self-consistent all the above statistics will equal zero;
larger values imply that the various options listed in 15.23.1 will only generate
approximate answers and the statistics give a quantitative estimate of that
approximation.
The difference statistics are also held in the output .ufs files and may be examined
using the analysis option 8 within SATLOOK and/or under Analysis etc. in P1X
(11.8.4.7).
5120257 / Apr 15 15-52

Section 15
15.23.3 UFC109/UFC111: Alternative UFC files

In order to remove some of the uncertainties associated with SAVEIT
assignments an option has been introduced in release 10.9 to create .UFC files
which reproduce exactly the iterative costs used by Frank-Wolfe and in a more
space-efficient format. It requires that a logical parameter UFC109 is set to
.TRUE. under namelist &PARAM in network .dat files. Thus if UFC109 = T (default
= T) two things happen:
(1) The costs stored are those from the “actual” assignment (see 15.23.3.1);
(2) Times, not costs, are stored under MUC (see 15.23.3.2).
In addition, post release 11.2, the second option is independently controlled by an
alternative parameter UFC111 such that, if UFC111 = T, then times are always
output, not costs, independent of the value of UFC109.
15.23.3.1 UFC109 = T: Storing “True” Frank-Wolfe Iteration Costs

The costs/times are stored as a “rolling summation” of all Frank-Wolfe iterations
over all simulation-assignment loops (up to certain limits – see below) instead of
re-creating the assigned route flows by an extra SAVEIT assignment. Similarly the
“weights” per iteration take into account not only the weights during the
assignment stage itself (see equation 7.2b) but also any averaging between
assignment simulation loops associated with DIDDLE, AUTOK, etc.
This has the benefit that any secondary analysis, e.g., skimming, SATME2 (see
13.3.13), etc. based on routes is exact, not an approximation, since it reproduces
the precise routes used in the full assignment. This therefore reduces (but not
entirely removes) some of the problems associated with, e.g., the uniqueness of
skimmed matrices (see note 6, 15.27.6).
The disbenefit is that there may be many more rolling iterations in total than there
would be in a SAVEIT assignment which means that: (a) the.UFC files are larger
and (b) any secondary analyses take proportionately longer.
However, if the total number of rolling FW iterations becomes too large (greater
than a &PARAM parameter NITA_C, default 256) then we revert to an extra
SAVEIT assignment in any case.
Note that the total number of Frank-Wolfe iterations aggregated over all
assignment-simulation loops depends on the rate of convergence as well as the
values set for MASL and NITA. Thus, if convergence is slow and the maximum
number of loops MASL is used and the maximum number of iterations per loop
are also used, then the total number of iterations equals MASL times NITA.
Therefore, reducing MASL and/or NITA will make it more likely that the option will
be used (although achieving an acceptable level of convergence is certainly a
more important objective). See Section 9.5 for advice on improving convergence
and 9.5.4 on the choice of NITA.
15.23.3.2 UFC109 or UFC111 = T: Storing UFC Link Times under MUC

Under multiple user classes if either UFC109 or UFC111 = T the output .UFC file
stores the sets of link times per iteration as opposed to link (generalised) costs by
5120257 / Apr 15 15-53

Section 15
both iteration and user class. This is possible because the times per iteration are
constant between all user classes on the same Frank-Wolfe iteration; the costs
may differ but only because the fixed costs per user class differ and, since the
fixed costs are fixed throughout (by definition), it is straightforward to construct the
costs per iteration/UC by adding (.UFC stored) times per iteration to fixed costs by
user class.
This means that the .UFC files produced under UFC109/111 will be reduced in
size by a factor of 1/NOMADS with only a very small overhead in reconstructing
costs as required for secondary analysis. However, for a single user class we
continue to store cost and there is no reduction in size.
Note that the default value of UFC111 is T, meaning that, post 11.2, the option to
output times rather than costs is virtually always invoked for MUC UFC files and
indeed UFC111 should only be set to F for test purposes.
15.23.4 NITA_S and UNCRTS: Accuracy of SAVEIT/UFC Assignments

The final SAVEIT assignment which creates the .ufc file and the corresponding
route flows may use a different maximum number of Frank-Wolfe iterations via the
parameter NITA_S. Thus if NITA_S is non-zero it replaces the value of NITA (see
7.1.5) in the final assignment. This option is useful if you have been using a
relatively low value of NITA within the assignment-simulation loops (not a bad idea
with DIDDLE; see 9.5.2) but you want a more representative single final
assignment.
Increasing NITA_S leads to improved convergence of the SAVEIT assignment
and therefore should reduce (but not eliminate) the problems of approximation
referred to above, 15.23.2. Thus the default value of NITA_S is 99 whereas the
default value of NITA is only 20. Users frequently increase NITA_S to even larger
values, e.g., 256.
For similar reasons the value of UNCRTS which also controls the number of
iterations undertaken by a Frank-Wolfe assignment (see 7.1.5) may also need to
be reduced in order to prevent the SAVEIT assignment terminating prematurely.
Post release 11 it is set equal to the best GAP value (9.9.1.2) achieved by the
main simulation-assignment loops such that the convergence in the main and
SAVEIT assignments will be roughly comparable. (Prior to 11.1 UNCRTS was set
equal to the final value of UNCRTS set during the assignment proper under
AUTONA (note 4), 9.5.4) and which is generally a lower value than the GAP; this
could therefore lead to extremely long SAVEIT assignments for no appreciable
gain in overall accuracy.)
In addition, to improve convergence, SATURN also automatically sets PARTAN
assignment under SAVEIT (for single user classes) and allows PARTAN as an
option for MUC SAVEIT assignments via a parameter SPARTA. See 7.11.7 and
15.57.6. Note that a side benefit of using PARTAN/SPARTA is that, by reducing
the number of Frank-Wolfe iterations required to produce a SAVEIT solution, all
subsequent analysis steps that use UFC files (e.g., SATPIJA, SLA, etc.) will
become correspondingly faster.
5120257 / Apr 15 15-54

Section 15
15.23.5 SATUFC – Re-creating .UFC files

A .ufc file may also be created after the original run of SATALL using a procedure
SATUFC introduced in SATURN 10.6. Basically SATUFC reads a .ufs file and
extracts the necessary information to carry out a SAVEIT-style assignment – with
the added proviso that the value of NITA_S can be set as a purely numerical
value on the command line. E.g.:
SATUFC net 30
will produce an output file net.ufc based on NITA_S = 30 (independent of the

value in net.ufs). If a numerical parameter is not used NITA_S is simply taken
from net.ufs.
In fact SATUFC is not a separate program, it is simply a run of SATALL with,
effectively, zero assignment-simulation loops and only the SAVEIT step included.
As a consequence it therefore requires that the original trip matrix .ufm file is
available.
However, post 10.8, if the original network were based on an elastic assignment
the “SAVEIT assignment” uses a fixed trip matrix assignment algorithm, in which
case it uses the output trip matrix (i.e., ROADIJ) from the original run rather than
the original input trip matrix file (FILTIJ). These algorithms are generally faster and
do not suffer from problems of terminating early.
SATUFC has several advantages:
♦ If the original .ufc file did not converge sufficiently well a better level of
convergence may be achieved by increasing NITA_S.
♦ It may also be computationally efficient to set SAVEIT = F in the original

network and to only run SATUFC when a .ufc file is actually required. (If NITA
is very small and NITA_S large the SAVEIT step may take virtually as long as
the original assignment-simulation loops.)
♦ UFS files can be sent without their .ufc files as the latter can be easily re-
created.
♦ By adding an argument UFO to the command line a .UFO file may be created
at the same time as the .UFC file (see 15.23.6 below).
♦ Post 10.8 it also updates the .ufs file to correctly set SAVEIT and/or SAVUFO
to T so that subsequent analysis programs such as P1X will “know” that the
.UFC/.UFO files should exist.
♦ Post 11.1 if the original network were run using OBA then SATUFC will, in
effect, generate a set of O-D paths in a .UFC file which approximate the same
final set of link flows. Thus the (newly created) .UFC file and the (original)
.UFO file fulfil similar functions in terms of post-assignment analysis, e.g.,
select link analysis, but the .UFC file has the advantage that it may be used in
certain programs such as SATPIG where the .UFO file may not.
♦ Similarly a .UFC file may be generated from a path-based assignment where

the .UFQ files which store the paths may also not be suitable for all forms of
post-assignment analysis.
5120257 / Apr 15 15-55

Section 15
♦ Note that if using SATUFC with either a path-based or OBA original solution it
may make sense to copy and rename the original .ufs file so the two sets of
solutions may be used independently.
15.23.6 Alternative Formats for Saving O-D Routes: UFO and UFQ files
The .ufc files described above are relevant to assignments done using the Frank-
Wolfe link-based algorithms (MET = 0). Path-based and origin-based assignments
use their own particular techniques to preserve route flow information and, in
addition, link-based routes may also be converted into an “extended” UFO (OBA)
format.
Thus path-based assignment (see 21.4) stores the exact path data in .UFQ files
while OBA stores the equivalent “splitting factors” in .UFO files (see 22.5.2). In
both cases the information saved is “exact” unlike the link-based .UFC files which
(see 15.23.2 above) may be an approximation based on an extra SAVEIT
assignment.
We note that path-based UFQ files are restricted to single user class assignments
only so that, in terms of practical applications, they are not really relevant and they
are not considered further.
In principle the same forms of analyses (such as those listed in 15.23.1) may be
carried out under all 3 methods, although the precise algorithms used to do so
may differ. Thus .UFC-based algorithms based on a Frank-Wolfe assignment
recreate each individual O-D path used in the assignment in order to analyse
them as appropriate, path-based algorithms analyse explicitly saved paths in the
same way while UFO-based algorithms use “splitting factors” in a “single-pass”
per origin without explicitly re-creating O-D paths (see 22.5.2). Note that, in
practice, some of the necessary programming work may not have been done yet
for certain combinations of method and analysis.
15.23.6.1 UFO vrs UFC

If, say, both .UFO and .UFC files are available for a particular network the user
may have the choice as to which to use (for example carrying out a Select Link
Analysis in P1X, 15.19, PIJA calculations, 13.3.14, or SATCH matrix cordoning,
12.1.12). In such cases the use of .UFO files is generally strongly recommended
as they are considerably faster than using .UFC.
The choice of UFO vrs UFC is generally controlled by a namelist parameter
USEUFO = T or F respectively which may be set in either network .dat files (which
sets the general default; see 6.3.1), SATPIJA or SATCH control files (13.3.14 and
12.1.12).
In addition the UFO format used for OBA (22.5.2) may also be adapted for use
with link-based Frank-Wolfe assignments; essentially the path flows in the UFC
file are converted into the equivalent (or, strictly speaking, nearest equivalent)
acyclic flows which are then stored in a UFO format. See 22.5.3.
UFO files, as explained in Section 22.5, have (at least) one major advantage over
UFC files in that they enable “warm start assignments” to be used under all
possible conditions. In addition the same analysis application may run much faster
with UFO than UFC files (since any analysis of all O-D routes with UFC contains a
5120257 / Apr 15 15-56

Section 15
loop over the number of iterations N which UFO avoids so that, in principle, it may
be N-times faster).
The downside of creating a .UFO file is that, if the Frank-Wolfe solution is not
particularly well converged and contains many examples of cyclical flows,
eliminating those cyclical flows may lead to a significantly different set of flows
(although arguably they may be nearer to a true Wardrop Equilibrium solution)
which causes more confusion than benefit.
Finally note that .UFO files may equally be converted into equivalent (or virtually
equivalent) .UFC files using SATUFC - see 15.23.5 above – and that an
alternative form of .UFO file may be created based on aggregated “spider”
networks – see 22,5.3 – which is generally speaking much faster to use for
analysis
15.23.7 Creating .UFO files (SAVUFO): Batch File Procedures (SATUFO)

In order to create both a UFO and UFC output file from a (Frank-Wolfe, MET = 0)
run of SATALL it is normally necessary to have both SAVEIT = T and SAVUFO =
T within the original network .dat file. (By contrast OBA always produces a UFO
file as long as SAVEIT = T.) The (approximate) algorithms used to create UFO
files from Frank-Wolfe assignment are described in Section 22.5.3
However, alternatively, .UFO files may be created “after the fact” if SAVUFO is not
T in the initial assignment by either:
1) Running the procedure SATUFC (15.23.5) with an extra (text) argument UFO
included in the command line, or
2) Running a procedure “SATUFO net” to create a file net.UFO on the
presumption that the file net.ufc has already been created.
Note that SATUFC and SATUFO are both batch files which call $SATALL.EXE
with particular command line parameters in order to carry out particular functions;
i.e., they are not distinct .exe files.
15.23.7.1 SATUFO: Single User Class option

A sub-option within the batch procedure SATUFO.BAT allows a .UFO file to be
created for a single user class n by using a Command:
SATUFO net NOMAD n
in which case the output .UFO file will be named net_n.ufo.
15.23.7.2 SATUFO: Multi-core option

The SATUFO process will also take advantage of the multi-core capability within
the software if available – see section 15.53 for further details.
15.23.8 Final Comments: The Uniqueness of Route Flows and Other Limitations
In applying the various analyses available within SATURN based on specific O-D
routes users must appreciate that all such outputs must be taken with a rather
large pinch of salt.
5120257 / Apr 15 15-57

Section 15
Firstly, it must be appreciated that O-D routes are not uniquely specified by
Wardrop Equilibrium (see 7.1.6) and that the routes generated by the Frank-Wolfe
algorithm (plus OBA) are, to a certain extent, arbitrary. Thus, strictly speaking,
Wardrop Equilibrium only identifies those O-D routes that may be assigned
positive flows but not the precise split of traffic between those routes. A simple
example is given in Section 7.1.6 to demonstrate the non-uniqueness of origin or
user class based flows between two parallel routes even when the total link flows
are uniquely specified. The final assigned route flows may simply be due to some
minor artefact of the algorithm used.
From which it follows – and this is the important point - that any outputs from a
route flow analysis such as a Select Link Analysis or skimming, say, distance from
a forest (15.27.6) are also non-unique and, therefore, prone to being arbitrary.
A knock-on impact of skimmed times, distances etc. etc. being non-unique is that
any further analyses based on those skimmed matrices becomes non-unique.
This therefore may introduce further problems with economic evaluation packages
such as TUBA or external demand models (VDM) which are not based on
generalised cost matrices generated by SATURN (which are unique); see also
7.8.6.
Secondly, there are potential problems with the “all or nothing” division of O-D
routes into “used” and “non-used”. Thus a “rat run” route which includes a large
proportion of very low capacity links may be allocated O-D route flows if it is a
minimum cost route, whereas an alternative route along a series of high-capacity
motorway links may not be used at all if its generalised cost is (just) 1 second
above the minimum. Small changes in either the network or trip matrix may
reverse either allocation.
On a more positive note one could argue that, given its sequence of operations,
the Frank-Wolfe algorithm is unlikely to produce a totally unbalanced or extreme
set of O-D route flows. Equally it treats all origins equally and simultaneously and
will not therefore produce route flows which are “biased” by origin. Its outputs
might therefore be charitably described as “plausible” – but never perfect.
The situation, however, becomes worse if we consider not just the OD route
patterns in a single network but any comparison of the route flows in two networks
which differ slightly from one another. Here the “noise” generated by the above
two problems may render any comparisons extremely tenuous.
To a certain extent the problems with route flows are simply an inevitable
consequence of the fact that more you disaggregate data the more unreliably it
becomes. There are far more route flows than, say, link flows and the flows per
route are much smaller than the flows per link. These problems are, however,
aggravated by the problems of non-uniqueness and the lack of an acceptable
behavioural model of route choice. What is required, possibly, is an extension to
Wardrop Equilibrium to deal with route choice and which would operate at a far
more disaggregate level than total link flows. This issue is discussed further in the
following section, 15.23.9.
15.23.9 Unique Route Flows: The Principle of Proportionality

One method (in theory at least) to define a unique set of path flows within a
Wardrop Equilibrium solution is to require that the path flows satisfy the
5120257 / Apr 15 15-58

Section 15
“proportionality condition”; see, for example, various articles by BarGera and

others.
Proportionality requires that, at any node A where there are more than one exit
links that are on minimum cost paths to another node further downstream, i.e.,
they represent parallel route segments with the same cost, then the proportion of
trips using each segment / exit link must be the same for all origins and/or
destinations. Thus, with reference to the example of two parallel links as
described in Section 7.16, the 50:50 split between the two alternative path
segments must be maintained for all origin and/or destination flows.
Proportionality is thus only a statement of conditions which must hold, it does not
in itself provide an algorithm for achieving such a solution. However there are
certain assignment algorithms which have recently been developed which do
generate proportional solutions but which have not reached the stage of finished
products.
An alternative “principle” for specifying a unique set of path flows is that of
“entropy maximisation” where we choose a set of path flows T pij which maximise
the entropy measure (see equation (13.2) in section 13.1.1). To a large extent (as
I understand it) proportionality and entropy maximisation generate the same
solutions but there may be pathological situations where they differ. To a certain
extent the differences are academic since algorithms to solve for either are hard to
come by.
15.24 Alternative Link Costs and/or Times for Tree Building
P1X, SATDB and SATLOOK contain various options (with a large degree of
overlap) which allow “trees” or minimum cost paths to be built from an origin to a
selected destination zone or indeed to all destinations. The “cost” used to build a
minimum cost path is defined as a linear combination of time and distance (or
distance-related parameters) as follows:
c =a1t + a2 d + ∑ bk d k
where c is the cost on a link

t is the link travel time (including any 44444 time penalties)
d is the link distance
m is a monetary toll (if any)
a 1 and a 2 are the values of time and distance respectively (generally set by
parameters PPM and PPK and possibly disaggregated by user class)
d k , k = 1, ... K are the additional link “KNOB” properties
b k , k = 1, ... K are conversion factors to reduce them to a common cost (see
7.12.2).
For most applications the KNOBS facility will not be invoked and cost is therefore
a linear combination of time, distance and, possibly, tolls. Weighting parameters
5120257 / Apr 15 15-59

Section 15
PPM and PPK will already have been defined by the user during the SATURN
runs and, if the user wishes to re-create the same or similar trees, the same
values should be selected. These values may also have been user-class specific.
However alternative cost trees may also be investigated; e.g., you may run
SATURN on the basis of minimum time trees but then look at minimum distance
trees.
Distance, KNOBS data and tolls are, by definition, fixed. However time may be
defined in a number of different ways (e.g., with or without penalties added) and
calculated at different points during the programs as elaborated below in 15.24.2,
15.24.3 and 15.24.4.
Note that these discussions refer equally to “time skims” as discussed in 15.27.
15.24.2 Travel Time: Alternative Definitions

“Time”, unless otherwise qualified, refers to the time to traverse a particular
(assignment) link by a standard vehicle or pcu. However in certain situations it
may be necessary to consider differential times by, say, user class or by bus lane.
These are explained further below, 15.24.4
For display purposes, e.g., in P1X, time is very often sub-divided into various sub-
components, e.g., fixed times, transient delays, queuing delays, etc. etc. Equally
link travel times as displayed may or may not include additional delays associated
with one or all of the delays from turning movements at the downstream end of the
link.
15.24.3 Calculating Times at Different Stages within SATURN

Link travel times are set at 4 different stages within SATURN as follows:
1) Free flow travel time;
2) Times calculated at each assignment iteration;
3) Travel time as calculated at the end of the assignment;
4) Travel time as calculated (for simulation turns only) by the simulation.
Of these (1), (3) and (4) are generally saved on the SATURN UF files but (2) is
only (in effect) saved on a UFC file if the SAVEIT option is requested.
Trees may be built using any of the (available) times above. The following notes
describe the differences between these times in greater detail and suggest
circumstances in which they might be used.
1) Free flow times are defined within SATNET for all network elements (e.g.,
links, centroid connectors) EXCEPT for simulation turns whose free flow times
are the delays calculated by SATSIM with zero flow on each turn. Free flow
times are generally used to build the first set of trees in the assignment.
These may be thought of as the "ideal" routes.
2) At each subsequent assignment iteration the times are set according to
equations (5.1) where V is the “current” flow such that the assigned volumes
at iteration i are used to set the times (and therefore the costs) at iteration i+1.
5120257 / Apr 15 15-60

Section 15
Therefore these times would be used to re-construct the routes built at each
stage of the assignment procedure; they constitute the “real” routes as
assigned.
(N.B. The times as defined above are only preserved on a UFC file if SAVEIT
= T, so that only then can actual routes be re-created. In actual fact what are
saved are NOT the times but the costs, i.e., including the fixed components
appropriately weighted. Therefore it is not possible to use, say, the second
set of link times in a new definition of generalised cost, although there is
probably very little reason why one should ever want to do that - the important
thing is to be able to re-create the routes to which trips were assigned at each
iteration.)
3) At the conclusion of the assignment, times are also calculated using (5.1) with
V equal to the final assigned flows. These are therefore the “best” times as
calculated by the assignment but, somewhat perversely, they are never used
by the assignment to build routes. These times should therefore be used to
calculate the minimum cost routes at convergence, e.g., to calculate an O-D
cost matrix for evaluation purposes.
(N.B. Although routes calculated using the above times were not necessarily
generated by the assignment this is not to say that they definitely were NOT.
Indeed in most cases the final routes will correspond to one and probably
more than one of the routes actually generated so that they are not
necessarily unrepresentative. However some care should be exercised in
their analysis.)
4) When the simulation stage is run after the assignment the delays on turns in
the simulation network are re-calculated by simulation. If the model has
converged properly these delays should differ by only a small amount from
those calculated by the assignment (and be identical in the event of perfect
convergence). These times are somewhat more “realistic” than those
calculated at the end of the assignment and therefore the “best” estimate of
O-D costs would be obtained using these costs. Again the same caveat as
above applies to the routes actually calculated using these costs; i.e., they do
not necessarily correspond to routes generated by the assignment although
they are unlikely to be “unrepresentative” routes.
Times (1), (3) and (4) can be selected by the user via menus in SATDB,
SATLOOK and P1X. Times (2) are effectively only available through the options
to “loop” over each iterative set of costs to construct each built tree in turn.
15.24.4 Extended Travel Times

The “basic” link travel times for “cars” as defined in 15.24.2 may need to be
extended to include additional time components as required in certain
circumstances. The need arises very often when different user classes have
different speeds and, in particular, when time is being skimmed (see 15.27.7.1)
as opposed to being used to set minimum cost routes.
Thus, by default, link time penalties as defined under the network 44444 data
records (6.8) are, by default, included within the normal definitions of skimmed
time on the basis that they are more likely to be “real” times rather than “notional”
times added by the user to improve the assignment routings. (Note that the
5120257 / Apr 15 15-61

Section 15
contribution of penalties is always included under the definition of “cost”, e.g.,

used to define minimum cost routes, since it is an integral component of the fixed
link costs)
Equally, any extra travel times associated with specific user classes calculated
using the CLICKS options (15.47) are also included by default. (N.B. CLICKS was
only introduced in 10.6.)
On the other hand there will definitely be occasions when a user wishes to
exclude 44444 penalties and/or CLICKS in the definition of times. Thus in the
interactive menus used in P1X, SATLOOK and SATDB to define time for tree
building and/or skimming there are “toggle” options to explicitly include or exclude
CLICKS and/or penalties.
In addition the include/exclude default options may be user set using parameters
USETP and CLICKY in the appropriate preferences files (SATLOOK0.dat etc.).
Thus if USETP = T then, if “time” is selected, it will include all 44444 time penalties
(for that user class); similarly if CLICKY = T then times defined according to
CLICKS are used in preference to “normal” times. Both parameters default to T.
15.24.5 Units of Time and Costs

As explained in 7.11.1 SATURN conventionally expresses all costs as
“generalised time” as opposed to “generalised cost” within the assignment
procedures. The same rule also applies by default to the analysis of the
assignment via tree building etc., although with 9.1 options have been introduced
to allow costs to be defined in units of, say, pence rather than seconds. This is
particularly useful for “skimming” trees as explained in Section 15.27.
Note however that SATURN virtually always defines generalised cost internally in
units of seconds, e.g., when carrying out elastic or variable demand calculations.
Users are therefore strongly recommended to stick with generalised time unless,
e.g., they specifically require costs in some other units to be exported to some
other evaluation package.
15.25 Stochastic Trees

“Stochastic trees” refers to minimum cost routes between origin and destination
zones (hence trees) built on the basis of using random number distributions to
generate individual link costs (hence stochastic). It is therefore the process at the
heart of stochastic assignment as described in Section 7.2.
All programs that allow the user to build trees - SATLOOK, P1X and SATDB -
also enable stochastic trees to be built by setting the parameter “SUZIE” to
.TRUE. Parameters SUET, KORN and KOB then control the generation of
randomised link costs in the same way as they do within stochastic assignment -
see Sections 7.2.3 and 7.2.4.
There are two very general circumstances in which stochastic trees are built:
1) To precisely reproduce the routes generated during the stochastic
assignment itself; and
5120257 / Apr 15 15-62

Section 15
2) To generate a series of “typical” stochastic routes in order to assess

qualitatively the effect of different parameter values.
In order to do (1) it is essential to have invoked the SAVEIT option during the
assignment (see Section 15.23) and to then select the desired iteration number or
numbers. As long as SUET, KORN and KOB are identical to those values used
during the assignment then the routes SHOULD be identical. (But, N.B., this
reproducibility is a function of how your program has been compiled vis a vis
random numbers since there is a choice between using your own
machine-dependent random number generating functions, which are probably
NOT reproducible, and using a SATURN-supplied function which is. If your
programs were supplied as “executables” from Leeds or Atkins, worry not; if they
are home-compiled check.)
Method (2) may be used, for example, to see how large a value SUET can take
before the routes generated using, say, minimum time as the basis, become
unrealistic.
15.26 Trees, Forests and Arboreta

A “tree” refers to the set of shortest routes from one origin to one (or all)
nodes/zones in a network. As such a separate tree is calculated on each iteration
within an assignment. A “forest” is therefore an aggregation of all the trees from a
single origin over all internal assignment iterations, weighted by the fraction of the
trip matrix as ultimately assigned to each iteration.
More precisely the “forest” value for a link is the proportion of trips from a
particular origin to a particular destination which use that link. It is therefore
virtually identical to the “Pija” factors as used by SATME2, although used in
different contexts
Forests are a highly preferable method of analysing O-D routes for the simple fact
that they contain information about ALL routes assigned traffic for that O-D pair,
as opposed to looking at the single route which is currently minimum cost at the
end of the assignment process and which may even not have been used in the
assignment itself.
Trees may be built in a number of different ways within P1X, SATDB or
SATLOOK, although the graphical methods within P1X (11.8.3) are generally
recommended.
Forests may be built in either P1X (graphically) or SATDB (numerically). Equally
they may be built under both stochastic and Wardrop equilibrium style
assignments. (But see remarks in Section 7.2.4 concerning the consistent re-
creation of randomised costs).
By contrast an arboretum is defined to be the set of all different routes used by a
single O-D pair; i.e. the complete set of different trees. Thus if an assignment
takes 20 iterations it generates 20 trees of which only 5 of these may make up the
arboretum. The “arboretum display” option in P1X displays each tree one at a
time with data on the fraction of all trips using that route (summed over all
iterations or trees). Because it uses fewer displays it is preferable to displaying
trees one at a time.
5120257 / Apr 15 15-63

Section 15
(N.B. An arboretum is essentially a Frank-Wolfe algorithm based construct for

which there is no direct equivalent under OBA.)
Note as well that forests and arboreta can only be constructed IF the SAVEIT
option is in effect - see Section 15.23.
15.27 Skimming Trees and/or Forests
15.27.1 Minimum Cost Trees and Matrices

Trees (15.26) represent the full set of minimum “cost” O-D paths, where cost is
some criteria such as time, distance, monetary cost or, most often, generalised
cost (i.e., a weighted combination of two or more components such as time and
distance) which the individual O-D paths (or “routes”) minimise. They are called
“trees” since, if you plot the set of minimum cost paths from one origin to all
destinations, the resulting sub-network resembles a tree which continuously
branches outwards from its root/origin such that there is only one possible path to
each destination D. The cost along the single path to D is therefore the minimum
cost to D and a “tree” is therefore synonymous with “minimum cost O-D path”.
Clearly trees depend on how “cost” is defined: the path that minimises time
between O and D is not necessarily the same path that minimises distance nor the
one that minimises generalised cost.
Note that in the vast majority of transport models “cost” is synonymous with
“generalised cost” so that we may distinguish cost from its sub-components such
as time and distance.
A “minimum cost matrix” is the complete matrix of O-D minimum costs as
extracted from the tree.
15.27.2 Skimming Trees

To “skim” a tree is to sum a particular “quantity”, e.g., time, distance, toll, etc., etc.,
link-by-link along the minimum cost paths for each O-D pair. For example, we may
wish to calculate the distance along the O-D path which minimises cost Therefore
we distinguish between the quantity which is used to build the tree and the
quantity which is skimmed. Skimming is very often an essential step in scheme
evaluation.
Within SATURN skimmed O-D matrices may be obtained in two different ways:
via trees (as described here) or, much more usefully, via “forests” as described in
15.27.3.
Trees may be skimmed to produce “skimmed matrices” as part of the tree-building
option 14 within SATLOOK; thus the ij-th element in the output matrix is, e.g., the
distance from origin i to destination j as summed along the links in the minimum
cost (time) path from i to j.
Note that using a “tree” to produce, say, distance skims does not necessarily
accurately reflect the average assigned distance for trips between a given O-D
pair in those cases where several different routes with several different distances
are used within the assignment process. Skimming a tree only gives one
particular route distance and indeed other routes may give lower or higher
5120257 / Apr 15 15-64

Section 15
distances so that the “true” average distance may also be greater or less than a
skimmed tree.
The problem becomes more acute with quantities such as tolls which are much
more “off or on”. Thus if an O-D pair uses two routes, one of which is tolled and
the other is not, then it is somewhat hit or miss whether the single skimmed route
gives zero toll or the full toll.
WARNING! Skimming O-D data from single path trees may therefore produce
unreliable or misleading results. The only quantity which may be skimmed
absolutely unambiguously from, say, the minimum cost tree is cost itself.
In fact the only arguable advantage to skimming a tree as opposed to skimming a
forest is that it is much faster – only one tree needs to be built per origin as
opposed to a forest skim where separate trees have to be built for each Frank-
Wolfe iteration; e.g., it may be 50 or 10 times more time consuming.
Cumulative link/node skims may also be obtained for individual links using the tree
building option within SATDB; in this case a distance skim, for example, would be
the summed distance from the origin to the end of a link. Similarly in P1X time
and distance skims are automatically accumulated for O-D trees plotted
continuously there.
15.27.2.1 Default O-D Costs

In the event that a particular o-d pair is not connected, for example due to the
origin having no out-bound centroid connectors, the skimmed cell in the matrix
takes on a default value of zero by default. Logically it might be argued that, if it is
impossible to get from o to d, the default value should be a very large value. On
the other hand, if the trip matrix contains a positive value in that cell (for whatever
reason), multiplying the trip matrix by the skimmed matrix would yield very large
numbers for the unconnected cells which may swamp the “correct” cells as part of
an economic evaluation of total vehicle-costs. The default value may, however,
be changed by the user within the SATLOOK interactive menus or via a
parameter DEFODC in SATLOOK0.dat.
15.27.3 Skimming Forests

As noted above (15.27.2) skimming the single minimum cost tree to produce, say,
distance may be unreliable and/or misleading. An alternative procedure – option 9
within SATLOOK - is to skim a “forest” (see 15.26) whereby the distance (say) is
calculated using the exact routes used on iterations 1, 2, 3, etc. and a correct
weighted average distance obtained.
The one basic option within a forest skim is to nominate the quantity to be
skimmed. Generally, but not always, the quantity skimmed will be a sub-
component of the generalised cost used to define the forest, e.g., time, distance,
toll, etc. Alternative options exist to either:
♦ construct the skimmed quantity from elements in the base network file;
♦ select a link property which is stored in a SATDB data base column (which in
turn may be read in from an external ascii file) (N.B. This option is only
5120257 / Apr 15 15-65

Section 15
available when SATLOOK is accessed via P1X and therefore SATDB may
be accessed as well; see 11.11.19);
♦ if a second network file is defined which is topologically identical to the first,

then a DA array from that file may also be nominated. This enables one to,
e.g. skim average times on network 1 paths based on the times calculated in
network 2 (new in SATURN 10.1).
In principle, therefore, it should be possible to set up properties such as fuel
consumption or accident rates per link and skim them in order to create O-D
matrices of fuel consumption or accident rates.
In addition there are a number of sub-options to modify the precise definition of
certain skimmed quantities. For example penalty times input under 44444 may be
optionally included or excluded, extra time components associated with specific
user/vehicle classes under CLICKS may be in/excluded and times/distances on
centroid connectors may be deliberately excluded (XCCSK; see 15.41.5).
Note that a forest skim is only possible with SAVEIT = T and also, since it involves
building and skimming one tree per iteration within the “SAVEIT assignment”, it
may take considerably more cpu time than skimming a tree. However the results
obtained will generally speaking be more accurate and are recommended for use
in matrix-based evaluation such as TUBA.
In particular a forest skimmed matrix satisfies the condition (but see 15.27.5
below) that:
∑ T S = ∑V S
ij
ij ij
a
a a
where the left hand side of the equation represents the total, say, vehicle-kms
summed over ij pairs and the right hand side represents the same quantity
summed over links. S ij and S a refer to the property being skimmed e.g., distance.
Note that some care needs to be exercised in the definition of V a in the above
equation since it must be: (1) the link flows from the trip matrix itself (e.g.,
excluding any fixed link flows); and (2) demand as opposed to actual flows. We
return to this point in the following section.
We may also note that forest and tree skims will give identical results for O-D pairs
where the assignment has only generated a single route. Typically this occurs for
very near O-D pairs or for very uncongested sections of the network.
For further information on SAVEIT and forests please refer to sections 15.23 and
15.26.
We also note one additional caveat with forest skims which is that, since the path
flows generated by a Wardrop Equilibrium assignment are not, strictly speaking,
unique (see 7.1.6), neither are skims taken over those paths (see 15.23.8). The
example given in 7.1.6 as to which origin(s) pay tolls illustrates the problem –
although, in practice, the problem is much more likely to be that the model shows
the two origins paying tolls in slightly different proportions rather than the extreme
“all or nothing” case where one origin pays tolls and a second does not. Note (7)
in 15.27.6 discusses this issue further.
5120257 / Apr 15 15-66

Section 15
15.27.4 Minimum Cost Matrices vrs Skimmed (Average) Cost Matrices

In effect minimum cost matrices – the matrix of minimum possible costs from O to
D 15.27.1) - are a particular example of matrices skimmed from a single tree
whereby the quantity which is skimmed (summed) is the same quantity which
defined the minimum “cost” paths. However, since the minimum O-D travel costs
are obtained as an integral part of the tree-building process, it is not necessary to
do a subsequent “skim” which would clearly give identical results.
However it is also possible to construct a matrix of costs by skimming a forest
where in this case the “cost” refers to the “generalised cost” used in the
assignment process (see 7.11.1) which, in turn, are the same costs upon which
the forest of assigned O-D routes are based. In this case the skimmed cost will be
the weighted average cost over all O-D routes used.
We recall that Wardrop’s Principle requires that at equilibrium all used routes have
equal and minimum costs so that – in the case of perfect equilibrium - the
minimum cost matrix will be identical to the cost matrix obtained by skimming the
forest. For less than perfect convergence (the inevitable norm) the minimum costs
will be (potentially) less than the costs along some assigned routes and therefore
less than the average.
In certain respects, assuming the inevitable less than perfect convergence, the
forest cost matrix is “better” than the minimum cost matrix since it corresponds to
the costs actually incurred according to the assignment; it might, therefore, be
better to use within economic evaluation. On the other hand it requires
considerably more CPU time to calculate. And, strictly speaking, neither is
“correct” in the sense of being equal to the cost matrix which would be obtained
under perfect convergence; in general one would expect that the minimum cost
matrix would be a slight under-estimate of the “true” ultimate cost matrix and the
average would be a slight over-estimate.
Thus, faced with two alternatives, neither of which is correct but one of which is
much cheaper to calculate, there is a strong case to be made for choosing the
cheaper alternative, i.e., to take cost matrices as equal to the minimum cost
matrices rather than the forest skims.
Note, however, that this advice does certainly not apply to any sub-components of
cost such as time or distance which can only be obtained reliably as skims over
forests as opposed to, say, building a minimum time tree or skimming a minimum
cost tree.
Finally, there is a third method by which cost matrices may be constructed. Thus,
if the cost per link is a weighted combination of, say, time and distance such that:
C a = w 1 t a + w2 d a
Then, if we take forest skimmed matrices of time and distance t ij and d ij then we
can also obtain the average cost matrix C ij via:
C ij = w 1 t ij + w 2 d ij
This method is sometimes necessary if, for example, the user wishes to define
different values of the weights w 1 and w 2 (se 7.8.6)
5120257 / Apr 15 15-67

Section 15
15.27.5 Skim/Cost Matrices and Trip Matrices

It needs to be appreciated that skimmed and/or cost matrices (in general) are
calculated entirely independently of any considerations of demand and actual
flows on individual links. Thus the O-D “distance” in a distance matrix is the sum
of the individual link distances along a particular path or paths whether or not the
O-D trips use those links in the “current” or a “later” time period. Demand and
actual flows play no role.
This may have certain implications for matrix-based evaluation procedures and, in
particular, for the interpretation of the “product” of a trip matrix and a skimmed
matrix; i.e., under what conditions will the following equation hold:
∑ T S = ∑V S
ij
ij ij
a
a a
where the left hand side of the equation represents the total, say, vehicle-kms
summed over ij pairs and the right hand side represents the same quantity
summed over links (and displayed in output tables such as Table 17.3 as
described in Section 17.9).
Firstly, such an equality never holds if the flows V a correspond to actual link flows
and the summation corresponds to, say, total pcu-kms within “this time period”
(see Table 17.3). In particular, there is no such thing as an “actual” trip matrix for
use on the left-hand side, only a demand matrix.
Secondly, if the matrix S ij has been skimmed from a (single path) tree then the
equality will not hold in general (unless, most unlikely, all O-D trips have been
assigned to single, not multiple, paths).
The equality may hold if: (a) T ij is a demand matrix; (b) S ij has been skimmed from
a forest and (c) the link summation includes both this and the following time
periods (the “Totals” column in Table 17.3).
However, even these conditions may not be sufficient to guarantee exact equality.
For example, if the link flows V a are obtained from the “true” model run and the
skimmed matrix is based on a forest obtained using an approximate SAVEIT
assignment (15.23.2) then the equality will only be approximate, limited by the
lack of perfect convergence within both the true and the SAVEIT assignment.
More specifically, if S represents time then the parameter AFTERS must equal
0.5; see 17.6.2.
Conditions becoming slightly easier if the quantity S refers to the “generalised
cost” used by the assignment as opposed to a particular component such as time
or distance (or if, say, the assignment is based on pure time). In this situation the
skim matrix S ij is effectively the same whether it is obtained as a minimum cost
matrix or as a forest skim to the extent that under perfect Wardrop Equilibrium all
used paths have equal and minimum cost. Clearly if the convergence is not
perfect then the equality will be only an approximation.
5120257 / Apr 15 15-68

Section 15
15.27.6 Summary: Minimum and/or Skim Matrices

This section summarises several common sources of confusion experienced by
users faced with the problem of producing “cost” and/or skimmed matrices (in
general).
1) A matrix of, say, O-D distances (times, tolls, etc.) may be produced in at least
three different ways (where we assume first that the assignment is not based
on minimum distance):
a) building minimum distance trees,
b) skimming distance along the (single path) minimum cost trees,
c) skimming average distance along the (forest of) multiple paths used
within the assignment.
These correspond to minimum cost matrices (Option 14 in SATLOOK),
skimmed matrices (Option 14 in SATLOOK) and forest skims (Option 9 in
SATLOOK and/or batch files such as SKIMDIST (15.27.7)) respectively. It is
important that users understand how these three types of matrices differ.
2) Of the above three methods, the third, i.e., the “forest skim” (15.27.3), is
almost certainly the most realistic since it corresponds most closely to the
“true” assigned paths, generates fewer problems in terms of uniqueness,
reliability etc. etc. (but not NO problems – see points 6, 7 and 8 below).
However it may take considerably more cpu – see point 9 below.
3) The first, “true” minimum distance (etc.), has the advantage of being
unambiguously defined but, on the other hand, it may not correspond to a
route that would actually be used by drivers. However, it might be useful to
compare a “true” minimum distance matrix to the “actual” distance matrix to
see how near users are to minimum distance.
4) Equally skimming distance (etc.) from a single minimum-cost tree is highly
unreliable (see 15.27.2). However skimming a single tree may be much faster
than skimming a forest and, if only an approximate answer is required, may
be sufficient.
5) On the other hand, if we are interested in a “cost” matrix for use, say, in an
external demand or evaluation model, where cost refers to the generalised
cost used in the assignment, then methods (a) and (b) above give identical
results while (c) differs only in terms of non-convergence. Indeed, if we have
achieved perfect Wardrop Equilibrium, cost should be equal on all routes used
and (c) must give the same result as (a) and (b). In practice deviations occur
due to a lack of perfect convergence so that (a) must give lower values than
(c). The answer which would be obtained ultimately by a perfectly convergent
Wardrop Equilibrium solution will (almost certainly) be somewhere between
the two values. Method (a) is therefore recommended unless one is
specifically interested in the average O-D costs.
6) When skimming from a forest, under the standard Frank-Wolfe method of
assignment as opposed to path-based or OBA, the level of convergence
achieved by the extra SAVEIT assignment (if one is required) becomes an
issue (15.23.2). Thus the routes generated by a SAVEIT Forest will not, in
5120257 / Apr 15 15-69

Section 15
general, reproduce the same routes and the same link flows as generated by
the assignment proper; they are only an approximation. The differences are
reduced by better convergence (i.e., increased values of NITA_S) which leads
to more accurate skims but it also means more cpu time. Compromises may
be required.
(N.B. These problems do not arise if the skimmed forests are based on the
actual assignment routes as opposed to an extra SAVEIT assignment; e.g., if
UFC109 = T; see 15.23.3.1)
7) Since the precise route flows generated under Wardrop Equilibrium are not
unique (see 7.1.6 and 15.23.8) neither are the average (forest-weighted) O-D
times, distances etc. cost components which are skimmed from them, even if
convergence were perfect. In addition the average OD speed matrix obtained
by dividing average distance by average time would not be unique either. This
may have implications for the convergence of linked supply and demand
models (7.8.6) or for economic evaluation models where the
demand/evaluation model is based on a different definition of generalised
cost from the assignment model and therefore requires separate skims of
time, distance, etc. The problem is most acute if a high degree of
convergence is required. It may also have implications for economic
evaluation models when applied to relatively small schemes when any source
of “noise” in time and distance etc. matrices is a problem.
8) The problems of non-uniqueness may be further aggravated by the presence
of “residual path flows” in the solution used which may make skimmed
quantities considerably more unreliable than, say, flows. See 15.57.
9) The problems of non-uniqueness for time and/or distance skims may be
particularly evident when comparing skims from two different schemes where,
for example, there may be large differences in individual O-D times or
distances when none might be otherwise expected. These differences may be
due to network 1 using an arbitrarily different set of OD routes from network 2
and, if there is a large degree of variability between the times/distances on the
alternative routes (even though they may have identical generalised costs),
then there will equally be a high degree of variability in the time/distance
skims.
10) The degree of variability may also depend on the relative cost “weights” (i.e.,
PPM and PPK) assigned to time and distance. Thus if PPK were near zero,
implying that distance is not very important in choosing minimum cost routes,
and an O-D pair is assigned to two routes, one with short distance and one
with long, then the skimmed distance could be anywhere between the
minimum and maximum distances depending on the essentially arbitrary split
between the two routes. On the other hand, the time skims in this situation
would be far more stable since time would be effectively equal to cost and the
costs on the two alternative routes would be equal. Conversely if PPM is small
then distance skims will be stable and time skims more variable. Note,
therefore, that different user classes which have different values of PPM and
PPK may well behave differently.
11) For assignments based on Frank-Wolfe (as opposed to OBA) calculating a
minimum cost matrix requires one tree build operation per origin; skimming
5120257 / Apr 15 15-70

Section 15
an average matrix from a forest requires one tree build operation per origin
per assignment iteration. Hence it may require 25, 50, 100, etc. times more
cpu time depending on the value of NITA_S. For large networks this time may
be significant. (Note that this does not apply to OBA since skimming under
OBA requires only a single pass; see 22.5.6)
15.27.7 Skimming Costs Using .Bat Files (E.g., SATCOST.bat)

A number of useful standard .bat files have been created within SATURN in order
to simplify and automate the creation of minimum and/or averaged “cost” etc.
matrices.
Thus the .bat file SATCOST automatically extracts the minimum (as opposed to
average) cost matrix (as defined in 15.27.1) and is available both within DOS and
SATWIN. For example, the command:
SATCOST net cij
Generates the matrix of minimum o-d costs for network net.ufs and stores them in
cij.ufm. Type “SATCOST” for full filename conventions. This is usefully coupled
with elastic assignment to generate cost matrices for external demand models
(see 7.8.6).
If the input network contains multiple user classes the calculations include all user
classes and the output matrix is a stacked matrix, one “level” per user class.
Similarly if the input network has an extension .uft., i.e., it represents the outputs
of multiple time periods, then the output matrix cij.ufm will be “stacked by blocks”
with each “block” (see 10.2.4) representing the o-d costs for a particular time
period.
Note that SATCOST - and all the variants below - produce cost matrices defined
in units of generalised seconds which are therefore compatible with the units used
within all elastic or variable demand models.
Equally note that the units are, effectively, O-D travel cost per pcu and bear no
relationship to the trip matrix or any factors used, e.g., to factor trip matrices. For
example, if you have a model with a single total trip matrix equally divided into six
user classes, then SATCOST will create a stacked .ufm matrix with six levels, one
per user class, each approximately equal to the cost matrix for a single user class.
Thus the fact that the trip matrix is divided by six per user class does not imply
that the cost matrices are equally factored.
Several alternative bat files are provided based on Forest Skimming (Option 9
within SATLOOK; see 11.11.9). In particular:
♦ SATC_AV skims average costs from a forest (15.27.3)
♦ SATC_MAR skims marginal costs (but only from networks which were
assigned under system optimal conditions; see 7.11.9).
♦ SATC_TP produces a minimum cost matrix (à la SATCOST) but over multiple

time periods (see Section 17).
♦ SKIMTIME skims averaged o-d times (in seconds) from a forest as described
in 15.27.3.
5120257 / Apr 15 15-71

Section 15
♦ SKIMDIST skims averaged o-d distances (in metres) from a forest.
♦ SKIMTOLL skims averaged o-d tolls (in pence; see Section 20.3) from a
forest.
♦ SKIMPEN skims averaged o-d time penalties (in seconds) as defined within
the 44444 data records from a forest.
♦ SKIM_ALL combines SKIMTIME, SKIMDIST, SKIMTOLL and/or SKIMPEN

into a single routine which skims all 3 or 4 quantities “simultaneously” which
means that the CPU time is reduced by a factor of roughly 3/4 (or 2 if there
are no tolls included in the definition of generalised cost). Time penalties are
only output if they exist.
♦ SKIMDA skims a particular property identified by its DA code, hence a

general purpose skim routine which could be used to skim time, distances,
etc. etc. by using the requisite DA code
♦ SATTUBA skims time, distance and/or tolls directly to a series of ascii files in
various TUBA formats; see Section 15.41 for further details
For further details on file format conventions etc. please type the names above.
Note also that routines SKIMTIME to SATTUBA as listed above may all take
advantage of multiple processors if available; see 15.53.3.2.
15.27.7.1 The Definition of Skimmed “Cost”

The following notes may help clarify exactly how the skimmed “cost” is defined in
certain of the above batch files.
Under SKIMTIME, times are equal to the “real” times along links and/or turns plus,
by default, any penalty times which may have been added under the 44444
restrictions (see 6.7). However, post 10.6, the 44444 penalties may be excluded
if a parameter USETP is set to F in the preferences file SATLOOK0.DAT. Equally,
if the CLICKS option is being used, the link times will use the CLICKS rules if a
parameter CLICKY = T in SATLOOK0.DAT which, by default, it is. See also
15.24.4. Finally skimmed times on centroid connectors may be excluded (by
setting them to zero) if a parameter XCCSK = T in SATLOOK0.dat (15.41.5).
In addition times under SKIMTIME are those calculated by the final simulation as
opposed to those calculated by the final assignment (DA code 4013 rather than
4003).
XCCSK also applies to SKIMDIST; i.e., if T skimmed distances on centroid
connectors are assumed to be zero.
Tolls under SKIMTOLL are in units of “pence” (or, strictly speaking, defined by the
parameter COINS) and include all monetary toll components whether defined
under the 44444 records or as a KNOBS input. See Section 20. (N.B. Since tolls
in the sense of explicit monetary tolls were only introduced in version 10.3
SKIMTOLL cannot be used with files created prior to 10.3.)
5120257 / Apr 15 15-72

Section 15
By contrast with SKIMTOLL SKIMPEN also extracts data from the 44444 data
inputs but only those elements which been defined as “times” rather than “money”;
i.e., those without a $ or £ sign. See 6.7.
15.27.7.2 Skimming Using Aggregated (SPIDER) Networks

If SPIDER = T and the network has been built using an aggregated network
definition (see 15.56) then the algorithm used to build minimum cost trees may be
based on either the basic or the aggregated network depending on whether a
parameter USESPI = F or T respectively. The default value set by the program is
F but it is generally over-written by the value within the preferences file
SATLOOK0.DAT (which may be set by the user). Or see the sub-section below for
a further method for setting USESPI.
The resultant skimmed matrices are the same whether or not the aggregated
network is used; the main difference is that the aggregated method requires
significantly less CPU time.
The use of aggregated networks applies to both skimming a single tree as well as
to forest-based average skimming. For forest-based skims the potential CPU time
reductions are significant (e.g., 10 times faster); however, for a single tree build
operation per origin/user class, not multiple iterations, CPU time is less of an issue
here in absolute terms.
Note, however, that at the time of writing the possibility to use aggregated
skimming applies to most – but not all – applications of skimming. Its use is being
gradually extended and will eventually cover all applications. Information within
the .LP files should hopefully make it clear whether it is being applied or not.
For further information see 15.56.7.1.
15.27.7.3 Command Line Over-rides for, e.g., the use of .UFO files
The command lines associated with procedures such as SKIMDIST, SKIMTIME
etc. etc. may also be used to “over-ride” certain default skimming options. For
example, the choice of whether or not to use a Spider Web network
representation rather than the normal network (assuming, of course, that the
SPIDER network has been created in the first place) is normally controlled by a
parameter USESPI described above and which may be set in the preferences file
(e.g., SATLOOK0.DAT). However, rather than changing the value of USESPI in
the preferences file, the choice may be made by including the “token” USESPI on
the command line. Hence:
SKIMDIST net matrix USESPI
Requests a distance skim on net.ufs with skimmed output to matrix.ufm but with
the parameter USESPI definitely set to .TRUE. independent of its default value
and/or any value set in the preferences file SATLOOK0.DAT.
Similarly the command:
SKIMDIST net matrix USEUFO
5120257 / Apr 15 15-73

Section 15
Requests the use of a .UFO file for skimming rather than a .UFC file (again
assuming, of course, that both .UFO and .UFC files are available). In this case the
default choice is set by USEUFO as defined within the network .dat file.
Other command line “tokens” include:
♦ USEUFC – use .UFC in preference to .UFO;
♦ NOT_USEUFO – do not use .UFO (and hence equivalent to USEUFC);
♦ NOT_USESPI – do not use a Spider Web network and
♦ NOT_USEUFC – use .UFO instead of .UFC.

These options were first introduced in release 11.1.11 in July 2012.
15.27.8 Post 10.9.17 Skimming Algorithms (NUSKIM = T)

Releases 10.9.17 and beyond include a new set of algorithms to carry out OD
skimming within SATLOOK which should be more cpu-efficient than the older
versions. Essentially they employ a “once-through” algorithm rather than tracing
each O-D path separately.
The new algorithms may be invoked by setting a namelist parameter NUSKIM = T
in the preferences file SATLOOK0.DAT. The default is, provisionally, T.
Alternatively the “preferences” option may be invoked in the command line to
define an alternative “local” preferences file rather than over-writing the “master”
version. For example:
SKIM_ALL net mat PREF mylook0.dat
Substitutes the preferences file mylook0.dat (which should be in the same folder
as net.ufs etc.).
15.28 Variable Program Dimensions

SATURN is available in differently compiled .exe files, each allowing for a different
maximum problem size. The smallest standard array size is version B with
intermediate versions available up to the largest X7 – further details are listed
below:
Array / Level Simulation Junctions Assignment Links Zones
B 500 7,500 400

C 1,000 22,500 800
S 1,500 32,500 1,200
H 2,000 47,500 1,600

K 2,500 60,000 2,000
L 3,000 73,500 2,000
M1 3,500 83,500 2,000
5120257 / Apr 15 15-74

Section 15
Array / Level Simulation Junctions Assignment Links Zones
M2 4,000 93,500 2,000
M3 4,500 103,500 2,000

N1 5,000 112,500 2,000
N2 9,500 120,000 2,000
N3 21,000 200,000 2,000

N4 23,000 200,000 4,000
X7 30,000 250,000 5,750
The above table provides a quick reference guide to the principle variations
between the different licence levels but other constraints – such as the number of
simulation links or turns - will also determine the licence level required to run
specific models.
Beyond Level ‘K’, the number of zones available is capped at 2000 to reduce
excessive memory requirements. If a larger version is required, please contact
Atkins to discuss your specific requirements.
Pre 11.2 several variants of Level ‘N3’ were created to accommodate the suite of
sub-regional models developed by Transport for London with various bespoke
configurations to accommodate their specific requirements. With the release of
11.2, the internal array dimensions were restructured to provide a new Level ‘N4’
to meet all their anticipated requirements but within a much smaller RAM footprint.
Therefore, there may be some issues of backward compatibility for very large
networks using SPIDER Network Aggregation and the standard ‘N3’ will not
necessarily be capable of running the TfL Sub-Regional HAMs and an upgrade to
Level ‘N4’ will be required.
The values of the above dimensions for a particular set of executables may be
established via Help/About in the P1X menu bar or the full set is contained in the
.lpn output files from SATNET.
Note that one particular array dimension, that controlling the maximum size of a
trip matrix within SATALL, may be effectively increased in size by the judicious
use of a parameter SPARSE; see 7.11.12.
Further details on the financial implications of upgrading your existing version are
may be found on the website (www.saturnsoftware.co.uk).
15.29 Comment Cards and Blank Records in Data Files

In theory any ASCII file used as input to a SATURN program, e.g., the .dat file
input to SATNET, may contain comment cards indicated by a ‘*’ in column 1. Any
such records are ignored and the next record read. This complements the use of
‘*’ in the namelist input conventions to indicate comments at the end of a line - see
Appendix A. This convention was first introduced in SATURN 9.1.
5120257 / Apr 15 15-75

Section 15
For network data files comment cards are particularly useful for, e.g., identifying
specific nodes, inserting comments when changes are made (impresses the QA
boyos!) or for “editing out” previous coding.
In practice the convention may not be 100% fool-proof as the new rule has meant
changing every single “read” statement to check for the ‘*’; almost certainly some
will have been overlooked. It should be fairly obvious when this happens - most
likely the program will crash - so the obvious solution is: (a) remove the comment
card, and (b) politely alert your friendly SATURN agent.
The same convention applies to other input ASCII files - in particular, .key files
may have comment lines inserted as may the standard graphics system file
“graf.dat”.
Blank lines in input data files are, generally speaking, handled in the same way as
comment cards, i.e., if read they are ignored and the next record read in its place.
If, on the other hand, they are allowed as input numerical records (see below) they
are interpreted by FORTRAN as a string of zeros.
Their (intentional) use is not recommended at all, in particular since there are
exceptions to the above rule. For example, numerical KNOB data contained on
extra lines in network .dat files may legitimately contain all zero entries and be
correctly represented by a blank line (15.14.5). Equally key files and GRAF.DAT
may contain all-blank records. There may be other examples but we haven’t
thought of them yet!
Prior to 10.5 blank lines were not explicitly detected and could give rise to fatal
errors, e.g., if they were meant to contain node numbers.
15.30 The Use of Sub-Files within Data Files: $INCLUDE

Certain data sections within, e.g., network .dat files allow “sub-files” to be
referenced by inserting a record containing the characters ‘$INCLUDE’ starting in
column 1 followed by a file name which should be read at that point. For example
the sequence:
66666
$INCLUDE metro.bus
99999
in a network .dat file requests the program to read the bus route data from a file
‘metro.bus’.
Note that the filename need not be enclosed in inverted commas, i.e., metro.bus,
not ‘metro.bus’, unlike filenames etc. which are specified within Namelist inputs
(see Appendix A). However, if they are, the ‘s are removed and a warning printed
in the .LP file.
Note that the file “metro.bus” should not contain the opening ‘66666’ record but
should contain a closing ‘99999’ record which indicates only that reading reverts
to the original file at that point. (Strictly speaking the 99999 record is optional as
an end-of-file has the same effect; however the use of 99999 records is strongly
recommended if only to positively affirm that this is the end of the desired data.)
The original file must therefore also contain a ‘99999’ record in the normal way to
indicate the end of a data section.
5120257 / Apr 15 15-76

Section 15
The facility is available within SATNET to read any of sections 1 through 8 in the
network input data files. It is being gradually extended to other programs and/or
files (e.g., counts in SATPIJA, see 13.2.1) and may also be used within Namelist
inputs; see Appendix A.
It may also, post 10.9 be “subscripted” so as to apply to a particular time period
under multiple time period modelling (PASSQ; see 17.4.4) in SATNET. For
example:
$INCLUDE(1) bus1.dat
$INCLUDE(2) bus2.dat
in a network .dat file would indicate that two different sets of bus routes were to be
included in the first and second time periods. See Appendix B.
An example of a network .dat file which makes extensive use of sub-files is given
below:
.....
44444
$INCLUDE 444.DAT
99999
55555
$INCLUDE XY.DAT
99999
66666
$INCLUDE BUS.DAT
99999
77777
$INCLUDE COUNTS.DAT
99999
77777
45 53 52 826 60
32 33 1500 70
* COMMENT
33 34 1600 80
7 8 800 90
99999
77777
$INCLUDE COUNTS3.DAT
99999
There are many possible benefits from using sub-files. For example if you have a
large number of networks in a certain study, all of which have the same co-
ordinates, it is much simpler to update a single .xy file than to update every single
network file when you wish to make changes. Clearly the resulting .dat files use
less disk space as well.
Sub-files may also be created and/or extended interactively using P1X; see
Section 11.9.2.6 and 11.9.2.7.
Finally we note that it is possible – and often highly desirable – to have effectively
the same data appearing in more than one file. For example, data for the same
simulation node may appear in several locations such that one may deliberately
take precedence over another as part of coding alternative scheme and/or
scenarios. See Section 6.15 for advice on using FIFO, TOPUP and DOUBLE
options.
5120257 / Apr 15 15-77

Section 15
15.31 Setting “Optimum” Stage Green Times
15.31.1 Background
A common problem in setting up future-year SATURN networks is to determine
appropriate signal setting parameters. The same problem does not arise with
current networks since, in theory at least, the settings may be observed. However
the easy solution of carrying present day settings forward into the future is clearly
fraught with errors since there is no guarantee that “good” settings for today’s
traffic levels will still be “good” in the future. The same problem also occurs in
present-day networks when network changes are tested.
The two main parameters of concern here are stage green times and offsets.
Cycle times generally have a smaller influence and anyway can be set as a
universal parameter LCY; inter-green times are generally fixed by reasons of
safety etc. The question of setting optimum offsets is discussed in Section 12.2
with respect to SATOFF.
However the problem of determining optimum stage green times is considerably
more complex than that of optimising offsets due to the potentially highly sensitive
feedback between stage times (which affect capacities) and flows. Basically if
one sets optimum green times for a pattern of flow which is in Wardrop
Equilibrium given the “old” green times, those flows will no longer be in equilibrium
since those routes which have been allocated more green times will have become
faster. We must therefore reassign in order to take account of the latest green
times. However this will tend to put more flow down those links that were given
extra green time and therefore, if we re-optimise the green time in accordance
with the new flows, the more heavily loaded links will tend to be assigned more
green time. And more green time tends to mean more flow -a vicious circle is
thereby established.
Considerable research work has gone into the investigation of the “Iterative
Optimal Approach” whereby a loop is established between Wardrop assignment
and signal optimisation using a number of different signal control policies as given
in section 15.31.3. Interested readers are referred to the classic tome on the
subject “Route Choice and Signal Control”, Avebury Press, by Tom van Vuren and
Dirck Van Vliet. Under certain circumstances this approach can lead to
considerable reductions in total travel time, eg up to 20% compared to the initial
(and therefore potentially arbitrary) settings in the base network. However a
closer examination of the process shows that this is often obtained via a process
in which flows and green times move in small steps in consistent directions with
the process only terminating once the stage times reach their minimum values.
Such solutions are also characterised by near “all-or-nothing” flow patterns
whereby very high flow rates with corresponding near maximum green rates occur
on certain well-defined corridors whereas parallel routes are virtually unused.
These solutions argue: (a) a large degree of co-operation between drivers and
signal setters and (b) that drivers can detect and react correctly to very small
shifts in green times.
It is therefore our belief that such solutions are not entirely realistic and may
actually over-estimate the level of performance of a network. Therefore the use of
an optimal iterative strategy must be viewed with extreme caution. See also
15.31.4.
5120257 / Apr 15 15-78

Section 15
On the other hand some reaction of signals to altered flow is clearly necessary.
Perhaps a good compromise for future year networks is to first set signals using
“engineering judgement”, carry out one full assignment followed by a stage time
optimisation and one more assignment (where by “assignment” in this case we
refer to a full run of SATURN with assignment/simulation loops internally).
If the improvements in total network travel time are significant, this procedure
could be repeated, always bearing in mind the possibility of producing unrealistic
flow and green time patterns and even deterioration of overall travel times.
There is another possible need for a fully automated approach; this is the case
where a network is not yet in existence, and initial green times can be determined
to impose a preferred flow pattern on traffic. The traffic engineer then has the
freedom to pursue the iterative loop until the signal settings are found that lead to
the lowest network travel times.
15.31.2 Optimum Stage Times using PIX

In order to optimize stage green times a special option has been included within
the P1X Network Editing options (see 11.9.13) to automatically consider all
signalised junctions and to optimise all green times (using options as detailed
below). This option is to be found within Global Operations on Signals and would
normally be followed by the creation of a new UF file and/or .dat file containing the
updated signal settings.
N.B. This replaces similar options previously available under option 1 of the now
discontinued program SATED
An illustration of a “typical” sequence of programs is given below.
Having re-assigned and re-simulated via SATALL the option of course exists to
loop back through P1X in order to re-optimise the signals - subject to the caveats
expressed in Section 15.31.1.
The optimisation process may also be carried out at selected nodes only
(11.9.13.2).
5120257 / Apr 15 15-79

Section 15
Alternatively, a new “batch procedure” SIGOPT has been introduced in Release

10.8.16 to optimise stage times and/or offsets and which effectively supersedes
both SATED/P1X in terms of stage times and SATOFF in terms of offsets -
described in detail in 15.31.6. Thus, in the above diagram, substitute SIGOPT for
SATED/P1X.
15.31.3 Stage Length Optimisation Algorithms

Five basic algorithms to optimise stage green times are provided:
1) SATURN Equi-saturation.
2) Webster.
3) Delay minimisation.
4) P0.
5) SATURN Equi-saturation Mark 2.
The first is the traditional algorithm provided for many years within SATURN; the
last is a recent modification thereof, while the remaining three were first
introduced in SATURN 9.2, having been converted from versions programmed for
SATURN 8 as part of a research project. They are provided primarily for
experimentation and their reliability cannot be guaranteed. Their choice is
governed by the Namelist parameter MYTVV set in the network .dat files with a
default, post 10.9, of 5 (previously 1).
The basic equi-saturation policy essentially follows the classic Webster approach
of attempting to minimise the maximum volume/capacity ratio by turn by adjusting
green splits. There are therefore only minor differences between options 1 and 2
(which mostly occur in complex situations with lane sharing, overlapping stages,
etc.)
Delay minimisation, as the name implies, attempts to minimise total vehicle-delay
at the intersection. Since it uses analytical approximations to calculate SATURN
delays it will not necessarily lead to a true optimum.
P0 is based on the elegant principle put forward by Mike Smith (University of
York) of equating the product of saturation flow times delay on competing arms.
Again, given the complexities at signals as represented within SATURN, our
version is not necessarily a “pure” application of PO. It differs from the first three
options in that it does not explicitly set out to produce a true local optimum but to
set the signals such that, in conjunction with the consequent re-assignment of
traffic, the total network travel times will be reduced.
Finally equi-saturation Mark 2, as introduced in 10.1, has the same general
objective as 1 but uses a different algorithm to achieve it. Experience to date is
limited; certainly in certain situations it performs much better but whether there are
other situations where it performs worse is not yet certain. Nonetheless it is
recommended over 1.
Each algorithm follows an iterative strategy whereby green time is “swapped”
between the “best” and “worst” stages, with the amount of green time swapped
being the (local) optimum. After each swap the best/worst criteria are recalculated
5120257 / Apr 15 15-80

Section 15
and the next pair identified. While fairly reliable, such an approach is not
guaranteed to produce a global optimum; under certain circumstances the
algorithm may “stick” and the apparently best pair for swapping may not in fact
lead to any improvement. For this reason the maximum number of iterations is
user-set in order to prevent infinite loops.
Further “outer” iterations may also be required since, once new stage times have
been generated, a re-simulation of that node may change some of the criteria on
which the optimisation was based; e.g. lane sharing may change. A further (user-
set) option specifies the maximum number of outer iterations allowed (default 1
since in most cases a re-simulation and re-optimisation has no effect).
Finally it should be noted that the optimisation procedures all assume that stage
times are defined by integer seconds as opposed to being continuous variables.
Again this implies that the solutions are not “true” global optima, but equally
means that they may be insensitive to small changes in junction parameters (e.g.
flows) and therefore they converge more rapidly.
15.31.4 Using SIGOPT (and/or SATOFF) within SATALL

As an alternative to optimising stage green times outside the
assignment/simulation loop as discussed in 15.31.2 it is also possible to do so
within the loop using SATALL. Thus setting the parameter SIGOPT = .TRUE in
(preferably) the original network .dat file or in the SATALL control file results in a
“two pass” simulation process within the standard loop. Thus on the first “pass”
the simulation uses the current stage green times and the latest assigned flows; it
then updates all stage times at signalised junctions independently and re-runs the
simulation in a second pass. Statistics describing the degree of changes to the
green times appear both on the screen and (in greater detail) in the .LPT file.
Note that the option SIGOPT automatically optimises all nodes; there is, as yet,
no option to optimise over a subset of signals although this can be done using the
batch procedure SIGOPT described in 15.31.6 below.
Equally the offsets can be automatically optimised within each simulation by
setting SATOFF = T – or offset optimisation could be done on its own by setting
SIGOPT = F and SATOFF = T (but, see below, this is not recommended).
The choice of optimisation algorithm 1 to 5 above is set by the parameter MYTVV
as set in &PARAM either in the SATNET .dat file or in the control file to SATALL.
It needs to be emphasised that this procedure is largely experimental and we
have very little experience so far to compare the results from the above procedure
from that using the explicit SATED-SATALL loop. Since the updates are more
frequent in SATALL - one per loop - one might expect to find “better” signal
settings and lower travel times using this method - but life is not necessarily
straight forward with network models! However using SIGOPT = T within
SATALL is likely to lead to over-estimates of network performance as noted in
15.31.1 and it should therefore be used with some caution and only if the resulting
signal times and flows are carefully analysed for “realism”.
The same note of caution should also be applied to the use of SATOFF = T within
SATALL. In particular, since the optimum offsets are most sensitive to link cruise
times which are (generally) fixed as opposed to turning delays which may vary
5120257 / Apr 15 15-81

Section 15
considerably with iterations of SATALL, the optimum offsets per node may only
change once within SATALL and the same result could be obtained by using the
program SATOFF on its own. Using SATOFF = T on its own within SATALL with
SIGOPT = F has even less to recommend it.
N.B. Optimising stage times (in particular) and/or offsets may lead to significant
improvements in the overall convergence of the assignment-simulation loops. See
Section 9.1.5.
15.31.4.1 NIPS
On the other hand, using the parameter NIPS to limit the number of times the
signal and/or offset optimisation within SATALL is called is STRONGLY
recommended. See 9.12.2. A value of 2 or 3 is recommended.
15.31.5 Preserving and Transferring New Stage Times

Having created new stage times (and/or offsets) by any of the above methods it is
natural to wish to include that information within a network .dat file. The best way
to do that is to use the Network Editing facilities within P1X and, in particular the
update option described in 11.9.13.2 and/or rgs files as described in 11.9.14.
Alternatively, the batch procedure described in 15.31.6 has options to output an
updated .dat file automatically.
Once an updated .dat file has been created you may wish to re-run SATURN
“from scratch” with the signals and/or offsets fixed at their optimal values. Before
you do so be careful that parameters such as SIGOPT or SATOFF have all been
“turned off” within the new .dat file. Also note that the “from scratch” results may
not be identical to those previously obtained since the new run may follow a
slightly different “convergence path” and wind up with slightly different results; only
with perfect convergence (unobtainable) would this problem would not arise.
15.31.6 The Batch Procedure SIGOPT

A new “batch procedure” SIGOPT.BAT has been introduced in Release 10.8.16 to
optimise stage times and/or offsets in a .ufs file and to create a new output file(s).
It effectively supersedes both P1X in terms of stage times and SATOFF in terms
of offsets. Output files may be either (a) .UFS, (b) .DAT and/or (c) .RGS
SIGOPT makes use of existing routines within P1X but runs in a non-graphical
non-interactive mode such that it resembles any other batch-mode program. It is
called via:
SIGOPT net KR control KP fildat
where control.dat (optional) is an ascii file which sets various options, filenames
etc. via Namelist and may also contain a list of selected nodes for optimisation.
The full list of parameters with their defaults is listed below.
Fildat (optional) specifies the name of an output (.dat) file containing the revised
network .dat file. Fildat may equally be specified as a Namelist parameter within
control.dat.
Note that if the input network file net.dat references $INCLUDE files within the
11111 records then the output file fildat copies these files directly into the new
5120257 / Apr 15 15-82

Section 15
11111 records; the $INCLUDE files may be recreated – and potentially renamed –
using text editing cut’n’paste. See 11.9.2.1.
The filenames for a new .ufs file and – optionally - a new .dat file must be explicitly
set within control.dat but that a file net.rgs is always output with its filename fixed
by the input network net.ufs.
PARAMETER TYPE DEFAULT FUNCTION NAME
SIGOPT LOGICAL .TRUE. If .TRUE. optimise green times
SATOFF LOGICAL .FALSE. If .TRUE. an offset optimisation is carried out
prior to green time optimisation
SELECT LOGICAL .FALSE. If .TRUE. read a set of selected nodes to be
optimised from this file immediately after
&END; see also 11.9.13.2
RESIM LOGICAL .FALSE. If .TRUE. a complete simulation is carried
out prior to the output of .ufs file
MYTVV INTEGER 1 Stage time Optimisation algorithm –

See 15.31.3
NOPMAX INTEGER 1 Maximum number of internal iterations used

by the signal setting routines; see 15.31.3
MANOFF INTEGER 0 The signalised simulation node number used

as the reference point for all optimum offset
set by SATOFF. See 12.2.3.
FILDAT CHARACTER Blank Defines an output .dat file

FILUFS CHARACTER Blank Defines an output .UFS file
RECORD(S) 2 – Selected (Signalised) Nodes

One node number per record in free format terminated by 99999 to select a
subset of nodes to be optimised for both stage times and/or offsets.
15.31.7 Using SIGOPT for Base Year Networks

In principle there should be no need to run signal optimisation for base-year
networks where the stage times should be directly obtainable from observation
and, one would hope, SIGOPT would give very similar times with very little
improvement in travel time. However, it may be a very useful
“calibration/validation” exercise to check that this is indeed the case since large
deviations between observed and “optimised” stage times at an individual node
might well be a very good indication that there is something wrong, e.g., that the
node has been miscoded or that the assigned flows are well out, etc. etc.
15.31.8 Convergence Statistics for Signal Optimisation

Whether or not the green splits at signals have actually been optimised it is
possible to calculate the maximum possible improvement in the V/C ratio per turns
at signalised nodes. These calculations are carried out at the end of every run of
SATALL and the improvements per node are saved on the output .UFS files as
5120257 / Apr 15 15-83

Section 15
well as the maximum time change per stage in order to achieve optimisation. The
.LPT file contains a global summary of the potential improvements.
In addition it is also possible within the P1X Convergence Menu (11.15) to list the
10 nodes with the maximum potential V/C improvements and to highlight them.
Note that those nodes with poorly set stage times are also likely to be the same
nodes that cause convergence problems for the assignment-simulation loops and
therefore optimising those signals may significantly improve overall convergence.
See note 9) in 9.1.5.
15.32 Determining Fuel Consumption

Fuel consumption is an area of major concern to traffic engineers for obvious
reasons. It is also an area which, as with emissions (15.33), is probably best
handled “post processing”; i.e., users will have their own particular favourite model
or formulae for fuel consumption which will require both data from SATURN such
as flows and/or speeds and exogenous data such as graphs of fuel consumption
vrs. speed. In such cases the best option is to dump the required SATURN data
into, say, a link-based text file using SATDB and to pass that data into their own
procedures. (Or it may also be feasible for users to set up their own equations /
calculations using the data manipulation facilities within SATDB (11.10.8.1))
However there are also internal fuel consumption models within SATURN. Thus,
in order to estimate the total amount of petrol consumed within the simulated
network, SATURN uses the following equation:
=f FLPK ∗ d + FLPH ∗ t + FLPPS ∗ s1 + FLPSS ∗ s2
where:
f = fuel consumption in litres
d = total travel distance in vehicle-kilometres
t = total delayed (idling) vehicle-hours
s1 = total number of ‘primary’ or ‘full’ stops at an intersection; e.g. where a vehicle
arrives at the end of a queue
s2 = total number of ‘secondary’ stops; e.g. stop-starts while a vehicle moves up
in a queue
and the “weighting” parameters FLPK etc. have been assigned default values as
follows:
FLPK = 0.07
FLPH = 1.2
FLPPS = 0.016
FLPSS = 0.005
These parameters were all chosen as appropriate figures for an ‘average’ British
car in 1981. More details may be found in Ferreira. (“The role of comprehensive
5120257 / Apr 15 15-84

Section 15
traffic management in energy conservation”, PTRC Summer Annual Meeting, July

1981).
Clearly these figures are now out-of-date and take no account, for example, of
the breakdown of the flow into various vehicle types. The parameters may be
user-set as standard namelist parameters within SATNET.
15.33 Determining Emission Statistics

Emissions of harmful pollutants from road traffic are an increasingly important
issue for engineers, planners and politicians alike - not to mention the general
public who have to live in it! It is also an extremely complicated process, both in
terms of actual emissions (e.g., variations between vehicles) and their ultimate
dispersion and chemical reactions.
Predicting emissions is, as with fuel consumption (15.32), probably best handled
“post processing”; i.e., users will have their own particular favourite model or
formulae for calculating emissions which will require both data from SATURN
such as flows and/or speeds and exogenous data such as meteorological data. In
such cases the best option is to dump the required SATURN data into, say, a link-
based text file using SATDB and to pass that data into their own procedures. (Or
it may also be feasible for users to set up their own equations / calculations using
the data manipulation facilities within SATDB (11.10.8.1))
Alternatively, in order to encourage the consideration of pollutant emissions,
SATURN contains some fairly simple-minded internal procedures for the
estimation and display of five standard pollutants: carbon monoxide, carbon
dioxide, hydrocarbons, nitrogen oxides and lead. The estimation procedures are
similar to those used to estimate fuel consumption, i.e. a linear model with
explanatory variables of time, distance, primary and secondary stops. Hence the
basic equation for the emission of pollutant i from a link is:
E i = ( a1i d + a2i tc + a3i tq + a4i s1 + a5i s2 ) V
where:
d is link distance
tc is average cruise travel time on the link
tq is the time spent “idling” in queues at junctions
s1 is number of primary stops per vehicle
s2 is number of secondary stops per vehicle
V is the vehicle flow
ai1, ai2... are (user-set) coefficients.
It needs to be emphasised that this is an extremely crude model. Moreover the

default coefficients given below are even worse! If it gets to within an order
magnitude of the “true” answer it will be doing well. The main reason for including
it at this stage is to provide, for examples, options in P1X to display emissions per
link or options in SATLOOK to print totals. Improved models with more reliably
5120257 / Apr 15 15-85

Section 15
calibrated coefficients will undoubtedly follow and users are strongly encouraged
to put forward their own models.
Default parameter values for four of the pollutants (excluding CO 2 ) have been
extracted (with some fairly broad brush assumptions; e.g. that a primary stop
involves a deceleration from 50 kph to rest and the reverse acceleration) from the
data used in the 1988 Leeds PhD dissertation of Athanasios Matzoros (see also A
Model of Air Pollution from Road Traffic I and II, A. Matzoros and D. Van Vliet,
Transportation Research, pp.315-335, Vol 26A, 1992). Default values are listed
below.
Grams / PCU / Kilometres Cruise Idling Primary Secondary

Hour Hour Stop Stop
Carbon dioxide 70.0 0.00 1200.00 16.000 5.000
Carbon monoxide 0.0 304.80 180.00 2.22 0.444
Nitrogen oxides 0.0 102.60 1.80 0.42 0.084
Hydrocarbons 0.0 57.00 30.00 0.39 0.078
Lead 0.0 0.36 0.09 0.0024 0.0005
Carbon dioxide parameters are extracted from the fuel consumption parameters
on the assumption that “most fuel” is converted into carbon dioxide.
Parameter values may be reset by users using the namelist inputs to SATNET
within a network .dat file. See Section 6.3.3; all parameters are “reals”. Their
names are constructed using the following conventions:
♦ All names commence with the characters CO, CO2, XNO, HC or PB.
♦ The next character is a P (for “per”).
♦ The final characters are K (for kilometre), CH (for cruise hour), IH (for idling
hour), PS (for primary stop) or SS (for secondary stop).
Thus HCPCH is the variable denoting hydrocarbons emitted (units of grams) per
hour cruise time per pcu.
15.34 Estimating Primary and Secondary Stops

While the simulation element within SATURN does not explicitly model the exact
progression of every vehicle as they move down a link it is possible to infer certain
properties of their progression. Thus SATURN estimates the number of times on
each simulation link that vehicles execute primary and secondary stops.
The distinction between the two forms of stop is basically the following. Imagine a
minor arm at a priority junction with a “stop sign” at the end; every vehicle
approaching that junction should (must!) come to a complete stand still either at
the stop line (if there is no queue) or behind the last vehicle in the queue; that is a
primary stop. If there is a queue and vehicles depart from the head of the queue
one at a time then vehicles further back will move up by accelerating and then
decelerating to a stationary position; these are secondary stops.
5120257 / Apr 15 15-86

Section 15
Clearly this two-way split does not exactly represent all possible vehicle
movements in a queue but it may well be sufficiently good for estimating
secondary parameters such as fuel consumption or emissions and for providing a
very broad description of the state of a junction.
The rules for estimating primary and secondary stops are, like their definitions,
somewhat arbitrary. Thus for minor arms at priority junctions all arriving traffic
must make a primary stop if its turn is over capacity or if the queue per lane is
greater than 2. If the queue per lane is (in the limit) zero the probability of a
primary stop is equal to the calculated probability of there being no gap. For
queues per lane between 0 and 2 pcu’s a linear relationship is assumed.
Secondary stops are calculated by assuming that all primary stops make a further
number of secondary stops equal to the queue length per lane divided by the
number of vehicles that can depart from the stop line “in a platoon” once a gap
occurs (assumed equal to one over the probability of a gap).
Roundabouts are treated in the same way as minor priority arms.
For major priority arms secondary stops are ignored and a primary stop only
occurs if the arm is over capacity or if, at the moment of arrival, the expected
queue length per lane is greater than 1.
At signals all arrivals primary stop during a red phase or, during the green phase,
if the expected queue is non-zero. Secondary stops occur whenever the lights go
red to all vehicles in the queue at that instant.
15.35 Altered Data Formats in .DAT Input Files

Generally data input files to SATURN programs are “formatted”, meaning that
repeated numerical data needs to be in fixed fields or sets of columns with a
specific number of decimal places, etc. See Section 2.8.1. These are specified by
“format statements” set within the program but which, as explained here, may also
be altered by the user.
An example taken from the buffer-network data input to SATNET, see 6.6, is
given below. Thus the first line specifies a buffer link from node 23 to node 22 in
the standard format. The line FORMAT (3F7.1... requests a new format, the
basic change being that the 3F7.1 implies that the three input fields following the
A-node and B-node occupy 7 columns with 1 decimal place as demonstrated by
the next data line for link 20 to 21. A line with characters FORMAT in columns 1
to 6 but blank thereafter causes the format to revert to its default.
23 22 28 56 2500 2 1000 2.19 125
FORMAT (3F7.1,2X,I1,A1,1X,F5.0,F5.1,2X,I3)
20 21 28.1 56.1 2500.2 2 1000 2.19 125
FORMAT
20 21 28 56 2500 2 1000 2.19 125
In principle the change of format facility could be applied almost anywhere: in

practice it has only been programmed in a very few places, including the buffer
network inputs illustrated above. In this case it has been done to make the data
generated under the SATBUF conversion procedure (see 15.8.2) accessible to
SATNET. Further extensions are planned.
5120257 / Apr 15 15-87

Section 15
The advantages of being able to change formats are mostly associated with the
ability to import data from other suites of programs with formats which do not
coincide with those of SATURN. Another example of the same basic principle is
the parameter XYFORM used by SATNET; see 6.3.4.
It should also be stressed that very often data may be read in a variety of forms,
provided that it appears within the column boundaries set, and that therefore the
formats specified within the Manual may not need to be absolutely strictly adhered
to. For example, the format specified in order to read in the “power” for a buffer
link speed flow is specified in Section 6.6 as FORMAT F5.1, implying that a single
digit appears after the decimal point and that the decimal place must appear in
column 39. In practice, since FORTRAN compilers are “forgiving” in terms of input
formats, the decimal point may appear in any column with any number of digits
following provided that the whole input appears in columns 36-40. Thus inputs of ‘
3’, ‘ 3.0’, ‘3.123’ will all be correctly read.
In addition, certain inputs which are specified as Integers, e.g., link times and/or
speeds with buffer link records, may generally have decimal places included,
again with the proviso that the full input appears within the strict column limits.
15.36 Turning Flows at Buffer Nodes

Although SATURN does not explicitly differentiate between different exit turning
movements from a buffer link in calculating minimum cost routes (unlike the
simulation network) when the O-D trips are assigned to paths through the buffer
network they do implicitly go through turns and the resulting turn flows may
optionally be saved.
To calculate and store buffer turn flows you must have both parameters SAVEIT
and REFFUB (which, if you think about, has a rational explanation!) as .TRUE on
entry to SATALL (the facility is not available in SATEASY). The turning flows are
calculated by carrying out a final full assignment using the iteration costs stored
on the ufc files (see 15.23) and the resulting flows stored in DA array 4953 on the
output .ufs file. These may subsequently be accessed using option 2 (look at
individual buffer nodes) within SATLOOK (11.11.2).
Note the following points:
1) Bus routes through the buffer network clearly also make turns; if there are
any such bus routes their (pcu) turn flows are calculated within SATNET and
stored in DA array 943. These are then added to the assigned flows in 4953
which therefore contains total pcu flows.
2) The same treatment is not applied to pre-loaded flows (but see note 4
below).
3) In multiple-user-class assignment all user classes are combined together in
array 4953.
4) Since, as explained in 15.23, the routes re-calculated via SAVEIT may be
only an approximation to the true routes used in the assignment (due to the
effects of DIDDLE or KOMBI for example) the turning flows are “furnessed”
so that the total exit and entry flows on each arm correspond exactly to
5120257 / Apr 15 15-88

Section 15
those assigned. This procedure would also account for any “missing” turn
flows due to pre-loaded flows.
15.37 Repeated Assignments: Modelling Cold Starts, etc.

The SATRAP option within the Assignment/Tree Building sub-menu within
SATDB repeats a full assignment to the same routes and in the same proportions
as in the final assignment (or, strictly speaking, the final assignment as re-created
under SAVEIT - see 15.23). Thus re-assigning the original trip matrix should give
the same (demand) link flows as already stored on the .ufs file. So why bother?
Firstly, SATRAP allows the user to investigate the impact of assigning a different
trip matrix to the same routes. One of the sub-options within SATRAP allows the
user to modify the matrix using random numbers in order to model the impacts of
day-to-day variability.
A further option allows the user to assign trips over only a section of the O-D
routes defined in terms of distance. For example you may ask for only the first (up
to) 500 metres from the origin to be loaded, the obvious application of which is to
model vehicle flows when the engine is still cold. Alternatively the flows may only
be loaded beyond, say, 500 metres, to represent warm vehicle flows. Adding the
two together gives total flows. In the case of the critical distance falling in the
middle of a link along an O-D path (as in fact must virtually always occur) the
loaded flow is taken pro-rata depending on the length of that link.
15.38 Non-discontinuous Speed-Flow Curves: the Kinky Option

Generally, as described in Section 5.4 and elsewhere, SATURN speed-flow or
cost-flow curves are assumed to follow a power law for flows up to capacity and to
be linear thereafter; equations (5.1a) and (5.1b) respectively. Thus there is a
discontinuity in the slope introduced at V=C (although the times or costs
themselves are continuous). Generally the discontinuity does not create problems
within the assignment algorithms and the shift to a linear form is quite realistic
particularly bearing in mind that a power-law curve with, say, power 5 goes very
rapidly towards infinity for V>>C, a not very realistic forecast which can have
serious consequences for scheme benefits.
However there may be circumstances when the user does wish to extend the
simple power law relationship over flows from zero to infinity, for example in
modelling networks with so-called “BPR curves” or when doing system-optimal
assignment where the discontinuity in slope may be an algorithmic problem (see
7.11.9). This is simply done by setting a parameter KINKY to .FALSE in the
network .dat file (or in control files elsewhere) in which case equation (5.1a) holds
over the full range of flows for “actual” times and (7.19a) holds for the full range of
marginal costs.
The default is .TRUE. and, it needs to be stressed again, the alternative should be
used with great caution. In particular it is not recommended to use with KINKY =
F with simulation networks. In addition, if KINKY = F, then care should be
exercised that parameters that control the power of cost-flow curves such BCRP
or PMAX should be less than or equal to 5.0.
5120257 / Apr 15 15-89

Section 15
In general KINKY = F should only be used in research-based applications and,

even then, for very specific purposes. For example, it may be useful in studies of
system optimal assignment and system optimal tolls; see 7.11.9.
Note that KINKY applies to all cost-flow curves, i.e. both buffer as input and
simulation as calculated.
15.39 Bus-only Lanes

Bus-only lanes in SATURN represent extra lanes along simulation links which are
for the exclusive use of public transport vehicles as coded under the 66666
network data records (6.9). The format specification for identifying bus lanes and
whether they are “nearside” or “offside” are given in Section 6.4.9.2.
15.39.1 Flows in bus lanes

Bus flows on a link are assigned to a bus lane – and are therefore removed from
“normal” traffic – but only if certain criteria based on the next link in the route are
satisfied. Two sets of acceptance criteria are applied: the first is fairly obvious but
may be overly strict so that a second rule has been added.
Thus, rule 1, for a nearside bus lane, if a bus route makes a turn at the
downstream end of the link which is allowed to use lane 1 (given the input
turn/lane specifications on that link) then it is allocated to the bus lane; otherwise it
is assumed not to use the bus lane. Thus, for example, a bus route which turns
right (drive on the left) at the end of a link would not be able to use a nearside bus
lane if the normal right turns were only allowed from lane 2. Similarly an offside
bus lane may only be used by a route whose exit turn uses the highest (most
offside) lane; e.g., left-turning buses would be excluded from an offside bus lane.
The second rule, termed the “1+1 rule”, relaxes the above criteria by increasing
both the critical lane and exit turn by 1. Thus, if a bus route takes the second exit
from the nearside and if that turn can use the second lane then that route may
use the nearside bus lane on the link. For example, a bus which is going straight
ahead (second turn) at a 4-arm junction may use a nearside bus lane if ahead
traffic can use lane 2.
Similar rules apply to offside bus lanes but in reverse.
At the moment the model does not fully consider the “continuity” of nearside and
offside bus lanes in allocating buses to bus lanes. Thus buses on a nearside bus
lane on link AB may transfer seamlessly to an offside bus lane on link BC and
back again to a nearside lane on CD. Furthermore it is not, for example, possible
to restrict bus lanes to certain “companies” or to require that only trams may use
offside lanes.
N.B. The above rules were only added in release 11.1. Prior to that all bus
flows were assigned to a bus lane if one were available.
15.39.2 Delays in Bus Lanes

Note that a bus lane in SATURN is assumed to go from the upstream “entry line”
to the downstream “stop line”; set-back bus lanes are therefore excluded. In
addition buses in bus lanes form separate queues and therefore have different
5120257 / Apr 15 15-90

Section 15
delays from “normal” traffic making the same turning movement. In effect we
assume that the exclusive lane continues through the junction to the next link’s
entry line - where it may, of course, meet up with a further bus lane.
More specifically the delay to a turn from a bus lane is equated to the minimum
delay associated with normal turning traffic; i.e. t 0 in equation (8.5a). Moreover
this delay is fixed, independent of the volume of traffic in the bus lane. Travel
time/speed along the link itself equals the cruise time for normal traffic and the
same link distance is assumed.
Clearly this model is only an approximation which will hopefully be improved with
later versions of SATURN. It does however include the two most salient features
of such bus lanes; i.e. that buses should incur lower queues and delays than other
traffic and, perhaps more importantly, that buses in an exclusive lane do not
reduce the capacity of other traffic on the same link.
15.39.3 Exits/Entries from Bus Lanes

At the start of a bus lane the bus traffic effectively leaves at the upstream end so
that: (a) its flow is an integral part of the previous turn (unless of course this is the
start of the route); and (b) its flow is not included as part of the normal flow on the
link. At the termination of a bus lane the buses rejoin normal traffic upstream on
the following link so that (a) it is not part of the final turn flow but (b) is part of the
next link flow.
In some respects bus lanes may be thought of as “tunnels” in that, as far as the
rest of the traffic on the network are concerned, buses “disappear” at the
upstream start of a sequence of bus-lane links and only “reappear” at the
upstream end of the first non bus-lane link.
Information on flows to, on and from bus lanes may be obtained via SATDB
(11.10.6) with up to 15 levels of flow definition available. In addition a table in the
.lpn file output by SATNET lists similar information on all links with bus lanes.
15.40 Motorway Weaving Segments
Weaving segments on motorways correspond to the situation depicted in the
diagram below (Figure 15.4) whereby an entrance ramp onto a motorway is
followed by an exit ramp downstream such that traffic entering the motorway and
staying on it (Flow 2) will need to “weave” with traffic which is already on the
motorway but wishes to take the next exit (Flow 3). This will lead to a reduction in
the capacity of the middle segment of the motorway if the fraction of traffic which
weaves is high and/or the distance between entry and exit is relatively short.
5120257 / Apr 15 15-91

Section 15
Figure 15.4 - Fig 2/7 from DMRB Vol. 6, Sect 2, part 1
In these situations SATURN uses formulae derived from DMRB (Design Manual
for Roads and Bridges) recommendations to reduce the saturation flow (and
hence the capacity) of the link (or links) comprising the intermediate segment.
N.B. The treatment below only applies to links coded as part of the simulation
network, not buffer. In addition it need not apply only to “motorways” (SATURN
normally does not know whether a link is motorway or not), although in practice
the required geometry of entries and exits is most likely to occur with motorways.
In addition it may not be used if the assignment is based on either path-based
assignment, OBA or multi-core. In principle it could but it hasn’t been coded;
requests to DVV.
15.40.2 Basic Background Theory

Paragraph 2.26 in DMRB Volume 6 Section 2 Part 1 TD 22/92 gives a formula for
the number of traffic lanes required for weaving:
Equation 15.3

1  Lmin 
=
N r Qnw + Qw1 + Qw 2  2 + 1 

D  Lact 
Where:
Nr = Number of traffic lanes required
Q nw = Total non-weaving flow in vph
Q w1 = Major weaving flow in vph
Q w2 = Minor weaving flow in vph
D = Maximum mainline flow in vph per lane, refered to as S below.

L min = Desirable minimum weaving length
L act = Actual weaving length available (in metres) (referred to simply as L from
now on)
5120257 / Apr 15 15-92

Section 15
(where L act is assumed to be greater than L min and, if not, take L min = L act such
that the factor within the bracket multiplying Q w2 = 3.)
In SATURN we need to “invert” this equation since the actual number of lanes
provided N a is already specified by the SATURN input along with its “natural”
saturation flow (which determines capacity) and what we need to know is how
much the saturation flow/capacity is reduced by the effect of weaving.
Thus we begin by factoring all the flows Q in Equation 15.2 by a uniform factor F
such that the required number of lanes given by Equation 15.2 equals the number
of actual lanes N a ( i.e., F.Q… are the flows at capacity) :
Equation 15.4
F ( Qnw + Qw1 + X f Qw 2 ) =
Na S
Where:
F = required factor
S = the saturation flow per lane as input by the user and ignoring any effect of
weaving (replacing D in Equation 15.2)
Xf = the extra weight associated with the minor weaving flow (= 2L min /L act + 1)
Furthermore at capacity the total unweighted flow should also equal the actual
number of lanes times the effective saturation flow Se:
Equation 15.5
F ( Qnw + Qw1 + Qw 2 ) =
N a Se
Let Qw = Qnw + Qw1 + X f Qw 2
Hence from Equation 15.3

Equation 15.6
S
F = Na
Qw
Subtracting Equation 15.4 from Equation 15.3 gives:

Equation 15.7
Qw 2 F ( X f −=
1) N a ( S − Se )
whence:
Equation 15.8
Qw 2 F ( X f − 1)
Se= S −
Na
and substituting F from Equation 15.5 into Equation 15.7 gives
5120257 / Apr 15 15-93

Section 15
Equation 15.9
 Qw 2 ( X f − 1) 
=
Se S 1 − 
 Qw 
Hence the saturation flow is reduced by a factor W:

Equation 15.10
Se Qw 2 ( X f − 1)
=
W = 1.0 −
S Qw
which may be more simply and intuitively written as:
Q
W=
Qw
where Q = Q nw + Q w1 + Q w2 .
Note that in the “worst possible case” when X f takes its maximum value of 3.0 and
Q nw = 0, Q w1 = Q w2 then the reduction factor W = 0.5 which might be thought a bit
extreme. Various alternative formulations have been proposed as discussed next.
15.40.3 Extensions and Alternatives to the Basic Theory

A further “feature” of the above model not mentioned above is that the reduction
factor is assumed not to apply for weaving lengths in excess of some value L max
(typically 3 km.) This will introduce a discontinuity into the multiplier of Q w2 , X f , in
that it jumps from a value of (2L max /L min – 1) > 1 at L = L max to 1.0 at L>=L max .
Recall that the maximum value of X f is 3.0 at L <= L min .
Two alternatives have been suggested (in addition to retaining the discontinuity):
(i) Reducing X f by a constant amount throughout such that it goes smoothly to
X f (L max ) = 1.0 and is 1.0 beyond.
(ii) Assume that X f (L) is a linear function between L = L min and L max going from
3.0 down to 1.0.
More specifically under assumption i) we introduce a correction factor equal to the
“normal” value of X f at L = L max less its desired value of 1.0:
Equation 15.11
Lmin
C = 2.0
Lmax
Hence the full formula for X f (L)is:
5120257 / Apr 15 15-94

Section 15
Equation 15.12
 Lmin
3.0 − 2.0 L L < Lmin
 max
 L L 
X f ( L )= 1.0 + 2.0  min − min  Lmin < L < Lmax
  L Lmax 
1.0 L > Lmax


Method ii) may be written:

Equation 15.13
3.0 L < Lmin


X f ( L )= 1.0 + 2.0
( L − Lmax ) Lmin < L < Lmax
 ( Lmin − Lmax )
1.0 L > Lmax

Having established X f (by whatever method) an alternative method for establishing
the capacity reduction factor W is to use the formula (as proposed by Philip
Barrett of HKBR):
Equation 15.14
 Qw 2 ( X f − 1) 
=W 1.0 / 1.0 + 
 Qw 
 
Which, to a first approximation, is the same as Equation 15.9 for small corrections
but is less severe as the effect increases, e.g., as Q w2 increases. Thus, whereas
Equation 15.9 gives a maximum reduction (minimum W) of 0.5 Equation 15.13
gives 2/3 under the same conditions.
A final extra “rule” is to set a minimum value on the capacity reducing effect of
weaving traffic by requiring that, say:
Equation 15.15
W ≥ Wmin =
0.75
Which, or which combination, of the above approaches is preferable is very much

in the eye of the user. There is very little empirical evidence to say that this
equation is “right” and that is “wrong” - what SATURN is doing is providing a set of
approaches which have been proposed (by experienced modellers!) and let the
user decide. And if the user has an alternative approach it should not be too
difficult to include alternative formulae within the programs.
15.40.4 Application within SATURN

To apply capacity reductions due to weaving within SATURN users must (a) set
various parameter values as used in the above equations (strictly speaking
5120257 / Apr 15 15-95

Section 15
optional as default values are provided), and (b) identify those links where
weaving occurs.
15.40.4.1 Network Coding: the W link marker

We note first that a weaving section may consist of either a single link as
illustrated in Figure 15.4 connecting the node with the “on ramp” to the node with
the “off ramp” or (less frequently) a series of (essentially one way) links
connecting the “on” and “off” nodes as illustrated in Figure 15.5.
Link identification is accomplished by coding a W within the 4 columns of the
simulation link record normally used to specify the number of lanes, i.e., columns
12 to 15 (see Sections 6.4.1 and 6.4.9.4). Thus 3W or W3 would both denote a 3-
lane link where weaving takes place.
Note that the link where the W is added is the middle link in the weaving section
(provided that there is only one intermediate link) and that nothing needs to be
added on either the links which enter the weaving segment or that exit (e.g., entry
and exit ramps). On the other hand if there are multiple intermediate links as in
Fig. 15.3 then a W must be added for all those links, otherwise a non-fatal error
results and the weaving movement is ignored.
15.40.4.2 Network Geometry

In either case a number of geometrical conditions need to be satisfied.
Figure 15.5 - A weaving section with intermediate links
Thus the “on” or “upstream” node will (normally) be a 3-arm priority junction with 2
one-way in-bound links feeding a single one-way out-bound link; i.e., in-bound
motorway and in-bound ramp feeding the out-bound motorway. In more precise
geometric terms there must be only one permitted turn from the entry ramp link -
the first geometrically possible turn - and only one permitted turn from the
“motorway” - the second geometrically possible turn - so that both have the same
exit arm. Thus one cannot have an exit from the motorway onto the ramp arm -
entry and exit ramps must therefore be defined at distinct nodes.
Equally the “off” or “downstream” node will also be a 3-arm priority junction with
one one-way in-bound arm feeding two outbound one-way arms. The entry
(motorway) arm must have both its two possible turns defined - the first to the off
ramp, the second continuing along the motorway and the off ramp link must be
one-way out-bound.
In practice both the on and off nodes will be 3-arm priority nodes as described
above. However, strictly speaking, the nodes may have more than 3 arms as long
as the extra arms and turns do not interfere with the required geometry. For
5120257 / Apr 15 15-96

Section 15
example the nodes could include both the entry and exit ramps on either side of a
motorway with the two motorway arms being two-way but the turns on one side of
the motorway could not cross those on the other side. In general such coding is
not recommended, particularly if weaving is being modelled: each direction of the
motorway should contain distinct nodes and links.
If there are one or more intermediate nodes such as nodes 11 and 19 in Figure
15.5, then each should be essentially a two-arm priority with a single one-way exit
feeding a single one-way exit. (Such nodes might be added in order to provide
“shape” to the network although, it should be noted, the “shape” may also be
obtained via a GIS file; see 5.7).
15.40.4.3 Assignment Calculations

The methods by which the required entry exit flows are monitored with an
assignment differ depending on whether not Network Aggregation (15.56) is
invoked or not (SPIDER = T or F).
Thus, if Network Aggregation is not invoked (SPIDER = F), the 4 demand entry-
exit flows which make up the weaving segment (two possible entries and two
possible exits) are continually monitored while the assignment is taking place and,
at the end of the assignment and prior to the next simulation, that information is
used to calculate the reduction factor as described above. (Strictly speaking only a
single flow is monitored since the other 3 flows may all be obtained knowing the
total demand flows on the entry/exit arms.)
On the other hand, if SPIDER = T and if all the nodes within the weaving segment
(e.g., nodes 10 to 20 inclusive in Fig. 15.5) are aggregated then all the possible
weaving movements 1-3, 1-4, 2-3 and 2-4 will either be distinct aggregated links
or part of larger aggregated links. In either case the necessary flows may all be
taken directly from aggregated link flows and no extra steps are required during
the assignment itself. The method is therefore much more efficient and
significantly faster in terms of CPU.
For additional discussion on aggregated networks see 15.56.7.4.
15.40.4.4 Simulation Capacities

Within the simulation the reduction factor is applied to the saturation flows for all
turns out of the “motorway” links coded as W. Thus, in Figure 15.5, it would be
applied to turns 10-11-19, 11-19-20, 19-20-3 and 19-20-4. It would not, however,
be applied to the turns corresponding to entry into the first weaving link (i.e., turns
2-10-11 and 1-10-11 in Figure 15.5)
The factor is, in effect, applied immediately after the saturation flows are set and
at the same time as the blocking back factor is applied; i.e., step (2) in Section
8.2.1. Note that the reduction factor is equally applied to all turns at intermediate
nodes (if any) between the entry and exit nodes.
Note that the weaving reduction is applied in addition to any other capacity-
reducing effects such as give-ways or blocking back.
5120257 / Apr 15 15-97

Section 15
15.40.4.5 Simulation Delays

Weaving does not, of necessity, add extra delays to traffic although there are
three ways in which extra simulation delays may result.
Firstly, if a link becomes over capacity due to weaving then queuing delays will be
imposed.
Secondly, if the weaving links are subject to link-capacity restraint functions (see
6.4.12) then the “link” or “pinch-point” capacity used in equation (6.2) is also
reduced in accordance with Equation 15.9 above leading to (in effect) a reduction
in cruise speed for a given flow.
Finally, if a Q-marker has been used on an intermediate link (see App. Q), then
the capacity used to calculate the V/C ratio in equation (Q.1) is taken after the
weaving factor W has been applied to the saturation flow, thus potentially
increasing the delay.
If none of the above three conditions occurs then introducing a weave marker will
have virtually no impact on travel times and hence on assignment. Link capacity-
restraint speed-flow curves are therefore highly recommended in conjunction with
weave markers.
15.40.5 SATURN Namelist Parameters

The following parameters may all be defined within the &PARAM namelist
parameters within a network .dat file (Section 6.3) to control the various options
within weaving calculations:
♦ WLMIN - Minimum length for weaving in metres - L min in Equation 15.2
♦ WLMAX - Maximum length for weaving in metres - L max in Equation 15.2
♦ PHILIP - If .TRUE. use Phil’s formula (Equation 15.13)
♦ STUART - If .True. use Stuart’s formula (Equation 15.11); else use (Equation
15.12)
Note that the first two parameters are “reals” while the latter two are “logicals”. The
default values are, respectively, 300 metres, 2000 metres, False and True. Thus if
the weaving section were 300 metres or less the maximum reduction would be
applied to saturation flows; if it were more than 2000 metres than no reduction
would apply.
15.40.6 Restrictions
The weaving calculations may not yet be applied to all possible situations within
SATURN. Thus it will not work with stochastic assignment (SUZIE = T). It should,
however, still function with, e.g., elastic assignment or multiple user classes (I
Think!).
15.40.7 Link Weaving and W Turn Priority Markers

There are certain obvious parallels between the phenomenon of weaving on a link
as described above and of “weaving at a node” as described in 6.4.2.5 and based
5120257 / Apr 15 15-98

Section 15
on the use of W turn priority markers. In both cases 4 sets of individual flows
come together and, depending on the level of “crossing over”, reductions in
capacity and increased delays may result.
The precise mechanisms by which these effects are modelled within SATURN are
different however. Thus W priority markers are modelled essentially as a form of
give ways at a single junction controlled by parameters such as GAP whereas the
link weaves use quite formulae and quite different parameters and apply over
more than one coded node.
Link weaving may be seen as weaving “over a distance” whereas W priority
markers represent weaving “at a point” - effectively therefore over much shorter
distances. The choice of one form over the other should therefore be partly
governed by the distance over which weaving is felt to take place.
15.40.8 Display of Link Weaving Data (E.g., P1X)

Each link which has been coded with a W is assigned a numerical “marker” which
indicates, inter alia, its position in the sequence. Thus a value of 1 indicates that
the link is the first link beyond the entry ramp in a sequence of more than 1 links
(e,g,, 10-15 in Figure 15-3), 4 indicates it is the final link before the exit ramp (16-
20 in 15-3), 5 that it is the only link in the sequence (i.e., both entry and exit) while
2 indicates an intermediate link in a sequence of multiple links (e.g., 15-16).
The markers may be displayed as link annotation data via P1X (under
“Properties”) or otherwise accessed as a data base item within SATDB.
In addition the .lpt files output by SATALL print a list of all links where weaving
factors have been applied at each assignment-simulation loop with the current
values of all relevant data such as Q nw , X f , etc. The factors may also be displayed
in the numerical node information menu in SATLOOK (post 10.6).
15.41 SATTUBA
15.41.1 Objectives
SATTUBA is a procedure embedded within SATLOOK which enables a set of
skimmed cost matrix files to be calculated from a .ufs network file and output in a
text format which is compatible with the economic appraisal program TUBA.
More specifically TUBA requires as input a set of matrices giving for each O-D
pair:
♦ passenger or vehicle trips;
♦ distance;
♦ time; and
♦ (monetary) charges.
These matrices may be further disaggregated by, e.g., user class, time period, trip
purpose etc.
5120257 / Apr 15 15-99

Section 15
Distance, time and/or charge matrices all need to be path-weighted averages, i.e.,
the travel time averaged over the paths used by each O-D pair as opposed to
being, say, the time component along a single minimum generalised cost path or
even the time along the minimum time path. In SATURN terminology TUBA
requires skimmed matrices as opposed to cost matrices; see Section 15.27.4.
Hence SATTUBA requires that the network is set up with SAVEIT = T and the
skims are based on forests, not trees.
We note that, as explained in 15.23.2 and 15.27.5, the forest path flows generated
by SAVEIT are not necessarily exactly equal to the path flows generated during
the “true” assignment. Thus quantities such as total pcu-hours, pcu-kms etc.
calculated using the skimmed and demand trip matrices – which is, effectively,
what TUBA seeks to do – are only approximations. See 15.23.2 for a discussion
of how these approximations may be improved.
We further note that, quite apart from numerical uncertainties arising from the
method of calculation and/or convergence, there are further theoretical problems
in that, in principle, Wardrop Equilibrium does not yield unique values of O-D time,
distance or toll. On the other hand it does yield unique values of OD generalised
cost. See below and sections 7.1.6, 7.8.6 and 15.23.8 for further discussion.
In a wider context it also has to be remembered that the “accuracy” of a skimmed
matrix is also affected by the overall convergence of the full model run, not just the
SAVEIT accuracy. Counter-intuitive results from economic evaluation techniques
such as TUBA or COBA may be simply a consequence of poor convergence in
either or both the do-nothing and do-something model runs.
Note that the trip matrix necessary as an input to TUBA may be “dumped” from
MX using the standard option to dump a matrix as comma-separated (CSV)
output; see 10.15.
N.B. The problem noted above with respect to the uniqueness of the sub-
components of generalised cost (i.e., time, distance etc.) is potentially a problem
for all economic evaluation procedures. There is therefore a very strong case for
basing economic evaluation on the generalised cost as used in the traffic
assignment model which has the advantage of being uniquely determined
(although there are still problems of convergence accuracy) as opposed to relying
on sub-components such as O-D time and distance which are not unique.
15.41.2 Single User Class Networks

The required matrices for a network with a single user class may be produced by
a specific bat file sattuba.bat which is run by a command such as:
sattuba net
which takes as input a network file net.ufs and outputs (up to) 3 matrices in text
format:
net_d.txt
net_t.txt
net_m.txt
5120257 / Apr 15 15-100

Section 15
net_p.txt
where the first matrix contains distances, the second contains times, the third
contains toll charges (if any exist) and the fourth contains penalties (if any exist).
Units are the defaults as specified by TUBA: distance is in kilometres, time and
penalties are in hours and tolls are in pence. The format used is TUBA “Format 1”
- see Appendix C of the TUBA User Manual for more details. (Essentially this
outputs all O-D cells, one record per origin, in comma-separated format. If
required options to input under formats 2 or 3 could be provided.)
15.41.3 Multiple User Class Networks

If the network has multiple user classes (NOMADS > 1) then separate TUBA data
files will probably need to be produced for each individual user class. Thus:
Sattuba net UC 2
processes data for user class 2 from the MUC network file net.ufs to produce:
Net.uc2_d.txt, net.uc2_t.txt, etc. etc.
Equally
Sattuba net UC *
processes data for all user classes. See 15.41.4.2.
15.41.4 Options within SATTUBA

We describe here three alternative options within SATTUBA: the use of a control
file, the use of distinct user classes and alternative output matrix file formats.
15.41.4.1 The ‘Control File’

The precise format of the output .txt files may be modified by a number of
parameters and/or options contained as Namelist parameters in the SATLOOK
preferences file satlook0.dat (11.17.2). Alternatively, a different preferences or
“control file” may be defined on the command line by, e.g.:
Sattuba net KR control
in which case the file control.dat defines the parameters.

The following namelist variables may be used:
♦ EFORM (Logical): If .TRUE. the data is output using E-Formats; Default F.
♦ NDPS (Integer): Number of decimal places printed (subject to certain

minima); Default 4.
♦ USETP (Logical): If .TRUE. 44444 time penalties are included within the
skimmed times (See 15.24.4); Default T
♦ CLICKY (Logical): If .TRUE. skimmed times by user class include any

possible extra times due to CLICKS (See 15.24.4); Default T.
5120257 / Apr 15 15-101

Section 15
♦ XCCSK (Logical) – If .TRUE. times and distances on all centroid connectors

(effectively only buffer centroids since simulation centroids have zero time
and distance by definition) are excluded from the skims by setting them to
zero. However any tolls on centroid connectors are included as set. See
15.41.5 below.
15.41.4.2 Distinct User Classes

SATTUBA may be used to output files for individual user classes using
commands of the form:
SATTUBA network UC n
which will output matrices of the form network.ucn_t.txt, etc. etc.

If “UC *” is used in the command line then the output matrices represent all the
possible user classes with matrices of the form network.uc1_t.txt,
network.uc2_t.txt, etc. etc.
15.41.4.3 Alternative Matrix Formats

By default SATTUBA outputs matrices using TUBA format 1 (CSV); alternatively
SATTUBA0 outputs its matrices as SATURN .ufm files whereas SATTUBA3
outputs them in TUBA Format 3. Otherwise the formats, filenames etc. are the
same as under SATTUBA.
The number of decimal places used in text output formats, e.g., CSV files, may be
user-set via a parameter NDPS in the “standard” SATLOOK preferences file
satlook0.dat or via user-set file; see 15.41.4. The current default is 4.
Note that there is no SATTUBA2 procedure since TUBA Format 2 does not make
much sense in this context. Equally there is no SATTUBA1 since that is what
SATTUBA does.
15.41.5 O-D Speeds in TUBA: XCCSK

We note that TUBA uses the O-D time and distance matrices produced by
SATTUBA to construct its own internal matrices of average O-D speed which in
turn it uses to estimate fuel consumption and vehicle operating costs. Problems
may arise if either the time or distance matrices contain “artificial” elements or
have certain components missing leading to unrealistic speeds.
Thus, if buffer centroid connectors have been created with either a distance and
no time or a time and no distance then the summed O-D times and/or distances
may lead to very high or very low speeds. The most frequent (inadvertent) cause
of this is when SHANDY = T and CROWCC = T (see 15.10.3), in which case a
buffer centroid connector which is defined in the network .dat file with both time
and distance fields blank will have its distance set equal to the crow-fly distance
but no equivalent time.
One solution is to set CROWCC = F (as recommended and, post 10.9, the
default), in which case the distances will not be added in the original network file.
An alternative is to use the parameter XCCSK (eXclude CC in SKims) within the
SATTUBA control file (see 15.41.4 above) to effectively set the time and distances
5120257 / Apr 15 15-102

Section 15
for all centroid connectors equal to zero, in which case they make no contribution
to O-D skims which are therefore based entirely on “real” network components
only. XCCSK is new in release 10.9 but is “retrospective” in the sense that 10.9
SATTUBA may be applied to .ufs files created prior to 10.9.
Note that XCCSK applies only to skims of time and distances, not to skims of,
e.g., tolls or generalised costs and that it is also used more widely within time
and/or distance skims; see, e.g., SKIMTIME and SKIMDIST in 15.27.7. Its default
(F) is set within the preferences file SATLOOK0.DAT.
A further example occurs when two zones both have centroid connectors feeding
in/out of the same simulation node, in which case the obvious path consists of an
entry connector to the stop-line at the node, a single turn at the junction followed
immediately by an exit connector. In this case the O-D pair will have positive time
from the turn but zero total distance (since both turns and simulation centroid
connectors have zero distance by definition). In this case there are fewer simple
remedies within SATURN.
N.B. SATTUBA is still very much “work in progress” and not all the final essential
options have been added. We therefore welcome feedback from users.
15.42 SATCOBA
SATCOBA is a procedure embedded within SATDB which enables a sub-network
of links to be defined which is compatible with that required by the economic
assessment program COBA and, in addition, to output a text file which specifies
the network and includes flow data and selected link data as required by COBA in
the formats required by COBA.
Alternatively a sub-set of links as would be used by COBA (see paragraph 1 in
15.42.1) may be selected within SATDB, after which the user is free to output
whatever data they wish in whichever format they wish (as opposed to SATCOBA
which outputs fixed data in fixed formats).
15.42.1 General Functionality

COBA requires that the network be defined in such a way that: (a) there are no
centroid connectors, only “real” links, and (b) all links are “bi-directional”; i.e., if a
link (A,B) is included it represents both the link from A to B and that from B to A
(or, in the case of a one-way link, only the direction that exists). Thus the first job
carried out by SATCOBA is to define an appropriate sub-network. Note that within
this sub-network node names are those used by SATURN but each link is given a
unique number which equals its normal link number in the SATURN assignment
network (so there will be gaps in the numbers). An alternative system of user-set
link numbers is described in 15.42.3.
Secondly SATCOBA then calculates the total flow per COBA link with the flow for
a 2-way link being the sum of its two directional flows. Furthermore, since COBA
wants flows over, say, 24 hours (or 12, etc. etc.), the flows are factored by a user-
set parameter COBAF which is defined under &PARAM in the original network
.dat file (default 1.0) and/or within the SATCOBA control file (see 15.42.2) via
COBAF1, COBAF2 etc.
5120257 / Apr 15 15-103

Section 15
By default the flows output are total flows and therefore include all fixed flow etc.
contributions, although there are alternative options (MUC and MVC) by which
flows by individual user or vehicle classes may be output (see 15.42.2 below). In
addition the units may be either pcu/hr or vph.
In addition, since COBA flows would normally be the weighted sum of flows from,
say, an AM, off-peak and PM network SATCOBA accepts as input one or more
“networks” (i.e., time periods) and outputs a single flow which is the weighted sum
of each individual network flow. (It is assumed that all networks have the same
“topology”.) Alternatively, if the parameter SUMNET = F (15.42.2), each network
flow is output separately
Next SATCOBA generates a (partial) data set which contains certain fixed data
such as the link distances. The full COBA input file requires further information
such as lit/unlit which is not available from within a SATURN network file on its
own.
Finally SATCOBA generates a set of turning proportions at each (internal)
simulation junction (the “turning matrix” in COBA terminology) with a directionality
flow factor for 2-way roads.
Thus the output from SATCOBA is a text file (extension .cba) which contains four
sections:
♦ a network definition section (COBA KEY 042)
♦ network flows (KEY 056)
♦ network fixed data (KEY 060)
♦ the “turning matrix” at each junction (KEY 082)

all in a format specified by COBA and which we need not specify in detail here.
To run SATCOBA (which can effectively only be run via its bat file) type:
SATCOBA net1 net2 net3 ... KR control
where net1.ufs, net2.ufs, net3.ufs ... are the output files from different time periods
whose (factored) flows are to be (optionally) added together. The output (text) file
would be net1.cba.
A control file, control.dat, which sets/over-writes various parameters may be
optionally defined via the bat file. If none is defined a “null” default file,
satcoba0.dat, is used which basically accepts all program defaults. See 15.42.2
Like SATTUBA, SATCOBA is very much “work in progress” - comments on a
postcard please to DVV.
15.42.2 The SATCOBA Control File

The control file consists of a standard set of namelist parameters headed by
&PARAM and terminated by &END. The default file satcoba0.dat sets all defaults.
The following parameters may be set:
5120257 / Apr 15 15-104

Section 15
Table 15.1 – SATCOBA Namelist Parameters
OPTION TYPE DEFAULT INTERPRETATION
NAMES Logical T If T use standard node names in the output file ;

if F use map-based sequential numbers 15.42.6
DEMAND Logical T If T use demand flows ; if Fuse actual flows

SUMNET Logical F If T add the link flows from each input network
and output their sum ; if F output individual flows
MIDLF Logical F If T define simulation link flows mid-link, not
downstream
MILES Logical F If T output link distances in miles ; else
kilometres
MAJORM Logical F If T the “turning matrix” for all priority junctions is
output in the order of a major arm first followed
by a minor arm
MUC Logical F If T flows are output separately for up to 3 user
classes, all from network 1, in the KEY056
records
MVC Logical F If T flows are output for up to 3 vehicle classes

from network 1 in the KEY056 records
PCUS Logical T If T user/vehicle class flows are output in units of
pcu/hr; if F they are converted into veh/hr. N.B.
This does not apply to total flows, only
disaggregate flows.
COBAF1 Real 1.0 Factor to be applied to the flows on input
network….
COBAF2 Real 1.0 ….ditto network 2 up to COBAF4
KNOB Integer 0 The SATNET KNOB field used to define COBA

link numbers ; see 15.42.3
FILKNB Character Blank The input file used to define COBA link numbers ;
see 15.42.3
FILNOD Character Blank The input file used to define node numbers; see
15.42.6
Notes:
1) NAMES will default to F, i.e., sequential numbers, if the standard SATURN
node names exceed 4 digits since 4 digits is the maximum permitted within
COBA format
2) MUC = T will only work if (a) only one network is being processed and (b) if
the number of user classes is less than or equal to 3 in that network. If not, it
is automatically replaced by F. Note that the limit of 3 is due to a limit imposed
by COBA in its KEY056 record formats.
5120257 / Apr 15 15-105

Section 15
3) Similarly MVC = T will only work if (a) only one network is being processed
and (b) if the number of vehicle classes is less than or equal to 3. Vehicle
class flows are obtained by summing over their constituent user class flows.
(Clearly both MUC and MVC cannot be T at the same time.)
4) Post 10.9 user and/or vehicle class flows may be output as either PCU/hr or
vph depending on whether parameter PCUS = T or F.
15.42.3 Defining COBA Link Numbers using KNOBS data

The default link numbering system used by SATURN to define link numbers in the
created coba-formatted network is, as mentioned above (15.42.1), to use the
(essentially arbitrary) numbering system used within SATURN assignment
networks. However it is also possible for the user to define their own set of link
numbers using the “KNOBS” input facility to SATNET; see 15.14. This option is
controlled by the namelist parameter KNOB in the satcoba control file (15.42.2).
Thus, if KNOB = 1, then the link numbers are those defined within KNOBS field 1,
etc., etc. If the input KNOBS value for a particular link is 0 then that link is not
included in the newly created satcoba network; this facility therefore allows the
user to “select” those links which are to be included in the coba files via KNOBS
data.
The KNOBS data is, by default, that input via SATNET into the network .ufs files
but it may also be input directly into SATCOBA via the namelist parameter
FILKNB (15.42.2) which defines the name of an input file. Format conventions for
the file FILKNB are as per inputs to SATNET (15.14.5).
Note that KNOBS data are essentially input and stored as “real” data but when
used in this context they are rounded off to the nearest integer
15.42.4 Common COBA Link Numbers in Multiple Networks

One very useful application of using KNOBS data to define link numbers is that it
allows two (or more) networks (e.g., a do-minimum and a do-something) to use
the same definitions of link numbers. To do so the user must first create a “text”
data file for the “base” network which contains one record per COBA link
containing three integers: the link A-node, its B-node and the corresponding link
number used to define that link in the output .cba COBA file. We propose a
standard extension of .cln (Coba Link Number) for such files such that net.ufs
would produce a file net.cln.
To create a .cln file use SATDB and choose (starting in the Master Menu):
6 – Miscellaneous Data Input
12 – COBA Network Link Numbers
13 – Dump the Full Data Base to an ASCII File (Master Menu)
and create the file with extension .cln. (A batch file to do the job automatically
could be created if desired – requests/bribes to DVV!)
5120257 / Apr 15 15-106

Section 15
To use a file, say net_base.cln, within another network, net_ds.ufs, you must first
create a “control file” coba_ctl.dat which might contain:
&PARAM
KNOB = 1
KNBFIL = ‘net_base.cln’
&END
and then run SATCOBA via:
SATCOBA net_ds KR coba_ctl
The output COBA file net_ds.cba would then contain, inter alia, flows on all the
links contained in net_base.cln using the same link number conventions. Note
that links which are in net_ds but not in net_base.cln would not appear in the .cba
file. However they are listed in the output .lpd file in order to help the user decide
whether to include them somewhere else within the coba file. Equally links which
are in net_base.cln but not in net_ds would not appear in the output .cba file.
Thus the only function of the .cln file is to supply link numbers, not network
structure.
15.42.5 Viewing COBA Link Numbers

The link numbers used in the output COBA network may be displayed (Version
10.5 and onwards) via P1X and/or SATDB but only (at the moment) if they are
based on SATURN assignment link numbers as opposed to user-set KNOBS
data. Thus they appear as option 12 under the “Miscellaneous Data Input” sub-
menu from the SATDB top menu.
In addition the links used may be selected under Link Selection in SATDB. (Recall
that for 2-way links only one direction is “used”, in general A-B rather than B-A
where A has a lower node number than B.)
To display the user-set link numbers simply access the KNOBS data element
used, preferably with the links “selected” as above.
15.42.6 Alternative / Sequential COBA Node Numbers

While it is generally preferable to use the “standard” SATURN node numbering
system within COBA networks it is not always possible. In particular, COBA
requires that node number have a maximum of 4 digits so that, if your SATURN
network uses 5-digit numbers then they will have to be reduced/converted to a
system that uses a maximum of 4. (One might well ask why COBA isn’t upgraded
to accept 5-digit node numbers rather than SATURN having to resolve the
problem mais c’est la vie!)
There are two alternative node numbering systems that may be used within
SATCOBA to avoid 5-digit node numbers.
The first is based on the sequential node numbers as used internally by P1X to
create “map networks” whereby each sequential number refers either to a zone
(the first NCENTS entries) or a junction, whether buffer or simulation. Note that
map sequential numbers may be viewed within the SATDB node data base as
5120257 / Apr 15 15-107

Section 15
accessed within P1X by selecting the appropriate entry from the list of node
attributes.
Sequential numbers are selected within SATCOBA by setting NAMES = F in the
control file (15.42.2) or, alternatively, it will be done automatically if the maximum
node number exceeds 9999.
The second system uses an explicit input file to convert SATURN node numbers
into a more compressed system – which could indeed be based on pure
sequential numbers as above but any arbitrary conversion system may be used.
To select this option (a) set NAMES = F as above but (b) define the conversion file
filename as FILNOD within the control file (15.42.2).
The conversion file consists of a series of records, one per “real” node (i.e., zones
are not included as they do not appear in COBA outputs), each of which contains:
(a) a (real) node name (which may exceed 5 digits) and (b) its equivalent output
number (4 digits or less). All COBA node number outputs are automatically
converted to the new system.
The main advantage of the second system is that it may applied to any number of
different networks, for example a do-minimum and a do-something network, which
have (some) different node numbers and therefore different sequential numbers.
In particular a new option in P1X (see 11.4.2) allows for a file to be created
containing the names and sequential number based on a “union” of all nodes.
If your network has more than 9999 sequential map numbers it cannot be used by
COBA in its current form and you’re in deep doodah! Try a cordon maybe?
15.43 Bitmaps within SATURN

Bitmaps are used as inputs within SATURN to provide a background to network
plots within P1X; see 11.3.6. Thus instead of a blank (i.e., white) screen
background an image obtained from a .bmp file is used and the network plot is
over-written upon it. An example from the central area of York is shown below.
Note that in this case the “network window” as nominated by P1X is larger than
the area covered by the bitmap so that there is a blank surround to the bitmap.
Had the bitmap covered a wider region than the network window then the
appropriate region of the bitmap would have been selected and suitably
expanded. Thus a very useful property of the bitmap displays is that they “move”
with the network window.
5120257 / Apr 15 15-108

Section 15
Within this particular context bitmap files must be of either “.bmp” or “pcx” format,
as opposed to, e.g., .jpg, .gif, etc.formats (although .jpg is allowed as output; see
11.3.6). However other graphical formats may almost certainly be converted into a
.bmp format by making use of standard software such as Paint.
Where or how the bitmap file is obtained is not strictly relevant; it might be
downloaded from, e.g., OS sources, scanned from a road map, dumped from a
GIS software package or even output from a different run of P1X for a different
network. The important thing is that it be in .bmp format and, equally important,
that the “area” which it covers be identifiable.
Thus in order for P1X to draw a bitmap background within the windowed area
covered by a network plot it is necessary to know (a) the precise area covered by
the network window and (b) the full area covered by the .bmp file, in effect the co-
ordinates of its 4 corners, so that the degree of overlap between the two may be
ascertained. This may not sound too difficult, indeed most of the time it isn’t; the
tricky thing is being able to obtain the co-ordinates of the bitmap and of the
network within the same reference system. (Note that it is the network “window”
which “controls” the region plotted and that the bitmap must be manipulated to fit
onto the area chosen by the P1X network window rather than the other way
around.)
Thus for every .bmp file used by P1X, say picture.bmp, it is necessary to set up a
further (very small) file, named picture.xyb, which specifies the 4 corners of
“picture” using the same coordinate system as that used by the network (i.e., the
co-ordinates as used within the 55555 network data section and independent of
XYUNIT (6.8)). .xyb files consist of a single record containing 4 (real) values in the
following order:
5120257 / Apr 15 15-109

Section 15
♦ XMIN - the east-west co-ordinate of the lower left-hand corner;
♦ XMAX - ditto for the upper right corner;
♦ YMIN - the north-south co-ordinate of the lower left-hand corner;
♦ YMAX - ditto for the upper right corner.

Optionally, a second record may be included which contains the “intensity scaling
factor” to be applied for that particular bmp image; see 15.43.6.
Note that the “units” of XMIN etc. should be the same as the units of the node X,Y
co-ordinates as defined under the 55555 records in the original network .dat file
(see 6.8). Thus if XYUNIT = 10.0 so that the co-ordinates are defined to the
nearest 10 metres then XMIN etc. should also be the nearest 10 metres.
However, as noted in 15.43.2, we strongly recommend that all co-ordinates are
defined in units of metres to minimise confusion,
The .xyb file may be most conveniently set up the user assuming that the
information is known in advance through knowing the source of the image.
Alternatively, if a bitmap is input into P1X without a corresponding .xyb file being
located, the user is offered the option to “calibrate” the .bmp file as detailed in
15.43.3.
15.43.2 Co-ordinate Systems

Once again, the importance of having a common system of co-ordinates for both
the network and the .bmp files cannot be over-emphasised. The simplest method
is to base both upon some standard system such as, in the UK context, the
Ordinance Survey (OS) co-ordinates with both east-west (X) and north-south (Y)
co-ordinates defined to the nearest metre. (Very often the “leading digits” as used
by the full OS system may be dropped; e.g., if all your X values begin with, say, 45
followed by 4 digits then it is easier to drop all the 45’s and stick to the final 4
digits.)
Note that defining co-ordinates as metres implies that XYUNIT should be set to
1.0 (its default). And we strongly recommend that such a system be adopted
throughout.
This means that networks which, for one reason or another, have been defined
from their “birth” using OS-based co-ordinates will find it much simpler to use .bmp
files than networks which are based on a more arbitrary set of co-ordinates. In the
latter situations it is probably far easier in the short term to convert .xyb co-
ordinates to the arbitrary system (see 15.43.3 below) rather than trying to convert
the original X,Y co-ordinates. However, on the other hand, there are considerable
longer-term benefits, e.g., being able to interface with various GIS-based data
sources, in using OS-based co-ordinates and it may therefore be a good idea to
“bite the bullet” and transform your arbitrary co-ordinates into OS NOW! For
further advice on how to do so please contact DVV.
15.43.3 “Calibrating” .bmp files

By “calibration” we refer to the process by which the four corners of a particular
.bmp file are established in terms of the co-ordinates used by the network. Ideally,
5120257 / Apr 15 15-110

Section 15
as we have pointed out above, both should be based on the same system and the
coordinates of the four corners should be established a priori. However, in the
absence of such information, a procedure has been established within P1X to
obtain this information.
In order to carry out this procedure the user must be able to identify the (network-
based) co-ordinates of two points within the bitmap display. Ideally these two
points should be as far away from one another as possible and near one or the
other diagonals. Normally the points will correspond to nodes for which the
network co-ordinates are known, although in principle they could be any points
which can be easily identified in network terms.
Formally the bitmap is displayed with a thin red strip added along the edges and a
further red cross displayed in the centre. The user is asked, first, to move and
click the mouse over the red cross (in order to confirm the centre point in pixels)
and next to click on two points and input their X,Y network co-ordinates. The four
corner points may then be easily calculated via a simple linear transformation.
A practical problem which arises in the above procedure is that it is not possible
within P1X to simultaneously display both the bitmap and the network (prior to
calibration). We therefore recommend first viewing the bitmap (e.g., enter it within
PMAKE or use any other graphical system such as Paint) in order to identify the
two points(/nodes) to be used and then viewing the network in P1X and using the
X,Y monitoring option under Information to determine - write them down! - the two
sets of co-ordinates. Armed with this information you can return to P1X and the
bitmap display to complete the calibration. Both procedures may be carried out at
the same time by having two program windows open - or even two computers!
This process is probably most easily done by using PMAKE to select, view and
calibrate the .bmp file and then exit the program. Trying to do the same process
within P1X leads to problems of having both a bitmap and an (incompatible)
network both trying to define a network window.
Once calibrated a .xyb file is automatically created (so that picture.bmp spawns a
file picture.xyb) and which will from then on be opened at the same time as the
.bmp file is opened.
15.43.4 Outputting Bitmaps to Hard Copy Devices

Bitmap files may be included in output hard copy plots in the same way that they
appear on the screen but there may be certain restrictions.
Bitmap files are held by P1X in internal memory and the array thus used has
dimensions (2001 by 2002 by default but may be increased by request) which will
normally cover the pixel dimensions set by the screen resolution. However hard
copy devices may well have pixel resolutions which exceed the above limits by
considerable margins and therefore the program is unable to print “full”
background bitmap images to such devices. Currently only the “upper half” of the
bmp file is printed (so as to use as much as possible of the available memory); a
more permanent “fix” is currently being sought.
Note that a pre-10.6 problem whereby the network and the bmp file were printed
with slightly different scales (by 5%) has been corrected.
5120257 / Apr 15 15-111

Section 15
There is, however, no problem in dumping the current plot plus bitmap display to a
.bmp output file or the clipboard and subsequently outputting to a printer (but with
some loss of resolution).
15.43.5 Bitmap backgrounds within Node Graphics

In principle a bitmap image could equally well be used as the background to node
graphics displays. At the time of writing the necessary co-ordinate
transformations have not been worked out but it will happen soon!
15.43.6 Changing the Intensity of Bitmap displays

If the bitmap display is too “intense” it may make the over-printed P1X displays
difficult to see. This may be corrected by reducing the intensity of the background
by setting a “scaling” factor between 0 and 1 (set within Display/Background or via
the .xyb file, 15.43.1); the lower the factor, the “whiter” the bitmap. The default
scaling factor is 1.0 but may be changed globally via the namelist parameter
SCABMP in the P1X preferences file p1x0.dat.
This option may be particularly useful within PMAKE when a new network is being
traced on a bitmap image.
15.43.7 Maximum Bitmap File Sizes

The “size” of a bitmap file which can be read by P1X, i.e., the number of pixels in
both the horizontal and vertical dimensions, is limited to certain upper limits, e.g.,
2003 x 2004. This may create problems for users since it is quite easy to create
.bmp files with an almost infinite number of pixels depending on the geographical
size of the file (i.e., the number of square kilometres) and its resolution. Some
compromises may be necessary within SATURN.
For example, if the .bmp file covers an area of 1 km x 1 km with 2,000 pixels in
each dimension then one pixel (in the .bmp file) covers 0.5 metres which, for most
purposes should provide sufficient resolution, However, if the user “windows in” to
a 20 x 20 metre display in order to look at a single junction then each pixel in the
original .bmp file covers 0.5/20 equals 1/40-th of the screen and the image would
be very “chunky”. That problem could be avoided by creating (outside SATURN) a
.bmp which covered just the 20x20 area with the full resolution of 2,000 x 2,000
pixels. However, that would not be a very useful background for a window of 1 km
x 1 km.
It is, of course, possible within P1X to prepare several different input .bmp files
and to “swap them over” depending on the current window, but it is not highly
satisfactory.
Such problems could also be removed by increasing the maximum dimensions
which SATURN can handle, e.g., to go from 2001 x 2002 to 10,000 x 10,000 and
this can be done easily enough when compiling the program. However this may
create other problems in that a .bmp file of 10,000 x 10,000 pixels requires 6 x 108
bytes, i.e., 0.6 GigaBytes, within P1X which might, in combination with all the
other demands from P1X, exceed the RAM provided on most machines and
therefore slow down the overall execution speed dramatically. In addition, even if
there were sufficient internal RAM, the cpu time required to input and manipulate
very large .bmp files may still be excessive for most user requirements.
5120257 / Apr 15 15-112

Section 15
The size and resolution of .bmp files may be easily manipulated using standard
Windows graphics packages such as MS Paint or MS Picture Manager for
example.
15.44 Defining Extra Bus Travel Times (BUSSPK and BTKNOB)

The travel times associated with bus routes are normally calculated by summing
the standard link and/or turn times associated with other vehicles along the route.
However it is possible to “supplement” these times to represent the additional
effects of, e.g., bus dwell times at stops or bus speeds being slower than cars.
The extra time may be introduced using either:
(i) an additional time proportional to the total distance over the whole route,
(ii) explicit link by link extra travel times coded as “knobs”.
In both cases the additional travel times are calculated once and for all per route
when the network is built within SATNET and then recorded within the .uf* files.
This means, for example, that it is not possible to “view” the extra travel times per
link using the bus “joy ride” display within P1X. The extra times are reported both
within the individual route statistics and in the more aggregate statistics under
option 6 in SATLOOK (but not, N.B. in the total pcu-hrs etc. reported under either
options 4 or 5 in SATLOOK).
Under (i) the proportionality between extra (i.e., stop) time and distance in km is
set by the parameter BUSSPK (Bus Stop Seconds Per Kilometre) defined within
the &PARAM namelist records in the network .dat file. In the event of there being
more than one “bus company” BUSSPK may be subscripted so that, e.g.,
BUSSPK(3) = 0.04 would set the specific value for bus company 3.
Under (ii) link data must firstly be defined using the KNOBS facility (see 15.14 -
any of the 3 input methods may be used) and a proportionality factor
BTKNOB(b,k) set > 0 where b refers to a bus company and k to a KNOB data set
(1 ... KNOBS). The units of BTKNOB are assumed to be seconds per whatever
units that particular knob data field is in. Again BTKNOB may be defined within
the &PARAM namelist records (6.3.3).
Note that in using namelist input to set BTKNOB which is a 2-dimensional array
you may need to use the array based input, so that:
BTKNOB(3) = 0.3, 0.0, 4.0
would set the elements (3,1), (3,2) and (3,3) to 0.3, 0.0 and 4.0 respectively. See
note 17, Appendix A. (In fact BTKNOB is the only variable to which array-based
inputs may be applied.)
Both methods are fairly “aggregate”, even crude, in that they do not allow you to
define stopping times by links by bus route (unless you have one route per
company which is not very practical). However they are a start and all requests
for more will be listened to.
5120257 / Apr 15 15-113

Section 15
15.45 Representing Walk / Pedestrian Networks

Traditionally SATURN networks represent roads down which cars travel and their
travel speeds are vehicle speeds. However there is no hard and fast reason why
every “link” in a SATURN network should be a road link and it is quite possible to
“fool” SATURN into treating a link as though it were part of the road network while
clever old you give it characteristics more appropriate to a pedestrian than a car.
How such coding “tricks” are accomplished is of course up to the user. One
common method (assuming that the walk networks are superimposed on a
simulation network) is to code the walk links and nodes as part of the buffer
network with (low) fixed speeds/times, a flat flow-delay curve (power = 0) and,
effectively, infinite capacity (e.g., 99999). The walk links are then connected to the
simulation network via external simulation nodes. The origin/destination zones
to/from which trips exit/enter are then connected to walk nodes rather than
simulation links.
Thus an o-d trip with a destination which requires walking will be assigned a route
which starts at a “normal” zone and initially follows a set of “normal” (i.e., car) links
until it reaches the walk links through which it can reach its destination. At this
point, in effect, the car becomes a pedestrian although as far as SATURN is
concerned nothing has really changed - it is simply finding a route through a
network. The same principle works in reverse for trips which start as walk trips.
If, very naturally, the point of transition from car to walk is at a car park note that
tolls (and capacities) may be associated with the car park as described in Section
20.5.3.
Certain “presentational” problems may occur in P1X if, for obvious reasons, the
nodes in the walk network have the same (or very close) co-ordinates to “real”
junctions since there will be a high degree of overlap between the walk network
and the road network. This may be avoided by assigning a unique set of capacity
indices to the walk links (a good idea anyway) and then excluding those capacity
indices from the network link plots as described in 11.6.1.4 and/or note 4, 11.6.4.
15.46 DBDUMP & P1XDUMP: Dumping Link Data to Text Files
15.46.1 DBDUMP: Dumping Data via SATDB

A batch file dbdump.bat based on the program SATDB has been set up in order
to provide a simple method to dump selected link data from a binary .ufs file into
an ascii text file. For example, the command:
Dbdump net flows.txt 4503
dumps the demand flows (DA code 4503) from net.ufs into a file flows.txt following
the “rules” described in 11.10.9.
Various options described below are provided to control the precise “format” and
contents etc. of the output file.
Tokens on the command line may be divided into two types:
♦ DA codes for output data items
5120257 / Apr 15 15-114

Section 15
♦ Options
DA codes are always given as numerical values; For a full list of the DA codes
within a .ufs file please consult Appendix J. Note, in particular, that codes such as
3808 to represent actual flow by user class 1 are also permitted (see 15.21.4).
Options are always represented by characters beginning with a $. They may be
further sub-divided into two groups, link types and format.
(i) Those that select the link types to be output
Under link selection the following characters indicate link types to be included:
$SL Include simulation links (i.e. roads)
$ST Include simulation turns
$SCC Include simulation centroid connectors
$BL Include buffer links
$BCC Include buffer centroid connectors
and the composites
$L Include all (simulation and buffer) links
$CC Include all (simulation and buffer) centroid connectors
Including an X immediately after $ indicates “exclude” that link type; e.g., $XST
implies exclude simulation turns but leave the other 4 types.
For example:
DBDUMP net net.txt 4503 $SL
would dump demand flows for simulation links only to file net.txt.
(ii) Those that control the format
Further options controlling the output formats, e.g., nodes in fixed columns versus
free format (CSV), are being added to match some of the interactive options within
SATDB. Thus:
$KP5COL Nodes are output in fixed columns of 5 or …
$KP6COL … in fixed columns of 6
Note that if the node or zone numbers in the network being dumped exceed 4
digits then the output link format automatically allocates 6 columns per node.
(The 5-column option may be set by default by defining the parameter KP5COL =
T in the preferences file p1x0.dat; KP5COL = F selects 6 columns.)
Furthermore, if the filename of the output file in the command line has an explicit
extension .CSV, then it is assumed that the output data format will be CSV rather
than fixed columns. For example:
DBDUMP net net.csv 4503 $ST
would dump demand flows for simulation turns to a CSV formatted file, net.csv.
5120257 / Apr 15 15-115

Section 15
15.46.2 P1XDUMP: Dumping Data via P1X

A very similar batch file to DBDUMP, P1XDUMP, dumps selected data to a text
file but based on P1X internal codes rather than DA codes. For example, the
command:
P1XDUMP net flows.txt 5
dumps the free-flow speeds (P1X internal code 5) from net.ufs into a file flows.txt.
See Appendix I for a full list of codes.
To request a particular user class for a user-class dependent variable (such as
link flows) the class is indicated by appending ‘Un’ to the internal code; for
example:
P1XDUMP net flow_uc4.txt 40U4
dumps the (demand) flow for user class 4.

The options $SL etc. described above under DBDUMP apply equally under
P1XDUMP.
15.47 CLICKS: Variable Free Flow Speeds by User Class
15.47.1 General Principles of CLICKS

The “CLICKS” parameters represent a somewhat simplistic method to model the
clearly evident fact that on, say, motorways, heavy lorries travel at a lower speed
than cars (whether due to speed restrictions or to vehicle characteristics – or
both). Setting a parameter CLICKS(2) = 100 signifies that user class 2 vehicles
(e.g., lorries) have a maximum speed of 100 kph on all roads (both buffer and
simulation).
Input values of CLICKS are included as subscripted variables within &PARAM in
the network .dat file; the default of 0.0 signifies that there is no maximum speed
restriction for that user class. Units are in kph.
CLICKS only has an impact on road links (i.e., buffer and/or simulation roads, not
simulation turns and not centroid connectors) whose free-flow speed is in excess
of the input value(s) of CLICKS. In modelling terms it is represented by a fixed
time penalty per user class equal to the difference in time between a vehicle
travelling at the input free-flow speed and at CLICKS; if the free-flow speed is less
than or equal to CLICKS then the time penalty is zero. (And equally if CLICKS is
not set the time penalty is zero.) (But see 15.47.3 for an alternative model with
variable time penalties.)
Generally speaking CLICKS is applied to links which have a speed-flow curve, but
they may equally well be applied to links which have a flat speed-flow curve. If the
link does have a speed-flow curve then it would be expected that CLICKS would
be somewhere in between the maximum free-flow speed and the minimum speed
at capacity; if not a Serious Warning 159 is generated.
In general we would expect that CLICKS(1) = 0 on the assumption that user class
1 represents cars and that cars can always travel at the maximum speed, i.e., the
5120257 / Apr 15 15-116

Section 15
free-flow speed coded for each link, and that there is no need to impose an extra
travel time on them. But, if you do want to impose penalties on all user classes,
go right ahead!
The fact that the penalty is fixed means that it is included within the travel time (for
that user class) under all conditions, i.e., all speeds and all flows. To give a simple
numerical example, consider a link 1 km long with an input free-flow speed of 120
kph (which presumably applies to cars, user class 1) but with user class 2 (lorries)
having been assigned CLICKS(2) = 100. Under free-flow conditions cars take 30
seconds to travel the 1 km. at 120 kph, lorries take 36 seconds at 100 kph. Hence
the fixed time penalty is 6 seconds for user class 2.
The end effect is identical to adding a penalty of 6 seconds within the 44444 data
records for user class 2 on that particular link; in both cases, the 6 seconds is
simply added to the minimum generalized cost for that link as used within the
assignment. Therefore, in both cases, the extra time may influence their route
choice. However, in practical terms, it is much simpler to set a single parameter
under &PARAM than to include explicit penalties for every link which requires it.
Although, on the other hand, explicit penalties under 44444 can be made much
more precise.
A possible modelling disadvantage of assigning a fixed penalty may be seen,
using the above 1 km long motorway link, by assuming that the speed at capacity
for that link has been coded as 40 kph. Under capacity conditions it is perhaps
more realistic to assume that both cars and lorries travel at the same bumper-to-
bumper speed. In fact the extra 6 second penalty on the lorries will bring their
effective speed down to 37.5 kph, an “error” of 2.5 kph. On the other hand it might
be argued that even under bumper-to-bumper conditions cars will still have a
slight advantage over lorries by being able to weave in and out a bit more and that
maybe a differential speed of 2.5 kph is not too bad an estimate of that effect. It is
up to user to judge whether or not this represents an “acceptable” model.
At this point, users may well be asking why there cannot be two (or more) different
speed-flow curves per link per user class which may differ at free-flow but come
together at capacity. In principle, there is no reason why such differential curves
could not be defined. Unfortunately, for complicated theoretical reasons, the
multiple user class assignment algorithm used within SATURN (see 7.3) requires
that there can be only one cost component which is flow-sensitive and that that
component (i.e., time) is common across all user classes. Fixed cost components
may, however, differ between user classes (e.g., the evaluation of distance in
generalized cost seconds) and the differential time penalties must therefore fall
into that category. Otherwise multiple equilibria may occur.
In practical terms, as mentioned above, the use of CLICKS may influence route
choice by user class. The extra time penalties will automatically be included within
any O-D skim that includes time.
Summary statistics listing the total extra travel time in terms of pcu-hours incurred
under CLICKS are given in the .lpt files and within the various list options under
SATLOOK and P1X. The outputs are disaggregated by: user class,
simulation/buffer, this/next/total time period and by capacity index. In principle
these totals could (and possibly should) be added to the cruise time etc. totals
which appear in standard output tables; however, for the time being, this has not
5120257 / Apr 15 15-117

Section 15
been done in order to allow users to think about exactly how they would wish to
have the data presented.
In summary setting a value for CLICKS is an extremely simple method to
represent differential speeds by user class but some users might feel that the
possible “errors” introduced at high flow levels may outweigh the advantages of
simplicity.
15.47.2 Disaggregated Levels of CLICKS (KLUNK)

Prior to the release of version 10.7 the value of CLICKS for a particular user class
applied equally to all links (excluding centroid connectors); post 10.7 CLICKS may
be disaggregated either by a link’s capacity index or, ultimately, per individual link.
The choice is set by an Integer input parameter KLUNK defined under &PARAM.
Thus, if KLUNK = 0 (the default) CLICKS(u) applies to all links for user class u. If
KLUNK = 1 then, in effect, CLICKS becomes a two-dimensional array such that
CLICKS(v,k) defines the value of CLICKS for vehicle class v for all links with
capacity index k. If KLUNK = 2 then every individual link can (potentially) have its
own unique set of CLICKS values.
N.B. With KLUNK > 0 the values of CLICKS are defined by vehicle class, not user
class, but, recall from section 5.8, that each user class should be associated with
a particular vehicle class (as set on the network 88888 data records) so the
general principle that each user class has a maximum speed per link is retained.
The reason for using vehicle classes directly rather than user classes is that there
are generally a much smaller number of vehicle classes (e.g., cars, light and
heavy lorries) and it is really the type of vehicle that determines maximum speeds,
not whether a car driver chooses a route based on minimum time or distance. It
also allows users to introduce new definitions of user classes but with the same
set of vehicle classes (e.g., split a user class Work into HB Work and NHB Work
but both are part of Vehicle Class 1) without having to update CLICKS(,). Plus it
allows data files such as FILVSD files (see below) to apply to more than one
network as long as both networks use the same conventions for capacity indices
and vehicle classes
15.47.2.1 KLUNK = 1 (Disaggregate by Capacity Index)

To input variable values of CLICKS by vehicle class under KLUNK = 1 the user
must either:
(a) prepare a text file (formatted as below) and define its file/pathname via the text
parameter FILVSD input under &PARAM in the network .dat file, or
(b) include extra records within the 33333 buffer data (new with 10.9).
15.47.2.2 FILVSD File Input:

The file must contain one record for each Capacity Index for which CLICKS values
are required with the first entry field containing the (integer) Index and the
following values containing the (real) maximum speeds for Vehicle Classes 1, 2,
3…. The format is essentially free – each item must be separated by either a
space or a comma from its neighbours; i.e., CSV is acceptable. All values for
5120257 / Apr 15 15-118

Section 15
Capacity Indices not included in the file default to zero (i.e., maximum speeds are
not applicable) as do missing or zero values per Vehicle Class as input.
For example, if capacity index 1 refers to a road type where vehicle classes 1 and
2 have normal link-dependent speed-flow curves but vehicle class 3 (HGVs
maybe) has an upper speed limit of 88 kph the relevant (CSV-formatted) record
would read:
1,0,0,88
and the maximum speed of 88 kph would then apply to all user classes associated
with vehicle class 3.
The file is terminated either explicitly by 99999 in columns 1 to 5 or simply by the
end of the file.
As with CLICKS(1) under KLUNK = 0 we anticipate that CLICKS will not apply to
the vehicle class “cars” (generally 1) so that one of the input fields (the first) will be
uniformly zero.
N.B. Note that the input maximum speeds are defined by vehicle class, NOT
by user class.
15.47.2.3 Extra 33333 Data records

To define the maximum speed for a particular combination of vehicle class and
capacity index the user must include a record in the network .dat file, similar to
default speed-flow records per capacity index (15.9.5), under 33333 (see note
(16), section 6.6) with:
(i) The character V in column 1 followed (in free format) by:
(ii) The vehicle class
(iii) The maximum speed (CLICKS) in kph
(iv) The capacity index
Thus the 3 data fields following V may be in any columns as long as they are
separated by either a blank or a comma. However, for “visual” reasons, we would
strongly recommend having the vehicle class in columns 2-5, the maximum speed
in columns 11-15 and the capacity index in columns 43-45 as done (in the latter
two cases) for default speed-flow curves 1. In fact it would make good sense to
include any specific maximum speeds by vehicle class/index immediately after
the equivalent default speed-flow record to make any comparisons of data much
more transparent.
Alternatively they might be contained in a separate file referenced by $INCLUDE.
Note that fields (ii) and (iv) must be integers (as well as, clearly, being valid
numbers) but the speed (iii) may be input as a real value. Normal logic checks
1
Note, if DUTCH=T has been set to permit longer node numbers, the matching columns will be 21-25 and 53-
55 respectively
5120257 / Apr 15 15-119

Section 15
that, e.g., CLICKS speeds are less than normal speeds, etc. etc. are carried out
and error messages produced as necessary.
The V-records will be ignored, in the same way that default speed-flow curves by
capacity index with a D in column 1 are ignored, when the buffer network is built.
Note as well that if any V- records are included under 33333 and KLUNK = 1 then
any reference to FILVSD is ignored; you cannot therefore use both methods to
define KLUNK = 1 data at the same time.
15.47.2.4 KLUNK = 2 (Disaggregate by Link)

Not yet implemented. This will probably be done in conjunction with the 33333
input formats above but per link rather than per capacity index. Thus the HGV
(say) speed-flow curves will be defined independently per link, e.g., as a flat
maximum speed until it intersects with the “normal” speed-flow curves.
15.47.3 Fixed Maximum Speeds: CLIMAX

An alternative to having a fixed difference in travel times per user/vehicle class is
to specify a fixed maximum speed by setting a parameter CLIMAX = T under
&PARAM. If CLIMAX = T then it is assumed that the speed-flow curve for a
particular user (or vehicle) class is fixed at CLICKS independent of the total link
flow until the car speed drops below that value, at which point the car and “other”
speed-flow curves coincide. In other words, the penalty time imposed under
CLICKS is not fixed but gradually reduces from its maximum value at flow equal
zero until it goes to zero at the point where the car speed equals CLICKS.
In almost all cases CLIMAX is used to model fixed speeds for HGV’s which are
less than car speeds under free-flow conditions up to the point where car and
HGV speeds become equal. Whether or not this is a better representation of the
differences between HGV and car speeds is of course up to the user.
In modelling terms the fixed travel time per link applied to, e,g., HGV’s is adjusted
within the simulation-assignment loops within SATALL at the end of each
simulation step, effectively at the same time as the link speed-flow curves per turn
are updated for the next assignment step via the simulation,
For example, consider (as in 15.47.1) a link which is (a) 1 km long, (b) has a
maximum speed (CLICKS) for HGVs of 100 kph and (c) a speed-flow curve
defined with a speed of 120 kph at free-flow. With CLIMAX = F the time penalty
for HGVs would be fixed and equal to the difference between 1/100 and 1/120
hours, i.e., 36 – 30 = 6 seconds. With CLIMAX = T the penalty would be initially
set to 6 seconds but if, at the end of the first assignment, the flow on that link were
sufficient to reduce the car speeds to 110 kph the new HGV penalty would be
1/100 – 1/110 = 3.27 seconds. If car speeds dropped to less than 100 kph the
HGV penalty would go to zero.
By introducing an “interaction” between two different sets of costs and flows on
the same link (in the same way that the delays to minor arm flows at a T-junction
are affected by and interact with flows on the major arm) an extra complication is
introduced into the assignment-simulation loops which, in principle, could lead to
non-convergence and/or multiple equilibria. However, compared to the
interactions that go on within the normal simulation process, the sort of
5120257 / Apr 15 15-120

Section 15
interactions we are talking about here are relatively “weak” and, touch wood,
should not lead to any extra convergence problems. Statistics to demonstrate the
degree of convergence, e.g., the ratio of the total absolute changes in penalties to
the total penalties, are printed each time the adjustments are made and should
converge to (near) zero.
15.47.3.1 Defining CLIMAX

CLIMAX is a Logical variable set in the network .dat files under &PARAM which is
set by individual user classes. Thus CLIMAX(3) = T turns “on” the CLIMAX option
for user class 3. The default is .FALSE. for all user classes.
Setting CLIMAX = T (i.e., no subscript) sets CLIMAX(n) = T for all user classes n
by default unless a specific record is included for an individual user class.
Note that CLIMAX(n) is only relevant if CLICKS(n) has been set. So, unlike
CLICKS, there is no problem with having CLIMAX(n) = T for all user classes since
normally there should be at least one user class to which CLICKS is not applied.
In addition CLIMAX() is a function of user class only and applies to all links (or,
strictly speaking, all links where CLICKS is less than the free-flow speed).
15.47.4 Link Times Incorporating CLICKS

By default the link travel times generally calculated and, e.g., displayed by P1X do
not include any extra times associated with CLICKS for particular user classes; in
effect they represent travel times by cars. Post release 11.3 it is possible to
calculate and display an average travel time representing a flow-weighted travel
time over all vehicle classes. Thus:
T w = t + ∑ u ∆ tu V u / ∑ Vu
Where tw is the weighted travel time
T is the “normal” time
∆ tu is the extra travel time for user class u
Vu is the flow for user class u
Where flows are expressed either in units of vehicles/hr or PCU/hr.
The weighted times are calculated within SATALL once the assignment-
simulation loops have converged and are then stored in DA codes 4008 (weighted
by vehicles/hr) and/or 4018 (weighted by PCU/hr). They may then be viewed in,
e.g., P1X as normal link data.
In the event that all user classes have the same PCU weight, ie., 1.0, both
measures of time are identical and 4008 is not included.
Current applications of weighted times include validation of timed routes (see
11.7.2.1) and joyrides (see 11.8.2.3). Further suggestions are most welcome.
15.48 UNIQUE: Combined Queues within the Buffer Network

The option “UNIQUE” was introduced in 10.7 in order to minimise the double-
counting of V>C delays in buffer networks in certain circumstances.
5120257 / Apr 15 15-121

Section 15
More precisely, consider a series of links A-B-C-D… in the buffer network such
that traffic on A-B can only exit to C (ignoring U-turns to A), traffic on B-C can only
exit to D, etc. etc. Hence all links must be assigned the same demand flow V. If,
say, A-B and B-C both had the same capacity C and V > C then, in reality, one
would expect that a queue of traffic would form on A-B at a rate V-C but that the
capacity on A-B would restrict or “meter” the “actual” flow to B-C to equal C and
that therefore there would not be a second queue on B-C. Hence there should be
a “queuing” delay on the first link but not on any of the flow-metered links
downstream.
However, prior to 10.7 and UNIQUE, the same queue build-up and consequent
ing delay was imposed on all links A-B, B_C, …., hence “double-counting” the
effects of queuing. But, if UNIQUE is set to T within the &PARAM of the .dat file,
the extra delay is imposed at only one of the links (that with the minimum capacity
which therefore represents the true “bottleneck”).
This option is useful if, say, an existing buffer link A-C is split by a mid-link node B
with no other changes and the same link properties apply on both A-B and B-C.
15.49 SATURN Summary Statistics Reporting Tool (SATSTAT)

SATSTAT is a tool used to automatically extract and summarise convergence and
summary performance statistics for each network(s) into a CSV file. The resulting
CSV files may be then be readily imported into the associated MS Excel
spreadsheet and comparisons undertaken between different networks.
SATSTAT consists of two parts: (i) a Fortran 32-bit program to extract the
summary statistics; and (ii) an MS Excel spreadsheet to undertake the
comparisons.
15.49.1.1 SATSTAT FORTRAN Program

For each UFS network(s) selected, the SATSTAT Fortran Program (v3.00) will:
♦ Automatically extract SATURN convergence, assignment/simulation statistics

and queues using the standard reports available through SATLOOK, SATDB,
P1X etc;
♦ Produces summary outputs in MS Excel CSV format of:

♦ Model Convergence (NITA,NITS,%flows, %gaps,%epsilon - SATLOOK
option 8);
♦ Model Runtimes (SATNET, Assignment, Simulation - SATLOOK option
8);
♦ Matrix Totals including Origins & Destinations within Buffer/Sim areas
BUT excluding INTRA-ZONALS;
♦ Simulation statistics (speed/distance/time within this time period /
following time period - SATLOOK option 4)
♦ Assignment / Simulation statistics (speed/distance/time - SATLOOK
option 5)
♦ Average Queue in the Simulation Network (SATDB DA Code 1433)
5120257 / Apr 15 15-122

Section 15
♦ Queue at End of Time period in Simulation Network (SATDB DA Code

1483)
♦ Average Delay / Vehicle (mins) (calculated)
♦ Congestion Index (mins / km) (calculated)

The name of the output file is the network name with a CSV extension (eg
EPSOM98M.CSV).
15.49.1.2 SATSTAT Excel Spreadsheet

In conjunction with SATSTAT, the resulting CSV file(s) may be imported into the
MS Excel spreadsheet called "Summary Report (v3.02).xls" via the "Import CSV"
Visual-Basic macro available in the Summary worksheet. Once the MS Excel
macro is run, it will ask for the name of the CSV file to be imported into the
spreadsheet and become available in the selection box. If selected, the network
stats will appear in the column below both in summary and more detailed form
enabling comparisons to be made between different networks. A demonstration is
available under Test Networks > Option 4 Run SATSTAT for Epsom.
SATSTAT has been successfully tested on all versions of SATURN 10.xx (ie 10.1
to 10.8). Please note that it does not disaggregate summary statistics by separate
user class, only for "TOTAL FLOWS".
15.49.2 Worked Example

A worked example is provided in the "Test Network" menu, option 4 that will run
the SATURN Epsom network for two scenarios (without/with development), run
SATSTAT to extract the summary statistics and open MS Excel (using a
Workspace) and import the two SATSTAT output CSV files.
The SATURN files are located in the sub-directory called “TEST\DEMO –
SATSTAT”. There are two sample networks: a reference case called
EPSOM98AXX.DAT and a development scenario called EPSOM98RXX.DAT.
Below we step through the process rather than running it all automatically.
15.49.2.1 Running SATSTAT in SATWIN

The SATSTAT module is selected for running in the usual fashion as shown below
for SATWIN11; from the Home tab, we can select SATSTAT.
5120257 / Apr 15 15-123

Section 15
This will load-up the SATSTAT module requesting the network(s) that you wish to
extract the summary statistics from:
The two networks we wish to compare are:
♦ Reference Case EPSOM98AXX.UFS; and
♦ Development scenario EPSOM98RXX.UFS.

We now select both these networks to run through SATSTAT as shown below.
Note that in this example, we have changed the Working Folder to
“C:\Users\SWAI2000\AppData\Local\Atkins|SATWIN” but the files may be located
in any folder.
5120257 / Apr 15 15-124

Section 15
We now run SATSTAT and the module will now, for each network in turn:
♦ Run SATLOOK and SATDB to determine the version of SATURN in use;
♦ Run SATLOOK and SATDB to extract the summary statistics; and
♦ Run the SATSTAT Fortran program to generate a summary statistics file in
CSV format.
The output(s) from the process will be a one (or more) CSV files with the same
filename as the network UFS file. In our example, the two output files will be
EPSOM98AXX.CSV and EPSOM98RXX.CSV.
15.49.2.2 Using the SATSTAT Spreadsheet

Once the Summary CSV files have been produced, we may import them into the
SATSTAT spreadsheet, the latest versionof which (at the time of writing) is called
"Summary Report Excel2007 (v4.10).xlsm". The process has however not
changed since the following example (which refers to "Summary Report
(v3.00).xls") as shown below was created. The spreadsheet consists of a number
of worksheets:
♦ A Version Control worksheet – for reference only
♦ A Summary worksheet – this is the main report; and
♦ A number of imported CSV summary files.
5120257 / Apr 15 15-125

Section 15
15.49.2.3 Importing CSV Files

♦ To import our new Summary Spreadsheet files, we select the Summary worksheet
and press the Import CSV button to bring up the Windows File Open dialogue box:
5120257 / Apr 15 15-126

Section 15
We may then select each CSV file, in turn, and these will be imported as new
worksheets into the existing spreadsheet.
Once they have been loaded as new worksheets, we may now select them to be
loaded into the reporting columns in the summary worksheet by clicking on the
Filter box at the top of each column. The summary statistics for that network will
then be summarised in the column below.
Once completed, Table 1 ‘Scenario Reports’ shows the summary statistics for two
networks side-by-side, as show below.
5120257 / Apr 15 15-127

Section 15
15.49.2.4 Summary Reports

At the highest level, the summary reports are available for:
Convergence in the Assignment-Simulation loop
♦ Number of loops undertaken;
♦ %Flows achieved
♦ %GAP achieved
Summary Statistics (post-simulation for TOTAL flows)
♦ Matrix totals excluding intra-zonals;
5120257 / Apr 15 15-128

Section 15
♦ Over-capacity queues;
♦ Link cruise times;
♦ Total travel times
♦ Average speed;
♦ Total delay;
♦ Average delay per vehicle;
♦ Average delay per vehicle-kilometre;
♦ Average trip length
♦ Average simulation queue;
♦ Simulation queue at end of modelled time period; and
♦ Turn penalties.
More detailed comparisons are available within the Summary worksheet by
selecting the second level option to highlight more convergence statistics and, for
example, performance for both the modelled hour and the next time period.
5120257 / Apr 15 15-129

Section 15
15.49.2.5 Importing Additional Networks

♦ This may be repeated for any number of networks. If further reporting columns
are required, an existing column may be copied across as shown below.
EXISTING
EXTENDED
5120257 / Apr 15 15-130

Section 15
15.49.2.6 Comparing Different Networks

We may also compare the summary statistics for each of the different networks
(eg the Development Scenario EPSOM98RXX against the Reference Case
EPSOM98AXX) by specifying the appropriate column ID (ie ‘C’ in this case).
Whilst Table 1 will remain unchanged, Table 2 below will now report on the
Differences and %Differences in the summary statistics (ie this network MINUS
the one with the column ID just selected) as shown below.
5120257 / Apr 15 15-131

Section 15
15.49.2.7 SATURN Versions

SATSTAT will work for all versions of SATURN v10 available i.e., v10.1 through to
10.9. It should operate correctly on any UFS files created under these various
versions as well as undertaking the summary reporting using any of these
versions.
15.50 SATMECC – Marginal Economic Consumer Costs
15.50.1 Basic Theory

The principle of “marginal cost” was introduced in Section 7.11.9 where equation
(7.46) defined the marginal cost for a “separable” cost-flow curve, i.e., one where
the cost of travel on link a is a function only of the flow on link a, as:
Equation 15.16
∂c
a (Va )
c= ca (Va ) + Va a
∂Va
In this section we generalise the concept to allow for “interactions” between

different streams of traffic and therefore “non-separable” cost-flow functions as
modelled by the simulation stage within SATURN. We use the acronym MECC to
stand for Marginal External Cost of Congestion.
However, the basic underlying concept of marginal cost is unchanged: it is the
extra cost imposed on all trips by the addition of one extra pcu (N.B. pcu, not
vehicle) on a particular “link” (where a link may be either a road or a simulated
turn). With separable costs the only other vehicles which are affected by an extra
vehicle on link a are those vehicles already on link a; with non-separable costs the
affected vehicles may be on other links. Unfortunately, since SATURN does not
generate explicit non-separable cost-flow curves of the form c a (V) where V
represents the complete vector of all link flows, we must resort to simulation.
We recall that non-separable or interaction costs only arise from turning
movements at simulation nodes. For buffer links and “pure” simulation links there
are no direct interactions and equations such as (7.46) may still be applied.
The basic method used to calculate marginal costs for simulation turns is to add
one pcu per turn, re-simulate that individual node and to calculate the changed
costs on all turns and/or links at that simulation node. It is carried out by a
procedure (i.e., .bat file) known as SATMECC which, in fact, makes use of special
procedures within SATLOOK. The procedure outputs an ascii file (details below,
15.50.8) with an extension .mec.
SATMECC was first introduced in 10.8 in 2007 and was developed with the
financial support, advice and technical co-operation of GMPTE (Greater
Manchester Public Transport Executive) and GMTU (Greater Manchester
Transportation Unit) whose inputs are gratefully acknowledged.
15.50.2 Marginal Cost vrs Marginal Time

Generalised cost is normally a weighted sum of time, distance and other
components such as tolls (see 7.11.1) but, of these, only time is directly affected
by flows; adding an extra pcu has no impact on link distance, for example.
5120257 / Apr 15 15-132

Section 15
Therefore marginal cost is effectively equivalent to marginal time with a “value of

time” factor (i.e., PPM) to convert marginal time into marginal cost in exactly the
same way that time is converted to cost.
We note briefly at this point, and in more detail later (15.50.5), that the value of
time may differ between different user classes and that we may distinguish
marginal cost by user class.
Within SATMECC outputs are always expressed in terms of marginal time (in
units of seconds/pcu) and it is up to the user to convert to marginal cost if and
when desired. (Indeed it would probably be more accurate to refer to MECT rather
than MECC but we retain the more standard convention.)
15.50.3 Marginal Cost Calculations: Incremental Simulation

MECC values per simulation turns are estimated by (a) carrying out a full
simulation of the “base” to obtain both base delays and base flows per turn and
(b) repeating a full simulation of the node with an additional small increment of
flow ΔV (e.g., 1 pcu) added to the turn in question. (But see 15.50.6 for alternative
procedures in selected circumstances.)
The total value of MECC may be calculated as:
Equation 15.17
MECC=
a ∑V ( d ( l ) − d ( B ) )
i
i i i ∆Va
Where i represents a particular turning movement (link) at that junction (including

a)
V i is the (total) demand flow for that turn
ΔV a is the increment of traffic to the current turn a (either positive or negative)
d i (I) is the simulated delay with the increment ΔV a
d i (B) is the delay in the “base” simulation
Notes:
1) This definition excludes the current cost of link a, i.e., the first term on the
right-hand-side of 7.46. However it is not difficult to add this contribution later
on as required.
2) Strictly speaking Equation 15.16 defines marginal time, not cost since we use
“unweighted” delays in units of seconds.
3) This method can give both positive and negative values of MECC whereas
the use of equations with separable cost-flow curves can only yield non-
negative values. Negative MECC values may seem counter-intuitive but in
fact they occur quite naturally as a result of normal give-way conventions. For
example, consider a roundabout with 4 arms (north, south, east and west)
with a very heavy flow from east to west which effectively blocks all entry
traffic from the south. In these circumstances the only way traffic from the
south can enter is when north-south traffic cuts off entry from the east. Hence
5120257 / Apr 15 15-133

Section 15
an increase in N-S flow can reduce the delays from the south leading to a
negative contribution to MECC which, in turn, can potentially drive the total
MECC negative as well.
15.50.4 Disaggregated Marginal Costs by Turn

The impact of adding an extra pcu on a particular simulation turn may be
disaggregated into increased delays to:
(a) pcus making that particular turn,
(b) other turning movements from the same arm and
(c) turns out of other arms at the same junction.
MECC is the sum of all three impacts.
We refer to these three disaggregate contributions as “own-MECC”, “arm-MECC”
and “interactive-MECC”.
15.50.5 Disaggregated Marginal Costs by User Class, Vehicle Class, etc.

If we wish to consider the marginal impact of increased flows on a particular link
on, e.g., one particular class of flows – as opposed to the total flow on links as
implied by the definition of V i in equation (15.16) – it is simply a question of re-
defining V i as the flow for that user class. Equally we could define marginal cost
for a particular class of flows such as buses.
Note that user class is defined here in terms of the class of vehicles affected as
opposed to the class of vehicles which is causing the changes. In particular, if we
increase the flow on link a by 1 pcu it does not matter which class of vehicles is
being increased since, say, 1 pcu of user class 1 has the same effect within the
simulation as 1 pcu of user class 2.
Note that in this context it is very important to distinguish between marginal cost
and marginal time since the conversion between the two will depend on the value
of time defined for that user class. If – as is most likely the case – users require
the total marginal cost in terms of, say, pence as opposed to total marginal time
then it is necessary to calculate marginal time for each individual user class,
weight that by the appropriate value of time for that class and then sum over all
user classes. It is not really possible to define an “average” value of time since the
distribution of flows by user class will vary by turn.
By a similar token please note that MECC is always calculated per pcu and that
different user classes may also have different values of pcu/vehicle. Again it is up
to the user to take account of these factors in terms of translating SATMECC
outputs into actual toll per vehicle.
15.50.6 Alternative Modifications to Incremental Simulation

There are a variety of circumstances under which the simple “add a pcu”
simulation method may give unreliable results (where “unreliable” generally
means extremely high absolute values). Therefore a number of “alternatives” have
been included within SATMECC as follows:
5120257 / Apr 15 15-134

Section 15
1) If the turn is over capacity in the base simulation we do not have to perform
a second simulation to calculate MECC since the main impact of an extra
pcu on an over-capacity link is essentially to make the queue on that arm
one pcu longer rather than changing the flows through the node. Thus we
may combine equations (7.46) and (8.5b) (or (8.11b) in the case of shared
lanes) to obtain:
Equation 15.18
MECC = ( LTP 2 ) V C
2) If the turn is “almost at capacity” (strictly 90% < V/C < 100% then a negative
increment of 1 pcu is used in the first instance rather than an increase of 1.0.
(But see point (7) below.)
3) If the turn has zero or very low flow (arbitrarily under 5 pcu/hr) the turn is
simulated at flows of, say, 5.0 and 6.0 pcus/hr as opposed to, say, 0.0 and
1.0 pcus/hr since, very often, there can be very highly significant changes
between no flow and a very small flow. This is particularly true of X-turns at
signals, even more so when they come from a single lane with other shared
movements.
4) If the addition of +1 pcu takes a turn beyond capacity then the increment is
reduced so as to go only “halfway” to capacity.
5) In order to minimise any problems of “noise” in the two simulations (if we are
looking at two very similar flows any “errors” in delay calculations will be
magnified) we convert the value of NUC applied at signalised junctions to a
large value. In particular this has proved to be essential for junctions with
very short signal phases and/or X-turns.
6) If, for whatever reason, a node does not converge to the required limits (see
8.3.2) even with any changes to NUC, etc. its convergence is judged to be
“poor” and, rather than permit any noise to creep into the calculations, its
MECC values are calculated using its separable cost-flow curve and
equation (15.15) above. This is probably an underestimate of the total
MECC since it exclude any interactions with other turns at that junction but
this is felt to be preferable to introducing random errors. In most networks
the number of “poorly” converged nodes is probably well under 1%. (A
higher percentage of poorly converged nodes may be an indication of
slightly dodgy coding practice.)
7) As an example of belt’n’braces and to cope with various “noise” problems
which empirically are observed to occur even with all the above rules, for
priority and signalised junctions, whenever both positive and negative
increments are feasible, we carry out two increments, both plus and minus 1
pcu, and take the minimum of the two MECC values. (In almost all cases
the two give virtually equal answers but there are odd examples when one
result appears to be unreliable and we prefer to believe the lower values.)
8) Turns at simulation dummy nodes experience zero delay by definition and
therefore zero marginal costs. They are included in the output .mec files with
values of zero. Similarly bus-only links and/or turns are assigned zero
MECC values.
5120257 / Apr 15 15-135

Section 15
15.50.7 Marginal Costs on Links

In addition to calculating marginal costs on simulation turns SATMECC also
calculates marginal costs for “pure” links (i.e., roads A-B as opposed to turns A-B-
C) which are (a) in the buffer network or (b) simulation links with capacity-restraint
speed-flow curves. In both cases it is only necessary to use equations (7.47a)
and/or (7.47b). Note that simulation links which do not have speed-flow curves
are excluded.
Links are included within the output .mec file (see 15.50.7) and are identified by a
value of 0 in the third node field; i.e, A B 0 as opposed to A B C for simulation
turns.
Simulation links without capacity-restraint speed-flow curves are totally excluded
as are all centroid connectors.
15.50.8 The SATMECC Batch Control File

A special batch file SATMECC.bat has been set up in order to carry out the
calculations detailed above making use of the program SATLOOK. Its
specification is as follows:
Call: SATMECC network (UC n KR control
Files: network.ufs Input network file
Network.mec Output ascii file of MECC values
Network.LPL Output line printer file from SATLOOK
Control.dat Control file (Optional)
UC n (optional) requests that the calculations be carried out for user class n and
the output file will be network.ucn.mec. UC * requests a loop over all user classes
to produce files network.uc1,mec, network.uc2.mec, etc. etc.
Output .mec files contain 8 “fields” formatted as follows:
Field 1 A-node
Field 2 B-node
Field 3 C-node (for a turn; 0 for a link whether simulation or buffer)
Field 4 The “base” delay to turn A-B-C in seconds
Field 5 The total MECC in seconds (N.B. marginal time, not cost)
Field 6 “Own” MECC
Field 7 “Arm” MECC
Field 8 “Interactive” MECC
For “pure” links A-B (i.e., simulation or buffer links) fields 7 and 8 are blank.
Note that Fields 1, 2 and 3 all occupy 6 columns in order to improve legibility for
networks which have up to 5-digit simulation node numbers. This may cause
5120257 / Apr 15 15-136

Section 15
problems in input to certain SATURN programs where the convention is to have 5

columns by default. Note that the latest 10.8 version of SATDB allows either 5 or
6 column node fields under the input of miscellaneous text files.
If DUTCH = T and the maximum node number used in the buffer network exceeds
5 digits then the first two fields occupy 9 columns each and the third (which is zero
by definition) occupies 2 columns (i.e., 0 in column 20).
In general MECC values are printed with two decimal places (with units of
seconds) although, in some extreme cases, there may not be sufficient “width” in
the format to permit two decimal places, in which case MECC is printed in an E-
format.
15.51 Running SATURN within DIADEM

The DIADEM suite of programs has been created by Mott-MacDonald under
contract to the DfT to provide demand matrix calculations linked to various traffic
assignment programs. In particular Diadem has been linked with SATURN such
that Diadem calculates vehicle trip matrices which SATURN may then assign. See
Section 7.4.5 for a discussion of the general VDM principles involved and for
suggestions as to how to make the overall process more efficient.
Full documentation on Diadem and its linkages with SATURN are provided by the
Diadem documentation.
Generally the procedures for running SATURN programs within Diadem are
controlled by Diadem itself. However, there are various options within SATURN
programs which may assist in achieving a well-converged solution with minimal
cpu and which either users may set themselves in their network .dat files and/or
Diadem developers may incorporate within the internal control procedures.
It is highly recommended that Diadem users ensure that they are running the most
up to date releases of SATURN since some of the features listed below are fairly
recent additions.
QUIET – This option enables SATURN programs such as SATALL to run totally
in “the background” without interrupting anything else. See 14.9
NDPS – This controls the number of decimal places used to output skimmed
matrices in TUBA Format 2. Large values, e.g., 4, are recommended to avoid
convergence problems due to rounding off but, in older releases of SATURN, this
could cause problems of “overflow” if a numerical skim value required more than
10 columns including decimal places. Corrected in 10.7. The current default
number of decimal places is 5. See 10.15.2 and 15.41.4.
DIADEM parameter. Setting DIADEM = T under &OPTION (N.B. not &PARAM) in
a network .dat file at the same time that UPDATE and/or WSTART are also T
means that, if the file to be updated as set in UPFILE does not exist, UPDATE
and/or WSTART are ignored. Normally a missing UPFILE is a semi-fatal error. In
the context of DIADEM this allows the same network .dat file to be used to build a
network for both the initial assignment and for later assignments where the
UPDATE/WSTART options may be invoked to update/warm start the previous
network. See 6.1.
5120257 / Apr 15 15-137

Section 15
XCL ON COMMAND LINES This feature allows more than 9 arguments per
command line. In the particular context of DIADEM this increases the number of
matrices which may be stacked and unstacked but the number is still potentially
limited. See 14.8.
UFMSTACK AND UFMUNSTACK These new bat files allow matrices to be
stacked and/or unstacked with, effectively, no limit on the number of levels / user
classes which may be accommodated. See 10.20.17 and 10.20.18.
SAVEIT – Unless you specifically need to create skimmed matrices of time,
distance, etc. in order to run the demand model within DIADEM (which, in general
terms, we do not recommend; see 7.4.5.3 and 7.8.6) or you are using a warm
start we recommend that you set SAVEIT = F and avoid the excess CPU of
creating .UFC files which will not be used at the end of each run of SATALL. Note
that, if required, a .UFC file can be created at the very end by running the
procedure SATUFC (see 15.23.5). (N.B. This does not apply under OBA where
the overheads associated with SAVEIT = T are minimal.)
SKIM_ALL – If, however, the Diadem model requires skimmed matrices of time,
distance and/or tolls on each supply-demand loop it will save CPU time to use the
simultaneous skimming procedures embedded in SKIM_ALL (see 15.27.7) rather
than skimming each component separately.
Further general advice on linking SATURN with external variable demand models
such as Diadem as given in Section 7.4.5.
Users may also wish to note that the “%Gap” convergence measure used within
Diadem has an equivalent measure within SATEASY, i.e., TxCij-AAD as referred
to in Section 7.5.5.
15.52 Running SATURN in Parallel

From SATURN v10.7 onwards, a new feature was introduced that enabled users
to take advantage of desktop PCs with more than one core and/or processor.
This was intended as stop-gap measure until development work on modifying the
SATURN source code to access more than one core was completed during early
2009. Subsequent testing has demonstrated that the process is also compatible
SATURN Multi-Core and enables the maximum use of all the cores available.
The software was developed in response to a need to reduce runtimes for
demand models where there is a requirement to undertake independent highway
assignments by time period (e.g., separate morning peak hour, inter-peak hour
and evening peak hour models) and to subsequent skim various permutations of
travel costs and/or demand for use in WebTAG-based compliant models.
The recent advances in PC-based desktop hardware has resulted in Intel-based
Core2Duo/ Nahlem / Sandy Bridge chips becoming the norm (amongst others)
and the existing methods of using SATURN to undertake tasks sequentially does
not utilise any of the other cores available as illustrated below in Figure 15.6 and
Figure 15.7..
5120257 / Apr 15 15-138

Section 15
Figure 15.6 – Traditional Sequential Operation
Figure 15.7 – Advantages of Multi-Core Processors
15.52.1 Additional Programs

Parallel runs can be performed with the aid of two programs: MONITOR and WAIT
5120257 / Apr 15 15-139

Section 15
15.52.1.1 Monitor
MONITOR takes a snapshot of all running processes in Windows at regular (user
specified) intervals and checks if a user specified program is still running. The
program terminates when the user specified program is not one of the currently
running processes. MONITOR takes two parameters:
♦ Parameter 1 – the SATURN program to run in parallel (eg $SATALL.EXE).
♦ Parameter 2 – the time interval (in seconds) for taking snapshots of running
processes to determine if the SATURN program specified by parameter 1 is
still running (eg 10).
15.52.1.2 Wait
WAIT (used within a batch file) causes the batch file to pause (where it is called)
for a user specified number of seconds before the batch file proceeds to the next
command. This introduces a short pause before the next instance of the
SATURN program that is to run in parallel is called. In other words, if the user
wishes to run two instance of $SATALL, the user should request a small pause
between the first and second runs commencing to prevent potential file access
errors arising. Note that WAIT has to be used within a batch file – it will not ‘wait’
as a single command line call.
15.52.2 An Example
An example of a batch file to undertake a ‘parallel’ run of the SATURN module is
annotated below (but the process would also readily work with other SATURN
modules including $SATALL, $SATPIJA, $SATLOOK, $SATME2, and $SATEASY
for example).
The batch file should contain the following commands:
PATH = C:\SATWIN\XEXES
1) sets the path to the folder containing SATURN programs (if required)..
SET INPUT1=EPSOM5000
2) sets the input parameter for the first SATURN run as an environment
variable. In this example, the network and matrix file have the same root
name (i.e. EPSOM5000.UFN and EPSOM5000.UFM), hence only one
environment variable (i.e. INPUT1) is required. If the root names were
different, two environment variables would have been required: one for the
UFN file and one for the UFM file.
SET INPUT2=EPSOM5001
3) sets the input parameter for the second SATURN run as an environment
variable. The root name of the network and matrix file is the same in this
example; hence, one environment variable is required as in 2.
START SATURN %INPUT1% %INPUT1%
4) starts the first SATURN run.

WAIT 5
5120257 / Apr 15 15-140

Section 15
5) Waits for 5 second to avoid simultaneous access to SAT10KEY.DAT

START SATURN %INPUT2% %INPUT2%
6) starts the second SATURN run

START /W MONITOR $SATALL 10
7) starts monitoring $SATALL.EXE every 10 seconds and MONITOR

terminates if $SATALL.EXE is not found in the latest snapshot of running
processes controlled by the Windows Operating System.
8) SATURN MULTI-CORE applications are multi-threaded versions of existing
programs that are able to take advantage of the additional processors (either
in the form of physical cores or virtual threads) available on most Intel /
AMD-powered standard desktop PCs.
The ‘start’ command will open a new command shell to run SATURN every time it
runs. If the user wishes each command shell to be closed at the end of the
operation, create a copy of the existing SATURN.BAT and add an extra line at the
end saying “EXIT”. So for example, if the amended batch file was called
“SATURNEXIT.BAT” the revised command line would be:
START SATURNEXIT %INPUT2% %INPUT2%
15.53 SATURN Multi-Core Applications

SATURN MULTI-CORE applications are multi-threaded versions of existing
programs that are able to take advantage of the additional processors (either in
the form of physical cores or virtual threads) available on most Intel / AMD-
powered standard desktop PCs.
SATURN MULTI-CORE is a separate, low-cost add-on to the standard suite and
may be accessed through an updated set of executables (and system files). The
control of the multi-threaded processors is automatically undertaken by the
program and the Operating System.
Multi-processor applications may be sub-divided into two categories:
a) those programs that allocate calculations to separate threads internally
within the processor(s) and therefore need to be linked with certain
routines compiled using IVF as opposed to Salford Fortran, and
b) those where the allocation to separate threads is handled at the level of
the batch file but the same basic program exe is used for each thread
(“distributed processing” as previously described in Section 15.52).
Applications under (a) require distinct EXE files, those under (b) require special
.bat files identified with the ‘_MC’ suffix.
In principle method a) should be faster and more efficient than method b) but, on
the other hand, it requires specially compiled versions of the .exe files whereas
method b) uses the standard exe’s but with “clever” batch files. Method a) works
by allocating tree-building etc. operations by origin between processors, method
b) works at a much more aggregate level by allocating, say, calculations per user
5120257 / Apr 15 15-141

Section 15
class to separate threads (and therefore is most efficient if the number of threads
available equals the number of user classes).
15.53.1 Programs Available

SATALL was the first program to be modified to function with multiple parallel
processors and was first released with version 10.8.22. Since then, further
development work has been undertaken to expand the number of programs
available with multi-threaded capability as detailed below. The development work
was completed with the release of 11.2.05 in March 2013.
Program Status How to Access? Version Comment
The assignment routines are

Replacement
Final v10.8.22 multi-threaded internally
SATALL $SATALL.EXE and
Release onwards whereas, the simulation
set MULTIC=T
remains unchanged
Replacement Various skimming options may
Final v10.9.22
SATLOOK $SATLOOK.EXE and be run using multiple threads
Release onwards
set MULTIC=T in parallel. See 15.53.3.2.
Replacement Generation of .UFO from

$SATUFO.EXE and existing .UFC undertaken
Beta set MULTIC=T v11.1.02 using multiple threads in
SATUFO
Release (and/or embedded onwards parallel. Replaces previous
within $SATALL.EXE distributed SATUFO_MC
if SAVUFO=T process.
Undertaken using a
distributed version whereby
the PIJA process is split by
“blocks” of origins and multiple
New versions of SATPIJA run for
Final SATPIJA_MC.BAT v10.9.22 each. A final SATPIJA run
SATPIJA_MC combines the individual
Release and onwards
$SATPIJA_MC.EXE datasets into a single file.
The management of the
process is undertaken
automatically by the software.
See 15.53.3.3.
New Multi-distributed as per
Final SATCH_MC.BAT v10.9.24 SATPIJA with each user class
SATCH_MC
Release and onwards undertaken on a separate
$SATCH_MC.EXE thread; See 15.53.3.6
(Secondary (See SATUFO

(Undertaken using UFO files)
Analysis) above)
15.53.1.1 SATALL Multi-Core Restrictions

We note that the multi-core facilities within SATALL do not (yet) work with every
possible combination of assignment options. Thus it does not work with any form
of elastic assignment, with stochastic assignment (SUZIE = T) or with
networks which incorporate Motorway Weaving Segments (Section 15.40). If
5120257 / Apr 15 15-142

Section 15
there is sufficient demand to include such options it will be considered for future
inclusion.
SATALL also does not work with either path-based or origin-based (OBA)
assignment because the theoretical principles of these algorithms require them to
be undertaken in a purely sequential process.
In addition multi-core requires that there is sufficient RAM provided to store the full
trip matrix in core; with certain matrices it may therefore be necessary to set a
control parameter SPARSE = F to select a more efficient system for matrices
where more than 50% of the Tij cell values are positive. See 7.11.12.
15.53.1.2 Numerical Differences between Multi-Core and Standard Programs

The development work required the computational intensive sub-routines to be
modified so that they may be undertaken in parallel. The work also required the
modified source code to be created separately using a different software compiler
than the standard release (specifically Intel Virtual Fortran rather than Salford).
An unavoidable consequence of using a different compiler is the introduction of
very small differences in the numerical precision that the internal calculations
within the assignment are stored in their respective versions. The differences
should, generally, be too small to spot but there may be some cases where, like
the analogy of a butterfly flapping its wings, the two may give detectable, even
significant, differences although each will be perfectly valid solutions.
Consequently, the results from the SATALL MC executable may be different
from the standard version.
However, the other executables that undertake the secondary analysis, should not
be affected as they are either (i) only re-building the existing stored paths rather
than undertaking new assignments; (ii) undertaking the analysis for each user
class in parallel using the same process.
15.53.2 Processors, Cores and Threads

Processors (or ‘Central Processor Units’ (CPUs) to give them their full name)
provide the computing power for the Personal Computer (PC). The processor
undertakes the tasks as specified by the Operating System (usually a version of
Windows) and the software programs using the Operating System. The processor
may have a single or multiple cores with each core capable of running
independently to provide additional computing power. Most Desktop PCs will
have at least two cores but four is becoming more common with higher-end
systems having six or more cores.
Cores and threads are often used interchangeably even though they are
fundamentally different. This has implications for the performance gains available
from multi-threaded applications.
Cores are physical hardware blocks in the central processor unit (CPU) that can
run applications serially whereas threads aren’t physical but are software-
generated tasks that can be undertaken independently. The computing power of
each core is a fixed quantity available for use. In day-to-day applications, not all
of the processing power available may be fully used if a software-generated
thread is paused or stopped whilst waiting for data so some of the processing
5120257 / Apr 15 15-143

Section 15
power may be unused and ‘wasted’. However, running two threads on the same
core enables the second thread to take advantage of this ‘spare’ processing
power whilst the first thread was waiting for data. Whilst running two threads on a
single core reduces wastage it is not a substitute for having additional physical
cores instead
There are various different propriety names for this technology - Intel’s Hyper
Threading (HT) technology, available on most of their medium and high-end
processors, is probably the most widely known. Intel HT uses this principle
whereby each physical core is able to run two threads simultaneously.
As far as SATURN Multi-core applications are concerned, its applications will
automatically generate N threads (either up to the maximum available as defined
by the operating system, the user-defined MCNUM parameter or the maximum
number of threads that the application may be broken down into as defined in the
batch files) so that tasks may be undertaken simultaneously. The Windows
Operating System takes the threads generated by the SATURN application(s) and
schedules them to run on the threads available. No further user intervention is
required.
15.53.3 Performance Gains

The performance gains available are dependent on a large number of variables
namely:
♦ PC hardware including the processor, operating system and RAM available;
and
♦ Model size and configuration particularly with the number of zones and user
classes.
The performance testing across a range of different sized SATURN models
demonstrated the significant reductions in model runtimes available with SATURN
Multi-Core. In the following paragraphs, examples are provided for a medium
sized model on a high performance desktop PC.
Typically, the multi-threaded applications reduced the overall model runtimes by
up to 1 / N where N was the number of physical cores available (depending on the
size and type of network and the assignment parameters used). For example, on
a quad-core machine, the model runtimes on various test networks were reduced
by up to a factor of four.
Note that all the tests were undertaken on the same HP XW8600 workstation (2 x
Intel Xeon X5450 3GHz with 4Gb RAM running Windows XP 32-bit). The
processors provided eight physical cores with each core able to handle one thread
each (i.e. no Hyper-threading option was available on these particular
processors).
15.53.3.1 SATALL (Multi-threaded)

The performance gains available with the multi-threaded version of SATALL are
shown below in Figure 15.8. The overall reduction in the total CPU time for
SATALL was reduced by up to 3.5 times on a Quad-core PC. With an extra fifth
core available, further reductions in model runtimes were achieved but with six or
more cores, the model runtimes marginally increased in this example.
5120257 / Apr 15 15-144

Section 15
Figure 15.8 – Example of SATALL Performance (Medium Size Network)
100%
90%
CPU Ratio
% of Existing Single Core Runtime
80%
70%
1/N
60%
50%
40%
30%
20%
10%
0%
1 Core 2 Cores 3 Cores 4 Cores 5 Cores 6 Cores 7 Cores 8 Cores
The assignment undertaken using SATALL involves an iterative looping process

between successive assignment (for tree-building and loading) and simulation (for
junction interactions). However, only the main assignment routines are undertaken
in parallel and therefore the benefits of SATALL Multi-core are dependent on the
time taken within the assignment and simulation routines. Similar results were
found in other models but the performance gains will be dependent on a large
number of variables including the PC hardware available and the SATURN model
used.
SATALL Multi-Core is also compatible with Network Aggregation techniques (see
Section 15.56) and the performance gains are independent (and hence, typically,
multiplicative). Further information may be found in Appendix S.
15.53.3.2 SATLOOK Skims (Multi-threaded)

At present multi-threaded versions of SATLOOK may only be run within a limited
number of applications / batch files which skim costs; specifically: SKIMTIME,
SKIMDIST, SKIMPEN, SKIMTOLL, SKIM_ALL (see 15.27.7) and SATTUBA (see
15.41.1).
The performance gains for such routines are similar to those produced by
SATALL with reductions of up to 3.5 times on a Quad-core PC (see Figure 15.9
for applications of SKIM_ALL). Performance benefits continued to improve with
five cores but there was some erosion of the gains beyond six cores.
5120257 / Apr 15 15-145

Section 15
Figure 15.9 – SATLOOK Performance (Medium Size Network using SKIM_ALL)
100%
90%
CPU Ratio
80%
70%
1/N
60%
50%
40%
30%
20%
10%
0%
15.53.3.3 SATUFO (Multi-threaded)

SATUFO Multi Core may be used to create a network .UFO file from a .UFC file
(see 15.23.7). The same implementation is used as with SATALL and SATLOOK
skimming. The .UFO file may be created as part of the main SATALL assignment
by setting SAVUFO=T and MULTIC=T or, alternatively, as separate standalone
process following the main assignment via the batch file SATUFO.BAT (with
MULTIC=T previously used in the main assignment).
15.53.3.4 SATPIJA_MC (Distributed)

Unlike the SATALL, SATLOOK and SATUFO Multi-Core applications, SATPIJA
uses a distributed approach whereby the creation of the PIJA file from the
assignment is split into ‘N’ blocks of zones (see 13.4.9), with each block
undertaken by a separate run of SATPIJA. Each SATPIJA run is undertaken in a
separate sub-directory (or ‘production folder’) and an extra (short) SATPIJA run is
undertaken at the end to combine the ‘N’ (smaller) PIJA files into a single file.
The process is automatically controlled by a new SATPIJA_MC batch file (13.6.3)
so, in theory, there are no changes to either the basic program, $SATPIJA.EXE,
or to its associated batch file, SATPIJA.BAT (13.6.2).
As with SATALL, the performance benefits will vary between models and the PC
hardware available. The splitting of the production of the PIJA into zones blocks
is (currently) undertaken based on the sequential zone numbers and the
distribution of trips in the matrix is unlikely to be equally shared between the
blocks of zones. In addition, for each of the SATPIJA runs, the network, matrix
and control files need to be copied to/from the ‘production folders’ which will incur
a performance ‘hit’.
The performance of the distributed SATPIJA_MC on a very large SATURN
network is shown below in Figure 15.10. As noted above, the potential benefits
will be dependent on the model and PC hardware used.
5120257 / Apr 15 15-146

Section 15
Figure 15.10 – SATPIJA_MC Performance (Very Large Network)
100%
90%
CPU Ratio
80%
70%
1/N
60%
50%
40%
30%
20%
10%
0%
15.53.3.5 Performance Scaling

As illustrated in the figures above, the practical testing showed that there were
(typically) negligible performance benefits over and above the use of five cores.
This ‘throttling’ of the performance arises due to the limited memory available
within the internal CPU Level 1/2/3 caches.
Conversely practical testing on other hardware systems (such as Blade servers)
shows further performance benefits arising with six or more cores. The
performances gains are clearly dependent on the SATURN model and computer
hardware used.
15.53.3.6 Running More than One Multi-Core Assignment

In Section 15.52, we describe how SATURN may be used (and controlled) to
undertake parallel operations. The same procedures may be used with SATURN
Multi-Core without any change to those procedures.
15.53.3.7 SATCH_MC: Distributed Trip Matrix Cordoning

A distributed procedure SATCH_MC may be used to create a multiple user class
cordoned trip matrix by creating cordoned matrices by user class within separate
processors and then finally creating a full stacked trip matrix by stacking the
individual sub-matrices using MX. See 12.1.6.
15.53.4 Multi-Core Parameters
15.53.4.1 Options
To activate the multi-threaded operations within SATALL and SATLOOK once
installed, the &PARAM namelist parameter MULTIC is set to TRUE in the network
.dat file and the Windows Operating System handles the allocation of the
computational calculations between the available threads available. The value of
5120257 / Apr 15 15-147

Section 15
MULTIC parameter is stored in the network binary files (.ufn/s) and the value read
by SATALL, SATLOOK, etc. where necessary.
An additional (integer) namelist parameter MCALG selects one of a set of optional
algorithms which are basically provided for internal testing. We recommend the
default value of 1.
A further (integer) &PARAM Namelist parameter MCNUM defines the maximum
number of core processors to be used on the computer; default 0 (meaning use all
available threads). See 15.53.4.2 below.
For the other Multi-Core programs (i.e. SATPIJA, SATCH and SATUFO), the
Multi-Core batch files have to be used.
15.53.4.2 Upper Limit on MCNUM Values

The SATURN-MC will require more memory than the standard versions
dependent on the number of threads available. Within the software, there is no
restriction set on the maximum number of threads that may be used. For the
distributed processes, a practical limit of 8 (eight) was coded but for version 11.3
onwards, the limit was increased to 32.
15.54 SATURN CASSINI
15.54.1 Overview
CASSINI is a Visual-Basic program developed to significantly reduce SATURN
runtimes when SATURN is used within a Variable Demand Model such as a
simple DIADEM model or a more complex, bespoke modelling system. See
Section 7.4.1 for a general discussion of the problems of convergence between
supply (i.e., assignment/SATURN) and trip matrix demand models and Section
7.4.5 for a description of the iterative “cobweb” loops between supply and demand
models whose runtimes CASSINI seeks to “optimise”.
CASSINI enables the user to automatically adjust the convergence targets set for
each run of SATURN to match the current level of convergence achieved for the
supply-demand “cobweb” loops. Typically, a ‘relaxed’ set of convergence criteria
would be set for the initial loops when supply-demand convergence is poor and
the trip matrices are still highly uncertain but these would be subsequently
tightened as the overall model convergence improves; in other words, reducing
the ‘over-convergence’ within the supply model (i.e., SATURN).
See section 7.4.5.3 for a more general discussion of the principles applied by
CASSINI.
Appendix R contains a copy of the ETC2009 paper that describes the practical;
benefits of CASSINI within a full WebTAG-compliant demand model.

Given a fixed trip matrix SATURN uses internal loops between its assignment and
simulation sub-models as well as internal iterations within the two sub-models in
order to achieve an overall equilibrium solution in terms of path-flow choices as
best represented by its “gap value” (see 9.2.1).
5120257 / Apr 15 15-148

Section 15
A characteristic of the process is a rapid initial descent before a much more

gradual approach to a highly converged solution as shown in Figure 15.11 below.
In this example, to achieve a %GAP value of 0.05 requires around 20 times the
CPU time to achieve a %GAP of 5.0, eight times the time to achieve a %GAP of
1.0 and four times the time to achieve a %GAP of 0.5 respectively. Clearly,
significant CPU savings may be achieved by (appropriately) reducing the
convergence targets for the SATURN highway model where possible.
Figure 15.11 – Typical SATURN Model Convergence Profile
%CPU Time
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
9.00%
8.00%
7.00%
6.00%
5.00%
%GAP (Assignment)
4.00%
3.00%
2.00%
1.00%
0.75%
0.50%
0.25%
0.10%
0.05%
However, SATURN may also be embedded within a larger demand model

structure (aka VDM Shell) in which the trip matrices are not fixed but are variable
and cost-dependent and this larger model structure must also converge to an
equilibrium solution (see 7.4.1). Typically some form of cobweb loop between
supply (assignment) and demand (see 7.4.5) is used in order to achieve
equilibrium between the two sub-models as illustrated in Figure 7.8.
We may quantify the degree of convergence between successive loops of the
demand models by a “supply-demand gap value” as given in TAG Unit M.2 and
defined by:
GAP − SD =
∑ ijctm ( )
C ( X ijctm ) D C ( X ijctm ) − X ijctm
*100
∑ ijctm C ( X ijctm ) X ijctm
where:
♦ X ijctm is the current flow vector or matrix from the model
♦ C(X ijctm ) is the generalised cost vector or matrix obtained by assigning that
matrix
5120257 / Apr 15 15-149

Section 15
♦ D(C(X ijctm )) is the flow vector or matrix output by the demand model, using the
costs C(X ijctm ) as input; and
♦ ijctm represents origin i, destination j, demand segment/user class c, time

period t and mode m.
The convergence profile of GAP-SD over cobweb loops is similar to the
assignment profile of GAP over internal loops, i.e., decreasing rates of
improvement as convergence improves, as shown below in Figure 15.12.
The objective of CASSINI is therefore to minimise the overall CPU time required in
order to achieve a satisfactory degree of convergence within both SATURN (the
supply model) and the supply-demand model; i.e., both GAP and GAP-SD must
be sufficiently near zero at the end of the process. (We assume here that the CPU
time required to run the demand model on its own (i.e., to produce the new set of
trip matrices) is effectively fixed per loop and that internal convergence within the
(pure) demand model is not an issue.)
CPU may be reduced by either reducing the time per SATURN run and/or by
reducing the total number of cobweb loops (or, as it turns out, by reducing the
former and not increasing the latter too much). We achieve this by noting that it is
not efficient to spend a lot of CPU obtaining a highly internally convergent
SATURN assignment for a particular trip matrix if that trip matrix is then going to
be considerably changed by the next supply-demand loop. For example, there is
no point in having link flows accurate to +-0.1% if trip matrix cells are varying by +-
10%.
We therefore apply a principle of “relaxed convergence” (see 7.4.5.3) by
specifying relatively easy convergence criteria for the initial SATURN runs when
the trip matrix to be assigned is still “in flux” but to tighten up those criteria once
the demand trip matrices begin to stabilise. While this may potentially increase the
overall number of cobweb loops required to achieve convergence the expectation
is that that increase will be more than offset by the CPU saved on earlier loops
where internal SATURN convergence is much faster.
We may note that this process of “relaxed convergence” is very similar to that
used by AUTONA (see 9.5.4) whereby we set “easy” assignment stopping
conditions when the assignment-simulation loops are poorly converged (in order
to minimise assignment CPU) but tighten them up as the assignment-simulation
convergence improves.
By setting a more relaxed highway convergence target for the early cobweb loops
using CASSINI, considerable savings in CPU time may be achieved as the ‘over-
convergence’ of the highway assignment is reduced. These two convergence
profiles are also shown below in Figure 15.12.
5120257 / Apr 15 15-150

Section 15
Figure 15.12 – Typical Demand Model Convergence Profile
70%
%GAP (Supply/Demand) 60%

Demand Model (%GAP)
50%
SATURN-CASSINI Convergence
(%GAP=Variable)
40%
30%
Standard SATURN Convergence
(%GAP=0.05)
20%
10%
0%
1 2 3 4 5 6 7 8 9 10 11
Demand Model Loop
15.54.3 Performance Gains

With CASSINI introduced, the demand model usually requires a few more loops to
achieve the same %GAP-SD value of <0.2 (say) – typically an extra three or four
loops reflecting the slower descent in this example. Nevertheless, there was an
overall saving of around 50% in the total CPU time required compared to the
standard method as shown below in Figure 15.13.
Figure 15.13 - Comparison of Highway Model Runtimes by Demand Loop
25.00
Standard
20.00 CASSINI
Cumulative SATURN CPU (hrs)
15.00
Time Saving
10.00
5.00
0.00
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Demand Model Loops
15.54.4 Compatibility with SATURN Multi-Core

CASSINI is fully compatible with SATURN Multi-Core, the new multi-threaded
version of the SATURN assignment program. The recent testing work using the
5120257 / Apr 15 15-151

Section 15
GBMF modelling system demonstrated that using Multi-Core has reduced overall
CPU times by a further 25% as shown below in Figure 15.14 below.
Figure 15.14 – Performance of CASSINI and SATURN Multi-Core
40.00
35.00
Total CPU for all Operations (hrs)
30.00
25.00
20.42
Time Savings
SATURN
20.00
Demand
47% 63%
15.00
8.78
4.03
10.00
13.82
5.00 9.52 9.52
0.00
Standard Method (Parallel Plus CASSINI Plus CASSINI & Multi-Core
Assignment)
15.54.5 Convergence Strategies

To operate CASSINI, the user needs to define the convergence strategy that
describes how the SATURN convergence parameters should change in response
to improving convergence in the trip matrices. As shown earlier in Figure 15.12,
the convergence parameters adopted for the early loops should be relaxed and
progressively tightened as the demand model convergence improves.
If the assignment convergence strategy is too relaxed then the supply-demand
model may not converge whereas setting too tight convergence criteria for the
initial loops may over-converge the highway assignment and ‘waste’ CPU time.
As such, it is a balancing act but it’s better to err on the side of caution and over-
converge the assignment (as a fully converged model remains the ultimate goal).
15.54.6 Running SATURN CASSINI

In normal operation, the CASSINI program is usually called internally within
SATNET and produces a supplementary ASCII data file containing eXtra
Convergence Parameters (.XCP) which propose new values for the relevant
convergence parameters such as MASL, etc. etc. SATNET then reads in this new
XCP file before fully processing the main network data file - the parameters in the
XCP file overwriting those contained in the network data file. CASSINI is
activated in SATNET by setting the parameter CASINI=T under &OPTION.
15.54.6.1 File Inputs

CASSINI requires three input files, namely:
5120257 / Apr 15 15-152

Section 15
♦ An existing SATURN Network data file with some additional parameters to

control the CASSINI process;
♦ A CASSINI Control ASCII file that defines the convergence strategy/strategies

to be implemented; and
♦ An ASCII report file on the Demand Model convergence (which defaults to a

DIADEM output file).
SATURN NETWORK FILE

As noted above, to operate CASSINI, a number of new parameters need to be
added to the existing &OPTION section (see 6.1) in the SATURN Network data
file as described below.
If TRUE, CASSINI will be called within SATNET and a number of

CASINI additional checks will be undertaken to ensure the files named below
exist. If any of these files do not exist, a semi-fatal error occurs.
Specifies the type of demand model used and the file format (and other
CASTXT operations) that CASSINI will expect. There are currently two options
either:
‘DIADEM’ file format and CASSINI will extract the convergence of the
demand model from a standard DIADEM report file a illustrated below –
this is the default option, or
A simpler ‘OTHER’ file format with the file consisting of two data fields in
CSV format. The first value is the demand model loop number whilst the
second value specifies the GAP-SD convergence of the demand model.
The “file name” of the CASSINI Control file defining the convergence
FILCAS strategy to be applied (see below for more information).
Default - blank (i.e., no file defined at this stage)
The “file name” of the ASCII CSV file reporting the convergence of the
FILGAP demand model
Default – blank (i.e., no file defined at this stage)
Note that the convergence parameters in the SATURN network file should be
relaxed as these will be applied for the assignment of the first demand model loop.
These will be subsequently overwritten by .XCP produced by CASSINI.
CASSINI CONTROL FILE

The convergence strategy is defined in the CASSINI Control file (as specified by
FILCAS parameter). The strategy is defined by setting a series of %GAP-SD
thresholds which, for a given %GAP-SD (or lower) in the demand model, the user
defines the parameters that CASSINI will export to the .XCP file. The parameters
are a sub-set of those normally contained in the &PARAM &END section of the
5120257 / Apr 15 15-153

Section 15
network data file, in particular those that relate to convergence options within
SATALL as shown in the table below. (N.B. the list may be extended if
necessary.)
The current list of parameters that may be changed by CASSINI is as follows (with
the new v11.2 parameters in italics):
♦ &OPTIONS: UPDATE, WSTART, DIADEM
♦ &PARAMS: SAVEIT, UFC109, FISTOP, STPGAP, XFSTOP, UNCRTS,

MASL, KONSTP, ISTOP, MET, NISTOP, NITA_M, NITA_C, NITA_S, NITS,
NITA, SPIDER, MULTIC, ILOVEU, NITS_M, SAVUFO, AK_MIN
The user may also provide more than one strategy with the strategy chosen
determined by the number of loops undertaken by the demand model. This
provides the user with the flexibility to switch between strategies depending on
whether the demand model is in an early stage (e.g., loops 1 to 5 for example),
middle stage (e.g., loops 6 to 10) or late stage (loops 11 onwards) and
approaching completion as illustrated below:
Early Middle Late
Demand Model Loop 1 to 5 6 to 10 11 to 15
KONSTP 1 1 1
STPGAP 10% 2.5% 0.05%
ISTOP 90% 95% 98%
MET 0 0 0
SAVEIT F T T
UNCRTS 10% 2.5% 0.05%
NISTOP 1 1 2
MASL 10 40 80
NITA_S 25 100 250
Each strategy is identified by a “[LoopThreshold Y]” where Y is the demand

model loop which that strategy is used. If more than one strategy is specified, the
Loop Thresholds must be provided in ascending order.
Within each strategy (or LoopThreshold), the following row(s) provide the
parameters to be transferred to the .XCP file depending on the GAP-SD value
reported in the Demand Model convergence file (FILGAP). Each row starts with
GAPValue Z% where Z% is the %GAP-SD threshold that identifies the
parameter(s) to be adopted for the next loop if the demand model convergence is
less than the value of Z. The parameters for each GAP-SD value must be
contained on the same row and each parameter separated by a comma.
5120257 / Apr 15 15-154

Section 15
In operation, CASSINI will:
♦ Read the demand model convergence file (as defined by FILGAP) and
determine the number of loops undertaken (so far) by the demand model and
resulting demand model convergence;
♦ Read the CASSINI Control file (as defined by FILCAS)
♦ Match the number of demand loops undertaken and the strategy to apply (as
defined by the Loop Threshold). So, for example, if there are two strategies:
an initial strategy for the first loop and a second defined for loop 5 onwards
[i,e., LoopThreshold 5], and four loops have been undertaken so far, the first
strategy will be applied;
♦ Within that strategy, compare the current demand model GAP-SD value
against the various %GAP-SD ranges [GAPVALUE] and export the
parameters to the XCP file.
An example of the control file is provided below.
EXAMPLE OF THE CONTROL FILE
5120257 / Apr 15 15-155

Section 15
EXAMPLE OF THE ‘DIADEM’ DEMAND MODEL FILE
DIADEM Results File
EXAMPLE OF THE ‘OTHER’ DEMAND MODEL FILE
5120257 / Apr 15 15-156

Section 15
EXAMPLE OF THE XCP FILE
XCP File
15.55 QUIET & QUICK Options via SATWIN

The QUIET and QUICK options in SATURN (see section 14.9 and 14.10) may
also be activated via SATWIN10 or SATWIN11. Once QUICK and/or QUIET is
toggled ‘ON’, the option remains active for subsequent SATURN commands
within SATWIN until they are toggled to ‘OFF’. The QUICK and/or QUIET settings
in SATWIN are also applied to DOS command line runs created by the SATWIN
(ie via the “TOOLS/SATURN DOS Command Shell” menu option). The SATWIN
settings can be overwritten if QUICK and/or QUIET is subsequently explicitly set
on the command line.
15.55.1 Using SATWIN10

In SATWIN 10 this is done by setting the QUIET and QUICK drop down to ON as
shown below.
5120257 / Apr 15 15-157

Section 15
15.55.2 Using SATWIN11

In SATWIN 11 this is done by pressing the QUIET and/or QUICK buttons located
on the bottom right-hand corner of the SATWIN11 interface as shown below.
15.56 Network Aggregation (SPIDER)

Network aggregation is a technique whereby links and/or nodes in the basic
assignment network may be combined together into an equivalent set of
aggregated links/nodes with the objective of reducing the cpu time required to
carry out the basic assignment steps of tree building and loading.
For example, as illustrated below, a one-way link from A to B followed (in series)
by a one-way link from B to C (so that node B has only one entry and one exit)
may be replaced by a one-way link from A to C with a cost equal to the sum of the
costs on A-B and B-C. Thus we have reduced two links to one link and removed
node B while at the same time retaining the same cost of travel between A and C
so that, if links A-B + B-C are part of a minimum cost path from a particular origin
in the original network, then so is A-C in the aggregated version of the network.
A-------B------C === A----------C
The cpu time required to build a minimum cost (shortest path) tree from a single
origin to all nodes in a network may be estimated by formulae such as, for the
d’Esopo algorithm most commonly used in SATURN:
T cpu = a 1 + (a 2 N nodes + a 3 N links ) (1 + a 4 Sqrt(N nodes ) )
See “Improved shortest path algorithms for transport networks” by Dirck Van Vliet,
Transportation Research Vol. 12, 7-20 (1978) and reproduced in Appendix T.
Other algorithms may have slightly different functional forms but all share the
same basic property of being increasing functions of the number of nodes and the
number of links in the network. Similarly the cpu time required to load a single
(origin) row of the trip matrix is proportional to the number of destinations times
the number of links.
Thus the total time required to carry out a single all-or-nothing assignment step,
the basic building block of the Frank-Wolfe algorithm, is an increasing function of
(a) the number of (origin) zones, (b) the number of nodes and (c) the number of
links. Any reductions in one or all of these should therefore lead to reduced cpu
times; network aggregation achieves this by reducing the number of nodes and/or
links.
5120257 / Apr 15 15-158

Section 15
In addition network aggregation reduces the cpu time involved in building trees
during post-assignment analysis such as skimming, select link analysis, etc, etc.
See Section 15.56.7.
A condensed version of the material that follows was presented at the ETC
(European Transport Conference) in Glasgow, 2010, by Wright et al and
reproduced in Appendix S (.pdf version only).
15.56.2 Aggregation Techniques
15.56.2.1 2-arm Links in Series

The simplest example of combining two links in series into one has been
illustrated above. Clearly the same technique may be applied in both directions
when both links A-B and B-C are two-way (assuming that U-turns are banned at
B); hence an aggregate link A-C replaces A-B and B-C while C-A replaces C-B
and B-A.
The same technique may clearly be extended to the case where there are a series
of more than one two-arm nodes between A and B such that a single link from the
start to the exit node replaces all the intermediate links and all the intermediate
nodes are removed. (This form of configuration occurs not infrequently in
SATURN networks when a number of artificial nodes are inserted between two
“main” nodes in order to give the link “shape” – although clearly a better method is
to define the shape via a .GIS file. In fact a common theme in network aggregation
is that the degree of potential aggregation and time savings that are available may
depend very sensitively on the coding techniques adopted.)
15.56.2.2 Aggregating Multiple-arm Nodes

It is also possible to eliminate nodes with more than 2 arms, for example a 3-arm
node N as illustrated below
May be aggregated into a “triangle”:
5120257 / Apr 15 15-159

Section 15
Such that the cost on the aggregate link A-C is the sum of the original costs on A-
N plus N-C. (Note that it is not necessary to create a “U-turn” link, say, from A to A
equivalent to A-N plus N-A since, even though the movement may be valid in the
original network, it can never be part of a shortest path tree.)
Note that in this case, if all the original links are 2-way, then the original network
segment contained 6 links as does the aggregated segment. So, if we have not
managed to reduce the number of links, we have at least removed one node
which, given the form of equation (15.x), should still lead to an overall reduction in
cpu time.
On the other hand if one of the original links were one-way - imagine that A-N
were one-way for example - then the original segment has 5 one-way links but the
aggregated segment has only 4 (A-C, A-B, B-C and C-B) and therefore the
numbers of both nodes and links has been reduced.
A common example of a 3-arm node might be an entry ramp onto a motorway
where A-N would be a one-way entry onto a motorway with one-way links B-N and
N-C. In this case 3 links are reduced to 2.
The entry ramp configuration may be generalised to any node that has a single
one-way exit and n one-way entries such that n+1 links are reduced to n. Equally
all nodes with a single entry and multiple exits may be aggregated to save one
node and one link.
Indeed a node with any number of entry/exits may always be removed by
aggregating pairs of entry/exits. The example of a 4-arm node is illustrated below.
5120257 / Apr 15 15-160

Section 15
which reduces to:
Note that here, if all arms are two-way, then we actually increase the number of
links from 8 to 12 in order to remove 1 node, although if one or more of the arms
are one-way the increase in links is reduced and may even represent a reduction.
(E.g., 2 one-way entry links and 2 one-way exit links reduce 4 links to 2.)
15.56.2.3 Application to “Spigot Zone Connectors”

A not uncommon coding “trick” used in SATURN is illustrated below where a zone
Z, rather than being connected onto a link A-B directly, is connected by an
external simulation “spigot” or “stub” node S which is in turn connected to an
“artificial” mid-link node M. (See also Sections 16.6.2 to 16.6.4 and 11.9.4.1)
However, in the assignment network representation of this section of the network

where “mini nodes” are created at the start and end points of all one-way links, the
situation would be as follows:
5120257 / Apr 15 15-161

Section 15
We therefore note that traffic leaving the network from zone Z has only two
possible paths available to it: Z-S1-M1-M3-B2 or Z-S2-M2-M4-A2. Equally there
are only two possible paths into Z from A1 or A2. Thus, in this situation we may
aggregate the network into 4 aggregate links – Z-B2, Z-A2, B1-Z and A1-Z – while
at the same time removing all the mini nodes at S and M. (Assuming all links are
two-way this removes 8 nodes out of13 and 8 links out of 14.)
Note that if the spigot node S has been coded as a buffer node under 33333 (see
Section 16.6.3) then a third mini-node is created at S has shown below. This
however does not change the general principle that zone Z is connected via
aggregate centroid connectors to nodes A and B but it does increase by 2 the
number of assignment links replaced.
5120257 / Apr 15 15-162

Section 15
We may further note (see also 16.6.4) that the above buffer node connector
allows possible U-turns via S 1 -S 3 -S 2 in the full network but that this possibility is
explicitly excluded in the aggregate network since, e.g., there is no aggregate link
created from A 1 to A 2 which would correspond to a U-turn.
15.56.2.4 Spigot Centroid Connectors in General

A more general variation on the spigot centroid connector configuration occurs
when the simulation node M is connected to more than 2 other internal simulation
nodes. In this situation a “mini aggregation” may be invoked by substituting direct
centroid connector links from M1 to Z and from Z to M2 in Figure 15.x with a
reduced number of zones and/or links removed. However, see step 2) in 15.56.3,
it is still an aggregation step worth doing.
15.56.2.5 Some Properties of Aggregate Networks

The final aggregate network will consist of a sub-set of the original nodes (since
none of the steps described above introduce new nodes) plus a set of new
aggregate links joining those nodes. Note that the number of zones remains
unchanged and therefore the proportion of zones within nodes – as well as the
proportion of centroid connector links within links – increases significantly.
In addition an aggregate network may contain a significant number of “duplicate
links”, i.e., links with the same A-node and B-node, the reason for which is
discussed below.
Both of these slightly unusual network properties may lead to variations in basic
tree build algorithms becoming effective; see below.
Note that the sub-set of nodes which are retained within the aggregate network
may be selected and therefore highlighted within P1X; see 11.6.3.5.
15.56.3 Implementation within SATNET

A (semi-empirical) methodology has been introduced into the network building
procedures within SATNET to produce an aggregated network, activated if a
&PARAM parameter SPIDER is set to .TRUE. (default .FALSE.). It proceeds via a
number of successive steps as follows:
5120257 / Apr 15 15-163

Section 15
1) Aggregate certain “priority” nodes, i.e., buffer nodes where there are
banned/penalised turns and weaving sections, where aggregation is
essential for the modelling (see 15.56.7.3);
2) Aggregate all “spigot” centroid connectors (15.56.2);
3) Aggregate stub link centroid connectors to external buffer zones (see
15.56.2)
4) Remove any bus-only links (since they will never form part of minimum
cost paths for trips in the trip matrix)
5) Aggregate all nodes which have a single exit with one or more entries
(N.B. this will include all “dummy” 2-arm nodes)
6) Ditto but with nodes with a single entry and / or more exits
7) Aggregate all nodes with, progressively, 3 arms, 4 arms, etc. etc. up to a
maximum of MAXSPA arms
Thus at the end of each step a new aggregated network is created and passed to
the following step for further aggregation. Steps 5) to 7) are repeated iteratively
with the maximum number of arms increased by one on each pass. Thus on the
first pass all 3-arm nodes are aggregated in step 7), on pass 2 all 3- and 4-arm
nodes are aggregated, etc. etc. The iterative loops are repeated until no further
aggregation is feasible or the maximum number of arms per node which may be
aggregated reaches MAXSPA as set in &PARAM (with a default value of 15).
A further rule is applied in step 7) which is that a node is only aggregated if, in
addition to having less than a certain number of arms, it also satisfies the (highly
empirical) rule that:
N new =< 23 + N in + N out + N 2w / 2
Where: N in = the number of in-bound directional links
N out = out-bound links
N 2w = number of two-way arms
N new = number of new direct links that will be created = N in * N out - N 2w
For example, aggregating a 6-arm node with 2 two-way arms, 2 one-way inbound
and two one-way outbound would create 14 new links from 8 existing links (i.e.,
we add 6 links and lose 1 node) but the above rule says to go ahead regardless.
In fact this rule allows nodes with up to roughly 20 arms to be removed even if this
seems totally counter-intuitive – empirically it saves CPU! And hencc the default
value of MAXSPA = 15 noted above.
Note that there is a large degree of overlap between some of the steps. Thus the
nodes which are aggregated under steps 5) and 6) would also be picked up under
step 7) but there may be a benefit to identifying the simplest structures and
aggregating them first before eliminating the more complex node structures.
Note as well that the number of links per node is not fixed but potentially grows
with each successive step. Thus node A may have initially have 4 arms but if one
5120257 / Apr 15 15-164

Section 15
of its neighbouring nodes B is aggregated then A will have additional links added
to all of B’s other neighbours.
At the end of the process the aggregated network structure is stored within the
.ufn/.ufs files so that it may be optionally used within subsequent assignments
and/or analyses.
15.56.4 Implementation within SATALL

Having created an aggregated network within SATNET the assignment procedure
within SATALL may then be based on the aggregated network. Thus the basic
Frank-Wolfe algorithm proceeds as normal with the one exception that step 3 (see
Section 7.1.2) - build minimum cost trees and load all O-D trips to the minimum
cost paths – uses the aggregated network. This is turn involves two extra steps:
1) Prior to tree building calculate the current cost of each aggregated link by
summing the costs of its constituent links, and
2) Post loading transfer the flows onto the aggregate links back onto their
constituent normal links to obtain Fa(n).
All other FW steps, e.g. the optimum combination of link flows and the calculations
of the objective function in step (4) are all based on the basic network definitions.
(Note that steps (1) and (2) above are repeated once per user class for MUC
assignment.)
While steps (1) and (2) are an extra overhead on the normal all-or-nothing loading
sequence which increases cpu these are compensated by the reductions in cpu
time for tree building and loading per origin and, provided that the number of origin
zones is large, the latter will always outweigh the former. Indeed, the larger the
number of zones, the more cpu time will be saved.
It should also be noted that the aggregate version of Frank-Wolfe may
occasionally give different results to the normal version. One reason arises when
there are two equal minimum cost routes between two nodes and the one
selected is essentially arbitrary. Equal cost routes occur most commonly on the
very first iteration where the costs are based on free flow speeds, distances etc.
which may well be identical on parallel routes; on later iterations, where flows are
essentially continuous variables, equal costs are much less likely. Another reason
may be the treatment of possible U-turns at simulation-buffer boundaries. In any
event, the final differences should be relatively small and it should be borne in
mind that both solutions are equally valid.
15.56.5 Alternative Tree Building Algorithms

Having established a different “form” of network on which to build trees it should
equally be feasible to create different tree building algorithms that take advantage
of the new network properties.
15.56.5.1 Duplicate Links

For example, aggregate networks tend to have a large number of duplicate links
(i.e., joining the same two nodes together) whereas these are not permitted in
“normal” networks. (The reason that they are not permitted in normal networks is
5120257 / Apr 15 15-165

Section 15
not because they are judged not to exist but due to the technical problems of
being able to uniquely identify links by their A-node and B-node; e.g., in a counts
file.)
The reason that duplicates can arise in aggregate networks is illustrated below
with a segment of a “grid network”.
If node D is aggregated a diagonal link from C to B will be created whose cost is

equal to the costs of CD plus DB. Similarly if A is aggregated another diagonal link
will be created from C to B with cost CA plus AB. For all origins (with costs fixed)
only one of the two alternative CB links may possibly appear in the minimum cost
tree, that version which has the lower cost. (Note that it is quite possible that
neither link appears in the minimum cost tree if B has an entirely different back-
node).
Thus if we eliminate the more expensive link between C and B prior to tree
building we will save time on tree building since only one version of link CB will
ever be considered as a candidate for inclusion in the minimum cost tree.
Unfortunately it is not possible to totally eliminate one of the duplicates once and
for all since the one to be eliminated depends on the current definitions of link
costs which change throughout the assignment process. However for a particular
iteration of Frank-Wolfe where the costs are fixed it is possible to eliminate the
more expensive alternative and therefore save cpu time for each origin zone’s tree
build.
This modification has therefore been introduced into the Frank-Wolfe algorithm
applied to aggregated networks and is found to reduce total cpu significantly.
(Duplicate links do not need to appear just as pairs: it is quite feasible for several
duplicate links to exist between the same two nodes so that eliminating all but one
reduces cpu time still further.)
15.56.5.2 Separate Centroid Connectors from Real Links

Tree building algorithms are based on repeating a number of very simple steps a
very large number of times; any reduction in the basic step sequence (no matter
how silly it appears!) may lead to not insignificant reductions in CPU time.
5120257 / Apr 15 15-166

Section 15
Thus in the aggregate tree building algorithm based on d’Esopo-Pape (see

Appendix T) we find empirically that splitting the algorithm into three distinct
stages saves a small amount of time. Specifically the stages are:
1) Construct the minimum cost paths from the origin zone to all connected
nodes. (Since we know that all the connected nodes must be added to
the loose end table we can do away with that test.)
2) Carry on tree building through all “real” links but ignore all out-bound
centroid connectors to destination zones.
3) For each destination zone consider all entry centroid connectors and
choose the minimum cost alternative (Once again we avoid any tests as
to whether a minimum cost link requires a loose-end table entry).
The reason that this 3-stage process appears to reduce CPU time for aggregate
networks but not necessarily for normal networks is probably associated with the
fact that aggregate networks contain a much higher proportion of zones and
centroid connectors than normal networks (see 15.56.2 above).
15.56.5.3 Eliminating Zero-flow Links

If we “know” in advance that certain links are never going to feature in minimum
cost O-D paths then they may be eliminated before the tree building takes place.
In particular if a link has zero flow then it can never be part of a used path for an
O-D cell with positive trips and it may be ruled out a priori.
For example, if we are re-constructing O-D paths post-assignment as part of a
Select Link Assignment (see 15.23 and/or 11.8.1) then we are only interested in
those paths which carry positive flows and clearly any link which we already know
has zero flow cannot be part of those paths. Thus before carrying out SLA we
remove all links with zero flow in total.
On the other hand if we are skimming, say, O-D distance or time then it is possible
for a link with zero flow to be part of a min-cost O-D path where the O-D itself has
zero flow.
Equally during the extra SAVEIT assignment where we have already carried out a
full assignment as part of the assignment-simulation loops we know which links
are unused and these can be eliminated within SAVEIT. (Although, strictly
speaking, it is possible that, due to poor convergence, a link could be used during
a SAVEIT assignment when it was never used during the “full” assignment.)
At the moment the “trick” of eliminating zero-flow links is used in the following
situations:
1. SAVEIT assignments: see 15.23.2;
2. SAVUFO calculations: see 22.5.3;
3. Select Link Analysis (SLA) with P1X: see 11.8.1.12.
4. SATCH cordoned matrices; see 15.56.7.2.
5120257 / Apr 15 15-167

Section 15
Eliminating zero-flow links can substantially reduce CPU time in all instances
since, empirically, it appears that over 50% of aggregate spider links may be
unused.
N.B. In principle it is possible to apply the same rules to “basic” networks but
since, in practice, there are very few if any “proper” links with zero flow then it is
not worth the added effort.
15.56.6 Results from Representative Networks
15.56.6.1 Pure Assignment (SATASS only)

We display below a table of results from a randomly selected set of real-life
networks in which we give:
♦ The number of zones and user classes (which are the same for both basic
and aggregated networks)
♦ The number of (assignment network) nodes and links in the base network
♦ The number of nodes and links in the aggregated network
♦ The number of newly created aggregate links which are duplicates (joining
the same A- and B-nodes)
♦ The total number of equivalent base links which the aggregate links map into
♦ The ratio of base/aggregate CPU time for a single Frank-Wolfe assignment

(i.e. no SATSIM)
5120257 / Apr 15 15-168

Section 15
Table 15.2 – Performance Comparison (SATASS CPU time only)
Aggregate
Original Network CPU
Network Zones UC Network Duplicates Equivalent
Ratio
Nodes Links Nodes Links
New
(5) 115 2 1,964 3,022 308 2,858 362 24,232 3.2
Town
York 176 1 1,246 2,329 340 3,026 413 16,379 2.2
(4)
Horley 229 2 4,263 6,440 621 6,313 1,063 5,89 3.3
Heysham 299 3 3,758 6,198 692 6,712 949 50,401 1.9

(2)
Dorset 527 6 3,204 20,116 1,616 18,114 4,693 175,665 9.2
Corby 598 8 13,374 21,229 2,310 27,364 4,187 200,797 13.5

(1)
Bristol 600 6 13,515 19,947 1,688 17,675 3,444 177,598 6.7
SALT 804 4 65,183 96,602 8,336 69,240 11,121 564,480 3.9
GMTU 993 1 42,665 63.596 5,264 60,363 14,422 567,896 11.0
East
1,348 7 30,633 52,277 4,926 53,363 17,028 387,600 8.6
London
M25 1,417 5 75,178 109,568 9,992 68,584 5,601 556,742 9.6
Central
1,638 7 28,587 60,325 6,064 61,922 22,645 335,510 6.0
London
South
(3) 2,520 5 57,877 93,905 8,833 96,296 23,593 753,240 2.9
London
LoHAM 5,624 5 119,534 185.576 21,348 151.776 13.513 962.301 3.75
The networks are arranged in order of increasing number of zones.

It is difficult to draw any universal conclusions from the above table; clearly the
improvement in CPU time is a function of certain network coding “idiosyncrasies”
(e.g., whether or not stub zone connectors are widely used). There is a tendency
for networks with smaller number of zones to be more efficient under aggregation
as we might expect since the more zones there are, the more opportunities there
are to reduce tree building times compared to the overheads involved in
constructing aggregate link costs.
15.56.6.2 Full Assignments (Assignment & Simulation)

Since SATURN incorporates both assignment and simulation sub-models and the
CPU time for the simulation is unaffected by network aggregation the overall
reductions for full runs are less spectacular than those demonstrated for pure
assignment sub-models above. Five of the above networks were selected (as
identified with suffixes 1 – 5) to compare the overall runtimes for the full SATURN
assignment using the four Frank-Wolfe-based assignment techniques currently
available:
5120257 / Apr 15 15-169

Section 15
♦ Standard Frank-Wolfe (FW);
♦ Multi-Core Frank-Wolfe;
♦ Frank-Wolfe with Network Aggregation technique; and
♦ Multi-Core Frank-Wolfe with Network Aggregation technique.

The assignments were undertaken on the same desktop PC with up to four cores
available to the software package. The three main elements of the SATURN
assignment are:
♦ Path-building and loading with fixed flow-delay relationships (assignment);
♦ Updating the flow-delay relationships representing vehicle interactions at

modelled junctions (simulation); and
♦ Re-estimation of the final paths and costs for skimming (SAVEIT – if

selected).
The first and third elements are multi-threaded whilst the simulation remains a
sequential process. Consequently, the reductions in CPU time arising from using
both network aggregation and multi-core processes do not directly translate into
the same proportional reduction in total CPU time.
Figure 15.15 presents the total CPU times for the FW algorithm combined with the
NA and/or Multi-core techniques using the five SATURN models. The total CPU
time is normalised with respect to the standard FW algorithm.
The results show that all three techniques - using either Multi-Core and/or
Network Aggregation - are at least twice as fast as the existing standard FW
algorithm for all five models and, in the best case found, virtually 20 times faster.
The reductions in CPU expenditure achieved by the Multi-Core algorithm or the
Network aggregation on its own are broadly comparable with CPU time reducing
by a factor of 2 to 2.5 for Model 5, increasing to factors between 4 and 5 for Model
1. In most cases, aggregating the network before assignment is more efficient
than distributing the original network across more than one CPU core – the
exception is the very large Model 3 network.
5120257 / Apr 15 15-170

Section 15
Figure 15.15 – CPU Time by Algorithm (Normalised to Standard FW)
0.50
Model 5 0.40
0.33
0.44
Model 4 0.44
0.31
0.28
Model 3 0.36
0.07
0.27
Model 2 0.15
0.06
0.26
Model 1 0.18
0.05
0.00 0.10 0.20 0.30 0.40 0.50 0.60
Multi-Core FW FW with NA Multi-Core FW with NA
As expected, creating a multi-core version of the network aggregation provides a

substantial “multiplicative” reduction in CPU time. In all cases, Multi-Core FW with
NA reduces the CPU expenditure by factors of between 3 (Model 5) and 20
(Model 1). The overall performance gain is principally determined by the
proportion of CPU expended on path building/loading relative to that spent in
junction simulation and the re-estimation of paths for the final assignment. The
overall reductions in CPU expenditure may be substantial – for example, for
Model 3, using Multi-Core FW with NA reduces the model run time (compared to
the standard FW technique) from 4.5 hours to less than 30 minutes with the same
level of convergence.
Further information on the practical benefits of Network Aggregation techniques
may be found in the Appendix S.
15.56.7 Other Applications of Aggregate Networks

Thus far we have concentrated on how aggregated networks may be used to
reduce the cpu time required to (a) build minimum cost trees and (b) load O-D
trips onto those paths. They may, however, be used effectively in several post-
assignment analyses as well as other modelling issues.
15.56.7.1 Tracing Paths in Aggregate Networks

If an analysis option of min-cost O-D paths wishes to trace a path which, in the
basic network, follows a link sequence A-B-C-...X-Y-Z then it requires 25 steps. If,
on the other hand, the network has been aggregated such that the equivalent
aggregated path is A-G-M-R-Z then only 4 steps are required: clearly potentially
much faster.
5120257 / Apr 15 15-171

Section 15
For example, O-D skims of, say, times along a forest may equally be calculated
on an aggregated network following the same basic procedures as for standard
networks but with one preliminary step: calculate the time (or whatever quantity is
to be skimmed) per aggregate link. CPU savings accrue from being able to
reconstruct the minimum cost paths per iteration using the much more compact
aggregate network such that similar time savings to those illustrated above for
assignment should also be achieved for skimming.
See Section 15.27.7.2 for information on aggregate skims within SATLOOK as
selected by a parameter USESPI.
Aggregated networks are also optionally used for Select Link Analysis within P1X
- see 11.8.1.12; also controlled by a parameter USESPI..
15.56.7.2 Tracing Paths in Hybrid Networks

For certain applications it is possible to trace paths through a “hybrid network”
which consist of a mixture of both aggregate and normal links. Hybrid networks
were first introduced in release 11.2.3 in February 2013.
For example, if in the above example of the basic path A-B-C-....X-Y-Z one were
doing a select link analysis of link K-L one could analyse a path that used the
aggregate links A-G, M-R and R-Z but, for the section G-M which contains the
individual link of interest K-L, one could revert to a basic network trace G-H-I-J-K-
L-M. Thus the “hybrid network” is formed of aggregate links where no “events of
interest” (e.g., a selected link) occur plus “normal” network links in the vicinity of
“events”. In so far as the majority of links in the hybrid network are aggregate the
number of steps required and hence CPU will be reduced.
The concept of a hybrid network was first used in trip matrix cordoning where the
“event” that distinguishes aggregate from normal links is the crossing of a cordon
link (either in-bound or out-bound). See 12.1.4, note 13). It is planned to extend
the principle to other areas of post-assignment analysis such as SATPIJA and
SLA.
We may also note that the concept of a hybrid network may be usefully combined
with that of eliminating zero-flow spider links prior to tree building and path tracing
as explained above in 15.56.5.3.
15.56.7.3 Banned and/or Penalised Turns at Buffer Nodes

Post release 11.1 it is possible to model banned and/or penalised turning
movements at buffer nodes provided that the node in question has been
aggregated (i.e., removed). These are defined within the 44444 data section using
the same formats etc. as for simulation nodes. See section 6.7.
For example, if a turn A-B-C in the buffer network is to be banned then, if and
when B is aggregated, the aggregate link from A to C (link A-B plus link B-C) is
not created. If the turn is penalised then the aggregate link A-C is created but any
time A-C is used during tree building then the necessary penalty is added to its
cost. The same principles apply if A-C is part of longer aggregate links.
5120257 / Apr 15 15-172

Section 15
15.56.7.4 Motorway Weaves in Aggregated Networks

The necessary flow calculations required to invoke the motorway weaving rules
(see 15.40.4.3) may be obtained far more efficiently using Network Aggregation if
all the nodes within the motorway weaving section have been aggregated.
15.56.7.5 High-Priority Nodes for Aggregation

In the cases of both banned turns and motorway weaves in order to insure that
the required nodes are in fact aggregated (since the final set of nodes to be
aggregated is effectively arbitrary) those nodes are assigned a high priority which
means that, in terms of steps 5) and 6) in the algorithm described in 15.56.3, they
are preferentially aggregated at an early stage of the process, independent of the
number of arms per node. Once all the “priority” nodes have been aggregated the
process proceeds as described in 15.56.3.
15.56.8 Further Research

Despite the impressive reductions in cpu time achieved with the current
techniques there are almost certainly further improvements possible. Thus the
rules that are used to determine when a node should be aggregated – and indeed
the order in which nodes are considered - are highly empirical and their efficiency
is highly dependent on unknown factors, e.g., how many new links will form
duplicates which may be subsequently removed. A more “intelligent” set of rules
would doubtlessly lead to further improvements in cpu times.
In effect network aggregation may be thought of as a form of “pre-tree” building; in
other words, before a minimum cost tree is built from a single origin, a number of
minimum cost “sections” are pre-constructed from existing links which then allow
the actual tree building to proceed with larger steps. Thus if the node-link
sequence A-B-C-D-E-F is repeated as a minimum cost segment for multiple
origins then replacing it by a single aggregate link A-F reduces CPU. On the other
hand if the aggregated link A-B-C-X-Y-Z never features as part of a minimum cost
path then its presence simply wastes CPU.
The “trick” therefore is to selectively aggregate “good” link sequences and to avoid
the “bad”; the current rather simple-minded procedure must almost certainly be
capable of improvement.
There may also well be more efficient methods for combining links together which
are dependent on a particular set of link costs - as opposed to the current network
aggregation procedure which aggregates links without regard to costs.
It may also be possible to eliminate a greater number of aggregated links prior to
tree building than just removing the more expensive duplicates. For example, one
may be able to apply a “triangle rule” which says that if nodes A, B and C form a
triangle and c(A,B) + c(B,C) < c(A,C) then link AC may be disregarded in terms of
tree building (for that particular set of costs, not necessarily universally).
An alternative, though less rigorous, approach would be to distinguish between
“probable” and “improbable” links where an improbable link (A,B) is very unlikely,
given its cost and the alternatives from A to B, to be part of any min cost trees but
an exact assessment might take longer than the time saved by eliminating that
link. Eliminating improbable links will speed up individual Frank-Wolfe iterations
5120257 / Apr 15 15-173

Section 15
but it would be necessary, near the end of the process, to re-introduce all links
just to confirm that none of the improbable links should be reclassified. (As long as
Frank-Wolfe finds lower cost auxiliary solutions on each iteration it should not
matter if it finds the absolute minimum cost auxiliary as long as no potential paths
are being ignored in perpetuity.)
The above thoughts on eliminating certain links are based on the empirical
observation that in most spider web networks less than 50% of all aggregate links
are assigned flows so that, had they been eliminated a priori, the ultimate solution
would be the same but achieved more quickly.
Several good topics for further research!
15.57 Residual (Incorrect) Path Flows and Restricted Frank-Wolfe

Algorithms
15.57.1 Residual Path Flows: Definition

A problem in identifying path flows under the Frank-Wolfe algorithm for solving
Wardrop Equilibrium (which does necessarily not apply to other algorithms such
as OBA) is that of “residual paths”. A residual path is one which has been
generated as a (current) best route on an early iteration of Frank-Wolfe but which,
by the end of the algorithm, is very much longer than the current best route but
has not been totally removed from the final averaged solution.
Thus, consider a situation where an O-D pair has two alternative routes available:
a “short” route that goes through a signalised intersection and a “long” route
without potential capacity restrictions. At equilibrium the signals are under
capacity and incur relatively minor delays and the all-or-nothing solution with all O-
D flow going through the “short” route and none on the “long” route is the correct
solution for this particular O-D pair.
However, it may have happened that on an early FW iteration (most likely the
second iteration following the initial all-or-nothing assignment to free-flow routes)
the signals had become heavily over capacity (due to the routes chosen by
alternative OD pairs which later divert elsewhere) and the minimum cost OD route
for our particular O-D pair went via the long route on that particular iteration. But
on all subsequent iterations the signals are never again as over-saturated and the
best O-D route is always via the signals. In this case the final path flow
contribution from the long route (as expressed by equation 7.2b) will never be
reduced to zero unless (unlikely) a particular value of lambda equals 1.0.
The creation of incorrect residual flows is an intrinsic property of the Frank-Wolfe
algorithm and is one of the reasons why its convergence rate slows drastically as
it approaches convergence.
Apart from slowing down convergence residual flows may also have several other
undesired consequences.
15.57.2 The Importance of Residual Flows

The practical impact that residual flows may have on different forms of path
analysis (see the list in 15.23.1) can be extremely variable. For example, in Select
Link Analysis, if a link has a total flow of 1000.0 pcus/hr of which 0.1 is based on
5120257 / Apr 15 15-174

Section 15
residual flows then the differences between including or excluding the residual
flows is arguably minimal.
On the other hand the impact of a small residual flow may be considerably
amplified in certain circumstances. Consider, for example (and this is based on an
example found in a real-life network), an O-D pair separated by a single link of
100 metres with signals at the downstream end such that, at equilibrium, the
correct solution is an all-or-nothing flow along that link even if the signals turn out
to be over capacity. (Since in that case more distant O-D pairs would have options
to divert further up/downstream to avoid the congested signals but the only option
for the “local” O-D pair might involve a relatively long and costly diversion.) Hence
a distance skim along the used path should give 100 m for that O-D pair.
If, however, on the very first all-or-nothing Frank-Wolfe free-flow assignment the
initial assumption is that the signals are operating under capacity then that first
assignment may “optimistically” severely over-assign multiple O-D trips along that
link, resulting in the downstream signals have a V/C ratio of, say, 2.0 and a
queuing delay (LTP = 60) of 30 minutes. Hence an alternative route of 30 km at an
average speed of 60 kph (assuming time-only assignment, PPK = 0) could be
lower cost and that path would be selected on the second FW iteration and
therefore become part of the final solution, even if its contribution may have been
diluted to, say, 1% by the end of the Frank-Wolfe iterations. Thus, in terms of
distance skims, that path would add 0.01 * 30,000 = 300 m to the average
distance so the skimmed distance would be 400 m, not 100.
In this case a small difference in flow has been magnified to produce a very much
larger difference in outputs.
15.57.3 Frank-Wolfe Assignment with Restricted Residual Flows

There appear to be (at least) two alternative methods to minimize the impact of
residual flows within Frank-Wolfe assignment:
(1) Apply Frank-Wolfe assignment as per normal but, in any post-assignment
analysis of individual O-D paths, identify any which appear to be “residual” and
remove them from the analysis, or
(2) Attempt to identify and eliminate any potentially likely residual flow paths
during the tree building stages within Frank-Wolfe so that any post-assignment
analyses may proceed as normal without worrying about possible residual
paths.
In effect the first tries to cure the disease once it has occurred, the second tries to
inoculate against it.
A semi-empirical method based on method (1) was initially introduced within
SATURN release 10.9 and is described in the following section, 15.57.4.
However, on further reflection, it seems that the method (2) is far more promising
but, at present, it has only been applied in preliminary stages. See 15.57.5.
The jury is still out!
5120257 / Apr 15 15-175

Section 15
15.57.4 Removing Residual Flows Post-Assignment

SATURN release 10.9.12 introduced two (highly experimental) applications which
attempt to remove residual flows if they have occurred within the assignment:
(1) Calculating multiple commodity (i.e., times, distances and tolls) O-D skims in
SATLOOK (SKIM_ALL, 15.27.7)
(2) Converting a .UFC O-D route format file into a .UFO format file in SATALL
(15.23.6 and 22.5.3)
Since any path flow along a non-minimum cost route is, strictly speaking, a
residual flow it becomes important to establish a rule to identify an “important”
residual flow which needs to be dealt with as opposed to the unimportant flows
that may be ignored. Within SATURN we use two criteria:
(i) The absolute difference AD in costs between the cost on a path c pij and its
minimum cost c ij * and
(ii) The relative difference RD = (c pij - c ij *) / c ij *
AD and RD are then compared to use-defined parameters (within &PARAM)
RESIDD and RESIDR such that if a path (or a portion of a path) satisfies the
condition that AD > RESIDD and RD > RESIDR then the path is considered to be
a residual flow path.
The default values of both RESIDR and RESIDD are both 0.0 signifying that
residual paths are to be ignored. Recommended values might otherwise be
RESIDR = 1.5 and RESIDD = 60.0 (in units of seconds).
N.B. These two options are only available on Beta-release and will almost
certainly be replaced by the use of methods to prevent residual paths
occurring in the first place.
15.57.5 Avoiding Residual Flows during Frank-Wolfe Assignment

An alternative approach to dealing with residual flows AFTER they have been
generated by an assignment is to prevent the assignment from generating them in
the first place.
The basic idea is, on very early iterations of Frank-Wolfe, to use an estimate of
what the final converged link costs are likely to be (e.g., from a “warm start”
network) to build a minimum cost tree per origin based on the final costs. Then,
when building the “proper” FW minimum cost trees links using the current FW
costs, exclude any links which, according to the final cost tree, are clearly
nowhere near minimum. The expectation is that the extra CPU involved in building
two trees instead of one will be justified by the early elimination of “bad” paths and
therefore not only reduce residual flows but accelerate convergence.
Improved Frank-Wolfe algorithms which incorporate the above ideas are currently
being developed and tested but are not yet available to users.
5120257 / Apr 15 15-176

Section 15
15.57.6 Avoiding Residual Flows: Choice of Assignment Algorithms

Whereas residual flows may be an intrinsic problem created by the Frank-Wolfe
algorithm the same problems do not occur with all traffic assignment algorithms.
Thus they are virtually non-existent under OBA and very much less common
under path-based algorithms (where social-pressure based algorithms, see
Appendix H, preferentially remove residual flows).
In addition the Partan variant of Frank-Wolfe (7.11.7) tends to reduce the
occurrence of residual flows due to its ability to include “backward steps” which
are able to entirely remove the contributions from early iterations. It is therefore
automatically invoked during a SUC SAVEIT assignment (15.23.4). N.B. To use
Partan during the MUC SAVEIT assignment you must set the parameter SPARTA
= T; it is not automatically invoked as with SUC. See 15.23.4.
Equally the use of incremental assignment (7.11.13) during the initial stages of an
assignment should, it is hoped, discourage the build-up of residual paths since, as
congestion builds up more slowly on early incremental assignments, the “correct”
O-D pairs should be able to choose alternative routes avoiding locally congested
links.
In particular the use of incremental assignment is (potentially) recommended to
reduce residual paths during SAVEIT assignments (15.23.2). Set the Namelist
parameter INKS_S = 4, say, in the network .dat file.
15.58 Error Listing (ERL) Files
15.58.1 Structure and Contents

Version 10.9.17 contains a new feature, Error Listing Files (.ERL), which provide a
list of the errors reported within SATNET ordered by node number(s) rather than
in the order in which they are detected (as they appear in the body of .LPN files)
or sorted by error number (as in the .LPN summary statistics).
Thus at the end of SATNET a text file with the extension .ERL is created which
contains one record per error detected with the following data fields:
(i) A-node
(ii) B-node
(iii) C-node
(iv) Error number
(v) A 0/1 identifier (Extra field 1)
(vi) A second numerical identifier (Extra field 2)
(vii) The (short) text message associated with the error number
5120257 / Apr 15 15-177

Section 15
A sample segment of a .ERL file follows:

14 10 0 137 0 2 Turn saturation flows per lane differ widely
14 10 27 97 1 0 Opposing X-turns at signals hook (interfere);
27 10 0 137 1 0 Turn saturation flows per lane differ widely
0 11 0 15 0 0 Maximum roundabout turn sat flow exceeds
13 12 0 162 0 1 Multiple turns sharing multiple lanes
The records are sorted firstly by B-node, secondly by A-node, thirdly by C-node
and finally by error number. If the error is associated purely with a node then the
A- and C-node entries are zero; equally if the error is on a link then the C-node is
zero while for an error associated with a turn all 3 fields are used. Errors which are
not associated with nodes, e.g., errors in parameter inputs, do not appear in the
.ERL list.
The error number uses the standard numbering system as listed in Appendix L,
e.g., all Warnings are in the range 1 -99, all Serious Warnings in the range 101-
199, etc. etc.
The first 0/1 extra identifier field is used, at the moment, to distinguish whether the
error is new (value = 1) or whether it has occurred in a previous .ERL file, in which
case it is set to zero. Thus an .ERL file for a previous run of SATNET may be
defined via a Namelist parameter FILERL input under &OPTION in the network
.dat file and the errors listed in the new .ERL file are compared to those in the old
.ERL in order to identify an exact match.
The second numerical identifier field is also used in association with a matching
entry in an input .ERL file but in this case the value is simply copied directly from
the value in the old .ERL file. The thought here is that if users wish to “mark”
certain error messages as being “OK”, e.g., by writing a 1 in the second field, then
the new .ERL file simply carries this information over. If no match is found the
second identifier defaults to 0.
Thus the intention is that users might input the .ERL file output by SATNET into,
say, Excel, and then add their own numerical marks therein before either re-
creating a new .ERL file for subsequent use by SATNET or inputting the new file
directly into P1X in order to highlight certain nodes (See 15.58.2). Hence the
procedure could be used as part of an “audit trail” where errors which have been
checked and approved might be assigned one numerical values and errors which
have not been checked could be assigned a different value.
It must be emphasised that at this stage in its development the concept of a
.ERL file is still highly fluid and we are very much open to suggestions from
users as to the basic format and contents of such files and equally the uses
to which they might be put.
15.58.2 Display of ERL Data in P1X

ERL data may be displayed in P1X by “highlighting” nodes (see 11.6.5.4) based
on the values in either the first or second extra identifier fields described above.
The options are entered via menu choices 1st or 2nd ERL Field within the Display
sub-menu.
These options differ from the “normal” highlighting procedures which highlight
nodes based on all errors detected within SATNET by basing it only on errors
5120257 / Apr 15 15-178

Section 15
which have been included within the .ERL file but with extra tests based on values
stored in the first and/or second “extra” data fields.
In both cases a “critical” value needs to be defined by the user but its application
differs between whether data from Field 1 or 2 is to be used. Thus with Field 1 the
test is based on equality; i.e., if you set a critical value of 1 only those error
records which have a 1 in Field 1 will be selected. Under 2 the test is “greater than
or equal”; i.e., all entries whose Field 2 value >= the critical value are selected.
In addition the second field differs in that the colour used to highlight the selected
nodes depend upon the value in the second field. Thus a low value might be
displayed with a light colour and progressively higher values with progressively
darker colours in order to indicate possible degree of urgency as set by the user.
The pens to be used for different numerical values are pre-defined within the
program but may be over-written using parameters NP_ERL(n) within the (most
recent) preferences file P1X0.DAT.
We repeat the information given above that, at the moment, Field 1 is set as either
0 or 1 within SATNET depending on whether an error is “old” or “new”, whereas
Field 2 is intended to be manipulated externally by the user via, say, Excel, prior
to its use in P1X.
15.59 Disaggregate Network Summary Statistics

Network statistics such as total PCU-hrs, total PCU-kms etc. are automatically
calculated over all links by SATALL (and SATSIM) with a split between, e.g.,
simulation links, buffer links, etc. as illustrated by the tables in Sections 17.8 and
17.9. In addition to total flows, flows are always disaggregated into the following
categories (if they exist): (1) bus flows, (2) pre-loaded flows, (3) PASSQ flows,
(4) all user class flows, and (5) flows exclusively from the trip matrix. Therefore the
standard output statistics always include the total PCU-kms by pre-loaded flows or
by user class 3, etc. etc.
However it is also possible to optionally obtain a further disaggregation of the
same statistics by sub-sets of links and/or by sub-sets of flows, either calculated
within SATALL/SATSIM or afterwards using SATLOOK.
Note that the sub-sets of flows are effectively fixed and used in each level of link
disaggregation. Thus the main choices to be made by the user are how to define
the disaggregation of links.
Traditionally links were disaggregated into sub-sets according to their capacity
indices but, post 11.2.8, it is possible to define a much wider range of criteria to
set link sub-sets. For example, links may be grouped into self-contained sectors or
“traffic boroughs” (see 5.1.7.1 and 5.1.7.2) and statistics such as total PCU-kms
by user class 3 produced per sector or borough.
Indeed these more general link criteria now take precedence over disaggregation
by capacity index since capacity indices are generally aimed primarily at setting
link speed-flow curves, from which a disaggregation of, say, PCU-kms may not be
particularly useful.
5120257 / Apr 15 15-179

Section 15
15.59.2 Disaggregation within SATALL

At the end of each run of SATALL (or SATSIM) a complete set of total network
statistics are calculated and stored within the output .UFS file. In addition,
optionally, a further set of disaggregate statistics is calculated and stored in .UFS
as controlled by user-set Namelist parameters in the network .dat files.
Thus if BYGRUP = T, statistics are calculated by link “groups” (see 5.1.7.3) where
the groups are defined either as (a) traffic boroughs if a parameter TFL = T or, if
TFL = F, (b) by a “N2G” file set as FILN2G. N2G files are specified further in
Section 15.60.?; basically they define an “index” for each node such that links are
grouped according to the node index of their B-node. (Which is effectively the way
in which links are grouped into traffic boroughs where the “name” of a link’s B-
node defines its borough number following TfL rules - see 5.1.7.2.)
Finally if BYGRUP = T, TFL = F, but no N2G filename has been set (FILN2G is
blank) then no disaggregate statistics are calculated within SATALL. When this
happens a warning message is generated.
If BYGRUP = F then the disaggregation is (potentially) set by the link capacity
indices but only if (a) a further namelist parameter BYCAPI = T and (b) capacity
indices exist in the network. Since, as explained above, capacity indices may not
be all that useful for disaggregate statistics BYCAPI defaults to F.
The disaggregate statistics calculated by SATALL and stored within the .UFS file
may be viewed only within SATLOOK – option 4, then 1 from the main menu; see
Section 11.11.4.
15.59.3 Disaggregation within SATLOOK

As mentioned above disaggregate network statistics as (optionally) calculated
within SATALL may only be accessed using SATLOOK (either the standalone
version or called from P1X). However, it is also possible to calculate similar
statistics “on the fly” within SATLOOK using not only those criteria available within
SATALL (e.g., disaggregation into traffic boroughs) but also by a much wider
range of possible disaggregation rules – main menu option 4 followed by option 2.
Thus the most basic level of link disaggregation is set by the parameters
BYGRUP, TFL and BYCAPI; if any of these three is “toggled” interactively then
the link sub-sets will be re-calculated and the disaggregate statistics will be re-
calculated and output. In addition the .N2G file which would have been initially set
as a network .dat file parameter may be re-defined interactively and the
disaggregate data re-calculated
In addition the link selection rules as set within SATDB may also be applied “on
top” of the normal link disaggregation rules – but only if SATLOOK is being
accessed via P1X.
A further P1X-only option allows the “indices” which define sub-sets of links to be
set via an existing integer data base column. Alternatively the link indices may be
input directly from a “.L2G” text file which gives the required index for each link;
see 15.60.4 for formatting rules.
5120257 / Apr 15 15-180

Section 15
15.60 Node and/or Zone Aggregation Files
15.60.1 General Principles and File Extensions

A set of filename conventions has been drawn up in order to identify ASCII text
files which define the “mapping” of one set of node/zone definitions into another.
Thus a file with extension .Z2G will contain data which specifies which Groups are
to be associated with each Zone, .Z2S maps Zones into Sectors, N2G maps
nodes into groups,G2S maps groups into sectors, etc. etc.
The following letters may be used: N for nodes, Z for zones, D for districts, B for
boroughs and S for sectors. In addition T represents “text” so that a .G2T file
would consist of a series of group names followed by a text description of that
group; e.g., “1 Otley”.
As a matter of good practice and common sense it is proposed – although this is
not a rigid requirement in SATURN – that all *2* (N2G, G2S, etc.) files should (a)
have the same “root” filename and (b) be stored in the same folder. In other
words, files such as mapping.z2g, mapping.z2s, mapping.g2s, etc. would all be
stored in the same folder and therefore have a common root pathname as well as
a common filename. The advantage of this is that the user need not define all the
possible mapping files since a SATURN program could logically infer a file/path
name when necessary.
In particular this facility is routinely used with text descriptor files of the form .G2T
whereby if the predicted file mapping.g2t can be found it is used to add text
names to groups; if not group text names are simply ignored.
15.60.2 FILZ2* – Zone Aggregation (.Z2G)

All files which map zones into more aggregate structures such as groups, sectors,
etc. have the same general, very simple format described as follows:
They consist of a series of text records (terminated by a 99999 record) where
each record consists of two integers in free format (i.e., including CSV) specifying
a zone followed by its group (where we use the terms “zone” and “group” to
denote the first and second quantities as in a Z2G file but the same specifications
apply equally to all such files)..
Note that numerical “names” must always be used for both the zone and the
group - not sequential numbers (although very often zone and/or group names
are in fact sequential).
Records need not be in numerical order of zones, i.e., the first number given is
always increasing, although this is generally the most convenient way to create
such files.
Duplication (i.e., assigning the same zone to two different groups) is not allowed
(although it may not always be checked).
A hyphen in front of a zone name (negative numbers) may be used to indicate a
“range” of zones. Thus two successive records:
9 1
-19 2
5120257 / Apr 15 15-181

Section 15
would indicate that all zone names in the range 10 through 19 would be assigned
to group 2 (and that zone 9 would be in group 1).
Note that 19 need not necessarily be a valid zone name itself, it simply represents
an upper limit, in which case the “true” upper limit would be the maximum zone
name lower than 19. The lower value of the range is the previous upper limit plus
one. If a negative number is used to indicate an interval the absolute value of the
negative number must be greater than the absolute of the previous number in the
list. If as above a positive number is used (e.g., 9) to set the previous line that
zone name must exist.
Therefore it is recommended that you use either all intervals (negative numbers)
or include all zone names in the Z2* file using the philosophy that the point of
using intervals is for the process not to fail and the point of using a zone by zone
list is that you want the process to warn you about missing elements by failing.
Errors occur and are noted if a record does not consist of two integers, if a zone
cannot be identified (excluding negative values above) and if some zones are not
assigned to groups. These may or may not result in the operation being rejected.
Blank records are allowed and ignored as our comments, i.e., records with a * in
column 1.
In order to process a Z2G file the zone names (and their number) must already be
known but the set of group names and their total number are only known and fully
specified after the Z2G file has been processed.
Note that the Z2G format also corresponds to a simplified version of the Records
2 used by the batch file MXM5; see Appendix W.3.
15.60.3 FILN2* - Node Aggregation (.N2G)

Files which map nodes into more aggregate groups follow the same specifications
as for zonal aggregation files as described in 15.60.2, two integer values in free
format – with the obvious caveat that the first integer value per record is a node
number, not a zone number.
The use of negative node numbers to indicate ranges is also allowed.
15.60.4 FILL2* - Link Aggregation (.L2G)

Links may be directly mapped into groups of links (as opposed to using their
B-node to define the mapping) via an “L2G” etc. file where the default file
extension .L2G signifies a file which gives the mappings of links into “groups”.
L2G files contain 3 free-format integer values per record, the first two being the
link A-node and B-node and the third being the group. The use of negative node
numbers to indicate “ranges” is not permitted with L2G files.
Currently L2G files are only processed within SATLOOK; i.e., it is not possible to
define an L2G file as a namelist parameter in a network .dat file and have the
appropriate aggregation statistics calculated within SATALL and stored on .UFS
files in the same way that node-based aggregate statistics may be set.
5120257 / Apr 15 15-182

Section 15
15.60.5 FIL*2T – Text Definitions

Files with extensions of the form Z2T, N2T, etc. etc. are used to supply alpha-
numerical titles to zones, nodes as indicated by the first letter in the extension.
They are not, however, generally available to users at present.
5120257 / Apr 15 15-183

Section 15

11.3.07 SATURN v11.3.07 Release DVV DAS EN IW 26/09/14
5120257 / Apr 15 15-184

Section 15
Simulation Network Coding Example
16. Simulation Network Coding Example

INTRODUCTION
Section 6 is complemented here by means of examples on how to code each of
the five types of intersections that can be handled by SATURN plus examples of
coding centroid connectors.
16.1 Traffic Signals

Figure 16.1 – A Schematic Traffic Signal
Assuming that node 44 sketched above represents a signalised intersection its

coding for SATURN input might be as follows:
44 4 3 4 61 85 0 45
45 0 0 0
16 2 25 200 0 1700 1 1 1600X 2 2
43 2 40 300 1400 1 1 3000 1 2 1200 2 2
55 2 25 220 1400 1 1 2800 1 2
19 4 6 43 55 43 45 43 16
10 7 4 43 55 16 45
25 0 4 16 55 55 0
15 5 4 16 55 55 45
FIRST RECORD (RECORD TYPE 1) - NODE DESCRIPTION

Cols. Nos. Input Remarks
4-5 44 Node number
10 4 Number of links (N.B. This includes the out-bound only link
to node 45)
15 3 Node type (traffic signal)
20 4 Number of signal stages
24 - 25 61 Relative offset of first stage
5120257 / Apr 15 16-1

Section 16
29 - 30 85 Cycle time at this junction

35 0 Default value of NUC is selected here
39 - 40 45 Minimum acceptable gap of 4.5 seconds
41 - 45 blank Default value of GAPM used here.
SECOND RECORD (RECORD TYPE 2) - DATA FOR THE LINK FROM NODE
45 TO 44
Col. Nos. Input Remarks
9 - 10 45 Node at the other end of the link
15 0 Number of entry lanes equal to zero here means a one-
way outbound road
20 0 *
25 0 *
* Link times and lengths are not relevant for one-way streets nor is it necessary to
code any information regarding turns which clearly do not exist.
THIRD RECORD (RECORD TYPE 2) - DATA FOR THE LINK FROM NODE 16
TO 44:
1–5 blank Stacking capacity for this link is to be estimated by default
as 2 x 200 / ALEX (2 = lanes, 200 = dist.
9 - 10 16 A-node for this link
15 2 Two approach lanes
19 - 20 25 Link free run time is 25 seconds
23 - 25 200 The link is 200 metres from middle of 16 to middle of 44
30 0 Left turn to node 43 is banned
31 blank No priority marker and
33 blank no lane specification needed for
35 blank missing turns.
36 - 40 1700 Sat. flow for straight-ahead movement
41 blank No priority marker required
43 1 This turn can only be made
45 1 from lane 1.
46 - 50 1600 Sat. flow for right turn to node 45
51 X Opposed right turn
53 2 This turn can only be made from
5120257 / Apr 15 16-2

Section 16
55 2 lane 2.
The fourth and fifth records contain similar data for each of the other two links to
node 44 in clockwise order, i.e. 43 and 55.
SIXTH RECORD (RECORD TYPE 3) - SIGNAL STAGE DESCRIPTION

14 - 15 19 This stage lasts 19 seconds followed by
20 4 an inter-green of 4 seconds duration.
25 6 Number of node entries to follow
29 - 30 43 The movement 43-44-55 is green.
34 - 35 55
39 - 40 43 As is the movement 43-44-45
44 - 45 45
49 - 50 43 And the movement 43-44-16
54 - 55 16
(N.B. The coding above could have been simplified by specifying 43 in cols. 29 &
30 and zero in column 35 as this would imply that all turns from 43 were green. In
this case NGM in column 25 would be 2.)
Records 7, 8 and 9 for this node contain similar data for the subsequent stages.
The effect of the stage definition records is briefly as follows. During the first stage
all three movements from node 43 are permitted, but after 19 seconds the
straight- ahead and right turns go red. After a further 4 seconds a right filter arrow
is displayed for turn 16-44-45, this display continuing for a further 10 seconds.
Note therefore that the left-hand turn 43-44-45 is continuously green for 33
seconds from the start of the cycle, i.e., it is green during the first inter-green
period of 4 seconds. Since there are no common movements between stages 2
and 3 all displays must be red for 7 seconds. The inter-green time of 0 in stage 3
implies that stages 3 and 4 run smoothly from one to another, the only difference
being that movement 55-44-16 becomes red during stage 4. Finally since there
are no common movements between stages 4 and 1 the 5 second inter-green
period after stage 4 is red for all movements.
16.2 Roundabouts
16.2.1 Roundabouts - Junction Type 2 (without U-turns)

Considering the same junction sketch and assuming that node 44 represents a
roundabout without U-turns we would code it as follows:
44 4 2 4 3600
45 0 0 200
16 2 25 300 0 1700 1 2 1700 1 2
43 2 40 220 3000 1 2 3000 1 2 3000 1 2
5120257 / Apr 15 16-3

Section 16
55 2 25 2800 1 2 2800 1 2
FIRST RECORD
5 44 Node number
10 4 Number of links
15 2 Node type
20 4 It takes 4 seconds to fully circle the roundabout.
22 - 25 3600 Maximum permitted flow at any point on the roundabout.
26 on blank Default values for LCY, NUC, GAPR and GAPM
to be used at this node.
The next four records (Record type 2) contain the link data for the four links as
described in 16.1. Since it is a roundabout records Type 3 are not required.
Notes:
1) All turn capacities from a single link should either be equal to the link exit
capacity or zero if they are banned turns. This is because the program
assumes that all turning movements have equal entry onto the roundabout
and hence that no one turn can have a greater capacity than any other.
2) Note that the roundabout capacity, 3600, is greater than any of the individual
entry arm capacities. This will have the effect of always allowing some flow
to enter from an arm even if the flow across the arm were at the nominal
capacity of its entry arm. For example if there were an assigned flow of
3000 pcu/hr from node 43 to node 16 (with no cross flow at its entry point so
that the actual flow would also be at capacity) entry from nodes 55 and 45
would not be entirely blocked. If however the maximum roundabout flow
had been defined as 3000 there would be no entry permitted from either
node.
3) The lane allocations are not in fact used yet by the program although it is
anticipated that eventually they will be.
4) None of the priority markers refer to roundabouts.
5) Note that no stacking capacities have been explicitly given in columns 1-5;
hence they will be calculated by default from the number of lanes, the link
distances and ALEX.
6) Had the node been coded as junction type 5, roundabout with U-turns, no
extra data would have been required on the link data records. The program
automatically generates U-turns to and from nodes 55 and 16 since these
are 2-way roads. No saturation or lane data for the U-turns should be
entered - if it is, it is ignored.
7) The coding above would almost certainly generate a Serious Warning 138
because the saturation flow from 2 lanes from 16 is 1,700 whereas for two
lanes from 43 it is 3,000; i.e., 850 per lane vrs 1500 per lane. While this is
5120257 / Apr 15 16-4

Section 16
not an impossible “on the ground” situation it is unlikely that two different
entry arms at the same roundabout would have such different saturation
flows per lane; i.e., they would be constructed with much more similar
engineering design.
16.2.2 Roundabouts - Junction Type 5 (With U-turns)

The coding for a roundabout junction with U-turns is exactly the same as for those
without U-turns except for replacing the junction type 2 with type 5. The U-turns
are not coded explicitly in the link records, and any saturation or lane data given
for them are ignored. The SATNET program itself deduces the appropriate turns
and saturation flow data from the other coded turns (see note 1 in 16.2.1 above).
16.3 Priority Junctions

Figure 16.2 - A Schematic Priority Junction
To code node 5 as a priority junction one would proceed as follows:

5 3 1 50 25
3 2 20 100 1600 1 1 2500 1 2
6 2 7 50 1200G 1 1 1000G 2 2
4 2 40 220 1800 1 2 1100X 2 2
FIRST RECORD
5 5 Node number
10 3 Number of links
15 1 Node type
16 - 20 blank N.B.This field not used at all by priority junctions
21 - 25 blank N.B.This field not used at all by priority junctions
26 - 30 50 Cycle time of 50 seconds
31 - 35 blank Use default value of NUC
36 - 40 25 Replace GAP by 2.5 seconds
5120257 / Apr 15 16-5

Section 16
SECOND RECORD
1-5 blank Stacking capacity calculated by default
10 3 Link from node 3 to node 5
15 2 Number of approach lanes
19 - 20 20 Free run time
23 - 25 100 Link length
27 - 30 1600 Saturation flow for turn 3-5-6
31 blank No priority marker; i.e., a major arm
33 1 This turn can only be made from
35 1 lane 1
37 - 40 2500 Saturation flow for turn 3-5-4 ...
41 blank which must also be from a major arm.
43 1 This turn can use either lane 1 (which it
45 2 shares with the other turn) or lane 2.
THIRD RECORD
1-5 blank Stacking capacity calculated by default
10 6 Link from node 6 to node 5
15 2 Two lanes
20 7 Free run time is 7 seconds
24 - 25 50 And the link length is 50 metres
31 G Turn 6-5-4 is a give-way turn from a minor link.
33 1 First lane used by turn
35 1 Last lane used by turn
41 G This is a give-way turn out of link 6-5
43 2 This turn can only ...
45 2 ... use lane 2
5120257 / Apr 15 16-6

Section 16
FOURTH RECORD
Similar to the above two; note that the X implies that the turn from node 4 toward
node 6 is an opposed right turn off a major road and therefore gives way to turns
3-5-6 and 3-5-4, but not to turns out of 6-5 which is a minor link.
16.4 External Nodes

Figure 16.3 - A Schematic External Junction
Assuming that node 58 above represents an external node connected via a (2-
way) road to an internal node 1 it might be coded as:
58 1 0
1 1 50 500
FIRST RECORD
Cols. Input Remarks
1-5 58 Name of the node
6 - 10 1 Connected to one other node
11 - 15 0 External node
16 ----- blank No other data required
SECOND RECORD
Cols. Input Remarks
6 - 10 1 Connection with node 1
11 - 15 1 Link 1-58 has 1 lane,
16 - 20 50 A travel time of 50 seconds, and
21 - 25 500 Is 500 metres long.
26 ---- blank No further data required.
In this case one would expect either that node 58 would be directly connected to a
zone via an external simulation centroid connector as illustrated in 16.6.2 or that it
would be part of the buffer network. But preferably not both! And certainly not just
to another simulation node as this is a fatal error; see 18.8.
5120257 / Apr 15 16-7

Section 16
16.5 Dummy Nodes

Figure 16.4 - A Schematic Dummy Junction
Assuming that node 5 is a dummy node inserted in the middle of the two-way road
between nodes 4 and 6 it could be coded as:
5 2 4
4 1 50 500 1500 1 1
6 1 40 500 1500 1 1
FIRST RECORD
Cols. Input Remarks
1-5 5 Name of the node
6 - 10 2 2 entry links
11 - 15 4 4 implies that 5 is a dummy
SECOND RECORD
Cols. Input Remarks
1-5 blank Stacking capacity to be calculated by default
6 - 10 4 The link from 4 to 5 has ...
11 - 15 1 ... a single lane ...
16 - 20 50 ... a travel time of 50 seconds and ...
21 – 25 500 ... a distance of 500 metres.
26 - 30 1500 The first turn, i.e. 4-5-6, exists with a (nominal) capacity of
1500 pcu/hr, and ...
33 1 ... uses lane 1 only
35 1
The third record is similar in content to the second.

Note that the capacities given for the turns - in this case just the straight ahead
movements - are purely nominal since the model assumes no delays at dummy
nodes, i.e., effectively an infinite capacity. However it is necessary to insert some
positive value in order to identify permitted movements; a banned turn,
presumably into a one-way street, would be identified by a capacity of 0.
5120257 / Apr 15 16-8

Section 16
16.6 Simulation Centroid Connectors

This section demonstrates the definition of simulation centroid connectors to
represent three different situations:
16.6.1 Zones connected to an internal link

Figure 16.5 - A Schematic Centroid Connector
The coded data under 22222 in this case would read:

5 3 5
and would imply that zone 5 is connected to link (3,5). In terms of traffic
movements the implication is that traffic TO zone 5 leaves from a point just
beyond node 3 and that traffic FROM zone 5 enters the link at a point just before
node 5, as indicated in both cases by the dashed lines. The effect is as though
traffic were parking on the link somewhere between nodes 3 and 5.
Note that in this case we have a zone numbered 5 (denoted by a triangle) and a
node numbered 5. Since these numbers appear in quite different positions in the
input the computer at any rate will always be able to distinguish them.
Nevertheless the user may become confused by exactly what 5 does represent,
so that the practice of having identical node and zone numbers is not necessarily
recommended. (Although there might well be situations where the zone is very
closely associated with one node so that it would be useful to give them the same
numbers.)
As indicated above link (3,5) is a one-way street from 3 to 5. The movements to
and from the zone would be the same if (3,5) were a two- way street - a separate
connector would need to be defined to allow for entry to the zone from node 5 and
exit to node 3. In this case the coded data would read:
5 3 5 5 3
However, were the link one-way in the opposite direction an error would result
since in that case there would be no such one-way link as (3,5).
5120257 / Apr 15 16-9

Section 16
16.6.2 Zones connected to an external simulation link (22222)

Figure 16.6 - A Schematic Centroid Connector
In the diagram above we shall assume that 7 has been coded as an external node
but that nodes 3, 6 and 5 are all internal, so that one might think of there being a
cordon cutting link (7,6) with the simulated network of interest lying to the right. In
this case the centroid connector may be defined under 22222 by either:
5 7 6
or
5 6 7
In either case it would be assumed that traffic from zone 5 enters the network at
node 7 and proceeds along link (7,6), while traffic to zone 5 exits from node 7 after
taking link (6,7).
Note that in this case we are assuming that (7,6) is in fact a two-way link. Were it
a one-way link in the direction 7-6 then only one centroid connector representing
traffic leaving zone 5 would be created, and similarly if it were one-way in the
opposite direction only the entry connector would be created. In such cases the
link could be coded as either (6,7) or (7,6) since, having identified node 7 as
external, the computer will make the appropriate checks as to whether the link is
one-way.
As above we use 5 to denote both a zone and a node, although in this case it
would appear to be more sensible to denote the zone by 7 since that is the cordon
point node at which it enters and/or leaves.
Note that this configuration corresponds to a “spigot” centroid connector as
described in section 5.1.8.1.
16.6.3 Zones connected to an External Simulation Link via a Buffer Node (33333)
The (spigot) configuration depicted in Fig 16.6, where zone 5 is connected to an
external simulation node 7, may also be achieved by including node 7 within both
the simulation and the buffer network definitions with the actual centroid connector
set within the 33333 data records, not the 22222 records. Thus node 7 would be
included as an external simulation node within the 11111 records (possibly
making use of AUTOX = T) while the 33333 data set would include a record such
as:
C 5 7 …. (times, distances etc. to follow)
5120257 / Apr 15 16-10

Section 16
No entry would be necessary under 22222. (Alternatively, and topologically

equivalent, the link 7-6 could also be included in the buffer network rather than the
simulation.)
In this case zone 5 would be connected directly to a buffer node 7 which, in turn,
would be connected via “dummy” links to the expanded sub-nodes (see Fig.
16.7(a) below) at both the upstream end of link 7-6 and the downstream end of 6-
7. (We assume here that node 7 does not figure anywhere else within the 33333
buffer network data and that its only function is to facilitate the centroid
connector.)
16.6.4 External Simulation Zones: Differences between 22222 and 3333

In terms of the expanded assignment network representation the general situation
when the external centroid connector is coded under 33333 is illustrated in Fig.
16.7(a). The expanded mini-nodes C1/C2/C3 represent the node C which is both
an external simulation node and a buffer node (node 7 in Fig. 16.6 above), Z
represents the zone (5 above) and A, the internal simulation node (5 above). Mini-
links C 1 -C 3 and C 3 – C 2 are the “dummy” links.
The equivalent expanded network where the centroid connector Z-C has been
included within the 22222 data is illustrated in Fig. 16.7 (b).
Figure 16.7(a) - Expanded assignment network representation of a combined
external simulation and buffer node coded under 33333
Figure 16.7(b) - Expanded assignment network representation of an external

simulation node coded under 22222
When viewed at the level of the “map network” (i.e, as plotted by P1X) both the
22222 and 33333 inputs would appear to be exactly the same (e.g., as in Fig.
16.6). In both cases traffic leaves the zone and enters the simulation network
proper along link 7-6 and conversely, exits the network and enters the zone along
6-7.
However there are subtle differences. Thus in Fig. 16.7(a), 33333 coding, it is
possible for traffic to make (in effect) a U-turn A1 to C1 to C3 to C2 to A2. By
5120257 / Apr 15 16-11

Section 16
contrast when the connector is defined within 22222, Fig. 16.7(b), node C3 does
not exist and direct links C1-Z and Z-C2 do not permit a U-turn at Z.
Since, generally speaking, U-turns are undesirable the 22222 representation of
Section 16.6.2 is to be (strongly) preferred to an entry under 33333.
It also worth noting that as the final link to the zone is in the buffer network, rather
than the simulation network, any queued traffic travelling to this particular zone
and held up in the simulation network will ‘re-appear’ on the buffer link (see
section 8 for more details on downstream flow metering that only occurs in the
simulation network).
There are also extra overheads created by having an extra buffer node within the
assignment network and (up to) 2 extra assignment links; for example it increases
the assignment CPU time necessary to build and load minimum cost O-D routes
by, typically, a few percent.
On the other hand it is easier using the 33333 records to ascribe specific
properties of time, distance and, e.g., tolls to a centroid connector whereas the
22222 representation implicitly assumes zero time and distance. Note that this
does not, however, apply to KNOBS data defined via an external file; see section
15.14.5.
16.6.5 Directionality of Spigot Centroid Connectors

A further difference between coding centroid connectors to “spigot” links (e.g. the
link 7-6 in 16.6.2 above; see 5.1.8.1) under 22222 or 33333 is that under 22222
the directionality (i.e., one-way or two-way) of the centroid connector is
determined by the directionality of the link 7-6, whereas under 33333 the centroid
connector may be either 1-way or 2-way as defined under 33333.
Note that an error (Serious Warning 167) will occur if the directionality of the
33333 centroid connector( s) differs from that of the spigot link; e.g., an out-bound
only centroid feeds a two-way spigot link. The error occurs whether the spigot link
is part of the simulation or the buffer network.
16.6.6 Zones representing Internal Parking Lots

It is often useful to recognise that ‘external’ nodes such as node 7 in 16.6.2 need
not be physically external, only ‘conceptually’ external. Thus zone 5 might in fact
represent an internal parking lot fed by link (7,6). If the link were one-way from 6
to 7 then this would represent a one-way entrance, and presumably there would
have to be another connection defined to represent the point of exit from the car
park.
Finally we notice that if all the links in 16.6.2 are two-way and 5 is indeed an
internal car park then the codings illustrated in 16.6.1 and 16.6.2 are roughly
equivalent since in both cases traffic entering zone 5 does so by leaving node 3 in
the direction of node 5 while traffic leaving zone 5 appears at node 5 in the
direction from 3. Indeed in some circumstances a car park off link (3,5) could be
adequately coded as in 16.6.1. Where the two representations differ is that 16.6.2
allows explicitly for delays to traffic at the entry/exit to the car park, node 6, and
defines the point of entry/exit much more precisely than 16.6.1. This extra
precision is very often useful if, for example, one has counts on the entry/exit
5120257 / Apr 15 16-12

Section 16
flows at the car park which one wishes to use to estimate the trip matrix using
SATME2. In 16.6.1 one cannot unambiguously associate these flows with a link,
in 16.6.2 one can.
This form of coding also allows one to assign a “time” to link 6-7 to represent, say,
a parking charge on entry, or even to assign a link capacity-restraint curve as
described in Sections 20.5.3 and 15.13 respectively.
Another example of a case where one might wish to use the more precise location
of zone connectors would be where link (3,5) was a relatively long link with
exit/entry mainly near one end. A further disadvantage to the internal style
connections is that the actual flow on (3,5) is underestimated by ignoring the
beginning and ends of trips. Again, if the link is a particularly long one, this may
lead to significant understating of travel times and distances. See Section 15.16.
(An alternative, and in some respects simpler, coding solution to the above
problem is to code two dummy nodes in the middle of a long link with a very short
‘dummy link’ in between to which the zone is connected.)
16.7 Motorway Links

The SATURN simulation routines were not originally designed with motorway-
style roads (i.e., divided highways with grade- separated entries and exits) in
mind, since such roads are not common features in networks to which traffic
management techniques are usually employed. However it is possible to include
them in SATURN simulation networks, although the level of accuracy is probably
not as good as with other types of roads and junctions.
The following points are suggestions as to how best to handle motorway links in
simulation (as opposed to buffer) SATURN networks:
1) While not absolutely essential it is much simpler to code divided motorways
as two distinct series of one-way links with one node at each entry and exit
point.
2) Each node on the motorway will therefore almost certainly have 3 one-way
arms - the motorway entering, the motorway leaving and the exit/entry arm.
The node should be coded as a priority junction with only 2 out of the 6
possible turning movements given positive saturation flows - i.e, the ‘turn’
from the entering to the exit motorway and the turn from the entry slip road
onto the motorway (or the converse for an exit). Entering traffic would
normally be coded as a merging movement (with no priority marker for the
on-motorway flow), while an exit junction would normally have no priority
markers on all turns.
3) Separate links need to be defined to represent the entry/exit arms with one
end at the 3-way motorway node and the other at a ‘normal’ intersection.
Again these should all be one-way links.
4) Since the cruising speed/travel time on all links is assumed to be fixed within
SATURN independent of flow these inputs should be selected to allow for
the expected assigned flow, not set at the maximum or free-flow speeds.
Thus if the user anticipates (or observes) speeds of, say, 50 km/h on a
motorway as opposed to say the speed limit of 100 km/h he should use the
5120257 / Apr 15 16-13

Section 16
former value. Alternatively one may use the option to define link speed-flow
curves (6.4.12) to represent the relationship between speed and flow on the
motorway link (as distinct from junction delays); indeed this facility was
created largely with motorways in mind.
5) Weaving sections between a motorway and a slip road (joint entry and exit)
may be modelled using a W turn priority marker; see 6.4.2.5.
5120257 / Apr 15 16-14

Section 16
5120257 / Apr 15 16-15

Section 16
Multiple Time Period Modelling in SATURN
17. Multiple Time Period Modelling in SATURN

INTRODUCTION
This section describes the manner in which over-capacity queues are “passed”
between time periods enabling SATURN to be used as a “quasi-dynamic” model.
Methods for modelling time-dependent matrices, e.g. models of peak spreading
are also included.
17.1 Treatment of Over-Capacity Junctions: General Principles

In order to describe how SATURN copes with the problems of flows in excess of
capacity at junctions it is perhaps useful to first outline the type of problems which
occur in conventional assignment models. Consider the very simple stretch of
road shown below with four junctions, A to D:
Let us further imagine that each junction has a capacity of 1,000 pcu/h and that
the trip matrix to be assigned consists of an hourly demand of 2,000 pcu/h from
left to right (i.e. from A to D) with no alternative routes and no other traffic. (We
might well question at this point what we actually MEAN by the trip matrix. We
shall assume that the hourly demand of 2,000 implies that 2,000 pcus arrive
uniformly at A during the hour to be modelled, even though clearly less than half
will actually complete their trip during the hour. Whether this picture of the demand
is realistic is not a question that is normally resolved during the assignment stage,
but one which needs to be more closely considered elsewhere in the overall
modelling procedures.)
What would clearly happen under these circumstances is that a queue would
develop at A such that the 2,000 pcus would require 2 hours to clear. The
average delay at A would be somewhat in excess of 30 minutes (since the first
pcu to arrive would suffer only a small delay and the last pcu to arrive would
queue for an hour with a linear increase in between), and a proper flow-delay
relationship should give this value. However there should be no comparable
queues building up at any of the 3 remaining junctions and they would operate at
capacity over the next two hours. Hence their average delays would be relatively
small, i.e., much less than 30 minutes.
Conventional assignment models would assign an hourly flow of 2,000 to all four
junctions and therefore, if they are to model the delay at A correctly, calculate
delays of 30 minutes at B, C and D as well. They, therefore, “double-count” the
queuing delays downstream of the “actual” queues.
In SATURN terms these problems do exist in the buffer network but – as we shall
see in the next sub-section – are dealt with by the simulation. (Although the
problems may be reduced in buffer networks via the UNIQUE option; see 15.48.)
5120257 / Apr 15 17-1

Section 17
Conventional / buffer network assignment models are therefore faced with two
problems:
♦ The realistic definition of delays at over-capacity junctions which allows for

long delays where queues do form but also avoids the problem of “double-
counting”.
♦ The spreading of queued traffic over a longer time period than that implied by
the input trip matrix.
17.2 Actual and Demand Flow in SATURN Simulation

Both problems are overcome within the simulation stage in that the simulated
traffic leaving each junction (i.e. the OUT flow for each turning movement) must
be within the capacity for that turn. Thus in the above example SATURN would
correctly predict an average arrival rate of 2,000 pcu/h and an average departure
rate of 1,000 pcu/h at A; all others have an arrival and departure rate of 1000
pcu/hr and therefore junctions B to D would operate exactly at capacity. It would
also correctly predict that a “permanent” queue 1 would build up at A at the rate of
1,000 pcu/h.
We therefore define “flow” in SATURN in two distinct ways:
1) As the “assigned” or “demand” flow. This is the flow given by the assignment
stage and corresponds to the total demand independent of when the flow
arrives, i.e., the 2,000 pcu/h at all junctions in the above example.
2) The “actual” or “simulated” flow which corresponds to the actual flow during
the time period simulated. Thus in the above example the actual flow
arriving at A would be 2000 pcu/hr whereas the actual flows (both arriving
and departing) on links AB, BC and CD would be 1000 pcu/hr.
For turns in the simulation network we may further sub-divide the actual flows into
the “actual arriving” flows and the “actual departing” flows. The difference
between these two corresponds to the rate at which the queue left at the end of
the time period for over-capacity turns builds up. Thus at A above the actual
arriving flow would be 2000 pcu/hr, the actual departure rate would be 1000
pcu/hr and the queue would build up at an “actual” rate of 1000 pcu/hr.
Note that the number of pcus in the queue depends not only on the rate of queue
build up but also on the length of the time period modelled. If, in the above
example, LTP = 30 there would be 500 pcus in the queue after 30 minutes; if LTP
= 15 it would be 250, etc etc. It is this queue which is “passed” to a subsequent
time period under the PASSQ option (see 17.3).
The difference between the assigned and actual arriving flows corresponds to
those pcus which wish to use a particular link or turn but are prevented from doing
so by queues upstream. They may therefore be thought of as a form of
1
N.B. We differentiate here between “permanent” queues at over-capacity junctions and
“transient” queues which build up and dissipate, for example during the red cycle at traffic signals.
5120257 / Apr 15 17-2

Section 17
“suppressed” demand. By definition these suppressed trips must constitute part

of the ‘queued at a junction’ flows at some point upstream.
Within the assignment stage the problems of traffic queued upstream and delay
double counting are overcome by using a ‘queue reduction factor’ (QRF)
calculated within the simulation. Thus if an assignment link has a QRF of 0.9 this
implies that only 90% of the total number of trips wishing to use that link will
actually arrive during the time period simulated and therefore the delays are
calculated corresponding to 90% of the assigned or demand flows.
17.2.1 Actual and Demand Flows by User Class

We note that the same distinction between actual and demand flows applies
equally to user-class specific flows as to total flows. Actual user class flows are
obtained by applying the same single link-specific factor as obtained for total flows
to user-class demand flows.
Note that this is only an approximation to the “correct” values which would be
obtained if the assigned O-D routes for each user class were reloaded but with the
route flows reduced every time an over-capacity simulation link was encountered.
However it should be a reasonably good approximation, particularly if the overall
differences between actual and demand flows are not great.
Equally actual user class link flows at individual simulation junctions may violate
Kirchoff’s Rule, i.e. total flow in does not equal total flow out, in particular if there
are multiple entries and exits in which case the estimation of the turning flows is
“under specified”. But if, for example, you have two entries and two exits and
therefore four “unknown” actual flows you also have four constraints on the total
in-bound and out-bound flows so the problem does not arise. However the
demand-based user-class flows must always satisfy Kirchoff’s Rule as will the
total demand flows.
The above considerations apply ONLY to simulation networks, NOT to buffer

networks for which the reservations expressed above concerning conventional
assignment models still apply. Thus in the buffer network demand and actual
flows are one and the same.
17.3 Linked Time Periods (The PASSQ Option)

A “quasi” dynamic element can be introduced into runs of SATURN by modelling
successive time periods with differing characteristics e.g., with changes in the
network or level of demand. This can be particularly useful when pronounced
peaks of demand exist, and one wants to study a period during which queues
form and dissipate.
For example, if we wished to study a total time period of two hours within which
the demands for O-D travel vary continuously as illustrated in Figure 17.1, then we
would divide the 2 hours into a discrete number of sub-periods (say 4 of 30
minutes), each with its own “rectangular” demand profile. Each sub-period is the
modelled individually as described below.
5120257 / Apr 15 17-3

Section 17
The ability to model a time period whose initial conditions (including the presence
of queues in the system) correspond to the final state of a previous time period, is
controlled by the logical parameter PASSQ in the &OPTION namelist input to
SATNET on the network data file. If PASSQ is TRUE the initial state is set
according to that recorded on the output file from the previous time period.
If two successive periods were to be modelled, the following procedure would
apply:
1) Run SATURN in the usual way for the first time period. For this run
PASSQ =.FALSE. in the initial network data file. (N.B. This is its default
value so that no mention need be made of PASSQ, as indicated in
Section 6.1.) Thus using the SATURN procedure one might command:
SATURN network1 tripod1
2) Set up a new network file (e.g. network2.DAT) in which PASSQ is set to

.TRUE. and run SATURN for the next time period using the revised
network and/or OD information. The final UFS file from run 1 is used in
this second run to (a) set up the queues, but also (b) to provide extra
information which is used to minimize the number of iterations (see note
(d) below).
1) This may be most conveniently done using the extended SATURN
procedure described in Section 14.4.1 with a command such as:
SATURN network2 tripod2 PASSQ network1.
2) or by
SATURN network2 tripod2
where the name of the “passq’ed” file is defined under &OPTION, see
6.1; e.g. UPFILE = ‘network1.ufs’.
The effect of the above procedure on the second time period is as
follows:
♦ The residual queues at the end of the first time period and the
“suppressed traffic” (as defined above in 17.2) are calculated from
the input UFS file.
♦ The suppressed trips are then added by SATNET as “fixed” link

and turn flows in the second time period equal to the differences
between demand and actual flows. This means that the routes to
be used by these trips are the same as those chosen in the
previous time period so that they may be thought of as “fixed” flows
in the same sense that bus routes constitute fixed flows.
♦ In addition the residual queues per turn (which are in pcus) are
converted into an “effective” fixed flow (in pcus/hr) equal to Q/LTP
which is added to the link “downstream entry flow” for the purposes
of the assignment (see 15.16.2).
5120257 / Apr 15 17-4

Section 17
♦ The residual queues from the previous time period are also taken
into account in the delay calculations for the current time period for
those specific turning movements.
♦ In addition (but only if UPDATE = F; see 15.3), the network build

program SATNET also takes the final set of flow-delay parameters
from the previous time period as initial estimates for this time
period, rather than starting “cold” with default values. This has the
advantage that the number of simulation-assignment loops in the
second time period may be considerably reduced with obvious
savings in terms of CPU times. N.B. If both PASSQ and UPDATE
are T then the flow-delay data is taken from the update file, not the
passq file.
♦ Information on the total number of “PASSQ’ed” trips and their

precise locations may be found in the .LPN files produced by
SATNET.
If further time periods are to be modelled, step 2) is repeated using the previous
output file as input; e.g.: setting
SATURN network3 tripod3 PASSQ network2
Thus if we look at the “permanent” queue of traffic on a single link over several
time periods it might resemble that sketched in Figure 17.1
Figure 17.1 - Growth and decay of over-capacity queues
Thus starting from zero queue at the start of time period 1 it grows linearly over
the first time period, continues to increase in the second, stays constant in the
third and disappears during the fourth.
FURTHER NOTES:
1) The networks defined in different time periods need not be identical.
Thus it is permissible to introduce, say, tidal flow schemes or new traffic
control settings. Suppressed flows on link A-B in one time period are
transferred to a link A-B in the next time period; if A-B does not exist then
no flow is transferred.
Thus problems may exist if, say, A-B is divided into two links A-C and C-
B in the second time period; the solution here is to ensure that node C
exists in all networks, even if sometimes it is only a dummy node
5120257 / Apr 15 17-5

Section 17
2) Equally the trip matrices may differ as well, although how this is done is
left to the user.
Given the difficulties of getting “good” trip matrices for even one time
period we would recommend that, unless peak spreading models are
being applied, trip matrices for successive time periods be set by simply
multiplying a “master” trip matrix by a uniform profile determined, for
example, by the average of observations at several sites. This may be
done using the FACTOR option in MX or, much more conveniently, the
parameter GONZO may be used to factor the matrix to be assigned; the
end effects are identical. See 17.4.3)
3) The above procedure does not apply at all to the buffer network which of
course is treated in the conventional manner without queues and without
fixed flows.
4) The value (s) of LTP refers to the individual time periods, not the total
time period modelled. Thus to model a 2-hour period subdivided into four
half-hour sub-periods the value of LTP should be 30, not 120. (This is not
to say that each sub-period should be of the same duration; different
values of LPT may be set in different time periods.)
17.3.2 Choice of Time Periods

Defining the time period(s) to be modelled involves choices of:
♦ the total time period to be modelled;
♦ its subdivision into distinct time periods or “slices”.

The first choice is generally straight-forward. Although in theory one could set up
linked SATURN models to run over the full 24 hours most studies consider
separate time periods such as the morning peak, inter-peak and evening peak.
The second question is how to divide, say, a 2-hour morning peak period into a
number of time slices. The most critical issue here is how rapidly travel conditions
change within the full period. If flows are reasonably constant then there is a
strong case for ignoring time slices and modelling a single time period; very often
inter-peak models do this.
On the other hand if the flows exhibit a strong “peak within a peak” then, in order
to correctly model the duration and the length of the resulting queues, sub time
periods are called for. The sharper the peaking, the smaller the time period that
will be called for.
There is however a competing requirement that the time slices should not be very
much shorter than the duration of trips within the simulation network, otherwise
the basic SATURN simulation assumption that trips are essentially loaded
simultaneously throughout the network tends to fall apart. In practical terms this
means that if, say, it takes 30 minutes for trips to travel from one side of the
network to the other then 30 minute time slices should be fine. 15 minutes is
probably still OK but 5 minutes would be cutting it a bit fine. On the other hand if
the network were only 5 minutes “wide” then 2 minute time slices might be
5120257 / Apr 15 17-6

Section 17
acceptable in some respects, although defining demand levels to that level of

detail might be questionable.
There is also no requirement that each time slice must be of equal duration. A 2-
hour period might be divided into 30 minutes, 4 15 minutes and a final 30 minutes
if most of the flow variability were concentrated in the central hour.
So, final recommendation for those who can’t make up their own minds: not less
than 15 minutes, no more than 1 hour. And please remember point (4) in 17.3.2
as regards how to define LTP.
17.4 Running Multiple Time Periods Using PASSQ: Simple Procedures

This section describes a number of methods for running multiple time periods
using PASSQ which are simpler than the somewhat long-winded “one step at a
time” approach described in 17.3.1 (although the end effect is the same). They
appear in historical order of development as well as ease of use. Thus the
SATTPX method described in 17.4.3 in conjunction with SATSUMA (17.5) is the
recommended technique; the first two sections only need to be consulted if you
need to take a more do-it-yourself approach.
In fact .PS files and the SATTP procedure are now longer included in the most
recent releases of SATURN; only SATTPX is available. However, if, for some
reason, users can see an application for either they could be resurrected and
therefore the documentation is still included in the next two sections
17.4.1 The Use of “PS” Files

The procedures for running linked time periods may be somewhat simplified by
making use of special input control files to SATNET known as “.PS” files.
Basically the .PS file is read after a full network .dat file and, using a namelist
input convention, can “overwrite” the following two network parameters:
PASSQ and GONZO
This allows you to use the same .dat file for, say, time periods 1 and 2 but for time
period 2, where the parameter PASSQ must be set to TRUE, this may be altered
with a PS file:
&PARAM
PASSQ = T
GONZO = 1.2
&END
as opposed to copying and editing the original .dat file to include an entry ‘PASSQ
= T’.
Thus the command:
SATNET network PS tp2
reads the basic network data from file ‘network. DAT’ but overwrites the values for
PASSQ and/or GONZO from a file ‘tp2.PS’ as illustrated above.
5120257 / Apr 15 17-7

Section 17
The reason for allowing a .ps file to over-write GONZO is to allow you to use the
same basic trip matrix for all time periods but to introduce time period-specific
factors set by GONZO.
17.4.2 The SATTP Procedure

A special .bat produced under DOS, SATTP.BAT, provides a simple method of
running multiple time periods making use of .PS files. Thus the command:
SATTP network trips post 4
assumes a basic network file ‘network.DAT’ and a basic trip matrix file ‘trips.UFM’
which are to be assigned over 4 time periods (set by the final parameter), where
*
files in the different periods are denoted by suffixes A, B, C and D respectively.
Thus a set of files networkA.UFS etc. are produced in time period 1, networkB.ufs,
in the time period 2, etc., etc.
The user is required to produce 4 separate ‘.PS’ files, postA.PS ... postD.PS
where all 4 files may (if they wish) define values for GONZO, ie. trip matrix factors
for each time period, and files postB.PS ... postD.PS MUST set PASSQ=T.
The .BAT file works by copying network.dat into time-period specific data files
networkA.DAT, ..., etc., and running the full SATURN procedure for all 4 time
periods with the PASSQ option invoked in time periods 2 to 4. The file structure is
illustrated in Figure 17.2.
Figure 17.2 - File Structure for Multiple Time Period Assignments
17.4.3 The SATTPX Procedure: Defining Trip Matrices

The principle of running multiple time periods has been further extended within the
batch procedure SATTPX - the strongly recommended technique - which runs
*
N.B. Under DOS this requires that the "name" of the base network file must be 7 characters or less
in order that the suffixes A, B, C etc may be added and still be 8 characters or less.
5120257 / Apr 15 17-8

Section 17
multiple time periods automatically and offers three different methods for defining
time-dependent trip matrices.
The first uses a fixed “base” trip matrix with global time-dependent GONZO factors
set by the additional namelist facility described in Appendix B whereby parameters
appropriate to different time periods may all be contained in a single .dat file by
the use of subscripts. Thus if a network.dat file contains &PARAM definition
records:
TIJFIL = ‘TRIPS.UFM’
GONZO(1) = 0.8
GONZO(2) = 1.2
GONZO(3) = 0.9
this defines GONZO values of 0.8, 1.2 and 0.9 for time periods 1, 2 and 3 as
factors applied to base matrix trips .ufm. (N.B. Recall that all trip matrices are
defined as rates in pcus/hr, not as absolute trips, so that the GONZO values
should be of the order of 1.0, not, say, of the order of 0.25 if a time period is being
divided into 4 sub-periods.)
Secondly individual time-period specific trip matrices may be defined in the .dat
files under &PARAM using subscripts; e.g.:
TIJFIL(1) = ‘TRIPS1.DAT’
Specific file names are required whenever they are not multiples of a common trip
matrix as occurs, for example, with peak spreading models (17.12).
Finally a single (i.e., not subscripted) trip matrix may be defined in the .dat file but
it must be a “blocked” matrix; i.e. one in which individual trip matrices per time
period (as in method 2 above) have been combined together into a single .ufm file
following the principles described in 10.2.5. Thus the .dat file might include:
TIJFIL = 'TRIPS123.DAT'
where trips123.dat is a “blocked” matrix from trips1.dat etc.

Note that methods 2 and 3 would not normally include GONZO factors since any
factoring would already have been included in creating the .ufm files.
To run this network for the three time periods for which data is provided use the
command:
SATTPX network 3
where 3 indicates the number of time periods to be run.

In this case there is no need to prepare explicit .ps files for each time period - a
standard .ps file which merely serves to turn on PASSQ is provided. The time-
period specific data is all contained in the single network.dat file.
Note as well that the parameter PASSQ should be set to .FALSE. in the file
network.dat; it of course needs to be .FALSE. for the first time period and
thereafter the batch procedure SATTPX ensures that it is re-set to .TRUE. for the
later time periods.
5120257 / Apr 15 17-9

Section 17
SATTPX is therefore a far more flexible method than that described in 17.4.2 so
that SATTPX effectively supersedes SATTP and the use of time-period subscripts
in data files also supersedes the need for users to set up specific .ps files. (.ps
files are still used - they are merely invisible to the user.) The file structure under
SATTPX is identical to that under SATTP as illustrated in Figure 17.3.
Note that, with later releases of the bat file (10.4 onwards?), SATTPX also
explicitly runs SATSUMA (see 17.5 next) at the end of multiple time period runs in
order to save the user having to call another bat file.
17.4.4 Multiple Time Period Network .Dat files: The use of Subscripts
The use of subscripts has been mentioned above in connection with the definition
of different trip matrices per time period and different LTP values; the procedure is
in fact general and may be applied to almost all parameter values set under
&PARAM in a network .dat file. See Appendix B.
17.5 The SATSUMA Program

Having simulated each individual time slice the final necessary step is to combine
together all the data in files networkA.ufs, networkB.ufs, etc into a single file. This
is the function of a special program SATSUMA as illustrated in Figure 17.3.
To invoke SATSUMA after a run of SATTPX type:
SATSUMA network 3
(where the parameter 3 defines the same number of time periods as under
SATTPX) to create a single output file:
network.uft
which has the same basic function as a .ufs file but which contains not only data
from each time period but also suitably aggregated data over all time periods. For
example a .uft file contains not only the flows in each individual time period but
also the average flow over all time periods. .Uft files may be input into P1X,
SATDB etc and both aggregate and/or disaggregate data displayed.
Note, however, that the .bat file SATTPX explicitly calls SATSUMA as its final
step (see 17.4 above) so that generally there is no need for a separate additional
call to SATSUMA – although there is no harm in doing so.
In addition to aggregating link/turn data SATSUMA also aggregates summary
statistics so that one may use a .uft file to display total vehicle hours, total vehicle
kms, etc over the full time period. The advantage of using SATSUMA as opposed
to a “DIY” approach is that it avoids problems of “double counting” since flows
which are passed as queues from, say, time period 1 to time period 2 tend to
appear in statistics for both time periods.
Depending on the type of data involved SATSUMA will either:
♦ Average, as with flows or times (with appropriate weighting factors).
♦ Add, as with fuel consumption which is stored in absolute terms, not as rates.
♦ Take data from the final time period, as in queue at the end of the time period.
5120257 / Apr 15 17-10

Section 17
In addition time - independent data such as link lengths are only stored once in
order to save space.
However, partly in order to save space, .uft files do not store full simulation data
such as cyclical flow profiles from each time period so it is not possible for
example, to edit and re-simulate individual nodes. Neither is the SAVEIT option
valid within .uft files so it is not possible to recreate routes from individual time
periods. For detailed analysis of these sorts the individual files networka.ufs etc
must be accessed.
Within standard bat files “T” and “UFT” may be used in virtually the same way that
“S” and “A” or “UFS” and “UFA” are used. See 14.2.2. For example you may use:
SATLOOK network UFT
Or
SATDB net1 UFT T 2 net2
17.6 The Definition and Calculation of Queues and Delays

The distinction between the delays associated with transient and over-capacity
queues and delays (see also 8.4.1 and 8.4.8) within this time period and in later
periods is illustrated in figure 17.3. This plots the number of pcus queued at an
over-capacity junction over the first and following time periods, from which the
delays are directly calculated.
Figure 17.3 - Queuing Components over Successive Time Periods
Thus in the first time period (0<t<LTP) Q t represents an average transient queue
(see 8.4.8) while the permanent or over-capacity queue grows from O to Q 1 (so
that the average over-capacity queue would be Q 1 /2). Note that the growth of this
queue may be limited by blocking back, in which case the queue effectively
continues to grow on the preceding link(s) and, possibly, on inbound centroid
5120257 / Apr 15 17-11

Section 17
connectors. However in this case those delays are associated with the preceding
link(s), not the link at the “head” of the queue.
During the second time period, as illustrated here, the newly arriving flow is less
than capacity so that the permanent queue declines (line AC) but has not gone to
zero by the end of the second period. If however we just consider the Q 1 pcus
present at the start of the second period they decrease linearly (line AB) at a rate
equal to the capacity such that at time t x they have all passed through.
The delays experienced by the traffic arriving on this link in time period 1 may
therefore be subdivided into four components.
1) Transient delays in time period 1, with total pcu-hrs given by the area (1),
the product of Q t and LTP.
2) Permanent queuing delay in time period 1 represented by the triangular area
(2) equal to Q 1 x LTP / 2.
3) The time spent by the Q 1 pcus in the permanent queue in the next time
period, triangle (3), plus....
4) ....the time spent in the transient queue in the next time period, rectangle
(4)**
The situation becomes more complicated in the second time period where not
only do we have queued traffic from the first time period but also newly arrived
traffic from the second period. Their delays are represented by areas (5) and (6)
with the possibility of extra delays in even later time periods. And to further
complicate matters the newly arrived traffic may be partly made up of traffic from
time period 1 which was caught up in queues upstream and arrivals later on in the
time period. Thus a portion of the over capacity queue (5) and the transient
queue (6) in the later time period(s) may be associated with queued-up traffic from
time period 1. Section 17.6.2 elaborates further on this topic.
Queue lengths are converted into delays by dividing by an appropriate flow -
generally the capacity for over-capacity movements or the arrival/departure flow
otherwise.
However in defining delays we may need to differentiate between the delays
experienced by traffic originating and/or arriving within that time period (part of
which may take place in later time periods) and delays purely within a single time
period (to include previously queued traffic).
Different functions may require subtly different definitions. Thus for assignment
purposes - where we are concerned with establishing routes for the new traffic on
the network - the relevant definition of delay per turn would need to consider:
Delays to newly arriving traffic (as opposed to traffic in queues at the end of the
previous time period).
**
For ease of illustration we have shown the transient queues in time periods 1 and 2 to be
equal; they need not be.
5120257 / Apr 15 17-12

Section 17
Delays incurred in later time periods by the newly arrived traffic (if there are
queues at the end of this time period).
For the purposes of assignment the most relevant delay is that experienced by the
traffic generated within that time period since that determines their route choice.
However for simulation purposes a more relevant definition of delay would include
both the new traffic and the previously queued traffic. For further discussion on
this point please see sections 17.8 and 17.10.
Note however that these problems only occur with over-capacity queued turning
movements and not with transient queues.
17.6.2 Downstream Queues Encountered by Queued Traffic: The AFTERS

Parameter
As explained above over-capacity traffic queued at one junction in, say, time
period n complete their journey in time period n+1. Part of their residual route
may go through downstream links which were also over capacity and the question
arises as to how long the downstream queues will be at the time the upstream
queued traffic arrives. With reference to Figure 17.4 the question is what is likely
to happen to the end of the queue in the next time period, i.e. the line AC. Thus if
arrivals equal capacity then the queues experienced by the upstream flows will
equal Q 1 (AC remains horizontal), if arrivals exceed capacity then the queues will
be greater then Q 1 and if arrivals are less than capacity the queue will be less.
The latter situation is likely to arise if the period in question is a peak period
followed by lower flows post-peak.
Historically (i.e. pre 9.4) SATURN took a neutral but generally optimistic view that
future queues would equal the average queues in the current time period. In the
case of the first time period as shown in Figure 17.4 that would imply a queue
equal to half of Q 1 . 9.4 introduced a new parameter AFTERS such that the
expected queue in time period n+1 is given by:
Q n+1 = AFTERS • Qe n
where Qe n is the queue at the end of time period n.
AFTERS may be set under &PARAM in the network .dat file or later and, for
historical continuity, defaults to 0.5.
However a more realistic value for AFTERS should be 1.0 which assumes that the
queue remains at its final value into the foreseeable future, which is probably a
more truly “neutral” assumption than 0.5. It is also the theoretically correct value
for situations where the upstream queue is directly blocked back by the
downstream queue and therefore the queue is “continuous”.
Values of AFTERS greater than 1.0 might be appropriate for situations where the
queues are relatively long distances apart and the demands in the next time
period are liable to increase; e.g. modelling a pre-peak period in a large network.
17.7 Junction-based Summary Statistics

Details of both the queued traffic and the suppressed traffic at individual junctions
are included in the standard simulation node “flow and delay” summary tables, a
5120257 / Apr 15 17-13

Section 17
“typical” example being given on the next page. The following points may help in
an interpretation of this output:
1) ‘AVERAGE DELAY’ is the average delay in seconds to pcus during the time
period (LTP) modelled. In the case of turns with permanent queues at the
beginning and/or the end of the time period the delay varies within the time
period but the average time spent in the queue is included within AVERAGE
DELAY. It includes both newly arriving traffic plus queued traffic; thus areas
(3), (4), (5) and (6) for time period (2) in Figure 17.4. (It does not, however,
include any possible delays arising from capacity-restraint curves on the link
(8.4.4); it may help to think of it as “stop-line delay”.)
2) The ‘ASGND FLOW’ is the assigned or demand flow as given by the
assignment while the ‘QUED UP’ flow is the suppressed flow due to queues
upstream from the current node. The difference of these two gives the
‘ARRIVE FLOW’ which reaches the node. ‘QUED HERE’ gives the rate at
which a permanent queue develops, so that subtracting this from the previous
column gives the ‘ACTUAL FLOW’ leaving the node. Note that these are all
given in pcu/h; i.e. they are rates, not absolute figures.
3) For turns, links and/or nodes with permanently queued pcus present at the
end of the time period the “tail back” at the beginning and end of the time
period is given in brackets on the line following that in which the ‘queuing rate’
is given. Thus in the above example a permanent queue builds up for turn
48-22-23 such that at the end of the time period (here 30 minutes) a tail back
of 47.0 pcus would have formed, with no permanent queue present at the
start of the time period.
4) The delays totalled for each link and for all turns at the node are “weighted”
averages where the weight for each turn is the arriving flow. The “total
capacity” given for each link is the sum of the individual turn capacities on
links where there is no lane sharing, but is less than their sum when there is
lane sharing in order to avoid any “double counting” of spare capacity in
lanes. For a full discussion of how turn and link capacities are defined please
see 8.9.
5) Various text characters - +, & etc., - may appear in the output tables to
indicate certain properties of a particular turn or link. For example a ‘*’
following the delay indicates that the cycle times are different at the upstream
node and that therefore any signal co-ordination will have been lost (which
may, in turn, affect the delay calculations).
Similarly at the end of the line:
♦ * indicates blocking back,
♦ % indicates mid-link capacity restraint,
♦ ! indicates weaving and
♦ + denotes the fact that there are extra queues waiting on in-bound
centroid-connectors.
5120257 / Apr 15 17-14

Section 17
Table 17.1 – Node 22 – Delays and Flows for Each Turn

Ave.
Fixed Assgnd QUEP Arrive Qued Actual V/C
From To Delay Capacity TPM
Flow Flow UP Flow Here Flow %
(secs)
From To All values in pcus-hr
21 71 0.0 0.0 0.0 0.0 0.0 0.0 0.0 1321.4 0.0
21 23 0.0 0.0 500.1 0.1 500.0 0.0 500.0 5087.8 9.8
21 48 7.4 0.0 258.7 0..1 258.6 0.0 248.6 963.8 26.8 X
Totals 21 2.5 0.0 758.8 0.2 758.6 0.0 758.6 5163.8 14.7
From
23 48 0.0 0.0 180.0 0.0 180.0 0.0 180.0 1200.0 15.0
23 21 0.0 0.0 338.0 0.0 338.0 0.0 338.0 5390.0 6.3
23 71 7.0 0.0 0.0 0.0 0.0 0.0 0.0 556.8 0.0 X
Totals 23 0.0 0.0 517.9 0.0 517.9 0.0 517.9 5400.0 9.6
From
48 21 5.7 0.0 442.3 183.2 259.1 0.0 259.1 998.7 25.9 G
48 71 10.5 30.0 30.0 12.4 17.6 0.0 17.6 466.6 3.8 G
48 23 319.4 0.0 725.9 300.7 425.2 93.9 331.3 331.3 128.3 G
(TAILBACKS 0.0 TO 47.0 PCU’S)
Totals 48 195.9 30.0 1198.2 496.2 701.8 93.9 607.9 1595.0 44.0
From
Overall 70.4 30.0 2474.9 496.6 1978.4 93.9 1884.5 12159 16.3
(TAILBACKS 0.0 TO 47.0 PCU’S)
17.8 Network-based Simulation Summary Statistic

SATURN gives total summary statistics from the simulation network which
differentiate between travel which is judged to take place DURING the time period
simulated and that which is judged to take place in LATER time periods due to
over-capacity queuing.
A sample print-out of simulation summary statistics is given in Table 17.2 with
each total divided into, e.g., pcu-kms in the simulated time period, in the next time
period (or, strictly speaking, in all later time periods if it takes a trip more than 1
period to reach its destination) and in total.
The division of pcu hrs between “this” and the “next” time period is based on the
areas illustrated in Figure 17.4. Thus the pcu-hrs in the first time period is made
up of areas (1) and (2) while that in the next time period is made up of that from
queued traffic on that link (areas (3) and (4)) plus that portion of areas (5) and (6)
that is made up of traffic currently queued upstream.
In terms of distance travelled the assumption is made that the queue is “vertical”
such that all vehicles which arrive during a time period (independent of whether or
5120257 / Apr 15 17-15

Section 17
not they depart) travel the full length of the link during that arrival time period. By
contrast the vehicles queued upstream travel the full distance in later time periods.
Hence in the statistics described below any pcu-kms in later time periods can only
arise from pcus queued upstream.
Note that the “next time period” statistics are, of necessity, only estimates since a
model based on, say, the half hour from 8:00 to 8:30 has no way of knowing what
traffic conditions will be like after 8:30. The estimates of future queues are
controlled by the parameter AFTERS as described in 17.6.2. A more correct set
of figures may be obtained if you are using the PASSQ option, see Section 17.3,
in which case the summary statistics for the PASSQ flows in the next time periods
may be substituted as done by SATSUMA.
Similar tables are produced, in addition to those for total pcu flows, at a more
disaggregate level either by flow (e.g. by user class) and/or capacity index/TfL
traffic borough/zonal grouping. See 11.11.4.
N.B. In order for data disaggregated by capacity index to include delays per
turning movement in addition to pure link-based totals make sure that the
parameter BEAKER is set to .TRUE. in your original network .dat file, otherwise
the indices defined by link do not get extended to the downstream turns. See
5.1.9.
Table 17.2 - Simulation Network Absolute Totals
This Time Next Time

Measure Total (Units)
Period Period
TRANSIENT QUEUES 41.5 7.3 48.8 pcu. hrs.
OVER-CAPACITY 114.7 30.0 144.7 pcu. hrs.
QUEUES
(ON LINKS 57.7 29.0 86.7 pcu. hrs.
ON CENTROIDS 57.0 1.1 58.1) pcu. hrs.
LINK CRUISE TIME 70.6 10.3 80.9 pcu. hrs.
(FREE FLOW 67.4 9.3 76.6 pcu. hrs.
DELAYS 3.3 1.0 4.2) pcu. hrs.
TOTAL TRAVEL TIME 226.9 47.6 274.5 pcu. hrs.
TRAVEL DISTANCE 2341.2 220.3 2651.5 pcu. kms.
OVERALL AVERAGE 10.7 4.6 9.7 kph
SPEED
FUEL CONSUMPTION 501.3 93.9 595.2 litres
An explanation of the terms used follows:
♦ TRANSIENT QUEUES: The time spent by vehicles in queues which, in the

case of signals, clear during a single cycle, as opposed to ...
♦ OVER-CAPACITY QUEUES: the extra time spent in queues at over-capacity

junctions waiting for the cycle in which the vehicle exits (subdivided into
5120257 / Apr 15 17-16

Section 17
queues on the links and, if there are any, queues on centroid connectors due
to blocking back (see 8.5))
♦ LINK CRUISE TIME: Time which would be spent travelling on links,

subdivided into free-flow speeds and the flow-specific extra travel time on
those links with link speed-flow curves (see 8.4.4).
♦ TOTAL TRAVEL TIME: The sum of both link and junction times.
♦ TRAVEL DISTANCE: Vehicle or pcu-kms on simulation links.
♦ OVERALL AVERAGE SPEED: Defined by (total distance) / (total time)
♦ FUEL CONSUMPTION: As estimated by time, distance and the number of

primary and secondary stops (see 15.32).
See Section 17.11 for a more detailed explanation of the formulae used to
calculate these statistics.
17.9 Combined Simulation and Buffer Total Statistics
17.9.1 Simulation Network Totals

The absolute simulation network totals described in 17.8 may also be combined
with absolute totals from a buffer network to give total statistics for the whole
network. A sample print out is given in Table 17.3.
Table 17.3 - Simulation (S), Buffer (B) and Buffer Centroid Connectors (BCC)
Total Travel Statistics
Absolute Totals: This Time Period Next Time Period Total
Transient Queues (pcu-hrs) (pcu-hrs) (pcu-hrs)
(S) 41.5 7.3 48.8
(B) 3.3 0.3 3.6
(T) 44.8 7.6 552.4
Over-Capacity Queues (pcu-hrs) (pcu-hrs) (pcu-hrs)
(S) 114.7 30.0 144.7
(B) 256.6 234.7 491.3
(T) 371.3 264.7 636.1
Link Cruise Time
(S) 70.6 10.3 80.9
(B) 98.1 98.1
(BCC) 35.4 35.4
(T) 204.1 10.3 214.4
Total Travel Time (pcu-hrs) (pcu-hrs) (pcu-hrs)
(S) 226.9 47.6 274.5
(B) 358.0 235.0 593.0
(BCC) 35.4 35.4
(T) 620.3 282.6 902.9
5120257 / Apr 15 17-17

Section 17
Travel Distance (pcu-kms) (pcu-kms) (pcu-kms)

(S) 2431.2 220.3 2651.5
(B) 2462.3 2462.3
(BCC) 490.0 490.0
(T) 5383.5 220.3 5603.8
Average Speed (km/h) (km/h) (km/h)
(S) 10.7 4.6 9.7
(B) 4.2 4.2
(BCC) 13.8 13.8
(T) 8.7 6.2
Here absolute totals, e.g. pcu-hrs, are subdivided by link type - simulation (S)
which here includes queues on simulation centroid connectors, buffer links (B)
and buffer centroid connectors (BCC) - and by this time period / later time periods.
Thus the simulation-based totals are not as disaggregate as those in Table 17.2
but are similar to those defined in the buffer networks.
In the buffer network link times are divided into three components to provide
comparability to simulation statistics:
♦ free flow = cruise times (t o )
♦ “transient queues” (AVn or ACn if V>C)
♦ over-capacity queues (B*(V-C)/C)

where the equations refer to equations (5.1) in Section 5.4.
In the buffer network pcu hrs in later time periods only result from those buffer
links where the demand (= actual) flow exceeds the capacity. Thus, with
reference to Figure 17.4, the transient queues in this/next time period correspond
to areas (1) and (4) respectively while the over-capacity queues similarly refer to
areas (2) and (3). Buffer distance is flow times distance. Again assuming a
vertical queue neither link cruise time nor distance can spill over into later time
periods; hence certain “next time period” entries in Table 17.3 are deliberately left
blank rather than being entered as zero.
The totals associated with “penalty times” refer to those “time” penalties as input
within the 44444 network data records (6.7) factored by the relevant flows on
those links or turns and converted into pcu-hrs. As with the previous measures
they are disaggregated by link type and by within/next time periods.
The toll totals are similar to the penalties although the tolls may be set either
within the 44444 records or via KNOBS inputs; both are included here.
Finally “total trips loaded” refers to the sum of all outbound trips which depart from
origin zones within that time period, in effect the sum of all trips in the (demand)
trip matrix. However it excludes any trips associated with unconnected o-d pairs
(e.g., where a zone has only in-bound centroid connectors in the network but has
out-bound trips in the trip matrix) and all intra-zonal trips. It is also the “demand”
total as opposed to the “actual” total which might be calculated as the sum of all
actual flows on in-bound centroid connectors to destination zones. Equally it does
5120257 / Apr 15 17-18

Section 17
not include any flows assigned under PASSQ. Finally under elastic assignment it
represents the final trips which are assigned to the road network and should
therefore be identical with the total number of trips in the output road trip matrix.
The data given in Table 17.3 are, in general terms, the “best” statistics to use for
overall network performance since they include all network components - buffer,
simulation, centroid connector - at the equivalent levels. They supersede - and
should be used in preference to - the “assignment network statistics” available
within SATLOOK which do not differentiate sufficiently clearly between demand
and actual totals, i.e. totals within this and later time periods.
17.9.2 Averaged Statistics over Multiple Loops

Aggregate data such as that in Table 17.3 is obtained from the link times, flows
etc. calculated on the final iteration of the assignment-simulation loops within
SATALL. They should therefore represent the best available information in the
sense of being most highly converged. However, despite this, if oscillations are
seen to occur in the data from loop to loop it could be argued that more reliable
results which would reduce the “noise” inherent in imperfectly converged solutions
could be obtained by averaging the data over, say, the final 4 loops.
This, post version 10.3, may be achieved as an option within SATLOOK (either on
its own or accessed from within P1X) through option 3 which allows both
averaging over the final n (user set) loops and/or printing of data (in the form of
Table 10.3) from a particular loop, not necessarily the final loop. The necessary
data from each loop (up to a certain maximum) is accumulated within SATALL
and included within the output .ufs files; see 9.7.
It has to be said that I have certain misgivings about this practice. In particular I
cannot see any advantage to using averaging data while the numbers being
averaged are consistently changing in one direction. For example, if the total
travel times on the final 4 loops were 102.0, 101.0, 100.5 and 100.0 then I would
much prefer to take 100.0 as my “best” answer than the average of the 4, 100.9.
On the other hand if the final 4 numbers were, in order, 101.0, 100.0, 102.0 and
100.5 then I can see the case for using 100.9. It’s up to the users to make up
their own minds! Printing the data from several final iterations may certainly help
you decide.
17.10 Delay-based Arrays in .UFS Files: Definitions

There are a large number of “Dirck Access” arrays stored on .ufs files which refer
to delays and/or travel times in different contexts. This section attempts to explain
the precise definitions used in each case.
The following table lists the DA code plus explanation. Those denoted * are
defined only for simulation links and those with a † are for simulation turns; all
others refer to assignment links which include both simulation links and turns as
subsets.
363* - TIM: Simulation link (cruise) time, either the free-flow time on links
without speed-flow curves or, post assignment, the flow-dependent
time on links with speed flow (6.4.12). (To obtain the "free flow" times
on simulation links use array 1803.)
5120257 / Apr 15 17-19

Section 17
1513* - DELRD: The average turn delay per vehicle (pcu) on a simulation link
weighted by turning flows plus any delays on the link from link
capacity constraints. The turn delays are based on those in 1633.
N.B. Both transient and queuing delays from V>C are included.
1543* - TLQT: The total pcu-hrs of delay per link within the current time
period, e.g., areas (1) and (2) in fig. 17.3 for an initial time period on
areas (3) to (6) for later time periods, plus any delays on simulation
links with speed-flow curves.
1633† - DEL: The turn delay per simulation turn including both transient and
over-capacity queuing effects but excluding any delays associated
with link capacity-restraint curves.
1653† - DEL_TR: The “transient” delay per simulation turn; i.e. excluding any
delays associated with over-capacity queuing.
1803 - FTIME: The “free-flow” time on all links within the assignment
network. For simulation turns (which have zero distance by definition)
this represents the delay for arrival flows approaching zero but with
all other flows (opposing or lane sharing) at their current value; it
therefore represents the minimum possible values for total turn delays
in, say, 1633 or 4003 and it is definitely considered as a delay. On
the other hand for all other assignment links which have a distance
(i.e., including simulation links) 1803 represents the cruise time at the
maximum link speed and in these cases should not be considered as
a “delay” component.
1853 - DATC: The delay at capacity, i.e. the difference in travel times
between flow=capacity and flow=zero. This may be used to
“parameterise” the flow-delay equations: see ??
4003 - Assignment Time: The times for each assignment link as calculated
during the assignment process as given by equations (8.5) (or, strictly
speaking, their more complex forms (8.11)).
4013 - Simulation Time: As 4003 but with the times for simulation links or
turns updated according to the simulation which follows the
assignment; i.e. using the data in 363 and 1633.
4023* - Simulation Time by link: Identical to 363.
17.11 Formulae for Calculating Totals

This section gives the definition of each component of, e.g., total pcu-hrs as listed
in various standard output tables and gives equations by which these numbers
may be calculated externally by users using, e.g., spreadsheets. It is divided into
three sub-sections to cover (a) simulation networks, (b) buffer networks and (c)
bus-only lanes within simulation networks.
WARNING: Whilst the formulae described below provide the basic calculations for
reproducing the simulation statistics outside SATURN, we recommend that
SATURN should always be used to estimate them. This is particularly important
for more complex examples involving networks using the PASSQ option.
17.11.1 Simulation Network Totals
5120257 / Apr 15 17-20

Section 17
The table below lists, in symbolic form, the absolute totals statistics within the
simulation network as illustrated in numerical form in Table 17.2.
TIME PERIOD: THIS NEXT TOTAL
Transient Queues (pcu/hrs) TQ.1 TQ.2 TQ.3
Over-Capacity Queues (pcu/hrs): CQ.1 CQ.2 CQ.3.
On Links CQL.1 CQL.2 CQL.3
On Centroids CQC.1 CQC.2 CQC.3
Link Cruise Time (pcu-hrs): LT.1 LT.2 LT.3
(Free Flow) LTF.1 LTF.2 LTF.3
(Delays) LTD.1 LTD.2 LTD.3
Total Travel Time (pcu-hrs) T.1 T.2 T.3
Travel Distance (pcu-kms) D.1 D.2 D.3
Stops (Primary) PS.1 PS.2 PS.3
Stops (Secondary) SS.1 SS.2 SS.3
Fuel Consumption (litres) FC.1 FC.2 FC.3
The totals above may be calculated from the formulae given below, thus rendering
all output statistics totally transparent to the users. It also makes it possible for
users to calculate statistics for, e.g., a subset of links or for a particular user class.
Elements such as X1653, X4513 refer to the data contained in DA arrays 1653,
4513 etc, parameters such as LTP and AFTERS refer to standard namelist
parameters described in 6.3 and the numerical values such as 3600 and 60 are
necessary to convert, e.g. seconds into hours. Division by 2 is sometimes used
(e.g., in CQL.1) to calculate an average queue which is half the final queue.
WARNING: The formulae given implicitly assume that multiple time periods and
PASSQ are not being used such that the queues at the start of the time period
are zero. In particular this affects the queuing statistics CQ.1 etc. and other
formulae, e.g., fuel consumption, that make use of them. In principle it would be
possible to write down the correct formulae but it would be complicated!
In addition they do not include any contribution from buses on reserved lanes
which must be added some (not all) of these categories. A separate set of
equations is given in 17.11.3.
To calculate any of the quantities below it is necessary to first read the required
DA arrays into, say, SATDB or an equivalent spread sheet, calculate new data
columns following the formulae given and then sum individual link values over a
certain subset. Thus to calculate TQ.1, transient queues in “this” time period, first
read in DA arrays 1643 (turn capacity), 1653 (transient delay per pcu) and 4513
(actual flows), perform the calculation indicated and sum over all simulation turns.
Note that in certain cases not all simulation turns or links should be included but
an extra condition needs to be applied; e.g. that there is a permanent queue
greater than zero on that link or turn, as with CQL.2. The select rules are given on
the far right.
5120257 / Apr 15 17-21

Section 17
In addition certain sums, e.g. CQL.2, are best calculated via certain “intermediate”
variables. Thus Q represents the number of queued pcus at the end of a time
period.
Quantity Formula Sum Over Select
TQ.1 X1653/3600 * min( X4513, X1643 ) * LTP/60 Sim Turns
TQ.2 TQ.3 - TQ.1
TQ.3 X1653/3600 * X4503 * LTP/60 Sim Turns
CQ.1 CQL.1 + CQC.1
CQ.2 CQL.2 + CQC.2
CQ.3 CQL.3 + CQC.3
CQL.1 X1483 * (LTP/60) /2 Sim Links
CQL.2 V * Q / X1663 Sim Turns Q>0
Q = (X4513 - X1643) * LTP/60
V = 0.5*Q + AFTERS*(X4503 - X4513)*LTP/60
CQL.3 CQL.1 + CQL.2
2
CQC.1 (X1403-X1393) * {LTP/60} / 2 Sim Links X1393>0
2
CQC.2 {(X1403-X1393) * LTP/60} / 2(X1393 * X1673) Sim Links X1393 >0
CQC.3 CQC.1 + CQC.2
LT.1 X4013 * X4513 * (LTP/60) / 3600 Sim Links
LT.2 LT.3 - LT.2
LT.3 X4013 * X4503 * (LTP/60) / 3600 Sim Links
LTF.1 X1803 * X4513 * (LTP/60) / 3600 Sim Links
LTF.2 LTF.3 - LTF.1
LTF.3 X1803 * X4503 * (LTP/60) / 3600 Sim Links
LTD.1 LT.1 - LTF.1
LTD.2 LT.2 - LTF.2
LTD.3 LT.3 - LTF.3
T.1 TQ.1 + CQ.1 + LT.1
T.2 TQ.2 + CQ.2 + LT.3
T.3 TQ.3 + CQ.3 + LT.3
D.1 X1893 * X4513 * (LTP/60) / 1000 Sim Links
D.2 D.3 - D.2
D.3 X1893 * X4503 * (LTP/60) / 1000 Sim Links
KPH.1 D.1 / T.1
5120257 / Apr 15 17-22

Section 17
Quantity Formula Sum Over Select

KPH.2 D.2 / T.2
KPH.3 D.3 / T.3
PS.1 X1523 Sim Turns
PS.2 X1523 * (X4503 - X4513) / X4513 Sim Turns
PS.3 PS.1 + PS.2
SS.1 X1533 Sim Turns
SS.2 X1533 * Q / (X1663 * LTP/60) Sim Turns Q>0
Q = max [ {(X4513 - X1643) * LTP/60}, 0.0]
V = 0.5*Q + AFTERS*(X4503 - X4513)*LTP/60
SS.3 SS.1 + SS.2
FC.1 FLPK * D.1 + FLPH * (TQ.1 + CQ.1) + FLPPS *
PS.1 + FLPSS * SS.1
FC.2 FLPK * D.2 + FLPH * (TQ.2 + CQ.2) + FLPPS *
PS.2 + FLPSS * SS.2
FC.3 FC.1 + FC.2
17.11.2 Formulae for Calculating Buffer Totals

The formulae in 17.11.1 apply only to quantities within the simulation network; a
more limited set of statistics apply to buffer network summations, for example
“Transient Queues (B)” as illustrated in numerical form in Table 17.9.
We therefore provide here the equivalent formulae for CQB.1 and CQB.2 (over-
capacity buffer queues within the time period and within the next time period
respectively). Note that the summations must be over selected links: (a) which
are buffer and (b) where V > C (X4503 > X1833).
0.5 ∗ ( X 4503 − X 1833) ∗ ( LTP / 60 )

CQB.1 =
2
0.5 ∗ ( X 4503 − X 1833) ∗ ( LTP / 60 )  / X 1833

2
CQB.2 =
Thus, referring to Figure 17.3, CQB.1 is represented by triangle 2 and is equal to

one half the height ((V-C) in pcu/hr multiplied by LTP in hours) times the base
(equal LTP in hours). Hence the units are pcu-hrs.
Similarly CQB.2 is represented by triangle 3 with the same height as above but
with base equal to the queue at the end of the time period divided by its capacity
(X1833).
To obtain the equivalent summations for transient queues (TQB.1 and TQB.2) it is
easiest to first calculate (for the same selected links as above) the transient queue
(in seconds) per (over capacity) buffer link I as the difference between the total
delay (equals total time 4003 less free flow time 1803) and the over-capacity delay
component:
5120257 / Apr 15 17-23

Section 17
=
TQi X 4003 − X 1803 − 0.5 ∗ ( X 4503 / X 1833) − 1.0  ∗ ( LTP / 60 ) ∗ 3600
Then, sum the product of TQ i and the length of the over-capacity queue at the end
of the time period LTP over the same over-capacity buffer links as above to
obtain:
TQB.2 =∑ TQi ∗ ( X 4503 − X 1833) ∗ ( LTP / 60 ) / 3600

i
N.B. Division by 3600 converts from pcu-sec to pcu-hr.
and: TQB.1=  X 4003 ∗ X 4503 ∗ ( LTP / 60 )  / 3600 − TQB.2 − CQB.1 − CQB.2
Where the first term above (which gives the total vehicle delay in pcu-hr) must be
summed over all buffer links, independent of whether or not they are over
capacity. Again division by 3600 is necessary to convert pcu-sec to pcu-hr.
17.11.3 Totals for Reserved Bus-only lanes

Buses which are allowed to bus exclusive bus-only lanes within the simulation
network are not explicitly included in the formulae listed in Section 17.11 although
they are included within certain (not all) elements in, e.g., Table 17.3.
The following set of equations indicate, using the notation at the start of Section
17.11.1, which elements include bus-only lanes and the equations necessary to
calculate the bus-only contribution. These should be calculated separately before
being added to the relevant simulation totals.
TQ.1 / TQ.3 X1803 * X2033 / 3600 Sim turns
D.1 / D.3 X1893 * X2033 / 1000 Sim links
LT.1 / LT.3 X4013 * X2093 / 3600 Sim links
LTF.1 /LTF.3 X1803 * X2033 / 3600 Sim links
Note the bus lane modeling assumes no difference between actual and demand
(i.e., scheduled) bus flows so that all the “next time period” totals TQ.2 etc. are
zero. And, in addition, there are no bus lanes coded within the buffer network.
5120257 / Apr 15 17-24

Section 17
10.9.17 Web release – Jun 10 DVV DG IW IW 22/06/10
5120257 / Apr 15 17-25

Section 17
Network Structure and Editing: PMAKE
18. Structure and Editing: PMAKE

INTRODUCTION
This section should be read in conjunction with Section 11.9 which documents, in
effect, a “sub-set” of the editing functions within SATURN, specifically the editing
of “properties” as opposed to structure. This chapter deals with the more general
problem of editing the network topology in addition to properties.
18.1 Network data base structures

This section gives a somewhat brief description as to the various ways in which
network descriptive data is stored and processed within SATURN. It serves as an
introduction to the PMAKE network editing procedures described below.
The essential database structure and flow is illustrated in Figure 18.1. Thus at the
start of the process we have the network.dat file (including any $INCLUDE files)
which, as we shall see below, is the critical element in the data structure. The .dat
file is, in computer terms, an ascii or text file, i.e. one that may be viewed and
edited directly on screen using standard facilities such as EDIT or NOTEPAD or
even word processors (if you are careful!; see 2.8).
From the basic .dat file SATURN (more specifically, SATNET) constructs a set of
sub-networks:
♦ the simulation network;
♦ the buffer network;
♦ the assignment network.

which are largely invisible to the user and stored (only) within the binary .uf* files.
The assignment network is constructed by combining together the necessary
elements of both the simulation and buffer networks into a single structure as
required by the assignment routines. See also 5.5.1.
Each of these three sub-networks possesses its own topology, input data (such as
link distances) derived directly from the .dat file and output data (such as flows
and actual travel times) which are calculated within the assignment/simulation
process via SATALL.
In addition a fourth network descriptor is constructed, the map network, which
provides the basic “lines on a road map” structure displayed by P1X and is what
the user “sees”; it is basically only topological. See also 5.5.2.
All four networks are closely inter-related and contain a series of “conversion
arrays” which convert between them; e.g. a road in the simulation network will
have an equivalent link in the assignment network and a further equivalent link in
the map network. Other data sources within SATURN are also stored in terms of
the same network structures; for example bus routes are stored as a series of
simulation and/or buffer elements which may in turn be converted into links in the
map network for display purposes and into assignment links for loading purposes.
5120257 / Apr 15 18-1

Section 18
Figure 18.1 - Basic Data Structures
There is thus, as shown in Figure 18.1, a direct relationship between the

information held in the network .dat file and the display of that network on the
screen via the map description.
The most important point to be made from Figure 18.1 however is that all the data
structures stem from the original .dat file and that therefore the .dat file is the
ultimate and 100% definitive source of network structure. Thus when you edit a
network, even though you may be making the changes on the screen, until they
are entered and saved within a .dat file they are only temporary. The objective of
an editing exercise (as well as constructing a network from scratch) is to produce
a network .dat file as illustrated at the bottom of Figure 18.1.
5120257 / Apr 15 18-2

Section 18
It could be argued that using ascii-based data files as the ultimate data source is
an out-moded form of operation in the 21st century and that a “proper” data base
system should be used instead. Fair point! In their favour ascii files have the
advantages that: (a) they work and (b) they are perfectly transparent to the user
who can alter the network properties using an editor and “see” exactly what the
data base contains. Thus a 1 in column 28 of a buffer link record (see 6.6)
unambiguously defines that link as 1-way, 2 implies 2-way, etc. etc. What you see
is what you get!
A further less obvious point which occurs during editing is that if the underlying
network topology is changed, e.g. by adding or deleting links, then all the various
pointers that relate, say, simulation data to map data or assignment data are no
longer valid and that they must be reconstructed by, in effect, re-running SATNET.
18.2 Network Editing

In general network editing within SATURN may be divided into:
♦ Changes to “properties” of the existing network, e.g. link capacities.
♦ Changes to the network “topology”, i.e., additions or deletions of nodes, links

or turns.
Both are reflected by changes to the basic .dat file (and thence to any output .uf*
files). Clearly therefore both may be accomplished by manual editing of the .dat
files; however both may also be accomplished interactively using P1X in one of
two “modes”; corresponding to i) and ii) above.
Thus property changes may be carried out using the standard editing facilities
within P1X (see 11.9) operating on an existing network. Thus each of the 8
standard data segments 11111, 22222 etc. may be edited as well as the
&OPTION and &PARAM segments (see Section 6). Note that such changes do
not affect any of the “linkages” between any of the network components shown in
figure 18.1 and that the edited network may be saved as either a new .dat or a
new .ufs file.
Topological changes may be applied either to an existing network or to a network
which is created “from scratch”. Both the latter operations are carried out by the
program P1X but operating under the name PMAKE. In either case topological
changes destroy the linkages between network components mentioned above and
the only possible output is the .dat file to be fed back through SATNET.
Changes to properties are documented within Section 11.9 whereas the
topological (PMAKE) changes are described within the remainder of this chapter.
There is however a large amount of overlap between the two and they should
probably be read in conjunction with one another.
18.2.2 The Internal Data File and Output .Dat Files

Both sets of procedures edit an “internal” .dat file which, in technical terms, is
stored as a temporary “direct access” file; basically this means that data records
may be conveniently inserted and/or deleted at any point within the file. Initially, if
5120257 / Apr 15 18-3

Section 18
one is editing an existing network, the internal .dat file is simply a copy of the
original network .dat file; if the network is being created from scratch a prototype
.dat file is created.
External copies of the .dat file may be “saved” at any point within the editing
process (as shown in Fig. 18.1). Thus an output .dat file is simply a straight
forward copy of the internal .dat file. In the same way that you are strongly
advised to take frequent back-up copies of, say, word document files it is also a
very good idea during editing to periodically take copies of the .dat file, just in case
something terrible happens.
The internal data may also be output or “saved” in other formats, in particular as
.ufn file as described in 18.2.6 below.
18.2.3 Editing $INCLUDE files

As described in Section 15.30 network .dat files may contain $INCLUDE records
which, in effect, point to subsidiary data files to be inserted at that point. Problems
may arise with the editing functions if the data which one wishes to modify is
contained in an included data file rather than the main .dat file.
This problem is overcome by optionally explicitly including the $INCLUDE files
directly within the internal data file described above where changes may be made.
For example, if you wish to make changes to a simulation node whose original
data is included in an $INCLUDE file this can only be done by first reading in that
file. On the other hand if you are making changes to simulation nodes which were
coded as part of the “master” .dat file it is not necessary to read in the $INCLUDE
files.
For each relevant data section (i.e., simulation data, simulation centroid
connectors, buffer data, etc.) the user is given the initial option to read in the
$INCLUDE file(s) or not. Generally speaking, unless you know for certain that you
will not be referring to data in a $INCLUDE file it is best to read them in.
Equally, at the end of each editing step the user has the choice of whether or not
to over-write the $INCLUDE file using the original filename.
At this stage our advice is that it is probably safer not to output new versions of
the $INCLUDE files since it is not always obvious whether the changes you have
made will have been recorded within those data records which are “internal” to the
$INCLUDE file or within records which will be part of the master .dat file. It may
therefore be safer to save the fully edited .dat file and then re-create the
$INCLUDE files by “cut and copying” from the full file.

Within each data sub-section it is also possible to directly edit the contents of that
segment using standard Windows edit boxes, in which case the “new” data file
once saved is “read in” using the standard data conventions described in Section
6. Thus if you do invoke direct screen editing you must be very careful not to
introduce data format errors which may confuse the editing routines more than
somewhat and make further corrections much more difficult.
5120257 / Apr 15 18-4

Section 18
It is also possible to screen edit over more than one data segment by specifying
the first line in the .dat file and up to 200 (roughly) lines following.
18.2.5 Output .UFS Files

An output .ufs file may only be saved if there was one input (as opposed to using
PMAKE to create a network file from scratch) and the only editing changes have
been to network properties, for example you have used P1X editing to optimise
the stage times.
Output .ufs files should be used with some care as it is not always intuitively
obvious as to which changes will or will not be included in an output .ufs file. Thus
topological changes are definitely not included, but neither are changes to bus
routes or link counts. See also 11.9.2.
18.2.6 Rebuilding a .UFN file

Creating a .ufn using P1X essentially incorporates the functions of (or most of the
functions of) SATNET within P1X. This option processes the internal .dat file in
the same way that SATNET does in order to produce: (a) an output .ufn file and
(b) - and perhaps more usefully - information on the errors encountered in
processing that .dat file.
The error listings are stored in a text file with extension .lp1 which is closed at the
end of rebuilding and may therefore be subsequently viewed by the user using
any standard text file editor such as Notepad or even Word in order to obtain full
information on any errors encountered during the building. A summary table of
errors, including full listings of all fatal and semi-fatal errors, is also output in a text
window.
Thus the so-called “Rebuild” option is useful for checking for data errors prior to
exiting from P1X and before running a new .dat file through SATNET in order to
correct those errors. Note that Rebuild/SATNET will pick up coding errors that
may not be picked up in, e.g., editing individual simulation nodes since it also
checks for inconsistencies “between” nodes.
Rebuilding is also extremely useful if you have made topological changes to the
network since it will produce, within the .ufn file, new simulation, buffer and
assignment networks which are all “in synch” with the latest map network. It also
updates any alterations made to bus routes.
Once created, the new .ufn file may be used to replace the current main input
network file to P1X, i.e., “network 1” as described in 11.4.1. (Or, in the case of
creating a network from scratch, it becomes network 1.) The old network may
then, optionally, be used as one of the other three alternative input files.
Note however that, by definition, .ufn files do not contain any information relating
to assignment and/or simulation. Thus if you edit a .ufs file which has been
through the assignment/simulation and replace it by a newly-created .ufn file and
continue to edit then any information on the assignment plus simulation etc. will
have been lost.
5120257 / Apr 15 18-5

Section 18
Equally, of course, .ufn files may be created by running SATNET directly on a .dat
file output by P1X/PMAKE but, in order to do this, it may be necessary to exit from
P1X first.
18.2.7 Repeated Edits using PMAKE

Once an initial version of a network has been created via PMAKE, saved as a .dat
file and the program closed it is possible to carry on the editing by converting the
.dat file into a .ufn file via SATNET and then using that file as input to a further run
of P1X as explained in 18.4. The further network alterations may be either
topological (using PMAKE) or pure data edits.
Alternatively, the .ufn file may be created directly within P1X/PMAKE as described
in 18.2.6 although, if you do use this facility, it is strongly recommended that you
also save your data as a .dat file as well for added security.
18.3 PMAKE - Network Building from Scratch
18.3.1 Objectives
PMAKE is the name given to a bat file which in fact runs P1X but without its
normal input .ufs file(s) such that the network is built entirely interactively on the
screen. In the context of figure 18.1 PMAKE builds (internal) map and .dat files
simultaneously such that at the end of the building/editing stages the internal .dat
file may be saved as a proper .dat file for input to SATNET (or for “internal”
rebuilding of a .ufn file).
Thus the main objective of PMAKE is to create a .dat file for input to SATNET - or,
perhaps more accurately, to help in the creation of a .dat file. While PMAKE is
very good at certain operations, such as defining nodes and links, it is not perfect.
Users must therefore expect that at some stage in preparing a network .dat file
they are going to have to “get their hands dirty” by doing some manual editing of
their dat file. Sorry, but life's like that!
Having, as a first stage, created a .dat file and, via SATNET, a .ufn file further
network editing may be continued by using the .ufn file as an input to P1X and
then choosing Network Editing from the top P1X menu as per 18.2 and 11.9.
Further topological changes may be made by entering PMAKE from the Edit
Menu.
PMAKE also maintains internally a purely buffer-style representation of the
network being created with its topology stored correctly but with only limited data.
This means that having built a network via PMAKE some of the normal analysis
functions of P1X become available, e.g. you may display link data or (possibly)
display shortest path trees. On the other hand, although you may define
simulation-nodes within PMAKE, it does not set up a simulation network structure.
All simulation-based data is stored only on the direct access .dat file.
However, by using the rebuild option to create a .ufn file, it is possible, without
exiting from PMAKE, to create a network with full simulation network details
included.
5120257 / Apr 15 18-6

Section 18
18.3.2 Input Screen

On entry to PMAKE with no network the user may either:
♦ work from a blank screen, or
♦ use an input bitmap file as a “template” to trace over.

The latter is highly recommended as a quick and convenient way to translate
existing map images into a SATURN network. Bitmap files as produced by the
scanned image of a normal road map may be used in this way. See 15.43
Note that bitmap or other graphics images files other than .bmp or .pcx files may
not be directly read into PMAKE. However it is generally not too difficult to use
standard graphics software packages such as PAINT to read in, e.g., a gif
formatted file and to output the same image as a bmp file (the preferred PMAKE
input format). Equally if a .bmp file is too large or too small as displayed by
PMAKE then you may use PAINT etc to suitably expand/contract the image.
18.3.3 Setting Co-ordinates

In addition to the background (or lack of it) the user is also required to set the co-
ordinates of the network being created in order to “scale” a point on the screen
into X, Y co-ordinates in, say, metres on the ground. Initially this is done by
specifying the co-ordinates of the four corners of the square screen; minimum and
maximum values of X and Y are sufficient to do this.
The parameter XYUNIT defines the units of XMAX etc in metres. Thus if XMIN =
0, XMAX = 1000 and XYUNIT = 1.0 (the defaults) then the equivalent horizontal
width of the window plotted would be 1000 metres. Setting YMAX to 1000 would
then imply that the image to be read in represents a 1 km square.
However given that most monitor screens are not square but rectangular it follows
that if you wish to use the full width and height of the screen you will need to set
XMAX etc appropriately (bearing in mind that the banner will be on the right hand
side). As a rough guide setting XMAX - XMIN to 1200 and YMAX - YMIN to 1000
(or in ratio) should use the full screen.
Note that the scaling between screen and real world may also be set (or re-set) at
later stages once part or all of the network has been defined. This option
becomes more convenient if the X, Y co-ordinates of 2 or more nodes are
available but the corners of the plot are less clearly identified.
Correct scaling factors are potentially important since they allow distances on the
screen to be correctly translated into link distances (in metres).
18.3.4 Creating Nodes and Links

Having established the scaling the user may now move on to the definition of new
nodes as described in 18.5 followed by the definition of new links joining the
nodes as described in 18.6. These stages need not be strictly consecutive
(although clearly you need some nodes before you can define links); thus you
may return to the node building stage at any subsequent point in the building
process.
5120257 / Apr 15 18-7

Section 18
The namelist parameters to be eventually included in the output .dat file under
&OPTION and &PARAM may also be set at any point during building; see
11.9.10.
Note that it is highly recommended that, as with word processing for example,
frequent copies of the current network are created using the “Save to a dat file”
options. Thus if mistakes do occur - whether yours or ours - the whole editing
session should not be lost.
In addition there may be advantages, having saved a .dat file, to exit
PMAKE/P1X, use SATNET to build a .ufn file from the latest .dat file and to
continue the editing from P1X as described next.
18.4 PMAKE: Editing Existing Networks

The network editing facilities within P1X allow users to edit either existing .uf* files
in conjunction with their associated .dat files or networks which have been built
from scratch via PMAKE directly (see 18.2.7).
PMAKE is entered from the “top” network edit menu in P1X (see 11.9.1). It differs
from the other editing functions listed in 11.9.1 (although some of these may also
be accessed from within PMAKE) in that it allows changes to the network
topology as opposed to changes to the properties of existing links. This implies,
in terms of the “new” output files shown in Figure 18.1, that only a new .dat file
may be produced once topological changes have been made by PMAKE since
the necessary “linkages” intrinsic within a .ufs file will have been broken.
The two basic topological options available are to add and/or delete nodes and
links. (The other options to edit namelist variables, to save files etc. are standard
items available elsewhere and which do not affect the network topology). Node
and link editing are described in the following two sections.
Note that the input .uf file used in this context may be a “NAFF” .ufn file, i.e. the
original .dat file contained semi-fatal errors (see 6.12) so that it cannot be used by
SATALL but was sufficient to generate map definitions. PMAKE may be used in
this context to make the necessary corrections to the .dat file.
18.5 Node Editing within PMAKE
18.5.1 Creating and Deleting Nodes

Nodes (including zones) within a network may be edited in the following ways:
1) By adding new nodes (zones)
2) By deleting existing nodes (zones)
3) By converting buffer nodes to simulation
4) By editing existing simulation nodes
5) By changing X, Y co-ordinates
6) By re-numbering existing nodes (zones)
5120257 / Apr 15 18-8

Section 18
7) By adding a new node in the middle of an existing link (see 18.6.4)

Clearly 1) and 2) alter the topology of the network and therefore the map
structure; less clearly 6) does as well, in particular when the re-numbering
changes the sequential order of the node numbers.
18.5.2 Adding Nodes

Nodes are added either as a new point in space or by splitting existing links. In
the former case the position is set by (left) clicking at a point on the map. By
default the new node will be a buffer node (but for the moment without links). Its
number may optionally be user-input each time a new node is created or
automatically added as the highest node (zone) number plus 1.
To split a link point to the position where the new node is to go and the link which
is to be split is decided by the existing link nearest to that point. (Generally the
new node should be virtually on an existing link so there should be little chance of
picking the wrong link.) As before the node number is generated by user input or
automatically. However in this case two new map links are created - i.e. if A,B is
divided at point C then A,C and C,B are both created as new 2-way map links -
plus up to 4 equivalent one-way buffer/simulation links.
Based on the position of the new node C between A and B certain link properties
of A,B are divided in proportion to crow-fly distances, for example link times and
distances, whereas others such as speeds or capacities retain their same values.
If A,B is a buffer link (the default when the network has been built from scratch)
then the sub-links are also buffer links. If however A and B are both simulation
nodes then C is also defined to be a simulation node coded, by default, as a
priority node (it may be edited into a different node type later if desired). At this
stage the coding in the .dat file for both nodes A and B is altered; for example the
entry arm at A from B must become an entry from C and the distance etc
corrected as above. Equally an entry for C is added as well within the 11111
records.
18.5.3 Deleting Nodes

Deleting a node means firstly that any entry under the 55555 data records is
removed but secondly and more importantly that any buffer or simulation links
involving that node are deleted. This also means that if, say, A is an entry to a 4-
arm simulation node B and A is deleted then B must become a 3-arm node. In
this case the .dat file entry for node B is revised to delete all entries referring to A
(with certain data columns removed as necessary) and the user is immediately
“offered” that node to edit (as per 11.9.3). This is particularly important if A is a
signalized junction since the stage timings will clearly need to be adjusted and it is
not easy for the program to make sensible “guesses” as to what these should be.
Deleting a simulation node A which is adjacent to an external simulation node B
may mean that B is also deleted from the 11111 records if B’s only links in the
simulation network are to A. However B would be retained within the buffer
network 33333 records.
Finally any centroid connectors to deleted simulation nodes are themselves
deleted and removed from the 22222 records.
5120257 / Apr 15 18-9

Section 18
18.5.4 Renumbering Nodes

Renumbering is restricted to buffer nodes and zones and any changes are only
recorded within the 33333 and 55555 data records. This means that if you
renumber a buffer node which is part of the bus route definitions under the 66666
records or counts under 77777 then - for the moment at least - they will not be
altered there.
18.5.5 Editing Simulation Nodes and Buffer Conversion

The editing of existing simulation nodes and the conversion of buffer nodes to
simulation are as described in sections 11.9.3 and 11.9.11 respectively.
18.5.6 Unconnected Nodes (ATLAS)

It is quite feasible to create new nodes and/or zones but not to create any links to
connect them, in particular when creating a network “from scratch” (18.3). In such
cases the new nodes, and their co-ordinates, will be contained within the 55555
records in an output .dat file. However, in general, in building a network .ufn file
SATNET ignores nodes in the 55555 records which are not included as links;
hence these nodes will not re-appear if you save a .dat file and rebuild your
network through SATNET.
However it is possible to include unconnected 55555 nodes as part of the map
network by setting a parameter ATLAS = T within the network &PARAM records.
This will be done automatically if the saved .dat file from PMAKE consists only of
nodes; otherwise it is optional.
This feature, post 10.6, therefore enables users to create networks which consist
ONLY of nodes and to add links at a later stage. Indeed it opens up the possibility
of “importing” a set of nodes plus co-ordinates (e.g. from a GIS package) into a
SATURN .dat file with only a set of 55555 data records, to build a .ufn network
with only map-based nodes present (the ultimate NAFF network!) and to rebuild
networks from there using PMAKE.
We note, however, that if there are extra ZONES included within the 55555 data
set which are not part of the simulation/buffer networks then it is not permitted to
proceed to the assignment stage, given that there may be confusion between the
network and the trip matrix as to which zones are really to be included. This leads
to a semi-fatal error (i.e., the output .ufn file from SATNET may still be edited via
P1X but it cannot be directly input into SATALL). The same restrictions do not,
however, apply to extra nodes added under ATLAS which do not appear in the
assignment network.
18.5.7 Errors in Node Coding

As noted in 2.9 errors in SATURN come in a variety of shapes and sizes ranging
from warnings to fatal errors. In editing nodes such errors may be either added or
(hopefully) removed by the changes made.
For nodes which have been processed through SATNET the standard “print”
option lists the number of each type of error defected by SATNET but not the
specific error message (which will be in the original .lpn file). Alternatively the
5120257 / Apr 15 18-10

Section 18
“error listing” options process the current node coding and prints both the total
number and the explicit messages.
In theory the errors should be the same in both cases (or until you begin to correct
them); in practice there may be slight inconsistencies in that SATNET probably
checks for a wider range of errors per node since it considers the network as a
whole rather than a single node on its own. Thus it is always wise to check the
.lpn files for error messages even if the editing options in P1X used to create the
.dat file do not indicate any problems.
Note too that it is possible to have fatal errors at nodes in P1X (which may be
treated as semi-fatal in SATNET). These may limit the options available; for
example it may not be permitted to simulate a node if it has some fatal errors or to
optimize traffic signal stage times if there are fatal errors in the stage definitions.
18.6 Link Editing within PMAKE

Link editing may be done by either:
(i) Adding new links (between existing nodes);
(ii) Deleting existing links;
(iii) Changing link properties: the (1-way) directionality or its capacity index;
(iv) Splitting links.
18.6.1 Adding Links

New links may be added either by clicking on both an A-node and a B-node or if
the “chain” option is on by clicking on a succession of single nodes, e.g., A, B, C,
…, in which case links A,B, B,C, C,D… are created. To terminate a chain click on
the EXIT button, lower right. (The same effect may be obtained under the first
mode by clicking A, then B, then B again, then C etc - more clicks are needed, but
clearly if the new links are isolated, not part of a chain, then this method is faster.)
The new link may be either created (for plotting purposes) as a straight line or
(post 10.5) as a series of intermediate plotting points in order to introduce
“curvature”. This data is saved within the GIS data (see 5.1.7 and 11.6.9). In the
former case the default distance is simply the crow-fly distance between the A-
and B-node; in the latter it is the sum of the individual sub-section crow-fly
distances.
Once created the new links are assigned appropriate properties. Thus if a link is
created between two existing simulation nodes it becomes a simulation link and
the properties of the nodes at either end are altered accordingly by inserting extra
arms. Equally if the nodes are buffer nodes (as is the default for newly created
nodes) then the link becomes a buffer link.
In either case default link properties are assigned, some of which are purely
arbitrary such as a capacity or speed while others are more “sensible”, for
example measuring the link distance from the node co-ordinates as mentioned
above.
5120257 / Apr 15 18-11

Section 18
The default values may be user-controlled by the use of “capacity indices” where
each capacity index will have its own set of free flow and capacity speeds, a
capacity and a cost-flow power as required to define a buffer link time-flow curve.
New links may be either simulation or buffer, depending on the “status” of the A-
node and B-node. If buffer, an extra record is created in the 33333 data section. If
simulation, both the A-node and the B-node are updated to include the extra arm,
using default link properties. The user is then given the option to immediately edit
the new node codings via standard node editing.
In addition new links may also represent centroid connectors but only in the buffer
network (entered under 33333) or as external simulation node connectors (in
which case only is the data entered under 22222). New centroid connectors to
internal simulation links may only be entered via the simulation update facilities as
described in 18.7.
18.6.2 Deleting Links

To delete a link the user must select the nodes at either end of the link with the
mouse (the order of selection does not matter). The link will then be removed
from the map network (so it will not appear on the screen) and (if exists there)
from the buffer network. If the link is part of the simulation network then the
simulation node definitions at either end are edited such that all references to that
arm are removed, turn data on link records suitably condensed etc. The user will
then be offered the option to further edit those two nodes (e.g. to revise the stage
definitions at signals).
However deleting a link does not necessarily remove all cross references to that
link elsewhere in the .dat files, e.g. to bus routes which use that link or to count
records. Thus some further action on the part of users, either manually editing the
.dat file or via PMAKE, may be necessary. Any such problems should be
detected by running SATNET on the output .dat file.
18.6.3 Changing Link Properties

“Properties” in this context refers to the directionality of links (which is topological)
and their capacity indices (which are pure properties). Thus having selected a link
(A, B) which is currently one-way from A to B it is possible to convert it to either a
2-way link or to change it to 1-way from B to A. Equally its capacity index may be
re-set.
Note that links may always be selected as A then B or B then A whether or not
they are one-way since in the map network from which one is choosing all links
are bi-directional.
18.6.4 Splitting a Link

Splitting a link creates a new node in the centre of an existing link and thereby
creates two extra links in total. More details are given under Adding Nodes,
18.5.1.
5120257 / Apr 15 18-12

Section 18
18.7 Simulation Centroid Connector Editing within PMAKE (11.9.4)

Simulation centroid connectors may be edited in seven ways:
i. Modifying (adding or deleting) those attached to a current simulation zone.
ii. Adding connectors to an existing buffer zone (ie convert to simulation).
iii. Delete all connections to an existing simulation zone (convert to buffer).
iv. Add a new zone plus connections.
v. By replacing an existing centroid connector to a link with a “stub”
connection to a new dummy node created mid-link (see 11.9.4);
vi. By screen editing;
vii. By deleting any “duplicate” zones which have identical centroid connectors
and aggregating them into a single zone (where the remaining zone is the
zone with the lowest number).
Changes made here are reflected purely in the 22222 data records as held on the
internal .dat file which, it will be recalled from 6.5, contains a zone number plus a
number of node pairs. The status of the current record for the selected (/created)
zone is displayed as text at the bottom of the network plot. Certain changes, e.g.,
deletions, are done by selecting a field number in the text.
Note that any changes made to simulation centroid connectors are topological, as
in PMAKE. Thus any changes made here make it impossible to output an
updated .ufs file, only a .dat file.
Note that to change centroid connectors in the buffer network you must use the
“link edit” options described in 18.6. However links to external simulation nodes
may be either handled here or under link edits.
18.8 Capacity Indices on “New” Links

Each new link created by PMAKE is automatically assigned a “capacity index”,
the general function of which is described in 5.1.9, although it may be effectively
excluded by setting a default index of zero. (N.B. Centroid connectors are always,
post 10.5, given an index of 0.)
Specifically within PMAKE the capacity index is used to set default speed-flow
curves for buffer links as explained in 15.9.4. Thus the distances of new buffer
links are calculated as their crow-fly values but the appropriate free-flow and
capacity times/speeds are calculated by standard values set per capacity index.
The parameters, e.g. speeds, per index may, in principle, be user defined within
PMAKE but at the time of writing this has not yet been implemented and a set of
16 standard indices corresponding to standard British DETR conventions have
been supplied as default.
5120257 / Apr 15 18-13

Section 18
18.9 U-Turns at External Simulation Nodes
18.9.1 The Problem

It is not impossible in SATURN for minimum cost routes generated during the
assignment to make U-turns at external simulation nodes which are ALSO part of
the buffer network. For example, in the diagram below where C is an external
simulation node which is also part of the buffer network, the path A-B-C-B-D is
sometimes permitted and might be a way of circumventing a banned (or possibly
rather difficult) turn A-B-D. (Clearly in order for this to happen B-C must also be a
two-way link.)
Similarly the path A-B-C-B-A may also sometimes be permitted.
Figure 18.2 (A) Buffer / Simulation
The reason why U-turns can occur at node C lies in the manner in which external
simulation nodes are “expanded” when they are introduced into the assignment
network. (In a similar fashion to the expansion of internal simulation nodes; see
Figure 5.2). Thus in the above network segment the assignment network
representation at node C is as sketched in Figure 5.2b. Assignment nodes C 1
and C 2 represent the “ends” of the 1-way simulation links; C 3 represents the node
within the buffer network. Links C 1 C 3 and C 3 C 2 are one-way “dummy” links which
allow trips to pass between the assignment and simulation networks. Hence the
mini-path C 1 - C 3 - C 2 is a permitted sequence of nodes in the tree building
algorithms.
(B) The assignment network representation of a combined external
simulation and buffer node
5120257 / Apr 15 18-14

Section 18
The problem is inherent in the SATURN network data structure and the tree
building algorithm used; it could be removed but only by explicitly “expanding” all
turns in the buffer network as well as the simulation.
The problem becomes particularly acute if the external link B-C has been given a
purely notional travel time of, say, 1 second with the “real” travel time on that link
being coded as part of a buffer link.
The assignment tree-build algorithms detect and ban sequences such as C 1 - C 3 -
C 2 above under MOST circumstances but not, for technical reasons, ALL. What
is not that clear is how often such undesired U-turns are likely to occur in practice;
it should not be too often. Certainly it is only possible in networks which combine
simulation and buffer networks and at two-way links between the inner and buffer
networks.
A not-uncommon example of the situation depicted in Fig 18.2(A) occurs if the
local “buffer network” consists only of a zone as explained further in Sections
16.6.3 and 16.6.4.
A secondary problem (although, again, not very common) arising from U-turns is
that they may conceivably affect the convergence of the assignment–simulation
loops if a U-turn is used on one loop but not on the next.
18.9.2 ILOVEU: Allowing U-turns

In order to avoid the potential problem above – or for any other reason – it is
possible (post release 10.4) to disable the assignment mechanism that checks for
U-turns by setting a parameter ILOVEU = F in the network .dat file under
&PARAM (see 6.3.1; default = T).
Our recommendation is to retain the default value of ILOVEU = T so that U-turns
are (effectively) blocked since, at most junctions apart from (some) roundabouts,
U-turns are not possible.
Note that in the original documentation describing ILOVEU the description of what
T and F did was reversed; e.g., it said that the default was F and that it was F that
“banned” U-turns. However the default value has consistently been set to .TRUE.
within the programs so that, unless the user has explicitly set ILOVEU to F in a
network .dat file, the end effect will have been that U-turns have been banned as
recommended.
An output table is included in the .lpt files, listing those nodes where U-turns are
possible, the total flow making U-turns, the total number of “trees” which included
that U-turn (summed over all origins and all internal assignment iterations) and the
last origin for which the problem was detected. If the total flow is zero then the
problem does not occur. It is also possible to display the total U-turn flows per
node in P1X (see 11.8.4.5).
N.B. The number of nodes that can be included in the above table is limited by an
array dimension (reported as Non-Fatal error 253 by SATNET). However,
generally speaking, the missing information is not critical.
The following rules should help to minimize any potential problems arising from
undesired U-turns:
5120257 / Apr 15 18-15

Section 18
1) Try to choose your external simulation nodes such that the links between
them and the simulation network are one-way.
2) Otherwise try to make the links to external simulation nodes as long as
possible.
3) If neither (1) nor (2) is practical try extending the definition of the buffer
network well away from the anticipated trouble spot.
4) Avoid connecting zones to “stub links” via a centroid connector defined under
the 33333 buffer link records as opposed to the 22222 simulation centroid
connectors; see the discussion in 16.6.4.
18.9.3 “Internal” Turns at External Simulation Nodes

Fig. 18.2(B) illustrates the method by which expanded nodes C 1 and C 2 are
created at both ends of a link from a single internal simulation node and the fact
that they are only connected to and from sub-node C 3 which represents the buffer
node. In fact this representation creates a particular problem which was only
corrected with release 11.2.6.
Consider the case where there are two two-way links to an external simulation
node C from two different internal simulation nodes, referred to as A and B.
(Diagram to follow). Let the two expanded nodes at the end of AC be A 1 and A 2
(entry and exit) and similarly B 1 and B 2 at the end of BC. Thus 4 sub-links would
be created: A 1 -C 3 , C 3 -A 2 , B 1 -C 3 and C 3 -B 2 .
However there were no direct links A 1 -B 2 which would represent the turning
movement A-C-B or B 1 -A 2 to represent B-A-C. Normally this would not be a
problem since the movement A 1 -B 2 could take place via two separate links A 1 -C 3
and C 3 -B 2 .
But this does create a potential problem when trying to convert a pattern of origin-
based link flows from a Frank-Wolfe assignment based on multiple independent
O-D routes (UFC) into a single “bush” or UFO structure (see 22.5.3) which is that
it is not possible to accommodate both turns A-C-B and B-A-C within the UFO
structure. However this problem can in fact be resolved by adding the extra direct
“dummy” links A 1 -B 2 and B 1 -A 2 and doing so enables a much closer fit to be
obtained between the original .UFC flows and the converted UFO flows.
It also tends to minimise differences between Frank-Wolfe and OBA assignments.
18.10 Disconnected Assignment Networks

An implicit assumption used in the network assignment algorithms is that all nodes
in the assignment have exit nodes, in effect that there are no “cul-de-sacs”, except
for origin and destination zones. Exceptions to this rule are treated as fatal errors
as far as carrying out an assignment is concerned, although it is possible to
construct networks which are valid for display within P1X and in which there are
cul-de-sacs. Hence it is identified as Semi-Fatal Error 427.
The problem tends to arise at the edges of networks where normally links leading
off into empty space should be connected to zones. In a simulation network such
nodes would generally be coded as externals and the AUTOZ option removes the
5120257 / Apr 15 18-16

Section 18
possibility of their being disconnected by automatically attaching a zone. In a

buffer network cul-de-sacs which are not connected to zones must be corrected
either by deleting the link or adding extra connections.
Less obviously the problem can also occur in a simulation network where a “real”
link into a simulation node has no permitted turning movements. (Recall that an
assignment node is created at the ends of every “real” link). The obvious solution
here is to make the link one-way (by assigning it zero input lanes) or to add at
least one turn.
An even less obvious example occurs when an external simulation node X is
coded between two internal simulation nodes A and B and has no other
connections to zones or buffer nodes as illustrated below.
Figure 18.3 (A) An external between two internal simulation nodes
The “expanded” assignment representation of links (A, X) and (B, X) is:

(B) The expansion of the external node in Figure 18.3a
with no connections between X1, X2 etc; hence X1 and X4 have no exits. Had X
been connected to either a buffer node or zone Z then there would be “dummy”
links as in Figure 5.2b from X1 and X4 to Z.
A “solution” to the above problem is to re-code X as an internal simulation node,
the most obvious candidate being a priority node. In fact this correction is made
automatically within PMAKE under certain circumstances; see 11.9.11.
A more general discussion of network connectivity is given in Section 5.5.4.
5120257 / Apr 15 18-17

Section 18
11.2.05 SATURN v11. Release (Full) DVV JS IW IW 17/03/13
5120257 / Apr 15 18-18

Section 18
Running SATURN Programs Interactively
19. Running SATURN Programs Interactively

19.1 Introduction
This section considers how to run interactive programs, primarily P1X and MX,
using the mouse and/or keyboard once they have been started using, e.g., the
command line approaches outlined in Section 14. The same programs may also
be run in a more batch-like style using KEY files as explained in 14.5.
19.2 Graphics and Text Mode

At the highest level interactive SATURN programs operate under two modes -
graphical and text. Under text mode alpha-numeric text display uses the full
screen (or full window) and user input is from the keyboard. Under graphics the
screen contains a combination of text, graphics, windows, etc and user input is
either from the keyboard and/or the mouse. Clearly text is the traditional mode
while the latest programs are more graphics-based; nonetheless text continues to
exist and has certain advantages.
Programs are not confined to a single mode. SATDB and SATLOOK (traditional
programs) are almost entirely text-based but have some graphics options. P1X is
basically graphical but when it calls SATLOOK or SATDB as options it reverts to
text.
Note that within P1X (only) a graphics window and a text window both exist
concurrently as indicated by two minimised tokens at the bottom of the screen
with titles “Text P1X ...” and “Graphics P1X ...” but at any one time only one has
“focus”. In principle the program knows which of the two should currently be in
focus so that if, say, the program is in text mode then the text token should be in
focus and the program will be expecting keyboard input. Problems may arise if the
program gets it wrong and appears to “hang”, an indication that the user may
need to manually focus on the “other” mode’s token.
In either mode user responses may be divided into the following very general
categories:
♦ choices from a menu;
♦ direct- generally numerical - responses to a direct question; e.g., you are

asked what node number you want and you key in the desired number;
♦ mouse “point and click” input, e.g., on a network plot;
♦ screen edit and/or edit box windows; and
♦ file opening and other standard Windows screens.
19.3 Menus
Menus within SATURN appear in four basic forms:
5120257 / Apr 15 19-1

Section 19
♦ “banners” which appear in conjunction with graphical output, by default as a

12-character wide strip on the right of the screen, with user input via either the
mouse or the keyboard (19.4);
♦ “Menu bars”: menus with pull-down menus which appear along the top of
(some) graphics screen and which supplement choices in the banner. (19.5)
♦ the “text-based” form whereby the menu occupies the entire screen (or
window) and user input is from the keyboard (19.6);
♦ Windows list boxes (see 19.7).

In all cases menu choices may be broadly sub-divided into five categories:
♦ further sub-menus;
♦ executable routines;
♦ numerical variables;
♦ logical variables; and
♦ scrollable variables
Thus a sub-menu choice takes you into a further menu system while an
executable routine initiates a particular “do this next” option (although the
distinction may be somewhat arbitrary as a do-this next routine may well start with
a menu).
Variables come in several forms although all have the basic property of
associating a value with a particular parameter, e.g. origin zone = 67. Thus
numerical variables can take on a wide range of values as with a parameter
associated with zone numbers. By contrast a logical variable can only have two
values, effectively true or false, on or off etc. Finally a scrollable variable is
basically numerical but one that takes on a relatively small number of values, e.g.
a parameter which defines one of three or four allowable options.
If a numerical variable is selected you will next either be prompted for the new
value or, possibly, choose from a list of allowable values. A logical variable
requires no further action, it simply changes or “toggles” to its logical opposite. A
scrollable variable changes to the next value in its list, returning to its “top” value if
the bottom of that list is reached.
19.3.1 Menu Structure

In general menus in SATURN are organized into the hierarchical or tree-like
structure where the top or “master” menu can call a number of different sub-
menus or executables routines. These in turn may call other sub-menus or
routines. We refer to the return to the menu from which the current menu was
called as going “back”. Equally we go “forward” to sub-menus.
In certain cases menus and/or routines may appear to be more “sequential”; e.g. if
you are defining a new simulation node you may first enter a menu to define
banned turns, then one to define lanes etc, etc in a continuing sequence. We
refer to this as going to the “next” menu. However, invisible to the user, each next
5120257 / Apr 15 19-2

Section 19
menu is actually generated by a return from the current menu to its upper level
menu which then automatically calls the next menu in the sequence.
The distinction between the two has implications for the terminology used to
describe “exits” from menus as discussed next.
In addition to the “normal” menu exits of forward, back and next referred to above
it is also possible to “quit” a menu abnormally which effectively terminates the
current operation and goes back one or more levels in the menu structure. In
most situations “quit” has the same effect as “return” or “back”. However when
the normal return operation is to the “next” menu quit aborts that step and
definitely returns you to an upper level.
19.3.2 Terminology: Exit, Return, Continue, Next, Quit, Back, Cancel, etc.
The terminology used to describe the different exit modes may differ between
different parts of the programs and some explanation of the terms used may help.
“Return” is used, mostly in text menus, to indicate either “back” or “next” - the
context of the menu decides which. Somewhat unfortunately, given what comes
next, in graphical banners it is referred to as “Q-return”, the primary reason being
that the letter Q is not very often needed to denote other operations whereas R for
“Return” could conflict with, say, R for “Repeat”. “Q-continue” is also used to
signify continue to the “next” menu.
The abnormal or “quit” exit is also referred to by more than one term or letter -
generally Q for Quit in text menus but also as QUIT when asked to set file names
from the keyboard or “Cancel” when setting them a Windows dialogue box.
Generally speaking abnormal quits are not present within graphical banners.
To exit fully from a program you must successively “return” back up to the master
menu where the quit/return option now signifies exit from the program.
Alternatively, you may exit at any stage by clicking on the exit cross (upper right)
in the current “background” window or by choosing Exit under Files in the menu
bar.
19.4 Banner Menus

In banners the choices are listed in a strip either to the right or above the main
plot. Generally each item occupies a single “slot” of up to 12 characters although
“multiple slots” may be used to improve clarity.
The “form” of each menu item - 1 to 5 in 19.3 - is indicated by a symbol on the
right hand side of the banner with the following convention:
1) Sub-menus: >
2) Executable: x
3) Numerical Variable: ?
4) Logical: a “radio button”
5) Scrollable: s
5120257 / Apr 15 19-3

Section 19
Each item has a single key alphanumeric character associated with it which is
displayed in a different colour (equivalent to underlined characters in a standard
Windows menu).
19.4.1 Keyboard vrs Mouse Control

Selection from a banner menu is based on either “keyboard” or “mouse” control
although mouse control is very much the norm these days. In the latter case –
“point and click” - the selection under the mouse is indicated by reversing the
colour of that item. Under keyboard control type the single highlighted key, either
a letter or a number (but without <enter>, see 19.6 below). For letters either
upper or lower case is acceptable.
Clicking anywhere but on a highlighted line is ignored. Similarly keying in a
character other than those highlighted has no effect. The program only continues
with a legitimate response.
The user may toggle between these two, via either the Systems/device menu,
(11.3.2) or the banner menu (11.15).
19.4.2 Focus
A particular problem encountered within 32-bit Windows SATURN is that under
keyboard control the input from the keyboard is directed to an “invisible” window
which, in effect, only exists as a minimized token on the tool bar at the bottom of
the screen with the title “Key Input”. When this token is “highlighted” or “in focus”
the program is waiting for a keyboard input to the banner menu; when it is not
highlighted it is expecting other forms of input.
Or so it should be. The problem that arises is that when the key input token has
been set in focus by the program the user may accidentally transfer focus
elsewhere by clicking with the mouse somewhere else on the screen. When this
happens the program will “hang” - it wants a keystroke command but the system's
attention is elsewhere.
The solution is simple - click on the “key-Input” token in order to highlight it, hit the
key you want and off you go.
19.5 Menu Bars (P1X only)

These are standard Windows-style bars with pull-down windows which appear at
the top of graphical windows and which contain standard options applicable to
most (or all) banners. For example, requests to dump the current screen image
into a bitmap file (11.3.5) may be accommodated at most times when a choice is
to be made from a banner menu. PCX, BMP, JPL and clipboard output options all
appear under Files. Options which are not currently available for one reason or
another are “greyed out”.
Clicking on an available option - or one from a pull-down menu - from the menu
bar is equivalent to making a choice from the options displayed in the banner;
both sets are equally available (and indeed in some cases the same choice is
available in both). In addition choices may be made from the menu bar even
when an “active” banner does not appear but mouse input is required; for example
5120257 / Apr 15 19-4

Section 19
when using the mouse to select a node or link it is possible to use the menu bar
to, e.g., change the window.
Selection from the menu bar may either use the mouse or via a “hot key”; e.g. files
may be selected by the key combination alt + F.
Note in particular that the menu bar contains a “Back” option which is equivalent
to Q-return in the banner proper and both are generally present. Users may find
“Back” easier to use for going back over several menus, e.g. to return to the
“master menu”, since its position on the screen is fixed.
Alternatively under Back one may also return directly to the Master Menu or to any
of the 13 sub-menus choices normally contained there.
Note that the menu bar is NOT active under keyboard control.
19.6 Text Menus

In text menus the choices appear as text on the screen with each item given a
numerical code 0, 1, 2 ... (plus, occasionally, negative numbers). To make a
choice key in that number followed by <enter>. Note, firstly, there is no mouse
input and, secondly, that unlike banner keyboard inputs the keystroke must be
followed by <enter> (which therefore allows you to correct mistakes).
The “form” of each menu item - 1 to 5 in 19.4 - is indicated by a character on the
far right. Note that the text symbol for a logical variable is ‘L’; the others are as in
banner menus.
An example of a text-menu with sub-menu choices (2 to 6) and executable
choices (0, 1, 2 and 7) is given below.
CHOICE OF OPTIONS FOR NODE 54

0 RETURN X
1 PRINT A FULL NODE DESCRIPTION X
2 CHANGE GLOBAL OR NODE-BASED PARAMETERS >>
3 CHANGE LINK-BASED PARAMETERS >>
4 CHANGE TURN-BASED PARAMETERS >>
5 CHANGE TRAFFIC SIGNAL SETTINGS >>
6 CHANGE THE TYPE OF NODE >>
7 GO TO THE SIMULATION AND ANALYSIS PHASE X
The input value 0 is almost always an acceptable response to a text menu

although it may not always appear explicitly in the menu for reasons of brevity. It
signifies “return” in the sense of “back” or “next” as appropriate and as explained
in 19.3. In text menus the <return> or <enter> key on its own is interpreted as 0,
i.e. return/continue.
In most text menus the single letter input value ‘Q’ is also a valid input which
terminates the current operation and takes you back to a previous menu. Except
5120257 / Apr 15 19-5

Section 19
for continue menus, as explained in 19.3, this has the same effect as RETURN.
In some menus explicit numerical values, generally -1, also allow the user to quit
and have explanations such as “Oops - get me out!” or “Do Nowt”. In certain
cases Q has no effect, probably due to the fact that you have got so far into an
option that it is no longer feasible to retreat; in desperation control-break or
control-alt-delete will probably blow the program!
19.7 Windows List Boxes

List boxes are standard Windows screens in which one item must be selected
from a list by first selecting that item and then clicking on the OK button, at which
point the window is closed. The items in the lists are much as in other SATURN
menus as listed 1 to 5 in 19.3 and generally include the default selection of
return/do nothing/etc.
Note that a selection must be made from the list before the program can continue;
i.e, you cannot minimise a list box and return later nor close it without making a
choice.
“Long” list boxes will have a vertical scroll bar included. Note that occasionally,
and for no obvious reason, the last item in even very short lists is left off the
bottom of the window and can only be seen by moving the scroll bar. To avoid this
problem an option is provided under “Gen Params” in the System/Device menu to
add an extra blank line to all list windows in order to avoid the problem.
19.8 Setting Variables

If a numerical variable is selected from a menu (where its current value is
displayed) the user is prompted for a new value. Under text mode it is input from
the keyboard following the prompt. Under graphics it is either (16-bit) input from
the keyboard and displayed in a “slot” in the banner or (32-bit) input via a “proper”
Windows window. All keyboard inputs are terminated by <enter>; alternatively
click OK in a window.
All variables will have default values associated with them, generally their current
value. A “null” response, i.e. hitting <enter> directly or the OK window button,
returns that value. In 32-bit windows these appear as initial values; in 16-bit the
current values are those in the previous menu.
Equally most variables have upper and lower values associated with them so that
inputting a value outside these limits will either cause the default (input) value to
be retained or, possibly, the nearest limit value to be used. You may even receive
a mild rebuke! In any case you will see the “new” value in the menu.
The input value should be in the same “format mode” as the value displayed; i.e.
an INTEGER value without a decimal place is required for variables displayed
without a decimal. On the other hand the values input for “real” variables should
include the decimal place (although it is not mandatory).
Logical variables do not require any further input; they simply “toggle” to the
opposite sense. In some cases this may be indicated by a change in the text, in
others “on” is replaced by “off”, “Yes” by “No”, etc while in still others T alternates
with F.
5120257 / Apr 15 19-6

Section 19
Equally for a scrollable variable no further input is required; it simply moves to the
next permitted value and the text changes as appropriate.
19.9 Windows Screen Edit and Edit Box Inputs

Certain data input operations within interactive programs use either a standard
Windows-based screen editing or edit box environment.
Thus screen-edit windows display a segment of text which the user may edit using
the keyboard and/or mouse. When you are finished “close” the window to return to
SATURN which then “processes” the text.
Edit boxes allows the values of specific variables (numerical, text, toggles, etc.) to
be altered by the user and returned to the calling routine.
Please note that the data in a screen-edit window is “formatted” and that the
position of different variables within the window is important since the data must
be “read” by the program when the window is closed. Thus if the window is made
up of a set of zone numbers plus trip origins with, say, 3 sets of pairs per line the
program is expecting to find the first three zones in line 1, the second three in line
2 etc. If, during the editing, you introduce extra lines the program may not be able
to interpret the data correctly. You are therefore advised to retain the original line
and column structure when editing (although, generally speaking, shifts of data
entries along the same line may be correctly interpreted). A bit like being told to
write between the lines when you were five years old!
We note that the use of edit boxes and screen editing has certain implications for
LOG and KEY files as explained in Section 14.5.9.
19.10 Output Text Windows

Windows containing text are created at certain points within interactive programs
for a variety of purposes. For example they may:
1) List short messages,
2) Give more substantial text outputs,
3) Provide a more complete explanation of entries in the banner menu.
Thus type 1 for example is used to print error and warning messages which will be
deleted by the program automatically when you continue with the next step. Type
2 may be used to give a complete listing of the current properties of a node in
node graphics; in this case the window is preserved until deleted by the user.
Type 3 windows are automatically deleted when the banner is updated.
These windows differ from those in Section 19.9 above in that they are for display
only, they cannot be edited in order to return data to the program.
These windows may differ in terms of whether they have scroll bars, whether they
have colour, how they are deleted etc. In most cases it should be possible to
“grab” text from the windows using standard cut and paste techniques.
5120257 / Apr 15 19-7

Section 19
19.11 The Help Facility

With all menus it is possible to obtain further information concerning the general
form of the menu and/or the choices available by entering the “help mode”. To
enter the help mode simply type ‘H’ in response to a text menu or click on ‘Help’ in
the banner or menu bar.
Essentially the help mode is a form of on-line editing system whereby the program
reads from a pre-prepared “.HLP” file at the relevant spot for the particular menu
from which it is called. The user is then able to “browse” through the help file by
commands which move the screen up or down in the file, e.g. with the cursor
keys. Exit to the original program is as indicated on the screen.
A special feature of all Help files is that a general program description is contained
at the very top of the file - this can be accessed by hitting the <home> key so that
the “screen” will be shifted to the top of the help file no matter where you are
currently positioned.
Unfortunately not all menus have a corresponding pointer into a help file; thus
sometimes a request to enter help will only get you a slightly rude message -
better luck next time!
A further use of the Help files is to obtain help on the output from an interactive
program AFTER the output has been produced - as opposed to obtaining it
beforehand whilst viewing the menu. The help in this case describes the
interpretation of the previous output.
Since .hlp files are ascii or “text” files it is quite feasible for users to edit them so
as to add their own site-specific information. However it must be noted that, from
version 9.2 onwards, .hlp files are stored as “direct access” files, which basically
mean that all lines must be the same length. Standard edit programs may well
truncate short added lines such that the edited version is no longer valid under
direct access. If this happens, use the MAKEDA77 facility supplied as part of
DBOS to recreate the direct access format.
19.12 Mouse-based Inputs

Mouse based inputs perform an important range of functions in P1X, e.g. to make
selections from the banner or to “point and click” to a node. Input is relatively
simple; only the left hand button is used and functions are designed to be self-
explanatory.
“Point and click” operations, e.g. to select a node from a network plot, are
generally accompanied by a set of “buttons” within the banner which allow one to
exit from that particular operation or to select further operations, e.g. redefine the
window. To select a button, point to it (it will reverse colour) and left click.
In certain situations you need only click the mouse, its position is irrelevant; for
example this may be used in a Joy Ride to advance from one node to the next. In
keyboard entry terms this is equivalent to “strike any key”.
5120257 / Apr 15 19-8

Section 19
5120257 / Apr 15 19-9

Section 19
Modelling Road User Charges in SATURN
20. Modelling Road User Charges in SATURN

20.1 Introduction
Increasingly these days motorists are being asked to pay directly to drive along
specific routes or to specific locations and the location and scale of these charges
are planning issues. This section describes how such charges - or “tolls” as we
prefer to call them - may be modelled within SATURN, with particular reference to
new facilities introduced in SATURN 10.3.
Tolls arise in a number of different contexts, for example, fixed tolls to cross a
bridge or to use a section of motorway, tolls levied to enter a particular area of a
city (whether collected directly at a toll point or indirectly via electronic methods) or
entry-to-exit motorway tolls. Other less obvious examples include parking
charges.
One common feature of most tolling systems is that their impact is differential
across the population of all drivers. For example tolls may differ between cars and
trucks, parking charges will differ between short-stay and long-stay, etc. etc. In
addition the “perceived” cost of a toll may depend critically on who is paying it.
Thus most studies of charges in SATURN are carried out in the context of
“multiple user classes” (see 7.3)
20.2 The Role of Tolls in SATURN Modelling

Tolls are defined as a (monetary) charge per “link” (where link in this context
includes simulation turns, centroid connectors, etc. as well as buffer/simulation
roads) per user class so that, in the context of a route over a succession of links,
they are additive. Thus we preclude the possibility of directly modelling non-
additive tolls, i.e., the situation which commonly arises with entry-to-exit tolls on
motorways whereby the toll from A to C is different from the sum of the toll from A
to B plus B to C. Note as well that tolls cannot be defined by node either so that
parking charges (which might most naturally be associated with a node/car park)
must be associated with links entering that node.
Once defined the way in which tolls affect choices within SATURN is relatively
straightforward: they are simply one extra component in the definition of
generalised cost; see 7.11.1 and 7.11.2. As such they influence route choice
within the assignment as well as the minimum o-d costs used within elastic or
variable demand assignment.
Thus, within SATURN demand models proper, there are no direct facilities for
“multiple criteria” modelling. For example it is not possible to define a demand
function in SATALL/SATEASY which is a function of time, distance and monetary
tolls separately, they are all subsumed within generalised cost. It would, of course,
be feasible for users to define such complex demand functions themselves using
the facilities within MX since it is quite possible to skim distinct matrices of time,
distance and tolls from an assignment (although there may be certain conceptual
problems of their uniqueness).
The “trick” therefore in modelling charges in SATURN is how to correctly interpret
the monetary tolls as components of generalised costs.
5120257 / Apr 15 20-1

Section 20
We note that tolls have always, pre 10.3, been capable of being modelled within
SATURN simply by including them as, e.g., extra time “penalties” or extra KNOBS
components. What is different in 10.3 is that the tolls are now explicitly identified
as monetary tolls and appropriate aggregate statistics are included in appropriate
monetary units. Previous statistics did not differentiate between, say, link
penalties which were “notional”, e.g., associated with using a non-signposted rat
run, or “real” as with tolls.
20.3 Input of Charges (Tolls) in SATURN

Tolls may be set within SATURN via network .dat files using either:
♦ the 44444 records, or
♦ the KNOBS facilities.

Both have their advantages and disadvantages and, for a wide range of
circumstances, either may be used. For a small number of toll points with charges
that are unlikely to vary the 44444 records are probably simplest, whereas
KNOBS may be preferable for a large number toll points where the user wishes to
optimize the tolls externally.
Further advantages of using an external file are that: (a) the tolls may be defined
with decimal points whereas under 44444 they may only be integer tolls; (b) file
input may be applied to centroid connectors and, in particular, (c) by using the
“wildcard” option (15.14.5) tolls may be easily set for all exit or all entry centroid
connectors to/from a zone without having to explicitly identify centroid connectors.
Under (b), and as described in Section 15.14.3, KNOBS may be input in three
different ways: two within the 33333 buffer records or one as an external data
(text) file defined by FILKNB. Given that tolls are a new feature in Version 10.3
and that users will probably not wish to change existing .dat files more than
necessary it is most likely that tolls defined as KNOBS will be input as a separate
file and the documentation below reflects this. An example of such a file follows
* ARTIFICIAL KNOBS DATA FOR LIVERPOOL NETWORKS

22 26 4 0.0
75 37 4 3.0
20 21 14 1.0
24 26 1 4 0.0
18 19 0 6.0
C 4 61 8 8.1
62C 5 9 9.9
99999
Note that this file contains two knob data fields (the columns headed by 4 and by
3.0), either or both of which may be used to define tolls; how this is done is
described below. In addition tolls are applied both to links (73-37 etc.), turns (24-
26-1) and centroid connectors (the zone being indicated by the letter C).
Both inputs use the convention that tolls are indicated by either the £ or $ symbol
although in slightly different locations. Thus within the 44444 records the toll is
5120257 / Apr 15 20-2

Section 20
entered within the appropriate user class columns of a particular link record as,
say, “ £50” or “ $50” to indicate (somewhat perversely - see below) a toll of 50
pence. Hence each and every toll has to include the £/$ symbol. An example is
given below:
44444
22 21 $ 25
21 22 $ 50
7 63 $ 50
32 33 $ 50
99999
Here a toll of 50 “pence” is to be levied on 3 links and 25 “pence” on a fourth.

On the other hand for KNOBS input the £/$ is entered not with each individual link
toll record but in the definition of the generalised costs in the 88888 records, i.e.,
once per user class; see 6.11.
KNOBS input contains one further feature not available through 44444 data which
is that the generalised cost definition under 88888 may also contain a “weight” or
“factor”. Thus if one wished to set a toll on a particular link that was £1.00 for user
class 1 and £2.00 for user class 2 then the 44444 record for that link would
include both “£100” and “£200” entries to define both tolls separately. Using
KNOBS one could define a single data entry of 100.0 for that link in the external
file with generalised cost weights defined as “£1.0” and “£2.0” within the 88888
records. The latter is clearly much simpler if one wishes to experiment with a
range of standard tolls it can be done by setting all KNOBS entries to a single
value such as 100 and then defining the actual toll via a single factor on the 88888
record.
An example of an 88888 data set which specifies the toll definitions for the KNOB
file illustrated above is as follows:
88888
1 1 $10.0
99999
The position of the entry $10.0 (columns 31 to 35 in the original) indicates that it
applies to the second knob data field and that all entries in that field are: (a) to be
interpreted as monetary and (b) multiplied by 10.0. Hence link 75 to 37 above will
have a charge of 10x3.0 = 30 “pence” levied against it, link 22 to 26 has no toll
since its second field is 0.0 (the first knob field is presumably used for some other
purpose), etc, etc.
(We note that the weighting factor above should, see 6.11, be input as a “real”
value, i.e., with a decimal place, but that, post 10.6, an integer input will be read
as an integer. Thus $10 would be interpreted as 10.0, not 0.10)
The other clear advantage of defining tolls within a separate KNOBS file rather
than within the .dat file itself is that it will be much simpler for users to re-define
tolls or to interface SATURN with other programs which, for example, are setting
optimum tolls.
5120257 / Apr 15 20-3

Section 20
20.3.1 Units of Charges

It is assumed that monetary tolls are always defined within the context of a system
such as pounds/pence, dollars/cents, euros/cents etc.; i.e., 100 smaller units
equal one of the larger. We have further assumed that it will be more convenient
for users to think in terms of individual charges being integer numbers of pence,
say, rather than fractions of pounds - 50p rather than £0.50 - but that in terms of
reporting total revenue collected through tolls they would prefer £2567.50 to be
output rather than 256750p.
This means that individual tolls are always input in units of pence/cents etc. but
that aggregate output statistics are always reported in pounds/dollars/euros/etc.
The “names” of the units may be user-set via the namelist parameters CURNCY
and COINS under &PARAM in network .dat files - defaults are “pounds” and
“pence” respectively.
The one unfortunate aspect of these conventions are that the £ or $ symbols are
used to indicate whenever monetary units are being used as inputs but the inputs
themselves will not be in pounds or dollars but in pence and cents. You get used
to it! The reason for this (as well as the absence of a euro symbol) is simply that
the $ and £ symbols are much more common on keyboards than any other
monetary symbols.
20.3.2 From Tolls into (Generalised) Times

As explained in 7.11.1 all cost components in SATURN, including tolls, must be
converted into “generalized time” (aka generalised cost) prior to assignment.
Thus – see equation (7.43) – monetary costs (i.e., tolls) must be divided by PPM
to convert them into time units.
The assumption, therefore, is that the tolls (whether defined via 44444 or KNOBS)
are in units of pence – or equivalent – and that PPM is equally “correctly” defined
in units of pence per minute. This is important since, not infrequently, PPM and
PPK are only defined in relative terms since, if only time and distance contribute
to generalized cost, it is only their ratio that matters. Thus “typical” relative values
might be PPM = 1.0 and PPK = 0.7 (which would have the same effect as 10.0
and 7.0). However the effect of tolls would be 10 times smaller if PPM = 10.0
rather than 1.0.
We should also note that, purely internally to the program and of no direct concern
to the user, an additional factor of 60.0 is applied to convert between minutes and
seconds since internally cost/time is in units of seconds.
Thus, the equation which converts a KNOBS entry into an assignment generalised
time in seconds is:
C= K ∗V 8k / ( PPM / 60.0 )
where K is the value of the KNOBS entry, V8k is its multiplier in the 88888 data
records (where it would be preceded by $ or £) and PPM is pence per minute. If
there were more than one KNOBS entry then C would be summed over all entries
and, with multiple user classes, the values of V8k and PPM would be user-class
specific.
5120257 / Apr 15 20-4

Section 20
20.4 Calculating and Reporting Charge/Toll Statistics
20.4.1 Calculating Vehicle Tolls

We may note that tolls are assumed to be levied per vehicle rather than per pcu
so that assigned flows, which are normally calculated as pcu’s per hour, must first
be converted into flows of vehicles per hour by making use of the conversion
parameters VCPCU. (But if, as by default, the conversion factors are all 1.0 then
they have no effect.)
Note that the pcu conversion factors must be applied indirectly via vehicle classes,
not directly per user class. For example, if heavy lorries have been defined as
user class 2 and user class 2 has been allocated to vehicle class 2 (see 6.11 and
5.8) and VCPCU(2) = 3.0 (see 6.3.3) then an assigned UC 2 flow of 300 pcu/hr
(i.e., 100 vph) on a link with a toll of 100 pence would generate tolls at a rate of
10,000 pence per hour.
Note as well that tolls are not levied on buses or on any other elements of fixed
flows.
20.4.2 Reporting Tolls

The total revenues generated by financial charges (independent of how they are
defined and levied) are included in standard output tables of combined simulation
and buffer total statistics as described in 17.9. A “sample” section of such a table
including toll data is shown below.
ABSOLUTE TOTALS THIS TIME NEXT TIME TOTAL (Units)
PERIOD PERIOD
PENALTY TIMES (S) 1.3 0.0 1.3 PCU/HRS
PENALTY TIMES (B) 1.6 0.0 1.6 PCU/HRS
PENALTY TIMES (BCC) 0.0 0.0 0.0 PCU/HRS
PENATLY TIMES (TOTAL) 2.9 0.0 2.9 PCU/HRS
TOLL CHARGES (S) 283.4 66.0 349.0 EUROS

TOLLCHARGES (B) 479.9 0.0 479.9 EUROS
TOLL CHARGES (BCC) 626.7 0.0 626.7 EUROS
TOLL CHARGES (TOTAL) 1390.0 66.0 1455.6 EUROS
Note: SIMULATION (S), BUFFER (B) AND BUFFER CENTROID CONNECTORS (BCC)
Thus we note that in this example that of the total 1,456 euros generated by
vehicles passing through various toll points 349.4 were from tolls on simulation
links, 479.9 from tolls on buffer links and 626.7 on buffer centroid connectors. In
addition the simulation totals may be further disaggregated into tolls generated
during the time period simulated and through queued trips which would pass the
actual toll points in a later time period. (The units of “euros” will have been defined
by the Namelist parameter CURNCY.)
5120257 / Apr 15 20-5

Section 20
Although not strictly relevant here the total pcu-hrs on (time) penalized links are
also shown above to emphasize the point that monetary tolls are distinguished
from the (possibly nominal) time penalties.
A .ufm matrix of tolls may be obtained using the standard batch file SKIMTOLL as
20.5 Examples of Charging Systems in SATURN
20.5.1 Distance-based Charges

Distance-based charges, i.e., a system whereby drivers pay a toll per link
proportional to the distance travelled on that link, may be modelled very simply if
all links in the network are to be tolled at the same rate simply by setting an
appropriate value of PPK (Pence Per Kilometre). However, that would fail to
distinguish between the toll element of distance and any other perceived and/or
real distance costs and moreover there would be no summary output tables of
total revenue generated.
A more general method, which also overcomes the latter problems above, is to
make use of the KNOBS facility. Thus (assuming that a “KNOBS file” is to be
used), the user would need to set up a data file consisting of link A-node and B-
node for those links where charges are to be levied plus either (preferably) the
distance or the toll itself.
If the KNOB field contains distance the user would have to define a pence per unit
distance multiplier within the 88888 record(s) (e.g., the $10.0 in the example given
in 20.3). Note that, if there were multiple user classes, a different rate of toll could
be set by user class.
Alternatively, if the KNOB field contains the toll (in pence) directly, the multiplier in
the 88888 record(s) would simply be $1.0 to indicate that the data field is indeed
in pence. A disadvantage of this method is that, with multiple user classes and
multiple tolls, a separate KNOBS data item would need to be included for each
user class. If tolls are indeed levied as a rate per distance then using distance as
the input is much more natural.
If different toll rates were to be set for, say, n different areas (i.e., for different sets
of links) then the KNOBS file would need to contain n separate distance fields for
each such area. Thus KNOB field 1 would contain the link distances for charge
area 1 (with zeros for all other links), KNOB field 2 would contain the distances for
links in charge area 2 (only), etc. etc. Equally the 88888 records would need to
contain n different multipliers by area.
20.5.2 Cordon-based Charging

The system of charging whereby every vehicle entering a closed cordon pays a
fixed charge (possibly user-class dependent) is now widely known following its
implementation in central London.
20.5.3 Parking Charges

Although not strictly tolls in the conventional sense parking charges may be
modelled within SATURN in very much the same way as other forms of tolls.
5120257 / Apr 15 20-6

Section 20
We may first note that car parks in SATURN may either be represented either as:
♦ zones whereby all traffic in the trip matrix to or from a zone is assumed to be
to or from the equivalent car park, or
♦ as nodes which are not themselves zones but are connected to zones via a
further series of links which represent walk links (See 15.46).
The simplest method to apply parking charges is to ensure that every entry point
to a car park (whether zone or node) goes through a link (not a centroid
connector) whose exit leads to a car park and that an appropriate “toll” (equals
parking charge) is levied on that link.
Note that the entry links to car parks may be assigned speed-flow curves with
capacities appropriate to the capacity of the car park. If there are multiple en
tries/links to the car park then it may be best to “channel” them all into a single
entry link where the capacity is applied, otherwise with multiple entry capacities
the total capacity may be over-estimated.
20.6 STOLL: Modelling Stochastic Values of Times of Tolls

A new option was introduced in SATURN 10.6 which enabled the way that
different drivers perceive the “value” of a fixed toll in different ways to be
modelled. Thus a toll charge of £5 may appear to be an impossible impediment to
travel to a penurious student but to a company director it may seem like nothing.
Such differences may be thought of in terms of either the “time value” of a fixed
toll or equally the “money value” of time, e.g., minutes per pence or pence per
minute, since SATURN needs to convert all elements of times, tolls, distances etc.
into common units of “cost”. In SATURN this is generally done by converting
everything into generalised time units so that toll charges may either be multiplied
by “minutes per pence” or divided by “pence per minute”. The latter approach is
intuitively preferable and hence, in modelling terms, we need to consider how the
variable PPM varies across the population of drivers.
One method by which variations in PPM may be modelled is by defining a series
of user classes, each of which is assigned a particular value of PPM via the 88888
data records. This is also a “natural” method for modelling different toll charges
for, say, different vehicle types (cars v lorries, etc.). However if one wishes to
distinguish a large number of sub-classes by PPM the total number of user
classes may grow rapidly with consequent increases in cpu time, file sizes, etc.
etc.
An alternative method is to follow an approach known as TRIBUT, proposed by
Fabien Laurent in 199x, which explicitly represents the variability in PPM by
introducing an explicit distribution of (in effect) PPM. The method is not dissimilar
to Burrell stochastic assignment and, in SATURN, is modelled as a sub-option
within SUZIE = T.
There are two key features of TRIBUT which distinguish it from normal SUE:
5120257 / Apr 15 20-7

Section 20
1) Rather than randomising the perceived cost on each link, a single perceived
VOT (i.e., PPM) is generated once per origin;
2) The randomised VOT is applied only to those links with tolls and only to their
toll component.
Thus all steps in the algorithm described in Section 7.2.2 are retained except that
the randomisation of costs in step 2(a) proceeds as above.
Thus, whatever VOT/PPM is generated per origin, that value is applied to all tolls.
With standard SUE it is possible that a randomisation of all link costs may imply
that, in effect, a driver applies a high value of time to one toll but a low value to
another. Logically a single driver should perceive all monetary tolls in the same
light.
To use the above method in SATURN the user must set both SUZIE and (a new
variable) STOLL (for StochasticTOLLs) to T under Namelist &PARAM. In addition
a choice of randomisation method must be made through the choice of KOB; see
Section 7.2.3 for further details.
The use of cumulative density functions (CDF) (KOB = 3) to describe the
distribution of VOT/PPM was specially introduced to be used with STOLL, in
particular to deal with asymmetric or skewed distributions of VOT. See 7.2.3.2 for
further details. (Note in particular that the CDF represents the distribution of a
unitless multiplier which is used as per equation (20.2) below to create
randomised perceived tolls.)
Thus the equation by which a monetary toll M (in units of pence) is converted into
an equivalent generalised time penalty T (in seconds) is given by:
T = 60.0 * M / (PPM x R) (20.2)
where R is the PPM multiplier randomly selected from the CDF (whose “central”
values should therefore be around 1.0).
We therefore note that, within the STOLL algorithm, the random multipliers
selected from a distribution are actually used to convert tolls into time units, not
the other way around. Hence the distribution of perceived tolls is really the
inverse of the VOT distribution which the user inputs, Generally speaking, a value
of time distribution will be positively skewed towards higher values. Users
therefore need to be careful that they define a CDF with the correct skewness. For
example the .cdf file (see 7.2.3.2) might look something like:
0.5
1.0
1.5
2.5
5.0
in order to generate a preponderance of high effective values of PPM. Note that in

this case the mean value of PPM will therefore be greater than 1.0.
5120257 / Apr 15 20-8

Section 20
5120257 / Apr 15 20-9

Section 20
Alternative Network Data Structures and Assignment Methods: Origin Based

Assignment (OBA) and Path Based Assignment
21. Alternative Network Data Structures and

Assignment Methods: Origin Based (OBA) and
Path Based Assignment
21.1 Network Data Structures
Traditionally SATURN has always stored network data required for the
assignment in arrays based on network links, e.g., V a . This is not to say that the
algorithms used such as Frank-Wolfe (7.1.2) only consider link-based data. For
example, Frank-Wolfe explicitly calculates and loads minimum cost paths (step (3)
in 7.1.2) in order to generate new sets of link flows; it does not, however, actually
store path flows explicitly since, for computational reasons, they are not required.
It is, however, possible to formulate alternative data structures in which additional
data is stored at a higher level of “disaggregation”. Thus we may store either:
(i) link-based data (as above),
(ii) path-based data,
(iii) origin-based data.
Thus under ii) we explicitly store information on every path generated plus its
assigned flow T pij in addition to link-based data such as V a .
Origin-based data (BarGera, “Origin-based algorithm for the traffic assignment
problem”, Transportation Science 36(4), 398-417, 2002) is, in a certain sense,
intermediate between link-based and path-based in that it stores the link flows as
generated by each individual origin:
Equation 21.1
Vai = ∑ Tij Pija

i
where P ija is the proportion of the trips T ij from origin i to destination j which use
link a.
Neither path- nor origin-based methods preclude link-based data: indeed link
flows may always be obtained by suitable summations of either path or origin
flows. The extra information stored may often be usefully applied to improve our
understanding of the solutions generated.
However, the main advantage of the alternative data structures is that they allow
fundamentally different assignment algorithms to be constructed which, as we
shall see below, have been shown empirically to be superior to link-based Frank-
Wolfe in a number of respects (although they also have disadvantages as
discussed below).
5120257 / Apr 15 21-1

Section 21

21.1.1 Path-based Assignment

Path-based methods were investigated by Kupiszewska and Van Vliet at the
University of Leeds under EPSRC grants from 1998 to 1999 and made fully
operational within SATURN 10.4 (although documentation was only added later).
Various papers which describe both theory and empirical results are included in
Appendix H.
Parameters which specifically control the choice and application of path-based
assignment are described in 21.7.1; in brief, set MET = 1 under &PARAM.
21.1.2 Origin-based Assignment (OBA)

Origin-based assignment (OBA) was developed by Hillel BarGera, a PhD student
working with Professor Dave Boyce at the University of Illinois at Chicago in the
late 1990’s. His work revolutionised traffic assignment in that his methods solve
for Wardrop Equilibrium solutions to an accuracy limited only by the numerical
accuracy of the computer and within comparable cpu times to existing algorithms
such as Frank-Wolfe.
OBA first became available in SATURN 10.5 through a collaboration with Hillel
BarGera and the University of Chicago but with additional licensing requirements.
(OBA was subsequently “bundled” into the main programs with the release of 10.9
and therefore is now generally available).
Further theoretical and programming work was undertaken by Dr Yanling Xiang
(Atkins) to extend the OBA algorithm to handle multiple-user class (MUC)
assignments. SATURN OBA (MUC) was previously available in Beta form as part
of SATURN v10.8 and was fully released with SATURN v10.9.
Background papers on OBA are included in Appendix G while further properties of
OBA are described in the following sub-sections and in Section 22.5.2 (splitting
factors).
Parameters which specifically control the choice and application of OBA are
described in 21.7.1; in brief, set MET = 2 under &PARAM.
21.2 Advantages and Disadvantages of OBA and Paths

The main advantage, certainly of origin-based assignment, is that it provides
(virtually) exact solutions to Wardrop Equilibrium Assignment without requiring
either excessive RAM or excessive cpu. In other words, it enables the
assignments to converge perfectly (delta values approaching zero) as well as
(unless there are problems within the simulation) the simulation-assignment loops
to converge perfectly as well (Gap values approaching zero). It represents a major
break through in both theory and practice.
One particular application where exact solutions are essential is the perennial
problem of comparing a “do-nothing” network with a “do-something” network
where the “scheme” (i.e., the changes) is relatively small and its effects are liable
to be lost within the “noise” of two approximate solutions. OBA assignment is
capable of accurately assessing even very minor schemes such as the redesign
5120257 / Apr 15 21-2

Section 21

of a single junction or the generation of extra traffic from a small development.

See 21.8 for some examples.
A further potentially very useful application of OBA is in the area of “warm starts”
or “perturbations” where the solution to one network makes use of information
from a previous network. Warm starts can considerably reduce cpu time and, for
technical reasons, are less easily available with Frank-Wolfe. See 21.3 below and
22.5.1.
In addition all (or almost all) standard post-assignment analyses such as trees,
forests, select link analyses etc. are also available with OBA with the added
advantage that the solutions being analysed are exact, not approximations to
previous solutions. In addition the various problems created by “residual path
flows” under Frank-Wolfe (15.57) are virtually non-existent under OBA and very
much less common under path-based algorithms (where social-pressure based
algorithms, see Appendix H, preferentially remove residual flows).
Path-based assignments, on the other hand, may significantly improve the
accuracy of an individual assignment but without, however, achieving the same
ultimate convergence as OBA. Nevertheless there are much more significant
improvements in carrying out perturbation assignment with path-based methods.
See 21.3 below.
Disadvantages, certainly for OBA, are due to limitations in the computer code
rather than to absolute theoretical restrictions. Whilst the previous limitation to
single-user class applications was overcome with the full release of the multiple-
user class version as part of SATURN v10.9 in September 2009, OBA cannot be
currently used for elastic assignment (and it is unlikely to be extended in the near
future).
The major practical problem with path-based assignment is the heavy requirement
for computer memory (RAM) to store the individual path information. This sets an
upper limit on the size of network that can be handled although as the available
RAM within computers increases through technological developments the upper
limits will increase correspondingly.
21.3 Perturbation Assignment (WSTART and/or IPERT)

We define a “perturbation assignment” as one which starts from a good initial
estimate of the final equilibrium flows and/or paths as opposed to, for example,
the Frank-Wolfe algorithm which (generally) starts from an initial all-or-nothing
assignment based on free-flow costs. (The UPDATE and RESTART options
within SATURN (see 15.3 and 15.4) may be thought of as “partial” perturbation
methods in that they start with improved cost-flow curves but they do not take
advantage of any initial o-d path information.)
Thus a perturbation assignment, whether it be link-, path- or origin-based, takes
as its initial assignment a solution which uses, as far as possible, the flows from a
previous assignment. The “new” assignment problem may differ from the “old” in
terms of changes to either: (i) the network topology (changes to the nodes and/or
links), (ii) network properties (e.g., changes to link costs) or (iii) the trip matrix - or
a combination of all three. By starting with a solution that is very much nearer to
the final solution than, say, a all-or-nothing solution very often leads to a
5120257 / Apr 15 21-3

Section 21

considerable decrease in the cpu time required to generate a well-converged

solution.
To request perturbation assignment either set WSTART = T under &OPTION in
the network .dat file or, optionally, set a parameter IPERT = 1 in &PARAM; both
have the same effect although the use of WSTART is much simpler (and will set
the appropriate value of IPERT automatically) and is strongly recommended. The
name of the file from which the warm start data is to be extracted is specified by
the &OPTION parameter UPFIL.
There are, however, certain restrictions in that an OBA perturbation is only
possible if both the “old” and “new” networks have an identical network structure in
terms of nodes and links; path-based perturbations can “translate” non-identical
network structures.
21.3.1 Link-based Perturbation Assignments

Unfortunately it is not generally possible to carry out a perturbation assignment
using only link-based flow information (i.e., the traditional SATURN assignment
methods with MET = 0) since it is difficult to ensure that the perturbed assignment
is “feasible”.
Basically “feasibility” requires that an assignment assigns all the trips in the trip
matrix and does not have negative path flows. The former condition is relatively
simple to satisfy but the latter is more complicated. If, for example, we wish to re-
assign a trip matrix in which the number of trips from one O-D pair has been
reduced, say from 10 to 8, then, if we know all the previously used paths and path
flows, we can simply remove a total of 2 trips from one or more existing paths (the
most obvious method being to reduce all path flows by 20%). Equally if an O-D
pair goes from 10 to 12 trips then we could either increase all existing path flows
by 20% or, say, add 2 trips to the current minimum cost route.
If we only have link flows but no direct information on path flows we can certainly
deal with an increase in O-D flows by using the option of assigning the extra trips
to minimum cost paths which can then be aggregated into a set of incremental link
flows. However, if the O-D flow is decreased, then there is a danger that if we
remove the trips from a single path we may be creating a solution with negative
path flows (even if all the aggregate link flows remain non-negative). Such a
situation is extremely difficult to detect (or, to put it another way, it may take longer
to detect the problem than to carry out the new assignment from scratch).
There is one, not infrequent, situation where a link-based assignment may be
easily “perturbed” and that is the case where each O-D cell in trip matrix is
uniformly factored, in which case factoring all link flows by the same factor
guarantees a feasible solution.
21.3.2 Path-based Perturbation Assignments

On the other hand problems of feasibility are much easier to deal with under path-
based assignments. If there has been no change in the network structure between
the “old” and “new” networks then all path flows are simply factored by the ratio of
new to old O-D trips.
5120257 / Apr 15 21-4

Section 21

If, on the other hand, there have been structural changes then some “old” paths
may not exist in the “new” network. In this case the new flows are either divided in
proportion between those O-D paths which are still valid or, if none are valid, a
new path corresponding to the minimum cost is created and assigned 100% of the
O-D flow.
21.3.3 OBA-based Perturbation Assignments

Perturbation under OBA is broadly similar to that under path-based but, as of yet,
no provision has been made for structural changes to the network. Thus, if there
are no structural changes, node splitting proportions by origin are simply carried
forward to provide an initial feasible solution.
21.3.4 Advantages of Perturbation Assignments

Perturbation assignments may be extremely “powerful” techniques in that they can
produce extremely accurate solutions relatively quickly. We refer to the papers in
Appendix H for further details and numerical examples. (N.B. These papers are
based on path-based methods as opposed to OBA but, in principle, the same
methods can be used with OBA.)
21.4 Storing O-D Path Files: UFO and UFQ

Since both path-based and origin-based assignment handle paths in different
ways from link-based they also have their own particular file structures for saving
path information. Thus, whereas link-based assignment stores the costs used at
every iteration in .UFC files in order to re-create paths (see 15.23.1), path-based
methods store all paths used explicitly in .UFQ files while OBA uses “splitting
factors” at each node to describe O-D route choice and uses .UFO files (plus .ost
files – see 21.6 below) to store that data. The precise structure of these files need
not concern the casual user – just don’t delete them!
But if you do want to know more about splitting factors and .UFO files please, at
least, see Section 22.5.2.
N.B. In order for either .UFQ or .UFO files to be explicitly created by SATALL the
Namelist parameter SAVEIT must have been set to TRUE in the network .dat file
(in the same way that a .UFC file is only stored under Frank-Wolfe when SAVEIT
= T). We note that it is also possible to create .UFO files under Frank-Wolfe (MET
= 0) as described in Section 22.5.3.
In principle this means that all the usual facilities within SATURN for analysing
paths post assignment such as select link assignment, o-d forests etc., may also
be invoked using path- and/or origin-based assignments, the only difference being
that the essential data is read from a file with a different extension. (See below for
minor exceptions to the rule.)
A further advantage to both path and OBA assignments is that any post-
assignment path analysis is identical to that used by the assignment, as opposed
to link-based methods where path analysis may be based on an approximation
(15.23.2). Thus time and distance o-d skimmed matrices as used for evaluation
purposes are exact, not approximate, so that the effect of any “noise” in the
5120257 / Apr 15 21-5

Section 21

solutions is further minimised. In addition (see 22.5.6) skimming a forest is much

faster in terms of cpu time under OBA than under Frank-Wolfe.
21.5 Practical Restrictions within SATURN

Both methods have various restrictions, although these are more of a temporary
and practical nature rather than theoretical restrictions. Thus path assignment will
only work for a single user class while OBA (post 10.9) allows multiple user
classes. In addition OBA will also only work for a fixed trip matrix whereas path-
based allows elastic demand models.
In addition, while virtually all “SAVEIT-based” analysis options described in 15.23
have been extended to use .UFP or .UFO files instead of .UFC., a few have not.
Thus OBA assignment cannot be used to generate cordoned matrices within P1X
(although they do work within SATCH) nor does it work with SATPIG.
However, post 11.1, it is now possible to create a Frank-Wolfe equivalent .UFC
file from an .OBA solution using the procedure SATUFC described in 15.23.5 such
that programs such as SATPIG etc. may be applied indirectly to OBA solutions.
21.6 Additional OBA Output Files

In addition to the .ufo file as mentioned above SATALL running under OBA
produces a number of other files whose primary function is diagnostic and which
normally need not be consulted by “non-expert” users. Thus, if the normal network
files produced by SATALL are net.ufs etc., then there are also:
Net.otb – summary table of OBA convergence measure in Tab delimited text
format. Each line represents one iteration, either main or inner iteration. The most
important columns are:
♦ Main iteration index
♦ Inner iteration index
♦ Clock – CPU time in seconds
♦ Objective function - the classical one (Beckmann et al., 1956)
♦ Real Gap – between objective function and lower bound
♦ Average Excess Cost* – weighted by route flow
♦ Maximum Excess Cost* – over all routes included in restricting subnetworks
♦ Average cost – from origin to destination weighted by route flow

* Excess Cost is the difference between the cost of the route and the minimum
cost for the same OD pair. It is always non-negative, and at equilibrium it is zero
for all used routes.
Net.ont – summary table of OBA restricting subnetworks statistics in Tab
delimited text format. Each line represents one main iteration. (Restricting
subnetworks change only in main iterations.) The most important columns are:
5120257 / Apr 15 21-6

Section 21

♦ Main iteration index
♦ Clock – CPU time in seconds
♦ New links – sum over all origins of the number of new links added to the
restricting subnetwork.
♦ Removed links - sum over all origins of the number of links that has been
removed from the restricting subnetwork.
♦ Merge nodes – sum over all origins of the number of merge nodes, i.e. nodes
with more than one approach (entering link), in the restricting subnetwork.
Non-basic approaches – sum over all origins of the number of non-basic
approaches in the restricting subnetwork; where for every node one approach is
considered basic, and all others (if there are any, i.e. if it is a merge node) are
considered non-basic.
Net.olg – Log file in text format that includes various messages mainly for
software development and debugging. Please send this file with any support
request.
Net.ost - Stores the complete OBA solution in compact binary format as used by
program segments written in C. The same basic information is also stored in .UFO
files but these are used by programs written in FORTRAN. Thus P1X reads .UFO
files whereas SATALL, when run in “perturbation mode”, reads .ost files (See
22.5.4).
Net.ofn – Stores the complete OBA solution in expanded text format. (This can be
an extremely large file even for networks of modest size and it is normally
excluded.)
21.7 Practical Considerations
21.7.1 Parameters
The following parameters defined within the network .dat &PARAM records control
the choice of method / data structure plus various sub-options:
MET 0 Use link-based methods (Default)
1 Path-based
2 Origin-Based Assignment
IPERT 0 Non-perturbation assignment (Default)
1 Perturbation assignment
ISP 0 Path-based Frank-Wolfe algorithm (Default)
1 Social Pressure
2 “Enhanced” Social Pressure
5120257 / Apr 15 21-7

Section 21

N.B. IPERT and ISP only apply to path-based assignment, i.e., when MET = 1,
and therefore are virtually never required. To request OBA the only parameter
that needs to be set is MET = 2.
Alternatively, the choice of perturbation or not may also be set within &OPTION
using the logical parameter:
WSTART F Non-perturbation assignment (Default)
T Perturbation assignment (Warm START)
21.7.2 FTN95_NEW_MEMORY
In order to run OBA with relatively large networks (in practice this means virtually
all networks) an environmental parameter FTN95_NEW_MEMORY has to be
turned “on” such that the internal memory used by the OBA calculations (which is
programmed in C) is released and recycled when it is no longer needed. If this
parameter is not set then SATALL will almost certainly crash, in a random
manner, due to memory allocation problems.
Since the release of SATURN v10.9.12, the parameter is automatically set either
by SATWIN or within the SATURN (or SATALL) batch file so it should be
“invisible” to the user. However, if for any reason the versions of satwin.exe
and/or satall.bat being used are not up-to-date, problems may result. If you
encounter problems, please contact us in the first instance.
There may also be instances where the amount of memory required to store the
path information is beyond the physical limit available to individual programs
under 32-bit Operating Systems (circa 1.6Gb RAM). This has occurred once with
a very large network (i.e. 30000+ nodes, 1500+ zones, 7+ user classes and
mostly non-zero demand ij pairs). Again, if you encounter problems, please
contact us in the first instance and it is very likely that the model will need to be
run within a 64-bit operating system.
21.8 Examples of OBA Applications

To demonstrate the ability of OBA in particular to estimate the impact of very small
changes in networks and/or trip matrices we give three examples drawn from real-
life networks. These involve three networks:
♦ A small (29 zone) buffer-only network of Headingley;
♦ A combined buffer and simulation York network (176 zones);
♦ An “anonymous” network known as “Inkton” (115 zones).

Small, totally artificial, “schemes” were introduced in all 3 networks as follows:
♦ Headingley: a single pcu per hour was added to one particular O-D pair
(equivalent to 0.5 pcu’s since LTP = 30 minutes);
♦ York: an extra lane was added to a particularly congested simulation link;
♦ Inkton: the traffic signal settings at a single junction were “optimised”.
5120257 / Apr 15 21-8

Section 21

Thus all three changes were relatively small, the first being to the trip matrix and
the last two to the network.
The changes were assessed by running all three sets of “before” and “after”
networks through SATURN under (a) Frank-Wolfe and (b) OBA, both with very
strict convergence criteria (e.g., NITA = 199, ISTOP = 100, NISTOP = 4, PCNEAR
= 0.2%).
Results for Headingley are given in Table 21.1. Thus we note that, from the OBA
results, adding one extra pcu/hr, has increased the total pcu-hrs by 0.39 whereas,
from the Frank-Wolfe results the extra trip has, counter-intuitively, reduced the
total pcu-hrs by 0.15. Given that the assignment delta values for OBA are roughly
3 orders of magnitude better than those for Frank-Wolfe we may safely assume
that the OBA results are the “correct” results. Thus, despite a relatively large
number of assignment iterations, the “noise” in the Frank-Wolfe solutions has
rendered the results somewhat meaningless.
We may also note that, although it is not highly relevant here, that OBA requires
many fewer iterations and roughly half the CPU time as Frank-Wolfe so that its
improved convergence is not simply the result of extra number crunching.
Table 21.1 - Headingley (Before and After)
Frank-Wolfe OBA
Before After Before After
PCU-hrs 443.14 442.99 442.45 442.84
Delta (%) 0.149 0.111 0.0001 0.0001
Gap (%) 199 199 30 32
CPU (secs) 0.8 0.8 0.4 0.4
Comparable results from York are given in Table 21.2. (The format is slightly
different from Table 21.1 since the York network contains a simulation component
so that we give assignment-simulation loops rather than assignment iterations and
add Gap values.)
The overall conclusions are similar to those obtained for Headingley. OBA
predicts a reduction in total pcu-hrs of 2.4 (as would be expected by adding an
extra lane on a congested road) whereas Frank-Wolfe predicts an increase of 6.0
pcu-hrs. Again one would interpret the discrepancy between the signs of the two
sets of figures as being a result of the increased “noise” in the Frank-Wolfe
solutions.
In this case OBA does require more CPU time than Frank-Wolfe (particularly, for
no obvious reason, in the after case).
5120257 / Apr 15 21-9

Section 21

Table 21.2 - York (Before and After)
Frank-Wolfe OBA
PCU-hrs 4430.3 4436.3 4429.1 4426.7
Delta (%) 0.013 0.014 0.000 0.000
Gap (%) 0.019 0.012 0.001 0.004
Loops 37 39 31 68
CPU (secs) 170 177 234 551
Finally, results from ”Inkton” (not its real name!) are given in Table 21.3.
Somewhat paradoxically, given that the scheme locally “optimised” a set of traffic
signals, both OBA and Frank-Wolfe agree that total pcu-hrs will increase, by 8.5
and 5.4 respectively. Again, given that the OBA Gap values are an order of
magnitude better than Frank-Wolfe, we would assume that there is less “noise” in
the OBA results and that 8.5 is a better estimate. Frank-Wolfe is therefore “in
error” by 3.1 or 36.5%
In terms of cpu times three of the four runs were very close to one another, the
one exception being OBA After which took roughly twice as long.
We may note a further “interesting” feature of the Inkton results which is that
Frank-Wolfe and OBA have converged to two significantly different solutions, as
evidenced the differences in the total PCU-hrs (e.g., 6838.1 vrs 6977.1). Thus we
have an example of multiple equilibria which, theoretically, are certainly possible
within SATURN given the “interactions” between flows and delays at intersections,
although very difficult to predict. (Their existence in this network may be somehow
related to the fact that local signal improvements do not lead to global
improvements.)
We may further note that the two sets of equilibria appear to be “stable”, in that if
we start OBA off from the final Frank-Wolfe solution it converges to the same point
and, equally, if we start Frank-Wolfe off from OBA. In theory, it might be possible
for the before and after solutions to converge to different equilibria with the same
algorithm and therefore give very different benefits (/disbenefits) but, in this case,
it appears not to have happened.
Table 21.3 - Inkton Before and After
Frank-Wolfe OBA
PCU-hrs 6838.1 6843.5 6977.1 6985.6
Delta (%) 0.0032 0.0033 0.0000 0.0000
Gap (%) 0.0030 0.0036 0.0001 0.0003
Loops 200 200 33 75
CPU (secs) 121 122 113 245
5120257 / Apr 15 21-10

Section 21

In general, we conclude that, for these relatively small schemes, the estimates of
benefits given by Frank-Wolfe are widely in error with 2 out of 3 having the wrong
sign. In addition the “correct” OBA results are obtained with broadly comparable
cpu times.
In practice, of course, schemes this small will be the exception rather than the rule
and we would expect that the influence of noise in Frank-Wolfe would decrease
(relatively speaking) as the magnitude of the benefits increased. Nonetheless it is
always reassuring for a modeller to know that results are as accurate as possible
across all schemes, not just for large schemes.
21.9 Further Information

Further information may be found in two European Transport Conference (ETC)
papers:
♦ the 2009 paper entitled: ‘A New Implementation of Origin-based Assignment

in SATURN. ’. A copy of the paper may be found in Appendix T. and
♦ the 2010 follow-up paper ‘The Practical Benefits of the SATURN Origin-
Based Assignment Algorithm & Network Aggregation Techniques’. A copy of
the paper may also be found in Appendix T.
5120257 / Apr 15 21-11

Section 21


d
5120257 / Apr 15 21-12

Section 21
Kick Starts: Updating, Warm Starts and Continuation Techniques
22. Kick Starts: Updating, Warm Starts and

Continuation Techniques
INTRODUCTION
22.1 Introduction to Kick Starts
Any methods within SATURN which permit an assignment to start with useful
information regarding the ultimate solution will be referred to, in the most general
terms, as “kick starts”. (The term “warm start” might be more appropriate but, as
we shall see below, warm start is used to refer to a particular technique.)
Thus two “assignment problems” A and B (where we define an assignment
problem as a combination of an input network and trip matrix as illustrated in
Figures 3.1 and 3.2) may either be the same or differ in terms of their:
♦ network topology (i.e., nodes and links),
♦ network properties,
♦ trip matrix.
Where, under network properties, we include both node and link properties such
as distances or capacities etc. and SATURN parameters such as GAP, NITA, etc.
If problems A and B are the same or “similar” in all or some of the above respects
then it may be possible to use information from the solution of A to help us solve B
more efficiently.
Examples of the sort of information which may be useful include (in no particular
order):
♦ simulation link cost-flow curves
♦ previous blocking back factors
♦ ratios of actual to demand flows (queue reduction factors)
♦ simulation cyclical flow profiles
♦ link flows
♦ paths and path flows
♦ elastic output trip matrices

Not all of these are necessarily always available (or, strictly, not always easily
available); for example, paths and/or flows may be difficult to transfer between
networks which are topologically different.
There have been a wide variety of “kick start” techniques within SATURN for
many years including:
♦ UPDATE = T within SATNET (15.3);
5120257 / Apr 15 22-1

Section 22
♦ RESTART within SATALL (15.4);
♦ Continuation within SATALL (9.12.1);
♦ REDMEN within elastic assignment (7.5.3.2)
♦ DIDDLE within SATALL (7.11.6)
♦ Path-based perturbation assignment (21.3)
♦ One Song to the Tune of Another within SATDB (11.10.7.7)

In addition a new technique, the “WSTART” or “Warm Start” option, has been
added to this list in Version 10.6. WSTART enables much greater use to be made
of the link flows from a previous assignment as a starting point to a new
assignment. (In principle WSTART provides the same options as path-based
perturbation techniques but allows them to be used over a much wider range of
conditions; path-based methods have been rarely applied outside of pure
research applications)
All the above “old” options are described individually elsewhere in the manual as
referenced above. WSTART is described in detail below (22.3).
22.2 Review of Traditional Kick Start Options

We review here the six “traditional” kick-start options listed in the previous section
in order to collectively describe their objectives, their common properties and their
restrictions and to try to indicate when and how each is best used. We will then
move on to the new “warm start” techniques introduced in 10.6.
22.2.1 UPDATE (15.3)

The UPDATE option in SATNET simply makes use of the final cost-flow curve
parameters, blocking back and QRF factors (17.2) from an “old” .UFS file to define
initial cost-flow curves for a new run rather than relying on (not very good) default
curves, etc. Its use is strongly recommended wherever possible – and indeed it is
almost always possible to apply UPDATE except when a network is being run for
the very first time. If the initial cost-flow curves are “correct” (or almost so) then the
initial assignment should be (almost) correct as well and the simulation-
assignment loops might, in principle, converge after a single loop.
Note that UPDATE may be applied not only to a different .dat file (e.g., net1.ufs is
used to update net2.dat) but it may also be used to “update itself” (e.g., a
previously assigned file net.ufs updates a new network net.dat with the same root
filename). This application is extremely useful during network development
(calibration and/or validation) when a network is being continuously modified and
the modeller does not wish to retain every historical network file (e.g., by calling
the networks net1.dat, net2.dat, etc. etc.). It should result in considerably less cpu
time in total since, once net1 has been run “cold”, net2 should be able to build on
the net1 solution and therefore converge faster; ditto net3 on net2, etc. etc. The
same principle applies of course if the filenames are unchanged.
5120257 / Apr 15 22-2

Section 22
22.2.2 RESTART (15.4)

The RESTART option is similar to UPDATE but is applied directly within SATALL
as opposed to UPDATE which is applied within SATNET prior to running
SATALL. However RESTART effectively includes all of UPDATE in that it starts
the initial assignment within SATALL using the previous set of cost-flow curves,
blocking-back factors and queue reduction factors (QRF). (In addition it also
transfers simulation CFP’s which UPDATE does not, but that only affects the initial
simulation and does not play a major role in overall convergence.)
RESTART may only be used when the only change has been to the trip matrix
and there is therefore no need to re-run SATNET in order to re-create a network
file.
22.2.3 CONTINUATION (9.12.1)

A Continuation run within SATALL directly continues the assignment-simulation
loops from a previous run of SATALL with the same trip matrix so that it
commences with not only the identical cost-flow curves etc. from the previous run
but also the previous link/path flows. It works with all assignment techniques
including Frank-Wolfe, not just OBA or path-based.
It represents, in a sense, a “boiling hot” start in that all possible prior information is
being used but is only applicable when there have been no changes whatsoever
in the network, trip matrix or parameters (except in so far as MASL is increased).
22.2.4 REDMEN (7.5.3.2)

REDMEN may also be thought of as a “kick start” to an elastic assignment in that
it provides a “good” initial estimate of how many O-D road trips will eventually be
assigned to the network. It may therefore prevent the O-D matrix estimates “flip-
flopping” backwards and forwards between very high and very low estimates of
the trip matrix. As a side effect if the matrix is more stable it becomes much easier
for the assignment to converge more rapidly as well.
22.2.5 DIDDLE (7.11.6)

DIDDLE is perhaps the “classic” example of a kick-start technique, albeit one
which is applied entirely internally within the assignment-simulation loops. Thus
DIDDLE uses information from the previous assignment, specifically the link flows,
to provide the starting point for the following assignment; i.e., during step 1) of the
Frank-Wolfe algorithm as described in 7.1.2.
Empirically it has proved to be extremely efficient in reducing cpu time and
improving the convergence both of the assignment – directly – but also – indirectly
– of the assignment-simulation loops.
22.2.6 Perturbation Assignment: Paths and OBA (21.3)

A “perturbation assignment” as used under path-based assignment starts a new
assignment using the paths (strictly speaking the flow proportions per path) from a
previous assignment. It permits either the network and/or the trip matrix to be
changed. If the network has been altered then the old paths are tested for
“connectivity” and spliced into correct new paths as necessary. A full description
5120257 / Apr 15 22-3

Section 22
of how path-based perturbations may be used is given in the papers reprinted in

Appendix H.
Similarly an OBA perturbation starts with the set of origin-based flows from a
previous OBA run and has similar procedures and applications to path-based
perturbations.
Both, in fact, function in a very similar fashion to the Frank-Wolfe based Warm
Start option (described below)
22.2.7 Conditions for Application

Table 22.1 indicates when strict “equality” is required between A and B in terms of
network topology, network properties and the trip matrix in order to apply the
technique. We can see that Continuation and DIDDLE are the most restrictive
whereas UPDATE and Perturbation have the least restrictions on their
applications:
Table 22.1 – Summary of Applications
Process Topology Properties Trip Matrix
UPDATE No No No
RESTART Yes Yes No
Continuation Yes Yes Yes
REDMEN No No No
DIDDLE Yes Yes Yes
Perturbation No No No
Thus UPDATE may be run under relatively weak conditions but, as a

consequence, provides the least useful information. At the other extreme a
Continuation Run requires the most stringent starting conditions (although not
difficult to achieve) but equally provides the “hottest” start.
22.3 Warm Starts (WSTART = T)
22.3.1 General Objectives

The objective of the so-called “warm start” or “WSTART” option is to allow
information on the previously assigned flows to be passed from the “old” to the
“new” network.
In effect WSTART may be thought of as a form of DIDDLE but one which
operates only on the very first loading step of the very first assignment. Thus, in
the Frank-Wolfe algorithm, as described in Section 7.1.2, WSTART replaces the
initial all-or-nothing flows based on free-flow costs in step (1) with a set of flows
obtained from the previous network. By contrast, DIDDLE creates an initial load in
exactly the same manner but on later assignment-simulation loops.
5120257 / Apr 15 22-4

Section 22
Thus it is extremely “natural” to apply both WSTART and DIDDLE together.

(Although our strong advice is to use DIDDLE at all times whether or not WSTART
is used as well.)
WSTART operates under two modes. Firstly, if the new network and trip matrix to
be assigned are identical to the “old” network and matrix then the “old” link flows
may be used directly. Thus:
Equation 22.1
Va ( 2) = Va (1)
where (2) refers to the “new” network and (1) to the old. This situation is likely to
arise, for example, if a network has been “edited” so that certain link properties
such as saturation flows or lane allocations have been altered but no links added
or deleted or if certain parameters under &PARAM have been re-set. These are
typical of the “network calibration” stage.
However, if there are either any topological network changes or changes to the
trip matrix then it will be necessary to create a “guesstimate” of the initial flows
obtained by assigning the “new” trip matrix to (as far as possible) the previously
assigned paths and in the same proportion:
Equation 22.2
Tpij ( 2) = Ppij ( 2)Tij ( 2)

And
Equation 22.3
Va ( 2) = ∑ Tpijδ pij
a
pij
Where P pij (2) represents the (estimated) proportion of trips from origin i to
destination j using path p in the “new” network, T ij (2) is the “new” trip matrix and δ pij
= 1 if path pij uses link a, else it is equal to 0.
If only the trip matrix has changed then applying equation (22.2) is relatively
simple since any paths in the old network must exist in the new network with the
identical structure and we can equate P pij (2) = P pij (1).
However, if certain links have been deleted in the “new” network, then an “old”
path pij may no longer be “valid” in the “new” network and it must be somehow
“spliced” to fit into the new network; hence extra complications arise since we will
need to somehow estimate P pij (2) from P pij (1). (N.B. Adding links introduces fewer
problems since all old paths must still exist although there are minor problems in
translating link numbers etc. between the two systems and/or deciding whether or
not any traffic should be assigned to the new links.)
A common example where the trip matrix changes but not the network occurs
when SATURN is being used as a pure assignment model in conjunction with an
5120257 / Apr 15 22-5

Section 22
external demand model (see Section 7.4.5). Alternatively changes to the network
with the trip matrix fixed occur routinely during network calibration (in addition to
changes in link properties).
In either case the initial set of flows V a (2) should provide a much better starting
point than an all-or-nothing solution and consequently result in considerably faster
convergence of the assignment (in addition to any benefits obtained by using
UPDATE = T, e.g., improved cost-flow curves)
We briefly note here that the equations such as (22.2) constitute the crux of the
problem as far as link-based Frank-Wolfe algorithms are concerned where
calculations involving path flows are difficult; by contrast they are “meat and drink”
to either path-based assignment or OBA. The introduction in 10.6 of UFO files, as
described in detail in 22.5, is the critical addition that allows warm starts to be
applied across the board.
Sections 22.4 and 22.5 below describe respectively how both functions are carried
out with particular reference to link-based Frank-Wolfe assignment; path-based
and OBA are dealt with in Section 21.3.
22.3.2 Running Warm Starts: Simple Situation

Technically, to run a warm start, set the &OPTION Namelist parameter WSTART
= T in the network .dat file input to SATNET. In addition the &OPTION parameter
UPDATE must also be T since both options use data from the same updated file
(as specified by UPFIL within &OPTION). Thus UPDATE makes use of the “old”
cost-flows curves etc. while WSTART makes use of the old flow information.
The file to be used to provide the warm start data is set by the parameter UPFIL
under &OPTION.
Note, therefore, that is not necessary to make use of .ufo files in these simple
situations whereas, as we shall see later (22.5.1), ufo files are required for
network and/or matrix changes.
22.4 WSTART with Topologically Identical Networks and Matrices

If the old and the new networks are “topologically” identical – i.e., they share
exactly the same definition of assignment links and nodes (including identical
turning movements) – and the trip matrix is identical then a warm start is relatively
simple: set the initial flows for the first assignment to be equal to the final assigned
flows from the old network – equation (22.1).
This situation does not require either UFC or UFO files from the original network
(i.e., SAVEIT could be F) since path flow information is not required at all. Clearly
SAVEIT = T plus UFC files are very useful in other contexts but if the user is
simply running a network, changing certain parameters based on fairly aggregate
information and re-running using WSTART, setting SAVEIT = F may save a
certain amount of cpu. For “final” runs we would, of course, strongly recommend
setting SAVEIT = T.
Note that being topologically identical allows for changes to be made in either
individual link properties such as capacities or times or in global parameters such
as GAP values. (If the properties and parameters were identical then nothing has
5120257 / Apr 15 22-6

Section 22
really changed and what is really needed - if anything - is a continuation run rather
than a warm start.)
Furthermore note that introducing new banned turns under 44444 does not count
as topological changes whereas changing turn saturation flows to zero under
11111 (which could have exactly the same effect as a 44444 ban) does alter the
network structure. This introduces the interesting idea that, in progressing from a
“do-nothing” to a “do-something” network, it may be possible to include the new
links in both networks but to effectively remove them from the do-nothing network
by the use of 44444 banned turns. In this way the do-nothing network might be
used to warm-start the do-something using the simpler methods described here.
As we shall see in the next section running a warm start when there have been
topological changes is more complicated and may require more CPU time.
An interesting extension of the idea of applying a warm start on a topologically
unchanged network occurs when none of the network changes affect the
assignment at all; for example when a network is updated by simply adding a new
or different set of counted flows to the .dat file or a different set of timed routes for
validation purposes. In this situation there is no need to carry out any form of re-
assignment since the flows from the previous network are equally valid in the new
network. To take advantage of this fact set WSTART = T and MASL = 1 in the
updated network (and preferably SAVEIT = F since the old .UFC file is still valid as
well) in which case all SATALL will do is to copy the old flows over, run a single
simulation and one can go directly into analysis in P1X with the new counts and/or
timed routes available.
Finally we note that, in particular, WSTART may be very efficiently applied in the
“topologically-equivalent” mode when a network which has been run under a
previous release of SATURN is run under a later release (i.e., currently only 10.6
since this was the first release where WSTART was provided).
22.5 WSTART with Altered Networks and/or Matrices: UFO Files
22.5.1 Introduction
As mentioned in 22.3.1, if either the network or the trip matrix differs between the
“new” and “old” networks, then the previously assigned flows (equation (22.1))
may not be used as a prior estimate of the new assignment and the more
complicated path-based equations (22.2) and (22.3) must be used. These
situations arise routinely during network and/or matrix calibration and during links
between SATURN and external matrix demand models.
With either path-based or origin-based assignments it is relatively straightforward
to re-assign a (potentially new) trip matrix to the formerly assigned paths. For
technical details please see Section 21.3. However there are problems carrying
out these calculations with link-based Frank-Wolfe (which, unfortunately, is what
most SATURN applications use).
These problems have been successfully overcome within 10.6 by the introduction
of “UFO files” as an alternative method to UFC files (see 15.23.6) to store
assignment path flows by using techniques developed under OBA (see 21.4).
(Basically that is all you need to know about UFO files so, if you feel that is a
5120257 / Apr 15 22-7

Section 22
sufficient explanation, feel free to skip over the more detailed description in 22.5.2
to 22.5.6 and go straight to 22.5.7!)
Note that UFO file are created routinely and with, effectively, very little extra CPU
time under OBA (met = 2) whereas to create UFO files from the starting point of a
Frank-Wolfe assignment (met = 0) may require considerable extra CPU time. In
the latter case the extra CPU time to create the UFO file in the first place may
actually be greater than the CPU time saved by subsequent applications. This is,
therefore, a major benefit in using OBA assignment.
22.5.2 UFO files within Origin-Based Assignment (Splitting Factors)

We must first invoke a bit of theory to explain what .UFO files consist of and how
they are integral to OBA.
First, we note that, if we could obtain a perfect Wardrop Equilibrium solution for a
particular origin, then the (positive) flows would define an “acyclic sub-network”,
which is to say a set of links within which no cycles are possible. Think of it as a
set of link flows which move continuously “forward” away from the origin until they
reach the destinations.
OBA uses this concept by always working with acyclic sub-networks by origin,
continuously refining them and the flows within each until a perfectly convergent
Wardrop solution is obtained.
A consequence of acyclic networks is that, at any stage, the current assignment
per origin may be specified in terms of: (a) a “topologically” ordered list of all
nodes starting from the “nearest” to the origin to the most distant, and (b) a set of
“splitting factors” which define, for each node, the division of flow into that node
from each possible entry node. Thus, if node N is “fed” by two entry nodes A and
B then the splitting factors on links A,N and B,N specify the relative fractions of
origin trips using both those links. In addition both nodes A and B must be before
N in the ordered list.
OBA uses this data structure in order, for example, to assign all traffic for that
origin. Thus, starting with the relevant O-D flows initially “loaded” at each
destination the loading algorithm works from the most distant node back down
through the order list of nodes until it eventually reaches the origin, at each node
dividing all the accumulated traffic between the permitted entry links and adding
that traffic to the entry nodes. Since the entry nodes are always lower down in the
list any accumulated flows will be dealt with later on until all flow arrives back at
the origin. This process is often referred to as a “single pass” in which all trips are
loaded “downhill”.
Equally post-assignment analyses such as selected link, forests, cordoning, etc.
etc. (15.23.1, 15.23.6) all follow the same general principle of using “single pass”
algorithms for each origin as opposed to explicit loops over individual O-D paths
with Frank-Wolfe. In most cases this results in much faster (less CPU) solutions
but there may be some cases where the extra complexity of single pass
algorithms renders them less efficient and/or unavailable.
The node list and splitting factors are ultimately stored in an output binary file with
the (arbitrary) extension .ufo. Hence we use the term “UFO file” to describe that
5120257 / Apr 15 22-8

Section 22
particular method of storing solutions which may then be used to re-create O-D
paths for various analyses.
Note that link splitting factors may be displayed within P1X (see 11.8.3).
Once we have a UFO file it is relatively simple, for example, to re-assign a
different trip matrix to the same set of paths or, if the network has changed, to
create an alternative UFO structure which is as near as possible to the original but
respects the new network structure. This property means that UFO solutions are
ideal for creating a warm-start assignment and that OBA is a “natural” algorithm
for warm starts.
Unfortunately, assignments obtained using the Frank-Wolfe algorithm are not, in
general, amenable to being stored precisely in the UFO format although it is
possible to convert a Frank-Wolfe solution into a nearly equivalent set of flows
which satisfy the acyclic condition and which may therefore be stored as .UFO as
explained in the following section, 22.5.3.
22.5.3 Creating UFO files from a Frank-Wolfe Assignment

The main problem in describing a Frank-Wolfe solution per origin in a UFO-style
format is that the link flows do not necessarily constitute an acyclic network, in
other words there may be sets of links, all of which have been assigned positive
flows, which constitute cycles. The most obvious example of this is the situation
where flows have been assigned to a link in both directions, i.e., link (A,B) has
positive flow and so does (B,A). One of the main reasons why Frank-Wolfe
converges extremely slowly beyond a certain point is that Frank-Wolfe finds it
almost impossible to remove cycles of flow once they have occurred.
It follows that if cycles do exist there must be some links (A,B) where flow goes “in
the wrong direction”; i.e., B is actually nearer to the origin than A. If we could
eliminate all such wrong-way flows then we could create a UFO solution.
The algorithm used to convert Frank-Wolfe solutions into splitting factor / UFO
solutions is as follows:
1) Build a minimum cost tree from the origin O and create an initial “topological”
list of nodes ordered by minimum cost from the origin; i.e., nearest node at
the “bottom”, most distant at the “top”.
2) Re-create the Frank-Wolfe solution for that origin by re-loading from the
UFC file to obtain all link flows V (A,B) for a single origin/user class. (See
below for alternative methods based on Spider networks.)
3) Re-arrange the list of ordered nodes as far as possible such that if V (A,B) > 0
then A is nearer the bottom of the list than B; e.g., swap A and B in the list.
N.B. This may not always be possible, particularly if flow is positive in both
directions (A,B) and (B,A) (in which case we try to satisfy the condition for
the direction with the greater flow.)
4) If V (A,B) > 0 but A and B are still “in the wrong order”, set V (A,B) = 0.
5) If, optionally, V (A,B) > 0 but the link (A,B) appears to be part of a residual path
(i.e., the cost of travelling to B via A is very much more expensive than via
the minimum cost route; see 15.27.8), set V (A,B) = 0
5120257 / Apr 15 22-9

Section 22
6) Calculate the splitting factors at all nodes for all entry links with positive flow.
7) Store in the UFO file (see 15.23.6).
We may note that, unless we have been able to re-arrange the list of nodes such
that all links where V (A,B) > 0 satisfy the “A before B” rule, the origin-based flows
given by the UFO solution will differ from those given by the UFC solution.
However, this may not necessarily be “a bad thing” since, by removing flows that
go in the wrong direction, we may well have a solution which is actually nearer to
Wardrop equilibrium. Also, given that the UFC flows are themselves generally only
approximations of the actually assigned flows (see 15.23.2), the additional
approximation may be less significant.
In order to create a .UFO output file from within SATALL it is necessary to set an
&PARAM parameter SAVUFO = T in the original .dat file along with SAVEIT = T.
In addition, another &PARAM parameter USEUFO = T will instruct analysis
programs such as P1X, SATCH, etc. to use the .UFO file in preference to the
.UFC file. Both SAVUFO and USEUFO default to F; see 6.3.1 as well as 22.5.7
below.
Alternatively a .UFO file may be created “after the fact” using a special procedure
SATUFO described in Section 15.23.7 or as part of the SAVUFC procedure
(15.23.5). A multi-core version of SATUFO, SATUFO_MC, is also available; see
15.23.7.
CREATING UFO FILES WITH SPIDER = T

If a network has been created in SATNET with SPIDER = T and run through
SATALL in the same “mode” then it is possible to use an alternative set of
procedures to obtain the “normal” link flows V (A,B) per origin/user class (step 2)
above). The spider methods turn out to be considerably faster (almost 20 times
faster in some empirical tests than the older methods) and is applied automatically
if SPIDER = T.
In addition, with SPIDER = T, it is possible to generate a second topological list of
nodes plus splitting factors etc. based on the spider network node / link definitions
and both sets of data are stored in the .UFO files. Procedures which use UFO
solutions for further analysis (skimming, SLA etc. etc.) may then use either set of
network/UFO structures, depending on which is more efficient (which is to say,
generally speaking, the spider network).
We note that the spider-based algorithm to calculate V (A,B) makes use of the “trick”
to eliminate aggregate links with zero flow prior to tree building (see 15.56.5.3)
which empirically reduces CPU by roughly 50% in most networks.
22.5.4 Converting a UFO solution for an altered network

Having created UFO solutions for an “old” network warm starts require that we
apply that solution to the “new” network where the network structure may be
different; i.e., nodes and/or links will have been added /subtracted.
If the network is unchanged topologically (but presumably the matrix is changed)
then the “old” UFO solution is still valid within the “new” network and it is simply a
question of reassigning the new flows to (in effect) the old paths.
5120257 / Apr 15 22-10

Section 22
However, if the network topology is changed, we must convert an old .UFO

solution into a form which is consistent with (a) the new network structure but (b)
also respects possible new shortest paths introduced by new links.
Such algorithms are provided within SATALL. A detailed description will be
provided later.
22.5.5 Estimating Initial Flows with a New Network and/or Trip Matrix
Having obtained a “best estimate” UFO solution by origin we may now simply
apply equations (22.2) and (22.3) in order to obtain an initial solution for the
assignment algorithm (whether Frank-Wolfe or OBA) which may then proceed as
normal – except, hopefully, an awful lot faster!
Note that this application of a warm start may be applied if (a) only the network
has been topologically changed or (b) if only the trip matrix has been changed or
(c) both. Situation (a) occurs routinely during network calibration; situation (b)
occurs not only during matrix calibration for a base year but also, very importantly,
with VDM when SATURN is being linked with an external demand model (see
7.4.5).
In the case of VDM the use of warm starts may lead to considerable reductions in
CPU time. However, to repeat the warning on CPU time given at the bottom of
Section 22.5.1, it may well be that, under Frank-Wolfe assignment, the extra CPU
time required to create a .UFO file at the end of one assignment in order to warm
start the next assignment may in fact be greater than the CPU time subsequently
saved. However, this does not apply to the use of origin-based assignment (OBA)
where the extra CPU to create a UFO file is minimal and the time savings may be
significant.
We therefore strongly recommend the use of OBA under external VDM.
22.5.6 Analysis Options using .UFO Files

Analysis options such as select link, analysis, display of forests, cordoning, etc.,
all of which re-create the routes used during the assignment (15.23) may
(virtually) all be run equally well using the information contained in .ufo files as
using .ufc files. But, in addition, analyses using .ufo files are likely to be
considerably faster (in terms of cpu time) than those based on .ufc. The basic
reason is that ufo-based analyses require a single pass or set of calculations per
origin whereas ufc-based analyses require a similar pass which is repeated once
per Frank-Wolfe iteration per origin.
The same considerations also apply to skimming matrices which is considerably
faster under OBA than Frank-Wolfe.
Instructions for creating .UFO files are given in 22.5.2 to 22.5.4 above.
22.5.7 Running Warm Starts: Complicated Situation

Technically, in terms of setting parameters, running a warm start with an altered
network and/or matrix is not very different to the correspondingly simpler situation
5120257 / Apr 15 22-11

Section 22
Thus, as before set the &OPTION Namelist parameter WSTART = T in the “new”
network .dat file input to SATNET. In addition the &OPTION parameter UPDATE
must also be T since both options use data from the same “old” file (as specified
by UPFIL). Thus UPDATE makes use of the old cost-flows curves etc. while
WSTART makes use of the old flow information.
However, in addition, the “old” network must have been run with &PARAM
parameters: (a) SAVEIT = T and (b) (for Frank-Wolfe assignment, MET = 0)
SAVUFO = T in order for that network to create a .UFO file (as per 22.5.3) to be
used by the “new” network. N.B. Under OBA (MET = 2) it is only necessary to set
SAVEIT = T, in which case the .UFO file is created automatically.
Otherwise no other changes are required.
Note that is also feasible to create .UFC and/or .UFO files “after the fact” using the
special batch file procedures SATUFC and SATUFO; see 15.23.5 and 15.23.7.
22.6 Warm Starts with Elastic Assignment

We consider here the case where WSTART = T and the assignment is elastic
(MCGILL ne 0 in &PARAM).
Basically, very little is changed from the situations described in Sections 22.3 to
22.5. If the network and the input trip matrix are unchanged (where by input trip
matrix we refer to the “base” trip matrix T ij 0 in the elastic calculations, i.e., FILTIJ
as opposed to the output trip matrix) then we set parameters as per 22.3.2. If, on
the other hand, either the network or the (base) trip matrix has changed proceed
as per 22.5.7.
Note, however, that the REDMEN option is always invoked with a warm start
elastic assignment (whether or not REDMEN is set to T in the network .dat file)
and that the trip matrix used as the initial estimate for the first assignment is the
trip matrix as output from the old network. In effect FILRED in the “new” network is
set equal to ROADIJ from the “old” network.
Thus, in the very first elastic assignment the initial trip matrix is taken from the old
output trip matrix and the initial link flows are based on the old link flows (suitably
corrected for network changes, etc.).
22.7 Advantages of Kick-Starts

The following advantages are likely (though not guaranteed to be obtained by the
use of the various kick start techniques described above:
♦ Reduced cpu time for assignment-simulation convergence
♦ Reduced “noise” during evaluation

In addition WSTART offers the following additional benefits:
♦ Reduced cpu time for analysis, e.g. select link, skimming etc.
♦ Greater flexibility in dealing with alterations to networks and/or matrices
5120257 / Apr 15 22-12

Section 22
The practical benefits of Kick-Start techniques (when used in the context of

external VDM) was demonstrated in the recent research work paper presented at
the 2010 European Transport Conference and reproduced in Appendix U. The
research concluded that the OBA-based VDM out-performed the equivalent
Frank-Wolfe based models both in terms of overall Supply-Demand GAP
convergence (1/3rd lower) and the total CPU time required (up to 2x reduction).
5120257 / Apr 15 22-13

Section 22
5120257 / Apr 15 22-14

Section 22
Linking SATURN and GIS
23. Linking SATURN and Geographical

Information Systems (GIS)
23.1 Introduction
This section discusses various ways in which SATURN users may interface their
SATURN data with “proper” GIS systems such as MAPINFO and ARCINFO and
vice-versa with a view to obtaining the best possible outputs by the using two sets
of systems in combination.
We note that SATURN has its own system of “.GIS files” which should not in any
way be confused with “proper” GIS systems such as ARCINFO. What a .GIS file
provides is a very simplified form of data coding whereby useful data such as
information on the shape of curved links, node text names, etc. etc. may be
accessed by SATURN programs to make their outputs more meaningful. Indeed
one of the objectives of this section is to suggest ways by which SATURN .GIS
files may be set up automatically from (proper) GIS systems and their associated
data bases.
A slightly different form of software with which SATURN may be usefully linked
are packages such as GoogleEarth(R) which can provide background .bmp files for
network plots as well as extremely useful network information such as lane
structure at intersections.
23.2 Exporting SATURN data to GIS Systems

In general there are three forms of data which a user might wish to export from
SATURN into a GIS system:
♦ Topological network data (including both nodes and links)
♦ Matrix data
♦ Link-based data
Of these the third is the most common whereby a SATURN user wishes to export
assignment outputs such as link flows or speeds for display or manipulation in a
GIS system. The simplest and most common way to do so is to use an ASCII file
dump from a program such as SATDB or P1X (11.10.9) or utilities such as
DBDUMP (see 15.46) to create text (ASCII) files which can be read by a GIS
system.
One problem that arises here is that SATURN identifies links in terms of their A-
node and B-node numbers but a GIS system may not have the same information
but prefer to have its data geo-coded by co-ordinates. There is a very useful
option within “Read Miscellaneous Data” in SATDB where option 6 creates 4 data
columns consisting of the (X,Y) co-ordinates for both the link A-node and B-node;
clearly these may then be included on an output ASCII file to geo-code each link
entry. Alternatively a separate file of node numbers plus X,Y co-ordinates may be
created; see 11.4.2 and 11.9.7.
5120257 / Apr 15 23-1

Section 23
Topological network data is generally already available and more easily accessed
in GIS packages than in SATURN but there are circumstances, as illustrated
below in Section 23.4 for MapInfo, where it is useful to build a GIS network
starting from a basic SATURN network data base.
We may also note that topological data describing a SATURN-based network may
be transferred to an alternative GIS system by “dumping” it into text files which
specify the essential node and link structures. See Section 11.4.2 for using P1X to
dump data. Further data manipulation may then be required to convert the data
into a form from which the GIS system can create its own networks.
23.3 Importing data from GIS Systems into SATURN

This section lists a number of “typical” data sets which may be easily created
within GIS systems and exported into SATURN as ascii data files. References to
the appropriate sections in the Manual which provide further information (e.g.,
formats) are given.
Imports into .GIS files (See Appendix Z)
♦ Node text names
♦ Link text names
♦ Curved links (which may then be used to set link distances in SATNET;
15.10.1)
♦ Poly-lines and Polygons

IMPORTS INTO NETWORK .DAT FILES
♦ Complete buffer network 33333 data sets (See 6.6)
♦ Use of Data Field Editing for e.g., link distances in P1X (See 11.9.17)
♦ Bus routes (See 6.9.2)
♦ X,Y co-ordinates (See 6.8)

IMPORTS INTO MATRICES
♦ Cell values in .CVS format (See 10.5)

MISCELLANEOUS
♦ Bitmap .BMP Files for use in P1X plotting (See 15.43)
♦ Trip ends (e.g., for use in matrix Furnessing and/or factoring; see 10.7.5)
23.4 The Atkins MapInfo Tools

Atkins SATURN Tools is a set of MapInfo tools developed by Atkins Transport
Planning originally as a set of in-house tools to enhance GIS publishing of
SATURN Networks within GIS MapInfo-based environment. The major benefit of
this is the ability to view the SATURN Model as part of your GIS based on the
same spatial reference / coordinate system, by default set to British National Grid.
5120257 / Apr 15 23-2

Section 23
This version of SATURN Tools is now available to the larger SATURN community
subject to conditions defined in the Disclaimer. Updates to the tools will be
available from http://www.saturnsoftware.co.uk/tools/saturntools.zip.
Requirements:
♦ MapInfo should be installed (No known problems with MapInfo versions 6.x
through to 10.x).
♦ SATURN *.dat file (for displaying network) and SATURN *.lks file (for
displaying assignment results such as flows.
♦ Users are expected to have basic knowledge of MapInfo.

Further information may be found in the Online Help files located in the folder
\TEST\GIS Tools.
23.4.1 Start SATURN Tools

To install, unzip the AtkinsModellingTools.zip file to a directory on your PC. The
following files must be kept together for the application to work properly, if at all:
♦ SATURNTools.mbx,
♦ AtkinsSATURNTools.chm,
♦ AtkinsModelTools.Icons,
♦ AtkinsModelTools.exe
♦ SATURNTools.ini
♦ SATURNTools.log
Start the program by double clicking the SATURNTOOLS.MBX this will
automatically start up MapInfo with the SATURNTools Menu under Tools >>
SATURN tools.
Figure 23.1 – SATURN Model Tools
In addition, SATURN Tools can be found under a new menu called Atkins
Modelling Tools or alternatively the most commonly used tools can be accessed
directly from the SATURN Toolpad menu buttons.
5120257 / Apr 15 23-3

Section 23
23.4.2 Load SATURN Tools each time MapInfo Starts

Follow the instructions below to instruct MapInfo to load SATURN Tools on every
start up. To do this do not double click on SATURNTools.mbx to start MapInfo.
1) Select the menu ToolsTool Manager.
2) Press button Add Tool
♦ Fill in the Add Tool form as shown below.
♦ Remember to browse to the location of SATURNTools.mbx on your own

computer.
Figure 23.2 – Add Tool
♦ Press OK.
3) Make sure SATURN Tools is in the Tools list on the Tool Manager form.
Check the Autoload check box.
Figure 23.3 – Tool Manager
5120257 / Apr 15 23-4

Section 23
4) Press OK.
MapInfo will now load SATURN Tools every time it is started
23.4.3 Introduction to Menus

SATURN Tools creates a special menu under Tools >> SATURN Tools. This
special menu can also be found under a new menu called Atkins Modelling Tools
>> SATURN Tools or alternatively the most commonly used tools can be
accessed directly from the new SATURN Toolpad menu buttons.
1) Accessing the menu from the new toolpad
Figure 23.4 – SATURN Toolpad
On first use after starting SATURN Tools will prompt the user for an output path.
♦ Create Nodes
♦ Import Network
♦ Create Bands
♦ Create Turns
♦ Label Links
♦ Settings
♦ Styles
♦ Log
♦ Instructions
♦ SATURN batch files
2) Accessing menu from the Tools >> SATURN Tools.
Figure 23.5 – SATURN Tools Menu
5120257 / Apr 15 23-5

Section 23
3) Accessing menu from the new menu called Atkins Modelling Tools >>
SATURN Tools.
Figure 23.6 – Atkins Modelling Tools Menu
CREATE NODES
The first thing stage is to create a Node table. This is done by clicking Create
Nodes and the specifying a SATURN *.dat file. SATURN Tools then extracts the
node coordinate information from the 55555 section of the Dat file and plots them
in a new map window.
SATURN Tools also reads the following settings from the &PARAM section of the
*.dat file and uses them to interpret coordinate information.For this reason, users
are expected to have some knowledge of the SATURN parameters:
♦ DUTCH - Thus being able to read both DUTCH=True and DUTCH=False

files.
♦ FREEXY - X and Y coordinates are in free format separated by blanks
♦ XYFORM "2F10.2" – X and Y coordinates like 45363453002345364342 into

453634530.0, 234536434.2
♦ XYUNIT - Scaling factor (eg 10 means an X of 34543 becomes 345430).

As an extra feature one can also add:
♦ XOFFSET and YOFFSET which are parameters that SATURN Tools will read
and use in shifting / translating the coordinates for the points. The tools will
offset/shift the coordinates read by the value given to XOFFSET and
YOFFSET respectively. This is useful since some models strip the first digit of
a number (e.g. 4561 represents the real coordinate 545610 so an XOFFSET
of 500000 is needed joined with an XYUNIT of 10.
5120257 / Apr 15 23-6

Section 23
OUTPUT FROM CREATE NODES

Create nodes creates a Node table with the Nodes and Centroids. Centroid IDs
are stored as 10000000+the SATURN ID.To display the node numbers as label
use the NodeLabel field where centroid number are stored as "C 12" where 12 is
the centroid number. The column NodeType will contain "C" for centroid nodes.
The table uses following MapInfo files:
♦ Node_<SATURN dat file name>.TAB
♦ Node_<SATURN dat file name>.MAP
♦ Node_<SATURN dat file name>.ID
♦ Node_<SATURN dat file name>.IND
♦ Node_<SATURN dat file name>.DAT

The created files are stored in the directory specified in the Settings menu.
23.4.4 Import Network

Next step is to import the Network from a SATURN.lks file. This is done by clicking
Import Network and the specifying a SATURN *.dat file.
Figure 23.7 – Select Network File Screen
The network file must be a dump from SATURN with the format described below.
The node table can be any table containing points with fields named NodeId, X
and Y with IDs corresponding to the chosen *.lks file or *.kp file.
To make SATURN Tools automatically create a Turn Layer, check the Generate
Turn box option.
The Generate Centroid Connectors option allows users to turn off the generation
of Connectors.
An example of a network with turns and nodes are shown below:
5120257 / Apr 15 23-7

Section 23
Figure 23.8 – Turns and Nodes Network Example
INPUT TO IMPORT NETWORK

The format of the LKS file is shown below:
* - COLUMN HEADER DATA:
* 1893 1 4 DISTANCE DISTANCE - assignment link distance(m)
* 2893 1 4 DIST_KM1 DIST_KM1
* 3893 1 4 DIST_KM2 DIST_KM2
*
1002 1001 636.00 0.64 0.64
1003 1002 400.00 0.40 0.40
1059 1002 491.00 0.49 0.49
SATURN tools reads the column names from the Column header section and
automatically substitutes illegal characters such as -,?,+,/,! etc. If the import
malfunctions you can modify this section to have unique names (not starting with
a number) to see if it helps. SATURN Tools may not be able to establishes the
DUTCH Setting within the *.kp or *.lks file and will present the user with a choice
that should be the same as the settings within the *.dat file otherwise the program
fails.
OUTPUT FROM IMPORT NETWORK

Create Nodes creates a network table with Links and optional Centroid connectors
and an optional Turn table with information and creates optional turn graphics.
This creates the following MapInfo files:
♦ Net_<SATURN dat file name>.TAB
♦ Net _<SATURN dat file name>.MAP
♦ Net _<SATURN dat file name>.ID
5120257 / Apr 15 23-8

Section 23
♦ Net _<SATURN dat file name>.IND
♦ Net _<SATURN dat file name>.DAT
♦ Turn_<SATURN dat file name>.TAB
♦ Turn _<SATURN dat file name>.MAP
♦ Turn _<SATURN dat file name>.ID
♦ Turn _<SATURN dat file name>.IND
♦ Turn _<SATURN dat file name>.DAT

The created files are stored in the directory specified in the Settings menu.
LOGFILE TRACE
Create Network leaves the following type of information in the SATURNTool.log
file
Date: 20030311 09:47:56,Create Network
Network-Inputfile:
C:\wsatkins\MapBasic\SATURN2MI\Data\Dutch=T.FLW\AMNETEXT.lks
Node-Inputfile:
C:\wsatkins\MapBasic\SATURN2MI\Data\Results\Node_Amnete_f.TAB
Centroids: T,Turns: T
Net Outputfile: C:\wsatkins\MapBasic\SATURN2MI\Data\Results\Net_AMNETEXT
Turn-Outputfile: C:\wsatkins\MapBasic\SATURN2MI\Data\Results\Turn_AMNETEXT
23.4.5 Create Bands

Create Bands is a tool that will work for any MapInfo table containing Lines or
Polylines. It creates a new region layer containing bands or buffers with varying
width depending on the value of a field in the table.
5120257 / Apr 15 23-9

Section 23
Figure 23.9 – Create Bands Example
To use the Create Band tool, click Create Bands and the following form then
appears:
Figure 23.10 – Create Bands Screen
5120257 / Apr 15 23-10

Section 23
First select a Link Table (any table containing lines or poly lines will do). Link
tables created by SATURNTOOLS will have a Net_ prefix. Once the table has
been selected you must select a field containing a number by which value the
bandwidth is determined. If the selected field is not a number you get an error
message asking you to select a numerical value.
As soon as a proper field has been selected a series of statistics are presented on
the form:
♦ Max: - specifies the maximum value of the selected field;
♦ Min: - specifies the minimum value of the selected field;
♦ Avg: - specifies the average value of the selected field; and
♦ Max width: - specifies the width of the band for the given maximum value.
BANDWIDTH INFORMATION
These values allow the user to specify the some form of scaling of the attribute to
be displayed as Bands.
♦ Units: This value specifies how values, used for labelling, are rounded. A
value of 1 would be suitable for variables such as vehicle flows for example;
♦ Metres per Unit - this value specifies the width of the bands per unit. e.g.
Units 10 and Metres per Unit 1 gives a band width of 10 for a value of 1.
Fixing the units and changing the Metres per unit allows one to decrease or
increase the band widths of the network at map scale. By clicking recalculate
settings after a change, max bandwidth on the network is calculated based on
these settings; and
♦ Offset: - This value specifies a parallel offset from the link to the band.
LEGEND CHECKBOX
If this checkbox is ticked a legend will be added to the Bandwidth table. The
legend will be place in the lower left corner of the Mapper window. The attribute
SIDE will have the value “LEGEND” for all legend items. The legend can be
moved in MapInfo by setting the band layer editable then selecting the items with
Side=”LEGEND” and selecting the pointer tool.
5120257 / Apr 15 23-11

Section 23
Figure 23.11 – Bands Legend Checkbox
The easiest way to use this function is to zoom in to your network with the Lower
Left corner in the Mapper placed where you want your legend to be then run
Create Bands. To show the values set the label for the bands to Value and use
the label placer tool in MapInfo. To change the Legend entries click the settings
button.
SETTINGS
The settings button opens the Bandwidth settings form.
RECALC MAX WIDTH

If the statistics doesn’t seem to change click the Recalc Max Width button. Note if
you've got special regional settings for your computer MapInfo might misinterpret
the values you put in (i.e 1,000 as 1 instead of 1000).
STYLES
The styles of the bands can be changed using the style selector buttons under
Positive and Negative values.
CREATE BANDS
Pressing this button will create bands for the selected link table.
OUTPUT FROM CREATE BANDS

Create Bands creates a band table based on the links in the input file. This
creates the following MapInfo files:
♦ <Inputfile name>_bands.TAB
♦ <Inputfile name>_bands.MAP
♦ <Inputfile name>_bands.ID
♦ <Inputfile name>_bands.IND
5120257 / Apr 15 23-12

Section 23
♦ <Inputfile name>_bands.DAT
LOGFILE TRACE
Create Bands leaves the following type of information in the SATURNTool.log file
Date: 20030311 09:51:09,Create Bands
,Network Inputfile:
C:\wsatkins\MapBasic\SATURN2MI\Data\Results\Net_AMNETEXT.TAB
,Band Outputfile:
C:\wsatkins\MapBasic\SATURN2MI\Data\Results\Net_AMNETEXT_Bands
23.4.6 Create Turns

SATURN Tools has the option of creating the Turn graphics when creating the
network. Select a MapInfo Turn table created by SATURN Tools when prompted
for a turn table. The Create Turns menu option will then add turn graphics to the
turn table.
Figure 23.12 – Turns Graphic
Stars represent Turns between coinciding nodes (allowed in SATURN, but not
displayable in MapInfo).
TURN SPECIFICATIONS
The Turns that are created are what is called Unit Turns. They have the following
default properties:
5120257 / Apr 15 23-13

Section 23
Figure 23.13 – Unit Turns Graphic
DISPLAYING RESULTS ON TURNS

To display results on turns one possibility is to use Thematic Mapping:
Figure 23.14 – Thematic Map Graphic
Note that it is possible to use the tools on a selection from a turn table created by
SATURN Tools (so you don’t have to wait hours for all 35.000 turns to map if you
just want to see one area). Below is a zoom in from MapInfo showing you the
detail you can get
5120257 / Apr 15 23-14

Section 23
Figure 23.15 – Thematic Mapping Turns Graphic
LOGFILE TRACE
Create Turns leaves the following type of information in the SATURNTool.log file
Date: 20030311 09:59:05,Create Turns
,Turn
Inputtable: C:\wsatkins\MapBasic\SATURN2MI\Data\Results\Turn_amnete_F.TAB
23.4.7 Label Links

The Label Links tool enables the user to present labels on both sides of all links in
a network.
The user must specify a Link table and the field to be displayed.
Figure 23.16 – Label Links Menu
5120257 / Apr 15 23-15

Section 23
Round to nearest: value rounds the value from the chosen Label field to the
fraction entered here. (eg set to 1000 a value of 123456.789 will be displayed as
123000 and set to 0.5 this displays as 123457.0)
Label Box Chars: value decides how many characters will be reserved for creating
the box highlighting the value.
Figure 23.17 – Label Box Characters
Distance to Link: Value specifies the distance from the link to the label centre.
Threshold: When ticked this box enables the Neutral and Negative Values Style
buttons. It also creates three layers to label.
♦ POS_<table name> with label >= threshold value
♦ NEG_<table name> with label <= threshold value
♦ NEU_<table name> the in betweens.

Allow overlapping Labels: Does exactly what it says on the label!
OUTPUT FROM LABEL LINKS

Label Links creates a Link table.The table uses following MapInfo files:
♦ Lbl_<Net table name>.TAB
♦ Lbl _< Net table name>.MAP
♦ Lbl _< Net table name>.ID
♦ Lbl _< Net table name>.IND
♦ Lbl _< Net table name>.DAT

The created files are stored in the directory specified in the Settings.. menu or the
path specified on first use.
23.4.8 Settings
The SATURN Settings menu allows you to set style of the map objects that
SATURN Tools creates. It also allows you to specify the output directory for
MapInfo tables that it creates. You can save your settings to the ini file that loads
automatically on start up. If you are unhappy with your settings press the default
settings button to revert to the hardcoded standard.
5120257 / Apr 15 23-16

Section 23
Figure 23.18 – SATURN Settings
SET STYLES
The Settings menu option Set Styles gives the user the possibility of changing the
styles of the SATURN network elements that are to be imported. See Styles
below.
BANDWIDTH SETTINGS
The Settings menu option Bandwidth Settings gives the user the possibility of
changing the variables of SATURNTools Bandwidth tools. See below.
Figure 23.19 – Bandwidth Settings
Pressing the Edit LegendList button gives the user the option to enter new values
or a different number of Legend entries. The text string to be entered must be a
5120257 / Apr 15 23-17

Section 23
semicolon separated text string ending on a ;. E.g. 1000;5000;10000; 5000;50000;

for the above window.
OUTPUT FOLDER
The Output Directory Browse button allows the user to specify a folder for MapInfo
tables created by SATURN Tools. In other words after setting this folder Nodes-,
Network- and Turn-tables that you import will be saved in the specified folder.
Figure 23.20 – Output Folder
Do as instructed select the desired directory and click the Save button
GENERATE TURNS
This check box indicates if turns will be created along with the network creation.
The default is unchecked.
GENERATE CENTROID CONNECTORS

This check box indicates if Centroid Connectors (buffer and simulation) will be
created along with the network creation. The default is checked.
SAVE SETTINGS
By clicking this you save the current settings to an INI file in the application
directory. This is the path where your mbx file is located. The INI file is named
SATURNTools.ini
CHANGING COORDINATE SYSTEMS

Open the SATURNTools.ini file in a text editor of your choice.
Change the line beginning with CoordSys = to your prefered MapInfo projection
keep it all on one line
CoordSys = CoordSys Earth Projection 8, 79, "m", -2, 49,
0.9996012717, 400000, -100000
SATURN Tools must be restarted for the changes to take effect.
5120257 / Apr 15 23-18

Section 23
DEFAULT SETTINGS
The Default Settings button resets all Styles and sets the output directory to the
path of the SATURNTools.mbx plus \Data. The values used in Create Band are
also reset.
23.4.9 Styles
Using this menu option allows you to change the Style setting for all the features
created by SATURN Tools. These settings are reset if you choose Default
Settings in the Settings menu. The Styles are not saved in the INI file.
Figure 23.21 – SATURN Style Settings
23.4.10 Log
SATURN Tools are now equipped with an ever growing log file. It is the
responsibility of the user to clear this log to prevent it from growing to unheard
proportions. The log keeps track of time of execution as well as input and output
files from the following processes:
♦ Create Node
♦ Import Network
♦ Create Bands
♦ Create Turns
Figure 23.22 – SATURN Log Tools
5120257 / Apr 15 23-19

Section 23
To view the log entries select Log in the menu and then press View Log.
To clear the log press Clear Log.
To exit the Log screen press the X in the upper right corner.
23.4.11 Instructions
Will open this help file.
23.4.12 Example
An example MapInfo workspace has been provided with the tools. SATURN data
files are kept separate from the MapInfo files. Use the help file to run a test on this
data.
Figure 23.23 – MapInfo Workspace Example
23.4.13 SATURN batch files

SATURN Tools also includes 3 batch files to speed up the process of extracting
data from SATURN for use with the tools. SATURN should be installed on the
machine for the batch files to run and the batch files themselves will be found in a
folder \BATS within the installed tools.
MAKEDATA.BAT
Produces network and link data for MapInfo based on DA Codes. The Command
is:
MAKEDATA .ufs file DACODE
eg
MAKEDATA DS2011v1 4513
This will produce a file containing actual flow information for the UFS file
'DS2011v1'.
MAKELINK.BAT
Dumps network link list for MapInfo. Command is MAKELINK .ufs file eg,
MAKELINK DS2011v1. This would produce a file containing link information for
the ufs file 'DS2011v1'.
5120257 / Apr 15 23-20

Section 23
MAKEFLOW.BAT
Dumps link flow list for MapInfo. Command is MAKEDATA .ufs file eg,
MAKEDATA DS2011v1. This would produce a file containing link flow information
for the ufs file 'DS2011v1'.
File Inputs may be obtained by typing the name of the batch file eg MAKEDATA
will produce:
C:\>MAKEFLOW <return>
SATURN v10 (SATWIN) BATCH FILE TO
Atkins September 2006:
TO DUMP NETWORK LINK ^& FLOW LIST FOR MAPINFO
#1 = Assigned Network File = %1.UFS or %1
#2 = Assigned Network File = %2.UFS or %2
Output Network FLOWs file called #1.LKS
^<Difference = #1 - #2^>
C:\>
To run, simply enter assigned network filename(s)
23.5 SATURN GIS Creator

Atkins SATURN GIS Creator Tools is a set of MapInfo tools developed by Atkins
to ease the creation of a curved links for a SATURN GIS (*.GIS) file. This version
of SATURN GIS Creator Tools is now available to the larger SATURN community
subject to conditions defined in the Disclaimer. Updates to the tools will be
available from
http://www.SATURNsoftware.co.uk/tools/AtkinsSATURNGISCreator.zip.
REQUIREMENTS
♦ MapInfo should be installed (No known problems with MapInfo versions 6.x
through to 10.x).
♦ A SATURN Network, typically imported into MapInfo using Atkins Model Tools
(SATURN Tools) or any other network table containing Anode and Bnode
columns representing the SATURN Anode and Bnode.
♦ SATURN version 10.6 and above.

Users are expected to have basic knowledge of MapInfo.
DISCLAIMER
Atkins SATURN GIS Creator Tools are provided to the SATURN Community by
Atkins Transport Planning and may not be passed to any third party without the
consent of Atkins, contact information is provided in Comments and Suggestions.
These tools are provided as is subject to the condition that users use them at their
own risk and any express or implied warranties are disclaimed.
23.5.1 Start SATURN GIS Creator Tools

To install, unzip the AtkinsSATURNGISCreatorTools.zip file to a directory on your
PC. The following files must be kept together for the application to work properly,
if at all:
5120257 / Apr 15 23-21

Section 23
♦ AtkinsSATURNGISCreator.MBX
♦ AtkinsSATURNGISCreator.chm
♦ AtkinsModelTools.Icons
♦ AtkinsModelTools.exe
To learn about the different functions use this Help file.
Start the program by double clicking the AtkinsSATURNGISCreator.MBX this will
automatically start up MapInfo with the SATURN GIS Creator menu under Tools.
For information on installation refer to the more detailed help file for the main
SATURN Tools or your MapInfo Manuals.
Figure 23.24 – SATURN GIS Creator Tool
23.5.2 Instructions
Once installed the SATURN GIS Creator Tool creates a special menu under
Tools, this menu can also be found under Atkins Modelling Tools. Alternatively the
most commonly used tools can be accessed directly from the new SATURN GIS
Creator Tool pad.
Figure 23.25 – SATURN GIS Creator Toolbar
The new tool pad from the SATURN GIS Creator
♦ Set Network and Node Tables
♦ Move Node
♦ Adjust Links
♦ Export Curved Links to SATURN
♦ Match Networks
5120257 / Apr 15 23-22

Section 23
♦ Export Window to SATURN
♦ View Log File
♦ Instructions
♦ About SATURN GIS Creator Tools
23.5.3 Set Links and Nodes Table

Clicking the the move node tools will call for the network and links table.
This is typically a network taken from SATURN using the Atkins SATURN Tools
comprising of a Nodes and Network Table. These need to be set before using the
tools.
Figure 23.26 – Set Links and Nodes Table
Clicking OK will open a mapper window with the two selectable tables. Editing can
be done in any mapper window where both tables are open and selectable. If you
have not set the tables you will get a message in the Message window.
TABLE DEFINITIONS (REQUIRED FIELDS)

The following lists essential tables and the recommended fields. Compulsory
fields are in BOLD other fields may be added at your leisure.
5120257 / Apr 15 23-23

Section 23
NODES
♦ NodeId Integer Index 1 ;
♦ X Float ;
♦ Y Float ;
♦ NodeLabel Char (10) ;
♦ NodeType Char (1) ;
♦ Comment Char (254) ;
NETWORK (MASTERNETWORK)
♦ ANode Integer Index 1 ;
♦ BNode Integer ;
♦ CNode Integer ;
♦ Comment Char (254) ;
23.5.4 Move Node

The Move Node is a tool button.It affects the way the cursor interacts with the
mapper. Click on a node and drag a line to the new location for the node.
The tool works on the basis of values in the Anode and Bnode fields of the Link
table. This means that all links with either an Anode or a Bnode identical to the
moved node's NodeID will be changed. A normal MapInfo edit session will only
move one line at a time.
When working with polylines only the first or last section is changed.
HINT! Holding SHIFT down while using this tool makes it work like the Adjust
Links tool Holding SHIFT+CTRL makes it move vertices.
5120257 / Apr 15 23-24

Section 23
Figure 23.27 – Move Nodes
Click the button, hold and drag to new location. Easy as that.
Figure 23.28 – Move Node
5120257 / Apr 15 23-25

Section 23
Figure 23.29 – Move Node
23.5.5 Adjust Links

Use this tool to curve the imported SATURN links. The tool introduces a new
vertex to the lines under the point where first selected. The position of the vertex
is decided by the position of the cursor when you let go of the left button.
Holding down CTRL when using the tool enables you to move vertices in the line
instead of creating new ones.(This can be used as a kind of un-do function if
minor mistakes are made since there currently is no undo function).
Be careful when adding vertices that they do not overlap. This can cause some
problems when adding further vertices.
5120257 / Apr 15 23-26

Section 23
CREATING A NEW VERTEX

Figure 23.30 – Creating a New Vertex
Click the link and hold and drag cursor to the location of the new vertex.
Figure 23.31 – Creating a New Vertex
A vertex is added to all links found under the cursor on the first click. Undo will
only undo the last of these actions and should as a rule not be performed when
using these tools.
5120257 / Apr 15 23-27

Section 23
MOVING AN EXISTING VERTEX

Figure 23.32 – Moving an Existing Vertex
Press CTRL and click the link and hold and drag cursor to the new location.
Figure 23.33 - Moving an Existing Vertex
Vertices are moved in all links found under the cursor on the first click. Undo will
only undo the last of these actions and should as a rule not be performed when
using these tools.
5120257 / Apr 15 23-28

Section 23
23.5.6 Export Curved Links to SATURN

This function will export all curved links found in the specified link table as well as
all the nodes in from a specified node table into a SATURN GIS file filling the
77777 card and the 88888 card respectively.
Use SATURN’s P1X to open the normal network then read the .GIS file. This can
be done by selecting:
♦ Files Menu Display Menu
♦ Inputs or GIS: Open a file
♦ GIS File
Once open please make sure that the heading in the right-hand menu reads:
Curved lines. If it does not, then change this by toggling the No Curves heading.
Then click on Re-Plot.
EXPORTING THE LINKS AND NODES A WALK THORUGH

Figure 23.34 – Selecting Links and Nodes for Table Export
Parameters for SATURN;
♦ FREEXY (On as default and only option in Beta Version)
♦ IROCKY (Disabled in Beta Version)
5120257 / Apr 15 23-29

Section 23
♦ XYFORM (Disabled in Beta Version)
♦ DUTCH
♦ XYUNIT
♦ XOFFSET
♦ YOFFSET.
A wrong input of any of these parameters will mean that SATURN may not be
able to find the matching link’s start and end or most likely will display unexpected
results.
Details of the parameters are provided in the main SATURN tools help file.
After a successful export the following message box appears
Figure 23.35 – Successful Export Screen
Clicking Yes will open the file in Notepad. If Notepad is not installed this may
cause an error.
5120257 / Apr 15 23-30

Section 23
Figure 23.36 – Nodepad Screen
The tool exports both links (up-stream and down-stream) SATURN will only use
one of them to represent the flows depending on SATURN parameters this may
be the first or the last link occurring.
A sample SATURN GIS file is shown below.
**************************************************************************
********************************
Net_HS11AM021204SP11PMC NETWORK with Node_HS11AM021204SP11PMC Nodes
&PARAM
DUTCH = F
FREEXY = T
XYUNIT = 1
XOFFSET =0
YOFFSET =0
&END
77777
90220 90252
479934.20 315382.03 478240.43 311782.76 481204.53 312206.20 480781.09
309877.27
500047.76 303737.34
99999
88888
C 1 457210 339820
C 2 456930 340170
C 3 456580 340150
5122 456250 337310
5123 456270 337400
5124 456200 337300
5125 455910 337170
5120257 / Apr 15 23-31

Section 23
5126 456300 337270

5127 456050 337250
16101 457190 339430
99999
23.5.7 Match Networks
THE MATCH NETWORK TOOL

The purpose is to match two networks (the source is the MasterNetwork and the
receiving network is the Destination network). The match is done by coupling
records with identical pairs of Anode and Bnode and cloning the geographic object
from the MasterNetwork to the Destination network.
The Destination network will end up having an integer field named Matched. The
Matched field will be either 1 for a successful match or 0 for no match.
Figure 23.37 – Matching Two Networks
This tool is useful for a lot of purposes. You can use it to identify link differences
between two SATURN Networks (e.g. by creating a thematic map showing
Matched 0 as thick red).
You can also use it to put objects to a table containing ANODE, BNODE fields
without having to do complex queries and update statements. (e.g. if you have a
fixed Band table of your whole network, you can still use this tool to get the
polygons across from one table to another while keeping the attributes of the
destination table).
5120257 / Apr 15 23-32

Section 23
BACKGROUND INFORMATION
The SATURN Tools allow you to import result files from SATURN as straight line
links.
In order to apply your curved links to the results you will use the Match Networks
function.
Once you have shaped your network in MapInfo using the SATURN GIS Creator
Tools you should save a master copy of the Links and the Nodes. The prime
function of the master tables is to store the line shapes and node locations used in
any of your scenarios and it is highly recommended that you use one file to store
the links for all scenarios for a model area.
SHAPED MASTER NETWORK FOR THE EPSOM SAMPLE NETWORK.

Figure 23.38 - Shaped Master Network for the Epsom sample network
5120257 / Apr 15 23-33

Section 23
IMPORTED RESULTS FROM SATURN KP FILE FOR THE EPSOM SAMPLE

NETWORK.
Figure 23.39 - Imported Results from SATURN kp file for the Epsom sample network.
MASTER NETWORK MATCHED WITH IMPORTED RESULT

Figure 23.40 - Master network matched with Imported result
23.5.8 Export Window To SATURN

Use this tool to create a bitmap and *.XYB file that can be added to SATURN as a
GIS raster file. SATURN handles BMP's of a maximum dimension of 2000x2000
pixels.
Click the SATURN BMP button to get the following screen:
5120257 / Apr 15 23-34

Section 23
Figure 23.41 – Export Settings to SATURN
REQUIRED PARAMETERS
Maximum Output Width or Height (pixels) - Reduce this number to create
smaller BMP files - below 96 is not recommended as the image will appear rough
even at the same scale as you see it on the screen now.
Font Size - decides the size of the Copyright notice that will be added to the
image.
Copyright Notice - Text to be put on the output image.
Output Path - a Path that must exist (must end with a \)
BMP and XYB File Name (no extension) - the filename of the bmp file and the
XYB file.
Find Tiles - a check box to indicate whether the program should open tiles that fit
the window or not to do so (in all cases the tiles needed will be listed in the
message window).
1st Tile Path - The first folder to be searched for Tile tables if tile is not found here
the next folder will be searched and so on.
2nd Tile Path, 3rd Tile Path, 4th Tile Path - As above but lower priority.
You will then get a confirmation that the file was saved
5120257 / Apr 15 23-35

Section 23
Figure 23.42 – Save Confirmation
This will have created the following two files
the content of the XYB file is:

2786.25 3089.13 8923.41 7321.65
The XYB file might need to be modified to match your SATURN XYFORMAT and
XYUNIT settings.
The contents of the XYB file is minx miny maxx, maxy taken from the Mapper
window corners.
To modify this open XYB file in Notepad.
23.5.9 Find Tiles?

The tool allows you to specify folders in which to search for 50K raster tiles. Tiles
must be British National Grid 20km by 20km Square and the names should be in
the form SU88.tab.
Figure 23.43 – Find Tiles
23.5.10 Make Tile Folder Settings Persistent for future searches

The table named RasterFolders.TAB in the program folder contains four records
the order of which decides where the tools will look for Raster Tiles.
Editing this table and committing the changes effect the default values for the
tools.
5120257 / Apr 15 23-36

Section 23
Figure 23.44 – Tile Folder Settings for Future Searches
Note the all paths must end in a '\' character or the tools may fail.
5120257 / Apr 15 23-37

Section 23
5120257 / Apr 15 23-38

Section 23
Index
24. INDEX
32-bit / 64-bit Operating System, see Hardware/Software Requirements
ACCEPT Profiles and Capacities 8.2
Actual Flows 5.1.11, 17.2
Actual Flows by User Class 15.21.4
A – Coefficient in flow-delay curves 8.4.2
ADEL 11.7.2.1
Advice Note 1A Speed-Flow Curves 15.9.2
AFTERS (Queues in future time periods) 17.6.2
AGAIN (Repeat Bat files using KEY) 14.5.8
AK_MIN 9.3.2
ALEX 6.3.3, 6.4.11, 8.5
All-or-Nothing Assignment 7.11.3
Alt + key input 19.4
AMY 6.3.1, 7.11.4
Appended data files 10.14
APRESV 8.8.3.1
Link-specific values in SATNET 6.4.14, 6.13.4
Arboreta 11.8.3, 15.26
ArcGIS linkages with SATURN 23.1
Array Dimensions and Versions 15.28
ARRIVE Profiles 8.1.3
ASHORT 6.3.1
Assignment 2.1, 7
Assignment networks 5.5.1
All-or-nothing 7.11.3
Burrell; see Stochastic
Choice of Algorithm: FW or OBA 9.5.3
Convergence Statistics 9.9.2
Continuation runs (WIDDLE) 7.11.6
Elastic 7.4, 9.6, 9.10
Choice of technique - Wardrop/Stochastic 7.2.6
Fixed travel times 7.11.4
Flat Trip Matrix 7.11.5
Generalised Cost 7.11.1, 7.11.2
Link listings 11.10.4
Multiple User Class 7.3, 9.11
Networks 5.5.1
Partan 7.11.7
SATEASY 7.2.6
Shadow Networks 7.11.10
Summary Statistics 11.11.5
Stochastic User Equilibrium 7.2
System Optimal 7.11.9
Wardrop Equilibrium 7.1
Atkins SATURN MapInfo Tools 23.4
ATLAS 6.3.1, 18.5.6
AUTNUC 15.15.2
5120257 / Apr 15 24-1

Section 24
Index
Automatic Timer (AUTO) 14.5.4

Changes to 14.5.6
AUTOK 9.3.1
AUTONA 9.5.4(4)
AUTOX 6.3.1, 15.12
AUTOZ 6.3.1, 15.12
Auxiliary Network Plots 11.5.4
Averaged simulation/buffer statistics 9.7, 17.9.2
AVERK: Average Kirchoff violations 13.3.3.3
A-Z Banners 11.6.9
Bandwidth (proportional) annotation in P1X
Link-based 11.6.3.2
Node-based 11.6.5.1
Fixed width, variable colours 11.6.3.8
Banned/Penalised Turning movements 6.9
Simulation Networks 5.5.1, 6.9
Buffer Networks 15.56.7.3
Banner Displays 11.15
Banner Menus 19.4
BAT Files 14
Batch Procedures 14.7
Creating DIY batch files 14.11
BB109 (new release 10.9 blocking back rules) 6.3.1, 8.5.5, 8.5.6
BBKING 8.5.6
BCRP 6.3.3, 5.4
BEAKER 5.1.9, 6.3.1, 15.13, 17.8
BETA 6.3.3, 7.7.1
Units 7.7.6
BETA-2 6.3.3
BETA-D 6.3.3
Bitmap (.bmp, .pcx, .jpg) graphical image files 11.3.6, 15.43
Bitmap folders 11.3.6
Blocking Back 5.1.11, 8.5
Convergence tables 9.9.1
Boroughs: See Traffic Boroughs
Break Option in KEY files 14.5.5
BTKNOB (Bus Times set by KNOBs) 6.3.3, 15.44
Buffer networks: 5.2, 5.3
Flow-delay curves 5.4.1
Queues and Bottlenecks 5.4.2
Summary Statistics 11.11.4, 15.59, 17.9
Capacity restraint 5.4
Conversion from Simulation (SATBUF) 15.8.2
Conversion to Simulation (P1X) 11.9.12
Link data formats in network .dat files 6.6
Turning flows at buffer nodes (see also REFFUB) 11.11.12
Bugs in Previous Releases App. E
BUSKER 6.3.1, 6.9.2
BUSPCU 6.3.3, 6.9.3
Bus-only Roads and Turns 6.4.4
5120257 / Apr 15 24-2

Section 24
Index
Bus-only lanes 6.4.9.2

Displayed with negative signs in SATDB 11.10.6.8
Bus routes 6.9
Bus companies 6.9.3
Bus Lanes 6.4.9.2, 15.39
Dump to text (.BRF) files 11.4.2.4
Route data dumped to CSV files 11.11.6
Route definitions 6.9.2
Editing bus routes 11.9.4
Extra travel times 15.44
Interpolation 6.9.2, 15.18
Summary Statistics 11.11.6
As fixed pre-load flows 15.5.5
SLA (Bus routes through a Select Link) 11.8.4.2
UPBUS: Down/upstream entries/exits 6.9.2, note 1)
U-turns on bus routes 6.9.2, note 10)
Routes which exit and re-enter 6.9.2, notes 11) and 12)
BUSSPK (Bus Stop Seconds Per Kilometre) 6.3.3, 15.44
BYGRUP (AKA BYBORO) 6.3.1, 11.11.4
C Priority Modifier (See also Clear Exit) 6.4.2.6
CAPMIN 6.3.3, 8.2.3
Capacities:
Accept Capacities 8.2
Buffer links 5.4
Simulation Links 6.4.12, 8.4.4, 8.9.4
Simulation Turns 8.2
Simulation centroid connectors 5.1.8.2, 8.5.2
Mid simulation link capacities 6.4.12.1, 8.4.4, 15.9.4
Capacity Indices 5.1.9, 6.4.12, 6.6
Default speed-flow curves 15.9.5
Names (CINAME) 6.3.4
Set in an X-File 6.13.4
Set as a “Global Data Field” from a text file 11.9.17
Capacity-Restraint Curves: See Speed-flow curves
Car Parks 15.45, 20.5.3
CASSINI 15.54
Centroids/zones 5.1.6
Centroid connectors:
Flows 15.16
Capacities due to blocking back 5.1.8.2, 8.5.2
In a simulation network 5.1.8, 6.5, 16.6
Via “spigots” or “stubs” 5.1.8.1, 11.9.4.1, 15.56.2.3
CFPs: see Cyclical Flow Profiles
Chains (of one-way links) 5.1.12
Applications to blocking back 8.5.5
Applications to random delays 8.6.4
Charging (Tolls) 20
Distance-based charges 20.5.1
Cordon-based charging 20.5.2
Parking charges 20.5.3
Stochastic Charges (STOLL) 20,6
5120257 / Apr 15 24-3

Section 24
Index
CHOKE Factors 8.4.4

Clear Exits (See C priority modifier) 6.4.2
Role in Y-merges 8.8.4.5
CLICKS: Variable speeds by User Class 15.47
Disaggregated by Capacity Index 15.47.2
V-records under 33333; maximum speed by veh class 6.6(16), 15.47.3
Incorporating variable speeds in link times 15.47.4
Display by simulation nodes 11.11.1
Use within Route Validation 11.7.2.1
CLIMAX: Fixed Maximum Speeds under CLICKS 15.47.3
Clipboard Outputs 11.3.6
COINS 6.3.4, 20.2
COBA10 speed flow curves 15.9.3
Best-fit Powers for Default Curves 15.9.6
COBA Output files (SATCOBA) 15.42
Cobweb Methods (Supply-Demand Equilibrium) 7.4.3, 7.4.4
Definition of O-D costs 7.8.6
Cold Start Re-assignments 11.10.7.4
Colours (pens) in P1X 11.3.7
COMPAS 6.3.1
Comma Separated Variables; see CSV
Command Line Namelist Parameters 14.6
Comment cards in dat files 15.29
Comparing 2 matrices (M2) 10.9.2
Comparing 2 networks
Simulation Nodes: P1X/SATLOOK 11.11.18
Highlighting coding differences 11.6.5.4
DACHEX 12.4
Connectivity of networks and/or trip matrices 5.5.4
Continuation Runs with SATALL 9.12.1, 22.2.3
Control Procedures 14
Convergence:
Within Wardrop Assignment 7.1.5
Within Elastic Assignment 7.5.5
Of Stochastic Assignment 7.2.5
Simulation convergence 8.3
Simulation-assignment convergence 9.2, 9.5, 9.8, 9.9.1
Guidance 9.2.5
Improved SATALL Convergence 9.5.1
SATME2 with Assignment 13.1.6
Display within P1X (10 Worst) 11.15
Display per node within SATLOOK 11.11.1
Of O-D routes 11.8.3.4
Relaxed control parameters 7.4.5.3, 9.5.4, 15.54
Supply-Demand (VDM) Models 7.8.6
Co-ordinates: 6.8
Choice of Units, etc. 15.43.2
Used to calculate distances 15.10
.xy sub files (in P1X) 11.9.6
Interpolating 6.8
Within GIS files App. Z
5120257 / Apr 15 24-4

Section 24
Index
Cordoning (see SATCH) 12.1

Within PIX 11.13, 12.1.4
Multiple User Classes 12.1.6
Cost-flow curves: See flow-delay curves
Cost matrices 15.27.1
For Elastic Assignment, base-year 7.8.1
Use within Supply-Demand Models 7.8.6
Minimum Cost 11.11.14
Average costs (Forest skims) 11.11.9
Costs (generalised) 6.11, 7.11.1, 7.11.2
Units: time or pence 15.24.4
Fixed link costs 7.11.1
Defined within Supply-Demand loops 7.8.6
Counts:
Input to SATNET 6.10
Input to SATME2 13.2.2
On links with centroids 15.16
.mcc externally input sub-files 11.7.1, 11.11.13
Compare to modelled flows 15.6, 11.7.1, 11.11.13
Inconsistencies: SATPIJA 13.3.3
Crow-fly distances 15.10.1, 11.11.16, App I.1
CROWCC (Buffer Centroid Connectors) 15.10.3, 15.41.5
CSV (Comma Separated Variables) Outputs:
Matrices 10.5.4, 10.5.5
SATDB network data 11.10.9
Cumulative Density Functions (KOB = 3) 7.2.3.2
CURNCY 6.6.3, 20.2
Curved links (for plotting) 5.7.1
Cyclical flow profiles 8.1.1
D markers: simulation link speed-flow 6.4.12.2
Data files; preparation of networks 6
Data requirements; general 3.2
DA Codes see Dirck Access
DACHEX: File comparison 12.4
DADUMP: File transfer 12.5
DALOAD: File import 12.5
DALOOK: Examining files 12.3
DAT files 3.3
Network .dat files 6
Data field editing (global) 11.9.17
.DBD Files (redundant) 11.10.9
DBDUMP 15.46.1
DCSV (Free-format speed-flow curves by C.I.) 15.9.5
Decimal places in fixed column formats 2.8.3
Default link Speed-flow curves 15.9.5
D records under network .dat 33333 6.6(8)
DEFCAP 6.3.3
Delay calculations (Simulation) 8.4
Functions of Flows 8.4.2
Random delays 8.6
Upper limits 8.4.1
5120257 / Apr 15 24-5

Section 24
Index
Equivalent DA codes 17.10

Definitions in P1X App. I.1.3, I.2, I.3
Delta Function for Wardrop Equilibrium 7.1.4
Link-specific Delta 11.8.3.5
Demand Flows 17.2, 10.18
Demand Functions 7.7.1
Demand Models: See Elastic Equilibrium Assignment
Demonstration program mode 14.5.4
Desire line (o-d) plotting 11.6.7
DETR Count Validations 11.7.1
Development traffic (loading single trees) 11.10.7.1
DEVTRIPS 11.10.7.1
DIADEM: Linkages with SATURN 15.51
%GAP Equivalent Convergence Measure 7.5.5
DIADEM Option (for UPDATE and/or WSTART) 6.1, 15.51
Diagonalisation (of cost-flow curves) 9.1.2
Diamond Cross Exit (D priority modifier) 6.4.2.7
DIDDLE 6.3.1, 7.11.6, 9.4,22.2.5
Differences between 2 Networks
Simulation Nodes (SATLOOK) 11.11.18
DACHEX 12.4
Dirck Access (DA) Codes 15.21
Times and Delays 17.10
Capacities 8.9.5
Definitions App. J
Direct Access Files:
Help files 19.11
Distance:
On links 6.4.5
Distribution Models 7.10, 10.18
Distributed (parallel) Processors: See Multi-core
DIY Fonts in P1X 11.3.8
Double click (P1X) 11.12.1
DOUBLE (plus TOPUP) 6.15.3
Downstream entry/exit flows 15.16.2
DTp Speed-Flow Curves (Advice Note 1A) 15.9.2
Dummy nodes 5.1.1.1
Part of chains 5.1.12
Simulation 8.1.1
Within blocking back 8.5.2(a), 8.5.5.2
Used with link capacity-restraint curves 8.4.4
DUTCH (Long node numbers) 6.3.1, 15.20
Dynamic assignment: see PASSQ
E Priority modifier (C + D combined) 6.4.2.8
Economic Evaluation Models; see TUBA
Edit Boxes (Windows) 19.9
Implications for LOG and KEY files 14.5.9
Editors (for ascii data files) 2.8
Editing Networks 11.9.1, 18.1
Global network data field editing 11.9.17
5120257 / Apr 15 24-6

Section 24
Index
Simulation Node Editing 11.9.3

Elastic Equilibrium Assignment: 7.4
Algorithms 7.5.2
Convergence Measures 7.5.5
Cost Matrices 7.8
Demand Functions 7.7.1
Elasticities 7.7.5
Multiple User Class 7.9
Loops 9.6
Reference Trip and Cost Matrices 7.8
Within SATALL 9.10
Sample.dat file 7.12.3
Time Period Choice Models App. V
Elasticities 7.7.5
Empirical 7.7.6
Supply based (speed flow sensitivity) 7.11.11
Emissions 15.33
EMME/2 formatted matrices 10.5.5, 10.15.1
Entry/Exit flows: Simulation links 5.1.8, 15.6.2
Epsilon Convergence Parameter 7.1.5
Epsilon-2 Congestion Parameter 7.2.6
Equilibrium Assignment See Wardrop
ERL (Error Listing) Files 15.58
Display as Selected Nodes in P1X 15.58.2
ERTM 4.3, 6.3.1
Errors
Fatal & Non-fatal 2.9
Suppressing Errors (ERRYES) 2.9, 6.3.1, 6.12.2
Upgrading Errors (ERRNO) 6.3.1, 6.12.3
Semi-fatal (NAFF) 6.12.1, 18.4
Highlighting within P1X 11.6.5.4
List of explanations App. L
ERL Files 15.58
Estuaries (Random Delays over Rivers) 8.6.3
EXCEL 11.10.9, 10.15
EXE files 3.4
Exit flows: Simulation links 5.1.8
EXPERT 6.3.1
EZBUS 6.3.1, 6.9.2
External simulation nodes:
Definition 5.1.1.2
Sample coding 16.4
U-turns 18.9
Unconnected 18.10
(Matrix) Factoring 10.7
(Selected Area) Factoring:
Interactive Control 10.7.1
Input Control File 10.7.2
FCF (Fixed Cost Flow Networks) 15.1
Creating FCF files with SATCH 12.1.11, 15.1.4
5120257 / Apr 15 24-7

Section 24
Index
Fcost (Cumulative generalised cost in P1X Joyrides) 11.8.2.1

(Data) Field editing (global) 11.9.17
FIFO (See also TOPUP) 6.15.1
Filename conventions 3.3
FILBMP (Background file/folder) 6.3.4, 11.3.6
FILCIJ 6.3.4, 7.12.4
FILGIS 6.3.4, 11.7
FILICE 6.3.4, 7.12.4, 13.1.6
FILKNB 6.3.4, 15.14.5, 15.42.3
FILN2G (see Groups) 5.1.7, 6.3.4, 11.11.4
FILTIJ 6.3.4, 7.12.4
FILZ2G 10.2.5.5, 10.5.2, 10.20.22
FILZ2S 10.2.5.3, 10.5.2, App W.3
Filters at Signals (Priority Marker F) 6.4.2.4
FILRED 6.3.4, 7.12.4
FILRGS 6.3.4, 6.4.3.5, 11.9.14
FISTOP 6.3.3, 7.1.5
Fixed Column Input Formats; variable decimal places 2.8.1, 2.8.3
DIY fixed column formats 15.35
Fixed Costs (on assignment links) 7.11.1
Fixed Flows 5.5.3
Flared Lanes 6.4.9.1
FLAREF – Nearside (Filter) lanes 6.4.9.3, 8.2.6
FLAREX – Offside (X-turns) lanes 6.4.9.3, 6.4.9.5, 8.2.6
FLAREX – In conjunction with MONACO 8.2.5.2
Knock-on impacts for adjacent turns/lanes 8.2.6.3
Link-specific values on link data Record 2B … 6.4.14
… or on X-Files 6.13.4
Flat Trip Matrix 7.11.5
Flow-delay curves: (see also Speed-flow)
Buffer links 5.4.1
Internal Simulation Links 6.4.12, 8.4.4
External Simulation Links 15.13
Simulation turns 8.4.2
Under ROSIE 8.4.3
DTp Advice Note 1A curves 15.9.2
COBA10 curves 15.9.3, 15.9.6
Default by Capacity Index 15.9.5
“Units” of the coefficient A 8.4.2
“Parametric” form of cost-flow equations 5.4.1
Flow Metering 5.1.11, 8.2.8, 17.2
FLPH 6.3.3, 15.32
FLPK 6.3.3, 15.32
FLPPS 6.3.3, 15.32
FLPSS 6.3.3, 15.32
Fonts (including DIY) 11.3.8
Forests: 15.26
P1X display 11.8.3
Skimming 11.11.9, 15.27.3
Sector-to-sector 11.10.7.4
FORMATS: DIY Changing .dat file formats 15.35
5120257 / Apr 15 24-8

Section 24
Index
FORTRAN Formats: Real Variables 2.8.3

FORTRAN Equations:
To manipulate link data 11.10.8.1
To manipulate matrix data 10.8.1
FOZZY 6.3.1, 6.9.2, 15.18
F priority markers (filters) 6.4.2.4
Frank-Wolfe Algorithm:
Single User Class 7.1.2
Elastic Assignment 7.5.2
FRED 6.3.3, 7.5.3.2
FREDDY (See also .RGS files) 6.3.1, 6.4.3.5, 11.9.14
FREEXY 6.8
FREE77: Free Format for 77777 count data 6.10 (13)
FRODO (Fixed cells in SATME2) 13.1.6
Frozen or Inelastic Trip Cells 7.5.6
FTN95_NEW_MEMORY 21.7.2
FUNNEL/Funnelling 8.8.4
Furnessing a matrix 10.7
Trip Ends Set Interactively 10.7.3
Trip Ends Set from a Control File 10.7.4
Basic Trip Distribution Models 10.19.1
Furness with SATME2 13.1.5, 13.1.12
Furnessing with SATCH (FURNES) 12.1.8
Fuel Consumption 15.32
Gap Acceptance 8.2.2
Pushing in from minor arms (CAPMIN) 8.2.3
GAP Function (see also Delta)
Assignment Gap 9.2.1
Link-specific assignment GAP functions 11.8.3.5
Simulation-assignment turn convergence gaps 9.9.2
Elastic Gap Functions 7.5.5
Supply-Demand Gap functions 15.42
GAP (Acceptance Parameter) 6.3.3, 15.15.1, 15.22
By Turn 6.13.5
GAPM 6.3.3, 15.15.1, 15.22
GAPR 6.3.3, 15.22
GEH Error Statistic 15.6.2
Direct calculation 11.10.8.1
Generalised Cost 6.11, 7.11.1, 7.11.2
Units: time or pence 15.24.2
.GIS Files 5.7
Creating/Editing 5.7.2
Choosing within P1X 11.6.10
Formats App. Z
Creating using Atkins MapInfo Tools 23.5
GIS Packages (e,g., MapInfo) 23.1
Exporting SATURN data to GIS 23.2
Importing data from GIS packages 23.3
Give Way Markers (G) 6.4.2.1
GONZO 6.3.3, 7.11.5, 15.2
5120257 / Apr 15 24-9

Section 24
Index
GO4IT App-Y, 14.5.10

G priority markers (give ways) 6.4.2
GRAF.DAT 11.3.1
Graphics: 19.2
MX 10.12
P1X 11.2
SATED (Node graphics) 11.12
Groups (of zones and/or nodes) 5.1.7, 10.2.5.2, 11.11.4
Hallmark (standard display of timing point data) 11.7.2.5
Hardware / Software Requirements 1.2
Head of Queues at signals: extra capacities 8.2.5
Headline Summary Stats: .CSV files 11.11.4, 11.11.13
Heavy vehicle (HGV) flows 15.5.1
Help System 19.11
.hlp pathname suffixes App. Y
HGVs (Heavy Goods Vehicles) 5.8.2
PCU factors 15.9.4
Highlighting errors etc. 11.6.5.4
History Network Files 6.2
Listing within P1X 11.8.4.10
Hooked turns at signals 6.4.2.7
“How To” Tutorials 15.1
ICING 6.3.1, 7.5.6
IFCC 6.3.2, 6.6
IFRL 6.3.2, 6.6
ILOVEU 18.9
IN Profiles 8.1.3
$INCLUDE 15.30
Converting from existing network files 11.9.2.6
Use in SATPIJA 13.2.1
Applications in cordoning 12.1.4 (10 & 15)
Over-riding network data with TOPUP and DOUBLE 6.15
Incremental Assignment 7.11.13, 15.23.2, 15.57.6
Inelastic (“Frozen”) Trip Cells 7.5.6
Installing SATURN 3.6.1
Interactive programs 19
Intergreens (signals) 6.4.3
Interpolated (bus) routes 6.9.2, 15.18
Inverse Demand Functions 7.7.2
IPERT (Perturbation assignment options) 21.3
IROCKY 6.3.2,5.1.7,6.8,10.2.5.3,
10.5.2
ISTOP; see also RSTOP 6.3.2, 9.1.2, 9.2.5, 9.2.6
Joy rides
Using P1X 11.8.2
Using SATLOOK (historical) 11.11.15
Within Validation 11.7.2.2
.JPG format input files 11.3.6
Junctions 5.1.1
KANGA (“jumps” in bus routes) 6.9.2
KDF 7.2.3.3
5120257 / Apr 15 24-10

Section 24
Index
KERMIT 6.3.1
KEY files 14.5
KEY and LOG filenames 14.5.1
Automatic timing (AUTO) 14.5.4
Break to interactive mode 14.5.5
Changes to automatic timing 14.5.6
Comments 14.5.7
Single keystroke entries 14.5.2
Mouse entries 14.5.3
“AGAIN” option 14.5.8
Edit Box entries 14.5.9
Over-writing (or not) existing files 14.5.10
Starting within P1X interactively 11.4.5
KEYSTROKE Responses 11.1.5
Kick Starts (Warm starts, etc.) 22.1
KINKY 15.38
Kirchoff’s Rule (SATME2) 13.3.3
KLUNK: Choice of methodology under CLICKS 15.47.2
KNOBS 6.3.2, 6.6, 15.14
Knob Files (KNBFIL) 15.14.5
Included in link fixed costs 7.11.2, 6.11
Used to define tolls 20.3
KNOBDUMP.bat 15.14.7
Transferring internal data to a Knob file 15.14.7
Negative generalised cost components 15.14.3
KOB 6.3.2, 7.2.3
KOMBI 6.3.2, 9.3
KONAL 6.6
KONSTP 9.2.3
KORN 6.3.2, 7.2.4
KP files 3.3
KPEXT App. Y
KPHMIN 6.3.2
KPHMAX 6.3.2
K s Factors 8.7.2
Lane definition 6.4.9.1
Lane Sharing and Choice Models 8.8
Lane width (plotted) 11.64
Last_P1X0.dat 11.4.4
Lateral Merges 8.8.4.1
LCY (Cycle time in seconds) 6.3.2, 8.1.2, 15.15.3
Consistency with neighbouring nodes 15.15.3
Links:
Alphanumeric Names 5.1.3
Assignment links 5.5.1, 11.10.4
Capacity Indices 5.1.9
Capacity Restraints 6.4.12, 15.9.4
COBA Speed-flow curves 15.9.6
Choice of Link Cost Stochastic Distributions 7.2.3
Counts 6.10
Default Speed-flow Curves 6.4.12, 15.9.5
5120257 / Apr 15 24-11

Section 24
Index
Distances 6.4.5
Restricted 6.7
Simulation links/roads 5.1.3
Stacking Capacities 6.4.11
Speed-flow curves 6.4.12, 8.4.4, 15.9.5
Times/speeds 6.4.5
Times: Alternative DA codes 17.10
Linked time periods: see PASSQ
LEFTDR 6.3.1, 15.7.2, App. Y
LIST 6.3.1
liv95.dat: sample network file 2.7
livtrips.dat: sample trip matrix 2.7
Logit Demand Functions 7.6, 7.7.1, 7.8
Multinomial Logit Models 7.6.2
Nested Logit Models 7.6.3, 7.6.4
LOG files: See KEY files 14.5.1
Loops:
SATEASY/SATSIM 9.1
SATALL 9.1
Terminating Criteria 9.2
LP files 3.3
LPG (Route flow) Files 12.6
LRTP; See Random Delays 6.3.2, 8.6.1
LTP 6.3.2,8.1.2,8.4.1,8.4.2, 8.4.5
L2G Files (links to groups) 15.60.4
Macros (See Key Files) 14.5.1
MANOFF 12.2.3
Map Networks 5.5.2
Dumping Map nodes to text files 11.4.2.2
Dumping Map links to text files 11.4.2.3
MapInfo (Atkins Tools) 23.4
Marginal costs: See SATMECC and System Optimal
MASL (Maximum assignment-simulation loops) 6.3.2, 9.1, 9.12.1
Use within SATALL continuation runs 9.12.1
MASL_F 7.5.3.4
MASL_M (Minimum assignment-simulation loops) 9.2.3
Matrices:
Aggregating sub-levels (MXAGG) 10.4.3, 10.20.21
Aggregating zones to, e.g., sectors 10.4.4, 10.16.4
Blocks (horizontal levels) 10.2.4
Comparison of 2 matrices (M2) 10.9.2
Compression:
Zones into Groups 10.4.4, 10.16.4
M3 10.16.3, App. W.1
M5 10.16.3, App. W.3
Copy a UFM file 10.4
(Minimum) Cost 15.27.1
Create a trip matrix file 4
Crow Fly distances 11.11.16
DAT and UFM files
General Properties 10.2.1
5120257 / Apr 15 24-12

Section 24
Index
Matrix input from a DAT file 10.5

Data inputs (standard) 10.5.1
Data inputs (non-standard) 10.5.2
Demand Models 10.18
Dimensions and Units 10.2.3, 10.5.1.4
Distribution Models 10.18, 10.19.1
Division (cell by cell) 10.20.25
Dumping to Ascii Files 10.15, 10.20.15
Editing zones (add, delete, etc.) 10.4.2
Estimation from counts (ME2) 13
EMME/2 Interface 10.5.5
Expansion of matrices (M5) 10.16.5, App. W.3
Factoring 10.7
Selected Area Factoring:
Interactive Control 10.7.1
Input Control File 10.7.2
File structure 10.3
Flat Matrix Creation 10.5.7
FORTRAN equations 10.8.1
Furness
Trip Ends Set Interactively 10.7.3
Trip Ends Set from a Control File 10.7.4
Graphics 10.12, 11.14
Levels 10.2.4
Log-sums (of cost matrices) 10.8.5
Multiplication (cell by cell) 10.20.19
MXM1, etc..bat files 10.20
Negative trip matrix cells; see ERTM
Output .UFM Matrices 10.16
Park ‘n’ Ride Skims 10.8.4
Printing
Complete Matrix to Line Printer 10.13
Row and Column Totals 10.14
Read non-zero matrix elements only 10.5.3
Reboots 10.4.6
Re-code a UFM File 10.4
Reduction (M4) 10.16.3, App. W.2
Rule of a Half 10.19.2
Screen Editing the Internal Matrix 10.10.4
Sectors 10.2.5.3
Select Options 10.6
Skim Matrices 15.27.2, 15.27.3
Spreadsheet input/output 10.5.4, 10.15
Stacking, unstacking matrices 10.2.4, 10.17
Statistical Analysis 10.9
Titles 10.2.7
Transposing a matrix 10.4, 10.8.2
Trip Length Distribution 10.9.3
Trip matrix distribution 7.10, 10.18
UFM Output 10.16
Unconnected OD cells 5.5.4
5120257 / Apr 15 24-13

Section 24
Index
Univariate Analysis of a Single Matrix 10.9.1

Updates of cell values 10.5.1.2
Viewing 10.10
Block of Cells 10.10.1
Multiple or stacked matrices 10.10.2
Single Rows and Columns 10.10.3
Sector-to-Sector Matrices 10.10.5
Row and Column Totals 10.11
Zone Editing 10.4
MAXDTP 6.3.2, 8.4.1
Maximum transient simulation queues 8.4.8
Maximum / Variable Array Dimensions 15.28
MAXLSF 6.3.2
MAXQCT 6.3.2, 8.4.1
MAXSPA 6.3.2, 15.56.3
MAXZN 6.3.2, 5.1.6
MCALG 6.3.2, 15.53.4.1
MCCS 6.3.2, 6.10
MCGILL 6.3.2, 7.12.2, 7.7.1, 7.9
MCNUM 6.3.2, 15.53.4.1
MCUBC 6.3.2, 7.10.2
MECC (SATURN Marginal Economic Consumer Costs) 15.50
Menus 19.3
Banners 19.4
Menu Bars 19.5
Text Menus 19.6
Single Lines 19.7
Merges (M Priority markers) 6.4.2
Y-merges 6.4.2.3, 8.8.3.1, 8.8.4.4
Capacity reductions (“Funnelling”) 8.8.4
Gap Acceptance Rules 8.2.2
Lane choice 8.8.3
Lateral merges 8.8.4.1
Metered Flow (Actual Flow) 5.1.11, 8.2.8, 17.2
Method of Successive Averages 7.2.2, 7.4.4, 7.4.5
ME2 (SATME2) 13
ME2 data files 13.9
Mid-link capacities 6.4.12
MINDER (Min distance route interpolation) 6.9.2, 15.18
MINLSF 6.3.2
MINRED 6.3.2
MINSAT 6.3.2
Minimum Cost Matrices 15.27.1
Compared with Forest Skimming 15.27.4
MONACO 6.4.9.5, 8.2.5.1
In conjunction with FLAREX 8.2.5.2
MODET 6.3.2
MONITOR (Parallel operations) 15.52.1
Moons (dependent simulation nodes) 8.3.5, 11.6.5.3
Motorway links 16.7
Mouse: Use of 19.13
5120257 / Apr 15 24-14

Section 24
Index
Entries in KEY files 14.5.3

vrs Keyboard Control 19.4
M priority markers (merging) 6.4.2.3
MSA Wardrop 7.2.2, 7.11.8
Multiple User Classes:
Algorithms 7.3.3
MUC Assignment 7.3.2
within SATALL 9.11
Definition of classes 7.3.1
Elastic MUC Assignment 7.9
Generalised costs 6.11, 7.3.2
Updating Trip Matrices: SATME2 13.4
Paper by DVV, Bergman & Scheltes App. C (PDF)
Multiple Crossing Points: SLA of Screen Lines 11.8.1.10
Multiple time period Modelling 17, App. V
Multi-core (Multiple processor) operations 15.52, 15.53
SATCH_MC 15.53.3.6
SATPIJA_MC 15.53.3.2
SATUFO_MC 15.53.3.7
Must-have files (P1X) 11.8.4.11
MX: see under Matrices
MX Command Line batch file 10.1.2
MXM1 .bat file 4.1, 10.20.1
MXM2 10.9.2, 10.20.2
MXM5 10.16.3, 10.20.20, App W.3
MXADD2 10.20.4
MXAGG (Aggregate matrix levels) 10.20.21
MXAVER2 10.20.5
MXBL0CK 10.20.10
MXDIVIDE 10.20.25
MXDOT2 10.20.19
MXFACTOR 10.20.3
MXKK 10.20.7
MXMSA (Successive Averages) 10.20.6
MXROH (Rule of a Half) 10.20.8
MXSTACK 10.20.9
MXSUB2 10.20.13
MXWEIGHT 10.20.14
MYTVV – Choice of signal optimisation algorithm 15.31.3
M108 (Merge rules post 10.8) 6.4.2.3, 8.8.4.5
NAFF (Semi-fatal) errors 6.12, 18.4
Namelist Input:
Full implementation App. A
Pseudo implementation App. B
Via the command line 14.6
Navigation Options (P1X Menu bar) 11.5.5
NDPS – Number of Decimal PlaceS for text skims 15.41.4
Network Aggregation – see Spider Web Networks
Network editing 11.9.1
Data field editing (global) 11.9.17
Networks: 2.3, 5
5120257 / Apr 15 24-15

Section 24
Index
Assignment network 5.5.1

Beginner's Guide to Coding 5.6
Buffer networks 5.2
Buffer data input 6.6
Data files; preparation of 6
Editing (PMAKE) 11.9, 18
Map networks 5.5.2
Network title 6.2
&OPTION records 6.1
&PARAM records 6.3
Simulation networks 5.1
Simulation data input 6.4
Aggregated (Spider Web) networks 15.56
Comparing two simulation networks 11.11.18
NFT 6.3.2, 8.5
NIPS 9.12.2, 15.31.4
NISTOP 9.1,2, 9.2.5
NITA 6.3.2, 7.1.5, 7.2.2
Low values of NITA 9.5.4
NITA_C (used under UFC109) 15.23.3
NITA_F 7.5.3.4
NITA_M 7.1.5, 9.5.1, 9.5.3, 9.5.4
NITA_S 15.23.4
NITS 6.3.2, 8.1.4, 8.3.2
NITS_M 8.1.4, 8.3.2
Nodes:
Buffer to Simulation Editing 11.9.12
Co-ordinates 6.8, 11.9.7
Editing Simulation Nodes 11.9.3
Graphical Display 11.12.3
Names 5.1.2
Numbers 5.1.2
Parameters 6.4.10
Simulation nodes 5.1.1
Simulation summary statistics by node 17.7
Alphanumeric names 5.1.2
Data base facilities within SATDB 11.10.5
List of standard data options App. I-3
NOMADS (Number of user classes) 6.3.2, 7.3
Non-Fatal Errors 2.9, App. L
NOPD 6.3.2
Normal Distribution: Stochastic Assignment 7.2.3
NOTUK 6.3.2, 15.7.1
NOXYC 5.1.6, 6.8
NO333C 6.6
NUC 6.3.2, 8.1.2, 15.15.2
NUCJT() 15.15.2
NUCMIN 6.3.2
NUSKIM (New algorithms for skimming in SATLOOK) 15.27.8
N2G Files (nodes to groups) 15.60.3
OBA – See Origin-based Assignment
5120257 / Apr 15 24-16

Section 24
Index
Objective function (assignment) 7.1.1

Offsets (at traffic signals) 6.4.3.4
Optimisation; see SATOFF and/or SIGOPT 11.9.13.1, 12.2, 15.31.6
Operating Systems (32-bit/64-bit) see Hardware / Soft-
ware Requirements
Order of Turns 6.4.8
Origin-based Assignment (OBA) 21.1.2, App.G
Use within VDM 7.4.5
Use with Warm Starts 22.5
Use with perturbation assignment 21.3.3
UFO files 21.4, 22.5.2
Output files (.otb, ont, .ost & .olg) 21.6
Splitting factors 22.5.2
OUT Profiles 8.1.3
P0: Signal Optimisation Policy 15.31.3
Parallel Operations 15.52
Parking Lots: zones 16.6.6, 20.5.3
Parking Charges 20.5.3
Park and Ride Cost Skims 10.8.4
PARTAN 6.3.1, 7.11.7
Application under SAVEIT 15.23.4
Reduction of Residual Flows 15.57.6
See also SPARTA
Path-based Assignment 21.1.1, App. H
Path-based perturbations 21.3.2
UFQ files 21.4
Path flows (SAVEIT assignment) 15.23.2
See also Route flows
PASSQ 6.1, 14.4.1, 17.3
PAUSE 19.12
P1X: 11.2
Alternative Device Output 11.3.2
Device parameters 11.3.4
Hard Copy Outputs 11.3.5
Highlighting errors 11.6.5.4
Input files 11.4.1
Link Annotation App I.1
Node Annotation App I.2
Output files 11.4.2
Pen/colour definitions 11.3.7
Plot display Definitions 11.6
Analysis Functions 11.8
Editing Facilities 11.9
Technical Specifications 11.16
Turn Annotation App I.3
Validation 11.7
Matrix Graphics 11.14
Node Graphics 11.12
Windowing 11.5
P1XDUMP 15.46.2
PCNEAR 6.3.3, 9.1
5120257 / Apr 15 24-17

Section 24
Index
PCU factors 4.2, 5.8.2, 15.9.4

PCX Files 11.3.6
.PS files 15.2.3
PCU’s 15.17
Pedestrian (Walk) Networks 15.45
Pedestrian/Pelican/Zebra 2-arm Crossings 6.4.3.6
Contribution to Link Speed-flow curves 6.4.12.3
Penalised links & turns 5.1.5, 6.7, 7.11.1
Inclusion within (skimmed) travel times 15.24.4, 15.27.7.1
See also Banned Turns
Perturbation Assignments 21.3, 22.2.6
See also Kick-Starts
PIJA Factors
From SATPIJA 13.2.1
Use in SATME2 13.1.1
Pinchpoint mid-link capacities 6.4.12, 6.4.12.1
PLFF3 15.5.4
PLOD 6.1, 14.4.4, 15.5
PMAX 6.3.3, 8.4.2
Plotters 11.3.5
PMAKE 18.1
Pollutants (Emissions) 15.32
POWER 6.3.3, 7.7.1
PPK 6.3.3, 6.11, 7.11.1
PPM 6.3.3, 6.11, 7.11.1
Preferences files 15.2
Pre-loaded Flow (PLOD) 14.4.4, 15.5
PLDFIL 6.1
Pre-loaded text data files 15.5.4
Pre-loaded bus flows 15.5.5
Printers 11.3.5
PRINT 6.3.1
PRINTF 6.3.1
Priority junctions:
Sample coding 16.3
Priority Markers 6.4.2
Priority Modifiers 6.4.2
Proportionality of Route Flows 15.27.8
PRSFD 6.3.1
Pseudo Link Cost-Flow Functions 7.7.3
Pseudo Link Objective Functions 7.7.4
Pushing in from give-way arms (CAPMIN) 8.2.3
Q105 8.4.7
Q Turn Priority markers 6.4.2, App. Q
QUEUE Profiles 8.1.3, 8.6.7
Display of queues 8.4.8
Transient queues 8.4.8
Random queues 8.6.5
QUEEN 6.3.1, 8.5
QUICK: Minimum CPU parameter settings 14.10, 15.55
QUIET: Running programs in Background 14.9, 15.55
5120257 / Apr 15 24-18

Section 24
Index
RAGS (Random delays At Give-way movementS) 6.3.1, 8.6.2

RANDC (Used in M5) App W.3
Random delays 8.6
As used with Blocking Back 8.6.6
Random queues 8.6.5
Random Numbers (KORN) 7.2.4
RBKS 8.7.2
Link values set in an X-File 6.13.4
RB106 (Roundabout modelling post 10.6) 8.7.3
Real Variables: Input Conventions 2.8.3
Rectangular Distribution (Stochastic Assignment) 7.2.3
REDMEN 6.3.1, 7.5.3.2, 7.5.6, 22.2.4
References App. C
REFFUB 6.3.1
Printing turning flows at buffer nodes 11.11.12
Relaxed convergence control parameters 7.4.5.3, 9.5.4, 15.54
Residual Frank-Wolfe path flows 15.57
RESTART 14.4.3, 15.4, 22.2.2
Restricted turns and/or links 5.1.5, 6.7
Resume Last P1X 11.4.4
Reverse directions link data 11.10.8.2
Right-hand drive (NOTUK) 15.7.2
.Rgs files (transferring signal settings) 11.9.14, 6.4.3.5
See also FREDDY 6.3.1
Output from P1X 11.9.2
Output from SIGOPT 15.31.6
Input to SATNET 6.4.3.5
Rivers (sets of lanes) 8.8.2, 8.9.3.4
Estuaries 8.6.3
Road User Charging 20
ROADIJ 6.3.4, 7.12
Roads 5.1.3
ROSIE: 6.3.1, 8.4.3
Wardrop Equilibrium under ROSIE 7.1.3
Roundabouts:
Modelling Assumptions 8.7
RBKS 6.13.2, 8.7.2
Sample coding 16.2
Saturation flows 6.4.7
With and without U-turns (Junction type 5 vrs 2) 5.1.1
Routes: See also Bus routes and (OD) paths
Fixed (Bus) Routes 6.9
“Other” Routes 6.9.4
Timing Points 6.9.5
Interpolation 15.18
Route flows 12.6
Uniqueness (within an assignment) 15.23.8
Proportional Route Flows 15.23.9
RSTOP; see also ISTOP 6.3.3, 9.1.2, 9.2.5, 9.2.6
RTP108 (Random delays by “estuary”) 8.6.3
Rule of a Half (Matrix calculations) 10.20.8
5120257 / Apr 15 24-19

Section 24
Index
Running Programs 3.4

SATALL 9, 9.7
BAT procedure 9.13
Continuation Runs 9.7, 9.12.1
Convergence Statistics 9.8, 9.9
Files 9.15.1
Control File Input 9.15.2
Running via SATURN 9.13
Multi-core operation 15.53.3.1
SATASS 7
SATBUF (Simulation to Buffer Networks) 15.8.2
SATCH: Cordoning 12.1
Data input 12.1.2
Files 12.1.2
Creating files with P1X 11.13, 12.1.4
SATCH_MC: Distributed processor version 12.1.6, 12.1.12, 15.53.3.6
Creating FCF files 12.1.11, 15.1.4
UFO or UFC 12.1.12
SATCCS (Simulation CCs to buffer format) 15.8.3
SATCOST 15.27.7
SATCOBA 15.42
SATDB: 11.10
Miscellaneous data inputs 11.10.6
Node Data Base 11.10.5
Technical Specification 11.18
SATDYSK (Dynamic Skims) 12.7
SATEASY: 7, 7.13
Control File 7.13.2
Convergence Measures 7.5.5
Files 7.13.1
File Structure 7.12.1
Running via BAT file 7.12.4
SATED: (Discontinued post 10.9) 11.12
Sat95key.dat; See SAT10KEY.dat App. Y
SATKK (Time Period Choice Modelling) App. V
SATLOOK: 11.11
Control Files 11.17.2
Files 11.17.1
Multi-core operation 15.53.3.2
SATMECC: SATURN Marginal Economic Consumer Costs 15.50
SATME2: 13, 13.6
Data Input 13.2.2
Files 13.6.1
Stacked MUC Matrices 13.4.4, 13.4.5, 13.4.6
Combined counts: Screenlines, cordons etc. 13.1.8
SATNET: 6
Data Inputs 6.1 to 6.11
Files 6.16
SATOFF: 12.2
Optimum offsets 12.2.1, 15.31.4
Files 12.2.3
5120257 / Apr 15 24-20

Section 24
Index
Optimisation within SATALL 9.12.2, 15.31.4

SATPIG: Dump Route Flows 12.6
SATRAP: Re-assignment to previous routes 11.10.7.4
SATPIJA 13.1.2
Control file 13.2.1
Technical Specifications 13.7
SATPIJA_MC: Multi-core operation 13.4.9, 13.7.3, 15.53.3.3
Text-based PIJA data (PIJAKP) 13.2.1
SATSIM: 8
Control File 8.10.2
Files 8.10.1
SATSTAT 15.49
SATSUMA 17.5
SATTIT.DAT 6.3.1, 15.21.1
SATTP (Running linked time periods with ps files) 17.4.2
SATTPX (Running linked time periods automatically) 17.4.3
SATTUBA 15.41
SATUFC – Re-creating .UFC files 15.23.5
SATUFO – Converting .UFC to .UFO files 15.23.7
SATUFO_MC – Multiple processor version 15.23.7, 15.53.3.7
SATU2 13.8
Saturation flows:
Roundabouts 6.4.7
Turns 6.4.6
SATURN:
8.1 App D.1
8.2 App D.2
8.3 App D.3
8.4 App D.4
9.1 App D.5
9.2 App D.6
9.3 App D.7
9.4 App D.8
9.5 App D.9
10.1 App D.10
10.2 App D.11
10.3 App D.12
10.4 App D.13
10.5 App D.13
10.6 App D-15
10.7 App D-16
10.8 App D-17
10.9 App D-18
11.1 App D-19
11.2 App D-20
11.3 App D-21
Procedure(s) 14.3, 9.14
Suite contents 1.5
SATWIN10 User Interface 3.7
SATWIN11 User Interface 3.8
5120257 / Apr 15 24-21

Section 24
Index
SAT10KEY.DAT App. Y
SAVEIT 6.3.1, 15.23.1
The (extra) SAVEIT Assignment 15.23.2
Accuracy of SAVEIT O-D routes 11.8.47, 15.23.2
Application of Aggregated (SPIDER) networks 15.56.5.3
SATALL parameter within continuation runs 9.12.1.1
SAVUFO 15.23.7, 22.5.7
Application of Aggregated (SPIDER) networks 15.56.5.3
SBT (Simulation Buffer Transformation) 15.1.7
Scatterplots (P1X) 11.7.1
Screen editing (Windows) 19.9
Implications for LOG and KEY files 14.5.9
Screen lines
Count Sets 6.10
Select Link Analysis 11.8.1.9
SDM (Simple or Separable Demand Models) 7.4.1
SECRET 6.4, 11.4.2.1
Sectors 5.1.7, 6.8, 10.2.5.3
Co-ordinates 6.8
Hierarchical definitions; see TFL and IROCKY 5.1.7
.Z2S files to convert zones to sectors 10.2.5.3, 10.5.1
Select Link Analysis (SLA) 11.8.1, 11.10.7.5, 15.19
Accuracy limitations of SLA 15.23.2
Select Link Matrices 11.8.1.3, 5.19
Bus Routes 11.8.4.2
Select Options for Matrices 10.6
Selected Area Matrix Factoring 10.7.1
Semi-Fatal Errors 2.9
Separable (and non-separable) cost-flow equations 7.1.3
Serious Warnings 2.9, App. L
SHANDY Option 6.3.1, 15.10
Shortest O-D paths: see Tree Building
Signals:
Coding example 16.1
Co-ordination 8.2.7
Filter lanes (Priority Marker F) 6.4.2.4
Intergreens 6.4.3
Minimum/maximum stage times 6.4.13
Offsets 6.4.3.4
Optimum offsets - see SATOFF 12.2, 11.9.13.1
Optimum stage times 11.9.13.1, 15.31.2
Optimisation at selected nodes 11.9.13.2, 15.31.6
Optimisation within SATALL 9.12.2, 15.31.4
Optimisation for improved convergence 9.5.1
Pedestrian Crossings
Percentage link green time (DA 1598) App I.1.1
.Rgs files of stage times 6.4.3.5, 11.9.14
Stages 6.4.3
SIGOPT: Signal Optimisation
Namelist Parameter 6.3.1, 9.12.2, 15.31.4
5120257 / Apr 15 24-22

Section 24
Index
Batch file to optimise all/selected signals 15.31.6

Simulation: 8
Cyclical flow profiles 8.1.1
Convergence (internal) 8.3, 9.9.4
Delays 8.4.1
Flow-delay curves 8.4.2
Linked time periods 17.3
Over-capacity junctions 17.1
Summary Statistics 11.11.4, 15.59, 17.8, 17.9
Time units 15.15.1
Simulation networks:
Bus-Only Roads 6.4.4
Centroid connectors 5.1.8, 6.5, 15.16
Conversion to buffer links (SATBUF) 15.8.2
Data input 6.4
Dummy nodes 5.1.1
Internal/external nodes 5.1.1
Junctions/nodes 5.1.1, 6.4.1
Link Speed Flow Curves 6.4.12
Node numbers 5.1.2
Restricted movements 5.1.5, 6.7
Roads/links: 5.1.3, 6.4.1
Signals 6.4.1
Summary statistics 11.11.4, 15.59, 17.8, 17.9
Turns: 5.1.4, 6.4.6
SIM109 8.3.4
SIM111 8.6.5
Single-keystroke responses 19.7
Entry in key files 14.5.2
Skimming Trees/Forests 15.27.2, 15.27.3
Min Cost vrs. Skimmed Cost 15.27.4
New algorithms post 10.9.17 (NUSKIM) 15.27.8
Uniqueness of skimmed times, distances etc. 15.23.8, 15.27.6
Use within Supply-Demand (VDM) Models 7.8.6
Skimmed Matrices (SATLOOK) 11.11.9
Skimming user-set variables (e.g., fuel consumption) 11.11.0
SKIM_ALL (aka SKIMALL) 15.27.7
SKIMDA 15.27.7
SKIMDIST 15.27.7
SKIMPEN 15.27.7
SKIMTIME 15.27.7
SKIMTOLL 15.27.7
SLA; See Select Link Analysis
SO (System Optimal) Assignment: SOWHAT / WHATHO 7.11.9
SPARSE (Trip Matrix Storage) 7.11.12
SPARTA (PARTAN + SAVEIT) 7.11.7, 15.23.4
Specimen network .dat file 6.12
Speed-flow curves:
Buffer links 5.4.1
Conventional forms 15.9.1
DTp curves 15.9.2
5120257 / Apr 15 24-23

Section 24
Index
COBA10 curves 15.9.3, 15.9.6

Default by Capacity Index 15.9.5
Best-fit Powers for Default DfT curves 15.9.3
Simulation links 6.4.12, 8.4.4
See also flow-delay curves
SPEEDS 6.3.1
Link Travel Times/Speeds 6.4.5
Spider Web Networks (Network Aggregation) 15.56
Applications to SLA 11.8.1.12
Eliminating duplicate links 15.56.5.1
Eliminating zero-flow links 15.56.5.3
Spigot Centroid Connectors (aka stubs) 5.1.8.1, 11.9.4.1, 15.56.2.3
Spines (P1X Cordons) 11.13.5
SATCH 12.1.4 (notes 6 and 7)
Spreadsheet outputs 11.10.9, 10.15
Stacked matrices 10.2.4, 10.17
STACK (matrix batch file) 10.20.11, 10.17
Stacked matrices 10.2.4
Stacking Capacities on Links 6.4.11
Convergence problems 8.5.7
Negative input values to “break” chains 5.1.12, 6.4.11, 8.5.5.4
Chain stacking capacities 8.5.5
Stage times (signals) 6.4.3.3
Minimum and Maximum green stage times 6.4.13
Start/W 14.11
Statistical Analysis of a matrix 10.9
Stochastic User Equilibrium (SUE) 7.2
Choice vrs. Wardrop 7.2.6
Convergence 7.2.5
STOLL: Stochastic Toll Charges 20.6
Stops: Primary and Secondary 15.34
STPCPU 9.2.3
STPGAP 9.2.3
Stub centroid connectors: See Spigot
Sub-files 15.30
SUBPQ within SATME2 13.1.4, 13.3.1, 13.4.8
Subscripted Namelist Variables 17.4.4, App. A, App. B
Successive Averages (Method of) 7.2.2, 7.4.4, 7.4.5
SUET 6.3.3, 7.2.3
User Class Value 6.11, 7.3.3
Suns (Independent simulation nodes) 8.3.5
Supply-Demand Equilibrium (see also VDM) 7.4.1
Convergence issues 7.8.6
SUZIE (Stochastic Assignment) 6.3.1, 7.2.2
SUZIEQ 6.3.1
System Optimal Assignment (SO) 7.11.9
Including simulation interactions (SATMECC) 15.50
System/Device Definitions 11.3
TAX 6.3.3, 6.4.2.2, 8.2.4
Link-specific values in an X-FILE 6.13.4
5120257 / Apr 15 24-24

Section 24
Index
Link-specific values on link records 6.4.14, 6.4.15

Zero TAX from late cut-offs 8.2.4.1
Coding extra lanes and/or flares 6.4.9.5
TDEL – Geometric delays 6.3.3, 8.4.1
Text Editors (Eg., Notepad) 2.8.2
Text files: dumping from SATDB 11.10.9
Text Menus 19.6
TFL (Transport for London numbering conventions) 5.1.7, 6.3.1, 11.11.4
Matrix applications 10.2.5.4, 10.4.4, 10.5.2
TIJMIN 6.3.3
Time vrs Distance Plots 11.7.2.3
Timing Points 6.9.5
Application under Validation 11.7.2.1
Time-flow curves See flow-delay curves
Time Period Definitions 17.3.3
Time Period Choice Models; see SATKK App. V
Tolls (see also Charges) 20
Using KNOB Files 15.14.4, 20.3
On Centroid Connectors (Wildcards) 15.14.5, 20.3
Stochastic tolls (STOLL) 20.6
Top Ten (Worst 10, Bottom 10 etc.)
Link Selection 11.6.1.1
Convergence Statistics 9.9.2, 11.15
O-D Routes 11.8.3.4
TOPUP (duplicate coded simulation nodes) 6.15.2
Traffic Boroughs:
Disaggregated Summary Stats 11.11.4, 15.59
Aggregates of nodes and/or zones 5.1.7.2, 10.2.5.4
Transient queues (maximum length) 8.4.8
Tree Building:
Link cost definition 15.24
Skimming trees/forests 15.27.2, 15.27.3
Stochastic 15.25
Trees v. forests 11.8.3, 15.26
To or from nodes and links 11.10.7.1
TRIBUT: See STOLL 20.6
Trip Length Distributions 10.12, 10.9.3
Within SATME2 13.3.11
Trip Matrices: 2.2
Creating a file using M1 4.1
Alternative M1 input formats 4.4
Factoring 10.7, 10.20.3
Negative cell values; see ERTM
.Trp files 11.13.7, 12.6.1
TUBA output/input files 15.41, 10.5.6
Formats 1, 2 and 3 10.5.6
Conversion to/from .UFM files 10.20.15, 10.20.16
Uniqueness of time, distance etc. matrices 15.41.1
TURBO (MUC matrices in SATME2) 13.4.6
Turns: 5.1.4
5120257 / Apr 15 24-25

Section 24
Index
Bus-Only 6.4.4
Counts 6.10
Order 6.4.8
Priority Markers (TPM) and Modifiers 6.4.2
Restricted 6.7
Saturation Flows 6.4.6
Two-way link data (summed 1-way data) 11.10.8.2
UF* files 3.3
UFC files; See also SAVEIT 15.23
UFC109: Alternative UFC Formats 15.23.3
SATUFC: Re-creating UFC files 15.23.5
Conversion to .UFO: SATUFO 15.23.7
UFC109/UFC111 6.3.2, 15.23.3
UFM2 … matrix .bat files 10.20.15
UFM(UN)STACK 10.20.17
UFO files 21.4, 22.5
Created under OBA 22.5.2
Created under Frank-Wolfe (SAVUFO/SATUFO) 22.5.3, 15.23.6, 15.23.7
Conversion to .UFC (SATUFC) 15.23.5
UFO + SPIDER 22.5.3
Use in SATCH 12.1.12
UFQ path files 21.4
UNCRTS: Assignment convergence stopping parameter 7.1.5, 9.5.4
UNIQUE: 15.48
Uniqueness of Wardrop Equilibrium Solutions 7.1.6
Route Flows 15.23.8
Skimmed matrices 15.27.6
Univariate Analysis of a matrix 10.11.1
“Unstack” a matrix 10.17
UK and non-UK use (NOTUK) 15.7.1
UNCRTS 6.3.3, 7.1.5, 9.2.3, 15.23.4
Changes under AUTONA 9.5.4(4)
UNSTACK (Matrix batch file) 10.17, 10.20.12
UPBUS 6.9.2
Application to joy rides 11.7.2.2
Application to timed routes 6.9.4, 6.9.5
UPDATE 14.4.2, 15.3, 22.2.1
UPFILE 6.1, 14.4.2
Upstream entry/exit flows 15.16.2
User Classes 5.8.1
Names (UCNAME) 6.3.4
Actual Flows 15.21.4
User Interfaces
See SATWIN10/11 3.7, 3.8
USESPI 15.27.7.2, 15.27.7.3
Within P1X SLA 11.8.1.12, 15.56.7.2
USEUFO 15.23.6, 15.27.7.3
Within SATPIJA 13.3.14
Within SATCH 12.1.12
U-turns: At internal simulation nodes 5.1.4
At external simulation nodes 18.9.1, 16.6.2, 16.6.3
5120257 / Apr 15 24-26

Section 24
Index
ILOVEU 18.9.2
In bus routes 6.9.2, note 10)
V-records under 33333; maximum speed by veh class 6.6(16), 15.47.3
Validation 11.7
Counts 11.7.1
Travel Time Routes 11.7.2
Variable Demand Models 7.4
Variable Program Dimensions 15.28
Variational Inequalities 9.2
VCPCU (PCU factors by vehicle class) 6.3.3, 15.17.2
VDM (Variable Demand Models; see also Supply-Demand) 7.4.1
External Loops with SATURN (Cobweb) 7.4.5
VDU files 3.3, 11.1.3
Change the VDU mode 14.5.6
Vehicle Classes 5.8.2
By user class 6.11
Names (VCNAME) 6.3.4
PCU Factors (VCPCU) 6.3.3, 15.17.2
Updating trip matrices 13.4.6
Vertical editing of network data fields 11.9.17
W-markers: See Weave Priority and/or Weaving on Motorways
WAIT (Parallel operations) 15.52
Walking Networks 15.45
Wardrop Equilibrium 7.1
Choice vrs. Stochastic 7.2.6
Delta Function for measuring success 7.1.4
MSA 7.2.2, 7.11.8
PARTAN variation 7.11.7
ROSIE option 7.1.3
Stopping criteria 7.1.5
Uniqueness 7.1.6
Warm Starts (WSTART/IPERT) 21.3, 22.3
Altered Networks and/or Matrices 22.5
Identical Networks 22.4
With Elastic Assignment 22.6
Warnings 2.9, App.L
Weave Priority Markers (W) at a single junction 6.4.2.5, 15.40.7
Weaving on Motorways (between junctions) 6.4.9.4, 15.40
Using Network Aggregation 15.56.7
WHATHO (See also SOWHAT) 7.11.9
WIDDLE 7.11.16
Wildcard entries on KNOB Files 15.14.5.2
Defining tolls on centroid connectors 20.3
Windows (screen editing) 19.9, 19.10
Windows Operating Systems, see Hardware / Soft-
ware Requirements
WINDY 6.3.1
Word Processors 2.8.3
Worst converged nodes, routes etc; see Top Ten
5120257 / Apr 15 24-27

Section 24
Index
WRIGHT 6.12.2, App. L

WSTART – See Warm Starts 6.1, 21.3, 22.3
XCCSK (Exclude Centroid Connectors in Skims; SATTUBA) 15.41.5, 15.27.7
XCL files: Extended Command Lines 14.8
X priority markers 6.4.2.2
X-Files 6.13
X,Y Co-ordinates; see Co-ordinates
XFSTOP 6.3.3, 7.1.5
XY sub-files 11.9.7
Output from P1X 11.4.2
XYB files (for .bmp images) 15.43.1
XYFORM 6.3.4, 6.8
XYUNIT 6.3.3, 6.8
Corrected by SHANDY 15.10.2
Y merges 6.4.2.3, 8.8.3.1, 8.8.4.4
Yellow boxes 8.5.3
Zebra crossings – see Pedestrian Crossings
ZILCH (Allowing zero trip matrices) 9.12.13
Zipped (.ufm) files 10.2.1
Zones/Centroids 5.1.6
Alphanumeric names 5.1.6
Co-Ordinates of zones 6.8
Sequential Numbers and Names 10.2.2
Z2G files: Zones to groups 10.2.5.5, 10.4.4, 10.16.4
Filename conventions 10.2.6, 15.60.2
Z2S files: Zones to sectors 10.2.5.3, 10.5.2, App W.3
5120257 / Apr 15 24-28

Section 24
Index
JOB NUMBER: 5120257 DOCUMENT REF: Section 24 Index.doc
10.9.17 Web release – Jun10 DVV NP IW IW 22/06/10
5120257 / Apr 15 24-29

Section 24

SATURN v11.3.12 Manual (Main) PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SATURN v11.3.12 Manual (Main) PDF

Încărcat de

Drepturi de autor:

Formate disponibile

SATURN MANUAL (V11.

Manual - Version 11.3

5.4 Capacity Restraint in the Buffer Network 5-16

5120257 / Apr 15 iii

8.5 Blocking Back 8-29

10.20 Useful Matrix Batch Files 10-54

14.1 Introduction to Control Procedures / Command Lines 14-1

15.33 Determining Emission Statistics 15-84

5120257 / Apr 15 vii

17.6 The Definition and Calculation of Queues and Delays 17-11

5120257 / Apr 15 viii

21.1 Network Data Structures 21-1

5120257 / Apr 15 1-1

Post release 10.9, SATURN includes options to carry out Origin-based

5120257 / Apr 15 1-2

♦ fully interactive analysis of results, including on-line help files

♦ optimum green splits for traffic signals

♦ traffic signal co-ordination modelled

♦ lane structure of intersections and choice of lane modelled

♦ the growth and decay of queues modelled quasi - dynamically

♦ facilities to “skim”, e.g., inter-zonal time, distance, etc. matrices

♦ bus routes, bus-only roads and bus-only lanes included explicitly

♦ both left-hand and right-hand drive accepted

♦ selected link analysis

♦ multiple User Class Assignment differentiating between, e.g., cars, taxis,

♦ full analysis of O-D routes generated by the assignment

♦ network and trip matrix cordoning for sub-areas.

♦ a SATURN to Tuba interface module (SATTUBA) to assist in the economic

♦ modelling tolls or road charges on specified links; and

1.2 Hardware / Software Requirements

5120257 / Apr 15 1-3

♦ Core2Duo processor (2.6GHz or faster)

1.2.1 64-bit Operating Systems

5120257 / Apr 15 1-4

1.4 Distribution of SATURN

5120257 / Apr 15 1-5

1.5 Contents of the Suite

5120257 / Apr 15 1-6

1.6 Version Control

JOB NUMBER: 5120257 DOCUMENT REF : Section 1.doc

Revision Purpose / Description

Originated Checked Reviewed Authorised Date

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

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

10.9.22 Web release – Dec 10 DVV AG IW IW 06/12/10

10.9.24 SATURN v10.9 Release (Full) DVV AG IW IW 06/05/11

11.1.09 SATURN v11.1 Release (Full) DVV AG IW IW 31/03/12

11.2.01 SATURN v11.2 Beta Release DVV JS IW IW 07/12/12

11.2.05 SATURN v11.2 Release (Full) DVV JS IW IW 17/03/13

11.3.03 SATURN v11.3 Release DVV EN IW IW 28/03/14

11.3.07 SATURN v11.3.07 Release DVV DAS IW IW 26/09/14

11.3.10 SATURN v11.3.10 Release DVV DAS IW IW 22/01/15

11.3.12 SATURN v11.3.12 Release DVV DAS IW IW 20/04/15

5120257 / Apr 15 1-7

The SATURN Suite – An Overview

2. The SATURN Suite – An Overview

2.1 The Structure of Assignment Models

5120257 / Apr 15 2-1

The SATURN Suite – An Overview

Figure 2.1 General Structure of an Assignment Model

♦ errors in the trip matrix,

♦ errors in the network specification,

♦ errors in the route choice model specification (e.g., the definition of