12. Supplementary Programs - Saturn Software 12.pdf · 12. Supplementary Programs I NTRODUCTION ... MUC assignment if ALLUC = F ; see 12.1.6 . MODET : Integer . 1 : ... NEW MATRIX

SATURN MANUAL (V11.3)

Supplementary Programs

5120257 / Mar 14 12-0 Section 12.docx

12. Supplementary Programs 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 of 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 change 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. However it may be necessary 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.



5120257 / Mar 14 12-1 Section 12.docx

Figure 12.1 - Use of SATCH

12.1.2 SATCH Files

Channel Number Remarks

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 for the cordoned network for input to SATNET. (Optional - DONET = T)

8 Input DAT file containing the data from the original network as



5120257 / Mar 14 12-2 Section 12.docx

Channel Number Remarks input to SATNET. (Optional - DONET = T)

13 SATCH.HLP (Optional)

15/14 Terminal (output only) (Mandatory - unless MODET = 0)

24 $INCLUDE files called from the network .dat file (Optional).

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

INCLUD Logical FALSE If TRUE the output cordoned network file has each



5120257 / Mar 14 12-3 Section 12.docx

Option Type Default Interpretation 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.

USEUFO Logical FALSE If TRUE matrix cordoning will use a .UFO file in preference to .UFC if both are available (where the default is that set on the input .UFS file). See 12.1.12.

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.

NEWMUG

Logical FALSE If TRUE nodes at the “outer” ends of cordon cut 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 included 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 defined 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’.



5120257 / Mar 14 12-4 Section 12.docx

c) The links are those that are ‘cut’ by the cordon as opposed to a continuous set of links that are themselves the cordon.

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 are 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. Hence 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.



5120257 / Mar 14 12-5 Section 12.docx

Holes can be detected by analysing the printed set of ‘back-nodes’. If 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 buffer links (if both exist or else clearly just the one type). The cordoned network includes both simulation and buffer components as appropriate. It 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 reached 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 NODEF 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. (See also 11.13.5 in P1X where the concept of a “spine” may be extended to allow a series of links which are not in a straight line.)

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



5120257 / Mar 14 12-6 Section 12.docx

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 network 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 copies to the output data file on channel 7:

(i) Any ‘general’ records, e.g. the &PARAM cards;



5120257 / Mar 14 12-7 Section 12.docx

(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 card) but then no data appears. SATNET might - with some justification - take umbrage at this apparent thoughtlessness on your 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 counted 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 traced 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.



5120257 / Mar 14 12-8 Section 12.docx

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 included 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 P1X

SATCH is basically a “batch” program; however most of the functions available within SATCH are also available within P1X, in addition to the ability to define a cordon as mentioned in note 14, Section 12.1.4.

Thus having defined a cordon in P1X 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).



5120257 / Mar 14 12-9 Section 12.docx

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. For 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 longer 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 only 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 set for ALLUC and NOMAD 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.



5120257 / Mar 14 12-10 Section 12.docx

In addition, if NOMAD > 1, then no output network .dat file is created on the 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 factored prior to assignment due to 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 re-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 that link. Differences between the two may be due to 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 achieved. Statistics 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



5120257 / Mar 14 12-11 Section 12.docx

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 FURNES 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 in 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 cordon cut link (i.e., a new 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 assigned a new node number and location. 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.



5120257 / Mar 14 12-12 Section 12.docx

12.1.12 Tracing O-D Routes: Choice of .UFO or .UFC

The tracing of the originally assigned O-D routes in order to create the cordoned matrix may use one of two methods: using a .UFO file or using a .UFC file. See 15.23.6 for a general description of the differences between the two methods. UFO calculations are considerably faster than UFC but, clearly, require that a .UFO file exists.

Note that the .UFO file will only exist if – under FW assignment - either SAVUFO = T in the network .dat file or SATUFO has been called post SATALL or if OBA assignment was used in the first place.

Provided that a .UFO file exists the choice of UFO or UFC is determined by the namelist parameter USEUFO = T or F respectively where the default value of USEUFO is set in the original network .dat file (6.3.1) but it may be over-written within the SATCH control file (12.1.2).

12.1.13 SATCH Batch Files

SATCH may be run using one of two “off the shelf” batch files: SATCH.bat and SATCH_MC.bat (the 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 altered network since there are no observable flows on which to base signal settings. The central hypothesis is that optimum



5120257 / Mar 14 12-13 Section 12.docx

network offsets can be determined which, to a good 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.

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 full run of SATURN is carried out, resulting in a file 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.



5120257 / Mar 14 12-14 Section 12.docx

Figure 12.2 - Use of SATOFF

(The box denoted by SATASS / SATSIM is, in current versions of SATURN, simply an application of the single program SATALL which carries out both assignment and simulation.)

At this point two alternative ‘loops’ may be used: 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 obtained after a single 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



5120257 / Mar 14 12-15 Section 12.docx

itself such that an updated and re-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 output .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.

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 to be fixed and all 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 to, 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”.



5120257 / Mar 14 12-16 Section 12.docx

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 range 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 net2.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 appropriately set control file in order to select the same basic steps as in SATOFF.

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 determined). For ‘normal’



5120257 / Mar 14 12-17 Section 12.docx

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



5120257 / Mar 14 12-18 Section 12.docx

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)

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



5120257 / Mar 14 12-19 Section 12.docx

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

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



5120257 / Mar 14 12-20 Section 12.docx

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

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 come first (with a 1 in 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.



5120257 / Mar 14 12-21 Section 12.docx

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 network 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 13nZ rows x nZ columns (where nZ is the number of zones). The 10 minute interval is user-set. By 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 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 to 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)



5120257 / Mar 14 12-22 Section 12.docx

♦ Queued delay (V >C)

Transient delays include both delays at junctions (turning movements) and speed/flow delays on capacity-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 delays after the last mid-point (9:45) are 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 estimated 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 wants 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 nZ x M rows where nZ is the number of zones and M is the number of discrete departure/arrival times (variable NTOM in &PARAM; see 12.7.5).



5120257 / Mar 14 12-23 Section 12.docx

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 it probably should be changed, in the arrival-based or backwards mode each row of the output matrix represents skimmed times for a destination so that e.g., the Jth element in such a row would be the time FROM origin J to that destination. In 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

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:



5120257 / Mar 14 12-24 Section 12.docx

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)



5120257 / Mar 14 12-25 Section 12.docx

12.8 Version Control

JOB NUMBER: 5120257 DOCUMENT REF: Section 12.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 Templates 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 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 – Jun 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 23/05/11

11.1.09 SATURN v11.1 Release (Full) DVV AG IW IW 31/01/12

11.2.01 SATURN v11.2 Beta Release DVV JS IW IW 07/12/12

11.2.05 SATURN v11.2 Release (Full) DVV JS IW IW 17/03/13

11.3.03 SATURN v11.3 Release DVV EN IW IW 31/03/14

Documents

12. Supplementary Programs - Saturn Software 12.pdf · 12. Supplementary Programs I NTRODUCTION ... MUC assignment if ALLUC = F ; see 12.1.6 . MODET : Integer . 1 : ... NEW MATRIX