Trip Matrices using M1 or MXM1

Important Trip Matrix Definitions

Further Notes on Trip Matrices

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

The ascii file (TRIPS.DAT) 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

1
 TRIPS.DAT
(ascii file)

M1

TRIPS.UFM
(Unformated UFM file)
Figure 4.1 - Obtaining a .UFM Trip Matrix from a .DAT file

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 formats are given in Section 10.5.1.

Following the header records, the O-D matrix is given, 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

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

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.5. 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 the matrix can be either in terms of vehicles or pcus,
although the latter is generally more realistic. The important point is to
ensure that all network capacities are defined in similar units, i.e., pcus
per hour or vehicles per hour. For simplicity all documentation refers to
pcus/hr. See Section 15.17.

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.

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

GONZO is much simpler and is therefore recommended except

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

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

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

5. Thus any negative cells will be ignored 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!
K:\….\dvv\saturn99\sect-4
Version dated: 24 November, 2018