Within the SATURN Suite matrix data exists in essentially two forms: first, as “raw” data in ascii or text files, and secondly as “processed” or binary data in unformatted files. These are most easily identified by their standard file extensions .dat and .ufm respectively.
With the exception of MX when used to “build” matrices by converting a .dat file into a .ufm file all programs which involve matrices access them in their .ufm format. Thus, for example, the trip matrix file input for assignment must be a .ufm file.
.Ufm files include not only all the cell values for the matrix but also a certain number of “header records” which record, for example, basic matrix data such as the number of rows and columns in the matrix but also relevant filenames, information on sectors and (post 11.3) details of any zone-to-group aggregations which may have been specified via .Z2G files (see 10.2.5.5).
For virtually all transport-based applications the matrices are square (number of rows equals number of columns) and the rows/columns are associated with zones. SATURN follows the general convention that rows are associated with origins and columns with destinations. Thus, in a trip matrix the seventh element in the third row represents the number of trips from zone 3 to zone 7. Each row is stored in a separate record within a .ufm file.
Note that with SATURN 9.5 matrix .ufm files are held in a “compressed” 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 compressed format records this with a single marker rather than n (number of columns) distinct values. A number of other similar “tricks” are employed. This means that, for example, an observed trip matrix, 95% of whose cells might be zero, only requires marginally more than 5% of a “full” matrix.
In theory MX can handle both square and non-square matrices; however, for the reason above, MX is very seldom used in practice with non-square matrices so some caution is advised if you do wish to work with non-square. The exception is “stacked matrices” - see 10.2.4 - which are in effect a set of multiple square matrices and are therefore standard.