4. Creating an Origin-Destination Matrix File

Size: px

Start display at page:

Download "4. Creating an Origin-Destination Matrix File"

Emil Murphy
6 years ago
Views:

1 4. INTRODUCTION Trip matrices used in SATURN are held as unformatted binary UFM files (10.2.1), i.e., their standard filename extension is UFM. For example the input trip matrix in Figure 3.1 is a UFM file. A comprehensive matrix manipulation program MX is included with SATURN and is described in Section 10; full documentation on matrices is given there. The UFM trip matrix file may be created in a number of different ways; for example using a wide range of input data formats from ascii/text files to MX as described in Section 10.5, or using SATME2 as described in Section 13 to create it from observed link flows. The traditional method using MX ascii input is described next. 4.1 Trip Matrices using M1 or MXM1 This section describes the simplest procedure to create a trip matrix, illustrated in Figure 4.1 below, based on an input ascii.dat file with complete O-D data plus certain other information to MX via the command: MXM1 trips or (more simply): M1 trips where MXM1 or M1 are simply.bat files which run the program MX in a particular way. (Previously M1 was a separate program.) By default the extension of the input file is assumed to be.dat ; i.e., in the above example the input file would be trips.dat as illustrated in Figure 4.1. However it is possible to use other extensions (the modern trend would be to use.txt) by commands such as: MXM1 trips.txt The ASCII file (TRIPS.DAT etc.) is formatted (see ) 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 / Mar

2 Figure 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 , although certain alternative formats, described in 4.4 below, were introduced in SATURN 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,..., (Fortran format 15I5). A new record is begun for each origin. The first entry for each new origin, i.e., cols. 1 to 5 on the first record, contains the name of that zone, followed by nc entries for trips to destinations 1, 2, 3,..nc. Hence the first record contains trips for up to 14 destinations, whereas subsequent records contain up to 15 destination trips, starting in cols. 1 to 5. The origin records MUST appear in order of increasing zone names; i.e., the lowest origin first, the second lowest next, etc., etc / Mar

3 A fuller description of what is meant by zone names is given in and An alternative long format is also available under which the matrix elements are specified as real s; see for details. In fact virtually any input format is acceptable by the program MX using interactive commands; see Section to 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 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 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 / Mar

4 4.3 Further Notes on Trip Matrices 1) In general matrix files contain a single matrix T(I,J) of trips from zone I to J although in certain circumstances, described in greater detail in Section 7.3, it is possible to create a single stacked matrix file which contains more than one trip matrix, e.g., a car and an HGV matrix, in order to carry out Multiple User Class assignments. See ) 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 laboursaving 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 ( ) 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 ). 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 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 / Mar

5 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 , 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 to 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 / Mar

6 4.5 Version Control JOB NUMBER: 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/ Web release Sept 06 DVV NP IW IW 08/09/ Web release Jan 07 DVV NP IW IW 04/01/ SATURN v10.7 Release DVV NP IW IW 12/03/ Web release Jul 07 DVV NP IW IW 19/07/ SATURN v10.8 Release DVV NP IW IW 26/01/ Web release Jul 08 DVV NP IW IW 07/07/ Web release Dec 08 DVV NP IW IW 12/12/ Web release Feb 09 DVV NP IW IW 16/02/ Web release Feb 09 DVV NP IW IW 16/06/ SATURN v10.9 Release DVV DG IW IW 04/09/ SATURN v10.9 Release DVV DG IW IW 22/10/ Web release Dec 10 DVV AG IW IW 06/12/ SATURN v10.9 Release (Full) DVV AG IW IW 05/06/ SATURN v11.1 Release (Full) DVV AG IW IW 31/03/ SATURN v11.2 Beta Release DVV JS IW IW 07/12/ SATURN v11.2 Release (Full) DVV JS IW IW 17/03/ SATURN v11.3 Release DVV EN IW IW 28/03/ / Mar

16. Simulation Network Coding Example

16. Simulation Network Coding Example 16. 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