SATURN MANUAL (V10.
9)
Creating an O-D Matrix File
4. Creating an O-D Matrix File
Trip matrices used in SATURN are held as unformatted binary “UFM” files
(10.2.1), i.e., their standard filename extension is UFM. For example the input trip
matrix in Figure 3.1 is a UFM file. A comprehensive matrix manipulation program
MX is included with SATURN and is described in Section 10; full documentation
on matrices is given there.
The UFM trip matrix file may be created in a number of different ways; for example
using a wide range of input data formats from ascii/text files to MX as described in
Section 10.5, or using SATME2 as described in Section 13 to create it from
observed link flows. The “traditional” method using MX ascii input is described
next.
4.1 Trip Matrices using M1 or MXM1
This section describes the simplest procedure to create a trip matrix, illustrated in
Figure 4.1 below, based on an input ascii “.DAT” file with complete O-D data plus
certain other information to MX via the command:
MXM1 trips
or (more simply): M1 trips
where MXM1 or M1 are simply .bat files which run the program MX in a particular
way. (Previously M1 was a separate program.)
By default the extension of the input file is assumed to be “.dat”; i.e., in the above
example the input file would be trips.dat as illustrated in Figure 4.1. However it is
possible to use other extensions (the modern trend would be to use .txt) by
commands such as:
MXM1 trips.txt
The ASCII file (TRIPS.DAT etc.) is formatted (see 10.5.1) as zone-to-zone flows
ordered (as is usual) first by origin and second by destination. However preceding
this data are four (sets of) header records:
1) RUN runname
2) &PARAM NROWS=nc,NCOLS=nc,MPNEXT=T, &END
3) TRIPS PCUH
4) matrixname
5101396 / May 11 4-1
10_09_24_Section 4.doc
SATURN MANUAL (V10.9)
Creating an O-D Matrix File
Figure 4.1 - Obtaining a .UFM Trip Matrix from a .DAT file
TRIPS.DAT
M1
TRIPS.UFM
Note:
Capital letters above denote mandatory input; lower case letters denote
inputs which must be chosen by the user.
Record (1) begins in col 1; runname should be chosen by the user and
begins in column 5.
Record (2) is an example of an input record which uses the “Namelist”
facility to explicitly define certain variable values by name; see Appendix A.
“nc” is the number of zones in the network. This record may be divided up
into several lines rather than 1; see the example below.
Record (3) must begin in col. 1 and have three blanks between the S and
the P. This record defines the matrix as a trip matrix in units of pcus per
hour.
Record (4) begins in col 1; “matrixname” should be chosen by the user.
Full details of the above “standard” format are given in Section 10.5.1,
although certain alternative formats, described in 4.4 below, were introduced
in SATURN 10.6.
Following the header records, each individual cell in the O-D matrix is given (by
default – see below) with up to 15 entries on each record in cols 1-5, 6-10, ...., 71-
75. (Fortran format 15I5). A new record is begun for each origin. The first entry
for each new origin, i.e., cols. 1 to 5 on the first record, contains the “name” of that
zone, followed by nc entries for trips to destinations 1, 2, 3,..nc. Hence the first
record contains trips for up to 14 destinations, whereas subsequent records
contain up to 15 destination trips, starting in cols. 1 to 5. The origin records MUST
5101396 / May 11 4-2
10_09_24_Section 4.doc
SATURN MANUAL (V10.9)
Creating an O-D Matrix File
appear in order of increasing zone names; i.e., the lowest origin first, the second
lowest next, etc., etc.
A fuller description of what is meant by “zone names” is given in 5.1.6 and 10.2.2.
An alternative “long” format is also available under which the matrix elements are
specified as real’s; see 10.5.1 for details.
In fact virtually any input format is acceptable by the program MX using interactive
commands; see Section 10.5.2 to 10.5.6. For example, the data may be contained
in a CSV-formatted file as produced by a Windows program such as EXCEL. In
addition, post release 10.6, the “batch” procedures M1 and MXM1 will also accept
various alternatively formatted files including CSV as explained in Section 4.4.
Hence transferring matrices from other suites of programs should not constitute a
problem.
The following sample file lists the beginning of the trip file for a network with 10
zones (so that only one record per origin zone is required).
RUN SECOND SATURNVILLE O-D RUN
&PARAM
NROWS=10,
NCOLS=10,
MPNEXT=T, &END
TRIPS PCUH
SATURNVILLE O-D
1 0 0 0 0 0 0 0 0 3 3
2 3 0 0 3 0 3 0 0 3 0
3 112 5 19 6 22 24 34 6 2 0
4.2 Important Trip Matrix Definitions
Note that the trip elements are given in pcus PER HOUR, independent of the
length of time period to be simulated. In other words they are specified as a rate
and the program itself will convert them into actual numbers proportional to the
length of the time period simulated, LTP.
Note also that, strictly speaking, the matrix can be either in terms of vehicles or
pcus, although the latter is generally more realistic and highly recommended.
The important point is to ensure that all network capacities, counts, etc. etc., are
defined in similar units to the trip matrices, i.e., pcus per hour or vehicles per hour.
For simplicity all documentation refers to pcus/hr as the recommended units. See
Section 15.17.
If, therefore, a separate trip matrix representing, say, HGVs is required it is the
responsibility of the user to ensure that the matrix is suitably defined in terms of
pcus/hr, not vph. If, as is generally the case, the originally provided HGV matrix
were constructed from a survey of vehicles or a demand model based on vehicles
it is equally the responsibility of the user to decide on suitable PCU factors in
order to convert vph (i.e., HGV/hr) into pcus/hr.
5101396 / May 11 4-3
10_09_24_Section 4.doc
SATURN MANUAL (V10.9)
Creating an O-D Matrix File
4.3 Further Notes on Trip Matrices
1) In general matrix files contain a single matrix T(I,J) of trips from zone I to J
although in certain circumstances, described in greater detail in Section
7.3, it is possible to create a single “stacked” matrix file which contains
more than one trip matrix, e.g., a car and an HGV matrix, in order to carry
out Multiple User Class assignments. See 10.2.4.
2) If a series of time-dependent trip matrices is required to represent
successive time periods (using the PASSQ option, Section 17.3) and if
these matrices differ only by time-dependent factors then there are two
labour-saving options to avoid coding a separate data file for each time
period: (a) using the FACTOR options within MX to create a set of separate
UFM matrix files from one original file (10.7); or (b), using the GONZO
parameter as input to SATNET to factor the single matrix at the
assignment stage (Section 6.3).
3) GONZO is much simpler and is therefore recommended but only for
relatively simple one-off “quick’n’dirty” tests. Thus when later analyses
require an explicit matrix, e.g. for comparison purposes, or if the matrix is
to be altered in connection with elastic assignment or SATME2 (13.1.10)
then using GONZO tends to lead to confusion as to whether or nor it is
included in the output matrices. Similar considerations also apply to
cordoning (see 12.1.7).
4) An alternative method to factor the as - read trip matrix file is available
under multiple level user class assignment where a particular user class
matrix may be defined as a fraction of a “full” matrix. See 6.11. The same
caveats as expressed above with respect to GONZO apply here as well;
i.e. if the trip matrix is likely to be referred to explicitly or altered in any way
then it is best to create it with the appropriate factors in the first place.
5) In the assignments trip matrix cells less than a critical value TIJMIN (a user
definable parameter - see 6.3.3) are ignored as being irrelevant.
6) Thus any negative cells will always be ignored during the assignment,
although it is possible to over-ride this rule by setting a parameter ERTM to
.TRUE (see 6.3.1). Quite why one would want to do so I do not know and
if you do try it and find the computer crashes and erases half your hard
disk when it tries to take the square root of a negative number or whatever
then don’t blame me! A Serious Warning 172 is generated if any negative
cells are detected in a trip matrix to be assigned.
5101396 / May 11 4-4
10_09_24_Section 4.doc
SATURN MANUAL (V10.9)
Creating an O-D Matrix File
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 DVV.
5101396 / May 11 4-5
10_09_24_Section 4.doc
SATURN MANUAL (V10.9)
Creating an O-D Matrix File
4.5 Version Control
JOB NUMBER: 5101396 DOCUMENT REF: Section 4.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 28/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 26/01/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 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 05/06/11
5101396 / May 11 4-6
10_09_24_Section 4.doc
