SATURN v11.2.05 Manual (All)

Simulation and
Assignment of
Traffic in
Urban
Road
Networks
Manual - Version 11.2

March 2013
Version 11.2.05
SATURN MANUAL (V11.2)
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-2
2.2 Trip Matrices in SATURN 2-4
2.3 Networks in SATURN 2-5
2.4 Route Choice in SATURN 2-6
2.5 Analysis in SATURN 2-7
2.6 General Advice on Using SATURN 2-7
2.7 Getting Started; Example Files 2-8
2.8 Text Files, Fixed Columns, Text Editors and Word Processors 2-9
2.9 Errors and Warnings: Fatal, Non-Fatal and Serious 2-11
3. The Basic SATURN Model 3-1
3.1 The Network Model Structure 3-2
3.2 Data Requirements 3-5
3.3 File Name Conventions 3-6
3.4 32-Bit SATURN Versions 3-8
3.5 Running Programs Under DOS (or Command Prompt) 3-9
3.6 Running Programs under WINDOWS: SATWIN 10 3-9
3.7 Using SATWIN 11 Beta 3-27
4. Creating an Origin-Destination Matrix File 4-1
4.1 Trip Matrices using M1 or MXM1 4-2
4.2 Important Trip Matrix Definitions 4-4
4.3 Further Notes on Trip Matrices 4-5
4.4 Alternative Matrix Formats using M1/ MXM1 4-6
5. Network Coding – A General Description 5-1
5.1 Simulation Networks 5-2
5.2 Buffer Networks 5-15
5.3 Defining the Buffer Network 5-16
5.4 Capacity Restraint in the Buffer Network 5-17
5.5 Assignment and Map Networks 5-18
5109341 / Mar 13 i
Master Main Document.docx
Contents
5.6 Building Networks: The Beginner's Guide 5-22

5.7 Geographical Information System (GIS) Data 5-27
5.8 User and Vehicle Classes 5-32
6. Preparation of a Network Data File 6-1
6.1 Option Specification Records (Mandatory) 6-3
6.2 Network Title (Mandatory) 6-5
6.3 Parameter Specification Records (Mandatory) 6-6
6.4 Simulation Network: the ‘11111’ Records 6-25
6.5 Simulation Centroid Connector Data: the ‘22222’ Records 6-53
6.6 The Buffer Network/Link Data: the ‘33333’ Records 6-54
6.7 Restricted Turns and Links: the ‘44444’ Records 6-56
6.8 Node and Zone Co-ordinates/Supplementary Data: the ‘55555’ Records 6-58
6.9 Fixed Routes (E.g. Buses): the ‘66666’ Records 6-60
6.10 Counts of Link and/or Turning Volumes: the ‘77777’ Records 6-66
6.11 Generalised Costs and/or Matrix Weights for Multiple User Classes: the ‘88888’ Records 6-67
6.12 Fatal Errors and NAFF UFN Files 6-70
6.13 Extra Input Network File: the X-File 6-72
6.14 Specimen File 6-74
6.15 FIFO, TOPUP and DOUBLE – Options for Repeated Data Input 6-76
6.16 SATNET Files 6-79
7. Assignment – The Role of SATEASY/SATALL 7-1
7.1 Wardrop Equilibrium Assignment 7-2
7.2 Stochastic User Equilibrium (SUE) Assignment 7-10
7.3 Multiple User Class Assignment 7-16
7.4 Joint Equilibrium Assignment and Variable Demand Models 7-19
7.5 SDM Assignment: 7-31
7.6 More Complex Elastic Assignment Models 7-44
7.7 Elastic Demand Functional Forms 7-50
7.8 Defining the Reference Trip and Cost Matrices 7-56
7.9 Multiple User Class Elastic Assignment 7-66
7.10 Combined Distribution and Assignment Models 7-67
7.11 Miscellaneous Assignment Procedures 7-70
7.12 Running SATEASY: A single elastic run 7-81
7.13 SATEASY: Technical Specifications 7-84
8. Simulation – The Role of SATSIM 8-1
8.1 Cyclical Flow Profiles 8-2
8.2 Accept Profiles and Capacities 8-6
8.3 Internal Simulation Iterations and Convergence 8-14
8.4 Simulation Delays, Queues and Flow-Delay Curves 8-17
8.5 Blocking Back 8-29
8.6 Random Delays and Queues (LRTP) 8-37
5109341 / Mar 13 ii
Contents
8.7 Modelling Roundabouts 8-41

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

Contents
11. P1X: Interactive Analysis of Results 11-1

11.1 Introduction 11-2
11.2 Network Plotting (P1X): The Master Menu 11-2
11.3 System/device Definitions 11-3
11.4 P1X External File Control 11-10
11.5 The Network Window 11-13
11.6 Basic Network Display 11-17
11.7 Validation Options 11-38
11.8 P1X Analysis Functions 11-43
11.9 P1X Editing Facilities 11-57
11.10 SATDB: Data Base Facilities 11-75
11.11 SATLOOK: Interactive Text Outputs 11-96
11.12 Node Editing and Graphical Display (SATED) 11-103
11.13 Graphical Network Cordoning 11-107
11.14 Pure Matrix Graphics 11-110
11.15 Convergence Statistics 11-111
11.16 P1X: Technical Specifications 11-111
11.17 SATLOOK: Technical Specifications 11-112
11.18 SATDB: Technical Specification 11-113
12. Supplementary Programs 12-1
12.1 Network Cordoning (SATCH) 12-2
12.2 Optimum Offsets (SATOFF) 12-14
12.3 Direct Examination of UF Files (DALOOK) 12-18
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-2
13.2 Matrix Estimation Data Requirements 13-17
13.3 Advice on Using SATME2 and Extra Options 13-27
13.4 Updating Multiple User Class O-D Matrices 13-40
13.5 SATME2 Technical Specifications 13-47
13.6 SATPIJA - Technical Specifications 13-49
13.7 SATU2 - Selected Link Matrices 13-51
13.8 “ME2” Output Files 13-52
14. Control Procedures (DOS Batch Files) 14-1
14.1 Introduction to Control Procedures / Command Lines 14-2
14.2 File Specification within Control Procedures 14-3
14.3 The ‘SATURN’ Procedures 14-6
5109341 / Mar 13 iv
Contents
14.4 Extended SATURN Procedures 14-7

14.5 “LOG”, “KEY” and “VDU” Files: Running Interactive Programs “Off-line” 14-9
14.6 Namelist Parameters Set on the Command Line 14-20
14.7 Command Line Options and Batch Procedures 14-20
14.8 Extended Command Line Files: Using .XCL Files 14-21
14.9 QUIET Command Lines 14-22
14.10 QUICK Command Lines 14-22
14.11 Create Your Own BATCH Files: A Beginners’ Guide 14-23
15. Special Options and Facilities 15-1
15.1 Network Aggregation and Simplification within Intermediate Bands 15-3
15.2 Preferences files 15-8
15.3 Network Updates (The Update Option) 15-9
15.4 Updating the Trip Matrix (The Re-start Facility) 15-10
15.5 Pre-Loading Fixed Flows (The “Plod” Option) 15-12
15.6 Comparing Assigned and Observed Flows: GEH Statistics 15-14
15.7 Use of SATURN Outside the U.K. 15-16
15.8 Using SATURN as a Conventional Assignment Model 15-17
15.9 Converting Conventional Speed-Flow Curves into SATURN Curves 15-20
15.10 The use of Crow-Fly Distances (The SHANDY Option) 15-29
15.11 Coding Combined Buffer and Simulation Networks 15-30
15.12 Automatic Network Coding (The AUTOX and AUTOZ Options) 15-31
15.13 Supplementary Data for Simulation Links Using Buffer Network Inputs 15-33
15.14 Extra Link Data (Knobs) 15-34
15.15 Node-Dependent Parameters: GAP, GAPM, NUC and LCY 15-38
15.16 Simulation Link Flows and Centroid Connectors 15-41
15.17 Pcu’s, Cars, Buses and Vehicles 15-42
15.18 Interpolating Routes 15-43
15.19 Select Link Analysis (SLA) 15-44
15.20 The Dutch Option (Long Node Numbers) 15-45
15.21 Referencing Data Arrays Via Dirck Access Codes 15-47
15.22 Choice of Gap Parameters 15-49
15.23 Re-constructing Assignment Routes: The SAVEIT Option and UFC Files 15-50
15.24 Alternative Link Costs and/or Times for Tree Building 15-60
15.25 Stochastic Trees 15-63
15.26 Trees, Forests and Arboreta 15-64
15.27 Skimming Trees and/or Forests 15-64
15.28 Variable Program Dimensions 15-75
15.29 Comment Cards and Blank Records in Data Files 15-76
15.30 The Use of Sub-Files within Data Files: $INCLUDE 15-76
15.31 Setting “Optimum” Stage Green Times 15-78
15.32 Determining Fuel Consumption 15-84
15.33 Determining Emission Statistics 15-85
15.34 Estimating Primary and Secondary Stops 15-87
15.35 Altered Data Formats in .DAT Input Files 15-87
5109341 / Mar 13 v
Contents
15.36 Turning Flows at Buffer Nodes 15-88

15.37 Repeated Assignments: Modelling Cold Starts, etc. 15-89
15.38 Non-discontinuous Speed-Flow Curves: the Kinky Option 15-89
15.39 Bus-only Lanes 15-90
15.40 Motorway Weaving Segments 15-92
15.41 SATTUBA 15-99
15.42 SATCOBA 15-103
15.43 Bitmaps within SATURN 15-108
15.44 Defining Bus Travel Times 15-113
15.45 Representing Walk / Pedestrian Networks 15-113
15.46 DBDUMP: Dumping Link Data to Text Files 15-114
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-120
15.50 SATMECC – Marginal Economic Consumer Costs 15-130
15.51 Running SATURN within DIADEM 15-135
15.52 Running SATURN in Parallel 15-136
15.53 SATURN Multi-Core Applications 15-139
15.54 SATURN CASSINI 15-145
15.55 QUIET & QUICK Options via SATWIN 15-153
15.56 Network Aggregation (SPIDER) 15-154
15.57 Residual (Incorrect) Path Flows and Restricted Frank-Wolfe Algorithms 15-167
15.58 Error Listing Files 15-170
16. Simulation Network Coding Example 16-1
16.1 Traffic Signals 16-2
16.2 Roundabouts 16-4
16.3 Priority Junctions 16-6
16.4 External Nodes 16-8
16.5 Dummy Nodes 16-8
16.6 Simulation Centroid Connectors 16-10
16.7 Motorway Links 16-14
17. Multiple Time Period Modelling in SATURN 17-0
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
17.6 The Definition and Calculation of Queues and Delays 17-11
17.7 Junction-based Summary Statistics 17-14
17.8 Network-based Simulation Summary Statistic 17-1
17.9 Combined Simulation and Buffer Total Statistics 17-3
17.10 Delay-based Arrays in .ufs Files: Definitions 17-5
5109341 / Mar 13 vi
Contents
17.11 Formulae for Calculating Totals 17-6

18. Network Structure and Editing: PMAKE 18-1
18.1 Network data base structures 18-2
18.2 Network Editing 18-4
18.3 PMAKE - Network Building from Scratch 18-7
18.4 PMAKE: Editing Existing Networks 18-9
18.5 Node Editing within PMAKE 18-9
18.6 Link Editing within PMAKE 18-12
18.7 Simulation Centroid Connector Editing within PMAKE (11.9.4) 18-14
18.8 Capacity Indices on “New” Links 18-14
18.9 U-Turns at External Simulation Nodes 18-15
18.10 Disconnected Assignment Networks 18-17
19. Running SATURN Programs Interactively 19-1
19.2 Graphics and Text Mode 19-2
19.3 Menus 19-2
19.4 Banner Menus 19-4
19.5 Menu Bars (P1X only) 19-5
19.6 Text Menus 19-6
19.7 Windows List Boxes 19-7
19.8 Setting Variables 19-7
19.9 Windows Screen Edit and Edit Box Inputs 19-8
19.10 Output Text Windows 19-8
19.11 The Help Facility 19-8
19.12 Mouse-based Inputs 19-9
20. Modelling Road User Charges in SATURN 20-1
20.2 The Role of Tolls in SATURN Modelling 20-2
20.3 Input of Charges (Tolls) in SATURN 20-3
20.4 Calculating and Reporting Charge/Toll Statistics 20-6
20.5 Examples of Charging Systems in SATURN 20-7
20.6 STOLL: Modelling Stochastic Values of Times of Tolls 20-8
21. Alternative Network Data Structures and Assignment Methods: Origin Based
(OBA) and Path Based Assignment 21-1
21.1 Network Data Structures 21-2
21.2 Advantages and Disadvantages of OBA and Paths 21-3
21.3 Perturbation Assignment (WSTART and/or IPERT) 21-4
21.4 Storing Path Files: UFO and UFQ 21-6
21.5 Practical Restrictions within SATURN 21-6
5109341 / Mar 13 vii

Contents
21.6 Additional OBA Output Files 21-7

21.7 Practical Considerations 21-8
21.8 Examples of OBA Applications 21-9
21.9 Further Information 21-11
22. Kick Starts: Updating, Warm Starts and Continuation Techniques 22-1
22.1 Introduction to Kick Starts 22-2
22.2 Review of Traditional Kick Start Options 22-3
22.3 Warm Starts (WSTART = T) 22-5
22.4 WSTART with Topologically Identical Networks and Matrices 22-7
22.5 WSTART with Altered Networks and/or Matrices: UFO Files 22-8
22.6 Warm Starts with Elastic Assignment 22-13
22.7 Advantages of Kick-Starts 22-13
23. Linking SATURN and Geographical Information Systems (GIS) 23-1
23.2 Exporting SATURN data to GIS Systems 23-2
23.3 Importing data from GIS Systems into SATURN 23-3
23.4 The Atkins MapInfo Tools 23-3
23.5 SATURN GIS Creator 23-22
24. INDEX 24-1
5109341 / Mar 13 viii

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 1981. 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 t o 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 6000 links in the standard PC version, 37500 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 t rip 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 or indeed using the DRACULA micro-
simulation with routes generated by SATURN.
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 t heoretically consistent modelling frameworks and c onvergent
algorithms reflecting the academic background of SATURN’s development.
5109341 / Mar 13 1-1

11_2_05_Section 1.docx
Introduction
Releases of “major” updates to SATURN occur on a r oughly annual basis (see

Section 1.6 below for a list); the latest release, 11.2, first became generally
available in November 2012.
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 s creen and/or to build networks from scratch on t he screen. T he
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 r elated fashion SATURN may be appl ied to the analysis of network-based
data which need not be in any way related to traffic assignment problems. Fo r
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 pur ely traffic assignment package with a fixed
user-defined trip matrix SATURN now also provides a num ber of standard
modelling steps for matrix estimation, e.g. modal split and distribution. T hese
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
5109341 / Mar 13 1-2

Introduction
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
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 r un on a w ide range of platforms including
mainframe computers, workstations and m icros 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) 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 i ssue and l arge-memory
5109341 / Mar 13 1-3

Introduction
high-speed machines are recommended). A typical lower-range specification for

a system to run SATURN 11.2 would include:
♦ 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. Un til
the release of Windows 7, 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 t hey will produce the same results. T he 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 (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.
5109341 / Mar 13 1-4

Introduction
We will continue to explore the migration of the computational intensive elements

of the SATURN suite into 64-bit IVF over the coming months.
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 pr ovided by the User Manual alone which is
available in both word processed and printed copy available through Atkins
Transport Planning and i ncluded on t he SATURN Installation CD as standard
Adobe PDF documents. T hey may also be downloaded from the SATURN
website:
♦ http://www.saturnsoftware.co.uk; or
♦ see Appendix C for a l ist of various relevant publications and bac kground
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 i s 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 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:
Ian Wright
SATURN Product Director
Atkins Limited,
Epsom Gateway, Woodcote Grove, Ashley Road, Epsom KT18 5BW
or call: Ian Wright, Epsom +44 (0) 1372-756272 or, alternatively, via e-mail at
saturnsoftware@atkinsglobal.com.
5109341 / Mar 13 1-5

Introduction
1.5 Contents of the Suite

As supplied to pc users on a s et 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.
5109341 / Mar 13 1-6

Introduction
1.6 Version Control
JOB NUMBER: 5109341 DOCUMENT REF : Section 1.doc
Revision Purpose / Description
Originated Checked Reviewed Authorised Date
1 Re-formatted (Final to DVV) TF / BG NS IW IW 06/05/06
3 Upgrade to V2 Template IW 22/06/06
3.2 Web Release – Sept 06 DVV NP IW IW 08/09/06
3.3 Web Release – Jan 07 DVV NP IW IW 04/01/07
3.4 SATURN v10.7 Release DVV NP IW IW 12/03/07
3.5 Web Release – Jul 07 DVV NP IW IW 19/07/07
3.7 Web Release – Jul 08 DVV NP IW IW 07/07/08
3.8 Web release – Dec 08 DVV NP IW IW 12/12/08
3.8.21 Web release – Feb 09 DVV NP IW IW 16/02/09
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. Release (Full) DVV JS IW IW 17/03/13
5109341 / Mar 13 1-7

The SATURN Suite – An Overview
2. The SATURN Suite – An Overview
Mini-Contents Page
2. The SATURN Suite – An Overview 2-0

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
5109341 / Mar 13 2-0

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 s lightly more user-friendly intro to SATURN than
meeting the documentation “cold”. E qually reading an ar ticle such as that in
Traffic Engineering and Control, 1980 (see reference 1 i n Appendix C) may
provide an easier starting point.
Alternatively there are a number of introductory SATURN courses available within
the UK, including ones run by the Institute for Transport Studies and
independently by Atkins; details available from Dirck Van Vliet (DVV) or Ian Wright
(IW) as appropriate.
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 t he “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.
5109341 / Mar 13 2-1

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 i mportant 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 errors (i) to (iii) 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 t o minimise problems of convergence.) Clearly the
5109341 / Mar 13 2-2

programs should - and do - assist users to minimise input errors, while the users
should choose the appropriate options within the assignment routines.
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 der ived 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 v alidated base
year matrix. A gain 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. T he elastic assignment
5109341 / Mar 13 2-3

options (see Sections 7.4 and beyond) also allow the basic assignment function
within SATURN to be i nterfaced with more general demand models such that
SATURN can include, e.g., modal split or distribution facilities.
However for most users the creation of a t rip 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 o f the properties that distinguishes 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:
5109341 / Mar 13 2-4

♦ 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
♦ 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
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. Y ou 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 l ot 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. H owever the user will still have several important
decisions to make; e.g
5109341 / Mar 13 2-5

♦ whether to use an “equilibrium” or “stochastic” framework;
♦ how to define “cost”
♦ how many iterations, etc, to allow

Details on the options available and the theoretical background to the choices
available are contained in Section 7 o f the Manual. I t 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 w ealth 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 t o 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 t heir
5109341 / Mar 13 2-6

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 PIX and remember to use
the “Help Facilities” with these programs.
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 nu mber 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 s tandard 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 t he functions of the above programs may be found elsewhere in the
manual.
5109341 / Mar 13 2-7

Please note however that the Epsom98net file is NOT intended as an illustration
of good coding practice; merely an ex ample 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.
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 par ticular 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 no t be explicitly input as a z ero 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 t he screen. U nfortunately, such
characters are virtually always misinterpreted by a FO RTRAN read statement,
5109341 / Mar 13 2-8

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).
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 f ixed range of
columns, that it is written as an integer (i.e., without a dec imal), 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.
5109341 / Mar 13 2-9

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 t herefore, 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
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 i n 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 c orrected before continuing, and al l non-fatal
errors should at least be t horoughly checked and c onfirmed that they are
deliberate.
5109341 / Mar 13 2-10

Certain Non-Fatal Errors (plus certain Serious Warnings – see below) are
optionally upgraded to Semi-Fatal status if a ne twork parameter WRIGHT is set
equal to T. This convention is strongly recommended. See Section 6.12.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. T he 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 c ount of the number of each category of errors detected per
simulation node i s included in the uf* files and may be di splayed as part of the
node print outs or node graphics. Fo r information on w hich error numbers are
which please see Appendix L (or, less conveniently, list the file SATTIT.DAT).
5109341 / Mar 13 2-11

2.10 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: Section 2.doc
3.1 Update Figure 2.1 IW 13/07/06
3.2 Web release – Sept 06 DVV NP IW IW 08/09/06
3.3 Web release – Jan 07 DVV NP IW IW 04/01/07
3.4 SATURN v10.7 Release DVV NP IW iW 12/03/07
3.5 Web release – Jul 07 DVV NP IW IW 19/07/07
3.8.22 Web release – Jun 09 DVV NP IW IW 16/06/09
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
5109341 / Mar 13 2-12

The Basic SATURN Model
3. The Basic SATURN Model
Mini-Contents Page
3. The Basic SATURN Model 3-0

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-7
3.5 Running Programs Under DOS (or Command Prompt) 3-8
3.6 Running Programs under WINDOWS: SATWIN 10 3-8
3.7 Using SATWIN 11 Beta 3-26
5109341 / Mar 13 3-0

INTRODUCTION
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 whi ch are concerned with getting traffic flows onto the network, and the
last four more generally with the analysis of loaded networks.
Originally each “functio n” was con tained within a single program or module.
However in more recent versions (9.3 and beyond) the basic “fun ctions” 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 networ k 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 tra ffic on the b asis 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 ena bles a deta iled 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 ba se analysis program SATDB which allows a n essentially free-

format manipulation and display of data.
Figure 3.1 and Figure 3.2 illustra te 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 indicat ed. Section
3.3 describes the file name conventions.
How to create the trip matrix file to b e assigned, trips.ufm in Figure 3.1 and Figure
3.2, is dealt with in Section 4.
5109341 / Mar 13 3-1

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 assignme nt and sim ulation 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 lo op is dictat ed by the procedure used: SATURN and
SATURN9 use SATALL, SATURN8 uses the explicit loop. See Sections 9.1 and
14.3.
SATNET checks al l input data, outputs error messages and sets up t he internal
structural networks as required by (a ) the simulation and (b) the assignment. The
precise structure of these networks or of the .u f* files which are passe d 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 o f the simula tion 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 ap propriate routes through the network for each
element in the trip matrix, bearing in mind relationships bet ween travel time an d
flow as determined by the simulatio n. By defau lt the model uses an ‘e quilibrium’
technique based on an optimum c ombination of all-or-not hing 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 dela ys 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 relationship s, in pract ice it is found to be bette r 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., netwo rks coded without any simulation
network (see 5.3), it is not nece ssary to run the simulation, in which case
convergence is reached by running the assign ment once and procee ding directly
to the analysis programs.
Apart from the iterative loops between the simulation and assignment stages there
are also int ernal iterative loops within both stages which need to converge .
Generally speaking users should allow a su fficient number of internal iterations
5109341 / Mar 13 3-2

(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 exa mine output
from the assignment or simulation using interactive commands.
In addition PIX/PMAKE also provides for on-line network editing. While not
shown in Figure 3.1 there are two “feedback” loops from PIX. Firstly, a new
network data file suitable for input to SATNET may be produced by PIX by editing
existing network files. Secondly an edited ver sion of the .ufs file may also be
produced and fed directly back to SATALL.
In older versions of SATURN (Figure 3.1) the analysis fun ctions of P1X were
contained in four separate programs, P1, SATLOOK, SATDB and SATED. The
latter three still exist as distinct pro grams and in certain sit uations are best run in
that mode rather than within P1X.
Figure 3.1 – Running the Basic Saturn Model using SATALL; the current methodology
5109341 / Mar 13 3-3

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

The input data to be p repared 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 spee d, number of lanes, st acking capacity
(optional);
d) Turn data - a saturation flow, lanes available, a priority marker indicat ing
give ways, etc;
5109341 / Mar 13 3-4

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

Thus all dat a input, with the exception of satu ration flows which require some
degree of “ engineering judgment”, are well d efined 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 containe d (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 cre ation 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 b e classified in a numb er 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 con siderably 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 n etwork/matrix/etc., and the extension indicate s
the process/program which has produced that particular file.
Thus a network “named” LIVNET might spawn a number of file s with extensions
such as LPA denoting the Line Printer output from the Assignment, UFS indicating
* As far as the normal us er is concerned the essential difference between text and binary files is
that a text fil e 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 pro gram. 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!
5109341 / Mar 13 3-5

the “Unformatted” output from th e 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 co ntaining a list of all termi nal 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 e xtensions “LP-” with the third let ter/number
indicating the program that produced it as follows:
LPN SATNET
LPA SATEASY
LPS SATSIM
LPT SATALL
LPL SATLOOK
LPG SATPIG
LPP P1X
LPD SATDB
LPM SATME2
5109341 / Mar 13 3-6

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 th e user on input. They are also
frequently used as a convenient shorthand to refer to files; e.g., the “LPN file”
would imply the lin e printer file produced by SATNET, a “DAT” file implies a
control file prepared by the user, etc. “UF files” refer in general t o all UF*
unformatted files, while UFA/S refers to eithe r 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 ina ccessible 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 “pa thname” associated with it. Thus th e file net3.ufs on your
working directory may h ave the full name c:\SATURN\NEWTOWN\2005\net3.ufs.
In certain circumstances net3.ufs (or even net3 i f SATURN expects the extension
.ufs) may be enough to identify it; in other circumstances the full pathname may
be required.
SATURN binary files st ore both filenames and pathnames and use both when
trying to open files.
Path/filenames may contain up to 256 characte rs. (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 bey ond are sp ecifically designed for 32-bit applications an d
may be run using the SATWIN Windows front-end program. Note, h owever that
5109341 / Mar 13 3-7

the 32-bit versions may also be run under Command Prompt which may be
accessed through SATWIN.
The following two sections describ e the two alternative methods in somewhat
general terms.
3.5 Running Programs Under DOS (or Command Prompt)

In order to r un one program - or a linked set of programs - it is necessa ry for the
user to specify: (a) the program(s) and (b) the files to be used. Thus for e very
individual program in th e 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 t he 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 prin ter output file
above would be LIVNET.LPL.
Note that simply t yping 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 t hat 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, t he procedure SATCOST (15.27.4) uses the
program SATLOOK in order to produce a matrix of o-d costs. Similarly th ere 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 proced ures 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 tot ally off-line or batch mo de. In addition the user may then
create their own “supe r-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).
Full instructions for running both styles of batch procedures are found in Section
14.
3.6 Running Programs under WINDOWS: SATWIN 10

This section shows you how to install SATURN and, briefly, how to run t he latest
version via SATWIN 10, SATURN Ten’s User-friendly Interface.
SATURN 11.1 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 t his respect. As a consequence, t he latest
5109341 / Mar 13 3-8

release builds on a stro ng 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.2 load the CD and, if the CD does not auto-ru n the install
process, double-click on:
Setup.exe
You will be led through a series of install scree ns 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 SATWIN 10 under
\Program files\ rather th an the default \satwin folder. This, and indeed installation
under any f older containing a space, was pr eviously prohibited but this limitation
has now been corrected.
However, once a su itable home has been ch osen, program executables and
assorted DLLs, bat and control files, help and PDF-based documentation will be
automatically installed on your hard disk. You can t hen run SATURN as
previously from a Command prompt (rememberi ng 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 SATWIN 10 which can be accessed t hrough 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 SATWI N 10 is launched, the
dialog box below will a ppear, enabling you to select the v ersion to use in the
current session.
5109341 / Mar 13 3-9

3.6.2 SATWIN 10
SATWIN 10 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
5109341 / Mar 13 3-10

The File menu is used to exit from SATWIN, for consistency with other Windows-based
software.
3.6.2.1.1 SATWIN 10 and Windows NT/2000/XP/Vista/7

If SATWIN 10 is launched on a Windows NT (or later) when logged in as a user
without write-access to the drive where SATWIN is insta lled, the follo wing error
could occur:
Run-time error 75 - Path/File access error
SATWIN 10 normally creates and updates some ASCII text files d uring use;
consequently, it needs to be able to write to the drive where it is in stalled 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 fold er where SATWIN 10 is installed as well as "Working
Folders" or log in as administrator.
3.6.2.2 Setting Folders

The Settings menu is used to select four standard folders where SAT URN files
are stored
 the “working folder”,
 the “Program folder” where the .exe and .bat files etc. are stored,
5109341 / Mar 13 3-11

 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 choi ce. Any later changes made are “remembered”
by SATWIN 10 the next time you use it.
The latter t hree folders probably n ever need to be re-set once they h ave been
initialised for your installation. However the first “working” f older, which defines
the folder from where, by default, current data files are selected, ten ds to be
changed frequently as users shift be tween different projects. The current working
folder is displayed on the main SATWIN 10 screen at all times.
3.6.2.3 Running a Single Module

From the main screen (see below), select Module Run using the mous e, 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 t he module SATURN (which runs
SATNET followed by SATALL), the template allows you t he basic selection of a
network .dat file and a matrix .ufm file as below plus, optionally, UPDATE and/or
PASSQ files.
5109341 / Mar 13 3-12

Once files have been selected, click on Run and the module execut es. Upon
completion you have t he option t o 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 e nter Edit mode.
Note that th is is not the same as d ouble-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 h ighlight 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 comma nd you can Double-click it, click the Run Ite ms(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).
5109341 / Mar 13 3-13

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 a nd SATNET v10.8.22 from
“Program Folder” C:\SATWIN\XEXES 1.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 en try 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 comma nds issued within
SATWIN will use data files and SATURN modules from the respective folders.
You can ch ange “Working Folder” and “Program Folder” at any time via the
Settings/Folders menu option.
3.6.2.4 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 don e using the ’Batch Run Setup’ Dialog box as
shown below.
5109341 / Mar 13 3-14

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 butt on 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 wit h the “Modu le Help” button provide additional supporting
information on that module.
After setting the module parameters, the command line will be display ed in the
editable batch file contents box. Further modules may be manually add ed to the
batch file contents text box.
The ‘Run’ b utton will start the the module(s) in the batch file contents text bo x
whilst the ‘Save’ button will save the contents to a batch file for later re-use. The
5109341 / Mar 13 3-15

‘Edit’ button will open the batch file in Notepa d and the ‘ Clear’ button to re move
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.6.2.5 Running from Command Line

This is perh aps the ne arest equivalent to run ning 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 t he 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 support ed DOS co mmands, 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 co nceal the
help box. Pressing the F2 key after selecting a com mand will display the
command’s help information in a separate Help dialog bo x. You can press the
up/down arrow keys on the keyboard to step t hrough previous commands if th e
cursor is on the comma nd entry bo x or use th e ‘Previous Commands’ button to
display the list of previously used commands.
3.6.2.6 Running the Test Network

Possibly the first thing you would want to do on loading SATURN and SATWIN 10
would be to run the test network.
Choosing a test network from the T est Network menu pres ents you with the Test
Run Template below corresponding to the network.
Test Network 1 will ru n MXM1 to build trip matrix HAT, followed b y SATNET,
SATALL and P1X for network HEADE, leavin g you in P1X interactive mode.
5109341 / Mar 13 3-16

Upon exit from P1X, the following screen will allow you to view any of the LP f iles
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.6.2.7 Other Tools

SATWIN also allows access to Notepad editor or a command line promp t through
the toolbar as below.
If the full or demo version of DRACULA is in cluded with SATURN, the menu
option DRACWIN will appear on the SATWIN menu bar (see ab ove). This
provides access to DRACULA through its front-end program DRACWIN.
3.6.3 Other Features OF SATWIN 10
3.6.3.1 Quick Access to Modules

SATURN modules (or other modules for PT-SATURN and DRACULA if installed)
may be accessed by right-clicking on the event log.
5109341 / Mar 13 3-17

3.6.3.2 Selective Deletion of Event Log Runs
When several runs are displayed on the event log, you can delete sele cted runs.
The options are availab le to remo ve all commands in the log or a set of cursor
selected commands. Individual commands can also be deselected as above.
3.6.3.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 select ion 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.6.3.4 Changing Working Folder

Double-click the Working Folder display bar to change fold ers. You can also type
in or copy and paste a folder in the folder display bar.
5109341 / Mar 13 3-18

3.6.3.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 viewin g LP files through SATWIN. The
editor can be accessed through the Tools menu
3.6.3.6 Saturn Manual

An Index to and Individual Chapters from the SATURN User Guide can also be
accessed directly from SATWIN.
3.6.3.7 An Integrated Front End

SATWIN 10 from version 10.3 of SATURN has also been designed to perform as
an integrated front-end for a range of transport planning software including not
only SATURN, but also DRACULA and PT-SATURN. The DRACULA
Demonstration is now in tegrated with the release of SATURN and access to th e
full program will be thr ough SATWIN 10. Similarly, PT-SATURN modules will
execute in the same way as those from SATURN.
3.6.3.8 SATURN Version Information

SATURN version infor mation can be found on the bottom left of SATWIN 10
window as illustrated below.
5109341 / Mar 13 3-19

Detailed SATURN version information (shown in the dialog box below) is available
through “SATURN Versi on Info” from the Help menu or by double-clicking the
version information area indicated above.
5109341 / Mar 13 3-20

If the user wishes to Detailed SATURN version information (shown in the dialog
box below) is available through “SATURN Versi on Info” from the Help menu or b y
double-clicking the version information area indicated above.
If “Version Unknown” appears in th e selection box, SATWIN 10 was u nable to
identify the specific version (eg a version of SATURN pre viously installed under
the XEXES directory).
The reference to the “SATURN Version Unknown” ma y be removed by the user

by:
 Determining the SATURN version and level in use. Thi s may be readily
achieved by viewing an y 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.V ER”, 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”
5109341 / Mar 13 3-21

3.6.3.9 Using Other Programs from SATURN DOS Command Shell

Access to other non-SATURN (user) programs from the SATURN DOS Command
Shell is possible by sp ecifying the full paths containing the user programs via
“SATURN DOS Command Shell Paths” from the Settings menu.
This will br ing up the dialog box below. You can add p aths 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.
5109341 / Mar 13 3-22

3.6.4 Recent Event Log Commands

You can access the previous 15 commands issued on the Events Log via the File
menu.
The list can be cleare d via the “Settings/Cle ar Recent Command List” menu
option
5109341 / Mar 13 3-23

3.6.5 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 Eve ntLog” from the File menu. Th e
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 comman ds, load an Events Lo g file via “File/Open
Eventlog File” menu option or drag and drop the file onto the Events Log.
3.6.6 SATURN File Associations

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

file association
5109341 / Mar 13 3-24

Screen shot of a “Wor king Folder” C:\SATWIN\TEST in Windows Explorer with

SATURN file association.
5109341 / Mar 13 3-25

LIV10L.UFS for exa mple is describ ed as “SAT URN Loaded network b inary 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.7 Using SATWIN 11 Beta

SATWIN 11 provides an updated f ront end for SATURN, replacing the existing
time honoured SATWIN10 application.
SATWIN 11 enables the user to undertake the following tasks:
 Easily access and discover categories of mod ules, e.g. Matrix Manipu lation
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 th e ‘Model
Complex’.
3.7.1 The ‘Model Complex

A Model Complex can be saved, reopened and shared.
The Model Complex ke eps track o f the user’s working fo lders, the SATURN
version and their own t ool folders (specifically batch files created by the user) a s
well as keeping a log of the commands that have been e xecuted 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 t he session will be saved in a last session log file that can
be opened next time SATWIN 11 is used. Th is file is overwritten every time
SATWIN is closed.
5109341 / Mar 13 3-26

3.7.1.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 se ssion (using th e auto saved session model complex
from the previous use)
2) Open the last used Mod el Complex (will be different to above option if t he
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 th e next SATWIN session where it
was left on last exit. This will mean that the quick start menu is not displ ayed. This
setting can be changed in the Tools tab.
3.7.1.2 Setting Folders and Properties for the Model Complex

The user may specify a name and a description for their Model Complex
5109341 / Mar 13 3-27

The Settings menu is a lso used to select two standard fold ers 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 installa tion routine either by default or by
explicit choice. Any late r changes made are “remembered ” by SATWIN 11 the
next time it is used.
The current working folder is disp layed on the main SATWIN 11 screen at all
times as is the current SATURN version.
3.7.1.3 Running a Single Module

From the ‘Home’ tab, click SATURN to start tha t specific module or alternatively
use the Search box on the Home tab to find the module to be run:
5109341 / Mar 13 3-28

A new module-specific template will be displayed allowing the user to select the
necessary files. For e xample, if the module SATURN (which runs SATNET
followed by SATALL) is selected, the template enables t he user to select the
network .dat file and a matrix .uf m 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 ha s 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 ma y be changed – select the Tools  User Interface  Clear
Parameters check box. To clear the parameters, click the reset button.
5109341 / Mar 13 3-29

All the Module Parameter forms have an experimental (!) feedback button allowing
the user to share their ideas with th e SATURN developmen t team via email. All
the feedback received will assist in the development of the future releases.
Upon completion of the module, the user has th e option to view the output LP file
or to run further modules.
The user may need to refresh the file list befo re the newly created L P files are
available. To view the selected file in the user-d efined text editor, click Show. To
review the errors in the Error Manager, click the exclamation icon.
3.7.1.4 Using the Command Log View to re-launch commands

The user may also run modules directly from th e Command Log viewer by double
clicking an existing command in the list
To enter the Edit mode, right click o n the Command Log entry  Edit Copy or 
Edit Task Description & Command Parameters. Then t ype a new co mmand or
edit the existing command and press OK
The image above for examples shows the following:
5109341 / Mar 13 3-30

 The current ’Working Folder’ is C:\Program Files (x86)\Atkins\S ATWIN

11.XX\Test; and
 The first command ‘SATNET Epsom98Net’ uses the Epso m98Net.DAT data
file from current Working Folder and the versio n of SAT NET in the c urrent
Program Folder.
The user may change the ’Working Folder’ and ’Program Folder’ at any time via
the Folder Settings menu option.
3.7.1.5 Running the Test Network

Once the initial in stallation has been completed, the user may wish to r un one of
the SATURN test networks. The T est networks are locate d 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.7.1.6 Other Tools

SATWIN 11 also allows access to Notepad e ditor or a command line prompt
through the toolbar as below.
3.7.2 Other SATWIN 11 Features
3.7.2.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.7.2.2 Changing Working Folder

To change the working folder, click t he Browse button next to the Working Folder
display bar to Change t he 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 ena ble the use r to move through
previously used paths - this is a good example where it m akes 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.7.2.3 Setting the Preferred Text Editor

By default, SATWIN 11 uses Notepad to view S ATURN LP files but the user may
specify a different default editor by clicking Set Default Editor from the Settings
menu. The default ed itor is u sed automatically when vie wing LP file s through
SATWIN 11. The default editor may also be accessed through the Tools tab.
5109341 / Mar 13 3-31

3.7.2.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 ind ividual sections and appendices. The latest
documents may also be viewed online via the Support tab too.
3.7.2.5 SATURN Version Information

SATURN version infor mation can be found ju st under wo rking folder display as
illustrated below.
More detailed information about the SATURN version (as shown in the dialog box
below) is available eith er through Support tab  Support Info  SATURN
Version Info or by hovering the mou se over the SATURN Version in the settings
panel.
5109341 / Mar 13 3-32

If the selection box states Version Unknown’, SATWIN 11 was unable to identify
the specific version (e. g. a versio n of SAT URN 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 t he executables. The SATURN Version and Level in
use will always be repo rted at the top of the t ext 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.7.2.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 t he User programs via
SATURN Command Shell Paths from the Tools tab. Once selected, t he dialog
box will en able the user to add e xtra path(s) containing other programs to be
used. The y may be added to the Additional User Programmes Paths area by
selecting the path(s) via the ’Browse ...’ button.
3.7.3 Saving the Events Log Commands for Re-use

Command(s) in the Events Log are a 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 comman ds, load an Events Log file via the ’File/Open
Eventlog File’ menu option or drag and drop the file onto the Events Log.
5109341 / Mar 13 3-33

3.8 Version Control
3 Upgrade to V2 Templates IW 22/06/06
3.1 Update Figure 3.1/2 IW 13/07/06
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
5109341 / Mar 13 3-34

Creating an Origin-Destination Matrix File
4. Creating an Origin-Destination Matrix File
Mini-Contents Page
4. Creating an Origin-Destination Matrix File 4-0

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
5109341 / Mar 13 4-0

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 t o create it from
observed link flows. T he “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 t o 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
5109341 / Mar 13 4-1

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 ex ample of an i nput 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. T his record defines the matrix as a t rip 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 t o 14 des tinations, 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.
5109341 / Mar 13 4-2

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 s eparate 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.
5109341 / Mar 13 4-3

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 al tered 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. S imilar 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 par ticular 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 t ry 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.
5109341 / Mar 13 4-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.
5109341 / Mar 13 4-5

4.5 Version Control
5109341 / Mar 13 4-6

Network Coding – A General Description
5. Network Coding – A General Description
Mini-Contents Page
5. Network Coding – A General Description 5-0

5.1 Simulation Networks 5-1
5.2 Buffer Networks 5-14
5.3 Defining the Buffer Network 5-15
5.4 Capacity Restraint in the Buffer Network 5-16
5.5 Assignment and Map Networks 5-17
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
5109341 / Mar 13 5-0

INTRODUCTION
Section 2.3 introduced the distinction between simulation and buf fer networks.
Section 5.1 following gives further information on how simulation networks are
specified, 5.2, 5.3 and 5 .4 carry out a s imilar 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 s elf-explanatory and i ncludes
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 w ithout delay.
Basically they represent a ‘quick-and-dirty’ node coding and THEIR USE IS NOT
TO BE 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.
They are also often used to indicate intermediate points on c urved links (a
previous recommendation) but the use of the GIS files (see 5.7) to describe link
shapes is highly preferable.
5109341 / Mar 13 5-1

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 c ordon 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 s peed-flow curve is strongly
recommended. (On the other land “in-bound” simulation links from an ex ternal
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 no t be s trictly 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.
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
5109341 / Mar 13 5-2

(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”. T hese 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. H owever 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 c apacity 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
(or counter-clockwise starting with the first turn to the right for drive on the right -
see Section 15.7.2).
5109341 / Mar 13 5-3

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 t herefore 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 bu ffer 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 m inor road giving way to the major arms at priority junctions, are
indicated by a s eries of ‘priority markers’. T he degree to which these turns are
impeded depends on bot h the ‘major’ flow and t he ‘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
only”; i.e. buses following fixed routes may use these turns/links but the vehicles
which are assigned routes within the assignment may not.
5109341 / Mar 13 5-4

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 pe nalty 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 de fined 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 l inks 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 t he 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 z ones may have the same numbers; i.e., you may define a z one 15
and a node 15 w ithout 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 o ver-ridden by the network inputs. T hus 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.
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
5109341 / Mar 13 5-5

55555 data records is a zone or a node and therefore the value defined in
&PARAM must be correct in the first place.
Zone numbers may normally have up to 5 digits (i.e., be numbered up to 99999)
although the use of 5 di gits 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 c ontained within 5 c olumns (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 ac cepted 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 de fined on t he 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 m atrix 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 s equential 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 di fferent “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 g iven 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. S ee Section 5.7 for general details and
Appendix Z for specific format details.
5109341 / Mar 13 5-6

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 and/or Traffic Boroughs (TfL rules)

A further optional level of zonal definition, “sectors” which are aggregates of
zones, was introduced with SATURN 8.2. A lthough the number and h ence 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 d efault). 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 de fined 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. N ote
here that, e.g., zone 50 would be in sector 0.
Otherwise the correspondence may be e xplicitly 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 ex plicitly 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 c onfused; this practice is not recommended and g enerates 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.
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) then the hierarchical rules used in Transport for London net works 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. Similar
rules apply to node nu mbers with 5 or more digits. (It is assumed that if a
zone/node has less than 5 di gits then the TfL rules do no t apply and t hat
zone/node would be allocated to borough/sector 0.)
5109341 / Mar 13 5-7

We further note that traffic borough numbers are grouped together in sets of two,
i.e., node/zone numbers 10xxx and 11xxx are both in the same borough, as are
12xxx and 13xxx, 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. etc.
In general traffic boroughs should be geographically “self-contained” in that nodes
in any particular borough should: (a) only be c onnected to other nodes in the
same borough or (b), if they lie on t he 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 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.
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.
Centroid connectors are uni-directional so that, for example, two connections
would be nec essary to represent vehicles parking on bo th sides of a l ink. 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 ex ception 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. E xamples 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 s ingle 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.
5109341 / Mar 13 5-8

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 t o an ( extra) internal node c reated 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 t he simulation link are more unambiguously defined (see 15.16). The
disadvantage is that it requires two extra simulation nodes to be de fined, with
consequent increases in RAM and c pu 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 ov erly sophisticated. I.e., connect to links; there are lots of other
issues to worry about in network coding.
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. T he 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. T he 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.
5109341 / Mar 13 5-9

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 di splayed and which suppressed. Equally they may be us ed 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. I t may also be def ined 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 i nput 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”.
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 Ordinance 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
5109341 / Mar 13 5-10

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 us ed to provide a bac kground 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 l ess 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.
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 i nto 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
5109341 / Mar 13 5-11

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 d elays 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 s ingle delay on one l ink 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 ar ms?) while externals would also not be permitted for reasons of
geometry.
There can be m ore 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.
Figure 5.2(c) illustrates a 2-way link into a r oundabout which, near the point of
entry, has been s plit into two short one-way links to represent the physical
separation of the entry and ex it points at the roundabout. In this case Z-B-A
represents a chain as does R-B-Z.
5109341 / Mar 13 5-12

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 s et 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.
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 c onsistently
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
5109341 / Mar 13 5-13

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 m uch 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 t hought of as a dou ghnut with the
simulation network in the middle. The essential difference is that the simulation
network has both junction and l ink 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 t hen to cordon off a sub-matrix of trips for the central area and t o
“simulate” this network. Apart from obvious problems with differences between
the two networks this method can be bot h time consuming and c omplex. T he
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
properties of junctions are relatively unimportant. S ection 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 pedes trianised area. I n 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 ex ternal node
(representing, for example, a c ar park) through a s ection 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.
5109341 / Mar 13 5-14

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
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 j oint simulation/buffer network; further useful
information is contained in Section 15.11.
5109341 / Mar 13 5-15

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). T he 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 n + t0 + B (V − C ) / C
= 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 c onstant worked out by the program equal to one hal f the time
period being modelled.
(Numerically: B = 30*LTP where LTP is in minutes and B in seconds.)
(But see 15.38 for an o ption 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
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 pow er curve. T hus the travel times input should include the
times to traverse the junction at the end of each link in addition to the link travel
5109341 / Mar 13 5-16

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 l ink in the buffer network has been as signed 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 dang er 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 p roblem 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
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
5109341 / Mar 13 5-17

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 buf fer
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.
5109341 / Mar 13 5-18

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”.
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 s imple 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)

while each map link joins two map nodes. They therefore correspond to the
“lines” plotted on a PIX network and r epresent roads and c entroid 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
5109341 / Mar 13 5-19

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 pos sible/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 f urther 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 t here is no
interaction between the two. For example, buses on bus-only links do not make
any call on t he modelled link capacities nor do they affect link travel times,
whereas other bus flows (and, indeed, all other fixed flows) do. S ee 15.39 for
further details.
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.,
5109341 / Mar 13 5-20

“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 l ack 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 w arning message 47 onl y
since a lack of connectivity may simply be due t o one-way streets and/or banned
turns although they may sometimes be s ymptomatic of more serious coding
problems.
Under (b) SATNET attempts to build a pa th 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 per mitted 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 t urns 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 net work and a t rip 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? H ere 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
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 l inks 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.
5109341 / Mar 13 5-21

Happily, there is now an eas ier alternative using P1X, which allows the user to
input network detail through a graphical editor on t he screen and to see the
network develop progressively. Although a s ingle 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 as ked 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 s ingle 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 t he Zone op tion 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 abl e 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
delete and change link directions. Splitting links is possible from both link and
node sub-menus.
5109341 / Mar 13 5-22

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.
5109341 / Mar 13 5-23

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 p rocess 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 s ignalised 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
5109341 / Mar 13 5-24

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 f aced 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 s aturation
flows. Where links or turns are involved, the active one i s always shown
highlighted on the junction plan in centre-screen, as shown below.
When complete, Quit and Save the node dat a (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.
5109341 / Mar 13 5-25

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 S imulation) and s plit 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 i nput the necessary changes to
ensure its correct functioning, from turn allocation to lanes to signal phases and
timings.
Centroid connectors may also be c hanged 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 i ncluded,
for example, in network plots. Thus GIS files describe both “topological” data
such as political boundaries, geographical features such as rivers, railway lines,
stations, etc. and “text” data such as names to be associated with nodes or links.
* 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.
5109341 / Mar 13 5-26

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 num ber 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 par tly so as to be accessible for matrix
applications).
Data sets (a) to (d) have certain “characteristics” associated with them. Thus they
have a c hoice of colour, areas can be i n-filled or not, lines can have a w idth
(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 s ize and colours. A nd of course all of them have spatial
coordinates. All of these are set by the user on the GIS file.
5109341 / Mar 13 5-27

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 t he file automatically. A lternatively 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 c reated 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 v ery good idea, particularly when a l ot 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.
5109341 / Mar 13 5-28

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 c losed loop are
individually defined as arcs with the same centre of curvature so that the closed
loop is plotted as a c ircle. 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.
5109341 / Mar 13 5-29

When curved links are created interactively within P1X three options are provided:
poly-lines, (single) arcs and circles.
5109341 / Mar 13 5-30

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 t axis would be different classes if there were taxi-only links. M UC
assignment is therefore the problem of assigning a nu mber 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 s ingle 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 c haracter) 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 ar e unrelated to the driver characteristics. E xamples would be
petrol cars, diesel cars, heavy lorries (HGVs), single-decker buses etc. C ars
driven by, e.g. time minimisers and di stance minimisers would be t he same
vehicle class although different user classes.
5109341 / Mar 13 5-31

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 m ultiple user
classes may be as signed to the same vehicle class. For example, if a u ser has
defined 5 user classes – say, cars (resident), cars (non-resident), taxis, LGVs and
HGVs then it might be natural to define 3 v ehicle classes where class 1 would
include both car user classes plus taxis, class 2 w ould 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 us ed 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 t herefore 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 as sumes, 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
5109341 / Mar 13 5-32

5.9 Version Control
JOB NUMBER: 5109341 DOCUMENT REF : Section 5.doc
2 DVV Changes
3 Upgrade to v2 Template 22/06/06
3.5 Web release – Jul07 DVV NP IW IW 19/07/07
3.7 Web release – Jul08 DVV NP IW IW 07/07/08
5109341 / Mar 13 5-33

Preparation of a Network Data File
6. Preparation of a Network Data File
Mini-Contents Page
6. Preparation of a Network Data File 6-0

6.1 Option Specification Records (Mandatory) 6-2
6.2 Network Title (Mandatory) 6-4
6.3 Parameter Specification Records (Mandatory) 6-5
6.4 Simulation Network: the ‘11111’ Records 6-24
6.5 Simulation Centroid Connector Data: the ‘22222’ Records 6-52
6.6 The Buffer Network/Link Data: the ‘33333’ Records 6-53
6.7 Restricted Turns and Links: the ‘44444’ Records 6-55
6.8 Node and Zone Co-ordinates/Supplementary Data: the ‘55555’ Records 6-57
6.9 Fixed Routes (E.g. Buses): the ‘66666’ Records 6-59
6.10 Counts of Link and/or Turning Volumes: the ‘77777’ Records 6-65
6.11 Generalised Costs and/or Matrix Weights for Multiple User Classes: the ‘88888’ Records 6-66
6.12 Fatal Errors and NAFF UFN Files 6-69
6.13 Extra Input Network File: the X-File 6-71
6.14 Specimen File 6-73
6.15 FIFO, TOPUP and DOUBLE – Options for Repeated Data Input 6-75
6.16 SATNET Files 6-78
5109341 / Mar 13 6-0

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 s egments, 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 i n numerical
order. The exceptions are segment 6, bus routes, and s egment 7, link counts,
which may appear more than once (but with the obvious proviso that all such
segments appear together and in the correct order).
Segments 6 and 7 al so differ from all others in that a “ title” may be i ncluded
following the opening 66666 or 77777 text; see 6.9.3 and note (3), 6.10.
5109341 / Mar 13 6-1

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. Fo r
example link capacity indices or link-specific parameters such as TAX may be
defined in this way. T he data which may be a dded 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). A lthough not used directly by SATNET if present it is
read in and c hecked 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.
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.
* Each "line" of the input file is referred to as a "record".

5109341 / Mar 13 6-2
Note that repeated variables (i.e., the same name is defined more than once)
generate semi-fatal errors since it is not clear which of the two (or more)
definitions is the correct one.
The following parameters may be defined by &OPTION; the first eight of which are
all LOGICAL and default to .FALSE., the last set are all character variables
(mostly file names) which default to “blank”:
TRUE if a new network is being built which is very similar to a

previous network, in which case the previous network will be used
UPDATE to provide good initial estimate of flow-delay parameters. N.B. If
you wish to set WSTART = T then UPDATE should also be set to
T. See Sections 15.3 and 22.3.
TRUE if queues are to be passed over from a previous time period.

PASSQ
See Section 17.3.
If TRUE the assigned flows from an i nput SATURN UF file are

PLOD
“Pre- LOaDed” as fixed flows onto this network. See Section 15.5.
If TRUE the pre-load data file uses free or CSV formats. S ee

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

PLFF3 as opposed to a turn for a free format pre-load data file. See
Section 15.5.4.
If TRUE the assignment uses a “ Warm Start” on i ts first

WSTART assignment. N.B. If WSTART = T then UPDATE should also = T.
See Sections 21.3 and 22.3.
If TRUE and t he file named under UPFILE does not exist then
DIADEM setting either UPDATE or WSTART to T does not result in a semi-
fatal error. See 15.51.
If TRUE the internal CASSINI steps to over-ride various settings

within SATNET are invoked. See 15.54 and 15.54.6.1 for a full list
of the Namelist variables which may be ov er-written. N.B. (Note
CASINI
that the variable name CASINI has only a single S in order to
confirm with the rule that all namelist variables have to have 6 or
fewer characters.)
The name of the network (.ufs) file which is to be used under the
UPFILE
UPDATE and/or WSTART options. See 15.3 and 21.3.
The name of the network (.ufs) file which is to be used under the
PQFILE
PASSQ option. See 17.3.
FILPLD The name of the network (.ufs) file which is to be “pre-loaded”. See
5109341 / Mar 13 6-3

15.5
FILERL The name of the input .ERL file used to monitor errors. See 15.58.
The name of the CASSINI Control file defining the convergence strategy
FILCAS
to be applied. See 15.54.6.
The name of the ASCII CSV file reporting the convergence of the demand
FILGAP
model. See 15.54.6
The CASSINI file which specifies the type of demand model used and
CASTXT the file format (and other operations) that CASSINI will expect. See
15.54.6.
Thus the OPTION records might be specified by the following set of records which
explicitly sets UPDATE to .TRUE., PASSQ to .FALSE. and, by default, PLOD to
.FALSE.:
&OPTION
UPDATE=T,
PASSQ=F,
UPFILE = ‘LASTNET.UFS’
&END
For users preparing a new network file the default values set for all of these
parameters are those required and therefore we need not be concerned with them
at this stage. Thus you need only include a ‘null’ namelist record:
&OPTION
&END
Note that both UPDATE and PASSQ allow initial estimates of the cost-flow curves
to be ex tracted 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 def ined as required by
UPDATE/PASSQ and they cannot both be the same file.
6.2 Network Title (Mandatory)

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

6.3 Parameter Specification Records (Mandatory)

These records set user-defined model parameters for this run using the
FORTRAN namelist facility as described above for the OPTION records, the one
difference being that the namelist ‘name’ is &PARAM instead of &OPTION. See
Appendix A.
Some of the parameters defined here are used in the network build stage, others
are relevant to the (later) simulation or assignment stages; the latter are set here
and passed to the relevant programs via the SATURN UFS/A files (where they
may be re-set). In certain cases therefore full documentation is deferred to later
sections with appropriate pointers being given here.
Note that repeated variables (i.e., the same name is defined more than once)
generate semi-fatal errors since it is not clear which of the two (or more)
definitions is the correct one.
The parameters are grouped under LOGICAL, INTEGER, REAL and
CHARACTER variables and listed in alphabetical order.
The default values set are generally “good” choices. H owever 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 s et. These are indicated by an al ternative
“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 us ed to refer, to, e.g., a p articular 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 pa rameter 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
5109341 / Mar 13 6-5

6.3.1 Logical Parameters

AMY If TRUE all assignments are carried out with “fixed” travel times
corresponding to free flow travel with no s peed changes. S ee Section
7.11.4.
Default – FALSE
ASHORT If TRUE assignment statistics by iterations are given in a table in the
output line printer files rather than (at length) per iteration.
Default – TRUE
ATLAS If TRUE all nodes in the 55555 data section are included in the map
network whether or not they are connected to links. See 18.5.2 and note
(9), 6-8.
Default - FALSE
AUTNUC If TRUE values of NUC are set automatically for certain junctions. See
15.15.2
Default – TRUE. (.FALSE. prior to 10.9)
AUTOK If TRUE any “Kombi” averaging of flows during the assignment–
simulation loops is controlled AUTOmatically. See Section 9.3.1.
AUTONA If TRUE “optimum” values of NITA and/or UNCRTS are calculated at
each separate assignment within SATALL. See Section 9.5.4.
Default – .TRUE. (.FALSE. prior to 10.9)
AUTOX If TRUE any uncoded external simulation nodes are automatically coded
using the best available data. See Section 15.12.
Default – TRUE
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 f ile 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.
5109341 / Mar 13 6-6

Default - .FALSE.
CLIMAX(n) If .TRUE> for user class n any input values of CLICKS represent a fixed
maximum speed rather than a fixed time penalty. See 15.47.3.
Default – FALSE
COMPAS If TRUE links from a common buffer node are sorted so that they appear
in the listings in clockwise order (counter–clockwise if LEFTDR=F).
Default - .FALSE
CROWCC If TRUE buffer centroid connectors with an input distance of zero are
replaced by a crow-fly distance. See 15.10.3.
Default - .FALSE.
DCSV If TRUE default speed-flow curves under 33333 ( see 6.6 and 15.9.5)
may be defined as free format (CSV) rather than fixed columns.
Default - .FALSE.
DIDDLE If TRUE each assignment after the first commences with the final set of
flows from the previous assignment; if FALSE it starts with an all-or-
nothing load. See 9.4.
Default - .TRUE.
DOUBLE If TRUE and TOPUP = T certain rules for “over-writing” data apply. See
6.15.3.
Default - .TRUE.
DUTCH If TRUE node numbers in the buffer network may have up to 8 digits,
otherwise they are limited to 5. (N.B. If TRUE certain input formats
throughout the Suite are altered – see Section 15.20.)
Default - .FALSE.
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!) I f TRUE the bus route data on t he 66666
data records (see 6.9.2) are in “free format”; if FALSE they are in fixed
5109341 / Mar 13 6-7

column format.
Default - .FALSE.
FIFO If TRUE, if and when a data item appears twice, the first data entry is
discarded and the last one used; if FALSE the first entry is always used.
See 6.15.
Default - .TRUE.
FOZZY If TRUE the program will try to “interpolate” unconnected nodes in bus
routes. See Sections 6.9.2 and 15.18
Default - .FALSE. (RECOMMENDED .TRUE.)
FREDDY If TRUE an out put .rgs file containing a l isting 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 66666 records (i.e. X,
Y co-ordinates) are input as “free format”; see 6.8.
Default - .FALSE.
FREE77 If TRUE counts under 77777 are read as free format. See note 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 s pecification as well as data. See
15.14.5.
Default - .FALSE.
FUNNEL If TRUE turns coded with a s ingle Priority Marker M ar e assumed to
“funnel” into a s ingle 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. S ee 18.9.1. N.B. Earlier versions of the
documentation had t he T/F definitions confused and r eversed; see
Appendix E.4
Default - .TRUE.
KERMIT (KilometERS and MinuTes!)
5109341 / Mar 13 6-8

If TRUE the travel distances and times input on buf fer link records are
assumed to be in units of kilometres and minutes rather than metres and
seconds. Outputs in P1X assume the same units. (Useful for very large
scale buffer networks only.)
Default - .FALSE.
KINKY If .TRUE. the standard speed-flow curves used for both the simulation
and buffer networks have a “kink” or discontinuity at V=C, above which
(V>C) they are linear and below (V<C), “power law”. If KINKY = FALSE
they are a power law throughout. USE WITH CAUTION! See 15.38.
Default - .TRUE.
KONAL If TRUE any KNOBS data is included at the end of each 333 buffer
record rather than as an extra line; see 6.6.
Default - .FALSE.
LCR108 If TRUE the “choke factors” applied to turn capacities are
calculated in a better way, introduced in 10.8, to remove possible
discontinuities. See 8.4.4 and note 3, App. D.17.5.
Default – .TRUE.
LEFTDR If TRUE left-hand drive assumed. See Section 15.7.
Default - .TRUE. (or as set in SAT95KEY.DAT; Appendix Y)
LIST If TRUE a c omplete 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.
5109341 / Mar 13 6-9

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 t o “random”
effects are applied to “give-way” or “minor” traffic movements as well as
“major”; see 8.6.2. (Recommended .TRUE.)
Default - .FALSE.
RB106 New rules for the simulation of roundabouts as introduced in 10.6 are
applied; see 8.7.3. In fact, post 10.9, the default value of T is always
taken,)
Default - .TRUE. (.FALSE. pre 10.8)
REDMEN Elastic Assignment Parameter; if TRUE an initial estimate of the road trip
matrix (file FILRED) is used under elastic assignment; see 7.5.3.2.
Default - .FALSE. (Recommended .TRUE.)
REFFUB If TRUE calculate buffer turn (geddit?) flows post assignment (but only if
SAVEIT = T)
Default - .FALSE.
ROSIE If TRUE time-flow curves for turns in shared lanes are calculated as a
function of the total shared flow, not the individual turning flow. See
8.4.3 and 7.1.3.
5109341 / Mar 13 6-10

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.
Default – .TRUE. (.FALSE. prior to 10.9)
SATOFF If TRUE signal offsets are optimised within SATALL; see Section 15.31.4
and 9.12.2.
Default - .FALSE.
SATTIT If TRUE the standard supplementary data file SATTIT.DAT is used to
define DA code text names. See 15.21.
Default - .TRUE
SAVEIT If TRUE the link costs as used for each assignment tree build are saved
on a U FC 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 s ystem optimal assignment is carried out as opposed to a
user optimal; See 7.11.9.
Default - .FALSE.
SPARSE Controls the system whereby SATALL stores internal trip matrices.
SPARSE = T is more efficient if more than 50% of the cells in the trip
matrix to be assigned are zero; else F is preferable. See 7.11.12.
5109341 / Mar 13 6-11

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 par ameter will be calculated
indicating the degree to which paths diverge from true minimum cost
paths.
TFL If TRUE 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, 6.8 and 10.5.2.
Default - .TRUE.
TOPUP If TRUE a node c oded 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.
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.
5109341 / Mar 13 6-12

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

IBUSVC(b) The vehicle class corresponding to buses in company (b); if
unsubscripted it applies to all buses and/or companies. See 5.8.2.
Default - 1
IFCC Defines whether the input centroid connector records in the buffer
network are assumed by default to be one-way or two-way. A ‘1’ implies
one-way and ‘2’ implies two-way. See Note 3 under 6.6.
Default: 2
IFRL As IFCC but for the “real” buffer links as opposed to the centroid
connectors. See Note 3 under 6.6.
Default: 1
INKS_S The number of incremental assignment steps to be applied at the start of
a SAVEIT assignment as opposed to a s ingle 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
5109341 / Mar 13 6-13

IROCKY By default the sector corresponding to a zone may be derived by

dividing the zone number by IROCKY (a very bad spelling of
HIERARCHY!). If 0 it does not apply. See 5.1.7.
Default: 0
ISTOP Used in the test for convergence of the assignment/simulation loops.
The loops stop automatically if ISTOP % of the link flows change by less
than “PCNEAR” percent (default 5%) from one as signment 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: 95 % (Changed from 90% in 10.5); Recommended 98%
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.3.2.3.
Defaults: 1
KLUNK Choice of method for variable speeds under CLICKS. See 15.47.2
Default: 0
KNOBS Number of extra data fields included on t he buffer data records – see
Sections 6.6 and 15.14.
Default: 0
KOB “Kontrol of Burrell” – sets the type of random link cost distribution used
under SUE: 0 – Rectangular 1 – Normal 2 – Modified Normal 3 – Input
density function. See Section 7.2.3.1.
Default: 0
KOMBI After “KOMBI” assignment/simulation loops the assigned flows are
averaged with those from the previous assignment in order to avoid
oscillations. A value of 0 implies that averaging never takes place (the
default). See Section 9.3.
Default: 0
KONSTP “KONtrol of StoPping Criteria”. The stopping criteria for assignment –
simulation loops are based on either: ISTOP (KONSTP = 0); %GAP
value (1); CPU time (2); ISTOP and/or CPU (3); %GAP and/or CPU (4);
%GAP and ISTOP (5); %GAP or (6) %ISTOP. See Section 9.2.3
Default: 0
KORN “Kontrol of Random Numbers” – the seed value for the series generation
of random numbers used in SUE. See Section 7.2.4.
5109341 / Mar 13 6-14

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. S ee
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
within SATALL; see 9.2.3.
Default: 1
MAXDTP Maximum “transient” delay (in minutes) permitted for a simulated turn.
See 8.4.1.
Default: 10 (Changed from 0 in 10.5)
MAXQCT MAXimum Queue Clearance Time (in minutes) for queued traffic at the
end of a simulation time period. If 0, it is ignored. See 8.4.1.
MAXSPA The maximum number of arms for an ( aggregated) node t o be further
aggregated under SPIDER = T. See 15.56.3.
Default: 30.
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
5109341 / Mar 13 6-15

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
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. I f MODET = 0 al l 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 t he line
printer file.)
Default: 1
5109341 / Mar 13 6-16

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)
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
5109341 / Mar 13 6-17

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 f or signals). Maximum
125. See 15.15.2.
Default: all 0
NUCMIN Minimum number of time-units into which the cycle is divided in the
simulation (maximum value 25). See 8.1.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 f actor AFTERS
in later time periods. A sensible value is 1.0; the default is optimistic and
chosen for historical compatibility. See 17.6.2.
Default: 0.5
AK_MIN Minimum value for averaging flows under AUTOK. See 9.3.2.
Default: 0.0 (i.e., does nothing although a value of 0.20 is tentatively
recommended)
ALEX Average Length of a v ehicle (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).
5109341 / Mar 13 6-18

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. S ee 6.9.1,
and, in particular, 6.9.3 for subscripted values of BUSPCU.
Default: 3.0
BUSSPK(b) Bus Stop Seconds Per Kilometre for all routes within bus company b.
See 15.44.
Default: 0.0
CAPMIN Minimum capacity to be expected for any (give-way) turn; any junction
with lower capacities will be factored up to CAPMIN (pcu/hr). See 8.2.
Default: 30.0
CLICKS(n) Maximum free-flow speed in KPH for user class n. See 15.47.
Defaults: 0.0
COBAF Factor to be appl ied 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.
5109341 / Mar 13 6-19

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)
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. S ee, 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: 5.0. Recommended 1.0.
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.
5109341 / Mar 13 6-20

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 5%) from one assignment to the
next. See also ISTOP. Section 9.1.2, 9.2.5 and 9.2.6.
Default: 94.5; Recommended 98.0.
SHADOW An assumed speed in kph for the “shadow network” assignment option;
see 7.11.10.
Default: 0.0
STPGAP Critical gap value (IN %) used to terminate assignment-simulation loops
when KONSTP = 1. See 9.2.3.
Default: 1.0%
STPCPU Critical CPU time (in seconds) used to terminate assignment-simulation
loops when KONSTP = 2. See 9.2.3.
Default: 1,000 seconds
SUET(u) Used to define the range of link cost variation in SUE assignment for
(optionally) user class u – see Section 7.2.3.
Default: 0.2
TAX 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
5109341 / Mar 13 6-21

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 r everse directions on s imulation
links to trigger Warning 32 (See Table 1, Appendix L)
Default – 0.001 (i.e., zero)
W32T Minimum relative difference in times on reverse directions on simulation
links to trigger Warning 32 (See Table 1, Appendix L)
Default – 01. (i.e., 10%)
W32KPH Minimum difference in speeds on reverse directions on simulation links
to trigger Warning 32 (See Table 1, Appendix L)
Default – 1.5 kph
XFSTOP Wardrop assignment stopping parameter for minimum step length. See
7.1.5.
Default: 0.05%
XYUNIT Number of metres corresponding to an integer value of 1 as used to
define node/zone co-ordinates. See 6.8.
Default: 1.0
6.3.4 Character Parameters

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.
5109341 / Mar 13 6-22

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 us ed 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.
FILPEN The file name of the .ufm matrix used to define link tolls by origin. (Not
yet available.)
Default – blank
FILKNB The file name used to define link KNOBS data. See 15.14.5.
Default – blank
FILBMP The file name of the .bmp file used to define a background display for
P1X plots. See 11.3.6.
Default – blank
FILRED The “file name” of the input .ufm matrix containing the initial estimate of
the road trip matrix under elastic assignment if REDMEN = T; see
7.5.3.2 and 7.12.3.
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
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).
5109341 / Mar 13 6-23


XFILE Name of the supplementary X-file; see 6.13.
Default - blank (i.e. no file)
XYFORM The “format” used to define node X, Y co-ordinates under the 55555
data records - see Section 6.8.
Default - 2I5.
N.B. Most namelist parameter names representing files have alternative spellings
so that, e.g., FILTIJ is also recognised by TIJFIL, FILCIJ by CIJFIL etc. etc.
6.4 Simulation Network: the ‘11111’ Records

Data in this section must be preceded by a single record with a 1 in column 1 (or,
more usually, 11111 in columns 1-5) and terminated by a single record containing
99999 in columns 1 to 5.
For internal nodes a complete description of the node, its links, capacities of turns
and signal timings (for traffic signals) must be given on three sets of records:
♦ Record type 1 - Node description (mandatory)
♦ Records type 2 - Link description - One record (mandatory) for each link in
strict clockwise * order but starting with any arbitrary link (plus, optionally, a
second link record to describe link speed-flow characteristics).
♦ Records type 3 - Stage descriptions. Only required for type 3 nodes; i.e.
traffic signals. One record per stage is input.
For external nodes only record types 1) and 2) are required. In addition only the
starred (*) variables below need be included on these records.
Nodes, whether internal or external, may be included in any order (i.e, they need
not be in numerical order).
All numerical data entries (bar one) are implicitly INTEGER and should (for safety)
be right justified; the speed flow power on record 2B explicitly requires a decimal).
However the following inputs may optionally include a dec imal within the
designated columns in order to provide greater accuracy: TIM on r ecord 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 edi ting facilities within PIX (see 5.6, 11.9 and 18) .
However some “fine tuning” using a text editor will probably still be needed
* Counter-clockwise under drive on the right.
5109341 / Mar 13 6-24

6.4.1 Node Data Formats
RECORD TYPE 1 - NODE DATA

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

1-5 STACK Link stacking capacity - see 6.4.11.
6-10 ANODE* Node at the ‘upstream’ end of the link (which may be an
external node)
11 QSTAR ‘*’ if a link speed-flow curve and/or extra link parameters are
required - see 6.4.12 and/or 6.4.14
12-15 LANES* Number of entry lanes (plus weave, flare and/or bus lane
indicators) for this link - see 6.4.9.1.
(0 if the link is one-way from ‘NODE’ to ‘ANODE’ or negative if
it is a bus-only link - See 6.4.4.)
16-20 TIM* Travel time for this link in seconds, or the average link speed in
KPH if SPEEDS = T (See 6.4.5).
21-25 IDIST* Length of this link in metres
26-35 Data for the first possible turn from this link:
26-30 LSAT The saturation flow of the first turn from this link in a clockwise
direction in pcus/hr. See 6.4.6 and 6.4.8.
5109341 / Mar 13 6-25

(0 implies that the turn is banned and a negative value implies

a bus-only turn - see 6.4.4.)
31 TPM The Turn Priority Marker for this turn - See 6.4.2.
32 TPMod Turn Priority Marker Modifier. See 6.4.2.
33 LANE1 First lane (counted from the nearside) used by this turn - 6.4.9.
35 LANE2 Last lane used by turn.
36-45 Data for the second possible turn from this link:
36-40 LSAT Saturation flow, priority marker
41 TPM and lane definition for the next
42 TPMod turn in a
43 LANE1 clockwise direction
45 LANE2 etc., etc.
up to
75 LANE2 for the fifth turn (as required).
In addition (post 10.9) the five data columns following directly on from the last
possible set of turn data may contain a value for TAX for that link; see 6.4.14 for
precise formatting conventions.
(N.B. The following record, 2B, is only needed i f 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 ex tremely useful for modelling motorway-type
links. See 6.4.12 and 6.4.14.)
RECORD TYPE 2B - LINK SPEED FLOW DATA

11-15 TFF Link travel time at free flow (in seconds) or
(if SPEEDS = T) Link travel speed at free flow (in kph)
16-20 TCAP Link travel time at capacity (in seconds) or
or (if SPEEDS = T) Link travel speed at capacity (in kph)
21-25 LCAPY Link capacity (pcu’s per hour)
29 S if speeds are used in 11-20, T if time; if blank then SPEEDS
decides. See 6.4.12.
36-40 N The power ‘N’ used in the speed-flow curve with a dec imal in
column 39 (by default – see 2.8.3)
43-45 INDEX A “link index” in the range 0-999 (where 0 or blank implies a
“non” index); see 5.1.9
5109341 / Mar 13 6-26

RECORD TYPE 3 – SIGNAL DATA

11-15 STAGL Stage duration (sec). See 6.4.3 and 6.4.13.
16-20 INTG Duration of following inter-green (Seconds). See 6.4.3.
21-25 NGM The number of node entries which follow as GNA(1), GNC(1),
GNA(2) ... GNC(NGM/2) (Since two entries are required per
green movement NGM is twice the number of such
movements.)
26-30 GNA(1) The A-node for the first green (i.e., permitted) movement
31-35 GNC(1) The C-node for this turn (i.e., The movement ‘A-node’ to
‘NODE’ to ‘C-node’ is permitted in this stage).
36-40 GNA(2) Second A-node.
41-45 GNC(2) Second C-node. etc.
for all green movements up to
71-75 GNC(5) Fifth C-node (as required).
N.B.
(i) If any C-NODE entry above is zero or blank it is assumed that ALL turning
movements from that A-NODE (except of course any prohibited movements
indicated by zero saturation flow) are allowed
(ii) If more than 5 movements are required they are continued onto a second
record with the 6th A-node appearing in cols. 26-30 of the second record,
etc
(iii) STAGL and INTG (stage duration and i nter-green) are normally input as
integer seconds but it also permissible to define them as real quantities (i.e.,
16.84 as opposed to 17) as long as the numbers fit within the allocated
column limits. See 2.8.3.
6.4.2 Turn Priority Markers (TPM) and Modifiers

(N.B. For right-hand drive read left for right in this note and vice-versa.)
These describe which traffic flows oppose a turning movement. Explanatory
notes follow. The main TPM must be one of the following:
G A turn which must give way (from a minor road) at a priority junction.
X Opposed right turn from a major road at a priority junction which needs to
cross the major flow in the opposite direction, OR an opposed right turn at
traffic signals which must cross the major flow from opposite arms.
M A turn which “merges” with another turning movement at a priority junction.
F A permanent filter at traffic signals with 100% green (generally to the left but
occasionally to the right).
W A weaving movement between traffic entering and l eaving (typically) a
motorway.
5109341 / Mar 13 6-27

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 t his means that the capacity for
movement 1 goes from its (otherwise) maximum value down to zero as the flow
on movement 2 increases from 0 to its capacity. See Figure 5.1. Movement 2 is
unaffected by movement 1.
However if they “share” the capacity for movement 1 goes from its maximum down
to ONLY 50% maximum as movement 2 increases, while movement 2’s capacity
also goes from 100% down to 50% as movement 1 i ncreases. H ence sharing
implies that both movements are guaranteed 50% of their capacity plus another
50% depending on the shared partner.
5109341 / Mar 13 6-28

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”. I n 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 t he final stage allows 2.0 PCUs then the
difference of 1.0 PCU will be allowed under TAX.)
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 al location 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 t o 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 pr iority junction (only) must give way to a single
“major” turn flow, the most obvious example of this being a s lip road entering a
motorway and giving way to the straight ahead flow on the motorway. In addition,
it only needs to find a gap in a single (nearest) lane (see below for the choice-of-
lane rules).
Since an M turn only gives way to traffic in one lane of one movement it is less
restrictive than a G marker.
Merge markers may occur either on their own (a “single-M merge) or in pairs for
two turning movements from different junction arms (a “double-M” or Y-merge).
The distinction is explained in the next two sub-sections.
The detailed modelling of merges is discussed further in Sections 8.2.2, 8.8.3 and
8.8.4. Appendix M discusses some of the issues involved in modelling merges
while the Q-marker is closely related to merges on motorways (see Appendix Q)
5109341 / Mar 13 6-29

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 i t 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 t urn may merge with a m ajor “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.
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-
5109341 / Mar 13 6-30

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 t he 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 s ingle-lane ramp merging into a m ulti-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 m odelled in this situation. N.B. Y-merges, as explained in
8.8.3.2, should not be used with certain lane configurations.
Alternatively, two one-way streets merging into a one-way street could also be
modelled by coding each turn as a G, but this would almost certainly result in
greater losses of capacity.
Funnelling and Lateral Merges (post 10.8)
In physical terms it is possible to envisage of two extreme physical forms of
“merges”:
(1) The two lanes that merge “funnel” into a single lane which therefore restricts
the total number of vehicles which may enter from both streams;
(2) The merging operation is more a question of two parallel streams being
brought into lateral contact without any significant restriction on total exit flow.
This distinction – and possible consequences – are discussed in greater detail in
Section 8.8.4.
Thus, with a “funnel”, there is a definite presumption that (all) the traffic from the
turn marked with the M and t he 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
5109341 / Mar 13 6-31

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) T urns coded F a t traffic signals “give way” (in the same way that G
movements give way) to traffic in their exit road (during those stages where the
exists traffic into the exit road) but are assumed to have 100% green time and
therefore they need not be mentioned explicitly in the stage definition records. F
turns would generally be expected to have an exclusive lane, as illustrated in the
diagram below, but this is not absolutely compulsory. They may be either left or
right turns (although left - nearside - is most common) but must be either the first
turn to left or right.
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 m otorway from/to an
adjoining slip road at the same node. The “geometry” is illustrated below (based
on left hand drive).
5109341 / Mar 13 6-32

Here A-E-D represents a 2-lane motorway and B-E-D a 2 l ane 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 t o be c oded with a pr iority 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 t o lane sharing: e.g. A-E-C and A-E-D may both share the
nearside lane.
W priority markers must always appear in pairs with, for fairly clear reasons which
are difficult to specify succinctly, certain geometrical rules. Pragmatically this boils
5109341 / Mar 13 6-33

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
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 t he major road W-E. H owever they do g ive 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 pr iority 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 av ailable lanes for a c lear 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 j ust one l ane to E this would not be t he case.
Warning 98 detects such instances and prints appropriate messages. N.B.
Warning 98 is only a suggestion, nothing more.
5109341 / Mar 13 6-34

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 c oded as D’s or neither, but there is no absolute
requirement that this is coded (apart from Serious Warning 167 resulting).
Users should be m ade aware that situation (a), no i nterference, is preferable in
the sense that it makes overall convergence easier. Therefore, if the situation is
likely to occur at one o r 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 hoo ked/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 pe riod 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 m ovement has a gr een signal. The “inter-green period” is the time
period between the end of one s tage (i.e., when one g reen movement ceases)
and the start of the next (i.e., when another green movement begins).
5109341 / Mar 13 6-35

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 l eft arrows in the first stage and o f 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 neg ative 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 t o 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
5109341 / Mar 13 6-36

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 def ined 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 pa rticular 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 t heir 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 i nfluence 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.
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.
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 N EGATIVE value of LANES on r ecord 2 abov e. T urn 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.
5109341 / Mar 13 6-37

By contrast bus-only turns are turns out of a n ormal link from which cars are
banned. This is signified by coding a ne gative 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. S imilarly the input cruising speed (if used) is the speed under these
conditions. Since this time or speed is taken as fixed by the program independent
of the flows assigned to this link it should reflect the expected level of traffic flow
on that link. However it must be emphasised that a number of studies have shown
that in urban conditions cruising speeds on most roads are virtually independent
of the flows, depending far more, for example, on whether the road is residential,
shopping, divided highway, etc. T his 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 ex plicitly 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 t hought of as “free-flow”
times or speeds. However an example of a case where they might not be free-
flow would be a m otorway-style road with grade-separated access and exit points
where intersection delays would be m inimal but the effect of flow on c ruising
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
5109341 / Mar 13 6-38

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 us ed; 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 m asse at the start of a par ticular green stage
rather than at random throughout the green stage(s), then this may be bet ter
reflected by reducing the length of the relevant green stage.
See 15.17 for a discussion of why we refer to pcu’s rather than vehicles.
6.4.6.2 Setting Saturation Flows
Setting “correct” saturation flows is as much an art as a science and it is not really
the role of this Manual to supply precise numerical formulae to apply since every
area to be modelled will have its own particular characteristics which will influence
saturation flows. However, in general terms, one can say that the following
features 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.
5109341 / Mar 13 6-39
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 c omputer 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:
♦ Calculating a s aturation 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 n umber 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 i t is to be hoped that the above procedures will be abl e 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!
5109341 / Mar 13 6-40

6.4.7 Roundabout Saturation Flow

Turning movements at roundabouts are not considered as individual turns. A ll
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 eq ual. ( If they are not equal the computer will apply the
maximum value to all turns. B anned 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). I t 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 t he 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 pr oportional to the number of lanes per arm.
Significant differences between the saturation flow per lane for different arms are
detected by Serious Warning 138, first introduced in Version 10.9.13.
6.4.8 The Order of Turns

Turning movements from each arm must be s pecified 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 w ould 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 anot her without there being an i ntersection. A ny possible errors
reported by this check should be studied on a map.
(*) Or counter-clockwise and on t he 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
5109341 / Mar 13 6-41

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. B y “effective” we mean that a l ink
which, say, has only one lane marked but is sufficiently wide that vehicles can
squeeze by on t he 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 t he same arm.
(Although the effect may also be adeq uately 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. H ence a
single lane is “OK” for major arms at priority junctions (although unlikely to occur
in real life), but not otherwise. Single lanes which include both give-way and non
give-way movements are a major problem for convergence (9.5).
In case of doubt - code extra lanes!
Lane definitions making use of flared lanes (post 10.9.20)
Post 10.9.20, it has become possible to explicitly define and model additional
flared lanes, i.e., short sections of roadway added at the stop line to
accommodate specific turning movements. The geometry of a flared right-turning
lane and the (shared) lane from which it diverges is illustrated below:
(Note: the above layout represents the use of the right turn FLAREX lane but also
equally applies to the left-turn FLAREF lane).
A represents the ahead movement in the “main lane” while F represents the flared
movement which diverges from the main lane into the flared lane.
With flared lanes (nearside and/or offside) defined the position on the link at which
lanes are defined has shifted upstream away from the stop line such that the
5109341 / Mar 13 6-42
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 al located to
lanes 1 and 2 whereas the F m ovement would be allocated to lane 2 o nly (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 t o code “artificial” extra lanes (as recommended pre
10.9.20; see above) has therefore become less acute. Thus the post 10.9 advice
is not to code extra lanes when in doubt but to code explicit flares.
Users should also note that:
♦ Shared ahead lanes: straight-ahead movements are not permitted from the
(extra) flared lane. In these cases, the full lane should be m odelled 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 net work .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 pr ogressing 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 s hould not have, say, a right-hand turn and a l eft 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.
5109341 / Mar 13 6-43
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 t otal of three lanes, two for normal traffic and t he
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.
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 t ram-only lane and S represents a t ram+bus lane. In
modelling terms there is no di stinction 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 t o 15 m ay be i ncluded 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 w ould indicate a near side 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 s ubsequently set by defining an ex plicit flared
length on t he 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.
5109341 / Mar 13 6-44

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 f inal 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 unl ikely 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.
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 p riority 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 c onfiguration 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 s ingle 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.
5109341 / Mar 13 6-45

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 s traight 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 em phasised 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 av ailable lanes for X-turners with the inside lane
shared and the outside lane X-turns only is not recommended on the grounds that
(a) it represents highly questionable traffic engineering practice and (b) it leads to
convergence problems when the exclusive lane goes over-capacity and the inner
lane therefore goes over-capacity as well in a very discontinuous fashion. See
Serious Warning 165.
Similarly coding two outside lanes both of which are shared between X-turners
and straight 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 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.
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.
5109341 / Mar 13 6-46

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 c olumns 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
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. A s long as the
default value exceeds the queue on a l ink it has no effect whatsoever on t he
simulation. However, if it does enter into blocking back calculations, it may be
important to set a “true” value; see 8.5.7.
If ALEX is zero, implying infinite capacity, then STACK is, in effect, infinite,
although the actual value stored will be zero. Hence setting ALEX to zero totally
suppresses blocking-back and in this case there is no real need to define STACK
at all.
The position of STACK on the record is clearly rather strange; logically the A-node
number should come first. The reason for this is historical as early versions of
SATURN did not include STACK. However, since in most cases the “stack field”
can be left blank, the ANODE will appear first.
We may also note that a negative stacking capacity may be input in order to
indicate one particular property, which is that a “link chain” (see 5.1.12) can not
be extended through this link. This has particular applications for blocking back
(see 8.5.5). If a negative value is input the absolute value defines the true stacking
capacity and a s eparate 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 m ay define link speed-flow curves for buffer links. E qually,
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 t he only way to adequately model
such links. However it is also possible to abuse the facility as noted below,
6.4.12.1.
5109341 / Mar 13 6-47

To do so you must first insert a ‘*’ in column 11 of the link data record (type 2),
indicating that an extra record (type 2B) is to be inserted before the next link data
record, containing speed-flow data. (N.B. Do not include a * if LANES = 0, ie.,
columns 12-15 are blank or zero, and the link is therefore one-way outbound.
This can sometimes be forgotten if an in-bound link is converted to out-bound
only.)
Note that the additional link record 2B) may also be us ed 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
2) the time at capacity t C in seconds / capacity speed in kph
3) the link capacity C (sometimes referred to as the “pinchpoint” capacity)
4) An ‘S’ or ‘T’ to indicate speeds or times above
5) A “power” n
6) A “link index” or “capacity index” (optional – default is 0); see 5.1.9.
such that link travel time as a function of flow V is defined by:
Equation 6.2
t (v) =
t0 + AV n v<c
where the parameter A is chosen such that t(C) = t C . For V > C the time is
constant, t C .
This data has two effects: (1) it determines the (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 t o denote “Speeds” or
“Times” is new in 10.5. If column 29 i s left blank then the choice is set by the
parameter SPEEDS as on the normal simulation link records. Previously SPEEDS
was always used.
We may note therefore that the same data columns and conventions are used in
the 11111 s imulation link speed-flow curves as in the 33333 bu ffer 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.
5109341 / Mar 13 6-48

We also note that if (and only if) the link is to an external simulation node then the
same information may also be input via the 33333 buffer records; see 15.13. If
both occur for the same link then FIFO (see 6.15) decides which to select.
However, it must be stressed that in such cases it is strongly recommended that
the users themselves make that decision by either removing the data within the
11111 or the 33333 r ecords 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.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
5109341 / Mar 13 6-49

&
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 =
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 t he extra
link parameters are defined using a c ombination of keywords and num erical
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 r equires a second line in order to
define link speed-flow properties (thus free-flow time of 60 seconds, capacity time
of 120 s econds, capacity 2000, power 2.5 and c apacity 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:
(a) The keyword used to designate TAX is, strictly speaking, any set of characters
beginning with a T and ending with an X; e.g., TX, TAX, TyrannosorusreX, etc.
etc. Ditto FX or FLAREX, FF for FLAREF or AV for APRESV. Nor is it case
sensitive.
(b) Keywords may also use columns 11 to 45 as long as those columns are not
being used for speed-flow data. (What happens is that the line is first scanned
5109341 / Mar 13 6-50

for keyword+values which are then replaced by blanks and then the speed-
flow data is read as per normal.)
(c) It is also possible to use Record 2B only to define TAX, FLAREX etc., i.e.,
with no speed-flow or capacity index defined for that link.
(d) Extra link parameters TAX etc. do not apply to links to external simulation
nodes although link speed-flow curves may be used for such links.
(e) Defining FLAREX and/or FLAREF on link Record 2B may be either an
alternative to coding an F i n the lane field on Record 2A (6.4.9.3) or a
supplementary data source. Thus if an F is used in the lane field in Record 2A
but FLAREX/F does not appear on Record 2B then the length of the flare is
assumed to be set by the default parameter FLAREX/F defined under
&PARAM. If FLAREX/F appears explicitly on Record 2B then that value is
used,
(f) A flared lane may also be included if FLAREX/F appears on Record 2B even if
an F did not appear in the lane field on R ecord 2A. It is, however,
recommended to use both methods “belt’n’braces”; i.e., code an F on r ecord
2A and set an explicit flare length on record 2B.
(g) Recall that both FLAREX and FLA REF are defined in units of PCUs, not
metres. And that TAX is also defined in units of PCUs.
(h) If either FLAREF or FLAREX appears to be a bnormally 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.
(i) Note that link-specific values of TAX, FLAREX/F and A PRESV may also be
set using an external X-File; see 6.13.4.
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 i nteger, 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).
5109341 / Mar 13 6-51

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.
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 s ingle record with a 2 i n 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. I f 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. S ince 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.
5109341 / Mar 13 6-52

6) It is also possible – although not recommended – to attach zones to the

simulation network via an intermediate buffer node, in which case the
connectors are contained within the 33333 data records. See 16.6.3.
7) Since a maximum of 6 input node pairs per record are allowed the final
column which may be used is column 65; any text beyond 65 is flagged
as a potential error, particularly if it is numerical (which might indicate that
it was intended to be a 7th input connector).
6.6 The Buffer Network/Link Data: the ‘33333’ Records

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

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). I t is further assumed
that all centroid connectors have fixed travel times (set by the free-flow
field) and an infinite capacity, i.e. 9 9999. (If the free flow and c apacity
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 t o 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 i mplies that it is two-way. I f
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 dec imal 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 t o the buffer network. (This happens very commonly
when a network is originally set up with buffer links defined under 3333
which are then re-defined as simulation nodes and added to the 11111
records). However a buffer link can join a pure buffer node to an external
simulation node or two external simulation nodes.
7) Excluded simulation links - as defined above - are not totally ignored in
that if A-B has previously been c oded as a s imulation 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 po wer) to be as sociated with a
capacity index and t o “replace” blank values on subsequent input
5109341 / Mar 13 6-54
records. These are indicated by a D in column 1. See Section 15.9.5 for

full details. Note that their format may be ei ther fixed column or free-
format (CSV) depending on whether DCSV = F or T.
9) KNOBS data may be included within the 33333 records either as an extra
formatted record following each link record or as free-format data at the
end of the normal link buffer data (i.e., columns 46 and bey ond)
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 i nterpreted 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 ex ternal 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.
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.
6.7 Restricted Turns and Links: the ‘44444’ Records

Links and/or turns may be banned t o 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.)
5109341 / Mar 13 6-55

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.1.
3) A banned l ink or turn is indicated by a negative indicator, 0 i mplies no
effect while a positive number is taken to be a penalty in either time or
monetary units as explained next.
4) A “toll” (i.e., a monetary penalty) is differentiated from a pure time penalty
by the inclusion of either a $ or & symbol preceding the numerical value.
The absence of either implies a ( possibly notional) time penalty whose
units are assumed to be seconds. Tolls are assumed to be given in units
of, say, pence rather than pounds so that a toll of five pounds would be
indicated by £500 (or $500). For further information see Section 20.
5) “Time” penalties may represent virtually anything the user may wish them
to represent. For example, they may be purely notional times designed to
deter non-local drivers from using a local rat-run, or they may be “real” in
that they represent the extra time for a lorry to drive down a windy road.
Under certain circumstances, see 15.24.4, options exist to include them
or exclude them with “normal” time. However, in terms of output statistics
of total times or speeds, penalty times are not included with “real” times
but are listed separately.
6) Buses and ot her “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.)
5109341 / Mar 13 6-56

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. N ote that this applies whether or not the subsequent
record contains nothing but zeros (or blanks) following a -2 entry. See
Section 6.12 for an annotated example.
10) Total output statistics of, e.g., total pcu-hrs for time penalties and t otal
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 r ecord with a 5 i n column 1 (or more usually
‘55555’) and terminated by a 99999 in columns 1 to 5, contains both co-ordinates
for zones and/or nodes as well as - optionally - certain supplementary data:
specifically sector numbers for zones. The role of co-ordinates is described in
Section 5.1.9.
Very often co-ordinate data may be obtained directly from other data sources, e.g.
GIS systems, and “converted” into the appropriate SATURN format. Note that it is
also possible to redefine the SATURN input format (see note (6) below) to
accommodate different data sources.
Data for both simulation and bu ffer nodes and zones are input, one pe r record,
according to the following format:
(N.B. A different format is required under the DUTCH Option - see Section 15.20
or if FREEXY = T - see note (10) below.)
Cols. Description
1 A ‘C’ if columns 2 to 5 contain a zone number (but see note 11);
or ‘S’ to denote a s ector; otherwise blank or part of the node num ber 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.
5109341 / Mar 13 6-57

2) If a node i s 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 O rdinance 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
uses all 6 av ailable 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
5109341 / Mar 13 6-58

are recorded as part of the map network so that they may be used, e.g.,
as part of network editing within P1X; see 18.5.2.
10) If the parameter FREEXY= T (see 6.3.1) then all the data records are
given in “free format”, i.e. no fixed columns and w ith 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 i n &PARAM, in which case any “node” number
less than or equal MAXZN is automatically interpreted as a z one. This
may be useful in converting data from external data sets although its long
term use is not recommended.
6.9 Fixed Routes (E.g. Buses): the ‘66666’ Records
6.9.1 General Principles and Format

Routes in SATURN are defined by a fixed sequence of nodes through either the
simulation or buffer networks and may represent either:
♦ Bus routes (or other transit services such as trams), or
♦ Routes to be used for later analysis, e.g. timed routes from moving car
observer surveys
The second use is (effectively) new in SATURN 9.5. The two are differentiated by
assigning a frequency of zero (columns 7-10 below) to non-bus routes.
Bus routes are “seen” by SATURN as fixed loads to be added to the “fixed”
assignment flows (see 5.5.3.). One bus per hour is equivalent to ‘BUSPCU’ pcus
per hour. Indeed, as note in 5.5.3, it may be possible / convenient to define bus
flows as pre-loaded flows (15.5.5 or vice-versa. For example, if you have a very
large number of low-frequency bus routes it may be simpler to simply aggregate
all their individual flows by link and input them as fixed pre-loaded flows.
Route data records are preceded by a record with 6 in column 1 (or more usually
‘66666’) and terminated by a r ecord 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.
5109341 / Mar 13 6-59

‘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 m aximum 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. H ence, in the above example, there would be a bu s
flow on both A-B and Y-Z as well as on the relevant first/last turns.
See also 6.9.4 on “zero-flow” routes where, in effect, the presumption is
that UPBUS = T.
2) If, however, A and Z were external simulation nodes then the first and
last flows would always be on links A-B and Y-Z since centroid connector
flows are allowed to terminate at external nodes (independent of
UPBUS).
3) The above restrictions only apply to the ends of routes within the
simulation network; they do not apply to sections of route through the
buffer network.
5109341 / Mar 13 6-60

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 di rect 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 l ast nodes. H ence in addition to the first and l ast 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 t he 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 t he first line

further continuation lines may be us ed, identified by blanks in
columns 1-15 followed by the node numbers in columns 16-80.
Note that this option may be combined with the FOZZY option so that the
nodes need not be consecutive; in fact this is certainly the easiest way in
which to define routes.
If, however, EZBUS is FALSE (the default although not recommended)
then the entry in columns 11-15 is necessary to specify the number of
nodes which will follow or, strictly speaking, the number of LINES which
follow. Thus, for example and assuming a maximum of 13 node entries
per line with DUTCH = F, any number between 14 and 26 w ill 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
5109341 / Mar 13 6-61

columns 11-15 only one l ine and t herefore 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 m ay be us ed 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 r ecords / 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 bu s
route if the complete round-trip route is coded rather than as two
separate sections.)
11) Routes are also allowed to exit the network from one “stub node” and re-
enter at another. This may happen if the network has been cordoned and
part of the actual route lies outside the coded section. As with U-turns no
extra time or distance is added in these cases.
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
5109341 / Mar 13 6-62

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”. N ote that this term need not have anything to do w ith
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 pc u factor to bus company 2. U nless otherwise set an i nput 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 i nput time (in seconds) to travel from the start
of a route to a particular node in that route. The precise definition of where the
timing point is taken is of course up to the user but it is recommended that they
represent the time to cross the stop line as opposed to the time to reach the back
of the queue. They would therefore include any delayed time at that intersection
and therefore their value should depend upon which exit turn is to be taken next,
i.e., the next node in the sequence. Their application for validation studies is
described in 11.7.2.
The starting point (zero time) for cumulative times is assumed to be the same
point at which a vehicle (bus) on the route would enter the network. Thus – see
note 1) in 6.9.2 – this would be the downstream end of the first link if UPBUS = F
5109341 / Mar 13 6-63

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 t he .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 t o 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 da ta segment then that route will b e
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
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 ex isting 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.
5109341 / Mar 13 6-64

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 o f each set of 66666 r ecords the list of
modifications is wiped clean and a new edit list must be c reated 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 as follows,
preceded by a 7 in column 1 (or more usually ‘77777’) and terminated by 99999 in
columns 1 to 5:
Cols.1 – 5 The A-node, A
Cols.6-10 The B-node, B
Cols. 11-15 The C-node, C (blank or 0 in the case of a link)
Cols. 16-20 The first specified volume in pcus per hour (see note 13).
Cols. 21-25 The second volume ...
Cols. 26-30 up to MCCS volumes (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 def ined. E ach set commences with a ‘ 77777’ record and i s
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 r eferred to within subsequent
programs. Thus a par ticular set of counts might be as sociated 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 r epeated in
different count sets; multiple values must be handled using MCCS.
3) In addition an i nformative title may optionally be included on t he 77777
record following the 7's giving, e.g., a screen line name to be associated
with the count set to follow.
4) Turn volumes as specified by nodes A-B-C may only be defined for turns
within the simulation network; links specified by A-B may exist in either
the simulation or buffer networks.
5) Volumes on centroid connectors may not be defined.
6) Counts on simulation links are assumed to refer to the “actual mid-link”
flows - see Section 15.16.
5109341 / Mar 13 6-65

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. A lternatively 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 i n
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 s et of links for later analysis. Z ero-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 i dentified for whatever reason (e.g., node no t
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 par ameter 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.
14) Finally we note that $INCLUDE files (see 15.30) may be used to define
the 77777 dat a 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.
15) 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:
5109341 / Mar 13 6-66

♦ 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
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). S ee
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:
5109341 / Mar 13 6-67

♦ 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 P PK values are assumed to
apply to this user class.
6) If, say, the first KNOB field were in units of seconds, then the weighting
value defined in columns 26-30 would be in units of pence/second (in
which case presumably the correct factor would be PPM/60.0). If it were
in units of pence already, e.g., it is being used to represent link charges,
then its weighting factor would simply be 1.0. In either case the KNOB
field is being treated only as a c ontributor to the total generalised cost
and would not be i nterpreted explicitly as a t ime 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 $ / £ i s followed by an ex plicit 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. I f - normally - KNOBS = 0 t hen 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
5109341 / Mar 13 6-68

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 c olumns per “real”
parameter may be av oided by setting a pa rameter 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.
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 neg ative cost (e.g., to encourage the
use of certain routes) then the data should be s et 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 w hich would prevent the assignment-simulation
stages in SATALL from running properly but would not prevent a ne twork map
description being created which would be s ufficient 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 f atal
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.
5109341 / Mar 13 6-69
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.
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 i nitial 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 s mall 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 27 1. 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 w ere 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.
5109341 / Mar 13 6-70

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 upg raded 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 oc curs – and ERRNO(n) = T – then an addi tional 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.
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 t he three data sections are
optional depending on parameters set under namelist. (And in fact at the time of
writing there are no op tions which use the 11111 node r ecords 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.
5109341 / Mar 13 6-71

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
The position of the RBKS data on the link records. (0, 1, 2…); See
NFRBKS
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
NFLX
(0, 1, 2 ...). N.B. Not fully operational yet.
Default – 0
The position of FLARE-F (flared PCUs for nearside turns) on the link
NFLF
records (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
5109341 / Mar 13 6-72

zero this implies that the first data item is a TAX value and t he 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 o r 10 i s 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 de fined: (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.
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 t urn 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 A s 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,
5109341 / Mar 13 6-73

NOMADS=3,
KNOBS=1, &END
11111
1 3 3 2 63
58 3 0 140 1870 1 1 3900 1 3
2 2 9 82 3400 1 2 0 0 0
26 3 17 150 3000F 1 2 1500 3 3
24 7 6 58 2 58 26 26 58
36 7 6 2 26 2 58 26 58
2 3 1
1 2 9 82 2500 1 2 1600X 2 2
3 3 27 248 2400 1 2 3000 2 3
29 1 20 130 900G 1 1 1600G 1 1
(Remainder of simulation network data)
99999 * Terminates simulation link data
22222 * Commences simulation C.C data
1 59 45
2 60 46
3 61 62
4 63 49 49 63
(Remainder of simulation centroid connector data)
99999
33333
3 2 28 56 2500 1 100 3.1
1978.00 * Extra (KNOB) data
29 2 21 42 1250 2 90
1983.00 * field, presumably
2 3 28 56 3750 2 100 3.1
1983.00 * some sort of date
C 2 59
9999.00 * with a default of
C 3 60
9999.00 * 9999 for centroid
C 4 61
9999.00 * connectors
(Remainder of the buffer network/link data)
99999
44444 * Banned links/turns
4 5 -1 0 30 * Link banned to UC 1, open to UC 2,
* 30 seconds penalty to UC 3
34 6 0 -2 * Open to UC 1 but banned to 2 and 3.
31 32 0 -1 0 * Banned to UC 2 only
46 51 50 10 -2 * 10 second penalty to UC 1, banned
* turn for classes 2 and 3.
16 17 18 -2 * Banned turn for all UC - therefore
* presumably a bus-only turn.
99999
55555 * Co-ordinates
1 17 53
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
5109341 / Mar 13 6-74

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 er ror. Three logical parameters, FIFO, TOPUP and
DOUBLE, control the decision in different circumstances.
6.15.1 FIFO – First In First Out

The Namelist parameter FIFO (“First In, First Out”) is instrumental in such
decisions: if FIFO = T then the first entry is rejected and the last entry used, and
vice-versa if FIFO = F.
The problem occurs in the following situations:
1) X,Y co-ordinates are repeated for the same node within the 55555 data
set.
2) Speed-flow data is coded for a simulation link leading into an ex ternal
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 c hanged 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
5109341 / Mar 13 6-75

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.
Thus, if a bas e network has been s et up i n which all (or possibly most) of the
11111 data is held in one or more $Include files and the user wishes to create an
alternative network which differs only with respect to minor changes to one or two
simulation nodes (e.g., by changing the signal settings) then they proceed as
follows:
(i) Set TOPUP = T within &PARAM;
(ii) Include the full data records for the modified simulation nodes at the top of
the 11111 data records in the network .dat file, i.e., before any $INCLUDE
records appear (but if DOUBLE = T, see below, either the “main” 11111
data records or the $INCLUDE file may come first);
(iii) Reference the complete base network data coding by one or more
$INCLUDE records which follows the modified data.
If the nodes included under (ii) are also included within the subsequent
($INCLUDE) file(s) then the node data records under (iii) are ignored and those in
the “main” .dat file are accepted. I.e., it is effectively a case of LIFO discipline –
Last In, First Out.
Note that if TOPUP = F (its default) then the fact that certain nodes are coded
twice would be treated as a semi-fatal error. The advantage of TOPUP = T is that
the user does not need to explicitly delete the old node r ecords and, if the
$Include file is being continually updated, those updates (apart from the
duplicated nodes) will be automatically taken on board in the changed network(s).
Note that the “correct” node coding must always appear at the top of the 11111
data segment (i.e., before $INCLUDE) and the ignored coding can only be within
a $INCLUDE file (but not if DOUBLE = T – see below). If data for the same node
appears twice in the same file it is a semi-fatal error.
As a variation on the above theme it is possible to “delete” a simulation node in a
later data set by including a single node record in an ear lier data set which
5109341 / Mar 13 6-76
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.
The same “LIFO” principle may also be appl ied under the 22222 s imulation
centroid connector data; if a z one record appears before a $I nclude record any
references to that zone in the $Include file are ignored. Note, however, that it is
not possible to “delete” a zonal centroid connector by inputting a negative zone
number first.
TOPUP was first introduced in SATURN 10.8.16.
6.15.3 DOUBLE
A more forgiving version of TOPUP is provided by setting a subsidiary parameter
DOUBLE = T in &PARAM. If both TOPUP = T and DOUBLE = T then any
distinction between data in the main 11111 segment and in $INCLUDE files is
dropped and duplicated simulation node data may appear in either the main .dat
file or in one or more $INCLUDE files independent of the order. The first version of
the node dat a 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 s egment; it may simply reference a string of $INCLUDE
files. For example, the following sequence would be an acceptable – and probably
very sensible – method for progressively defining “scenarios”:
11111
$INCLUDE do_something.dat
$INCLUDE do_minimum.dat
$INCLUDE base_year.dat
99999
Thus the do minimum .dat file would over-write certain data defined in the base
year and do -something could in turn over-write data coded in either the do
minimum or base year scenarios.
A (Semi) Fatal Error still results if data for the same node appears more than once
in the same data segment (main or $INCLUDE). Equally semi-fatal errors result if
a negative (delete this node) number appears more than once or if the negative
node number appears after the node data which it is intended to delete.
DOUBLE was first introduced in SATURN 10.9.15 with a default value of .FALSE.,
largely for historical compatibility, but its default was changed to the
recommended value of .TRUE. in the release version 10.9.22.
5109341 / Mar 13 6-77

6.16 SATNET Files

Channel Remarks
1 An output UFN file suitable for input to SATALL. (Mandatory)
2 An input UFS file containing data from Aa previous run to be used for
updating. (Optional - UPDATE = T)
5 A “DAT” file containing the control parameters and network data; see
6.1 to 6.11.
(Mandatory)
6 An output LPN line printer file. (Mandatory)
9 An input UFS file containing pre-loaded flows; see 15.5
(Optional - PLOD = T)
10 An input trip matrix .ufm file for checking purposes
(Optional – if FILTIJ has been defined)
11 Output .ERL file used to store sorted node-based error messages
12 Scratch file used to store error messages for the output .ERL file
13 Input .ERL file defined by FILERL in &OPTION
(Optional)
15/14 Terminal (output only)
(Optional - MODET ne 0)
17 File “SATTIT.DAT” which contains default array names for the various
data records stored on the output UFN file.
(Optional - SATTIT = T)
18 An input UFS file containing pre-loaded flows; see 15.5
(Optional – PLOD = T)
19 A scratch file used to input GIS/BMP/UNION files as required.
(Optional -)
20 A scratch UFX file used for both input and output.
(Optional - UPDATE or PASSQ = T or a buffer network included)
21 A text file used to input supplementary KNOBS data and/or count data
from FILMCC. See 15.14.5.
(Optional -)
22 A scratch UFX file used for both input and output.
(Mandatory)
23 The input “X-file”; see 6.13
(Optional)
5109341 / Mar 13 6-78

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.
5109341 / Mar 13 6-79

2 L4L DVV 28/05/06
3.1.4 STPGAP etc. added DVV 02/07/06
SATURN v10.7 Patch #3 DVV NP IW IW 18/06/07
5109341 / Mar 13 6-80

Assignment – The Role of SATEASY / SATALL
7. Assignment – The Role of SATEASY/SATALL
Mini-Contents Page
7. Assignment – The Role of SATEASY/SATALL 7-0

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
5109341 / Mar 13 7-0

INTRODUCTION
The assignment procedure accepts as input a trip matrix and a net work and
assigns those trips to routes through the network based on the current cost-flow
relationships, either user-input or derived from the simulation. Its 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). E xtra
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. C ertain 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 are described in Section 5.4. The ex tra
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.
5109341 / Mar 13 7-1


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 al l
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 r oute 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 obt ained 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:
5109341 / Mar 13 7-2

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 o f 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.
5109341 / Mar 13 7-3

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 l anes
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 l onger be r epresented as a m inimisation
problem, since the objective function (7.1) may no l onger be uni quely 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 c ertain Variational Inequalities sense, not minimisation. In both
cases we solve for λ via the same equation (9.4):
∑ c ( λ ){V
a a − Fa } =
0
5109341 / Mar 13 7-4

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 appl ied 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 al so on m otorways, traffic entering from a slip road might be
assigned a gr eater PCU factor on t he first link downstream as a w ay of
representing a greater ‘impedence’ associated with (initally slower moving) joining
traffic.
7.1.4 The Delta Function to Monitor Wardrop Equilibrium

The relative “success” in achieving a Wardrop Equilibrium may be m onitored 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
5109341 / Mar 13 7-5

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 w ell-converged assignment model that gives a s ingle 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 f or a di scussion 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 c ost-effective. This section briefly describes these
criteria.
5109341 / Mar 13 7-6

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 par ameter
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
5109341 / Mar 13 7-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 s pecified
using the parameter NITA_M. This is useful if, for one r eason 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 s et 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 v ery large
value).
We may also note here that NITA may not necessarily be a c onstant 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.
5109341 / Mar 13 7-8

7.1.6 Uniqueness of Wardrop Equilibrium Solutions

In general the link flows V a generated by a per fectly 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 pc u/hr.
The “most likely” equals “most obvious” solution is for each origin to have a flow of
250 pcu/hr on eac h 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. T he 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 di stribution about the average as
5109341 / Mar 13 7-9

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. S ee 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. C arry out a B urrell-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. I ncrement n by 1 and r eturn to step 2 unless n ex ceeds some pre-set
value (NITA).
The reason for choosing the “averaging factor” 1/n in step 3 is that it ensures that
after n i terations the total flow is equally divided between all n s ets 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
5109341 / Mar 13 7-10

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 unr easonable (unless cpu time is a c onstraint). S ee 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.
5109341 / Mar 13 7-11

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 s et 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 C DF; for example a f ile
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 m uch “tighter”
distribution in the range 0.0 to 1.10. The different functions may be us ed 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 w ay that it may be de fined on t he
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 C DF may represent a s kewed distribution such as a g amma 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
5109341 / Mar 13 7-12

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.
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 s tochastic 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.
5109341 / Mar 13 7-13

However to help in monitoring the level of convergence SATURN stochastic

assignment routines print out a number of global statistics
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 t he 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 v alue 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 A MY. O f 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 s omewhat
approximate fashion, the differences in route choice BETWEEN different drivers.
However for highly congested networks it is probably safe to ignore stochastic
5109341 / Mar 13 7-14

effects and t o use an eq uilibrium 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).
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 t axis would be different classes if there were taxi-only links. M UC
assignment is therefore the problem of assigning a nu mber 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 s ingle user class and an up per limit of 32. T he 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
* See Section 5.8 for a description of the distinction between user and vehicle classes.
5109341 / Mar 13 7-15

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.
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 des cription 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 r equired 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. I n 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 4 n x n m atrix 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 m atrices into a s ingle 15n x n s tacked
matrix.
5109341 / Mar 13 7-16

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
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 s ingle user class requires a
standard n x n “unstacked” trip matrix with no addi tional 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 us er 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.
5109341 / Mar 13 7-17

7.3.2.3 MUC Network Restrictions

Banned links and turns as specified on the ‘44444 records’ input to SATNET can
also be m ade user-class specific so that, for example, a t urn can be banned t o
HGV’s or a l ink reserved for taxis and bus es. 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 mirror very closely those described above for either Wardrop
Equilibrium (7.1.2) or Stochastic Equilibrium (7.2.2) with the one ex ception 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.
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 ex ception to this rule - if a us er 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. N ote 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 out put of which will be o-d travel costs by road. T hese costs will
5109341 / Mar 13 7-18

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)
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 s upply 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 t hat 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 i n 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.
5109341 / Mar 13 7-19

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 w ider (e.g. whether to
travel by road) choices are in equilibrium with the resulting road costs.
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 l ot 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 t hese
became widely known as either “elastic” or sometimes “SATEASY” models.
However, on i ts own, elastic is not a par ticularly 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
5109341 / Mar 13 7-20

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 w hole 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 t o have a m atrix 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
transport cost matrices, these will need t o be generated by other models and
converted (as required) into SATURN matrix format. In particular the PT-
SATURN suite of programs, also available through Atkins Transport Planning,
may be us ed to carry out public transport assignment in conjunction with
SATURN.
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 dem and curves, the
solution point also has the property that it minimises a c ertain 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 t he 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
5109341 / Mar 13 7-21

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.
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. H ence 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.
-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.
5109341 / Mar 13 7-22

Thus the problem of minimising the objective function (7.10) may be i nterpreted
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
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
5109341 / Mar 13 7-23

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:
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 t wo 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 s tep (1) (demand) by the horizontal line from B to C. H ere
successive applications of the supply and dem and 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
5109341 / Mar 13 7-24

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.
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 unc ongested 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 t he 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 s omewhere 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:
5109341 / Mar 13 7-25

(1 − λ )T ( n ) + λ d (c ( n ) )
T ( n +1) =
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 ei ther “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 s et up either as “DIY
projects” or within other transport modelling packages such as EMME.
Alternatively, the matrix manipulation facilities within MX may also be us ed to
carry out the basic matrix-based operations of demand models.
Such procedures may be s aid to embed the assignment within an iterative
external VDM “shell” as illustrated below in Figure 7.8.
5109341 / Mar 13 7-26

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 dem and 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 l onger applies. (But see reference 13 i n 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
5109341 / Mar 13 7-27

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 t he “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 ac ceptable 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 s ignificantly altered by the next cycle of the demand model. This
suggests that one s hould try to set easy (relaxed) assignment convergence
criteria for early loops of the demand-supply cycle but to tighten the convergence
5109341 / Mar 13 7-28

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 $I NCLUDE 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 nec essary on t he
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.
7.4.5.4 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 under taken 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 c ycle and t he 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)
5109341 / Mar 13 7-29

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 t he 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 e stimated
by carrying out a final fixed trip matrix assignment using standard algorithms and
recording the routes used via a . ufc file (see 15.23). I t is these routes and t he
output trip matrix T ij which will be us ed 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 10 0% 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. T hus, and i n
particular if you have set a relatively small value of NITA in order to reduce overall
cpu time, a be tter estimate of the final routes should be obt ained 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 S ons. 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:
www.dft.gov.uk/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
5109341 / Mar 13 7-30

fixed. H owever, it could also be t hought 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 pas senger (occupancy). I t 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 i nterpreted as the

expected number of trips if the costs are c ij 0. G enerally c ij 0 would be t aken 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 ex pressed 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 ot her 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
5109341 / Mar 13 7-31

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 j oint
project between the Institute for Transport Studies and WS Atkins, funded by DTp
and administered by TRL. T he 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 ).
5109341 / Mar 13 7-32

Each pseudo link has a cost associated with it which depends on the flow
assigned to it, hence a ps eudo 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 ex tended 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 s tressed 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 t he 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 s een 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 t otal 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. S ee 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
5109341 / Mar 13 7-33

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. T he 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:
5109341 / Mar 13 7-34

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 v iewed as a s tandard
assignment of a fixed trip matrix - T ij max - to a net work 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
5109341 / Mar 13 7-35

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
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.)
A
T ij max is basically an ar tificial 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 g ood 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 m uch
improved overall convergence and it is therefore always used. The choice of T ij (1)
may be made in two ways:
5109341 / Mar 13 7-36

If REDMEN = T then it is taken from an input trip matrix which represents a prior
estimate of T ij , for example from a pr evious 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 us ing 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 )
5109341 / Mar 13 7-37

cij( ) 〈 dij(
n)
0 n
( n +1)
Fij =
Tij
max
cij( n ) 〉 dij( n )
Hence the maximum number of trips are 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 t he 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 M ASL 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. B y default neither
option is invoked although we would recommend their judicious use..
5109341 / Mar 13 7-38

OPTIMUM STEP LENGTH; 4)
In order to choose the optimum value of λ one may either use a r outine 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 m onitored 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 n umber of
other measures may be formulated which refer more specifically to either road or
pseudo links.
5109341 / Mar 13 7-39

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 r elative 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.
5109341 / Mar 13 7-40

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 def ine 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 i nput .ufm matrix where a c ell value of 0 i mplies
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). B oth may be m ost
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
5109341 / Mar 13 7-41

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 s et 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? T he question is what does
SATURN do in such situations.
In the case of origins which have (some) trips but no ou t-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 r easonable
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.
5109341 / Mar 13 7-42

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 publ ic transport can be r epresented
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 c o is cPT ij in both. Two
5109341 / Mar 13 7-43

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 t he
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

( )
N
1
Or cij =
β 
∑
− ln  exp − β cijn 
n=2 
(b)
so that in equations (7.20) we substitute cij for cijPT .
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.
5109341 / Mar 13 7-44

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
5109341 / Mar 13 7-45

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 m odel 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. Fur ther 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. T his 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 o ff peak. D enote 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.
5109341 / Mar 13 7-46

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. G iven 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 t o 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.
5109341 / Mar 13 7-47

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. T his 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 t hat 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 r ational
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 t he assignment with weighted time and di stance but the
“weights” are different in the logit model, then the situation would be m ore
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
5109341 / Mar 13 7-48

all other cost matrices must be c onverted into the same units. E qually 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 i nterpreted as the “existing
situation”. E qually T0 may be t hought of as the “inelastic” demand since if the
5109341 / Mar 13 7-49

costs do not change or if T is independent of c then again T = T0. S ee 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 M CGILL = 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 ex treme, 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 i n 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 c 0 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 t o do is to move continuously between a
model based on ab solute cost changes to relative cost changes. Which, to my
5109341 / Mar 13 7-50

mind, is a major advantage since basically I don’t believe that trip makers perceive
compared costs in an a bsolute 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 t he 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 0 (T max − E ) / T 0 )
1/ p
= (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:
5109341 / Mar 13 7-51

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 0 ( (T 0 ) −1 p ) (T max ) − T q  / q
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 ) = T12c 2 + T2c 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 0 − T c 0 + T ln T / T 0 + T 0 − T ln T 0 − T / T 0  / β
 ) ) (f)
5109341 / Mar 13 7-52

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 g iven 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 d isaggregated 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
5109341 / Mar 13 7-53

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 t he elasticities are not
constant but depend on t he point on t he 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
0
SATALL are those that would apply if the costs of travel by road equal c 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
0
logit choice models (MCGILL = 1, 10 or 11) the costs c 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 ac cessed within the network parameters printed by SATLOOK. In the
case of MCGILL = 10 or 11 t he 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
5109341 / Mar 13 7-54

with numerical underflow or overflow and (b) it is most unlikely that this is what the
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 P OWER and
therefore setting BETA to an appr opriate 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. E lastic assignment is very much a s ituation 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 s ituation 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 i ncremental 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.
5109341 / Mar 13 7-55

Figure 7.16 - An “incremental” demand curve in the base year
The most obvious example of finding a poi nt on t he 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 t he 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 t o demand if costs increased by 10%”. T hus 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 t he 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.
5109341 / Mar 13 7-56

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 w e 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.
5109341 / Mar 13 7-57

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 v alid 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%. E lastic
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 t his. ( 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).
5109341 / Mar 13 7-58

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 P T represent road and publ ic transport and T ij A
represents the total number of ij trips. S ee 7.6.1. A s 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 i nterpreted as a bas e 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.
5109341 / Mar 13 7-59

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. N ote 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.
5109341 / Mar 13 7-60

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. I n the base year this might represent an
observed matrix (aggregated over all choices); in an al ternative/future year
scenario it could represent the base year matrix suitably growthed up ei ther
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 dem and 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 j udicious choice of β and/or p par ameters, 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 t o 110 m inutes. With an absolute function 100 t o 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 s ingle
link or a cordon which is crossed only once then all trips will experience the same
5109341 / Mar 13 7-61

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 y our 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 del ay 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
5109341 / Mar 13 7-62

T0 and c0. I t also follows that X0 may be obt ained 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 r ewritten 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 c hanged network. I f 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 s ubstitute for being careful and bas e
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
uncommon for combined VDM models to be formulated in which this rule is not
adhered to.
* 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.
5109341 / Mar 13 7-63

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 di fferent 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 s trong possibility that the combined supply-demand
model will not converge to a uni que 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 af fect on t he 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 pu re 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 num ber 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 t herefore
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.
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 pr actice that we (DVV) would particularly recommend. From a
5109341 / Mar 13 7-64

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 t o the user. A ll 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. I f 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 el astic 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. D o 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 )
where the additional subscript m refers to a different user class.
5109341 / Mar 13 7-65

Alternatively the demand functions may be t he 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 out put, i.e., c ij 0, T ij ' and T ij are “stacked” matrices with a distinct
level for each user class. S trictly 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 t o facilitate the comparison of input and out put 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 di stinct level for
each user class.
Class specific demand functions may be specified by defining individual values of
MCGILL (which sets the functional form) and B ETA/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 P OWER 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:
1. Incremental:
Equation 7.38
=
Tij AT 0
(
i ij exp − β ( cij − cij )
0
)
2. Absolute or shared:
5109341 / Mar 13 7-66

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 t oo 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.
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).
5109341 / Mar 13 7-67

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 M CGILL. Thus MCUBC may be ei ther 1 or 2 bu t
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 s equence of two further nested choices if
MCGILL = 10 - whether to choose travel by road and/or within a c ertain 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 B ETA_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 t heir own the combined
problem may be r epresented as a convex minimisation problem - the objective
functions for each sub-problem being essentially added t ogether - 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 to 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
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.
5109341 / Mar 13 7-68

Since then very little extra work has been c arried out on t hese 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:
Equation 7.42
T + D ( PPK / PPM ) + ( M / PPM )

Ct =
5109341 / Mar 13 7-69

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 P PK) 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 m ore
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 P PU(1) a w eight 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
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”.
5109341 / Mar 13 7-70

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 s ummation 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 s peed change to change the
travel times according to the assigned flows if AMY = F, or no s peed change if
AMY = T. See 7.11.4 below.
There is one addi tional set of circumstances under which an al l-or-nothing
assignment is carried out and t hat is when minimum distance is requested, i.e.
PPM = 0 and P PK ne 0, and S UZIE is FALSE so that there are no s tochastic
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 c arried 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 i teration 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 i s not something that users should contemplate using in “real”
applications.
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
5109341 / Mar 13 7-71

than is an al l-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 r ecommended and i ts default has therefore been s et 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 e ffectively 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 N ITA 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 av eraged to produce a new trip matrix. T his 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.
Note that SAVEIT cannot be used with WIDDLE = T since the majority of paths
will have been ef fectively generated by the first assignment(s). Equally, and i n
addition to being buffer-only, WIDDLE currently only applies to fixed trip matrix
assignment and a single user class.
5109341 / Mar 13 7-72

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 s ingle user class which tries to speed up i ts
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 ne w 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 c ertain lower limit,
where negative values correspond to a dec reased 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 w eighted 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
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.
5109341 / Mar 13 7-73

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. M ore 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 S AVEIT
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
which seeks to minimise the travel cost of each individual driver. Mathematically
system optimal assignment minimises:
5109341 / Mar 13 7-74

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 s trict
“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 V an Va < Ca (7.47a)
= B Va / Ca Va > Ca (7.47b)
Given that SO assignment may be v iewed 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 us ed under very
specialised circumstances, e.g. to determine how much a net work 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
marginal costs to decrease as V goes from just below to just over C. This can
lead to convergence problems and/or multiple equilibria.
5109341 / Mar 13 7-75

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 r eplaced 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 v ery
early stage and further developments will require both extra theory and ex tra
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 c ertain 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
“shadow network” which is a r eplica of the original network but with constant
minimum speeds.
5109341 / Mar 13 7-76

More accurately the diversion to the shadow networks is based on costs where for
each O-D pair a m inimum distance route is built -which at fixed speeds also
minimises time and c ost - and the corresponding generalised cost of that route
stored. A ny route with greater cost than that will be di verted 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. I t
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. T o invoke the facility it is only necessary to set a p arameter
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. I n principle the ideas could be ex tended to multiple user
classes, however the necessary programming extensions have not been c arried
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 VaDMA
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
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.
5109341 / Mar 13 7-77

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 c hange in the trip matrix, and eq ually the greater will be t he
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
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.
5109341 / Mar 13 7-78

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 l onger 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 i ncremental assignment with, say, 4 i ncrements 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 c hosen 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
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.
5109341 / Mar 13 7-79

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 c omplete “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
The input files are most conveniently defined within the original network .dat file as
illustrated in 7.12.4, although they may also be s pecified via the .bat procedure
(7.12.5).
5109341 / Mar 13 7-80

7.12.2 Selecting Options and/or Parameters

There are a num ber of options available for applying elastic assignment, and
these may either be s et up pr eviously 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
FRED Default 1.0; see 7.5.3.2
6) Specify whether the frozen cell option (7.5.6) is invoked or not
5109341 / Mar 13 7-81

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 s et
within the original .dat file and t his 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’
5109341 / Mar 13 7-82

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
5109341 / Mar 13 7-83

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
0
loaded (or the “reference” trip matrix T ij 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. A ll 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,

ICING, ILOVEU, KINKY, LCR108, MONACO, PARTAN,
5109341 / Mar 13 7-84

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. s ets 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 t he record immediately
following the namelist records (i.e. following &END) and oc cupies columns 1 t o
76.
5109341 / Mar 13 7-85

2 DVV changes (L4L plus S7.14 DVV 28/05/06

removed)
ROSIE modified DVV 28/10/06
5109341 / Mar 13 7-86

Simulation – The Role of SATSIM
8. Simulation – The Role of SATSIM
Mini-Contents Page
8. Simulation – The Role of SATSIM 8-0

8.1 Cyclical Flow Profiles 8-1
8.2 Accept Profiles and Capacities 8-5
8.3 Internal Simulation Iterations and Convergence 8-13
8.4 Simulation Delays, Queues and Flow-Delay Curves 8-16
8.5 Blocking Back 8-28
8.6 Random Delays and Queues (LRTP) 8-36
8.7 Modelling Roundabouts 8-40
8.8 Lane Choice Modelling 8-42
8.9 Simulation Network Capacities 8-50
8.10 SATSIM: Technical Specifications 8-57
5109341/ Mar 13 8-0

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 t urn 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. T he 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 1082 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 ex ecution 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 s et 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.
5109341/ Mar 13 8-1

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 m inutes 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 t o 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 r ight turner is usually greater than that for a l eft 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;
5109341/ Mar 13 8-2

♦ 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 l ess 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 o f 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 o ccupies a large proportion of the programming required. S ee
Section 8.2 for further information.
The OUT pattern of a turn is based on t he ARRIVE and A CCEPT 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
5109341/ Mar 13 8-3

average number of vehicles waiting for a s uitable 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 anal ysis functions within PIX
(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 s imulated. 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 ar e not carried
through to any entry arms and therefore blocking back is not transmitted through
dummy nodes; see note b), section 8.5.2.
5109341/ Mar 13 8-4

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 t ime unit an appr opriate adjustment is
made).
♦ If the turn is coded as a g ive-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 pr obabilistic argument as to where in the
queue the first blocked vehicle will occur). See 8.2.5.
5109341/ Mar 13 8-5

♦ 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
5109341/ Mar 13 8-6

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. H ence 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; but, if there
5109341/ Mar 13 8-7

is significant platooning, t he overall capacity may be s omewhat greater than

CAPMIN.)
The decision as to which rule is applied and t o which movements is based on
geometrical considerations and t he 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.
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 terminate with a stage in which the X-turn is
unopposed (i.e., a l ate cut-off) then the extra allocation of TAX pcus is not
allocated.
Originally TAX was a u niversal parameter; with SATURN 9.4 it became a l ink-
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.5 Unimpeded (Green) Vehicles at the Head of a Queue

Imagine a q ueue 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.
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:
5109341/ Mar 13 8-8

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 v ehicles 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 ex plicit 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 f lared 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 r eached 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.
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.
5109341/ Mar 13 8-9

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:
(1) Both Q A and Q F < X
(2) Both Q A and Q F > X
(3) Q A > X but Q F < X
(4) 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”
5109341/ Mar 13 8-10

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 anot her, 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 t urning 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.
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.
5109341/ Mar 13 8-11

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 i f 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 s ingle 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.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 s ignalised 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. T hus in order to model co-ordinated signals within an ar ea it is
essential that all junctions within that area (including non-signalised junctions and
5109341/ Mar 13 8-12

dummies) are coded with a c ommon cycle time. This may be ac hieved 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.
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 ov er 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 l ess 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 t he ahead f low 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 henc e 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.
5109341/ Mar 13 8-13

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
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
NITA_M which defaults to 5).
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.
5109341/ Mar 13 8-14

Note that the IN and O UT 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 t he 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 w orst 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).
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 par ameter 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 s imulation 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
5109341/ Mar 13 8-15

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
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.
5109341/ Mar 13 8-16

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 v ehicle 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
time period (i.e., LTP) suffers the maximum delay equal to twice that given by
(8.4).
Clearly LTP is a c ritical 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. H owever in
certain simulation summary statistics a di stinction 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 v ery 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 n + t0 + B ∗ (V − C ) / C
= V ≥C (b)
Where:
t o is the free-flow travel time (in seconds),
C is the turn capacity (in pcu/hr), and
5109341/ Mar 13 8-17

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 m ore 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.
Figure 8.3 - Flow Delay Curves and their Fitting Points
For turning movements A and n ar e 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.
5109341/ Mar 13 8-18

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 pow er 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 c apacity of 10,000
pcu/hr, a power n = 10 and capacity delay of 10 seconds then A must equal 10 to
the power –49. 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.
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.) S ee section 8.4.6 for restrictions on t he 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
5109341/ Mar 13 8-19

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 m odelled as total entry arm flows (see 8.7.1) is an i mplicit
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. E qually, explicit capacities may be de fined 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 t he 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.
5109341/ Mar 13 8-20

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
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 r educed (“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. H ence on m otorway-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 t o 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 s imulated 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 del ays indicates by a % those turns
whose capacity is reduced but the value of the choke factor is not given.
5109341/ Mar 13 8-21

(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.
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 s aid, 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 c ontinuous 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.
5109341/ Mar 13 8-22

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 i t becomes highly important for scheme evaluation to get
those numbers correct. Which, in turn, means that it is highly important to get LTP
“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 m inutes. 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. C learly 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 ov er-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 l ane with an as signed 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.
5109341/ Mar 13 8-23

In order to remove such situations, and to effectively provide a s afety 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
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 r e-defined so as to
incorporate an uppe r 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 appr oaches 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
5109341/ Mar 13 8-24

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. I n particular these arose when one or more of the
following circumstances occurred:
♦ 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 m inimal. 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 i t 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
5109341/ Mar 13 8-25

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
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 ac ceptable gap appears in the major flow we need t o know the
probability that there is at least one v ehicle 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 i llustrated 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 L TP/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 pe rmanent queue at the start of the time period associated with
PASSQ (see 17.3) then the linear increase is added on t o that initial queue.
Although, clearly, if you start with an i nitial queue but the capacity exceeds the
arrival flow in that time period (V<C) then the permanent queue will decrease
5109341/ Mar 13 8-26

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 c alculated 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,
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 l ength 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.
5109341/ Mar 13 8-27

8.4.8.6 Display of Queues

The (transient) queue profiles per turn may be di splayed numerically within the
SATLOOK node display menu (option 4). In addition SATLOOK node display
may also display the maximum and t he 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.
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 t aken with a l arge
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 r educes 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 s imulation 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 (optionally - see below) to all centroid connectors entering that link. The
size of BBF is chosen such that the average/maximum queue (see 8.5.2 (f))
5109341/ Mar 13 8-28

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 pc u/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. H ad the
capacity been 500 t he blocking back factor would only have been 49 9/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 p riority
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 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 both 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 r educed and, in the case of running a s ubsequent time period
under PASSQ, the “missing” flows would be “ passed over” as fixed flows.
The existence of blocking back on a c entroid connector is indicated by a
finite capacity (which is related indirectly to BBF) as stored in DA code 1383.
5109341/ Mar 13 8-29

(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
there would be no queue on C -B; in such cases it would be pr eferable 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 appl ied 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 t hose 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
5109341/ Mar 13 8-30

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 w ould 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.
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 t otally blocked. (These turns would be as signed a priority marker X.)
Thus equations such as (8.2) will continue to apply with the “major” flow V 1 (i.e.,
5109341/ Mar 13 8-31

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 c ontinuous and t hat there would be no g aps 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 g reater 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
released version 10.4.10 this facility was not included and t he 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.6a, 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.6b, 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.
5109341/ Mar 13 8-32

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
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
5109341/ Mar 13 8-33

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.
STOP PRESS: Post release 11.1.9 the “internal” blocking back as described
above has been r emoved 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 r estricted 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 t raffic entering on one ar m
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.
5109341/ Mar 13 8-34

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 s imulation 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 r educed. So neither, one or
both could block back depending on the Q vrs. S values on each individual link.
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.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 l ink 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 bl ocking 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.)
5109341/ Mar 13 8-35

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
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 pedes trian crossing slightly displaced from a s ignalised 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.
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 m odel 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 w orst links in terms of changes in their blocking-
back factors from one s imulation 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 j unction 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. T he 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 m inor arms at priority
junctions. H owever at major arms at priority junctions and al l 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
5109341/ Mar 13 8-36

“random delay” component which is calculated from the following formula as used
in the traffic simulation model TRANSYT:
Equation 8.8
=(d ) {
(T / 4q ) ( q − s ) + ( 4q / T ) 
2 1/ 2
}
+ (q − s)
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). T he 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 t he same as the delay calculated for a s ingle 30 m inute
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.
5109341/ Mar 13 8-37

As a r ule 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:
a) the additional delay contribution is probably realistic and (b) by making delay
a “smoother” function of flow it makes both assignment and as signment-
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 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 l ess 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 del ays will be virtually zero for all
flows up unt il C (i.e., S). S etting 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 c apacities (i.e., q and s in
equation 8.8) aggr egated 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.
5109341/ Mar 13 8-38

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.
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 s ingle lane. This, in turn, creates problems of convergence
between assignment and simulation.
This problem may be ov ercome 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 l ogical 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 t he (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.
5109341/ Mar 13 8-39

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,
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 pos sible 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 s omewhat simplified model in that no di stinction is made between the
different possible exits from each entry arm or of the possible allocation of
different exit movements to different lanes. N or 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 t o later exits (on the inside and
interfering least).
In fact turning flows from the same entry arm at a r oundabout may be s een as
implicit examples of “rivers” as explained in 8.8.2.
5109341/ Mar 13 8-40

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 t he 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
(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 t hat arm, its
capacity, the probability of gaps, etc. etc. and appl ied 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. S ince logically U-turns should always be po ssible 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 ar m 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 t hat 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!
5109341/ Mar 13 8-41

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).
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 eq ually, since a straight
ahead vehicle cannot go if there is a stationary turner ahead, the straight ahead
capacity will be l ow as well. C learly 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 t he 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 v ery 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 ot her 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 a nd 2 and r ight turns use lane 2
5109341/ Mar 13 8-42

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.
If one m ember of a r iver is over capacity then all members are and t hey 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 ac tual 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.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 ex ception 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.7 illustrates a s ituation typical of an ent ry 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.
5109341/ Mar 13 8-43

Figure 8.7 - 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
() ( )
+ VDBC ∗ APRESV =
1 2
VAB 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 t he 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.
5109341/ Mar 13 8-44

8.8.3.2 Double-M “Y” Merges

The same principle also applies in the case of a “Y-merge” (Figure 8.8) where two
streams of traffic, both coded M, merge into one with equal priority, as happens
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.8 - 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 t he 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 appl ied perfectly happily at “asymmetric”
junctions (i.e., a different number of lanes on b oth 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 m otorway entry ramp with an M on t he
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;
5109341/ Mar 13 8-45

Note that the case of a single lane on both entry arms of the Y is accepted
although possibly unusual in practice.
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.7, if the motorway has 2 l anes on A -B and 2
lanes on B -C and t here is no e longated 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 m ore “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.9 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 .
5109341/ Mar 13 8-46

Figure 8.9 – 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 l ateral merge could be partially

represented by the choice of the gap G (i.e. GAPM) Thus a “lateral merge” would,
generally speaking, require a l ow gap value such that G S M < 1 w hich would
therefore have a r elatively minor impact on c apacity; a “ funnelling merge” which
represents a greater capacity reduction, would require a l arger gap value. Thus
curve (a) in Figure 8.9 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 f unnel-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.7, 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 S m + VM S M < 1
5109341/ Mar 13 8-47

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.9 where GS M
= 1. Thus Equation 8.14 only sets a lower capacity C m in case (a) in Figure 8.9
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.7, 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 t he 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 t he 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 l ess 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.
5109341/ Mar 13 8-48

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 pr oviso 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 t hat 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 t o 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 t hen 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 FU NNEL = F t hen 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 P riority 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.
5109341/ Mar 13 8-49

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. N ote 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 de fined 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
5109341/ Mar 13 8-50

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 c apacities 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. T hus 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 addi tional capacity reflecting the spare
capacity in that lane.
5109341/ Mar 13 8-51

The problem which emerges here is that the “spare capacity” may differ for
different turning movements if they have different saturation flow rates. I f, 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 t hat 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 t otal lane capacity we cannot simply add up t he 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 t hird of a w eighted average of 1200 and 1500 pc u/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 l ane 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 i s obtained by summing up the link capacities
of its entry arms.
5109341/ Mar 13 8-52

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.
5109341/ Mar 13 8-53

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.
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 z ero 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:
5109341/ Mar 13 8-54

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).
For example in all three cases given in 8.9.3.1 above the queue dispersion rate
would be 1500 pc u/hr (equal to the average of 1200 and 1800 bu t only by
coincidence, not a g eneral 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) s hould be t he 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 ACQn + B (V − CQ ) / CD
t =+ V > CQ (b)
where B as before is half the time period which is being modelled. The
parameters t o , A and n ar e again evaluated by the simulation. Fi gure 8.9
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.
5109341/ Mar 13 8-55

Figure 8.10 - The basic and modified cost-flow curves for over-capacity simulation
turns.
Note that since C Q may be z ero 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 l ower
slope reflecting the fact that mathematically the dispersion capacity must be
greater than any individual turning capacity. This is illustrated in Figure 8.9.
Our definition of the assignment cost (or time) vrs flow curve does not therefore
have any impact on t he 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 s ubsequent 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 r iver is over capacity, then all turns in that river must be ov er
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 r iver may be di fferent
5109341/ Mar 13 8-56

(see tables 8.1b and 8. 2b) since it depends on the number of lanes which they
use.
Note that the capacity of a r iver is simply the sum of the lane capacities of its
constituent lanes.
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 l ink as a w hole 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 o f simulation links (see 15.16) N.B. Only relevant if
blocking back on a l ink 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 as signment 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 t hus as defined in 8.9.1; for
buffer links it is the “normal” capacity.
8.10 SATSIM: Technical Specifications
8.10.1 SATSIM Files

Channel Number Remarks
1 An input UFA file from SATEASY (Mandatory)
5109341/ Mar 13 8-57

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 def ined here constitute a s ub-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.
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
5109341/ Mar 13 8-58

2 L4L DVV 28/05/06
5109341/ Mar 13 8-59

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

SATALL
Mini-Contents Page
9. Assignment / Simulation Loops – The Role of SATALL 9-0

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-20
9.9 SATALL Convergence Statistics: Full Line Printer Listings 9-21
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-28
9.14 The SATURN Batch Procedure 9-29
9.15 SATALL: Technical specifications 9-30
5109341 / Mar 13 9-0

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 t o 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
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
5109341 / Mar 13 9-1

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 c o-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 l oop n-1. I f this exceeds the (integer) parameter ISTOP then the
process is judged to have converged satisfactorily. I f the criteria is satisfied on
NISTOP successive loops then the process is terminated (where, by default and
in all versions prior to 10.3, NISTOP = 1 s o that the loops stop as soon as the
ISTOP criterion is met).
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 i ntroduced at a l ater stage of SATURN development and t hese 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. E ssentially 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
requires longer run times so that, in practice, the target level of convergence will
represent a compromise between accuracy and run times.
5109341 / Mar 13 9-2

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 bo th faster and,
ultimately, “more clever” in terms of the steps that can be introduced in order to
improve the rates of convergence. Fo r 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 c arried out within
SATALL. I ndeed, as with the elastic DIDDLE (what a g reat 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 t ables of convergence statistics which are (a) included within
the .lpt files but (b) may also be v iewed 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
♦ A/S Step - Step length used per loop / Simulation repetitions
5109341 / Mar 13 9-3

♦ Assignment/ Simulation Loop - % Link flows differing by < 5% between

successive assignments
♦ Assignment/Simulation Loop - % Turn delays differing by < 5% 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 m onitors the successive internal convergence of each
simulation using the parametric measure discussed in 8.3. A gain, as a r ule of
thumb, if these figures are much in excess of 1.0 you should consider increasing
NITS.
Columns 1 and 2 al so give the numbers of assignment and s imulation internal
iterations undertaken (for which NITA and NITS set upper limits).
Column 3 r eports 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 us ed in SATURN from the beginning and ha s thereby
acquired a c ertain historical momentum. It is (by default, see 9.2.3) the “main”
5109341 / Mar 13 9-4
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 or
95%. IS TOP and/or RSTOP are set in &PARAM; see 6.3.2. See also 9.2.3 for
alternative stopping criteria.
“% DELAYS” is similar to “% FLOWS” but is based on the fraction of simulation
turns whose delays change by less than 5% (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 v ery 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.
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 t o be ac hieved and, indeed, should be ac hieved. A GAP value of
5109341 / Mar 13 9-5

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 i n
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
4.4.19-4.4.28, Chapter 4, Section 2, Volume 12 of DMRB.
Please note that the measures included in Table 2 ar e essentially arbitrarily
selected from a v ery large number of potential convergence statistics. For
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.
5109341 / Mar 13 9-6

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, 95/94.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 f ixed 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
calculate and under stand 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 t he “accuracy” of the assignment method used. Thus if one uses an
5109341 / Mar 13 9-7
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 de finite 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 continues to be
%FLOWS (KONSTP = 0).
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 l ess 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 v ery broad-brush “quick and dirty”
estimate of what traffic conditions may look like in 20 years time the results will, of
necessity, be v ery inexact and t here 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 c an only be
accurately measured if both sets of results are extremely accurate. Otherwise the
differences will simply get lost in the “noise”.
It can be ar gued that, as a v ery 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 WebTAG Variable Demand Modelling, Section 3.10.4).
This implies that if a s cheme reduces total travel cost by, say, 1%, then you
require a GAP value of 0.1% or better to achieve a satisfactory evaluation.
5109341 / Mar 13 9-8
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 3.19
The current guidance from the Department for Transport is provided in its
Transport Appraisal Guidance (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 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 p ractically
undertaken whilst more stringent criteria would be appl icable 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).
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 t o the nearest integer, i.e., 97%, and c ompared to the
integer value ISTOP, e.g., it would satisfy ISTOP = 97. Equally 96.4 would be
5109341 / Mar 13 9-9

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 def ined 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. T hus 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 t he 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 al lows 3 as signments 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.
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. I f however
5109341 / Mar 13 9-10

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 V ariational 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
where now the costs c a (Λ) are those derived from simulation n+1 based on Λ-
averaged flows. A gain we may think of the costs as a f orce 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.
5109341 / Mar 13 9-11

If, as mentioned above, Φ(1) > 0 then a step-size of 1 is used and no a veraging
takes place. N.B. This is the most frequent result; see below. Alternatively, if Φ (1)
< 0, then equation (9.5) is solved by a h euristic method of successive
interpolations.
Thus we first calculate Φ(0); this may be d one, in fact, immediately after
simulation n w here 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 pos sible to “accelerate” the estimation of Λ by introducing an ad ditional
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 t he next application of AUTOK w e
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.
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 def ault 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
5109341 / Mar 13 9-12

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 i nterpreted 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. H owever if using KOMBI is the price that has to be paid for
achieving good convergence then it is a pr ice 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. H owever an al ternative
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
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 m ore accurate solution. T his 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
5109341 / Mar 13 9-13
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 t he simulation; e.g., their
%FLOWS reach 90% but fail to progress much further. The next two sections
provide advice on w hat to do w ith (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 s ingle 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
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
5109341 / Mar 13 9-14

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 l arge 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 s trong 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 t he
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 c orrected 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 di stance (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 P PK may well be c onstrained by other factors
such as evaluation.)
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 del ays; reducing the level of
5109341 / Mar 13 9-15
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 l ane 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 l ong 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 s ingle 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 t o coding errors at
the junction leading to very low capacities. To illustrate the point from one
(anonymous!) network: a priority T-junction on a m ajor 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
5109341 / Mar 13 9-16
100 or 200, the resulting queue stretched back for 10 km and t he 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) b e 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 r emoved,
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 ac hieved 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 near s global convergence and the flows being simulated are
relatively stable, the normal simulation convergence criteria will be m et 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.
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 pr actical consideration. M ost of these
5109341 / Mar 13 9-17
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 o f (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 ac hieved 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 v ery long, very accurate
assignment to a net work 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 t enth 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
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 v alue
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).
5109341 / Mar 13 9-18

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. H owever 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 ex pected 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 out put files (although, see below, the use of SATALL is strongly
recommended.
Net.DAT
SATNET
Net.UFN
Cijø.UFM Control.DAT
Tijø.UFM SATEASY Tij′.UFM
Net.UFA
Tij′.UFM
SATSIM
Net.UFS
5109341 / Mar 13 9-19

Thus starting from a ne twork data file net.dat fed through SATNET the process
starts with an i nitial elastic assignment using SATEASY. T his 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 el astic
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 ou tput file containing converged assigned flows
By combining two programs into one SATALL should be bo th faster and,
ultimately, “more clever” in terms of the steps that can be introduced in order to
improve the rates of convergence. Fo r 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 c arried out within
SATALL. I ndeed, as with the elastic DIDDLE (what a g reat 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 as signment 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 5% (or, strictly
speaking, PCNEAR %) between successive assignments; see 9.2.
5109341 / Mar 13 9-20

(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 i i) 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 t he 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 i ii) goes to zero at
convergence.
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 par ticular 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 i i) determine the simulation stopping criteria; see 8.3. A t
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.
5109341 / Mar 13 9-21

9.9.1 Assignment - Simulation Loop Convergence

9.9.1.1 Global Measures
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 o f the complete set of loops and m ay 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 5%
(or, strictly speaking, PCNEAR%) between successive assignments; see
9.2.1. T he distribution of PCOK for a s tandard 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%
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. N B:
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
5109341 / Mar 13 9-22

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 l argest changes in Blocking Back Factors used on the
current and p revious 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.
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 t wo
successive simulations (with an as signment 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.
5109341 / Mar 13 9-23

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 t he 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 as signed to the current minimum cost
routes.
♦ DELTA = (C1 - C2)/C2; see 7.1.4.
♦ 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;
5109341 / Mar 13 9-24

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. B ETA and P OWER are elasticity - related
parameters, etc. Similarly the share-based demand functions, the extended logit
models (7.6) and t he distribution models (7.10) may all be i nvoked 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.
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. T his 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 t he real links. Empirically
using DIDDLE appears to improve convergence significantly.
5109341 / Mar 13 9-25

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 s et 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
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 c an 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 ex tra 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 t hat file is used as input. A consequence of using this
option is that an existing net.ufn file will itself be over-written.
5109341 / Mar 13 9-26
Clearly this facility depends on t he network having a s imulation component; a

similar continuation option for buffer-only networks is described under WIDDLE in
7.11.6.
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 v ery 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.
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 l oad of the fixed flows followed by a single
simulation. In effect MASL = 1. Clearly no f eedback is necessary since the
simulated delays have no impact on the flows.
At first glance this may seem a bi t of a silly option – why have an as signment
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 r e-assigning a c ordoned trip matrix (a) takes time and (b) is not
5109341 / Mar 13 9-27

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 al tered but the link flows themselves remain
unchanged.
Another application would be t o do a genui ne 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 as signment 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)
5109341 / Mar 13 9-28
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 t hat the output file is
always .UFS whether or not the network is pure buffer or not. I f network.UFN
does not exist but network.UFS does then it is renamed.
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.
5109341 / Mar 13 9-29

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)
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 nes ted 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
5109341 / Mar 13 9-30

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 def ined here constitute a s ub-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
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:
TTLE = 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
5109341 / Mar 13 9-31

10.9.24 SATURN V10.9 Release (Full) DVV AG IW IW 06/05/11
5109341 / Mar 13 9-32

MX: Interactive Matrix Manipulation
10. MX: Interactive Matrix Manipulation
Mini-Contents Page
10. MX: Interactive Matrix Manipulation 10-0

10.1 Synopsis 10-1
10.2 Matrix Files: General Properties 10-4
10.3 MX File Structure 10-9
10.4 Copy/Transpose/Re-code an Input UFM File; Re-defining Zones 10-10
10.5 Matrix Input and/or Updating from a .DAT File 10-13
10.6 Select Options 10-22
10.7 Matrix Factoring 10-24
10.8 Matrix Manipulation 10-31
10.9 Statistical Analysis 10-35
10.10 Viewing and/or Editing Matrix Elements 10-36
10.11 Viewing Row and Column Totals 10-38
10.12 Matrix Graphics 10-39
10.13 Printing a complete matrix to a line printer 10-39
10.14 Printing/Dumping Row and Column Totals 10-39
10.15 Dumping a Matrix to an ASCII .DAT (Text) File 10-40
10.16 Output UFM Matrices 10-43
10.17 Stacking and Unstacking Matrices 10-44
10.18 Matrix Demand Calculations 10-45
10.19 The MX Box of Clever Tricks 10-46
10.20 Useful Matrix Batch Files 10-47
5109341 / Mar 13 10-0

INTRODUCTION
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 pe rfectly 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 s ometimes cell values are referred to explicitly as
“trips”, e.g. when discussing distribution models. E qually “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 s ingle “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 t hese files (e.g. matrix title) and t o
5109341 / Mar 13 10-1

introduce a supplementary network UFS or GIS file (10.3.3) to supply,

e.g., sector definitions (10.2.5) or zone names (10.3.3).
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 s preadsheet
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 ex isting matrix may be
“incremented”.
10.1.1.2 Matrix Changes

1) SELECT
Certain options, such as factoring, may be ap plied 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.
5109341 / Mar 13 10-2

10.1.1.3 Analysis
1) STATISTICS (UNIVARIATE OR COMPARISON)
Compare two matrices, obtain a s et 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 t he
terminal. Cursor control keys may be used to “move” through the
matrix and m ore than one m atrix may be viewed simultaneously. I n
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
5109341 / Mar 13 10-3

A prototype set of “formal” transport demand model steps such as

distribution or modal split are carried out using a combination of input
trip and c ost matrices. These parallel the standard elastic demand
options within SATEASY (see sections 7.4 to 7.10) and dem and
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 s econdly 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.
For virtually all transport-based applications the matrices are square (number of
rows equals number of columns) and t he 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.
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
5109341 / Mar 13 10-4

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.
A consequence of this change is that .ufm files created by 9.5 are not backwards
compatible; thus 9.5 can read earlier .ufm files but not vice versa.
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 s et of multiple square
matrices and are therefore standard.
10.2.2 Zonal Sequential Numbers, Numerical Names and Zone Titles

Each row and c olumn of a (square) SATURN matrix has an ex ternal 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. S ince zone numbers need not be s equential 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 f ixed 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 pos itive non-zero numbers and, whereas
exceptions to this rule will be f atal 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.
For square matrices rows it is assumed that the same set of numerical names
and/or titles applies to both rows and columns.
5109341 / Mar 13 10-5

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. Fo r
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 i nteractively defined within MX (under Matrix Manipulation 10.8 or UFM
Output 10.16).
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”. T hus 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. T hese are illustrated in Figure 10.1a and 10. 1b
respectively.
5109341 / Mar 13 10-6

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 is new 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.
5109341 / Mar 13 10-7

10.2.5 Sectors
Sectors represent a user-set level of zonal aggregation as described in section
5.1.7 and as such are equally applicable to matrices which are based on zones as
to networks. Li ke the alphanumeric zone names sector definitions may be
obtained “externally” from either:
(a) an associated GIS file (see Block 8, App. Z),
(b) a network .ufs file (see 6.8),
(c) an explicit “zone-to-sector” (.Z2S) file (10.2.5.1 below),
(d) “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
(e) alternatively, set within the program using a sub-option of the Files menu.
Generally speaking the number of sectors (which are restricted to less than 20
anyway) should be s mall 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 s et 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.1 Z2S (Zone to Sector) Files

Z2S (Zone to Sector) Files are external files which convert zones to sectors and
are new in Version 10.9. Essentially they are free-format text files which consist of
a set of records, one per zone, containing the zone name and the corresponding
sector separated by a comma and/or a space (i.e., CSV).
The same files may also be defined by the parameter FILZ2S in a matrix .dat file
(see 10.5.2) and have the standard extension .Z2S.
Note that their format also corresponds to a s implified version of the Records 2
used by the batch file MXM5; see Appendix W.3.
10.2.6 Matrix Title

Every .ufm matrix file has a t ext title of up t o 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”!
5109341 / Mar 13 10-8

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);
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. T hus 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
5109341 / Mar 13 10-9

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 r edefined 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
(matrices) being examined. T hus either may supply the necessary sector
definitions which (see 5.1.7 or 10.2.5) are originally set within the node c o-
ordinate data sets on a net work .dat file or the .gis file. E qually 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 pr edefined as part of an i nput .ufm file. T his
option is particularly useful when the matrix is being input from a .dat file and the
zone names are not known a pr iori (see 10.5). Post 11.1 the zone names are
applied to rows within all levels of a s tacked 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 ou tput “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”
5109341 / Mar 13 10-10

(ii) as its transpose (T ij becomes T ji )

(iii) as a compressed/expanded/recoded matrix
(iv) as an a ggregated version of a s tacked input matrix (i.e., with all levels
summed to create a single square matrix)
(v) as a single level from an input stacked matrix
(vi) by “pasting” an ex ternal square matrix into a single level of an internal
stacked matrix
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 al tered 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.2.
10.4.1 Zonal Editing

Zonal editing must 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. I t 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 des cribed as
follows:
1) Deletion is straightforward - both the row and the column corresponding to
the zone selected are removed. A lternatively a range of zones, e.g. all
external zones, may be removed.
5109341 / Mar 13 10-11

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 ei ther defined uniformly by row and c olumn (e.g. set all
row elements to 1 and all column elements to 2) or they may be copied
(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 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 z one into another with a
different name (“one to one”). S ince 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 c ompressed may either be i n 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 s ingle 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 t he next two (one into one) being effectively
renaming.
5) The “Split” function may be us ed to divide a s ingle 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 z one 100% into a di fferent 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 a ggregated 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.
5109341 / Mar 13 10-12

To a l arge extent the options here mirror the three transformation options, “M3,
M4 and M5”, available under option 14 (Section 10.16) and as distinct batch files
(see Appendix W), which dump the internal matrix to a .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 agg regate to districts 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 r un 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.0 and Appendix W.3.
10.4.2 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 c arried out using an ex ternal procedure mxagg; See
10.20.21.)
Secondly, and s imilarly, a s quare internal matrix may be c reated 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 us efully combined with the “cut” operation (see
10.16) whereby a square matrix is extracted from a stacked matrix, edited in some
fashion and then pasted back in to the original matrix.
10.5 Matrix Input and/or Updating from a .DAT File

The internal matrix may be bui lt 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)
5109341 / Mar 13 10-13

♦ 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 out put .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. N ote, 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 c olumns (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).
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 onl y 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.
5109341 / Mar 13 10-14

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 c olumns 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 pos sible 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 m ore 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.
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.
5109341 / Mar 13 10-15

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.
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
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) THE “MATRIX PARAMETER” RECORD (optional - MPNEXT=T)

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.)
(a) LONG = FALSE (its default): (FORMAT 15I5)
5109341 / Mar 13 10-16

1ST CARD(S) - The “name” for row 1 i n cols. 1 t o 5, followed by the

NCOLS elements in cols. 6-10, 11-15, etc., using the subsequent cards as
necessary. T hus 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 i n 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 i n 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 s kipped before origin 1 dat a,
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.
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 r ows and a s ingle
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.
5109341 / Mar 13 10-17

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 s ingle 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. C hoices 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 s pace
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.
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:
*
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.
5109341 / Mar 13 10-18

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:

11 22 6.00
would imply a cell element of 6.00 for row (origin) 11 and column (destination) 22,
both 11 and 22 bei ng zone “names” which would need t o 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.
5109341 / Mar 13 10-19

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 t o 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
by Windows programs such as EXCEL and t herefore 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 s pace between successive values, or both commas and/or spaces
may be us ed. However there may be c ertain instances where spaces are not
recognised as CSV-compatible so that the use of “pure” CSV formats is
recommended.)
5109341 / Mar 13 10-20

Note that zero cell values must be included as must rows which are all zeros.
However, an i nput 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. I n 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 s tacked CSV records they should be
identical within each level although, strictly speaking, they are ignored after the
first level has been r ead in. On the other hand s equential 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 al phabetic 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:
♦ 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 ….
5109341 / Mar 13 10-21

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 op tion 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 pu rely 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 i nput .dat or .ufm
matrix file, allows one t o set a flat matrix with user-set numbers of rows and
columns
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
5109341 / Mar 13 10-22

♦ “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.
♦ 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 t o be specified. T he principles apply equally to link selection
within P1X or SATDB; see 11.6.1 for further details.
5109341 / Mar 13 10-23

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 t hose 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, PIX 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) 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 oper ate only on t he
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.

3) Singly - or Doubly-Constrained Furnessing:
Tij = Ai B jTij
where the row and/or column balancing factors are chosen such that
∑Ti
ij = Dj
5109341 / Mar 13 10-24

∑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 s et 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 i n 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 r ow and/or column of the matrix to be factored contains all zeros
then equally the factored matrix row/column will also be al l zeros (under both
singly and doubly constrained).
However confusion may arise if a r ow/column contains a v ery 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.
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
5109341 / Mar 13 10-25

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 par ticular sub-matrix the
selection may be f urther refined by setting, e.g., internal zone limits and/or cell
value conditions as “AND” conditions.
Note that a s ingle level may equally be s elected 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.
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 t o 5 of level 2 t hen one c ould 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.
5109341 / Mar 13 10-26

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.
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.
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 c omplete 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
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 opt ions to read in factors from an ex ternal .dat file
although this can be done w ith only slight inconvenience using selected area
factoring (10.7.3). For example a control file:
5109341 / Mar 13 10-27

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 m ore 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.
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.
5109341 / Mar 13 10-28

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 c omma or by one or more spaces. If CSV =
.FALSE. the fixed columns (with decimal points) specified below must be us ed.
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:

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)
5109341 / Mar 13 10-29

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 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 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:
5109341 / Mar 13 10-30

Cols.1 – 5 The row/origin zone name or sequential 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 SET 6 - DESTINATION/COLUMN FACTORS (OPTIONAL)

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).
5109341 / Mar 13 10-31

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
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 e xponentiate - they can also use a num ber 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.
5109341 / Mar 13 10-32

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 us ed 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
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.1.
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.
5109341 / Mar 13 10-33

Syntax rules are that either ROW or ROW(0) implies the row total from the internal
matrix. R OW(n) is the total from the n’th .ufm input matrix. D itto 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).
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 pe rformed 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 hi erarchical demand model into a s ingle
5109341 / Mar 13 10-34

composite perceived cost matrix via a “ log sum”. See, for example, equation
(7.27) in section 7.6.3. In principle a l og 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.
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:
(1) Setting a fixed value for all intra-zonal cells
(2) Creating intra-zonal values based on the minimum of all other cells in a row.
More specifically option (2) has been c reated 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. T hey 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 b ased on ei ther 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 pr int copious
5109341 / Mar 13 10-35

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.
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)
5109341 / Mar 13 10-36

10.10.1 Viewing a Block of Cells

Depending on the options selected this option displays on t he 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 c orner” of the display.
Alternatively the cell in the upper left hand c orner may be ex plicitly set via a
“location sub-menu”.
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 i ncluded (space permitting). Equally
the total of all cells appears in the extreme lower right hand corner. Options are
provided such that the row and c olumn 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 s ingle level of a stacked matrix may be
selected for display only.
Post 11.1.14 buttons have been added t o 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!
5109341 / Mar 13 10-37

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. N ote 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 c olumn 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 c olumns. 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. N ote 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 c olumn 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. S ee
10.10.2.
3) and column totals from stacked matrices may be shown “interleaved”, e.g.
the row totals for row 1 f or 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.
5109341 / Mar 13 10-38

10.12 Matrix Graphics

Graphical facilities in MX, unlike PIX, are relatively new and in fact do little more
than duplicate facilities already in PIX (see 11.6.7.2). Essentially two options are
available:
1) Frequency Distributions.
2) Trip Length Distributions
plus a par ameters 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.)
The trip length distribution 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 c osts. ( 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).
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 s preadsheet; 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 S ATURN-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 t rip 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 s preadsheet, as
opposed to simply printing data or transferring it elsewhere within MX.
5109341 / Mar 13 10-39

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 out put as a
single line to an a scii 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.
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. I t 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.
5109341 / Mar 13 10-40

10.15.1.1 SATURN Formats

In case (1) the user may choose one o f the two “standard” SATURN formats
(LONG = T or F) which effectively differentiate between an out put 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
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 r ecord 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 e ffectively 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 l onger (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 r ow are output to a s ingle 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
5109341 / Mar 13 10-41

however that a spreadsheet may be “clever enough” to read alternative SATURN

outputs and that, if you do try to use a s preadsheet, there may be l imits 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 m atrix as 10 200 x 20 s trips, each as
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 N on-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 i n 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 ar e 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 c ircumstances 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”.
5109341 / Mar 13 10-42

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
(assuming “decimalised” outputs) if a m atrix contains inter-zonal travel times
which are of the order of 30 m inutes in units of seconds 2 dec imal 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 out put 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 v ery
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 dec imal places as this corresponds roughly to the
numerical precision of single-precision real variables on t he 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 t hen 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)
5109341 / Mar 13 10-43

procedure described in Section 4 uses this output option after reading a .dat file
(10.5). The output matrix, referred to as Z i n 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).
Output may either be done “as is” (the usual option), as its transpose (although it
is probably preferable to use the matrix manipulation options to transpose it
internally first) or by compressing/expanding/re-coding the output matrix.
The latter options were formerly handled by the SATURN programs M3, M4 and
M5 and the names are retained for ease of identification. In all three cases the
specifications for the new zone structure must be pre-coded on an i nput dat file
whose formats follow the previous M3/M4/M5 conventions. T hese are given in
Appendix W. Note that both M3 and M4 have been effectively superseded by M5.
However note that similar recoding etc. functions are also available interactively
on input, see Section 10.4, and those are preferable in most cases to recoding the
matrix at the output stage.
If the internal matrix is stacked with multiple “levels” a single level may be dumped
as a square output .ufm file, an ope ration referring to as “cutting” a matrix. See
10.4.2 for the reverse procedure to “paste” a square input matrix into a single
level. The same option is also available as described in 10.17.A further option
(post 10.8) allows a matrix of 0/1 to be output to represent the current state of “cell
selection” (10.6). Thus 0 represents non-selection, 1, selection.
Options to change the matrix dimensions and units (10.2.3) and t he title are
available.
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 s tacked either in “levels” or in “blocks” as
selected by the user; see 10.2.4.
A procedure to stack matrices using a p re-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 c olumns could give 4 10 x 10 output
matrices, one per level. Alternatively, post 10.9.20, a single level may be selected
5109341 / Mar 13 10-44

for output as a square matrix, an operation referring to as “cutting” a matrix. See

10.?.? for the reverse “paste” procedure to input a single level.
In Version 10.7 an op tion has been added t o 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 s ingle 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 t rip matrices are
input along with essential parameter values. The r esult 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
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.
5109341 / Mar 13 10-45

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 t herefore 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).
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 pr obably 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.
5109341 / Mar 13 10-46

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.
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 s tandard “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.
5109341 / Mar 13 10-47

10.20.2 MXM2: Compare 2 Matrices

MXM2 mat 1 mat2
Carries out the full set of standard statistical comparisons between 2 .ufm matrix
files mat1.ufm and mat2.ufm and ou tputs 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 l evel 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 m at2.ufm together to produce an out put 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
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
5109341 / Mar 13 10-48

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 hal f” (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.
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 t he 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.
5109341 / Mar 13 10-49

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:
♦ 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
5109341 / Mar 13 10-50

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
♦ 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
5109341 / Mar 13 10-51

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 s tacked. 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.:
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.
5109341 / Mar 13 10-52

10.20.20 MXM5: Matrix Compression, Expansion and/or Reordering

MXM5 mat 1 mat2 contol
Ouputs 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 c ombined
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.1
and in 10.16.
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 t o L2. If L1/L2 are not explicitly included
then all levels are aggregated. See 10.2.4 and 10.4.2.
5109341 / Mar 13 10-53

3 STACK /UNSTACK DVV 02/07/06
3.4.1 V10.7.10 Release DVV NP IW IW 24/04/07
5109341 / Mar 13 10-54

P1X: Interactive Analysis of Results
11. P1X: Interactive Analysis of Results
Mini-Contents Page
11. P1X: Interactive Analysis of Results 11-0

11.2 Network Plotting (P1X): The Master Menu 11-1
11.3 System/device Definitions 11-2
11.4 P1X External File Control 11-10
11.5 The Network Window 11-13
11.6 Basic Network Display 11-17
11.7 Validation Options 11-39
11.8 P1X Analysis Functions 11-44
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-106
11.13 Graphical Network Cordoning 11-110
11.14 Pure Matrix Graphics 11-113
11.15 Convergence Statistics 11-114
11.16 P1X: Technical Specifications 11-114
11.17 SATLOOK: Technical Specifications 11-115
11.18 SATDB: Technical Specification 11-116
5101396 / Mar 13 11-0

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 net work editing, SATED edits simulation nodes
and SATDB provides spreadsheet-like facilities. S ince 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 ac cessed 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 t echnical
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.
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.
On first entry to a run of P1X and on subsequent returns the “master menu” allows
access to a l arge set of sub-menus which may be c lassified into (with further
information given in the sections noted):
5101396 / Mar 13 11-1

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 ac cessed 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 PIX. S ee 19.5. I n addition a n umber 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 t o know the device dimensions in order to
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
5101396 / Mar 13 11-2

“tell” the program about the output devices available to it. I t 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 n umber 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 pr inter 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 s ent 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 al ternative devices. T he default makes them
“screen” and “printer”. Either may be c hanged within the System/Device menu -
see 11.3.3 - although the primary device must always be a t erminal (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).
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.
5101396 / Mar 13 11-3

11.3.3 The System/Device Menu

Having initialised the primary and alternative devices and their characteristics the
System/Device Menu allows one t o 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
(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)
5101396 / Mar 13 11-4

(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.
5101396 / Mar 13 11-5

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 t o 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
5101396 / Mar 13 11-6

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 s et 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 ov er-written within the program (11.3.4). I n 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 t he 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 t he screen. For example they may be ac cessed by the
“paintbrush” program with Windows and by Harvard Graphics and, if necessary,
re-directed to hard copy devices via these programs.
5101396 / Mar 13 11-7

Equally bitmap files may be us ed as inputs to P1X and displayed, e.g. as

“background” to SATURN plots.
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 ex port 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 s et within the Systems/device menu (11.3.3) and a s equential 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 par ameter 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. S ee 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 i nto 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
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.
5101396 / Mar 13 11-8

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! P art 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. T herefore a f inite “thickness” may be s et 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 t hrough the printer
dialog box once if, subsequently, an er roneous return of Cancel occurs the
program goes ahead an d 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
file, rather than the A0 device directly, and onl y spool those print files that you
really need. B ut quite how you spool printer (.prn?) files later on I have no
experience with.
5101396 / Mar 13 11-9

11.4 P1X External File Control

The choice and c ontrol 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 net work .ufs(/ufa/ufn/etc) file (“network 1”) which
determines the basic display plus, optionally, up t o 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 di rectly 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 f urther 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 t o re-run a c omplete
SATURN procedure before re-entering P1X.)
d) A GIS file (see 11.6.10).
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.
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.
5101396 / Mar 13 11-10

11.4.2 Output Files

The following files (in addition to plot files) may all be out put 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 “re-created” version of the original network .dat file obtained from the data
contained in the input .uf* file; see 11.4.2.1.
6) 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.
7) A text (ASCII) file containing, for every “map” link AB (i.e., the lines that
appear on t he 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 5 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 5) 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 t he 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.
11.4.2.2 Lists of Map Nodes

Creating a list of map nodes, option 6 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
5101396 / Mar 13 11-11

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 7) 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 m ay 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 G IS 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 us ed to convert
simulation centroid connectors into a form that could be us ed with a buf fer
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.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.
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 i nput may be s tored in another specific sub-directory. Y ou
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 s hort 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.
5101396 / Mar 13 11-12

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.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.
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 i ntroduced in
10.8. MOVE allows the window to be s hifted 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.
5101396 / Mar 13 11-13

“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 s imilar way the “SCALE” option allows two nodes to be l ocated 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 Y max 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”.
5101396 / Mar 13 11-14

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 i nput 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 al ternative 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. H owever 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
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 r ed
rectangle within the plot, thus showing you where the current window is located
within the full network. See below.
5101396 / Mar 13 11-15

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.
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 i nstant indication as to
where the current window is in relation to the full network.
5101396 / Mar 13 11-16

11.5.6 Setting the Initial Window

By default the initial window set on f irst entering P1X will be t he full network.
However there are two alternatives which may be set via the Command Line:
(1) If RESUME is set on t he 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 nu merical 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 di splayed, 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
relating, e.g., to trees or select link flows will be superimposed on t o 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. Fo r example one
might wish to plot only those links where the flow (in either direction) exceeds,
5101396 / Mar 13 11-17

say, 500 pcu/hr. This could be done b y, 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 l ink 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. T he
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 t o 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. B y default equality or non-equality is based on r ounding 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.
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. A gain all these types of requests may be a dded as
additional AND/OR conditions.
5101396 / Mar 13 11-18

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 c licking 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 o f 11.6.4 and indeed menu
access to this option is available both under Link Selection and Li nk 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 t he shortest path while bus information displays all
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.
5101396 / Mar 13 11-19

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 w here 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 g enerated 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
which case, see below, they are displayed on ev ery 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.,
5101396 / Mar 13 11-20

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 annot ated 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. H owever 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,
9) The GEH statistic as 8) but with a + or – sign.
It is not essential that the files on N ET1 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 net work and t he 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.
5101396 / Mar 13 11-21

Note that the “sense” of the operation implied by options 3, 5 and 6 abov e 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 def ined 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.
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 s ingle “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.
5101396 / Mar 13 11-22

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
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.
5101396 / Mar 13 11-23

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 c onstant “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.
Minimum / Maximum / Fixed Bandwidths

Post release 11.2.4, extra features have been added t o 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/or
c) a maximum width
5101396 / Mar 13 11-24

Thus adding a fixed width enables very low / zero values to become more
apparent, while having a minimum width has a similar impact.
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 g eometrical
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 c hoices 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.
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).
5101396 / Mar 13 11-25

11.6.3.5 Single (Uniform) Colours per Data Item

By default each data item is assigned a s ingle 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 al l data values up t o and i ncluding -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 i s 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.
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,
5101396 / Mar 13 11-26

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 abl e to indicate links whose, e.g., speeds are
within a c ertain range by a s et of colours. T his 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).
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).
5101396 / Mar 13 11-27

11.6.4 Link Display Options

By default a l ink is represented as a s traight line joining its A-node and B -node
(generally) in black on a w hite 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 ent ered 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 hi ghlighted, e.g. by the use of “zig-zag”
lines or by solid in-filled bands whose width and colour are user-set.
6) Links may be dr awn 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 e xcluded from plots (or, less usefully, only
centroid connectors may be plotted); by default both “real” links and centroid
connectors are included. E qually 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
banner. (If the lanes appear too large or too small by a f actor 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 r e-set to provide more or less “width” as
required
5101396 / Mar 13 11-28

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 ei ther “solid” (i.e.,
in-filled) or “open”. If, however, numerical node dat a 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
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 w ide range of node “input properties” such as the
offset or cycle time at signalised nodes as well as a wider range of “output” node
5101396 / Mar 13 11-29

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 de fined 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.
“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
5101396 / Mar 13 11-30

(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 l ink entering a no de 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.
11.6.5.2 Node Bandwidth Colours

The colours used to depict node dat a via bandwidths may be det ermined by a
variety of rules. The simplest is to use a single colour (or, strictly speaking, a
single colour for positive values and anot her for negative). Alternatively, as with
node shapes, a bandwidth colour specific to the junction type may be set.
Alternatively the colour may be det ermined 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
5101396 / Mar 13 11-31

100 to 200 i n 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 i n 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 al l 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 t he “size” of the output device and m ay appear differently on t he
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.
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 t reated 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.
5101396 / Mar 13 11-32

Thus under a) one m ight 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 t he basis of numbers; e.g., select those nodes whose
numbers are between 100 and 200.
Option d) provides a s omewhat 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 us ing 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 s election 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
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 det ected, the difference in this case
being that not necessarily all errors detected by SATNET are displayed, only
5101396 / Mar 13 11-33

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 l ocating 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 g raphics. In addition, the same “loop” may be i nvoked 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.
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;
5101396 / Mar 13 11-34

(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 a rrow with a per pendicular bar at the end i s 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 v ia 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 us er 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 c olumn 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 w ith 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.
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 t o 69 ( inclusive) and
destinations 70 to 89, in which case the only matrix elements to be considered in
the row/column summations would be t hose in the “rectangle” containing the 10
origins and 20 des tinations (200 o-d pairs). Selection therefore changes the
values of the numerical values displayed.
5101396 / Mar 13 11-35

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 t o 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 r ow/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. T his 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).
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.
5101396 / Mar 13 11-36

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 ex tra 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.
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;
5101396 / Mar 13 11-37

♦ 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!). U nder 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 G IS 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 opt ions above
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 s imilar fashion to
using SATURN-set GIS data as background. Bitmap backgrounds have the
5101396 / Mar 13 11-38

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 t he 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 num ber of different locations within SATURN and in a num ber of different
ways as explained in 15.6. U nder P1X Validation both numerical statistics and
graphical scatterplots may be obt ained 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 net work 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 s ingle data set may be no minated under
disaggregation.
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.
5101396 / Mar 13 11-39

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. T hus 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.
Note that the same set of options may also be i nvoked under option 13 o f
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.
5101396 / Mar 13 11-40

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 intended to be us ed 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.
11.7.2.1 The Definition of 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 i nternal simulation link where there is, by definition, no ex it 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 s et interactively within the joyride
options or pre-set within the preferences file p1x0.dat; its default is T.
11.7.2.2 Joy-Ride Displays

The outputs are not dissimilar to those produced by the Joy Ride or Bus Route
analyses. For example the routes may be di splayed one l ink at a t ime 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 t iming point has been
provided a box appears on the plot with both the timing point and the cumulative
modelled time displayed top and bo ttom respectively. T he 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 i nfluenced by its application to “true” (positive frequency) bus
routes and i ndeed 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.
5101396 / Mar 13 11-41

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 pl otted 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 di stance 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).
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 c ompared 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 hi ghly recommended in practice). S preads are
(optionally) input in the second input field within brackets in the network 66666
records (see 6.9.5).
Optionally the node annot ation at each point may be di splayed, 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.
5101396 / Mar 13 11-42

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.
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.
5101396 / Mar 13 11-43

The data items thus created may be annotated on each individual link in order to
give an ov erall 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 par ticularly appropriate display format may be s elected, code name
“Hallmark”, which uses a bandw idth 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 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 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.
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 t he 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 nodes;
5101396 / Mar 13 11-44

♦ 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 s elected, a r oute 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 t he 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 s elect 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).
On the other hand i t 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 t aken with a l arge
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 t he links are not explicitly calculated or
displayed. The “Matrix - Yes” / “Matrix - No” option toggles between them.
Link flow data may be s aved in the internal (SATDB) data base, either
automatically or optionally once created.
5101396 / Mar 13 11-45

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 m atrix. 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 de fined, 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
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 t he 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).
5101396 / Mar 13 11-46

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 s et of more than one l inks, 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.
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 four 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.
Under options (2) and (3) turns may also be included. In all four 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 c omma or a s pace. 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).
5101396 / Mar 13 11-47

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 tptals, 2,500, equals (in this case) the flow 500 which uses both. (N.B. This is
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 s et 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 c hooses 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).
5101396 / Mar 13 11-48

11.8.1.11 Multiple Links SLA

Selecting a set of “multiple links” for SLA is effectively the same as slecting a
number of single links in succession, the main difference being that the SLA
calculations are carried out simultaneously with a c orresponding increase in
efficiency. Thus carrying out an S LA 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 di splayed on t he
network plot immediately after the SLA has been carried out.)
There are strong similarities between Multiple Links and S creen Line SLAs in
terms of inputs. Thus both may define their particular sets of links either one at a
time using the mouth, 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 c ertain 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.
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.
5101396 / Mar 13 11-49

Thus it is now possible to carry out an SLA on, e.g., only links which are
downstream of a s elected link and which, therefore, would be t he 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.?.
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 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.
Note that “delay” as displayed within the banner is defined to be t he 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”.
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.
In the event that the joyride route contains “penalties” - as defined under the
44444 records - then these too are recorded. 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.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 des tination 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:
5101396 / Mar 13 11-50

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 i terative 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.
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.
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.
5101396 / Mar 13 11-51

Trees may also be displayed “in reverse”, i.e. into a destination as opposed to out
of an or igin. 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 no minated 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
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).
5101396 / Mar 13 11-52

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 t he 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 s et; e.g., 20 kph. (Change the namelist parameter
WALKPH in P1X0.DAT.)
5101396 / Mar 13 11-53

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
This data 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 da ta could be m anipulated internally as desired; see

11.10.5. For example, the node minimum costs could be displayed using any
of the standard node di splay options (11.6.5). Alternatively, one could do
things such as calculating the isochrone minimum cost to several zones
representing, say, hospitals so that taking the minimum over several data
5101396 / Mar 13 11-54

columns would then give you the (minimum) cost from every node t o 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 w orst 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 m easure 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)
5101396 / Mar 13 11-55

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 s imulation 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 l arge 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
5101396 / Mar 13 11-56

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

These are described in sub-sections 11.8.4.2 to 11.8.4.9.
11.8.4.2 Interactive Information: Links, Nodes, Zones and Buses

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 options are available with buses. Firstly, individual bus routes are displayed
using both numerical data (in the banner) and a link-by-link graphical (“joy ride”)
display (see the figure below). S econdly, 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 pr ovided e.g., annotate the total bus flows per link,
names of the bus routes, etc. etc,; requests to DVV.)
All these functions are “look only”, i.e. no editing is possible.
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
5101396 / Mar 13 11-57

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 l inks 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.
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 es timate 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.
5101396 / Mar 13 11-58

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.

The data fields include both inputs to SATME2 such as the counted flows and
outputs such as the post-ME2 flows, the Xa 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
5101396 / Mar 13 11-59

6) edit bus routes

7) edit counts
8) edit the generalised cost definitions
9) update namelist parameters/options
10) convert buffer nodes to simulation
11) make (global) changes to traffic signals including:
− optimise all signalised green stage times and/or offsets
− transplant signal settings between networks
− update stage times and of fsets (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 c arried 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 bui lt by running SATNET. T his 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:
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.
5101396 / Mar 13 11-60

♦ an updated .dat network file;
♦ an updated .ufs file;
♦ 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 s pecially 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 o f 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 et c. 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 node s/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.
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.
5101396 / Mar 13 11-61

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
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 ouput 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 f ile
newnet_11111.dat would contain all the 11111 simulation network data and t he
11111 data set within newnet.dat would contain a s ingle 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 t ext 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.
5101396 / Mar 13 11-62

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 –
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 new ly
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 t he 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 p roblem 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 di rectly 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 s ignal (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 edi ted 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.)
5101396 / Mar 13 11-63

At any point the node may be re-simulated and the effect of the changes viewed
as under SATLOOK (11.11.1).
The “Error Listing” gives a l ist of those errors which would be detected within
SATNET if the current net node c oding 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. N ote 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 t urns allows topological changes at the
simulation node and t he 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 ar e 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 da ta records result in changes to the centroid connectors.
Strictly speaking therefore they are more akin to PMAKE than to, say, node
5101396 / Mar 13 11-64

editing but they are documented here (as well as in 18.7) since they are accessed
from the same menu as node editing.
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 ex isting zone from
the buffer to the simulation network.
However invoking any of the options above will change the location of the centroid
connectors and henc e the definition of the map network “topology”. H ence this
option is like PMAKE in respect to topology such that, once changes are made
here, certain restrictions on w hat further steps may be t aken 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 z one which is connected to an ex ternal 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.
5101396 / Mar 13 11-65

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 edi t box to make changes to the
time(s), distance, etc.
5101396 / Mar 13 11-66

Note that link properties which are “added” within SATURN, such as flows or the
speeds/times at those flows, cannot be edi ted 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 r ecords 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 al tered by selecting the node with the
mouse and pointing to the new position. T hese 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 s et
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 par ticular study area to share a common
definition of nodes and co-ordinates. This saves the need to edit a wide range of
.dat files.
5101396 / Mar 13 11-67

Note that a s upplementary “.xy” sub-file may also be an i nput file to P1X. An y
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 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 ex isting route (or equally a r oute which has been c opied from an
existing route and renamed) has several sub-options which may be f urther 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 ne w 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.
5101396 / Mar 13 11-68

11.9.9 Editing Counts

Counts (whether on links or turns) may be either:
a) Added
c) 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 dat a 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 del eted, 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 par tially 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 dat a 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 i nvoked 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 s imulation-based
parameter such as LTP will not change the manner in which simulation nodes are
5101396 / Mar 13 11-69

modelled anywhere within P1X. However, post 10.5, the changes may also be
applied internally and would therefore be included on an output .ufs file; a “toggle”
is provided within the relevant P1X banner. This may be us eful if, for example,
one wished to change, say, ISTOP before doing a c ontinuation 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 appl ied 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. H owever it needs to be s tressed 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.
5101396 / Mar 13 11-70

In particular adding link capacity restraint data – which basically reproduces the
buffer link’s speed-flow curve – is seen as a “quick and di rty” technique. It may
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 bes t to initially code the junction as a pr iority 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 c orrectly coded node des cription 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 a s 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 i dentified 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 bu ffer 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 t o be c oded within the 11111 r ecords since if the
parameter AUTOX = T (see 15.12) then they will be automatically recognized as
5101396 / Mar 13 11-71

external nodes by SATNET. It is therefore assumed that AUTOX will be T and no

extra entries are added under 11111.
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 o ther 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 pr iority node and ei ther added t o the 11111 dat a 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 c ombined 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 s ingle set of signals via node editing. Either or both may be
selected in the above order.
5101396 / Mar 13 11-72

Note that a further option then allows for a full network re-simulation since that
may in turn affect the signal optimisation and an i terative loop between
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 c ould 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 updat ed 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
5101396 / Mar 13 11-73

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).
Once created a .rgs file may be read by P1X (only) and its signal settings used to
replace those in the current network. (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 ac complished 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.
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 i s
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 i n
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 i n the
simulation node data formats (6.4.1).
Differences at one l evel 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
Windows edit box where it may be edi ted 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
5101396 / Mar 13 11-74

records to add an ex tra buffer link that link will not appear on t he 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 w ithin 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 s et “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 t ransferred en m asse 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 k ph. This method is therefore simpler
than having to set an extra list of all desired links with the attribute 45.
Alternatively, the data may be c reated by a c ombination 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.
5101396 / Mar 13 11-75

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 t urn data “A B C data …”. In all cases the “data” may
contain several different fields (e.g., link distance, link speed, etc. etc.) and t he
user must then define each individual data item in the list.
Similarly node dat a must be t ransferred 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 app lied 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 bu ffer 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)
♦ Number of lanes
♦ Stacking capacity (pcus)
5101396 / Mar 13 11-76

♦ 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 s ub-program within P1X. The former is useful for
operations that do no t 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 don e 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 t hought of as a matrix of rows and c olumns as illustrated
below:
(link) A B C D1 D2 D3 ...
1 a1 b1 d11 d12
2 a2 b2 c2 d21 d22
...
L
5101396 / Mar 13 11-77

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 c entroid connectors in both the buffer and s imulation
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 t he flow on l ink 1, d 12 the time on l ink 1 et c. 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 nu mber 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. I n addition certain data values may be “ missing” in
which case they are displayed by an “ m”; for example a dat a 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 t o add an al ternative 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
options available to the node data base closely parallel those available to links.
Section 11.10.5 gives further details.
5101396 / Mar 13 11-78

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). Fur ther documentation is
contained in the sub-sections noted and within the Help system available
interactively.
1) FILES MENU
This option allows the definition and r eplacement 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 t o 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 can
not 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)
The “Special Menu” offers a range of functions for inputting new data columns
from either uf* or other files, including:
5101396 / Mar 13 11-79

♦ 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 al gebraic
expression involving existing data columns or by invoking the time-flow curves
within SATURN to calculate the link times corresponding to flows in an ex isting
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
SATDB in order to use a local edit program to change the scratch file, and
5101396 / Mar 13 11-80

then re-enters SATDB in order to re-read the file and r eplace the old data
base. (But see Option 15 below.)
10) STATISTICAL ANALYSIS
Two forms of analysis are available: either a uni variate analysis of a s ingle
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)
5101396 / Mar 13 11-81

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. I n addition a num ber 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. E qually 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. T hus 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.
5101396 / Mar 13 11-82

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 t o store it as link data. T hus 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 r ange 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 ac cessed 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 c orresponds 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 i s 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.
5101396 / Mar 13 11-83

If you are still confused the diagrams in Section 16.6 may help!
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 i s the link in the buffer network from node 2 t o 3 w hile link 9 i s a
centroid connector in the buffer network from node 6 to zone 23.
11.10.5 The SATDB Node Data Base

The node dat a 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. Fo r
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 dat a base consists of the nodes
represented in the map network, i.e. zones, simulation nodes (all types) and buffer
nodes. T hus 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 ex isting columns, carry out basic statistical
analysis, select a s ub-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 l ist of the nodes
and/or zones to be selected.
Data input from one o r more network files is by selection from a l ist of named
parameters (delay, flow etc) rather than via DA codes as is the norm with link
data. A ppendix 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 ar ray in the node dat a 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 annot ated within P1X. T he
system of node selection (11.6.6.3) is common between the two.
5101396 / Mar 13 11-84

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 num erical 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 i nput. 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 r oute 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 t o new
columns in the data base.
Thus each record consists of two “parts”:
(i) Link identifiers
(ii) One or more data values
5101396 / Mar 13 11-85

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 bl ank or a c omma (“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 us ed 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
5101396 / Mar 13 11-86

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

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
♦ 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 s elected 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
♦ 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.
5101396 / Mar 13 11-87

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 or igin to one (or all)
nodes/zones in a net work; 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 t he definition of link costs upon w hich 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 o f) each link or to “skim” an al ternative 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 t he
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
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.
5101396 / Mar 13 11-88

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 l oaded “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 t he case (as discussed below) with a ne w 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 l oaded 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 r outing 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
network and the total number of trips generated by the site. It avoids the need to
add a z one to the network and m atrix 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 us ed 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.
5101396 / Mar 13 11-89

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 dat abase and t he 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 di splayed 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 ne twork which has been t hrough 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 s imulation 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
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
5101396 / Mar 13 11-90

be assigned need not be the same. S ee also 15.37 for further suggestions for
use.
Further options allow only “part” of each path to be l oaded 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 as signed either by
specifying upper and lower zone limits for origins and/or destinations or, post 10.7,
by specifying upper and l ower sectors. ( More complex “selected” assignments
may be obt ained by modifying the actual trip matrix to be as signed, 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 di splayed 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.
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.
5101396 / Mar 13 11-91

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 d one 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 s lightly different interpretation within
SATDB. H ere it enables one t rip 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 t o 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 us ed to derive new corresponding link travel times (see also
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 bas ed on full o-d
routes or a “partial-route” assignment may be carried out.
Full v Incremental Loads
5101396 / Mar 13 11-92

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.
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 t he selected link(s). Why? Consider a single o-d
pair with 10 t rips which uses two routes 50:50, 5 t rips on eac h. If a s elect 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
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 v ia 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 s election is in force (option 2, 11.10.2), only to those currently selected.
5101396 / Mar 13 11-93

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 e xisting 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. S econdly, 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.
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.
5101396 / Mar 13 11-94

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 l ink may be as sociated with
each turn at the end o f a link and t hen (separately) added t o 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 t urn and s et that as a l ink
property.
Note that under the node data base link data may be further aggregated into node
properties using either of the 3 opt ions above. Hence turn data might be
aggregated by link and t hen 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. S ee 11.10.1. I n certain situations it is desirable to assign
numerical values instead of missing values, e.g., when doing a num erical link
selection test. Option 6 al lows numerical values to be s ubstituted 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 s election 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.
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.
(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 bu t are now largely
redundant since the .dbd file format is a good deal more restrictive and SATURN-
5101396 / Mar 13 11-95

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 l ower 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 num bers 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.
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;
5101396 / Mar 13 11-96

♦ 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 o f the column listings and i n 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
♦ 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
5101396 / Mar 13 11-97

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. E qually each output column may be assigned a ne w 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 no t be s elected 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.
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. G enerally one needs to choose a
non-standard and unus ed code but also one l ess than 5003. R ecommended /
“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
5101396 / Mar 13 11-98

statistics from the simulation phase may be pr inted 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
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 f urther 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.
5101396 / Mar 13 11-99

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 edi ted) or as contained in a second
input network file for comparison purposes. 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). See 11.11.18 for the same option over all
simulation nodes.
Release 10.9 includes an option to list the standard simulation and/or simulation-
assignment convergence statistics per node/link/turn; see 9.9.2.
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. T hese problems
are due t o a l ack 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 bu ffer 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.
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 i n 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 ent ry and e xit 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.
Note that these figures may be obtained in three basic ways:
1) Using the aggregate data calculated within SATALL (or
SATSIM/SATEASY) and stored on the .ufs file;
2) Calculating the same totals explicitly here from, e.g. the basic flow and
time/distance per link arrays.
5101396 / Mar 13 11-100

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. A nother is to use the node-based
selection to produce statistics for, say, all signalized junctions.
Disaggregated Summary Statistics
With all options the outputs may optionally be disaggregated over Capacity
Indices (if they exist within the network; see 5.1.9). E,g., you may obtain total
pcu-hrs by all links which have a Capacity index of 1, 2, 3 etc. etc. (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.)
However, it is also possible with option 2 t o 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 as cii 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 these options are 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) Files
Post 10.8 an option exists to output the full (“headline”) set of summary statistics
as a text file in CSV format. The first record contains asset of (fairly succinct)
column headers. Each subsequent record corresponds to a different set of flows
and/or a different level of disaggregation as above.
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
5101396 / Mar 13 11-101

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.
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 l arge 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 t rips
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 t he 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 r educed
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.
5101396 / Mar 13 11-102

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
5101396 / Mar 13 11-103

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 us er-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 opt ional 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. T ravel 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 t he
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.
5101396 / Mar 13 11-104

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 net work validation, is much more conveniently catered for by the
pure graphics displays in PIX; see 11.8.3.
On the other hand t his 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. Fo r
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 PIX (see 11.8.2) and ar e therefore largely
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 t o calculate a c row-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 PIX.
11.11.18 Comparison of Simulation Node Coding

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 i ntroduced in an
5101396 / Mar 13 11-105

updated network, particularly if standards of documentation are not as good as

they should be!
The list of nodes numbers may be ex tended to a c omplete 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 di splayed 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 ac cessed 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 pr ior
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.
5101396 / Mar 13 11-106

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 r epresentative 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 pr iority
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 gray while the background of
each “block” is filled in dark gray; 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
5101396 / Mar 13 11-107

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 g reen “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 or to carry out a microsimulation demonstration
run of the node using DRACULA (see also 11.13.8);
♦ 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 de lays) as a
standard option plus the last table displayed as a further explicit menu option;
♦ To “print” the node des cription 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).
5101396 / Mar 13 11-108

♦ 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 ex amine their impact by re-simulating
that node in isolation.
♦ They may convert a b uffer node as read from an i nput 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 af fected 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
5101396 / Mar 13 11-109

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 s elect the links they cross or by a r ectangular
“box” which cuts selected links. I t may also be set by a pr eviously 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 w hich is used to
distinguish the inside of the cordon from the outside; see the parameter MIDDLE
described in note 1 i n 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.
5101396 / Mar 13 11-110

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 ne twork .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 t he 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.
♦ Run a short demonstration of DRACULA on the cordoned network. (11.13.8)
♦ Define capacity indices within the cordoned network (11.13.4).
5101396 / Mar 13 11-111

♦ Use the cordon to “select” either those links and/or nodes inside or outside for
further analysis with P1X; see 11.13.3.
♦ 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. E qually 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 f or
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 s elected 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.
5101396 / Mar 13 11-112

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.
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
as required by DRACULA. 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.13.8 DRACULA Demonstration

By dumping a c ordoned network .net file and the corresponding route file (.trp)
into standard files with the formats required by DRACULA it is possible to run a
short demonstration of the DRACULA micro-simulation model for the cordoned
area. This option utilises both the “network output” and “routes files output”
options to generate the minimum data files required for a run of DRACULA.
A similar option, but for a single node in isolation, is also available through node
graphics animation (11.12.3).
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 c onnection with the spatial location of the zones. S patial 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.
5101396 / Mar 13 11-113

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.
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 s ignalised 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)
5101396 / Mar 13 11-114

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)
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)
5101396 / Mar 13 11-115

15/14 Terminal (both input and output) (Mandatory)

28 Output UFM files containing the inter-zonal
29 Skimmed matrices, e.g., time, cost, etc.,
30 or crow-fly distances. The f irst 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 m ay be us ed 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)
5101396 / Mar 13 11-116

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)
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 ei ther
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 i n cols. 1 - 5. I nitial 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 s ingle 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 ent ries
occupy 10 columns, not 5, and the data values commence in Column 31; see
Section 15-20.
5101396 / Mar 13 11-117

2 L4L Added DVV 28/05/06
5101396 / Mar 13 11-118

Supplementary Programs
12. Supplementary Programs
Mini-Contents Page
12. Supplementary Programs 12-0

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-17
12.5 Transferring UF files (DADUMP and DALOAD) 12-17
12.6 SATPIG: Generating Route Flows 12-18
12.7 SATDYSK - Dynamic Time Skims 12-21
5109341 / Mar 13 12-0

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 o f 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 c hange 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. H owever it may be nec essary 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.
5109341 / Mar 13 12-1

Figure 12.1 - Use of SATCH
12.1.2 SATCH Files

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 f or the cordoned network for input to SATNET.
(Optional - DONET = T)
8 Input DAT file containing the data from the original network as
input to SATNET. (Optional - DONET = T)
5109341 / Mar 13 12-2


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

This input file (which is mandatory) contains all the “control” information required
by the program in addition to the network and matrix information which is input via
the network .ufs and matrix .ufm files.
RECORD 1 - SATCH NAMELIST OPTIONS (&PARAM) (MANDATORY)

Option Type Default Interpretation
MIDDLE Integer 0 A node number which is inside the cordon (in order
to distinguish ‘inside’ from ‘outside)
NOMAD Integer 1 The ‘matrix sub-level’ to be used if working with
MUC assignment if ALLUC = F ; see 12.1.6
MODET Integer 1 If ne 0 diagnostic messages are output to the
terminal
DEMAND Logical FALSE If TRUE any output trip matrix is in terms of ‘demand
flows’ (as is the input matrix); if FALSE the output
matrix is in ‘actual flows’. See 12.1.9.
DONET Logical TRUE If TRUE a network DAT file is output to channel 7
using data read from channel 8.
DOMAT Logical TRUE If TRUE a UFM trip matrix file for cordoned network
is output to channel 4.
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.
5109341 / Mar 13 12-3

Option Type Default Interpretation

INCLUD Logical FALSE If TRUE the output cordoned network file has each
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.
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 i ncluded 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 de fined as the A-node, but the program will later
redefine the A-node as being the node which is ‘inside’ the cordon and the
B-node as being on the ‘outside’.
c) The links are those that are ‘cut’ by the cordon as opposed to a continuous
set of links that are themselves the cordon.
5109341 / Mar 13 12-4

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 ar e 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. H ence 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.
5109341 / Mar 13 12-5

Holes can be detected by analysing the printed set of ‘back-nodes’. I f

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 bu ffer links (if both exist or else
clearly just the one type). The cordoned network includes both simulation and
buffer components as appropriate. I t 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 r eached 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 N ODEF
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.
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 def ined. 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.
5109341 / Mar 13 12-6

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 net work 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 c opies to the output data file on
channel 7:
(i) Any ‘general’ records, e.g. the &PARAM cards;
5109341 / Mar 13 12-7

(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 c ard) but then no dat a appears. SATNET might - with
some justification - take umbrage at this apparent thoughtlessness on y our
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 c ounted 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 t raced 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.
5109341 / Mar 13 12-8

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 i ncluded 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 PIX

SATCH is basically a “ batch” program; however most of the functions available
within SATCH are also available within PIX, in addition to the ability to define a
cordon as mentioned in note 14, Section 12.1.4.
Thus having defined a cordon in PIX options exist (see 11.13) to:
♦ Produce an output cordon.dat network file as under the DONET option within
SATCH.
♦ Produce an output cordoned .ufm trip matrix, analogous to DOMAT (but

probably with smaller limits on the maximum number of output zones).
5109341 / Mar 13 12-9

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. Fo r 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 l onger 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 onl y 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 s et for ALLUC and N OMAD 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.
5109341 / Mar 13 12-10

In addition, if NOMAD > 1, then no out put network .dat file is created on t he
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 f actored prior to assignment due t o 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 r e-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 t hat link. D ifferences between the two may be due t o
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 ac hieved. S tatistics 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
5109341 / Mar 13 12-11

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 F URNES 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 i n 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 c ordon cut link (i.e., a ne w 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 as signed a new node nu mber and l ocation. 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 Ian Wright 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.
5109341 / Mar 13 12-12

12.1.12 SATCH Batch Files

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

The relative offsets between intersections can be readily set on-line in response to
traffic conditions. In practice, this needs flows to be continuously monitored and
optimal solutions updated. On the other hand, the problem is more difficult in
modelling for a future year or an al tered network since there are no observable
flows on which to base signal settings. T he central hypothesis is that optimum
network offsets can be determined which, to a g ood 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.
5109341 / Mar 13 12-13

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 f ull run of SATURN is carried out, resulting in a f ile
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.
Figure 12.2 - Use of SATOFF
(The box denoted by SATASS / SATSIM is, in current versions of SATURN,

simply an appl ication of the single program SATALL which carries out both
assignment and simulation.)
5109341 / Mar 13 12-14

At this point two alternative ‘loops’ may be us ed: 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 obt ained after a s ingle 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
itself such that an upda ted and r e-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 ou tput .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.
5109341 / Mar 13 12-15

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 t o be fixed and al l 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 t o, 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”.
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 r ange 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 net 2.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 appr opriately set control file in order to select the same basic
steps as in SATOFF
5109341 / Mar 13 12-16

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 det ermined). For ‘normal’
users the same information is much more conveniently supplied by SATDB which
will not only give values for all items in an array such as the link volumes in 4503
but also lists it in a table along with the link A-node and B -node. On the other
hand DALOOK is more convenient to examine the contents of ‘non-link-based’
data arrays.
To run the program using standard procedures type:
DALOOK LIVNET
or
DALOOK I
to run fully interactively.
12.4 Direct Comparison of UF Files (DACHEX)

DACHEX enables users to compare two UF files element by element and to print
out summary statistics of which elements differ and by how much. Like DALOOK
it is essentially a pr ogrammer’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)
5109341 / Mar 13 12-17

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.
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)
5109341 / Mar 13 12-18

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
31-40 Route flow (pcu/hr) in format F10.2 (i.e. decimal in
column 38)
41-50 Number of nodes in the route
RECORD(S) 2:
The series of nodes making up the route in format I10, i.e. up to eight nodes per
line, 10 columns each.
♦ TRPFOR = T each set of records is output using the .trp format conventions
adopted by DRACULA such that:
RECORD 1:
Cols 1-10 Origin zone (name)
11-20 Destination zone (name)
21-25 User class number (NOMADS>1)
26-35 Route flow (pcu/hr) in format F10.2 (i.e. decimal in
columns 33)
36-45 Fractional route flow in format F10.6
5109341 / Mar 13 12-19

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).
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 pat h 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.
5109341 / Mar 13 12-20

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 c ome
first (with a 1 i n 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.
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 ne twork 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 m inute interval is user-set. B y 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
5109341 / Mar 13 12-21

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 t o use that as
part of a peak-spreading model.
The “skims” are based on calculating minimum time routes independent of
whether or not the original assignment model was based on pure time or
generalised cost so the paths found are not necessarily those used by the original
model. In effect the original model is simply being used to generate a set of
dynamic link times and/or delays by clock time.
12.7.2 Instantaneous Link Travel Times

The instantaneous or dynamic estimates of link times as a function of clock time
are based on the sum of two components:
♦ Transient travel times (i.e., V < C)
♦ Queued delay (V >C)

Transient delays include both delays at junctions (turning movements) and
speed/flow delays on c apacity-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 del ays after the last mid-point (9:45) are
5109341 / Mar 13 12-22

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 e stimated 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 w ants 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).
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 i t probably should be c hanged, in the arrival-
based or backwards mode each row of the output matrix represents skimmed
times for a des tination so that e.g., the Jth element in such a row would be t he
time FROM origin J to that destination. I n 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
5109341 / Mar 13 12-23

12.7.5 The SATDYSK Control File

Similar to other control files it is based on namelist input (see App.A) with “name”
&PARAM. The following variables, with their type and default values may be set.
Variable Type Default Function
DEPART L T If T skims are based on departure times; if
F on arrival time
NTOM I 10 Number of arrival/departure skims
TOM I 600.0 Time in seconds between skims
E.g.:
&PARAM
TOM = 30
DEPART = T
&END
Note that the values of TOM and NTOM should presumably reflect the total length
of the time period modelled. Thus the defaults cover a range of departure times of
6000 seconds, 1 hour and 40 minutes. If the model were of three 30-minute time
slices then the last two skims would probably be redundant; if the model covered
2 hours then the range would probably need to be extended.
12.7.6 Running SATDYSK

To run the program you must first have run a multiple time period simulation; e.g.,
SATTPX net 4
SATSUMA net 4
followed by:
SATDYSK net
The bat file SATDYSK uses the following files:
net.uft Input network file
net.ufm Output skimmed matrix file
net.LPV Output line printer file
SATDYSK0.DAT Control file (12.7.5)
5109341 / Mar 13 12-24

5109341 / Mar 13 12-25

Deriving O-D Demand Data from Traffic Counts (SATME2)
13. Deriving O-D Matrices from Traffic Counts

(SATME2)
Mini-Contents Page
13. Deriving O-D Matrices from Traffic Counts (SATME2) 13-0

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-39
13.5 SATME2 Technical Specifications 13-46
13.6 SATPIJA - Technical Specifications 13-48
13.7 SATU2 - Selected Link Matrices 13-50
13.8 “ME2” Output Files 13-51
5109341 / Mar 13 13-0

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 t he 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 o f the two main inputs and that (b) the main output of the
process is modelled flows.
Figure 13.1 – Structure of Assignment Models
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
5109341 / Mar 13 13-1

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
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)
5109341 / Mar 13 13-2

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 s pecial case of link constraints and as such may be i nput
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 t he 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.
5109341 / Mar 13 13-3

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 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 t o entry and ex it flows from zones (but not on specific
centroid connectors). A ll 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.
5109341 / Mar 13 13-4

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
5109341 / Mar 13 13-5

by SATME2 as demand flows and any corrections due to flow metering are
ignored.
Alternatively, if counts are “corrected” using the 11111 dat a 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 i f it
were processed within SATPIJA. Some care may be necessary here if that is not
you intend.
N.B. Table 1 w ithin 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 s ingly- 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 c olumn 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 pow er 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 a fter ME2 is applied,
their changes and (if appropriate) their constrained totals.
5109341 / Mar 13 13-6

Note that there nay be s ignificant advantages to running an M X 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 t he 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 m ethod has yet been i mplemented to impose a m easure 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. T he 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 i nput via a m atrix 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 I CEME2 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 l ink 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
5109341 / Mar 13 13-7

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 ab solute 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 m atter
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.
5109341 / Mar 13 13-8

This option may help to correct errors and/or inconsistencies introduced by the
assignment. It may also be us ed 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 t rip matrix which can simultaneously satisfy both counts and as signed
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 c ombined into a s ingle
constraint are listed within a s ingle 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 l onger applied as an i ndividual constraint, only as part of the combined
constraint.
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 c ombined 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 dr iver is highly unlikely to use one link and then
back-track in order to use the second. On the other hand a s creen 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
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
5109341 / Mar 13 13-9

(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.
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 w here both paths
come together. H ence the balancing factors at points 1 and 2 ar e raised to a
power 0.5 (i.e., square rooted).
Figure 13.3 – (A) A single o-d path with three count sites
5109341 / Mar 13 13-10

(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 i n 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
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.
5109341 / Mar 13 13-11

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 i n 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 s et of PIJA factors when it is assigned it will b e
assigned to different paths and/or different path proportions from the original
matrix and henc e a ne w set of PIJA factors will result. This feed-back effect
introduces a c onvergence problem in that we seek to find a t rip matrix which is
compatible with a s et 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
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 s uch 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 t o “soften” the changes in the trip matrix by
5109341 / Mar 13 13-12

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 r elated 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 ac hieved. An extreme example of this is a
bottleleneck 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.
13.1.11 When to use SATME2; Initial Calibration Steps

It must be strongly emphasised that SATME2 should only be appl ied after all
other possible forms of validation on t he network and or iginal trip matrix have
been carried out. In effect ME2 attributes all differences between observed and
modelled counts to errors in the trip matrix and at tempts 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 r elatively 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 c ounted link with zero
modelled flow but a positive count.
5109341 / Mar 13 13-13

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 z ero 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 i n 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
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 r atio 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. O n the other hand i t might be t hat 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 w hat 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.
5109341 / Mar 13 13-14

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 i n .LPM) then a S erious 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 a ttempt 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.
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 i ntroduced. A gain, 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 di scarded 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.
5109341 / Mar 13 13-15

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 3.19c 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 T ij pairs
F - Analyse only positive T ij pairs
See note 7.
DUTCH LOGICAL F T - Link/turn records 2 below are
formatted according to the
DUTCH options (15.20).
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 P ija
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;
5109341 / Mar 13 13-16


See 13.4.6.
CHECKS LOGICAL F T – Carry out checks on the input
data only – no output .UFP file will
be produced
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)
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.
5109341 / Mar 13 13-17

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 r ecords
(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 t wo 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 c ount 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.
5) Alternatively, if UFFLOW = F and the counts are to be included on the control
file, then they may be s et in an ex ternal 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 s tacked (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)
5109341 / Mar 13 13-18

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 s eparate 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.
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
5109341 / Mar 13 13-19


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 c olumn 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)
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
5109341 / Mar 13 13-20


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 r ecord. D ata sections must be in increasing
numerical order and not all sections need t o be included - indeed no a dditional
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:
Cols. 1 - 5 The A node
Cols. 6 – 10 The B node
Cols. 11 – 15 The C node
Cols. 17 The (new) constraint type:
L – Less than
E – Equality
G - Greater than
Or
X - Exclude from the calculations
Cols 18-25 The (modified demand) flow in pcus/hr
5109341 / Mar 13 13-21

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 i nput 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 c olumns not 5. N ote
equally that if DUTCH = T a di fferent 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
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
5109341 / Mar 13 13-22

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 bet ween these zones will be the same in the final and pr ior
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 t o include the first and l ast sectors in columns 2-5 and 6 -10.
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.
5109341 / Mar 13 13-23

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 l ist 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 t wice the
number that appears in columns 11-15 up to a maximum of 12 per line.
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
5109341 / Mar 13 13-24

is input within its own “header” 66666 and “ trailer” 99999 r ecords 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
RECORD 8 MATRIX TITLE (MANDATORY)

Cols 1 - 76 A title for the new output matrix.

Thus an input data file might read:
RUN TEST SATME2 RUN
&PARAM
SEED = 0.5
STATS = T
PRINT = T
&END
5109341 / Mar 13 13-25

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
4 G 700
2 L 400
24 E 900
20 1500
99999
33333
18 = 2700
1 G 1400
5 L 900
6 G 300
7 L 900
24 400
99999
44444
4 5
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 t o a c ertain 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
5109341 / Mar 13 13-26

experience of the authors - suggestions for other points to be included here would
be very welcome.
In addition certain other options which may be i nvoked 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. P erhaps 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.8 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 v ery 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 us ed for the simplest forms of matrix update,
e.g., with a single user class and a s quare 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 P RIOR = T, (i.e., updating a trip matrix with no
change to zero elements it may be worth setting the parameter ALLIJ in SATPIJA
5109341 / Mar 13 13-27

to .FALSE. so that PIJA’s are not calculated for cells where T ij = 0; this may
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 l ong 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 n eed 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 t hat 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 t he 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 f ixed 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
5109341 / Mar 13 13-28

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.
SUBSLQ – This, in turn, is a special case of SUBPQ whereby if there is a residual
queue Q on a l ink (A,B) following a P ASSQ 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 s uch 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 l ink 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. A ppropriate factors may be det ermined 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 de stination
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.
5109341 / Mar 13 13-29

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
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 l arge 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 s tatistics 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 al l
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
5109341 / Mar 13 13-30

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.
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 c ounted 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 i ndividual
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 det ected 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 w here a K irchoff violation has been i dentified 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.
5109341 / Mar 13 13-31

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.
13.3.3.5 Common Causes of Kirchoff Violations

From an ex amination 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 t hat a l ink 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 j unction has, say, two links in and t wo 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 K irchoff violation because we have an
entry flow of 500, an exit flow of 1,000 and no o ther 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. S omewhat 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 l inks 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.
5109341 / Mar 13 13-32

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 l inks. It is possible, post 10.9 and using the parameter SUBSLQ
(see 13.3.1), to subtract the residual queues from the counts or not depending on
whether the count is assumed to be t aken at the stop-line itself or mid-link
(upstream of any residual queues).
However, given these ambiguities there is a s trong 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 m atrix output from SATME2 to be r e-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 r un 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.5.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 as signment 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. H owever the following assumptions are made by SATME2: (i) In the
update mode (PRIOR = T) any such elements retain their input value, and (ii) with
5109341 / Mar 13 13-33

PRIOR = F they are set to zero. H ence 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
bottleneck rather than the demand trip matrix. T his 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 i terates between matrix
estimation and as signment. 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 t he 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. E ach
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 m ore 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 t hen, if the
changes seem sensible, add t he 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.
5109341 / Mar 13 13-34

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 al l turn counts in the second, then
setting SET777(1) = T and SET777(2) = F w ill automatically include only link
counts in SATME2 but still leave you the possibility to use the turn counts for
other validation purposes.
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 t he same path flows
which is either repeated or contradictory. For example, if link A-B feeds directly
into B-C with no c ross links then the same path flows use each and V A-B must
equal V B-C . If the counted flows on bot h 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 l ist 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 l eading to an i mproved output matrix. The “shotgun” approach of
throwing in every single available count at the first opportunity should be avoided.
5109341 / Mar 13 13-35

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 i n parallel rather than in series as
discussed above (13.3.9) and that it is useful to have counts spread over the
whole network rather than, say, concentrated in a c ity 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 c ase 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 pr iori
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 t o 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” (e.g., cost, distance, time etc.); and
b) a “bandwidth” for the distribution. 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.
5109341 / Mar 13 13-36

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
ME2 calculations have taken place, lists a n umber 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 ou tput matrices are
complex. E.g., it is not possible to say that adding one ex tra 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 )
5109341 / Mar 13 13-37

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
would be. For example, in an e xtreme case, if we have the same count on t wo
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 ac tively factoring the same cells in an oppos ite
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 s imilar interpretation might be appl ied. Thus
values >> 1 o r negative values might indicate problems of consistency with the
counts.
13.3.13 Errors in SAVEIT Flows

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 s mall 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; see
15.23.3. In certain circumstances this has proved to be ex tremely beneficial
(although the downside is that it may increase the CPU time required by
SATPIJA).
5109341 / Mar 13 13-38

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 M ultiple
User Class (MUC) Assignment procedure, as described in Section 7.3, are similar
in principle to updates within a S ingle 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 s implest – 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,
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
5109341 / Mar 13 13-39

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 o f these parameters needs to be specified; if the MUC assignment is
structured so that each user class corresponds to a s eparate level in the trip
matrix then either KLASS or LEVEL may be us ed (or, if both are specified, belt
and braces, they must be equal).
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 s ingle trip matrix all three parameters LEVEL,
KLASS and IVC are redundant; in effect, all three equal to 1.
5109341 / Mar 13 13-40

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 as signed 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 l evel will
contain multiple user classes, in which case the sum of the factors should be 1.0.
In the former case updating a l evel is fully equivalent to updating a s ingle 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:
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.
5109341 / Mar 13 13-41

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 l evel 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 updat ed 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.
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.
5109341 / Mar 13 13-42

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 ex tra 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 f rom 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.5.2. An example of the Command Lines would be:
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
5109341 / Mar 13 13-43

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 aut omatically within SATME2 by using an opt ion
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 ei ther output
directly as a s quare matrix or proportionately divided between the matrix levels
and output as part of a stacked trip matrix depending on w hether a par ameter
TURBO wais 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:
5109341 / Mar 13 13-44

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 us ed 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 al l 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
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 i s updating only one par ticular 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 appr oximation but, given the normally
relatively small contribution of PASSQ flows to total flows, it is felt to be justified.
5109341 / Mar 13 13-45

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 di fferent 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 m ulti-core computer in order to reduce CPU time. See
Sections 13.6.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 di vided and ( b) which subset IPART a
particular run will process (where 1 < = IPART <= NPART). For example, if a
network has 55 z ones and N PART = 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.6.2). The process can be c ontrolled from a
single batch file SATPIJA using n#N on the command line (see 13.6.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
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.6.2)
the standard filenames would be c ounts_1.UFP, counts_2.UFP … whereas the
aggregate .UFP file would be named counts.UFP.
13.5 SATME2 Technical Specifications
13.5.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
5109341 / Mar 13 13-46

definitions and their PIJA’s

5 Input DAT file. Mandatory
6 The output LPM line printer file Mandatory
7 The output “.ME2” summary data file; see 13.8. 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)
13.5.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.8.
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
5109341 / Mar 13 13-47

13.6 SATPIJA - Technical Specifications
13.6.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.6.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.6.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
5109341 / Mar 13 13-48

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.6.3 The SATPIJA_MC Batch Multiple Processor Procedure

SATPIJA_MC To run SATPIJA_MC call
SATPIJA_MC network trips counts (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
QUIET Runs in the background without any Optional
windows
13.6.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 heade r 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.
The header record contains 5 elements:
♦ A-node.
♦ B-node.
♦ C-node (blank if a link).
♦ The number of pija “pairs” to follow.
5109341 / Mar 13 13-49

♦ 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 da ta records each containing 50 i ntegers and 50 r eals, plus a final
record with 23 of each.
13.7 SATU2 - Selected Link Matrices

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.4).
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).
5109341 / Mar 13 13-50

Figure 13.4 – Producing a T ija matrix
13.7.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.8 “ME2” Output Files

Following SATURN 10.5, SATME2 now automatically outputs an as cii/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;
5109341 / Mar 13 13-51

♦ 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.
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. Fo r
example, the current files do not contain any information on zone constraints so
these may be added at a later date.
5109341 / Mar 13 13-52

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
5109341 / Mar 13 13-53

Control Procedures (DOS Batch Files)
14. Control Procedures (DOS Batch Files)
Mini-Contents Page
14. Control Procedures (DOS Batch Files) 14-0

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-5
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-19
14.7 Command Line Options and Batch Procedures 14-19
14.8 Extended Command Line Files: Using .XCL Files 14-20
14.9 QUIET Command Lines 14-21
14.10 QUICK Command Lines 14-21
14.11 Create Your Own BATCH Files: A Beginners’ Guide 14-22
5109341 / Mar 13 14-0

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 l arge extent the batch mode of running SATURN programs has been
superseded by the introduction of the SATWIN front end w hich 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. T hus, 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 t rip
matrix files which need not be further specified. A lternatively, under “pure”
Windows, one might select SATEASY as an icon or from a SATWIN list and then
select the files interactively. I n 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 e quivalent .bat file with the same
“name” as the .exe file (so that the SATEASY.bat procedure runs the
$SATEASY.exe program) and w hich requires a C ommand 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 t he
program exe file such that file names etc get passed back and forwards between
the two. P reviously under 16-bit “pure” dos this involved, to a g reater 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 di vided into mandatory and opt ional 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:
SATEASY livnet livtrips
5109341 / Mar 13 14-1

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 di vided into specific “keywords” such as KR
above which are fixed and “ parameters” such as choice above (typically
filenames) which the user selects. Ce rtain 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 pr ogram, e.g. SATALL, all the individual input and out put 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 t rips.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 s ufficient. I ndeed this method is highly recommended, in particular
since it makes subsequent command procedures considerably simpler and more
fool-proof.
5109341 / Mar 13 14-2

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 PIX 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:
PIX livnet.ufs
will run P1X on a file livnet.ufs. Alternatively
PIX livnet
will also input livnet.ufs where the extension .ufs is implied by default.
Alternatively either:
PIX livnet UFT
or P1X livnet.uft
both define an i nput 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:
PIX 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 bas ed 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.
5109341 / Mar 13 14-3

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:
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 ou tput, to be entered via the
terminal/keyboard. For example:
SATLOOK I
runs SATLOOK “interactively” in terms of file definitions. T his 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.
5109341 / Mar 13 14-4

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”
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 pr ogram, 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. S imilarly all other files have a us er-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 U FS 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.
5109341 / Mar 13 14-5

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 U PDATE file is defined via the SATURN command line,
5109341 / Mar 13 14-6

UPDATE is automatically set to T within SATNET. In either case file ‘net1.UFS’

must exist.
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. U ltimately, 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 pr eviously 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.
5109341 / Mar 13 14-7

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.
Note that, unlike PASSQ and U PDATE above, if a pr e-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. “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.
Log files have standard filenames based on the program names such as
PIXn.LOG, SATDBn.LOG, etc. where the ”generation number” n i s 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
mode where a pr ogram may be r un apparently on-line but with the viewer only
5109341 / Mar 13 14-8

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 k ey file the standard command line should
(normally) contain the “keyword” KEY followed by a f ilename 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 ex tension .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 i nput 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
5109341 / Mar 13 14-9

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 t he
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 l inear combination of link time and di stance 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
5109341 / Mar 13 14-10

which will extend NET.UFS to include fuel consumption in file NETX.UFS. The
terminal output responses would be s tored in SCRATCH.VDU. (Although you
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 or iginally input in a v ariety 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:
5109341 / Mar 13 14-11

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
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 bi t 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 w hich 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
5109341 / Mar 13 14-12

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 r e-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.
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 k ey 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 v ariation on t he 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 i nput 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.
5109341 / Mar 13 14-13

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 K EY 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 t o 5 of lines which
normally contain numerical input; or
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
5109341 / Mar 13 14-14

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’
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. N ote 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
5109341 / Mar 13 14-15

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
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 PIX, SATDB,
SATLOOK, SATED 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.
5109341 / Mar 13 14-16

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 i nvoked 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 ent ry in a l og 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.
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 e xisting file in the first place then the user would have been pr ompted
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
5109341 / Mar 13 14-17

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 r elevant, the line
containing Y would not be needed and t he “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
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 o f 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
5109341 / Mar 13 14-18

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 t heir associated bat files it is possible to include
namelist parameter definitions as the final entries on t he 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 q uirk of DOS it is not possible to include equal signs on t he
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.
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 PIX 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”
5109341 / Mar 13 14-19

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 C SV 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 t his 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.
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 t ext (ascii) file list.xcl and c oncatenate 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.
5109341 / Mar 13 14-20

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 c ommand 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.
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 s et to .TRUE. using a t oggle provided within
SATWIN, in which case it will be appl ied 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 r un 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),
5109341 / Mar 13 14-21

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 s et to .TRUE. using a t oggle provided within
SATWIN, in which case it will be appl ied 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 ex ample, 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
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
5109341 / Mar 13 14-22

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 s tandard name. Equally
temporary files may be deleted etc.
.Bat files may also include certain error checks and internal logic. Fo r example
one may check whether or not an e ssential input file exists and take the
appropriate action if not, or the “convergence status” of a par ticular operation
monitored in order to terminate at the required level. Dos manuals may be
consulted for further information.
Within Windows, and C ommand Prompt, one p articular 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.
There may of course be other “tricks” available within Windows to accomplish the
same ends.
5109341 / Mar 13 14-23

JOB NUMBER: 5109341 DOCUMENT REF : Section14.doc
2 S14.5.9 Updated DVV 25/05/06
3.1 14.5.9 updated again DVV 09/07/06
3.4 SATURN v10.7 DVV NP IW IW 12/03/07
14.9 QUIET DVV 06/08/07
5109341 / Mar 13 14-24

Special Options and Facilities
15. Special Options and Facilities
Mini-Contents Page
15. Special Options and Facilities 15-0

15.1 Network Aggregation and Simplification within Intermediate Bands 15-2
15.2 Preferences files 15-7
15.3 Network Updates (The Update Option) 15-8
15.4 Updating the Trip Matrix (The Re-start Facility) 15-10
15.5 Pre-Loading Fixed Flows (The “Plod” Option) 15-11
15.6 Comparing Assigned and Observed Flows: GEH Statistics 15-13
15.7 Use of SATURN Outside the U.K. 15-15
15.8 Using SATURN as a Conventional Assignment Model 15-16
15.9 Converting Conventional Speed-Flow Curves into SATURN Curves 15-19
15.10 The use of Crow-Fly Distances (The SHANDY Option) 15-28
15.11 Coding Combined Buffer and Simulation Networks 15-30
15.12 Automatic Network Coding (The AUTOX and AUTOZ Options) 15-31
15.13 Supplementary Data for Simulation Links Using Buffer Network Inputs 15-33
15.14 Extra Link Data (Knobs) 15-34
15.15 Node-Dependent Parameters: GAP, GAPM, NUC and LCY 15-38
15.16 Simulation Link Flows and Centroid Connectors 15-41
15.17 Pcu’s, Cars, Buses and Vehicles 15-42
15.18 Interpolating Routes 15-43
15.19 Select Link Analysis (SLA) 15-44
15.20 The Dutch Option (Long Node Numbers) 15-45
15.21 Referencing Data Arrays Via Dirck Access Codes 15-47
15.22 Choice of Gap Parameters 15-49
15.23 Re-constructing Assignment Routes: The SAVEIT Option and UFC Files 15-50
15.24 Alternative Link Costs and/or Times for Tree Building 15-60
15.25 Stochastic Trees 15-63
15.26 Trees, Forests and Arboreta 15-64
15.27 Skimming Trees and/or Forests 15-65
15.28 Variable Program Dimensions 15-75
15.29 Comment Cards and Blank Records in Data Files 15-76
15.30 The Use of Sub-Files within Data Files: $INCLUDE 15-77
15.31 Setting “Optimum” Stage Green Times 15-79
15.32 Determining Fuel Consumption 15-85
15.33 Determining Emission Statistics 15-86
15.34 Estimating Primary and Secondary Stops 15-87
15.35 Altered Data Formats in .DAT Input Files 15-88
15.36 Turning Flows at Buffer Nodes 15-89
15.37 Repeated Assignments: Modelling Cold Starts, etc. 15-90
5109341 / Mar 13 15-0

15.38 Non-discontinuous Speed-Flow Curves: the Kinky Option 15-90

15.39 Bus-only Lanes 15-91
15.40 Motorway Weaving Segments 15-92
15.41 SATTUBA 15-100
15.42 SATCOBA 15-104
15.43 Bitmaps within SATURN 15-109
15.44 Defining Bus Travel Times 15-114
15.45 Representing Walk / Pedestrian Networks 15-114
15.46 DBDUMP: Dumping Link Data to Text Files 15-115
15.47 CLICKS: Variable Free Flow Speeds by User Class 15-116
15.48 UNIQUE: Combined Queues within the Buffer Network 15-121
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-147
15.55 QUIET & QUICK Options via SATWIN 15-156
15.56 Network Aggregation (SPIDER) 15-157
15.57 Residual (Incorrect) Path Flows and Restricted Frank-Wolfe Algorithms 15-173
15.58 Error Listing Files 15-176
5109341 / Mar 13 15-1

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 t o 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
would lie, geographically, between the central “pure” simulation network and the
outer buffer network and which would be m odelled at a s impler and/or more
5109341 / Mar 13 15-2

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 r educe “noise”. FCF
may be t hought 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 t0, 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 bas ic 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 t o a r educed 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
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
5109341 / Mar 13 15-3

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
5109341 / Mar 13 15-4

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 t he 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 des ignated 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., t0, 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 di splayed as node dat a 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 pr operties includes a l ine 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
5109341 / Mar 13 15-5

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 an d 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 ex tra records “$INCLUDE old_base.buf” and “$INCLUDE
old_base.map” within the 33333 da ta 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 dat a 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.
5109341 / Mar 13 15-6

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 di stinction 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. T he 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 pr eferences 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.
5109341 / Mar 13 15-7

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 PIXO.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 t hought 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 pr ogram cannot locate a pr eferences 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 k ey 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 c hannel 2 to SATNET
(which may most easily be done us ing 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.
5109341 / Mar 13 15-8

Note that both UPDATE and P ASSQ may be u sed 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 i ntroduced. 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. C learly 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 onl y 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
5109341 / Mar 13 15-9

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 us er to carry out a f ull set of SATALL simulation-
assignment loops when the only difference between the current and a f ormer 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 c ontrol 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 nec essary to take a c opy 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
5109341 / Mar 13 15-10

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 m uch different either. H ence 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. I ndeed that particular application,
described in 15.5.1, has been l argely superseded by the Multiple User Class
Assignment option which is more general and more flexible and g enerally
recommended in preference to PLOD (see 7.3). However, as discussed in 15.5.2
and beyond below, a num ber 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.
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
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
5109341 / Mar 13 15-11

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 l orries from a l ink 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 t rip
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 no t 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
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 p re-loading from a .ufs file is not permitted (paragraph 4, 15.5.1),
5109341 / Mar 13 15-12

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 l ink and t he 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.
15.6 Comparing Assigned and Observed Flows: GEH Statistics
15.6.1 General Options

It is possible to obtain a nu mber 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:
5109341 / Mar 13 15-13

The most comprehensive and flexible set of comparisons is available within P1X,
either under Validation (11.7.1) or SATLOOK (11.11.13). I n 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 us ed (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 f lows may be r ead 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 ex ception 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 s tatistic 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.
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 i ndication of various levels of GEH values, both
qualitatively and quantitatively:
5109341 / Mar 13 15-14

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 m easure that a pr ofessional 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 t he 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 t ransport 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 c hi-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 er ror of 126 i s “twice as bad” as 63, not four times as bad. T hese
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
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
5109341 / Mar 13 15-15

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 anot her, 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).
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
5109341 / Mar 13 15-16

are no simulation nodes there is no necessity to use the simulation stage SATSIM
and the assignment obtained from one ex ecution of SATEASY is a c onvergent
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 t he 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. N ode 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 r ecords (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 50
C 4 61 5 25
...
99999
55555
..... Co-ordinate data
99999
99999
(End of file)
15.8.2 Converting Simulation Networks to Buffer (SATBUF)

For various applications it is sometimes useful to convert a net work 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
5109341 / Mar 13 15-17

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 A SCII 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 t he delays which would be
modelled in the buffer network (so that in a b uffer 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”.
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
5109341 / Mar 13 15-18

♦ 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.
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.
5109341 / Mar 13 15-19

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 i s 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, t0, a and n, are fitted from the following constraints:
1) Free flow times must be the same (hence t0 = d/S0);
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:
5109341 / Mar 13 15-20

∫ 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
50 30 1200 2200 4.29

45 25 500 1000 3.96
35 25 350 600 4.40
25 15 250 500 3.81
5109341 / Mar 13 15-21

S0 S1 F C N
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 s imulation 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 c oded 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 buf fer networks at any stage MUST be i ncluded 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.
5109341 / Mar 13 15-22

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:
S0 is the free flow speed
S1 is the “intermediate” break point speed
S2 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 / S2
N.B lim ( R log R ) / ( R − 1) =

1
R →1
and “log” above refers to the “natural log”
5109341 / Mar 13 15-23

Our thanks are due t o 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 S0, S1 and S2 in km/h whilst breakpoint F and capacity flow C are in pcus/h
5109341 / Mar 13 15-24

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,
5109341 / Mar 13 15-25

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 l ink 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 o f 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 as sumed 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 bu ffer links by defining
“default” speed flow curve parameters which apply to all buffer links which have
the same capacity index. T o use this option within a net work 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 p ower
but include the distance and c apacity 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.
5109341 / Mar 13 15-26

Thus all links with the same capacity index will have an identical speed-flow curve
plus capacity. N ote 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 i nput data file using these conventions is illustrated below
where “default” indices 1 t o 14 ar e equivalent to the “typical” DfT parameters
defined above. Thus link 6-7 has a length of 90 meters 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 r ecords and c an 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
5109341 / Mar 13 15-27

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.
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” S1 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 S0, S2 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 dat a records, not to
individual link records. However, there is no reason why it should not be extended
to individual records and, if no p roblems 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 w arning message
(WARNING 35) if they differ by more than 10 meters in absolute terms AND
by more than 5% in relative terms.
5109341 / Mar 13 15-28

♦ If a z ero (or blank) value has been i nput it substitutes the crow-fly distance
calculated from the input XY co-ordinates and prints a w arning 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. T hus 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 t hen 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. T hus 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 es timate 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 t imes 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 i s likely to be the preferred option. However, the
default option prior to 10.7 was effectively T so, for upwards compatibility, the
5109341 / Mar 13 15-29

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 i ncluded
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 c onnected 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 bu ffer 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 I n 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 s imulation
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.
5109341 / Mar 13 15-30

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 i ncluded under
33333.
3) In constructing the joint buffer/simulation network SATNET ignores an i nput
buffer link if either of the nodes has already been de fined 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 t o remove simulation links from the buffer network input.
However some care needs to be ex ercised 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 no t 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 meters 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.
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
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 t o 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).
5109341 / Mar 13 15-31

The AUTOZ option removes the need t o 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 i nternal connections, otherwise there will be duplication,
and AUTOZ should only be i nvoked when ALL external nodes are pure cordon
points, not when they are links between the simulation and bu ffer 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. A n
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 ar e 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 s econds and 100 meters. 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
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
5109341 / Mar 13 15-32

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 nu mber 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 s imulation 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 t hat 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 t he link. H owever the effect can be i mportant on
external links between the simulation and buf fer networks, as otherwise it could
lead to a s ituation 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.
5109341 / Mar 13 15-33

15.14 Extra Link Data (Knobs)
15.14.1 Introduction to Knobs

SATURN allows a v ariable number of additional data items - referred to as
“knobs” - to be i nput 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. Fo r 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 per formed on t he
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 def ined as a l inear 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.
5109341 / Mar 13 15-34

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 us ed 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 w eights
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. A s noted in section 6.11 tolls
are indicated by including either a $ o r & 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 nu merical factor (apart from 1.0) is also included then the knob entry is
factored by that amount. T his 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.
5109341 / Mar 13 15-35

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.1 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 ex ternal file may also be
defined for all components within the SATURN assignment networks, e.g., turns
(by including 3 nodes ) and s imulation centroid connectors as well (defined by
including a ‘ C’ in columns 1, 6 o r 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 appr opriate
column may be r elaxed 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 r elaxed so that an out bound 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.
5109341 / Mar 13 15-36

Sound complicated? Stick to wildcard definitions!
15.14.5.2 Wildcard Inputs

In addition KNOBS data read from an ex ternal 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 pa rticular assignment link that value
defaults to zero. Thus, in the case of a s eparate file, not all links need t o 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 opt ion has been i ncluded 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.
5109341 / Mar 13 15-37

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 us ed 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. H ere a s mall 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 bl ocked 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
5109341 / Mar 13 15-38

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 s udden jump of 5 s econds may be r elatively very important in terms of
convergence between simulation and assignment.)
Thus, for signals with X-turns, we now recommend that NUC should be l arge
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 s econds 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 s econd 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 w hich 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 net work .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.
5109341 / Mar 13 15-39

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 c ounter-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 i t 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 t he same cycle length then life is simple - all junctions should be
simulated using that cycle time and t here is no need f or any changes from the
default LCY. I f however different signals operate on di fferent 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.
5109341 / Mar 13 15-40

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 r eal
effect on the OUT-IN transformation since an OUT profile evaluated with, say, 10
time units would be s uitably 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

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 a simulation link AB. X and Y mark the “imaginary” points along AB
where trips leave and enter Z.
The “flow” on A B 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 c onnected 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. B y 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.
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. T his
5109341 / Mar 13 15-41

possibility arises with bus routes which may originate/terminate at either end of
simulation links (see 6.9.2). It may also arise, less obviously, with either pre-
loaded or PASSQ flows 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 that are connected to zones (or where bus routes begin or end) 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.
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 t he trip matrix
elements must be de fined in terms of the same units. I n 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 s ometimes, e.g., when giving total bus flows on l inks, in
terms of pcu’s. Hopefully the text should make it clear what is being printed.
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.
5109341 / Mar 13 15-42

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 s equence of consecutive nodes. For long routes this can be
laborious and t herefore a simpler method is available if node c o-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 B1,
B2…. 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 i f the first method fails.
This requires that a &PARAM parameter MINDER is set TRUE.
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.
5109341 / Mar 13 15-43

Note, however, that in order to use this facility node c o-ordinates MUST be
defined (although, strictly speaking, only for those nodes which lie on t he
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. T hus 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:
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 pr int 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
5109341 / Mar 13 15-44

(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 t he 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
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 i ntroduced to allow nodes with up t o 8-digit node
numbers to be de fined in buffer networks - so-called because it is common
practice in The Netherlands. The major effect of this option is to change a number
5109341 / Mar 13 15-45

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 di gits (although it is
recommended that a maximum of 4 be u sed so as to keep the formats “neat”).
Equally zone numbers are still effectively limited to a maximum of 5 di gits (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. 11 - 20 The B-node, B
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.
Cols. 11 - 20 The B-node, B
(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.
5109341 / Mar 13 15-46

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 v ery 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
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”
5109341 / Mar 13 15-47

numerical data (i.e., numbers which may include a dec imal 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 D A 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 no t
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 us ed 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 bey ond 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
codes were used up. Thus class- specific flows were stored in arrays 3803, 3813,
3823, etc. for user classes 1, 2, 3, etc. up t o 3893 f or 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
5109341 / Mar 13 15-48

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 s ingle “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 obt ained, 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 G APM can have a very strong
influence on t he capacities and del ays given by the SATURN simulation model
and some care should be ex ercised in their choice. I n 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
Cm of the minor arm is given by the equation:
Equation 15.2
Cm S m (1 − VM S M )
=
GS M
where Sm is the saturation flow of the minor arm, VM and SM are the flow and
saturation flow of the major arm and G is the gap value.
5109341 / Mar 13 15-49

Hence C goes from a maximum Sm equal to its saturation flow at zero opposing
flows down to zero at VM = SM (or, strictly speaking CAPMIN; see 8.2.3)with a
power defined by G.SMi. 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/VM, 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 appr eciated that GAP is essentially a par ameter 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/SM.
We may also note that the standard default value of GAP set by SATURN is 5.0
seconds which is almost certainly on t he high side, causing the SATURN
simulation to under-estimate capacities. T he 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 abl e to analyse in detail the O-D
routes used to obtain those flows.
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).
5109341 / Mar 13 15-50

♦ 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 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 c alculated by a s ingle 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)..
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.
5109341 / Mar 13 15-51

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 s ingle assignment and t he routes/costs used on t hat 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 o f 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 a ggregated SPIDER network may be us ed 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 S PIDER assignment (see 15.56.5.3) may be
used to great effect within a SAVEIT assignment.
In addition, post release 11.2, a S AVEIT assignment may use an I ncremental
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 t o request 4 i ncrements.
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
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 l ink generated by a
5109341 / Mar 13 15-52

select link analysis may not exactly equal those generated by the original
assignment.
However, it also needs to be bor ne in mind, that the “errors” associated with
SAVEIT are just one extra source of “noise” to be added t o the non-convergence
errors from SATALL proper (see 2.1 and 9.5). Essentially the SAVEIT assignment
is an appr oximation to an appr oximation. 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 t he statistics give a q uantitative estimate of that
approximation.
The difference statistics are also held in the output .ufs files and may be examined
using the analysis option 8 w ithin SATLOOK and/or under Analysis etc. in P1X
(11.8.4.7).
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 m ore
space-efficient format. It requires that a l ogical parameter UFC109 is set to
.TRUE. under namelist &PARAM in network .dat files. Thus if UFC109 = T (default
= T) two things happen:
5109341 / Mar 13 15-53

(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 t he 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
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 r educed in
size by a factor of 1/NOMADS with only a very small overhead in reconstructing
5109341 / Mar 13 15-54

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 t he 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 final GAP value (9.9.1.2) achieved by the
main assignment 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 S AVEIT solution, all
subsequent analysis steps that use UFC files (e.g., SATPIJA, SLA, etc.) will
become correspondingly faster.
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 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 the second parameter is not used NITA_S is simply taken from
net.ufs.
5109341 / Mar 13 15-55

In fact SATUFC is not a separate program, it is simply a r un of SATALL with,

effectively, zero assignment-simulation loops and only the SAVEIT step included.
As a c onsequence 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 c omputationally efficient to set SAVEIT = F i n 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 s ent without their .ufc files as the latter can be eas ily 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 t he (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.
♦ 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 pr eserved in an “extended” UFO (OBA)
format.
5109341 / Mar 13 15-56

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 s o
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.
If, say, both .UFO and .UFC files are available for a pa rticular network the user
may have the choice as to which to use (for example carrying out a Select Link
Analysis in P1X, 15.19). In such cases the use of .UFO files is generally strongly
recommended as they are considerably faster than using .UFC.
In addition the UFO format used for OBA (22.5.2) may also be adapt ed 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
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 above – and that an
alternative form of .UFO file may be c reated based on aggr egated “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 and
SATUFO_MC)
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 =
5109341 / Mar 13 15-57

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 ex tra 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_MC: Multiple User Class plus Multi-core option

SATUFO_MC (see 15.53.3.7) is a special “multiple processor distributed” batch
file which creates a full .UFO file for a m ultiple user class network by iteratively
calling SATUFO once per user class:
(a) SATUFO net NOMAD 1
(b) SATUFO net NOMAD 2
(c) ....
Followed by a special call to SATALL:
(d) SATALL net ALLUFO
Which creates a multiple user class file net.UFO by merging the single user class
files net_1.ufo, net_2.ufo etc. etc. as created by the above calls to SATUFO.
Note that SATUFO_MC uses only standard .exe files (specifically $SATALL.EXE)
but the batch file is structured in such a w ay that individual UC calculations are
allocated to particular processors/threads in order to reduce CPU time.
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 r ather
large pinch of salt.
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
5109341 / Mar 13 15-58

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 t hose 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 al located 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 us ed 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 anot her. 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 t he lack of an ac ceptable
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 uni que set of path flows within a
Wardrop Equilibrium solution is to require that the path flows satisfy the
“proportionality condition”; see, for example, various articles by BarGera and
others.
5109341 / Mar 13 15-59

Proportionality requires that, at any node A where there are more than one exit
links that are on m inimum 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 uni que set of path flows is that of
“entropy maximisation” where we choose a set of path flows Tpij which maximise
the entropy measure (see equation (13.2) in section 13.1.1). To a large extent (as
I understand it) proportionality and ent ropy 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 l arge 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 l inear combination of time and di stance (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)
a1 and a2 are the values of time and distance respectively (generally set by
parameters PPM and PPK and possibly disaggregated by user class)
dk, k = 1, ... K are the additional link “KNOB” properties
bk, 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
PPM and P PK will already have been def ined by the user during the SATURN
runs and, if the user wishes to re-create the same or similar trees, the same
5109341 / Mar 13 15-60

values should be selected. These values may also have been user-class specific.
However alternative cost trees may also be i nvestigated; 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.
Therefore these times would be used to re-construct the routes built at each
5109341 / Mar 13 15-61

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. T hese 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 o f 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. I f the model has
converged properly these delays should differ by only a s mall 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 s elected 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 t o 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) 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
contribution of penalties is always included under the definition of “cost”, e.g.,
5109341 / Mar 13 15-62

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 penal ties 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 C LICKY 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 ex ported to some
other evaluation package.
15.25 Stochastic Trees

“Stochastic trees” refers to minimum cost routes between origin and des tination
zones (hence trees) built on t he 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 bui lt 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
2) To generate a series of “typical” stochastic routes in order to assess
qualitatively the effect of different parameter values.
5109341 / Mar 13 15-63

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 c ompiled vis a v is
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 o rigin 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 l ink is the proportion of trips from a
particular origin to a pa rticular 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 bui lt in a num ber 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 bui lt 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. T he “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.
(N.B. An arboretum is essentially a Frank-Wolfe algorithm based construct for
which there is no direct equivalent under OBA.)
5109341 / Mar 13 15-64

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 or igin to all
destinations, the resulting sub-network resembles a t ree 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 es sential step in scheme
evaluation.
Within SATURN skimmed O-D matrices may be obt ained 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 g iven 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 i ndeed other routes may give lower or higher
distances so that the “true” average distance may also be greater or less than a
skimmed tree.
5109341 / Mar 13 15-65

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 s kimmed
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 t ree needs to be bui lt per origin as
opposed to a forest skim where separate trees have to be bui lt 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 i terations 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 s ub-
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
available when SATLOOK is accessed via P1X and therefore SATDB may
be accessed as well; see 11.11.19);
5109341 / Mar 13 15-66

♦ 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 pos sible 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 i n/excluded and t imes/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 r epresents the same quantity
summed over links. Sij and Sa refer to the property being skimmed e.g., distance.
Note that some care needs to be ex ercised in the definition of Va 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.
5109341 / Mar 13 15-67

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 pa rticular 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 i t 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 w ould expect that the minimum cost
matrix would be a s light 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:
Ca = w1 ta + w2 da
Then, if we take forest skimmed matrices of time and distance tij and dij then we
can also obtain the average cost matrix Cij via:
Cij = w1 tij + w2 dij
This method is sometimes necessary if, for example, the user wishes to define
different values of the weights w1 and w2 (se 7.8.6)
5109341 / Mar 13 15-68

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 t rip matrix and a s kimmed
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 r epresents 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 Va 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 Sij has been s kimmed 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) Tij is a demand matrix; (b) Sij 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 Va are obtained from the “true” model run and t he
skimmed matrix is based on a forest obtained using an appr oximate SAVEIT
assignment (15.23.2) then the equality will only be approximate, limited by the
lack of perfect convergence within both the true and t he 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 Sij 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.
5109341 / Mar 13 15-69

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 i n 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 us ed by drivers. However, it might be us eful 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 s omewhere 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
5109341 / Mar 13 15-70

general, reproduce the same routes and the same link flows as generated by
the assignment proper; they are only an appr oximation. 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 hi gh 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 hi gh 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 any where 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 s table 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
5109341 / Mar 13 15-71

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 aut omate 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 t he output matrix is a s tacked 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 pa rticular 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.
5109341 / Mar 13 15-72

♦ 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.
♦ 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 i n 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.)
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.
5109341 / Mar 13 15-73

15.27.7.2 Skimming Using Aggregated (SPIDER) Networks

If SPIDER = T and t he network has been bui lt using an a ggregated 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 t imes 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 u sed 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
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:
5109341 / Mar 13 15-74

♦ 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 bey ond include a ne w set of algorithms to carry out OD
skimming within SATLOOK which should be m ore 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 i nvoked 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 nety.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 N4 – further details are listed
below:
Array / Level Simulation Junctions Assignment Links Zones
B 500 7500 400

C 1000 22500 800
S 1500 32500 1200
H 2000 47500 1600

K 2500 60000 2000
L 3000 73500 2000 (2400)
M1 3500 83500 2000 (2800)

M2 4000 93500 2000 (3200)
M3 4500 103500 2000 (3600)
5109341 / Mar 13 15-75

Array / Level Simulation Junctions Assignment Links Zones
N1 5000 112500 2000 (5750)
N2 9500 120000 2000 (6950)
21000 200000
N3 ‘Standard’ 2000+ (8250)
(No change) (No change)
N3 ‘Inter’
21000 700000 2750+
(pre 11.2)
N3 ‘Large’
21000 700000 5750+
(pre 11.2)
N4 (post 11.2) 23000 200000 4000+
X7 Bespoke
Note: ‘+’ the maximum number of zones is 8,250 and it is available upon request.
(N.B. there is a risk that some of the Multi-Core versions of the existing
applications may not be available in the larger sizes).
Other dimensions, such as the number of simulation links or turns, are equally
restricted but with ratios chosen such that if the above limits are satisfied then so
should the others. Beyond Level ‘K’, the number of zones available is artificially
capped at 2000 i n the standard release version to reduce excessive memory
requirements. These versions with the larger zone dimensions are available for
free to the existing Level holders. For Level ‘N3’, a s et of larger zone versions
was created to accommodate the suite of sub-regional models developed by
Transport for London with various bespoke configurations to accommodate their
increasing size over time. P ost 11.1, the internal array dimensions were
restructured to provide a new N4 to meet all the anticipated requirements but
within a smaller RAM footprint. Therefore, there may be some issues of backward
compatibility for very large networks using SPIDER Network Aggregation.
The values of the above dimensions for a pa rticular 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 ef fectively 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.
5109341 / Mar 13 15-76

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 ot her examples but we haven’t
thought of them yet!
Prior to 10.5 blank lines were not explicitly detected and c ould 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.)
5109341 / Mar 13 15-77

The original file must therefore also contain a ‘99999’ record in the normal way to
indicate the end of a data section.
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
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 c ertain 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.
5109341 / Mar 13 15-78

Sub-files may also be c reated and/or extended interactively using P1X; see
Section 11.9.2.6 and 11.9.2.7.
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. T he 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 s maller influence and any way can be s et 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 pat tern 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. A nd 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. H owever 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 l arge 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.
5109341 / Mar 13 15-79

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 v iewed with extreme caution. S ee also
15.31.4.
On the other hand some reaction of signals to altered flow is clearly necessary.
Perhaps a g ood 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 p referred 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.
5109341 / Mar 13 15-80

The optimisation process may also be carried out at selected nodes only
(11.9.13.2).
Alternatively, a new “batch procedure” SIGOPT has been i ntroduced 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) PO.
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 r esearch 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.
PO is based on the elegant principle put forward by Mike Smith 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.
5109341 / Mar 13 15-81

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
and the next pair identified. While fairly reliable, such an appr oach is not
guaranteed to produce a g lobal optimum; under certain circumstances the
algorithm may “stick” and t he apparently best pair for swapping may not in fact
lead to any improvement. Fo r 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 al ternative to optimising stage green times outside the
assignment/simulation loop as discussed in 15.31.2 it is also possible to do s o
within the loop using SATALL. T hus 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 aut omatically optimised within each simulation by
setting SATOFF = T – or offset optimisation could be done on i ts 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 em phasised that this procedure is largely experimental and w e
have very little experience so far to compare the results from the above procedure
from that using the explicit SATED-SATALL loop. S ince the updates are more
frequent in SATALL - one per loop - one might expect to find “better” signal
settings and l ower travel times using this method - but life is not necessarily
straight forward with network models! H owever 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”.
5109341 / Mar 13 15-82

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
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 i dentical 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. It effectively supersedes both
SATED 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 as cii file which sets various options, filenames
etc. via Namelist and may also contain a l ist of selected nodes for optimisation.
The full list of parameters with their defaults is listed below.
5109341 / Mar 13 15-83

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
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 from this file immediately after &END
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.
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 di rectly obtainable from observation
and, one w ould 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 i ndividual node
might well be a v ery 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.
5109341 / Mar 13 15-84

15.31.8 Convergence Statistics for Signal Optimisation

Whether or not the green splits at signals have actually been opt imised 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
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 a rea 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
5109341 / Mar 13 15-85

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
traffic management in energy conservation”, PTRC Summer Annual Meeting, July
1981).
Clearly these figures are now out-of-date and take no ac count, 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 i ncreasingly 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 l inear 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.
5109341 / Mar 13 15-86

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 or der
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
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 CO2) have been
extracted (with some fairly broad brush assumptions; e.g. that a p rimary 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 I I, 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 net work .dat file. S ee 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 p riority junction with a “ stop sign” at the end; every vehicle
approaching that junction should (must!) come to a complete stand still either at
5109341 / Mar 13 15-87

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 t ime then vehicles further back will move up by accelerating and t hen
decelerating to a stationary position; these are secondary stops.
Clearly this two-way split does not exactly represent all possible vehicle
movements in a queue but it may well be s ufficiently 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 s econdary stops are, like their definitions,
somewhat arbitrary. Thus for minor arms at priority junctions all arriving traffic
must make a pr imary 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. Fo r
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 pl atoon” 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 pr imary 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 i n 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 t o 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 d ecimal 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.
5109341 / Mar 13 15-88

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 appl ied almost anywhere: in
practice it has only been programmed in a v ery 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.
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 t hat 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
5109341 / Mar 13 15-89

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 ent ry flows on eac h arm correspond exactly to
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. I n the case of the critical distance falling in the
middle of a l ink 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. T hus 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 l inear 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 c ircumstances 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
5109341 / Mar 13 15-90

7.11.9). This is simply done by setting a pa rameter 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.
In general KINKY = F s hould 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 ne arside bus lane, if a b us 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 us ed by a r oute 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 near side 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 l ink AB may transfer seamlessly to an offside bus lane on l ink BC and
back again to a nearside lane on CD. Furthermore it is not, for example, possible
5109341 / Mar 13 15-91

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. I n
addition buses in bus lanes form separate queues and t herefore have different
delays from “normal” traffic making the same turning movement. I n 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. t0 in equation (8.5a). Moreover
this delay is fixed, independent of the volume of traffic in the bus lane. T ravel
time/speed along the link itself equals the cruise time for normal traffic and t he
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 ex clusive 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 ob tained 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 m otorways 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
5109341 / Mar 13 15-92

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.
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 ei ther 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
Qnw = Total non-weaving flow in vph
Qw1 = Major weaving flow in vph
Qw2 = Minor weaving flow in vph
D = Maximum mainline flow in vph per lane, refered to as S below.
5109341 / Mar 13 15-93

Lmin = Desirable minimum weaving length

Lact = Actual weaving length available (in metres) (referred to simply as L from
now on)
(where Lact is assumed to be greater than Lmin and, if not, take Lmin = Lact such
that the factor within the bracket multiplying Qw2 = 3.)
In SATURN we need t o “invert” this equation since the actual number of lanes
provided Na 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 Na ( 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 (= 2Lmin/Lact + 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:
5109341 / Mar 13 15-94

Equation 15.8
Qw 2 F ( X f − 1)
Se= S −
Na
and substituting F from Equation 15.5 into Equation 15.7 gives

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 = Qnw + Qw1 + Qw2.

Note that in the “worst possible case” when Xf takes its maximum value of 3.0 and
Qnw = 0, Qw1 = Qw2 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 Lmax
(typically 3 km.) This will introduce a discontinuity into the multiplier of Qw2, Xf, in
that it jumps from a value of (2Lmax/Lmin – 1) > 1 at L = Lmax to 1.0 at L>= Lmax.
Recall that the maximum value of Xf is 3.0 at L <= Lmin.
Two alternatives have been suggested (in addition to retaining the discontinuity):
(i) Reducing Xf by a constant amount throughout such that it goes smoothly to
Xf(Lmax) = 1.0 and is 1.0 beyond.
(ii) Assume that Xf(L) is a linear function between L = Lmin and Lmax going from 3.0
down to 1.0.
More specifically under assumption i) we introduce a correction factor equal to the
“normal” value of Xf at L = Lmax less its desired value of 1.0:
5109341 / Mar 13 15-95

Equation 15.11
Lmin
C = 2.0
Lmax
Hence the full formula for Xf (L)is:

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 Xf (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 Qw2 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 m inimum value on t he 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 pr oposed (by experienced modellers!) and let the
5109341 / Mar 13 15-96

user decide. And if the user has an al ternative 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
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 w eaving section may consist of either a s ingle 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 i ntermediate 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 i f 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 s ingle one-way out-bound link; i.e., in-bound
motorway and i n-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 per mitted 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 ent ry
5109341 / Mar 13 15-97

(motorway) arm must have both its two possible turns defined - the first to the off
ramp, the second continuing along the motorway and t he 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 t urns do not interfere with the required geometry. For
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 i n order to provide
“shape” to the network although, it should be not ed, 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 w hether 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 t wo
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
5109341 / Mar 13 15-98

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.
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 appl ied 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 de fined 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 - Lmin in Equation 15.2
♦ WLMAX - Maximum length for weaving in metres - Lmax 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 m etres 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,
5109341 / Mar 13 15-99

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
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 s een as weaving “over a di stance” whereas W priority
markers represent weaving “at a poi nt” - 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 di splayed 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 Qnw, Xf, 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 pr ocedure 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 s et of matrices giving for each O-D
pair:
♦ passenger or vehicle trips;
♦ distance;
♦ time; and
5109341 / Mar 13 15-100

♦ (monetary) charges.
These matrices may be further disaggregated by, e.g., user class, time period, trip
purpose etc.
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 w ith 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 s imply a c onsequence 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
5109341 / Mar 13 15-101

net_t.txt
net_m.txt
where the first matrix contains distances, the second contains times and the third
contains toll charges (if any exist).
Units are the defaults as specified by TUBA: distance is in kilometres, time is 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 m odified by a num ber of
parameters and/or options contained as Namelist parameters in the SATLOOK
preferences file satlook0.dat (11.17.2). Alternatively, a di fferent 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
5109341 / Mar 13 15-102

♦ CLICKY (Logical): If .TRUE. skimmed times by user class include any

possible extra times due to CLICKS (See 15.24.4); Default T.
♦ 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 us ed 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 v ehicle 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.
5109341 / Mar 13 15-103

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
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 di stances, not to skims of,
e.g., tolls or generalised costs and t hat 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 de fined 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.
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.
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.
5109341 / Mar 13 15-104

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 i ts
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 s tandard 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:
5109341 / Mar 13 15-105

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 di gits since 4 di gits 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.
5109341 / Mar 13 15-106

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 i nput 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 s tored 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!)
5109341 / Mar 13 15-107

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 al l the
links contained in net_base.cln using the same link number conventions. N ote
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 di splayed (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 di rection 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 r educed/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 num bering systems that may be us ed 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 z one
(the first NCENTS entries) or a j unction, whether buffer or simulation. Note that
5109341 / Mar 13 15-108

map sequential numbers may be viewed within the SATDB node data base as
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 bas ed 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 c reated
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 bl ank (i.e., white) screen
background an i mage 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 s elected and suitably
expanded. Thus a very useful property of the bitmap displays is that they “move”
with the network window.
5109341 / Mar 13 15-109

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 r oad map, dumped from a
GIS software package or even output from a di fferent 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 c orners 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:
5109341 / Mar 13 15-110

♦ 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 t he 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 m ost conveniently set up t he 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 di gits 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 de fined
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! Fo r
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,
5109341 / Mar 13 15-111

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 pr ocedure 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 an y 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 bi tmap 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.
5109341 / Mar 13 15-112

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 c hanged 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 kilometers) 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 r emoved 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.
5109341 / Mar 13 15-113

The size and resolution of .bmp files may, I (DVV) am reliably informed, be easily
manipulated using standard Windows graphics packages such as Paint but
exactly how this is done is a bit of a mystery to me! Ask a young person.
15.44 Defining Bus Travel Times

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 (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.
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
5109341 / Mar 13 15-114

“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 t o 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 pedes trian although as far as SATURN is
concerned nothing has really changed - it is simply finding a r oute 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: Dumping Link Data to Text Files

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. 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
♦ 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:
5109341 / Mar 13 15-115

(i) Those that select the links to be output, and

(ii) Those that control the format.
Under link selection the following characters indicate link types to be included:
$SL Include simulation links (i.e. roads)
$SCC Include simulation centroid connectors
$BCC Include buffer centroid connectors
$CC Include all centroid connectors
$SL Include simulation links (i.e.roads)
$SCC Include simulation centroid connectors
$BCC Include buffer centroid connectors
Including an X immediately after $ i ndicates “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.
Further options, still to be programmed, will control output formats, e.g., fixed
column vrs free format (CSV).
And indeed a further option introduced in 10.8 is that, if the filename of the output
file has an extension .CSV, then it is assumed that the output data format will be
CSV rather than fixed columns.
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 m aximum speed of 100 kph on al l 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 v ehicle
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 al ternative model with
variable time penalties.)
5109341 / Mar 13 15-116

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
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 t hat 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 t he other hand, explicit penalties under 44444 c an be m ade 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 c oded 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 s econd penalty on t he 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 def ined. 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 t he differential time penalties must therefore fall
into that category. Otherwise multiple equilibria may occur.
5109341 / Mar 13 15-117

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 add ed to the cruise time etc. totals
which appear in standard output tables; however, for the time being, this has not
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 t he 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 m uch 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
5109341 / Mar 13 15-118

(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 t he
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
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 par ticular combination of vehicle class and
capacity index the user must include a r ecord, similar to default speed-flow
records per capacity index (15.9.5), under 33333 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 dat a fields following V may be i n 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. 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.
5109341 / Mar 13 15-119

Note that fields (ii) and ( iv) must be i ntegers (as well as, clearly, being valid
numbers) but the speed (iii) may be i nput as a real value. Normal logic checks
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 don e 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 def ined independently per link, e.g., as a f lat
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 k ph the new HGV penalty would be
1/100 – 1/110 = 3.27 seconds. If car speeds dropped to less than 100 k ph 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
5109341 / Mar 13 15-120

non-convergence and/or multiple equilibria. However, compared to the

interactions that go on within the normal simulation process, the sort of
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 s hould
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.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.
More precisely, consider a s eries 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 t he first link but not on any of the flow-metered links
downstream.
However, prior to 10.7 and U NIQUE, the same queue build-up and c onsequent
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 t hen be r eadily imported into the associated MS Excel
spreadsheet and comparisons undertaken between different networks.
5109341 / Mar 13 15-121

SATSTAT consists of two parts: (i) a For tran 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)
♦ 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 i mported 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 m ore 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".
5109341 / Mar 13 15-122

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 M S 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.
This will load-up the SATSTAT module requesting the network(s) that you wish to
extract the summary statistics from:
5109341 / Mar 13 15-123

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:\PROGRAM
FILES\ATKINS\SATWIN 10.XX\TEST\DEMO – SATSTAT” but the files may be
located in any folder.
5109341 / Mar 13 15-124

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 s ummary 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 called (in this instance) Summary Report (v3.00).xls as
shown below. 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.
5109341 / Mar 13 15-125

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:
We may then select each CSV file, in turn, and these will be i mported 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.
5109341 / Mar 13 15-126

Once completed, Table 1 ‘Scenario Reports’ shows the summary statistics for two
networks side-by-side, as show below.
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
5109341 / Mar 13 15-127

Summary Statistics (post-simulation for TOTAL flows)

♦ Matrix totals excluding intra-zonals;
♦ 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.
5109341 / Mar 13 15-128

15.49.2.5 Importing Additional Networks

♦ This may be r epeated for any number of networks. I f further reporting columns
are required, an existing column may be copied across as shown below.
Existing
Extended
5109341 / Mar 13 15-129

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 w ill remain unchanged, Table 2 bel ow will now report on t he
Differences and %Differences in the summary statistics (ie this network minus the
one with the column ID just selected) as shown below.
5109341 / Mar 13 15-130

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.49.2.8 Further Development

The core SATSTAT Reporting Tool is now complete and has been used internally
within Atkins Transport Planning for several years. There have been a number of
suggestions for extending its functionality, for example extending the summary
reporting by separate user class as well as total flows, we would welcome any
further comments and suggestions for new features and options.
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 t herefore “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 ex tra pcu (N.B. pcu, not
vehicle) on a par ticular “link” (where a l ink may be ei ther a r oad or a s imulated
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 ca(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 t o 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 t echnical co-operation of GMPTE (Greater
5109341 / Mar 13 15-131

Manchester Public Transport Executive) and G MTU (Greater Manchester

Transportation Unit) whose inputs are gratefully acknowledged.
15.50.2 Marginal Cost vrs Marginal Time

Generalised cost is normally a w eighted 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 ex tra pcu has no i mpact on l ink distance, for example.
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 t hat 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 t o 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 w ith 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)
Vi is the (total) demand flow for that turn
ΔVa is the increment of traffic to the current turn a (either positive or negative)
di (I) is the simulated delay with the increment ΔVa
di (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.
5109341 / Mar 13 15-132

3) This method can give both positive and neg ative 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
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 Vi in equation (15.16) – it is simply a q uestion of re-
defining Vi 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
5109341 / Mar 13 15-133

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:
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 e xtra
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 pc u/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 v ery highly significant changes
between no flow and a v ery 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 pr eferable 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 ex ample of belt’n’braces and t o cope with various “noise” problems
which empirically are observed to occur even with all the above rules, for
5109341 / Mar 13 15-134

priority and s ignalised junctions, whenever both positive and negat ive
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.
15.50.7 Marginal Costs on Links

In addition to calculating marginal costs on s imulation 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 s et up i n 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
5109341 / Mar 13 15-135

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 t o 5-digit simulation node numbers. This may cause
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 di scussion 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 w ell-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
5109341 / Mar 13 15-136

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 updat ed 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 i nvoked to update/warm start the previous
network. See 6.1.
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 w arm
start we recommend that you set SAVEIT = F and a void 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 c ore 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 t o 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
5109341 / Mar 13 15-137

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..
Figure 15.6 – Traditional Sequential Operation
Figure 15.7 – Advantages of Multi-Core Processors
5109341 / Mar 13 15-138

15.52.1 Additional Programs

Parallel runs can be performed with the aid of two programs: MONITOR and WAIT
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 o f 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. I n other words, if the user
wishes to run two instance of $SATALL, the user should request a small pause
between the first and s econd 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 ‘parallel’ run of the SATURN module (which runs SATNET and
SATALL) is found in the subfolder “TEST\DEMO PARALLEL” where SATURN is
installed. This is by default C:\SATWIN\ TEST\DEMO PARALLEL.
The batch file created to perform the parallel run is called PARALLEL.BAT. The
file can be modified accordingly to perform parallel runs with other SATURN
modules including $SATALL, $SATPIJA, $SATLOOK and $SATEASY.
The salient parts of PARALLEL.BAT are as follows:
1) PATH = C:\SATWIN\XEXES: sets the path to the folder containing SATURN
programs. It is not necessary if PARALLEL.BAT is run through the “Batch
Run” menu of SATWIN.
2) SET INPUT1=EPSOM5000: 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 E PSOM5000.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.
3) SET INPUT2=EPSOM5001: 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.
5109341 / Mar 13 15-139

4) START SATURNEXIT %INPUT1% %INPUT1%: starts the first SATURN

run.
5) WAIT 1 - Waits for 1 s econd to avoid simultaneous access to
SAT10KEY.DAT
6) START SATURNEXIT % INPUT2% % INPUT2% - starts the second
SATURN run
7) START /W MONITOR $SATALL 10 - starts monitoring $SATALL every 10
seconds and MONITOR terminates if $SATALL is not found in the latest
snapshot of running processes.
15.52.3 Further Comments

PARALLEL.BAT can be modified accordingly to perform parallel runs with other
SATURN programs including:
♦ For SATLOOK – replace SATURNEXIT in 6 (above) with SATLOOKEXIT and
$SATALL in 7 to $SATLOOK;
♦ For SATALL – replace SATURNEXIT in 6 (above) with SATALLEXIT;
♦ For SATEASY – replace SATURNEXIT in 6 (above) with SATEASYEXIT and
$SATALL in 7 with $SATEASY; or
♦ For SATPIJA – replace SATURNEXIT in 6 ( above) with SATPIJAEXIT and
$SATALL in 7 with $SATPIJA.
In all of the above, set the input parameters according to the requirements of the
SATURN program.
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 and extra EXEs (both identified with the ‘_MC’ suffix).
5109341 / Mar 13 15-140

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
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 under taken to expand the number of programs
available with multi-threaded capability.
The current status (as of December 2012, release 11.2.01 Beta) of SATURN
Multi-Core Applications is detailed below.
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
5109341 / Mar 13 15-141

Program Status How to Access? Version Comment
New Multi-distributed as per

Final SATUFO_MC.BAT SATUFO; See 15.53.3.7
SATUFO_MC v10.9.24
Release and Post v11.2 - replaced by
$SATUFO_MC.EXE SATUFO – see abov)
(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 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. However, some of the preparation
tasks may be pa rallelised and these are currently under development and
expected to form part of Version 11.1.
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 nec essary to set a
control parameter SPARSE = F t o select a m ore 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 di fferent 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 but terfly flapping its wings, the two may give detectable, even
significant, differences although each will be per fectly 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
5109341 / Mar 13 15-142

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 s ingle or multiple cores with each core capable of running
independently to provide additional computing power. M ost 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 t hreads 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
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 s ubstitute for having additional physical
cores instead
There are various different propriety names for this technology - Intel’s Hyper
Threading (HT) technology, available on m ost of their medium and hi gh-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) so that tasks
may be unde rtaken simultaneously. T he Windows Operating System takes the
threads generated by the SATURN application(s) and schedules them to run on
the cores 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
5109341 / Mar 13 15-143

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 H yper-threading option was available on t hese 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.
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. S imilar 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). Fur ther information may be found in Appendix S. Note that the
Network Aggregation part of Multi-Core remains in Beta form.
5109341 / Mar 13 15-144

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). P erformance benefits continued to improve with
five cores but there was some erosion of the gains beyond six cores.
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, that there are no c hanges to either the basic program,
$SATPIJA.EXE, or to its associated batch file, SATPIJA.BAT (13.6.2). However,
5109341 / Mar 13 15-145

to assist in controlling the distributed process, a copy of the existing standard

executable has been created called $SATPIJA_MC.EXE.
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 t he sequential zone numbers and t he
distribution of trips in the matrix is unlikely to be e qually 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.
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 t o 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. T he
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 us ed (and controlled) to
undertake parallel operations. The same procedures may be used with SATURN
Multi-Core without any change to those procedures.
5109341 / Mar 13 15-146

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 created cordoned matrices by user class within separate
processors and t hen finally creating a full stacked trip matrix by stacking the
individual sub-matrices using MX. See 12.1.6.
15.53.3.8 SATUFO_MC: Creating .UFO files in Parallel with Multi-Core

A distributed procedure SATUFO_MC may be used to create a network .UFO file
from a .UFC file (see 15.23.7) by repeated calls to SATUFO to create sub-UFO
files per user class followed by a procedure ALLUFO which runs SATALL in a
particular mode to merge the individual .UFO sub-files into a normal .UFO file.
Note: superseded by new SATUFO option – see 15.53.3.3 above.
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
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 and
dependent on the number of threads available. Accordingly, to prevent excessive
memory requirements, there is an i nternal MCNUM limit of 8 ( eight) and all
MCNUM values greater than 8 will be internally re-set to this upper limit.
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 V ariable 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
5109341 / Mar 13 15-147

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 s et for the initial loops when supply-demand convergence is poor and
the trip matrices are still highly uncertain but these would be s ubsequently
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 c opy 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).
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. C learly,
significant CPU savings may be ac hieved 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%
5109341 / Mar 13 15-148

However, SATURN may also be embedded within a l arger 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 dem and (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 WebTAG Unit 3.10.4
and defined by:
GAP − SD =
∑ ijctm ( )
C ( X ijctm ) D C ( X ijctm ) − X ijctm
*100
∑ ijctm
C ( X ijctm ) X ijctm
where:
♦ Xijctm is the current flow vector or matrix from the model
♦ C(Xijctm) is the generalised cost vector or matrix obtained by assigning that

matrix
♦ D(C(Xijctm)) is the flow vector or matrix output by the demand model, using
the costs C(Xijctm) 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 hi ghly 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 pr inciple 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
5109341 / Mar 13 15-149

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. T hese two convergence
profiles are also shown below in Figure 15.12.
Figure 15.12 – Typical Demand Model Convergence Profile
70%
60%
Demand Model (%GAP)
%GAP (Supply/Demand
50%
SATURN-CASSINI Convergence
(%GAP=Variable)
40%
Standard SATURN Convergence

30%
(%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.
5109341 / Mar 13 15-150

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
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
5109341 / Mar 13 15-151

to improving convergence in the trip matrices. As shown earlier in Figure 15.12,

the convergence parameters adopted for the early loops should be r elaxed 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 &PARAM,
15.54.6.1 File Inputs

CASSINI requires three input files, namely:
♦ 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 num ber 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. T here are currently two options
either:
‘DIADEM’ file format and CASSINI will extract the convergence of the
demand model from a s tandard 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
5109341 / Mar 13 15-152

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 s eries 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 s ub-set of those normally contained in the &PARAM &END section of the
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 e xtended 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 t o 10) or late stage (loops 11 on wards) and
approaching completion as illustrated below:
5109341 / Mar 13 15-153

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 t ransferred to the .XCP file depending on t he 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.
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.
5109341 / Mar 13 15-154

Example of the Control File
Example of the ‘DIADEM’ Demand Model File
DIADEM Results File
5109341 / Mar 13 15-155

Example of the ‘OTHER’ Demand Model File
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 SATWIN by setting the QUIET and QUICK drop down boxes
(on the SATWIN toolbar) to ON as shown below.
5109341 / Mar 13 15-156

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 ov erwritten if QUICK and/or
QUIET is subsequently explicitly set on the command line.
15.56 Network Aggregation (SPIDER)

Network aggregation is a technique whereby links and/or nodes in the basic
assignment network may be c ombined 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:
Tcpu = a1 + (a2 Nnodes + a3 Nlinks ) (1 + a4 Sqrt(Nnodes) )
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
5109341 / Mar 13 15-157

times; network aggregation achieves this by reducing the number of nodes and/or
links.
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 appl ied 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 r eplaces all the intermediate links and all the intermediate
nodes are removed. (This form of configuration occurs not infrequently in
SATURN networks when a num ber 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”:
5109341 / Mar 13 15-158

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 i f 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 t hat 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 s ingle entry and m ultiple exits may be ag gregated 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.
5109341 / Mar 13 15-159

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 l ink 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:
5109341 / Mar 13 15-160

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 i s connected via
aggregate centroid connectors to nodes A and B but it does increase by 2 t he
number of assignment links replaced.
5109341 / Mar 13 15-161

We may further note (see also 16.6.4) that the above buffer node connector
allows possible U-turns via S1-S3-S2 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 A1 to A2 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 i ntroduced 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:
5109341 / Mar 13 15-162

1) Aggregate certain “priority” nodes, i.e., buffer nodes where there are
banned/penalised turns and w eaving 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 eac h 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 f urther
aggregation is feasible or the maximum number of arms per node which may be
aggregated reaches MAXSPA as set in &PARAM..
A further rule is applied in step 7) which is that a node i s only aggregated if, in
addition to having less than a certain number of arms, it also satisfies the (highly
empirical) rule that:
Nnew =< 23 + Nin + Nout + N2w / 2
Where: Nin = the number of in-bound directional links
Nout = out-bound links
N2w = number of two-way arms
Nnew = number of new direct links that will be created = Nin * Nout - N2w
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!
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
5109341 / Mar 13 15-163

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 bas ed on t he 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 loaded 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 calculation
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 not ed 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 t he
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 r elatively small and i t 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
5109341 / Mar 13 15-164

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 c andidate 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 t he 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.
5109341 / Mar 13 15-165

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 t hese can be el iminated 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.
5109341 / Mar 13 15-166

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 t able of results from a r andomly 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 s ingle Frank-Wolfe assignment

(i.e. no SATSIM)
5109341 / Mar 13 15-167

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,449 5 119,534 185,576 21,438 151,776 13,513 963,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:
5109341 / Mar 13 15-168

♦ 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 c osts 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 m ulti-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. I n 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.
5109341 / Mar 13 15-169

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). T he overall performance gain is principally determined by the
proportion of CPU expended on pat h building/loading relative to that spent in
junction simulation and t he re-estimation of paths for the final assignment. T he
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.
5109341 / Mar 13 15-170

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 s kimmed) 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 aggr egate 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 m ixture 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 s elect link analysis of link K-L one c ould analyse a pat h 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.
5109341 / Mar 13 15-171

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 t o 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 i ndividual Frank-Wolfe iterations
5109341 / Mar 13 15-172

but it would be nec essary, near the end o f 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 eac h 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 t he 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 w hich 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 s ignalised 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 t hat 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
5109341 / Mar 13 15-173

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 r eal-life network), an O -D pair separated by a s ingle 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 t hat path would be selected on t he 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 m ethod (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!
5109341 / Mar 13 15-174

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 deal t 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 cpij and its
minimum cost cij* and
(ii) The relative difference RD = (cpij - cij*) / cij*
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.
5109341 / Mar 13 15-175

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 v ery 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 t o 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 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
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);
5109341 / Mar 13 15-176

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 p revious run of SATNET may be
defined via a N amelist 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 m atch 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 t hen 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
5109341 / Mar 13 15-177

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 onl y 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 l ight colour and pr ogressively 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 ov er-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.
5109341 / Mar 13 15-178

2 15.31.4 NIPS DVV 12/05/06
3.1 Update 15.24/6/32/33/41 DVV 11/08/06
3.50 SATMECC added 08/07/07
15.51 Diadem DVV 07/08/07
5109341 / Mar 13 15-179

Simulation Network Coding Example
16. Simulation Network Coding Example
Mini-Contents Page
16. Simulation Network Coding Example 16-0

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-7
16.6 Simulation Centroid Connectors 16-9
16.7 Motorway Links 16-13
5109341 / Mar 13 16-0

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 s ignalised 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
29 - 30 85 Cycle time at this junction
5109341 / Mar 13 16-1

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 meters 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
55 2 lane 2.
5109341 / Mar 13 16-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 s econds 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 s econds.
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 i nter-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 c ommon movements between stages 4 and 1 t he 5 s econd inter-green
period after stage 4 is red for all movements.
16.2 Roundabouts
Considering the same junction sketch and as suming that node 44 r epresents a
roundabout without U-turns we would code it as follows:
5109341 / Mar 13 16-3

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
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 t he
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 eq ual to the link exit
capacity or zero if they are banned t urns. T his 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 a rm even if the flow across the arm were at the nominal
capacity of its entry arm. Fo r example if there were an as signed 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 c oded as junction type 5, roundabout with U-turns, no
extra data would have been required on the link data records - the program
would automatically generate U-turns to and from nodes 55 and 16 s ince
these are 2-way roads.
5109341 / Mar 13 16-4

7) The coding above would almost certainly generate a S erious 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
not an i mpossible “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 c onstructed with much more similar
engineering design.
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
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
5109341 / Mar 13 16-5

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 meters
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
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.
5109341 / Mar 13 16-6

16.4 External Nodes

Figure 16.3 - A Schematic External Junction
Assuming that node 58 above represents an ex ternal node c onnected 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 meters 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.
16.5 Dummy Nodes

Figure 16.4 - A Schematic Dummy Junction
5109341 / Mar 13 16-7

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 meters.
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.
5109341 / Mar 13 16-8

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 i s connected to link (3,5). I n 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. T he 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 abl e 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 er ror would result
since in that case there would be no such one-way link as (3,5).
5109341 / Mar 13 16-9

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 c oded 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 t o denote both a z one 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 w ould 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)
5109341 / Mar 13 16-10

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 w hich, 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 i s 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).
Editoral correction: introduce nodes A1 and A2 at the left and Z on the right, plus
change the directional arrow on t he lower link. 16.7(b) would exclude C 3 and
have direct links between Z and C1/C2.
Figure 16.7A - Expanded assignment network representation of a combined
external simulation and buffer node coded under 33333
Figure 16.8B - 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 i nputs would appear to be e xactly 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.
5109341 / Mar 13 16-11

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
contrast when the connector is defined within 22222, Fig. 16.7(b), node C 3 does
not exist and direct links C 1 -Z and Z-C 2 do not permit a U-turn at Z.
Since, generally speaking, U-turns are undesirable the 22222 r epresentation 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 i n the simulation network will ‘re-appear’ on t he buffer link (see
section 8 for more details on do wnstream 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 i t is easier using the 33333 r ecords 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 er ror (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 appear s 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
5109341 / Mar 13 16-12

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
flows at the car park which one w ishes 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 en try, 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 i n 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 t he 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 s elected to allow for
the expected assigned flow, not set at the maximum or free-flow speeds.
5109341 / Mar 13 16-13

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
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 s lip road (joint entry and exit)
may be modelled using a W turn priority marker; see 6.4.2.5.
5109341 / Mar 13 16-14

3.4 SATURN v10.7 DVV NP IW IW 12/03/07
5109341 / Mar 13 16-15

Multiple Time Period Modelling in SATURN
17. Multiple Time Period Modelling in SATURN
Mini-Contents Page
17. Multiple Time Period Modelling in SATURN 17-0

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
17.6 The Definition and Calculation of Queues and Delays 17-11
17.7 Junction-based Summary Statistics 17-14
17.8 Network-based Simulation Summary Statistic 17-16
17.9 Combined Simulation and Buffer Total Statistics 17-18
17.10 Delay-based Arrays in .ufs Files: Definitions 17-20
17.11 Formulae for Calculating Totals 17-21
5109341 / Dec 12 17-0

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 w hich needs to be m ore 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 hou rs to clear. The
average delay at A would be s omewhat in excess of 30 m inutes (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. H owever 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.)
Conventional / buffer network assignment models are therefore faced with two
problems:
5109341 / Dec 12 17-1

♦ 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 av erage departure
rate of 1,000 pcu/h at A; all others have an ar rival and depar ture 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 c orresponds 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 pc u/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 t he 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 ac tual 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 t hought of as a form of
“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)
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.
5109341 / Dec 12 17-2

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 s imulated and t herefore the delays are
calculated corresponding to 90% of the assigned or demand flows.
Actual and Demand Flows by User Class
We note that the same distinction between actual and dem and 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 t wo 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 hou rs into a di screte number of sub-periods (say 4 o f 30
minutes), each with its own “rectangular” demand profile. Each sub-period is the
modelled individually as described below.
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.
5109341 / Dec 12 17-3

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 m ost conveniently done us ing the extended SATURN
procedure described in Section 14.4.1 with a command such as:
SATURN network2 tripod2 PASSQ network1.
2) or by
3) 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 o f the first time period and t he
“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 “entry flow” for the purposes of the
assignment
♦ 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
5109341 / Dec 12 17-4

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 c onsiderably 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 t heir

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
2) Equally the trip matrices may differ as well, although how this is done is
left to the user.
4) 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
5109341 / Dec 12 17-5

multiplying a “ master” trip matrix by a uni form 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 o f 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 hour s 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 t he 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 s ide of the
network to the other then 30 m inute time slices should be f ine. 15 m inutes is
probably still OK but 5 minutes would be cutting it a bit fine. On the other hand if
the network were only 5 m inutes “wide” then 2 minute time slices might be
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.
5109341 / Dec 12 17-6

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 t o be c onsulted if you
need to take a more do-it-yourself approach.
In fact .PS files and t he 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 r esurrected 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 s omewhat simplified by
making use of special input control files to SATNET known as “.PS” files.
Basically the .PS file is read after a f ull network .dat file and, using a nam elist
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
&EN
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.
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.
5109341 / Dec 12 17-7

17.4.2 The SATTP Procedure

A special .bat produced under DOS, SATTP.BAT, provides a s imple 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 s eparate ‘.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 r unning 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
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
*
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.
5109341 / Dec 12 17-8

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 de fined 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 i n 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 s et 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.
5109341 / Dec 12 17-9

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 m ay 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 i nput 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 f or 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 t o time period 2 t end 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.
5109341 / Dec 12 17-10

♦ Take data from the final time period, as in queue at the end of the time period.
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
5109341 / Dec 12 17-11

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 t he preceding link(s) and, possibly, on i nbound centroid
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 t his link in time period 1 m ay
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. A nd 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. T hus a por tion of the over capacity queue (5) and t he 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 appr opriate flow -
generally the capacity for over-capacity movements or the arrival/departure flow
otherwise.
However in defining delays we may need t o 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. T hus 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:
**
For ease of illustration we have shown the transient queues in time periods 1 and 2 to be
equal; they need not be.
5109341 / Dec 12 17-12

Delays to newly arriving traffic (as opposed to traffic in queues at the end of the
previous time period).
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 c omplete their journey in time period n+1. P art 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 l ess.
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 ne w 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 s et 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.
5109341 / Dec 12 17-13

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
“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 o f 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 per manent 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 pa rticular turn or link. For example a ‘*’
following the delay indicates that the cycle times are different at the upstream
node and t hat therefore any signal co-ordination will have been l ost (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 i n-bound
centroid-connectors.
5109341 / Dec 12 17-14

Table 17.1 – Node 22 – Delays and Flows for Each Turn

Ave.
Fixed Assgnd QUEP Arrive Qued Actual
From To Delay Capacity V/C % 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)
5109341 / Dec 12 17-15

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 t o
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
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 l ike 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.
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. S ee
5.1.9.
5109341 / Mar 12 17-16

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
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 s pent travelling on l inks,

subdivided into free-flow speeds and t he 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.
5109341 / Mar 12 17-17

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 bu ffer 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
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.
5109341 / Mar 12 17-18

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). B uffer distance is flow times distance. A gain 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 net work 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
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. T hey 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
5109341 / Mar 12 17-19

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. T hose denoted * are
defined only for simulation links and those with a † a re 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.)
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. T he 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 al l 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
5109341 / Mar 12 17-20

therefore represents the minimum possible values for total turn delays
in, say, 1633 or 4003 and it is definitely considered as a del ay. 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 g ives 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

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
5109341 / Mar 12 17-21

TIME PERIOD: THIS NEXT TOTAL

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 A FTERS 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 eq uivalent 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 appl ied; e.g. that there is a pe rmanent queue
greater than zero on that link or turn, as with CQL.2. The select rules are given on
the far right.
In addition certain sums, e.g. CQL.2, are best calculated via certain “intermediate”
variables. T hus Q represents the number of queued pcus at the end of a t ime
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
5109341 / Mar 12 17-22


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
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
5109341 / Mar 12 17-23


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 i s 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 w ith 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:
=
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
5109341 / Mar 12 17-24

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 t he 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.
5109341 / Mar 12 17-25

3.4.1 v10.7.10 Release DVV NP IW IW 24/04/07
10.9.17 Web release – Jun 10 DVV DG IW IW 22/06/10
5109341 / Mar 12 17-26

Network Structure and Editing: PMAKE
18. Structure and Editing: PMAKE
Mini-Contents Page
18. Network Structure and Editing: PMAKE 18-0

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
5109341 / Mar 13 18-0

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 as cii or text file, i.e. one t hat may be v iewed 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 bu ffer networks into a s ingle 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 out put 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 r oad 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 c ontain a s eries 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 s eries 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.
5109341 / Mar 13 18-1

Figure 18.1 - Basic Data Structures
There is thus, as shown in Figure 18.1, a di rect relationship between the

information held in the network .dat file and t he display of that network on t he
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.
5109341 / Mar 13 18-2

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 u sed instead. F air 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 ac complished 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 ex isting network. Thus each of the 8
standard data segments 11111, 22222 et c. may be edi ted 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 l arge 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
5109341 / Mar 13 18-3

one is editing an e xisting 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 out put .dat file is simply a s traight
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 w ishes 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 w hose 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.
5109341 / Mar 13 18-4

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 us ed 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 t he 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 m ay therefore be s ubsequently 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 us ed 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.
5109341 / Mar 13 18-5

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 s aved 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 ne twork .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 i nput to P1X and
then choosing Network Editing from the top P1X menu as per 18.2 and 11.9.
Further topological changes may be m ade by entering PMAKE from the Edit
Menu.
PMAKE also maintains internally a pur ely 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.
5109341 / Mar 13 18-6

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). E qually 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 poi nt on the screen
into X, Y co-ordinates in, say, metres on t he ground. I nitially 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 X YUNIT = 1.0 (the defaults) then the equivalent horizontal
width of the window plotted would be 1000 m etres. 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 t he 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 de fined. 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.
5109341 / Mar 13 18-7

The namelist parameters to be eventually included in the output .dat file under
&OPTION and & PARAM may also be s et 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. T hus if mistakes do oc cur - 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 t o
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 pr oduced once topological changes have been m ade 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)
5109341 / Mar 13 18-8

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 poi nt on the map. B y
default the new node will be a buf fer 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. E qually an ent ry for C is added as well within the 11111
records.
18.5.3 Deleting Nodes

Deleting a node m eans firstly that any entry under the 55555 dat a 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 t he 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 r etained within the buffer
network 33333 records.
Finally any centroid connectors to deleted simulation nodes are themselves
deleted and removed from the 22222 records.
5109341 / Mar 13 18-9

18.5.4 Renumbering Nodes

Renumbering is restricted to buffer nodes and z ones 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 t hen - 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 aut omatically 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 s et 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). A lternatively the
5109341 / Mar 13 18-10

“error listing” options process the current node coding and pr ints 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 s light 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. T hus 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). T hese 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 ei ther by clicking on both an A-node and a B -node or if
the “chain” option is on by clicking on a s uccession 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 obt ained 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 ei ther created (for plotting purposes) as a s traight line or
(post 10.5) as a s eries 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 c apacity or speed while others are more “sensible”, for
example measuring the link distance from the node co-ordinates as mentioned
above.
5109341 / Mar 13 18-11

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 c apacity 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 c onnectors (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 r emoved
from the map network (so it will not appear on the screen) and (if exists there)
from the buffer network. I f 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 nec essary. 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 i n the centre of an existing link and thereby
creates two extra links in total. M ore details are given under Adding Nodes,
18.5.1.
5109341 / Mar 13 18-12

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 e xisting centroid connector to a l ink 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.
5109341 / Mar 13 18-13

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 w hich 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. A ssignment 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 pe rmitted sequence of nodes in the tree building
algorithms.
(B) The assignment network representation of a combined external
simulation and buffer node
5109341 / Mar 13 18-14

The problem is inherent in the SATURN network data structure and t he 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 p arameter 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. I t 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:
5109341 / Mar 13 18-15

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.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
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 a t
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
5109341 / Mar 13 18-16

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.
5109341 / Mar 13 18-17

5109341 / Mar 13 18-18

Running SATURN Programs Interactively
19. Running SATURN Programs Interactively
Mini-Contents Page
19. Running SATURN Programs Interactively 19-0

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-7
19.12 Mouse-based Inputs 19-8
5109341 / Mar 13 19-0

INTRODUCTION
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 s tarted 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 t ext. U nder 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 u ser input is
either from the keyboard and/or the mouse. C learly 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 gr aphics window and a t ext 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”. I n principle the program knows which of the two should currently be i n
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 di vided into the following very general
categories:
♦ choices from a menu;
♦ direct- generally numerical - responses to a direct question; e.g., y ou 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:
♦ “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);
5109341 / Mar 13 19-1

♦ “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 par ticular “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 par ticular parameter, e.g. origin zone = 67. Thus
numerical variables can take on a w ide range of values as with a par ameter
associated with zone numbers. By contrast a logical variable can only have two
values, effectively true or false, on or off etc. Fi nally 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 nu merical variable is selected you will next either be prompted for the new
value or, possibly, choose from a l ist 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 num ber 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 m enu to define
banned turns, then one to define lanes etc, etc in a c ontinuing sequence. We
refer to this as going to the “next” menu. However, invisible to the user, each next
menu is actually generated by a r eturn from the current menu to its upper level
menu which then automatically calls the next menu in the sequence.
5109341 / Mar 13 19-2

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. I n
most situations “quit” has the same effect as “return” or “back”. H owever 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
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).
5109341 / Mar 13 19-3

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 num ber (but without <enter>, see 19.6 below). For letters either
upper or lower case is acceptable.
Clicking anywhere but on a hi ghlighted line is ignored. S imilarly 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 c hoice 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
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.
5109341 / Mar 13 19-4

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 i s almost always an ac ceptable 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
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”. I n certain
cases Q has no effect, probably due to the fact that you have got so far into an
5109341 / Mar 13 19-5

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 g enerally 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 num erical variable is selected from a m enu (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.
Equally for a scrollable variable no further input is required; it simply moves to the
next permitted value and the text changes as appropriate.
5109341 / Mar 13 19-6

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 s creen-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 i n
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. I n most cases it should be p ossible to
“grab” text from the windows using standard cut and paste techniques.
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
5109341 / Mar 13 19-7

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 s hifted to the top of the help file no m atter 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
means that all lines must be the same length. Standard edit programs may well
truncate short added l ines 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 c lick” to a node . I nput is relatively
simple; only the left hand button is used and functions are designed to be s elf-
explanatory.
“Point and c lick” operations, e.g. to select a node from a net work 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 onl y 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”.
5109341 / Mar 13 19-8

5109341 / Mar 13 19-9

Modelling Road User Charges in SATURN
20. Modelling Road User Charges in SATURN
Mini-Contents Page
20. Modelling Road User Charges in SATURN 20-0

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
5109341 / Mar 13 20-0

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 num ber 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 l ong-stay, etc. etc. In
addition the “perceived” cost of a toll may depend c ritically on w ho 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 e xtra 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.
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
5109341 / Mar 13 20-1

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 appl ied 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 buf fer records or one as an e xternal 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 us ed to define tolls; how this is done i s
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 r ecords the toll is
entered within the appropriate user class columns of a pa rticular link record as,
say, “ £50” or “ $50” to indicate (somewhat perversely - see below) a toll of 50
5109341 / Mar 13 20-2

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 t hen 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 s ingle
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 s eparate 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.
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
5109341 / Mar 13 20-3

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.
5109341 / Mar 13 20-4

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 def ined 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 s imulation
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.)
5109341 / Mar 13 20-5

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 t oll 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 s ummary 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 da ta 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 t o be i ncluded 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.
5109341 / Mar 13 20-6

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 c ar park (whether zone or node) goes through a l ink (not a centroid
connector) whose exit leads to a c ar park and t hat an appr opriate “toll” (equals
parking charge) is levied on that link.
Note that the entry links to car parks may be as signed 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 bes t 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 b y 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 l arge 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 appr oach 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 s ub-option
within SUZIE = T.
There are two key features of TRIBUT which distinguish it from normal SUE:
5109341 / Mar 13 20-7

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 s ingle 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 us ed 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 pos itively 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.
5109341 / Mar 13 20-8

5109341 / Mar 13 20-9

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
Mini-Contents Page
21. Alternative Network Data Structures and Assignment Methods: Origin Based
(OBA) and Path Based Assignment 21-0
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 Path Files: UFO and UFQ 21-5
21.5 Practical Restrictions within SATURN 21-5
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
5109341 / Mar 13 21-0


INTRODUCTION
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 c ertain 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 o btained 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).
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.
5109341 / Mar 13 21-1


Parameters which specifically control the choice and appl ication 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 c ollaboration 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 pr ogramming 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 i n Section 22.5.2 (splitting
factors).
Parameters which specifically control the choice and appl ication 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 l ost within the “noise” of two approximate solutions. OBA assignment is
capable of accurately assessing even very minor schemes such as the redesign
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.
5109341 / Mar 13 21-2


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 i ndividual assignment but without, however, achieving the same
ultimate convergence as OBA. N evertheless 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 i nitial all-or-nothing
assignment based on free-flow costs. ( The UPDATE and R ESTART options
within SATURN (see 15.3 and 15.4) may be t hought 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 al l-or-nothing solution very often leads to a
considerable decrease in the cpu time required to generate a w ell-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
5109341 / Mar 13 21-3


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 l inks; 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 per turbation 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 as signment 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 dan ger 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 l ink-based assignment may be
easily “perturbed” and t hat 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.
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 ar e valid, a
new path corresponding to the minimum cost is created and assigned 100% of the
O-D flow.
5109341 / Mar 13 21-4


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 num erical 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 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 O BA 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 bas ed on an appr oximation
(15.23.2). Thus time and di stance o-d skimmed matrices as used for evaluation
purposes are exact, not approximate, so that the effect of any “noise” in the
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
5109341 / Mar 13 21-5


only work for a s ingle 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 Fr ank-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:
♦ 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.
5109341 / Mar 13 21-6


♦ 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 i t 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
N.B. IPERT and I SP 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)
5109341 / Mar 13 21-7


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 env ironmental 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 r ecycled when it is no l onger 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. I f 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 s ingle pcu per hour was added to one par ticular 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”.

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%).
5109341 / Mar 13 21-8


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
Iterations 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).
5109341 / Mar 13 21-9


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 or der 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 f urther “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 no t 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.
5109341 / Mar 13 21-10


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
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.
5109341 / Mar 13 21-11


5109341 / Mar 13 21-12

Kick Starts: Updating, Warm Starts and Continuation Techniques
22. Kick Starts: Updating, Warm Starts and

Continuation Techniques
Mini-Contents Page
22. Kick Starts: Updating, Warm Starts and Continuation Techniques 22-0
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
5109341 / Mar 13 22-0

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 as signment
problem as a c ombination 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);
♦ RESTART within SATALL (15.4);
♦ Continuation within SATALL (9.12.1);
5109341 / Mar 13 22-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 r arely 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 t he 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 us ed 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.
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,
5109341 / Mar 13 22-2

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 t o 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 p revious 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 c hanges 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 f orwards between very high and v ery 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 ex tremely 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 al tered then the old paths are tested for
“connectivity” and spliced into correct new paths as necessary. A full description
of how path-based perturbations may be used is given in the papers reprinted in
Appendix H.
Similarly an O BA perturbation starts with the set of origin-based flows from a
previous OBA run and has similar procedures and applications to path-based
perturbations.
5109341 / Mar 13 22-3

Both, in fact, function in a v ery 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 t he 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 r un 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 t hought 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.
Thus it is extremely “natural” to apply both WSTART and D IDDLE 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:
5109341 / Mar 13 22-4

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 nec essary 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 de leted in the “new” network, then an “old”
path pij may no l onger be “valid” in the “new” network and it must be s omehow
“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
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 m uch 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)
5109341 / Mar 13 22-5

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 t he 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
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
5109341 / Mar 13 22-6

by the use of 44444 ba nned 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 w arm start on a t opologically
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 t o 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 us ed as a prior estimate of the new assignment and t he 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 t o know about UFO files so, if you feel that is a
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.
5109341 / Mar 13 22-7

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 s pecified 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 s ome 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
particular method of storing solutions which may then be us ed 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.
5109341 / Mar 13 22-8

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 within Frank-Wolfe

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 l ink in both directions, i.e., link (A,B) has
positive flow and s o does (B,A). One of the main reasons why Frank-Wolfe
converges extremely slowly beyond a c ertain 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 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 s ingle 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
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
5109341 / Mar 13 22-9

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 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 ne twork has been created in SATNET with SPIDER = T and run through
SATALL in the same “mode” then it is possible to use an a lternative set of
procedures to obtain the link flows 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 the spider-based algorithm 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.
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 i nitial 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,
5109341 / Mar 13 22-10

with VDM when SATURN is being linked with an ex ternal 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 r un 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
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 r un 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.
5109341 / Mar 13 22-11

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

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 E uropean Transport Conference and reproduced in Appendix U. The
research concluded that t 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).
5109341 / Mar 13 22-12

2 Major additions DVV 29/05/06
3.1 Minor mods DVV 10/07/06
5109341 / Mar 13 22-13

Linking SATURN and GIS
23. Linking SATURN and Geographical

Information Systems (GIS)
Mini-Contents Page
23. Linking SATURN and Geographical Information Systems (GIS) 23-0

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
5109341 / Mar 13 23-0

INTRODUCTION
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 t he 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 us efully linked
are packages such as GoogleEarth 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 v ery 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 out put 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.
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 G IS network
starting from a basic SATURN network data base.
5109341 / Mar 13 23-1

We may also note that topological data describing a SATURN-based network may
be transferred to an al ternative 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 us ed 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 s et 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 t he
same spatial reference / coordinate system, by default set to British National Grid.
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
5109341 / Mar 13 23-2

♦ MapInfo should be i nstalled (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.
23.4.2 Load SATURN Tools each time MapInfo Starts

Follow the instructions below to instruct MapInfo to load Saturn Tools on ev ery
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
5109341 / Mar 13 23-3

♦ 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
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 >>
5109341 / Mar 13 23-4

Saturn Tools or alternatively the most commonly used tools can be ac cessed
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
3) Accessing menu from the a new menu called Atkins Modelling Tools >>
SATURN Tools.
Figure 23.6 – Atkins Modelling Tools Menu
5109341 / Mar 13 23-5

CREATE NODES
The first thing stage is to create a N ode 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 D UTCH= 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.
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 num bers as label
5109341 / Mar 13 23-6

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 t able 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:
Figure 23.8 – Turns and Nodes Network Example
5109341 / Mar 13 23-7

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 abl e 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
5109341 / Mar 13 23-8

♦ Net _<SATURN dat file name>.MAP
♦ Net _<SATURN dat file name>.ID
♦ 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 t ool 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.
Figure 23.9 – Create Bands Example
5109341 / Mar 13 23-9

To use the Create Band tool, click Create Bands and the following form then
appears:
Figure 23.10 – Create Bands Screen
5109341 / Mar 13 23-10

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 num ber 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;
♦ Meters per Unit - this value specifies the width of the bands per unit. e.g.
Units 10 and M eters per Unit 1 gives a band w idth of 10 for a v alue of 1.
Fixing the units and changing the Meters 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 l egend will be add ed 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.
5109341 / Mar 13 23-11

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 t hen 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 c hanged 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 t able 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
5109341 / Mar 13 23-12

♦ <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:
5109341 / Mar 13 23-13

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 a rea). Below is a zoom in from MapInfo showing you the
detail you can get
5109341 / Mar 13 23-14

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
5109341 / Mar 13 23-15

Round to nearest: value rounds the value from the chosen Label field to the
fraction entered here. (eg set to 1000 a v alue 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.
5109341 / Mar 13 23-16

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 i mported. 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
5109341 / Mar 13 23-17

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. (I know it’s
not logical, but this is the best work around in MapBasic that I could think of – if
you’ve got a better solution don’t hesitate to let me know - Erik).
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 I NI 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
5109341 / Mar 13 23-18

SATURN Tools must be restarted for the changes to take effect.
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 ev er 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
5109341 / Mar 13 23-19

♦ Create Turns
Figure 23.22 – SATURN Log Tools
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 t he
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'.
5109341 / Mar 13 23-20

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 i nstalled (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 B node
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.
5109341 / Mar 13 23-21

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:
♦ 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 i nstallation 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 s pecial 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
5109341 / Mar 13 23-22

♦ Move Node
♦ Adjust Links
♦ Export Curved Links to SATURN
♦ Match Networks
♦ 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
5109341 / Mar 13 23-23

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 t he recommended fields. Compulsory
fields are in Bold other fields may be added at your leisure.
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 t ool 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 c hanged. 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.
5109341 / Mar 13 23-24

Figure 23.27 – Move Nodes
Click the button, hold and drag to new location. Easy as that.
Figure 23.28 – Move Node
5109341 / Mar 13 23-25

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.
5109341 / Mar 13 23-26

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 t o all links found under the cursor on t he first click. Undo will
only undo the last of these actions and should as a rule not be performed when
using these tools.
5109341 / Mar 13 23-27

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.
5109341 / Mar 13 23-28

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 t able into a S ATURN 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 pl ease 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)
5109341 / Mar 13 23-29

♦ 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.
5109341 / Mar 13 23-30

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
5109341 / Mar 13 23-31

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
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 ha ving an i nteger field named Matched. The
Matched field will be either 1 for a successful match or 0 for no match.
5109341 / Mar 13 23-32

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).
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.
5109341 / Mar 13 23-33

SHAPED MASTER NETWORK FOR THE EPSOM SAMPLE NETWORK.

Figure 23.38 - Shaped Master Network for the Epsom sample network
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.
5109341 / Mar 13 23-34

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:
Figure 23.41 – Export Settings to SATURN
5109341 / Mar 13 23-35

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 adde d 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 s o (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
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 m axx, maxy taken from the Mapper
window corners.
To modify this open XYB file in Notepad.
5109341 / Mar 13 23-36

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.
Figure 23.44 – Tile Folder Settings for Future Searches
Note the all paths must end in a '\' character or the tools may fail.
5109341 / Mar 13 23-37

SATURN v10.8 Release –

3.6 DVV 25/03/08
converted to SATURN & GIS
Web release – Jul 08 (Work In

3.7 DVV NP IW IW 07/07/08
Progress
5109341 / Mar 13 23-38

Index
24. INDEX
32-bit / 64-bit Operating System, see Hardware/Soft- 1.2
ware 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
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
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 MAPINFO Tools 23.4
ATLAS 6.3.1, 18.5.6
AUTNUC 15.15.2
Automatic Timer (AUTO) 14.5.4
5109341 / Marc 13 24-1

Index
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
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
Blocking Back 5.1.11, 8.5
Convergence tables 9.9.1
Boroughs: See Traffic Boroughs
Break Option in KEY files 14.5.5
Buffer networks: 5.2, 5.3
Flow-delay curves 5.4.1
Queues and Bottlenecks 5.4.2
Summary Statistics 11.11.4, 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
Bus routes 6.9
Bus companies 6.9.3
Bus Lanes 6.4.9.2, 15.39
Route definitions 6.9.2
5109341 / Marc 13 24-2

Index
Editing bus routes 11.9.4

Interpolation 6.9.2, 15.18
Summary Statistics 11.11.6
As fixed pre-load flows 15.5.5
SLA (Buses through a Select Link) 11.8.4.2
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
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
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
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
5109341 / Marc 13 24-3

Index
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
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
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
5109341 / Marc 13 24-4

Index
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
Network Data files; preparation of 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
Data field editing (global) 11.9.17
.DBD Files (redundant) 11.10.9
DBDUMP 15.46
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
DEFCAP 6.3.3
Delay calculations (Simulation) 8.4
Functions of Flows 8.4.2
Random delays 8.6
Upper limits 8.4.1
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
5109341 / Marc 13 24-5

Index
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
DRACULA Demonstration 11.13.7
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
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 flows: Simulation links 5.1.8
Epsilon Convergence Parameter 7.1.5
Epsilon-2 Congestion Parameter 7.2.6
5109341 / Marc 13 24-6

Index
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
(Data) Field editing (global) 11.9.17
FIFO (See also TOPUP) 6.15.1
Filename conventions 3.3
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
FILTIJ 6.3.4, 7.12.4
FILZ2S 10.2.5.1, 10.5.2, App W.3
Filters at Signals (Priority Marker F) 6.4.2.4
FILRED 6.3.4, 7.12.4
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
Link-specific values on link data Record 2B … 6.4.14
… or on X-Files 6.13.4
5109341 / Marc 13 24-7

Index
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
Skimming 11.11.9, 15.27.3
Sector-to-sector 11.10.7.4
FORMATS: DIY Changing .dat file formats 15.35
FORTRAN Formats: Real Variables 2.8.3
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
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.1.2
Elastic Gap Functions 7.5.5
Supply-Demand Gap functions 15.42
5109341 / Marc 13 24-8

Index
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
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 Systems (e,g., MapInfo ) 23
Give Way Markers (G) 6.4.2.1
GONZO 6.3.3, 7.11.5, 15.2
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
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
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)
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
5109341 / Marc 13 24-9

Index
Inverse Demand Functions 7.7.2

IPERT (Perturbation assignment options) 21.3
IROCKY 6.3.2,5.1.7,6.8,10.2.5,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 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
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
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
5109341 / Marc 13 24-10

Index
LCY (Cycle time in seconds) 6.3.2, 8.1.2, 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
Distances 6.4.5
Restricted 6.7
Simulation links/roads 5.1.3
Stacking Capacities 6.4.11
Speed-flow curves 6.4.12, 15.9.5
Times/speeds 6.4.5
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
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
MASL 6.3.2, 9.1, 9.12.1
MASL_F 7.5.3.4
Matrices:
Aggregating sub-levels (MXAGG) 10.4.2, 10.20.21
Blocks (horizontal levels) 10.2.4
Comparison of 2 matrices (M2) 10.9.2
Compression:
M3 10.16, App. W.1
M5 10.16, App. W.3
Copy a UFM file 10.4
(Minimum) Cost 15.27.1
Create a trip matrix file 4
5109341 / Marc 13 24-11

Index
Crow Fly distances 11.11.16

DAT and UFM files
General Properties 10.2.1
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
Distribution Models 10.18, 10.19.1
Dumping to Ascii Files 10.15, 10.20.15
Editing zones (add, delete, etc.) 10.4.1
Estimation from counts (ME2) 13
EMME/2 Interface 10.5.5
Expansion (M5) 10.16, App. W.3
Factoring 10.7
Selected Area Factoring:
Interactive Control 10.7.1
Input Control File 10.7.2
File structure 10.3
Flared lanes 6.4.9.3
FLAREF 6.4.9.3
FLAREX 8.2.5.2, 8.2.6
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
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
Re-code a UFM File 10.4
Reduction (M4) 10.16, App. W.2
Rule of a Half 10.19.2
Screen Editing the Internal Matrix 10.10.4
Sectors 10.2.5
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
Transposing a matrix 10.4, 10.8.2
Trip Length Distribution 10.9.3
Trip matrix distribution 7.10, 10.18
5109341 / Marc 13 24-12

Index
UFM Output 10.16

Unconnected OD cells 5.5.4
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
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
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.8
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
5109341 / Marc 13 24-13

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
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
MXADD2 10.20.4
MXAGG (Aggregate matrix levels) 10.20.21
MXAVER2 10.20.5
MXBL0CK 10.20.10
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
Assignment network 5.5.1
Beginner's Guide to Coding 5.6
Buffer networks 5.2
Buffer data input 6.6
5109341 / Marc 13 24-14

Index
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 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
OBA – See Origin-based Assignment
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
5109341 / Marc 13 24-15

Index
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
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
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
PCNEAR 6.3.3, 9.1
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
Penalised links & turns 5.1.5, 6.7, 7.11.1, 15.24.4
See also Banned Turns
Perturbation Assignments 21.3, 22.2.6
5109341 / Marc 13 24-16

Index
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
RAGS 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
5109341 / Marc 13 24-17

Index
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
Rivers 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
Routes:
Fixed (Bus) Routes 6.9
“Other” Routes 6.9.4
Timing Points 6.9.5
Interpolation 15.18
Route flows 12.6
Uniqueness 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
Running Programs 3.4
SATALL 9, 9.7
BAT procedure 9.13
Continuation Runs 9.7, 9.12.1
Convergence 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
5109341 / Marc 13 24-18

Index
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
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
SATME2: 13, 13.5
Data Input 13.2.2
Files 13.5.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
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.6
SATPIJA_MC: Multi-core operation 13.4.9, 13.6.3, 15.53.3.3
SATSIM: 8
Control File 8.9.2
Files 8.9.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
5109341 / Marc 13 24-19

Index
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.7
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
Procedure(s) 14.3, 9.14
Suite contents 1.5
SATWIN 3.6
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
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
Sectors 5.1.7, 6.8, 10.2.5
Co-ordinates 6.8
5109341 / Marc 13 24-20

Index
Hierarchical definitions; see TFL and IROCKY 5.1.7

.Z2S files to convert zones to sectors 10.2.5, 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
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
Optimisation within SATALL 9.12.2, 15.31.4
Optimisation for improved convergence 9.5.1
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
Batch file to optimise all signals 15.31.6
Simulation: 8
Cyclical flow profiles 8.1.1
Convergence (internal) 8.3, 9.9.1
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, 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
5109341 / Marc 13 24-21

Index
Roads/links: 5.1.3, 6.4.1

Signals 6.4.1
Summary statistics 11.11.4, 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 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
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
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, 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
5109341 / Marc 13 24-22

Index
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
System/Device Definitions 11.3
TAX 6.3.3, 6.4.2.2, 6.4.9.5, 8.2.4
Link-specific values in an X-FILE 6.13.4
Link-specific values on link records 6.4.14, 6.4.15
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, 10.2.5
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.1.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
Transient queues (maximum length) 8.4.8
Tree Building:
5109341 / Marc 13 24-23

Index
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, App I.9
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 12.6
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
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
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.6
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) 22.5.3, 15.23.6, 15.23.7
Conversion to .UFC (SATUFC) 15.23.5
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
5109341 / Marc 13 24-24

Index
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
User Classes 5.8.1
Names (UCNAME) 6.3.4
Actual Flows 15.21.4
USESPI, USEUFO etc. 15.27.7.3
U-turns: At internal simulation nodes 5.1.4
At external simulation nodes 18.9.1, 16.6.2, 16.6.3
ILOVEU 18.9.2
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) 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
Names (VCNAME) 6.3.4
PCU Factors 15.17.2
Updating trip matrices 13.4.6
Vertical editing of network data fields 11.9.17
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 7.11.9
WIDDLE 7.11.16
Wildcard entries on KNOB Files 15.14.5.2
5109341 / Marc 13 24-25

Index
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
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
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
Z2S files: Zones to sectors 10.2.5, 10.5.1, App W.3
5109341 / Marc 13 24-26

Index
JOB NUMBER: 5109341 DOCUMENT REF: Section 24 Index.doc
2 Various DVV 09/07/06
10.9.17 Web release – Jun10 DVV NP IW IW 22/06/10
5109341 / Marc 13 24-27

Simulation and
Assignment of
Traffic in
Urban
Road
Networks
Appendices - Version 11.2

March 2013
Version 11.2.05
Contents
Contents
Section Page
A. Data Input Using (Pseudo) Namelist A-1
A.1 Version Control A-5
B. Time Period Specific Data Using Namelist B-1
B.1 Version Control B-2
C. Additional SATURN Documentation C-1
C.1 Version Control C-5
D. Changes in SATURN Versions 8.1 - 11.1 D-1
D.1 Changes in SATURN 8.1 D-1
E. SATURN Bugs E-1
E.1 SATURN 10.4 Bugs E-1
E.7 Version Control E-37
F. Unused F-1
5109341 / Mar 13 i
Master Appendices Document.docx
Contents
F.1 Version Control F-1

G. A Brief Overview of the Origin-Based Assignment Algorithm G-1
G.1 Version Control G-5
H. Papers on Path-Based Assignment H-1
H.1 “101 Uses for Path-based Assignment” H-1
H.2 Paper presented in Poland 1999 H-13
H.3 Version Control H-20
I. Annotation Data Lists in P1X I-1
I.1 Link Data I-1
I.2 Turn-based data: I-9
I.3 Node-based Data: I-11
I.4 Version Control I-13
J. A Guide to DA Codes J-1
J.1 DA Codes based on Simulation Roads J-1
J.2 DA Codes based on Assignment Links J-3
J.3 DA Codes based on Simulation Turns J-6
J.4 Version Control J-8
K. Batch Files Included in the SATURN Suite K-1
K.1 Version Control K-7
L. SATURN Error Messages L-1
L.1 Version Control L-15
M. Modelling of Motorway Merges M-1
M.1 Introduction M-1
M.2 Current Status M-1
M.3 Version Control M-2
N. Unused N-1
N.1 Version Control N-1
O. Unused O-1
O.1 Version Control O-1
P. Unused P-1
P.1 Version Control P-1
Q. Using Q Markers for Motorway Merges Q-1
Q.1 Version Control Q-3
R. WebTAG-based Variable Demand Modelling using SATURN R-1
R.1 Background R-1
R.2 Version Control R-2
S. Practical Benefits of Origin-based Assignments & Network Aggregation S-1
5109341 / Mar 13 ii
Contents
S.1 Background S-1

S.2 Version Control S-2
T. Background Theory of Network Aggregation T-1
T.1 Background T-1
T.2 Version Control T-2
U. Unused U-1
U.1 Version Control U-1
V. Dynamic Time Period Choice Modelling (SATKK) V-1
V.1 Version Control V-9
W. Additional MX-based Procedures W-1
W.1 M3: Matrix Compression W-1
W.2 M4: Matrix Reduction W-2
W.3 M5: Matrix Compression, Expansion and Re-coding W-3
W.4 MX-Based M1 to M7 .BAT files W-7
W.5 Version Control W-9
X. Unused X-1
X.1 Version Control X-1
Y. The SAT10KEY DAT File Y-1
Y.1 Version Control Y-3
Z. GIS File Specification Z-1
Z.1 Version Control Z-7
5109341 / Mar 13 iii

Appendix A - Data Input Using (Pseudo) Namelist
A. Data Input Using (Pseudo) Namelist

All input of simple control parameters for programs in SATURN uses the namelist
facility, (or, strictly speaking, a variation on the standard FORTRAN namelist
conventions which we sometimes term “pseudo-namelist”). In effect namelist is a
method of free-format data input in which the user directly defines the values of
certain key parameters or variable names to be used by the program. Variables
which do not appear in the user's list are assigned standard default values.
The most obvious alternative method is input via fixed column conventions
whereby, for example, a ‘1’ in column 10 might indicate that the user wants a
certain file to be output or a 3 in column 5 might indicate that a total of 3 trees are
to be printed. The problem with this method is that it is difficult for the user to
remember which column corresponds to which variable and it is sometimes
difficult for the program to detect that the user wishes to have certain default
values used. Namelist overcomes both problems by associating easily
remembered variable names with pre-defined default values.
A standard namelist input command consists of essentially three segments:
1) An identifier which gives the ‘name’ associated by the program with the
following variable list. This has the form: &PARAM ... where a blank in the
first column and an ‘&’ in the second indicate that the namelist identifier
follows. Here ‘PARAM’ is the name associated with certain list of variables
by the program.
2) Variable definitions of the form:
− KPHMAX=1, ROSIE=F, ALEX=5.2, USER= ‘harry’, ... ,

where KPHMAX is an integer variable used within the program, ROSIE
islogical, ALEX is REAL and USER, a CHARACTER variable which stores
text. Note that each definition is separated by a ‘,’ from that following and
that the final entry is also followed by ‘,’
3) An ‘END’ identifier which indicates the end of the variable definitions and
has the form:-
− ROSIE=T, &END.
Note that the ‘,’ and blank following the final variable are recommended but
not essential; see note 5 below. If &END appears on a new record it must
have a blank in the first column.
Thus a complete input record for data input using namelist might be:
− &PARAM
− ROSIE = T
− AMY = .FALSE.
− ALEX = 5.2
− END
5109341 / Mar 13 A-1

11_2_05_App A.docx
Alternatively, although this is not recommended, all entries could be

squeezed onto one line:
&PARAM ROSIE=T,AMY=T,ALEX=5.2, &END
As mentioned above the precise rules used within SATURN to govern namelist
inputs differ from more standard compiler-specific rules. The SATURN namelist
has been programmed from scratch using FORTRAN such that in some respects
it is less restrictive.
The following rules specify how to set up a set of input records to be read as
pseudo-namelist;
1) The first record contains the “name” of the namelist set, e.g., “&PARAM”.
(Note “PARAM” on its own is also acceptable.)
2) Subsequent records contain variable definitions, one or more per record, of
the form:
− “name1” = “value1” , “name2” = “value2” ...

where “name” is the variable name and “value” is the value that the user
wishes it to take.
3) The “name” entry must be identical to one of a set of variable names
specifically defined for each program. Either upper or lower case characters
may be used but, for the purposes of identifying names, lower case is
converted to upper case. Leading blanks are allowed; i.e. the name need
not begin in column 1, but there cannot be any internal blanks within the
name definition.
4) The “=” above is not strictly necessary although a good idea; a single blank
serves to mark the end of the name and the start of the value.
5) Equally the comma used to separate entries is not necessary - one or more
blanks or a new line are sufficient - but it is probably a good discipline to
stick to.
6) Definitions (name + value) must be entirely contained on one record.
7) “Values” may be one of four types:
(i) Logical, defined by either T or F (although .TRUE. and .FALSE. are
also permitted);
(ii) Integer, defined by a set of numbers without spaces and without any
decimal;
(iii) Real, defined by numbers WITH a decimal point;
(iv) Character, with the alpha-numeric value contained within `....'
8) The “type” must correspond to the “type” of variable as defined by the
program; e.g., you may only use a T or F for a variable which has been
defined as LOGICAL within the program, an integer value for INTEGER
variables and real values for REAL variables. The one exception are real
5109341 / Mar 13 A-2

11_2_05_App A.docx
variables which may be defined by an integer input; e.g., REAL = 6 would be

interpreted as REAL = 6.0.
9) Values may be terminated either by a blank space or a ‘,’.
10) Any “errors” in following the above conventions will result in non-fatal errors
and the line is ignored.
11) As with standard namelist any variable not explicitly defined will take its
default value.
12) “Subscripted” variables are allowed, so that an entry such as:
− MCGILL (2) = 3
would refer, in this case, to the value of a parameter MCGILL for user class
2. (But see Appendix B for another application of subscripts to multiple time
periods.)
Subscripted variables or “arrays” may also be defined in a single record by
an entry such as:
− BTKNOB = 1.0, 3.0, 4.0, 0.0

which would define the elements BTKNOB(1) .... BTKNOB(4) without the
need to repeat the identifier BTKNOB for each element. Applications of
namelist arrays are however somewhat limited to date.
Alternatively a colon may be used to designate a range of subscripted
variables with a single value as in;
BTKNOB(1:5) = 1.5
13) The list of variables is terminated by ‘&END’ as in standard namelist. This
may appear either on a line by itself - most logical - or else after the end of
the value definition. It may also appear on the first record, implying that no
values are to be changed from their defaults.
14) “Comment cards” may be included identified by a * in column 1; the record
is printed to the line printer file but otherwise ignored.
15) Equally comments may be inserted at the end of each record by inserting a
‘*’ and any characters following the * are ignored.
16) The maximum “width” of a record containing Namelist data is 80 columns
and, with the one exception noted next, a single variable specification is not
allowed to continue from one record to the next.
17) However, a Character variable is allowed to have up to 256 characters by
making use of a “continuation” option. For example, to set a filename which
requires more characters than are available within a single 80-character
record the user must: (a) include a + either immediately before or
immediately after the standard variable name, e.g., FILTIJ+ or +FILTIJ
instead of FILTIJ; (b) include only the initial apostrophe ‘ on the first record;
(c) include one or more additional records terminated by the final ‘ at the end
5109341 / Mar 13 A-3

11_2_05_App A.docx
of the last record. Trailing blanks at the end of one record or initial blanks at
the start of a new record are ignored.
18) Namelist records may also make use of the $INCLUDE facility described in
15.30. Thus if the name list records contain a line
− $INCLUDE newlist.dat
the file ‘newlist.dat’ is opened and the program continues to read from that
file until the end of the file is encountered, at which point the program returns
to reading from the original file. The record $INCLUDE must commence in
column 1 and be in upper case. Any text on the remainder of that line is
ignored.
Note the same rules of syntax apply within the ‘included’ file and that it should not
contain either the ‘name’ or ‘end’ identifiers e.g. &PARAM or &END. It is most
usefully used for large namelist segments containing standard definitions, e.g.
emission rate parameters that may be applicable to a large number of data files.
Post SATURN 10.4 a check is made as to whether the same variable “name”
appears more than once. If so, an error plus message is generated. Note that the
error is generally non-fatal but in SATNET it is semi-fatal.
EXAMPLES
For example the parameter records input to program SATME2 might read:
&PARAM
PRINT = F
SEED = 0.00,
* This is a comment
XAMAX = 5.00 * as is this
ITERMX = 10,
&END
A “null” entry could consist of any of the following:
&PARAM
&END
or
&PARAM &END
The first is the “recommended” form.
5109341 / Mar 13 A-4

11_2_05_App A.docx
A.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App A.doc
3 Upgrade to V2 Template DVV IW DVV IW 28/06/06
11.2.05 SATURN v11.2 Release (Full) DVV JS IW IW 17/03/13
5109341 / Mar 13 A-5

11_2_05_App A.docx
Appendix B - Time Period Specific Data Using Namelist
B. Time Period Specific Data Using Namelist

As explained in Appendix A namelist in SATURN is not a standard application but
is a purpose-built facility, therefore allowing the use of various features which are
very much SATURN-specific. One such example is the use of subscripts to
denote specific time periods. Hence a namelist containing the following:
GONZO(1) = 0.66,
GONZO(2) = 1.10,
GONZO(3) = 0.90,
would be interpreted as a request to set the parameter GONZO to the value 0.66
in time period 1, 1.10 in time period 2 and 0.90 in time period 3. In this case the
value of the time period, 1, 2 or 3, would be determined by the context in which
the data file was being used.
This feature allows a particular .dat file to be used for a range of linked time
periods; see Section 17.3 and 17.4.3 for more details.
Both general and time-specific definitions may be contained in the same namelist;
for example:
GONZO(1) = 0.66,
GONZO(3) = 0.90,
LTP = 30
LTP(2) = 15
would specifically set GONZO for periods 1 and 3 but its value for time period 2
would be the default. Equally the default value for LTP would be 30, with that for
period 2 re-set to 15.
The use of subscripts to represent time periods should not be confused with the
alternative use of subscripts to represent user classes (note 12 in Appendix A)
which, at the moment, is only used for a relatively small number of elasticity-
related parameters. Thus the latter parameters cannot be defined with distinct
values by both user class and time period (a system of “double” subscripts could
be introduced if required).
In addition the $INCLUDE file definitions (see 15.30) 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). For example:
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.
5109341 /Mar 13 B-1

11_2_05_App B.docx
Appendix B - Time Period Specific Data Using Namelist
B.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App B.doc
5109341 /Mar 13 B-2

11_2_05_App B.docx
Appendix C - Additional SATURN Documentation
C. Additional SATURN Documentation

The following publications provide useful general descriptions of SATURN and its
applications. The documents with a ‘*’ suffix are reproduced in this Appendix
whilst copies of the others may be obtained on request from DVV.
1) SATURN - A Simulation-Assignment Model for the Evaluation of Traffic
Management Schemes (*).
M.D. Hall, D. Van Vliet and L.G. Willumsen
Traffic Engineering & Control, 21, 168-176, April 1980.
2) Applications of SATURN to the Analysis of Traffic Management Schemes.
L.J.A. Ferreira, M.D. Hall and D. Van Vliet
PTRC Summer Annual Meeting, July 1981.
3) SATURN - A Modern Assignment Model (*)
Dirck Van Vliet
Traffic Engineering and Control, 23, 578-581, December 1982.
4) Equilibrium Traffic Assignment with Multiple User Classes (*)
D. Van Vliet, T. Bergman and W. H. Scheltes
P.T.R.C. Summer Annual Meeting, July 1986.
5) A Validation of SATURN using Before and After Survey Data from
Manchester (*)
A. Matzoros, J. Randle, D. Van Vliet and B. Weston
Traffic Engineering and Control 28, 641-643, 1987.
6) The interaction between signal setting optimisation and reassignment:
Background and preliminary results.
D. Van Vliet, T. Van Vuren and M.J. Smith
Transportation Research Record, 1142, 16-21, 1987.
7) The Frank-Wolfe Algorithm for Equilibrium Traffic Assignment viewed as a
Variational Inequality (*)
D. Van Vliet
Transport Research 21B, 87-89 (1987)
8) A Full Analytical Implementation of the PARTAN/Frank-Wolfe Algorithm for
Equilibrium Assignment (*)
Y. Arezki and D. Van Vliet
Transportation Science 24, 1, 58-62 (1990)
9) A model of air pollution from road traffic, based on the characteristics of
interrupted flow, and junction control: part I - model description, part II -
model results.
5109341 / Mar 13 C-1

11_2_05_App C.docx
A. Matzoros and D. Van Vliet

Transportation Research A, 26A, 4, 315-355, 1991.
10) Demand responsive assignment in SATURN. (*)
M.D. Hall, T. Fashole-Luke, D. Van Vliet and D.P. Watling
Stream E, pp25-39, PTRC Summer Annual Meeting, September 1992.
11) An equilibrium incremental logit model of departure time and route choice.
K.K. Chin, D. Van Vliet and T. Van Vuren
PTRC European Transport Forum, 1995.
12) Incremental traffic assignment: a perturbation approach.
D. Kupiszewska and D. Van Vliet
IMA Conference on Mathematics in Transport Planning and Control, Cardiff
edited by Griffiths, J.D., Pergamon, 1998.
13) 101 uses for path-based assignment.
D. Van Vliet and D. Kupiszewska
PTRC Education and Research Services Ltd, Seminar F, Transportation
Planning Methods, 121-132, 1999.
(Reproduced in Appendix H)
14) Allowing for Variable Demand in Highway Scheme Assessment.
J.J. Bates, D. Coombe, S. Porter and D. Van Vliet
PTRC European Transport Conference, 1999
The following references should be consulted for further details on the ME2 matrix
updating procedures (Section 13):
1) The Most Likely Trip Matrix Estimated from Traffic Counts
H. J. Van Zuylen and L. G. Willumsen
Transportation Research 14B, 281-294, September 1980.
2) Estimation of Trip Matrices from Volume Counts: Validation of a Model
under Congested Conditions
L.G. Willumsen
Proceedings PTRC Summer Annual Meeting, Warwick University, July
1982.
The following references should be consulted for further details on the DRACULA
micro-simulation software:
1) (DRACULA) Microsimulation models incorporating both demand and supply
dynamics (*)
Liu, R. And D. Van Vliet and D. Watling
Transportation Research 40A, 125-150, 2006.
5109341 / Mar 13 C-2

11_2_05_App C.docx
There are also some computer text files which complement the User Manual,
dating from the 1980’s and have limited relevance these days. The files, labelled
as SATURN NOTES (filenames notes.all and tech.n, n = 1,...9), contain a general
description of various theoretical aspects, special features, etc. of the model. The
most relevant sections of the notes are now included within the manual, although
certain detailed pieces of information, e.g. how the lane choice model algorithm
works, the probabilistic modelling of queues and delays at give-ways, are still only
available within the notes. Copies are available from either DVV or Atkins.
Appended Text Files
In the .pdf versions of Appendix C the following files are included below:
(1) Demand responsive assignment in SATURN. (*)
M.D. Hall, T. Fashole-Luke, D. Van Vliet and D.P. Watling
Stream E, pp25-39, PTRC Summer Annual Meeting, September 1992.
(2) A Full Analytical Implementation of the PARTAN/Frank-Wolfe Algorithm for
Equilibrium Assignment (*)
Y. Arezki and D. Van Vliet
Transportation Science 24, 1, 58-62 (1990)
(3) The Frank-Wolfe Algorithm for Equilibrium Traffic Assignment viewed as a
Variational Inequality (*)
D. Van Vliet
Transport Research 21B, 87-89 (1987)
(4) A Validation of SATURN using Before and After Survey Data from
Manchester (*)
A. Matzoros, J. Randle, D. Van Vliet and B. Weston
Traffic Engineering and Control 28, 641-643, 1987.
(5) Equilibrium Traffic Assignment with Multiple User Classes (*)
D. Van Vliet, T. Bergman and W. H. Scheltes
P.T.R.C. Summer Annual Meeting, July 1986.
(6) SATURN - A Modern Assignment Model (*)
Dirck Van Vliet
Traffic Engineering and Control, 23, 578-581, December 1982.
(7) SATURN - A Simulation-Assignment Model for the Evaluation of Traffic
Management Schemes (*).
M.D. Hall, D. Van Vliet and L.G. Willumsen
Traffic Engineering & Control, 21, 168-176, April 1980.
(8) The Common Man’s Guide to Equilibrium Assignment
Dirck Van Vliet, Technical Note 13, ITS Leeds, May 1979
5109341 / Mar 13 C-3

11_2_05_App C.docx
(9) DRACULA: A microscopic day-to-day dynamic framework for modelling

traffic networks
D.P. Watling, R. Liu, D. Van Vliet
Transportation Research A
5109341 / Mar 13 C-4

11_2_05_App C.docx
DRACULA: a microscopic, day-to-day dynamic
framework for modelling traffic networks*
by
Ronghui Liu, Dirck Van Vliet and David Watling
Institute for Transport Studies

University of Leeds
Leeds LS2 9JT
U.K.
*
Paper prepared for Transportation Research A
DRACULA: a microscopic, day-to-day dynamic framework
for modelling traffic networks
Ronghui Liu*, Dirck Van Vliet and David Watling
Institute for Transport Studies, University of Leeds, Leeds LS2 9JT, U.K.
Abstract
We describe a new approach to modelling road traffic assignment, code-named DRACULA

(Dynamic Route Assignment Combining User Learning and microsimulAtion), in which the
emphasis is on the “microsimulation” of individual trip makers and individual vehicles. It
represents directly driver choices as they evolve from day to day combined with a detailed
within-day traffic simulation model of the space-time trajectories of individual vehicles
according to car-following, lane-changing rules and intersection regulations. It therefore
models both day-to-day and within day variability in both demand and supply. As such we
believe it is a particularly suitable framework for the realistic modelling of “real-time”
technological strategies such as responsive traffic control, dynamic route guidance and
congestion management strategies.
A number of representative applications of DRACULA are presented, including: sensitivity

studies of the impact of day-to-day variability; an application to the evaluation of alternative
signal control policies; and the evaluation of the introduction of bus-only lanes in a sub-
network of Leeds. Our experience demonstrates that this modelling framework is
computationally feasible and offers a number of significant advantages over conventional
equilibrium-based models. It also provides a fully internally consistent, dynamic assignment
model with both within- and between-day dynamics, as well as providing a natural means (by
incorporating appropriate behavioural rules) for modelling departure time choice.
Keywords: Network modeling; Microsimulation; Dynamic assignment; Variabilities; Real

time strategies
1. INTRODUCTION
Recent years have seen a massive increase in “real-time” advanced technological strategies
designed, for example, to reduce congestion, improve network efficiency, promote public
transport, decrease pollution and/or increase road safety. At the network-wide level, these
include: responsive, optimized traffic signal control, e.g. SCOOT (Hunt et al., 1981);
congestion-based road pricing (Oldridge, 1990); dynamic route guidance/information and
variable message signs (Emmerink and Nijkamp, 1999); congestion management strategies,
e.g. freeway ramp metering, gating (Papageorgiou et al., 1989; Shepherd, 1991); and
responsive priority measures for public transport (Quinn, 1992; Liu et al., 1998).
* Corresponding author. Tel: +44-113-343-5338; fax: +44-113-343-5334; e-mail: rliu@its.leeds.ac.uk
2
A general property of all these strategies is that they both respond to – and in turn influence -
actual prevailing congestion levels, rather than being designed on the basis of long-term
average conditions. That is to say, the variation in traffic conditions is just as important a
consideration as the mean. Variabilities include the temporal distribution of flows both
within and between days, as well as the variation in travel times and delays both within and
between days. It includes not only “natural” variability associated with normal trip making
decisions but also “unnatural” variability associated with incidents or accidents. In order to
evaluate these systems and to determine the best strategy for implementation, it is crucial to
have a reliable evaluation model that fully incorporates the effects of variability.
For many years, models for assessing traffic networks have been based on the Wardrop
equilibrium principle (Wardrop, 1952), predicting a long-term average state of the network.
They assume steady state network supply and demand conditions from day-to-day and within
different periods of a day, and therefore have had great difficulty in the representation and
evaluation of the above real-time policies whose major purpose is to deal with variability in
demand and traffic conditions. In addition there is strong evidence that by ignoring most
sources of day-to-day and within-day variabilities, conventional equilibrium models tend to
over-estimate network performance and therefore to produce biased results (Mutale, 1992).
This paper describes a new traffic network model framework, DRACULA (Dynamic Route
Assignment Combining User Learning and microsimulAtion), which attempts to represent
directly the behaviour of individual drivers and vehicles in real-time as these evolve from day
to day. It combines an individual driver travel demand and route choice model and a network
learning model with a microscopic traffic simulation model. The demand model represents
the day-to-day and within-day variability in total demand within a fixed departure time
period. The traffic simulation model determines the space-time trajectories of individual
vehicles according to car-following, lane-changing rules and intersection regulations. In
combination they model the evolution of the traffic system over a representative number of
days so that both within-day and between-day variabilities are included.
DRACULA does not explicitly set out to predict, for example, the day-average hourly flow or
delay on a certain link, but to examine the full distribution of flows and delays over the
period modelled. Aggregate measures are then obtained by averages over the full number of
days simulated (less any warm-up period). There is therefore no intrinsic requirement that
the system will settle down to a single self-consistent equilibrium state (as implied by models
based on Wardrop equilibrium principles); indeed, given the variabilities in the model inputs,
variabilities in the outputs are virtually guaranteed.
A brief review of the analysis of traffic networks is presented in the next section. The
proposed microscopic framework of day-to-day dynamic network models is then described.
Potential applications of such a model framework and a number of examples are given,
followed by concluding remarks.
2. BACKGROUND REVIEW
Traditionally the analysis of traffic in urban road networks is based on the concept of
equilibrium whereby a fixed trip matrix is assigned to equal minimum cost routes between
each origin-destination pair based on perceived link costs. Thus it is making very precise
assumptions not only as to how many drivers travel between each origin-destination pair but
3
also as to which routes they use and what the consequent travel costs will be. In addition
temporal variations within the study time period are generally ignored.
There have been many sophisticated equilibrium models developed and indeed widely used
to study the average effect of long-term changes in ‘supply’ conditions (such as the provision
of a major new road or junction design improvements) and/or long-term changes in ‘demand’
(such as that due to a new development or growth in car ownership). SATURN (Van Vliet,
1982) and EMME/2 (INRO, 1998) are two examples of commercial products based on sound
theoretical principles. The major assumptions such models generally make are:
(a) constant (between day) supply and demand conditions;
(b) inelastic demand, in particular departure time choice neglected;
(c) the ultimate prevalence of a stable equilibrium state of the system;
(d) choices made after a measure is introduced are independent of those made before;
(e) all drivers have the same choice objectives and constraints;
(f) drivers acquire perfect knowledge of traffic conditions, including variability over time;
and
(g) queuing is adequately represented by averages over short time intervals.
In addition the supply-side assumptions made in most models are often gross over-
simplifications. For example, the “separability” assumption that the travel time on a link is a
function only of the flow on that link clearly ignores any interaction effects at junctions but is
tolerated due to the fact that it leads to soluble mathematical models.
It is clear that this picture represents an over-simplification of real life. The composition of
the driver base varies from day to day, and in practice drivers do not all find optimum routes,
particularly infrequent drivers. Equally travel conditions vary (sometimes widely) from day
to day, partly due to fluctuating demand but also due to factors such as weather conditions,
incidents etc. There is strong evidence that, due to the non-linearity of cost-flow
relationships, the net effect of variability in supply and demand conditions is to significantly
increase the mean values of traffic outputs such as travel time and fuel consumption. For
example, Mutale (1992), based on a different modelling technique to that used here,
estimated a 14% increase in mean total travel time over equilibrium due to the expected
variability in a north Leeds network.
Partly in response to these deficiencies, enormous advances have been made in the way in
which traffic networks may be modelled. Stochastic equilibrium models try to represent the
uncertainty in drivers’ choices by assuming that perceived utilities are random variables
(Maher and Hughes, 1997; Maher, 1998). Multiple user-class models attempt to differentiate
between drivers (Dafermos, 1972; Daganzo, 1983; Van Vliet et al., 1986). Theoretically
sound dynamic equilibrium models (e.g. Friesz et al., 1989; Ran and Boyce, 1994)
incorporate the within-day dynamics of trip demands and choices although the difficulty in
ensuring the temporal and spatial consistency in the resulting dynamic flows has hampered
the development of efficient and reliable solution algorithms. On the other hand more
heuristic models such as CONTRAM (Taylor, 1990) have successfully incorporated within-
day dynamics. Finally simulation models such as SATURN incorporate traffic interactions at
junctions.
A number of studies have attempted to model "real time" policies by attempting to modify
existing models; see, for example, Van Vuren and Watling (1991) for work on route
4
guidance. The appeal of such methods lies mainly in the production of (hopefully) unique,
stable predictions.
In general terms all such models are constrained to make compromises between the desire to
accurately reflect the behaviour of individual drivers and of the road infrastructure and the
need to design algorithms which can solve the specific model. Very often one feels that the
solution method comes first and the model specification comes second. In particular existing
approaches, all of which are - to a greater or lesser extent - equilibrium based, struggle to deal
with schemes whose main objectives are to deal with variability (e.g. real time information
systems). The success of these real-time strategies depends upon reacting to variability,
which occurs between days, and within days - precisely the variability which equilibrium
models neglect. Furthermore, the range of short-term responses induced will be wider than
route choice, including choice of time to travel and of mode to travel. The nature of these
responses is likely to be highly individual-specific, depending on personal characteristics of
the individual, the nature of the trip, the time-dependent and imperfect knowledge of the
driver, and the driver’s own choice criteria and constraints.
However, fundamental new approaches have arisen in recent years. Firstly the theoretical
work of Cascetta (1989) on stochastic process models of traffic networks signified the birth
of a logical successor to equilibrium models – he derived conditions guaranteeing properties
that are the equivalent of equilibrium uniqueness and stability. Advances have also been
made in representing drivers’ spatially and temporally varying perception of a network
structure (Dehoux and Toint, 1991) and a driver’s habitual tendencies by using appropriate
decision rules (Mahmassani and Jayakrishnan, 1991).
There have been recent efforts to explicitly represent the day-to-day dynamic adjustments in
driver behaviour, based on various behavioural principles and various sorts of static or
dynamic traffic flow relationships (such as DYNASMART, Hu and Mahmassani, 1997;
Cantarella and Cascetta, 1995). Those proposed give great flexibility on the behavioural
choice side, yet are more limited in their traffic flow modelling capabilities. For example, the
traffic simulation in DYNASMART is based on a mesoscopic simulator that treats traffic
individually but moves them according to macroscopic flow principles (Jayakrishnan et al.,
1994). Vehicles move in segments on a link at a speed determined from a speed-flow
relationship and the prevailing density on that segment of road. There is no representation of
vehicles’ lane-changing and car-following behaviour, making it difficult if not impossible to
model complex traffic intersections, responsive signal control, selective vehicle priority
systems, traffic responses to incidents, buses stopping at bus-stops or bus-laybys.
In parallel, there have been large numbers of pure microsimulation models developed, such
as NEMIS (Mauro, 1991), AIMSUN2 (Barcelo et al., 1995), PARAMICS (Cameron and
Duncan, 1996), TRAF-NETSIM (Rathi and Santiago, 1990), MITSIM (Yang and
Koutsopoulos, 1996), and TRANSIMS (Nagel, 1996). These approaches are based on car-
following, lane-changing and gap acceptance rules, and have shown themselves capable of
representing the detailed traffic features just mentioned. However, these models are unable
to address route choice responses in any consistent or acceptable manner. They either have
no concept of a route (with choice behaviour represented by mean turning percentages, which
can lead to paths being traced out with repeated cycles), or have routes determined
exogenously by an assignment model operating at a different level of traffic flow detail. Nor
do they explicitly address the issue of day-to-day demand variability.
5
Unlike the models described above, DRACULA aims to take the best elements of both the
latter two approaches (i.e. day-to-day dynamics and traffic microsimulation) and to set these
in a single, consistent framework. It is a microsimulation of both the demand and the supply.
3. DRACULA MODEL STRUCTURE
As with conventional models the DRACULA approach begins with the concept of demand
and supply (or performance) sub-models that interact with each other. However, by contrast
with conventional models, in DRACULA both the demand and supply sub-models are based
on microsimulation and both evolve from day to day. In DRACULA, trip makers are
individually represented and their daily route choices (demand) are made based on their past
experience and their perceived knowledge of the network conditions. Individual vehicles are
then moved through the network (supply) following their chosen routes according to car-
following and lane-changing rules. The demand stage predicts the level of individual demand
for day n from a full population of potential drivers and the supply model for day n
determines the resulting travel conditions. The costs experienced by drivers are then re-
entered into their individual ‘knowledge bases’ which in turn affect the demand model for
day n+1. The process continues for a pre-specified number of days.
The framework combines a number of sub-models of traffic flow and drivers’ choices for a
given day with a day-to-day driver learning sub-model. In its most general form it has the
following structure although, as we shall discuss later, certain alternative methods or
simplifications are possible within most stages.
1. [Initialization] Establish a population of potential drivers with individual characteristics

and assume initial driver perceptions for each link in the network. Set day counter n=1.
2. [OD Demand] Select the total day-n demand for each origin-destination pair according to
some given probabilistic rules.
3. [Departure Time Choice] Individuals travelling on the day choose their departure time to
travel.
4. [Route Choice] Each driver travelling on the day chooses a route based on their current
perceptions of traffic conditions and previous experiences. The travel time component of
the cost is based on the individuals' departure time and their predicted arrival times at each
link/turn.
5. [Supply Variability] “Global” network supply conditions are selected for day n prior to
loading by some given probability laws to simulate effects such as weather and lighting
conditions. “Local” variations in network conditions (representing road works, incidents
etc.) are also specified.
6. [Traffic Loading] A microscopic simulation of traffic conditions on day n is carried out

given the choices above. Drivers experience within-day variable link/turn travel times for
the route and departure time they have chosen.
7. [Learning] Drivers update their perceptions based on their experiences on day n.
6
8. [Stopping Test] If some stopping condition is satisfied, terminate; otherwise increment the
day counter and return to step 2.
Note that this process need not – and indeed almost certainly will not – converge to a single
precise equilibrium point but will vary from one day to the next. However, due to the
interactions between the demand and supply models, it will – arguably – reach a state where
they are broadly in balance and, at the more theoretical level, our objective is to determine the
probability distribution of individual day-to-day states.
Similar models of this structure have been considered previously by Alfa and Mink (1979),
Ben-Akiva et al. (1986), Cascetta (1989), Vythoulkas (1990), Emmerink et al. (1994), and Hu
and Mahmassani (1997).
Details of the functionality of steps 1 to 5 and 7 are discussed in section 4. Section 5

describes in detail the traffic microsimulation model used in step 6.
4. DAY-TO-DAY EVOLUTION OF TRAVEL DEMAND AND NETWORK

CONDITIONS
4.1. Modelled population
As opposed to the traditional concept of a fixed matrix of trips from origin to destination, the
DRACULA approach is based on the concept of a large “population” representing all the
potential drivers in the study area. Each individual member of this population has certain
characteristics (such as household origin, work place, car-ownership status, driving style etc)
and a “history file” in which the accumulated experience of previous choices and travel
conditions encountered is stored. Equally the vehicle they drive will have certain fixed
characteristics such as vehicle size and engine type (see Section 5.2 for the full list) which do
not change from day-to-day. As far as feasible the distribution of characteristics should
match as closely as possible that of the area being modelled. In practice, however,
simplifications and compromises will need to be made. More pragmatically therefore we aim
at generating a population whose trip making behaviour at the aggregate day-to-day level
matches the averages and variances observed in real life.
For all applications to date the population has been derived from an existing conventional trip
matrix Tij from origin i to destination j. We then assume (see also Section 4.2 below) that the
day-to-day variability in the number of trips may be described by a normal distribution whose
mean is Tij and whose variance is βd2Tij2 where βd > 0 is a user-set coefficient of demand
variation. Hence the demand for ij trips on day k is:
tij(k) = Nor(Tij, βd2Tij2) (1)
and we define our population of potential ij travellers to be Tijmax, the pragmatic maximum
number of trips generated by Eq. (1). In practice we use:
Tijmax = Tij + 3βdTij (2)
By default, each driver’s choice on the first day of travel is based on average free-flow travel
times, and for each link the perception is unchanged until that link is used by the individual.
7
However the initial choices may also be specified to be those resulting from a previous model
run. The most obvious application of this is in a before-and-after study of a scheme, in which
the initialisation of the ‘after’ run is based on the final conditions of the ‘before’ run.
Similarly, the initial “histories” of drivers - ie. their remembered experiences on the network -
may be set to be their accumulated experiences in the previous run.
In addition to “drivers” the modelled population also include elements such as buses
following fixed routes, for which clearly route choice and a “knowledge base” are not issues.
They will, however, require their own appropriate vehicle characteristics.
4.2. Day-to-day demand
On any particular day within the evolution of the model each member of the population
makes a decision as to whether to travel or not. In principle the decision could - and should –
be based on the individual characteristics of that member of the population, so as to
differentiate between regular commuters and one-off shopping trips and to include elements
of their knowledge base. In practice a more pragmatic approach has been used whereby
individual decisions are constrained by the predicted daily trips for their particular origin-
destination pair.
Thus for each origin i and destination j we:

(1) select the mean demand level appropriate to day k, denoted tij(k), from Eq. (1);
(2) form the probability pij(k) = tij(k)/ Tijmax;
(3) each potential traveller then independently chooses to travel on day k with probability
pij(k).
Note that clearly, any reference to drivers’ histories or choices made during the simulation
relates to the fixed pool of potential travellers who keep their identification through the
simulation, rather than the day-to-day varying pool of individuals who actually make a
journey through the network.
A generalisation of this method is also permitted, in which different ‘user classes’ are
defined, which differ only in their propensity to travel (representing, for example, shopping
trips which may be made less frequently than journey-to-work trips).
4.3. Departure time distribution
The choice of departure time within DRACULA may be handled in a number of different
ways. The default and simplest method is to randomly assign a desired departure time for
each potential driver in the modelled population; when drivers choose to travel on day n they
will depart at their desired departure time, independent of their experiences and route choice.
The departure time profile could be flat or distributed probabilistically according to some
user-specified distrbution (e.g. a step function over time slices).
A more complex departure time choice in response to travellers’ experience has also been
incorporated within DRACULA whereby departure time selection takes place at the start of
every day based on a traveller’s preferred arrival time and on the previous day’s experiences
(anyone not travelling on the previous day will keep the same preferred departure time). A
simple continuous adjustment is made for each individual m on each origin-destination
movement i-j in turn, based on that individual’s:
8
(a) preferred arrival time at the destination, aijm;
(b) trip time from the previous day tijm(k); and
(c) departure time on the previous day dijm(k).
For example, aijm could be randomly drawn at the start of the simulation from a specified time
profile as in the first method.
The difference between the desired and actual arrival time on day k is then:
δijm(k) = dijm(k) + tijm(k) – aijm(k) (3)
The driver is assumed to (independently between days and from other drivers) be indifferent
to a lateness of em tijm(k), where em is drawn from a uniform [0, ε] distribution. Hence, we
define the perceived lateness as:
∆ijm(k) = δijm(k) – em tijm(k) (4)
If ∆ijm(k)>0, the users adjust their departure time so that the perceived lateness would be zero
if yesterday’s trip time were repeated, then,
dijm(k+1) = dijm(k) - ∆ijm(k) (5)
Otherwise,
dijm(k+1) = dijm(k) (6)
Thus, in the present version of the model, no early arrival correction is made, but this is
trivial to change, as we would just then always set dijm(k+1) according to Eq. (5) regardless of
the sign of ∆ijm(k). The flexibility of the framework enables a more general (experience-
dependent) departure time choice to be implemented easily at a later stage.
A third, even simpler method, would be to randomly generate a day/trip departure time from
a pre-specified profile, independent of past history.
4.4. Route choice
By default, each driver travelling on a particular day chooses their minimum perceived
generalised cost route based on the traditional concept of utility maximisation that underlies
virtually all current traffic assignment models.
An alternative choice model implemented in DRACULA is the “boundedly rational choice”,

based on the work of Mahmassani and Jayakrishnan (1991). This model assumes that drivers
will use the same (habit) route as on the last day in which they travelled, unless the cost of
travel on the minimum cost route is significantly better than that on their habit route. The
threshold is that a driver will use the same route unless:
Cp1 - Cp2 > max(η∗Cp1, τ) (7)
9
where Cp1 and Cp2 are costs along the habit and the minimum cost routes respectively, η and
τ are global parameters representing the relative and the absolute cost improvement required
for a route switch.
These rules are only intended as an example of the range of rules that could possibly be
implemented in a flexible approach such as DRACULA. Alternative behavioural rules that
could be provided in the future include the concept of risk minimization, with drivers
perceiving cost variances as well as means.
The route choices are made and fixed before the trips start; drivers follow their chosen routes
through the network to their destinations and will not (within the current state of model
development) make en-route diversion when, e.g., encountering congestion.
4.5. Learning
After each journey individuals use their experienced travel times on the links used on that
journey to update their perceived link travel times according to the following conditions:
(a) experiences more than M days old are forgotten; and
(b) the perceived travel cost is the average of (at most) the last N remembered
experiences on that link.
Here M and N are global parameters set at the start of simulation, although their effect will be
specific to each individual’s experience. It may reasonably be argued that these parameters
should be allowed to vary with the driver and/or trip type. Such options can be added to the
program if future research suggests so.
Generally, it is expected that N will be the main parameter affecting perceived cost; M is
intended mainly as a device for drivers to ultimately forget a single bad experience of a link
which may occur particularly in the atypical, initial warm-up days. Therefore, it is expected
that N < M.
4.6. Supply variability
The effect of day-to-day variability of network condition is represented at two levels. The
global variability represents the effects of weather, daylight etc, and is represented in the
model by a variable link cruise speed through a normal distribution:
vm = Nor(Vm, βs2 Vm2) (8)
where vm is a random variable representing the daily cruise speed of link m, Vm the average
cruise speed for the link and βs a global coefficient of variation representing the daily
variation in link speed.
Locally, incidents (e.g., breakdowns or road closures) may occur one day but not another.
This is represented before loading by specifying the location and duration of the incidents.
The global and local variabilities will affect (through the traffic simulation described in the
next section) the travel times of vehicles travelling on that day, but not on the routes
individuals take.
10
5. THE TRAFFIC SIMULATION
The traffic model in DRACULA is a microsimulation of the movement of (pre-specified)

vehicles through the network. Drivers follow their pre-determined routes and enroute
encounter signals, queues and interact with other vehicles on the road. A large number of
such microscopic vehicle models have been developed in the past at varying levels of
complexity and network size (e.g. in some the network is effectively a single intersection) - a
few are mentioned in Section 2. An essential property of all such models is that the vehicles
move in real-time and their space-time trajectories are determined by, e.g., car following and
lane-changing models and network controls such as signals. Rather than adopting an existing
model, in DRACULA we elected to develop our own microsimulation model from scratch
beacuse of the strong need to control the interaction between the supply and demand models
and, in particular, the need to associate a specific route and destination with each vehicle.
The simulation is based on fixed time increments; the speeds and positions of individual
vehicles are updated at an increment of one second. Spatially, the simulation is continuous in
that a vehicle can be positioned at any point along a link. The model includes an animated
graphical display of vehicle movements in the network.
The simulation starts by loading the simulation parameters, network data including global
and local variations and trip information (demand and routes determined by the demand
model). It then runs through an interative procedure at the pre-defined time increments,
within which the following tasks are performed:
1. Update the state of traffic signal controls, and check if any incident starts or ends;
2. Generate new entry vehicles and place them on their entrance links;
3. Loop through all vehicles in the network, and for each one of them:
(a) check if the vehicle wants to change lane and, if so, whether the gaps are acceptable;
(b) update the vehicle’s speed and acceleration and advance it to its new position. At the
end of the link, either remove the vehicle from the network (if it arrives at its
destination) or pass it to its next link en route;
(c) calculate vehicle emissions and fuel consumption, and record traffic performance
measures;
4. Update the graphical display if required;
5. Update the simulation clock and return to step 1.
Two additional time periods are simulated for each study (for example peak) period on each
day: a warm-up period to ensure that the simulation does not start with an empty network and
a cooling-off period which represents, say, the off-peak period. In the warm-up period trips
are generated with flow rates increasing linearly from a pre-peak level (which is assumed to
be half of the starting peak level) to the level at the start of the study period. During the study
period trips generated by the demand model arrive on the network. In the cooling-off period
flows arriving on the network are reduced gradually to an off-peak level, and the run
continues until all trips generated by the demand model complete their journey.
The detailed traffic simulation is discussed next.
5.1. Network represention
11
The network is represented by nodes, links and lanes. A node is either external, where traffic
enters or leaves the network, or an intersection. There is no restriction on the number of
roads connected to an intersection.
A link is a directional roadway between two nodes and consists of one or more lanes. A link
is specified by its upstream and downstream nodes, cruise speed, number of lanes, and turns
permitted to other outbound links from the downstream node. For each permitted turn, the
lane(s) in the link that can use this turn are specified and a marker describing its priority over
opposing flows is given.
In the model traffic moves in lanes. A lane can be reserved for a particular type(s) of
vehicles only (for example a reserved bus lane). The reservation is specified by its start and
end position on the lane and, optionally, by a start and end time of its operation.Vehicles
travel through an intersection along “inter-lanes” which are straight lines connecting the
stopline of an inbound lane with the entrance of an outbound lane; the crossing point of two
inter-lanes is a conflict point.
5.2. Vehicle generation
Vehicles are individually represented; each has a set of individual characteristics including
vehicle type (car, bus, guided-bus, taxi, heavy goods vehicle); vehicle length; desired
minimum distance headway; normal and maximum acceleration; normal and maximum
deceleration; desired speed (relative to the mean speed on any individual link) and acceptable
gap. These characteristics are randomly sampled from normal distributions representative of
that type of vehicle:
pt = Nor(Pt, βv2 Pt2) (9)
where pt is a random variable representing vehicle parameter p for vehicle type t and Pt is the
average value for the type of vehicles. βv is a user-defined coefficient of variation and is
assumed to be independent to vehicle types. The characteristics for each vehicle are chosen at
the start of a model run. The default values are based on a number of sources, including May
(1990), Institute of Transportation Engineers (1982) and Gipps (1981).
Public transport vehicles are represented with additional information such as service number,
service frequency, bus stops and average passenger flows at each bus stop, etc.
Vehicles enter the network at the upstream end of the entrance link (the first link en-route),
with initial position and speed based on the position and speed of the preceding vehicle. If
there is no space available in the entrance link, vehicles wait in a vertical queue at the
upstream end of the link to enter the network at a later time.
5.3. Vehicle movement
Vehicle movements in a network are determined by its desired movement, response to traffic
regulations and interactions with neighbouring vehicles. The simulation maintains a linked
list of vehicles in each lane and moves individual vehicles according to a car-following model
and a lane-changing model, and their response to traffic controls at intersections.
5.3.1. Car-following model
12
The car-following model calculates a vehicle’s acceleration in response to its desired speed
and the relative speed and distance of the preceding vehicle. Depending on the magnitude of
the relative distance, a vehicle is classified into one of three regimes: free-moving, following
or close-following.
Free-moving: when a vehicle is the leading vehicle in its lane and its position relative to the
stopline of the link is larger than a pre-defined threshold dh, or if it is a following vehicle with
a space headway larger than dh, the vehicle accelerates or decelerates freely in order to
maintain its desired speed.
Following: when the space headway becomes shorter than dh but longer than a lower
threshold dl, the vehicle will take a controlled speed which is derived from the relative speed
and distance of the preceding vehicle in a manner similar to that used in NEMIS (Mauro,
1991):
vifollowing(t) = c1vi(t-τ) + c2vi-1(t) + c3(xi-1(t) - xi(t-τ) –Li-1 - simin) (10)
where i and i-1 denote the subject and its preceding vehicle, v and x the speed and position of
a vehicle, τ is the reaction time, Li the length and simin the minimum safety distance of the
vehicle. Parameters c1, c2 and c3 are constants.
Close-following: when the space headway is below dl, the following vehicle will prepare to
stop in case the preceding vehicle brakes suddenly. A Gipps’ (Gipps, 1981) safety speed is
used which has the following form:
close
vi (t) = d i τ + di 2τ2 -di {2[x i-1 (t -τ)- x i (t -τ)-Li-1-si min ]- vi (t -τ) τ- vi-1 (t -τ) 2 /d'i-1} (11)
where di is the maximum deceleration of vehicle i and d’i-1 is the deceleration of vehicle i-1
perceived by vehicle i; the latter is assumed to be the minimum of -3.0 and (di-1-3.0)/2 m/s2.
In the model, the vehicle’s reaction time (τ) is assumed to be the same as the simulation step.
The actual speed of the following vehicle i is:
vi(t) = min(vifollowing(t), viclose(t)) (12)
In all cases, drivers will not want to move at a speed exceeding their desired one, accelerate
at a rate exceeding their maximum acceleration, or decelerate above their maximum
deceleration rate. When a vehicle moves at a speed below a minimum speed, the vehicle is
regarded as stationary.
5.3.2. Lane-changing model
The lane-changing model contains three steps: (1) obtain the lane-changing desires and define
the type of changing, (2) select the target lane, and (3) change lane if all gaps are acceptable.
The model divides drivers’ lane-changing desires into one of five types when drivers have to
or want to change lane in order to:
(a) reach a bus stop on the link;
(b) avoid a restricted-use lane or incident;
13
(c) make their turn from the next junction;
(d) move into a lane reserved for their type; or
(e) gain speed by overtaking a slower moving vehicle.
The first three types are “mandatory”, i.e. the lane-changing has to be carried out by a certain
position on the current link; the other two types are “discretionary”. Whether a discretionary
lane-change can be carried out depends on the actual traffic conditions. For example, a
vehicle would only change lane to gain speed if the speed offered by the adjacent lane is
higher by a pre-defined factor.
When a vehicle wishes to change lane, it looks for a target lane. The target lane is generally
determined by the lane-changing requirement, except in the case of overtaking which is only
permitted from the nearside to the offside. Once it has chosen a target lane, it examines the
“lead” and “lag” gaps in its target lane, and makes the lane-changing movement immediately
if both lead and lag gaps are acceptable. For discretionary lane-changing, a gap gi for vehicle
i is acceptable if it is greater than a minimum safety distance Gimin which the vehicle wants to
keep in case the preceding vehicle breaks suddenly:
Gimin = vi*τ + vi2/(2*di) - vi-12/(2*di-1) + simin (13)
The acceptable gap for mandatory lane-changing decreases as the vehicle gets closer to its
‘target point’. The target point can be a bus-stop, the position of an incident, or the end of the
queue from the stopline (in the case of lane-changing for next junction turning). If a vehicle
gets nearer to its target point but has not been able to change to the target lane, the vehicle
may slow down and eventually stop and wait for an opportunity to change lanes. When the
speed on the target lane is below a pre-defined threshold, some drivers on the target lane may
deliberately slow down in order to create gaps for the subject vehicle to join. These drivers
are randomly selected from a pre-defined proportion which is related to the type of subject
vehicle (for example, there might be a higher proportion of people willing to giveway to
buses than to cars).
Vehicles can only change one lane at a time. After one such manoeuvre, the vehicle has to
wait for a pre-defined period of time before making another lane-changing attempt.
5.3.3. Intersection simulation
Vehicles start to react to traffic controls (signals or giveway) at a downstream intersection

when they are within the distance dh from the stopline. Only the lead vehicle in each lane
reacts to intersection control; the following vehicles follow the preceding ones according to
car-following rules until they become the lead vehicle. Three types of intersections are
modelled: signalised, giveway and roundabout.
At a signalised intersection, when the signal has just changed to green, the head of the queue
checks whether its path is clear before moving off. During the remaining green period,
vehicles move across the intersection at a speed determined by the car-following rules: the
lead vehicle follows the last vehicle in the outbound lane it turns into. At the instant the
signal changes to amber, the vehicle nearest to the stopline will consider whether to stop. If it
is too close to the stopline, it will either go ahead if it can pass the stopline within the amber
period with its current speed, or alternatively make a random decision whether to carry on
moving or to stop. If the decision is to stop, it applies its maximum deceleration if necessary;
14
similarly, if it decides to go on, it may accelerate at its maximum acceleration rate. This
decision is then maintained throughout the remaining amber period. A vehicle is allowed to
move across at the start of a red signal only if it can not stop at the stopline with its maximum
deceleration.
Travelling towards a giveway intersection, vehicles will aim to stop just before the stopline,
and only when they are a few metres away from the stopline where they can see the situation
on the major road will they start to look for gaps to join in or to cross the major flows. The
acceptable gap is individual based and can vary with the length of time the individual has
waited at the giveway sign. Vehicles approach a roundabout as though approaching a priority
junction and give way to circulating traffic on the roundabout.
5.4. Simulation outputs
The traffic simulation records the link travel times for each demand trip and passes this
information to the driver learning process where the individuals update their perception of the
network incorporating today’s travel experience.
As a measure of network performance, the simulation also outputs (by default) network, link
and route specific measures such as average travel time, speed, queue length, fuel
consumption and pollutant emission over regular time periods defined by the user. At the
user’s request, the program may also output vehicle trajectories. A graphical animation of the
vehicles’ movements can also be shown in parallel with the simulation, giving the user a
direct view of the traffic condition on the network.
6. IMPLEMENTATION
DRACULA has been developed as a flexible framework through modular implementation of

its sub-models. We described in Section 4 and 5 the most general formulation of the demand
and supply models. At its most detailed level, DRACULA represents individual drivers’ day-
to-day choice making processes and individual vehicles’ movements through a network; this
version of the model is hereafter called the “full model”.
In practice, however, it may be desirable to run the model with a number of simplifications.
Thus, the traffic supply model may be based on a more conventional static network model
with macroscopic flow-delay functions but with variable parameters such as link capacity,
while the demand model is based on the full evolution of driver choices from day to day. An
application of the latter approach is described in Section 7.2.
Similarly the demand route choice can be derived from a static equilibrium assignment, but
applied to the vehicle-by-vehicle simulation. DRACULA is compatible with the equilibrium
model SATURN such that it can use the network and route assignment from SATURN and
combine that with its detailed microsimulation to model the supply-side effect of some real-
time strategies. The microsimulation model requires essentially the same basic data as a
macrosimulation model such as SATURN - nodes, links, number of lanes per link, lane
markings, signal operations, giveway rules, etc., with some extra data related to the geometry
and size of intersections for example.
15
The flexibility of the framework ensures that, while keeping its novel aspects in one way or
the other, DRACULA can be integrated to a greater or a lesser extent into existing models.
Current data bases will almost certainly provide the best starting points for new models.
The program is written in C, and operates under the PC MS-DOS or WINDOWS

environment. The implementation imposes no limitation on the size of the network or the
demand level. However, the processing speed does decrease as the number of vehicles
travelling on the network at the same time increases; the processing speed does not appear to
be affected significantly by the size of the network.
Figure 1 shows the simulation processing speed (measured as the ratio of the time simulated
to CPU time) as a function of traffic density in a network using a Pentium II-300 PC. The
network is the north Leeds network described in Section 7.5. It can be seen from the figure
that the processing speed decreases exponentially as flow density increases. Even at the full
demand (23,000 vehicles/hour) the simulation ran 20 times faster than real time.
(insert Figure 1 here)
7. APPLICATIONS
7.1. General
While in theory DRACULA could be applied to studies of long term and large scale network
changes, such as the construction of new motorways or a bypass, this is an area where
conventional aggregate equilibrium models are likely to be satisfactory (although the difficult
question of demand responses such as departure time changes arises even here). However the
behaviourally sounder microscopic models could be used to test certain key assumptions of
macroscopic models, and to suggest alternative methods (possibly empirical modifications)
which might improve conventional techniques. Certain fundamental questions related to the
stability of solutions and the existence of multiple equilibria may also be addressed by such
models (Watling, 1996).
However, it is in the general area of testing real-time policies that we feel the use of
microscopic models to be essential. For example it is an ideal environment for a detailed
simulation of responsive signal control systems (such as SCOOT), including the potential
effects on driver re-routing. Similarly it can be used to model congestion pricing schemes
such as those proposed by Oldridge (1990) where the charge - if any - is determined by the
precise space-time trajectory of individual vehicles. Aggregate network models have
singularly failed to come to grips with such policy tests (May et al., 1997). In addition
disaggregate demand models, in which each individual’s propensity to pay for travel may be
represented, offer a sounder behavioural basis than aggregate models.
A key feature of the model is its ability to consider multiple classes of users, which may
differ in one or more of the following characteristics:
(a) informed or non-informed, and the nature of information available;
(b) speed-control equipped or not;
(c) behavioural response rules;
(d) traffic performance characteristics (length, acceleration, deceleration, risk);
16
(e) vehicle types which determine their access to physical facilities (such as bus lanes,
HOV lanes and guideways for guided buses).
Finally, it offers an opportunity to measure measure reliability within a modelling framework.

Reliability is an issue which is probably felt to be crucial by most commuters but generally
disregarded by most models.
Next we present some results from applications of DRACULA in studying the variability
effect, in modelling dynamic systems on drivers route choices and system performances, and
in scheme evaluation. The results and discussion are primarily intended to illustrate the
applicability of the DRACULA approach, and to show that the model responds logically to
changes in model parameters.
7.2. Day-to-day variability (Simplified Model)
In this section, a simplified DRACULA model is used to study the sensitivity of the model
predictions to day-to-day demand and supply variability. A highly simplified traffic model is
used, with a static flow-delay relationship for each link and no junction-based delay. In
particular, below capacity travel time is assumed to increase with flow according to a power-
law, with delays increasing linearly above capacity according to deterministic queuing
theory.
On the demand side, the full evolution of driver choices from day to day (as described in
Section 4) is modelled. On the supply side, link capacities vary randomly (according to a
uniform distribution) from day-to-day to simulate crudely the effect of parking, accidents etc.
Preliminary tests with the above model have been performed on a number of networks,
ranging from small artificial ones to a real-life network (created originally for the SATURN
equilibrium model) containing some 440 links and 20000 individual trips on average per day.
Because neither the method of generating the variability, nor the actual levels of variability
assumed, were calibrated from real-life data, the work was considered to be more of a
sensitivity analysis. For this reason, it is not appropriate to report absolute figures. Instead,
the general themes arising from the tests are reported. These will serve as hypotheses, to be
tested in the next sub-section on different scenarios.
Stability of the model was examined by comparing day-averaged link flows and travel times
from runs with different numbers of total days simulated, different numbers of “warm-up”
days discarded, and different pseudo-random number seeds. In addition, successive n-day-
average flows were compared (n=10) as a measure of 'stability'. Different networks tended to
need a different number of days to stabilise to the same level, although 50-100 was generally
found to be adequate. The apparent stability was verified by comparing runs with different
random number seeds, where it was confirmed that the differences in mean flows were
attributable purely to sampling variation.
The general findings were:
(a) As might be expected, link flow variances generally increased with a decrease in the
behavioural parameter M (see Section 4.5) over the range 5 to 20. Provided M was
somewhat less than the number of (non warm-up) days simulated, mean flows were not
17
greatly affected. For large values of M, certain pathological cases existed where single
very bad experiences in early days had a significant effect on final flows.
(b) When the behavioural parameter N (Section 4.5) was set to 1 (in practice, this is
something akin to a network full of “tourists”), the model produced unstable - and
perhaps implausible - flows for long periods. However, for larger values of N (3 ≤ N ≤
10) this instability was not evident. The mean flows did not vary greatly with N in this
latter range.
(c) Increasing the variability in OD demand was found to increase the variance in link flows,
though it did not substantially affect mean flows. For 3 ≤ N ≤ 10, these mean flows were
found to be well-approximated by a deterministic equilibrium model applied to the
average OD matrix.
(d) Variability in capacity, when applied to certain critical links, was found to have the
greatest effect on long-term mean flows, these being rather different to the equilibrium
prediction from average capacity values.
(e) Generally, even in cases where equilibrium and mean day-to-day flows were similar, the
former model consistently under-estimated average total travel time in the network (as
expected - see Cascetta, 1989; Mutale, 1992).
7.3. Day-to-day variability (Full Model)
Further to the tests reported above, the full DRACULA model was used to further study the
effects of demand and supply variability on network performance. The full model, which
contains the main features listed in Sections 4 and 5, was applied to the network of Otley – a
real-life network with some 50 links and 2,500 individual trips in a one-hour morning peak.
Six simulation tests were conducted with various level of variability in day-to-day demand
and network supply conditions (including vehicle characteristics). The detailed parameter
settings are listed in Table 1. For each test a total of 100 days were simulated.
(insert Table 1 here)
Figure 2 shows the day-to-day total vehicle travel times (in vehicle-hours) over the 100 days
simulated for tests 1-4. It demonstrates a general feature of DRACULA results: the results do
not converge to a single equilibrium state but continue to vary ad infinitum. Figure 3
compares the relative impacts of demand and supply variability on the averages and variances
in daily vehicle travel times; the comparison is made under the assumption that a demand
variability range of 0<βd<0.2 is comparable to a supply variability range of 0<βs+βv<0.2.
Both Figs. 2 and 3 show that the day-to-day total vehicle-hours are much higher on average at
higher variability than at lower variability. More specifically Fig. 3a shows that the demand
variability on its own does not substantially affect the average travel times, most of the
increases being due to supply variability. However, the demand variability introduce greater
variation in day-to-day travel times than does the supply variability (Fig. 3b). This implies
that a network becomes more unreliable as the demand variation increases.
(insert Figure 3(a) and 3(b) here)
18
A further study was carried out on the Otley network, with βd, βs, and βv all being set at 0.2
and a total of 1000 days being simulated. Figure 4 shows the frequency distributions of total
network travel times by day over the 1000 days simulated. It can be seen that the distribution
is skewed towards higher travel times, illustrating the existence of a small number of “very
bad” days. These days, although relatively few, have a significant impact on the average
result since they are not compensated by any “very good” days. Thus the mean travel time of
98.6 is significantly greater than the mode of 88.7 and the median of 95.0
7.4. Responsive traffic signals
In this example, we apply DRACULA to a study of the effect of responsive signals on

network performance and drivers’ route choice. The full DRACULA model was tested on a
small artificial network with 4 possible routes, 4 signals and 2 O-D pairs (see Figure 5).
The signals may be set by a simple responsive “equi-saturation” policy where the green
proportions allocated to each stage are determined based on the number of vehicles
discharged in the previous cycle. Here, signal cycles were kept constant and a minimum
green period of 8 seconds was maintained. In addition, a fixed plan optimised to the average
traffic condition is used for comparision. A total of 100 days and two levels of variability in
daily demand (βd = 0.05 and 0.2) were simulated. The averages and standard deviations in
network total travel times (in vehicle-hours) are summarized in Table 2. Day to day total
vehicle-hours are shown in Figures 6(a) and 6(b) for the low and high levels of variability
respectively.
(insert Tabel 2 here)
(insert Figure 6(a) and 6(b) here)
It can be seen that:
(a) Under both signal control policies, both the average and variance in vehicle-hours are
higher at higher demand variability. This conforms with the results found in the above
two studies;
(b) Average travel times are lower under the responsive policy than under the fixed plan; and
(c) The responsive policy performanced even better over the fixed signals under higher
demand variability; the average difference in travel times between the responsive signals
and the fixed plans is 26.7sec with βd=0.2 compared with 20.4sec when βd=0.05 (Fig. 6).
19
The better travel performances produced by the responsive signals have also played an
important role in drivers’ route choice. Changes in signals were seen to attract drivers to the
more direct routes. With the responsive plans all drivers were assigned to the two minimum
distance routes by the end of 100 days, whereas with the fixed signal all four routes were
used.
7.5. Scheme evaluation
In this example, we apply the full DRACULA model to a large, real-life network to examine
the short-term effect of a demand-management measure on drivers’ route choice and network
performance. The network (cordoned off from the SATURN Leeds model) covers a triangular
area (in the north of Leeds) between the outer ring road and the city centre (see Figure 7).
There are some 200 intersections, 400 links and 23,000 car trips per hour in the morning peak
period. The radial routes carrying most of the traffic to the city centre in the morning are
Kirkstall Road on the east, Meanwood Road on the west, and Otley Road and Spen Lane in
the middle.
The proposed scheme introduces bus-only lanes on Otley Road in-bound from the ring road to
Shaw Lane (shown as zigzag links in Figure 7). The road space available to general traffic is
hence reduced from two lanes to one. The remaining lane is further narrowed to reduce the
free-flow speed. The full DRACULA model is used to compare the route switching and
travel time changes for the before and after scenarios. A total of 100 days were simulated with
βd, βs and βv all being set to 0.1. Only the car trips were simulated.
With the severe reduction on road capacity along Otley Road, it is expected that some route
switching to alternative routes must take place. Figure 8 shows the differences in average link
flows between the base and the scheme scenario over the last 50 days simulated. It can be
seen that flow through the upper Otley Road was significantly lower in the scheme network
than in the base network and that much of those flows were diverted to nearby Spen Lane or
Meanwood Road. An analysis of trips from the top of Otley Road just outside the Ring Road
to the City Centre (an OD pair whose minimum distance route is along Otley Road) reveals
that the average journey time has increased from 10.5min to 11.5min in the scheme network.
9. CONCLUSIONS
The methodology described here is similar to conventional models in that it starts with the
same basic behavioural assumptions, eg. that drivers attempt to choose maximum utility
routes and that they wait for gaps in the major flows at priority junctions, and outputs the
same aggegated statistics such as average link flows and times. However it differs
significantly in that it operates throughout at a very disaggregate level and aggregates by
20
explicit summation at the end rather than trying to infer aggregate system properties via
deductive mathematical formulae and algorithms as conventional models do. This approach,
we believe, offers several distinct advantages as outlined below with particular reference to
areas where, we believe, conventional models experience problems. Inevitably, it suffers
from a number of disadvantages which we also list.
Its advantages include the following:
1. By incorporating the most significant causes of variability in traffic conditions it

represents a far more realistic and far more comprehensive model of road networks than
conventional models. It is clear to even the most casual observer that every road and
junction in a traffic network experiences a wide range of conditions throughout the day
and throughout the year. To characterise a particular link by saying it has an average
peak hour flow of, say, 1800 vehicles per hour at a speed of 18.3 kph (as a conventional
model might) is like saying the average day time temperature in Leeds is 13ºC. These
figures are not necessarily wrong, but they certainly fail to adequately describe the full
picture.
2. It produces a much greater range of outputs, not just means but also variances and
probability distributions both within and between days.
3. By explicitly modelling variability at several levels it avoids the potential bias of

conventional models to overestimate network performance as mentioned in Section 2.
The average results produced by DRACULA are true means of a distribution of predicted
daily outputs, not the estimate of some "average" day.
4. It is capable of testing a much greater range of policies, more specifically those

mentioned in the Introduction such as route guidance or responsive traffic signals which
attempt to deal with the variability in traffic conditions in addition to the mean conditions.
5. By working at a disaggregate microsimulation level it can avoid – or, to be more accurate,

has the potential to avoid - a large number of approximations that conventional models
are forced to make, particularly at the ‘supply level’. For example, conventional
assignment models are very weak in dealing with time-dependent queues which occur
with junctions which are near or just over capacity. In DRACULA queues build up and
decay perfectly natually and need not occur at the same time and to the same extent each
day. As a second example, conventional network models find it difficult to deal with lane
choice and lane sharing problems (in fact most tend to ignore it entirely) whereby a single
vehicle at the head of a lane which is turning to the offside and is blocked by opposing
traffic may therefore block that lane for straight ahead and/or nearside turns. In models
such as SATURN, this effect is modelled on a probabilistic basis whereby the likely
number of non-blocking vehicles at the head of a queue is estimated. Again, in
DRACULA this situation presents no problems; blocking lanes (and lane choice) occur in
a natural manner.
6. It provides a solution to ‘dynamic assignment’ where it is dynamic both within and

between days. Moreover it does not need to rely on extensions to Wardrop’s Principle in
order to obtain a mathematical formulation, but is based on more behaviourally sound
principles.
21
7. Furthermore it has the potential to provide a mechanism for modelling departure time
choice which clearly is an important issue in over-capacity situations, and one which to
date conventional models have significantly failed to address. A relatively simple and
preliminary specification was given in Section 4.3, although the tests reported here used
pre-determined departure times.
8. Multiple user classes are straight forward to model at virtually any level of disaggregation
and at virtually no extra computational effort, simply by associating particular
characteristics with each member of the "population". Indeed, since each member can be
assigned a whole "vector" of characteristics, there is great flexibility in aggregating travel
statistics by "class". Contrast this to conventional models where each user class requires:
(a) a distinct trip matrix (or, more often than not, a distinct factor) and (b) a separate set of
shortest route calculations; so that the total cpu time increases roughly in proportion to the
number of classes.
9. By operating in real time DRACULA may be used to provide inputs to other real-time
models such as vehicle emission and dispersion models or noise models. Since these
processes do not directly affect driver behaviour they can be thought of as add-ons - albeit
very important ones - rather than integral components.
Clearly there are problems with a microsimulation approach. These include:
1. It requires large quantities of computational time and memory, which increase roughly
linearly with the size of the problem. Nevertheless, as demonstrated in Figure 1,
DRACULA can run moderately sized networks on standard PCs much faster than real
time and, given the rapid improvements in computer technologies, computational
requirements will become less of an issue in the future. It should also be noted that, once
beyond the initial warm up period, all calculations in DRACULA are useful, unlike
conventional assignment models where early iterations only serve as a means to approach
the final "correct" iteration.
2. As with all "stochastic" models its outputs are subject to statistical uncertainties and are
sensitive to the precise stream of random numbers used. Deterministic models do have
the advantage of providing an exact "point" solution (within convergence errors, of
course).
3. Calibration is difficult, particularly given the wide range of input variables and the fact
that it is generally not possible to associate a directly observable output with a single
input. For example, if one were to measure the day-to-day variance in link traffic flows
and speeds it might be possible to "match" these variances by varying any one of a
number of input parameters such as the ß's in Eqs. (1), (8) and (9).
4. Similarly, since its input parameters are almost all "universal", it may be difficult to
calibrate more "local" parameters, for example, the capacity or the saturation flow of a
single link, which would normally be provided as input data in conventional models.
5. Since there is no direct analytical functional relationship between inputs and outputs it is
difficult to use DRACULA as a "normative" model, e.g. to use it to suggest improved
strategies for setting traffic signals or providing route guidance. Its role is firmly in
evaluation.
22
Overall we would argue that a microsimulation framework such as that embodied within
DRACULA offers a viable alternative for futher developments compared with the more
traditional equilibrium or aggregate models. The applications described here show that it can
handle realistically sized networks on standard PCs and that it responds logically to various
sources of variability.
The framework is undergoing further research and development, reflecting on-going research
in developing real-time strategies and in the dynamic evolution of traffic networks.
Improvements have been made to the simulation of public transport networks (including bus
service routes, bus stops and reserved bus lanes), selective vehicle detection and journey time
prediction and responsive signal controls for public transport priority (Liu et al., 1998).
Research is under way to study the effect of external vehicle speed control systems on
network congestion, pollution and safety, where the DRACULA model is used to model the
complex interactions between speed-controlled and non-controlled vehicles (Liu and Tate,
1999). It is also planned to connect the simulation model to a real-time signal control system
(such as SCOOT) and to incorporate dynamic en route diversion into the framework. A
traffic emission model has been developed under the general framework which takes
individual vehicles’ instantaneous speed and acceleration and derives pollutant emissions.
Acknowledgements
We wish to acknowledge a grant from the UK Engineering and Physical Science Research
Council and useful discussions with a large number of colleagues both at ITS and elsewhere
over a long period of time.
References
Alfa, A.S. and Mink, D.L. (1979) A stochastic model for the temporal distribution of traffic
demand - the peak hour problem. Transportation Science 13, 315-324.
Barcelo, J., Ferrer, J., Grau, R., Florian, M. and Chabini, E. (1995) A route based version of
the AIMSUN2 micro-simulation model. 2nd World Congress on ITS, Yokohama.
Ben-Akiva, M., De Palma, A. and Kanaroglou, P. (1986) Dynamic model of peak period
traffic congestion with elastic arrival rates. Transportation Science 20(2), 164-181.
Cameron, G.D.B. and Duncan, G.I.D. (1996) PARAMICS, parallel microscopic simulation of
road traffic. J. of Supercomputing 10(1), 25-53.
Cantarella, G.E. and Cascetta, E. (1995) Dynamic process and equilibrium in transportation
networks: towards a unifying theory. Transportation Science 29(4), 305-329.
Cascetta, E. (1989) A stochastic process approach to the analysis of temporal dynamics in

transportation networks, Transportation Research 23B, 1-17.
Dafermos, S.C. (1972) The traffic assignment problem for multiclass user transportation
networks. Transportation Science 6, 73-87.
23
Daganzo, C.F. (1983) Stochastic network equilibrium with multiple vehicle types and
asymmetric, indefinite link cost Jacobians. Transportation Science 17, 282-300.
Dehoux, P. and Toint P. L. (1991) Some comments on dynamic traffic modelling in the
presence of advanced driver information systems. In Advanced Telematics in Road
Transport, Elsevier, 964-980.
Emmerink, R.H.M., Axhausen, K.W., Nijkamp, P. and Rietveld, P. (1994) Effects of

information in road transport networks with recurrent congestion. Transportation 22, 21-53.
Emmerink, R.H.M. and Nijkamp, P. (ed.) (1999) Behavioural and Network Impacts of Driver
Information Systems. Avebury, Aldershot, UK, in print.
Friesz, T.L., Luque, J., Tobin, R.L. and Wie, B. (1989) Dynamic network traffic assignment
considered as a continuous time optimal control problem. Operational Research 37(6), 893-
901.
Gipps, P.G. (1981) A behavioural car-following model for computer simulation.

Transportation Research 15B, 105-111.
Hu., T.-Y. and Mahmassani, H.S. (1997) Day-to-day evolution of network flows under real-
time information and reactive signal control. Transportation Research 5C, 51-69.
Hunt, P.B., Robertson, D.I., Bretherton, R.D. and Winton, R.I. (1981) SCOOT – a traffic
responsive method of coordinating signals. TRRL Laboratory Report 1014.
INRO Consultants Inc. (1998) EMME/2 User’s Manual, Release 9.0.
Institute of Transportation Engineers (1982) Transportation and Traffic Engineering

Handbook, 2nd edition. Prentice-Hall Inc., Englewood Cliffs, N.J.
Jayakrishnan, R., Mahmassani, H.S. and Hu, T.-Y. (1994) An evaluation tool for advanced
traffic information and management systems in urban networks. Transportation Research 2C,
129-147.
Liu R., Clark S.D., Montgomery F.O. and Watling D.P. (1998) Microscopic modelling of
traffic management measures for guided bus operation. Paper presented at the 8th World
Conference on Transport Research, Antwerp, Belgium, July 1998.
Liu, R. and Tate, J. (1999) Microscopic modelling of external vehicle speed control systems.
Paper presented at the 1999 UTSG Annual Conference, January 1999, York.
Maher, M.J. (1998) Algorithms for logit-based stochastic user equilibrium assignment.
Transportation Research 32B, 539-549.
Maher, M.J. and Hughes, P.C. (1997) A probit-based stochastic user equilibrium assignment
model. Transportation Research 31B, 341-355.
24
Mahmassani, H.S. and Jayakrishnan, R. (1991) System performance and user response under
real-time information in a congested traffic corridor. Transportation Research 25A, 293-308.
Mauro, V. (1991) Evaluation of dynamic network control: simulation results using NEMIS
urban microsimulator, Transportation Research Board 70th annual meeting, Washington DC.
May, A.D. (1990) Traffic Flow Fundamentals. Prentice Hall, Englewood Cliffis, New Jersey.
May, A.D., Milne, D.S., Smith, M.J., Ghali, M.O. & Wisten, M.B. (1997) A comparison of
four alternative road pricing systems, Proc. of the 7th World Conference on Transport
Research, Sydney, (ed. Hensher, D.A., King, J. & Oum) Pergamon.
Mutale, W. (1992) Effect of variability in travel demand and supply on urban network
evaluation, PhD Thesis, University of Leeds, U.K.
Nagel, E. (1996) Particle hopping model and traffic flow theory. Physics Review E53(5),
4655.
Oldridge, B. (1990) Electronic road pricing - an answer to traffic congestion? Proc.

Information Technology and Traffic Management. HMSO, London.
Papageorgiou, M., Hadi-Salem, H., Blosseville, J.M. & Bhouri, N. (1989) Modelling and
real-time control of traffic flow on the Boulevard Peripherique in Paris. IFAC Control,
Computers, Communications in Transportation, Paris, Pergamon, Oxford, 205-211.
Quinn, D.J. (1992) A review of queue management strategies, Traffic Engineering + Control,
33(11), 600-605.
Ran, R. and Borce, D.E. (1994) Dynamic Urban Transportation Network Models. Springer-
Verlag, Berlin.
Rathi, A. and Santiago, A. (1990) The new NETSIM simulation program, Traffic
Engineering + Control, 31(5), 317-320.
Shepherd, S.P. (1991) The development of a real-time control strategy to reduce blocking-
back during oversaturation using the microsimulation model NEMIS. Proc. of the 24th ISATA
International Symposium on Automotive Technology and Automation, Florence, Italy,
Automotive Automation Ltd, 151-158.
Taylor, N.B. (1990) CONTRAM 5: an enhanced traffic assignment model, TRRL RR 249.
Van Vliet, D. (1982) SATURN - a modern assignment model, Traffic Engineering + Control,
23(12), 578-581.
Van Vliet, D., Bergman, T. and Scheltes, W. (1986) Equilibrium traffic assignment with
multiple user classes. Paper presented at the 1986 PTRC Summer Annual Meeting, Brighton,
July, 1986.
Van Vuren, T. and Watling, D. (1991) Multiple user class assignment model for route
guidance. Transportation Research Record 1306, 22-32.
25
Vythoulkas, P.C. (1990) A dynamic stochastic assignment model for the analysis of general
networks. Transportation Research 24B, 453-469.
Wardrop, J.G. (1952) Some theoretical aspects of road traffic research. Proceedings, Institute
of Civil Engineers, Part II(1), 325-378.
Watling, D. (1996) Asymmetric problems and stochastic process models of traffic

assignment. Transportation Research 30B, 339-357.
Yang, Q. and Koutsopoulos, H.N. (1996) A microscopic traffic simulator for evaluation of
dynamic traffic management systems. Transportation Research 4C, 113-129.
26
Table 1
Coefficient of variances used in the simulation tests.
Test Number βd βs βv
1 0.05 0.05 0.05
2 0.10 0.10 0.10
3 0.15 0.15 0.15
4 0.20 0.20 0.20
5 0.05 0.20 0.20
6 0.20 0.05 0.05
Table 2
Summary results of network total travel times (in vehicles-hours) under the two signal control
policies.
Demand Variability Signal Policy Mean Std. Dev.

Fixed 101.1 15.6
βd = 0.05 Responsive 79.7 12.2
Difference 21.4
Fixed 111.5 44.0
βd = 0.2 Responsive 84.6 36.0
Difference 26.9
27
Figure Captions:
Fig. 1. Simulation speed factor versus traffic density.
Fig. 2. Daily network total travel time (in vehicle-hours) over 100 days simulated under
variable demand and supply conditions. Four levels of coefficient of variation (CoV=0.5, 0.1,
0.15 and 0.2) are introduced to both the day-to-day demand (βd) and the supply (βs and βv).
Fig. 3. Average (a) and standard deviation (b) in daily travel times as a function of demand
and supply variability.
Fig. 4. Frequency distribution of average daily travel time (in vehicle-hours) for the Otley
network, based on a simulation of 1000 days.
Fig. 5. The network for testing the signal control policies. Intersections C, D, E and F are
signalized and the two OD pairs are A to B and B to A. One-way streets are indicated by
arrows.
Fig. 6. Network total travel time under the fixed and the responsive signals, for demand
variability of 5% (a) and 20% (b).
Fig. 7. The North Leeds network. The proposed bus-lanes run along the links shown as zigzag
lines. One-way streets are indicated by arrows.
Fig. 8. Flow differences between the base and the scheme network averaged over the last 50
days. Black and gray indicate an increase and decrease of flow from the base to the scheme
network respectively. The bandwidth is in proportion to the flow difference.
28
Figure 1.
140
Simulation Speed Factor
120 North Leeds Network

100
80
60
40
20
0
0 0.2 0.4 0.6 0.8 1 1.2
Density /23,000 vehicles
29
Figure 2.
CoV=0.2 CoV=0.15
60 CoV=0.1 CoV=0.05
50
Total Travel Time
40
30
20
0 20 40 60 80 100
Day
30
Figure 3(a)
50
supply only
Av. travel time (sec) 45 demand only
demand+supply
40
35
30
25
0 0.05 0.1 0.15 0.2 0.25
Coefficient of Variation
Figure 3(b)
4
Stdev. of travel time (sec)
supply only
demand only
3
demand+supply
0
0 0.05 0.1 0.15 0.2 0.25
Coefficient of Variation
31
0
0.
21
0
0.
20
0
0.
19
0
0.
18
0
0.
17
0
0.
Average Travel Time

16
0
0.
15
0
0.
14
0
0.
13
0
0.
12
0
0.
11
0
0.
10
.0
90
.0
80
.0
70
200
175
150
125
100
75
50
25
0
Frequency
Figure 4.
32
Figure 5.
C D E F
A B
33
Figure 6 (a)
250 Responsive
Fixed
Total Travel Time
200
150
100
50
0
0 20 40 60 80 100
Day
Figure 6(b).
Responsive
250
Fixed
Total Travel Time
200
150
100
50
0
0 20 40 60 80 100
Day
34
Figure 7.
Outer Ring Road
Otley
Road
Meanwood
Road
Kirkstall
Road
Spen
Lane
City
Centre
Figure 8.
150 vehicles:
35
C.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App C.doc
11.2.01 SATURN V11.2 Beta Release DVV JS IW IW 07/12/12
5109341 / Mar 13 C-5

11_2_05_App C.docx
Appendix D - Changes in SATURN Version 8.1 – 11.1
D. Changes in SATURN Versions 8.1 - 11.1

D.1 Changes in SATURN 8.1
SATURN 8.1, introduced for the first time to users in September 1990, represents
a major upgrade to SATURN 7.1 with both changes to existing programs in
addition to totally new facilities. The inevitable bad news is that files produced
with SATURN 7 are no longer “legible” under SATURN 8 although - the good
news - the raw data files should, generally speaking, be upwards compatible
(though certain minor corrections may be necessary).
Thus it is quite feasible to transfer work already begun using SATURN 7 onto
SATURN 8 but starting with the original data files as input to SATNET to define
the network and as input to M1 to define a trip matrix, not the output binary files.
If you no longer have the matrix data files, or a matrix has been modified such that
only a binary file is available, you should make use of the VVDART option within
M1 (N.B. SATURN 7 M1) to “dump” the binary into a card image file which may
then be input into M1 of SATURN 8. Alternatively a one-off program MATUP78
has been written to convert SATURN 7 binary matrix files into SATURN 8 binary
matrix files, but it may need to be tailored to local systems.
With network data files the situation is different in that there is no program to
“dump” network binary files into card image, although on the other hand the
opportunities to “edit” network files in version 7 were very limited. Hence you
should still have the original card image files. (If not, ring DVV for advice.)
It should however be noted that you will not produce exactly the same results,
e.g., flows and times, using version 8 as were obtained with version 7 since
certain aspects of the simulation have been changed(/improved?). Whether these
differences will be large or small is hard to predict since it depends on whether or
not your network contains many nodes which are critically different under
SATURN 8. The only answer is to try it! (Buffer-only networks, on the other hand,
should give identical results, provided that all control parameters are unchanged.)
The following material describes in greater depth the main differences between
SATURN 7 and SATURN 8.1, divided into various categories.
D.1.1 General New Features

1) A system of “pseudo-namelist” input is now available within all programs,
whether or not a user’s compiler supports the “proper” namelist facility. This
applies in particular to micro users. This makes the input of parameters
considerably easier and obviates the old system which required that records
be input in a very precisely defined order. It also allows for the upwards
compatibility of SATURN 7 data files.
See Section Appendix B for details.
2) A set of “conventions” has been established for high level procedures (bat
files to micro users) whereby all operating systems can be made to “look
5109341 / Mar 13 D-1

11_2_05_App D.docx
alike” in terms of their command structures. This allows for a more

“universal” documentation and is described in Section 3.4.
3) Equally a universal set of conventions has been established for filenames -
or, more precisely, for filename extensions. Thus, for example, all input data
files should have the extension “dat” as in “livnet.dat”. See Section 3.3.
4) A system of “help” files has been added to all interactive programs such as
SATLOOK, P1, etc., to provide an on-line help with the menus. See Section
9.1.2.
5) Updating the programs to accommodate different maximum network
dimensions prior to compilation is now much simpler and can be done purely
and simply by changing dimensions; all the “exceptions” have been
“programmed out”.
6) New PC 386 versions are available based on the Salford FNT77 compiler
which incorporates its own graphics routines and therefore enables more
graphical facilities combined with easier programming. Equally for users
who wish to compile the programs themselves using their own graphics
library the “conversion logic” is much improved with all graphics calls being
contained in well-defined subroutines within a new graphics library. Things
ARE easier - trust me!
The documentation is much improved, with a more logical structure, more sub-
sections, better cross-references and a (still fairly basic) index.
D.1.2 Changes to Existing Programs

Various “major” program specific changes are noted below; “minor” changes such
as the re-ordering of menus are ignored.
D.1.3 SATNET
1) 5 digit simulation node numbers now permitted.
2) Turn priority “modifiers” have been added to change the impact of priority
markers in certain (probably unusual) situations; see 6.4.2.
3) Each record in a UFS file now has a “title”; a new data file (SATTIT.DAT) is
therefore needed as input to SATNET to define them.
4) Users are recommended (as a consequence of allowing 5 digit node
numbers) to use 99999 instead of 9999 to mark the ends of data segments
in the input to SATNET.
5) Roundabouts may now be coded as simulation node type 5 which implies
that U-turns are permissible.
6) New parameters include KORN, KOB
See Section 6.3.
5109341 / Mar 13 D-2

11_2_05_App D.docx
D.1.4 SATASS
1) An improved multiple user class assignment algorithm has been introduced
which should improve the division of link flows between user classes.
2) New options ROSIE and DIDDLE introduced, largely as yet for
experimentation; see Sections 7.1.3 and 7.8 respectively.
3) The method by which random costs in stochastic assignment are
determined has been changed to make them capable of being repeated later
on for analysis purposes; refer to parameters KORN and KOB in Section
7.2.3 and 7.2.4.
D.1.5 SATSIM
1) The lane choice mechanism has been updated, maybe EVEN improved!
2) Delays to turns in shared lanes are more self-consistent, reflecting the fact
that they share the same queue.
3) Unblocked vehicles at the head of a lane when lights go green can now “go”
before a blocked vehicle arrives.
4) Output statistics now include estimates of, e.g., vehicle-kms in later time
periods due to queued traffic.
D.1.6 SATLOOK
1) A new option provided to give summary statistics of errors and convergence
parameters from a full SATURN run.
2) The tree building options have been considerably extended.
D.1.7 P1
1) A new option to automatically display ALL trees from an interactive
assignment for a single O-D pair.
2) Forests may now be built and displayed directly in P1 (rather than
transferring them from SATLOOK).
3) Options to “shift” the window, e.g., to the left or right, and to “zoom” or “pan”.
4) Turn data may now be annotated, e.g., turning volumes.
5) Similarly node data other than simply node numbers may be displayed.
6) An informative “banner” giving details of the plot is available.
7) The “scale” of the plot is calculated, e.g., 1:10000, and may be used to set
the window size.
8) 2-way flows may be chosen.
D.1.8 SATED
1) Node graphics introduced.
5109341 / Mar 13 D-3

11_2_05_App D.docx
2) Cyclical flow profiles may now be disaggregated by lane as well as by turn.
D.1.9 Changes to Matrix Facilities

1) In the matrix furness program M6 new origin and destination totals may now
also be defined as differences or factors from the existing totals as opposed
to defining each total explicitly.
2) Most matrix-based programs, which in version 7 would only run in a “batch-
mode”, may now be run in an “interactive mode”; see Section 10.9. Indeed
the interactive mode is now much the easiest way to run matrix programs so
that the hassle of preparing a control file first may now be avoided.
3) Binary matrix files are now stored in the same “Dirck Access” format as the
network binary files, thus simplifying certain analysis functions.
4) A new matrix program, M7 carries out a matrix transformation in the sense
that the (i,j)th element becomes the (j,i)th.
D.1.10 New “Major” Programs
SATDB
Although introduced in later versions of SATURN 7 SATDB is now offered
“officially” as part of SATURN 8. See Section 9.5 for a more complete description
of its extensive data base facilities.
SATCH
Equally the cordon program SATCH was included in later versions of SATURN 7
but is now released in a more polished form as part of SATURN 8. See Section
12.1.
SATOFF
A totally new program in SATURN 8, SATOFF optimises signal offsets, mainly
with a view to deciding on appropriate offsets in future networks with very different
flow patterns from the present. See Section 12.2.
SATU2
SATU2 is a supplementary program for PIJA analysis which converts PIJA values
calculated by SATASS into matrices of trips using the selected links. See Section
11.6.
D.1.11 New “Minor” Programs

Programs DALOOK, DACHEX, DADUMP and DALOAD have been added with
slightly esoteric functions which generally speaking are not required by the normal
user. See Sections 12.3, 12.4 and 12.5 for further details.
5109341 / Mar 13 D-4

11_2_05_App D.docx

For users who are upgrading directly from version 7 to version 8.2 directly, read
Appendix D first. SATURN 8.2 was first released in May 1991.
Welcome to the Club!
First, the good news! Matrix files, both .dat and .ufm, are unchanged. Network
.dat files have been extended but version 8.1 files are equally valid under 8.2.
However network .ufs and .ufa files treat co-ordinates differently; networks with
no co-ordinates should be upwards compatible - although they will miss out on a
good deal of the fun! Re-running jobs from the same .dat files should however
produce identical results.
Now for the new developments.
The biggest change between versions 8.1 and 8.2 is largely invisible to users,
although its eventual affects will be great. Thus a new “level” of network definition
has been created - the “map network” - in addition to the existing buffer and
simulation definitions. A map network consists exclusively of “lines” or non-
directional roads in the sense that both a 1-way and a 2-way section of road are
represented by a single “line” on a map. Thus a plotted network may be
considered as a network of lines, some of which may have a 1-way property.
As a result of introducing the map network P1 has been substantially re-written
internally, although the menus as seen by users are essentially the same.
A resulting new concept is the idea of “interpolated” routes whereby, e.g., a bus
route may now be specified by a series of unconnected nodes and the program
builds up a complete route by “filling in” the intermediate nodes in the route. The
interpolation is based on map network definition. This feature appears thus far in
several programs - SATNET, SATCH, P1 and others. See Section 15.18.
We note that the map-based features are only available in those networks where
co-ordinates are defined for (all) nodes in the original .dat file. Thus including
node co-ordinates should be increasingly seen as mandatory - although strictly
the programs can still be run without them.
One - inevitable! - consequence of the mapping concept is that networks created
under 8.1 are no longer compatible with 8.2, unless they happen to contain no co-
ordinate data.
Another new concept in 8.2 is that of “sectors” whereby every zone may be
defined as part of a larger “sector” - a common feature in most studies already.
This enables, e.g. zone-to-zone trip matrices to be automatically grossed up into
sector-to-sector format for easier analysis.
A further new general concept concerns interactive programs such as SATDB,
SATED, etc. which now automatically produce a “log” file which records all the
user’s terminal inputs. This may then be used as a “dummy” input terminal file to
repeat the same set of commands in a “batch” or “off-line” mode. Thus all
interactive programs may all be run repeatedly in “batch”. See Section 9.1.3 for
complete details.
5109341 / Mar 13 D-5

11_2_05_App D.docx
Various “major” program specific changes are noted below; “minor” changes such
as the re-ordering of menus are ignored.
D.2.1 SATNET
1) The parameter FOZZY is introduced to enable bus routes to be defined via
“interpolation” - a godsend for users with many routes! See 6.3.1 and 6.9.
2) “Sectors” definition has been introduced as (an optional) part of the co-
ordinate data input section. See Section 6.8 and the new parameter
IROCKY in 6.3.2.
3) Link/turn count data may be sub-divided into several different “sub groups”,
generally referred to as “screen lines” by using the ‘777’ data input records
more than once. See 6.10.
4) The new parameter BEAKER allows capacity indices to be defined for turns
in the simulation network as well as links. See Section 6.3.1.
5) Nodes not given co-ordinates may now have them worked out from the co-
ordinates of their neighbours.
D.2.2 SATDB
1) The facilities to carry out “selected link assignment” have been considerably
extended, e.g., to allow the analysis of trips crossing any one of a set of
screen line links (as defined in SATNET) in addition to trips using a single
link/turn. In addition a “selected trip matrix” may also be created and sector-
to-sector trips may be printed.
2) A new “miscellaneous” option permits link and/or turn data to be read from
an input “text” or “data” file, stored in the internal data base and from there
stored in a UFS file (if required). This provides a relatively simple method
for transferring data into a SATURN file, e.g., from another suite of
programs.
D.2.3 P1
Although substantially re-written to make use of the “map network”, P1 will appear
much the same to users - although there has been a certain amount of “shuffling”
of options between menus. In addition a number of new facilities have been
added:
1) Terminal output (screen size permitting) now includes a text banner down
the right-hand side with, e.g., a list of the parameters being annotated,
origins and destinations from trees, etc.
2) Tree selection has been considerably enhanced and includes both
isochrones, skimmed times and distances plus an “animated” link-by-link
display of minimum routes.
3) “Interpolated routes” - see above - may be directly selected and displayed by
nominating end nodes.
5109341 / Mar 13 D-6

11_2_05_App D.docx
4) Link annotation “bandwidths” may now be “in-filled” and/or over-written with

numerical values.
5) The format of the input device data file GRAF.DAT has been altered from
8.1; this also applies to SATED.
D.2.4 SATED
1) Two new methods of defining and editing data for a single simulation node
are introduced:
(i) the data may be read entirely from a .dat file (e.g., as input to
SATNET), or else
(ii) a buffer node in an existing UF file may be converted into a simulation
node, making the maximum use of the information already coded
within the buffer network.
2) The node graphics have been extended to allow the animated display of
cyclical node profiles, e.g., the change in the queuing pattern over a single
cycle of the traffic signals.
5109341 / Mar 13 D-7

11_2_05_App D.docx

For users who are upgrading directly from version 7 to version 8.3 directly, read
appendices D and E first. SATURN 8.3 was first released in December 1991
(although many of the program changes reported below were actually
incorporated in earlier releases but largely undocumented).
Basically SATURN 8.3 does not represent a major change from 8.2, it is more a
continuous development with a number of specific new programs being added.
Thus there are no changes in either data inputs or the structure of the various
binary UF files (except in so far as new variables/records may have been added).
We first describe the three new programs added under SATURN 8.3, SATEASY,
SURI and MX, followed by new features common to all (or most) programs in the
Suite and by specific “major” changes to existing programs.
D.3.1 SATEASY
SATEASY is essentially the latest version of SATASS and will in time replace it
completely. However for the moment both will exist in tandem.
The main extension in SATEASY is that it allows an elastic Wardrop assignment
for one user class; e.g., assignment plus modal split. A number of notes
describing the theory, options, inputs etc. are available on hard copy - please ask
DVV for copies.
A further extension allows for multiple-user-class elastic assignment, so that you
can model the differing reactions of work trips and shopping trips to increased
congestion.
What SATEASY does not have is any sort of selected link analysis and therefore
no PIJA analysis. My intention is to set up a new separate program, say
SATME1, that will do the PIJA analysis based on the SAVEIT principle. It also
does not allow “quantum assignment” which is now felt to be counter-productive
for the reasons given in 7-4-5.
It does however also contain a new PARTAN option (which may be set as a
parameter on the .dat files input to SATNET) which carries out “PARTAN”
assignment as a variation on Frank-Wolfe for Wardrop equilibrium with a single
user class. I have an article by Yazid Arezki and myself from Transportation
Science which gives the theory and I can send that to anyone interested.
PARTAN may significantly speed up the rate of convergence and as far as I am
aware (famous last words!) is bug-free. Try it and see if it works - I would be very
interested to find out how it performs.
No documentation on PARTAN yet included - be patient.
D.3.2 SURI
SURI is a SATURN-URECA Interface program developed jointly by Leeds and
WS Atkins. Unlike other programs in the Suite it is only available via an extra
purchase from Atkins since only UK users will be interested.
5109341 / Mar 13 D-8

11_2_05_App D.docx
D.3.3 MX
MX is a prototype matrix data base program which will do for matrices the sort of
things that SATDB does for networks. The idea is to eventually include most of
the functions now carried out by M1 to M7 within one, essentially interactive,
matrix manipulation program, MX.
At the moment MX is all there but with very little documentation and a bit like a
brand new house with a roof and all the windows in place but with the distinct
possibility that it you switch on the hall light the loo may flush! New facilities are
being continually added.
One totally new option is the facility to create a new matrix from one or more
existing matrices using FORTRAN style equations. Hence it can be used instead
of the ADD, DOT, etc. options in M1, as well as doing more complicated functions.
For example if you wanted to set up a “deterrence function” matrix defined by
EXP( -B * C(I,J) then MX can do that for you.
Basic documentation is included in 10-9 and the help file is mostly done. In
addition there is an MX.bat file so type MX or MX I and see how you get on. Ring
DVV with any queries - or suggestions/requests!
D.3.4 New General Features

1) Link capacity restraint/speed-flow curves introduced on internal simulation
links. This, for example, enables motorway-style links to be included within
the simulation network. See 6.4.12.
2) A “MENU” parameter is included in the DOS.bat command files which allows
you to run “batch” programs more easily. Thus the command:
M1 MENU
runs M1 with interactive menu control - similar to typing “M1 I”
followed by defining the control file as “TERM”. Same effect, just
simpler. Documentation to follow. Try it.
3) An “automatic timer” option (nothing to do with ovens!) has been added so
that when running interactive programs with KEY input (i.e., dummy terminal
input) the program pauses for a fixed number of seconds between each
screen. Documented in 14.7.1. It is essentially designed for demonstration
purposes.
4) Equally a “break” facility has been incorporated into KEY files to allow you to
transfer from the batch mode back to interactive. Useful for re-defining
program defaults as local standards. See 14.7.2.
5) A (highly) prototype Geographical Information System (GIS) has been
introduced whereby P1 network plots can include background information
such as political boundaries, rivers, place names etc. This is highly
experimental at the present - my intention is to include it “properly” as a
feature of SATURN 9 at which point we have some form of mouse-activated
input which will make it easy for the user to define the data that has to go
into the GIS file. The current version is (even by my standards!) user
unfriendly as I am still playing around with appropriate file formats and what
5109341 / Mar 13 D-9

11_2_05_App D.docx
sort of features are desired by users. However I'm very keen on the whole
concept so any suggestions are very welcome.
See Section 9.4.6 for reasonably comprehensive documentation.
6) At certain points in certain programs where the program has “paused” it is
now possible to move immediately on to another output display by pressing
a single key. For example in P1 you may shift the window upwards by either
pressing U or the cursor control up-arrow once the current plot is finished;
previously you would have had to hit ‘return’ to get to the main menu and
then request the “up” option there.
The facility is only (currently) used at four different points; in P1, MX,
SATDB and SATED, but more will be added later. See Section 9-1-4.
7) SATASS and SATLOOK now provide summary statistics for total flows
through penalised links or turns (as defined under the 44444 cards input to
SATNET) in terms of total pcu-hrs/hr.
8) A third form of randomised cost distribution is now available under SUZIE; a
value of KOB = 2 uses normal distributions where SUET now defines the
coefficient of dispersion (variance to mean) as opposed to the coefficient of
variation (standard deviation to mean) as under KOB = 1. Theoretically this
has nicer properties, in particular for links ‘in series’. It may be used in
SATASS, SATLOOK, SATDB and P1.
D.3.5 Specific Program Changes
SATNET
Link capacity restraint/speed-flow curves introduced on internal simulation links.
This, for example, enables motorway-style links to be included within the
simulation network. See 6.4.12.
SATLOOK & SATDB

New “files menus” included in both to provide greater flexibility in defining files.
(N.B. These menus are designed to have the same “look and feel” as the files
menu in P1 although all three differ in details).
SATED
The node graphics provide an option to print out link data (e.g., flows) in addition
to turn data for the selected node.
M1
1) The “stack” option now allows up to 10 single matrices to be stacked (the
previous maximum was 4). In addition, under MS-DOS a new procedure
“STACK” is provided to make stacking matrices easier. Type STACK for
details.
2) A new “unstack” option now allows you to convert a stacked matrix into its
constituent parts. See the parameter UNSTACK in 10.2. In addition, under
5109341 / Mar 13 D-10

11_2_05_App D.docx
MS-DOS a new procedure “UNSTACK” is provided to make unstacking

automatic. Type UNSTACK for details.
M6
New option ‘NEWT’ allows for the input of selected row/column totals instead of
having to define them all.
P1
1) GIS (Geographical Information Systems) input files introduced. See Section
9.4.6.
2) A supplementary node co-ordinate file can now be input to update node co-
ordinates; useful for correcting plots without having to go all the way back to
SATNET. Accessed from the Files Option in P1; details under Help and in
9-4-8.
3) An option to interactively change node co-ordinates within P1 has been
added, entered either from the Files Option or - 386 users only - by typing E
(for Edit) when closing a plot on the screen (an example of point 6 under
General Features above). Sector-based co-ordinates may be defined at the
same time. In addition the complete set of (new) co-ordinates may be
“dumped” to a card image file suitable for direct inclusion in a network .dat
file.
4) The matrix display facilities have been extensively updated and extended.
For example you can now look at two matrices at once and select ranges of
rows and/or columns to display. Using the latter facility it is possible to
examine, in effect, individual matrix
5) The node display menu has been updated and various new options
introduced.
6) Options to “force” the banner to appear either on the right or the top of the
plot are now available - previously the program choose for itself where - and
if - to put the banner.
5109341 / Mar 13 D-11

11_2_05_App D.docx

SATURN 8.4, first released in October 1992, does not represent a major change
from 8.3, but (like 8.3 before it) is part of a continuous development with one
major new program P1X being added. Thus there are no changes in either data
inputs or the structure of the various binary UF files.

1) The KEY and VDU facilities have been augmented by allowing the user to
change the definition of these ‘modes’ by the use of AUTO and VDU records
in a KEY file. See Section 14-7-3.
2) A third form of randomised cost distribution is now available under SUZIE; a
value of KOB = 2 uses normal distributions where SUET now defines the
coefficient of dispersion (variance to mean) as opposed to the coefficient of
variation (standard deviation to mean) as under KOB = 1. Theoretically this
has nicer properties, in particular for links ‘in series’. It may be used in
SATASS, SATLOOK, SATDB and P1. See 13-2-3.
3) Screen output (386/486 versions) now comes in colour - in particular the
Help system should only be accessed by users wearing dark glasses!
4) More comprehensive simulation network summary statistics are provided in
the output from SATSIM.
D.4.2 New Programs: P1X

P1X is an extended version of P1 which includes not only the ‘network graphics’
features of P1 but also the node graphics from SATED. In programming terms it
is a fairly enormous program which possibly will not fit into all computers. It does
however certainly work on 486 systems where it was developed.
It represents a major extension to P1, in particular by including the node graphical
display of single nodes previously available within SATED but also much
extended now.
Other new features include:
a) Output “.PCX” graphic files - see Appendix Z.
b) More turn data available, e.g. V/C ratios;
c) An option provided to “round off” annotated link data.
d) GIS file formats now specified; see Appendix Z.
e) An option is provided to define an “alternative device”, e.g., useful to jump
quickly from an image on the terminal to hard copy output without going
through a whole series of menus.
f) Selected link assignment (as in SATDB) plus display now available directly
in P1X.
5109341 / Mar 13 D-12

11_2_05_App D.docx
g) Link “selection” may now be based on data being annotated (previously this
could be done but only be “re-creating” the same data within the Select
Menu)
h) Bandwidths on hard copy output device may now be “in-filled” by a set of
parallel lines 1 mm apart.
i) An option has been added so that, when numerical annotation is included
with a bandwidth, it may be either inside or outside (i.e., on top of) the
bandwidth.
D.4.3 Specific Program Changes
SATSIM
The output summary statistics, e.g., total vehicle-kms., are given more
comprehensively by including both figures for the time period simulated plus
estimates for any queued traffic, as well as being disaggregated by type of flow
(e.g., buses, user class) and by capacity index (if used).
SATED
The node graphics are considerably improved (as well as being included within
P1X; see above). In particular the flexible band-widths or “tubies” for displaying
turn data is a major improvement. In addition:
1) Stage diagrams may be “inserted” at the top of the plot.
2) SATLOOK-style numerical output now directly accessible from the graphics
menu.
3) Salford PC versions now include an option to “define” node data via
“windows” which are superimposed on a node graphics plot.
SATLOOK
The convergence statistics summary tables are a bit more “clever” in that they
exclude parameters which cannot be measured under certain options.
SATME2
1) Selected elements within the trip matrix may be “fixed”.
2) Constraints need no longer be “equality” constraints; counts may be
interpreted as upper or lower limits.
N.B.The current version of SATME2 was previously available under the name
“SATME3”; it now replaces SATME2 as the new facilities have now been
sufficiently well tested. Data files previously used may need minor alterations to
conform to the new input conventions and/or variable names.
5109341 / Mar 13 D-13

11_2_05_App D.docx

SATURN 9.1, first tested on an experimental basis in May 1994, contains a
number of major changes from 8.4, but at the same time is part of a continuous
development. Thus the basic structure of both the network and matrix ASCII data
input files and of the various binary UF files is essentially unchanged and files
created under 8.4 or before should still be largely compatible with 9.1 (although
the converse is not true - files created under 9.1 will almost certainly not run with
8.4 programs.) The formats of some of the “minor” data files however have
changed as, inevitably, will the exact order of inputs in “key” files.
The program structure has undergone some modifications. Thus the program MX
has been extended to include virtually all the functions contained in programs M1
to M7 so that these programs, although retained in 9.1, are being gradually
phased out. Secondly P1X has incorporated many routines from SATDB and
SATED and the trend is very much, as with the matrix programs, towards creating
one all-singing all-dancing interactive analysis program. Thirdly a new program
SATALL has been created which brings together SATASS and SATSIM; see
Section H.7.
The documentation has been updated to reflect these changes and, where
appropriate, new document references are given in the following notes.

1) Certain operations now use mouse controls, for the moment in P1X only.
See H.8.1 below for specific details and Section 9.1.7 for general principles.
2) Equally data in some circumstances may be defined using a screen editing
or window-style environment, in particular within P1X, SATDB, MX and
SATED. Notes under these specific programs give details. A more general
description of the principles involved is given In Section 9.1.6.
3) The use of “comments” in data files has been introduced. These appear in a
number of different file formats with the common feature that a ‘*’ is used to
indicate that the text following is a comment. See Section 15.29.
In particular comments are used in:
a) Namelist input records; see appendix A, notes 13 and 14.
b) Comments may be included in KEY files by including lines with a ‘*’ in
column 1. These lines are ignored when a key file is being read but
they will appear on the screen. See Section 9.1.3.
c) Comments are allowed in GRAF.DAT.
d) All input .dat files (will eventually) allow comment lines, but for the
moment some of the more obscure data file input routines have not
been modified. Most importantly they may be used freely in network
.dat files.
4) The conventions used to define “namelist” parameters have been generally
extended to include new features such as the comments mentioned above
5109341 / Mar 13 D-14

11_2_05_App D.docx
as well as the ability to define time period-specific parameters described in

H.3 below. Appendices A and B have been revised to reflect these
changes.
5) The use of “key strokes” to choose the next option has been increased,
particularly in P1X in conjunction with the display of the available options in
the banner. Thus depressing the ‘1’ key may take you directly into option 1
as opposed to typing <enter> to obtain the menu display followed by ‘1’
<enter) to select option 1. See Section 9.1.5.
In addition key strokes - or their numerical ascii equivalents - are entered
into LOG files so that you can make use of key strokes and still have a LOG
file that can be turned into a “useable” KEY file. Equally mouse-based input
is also recorded into the log file so that interactive jobs involving both single
key strokes and mouse input may be repeated via key files. See 14.7.5.
6) As a general rule a response of Q for “quit” in most replies within interactive
programs will have the effect of returning you to the previous menu.
However it can probably never be made into a universal rule since there are
always circumstances when you are halfway through an operation and there
is no way of getting back to your starting point.
Equally when asked to define a filename a response of “quit” will also
(sometimes!) get you back to the previous menu; useful if you accidentally
get into the wrong option.
7) Extra file opening and checking options have been introduced. Thus:
♦ When opening a new file programs now check whether or not that file is
already “open”, in which case it will request another file. Previously this
resulted in a fatal error.
♦ If the file requested is not found a (Dos) directory listing is generated

with up to 16 apparently suitable filenames from the home directory.
♦ An option to automatically over-write existing output files has been

introduced (previously you were asked whether or not you wished to
overwrite that file). This makes the use of key files easier but a bit more
dangerous in that you may overwrite important files without realising.
8) Text/filenames may be defined via namelist and are passed via the UFS/A
files etc. Thus you may define the trip matrix filename when defining an
input file to SATNET so it need not be re-defined for SATASS. More
usefully if you want, for example, to do a select link analysis in SATDB or P1
the program “knows” the trip matrix it requires.
In addition a number of other “useful” filenames such as a GIS file name are
stored on .ufs files and accessed when needed.
9) All UF* files now contain a “Version indicator” which is printed out to the LP
files indicating, e.g., that this file was produced by a version 9.1 program. At
the moment this is for information only but in the future it will be used to aid
in the correct reading of out-of-date files.
5109341 / Mar 13 D-15

11_2_05_App D.docx
10) The number of multiple user classes has been increased to 32 from 10. To
accommodate the extra arrays needed in UF files a system of “extended”
Dirck Access codes has been created; see 15.21.1.
11) The interactive programs P1X and SATED now require mandatory namelist-
based parameter definition files in order to define default values for internal
parameters. For example if you want node numbers to be displayed by
default by P1X you may set a relevant program variable to 1; if it is 0 node
numbers are not displayed. Files may be saved from within the programs
once you have modified the menus to your own requirements so that from
then on the program will have been “customised” to your specifications. See
Sections 9.7.3 and 9.9.2.
12) Ascii data “sub-files” have been introduced whereby a sub-file might contain
the complete set of bus route data as normally contained with a full network
.dat file - hence a “bus sub-file”. Sub-files may be “called” from a network
file using a $INCLUDE option described in Section 15.30 within SATNET.
The use of .xy files in SATURN 8.4 is an early example of a subfile
Sub-files may be created in the usual ways with an edit program or
alternatively some may be created interactively within P1X; see 9.4.12.
13) Matrices with greater than 1,000 rows may now be read as standard without
generating a programming error, although not all programs can necessarily
handle matrices of this size. For example the standard acceptable matrix
size in MX is 600 x 600. As always larger-dimensioned programs are
available on request for those willing to part with additional licence money!
14) The conventions by which array dimensions are defined has been altered
such that multiplely-dimensioned array lengths such as (3,3000) are now
coded as (3,(3000)) in order to simplify re-setting maximum network
dimensions. This is only of interest to programmers who will no doubt be
wondering why I am so obstinate in not using “parameters” - old habits etc.
etc.
15) Both SATDB and P1X now match links which are, e.g., simulation in one
network but buffer in another or vice-versa. Thus if you convert a buffer
network into simulation it is now possible to compare flows in the two
networks either graphically or in tables.
16) A series of tutorial or “how to” batch files has been set up in order to
demonstrate specific features of SATURN interactive programs. For
example, there is a How procedure to demonstrate how to obtain a Selected
Link Analysis within P1X. See 9.1.8.
D.5.2 GIS Files

The functions and contents of SATURN GIS files have been considerably
extended within SATURN 9.1, as have the number of programs which can make
use of the data contained within.
In particular data contained in GIS files are now used by both network- and matrix-
based programs and the name of the GIS file associated with either a network or
trip matrix is now stored on the ufs/ufm files so that, if required, the correct GIS file
5109341 / Mar 13 D-16

11_2_05_App D.docx
can be opened and accessed when and as required. Thus, for example,
SATLOOK now has access to the link and node name information held on GIS
files and prints this information out as appropriate. To enable this to happen new
(character) parameters GISFIL have been added to the Namelist parameters read
from .dat files by SATNET, M1 and MX. See Sections 6.3.4 and 10.2.3.
Data encoded within GIS files has been extended to include the following:
♦ Node, zone and/or sector alphanumeric names;
♦ Link names.
♦ Co-ordinates for links which are “curved” as opposed to straight lines. (See
section 9.4.2.7)
♦ X,Y co-ordinate data (identical to that input to SATNET)

Unfortunately it has been necessary to modify the GIS file formats from those
previously set up under SATURN 8.4 to accommodate the new features. Full
specifications are given in Appendix Z. It is however possible to re-format old files
with a bit of programming or clever use of spreadsheets; Mike Hall or Dirck Van
Vliet can advise.
It should also be noted that GIS files may now be set up relatively painlessly using
mouse controls within P1X; see 9.4.6.2.
D.5.3 Time Period Modelling - PASSQ Options

The facilities which allow SATURN to carry out “quasi-dynamic” assignment, the
use of PASSQ and linked time periods, have been considerably simplified by the
introduction firstly of “.ps” files and secondly by the option to define data for
several time periods within a single network data file. These options are
described in Sections 15.2.3 through 15.2.6.
The ultimate objective is to make it as convenient to run and to analyse linked
time periods as it is to run and analyse static or single time period networks.
However certain programs (see SATSUMA in 15.2.6) are still not completed so
that full facilities will be included in SATURN 9.2.
D.5.4 SATNET
1) Default speed-flow curves as identified by the capacity index may be defined
within the 3333 buffer network data. This facility removes the need to code
speeds and capacities more than once for similar buffer links. See Section
15.9.4.
2) Capacity indices for simulation links may be included on the mid-link
capacity restraint records. See Section 6.4.1. They may also be used in
conjunction with the default speed-flow curves coded under the 333 records
to define simulation mid-link speed-flow or capacity-restraint data. See the
specification for Record Type 2B in Section 6.4.1 plus Sections 6.4.12 and
15.9.4.
3) The “SHANDY” option allows input link distances to be checked against
crow-fly distances calculated from node co-ordinates and zero-coded
5109341 / Mar 13 D-17

11_2_05_App D.docx
distances to be replaced by crow-fly distances. See 15.10. This option

applies both to buffer links and simulation links.
4) Comment cards are now permitted throughout the input .dat files following
the convention that a ‘*’ in column 1 denotes a comment card; see Section
15.29.
5) The logic by which the terminating ‘99999’ records are detected has been
“improved” so it is possible that certain existing files will no longer be
correctly interpreted. Thus a 9 in column 1 followed by blanks is a valid
99999 record. This avoids problems under the DUTCH options whereby
node numbers > 99999 could lead to confusion.
6) Simulation centroid connectors may now be defined as going to a single
node, although this will be interpreted as a set of links either to or from that
node. See the notes added to Section 6.5.
7) Coding bus route has been made considerably simpler by removing the
need to specify the “number of nodes” entry and by allowing free format
entries of the node numbers (i.e., the nodes need not be in fixed columns).
This option is controlled by setting a parameter ‘EZBUS’ to .TRUE. See
Note 4, Section 6.9
8) An $INCLUDE option in the input .dat files switches input to a sub-file within
the 44444, 55555, 66666 or 777777 data records. See Section 15.30.
9) The formats used to define X,Y co-ordinates on the 55555 data records may
now be user defined via a parameter XYFORM - see Section 6.3.4 and note
(7) under 6.8. This option is very useful for networks whose X,Y values are
taken directly from Ordinance Survey data bases whose “standard” widths
exceed 5 digits or are most easily expressed with a decimal.
10) Extra information/messages is now included in the summary table of errors
using text contained in the file SATTIT.DAT. Thus if, say, error 115 has
occurred 26 times a message will appear saying that error 115 is caused by
“making bad jokes” or whatever so that users will not need to search through
the lp file to find out what 115 is all about.
11) The name of the .UFS file being updated may be set within an input .DAT
file as an alternative to setting it within the call to the bat file or procedure.
See 6.1.
Equally the filenames of the trip matrix and GIS file associated with the
network may be defined under &PARAM. The names of these files are then
carried forward within the .ufs file structure so that they may be
automatically opened and used by later programs as required. See Section
6.3.4.
12) A new parameter DEFCAP sets the default road capacity per link on out-
bound external simulation links. This has no effect on simulation results or
delay calculations but may effect graphical listings of capacities or V/C
ratios. See parameter DEFCAP in Section 6.3.3.
5109341 / Mar 13 D-18

11_2_05_App D.docx
13) Under certain circumstances the output binary file from SATNET is now
given an extension .UFN rather than .UFS so as to avoid confusion with the
output files from SATALL and/or SATURN.
14) Bus names may now be “alpha-numeric” as opposed to pure numbers as
previously. This means that the manner in which they are referenced, e.g.,
in P1X, has changed in that they are now referred to by their SEQUENTIAL
number.
15) An “informative title” may be included after the 77777 record (but on the
same line) to give a title for, .e.g., the set of screenline counts that follow.
However the name is not used in very many displays as of yet.
16) A new parameter NUCMIN introduced to set a lower limit on permitted
values of NUC. See 6.3.2.
17) A new parameter BUSKER allows a complete set of bus route data with
every node included to be output to a “network.bus” file.
18) Bus route names are now stored as “alpha-numeric” rather than as pure
numbers. Existing dat files are still acceptable; the differences only become
evident in the way in which bus routes are selected, e.g., in P1X. See 6.9.
D.5.5 SATEASY and SATASS

SATEASY and SATASS continue to co-exist in 9.1 with virtually all of the
functions of SATASS now contained in SATEASY (with the exception of PIJA
calculation). The intention is to phase out SATASS as quickly as possible and
replace it by SATEASY (although the program name may revert to SATASS for
continuity). Some of the changes noted below refer to only one program; if not so
noted they apply to both.
1) Output statistics from the assignment now have a higher level of
disaggregation by, for example, capacity index.
2) A parameter has been included (SEED) which, if FALSE, excludes the
calculation of PIJA’s if the corresponding element Tij in the trip matrix equals
0. This can result in considerably smaller UFP files (which can be HUGE!)
and reduced cpu time to run SATME2. See Section 7.6.2. (SATASS only)
3) A check is included that the zone names on the trip matrix file are identical
to the zone names on the network file; if not a warning message is given.
4) A list of the 10 worst converged links between assignment and simulation is
now given in line printer output as an extra indication of where any lack of
convergence between simulation and assignment is based. (SATEASY
only)
5) The batch procedure SATURN has been modified such that, for pure buffer
networks, the final output file is now a .UFS file, not .UFA so as to be similar
to the output from a simulation network. The “intermediate” file output by
SATNET is renamed as “.UFN”.
6) Elastic options in SATEASY calculate an approximate elasticity for the trip
matrix as a whole and print warning messages if the values get too large.
5109341 / Mar 13 D-19

11_2_05_App D.docx
D.5.6 SATSIM
1) Fuel consumption statistics per simulation link as calculated within SATSIM
are now stored as a Dirck Access array 1503 in UF* files in units of total
litres within the time period.
Equally the numbers of primary and secondary stops per turning movement
are stored as arrays 1523 and 1533, and the mean simulation link delay in
seconds per pcu is stored as array 1513.
Thus all 4 are now available for, e.g., graphical display within P1X or for
manipulation within SATDB.
2) Output simulation statistics explicitly differentiate between totals which are
accumulated WITHIN the time period simulated and those which occur in the
next time period due to queues at over-capacity junctions. These are stored
within the UFS files so that the same data may also be displayed by
SATLOOK. See Section 15.1.4.
D.5.7 SATALL
The new program SATALL in effect combines the programs SATEASY and
SATSIM into a single program as well as carrying out a full convergence loop
between the two. Thus the output file contains both converged assigned flows
By combining two programs into one SATALL should be both faster and,
ultimately, “more clever” in terms of the steps that can be automatically introduced
in order to improve the rates of convergence. However at the time of writing
SATALL simply follows the simple logic of the SATASS/SATSIM loops.
Documentation is contained in Section 18.
1) SATALL features better screen report formats, including loop convergence
statistics from the assignment-simulation loop as well as convergence
statistics from each procedure individually in a format that does not “scroll
off” the screen before you can read it.
2) It also requires an input file (from SATNET) with extension UFN rather than
UFS and outputs a final file with standard extension UFS even if the network
is pure buffer. (N.B. The renaming of the output file from SATNET from
.UFS to .UFN is taken care of within the bat procedure.)
3) Convergence statistics comparing simulation totals between successive
simulations are included within the SATALL line printer output and provides
another method for gauging the overall convergence of the assignment-
simulation loops.
4) The statistics for comparing flows between successive assignments (in
addition to “ISTOP”) now include a mean GEH statistic, relative mean
absolute difference and relative standard deviation. The GEH statistic also
appears in the new screen report mentioned under 1 above.
5109341 / Mar 13 D-20

11_2_05_App D.docx
D.5.8 P1X
1) A large number of input and/or choice operations may now be executed via
the use of a mouse (see Section 9.1.7). In general these are entered
through the key stroke M following a standard network plot; subsequent
choices are indicated by the menu in the banner. In particular the mouse
may be used to:
a) change XY co-ordinates
b) re-define the window
c) define a cordon (and produce a control file for SATCH)
d) select nodes for graphical display
e) request select link re-assignment
f) define bus routes (for output to a file)
g) define joy rides
h) define counts (for output to a file)
i) display trees, forests, etc.
j) create/edit GIS files
k) request link or node based information for display in the banner.
Further information on these options is best obtained by direct
experimentation; some help menus are being prepared but if they are not
available, please be patient!
Note that option M is only displayed if the mouse option is “activated” within
the system/device menu (option 15); the default setting on/off is controlled
by a parameter set within P1X0.DAT which may be customised by users.
2) The manner in which annotated link data is handled has been brought into
line with the concept of a data base as used in SATDB with the
consequence that the majority of options from SATDB are now included in
P1X. Hence P1X and SATDB have been effectively merged.
For example data may be viewed in a tabular format on the screen or
dumped to the line printer file, statistical tests may be carried out, etc.
Link annotation data, as selected from a menu, may now either be stored in
the “permanent” data base or, under a “pick and plot” option, it may appear
directly in a plot without being permanently saved. This saves a good deal
of time if you are simply “browsing” through the data by reducing the number
of instructions necessary to get data up on the screen. In addition, if you
are happy with the data, you may ask to have it permanently stored in the
data base.
3) In a similar manner the “node graphics within P1” options have been
extended such that many of the options within SATED may now be
accessed from P1X. For example you may now “edit” simulation nodes from
5109341 / Mar 13 D-21

11_2_05_App D.docx
within P1X, although for the moment this may only be done on an
“experimental” basis - options to permanently save changes will be added as
time permits.
4) More options now use data stored on the GIS files in addition to there being
a greater variety of data on the GIS files themselves; see H.2 above. Thus
P1X can now display:
alphanumeric names for links
node names
curved roads
more “IKONS”: Church, car park and hospital
5) Options have been added to update existing network .dat files by adding, via
the mouse, new bus flows and/or new count data. Thus P1X complements
the use of SATED to update the simulation network data within a .dat file.
The intention is that eventually a single graphics-based program will be able
to update/create all sections of a network .dat file working solely with mouse
and/or screen editing facilities. Equally a .gis file may be updated or created
from scratch; see 9.4.6.2.
6) Sub-files containing bus, count and xy data may be created directly within
P1X.
7) A wider range of node data, e.g. V/C ratios, is available within network
plotting.
8) An “overlay” option has been added within the tree menus such that
successive trees appear superimposed upon the same plot with each tree
appearing in a different colour.
9) Desire lines for matrices may be plotted, i.e., lines directly linking an origin
and destination whose width is proportional to the trip matrix element.
Options also exists to direct the line via an intermediate point so that a trip
matrix representing trips through an interview station will actually pass
through that point. Enter the matrix option menu for further explanation.
10) When matrices are displayed it is possible to “filter out”, say, rows/columns
with very low values to avoid “cluttering up” the display.
11) Stacked matrices may be displayed (but only a single level can be selected
at a time).
12) A number of additional methods to highlight “selected” links have been
added, largely replacing the use of “zig-zag” lines by solid in-filled bands.
13) Similarly the width and/or colour of a link may 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.
14) Data annotation may be requested only on selected links.
5109341 / Mar 13 D-22

11_2_05_App D.docx
15) Data from two networks could previously only be annotated by, e.g., 2/1
ratios; now they may also be annotated “in reverse” as 1/2, etc.
16) More options have been added in order to “force” annotation to appear.
17) Mid-link capacity has been added to the list of “standard” data items such
that information on such links may be more easily obtained.
18) A further standard data entry is the difference in link flows between
successive assignments (runs of SATASS) plotted as a GEH error statistic.
This allows the user to help to identify those sections of the network where
the SATASS/SATSIM convergence is poor.
19) Numerically annotated link data, as well as appearing as numbers parallel to
the link, may now also appear “horizontally” within “data boxes” which are
joined to the centre of a link by a “twig”. This removes some of the problems
associated with poor resolution of numbers on the screen when written at an
angle.
20) Demand/accept flows are now distinct options for annotation to avoid the
previous confusion.
21) Simulation link arrays may be selected for annotation using their DA code,
not just assignment links.
22) The mouse-based cordon selection may also be used to blank off selected
areas; e.g., mouse cordon.
23) Plots may be overlaid by grid lines, either at fixed intervals or a fixed number
per side
24) Plot titles may now be up to 76 characters long (the previous limit was 40).
25) The default parameter file P1X0.DAT has been set up in order to allow users
to “customise” default options; see 9.4.10.
26) A parameter in P1X0.DAT determines whether or not you start with a full
network plot or go straight into the first menu.
27) As a consequence of the new methods for handling annotated data the two
scratch files 3 and 4 are no longer used; non-programmers will notice no
difference whatsoever!
28) A simple option to reverse the selection has been included; e.g., if you select
all links above 500 pcu/hr you can “toggle” to those below.
29) Turn-based data held in the (SATDB) data base may be displayed either as
“turn data” within a network plot or as part of the node graphics.
30) Nodes to be annotated may be selected by their node type; e.g., traffic
signals only.
31) An option to obtain scatterplots of one variable data column in the data base
against another (e.g., modelled flows versus counts) may be obtained
through the STATISTICAL ANALYSIS options shared with SATDB.
5109341 / Mar 13 D-23

11_2_05_App D.docx
D.5.9 SATED
The role of SATED has changed significantly. Originally it was very much a
program that could only be run AFTER a full run of SATURN in order to
experiment with alternative simulation node definitions. Gradually options were
introduced so that the experimental changes could be stored in either the UFS
files or (partial) network data files.
The latter function has been extended so that SATED may now be used
essentially as a SATURN-specific editor to prepare network data files prior to
input to SATNET. This is done via a series of screen-editing window-based
options in which correctly formatted node data files may be created on-line or
existing data files may be edited. Both functions are entered via option 5 in the
master menu. It is hoped that this function will be of great use to users who have
to prepare simulation node data for a large network.
More specific changes include the following:
1) A bug in previous versions whereby simulation link speed-flow data was not
output by SATED has been corrected and full facilities to set and/or edit
such data are included.
2) If a distance is changed for a link (A,B) it is also changed by default for (B,A)
3) Simulation node co-ordinates may be set/altered within SATED.
4) An option has been added to allow the user to automatically loop over all
entry links at a node/all turns from a link when in “edit mode”.
5) A default parameter file SATED0.DAT is required in order to allow users to
“customise” any default parameters.
6) The master menu now offers explicit sub-menus for both Files and
Parameters.
7) Three new options have been added for signal optimisation (although the
three new ones are basically research only and should probably be avoided)
and maximum stage lengths may be specified (in addition to minima) for the
“standard” option. In addition the choices are now made within a menu.
D.5.10 Graphics (SATED and P1X)

1) Node graphics plots may now (optionally) include a title and the banner may
be excluded (as in network plots).
2) Hard copy graphics devices which do not allow “in-fill” options, i.e., pen
plotters, now are programmed with a fairly crude in-fill option using closely
spaced lines.
3) An option has been included within the screen/device graphics menu
(accessible from both P1X and SATED) to allow an existing .pcx file to be
read in and therefore displayed on the screen. See 9.4.7.
4) Output to HP laser jet devices is now (we think!) possible; see GRAF.DAT
for documentation on how to set appropriate data in GRAF.DAT.
5109341 / Mar 13 D-24

11_2_05_App D.docx
5) Up to 20 separate devices may not be listed in GRAF.DAT.
D.5.11 SATDB
1) A major change is to introduce a screen--edit function within the “view data
on the screen” option, thus allowing users to change data within SATDB
rather than having to export it to a different program, e.g., a spreadsheet or
editor.
2) 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 turn delays
to produce a total link delay, or divide link flow between its turns. This opens
up a range of operations which previously could only be done by
“programming”.
3) An option has been introduced to automatically loop over multiple user
classes within selected link assignment.
4) Multiple data columns may now be read from input .dat files instead of just a
single data entry with the data read in free format; see 9.8.3.
5) Non-defined links under miscellaneous input may now be set to a default
value, e.g., 0, instead of being assigned missing values.
6) Alphanumeric link names from a GIS file may be set up as a “data column”
in the link data base.
7) Option 8 under the Assignment/Tree Build option calculates turning volumes
at buffer nodes, stores them (not very usefully) in the data base and (more
usefully) prints turn matrices at selected nodes or for all nodes to the line
printer.
8) This option does not “sit very comfortably” within SATDB so that it will
reappear elsewhere in due course.
9) Both counts and the associated count set number may be read in
simultaneously.
10) Statistical analysis may be disaggregated BY values in another data column,
e.g., disaggregated by capacity index or by count set number.
D.5.12 SATLOOK
1) Options have been introduced to allow users to skim generalised costs in
cost units as opposed to effectively forcing them to appear in units of
generalised time as previously.
2) Skimming “forests” as opposed to skimming “trees” is now allowed; see
Section 15.27 for a full description. This is now option 9 so that the old
option 9, the very early version of SATDB, no longer exists. Any facilities
there are now much be more easily handled within SATDB itself.
D.5.13 MX
5109341 / Mar 13 D-25

11_2_05_App D.docx
MX has been greatly extended under 9.1 so that not only does it incorporate a
number of entirely new functions, it also includes virtually all of the functions
previously carried out by the individual programs M1 to M7. Thus, although the
latter programs are still included within SATURN 9.1, they are only there to
provide continuity and users are advised to migrate to MX whenever feasible. It is
intended, at a later stage, to produce a set of “M1 etc emulation” bat files which
have the same format as the current M1, M2, etc, bat files but will actually work by
calling MX with a relevant key file.
1) A screen-edit/window option to interactively change data is now included as
a sub-option available from within the “display on the screen” option. In
addition to editing an existing matrix on a cell-by-cell basis this also means
that you can create a matrix entirely “on screen” without first producing a
correctly formatted .dat file. This should be of great benefit to users
producing either small matrices from scratch or making minor changes to
larger existing matrices.
2) The internal matrix file within MX may now be built directly from an input .dat
file, not just .from ufm files. This enables MX to perform the essential
operation, previously only handled within M1, of creating a .ufm file from a
.dat file. In addition a wider range of input data formats can be handled,
thus making the job of accessing matrix data from other suites potentially
easier.
Alternatively a “flat” matrix can be created with equal values in each cell as
a starting point.
3) MX now can dump output ASCII files in the form: I J Tij with one record for
each non-zero matrix element. The same format is also allowed for input.
The precise format may be user-set. This should improve transferability of
data between SATURN and other similar suites of programs.
4) Row and column totals are now included as the last row/column in ij print-
outs.
5) Any screen listing of matrix elements now goes to the line printer file as well
as to the terminal.
6) MX now reads from a GIS file associated with the matrix. In particular
alpha-numeric zone names are read from an input GIS file and these are
included in the print out of row and column totals.
7) New trip ends for matrix furnessing may now be set up using a screen edit
or window-style input format.
8) A new unified format has been created for the input .dat files used in M6
matrix furnessing to define new trip ends; see Section 10.9.4.2. This
includes, e.g., both definitions of row and column totals directly plus row and
column changes; previously different sorts of information were contained in
distinct files. Equally an option has been created which outputs trip end
totals in the same “standard” file formats.
9) The STACK and UNSTAK options from M1 have been included in MX under
option 15 from the Master Menu.
5109341 / Mar 13 D-26

11_2_05_App D.docx
10) The functions to compress and/or re-code matrices as previously provided

by programs M3/M4/M5 are now included under the ufm output options. In
each case an input .dat file must be prepared which follows with minor
exceptions the control files previously used by M3/M4/M5. Format
specifications are given in Section 10.9.4.
11) Trip length distribution option (from M1) is included as an option under
“STATISTICS” from the Master Menu.
12) Most print formats have been adjusted to allow for 5-digit zone numbers -
although their use is not particularly recommended as it leads to
complications elsewhere.
5109341 / Mar 13 D-27

11_2_05_App D.docx

SATURN 9.2, first released in May 1995, contains a number of minor changes
from 9.1, mostly in graphics and mouse-based facilities, but at the same time is
part of a continuous development. Thus the basic structure of both the network
and matrix ASCII data input files and of the various binary UF files is essentially
unchanged and files created under 9.1 or before should still be compatible with
9.2 (although the converse is not true - files created under 9.2 will almost
certainly not run with earlier programs.)
The exact order of inputs in “key” files is likely to have changed.
The following sub-sections describe, firstly, general new features of 9.2, followed
by a description of new programs included in 9.2 for the first time and concluded
by a note of changes to individual programs.
As with all new software releases there is always a greater chance of bugs
appearing in new components than old. Most of the new features listed below
have been adequately tested and many of course are relatively simple such that
either they work or don't work. However others have either only been introduced
very recently or are the sort of code that, from painful experience, works 99.99%
of the time but fail under very specific or unusual circumstances. Bugs in the
latter category may take years to emerge.
Therefore new features which we feel may be somewhat “dubious” are indicated
by the symbol ⊗ below. This is not to say that we do not recommend their use,
indeed we would positively encourage users to try them and to alert us to any
problems that arise.
References are made to sections in the Documentation where full details may be
found.

1) Missing or “unfindable” control and help files no longer generate fatal errors
but only non-fatal errors. In the event of a missing control file all default
values are taken (as would normally result if the control file were simply a
“dummy” file).
2) Generally speaking these errors occur when the files exist in a sub-directory
where, for one reason or another, the program does not search “rights” so
that the solution may be to change an “APPEND” or equivalent definition.
3) The contents of the essential file SATKEY.DAT has been extended so that
certain universal parameters applicable to all programs may be user set, for
example the number of lines on the VDU screen or a pathname “prefix” for
help files which may also help solve problems in locating help files stored in
standard directories. See Appendix Y.
4) HELP files are now set up as “direct access files” which gives the advantage
of considerably faster access. It does however mean that the .hlp files from
earlier versions are no longer valid (since they are not direct access) and
that the current versions occupy more memory.
5109341 / Mar 13 D-28

11_2_05_App D.docx
In addition if you wish to modify any help files for local conditions you must
ensure that the edited file is a correctly formatted direct access file. A DBOS
facility, MAKEDA77, is included on your DBOS disc - type MAKEDA77 and
follow instructions.
See Section 9.1.2.
5) Fuel consumption equation coefficients may now be user set via namelist
parameters input to SATNET, see 15.32.
6) Bat files MXM1, MXM2, etc. duplicate the original functions of M1, M2 etc
but use MX - see 10.1.5.
7) In order to provide compatibility between runs of 9.2 and previous runs a
logical variable PRE92 is introduced. If TRUE this “de-activates” a number
of new features introduced in SATURN 9.2, e.g., any new checks on
recently discovered potential bugs.
Note that this does not guarantee that you will get 100% strict agreement
with previous runs (and equally the results might well not differ even with
PRE92 = FALSE); the use of new compilers and/or new machines also has
an effect.
This is intended to become a standard feature with each new release. Thus
a PRE93 parameter in 9.3 will similarly de-activate any new code in version
9.3 when released.
8) An option to automatically optimise green times at all signalised junctions
has been introduced into SATED to complement SATOFF which optimises
offsets. This is a much requested feature, but one which should be used
with caution as its repeated use may well give unrealistic results. See
15.31. Try HOW6.
9) The number of “HOW” tutorial files has been extended; users are strongly
encouraged to try it out! Type “HOW”. See 9.1.8. Where specific HOW
files have been created in order to demonstrate near features of 9.2 these
are indicated below.
10) Extremely rough ‘n’ ready estimations of standard emissions - CO, CO2,
NOX, hydrocarbons and lead - are now provided; see 15.33.
11) Standard pc versions are now compiled under version 3.0 of Salford FTN77
and also user version 3.0 of DBOS. You will therefore need to install the
new version of DBOS.
12) The format of GRAF.DAT has changed (although old versions are still
compatible) and a new option to allow “proper” infilling on devices such as
laser printers has been included. See GRAF.DAT itself for details.
D.6.2 New Programs
SATPIJA + SATME3
SATPIJA is a new program which produces a UFP file from an existing UFS (or
UFA) file created with SAVEIT = T. It therefore duplicates the role of SATASS
5109341 / Mar 13 D-29

11_2_05_App D.docx
and (see I.4 below) means that all functions of SATASS are now carried out by
either SATEASY or SATPIJA (plus other functions of course).
However the exact form of the new UFP files differs from those produced by
SATASS; hence an upgraded version of SATME2, called SATME3, is provided to
be used in conjunction with SATPIJA. Otherwise SATME2 and SATME3 are
indistinguishable.
See 11.7 for a full description of both programs.
SATSUMA
SATSUMA combines together a series of .ufs files from successive time periods
run using the PASSQ option in order to produce a new form of UF file, a .uft file, in
which, for example, the flow record gives a suitably averaged flow, the summary
totals add together each time period without double counting any effects due to
vehicles queued at the end of one time period, etc.
It is hoped that this program, along with the easier options for running multiple
time periods introduced in 9.1, will make applications of PASSQ far more user
friendly, and that a quasi-dynamic version of SATURN will more accurately reflect
some of the detailed behaviour of time-varying flows in peak periods. See 15.2.6.
SATNET
1) An increased range of namelist parameters has been provided, most of
which are “carried forward” and used in later programs. These include:
♦ Elastic assignment parameters MCGILL, etc; see 6.3
♦ PCNEAR; see 8.7.1.
♦ Wardrop assignment stopping criteria UNCRTS, XFSTOP and FISTOP;

see 13.5.1.
♦ Fuel consumption coefficients; see 15.32
♦ PARTAN; see 13.5.7.
♦ PRE92; see I.1 above
♦ SIGOPT; see 15.31.
♦ ERTM; see 6.3.1.
♦ WINDY; see 6.3.1.
♦ Emission coefficients; see 15.33.

Additional file names may be defined under namelist including (see 6.3.4): CIJFIL,
a file name for the cost matrix used under elastic assignment
D.6.3 Assignment Programs

1) The old assignment program SATASS has now been virtually totally
replaced by SATEASY which carries out all the functions of SATASS apart
5109341 / Mar 13 D-30

11_2_05_App D.docx
from PIJA analysis which is now handled by SATPIJA (see I.2 above). Thus
the 9.2 SATURN bat file calls SATEASY rather than SATASS.
2) All elastic equilibrium parameters such as MCGILL may now be defined
within SATNET and transferred via the .ufs files through to SATEASY
including a character variable CIJFIL that pre-defines the cost matrix file
name (see I.3 above).
3) The stopping criteria for Wardrop equilibrium may now be user set; see
10.1.5.
4) A new parameter ASHORT has been introduced in order to optionally
replace the assignment statistics listed at length within the output line printer
file by a much briefer summary table at the end. See 6.3.1.
5) A logical option, ERTM, to allow negative T ij’ to be assigned has been
created but is definitely not recommended; see 6.3.1.
D.6.4 Simulation Programs

1) Link delays (i.e. on links with speed-flow curves defined) are included as a
separate component in output statistics.
2) Upper limits have been introduced on the delays both within the time period
simulated (MAXDTP) and to permanently queued traffic at the end of the
time period (MAXQCT); see 8.4.1.
3) Bat files produce different messages for assignment/simulation iterations
which “converge” (i.e. satisfy ISTOP) and those that are “terminated” on
maximum iterations.
4) A number of changes have been made to the way in which delays are
calculated at simulation turns. Some, mostly minor (see I.12), are related to
delays at zero or near zero flows and will have little practical effect. Others
relate to give way turns sharing lanes with non give-ways and may be more
substantial.
Preliminary results suggest that these changes may improve the convergence of
simulation-assignment loops in previously badly behaved networks, but on
SATURN it is notoriously difficult to generalise.
These changes may, if desired, be de-activated with the PRE92 parameter - see
note 6 in I.1.
D.6.5 SATALL
1) The length of the LP output file may be significantly reduced by making use
of summary tables for assignment statistics by iteration via the new
parameter ASHORT described above.
2) By setting a parameter SIGOPT = T it is now possible to automatically
optimise signal stage green times once within each simulation. This is still
very much an experimental research-only facility but it is available; see
15.31.
5109341 / Mar 13 D-31

11_2_05_App D.docx
3) The convergence measure of “flows within 5% of their previous value” has

been changed such that the 5% is now a user-set parameter PCNEAR; see
8.7.1 and 6.3.3.
4) New convergence statistics have been added to the window displays; see
18.4.
D.6.6 SATED
1) Nodes may be edited using full graphical display and with instructions in the
banner, in particular signal stages may be so defined and stage inserts
appear as they are created.
2) A choice of stage length signal optimisation algorithms is now available; see
15.31.
D.6.7 SATDB
A preferences file SATDB0.DAT has been introduced; see 9.1.9.
D.6.8 P1X
1) The way in which GIS files may be either created or extended has been
made more “random access” in that the various sub-sections may be
amended in any order or more than once. The banner display has been
generally improved as well.
2) Options to cancel all current link annotation added.
3) There is a new facility to store/recall former window definitions including the
previous window definition; see 9.4.2.1. It is planned to extend this facility
such that useful window definitions, once created, can be permanently
stored, e.g. as part of the preferences file.
4) There have been minor changes in GIS file definitions:
♦ Add a zone number plus title to polygons
♦ Line widths can be in units of “metres on the ground”
♦ See Blocks 1 and 2, Appendix Z.

5) An “Information” option has been included within the mouse-based options
in order to obtain detailed information listed within the banner on either
nodes, links or zones. Try HOW5.
6) Scattergrams of, e.g., flows vrs counts are available through the statistics
sub-menu of the database options. Try HOW4.
7) Histograms of matrix frequencies and trip length distributions are available
via the matrix display options. Try HOW7.
8) A “node selection” menu has been added which allows, for example, node
data to be displayed only at signalised junctions. Try HOW8.
5109341 / Mar 13 D-32

11_2_05_App D.docx
9) A limited number of options from SATLOOK are now available via an option
(27) within the main text-based menu.
10) An option to output an updated .ufs file which can include modifications to
simulation nodes introduced via the node graphics has been introduced.
(Previously you could “edit” nodes but could not “save” the results.)
11) An option to issue a “DOS” command from within the graphics
system/device menu allows you to, e.g., print files without exiting from P1X.
12) An explicit left-hand margin has been added for better printing for bound
reports (within the General Display Menu).
13) Output devices may be connected via ports COM1 to COM4 or LPT1 to
LPT4 (within the System/Device Menu).
14) Rectangular plots may be “centred” within the plot so that the full
height/width is available for the banner.
D.6.9 MX
1) The options available to either dump .UFM files into ASCII files with user-set
formats, or equivalently to read matrix input from ASCII files in non-SATURN
format have been considerably extended. See 10.9.4.7.
2) Row/column sums may be disaggregated by level for stacked matrices.
3) A preferences file MX0.DAT has been introduced; see 9.1.9.
4) A new bat file, MXX.BAT, has been created with an easier format for
multiple matrix input. Type MXX for information.
D.6.10 SATLOOK
1) Both assignment and simulation summary totals are optionally printed in
both “F” and “E” formats, where E-formats are particularly useful for very
small numbers which tend to otherwise be printed as 0.00 or very big
numbers which appear as *****.
2) When producing cost or skimmed matrices from multiple user class
networks it is now possible to produce stacked matrices directly with one
level per user class. Useful for input to elastic multiple user class
assignment using SATEASY.
5109341 / Mar 13 D-33

11_2_05_App D.docx
D.6.11 BUGS
A number of “bugs” have been detected in the calculation of simulation delays in
SATURN 9.1 and, by implication, in earlier versions. These range from the
correction of extreme anomalies with few practical implications to what could most
accurately be described as “silly errors”, particularly with respect to give way
turns, which, under the most unfavourable conditions, can give quite significant
changes in calculated delays. Overall, however, differences in, say, total
simulated vehicle-hours between SATURN 9.2 and earlier versions are, generally
speaking, not large.
One example of “anomalous delays” occurred at signals with shared lanes and
zero or extremely small flows (e.g. 0.00001 vph) with reported delays of 5 or 6
figures. Since the product of flow and delay was either zero or near zero this had
no effect on summary statistics, but still looked fairly dubious.
One positive result of the “tightening up” of delay calculations within the simulation
is that the overall level of assignment - simulation convergence can be improved.
Further information is given in I.5.
D.6.12 DOCUMENTATION
In addition to minor alterations throughout and new sections noted above the
following sections and/or sub-sections have been added:
9.1.9 Preferences Files
10.9.4.7 Non-Standard MX Data Input
11.1.5 Convergence of Matrix Estimation and Assignment
13.1.5 Stopping and/or Convergence Criteria for Wardrop Equilibrium
13.2.5 The Convergence of Stochastic Assignment
13.5.7 Partan Assignment
14.7.4 Comments in Key Files
14.7.5 Ascii Keys and Mouse Commands within Key Files
15.1.4 Network-based Simulation Summary Statistics
15.27 Skimming Trees and/or Forests
As always readers of the hard copy, word processed documentation need to be
aware that, since these are only released at intervals, the ASCII documentation
files supplied on disk with the .exe files may well be more up to date. In case of
discrepancies between the two believe the ASCII files!
5109341 / Mar 13 D-34

11_2_05_App D.docx

SATURN 9.3, first released in September 1996, contains a number of major
changes from 9.2, in particular within SATALL and P1X. However the basic
structure of both the network and matrix ASCII data input files and of the
various binary UF files is essentially unchanged and files created under 9.2 or
before should still be compatible with 9.3 (although the converse is not true - files
created under 9.3 will almost certainly not run with earlier programs.) The exact
order of inputs in “key” files is likely to have changed.
The following sub-sections describe, firstly, general new features of 9.3, next a
description of new programs included in 9.3 for the first time and finally notes of
changes to individual programs.
References are made to sections in the (latest) Documentation where full details
may be found.

1) Under DOS the .exe and .bat files have been restructured such that it
becomes easier for programs to “find” files in other sub-directories or, if they
are not in the sub-directory where they should be, in another obvious sub-
directory, e.g. your home directory. In part this is done by storing full
“pathnames” in addition to “filenames” in the .ufs files. Thus if you ran
SATURN on a file “network.dat” in sub-directory C:\SATURN\WORK the
resulting .ufs would store both network.dat and
C:\SATURN\WORK\network.dat. If you later copied network.ufs to a
different sub-directory or even changed its name programs should still be
able to locate its original .dat file.
2) The “$INCLUDE option” may now be used within Namelist; see Appendix A,
Note 16.
3) A bat+key procedure SATBUF has been written which uses SATDB to
convert simulation networks into “best fit” equivalent buffer networks on a
link by link basis; see 15.8.2.
4) A new “Directory Enquiries” option using the Salford subroutine
SELECT_FILE@ for directory listing which lists the acceptable files in a
window is optionally available.
D.7.2 New Programs
SATPIG
A new program SATPIG produces a complete set of route flows output to an
ASCII file, i.e., for every route used by (positive) ij trips the number of trips
assigned plus the node-by-node definition of the route is given. This may be
used, for example, to interface SATURN with various micro-simulation packages.
See 12.6.
5109341 / Mar 13 D-35

11_2_05_App D.docx
SATNET
1) The output UF file is now always a UFN file, not UFS, and both the program
and associated bat files have been so modified.
2) All variables used under elastic assignment or simulation may now be
defined within SATNET and “carried through” as defaults. Hence the list of
variables in Section 6.3 is considerably longer. The intention is now to
minimise the use of separate control files at later stages in the
assignment/simulation loops by setting all parameters for a network with
SATNET.
3) Equally all file names which are used in subsequent programs, e.g., the cost
matrix file for elastic assignment, may now be defined as namelist
parameters in SATNET and “carried through” via the uf* files; subsequent
jobs require fewer parameters in the command line. For example, it is
possible to run an elastic assignment with a command such as “SATEASY
network” without having to specify any further file names. See 6.3.4.
4) Certain default parameter values have been changed to reflect current
usage more accurately, in particular:
5) SAVEIT (F to T), MASL (5 to 15), NITA (10 to 20), NITS (6 to 10), ISTOP (85
to 90)
6) New namelist parameters has been provided, including:
♦ MIN/MAXLSF: error checks on lane saturation flows
♦ FRED: to set an estimated trip matrix for elastic assignment, see 7.5.3;
♦ NFT: to choose old SATURN versions
♦ COMPAS: to sort exit buffer nodes into clockwise order.
♦ KERMIT: buffer distances and times are defined in units of KilometERs

and MInuTes (Obvious really and quite inevitable!)
♦ SATTIT; see note 8 below
♦ TIJMIN; lower limit on trip matrix cell values to be assigned; see 6.3.3
and note 3 at the end of Section 4.
7) The data formats used for any data input section may now be user-defined
within the .dat files themselves. For example if you wish to have co-
ordinates or link counts defined in different columns from the SATURN
standards you may do so by inserting an extra record with the required
format. See 15.35.
8) The value of MAXZN is automatically increased in line with the maximum
zone number actually coded so that, in effect, it has become a redundant
parameter.
9) The supplementary file SATTIT.DAT is no longer mandatory; if it cannot be
found then default DA titles are taken from the program. In addition a name
5109341 / Mar 13 D-36

11_2_05_App D.docx
list parameter SATTIT has been included such that if SATTIT = F the file is
not referenced at all.
10) If the trip matrix is defined within SATNET checks on its validity are carried
out in SATNET in addition to SATALL such that possible errors, e.g.
inconsistent number of zones, are picked up at an earlier stage.

The old assignment program SATASS has now been virtually superceded by
SATEASY, and SATEASY in turn by SATALL. The SATASS exe file will
continue to be supplied with 9.3 but its use is not recommended.
Within elastic assignment it is possible to specify certain Tij’s to be inelastic (i.e.
“frozen”). See 7.5.5
The use of SUZIE = T with SUET = 0.0 to do MSA for Wardrop Equilibrium has
been formalised and an extended set of convergence statistics, including delta
values, are included. See Section 7.11.8. It may be used to indicate a minimum
number of iterations for stochastic assignment. It may also be used under
multiple user classes.
Iteration costs stored under SAVEIT are now held in a separate file with a .UFC
extension instead of being included as part of the ufs file. They are also calculated
with DIDDLE = T and with elastic assignment; i.e., all the time when SAVEIT = T.
Being held on a separate file there is no longer any upper limit to the number of
iterations which can be processed in this manner (as opposed to previous
versions where there was an upper limit of 99). See 15.23.
Aggregate assignment statistics are printed out subdivided by capacity index.
Tabulated values of the objective function Z and total costs are now normally
given divided (normalised) by the total number of trips which should make them
somewhat easier to digest.

1) Blocking back occurs on centroid connectors in addition to blocking back on
upstream links. Hence the “knock-on” impacts of blocking back are far less,
particularly in situations where large centroid connector flows could totally
block a link. See 8.5. Queuing delays on links and on (blocked back)
centroid connectors are distinguished within simulation summary statistics.
See 17.8.
2) As with SATURN 9.2 (see note 4 in I.5) a number of minor changes have
been made either in the simulation or in the simulation/assignment interface
which might be described as a general “tightening up” of minor problems.
The net effect, however, has been a further significant improvement in the
convergence of the assignment/simulation loop, especially near full
convergence. If required these changes may be avoided by setting NFT =
92 (but certainly NOT recommended!).
3) A new array (DA code 1543) has been introduced which stores, for each
simulation link, the total delay in pcu-hrs experienced by traffic on that link
5109341 / Mar 13 D-37

11_2_05_App D.docx
WITHIN the time period simulated (including delays, if any, on centroid

connectors due to blocking back). It includes both transient delays plus
queuing delays (but, again, only WITHIN the time period).
4) The Weston Gap - a method for introducing flow-dependent gaps has been
included but, as it is still experimental, not yet documented. Essentially it
allows you to reduce a minimum gap of, say, 5 seconds at zero cross flow to
3 seconds if the cross flow reaches 100% capacity. If you think you would
like to try it contact DVV.
D.7.5 SATALL
SATALL is now the “standard” procedure for running simulation networks as
opposed to explicit loops over SATSIM and SATASS/SATEASY. It contains all
previously available simulation/assignment options and has been proved to be
sufficiently robust.
1) The length of the LP output file has been significantly reduced by the
inclusion of summary tables for convergence statistics.
2) A greater range of convergence statistics are now ouput, for example in line
with the latest British requirements in the Traffic Appraisal in Urban Areas
Manual; see 9.8.
3) Automatic green splits may be calculated within SATALL via the parameter
SIGOPT (and works better than before); see 15.31.4.
4) The option to run elastic MUC now works. See 9.11.
5) Turning flows at buffer nodes are now calculated and stored on the output
UFS file (if SAVEIT and REBBUF = T) where they may be printed using
SATLOOK; see J.10 and 15.36.
6) A gap function is calculated under (Wardrop) multiple user class and elastic
assignment.
7) A “hot key” to stop runs has been introduced, i.e.; typing Q terminates an
iterative run at the next simulation. See 9.7.
8) DIDDLE works under both elastic and fixed trip matrix and answers every
user's prayers for improved convergence. Trust me! See 9.4.
9) “Continuation” runs of SATALL are now possible; e.g. if you run 20
simulation/assignment loops and think you would like 25 you can run 5 extra
loops without having to re-run from scratch. See 9.7 and 9.12.
D.7.6 P1X
1) P1X has continued to swallow up large chunks of SATLOOK, SATDB and
SATED such that most of the first two programs are now available within
P1X and the node graphics in P1X already covers much of SATED. In
addition most of the cordon facilities in SATCH may also be accessed via
PIX; see 11.13.
5109341 / Mar 13 D-38

11_2_05_App D.docx
2) The facilities to either create or extend GIS files have been enhanced, for
example GIS items may be added in any order.
3) Excess travel time (i.e. delay) is accumulated and displayed on joyride
routes.
4) The control file GRAF.DAT is now optional; if not found for any reason an
internal default version is set up. See 11.3.1.
5) Banner menu choices may be made by mouse if a parameter “mini mouse”
is toggled to “maxi mouse” within the System/Device menu. See 11.1.7.
6) An “arboretum” option has been added to the tree options - basically an
arboretum is like a forest without the repetitions so it displays each distinct
route used by an O-D pair and its proportion. See 15.26.
7) An option to provide interactive bus information is available through the
Analysis Options; see 11.8.4.
8) Contour isochrones with in-filling added to the tree-build options - “a glorious
riot of colours” (The Guardian).
9) A completely new set of “edit” functions have been added; e.g. to convert
buffer nodes into simulation nodes (similar to old routines to SATED but
better). Both the .dat files and the .ufs files may be updated. See 11.9.
10) The options by which the window may be interactively set using the mouse
have been extended to allow the user:
♦ to “drag” the window
♦ to scale the window

11) An input .pcx file may be used to set the “background” to a plot so that the
SATURN plot can “over write” an existing map if desired. See 11.3.5.
12) A “union” of two networks can be created such that the links included on the
screen contain all those EITHER in network 1 OR in network 2. See
11.4.3.1.
13) Links now have a default “bandwidth” (as opposed to being just displayed as
lines), defined within the general display menu. See 11.6.4.
14) Data annotation to “curved” links - as defined using GIS data - now “follows”
the curve, not the straight line joining the two end nodes. (But only, to date,
for numerical annotation along the link, data in boxes (the “twig” goes to the
mid point of the curved link) and data in variable bandwidths.)
15) Select link analysis may now either be carried out for a single user class (for
multiple user class networks) or for all user classes combined together.
16) PCX output files and outputs to the “alternative device” may optionally
exclude the banner menu choices which automatically appear on screen.
See 11.3.5.
5109341 / Mar 13 D-39

11_2_05_App D.docx
17) Annotated link data may be “selected” by specifying upper and lower limits
for inclusion; e.g. don’t include zero’s. See 11.6.2.
18) Networks which are, e.g., long and narrow may now optionally be “centered”
within the full available screen to avoid problems with the banner being
“squeezed” along the shorter dimension of the plot so that full information is
not given. See 11.5.
D.7.7 SATDB
1) An option to selectively assign trips relative to their distance from the origin,
i.e., to differentiate cold starts, has been incorporated in SATRAP. See
15.37.
2) Turn data may be aggregated up into link data, either as a straight
summation or as a flow-weighted sum. For example, you may add up stops
per turn to obtain total stops per link.
3) The % green time per turn or link is available as standard data.
4) The option to read in miscellaneous input data from an ascii file will now (a)
read centroid connector data (in the same format used to dump it from
SATDB) and (b) not exit if it comes across any text in the file (such as
namelist data). This provides an alternative, and in some respects more
natural method, to “dump” data (using option 13) and to read it back again
(e.g., post editing) via the miscellaneous facility. See 11.10.3.
5) Four columns containing the X and Y co-ordinates of the link A-node and B-
node may be added from within the Miscellaneous Options; this is useful for
passing link data into external GIS systems.
6) Various options now facilitate replacing missing values - either in existing
columns or when created - by default numerical values, e.g. zero.
D.7.8 MX
Note that the traditional matrix manipulation programs M1 to M7 have been
relegated to the SATURN reserve side and that MX now handles everything. The
programs, however, still exist and may be obtained on request from either DVV or
Atkins.
1) There are considerably more options available to deal with stacked matrices;
e.g. printing multiple levels “inter-leaved” in a single ij cell, printing row and
column totals by level, aggregating all levels into a single internal matrix.
See 10.10.2 and 10.11
2) Limited graphics have been introduced - more to follow. See 10.12
3) Selection may now be based on “cell values” as well as “area”; see
10.6.Thus, for example, factoring may be selectively applied to ij cells based
on their current values. See 10.7.1.
4) An option to include row/column totals on every screen, not just on the
bottom/RHS screens, is introduced. See 10.10.1.
5109341 / Mar 13 D-40

11_2_05_App D.docx
5) Greater use is made of alphanumeric zone titles from GIS files.

6) Interactive options added to set matrix dimensions/units and title for an
output .ufm matrix. See 10.16
7) Row and column totals printed for several input matrices together (“inter-
leaved”). See 10.11.
8) An external .ufm matrix may be read in as its transpose or by a series of
zone re-definitions as in M3/M4/M5. See 10.4. Thus re-coding can be done
either as part of the input or as part of the output.
9) Add an option under “M5” output to allow totally new and “empty” zones to
be added into a matrix. See note 6, 10.16.3.
10) The internal matrix may be transposed internally as part of the “fortran
equation option”. See 10.8.2.
11) Text names for sectors (if defined) are used in block listings and sector 0 is
not included if it does not exist. See 10.10.5.
12) The factor options now include explicit options to factor by either row-
specific or column-specific factors. See 10.7.3.
13) The cells displayed under the “view on the screen” option may now be
“selected”; e.g., you may only display values > 10, all other cells are blank.
See 10.6.
14) A transport specific option to add two cost skims via an intermediate (e.g.
park ‘n’ ride) zone is introduced. See 10.8.4.
D.7.9 SATLOOK
1) Turning flows at buffer nodes may be displayed from within option 2, either
at individual nodes on the screen or en masse to the line printer file; see
note 4 under J.6 and 15.36.
2) Simulation summary statistics now include a breakdown into, e.g. total
vehicle hours, within the time period and beyond the time period in terminal
outputs (previously they were available in the LP file only), plus a new set of
statistics which brings together totals for the simulation network with the
equivalent totals from the buffer network. The latter provides a better single
estimate of, e.g., total vehicle hours over the whole network, than was
previously available from the assignment network summary statistics. See
17.9.
D.7.10 SATME2
While the matrix update program SATME2 has not changed significantly the
method of interfacing with SATURN has. In 9.2 a new program SATPIJA was
introduced to provide an alternative method to SATASS to create a UFP file and,
since the UFP files created by SATPIJA had a different format to those created by
SATASS, an extended version of SATME2, SATME3, was also created. Since
the new SATPIJA/SATME3 route has now been successfully validated the old
5109341 / Mar 13 D-41

11_2_05_App D.docx
SATASS/SATME2 option has been removed and, to maintain compatability with

long-standing program names, SATME3 replaces SATME2.
Full instructions are given in the (re-numbered) Section 13.
D.7.11 BUGS
A separate list of bugs in 9.2, none very serious but as ever potentially annoying,
is available and is routinely sent out via email.
In addition to minor alterations throughout and several new sub-sections covering
new features noted above several sections have been re-numbered and the old
section 7 on SATASS has been replaced by section 13 which covers SATEASY.
The documentation supplied to users on computer files is now given as WORD 6
files instead of as ascii files as was the previous convention.
D.7.13 FEATURES IN PROGRESS

Very often SATURN programs as supplied contain a number of functions which
are not fully tested and therefore undocumented, but still basically available if you
know how. The “Weston Gap”, note 4 in J.5, is a case in point. Others in 9.3
include:
1) System optimal assignment.
2) Shadow networks assignment.
3) Supplementary files defining capacity indices.
4) Blocking back based on maximum (as opposed to average) queues.
(Possibly more realistic if using PASSQ).
5) A DA array on .ufs files to explicitly record tolls under road charging tests.
6) A perturbation technique to model peak spreading under PASSQ (as
developed by KK Chin) can be applied with existing programs and key files.
If you would like more information about any of the above please contact DVV.
5109341 / Mar 13 D-42

11_2_05_App D.docx

SATURN 9.4, first released in March 1998, continues the developments made in
9.3, primarily within the interactive program PIX. New input facilities have been
introduced in SATNET and a node data base facility has been added to
SATDB/PIX to complement the existing link-based data base.
The basic structure of both the network and matrix ASCII data input files and of
the various binary UF files is essentially unchanged and files created under 9.3 or
before should still be compatible with 9.4 (although the converse is not true - files
created under 9.4 will almost certainly not run with earlier programs). The exact
order of inputs in “key” files is likely to have changed.
The following sub-sections describe general new features of 9.4 followed by notes
of changes to individual programs.
may be found.

1) All .bat files for interactive programs such as PIX allow a “preference file” to
be specified.
2) Namelist parameters may be set on the command lines of certain
programs/bat files; See 14.6.
3) In very limited cases (see 10.14) it is possible to “append” (i.e. add) data to
an existing file, e.g., in order to export data for several test runs to a
spreadsheet.
4) The “command line” used to initiate a job is now detected by the program
and recorded in the LP files; useful in determining “how” a job was set up.
D.8.2 SATNET
1) Separate sets of bus route 66666 definitions disaggregated “by company”
are allowed. 6.9.
2) A new extra input data file, the “X-file”, has been introduced which allows
link-dependent values of TAX and turn-dependent GAP values to be
defined. 6.13
3) A new class of give way movements denoted by W for weaving segments,
e.g. on motorways with slip roads, has been added. 6.4.2.5.
4) The following new parameters have been added and their functions
described in 6.3:
KINKY; 15.38
MAXLSF
QUEEN; 8.5
SATTM; 15.21
5109341 / Mar 13 D-43

11_2_05_App D.docx
SHADOW; 7.11.10
SOWHAT; 7.11.9
XFILE; 6.13
5) A “history file”, basically an extended title, may now be included in the
network.dat file and stored in the uf* files. See 6.2.

1) The technique known as “shadow networks” which is used to remove excess
demand, an alternative to the use of elastic assignment, has been
introduced and documented; see 7.11.10.
2) Equally “system optimal” assignments may now be carried out where a
system optimal assignment minimises total network travel cost as opposed
to individual driver trip cost. Its applications are more theoretical than
practical. See 7.11.9.

1) Roundabout entry capacities may now be reduced by exit flows to the same
arm using what are known as “K S factors”; see 8.7.2.
2) Link-dependent TAX values may be set; see 8.2.3.
3) An alternative blocking back rule has been introduced based on maximum
rather than average queue lengths over a link. See 8.5.
4) Several new time-based DA arrays are included in .ufs file, one
consequence being that all simulation total statistics can be calculated by
formulae involving only DA codes; see 17.11. Previously certain
calculations, e.g. queued delays in future time periods, could only be
calculated by programming.
D.8.5 SATALL
1) An option is now provided, primarily via the .bat file, to carry out one or more
continuation assignment-simulation loops to an existing .ufs file rather than
starting all over again from scratch. See 9.12.2.
2) The tricolour “window” display when the program is running now adds the
file name at the bottom of the screen.
5109341 / Mar 13 D-44

11_2_05_App D.docx
D.8.6 P1X
PIX has been extended and considerably altered in several respects. In particular
the conversion of text-based menus into banner as opposed to graphically-based
menus has been largely completed. Some text menus remain but only when they
are much more convenient in that format. The network editing options have been
extended and generally “tightened up”; more to come. In addition virtually all of
the remaining “useful” components of SATLOOK, SATDB and SATED are now
accessible from within PIX.
1) Data for turns may now be displayed as horizontal numbers within boxes
and the choice of turn data has been extended, e.g. to include GAP values.
2) Simulation links may be drawn with a finite width and the lane structure
illustrated as opposed to being simply single lines.
3) The size of the 1-way arrows may now be user set or suppressed entirely by
putting the size to zero.
4) Mouse-based selections from a banner may be over-riden using a “hot key”,
alt + a key. 11.1.2.
5) A new form of banner has been introduced, the “A-Z banner”, in both
network and node graphics plots giving full information on what the current
plot displays as both network and node graphics plots opposed to a banner
indicating choices. 11.6.9.
6) The choices listed in the banner may optionally be suppressed from outputs
to hard copy devices. 11.3.5.
7) Node-based data may be plotted as proportional “bandwidth” circles. In
addition the set of available node-based data has been considerably
increased. The options to select the nodes to be displayed have also been
extended. 11.6.5.
8) Select link analysis may be carried out on centroid connectors as well as
“real” links. 11.8.1.
9) A parameters sub-menu has been added to isochrone displays. 11.8.3.
D.8.7 SATDB
1) A variable number of decimals per output column may now be selected
under the “Housekeeping” menu.
2) A node-based data base is included in addition to the traditional link-based
and with all the standard options. See 11.10.5.
3) Selected links may be identified by a 0/1 in a new column.
4) Options to “unpack” simulation link and turn data have been added, e.g. to
allow priority markers on lane restrictions per turn to be displayed.
5) A “parameters/options” sub-menu has been added to the terminal display to
allow, e.g. lines with only missing data values or centroid connectors to be
excluded from the listings.
5109341 / Mar 13 D-45

11_2_05_App D.docx
D.8.8 MX
1) Ascii data files with “Spreadsheet-style” formats (values separated by
commas) are now available for both output and input; 10.5 and 10.15.
2) The graphical-output facilities have been extended to include pcx files and
scatterplots.
3) Most facilities previously available on a cell-by-cell basis, e.g. display on
screen, are now equally available for sectors.
4) Matrix dumps to ascii files may now include only a subset of all elements,
e.g. vertical strips to avoid very long record lengths per record. See 10.15.
5) Equally input from ascii files need not be based on full matrices so that the
matrix may be input and/or updated in stages. 10.5.
6) Matrix totals (i.e. the sum of all elements) may now be “dumped” to an
external ascii file. 10.14.
7) The FORTRAN-based matrix manipulation equations may now use row and
column totals as variable names; this can be very useful in emulating trip
distribution models. 10.8.1 and 10.19.1.
D.8.9 9.2 BUGS

A number of bugs have been found in 9.2 (as in earlier versions) and these are
listed in ascii files BUGS.93 and BUGS.92 which are supplied with SATURN 9.4.
Note that these do not necessarily occur in all released versions of 9.3 or 9.2 as
errors are corrected in later releases. The vast majority of the reported bugs are
relatively benign and only inconveniences; e.g. you try to do something and the
program does not respond or crashes. A small number however can lead to
incorrect results in certain (often unlikely) circumstances. It is a good idea to at
least scan these lists.
It should also be noted that some of the bugs have in fact been around for years
and not detected probably indicative of the fact that they are very rare and only
occur in highly specific circumstances.
The documentation has been extensively revised throughout and issued as hard
copy in ring binders by WS Atkins.
1) Sections 15.1 and 15.2 on queues and PASSQ have been put in a separate
section, 17, and expanded considerably.
2) Documentation is now held as WORD 7 documents.
D.8.11 FEATURES IN PROGRESS

1) A singly constrained trip distribution model may be incorporated with single
user-class assignments; more complex joint distribution - assignment
procedures are being developed.
5109341 / Mar 13 D-46

11_2_05_App D.docx
2) A new program PMAKE (strictly speaking PIX run from a different bat file)
allows networks to be defined interactively on screen using the mouse to
define nodes and links. For instructions how to use PMAKE (which is in fact
included in 9.4) please consult Mike Hall or Dirck Van Vliet.
5109341 / Mar 13 D-47

11_2_05_App D.docx

SATURN 9.5 was first released in beta-test form in September 1999, and as a full
release in March 2000. It is the first version of SATURN to be made available in
both dos (16-bit) and 32-bit Windows versions, so it is now fully (or almost fully!)
compatible with Windows 95, 98 and NT.
Compatibility with older versions of SATURN: as with previous new releases 9.5
binary files are no longer compatible with 9.4 and earlier versions of the programs,
but binary files from old versions may still be read (within reason). Equally (ascii)
data files from older versions may still be read by 9.5 but not necessarily vice-
versa. Finally the exact order of inputs within key files may have changed.
Users are reminded that they may use the NFT parameter (6.3.2) to explicitly run
previous versions of SATURN. However if they do wish to use the latest 9.5
version they will need to check that old explicit settings of NFT in existing network
data files (e.g. NFT = 94) are updated to NFT=95 (or NFT = 0).
The following sub-sections describe general new features of 9.5 followed by notes
of changes to individual programs.
may be found.
D.9.1 Windows 95/98/NT 32-Bit Versions

1) The bat files used in the 32-bit versions use a different procedure to transfer
command line parameters (i.e. the “net” in a command PIX net) into the
programs. Previously these were included in a standard file look.ere which
the program read; currently they are read directly from the command line by
the program. The advantage of the new system is that it is less prone to
confusion over which version of look.ere is which under multi-tasking; the
disadvantage is that the users have less control over what the bat files do by
being able to make their own changes.
Note however that the new bat files follow the same command line
conventions as the old. If a program appears to “misinterpret” a command
line please get in touch with DVV; some teething problems are inevitable.
It should also be noted that the new .bat files are incredibly simple - either
they print the command formats to the screen or else they call the .exe file
with the same command line arguments. So, apart from one extra
keystroke there is no difference between typing:
SATNET mynet (which calls the bat file)
and $SATNET mynet (which calls the exe file)
Those of you who are inclined to write your own .bat files, e.g. to set up long
over-night runs, may wish to note that it is probably preferable to use the
direct calls to the .exe’s.
2) The 32-bit Windows version allows multi-tasking but with restrictions. Thus
you can have two versions of, say, MX active at the same time but two
5109341 / Mar 13 D-48

11_2_05_App D.docx
programs must not access the same files simultaneously. To a certain

extent you can get around this problem by copying one file into another with
a different name. However problems can still arise since, for example,
network .ufs files generally contain the names of the .dat file from which they
were created and the trip matrix .ufm file. These may be opened
automatically by programs such as P1X; renaming the main file does not of
course rename these sub-files.
3) Screen editing is handled differently under Windows. The good news is that
it uses a proper edit window which is standard and much more flexible than
the old-style 9.4 screen editing based on limited Salford functionality. The
bad news is that it is not yet used as frequently as it was before but we are
working on that one. See 19.9.
4) In certain instances text outputs may be directed not to the “screen”, i.e. into
the master window, but to sub-windows which, like normal windows may be
re-sized, moved about the screen, copied to the clipboard, deleted etc. This
means that it is now easy to refer back to previous output information rather
than having to try to remember it. See 19.10.
5) Interactive programs, largely P1X, now have a menu bar with pull down
menus to complement the traditional SATURN choices from a banner menu.
19.5
6) At a technical level please note that the Windows versions no longer require
the Salford DBOS memory manager to be loaded. They do however require
various .dll files which are normally located in the same sub-directory as the
.exe files when the programs are installed; once set up users need do
nothing.
D.9.2 General Features

1) The concept of using symbols at the far right hand of menu items to indicate
whether they lead to further menus (>), are logical variables which may be
toggled (L), etc. has been extended from the graphical banner menus to
include text menus.
2) We now have a web site - largely under construction;
http://www.its.leeds.ac.uk/saturn/index.html. In particular the latest
documentation files are stored there and should be accessed by users
wanting the most up-to-date documentation.
Binary files, i.e. those with extensions .ufm, .ufs, etc., are now “zipped”
which basically means that they require less disc space through, e.g.
reducing a string of consecutive 0’s to essentially a single value of 0 plus
appropriate pointers. The savings are particularly significant for very sparse
matrices.
A consequence is that binary files are no longer backwards compatible such
that files produced by 9.5 cannot be read by 9.4 or earlier programs; the
converse, however, is not true.
3) The essential file is now - logically! - SAT95KEY.DAT; see Appendix Y.
5109341 / Mar 13 D-49

11_2_05_App D.docx
4) A new definition of “vehicle classes” is introduced; see 5.8.2.

5) The parameter LEFTDR is now included under SAT95KEY.DAT as a
“universal” parameter. See Appendix Y.
D.9.3 SATNET
1) Bus lanes may now be defined as part of simulation links by adding a B
before or after the number of links entry per link. Thus 2B instead of 2 (or 3)
implies 2 lanes for “normal” traffic plus one off-side bus lane; B2 is the same
except that the bus lane is on the near-side. See 6.4.9 and 15.39.
2) “Bus route” inputs may now be used to define routes in a much more
general sense; e.g. routes over which timed observations have been taken
and which will be used for validation. Timing points are included within
closed brackets after the relevant nodes. See 6.9.4.
3) A new parameter UPBUS allows (bus) routes which commence on a
simulation link to start at the upstream end of the link as opposed to buses
entering at the downstream end. Similar rules apply to the ends of routes.
See 6.9.2, note (1).
4) Bus routes may now be coded “in reverse”. If you have a bus route which
goes through slightly different nodes “out” and “back” you can define “back”
with the same basic set of nodes as “out” rather than having to put them all
in reverse order. See 6.9.2, note (7).
5) Data checking on input bus routes has been tightened up. In particular a
long-standing “bug” whereby a bus route could execute a U-turn at a
simulation node where U-turns were not permitted (i.e. any node apart from
a type 5 roundabout) has been (correctly!) identified as a fatal error. Hence
error-free networks under 9.4 may fail under 9.5. The quickest and simplest
solution is to delete the offending routes; the recommended solution would
be to redefine the route to avoid U-turns.
6) If a network has Fatal Errors, leading to an “Abnormal Termination”, a
summary of the Fatal Errors messages is given at the end of the .lpn file and
- 32-bit version - in a separate window.
7) The format of the 88888 data records has been modified to allow a “vehicle
class” to be inserted in columns 6-7; see 6.11. This could create problems
in existing data files if the matrix level, previously columns 6-10, was not
right justified. Not very likely.
8) The default values of certain input variables, in particular DIDDLE, have
been changed to reflect “best practice”; this may mean that old network files
will give different results. In addition other variables have new default values
“recommended” although not actually changed from previous versions. See
6.3.

1) The “simple” elastic options (i.e. T ij is a function of C ij only) have been
extended to include MCGILL = 5 and 6 where the demand models are:
5109341 / Mar 13 D-50

11_2_05_App D.docx
5: Nested logit model. See 7.6.2.

6: Single logit model (but differs from MCGILL = 2 in the way in
which the trip matrix is defined).
These two models are characterised as being “share” models as opposed to
“incremental” models in that the input trip matrix represents the full O-D
matrix including, e.g. both road and public transport trips.
2) In addition a set of singly (origin) constrained distribution models have been
introduced. See 7.10.1. These are of the incremental logit form:
o)
−β( Cij −Cij
Tij = A i Tijo e
where the balancing factor A i guarantees
Σ Tij = O i
j
Furthermore these may be combined with the “simple” elastic logit models
for MCGILL = 5 or 6 to provide joint distribution/modal split/assignment
models. See 7.10.4.
Both these extensions were developed under a DETR-sponsored research
project carried out by MVA and John Bates Associates in conjunction with
DVV; their input gratefully acknowledged.
3) Estimated or empirical values of elasticities (disaggregated by user class if
appropriate) are calculated within SATEASY/SATALL and printed both in
the lpa/lpt files and within the network parameters output by SATLOOK
(7.7.5 and 11.11.7).

1) A number of long-standing, apparently minor bugs have been corrected
which collectively may, in some cases, lead to improved convergence rates.
2) A new feature is introduced for modelling roundabouts whereby the entry
capacity for entry for an arm may be reduced in relation to the exit flow on
that arm (i.e. flow that exits before the new flows enter) via “Ks factors”. See
8.7.2.
D.9.6 SATALL
An option to “continue” previous SATALL runs has been introduced. See 9.12.1.
D.9.7 PIX
1) The main menu now contains a “Validation” option which in turn comprises:
♦ A comparison of modelled vrs. observed counts. (11.7.1)
♦ An analysis of time-distance diagrams on selected routes. (11.7.2)
5109341 / Mar 13 D-51

11_2_05_App D.docx
The latter is new in 9.5 and works on the principle that timed routes may be
defined as a subset of the bus routes in which (a) the frequency is zero and
(b) observed cumulative times to individual nodes are defined in the original
.dat file input to SATNET.
Count validation is essentially the existing statistical analysis of observed
vrs. modelled flows but with various options, e.g. demand or actual flows.
(See also L.9, note 3.)
2) Node numbers may be annotated “offset” from their junctions independently
of any annotation which traditionally appears “at” the junction.
3) Several other options permit time vrs. distance diagrams to be created; e.g.
joy rides, bus routes, o-d trees, all under Analysis.
4) Select link analysis options have been considerably extended, e.g. to select
actual, demand or queued up flows or to output selected trip matrices (which
previously was only available within SATDB). Also flows to origins or from
destination zones may be selected.
5) Bus route analysis may optionally include all of the first and last links;
previously a bus route defined by A-B-C-- X-Y-Z began at the downstream
end of link A-B and terminated at the upstream end of Y-Z; links A-B and Y-
Z may now be included.
6) The Editing options have been extensively revised. See 11.8 and Section
18. In particular the PMAKE procedure which allows the “topology” of
networks to be created interactively on screen and which has been “under
development” for some time is now operational. The same procedures may
also be used to edit network properties on screen and to create new
scenarios for testing on network .dat files.
7) BMP outputs are now allowed under 32-bit versions. Technically the bitmap
outputs have now become “generic” so that you may select whether a “PCX”
output option produces a PCX or BMP file or, thirdly, output to the clipboard.
8) It is devoutly hoped, though not conclusively proved, that printing to external
devices will be considerably simpler under WINDOWS 32-bit systems in that
the drivers within Windows can be used. This also means that graf.dat can
be essentially reduced to 2 devices, the screen and the printer.
9) A facility to “dump” the information on a network .ufs file into an equivalent
(or nearly so) .dat file has been added. Useful if one of your colleagues
(never you!) has been a bit over enthusiastic with the delete key!
D.9.8 MX
1) A new set of “Demand Calculations” has been added which effectively
mirrors the elastic demand models available through SATEASY and/or
SATALL. The latter programs calculate the cost of travel by road as part of
the assignment program; within MX the road costs - and indeed any other
cost matrices which are needed within the model - must be input .ufm files.
Thus to carry out a simple modal split model input a trip matrix plus two cost
5109341 / Mar 13 D-52

11_2_05_App D.docx
matrices, define the relevant parameters within MX and create a demand trip
matrix. See 10.18.
2) Both input from and output to an external .dat file may now be “partial” such
that only a part of the matrix is affected. These options are useful if, for
example, it is desired to dump a SATURN matrix into a spreadsheet, e.g.
EXCEL, for further manipulation but that program cannot accept a large
number of “columns”, in which case one can dump and re-read the matrix in
vertical “strips”. See 10.5.4 and 10.15.
3) New style screen editing is available under Furness options to define new
trip ends etc, but not (yet) to edit individual cell or sector values.
4) Under Row and Column Totals, both listing (option 9) and dumping (option
12), the grand total of all matrix cells may be output on its own. In addition,
when writing to an external file the data may be “appended” to an existing
file which can be quite useful when collecting data from a series of runs
under a batch procedure. See 10.14.
5) The options to print to alternative devices under matrix graphics has been
extended so as to be comparable with standard facilities in PIX.
6) Editing of zones, e.g. adding or deleting rows and columns may now be
done directly to the internal matrix "in situ" rather than applying the changes
while copying from an external .ufm file. (Although we do cheat a bit by first
copying the internal matrix to a “scratch” .ufm file and then re-copying as
before). See 10.4.
7) Conversion options to and from EMME/2 have been created (although not
extensively tested). Thus input from a .dat file may use a standard EMME/2
format; equally output to a .dat file may use the same format. See 10.5.5
and 10.15.
D.9.9 SATLOOK
1) Option 4, Simulation Summary Statistics, has been extended to cover not
only buffer plus simulation statistics but also to output statistics for buffer-
only networks. Option 5 - assignment summary statistics - becomes virtually
redundant as a consequence.
2) Simulation statistics may now be calculated “on the hoof”, not using pre-
calculated statistics from SATALL as stored in the .ufs files. This enables
standard summary statistics to be calculated for only a set of PIX/SATDB -
selected links.
3) Comparison statistics between observed and modelled flows are now much
more flexible with options to distinguish e.g., actual or demand flows or
counts on links or turns. See 11.7.1.
D.9.10 SATDB
1) An option, to be known henceforth as One Song to the Tune of Another, has
been created whereby one trip matrix is assigned and loaded according to
the routes and route proportions of another network (to which, presumably, a
5109341 / Mar 13 D-53

11_2_05_App D.docx
different matrix had been loaded). An output .ufa file is produced and may
next be simulated via SATSIM.
2) This represents a form of perturbation assignment whereby the impact of
loading a (slightly) different matrix to fixed routes may be determined. See
11.10.6.
D.9.11 SATED (Node Graphics)

Nodes with arms at very low angles (nearly parallel) are “adjusted” such that kerbs
do not meet at long distances from the junction centre. Previously this was done
by adjusting their angles of approach; in 9.5 it is done by “pushing” them apart at
right angles to their approach direction. This appears to better interpret the likely
junction configurations in real life but there are bound to be a number of strange
cases where further fine tuning to the algorithm used will be necessary. Please
notify Dirck Van Vliet of any examples of node graphics which do not “look right”.
D.9.12 New Programs

A new program SATDYSK which carries out dynamic skims has been added; see
12.7. It should be stressed that this program is still under development and may
well be modified over time.
D.9.13 Documentation
1) This has been extensively rewritten, in particular with Windows applications
in mind, and is now produced using Office 2000. Illustrations of SATURN
screen images are now included.
2) Note that the files are in 14-font and have margins set for alternate left - and
right-hand pages. They are therefore best printed as two pages per A4
sheet “side by side”.
3) The files will be included with any releases but users are encouraged to
download the very latest versions from our web site as these will be
continuously updated. See note 2 under L.2.
4) Note in particular that a Beginner’s Guide to Network Coding has been
introduced, section 5.6, plus two new sections: 18 which describes the new
interactive network editing and building procedures and 19 which describes
interactive procedures in general (formerly part of Section 11).
5109341 / Mar 13 D-54

11_2_05_App D.docx

SATURN 10.1 was first released in September 2000 and is the first fully 32-bit
version of SATURN so it is now compatible with Windows 95, 98 and NT. The
programs may however still be compiled as 16-bit executables (with slightly
different functionality) and may be supplied if required.
As with previous new releases 10.1 binary files are no longer necessarily
compatible with 9.5 and earlier versions of the programs, but binary files from old
versions may still be read (within reason) by 10.1. There is (apparently) no
problem in transferring files between 16 and 32-bit versions. Equally (ascii) data
files from older versions may still be read by 10.1 but not necessarily vice-versa.
Finally the exact order of inputs within key files may have changed.
However, given the relatively short time period between the releases of 9.5 and
10.1, there have been relatively few changes in formats so upgrades from 9.5 to
10.1 should not pose a problem. Your incompatible file is of course the exception
to the rule!
The following sub-sections describe general new Windows features of 10.1
followed by notes of changes to individual programs. Where changes have been
introduced following the general release version 10.1.5 in September 2000, the
first version number is noted as e.g. [10.1.6]. Thus version 10.1.9 was released in
January 2001.
may be found.
D.10.1 Windows 95/98/NT 32-Bit Versions

1) Version 10.1 of SATURN is the first to be primarily programmed as a 32-bit
program - and therefore suitable for use under Windows 98/NT/2000. In fact
10.1 is only being released as 32-bits, although a 16-bit version may also be
compiled on request. See 3.4
2) There is therefore a continuing shift away from keyboard based inputs and
text menus in the interactive programs such as P1X to windows-style inputs
and graphical display banners.
3) In order to emphasise its role as a fully compatible Windows program
version 10 is also released in parallel with the SATWIN “front end” program,
which may be used to run SATURN programs without recourse to either
Command Prompt or Dos. See 3.6.
D.10.2 SATNET
1) Fatal coding errors in SATNET are now sub-divided into “fatal” and “semi-
fatal” such that semi-fatal errors prohibit the network from proceeding into
SATALL but allow it to be processed by P1X so that the errors may be
interactively corrected, 6.12 and 18.4.
2) The maximum length of a “pathname” which may be stored for a file is
increased to 256 characters from 96.
5109341 / Mar 13 D-55

11_2_05_App D.docx
3) A parameter FREEXY now allows X, Y co-ordinates to be input as “free

format” under the 66666 data records, solving problems of, e.g. 5-digit zone
numbers and co-ordinates with more than 5 digits. 6.8 [10.1.6].

1) A WIDDLE option (a variation on DIDDLE) has been added to allow
assignments in buffer-only networks to be continued from previous
assignments (see 9.11.6).
2) An extra parameter NITA_S to control the number of assignment iterations
on the extra SAVEIT loop for elastic assignment has been introduced; see
15.23 [10.1.6].
D.10.4 PIX
1) Interactive network editing facilities, in particular the topological editing
functions under PMAKE, have been extensively tightened up and extended.
Try them! Section 18.
2) An auxiliary network plot is available to indicate, e.g. the location of the
current window within the full network. See 11.5.2.
3) Parameters, e.g. height and width, of the “alternative device”, i.e. the printer,
may now be set interactively during a program run; see 11.3.4.
4) Network-wide signal optimisation routines within P1X have been enhanced
to allow the joint optimisation of both stage times (green splits) and offsets
as well as the option to introduce a re-simulation loop. See 11.9.12 [10.1.6].
5) In addition the above optimisation may only cover selected nodes [10.1.6].
6) Trees may now be defined by the destination-end as opposed to origin only.
See 11.8.3 [10.1.8].
7) The interactive editing of simulation nodes (or of buffer nodes converted to
simulation) now allows bus-only links and/or turns to be defined more easily.
[10.1.8]
D.10.5 MX
1) The demand calculations have been generally “beefed up” and made more
user friendly such that they are now essentially functional rather than
experimental. See 10.18.
2) A new form of stacked matrix by “blocks” as opposed to “levels” has been
introduced. Its first application is to store trip matrices by multiple time
periods within a single .ufm file. See 10.2.4 and 17.4.3.
3) Inputs from EMME/2 produced ascii matrices have been “tightened up” and
made more reliable; 10.5.5 [10.1.6].
4) The option to read non-zero matrix elements off a single record now allows
for a matrix level to be explicitly included in order to make it easier to
update/define stacked matrices; 10.5.3 [10.1.6].
5109341 / Mar 13 D-56

11_2_05_App D.docx
5) Zones may be added together (“compressed”) either from sequential blocks

of zones or from “mixed” sets. See 10.4 [10.1.7].
6) The selection rules involving tests for EQ or NE now include an explicit
plus/minus value. See 10.6 [10.1.8].
D.10.6 SATCH: Cordoning

Multiple user class matrices may now be cordoned over all levels, not just for a
single user class. 12.1.6.
D.10.7 SATDB
An explicit GEH function is now included within the “FORTRAN equations” to
calculate new data columns 11.10.8.
D.10.8 SATED (Node Graphics)

A new procedure for optimising signal green times has been introduced, basically
a revised Mark II version of the SATURN equi-saturation algorithm. See 15.31.3.
D.10.9 SATLOOK
Count vrs modelled flow comparisons now include explicit output statistics for
three validation criteria as recommended by the UK DETR. 11.7.1.
D.10.10 Multiple Time Period Modelling

Facilities for multiple time period modelling have been improved, first by
introducing “blocked” matrix files (10.2.4) which contain trip matrices for several
time periods within a single .ufm file and secondly by introducing demand
algorithms based on the incremental logit model proposed in a PhD at Leeds by
KK Chin. The latter algorithm appears both as a pure matrix manipulation model
within MX (10.18.2) and as a new program SATKK which allows a joint
equilibrium model of time plus route choice to be formulated and solved using an
iterative procedure similar to Frank Wolfe. See 17.12.
While the new program SATKK has been included within SATURN 10.1 its
documentation verges on the non-existent. However it does seem to work and
has been successfully run during a SATURN Intermediate Workshop at Leeds;
interested users are advised to contact DVV.
5109341 / Mar 13 D-57

11_2_05_App D.docx

SATURN 10.2 was first released in September 2001.
versions may still be read (within reason) by 10.2. There is (apparently) no
problem in transferring files between 16 and 32-bit versions. Equally (ascii) data
files from older versions may still be read by 10.2 but not necessarily vice-versa.
Finally the exact order of inputs within key files may have changed.
The following sub-sections describe general new Windows features of 10.2
followed by notes of changes to individual programs. Where changes have been
introduced following the general release version 10.2.8 in September 2001, the
first version number is noted as e.g. [10.2.9].
may be found.
D.11.1 Windows 32-Bit Updates

1) The continuing process of converting from text- to windows-based
interfaces within the main interactive programs P1X and MX has continued.
In general terms virtually all of P1X has been converted with the exception of
the SATDB and SATLOOK sub-programs (which are not planned to be
changed), whereas only limited changes have been made to MX as noted
below.
2) The format of KEY and/or LOG files have been altered when used to record
choices from P1X banner menus such that the letter selected is recorded as
well as its pixel position. This removes the problem with transferring key files
between computers with different pixel resolutions or between networks
where, for whatever reason, items in a banner menu appear at different
locations. Using Key files should therefore be more “robust”.
3) The Windows front-end program SATWIN has had a number of minor bugs
corrected, particularly those related to file selection for lesser used options
and modules. The Batch files used have also been modified to ensure the
correct sequential operation of modules under multi-tasking operating
systems like NT.
4) SATWIN has also been extended to allow spaces in folder names, which
was strictly disallowed in the previous version. This should allow it to be
installed under ‘Program files’ if required. The file Editor as before uses
NotePad or WordPad by default but users can now also select their favourite
editor from the Tools |Menu if desired.
5) Other extensions include quick access to modules through a right click on
the event log, selective deletion of items from the event log (hold down
CTRL key, click on lines to be deleted and Clear Selection); and an option to
highlight and re-run a selection from the event file (as for delete but click on
Run Selected Items).
5109341 / Mar 13 D-58

11_2_05_App D.docx
6) Both the SATURN Introduction slideshow and User Documentation can be

viewed through SATWIN.
7) Finally, the DRACULA demo is loaded automatically for access through the
Module option in the toolbar. If the full DRACULA is purchased, it installs
and is accessible under SATWIN.
D.11.2 SATNET
The default values for MAXDTP and MAXQCT have been changed to the
“sensible” values of 10 and 60 respectively. If you have not previously used these
parameters - which you should be doing! - then re-running old jobs will give
different answers unless these parameters are explicitly re-set to their old default
values of 0.

A small number of long-standing and extremely rare bugs within the simulation
have been corrected; these may produce relatively small differences in the
outputs from certain networks.

The MCGILL values have been redefined such that the “incremental” demand
models and the “shared” demand models have distinctly different MCGILL values.
Thus MCGILL = 1 ... 4 remain the same but values 5 and 6 (nested logit and logit)
have been renumbered as 10 and 11. It is intended to further extend the set of
functions catered for so that 5 will eventually be re-used (probably for Box-Cox)
D.11.5 PIX
1) Link annotation display now allows geometrical displays to use a variety of
colours dependent upon the numerical values which are being annotated
e.g. flows of 0-200 in red, 201 to 400 in blue, etc. etc. 11.6.3.4.
2) The “Variable Intensity” display now allows the maximum intensity value to
be set to zero, in which case all displays are at maximum intensity so that all
link data is displayed as a solid bar of fixed width, full length. So it only really
makes sense to use it when you are also using variable colours! 11.6.3.2.
3) Tree-based analysis has been extended such that trees based on routes
used in networks other than network 1 may also be displayed provided that
the “other” network is structurally identical to network 1. (To be extended to
allow for structurally different networks “soon”.) 11.8.3.3.
4) Plot windows may now be defined by explicitly defining the values of the
min/max X and Y co-ordinates within 32-bit windows.
5) The set of plot window definitions as used in a particular run may now be
saved and stored in an external “.wxy” file which may subsequently be read
within another run such that “standard” windows may be re-created. 11.5.2.
6) The process of selecting a sub-set of selected nodes has been redesigned
and, in particular, now allows the user to select nodes by clicking on them
with the mouse.
5109341 / Mar 13 D-59

11_2_05_App D.docx
7) Multiple node data may be displayed graphically within “boxes”. 11.6.5.

8) All “text” menus have been removed as alternatives to banner menus while
a large number of windows-based selection and edit boxes have been
introduced.
9) In addition forests may be displayed for more than one network at the same
time or with the differences between two networks displayed. 11.8.3.3
10) The number of standard items of link annotation which may be selected from
(text) links has been extended and now provides options to select flows,
times etc. by user class or time period explicitly (rather than having to resort
to DA codes).
11) A new option has been introduced into the Windows Menu Bar (under Back)
which takes you back directly to the master (i.e., top-most) menu
12) An extra parameter has been added to the set of parameters which control
the appearance of plots on the screen or printer; thus the “shift correction”
corrects a potential problem whereby alphanumeric output which is rotated
from the purely horizontal or vertical is incorrectly shifted upwards or
downwards on some devices. The “annotation shift” provides an empirical
correction. 11.3.4.
13) The cordon options within P1X now allow an output cordoned trip matrix to
be a stacked matrix for multiple user classes (as is also available within
SATCH with ALLUC = T).
D.11.6 PMAKE (Network Editing)

Although PMAKE is effectively a sub-component of P1X we list separately those
new functions available within network editing.
1) A new output option, “Rebuild”, allows a .ufn file to be constructed from the
internal .dat file which is created/manipulated by PMAKE. In effect this
introduces SATNET as a sub-procedure within P1X. 11.9.2.
2) The range of data entries which may be graphically edited has been
considerably extended to include, e.g., the counts data section and other
components such as bus routes have considerably more functionality.
3) Most forms of editing now allow screen edit options to directly alter the .dat
file within particular sub-sections (e.g. you may screen edit the coding of
simulation nodes). In addition the .dat file may be screen edited as a whole;
11.9.14.
4) Signal settings from simulation nodes may now be dumped into special .rgs
files which may most usefully be used to “transplant” a set of signal settings
from one network into another. 11.9.16.
5) A set of options allow two networks to be compared node by node and
tables produced to indicate, for example, when a node is coded identically in
both networks apart from, say, its signal timings, etc. 11.9.15
5109341 / Mar 13 D-60

11_2_05_App D.docx
D.11.7 MX
A number of minor changes and additions have been made. For example the
procedures to define new zones have been extended and, hopefully, made more
intuitive.
D.11.8 Path-based Assignment Algorithms

A totally new set of assignment procedures has been introduced which explicitly
stores flows on O-D paths in addition to flows on individual links. This is based on
research carried out at ITS Leeds by Dorota Kupiszewska and Dirck Van Vliet with
the original C-code having been translated into Fortran. Path-based algorithms
offer the possibility of improved convergence rates, alternative elastic assignment
algorithms and much simpler analysis for certain operations. A set of papers is
available from Dirck Van Vliet. Full documentation will (eventually) be included in
a new section of the manual, 20.
D.11.9 New Programs: SPATULA

SPATULA converts outputs from the DRACULA Suite into a SATURN-compatible
network binary file - specifically .ufd files - which may then be read by P1X such
that the various analysis options therein may be used to view DRACULA outputs.
D.11.10 SAT10KEY.DAT
The standard identification file has been re-named from SAT95KEY.DAT to
SAT10KEY.DAT; see Appendix Y. Note, however, that for the time being
SAT95KEY.DAT files will continue to be accepted.
5109341 / Mar 13 D-61

11_2_05_App D.docx

SATURN 10.3 was first released in Beta version in April 2002 and as a full release
(10.3.9) in October 2002.
versions may still be read (within reason) by 10.3. Equally (ascii) data files from
older versions may still be read by 10.3 but not necessarily vice-versa. Finally the
exact order of inputs within key files may have changed.
The following sub-sections describe both new general features of 10.3 (e.g., new
Windows 32-bit features) and changes to specific programs. Where changes
have been introduced following the general release version 10.3.9 in October
2002, the first version number is noted as e.g. [10.3.10].
may be found.
N.B. The order of items within each section is not based on relative importance
but, roughly speaking, on the chronological order of development.
D.12.1 General Updates

1) The problem of text which is written at an angle (specifically numerical link
annotation in P1X) appearing (sometimes but not always) at the wrong
position and the wrong orientation on (some!) hard copy outputs larger than
A4 has been solved by substituting an optional set of “DIY” fonts. 11.3.8.
2) All text and edit box etc. windows now allow Cut, Paste and/or Copy
operations as appropriate.
3) The .bat files are now more “clever” in that you may input file/pathnames
directly as in P1X net1 net2.ufs instead of P1X net1 S 2 net2. 14.2.1.
4) Namelist now accepts the input of subscripted arrays; see note 12, Appendix
A.
D.12.2 SATNET
1) The KNOBS facilities has been extended in several ways (15.14), both in
terms of inputs (described here) and applications (notes 2 and 3):
♦ They may be included in the 333 records on the same line as the link to
which they refer as opposed to being a second record which must
always appear (parameter KONAL).
♦ The data may be input as part of a separate input file (defined by the
namelist parameter KNBFIL).
2) Tolls may be explicitly defined within the 44444 records in monetary units as
opposed to equivalent time units and also defined through the KNOBS
inputs. 20.3.
5109341 / Mar 13 D-62

11_2_05_App D.docx
3) The extra time spent by buses at bus stops along links may be explicitly
defined using KNOBS data. 15.44.
4) New namelist variables NOXYC and NO333C allow zones to be
distinguished by their absolute value rather than using a C in column 1
(useful in converting existing data sets). 5.1.6, 6.6 and 6.8.
5) The output .lpn file now gives the line number in the input .dat file any time
that it reproduces that a data line. This makes locating errors in the .dat file
much simpler.
6) Certain input fields (e.g., link times or speeds) on either the 11111 or 33333
data sets which are implicitly integers may now be input with decimal places
for greater accuracy if required. 6.4 and 6.6 (Note 10).
7) Bus lanes may be explicitly defined as parts of simulation links for the
exclusive use of buses. They are coded by adding the letter B to those
columns on a link data record which define the number of lanes. 15.39 and
6.4.9.
8) The SHANDY option has been extended so as to “suggest” correct values
for XYUNIT if the input link distances disagree consistently with those
calculated from crow-fly distances, e.g., by a factor of 10 implying that
XYUNIT is out by a factor of 10.

1) A complete set of simulation plus buffer summary statistics including
summations for penalties and tolls is included at the end of every run of
SATALL plus, optionally, at the end of each loop. See also D.12.10.
2) A new facility to model the “weaving” effect between in-bound and exit
ramps on motorways has been introduced. 15.40
3) The lane choice on links where merging traffic enters has been altered to
allow for traffic on the major road to avoid the lane where the merging will
take place. This therefore reduces the delay to and increases the capacity of
merging traffic and means that the 10.3 simulation gives significantly
different results from previous versions. However it is possible to use the
old rules by setting a parameter APRESV to 0.0 or by NFT = 102. 8.8.3.
4) Merging movements may now be defined in “pairs” to represent, e.g., the
situation where two motorway links come together in a “Y” junction. 6.4.2.3
and 8.8.3.

1) The effect of monetary charges (including parking charges, road charging
etc.) is now explicitly included within the assignment and elsewhere. Tolls
are input in monetary units (e.g., pence) and converted into generalised time
units along with “real” time and converted distance in order to determine
both route choice as well as the more general demand functions. Previously
tolls could be modelled but had to be first converted into the equivalent time
units by the user. 20.2.
5109341 / Mar 13 D-63

11_2_05_App D.docx
2) When the output .ufc (SAVEIT) file is based on a final re-assignment rather
than the “actual” assignment (as happens with, e.g., DIDDLE) and therefore
use of the SAVEIT-based analyses is only approximate a table of statistics
comparing the “true” link flows and the “SAVEIT” link flows is produced
within SATALL. The same data may also be accessed from within
SATLOOK (main option 8) and in P1X. 15.2.
3) The total number of trips assigned (total and disaggregated by user class
where appropriate) is now stored on the output .ufs file and are reported
within the output simulation/buffer statistics by SATLOOK etc. A useful
output statistic under elastic assignment. 17.9.
4) The elasticities calculated for shared demand functions (e.g., logit models)
where MCGILL > 10 are now done after the assignment using output road
costs rather than pre-assignment using essentially guesstimates of the road
costs; the two methods may give quite different values and the new method
is more appropriate. 7.7.6.
D.12.5 SATALL (Assignment / Simulation Convergence)

1) The stopping condition for the loop between simulation and assignment
within SATALL may now require that the stopping criteria are satisfied on
more than one successive loop via a parameter NISTOP. 9.1.
2) Flow convergence statistics between successive assignment / simulation
loops for multiple user classes are now disaggregated by user class and
printed both within the .lpt files as well as within the summary statistics
produced by SATLOOK and/or P1X. 9.11.
3) The distribution of the %FLOW and %DELAY statistics which monitor
convergence of the assignment / simulation loops are now given for variable
values of the critical difference (PCNEAR, in effect) as well as the traditional
single value for fixed PCNEAR. 9.9.1.
D.12.6 PIX
1) Geometric link annotation (e.g., bandwidths) allows a full choice of colours
based on link values through, e.g., user-set ranges. 11.6.3.4.
2) Link annotation may consist of fixed width bars with variable colours to
denote ranges of values; e.g., links whose speed is 0-10 kph will be in one
colour, 10-20 kph in a different colour, etc. 11.6.3.5.
3) Node annotation can be displayed within “boxes” such that more than one
data property can be annotated. 11.6.5.1.
4) An option has been added to the Windows menu bar to return directly to the
“top” menu from anywhere in the program and/or to further directly select
any of the standard “top” choices. E.g., you can go directly to the Analysis
menu from anywhere within P1X. 11.2.
5) Select link analysis allows multiple user class stacked matrices to be output
in a single run. 11.8.1.
5109341 / Mar 13 D-64

11_2_05_App D.docx
6) Select link analysis now outputs a table showing the demand flows from all
possible entry points to the first node to all possible exits from the final node.
11.8.1.
7) The node bandwidths displays may be in multiple colours; e.g., set by range
bands, positive vrs negative, etc. 11.6.5.2.
8) Pen colours for the secondary device (i.e., printer) may be defined internally
in the same way as the standard pen colours may be defined for the screen.
11.3.7.
9) The log files produced by P1X - which in turn become key files - have been
“tightened up” and are less prone to random crashes.
10) A selection of links and/or nodes (in the sense of selecting a sub-set of links
for display) by pointing and clicking with the mouse. 11.6.1 and 11.6.5.3.
11) With multiple user classes the annotated link data may either be selected for
a single user class or for all classes. 11.6.2.
12) The definition of devices has been tightened up so that now the “primary”
device is always the terminal screen and the “secondary” device is always a
printer accessed using the Windows drivers. This further reduces the
importance of the graf.dat file in that you may still select various devices
from graf.dat but the only information taken on board is information relating
to device dimensions (e.g., distinguishing an A4 from an A0 printer) etc. so
that there is no difference for example between a “PLOTTER” and a “LASER
PORTRAIT FILE”. 11.3.2.
13) A problem with Windows List Boxes (e.g., menus) has been corrected
whereby scroll bars sometimes appear on even very short lists with the final
item “off the bottom”. By optionally adding an extra blank line on the bottom
the problem disappears. 19.7.
14) It is now possible to include/exclude links from the plots by virtue of their
capacity index, a sort of halfway house between “link selection” and “link
display”. 11.6.1.4.
15) O-d desire lines are still restricted to a maximum number of 502 but now, if
there are more than 502 possible entries, the 502 maximum values are
included. 11.6.7.
16) Bitmap background displays “move” as the network window “moves”. 15.43.
17) A “routes file”, similar to that produced by SATPIG, may now be produced
for a cordoned network (with a view to passing it on to a micro-simulation
framework such as DRACULA; see next point). 11.13.2.
18) A short demonstration of the DRACULA micro-simulation program may be
run either using the cordoned network or node graphics. 11.13.7.
19) The Information options have (a) been added as one of the choices from the
“master menu” (and also retained under Analysis) and (b) been extended to
include most of the convergence and/or error summary statistics available
from SATLOOK.
5109341 / Mar 13 D-65

11_2_05_App D.docx
20) The choice between Network and GIS editing is now made within the Master
Menu rather than one sub-menu removed.
21) An extra option under Display allows direct control of bitmap files used as
background. 11.6.10 and 15.43.
22) The secondary device (i.e., printer) dimensions may now be set
automatically by defining the device as, e.g., A0 or A3. 11.3.4.
23) An option under Information allows the user to “monitor” the user co-
ordinates of points within a plotted window by pointing with the mouse; the
co-ordinates appear in the banner. 11.8.6.
24) A DRACULA micro-simulation demonstration of flow patterns of traffic at a
single junction is available under Node Graphics. 11.12.?
25) A new option to “mark” the various network parameters and to print warnings
of any apparently “weird” choices (as judged by DVV and MDH!) is available
under Information.
26) When using the mouse, e.g., to define a “window box”, the co-ordinates of
the current mouse position generally now occur within the banner as a guide
to the point to be selected.
D.12.7 PMAKE (Network Editing)

Although PMAKE is effectively a sub-component of P1X we list separately those
new functions available within network editing.
1) A rebuild facility has been added - effectively incorporating SATNET within
P1X. 18.2.6.
2) All 8 data segments including the 44444 and 88888 data records may be
edited directly.
3) Simulation centroid connectors to links may now be converted automatically
into connectors to a new priority node created in the middle of the link.
11.9.4.
4) Files referenced via $INCLUDE records may now be input and edited and
also re-created at the end of the edit procedures. 18.2.3.
5) Screen editing (via standard Windows edit boxes) is now available for all
data segments. 11.9.16.
6) Bitmap files used as background for tracing networks now require co-
ordinates to be defined. 15.43.
7) Signal settings from one network may be transferred to another via “.rgs
files”. 11.9.14.
D.12.8 MX
1) Spreadsheet (comma separated CSV) input now allows zone names and/or
sequential numbers to be optionally included on each “row” record.
(Previously they could be output but not input.) 10.5.4.
5109341 / Mar 13 D-66

11_2_05_App D.docx
2) Errors in editing the zone structure have been corrected and more options
included for compression/renaming. 10.4
3) The identification of intra-zonal cells has been “tightened up” for stacked
matrices so that the totals printed under row and column totals are
improved. 10.11.
4) An option under Matrix Manipulation allows the log-sum of two or more cost
matrices to be created; e.g., for application within hierarchical logit models.
10.8.5.
D.12.9 Path-based Assignment Algorithms

These are now included as standard and (will be) documented.
D.12.10 SATDB
1) SATCOBA allows a sub-network with the specifications required by COBA
(e.g. 2-way links appear only once) to be created from a SATURN network
and a correctly formatted data file including flows from multiple time periods
to be output. 15.42.
2) Options have been added to allow link or turn data to be aggregated by
node. 11.10.5 and 11.10.8.4.
3) The aggregation of, e.g., turn data to links or link data to nodes may be
based on maximum or minimum values in addition to straight forward
summations or averages. 11.10.8.4.
4) The option to do an all-or-nothing assignment also now calculates a delta
function value as would have been done within the original assignment itself.
11.10.7.3.
5) A new DA array numbered 4053 has been added and represents the
average link speed including - for simulation links - the flow-weighted
average delay at the downstream junction.
6) The “rules” for calculating reverse link values, in particular those to obtain
two-way flows from one-way flows, have been “tightened up” to cope with
one-way links and to better satisfy what would be required under the
SATCOBA facility mentioned above. 11.10.8.2.
7) An option has been added under “dump to a text file” to include a blank C-
node entry for links under CSV format (in effect an extra comma). Thus both
links and turns have three initial identification entries prior to the data proper.
11.10.9.
8) In addition the “width” of the individual records dumped to a text file has
been increased so that up to 24 data items may be dumped. 11.10.9.
D.12.11 SATLOOK
1) A new .bat file plus internal operation SATTUBA outputs the time, distance,
and monetary tolls (as required) matrices in the format required by the latest
evaluation program Tuba. 15.41
5109341 / Mar 13 D-67

11_2_05_App D.docx
2) The output tables which include both buffer and simulation summary
statistics (e.g., total vehicle-hours) now also include totals for time penalties
(input under the 44444 records) and for all monetary charges. 17.9.
3) The output tables under Error/Convergence Stats now include the summary
table from SATALL which includes, e.g., the average absolute difference
between flows from one loop to the next as well as the table which gives the
“ISTOP statistic”. That table has itself been extended to include the Relative
Average Absolute Difference (RAAD) as required by DfT validation
procedures. 11.11.8 and 9.9.1.
D.12.12 SATCH
1) Several “bugs”, both in SATCH on its own and in cordoning within P1X,
have been corrected.
2) A “spine” option, similar to that already in SATCH, has been added to the
cordon options within P1X so that, e.g., a section of motorway may be
“cordoned off” and the matrix of all trips entering/exiting along that stretch of
motorway calculated. 11.13.5.
3) Within P1X the cordoned trip matrix may optionally be printed to a window
while output to a .ufm file is also optional. 11.13.6.
4) A “routes file” similar to that produced by SATPIG (except that SATPIG runs
for a full network) and intended for input into DRACULA may now be output
within P1X. 11.13.7.
5) A demonstration run of the DRACULA micro-simulation model over the
cordoned sub-network may be generated automatically from P1X. 11.13.8.
6) The cordon may now be interactively set in P1X by a rectangle set by
“rubber banding” (similar to the “box” option under windowing).
D.12.13 SATPIG
1) SATPIG now produces an output “.kp” file in addition to the .lpg file
containing the route data. 12.6.
2) The route data file has an extra (.trp) format suitable for direct input into
DRACULA.
1) The manual has been fully updated to include the new facilities reported
above. In particular one new section, 20 on tolls, has been included and
several other subsections have been extensively revised, e.g., 15.14, or
added, e.g., 15.40 to 15.45.
2) Previous appendices D to N which contained details on improvements from
SATURN 8.1 up to 10.2 have now been aggregated into a single Appendix
D and denoted D1, D2, etc. up to the current section D12.
5109341 / Mar 13 D-68

11_2_05_App D.docx

Date of last Update: 05 December 2003
SATURN 10.4 was first released in Beta version (10.4.3) in March 2003 and as a
full release (10.4.10) in October 2003.
D.13.1 P1X
1) The Validation options have been extended to allow a set of summary tables
for each route with timing points to be printed automatically to the .lpp file
and to a window with appropriate statistics for the goodness of fit between
observed and modelled times included. Statistics include a test for the DfT
criterion of +-1 minute or 15%. 11.7.2.3
2) GEH statistics comparing observed and modelled flows under Validation
may now have a “sign” added; i.e., positive or negative depending on
whether the observed flows are greater or less than the modelled flows.
3) The choice of turn annotation data has been extended to include input turn
count data and error statistics such as GEH which compare modelled and
observed counts.
4) Turn goodness of fit statistics (e.g., GEH as above) may also be displayed
under Validation in addition to (/instead of/without) link validation statistics.
5) The turn annotation choice menu is entered directly if numerical data is
selected.
6) Cordoned trip matrices may be “Furnessed” in order that the new origin /
destination totals at the new crossing points correctly equal the assigned
flows at those points (correcting for approximate routes). This also applies
to SATCH. 12.1.7.
7) A confirmation “OK” box has been added once a select link choice has been
set. E.g., if you make a mistake setting a sequence of nodes you can
“cancel” rather than having to go through the full SLA calculations.
8) Outputs under DUTCH are improved by checking for maximum node length
actually used rather than allowing for 8 columns and restricting the
remaining data output (e.g., GEH stats under count comparisons)
9) U-turns at external simulation nodes may be printed under Information
options and/or displayed as plotted node data. 11.8.4.5.
10) The format of the Graf.dat file has been altered to allow extra parameters
such as the “rotational shift” to be entered as user-set defaults. 11.3.4.4.
11) An option under the Window Menu to return to (up to 10) previously selected
windows (whether or not the windows have been specifically “saved”) has
been added. 11.5.3.
12) The co-ordinates of any point within the on-screen network may be
“monitored” to show the user-defined X,Y. 11.8.4.2.
5109341 / Mar 13 D-69

11_2_05_App D.docx
13) An option is provided under editing to “examine” the various network

parameters for values which, in the opinion of Dirck and Mike, look a little
fishy. 11.9.11.
14) Zonal sector numbers are now included as a standard node data item to be
displayed.
15) P1X is now more “robust” against the program crashing when more than one
application is running at the same time and the same “non-essential” file
(e.g., a trip matrix) is required by more than one application.
16) Re-creating a .dat file from a .ufs file has been improved and various
“glitches” repaired. However, it needs to be borne in mind that the facility
does not necessarily cope with all the most obscure options available within
network coding (particularly the most recently added features) and that a
“perfectly cloned” .dat file may not always result.
D.13.2 MX
1) The bat files MXM5 and MXM7 which were included in SATURN versions
prior to 10.3 have been resurrected.
2) The options to edit the zone structure of a matrix have been extended and
generally tightened up so that it is easier to edit stacked matrices (although
not necessarily recommended).
3) The matrix build batch file MXM1 now allows the input “data” file to have any
extension, not just .dat, although .dat remains the default. Thus the
command “MXM1 trips.kp” will read from the file trips.kp.
4) The batch file mx.bat now includes an extra keyword “OUT” to define the
output .ufm matrix and the options which may be used in conjunction with
“MX I” have been extended to include all standard keywords, e.g., including
OUT. 10.16.
5) A CSV input option is included under the M5 option for .ufm outputs.
Appendix W.3.
6) The maximum array dimensions for rows and columns have been modified
such that the maximum number of columns permitted is 3 times the
maximum number of rows. This means that, with the maximum number of
zones for your SATURN level, a matrix with three stacked levels may be
processed by MX.
D.13.3 SATNET
1) A new parameter ILOVEU allows U-turns at external simulation nodes
connected to buffer nodes to be either fully accepted or banned (as far as
possible). Previously U-turns were always banned, although not with a 100%
guarantee. 18.9.
2) Extra checks have been included on signal settings/lane choice that may
impede convergence.
5109341 / Mar 13 D-70

11_2_05_App D.docx
3) Zones for which sectors have not been explicitly defined are now assigned
to sector 0. (But only when some sectors have been defined; if no sectors
are defined all zones default to sector -1.)
4) The rules concerning the definition of Y-merges have been tightened up to
avoid confusion between entry ramps on a motorway (for which a single M is
advised) and the merging of two motorways (for which 2 M’s are allowed).
5) Namelist input is checked as to whether the same variable “name” appears
more than once and a semi-fatal error generated if so. (In fact the check is
done automatically for all namelist inputs but is only semi-fatal in SATNET.)
Note 17, Appendix A.
6) The pre-load input file may now either a .ufs file (as before) or a text-based
file containing link identification and flows. In other words it is no longer
necessary to set up the pre-loaded flows via a SATURN run, they may be
obtained directly from some other data source. 15.5.4 and 14.4.4.
7) Both the UPDATE and PASSQ options may be used simultaneously and a
new input &OPTION parameter PQFILE has been introduced in order to
define the PASSQ input file (in addition to UPFILE for UPDATE).
8) Minimum and maximum green stage lengths (as used during signal
optimisation) may now be defined within the network .dat files and/or edited
within P1X. See 6.4.13 and 15.31.
D.13.4 SATALL
1) A new option “AUTOK” has been introduced which removes the need to set
KOMBI in advance and which appears to considerably improve the
convergence of the assignment-simulation loops. AUTOK automatically
selects the “optimum” weighted average of two successive loops as
opposed to KOMBI which uses a fixed 50:50 average whether or not it is
actually required. 9.3.2.
2) New default values of the blocking back parameters set at the start of each
new simulation are based on the previous blocking back factors plus latest
assigned flows in order to reduce the time taken to calculate blocking back
factors and to improve convergence when the changes to the assigned flows
are small (as occurs under AUTOK).
3) The transfer of delays between the simulation and the assignment, i.e., the
creation of new cost-flow curves following each simulation, has been
“tightened up” in a number of relatively minor ways which, in some cases,
allows improved convergence.
4) A potential (and hopefully rare) problem of using the REDMEN option in
conjunction with frozen cells (ICING = T) has been spotted and dealt with.
7.5.6.
5) A measure of the strength of the relationship between (aggregate) network
travel times and trip matrices which conforms to the parameter “g” as used
by VaDMA (paragraph 4A11 in Appendix 4A) is now calculated at the end of
5109341 / Mar 13 D-71

11_2_05_App D.docx
every assignment. It is printed out in the .lpt files and may also be accessed
via the “Convergence etc.” statistics in SATLOOK/P1X. 7.11.11.
6) A new “convergence” table has been introduced into .lpt files which shows
the 10 biggest changes in blocking back factors from one loop to the next
D.13.5 SIMULATION
1) APRESV, as used to control lane choice for merges, is now handled slightly
differently. i.e., it’s improved and has more impact!
2) A new turn-based variable has been added which, for signalised junctions,
monitors the ratio of delay with signal co-ordination to signals without co-
ordination. This is also one of the “tightening up” measures referred to in
note 4 under SATALL which can lead to improved convergence.
3) X-turns at signals (i.e., traffic which gives way to straight ahead opposing
flows in the same stages) are handled differently when the opposing traffic is
being blocked back from its exit link. Previously it was assumed that the
opposing traffic flowed continually across the junction at its maximum rate
and did not leave any gaps for the X-turners. 10.4 assumes “yellow box
conditions”, i.e., that the opposing traffic only crosses the junction when
there is space downstream and that therefore it leaves gaps for the X-
turners. 8.5.2.
D.13.6 ASSIGNMENT
1) The total U-turn flows through external simulation nodes is now recorded
and stored on the .ufs files. 18.9.
2) Output Tij matrices from incremental elastic assignment (i.e., MCGILL <10)
now include input intra-zonal trips unchanged. 7.4.4.
3) Uncertainties regarding what happens under elastic assignment for O-D
cells which have positive trips input but which are unconnected have been
resolved. Thus (as with intras above) they are included in the output trip
matrix at their input values under simple incremental demand models. See
7.5.7.
D.13.7 SATDB
1) The minimum number of data columns has been increased from 5 to 8.
2) SATCOBA now accepts a control file as input which allows a choice of
certain options and/or parameters to be set. 15.42.2.
3) Turn data may now be aggregated to link data by their exit link as well as
their entry link, i.e., turn A-B-C is added to link B-C as well as A-B.
4) New “skimming” .bat files SKIMTIME, SKIMDIST and SKIMTOLL have been
created in order to automatically skim average time, distances and tolls from
a network .ufs file. 15.27.4
5109341 / Mar 13 D-72

11_2_05_App D.docx
D.13.8 SATME2
1) “Frozen zones” may now also be defined as “frozen sectors”; similarly
frozen i-j cells may also be defined at the sector level. 13.2.2.
2) Table numbers have been inserted in the output .lpm and are cross-
referenced within the Manual.
3) A new parameter ODXMAX is introduced which in effect frees the o-d
balancing factors from the upper/lower limits set by XAMAX. However, if you
need to use it, it probably means that you need to look more carefully at your
inputs. 13.3.1 and 13.3.2.
D.13.9 SATPIJA
A new option PIJAKP allows the PIJA factors to be output as a text file (default
extension .kp) in addition to the .ufp file output. The option is useful if it is desired
to transfer PIJA data to another suite of programs or, e,g., EXCEL.
D.13.10 SATOFF
A new parameter MANOFF (MAster Node for OFFsets) has been introduced
(12.2.3) which “fixes” the offset for a particular signalised node such that all new
optimised offsets are taken relative to that point. The change is purely cosmetic
and does not affect the simulation.
D.13.11 SATWIN
1) A direct link to the SATURN Website has been included on the SATWIN
interface.
2) Dropdown boxes have been introduced for the various Settings choices,
allowing, for instance, users to select previously used Working folders more
conveniently. An edit function also lets users delete previously used folders
from the lists. The default file editor may also be changed through the
Settings option.
3) Lines in the ‘Events Log’ window may now be edited directly to change or
correct commands.
4) Any command may be typed directly into the ‘Events Log’ and executed
immediately. This can include functions such as Notepad for network editing
eg. Notepad LIV10.DAT
5) A direct call to DRACWIN, the DRACULA front-end, is available to users
from the main SATWIN Toolbar.
5109341 / Mar 13 D-73

11_2_05_App D.docx

Date of last Update: 11 November 2004
SATURN 10.5 was first released in Beta version (10.5.1) in November 2003 and
as a full release (10.5.10) in October 2004. The following new features are to be
noted. (Note as well that the documentation has been extensively updated to take
account of these new features and references to the relevant sections of the
manual given.)
D.14.1 P1X
1) Arrows added to bus lanes in node graphics.
2) An option to define the default title as filename + date in addition to network
title + date added.
3) Link data for annotation sub-divided into 5 sub-sets and the order of items
rationalised (plus several new items added). 11.6.2.1.
4) Maximum transient queues by links, turns and lanes added within
SATLOOK simulation node analysis options.
5) Various improvements/bug fixings have been added to PMAKE; for
example:
♦ giving warnings when negative co-ordinates are generated;
♦ making sure that new nodes without connections do not disappear

when the plot is refreshed;
♦ making sure that altered junction types appear correctly on refresh plots
♦ creating new nodes outside the min/max boundaries of the current

network and/or windowed plot;
♦ ensuring that text Namelist parameters are not repeated in output .dat
files;
♦ making it easier to convert external simulation nodes to full internal

simulation nodes;
♦ when a simulation link is deleted any associated centroid connectors

are edited interactively rather than automatically;
♦ newly created buffer centroid connectors are assigned a capacity index

of 0;
♦ adding and deleting centroid connectors within the simulation network

(i.e., the 22222 data records) which has its own sub-menu may now be
done (partially - to external simulation nodes only) within PMAKE
Add/Delete Links (18.7);
♦ curved links (as per GIS files) may be immediately defined as new links
are added (see also note 15 below);
5109341 / Mar 13 D-74

11_2_05_App D.docx
♦ GIS files may be created at the same time as new networks are being
created and the user is prompted to save such files before exiting;
♦ Duplicated curved links are reported if and when a new definition is

initiated and, when inputting from a GIS file, the first definition is always
used by default.
6) The list of the 10 worst converged simulation nodes from SATALL is now
also given within the standard convergence statistics in P1X and/or
SATLOOK.
7) An option under “Select” for either link or node display allows either the “top
ten” (i.e., the 10 links or nodes with the maximum property) or the “bottom
ten” (minimum property) to be selected for display. 11.6.1.1.
8) Link data under node graphics has been (a) “re-organised” into different sets
and (b) had extra data sets added; e.g., it is now possible to display all the
data contained in the data base. (Useful for examining multiple networks
where you can, e.g., look at link flows in all networks simultaneously by first
adding them to the data base.
9) The lines used for node shapes (e.g., circles for roundabouts) may now be
assigned a “width” which makes them stand out better with bitmap
backgrounds.
10) The colours used to display zones may be set according to zone sector
numbers to make it more obvious which zones are in which sectors.
11.6.5.1.
11) SATURN users who are also DRACULA users may now either run the
demo versions of DRACULA or their own full versions from within network
cordoning and node graphics.
12) At the end of any DRACULA run (either full or demo) the user may choose
to view any of the standard text output files from that run within text
windows.
13) Simulation centroid connector (22222) data sets may now be screen edited
under network editing. 11.9.4.
14) The “intensity” of background .bmp files can be reduced in order to make the
P1X display more prominent. (Especially useful within PMAKE.) 15.43.6.
15) GIS editing is now more closely integrated into the network editing options
so that, for example, curved links may be defined within PMAKE / Link Edits,
either for existing links or, in particular, when a new link is first created.
18.6.1.
16) Nodes converted from buffer to simulation under PMAKE may now have
extra records representing link capacity restraint added automatically based
on the buffer link properties. This allows a “quick and dirty” conversion
which is not necessarily recommended. 11.9.12.
17) Lane turning arrows in P1X node graphics are assigned a user-set width.
5109341 / Mar 13 D-75

11_2_05_App D.docx
18) GIS curved links may now be drawn as the partial arc of a circle by defining
a centre of curvature as opposed to a set of explicit points. An extension is
to define a set of links which constitute a closed loop as a full circle, e.g., to
correctly represent roundabouts which have been broken down into a series
of sub-nodes. 5.7.3.
19) The edit options to optimise signals and transplant signal timings are now
“grouped” into a single “Global Operations to Signals” sub-menu which has
been extended to include the “update” option described next.
20) Signal stage times and/or offsets may be “updated” from the .ufs file to the
internal .dat file under Network Editing, specifically so that changes made in
SATALL by using either SIGOPT or SATOFF parameters or in SATOFF
may be transferred into a .dat file.
21) The set of available bus-based link flows for annotation has been increased
to include, e.g., entry flows upstream and downstream.
22) Isochrones may now be output much more quickly by plotting different
coloured circles at zones and/or nodes in order to denote equi-distant bands
from the origin or destination. 11.8.3.4
23) Link flows at the downstream stop line, both demand and actual, have been
added to the standard list of link annotation choices. These may be used in
preference to the existing link flows which, in the case of simulation links
which are “bridged” by centroid connectors, are the mid-link flows.
24) Namelist parameters changed via P1X network editing (e.g., changing
ISTOP) may (optionally) now be included on an output .ufs file. Useful for
changing parameters prior to doing a continuation run with SATALL, for
example. 11.9.11 and 9.12.2.
25) A “select” option has been added to the turn annotation based on the node
selection in force. 11.6.5.3 and 11.6.6.
26) Select Link Analysis of Screen Lines has been extended in two ways. Firstly,
the screen line may be defined using a 7777 input data set or as the
currently selected links (as also available within SATDB SLA) and also as
an input (free-format) file. Secondly, the “selection” criteria in the event of
multiple crossings may be set either to a minimum or an exact number of
crossings and the critical number of crossings may be varied. 11.8.1.8 and
11.8.1.9.
27) Under the choice of link annotation (flows) the first three user classes are
explicitly listed for both actual and demand flows. 11.6.2.1
28) The “line drawings” of simulation nodes as included within a network plot
have been re-scaled so that the lane widths etc. at the junction are at the
same scale and line up with the lanes plotted on the links. See also #37
below. See 11.6.4 (7) and 11.6.5.1 (4).
29) The format of the .rgs files has been changed such that the cycle time is
included as well. 11.9.14.
5109341 / Mar 13 D-76

11_2_05_App D.docx
30) The bandwidth colours for one plotted variable, say flows, may now be set
with reference to a second variable, say speed. 11.6.3.4.
31) The numerical value printed outside a bandwidth now takes the same pen
colour as the bandwidth plot.
32) If, say, the differences in flows between networks 1 and 2 is being plotted
and a link in network 1 is not present in network 2 it is now possible to define
a default flow for the missing link, the obvious value being zero. Previously
no data at all was plotted for the unmatched link. 11.6.2.4.
33) Saved Windows co-ordinates (as in .wxy files) may now have a text name of
up to 28 characters recorded on creation to assist in later identification.
11.5.2.
34) The Information menu prints comparative simulation summary statistics for
either multiple networks or multiple time periods (as already available in line
printer or terminal output from SATLOOK). 11.8.4.4.
35) Count validation statistics of multiple count sets (“disaggregation”) may now
be applied to a single set only. 11.7.1.
36) The positions of the pop-up windows which are used, e.g., to set device
parameters, are now centred better by taking account of the screen
resolution.
37) The angles of the arms as used under basic node graphics are now
determined by the initial directions of any curved links defined within GIS
files, not simply as “crow fly” to the adjacent node. 11.6.5.1(4).
38) The preferences file P1X0.DAT has been reformatted with one entry per line
and with an explanatory text added as a comment at the end of each line (or
some lines – work in progress!). 11.4.3.
39) If a timed route has been included within the 66666 routes which is not a
bus route (i.e., it has a frequency of zero) and it uses one or more links with
bus lanes then the times/delays on those links taken within a joy ride are
now the “car” times/delays rather than the bus lane times/delays as was
previously assumed.
40) A new “menu entry” has been added at the top level, “Convergence”, whose
objective is to display data relating to the convergence of the assignment-
simulation loops. To a certain extent it contains the same information as
given under option 8 in SATLOOK or the convergence option within P1X
Information, but broken down into smaller chunks. However it also contains
a number of new convergence indicators such as 42 below as well as a
useful short summary table of the main convergence indicators for one or all
of the input networks. 11.15.
41) The definition of the blocking back factor BBF displayed as link data has
been “reversed” so that it is now 1.0-BBF that is plotted (as a percentage)
instead of BBF. Thus if a link is not blocking back, in which case BBF = 1, a
value of 0 is displayed; but if a link is strongly blocking back, say BBF = 0.2,
then a “positive” value of 0.8 (80%) is displayed. This makes it much easier
to identify those links that are blocking back.
5109341 / Mar 13 D-77

11_2_05_App D.docx
42) A table listing the 10 biggest changes in blocking back factors over the final
two assignment-simulation loops is included both within the Convergence
Statistics within Information and within the Convergence Menu (#40 above).
The same table appears in the .lpt files.
43) The KEY and VDU commands on the command line may now be combined
into a single keywork KEYVDU such that “KEYVDU X” is equivalent to “KEY
X VDU X”. Useful if the command line is near its maximum number of
entries. 14.5.1.
44) Select Link Analysis may now be based on a network other than the “base”
network 1 provided that the second network is structurally identical to that on
network 1. 11.8.1.7.
45) A (normally hidden) message has been added whenever you go from the
graphics screen to the text screen (e.g., when entering SATLOOK) such
that, if the text screen is automatically maximised (as it should be), the
message is hidden; if not, the message tells you to maximise it yourself.
46) The “rubber band” rectangle which indicates the choice of a new window
under Boxes now has a 2 mm width if there is a background bmp file (so that
it is more prominent).
47) Links which have been selected as part of a screen line under Select Link
Analysis may be “de-selected” by clicking on a link which has already been
selected.
48) Cumulative penalty times (i.e., 44444 data) and tolls are now included in the
joyride tables in the .lpp files as well as being listed in the banner.
49) The list of link properties which may be annotated has been extended to
include:
♦ Blocking Back Factors from the previous assignment-simulation loop;
♦ The differences between the last two sets of blocking back factors;
♦ The previous set of assigned demand flows;
♦ differences between the last two sets of demand flows.

All of these are useful in assessing assignment-simulation convergence.
D.14.2 MX
1) If sectors are used and certain zones are undefined (sector = –1) then an
option is added to convert their sector definitions to 0 (which, post SATURN
10.4, is the standard default value for undefined sectors).
2) However it may be somewhat difficult to have undefined (-1) sectors in the
first place since any input values of –1 (presumably from pre 10.4 network
files) are automatically converted to 0 on input in order to conform with what
SATNET does.
5109341 / Mar 13 D-78

11_2_05_App D.docx
3) A new batch file MXWEIGHT has been added to take a weighted average of
two .ufm matrices (as opposed to MXAVER2 which always takes a 50:50
average). 10.20.12.
4) The control (text) file used to input Furness trip ends may be in CSV format
as well as fixed format to avoid any problems with the number of decimal
places being limited. (In fact all numerical inputs into MX should now not be
restricted in this way.) 10.7.5.
5) The options to “dump” to ascii/text files now explicitly includes Tuba Formats
1, 2 and 3 (but with some limitations). 10.15.
D.14.3 SATNET
1) Extra warnings have been added to deal with the improper use of the
parameter KINKY (i.e., setting KINKY = F is bloody dangerous!)
2) Warnings identify the situation where a namelist variable name is correctly
identified but the wrong data type is used; e.g., a text parameter is assigned
an integer value.
3) The rules whereby bus routes are allowed / not allowed to make U-turns
have been made (hopefully!) more realistic. This may also affect the way in
which routes are interpolated between non-adjacent nodes.
4) An explicit check has been added on the maximum number of KNOBS, 8.
5) FORTRAN read errors encountered when processing extra KNOBS data
lines within the 33333 records are now semi-fatal errors.
6) A new parameter (FREEKY) has been added to allow KNOBS data to be
read in as “free format”, e.g., in CSV format.
7) Extra error checks are incorporated when reading 33333 KNOBS data, e.g.,
that there are not multiple entries in a single block of 10 columns. (Which
may happen if the record being read is in fact a new link record, not a
KNOBS record.)
8) Users may wish to note that 5-digit zone “names” are now permitted – and,
in fact, have been for some time although not documented. 5.1.6.
9) The extra line input following a simulation link record to define a link speed-
flow or capacity-restraint function may now explicitly code an ‘S’ or ‘T’ in
column 29 to indicate whether the two data fields in columns 11-15 and 16-
20 are speeds or times. If blank the parameter SPEEDS decides. This
means that buffer network 33333 link records may be copied directly for this
purpose without worrying about whether they use the same conventions
about speeds/times as simulation link records. 6.4.12.
10) Completely blank lines in network .dat files are now explicitly detected and
treated (mostly) as comments. Previously they were read as blanks (doh!),
i.e., one or more zeros, which might cause fatal or semi-fatal input errors, for
example if they were link count records which had to contain non-zero A-
node and B-node entries. The one exception to this rule is KNOBS data
contained on a separate line following a buffer link, in which case a full set of
5109341 / Mar 13 D-79

11_2_05_App D.docx
zeros is a legitimate input. (Previously blank lines were explicitly detected

and ignored under 33333 records only.) 15.29 and 15.14.5.
11) The rules concerning capacity-restraint data on links from an internal
simulation node to an external node which have been coded within both the
11111 and the 33333 data segments have changed such that the 11111
data is always used independent of FIFO. 6.15
12) The option to “UPDATE” using a previous network has been improved such
that a much better initial simulation-assignment convergence may be
obtained using UPDATE. See also D.14.7 (3). 15.3.
13) A new semi-fatal error has been introduced if, with multiple user classes, a
user class definition does not appear within the 88888 data records (or if,
less likely, the same user class appears twice).
14) An error check (Serious Warning 139) has been introduced to detect X
priority markers at priority junctions which have apparently been coded on
the wrong arm and which can cause a straight ahead major movement to
give way to opposite turning traffic. The results can be catastrophic! (And
found to occur in real networks which have been apparently well validated.)
See 6.4.2.2.
15) A further error check has been introduced (Serious Warning 137) to detect
inconsistent saturation flows per lane (e.g., a left turn been given a
saturation flow of 2,000 and the straight ahead being given 1,500 which
might indicate that the numbers have been swapped around). The “rules”
are essentially arbitrary but it is hoped that they will help to detect “gross”
coding errors. See 6.4.6.3.
16) The default values of certain namelist parameters have been changed from
their “historical” to their (previously) “recommended” values. The reason why
they had not previously been changed was to ensure upwards compatibility
with older versions of the programs. However, given that 10.5 is unlikely to
give exactly the same results as previous versions (see, for example,
D.14.5) it seemed to be a good moment to make these somewhat overdue
changes. The parameters affected and their old and new values are listed
below:
♦ BEAKER from F to T
♦ SHANDY from F to T
♦ ISTOP to 95 from 90
♦ MAXDTP to 10 from 0
♦ MAXQCT to 60 from 0
♦ NISTOP to 4 from 1
D.14.4 SATALL
1) The table printed at the end of each assignment-simulation loop listing the
10 turning movements with maximum differences in delays has been
5109341 / Mar 13 D-80

11_2_05_App D.docx
updated to include current and previous capacities and cross-referenced to

the SATURN manual.
2) Maximum transient queues per link and turn are now calculated and
recorded for every simulation node.
3) An extra line has been added at the bottom of the “on screen” window during
execution listing the values of MASL, NITA, etc.
4) An improved method for including signal optimisation stages (either
SATOFF or SIGOPT = T) within the simulation / assignment loops has been
introduced. The new method carries out a fully converged assignment /
simulation loop before optimising the stages and/or offsets and repeating the
“outer” loop. The process may be repeated a small number of times (as
controlled by a new parameter NIPS). 9.12.2
5) Setting ICING = T but failing to define an input frozen trip matrix (which can
be done either using FILICE in the .dat file or FREEZE on the command
line) is detected as a fatal error. Equally if both FILICE and FREEZE are
used the file set by FREEZE is used and a message to that effect is given in
the .lpt file.
6) Flows which enter and leave simulation links at “the wrong ends”, for
example bus flows when UPBUS = T, are more tightly controlled, avoiding
potential reporting errors with link flows.
D.14.5 SIMULATION
1) Minor improvements made to the “yellow box” rules whereby X-turners at
signalised junctions are opposed by traffic which is blocked back. See 8.5.3
and point 3 under Simulation in Appendix D-13.
2) A number (but not all) of the new simulation options introduced in 10.4 may
now be excluded by setting NFT = 103.
3) The internal convergence of priority junctions with shared lanes has been
improved in certain (probably not very common) situations where there is a
local “surge” in arriving traffic, due, for example, to traffic signals very near
upstream.
4) Blocking back rules have been changed in a number of ways to deal with
situations where what is, in effect, a single link is coded as a series of links
through 2-arm nodes (e.g., by including mid-link pedestrian crossings).
Firstly, if the node at the upstream end of the “full” link is an external node
then no blocking back is modelled at the downstream end. Secondly, if the
“full” link ends at another internal simulation link then the stacking capacity
considered is the sum of the stacking capacities of all the links in series.
8.5.4.
5) A potential problem in the lane-sharing sub-model has been corrected (see
note 24 in the list of Bugs in 10.4) and will lead to marginally different results
between 10.4 and 10.5 (as do points 1 to 4 above as well).
5109341 / Mar 13 D-81

11_2_05_App D.docx
6) Random delays may now be applied to both “give-way” or “minor” turning

movements as well as “major”, although the overall impact on existing
networks is likely to be small. See 8.6.2.
7) An error in the calculation of delays has been detected under networks with
PASSQ = T for turning movements which share lanes. Thus if there is an
initial queue at the start of the time period within the shared lanes and the
relative proportions of turns within the shared lane(s) has changed from the
previous time period then the over-capacity delay component may differ
(possibly significantly) between turns whereas, since the queue is a common
queue, the delays should be equal. The greater the change in proportions,
the greater are the differences in delays. This has been corrected by
calculating all over-capacity delays in shared lanes based on the shared
queue and a common V/C ratio.
8) For networks where PASSQ = F the V/C ratios should be identical for shared
lanes so that the effects should be minimal. However small differences on
early iterations, where the simulation convergence is less than perfect, may
affect the overall “convergence path” and lead to small differences in the
final results.
9) As a consequence of 7 and 8 the rules governing simulation turns which
share lanes and are over capacity have been tightened up to insure that all
turns in the shared lane(s) have exactly equal V/C ratios. Equal V/C ratios
has always been the objective in such situations, but certain (fairly rare)
circumstances have been identified in which they do not and small
inequalities which were previously tolerated have been corrected.
10) The net consequence of changes 7, 8 and 9 is that the simulation in 10.5
gives slightly different – and, in principle, “better” - results from previous
versions. An extra logical parameter Q105 has been added to allow the old
rules to apply if Q105 = F and, the new rules, if Q105 = T. 8.4.7.
11) A new set of parameters has been added to measure the convergence of
each internal simulation node in terms of its IN profiles (i.e., the “between-
node” convergence) in addition to the traditional convergence of OUT
profiles (which measures both “between-“ and “within-node” convergence).
8.3.3.
12) The calculation of flow-delay curves has been tightened up for turns which
(a) are heavily over capacity in the current time period and (b) have very
large initial queues from PASSQ such that MAXQCT is invoked in both. The
objective is to ensure that the delays calculated by the simulation and by the
assignment agree. This can improve the convergence between the two sub-
models. See also point 2 under D.14.7 as well as 8.4.6.
13) A new parameter NITS_M has been introduced to set a minimum number
of simulation iterations. This may be used to help to obtain very high
assignment-simulation convergence levels which are otherwise limited by
the simulation converging after only 2 or 3 internal iterations as the overall
process nears convergence. (This applies particularly under OBA; see
D.14.6.) 6.3.2 and 8.3.
5109341 / Mar 13 D-82

11_2_05_App D.docx
D.14.6 ORIGIN-BASED ASSIGNMENT (OBA)

A major innovation in 10.5 has been the inclusion of the so-called Origin-Based
Assignment (OBA) algorithm as developed by Hillel BarGera as a PhD student of
Prof. Dave Boyce at the University of Illinois at Chicago in the late 1990’s. His
work has 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 as traditionally used in SATURN.
OBA first became available in SATURN 10.5 through a collaboration with Hillel
BarGera and the University of Chicago but with additional licensing requirements.
Background papers are included in Appendix G and instructions for running OBA
within SATALL are given in Section 21.
OBA is particularly efficient relative to Frank-Wolfe (the algorithm normally
employed within SATURN) in assessing the impact of small “schemes”. If the
assignment is less than perfect then the change in, say, total vehicle-hours due to
the scheme may be totally masked by the intrinsic “noise” in the with- scheme and
without-scheme solutions. By making the assignment extremely accurate OBA
allows the impact of even very small changes, such as the addition of a single
lane or changes to signal timings, to be accurately measured.
D.14.7 ASSIGNMENT
1) A new parameter NITA_M has been introduced which sets a minimum
number of iterations within the standard assignment methods. This may be
used to help to obtain very high assignment-simulation convergence levels
which are otherwise prevented by the assignment itself converging after only
1 or 2 internal iterations as the overall process nears convergence. 7.1.5
and 9.5.1
2) The use of MAXQCT to limit queuing delays in the simulation has also been
introduced into the assignment so that the upper limits on delay are taken
into account in working out route choice. This also potentially improves the
convergence between the assignment and the simulation. 8.4.6.
3) The number of assignment iterations on the very first assignment-simulation
loop when using an UPDATE network has been (potentially) increased in
order to take full advantage of the potential benefits of UPDATE. See also
D.14.3 (12). 15.3.
4) An extra demand-based convergence parameter for elastic assignment has
been added, TxCij-AAD, which is based on the absolute differences
between current o-d trips and the corresponding values calculated from the
o-d costs and weighted by trip costs. It is very similar to an existing
convergence parameter, TIJ-AAD, which, however, is unweighted. The new
parameter is effectively the same as that used by DIADEM. 7.5.5.
D.14.8 SATLOOK
1) The list of the 10 worst-converged simulation nodes is now included within
the standard convergence statistics.
5109341 / Mar 13 D-83

11_2_05_App D.docx
2) An extra skimming batch file, SKIMPEN, has been added to SKIMTIME etc.
in order to skim time penalties as set under the 44444 records (and which
may have been used in the past to model tolls). 15.27.4
3) Various messages have been added for simulation links where the cycle
times are different at the upstream and downstream nodes such that any
signal co-ordination is lost. E.g., 17.7.
4) The various components of the calculation of a simulated delay (e.g., delay
spent in cyclical flow profiles as opposed to over-capacity queues) may now
be explicitly printed under node data. 11.??
D.14.9 SATDB
1) The link numbers as used for setting up a COBA network may now be
created with the Miscellaneous Data Input Menu and also displayed using
P1X. 15.42.4
2) When reading data from an external ascii data file an additional data column
may be created which stores the line number for each input link. This may
be used, for example, to display the data in the same order as input (by
sorting on the line number column in ascending order).
3) An option has been added when inputting a DA column from two input files
to automatically create a third column equal to their differences. This makes
it quicker to look at, say, flow differences without having to explicitly create a
differences data column.
D.14.10 SATOFF
The batch file satoff.bat may now automatically run SATSIM after running
SATOFF in order to update the simulated cost-flow curves in order to make
repeated loops with SATALL simpler. 12.2.4. (But see also point 4 under
SATALL above for an alternative method of linking the two procedures.)
D.14.11 SATME2/SATPIJA
1) Extra documentation has been added to Section 13 of the Manual to give
(we hope!) useful advice on common problems encountered in using
SATME2; e.g. starting from a “good” prior matrix (13.1.9), what sort of
counts to include (13.3.9), etc. The added warning messages (see below)
reflect this new advice.
2) Warning messages are included in the SATME2 LPM file if the flows from
the input trip matrix differ “significantly” from the counted flows; i.e., if the
prior matrix is a poor starting point and needs to be improved.
3) Equally warning messages are included in the SATPIJA LPJ file if the set of
counts used appears to have problems.
4) A check is introduced as to whether the input prior trip matrix has been
produced by SATME2 in order to try to prevent users continually updating
matrices through multiple loops through SATME2. Doing so is now a fatal
error (although it may be allowed by explicitly setting a parameter ENCORE
to T in the namelist parameters). 13.3.5.
5109341 / Mar 13 D-84

11_2_05_App D.docx
5) A new set of (subscripted) SATPIJA control parameters SET777() allows

certain sets of input counts contained within separate 77777 data sets on
the network .dat file to be easily included/excluded from the .UFP files and
hence from SATME2. 13.2.1 and 13.3.8.
6) Useful data from a run of SATME2 (e.g., XA balancing factors) is dumped
onto an ascii data file (extension .me2) which may be read by P1X to
provide extra insights into what has happened within SATME2. 13.8 and
11.8.5.
7) Link flows as input on a SATPIJA control file are read essentially as free
format, not – as before – as integers within 5 fixed columns. 13.2.1.
8) Counts may now be combined together (e.g., from parallel roads, over a
screen line, etc.) such that the constraint is on the total flow over all links,
not on individual links. 13.1.8.
D.14.12 SATCOBA
1) An option to add together the link flows from two or more input “networks”
(presumably different time periods during the same day) and output a single
weighted flow as opposed to the full set of multiple flows is now available.
15.42.2. (In fact this was the original intention of SATCOBA and what the
manual says it does!)
2) An extra table of link turning proportions (COBA KEY 082) has been added.
This is useful for generating accident statistics. 15.42.1
3) Extra documentation describing how to display the link numbers generated
by SATURN for coba links within P1X has been added. 15.42.5
4) Link flows on simulation links which are “bridged” by centroid connectors
may now either be defined as mid-link flows or (the recommended default)
as stop-line flows at the downstream end (i.e., to include entry flows from
centroid connectors). Parameter MIDLF. 15.42.2
5) The necessary “knobs” data to define user-specified link numbers may now
be input directly to SATCOBA rather than through SATNET. 15.42.3
6) Documentation explaining how to use a common system of link numbers for
both, e.g., “do-minimum” and “do-something” networks using KNOBS data
has been added. 15.42.4.
5109341 / Mar 13 D-85

11_2_05_App D.docx
DATE OF LAST UPDATE: 16 JANUARY 2006

SATURN 10.6 was first released in Beta versions during 2005 (with temporary
version numbers 10.6.1 thru 10.6.12) and as a full release (official 10.6.14) in
March 2006. The following new features are to be noted. (Note as well that the
documentation has been extensively updated to take account of these new
features and references to the relevant sections of the manual are given.)
Items added after the original release of 10.6.14 are given in italics.
D.15.1 P1X
1) An option to select from multiple count fields added in the plotting options
under Validation/Counts
2) Select Link Analysis may now be undertaken for “All OD pairs”, i.e., with no
test on whether or not an OD pair should be included;
3) The width of a lane (which defaults to 3.75 m) may be altered with the effect
of making the roads appear wider when plotted with explicit lanes; the same
effect applies to junction line drawings. 11.6.4(8).
4) Various options to calculate and display the “worst” O-D paths in terms of
having the maximum cost in excess of the minimum have now been added.
These help to identify where convergence problems are arising
5) Options have been included under Node and Link Information to list all the
link data currently stored in the data base.
6) The input format of curved links on .gis files (77777 data) has been modified
such that it is no longer strictly necessary to include blank records at the end
of links where the number of X,Y points is a multiple of 4. This may make it
easier to import data from external data sources such as Mapinfo files, etc.
Appendix Z, BLOCK 7.
7) The convergence options will now print the standard convergence tables 1
and 2 for all input networks (if more than one).
8) Enclosed polygons in GIS files may now have a line width associated with
them. Appendix Z, Block 1.
9) The “intensity” of a .bmp may now be defined within its .xyb file. 15.43.6.
10) Plotted count data under Validation/Counts may now be selected by the
7777 set number in the same way that selection may be done under “Go”.
11) The “link selection rules” may now be applied to the analysis of counts under
Validation/Counts.
12) Links selected under Information may now either be 1-way or 2-way; in the
latter case, once selected, the properties of both directions of a link are
given.
5109341 / Mar 13 D-86

11_2_05_App D.docx
13) Link information now lists all bus routes which go through that link.
14) An Appendix I.1 has been added which lists (or will eventually list when it is
finished) all the various link data items available in P1X with a potted
explanation of what each contains. Similarly Appendices I.2 and I.3 list node
and turn data respectively..
15) Extra simulation link data is provided, for those links with capacity-restraint
speed-flow curves defined, to differentiate delays associated with the link
capacity restraint, those associated with turning movements at the stopline
and the sum of the two. Previously what was being plotted when was
somewhat ambiguous in that situation (it was actually the sum although it
was misleadingly titled “delay at jcn”).
16) A negative link width by capacity index implies that links with that capacity
index will not be plotted. The negative values may usefully be input via the
preferences file to automatically suppress the plotting of certain classes of
links. 11.6.4, note 4.
17) Under Node Graphics it is now possible to output some of the numerical
SATLOOK-based tables (E.g., the table of turning flows and delays) directly
to windows which may be cut, pasted etc.
18) Hard copy plots are now scaled to use 100% of the plotter paper if required.
Previously only 95% was used. This is probably only important if a .bmp
background file is being printed as well since, previously, the .bmp file was
scaled to 100% and therefore came out 5% larger than the network plots.
19) As mentioned above, 18, hard copy outputs may now include .bmp
background files to the correct scale. 15.43.4.
20) The main Window bar choice “Back”, which previously had two pull-down
sub-menus for either going “back” one level or going directly to an option in
the “master menu”, now appears as two separate items in the Window bar –
“Master Menu” and “Up1”. Up1 is equivalent to “Return” or “Quit” in the
banner and has the advantage that it always remains in the same position to
make multiple returns simpler.
21) Three extra link data items have been added under “Times” in P1X in order
to display the value of CLICKS per link, the extra time penalty per link due to
CLICKS and the cruise speed with CLICKS included. 10.6.16.
22) Improvements have been made to prevent the “Master Menu” and/or “Up1”
options on the Windows command bar line from being “greyed out” when
they need not be. 24/05/06
D.15.2 MX
1) The outputs obtained from dumping “Grand Matrix Totals” have been
extended, particularly with multiple matrices with multiple levels
2) New “batch” procedures UFM2CSV etc. have been introduced in order to
easily “dump” .ufm matrix files into “text” or “ascii” with a number of standard
formats; e.g., UFM2CSV creates a CSV file for transfer into Excel,
UFM2SATL dumps into the standard “long” SATURN format, etc. 10.20.13.
5109341 / Mar 13 D-87

11_2_05_App D.docx
3) Equally CSV2UFM automatically builds .UFM matrix files from a CSV text
input such that, by combining with UFM2CSV, it becomes much easier to
transfer SATURN matrices to and from, e.g., EXCEL. 10.20.14
4) The number of decimal points used to “dump” matrices to text files under
Tuba formats 2 and 3 is now user-defineable. The number may also be set
by default in the MX preferences file mx0.dat (using namelist parameter
name NDPS). 10.15.2.
5) Equally matrices may now be “text-dumped” with E-formats (e.g., 0.602E+02
as opposed to 60.2) and a user-set number of decimal points with most
output formats (i.e., not just Tuba formats). The advantage of E-formats is
that all output numbers have the same “precision” independent of their
absolute value.
6) Explicit options to read in text files with Tuba formats 1, 2 and 3 are now
included. 10.5.6.
7) The standard “batch” procedure MXM1 (aka M1) will now read data files in
which the standard header records are combined with cell values given in
CSV formats (which therefore includes Tuba Format 1). This facilitates the
direct input of matrices from other suites of programs such as EXCEL. 4.4.
This option uses a new Namelist parameter KROPT (to be documented
eventually within 10.5.1).
8) The “automatic” batch procedures such as MXFACTOR, MXSTACK, etc.
have been modified to be 100% background. Previously they would open a
terminal screen and write file details to it; they now create a file dummy.vdu
instead so that they function in the same way as KEY + VDU. N.B. Similar
changes have been made to batch files using SATLOOK and SATDB etc.
9) The facilities to create a .ufm file by reading a text file with one record per
line have been improved, in particular to allow stacked matrices to be
created in this manner with the level explicitly input. 10.5.3.
10) An option to allow “lines” of row and column zone names to be embedded
within the screen display during screen editing (as opposed to only
appearing at the edges of the display) has been introduced. Equally buttons
to shift the screen edit area up, down, left and right have been added.
Version 10.6.15 07/03/06.
11) The batch file MXSTACK will now accept up to 8 input matrices to be
stacked; previously the (unstated) maximum was 7. May 2006.
12) New batch files STACK and UNSTACK have been added with consequent
changes to MX. UNSTACK automatically unstacks a stacked matrix mat.ufm
into square matrices mat1.ufm, mat2.ufm, etc. while STACK does the
opposite, i.e., creates a stacked matrix mat.ufm from mat1.ufm, mat2.ufm.
This avoids having to explicitly name the sub-matrices. Both require the
10.6.17 version of MX. 03/06/06. 10.20.11 and 10.20.12.
13) The “internal” unstacking option within MX now offers three options for
naming the output unstacked matrices: (1) fully interactive (as now); (2)
mat1.ufm, mat2.ufm … where mat.ufm is the matrix being unstacked, or (3)
5109341 / Mar 13 D-88

11_2_05_App D.docx
root1.ufm, root2.ufm where “root” is defined independently of current matrix

names. 03/06/06. 10.17
14) An “XCL” option has been added within MX whereby an eXtra Command
Line can be added to the MX batch files to enable more than 9 arguments to
be called on the command line. Section 14.8. 25/05/06.
D.15.3 SATNET
1) Extra arrays in the output .ufn/.ufs etc. files contain a list of all link tolls (as
opposed to previous versions where only the tolls entered under 44444 were
explicitly stored). This means that a number of analysis options such as Joy
Rides in P1X now give complete summations of link tolls en route.
2) A new semi-fatal error has been introduced whereby, if the network and the
trip matrix have the same number of zones and the zones in each are
“named” (i.e., they have non-sequential numbers), the same zone name
appears in different positions in both. 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 3rd zone. Highly suspicious! 5.1.6.
3) If UPDATE is set to .TRUE. in &OPTION but no update file is explicitly set
(either via UPFILE or the command line) then the program looks for a .ufs
file with the same root; ie., after ‘SATNET net’ it seeks to update the file
net.ufs. This ensures that if a network data file net.dat is being continually
edited each new version will be updated with the results from the last run of
SATALL with (hopefully) reductions in the subsequent SATALL run times.
4) A new option WSTART (for Warm START) has been included within
&OPTION to enable the first assignment to be a “warm start”, i.e., one which
commences from a previous assignment solution. In addition the
documentation and advice relating to warm starts has been enhanced and
users are strongly recommended to read Section 22.
5) Networks may now be built under ATLAS = T with only 55555 X,Y node co-
ordinate data included (i.e., no simulation or buffer links at all) in order to
prepare a network to be edited under PMAKE – presumably from an existing
data base consisting of node names and co-ordinates. 18.5.2.
6) Setting an XFILE which cannot be opened (for whatever reason) is now a
semi-fatal error, not a non-fatal error.
7) Coding the first turn from a link at signals as an X-turn rather than the last
turn (i.e., the left turn as opposed to the right turn under drive on the left) is
now a semi-fatal error.
8) BUSKER now uses a different “compressed” format for very long bus routes
in order to fit them within the maximum allowed 20 records. 6.9.2, note (10).
9) An option to define variable maximum free-flow speeds by user class, code
name “Clicks”, has been introduced. This allows, for example, heavy lorries
to have lower speeds (and therefore higher times) than cars on high-speed
motorway links. In turn this may influence their assigned route choice. 15.47.
5109341 / Mar 13 D-89

11_2_05_App D.docx
10) The total number of error checks (in addition to the specific check noted in 2
above) has been increased. Thus Warnings 80 to 85, Serious Warnings 41
to 48, Non-Fatal Errors 63 to 65 and Fatal Errors 74 to 84 are all new. Users
are strongly encouraged to check out these errors in particular in the .lpn
files. In addition, since the fatal errors have been extended, it is quite
possible that network data files that previously “passed” will now “fail” and
the necessary corrections will need to be made before that network will run
under 10.6.
11) Checks have been added for negative weights (e.g., PPM, PPK, etc.) used
under 88888. 02/06/06
12) Extra error checks have been added for potential problems reading default
speed-flow curves under 33333 with DUTCH = T. The problem is that if you
do not include the extra columns required under DUTCH the speeds etc. get
misread and it is possible that all default speed-flow curves are missed out
with no error message printed. This one has been around along as the
default speed-flow curves under 33333 have been. Corrected in 10.7.1 only.
09/06/06
D.15.4 SATALL
1) The convergence rules for terminating the assignment – simulation loops
have been extended to include both gap values and total cpu time. 9.2.3.
2) The SAVEIT assignment for a single user class now automatically uses the
PARTAN option (7.11.7) which should provide a more accurate assignment
and therefore better post-assignment analysis of route flows. 15.23.4.
3) A “morning after pill/procedure” SATUFC based on SATALL has been
created which will build a new .ufc file containing a new set of assignment
routes under SAVEIT. This can be useful if, for example, the original
SAVEIT assignment was not accurate enough or was not carried out at all
(SAVEIT = F). 15.23.5.
4) CODMIN = T (as set in the network .dat files) automatically generates a
matrix of O-D minimum costs at the end of the assignment.
5) Frozen cells may now be used with incremental distribution (i.e., ICING = T
with MCUBC = 1).
6) The WSTART (Warm Start) option now allows the very first assignment
within SATALL to be based on the flows from a previous assignment,
leading to potentially major improvements in convergence and cpu times.
Section 22.
7) Related to WSTART, assignment solutions may now be stored as “UFO
files”, a description based on OBA methodologies which enables warm
starts to be carried out even if the network and/or the trip matrix have been
modified. Section 22.3.
8) Multiple corrections have been added under WSTART as per Appendix E.4,
note 7. 10.6.15 onwards.
5109341 / Mar 13 D-90

11_2_05_App D.docx
9) Multiple corrections have been added under CLICKS as per Appendix E.4,
notes 10 and 14. 10.6.15 onwards.
D.15.5 SIMULATION
1) Print-outs of blocking back factors now differentiate between whether the
link is the first in a chain of links which block back or somewhere after the
first. This may be useful information to analyse non-convergence of blocking
back patterns.
2) Minor modifications have been introduced into the simulation of roundabouts
to deal with an extremely rare possibility that the capacity of an arm could go
to zero and cause divide-by-zero crashes. A bi-product of these changes is
an improvement in the rate of internal convergence. The “old” form of
simulation may be retained by setting an &PARAM parameter RB106 to F.
8.7.3.
3) The rules by which turning movements which are green in two successive
stages are assumed to be continuously green during the inter-green have
been extended to exclude double-phasing at pedestrian signals and the
rather unusual case of X-turns which are green in all stages. 6.4.3.
4) Various changes have been introduced in the simulation from 10.6.15 thru
10.6.17 to prevent program crashes; see item 11 in Appendix E,4. It is
expected – although not guaranteed – that these changes will not have any
effect on networks that currently run happily, only on those that currently
crash
D.15.6 ASSIGNMENT
1) A new form of distribution is introduced for stochastic assignment defined in
very general terms via a “cumulative density function”. For example, one
may use this option to define a gamma distribution, a log-normal distribution,
etc., etc. See 7.2.3.
2) The upper limits on NITA and NITA_S have been increased to the minimum
of 1001 and 4004/NOMADS so that clearly the second restriction will only
apply if the number of user classes (NOMADS) is five or greater. In addition
this restriction should only really affect NITA_S since the values used for
NITA should be much smaller than these limits anyway.
3) If both AUTOK = T and NIPS > 0 so that the assignment-simulation loops
are repeated with updated signal settings the AUTOK averaging is not
applied on the first loop post updating. May 2006. 9.12.2
D.15.7 SATLOOK
1) Total network statistics such as total vehicle-hours, vehicle-kms, etc. are
now printed disaggregated by user class for buffer-only networks.
2) Joy ride statistics as printed to the .lpl file (but not to the terminal) now
include total penalties and tolls.
5109341 / Mar 13 D-91

11_2_05_App D.docx
3) Forest skims output as text files (Tuba Formats) may now be optionally
written in E-formats and/or with a variable number of decimal points for
maximum precision.
4) The definition of “costs” either for building trees or for skimming has been
extended to explicitly include monetary tolls. This applies to be both “forest
skims” and to single minimum cost paths (options 9 and 14 respectively).
Later versions of 10.5 may contain the same facilities.
5) The output menu for simulation nodes now includes an option to print all
capacity-reduction factors associated with motorway link weaving. 15.40.8.
6) GO4IT has been added to SATLOOK0.DAT to make it easier to avoid
problems with key files and whether or not new files are automatically over-
written. 10.6.17. See also notes 3 and 4 under D.15.8 which make it less
necessary to worry about GO4IT.
7) Explicit options have been introduced to include/exclude 44444 penalty
times and/or extra CLICKS time in the definition of skimmed “time”. (See
item 13 in Appendix E.4.) May 2006. 15.24.4 and 15.27.7.
D.15.8 Key Files

1) The command line parameters KEY and VDU have been combined into a
single parameter, KEYVDU, such that, e.g., MX matrix KEY X VDU X may
be written as MX matrix KEYVDU X. The main advantage is that it can save
two parameters on a command line which, given that the upper limit is 10,
can sometimes be useful. See 14.5.1.
2) More rigorous checks for KEY files which terminate prematurely have been
introduced in order to remove potential problems of programs hanging.
10.6.15.
3) New checks have been included on incorrect key files where a file to be
opened does not exist and therefore there is no question “Do you want to
over-write this file?” but the key file contains a Y response to say Over-write.
See 14.5.9. Non-fatal error. 31/05/06
4) Similarly the fatal error that trapped the converse Key File error where a Y
line was needed (“Yes I want to over-write an existing file”) but not included
is now a Non-Fatal Error. See 14.5.9. 31/05/06
D.15.9 SATCOBA
1) The order of links at priority junctions used to output turn proportions may
now be optionally adjusted such that the first two links are, in order, major
and minor. Parameter MAJORM, 15.42.2
2) Flows from (up to 3) multiple user classes may now be output. Parameter
MUC, 15.42,2
D.15.10 SATME2 / SATPIJA

1) As with SATNET a new fatal error has been introduced such that, if the
network and the trip matrix have the same number of zones and the zones
5109341 / Mar 13 D-92

11_2_05_App D.docx
in each are “named” (i.e., they have non-sequential numbers), the same
zone name appears in different positions in both. 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! See 5.1.6
2) New statistics listing the maximum / minimum changes by O-D pair / origin /
destination are given under Table 14. These may be compared with values
of input parameters such as XAMAX.
D.15.11 SATCH
1) A new parameter INTRAS has been added such that, if INTRAS = T, any
intrazonal trips from the input trip matrix are included in the cordoned trip
matrix. 12.1.4, note (14)
2) The cordoned bus routes “respect” the use of FOZZY in that, if the nodes in
the “full” network are not consecutive but require intermediate nodes to be
interpolated, the intermediate nodes are also excluded from the cordon
routes. 12.1.4, note (15).
3) Potential problems associated with using either GONZO or explicit user-
class factors within the 88888 records have been identified and corrected.
See 12.1.6 and 12.1.7. The basic problem is that it was possible to “double
count” the effect of GONZO by including it both (explicitly) within the
cordoned network .dat file and (implicitly) within the cordoned trip matrix.
1) The Manual has been extensively upgraded and extended to cover not only
the new options listed above but also to explain in greater detail existing
features of SATURN. See, in particular, sections 4.4, 8.4.8, 9.2, 9.5, 11.15,
15.3, 15.4, 15.23, 15.27, 15.46, 21.3, 21.8, 22 and Appendix E, in addition to
specific sections above.
D.15.13 SATPIG
1) Route data is now output only to the .trp (or .kp etc.) ascii text file, not to the
.lpg file, in order to save creating two potentially very large files when only
one is really necessary.
D.15.14 SATDB (DBDUMP)

1) A new batch file dbdump has been introduced in order to automatically
dump data from a SATURN .ufs file into an ascii text file. For example, the
command:
Dbdump net flows.txt 4503
automatically dumps the demand flows (DA code 4503) from net.ufs into a
file flows.txt. Various options are provided to control the “format” etc. of the
output file. 15.46.
D.15.15 SATTUBA
1) SATTUBA has been extended to treat individual user classes under MUC.
5109341 / Mar 13 D-93

11_2_05_App D.docx
DATE OF LAST UPDATE: 8 JULY 2007

SATURN 10.7 was first released in Beta version from July 2006 (with purely
temporary version numbers 10.7.1, 10.7.2 etc.) and as a full release (official
10.7.8) in February 2007. The following new features are to be noted. (Note as
well that the documentation has been extensively updated to take account of
these new features and references to the relevant sections of the manual are
given.)
D.16.1 P1X
1) “Default” link capacity-restraint records may be defined for simulation links
under Network Editing. I.e., you define simply a capacity index and the
parameters of the speed-flow curve are taken from a “default” (D) record
defined under the 33333 data records. 20/06/06.
2) Link travel times and/or speeds as calculated by P1X during tree building
and/or joyrides and displayed in the banner now (optionally) include the
effect of CLICKS. 10.7.1 09/06/06
3) Options added within P1X network editing of simulation nodes/links such
that a default speed-flow curve (i.e., one based only on the capacity index
and curves defined under 33333) can be created for a simulation link rather
than explicitly setting a free-flow speed, capacity speed, etc. etc.. 10.7.1
14/06/06
4) Banned turns displayed within P1X as “blocked arrows” previously only
included turns with zero saturation flow as coded under 11111 but not any
turns for which a banned movement was defined under 44444. The latter
turns are now included as well. 16/08/06
5) Filenames as listed under “Show A-Z” now contain up to 24 characters on 2
lines in the banner if necessary. 24/08/06
6) The (text-based) options within SATDB to input data (e.g., flows) for ALL
user classes now allow the total number of user classes to be greater than 4
and data for ALL classes are added to the data base. 06/10/06
7) Nodes may now be “marked” or “highlighted” with a small circle to indicate
where either (any) warnings or certain specific warnings, etc. have occurred
during the network processing in SATNET. This can therefore act as a guide
to locating nodes where particular errors have occurred so as to make it
easier to correct those errors through Network Editing. See 11.6.5.4.
30/10/06
8) The use of the “mouse” has now been effectively turned off when P1X is run
with both KEY and VDU options on so as not to interfere with the use of the
mouse by any other currently running windows. 01/11/06
9) The number of scatter plots and tables within windows which appear under
the Validation of Counts disaggregated by count sets is now strictly limited
5109341 / Mar 13 D-94

11_2_05_App D.docx
since, with up to 120 different count sets now permitted, the number of
active windows created becomes prohibitively large.
10) The total number of individual Warnings, Serious Warnings, etc. etc.
generated within SATNET along with informative titles may be displayed in a
window as an option under Information. A summary table of warnings etc. by
data input segment is also included. 11.8.4.9. 06/12/06
11) The option under Information to display “Convergence errors etc.” has been
replaced by a shorter option that simply list CPU times and other
miscellaneous network data such as elasticities etc. since Convergence
statistics are provided within their own main menu and the error messages
are now given separately under #10 above. 11.8.4.8. 07/12/06.
12) User Class Flows may now be optionally annotated in units of vehicles per
hour as opposed to PCUs per hour provided that: (a) the user class has
been assigned a vehicle class and (b) that that vehicle class has a value of
VCPCU different from 1. N.B. This option does not apply to total flows
where, for certain components such as PASSQ flows, it is more difficult to
establish PCU factors. 16/12/06
13) Extra link and turn data annotations have been made available, for example
the average queue lengths associated with V>C queuing may now be
displayed in addition to the total average queue length previously available.
Full lists available in App. J. See also D.16.3 (3). 28/01/07.
14) A new set of options has been added under Tree Building to identify the
“Worst O-D routes”; i.e., those paths where the difference between the path
cost and the minimum O-D cost is maximised. Identifying such paths may
help to pin-point the sources of convergence problems. 11.8.3.4.
15) The default “user class” for SLA has been set to zero so that, for multiple
user classes, all user classes are analysed. For a single user class it
defaults to 1. Also added as a parameter MADSLA in the preferences file.
Similar changes are made in SATDB. 10.7.8. 17/02/07.
D.16.2 MX
1) The MXM5 options now allow zones to be deleted from an existing matrix.
(Or, strictly speaking, the documentation makes it a bit more clear how to do
it.) See Appendix W.3. 03/06/07
2) MXM5 permits newly created zones to have user-defined row, column and
intra values set; previously all new zones had their cell values set to zero.
Appendix W.3.
3) MXM5 will now operate on both “simple” square matrices and stacked or
blocked matrices. Appendix W.3.
4) The “interactive” zonal editing options within MX now allow you to create an
equivalent input file for MXM5 to make it easier to repeat the same editing
operation on other matrices. 10.4.1.
5) The numerical Trip Length Distribution options have been extended (a) to
allow more options (e.g., include/exclude intra-zonals) and (b) to output
5109341 / Mar 13 D-95

11_2_05_App D.docx
directly to an external ascii file or to a window to make accessing the results

easier.
6) An option to dump data from more than one matrix to an ascii text file has
been added but only under the specific formats of Tuba-3 or “one IJ record
per line”.
7) Dumping SATURN .UFM files to EMME-2 formatted text files previously
excluded any output for matrix rows which contain all zeros. 10.7 adds a text
record consisting of only the row origin in the case of all-zero rows.
18/12/06.
D.16.3 SATNET
1) Bus routes are now allowed to make a U-turn at all types of simulation
nodes, not just simulation type 5 roundabouts or buffer nodes as before. The
U-turn is treated as a “free turn” with no delay added. See note (10), section
6.9.2.
2) Bus routes are now allowed to exit the network at one external node and re-
enter at another (where an “external node” in this context may be either an
external simulation node which does not lead into the buffer network or a
buffer node which exits only to a zone. This will probably have more
applications within cordoned networks where routes in the main network
may snake in and out of the cordoned network. See note (11), section 6.9.2.
3) If a parameter WRIGHT is set to T then certain existing warnings, serious
warnings and/or non-fatal errors may be upgraded to semi-fatal (NAFF) on
the basis that there is no conceivable reason that could explain these errors
even though SATURN can manage to run with them included in the network
coding without crashing. At the moment only a small number of Serious
Warning (139 and 140) and Non-Fatal Error 227 have been so identified but
the number will increase. N.B. The default value for WRIGHT has been set
to .TRUE. in the release version 10.7.8: attention! 6.12.2. 09/10/06
4) All warnings, serious warnings, etc. that occur at nodes are now cross-
classified by node numbers so that the final error summaries in the .LPN
files not only list the number of times a particular error occurred but also the
nodes at which those errors occurred. The information is also added to the
.uf* files for display in P1X under Information. 26/10/06
5) Links which appear in more than one set of 77777 counts are now recorded
as appearing in both/all sets and will appear as such within the Validation
etc. summary statistics in P1X, SATLOOK etc. However links which appear
twice within the same count segment are still errors. 30/10/06
6) The maximum number of individual 77777 count sets has been increased
from 20 to 120. 12/11/06
7) Setting ERRYES(437) = F converts a Semi-Fatal Error for an unidentified
link within the 77777 records into a Serious warning 269 such that the
assignment stage may still be invoked. 11/11/06
5109341 / Mar 13 D-96

11_2_05_App D.docx
8) A logical namelist &PARAM parameter CROWCC has been introduced to

control whether zero-distance buffer centroid connectors are assigned a
non-zero crow-fly distance. See E.4, # 29 and 15.10..3 03/12/06
9) The number of individual Warnings, Serious Warnings etc. generated within
SATNET are now stored on the output .uf* files and may be displayed in
P1X. See D16.1 #10. 06/12/06
10) A summary table giving the number of Warnings, etc. by input data segment
(i.e., 11111, 22222 etc.) is now included near the end of the .LPN files and is
also interactively printed on request in P1X. 09/12/06
11) A new option “UNIQUE” has been introduced to minimise the double-
counting of V>C delays in buffer networks in certain circumstances.
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 will be assigned the same demand flow V. At
the moment if, say, all links have the same capacity C and V > C then the
same queuing delay will be imposed on all links – “double-counting”.
However, if UNIQUE = T, the extra delay is imposed at only one of the links
(that with the minimum capacity which therefore represents the “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. See 15.48. 01/02/07.
12) Default speed-flow curves by capacity index under 33333 may now 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. 15.9.6 10/02/07.
D.16.4 SATALL
1) The simulation summary statistics such as total pcu-hrs etc. may differ
marginally from those calculated previously due to a bug discovered in
previous releases. See Appendix E.4, #26. 14/11/06.
2) .The CLICKS option to allow differential speeds by user class has been
extended to allow CLICKS to be disaggregated by link capacity index. As
selected by setting an &PARAM parameter KLUNK = 1. 15.47.2. 03/12/06.
3) The number of simulation data arrays stored by SATALL on the .ufs file has
been extended to include:, e.g., queues due to V>C per simulation link
and/or turn. These new data arrays may be viewed within P1X. Many of
them make use of the extra space available for DA codes in 10.7 as noted
D.16.9 below. 28/01/07
4) The rules for using a stacked trip matrix under MUC have been tightened up
so that if, for example, the trip matrix has 5 levels but the network has only 3
user classes or if one of the levels of the trip matrix is not selected by any of
the user classes it is a fatal error. Check the definitions of matrix levels in the
88888 records of the network .dat file.
5109341 / Mar 13 D-97

11_2_05_App D.docx
D.16.5 SIMULATION
1) The procedures by which delays are calculated for X-turns at priority
junctions which share lanes have been revised slightly in order to remove a
possible discontinuity in the outputs which was adversely affecting the
assignment-simulation convergence. 02/07/06.
D.16.6 SATLOOK
1) Comparison statistics between modelled flows and input counts may
optionally not appear on the terminal screen in otherwise interactive modes
but only in the LP files. This can be useful when there are a very large
number of counts and/or count sets. 12/11/06.
2) The tests for DETR-compliance have been (correctly) extended to include
the separate category of counted flows above 2700 and the default is now
for DETR compliance to be included by default (but this may be changed, if
desired, via the preferences file). 21/11/06
3) A number of other improvements have also been made to the comparison of
observed and modelled flows, particularly when the counts have been
divided into multiple count sets under the 77777 network data. In particular a
CSV file containing “headline statistics” for each input count set has been
introduced and which contains a summary of all the most important statistics
in a CSV format. 03/12/06
4) It is possible to carry out count comparisons using an input file of count data
rather than relying on counts input under the 77777 data records in the
original network .dat file. See 11.11.13. 04/03/07
5) Extra options which indicate when and my how much the link capacity, as
defined on a link speed-flow record, “actively” restricts the junction stop-line
capacities. See 8.4.4. 23/12/06
D.16.7 SATTUBA
1) New versions of the batch file sattuba0 and sattuba3 added to request
output files in .ufm format or tuba-3 format respectively. 15.41.4.3 15/08/06
2) Files for all user classes may be output from a single command by using
“UC *”. 15.41.4.2. 27/08/06
1) A new method to “freeze” cells has been introduced whereby a matrix of
frozen cells may be input in much the same way that frozen cells may be
introduced into the elastic functions within SATALL. 13.1.6. 26/11/06
D.16.9 SATWIN
1) The initial SATWIN start-up screen as been replaced by a new menu to
select the various versions of SATURN Executables installed on the
machine. See 3.6. 18/02/07
5109341 / Mar 13 D-98

11_2_05_App D.docx
D.16.10 DA Codes
1) The conventions by which DA codes represent different styles of data have
been extended such that “real” data (i.e., numerical data which includes
decimals) can be stored in codes ending with an 8 as well as a 3. Effectively
this doubles the number of available codes and the number of data arrays
that can be stored. See 15.21. 28/01/07
D.16.11 SATDB
1) An alternative method of representing bus route data in the data base has
been introduced whereby the new data column stores the order of the link
or turn in the route, i.e., the first link in the route is 1, the second is 2, etc.
etc.. The old method simply stored the route number. This option is useful if
you wish the data display on, e.g., the screen to appear in route order.
2) SATRAP (full multiple route re-assignment) now allows a sub-matrix of O-D
trips to be specified in terms of sectors in addition to zones. This permits one
to calculate, in effect, a “forest” of loaded trips between two sectors. 10.7.4.
15/12/06
3) If there are more than six columns of data to be displayed to the terminal
screen then Left and Right control buttons have been added to the menu
bar. Equally a Formats button has been included to directly change the
format (number of decimal places) of an individual column. 10.7.8. 21/02/07
1) The Manual has been extensively upgraded and extended to cover not only
the new options listed above but also to explain in greater detail existing
features of SATURN. Note, in particular, Appendices I and J, which
document what is contained in DA codes and what P1X annotation consists
of, and Appendix K, a list of all available batch files, has been added.
2) The Manual is now in A4 PDF format and is updated on a regular basis –
typically every quarter – and is available for download from the SATURN
website.
5109341 / Mar 13 D-99

11_2_05_App D.docx
DATE OF LAST UPDATE: 21stJUNE 2009

SATURN 10.8 was first released in pre-Beta version in March 2007 (with purely
temporary version numbers 10.8.1, 10.8.2 etc.) and as a full Beta release (official
10.8.12) in December 2007. The first full release was version 10.8.15 in March
2008 followed by a (limited) release of 10.8.16 in June 2008 and a more general
release of 10.8.17 in July 2008. The latter two contain, mostly, additional analysis
facilities but see also point (18) under D.17.5 regarding possible differences in
numerical outputs. Thus 10.8.17 can be expected to give different results
(probably only slightly different) from 10.8.15.
The “final official” release was, firstly, 10.8.20 in December 2008. With the
exception of one extremely minor change to the simulation routines (point (19)
under D.17.5), which was added to avoid a potential crash and should never occur
in a well-formulated network, there were no changes to the basic simulation or
assignment routines in 10.8.20 over and above 10.8.17 so that the results should
be identical. However a number of extensions were made to the various
subsidiary programs; see, for example, points 10) to 12) under SATME2 which
may be extremely useful.
A second “even more final” release of 10.8.21 was made in February 2009 with
the specific objective of including a small number of quite useful analysis options
which had been developed as part of release 10.9 but which could easily be shoe-
horned into 10.8. See points 46) to 48) under P1X, 22) under SATNET, 7) under
SATLOOK and 3) and 4) under General (D.17.10). In addition a number of minor
bugs were corrected. However there were no changes to either the simulation or
assignment routines between 10.8.20 and 10.8.21 so that 10.8.21 should give
identical results to 10.8.20 and, in turn, almost certainly, identical results to
10.8.17.
A third and definitely “final” release of 10.8.22 was made in June 2009 with the
specific objective of enabling the release of SATURN Multi-Core as part of v10.8.
As with v10.8.21, there were no changes to either the simulation or assignment
routines between 10.8.21 and 10.8.22 (other than facilitating multi-core) so that
10.8.22 should give identical results to 10.8.21.
Or maybe not all that “definitely final” as there is yet another unofficial release,
10.8.23 in November 2009, which corrects various obscure bugs detected in
10.8.22 (e.g., see 40) in Appendix E.5) but is only being circulated to users who
experience those bugs.
The following sections describe the changes made to SATURN 10.8 over and
above release 10.7.9 (some of which may equally have been included in 10.7.10,
etc.).
D.17.1 P1X
1) Dumping isochrones as data files. Isochrone data, i.e., the minimum “cost”
from a selected zone to all other nodes/zones/ may now be dumped either to
an external text file or stored internally in a node data base column. The
5109341 / Mar 13 D-100

11_2_05_App D.docx
basic intention is to be able to export the data into a GIS system to produce
a “proper” isochrone plot. 11.8.3.3.
2) An option to include the “map sequential number” has been added under
annotated Node Data. This is potentially of interest since it is the map
sequential numbers which are used under SATCOBA if sequential node
numbers are used for output.
3) The difference between a link/turn count and its capacity, when the count
exceeds the capacity, may now be plotted under either Count Validation or
ME2 Analysis.
4) Plotted data under either Count Validation or ME2 Analysis may now be
restricted to the “Top Ten”, e.g., the 10 links with the maximum error, and
the top ten data displayed in a window.
5) Converting a buffer node with more than 6 arms to a simulation node under
PMAKE is not permitted; previously it caused a crash. 22/03/07
6) Critical GAP values when reported/displayed by turn now differentiate
between merges and non-merges; in the former case GAPM is reported, in
the latter, GAP. 02/04/07
7) The editing of GAP values by turn within network editing has improved in
several respects; e.g., a change to a single turn can optionally be transferred
into the “nodal value”. 02/04/07
8) Network edits now accept input files to list all those buffer nodes to be
converted to simulation with their new junction type indicated. See 11.9.12.4.
Equally files containing lists of links (A,B) and turns (A,B,C) plus data may
be input to automatically edit various link and/or turn properties. See also
#24 below. 30/03/07
9) Node selection now allows nodes to be selected on the basis of whether or
not they had any Warnings, Serious Warnings, etc. etc. during network
building. 09/04/07
10) The editing of simulation nodes under Network Editing of the .dat file now
allows a “loop” to be set up whereby all selected nodes are processed in
order, rather than having to select each individual node with the mouse. In
particular, this may be combined with the new option (#9 above) to select
nodes with particular levels of coding errors so that you may now simply
select all nodes with, say, a particular NAFF error and loop over all
occurrences of that error. 09/04/07
11) Editing bus routes which have errors already has been made simpler.
10/04/07
12) Dummy nodes may now be optionally represented by a “star” rather than left
as a “hole” as previously. Controlled on/off by a parameter 4STAR = T/F in
P1X0.dat. See 11.6.5.1. 18/04/07.
13) A new “search option” MOVE has been added under Window to allow the
current window to be moved incrementally in any direction from the current
window – a sort of generalization of the Left, Right Up and Down
5109341 / Mar 13 D-101

11_2_05_App D.docx
commands. In addition, the extent of the overlap between incremental

windows, previously fixed at 0.5, and the degree of expansion/contraction
under Pan/Zoom are now user-set parameters. See 11.5.1. 06/05/07.
14) External simulation nodes which are also part of the buffer network are now
assigned a light blue colour in order to distinguish them from external nodes
which on the “true” edge of the network. And which continue to be blue
11/05/07
15) The ME2 Analysis display options include an option to annotate only those
X a Balancing Factors which are equal to the max/min values. 14/05/07.
16) The “main” text window which is used, for example, by the SATLOOK
and/or SATDB options now permits Edit/Copy/Paste functionality. 26/05/07
17) Links from external simulation nodes which have been artificially coded with,
e.g., 6 lanes are now plotted with a reduced number of lanes. 08/06/07.
18) Annotated turn data may now be “selected” using the same link selection
criteria as used in the SATDB link data base. 08/06/07.
19) LOG and KEY files now contain a reference to the user network coordinates
as well as the pixel coordinates when the mouse is being used to select a
point on the display screen (e.g., creating a Box as opposed to selecting an
item from the banner). This means that if the KEY file is used on a computer
with a different pixel resolution the desired coordinates should be identified.
21/09/07.
20) Bus routes may be selected under Information by first selecting a specific
“bus company” 10/10/07
21) The network filename is now displayed on the right hand side of the top
“caption band” in addition to the P1X program name. 15/10/07
22) A form of “Select Link Bus analysis” marks all links served by bus services
through a selected link. See 11.8.4.2. 02/11/07
23) The Preferences File has been extended to include a complete list of all
parameters used to define different colours by range value for annotated
data. 22/11/07
24) Options have been introduced within Network Editing to edit complete “data
fields” (e.g., link distances, turn saturation flows, etc.) covering all simulation
nodes/links/turns. By contrast the normal simulation node editing allows one
to edit any of the individual data values associated with a single simulation
node but not the same data field (e.g. distance) over all nodes. The data
may be obtained either from an ascii text file (e.g., generated from a GIS
data base) or by an internally created DB column (e.g., to calculate
saturation flows from an equation involving more fundamental variables such
as lane widths). See 11.9.17. 09/01/08.
25) The 44444 records dumped under the “re-create a .dat file” option under
Files have been corrected: (a) to exclude bus-only links or turns which will
already have been indicated by negative signs under 111111 and (b) to add
$ to tolls. 09/01/08.
5109341 / Mar 13 D-102

11_2_05_App D.docx
26) The automatic node graphics loop over selected simulation nodes as
mentioned under 10) above has now been extended to cover non-editing
mode. For example, you can automatically loop over all nodes which have
been selected on the basis of having a particular error. See 11.12.1.
17/02/08
27) .Dat files dumped from P1X, e.g., from network editing or re-created from an
existing .ufs file, now contain a full list of all &PARAM parameters, not just
those that differ from their defaults. 10.8.16 only. 11/03/08
28) An explicit option has been added when a new .ufs file is output under Files
to set the parameter SECRET = T on output (the default is F) so that the .ufs
file cannot then be used to re-create the basic .dat file information. 10.8.16
only. 11/03/08
29) An “UNDO” option added within the interactive definition of nodes in both a
joy ride and the definition of bus routes within network editing. 10.8.16.
30/03/08
30) Joy ride definitions set interactively may now be “dumped” into a text KEY
file that may be input into SATLOOK to, effectively, repeat the same
operation with, e.g., a different network. 10.8.16. 30/03/08
31) The input .UFC file may now be re-set interactively under the Files Menu.
This could be useful if filenames have been changed and the “correct” .UFC
file cannot be located automatically; on the other hand it opens up the
possibility of selecting the “wrong” .UFC file. Be careful! 10.8.16. 17/04/08.
32) An option has been added in the Master Menu to enter Node Graphics in an
automatic loop over all “highlighted” nodes. E.g., you can choose under
Display to highlight all nodes with a particular Serious Warning and then
examine all nodes with that particular error. See 11.6.5.4. 10.8.16.
18/04/08.
33) Equally a node-graphics loop over all “highlighted” nodes may be requested
within the simulation node sub-section of Network Editing. (At the moment
you can do the loop but only have first selecting the highlighted nodes.)
10.8.16. 19/04/08.
34) The Network Editing of 33333 Buffer Links now contains an option to
automatically delete all “second records” containing KNOBS data. This is
part of several new facilities to assist users to transfer KNOBS data into an
external ascii file. See 15.14.7. 10.8.16. 18/04/08
35) Node Graphics and SATLOOK simulation node analyses now allow the user
to list a table of the original input delays at a node, i.e., not the delays
which may have been re-calculated due to a selected node having been
through a re-simulation process. Normally the two are identical (or
extremely close). However, if you are looking at a .UFS file from an older
version (i.e., 10.7 or earlier) then the 10.8 simulation may be slightly different
from the previous simulation due to the new rules in 10.8 and therefore give
different delays. Which can be confusing! 10.8.16. 08/05/08.
5109341 / Mar 13 D-103

11_2_05_App D.docx
36) The set of “10 worst” statistics now contains a list of the 10 worst “gaps”
where the gap is defined to be the difference in delays as calculated by the
simulation and the previous assignment multiplied by the flow. See 9.9.1.
10.8.16. 24/05/08.
37) A Gap or Delta contribution by individual link may now be calculated under
Analysis / Trees and should prove useful in helping to identify problem areas
in terms of convergence. See 11.8.3.5. 10.8.16. 27/05/08.
38) The validation of count data may now be carried out using count data (of the
format used for 77777 data in network .dat files) may now be directly input to
P1X as opposed to using only the counts pre-set in the original network .dat
file. 10.8.18. 18/07/08.
39) Node graphics data display now allows (basic) data extracted from a second
input .ufs file to be displayed as well as that from the main network. This
applies to both turn-based and link-based data displays. 10.8.19. 22/07/08.
40) “Navigation options” have been added to the Menu Bar which replicate
standard window options such as move Up, Down, etc. etc. but which
enable those steps to be carried out repeatedly from a fixed position of the
mouse with multiple clicks. Try it! See 11.5.5. 10.8.19. 31/07/08.
41) The Convergence Options now include two new options: (1) to highlight the
nodes printed under any of the “10 worst” categories, e.g., delay differences;
(2) to enter a node graphics loop over the (up to) 10 worst nodes in order to
examine the source of the problem more closely. See also 7) under
SATLOOK in D.17.6 and section 11.15 of the Manual. 10.8.19. 04/08/08.
42) In addition the edit simulation node options under Network Edit also allow a
loop over, say, the 10 worst converged nodes in terms of turn delays as in
41) but with the extra possibility to edit the .dat file directly. See section
11.9.3. 10.8.19. 18/08/08.
43) Extra navigation options (see 40) above) added to allow: (a) a single mouse
click to set the centre of the plot and (b) the last window. 07/10/08. Release
10.8.20
44) Background bitmap images from .jpg format files is now permitted. See
11.3.6. 07/10/08. Release 10.8.20. See point 48) below for outputs to .jpg.
45) Link data annotated from two or more networks may now be calculated as
the GEH difference statistics between the flows on networks 1 and 2. See
11.6.2.3. 22/11/08. Release 10.8.20
46) A red bar has been added on individual node plots to indicate when an exit
and/or entry link is blocking back. 10.8.21. 24/01/0
47) An explicit option to print standard Node Table 2 (Flow and delay data) from
within Node Graphics has been added. 10.8.21. 27.01/09
48) The option to output screen images to .JPG files (in addition to importing
.JPG files; see 44) above) has now been added. 10.8.21. 01/02/09.
5109341 / Mar 13 D-104

11_2_05_App D.docx
D.17.2 MX
1) XCL command line extensions removes the upper limit of 9 on the number
of arguments used on a command line. See 14.8
2) New procedures to stack and unstack .ufm matrices, UFMSTACK and
UFMUNSTACK, have been introduced to allow an unlimited number of
matrices to be stacked by listing their filenames as individual records with a
text “control file”. They provide an alternative to the use of XCL, See
10.20.17 and 10.20.18 09/03/07 and 14/02/08 for UFMUNSTACK.
3) Origin and destination totals for matrix Furnessing can be copied from one to
the other and/or swapped between them. 29/03/07.
4) Fortran Equations can now use TOT(n) as a function to denote the total
number of elements in matrix n. See 10.8.1. 10/07/07.
5) The compression of matrices via M5 (/MXM5) is now based on double
precision calculations to avoid possible loss of values due to rounding
errors. 22/10/07
6) An output .ufm matrix can be created containing 1/0 values to indicate
whether that cell has been selected or not. See 10.6.3. 13/11/07
7) With stacked matrices the “selection by location” rules have been extended
to include “multiple locations” so that, for example, rows 3 to 5 may be
selected in all levels of the matrix or, alternatively, only in a single level. See
10.6.1. 15/11/07.
8) The screen editing of “row-based vectors” such as origin trip ends, origin
factors, etc. etc. now takes proper account of levels within stacked matrices.
See 10.7.3. 15/11/07.
9) Various print formats have been changed so that matrices which have very
large individual cell values, e.g., which would require more than 7 digits to
write as an integer, or (more commonly) equally large row or column totals
will appear with a reduced number of decimal points to avoid values
appearing as ********. 04/01/08. 10.8.13 only.
10) The default number of decimals used in CSV output dumps has been
increased from 2 to 5 (parameter NDPS in the preferences file). This is in
response to the current trend to require trip matrices to be “in-filled” such
that all cells contain positive (if very small) numbers. See 10.15.2. Release
10.8.14 only. 25/01/08
11) At the same time the sum of the “rounding errors” caused by writing a “real”
variable to a CSV file with a finite number of decimal places is calculated
and printed. Increasing NDPS is designed to minimize this error. 10.8.14.
25/01/08.
12) The “matrix number”, e.g., mf45, used when creating an output matrix in
EMME format may now take values from 1 up to 999, not 1 to 999. 10.8.19.
29/08/08.
5109341 / Mar 13 D-105

11_2_05_App D.docx
13) Option added to suppress the final 99999 record for matrices dumped to a
ascii/text file with the one line per cell format (effectively TUBA-1). 03/10/08.
Release 10.8.20.
14) The automatic factoring procedure MXFACTOR may now be applied to only
one level of a stacked matrix, See 10.20.3. 11/10/08. Release 10.8.20.
15) A new batch file MXAGG has been introduced in order to aggregate a
stacked matrix into a square matrix equal to the sum of all levels – with extra
options to select a subset of levels. See 10.20.20. 12/10/08. Release
10.8.20.
D.17.3 SATNET
1) Several new Warnings, Serious Warnings and Non-Fatal Errors have been
added and users are strongly recommended to check for “new” errors in
existing networks. More specifically, Warnings 90 – 96, Serious Warnings 49
– 63 and Non-Fatal Errors 72 – 76 have been added.
2) Bus route “names” input under 66666 previously were read from columns 2
to 5; they may now be read anywhere within columns 1 to 5 with a maximum
length of 4 characters. If all 5 columns are used column 1 is ignored (as
before). See 6.9.1.
3) The number of records per route has been increased from 20 to 78
(including elements such as timing points etc. in addition to per nodes). See
note (9), 6.9.2.
4) The list of Serious Warnings etc. that are upgraded to NAFF errors under
WRIGHT = T has been extended. Zero Tolerance! See 6.12.2 for a full list.
26/05/07
5) Single lane arms at signals which include a X-marked right turn are now
classified as a Serious Warning 152 (previously they were Warning 12) on
account of the severe problems they frequently cause for simulation
convergence. 26/05/07
6) Warning and/or Serious Warning introduced for node-specific values of NUC
which are judged to be too small. 15.15.2.
7) NUC may now, in effect, be disaggregated by node type such that NUCJT(j)
sets a default value of NUC for all simulation nodes of type j and therefore
over-rides the “global global” default set by NUC. 15.15.2
8) The upper limit on NUC (number of time units per cycle) has been increased
to 125. 15.15.2
9) A new logical parameter AUTNUC has been introduced to allow the program
to decide automatically on an “optimal” node-specific value of NUC
depending on, for example, stage times at signals. 15.15.2.
10) A potentially very useful extra error check (Non Fatal Error 273) has been
added to detect links A,B which have exit turns from B but no entry turns into
A,B at A. It would appear from looking at a number of existing networks that
this occurs not infrequently and almost certainly unintentionally. It may also
5109341 / Mar 13 D-106

11_2_05_App D.docx
have been the cause of program crashes prior to 10.8; see note 20) in
Appendix E.5. 27/06/07.
11) DIADEM. Setting DIADEM = T in &PARAM allows the external control
procedures in the Diadem demand models to differentiate between when
UPDATE = T and/or WSTART = T are being used on the first supply-
demand loop and subsequent supply-demand loops. It avoids problems of
errors occurring on the first loop when essential files have not yet been
created. 15.51
12) The data extracted from the update .ufs network file under UPDATE = T has
been extended to include extra necessary information in order for the first
new simulation in SATALL to carry on as closely as possible from the final
simulation of the update network. Previously it essentially started from
scratch. With luck this should speed up convergence. 15.3. 12/08/07
13) Link counts under 77777 may now be read as Free Format by setting a
parameter FREE77 = T (although the A-node, B-node and C-node are still
read in fixed columns). Note (12), section 6.10. 22/08/07
14) If a GIS file is defined in the .dat 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 15.10.1.
23/11/07
15) KNOBS data read from an external KNOBS file (FILKNB) may now define
links using a “wildcard” principle whereby, if an A-node/zone is defined but
the B-node columns are left blank, 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 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. See 15.14.5. 26/11/07.
16) The “Parameter Examination” previously available within P1X Information is
now used in both SATNET and SATALL to critically evaluate the choice of
parameters and to “suggest” improved choices. The outputs appear in the
relevant .LP files. 04/12/07
17) Networks with Semi-Fatal or NAFF errors cause the program to terminate
with a stop code of 5. In normal SATURN applications this has no direct
effect but users who wish to create their own control .bat files may be able to
make use of this feature. 10.8.14. 23/01/08.
18) The parameter RB106 now defaults to .TRUE. See 8.7.3. 26/02/08.
19) A new option TOPUP introduced to allow new network coding to be added
without removing the existing coding in £INCLUDE files. See 6.15.2. 10.8.16
only. 28/03/08.
20) Warning 18 (zero sat flow turns included in green stages) has been
upgraded to a Serious Warning 128 while Non-Fatal-Error 251 (funny bus
5109341 / Mar 13 D-107

11_2_05_App D.docx
route turns out of bus lanes) has been downgraded to Warning 18. 10.8.19.
26/08/08.
21) If you have a single user class (NOMADS = 1) and you set, say, MCGILL(1)
= 2 it is now treated the same way as defining MCGILL = 2; previously it
would be ignored.
22) A new logical parameter BANKER has been added which, if T (default is F),
outputs an ascii file with extension .BNT with a complete list of banned turns
including both U-turns and turns into non-exit 1-way roads in addition to
explicitly banned turns under either 11111 or 44444 data inputs. 10.8.21.
29/01/09.
D.17.4 SATALL
1) A “QUIET” option has been introduced into the Command Line such that,
e.g., “SATALL net QUIET” will run SATALL totally “in the background”; i.e., it
will not open any special reporting windows or “grab” the mouse. See
section 14.9.
2) The averaging of two OBA solutions under AUTOK has been improved in
order to improve assignment-simulation convergence.
3) The initial assignment under a Warm Start takes the input set of link flows
without any further re-assignment.
4) AUTONA introduced to automatically set NITA on each assignment iteration
and thereby reduce CPU time / improve convergence. (Although it defaults
to .FALSE. and is only used if re-set to T.) To date AUTONA has been
mostly tested with OBA where it shows considerable benefits; experience
with Frank-Wolfe is more limited. 9.5.4.
5) Default values of NITA_M and NITS_M (minimum number of iterations for
assignment and simulation respectively) now default to 3 and 5. Equally
NITA_S has been increased to 99. 10.8.14. 25/01/08
6) The use of the network namelist parameter CLIMAX to model flat speed-
flow curves for, e.g., HGVs under CLICKS has been introduced. 15.41.3.
31/01/08
7) An option to represent the “stochastic” valuation of tolls (i.e., variable values
of time) denoted STOLL which has actually been around since 10.6 is now
documented. See 20.6. 04/02/08.
8) The stopping rules have been modified when SIGOPT and/or SATOFF are
being used in conjunction with NIPS such that, every time the signals are
updated, the “counter” of successful loops is put back to zero such that
NISTOP successful loops are required after the last update. Previously it
was possible for the loops to terminate prematurely. 10.8.15. 05/03/08.
9) The output screen window that gives on-going convergence statistics now
prints the gap values rather than GEHBAR (except under stochastic
assignment, etc. when gap values are not defined). 10.8.16. 10/04/08.
5109341 / Mar 13 D-108

11_2_05_App D.docx
10) The reported out-turn elasticities under elastic assignment are now split by
generalised cost bands (with the objective of detecting different elasticity
values between short and long trips). See 7.7.6. 22/11/08. Release 10.8.20.
P1X
11) Introduction of the Multi-Core algorithm add-on module enabled by the
MULTIC parameter (default = FALSE). Release 10.8.22 16/06/09.
D.17.5 SIMULATION
1) A highly unlikely bug affecting X-turns at signals which share a single lane
with traffic whose flow is almost but not quite zero (e.g., 0.001 pcu/hr) has
been corrected. See error 2) under Appendix E.5. 30/01/07.
2) Merges may now merge into “major” turns which do not use the inside lane.
See #12 under Appendix E.5 for a more complete explanation of the
problem and its correction. See 6.4.2.3. 05/07.
3) The procedures whereby the “choke factors” (section 8.4.4) applied to turn
capacities to bring link capacities into line with link speed flow curve
capacities have been modified to remove a discontinuity between over and
under capacity turns. This improves convergence, particularly in situations
where successive assignments were taking flows just above and just below
capacity. The new procedures are optional and may be de-selected by
setting a parameter LCR108 to F (in &PARAM); the default is T. 01/08/07
4) In addition the calculated “choke factors” are preserved on the .ufs files and
between internal loops rather than being calculated “on the fly” each time a
node is simulated. 01/08/07.
5) Finally, possible oscillations in the choking factors have been damped down.
The net effect of changes 2) to 4) has been to improve both the internal
convergence of the simulation as well as the convergence of the
assignment-simulation loops. 01/08/07
6) The lane choice rules have been slightly modified to make it easier for an
over-capacity turn with a choice of two or more lanes to use one lane
exclusively if that lane has a lower V/C ratio than the alternative lanes.
01/08/07.
7) Relatively minor changes have been made to the treatment of multiple X-
turns in a single lane so that a discontinuity in the algorithms applied above
and below capacity has been corrected. Delays and capacities are now
continuous functions of flows, etc. which improves convergence. The impact
should otherwise be small. 17/08/07
8) A new option MONACO has been introduced to allow more, e.g., straight-
ahead traffic to pass in an outside lane which may be partially blocked by X-
turners. Thus, if MONACO = T (default = F) it requires TAX + 1 queued X-
turns to block the lane; currently it only requires one. This increases the
number of straight-ahead pcus which are allowed to pass “at the head of the
queue” by a factor of TAX+1. See 8.2.5.
5109341 / Mar 13 D-109

11_2_05_App D.docx
9) If RTP108 = T random delays per simulation turn are set by “estuary” as

opposed to “river”; this reduces a possible source of discontinuity and may
therefore improve simulation-assignment convergence. See 8.6.3.
10) The rules for blocking back have been slightly modified to allow for mid-link
priority nodes which have been inserted near the upstream end of a
simulation link (and which should probably not be there in the first place)
such that any blocking back from these nodes uses the FULL stacking
capacity not only of the link upstream of the priority junction but also any 2-
arm links downstream. See 8.5.4. 17/07/07
11) The rules for how many vehicles can get through “at the head of a queue”
(8.2.5) which is partially blocked by, say, right turners have been modified
and may produce different results. 15/11/07
12) The rules to treat two opposing X-turns, in particular when they are in single
lanes, have been “improved”. 16/11/07
13) The standard array dimensions for storing CFP’s (Cyclical Flow Profiles)
have been increased by 50%, partly to account for the extra demands
required by setting AUTNUC = T. Alternatively it allows an increase in the
global value of NUC by up to 50% (not necessarily recommended). 24/11/07
14) The rules for merges (turns coded with a Priority Marker M) have been
modified in a number of respects. Arguably the most important applies to
“single” merges (as opposed to a Y-merge), e.g., a ramp entering a
motorway where the ramp has a priority marker M but the motorway does
not. Prior to 10.8 the capacity of the motorway arm was reduced in
proportion to the merging traffic within the shared lane but not vice-versa. In
10.8 the capacity of the merge is also potentially reduced if the total (ie ramp
plus motorway) V/C ratio in the shared exit lane appears to be greater than
1. However this is only likely to occur if the value of GAPM is relatively small,
e.g., less than 2 seconds and the normal gap acceptance rules have not
sufficiently restricted entries from the ramp. The old pre-10.8 rules may be
re-instated by setting an &PARAM parameter M108 = F (default T). Full
details are given in Section 6.4.2.3 and 8.8.4. 03/12/07.
15) Further to 14 and the use of M108 = T the new rules also affect the
calculation of capacities at Y-merges, possibly significantly. The new rules
appear to be “better” and, all other things being equal, are recommended.
20/02/08.
16) The lane-choice rules for signalised links with an under-capacity X-turn lane
have been modified to achieve a more equal V/C ratio in adjacent lanes for
non-X turns. Generally speaking this marginally increases capacity and
decreases delay. 10.8.12 11/12/07.
17) If a filter (Priority Marker F) has been coded at signals in, presumably, lane 1
and another turn has also been allocated to lane 1 then the simulation gives
very strange results. This situation is detected as Serious Warning 105 in
SATNET but, arguably, it should be converted to a Semi-Fatal error under
WRIGHT = T. The simulation is corrected in 10.8.12. 17/12/07
5109341 / Mar 13 D-110

11_2_05_App D.docx
18) Various relatively minor corrections have been made to the simulation within
releases 10.8.16 and 10.8.17 such that, e.g., running 10.8.16 and/or 10.8.17
may give slightly different outputs from 10.8.15. (Although, inevitably, there
may be certain “pathological” cases where the differences are more
significant.)
19) A further minor simulation correction has been added in 10.8.19 to correct
an inconsistency which occurs when the initial queue at a roundabout arm
due to PASSQ flows takes much, much longer than LTP to clear and the
flow in the current time period is also much, much greater than the capacity.
The simulated delays are no longer restricted by MAXQCT as they should
be. Note that the problem only occurs if the demand is very much greater
than capacity and almost certainly means that there is a problem with the
trip matrix. 28/08/08.
D.17.6 SATLOOK
1) SATMECC is a new option to calculate the Marginal External Cost of
Congestion via simulation, i.e., the impact of adding 1 extra pcu per turn or
link. The outputs may then be used to calculate/.estimate optimum tolls. Full
documentation in Section 15.50.
2) The output TUBA format 2 for skimmed matrices now provides a “width” of
15 columns instead of 10 so that there is no longer a need to reduce the
number of decimal places NDPS to 2 to avoid overflow problems (as
originally recommended by DIADEM). Actually included in 10.6. 15.51.
3) Simulation Summary Statistics calculated internally (as opposed to simply
being read from a .ufs file) may now be disaggregated by properties other
than just Capacity Indices. For example, you may create a list of Traffic
Boroughs per link and disaggregate by boroughs. 11.11.4. 04/09/07.
4) Simulation Summary Statistics may now be output in full to a .CSV file such
all data for a single flow/index category is in a single record. 11.11.4.
04/09/07.
5) Simulation Summary Statistics which are created “on the fly” – option 2 -
may now be output to a .CSV file which contains the 14 basic statistics
disaggregated either by link or by node. 10.8.16 only. 04/04/08.
6) The standard data-printing options for a simulation node now include a
listing of all the standard “convergence” errors, e.g., the differences in delays
as calculated by the assignment and by the simulation. See also 41) under
P1X in D.1.7.1. 10.8.19. 04/08/08.
7) A facility to skim O-D time, distance and tolls simultaneously from a forest
(as opposed to carrying out 2 or 3 separate skims in order to reduce CPU
time by a factor of roughly 2 or 3) has been added. This may be called either
interactively under main option 9, via a standard batch file SKIM_ALL (cf
SKIMTIME, etc.) or in SATTUBA. It should be applicable to external
applications such as Diadem where multiple skims are repeatedly required.
See 15.27.7. 10.8.21. 24/01/09
5109341 / Mar 13 D-111

11_2_05_App D.docx
D.17.7 SATUFC & SATUFO

1) An additional option ‘UFO’ on the SATUFC command line now allows a
.UFO file to be created in addition to the .UFC file. See 15.23.6. 17/07/07
2) SATUFC now produces a new .ufs file which contains correct information for
SAVEIT and/or SAVUFO. This avoids a number of problems of analysis
programs not realising that SATUFC has been run and therefore not finding
the UFC/UFO files. See also #13 in Appendix E-5. 15.23.5. 17/07/07
3) If the original network had been through an elastic assignment the SAVEIT
assignment which creates the .UFC file uses a fixed trip matrix assignment
algorithm using the output trip matrix from the original elastic run. 15.23.4.
17/07/07
4) SATUFO has been created in order to create a .UFO file from UFS/UFC
files assuming that SAVUFO was not originally set to .TRUE. (or, if the UFC
file was also created “after the fact” by SATUFC, that the UFO option (see
#1 above) was not invoked. 15.23.6. 21/07/07
1) Before and After Trip Length Distributions may be printed in the .LPM file in
order to compare the before (prior) and after (output) trip matrices.13.3.10
2) Extra checks have been included in SATPIJA to detect: (a) counts which are
totally or largely downstream of queued links which effectively “fix” the flow
through the count; (b) counts which are over capacity, (c) possible
inconsistencies between adjacent counts.
3) SATME2 will now accept (a) stacked matrices as input and (b) stacked
matrices as output. See 13.4.3. 24/08/07.
4) The standard array dimensions per release level have been increased so
that, e.g., the maximum number of ij matches per link is 50% greater. (Also
in 10.7.11) 10/08/07
5) SATPIJA can calculate weighted PIJA factors over all user classes within a
common vehicle class in order to update the total trip matrix for that vehicle
class. This means, for example, that you can update a total matrix of car
trips which, for assignment purposes, is sub-divided by purpose. See
sections 13.4.2 and 13.4.6. Version 10.8.13. 03/01/08.
6) SATPIJA now contains a series of checks to detect violations to Kirchoff’s
Rule, i.e., the sum of the counted flows into a node does not equal the sum
of the counted flows out of that node. It also detects “near” violations
whereby if, say, all input arms to a node and all but one output arms are
constrained then the :missing” arm is equally constrained and its implied
flow may be compared against the current assigned flows to detect large
discrepancies. See Section 13.3.3. Version 10.8.17. 18/06/08.
7) The most important error messages are now grouped together and re-
printed near the end of the .LP output files from both SATPIJA and
SATME2 in order to make them more obvious to users. 10.8.19 08/08.
5109341 / Mar 13 D-112

11_2_05_App D.docx
8) Equally the summary of errors from SATPIJA is included in the .UFP files
and re-printed by SATME2. 10.8.19 08/08.
9) A new parameter SUBPQ has been introduced into SATME2 in order to
subtract only the PASSQ flows from the counts as opposed to SUBFIX
which removes all the fixed flows, including the PASSQ component.
Included in 10.8.15 but not fully documented until 24/07/08 and with certain
errors within MUC applications corrected at the same time. See 13.1.4,
13.3.1 and 13.4.9.
10) Further to 6) an option AVERK has been added such that if counts at a node
violate Kirchoff’s rule (flow in equals flow out) they may be automatically
corrected by averaging the input and output flows at the common node. The
updated flows may also be output to an ASCII file if a filename FILKP is set.
See 13.3.2. 10.8.20. 01/10/08.
11) A new method has been introduced to allow SATME2 to update multiple
levels in a stacked trip matrix as identified by their vehicle class IVC by (a)
updating the aggregated trip matrix for that vehicle class and then (b)
updating the individual matrix levels proportionately. Set parameter TURBO
= T in the SATPIJA Namelist parameters (Think TURBOprop!), See 13.4.6.
10.8.20. 14/10/08.
12) A new source of potential error has been identified in situations where the
“SAVEIT assignment and the “actual assignment” give significantly different
flows on counted links. This means that SATME2 will be trying to factor the
trip matrix based on incorrect PIJA factors. Appropriate Warning and Serious
Warning messages have been introduced into SATPIJA. See 13.3.12.
10.8.20. 21/11/08.
D.17.9 SATWIN
1) Command line length increased to 2048 characters. 15/10/07
2) The date of each .exe file which is run is now recorded within the header
records at the start of every .LP file. 17/12/07.
3) “Module Run” menu has been extended with more categorised menu items
so as to include “most” of the various SATURN programs and processes
available. Version 10.8.15 21/03/08;
4) The dialog box from the “Batch Run” menu has been extended with
categorised SATURN batch files available from a selection menu with
integrated ‘help’ function. Version 10.8.15 21/03/08;
5) The QUIET option, enabling SATURN, SATALL, SATNET, SATPIJA and
SATME2 to run in the background when using SATWIN, may be switched
ON/OFF via the main SATWIN toolbar. Version 10.8.15 21/03/08.
D.17.10 General Procedures

1) Namelist character variables, e.g. used to define file names,, may now
contain up to 256 characters by using a “continuation” option whereby the
5109341 / Mar 13 D-113

11_2_05_App D.docx
full name is defined on two or more input records. See Note 17) in Appendix
A. The previous upper limit was around 68. 14/10/07.
2) Files which are “read only” are now opened in such a way that, in principle at
least, the same file can be accessed by two or more SATURN programs
running concurrently. 10.8.14. 25/01/08
3) No .LOG files are created when interactive programs such as MX or P1X are
run in KEY + VDU mode. 10.8.21 12/01/09.
4) If the file sat10key.dat cannot be opened because it is temporarily in use by
another program running in parallel the program pauses briefly and tries
again, up to 6 times in total, before the program is finally terminated.
10.8.21. 15/01/09.
D.17.11 SATDB
1) The calculation of link travel times from flows may now use a column of
either demand or actual flows; previously the assumption was that the flows
were always demand flows and that they were therefore always factored
down to actual flows before doing the time v. flow calculations. 31/03/07
2) Actual flows by user class may be directly accessed via a DA code by using,
say, 3808 in place of 3803; i.e., replace the final 3 by an 8. See 15.21.4.
9/04/07
3) Miscellaneous ASCII data input files may now have the node numbers in
either fixed column blocks of 5 or 6. Previously only blocks of 5 were
permitted (or completely CSV free format input) whereas a number of
SATURN programs produce output with fixed blocks of 6 for easier
identification. 13/05/07
4) When dumping link data to an ascii (.txt) file an option has been added to
automatically suppress all links which contain nothing but missing values.
28/07/07.
5) Single trees can now be built from either nodes or links in addition to zones
and they can be built either out-bound or in-bound. In addition a vector of
trips may then be assigned to the calculated routes. See 11.10.7.1.
22/08/07.
6) The input of data from an ascii (e.g., txt) file now automatically distinguishes
Reals from Integers. 04/09/07
7) Copy/Cut/Paste functionality added to the link and/or node Display
Windows. 20/09/07.
8) When reading in a DA code which does not contain data on all possible links
(e.g., simulation link or simulation turn data as opposed to assignment link
data) and the other links are assigned missing values then an option has
been added to automatically select only those links. This makes it simpler to
suppress the output of “m’s” to terminal or ascii file outputs. See 11.10.2 (4).
19/01/07
5109341 / Mar 13 D-114

11_2_05_App D.docx
9) Both the SATRAP and ONE SONG … options now explicitly store re-
assigned flows for individual user classes in internal data base columns in
addition to the total flow. 10.8.16 12/03/08.
10) The .ufa file output under One Song … now contains the name of the latest
trip matrix files, the total trips loaded and the individual updated user class
flows (see #9). 10.8.16. 12/03/08.
11) An option has been added under Select to easily de-select all links which
contain nothing but missing values. 10.8.16. 18/04/08.
12) An option has been included under Miscellaneous Inputs to automatically
input all items of KNOBS data into data base columns. 10.8.16. 18/04/08.
13) An external batch file KNOBDUMP has been created to automatically dump
all KNOBS data into an ascii file. This facility is intended to assist users who
currently have KNOBS data stored as extra lines within the 33333 data set
to transfer that data into an ascii file which can then be input to SATNET via
KNBFIL. See 15.14.7.10.8.16. 18/04/08
14) Stage definitions per signalised turn may now be created under
Miscellaneous Input / Packed Turn Data giving a series of data columns 1/0
to indicate green/red in the corresponding stage. 10.8.19. 29/07/08
D.17.12 Signal Optimisation Programs

1) A new “batch procedure” SIGOPT.BAT has been introduced in Release
10.8.16 to automatically optimise stage times and/or offsets and to store the
new settings in either: (a) a new .UFS file, (b) a new .DAT file or (c) a .RGS
file. It makes use of routines already included in P1X but runs in an off-line
or batch mode. It effectively supersedes SATOFF in terms of offsets. It may
also be run for a selected sub-set of nodes. See 15.31.6. 24/05/08.
1) A full update has been carried out for the June 2009 release with
subsequent ongoing revisions.
5109341 / Mar 13 D-115

11_2_05_App D.docx
DATE OF LAST UPDATE: 4th OCTOBER 2011

SATURN 10.9 was first released in pre-Beta version in December 2008 (with
purely temporary version numbers 10.9.1, 10.9.2 etc.) and as a full release
(official 10.9.12) in November 2009. Further full or partial releases were made as
10.9.15 in February 2010, 10.9.17 in June 2010, 10.9.22 in January 2011 and
(finally) 10.9.24 in May 2011.
Significant new features include new style .UFC files (see note 4, D.18.2), phased
in blocking back (note 6, D.18.3) and explicit flared lanes (note 4 in D.18.1 and
note 9 in D.18.3). Try them out!
With respect to flared lanes (see 6.4.9.3 and 8.2.6), a word of caution is required:
their introduction in 10.9.22 was based on a relatively early stage of development
and a number of consequent corrections and/or improvements were made in
10.9.23 and 10.9.24 (note 12 in D18.3). Post 10.9.24, while the added impact of
flared lanes seems to be “sensible” in all 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 further
changes to the modelling. Users are strongly encouraged to include flares in their
data coding – but with care!
In terms of backwards/forwards compatibility the 10.9 network .dat files contain
several new features (e.g., parameter names) which will not be recognised by pre
10.9 versions of SATNET but will not cause the program to crash; however pre
10.9 .dat files will be read perfectly happily by 10.9. Similarly 10.9 network .ufs
files contain new arrays which older version exe’s will be able to read but not
recognise whereas 10.9 exe’s will be able to read pre 10.9 ufs files. Matrix .ufm
files have not fundamentally changed and should be both forward and backward
compatible.
In terms of results there have been a large number of both relatively major and
minor changes to the simulation so that one might expect 10.9 to give different –
possibly significantly different – results to pre 10.9. For this reason the opportunity
has been taken to change the default values of a number of parameters, typically
options that were introduced in recent releases but “turned off” by default are now
“turned on” having been verified in practice. E.g., see note 10) under SATNET.
Our advice therefore would be to re-run old networks “from scratch” and certainly
not to do comparisons between 10.9 outputs and pre 10.9 outputs.
The following sections describe the changes made in SATURN 10.9, some of
which were also included in version 10.8.21 and/or 10.8.22 and listed in Appendix
D-17.
D.18.1 SATNET
1) A check is made whether LTP has been explicitly set in the &PARAM
records in the network .dat file and, if not, a warning message is printed.
This follows from the fact that the default value, 30 minutes, is probably not
the preferred value for most applications. See 8.4.5.
5109341 / Mar 13 D-116

11_2_05_App D.docx
2) Extra checks on network connectivity have been added: (a) on the

assignment network (previously included as Warning 47 but only if EXPERT
= T and PRINT = T); (b) the map network and (c) O-D pairs in the trip matrix
for which no route exists (previously included within SATALL). Non-Fatal
Errors 277 and 278 have been added to cover (c) and (b) respectively with
both upgraded to Semi-Fatal Errors under WRIGHT = T. See 5.5.4.
3) Q105 and RB106 are now always assumed to be .TRUE. within the
programs. Ditto LCR108. So, in effect, they are no longer parameters and
changing their values in a network .dat file has no effect. See 8.4.7, 8.7.3
and 8.4.4.
4) The presence of a flared lane (or lanes) at either signals or priority junctions
is indicated by an F within the lane field (columns 11 to 15 of the first link
record). Both nearside and offside flares may be represented. 10.9.20. See
6.4.9.3.
5) &PARAM parameters FLAREX and FLAREF have been added to represent
the default length (in units of PCUs) of offside/nearside flares. But see note
26) below as well. See 8.2.6.
6) Link-specific TAX values may now be added at the end of the (first)
simulation link data record – although another new method for including it on
the second link record (see note 26 below) is preferred. See 6.4.15.
7) New advice is provided on the tricky problem of coding extra “pseudo” lanes
for X-turns at signals and/or flared lanes which makes maximum use of the
new TAX and FLAREX options above. See 6.4.9.4.
8) Allow clear exits – priority modifier C – for filters at signals. See 6.4.2.6.
9) Warning 13 – not all obvious roundabout turns coded – is now Semi-fatal
under WRIGHT = T as is non-fatal error 234 – an X-turn at signals which is
unopposed.
10) The default values for RTP108, MONACO, AUTONA, AUTOK and AUTNUC
are changed to .TRUE. (but, unlike Q105 etc. above, they still have an effect
if turned to .FALSE.). See 8.6.3, 8.2.5, 9.5.4, 9.3.1 and 15.15.2 respectively.
11) $INCLUDE may now have a time period subscript; e.g. use “$INCLUDE(3)
file” if file is only applicable to time period 3 in a multiple time period .dat file.
See 15.30 and 17.4.4
12) Default for NIPS set to 2, 19/01/09. See 9.12.2.
13) A new logical parameter BANKER has been added which, if T (default is F),
outputs an ascii file with extension .BNT with a complete list of banned turns
including both U-turns and turns into non-exit 1-way roads in addition to
explicitly banned turns under either 11111 or 44444 data inputs. Also in
10.8.21. 29/01/09.
14) The rules for defining KNOBS data (in particular tolls) on simulation centroid
connectors have now been relaxed so that it is possible to define a
simulation centroid connector by its zone number and a single node
number, i.e., the two numbers at either end of the dashed CC lines on
5109341 / Mar 13 D-117

11_2_05_App D.docx
network plots, the obvious way to define them. However, strictly speaking,
simulation centroid connectors need a zone number plus two node numbers
to define a link but this is difficult and counter-intuitive. Indeed the use of
“wildcard” entries (zone only) is strongly recommended. See 15.14.5.
20/03/09. 10.9.5.
15) A new &OPTION parameter PLFF3 has been introduced such that, if TRUE,
links in a text file containing pre-loaded flows (hence PLODFF = T) need
only be defined by an A-node and B-node; i.e., no 3rd field containing a 0 is
necessary in order to distinguish turns from links. See 15.5.4.
16) A new parameter DCSV allows default buffer speed-flow curves by capacity
index to be defined in free format within the 33333 data records. This
eliminates potential problems of column definitions when DUTCH = F or T.
See Note 4) in 15.9. 10.9.5. 07/04/09.
17) A new algorithm is used to estimate better values of XYUNIT by comparing
input coded distances with calculated crow-fly distances by excluding: (a)
links which only lead to zones and which may well have artificial distances
and (b) obvious outliers. 10.9.6. 25/04/09
18) A new method to interpolate missing X,Y node co-ordinates has been added
to cover the situation where there are two undefined nodes on links
between two defined nodes (as opposed to just one previously). 10.9.6.
26/04/09.
19) The default value of the &PARAM parameter CROWCC has been changed
to .FALSE. in order that, by default, buffer centroid connector distances
which are input as zero are not re-set by their crow-fly distances. See
15.10.3. 10.9.8. 10/07/09.
20) The network coding practice of sub-dividing a link into a short series of 2-
arm “artificial” nodes (e.g., to give it “shape”) has now been formally
identified as a “chain” of nodes with applications to blocking back, random
delays, etc. etc. where we expect the series of links to function as a single
link in some respects. More complicated examples of the same basic
phenomenon are also identified. See 5.1.12 and 8.5.5. Chained links may
also be displayed within P1X.
21) User-class specific values of SUET (virtually never used) may now be
defined as a subscripted &PARAM Namelist variable. E.g., SUET(2) = 0.5
sets the value of SUET for user class 2 only. See 7.3.3. 10.9.10. 12/08/09.
22) A new parameter FREE88 allows the values of PPM, PPK and KNOBS
weights per user class to be input in free format – so as to avoid problems
with trying to define values within 5 columns. See 6.11, note 12). 10.9.10.
12/08/09.
23) MYTVV, which selects the algorithm used for signal optimisation, now
defaults to 5 rather than 1. The differences should be slight. See 15.31.3.
10.9.10. 12/08/09.
24) Maximum free-flow speeds (CLICKS) disaggregated by both vehicle class
and capacity index (KLUNK = 1) may now also be defined by including
5109341 / Mar 13 D-118

11_2_05_App D.docx
single records with a V in column 1 under the 33333 buffer data records as
an alternative to using an external FILVSD file. See 15.47.2. 10.9.10.
13/08/09.
25) An alternative algorithm for interpolating between two non-connected nodes
in a bus route based on minimum distance has been created. It may be
used if the normal direct-line method fails provided a parameter MINDER =
T. See 15.18. 10.9.10. 14/08/09. Equally the direct-line method has also
been improved, in particular to avoid “diversions” down spigot zone
connectors.
26) The simulation link record 2B, which previously has been used to define
simulation link speed-flow curves, may now also be used to define link-
specific values for TAX, FLAREF and FLAREX. See 6.4.14. 10.9.10.
17/08/09.
27) The default value of NITS (maximum number of simulation iterations) has
been increased from 10 to 20. See 8.1. 10.9.10. 29/08/09.
28) The default for NITA_M has been reduced to 1 under OBA (but is still 3
under Frank-Wolfe). 10.9.13. 30/11/09.
29) A new Serious Warning 138 has been added to detect roundabouts where,
e.g., the saturation flows coded for two or more arms are the same but the
number of lanes differs. Strictly speaking, it tests for significant differences
in saturation flow per lane between different arms. See 6.4.7. 10.9.13.
5/12/09.
30) Another new Serious Warning 167 tests for centroid connectors from a
buffer zone which are, e.g., coded as 2-way but the out-bound link(s) from
the buffer node is 1-way. See 16.6.4. 10.9.13. 5/12/09.
31) A new Warning detects possible simulation nodes where there appear to be
sufficient links on an outbound arm to justify using a Clear Priority Modifier
on an exit turn. See 6.4.2.6. 10.9.13. 06/12/09.
32) Incorrectly including &PARAM namelist variables within &OPTION now
results in a Fatal Error 486 (in the same way that including &OPTION
variables under &PARAM is currently FATAL 486). 10.9.14. 10/12/09.
33) The output .bus files produced if BUSKER = T are now consistently either
10 nodes per line or 13 nodes per line depending on whether there are 5-
digit nodes anywhere in the network or not, not just on the individual
routes. 10.9.14. 19/01/10.
34) Bus-lanes may now distinguish between bus-only lanes, tram-only lanes
and bus-or-tram lanes by using the letters B, S and T respectively on
simulation link records. 10.9.15. 01/02/10.
35) An alternative, more natural, set of TOPUP rules has been introduced
whereby the data input for simulation nodes may be duplicated in
$INCLUDE files via a parameter DOUBLE = T under &PARAM. This makes
it easier to create alternative scenario networks based on a master version.
The default value of T is strongly recommended. See 6.15.2 and 6.15.3.
10.9.15. 04/03/10.
5109341 / Mar 13 D-119

11_2_05_App D.docx
36) Various Warning messages which create Semi-fatal errors under WRIGHT =
T have been upgraded and renumbered as Serious Warnings. Thus
Warning 13 becomes Serious Warning 168, 17 to 169, 76 to 176 and 77 to
177. Thus none of the remaining Warnings become Semi-Fatal under
WRIGHT = T, only certain Serious Warnings and Non-Fatal errors. 10.9.16.
07/04/10.
37) In addition the set of Serious Warnings and Non-Fatal Errors which are
upgraded to Semi-Fatal under WRIGHT = T has been increased
significantly. For a full list see Appendix L. 10.9.16. 07/04/10.
38) If a negative stacking capacity is input in field 1 (columns 1 – 5) on a
simulation link record for link A-B this is taken to imply that that link should
not be considered to be part of a set of in-series 2-arm links for blocking
back purposes but is to be allowed to block back in its own right. See
8.5.5.4. 10.9.18. 04/07/10.
39) Warning 24 – an input time or speed which is out of range – has been
expanded to distinguish the situation where the input value is zero as a
Serious Warning 170. 10.9.19. 21/08/10.
40) A range of values for ERRYES 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 Section 2.9 and Appendix A. 10.9.19. 22/08/10.
41) ERL files which contain a full list of errors found within SATNET and sorted
by node order are automatically output and may be subsequently processed
by users. They may also be used to help identify “new” error messages. See
15.58.
42) Timing point routes which have a frequency of zero (as is normal) are now
always modelled as beginning at the first coded (simulation) node and
terminating at the final coded node as if, in effect, UPBUS = T, independent
of the actual value of UPBUS. This is a more “natural” assumption but
means that the modelled timing points may differ within, e.g., Validation
statistics in P1X. However it also means that timing points defined at the
final node are always accepted. See 6.9.5 and 11.7.2.2. 10.9.24. 28/04/11.
D.18.2 SATALL
1) Extra warnings, Serious Warnings and Non-fatal errors identified within
SATALL have been added to the lists produced by SATNET so that the lists
of errors displayed in, say, P1X now includes errors from both SATNET and
SATALL.
2) If MASL = 1 and SAVEIT = T the output .UFC file is always based on the
actual (single) assignment, not an extra SAVEIT assignment; see also
UFC109 under 4). 15.23.2.
3) The default value for UNCRTS changed to 0.05 from 0.2.
4) A new option UFC109 has been introduced and set under namelist
&PARAM in network .dat files. If UFC109 = T (default = F) two things
happen.
5109341 / Mar 13 D-120

11_2_05_App D.docx
Firstly, the output .UFC file under multiple user classes stores the sets of
link times per iteration as opposed to link (generalised) costs by 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
however, since the fixed costs are fixed throughout (by definition), it is
straightforward to construct the costs per iteration/UC by adding (stored)
times per iteration to fixed costs by user class. This means that the .UFC
files produced under UFC109 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. Note that for a single user class we
continue to store costs, not times, since there is no difference in file size and
it would only save a small overhead.
Secondly, the costs/times may be stored as a rolling summation of all
Frank-Wolfe iterations over all simulation-assignment loops instead of re-
creating the assigned route flows by an extra SAVEIT iteration. This has the
benefit that any secondary analysis, e.g., skimming, based on routes is
exact, not an approximation. The dis-benefit 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 longer. However, if the number of rolling iterations becomes too large
(greater than NITA_C – see below) then we revert to an extra SAVEIT
assignment. See 15.23.3. 10.9.5. 04/04/09
5) A new &PARAM integer parameter NITA_C sets the maximum number of
rolling FW iteration costs/times which may be stored in a .UFC file when
UFC109 = T. See 15.23.3. 10.9.5. 04/04/09.
6) The choice of convergence rules set by KONSTP has been extended to
allow the combination of either the ISTOP link flow criterion with a maximum
cpu time or minimum GAP value with maximum cpu time. Both are more
sensible than simply setting a maximum cpu time on its own. See 9.3.2.
10.9.5. 05/04/09.
7) The possibility that a run of SATALL may terminate with error level 2
(indicating that it has converged only on the maximum number of loops
MASL, not, e.g., on ISTOP) has been removed. Previously STOP 2 might
cause a long batch file run to hang. 10.9.5 and also 10.8.22. 08/04/09.
8) A new command line parameter QUICK, if used, artificially reduces all loop
etc. counters such as MASL, NITA, NITS etc. to minimal values so that the
program runs in minimal CPU. Useful for checking if long batch files have
been set up correctly. See 14.10. 10.9.7. 13/05/09.
9) The option AUTONA, in addition to potentially adjusting NITA at each loop,
now also sets UNCRTS in order to allow the assignment to converge better.
10.9.8. 30/06/09.
10) New advice is now provided in the manual on the choice of stopping criteria
for the assignment-simulation loops. In brief our recommendation is to use a
Gap value rather than %FLOWS (although the preference is fairly marginal).
See the discussion in 9.2.3. 14/04/10.
5109341 / Mar 13 D-121

11_2_05_App D.docx
11) Disaggregated cpu times broken down by, e.g., simulation and assignment,
now include explicit times before and after the main loops (basically inputs
and outputs). These are printed at the end of the .LPT files. 10.9.17.
12/06/10.
12) The calculation of the optimal step length used under AUTOK to average
two assignments based on the simulation has been “improved” so that it
should take fewer iterations to identify the optimum. See 9.3.2.1 10.9.17.
01/06/10.
13) The order in which the nodes are considered within a single internal
simulation iteration has been changed so that instead of simply taking them
in a pure numerical order a topologically-based strategy of working from the
outside of the network inwards has been adopted. In principle this should
reduce the number of required internal iterations. See 8.3.4. 10.9.17.
01/06/10.
14) If AUTONA = T the value of UNCRTS used during the SAVEIT assignment
is set equal to the minimum value of UNCRTS as adjusted (downwards) by
AUTONA during the assignment-simulation loops in order to make the
assignment convergence comparable to the minimum GAP value. This, in
turn, will therefore help to improve the convergence of the SAVEIT
assignment and make it more comparable to GAP as well (at the cost of
extra CPU time). See 9.5.4 and 15.23.2(4). 10.9.18. 03/08/10.
15) The method by which SATALL (and SATEASY) store trip matrices in
internal memory may be made more efficient by setting a network parameter
SPARSE = F if more than 50% of the trip matrix cells are likely to have
positive values (i.e., the matrix is not “sparse”). This avoids problems of
potential crashes due to insufficient array lengths. See 7.11.12. 10.9.21.
11/11/10.
16) If negative cells are found in the trip matrix and a Serious Warning
generated then, in addition to messages output in the .LPT file (which no
one ever looks at!), the warning 172 is recorded in the output .ufs file where
it could be printed by P1X etc along with all the other errors detected by
SATNET. 10.9.21. 19/11/10.
17) New rules are applied to the use of SATOFF = T coupled with MANOFF (a
fixed master node to define relative offsets) such that all signalised nodes
that do not have the same cycle time as MANOFF do not have their offsets
adjusted.10.9.23. 01/02/11.
18) If the input network .UF file was created by a program (i.e., SATNET) which
is from a later release version of SATURN then SATALL will fail with a fatal
error in order to avoid any possible problems of non-upwards compatibility.
10.9.23. 01/02/11.
19) The printing of simulation summary statistics to the .LPT file has been
reduced so that statistics disaggregated by, e.g., capacity index, are not
included. 10.9.23. 15/02/11.
20) The “sub-procedure” within SATALL which creates a .UFO after an
assignment has already been run has been extended for multiple user
5109341 / Mar 13 D-122

11_2_05_App D.docx
classes so that a single user class .UFO file may be created. In particular
this option may be invoked by a distributed multiple processor procedure
SATUFO_MC which creates separate .UFO sub-files using separate
processors before merging them all into a single .UFO file. See 15.23.7 and
15.53.2.7. 10.9.24. 22/04/11.
21) A Multi-Core version of Network Aggregation (SPIDER=T) released to all
existing Multi-Core users as part of the standard SATALL release. 10.9.24
31/05/11
D.18.3 Simulation
1) The method for calculating random delays upstream of links which block
back has been modified so that the capacity used in the formula is the
capacity BEFORE blocking back was applied. This removes a possible
discontinuity when the link downstream goes from a state of blocking back
to not blocking back or vice versa. See 8.6.5.
2) Arrays of simulation turn delays broken down by: (a) V>C permanent
queues, (b) random delay and (c) CFP only have been created and may be
accessed within P1X.
3) Random delays are not included on links which are part of “internal” chains
of 2-arm “artificial” nodes. See 8.6.4. 10.9.7. 01/06/09
4) The equation used to define delays on Q-turns has now been
“parameterised” in the sense that the numerical constants 226 and 0.75
(see Equation (Q-10 in Appendix Q) may now be user-set via Namelist
parameters QDMAX and QVCMIN under &PARAM.
5) The rules for blocking back on links which have been artificially sub-divided
into one or more continuous sub-links (e.g., to provide a link “shape” via 2-
arm dummy nodes) have been made more general. Set BB109 = T to
invoke the new rules. See 5.1.12 and 8.5.5. 10.9.9. 25/07/09.
6) Blocking back may also now be “phased in” when the queue on the link is
only slightly smaller than the stacking capacity by setting BB109 = T and
BBKING < 1.0 See 8.5.6. 10.9.9. 25/07/09.
7) The calculation of capacities for X-turns at signals – and of any turns with
which they share lanes – has been extended by the introduction of an
explicit length of flared lane denoted by FLAREX. See 8.2.5.2 and 8.2.6 plus
notes 4) and 26) under SATNET D.18.1 above. 17/08/09.
8) The rules governing a Y-merge and whether or not it is subject to
“funnelling” have been slightly updated in 10.9.18 which will therefore give
slightly different results from previous releases. See 8.8.4.4. 25/07/10.
9) Flared lanes are now explicitly modelled in terms of increasing the capacity
of those turns which are allowed to use flared lanes. See 8.2.6. 10.9.20.
15/09/10.
10) The rules for the reductions in capacity due to weaving on links between
“motorway” junctions (see Section 15.40) have been extended such that if
there is more than one link between the entry and exit ramps (as illustrated
5109341 / Mar 13 D-123

11_2_05_App D.docx
in Fig 15.3) than the reduction factor is applied to all those links; previously
it was only applied to the last link. 10.9.23. 20/02/11.
11) The rules for applying an additional delay at Q-turns (App. Q) have been
modified such that if the Q-marker is within a link weaving section then the
saturation flow used in equation (Q.1) is reduced by the weaving factor in
order to produce a larger delay. See also 15.40.4.5. 10.9.23. 20/02/11.
12) Post 10.9.23 the rules for modelling flared lanes (either X or F) at priority
junctions have been upgraded, basically increasing the capacity, in
particular when queues are near to or greater than flare lengths, and
correcting a potential instability (see note 44 in Appendix E-6). Equally other
modifications, possibly less extreme, have been made to the modelling of
flares at traffic signals. 10.9.23. 16/03/11.
1) Certain errors in input in the control file have been upgraded to semi-fatal
and result in the program being terminated once it has got to the end of the
inputs.
2) Extra warning messages have been added if (a) the number of frozen cells
appears to be too large and (b) if the total number of trips changes
significantly post ME2.
3) A summary table of stats per internal iteration – Table 9B – is included at
the end of the internal iterations. 15/01/09.
4) Zonal constraints (input data segments 22222 and/or 33333) may now be
duplicated in the sense that a GT and a LT constraint may now appear for
the same zone, effectively defining a range. 13.1.7. 10.9.6. 17/04/09
5) A new table (11.c) has been added to the output .LPM file to list all origin
and destination zonal totals before and after and to compare the two. 13.1.5.
10.9.6. 25/04/09.
6) The name of the output .ME2 file is now based on the output matrix filename
(change .UFM to .ME2) rather than the counts file. 13.8. 10.9.8 13/06/09
7) The contents of the output .ME2 file have also been extended so as to
include the link sensitivity variables as normally contained in Table 10 and
described in 13.3.11. Also in 10.8.22. 05/05/09.
8) The original input “actual” counts from SATPIJA are now included in the
.UFP file as well as the “demand” counts and passed to SATME2 where
they now appear in Table 1. They are also included within the .ME2 files
passed to P1X where they may be displaced under ME2 Analysis. 10.9.13.
15/10/09.
9) The .ME2 files created by SATME2 and passed to P1X now include
information on the various namelist parameters set within both SATME2 and
SATPIJA. They may be displayed as a text window under ME2 Analysis in
P1X. 10.9.13. 15/10/09.
5109341 / Mar 13 D-124

11_2_05_App D.docx
10) The output .ME2 files contain the combined set number for counts that are
combined into “screen lines” under 6666 and these may therefore be
displayed in P1X. 10.9.18. 31/07/10.
11) SATPIJA now will correctly process PASSQ flows by individual user classes
if the “pre” and “current” networks have different link structures. 10.9.19.
14/08/10.
12) SATPIJA may now process subsets of origin zones in “segments” or “slices”
such that a full PIJA analysis may be broken down into multiple sub-steps,
the main objective being to run each sub-step simultaneously within a
separate core on a multi-core machine in order to save CPU. A subsequent
run of SATPIJA will then aggregate each sub-file to create a normal full
.UFP file. See 13.4.9. 10.9.21 24/11/10.
13) A new multi-core batch file SATPIJA_MC has been created in order to use
the “segmented” application of SATPIJA (see 12) above) in order to
calculate a .UFP file using multiple processors with a consequent reduction
in CPU time. See 15.53.2.2. 10.9.24. 20/04/11.
D.18.5 SATSUMA/SATTPX
1) QUIET option now allowed. See 14.9.
2) The first time period may now have a PASSQ flow input by defining PASSQ
= T and FILPLD under &OPTION in the base network .dat file. See ??
D.18.6 SATDB
1) The minimum-maximum number of columns allowed in the link data base
has been increased from 8 to 12. In other words if your network is at the
limit of the number of assignment links then you can create at least 12 data
columns, but if you are below the limit you may have up to 24 data columns.
2) The batch file satbuf has been updated to function properly for networks
where DUTCH = T and link A- and B-nodes need to occupy 10 columns
each, not 5, on the output file. See Section 15.8.2. 10.9.15. 05/02/10.
D.18.7 General
1) No .LOG files created when interactive programs such as MX or P1X are
run in KEY + VDU mode. Also in 10.8.21. 12/01/09.
2) If the file sat10key.dat cannot be opened because it is temporarily in use by
another program running in parallel the program pauses briefly and tries
again. Also in 10.8.21. 15/01/09.
3) Unidentified “tokens” on a command line now result in Fatal Errors; e.g.,
trying to invoke PASSQ under SATALL instead of within SATNET. 10.9.7.
28/05/09.
4) Default .LP files created under commands such as MX I or even $MX (to
simply run the .exe file directly) are assigned names such as mx1.lpx,
mx2.lpx, if the normal default file mx.lpx is currently open. This may occur if
several jobs are being launched simultaneously. 10.9.8. 05/07/09.
5109341 / Mar 13 D-125

11_2_05_App D.docx
5) The program SATED is no longer included with the standard .exe files since
all its essential functions are embedded within P1X. 10.9.10.
6) LOG files have been made a bit more “robust” when converted to KEY files
by replacing certain blank lines by their equivalent defaults. For example, if
the reply to a Yes/No question was simply <return> implying the default of
Yes, then “Yes” is written to the LOG file rather than a blank line. This then
helps subsequent runs using KEY files to differentiate between certain
inputs. 10.9.19. 19/08/10.
7) As a general rule – but as yet not universally applied – if an output text file
has been given the extension .CSV then the output data is in “true” CSV
format in the sense that a comma is inserted at the end of each numerical
field. In particular this applies to the output of grand matrix totals in MX,
Section 10.14. 10.9.20. 12/09/10.
8) All complete listings of network namelist parameters (i.e., logicals, integers
and reals) now contain separate listings of just those parameters whose
values differ from the standard defaults; e.g., in SATNET, SATALL, P1X,
etc. 10.9.20. 20/09/10.
9) KEY files input to interactive programs previously had to have an extension
.key; this rule has now been relaxed such that the extension .log is also
permitted. This means that a LOG file produced by one program run may be
used directly as a KEY file in a later run without the necessity to rename it
with an extension .key. See 14.5.1. 10.9.21. 05/11/10.
10) In addition KEY and/or VDU files may be defined on a command line by
virtue of their extension without necessarily following the keyword KEY or
VDU. Thus instead of P1X net KEY jim one could write P!X net jim.key. Or
equally P1X net jim.log. See 14.5.1. 10.9.22 15/12/10.
D.18.8 P1X
1) A red bar has been added on individual node plots to indicate when an exit
and/or entry link is blocking back. Also in 10.8.21. See 11.2.2. 24/01/09
2) Blocking back values on both entry and exit links has been added to set 3 of
the link data as displayed under individual node graphics. 24/01/09
3) An explicit option to print standard Node Table 2 (Flow and delay data) from
within Node Graphics and/or the last table previously used has been added.
Also in 10.8.21. See 11.2.3. 27.01/09
4) Output to .JPG files should now be operational. Also in 10.8.21. 01/02/09.
5) Differences in network coding of individual simulation nodes between
networks 1 and 2 may now be “highlighted” and node graphics loops over
those nodes that differ may be initiated. This is a very useful option for
discovering what other people have done to your network and not
documented while you were on holiday! A complete table of differences per
node is printed out automatically to the .LPP file (but, for the moment, can
only be viewed by going to the .LPP file afterwards, not interactively). A
5109341 / Mar 13 D-126

11_2_05_App D.docx
similar option is also available in SATLOOK; see note 3) in D.18.9. See

11.6.5.4. 20/03/09.
6) Similarly within the SATLOOK standard text tables a new option, #25, has
been added to print a full list of coding differences for an individual node.
N.B. Only available when SATLOOK is called as a sub-component of P1X,
not with SATLOOK as a free-standing program. See 11.11.1. 20/03/09.
7) Under network editing the 11111 data segment when $INCLUDE files have
been included P1X now keeps track of whether changes have been made to
simulation nodes within individual $INCLUDE files and offers the option at
the end of node editing to only re-create those files which have been
updated. 10.9.7. 10/05/09.
8) In node graphics it is now possible to jump directly to an adjacent node by
clicking on its node number at the end of its arm on the current plot – rather
than selecting the option from the banner and then clicking at the end of the
arm. See 11.2.1. 10.9.7. 12/05/09.
9) Double clicking on a simulation node whilst in network plots will lead directly
to node graphics for that node. See 11.2.1. 10.9.7. 20/05/09.
10) When editing simulation nodes under node graphics it is now possible to
return directly to the same data field as previously edited without having to
repeat all the intermediate steps. E.g., if you have recently re-set the
saturation flow for one particular turn you may choose to repeat the identical
operation with one mouse click. 10.9.7. 30/05/09.
11) The logical namelist variable PANDP in the “standard” preferences file
P1X0.DAT has now been set to T (so that the “pick’n’plot” rule is applied
when selecting new link data to annotate as opposed to “Add to D.B.”) in
accordance with the default set within the program. Apparently it may have
alternated between T and F in recent releases. If you prefer it to be F (e.g.,
because you have various key files implicitly that assume it is F) then you
will need to amend your preferences file accordingly. 10.9.7. 01/06/09.
12) Forest display now includes measures of the path-averaged time, distance,
speed, etc. etc. in the banner. 10.9.10. 30/07/09.
13) Around 20 extra items have been added to the lists of link data that may be
selected for annotation to include, e.g., flows aggregated over vehicle
classes, crow-fly distances and differences between crow-fly and coded link
distances, links which are part of “chains”, simulation convergence statistics
per link, etc. etc. See Appendix I.1. 10.9.13. 23/10/09.
14) Similarly extra items have been added to the list of simulation turn data as
used either for network-wide turn annotation or for individual node graphics.
See Appendix I.2. 10.9.13. 23/10/09.
15) The “housekeeping” menu under link display now contains an option to
delete data base columns as well as to hide/display them. 10.9.13.
15/11/09.
16) The lists of “10 worst” convergence parameters now includes a measure of
how much signalised junctions might be improved through signal
5109341 / Mar 13 D-127

11_2_05_App D.docx
optimisation ranked by the amount by which the maximum V/C ratio could
be reduced. This helps to identify badly coded junctions which may be
impeding convergence. 10.9.13. 01/12/09.
17) Options have been added so that when a new file containing X,Y co-
ordinates is created the format may be changed (e.g., to CSV from fixed
column) and the factor XYUNIT may be explicitly added so that the co-
ordinates are output in units of metres. See 11.9.7. 10.9.14. 12/09/09.
18) The Select Link Analysis main menu now displays the filename of the trip
matrix being assigned and allows it to be re-defined (so that if you want to
do a SLA for network 2 you may also select the trip matrix from network 2).
See 11.8.1.8. 10.9.15. 05/02/10.
19) The node graphics displays now explicitly plot flared lanes, both nearside
and offside. See 11.12.2. 10.9.15. 01/02/10.
20) A new link data set consisting of “link properties” such as flare lengths may
now be selected within node graphics. 10.9.15. 01/02/10.
21) A new “resume” option automatically creates (/overwrites if necessary) a file
last_p1x0.dat containing all the relevant parameters and window information
at the point of exit from P1X such that that file may be picked up by the very
next run of P1X enabling the next run to resume with the same conditions as
the last. Extremely useful! See 11.4.4. 10.9.15. 13/02/10.
22) A link to the display of all individual bus routes has been added within the
Validation menu; at present only those with timing points may be accessed.
26/03/10. 10.9.16.
23) An option to print a full table of bus route summary statistics (currently
option 6 within SATLOOK) is now available under Information/Bus
Routes/Options. 26/03/10. 10.9.16.
24) The validation of timed routes now permits an average turn delay to be
included within the final simulation link of a timed route so as to be
consistent with the other definitions of timing points. See 11.7.2.1. 31/03/10.
10.9.16.
25) A text output file may be created containing a full list of all nodes formed by
the union of two topologically different networks with their common
sequential node numbers. See 11.4.2. In turn this may be used by
SATCOBA; see D.18.12. 10.9.16. 01/05/10.
26) The “double-click” option to select a node for node graphics is now entered
into the log files and will be correctly recognised in subsequent key files.
See 11.12.1. 10.9.17. 08/05/10.
27) The “resume option” (21 above) has been extended such that the file
last_p1x0.dat not only contains the co-ordinates of the last window used, it
also remembers all the previously saved windows from the previous run
(which might also be entered in a .WXY file). 10.9.17. 11/06/10.
28) Node graphics images may now be output as .JPG files. 10.9.17. 12/06/10.
5109341 / Mar 13 D-128

11_2_05_App D.docx
29) The “resume option” (see 21) above) may also be invoked immediately on
entry by including the key word “RESUME” on the command line. 10.9.18.
03/07/10.
30) The definition of “stack” as used in the calculation of QoverS has been
changed so that it equals the value as used in blocking back calculations,
i.e., the combined stacking capacity of the chain if the link is part of a chain
of in-series links; otherwise the normal link stacking capacity. This avoids
the “presentational” problem of Q/S values appearing as greater than 100%
when in fact there is no blocking back on the link/chain. See 8.5.5.5.
10.9.18. 04/07/10.
31) The “vertical” or “global” editing of link data has been extended to include
the capacity indices which are stored on the second link record. See
11.9.17. 10.9.18. 05/07/10.
32) Destination zones which cannot be reached from a particular origin during a
“plot to all zones” tree build and which may be a consequence of a
disconnected network are indicated by a large red X. See 11.8.3, option c).
10.9.18. 22/07/10.
33) While editing individual simulation nodes it is now possible to move to an
adjacent node by clicking on its A-node number directly within the node plot
rather than having to “quit” the current node and then select another node.
10.9.19. 19/08/10.
34) In the editing of simulation node data (e.g., within PMAKE) it is now
assumed that any comment records that precede the node record the .dat
file are part of that node’s records and they are therefore included within the
editing process where they may be modified by screen editing. As
previously any comment records within the node data are also included
within editing but any comments at the end of the node records (i.e., beyond
the link or signal data) are assumed to refer to the following node. See
11.9.3. 10.9.19. 19/08/10.
35) New little green arrows in the middle of each boundary line have been
added to move the window up, down etc., along with arrows in the 4 corners
to shift the window at 45 degrees plus two small circles with plus/minus
signs to indicate zoom in/out. So the same functionality as appears on the
menu bar as Nav-L etc. but hopefully more intuitive. See 11.5.5. 10.9.20.
14/09/10.
36) Editing link and/or turn data within node graphics has been easier by
introducing small “target boxes” at the end of each arm to select a link or
later a turn. Subsequent data editing is then based on the use of Windows
edit boxes. See 11.12.4. 10.9.20. 14/09/10.
37) The “vertical field” editing may now use a single fixed value to be applied to
all (or a selected subset of) nodes and/or links as opposed to defining
individual values per node or link via an external data file or internal data
base column. 10.9.21. 23/10/10.
5109341 / Mar 13 D-129

11_2_05_App D.docx
38) The “auxiliary network plot” which shows the position of the current window
within the full network now re-appears each time a new window is created.
See 11.5.4. 10.9.21. 27/10/10.
39) The criteria for “selecting” nodes for display have been extended in order to
select either (a) nodes which have been retained in a spider web
aggregated network (15.56) or (b) are treated as “moons” or “dependent
simulation nodes” within the simulation (8.5.3). See 11.6.5.3. 10.9.21.
21/11/10.
40) Within node graphics if two arms at a node are very near one another such
that any notation (e.g., A-node numbers) at the end of the arms overlaps,
the notation is moved sideways to eliminate the overlap. 10.9.21. 21/11/10.
41) The option to annotate bus flows on (nearside and/or offside) bus lanes has
been extended to include flows on bus-only links. 10.9.23. 24/01/11.
42) All bus flows may be optionally displayed in units of either vehicles (i.e.,
buses) per hour or PCUs per hour – provided, for the moment that all buses
have a common BUSPCU factor. 10.9.23. 25/01/11.
43) A “quick toggle” switch to swap between numerical and geometrical (e.g.,
bandwidth) link annotation is now provided. In most cases this will mean
either numbers on links or bandwidths but if, say, the option to print
numerical boxes was selected most recently from the full set of display
options then that becomes the default “numerical” toggle. Ditto with
alternative geometrical options such as variable intensity etc. 10.9.23.
19/02/11.
44) An option to temporarily “suspend” link selection has been added. Thus if
there is a link selection rule in force it can be turned “inactive” without losing
all the select information and therefore turned “active” at a later stage.
10.9.23. 20/02/11.
45) A number of “toggle options” have been added to the pull-down menus
under Display and Windows on the menu bar. For example both the
switches noted above under 43) and 44) are included under Display.
Equally, for example, the option to print node numbers offset is also
available under Display. 10.9.23. 19/02/11. The set of options available from
the pull-down menus has been further extended under 10.9.24.
46) New options have been introduced to process .ERL files in which the two
extra data fields have been used to distinguish, e.g., recently introduced
errors from older ones. Development is ongoing but the basic idea is to
allow a “selective” highlighting of various errors using information from the
.ERL files rather than the complete list of errors as detected by SATNET
and stored on the .UFS file. 10.9.23. 25/02/11.
47) Simulation zones which have identical centroid connectors may be
aggregated into single zones under network editing / PMAKE using the
lowest zone numbers. Common examples are multiple external zones all of
which are connected onto a single external simulation node. See 11.9.4.1.
10.9.23. 09/03/11.
5109341 / Mar 13 D-130

11_2_05_App D.docx
48) The batch file procedure SIGOPT (15.31.6) which makes use of P1X now
edits stage times and/or offsets of those simulation nodes which have been
coded within $INCLUDE files by explicitly incorporating all such files within
the new output .dat file. At the same time the sigopt.bat file itself has been
upgraded to make it easier for the user to define the name of the new .dat
file. 10.9.24. 30/03/11.
49) Data contained in .ERL (Error Listing) files may now be used to highlight
those nodes that satisfy certain criteria based on the values in either of the
two “extra” fields which may be manipulated by the users. For example, it is
possible to externally assign different numerical values in the second field
(e.g., using Excel) to indicate the degree of “urgency” associated with each
particular error and to highlight these using different colours in P1X. See
11.6.5.4 and 15.58.2. 10.9.24. 22/04/11.
50) A command line such as “P1X network 485” causes the initial network
window to be opened with node (/zone) 485 in the middle. The option is
invoked whenever a pure numerical value is input on the command line. See
11.5.6. 10.9.24. 27/05/11.
D.18.9 SATLOOK
1) A facility to skim O-D time, distance and tolls simultaneously from a forest
(as opposed to carrying out 2 or 3 separate skims in order to reduce CPU
time by a factor of roughly 2 or 3) has been added. This may be called either
interactively under main option 9, via a standard batch file SKIM_ALL (cf
SKIMTIME, etc.) or in SATTUBA. See 15.27.7. Also in 10.8.21. 24/01/09.
2) An option has been included within SATTUBA to exclude all times and
distances on centroid connectors (which, in practice, means buffer centroid
connectors) from skims on the assumption that they are essentially arbitrary.
However toll skims continue to tolls on include centroid connectors. See
XCCSK under 15.41.4. 10.9.8. 10/07/09.
3) An option to print all differences in coding between common simulation
nodes in networks 1 and 2 is now available but only when SATLOOK is
called as a sub-component of P1X. See also note 5) under D.!8.8 above.
See 11.11.18. 10.9.10. 14/08/09.
4) The filename conventions used in SATTUBA and SKIM_ALL etc.have been
changed such that an output time file net.t.ufm becomes net_t.ufm; i.e., full
stop becomes an underscore. 10.9.13. 01/12/09.
5) SKIM_ALL now outputs up to 4 skimmed matrices by including a matrix of
time penalties (in seconds) if any exist. 15.27.7. 10.9.16. 21/04/10.
6) A new set of O-D skimming algorithms have been introduced under
standard batch procedures such as SKIM_TIME, SKIM_ALL, etc. etc which
are more CPU-efficient than the old versions and also form the basis for
new multi-core versions. On the other hand they use more RAM so, for that
reason, they are only available in the standalone batch version of
SATLOOK, not in the interactive versions and/or accessed via P1X. See
15.27.8. 10.9.17. 07/05/10.
5109341 / Mar 13 D-131

11_2_05_App D.docx
7) Turning flows at (all) buffer nodes may now be output (a) to an external text
file (as opposed to just the .LPL file) and (b) in a one-record-per-turn format
(as opposed to an in-bound out-bound matrix format). See 11.11.12.
10.9.22. 28/12/10.
D.18.10 MX
1) The ratio of the maximum number of rows permitted relative to the
maximum number of columns permitted has been increased from 3 to 6.
This means that a matrix with 6 levels will always be accepted even if the
number of rows/zones exactly equals its maximum. However, if you have
fewer zones/rows than the maximum, the number of permitted levels will
increase in proportion. 10.9.5. 20/03/09.
2) The maximum number of rows has been further increased to 9 times the
columns/zones in order to provide even more “headroom” for stacked
matrices in 10.9.13. 25/10/09.
3) An option to define sectors by zone interactively added. 10.9.8. 18/06/09
4) Matrices dumped in EMME/2 format to ascii (.txt) files may now have their
number of decimal places defined. 10.9.8. 20/06/09.
5) The first matrix input into MX as part of standard matrix batch files MXADD,
UFM2CSV, etc. etc. is now closed immediately after it has been read in in
order to reduce the possibility that two separate applications of MX (or
indeed any programs) operating in different cores will both try to open the
same matrix file at the same time. 10.9.13. 23/10/09.
6) The QUIET option can now be included in the command line for M1 and
MXM1 so that a matrix can be created from a .dat file without grabbing the
screen at all. Release Version 10.9.14 09/12/09.
7) The standard batch files UFMSTACK and UFMUNSTACK now have an
option to run in QUIET mode. Release Version 10.9.17. 09/06/10.
8) Further to 3) above a further option has been added to define sectors by
zone using an explicit external text file which by default has the extension
.Z2S and consists of one record per zone giving the zone name and its
sector. See 10.2.5. 10.9.19. 27/08/10.
9) Equally a .Z2S filename may be included as a namelist parameter within a
matrix .dat file such that the zone-to-sector conversion is permanently
stored within the .ufm file structure. 10.9.19. 27/08/10.
10) Matrix row and/or column totals may now be output in a CSV format,
basically one record per zone with options to in/exclude sequential row
numbers, zone names, etc. etc. See Section 10.14. 10.9.20. 11/09/10.
11) “Cut” and “Paste” operations have been added such that an individual sub-
matrix may be extracted (cut) to a .ufm file from a stacked matrix or a
square input matrix may “over-write / paste” an existing level in an internal
stacked matrix. See 10.4.2 and 10.16. 10.9.20. 22/09/10.
5109341 / Mar 13 D-132

11_2_05_App D.docx
12) Factoring of selected areas of a matrix may now be easily applied to a

single level only over a stacked matrix. See 10.7.2 and 10.7.3. 10.9.20.
22/09/10.
13) The procedures by which a .ufm matrix may be updated using text data read
from a CSV file now allow the text file to be in fixed column format with
spaces between each numerical entry rather than commas. In particular this
applies to the batch file CSV2UFM. Note that UFM2CSV creates a text file
which is “true” CSV (commas between values rather than spaces) so not a
problem currently for re-input via CSV2UFM but that format might be altered
if the file is processed and re-gurgitated by, say, Excel. 10.9.24. 17/03/11.
14) In addition, when updating a .UFM file from a CSV file, the row/zone names
are now taken from the original input .ufm file rather than defaulting to
sequential names as at present. 10.9.24. 16/03/11.
D.18.11 SATCH
1) The default value of DEMAND has been changed to F; i.e., output trip
matrices are based on actual flows, not demand flows, by default. 10.9.6.
17/04/09.
2) A second table has been added comparing O/D totals in the output trip
matrix with the corresponding network flows after Furnessing has been
carried out. 10.9.6. 17/04/09.
3) The batch file has been extended so that a single user class output trip
matrix may be requested via the command line by including, eg., NOMAD 2
at the end of the line. Its primary function is to be used as part of a new
multi-core distributed batch file SATCH_MC described next. 10.9.24.
15/04/11.
4) Multiple user class matrices may now be produced “in parallel” using
multiple processors via the batch file SATCH_MC which allocates one user
class per processor to produce a series of individual user class (square) trip
matrices and then stacks them into the required multi-level trip matrix. (Yet
to be finalised). See 12.1.6 and 15.23.2.6. 10.9.24. 22/04/11
D.18.12 SATCOBA
1) Two new options have been added to (a) output flows from a single network
disaggregated by vehicle class (in addition to by user class) and b) to output
such flows in units of either PCUs/hr or vph. See 15.42.2. 10.9.10. 13/08/09.
2) A new option permits a node conversion file to be input so that 5-digit node
numbers may be converted to 4-digit numbers with the added benefit that
the same conversions may be applied across any number of networks which
may have different nodes included (e.g., do something vrs. Do-min). See
15.42.6. 10.9.16 01/05/10.
D.18.13 SATPIG
1) New options have been added to control (and in particular to increase) the
number of paths output. Thus if ALLOD = T at least one route is included for
5109341 / Mar 13 D-133

11_2_05_App D.docx
every O-D pair whether or not it has any trips in its trip matrix cell. Equally a
new parameter PODMIN sets an inclusion test based on a minimum fractional
use of a path – in addition to FPHMIN which tests the absolute flow in pcu/hr.
See 12.6. 10.9.10. 14/08/09.
2) Output files under TRPFOR = T now include both the absolute flow in pcus/hr
and (new) the fractional flow on the first record for every route.
3) A option to output all path data in CSV format with all numbers on a single
record has been introduced. Set the new Namelist Parameter CSVFOR = T.
10.9.24. 19/03/11
D.18.14 CASSINI
1) A new program to enable Network parameters such as MASL, NITA etc. to
be adjusted between external demand loops dependent on the level of
convergence reported by the demand model (e.g., DIADEM) in order to
“relax” the convergence criteria for the SATURN assignment. See 15.54.
10.9.10 04/09/09
2) Renaming of the CASTXT options to either ‘DIADEM’ (the default value) or
‘Other’; previous versions had problems in selecting non-DIADEM formats
for CASSINI to correctly read-in. See 15.54 10.9.22 06/12/10
D.18.15 SATWIN
1) Option to link the various files used by SATURN to their respective
programs within Windows Explorer. See 3.6.6. 10.9.12 26/10/09.
2) Increase in the number of different sets of SATURN executables that may
be selected on the start-up screen from 10 to 15. See 3.6.1. 10.9.12
26/10/09.
3) For each event, the selected working folder and program folder are saved to
enable previous ‘events’ to be re-run more easily. Option to ‘save’ event log
for subsequent re-importing back into SATWIN. See 3.6.5. 10.9.12
26/10/09.
4) Location of temporary SATWIN.BAT files moved to core install directory (eg
C:\SATWIN\TEMP)
5) New options to select QUICK / QUIET = TRUE for all SATURN programs
through toggle option. See 15.55 10.9.10 04/09/09.
6) Introduction of a new ‘Non-Core Alternatives’ sub-menu that enables users
to run either:
• the previous v10.9.12 releases of SATNET and SATALL exe’s rather than
the new SATURN 10.9.17 versions (as called by SATNETX.BAT and
SATALLX.BAT separately or SATURNX.BAT combined); or
• a hybrid option of SATNET v10.9.17 and SATALL v10.9.12 (as accessed
by SATNET.BAT and SATALLX.BAT separately and SATURNH.BAT
combined) that will provide the benefits of more comprehensive network
coding checks whilst still using the earlier SATALL version.
5109341 / Mar 13 D-134

11_2_05_App D.docx
7) NB: replaced with v10.9.22 and v10.9.17 hybrid. 10.9.22 26/01/11

8) NB: replaced with v10.9.24 and v10.9.22 hybrid. 10.9.24 31/05/11
9) New ‘Developer’ option under the Module sub-menu to provide access to
DACHEX, DADUMP, DALOAD and DALOOK 10.9.22 06/12/10
10) Labels added to the SATWIN Module menu and dialogue boxes to aid
identification, re-grouping of modules into new ‘application’ groups and review
of supplied batch files and modules. 10.9.24 31/05/11
11) Multi-core options available (as indicated by ‘+MC’ suffix) within the SATWIN
modules for SATPIJA, SATUFO and SATCH operations. 10.9.24 31/05/11.
12) Settings option to manually select P1X0.DAT version (e.g. v10.9.17) for the
appropriate $P1X.EXE being used. This resolves a problem with backward
compatibility between the P1X0.DAT and the $P1X.EXE introduced with
10.9.17. P1X may crash with a Runtime Error 52: ‘Invalid character in field’.
Users are able to select the DAT file to use from the ‘Settings’ menu. (NB: an
automated system will be introduced at a later date) 10.9.24 31/05/11.
1) Full updates have been carried out for the November 2009 release of
10.9.12 as well as for 10.9.17 in June 2010, 10.9.22 in January 2011 and
10.9.24 in May 2011.
2) The 10.9.17 release contains new Appendices R, S and T which contain
print-outs of two recent ETC papers on OBA, CASSINI and Network
Aggregation plus a copy of a more ancient paper by DVV on tree-building
algorithms which is relevant to network aggregation.
DVV / IW 03/10/11
5109341 / Mar 13 D-135

11_2_05_App D.docx
DATE OF LAST UPDATE: 15th OCTOBER 2012

SATURN 11.1 was first released in pre-Beta versions in June 2011 as 11.1.1, as
11.1.2 in August 2011 etc. etc. up until its first full release as 11.1.8. in January
2012 and its final full release 11.1.9 in April 2012. Various incremental corrections
were made thereafter to correct specific problems and various one-off releases
made to specific users.
The most prominent new advance in 11.1 as compared to previous releases is the
full introduction of “Network Aggregation” or “SPIDER” techniques which have
been available on Beta-release in 10.9. Basically SPIDER allows the assignment
sub-module within SATURN to be run up to 10 times faster than traditional
methods. In addition the same ideas may be applied to a wide range of post-
assignment analyses such as Select Link Analysis although some of these
applications are still effectively on Beta release and more will be added in later
releases.
For a more complete description of SPIDER methods see Section 15.56.
As always, in terms of backwards/forwards compatibility, the 11.1 network .dat
files contain several new features (e.g., parameter names) which will not be
recognised by pre 11.1 versions of SATNET but will not cause the program to
crash; however pre 11.1 .dat files will be read perfectly happily by 11.1. Similarly
11.1 network .ufs files contain new arrays which older version exe’s will be able to
read but not recognise whereas 11.1 exe’s will be able to read pre 11.1 ufs files.
Matrix .ufm files have not fundamentally changed and should be both forward and
backward compatible.
In terms of results there have been a large number of both relatively major and
minor changes to the simulation so that one might expect 11.1 to give different –
possibly significantly different – results to pre 11.1. For this reason the opportunity
has been taken to change the default values of a number of parameters, typically
options that were introduced in recent releases but “turned off” by default are now
“turned on” having been verified in practice. E.g., see notes under SATNET.
Our advice therefore would be to re-run old networks “from scratch” and certainly
not to do comparisons between 11.1 outputs and pre 11.1 outputs.
which were also included in latest released versions of 10.9, i.e., 10.9.25 (and
may also be in the very latest versions of 10.9 which are not on general release).
Each note should give the precise release number in which the change was
introduced (e.g., 11.1.3), the date and references to relevant sections in the
Manual.
D.19.1 SATNET
1) APRESV has been made a link-dependent variable which may be set on the
second link record as currently done for TAX, FLAREX and FLAREF. See
6.4.14 and 8.8.3.1. 10/06/11
5109341 / Mar 13 D-136

11_2_05_App D.docx
2) New parameter KARL (default = 50) to control when repeated error

messages in certain circumstances (e.g., coded distances different from
cow-fly distances) are suppressed. See 6.3.2. 23/06/11.
3) NO333C = T (which allows zone numbers to be input without a C) has been
correctly installed and also applies to data input under KNOB files. See
15.14.5.1. 11.1. 02/08/11.
4) The minimum value of NITA_S has been upgraded to 99 from 25. See 6.3.2.
11.1. 05/08/11.
5) The rules for identifying a large input capacity such as 9999 as a “dummy”
which is effectively treated as an infinite capacity but very often printed as
zero or blank have been changed. 9999 is still a dummy but any values up
to 18,888 are treated as “real” on the basis that a 5-lane motorway may
genuinely have a 5-digit capacity, 11.1. 23/09/11.
6) Banned and/or penalised turns at buffer nodes may now be modelled
provided that SPIDER = T and the node in question has been aggregated
(i.e., removed) by the network aggregation procedure. Thus the 44444 data
may now include banned turn data. See 6.7 and 15.56.7.1. 11.1.1. 15/08/11.
7) The rules under which bus routes are allowed to use bus lanes have been
improved to consider where the bus route goes next. Thus, for example, a
bus route which turns right from the most offside lane on a link would not be
allowed to use a nearside bus lane on that link but would have to join the
“normal” traffic as a fixed flow on the central lanes. See 15.39.1. 11.1.3.
09/10/11.
8) Bus routes are now allowed to exit and re-enter the coded network at non-
adjacent nodes, e.g., to represent a route which uses minor roads which
have not been included in the main network. An exit/entry is indicated by
including a “wildcard” node number KANGA (default 9999) in the normal list
of nodes. See note 12), Section 6.9.2. 11.1.3. 20/10/11.
9) A new set of parameters ERRNO(n) allows selected Warnings, Serious
Warnings and Non-Fatal Errors to be upgraded to Semi-Fatal Errors, in
effect, a form of DIY WRIGHT = T selection of “vital” errors. See 6.12.3.
11.1.5. 11/12/11.
10) Options have been introduced to edit or modify bus routes by either
including an initial “delete” record to remove a route with the same name
which appears later within the 66666 records or over-writing route
frequencies also using a previous 66666 record. See 6.9.6. 11.1.8.
13/01/12.
11) The default value of NUC has been changed to 10 from 15. The use of
AUTNUC = T or setting NUCJT(3) > 10 for signals is strongly
recommended. N.B. If NUC is explicitly set in your .dat file changing the
default has no effect. 11.1.8. 27.01/12.
12) Non-Fatal errors 285 and 286 – repeated &OPTION or &PARAM records –
are now, by default, NAFF under WRIGHT = T. 11.1.9. 15/03/12.
5109341 / Mar 13 D-137

11_2_05_App D.docx
D.19.2 SATALL
1) The post-assignment procedure SATUFC which generates a .UFC file to
enable O-D paths to be examined has been extended to accept networks
which were originally run using OBA and for which the .UFO files are not
suitable for all possible analyses, e.g., SATPIG. See 15.23.5. 11.1.1
10/06/11
2) An extra parameter MASL_M (set under &PARAM in SATNET) sets a lower
limit on the number of simulation-assignment loops. See 9.2.3. 11.1.1.
13/06/11
3) The rules which determine the convergence parameter UNCRTS in the
extra SAVEIT assignment have been altered so that it equals the
assignment-simulation GAP value. This should ensure that the SAVEIT
assignment neither terminates prematurely nor takes excessive iterations.
See 15.23.4. 11.1.1. 13/06/11
4) Extra stopping criteria for the assignment-simulation loops with KONSTP = 5
and 6 have been added based on GAP and ISTOP (5) and GAP or ISTOP
(6). See 9.2.3. 11.1.1. 15/06/11.
5) An alternative REAL form of ISTOP, RSTOP, has been added which allows
the critical stopping criteria to take on values such as 97.3% rather than 97
or 98%. The stopping tests are now all based on the “real” value RSTOP
although, due to the way in which integer rounding took place before, the
end effect is the same. See 9.2.6.
6) The method by which a .UFO file is created following a “normal” Frank-
Wolfe assignment (i.e., not OBA) has been made considerably faster by
making use of a Spider network (assuming that SPIDER = T) plus an
improved internal algorithm. The same methods are also used when the
batch procedure SATUFO is run on its own. See 22.5.3. 11.1.6. 12/12/11.
D.19.3 Simulation
1) The “rules” for modelling Y-merges have been altered to allow APRESV to
have an impact on either arm. See 8.8.3.2. Note in addition that APRESV
may now be set as a link-specific value; see 6.4.14 and note 1) under
D.19.1. 11.1.1. 13/06/11.
2) BB109 is always .TRUE. now (Or, strictly speaking, its value is ignored
since wherever it was previously invoked the program now assumes it is
TRUE.) 28/08/11.
3) Simulation nodes with fixed cost-flow curves (FCF) introduced as well as an
improved method to convert intermediate simulation networks into buffer
(BST). See Section 15.1. 11.1.2. 09/09/11.
4) Blocking back has been “tightened up” on links where there is either (a)
traffic entering from centroid connectors at the downstream end of the link or
(b) buses exiting from the downstream end. The convergence of the
blocking back factors should be improved although the overall impact may
not be great. 11.1.3. 17/10/11
5109341 / Mar 13 D-138

11_2_05_App D.docx
5) Random delays now contribute to extra queues on links but only if a new
parameter SIM111 = T. See 8.6.5. 11.1.3. 17/10/11.
6) Turns at signals which have been coded with an X but whose green phases
are terminated by stages where there are no opposing turns (i.e., by a late
cut-off) do not now qualify for an extra TAX capacity at the end of their
green phases. They are currently identified as Warning 79 in SATNET. See
6.4.2.2 and 8.2.4. 11.1.8. 19/01/12.
7) Capacity reductions caused by “weaving” between motorway junctions
(Section 15.40) may now be modelled even when network aggregation
(SPIDER = T) is being used; previously it could only be invoked if SPIDER
was not used. 11.1.8. See 15.56.7.
8) Blocking back rules have been substantially revised for links which are parts
of chain. Thus, rather than allowing “internal” blocking back as described in
Section 8.5.5.1 of the manual to “spread” the queue within the chain, the
“internal” blocking back has been removed in order to (empirically) improve
convergence. Thus the full queue is calculated and allocated at the most
downstream link in the chain, the blocking back factor is applied at the most
upstream link but there is now no blocking back and/or queues on any of the
intermediate links. The net impact should be much the same as at present
since the important blocking back factor which is at the upstream end of the
chain should be the same as before; the main differences are presentational
in terms of the distribution of the queue along the links in the chain. 11.1.9.
15/03/12.
D.19.4 P1X
1) Green arrows to change window positions made active during Joy Ride
calculations. 11.1.1. 23/06/11.
2) Right mouse click to move up one level on the banner menus; i.e.,
equivalent to Quit/Return/etc. 11.1.1. 16/08/11.
3) An option is now provided to directly enter the node selection procedures
from within Global Signal Optimisation within Network Editing, rather than
having to do node selection first. 11.1.2. 23/08/11.
4) The option to read node data into the SATDB node data base directly from
an external ASCII file has been extended such that the file need not contain
any node data, simply a list of node numbers which are used for selection
purposes only. Note, however, that a very similar option is already available
within the existing Node Selection procedures. 11.1.2. 23/08/11.
5) A text file network description corresponding to the map network links may
be output from within either Output Files (11.4.2.3) or Network Edits
(11.9.2.5). These files may optionally refer to a sub-set of all map links; e.g.,
simulation centroid connectors only. 11.1.2. 09/09/11.
6) All outputs from Node/Zone/Link Information now go to the .LPP file well as
to a separate window. 11.1.2. 26/09/11.
5109341 / Mar 13 D-139

11_2_05_App D.docx
7) PMAKE (network editing) permits an existing network .dat file to be

converted into an alternative form whereby each data segment (11111,
22222 etc.) is created as a separate file which is referenced by $INCLUDE
in the main .dat file. See 11.9.2.6. 11.1.2. 03/10/11.
8) An extra option (#24) in the SATLOOK node flow-delay tables allows the
differences in flows and delays between networks 1 and 2 at a single node
to be displayed. 11.1.3. 24/10/11.
9) Speeds may optionally be output as MPH rather than KPH (although maybe
not as yet in every possible location throughout P1X). 11.1.4. 10/11/11.
10) Select Link Analysis has a new option to carry out the analysis on
“multiple” links; i.e., a series of individual links which are treated in a single
pass with the select flows being stored in discrete data base columns. See
11.8.1.11 11.1.4. 10/11/11.
11) Selected Link Assignment may also now take advantage of Spider networks
(SPIDER = T) which means that SLA calculations become considerably
faster by factors of up to 10 times. See 11.8.1.12. 11.1.8. 27/01/12.
12) SLA link flows on links which are either upstream or downstream of a
selected link may now be “filtered” in or out; e.g., one may identify only
those flows which occur after a selected link has been passed as these
would be the links affected if the selected link were blocked for any reason.
See11.8.1.13. 11.1.8. 27/01/12.
13) The geometry of node diagrams has been altered such that if two arms are
opposite one another (e.g., north and south) and their lane structures do not
match then the method for aligning them has been improved. 11.1.8.
27/02/12.
14) Various default parameters within Network Editing / PMAKE such as default
speeds on newly created links, etc. are now grouped within a single menu
which may be accessed from different points. 11.1.9. 03/03/12.
D.19.5 MX
1) An option has been included to output zero-value cells under Tuba 3 text file
outputs. See 10.15.1.5. Release 11.1. 20/07/11.
2) A new set of options has been added within Matrix Manipulation (Option 8
from the master menu) to deal specifically with intra-zonal cells. Either a
fixed value may be introduced or a value equal to 0.5 times the minimum
cell value within each (origin) row (where the latter application is specifically
designed to create an intra-zonal cost from an existing inter-zonal cost
matrix). See 10.8.7. 11.1.3. 22/10/11.
3) The batch procedure MXM5 has been extended to allow both row and
column (origin and destination) factors to be used and to be defined within
the control file. See Appendix W.3. 11.1.3. 22/10/11.
5109341 / Mar 13 D-140

11_2_05_App D.docx
D.19.6 SATCH
1) Certain errors in Namelist inputs (e.g., unrecognised text names) are now
upgraded to Fatal. Release 11.1 31/07/11.
2) The SPINE option has been upgraded so that rather than just defining a
start and end node (NODES and NODEF) to define an interpolated “spine”
various intermediate nodes (NODEM) may also be set. See note 7), 12.1.4.
Release 11.1 31/07/11.
3) A new option ADDXZ has been added such that, if F, then eXternal Zones
are not ADDed within the 22222 simulation centroid connectors. See note
8), 12.1.4. Release 11.1.2. 14/09/11.
4) A new option to produce a new network .UF file with the simulation nodes
outside the cordon indicated as “fixed cost flow” nodes: set DOFCF = T.
See 12.1.11 and 15.1.4. Release 11.1.3. 14/09/11.
5) New option INCLUD = T now creates the various 11111, 22222 etc. data
sets as external files referenced by $INCLUDE within the main network .dat
file. See note 10), 12.1.4. Release 11.1.2. 21/09/11.
6) New option SZONE = T means that the new zones in the cordoned network
are assigned sequential numbers 1, 2, 3 … rather than the “names” used in
the old network. See note 8), 12.1.4. Release 11.1.2. 28/09/11.
7) The output 55555 data segment includes default co-ordinates for the newly
created zones at each cordon point. 11.1.3. 17/10/11.
8) If the original network .dat file used $INCLUDE files plus TOPUP = T so that
simulation nodes were allowed to appear twice they will now only appear
once in the cordoned network .dat files. 11.1.8. 26/01/12.
D.19.7 SATDB
1) The maximum number of potential data base columns has been increased
to 48 with a minimum of 24 (previously 24 and 12). 11.1.4. 01/11/11.
D.19.8 General Changes

1) A set of procedures have been introduced with the objective of creating a
level of network representation which is intermediate between buffer and
simulation: the Fixed Cost Function (FCF) representation. See 15.1.
Release 11.1.3. 08/10/11.
IJW / DVV – 31/03/12
5109341 / Mar 13 D-141

11_2_05_App D.docx
D.19.9 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App D.doc
2 D.15 added DVV, Minor typos DVV 28/05/06

etc. In D-15
3.1i 10.6.15 updates added DVV 05/07/06
3.1ii Minor on-going updates DVV 14/07/06

(absorb App D17)

(absorb App D19)
5109341 / Mar 13 D-142

11_2_05_App D.docx
Appendix D20 - Changes in SATURN Version 11.2
DATE OF LAST UPDATE: 31st MARCH 2013

SATURN 11.2 was first released in pre-Beta versions as 11.2.01, 11.2.02 … for
internal testing starting in June 2012 and as a Beta full-release in December 2012.
A “full” release of 11.2.05 took place in March 2013.
The most prominent new feature in 11.2 is the expansion of the existing
secondary analysis processes to take advantage of the inherent efficiency of the
UFO/OBA files to store path information from the assignment. This removes the
requirement for the secondary analysis to rebuild the paths from the .UFC file
before any interrogation may be undertaken. Consequently, the majority of the
secondary analysis processes (e.g. skimming, select link analysis and SATCH)
will run much faster than previously.
It is also worth noting that development work continues with the Network
Aggregation techniques (previously released as part of 11.1) to improve its
performance as well as enabling OBA assignments to be warm-started using
SPIDER-based assignments.
As always, in terms of backwards/forwards compatibility, the 11.2 network .dat
files contain several new features (e.g., parameter names) which will not be
recognised by pre 11.2 versions of SATNET but will not cause the program to
crash; however pre 11.2 .dat files will be read perfectly happily by 11.2. Similarly
11.2 network .ufs files contain new arrays which older version exe’s will be able to
read but not recognise whereas 11.2 exe’s will be able to read pre 11.2 ufs files.
Matrix .ufm files have not fundamentally changed and should be both forward and
backward compatible.
In terms of results there have been a limited number of minor changes to the
simulation but nevertheless one might expect 11.2 to give different – possibly
significantly different – results to pre 11.2. Our advice therefore would be to re-
run old networks “from scratch” and certainly not to do comparisons between 11.2
outputs and pre 11.2 outputs.
which were also included in latest released versions of 11.1, i.e., 11.1.10 (and
may also be in the very latest versions of 11.1 which are not on general release).
Each note should give the precise release number in which the change was
introduced (e.g., 11.1.3), the date and references to relevant sections in the
Manual.
D.20.1 SATNET
1) The rules by which aggregated SPIDER networks are constructed have
been updated in several (relatively minor) respects. For example steps 5)
and 6) in Section 15.56. 3 where nodes with single exits/entries are treated
have been altered such that the nodes are completely aggregated as in
step 7); previously it was possible (though not very likely) for the central
node to remain which created problems for certain analysis functions.
5109341 / Mar 13 E-142

11_2_05_App D20.docx
2) Secondly, the maximum number of arms at nodes to be aggregated now

differentiates between simulation and buffer nodes; empirically it is found
that setting a lower limit for buffer nodes is beneficial (related to the fact that
all assignment links in the simulation network are one-way whereas buffer
links are mostly two-way. See 15.56.3.
3) The rules under which AUTNUC = T “optimises” the value of NUC per node
have been slightly modified so that, for example, instead of progressively
doubling the input value of NUC until a certain minimum value has been
reached, it now increments NUC by its initial value until the minimum is
reached. This results in smaller values of NUC and, as a by-product,
marginally reduces the memory required to store CFPs. See 15.15.2.
Release 11.2. 30/09/12.
4) The amount of RAM provided to store IN and OUT CFPs has been
increased by 50% in order to avoid having to move to larger release levels.
10/10/12.
5) Bus routes may now have “Delete” and “Frequency Edit” markers. See
6.9.6. 10/09/12.
6) The Namelist Parameters BB109 (8.5.5) and UFC109 (15.23.3) have both
had their default values changed to .TRUE. 11.2.1. 25/11/12.
7) A new parameter UFC111 has been introduced to replace one of the two
functions previously controlled by UFC109. Thus if UFC111 = T then output
.UFC files always adopt the convention that, for MUC networks, a single set
of link times are stored per assignment iteration as opposed to separate
sets of link costs for each user class independent of the value of UFC109.
Since the default is UFC111 = T this means that the UFC files virtually
always store times and the files are therefore much smaller. See 15.23.3.2.
11.2.1. 27/11/12. N.B. This may mean that some older .UFC files will be
“misinterpreted” by current analysis programs such as P1X and will need to
be recreated.
8) Setting a new Logical parameter TFL = T indicates that node and zone
names obey the hierarchical rules appropriate to Transport for London
networks. E.g., that the first digit of a 5-digit zone name gives a “sector” and
the first two define a “traffic borough”. Other similar numbering conventions
apply to node numbers. See 5.1.7 and 6.8(4). 11.2.2. 10/01/13.
9) In addition if TFL = T Serious Warnings are flagged if a node has all its
immediate neighbours located in different traffic boroughs (i.e., it is an
“enclave”) or if, similarly, a simulation zone is only connected to nodes
outside its borough. 11.2.2. 17.01/13.
10) KNOBS data files – which are text files – may now (a) have records with
more than 80 characters and (b) be fully specified in free format (i.e., the
node specifications do not need to be in fixed columns) by setting an
&PARAM variable FREEKN = T. See 15.14.5.1. 11.2.4. 01/03/13.
11) A new test on the values of LCY has been introduced in order to detect a
simulation node with, say, LCY = 60 when all its neighbours have LCY = 70.
5109341 / Mar 13 E-143

Serious Warning 183 (although probably a Warning would be sufficient. See

15.15.3. 11.2.4. 04/03/13.
12) The number of parameters in the &PARAM and &OPTIONS sections that
may be changed by the CASINI=T option has been increased. The full set
is defined below (with the new 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
D.20.2 SATALL
1) The post-assignment procedure SATUFC which generates a .UFC file to
enable O-D paths to be examined has been extended to accept networks
which were originally run using OBA and for which the .UFO files are not
suitable for all possible analyses, e.g., SATPIG. See 15.23.5. 11.1.1
10/06/11.
2) An “incremental assignment” variation on Frank-Wolfe assignment has been
included within the SAVEIT assignment with the objective of trying to reduce
“residual paths”. Its effectiveness is still under trial. See 7.11.13, 15.23.2
and 15.57.6. 11.2. 24/09/12.
3) The rules by which delays at very low flows are truncated to zero have been
changed by making the cut-off flow link dependent rather than a universal
value. This removes possible but extremely rare cases of “underflow” which
impact, for example on SATPIJA. The downside is very small differences in
outputs compared to earlier releases. 11.2. 06/10/12.
4) The algorithms used to calculate .UFO files from Frank-Wolfe have been
substantially improved both in terms of their accuracy but also in terms of
the required CPU time. In particular a multi-core element has been
introduced and enabled when MULTIC=T (and which effectively renders
SATUFO_MC redundant). See 15.53.
5) The option to use PARTAN assignment as part of the SAVEIT assignment
step has been extended to MUC by setting a Namelist parameter SPARTA
= T. See 7.11.7 and 15.23.4. An important benefit of using
PARTAN/SPARTA within SAVEIT is that, by (potentially) 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. 11.1.15. 15/11/12.
6) Simulation turns which have been assigned a nominally infinite capacity of
99,999 (which may be set by default) now must always have zero over-
capacity delays in the (unlikely?) event of an assigned flow exceeding
99,999 pcu/hr. 11.2.3. 20/02/13.
7) The format of the .UFO files has been extended to includet a representation
of both “normal” networks and “spider” networks so that the various analysis
functions (such as SLA, cordoning, etc.) have a choice of which
5109341 / Mar 13 E-144

representation to use (with the spider .UFO format being generally much
faster). 11.2.1.
D.20.3 Simulation
1) A number of small alterations / corrections to the simulation code – mostly to
do with flares – means that 11.2 gives slightly different outputs from 11.1.
2) A form of “relaxed convergence” has been introduced whereby the cyclical
flow profiles (CFP) on early iterations are treated as “flat” at junctions where
there is relatively little variability between time units. This may happen at
roundabouts or priority junctions but never at signals. By temporarily
redefining NUC as 1 this may lead to a substantial reduction in cpu time.
See 8.?. N.B. Not yet finalised at the time of first release.
3) The “rules” by which a flared lane is modelled have been altered in terms of
what happens to capacities if both the flared lane and the main lane have
queues back to the flare point. This means that the simulation will give
different results, especially when the V/C ratio for the lane is high and/or the
flare is relatively short. 11.2.3. 26/01/13.
D.20.4 P1X and/or SATDB

1) “Little things mean a lot”. Multiple minor changes have been made in P1X,
too numerous to mention individually.
2) Various post-assignment analyses such as SLA may now choose whether
to use a .UFC or a .UFO file if both are available. See 15.23.6. 24/10/12.
3) The command, say, P1X net 555 NG requests P1X to produce an initial
network window centred around node 555 but – the new addition of NG – to
go straight into node graphics for that node. 29/11/12.
4) Option added within the Node Display menu to allow only nodes (i.e., no
links) to be plotted. 11.2.3. 23/01/13.
5) The SATDB options to create and/or input .DBD files have been removed
since virtually all the same functions may be accomplished via text data
files. 11.2.3. 24/01/13.
6) A new option under Route Validation allows the full set of routes with timing
points to be analysed and the final timing errors to be associated with each
link in those routes. The mean errors per link, %errors per link etc. etc. are
stored in SATDB data base columns for further display, analysis, etc. See
11.7.2.5. Release 11.2.3. 27/01/13.
7) Bandwidth annotation has been enhanced by allowing: (a) a fixed width in
mm added to all bandwidths (to make very low/zero values more obvious);
(b) a minimum bandwidth (ditto) and (c) a maximum. See 11.6.3.2. 11.2.3
01/02/13.
8) Validation of routes with timing points included may now be carried out
using route data read directly from a text file rather than relying on data pre-
input at the network build stage and read from .UFS file. 11.2.3. 01/02/13.
5109341 / Mar 13 E-145

9) The link-based timing point validation statistics mentioned in 6) above may

be annotated using a particular set of pre-defined bandwidth parameters
referred to as their “hallmark” whereby pre-defined colours are chosen for
%error 0-15%, 15-30%, etc. etc. See 11.2.7.5. 11.2.3. 07/02/13.
D.20.5 MX
1) The Statistical Options now include a series of options to print a table of the
standard univariate statistics over all matrices, not just a single matrix. See
10.9.1. Release 11.1.12. 03/09/12.
2) Similarly the M2 comparisons of two matrices may now be applied to two
different “levels” within an internal stacked matrix. See 10.9.2. Release
11.1.12. 03/09/12.
3) Equally univariate statistics may be displayed for a single level and/or a
table of comparative univariate statistics for all levels within a matrix may
also be printed. See 10.9.1. Release 11.1.12. 04/09/12.
4) The rules for selection now include options to select either a single level of a
stacked matrix or a range of levels. See 10.6.1. 11.1.13. 11/10/12.
5) Screen printing has added tool bar options to jump to the next level up or
down and the ease of selecting an individual level to be printed from the
menus has been improved. See 10.10.2. 11.1.14. 24/10/12.
6) Setting a new Logical parameter TFL = T in matrix .dat files indicates that
node and zone names obey the hierarchical rules appropriate to Transport
for London networks. E.g., that the first digit of a 4-digit zone name gives its
sector. See 5.1.7 and 8) under D.20.1 above for network files. 11.2.1.
27/11/12.
D.20.6 SATPIJA
1) Counts which are to be input on the control file (UFFLOW = F) may now be
defined using a $INCLUDE record to set the name of an external data file.
Release 11.2. 22/09/12.
2) The array dimensions for the maximum number of IJ pairs per link have
been increased in order to accommodate extremely large (i.e., LoHAM)
networks. 11.2.4. 02/03/13. Ditto for SATME2.
D.20.7 SATME2
1) An option to treat the input counts as pure demand flows, rather than as
actual flows which need to be potentially factored up to allow for flow
metering at queued junctions upstream, has been introduced via a Namelist
parameter DEMAND. See Sections 13.1.4.2 and 13.2.2. 11.1.12. 09/09/12.
2) A new parameter FREE6 = T permits the combined link data input under
section 66666 to be in free format, e.g., CSV. 11.2.3. 01/03/13.
3) In order to process combined count constraints (6666 data sets) more
efficiently the input .UFP file is first copied into two “true” direct access files
5109341 / Mar 13 E-146

before the PIJA factors are added together. For large data sets (e.g. Loham)
speed up factors are of the order of 100! 11.2.4. 07/03/13.
4) In order to better monitor situations where combined constraint sets (66666
inputs) contain summed Pija factors > 1.0 due to multiple crossings and Pija
is capped at 1.0 a summation is kept of all Tij * (Pija – 1) to quantify the
extent of the problem. The information is printed to the .LPM files. See
13.1.8. 11.2.5. 29/03/13.
D.20.8 SATLOOK / Skimming batch files

1) SKIMDIST etc. have extra command line parameters USESPI and/or
USEUFO to explicitly request the use of spider, UFO options if not already
the default. Equally NOT_USESPI etc. to turn them off. See 15.27.3.
25/08/12.
D.20.9 New SPIDER Network Applications

1) A new method of analysis based on the concept of “hybrid networks” (part
aggregated SPIDER network, part normal network) has been introduced
Into SATCH and has been found to reduce the CPU needed to calculate a
cordoned trip matrix by around a factor of 10. See 15.56.7.2. 11.2.3.
21/02/13.
D.20.10 General Changes

1) Records in KEY files now contain a “menu check code” in columns 76-80 in
order to verify that the menu reading a particular record was the same one
that created it. I.e., it detects if KEY files are somehow out of synch. See
14.5.3. Release 11.1.14. 22/10/12
D.20.11 SATURN Multi-core

1) SATURN Multi-core functionality extended to the creation of UFO files from
FW assignments within SATALL (via SAVUFO=T option) and standalone
SATUFO.BAT process.
D.20.12 SATWIN
1) A new SATWIN graphical user interface (GUI) has been developed (using
Microsoft WPF) to replace the existing SATWIN version (after a decade of
good service!). The new SATWIN updates the existing workflows and
enables model specific set-up and operations and to be saved and re-
loaded. See section 3. In development for v11.2 release and made
available as a beta version.
D.20.13 New Licence Level (N4)

1) The existing Licence Levels beyond the standard N3 level have been
restructured to remove the proliferation of bespoke versions for individual
applications. The source code has also been restructured to reduce
memory requirements for these larger levels with a new standard ‘N4’
introduced. With the internal restructuring, there may be some issues of
backward compatibility for very large networks using SPIDER Network
5109341 / Mar 13 E-147

Aggregation as the network may not be able to be opened in subsequent

versions of P1X. In these situations, the user should revert back to the
earlier version that the original files were created in.
The changes are summarised below:
Array / Level Simulation Assignment Links Zones*

Junctions
B to N3
Unchanged – see Section 15.28
Standard
N3 21,000 200,000 2,000+ (default)

‘Standard’ (No change) (No change) (No change)
N3’ Inter’ 21,000 700,000 2,750+
N3 ‘Large’ Bespoke
N4 23,000 200,000 4,000+
X7 Bespoke
Note: ‘+’ the maximum number of zones is 8,250 and it is available upon
request. (N.B. there is a risk that some of the Multi-Core versions of the
existing applications may not be available in the larger sizes).
IJW / DVV – 31/03/13
5109341 / Mar 13 E-148

D.20.14 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App D.doc
2 D.15 added DVV 28/05/06
3.1i 10.6.15 updates added DVV 05/07/06
3.1ii Minor on-going updates DVV 14/07/06

(absorb App D17)
11.01.10 Web release- Sep 10 DVV JS IW IW 14/09/12
2012 SATURN User Group DVV JS IW IW 10/10/12

(absorb App D19)
5109341 / Mar 13 E-149

Appendix E - SATURN Bugs
E. SATURN Bugs
E.1 SATURN 10.4 Bugs
Date of last update: 5th October 2004
The following “problems” have been identified in SATURN Version 10.4.10 as
released in November 2003 and corrected in Version 10.4.11. (Although in
certain cases more comprehensive “fixes” have been added into 10.5 which users
may wish to “test drive”; all requests to DVV.)
1) P1X – Matrix cordoning in either P1X or SATCH may cause crashes or
illogical terminations. I say “may” rather than “will” since the problems involve
undefined variables in logical checks which may or may not yield the correct
results. Problems are worse with multiple user classes and/or stacked
matrices.
2) P1X – The 10.4 versions of GRAF.DAT included for the first time entry fields
for the “rotational shift” parameter for each device. Unfortunately the value for
device 1 (the terminal) over-writes all subsequent values (e.g., hard copy
outputs) so that choosing a different value for hard copy outputs still requires
an interactive change.
3) P1X – There is a problem in creating key files from any operation that
involves PMAKE setting node co-ordinates (e.g., creating a new node,
changing node co-ordinates, etc.) However the problem was also in 10.3 and
is clearly not the sort of operation that users are likely to use.
4) P1X – The window created for node screen editing (17 lines by 64 columns) is
not large enough to deal with some nodes, in particular signalised nodes with
many arms and./ or signal stages.
5) P1X/PMAKE – When adding buffer links to networks where KNOBS > 0 and
the KNOBS data is input as one extra record per buffer link on the 33333 data
set only a single new record is added to the 33333 data records by PMAKE,
i.e., an extra KNOBS record is not created. This means that every second
new buffer link is incorrectly read as the KNOBS record for the previous link
so roughly half the added (directional) links are missing. This can be
corrected manually by editing in blank records after each new buffer link
record. Corrected in 10.5 only.
6) P1X/PMAKE – Screen editing a “chunk” of the complete network file may lead
to errors if : (a), the section selected (as a first line plus number of lines)
extends beyond the end of the file (in which case it wraps back to the start of
the file); or, (b), extra lines are added via screen editing.
7) P1X/PMAKE – The frequency of a newly added bus route always defaults to
1 independent of the user’s input. Now corrected..
8) SATALL – The array 4053 which sets “average” link speeds including flow-
weighted delays at junctions for simulation links is incorrect for simulation
links which have a capacity – restraint or speed-flow curve included. Basically
the contribution to the delay from the speed-flow component was double
5109341 / Mar 13 E-1
11_2_05_App E.docx
counted resulting in speeds that were too low. However the problem does not
occur in the equivalent speeds reported by P1X which were calculated
correctly.
9) SATALL – The ROSIE option does not work - at all! Basically the problem
lies in transferring speed-flow curves from the simulation to the assignment
(one of the very clever improvements in 10.4 that works very well for ROSIE =
F is decidedly not very clever for ROSIE = T) and results in very poor
convergence. Fortunately the poor convergence is extremely evident so the
problem should be difficult to miss.
10) SATALL – The option to reproduce results as per 10.3 by setting NFT = 103
mostly does not work; i.e., most of the new facilities introduced in 10.4 are
“hard wired” in and cannot be by-passed by setting NFT = 103. Some will be
by-passable in 10.4.11 but the majority, mostly relatively minor, are extremely
difficult to exclude given the way in which they are programmed and most
likely never will be. Users are reminded, however, that the best way to
reproduce 10.3 runs is to use 10.3 SATALL! If you want the advantages of
10.4 you have to be using 10.4.
11) SATALL – An error has been found with links which (a) have simulation
centroid connectors attached, (b) block back and (c) have flows which enter at
the upstream end (e.g., from bus routes starting under UPBUS = T or bus
lanes terminating on the previous link). It is not yet clear exactly what impact
the error has, possibly it may affect the assignment-simulation convergence,
but it is corrected in 10.5.
12) SATSIM – Problems may occur when printing bus summary statistics if there
are no capacity-restrained links in the simulation network; i.e., it may crash or
it may just print silly numbers or no numbers (a problem of bus flows being
undefined).
13) SATBUF – The essential key file satbuf.key was omitted from the install cd
and may be obtained by direct request to DVV and/or downloaded from the
SATURN website.
14) MX – Undefined cells on the right hand side of the matrix display when the
“zero point” is very near the maximum column have been corrected.
15) SATALL / P1X – The values of ‘g’ (the “speed-flow elasticity as used by
VaDMA) have been overestimated since they were based on variable time
components only, i.e., the fixed time components were excluded. Including
them (correctly) reduces g values by, say, a factor of 2.
16) SATLOOK/MX – The maximum output length for a single record of CSV
output is 8192 bytes but the maximum input is only 4096. Hence SATLOOK
can produce CSV cost skins (as in SATTUBA) which MX cannot read.
Corrected.
17) P1X (Cordoning) - The option to produce a cordoned (i.e., sub-area) network
.dat file directly within P1X will not work if the cut links include a link which
joins two external simulation nodes but is itself part of the buffer network.
There are, however, no problems with doing exactly the same cordon in
5109341 / Mar 13 E-2

11_2_05_App E.docx
SATCH. The soluton is therefore to create a control file for SATCH and run
that program to cordon the network instead.
18) SATCH (Multiple User Class Matrix Cordoning) – There may be problems
cordoning actual (i.e., DEMAND = F) trip matrices from networks with ALLUC
= T, several multiple user classes and/or a relatively large number of links.
The program may crash due to an array dimension being exceeded by the
product of classes times links. Corrected in 10.5 only.
19) SATED – Optimising signal green times leads to a crash with a message
saying “Missing segment UNPACK_STAGL_GREENS”. This is due to the
installed version of SATED not being correctly compiled. Atkins will supply a
replacement .exe.
20) SATEASY – As with 17 above SATEASY may also crash due to a missing
segment on compilation. Again Atkins will supply a replacement .exe.
21) P1X (Select Link Analysis) – If you have multiple user classes and request
that the SLA be carried out with ALL user classes and the exit from SLA you
may not be able to get back into SLA.
22) P1X (Edit External Simulation Nodes) – External simulation nodes may be
selected for editing as simulation nodes within network editing but not if
selected by number; i.e., you can point to them with the mouse but not enter
them numerically.
23) SATLOOK – The “Totals” line on the Lane Choice display for simulation
nodes was printing data for the last turn, not the totals. Corrected in 10.4.12.
24) SIMULATION (SATALL/SATSIM) – The lane choice mechanism has been
observed to misbehave when an even spread of traffic between all available
lanes leaves a shared lane over capacity and its (unshared) neighbours under
capacity. An over-enthusiastic re-allocation of traffic can leave the shared
lane empty. This results in an over-estimate of turn capacities used in the
cost-flow curves for assignment but link and road capacities as well as all
delays are virtually unaffected. However the incorrect capacity may add
marginally to convergence problems in the simulation – assignment loops
(along with lots and lots of other “correct” effects). A message saying “FUNNY
IN MIXLIN …” may also appear in the .lpt file. Corrected in 10.4.12.
25) SATNET – A slight inconsistency with FIFO = F (not its default) has been
corrected. Thus when a link to an external simulation node is assigned a link
speed-flow curve under the 11111 records and again under the 33333
records its capacity - if FIFO = F - should equal that from the 33333 record.
There are two DA codes in SATURN which store this information; one was
correctly set but not the other. They are now both correctly set.
To be honest I’m not sure whether this affects any of the simulation outputs
although it does affect the information output for that link. However it needs
to be stressed that the onus should be on the user in such situations to
remove one or the other of the conflicting data records in order to avoid any
possible ambiguity rather than relying on setting FIFO = F to do the job
automatically.
5109341 / Mar 13 E-3

11_2_05_App E.docx
26) SATALL – Using the FREEZE keyword on the command line to set a frozen
trip matrix does not work when ICING = T. The program does not open the file
and proceeds with the full matrix elastic as though ICING = F. The option to
set the file through FILICE in the network .dat file however works – and in fact
this is the recommended method anyway.
27) SPATULA – If the network is relatively large so that the o-d paths contained
in the .trp files as passed to DRACULA occupy more than one line then
SPATULA produces a fist-full of errors.
28) SATALL – Doing extra continuation loops using the MASL parameter on the
command line does not do exactly what it is meant to do when ROSIE = T.
Thus the first extra assignment does not use ROSIE, it does a normal
assignment, but subsequent assignments use ROSIE. The end effect is small.
This is not really a proper error, just another (possibly less good) way of doing
extra loops. Corrected in 10.5.
29) SATALL – Using the command option “MASL n” in the command line
effectively terminates the command line; any following options are ignored. If
MASL n comes at the end of the command line there is no problem. N.B. This
problem does not affect the SATWIN Module run of SATALL since MASL is
not available there in the first place!
30) SATALL – The table which lists the 10 biggest differences between
“assigned” and “saveit” flows has the two sets of flows reversed.
31) SATALL – The comparison statistics between “assigned” and “saveit” flows
(see #30) are also incorrect for a number of different assignment techniques.
They are correct for basic Wardrop Equilibrium, fixed trip matrix and 1 user
class, but are certainly wrong for multiple user classes at least. They make
the SAVEIT flows look more different from the assigned than they really are.
However all the SAVEIT calculations themselves and any further calculations
based on them are otherwise correct, it is only the printed numbers which are
wrong. Corrected in 10.5 only.
32) SATALL (and SATLOOK) – The text names by capacity index (as set by
CINAME) as given in the tables of simulation summary statistics are out of
order if there are some indices which are only used by buffer links. The
numerical indices and all the tabulated data are correct. (30/06/04)
33) SATALL – An error has been spotted in the PASSQ flows passed from one
time period to the next if: (a) the first two nodes on a bus route are from an
internal simulation node to an external simulation node (and thence into the
buffer network) and (b) UPBUS = T. The full bus flow is incorrectly passed
whereas (unless there is capacity restraint on the link) the passed flow should
be zero. (06/07/04)
34) DALOAD -. Matrix zone sequential numbers and names are not carried
through to an output .ufm file. (9/07/04)
35) P1X – Forests calculated using the second network are incorrect in that they
(correctly) use the costs from the second network but (incorrectly) weight
them according to the first network. This may also result in fatal errors with a
DA code not found. (30/09/04)
5109341 / Mar 13 E-4

11_2_05_App E.docx
36) P1X (Cordoning) – Using a cordon to select simulation turns either inside or
outside the cordon does not necessarily pick all such turns. (05/10/04)
5109341 / Mar 13 E-5

11_2_05_App E.docx

Date of last update: 7th March 2006
released in December 2004. Unless otherwise stated they have all been
corrected in the most recent version of 10.5 (as opposed to being corrected in
10.6 if they are more complex).
Many of these pre-date 10.5 and were also present in 10.4 or earlier releases.
1) MX – Data dumped from multi-level matrices under Tuba Format 3 always
gives the level (i.e., user class) as 1 for all levels. Corrected 04/01/05
2) P1X – Matrix desire lines plotted sector to sector for selected O-D sectors: If
you, say, wish to select origin sectors 3 through 5 and destination sectors 13
through 15 then the destination sectors incorrectly use the origin limits as well
so that, in the above case, you would get the desire lines from origin sectors
3-5 to destination sectors 3-5. This also means that if you select a single
origin, say 3, you get no desire lines displayed at all since the only selected
cell, 3 to 3, is an “intra”. Also in 10.4. Corrected 20/02/05
3) P1X – The choice of whether to display matrix data by sector or cell is
sometimes missing, particularly if more than one network file is input. Also in
10.4. Corrected 20/02/05
4) P1X and SATCH – Cordoning problems may possibly occur with very large
release Levels, e.g. levels N1, N2 etc. The program doesn’t crash but the
results look extremely weird. However what happens exactly may be a bit
unpredictable. One possibility is that having defined the cordon and then an
inner node nothing further happens. Possibly only in 10.4. Corrected
24/02/05
5) P1X and/or SATLOOK – The combined statistics for simulation and buffer
networks (e.g., PCU-HRS) have an error with multiple user classes and
elastic assignment. The buffer totals – and therefore also the simulation plus
buffer totals – for user classes greater than one are all those for user class 1.
Also in all previous releases of SATURN, presumably back to the point where
multiple user class elastic assignment was introduced. For all other
conditions, e.g., fixed trip matrix, single user class, etc., it works fine.
Corrected 27/02/05.
6) SATALL – In my enthusiasm to convert users to the use of AUTOK in place
of KOMBI it appears that AUTOK is automatically set to .TRUE. whenever
KOMBI > 0 (so both options to average assignment-simulation loop flows are
applied together and it is not possible to use just KOMBI on its own as done in
the past). In some respects this is not a bad thing and I would hope that it will
improve convergence but it does make it difficult to reproduce previous results
with 10.5. Corrected 27/02/05.
My advice would be to set KOMBI = 0 and AUTOK = T in order to use
AUTOK “properly”. In fact, with 10.5.13, a extra check has been added such
that if AUTOK = T and KOMBI > 0 then KOMBI is re-set to zero.
5109341 / Mar 13 E-6

11_2_05_App E.docx
In order to see what is happening in 10.5.12 users should view the column
headed “A/S Step” in Table 1 of the Convergence Statistics either in the .lpt
files or interactively via SATLOOK or P1X. If KOMBI is set to, say, 10, then
the first 10 loops should give 1.000/1 followed by 0.500/1 for subsequent
loops. If AUTOK is having an impact then these values will differ.
The problem may be partially circumvented by setting a (otherwise
undocumented) namelist parameter AKMIN = 1.0 under &PARAM. This sets
a lower step length of 1.0, i.e., no averaging of flows at all under AUTOK.
Therefore SATALL effectively ignores the fact the AUTOK = T up until the
KOMBI loop so that those initial loops are equivalent to the old methods.
The downside is that on later loops the averaging of 0.5 under KOMBI may
in fact not take place so therefore in this range KOMBI is being ignored.
7) P1X and/or SATLOOK – There is a potential problem created by assessing
errors at simulation nodes whereby, having requested a simulation node
numerically via SATLOOK or via Node Graphics in P1X, the program hangs.
The error only occurs with some priority junctions (in fact probably not very
many). Corrected 26/02/05.
8) SATNET – The use of ATLAS = T (or, strictly speaking, having ATLAS = T
and extra nodes being set under 55555 which are not connected to links)
may: (1) possibly cause problems in running SATNET by referencing
undefined variables (although empirically, it doesn’t seem very likely); and (2)
cause more serious problems in SATCH and (possibly) P1X (see below). You
will of course recall that ATLAS is a useful option in creating networks from
scratch using PMAKE but, once the networks are created, it should probably
be removed. Also present in 10.4. Corrected 02/03/05, partially in 10.5 and
more fully in 10.6.
9) SATCH - The use of ATLAS = T (or, strictly speaking, having ATLAS = T and
extra nodes being set under 55555 in SATNET) creates serious problems in
cordoning a trip matrix in SATCH. Basically it fails completely. Best advice: as
under 8, do not use ATLAS with final networks. N.B. The same problems may
or may not occur with cordoning matrices in P1X. Also present in 10.4.
Corrected in 10.6 02/03/05.
10) P1X – Network parameters reported for networks other than the primary
network (as requested under Information) all refer to the primary network.
Correct parameters may however be obtained within the Files option in
SATLOOK. Only corrected in 10.6 02/03/05.
11) SATALL – Roundabouts which have been defined with circulating capacities
of 99999 (five 9’s) – or indeed any value greater than 16384 – will cause a
floating point error in the first simulation.(NAOMI networks please note.)
Corrected 05/03/05.
12) SATNET – The test as to whether an input pre-load file is a binary .UFS file or
otherwise a text file is based on the file extension and is, incorrectly, case
sensitive. Thus .UFS is correctly identified as a binary file extension but not
.ufs. Trying to read a binary file as though it were text results in a very large
number of non-fatal errors. Also present in 10.4. Corrected 09/03/05.
5109341 / Mar 13 E-7

11_2_05_App E.docx
N.B. The problem should not occur when using PLOD on the command line
since the extension should be correctly added with an upper case extension
.UFS by default; it is much more likely when using the Namelist parameter
PLDFIL under &OPTION (as you are recommended to do!).
13) SATALL – Although path-based assignment methods are now documented
(Section 21) the necessary array dimensions have not been increased in line
with other array dimensions per release level (on the assumption that, since
no one was using it, there was no point in increasing the RAM requirements.).
Hence it is only really possible to run path-based assignment on relatively
small networks (e.g., 80 zones or less) independent of the Level. Users
wishing to try out path-based methods on larger networks should contact
DVV. 16/03/05.
14) P1X – The option to select “Options” from the Choice of Link Display menu is
not available for buffer-only networks. Options is not always useful but is, for
example, if you have multiple user classes. Also in 10.4. Corrected 19/03/05.
15) MX – An error occurs when building a .ufm from an input text (.dat, .txt, etc.)
file if:
(i) the text file has a single line per cell (as described in 10.5.3);
(ii) each record references zone names (with or without the equivalent
sequential numbers);
(iii) the number of zones (N) is set before the records are pre-read in
order to establish the complete set of zone names.
Basically the program adds the zone names that it reads in to the input
number of rows N so that the matrix winds up with twice the number of rows
and columns desired with the first set of ‘N’ rows and columns all being
numbered as zone 0. Corrected 13/04/05.
The problem may be avoided by not setting the number of rows before
entering pre-read, in which case the program winds up with the correct
number of rows and columns.
16) SATSUMA – The program crashes with networks which contain either: bus
flows, pre-load flows or multiple user classes. Corrected in 10.5.14. 28/04/05.
17) SATLOOK/P1X – The simulation summary statistics which compare either
more than one input network or multiple user classes may contain some
numbers which are “undefined” and get printed as, for example, ??????? or
******. The numbers which are printed should, however, all be correct.
Corrected in 10.5.14. 28/04/05.
18) P1X – If you use the link-based Choice of Annotation to create and display a
data array such as actual user class flows it appears correctly on link plots.
However if you then look at the same data as turn flows in node graphics or
in SATDB screen displays the flows are not factored down from demand
flows. Corrected in 10.5.14. 02/05/05.
19) SATNET – Yet another problem with ATLAS = T! If your 55555 X,Y data
records define new zones which did not appear under either the simulation
5109341 / Mar 13 E-8

11_2_05_App E.docx
11111 or buffer 33333 data sets then the zones in the assignment network
and the map network are incompatible which creates severe problems. In
addition the trip matrix may well have the wrong number of zones and/or be
based on the “wrong” system; in either case the assignment will be highly
problematic. To be safe this now becomes a semi-fatal error. Corrected in
10.5.15. 12/06/05.
ADVICE: Avoid using ATLAS = T with networks where it is no longer needed
to help build the network and where you are ready to go on to do the
assignment.
20) P1X – GIS files that contain a very large number of curved link records
(specifically if the total number of X,Y points exceeds 9999) give rise to
spurious lines heading off the screen to the “origin” lower left for all those links
beyond the point where the array dimension was exceeded. Corrected in
10.5.15. 15/06/05.
21) SATALL – Capacity reduction factors due to “weaving” on motorways are set
incorrectly when: (a) there is more than one link coded between the relevant
entry and exit ramps, say nodes A-B-C; and (b) the node number B is greater
than C. In this case the weaving factor is only applied to link B-C
(independent of whether B > or < C), not A-B. Corrected in 10.5.15. 21/06/05
22) P1X etc. – Analysis options such as Select Link Analysis which make use of
.ufc files may crash if very large values of NITA_S were used to create the
.ufc file in SATALL. Specifically a message appears saying that DA code
10003 cannot be found. The problem only occurs if NITA_S x NOMADS > 900
(so that mostly it will occur with multiple user classes). Corrected in 10.6.
23/06/05
23) SATALL – A “divide by zero” crash may occur within the simulation if an X-
turn at signals has been coded such that it overlaps with the adjacent straight-
ahead turns in 2 or more lanes and the X-turn is over capacity. For example,
straight-ahead traffic uses lanes 1 to 3 and the X-turners use lanes 2 and 3.
Since this is probably a traffic engineering no-no – since, in the above
example, turning traffic from lane 2 would have to cross straight-ahead
traffic from lane 3 – it should never happen in the first place. However, there
is, at the moment, no error check in SATNET to detect the possibility.
Corrected in 10.5.15. 30/06/05.
24) SATCH – The program may get stuck in an infinite loop when processing bus
route data if:
(iv) EZBUS = T,
(v) A $include file is being used,
(vi) The final record in the file does not have a <return> character
(carriage control/line feed) at the end of the record.
To correct simply add <return> at the end of the last record. Corrected in
10.6 only. 03/06/05.
5109341 / Mar 13 E-9

11_2_05_App E.docx
25) SATALL – The total pcu-hrs for transient queues in the “next time period” as
printed in the .lpt file or via SATLOOK, P1X, etc. are inconsistent if your
network includes Q-markers (see Appendix Q). Basically the delays are
correctly included in the disaggregate statistics (e.g., by user class, bus flows,
etc.) but are not included in the aggregate (“total flows”) statistics which are
therefore lower than the sum of the disaggregate totals.
Conversely, if any of the Q-turns are over-capacity, then the queued times
“in the next time period” are double-counted on the Q-turns but correctly
calculated for the aggregate statistics.
Overall both effects are generally small – and clearly zero if you have no Q-
turns in your network. Corrected in 10.5.15. 05/07/05.
26) SATCH – The “interpolation” of non-adjacent nodes in bus routes is less
“clever” than in SATNET so that, for example, a network .dat file produced by
SATCH may send bus routes through a banned turn. This results in semi-fatal
(NAFF) errors in SATNET. Corrected in 10.5.15. 05/07/05.
27) P1X – The option to transplant stage timings via .rgs files works OK if the .rgs
file was produced pre 10.5 but, perversely, will not work if the .rgs file has
been produced by the latest (10.5) version of P1X. Corrected in 10.5.16.
09/09/05.
28) SATALL – If UPBUS = T errors can occur in calculating the queued up flows
(and therefore the difference between demand and actual flows) on links
where both bus routes terminate and there are other exit centroid
connectors. The effects are not expected to be appreciable except possibly in
very heavily congested networks. Corrected in 10.5.16. 10/09/05.
29) SATCH – The program may crash with a divide-by-zero (or equivalent) in
subroutine SATCH_MATRIX_FLOWS message if certain cordon crossings
links have been assigned zero flows in the matrix cordoning but had positive
flow in the full network. Corrected in 10.5.16. 17/09/05
30) MX – If a .ufm matrix is built from a text file in CSV format with the zone
numbers given as the first entry in each row no check is made that the zone
numbers are in sequential order. Therefore the output matrix may “fall over”
under certain matrix operations – but not all. Corrected in 10.6. 02/10/05
31) SATCH / P1X (Cordoning) – The treatment of unidentified nodes in a bus
route differs between SATNET and cordoning routines. In SATNET an
unidentified node is treated as a non-fatal error and ignored; within cordoning
it is treated as, in effect, a fatal error and further processing of the route is
terminated whenever such a node is detected.
If the unidentified node occurs before the route enters the cordoned
network (or within the cordoned network) the route is not included in the
cordoned network. However, if the node occurs after the route has entered
and exited from the cordon network, it will be included (since processing of
routes terminates at the point of exit).
The end effect is that the cordoned network may contain fewer buses than
the full network.
5109341 / Mar 13 E-10

11_2_05_App E.docx
Corrected in 10.6.12. 03/12/05

32) SATCH / P1X (Cordoning) – The use of either GONZO or factors within the
88888 records to factor all or part of the input trip matrix can lead to problems
with the cordoned network and trip matrices. Basically, it is possible for the
factoring to be “double counted” within the cordon. See 12.1.6 and 12.1.7 of
the Manual for a more complete explanation of what has been done within
10.6 to correct the problem. 13/12/05
33) P1X – The standard dimensions for A3 and A4 plotters are wrong in that
290.0 is used rather than (as everyone, of course, knows!) 297.0 mm.
Similarly the standard version graf.dat uses 290.0 as well. What effect this
has on the output plots I’m not entirely sure but it’s probably pretty small, e.g.
one dimension may be plotted at a slightly different scale than the other.
30/12/05.
34) SATNET – The use of the symbol £ to denote toll charges within the 44444
data records does not always work but $ seems much safer; both are meant
to be acceptable. Stick to the dollar (Canadian, of course!). 19/01/06.
35) SATME2 – Reading in frozen cell records from the control file, data segment
55555, will give incorrect frozen cells if the records for one origin pair occupy
more than one line. The problem was that the first set of 6 destination pairs
were being read from the first 60 columns of the initial record instead of
columns 16-75 (so that it would read the origin zones and number of
destination pairs from columns 1-15 as though they were destination
numbers). With luck this would have produced a fatal error but not
necessarily. 21/01/06.
The error would also have occurred in previous SATURN releases back to
about 2002 when the option for multiple input lines was first introduced.
Any users who have used this facility had better re-check their previous
runs. Apologies.
36) SATLOOK – The option to “skim forests” over multiple user classes
automatically does not work as (presumably) intended by the user if the
commodity being skimmed, strictly speaking, depends upon the user class.
Thus there is no problem in skimming, say, distance or time which are
independent of user class. However skimming generalised cost, which may
differ between user classes due to different definitions of PPM or PPK, or tolls
or 44444 penalties, which may also be user-class specific, does not
necessarily work as the user might expect. In these cases the commodity
skimmed is the specific commodity from user class one and it does not
change with user class. (Although the paths skimmed do, correctly change
with user class).
The problem does not occur if each user class is skimmed individually and
the skimmed commodity is re-set each time. (Although clearly doing it this
way is more long-winded and the resulting skimmed matrices may need to
be stacked at the end of the process.)
IN addition the problem does not occur if the standard batch files to skim
forests such as SATC_AV, SKIMTOLL and SKIMPEN, etc. are employed.
5109341 / Mar 13 E-11

11_2_05_App E.docx
Indeed, their use is generally recommended over the more DIY application
of SATLOOK.
Finally the problem does not occur either with Option 14 – skim from a
single tree – where there is not an option to skim automatically over multiple
user classes.
The problem is corrected only in release 10.6.14. 29/01/06
37) SATALL – The program may crash with a message that talks about “illegal
floating point operation” or “divide by zero” or words to that effect, possibly in
a segment FLODEL_105. The root cause is a roundabout that somehow gets
stuck in a loop during simulation and winds up with one arm with zero
capacity; hence the eventual divide by zero. In principle CAPMIN is meant to
prevent this happening but it is not foolproof as it turns out.
The problem is corrected in 10.6 by setting a parameter RB106 = T which
prevents capacities going to zero in the first place by using CAPMIN
correctly. It is also corrected less satisfactorily in 10.5.19 by having an
absolute lower limit of 1.0 pcu/hr capacity on all roundabout arms. 07/03/06
38) SATALL – The program may also crash with messages similar to bug 37
above (but in a segment SETSSS more likely) due to junctions with Q priority
markers having zero total assigned flows. Corrected in 10.5.19 and 10.6.15
07/03/06..
5109341 / Mar 13 E-12

11_2_05_App E.docx

released in February 2006 and/or in subsequent 10.6 releases. Unless otherwise
stated they have all been corrected in the most recent version of 10.6 and all are
corrected in 10.7.09.
Some of these (potentially) may pre-date 10.6 and would also have been present
in 10.5 or earlier releases.
1) SATPIJA – The program crashes with an unidentified channel number 0 if
ALLIJ is set to .TRUE. (The default is .FALSE.). The problem did not occur
previously in 10.5 etc. Corrected in 10.6.15 07/03/06.
2) P1X – Analysing Arboreta in very large networks may cause a crash due,
e.g., to the length of an O-D path exceeding a fixed (and unchecked) array
dimension in the program. Present in previous releases, 10.5 etc. Corrected
in 10.6.15 07/03/06.
3) P1X - .XYB files (which give the co-ordinates for bitmap files) are incorrectly
output by the program in that it writes the 4 values on 4 separate records
rather than on a single line; they are therefore not read correctly on input.
.XYB files created by previous versions are fine. Corrected in 10.6.15
08/03/06.
4) P1X – Flows disaggregated by both user class and time period (in the case of
.uft input files) always appear as average user class flows. Corrected in
10.6.15 18/03/06.
5) SATNET – It appears that data which is to be added to link generalised costs
via a KNOBS entry (e.g., tolls) will not be added if the conversion factor
entered under the 88888 data records (e.g., in columns 26-30) is too small.
More specifically, the input value F which is in units of “pence per knob” is
converted into units of “seconds per knob” via the formula 60F/PPM; if that
value is less than 1.0 then the KNOB data is ignored. Or, strictly speaking,
the data is ignored if the sum of four successive converted factors is less
than 1.0. So if F = 1 and PPM < 60 (£36/hr) then you should be OK.
The error has come up at least once in practice but whether it has occurred
more widely is very hard to say. Hopefully it hasn’t since, if it had, it should
have been relatively easy to spot in that the KNOB (toll?) would have had no
affect whatsoever on the assignment.
The same error occurred on previous release versions as far back as I can
easily trace. 05/04/06
6) SATNET – Another error related to the translation of KNOBS data into link
generalised costs occurs in the somewhat unlikely situation where the value
of time (PPM) is zero but the value of distance (PPK) is not and one or more
KNOBS data need to be combined with the distance. The problem was that
the distance components were being converted into metres (the original
5109341 / Mar 13 E-13

11_2_05_App E.docx
intention) but the KNOBS data were converted into pence. Both are now
(post 10.6.15) correctly converted into metres.
Whether this situation has ever occurred in real-life is difficult to say. The
resulting assignment would be an all-or-nothing assignment to the minimum
generalised “distance” paths since there is no variable time component to
consider. With multiple user classes the problem could occur with any
individual user class where PPM = 0, PPK > 0 and KNOBS data were
included.
The same error occurred on previous release versions as far back as I can
easily trace. 07/04/06
7) SATALL – The warm start option (WSTART = T) does not work under a
number of possible scenarios as listed below. In effect WSTART should be
thought of as still being under Beta-test, although it does seem to work
properly and highly effectively in the most basic situations (e.g., single user
class, minimal fixed flows, etc.).
(i) Multiple user classes with changes to either the network or trip matrix
from the “update” network. Basically the resulting total flows and
delays are grossly underestimated.
(ii) Any differences in fixed flows (e.g., bus flows, pre-loads, etc.)
between the current network and its update network.
(iii) MUC, changed network and/or matrix and any fixed flows
All known bugs have been corrected in 10.6.15. 07/04/06.
In addition the documentation (Section 22) in the 10.6.14 release was very
much work-in-progress and not a great deal of use but this will be completed
ASAP and available through the website.
8) SATNET – The program may crash with a Floating Point Error (Divide by
zero) if (a) AUTOX = T and (b) ALEX = 0.0. The source of the problem is
trying to set a default stacking capacity at links to/from newly created external
simulation nodes by dividing a link length by ALEX. (Previously the stacking
capacity was just set to zero.) Corrected in 10.6.15 10/04/06
9) SATNET – Reading 44444 penalty/toll records with 21 user classes (so that
three input lines per link are needed) causes a program crash. 20 or 22
should be OK. The same problem might occur with 31 user classes.
Corrected in 10.6.15 11/04/06
10) SATALL – Using CLICKS with elastic multiple user classes causes SATALL
to crash with a reference to a device out of range. Corrected in 10.6.15
19/04/06
11) SATALL – The program may potentially crash with a floating point error in
the simulation due to a problem in the lane choice sub-model. It would appear
that the problem is very rare (and has been around in 10.5 at least and
possibly earlier releases) and may be triggered by a lane choice allocation
which would have been flagged as a Serious Warning within SATNET.
Corrected in 10.6.15 29/04/06
5109341 / Mar 13 E-14

11_2_05_App E.docx
12) SATALL – The link weaving mechanisms (as described in section 15.40 of
the Manual) have not been fully activated under elastic multiple user class
assignment. Corrected in 10.6.15 29/04/06
13) SATTUBA – Not so much a bug but an omission, the definition of skimmed
times excludes: (a) any possible time penalties entered under 44444 and (b)
any extra times due to CLICKS. Both are now included optionally via logical
parameters USETP and CLICKY in the preferences file satlook0.dat. Both
default to .TRUE. Added in 10.6.16 05/05/06.
14) SATNET – A further problem with CLICKS: if you have more than 4 user
classes then the fixed penalties added for CLICKS(n) where n > 4 are
calculated for n modulo 4. In other words CLICKS(1) is used in place of
CLICKS(5) to calculate the extra time penalties (if any) for user class 5,
CLICKS(2) in place of CLICKS(6) for user class 6, etc. etc.
Note, however, that this error only affects the assignment and that, once
assigned, the extra pcu-hrs per user class due to any reduced maximum
speed are correctly calculated per user class and printed correctly in the
tables in the .lpt file. If, therefore, you have a network with limited route
choice the errors may be minimal. Corrected in 10.6.16 08/05/06
15) SATALL – The program may get stuck in an infinite loop if SATOFF and
SIGOPT are both .TRUE. and MANOFF is being used. This can occur if the
offset for the “master node” is reduced sufficiently such that start/end times of
a stage go negative. The problem was also present in previous releases. .
Corrected in 10.6.16 11/05/06
16) MXM5 – Terminating the list of zone correspondence records with a blank
record as opposed to a 99999 record does not work, although the manual,
Appendix W.3, says it does. Stick to 99999. Equally Appendix W gives the
default of CSV as T - it is, in fact, F. Corrected in 10.6.17 02/06/06
17) SATNET – Reading default speed-flow curves under 33333 with DUTCH = T
requires that the relevant data is contained in columns 21 to 55, not 11 to 45
as when (normally) DUTCH = F. However, if the data is in columns 11-45 with
DUTCH = T then it is very likely that the data will not be processed at all, no
default speed-flow curves are created and, most importantly, no error
messages result. Corrected in 10.7.1 09/06/06. N.B. This problem has been
around as long as default speed-flow curves have been around so it is not a
10.6 problem specifically.
18) SATNET – The parameter ILOVEU which controls whether U-turns are
“discouraged” at external nodes which lie between the buffer and simulation
networks (se 18.9) has been described in the documentation the wrong way
round. Thus the original documentation stated that, in order to discourage U-
turns, ILOVEU had to be set to F and that this was the (recommended)
default. The correct version is that ILOVEU has to be set to T to discourage
turns and this is the default. Hence, unless a 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 generally recommended. Thus there have been no program
changes, only corrections to the Manual. This problem has been there ever
since ILOVEU was introduced in version 10.4.
5109341 / Mar 13 E-15

11_2_05_App E.docx
19) VDU Option with KEY files – Interactive programs such as P1X, SATDB,
etc. which are run “in batch mode” using the VDU + KEY options on the
command line were “improved” in 10.6 so that any commands which were
entered under the Windows Bar, e.g., commands to move a display screen up
or down, were ignored on the assumption that all such commands were not
essential under VDU since all they did was to change a screen display which
was never viewed anyway. However, it turns out that this is not always the
case since commands such as &Order in SATDB displays may actually be an
integral part of a KEY file. The option has therefore been removed under
10.6.17. 10/07/06.
20) P1X – Actual and/or queued upstream flows as displayed are potentially
miscalculated for: (a) networks other than the base network which (b) have a
different topology from the base network. For the base network or identical
topology there is no problem. The basic problem is that the queue reduction
factors for a link in network 2 may pick up an additional factor from a turn with
the same number in network 1. Not all link data is therefore affected. The
problem was created in release 10.5.15. Corrected in 10.7.2 15/07/06.
21) P1X – Various relatively minor problems have been corrected in banner
displays of the link quantities being annotated. Mostly it was a question of the
banner being blank instead of displaying the correct data title. Corrected in
10.7.2 15/07/06.
22) MX – Building a .ufm file from ascii data input of the form “Name(I), Name(J),
Tij” fails to detect if either zone name is zero and therefore erroneously adds
a zone zero. (If I and J are sequential zeroes are ignored.) Corrected in
10.7.2. 27/07/06.
23) Matrix Stacking – If MX is used (either internally or with an external batch file
such as mxstack) to stack matrices which are themselves stacked the
number of levels in the output .ufm file is incorrectly specified. For example, if
you stack 4 square matrices into a fileM4A.ufm and another 4 square
matrices into M4B.ufm an then jointly stack M4A and M4B into M8.ufm – so
that M8 contains 8 square matrices – then M8 only registers 2 levels. This has
implications if M8.ufm is then used as a trip matrix for a network with 8 user
classes since SATALL may require a trip matrix with 8 levels specified. (N.B.
The number of rows and columns in M8.ufm would be fine; it is the only the
presumed number of levels which is wrong.) Corrected in 10.7.3 15/08/06
24) SATCOBA – Various problems have surfaced when running SATCOBA, in
particular with networks with 5-digit node numbers which are automatically
forced to use sequential node numbers (NAMES = F) due to the fact that
COBA only allows a maximum of 4 columns for input node numbers. Firstly,
the “towards node” in columns 47-50 COBA Key 056 was always output as
the “real” node number, not sequential, so failed whenever NAMES = F (i.e.,
definitely with 5-digit nodes). This has been corrected in 10.7.5. However if
SATCOBA is being used to output data from two input files which are
structurally different then it is not possible to match the networks based on
sequential node numbers since these will differ between the two networks. At
the moment there is no way around this problem; a solution could
undoubtedly be found within SATURN but the obvious solution is to change
COBA to accept 5-digit node numbers. So push them! 15/10/06
5109341 / Mar 13 E-16

11_2_05_App E.docx
25) P1X – A long-standing problem with has been found with the reporting of
flows on links from an internal simulation node (I) to an external simulation
node (E) when PASSQ is being used. Basically any PASSQ (fixed) flows on I-
E are effectively removed immediately before they arrive at E so that the
reported downstream stop-line arrival flows (both demand and actual) do not
include PASSQ flows and therefore under-report the true arrivals. However
the “normal” annotation of (demand/actual) flows on the link are unaffected
and there is no affect on delays, total pcu-hours etc. etc. The problem only
really came to light in 10.6 when an option to annotate downstream arrivals
was added. Corrected in 10.7.5 14/11/06
26) SATALL – Quantities such as total pcu-hours, total pcu-kms etc. etc.
calculated within the simulation network may double-count the inputs from
bus flows which start upstream on simulation links E-I where E is an external
simulation node and I is internal. On the other hand the same quantities
calculated directly within SATLOOK are correct. N.B. the problem has no
effect whatsoever on assigned flows, calculated times, etc. etc., only
summary statistics. Corrected in 10.7.5 14/11/06
27) P1X – Creating a SLA trip matrix without having an input .ufm trip matrix but
using the option to run with a flat trip matrix crashes with a message about
accessing channel 0. Corrected in 10.7.6. 30/11/06
28) SATNET – Crashes if both BUSKER and FREDDY are .TRUE. since the
program attempts to output both a bus and a signals data file on the same
channel without closing the first file before going on to the second. Generates
a miscellaneous Fatal Error with parameters 0 and 7. A bug from way back.
Corrected in 10.7.6. 01/12/06
29) SATNET – Not so much a bug, more a possibly undesired outcome of using
crow-fly distances to define buffer-link distances if the input value on the
33333 records is zero and SHANDY = T. The problem is that this correction is
applied to all buffer links including centroid connectors. While it may be
sensible and highly desirable to calculate “correct” distances for “real” links it
may quite acceptable to have zero-length centroid connectors (in the same
way that they may quite legitimately have zero times). Therefore a new logical
parameter CROWCC has been introduced in 10.7 such that a distance of
zero for a buffer centroid connector is only replaced by its crow-fly distance if
SHANDY = T and CROWCC = T. The default value of CROWCC = T
maintains the status quo. Added in 10.7.6. See 15.10.3. 03/12/06.
30) MX – Dumping SATURN .UFM files to EMME-2 formatted text files currently
excludes any output for matrix rows which contain all zeros (as well as
excluding any non-zero cells in rows which otherwise contain one or more
positive cells). Whether or not EMME-2 can accept files with such missing
rows I do not know, but 10.7 adds a text record consisting of only the row
origin in the case of all-zero rows. 18/12/06.
31) P1X – Errors can occur while editing nodes under Node Graphics (i.e.,
temporary editing, not permanent editing as under PMAKE) if, after having
either added or deleted signal stages, you call both the options to Simulate
and to Process the new signal data. The errors only appear if you then move
5109341 / Mar 13 E-17

11_2_05_App E.docx
on to edit further signalised nodes with higher node numbers. Corrected in

10.7.7 19/12/06.
32) SATALL – The combination of setting RAGS = T, LRTP > 0 and a
roundabout with junction type 5 causes extremely high random delays to be
calculated at the roundabout such that, in all probability, the assigned flows
will be zero. Note that the default is RAGS = F and LRTP = 0 so unless you
have specifically changed both these parameters the problem will not occur.
Corrected in 10.6.18 and 10.7.7. 18/01/07
33) SATME2 – The Namelist parameter that specifies the file to be used to set
frozen cells under FRODO = T is listed in the manual as FILICE but the
program looks for either parameter names ME2ICE or ICEME2 instead. 10.7
has been corrected to accept either FILICE or ME2ICE etc. but with current
10.6 versions you will need to use ME2ICE or ICEME2. Corrected in 10.6.18
and 10.7.7. 24/01/07
34) P1X – Creating %Green Time link annotation data for networks other than
network 1 may result in errors if the structure of that network differs materially
from that in network 1; e.g., if it has a different number of simulation nodes or
different signalised nodes, etc. etc. On the other hand it is perfectly possible
to compare two networks if, say, the second network has had its signal
settings optimised from the first network. Corrected in 10.7.7, 31/01/07.
35) MX – Editing zone structure (e.g., adding zones, deleting zones, aggregating
zones, etc.) with stacked (MUC) matrices causes a problem with the zone
(row) names for levels 3 and beyond in that it retains the old names. However
the new cell values should all be correct. Corrected in 10.6.18 and 10.7.8
05/02/07.
36) SATPIG – The program may crash with a Fatal Error 29 for: (a) multiple user
classes with (b) either a large number of SAVEIT iterations and/or a large
number of links. Corrected in 10.6.18 and 10.7.8. 06/02/07
37) P1X/SATDB – It is possible that, if simulation-based data is selected through
the P1X link annotation menu and subsequently displayed via SATDB, that
turn data may not be defined as expected. For example, the “delay”
calculated for simulation turns corresponds to the buffer link definition of
actual time less free flow time rather than total turn time. There may be one or
two other examples. (The basic reason is that the P1X link annotation menu
was originally created purely to set link data, turn data were a bit of an after
thought.) Corrected in 10.7.8. 16/02/07.
38) P1X/SATDB – When selecting “All” user class flows using the “numerical”
P1X menu in SATDB (i.e., where you use option 91 to select all user
classes), it is possible that one or more of the higher user classes may be
created as columns of zeros. The error only occurs in (larger) networks
where the number of assignment links multiplied by the number of user
classes is greater than twice the maximum number of assignment links.
Corrected in 10.7.8. 21/02/07.
5109341 / Mar 13 E-18

11_2_05_App E.docx

released in March 2007. Those up to and including 12) have all been corrected in
the most recent version of 10.7, 10.7.10, released in June 2007. Errors 13) and
beyond have mostly been corrected in 10.8 only but some have been added to a
version 10.7.11 which has not been made available as a general release but
which could be made available to users who encounter the specific problems
noted below.
in 10.6 or even much earlier releases.
1) SATALL – It is possible, with elastic assignment and a single user class, that
the program may either crash or print silly cell values when reporting the 10
worst converged elastic O-D pairs. Or it may work perfectly well depending on
the value used for an otherwise undefined variable. The same problem should
have occurred in 10.6. Corrected in 10.7.10 29/03/07.
2) SATALL/SATSIM Simulation – An error may occur in calculating the extra
“TAX” capacity of an X-turn at the end of a green phase at signals if it shares a
single lane with another turning flow which is extremely small (e.g., 0.0001
pcu/hr) but not yet zero. The extra added capacity will be very near zero as
well, possibly leading to very high V>C delays. The problem has been around
for at least three years without being spotted so is hopefully extremely rare.
Corrected in 10.7.10 29/03/07.
3) P1X – The choice of Validation in the Master Menu is greyed out when there
are counts available for validation studies but no timed routes. If both occur or
just timed routes Validation is available. Corrected in 10.7.10. 21/03/07.
4) SATALL – The use of AUTOK under multiple user class assignment has been
either improved in 10.7.10 or a bug corrected depending on your point of view.
A problem which has been around for a very long time. 30/03/07.
5) SATEASY – Multiple user class elastic assignment does not work correctly
due to a double counting of minimum link travel times. The problem has been
there for quite a long time. However MUC elastic assignment works perfectly
well in SATALL which is what we strongly recommend using anyway. And is
what the batch procedure SATURN runs by default Corrected in 10.7.10.
30/03/07
6) SATALL/SATSIM Simulation – The program may crash (Illegal operation in
MIXUP2_105) under extremely rare circumstances which are detected in
SATNET by Non-Fatal error 226 but not prevented. So logically 226 should be
a Semi-Fatal Error and probably will be very soon. (It occurs when two turning
movements share a lane but neither has green in the same stage so that both
block one another.) Corrected in 10.7.10.10/04/07.
7) SATNET – The error summary by all data segments which appears very near
the end of the .LPN file (and which may also be printed within P1X) incorrectly
5109341 / Mar 13 E-19

11_2_05_App E.docx
reverses Warnings and Non-Fatal Errors. At all other points they are correctly
given. Corrected in 10.7.10.10/04/07.
8) SATSTAT - May not generate a full report if the network does not include any
links with Capacity Indices. Corrected in 10.7.10. 12/04/07.
9) P1Viewer/MXViewer – The initial release version only provided access to the
maintained level rather than Level ’N3’. Fixed in Release Patch #1 (21/03/07)
and included in all v10.7.9 released post 21/03/07.
10) SATWIN - Fortran File Opening Error 9016 may be generated when accessing
data files located outside the Working Folder with long path names and/or
embedded blanks. Corrected in 10.7.10. 14/04/07.
11) SATTUBA/MX etc. – There is a problem when producing skims for very large
matrices under Tuba Format 1 or any other format mechanism that produces a
full CSV record per origin in that the maximum record length is 8192
characters. If the required length exceeds this it may either cause a crash or
else simply truncate the output record to 8192 characters. The latter produces
a Non-Fatal Error message in the .LP file which may escape your notice. The
dimension has been doubled to 16384 in 10.8 but you will also need a similarly
extended version of TUBA. The same problem may also occur when
outputting large CSV files in MX. See 10.15.1. 14/05/07.
12) SATALL/SATSIM Simulation – Turning movements coded with a turn Priority
Marker M for merge may give unintended results with certain junction
geometries.
The basic intention of the M marker is to model merges, e.g., entry ramps onto
motorways. These would be coded as a 3-arm priority junction with two one-
way in-bound entry arms, the motorway and the ramp, one one-way out-bound
arm, the exit motorway, and two turns: ramp to motorway coded M and
motorway through to motorway. The assumption is that the outer lane of the
ramp-motorway turn would merge with the inside lane of the motorway-
motorway turn which would, by definition, be lane 1 on the motorway entry.
Problems occur if the ramp is, effectively, coded as two-way such that there is
an additional permitted left-hand turn off the motorway onto the ramp and that
turn has the exclusive use of the inside lane. In this situation there is no traffic
defined in lane 1 for the entry ramp traffic to merge with and the estimation of
gap acceptance for ramp entry traffic becomes ill defined and essentially
arbitrary. Most of the time there will be no reduction in the ramp entry capacity
below its saturation flow but it is also possible that the capacity will be reduced
to zero/CAPMIN with, consequently, very large delays.
In 10.8 this situation is: (a) detected as a Non-Fatal Error in SATNET but (b)
corrected in the simulation by merging the ramp entry traffic into the inside
lane as used by the motorway through traffic, not exclusively lane 1. With 10.7
the only solution – and probably the best solution in 10.8 as well - is simply not
to use M markers with such a geometry or, if you do, allow the motorway
through traffic to share lane 1 with the exit traffic from the motorway, in which
case the entry traffic has something to merge with.
Hopefully the coding as described above is fairly infrequent in practice.
5109341 / Mar 13 E-20

11_2_05_App E.docx
The same problem occurs with junctions with more than 3 arms and/or with
merges “from the offside”. See 6.4.2.3. 03/05/07.
13) Using SATUFC to produce .UFC files post assignment may not allow
procedures such as forest skims to work subsequently since programs such
as SATLOOK or SATCH automatically think that there is no .UFC file in
existence. Corrected initially in 10.8.5 by letting the programs look for the
relevant .UFC files but more comprehensively in 10.8.6 (see point 2 in
Appendix D17.7) by automatically upgrading the .UFS files to register SAVEIT
= T etc. 07/06/07
14) SATALL/SATSIM/Simulation. It is possible – though probably extremely rare
– for roundabouts where one or more arms have link speed-flow curves which
do restrict arm capacities for the internal give-way calculations and the
“choking” from mid-link capacities to get locked into some form of positive
feedback loop which results in very extreme capacities and/or delays.
Corrected in 10.8.5. 17/07/07.
15) SATPIG/SATPIJA If the produce of NOMADS times NITER_S exceeds 999
an array dimension will be exceeded and the program will crash. The
correction dimension (as in all other programs) should be 4001. Note as well
that there is also an upper limit of 1001 on NITA_S for a single user class.
Corrected in 10.7.11 and 10.8.6. 20/07/07.
16) P1X, SATDB, etc. Various problems have been identified performing Select
Link Analysis based on .UFO files. Thus, (1), with MUC networks the user
class flows printed for UC > 1 are incorrect (To be more precise they show the
differences from the previous values.) (2) Screen line SLAs do not account
for the possibility of paths crossing 2 or more links in the screen line; if they do
their flows are double counted; (3) Spurious “CANT FIND …” messages in the
LP files have been removed. (1) has been corrected in 10.8.6, (2) is still under
review. 21/07/07
17) SATALL (Simulation) – It is possible – but highly unlikely – to generate an
Invalid Floating Point Operation (divide by zero) in SET BB TARGET_AVERQ.
Corrected in 10.8.6. 01/08/07.
18) SATALL (Simulation) – It is possible to generate a crash (undefined variable
in subroutine BBLIST) if QUEEN = T, but not consistently. The error has been
in existence for several years without ever being spotted. Corrected in 10.7.11
and 10.8.9. 27/09/07.
19) SATNET – Problems can occur if capacity-restraint speed-flow curves and/or
capacity indices are included in both the 11111 simulation data and the 33333
buffer data. The intention was that, if they differ, the initial 11111 would always
be used in preference to the buffer data but this is not always the case. In
particular this applies to speed-flow curves on simulation links from an internal
node to an external simulation node. Setting FIFO = F should help. Corrected
in 10.8.9. 27/09/07
20) SATALL/SATSIM/Simulation. It is possible for the program to terminate
prematurely with a Miscellaneous Fatal Error 29 message. The cause of the
problem is that described under 10) in Appendix D.17.3, Non-Fatal Error 273
(10.8 releases only). However it is not the case that all occurrences of NFE
5109341 / Mar 13 E-21
11_2_05_App E.docx
273 inevitably cause the crash; in fact relatively few of them do. However
correcting all such errors should remove the problem. Corrected in 10.7.11
28/10/07.
21) SATNET. If KNOBS data is being read with KONAL = T, i.e, with all the data
included at the end of each 33333 link data record, the data is incorrectly read
if DUTCH = T. Thus, rather than reading the data from column 56 onwards
(since with DUTCH = T the normal capacity index is in columns 53-55) it reads
it from column 46 onwards as it would normally do if DUTCH = F. Corrected in
10.7.11. 23/11/07.
22) Simulation. If a filter (Priority Marker F) has been coded at signals in,
presumably, lane 1 and another turn has also been allocated to lane 1 then
the simulation gives very strange results. This situation is detected as Serious
Warning 105 in SATNET but, arguably, it should be converted to a Semi-Fatal
error under WRIGHT = T. Corrected in 10.8.12 only. 17/12/07.
23) SATNET/Simulation. Any roundabout which has been coded with a circle
time of greater than 64 seconds will have its circle time taken modulo 64 –
which, if it is between 64 and 128 seconds, it will be reduced by 64. The
problem has been there since the year dot apparently. Note that there is an
upper limit of LCY set on the circle time so that the error cannot only occur if
LCY > 64. Corrected in 10.8.13. 10/01/08
24) SATME2 – If the input prior trip matrix contains negative cells (pretty unusual
but it has happened!) then those cells get confused with frozen cells and wind
up being output as a positive value. Another error that has been there forever.
Correct in 10.8.14. 06/02/08.
25) MX – Errors occur when reading in a stacked matrix which contains multiple
levels from a text file of the form: NI NJ Level Cell; i.e., the “zone names” of
the origin and destination, the level and the cell value. Basically the level is
ignored and the matrix created will be square. In particular this affects the
input of stacked matrix under TUBA Format 3. Corrected in 10.8.14. 10/02/08.
26) SATNET – The program crashes with KLUNK = 1 and more than 5 user
classes (NOMADS > 5) with an “end of file” message. Corrected in 10.7.11
and 10.8.15. 18/02/08
27) SATALL – One of the assumptions made in the calculation of total pcu-hrs to
come in later time periods is inconsistent with the assumptions normally made
in skimming average O-D times. The differences occur specifically on links
which: (a) block back and (b) are “spanned” by centroid connectors. The
assumption made in calculating skimmed times is that any trips queued on the
centroid connector will experience the maximum queue on the link in the
future whereas in the calculation of total pcu-hrs the queue to be experienced
is factored by AFTERS (whose default value is 0.5). If AFTERS = 1 the
differences are zero for these particular links but, equally, setting AFTERS = 1
leads to inconsistencies elsewhere. The problem only arises in very highly
congested networks where it is likely to be a few percent at most. The
skimmed times are currently “correct” (in so far as any assumptions made
about what happens to queues in later time periods can be thought of as
5109341 / Mar 13 E-22

11_2_05_App E.docx
“correct”); the calculation of total pcu-hrs has been corrected in 10.8.16.

11/03/08.
28) SATNET/P1X – If a $INCLUDE file is terminated by a 99999 record that
record will not be treated as an end of data segment by SATNET; only a
99999 record in the “main” .dat file counts. However, if you subsequently edit
the network in P1X and ask for the $include file to be copied into the main .dat
file, the 99999 record is copied so that the data segment will be terminated by
two 99999 records which are interpreted as an end of file by SATNET. In the
corrected version of P1X 99999 is not copied. 10.8.16. 17/03/08.
29) MX – If the control file used to define trip ends for matrix Furnessing – see
Section 10.7.5 – does not contain &PARAM namelist parameters the file will
not be read and, possibly, the program will hang. The documentation states
that the Namelist is optional; in fact it is – or was – mandatory. Corrected in
10.8.16 where it now becomes optional. 20/03/08.
5109341 / Mar 13 E-23

11_2_05_App E.docx

Date of last update: 1th May 2010
released in March 2008 and/or in later 10.8 releases up to and including 10.8.22.
1) SATNET – Although the manual states that multiple bus lanes may be defined
on network .dat files by, e.g., BB2 it actually generates a fatal read error.
Corrected in 10.8.16 9/04/08.
2) P1X – Calculating SLA Actual (as opposed to Demand) flows ignores any
possible reductions on the first simulation turn immediately after an OD route
leaves the origin; subsequent reductions at over-capacity turns are correctly
treated. The end result is that the Actual flows may be over-estimated. The
bug has been there in all previous versions. Corrected in 10.8.16. 16/04/08.
3) SATCH/P1X – Cordoning a network with KNOBS > 0 and where the KNOBS
data appears as a second line after the link data lines within 33333 (so that
KONAL = F and a knobs file is not being used) and the extra lines can be
entirely blank can create errors. What happens is that the blank line is ignored
and the next record which should be a genuine buffer link record is skipped
instead. The error has been around for several releases. Note that we now
strongly recommend inputting KNOBS data via a separate “knobs file”, not
within the 333333 data, in which case the error can never occur. Corrected in
10.8.16. 16/04/08.
4) P1X – Network Editing has problems dealing with blank records within the
33333 data used as a “second record” containing KNOBS data. Basically the
editor re-writes them as a comment and they will then be ignored in any output
.dat file. A long-standing error, not just in 10.8. Corrected in 10.8.16. 18/04/08.
5) P1X – If a log/key file contains an integer X/Y co-ordinate with 6 (or more)
digits, e.g., as used to define the corner of a Window box, the co-ordinate is
output as an integer but incorrectly read within a key file as a real. For
example, a value of 123456 will be read as 1234.56 and hence totally
“misplaced” by the key file. 5-digit co-ordinates are not a problem. The error
can be corrected by manually editing the key files to add a decimal place to 6-
digit numbers but keeping within the requisite 8-column field; e.g., replace
‘bb123456’ by ‘b123456.’ (where ‘b’ represents a blank). The affected lines are
those that are terminated by (Mouse pixels/status/X,Y). This is a new problem
in 10.8 which is a consequence of including network co-ordinates in addition to
pixels in key files in order to make key files less dependent on device
resolution. Corrected in 10.8.16. 22/04/08.
6) Simulation – The new parameter RTP108 is unreliable and can generate
incorrect random delays. Its use is therefore not recommended and it should
be set to .FALSE. (its default) under &PARAM in network .dat files. Corrected
in 10.8.16. 24/04/08.
5109341 / Mar 13 E-24

11_2_05_App E.docx
7) SATNET – A bus route which executes a U-turn at a simulation node which is

not a Type 5 roundabout may possibly (but not always) lead to a crash.
Corrected in 10.8.16. 26/04/08
8) SATALL/Simulation – An explosive cocktail may be created by having two X-
turners in the same exclusive lane with one or more of the X’s entering a link
which is blocking back. This may cause the computer either to crash, hang or
to generate negative capacities – or it may only slightly misrepresent the extra
post-green capacity “TAX”. Corrected in 10.8.16 27/04/08.
9) SATALL – It is possible for the program to crash (Floating Point Error within
subroutine DEL_107), caused by the “major turning movement” in a merge
having zero flow (i.e., not the turn with a priority marker M but the turn into
which it merges). In addition the new 10.8 “funnelling” rules must be turned on,
so that FUNNEL = T (its default) plus RTP108 must be T as well (default F). A
simple work-around, should the problem arise, is, therefore, to set FUNNEL =
F and/or RTP108 = F. Corrected in 10.8.16 04/05/08.
10) SATALL – A similar crash (Floating point stack fault in MIXRIV) may also
occur (but extremely rarely) with RTP108 = T. Corrected in 10.8.16 04/05/08.
11) SATNET – If UPDATE = T and the arrays containing either the IN or OUT
simulation profiles are greater than 75% of the maximum limits then problems
may arise with the update addressing memory outside the allocated space. In
general this does not seem to be a problem, except in so far as the update
process is not as efficient as it might be, but it may also cause the program to
crash, in which case you’ll know about it! Corrected in 10.8.16. 07/05/08.
12) MX – The output of a sector-sector .UFM matrix file may omit certain cells.
The bug is not new and has been present for a long time. Corrected in
10.8.17. 24/06/08.
13) SATNET and others – Input from a free format text file with data of the form
“…1.0 , 2.0 …”, i.e., with the two data fields separated by both blanks and a
comma, will not be read correctly. Specifically the problem surfaced while
reading CLICKS data under KLUNK = 1 but it could happen anywhere. Note
that “1.0,2.0” (comma, no blank) works correctly (and which is what is
produced by CSV files output by SATURN) as does “1.0, 2.0” (blank after the
comma) and “1.0 2.0” (blank, no comma). Corrected in 10.8.18. 14/07/08
14) SATALL – The simulation of the effect of funnelling on offside merges (with
M108 = T and FUNNEL = T) may identify the “major” merging turn incorrectly
and thereby – most probably but not necessarily – underestimate the capacity
reductions. Corrected in 10.8.17 as released. 16/07/08
15) SATPIJA & SATME2 – The use of the parameter SUBPQ = T to subtract
PASSQ flows from the input count does not work correctly for MUC
assignment in that it subtracts the total PASSQ flow from the counts rather
than the user-class specific PASSQ flows. Corrected in 10.8.19. 24/07/08
16) TBA22UFM and TBA32UFM – The batch files for converting Tuba-2/3 text
files back into .UFM do not re-create all the original zones in the input .ufm file
if a zone does not appear at all as either an origin or a destination in the text
file. Not a problem for “full” matrices. Corrected in 10.8.19. 25/07/08
5109341 / Mar 13 E-25

11_2_05_App E.docx
17) SATNET – You can get a crash – Divide by Zero in CHECK_IGL_NUC – if you
have a stage length of zero which would otherwise produce Semi-Fatal Error
227. It may be caused by having an incorrect number of stage definition
records / an incorrect value of the number of stages in the Node Record.
Corrected in 10.8.19. 04/08/08.
18) P1X – PMAKE fails when a new link is connected to a traffic signals node.
Corrected in 10.8.19. 22/08/08.
19) SATNET – The use of < or > symbols to set explicit upper and lower limits on
stage green times in network .dat files (see 6.4.13 in the Manual) has several
problems. Firstly, SATNET may crash with certain inputs. Secondly, various
analysis programs such as P1X may fail to read the limits correctly from .ufs
files (although they should be OK in SATALL). Corrected in 10.8.19. 04/09/08.
20) SATNET - Reading in an ascii file of pre-load flows under free format
(PLODFF) implicitly assumes that the data file consists of link records only,
i.e., A-node, B-node, flow. Hence pre-load flows on turns cannot be read and,
if your data records do consist of A,B,C,flow, A,B will be read as a link and C
will be incorrectly read as a flow. Corrected in 10.8.20 by adding a new
&OPTION logical parameter PLFF3. 20/10/09.
21) P1X – Certain semi-fatal errors detected in SATNET, in particular references
to otherwise undefined simulation nodes as a link A-node, may cause a crash
if the node in question is viewed using node graphics. Corrected in 10.8.20.
06/11/08.
22) P1X – Errors occur in node .dat file editing if you try to add more than one
extra speed-flow records at a single node; e.g., if you create new capacity
indices on two links. It tends to overwrite existing records rather than creating
new records. Corrected in 10.8.21 and 10.9. 23/12/08.
23) P1X, SATDB, SATLOOK, etc.– If a network has been through a multiple user
class elastic assignment in which not all user classes are elastic, and in
particular if the last user class was assumed to have a fixed trip matrix, then
the default trip matrix input to P1X etc. will be the reference trip matrix, not the
output trip matrix. (P1X “thinks” that the whole assignment was based on a
fixed trip matrix, not just the final user class. The error is actually in SATALL
which outputs an incorrect “global value of MCGILL = 0 in the .ufs file.) This
affects all options that make use of a trip matrix, for example Select Link
Analysis which will, by default, be based on an incorrect matrix. There is a
simple work-around: redefine the trip matrix to be assigned to be the correct
one. Corrected in 10.8.20 and 10.9.2. 27/12/08
24) P1X. A problem can occur with network editing. Thus if two external simulation
nodes A and B are joined by a link in the buffer network and A, say, is
converted to an internal simulation node then node B should have an extra
arm added from A in the 11111 data file. Currently this does not happen and
semi-fatal errors occur in SATNET with the updated network .dat file.
Corrected in 10.8.21 and 10.9. 28/01/09.
25) P1X. Node selection does not work for nodal data annotated as “boxes” within
the main network plots. Corrected in 10.8.21 and 10.9. 30/01/09.
5109341 / Mar 13 E-26

11_2_05_App E.docx
26) SATLOOK. The batch file procedure SKIMTIME is meant to either include or
exclude 4444 penalty times in the definition of link times depending on
whether a parameter USETP is set T or F in SATLOOK0.DAT (See Section
15.27.7 in the Manual). However penalty times are always excluded
independent of USETP. Note that this problem does not occur with SATTUBA
or with forest skims carried out interactively/via a KEY file. Corrected in
10.8.21 and 10.9. 30/01/09.
27) SATALL/SATSIM. Messages may appear in the .LPT/.LPS files advising that
negative random delays have been calculated. These may be ignored and the
negative values have no effect on the simulation. The problem is due to
rounding errors in the calculations of random delay which may occur if a turn
saturation flow has been assigned an artificially high value such as 99999 but
not with “normal” saturation flows. Corrected in 10.9. 10/02/09.
28) SATALL. It is possible for the simulation to “hang” (i.e., to go into an infinite
loop internally) due to a calculation associated with blocking back. However
the bug has been there for over 20 years and, to the best of our knowledge,
has only “gone off” once. Corrected in 10.9 (N.B. not in 10.8 since the
correction may lead to differences in blocking back, possibly significant if the
blocking back is very “sensitive”.) 10/02/09.
29) SATPIG. The program can start to produce silly outputs and/or crash if a
(relatively) very large output file is produced due to an array dimension being
exceeded. This is most likely to happen with a large number of zones since
the array required increases in proportion to the number of zones squared
whereas the array dimension provided increases more like linearly with
network size. Correct in 10.8.21. 12/02/09.
30) SATALL. Warm starts (WSTART = T) do not work for: (a) Frank-Wolfe
assignment where either the network and/or trip matrix is changed and . UFO
file is used, (b) a single user class, and (c) some fixed flows present (e.g., bus
flows, PASSQ, etc.) Corrected in 10.8.22. 12/03/09.
31) SATNET. The logical &OPTION parameter DIADEM which is meant to permit
UPDATE and/or WSTART = T when there is no file to update does not work
when just UPDATE = T. And possibly not at all. Corrected in 10.8.22. 14/03/09
32) SATALL. It is possible for the program to crash at a very early stage if the
number of user classes (NOMADS) is relatively large. The problem occurs
while writing a list of all &PARAM REAL parameter values to .LPT when an
array dimension is exceeded. The critical maximum value of NOMADS is
probably about 14. The same error can occur in P1X under
Information/&PARAM Lists. Corrected in 10.8.22. 14/03/09.
33) SATCH. An error of long-standing may occur in cordoning a network .dat file if:
(a) the network .dat file set AUTOX = T; (b) a centroid connector of the form Z
A B is defined within the 22222 records where link A,B is inside the cordon;
and (c) A (or B) is an external simulation node which has not been explicitly
set within 11111 but only defined by AUTOX. I.e., A had been defined only as
an in-bound arm at B and then AUTOX assumes that it must be an external
simulation node. The error is that A will not now be identified by SATCH as a
node inside the cordon and the centroid connector will not be included in the
5109341 / Mar 13 E-27

11_2_05_App E.docx
output cordoned .dat file. Warning messages (though not highly explicit)
appear in the .LPC file; search for “BOSS”. Corrected in 10.8.22 and 10.9.
19/03/09.
34) SATLOOK. Another long-standing error: the network summary statistics (e.g.,
total pcu-hrs/hr) comparing several different network files give certain
misleading statistics when the networks have been run with different values of
LTP. Basically the program assumes that the value of LTP for network 1
applies to all networks so that when converting rates to absolute totals or vice
versa (e.g., this is done for fuel consumption) errors result. Corrected in 10.9.
26/03/09.
35) SATPIJA. The combination of choosing IVC > 0 and ALLIJ = T leads to
nonsensical results – no Pija matches are identified and any subsequent runs
of SATME2 will not do anything. Generally speaking there is very little reason
to set ALLIJ = T so the obvious correction is to set it F. Corrected in 10.8.22.
25/04/09.
36) SATNET. Using the CLICKS option with the data defined in an external .VSD
file (i.e., disaggregated by vehicle class and capacity index) fails if the number
of vehicle classes in the network exceeds 5. This is now a semi-fatal (NAFF)
error. Corrected in 10.8.22 and 10.9. 16/05/09
37) SATSTAT. Erroneous reporting of User Class 1 summary statistics rather
than correct values for ALL User Classes combined. Corrected in 10.8.22.
25/06/09
38) SATCOBA. The user-class flows output from a single input network with MUC
= T are output in the wrong order and (for two-way links) with directional flows
only. Corrected in 10.8.22 and 10.9.8. 26/06/09.
39) SATSTAT. Limited reporting undertaken for simulation only networks.
Corrected in SATSTAT V3.1 (as part of later 10.8.22 releases and 10.9.10.
27/07/09
40) SATALL. The program may hang under multiple user class elastic assignment
in a network which makes use of both CLICKS and CLIMAX. Corrected in
10.8.23 and 10.9.13. 01/11/09.
41) SATALL. The multicore version does work for networks which include either
elastic assignment and/or weaving movements and no warning messages
appear. This has been corrected in 10.9 such that attempting either of the
above assignment methods with MULTIC = T results in a semi-fatal error.
Corrected in 10.9.16. 01/05/10.
5109341 / Mar 13 E-28

11_2_05_App E.docx

Date of last update: 9th January 2012
released in November 2009 and/or in later 10.9 releases up to and including
10.9.22 as released in January 2011 and 10.9.24 as released in May 2011.
1) SATALL – Errors may occur when running a warm start option within MUC
OBA causing the program to abort at the first assignment stage, particularly if
there are banned turns under 44444. Corrected in 10.9.13. 01/12/09.
2) SATPIJA – The program may crash with Fatal Error 34 if the cost data
contained on the .UFC file is too large to be copied into internal memory and
therefore an external scratch file has to be created on channel 29. It may also
require that UFC109 = T. Corrected in 10.9.15. 23/02/10.
3) SATPIJA – The program may hang when run in conjunction with OBA – but
not always. Corrected in 10.9.15. 12/03/10.
4) P1X and/or SATCH – Cordoning off a network .dat file suitable for input to
SATNET may run into problems with bus routes which have a single digit
name/number written in column 5 (i.e., columns 1 to 4 are blank) in the original
network .dat file since the cordon program only checks for non-blanks in
columns 1 to 4. The error has probably been around for a long time. Corrected
in 10.9.16. 17/03/10.
5) SATALL – A floating point error may occur if the total number of assignment-
simulation loops exceeds 401. Normally MASL is limited to a maximum of 401
but it is possible that if one includes up to NIPS repetitions for signal
optimisations that MASL * NIPS > 401 and the error occurs. One solution is to
optimise the signals externally, another is to improve the network coding so
that you don’t need so many loops to converge. The error has probably been
around for a long time. Corrected in 10.9.16. 17/03/10.
6) SATLOOK – The option “-1 - SKIM TIME, DISTANCE AND TOLLS
ALTOGETHER” within the Forest Skimming Menu will crash with an error
message of non-increasing DA codes with multiple user classes networks if
you have explicitly selected a single user class (under menu choice 3).
Corrected in 10.9.16 and later versions of 10.9.12. 28/03/10.
7) SATALL – A crash may occur under elastic assignment, referencing routine
PRINT_TOP_TEN. This happens if, when the program calculates the ten worst
O-D pairs in terms of convergence to the demand model, one of the origins is
the highest numbered zone. So if you have, say, 1,000 zones the chances of
the last zone being amongst the top ten is only 1 in 100, hence the error does
not always occur. Corrected in 10.9.16. 14/04/10.
8) SKIM_ALL (SATLOOK). The program may terminate with a SATURN Fatal
Error to the effect that an output DA code exceeds 99,993 if the number of
5109341 / Mar 13 E-29

11_2_05_App E.docx
zones times user classes exceeds (approximately) 9,900. Corrected in

10.9.16. 28/04/10.
9) SATPIJA – The program gives highly unreliable PIJA data whenever UFC109
= T, It is recommended that any users wishing to use SATPIJA with UFC109 =
T switch to a very recent (10.9.17+) version or, alternatively, make sure that
UFC109 = F in their network files. Corrected in 10.9.17. 14/05/10.
10) SATPIG – The same problem as above with UFC109 = T also applies to
SATPIG. Corrected in 10.9.17. 18/05/10.
11) MX – Stacking matrices where the total number of matrix rows, i.e., the
number of zones times the number of levels, exceeds the maximum number of
zones permissible in your release version (e.g., 2,000 in the largest versions)
may result in (some of) the zone names on the output .ufm file being set to
zero. The error does not however affect the matrix cells themselves so that the
stacked matrices may be used happily enough for assignment purposes. It
also only appears to occur in exe’s produced under FTN95 (the norm) rather
than FTN77. This is a long-standing error. Corrected in 10.9.17. 21/05/10.
12) SATNET – Inputting pre-load flows from a text file with PLODFF = T along with
the various sub-options provided by PLFF3 = T or F should be used with great
caution; basically it works with some combinations of data formats and options
but not others. Corrected in 10.9.17. 11/06/10.
13) P1X – Actual vehicle class flows are the calculated the same as demand
vehicle flows for annotation. N.B. User class flows are correct. Corrected in
10.9.17. 14/06/10.
14) SATSTAT – The embedded macros within the Excel Spreadsheet do not
function in Excel 2007. Corrected in 10.9.17. 22/06/10.
15) SATSTAT – The executable is not compatible with long filenames using “.” As
part of the filename. Corrected in 10.9.17. 22/06/10.
16) P1X – The subscripted namelist variables included within the “re-create a .dat
file” option may contain unwanted spaces within the brackets; e.g., MCGILL(1)
might well be written as MCGILL( 1) with a blank between ( and 1. This may
cause the namelist data to be misinterpreted on input to SATNET. Corrected
in 10.9.18. 24/06/10.
17) SATNET – Subscripted namelist variables which contain a space – see the
example above – were not correctly interpreted as subscripted variables.
Corrected in 10.9.18. 24/06/10.
18) P1X – GIS-based crow-fly distances as calculated along curved links defined
in .GIS files and used in link annotation are correct in one direction (the
direction coded in the 77777 .GIS data file) but not the other. Equally the data
variable which is the difference between crow-fly and coded distances is
calculated as coded minus crow-fly, not the other way around as documented.
Corrected in 10.9.18. 19/07/10.
19) The simulation routines in SATALL and/or SATSIM in release 10.9.17 fail with
certain network geometries containing dummy nodes. The problem is
associated with the new “trick” introduced in 10.9.17 of treating simulation
5109341 / Mar 13 E-30
11_2_05_App E.docx
nodes in a form of topological ordering rather than purely numerical. An extra

logical parameter, SIM109, has now been added such that if SIM109 = T then
the new (improved?) topological order is adopted whereas with SIM109 = F
the old (safe) numerical order is used. Full runs with 10.9.17 are therefore not
recommended – which was effectively the same advice, though for slightly
different reasons, as given at the time of the release. All 10.9.17 analysis
programs are however still recommended for use. Corrected in 10.9.20.
06/09/10.
20) SKIM_ALL in 10.9.17 fails if the network contains 44444 time penalties (as
opposed to monetary tolls) which are output as the 4th matrix. A crash
message appears to the effect that a DA code 93 is being output and is less
than 103. Corrected in 10.9.20. 07/09/10.
21) SATALL (and/or SATSIM) may hang under certain fairly obscure
circumstances, most probably associated with simulation links with stacking
capacities in excess of, say, 100 PCUs and possibly after a large number of
loops as the run nears convergence. Corrected in 10.9.20. 07/09/10.
22) The batch procedures STACK and UNSTACK which use MX to stack /unstack
matrices may fail with the most recent versions of MX. Alternative procedures
such as MXSTACK or UFMUNSTACK are not affected. Corrected in 10.9.20.
28/09/10.
23) If MX is used to create an internal stacked matrix from an input .csv data file
where the zone names are included in the data file then the name for the last
(highest) zone is set equal to its sequential number, not its zone name. While
this does not affect the cell values, so that a matrix so created may be used
perfectly happily for assignment purposes, it does invalidate certain MX
options where a row or column has to be identified by its name as opposed to
its sequential position. N.B. The problem does not occur when the .CSV file is
used to update cell values in an existing .ufm matrix, e.g., in the batch file
CSV2UFM. Corrected in 10.9.21. 05/10/10.
24) Producing SLA matrices for all user classes in P1X using OBA does not work
– basically the option had not been included. Added in 10.9.21. 09/10/10.
25) Cordoning a stacked trip matrix for multiple user classes in P1X using OBA
only works correctly for user class 1. Corrected in 10.9.21. 13/10/10.
26) The latest version of SKIM_ALL based on 10.9.17 SATLOOK does not
correctly skim time penalties if: (a) there are no monetary tolls and (b) the
parameter NUSKIM on the preferences file = T (its default). In these
circumstances the output matrix is all zero. The problem can be corrected by
setting NUSKIM = F in the default preferences file SATLOOK0.DAT.
Alternatively, though not documented, a “temporary” alternative preferences
file may be defined by using a keyword KR on the command line, as in
SKIM_ALL net mat KR mylook0, where mylook0.dat sets NUSKIM = F. There
are no problems with any of the other three skimmed matrices. N.B. The same
problem occurs with SATTUBA which uses the same basic subroutines.
Corrected in 10.9.21. 31/10/10.
27) MX may crash when printing row and column totals for stacked matrices if one
or more totals are less than 1.0. Corrected in 10.9.22. 06/12/10.
5109341 / Mar 13 E-31
11_2_05_App E.docx
28) SATLOOK: skimming forests for, e.g., time using the interactive options for
OBA plus multiple user classes fails in that it only skims the first user class.
However batch procedures such as skimtime work perfectly well in these
situations. Corrected in 10.9.22. 06/12/10.
29) MX: The new option to print all zone names from within the Files menu has
been assigned the fixed option number 9 which may conflict with the option
number to open the 9th input matrix. It has therefore been changed in 10.9.22
to option 14. 06/12/10.
30) Offset optimisation (SATOFF or SATALL with SATOFF = T) fails (possibly
crashes) if any signalised nodes have cycle times in excess of 256 seconds.
Corrected in 10.9.22. 13/01/11.
31) SATSUMA is likely to crash with the most recent .ufs files. Corrected in
10.9.23 (unfortunately just too late for the release of 10.9.22). 22/01/11.
32) SATPIJA may run extremely slowly under OBA for user classes which (a)
have (relatively) high numbers and (b) may have a large proportion of
“missing” origins (i.e., with zero trips which have therefore not been analysed
for best routes within OBA). The problem is due to having to rewind and reread
the .UFO file each time such an origin is encountered. N.B. There are no
problems with the output .UFP file, just the time it takes to correct it. Corrected
in 10.9.23. 21/01/11.
33) SATALL: The use of the offset optimiser SATOFF = T coupled with the use of
a fixed reference offset node MANOFF may (but not necessarily) cause the
program to hang if the signalised nodes do not all have a common cycle time.
Corrected in 10.9.23. 30/01/11.
34) P1X: The complete list of link variables that may be annotated and which is
displayed as a “selection box” is not long enough to hold the maximum set of
variables which occurs when there 3 or more user classes, fixed flows, bus
flows, etc. etc. Thus certain variables such as BBF may “fall off the end”. The
problem does not occur with sub-lists such as flows, times etc. etc. Corrected
in 10.9.23. 30/01/11.
35) SATALL may (possibly) give seriously incorrect results if the input .UFN file
was created by a later release version of SATNET; i.e., the two programs are
not backwards compatible. In particular 10.9.17 SATALL does not work
properly with .UFN files produced by 10.9.23 SATNET. Previously this was a
non-fatal error 127 in SATALL but it has now been upgraded to a Fatal Error.
Corrected. 31/01/11.
36) SATALL will not output a correct .UFC file with UFC109 = T and elastic
assignment. Corrected in 10.9.23. 14/02/11.
37) P1X The banner menu may temporarily disappear during Node Graphics
Editing if the mouse is clicked “incorrectly”, i.e., not on a valid item in the
banner or a valid “box” within the node plot. Running the mouse over where
the banner should be will reveal the available option lines but none of the
“supplementary” lines. Corrected in 10.9.23. 15/02/11.
5109341 / Mar 13 E-32

11_2_05_App E.docx
38) SATNET. The FILERL option to read in an existing .ERL file is likely to fail if
the file has had an extra “title line” inserted at the top of the file. Since the title
line is now always included on output .ERL files this means that the program
will only work if (a) the title line is deleted or (b) the .ERL file is from a much
earlier version of SATNET. Corrected in 10.9.23. 25/02/11.
39) P1X. The option within PMAKE to “split” a link does not work if the link is
between an external and an internal simulation node. A long-standing problem.
Corrected in 10.9.23. 05/03/11.
40) P1X. There may be certain problems in deleting multiple simulation zones from
the 22222 data set under Network Editing / PMAKE. A long-standing problem.
Corrected in 10.9.23. 05/03/11.
41) P1X. Dumping .dat files from .ufs files may run into problems in the 88888
dumped records with a $ toll charge multiplier for a KNOBS record which is
numerically greater than 10.00 since the field gets dumped as $****. Corrected
in 10.9.23. 07/03/11.
42) P1X. A “glitch” has been corrected whereby, at present, if you select an option
from a pull-down menu from the Window Bar and that option “sits on top of”
one of the green arrows then the arrow is obeyed rather than the pull down
option. The pull down menu item now takes precedence. Corrected in 10.9.24.
18/03/11.
43) SATALL. The program may crash under MUC OBA with a Divide By Zero
error (which may actually appear on the screen as something else) if one of
the user classes has zero trips in total in the stacked .UFM matrix. Corrected
in 10.9.23. 15/03/11.
44) SATALL. A modelling “glitch” has been detected in the modelling of flared
lanes at priority junctions whereby, if the queue in either the flared lane or the
lane from which it originates is near the flare length, then it is possible for two
apparently stable solutions to exist which, inter alia, can badly affect
simulation-assignment convergence. Basically with an identical set of flows if
the simulation assumes initially that the lane is “blocking back” (queue
exceeds flare) then the outcome is that it does but if the initial assumption is
that it doesn’t then the outcome is that it doesn’t. A small change in flows may
cause the model to flip-flop between the two alternative solutions. Corrected in
10.9.23. 16/03/11.
45) P1X. The program will not run for buffer only networks (it reports an error for a
missing DA code 1993). Corrected in 10.9.23. 12/04/11.
46) PMAKE. Deleting nodes and/or links where there were comment cards before
the initial node record in the .dat file may lead to errors. Corrected in 10.9.24.
20/05/11.
47) SATCH. It is possible that if the original network contained very high 4-digit
zone numbers, e.g., up to 9901, then the newly created zone numbers at
cordon points will be 5-digit starting with 10001. While 5-digit zones may be
OK with simulation 22222 connectors, they do create problems with 33333
buffer networks if DUTCH = F. Detected as an error in 10.9.24. 20/05/11.
5109341 / Mar 13 E-33

11_2_05_App E.docx
48) MX. When building stacked matrices from “one record per cell” input files
which contain: (a) sequential O-D numbers, (b) not their names, (c) the level
and (d) the cell value the level values are in fact ignored. Thus MX interprets
the sequential origin number as being the “stacked” value; i.e., if a record
refers to sequential origin, say, 5 cell in level 2 MX expects the input origin to
be Nzones + 5, not a sequential number in the range 1 to Nzones. Whether
level is input as 1 or 2 is irrelevant. This is probably counter-intuitive although it
is the rule that is adopted when a ufm matrix is dumped to text with one record
per cell. The simplest work-around is to keep the level defined but interpret the
O-D inputs as zone “names” in the range 1 to Nzones rather than sequential,
in which case the level is applied correctly. This is a long-standing problem, no
change has yet been applied. 16/06/11.
49) P1X. Select Link Analysis fails in release 10.9.24 if two or more networks are
currently defined. The problem is that a box that requires a Yes/No return after
a link has been defined does not have enough space to include all the printed
data so the Yes/No boxes don’t appear and the program crashes. Corrected in
10.9.25. 17/06/11. N.B. A corrected P1B exe will be released.
50) P1X. The program crashes with a SATURN Fatal Error 29 when performing a
Joy Ride if the route goes through a banned turn. Corrected in 10.9.25.
23/06/11.
51) P1X. Editing 55555 network co-ordinates runs into a problem, essentially an
infinite loop trying to create an infinitely big data file, if the 55555 data includes
an old $include record commented out as *$INCLUDE (i.e., with * (correctly) in
column 1). So if you need to comment out a $INCLUDE record use, say, **
instead of *, delete it entirely, etc. The same problem may possibly, but not
necessarily, occur in other data segments as well. This is a long standing
problem corrected in 10.9.25. 24/06/11.
52) P1X. Further to 51) P1X editing of 55555 records may also get stuck in an
infinite loop if $INCLUDE is entered in lower case, i.e., $include. So use upper
case $INCLUDE throughout – although the problem is probably only related to
55555 co-ordinate inputs. This is also a long standing problem corrected in
10.9.25. 24/06/11.
53) MX. When using a network .ufs file to rename, say, sequential row names in a
stacked (multiple level) .ufm matrix with, say, non-sequential zone names from
the network the transformation is only applied to the base level, not the higher
levels. In practical terms this may make very little difference, e.g., it does not
affect the assignment, but in some circumstances it might. It has therefore
been corrected in 11.1. A long standing error. See 10.3.3. 01/07/11.
54) P1X. Editing signal settings at simulation nodes does not work if applied after
extra lines have been added to the main body of the node .dat file by either
screen editing (add comment lines) or by adding second link records (e.g., by
defining flares). Basically internal pointers are not correctly updated. You may
however update signals prior to adding extra records. Corrected in 10.9.25.
17/07/11.
55) P1X. The 10.9.24 as-supplied preferences file P1X0.dat may contain a
misleading value for the parameter XYFORM = ‘2F10.1’. Ideally this should be
5109341 / Mar 13 E-34

11_2_05_App E.docx
the same value as that used by SATNET when building networks, for which
the default is 2I5 although, in terms of values to be recommended as defaults,
2F10.1 is preferable. If the values of XYFORM differ between that used to
build a network and that used by default within P1X then problem arise in
editing X,Y co-ordinates and dumping them to a new .dat file in that the new
55555 entries will be in a different format I(i.e., 2F10.1) from the old (e.g.,2I5)
The simplest solution is simply to edit P1X0.DAT and replace 2F10.1 by a a
more appropriate local value. 17/07/11.
56) P1X. Joy rides which start at an external “spigot” node (i.e., a node which has
only one arm leading to a mid-link node plus one or more zone connectors)
and for which the second node selected is the mid-link node will fail to identify
that first link correctly. Instead the joy ride finds the second node correctly but
then adds an illegal U-turn at an adjacent node so that it creates three links
rather than one. There is a simple workaround which is to define the second
node further away than the mid-link node, in which case the joy ride will
correctly interpolate through second node. Corrected in 10.9.25. 25/07/11.
57) SATLOOK. The option to print turning flows at buffer nodes does not work at
all in release 10.9.24 (and possibly some slightly earlier releases). The
numbers printed are essentially random, probably zeros. Corrected in 10.9.25.
25/07/11.
58) P1X/SATDB. The input of actual link flows (e.g., user class flows based on the
3808 convention) from alternative networks may assign an incorrect data
column title, probably “Queue Reduction Factor”. This only affects the title, not
the content of the data read in. Corrected in 10.9.25. 02/08/11.
59) SATNET. The default value of NITA_S, documented as 99 in the Manual, is
actually 25. Upgraded to 99 in release 11.1 and in 10.9.25. 05/08/11.
60) SATALL. The combination of QUIET and REFFUB = T gives rise to a fatal
error of writing to an unopened file. Corrected in 10.9.25. 05/08/11.
61) SATLOOK. Incorrect skim matrices are produced with SKIM_TIME,
SKIM_DIST, SKIM_PEN and/or SKIM_TOLL batch files when both SPIDER
and Multi-core are used together. Skim matrices from SKIM_ALL.bat are not
affected. Corrected in 10.9.25. 13/08/11. N.B. Also available in SATLOOK
Beta within 10.9.24 as released 08/11.
62) SATNET. Spurious error messages may be generated for links which have
had flared lanes – either offside or nearside – coded. More specifically
Warning 91, Serious Warning 130 and Non-Fatal Error 226, all which involve
various levels of incompatibility between the lane allocation and the stage
definitions per turning movement, do not take account of the fact that the flared
lanes effectively provide an extra lane for certain turns which “corrects” the
incompatibility. Thus there is no problem in the simulation modelling of these
configuration and the errors should therefore be ignored. Or, alternatively,
suppressed by setting, e.g., ERRYES(91) = F (although this may also
suppress genuine examples of Warning 91. Corrected in 10.9.25. 25/08/11.
63) SATNET. Similarly Serious Warning 105 – a filter movement at signals should
have the exclusive use of lane 1 – is also spurious if a filter lane has been
coded. Since this is normally upgraded to a Semi-Fatal NAFF Error under
5109341 / Mar 13 E-35
11_2_05_App E.docx
WRIGHT = T it is slightly more annoying than 62) above but again may be
suppressed by setting ERRYES(105) = F. Corrected in 10.9.25. 25/08/11.
64) P1X. Spurious error messages as reported above under notes 62) and 63) are
also reported within node graphics. Corrections here are only included in
release 11.1. 25/08/11
65) SATPIJA_MC. The listing of error messages as generated by the first (partial)
run of SATPIJA is not included within the combined output .UFP file nor is it
printed within the final output .LPJ file. Corrected in 10.9.25 and 11.1.2.
05/09/11.
66) SATALL. If an origin has only one possible connected destination and that OD
pair has positive trips in the trip matrix and SPIDER = T then those trips are
not assigned. With SPIDER = F it is not a problem. Corrected in 10.9.25 and
11.1. 22/09/11.
67) P1X. Mid-link simulation capacities in excess of 9,999 are not currently
annotated (or are annotated as zero). They should, however, appear correctly
in print-outs of node data. Corrected in 11.1.2. 25/09/11.
68) SATNET. Similar to 67, input mid-link capacities in excess of 9,999 may, in
certain circumstances, be treated, effectively, as infinity and therefore printed
as either zero or blank. They should, however, be correctly recorded within the
.UFN file and therefore correctly used within all subsequent stages (e.g., within
the simulation) although it is probably worth checking the print-outs of node
data in P1X to see that they have been correctly recorded. Corrected in 11.1.2.
25/09/11.
69) P1X. A very, very longstanding problem. If a simulation zone Z has two or
more centroid connectors to the same simulation node A (this happens if Z has
connections to links A-B, A-C...) then each of these connectors becomes a
separate link in the map network. These are then plotted directly on top of one
another which, visually, is not a problem. However, if one tries to annotate,
say, flows the centroid connectors will display only the flow from a single
connector (which is clearly less than the total) or will display them all but over-
written. Corrected in 11.1.2 such that the total flow from all connectors is now
annotated. 28/09/11.
70) SATALL. The program may crash with an Illegal Operation (Divide by zero)
message in FLODEL in Simlib if a link with a flare coded (either nearside or
offside) has two additional turns in shared lanes which have both been
assigned zero flows. Corrected in 10.9.26 and 11.1.2. 02/10/11.
71) SATALL. If an offside flared lane at signals with an X-turn has its green times
in a totally separate and non-overlapping stage from the straight ahead traffic
then the resulting delays and capacities may be unreliable. N.B. This is also an
example of Non Fatal Error 226. Corrected in 11.1.3. 24/10/11.
72) MXM5. The matrix editing procedures may give incorrect results if the total
number of “transformations” (e,g., converting zones into sub-zones) exceeds
the maximum number of matrix zones permitted. Corrected in 11.1.3.
27/10/11.
5109341 / Mar 13 E-36

11_2_05_App E.docx
73) P1X/PMAKE. Editing either the 44444 (penalised links) or 77777 (counts) data
sets causes a crash if the total number of records in either segment (including
those in $INCLUDE files) exceeds 399. See 11.9.6 and 11.9.9. Corrected in
11.1.4 (in the sense that it no longer crashes but there is now an upper limit on
the number of 444 or 777 records which can be text edited). 26/11/11.
74) SKIM_ALL (10.9.24). There appears to be a somewhat intermittent error with
the 10.9.24 release of SATLOOK used in matrix skims via SKIM_ALL which is
manifested by very large zone numbers being included on the output .UFM
files for certain rows (normally the lowest numbered rows). The problem
appears to be associated with the use of multi-core and/or Spider. The root
cause of the problem has not been identified but it does appear to have been
corrected in the 10.9.25 release of SATLOOKB in August 2011 so users are
recommended to replace their 10.9.24 $SATLOOK.EXE by 10.9.25
$SATLOOKB.exe. The problem is, however, relatively benign in that it does
not appear to affect any of the output skimmed cell values, only the zone
numbers which are only included for information purposes. 20/11/2011.
75) SATTUBA. If the network file to be skimmed via SATTUBA contains one or
more time penalties on links (e.g., as input under 44444) then, instead of
creating a separate .txt file of skimmed penalties, the penalties are included as
part of the distance skimmed .txt files. Thus the distance .txt file contains twice
the number of required origin rows with the 2nd, 4th, 6th, ... rows containing time
penalties skims ( which are mostly zeros). This may be corrected by setting
the parameter NUSKIM = F in the SATLOOK0.DAT preferences file. Note that
the same problem does not occur if skims are output as .ufm files or if there
are no time penalties. Corrected in 11.1.7. 09/01/2012.
5109341 / Mar 13 E-37

11_2_05_App E.docx
E.7 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App E.doc
3.1 Additions to 10.6.17 DVV 10/07/06
3.5 Web Release for Jul 07 DVV NP IW IW 20/07/07
E.6 started for 10.8 bugs DVV 26/04/08

Bugs v10.3.9 removed
5109341 / Mar 13 E-38

11_2_05_App E.docx
E. SATURN Bugs
Date of last update: 1st March 2013
The following “problems” have been identified in SATURN Version 11.1 as
released in April 2012 and/or in later 11.1 releases.
1) P1X – SLA analyses using spider-based options may “double-count” certain
O-D movements through the selected link(s). The problem arises if the origin is
within a single aggregate link of the selected link; i.e., there is an aggregate
link whose A-node is the origin and which includes the selected link. There is
no problem if the origin and the selected link are well separated. N.B. The
problem applies primarily to total flows under multiple user class assignment;
individual UC flows are less affected. The problem does not occur if the control
parameter USESPI = F as may be set in P1X0.DAT or if the SPIDER option is
toggled off in the Analysis Menu. Corrected in 11.1.10. 23/05/12.
2) SATLOOK/P1X – The SATLOOK option to print total simulation statistics as
calculated within the program (Main menu option 4, then 2) does not work with
.UFT files representing multiple time period runs. Corrected in 11.1.11.
04/07/12.
3) SATALL – Using the Fixed Cost Flow (FCF) option with a network which
contains one or more Q-turns does not properly simulate those Q-turns witjin
the FCF network. In effect the capacity of the Q-turn becomes equal to the
point at which the Q delays start to kick in, i.e., 75% of the saturation flow
rather than the saturation flow. Corrected in 11.1.11. 15/07/12.
4) SATALL – Weaving segments on motorways containing more than one link
may give unreliable results with SPIDER = T. Corrected in 11.1.11. 15/07/12.
5) UFMSTACK – If the control file which lists the filenames of the matrices to be
stacked contains a blank line at the bottom that line is read as though it were
an additional filename and the procedure terminates with an error message
that (blank).ufm cannot be found. Suitable checks added in 11.1.11. 18/07/12.
6) SATALL – Various problems with the program crashing due to overflow have
occurred in a very small number of extreme situations and have been
corrected. They are all long-standing problems dating back to 10.9 and beyond
and – normally! – should have negligible effect on network results. 24/07/12.
7) SATLOOK/P1X – The routine to print out simulation+buffer summary statistics
will fail for .UFT files for greater than 5 multiple time periods. A long standing
problem which also occurred with 10.9.24 and probably for some time
previously. Corrected in 11.1.11 and also 11.1.09B. 06/08/12.
8) SATALL – The program may potentially crash while updating signal timings
(SIGOPT = T) if MYTVV = 2 or, possibly, 4. In addition the crashes only seem
5109341 / Mar 13 E-1

11_2_05_App E7.docx
to occur if certain arms have zero flow. The problems are very long standing.
Corrected in 11.1.12 and also 11.1.09b. 23/08/12.
9) SATALL – Crashes may occur relatively infrequently with FCF networks in a
subroutine SET_ESTUARY_FLOWS. Corrected in 11.1.12 and also 11.1.09b.
23/08/12.
10) SATPIJA – Crashes may occur very infrequently due to problems in the .UFC
files which were in turn created within SATALL whereby extremely low delays
might be evaluated at extremely low flows creating an underflow problem
which (bizarrely) is only manifested by times dumped to .UFC files. The
problem has been corrected in version 11.1.13 (aka 11.2) by introducing link-
dependent safeguards for very low flows/times. 06/10/12.
11) P1X – The program may stop unexpectedly during Select Link Analysis of
multiple nodes if the nodes include certain combinations of buffer and
simulation nodes. Corrected in 11.1.13. 06/10/12.
12) SATALL (RESTART) – The command line option RESTART does not work
with OBA (although it does with Frank-Wolfe). This has not yet been fixed.
Users are recommended to use a Warm Start option within SATNET.
10/10/12.
13) SATALL – UFO files produced by SATALL by OBA with SPIDER = T are
generally unusable by post-assignment analysis options such as SLA in P1X,
SATPIJA, etc. etc. Corrected in 11.1.13. 10/10/12.
14) MX – If a .GIS file is being used and which contains a 88888 section of co-
ordinates the program will potentially terminate with a “not enough RAM”
message if the matrix is stacked and the total number of stacked matrix rows
exceeds the normal limits on the maximum number of zones. Corrected in
11.1.14. 24/10/12.
15) SATUFO_MC may create a “truncated” .UFO file during its final stage when it
“merges” together the individual UC .UFO files into a single file if the network
is too large (in terms of the number of zones). Corrected in 11.2.4 – although
the 11.2 versions of SATUFO are now multi-core enabled so that
SATUFO_MC is effectively redundant. 01/03/13.
5109341 / Mar 13 E-2

11_2_05_App E7.docx
E.8 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App E.doc
3.1 Additions to 10.6.17 DVV 10/07/06
E.6 started for 10.8 bugs DVV 26/04/08

Bugs v10.3.9 removed
5109341 / Mar 13 E-3

11_2_05_App E7.docx
Appendix F - Unused
F. Unused
F.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App F.doc
5109341 / Mar 13 F-1

11_2_05_App F.docx
Appendix G - A Brief Overview of the Origin-Based Assignment Algorithm
G. A Brief Overview of the Origin-Based

Assignment Algorithm
This appendix describes the basic principles of the Origin-Based Assignment
(OBA) algorithm as developed by Hillel Bar-Gera while a Ph.D. student at the
University of Chicago under the supervision of Prof. David Boyce.
The main solution variables in this algorithm are origin-based approach
proportions, α pa , for every origin p and every link a, such that for every origin p
and node i the sum of origin-based approach proportions over all links ending at
node i is equal to one. Using origin-based approach proportions, route proportions
are determined by the product of approach proportions of all the links along the
route, that is:
γ pqr = ∏ α pa
a⊆r
Route flows are determined by the product of OD flow and route proportion, that
is:
h pqr = T pq ⋅ γ pqr
It can be shown (Bar-Gera, 2002; eq. 14) that if link a goes from node i to node j,
and if the total flow from origin p to node j is g pj , then the total flow from origin p
that arrive to node j through link a is
f pa = α pa ⋅ g pj
in that respect α pa is indeed the proportion of flow on approach a to node j for
origin p, as implied from the name of these variables.
The representation of the solution by origin-based approach proportions allows
storing a complete description of the route flows very efficiently. The efficiency of
the representation is further enhanced using the fact that at most nodes one link
receives approach proportion value of one, while the value of all other links ending
at the same node is zero. The availability of route flows can be useful for solution
analysis. It is also useful in searching for the equilibrium solution. This is a major
difference from many alternative solution procedures, including the most common
algorithm of Frank and Wolfe, which store only total link flows during the iterative
process.
A key point in this algorithm is that for every origin an a-cyclic restricting
subnetwork is chosen, A p , such that approach proportions for origin p of links that
are not included in A p are restricted to zero. Using the equation for route
proportions it can be seen that under these restrictions, for every origin, only
routes that are limited to the links in its restricted subnetwork can be used. In
particular, since A p is a-cyclic, meaning that it does not contain a directed cycle of
links, any cyclic route must contain at least one link that does not belong to A p ,
5109341 / Mar 13 G-1

11_2_05_App G.docx
and hence the flow along any cyclic route must be zero. It is important to note that
the restriction to a-cyclic subnetworks, does exclude many solutions that do not
use cyclic routes, and are usually considered legitimate. It can be shown (for
example Bar-Gera, 2002; Lemma 3) that there is always an equilibrium solution
that is a-cyclic by origin. Therefore, this restriction does not prevent the algorithm
from converging to the true equilibrium solution.
The restriction to solutions that are a-cyclic by origin has several important
advantages. First, the simple route flow interpretation presented above is, in fact,
valid only for solutions that are a-cyclic by origin. Second, a-cyclic subnetworks
allow a definition of a topological order of the nodes, which is an origin-specific
ordering of the nodes, such that every link in the restricting subnetwork goes from
a node of lower topological order to a node of higher topological order. Most
computations in the proposed algorithm are done in a single pass over the nodes,
either in ascending or descending topological order. The time required by such
computations is a linear function of the number of links in the network. This
computational efficiency is the main reason for restricting to a-cyclic solutions.
In solving the traffic assignment problem, the algorithm starts with trees of
minimum cost routes as restricting subnetworks, leading to an all-or-nothing
assignment. Then, the algorithm considers all origins in a sequential order. For
each origin the restricting subnetwork is updated, and the origin-based approach
proportions are adjusted within the given restricting subnetwork.
To update a restricting subnetwork, unused links are removed; ν i - the maximum

cost from the origin to node i within the restricting subnetwork is computed for all
nodes; and all links [i,j] such that ν i <ν j are added to the restricting subnetwork.
Once a new restricting subnetwork is found, several computationally intensive
steps are needed including reorganization of the data structure. However,
restricting subnetworks tend to stabilize fairly quickly. Therefore, it is useful to
update origin-based approach proportions while keeping the restricting
subnetworks fixed. This is done by introducing “inner iterations” as described in
the flow chart.
To update origin-based approach proportions within a given restricting subnetwork
a search direction based on shifting flow from high cost alternatives to low cost
alternatives is used. In addition to current costs, estimates of cost derivatives are
used to improve the search direction in a quasi-Newton fashion. When two
independent routes are considered, the amount of flow shifted by the search
direction equals the difference between route costs divided by the sum of route
cost derivatives, which is exactly what would be obtained by considering objective
function second-order approximation.
The second-order search direction described above is viewed as desirable flow
shifts. These are scaled by a step size between zero and one, and then truncated
to guarantee feasibility. We refer to this technique as the boundary search
procedure, as it tends to choose solutions along the boundary, although it does
consider interior points as well. This technique is somewhat different then
conventional line search techniques, where shifts are first truncated to guarantee
feasibility and only then scaled by a step size. The importance of the boundary
search for origin-based assignment is that it is effective in eliminating residual
flows, i.e. small flows on sub-optimal routes. The elimination of residual flows is
critical for algorithm convergence. (See Bar-Gera, 2002 for details.)
5109341 / Mar 13 G-2

11_2_05_App G.docx
In order to guarantee descent of the objective function, and convergence of the

algorithm, the search considers step size values of 1,1/2,1/4,1/8 etc. The stopping
condition is based on the concept of social pressure introduced by Kupsizewska
and Van Vliet (1999). The basic idea is that every traveler shifted from route r 1 to
r 2 puts pressure (positive or negative), which is equal to his/her gain (or loss) as a
result from the shift, that is according to the difference in route costs. The total
social pressure is the sum of the pressure from all the travelers. Our search
direction is good in the sense that it always enjoys positive social pressure for
small step sizes. As the step size increases, the social pressure decreases, and
eventually it may become negative. Our goal is to find the largest step size, i.e.
the first in the sequence 1,1/2,1/4,1/8… with positive social pressure. This social
pressure principle is in fact equivalent to the stopping condition of the line-search
in the Frank-Wolfe algorithm, only that this principle is applicable in certain cases
where the line-search optimization rule does not.
The origin-based algorithm has been demonstrated in numerous large-scale
applications as capable of achieving highly accurate solutions, limited only by the
accuracy of computer arithmetics, much faster than the Frank-Wolfe algorithm.
INITIALIZATION:
for every origin p
Let A p be a tree of minimum cost routes under free flow conditions from p
Let α pa equal 1 for all links in A p and 0 otherwise. (All-or-nothing assignment)

end for
MAIN LOOP:
for n=1 to number of main iterations
for every origin p
update restricting subnetwork A p
update origin-based approach proportions α pa

end for
for m=1 to number of inner iterations
for every origin p

end for
end for
end for
UPDATE RESTRICTING SUBNETWORK FOR ORIGIN P:

remove unused links from A p
5109341 / Mar 13 G-3

11_2_05_App G.docx
for every node i compute the maximum cost ν i from p to i

for every link a=[i,j]
if ν i <ν j add link a to A p

find new topological order for new A p
update data structures
UPDATE ORIGIN-BASED APPROACH PROPORTIONS FOR ORIGIN P:

compute average costs and Hessian approximations
for step size 1,1/2,1/4,1/8…
compute flow shifts and scale by step size
project and aggregate flow shifts
if social pressure is positive then stop
end for
apply flow shifts
update total link flows and link costs
REFERENCES
Bar-Gera, H. (2002) Origin-Based Algorithm for the Traffic Assignment Problem.
Transportation Science, 36, 398-417.
Bar-Gera, H. and Boyce, D. (2003) Origin-based algorithms for combined travel
forecasting models, Transportation Research 37B (5), pp. 405-422, 2003.
Boyce, D. and Bar-Gera, H. (2003) Validation of urban travel forecasting models
combining origin-destination, mode and route choices, Journal of Regional
Science, 43 (2003): 517-540.
Kupsizewska, D and Van Vliet, D. (1999) UK 101 uses for path-based
assignment, European Transport Conference 1999
Xiang, Y, Wright, I, Van Vliet, D, Bar-Gera, H. and Boyce, D (2009) A new
implementation of origin-based assignment algorithm in SATURN, European
Transport Conference 2009
5109341 / Mar 13 G-4

11_2_05_App G.docx
G.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App G.doc
5109341 / Mar 13 G-5

11_2_05_App G.docx
Appendix H -Papers on Path-Based Assignment
H. Papers on Path-Based Assignment

H.1 “101 Uses for Path-based Assignment”
Kupsizewska, D., and D. Van Vliet (1999) “101 Uses for Path-based Assignment,”
Transportation Planning Methods: Proceedings of Seminar C held at the PTRC
Transport and Planning Annual Summer Meeting, University of Sussex, Sussex,
UK, 11-15 September, no. 434.
101 USES FOR PATH-BASED ASSIGNMENT
D. Kupiszewska and D. Van Vliet

Institute for Transport Studies, University of Leeds, UK
ABSTRACT
Traditionally traffic assignment models are based on flows per link as opposed to
flows per individual O-D pair although, in principle, the latter is the basic building
block. The basic issue is the computer RAM required. This paper proposes a set
of linked traffic assignment algorithms based on path flows which, it is shown have
many desirable properties and are computationally feasible with current-day PC's.
Thus they enable faster convergence rates and more accurate estimates of small
changes in flows to be achieved via "perturbation" techniques. They are also very
useful in situations where the trip matrix to be assigned is variable, not fixed, since
a good starting point for an assignment with an updated trip matrix may be
generated by factoring path flows pro rata (which is not possible with pure link
flows). This occurs with "elastic" assignment models linked to, e.g., distribution,
modal split or time-period choice models ("peak-spreading"). In such cases more
efficient algorithms may be developed. Their efficiency is demonstrated using a
set of real-life networks.
Finally, path flows easily and quickly provide useful information for the analyses of
traffic flow patterns, for example to determine which precise trips are on a
particular link or which paths a particular O-D pair uses. They also provide
essential linkages between aggregate assignment models and more detailed
vehicle-by-vehicle simulation models.
1. INTRODUCTION
Traditionally traffic assignment models based on the fundamental principle of
Wardrop Equilibrium have almost always used algorithms whose basic building
block is the set of flows on links. Alternatives do exist; algorithms may be based
explicitly on origin-destination path flows and several examples have been
proposed, notably in the formative years of algorithm development before the
Frank-Wolfe algorithm and variants thereto became established as the standard
technique. (Note that although Frank-Wolfe calculates O-D paths it does not
explicitly store flows on individual paths since it can function perfectly happily with
flows defined at the more aggregate link-flow level.)
5109341 / Mar 13 H-1

11_2_05_App H.docx
The main pragmatic reason why path-based algorithms have not been widely
used is the fact that they require considerably more computer memory (RAM) than
link-based algorithms. Or, more to the point, they have required more memory
than has been available on standard computers for the sort of commonly-used
network dimensions. However to a large extent that problem has become less
critical with the phenomenal growth of the RAM available as standard in current-
day PCs. This paper therefore considers a number of alternative algorithms
related to Frank-Wolfe but which rely on the availability of path flow information.
We shall demonstrate that these new algorithms can be considerably more
efficient than link-based algorithms, both in terms of obtaining solutions and in
terms of analysing the solution once obtained.
Section 2 defines the problem, Section 3 describes a family of algorithms which
rely on the availability of path flows, Section 4 examines their performance in real-
life networks and Section 5 considers their potential applications for post-
assignment analysis. Finally Section 6 counts the uses and attempts to come to
101!
The descriptions are of necessity brief; longer explanations and full results are
given in a series of technical notes available on request from the authors.
2. TRAFFIC ASSIGNMENT: DIFFERENT PERSPECTIVES

Traffic assignment algorithms attempt to assign a trip matrix T ij to various paths
between their origin i and destination j in order to achieve "Wardrop equilibrium"
such that the costs on all used routes are equal and minimum and all unused
routes have equal or greater costs. Mathematically, in terms of path flows:
T pij >0 ⇒ C pij = C* ij (1a)
T pij = 0 ⇒ C pij ≥ C* ij (1b)

where T pij is the flow on path p from i to j, C pij is the path cost on pij and C* ij is the
minimum path cost from i to j. Aggregating path flows yields the equivalent link
flows V a , the flow on link a. This may be equivalenced to a constrained
minimisation problem:
min Z = ∑ ∫oVa C a ( v)dv (2)

a
subject to the assignment being "feasible" where feasibility is most easily defined
in terms of path flows:
∑ Tpij = Tij (3a)

p
Tpij ≥ 0 (3b)
With link flows the feasibility conditions are more implicit than explicit. Ensuring
that solutions are feasible is a critical issue in designing algorithms and one where
path-based algorithms have inherent advantages over link-based.
5109341 / Mar 13 H-2

11_2_05_App H.docx
The standard algorithm used to solve for Wardrop Equilibrium is the Frank-Wolfe
algorithm, at whose heart is an iterative loop in which the current solution is
improved by generating a "descent direction" and moving an optimum distance λ
which minimises Z in that direction. The direction is set by calculating the current
minimum cost routes for each origin-destination pair ij, denoted pij*, and assigning
all ij trips to those routes, creating both a new set of path flows and a
corresponding set of link flows.
In terms of link flows the optimum solution may be written:
Va( n +1) = (1 − λ)Va( n ) + λFa( n ) (4a)
where V a (n) is the link flow on iteration n and F a (n) the all-or-nothing flow. In terms
of path flows we have:
 = (1 − λ)T n pij ≠ pij *

( n +1)  pij
Tpij  n
(4b)
= (1 − λ)Tpij + λTij pij = pij *

We note that while the optimum λ value may be calculated by reference to link
flows only (since Z, eqn (2), is expressed as a function of link flows only) it is
applied at both levels.
3. PATH-BASED ASSIGNMENT ALGORITHMS

This section examines how variants of the Frank-Wolfe algorithm may be
developed by making more explicit use of path flows. We start with algorithms for
the basic problem of assigning a fixed trip matrix to a single network and move on
to more complex applications.
3.1 THE "SOCIAL PRESSURE" ALGORITHM

The general form used here is based on the principle that at each iteration trips
are transferred to the cheapest route at a rate proportional to a "Social Pressure
Factor". The Social Pressure concept is intuitively based on the idea that drivers
travelling along relatively expensive routes are more strongly inclined to shift
routes than those with costs closer to the minimum (there are equivalent more
mathematical interpretations). For example we could define social pressure as:
P pij = C pij - C* ij (5)
This leads to a different descent direction from Frank-Wolfe and a different set of
equations for the updated path flows:
5109341 / Mar 13 H-3

11_2_05_App H.docx
 n
 = (1 − λPpij )Tpij pij ≠ pij*
( n +1) 

Tpij  (6)
 (n ) n
 = Tpij + ∑ λPqijTqij pij = pij *
 q≠p
where λ is again an optimum value to minimise Z.

The advantage of the social pressure approach is that it does not adjust path
flows that are already at equilibrium (minimum cost) since their social pressure is
zero, but only those that are more expensive than the minimum. Pure Frank-
Wolfe adjusts all path flows including those that are currently in equilibrium.
A previous paper (Kupiszewska and Van Vliet 1998) has demonstrated the
improved convergence rate of a Social Pressure algorithm in terms of the number
of iterations. The point here is that it is only possible with path-based solutions.
3.2 PERTURBATION ASSIGNMENT: NETWORK ALTERATIONS

Traditionally scheme evaluation is carried out by assigning a "do nothing" or
"before" network and a "do something" or "after" network "from scratch" and
comparing the two. However, very often the "noise" in the two solutions can
effectively mask the true differences. Path-based algorithms allow one to model
changes in a network (i.e. schemes) in a "perturbation mode" by starting the
assignment in the "after" network with the path flows (and therefore link flows)
from the "before" network. The good starting point should lead to faster solutions
and, potentially, less noise.
If all links in the before network are still present in the after network then a before
assignment, whether it be expressed in terms of link or path flows, will provide a
feasible starting solution for the after network. We can write either:
VaA = VaB (7a)
or T pij A = T pij B (7b)
where A and B denote "after" and "before" respectively.

However, if one or more links are removed from the before network to create the
after network, then the set of link V a B defined above is no longer feasible for the
after network and the corrections can only be done by resorting to path flows. By
contrast it is relatively simple to identify whether or not a before path exists in the
after network; if so, use (7b); if not, reassign those path flows to, say, a minimum
cost path.
3.3 PERTURBATION ASSIGNMENT: MATRIX CHANGES

A different form of assignment perturbation occurs when the trip matrix changes
rather than the network. If it changes by a uniform factor, say 1.05 to represent
5% growth, then clearly both
5109341 / Mar 13 H-4

11_2_05_App H.docx
VaA = 1.05 V a B (8a)

and T pij A = 1.05 T pij B (8b)
give feasible equivalent starting points for after solutions in link and path-flow
space respectively. If, however, the changes are ij-dependent then we may use
equations such as:
T pij A = T pij B (T ij A/T ij B) (9)
to provide initial after path-flow solutions; there is no equivalent method using link
flows only.
There are many situations where the trip matrix changes non-uniformly within an
iterative procedure; e.g. as part of an elastic demand model where the trip matrix
changes in response to the network costs, or matrix estimation where the matrix is
updated in accordance with the latest route patterns. In both cases path-based
assignment algorithms allow one to "warm start" assignment n+1 with the results
of assignment n, leading to faster convergence within each assignment.
3.4 PATH FLOWS WITH ELASTIC ASSIGNMENT

Path flow information may also be used in a slightly different way within "internal"
elastic assignment algorithms where the trip matrix and link flows are both
adjusted simultaneously (see Hall et al, 1992). A detailed analysis of the
convergence of these algorithms which are based on Frank-Wolfe shows that
once the solution nears equilibrium its progress slows to near zero (a well - known
problem with Frank-Wolfe) but that in particular the trip matrix elements can
become "stuck" relatively far away (e.g. of the order of one or two per cent) from
their ultimate equilibrium values.
The problem, in a nutshell, is that the matrix "target" defined by the descent
direction is "near" to the current value such that large values of λ are optimal
whereas the target flows for links, being all-or-nothing, are "far away" such that
small values of λ are indicated. The inevitable compromise of small λ means that
the trip matrix can change only very slowly.
A potential improvement is to introduce two other choices of descent directions
into the algorithms:
1) With the matrix fixed consider all-or-nothing path flows.
2) With the path flows fixed in proportion vary only the trip matrix (using
equation (9) to update path and therefore link flows).
The first option is possible with only link flows available, the second is only
possible with path flow information.
3.5 APPLYING TOLLS TO NON-EQUILIBRIUM SOLUTIONS

There is a particular problem which emerges with perturbation assignment where
the change, whether to the trip matrix or the network or both, is small and which
we term "residual convergence". Thus if the before network is not perfectly
converged so that some used paths are not exactly minimum cost paths then
those path flows will continue to change in the after network even though they
5109341 / Mar 13 H-5

11_2_05_App H.docx
may not be directly affected by the network changes. Indeed they would indicate
differences even if the after network were completely unchanged.
We therefore need a technique which will, in effect, "freeze" the before solution
and allow only the "true" changes to occur in the after network. In theory this
could be done by reducing the cost on the more expensive routes to make them
equal to the minima, thus converting a non Wardrop equilibrium solution into an
equilibrium solution. An alternative and very elegant solution to this problem has
been recently provided in a paper by Hagstrom (1998) in which she showed how,
by associating "tolls" with links, the costs on used paths could be increased to
equal that on the maximum cost used path (as opposed to bringing all path costs
down to the minimum using reduced costs; the end result is the same).
However these tolls have to be "commodity specific", where a commodity is, e.g.,
flow for a particular O-D pair, or all flows from one origin or to one destination.
Hence each link would potentially need one toll per commodity which is fine in
theory but leads to practical problems of computer storage in large networks. A
further requirement is that the commodity flows must not form "cycles" in the
network, i.e. a series of links such as A-B, B-C, and C-A that form a closed loop or
cycle.
To make the algorithm practical it is essential to be able to define the commodities
at the zonal level (i.e. by origin or by destination), not the O-D level, and to
guarantee the absence of cycles per zone. This requires the development of two
new algorithmic techniques, the first to remove cycles and the second to calculate
the tolls (plus, strictly speaking, a third to do an assignment with commodity-
specific tolls in place but this, compared to the first two, is relatively simple).
3.6 REMOVING CYCLES

The removal of cycles may be achieved by applying a technique known as
"cleaning" which involves, firstly, identifying path flows which might be part of
cycles and then removing them from the solution.
Thus, rather than looking for cycles directly, the cleaning algorithm identifies those
O-D paths with T pij > 0 which contain "backward" links, where a link A-B moves
backward relative to the origin if the minimum cost from the origin to B is less than
the minimum cost to A. Clearly such paths pij cannot be minimum cost paths and
therefore, from (1b), should have T pij = 0. Less clearly, backwards paths are a
necessary (but not sufficient) condition for cyclical flows. (N.B. The concept of a
backward path is closely related to the "unreasonable" path definition of Dial
(1972).)
By removing backward paths we should be (a) moving nearer to Wardrop
equilibrium (as shown by Janson et al (1987)) and (b) removing cycles.
A number of strategies for re-assigning flows on backward paths have been
devised. The most obvious is to reassign them totally to the current minimum cost
paths. An alternative general principle is to reassign them to the minimum cost
paths but with an optimum proportion λ chosen to minimise Z. The disadvantage
of the latter is that, whilst minimising Z in the short term, it does not remove
backward trips - the purpose of the exercise - unless λ = 1. Several alternative
strategies have been investigated.
5109341 / Mar 13 H-6

11_2_05_App H.docx
3.7 APPLYING TOLLS

An algorithm to calculate a set of commodity - specific tolls to bring a non-
equilibrium assignment into a 100% equilibrium solution has been presented by
Hagstrom (1998) and will not be plagiarised here. We can confirm the validity of
the algorithm by network tests applied at the origin level once all cycles have been
removed. We further note that the number of links which require tolls is relatively
small.
4. RESULTS
This section evaluates the algorithms described in Section 3 via a series of tests
on real-life networks whose dimensions are listed in Table 1.
Table 1: Network Dimensions
Zones Nodes Links No. of Tij>0 K Bytes
York 176 1246 2329 27574 7140
Cambridge 141 1690 2795 7575 3509
Chester 132 1356 2104 3066 1071
Leeds North West 70 913 1406 3222 836
Headingley 29 73 188 252 20
The objective of the tests from 4.2 onwards is simply to see whether the new
algorithms can obtain the "correct" answer - or, more accurately, the correct
answer within specified error limits - to assignment problems using either fewer
iterations or less cpu time than conventional algorithms. As a general rule the
"answer" is assumed to be the total cost of vehicle travel within the network (Σ V a
C a ) such that differences between two networks may be interpreted as scheme
benefits.
4.1 MEMORY (RAM) REQUIREMENTS

We note first that even for the two largest networks tested, York and Cambridge
which might be classified as "moderately" sized networks, the memory
requirements listed are not excessive by current standards of 32 or 64 Mbyte PCs.
The vast majority of memory is needed to store path definitions and it is therefore
roughly proportional to the number of O-D pairs with positive flow, the number of
paths used per O-D pair and the number of links per path. The method is
therefore more memory-efficient with "sparse" trip matrices such as Cambridge
where the 7575 used cells represent around 38% of the total intra-zonal cells as
opposed to York (where presumably the trip matrix has been obtained via a
synthetic process as opposed to purely observed trips) where some 90% of the
cells are filled. Given that with large observed matrices typically less than 10% of
the cells are filled we note that a network with, say, 500 zones might have the
same memory requirements as York in terms of numbers of paths. (Although we
might expect the number of links per path to increase roughly as the square root
5109341 / Mar 13 H-7

11_2_05_App H.docx
of the network dimensions. On this reckoning a 500 zone network with 27,574
used cells, 11% occupancy, would need around 12 Mbytes).
We may also note that the programs have not been written with the explicit
objective of minimising RAM (particularly since it was not a problem); reducing cpu
was a greater concern. There remain a number of "tricks" which could be invoked
to reduce RAM if required.
Overall we conclude that while the methods described here may not yet be
feasible for the world's largest networks on the world's normal computers they are
certainly feasible for the majority of "normal" networks.
4.2 NETWORK PERTURBATIONS

Results on the evaluation of small network changes using a combination of
perturbation assignment and Social Pressure have been reported elsewhere
(Kupiszewska and Van Vliet, 1998). This demonstrated that perturbation
techniques were able to give accurate estimates of changes in total network costs
within a small number of iterations (sometimes a single iteration was sufficient)
and at a much reduced cpu time compared to the standard method of comparing
two network assignments run "from scratch".
4.3 MATRIX PERTURBATIONS

A "perturbed" York matrix was created by artificially adding 50 trips to a single
origin (zone 46) and factoring up all destination trips pro rata. (The original matrix
contained 38,830 inter-zonal trips.) Exhaustive assignments (800 iterations)
showed that the extra trips increased the average time per trip by 2.30 seconds
(from 782.83 to 785.13).
To evaluate the effect of these extra trips via perturbations we first ran the network
with the "before" matrix for 399 iterations (using Social Pressure) to obtain a
before cost of 782.97. We then ran the same network with the after matrix in
perturbation mode; i.e. with initial path flows as defined by (9). After just one
iteration we obtained a cost of 785.41 which gives a disbenefit of 2.44, an "error"
of only 0.14 or 6% from the "best" figure of 2.30. 398 additional iterations reduced
the cost to 785.13, a difference of 2.16 and, coincidentally, the same absolute
error of 6% as after one perturbation iteration. Hence a single iteration of a
perturbation algorithm has provided as accurate estimate of the change in costs
as 399.
Another way to appreciate the accuracy of this result is to compare it to the results
of assigning the two matrices "from scratch" for an equal number of iterations and
looking at the differences. Running both for 399 iterations yielded a disbenefit of
785.14 - 782.97 = 2.17, an "error" of -0.13 very similar in magnitude to the error of
0.14 with a single perturbation iteration. Again a single perturbation iteration is as
good as 399 from scratch.
4.4 "WARM STARTS" IN ELASTIC ASSIGNMENT

A preliminary series of tests was carried out using the base York network (Table
1) under the following elastic demand model:
5109341 / Mar 13 H-8

11_2_05_App H.docx
Tij (C ij ) = 1.6 x Tijo (C ij / C ijo ) −0.5 (10)
where T ij o and C ij o are the base year matrix and resulting cost matrix respectively
and C ij is the cost matrix consistent with T ij . The factor 1.6 represents an
exogenous 60% growth from the base year. The specific convergence of the
algorithms with respect to the trip matrix is given by:
RAAD = ∑ Tij − Tij (C ij ) / n (11)

ij
the relative average absolute difference between the estimated road trip matrix
and the demand matrix resulting from the current minimum costs. The algorithms
tested involved two "half" steps per normal iteration, one with both the trip matrix
and the (all-or-nothing) path flows adjusted and one with the path flow proportions
fixed and the matrix variable (basically method 2 in section 3.4).
Broadly speaking the modified technique gave consistently improved RAAD
values although the improvements might be best described as "clear" rather than
spectacular. For example after 25 iterations the basic and improved algorithm
gave RAAD values of 2.14% and 1.49%; after 399 the figures were 0.12% and
0.06%.
4.5 REMOVING CYCLICAL FLOWS

The "obvious" cleaning strategy, described above, was found to be successful in
removing cycles from all five basic test networks (see Table 1). In the York
network all cycles were removed after 95 Frank-Wolfe iterations with an extra
cleaning step applied every 5 iterations; i.e. 19 cleaning steps were required. In
Headingley two applications of cleaning after each 3 iterations were necessary to
remove cycles. In all other networks tested the maximum number of cleaning
steps was 21.
Note that although all cycles could be removed from the network this did not imply
that all backward paths were also removed. In fact in no network, over a
maximum of 399 iterations was it possible to remove all backward paths, although
in some their number was reduced to less than 1% of all used paths.
By contrast, in the normal application of Frank-Wolfe/Social Pressure, those
origins with cycles, once created, were unchanged over a full 399 iterations.
Generally speaking most networks had cycles created from, say, 80 to 90% of the
origins, i.e. not necessarily every origin. In only one network tested, Leeds North
West, were no cycles created by the normal algorithms.
However in terms of standard convergence statistics the results were less
impressive. While the methods with cleaning steps generally gave reduced "gap"
values, for example the improvements were noticeable rather than spectacular.
For example, after 100 iterations of the York network the gap was 0.24% without
cleaning, 0.08% with.
These results are somewhat disappointing in that it might have been expected
that getting rid of cycles in the network would "break the log jam" in Frank-Wolfe
5109341 / Mar 13 H-9

11_2_05_App H.docx
and allow convergence to proceed unobstructed to near zero levels. More work
needed!
Experiments with other strategies were inconclusive. There was no clear-cut
"pecking order" amongst the different strategies in that the technique that worked
best in one network might not be best in a different network. This suggests that a
"mixed strategy" in which the different techniques were all used at different
intervals might be safest in terms of removing cycles.
4.6 USING TOLLS TO CONVERT A NON-EQUILIBRIUM SOLUTION TO

EQUILIBRIUM
The principle of applying tolls to a "before" network to bring it into equilibrium prior
to commencing a perturbation assignment was tested on the Headingley network
(see Table 1) where the "scheme" tested involved reducing the capacity of a
heavily-used link by 15%. The results in terms of total network vehicle-costs are
given in Table 2.
Thus exhaustive before and after assignments - "∞" iterations - show that the
capacity reduction increases costs by 3.188. If we were to stop the before
assignment after 9 iterations (with cleaning to remove cycles), calculate tolls and
carry those tolls through to one perturbation iteration of the after network the cost
increase is 3.233 from 339.859 to 343.092 (excluding toll costs), an "error" of
1.4% from 3.188. Had we run 10 before iterations the difference would be 3.152,
a change of only 0.081 from 9 iterations even though the individual totals
themselves were changing by around 5.0. Comparing 20 and 21 before iterations
we find a constant error of 0.16% despite a change in the individual cost
components of 1.073.
We conclude that the differences obtained by this method are far more stable, by
around 2 orders of magnitude, than the individual totals. These excellent results
of course need further confirmation from other networks and other "schemes" as
well as examining how the results change over more than one after perturbation.
Table 2: Total Costs; Headingley; One extra tolled iteration
Iterations Before After +1 Difference Error (%)

9 339.859 343.092 3.233 1.4
10 344.853 348.005 3.152 1.1
11 340.111 343.274 3.163 0.8
12 339.077 342.279 3.202 0.4
…
20 338.747 341.930 3.183 0.16
21 339.206 342.394 3.183 0.16
…
"∞" 339.586 342.764 3.188
5. POST-ASSIGNMENT ANALYSIS
While the most important function of an assignment is to obtain estimates of the
link flows and costs it is very often equally important to be able to analyse in detail
5109341 / Mar 13 H-10

11_2_05_App H.docx
the pattern of detailed path flows used to obtain these link flows. Examples
include:
1) Examining O-D routes to "validate" the assignment based on observed
routing patterns.
2) "Select link assignment"; i.e. which O-D movements have been assigned to
a particular link (or set of links as in a screen line or along a new road); also
used for validation.
3) "Cordoning" a network to obtain a trip matrix for a sub-area.
4) "P ija " data sets as used in matrix updates.
5) Transferring assignment information from "macroscopic" models to
"microscopic" models (e.g. from SATURN to DRACULA).
6) "Skimming"; e.g. obtaining the average O-D travel distance or time along
routes generated by minimum cost assignment.
7) Differentiating between "cold" and "warm" engines based on distance from
their origins in order to obtain emission estimates.
It is of course possible to obtain all the information above using conventional
models as long as it is possible to re-construct all the trees and the final
proportions by iteration used in the assignment. For example SATURN (Van Vliet
and Hall, 1998) does this by saving the costs used in each assignment iteration.
However this method is neither particularly efficient in terms of memory
(particularly if a large number of iterations are used to obtain accurate solutions)
or cpu time (since the analysis can take virtually as long as the original
assignment).
On the other hand with path flows stored a priori calculations such as those above
may be done perfectly naturally with minimal programming complexity and
efficient cpu. Moreover the methodology will be independent of the exact
algorithm used to generate the path flows; it will work equally well, for example,
with Social Pressure algorithms where each O-D pair will have its own set of path-
flow proportions and with Frank-Wolfe where the λ-generated proportions are the
same over all O-D pairs.
6. CONCLUSIONS
The most important outcome from this research has been to demonstrate the
feasibility of basing traffic assignment algorithms for realistic networks on path
flows rather than link flows. A number of the benefits of so doing have been
demonstrated; more will no doubt emerge in the future.
In terms of the benefits already established the most important has been the
capability to estimate the impact of small changes to either the network properties
or the trip matrix using perturbation techniques requiring a small number of
iterations - or even a single iteration. An improved version of the basic elastic
assignment algorithm has been devised and tested; further enhancements are
likely.
5109341 / Mar 13 H-11

11_2_05_App H.docx
The next stage in the process - as far as the second author is concerned - is to
fully implement path-based algorithms within SATURN where, it is envisaged, they
will ultimately become the standard. Their role within the assignment process is
already operational; they are currently being implemented within the analysis
functions of SATURN where path flow analyses as described in Section 5 are
routinely carried out.
The other main strand of application in the near future is likely to be within the
area of Variable Demand Modelling linked to traffic assignment (Bates et al,
1999). A DETR sponsored project is investigating the practicality of introducing
more complex demand models (as opposed to the simpler elasticity models)
which will require a far greater number of repeated assignments within "outer
loops" of a complex demand model. It is our view that the best way to make these
complex models computationally feasible is to have assignment models which can
be run in a "perturbation mode" which, in turn, requires path flows.
ACKNOWLEDGEMENTS
We gratefully acknowledge a grant from EPSRC which supported this research. It
is also a pleasure to acknowledge many fruitful discussions over the years - and
ideas pinched from! - Mike Smith, Helmut Schittenhelm, Michael Patriksson,
Helena Cybis, Judith Wang, Sameiro Carvalho, Mike Hall and Jane Hagstrom.
BIBLIOGRAPHY
Bates, J.J., Coombe, D., Porter, S. and Van Vliet, D. (1999) Allowing for Variable
Demand in Highway Scheme Assessment. European Transport Conference.
Cambridge.
Dial, R.B. (1972) A Probabilistic Multipath Algorithm which Obviates Path
Enumeration. Transportation Research, 5, pp.83-111.
Hagstrom, J.N. (1998) Computing Tolls and Checking Equilibrium for Traffic
Flows, Submitted to Transportation Science.
Hall, M.D., Fashole-Luke, T., Van Vliet, D. and Watling, D.P. (1992) Demand
Responsive Assignment in SATURN. Proceedings of the 20th PTRC Summer
Annual Meeting, Manchester.
Janson, B.N. and Zozaya-Gorostiza, C. (1987) The Problem of Cyclic Flows in
Traffic Assignment. Transportation Research, 21B, pp.299-310.
Kupiszewska, D. and Van Vliet, D. (1998) Incremental Traffic Assignment: A
Perturbation Approach. In Mathematics in Transport Planning and Control.
Proceedings of the Third IMA International Conference on Mathematics in
Transport Planning and Control, Pergamon Press, pp.155-165.
Van Vliet, D. and Hall, M.D. (1998) The SATURN 9.4 User Manual, W.S. Atkins,
Epsom.
5109341 / Mar 13 H-12

11_2_05_App H.docx
H.2 Paper presented in Poland 1999

D. Van Vliet and D. Kupiszewska*
Institute for Transport Studies
University of Leeds
LEEDS, LS2 9JT, UK
Email: d.vanvliet@its.leeds.ac.uk, Telephone: +44(0)113 2335338, Fax:
+44(0)113 2335334
*Address: Wiejska 9 m 48, 00-480 Warszawa, Poland. Tel: (+48) 22 629 1021,
Fax: (+48) 22 6214094
PATH-BASED ALGORITHMS FOR TRAFFIC ASSIGNMENT
SUMMARY
This paper proposes a set of linked traffic assignment algorithms based on path
flows as opposed to flows per link. These algorithms are shown to converge
faster, particularly under "perturbation" conditions with small changes to the
network and/or the trip matrix. They are also computationally feasible with
current-day pc's.
1. INTRODUCTION
Traditionally traffic assignment models based on the fundamental principle of
Wardrop Equilibrium have almost always used algorithms whose basic building
block is the set of flows on links. Alternatives do exist; algorithms may be based
explicitly on origin-destination path flows and several examples have been
proposed, notably in the formative years of algorithm development before the
Frank-Wolfe algorithm and variants thereto became established as the standard
technique. More recently algorithms based on origin-specific flows have been
proposed.
The main pragmatic reason why path-based algorithms have not been widely
used is the fact that they require considerably more computer memory (RAM) than
link-based algorithms. Or, more to the point, they have required more memory
than has been available on standard computers for the sort of commonly-used
network dimensions. However to a large extent that problem has become less
critical with the phenomenal growth of the RAM available as standard in current-
day PCs. This paper therefore considers a number of alternative algorithms
related to Frank-Wolfe but which rely on the availability of path flow information.
We shall demonstrate that these new algorithms can be considerably more
efficient than link-based algorithms, both in terms of obtaining solutions and in
terms of analysing the solution once obtained.
Section 2 defines the problem, Section 3 describes a family of algorithms which
rely on the availability of path flows, with indications of their performance in real-
life networks, and Section 4 considers their potential applications for post-
assignment analysis. Finally Section 5 concludes.
More detailed results are given in a series of technical notes available on request
from the authors or in references [4, 5].
5109341 / Mar 13 H-13

11_2_05_App H.docx
2. TRAFFIC ASSIGNMENT: DIFFERENT PERSPECTIVES

Traffic assignment algorithms attempt to assign a trip matrix T ij to various paths
between their origin i and destination j in order to achieve "Wardrop equilibrium"
such that the costs on all used routes are equal and minimum and all unused
routes have equal or greater costs. Mathematically, in terms of path flows:
T pij >0 ⇒ C pij = C* ij (1a)
T pij = 0 ⇒ C pij ≥ C* ij (1b)

where T pij is the flow on path p from i to j, C pij is the path cost on pij and C* ij is the
minimum path cost from i to j. Aggregating path flows yields the equivalent link
flows V a , the flow on link a. This may be equivalenced to a constrained
minimisation problem:
min Z = ∑ ∫oVa C a ( v)dv (2)

a
subject to the assignment being "feasible" where feasibility is most easily defined
in terms of path flows:
∑ Tpij = Tij (3a)

p
Tpij ≥ 0 (3b)
With link flows the feasibility conditions are more implicit than explicit. Ensuring
that solutions are feasible is a critical issue in designing algorithms and one where
path-based algorithms have inherent advantages over link-based.
The standard algorithm used to solve for Wardrop Equilibrium is the Frank-Wolfe
algorithm, at whose heart is an iterative loop in which the current solution is
improved by generating a "descent direction" and moving an optimum distance λ
which minimises Z in that direction. The direction is set by calculating the current
minimum cost routes for each origin-destination pair ij, denoted pij*, and assigning
all ij trips to those routes, creating both a new set of path flows and a
corresponding set of link flows.
In terms of path flows the optimum solution may be written:
 = (1 − λ)T n pij ≠ pij *

( n +1)  pij
Tpij  n
(4)
= (1 − λ)Tpij + λTij pij = pij *

We note that while the optimum λ value may be calculated by reference to link
flows only (since Z, eqn (2), is expressed as a function of link flows only) it is
applied at both levels.
5109341 / Mar 13 H-14

11_2_05_App H.docx
3. PATH-BASED ASSIGNMENT ALGORITHMS

This section examines how variants of the Frank-Wolfe algorithm may be
developed by making more explicit use of path flows. We start with algorithms for
the basic problem of assigning a fixed trip matrix to a single network and move on
to more complex applications. Brief references are made to empirical results
obtained by applying these algorithms to a range of real-life networks, the largest
of which contained 176 zones, 1246 nodes and 2329 links.
3.1 THE "SOCIAL PRESSURE" ALGORITHM

The general form used here is based on the principle that at each iteration trips
are transferred to the cheapest route at a rate proportional to a "Social Pressure
Factor". The Social Pressure concept is intuitively based on the idea that drivers
travelling along relatively expensive routes are more strongly inclined to shift
routes than those with costs closer to the minimum (there are equivalent more
mathematical interpretations). For example we could define social pressure as:
P pij = C pij - C* ij (5)
This leads to a different descent direction from Frank-Wolfe and a different set of
equations for the updated path flows:
 n
 = (1 − λPpij )Tpij pij ≠ pij*
( n +1) 

Tpij  (6)
 (n ) n
 = Tpij + ∑ λPqijTqij pij = pij *
 q≠p
where λ is again an optimum value to minimise Z.

The advantage of the social pressure approach is that it does not adjust path
flows that are already at equilibrium (minimum cost) since their social pressure is
zero, but only those that are more expensive than the minimum. Pure Frank-
Wolfe adjusts all path flows including those that are currently in equilibrium. A
previous paper [4] has demonstrated the improved convergence rate of a Social
Pressure algorithm in terms of the number of iterations.
3.2 PERTURBATION ASSIGNMENT: NETWORK ALTERATIONS

Traditionally scheme evaluation is carried out by assigning a "do nothing" or
"before" network and a "do something" or "after" network "from scratch" and
comparing the two. However, very often the "noise" in the two solutions can
effectively mask the true differences. Path-based algorithms allow one to model
changes in a network (i.e. schemes) in a "perturbation mode" by starting the
assignment in the "after" network with the path flows (and therefore link flows)
from the "before" network. The good starting point should lead to faster solutions
and, potentially, less noise.
5109341 / Mar 13 H-15

11_2_05_App H.docx
If all links in the before network are still present in the after network then a before
assignment, whether it be expressed in terms of link or path flows, will provide a
feasible starting solution for the after network. We can write either:
VaA = VaB (7a)
or T pij A = T pij B (7b)
where A and B denote "after" and "before" respectively.
However, if one or more links are removed from the before network to create the
after network, then the set of link V a B defined above is no longer feasible for the
after network and the corrections can only be done by resorting to path flows. By
contrast it is relatively simple to identify whether or not a before path exists in the
after network; if so, use (7b); if not, reassign those path flows to, say, a minimum
cost path.
3.3 PERTURBATION ASSIGNMENT: MATRIX CHANGES

A different form of assignment perturbation occurs when the trip matrix changes
rather than the network. If it changes by a uniform factor, say 1.05 to represent
5% growth, then clearly both
VaA = 1.05 V a B (8a)
and T pij A = 1.05 T pij B (8b)
give feasible equivalent starting points for after solutions in link and path-flow
space respectively. If, however, the changes are ij-dependent then we may use
equations such as:
T pij A = T pij B (T ij A/T ij B) (9)
to provide initial after path-flow solutions; there is no equivalent method using link
flows only.
There are many situations where the trip matrix changes non-uniformly within an
iterative procedure; e.g. as part of an elastic demand model where the trip matrix
changes in response to the network costs, or matrix estimation where the matrix is
updated in accordance with the latest route patterns. In both cases path-based
assignment algorithms allow one to "warm start" assignment n+1 with the results
of assignment n, leading to faster convergence within each assignment.
Empirical tests show that, with a well-converged prior network, the change in total
vehicle-cost created by adding 50 trips to 38,830 could be estimated to an
equivalent accuracy by a single perturbation assignment as with 399 iterations
"from scratch".
3.4 PATH FLOWS WITH ELASTIC ASSIGNMENT

Path flow information may also be used in a slightly different way within "internal"
elastic assignment algorithms where the trip matrix and link flows are both
adjusted simultaneously [2]. A detailed analysis of the convergence of these
algorithms which are based on Frank-Wolfe shows that once the solution nears
equilibrium its progress slows to near zero (a well - known problem with Frank-
5109341 / Mar 13 H-16

11_2_05_App H.docx
Wolfe) but that in particular the trip matrix elements can become "stuck" relatively
far away (e.g. of the order of one or two per cent) from their ultimate equilibrium
values.
The problem, in a nutshell, is that the matrix "target" defined by the descent
direction is "near" to the current value such that large values of λ are optimal
whereas the target flows for links, being all-or-nothing, are "far away" such that
small values of λ are indicated. The inevitable compromise of small λ means that
the trip matrix can change only very slowly.
Two alternative choices of descent directions are:
♦ With the matrix fixed consider all-or-nothing path flows.
♦ With the path flows fixed in proportion vary only the trip matrix (using equation
(9) to update path and therefore link flows).
The first option is possible with only link flows available, the second is only
possible with path flow information. Empirically option 2 is observed to improve
the trip matrix convergence with minimum impact on the path-flow convergence.
3.5 REMOVING CYCLES

Previous research [3] has demonstrated that one of the main problems with
Frank-Wolfe is that it allows cycles to develop whereby a cycle exists if a set of
links, each of which carries flows for a particular o-d link, form a closed loop. By
removing cycles convergence may be improved.
However, rather than looking for cycles directly, an alternative "cleaning" algorithm
is to identify those o-d paths with T pij > 0 which contain "backward" links, where a
link A-B moves backward relative to the origin if the minimum cost from the origin
to B is less than the minimum cost to A. Clearly such paths pij cannot be
minimum cost paths and therefore, from (1b), should have T pij = 0. Less clearly,
backwards paths are a necessary (but not sufficient) condition for cyclical flows.
(N.B. The concept of a backward path is closely related to the "unreasonable"
path definition of Dial [1]).
A number of strategies for re-assigning flows on backward paths may be devised.
The most obvious is to reassign them totally to the current minimum cost paths.
An alternative general principle is to reassign them to the minimum cost paths but
with an optimum proportion λ chosen to minimise Z. The disadvantage of the
latter is that, whilst minimising Z in the short term, it does not remove backward
trips - the purpose of the exercise - unless λ = 1. Empirical tests indicate that all
cycles may be removed by a maximum of, roughly speaking, 100 Frank-Wolfe
iterations with cleaning steps every 5 iterations. Some networks required much
fewer.
4. POST-ASSIGNMENT ANALYSIS
While the most important function of an assignment is to obtain estimates of the
link flows and costs it is very often equally important to be able to analyse in detail
the pattern of detailed path flows used to obtain these link flows. Examples
include:
5109341 / Mar 13 H-17

11_2_05_App H.docx
♦ Examining O-D routes to "validate" the assignment based on observed

routing patterns.
♦ "Select link assignment"; i.e. which O-D movements have been assigned to a
particular link (or set of links as in a screen line or along a new road); also
used for validation.
♦ "Cordoning" a network to obtain a trip matrix for a sub-area.
♦ "P ija " data sets as used in matrix updates.
♦ Transferring assignment information from "macroscopic" models to

"microscopic" models (e.g. from SATURN to DRACULA).
♦ "Skimming"; e.g. obtaining the average O-D travel distance or time along
routes generated by minimum cost assignment.
♦ Differentiating between "cold" and "warm" engines based on distance from

their origins in order to obtain emission estimates.
It is of course possible to obtain all the information above using conventional
models as long as it is possible to re-construct all the trees and the final
proportions by iteration used in the assignment. However this method is neither
particularly efficient in terms of memory nor cpu time.
On the other hand with path flows stored a priori calculations such as those above
may be done perfectly naturally with minimal programming complexity and
efficient cpu. Moreover the methodology will be independent of the exact
algorithm used to generate the path flows.
5. CONCLUSIONS
The most important outcome from this research has been to demonstrate the
feasibility of basing traffic assignment algorithms for realistic networks on path
flows rather than link flows. A number of the benefits of so doing have been
demonstrated; more will no doubt emerge in the future.
In terms of the benefits already established the most important has been the
capability to estimate the impact of small changes to either the network properties
or the trip matrix using perturbation techniques requiring a small number of
iterations - or even a single iteration. An improved version of the basic elastic
assignment algorithm has been devised and tested; further enhancements are
likely.
6. ACKNOWLEDGEMENTS
We gratefully acknowledge a grant from EPSRC which supported this research. It
is also a pleasure to acknowledge many fruitful discussions over the years - and
ideas pinched from! - Mike Smith, Helmut Schittenhelm, Michael Patriksson,
Helena Cybis, Judith Wang, Sameiro Carvalho, Mike Hall, Bob Dial and Jane
Hagstrom.
5109341 / Mar 13 H-18

11_2_05_App H.docx
7. REFERENCES
1) Dial, R.B. (1972) A Probabilistic Multipath Algorithm which Obviates Path
Enumeration. Transportation Research, 5, pp.83-111.
2) Hall, M.D., Fashole-Luke, T., Van Vliet, D. and Watling, D.P. (1992) Demand
Responsive Assignment in SATURN. Proceedings of the 20th PTRC
Summer Annual Meeting, Manchester.
3) Janson, B.N. and Zozaya-Gorostiza, C. (1987) The Problem of Cyclic Flows
in Traffic Assignment. In: Transportation Research, 21B, pp.299-310.
4) Kupiszewska, D. and Van Vliet, D. (1998) Incremental Traffic Assignment: A
Perturbation Approach. In Mathematics in Transport Planning and Control.
Proceedings of the Third IMA International Conference on Mathematics in
Transport Planning and Control, Pergamon Press, pp.155-165.
5) Kupiszewska, D. and Van Vliet, D. (1999) 101 Uses for Path-based
Assignment. European Transport Conference, Cambridge.
5109341 / Mar 13 H-19

11_2_05_App H.docx
H.3 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App H.doc
5109341 / Mar 13 H-20

11_2_05_App H.docx
Appendix I - Link Annotation Data Lists in P1X
I. Annotation Data Lists in P1X

This appendix lists the link data items which may be selected for annotation from
the standard lists within P1X for links, turns and nodes. See 11.6.2, 11.6.6 and
11.6.5 respectively.
Each data item contains: (a) a numerical value as used for selection under
“keyboard mode” (i.e., within SATDB); (b) the “short” description which appears in
the P1X choice windows; and (c) a “longer” description which specifies the precise
definition of each quantity as necessary. References to sections within the
Manual where a full description is given are optionally included.
Some of the data items correspond directly to data stored in a DA Code on the
.uf* file, in which case the code is noted; over half do not. However, those that do
not will have been calculated by the manipulation of data read directly from DA
codes and, if the calculation is straightforward, it is indicated.
N.B. In the case of certain flow variables such as user class flows the DA code
listed is that containing the demand flow although it is possible that the flow
actually selected could be either demand, accept or queued depending on options
selected elsewhere.
The list of link data is further subdivided into 5 sub-lists, corresponding to the 5
different sub-windows which the user may select
I.1 Link Data

Note that “link data” 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.
I.1.1 Properties
No Title Explanation
6 Distance (metres) As input in metres on the 11111 / 33333 data
records, not crow-fly (unless the original input
value was zero which was then replaced by a
crow-fly distance by SATNET). See 6.4.5. DA
1893.
1 Lanes Number of lanes at the downstream stop line
(simulation links only)
2 Stacking capacity The number of pcu’s which may “stack on a
simulation link before blocking back
commences; see 6.4.11. DA 363
3 Capacity Index A numerical index whose interpretation is
open to the user to decide. See 5.1.9 DA 604
33 Per cent green split Percentage of the cycle time for which a link
receives a green signal (flow weighted by
individual turns) DA 1598
5109341 / Mar 13 I-1

11_2_05_App I.docx
38 TAX Number of X-priority-marker pcus which are
allowed to queue in the middle of the junction
prior to clearing at the end of a green phase.
See 6.4.2.2. DA 463
39 RBKS Factor to model the effect of entry flows on
exits from the same arm at roundabouts. See
8.7.2. DA 473
53 Weave Markers See 6.4.2.5
54 Merge Markers See 6.4.2.3.
98 Crow-fly Distance The link distance as calculated by the direct
crow-fly distance between its A and B nodes –
or, in the case of a .GIS file with curved link
data, the sum of the crow-fly distances of
each sub-link. See 15.10.1. (m)
99 Crow-Fly – Coded Distance The difference between the crow-fly distance
above and the distance coded in the network;
i.e., the “error”. (m)
100 % Diff Crow-fly v coded Distance The difference between the crow-fly distance
above and the distance coded in the network
expressed as a % difference relative to the
crow-fly.
101 Chained Stacking Capacity The total of all the stacking capacities of a
series of link which make up a “chain” (see
5.1.2), of which this link is one. DA 388. See
8.5.5.5.
102 FLAREX The length of the flared lane for X-turners at
signals (FLAREX); see 8.2.5.2. DA 468
103 FLAREF The length of the flared lane at traffic signals
(Priority modifier F; see 6.4.2.4) DA 478
104 Chained Links All links which are part of a “chain” (see 5.1.2)
are assigned a value 1; otherwise 0.
I.1.2 Link Flows
23 Demand flow (pcu/hr) See 17.2. Includes all flow components (e.g.
assigned from the trip matrix, bus flows etc.
but excludes all bus flows on bus lanes). For
simulation links with traffic entering/exiting at
either end it is the flow mid-link. DA 4503
24 Actual flow (pcu/hr) Flow (pcus/hr) which actually arrives during
the time period simulated. For simulation links
with traffic entering/exiting at either end it is
the flow mid-link. See 17.2. DA 4513
25 Queued flow (pcu/hr) Difference between demand and actual flows
5109341 / Mar 13 I-2

11_2_05_App I.docx
(#23 - #24) and therefore the flow which is
due to arrive in the next time period. Pcus/hr.
64 Demand Flow Downstream As #23 but the demand flow which arrives at
the downstream stopline after any exit/entry
traffic, e.g., centroid connector flows, bus
routes, etc., has been allowed for. See 15.16.
65 Actual Flow Downstream As #24 but the actual flow which arrives at the
downstream stopline after any exit/entry
traffic, e.g., centroid connector flows, bus
routes, etc., has been allowed for. Aka arrival
flow. See 15.16
20 Pre-load flows (Demand or Actual) flows input under PLOD =
T. See 15.5. DA 2013
21 PASSQ flows (pcu/hr) – A/D Flows “passed” from a previous time slice due
to queues therein. May be optionally set to
either Demand or Actual within the current
time period. DA 2023
22 Fixed flows (pcu/hr) – A/D Total of all fixed flows; e.g., buses, preload,
passq. May be optionally set to either
Demand or Actual within the current time
period. DA 2093
40 UC n Flow (Demand) Refers to user class 1 by default but may be
changed interactively to any user class –
particularly useful if there are more than 3
user classes which are not explicitly included
under #66-71 below – or to all user classes.
41 UC n Flow (Actual) As #40 but actual flows, not demand,
obtained by factoring down the user-class
demand flow by the reduction factor for total
actual to demand flows per link. Strictly
speaking this is an approximation; see
15.21.4.
66 UC 1 Flows – Demand Always refers to flows from user class 1 DA
3803
67 UC 1 Flows - Actual As #67 but factored down to actual flows.
68 UC 2 Flows - Demand Etc. DA 3813
69 UC 2 Flows - Actual Etc.
70 UC 3 Flows - Demand Etc.
71 UC 3 Flows - Actual Etc. (For UC > 3 you need to set the user
class n and the use options 40/41)
42 Entry flows: CCs/bus/etc (Demand or Actual) Flows entering the link
either at the upstream and/or downstream
end due to centroid connectors, bus routes
starting, residual queues under PASSQ, etc.
etc. (pcus/hr) See 5.1.8.
5109341 / Mar 13 I-3

11_2_05_App I.docx
43 Exit flows to CC/bus/etc As #42 but exit flows
50 Demand flow (+ bus lane) As #23 but with bus lane flows included
51 Actual flow (+ bus lane) As #50 but factored down to actual flows.
11 Capacity (pcu/hr) For simulation links capacity is a weighted
sum of turn capacities; for buffer links
(including CCs) it is the (fixed) input capacity;
for simulation CCs it is normally infinite
(99999) except when blocking back is present
on an entry link (8.5.2) DA 1863 / 1643
27 Mid link capacity (pcu/hr) Simulation links only: As defined on the
capacity-restraint speed-flow record. See
6.4.12. DA 393
12 V/C ratio (per cent) (Actual) Volume to Capacity (#11) ratio for the
link as a whole
87 Demand flow, vehicle class n The total (demand) link flow for vehicle class
n (i.e., the sum of all the user class flows in
vehicle class n). By default n = 1 but it may be
changed to any other single vehicle class
number. Pcu/hr
88 Actual flow, vehicle class n As above but factored down to an actual flow.
Pcu/hr
89 Demand flow, vehicle class 1 As 87 above but always for vehicle class 1
90 Actual flow, vehicle class 1 As 88 above but always for vehicle class 1
91 … ditto for class 2 … Demand/actual flows for vehicle classes 2
and 3 (explicitly). To view the flow for vehicle
class 4 it is necessary to use 87 above with
the single vehicle class set to 4.
105 Tij Demand flow The total flow assigned from all cells in the trip
matrix, equal to the total demand flow less the
fixed flow. I.e., the sum of all the individual
user class flows in a MUC model. Pcu/hr.
106 Tij Actual Flow As 105 but the actual flow Pcu/hr
107 Tij + PASSQ Demand flows The flow as assigned from the trip matrix plus
an estimate of the equivalent flows contained
in the PASSQ flows
108 Tij + PASSQ Actual flows As 107 but actual flows. Pcu/hr
34 Counts (pcu/hr) As input under the 77777 data records in the
network .dat file. With multiple count fields a
particular field is user-selected (default to 1).
35 Errors Difference between flows (#24) minus counts
(#34).
36 Relative errors (%) Error / flow per counted link expressed as a
5109341 / Mar 13 I-4

11_2_05_App I.docx
percentage (with + or – signs)
75 Previous Demand Flow Taken from the previous assignment-
simulation loop (pcus/hr). DA 4493
76 Changes in Demand Flow Difference between #75 and #23 and
therefore an indication of convergence of the
assignment-simulation loops
37 GEH convergence GEH statistics comparing the link flows from
the last loop with those from the previous
loop. See 15.6.2.
72 SAVEIT Flows (Demand) Total demand flows as calculated by the
additional “saveit” assignment used to
reproduce route flows. See 15.23.1.
86 Bottleneck Capacity The “pinch-point” capacity (#27) set by a
simulation link speed-flow curve but only if
that capacity is “active”; i.e., only if it less than
the junction capacity which it therefore
restricts. See 6.4.12.
I.1.3 Times, Queues and Speeds
4 Free flow time (secs) Simulation links: Stopline to stopline travel
time under free flow conditions. Buffer links:
free flow travel time. DA 1803
5 Free flow speed (kph) Speed based on free-flow time #4
15 Cruise time (secs) Simulation links: Stopline to stopline time
allowing for speeds to decrease according to
a link capacity-restraint curve (otherwise
equals #4). Buffer links: congested travel
time.
16 Cruise Speed (kph) Speed based on cruise time #15
14 Delays (secs) Simulation links: Flow-weighted delay to
include: (a) transient delays, (b) V>C queuing
delays and (c) any delays associated with link
capacity restraint (speed-flow) curves.
Buffer links: Difference between congested
(speed-flow) and free-flow travel times.
N.B. Both exclude any 44444 time penalties
or extra CLICKS times.
77 Stopline Delays Simulation links: Same as 14 but without
element c), i.e., transient plus V/C delays but
without delays on the link arising from speed-
flow curves
78 Capacity Restraint Delays Simulation links: Delay arising from the link
capacity-restraint or speed-flow curve only.
5109341 / Mar 13 I-5

11_2_05_App I.docx
Buffer links: Difference between congested
and free-flow travel times (same as #14).
17 Total time (+ Qs) secs Simulation links: Sum of delays #14 and free-
flow travel time on simulation links.
Buffer links: congested time
18 Net speed (+ Qs) kph Speed based on total simulation link travel
time #17 DA 4053
95 RTP delay The random delay per turning movement
weighted by flow to give an average per link.
See 8.6. DA 1658
96 V>C delay The delay due to over-capacity queues per
turning movement weighted by flow to give an
average per link. See 8.4.1. DA 1638
97 CFP delay The “transient” delay per turning movement
as associated with cyclical flow profiles
See 8.4.1. DA 1628
9 Average Queue Total (pcu) The sum of the average transient queues and
the average V>C queues as summed over all
turning movements and all lanes. See 8.4.8
DA 1433
13 Q at end of time period Permanent V > C queue (pcus) aggregated
over all lanes and/or turns at the end of the
simulated time period. Excludes any transient
queues.
8 QoverS % The average queue (#9) divided by the link
stacking capacity (6.4.11) and expressed as a
percent. N.B. The link stacking capacity is that
used in assessing blocking back so,
depending on the link properties and the
degree of blocking back, it may be either: (a)
the stacking capacity of the link on its own or
(b) the stacking capacity of its “chain”. See
8.5.5.5.
10 Blocking Back Factor % 100.0*(1.0 – BBF) In other words, if a link is
blocking back (in which case BBF < 1) a
positive value is displayed. If a link is not
blocking back (BBF = 1) a value of 0 is
displayed. See 8.5.1 DA 1443 x 100
73 BBF_IN Block Back Factor as input from the previous
simulation (defined as per #10). DA 1353
74 Changes in Blocking Back Differences between #10 and #73 above;
non-zero values indicate a lack of
convergence
5109341 / Mar 13 I-6

11_2_05_App I.docx
57 Maximum trans Q (pcu) Based on the summation of all transient
queues over all lanes and all turning
movements. See 8.4.8. DA 1373
84 Q-bar (V > C) Average Queue – V > C (pcus) DA 1378
85 Q-bar (V>C) + max trans Q Average V>C Queue + Maximum Transient
Queue: DA 1378 + DA 1373
7 Power x 100 The power n as used in the link cost-flow
curve. See 5.4 and 8.4.2. DA 1823
47 Penalties – Time (secs) Time penalties as defined for links under
44444 data, but excluding any aggregates
turn penalties out of simulation links (for the
currently selected user class). See 6.7.
48 Monetary tolls (pence) Monetary tolls (e.g., in units of pence) levied
per link whether defined under 44444 or via a
KNOBS file (for the currently selected user
class). See 20.3.
56 Penalties - Banned turns A negative value to indicate a banned link (for
the currently selected user class). See 6.7
52 Weaving factors The reduction factor W applied to link
capacities due to weaving between entry and
exit ramps. Expressed as a percentage. See
15.40.2. DA 1563 x 100
55 Signal Co-ordination Ratio of the delay at signals given the normal
“platooned” arrival pattern to the delay if the
arrival pattern were flat. Expressed as a
percent and weighted by turning flow. See ?
79 Max Speed, UC n Maximum Speed, UC n: either the normal
speed at free flow or the maximum set by
CLICKS and/or CLIMAX for UC n.
80 CLICKS: UC n Cruise Time for UC n (seconds) including
the affect – if any – of CLICKS and/or
CLIMAX
81 Add Tim UC n Extra Cruise Time for UC n (seconds); i.e.,
the difference in the travel time between
“cars” and a particular user class due to
CLICKS/CLIMAX
82 Spd Dif UC n Speed Difference between UC n and “cars”
(kph) including the affect – if any – of
CLICKS/CLIMAX. N.B. Actual speeds are
used here, not free-flow speeds.
83 CrSpeed UC n Cruise Speed for UC n (kph) including the
affect – if any – of CLICKS/CLIMAX
5109341 / Mar 13 I-7

11_2_05_App I.docx
104 Sim Convergence: Delays The difference in delay per simulation turn
between the simulation and assignment
(See 9.9.1.2)
105 Sim Convergence: Gap The difference in delay per simulation turn
multiplied by the flow weighted by flow to give
an average per link, (See 9.9.1.2)
106 Sim Convergence: Capacity The difference between turn capacity on
successive simulations weighted by flow to
give an average per link. (See 9.9.1.2)
107 Sim Convergence: Flows The difference between turn capacity on
successive simulations weighted by flow to
give an average per link. (See 9.9.1.2)
I.1.4 Link Bus Flows
19 Bus flows (pcu/hr) – Demand N.B. In units of pcu’s, not buses, per hour.
58 Bus Flows (Actual) As #19 but factored down by ratio of total
actual flows to total demand flows
59 Bus Flows (Queued upstream) Difference between #19 and #58
44 Bus Lane flows – Nearside Demand flows in pcu/hr of buses in a
nearside bus lane
45 Bus flows (not bus lane) Bus which use a “middle” link in preference
(for whatever reason) to an available bus
lane.
46 Bus lane flows – Offside Demand flows in pcu/hr of buses in a offside
bus lane
49 Total Bus lane flows Sum of nearside and offside bus lanes
60 Bus Entry Flow Upstream Bus flows which start upstream on this link
Pcus/hr. DA 953.
61 Bus Entry Flow Downstream Pcus/hr.
62 Bus Exit Flow Upstream Pcus/hr
63 Bus Exit Flow Downstream Pcus/hr DA 963
5109341 / Mar 13 I-8

11_2_05_App I.docx
I.1.5 Link Emissions
26 Fuel consumption (l/hr) See 15.32. DA 1503
28 CO2 (kilos) See 15.33. DA 1713
29 CO (kilos) See 15.33. DA 1703
30 Nox (kilos) See 15.33. DA 1723
31 Hydrocarbons (kilos) See 15.33. DA 1733
32 Lead (kilos) See 15.33. DA 1743
I.2 Turn-based data:

The following data items may be selected by simulation turn in P1X (so clearly this
does not apply at all to buffer networks). See 11.6.6
1 Demand flow (pcu/hr) The demand flow to arrive at the downstream
stop-line.
2 Exit flow (pcu/hr) Flow which actually passes through the
downstream stop-line (e,g., limited by the
turn capacity).
3 Arrive flow (pcu/hr) “Actual” flow which arrives at the stop-line
4 Flow queued upstream (pcu/hr) The difference between #1 and #3.
5 Flow queuing here (pcu/hr) Rate at which a queue builds up at the stop-
line assuming that the arrival flow exceeds
the capacity. #3 - #7
6 Fixed flow (pcu/hr) Total of all fixed flows; e.g., buses, preload,
passq. Demand-based.
7 Capacity (pcu/hr) As calculated by the simulation.
8 Average queue total (pcu) The sum of the average transient queues and
the average V>C queues as summed over all
lanes. See 8.4.8
9 Delay (secs) Includes both: (a) transient delays and (b)
V>C queuing delays (but excludes any link-
based delay arising from link speed-flow
curves). See 8.4.1
10 V/C (percent) Arrive flow #3 divided by capacity #7
11 Queue at start of period Permanent queue at the start of the time
period as left by the previous time period
under PASSQ
5109341 / Mar 13 I-9

11_2_05_App I.docx
12 Queue at end of period Permanent queue at the end of the time
period assuming that flow > capacity
(including the affect of any initial permanent
queue). Excludes any transient queues.
13 Saturation flow (pcu/hr) As input. See 6.4.6.
14 GAP Critical gap in seconds (which, in principle,
may be turn-dependent)
15 Turn Priority Markers Characters X, F, G, etc. See 6.4.2.
16 Counts (pcu/hr) As input under 77777. Count field 1 by
default
17 Errors (Count – Actual) Pcus/hr
18 % Errors (Counts – Actual) / Actual
19 GEH Errors (no sign) 15.6.2
20 GEH Errors (with sign) 15.6.2
21 Signal Coordination Factor Ratio of the delay at signals given the normal
“platooned” arrival pattern to the delay if the
arrival pattern were flat.
22 Bus Flows (Demand) Pcus/hr
23 Bus Lane Flows (Demand) Pcus/hr
24 Bus Flows excl bus lanes Pcus/hr
25 Demand + bus lane flow Pcus/hr
26 Exit + bus lane flow Pcus/hr
27 Arrive + bus lane flow Pcus/hr
28 Average V>C Queue (pcus) DA 1368
29 Maximum Transient Queue DA 1373
30 Av V>C + Max Trans Queue DA 1368 + DA 1373
31 Delay in SATALL The ‘original‘ delay per turn as calculated by
the final simulation in SATALL and therefore
unaffected by any node editing in P1X.
32 CFP Delay The “transient” delay per turning movement
as associated with cyclical flow profiles. See
8.4.1. DA 1628.
33 V>C Delay The delay due to over-capacity queues per
turning movement. See 8.4.1. DA 1638
34 RTP Delay The random delay per turning movement.
See 8.6. DA 1658.
35 Choke Factor The ‘choke factor‘ applied to simulation turns
to account for mid-link capacity restrictions.
5109341 / Mar 13 I-10

11_2_05_App I.docx
See 8.4.4. DA 1668.
36 Simulation convergence : Delay The difference in delay per simulation turn
between the simulation and assignment.
(See 9.9.1.2)
37 Simulation convergence : Gap The difference in delay per simulation turn
multiplied by the flow, (See 9.9.1.2)
38 Simulation convergence : Capac The difference between turn capacity on
successive. (See 9.9.1.2)
39 Simulation convergence : Flows The difference between turn capacity on
successive. (See 9.9.1.2)
I.3 Node-based Data:

The following table lists those data items available under Node Annotation in P1X.
See 11.6.5. The same data may also be included within a SATDB Node Data
Base; see 11.10.5.
1 Node numbers “Numerical Name”, not sequential
2 V/C ratio (percent) The % ratio of the total actual flow arriving at
the stop line (#24 under I.1.2) summed over
each entry link divided by the sum of the
capacities per entry link (#11 under I.1.2).
Hence a very high (and unused) capacity on
one arm may “mask” a heavily overloaded
arm in terms of this measure.
3 Delay time (seconds) Flow-weighted average delay over all turning
movements at a simulation node / over all
entry links at a buffer node
4 Demand flow (pcu/hr) Summed over all entry arms.
5 Arrive flow (pcu/hr) Summed over all entry arms.
6 Capacity (pcu/hr) Summed over all entry arms
7 Actual flow (pcu/hr) Summed over all entry arms.
8 Fixed flow (pcu/hr) Summed over all entry arms
9 Flow from zones (pcu/hr) Summed over all entry arms
10 Flow to zones (pcu/hr) Summed over all entry arms
11 Queue here (pcu)
12 End queue (pcu)
13 Queue upstream (pcu)
14 Mean queue (pcus) Averaged over all entry arms
5109341 / Mar 13 I-11

11_2_05_App I.docx
15 Start queue (pcu) Sum of all the permanent queues at the start
of the time period as left by the previous time
period under PASSQ.
16 Primary Stops See 15.32.
17 Secondary Stops See 15.32
18 NUC As input. See 8.1 and 15.15.2.
19 Cycle time LCY (seconds) As input. See 6.4.3.
20 Offsets (seconds) As input. See 6.4.3
21 GAP (seconds) Minimum acceptable gap for give-ways at
signals and priorities; GAPR at roundabouts.
See 15.22
22 GAPM (seconds) Minimum acceptable gap for merging. See
15.22
23 RB circle time (seconds) See 6.4.1
24 RB capacity (pcu/hr) Capacity of the roundabout circulating
section; see 6.4.7.
25 Convergence (out) Measure of the change in the OUT cyclical
flow profiles from one internal simulation to
the next. See 8.3.2
26 Errors + Warnings Total of all errors and warnings generated at
a simulation node during the network build in
SATNET. See 2.9.
27 Warnings As #26 but warnings only. See 2.9.
28 Serious Warnings As #26 but warnings only. See 2.9.
29 Non-Fatal Errors As #26 but warnings only. See 2.9.
30 NAFF Errors As #26 but warnings only. See 2.9.
31 U-turns at External Sim. nodes See 5.1.4.
32 Sector name The numerical sector name within which a
zone is included. See 5.1.7
33 Convergence (IN) Measure of the change in the IN cyclical flow
profiles from one internal simulation to the
next. See 8.3.3.
34 Junction Type 0 – External; 1 – Priority; 2/5 – Roundabout;
3 – Signals; 4 – Dummy. See 6.4.1.
35 Map Sequential Number Sequential number as used to set up network
plots including all zones, simulation and
buffer nodes
36 Number of arms Number of connected nodes/links per node
(excluding centroid connectors for simulation
nodes)
5109341 / Mar 13 I-12

11_2_05_App I.docx
I.4 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App I.doc
3.2i DA Codes added DVV 16/12/06
3.8 Web release DVV NP IW IW 12/12/08
3.8.21 Web release – Feb09 DVV NP IW IW 16/02/09
3.8.22 Web release – Jun09 DVV NP IW IW 16/06/09
5109341 / Mar 13 I-13

11_2_05_App I.docx
Appendix J - A Guide to DA Codes
J. A Guide to DA Codes
We provide here a list of the “most useful” DA codes used in SATURN UF* files
with an explanation of their contents. “Most useful” means that the codes listed
are those that ordinary users might conceivably wish to access, e.g., through P1X
DA Code choices (11.6.2.1), as opposed to the more esoteric codes that only
programmers need to know about. See 15.21 for an explanation of the role of DA
codes.
The lists are subdivided into data based on simulation links, assignment links and
simulation turns respectively (although, strictly speaking, assignment links include
both simulation links and turns as subsets).
Note that in certain cases data contained in DA codes appears directly in the data
annotation lists in P1X as noted in Appendix I.
J.1 DA Codes based on Simulation Roads

344 LDR Packed link data (E.g., number of lanes,
major/minor, etc. etc.) Further details on request
to DVV.
354 LDR_2 More packed link data
363 Time Simulation link 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.)
N.B. this does not include any contribution from
turning delays, purely cruise time on the link.
374 LFIN0 pointer into array FIN()
383 STACK Link stacking capacity in pcu's
393 PINCH Mid-link capacity in pcus/hr as set by a link
speed-flow curve
463 TAXES TAX pcus clear after green stage. See 8.2.3.
473 RBKS Exit flow reduction factor – rbks. See 8.7.2
514 LALS LALS(N) converts a simulation road N into an
assignment link number
953 BUSFL_UP Bus flows enter/exiting upstream pcus/hr (with 6
different definitions, e.g., flows on bus lanes,
included in one DA code)
963 BUSFL_DOWN Bus flows enter/exiting downstream pcus/hr (6
definitions)
973 BUSFL_ON Bus flows on the link pcus/hr (3 different
definitions in one array)
5109341 / Mar 13 J-1

11_2_05_App J.docx
1353 BBF_IN Previous Blocking Back Factor

1373 QMAX_AA Maximum transient queue per simulation link.
8.4.8.
1378 QVC_AA Average queue (in pcus) due purely to flows in
excess of capacity per simulation link
1383 QFRC Initial (pcu) queue from zonal entry flow
1393 FRCCAP From Zone entry capacity (pcus/hr)
1403 FRCENT From Zone entry flows (summed over both
upstream and downstream entries)
1413 TOCENT Fraction of link exits to zones (summed over both
upstream and downstream exits)
1423 QUEUE Total demand flow at the downstream stopline
(so that flows entering and/or leaving at the
downstream end have been accounted for)
(pcus/hr)
1433 QRD Total average queue per simulation link
1443 BBF Link blocking back factor; see 8.5

1448 STACQ Stacking capacity per simulation link as used in
the actual blocking back calculations. This can
equal to either: (a) the link stack capacity on its
own or (b) the stacking capacity of the chain of
links in series of which this link is a member.
1453 QRFUP Queue reduction factor upstream: ratio of actual
to demand flows
1463 ARRIVALS Actual arrival flows downstream (cf. 1423 which
contains demand flows)
1473 LINK CAP Link stop-line capacity in pcus/hr
1483 QRDP V>C Road queue at end of period
1493 FLOWUP(D) Demand flow at the upstream stopline in pcus/hr
1503 FUEL Liters consumed per link within the time period
CONSUMPTION (LTP) simulated. N.B. an absolute measure, not
a rate.
1513 LINK (Av jcn) Delay 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, i.e.,
they include both transient and over-capacity
queuing.
5109341 / Mar 13 J-2

11_2_05_App J.docx
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 or areas (3) to (6)
for later time periods, plus any delays on
simulation links with speed-flow curves.
1553 FLOWUP(A) Actual flow upstream (pcu/hr)
1563 WOVEN Sat Flow reduction due to weaving
1573 BBF_OFF Flow removed by blocking back pcus/hr
1598 PCGTNRD Percentage Green Time per simulation link. With

(normally) multiple turns it is a flow-weighted
average of the green times per turn.
1633 DEL The turn delay per simulation turn including both
transient and over-capacity queuing effects
(including queues in later time periods).
1673 BBF_EQ Blocking Back Factor for no Queue growth
1703 CO EMISSION Units of kilograms per link
1713 CO2 EMISSION Kilograms per link
1723 NOX EMISSION Kilograms per link
1733 HC EMISSION Kilograms per link
1743 PB EMISSION Kilograms per link
1753 PM10’s EMISSION Kilograms per link
1763 FRCENT_UP Entry flows upstream from zones etc. (pcus/hr)
1773 FRCENT_DN Entry flows downstream from zones etc.
(pcus/hr)
1783 TOCENT_UP Fraction of exit flows upstream
1793 TOCENT_DN Fraction of exit flows downstream
4023 Simulation Link Time Identical to 363.
J.2 DA Codes based on Assignment Links

554 ANODE A-node of an assignment link, internal sequential
number
564 BNODE B-node of an assignment link, ditto
584 LUX Coded link type data
604 LCI Link Capacity Indices (not sequential, actual
“names”)
5109341 / Mar 13 J-3

11_2_05_App J.docx
624 LSEED Seed value for link random nos.

714 LREV List of inbound assignment links
794 LINK_WEAVE Markers for motorway weaves; see 15.40
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
1813 A A coefficient in flow-delay curve. See 5.4 and
8.4.2 for a discussion of its “units”.
1823 N Power n in flow-delay curve. See 5.4.
1833 CAPACITY Capacity of assignment link (pcu/hr)
1843 REV.CAP Reverse of the “dispersion” capacity of an
assignment link as used in cost-flow curves. See
8.9.3.3.
1853 CAP DEL The delay at capacity, i.e. the difference in travel
times between flow=capacity and flow=zero.
This might potentially be used to “parameterize”
the flow-delay equations.
1863 ACT CAP Practical capacity per assignment link as used
for reporting purposes (pcus/hr)
1893 DISTANCE Link distance in metres (zero for all simulation
turns)
2003 BUS FLOW Total bus flows in pcus/hr excluding any flows
on bus-only lanes (see 2033)
2013 PLOD FL Pre-loaded flows in pcus/hr
2023 PASSQ Flows loaded via PASSQ from a previous time
period (Pcus/hr)
2033 BUS-L FL Flows on bus/reserved lanes (pcus/hr)
2093 VOL_FIX Total fixed flow in pcus/hr; i.e., the sum of 2003,
2013 and 2023 but excluding 2033
2303 KNOB1 1st extra KNOBS data set
5109341 / Mar 13 J-4

11_2_05_App J.docx
2313 KNOB2 2nd extra KNOBS data set

2323 KNOB3 3rd extra KNOBS data set
2333 KNOB4 4th extra KNOBS data set
2603 COSTS 1 The “fixed cost” in generalized seconds per
assignment link to include (as appropriate): (a)
distance, (b) tolls, (c) 44444 time penalties, (d)
KNOBS components and (e) extra CLICKS
times. For MUC this refers to user class 1.N.B. It
does not include the fixed travel time component
1803 although, for assignment purposes, 2603
and 1803 may be added together to give a “total”
fixed cost in generalized seconds
2613 COSTS 2 Ditto for user class 2, …
2623 COSTS 3 … etc. etc.
3803 UC-1 FLOWS Demand flows for user class1 (pcus/hr)
3808 UC-1 A-FLOWS Actual flows for user class 1 (pcu/hr)
N.B. 3808 is not, strictly speaking, a DA code
since there is no record in a UF* file with a code
3808. However it is used to represent 3803
(demand flows) factored down to actual flows
and may be accessed in the usual way. Ditto
3818, 3828, etc. etc. See 15.21.4.
3813 UC-2 FLOWS Ditto for user class 2
3823 UC-3 FLOWS Ditto for user class 3
3833 Etc. Etc.
4003 TIME(A) The congested travel times for each assignment
link as calculated at the end of the assignment
process as given by equations (8.5) (or, strictly
speaking, their more complex forms (8.11)). N.B.
If the link in question is a simulation road then
the travel time is the time only on the road itself
and excludes any contribution from delays on
turns out of the stop-line.
5109341 / Mar 13 J-5

11_2_05_App J.docx
4013 TIME(S) 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.
4033 Marginal Cost Marginal cost time or tolls ( in seconds) as given
(Time) Tolls by equation (7.47)
4043 Marginal cost /time For a single user class:
Total marginal cost (seconds) equal to the sum
of: (a) fixed link costs (i.e., 2603) and (b)
marginal time per link; i.e., equation (7.46)
For multiple user classes:
Total marginal time only (on the basis that the
fixed costs are UC-dependent and only one
“version” of 4043 is output)
4053 SPEED Congested link speed (including a weighted
junction delay) in kph
4493 P-FLOWS Demand flows as per 4503 calculated on the
previous assignment-simulation loop: pcus/hr
4503 D-FLOWS Demand flows per assignment link (summed
over all user classes, including fixed flows, etc.,
etc. as appropriate but excluding any flows on
bus-only lanes (see 2033)): pcus/hr
4513 A-FLOWS Actual flows in pcus/hr; see 17.2.
4523 W-FLOWS Weave (demand) flows; see 15.40
J.3 DA Codes based on Simulation Turns

414 SAT-FLOW Simulation turn saturation flow in pcus/hr
424 ITDATA Packed simulation turn data; e.g., lane
allocations
434 INDEXS Pointer to arrays TRED/TGREEN
483 GAP_MOVE Gap values by turn
494 ITDATAX2 Extra packed simulation turn data
504 MOUT0 Pointer to array OUT for a turn
524 LTN Converts a sim. turn to an assignment link
1363 QMAX_TA Maximum transient queue per simulation turn
(PCUs) (aggregated over all lanes)
1368 QVC_TA Average queue (in pcus) due purely to flows in
excess of capacity per simulation turn.
1438 QBAR_TA Total average queue (in pcus) per simulation
5109341 / Mar 13 J-6

11_2_05_App J.docx
turn.
1523 P-STOPS Number of Primary stops per turn
1533 S-STOPS Number of Secondary stops per turn
1583 TP_TURN Time (secs) at which the initial Q clears
1593 TQ_TURN Time (secs) at which V>C Queue clears
1603 TURNF Fraction of (demand) link flow per simulation turn
1613 QIN Turn queue at start of each LCY cycle (pcus)
1623 QST Queued pcus per turn at the start of the time
period (LTP).
1628 DEL_CFP Delay per turn as calculated from the cyclical
flow profiles (CFP) including any random delays
(1658) but excluding any “fixed” delays i.e.,
TDEL or times to circle roundabouts (seconds).
See 8.4.1.
1633 DELAY The total turn delay per simulation turn including
both transient and over-capacity queuing effects
(secs). See 8.4.1.
1638 DEL_VGC Delay per turn due to over-capacity queues
(seconds). See 8.4.1.
1643 CAPACITY Total simulation turn capacity, pcus/hr
1648 PRE_GRAPH Capacity per turn calculated in the previous
assignment-simulation loop (PCUs/hr)
1653 DEL_TR The “transient” delay per simulation turn; i.e.
excluding any delays associated with over-
capacity queuing but including any “fixed” delays
i.e., TDEL or times to circle roundabouts.
(Seconds). See 8.4.1.
1658 DEL_RTP Delay per turn due to random arrival rates
(seconds); see 8.6.1.
1663 CAP_EQ Estimated capacity in the next time period
(pcus/hr)
1668 CHOKE_T Capacity reduction factor per turn due to
restricted mid-link capacities, See 8.4.4.
1693 SIGCOF Signal Co-ordination Factor defined as the ratio
of the delay assuming platooned arrivals to the
delay with a flat arrival profile.
1694 MOVE_BB Blocking back “status” per simulation turn; 0 –
turn does not block back; 1 – blocks back over
shared lanes; 2 – blocks back on its own
5109341 / Mar 13 J-7

11_2_05_App J.docx
J.4 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App J.doc
3 Upgrade to V2 Template IW DVV IW DVV 28/06/06
5109341 / Mar 13 J-8

11_2_05_App J.docx
Appendix K - Guide to SATURN Batch Files
K. Batch Files Included in the SATURN Suite

The SATURN suite of programs comes with a multitude of batch files. Some of
these are front end files that run the basic SATURN programs like SATNET,
SATDB, SATALL, etc. Many of them are analysis files that carry out mundane
tasks very quickly. For example to subtract one matrix from another, rather than
running MX interactively or creating a little ad hoc batch file, it is more efficient to
use MXSUB2.BAT, which has already been set up to do the job.
Below is a list with a brief description of all the batch files that come with
SATURN. They are sorted in topic order. They are located in the XEXES sub-
folder.
To find out what the required input/output files are, type the batch name in a dos
window, and the details will scroll onto the screen. Note that the batch files with a
‘*’ also have an additional version with a ‘EXIT’ suffix (e.g. SATALLEXIT.BAT)
which will automatically close the DOS shell window upon completeness.
Main SATURN modelling

SATALL.BAT* Assigns a fixed matrix to a built network (see section 9)
SATEASY.BAT Assigns a variable matrix to a built network (see
section 7)
SATNET.BAT Builds and checks an ascii SATURN network (see
section 6)
SATSIM.BAT Simulation program (see section 8)
SATURN.BAT* Builds, Assigns and Simulates a SATURN model (see
section 8)
Matrix Estimation Modelling
SATME2.BAT* Matrix Estimation Related Program (see section 13)
SATPIJA.BAT* Matrix Estimation Related Program (see section 13)
SATPIJA_MC.BAT* Multi-Core version of SATPIJA (see section 15.53)
Multiple Time Period Modelling
SATSUMA.BAT Combine time period specific UFS files into one
aggregate UFT file (see section 17.5)
SATTPX.BAT Runs linked time periods automatically (see section
17.4.3)
SATDYSK.BAT Skims minimum origin destination times for a network
with multiple time periods (see section 12.7)
SATC_TP.BAT Produces a multi-period horizontally stacked (block)
minimum cost matrix
5109341 / Mar 13 K-1

11_2_05_App K.docx
Dynamic Time Period Choice Modelling (incremental Logit Time

Choice)
SATKK.BAT Incremental Logit Time Choice Program (see appendix
V)
SATTPKK.BAT One Loop of the Entire Incremental Logit Time Choice
Model (see appendix V)
MXKK.BAT Produces average network and matrix files (see
section 10.20.7)
MapInfo Conversion
MAKEDATA.BAT Dumps network, link and flow list for MapInfo from up
to 3 UFS files (see section 23)
MAKEFLOW.BAT Dumps network, link and flow list for MapInfo from up
to 2 UFS files (see section 23)
MAKELINK.BAT Dumps network link list for MapInfo (see section 23)
Matrix Manipulation
MX.BAT General Matrix Manipulation Program (see section 10)
MXADD2.BAT Adds two matrices together (see section 10.20.4)
MXADD3.BAT Adds three matrices together
MXADD4.BAT Adds four matrices together
MXAGG.BAT Adds one or more levels of a stacked matrix to
produce a square matrix (see 10.20.20)
MXAVER2.BAT Average 2 matrices (see section 10.20.5)
MXBLOCK.BAT Horizontally stack up to X matrices into one matrix;
used by time periods (see section 10.20.10)
MXDOT.BAT Take the “dot product” of two matrices (see section
10.20.19)
MXFACTOR.BAT Factor an entire UFM matrix by a user input number
(see section 10.20.3)
MXI.BAT Run MX interactively, without any pre-defined input
(see section 10.20)
MXM1.BAT or M1.BAT Build a UFM matrix from a standard dat file using MX.
(see section 4.1 and 10.20.1)
MXM2.BAT Statistically compare 2 matrices (see section 10.9.2
and 10.20.2)
MXM5.BAT Matrix Compression Expansion and/or Recoding (see
Appendix W.3)
MXM7.BAT Matrix transposition (See section 10.16 and/or
Appendix W.4)
MXMSA.BAT Use the rule of successive averages to combine
matrices (see section 10.20.6)
5109341 / Mar 13 K-2

11_2_05_App K.docx
MXROH.BAT Use the rule of a half to calculate benefits (see section

10.20.8)
MXSTACK.BAT or Vertically stack up to 8 matrices into one matrix (see
STACK.BAT section 10.20.9)
MXSUB2.BAT Subtract one matrix from another (see section
10.20.13)
MXTOTALS.BAT Output row and column totals by user class
MXTO20.BAT Transform all non-zero cell values to 1
MXTO21.BAT Transform all zero cell values to 1 and all non-zero cell
values to 0.
MXTRANSPOSE.BAT Alternative version of MXM7 to transpose a matrix.
MXWEIGHT.BAT Weighted Average of 2 matrices (see section 10.20.14)
MXV.BAT Run MX in "look only" mode
MXX.BAT General matrix manipulation program with multiple
matrix input (see section 10.20)
STACK10.BAT Stack individual square matrices (up to a maximum of
10) with user defined filenames to a vertically stacked
matrix
UNSTACK.BAT Unstack a vertically stacked matrix into individual
square matrices (see section 10.20.12)
UNSTACK10.BAT Unstack a vertically stacked matrix into individual
square matrices (up to a maximum of 10) with user
defined filenames (see section 10.20.12)
UFMSTACK.BAT Stack a set of matrices using a control file (see section
10.20.17)
UFMUNSTACK.BAT Unstack a set of matrices using a control file (see
section 10.20.18)
EMME2 Matrix Conversion (see section 10.20)
EMME2UFM.BAT Creates a UFM matrix from an EMME/2 ascii matrix
UFM2EMME.BAT Dumps a UFM matrix to an ascii file with EMME/2
Format
TUBA Conversion (see section 10.20)
SATTUBA.BAT Produces time/distance/toll matrices for input to TUBA
(see section 15.41)
SATTUB0.BAT As SATTUBA.BAT but matrices output in SATURN
UFM format (see section 15.41.4.3)
SATTUB2/3.BAT As SATTUBA.BAT but matrices output in TUBA 2/3
format (see section 15.41.4.3)
TBA12UFM.BAT Creates a UFM matrix from an ascii file with TUBA
Format 1
Format 2
5109341 / Mar 13 K-3

11_2_05_App K.docx

Format 3
UFM2TBA1.BAT Dumps a UFM matrix to an ascii file with TUBA Format
1
2
3
Matrix Conversion (see section 10.20)
CSV2UFM.BAT Creates a UFM matrix from a CSV format
LINE2UFM.BAT Create a UFM matrix from an ascii/text file with
individual I,J records
UFM2LINE.BAT Dumps a UFM matrix to an ascii file with one record
per positive I,J element
UFM2SATL.BAT Dumps a UFM matrix to an ascii file with Format 1:
Long Format
UFM2SATS.BAT Dumps a UFM matrix to an ascii file with Format 2:
Short Format
UFM2CSV.BAT Dumps a UFM matrix to an ascii file with CSV Format
5
Matrix Skims
SATCOST.BAT Produces a minimum cost skim matrix (see section
15.27.7)
SATMCOST.BAT Produces a minimum marginal cost matrix.
SATC_AV.BAT Produces a path-averaged cost matrix from a network
by skimming a forest. See 15.27.4.
SATC_MAR.BAT Produces a minimum marginal cost from a network
assigned via system optimal. See 15.27.4.
SKIMDIST.BAT Produces a path-averaged distance matrix from a
network by skimming a forest (see section 15.27.7)
SKIMPEN.BAT Produces a path-averaged 44444 penalties matrix from
a network by skimming a forest (see section 15.27.7)
SKIMTIME.BAT Produces a path-averaged time matrix from a network
by skimming a forest (see section 15.27.7)
SKIMTOLL.BAT Produces a path-averaged toll matrix from a network
by skimming a forest (see section 15.27.7)
SKIM_ALL.BAT Produces separate path-averaged time, distance, toll
and/or time penalty matrices from a network by
skimming a forest (see section 15.27.7)
Network Conversion Programs for COBA and DRACULA
SATCOBA.BAT Produce a COBA input file from one or more UFS files
(see section 15.42)
5109341 / Mar 13 K-4

11_2_05_App K.docx
SATPIG.BAT Generates route flows from SATURN to use in

DRACULA (see section 12.6)
Analysis and Manipulation of Assigned Networks
DACHEX.BAT Compares two UF files element by element (see section
12.4)
DADUMP.BAT Dumps a UF file element by element for later processing
by DALOAD (see section 12.5)
DALOAD.BAT Recreates a UF file element by element from DADUMP
output text file (see section 12.5)
DALOOK.BAT Interactively examines a UF file element by element (see
section 12.3)
DBDUMP.BAT Dump data from UFS network to an ascii/text file based
on DA codes (see section 15.46)
KNOBDUMP.BAT Dump all KNOBS data from a ufs network to an ascii/text
file (see section 15.46)
SATBUF.BAT Convert a simulation network to a buffer network (see
section 15.8.2)
SATCCS.BAT Creates an output text file in 33333 format for simulation
centroid connectors only. See 15.1.6.
SATCH.BAT Cordon a section of a network and/or trip matrix (see
section 12.1)
SATCH_MC.BAT Multi-Core version of SATCH (see section 15.53)
SATSTAT.BAT Extracts network data from a UFS file
SATTRIM.BAT Removes asterisks (as comment cards) from text files
SATUFC.BAT Produces a UFC file from a UFS file with an optional
user-set NITA/NITS (see section 15.23.4)
SATUFO.BAT Produce a .UFO file from a .UFS plus .UFC file
SATUFO_MC.BAT Multi-Core version of SATUFO (see section 15.53)
SATDB.BAT Database Analysis Program (see section 11.10)
SATED.BAT Optimises offsets of traffic signals (see section 11.12)
SATLOOK.BAT* Post Modelling Investigative Program (see section 11.11)
SATMECC.BAT Produce MECC (Marginal Economic Consumer Cost)
estimates per link/turn (see section 15.50)
SATOFF.BAT Optimises offsets of traffic signals (see section 12.2)
SIGOPT.BAT Optimise stage green times and/or offsets of traffic
signals (using routines in P1X) (see section 15.31.6)
Plotting
P1V.BAT Run P1X in "look only" mode
P1X.BAT Interactive plotting and analysis program (see section
11.2)
PMAKE.BAT Interactive network building (see section 18.1)
5109341 / Mar 13 K-5

11_2_05_App K.docx
Miscellaneous
SATWINSYS.BAT Temporary internal operation file produced by SATWIN
5109341 / Mar 13 K-6

11_2_05_App K.docx
K.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App K.doc
1 Final (v3.3 Manual Upload) TL NP IW IW 13/11/06
3.3 Incorporate into v3.3 Release TL NP IW IW 04/01/07
Trim for Release
3.4 SATURN v10.7 Release TL NP IW IW 12/03/07
3.5 Web Release for Jul 07 TL NP IW IW 19/07/07
3.6 SATURN v10.8 Release INJ NP IW IW 25/03/08
3.7 Web Release for Jul 08 TL NP IW IW 07/07/08
3.8 Web release DVV NP IW IW 12/12/08
3.8.21 Web release DVV NP IW IW 16/02/09
3.8.22 Web release DVV NP IW IW 16/06/09
5109341 / Mar 13 K-7

11_2_05_App K.docx
Appendix L - SATURN Error Messages
L. SATURN Error Messages

This section lists the complete set of Warnings, Serious Warnings, Non-Fatal
Errors and Fatal Errors as detected within SATNET. Note that the Semi-Fatal
Errors use the same numbering and descriptions as the Fatal Errors with the
exception that the numbers used are in the range 401 495 to rather than 301 to
395 so that Table L.4 applies to both sets.
Errors which are upgraded to Semi-Fatal (NAFF) under WRIGHT = T are
indicated by a * next to the number. These will then also appear under Semi-Fatal
errors 490, 491 and/or 492.
Table L.1 – Warnings
Code Description
1 Rather high or low speed
2 Turn saturation flow less than the minimum
3 Some but not all turns coded as G – normally they should all be G
4 A marker X has been used for a turn at a simulation junction but there are
apparently no major links to oppose this turn
5 A marker X has been used for a turn at a simulation junction but there are
apparently two or more opposing major arms. this may create problems as only
the opposing flow from the first (clockwise) arm will be modelled.
6 A priority junction has no minor (give-way) arms and some major arms
7 No simulation data has been input after the 11111 record
8 Turn marker X has appeared for two or more turns on the same link
9 A turn is coded as a merge (M) but is the final possible turn; i.e., an offside merge
10 A turn is coded as a banned turn but has been assigned lanes
11 An empty data section encountered
12 More than one give-way turn sharing a single lane at a priority junction. See
Section 6.4.9.
13 See Serious Warning 168.

14 A roundabout turn saturation flow is less than the maximum for a turn from that
entry, since SATURN assumes all turns have equal access from an arm this is
inconsistent and the program will in fact apply the maximum flow to all turns. the
value is therefore changed to the maximum.
15 The maximum turn capacity at the roundabout exceeds the input roundabout
capacity
16 Rather long inter-green time for a stage
17 See Serious Warning 169
18 Bus route using a non-permitted turn from a bus lane
19 The total times defined for stages and inter-greens at a simulation node (signals)
differ from the total cycle time
20 Coded as F, a permanent filter at traffic signals, but also explicitly mentioned in
one or more stages. Since by definition it is 100% green it is not necessary to
code it explicitly.
5109341/ Mar 13 L-1

11_2_05_App L.docx
Code Description
21 A very short red phase
22 A very short red phase (less than 1 time unit in duration)
23 The total upstream saturation entry flows seem to be inconsistent with the
number of lanes at the downstream end.
24 Input link time/speed out of range set by the speed-flow record
25 An input distance of zero is replaced by the crow-fly value
26 No ban/penalty (i.e., non-zero) entries in a 44444 input record
27 The initial columns on stage records should be blank
28 A zone is connected as a centroid connector to a one-way simulation link but the
(external) node appears in the buffer network. See Section 15.11, note 1.
29 You have requested speeds but the distance is zero.
30 The calculated speed is outside the expected range KPHMIN to KPHMAX
31 A buffer link was one-way in the opposite direction in the simulation network
32 Simulation link distances, times and/or speeds differ in reverse directions. Any
difference at all in distances triggers a warning but times must differ by 10% or
greater and/or speeds must differ by greater than 1.5 kph. The critical limits are
also namelist parameters under &PARAM with W32D = 0.0 by default for zero
differences in distances, W32T = 0.10 (i.e., 10%) for relative times and W32KPH
= 1.5 for speeds.
33 Suspicious link distance – the input value differs “significantly” from the crow-fly
value. See Serious Warning 136 for “highly significant” differences. A significant
difference is defined to be either greater than 10 metres or a relative difference of
either more than plus 10% or minus 5% relative to the crow-fly. Note that
differences between coded and crow-fly distances may also be displayed as link
annotation dat within P1X.
34 An off-side filter must be from a one-way entry to a one-way exit.
35 Capacity times (if defined) should equal free flow times for centroid connectors.
36 Infinite capacity assumed on centroid connectors
37 Co-ordinates for a node have occurred more than once; FIFO decides which of
the two is actually used
38 Not all nodes and centroids have been assigned co-ordinates
39 A bus route has the same name as a previous route this will cause problems if
you use SATLOOK etc
40 The initial link in a bus route is from an inner simulation node to an external node.
This causes problems in the simulation so we ignore this link.
41 The final link in a bus route is from an external node to an inner simulation node.
This causes headaches for the simulation so we must ignore this link.
42 A link with a count given is bridged by centroid connectors did you consider this
in working out the counted flow?
43 A turn is coded as a right turn but is not the last. E.g., the turn in question enters
from the south and exits to the east but there is also a one-way entry from the S-
E between the two.
44 A turn has been coded as a merge (M) but is not the first possible turn.
45 The total inter-green time exceeds the total stage time.
46 A centroid connector to an external link has been included twice; the second
5109341/ Mar 13 L-2

11_2_05_App L.docx
Code Description
reference is unnecessary and is ignored.
47 Some assignment nodes cannot be reached from zone 1 – the network may
therefore be disconnected. On the other hand it may be caused by one-way
roads near the edge of the network around which there are no routes within the
coded network. See Section 18.10. See also Non-Fatal Errors 273 and175.
48 No trip matrix factor input – default of 1.0 assumed
49 A buffer link has both nodes in the simulation network
50 The saturation flow per lane is low (<MINLSF)
51 The saturation flow per lane is high (>MAXLSF)
52 An external simulation node with 2 arms
53 Two priority movements share the same exit but neither has a turn priority marker
54 Link capacity index defined twice (and differently)
55 Using an old value of NFT – are you sure?
56 PASSQ is being used but with buffer only networks – ok?
57 Using a T indicator on a default speed-flow record
58 A blank or zero node record in a (bus) route
59 Read error on simulation link time/speed
60 Read error on simulation link distance field
61 The value of a suspicious namelist parameter has been changed. See also
Serious Warning 171 where similar errors are upgraded to a semi-fatal error
under WRIGHT = T
62 Too many (comment) lines to define a single bus route
63 Not enough lines input in a bus route (EZBUS = F)
64 Final timing point not recorded, route stops upstream
65 Low stacking capacity per lane (< 3.0)
66 Link exists but only in the opposite direction
67 Sector 0 has been used both explicitly and by default
68 A priority marker G looks suspiciously like a merge! (M)
69 Elastic demand applied to user classes which share Tij levels
70 A link in the 33333 buffer network data has previously been defined with link
speed-flow data in the 11111 simulation data; please check for inconsistencies.
71 DUTCH = T but no buffer network; never used in simulation networks
72 Dummy nodes with 3 or more arms are not a good idea!
73 Bus routes with u-turns at non-simulation nodes
74 Suspiciously large input KNOBS data entry
75 Suspicious KNOBS data field (e.g., >1 entries or no decimal point)
78 Possibly strange bus turn from a reserved mid-link lane; e.g., a route turns
nearside and crosses other turns
79 An X-turn at signals is only in stages in which it is unopposed – hence it has
nothing to give way to. (N.B. This may fail to detect the situation where there are
5109341/ Mar 13 L-3

11_2_05_App L.docx
Code Description
two opposed (X) right turns in a single stage but which – through the choice of
NOTUK and/or D Priority Modifiers – do not interfere because they do not hook;
see 6.4.2.7.). See also Serious Warning 111 which is more general and includes,
e.g., give-ways at priority junctions.
80 Incorrect data on a KNOBS record; spaces in the entry field
81 Cycle time is very low - < 10 seconds
82 Cycle time is very high - > 999 seconds
83 Using a W(eave) marker on a link but not capacity restraint. This may mean that
the weaving rule reduces the link capacity but without a link speed-flow curve it
will not reduce the link speed. See 15.40.4.5.
84 An inter-green time is redundant – all turns continuously green
85 Column 6 on a bus route must be blank, R or T
86 A $include file has a redundant header record, e.g., 66666 for bus routes, at the
start of the file
87 At least one value of CLICKS(UC) should equal zero
88 CLICKS(UC) should not be set for UC > NOMADS
89 CLICKS() should only be set for multiple user classes, NOMADS > 1.
90 Repeated link A,B records in a KNOBS data file
91 Two turns have the same lanes at signals but do not always appear together in
the same signal phases; hence one turn will potentially block the other. See also
Serious Warning 130 which is the same basic situation but judged to be a bit
more severe.
92 A zone connected under 33333 would be better coded under 22222; this
removes the possibility of U-turns. See Section 16.6.4 and 18.9.1. See also
Serious Warning 174 below.
93 More than one give way turn sharing a single lane at signals see Section 6.4.9.
94 AUTNUC: increase NUC to correct short signalised stage lengths
95 Unidentified node entry within 55555 data records
96 A give-way turn (priority marker G) has both shared and unshared lanes. While
this can occur commonly – and therefore “correctly” - in real life, it does cause
potential convergence problems with the lane choice algorithm so, if you are
otherwise undecided, code separate unshared lanes.
97 Opposing x-turns at signals hook; i.e., interfere. Since such turns can make
convergence more difficult it is worth checking to see if any such occurrences
should be converted to non-hooking. As a general rule in modern networks
hooked turns at signals are very much the exception rather than the rule
(although the defaults in SATURN may still indicate otherwise; see 15.7.1). See
Section 6.4.2.6.
98 The lane structure suggests that a minor turn might be given a clear exit priority
modifier C. See Section 6.4.2.6
5109341/ Mar 13 L-4

11_2_05_App L.docx
Table L.2 – Serious Warnings
Code Description
101 MTFLOW is set to True but there are no counts input
102 The speed or time is zero but the distance is non-zero
103 Due to a lack of convergence in the previous simulation fixed flows do not
balance. Solution: repeat previous SATSIM with increased NITS.
104 Turn coded as a filter (priority marker F) but is neither the first nor last turn
105* A turn is coded as a filter – F – but shares lanes
106 No green movements defined for a stage – either the first node entered is zero or
the number of nodes indicator is zero. (All red phases are coded as part of the
inter-green for the previous phase.)
107 A u-turn has been identified as a green movement but u-turns are not possible at
signals – input ignored
108* No capacity in either direction in a simulation link
109 Some of your in-links may not have been defined in strict clockwise order. A
series of left-hand turns (Ignoring one-way streets) through the following nodes
fails to return to Its starting point as it should, or else requires more than 20 steps
to do so. Please check these node sequences on a map. See Section 6.4.8. N.B.
If your network contains overpasses etc. this may be the explanation, in which
case ignore this error.
110 An input zone's sector exceeds the maximum allowed
111 No opposing turns found for a turn with a priority marker at either a priority or
signalised junction. See also Warning 79 which is specific to X-turns at signals
and which is effectively a sub-set of 111.
112 A zone has one or more centroid connectors connected to external simulation
nodes. Normally a zone is connected to a single external node or to one or more
internal links, but not both.
113 Simulation arms have (apparently) not been input in (counter-)clockwise order
according to the co-ordinates of the A-nodes. N.B. If your network contains
overpasses etc. this may be the explanation, in which case ignore this error.
114 The coded link distance was X in the simulation network and Y in the buffer
network. The simulation distance is therefore re-set to Y
115 The link simulation time was outside the range of travel times set in the buffer
network the simulation time is re-set
116 An external simulation node with more than 2 arms
117* Two priority movements cross at a priority junction but neither has a turn priority
marker
118 The named trip matrix cannot apparently be found
119* The number of columns in the trip matrix does not equal the number of zones in
the network
120* The number of rows in the trip matrix does not equal the number of zones in the
network
121* The level selected by a user class exceeds the number of stacked levels in the
trip matrix
122* A stacked level in the trip matrix is not selected
123* The maximum level selected by a user class exceeds the number of stacked
5109341/ Mar 13 L-5

11_2_05_App L.docx
Code Description
levels in the trip matrix
124 A nearside turn which is all green but not a filter
125 A two-way route has been assigned (directional) timing points
126 Total intergreen stage times equals zero (but it may be that the user has explicitly
coded all intergreen periods when at least one movement overlaps as separate
stages, in which case ignore this message)
127* Equal free-flow and capacity speeds on a default S.F. record but a positive value
of the power
128 A turning movement has zero saturation flow but is coded as green during a
stage
129 Blank record read in – and skipped
130 Two turns have the same lanes at signals but do not always appear together in
the same signal phases; hence one turn will always block the other – bad for
convergence! Change either the lane or signal definitions. See also Warning 91
which is the same basic situation but judged to be a bit less severe.
131 A single lane merges with multiple lanes at a Y. Arguably the other turn should
not be an M but if this is, say, a 1-lane entry ramp onto a motorway then it’s
probably OK.
132 Multiple lanes merge with a single lane at a Y. Arguably this turn should not be an
M but if this is, say, a 1-lane entry ramp onto a multi-lane motorway then it’s
probably OK.
133 Setting KINKY = F with a simulation network included
134 The value of a suspicious NAMELIST parameter has been changed
135 More than one give-way turn sharing the single lane: major arm at a priority
junction; see Section 6.4.9.
136 Suspicious link distance – the input value differs ”highly significantly” from the
crow-fly value. See Warning 33 for a “significant” difference. A highly significant
difference is defined to be either greater than 50 metres or a relative difference of
either more than plus 30% or minus 25%.
137 The turn saturation flows per lane differ widely single arm at a signalised or
priority junction; see Section 6.4.6.3.
138 The maximum saturation flow per lane on one roundabout arm is more than 50%
greater than the minimum saturation flow per lane on another. One would
normally expect similar design standards on all arms at a roundabout.
139* Very strange priority junction X-marker – probably on wrong arm or else a minor
arm has not been defined (with G markers) See Section 6.4.2.2.
140* An X-Turn at signals has another turn "outside" it which is not an X
141* No suitable .OST file found; set IPERT = 0 / WSTART = F
142* An X-Turner shares 2 or more lanes with the turn inside it and therefore would be
forced to “weave” with other turns when turning from an inside lane. See Section
6.4.9.6 and also Serious Warning 162.
143* No suitable .UFO file found; set WSTART = F
144 An input field that is meant to contain real data (ie with a decimal point) only has
an integer; check it is read correctly.
145 Unacceptably high level of read errors from a data file
146 Pre-load flows should appear on both simulation links and turns
5109341/ Mar 13 L-6

11_2_05_App L.docx
Code Description
147 A positive inter-green separates two identical stages
148 The rules for green during inter-green differ in 10.6
149 Repeated link A,B Records in a KNOBS file: different values
150 A nearside merge into a turn not in its inside lane. E.g., if turn A-B-C is an entry
ramp onto a motorway and turn D-B-C is the through movement on the motorway
then D-B-C does not use the inside lane. This almost certainly implies that there
is a turn D-B-A (i.e., an exit off the motorway onto the ramp) which does use the
inside lane.
151 An offside merge into a turn not in its outside lane. As 150 but on the opposite
side,
152 A single-lane arm at signals which includes an X-marked turn; see Section 6.4.
153 Increase NUC to deal with shortest signal stage lengths with X-turns
154 An X-turn shares identical lanes with the turn inside it but that turn could use
lanes further inside to avoid being blocked by the X-turn. E.g., a straight ahead
movement and an X-turn are both allocated to lane 2 only so it might be possible
to avoid the potential conflict by allowing the straight movement to use lane 1 as
well. N.B. If the X-turn has a flare the warning is ignored.
155 A merge turn has more lanes than the turn it merges into
156 The exit link from a merge has Equal/More lanes than the sum of the two merging
turns
157 Mid-link capacity either >> or << stop-line saturation flows; the critical ratios are
either 3 times or 1/3. See 6.4.12.1 and 8.4.4.
158* A turn is not coded as an X-Turn but maybe it should be since it hooks with turns
which are green in the same stages
159 CLICKS speed on a link is less than the normal capacity speed
160 The exit link from a merge has significantly fewer lanes than the sum of the two
merging turns
161 An X-turn at a priority junction has no major turns opposing it
162 Multiple turns sharing multiple lanes – so that, e.g., an offside turn from an inside
lane would inevitably have to cross an inside turn from an offside lane – disaster!
See also Serious Warning 142 and Section 6.4.9.6.
163 There are no time or speed entries on a 33333 buffer link but either the distance
and/or the capacity has been coded so it is not possible to use a default speed-
flow curve as might be expected by the absence of speed/time.
164 A buffer link has zero capacity (implying fixed speeds) but the free flow and
capacity times input differ
165* An X-turn at signals has both exclusive and shared lanes. See 6.4.9.4.
166* Two opposing X-turns at signals have different priority modifiers; e.g., one turn is
coded XD and the opposite is X-blank. Logically both should be XD or neither
have D.
167 The directionality of a buffer centroid connector and the link(s) to which it is
connected are different (e.g., 1-way out versus 2-way in)
168 A turn has been banned but other turns at the roundabout use the exit. E.g., the
turn from south to north has been banned but the turn from west to north is
allowed.
169* Incorrect signal stage specification: the number of nodes in the list must be even
5109341/ Mar 13 L-7

11_2_05_App L.docx
Code Description
170 An input time/speed of 0.0 on a simulation link is replaced by the minimum time /
maximum speed from the speed-flow curve.
171* A highly suspicious /illegal value of an input Namelist parameter; this is upgraded
to a semi-fatal error under WRIGHT = T. See also Warning 61.
172 A negative trip matrix cell has been detected in either SATNET or SATALL and
will not be assigned. See note 6) in Section 4.3.
173 Using OBA without having FTN95_NEW_MEMORY turned on.
174 Positive flow making a U-turn at an external simulation node. See also Warning
92 which simply flags the possibility of a U-turn. See Section 16.6.3 and 18.9.1.
175 The coded flare length (either F or X) exceeds either the link length or 100 metres
176* The number of stage green node pairs exceeds the actual number of entries
177* Extra stage green node entries which will not be read
178 Very strange stage sequencing for an X-turn at signals. E.g., an opposing turn
continues at the end of the X-turn phase so that the (TAX) vehicles queued in the
centre of the junction cannot clear.
179 An offside filter FX shares 2 or more lanes with the turn inside it; see 6.4.9.6.
180 A nearside filter FF shares 2 or more lanes with the turn outside it; see 6.4.9.6.
181 A TfL node is entirely surrounded by nodes in different traffic boroughs. See
5.1.7.
182 A TfL zone is only connected to simulation nodes outside its traffic borough. See
5.1.7.
183 A simulation node has a LCY value of, say, 60 but all its neighbours have LCY =
70. See 15.15.3.
Table L.3 – Non-Fatal Errors
Code Description
201* Turn priority modifiers only allowed with markers X or G
202 No input is required in fields 4 and/or 5 for junctions other than signals and
roundabouts
203 Turn A is crossed by turn B and both are green during stage N e.g. one is north-
south and the other is east-west, and neither has a priority marker, e.g., X
204* Nodes in the assignment network have no entries to them which may indicate
that the network is disconnected in some way. N.B. This only applies to “real
nodes”, not zones, since it is quite permissible to have zones on the network
boundary which are exit only and therefore have no entries.
205 Two centroids may not be directly linked together in the buffer network.
206 Capacity travel times must exceed the free-flow times
207 A positive power-law flow-delay curve when the time at capacity equals the free-
flow time (or has been set equal to zero or left blank to imply equality
208 Negative co-ordinates - X and Y must be => 0
209 Duplicate count number
210 Zero flow defined for a count
211 No positive saturation flows coded for turns out of a dummy node
5109341/ Mar 13 L-8

11_2_05_App L.docx
Code Description
212* No in-bound arms defined for a simulation node
213 Both free flow and capacity speeds, the capacity and the link index must all be
positive
214 The capacity speed must be less than the free flow speed
215 Duplicate capacity index in a (default) speed-flow data record
216 No suitable node co-ordinates identified - SHANDY option off
217* Numerical data beyond column 65 on a simulation CC record under 22222 which
may be intended to define another link. N.B. If there is non-numerical data, i.e.,
text, beyond column 65 it is assumed that it is some form of comment and is
therefore acceptable.
218* Repeated restricted link/turn data under 44444
219 A C (or E) priority modifier cannot refer to the first turn
220 A D (or E) priority modifier cannot be used for the first or second turn
221 No centroids defined
222 A bus route "stutters"; i.e., it goes twice through links A-B-A-B
223* User class out of range 1 to NOMADS
224* Matrix level out of range 1 to 36
225* Lanes on a give-way turn entirely enclose a non give-way turn
226* Two or more turns have lanes which are shared but do not appear in the same
signal phases; hence one turn will always block the other - catastrophe! Change
either the lane or signal definitions. See also Serious Warning 130 and Warning
91.
227* Zero length green stage
228 Fortran read error within 55555 data records (ie co-ordinates)
229 Invalid value for TAX in the XFILE
230 Invalid entry for link (A,B) in the XFILE 22222 records
231 Invalid value for RBKS in the XFILE
232 Invalid value for GAP in the XFILE
233 Invalid entry for turn (A,B,C) in the XFILE 33333 records
234* An X-Turn is green in every stage and therefore has no opportunity to clear at the
end of a green phase under TAX (which means that there is a possibility of zero
capacity)
235 Too many different capacity indices used
236* No turns allocated to a lane
237 Unidentified node in a (bus) route
238 * In column 11 (= capacity restraint) on an outbound-only link
239* Error in processing lanes input field
240* Error in processing an entry on a simulation node record in one or more data
fields due to a Fortran read error
241 Not currently in use. (The previous incarnation - too many lines to define a single
bus route; the maximum permitted is 78 – is now Semi Fatal 330.)
242 Error in defining a weaving segment on a simulation link; e.g., the entry link
cannot be matched to an exit link
5109341/ Mar 13 L-9

11_2_05_App L.docx
Code Description
243 Error in defining a weaving segment on a simulation link; not used yet
246 Weaving (W) sequence not terminated by an entry link
247 Entry weave (W) link not matched to an exit link sequence
248 Middle weave (W) link not matched to an exit link sequence
249 Failure to identify a link/turn in the KNOBS data file
250 Fortran read error in the KNOBS data file
251 Possibly strange bus turn from a reserved nearside lane; e.g., a route turns
offside and crosses other turns
252* Turn coded as a merge (M) but is crossed by another turn
253 Number of possible u-turns at external simulation nodes exceeds number allowed
for checking in SATALL
254 FILKNB defined but KNOBS = 0
255 FILKNB as defined cannot be opened
256 Minimum stage green time exceeds the input green time
257 Maximum stage green time less than the input green time
258 An external simulation link has zero distance but +ve speed
259 More than 1 data inputs where there should be one; 1 2 not 12
260 Defining a GAP Value in an XFILE for a roundabout turn
261 Suspicious simulation link capacity restraint record - blanks not found where they
are expected (columns 1-10 and 26-35)
262 No zones have been created (so no assignment possible)
263 * Using WSTART = T without defining a trip matrix via FILTIJ
264 * Duplicate links on a single 22222 zonal centroid connector record
265 * Assigning monetary tolls to a user class where PPM = 0
266 Read error on a default S-F curve (D) record under 33333
267 Blank Capacity Index field on a default S-F D-record under 33333
268 Duplicate count: different 7777 sets but different values
269 Unidentifiable node, link or turn: link counts under 77777. See also Fatal Error
337 / Semi-Fatal 437 which may be downgraded to 269 by setting ERRYES(437)
= F. See Note 12) under 6.10.
270 Cannot set the power N from coba-10 speed-flow data
271* WSTART = T requires a .UFO File from the Update network
272 Data In the wrong columns on a node data record
A simulation link has downstream exits but no upstream entries. In other words a
link A-B exists at node B but at A there are no turning movements into A-B; e.g.,
273*
a turn has been left out at A. The same problem can occur if a 1-way simulation
link becomes 2-way at a 2-arm only junction.
Negative KNOBS weighting value used in 88888 Data; if you wish to introduce
274 negative cost components on links you must set negative link properties within
the KNOBS file with a positive 8888 weight.
5109341/ Mar 13 L-10

11_2_05_App L.docx
Code Description
275* A buffer link has no entries apart from its own U-turn
A count field under 77777 has no data entries; possible corrections are to reduce
276
MCCS or to set FREE77 = T for free format entry
A disconnected O-D pair has positive trips in the trip matrix and therefore cannot
be assigned to a path from its origin to its destination. All user classes are
checked individually and potential paths take account of, e.g., banned turns. Note
that if the trip matrix is not specified as an input to SATNET then this particular
277* test is not carried out. Disconnected O-D pairs are also reported in SATALL but
not as semi-fatal errors. Note that destination zones that cannot be reached from
a particular origin are indicated by a large X in the “build a tree to all zones”
option in P1X (see 11.8.3) and that this is a very handy tool for positively
identifying disconnected O-D pairs.
The map network is disconnected; certain nodes cannot be reached from others
278*
and exist as a sort of “island”
The specified Update or Warm Start network (FILUP) cannot be found by
SATNET. Normally this will be a semi-fatal error but, if the file is designed to be
used as part of a supply-demand loop in which case the trip matrix is being
279
iteratively updated and the network on loop n is updated from loop n-1, then it
may well be that no update network yet exists on loop 1. In which case setting a
parameter DIADEM = T changes the NAFF to a NFE.
The PASSQ network has got a different topology from the network being built in
SATNET. This does not prevent flows being passed from one network to the
other since if a link (A,B) exists in the pre-network and has flows queued
upstream then the missing trips will be correctly transferred to link (A,B) in the
280 main network whether or not they have exactly the same link number. It is
possible that, say, a tidal flow system introduced in a later time period may affect
the link structure but a far more likely reason is that the user has input the wrong
filename under FILPQ. Or that the main network has been edited but not the pre-
network.
Column 11 on a simulation link record should be either a blank (normal) or a * to
indicate a second capacity-restraint record to follow. Anything else generates an
281
error, the most likely cause of which is the a-node number in columns 5-10 being
misplaced so it overspills into column 11.
282 Column 11 of a link simulation record must be 0 or blank.
283 Flare markers F or X may not be used on external simulation links
284 Flare markers F or X may not (yet) be used on roundabouts
285 The &OPTION Namelist marker is repeated in the .dat file.
286 The &PARAM Namelist marker is repeated in the .dat file.
287 SPIDER = T is ignored due to previous fatal errors
288 Buffer turns cannot be banned/penalised unless SPIDER = T
5109341/ Mar 13 L-11

11_2_05_App L.docx
Table L.4 – Fatal (and Semi-Fatal) Errors
Code Description
301 Invalid simulation node number le zero; probably a link record is being read out of
synch
302 The offset exceeds the cycle time or the number of stages must be le 20
303 Junction type out of range
304 The number of legs out of range at a simulation node
305 Node/link/turn cannot be identified
306 The speed or time is non-zero but the distance is zero
307 An A-node has appeared twice at a simulation node
308 Positive turn saturation flow from a link with 0 lanes
309 Incorrect priority marker – cannot be identified
310 Priority marker X has appeared at the same time as G on the same link
311 Priority marker not allowed for a certain junction type
312 Incorrect allocation of lanes for a turn
313 A turn has been coded as a merge (M) but there appears to be no allowed
turning movement to merge with.
314 A turn has not been assigned the obvious lane for its priority code
315 Turn coded as a merge (M) but is crossed by another turn
316 The number of nodes listed as green for a stage exceeds the maximum number
of turning movements
317 A node cannot be identified within a stage definition record
318 An A-node has not been defined as a node itself.
319 A turn has a positive saturation flow but has not been coded as green in the 1
phase coded.
320 A turn is all red but has been assigned a non-zero saturation flow.
321 Something appears twice in the input simulation network data. Note such
problems may be removed by the (correct!) use of the TOPUP option; see 6.15.2.
322 A simulation link joins two external simulation nodes; it must be defined within the
buffer network
323 A simulation link A-B defined at B has not been defined in reverse at node A
324 A turn has a positive saturation flow but its exit link does not exist (i.e., it is one-
way in the other direction. Easily corrected by setting the turn saturation flow to
zero.
325 No connections given for a zone
326 A centroid is connected to a link which cannot be identified or has zero capacity
327 Each assignment node must have an exit – i.e. there must be no points in the
network that traffic can reach but then have no possible exits (see Section 18.10
of the SATURN manual.) N.B. Error 324 will give rise to this error as well but it is
not the only possible source of the problem.
328 Incorrectly formatted 333 buffer input record. For example, the data may have
been formatted using DUTCH = F conventions (5 column blocks) but DUTCH =
T, or vice-versa.
329 Exceeding the size condition on the number of assignment links
5109341/ Mar 13 L-12

11_2_05_App L.docx
Code Description
330 Too many lines to define a single bus route; the maximum permitted is 78
331 Unidentifiable turn in a bus route
332 Zone has been defined twice
333 Unidentifiable node, link or turn: banned turns
334 The number of banned turns is too large
335 The number of nodes used to define the bus route must be >3 and <512
336 No possible path between 2 nodes in a bus route
337 Unidentifiable node, link or turn: link counts in the 77777 data segment. N.B. This
fatal error may be downgraded to a Non-Fatal error 269 if ERRYES(437) = F.
See Note 12) under 6.10.
338 Total green stage times equals zero
339 The number of lanes > 7
340 No turns allocated to a lane
341 Total of inter-greens exceeds the cycle time
342 An off-side filter must be from a one-way entry to a one-way exit
343 Incorrect link capacity restraint record: zero or negative speed, time or capacity
344 No in-bound arms defined
345 Incorrect link capacity restraint record: capacity time < free flow time (or speed >)
346 Duplicate assignment links
347 NUC value found less than NUCMIN
348 Incorrect use of a Q priority marker
349 Incorrectly paired W-marker (non-existent turn) or a Weave marker is being used
with an assignment method (e.g., OBA) which does not support weaves.
Logically the second error should have a distinct error code but at the present
time spare numbers are limited.
350 Incorrectly paired W-marker (other turn not W)
351 Incorrectly coded W-marker – must use either the inside or the outside lane
352 Multiple user classes (NOMADS > 1) but no 88888 records
353 Missing network title/history file too long
354 Same node appears twice in succession in a bus route
355 The number of default speed-flow curves is too large
356 Stack input could be confused with the 99999 records
357 Neither 11111 or 33333 data records found
358 Read error on simulation link time/speed
359 Read error on simulation link distance field
360 Incorrect value of number of signal green node entries
361 Incorrect simulation node record
362 Unidentified simulation A-node and AUTOX = F
363 Blank, zero or negative zone name in 22222 records
364 Repeated Namelist variable name in &OPTION or &PARAM
365 Unidentified capacity index on a simulation link record
5109341/ Mar 13 L-13

11_2_05_App L.docx
Code Description
366 Syntax error in reading > or < entries in a stage green
367 Fortran read error in the KNOBS 33333 extra data line
368 Fortran read error in the stage green nodes
369 Nonsensical data on a simulation link capacity restraint record
370 Failure to open an input UPDATE file
371 Failure to open an input PASSQ file
372 A user class has not been defined within the 88888 records
373 A user class has been defined more than once within the 88888 records
374 Failure to define a CDF file when KOB = 3
375 Failure to open the pre-set CDF file (under KOB = 3)
376 Read failure from a CDF file (under KOB = 3)
377 Unacceptably high level of read errors from a data file
378 Incompatible zone names in the network and trip matrix
379 Time to circle roundabout exceeds/equals the cycle time
380 Using ATLAS = T defines extra zones which do not appear in the assignment
network: assignment is not recommended
381 Failure to open the defined XFILE
382 A near-side (first) turn has been coded as an X at signals
383 Totally incompatible NAMELIST parameters
384 A real number (with decimals) input in an integer-only field
385 KDF() for one U.C. references a non-existent CDF function
386 An &OPTION parameter appears within &PARAM
387 Both a 7777 data section and an external .MCC file are set
388 Negative weighting value (PPM or PPK) used in 88888 data
389 Read errors in all/most default S-F (D) records Under 33333
390 Warning upgraded to a semi-fatal error (WRIGHT = T). (Strictly speaking this
error only occurs as a Semi-Fatal error 490.)
391 Serious warning upgraded to a semi-fatal error (WRIGHT = T) (Strictly speaking
this error only occurs as a Semi-Fatal error 491.)
392 Non-fatal error upgraded to a semi-fatal error (WRIGHT = T) (Strictly speaking
this error only occurs as a Semi-Fatal error 492.)
393 Setting KLUNK > 0 with no indices/user or vehicles classes
394 Cannot open the defined KNOBS File (FILKNB)
395 Negative total fixed link costs; e.g., from setting negative tolls?
396 A filter at signals shares multiple lanes; it should have an exclusive lane
397 An external simulation node has been coded with no zone or buffer outlet
5109341/ Mar 13 L-14

11_2_05_App L.docx
L.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App L.doc
3.6 SATURN v10.8 Release – DVV NP IW IW 25/03/08

New Section
10.9.12 SATURN v10.9 Release DW DG IW IW 22/10/09
10.9.22 Web release – Dec 10 DW AG IW IW 06/12/10
5109341/ Mar 13 L-15

11_2_05_App L.docx
Appendix M - Modelling of Motorway Merges
M. Modelling of Motorway Merges

M.1 Introduction
In SATURN, motorway merges have historically been difficult to represent
satisfactorily in congested conditions. The available method of coding has been
to apply what Saturn calls a turn priority marker M to the merge link. This informs
the program that traffic on that link has to give way to mainline traffic in a
predetermined way. It is similar to a give way junction, but takes account of the
fact that merging traffic does not necessarily come to a halt, and only gives way to
one direction of traffic. It therefore has more capacity than a standard give way
junction.
This method usually works where conditions are reasonably free flowing.
However, it works less well in congested conditions, and can result in huge and
unrealistic delays to merging traffic. It also assigns all junction delay onto the
merge and none on the main line, which is not a true reflection of how merges are
observed to operate. In reality, delay at a merge junction affects both the merge
and the mainline traffic although not necessarily equally.
Since Version 9.2, SATURN has offered an alternative way of coding merges
called the Q marker, which came about as a result of a recommendation in COBA.
This marker is coded downstream of the merge junction, and assigns a calculated
delay to every vehicle which goes through it, causing delay at the merge junction.
With this method, delays are at both merge and mainline traffic streams, as in
observed cases. However, as discussed later, there are some problems with this
method, as the delay can be overestimated under congested conditions.
Because the above methods given in the manual do not work well under
congested conditions, many users have devised their own ad hoc ways of coding
merges which try to reduce merge delays. The result is that between different
organizations, and sometimes even within the same organization, motorway
merges are being coded differently for different schemes.
M.2 Current Status

Withdrawn for review in December 2010 - please contact Atkins for the latest
advice.
5109341 / Mar 13 M-1

11_2_05_App M.docx
Appendix M - Modelling of Motorway Merges
M.3 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App M.doc
3.6 SATURN v10.8 Release – TL NP IW IW 09/02/08

New Appendix for Motorway
Merges
10.9.22 Withdrawn for Review
5109341 / Mar 13 M-2

11_2_05_App M.docx
Appendix N - Unused
N. Unused
N.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App N.doc
5109341 / Mar 13 N-1

11_2_05_App N.docx
Appendix O - Unused
O. Unused
O.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App O.doc
5109341 / Mar 13 O-1

11_2_05_App O.docx
Appendix N-O-P - Unused
P. Unused
P.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App P.doc
5109341 / Mar 13 P-1

11_2_05_App P.docx
Appendix Q – Using Q Markers for Motorway Merges
Q. Using Q Markers for Motorway Merges

A special turn priority marker Q has been introduced in SATURN 9.2 in order to
model the merge delay formula from COBA 10 for traffic entering a motorway from
a slip road:
Equation Q-1
=d 226 (V C − 0.75 )
where d = delay (in seconds)

V = total volume of traffic both “on” the motorway upstream and
joining from the slip road
C = motorway capacity “downstream”
For V > C the delay is “capped” at its maximum value for V = C, i.e., 226/4 = 56.5
seconds.
A Q marker may only be used in very particular circumstances as illustrated
below:
A-B-C-D represents a motorway with an entry slip road S-B. C is an “artificial”

node introduced between junctions B and D located, in general, at the end of the
extra merge lane(s). C is coded as a priority junction and turn B-C-D has a priority
marker Q in the “normal” link data record column. (see 6.4.1; hence column 31
since there can only be a single turn at a Q-junction). Delays at C are calculated
according to (Q.1) since the flow on both B-C and B-C-D must equal the total flow
V defined above. The capacity C is set by the turn saturation flow (but see note
10) below). The formula holds for all values of V, including V > C; any additional
queuing delay is included on the link - see next.
Link B-C may either be coded with a fixed cruise time or as a capacity-restrained
link with a speed-flow curve. In either case if the flow on B-C (and hence on B-C-
D) exceeds capacity C the queuing delay - T/2 (V/C - 1) - is added on to the link
“cruise time” (as opposed to normal capacity restrained links where any over-
capacity delay is associated with its exit turns).
Thus the total travel time from B to (downstream of) C is made up of:
(i) a (flow-dependent) cruise time on B-C;
(ii) over-capacity queuing delay on B-C;
5109341 / Mar 13 Q-1

11_2_05_App Q.docx
(iii) merge delay on B-C-D as given by (Q.1).

The following restrictions and/or caveats should be noted:
1) C must be a priority junction with two arms, one in and one out, and hence
only 1 turn.
2) Link capacity on B-C (if used) must equal the turn saturation flow on B-C-D.
3) If link C-D blocks back it will reduce the link capacity on B-C and hence the
point at which queue delays occur but has no influence on the merge delays
on B-C-D.
4) Calculations of, e.g., fuel consumption or pollutant emissions which
differentiate between cruise and idling time may therefore give “incorrect”
results since the queuing time “appears” on the link.
5) The merge delays do not contribute to queues on B-C which only occur
when V > C.
6) Logic checks on coding are not exhaustive - soyez prudent!
7) Distances are coded normally; in principle in terms of total travel time it
should not matter where C is located, although since the “speed” on B-C
includes delay (Q.1) if B-C is very short it may appear to have a very low
speed.
8) Other link attributes and properties such as queue lengths and blocking
back, etc. should behave themselves but this is a very new option so
WATCH IT! Suggestions for improvements or alternative ways of
representing the effect would be much appreciated.
9) Post release 10.9 the numerical “constants” 226 and 0.75 in equation (Q-1)
may be defined as &PARAM parameters QDMAX and QVCMIN in network
.dat files.
10) If the link segment B-C-D has been coded with motorway weaving markers
W (See 15.40) then the saturation flow / capacity used in equation (Q-1) is
reduced by the weaving factor W (e.g., equation 15.9), thus producing an
additional increase in the delay due to weaving. See also 15.40.4.5.
5109341 / Mar 13 Q-2

11_2_05_App Q.docx
Q.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App Q.doc
2 Clarification of max delay DVV 29/05/06
5109341 / Mar 13 Q-3

11_2_05_App Q.docx
Appendix - R – WebTAG-based Variable Demand Modelling using SATURN
R. WebTAG-based Variable Demand Modelling

using SATURN
R.1 Background
This appendix contains a copy of the paper presented at the 2009 European
Transport Conference describing the background to the development of the
SATURN CASSINI program and the use of distributed computing to significantly
reduce the CPU requirements for Variable Demand Models using SATURN. The
Appendix provides further details to those originally provided in Section 15.52,
15.53 and 15.54.
5109341 / Mar 13 R-1

11_2_05_App R.docx
A NOVEL DESIGN AND IMPLEMENTATION OF AN AGGREGATE UK-BASED
TRANSPORT MODEL
Yanling Xiang, Ian Wright and Tony Meehan, Atkins Limited
1. INTRODUCTION
This paper presents a flexible, aggregate transport modelling framework with state-
of-the-art model design and implementation that takes advantage of recent
advances in computer power to provide robust demand forecasts within a
reasonable timeframe.
The Great Bristol Modelling Framework (GBMF) has been developed as a six-
stage, fully WebTAG-compliant (DfT, 2004 onwards) aggregate transport model
system to assess a range of potential transport interventions in the West of
England. The GBMF system has been successfully applied to assess a range of
transport interventions (including demand management) and has supported a
number of a Major Scheme Bid (MSB) submissions seeking UK Central
Government funding.
Within the UK, the majority of the transport modelling undertaken for large urban
areas continues to use aggregate models, reflecting the extensive experience in
developing and applying them coupled with the typically smaller data requirements.
Data collection in the UK for transport appraisal typically involves roadside
interview data (RSI), onboard public transport surveys, manual / automatic count
data, and journey time data etc rather than much larger, and more expensive,
household interview data and revealed / stated preference data required to support
disaggregate choice models.
To support the practitioner in developing MSB submissions, the UK Department for

Transport (DfT) provides their WebTAG guidance on the building of stage-based
transport models including the option to use imported sensitivity parameters
(referred to as ‘illustrative’ parameters in WebTAG) rather than estimated
parameters derived from more local data sources. The suitability of the model for
scheme appraisal is demonstrated through a series of realism tests to ensure that
the model realistically represents locally observed behavioural characteristics.
The GBMF modelling system was developed using INRO’s EMME multi-modal and
SATURN (Van Vliet et al, 1980) highway assignment software suites and includes
a number of innovative features such as:
• One of the first fully WebTAG-compliant demand models in the UK;
• A six-stage model representing a 24-hour travel demand in

Production/Attraction (P/A) format using an incremental, logit-based pivot-
point form to achieve equilibrium in forecasting mode;
• Fully multi-modal functionality with detailed representation of travel demand

by purpose, mode, car availability and income group (within both the supply
and demand-side sub-models ) to asses demand management schemes;
1
• A new P/A-based time of day choice implementation, derived specifically for
this study, that enables time period choice to be undertaken after main mode
choice but before destination choice;
• The adoption of cost-dampening and the introduction of further segmentation

by distance-based value of time to achieve the required outturn elasticities for
longer-distance trips; and
• Recent developments in SATURN including both optimising the model for

running on quad-core desktop computers and the use of SATURN-CASSINI
software that enables the convergence targets in the supply-side model to be
dynamically linked to those obtained within the demand model.
This rest of the paper is structured as follows: Section 2 presents an overview of

the GBMF system whilst Section 3 describes the technical innovations developed
for GBMF including the use of High Performance Computing (HPC) and SATURN-
CASSINI to significantly reduce overall model runtimes along with a new PA-based
time-of-day choice formulation. Section 4 presents a comparison of the calibrated
model parameters and resulting outturn elasticities, before-and-after the use of a
cost-dampening mechanism, which is applied through the introduction of Value of
Time (VOT) variation with distance. A summary of the model development is
provided in Section 5.
2. GBMF MODELLING SYSTEM
FULLY WEBTAG-COMPLIANT CHOICE STRUCTURE
The GBMF is an aggregate transport modelling framework consisting of six stages

to represent average weekday traffic conditions. It consists of five EMME-based
demand modelling stages plus a separate supply-side route choice assignment
stage for highway (SATURN) and Public Transport (EMME), as detailed in Table 1.
Table 1 - GBMF Demand Model Stages
Stage Model Temporal Scope Form Person Type

1 Frequency Modelling 24-hour P/A Trip-ends All (CA & NCA)
2 Main Mode Choice 24-hour P/A Trip-ends CA
Translate 24-hour to AM
3 Time Period Choice (3hr), IP (6hr), PM (3hr) P/A Trip-ends All (CA & NCA)
and OP (12hr) periods
Translate P/A
3hr (AM), 6hr (IP), PM
4 Destination Choice Trip-ends to All (CA & NCA)
(3hr) and OP (12hr)
P/A matrices
3hr (AM), 6hr (IP), PM
5 Sub Mode Choice P/A matrices All (CA & NCA)
(3hr) and OP (12hr)
6 Assignment 1-hour (AM, IP, PM) O/D matrices All (CA & NCA)
Note: CA and NCA refer to person types with or without car available respectively whilst AM (07:00-
10:00), IP (10:00-16:00), PM (16:00-19:00) and OP (19:00-07:00) represents the time period
specification in a 24-hour weekday time frame. The conversion from P/A to O/D form is described
in more detail in Section 3.
2
The GBMF demand model is an incremental logit-based model following the
WebTAG guidance. Figure 1 shows the demand model hierarchical structure with
the frequency modelling placed at the top and the sub mode choice for both cars
and PT placed at the bottom.
Figure 1 - GBMF Demand Model Structure
EMME Demand 1. Trip Frequency

Model
2. Main Mode Choice
Car / Park & Ride Public Transport
3. Time Period Choice 3. Time Period Choice
4. Destination Choice 4. Destination Choice
5. Sub-Mode Choice 5. Sub-Mode Choice
SATURN Assignment EMME Assignment

Car Park & Ride Rail Bus/BRT
Note that the non-motorised modes such as walk and cycles are not explicitly
modelled in GBMF. There potential impact on demand changes is represented
through the trip frequency sub-model as permitted by WebTAG.
Park and ride (P&R) is treated as a sub mode of car. P&R modelling uses an
absolute logit model of site choice to enable P&R users to choose between
competing sites within their catchment areas.
3
LEVEL OF SEGMENTATION
Demand Segmentation (Stages 1 to 5)
To support a range of Major Scheme Bid submissions including the appraisal of

road-user charging schemes, travel demand is disaggregated into sixteen
segments as summarised below in Table 2. Travel demand is separated into five
different journey purposes (home-based work, home-based other, non home-
based other, home-based employers business and non home-based employers
business), three household income bands (low, median and high) and two person
types (car-available and non-car available). The level of segmentation is more
detailed than the minimum suggested by WebTAG.
Table 2 – Demand Model Segmentation

Car Available (CA) Non Car
Supply Demand
Income Income Income Available
Purpose Purpose
Low Medium High (NCA)
HBO 1 2 3 12
Other
NHBO 4 5 6 13
NHBEB 7 14
Work
HBEB 8 15
Commuting HBW 9 10 11 16
In addition, the GBMF separately represents light and heavy good vehicles but
these are not considered within the demand model.
Supply-Side Segmentation (Stage 6)
For highway assignment modelling, the GBMF demand is aggregated, by income

group, into four user classes within each time period plus a further two user
classes for light and heavy goods vehicles as summarised in Table 3. The
aggregation is undertaken by income group as the route choice coefficients for the
assignment are the same and enables the overall CPU time to be significantly,
reduced.
Table 3 – Highway Assignment User Classes (by Time Period)

User Demand Demand
Description
Class Segments Responsive
1 Car Non Work Income Low 1, 4, 9 Yes
2 Car Non Work Income Median 2, 5, 10 Yes
3 Car Non Work Income High 3, 6, 11 Yes
4 Car Work 7, 8 Yes
5 Light Goods Vehicles Not represented No
6 Heavy Goods Vehicles Not represented No
4
A higher level of aggregation is undertaken in the public transport assignment
model with segmentation only applied by mode (ie bus, rail, BRT/LRT) reflecting
limitations within the EMME software.
The three (one-hour) supply-side models provide costs for the AM peak period
(07:00-10:00), Inter-peak period (10:00-16:00) and PM peak period (16:00-19:00).
Separate pre-peak hour models represent the travel conditions in the 07:00-08:00
and 16:00-17:00 time period for the AM and PM peak hours respectively. The
demand for these pre-peak hours is a proportion of the peak hours with the factor
derived from local traffic count profiles.
To reduce model runtimes, it is assumed that that the assignment costs for the Off-
Peak (19:00-07:00) representing the travel conditions in that period are a
proportion of the inter-peak period costs.
3. TECHNICAL CHALLENGES & INNOVATIONS
HIGH P ERFORMANCE C OMP UTING
Convergence Targets
The GBMF demand model, highway and public transport assignment models are
linked together with demand and supply loops controlled in an automated fashion.
The traditional Cobweb averaging method was implemented to determine the
equilibrium point between the demand and supply models and the %GAP measure
(as defined in WebTAG Unit 3.10.4) was used to monitor the level of convergence
achieved. The %GAP measure (across all segments) is defined as:
∑ 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
- 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 GBMF model is run until the convergence level, as measured by the
aforementioned %GAP, is lower than 0.2%. Experimentation has shown that this
requires the highway convergence levels as defined by Wardrop’s equilibrium to be
less than 0.05%. This is a very high level of convergence and incurs a substantial
CPU overhead.
5
Model Runtimes
The largest of the GBMF models has 600 zones and on a standard high-spec
Pentium-4 based desktop PC required more than 100+ hours of CPU time to
achieve the required convergence target. The majority of the CPU time was
required to undertake the highway assignments (and subsequent skimming). To
reduce model runtimes, a number of changes were made including the use of the
latest Intel Quad-core Xeon (X5450) workstations, simultaneous skimming of time,
distance and tolls using the new SKIM_ALL option in SATURN and the
parallelization of the assignment and skimming by time period across the individual
CPU cores as illustrated below in Figure 2.
Figure 1 - Parallel SATURN Highway Procedure

Core 1 Core 2 Core 3
Demand Model
Not used* Not used*
(Loop n)
Highway Assignment Highway Assignment Highway Assignment

(AM Peak) (Inter Peak) (PM Peak)
Skim Highway Costs Skim Highway Costs Skim Highway Costs

(AM Peak) (Inter Peak) (PM Peak)
Demand Model
Not used* Not used*
(Loop n+1)
* Not used by SATURN
The control of the parallel process was undertaken by the new SATURN
MONITOR and WAIT programs called from within the EMME demand model.
VARIABLE C ONVERGENCE TARGETS (S ATURN CAS S INI)
Highway Convergence
The SATURN assignment algorithm uses the Frank-Wolfe algorithm (Frank and
Wolfe, 1956) to achieve an equilibrium solution. A characteristic of the algorithm is
a rapid initial decent before a gradual approach to a highly converged solution as
shown in Figure 3. For 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. Clearly,
significant CPU savings may be achieved by (appropriately) reducing the
convergence targets for the SATURN highway model where possible.
6
Figure 3 – SATURN Assignment: %CPU time to converge to %GAP=0.05
%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%
Demand Model Convergence

As noted earlier, the demand model uses a Cobweb method to achieve
convergence between the supply and demand models. The convergence profile of
the demand model is similar to the highway model as shown below in Figure 4. By
setting a more relaxed highway convergence target for the early demand model
loops, considerable savings in CPU time may be achieved. This is undertaken
automatically by the new SATURN-CASSINI (Atkins, 2009) program that tracks the
level of convergence achieved within the Demand Model and sets appropriate
targets for the highway model. The two profiles are also shown in Figure 4.
Figure 4 – Variable Convergence Targets
70%
60%
Demand Model (%GAP)
%GAP (Supply/Demand
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
7
SATURN-CASSINI
With the SATURN-CASSINI program, a considerable reduction in CPU time is

achieved for the early loops of the demand model. Whilst the demand model
requires more loops to achieve the same %GAP value of <0.2 – typically an extra
three or four loops reflecting the slower descent – there is an overall saving of
around 40% in the highway CPU time compared to the standard method as shown
in Figure 5 below.
Figure 5 – Comparison of GBMF 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
With these innovations in optimising the CPU usage, CASSINI has reduced model
runtimes from around 30+ hours to around 18 hours per 2031 forecast year
scenario.
The recent introduction of SATURN Multi-Core, the new multi-threaded version of

the SATURN assignment program, has further reduced overall CPU times to less
than 13 hours – a further reduction of over 25%.
P RODUCTION-ATTRACTIONS WITH TIME P ERIOD C HOICE
The introduction of PA-based modelling, as required by WebTAG, with the explicit

consideration of time period choice is complex particularly when, as shown
previously in Figure 1, time period choice is undertaken after main mode choice
but before destination choice. The key technical challenge, within the demand
model, was how the demand and costs arising from the return leg of a home-based
trip may be estimated when the timing of the return leg is dependent on the earlier
outward journey.
8
In other words, if an outward home-based trip retimed from the morning peak
period to the corresponding inter-peak period in response to the introduction of a
morning peak road pricing, when would the corresponding return leg be
undertaken?
Within the demand model, the challenge was to determine the appropriate travel
demand and associated costs of return-legs of home based trips in a coherent and
consistent manner given that the return-leg journeys were constrained by the
nature of their outward journeys. Whilst WebTAG requires that a PA functional
form should be adopted, it did not provide any guidance on how it may be
implemented.
Methodology
A new PA-based formulation with time period choice was proposed. The
fundamental assumptions underpinning this approach are the use of fixed return
proportions and time of day restriction:
• For outward trips leaving home within each time period, the proportions of
trips returning in subsequently time periods remain fixed by purpose over the
base year and future forecast years. In other words, if AM tolls were applied
and certain trips shifted to the IP period (for example), the return leg of these
transferred outward trips would have the same return patterns as those
already established in the base inter-peak period;
• The time of a day choice starts with the AM Peak period and that trips
departing over the course of the day will all return before the commencement
of the following AM Peak period the next day. In other words, for each
outbound from-home trip, there would be an equivalent trip returning home
during the day and the sum of outward journeys equals to the sum of return
journeys.
Accordingly therefore, only the outward from-home trips in each time period are
explicit modelling variables for the PA formulation within the GBMF demand model.
The return-leg demands were calculated from outward-leg demands with
associated return proportions. The following paragraphs describe the details of the
PA formulation when the time period choice is structured as previously shown in
Figure 1.
Time Periods
Denote the modelled time period as (t), outward from-home time period as (s), and
return to-home time period as (r) respectively. The four time periods (t) in a 24-
hour day are:
t=am: 07:00-10:00; t=ip: 10:00-16:00; t=pm: 16:00-19:00; and t=op: 19:00-07:00

For a given time period t, the outward from-home time period (s) is the same as t:
s = t for t ∈{am, ip, pm, op}.
9
For each time period t (or s), there are multiple corresponding return time periods
(r) as defined below:
r ∈{am, ip, pm, op}, if t = am;
r ∈{ip, pm, op}, if t = ip;
r ∈{pm, op}, if t = pm; and
r ∈{op} if t = op.
The above relationship is illustrated below in Table 2 where symbol (√) indicates
available returning time periods for each outward time period:
Table 2 - Returning Time Period Specification

Return To-Home time period (r)
AM IP PM OP
AM √ √ √ √
IP √ √ √
Outward From-Home Period (s)
PM √ √
OP √
Demand Model Variable Notations
We use “p.c.m” or “pcm” to represent segmentation used in the GBMF with

combination of purpose (p), person type (c) (household income band and
CA/NCA), and mode (m). Table 4 below provides the variables used for the PA
specification.
Table 4 – Notation Used in the PA Formulation
Notation Description Source Data

Given time period t, reference outward from-home trip
0 proportion by p.c.m for origin sector I and destination sector
Pout IJpcmt RSI data
J. These factors are used only once in creating base PA
trips.
Given time period s, fixed to-home proportion for trips
returned in time period r by p.c.m. These factors are only
RSI data and
Pr et 0pcmsr segmented by p.c.m – not enough data is available to
NTS data
populate all ij pairs in a matrix from. (Not sure at this stage if
sector based factors are achievable).
The total of from-home trips from 2006 RSI by p.c.m in time
( RSI )
TIJpcms period s from origin sector I to destination sector J RSI data
(directional from-home).
The total of from-home and to-home trips from RSI by p.c.m
( RSI )
TIJpcmt in time period t from origin sector i to destination sector j RSI data
(non directional).
10
Notation Description Source Data
Calibrated /
Validated
(OD ) 0 Reference OD assignment matrices from origin i to
Tijpcmt base
destination j in time period t by p.c.m (non directional).
assignment
matrices
(OD ) 0 Reference outward OD trips from origin i to destination j in
Tijpcms
time period s by p.c.m (directional from-home).
( PA ) 0
Tijpcmt Reference production-attraction (PA) trips from production
zone i to attraction zone j in time period t by p.c.m.
( PA ) 0 Reference production-attraction (PA) costs from production
Cijpcmt
zone i to attraction zone j in time period t by p.c.m.
Skimmed base OD generalised costs of travel for outward
(OD ) 0
Cijpcms trips in time period s from origin i to destination j by p.c.m
Given time period t, skimmed base OD generalised costs of
(OD ) 0
Cijpcmtr travel for trips returning home in time period r from origin i to
destination j by p.c.m (directional to-home)
( PA ) 0
Tijpcm Reference 24hr PA trips from production zone i to attraction
24 Fixed
zone j by p.c.m.
PA costs of travel for time period t converted from relevant
( PA )
Cijpcmt OD outward and return costs from production zone i to
attraction zone j by p.c.m.
Skimmed OD generalised costs of travel for outward trips in
(OD )
Cijpcms time period s from origin i to destination j by p.c.m
Given time period t, skimmed OD generalised costs of travel
(OD )
Cijpcmtr for trips returning home in time period r from origin i to
destination j by p.c.m (directional to-home)
The change of PA costs from the forecast year over the
∆Cijpcmt
( PA )
base year from production zone i to attraction zone j in time WebTAG
period t by p.c.m.
CC Composite costs (logsums) over IHL WebTAG
Subject to
λ A series of IHL Spreading parameters over FMTD stages
realism tests
Output
( PA ) Latest production-attraction (PA) trips from production zone directly from
Tijpcmt
i to attraction zone j in time period t by p.c.m. the demand
model
(OD ) Estimated OD outward trips from origin i to destination j in
Tijpcms
time period s by p.c.m (directional from-home).
Given time period t, estimated OD return trips that happen
(OD )
Tijpcmtr in time period r from origin i to destination j by p.c.m
(directional to-home).
Given time period t, the latest total OD trips estimated in the Send to the
(OD )
Tijpcmt current demand/supply loop from origin i to destination j in assignment
time period t by p.c.m (non directional). stage
11
Create Outward and Return Proportions
For a given time period t, the reference proportion of outward (from-home) trips
over total trips was calculated via RSI data, which should only be used once to
create reference PA matrices by time period and by segmentation:
( RSI )
TIJpcms
Pout 0
IJpcmt = ( RSI )
(1)
TIJpcmt
The fixed reference proportions by time period s for GBMF were based on National
Travel Survey (NTS) data supplied by DfT (as shown below in Table 5). Note that
for a given time period s, proportions for trips returning home in time period r are
subject to the following constraint:
∑ Pret
r
0
pcmsr =1 (2)
Table 3: Example Set of Fixed Return Proportions

HBW HBO HBEB
AM Outward
AM Return 0.03 0.26 0.06
IP Return 0.20 0.55 0.55
PM Return 0.67 0.15 0.31
OP Return 0.10 0.04 0.08
Total 1.00 1.00 1.00
IP Outward
IP Return 0.26 0.70 0.81
PM Return 0.49 0.25 0.16
OP Return 0.25 0.05 0.03
Total 1.00 1.00 1.00
PM Outward
PM Return 0.48 0.58 0.40
OP Return 0.52 0.42 0.60
Total 1.00 1.00 1.00
OP Outward
OP Return 1.00 1.00 1.00
Total 1.00 1.00 1.00
Create Reference PA Costs and Demands
For a given time period t, reference demands and costs were calculated by the
following two formula respectively:
12
( PA ) 0
Tijpcmt = Tijpcms
( OD ) 0
= Tijpcmt
( OD ) 0 0
Poutijpcmt (3)
( PA ) 0
Cijpcmt = (Cijpcms
( OD ) 0
+ ∑ (Cijpcmtr
( OD ) 0
)' Pr et 0pcmsr ) / 2 (4)
r ≥s
where r ≥ s means that r ranges from the outward from-home time period (s) up to
the last time period (op) in a day, and the (·)’ means a transpose of a matrix. In
other words, the costs defined in (4) are a weighted average of the outward and
return legs.
The daily 24-hour reference demand was the sum of the time period PA demands
(which account for only an half of total OD demands):
24 = ∑ Tijpcmt
( PA ) 0 ( PA ) 0
Tijpcm (5)
t
Convert OD Costs to PA Costs
For each demand / supply loop, the skims from the OD-based assignment by time
period (t) were converted to PA costs for feeding into the demand model. With the
same formulation as given by (4), the PA costs in forecasting considered both
outward and return journeys simultaneously as a weighted sum given below:
( PA )
Cijpcmt = (Cijpcms
( OD )
+ ∑ (Cijpcmtr
( OD )
)' Pr et 0pcmsr ) / 2 , (6)
r≥s
where r ≥ s means that r ranges from the outward from-home time period (s) up to
the last time period (op) in a day.
By adding the relevant return costs, say, any AM tolls will be appropriately
allocated to further to-home trips occurring in the same and subsequent time
periods (i.e. IP, PM and OP), and therefore the impact of AM tolls will be
distributed across all time periods rather than incorrectly allocated to the AM
demand calculation only.
Incremental Demand Modelling
For an Incremental Hierarchical Logit (IHL) formulation as used in GBMF, the

change of PA costs at the bottom level of hierarchy over the base year was simply
defined as
∆Cijpcmt
( PA )
= Cijpcmt
( PA )
− Cijpcmt
( PA) 0
(7)
Based on ∆Cijpcmt
( PA )
, the composite costs i.e. the structured logsums over the various
stages of the demand model were calculated in the standard way:
CC = f (∆Cijpcmt
( PA ) ( PA ) 0
, Tijpcmt , λ) (8)
13
Based on the CC and others, the demand model calculated a new set of PA
outward-leg demands for each demand/supply loop, or simply
( PA )
Tijpcmt = f (CC , Tijpcmt
( PA ) 0
,λ)
Convert PA Demands to OD for Assignment
( PA )
The outward PA demands Tijpcmt output from the demand model were then
converted to the OD form for assignment. The outward from-home OD demands
are simply the latest PA demands output from the demand model:
( OD )
Tijpcms = Tijpcmt
( PA )
(9)
Return-leg demands were constrained by relevant outward from-home trips that

take place in previous time periods. Note that the PM return demands
corresponded to proportions of trips travelling out in the AM period, IP period, and
PM period respectively.
For given time period (t), the formula to calculate to-home demands is given below
by applying the fixed return proportions over the latest outward from-home trips:
( OD )
Tijpcmtr = ∑ Pr et 0pcmsr (Tijpcms
( OD )
)' , (10)
s≤r
where s ≤ r means that s ranges from the first time period (AM) up to the current
time period t.
Finally, the OD assignment demands were simply the sum of from-home and to-
home trips:
( OD )
Tijpcmt = Tijpcms
( OD )
+ Tijpcmtr
( OD )
(11)
Final Comments
The demand model estimates the outward PA demands directly by standard IHL
technique. The return-leg demands were implicitly considered via the outward
journeys in the following way:
• Return OD costs were incorporated in formulas (4) and (6) above, i.e. the PA
costs are taken as the average OD costs between the outward and return
journeys;
• Return-leg trips were collected by formula (10) from their relevant outward
legs using fixed return proportions. Therefore, any reduction of AM trips
resulting from say, the introduction of AM tolls, would have been mapped
onto the corresponding return legs.
14
C OS T DAMP ENING : VALUE OF TIME VARIATION WITH DIS TANCE
Overview
An inherent property of incremental hierarchic logit models is the difficulty in

achieving observed outturn elasticities for both shorter and longer distance trips.
The calibration of the initial GBMF (referred to as ‘version 1 model’ herein)
focussed on achieving the appropriate outturn elasticities for shorter-distance trips,
reflecting the main area of interest for the study. However, as subsequently
described in Section 4, the resulting outturn elasticities were notably higher than
the target elasticities as recommended by WebTAG.
Variations in Value of Time
To overcome this problem, a form of cost dampening was introduced (as now
outlined in the latest WebTAG Unit 3.10.4) whereby the Value of Time (VOT)
varied with distance for non-work trips. The adoption of VOT variation in the
subsequent version 2 enabled the model to successfully replicate the target
elasticities.
WebTAG Unit 3.12.2 (para 11.4.2) provides a formula to estimate local VOTs for
modelling road pricing schemes if the full distribution of income and distance of
trips is known. For GBMF, the average household income for all movements was
incomplete so an alternative expression of the WebTAG formula was derived as
presented below:
ηs ηs
 D  DC  

VOT = max VOTC   ,VOTC  
  D0   D0  

where:
• VOT : value of time used in version 2 for non-work trips (which varies by
distance);
• VOTC : the central value of time derived from WebTAG for non-work trips;
• D: length of trip (as estimated below); and
• D0 , DC , and η s : parameters.
The formula provides a matrix of VOTs by distance for non-work trips with the trip
length D representing the distance between each i-j pair in typical free-flowing
conditions. The distance elasticity parameter (η s ) is provided in para 11.4.4 of
WebTAG Unit 3.12.2 and is set to: 0.314 for other trips (HBO / NHBO) and 0.421
for commuting trips (HBW), together with the distance parameter D0 as 7.58 miles
(12.2 kilometres). The value of DC was set to 4km to identify the very short
distance trips (including intra-zonal movements).
15
Table 6 below summaries the VOTs used in both GBMF v1 and v2 models by
income group and purpose – the VOT variation by distance used in the v2 model is
represented by the matrix average, minimum and maximum. Note that there was
no variation in VOTs for either car-based Home-Based Work (as the outturn
elasticities were already within the acceptable range defined in WebTAG) or work
trips (single income group).
Table 6: Variation in Value of Time with Distance

Car Available (HBO / NHBO) Non Car Available
Purpose Income Income Income
HBW HBO / NHBO
Low Median High
GBMF Version 1 (Without VoT Variation)
Central Value 7.08 9.14 10.98 6.66 5.49
GBMF Version 2 (With VoT Variation)
Average Value 8.40 10.84 13.02 8.57 6.51
Minimum Value 4.99 6.44 7.74 4.16 3.87
Maximum Value 26.80 34.60 51.57 39.69 20.78
All values in pence / minute.
4. MODEL CALIBRATION AND OUTTURN ELASTICITIES
MODEL C ALIBRATION
WebTAG provides a range of illustrative model parameters for use in models

where locally observed data is not available. WebTAG recommends that model
parameters should be within this range (as outlined in WebTAG 3.10.3), as they
are derived from a number of UK models developed using locally collected
Revealed / Stated Preference survey datasets.
The following paragraphs compare the model sensitivity parameters and outturn
elasticities for the GBMF version 1 and version 2 implementations (ie before and
after the introduction of VOT variation with distance)
C OMP ARIS ON OF MODEL S ENS ITIVITY P ARAMETERS
Table 7 compares the model scale parameters (Theta) between lower level
destination choice lambdas and upper level mode choice lambdas for version 1
and version 2 models alongside the range of illustrative WebTAG parameters for
each purpose. Note that time period choice scale parameters used the same
values as the main mode choice in GBMF as recommended by WebTAG and are,
in effect, undertaken simultaneously.
Table 7 shows that the introduction of variation in VOT by distance enabled the
calibrated Theta parameters for the version 2 model to match the median WebTAG
values. Conversely, several of the version 1 model values were significantly below
the minimum recommended WebTAG target values as indicated by (*).
16
Table 7 – Comparison of Scale Parameters in Mode Choice
WebTAG Theta
Purpose GBMF Theta
(Minimum / Median / Maximum)
GBMF Version 1 (Without VOT Variation)
HBO 0.27 / 0.53 / 1.00 0.51
NHBO 0.62 / 0.81 / 1.00 0.48(*)
NHBEB 0.73 / 0.73 / 0.73 0.46(*)
HBEB 0.26 / 0.45 / 0.65 0.55
HBW 0.50 / 0.68 / 0.83 0.54
GBMF Version 2 (With VOT Variation)
HBO 0.27 / 0.53 / 1.00 0.53
NHBO 0.62 / 0.81 / 1.00 0.81
NHBEB 0.73 / 0.73 / 0.73 0.73
HBEB 0.26 / 0.45 / 0.65 0.45
HBW 0.50 / 0.68 / 0.83 0.68
Table 8 presents the comparison of model sensitivity parameters (Lambda) for

destination choice by mode (ie car versus public transport). As with the mode
choice parameters, varying VOT by distance enables the version 2 model
parameters to be set to the median WebTAG illustrative values for both modes
whereas a number of the highway lambda values for version 1 model were below
the minimum target values. Note that for both models, the public transport
destination choice parameters were set to the median WebTAG values.
Table 8 - Comparison of Sensitivity Parameters in Destination Choice

WebTAG Lambda GBMF Lambda
Purpose Public Public

Highway
Transport Highway Transport
(Min / Median / Max)
(Median) (CA / NCA)
HBO -0.074 / -0.090 / -0.160 -0.036 -0.070(*) -0.036
NHBO -0.073 / -0.077 / -0.105 -0.033 -0.069(*) -0.033
NHBEB -0.069 / -0.081/ -0.107 -0.042 -0.068(*) -0.042
HBEB -0.038 / -0.067 /-0.106 -0.036 -0.042 -0.036
HBW -0.054 / -0.065 / -0.113 -0.033 -0.050(*) -0.033
HBO -0.074 / -0.090 / -0.160 -0.036 -0.090 -0.036
NHBO -0.073 / -0.077 / -0.105 -0.033 -0.077 -0.033
NHBEB -0.069 / -0.081 / -0.107 -0.042 -0.081 -0.042
HBEB -0.038 / -0.067 / -0.106 -0.036 -0.067 -0.036
HBW -0.054 / -0.065 / -0.113 -0.033 -0.085 -0.033
17
O UTTURN E LAS TICITIES
WebTAG Target Values
WebTAG suggests that the fuel cost elasticities should be within the range of -0.1
to -0.4, with the more discretional trips (ie HBO / NHBO) closer to -0.4 whilst more
compulsory trips such as Work (ie HBEB / NHBEB) close to -0.1. WebTAG also
recommends that overall, all-day elasticity should be within the range of around
-0.25 to -0.3, depending on the geographical location of the modelled are and the
relative affluence to the UK as a whole. Using the aforementioned model
parameters (ie lambda and theta values), outturn fuel-cost elasticities were
estimated for the two GBMF model formulations.
Model Performance
Table 9 presents the outturn fuel cost elasticities for the ‘Internal to
Internal/External (‘I to I&E’) movements by time period and purpose where I
represents the main modelled area and E represents the area outside. Note that in
GBMF, external to external movements (E to E) were excluded from the demand
model as the costs of those movements were not fully represented and were only
subject to external growth factors (as were the light and heavy good vehicle
movements).
Table 9 - Comparison of Outturn Fuel Elasticities

Total
Time Movement
HBW HBO NHBO Non- Work All
Period Type
Work
AM I to I&E -0.21 -0.85 -1.09 -0.42 -0.09 -0.38
IP I to I&E -0.16 -0.53 -1.01 -0.53 -0.07 -0.43
PM I to I&E -0.11 -0.45 -0.97 -0.35 -0.04 -0.33
All Day I to I&E -0.16 -0.59 -1.02 -0.46 -0.07 -0.39
AM I to I&E -0.29 -0.38 -0.39 -0.32 -0.12 -0.30
IP I to I&E -0.23 -0.27 -0.42 -0.29 -0.10 -0.26
PM I to I&E -0.14 -0.22 -0.42 -0.23 -0.06 -0.22
All Day I to I&E -0.23 -0.28 -0.41 -0.28 -0.10 -0.26
Table 9 shows that for the version 1 model (without VOT variation with distance),
the outturn fuel cost elasticities were too high for the discretionary trips (HBO and
NHBO) which, in turn, result in overall outturn all-day elasticities noticeably greater
than the WebTAG target values. With the version 2 model, the introduction of VOT
variation with distance enabled the outturn elasticities to fall within the WebTAG
recommended range. The overall elasticity of -0.26 was lower than the maximum -
0.30 target value reflecting the high income levels in the Greater Bristol area
compared to the UK average.
18
5. SUMMARY
This paper presents a flexible, state-of-the-art aggregate transport modelling

framework with innovative design and implementation. The GBMF framework
represents the latest in UK best-practice for equilibrium-based demand models.
GBMF includes a number of innovative features including:
• One of the first, fully-WebTAG compliant six -stage demand model

representing a 24-hour travel demand in Production/Attraction (P/A) format
using an incremental, logit-based pivot-point form to achieve equilibrium in
forecasting;
• An innovative Production-Attraction (PA) formulation has been constructed

for the GBMF with pseudo tours for average week days to enable the latest
WebTAG requirements to be satisfied. Pseudo tours have been created
based on trip data for home-based trips by using return proportions obtained
from UK Department for Transport (DfT). This PA formulation is consistent to
the GBMF demand modelling structure with pseudo tour zonal costs
appropriately weighted between outward and return legs;
• The introduction of a form of cost dampening by distance-based value of time

to achieve the required outturn elasticities for the fully represented
movements within the study area; and
• The use of SATURN-CASSINI software - enabling the convergence targets in

the supply-side model to be dynamically linked to those obtained within the
demand model – has substantially reduced model runtimes. The recent
migration to SATURN Multi-Core has provided further reductions to support
the practitioner.
The GBMF has been used to support a number of Major Scheme Bid submission
for UK Central Government funding and provides a modular framework that has
been readily adapted to create a family of models of the Greater Bristol area.
6. REFERENCES
Van Vliet, D. Hall, M.D. and Willumsen, L.G. (1980) SATURN - A Simulation-
Assignment Model for the Evaluation of Traffic Management Schemes, Traffic
Engineering & Control, 21, 168-176, April 1980.
Frank, M and Wolfe, P (1956), An algorithm for quadratic programming, Naval

Research Logistics Quarterly, No. 3 1956, pp. 95-110.
Department for Transport (2004 onwards), Transport Analysis Guidance

(WebTAG) TAG Units 3.10 Variable Demand Modelling.
Atkins Limited (2009), The SATURN-CASSINI User Guide, SATURN Manual

(v10.9), Section 15.54 and Advanced SATURN Workshop, Day 2, Session 5
(Atkins, 2009).
19
Appendix - R – WebTAG-based Variable Demand Modelling using SATURN
R.2 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App R.doc
5109341 / Mar 13 R-2

11_2_05_App R.docx
Appendix S – Practical Benefits of Origin-based Assignments & Network

Aggregation
S. Practical Benefits of Origin-based

Assignments & Network Aggregation
S.1 Background
This appendix contains a copy of the paper presented at the 2010 European
Transport Conference (ETC) that followed on from the 2009 ETC paper described
in Appendix R. The first part of the paper demonstrated how the use of OBA,
coupled with CASSINI and Warmstart techniques, produced substantial
reductions in the overall supply-demand GAP convergence hitherto unobtainable
using the Frank-Wolfe algorithm and reduced the total CPU time for a fully
WebTAG-compliant demand model by a factor of 2.
The second part of the paper described how the new Network Aggregation
technique (as known as SPIDER), undertaken in the initial network building stage,
reduced overall CPU times by similar factors to those offered by SATURN Multi-
Core and sometimes well in excess.
The second 2009 ETC paper describes the development of the OBA algorithm
and the extension for Multiple User Class assignments.
5109341 / Mar 13 S-1

11_2_05_App S.docx
THE PRACTICAL BENEFITS OF THE SATURN ORIGIN-BASED ASSIGNMENT
ALGORITHM & NETWORK AGGREGATION TECHNIQUES
Ian Wright, Yanling Xiang, Liz Waller, Jenny Cross & Eric Norton, Atkins Limited
Dirck Van Vliet
1. INTRODUCTION
The implementation of the Origin-Based Assignment (OBA) algorithm (Bar-Gera et al,

2003) in SATURN (Van Vliet et al, 1980) for multiple user class (MUC) assignments was
made available to SATURN users in 2008. A summary of the development work (and the
potential benefits) was presented at 2009 ETC with a paper entitled ‘A New
Implementation of Origin-Based Assignment Algorithm in SATURN’ (Yanling et al, 2009a).
The first part of this follow-up paper describes the practical benefits of using ‘warm-starts’
with SATURN OBA whereby stored cost and/or flow information from a previously
converged network solution is used to start the current assignment in preference to free-
flow costs and default zero flows typically used. As with path-based algorithms, OBA may
readily use ‘warm-start’ techniques to transfer assigned flows from the ‘old’ network to the
‘new’ one to improve convergence and reduce model runtimes.
Whilst the 2009 release of the SATURN Multi-Core offered significant reductions in model
assignment runtimes, those performance gains have been more than matched by the
practical benefits of embedding origin-based assignments, such as SATURN OBA, within
a full Variable Demand Modelling (VDM) framework. In particular, the use of OBA - in
preference to existing Frank-Wolfe (FW) based algorithms (Frank and Wolfe, 1956) – has
demonstrated tangible benefits in terms of:
 improvements in convergence in both the highway assignment and also the supply-
demand equilibrium loops;
 the efficiency of the ’warm-start’ OBA (Ws-OBA) in building on stored flows from an
existing, converged solution rather than starting from free-flow conditions; and
 faster secondary analysis using the path information retained by OBA.
These practical benefits, over existing FW algorithms, are quantified using two models
developed to support Major Scheme Bid (MSB) submissions and demonstrate that the
origin-based algorithm produces comparable economic (TUBA-based) benefits results to
the existing process. In both cases, the Ws-OBA algorithm achieved high levels of
convergence with substantial reductions in overall computational (CPU) time required.
The second part of the paper presents a new Network Aggregation (NA) Technique
undertaken in SATURN within the initial network building stage. The NA procedure
analyses the network structure to identify ‘chains of links’ that can be aggregated to
provide a much more compact network definition. In effect it may be thought of as a form
of “pre-tree” building in standard FW assignments; in other words, before a minimum cost
tree is built from a single origin a number of minimum cost “sections” are constructed from
existing links which then allow the actual tree building to proceed with larger steps.
Tests using the NA technique on a series of real-life networks reduced CPU times by
similar factors to those offered by SATURN Multi-Core and sometimes well in excess.
1
The development of the hybrid FW-OBA algorithm, previously referenced in the ETC 2009
paper, was subsequently discontinued as it became clear it could not effectively compete
against the latest SATURN multi-core techniques.
The SATURN OBA (along with ‘warm-start’ techniques) was made available to all
SATURN Users with the release of SATURN Version 10.9 in October 2009. The new
Network Aggregation techniques are already in use and will be officially released to the
SATURN User Community in January 2011.
2. TEST MODELS AND SCHEMES
The practical testing for Ws-OBA and Network Aggregation was undertaken using existing
transport models. The transport models used are briefly described below. All tests were
undertaken using SATURN v10.9.
PART 1 WS-OBA TESTS
Two MSB-compliant variable demand models were used to compare the performance of
the warm-start OBA and the multi-core FW algorithms:
 Model A (A PT Scheme): a new public transport mode introduced in a large
conurbation to enhance the public transport provision; and
 Model B (A Highway Scheme): a package of highway measures across a sub-

regional network.
The two strategic transport models adopt a similar aggregate form to those previously
described (Xiang et al, 2009b) based around:
 A five-stage incremental demand model fully compliant to UK Department for

Transport (DfT)’s Transport Analysis and Guidance (WebTAG), including
frequency modelling, main mode choice (between highway and PT), time period
choice, destination choice, and sub-mode choice; and
 Use of the SATURN CASSINI application (Atkins, 2010) which automatically

adjusts the convergence targets set for each run of SATURN to match the current
level of convergence achieved for the supply-demand “cobweb” loops. To
maximise the performance available from the desktop PC, the assignments and
subsequent cost skimming for the separate morning, inter-peak and evening time
periods were undertaken in parallel (with the assignments also using the latest
SATURN multi-core techniques as described later in this paper).
PART 2 NETWORK AGGREGATION TESTS
Five models were used to demonstrate the practical performance gains available with the
new Network Aggregation technique, implemented in SATURN for FW assignments.
These models are described below:
 Model 1: Six user classes, 600 zones, 13515 / 19947 assignment nodes / links;
 Model 4: Two user classes, 229 zones, 4263 / 6440 assignment nodes / links; and
 Model 5: Two user classes, 115 zones, 1964 / 3022 assignment nodes / links.
2
PC HARDWARE SPECIFICATION
All the computational results presented in the paper were obtained by using commercially
available standard desktop workstations based around an Intel Xeon Quad-Core CPU
X5450 @3.00GHz with 4 GB of RAM running Window XP 32-bit Operating System).
3. OBA PERFORMANCE COMPARISON TO FW ASSIGNMENTS
HOW WARM-START WORKS USING SATURN-OBA
OBA Overview
Bar-Gera (2002) proved that there is always an equilibrium solution by origin for acyclic
sub-networks and the necessary restriction to using only acyclic sub-networks will not
prevent the algorithm from converging to the true equilibrium solution. The OBA algorithm
uses this concept by always working with acyclic sub-networks, continuously refining the
structure and the flows within each origin sub-network until a perfect 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 furthest, 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 AN and BN 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. The OBA uses the data structure in order to assign
all traffic for that origin. Starting with the relevant O-D flows initially “loaded” at each
destination, the loading algorithm works from the most distant node back 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.
For SATURN-OBA, the node list and splitting factors are saved in an output binary file with
the (arbitrary) extension .UFO. Using the stored UFO files, it is relatively simple 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. These UFO solutions provide the necessary
information to warm-start another assignment.
To evaluate the performance of the SATURN FW and Warm-start OBA algorithms, Models
A and B were run with the same inputs with the two assignment algorithms. The runs
undertaken were:
 Model A: With / Without Scheme scenarios were run for two forecast years; and
 Model B: With / Without Scheme scenarios were modelled for one forecast year
(with the benefits extrapolated from a single forecast).
The model forecasts were appraised using DfT’s TUBA software package which
undertakes a full cost-benefit appraisal over a 60-year period.
The relative performance of the models was assessed by determining the supply-demand
convergence and the amount of CPU expenditure required. The %GAP measure (as
defined in WebTAG Unit 3.10.4) was used to monitor the level of convergence achieved.
3
The latest WebTAG (April 2010) suggested that the %GAP measure should be less than
0.01 or 0.1 times the ratio of any scheme benefits to the DM network costs, whichever is
the lower. The Supply-demand %GAP measure (referred to SD-%gap hereafter) is
defined as:
 ijctm  
C  X ijctm  D C  X ijctm   X ijctm
*100
 ijctm
C  X ijctm  X ijctm
where:
- Xijctm is the current flow vector or matrix from the model
- C(Xijctm) is the generalised cost vector or matrix obtained by
assigning that matrix
- D(C(Xijctm)) is the flow vector or matrix output by the demand model,
using the costs C(Xijctm) as input; and
- ijctm represents origin i, destination j, demand segment/user class c,
time period t and mode m.
MODEL A WITH MULTI-CORE FW ASSIGNMENT
Supply-Demand Convergence
Figure 1 presents SD-%gap values by supply-demand loop from the later forecast year for
Model A With / Without Scheme using the existing multi-core FW algorithm. The SD
%gap target was set to 0.05 but neither the DM nor the DS scenarios achieved this target
before the maximum number of SD-loops was reached – previous testing had shown that
additional supply-demand loops would only result in further oscillation. The final SD-%gap
values were around 0.1 with oscillation starting to occur from loop 17.
Figure 1 – SD Convergence Profile for existing FW algorithm (Model A)

1000
100
With Scheme
Log (SD‐%Gap)
10 Without Scheme
1
1 3 5 7 9 11 13 15 17 19 21 23
0.1
0.01
SD‐Loop
4
CPU Time
To minimise CPU expenditure, the SATURN-CASSINI software (Atkins, 2010) was used to
automatically adjust the convergence targets set for each run of the SATURN assignment
to match the current level of SD convergence. A ‘relaxed’ set of SATURN convergence
criteria (e.g. %gap value of 1.0) were set for the initial loops when the SD convergence
was poor and the trip matrices were still highly uncertain but the criteria were subsequently
tightened (progressively increasing to a %gap value of 0.05) as the overall model
convergence improved.
Nevertheless, a considerable CPU expenditure was required to complete the 24 loops –

for example, the later forecast year required around 29 hours of CPU time to complete this
number of loops. Figure 2 shows the CPU time for the three model components:
 Four stage, EMME-based incremental logit demand model (plus EMME PT
assignment model);
 SATURN-based highway assignment; and
 SATURN-based highway skimming of time, distance and toll components.
As noted earlier, both the SATURN assignment and skimming were distributed across the
four available cores.
The largest CPU time was the SATURN assignment accounting for 44% of the total 29
hours required, with skimming accounting for 25% hours and the more complex demand
model only requiring the remaining 31%. Figure 2 clearly shows the potential reductions in
the overall model runtimes even if only small increases in the efficiency of the assignments
and skimming could be achieved.
Figure 2 – FW CPU Expenditure by Model Component (Model A, With Scheme)
120
SATURN Skimming
100 SATURN Assignment
Demand Model Process
CPU Time (mins)
80
60
40
20
0
1 3 5 7 9 11 13 15 17 19 21 23 End
SD‐Loop
5
MODEL A WITH WARM-START OBA
Model A was re-run with the same input files but using the Ws-OBA technique. Figure 3
shows the comparative performance of Ws-OBA and the FW algorithm (as previously
displayed in Figure 1). The Ws-OBA technique initially has a steeper descent profile as
well as continuing to descend towards the SD-%gap convergence target of 0.05; the target
was reached within only 15 loops.
Figure 3 – Comparison of SD Convergence Profiles (Model A, With Scheme)

1000
100
Log (% SD‐Gap)
10 FW
OBA
1
1 3 5 7 9 11 13 15 17 19 21 23
0.1
0.01
SD‐Loop
CPU Time
Figure 4 shows the profiles of CPU expenditure by loop for Ws-OBA (and comparable to
Figure 2). Whilst the average CPU time for each iteration of the demand model
component remains unchanged, there are significant time savings in the highway
assignment and substantial reductions in the skimming time.
6
Figure 4 – Ws-OBA CPU Time by Model Component by SD-Loop (Model A)
120
SATURN Skimming
100 SATURN Assignment
Demand Model Process
CPU Time (mins)
80
60
40
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 End
SD‐Loop
As noted above, the Ws-OBA model run reached the stopping criteria in 15 loops whereas
the FW-based model run did not achieve the stopping criteria but was terminated after the
maximum number of loops (24). Table 1 compares the CPU time required to achieve the
lowest SD-%gap value (15 loops for Ws-OBA and 22 loops for FW). The table shows that
the Ws-OBA algorithm out-performed FW with a much lower SD-%gap value (0.048
versus 0.071), achieved in around half the CPU time.
Table 1 – CPU Time by Model Component (Model A, With Scheme)
VDM Element FW Ws-OBA Difference %Difference

Convergence
SD Loops 22 15
SD-%gap 0.071 0.048 -0.023
Component
Demand / PT Models 9.4 6.1 -2.9 -32%
Highway Assignment 12.7 7.3 -4.8 -38%
Highway Skimming 7.3 1.2 -6.0 -82%
Total 29.4 14.6 -13.8 -47%
Table 2 summarises the SD-%gap levels achieved and CPU expenditure after the 15 SD-
loops (when Ws-OBA had reached the SD convergence target). At this stage, the FW SD-
%gap value was twice the Ws-OBA value. In terms of the CPU time expended by each
VDM component, additional CPU time was required for the Ws-OBA assignment (+14%)
but this was more than offset by the 39% reduction in the CPU time required for skimming.
7
Table 2 – CPU Time by Model Component after 15 Loops (Mod A, With Scheme)

Convergence
SD Loops 15 15
SD-%gap 0.103 0.048 -0.055
Component
Demand / PT Models 6.7 6.5 -0.3 -3%
Highway Assignment 6.1 7.9 +1.8 +14%
Highway Skimming 4.1 1.3 -2.9 -39%
Total (hrs) 17.0 14.6 -1.4 -5%
How Do the Performance Gains Arise?
The OBA algorithm stores route information during the assignment and provides two
distinct advantages over the existing FW algorithm. Firstly, after the initial loop 1
assignment, the subsequent highway assignments may be continued from the previous
converged assignment rather than starting from free-flow network conditions. The
differences in the start and end %GAP values in the assignment between the two
algorithms are illustrated below in Figure 5 (FW) and Figure 6 (Ws-OBA). Ws-OBA
provides a significant reduction in the CPU time required in subsequent loops (as
highlighted in Table 1). Secondly, the highway costs are skimmed from the assignment by
simply summing the origin-based route proportions rather than re-building the paths from
the link information stored.
Figure 5 – FW Internal SATURN Convergence by SD-Loop (Model A)
100
10
Log (Assignment %Gap)
1
1 3 5 7 9 11 13 15 17 19 21 23
0.1 %GAP ‐ 1st Loop
%GAP ‐ Final Loop
0.01
SD‐Loop
8
Figure 6 – Ws-OBA Internal SATURN Convergence by SD-Loop (Model A)
100
%GAP ‐ 1st Loop
10
%GAP ‐ Final Loop
Log (Assignment %Gap)
1
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0.1
0.01
SD‐Loop
TUBA Results
The business case TUBA benefit analysis was undertaken for Model A to determine the
impact of the Ws-OBA on the final scheme benefits. The overall impact of the proposed
scheme – as indicated by the Present Value of Benefits (PVB) measure – is summarised
below in Table 3. The table shows that the overall PVB increased due to the higher levels
of convergence achieved (and hence, reduced assignment ‘noise’) in the OBA-based
highway model forecasts.
Table 3 – Comparison of Projected Present Value of Benefits (Model A)

FW Ws-OBA
Total PVB 1.00 1.10
MODEL B COMPARISON RESULTS WITH BETWEEN FW AND WS-OBA
The Model B VDM tests evaluated a highway scheme for a single forecast year with the
comparisons undertaken for Model A repeated for Model B. Figure 7 compares the SD
convergence profile for the With Scheme scenario using the existing FW and Ws-OBA
algorithms. As with Model A, the Ws-OBA algorithm has a steeper descent profile as well
as continuing to decrease towards the SD-gap convergence target. The target
convergence was reached within only 15 loops using the Ws-OBA algorithm whereas the
FW algorithm started to oscillate from loop 18 with a SD-%gap value of around 0.1.
9
Figure 7 – Comparison of SD Convergence Profiles (Model B, With Scheme)
100.0
FW
10.0
OBA
Log (SD‐%Gap)
1.0
1 3 5 7 9 11 13 15 17 19 21 23
0.1
0.0
SD‐Loop
CPU Time
Table 4 compares the CPU expenditure required by the FW and Ws-OBA algorithms to
reach their lowest SD-%gap value. The relative performance of the two algorithms is
similar to that found in Model A. The FW algorithm required around 30 hours of CPU
expenditure to achieve its lowest SD-%gap value of 0.078 whereas the more efficient Ws-
OBA algorithm reached the target SD-%gap value of 0.050 in around 16 hours of CPU –
slightly more than half that of the FW algorithm.
Table 4 – CPU Time by Model Component (Model B, With Scheme)

Convergence
SD Loops 21 (Lowest) 16
SD-%gap 0.078 0.045 0.033
Component
Demand / PT Models 5.4 4.3 -1.1 -21%
Assignment 19.8 9.7 -10.0 -51%
Skimming 5.1 2.3 -2.8 -54%
Total (hrs) 30.2 16.3 -13.9 -46%
TUBA Results
A TUBA evaluation was undertaken for the Model B highway scheme using both the FW
and Ws-OBA algorithms. The overall impacts of the scheme are given below in Table 5
(with the values normalised to the FW Total PVB). The analysis confirms that the project
benefits using the two algorithms were very similar.
10
Table 4 – Comparison of Projected Present Value of Benefits (Model B)
FW Ws-OBA
Total PVB 1.00 1.02
SUMMARY OF WARMSTART OBA PERFORMANCE COMPARISON
The results from the performance undertaken with Models A and B clearly demonstrate
the practical benefits gained with the new Ws-OBA when compared to the existing FW
algorithm. The Ws-OBA achieved far higher levels of supply-demand convergence and
within substantially less computational time (typically a factor of two lower).
With the saved path information always available, OBA is shown to provide substantial
time savings for undertaking cost skimming. (Similar performance gains would be
achieved for the other secondary analysis processes).
The TUBA economic evaluation demonstrated that the Present Value of Benefits for the
schemes were comparable between the two algorithms though, in the two networks
tested, that the projected highway benefits were higher.
4. NETWORK AGGREGATION
BASIC CONCEPTS
The total time required to carry out a single all-or-nothing assignment step, the basic
building block of the Frank-Wolfe algorithm for traffic assignment within SATURN, is an
increasing function of: (a) the number of (origin) zones; (b) the number of nodes; and (c)
the number of links (see Van Vliet (1978) for “typical” formulae). While (a) is fixed, any
reductions in either (b) or (c) should therefore lead to reduced CPU times and this is the
objective of a “network aggregation” technique proposed in Van Vliet (1978).
For example, 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. This geometry commonly occurs in SATURN networks with, e.g., network
shaping nodes, centroid connector stubs and separate bus lanes.
Less obviously a node with three arms may be removed entirely and its input and output
links replaced by pairs of links such that the total number of links is not increased.
Equally, nodes with four or more arms may also be removed although there is no
guarantee that the number of output links is reduced (which depends on how many links
are one-way).
A (semi-empirical) methodology has been introduced into the network building procedures
within SATNET to produce aggregated networks by removing nodes in a progressive
manner. Further information may be found in the SATURN User Manual (Atkins, 2010)
including a detailed description of the NA techniques with illustrated examples.
11
The Frank-Wolfe algorithm in SATALL proceeds as normal by optimally combining an
auxiliary all-or-nothing solution of basic link flows with the current solution but with one
major exception. Thus the NA technique uses the aggregated network (as a "shortcut") to
build and load minimum cost trees in order to obtain the all-or-nothing basic link flows,
rather than use the full network. This in turn involves three extra steps:
 Prior to tree building calculate the current cost of each aggregated link by summing
the costs of its constituent basic links;
 Remove the more costly of any duplicated aggregated links (i.e., links with the
same A-node and B-node, of which there may be a sizeable proportion); and
 Post loading of the aggregated network, transfer the flows loaded onto the
aggregate links back onto their constituent basic links to obtain “auxiliary” all-or-
nothing flows on the basic links.
PERFORMANCE
The Network Aggregation version of the FW algorithm shows extraordinary reduction in

model runtimes (CPU expenditure) while maintaining the same level of assignment
convergence, especially in the multi-core version. Table 5 provides a summary of
changes in network dimensions and “pure” assignment times for a range of SATURN
networks (where a “pure assignment” refers to a single assignment within SATURN as
opposed to a full SATURN run which loops between assignment and simulation sub-
modules). The results for Models 1 to 5 are indicated by ‘*’ with the other networks – from
real-life studies, used for software testing.
Table 5 also describes the number of ‘Duplicates’ and ‘Equivalent’ links. ‘Duplicates’
refers to sets of links – see above – which may be replaced by a single link, thus saving
CPU time. ‘Equivalent links’ is the sum of all links in the underlying assignment network
which are included within individual links in the aggregated network.
Table 5 – Benefits of Network Aggregation
User Original Network Aggregated Network CPU

Zones Duplicates Equivalent
Class Ratio
Nodes Links Nodes Links
5
115* 2 1,964 3,022 308 2,858 362 24,232 3.2
176 1 1,246 2,329 340 3,026 413 16,379 2.2
4
229* 2 4,263 6,440 621 6,313 1,063 54,989 3.3
299 3 3,758 6,198 692 6,712 949 50,401 1.9
2
527* 6 13,204 20,116 1,616 18,114 4,693 175,665 9.2
598 8 13,374 21,229 2,310 27,364 4,187 200,797 13.5
1
600* 6 13,515 19,947 1,688 17,675 3,444 177,598 6.7
993 1 42,665 63,596 5,264 60,363 14,422 567,896 11.0
1,348 7 30,633 52,277 4,926 53,363 17,028 387,600 8.6
1,638 7 28,587 60,325 6,064 61,922 22,645 335,510 5.6
3
2,520* 5 57,877 93,905 8,833 96,296 23,593 753,240 2.9
n
Key: CPU Ratio based on the SATURN Assignment time (SATASS) component only; * indicates Model 1 to 5
12
Table 5 demonstrates the reductions in the number of nodes by factors of up to eight but
only modest reductions or even increases – sometimes appreciable - in the number of
links. Pure assignment runtimes were typically reduced five-fold but with reductions in
excess of ten times for certain networks, equivalent to or greater than the performance
gains offered by SATURN Multi-Core.
CPU Times for Assignment plus Simulation
However, 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. The following sections present full SATURN assignment CPU comparison
results based on the test models 1-5 (as presented in Section 2) by running:
 Standard FW;
 Multi-Core FW;
 FW with NA technique; and
 Multi-Core FW with NA 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 8 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.
13
Figure 8 – 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.
Flow Differences
The different techniques were run to the same level of convergence. A standard
regression analysis was undertaken for Model 1 to compare the assigned link flows and
the analysis confirms that the assignments were virtually identical.
FURTHER DEVELOPMENTS OF NETWORK AGGREGATION
Despite the impressive reductions in CPU time achieved with the current techniques there
are almost certainly further improvements possible. 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
14
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”; it should almost certainly be possible to improve the current rather simple-minded
procedure.
There may also 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, rather 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 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 aggregated 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.
5. CONCLUSIONS AND FUTURE DEVELOPMENTS
WARM-START OBA
The performance results from Models A and B clearly demonstrate the benefits to be
gained with the new Warm Start OBA algorithm when compared to the FW. Ws-OBA
achieved far higher levels of supply-demand convergence in a VDM context, and within
substantially less computational times (typically half).
With the saved origin-based information always available, OBA is also shown to provide
substantial time savings for undertaking the cost skimming. (Similar performance gains
would be achieved for the other secondary analysis processes).
The TUBA economic evaluation demonstrated that the Present Value of Benefits for the
schemes were comparable between the two algorithms though, in the two networks
tested, the projected highway benefits were higher.
15
NETWORK AGGREGATION
The technique of network aggregation introduced in SATURN for FW assignments has

been shown to lead to a substantial reduction in CPU time required to achieve similar
levels of convergence. The small overhead following the introduction of the “pre-tree”
building procedures with aggregated networks is several orders of magnitude smaller than
the time savings generated during the main assignment. In particular, the reduction in
overall assignment times for large SATURN models are substantial and suggests that
tiered VDM approaches – previously used to provide practical runtimes for converged SD
loops - are no longer required for assignments undertaken using NA-based techniques.
Currently the NA technique has only been coded in SATURN for the FW assignment with
either single core or multi-core implementation, not OBA. In principle, the technique may
be applied to any assignment algorithm during the path building and loading stages which
are normally computationally intensive in terms of runtimes.
FUTURE DEVELOPMENTS
A natural extension of the NA technique is to the existing SATURN OBA and further
development is currently underway in this area. The introduction of NA into OBA is
theoretically guaranteed to mathematically converge (with the proof provided in Appendix
A). The mathematic proof shows that the Jacobian matrix of link costs in an aggregated
network is always symmetrical for the off-diagonal terms. It is well known that with
symmetrical Jacobian matrix, an traffic assignment problem can always be formed as an
equivalent minimisation problem with solutions (Dafermos,1971) that satisfy Wardrop user
equilibrium conditions. In the context of OBA, a unique global minimum solution was
mathematically proven by Bar-Gera (2002) and the use of a network, in aggregated form,
does not affect the properties of Bar-Gera’s algorithm.
The forthcoming extension of NA techniques to OBA will further enhance the practical
benefits of Origin-based assignments.
16
7. REFERENCES
Bar-Gera, H and Van Vliet, D (2003) The application of Origin-based assignment to

SATURN networks with asymmetric cost functions, European Transport Conference 2003.
Bar-Gera, H. (2002) Origin-Based Algorithm for the Traffic Assignment Problem,

Transportation Science 36 (4), pp 398-417.
Van Vliet, D. Hall, M.D. and Willumsen, L.G. (1980) SATURN - A Simulation-Assignment
Model for the Evaluation of Traffic Management Schemes, Traffic Engineering & Control,
21, 168-176, April 1980.
Van Vliet, D. (1978) Improved shortest path algorithms for transport networks,
Transportation Research Vol. 12, 7-20.
Xiang, Y, Wright, I, J, Van Vliet, D, Bar-Gera, H and Boyce, D (2009a), A New

Implementation of Origin-Based Assignment Algorithm in SATURN, European Transport
Conference 2009, Netherlands.
Xiang, Y, Wright, I, J, and Tony, M (2009b) A Novel Design and Implementation of AN

Aggregate UK-based Transport Model, European Transport Conference 2009,
Netherlands.
Atkins Limited (2010), The SATURN-CASSINI User Guide, SATURN Manual (v10.9),
Section 15.54 and Advanced SATURN Workshop, Day 2, Session 5 (Atkins, 2009).
Frank, M and Wolfe, P (1956), An algorithm for quadratic programming, Naval Research
Logistics Quarterly, No. 3 1956, pp. 95-110.
Dafermos, S. C (1971). An Extended Traffic Assignment Model with Application to Two-

Way Traffic. Transportation Science 5(4), pp.366-389
17
APPENDIX A – THEORETICAL PROOF OF EXTENDING NA TECHNIQUES TO OBA
Let a transport network represented by a direct graph G  ( N , L) where N is the set of nodes and
L is the set of links. And, a spider web network is defined by another direct graph G'  ( N ' , L' )
where N ' is the set of nodes and L ' is the set of links
Notation:
va : total flow on a normal link a

ca : cost of link a. Assume monotonically increasing separable cost function ca  ca (va ) (in
SATURN, they are realised via a technique of diagonalisation by simulation).
 aS : is 1 if link a is a part of spider web link S; and 0 otherwise

VS : flow on a spider web link S
CS : cost of spider web link S
 : normal link (a) - spider web link (S) incidence matrix
J SW : Jacobian derivative cost coefficient matrix of the spider web network.
Proof
In matrix form, the following relationship always holds:
v   V
C  T  c(  V )
For a normal network a, link flow on it is then as:
v a   S  aS VS (1)
And, for spider web link S, its cost is:
C S  a  Sa
T
c a (v a )  a  Sa
T
c a (S  aS VS ) (2)
Giving two spider web links A and B and from (1) and (2), we have
C A  a  Aa
T
c a ( A  aAV A )
C B  a  Ba
T
c a ( B  aBV B )
From (1) we have
dv a
  aS
dVS
The off-diagonal terms of Jacobian matrix of cost function of spider web network are:
C A T dc a dv a T dc a dc
 a  Aa  a  Aa  aB  a  aA aB a (3)
V B dv a dV B dv a dv a
18
C B T dc a dv a T dc a dc
  a  Ba   a  Ba  aA  a  aB  aA a (4)
V A dv a dV A dv a dv a
Clearly, from the right hand side of (3) and (4), the following
C A C B

V B V A
Therefore, the Jacobian matrix of a spider web network is symmetric. Consequently, the traffic
assignment problem may be expressed as a minimisation problem (Dafermoss 1971).
Moreover, the diagonal terms of the Jacobian matrix are
C A T dc a dv a T dc a
  a  Aa   a  Aa   aS (5)
V A dv a dV A dv a S
C B T dc a dv a T dc a
  a  Ba   a  Ba   aS (6)
V B dv a dV B dv a S
Considering (3) – (6) together, we have the following conditions:
C A C A C B C B
 0  0
V A V B ,
V B V A
Therefore, for each row of the Jacobian matrix, the diagonal term is always larger than off-diagonal
terms and indeed it is the sum of all them. A specific example for a three-arm node N which is
aggregated is given below.
 c1 c3 c1 c3 

 (V V )  (V V ) (V  V ) (V V )
0 0 0 
 1 2 1 3 1 2 1 3

 c1 c1 c4 c4 
  0 0 0 
(V1 V2 ) (V1 V2 ) (V2 V6 ) (V2 V6 )
 
 c3 c3 c2 c2 
 0  0 0 
(V1 V3 ) (V1 V3 ) (V3 V4 ) (V3 V4 )
J SW ൌ  
 c2 c2 c5 c5 
 0 0  0 
 (V3 V4 ) (V3 V4 ) (V4 V5 ) (V4 V5 ) 
 c5 c5 c6 c6 
 0 0 0  
 (V4 V5 ) (V4 V5 ) (V5 V6 ) (V5 V6 ) 
 c4 c6 c4 c6 
 0 0 0  
 (V2 V6 ) (V5 V6 ) (V2 V6 ) (V5 V6 ) 
A
c1 A
c5 V1
c3 V6
N c6 C C
V4 V
2 V3
c2
c4 V6
19
B
B
A NEW IMPLEMENTATION OF ORIGIN-BASED ASSIGNMENT ALGORITHM IN
SATURN
Yanling Xiang and Ian Wright, Atkins Limited

Dirck Van Vliet
Hillel Bar-Gera, Purdue University, and Ben-Gurion University of the Negev, Israel
David Boyce, Northwestern University
1. INTRODUCTION
The most common traffic assignment algorithm used in practice is the link-based
Frank-Wolfe algorithm (Frank and Wolfe, 1957), which has been the principal
assignment algorithm (with various modifications) used in the SATURN highway
assignment suite since its first release in 1981 (Van Vliet et al, 1980). Whilst the
Frank-Wolfe (FW) algorithm is theoretically proven to produce a converged
solution (when the problem has a convex optimisation formulation) it fails to
achieve accurate solutions within any practical computation timeframe.
The Origin-Based Assignment (OBA) algorithm (Bar-Gera, 2002) was developed

by Prof. Hillel Bar-Gera, while a PhD student at the University of Chicago in the
late 1990’s. The key difference of OBA from the link-based FW algorithm is that it
stores the link flows as generated by each individual origin. In a certain sense,
OBA is an intermediate between link-based and path-based algorithms but without
requiring excessive RAM or CPU as typically characterized by the latter. The
principle of OBA is that, by considering origin-based link flows from the a-cyclic
subnetwork, it provides a computationally efficient route-building process as well
as enabling the elimination of residual flows (i.e. small flows on sub-optimal routes)
that have a detrimental impact on algorithm convergence.
The algorithm revolutionised traffic assignment in that it provided a Wardrop

Equilibrium solution whose numerical accuracy was restricted only by the
numerical accuracy of the computer, i.e. it converged exactly within reasonable
CPU times. OBA first became available with the release of SATURN Version 10.5
in 2005 for single user class (SUC) assignments only - this restriction precluded its
practical application.
A secondary benefit of the OBA algorithm is that the secondary analysis that
requires route information (e.g. select-link analysis and cost skimming) may be
readily extracted from the route information stored during the assignment rather
than having to be subsequently re-built from the link information stored under FW.
This paper presents the subsequent developments of OBA within SATURN: (i) the
extension of the algorithm to handle multiple user class (MUC) assignments; and,
more recently, (ii) a hybrid algorithm combining the speed of Frank-Wolfe algorithm
with the accuracy of OBA. This development work continues and the latest results
presented show its potential. The recent release of multi-threaded implementation
of the existing FW algorithm (SATURN Multi-Core) provides further exciting
opportunities to combine the speed of FW with the subsequent accuracy of OBA
MUC.
1
This paper is organised as follows: Section 2 presents an overview of the OBA
algorithm (applicable to both SUC and MUC implementations) whilst Section 3
describes the extension of the existing OBA algorithm for the MUC problem as well
before providing a practical comparison of FW and OBA algorithms. Section 4
describes the hybrid algorithm with latest results whilst Section 5 provides a
summary of the findings.
2. AN OVERVIEW OF ORIGIN-BASED ASSIGNMENT
A-C YCLIC S UBNETWORKS
Unlike the link-based FW algorithm, the routes created by the OBA path-building
process connecting the origin to all other origins cannot pass through the same
node more than once – the resulting subnetwork is described as ‘a-cyclic’. The
work undertaken by Bar-Gera (2002) proved that there is always an equilibrium
solution by origin for a-cyclic subnetworks and the restriction to using only a-cyclic
subnetworks will not prevent the algorithm from converging to the true equilibrium
solution.
AP P ROACH P ROP ORTIONS AND R OUTE F LOWS
The main solution variable in the OBA algorithm is the calculation of the origin-
based approach proportions for every origin and every link in the subnetwork, such
that for every origin p and node i contained therein:
• the sum of origin-based approach proportions, for each origin p over all
subnetwork links ending at node i is equal to one; and
• the approach proportions for origin p of links that are not included in the
subnetwork are restricted to zero.
Using origin-based approach proportions, route proportions are determined by the

product of the individual approach proportions of all the subnetwork links along the
route. The resulting route flows are simply determined by the product of OD flow
and route proportion.
Advantages
The representation of the solution by origin-based approach proportions allows

storing a complete description of the route flows very efficiently. This is a major
difference from many alternative solution procedures, including the most common
FW algorithm, which store only total link flows during the iterative process. The
use of a-cyclic subnetworks allows a definition of a topological order of the nodes,
which is an origin-specific ordering of the nodes, such that every link in the
restricting subnetwork goes from a node of lower topological order to a node of
higher topological order.
2
Most computations in the proposed algorithm are done in a single pass over the
nodes, either in ascending or descending topological order. The time required by
such computations is a linear function of the number of links in the network. This
computational efficiency is a major advantage of the restriction to a-cyclic
solutions.
TRAFFIC AS S IGNMENT
Using the A-Cyclic Subnetwork
In solving the traffic assignment problem, the algorithm starts with trees of
minimum cost routes as restricting subnetworks, leading to an all-or-nothing
assignment. Then, the algorithm considers all origins in a sequential order. For
each origin the restricting subnetwork is updated, and the origin-based approach
proportions are adjusted within the given restricting subnetwork.
To update a restricting subnetwork, unused links are removed. Once a new

restricting subnetwork is found, several computationally intensive steps are needed
including a reorganization of the data structure. However, the structures of the
restricting subnetworks tend to stabilise fairly quickly. Therefore, it is useful to
update origin-based approach proportions while keeping the restricting
subnetworks fixed. This is done by introducing “inner iterations” as described in
the flow chart, presented below in Figure 1.
To update origin-based approach proportions within a given restricting subnetwork

a search direction based on shifting flow from high cost alternatives to low cost
alternatives is used. In addition to current costs, estimates of cost derivatives are
used to improve the search direction in a quasi-Newton fashion. When two
independent routes are considered, the amount of flow shifted by the search
direction equals the difference between route costs divided by the sum of route
cost derivatives – the same result as would be obtained by considering an
objective function second-order approximation.
Eliminating Residual Flows
The second-order search direction described above is viewed as desirable flow

shifts. These are scaled by a step size between zero and one, and then truncated
to guarantee feasibility, a process referred as the ‘boundary search procedure’.
This technique is somewhat different than conventional line search techniques,
where shifts are first truncated to guarantee feasibility and only then scaled by a
step size. The importance of the boundary search for OBA is that it is effective in
eliminating residual flows, i.e. small flows on sub-optimal routes. The elimination of
residual flows is critical for algorithm convergence. See (Bar-Gera, 2002) for
details.
3
Achieving Convergence using ‘Social Pressure’
In order to guarantee descent of the objective function, and convergence of the

algorithm, the search considers various step size values of 1/n. The stopping
condition is based on the concept of ‘social pressure’ introduced by Kupsizewska
and Van Vliet (1999). The principle of social pressure is that every traveller shifted
from route r 1 to r 2 places pressure (positive or negative), which is equal to their
gain (or loss) as a result from the shift, that is according to the difference in route
costs. The total social pressure is the sum of the pressure from all the travellers.
The search direction is beneficial in the sense that it always enjoys positive social
pressure for small step sizes but, as the step size increases, the social pressure
decreases, and eventually it may become negative. The objective is to determine
the largest step size with positive social pressure - this social pressure principle is
similar to the stopping condition of the line-search in the Frank-Wolfe algorithm.
3. EXTENDING OBA TO MULTI-USER CLASS PROBLEMS
O VERVIEW
The OBA algorithm was originally implemented for single user class problems but
the principle restriction to SUC related to the implementation rather than any
theoretical considerations. By its nature, OBA creates multiple copies of the same
network via its use of a-cyclic subnetworks and provides a flexible framework that
may be readily expanded.
Within OBA, the origin-based link flows are independent between origins and the
revisions to handle MUC problems naturally extends that principle such that the
origin-based link flows are independent by origin and user class. In theory, the
extension to MUC problems is simply achieved by considering the MUC network
as an enlarged SUC network, whereby the origins for each user class are arranged
sequentially in turn as if they were consecutive origins with the total number of
virtual origins equal to the number of user classes (UC) multiplied by the number of
zones.
P ROGRAMMING
In practice, however, there was a substantial volume of re-coding of the existing

data structures and algorithm to handle specific user-class components such as
demand, generalised costs, banned turns, and penalties as well as ensuring
consistency with the existing functionality of the SATURN suite.
The MUC implementation of OBA in SATURN is a natural extension of SUC OBA

based on its multi-copy property. The theoretical framework of OBA is theoretically
scalable across any number of user classes in essence and all the properties of
SUC OBA hold equally for MUC.
4
The existing OBA was coded in the C language and linked to the existing SATURN
FORTRAN through object libraries. Whilst the majority of the changes were
(relatively) straightforward, the principle complication occurred in the calculation of
link costs for MUC networks. For the existing FW assignments implemented in
SATURN, SUC and MUC link costs are calculated differently – for MUC, link costs
are the summation of:
• UC independent congested flow-dependent link costs (delays); and
• UC dependent free-flow link costs and fixed penalties (including bans or

tolls).
The cost function in the C programming for MUC OBA was implemented in a
similar way as that in FORTRAN for MUC FW assignments. The handling of
banned links in C was actually a translation of equivalent FORTRAN code. For the
calculation of cost derivatives, no special treatment was needed as they are a
function of congested link flows which are UC independent.
The following summarises key techniques and methods that were adopted for the
development of the MUC OBA in SATURN with C programming:
• New data structures were created to store origin-based networks by UC and

origin (plus various new structures and arrays for MUC OBA-specific
components);
• FORTRAN COMMON blocks already in SATURN were shared wherever

possible to reduce computer memory requirements;
• The MUC OBA assignment initialisation was based on the same principle as
that of SUC OBA - an All-Or-Nothing (AON) shortest path calculation. The
only difference was that, in addition to the UC-independent free flow costs,
the UC-specific fixed costs formed the basis for MUC route initialisation; and
• MUC OBA assignments were undertaken by UC and by origin in a sequential

order - whenever user classes are switched from one to another during the
assignments, UC-specific fixed costs and link bans are updated accordingly
and global structures refreshed for the next UC assignment.
Figure 1 below presents the flow chart of the implementation of MUC OBA
algorithm in SATURN.
Figure 1 – Flow Chart showing the OBA MUC Algorithm

Initialization:
for every UC k
Get UC-specific fixed costs and link/turn bans for k
for every origin p
Let A p be a tree of minimum cost routes under free flow conditions from p
Let α pa equal 1 for all links in A p and 0 otherwise. (All-or-nothing assignment)
end for
5
end for
Main loop:
for n=1 to number of main iterations
for every UC k
Get fixed costs and link/turn bans for UC k
for every origin p
update restricting subnetwork A p
end for
end for
for m=1 to number of inner iterations
for every UC k
Get fixed costs and link/turn bans for UC k
for every origin p
end for
end for
end for
end for
Update restricting subnetwork for UC k and origin p:
remove unused links from A p
for every node i compute the maximum cost ν i from p to i
for every link a=[i,j]
if ν i <ν j add link a to A p
find new topological order for new A p
update data structures
Update origin-based approach proportions for UC k and origin p:
compute average costs and Hessian approximations
for step size 1,1/2,1/4,1/8…
compute flow shifts and scale by step size
project and aggregate flow shifts
if social pressure is positive then stop
end for
apply flow shifts
update total link flows and link costs
P ERFORMANCE OF THE OBA MUC ALGORITHM
The performance of the new OBA MUC algorithm against the existing FW-
implementation in SATURN is shown below for two real-life models:
• Model 1 was a relatively small SATURN assignment model with six user
classes, 216 zones, 3001 assignment nodes, and 4545 assignment links;
whilst
• Model 2 was a much larger SATURN model with nine user classes, 453
zones, 7063 assignment nodes, and 10285 assignment links.
6
The comparisons illustrate %GAP against total CPU time in hours. %GAP is a
normalised convergence indicator for Wardrop equilibrium - in SATURN it
measures the degree to which the routes assigned are minimum cost routes after
the simulation stage.
Figure 2 shows the convergence for the OBA MUC and FW algorithms for Model 1
whilst Figure 3 provides the same comparison for Model 2. For both models, whilst
the FW algorithm was more efficient in early stages, it did not reach the same low
level of convergence that OBA subsequently achieved within the equivalent CPU
time.
Figure 2 - SATURN Convergence (Model 1)
1.0
0.0 1.0 2.0 3.0 4.0 5.0 6.0
0.1
0.01
%GAP
FW
OBA
0.001
0.0001
0.00001
CPU Time (minutes)

1.0
0 10 20 30 40 50 60 70
0.1
%GAP
0.01 FW
OBA
0.001
0.0001
CPU Time (minutes)
7
S UMMARY
The analysis shows that the OBA MUC algorithm was able to achieve higher levels
of convergence than the FW algorithm within similar CPU expenditure. Whilst the
existing FW algorithm was much faster in the initial stages it eventually became
‘stuck’ and unable to reduce the convergence error within its assigned solution.
4. HYBRID FW-OBA ALGORITHM
More recently, a new hybrid algorithm - combining the speed of Frank-Wolfe with
the accuracy of SATURN-OBA – has been developed to enable very highly
converged highway assignment solutions to be achieved without a significant
increase in CPU overheads. The current development work is focussing on the
optimal strategy for balancing the CPU time required and the level of convergence
achieved.
S ATURN AS S IGNMENT
The hybrid algorithm initially starts off with the FW algorithm before transferring to
the OBA MUC algorithm. The transfer point is determined by the level of
convergence between the assignment-simulation loops in SATURN.
Assignment-Simulation Loops
The SATURN assignment consists of two modules (Figure 4): (i) a pure
assignment module based on “separable” link cost-flow functions; and (ii) a
simulation stage which accounts for non-separable interactions between traffic
streams at junctions. The assignment provides link (and turn) flows to the
simulation which, in turn, produces an updated set of separable cost-flow functions
based on the junction interactions for use in the next assignment. These two
modules are run in an iterative loop until: (i) both modules have converged
internally; and (ii) the changes in the cost-flow functions and/or link flows are very
small.
Figure 4 - SATURN Assignment and Simulation Loop
8
Switching Between Algorithms
A key feature of the early assignment-simulation loops is the large changes in the
cost-flow functions between successive loops. These occur because of the large
imbalance in the assigned flows estimated in the current assignment and those
derived from the previous loop and used in the simulation. Consequently, at this
early stage, it is not necessary to estimate a highly converged assignment and it is
more efficient, in terms of CPU required, to use FW. However, once the
convergence between the assignment and simulation has begun to stabilise, it is
advantageous to have a highly convergent assignment available with OBA.
P ERFORMANCE OF THE HYBRID ALGORITHM
The performance of the hybrid algorithm against both the FW and OBA MUC
implementation in SATURN is shown below for three more real-life models using
the same comparisons previously shown in Section 3 with (Log) %GAP plotted
against total CPU times. The Hybrid algorithm was also tested using the earlier
models and the performance of the algorithm is also presented. The three new
models were:
• Model 3 was a SATURN model with nine user classes, 321 zones, 5678
assignment nodes, and 8354 assignment links;
• Model 4 was a larger SATURN model with five user classes, 510 zones,
15875 assignment nodes, and 22113 assignment links; and
• Model 5 is a SATURN model with a single user class, 846 zones, 15599
assignment nodes, and 26849 assignment links.
Different convergence targets were used depending on the overall size of the
model. A convergence target of %GAP < 0.0001 for four consecutive loops was
set for Model 3 whilst more relaxed targets of %GAP < 0.001 and %GAP < 0.01
(for four consecutive loops) was selected for the larger Models 4 and 5
respectively.
Figure 5 compares the profiles for the three algorithms for Model 3 with the
assignment terminated when the convergence criteria was met. As previously
described in Section 3, the FW algorithm was quicker in the early stages despite
the oscillations in performance. The MUC OBA algorithm was much slower to
achieve similar levels of convergence but less prone to oscillation as well as
having a more linear descent profile. If the assignment was continued beyond the
pre-defined convergence target, the algorithm would have converged to a lower
%GAP value than would be achieved by FW.
The hybrid algorithm combined the strengths of the two algorithms: the initial rapid
improvements in convergence from FW followed by a steady decent profile of OBA
MUC. Within these tests, the switch to MUC OBA was undertaken at an early
stage (i.e. %GAP < 0.1) – empirical testing showed that switching to OBA MUC at
this level of convergence enabled lower %GAP values to be subsequently
achieved. Further optimisation work is underway in this area.
9
1.0
0 5 10 15 20 25 30 35
Switch from FW to
OBA for Hybrid
0.1
0.01
FW
%GAP
OBA
Hybrid
0.001
0.0001
Target %GAP <0.001 for

four consecutive loops
0.00001
CPU Time (minutes)
Figure 6 provides a similar comparison for the larger Model 4 with the assignment
also terminated when the convergence criteria (%GAP < 0.001) was achieved.
The MUC OBA and Hybrid algorithms performed less well with FW achieving the
convergence target much more quickly. The MUC OBA algorithm eventually
achieved a lower %GAP value but a considerable extra CPU overhead was
incurred. Conversely, the Hybrid algorithm incurred some oscillations in the
convergence caused by variations in flows and cost-delay functions in the
simulation between successive loops.

10.0
Switch from FW to
OBA for Hybrid
1.0
0 50 100 150 200 250
0.1
FW
%GAP
OBA
Hybrid
0.01
0.001

0.0001
CPU Time (minutes)
10
Figure 7 provides the same comparison for the Model 5 with the assignment
terminated when the convergence criteria (%GAP < 0.01) was achieved. Whilst
the MUC OBA converges much more slowly, the Hybrid algorithm is comparable to
the FW algorithm in terms of CPU expenditure to reach the same convergence.
10.0
Switch from FW to
OBA for Hybrid
1.0
0 10 20 30 40 50 60 70
FW
%GAP
0.1 OBA
Hybrid
0.01

0.001
CPU Time (minutes)
For completeness, Figure 8 shows the performance of the Hybrid model for Model
2 previously tested in Section 3. As with the other models, the Hybrid algorithm
shared the initial characteristics of the FW algorithm before providing an OBA
solution to a higher level of accuracy.
1.0
0 10 20 30 40 50 60 70
Switch from FW to
OBA for Hybrid
0.1
%GAP
0.01 FW
OBA
Hybrid
0.001
0.0001
CPU Time (minutes)
11
S UMMARY
By combining the rapidity of the FW algorithm in the early stages and subsequently
switching over to OBA MUC algorithm, the Hybrid algorithm has shown
performance advantages and its potential in solving real-life traffic assignment
problems:
• It is (generally) faster than OBA MUC alone but also more accurate than FW
in assignment convergence; and
• By using (and storing) route proportions, any secondary analysis may be

undertaken without needing to re-build the paths used by FW.
5. CONCLUSIONS
The development of the SATURN-based OBA MUC algorithm has been

presented in this paper. The performance of OBA MUC has been compared
against the existing FW algorithm for four real-life applications and its theoretical
superiority in achieving higher levels of convergence has been demonstrated.
These higher levels of convergence now achievable in SATURN will provide

practical benefits to other models that are sensitive to convergence including
demand models (e.g. DIADEM) and cost-benefits models (e.g. TUBA) for example.
The hybrid FW-OBA MUC algorithm brings together the advantages of FW and
OBA MUC and has led to improvements in computer runtimes and/or assignment
accuracy. The switch to OBA guarantees greater accuracy in the final equilibrium
assignment such that the impact of assignment noise is significantly reduced
(compared to existing FW-based processes) and high levels of convergence.
On a more practical-side, the hybrid algorithm has offered reduced model

runtimes in some networks and further efficiencies in secondary analysis as
the route information is stored during the assignment. The hybrid algorithm has
also recently been combined with the multi-threaded implementation of FW
available in SATURN Multi-Core and this has demonstrated further reductions in
CPU required – however, this discussion is beyond the scope of this paper.
Development work continues on the hybrid method already available in the latest
SATURN Beta versions with work focussing on further optimisation of the switch-
over strategy and associated controls.
The current OBA MUC development work has also reinforced the importance of
good quality network coding. Convergence within SATURN is sensitive to the
interactions between the assignment and simulation loops. New OBA algorithms
are able to achieve very high levels of convergence but only if the network coding
enables robust and stable estimates of flow and travel costs to be calculated.
12
6. REFERENCES
Bar-Gera, H and Van Vliet, D (2003) The application of Origin-based assignment to

SATURN networks with asymmetric cost functions, European Transport
Conference 2003.
Bar-Gera, H. and Boyce, D. (2003) Origin-based algorithms for combined travel

forecasting models, Transportation Research 37B (4), pp. 405-422.
Bar-Gera, H. (2002) Origin-Based Algorithm for the Traffic Assignment Problem,

Transportation Science 36 (4), pp 398-417.
Bar-Gera, H. (1999) Origin-Based Algorithm for Transportation Network Modeling,

National Institute of Statistical Sciences (NISS), Technical Report Number 103.
Kupsizewska, D and Van Vliet, D. (1999) UK 101 uses for path-based assignment,
European Transport Conference 1999.
Van Vliet, D. Hall, M.D. and Willumsen, L.G. (1980) SATURN - A Simulation-
Assignment Model for the Evaluation of Traffic Management Schemes, Traffic
Engineering & Control, 21, 168-176, April 1980.
Frank, M and Wolfe, P (1956), An algorithm for quadratic programming, Naval

Research Logistics Quarterly, No. 3 1956, pp. 95-110.
13
Appendix S – Practical Benefits of Origin-based Assignments & Network

Aggregation
S.2 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App S.doc
3.2.1 Web release – Jan 07 DVV NP IW IW 04/01/07
5109341 / Mar 13 S-2

11_2_05_App S.docx
Appendix T – Background Theory of Network Aggregation
T. Background Theory of Network Aggregation

T.1 Background
This appendix contains a copy of the paper published in Transport Research
Volume 12 (1978) that describes the original background theory to Network
Aggregation, supplementing the information provided in Section 15.56.
5109341 / Mar 13 T-1

11_2_05_App T.docx
Appendix T – Background Theory of Network Aggregation
T.2 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App T.doc
5109341 / Mar 13 T-2

11_2_05_App T.docx
Appendix U - Unused
U. Unused
U.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App U.doc
3.4 SATURN v10.7 Release DVV NP NP IW 12/03/07
5109341 / Mar 13 U-1

11_2_05_App U.docx
Appendix V – Dynamic Time Period Choice Modelling (SATKK)
V. Dynamic Time Period Choice Modelling

(SATKK)
INTRODUCTION
This note describes time period (“Peak Spreading”) modelling, in particular how to
assign a time-varying trip matrix and how to estimate time-dependent trip matrices
using an incremental logit model.
INCREMENTAL LOGIT TIME CHOICE MODELS

The incremental logit model of time choice predicts the distribution of o-d trips
between a discrete number of time periods (indexed by t) based on an observed
“base year” distribution and changes in travel costs from the base year. In other
words it is a model of peak spreading or contraction.
THE MODEL
In brief the number of trips from origin i to destination j in time period t, T ijt ,
(assuming, for the moment, a single user class) depends on 3 factors:
1) The value of T ijt in some base year;
2) A growth factor (either universal or i/j dependent) to reflect exogenous
growth in some forecast scenario;
3) A logit-style deterrence function of the form exp(-β(C ijt – C ijt 0)) where C ijt is
the cost from i to j in the forecast scenario and C ijt 0 is the equivalent in the
base year.
(In addition there is, in effect, a fourth term which constrains the total number of
trips from i to j to the total reflected by the growth factors in (2) above.)
Mathematically:
Equation V-1
( (
S ijt exp -β c*ijt − d ijt)) × S
exp (-β(c − d ))
Tijt =
∑ * ij
S ijτ ijτ ijτ
τ∈All t's
5109341 / Mar 13 V-1

11_2_05_App V.docx
Where:
T ijt Demand flow on all paths from origin i to destination j in time slice t;
β Measure of sensitivity to change of departure time (with units of inverse

cost)
Minimum path generalised cost, including any toll or road pricing
c *ijt charge, from origin i to destination j in time slice t
d ijt (C ijt 0) Generalised path cost, including any toll or road pricing charge,
from origin i to destination j in the base year for time slice t
S ijt Forecast trip demand, if costs remains fixed at d ijt , from origin i to
destination j in time slice t. equal to the base year matrix multiplied by
any growth factors; e.g., S ijt = 1.20 T ijt 0
S ij ∑S
t
ijt ; i.e., total forecast trip demand from i to j for all time slices
Thus if the costs in a par ticular time slice increase (and other costs remain the
same) then the third term above diverts trips to the alternative time periods;
conversely if costs are reduced this will lead to an increase in trips in that period. If
the costs are unchanged from the base year then the relative distribution across
time periods is also unchanged.
Note that the “current” path costs c ijt referred to above must be t he costs after
assigning T ijt . In other words c ijt and T ijt must be self-consistent or “in equilibrium”
in the same sense that an elastic demand model must be in equilibrium with its
assigned flows. We therefore require joint solution algorithms which are
guaranteed to converge to the correct equilibrium; see 1.3 below.
DEFINITIONS: BASE YEAR, BASE MATRICES, PIVOT POINTS, ETC.

The term “base” may be used in more than sense in the descriptions of the
incremental logit choice model. Thus, in one sense, we may refer to a “base year”
with a “base trip matrix” (divided into time periods) T ijt 0 and a “base cost matrix”
C ijt 0 . Equally, in the forecast year, we can think of the combination of trips S ijt
0
and c osts C ijt as defining a “ base point” for the forecast year’s demand
function (i.e. equation (1)). N ote that in this terminology the base costs are the
same in both base and forecast years but that the base point trip matrices are not
necessarily the same (since the forecast will probably allow for exogenous
growth).
0
It may therefore be useful to refer to S ijt and C ijt as the “pivot point” of the
demand functions in order to distinguish them more clearly from their counterparts
in the base year. In particular when we wish to refer to S ijt unambiguously we
shall call it the “base/pivot trip matrix”.
5109341 / Mar 13 V-2

11_2_05_App V.docx
DISCUSSION
It can be ar gued that the use of a l ogit choice model is less than perfect in the
case of departure time choice, in particular when the time periods are relatively
short and there is a high degree of correlation between them. In addition there is
nothing in the above cost-based term to reflect the empirical fact that for certain
trips, in particular the journey to work, travellers prefer an ear lier departure to a
later in order that they may arrive “on time” (an effect which more recent and more
complex time choice models can incorporate).
However one major advantage of the above model is that it has been shown in a
PhD dissertation by KK Chin (based, in part, on research carried out for the then
DTp) that the departure time choice model and t he Wardrop-equilibrium
assignment per time period which follows may be represented by the minimisation
of a joint objective function so that, in effect, the joint problem of departure time
and route choice is equivalent to a Wardrop assignment problem over a “hyper
network” to which a c onvergent solution may be s olved using standard network
assignment algorithms such as Frank-Wolfe.
By contrast other forms of departure time choice models face algorithmic
difficulties in obtaining a guaranteed self-consistent and convergent solution
between time choice and route choice and need to resort to heuristic methods. In
the view of the author there is a lot to be said to starting with a model for which
convergent algorithms exist and t hen improving the demand model within that
convergent framework rather than trying to “work backwards” from a behaviourally
preferable demand model towards a convergent algorithm.
With respect to the particular point of early departures being preferred to late it
should be not ed that empirical tests using SATURN simulation networks with
PASSQ (see below) have shown a t endency for more trips to divert out of the
“peak” to the “pre-peak” rather than the “post-peak” since the impact of queues
which start in the pre-peak have a greater impact on costs in the post-peak; i.e.,
drivers can reduce their costs by joining a queue earlier rather than later.
In addition it should be possible to segment drivers in the base year into user
classes such that, e.g., a certain class will appear only in the pre-peak and the
peak, in which case it is not possible for peak trips to switch to the post-peak since
T ijt for the post-peak is zero by definition. Fo r example if the total base-year
“profile” in three periods is made up of:
0.8 1.2 1.0
it could be sub-divided into 4 “user classes” with base-year profiles:
(1) 0.6 0.0 0.0
(2) 0.2 1.0 0.0
(3) 0.0 0.2 0.1
(4) 0.0 0.0 0.9
in which case user classes (1) and (2) would be unabl e to change time periods
according to equation (1), user class (2) would preferentially change from peak to
pre-peak while (3) would go from peak to post-peak only. The split into the four
5109341 / Mar 13 V-3

11_2_05_App V.docx
groups would clearly be “calibration parameters”, possibly related to trip purpose,

at the user’s discretion.
COMBINED ASSIGNMENT AND DEMAND SOLUTION ALGORITHMS

Since, as mentioned in 1.2, the problem of finding a self-consistent or “equilibrium”
solution linking the time period “demand” model with the assignment “supply”
problem can be represented as a convex optimisation problem it may be solved
using similar algorithms to those used to solve the more conventional elastic
assignment problem. The algorithm followed is iterative in nature as follows:
1) Given the “current” trip matrices T ijt (n) assign them (full equilibrium) to the
network(s) and obtain the link flows V at (n) and costs c at (n) for each time slice.
2) Calculate the current o-d costs c ijt (n)
3) Calculate “target” trip matrices F ijt (n) (via equation (1)) corresponding to c ijt (n)
and assign them as well to the network(s) to obtain “target” link flows W at (n) .
4) Obtain an upda ted estimate of the trip matrices as a l inear combination of
the previous and target trip matrices:
Equation V-2
T ijt (n + 1) = (1 - λ) T ijt (n) + λ F ijt (n)
Where λ is an “optimum” value chosen to minimise the objective function.

5) Increment n and return to step 1 unless some convergence criteria is met.
2. SATURN PROGRAMS AND PROCEDURES

Please note that the facilities described here are not exclusive or restrictive in the
sense that they represent the only possible ways in which SATURN might be used
“dynamically”. S ATURN is essentially a “ tool box” of network and matrix-based
procedures within which users may devise their own modelling frameworks – and
indeed are encouraged to do so.
INDIVIDUAL COMPONENTS USEFUL FOR TIME PERIOD MODELLING
PASSQ – DYNAMIC LOADING

The mechanism by which SATURN assigns time-varying trip matrices is via
“PASSQ” whereby a series of separate assignments is carried over, say,
successive 30 m inute periods with the proviso that at any point in the network
where assigned flows are over capacity for particular movements the excess flows
are not assigned “downstream” in that time period but are “passed” to the next (30
minute) time period. We describe this method as being “quasi-dynamic” – it is not
a perfect representation of the way traffic moves in time and s pace but it does
deal with some of the extreme problems of conventional assignment models
where trips are loaded “simultaneously” on all links along their assigned paths.
The batch file procedure SATTPX carries out multiple time period assignments
automatically.
5109341 / Mar 13 V-4

11_2_05_App V.docx
STORING MULTIPLE TIME PERIOD MATRICES

If we have, say, 3 time periods then we need 3 sets of trip matrices, 3 sets of cost
matrices, etc., all of which will be duplicated for both the base year and the test
scenarios. In order to reduce the number of matrices to manageable proportions
SATURN 9.5/Ten introduced an alternative form of stacked matrices where the
basic square matrices are stacked “horizontally” in “blocks” rather than (as is done
with multiple user classes) “vertically” in “levels”.
All procedures for multiple time periods described herein assume that all time-
period matrices are “blocked”.
MXKK – INCREMENTAL LOGIT DEMAND MODEL

The general matrix manipulation program MX has had an ex tra set of demand
calculations added in order to calculate the period-specific trip matrices via
equation (1) given three input stacked matrices representing S ijt , C0 ijt and C ijt plus
the β parameter. Note that this is the only demand calculation available when the
input matrices are stacked as blocks.
A special bat file MXKK.BAT has also been created to carry out these calculations
automatically.
SATCOST – MULTIPLE TIME PERIOD MINIMUM COST MATRICES

A .uft file from SATSUMA contains network data for multiple time periods; we may
produce a single stacked matrix of minimum o-d costs by time period by using a
new option (#19) within the tree building sub-menu of SATLOOK (#14). A new bat
file SATCOST does this automatically to produce a single “blocked” cost matrix for
each time slice.
SATKK
SATKK is an en tirely new SATURN program which carries out an optimum
combination of two sets of multiple time period matrices plus assigned networks in
order to produce a ne w averaged trip matrix which (in combination with the
averaged link flows which are not explicitly output) minimizes the objective
function. Thus it is doing a l ine search to find an optimum lambda value in the
range 0 to 1.
The output from SATKK includes a set of convergence statistics which compare:
(a) the matrices and (b) the link flows for each time period using a range of basic
statistics. These are included both in the “main” line printer file .LPK as well as in
a “mini” line printer file .MLP which, as we shall see below, is automatically
displayed on screen by the SATTPKK macro bat file.
BETA_T
KK’s incremental logit formulae require a parameter β which represents the
sensitivity of trip makers to relative changes in costs. In SATURN β will be
represented (when required) by the parameter name BETA_T.
Beta is needed by both MXKK and SATKK. Since the latter program uses network
files it is possible to set BETA_T as a namelist parameter input under &PARAM in
5109341 / Mar 13 V-5

11_2_05_App V.docx
the original network .dat files and thence passed through the ufs/uft files, although
it may also be set within SATKK itself. In general it is best to set it once and for all
within the .dat files.
However with MXKK which operates only with matrices there is no provision to set
and transfer such a parameter and therefore BETA_T needs to be set each time
MXKK is run; thus it is included as a command line parameter.
A SINGLE LOOP OF KK’S INCREMENTAL LOGIT ALGORITHM

We consider here how, using the various “tools” described above, we may carry
out a s ingle loop of the iterative algorithm described in 1.3 to solve for the
equilibrium trip matrices. Thus, at the end of the nth loop, we will have a best
current estimate T(n) ijt of the time-period specific trip matrices – how do we
progress to T(n+1) ijt ?
The steps are shown diagrammatically below and explained in detail further down.
1) SATTPX: Assign the current matrices over all time periods to produce link
flows V at and costs C at by time period.
2) SATCOST: Use the time period specific costs to calculate minimum cost o-d
matrices by time period.
3) MXKK: Calculate the equilibrium trip demands by time period given the
latest minimum o-d costs.
5109341 / Mar 13 V-6

11_2_05_App V.docx
4) SATTPX: Assign the "target" trip matrices F ijt over all time periods to
produce new "target" link flows W at (n) (N.B. the costs at W at are not needed).
5) SATKK: Calculate the optimum combination of the previous and t he target
matrices T ijt (n) and F ijt (n) to produce the next trip matrix. N .B. The
corresponding sets of link flows are also needed in these calculations.
THE SATTPKK BATCH FILE

The five distinct steps in the above procedure may be carried out manually using
separate bat files at each step or, much more conveniently, all five may be
bundled into one "macro" bat file. Thus SATTPKK (SATurn Time Period à la KK)
has been created with the following “command line structure:
Call: SATTPKK network trips NTP BETAT Tijnew
Files:
network.DAT Base network data file
trips.UFM Current trip matrix file to be assigned
NTP Number of time periods (GE 2, LE 9)
BETAT Beta parameter in the logit model
Tijnew.UFM Output "optimum" trip matrix file
network.UFT Output SATURN UFT file from SATSUMA
TIJ0.UFM Base trip matrix (filename fixed)
CIJ0.UFM Base cost matrix (filename fixed)
MULTIPLE LOOPS
A “full” solution of the combined time period choice assignment model will require
running SATTPKK repeatedly until convergence is (hopefully – see below)
obtained.
SATTPKK NET T1 3 0.003 T2
SATTPKK NET T2 3 0.003 T3
…
where the “first” trip matrix T1.UFM would normally be eq uated to the base trip
matrix TIJ0.UFM.
N.B. We have chosen 3 time periods and a be ta value of 0.003 purely arbitrarily
above.
Note that at the end of the procedure we would need to carry out one more full
assignment with the “final” trip matrix in order to obtain the final link flows, etc. via:
SATTPX NET Tn 3
5109341 / Mar 13 V-7

11_2_05_App V.docx
CONVERGENCE ISSUES
The procedures implied by the batch file SATTPKK are based on the joint strategy
of (a) calculating a new set of trip matrices based on t he current minimum o-d
costs and (b) re-assigning them using a full equilibrium assignment. While an
intuitively attractive strategy and one that progresses “most of the time” it is
unfortunately not necessarily guaranteed convergent; in other words at a certain
point it may be become “stuck” in the sense that SATKK generates an optimum
combination lambda parameter equal to zero.
The theoretical reasons for this potential non-convergence are now well
understood and appl y equal well to other forms of joint assignment-demand
models. E qually the correct solution is well understood and c onsists of (a)
calculating the new set of trip matrices based on the average o-d costs and (b) re-
assigning them to the existing paths and in the same proportions. This
guarantees a descent direction which, in terms of SATKK, translates into a non-
zero optimum value of lambda.
Unfortunately the necessary algorithmic steps within SATURN have yet to be
established in, e.g., a user-friendly set of procedures as per SATTPKK although
they could be carried out in a somewhat sledge-hammer approach whereby each
individual time slice would have to be treated individually.
5109341 / Mar 13 V-8

11_2_05_App V.docx
V.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App V.doc
5109341 / Mar 13 V-9

11_2_05_App V.docx
Appendix W - Additional MX-based Procedures
W. Additional MX-based Procedures

W.1 M3: Matrix Compression
N.B. M3 provides a similar but more limited functionality to M5 (see Appendix
W.3) and is included here primarily for historical continuity. Users are therefore
advised to use M5 instead.
RECORD 0 - Namelist &PARAM with one logical parameter:
AVER T - Average the elements in the compressed matrix - see note 2 below
F - Add the compressed matrix elements
Default: F
RECORDS 1. ZONAL COMPRESSION RECORDS FORMAT (16I5)
These give the (sequential) district numbers corresponding to each (sequential)
zone number in strict order of sequential zones where a “district” is defined as an
aggregate of the current “zones”.
Cols. 1-5 District in which zone 1 lies

Cols. 6 - 10 District in which zone 2 lies
etc. up to Cols. 76-80, continuing on subsequent records as necessary.

N.B. A district number must be given for every zone; hence the number of records
required for the compression cards depends on the size of the input matrix.
RECORD 2. MATRIX TITLE CARD
COLS. 1 - 76 A title for the output UFM matrix
Notes:
1) Checks are made that every zone is assigned a new and valid district and
that the new district numbers are continuous, i.e., there are no gaps.
2) If AVER = .TRUE. the element (I,J) in the output (compressed) matrix
equals the average value of all those elements in the original matrix cells
corresponding to (I,J); otherwise it is the sum of these elements.
3) Note that all input refers to sequential numbers rather than external names.
Hence the district ‘names’ are by default the same as their sequential
numbers. If inconvenient the program could be changed fairly easily but
users are reminded that the same operation may be carried out with external
names using the M5 option, Appendix W.3 (although the input may be
slightly more laborious).
5109341 / Mar 13 W-1

11_2_05_App W.docx
W.2 M4: Matrix Reduction

N.B. M4 provides a similar but more limited functionality to M5 (see Appendix
W.3) and is included here primarily for historical continuity. Users are therefore
advised to use M5 instead.
RECORDS 1. NAMELIST PARAMETERS (&PARAM)
ALLOS LOGICAL F T - Include all origins or rows in the
reduced matrix (but reduce the
columns)
ALLDS LOGICAL F T- Include all destinations or columns
in the reduced matrix (but reduce the
rows)
NAMES LOGICAL F T - Zone names as opposed to zone
numbers are used for Records 2
below.
INCLUD LOGICAL T T - The zones listed on Records 3
below are those to be INCLUDED in
the new matrix.
F - They are to be EXCLUDED.
NINTC INTEGER 0 The number of zones to be included
in Records 2.
RECORDS 2. ZONAL SUBSET RECORDS (FORMAT 15I5)

These give the zones (either in terms of their names or sequential numbers
depending on the value specified for NAMES) to be retained in the reduced matrix
if INCLUD =T or to be removed if INCLUD = F.
Cols. 1-5 First zone

Cols. 6 - 10 Second zone etc. up to cols. 71 to 75 and continuing on
subsequent records for all NINTC zones.
RECORD 3. MATRIX TITLE RECORD
Cols 1 - 76 A title for the UFM matrix

Notes:
1) This option only works for reducing a “square” matrix; i.e., one in which the
number of rows and columns are equal.
2) However the output matrix need not be square - we can reduce either the
number of rows or columns while leaving the other dimension as in the full
matrix by the choice of the parameter ALLOS and ALLDS. Normally
however both are left as false and the matrix is reduced in both dimensions.
5109341 / Mar 13 W-2

11_2_05_App W.docx
W.3 M5: Matrix Compression, Expansion and Re-coding

The M5 procedures for matrix “zone editing” (compression, expansion and/or re-
coding) manipulation may be run using the batch file MXM5 (See 10.16 and
10.20.20.). See Section 10.4.1 for the interactive steps equivalent to M5.
RECORDS 1. NAMELIST PARAMETERS (&PARAM)
PARAMETER TYPE DEFAULT INTERPRETATION
INCLUD LOGICAL T T – Those zones NOT explicitly mentioned
on zonal correspondence records below
remain as they are on the output matrix
F – Those not mentioned are excluded
CSV LOGICAL F T – Records 2 below are in comma
separated variables, i.e. free format
F – They are formatted
RANDC LOGICAL F T – Both row and column (origin and
destination) factors are included. (Added
22/10/11). See Note 11 below.
DEFROW REAL 0.0 Default value for all row elements for a
newly created zone
DEFCOL REAL 0.0 Ditto column …
DEFINT REAL 0.0 … and intra-zonal values
M5ZERO LOGICAL F If T then all intra-zonal cells for newly
created zones must be zero; see note 4.
IROCKY INTEGER 0 If > 0 then the program compresses each
zone in the input matrix by dividing its name
by IROCKY – see note 9 below.
NBASE INTEGER 1 Used in conjunction with IROCKY to set new
zone numbers; see note 9.
RECORDS 2. ZONAL CORRESPONDENCE RECORDS (Mandatory unless

IROCKY > 0)
These records are either formatted (FORMAT (I5, 5(I5, F5.2)); see below) or free
format depending on CSV = F or T respectively. Free format may be used, for
example, if zone numbers have more than 5 digits or the factors do not
conveniently fit into 5 columns.
Each record gives for zone names in the old matrix the corresponding zone
names in the new matrix, plus – if RANDC = F - the fraction of the old zone
contained in the new which will be used to factor both rows and columns. (N.B.,
sequential numbers are not used at all in inputs to M5.) See note 11) below for the
extra data required for RANDC = T.
N.B. The input records must be in increasing order of old zone numbers,
otherwise the data file is rejected.
5109341 / Mar 13 W-3

11_2_05_App W.docx
Up to 5 new zones may be defined per record; if more than 5 new zones are
required further records may be included with the old zone number repeated in
columns 1-5. (N.B. records referring to the same zone MUST be sequential.)
Totally new zones may also be added in the output matrix, in which case the “old
zone” entry is blank and all new cell elements must be zero.
Cols. 1–5 The name of the old zone (Zero or blank for a totally new
zone defined in columns 6-10).
Cols. 6 – 10 The first new zone name corresponding to this zone (Zero or
blank if the old zone in columns 1-5 is to be removed)
Cols. 11 – 15 The fraction of the old zone lying in the new (with, by default,
a decimal point in col. 13, F5.2; but see 2.8.3 for alternative
decimal places.)
(If omitted (i.e., blank) a value of 1.0 is assumed.)
Cols. 16 – 20 The second new zone (if any)
Cols. 21 – 25 The fraction in the second zone
(decimal in col. 23)
Etc. etc. up to a maximum fifth new zone in cols. 46 to 55.

RECORD 3 (Mandatory)
A ‘99999’ or a blank record to indicate the end of the zonal correspondence
records. (99999 recommended!)
RECORD 4. MATRIX TITLE (Mandatory)
Cols. 1 - 76 The title record for the matrix

NOTES:
1) Zones are compressed when more than one (or, strictly, fractions of more
than one) are compressed into larger zones (referred to as districts) in the
output matrix. Expansion on the other hand occurs when 1 zone in the old
matrix is sub-divided into 2 or more “sub-zones” in the output matrix. Re-
coding occurs when the zone remains the same but its name is changed.
2) The fractions defined as part of records 3 define whether the zone is to be
compressed, expanded or recoded. Thus a zone which is being either
compressed or recoded should have a fraction equal to 1.0 since all of that
zone goes into the new zone. On the other hand a zone which is being
expanded will have more than one new sub-zone corresponding to it and
fractions of less than 1.0. (Logically the sum of the fractions for one zone
should be 1.0 but no check is made.)
Logically all the fractions defined should be greater than zero, otherwise the
old zone is not really contributing to the new zone(s). There is, however, one
5109341 / Mar 13 W-4

11_2_05_App W.docx
exception which is that a zone may be copied into itself with a fraction of 0.0,
the end effect being that the old zone is retained in the new system but with
all zero cells (unless, of course, another zone is being copied into it at the
same time),
3) If INCLUD is TRUE all zones NOT specifically mentioned on the
correspondence records are retained in the same form on the output matrix.
If INCLUD is FALSE it is assumed that any zones not explicitly mentioned
are to be removed or deleted from the output matrix.
4) The elements in the output matrix are derived from the input elements as
follows.
Tij2 = ∑ Tkl1 Fki Flj

k ,1
where
T2 ij is the output matrix element i,j on channel 2;
T1 ij is the input matrix element i,j on channel 1; and
F ki is the fraction of old zone k in new zone i as given on the zonal
correspondence records.
For example if the matrix elements are O-D trips which are being divided
into a finer zoning system then trips from one sub-zone to another equal the
zone-to-zone trips factored down by both an origin factor and a destination
factor. Provided that the fractions given for each zone add up to 1.0 the
sum of the matrix elements in the new matrix should equal the sum of the
old.
The one exception to the above equation is that if M5ZERO = T then all
intra-zonal cells for new cells are set to zero. (Since, even if all old intra-
zonal cells were zero, if the new zone is an aggregation of several old zones
its intra-zonal value may be the sum of several previous non-zero inter-
zonal cells.)
5) If the old zone in columns 1-5 is NEGATIVE then it is assumed that ALL
zones from the previous entry up to and including the current (negative)
zone are treated in the same way. E.g.,
50 7 1.0
-100
implies that all zones from 50 through 100 are mapped into the new
zone 7.
6) If columns 1 to 5 are blank - implying that a totally new zone is to be defined
- then only columns 6 to 10, the name of the new zone are processed. Thus
each new zone is contained in columns 6 to 10 on separate records. These
may be in any order. The cell values used for any newly created zones are:
(a) DEFROW along its row(s), (b) DEFCOL along its column(s) and (c)
DEFINT for its intra-zonal cell.
5109341 / Mar 13 W-5

11_2_05_App W.docx
7) Similarly if columns 6 to 10 are blank then the old zone referenced in

columns 1 to 5 is deleted. (New option in 10.7.)
8) An old zone is also deleted if it appears in columns 1-5 but does not appear
as one of the “new” zones on that record. For example, a record “ A B 1.0”
would imply that a new zone B is to be created exactly equal to A and that A
no longer exists. On the other hand “A B 1.0 A 1.0” would imply that not only
is a new zone B created – a direct copy of A – but A is also retained.
Similarly “A B 0.5 A 0.5” would imply that zone A is being split in two with
one half now taking the name B.
9) The “IROCKY” option enables matrix aggregation to be defined in an
extremely simple mode. It is based on the concept of defining zone names
using a “hierarchical” numbering system, such that a zone 6805 would by
definition be within sector 6, traffic borough 68 and district 680(where the
designation sector/borough/district is of course arbitrary). Thus if IROCKY
>0 the new zone names are related to the old names via the formula.
NEW = NBASE + INT (OLD/IROCKY)
where INT ( ) denotes taking the integral value rounding down. Thus if
NBASE = 0 and IROCKY = 1000 then zone 6805 becomes 6.
Note that when NBASE = 0 (which, for historical reasons, is NOT the
default) then IROCKY here is identical to its use in network .dat files to
define sectors from zones; see 6.3.2, 6.8 and 5.1.7.
10) Note that in their simplest form Records 2 may also be used to convert
“zones” into “sectors” whereby each record contains just two numbers, the
zone number followed by its “new zone” number or, in effect, its sector. The
same format is used in the “.Z2S” text files used to define sectors per zone;
see 10.2.5 and 10.5.1.
11) If (post October 2011, release 11.1.3) the Namelist parameter RANDC is set
to T then the weighting factors which are applied to convert old zones into
new zones differ between rows (i.e., origins) and columns (i.e.,
destinations). The column-specific factors are input along with the row-
specific factors in Records 2 above. Specifically each row factor is followed
by a column factor, either separated by a column under CSV or in a
separate 5-column field under fixed format. Thus, in the latter case, the new
zone numbers appear in column fields 6-10, 21-25, 36-50, etc. etc.
(FORMAT (I5, 5(I5, 2F5.2));
An example of an M5 input file is given below with comment lines included:
&PARAM
&END
* Add 2 new zones 9908 and 9909 which will be zero in both row sand
columns
9908
9909
5109341 / Mar 13 W-6

11_2_05_App W.docx
* Renumber zones 9905, 9906 and 9907 to be 9900, 9901 and 9101
respectively
9905 9900 1.00
9906 9901 1.00
9907 9101 1.00
99999
Removing Penlink and adding Busway zones (New matrix title)
W.4 MX-Based M1 to M7 .BAT files

We list here the specifications for a series of dos bat files which may be used to
replicate the functions of the former SATURN programs M1 to M7 (but not M3, M4
or M6) using the program MX plus specifically created command files. Generally
speaking the format of these bat files follows that of the equivalent M1 etc. bat
files. However the format of the necessary input control files may be slightly
different from former specifications in order to follow the equivalent specifications
required by MX.
Call: MXM1 mat
Build a UFM matrix file from a standard dat file (and no other M1
Function:
functions)
Files: mat.DAT - Input matrix data file; see 10.5.1.
mat.UFM - Output UFM matrix file
mat.LP1 - Output line printer file
Call: MXM2 mat1 mat2
Function: Compare two UFM matrix files
Files: mat1.UFM - First input UFM matrix file.
mat2.UFM - Second input UFM matrix file.
mat1.LP2 - Output line printer file.
Call: MXM5 mat1 mat2 kr

Function: Matrix Compression, Expansion and/or Recoding
Files: mat1.UFM Input UFM matrix file.
mat2.UFM - Output UFM matrix file.
kr.DAT - Input card reader control file; see W.3 (Mandatory)
Call: MXM7 mat1 mat2
Function: Matrix transposition
Files: mat1.UFM - Input UFM matrix file.
5109341 / Mar 13 W-7

11_2_05_App W.docx
mat2.UFM - Output (transposed) UFM matrix file.

5109341 / Mar 13 W-8

11_2_05_App W.docx
W.5 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App W.doc
3 Upgrade to V2 Template DVV IW DVV IW DVV
3.1 W.3 / M5 updated DVV 03/07/06
5109341 / Mar 13 W-9

11_2_05_App W.docx
Appendix X - Unused
X. Unused
X.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App X.doc
3 Upgrade to V2 Template DVV IW DVV IW DVV
5109341 / Mar 13 X-1

11_2_05_App X.docx
Appendix Y – The SAT10KEY DAT File
Y. The SAT10KEY DAT File

Each version of SATURN comes with a unique version of a special file,
SAT10KEY.DAT, which, in versions prior to 10.2, was titled SAT95KEY.DAT and,
prior to 9.3, was SATKEY.DAT. In its original and most basic form it contains the
name of the licensed organisation and a site-specific code, the latter (fiendishly
clever!) device fools all those nasty software pirates. Without a (correct) version
of SAT10KEY.DAT, no SATURN programs can execute.
With version 9.2 an option was introduced to allow users to extend the file in order
to include a set of namelist-based parameters which define options or facilities
specific to that particular user. For example you can define the maximum number
of lines to appear on terminal screens - otherwise this is a universal constant. A
full description of the parameters which may be set is given below.
Note that: (a) it is not necessary to modify your (as supplied) version of
SAT10KEY.DAT - the default values are precisely what you had before; and (b) if
you do, be very careful not to alter the first two lines since, if you do, nothing will
work.
The formal specification of the namelist component is as follows:
NAMELIST: &PARAM
INTEGER VARIABLES
LPERT Maximum number of lines on terminal screen. Default: 22

LPERP Maximum number of lines on line printer output. Default: 60
LOGICAL VARIABLES
LEFTDR If .TRUE. then left hand drive is assumed as default throughout

(but may be over-ridden, e.g. in SATNET, 6.3.1) Default: .TRUE.
ADDAL If .TRUE. an extra line is added to all window select boxes in order
to avoid an unnecessary scroll bar. Default: .TRUE.
GO4IT If TRUE. the files created within SATURN programs may over-
write existing files without user confirmation. E.g., see 4.5.9.
Default: .TRUE.
CHARACTER VARIABLES
HPREF Pathname “prefix” used to define a complete pathname for .hlp

files. Default: blank
CPREF Pathname “prefix” used to define a complete pathname for
preferences or “Control” .dat files. (Equivalent to the Control Folder
under SATWIN) Default: blank
KPREF Pathname “prefix” used to define a complete pathname for .key
files. Default: blank
5109341 / Mar 13 Y-1

11_2_05_App Y.docx
KPEXT Default (3-character) extension to be used for output ascii files.

Default: ‘KP ’
DRIVE The one-character letter specifying the computer drive where the
programs, data etc are stored. Default: ‘C’
Thus a sample file might read:

User name
Code
&PARAM
LPERT = 25,
HPREF = ‘C:\SATURN\HELP\’
&END
This would imply 25 lines of terminal output between pauses and that the full
pathname of the help file for, say, SATED would be:
C:\SATURN\HELP\SATED.HLP.
Note that certain of these parameters may be also contained with individual
program Preferences Files (15.2) and that therefore the values set in
SAT10KEY.DAT may be over-written by values set in the Preferences File. For
example, KPEXT is also contained in MX0.DAT, P1X0.DAT, SATDB0.DAT and
SATLOOK0.DAT. Similarly GO4IT is also included in the same 4 Preferences
Files.
WARNING! Some care must be exercised by users as to which folder the file
SAT10KEY.DAT appears in, particularly if they wish to make changes therein.
Thus, under normal install procedures, SAT10KEY.DAT should be located in a
folder …\satwin\xexes and SATURN programs would look there first. However, if
they do not find it there they do not give up – Oh No! – they look in several likely
alternative locations. In order to determine exactly which location a program is
reading SAT10KEY from consult the relevant .LP file very near the top; the full
pathname should appear there. Clearly that is the location of the file that should
be modified.
Users should also beware of SATURN programs accidentally picking up “wrong”
versions of SAT10KEY.DAT, e.g., older versions from previous installations which
contain misleading parameter values.
5109341 / Mar 13 Y-2

11_2_05_App Y.docx
Y.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App Y.doc
3.4.1 V10.7.10 KPEXT clarified DVV NP IW IW 27/04/07
3.6 SATURN V10.8 Release DVV NP IW IW 09/02/08
10.9.10 SATURN V10.9 Release DVV NP IW IW 04/09/09
10.9.12 SATURN V10.9 Release (Full) DVV NP IW IW 22/10/09
5109341 / Mar 13 Y-3

11_2_05_App Y.docx
Appendix Z - GIS File Specification
Z. GIS File Specification

We define here the precise format conventions as used by GIS files within
SATURN. They have a similar structure to other SATURN data files whereby
blocks of data are identified by an opening record such as 11111, 2222 etc. and
are terminated by a 99999 record. Blocks must appear in numerical order and are
terminated by a final 99999 record.
In addition a GIS file should contain a title on the very first record followed by an
optional and very short set of namelist parameters prior to the first set of 11111,
etc. records.
It is furthermore assumed that the standard filename “extension” is “gis”, e.g.,
network.gis. (See Section 3.3.)
In general, because most GIS files are likely to be generated interactively in P1X,
users need not be too concerned about the specific formats used. They are
supplied below for completeness and to enable, for instance, the reformatting of
externally generated (digitised) data.
RECORD 0.1 - Title
Cols 1 - 28 A text record containing an (arbitrary) file title
RECORD 0.2 - NAMELIST PARAMETERS (Optional)
These consist of a header record &PARAM, one or more records defining the
following parameters which are only relevant to the node co-ordinate data section
(BLOCK 8 below) and have the same standard interpretation as used in network
.dat files plus an &END record.
DUTCH If TRUE node numbers may have up to 8 digits. Default - .FALSE.

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 does not apply.
XYFORM The “format” used to define node X, Y co-ordinates under the
55555 data records - see Section 6.8. Default - ‘215’
BLOCK 1 - ENCLOSED POLYGONS

These records define a set of “corner” point co-ordinates which define an
enclosed polygon. They need not constitute a “closed” set in the sense that the
final point need not equal the first; hence the final edge joins the first and last
corners.
Record 1.1
Cols 1 5 11111
Record 1.2.1 Start of a new polygon (FORMAT (2F10.2, 3I5, 3X, A12)
Cols 1 - 10 X coordinate of the first “corner” (decimal point in col. 8)
5109341 / Mar 13 Z-1

11_2_05_App Z.docx
Cols 11- 20 Y coordinate of the first “corner” (decimal point in col. 18)
Cols 21- 25 Pen colour (in range 1 to 16)
Cols 26- 30 A non-zero if the area is to be “in-filled”
Cols 31- 35 An equivalent zone number if the area represents a zonal
boundary (N.B. use the zone “name” as opposed to its “sequential
number”.)
Cols 36- 40 Line width in mm. (Real – decimal place in col. 39)
Cols 41 - 60 An alphanumeric title for the area (as yet not used)
Record 1.2.2 Co-ordinates of the polygon’s next (up to) 4 “corners”:
Cols 1- 10 X coordinate of the next+1 “corner” (decimal in col. 8)

Cols 11- 20 Y coordinate of the next+1 “corner” (decimal in col. 18)
Cols 31- 40 Y coordinate of the next+2 “corner” (decimal in col. 38) etc.
where a polygon is terminated either by the next 20 columns for (X,Y) being blank
or, if the final corner is the 4th on a record, by a blank record following. A new
polygon commences on the next record (1.2.1) or is terminated by:
Record 1.3 End of Polygons
Cols 1- 5 99999
BLOCK 2 - POLYLINES
These records define a set of “points” making up a “polyline”. They may be
plotted either as a line joining successive points or as a “bandwidth” joining those
points. The latter might be used to represent a river.
Record 2.1
Cols 1- 5 22222
Record 2.2.1 Start of a new polyline (FORMAT (2F10.2, 2I5, A1)
Cols 1- 10 X coordinate of the first “corner” (decimal in col. 8)

Cols 11- 20 Y coordinate of the first “corner” (decimal in col. 18)
Cols 26- 30 The (integer) line width in millimetres “on the screen” if col. 31 is
blank
OR
The (integer) line width in metres “on the ground” if col. 31 is ‘G’
(In either case 0 or blank for a line)
5109341 / Mar 13 Z-2

11_2_05_App Z.docx
Col 31 ‘G’ or blank
Record 2.2.2 Co-ordinates of the next (up to) 4 “corners”:
Cols 1- 10 X coordinate of the second “corner” (decimal in col. 8)

Cols 11- 20 Y coordinate of the second “corner” (decimal in col. 18)
Cols 31- 40 Y coordinate of the next+2 “corner” (decimal in col. 38) etc.
where the polyline is terminated either by the next 20 columns for (X,Y) being
blank or, if the final corner is the 4th on a record, by a blank record following. A
new line then commences on the next record (2.2.1) or is terminated by:
Record 2.3 End of polylines
Cols 1- 5 99999
BLOCK 3 - IKONS
These records define a set of “ikons” and their co-ordinates, where an “ikon” is
one of a standard set given below.
Record 3.1
Cols 1- 5 33333
Record 3.2.1 (FORMAT (2F10.2, I5, F5.0, I5)
Cols 1- 10 X coordinate (decimal in col. 8)

Cols 11- 20 Y coordinate (decimal in col. 18)
Cols 26- 30 Ikon height in millimetres “on the screen” (no decimal)
Cols 31- 35 Ikon number representing:
1 - a monopoly-style house
2 - a BR symbol
3 - a car park
4 - a church
5 - a hospital
6 – a Tetley pub
7 – a square box with a letter inside (see col. 45)
8 – a LT logo
9 – a regular n-sided shape
5109341 / Mar 13 Z-3

11_2_05_App Z.docx
Cols 36- 40 Background pen colour for ikon 7 (in range 1 to 16)
Col 45 The letter used in ikon 7 (text)
Record 3.2.2 As 3.2.1 for the next ikon

etc., etc. until terminated by:
Record 3.3
Cols 1- 5 99999
BLOCK 4 - TEXT
These records define a set of co-ordinates and of text to appear centred at those
points
Record 4.1
Cols 1- 5 44444
Record 4.2.1 (FORMAT (2F10.2, 2I5, 2X, A28)
Cols 2- 10 X coordinate of the centre of the text (decimal in col. 8)

Cols 11- 20 Y coordinate of the centre of the text (decimal in col. 18)
Cols 26- 30 Character height in millimetres (no decimal)
Cols 33- 60 Text (left justified)
Record 4.2.2 As 4.2.1 for second text entry

Record 4.3
Cols 1- 5 99999
BLOCK 5 - NODE NAMES

These records define a set of alpha-numeric names to be associated with nodes
and/or zones.
Record 5.1
Cols 1- 5 55555
Record 5.2 (FORMAT (A1, I9, 2X, A28)
Cols 1 A ‘C’ for a zone to follow

Cols 2- 10 Node/zone name (numerical value)
Cols 13- 40 Its name in characters
5109341 / Mar 13 Z-4

11_2_05_App Z.docx
Record 5.3
Cols 1- 5 99999
BLOCK 6 - LINK NAMES

These records define a set of alpha-numeric names to be associated with those
links along routes defined by a set of nodes.
Record 6.1
Cols 1- 5 66666
Record 6.2 (FORMAT (A12, 3X, A65)
Cols 1- 12 A road name in characters (e.g., M1)

Cols 15- 80 A set of nodes through which the road passes such that nodes
which are not connected are “interpolated”. The format is “free”.
Record 6.3
Cols 1- 5 99999
BLOCK 7 - CO-ORDINATES OF CURVED LINKS

These records define a set of co-ordinates for links which may (optionally) be
plotted as a set of “poly lines” (i.e. approximating to a curve) through a set of
intermediate points rather than as a straight line or as part of an arc from a circle
(in which case the user needs to input the centre of curvature of the circle rather
than discrete points along the arc).
Record 7.1
Cols 1- 5 77777
Record 7.2.1 Link Identifier (FORMAT 2I10)
Cols 1- 10 Link A-node

Cols 11- 20 Link B-node (Negative for an arc; see below)
Record 7.2.2: Co-ordinates of the intermediate points:
Cols 2- 10 X coordinate of the next+1 point (decimal in col. 8)

Cols 11- 20 Y coordinate of the next+1 point (decimal in col. 18)
Cols 21- 30 X coordinate of the next+2 point (decimal in col. 28) etc.
where the points are terminated either by the next 20 columns for (X,Y) being
blank or, if the final point is the 4th on a record, by a blank record following. A
new line then commences on the next record (7.2.1) or is terminated by:
5109341 / Mar 13 Z-5

11_2_05_App Z.docx
Record 7.3
Cols 1- 5 99999
N.B. With version 10.6 it is no longer necessary to include a blank record if, as
noted above, the number of X,Y points is a multiple of 4. The program scans the
following line and, if it contains a valid A-node and B-node in columns 1-20, the
assumption is that this must be the start of a new link record and the previous set
of curved points is terminated. Data using the older convention is still of course
acceptable.
ARCS RATHER THAN POLYLINES

To define the link to have the shape of an arc of a circle the user must:
a) set the link B-node negative
b) set the co-ordinates of the centre of the circle as the (only) two values
on the next record (7.2.2)
Notes:
If a link is entered twice within the 77777 records (including one entry as (A,B) and
a second as (B,A)) then the first is ignored and a warning message generated.
BLOCK 8 - NODE CO-ORDINATES

These records define the co-ordinates of nodes and/or zones. They follow
precisely the rules used to define the equivalent data section in network data files
- see Section 6.8 - with the one difference being that here the data follows a
88888 header whereas in .dat files they are 55555. Thus for zones sector
definitions may also be included. The namelist parameters DUTCH, IROCKY and
XYFORM above are relevant to this data set.
Record 8.1
Cols 1- 5 88888
Record 8.2 Identical to the ‘55555’ records as input to SATNET

Record 8.3
Cols 1 - 5 99999
RECORD 9 FINAL “END OF FILE” RECORD
Cols 1- 5 99999
5109341 / Mar 13 Z-6

11_2_05_App Z.docx
Z.1 Version Control
JOB NUMBER: 5109341 DOCUMENT REF: App Z.doc
5109341 / Mar 13 Z-7

11_2_05_App Z.docx

SATURN v11.2.05 Manual (All)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SATURN v11.2.05 Manual (All)

Uploaded by

Copyright:

Available Formats

Simulation and

Manual - Version 11.2

5.6 Building Networks: The Beginner's Guide 5-22

8.7 Modelling Roundabouts 8-41

5109341 / Mar 13 iii

11. P1X: Interactive Analysis of Results 11-1

14.4 Extended SATURN Procedures 14-7

15.36 Turning Flows at Buffer Nodes 15-88

17.11 Formulae for Calculating Totals 17-6

5109341 / Mar 13 vii

21.6 Additional OBA Output Files 21-7

5109341 / Mar 13 viii

5109341 / Mar 13 1-1

Releases of “major” updates to SATURN occur on a r oughly annual basis (see

5109341 / Mar 13 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

5109341 / Mar 13 1-3

high-speed machines are recommended). A typical lower-range specification for

1.2.1 64-bit Operating Systems

5109341 / Mar 13 1-4

We will continue to explore the migration of the computational intensive elements

1.4 Distribution of SATURN

5109341 / Mar 13 1-5

1.5 Contents of the Suite

5109341 / Mar 13 1-6

1.6 Version Control

JOB NUMBER: 5109341 DOCUMENT REF : Section 1.doc

Revision Purpose / Description

Originated Checked Reviewed Authorised Date

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

3 Upgrade to V2 Template IW 22/06/06

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

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

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

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

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

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

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

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

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

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

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

10.9.22 Web release – Dec 10 DVV AG IW IW 06/12/10

10.9.24 SATURN v10.9 Release (Full) DVV 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. Release (Full) DVV JS IW IW 17/03/13

5109341 / Mar 13 1-7

The SATURN Suite – An Overview

2. The SATURN Suite – An Overview