DIADEM 5.0 user manual (SATURN version)

13 downloads 12112 Views 3MB Size Report
Feb 7, 2011 ... There are separate versions of the manual for SATURN and ... shown in the header of each page of the manual. .... product or service.
DIADEM User Manual

Version 5.0 (SATURN)

February 2011 (Reissued September 2012) Department for Transport

DIADEM User Manual

293772

ITD

ITW

04

L

http://pims01/pims/llisapi.dll/open/1508352065 July 2012

Version 5.0 (SATURN)

February 2011 (Reissued September 2012)

Department for Transport From Thursday 13th September 2012, the responsibility for the maintenance, support, and sale of DIADEM on behalf of the Department for Transport has transferred from Mott MacDonald to Atkins Limited. For all enquires, please contact Atkins via email on [email protected] in the first instance or by telephone on +44 (0)1372 756272

Atkins Limited, Woodcote Grove, Ashley Road, Epsom KT18 5BW, United Kingdom T +44(0) 1372 726140 F +44(0) 1372 740055 , W www.atkinsglobal.com

DIADEM User Manual Version 5.0

Issue and revision record Revision A

Date March 2010

Originator A Gordon

Checker S Sirivadidurage

Approver C White

Description First issue (version 4.1 manual)

B

May 2010

A Gordon

S Sirivadidurage

C White

Second issue

C

August 2010

A Gordon

S Sirivadidurage

C White

Third issue

D

October 2010

A Gordon

S Sirivadidurage

C White

Fourth issue

E

January 2011

A Gordon

C White

C White

Fifth issue (version 5.0 manual)

F

February 2011

A Gordon

S Sirivadidurage

C White

Sixth issue

This document is issued for the party which commissioned it and for specific purposes connected with the above-captioned project only. It should not be relied upon by any other party or used for any other purpose.

We accept no responsibility for the consequences of this document being relied upon by any other party, or being used for any other purpose, or containing any error or omission which is due to an error or omission in data supplied to us by other parties This document contains confidential information and proprietary intellectual property. It should not be shown to other parties without consent from us and from the party which commissioned it.

Mott MacDonald, Stoneham Place, Stoneham Lane, Southampton SO50 9NW, United Kingdom T +44(0) 23 8062 8800 F +44(0) 23 8062 8801, W www.mottmac.com

DIADEM User Manual Version 5.0

Content Chapter

Title

1.

Introduction

1

2.

Installation

2

3.

Overview of DIADEM

3

3.1 3.2 3.3

Purpose of DIADEM__________________________________________________________________ 3

Types of demand model ______________________________________________________________ 4

Help and support ____________________________________________________________________ 4

4.

Background information

4.1 4.2 4.3 4.4 4.5 4.6

Logit models________________________________________________________________________ 6

HADES___________________________________________________________________________ 13

Generalised costs and cost damping____________________________________________________ 24

OD and PA ________________________________________________________________________ 28

Public transport in DIADEM ___________________________________________________________ 31

Segmentation in DIADEM ____________________________________________________________ 32

5.

Preparation for a DIADEM run

5.1 5.2 5.3

Overview _________________________________________________________________________ 34

Incremental model __________________________________________________________________ 35

Absolute model ____________________________________________________________________ 36

6.

Entering DIADEM data

41

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13

Overview _________________________________________________________________________ The DIADEM Control file _____________________________________________________________ General information _________________________________________________________________ Page 1: forecast network files(s) and segmentation ________________________________________ Page 2: Model Parameters ___________________________________________________________ Page 3: Highway Trip/Cost Data _______________________________________________________ Page 4: PT Trip/Cost data ____________________________________________________________ Page 5: PA Model Data ______________________________________________________________ Page 6: Absolute Model Data _________________________________________________________ Page 7: DIADEM Parameters _________________________________________________________ Page 8: HADES Data________________________________________________________________ Page 9: SATURN Settings ____________________________________________________________ Running DIADEM___________________________________________________________________

41

41

42

43

46

53

59

61

63

66

68

73

74

7.

DIADEM output

75

7.1 7.2

Output files ________________________________________________________________________ 75

Dealing with error and warning messages________________________________________________ 78

8.

Hints and tips

8.1 8.2 8.3

Realism testing with DIADEM _________________________________________________________ 81

Reducing run times _________________________________________________________________ 83

Improving convergence ______________________________________________________________ 84

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

Page

6

34

81

DIADEM User Manual Version 5.0

8.4

Freezing particular movements ________________________________________________________ 85

9.

References

Appendices Appendix A. A.1. A.2. Appendix B. B.1. B.2. B.3. B.4. Appendix C. Appendix D. D.1. D.2. D.3. D.4.

Description of algorithms _____________________________________________________________ Definitions and notation ______________________________________________________________ Algorithm 1/MSA/FSL________________________________________________________________ Demand model functions _____________________________________________________________ Logit model________________________________________________________________________ The hierarchical model_______________________________________________________________ A general note on the demand models __________________________________________________ Example implementation of incremental logit model ________________________________________ Initial tour proportions from NTS data ___________________________________________________ History of DIADEM changes __________________________________________________________ Changes between 4.1 and 5.0 _________________________________________________________ Changes between 3.1 and 4.1 _________________________________________________________ Changes between 3.0 and 3.1 _________________________________________________________ Changes between 2.1 and 3.0 _________________________________________________________

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

86

87

88

88

88

90

90

92

92

93

97

99

99

99

99

99

DIADEM User Manual Version 5.0 (SATURN)

1. Introduction

This document provides guidance on how to run version 5.0 of DIADEM (Dynamic Integrated Assignment and DEmand Modelling). It should be read in conjunction with the Department for Transport’s latest WebTAG guidance on variable demand modelling which provides information on appropriate demand modelling structures and associated parameters (http://www.dft.gov.uk/webtag). DIADEM fulfils two main roles: ƒ It provides a relatively simple way to link highway assignment models to a variable demand model. Currently links to CONTRAM and SATURN assignment models are supported, though links to other packages may be possible. ƒ It provides a means of achieving convergence between assignment (supply) and demand models.

DIADEM is intended to extend existing highway assignment models to variable demand modelling as easily as possible. It may not be appropriate for every possible demand modelling situation. In some cases more complex demand modelling software will be required; for example DIADEM does not include an explicit representation of walking and cycling modes. There are separate versions of the manual for SATURN and CONTRAM users. The manual version is shown in the header of each page of the manual. The DIADEM website (http://www.dft.gov.uk/diadem) provides information on DIADEM and access to the latest versions of the software and manuals.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

1

DIADEM User Manual Version 5.0 (SATURN)

2. Installation

You must have administrator rights on your pc to install DIADEM. If you receive the software on CD the installation process should start automatically on inserting the CD into the drive. If this does not happen, or you have received the software through a different medium you will need to run the program called setup.exe. To complete the installation you will need to accept the terms of the licence agreement. The following files will be installed to the DIADEM program files directory: ƒ ƒ ƒ ƒ

DIADEM software DIADEM help file Licence agreement (licence.txt) CONTRAM and SATURN versions of the manual

DIADEM works with SATURN version 10.8.21 and later and CONTRAM8. The system requirements are: ƒ Windows XP or Vista ƒ Minimum 1024x768 screen resolution We are not aware of any problems using DIADEM with Windows 7, though this has not yet been fully tested. The amount of memory (RAM) and disk space required depend on the size of the network being used with DIADEM and the level of segmentation. Typically, the most significant performance improvements are obtained by ensuring that enough RAM is available for DIADEM not to need to use virtual memory. 256MB is the recommended minimum but 1GB or more may be required for large models. If there is insufficient RAM DIADEM will use virtual memory instead but this will significantly increase run times. 7MB of disk space is required for the DIADEM software itself. In addition sufficient space must be available to store DIADEM outputs, as follows: ƒ For CONTRAM DIADEM creates one trip matrix per iteration. ƒ For SATURN DIADEM creates one matrix per iteration for each of trips, time, distance and generalised cost for each time period and user class. The actual amount of disk space required may vary from a few megabytes to several hundred megabytes depending on the size of the model network and matrix files. If SATURN is being used as the assignment model DIADEM can reduce run times by carrying out assignments in parallel, provided suitable hardware is available (minimum dual core processor). Software updates are made available via the website http://www.dft.gov.uk/diadem. Downloading the software requires a user name and password which are provided to licence holders when they purchase the software.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

2

DIADEM User Manual Version 5.0 (SATURN)

3. Overview of DIADEM

3.1

Purpose of DIADEM

DIADEM aims to provide a user-friendly method for setting up a multi-stage transport demand model and then finding equilibrium between demand and supply, using an external assignment package as the supply model. The process iterates between demand calculations and assignments, meaning that several assignments are needed in a single DIADEM run. As with all such iterative processes, equilibrium is not found exactly but convergence criteria are used to determine when the solution is close enough to equilibrium. More details of the algorithms used in this process can be found in Appendix A. DIADEM does not include an assignment module; instead it relies on other software packages to carry out assignments. Currently DIADEM can formally be linked to CONTRAM and SATURN highway assignment models, although a DIADEM user has developed a link to VISUM and links to other packages may be possible (contact DIADEM support for advice). Any public transport (PT) assignment package can be used, provided it can produce trip and cost data in the required format. The software structure is illustrated in Figure 1. The PT and highway assignment models are external to DIADEM. Outputs are produced in comma-separated variable (CSV) or plain text format to allow further analysis. Figure 3.1:

DIADEM software structure

User Interface

PT Assignment

Parameters Model structure

Costs Trips

Trips Demand Model

DIADEM Engine Costs

Highway Assignment Costs

DIADEM software

Equilibrium trip matrix & convergence results

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

3

DIADEM User Manual Version 5.0 (SATURN)

3.2

Types of demand model

The main form of demand model available in DIADEM is the incremental hierarchical logit model, as recommended in WebTAG. This can be used to model trip distribution, mode choice and time period choice and can also be linked to an incremental trip frequency model. The incremental model works by adjusting an input reference demand matrix according to changes between forecast travel costs and input reference travel costs. An absolute version of the hierarchical logit model is also available. A more detailed discussion of the logit model and its application in DIADEM can be found in Section 4.1. A simple elasticity model using the Tanner function is available. Power and exponential elasticity functions are special cases of the Tanner function. It should be noted that WebTAG currently states that ‘Pending further research it is recommended that simple elasticity models are not used to model the full effects of variable demand’, although consultation guidance on proportionate appraisal proposes allowing their use on schemes with capital costs less than £20m (October 2009 consultation version of Unit 3.10.1). If you are using SATURN then it is usually more efficient to implement elasticity models using the options available within SATURN, rather than using DIADEM. The functional form of the elasticity model is given in Appendix B. DIADEM 5.0 includes the HADES model of arrival time choice. This part of DIADEM currently has beta test status. It is described in more detail in Section 4.2. For further discussion of these models and how to decide which is appropriate for your application please see WebTAG Unit 3.10.3 (Variable Demand Modelling - Key Processes). 3.3

Help and support

DIADEM has a context-sensitive help system. Pressing F1 or clicking the Help button will bring up help information relevant to the page you are working on. The help file can also be accessed via the Help menu. The help and manual contain mostly the same information, though the former does not include the appendices that are part of the manual. The DIADEM website (http://www.dft.gov.uk/diadem) includes an FAQ list which covers a number of issues relating to running DIADEM. If you have any questions, problems or suggestions for improvements please contact the DIADEM help desk at Mott MacDonald: email [email protected]. DIADEM is developed on behalf of ITEA division of the Department for Transport (E: [email protected]). Please note that details of support queries will be passed to the Department for their information.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

4

DIADEM User Manual Version 5.0 (SATURN)

Guidance on all aspects of modelling, including assignment and variable demand modelling, can be found on WebTAG (http://www.dft.gov.uk/webtag). Questions on the application and interpretation of WebTAG should be directed towards DfT.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

5

DIADEM User Manual Version 5.0 (SATURN)

4. Background information

4.1

Logit models

4.1.1

Absolute logit

The logit model is at the heart of the main DIADEM demand model. It is one of a family of models referred to as discrete choice models. Such models predict the probability that an individual will pick a particular alternative when faced with a choice between a number of options. For instance, in the context of mode choice they can be used to predict the probability of someone choosing to travel by bus. When applied to a large number of people these probabilities can be interpreted as mode shares, e.g. the proportion of people who will choose to travel by bus. These proportions can then be multiplied by the total number of people to obtain the number of people using each mode. Algebraically, the multinomial logit model is given by: pi =

exp(U i ) exp U j

∑ ( ) j

where pi Ui

is the probability of choosing alternative i is the utility of alternative i

‘Utility’ is a term used in economics to describe the amount of satisfaction derived from consuming a product or service. In general the utility of travel is negative and is related to the generalised cost of travel by Ui = λci where ci λ

is the generalised cost of alternative i is a negative scaling parameter

The scaling parameter can be interpreted as a factor to convert from generalised cost to utility; it can also be seen as a measure of the sensitivity of travel choices to generalised cost. Taking an example with just two alternatives, say bus and car, it can be shown that the formula reduces to:

pcar =

exp(U car ) 1 = ( ( ( ) ( ) exp U car + exp U bus 1+ exp λ c bus − ccar ))

This shows an important property of logit models: the choice probabilities depend only on the absolute differences in costs between the alternatives.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

6

DIADEM User Manual Version 5.0 (SATURN)

When viewed graphically logit models follow a typical S-shaped curve. This can be seen in Figure 4.1, which shows the curves for different values of λ, illustrating how it changes the sensitivity of mode shares to costs. Figure 4.1:

Typical logit curves

100% λ=-0.12

90%

λ=-0.08 λ=-0.04

80%

Car mode share

70% 60% 50% 40% 30% 20% 10% 0% -80

-60

-40

-20

0

20

40

60

80

Bus cost minus car cost

In transport modelling logit models have a multitude of uses. In DIADEM the absolute model can be used to model choices of mode and destination (destination choice models are also referred to as trip distribution models). 4.1.2

Mode-specific constants, size variables and K-factors

When using an absolute logit model for mode choice it is usually found that generalised cost alone is not enough to explain the observed mode choice. For example, the logit model would predict that if the generalised costs are the same then the mode share would be 50/50 between car and PT, whereas the corresponding observed mode share might be closer to 60/40. This is usually handled by adding a constant to the generalised cost for one of the modes. This represents the remaining preference for one particular mode, after differences in generalised costs have been taken into account. These constants are called mode-specific constants. Mode-specific constants can be defined in DIADEM. These constants must be in the same units as the generalised cost function (usually generalised minutes). A positive value for the constant reflects a dislike of that mode, i.e. other things being equal, as the constant increases the mode share will decline. Similarly, destination choice cannot usually be explained by travel costs alone. For example, suppose Zones X and Y have the same travel costs from Zone Z. If Zone X has twice as many shops as Zone Y we would expect it to attract about twice as many shoppers. This is reflected through the use of size variables 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

7

DIADEM User Manual Version 5.0 (SATURN)

which are added to the basic functional form as follows: p j |i =

( ) ∑ B j exp(Uij ) B j exp U ij

j

where pj|i Bj

is the probability of someone travelling from zone i choosing to travel to zone j is the size variable for zone j

Because of the way size variables are used it is only their relative size that affects the model results, the actual units used are not important. Typical size variables will depend on the trip purpose. For instance, commuting trips will often use the number of jobs; shopping trips might use the amount of retail floorspace or the number of retail employees. Size variables cannot be used with the doubly-constrained distribution model (i.e. where the number of trips to and from each zone is fixed). When this model is used then, in effect, DIADEM estimates its own size variables to ensure that the specified destination trip end constraints are met. In a similar vein, K factors are sometimes used in distribution models. They depend on the zone pair and are added to the model as follows: p j |i =

( ) ∑ K ij exp(Uij ) K ij exp U ij

j

They are used to give a better fit between modelled and observed data. K-factors are much-abused in distribution modelling and often lead to over-specified models. K factors can be used in conjunction with size variables: p j |i =

( ) ∑ K ij B j exp(Uij ) K ij B j exp U ij

j

Alternatively this can be written as: p j|i =

(

( ) ( )) ∑ exp(Uij + ln(K ij ) + ln(B j )) exp U ij + ln K ij + ln B j

j

In other words the size variables and K factors can be incorporated into the utilities. This formulation is used in DIADEM in the calculation of composite utilities (see following section). Section 6.9 explains how the various constants are entered into DIADEM by the user. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

8

DIADEM User Manual Version 5.0 (SATURN)

4.1.3

Hierarchical logit

The model becomes more complicated when more than one choice is being considered. Suppose a traveller has to choose between 2 modes and 3 destinations, a total of 6 different combinations. The multinomial logit could be used to model the choice between these 6 options, but it is more common to have mode and destination choice in a hierarchical structure (often referred to as nested logit, and sometimes tree logit).

Mode Bus

Car Destination D1

D2

D1

D3

D2

D3

In effect the logit model is being applied several times, once for mode choice and once for destination choice for each mode separately. These results are then combined together. On the probability side, the probabilities at the bottom level are calculated conditional on the choice(s) made at the higher level. This is denoted pj|im. The combined probability of a traveller from zone i choosing to travel to destination j by mode m is then: p jm|i = pm|i p j |im =

(

)

exp U ijm exp(θU i *m ) exp(θU i *m ) exp U ijm

∑ m

∑ ( ) j

Note the additional scaling/tree parameter θ. This must be greater than zero and less than or equal to 1. It represents how sensitive the upper level choice is to cost, relative to the lower level. The response most sensitive to cost appears at the bottom of the hierarchy, with other responses less and less sensitive the higher up the tree they are. On the cost side, the bottom level model uses generalised costs converted to utilities Uijm in the normal way. The higher level then uses utilities Ui*m which are, in some sense, the average over the choices in the nest below. These are referred to as composite utilities and are calculated as follows:

U i *m = ln

∑ exp(U )

ijm

j

4.1.4

Spatial segmentation

Spatial segmentation is a feature available in DIADEM whereby the distribution model parameters (λ or θ, depending on the position of distribution in the hierarchy) can vary by OD pair.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

9

DIADEM User Manual Version 5.0 (SATURN)

4.1.5

Incremental logit

Incremental models are used where the costs and demand (or probabilities) for a reference case are known as we want to estimate how a change in cost will affect demand. In DIADEM the form of incremental logit model is: p i =

p i0 exp(ΔU i )

∑p

0 j

(

exp ΔU j

)

j

where ΔU i= Ui-Ui0 = λ(ci-ci0) where λ PAT2

(late arrival )

τ ∈ [PAT1, PAT2 ] (on − time arrival ) τ < PAT1 (early arrival )

where: τ PAT1, PAT2 ξ (τ ) α β γ

is the arrival time are the beginning and end of the PAT window is the travel duration for arrival time τ is the cost coefficient for travel duration is the cost coefficient per unit time for early arrival is the cost coefficient per unit time for late arrival

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

14

(4.1)

DIADEM User Manual Version 5.0 (SATURN)

Note that HADES does not currently include distance or toll-related costs. HADES is an equilibrium model and seeks to allocate trips to arrival times in such a way that no traveller can reduce their generalised cost by changing their arrival time. Equation (4.1) can be used when the scheduling constraint is at the destination end of the trip and is often applied when considering the journey to work, or travel to a business appointment. It may not be applicable to the return leg of such trips, and thus is perhaps best suited to modelling the AM peak. 4.2.3

Implementation of HADES in DIADEM

4.2.3.1

Overview

This section explains the details of how HADES has been implemented in DIADEM. It should be noted that HADES is currently implemented only as an absolute demand model, whereas DIADEM is most often used to implement an incremental model. The notation used below does not explicitly refer to time periods. Within DIADEM, HADES is applied independently between time periods, i.e. the choice of arrival time within one time period will not affect the choice of the arrival or departure time of the other leg of the trip in a different time period. 4.2.3.2

Limitations

The current implementation of HADES in DIADEM has some limitations: ƒ Only travel durations and scheduling costs are included in the generalised cost function. Distancebased and toll costs are not included at the present time. ƒ Convergence between the assignment and HADES demand model is slow and in some cases it may not be possible to achieve acceptable levels of convergence. ƒ HADES can only be used for highway trips, not public transport. ƒ HADES can only be used as a stand-alone demand model, or linked to an absolute logit model of mode and destination choice. It cannot be linked to an incremental logit model.

Some or all of these limitations may be addressed in future versions of DIADEM. 4.2.3.3

Segmentation

The levels of segmentation associated with the HADES model in DIADEM are: ƒ Whether to use HADES is defined separately for each demand segment; even for demand segments that do use HADES, it may be turned off in selected time periods (for example, it may only apply to commuting trips in the AM peak). ƒ The definition of PAT windows is done by demand segment, destination sector and time period ƒ The definition of scheduling parameters β and γ is done by demand segment, destination sector and time period. ƒ The definition of demand by PAT window is done by origin-destination pair, demand segment and time period. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

15

DIADEM User Manual Version 5.0 (SATURN)

The ability to define PAT windows and scheduling parameters by destination sector is designed to recognise that there may be variations in trip scheduling constraints even within a demand segment. For instance, commuters travelling to one area may be predominantly factory workers, who will have different constraints compared to workers travelling to a different area who may be mainly office workers. The details of how to enter HADES data in DIADEM are covered in Section 6.11. 4.2.3.4

What does the assignment represent?

For a dynamic assignment model like CONTRAM it is well-defined that the trip matrix for, say, the time slice 0810-0820 represents all trips departing in that time slice. For a static model like SATURN it is less clear cut and, to some extent, is up to the modeller. So a SATURN time slice for 0810-0820 could either represent trips departing in that time, or trips with a midpoint in that time (the mid-point being midway (in time) between the departure time and arrival time of the trip). Within DIADEM the user can choose either option. 4.2.3.5

Assignment-HADES iteration

Overview Although sometimes referred to as a departure time choice model, HADES is strictly speaking a model of arrival time choice. On the other hand, assignment models typically work on the basis of departure times (or, occasionally, trip mid-point times). Interfacing between the HADES demand model and an assignment model therefore involves a translation of data between the two paradigms. The overall process is shown in Figure 4.5 below.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

16

DIADEM User Manual Version 5.0 (SATURN)

Figure 4.5:

Assignment-HADES iteration.

Time skimming

Assignment Assignment trip

matrix

Allocate demand to

assignment time

slices

Estimate travel durations as function of arrival time

Adjusted arrival time matrix Convergence algorithm Arrival time matrix

Calculate cost of arrival in each arrival time window

Allocate demand to each arrival time window

The details behind each step are described in more detail below. Time skimming After an assignment travel durations are skimmed as per a conventional DIADEM run. However, the way these skims are used is slightly different. Within HADES it is assumed that travel duration varies continuously with arrival time, and therefore also by departure time. For each OD pair and demand segment the skim will return a single value for the travel duration for each time slice. It is then necessary to associate this duration with a fixed point in time. If the assignment is based on departure times (or trip mid-points), then the travel duration is assumed to be that for a trip departing at (or with a mid-point at) the middle of the time slice, i.e. if the time slice represents 0810 to 0820 then the skimmed travel duration is assumed to be for a trip departing (or with a mid-point at) 0815. Travel durations by arrival time From the previous step, for each OD pair and demand segment we have the travel duration for a discrete set of departure times (or trip mid-points). As noted earlier, HADES is more concerned with arrival times,

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

17

DIADEM User Manual Version 5.0 (SATURN)

so the data are translated to travel duration by arrival time as follows: ƒ For assignments based on departure time, arrival time is departure time plus travel duration ƒ For assignments based on trip mid-points, arrival time is trip mid-point time plus half the travel duration

Travel durations for arrivals at other times are interpolated from the above values 1. This can only give travel durations for a period similar to that covered by the assignments. For example if the assignment covers, in total, the period 0800-0900 then the above might only give us travel durations for arrival between 0810 and 0910 (assuming 10 minute travel durations). For this reason, the user must also define pre-peak and post-peak travel times. When modelling the AM peak the former will be close to free-flow times, but the latter are likely to be a bit higher. Durations for arrival before or after the time interval defined by the above process are then extrapolated until they hit the user-defined pre and post-peak times. This gives us travel durations for a much wider range of arrival times than implied by the assignment. (This has implications for the length of the period covered by PAT windows, compared to that covered by the assignment. This is discussed further in Section 6.11.) The process is illustrated in Figure 4.6. The red squares represent the travel durations for a set of departure times, as defined by the assignment. Converting these to travel durations for a set of arrival times gives us the blue diamonds; the horizontal distance between the two represents the travel duration. The blue line shows the interpolation and extrapolation of these values, including the user-defined pre-peak and post-peak durations, represented by the horizontal sections of the line. Figure 4.6:

Obtaining travel durations as a function of arrival time.

50 travel duration 47 mins

45 40

Travel duration

35 30 25 20 As function of arrival time 15 As function of departure time 10 5 0 08:00

08:15

08:30

08:45

09:00

09:15

09:30

09:45

10:00

Time

1

At this stage DIADEM will check for violations of the first-in first-out (FIFO) principle by looking for any cases where later departure implies earlier arrival. A warning message will be issued to the log file if this is found to be the case. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

18

DIADEM User Manual Version 5.0 (SATURN)

Cost of arrival in each arrival window For a trip for a given origin, destination and demand segment, with a preferred arrival time window k, the next step is to calculate the cost of arrival in each possible arrival time window, in order to then be able to calculate the optimum arrival time, i.e. the one with the minimum cost. The cost of arrival in a given arrival time window is calculated assuming arrival in the middle of the window. The travel duration (interpolated as described earlier) is added to any scheduling cost. The scheduling cost will be zero for any actual arrival time window h that is the same as the preferred arrival time window k. For a trip from zone i to zone j in demand segment c with PAT window k the generalised cost of arriving in the middle of a particular arrival time window h (at time τh) is given by 2:

Vijckh

⎧ξ ijc (τ h ) + γ Jc (τ h − PAT 2 k ) if ⎪⎪ if =⎨ ξ ijch ⎪ξ (τ ) + β (PAT 1 − τ ) if k h Jc ⎩⎪ ijc h

τ h > PAT 2 k

(late arrival )

τ h ∈ [PAT 1k ,PAT 2 k ] (on − time arrival ) τ h < PAT 1k

(4.2)

(early arrival )

ξ ijc (τ h ) is the (interpolated) travel duration for demand segment c from zone i to zone j arriving at time τh

J

is the sector which contains zone j

Allocate demand to arrival time windows Once the utilities Vijckh have been calculated the demand Tijck is allocated on an all or nothing basis to arrive in the arrival time window h*(k) with the lowest generalised cost. This gives the ‘auxiliary’ demand Y:

Yijckh = Tijck ⋅ δ ijck:h,h*

(4.3)

where

δ ijck :h,h * = 1

if h=h*, i.e. h is the arrival time window with the lowest cost for this ijck

δ ijck :h,h * = 0

otherwise

Y is subsequently combined with the current best estimate of trips, as described below. Convergence algorithm N is the current best estimate of the number of trips from i to j in class c with a preferred Suppose X ijckh

arrival time of k that choose arrival time window h. (N is the iteration number and refers to the number of HADES-assignment model loops that have been carried out.)

2

This is slightly simpler than equation (4.1). In DIADEM the cost is expressed in generalised minutes. In DIADEM-HADES travel durations are also in minutes, therefore we can set α=1 and define the scheduling parameters β and γ as the scheduling costs per minute of early or late arrival relative to one minute of travel duration. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

19

DIADEM User Manual Version 5.0 (SATURN)

Following the assignment of XN, the skimming of costs and completion of all the steps already described above we end up with the auxiliary solution. The two are then combined to obtain the next estimate. With the fixed step length (FSL) and method of successive averages (MSA) algorithms this is done as follows: N +1 N X ijckh = (1− α ) ⋅ X ijckh + α ⋅Yijckh

(4.4)

where α is the step length, as defined by either the fixed step length (FSL) or method of successive averages (MSA) algorithm. If the Social Pressure algorithm is used the formula is:

N +1 X ijCkh

[

]

* N N −1 ⎧ X ijCkh if h ≠ hijCk − min 1,α ⋅ PijCkh ⋅ X ijCkh ⎪ * N −1 = ⎨X N + min 1,α ⋅ PijCkh ⋅ X ijCkh if h = hijCk ⎪ ijCkh * h ≠ hijCk ⎩

∑( [

]

)

(4.5)

where

PijCkh

⎧⎛ V −V * ⎪⎜ ijCkh ijCkhodCk ⎪⎜ ⎪ V = ⎨⎜⎜ * ijCkhodCk ⎝ ⎪ ⎪V −V * ⎪⎩ ijCkh ijCkhodCk

⎞ ⎟ ⎟ ⎟⎟ ⎠

if

V

* ijCkhodCk

>0

otherwise

Convergence monitoring Because HADES uses a deterministic choice model it is possible to calculate a delta gap function analogous to that used in Wardrop equilibrium assignment models:

δ=

∑X

ijchk

N +1 ⎛ ijckh ⎜Vijckh



∑X

(

)

− min Vijckh ⎟⎞ h ⎠

(4.6)

N +1 ijckhVijckh

ijckh

This is referred to as the HADES gap in the output files. It is not directly comparable to the demand-supply gap usually reported by DIADEM. The gap will be zero at equilibrium. The HADES gap value can be used as a stopping criterion in the iterative process. An alternative convergence measure, the average excess cost (AEC), is discussed in Mott MacDonald (2011). It is not automatically output by DIADEM, but can be calculated from standard outputs. Please contact DIADEM support if you would like details.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

20

DIADEM User Manual Version 5.0 (SATURN)

Conversion of demand by arrival time window to demand by assignment time slice Having calculated the demand X by arrival time window, it then needs to be converted into demand by assignment time slice. At this stage we are only interested in the actual arrival time window h and not the preferred arrival time window k so we can sum the arrival time matrix over k as follows: N +1 X ijch =

∑X

N +1 ijckh

(4.7)

k

For tidiness we now drop the ijc subscripts, but note that the following steps need to be carried out for each ijc combination. First calculate the cumulative arrival time distribution Ω, i.e. the total demand arriving before the end of each arrival time window (τendH): Ω(τend H ) =

H

∑X

N +1

h

(4.8)

h=1

In addition we can also calculate the cumulative demand at the start of the first arrival time window Ω(τstart1 ) 3. Using the interpolation method set out earlier, we then estimate travel durations for arrival at the end of each arrival time window (and the beginning of the first one) to obtain ξ (τend H ) and ξ (start 1 ) . For departure time-based assignment we can then calculate the cumulative distribution of demand by departure time, Q, at the corresponding departure times: Q (τend H − ξ (τend H )) = Ω(τend H )

(4.9)

Q (τstart1 − ξ (τstart1 )) = Ω(τstart1 )

Or, for assignments based on trip mid-points: ξ (τend H ) ⎞ ⎛ Q ⎜ τend H − ⎟ = Ω(τend H )

2 ⎝ ⎠

ξ (τstart1 ) ⎞ ⎛ Q⎜ τstart1 − ⎟ = Ω(τstart1 ) 2 ⎝ ⎠

(4.10)

Using linear interpolation we then evaluate Q at the end of each assignment time slice r. Call this Qr. The demand to be allocated to timeslice r for assignment is then just: Qr - Qr-1

where Q0 is Q evaluated at the beginning of the first time slice

Note that not all demand will be allocated to assignment time slices. Some may be allocated to pre and post-peak periods and will not be assigned.

3

This is not necessarily zero as HADES can shift demand to arrive before the start of the first arrival time window. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

21

DIADEM User Manual Version 5.0 (SATURN)

The principle is illustrated in Figure 4.7 which shows cumulative demand distributions by arrival and departure times, and how the latter is used to calculate the demand allocated to a particular time slice (0800-0815), using the difference in the cumulative demand function (departure time) between the beginning and end of the time slice. If the 0800-0815 time slice were the first assignment time slice, then any trips departing before 0800 would not be assigned. Figure 4.7:

Use of cumulative demand distributions to allocate demand to assignment time slices.

160

Cumulative demand

140

By arrival time By departure time

120 100 80 60 40 20 0 07:30

Demand allocated to 0800-0815 time slice

08:00

08:30

09:00

09:30

T ime (arrival or departure)

The first iteration On the very first iteration it is assumed that all travellers choose to arrive at their preferred arrival time. The user-defined pre-peak travel durations are then used to convert this to departure times (or trip mid-points), and then to demand by time slice for assignment. 4.2.4

Integrating HADES with other demand responses

The process described above refers to HADES iterating with the assignment only, with no other demand responses involved. However DIADEM allows HADES to be integrated with other responses, specifically absolute logit models of mode choice and distribution (the other DIADEM responses of frequency and time period choice are not currently available in absolute form). The overall process is illustrated in Figure 4.8.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

22

DIADEM User Manual Version 5.0 (SATURN)

Figure 4.8:

Integrating HADES with other demand responses.

Main demand model (mode choice & distribution)

Demand by time period (HADES segments/periods)

Demand by time period (non-HADES segments/periods)

Run HADES model

Apply fixed profiles

Demand by assignment time slice

Assignment

Costs by assignment time slice

Costs by time period

The main demand model is shown at the top. This produces trip matrices by time period. For HADES demand segments and time periods the HADES process described earlier is applied to produce demand by time slice, ready for assignment. For non-HADES demand segments and time periods, fixed profiles are applied to produce demand by time slice. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

23

DIADEM User Manual Version 5.0 (SATURN)

The demand is then assigned and the costs skimmed. For HADES time periods there is an iterative loop between the assignment and HADES which is run to convergence, as described in section 4.2.3. This is done independently for each time period to which HADES is applied. Following the convergence of this loop, costs by time period need to be calculated for passing to the demand model. This is a three-stage process as follows: ƒ For each OD pair and demand segment, the actual arrival time h is checked to see if it falls within the time period. Based on the actual arrival time and the travel duration the clock time of the midpoint of the trip is calculated to see if it is within the time period. If it does, the related data is used in the following stages. If it doesn’t, the data is discarded. For example, the time period might be 0700-1000. If the actual arrival time is 1010 and the travel duration is 30 minutes then the midpoint occurs at 0955 and fits in the time period. If the actual arrival time is 1010 and the travel duration is 10 minutes then the midpoint occurs at 1005 and is outside the time period. ƒ For each preferred arrival time k, the minimum cost over all actual arrival times h is found. ƒ A flow-weighted average of this minimum cost over all k is then calculated. This gives the cost by OD pair, demand segment and time period which is passed to the main demand model.

Note that, for HADES demand segments and time periods, the costs used in the main demand model do not include distance-related or toll costs. This may be changed in a future version. 4.3

Generalised costs and cost damping

4.3.1

Generalised costs

DIADEM works with generalised costs in time units, specifically generalised minutes. The cost function is:

ppk ⋅ d + toll ⎞ ⎛ 60 ⋅ ⎜t + ⎟ VOT ⎝ ⎠

for highway trips

fare ⎞ ⎛ 60 ⋅ ⎜t + ⎟ ⎝ VOT ⎠

for PT trips



where t d toll fare ppk VOT

is the time in hours is the distance in kilometres is the toll (or parking charge) in pence is the PT fare in pence is the vehicle operating cost in pence per kilometre is the value of time in pence per hour

Generalised costs are converted to utilities for use in the demand model as described in Section 4.1.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

24

DIADEM User Manual Version 5.0 (SATURN)

4.3.2

Cost damping

It was noted in section 4.1.1 that the choices predicted by the multinomial logit model depend only on the difference in utilities or generalised costs between alternatives. This means that for a choice between two alternatives, the model gives the same choice probabilities when the alternatives have costs of 115 and 120, as when the alternatives have costs of 15 and 20. However, some modellers argue that this overestimates the sensitivity of longer trips to differences in costs and that in the former case the split should be closer to 50/50 than in the latter case. One way to achieve this is to use cost damping. The idea behind cost damping is to adjust the cost for longer trips so that their sensitivity to individual cost components (like fuel cost or travel time) is reduced. A typical impact of cost damping is shown in Figure 4.9. This shows that the cost used in the demand model is reduced compared to the ‘undamped’ cost and that a greater reduction is applied the higher the undamped cost.

Figure 4.9:

Effect of cost damping on the cost used in the demand model.

80 Undamped

70 Cost used in demand model

Damped 60 50 40 30 20 10 0 0

10

20

30

40

50

60

70

80

Undamped cost

Table 4.1 shows how cost damping can affect mode shares in a model of the choice between car and PT. In Scenario 1 the two modes have costs of 115 and 120 units respectively, in Scenario 2 the costs are 15 and 20. The difference in costs between the two modes is the same in both scenarios (5 units). Without cost damping the mode shares are the same in both scenarios (60/40). With cost damping the shares in Scenario 1 become more even (55/45) but there is little change in Scenario 2, i.e. cost damping makes travellers less sensitive to cost differences in the higher cost scenario.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

25

DIADEM User Manual Version 5.0 (SATURN)

Table 4.1:

Example of the effect of cost damping on choice probabilities. Mode shares (choice probabilities)

Scenario

Mode

Undamped cost

Without damping

With damping

Car

115

60%

55%

Scenario 1 Scenario 2

PT

120

40%

45%

Car

15

60%

59%

PT

20

40%

41%

WebTAG 3.10.2 ‘Variable demand modelling – scope of the model’ sets out 4 different cost damping mechanisms. All of these are available in DIADEM. For consistency with the notation in WebTAG the following sections use c to refer to money costs; in DIADEM this is either the combination of toll and vehicle operating cost for highway trips, or fare for PT trips. The basic cost function is then: c ⎞ ⎛ 60 ⋅ ⎜t + ⎟

⎝ VOT ⎠

The following sections set out the different cost damping functions. Further information on obtaining suitable parameter values can be found in WebTAG. All the functions have been previously used in practice, but there is little empirical evidence to prefer one method over another. A thorough review of cost damping methods and their theoretical basis can be found in Daly (2010). 4.3.2.1

Damping by a function of distance ⎧⎛ dshort ⎞ −α c ⎞ ⎛ ⎪⎜ ⎟ ⋅ 60 ⋅ ⎜t + ⎟ if dshort > d ′ VOT ⎪⎝ k ⎠ ⎝ ⎠ damped cost = ⎨

c ⎛ ⎞

⎪ if dshort ≤ d ′ ⎪60 ⋅ ⎜t + VOT ⎟ ⎝ ⎠ ⎩

where dshort α k d'

is the shortest distance on the network for the zone pair is a parameter greater than or equal to zero and less than one is a positive parameter is a cut-off distance, below which cost damping is not applied, with k=d’ if d’>0

According to WebTAG dshort “should be calculated by skimming distances along minimum distance paths built between all origin-destination pairs using a base year network. In forecasting, there would only be a need to recalculate these distances if the structure of the network changed significantly between base and forecast years.” 4.3.2.2

Damping by a power function of cost ⎛ c ⎛ damped cost = μ ⋅ ⎜⎜ 60 ⋅ ⎜t + VOT ⎝ ⎝

⎞⎞ ⎟ ⎟⎟ ⎠⎠

β

where 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

26

DIADEM User Manual Version 5.0 (SATURN)

β μ

4.3.2.3

is a parameter greater than zero and less than or equal to one

is a positive parameter

Varying the non-working value of time by distance ⎛ c ⎞ ⎟

damped cost = 60 ⋅ ⎜⎜ t + ⎟ ⎝ VOTd ⎠

where VOTd

is the value of time which varies with distance and is calculated using:

⎛ max (d,d c ) ⎞ ⎟ VOTd =VOT .⎜⎜ ⎟ d0 ⎝ ⎠

nc

VOT

is the average value of time;

d0

is a calibrated parameter value to ensure that the average value of time is consistent with

that derived from either WebTAG or local data;

nc

is the elasticity of VOT with respect to distance;

dc

is a calibrated parameter value designed to prevent short-distance trips, particularly intrazonal trips, becoming unduly sensitive to cost changes.

4.3.2.4

Log cost plus linear cost damped cost = 60 ⋅ t + ε log(c + δ) + γc

where δ

is a small constant (e.g. 1p); and

ε, γ

are coefficients greater than or equal to zero

When models of this type are used, the implied value of time (pence per hour) can be obtained from the formula: VOT =

60 ε γ+ c +δ

These values of time need to be acceptable over all appropriate values of c.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

27

DIADEM User Manual Version 5.0 (SATURN)

4.3.2.5

Implementation in DIADEM

All of the cost damping mechanisms can be combined into a single function: ⎛ 60 ⋅ t + ε ⋅ log(ppk ⋅ d + toll + δ ) +

⎛ dshort 0 cost = μ⎜ ⎜ k ⎝

−α ⎜

⎞ ⎜ ppk ⋅ d + toll ⎟ γ ⋅ (ppk ⋅ d + toll ) + S1 ⋅ 60 ⋅ ⎜ n ⎟ ⎛ max (dshort,d c ) ⎞ ⎠ ⎜ ⎟⎟ VOT .⎜⎜ ⎜ d0 ⎠ ⎝ ⎝ ⎛ 60 ⋅ t + ε ⋅ log(fare + δ ) +

⎛ dshort 0 cost = μ⎜ ⎜ k ⎝

−α ⎜

⎞ ⎜ fare ⎟ γ ⋅ (fare ) + S1 ⋅ 60 ⋅ n ⎟ ⎜ ⎛ max (dshort,d c ) ⎞ ⎠ ⎜ ⎟⎟ VOT .⎜⎜ ⎜ d0 ⎠ ⎝ ⎝

⎞ ⎟ ⎟ ⎟ ⎟ ⎟ ⎠

⎞ ⎟ ⎟ ⎟ ⎟ ⎟ ⎠

β

for highway

β

for PT

where S1 is a binary switch that takes the values: ⎧1 if ε = γ = 0

S1 = ⎨ ⎩0 otherwise

In other words, when the log plus linear cost option is applied, the final term inside the brackets is not used (it would duplicate the linear cost term that has the ε coefficient). By setting appropriate values for each parameter, particular cost damping mechanisms can be turned on or off, and different methods can be used together. This is explained further in section 6.5.5.5, which describes how cost damping data can be entered into DIADEM. Note that the log plus linear cost method and the varying non-working value of time by distance method should not be used at the same time. 4.4

OD and PA

4.4.1

Introduction

As discussed in WebTAG Unit 3.10.2 (Variable Demand Modelling – the Scope of the Model) trip matrices can be represented in origin-destination (OD) or production-attraction (PA) format. Consider someone who lives in zone A and works in zone B. They commute to work in the AM peak and return home in the PM peak. This behaviour would be represented in the two matrix formats as follows:

OD matrix AM peak:

OD matrix PM peak:

A

B

A

0

1

B

0

0

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

28

A

B

A

0

0

B

1

0

DIADEM User Manual Version 5.0 (SATURN)

PA matrix 24 hrs: A

B

A

0

1

B

0

0

In the PA format the value of 1 with production zone A and attraction zone B implies the outbound trip from A to B and the return trip from B to A. Some notations would require a value of 2 to give a single outbound and a single return trip. However in the convention used in DIADEM a value of 1 implies a single trip in each direction. The key differences can be summarised as follows:

OD

PA

Usually broken down by time period

Usually represent a 24 hour total

Direction of travel is always from origin to destination

Production end is always the home end of the trip, regardless of the direction of travel

It can be seen that the OD representation loses the link between outbound and return trips. This means it is difficult to ensure consistency of travel behaviour between the two legs. For example, someone might choose to go out by car but return by bus. This is one of the main disadvantages of OD-based demand modelling. Where matrices are in PA format it is still necessary to convert them to OD matrices by time period for assignment to the transport network. This is done using a series of factors which, for example, represent the proportion of trips that go out in the AM peak, or the proportion that return in the inter-peak. Conversion from OD to PA is usually not possible as the link between the two legs has normally been lost, as has the information on which end of the trip is ‘home’. Variable demand modelling can be done using OD or PA format matrices. WebTAG recommends that PA is used for home-based trips. This has the advantage that it ensures consistency between mode and destination choice for outbound and return trips, and that these decisions are affected by costs on both legs. PA modelling is normally only used for home-based trips. Non home-based trips can be modelled on an OD basis. 4.4.2

Trips and tours

DIADEM actually uses a development of 24 hour PA modelling. This is necessary because traditional PA modelling does not support the modelling of time period choice in a way that is consistent with WebTAG. This is explained further in the paper by Gordon et al (2007). For home-based trips, a single tour consists of all the trips made between leaving home and returning. For example home to work to shops to home is a single tour.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

29

DIADEM User Manual Version 5.0 (SATURN)

DIADEM makes the simplifying assumption that all tours are so-called ‘simple’ tours, i.e. they go from home to a single destination and then back home again. Diversions from this can be modelled as non homebased trips using OD-based demand modelling. The distinction between PA modelling and simple tours is not clear cut. As far as DIADEM is concerned the key difference is that with tour modelling we explicitly consider, and link together, the time periods for outbound and return travel. The 24 hour PA matrix is broken down by outbound and return travel times. If there are, for example, four time periods (AM and PM peaks, inter-peak and off-peak) then the PA matrix is broken down into 16 (=4 x 4) combinations of outbound and return times. To break down a 24 hour PA matrix to this level of detail requires information on what proportion of trips in the 24 hour matrix go out and return in each combination of time periods. This data is typically available from household travel diaries, but usually not from roadside interviews. A new method has been developed for DIADEM which makes use of national data combined with local data to minimise the local data requirements. This can be illustrated with reference to the following table. Table 4.2:

Tour and PA modelling data requirements.

Return time period

Outbound time period

AM

IP

PM

OP

Total

AM IP PM OP Total

Consider a particular zone pair, mode and demand segment. For tour-based modelling we need to know the proportion of trips for each of the 16 unshaded cells in the table, e.g. 45% of commuting trips by car go out in the AM peak and return in the PM peak. However, typically we may only know the proportions in the shaded cells, e.g. 70% of commuting trips by car go out in the AM peak. The approach used in DIADEM is to take initial estimates for the unshaded cells (also called tour proportions), for which local information may not be available and to use local data for the shaded cells to furness the unshaded cells. Initial estimates for the tour proportions cells (by purpose and mode) have been calculated from National Travel Survey (NTS) and reproduced in Appendix C for information. The user then needs to just specify local data for the shaded cells. These tour proportions are used slightly differently in the incremental and absolute implementations of the model. In the incremental version the tour proportions are applied to the input reference 24 hour PA matrix to obtain reference tour matrices by outbound and return time periods. The tour proportions have no further use as the information they contained is now in the reference tour matrices. The application of time period choice in the incremental model may subsequently change the number of trips in each outbound/return time period combination. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

30

DIADEM User Manual Version 5.0 (SATURN)

In the absolute version no reference matrix is input, just the trip ends. The tour proportions are therefore used to segment the trip ends by each outbound/return time period combination. (Note that for the doublyconstrained model the constraints are always applied summed over all time periods and modes). 4.5

Public transport in DIADEM

DIADEM has a simplified representation of public transport (PT). Mode choice in DIADEM is a simple two way choice between car and PT. If a more detailed representation of mode choice is required this will need to be represented outside DIADEM. Examples might include modelling the choice between bus and rail, or looking at park and ride submodes. In many cases it will be possible to use the public transport assignment model for these choices and to use DIADEM for main mode choice and other demand responses – please contact DIADEM support for advice. A second simplification is that DIADEM assumes that PT costs are not demand responsive. DIADEM will carry out a highway assignment every time it adjusts demand to see how costs are affected, but assumes PT costs remain unchanged. This has two implications: ƒ The level of crowding, if modelled, is assumed to remain constant and will not change as public transport passenger numbers change. ƒ Bus travel times are not automatically linked to changes in highway travel times.

If either of these effects is significant then it might be necessary to include an additional manual outer loop in the DIADEM process, for example: 1. Obtain an initial set of forecast PT costs for input to DIADEM 2. Run DIADEM with these PT costs 3. Based on DIADEM outputs (PT passenger demand, highway travel times) update the forecast PT costs and, if they have changed for those previously input, rerun DIADEM 4. Repeat as necessary until PT costs have stabilised WebTAG states that it is acceptable to use fixed PT costs where the mode share is less than 5%. As noted above it will also be acceptable if a) crowding is not significant and b) travel times for the PT mode(s) being considered do not depend significantly on highway travel times. In all other cases a manual outer loop similar to that described above will be required. Note that although PT costs remain fixed within a given DIADEM run, they can change between different DIADEM runs to reflect different scenarios, whether that it due to changes in the individual cost components (e.g. reduced travel times as a result of infrastructure improvements) or changes in the cost coefficients (e.g. increased values of time as a result of incomes increasing over time).

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

31

DIADEM User Manual Version 5.0 (SATURN)

4.6

Segmentation in DIADEM

4.6.1

Demand segments

DIADEM demand models operate with two levels of segmentation: trip purpose and person type. This is illustrated with an example in Figure 4.10. Total travel is first split into 3 purposes: commute, employer’s business and other. Travel within each purpose is then further divided into trips made by two distinct person types, those with a car available for the trip and those without. Figure 4.10: Segmentation by trip purpose and person type

All Travel

Commute

Car avail.

No car

EB

Car avail.

Other

No car

Car avail.

No car

As well as car availability the other common division of person types is according to income or willingness to pay bands, for example to model the response to road tolling. This can also be represented in DIADEM. Each trip purpose is treated independently for demand modelling. For example, in a doubly-constrained distribution model distinct trip end constraints are used for each purpose and are applied separately. The way person types are grouped into trip purposes only matters when a doubly-constrained distribution model is being used. In this case the trip end constraints are applied at the purpose level, not to individual person types within that purpose. This can be seen as different person types competing for a single set of trip ends. Each person type can have its own demand model structure and associated parameters. The only restriction is that if one person type within a purpose has a doubly-constrained distribution model then all person types within that purpose must have one. Person types can be marked as being ‘car not available’. Mode choice is not modelled for these person types; they are assumed to be captive to public transport. The main reason for including such person types would be to ensure that they are included in the competition for trip ends in a doubly-constrained distribution model. The purpose/person type combinations used in the demand model have to be mapped to the different user classes in the assignment model. This is described in detail in section 6.4. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

32

DIADEM User Manual Version 5.0 (SATURN)

In the rest of this document the term ‘demand segment’ is used to refer to a particular purpose/person type combination. Demand segments can also represent a particular vehicle type. For example HGVs can have their own demand segment which may be treated as having fixed demand, i.e. no variable demand model is applied. 4.6.2

Time periods

If time period choice is modelled then time periods will be linked together through the structure of the model hierarchy. If time period choice is not modelled then the demand model is generally applied independently to each time period (for OD modelling) or each combination of outbound and return time period (for PA modelling). The exception is when the doubly constrained distribution is used, in which case the constraints are applied summed across all time periods.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

33

DIADEM User Manual Version 5.0 (SATURN)

5. Preparation for a DIADEM run

5.1

Overview

Chapter 6 sets out the process of setting up a DIADEM run in detail. This chapter describes some of the data preparation required before starting the DIADEM software and gives a brief overview of the DIADEM set up process. DIADEM will need to be run separately for each scenario (Do-Minimum (DM) and Do-Something (DS)) and forecast year. The data preparation and DIADEM set up are slightly different for absolute and incremental models and are set out separately in the following sections. Note that it is possible to mix absolute and incremental model demand segments within the same DIADEM run. Simplified representations of a DIADEM run are shown in Figure 5.1 to Figure 5.3 at the end of this chapter, representing an incremental model pivoting off the base year, an incremental model pivoting off the Do-Minimum, and an absolute model respectively. The shaded boxes represent information specified by the user via the interface program. The iterative loop is shown within the dotted line and is controlled by DIADEM. A summary of trip and cost data requirements for the different types of demand model is shown in the table below. Table 5.1:

Summary of trip and cost data requirements

Incremental model

Reference trips

OD

PA

Required (by time period)

Required (24 hr PA)

Absolute model OD

PA

Not required

Required

Required when trip ends are defined rather than ‘initial guess’

Trip ends

Not required

Either trip ends or ‘initial guess’ matrix is required.

Initial guess matrix

Not required

Reference costs

Initial tour proportions, outbound and return time period proportions

Not required

Required

Not required

Required

An absolute model with HADES requires the following additional trip data: ƒ Profile of trips over preferred arrival time windows for each HADES demand segment/time period ƒ Profile of trips over time slices for each non-HADES demand segment/time period 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

34

DIADEM User Manual Version 5.0 (SATURN)

5.2

Incremental model

Before running DIADEM you will need, at least, the following: ƒ Assigned validated base year highway networks (if pivoting off the base) ƒ Assigned DM highway networks (if running the DS and pivoting off the DM) ƒ Forecast year reference highway trip matrices ƒ Forecast year/scenario (e.g. 2016 Do-Minimum) network data files ƒ Details of the demand model structure you want to set up

If you are doing mode choice modelling, or are modelling non-car available demand segments, you will also need the following public transport (PT) data: ƒ Forecast year reference trip matrices ƒ Forecast year/scenario travel times and, optionally, fares ƒ Reference case travel times and, optionally, fares

The following is a brief summary of the steps required in setting up and carrying out a run of DIADEM. Further explanation of the steps involved and terminology is given elsewhere in the manual and in WebTAG. 1. Consult WebTAG and decide on the appropriate segmentation and demand model structure and parameters. 2. Prepare forecast network data file(s) for the scenario and year you are planning to model. 3. Prepare the reference trip matrix/matrices: a. If pivoting off the base year these will be unrestrained growth forecasts from, e.g., applying TEMPRO to the validated base year matrix. b. If running the DS and pivoting off the DM these will be the forecast trip matrices output by the DIADEM DM run. 4. Locate previous assignments from which reference costs can be obtained: a. If pivoting off the base year these will be the base year assignment. b. If running the DS and pivoting off the DM these will be the costs from the assignment of the forecast DM matrix produced by DIADEM. 5. If using a mode split model, or modelling non-car available person types, then carry out PT assignments for the scenario and forecast year you are modelling and skim forecast costs (fare and generalised time). Repeat for the scenario from which reference costs will be obtained (base year if pivoting off 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

35

DIADEM User Manual Version 5.0 (SATURN)

base, DM if pivoting off DM). 6. Using the DIADEM interface set up the DIADEM data using the segmentation and demand model structure and parameters that you decided upon at step 1 and using the reference trip and cost matrices, and PT forecast cost matrices (if applicable) you obtained above. 7. Save the DIADEM control file. 8. Click the Run DIADEM button. 9. When the DIADEM run has completed check the output .csv file to ensure that convergence is acceptable. Use matrices with ‘best’ appended to the file name for all further analysis. Check the log file for warning messages. 5.3

Absolute model

Before running DIADEM you will need, at least, the following: ƒ Forecast year trip ends (absolute model) or an initial guess of the full trip matrix for the year you are modelling ƒ Forecast year/scenario (e.g. 2016 Do-Minimum) network data files ƒ Details of the demand model structure you want to set up

If you are doing mode choice modelling, or are modelling non-car available demand segments, you will also need the following public transport (PT) data: ƒ Forecast year/scenario travel times and fares ƒ Forecast year reference trip matrices

If you are specifying trip ends rather than an initial guess matrix then you will also need to provide some reference costs for DIADEM to carry out an initial distribution of the trip ends. These will usually come from the modelling results of some other year/scenario that has already been carried out, for example the base year model, the do-minimum model when modelling the do-something, or the scheme opening year when modelling the design year. The following is a brief summary of the steps required in setting up and carrying out a run of DIADEM. Further explanation of the steps involved and terminology is given elsewhere in the manual and in WebTAG. 1. Consult WebTAG and decide on the appropriate segmentation and demand model structure and parameters. 2. Prepare forecast network data file(s) for the scenario and year you are planning to model. 3. If using a mode split model, or modelling non-car available person types, then carry out PT assignments for the scenario and forecast year you are modelling and skim forecast costs (fare and 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

36

DIADEM User Manual Version 5.0 (SATURN)

generalised time). 4. Using the DIADEM interface set up the DIADEM data using the segmentation and demand model structure and parameters that you decided upon at step 1 and using the reference trip and cost matrices, and PT forecast cost matrices (if applicable) you obtained above. 5. Save the DIADEM control file. 6. Click the Run DIADEM button. 7. When the DIADEM run has completed check the output .csv file to ensure that convergence is acceptable. Use convergence results to pick ‘best’ DIADEM matrix and use this for all further analysis. Check the log file for warning messages.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

37

DIADEM User Manual Version 5.0 (SATURN)

Figure 5.1:

Structure of a DIADEM run, incremental model pivoting off the base year. (Shaded background indicates user-specified input.)

Base year validated trip matrices

TEMPRO growth

Reference trip matrices (PT & HW)

Demand model structure and parameters

Base year validated assignments

Skimming

Reference cost matrices (PT & HW)

Demand model

Forecast PT costs

Forecast cost matrices (PT & HW)

Forecast trip matrices

Skimming

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

38

Forecast highway assignment

Forecast highway network files

DIADEM User Manual Version 5.0 (SATURN)

Figure 5.2:

Structure of a DIADEM run, incremental model pivoting off the Do-Minimum. (Shaded background indicates user-specified input.)

DM DIADEM output matrices

Unmodified

Reference trip matrices (PT & HW)

Demand model structure and parameters

DM DIADEM assignments

Skimming

Reference cost matrices (PT & HW)

Demand model

Forecast PT costs

Forecast cost matrices

Forecast trip matrices

Skimming

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

39

Forecast highway assignment

Forecast highway network files

DIADEM User Manual Version 5.0 (SATURN)

Figure 5.3:

Structure of a DIADEM run, absolute model. (Shaded background indicates user-specified input.)

Demand model structure and parameters

HADES data (optional)

Demand model

Forecast PT costs

Forecast cost matrices

Trip ends and reference costs (PT & HW)

OR

Initial guess matrix (PT & HW)

Forecast trip matrices

Skimming

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

40

Forecast highway assignment

Forecast highway network files

DIADEM User Manual Version 5.0 (SATURN)

6. Entering DIADEM data

6.1

Overview

DIADEM input data is set up from a Windows interface. As discussed earlier, some external preparation of data files is required beforehand. The data set up in the DIADEM interface can be saved to the DIADEM control file. The data does not need to be complete to be saved; indeed it is recommended that data is saved regularly as you go through the data set up process. Saved files can of course be opened later. Saving and opening files is done through the File menu or via the Save and Open toolbar buttons. The interface consists of a number of separate pages. Sections 6.4 onwards describe the data requirements for each of these pages in turn. All data should be entered for a page before moving on to the following page. 6.2

The DIADEM Control file

6.2.1

Overview

All data entered via the GUI is saved to a control file. Control files are saved and opened using the familiar File>Open, Save and Save As menu commands. New files are created using File>New. From version 3 onwards of DIADEM, control files are in xml format and have a .xml extension. xml stands for eXtensible Markup Language. The basic idea of xml is that it uses tags in angle brackets to identify and describe the data. For example: 5.0 indicates that the data item ‘version’ takes a value of 5.0 (i.e. this control file is from DIADEM version 5.0). It is by no means necessary to understand xml to be able to use DIADEM. All editing of data can (and in most cases should) be done through the DIADEM GUI and there is no need to work with the xml files directly. If you do want to find out more there is plenty of material on the internet (a search for ‘xml tutorial’ will bring up some possibilities). 6.2.2

Viewing xml data

The control file data can also be viewed via the menu option View>Data as tables. This displays the data in your default internet browser. It can then be printed or copied to a word processor (for example). This could be useful if you want someone else to review the file or to include it in a report. 6.2.3

Editing xml data

It is recommended that all editing of DIADEM data is done via the GUI, as this will ensure that the integrity of the data is maintained. However, other methods of editing xml data are available and may be used if 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

41

DIADEM User Manual Version 5.0 (SATURN)

only very minor changes are required, e.g. altering a file name or parameter values. Major changes involving altering the structure of the model, such as adding a demand segment, should not be made in this way. xml files can be opened and edited in any standard text editor. However, it is far easier to use an editor specifically designed for use with xml as these will interpret the file so that the data can be displayed in a more structured way which makes it easier to distinguish between the tags (which shouldn’t be changed) and the data itself (which can be). A huge number of xml editors is available on the internet, many of which are free for commercial use. Please contact DIADEM support if you require further advice in this area. 6.2.4

Backwards compatibility

DIADEM 5.0 can open control files created in all previous versions of DIADEM. This includes plain textbased control files created using version 2.1. However, it will always save control files in DIADEM 5.0 xml format. 6.3

General information

Before entering the data page by page the choice between using SATURN and CONTRAM assignment models should be made.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

42

DIADEM User Manual Version 5.0 (SATURN)

6.4

Page 1: forecast network files(s) and segmentation

Figure 6.1:

Page 1: Segmentation (SATURN version)

The first step is to define the time periods that are being modelled. Time periods can be further divided into time slices. Time periods are intended to be fairly long, say the whole of the AM peak (e.g. 0700-1000) or the inter-peak (e.g. 1000-1600), whereas time slices are typically much shorter, say 10 to 30 minutes long. The main purpose of timeslices is to provide a profile of demand and travel costs within the time period for the HADES arrival time choice model. Before the HADES option was introduced it was standard practice to use one time slice per time period. Note that the main demand model operates at the time period level using costs averaged over all time slices in the period, with demand by time period then being split to time slices either using HADES, or by applying user-defined profiles, depending on the options selected by the user. A SATURN network file (.dat) must be defined for each time slice, representing the scenario you are forecasting. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

43

DIADEM User Manual Version 5.0 (SATURN)

To define a time period you can: ƒ Access the time period menu (on the main menu or right click in the time period box ) and select ‘Add Time Period’, or ƒ Click the ‘Add Time Period’ toolbar button

Time periods can be renamed and deleted via the same time period menu. To define time slices and, simultaneously, specify the SATURN network file for the time slice choose ‘Add time slice/SATURN Network’ from the right click menu. If time slices are linked using the PASSQ option then this can be indicated using the check box above the time periods box. It is strongly recommended that this is selected if the HADES model is to be used, otherwise there is a significant risk that the FIFO principle (first-in first-out) will be violated. If selected, PASSQ will be applied within each time period but not between time periods. NB: If you are using the option to run SATURN assignments in parallel (see Section 6.11) then you must put the SATURN network files for each time period in a separate directory. This will reduce the risk of file opening errors, with different SATURN programs trying to access the same file at the same time.

It is also necessary to specify the duration of each time slice. This is done by right clicking on the SATURN network file name for the time slice and choosing ‘Change Duration’. For the first time slice in the period the start and end times must be defined, using the 24 hour clock (e.g. 0800, 1700 etc.). For subsequent time slices in the period only the end time needs to be defined (the assumption is that time slices are contiguous, so the start time of each time slice must be the end time of the previous one). The specified durations must cover the full period represented by the assignment model, even if the model is only an average hour from that period. For example if the inter-peak period from 1000 to 1600 is modelled with a single time slice representing an average hour within the period then the start and end times of the time slice should be entered as 1000 and 1600 respectively. When using PA modelling it is important that together the time periods cover a full 24 hour period. In the current version of DIADEM there are some restrictions on the way the SATURN network files should be set up: ƒ PASSQ should be set to FALSE within the .dat file. If you want to link time periods using the PASSQ option you should check the ‘Use PASSQ’ box in DIADEM.) ƒ SAVEIT should be set to TRUE, if you want to skim average costs (see section 6.6). ƒ FILTIJ (i.e. the trip matrix name) should not be specified. ƒ The GONZO parameter should be set to 1.0 (the default).

DIADEM will check how many user classes are specified in the first SATURN network and set up the correct number of user classes in the user class window. The user classes can be renamed via the user class menu (main menu or right click).

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

44

DIADEM User Manual Version 5.0 (SATURN)

It is then necessary to define the correspondence between assignment user classes and purposes. It is possible for more than one purpose to be grouped into a single user class, perhaps to minimise assignment run times. Each demand segment can have a completely different demand model but to keep run times down it may be desirable to aggregate some demand segments together for the purposes of assignment. For example there may be demand segments of ‘home-based employer’s business’ and ‘non home-based employer’s business’, which are combined in a single ‘employer’s business’ user class for assignment. Thus the time and distance skims used in the demand model will be the same for each demand segment within the user class. Purposes are added to user classes by right clicking on the user class and selecting ‘Add Purpose’. Once they have been created Purposes can be deleted and renamed. At least one Purpose must be created for each user class. One person type is automatically created for each purpose. Additional person types can be added by right clicking on the purpose and choosing either ‘Add Person Type’ or ‘Add No Car Person Type’. DIADEM does not include trips for ‘no car’ person type in the matrices used in the SATURN assignment. The right click and Purpose menus can be used to rename and delete purposes and person types. Having completed the Segmentation page it is then possible to move to the next page – Model Parameters.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

45

DIADEM User Manual Version 5.0 (SATURN)

6.5

Page 2: Model Parameters

Figure 6.2:

Page 2: Model Parameters (SATURN version - CONTRAM version is very similar).

This page is used to define the demand model structure and associated parameters for each demand segment. 6.5.1

Defining the demand model type

The first step on this page is to specify the type of demand model used for each purpose. Initially all purposes appear in the Fixed Purposes box. Trip purposes to be treated as variable demand then need to be dragged to one of the other boxes, depending on the desired type of demand model (incremental or absolute, OD or PA, or even simple elasticity). The data that needs to be filled in on the rest of the page then varies according to which model form has been selected.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

46

DIADEM User Manual Version 5.0 (SATURN)

6.5.2

Model hierarchy

The demand segment is selected using the drop down box at the top of the page. The numbering of demand segments is determined by the order in which they are added to the Segmentation page. The model hierarchy needs to be specified for all variable demand segments (except those using an elasticity model). The available model responses appear in the left hand side of the Model Hierarchy frame. The right hand side of the frame displays the responses that DIADEM will model; this is initially blank. Model responses are added to the right hand side by either double clicking the response on the left or highlighting the response and clicking the button between the two boxes. Deselecting responses works in a similar way. There are certain restrictions on which combinations of choices can be selected for each demand segment: ƒ Only one form of distribution model can be selected ƒ Frequency can only used in incremental models and can only be selected if a distribution option is also selected ƒ No responses can appear above frequency ƒ HADES is only available in absolute models and, if selected, must be at the bottom of the hierarchy.

The different distribution options are discussed in Section 4.1.6. The hierarchy of responses is also defined in this box. To change the position of a response in the hierarchy highlight it with a left mouse click and then use the up or down button to move it. The most sensitive response should be at the bottom of the hierarchy and the least sensitive at the top. This should be reflected in the values of the parameters associated with each response (see below). Once all the data has been defined for a particular demand segment it is possible to move on to the next one. This can be done in a number of ways: ƒ Select a different demand segment from the drop down box ƒ Click the ‘Go to next DS’ button to go to the next demand segment ƒ Click the ‘Copy to next DS’ button to copy the settings from this demand segment to the next. This can be useful when setting up the data for the first time as there will often be only small differences in the parameters for different demand segments. 6.5.3

Parameters

Model parameters must be defined for each of the selected responses (the parameter boxes for responses not selected will be greyed out). For the logit-based models the spread (or dispersion) parameter λ must be defined for the choice at the bottom of the hierarchy. λ must be negative.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

47

DIADEM User Manual Version 5.0 (SATURN)

For choices above the bottom the scaling parameter θ must be defined. For each level this determines the sensitivity of the response relative to the level below. θ must be greater than zero and less than or equal to 1. It will be clear from which boxes are greyed out for each response whether θ or λ needs to be defined. See Section 5.1 for an explanation of θ and λ. Illustrative parameter values can be found in Section 1.11 of WebTAG Unit 3.10.3 (Variable Demand Modelling - Key Processes), or they can be calibrated locally if suitable data are available. In general, the appropriate value of λ depends on the units used for generalised cost. DIADEM always uses generalised minutes – this is consistent with the illustrative parameters in WebTAG. In accordance with WebTAG advice when mode choice appears above distribution in the hierarchy it is possible to define separate distribution parameters for car and PT modes. If mode choice is below distribution then only a single parameter can be defined. The elasticity model uses the Tanner function (see Appendix B.3) so two parameters are needed, although often one of them will be zero. The first parameter, λ, corresponds to the exponential part of the function and the second parameter, γ, to the power function. Thus to implement a power elasticity function set λ to zero, and to implement an exponential elasticity function set γ to zero. Non-zero parameters must be negative . Note that λ corresponds to the B parameter in the WebTAG notation and γ corresponds to the A parameter. Parameters relating to the use of the HADES model (if selected) are defined separately, on the ‘HADES Data’ page. 6.5.4

Advanced distribution options

There are two features available under the advanced distribution options: calculating intra-zonal costs and spatial segmentation. Assignment models have trouble producing costs for intra-zonal trips and will typically return a value of zero. Even when a non-zero value is returned it may not be reliable. However, redistribution of trips between inter and intra-zonals is a possible response. To model this correctly a reasonably accurate intrazonal cost is required. DIADEM estimates this as a factor ρ multiplied by the minimum inter-zonal cost. ρ=0.5 is a sensible value to use. It is possible to define a minimum intra-zonal cost. This can be useful if, for any reason, the inter-zonal costs in the network model are not accurate (e.g. the minimum inter-zonal cost may be zero because of unusual centroid connector configurations for adjacent zones).

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

48

DIADEM User Manual Version 5.0 (SATURN)

For incremental models intra-zonal costs are only relevant if there are intra-zonal trips in the reference matrix. If this is the case it is important that the intra-zonal trips are a reasonable estimate and not just an artefact of matrix building procedures. For absolute models it is recommended that intra-zonal cost estimation is always used. Spatial segmentation is a feature in DIADEM whereby the distribution model parameter (λ or θ, depending on its position in the hierarchy) can vary according to the zone pair. When this option is selected the distribution parameters are defined in a separate file, which has the following comma-separated variable format: origin sector, destination sector, demand segment, mode, distribution model parameter The zone to sector correspondence list is defined on the PA Model Data page. Mode=1 for highway and mode=2 for PT; mode=0 can be used in cases where distribution is above mode choice in the hierarchy to indicate that the parameter is not segmented by mode. Note that the options selected on this page apply to all demand segments. 6.5.5

Generalised cost coefficients

The generalised cost function used in DIADEM is: ppk ⋅ d + toll ⎞ ⎛ 60 ⋅ ⎜ t + ⎟ VOT ⎝ ⎠

for highway trips

fare ⎞ ⎛ 60 ⋅ ⎜ t + ⎟ VOT ⎝ ⎠

for PT trips

where t d toll fare ppk VOT

is the time in hours is the distance in kilometres is the toll (or parking charge) in pence is the PT fare in pence is the vehicle operating cost in pence per kilometre is the value of time in pence per hour

t, d, toll and fare are obtained by DIADEM by automatically skimming the costs, or via user-supplied files (see subsequent input pages for details). On this screen it is necessary to define the value of time and, for highway trips, the vehicle operating cost coefficient. Values of time and vehicle operating costs for the calculation of the cost coefficients can be found in WebTAG Unit 3.5.6 (‘Values of Time and Operating Costs’). 6.5.5.1

Differences between reference and forecast cost coefficients

In an incremental demand model the forecast demand depends on the difference between the latest forecast generalised cost from the scenario currently being modelled and a reference generalised cost. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

49

DIADEM User Manual Version 5.0 (SATURN)

When pivoting off the base year the reference cost coefficients must be the base year coefficients. The forecast cost coefficients must be the future year coefficients. Values of time increase in the future as a result of increasing incomes. Similarly, operating costs change as a result of changing fuel costs and improved vehicle efficiency. These changes should be accounted for when calculating cost coefficients for future years. This means that VOT and VOC values for the ‘forecast’ scenario should be different from the ‘reference’ values, when pivoting off the base year. When modelling the DS by pivoting off the DM they would normally be the same. The most common exception to this would be if fuel costs change between DM and DS, as would be the case when undertaking realism testing (see Section 8.1.2). See section 4.1.5 for a fuller discussion of pivoting. 6.5.5.2

Using assignment costs (SATURN)

Wherever possible it is recommended that the same generalised cost function is used in the assignment and demand models. Otherwise there may be problems achieving convergence. If the ‘Use Assignment Costs’ option is checked then DIADEM will skim the total generalised cost from the SATURN model. Implicitly this means that the same values of time (PPM parameters) and vehicle operating costs (PPK parameters) will be used in the assignment and demand models. Future year PPM and PPK values will need to be adjusted to reflect changes in values of time and fuel costs, as discussed above. The use of this option is recommended unless there is particular requirement to use different cost functions in the demand and assignment models. This option cannot be used if cost damping is to be applied. If this option is selected for all car-available variable demand segments then the user can choose between skimming costs on the minimum cost path, or as an average over all used paths. (This choice is made on the Highway Reference Trip/Cost data page. See Section 6.6.4 for more information and advice on the preferred option.) Otherwise only the ‘average’ option is available. All money charges specified in the network data files, such as tolls, must be in the same price base in all networks, even if they relate to different modelled years. 6.5.5.3

Units for PT time and fare skims

Unlike highway costs, PT cost components are a user input and DIADEM has no control over which units are used. DIADEM therefore needs to know which units have been used in the input time and fare matrices so that it can calculate generalised costs correctly. Input time skims may be in hours, minutes or seconds, and fare skims may be in pounds or pence 6.5.5.4

Including the full trip costs

For absolute demand models and/or if cost damping is being used it is particularly important that the generalised cost for each zone pair represent the full trip costs, i.e. the costs on the centroid connector must be an accurate representation of the costs of that section of the trip that does not take place on the 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

50

DIADEM User Manual Version 5.0 (SATURN)

main model network. Similarly, on the PT side it is important that fares and times are included so that the full costs are taken into account by the model. 6.5.5.5

Cost damping

Cost damping is explained in Section 4.3.2. Clicking the ‘Cost Damping’ button brings up the following data input screen:

Parameters are defined by trip purpose and by mode.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

51

DIADEM User Manual Version 5.0 (SATURN)

The default parameters are such that cost damping does not actually alter the cost compared to the undamped value. This means that if you want to use, say, the ‘power function of cost’ damping mechanism you only need to change the parameters in that section. Note that the ‘varying non-working time by distance’ option should, by definition, not be applied to employer’s business trips. Also, it should not be used at the same time as the log plus linear cost method for a given demand segment. The following restrictions apply to the parameter values: Table 6.1:

Restrictions on values of cost damping parameters

Parameter(s)

Acceptable values

k, μ, δ

>0

d’, dc, d0, ε, γ

≥ 0; if d’ > 0 then must have d’ = k

α, nc

≥0, < 1, α + nc < 1

β

>0, ≤ 1

Clicking the Reset option will make all parameters revert to their default values and, in effect, turn off cost damping. The following table shows the default values for each cost damping function: Table 6.2:

Parameter values needed to turn off cost damping options

Damping option

Parameter values to turn off (defaults)

Function of distance

k = 1, α = 0, d’= 0

Power function of cost

μ = 1, β = 1

Varying non-working time by distance

nc = 0, dc = 0, d0 =1

Log plus linear cost

ε = 0, δ = 0.1, γ=0

The four text boxes at the bottom of the screen are used to define the shortest distance for each OD pair. This information is only required if the ‘damping by a function of distance’ or ‘varying non-working value of time by distance’ is being used, i.e. if either α or η is changed from its default value of zero. A file should be defined for reference and forecast, for highway and PT trips (the actual file used in each case may be the same). These files should be in ‘TUBA format 2’ i.e. comma-separated variable: origin zone, destination zone, distance (in kms) 6.5.6

Occupancy

Occupancy is used to convert between vehicle trips and passenger trips when calculating mode choice. It represents the average number of private vehicle occupants for the demand segment. It should be greater than or equal to 1. If the input reference highway trips are in units of pcus then the occupancy should be the average number of occupants per pcu unit; if they are in units of vehicles then it should be the average number of occupants per vehicle.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

52

DIADEM User Manual Version 5.0 (SATURN)

6.6

Page 3: Highway Trip/Cost Data

Figure 6.3:

6.6.1

Page 3: Highway Trip/Cost Data (SATURN version)

Overview

This page is used to define the highway reference demand and cost data, which is used mainly for incremental demand models. However, reference costs are also needed for absolute demand models with trip ends defined. For an incremental model the reference data represent a hypothetical situation, i.e. if the forecast costs were equal to the reference cost then the demand would be equal to the reference demand. In other words it defines a point on the demand curve. However, it is not expected to represent the equilibrium situation for the current scenario; this is because when the reference demand is assigned to the network the output forecast costs will not be the same as the reference costs. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

53

DIADEM User Manual Version 5.0 (SATURN)

The incremental demand model in DIADEM adjusts the input reference demand according to the differences between the reference cost and the actual forecast costs. This process is know as pivoting (see Section 4.1.3 for more information). Reference trips should not be defined for demand segments using the absolute logit model. Reference costs may be needed, depending on the way the absolute model is set up, but have a different role from when they are used with an incremental model. When trip ends are defined for the absolute model the reference costs are used to produce an initial set of trip matrices to be assigned. They then play no further role in the model. For the absolute model the reference costs should represent the best guess of what the costs will be in the scenario being forecast. The more accurate the guess the less time DIADEM will take to converge. There are two main ways of setting up reference data for an incremental model: pivoting off the base year or pivoting off the do-minimum. Reference trips should be defined by time period, reference costs by time slice. Trips by time period are converted to trips by time slice in one of two ways: ƒ For demand segments and time periods which use the HADES model, the conversion is carried out as part of the HADES process. ƒ For all other demand segments and time periods the conversion is carried out using fixed demand profiles, as defined on the bottom of this page.

6.6.1.1

Pivoting off the base year

When pivoting off the base year the reference costs should come from the validated base year assignment. The reference demand should represent the unrestrained forecast of travel demand in the forecast year being modelled in DIADEM, i.e. assuming no change in costs. In the UK this would typically be obtained by taking the base year validated matrix and increasing it with factors obtained from TEMPRO (for cars and PT passenger travel) and other DfT forecasts for goods vehicles. For every non-zero cell in the reference trip matrix there must be a corresponding cost in the reference cost file. This may not be the case if, for instance, the reference trip matrix contains OD trips that do not exist in the base matrix. Therefore zoning systems in the base and forecast networks must be the same, even if some zones do not have any trips in the base matrix. 6.6.1.2

Pivoting off the DM

Pivoting off the DM requires that DIADEM has already been run for one scenario for the year under consideration. Typically the DM would have been pivoted off the base year (see above). When running DIADEM for the do something (DS) in the same year it is possible to pivot off the DM rather than the base year . In this case the reference demand should be the trip matrix output by the DM DIADEM run and the reference costs from the assignment of that matrix to the corresponding DM network. The advantage of this approach is that DIADEM should be starting at a point closer to the DS equilibrium and thus converge more quickly. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

54

DIADEM User Manual Version 5.0 (SATURN)

WebTAG recommends pivoting off the DM when modelling the DS. 6.6.1.3

Pivoting summary

The following table summarises how the reference data can be obtained according to whether the base year or DM is used as the pivot point:

Pivot

Reference costs

Reference cost coefficients

Forecast cost coefficients

Reference demand

Base year

Base year costs

Base year coefficients

Forecast year coefficients

Unrestrained growth from base year to forecast year applied to base year matrix

Do-minimum

DM costs from converged DIADEM run (same forecast year)

Forecast year coefficients

Forecast year coefficients

DM demand from converged DIADEM run (same forecast year)

Innumerable pivoting options are possible but the above are the most common. 6.6.2

Important note on reference costs

It is important that reference costs for incremental models are defined for all origin/destination/time period/demand segment/mode combinations that have non-zero trips in the reference trip matrix. The most common reason for not doing this occurs when the forecast network has additional zones that are not in the networks used to provide the reference costs. All networks in DIADEM (reference and forecast, PT and highway) must have the same zoning system. An example of this is as follows. Suppose we are pivoting off the base year (i.e. reference costs are skimmed from the base year assignments) and additional development zones are added to the forecast networks. In this case no reference costs are available to and from the development zones and the demand model calculations will be incorrect. The solution in this case is to make sure the development zones are included in the base year network, even if there are no trips in the base year matrix. This will ensure that reference costs can be skimmed for all necessary movements. When used with absolute demand models, reference costs must be available for every zone pair. 6.6.3

Entering data

Highway reference trip data must be defined for each car-available demand segment and time period for which an incremental model is used. Potentially there are a large number of combinations of demand segments and time periods so DIADEM uses a file naming convention to reduce the data entry requirements on this screen. Reference trip data file names for OD-based modelling have the format: ????_TX_DSY.dat for time period X and demand segment Y. ???? is any user-defined string; X and Y are integers. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

55

DIADEM User Manual Version 5.0 (SATURN)

Note that the above data is defined by time period then split by time slice using either HADES (if selected) or user-defined profiles (otherwise). For PA-based modelling the reference trips should be in the form of a 24 hour PA matrix, therefore the file name excludes any reference to the time period: ???? _DSY.dat Note that in the PA reference matrix a value of 1 gives two OD trips: one from the production zone to the attraction zone and another in the reverse direction. Note that Y refers to the number of the demand segment as used in the drop down box on the Model Parameters page. The numbering of demand segments is determined by the order in which they are added to the Segmentation page. The demand segment number for each purpose/person type combination can be viewed in the Demand segment drop-down box on the Model Parameters page. Rather than specifying the file name separately for each individual demand segment and time period combination it is only necessary to define the ‘root’ name (???? in the above examples) and the directory where the files are located. For example suppose the reference trip files take the form ‘reftrip_TX_DSY.dat’ then just ‘reftrip’ is entered in the ‘Trips’ box on this screen. reftrip_T1_DS3.dat would be the reference trip matrix for time period 1, demand segment 3. The format used in these files is a comma-separated variable format with three numbers on each line representing the origin zone, destination zone and matrix value. For example: 101,102,23.5

104,103,42.1

defines a value of 23.5 from zone 101 to zone 102 and a value of 42.1 from zone 104 to zone 103. This is the same as TUBA format 2. It is important to note that in the SATURN version of DIADEM zone names rather than sequential numbers should be used in all input matrices. DIADEM relies on the reference trip matrix to build up a complete list of zone names. Therefore each zone name should appear at least once in the reference trip matrix. If, for some reason, there are zones with no trips to or from them in the reference matrix then the simplest thing to do is to add them as an intra-zonal OD pair with zero trips, e.g. for zone 101 put 101,101,0 in the reference trip matrix file. OD trip matrices should be defined in units of vehicle or pcu trips per hour. PA matrices should be total vehicle or pcu PA trips over the 24 hour period (remembering that a value of 1 in a PA matrix cell implies one outbound trip and one return trip in 24 hours). If vehicle trips are used then the occupancy on the Model Parameters page should be occupancy per vehicle; if pcu trips are used then it should be occupancy per pcu. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

56

DIADEM User Manual Version 5.0 (SATURN)

There are two available methods for entering reference cost matrix (SATURN GC, time and distance) data: Method 1: This is similar to the way reference trip matrix data is entered. Reference cost data must be defined for each user class and time period. As for reference trips, a file naming convention is used as follows: ????_TSX_UCY.dat for time slice X and user class Y. (Note that OD costs should be defined in this format even for demand segments using PA modelling; DIADEM will calculate PA costs from OD.) The root ???? is defined separately for SATURN GC, time, distance and (optionally) toll matrices. Note that reference trips are defined by demand segment and reference costs by user class. For example, suppose the root is defined as ‘refTime’ then DIADEM would expect the file refTime_T1_UC2.dat to contain reference times for time period 1, user class 2. The units used should be hours for SATURN GC and time, kilometres for distance, pence for tolls.

Method 2: This method is simpler than Method 1 and reduces the risk of errors being introduced due, say, to skimming costs in incorrect units. For each time slice a SATURN UFS file must be defined, from which DIADEM will skim the reference costs automatically. For instance, if you are pivoting off the base year then you would specify the UFS files for the base year assignment. If you are skimming an average over used paths (see section 6.6.3) the corresponding SATURN output UFC file(s) must be in the same directory as the UFS file(s), but do not need to be defined by the user. Reference costs and trips for non-car available demand segments are specified on the PT Trip/cost data page. 6.6.4

Skimming costs with SATURN

There are two options for skimming costs from SATURN assignments: ƒ Averaging (flow-weighted) over all used paths (so-called ‘forest’ skims), and ƒ Skimming the current minimum cost path only

In a perfectly converged assignment the generalised costs skimmed using the two methods are identical. However, individual components (time, distance, toll) are unlikely to be. The minimum cost path option is recommended, provided that a) the assignment converges very well (e.g. assignment gap of 0.1% or less) and b) the demand model uses the same cost function as the assignment (which also precludes the use of cost damping). Indeed this option will be greyed out unless the latter condition is true for all variable demand car-available demand segments. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

57

DIADEM User Manual Version 5.0 (SATURN)

In other situations the ‘average’ option should be selected. When using this option, it is essential that the SAVEIT assignment carried out in SATURN is as accurate as possible, to minimise the amount of noise in the costs passed to DIADEM. This usually requires setting the SATURN parameter NITA_S sufficiently high. For more information see Section 15.23 of the SATURN manual (version 10.9). Skimming average cost paths can take much longer than minimum costs. If the reference cost matrices are input manually into DIADEM (rather than letting DIADEM skim them from UFS files) they should be consistent with the skim method selected, e.g. if average skims are selected then the reference costs should represent average skims. 6.6.5

Demand profile for non-HADES segments and periods

This file is only needed if there is more than one time slice per time period. Since the main demand model operates at the time period level, DIADEM needs a way to disaggregate demand by time period from the demand model to demand by time slice for assignment. For HADES demand segments and time periods this is done using the HADES arrival time choice model. For other demand segments and time periods this is done with user-defined profiles. These are specified via an input file that is defined on this section of the page. The file should be in comma-separated variable (csv) format as follows: origin zone, destination zone, demand segment, time period, proportion of demand in first time slice within the time period, proportion of demand in second time slice in period, etc.. The first four values are integers; the rest are real numbers greater than or equal to zero and less than or equal to one. The sum of the proportions for a given origin, destination, demand segment and time period must equal 1.0. Data must be defined for all combinations of origin, destination, demand segment and time period for which HADES is not used.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

58

DIADEM User Manual Version 5.0 (SATURN)

6.7

Page 4: PT Trip/Cost data

Figure 6.4:

Page 4: PT Trip/Cost data

This page is only used if mode choice, or non-car available demand segments, are being modelled. DIADEM assumes that PT forecast costs (times and fares) do not change in response to changes in PT or highway demand, unlike highway costs. PT forecast costs are therefore fixed for the duration of the DIADEM process, whereas DIADEM automatically skims forecast highway costs from the latest assignment. PT reference and forecast costs, which may be different, must be input by the user. Reference trips and reference and forecast times must be defined for all car available demand segments for which mode choice is being modelled, and for all non-car available demand segments, for all time periods. Definition of reference and forecast fares is optional. However, it is recommended that they are always defined unless the reference and forecast fare cost coefficients are the same and the reference and forecast fares themselves are the same. All fares must be entered in the same price base (consistent with that used elsewhere, e.g. values of time), even if they relate to different modelled years.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

59

DIADEM User Manual Version 5.0 (SATURN)

Please see Section 7.6.1 for an explanation of reference costs and demand. The forecast times and fares are the times and fares for the scenario being modelled by DIADEM. By definition the PT reference demand for car-available demand segments should exclude any trips that are captive to public transport. DIADEM is designed to be used with outputs from any PT assignment package so a simple matrix format is used and it is assumed that each matrix file contains data for only one data type, demand segment and time period. The format used is a comma-separated variable format with three numbers on each line representing the origin zone, destination zone and matrix value. For example: 101,102,23.5

104,103,42.1

defines a value of 23.5 from zone 101 to zone 102 and a value of 42.1 from zone 104 to zone 103. This is the same as TUBA format 2. The files are defined as follows: select a data type from the drop down menu and specify a file name. Then select to which time period(s) and demand segment(s) the data applies, click on the appropriate check boxes. It is expected that cost data will quite often apply to more than one demand segment, and possibly time period, but it is unlikely that trip data will. It is possible that the same cost data apply to both the reference and forecast cases. In this situation the file only needs to be defined once provided the ‘Use reference costs as forecast costs’ box is checked. Having done all that click the ‘Use’ button – a summary of the input data then appears in the box in the bottom half of the page. Note that facilities to edit data once it appears in this box are currently limited, although lines can be deleted by right clicking on them and choosing ‘Delete Selected’ or ‘Delete All’. OD trip matrices should be defined in units of passengers per hour. PA matrices should be total passenger PA trips over the 24 hour period (remembering that a value of 1 in a PA matrix cell implies one outbound trip and one return trip in 24 hours). PT time matrices can be generalised time matrices and include components such as wait time, walk time and transfer penalties which may have been weighted. Some PT packages include fares when skimming generalised time. These can be used in DIADEM as long as care is taken that there is no double counting with the fare matrices. PT time matrices can be in hours, minutes or seconds and fare matrices may be in pounds or pence. The units used should be specified in the Generalised Cost Coefficients section of the Model Parameters page.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

60

DIADEM User Manual Version 5.0 (SATURN)

6.8

Page 5: PA Model Data

Figure 6.5:

Page 5 : PA Model Data

This page is used to define three file names related to PA/tour demand modelling. The files should contain the following data: File

Contents

Outbound proportions

The proportion of all trips that go out in each time period, defined by production and attraction sector, demand segment, and mode. These proportions are typically obtained from local survey data.

Return proportions

As outbound proportions, but for the return trips.

Tour proportions

An initial estimate of tour proportions, which will then be adjusted using the above data. Defines the proportion of trips going out and returning in each combination of outbound and return time periods, by origin and destination sector, demand segment and model. Typically these will based on the data file supplied with DIADEM (which comes from an analysis of NTS data) but in some cases may be based on local survey data. Note that the former assumes all zones are grouped together into a single sector.

The files need only contain data for demand segments for which PA-based demand modelling is being used, whether it is an incremental or absolute model. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

61

DIADEM User Manual Version 5.0 (SATURN)

For a description of PA modelling in DIADEM and more details of how the data in these files is used please see section 4.2. 6.8.1

File formats

All files are in comma-separated variable format as follows: Outbound and return time period proportions: production sector, attraction sector, demand segment, mode, proportion in period 1, proportion in period 2, etc Initial tour proportions: production sector, attraction sector, demand segment, mode, outbound time period r, proportion in going out in r returning in period 1, proportion going out in r returning in period 2, etc Notes: For modes, mode=1 represents highway, mode=2 is public transport. When this data is used with an absolute model with mode choice then the proportions should not be segmented by mode; this is indicated by putting mode=0. All proportions should be between 0 and 1 (inclusive). For a given demand segment and mode the sum of the outbound proportions over all time periods should equal one. Similarly for the return time periods. For a given demand segment and mode the sum of the initial tour proportions over all outbound and return time periods should equal one.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

62

DIADEM User Manual Version 5.0 (SATURN)

6.9

Page 6: Absolute Model Data

Figure 6.6:

Page 6: Absolute Model Data

This page is used to define various file names containing data for the absolute demand model. The data falls into two categories: trip data and model constants (mode constants and size variables). Trip data may be defined in one of two ways: as trip ends, or as a full initial guess matrix. 6.9.1

Initial guess

Defining the initial guess requires full trip matrices by demand segment and mode. These are specified in a similar way to the reference trip matrices used for the incremental model, i.e. OD matrices by time period for OD-based models and 24 hour PA matrices for PA-based models. The initial guess is used as the matrix to be assigned on the first iteration by DIADEM. It is also used to calculate the trip end constraints to be applied during the model. Definition of the initial guess matrix is very similar to defining highway reference trip data: For all PT data and SATURN highway data: 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

63

DIADEM User Manual Version 5.0 (SATURN)

OD trips: ????_TX_DSY.dat for time period X and demand segment Y. ???? is any user-defined string; X and Y are integers. For PA-based modelling the initial guess trips should be in the form of a 24 hour PA matrix, therefore the file name excludes any reference to the time period: ???? _DSY.dat The root of the file name (????, which need not be limited to four characters) is defined separately for HW and PT initial guess in the appropriate text box. 6.9.2

Trip ends

When applying an absolute model a full estimate of the trip matrix may not be available, in which case just the trip ends can be defined instead. DIADEM then needs to distribute the trip ends to get a matrix suitable for the first assignment. It does this using reference costs defined on the previous highway and PT data pages. Note that the trip ends may be total trip ends over all modes, or separately for each mode, depending on the modelling options chosen:

Responses modelled for demand segment

Interpretation of trip ends

Mode choice modelled

Total over all modes

No mode choice

Single mode (highway if car available, PT if no car available)

Whether origin/production or destination/attraction trip ends need to be defined depends on the distribution model options chosen: Form of distribution model

Trip ends required

OD, origin constrained

Origin only

OD, destination constrained

Destination only

OD, doubly constrained

Origin and destination

PA, singly constrained

Origin only

PA, doubly constrained

Origin and destination

6.9.3

Constants

Definition of constants is optional. For the distribution model it is possible to define size variables for origins (for destination-constrained models) or for destinations (for origin-constrained models). It is also possible to define K factors. Note that size variables are ignored for doubly-constrained models. For the mode choice model mode constants can be defined. For more details on the use of constants refer to Section 4.1.2.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

64

DIADEM User Manual Version 5.0 (SATURN)

6.9.4

File formats

All files are in comma-separated variable format (except highway initial guess for CONTRAM) as follows: Initial guess uses the same file format and file naming convention as reference highways trips (SATURN) version: origin zone, destination zone, trips (trips are trips per hour for OD, 24 hour total for PA). Trip ends (PA modelling): zone number, demand segment, trip end total Trip ends (OD modelling): zone number, demand segment, trip ends in time period 1, trip ends in time period 2, etc. Size variables: zone number, demand segment, size variable K factors: origin zone, destination zone, demand segment, K factor Mode constants: mode, demand segment, value of constant Notes:

Origin trip ends are only required for demand segments using an origin or doubly-constrained model.

Destination trip ends are only required for demand segments using a destination or doubly-constrained

model.

The units used for size variables and K factors are irrelevant – it is only their relative value that is important.

Size variables and K factors must be non-negative. A value of zero will result in no trips for the zone or

zone pair in question.

Any size variables or K factors not specified in the files are assumed to be 1.

For modes, mode=1 represents highway, mode=2 is public transport.

The mode constants should be in the same units as the generalised cost function. This is usually

generalised minutes.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

65

DIADEM User Manual Version 5.0 (SATURN)

Mode constants only need to be defined for one mode – it is only the difference in the constants between modes that matters. 6.10

Page 7: DIADEM Parameters

Figure 6.7:

Page 7: DIADEM Parameters

This page defines settings related to the algorithms used to achieve convergence between supply and demand. Depending on the model set up, two levels of convergence may be relevant. 6.10.1 Main demand-supply loop

Three algorithms are available from the drop down menu: ƒ Fixed Step Length (FSL): this is usually the best performing algorithm, achieving the required level of convergence in fewest iterations.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

66

DIADEM User Manual Version 5.0 (SATURN)

ƒ Method of Successive Averages: this is the traditional ‘slow but sure’ method. Research to date shows that it will take a very long time to reach acceptable convergence levels. ƒ Algorithm 1: this performs like FSL in the early iterations, but can then use up a lot of run time without making further progress towards convergence.

Depending on the algorithm selected a number of parameters also need to be defined in the Algorithm frame. It is recommended that the default values are used to start with. The step length for FSL can be tweaked to improve run times and convergence, as explained in Section 8.3. For an explanation of the role of these parameters please see Appendix A. The Convergence frame is used to specify the stopping criteria for DIADEM: ƒ Maximum Iterations: for MSA and FSL there is one assignment per iteration. For Algorithm 1 there may be more than one, particularly as equilibrium is approached. ƒ Maximum Flow Change: close to convergence DIADEM may make very small changes in the demand matrix which are virtually imperceptible to the assignment. When the largest change in cell values is less than the value of this criterion DIADEM will stop. ƒ Absolute Gap: DIADEM will stop when the absolute gap falls below this value. The value achievable is very dependent on the size of the problem being solved so it is usually advisable to set this to zero. ƒ Relative Gap: DIADEM will stop when the relative gap falls below this value. (See Section 1.5 of WebTAG Unit 3.10.4 (Variable Demand Modelling - Convergence Realism and Sensitivity) for advice about convergence in variable demand models, for the formula used to calculate the gap and for the appropriate value for this parameter.) 6.10.2 HADES-assignment loop

This section will be greyed out unless HADES has been selected for at least one demand segment. The FSL and MSA algorithms are also available for the HADES-assignment loop. In addition, the Social Pressure algorithm can be used. The latter is described in Section 4.2.3.5. The stopping criteria are similar to the main demand-supply loop, but note that the gap is the HADES gap as defined in Section 4.2.3.5. 6.10.3 Sector file

This page can also be used to define a sector file. This is mandatory if PA-based modelling, HADES, or spatial segmentation is being used. A sector is a group of zones and the file contains a correspondence list between model zones and sectors. The file should be in comma-separated variable format, with one line for each model zone: zone number, sector number

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

67

DIADEM User Manual Version 5.0 (SATURN)

Zone and sector numbers must be positive integers. It may help to avoid confusion if there is no overlap between zone numbers and sector numbers. For example, if the highest zone number is 935 the sector numbering could start at 1001. 6.11

Page 8: HADES Data

Figure 6.8:

Page 8: HADES Data

6.11.1 HADES log file

The HADES log file is described in Section 7.1.4. It contains very detailed information, and, for large networks, can take up a lot of disk space. It is recommended that the “Output HADES Log File” option is selected, unless the output log file is so large that it causes problems. 6.11.2 Selection of HADES time periods

The selection of which demand segments which use HADES was made on the Model Parameters page. Here, it is necessary to define to which time periods HADES is applied. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

68

DIADEM User Manual Version 5.0 (SATURN)

The theory behind HADES is based on the idea of a preferred arrival time at the destination and was developed to explain the behaviour of commuters in the AM peak. Arguably, it is less applicable to other time periods. This section therefore allows the user to choose to apply HADES in certain periods only. 6.11.3 Interpretation of assignment time slices

Assignments may be assumed to be based on either trip departure times or trip mid-point times. The choice is made by selecting the appropriate radio button. For CONTRAM it should always be departure times; for SATURN it is up to the modeller, depending on what was assumed when building the model. 6.11.4 Input files containing HADES parameters

Most HADES-related data is defined via four user-defined input files. These files are in comma-separated variable (csv) format and contain the following data: ƒ ƒ ƒ ƒ

Definitions of arrival time windows Scheduling parameters, by destination sector and demand segment The profile of demand by preferred arrival time window, by origin, destination and demand segment Pre and post-peak travel durations by assignment user class

6.11.4.1 Arrival time window definitions This file contains the definition of the arrival time windows. The time period being modelled should be divided into a series of contiguous arrival time windows, in a similar way to the division of the modelled period into a series of assignment time slices. However, as explained below, the period covered by the arrival time windows will usually need to be longer than that covered by the assignment. Every trip in the model is allocated to one of these windows, as its preferred arrival time (PAT). Several sets of windows may be specified. Different demand segment/destination sector/time period combinations may each use a different set. It is good practice for a single set to apply only to a single time period, so as a minimum there would be one set of windows for each time period. However, it is also possible to define a single set of windows covering the whole day and to use that set for each time period (setting demand in some windows to zero, as appropriate for the time period.) The set to be used for each demand segment, destination sector and time period is defined in the scheduling parameters definition file (see below). It is expected that for the vast majority of applications a single set of arrival time windows for each time period should be sufficient. The format for each row in the file is: ID for arrival time window set, start of first window, start of second window, …start of last window, end of last window The ID should be a unique integer identifying this set (i.e. the same ID cannot be used on any other row in the file). Times are in hhmm format, for example 0830 or 1115. Times should be strictly increasing from left 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

69

DIADEM User Manual Version 5.0 (SATURN)

to right. The format ensures that the windows are contiguous and non-overlapping. There is no practical limit on the number of windows within each set. The following example defines a set of four windows with ID=1, with the start of the first window at 0800 and the end of the last window at 0900. The times covered by the four windows are 0800-0820, 0820-0830, 0830-0840 and 0840-0900: 1,0800,0820,0830,0840,0900 Arrival time windows within a given set may be of different lengths. The different sets are, in effect, independent. Each set may start and finish at different times and the durations of the windows differ between sets. However, the appropriate start and end times of the set will need to be set appropriately for the time periods being modelled, as discussed below. The period covered by the arrival time windows clearly needs to be related to that covered by the assignment. For example if the arrival time windows go from 0700-1000 and the assignment covers 16001700 then no flow will get assigned. The arrival time windows should start no later than the arrival time of a trip departing at the beginning of the assignment period. This is most easily handled by making sure that the arrival time windows and the assignments start at the same time. At the other end, the arrival time windows should finish no earlier than the arrival time of a trip departing at the end of the assignment period. The end of the last arrival window should, ideally, be no earlier than the end of the period covered by the assignment plus the duration of the longest trip in the network. If these conditions are not met then it is likely that the assignment will be missing trips, i.e. in reality, the assignment period includes trips which arrive outside of the period defined by the arrival time windows, but because these are not represented in the HADES model they will not be included in the assignment. A warning will be issued to the .log file if this is the case. 6.11.4.2 Scheduling parameter definitions This file is used to define, for each destination sector, demand segment and time period, which set of arrival time windows to use, and the β (early) and γ (late) scheduling parameters. Note that within HADES in DIADEM, generalised costs are expressed in time units. The β and γ parameters in this file should therefore be expressed relative to a unit of travel time. For example a β value of 0.3 would indicate that 1 minute of early arrival has the same cost as 0.3 minutes of travel duration. The format for each row in the file is: destination sector, demand segment, time period, early arrival parameter (β), late arrival parameter(γ), arrival time window ID There should be a row in the file for each destination sector and demand segment for which the HADES demand model has been selected.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

70

DIADEM User Manual Version 5.0 (SATURN)

The destination sector must be an integer and must have been defined in the sector definition file that is specified on the ‘DIADEM parameters’ page (Section 6.10.3). β and γ must be non-negative. The arrival time window ID must have been defined in the arrival time window definitions file (as described in 6.11.4.1. The following example defines that destination sector 2, demand segment 5, time period 1 should use arrival time windows with ID=1, with β=0.3 and γ=0.8. 2,5,1,0.3,0.8,1 Table 6.3 is taken from the Good Practice Guide for the previous version of HADES (Mott MacDonald, 2004) and presents a summary of evidence for the β and γ parameters. These are for one minute of early or late arrival, relative to one minute of travel duration. The table also includes a column for ‘Lateness penalty’. This is a fixed cost of late arrival, regardless of exactly how late that is. Note that this is not included in the HADES costs within DIADEM. Table 6.3:

Summary of the evidence on the valuation of schedule delay.

Source

Early arrival (β)

Late arrival (γ)

Lateness penalty

Small (1982)

0.61

2.40

5.47

Polak and Bates (1996) Arrival constrained Arrival+departure constrained No constraints Whole sample

0.13 0.16 0.02 0.13

0.64 0.42 0.25 0.43

Polak (1991 – Trondheim) Fixed hours commuters Flexible hours commuters Other All

0.66 0.61 0.78 0.52

1.02 0.77 0.52 0.49

Polak (1994 – LCC dataset) Commuters Employers’ business Shopping and Leisure

2.81 0.55 0.66

3.48 1.40 0.40

0.64

0.69

Wardman (1998 – average of 13 European studies) Source:

7.4

Mott MacDonald (2004)

6.11.4.3 Demand profile by PAT window This file defines the demand profile for each Preferred Arrival Time (PAT) window, for each origindestination (OD) zone pair and demand segment, i.e. the proportion of travellers within each PAT window . It is used to split the total demand by time period to demand by PAT window. Depending on which other demand model responses have been selected, the total demand may be the output from the main demand model, or a fixed user-supplied value.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

71

DIADEM User Manual Version 5.0 (SATURN)

The format is: origin zone, destination zone, demand segment, time period, proportion of demand for preferred arrival time window 1, proportion of demand for preferred arrival time window 2, etc. The first four values are integers; the rest are real numbers greater than or equal to zero and less than or equal to one. The sum of the proportions must not exceed 1.0, otherwise DIADEM will issue an error message and stop. If the sum of proportions is less than 1.0 then a warning message will be issued to the log file but DIADEM will continue to run; this is to allow the situation where the defined trip numbers represent the demand over a longer period than that defined by the arrival time window (though this unlikely to be appropriate where HADES is being used in conjunction with a mode choice or distribution model). Note that different OD pairs, demand segments and time periods may use different sets of arrival time windows, and that the number of windows within each set might be different. This means that the number of items on each row of this file may vary. Obtaining data on preferred arrival times is one of the biggest challenges in using HADES. Software has previously been developed for DfT for inferring preferred arrival times from actual arrival times, but that is not on general release. An alternative approach that has been suggested is to assume that preferred arrival times equal actual arrival times in the model base year. HADES can then be used in forecasting (with or without a scheme) to give a broad indication of how arrival and departure time profiles might change in the future. 6.11.4.4 Pre and post-peak travel times Pre and post-peak travel times are defined in this file. For an explanation of their use see Section 4.2.3.5 (specifically the section discussing the interpolation of travel durations by arrival time). The format is: origin zone, destination zone, user class, time period, pre-peak travel duration, post-peak travel duration The first four values are integers; the last two are real numbers greater than zero. Travel durations should be specified in minutes. Note that durations are defined by assignment user class, not by demand segment. However, they are applied by demand segment, with the demand segment to user class correspondence (defined on the Segmentation page) used to identify which user class values to apply to a given demand segment. These travel times are defined by time period. HADES is applied independently to each time period, Travel times within each period are taken from the assignment model, but travel times before and after the period must be defined by the user.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

72

DIADEM User Manual Version 5.0 (SATURN)

6.12

Page 9: SATURN Settings

Figure 6.9:

Page 9: SATURN Settings.

This page contains settings relating to the way SATURN should be run. SATURN may be run in ‘quiet’ mode, which switches off all screen output when running SATURN modules such as SATALL. This means that while DIADEM is running there is little visible indication of progress, other than a small DIADEM progress window. Windows Task Manager can be used to monitor program activity. The second box specifies the path where the SATURN executable files (.bat, .exe) are located. If the default options were used when installing SATURN this will usually be C:\SATWIN\XEXES. If more than one version of SATURN is installed then this should be the location of the executable files for the version that should be used for this particular DIADEM run. The last chosen location is remembered by DIADEM and will be used as the default for new control files. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

73

DIADEM User Manual Version 5.0 (SATURN)

It is possible to set up DIADEM so that assignments for different time periods are run in parallel, provided appropriate hardware is available (minimum of a dual core processor). This can greatly reduce run times, for example running four SATURN assignments in the same time it takes to run one. This page will report how many processors the operating systems reports are available. It is recommended that the number of assignments set to run in parallel should not exceed this value – there will be no run time advantages in doing so and there is a risk the whole DIADEM run may take longer. Run time reductions from this option are likely to be small if you are using the multi-core version of SATURN. For this option to work it is necessary that the file SAT10KEY.DAT is read-only. DIADEM will look for this file in ..\DAT\ folder (relative to the location of the exes) and offer to make it read-only if it is not already. Running assignments in parallel does not apply if the PASSQ option has been selected on the Segmentation page – the assignments must then be run one after the other so that the correct queues can be passed from one time period to the next. NB: If you are using the option to run SATURN assignments in parallel then you must put the SATURN network files for each time period in a separate directory. This will reduce the risk of file opening errors, with different SATURN programs trying to access the same file at the same time. 6.13

Running DIADEM

Once all the data has been set up the control file should be saved. The DIADEM process is started by clicking on the ‘Run DIADEM’ button at the bottom of the window. After a few moments an assignment will start. When the first assignment finishes a small DIADEM progress window will appear, reporting the iteration number and the current value of the relative gap function. Depending on the convergence criteria, a number of further assignments will be carried out. If any errors arise during the process a window will appear with an error message. Otherwise DIADEM will have successfully completed when all the assignments have stopped. Note that for very large models there may be a gap of up to a few minutes between assignments. When DIADEM has finished a message will appear saying ‘DIADEM run completed.’ 6.13.1 Batch mode

Several DIADEM control can be set up to run consecutively, without any user intervention. To do this create a plain text file. Each line of this file should contain the name of a control file, with the full path and including the .xml extensions, e.g. c:\diadem\test1.xml c:\diadem\test2.xml etc….





In the user interface go to File>Batch File and open the above text file. The first control file will start running immediately. Any error messages will be written to a log file.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

74

DIADEM User Manual Version 5.0 (SATURN)

7. DIADEM output

7.1

Output files

There are various DIADEM output files: a series of demand files, a log file and a summary convergence file. In addition there will be a series of files produced by the assignment software. In the following descriptions ‘root’ represents the name of the DIADEM control file; it is used in the names of several output files. 7.1.1

Checking results

The following sections describe the DIADEM output files in more detail. Briefly, the following should be checked for any DIADEM run: ƒ Deal with any error messages issued during the run. ƒ Look in the log file to see if there are any warning messages and deal with these as appropriate. ƒ Look at the convergence file to make sure DIADEM has reached an adequate level of convergence ƒ Check that the travel behaviour is consistent with the scenario being modelled. For the DM it would be sensible to compare the output trip matrices with the reference trip matrices; the DS output trip matrices can be compared with the DM trip matrices. Results to look at include: ƒ Total trip numbers are reported in the convergence file; these will only change if the trip frequency response is modelled or an elasticity model is used. ƒ Total trip numbers by mode and time period can be calculated from the output trip matrices. These can be used to check the mode and time period choice responses are reasonable. ƒ The trip matrices can be used in a trip length distribution analysis. 7.1.2

Log file

This file is called root.log. This file contains a log of the timing of each step of the DIADEM process. It also includes any warnings that are produced. Note that these warnings are not serious enough to cause the DIADEM run to fail, but should be investigated further (see Section 7.2 for more on warning messages). Note that this file is appended to rather than replaced, i.e. if the same DIADEM control file is run twice then the log will contain output relating to both runs – running it a second time does not delete the output from the first.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

75

DIADEM User Manual Version 5.0 (SATURN)

7.1.3

Convergence files

7.1.3.1

Main demand-assignment loop

A summary convergence file in comma-separated variable format (extension _results.csv) is produced. The root of the file name will be the same as the DIADEM control file. This file contains the following information for each subiteration: ƒ Step length (see Appendix A: for explanation) ƒ The maximum change in a matrix cell value (compared with the matrix produced at the end of the last main iteration) ƒ Objective function value (see Appendix A for explanation) ƒ The absolute and relative gap values (see WebTAG for formulae) ƒ Statistics on the stability of costs at the matrix cell level (relative average absolute difference, average absolute difference, root mean square difference, % of cells changing by less than 5%) ƒ Statistics on the stability of trip numbers at the matrix cell level (same measures as cost stability) ƒ The total trips in the system (this should be constant unless an elasticity or frequency model is being used) ƒ The total cost in the system

Note that some statistics are only output for the last subiteration in each main iteration. Advice on appropriate levels of convergence can be found in Section 1.5 of WebTAG Unit 3.10.4 (Variable Demand Modelling - Convergence Realism and Sensitivity) . Note that the trip matrix closest to equilibrium (the one with the minimum gap) may not be the final trip matrix output by DIADEM. The convergence results should be used to identify the best iteration/subiteration and the corresponding trip matrix should be used as the basis of subsequent analysis and appraisal. As described in the following section, DIADEM automatically identifies the trip matrices from the best iteration/subiteration (defined as the one with the lowest relative gap). If the best trip matrices are not the ones from the final subiteration then it will be necessary to reassign the best matrices to obtain cost matrices, link flows etc. for subsequent analysis and appraisal. 7.1.3.2

HADES-assignment loop

If HADES is being used, a summary convergence file for each HADES-assignment loop is produced for each time period. The loop number and the time period are included in the file name which has the format _IterX_ TY_ HADES_results.csv. This is very similar to the main results.csv file, but it reports the HADES gap value for each iteration of the HADES-assignment loop, and does not report an objective function value or the absolute gap value.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

76

DIADEM User Manual Version 5.0 (SATURN)

7.1.4

HADES log file

This is an extra file in csv format containing the following information for every iteration, origin, destination, demand segment, preferred arrival time and actual arrival time: ƒ Travel duration ƒ Total generalised cost ƒ Number of trips

The scheduling cost can be calculated by subtracting the travel duration from the total generalised cost. As with the HADES-assignment loop convergence file, a separate file is produced for each time period and iteration of the main demand-assignment loop. This file can get quite large, so its output can be suppressed on the HADES Data page when setting up the DIADEM run. 7.1.5

Trip matrices

7.1.5.1

Highway

All intermediate OD trip matrices produced by DIADEM are saved with a file name of the form root_HWtrips_TX_DSY_M_N.dat where X is the time period, Y is the demand segment, M is the main iteration number and N is the subiteration number. The matrices from the best iteration are copied to root_HWtrips_TX_DSY_best.dat. The units used are vehicle or PCU trips per hour (whichever was used for the input matrices). For demand segments that use a PA demand model, PA trips are output for each iteration in the form of 24 hour PA and PA tour matrices. A 24 hour PA matrix is produced with a file name of the form root_HWtrips_DSY_M_N.dat. Tour matrices are produced with file names of the form root_HWtrips_ToutX_TretZ_DSY_M_N.dat where X is the outbound time period, Z the return time period. The units used are absolute vehicle (or PCU) numbers. Note that the 24 hour PA matrix is just the sum of the corresponding tour matrices over all outbound and return time periods. The UFM matrices from the last subiteration, as used in the final assignment, are called UFM_TX.UFM (all assignment user classes stacked together). 7.1.5.2

Public transport

PT trip matrices are output only for those demand segments for which mode choice is modelled. OD trip matrices are called root_PTtrips_TX_DSY_M_N.dat where X is the time period, Y is the demand segment, M is the main iteration number and N is the subiteration number. The matrices from the best iteration are copied to root_PTtrips_TX_DSY_best.dat. The units used are passenger trips per hour. For demand segments that use a PA demand model, PA trips are output for each iteration in the form of 24 hour PA and PA tour matrices. A 24 hour PA matrix is produced with a file name of the form root_PTtrips_DSY_M_N.dat. Tour matrices are produced with file names of the form root_PTtrips_ToutX_TretZ_DSY_M_N.dat where X is the outbound time period, Z the return time period. The units used are absolute passenger numbers. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

77

DIADEM User Manual Version 5.0 (SATURN)

7.1.6

Other files

In addition to the files described above other files may be produced by the assignment software as follows: Skim cost matrices from the final assignment (tim_TX_UCY.dat, dis_TX_UCY.dat, cst_TX_UCY.dat). UFN, UFC, UFS, LPN, and LPT files are created during the assignment (carried out using the SATURN module). The LPT file may provide useful information if DIADEM stops due to a failed SATURN assignment. LOG, LPX. UFM files are created by the MX module, which is used to build UFM files from ASCII files output by DIADEM. LOG, LPL, DAT files (cst*.dat, tim*.dat, dis*.dat) are created by SATLOOK, which is used to skim cost matrices (the DAT files) in ASCII format from completed assignments. Note that very large numbers of LOG files (MX*.LOG, SATLOOK*.LOG) may be produced. It is usually safe to delete them. 7.2

Dealing with error and warning messages

7.2.1

Overview

Error messages in DIADEM will usually appear in their own window and will cause the program to stop before it has successfully completed. Warning messages will appear in the log file. They do not prevent DIADEM running to completion, but may indicate problems with the input data that may mean the results are unreliable. Some of the more common messages are discussed below. For more help with these and any other messages please contact DIADEM technical support. 7.2.2

‘Division by zero in elasticity demand function calculation’ (error)

This message appears in a pop-up window and will include information on the origin, destination, demand segment, and time period concerned. It will usually occur just after the first assignment. It can only appear when an elasticity model is being used with a non-zero γ parameter. DIADEM will report this message if either the reference or the forecast cost is zero. This is usually a result of not setting the ‘Assign zero packets’ parameter to TRUE. This will usually be because the reference trip matrix includes intra-zonal trips; the skimmed cost will be zero for these trips. Because intra-zonal trips are not assigned they do not affect the costs for other trips and can safely be removed from the reference trip matrix. It may also be a result of centroid connectors being defined in such as way as to allow OD routes to take place solely on connectors and to have no time or distance. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

78

DIADEM User Manual Version 5.0 (SATURN)

7.2.3

‘MatrixFile::read Cannot open file name for input’ (error)

This usually occurs very shortly after clicking the ‘Run DIADEM’ button. It is because a path has not been specified correctly, a specified file does not exist or a particular file has not been specified at all. It can also occur later in the DIADEM run as a result of a failure to skim costs from an assignment. Look in the SATLOOK .lpl files for clues, or SATALL .lpt files if the assignment itself failed. Also, see Section 8.2.5 for likely causes of this in SATURN. 7.2.4

‘Warning: N origin/destination/demand segment/ time period combinations have highway trips but no PT trips’ (warning)

This message will appear if there are zero PT trips but non-zero highway trips (or vice versa) in the reference matrices for a particular origin/destination/demand segment/ time period combination. In this situation the mode choice model can still be applied but it will not model any change in mode share for that particular combination, i.e. it is fixed at 100% for one mode. 7.2.5

Spawn of SATURN process returned error code XXXX (error)

If this occurs shortly after clicking ‘Run DIADEM’ and there is no evidence of SATURN being run then it is likely that DIADEM cannot find the SATURN program files. Check that the path to the SATURN executable files that you defined is correct. If this occurs later in the DIADEM run and SATURN is being run then it indicates a failure in one of the SATURN modules used by DIADEM. The DIADEM error message will often be preceded by a SATURN error message. In this case check the LP file from the latest SATURN module to be run for information on the cause of the failure. Common reasons for SATURN failures include: ƒ Spaces in file and path names (not a problem with SATURN 10.5 or later). ƒ SATNET: errors in forecast network .dat file(s). ƒ SATALL: semi-fatal errors in SATNET meaning UFN file cannot be used for assignment; incompatibility of zoning systems in matrix and network files (see Section 7.6.3 about including all zone names in reference trip matrix file). ƒ SATLOOK: previous failure of SATALL meaning costs cannot be skimmed from UFS file(s). 7.2.6

‘Furness not converged in doubly-constrained distribution’ (error)

The doubly-constrained distribution model uses furnessing to ensure trip end constraints are met. Furnessing is an iterative procedure and usually converges very quickly. This message will be issued if the furnessing process does not converge. The most likely cause is using an incremental version of the model with a very sparse reference trip matrix, i.e. one with lots of zeros. In particular, it is worth looking out for any rows or columns with just one or two non-zero entries. The solution is to fill in as many of the gaps in the reference matrix as possible. Simply ‘seeding’ the matrix by replacing zeroes with some fixed value is unlikely to be acceptable as it will distort the distribution of trips in the matrix.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

79

DIADEM User Manual Version 5.0 (SATURN)

7.2.7

HADES-specific messages

7.2.7.1

Time period boundary outside defined range for linear interpolation

This message indicates that the period covered by the arrival time windows is too short relative to the period covered by the assignment model. The message will state which origin, destination and demand segment are affected. It will also report a range of departure times (or trip mid-points) corresponding to the departure time of a trip arriving at the start of the first arrival time window, to the departure time of a trip arriving at the end of the last arrival time window. The start and end of every assignment time slice must be within this range. If not, the interpolation method described in Section 4.2.3.5 cannot be used and demand within the assignment time slice will be under-represented. The solution is to extend the period covered by the arrival time windows, or reduce the period covered by the assignment time slices. As discussed in Section 4.2.3.5, the arrival time windows should start no later than the arrival time of a trip departing at the beginning of the assignment period, and should finish no earlier than the arrival time of a trip departing at the end of the assignment period. If this message appears in relation to early iterations, but not for the final few iterations of the HADES run it is less important to take action. This can happen because demand is too peaked in the early iterations (everyone arriving close to their preferred time), leading to excessive travel durations. As the iterations progress the peak flattens out, travel durations reduce, and all trips now arrive within the period covered by the arrival time windows. 7.2.7.2

Pre-peak travel durations not increasing/ Post-peak travel durations not decreasing

As described in Section 4.2.3.5, interpolation and extrapolation is used to estimate the travel duration for any given arrival time. For arrivals near the beginning of the modelled period this works best if travel durations are increasing, i.e. the pre-peak travel duration is less than the travel duration from the first assignment time slice, which is less than that from the second time slice. Conversely, at the end of the modelled period travel durations should be decreasing. This message may indicate that the (fixed) pre or post-peak travel durations are too high, or that the period covered by the assignment is too short (hence travel durations do not increase at the beginning of the period, and decrease at the end, as would be expected if the whole of the peak period were modelled). 7.2.7.3

Possible FIFO violation

FIFO stands for ‘First In First Out’, meaning that if, for a particular OD pair and user class, vehicle X departs before vehicle Y then it should also arrive before vehicle Y. This message will be produced if this condition is not met. For example the travel duration for a vehicle departing at 0800 might be 20 minutes (implying arrival at 0820), but a later departure at 0805 might have a 10 minute travel duration (implying an earlier arrival at 0815). This should never happen in a CONTRAM model. In SATURN it can usually be fixed by using the PASSQ option on the DIADEM Segmentation page. If this doesn’t work then please contact DIADEM technical support for further advice. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

80

DIADEM User Manual Version 5.0 (SATURN)

8. Hints and tips

8.1

Realism testing with DIADEM

8.1.1

Overview

Realism testing is an important part of making sure the demand model is compliant with WebTAG. It is essential when importing model parameters (e.g. using the WebTAG illustrative parameters) rather than calibrating them locally. The relevant part of WebTAG is Section 1.6 of Unit 3.10.4 (Variable Demand Modelling - Convergence Realism and Sensitivity) 8.1.2

Fuel cost elasticity

The main requirement is to test the outturn elasticity of vehicle kilometres with respect to the cost of fuel. This is calculated from the following formula: ⎛ T1 ⎞ log⎜ 0 ⎟ ⎜T ⎟ ⎠ ⎝ E=

⎛ C1 ⎞ log⎜ 0 ⎟ ⎜C ⎟ ⎠ ⎝

where T0 and C0 are the base model vehicle kilometres and fuel cost respectively, and T1 and C1 are the equivalent quantities after an increase in the cost of fuel. WebTAG recommends that the calculation is done on a network basis (i.e. vehicle kilometres summed over links) and a matrix basis (i.e. vehicle kilometres summed over matrix cells). In both cases vehicle kilometres should exclude movements and vehicle types that are not subject to variable demand. To obtain the required data from DIADEM the procedure is as follows: 1. Decide on what increase in fuel cost to test. WebTAG suggests 10%. In some cases this small increase can get lost in convergence noise so 20% may be better. This gives you the value of (1.1 for a 10% increase, 1.2 for 20%). 2. For each demand segment/user class calculate how much of the distance coefficient in the generalised cost represents fuel costs. If non-fuel VOCs are not included then this will be 100%, if they are included it will be less. 3. From (1) and (2) calculate how much the distance coefficient needs to be increased to reflect your chosen fuel cost increase. For example, if you increase fuel costs by 20%, and fuel costs represent 60% of your distance coefficient then you need to increase your distance coefficient by 20% x 60%=12%. 4. Create forecast scenario network file(s). This should be the base year network with the distance coefficient increased according to (3). No other changes from the base year network should be made. 0

5. Obtain T . The method for doing this depends on the demand model being used: a. Incremental OD: T0 comes from the validated base model assignments 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

81

DIADEM User Manual Version 5.0 (SATURN)

b. Incremental PA and Absolute PA/OD: T0 obtained from assigning the results of a DIADEM run set up to model the base year without the fuel cost increase 6. Set up a DIADEM control file for the increased fuel cost scenario. The inputs should be as follows: a. Forecast network files should be those created in (4) above b. For an incremental model: i. Reference costs should be base year costs ii. Reference trip matrices should be base year trip matrices c. For an absolute model: i. Initial guess matrix should be base year trip matrices 7. Run DIADEM to convergence. 1 8. Extract forecast vehicle kilometres T from the assignments and calculate the elasticity of vehicle kilometres with respect to fuel cost using the above formula. This can be done by user class and time period.

If the outturn elasticity is not acceptable then some adjustment of the demand model parameters may be required. The elasticity is roughly proportional to the distribution lambda parameters input to DIADEM (assuming distribution is at the bottom of the hierarchy). So if the elasticity for a particular demand segment is 50% too high then the distribution lambda parameter should be factored by 1/1.5. There is no need to adjust the theta parameters for responses higher up the hierarchy – these just reflect the relative strengths of the different responses and should be maintained. More information on model adjustment can be found in WebTAG 3.10.4. 8.1.3

Journey time elasticity

WebTAG also recommends the calculation of other elasticities. Elasticities with respect to parking charges and public transport fares can be calculated by adapting the above procedure. Elasticities with respect to car travel times are more problematic and require a more approximate approach. The elasticities of vehicle kilometres with respect to fuel costs and journey times are related as follows: E time = E fuel

where

p time p fuel

p time

p fuel

is the cost of travel as a proportion of total generalised cost, and is the cost of fuel as a proportion of total generalised cost.

If you know the total vehicle kilometres, K, and the total vehicle hours, T, then you can calculate an p time average value for fuel as: p p time aT = bK p fuel

where a is the cost per hour from the generalised cost function and b is the cost per km. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

82

DIADEM User Manual Version 5.0 (SATURN)

The elasticity of vehicle kilometres with respect to journey time can then be estimated as: aT E time = E fuel bK This is only a crude estimate. If the result is close to the WebTAG recommended limit of -2.0 then please contact DIADEM support for advice on obtaining a more accurate value. 8.2

Reducing run times

The vast majority of the total DIADEM run time is spent running assignments and skimming costs. To reduce run times you therefore need to reduce the time spent on these tasks and minimise the number of iterations that DIADEM does. Skimming costs as an average over all used paths in SATURN takes much more time than skimming minimum cost paths. As noted in Section 6.6 it is acceptable to skim minimum cost paths provided that the assignment is well converged. Assignment run times in SATURN can often be reduced significantly by adjusting the convergence parameters. Setting SATURN parameters similar to the following values is often successful in minimising run times: NITA = 10 MASL = 100 AUTOK = T KOMBI = 0 NITA_M = 3 DIDDLE = T,

AUTONA = T

If you are skimming minimum cost paths you can also set SAVEIT=F, but when final assignments are being run to provide inputs to TUBA it will need to be set to T and NITA_S will need to be sufficiently high to make the SAVEIT assignment as accurate as possible (for more information see Section 15.23 of the SATURN manual). Of course, each network is different and some experimentation with the above parameters may be necessary. If you are using SATURN version 10.6.17 or later you can make use of the ‘warm start’ facility. This means that the SATURN assignment can make use of the route and cost information from the previous DIADEM iteration, reducing the time required to get a converged assignment. To do this make the following modifications to your network.dat files: ƒ Set UPDATE to ‘T’ under &OPTION ƒ Set WSTART to ‘T’ under &OPTION ƒ Set SAVUFO to ‘T’ under &PARAM

The last two options are likely to be most successful if you are using the origin-based assignment (OBA) option, but are sometimes worth trying in other cases. When you run DIADEM you may see a SATURN dialogue box asking you for a UFS file to update from. You can select your base year UFS file. This will only happen on the first DIADEM iteration. Subsequently the warm start and update will be based on the results of the previous DIADEM iteration. 244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

83

DIADEM User Manual Version 5.0 (SATURN)

It should be noted that in some cases the extra time taken for SATURN to produce the UFO file might offset other time savings, particularly for a high value of NITA_S, so significant savings cannot be guaranteed. For more information on warm starts see Section 22 of the SATURN manual. The above information is based on the manual for SATURN version 10.7.10 and may not be appropriate for later versions. To minimise the number of iterations it is worth experimenting with different algorithms to see which works best for your model. It can also be worth experimenting with the initial step length for Algorithm 1 and the fixed step length algorithm. The values in the Max Flow Change column of the _results.csv file can provide a useful indication of how to change the step length. A sequence of values of the same sign is usually an indication that the step length can be increased, for example: -9.98, -7.85, -6.37, -5.16 etc. Conversely, alternating signs can be an indication that the step length needs to be decreased: -9.98, 8.56, -7.45, 6.78 etc. High step lengths tend to be more successful in relatively uncongested networks and vice versa. 8.3

Improving convergence

There are a number of things to adjust to try to improve DIADEM convergence: ƒ ƒ ƒ ƒ ƒ

Increase the maximum number of iterations Decrease the stopping values for the gap values Decrease the value of the ‘maximum flow change’ parameter Improve your assignment convergence Adjust the initial step length (for Algorithm 1 and Fixed Step Length)

In the majority of cases improving assignment convergence is the most effective action. The main measure of this is the assignment gap (post-simulation in SATURN). Values of 0.1% or lower may be required. However a low global gap value can sometimes hide local problems that cause difficulties for DIADEM. Since DIADEM uses the costs from the assignment it is important that costs in the assignment are as stable as possible. If you are skimming costs over an average of used paths in SATURN then the accuracy of the SAVEIT assignment is also important; it should match the ‘actual’ assignment as closely as possible and you may need to increase the value of the NITA_S parameter. See Section 15.23 of the SATURN manual for further information. CONTRAM users can improve convergence by using smaller packet sizes. It is recommended that the gap is used as the stopping criterion in SATURN. This requires setting KONSTP=1 in the SATURN .dat network file, and STPGAP equal to the stopping value; 0.1 is recommended as a good starting point and can be reduced later if required. It can be worth experimenting with different algorithms. Algorithm 1 is normally the most effective, but can be sensitive to assignment convergence noise, in which case the Fixed Step Length method may give better convergence. As a last resort, Method of Successive Averages can be used, but this is likely to be slow to converge to an acceptable level.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

84

DIADEM User Manual Version 5.0 (SATURN)

8.4

Freezing particular movements

In many variable demand modelling applications it is desirable to freeze certain movements in the trip matrix, i.e. they are not subject to variable demand. This is most often done for external to external trips, on the basis that the costs (and the changes in costs) are not usually fully modelled for such trips. In DIADEM the decision to use variable demand modelling is made at the trip purpose level. So this requires setting up additional trip purposes and demand segments for the fixed trips. For example, suppose a subset of movements for employer’s business trips is to be frozen. This suggests the following set up of trip purposes in DIADEM: ƒ Home-based employers business (VDM): modelled as variable demand (PA) ƒ Non-home based employers business (VDM): modelled as variable demand (OD) ƒ Employers business (fixed): modelled as fixed demand

All three purposes can be combined into a single assignment user class. The reference matrices (in an incremental model) or trip ends (for an absolute model) for the variable demand segments should exclude those trips which are being treated as fixed demand.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

85

DIADEM User Manual Version 5.0 (SATURN)

9. References

Arnott, R., de Palma, A., Lindsey, R. (1994). Welfare effects of congestion tolls with heterogeneous commuters. Journal of Transport Economics and Policy. Bates J, Ashley D and Hyman G (1987). The nested incremental logit model: theory and application to model choice. Proceedings 15th PTRC Summer Annual Meeting, University of Bath, England. Bates J (2007). Practical modelling of trip re-scheduling under congested conditions. Transportation Research Part A 41 (2007) pp788-801. Daly A. (2010). Cost Damping in Travel Demand Models. Report of a study for the Department for Transport. Available from http://www.dft.gov.uk/pgr/economics/rdg/costdamping/ [Accessed 24 March 2010] Gordon A, Daly A, Bates J and Oladeinde F (2007). Modelling time period choice in large-scale hierarchical demand models: some problems and a solution. Proceedings of European Transport Conference. Available from http://etcproceedings.org/paper/modelling-time-period-choice-in-large-scale-hierarchical-demandmodels-some-pr [Accessed 30 April 2010] Mott MacDonald (2004). HADES Good Practice Guide. http://www.dft.gov.uk/pgr/economics/rdg/dtc/phase2/hades/ [accessed 18/11/09] Mott MacDonald (2005a). HADES Extension Validation Report. Available from http://www.dft.gov.uk/pgr/economics/rdg/dtc/phase3/ [accessed 02/11/09] Mott MacDonald (2005a). HADES B Final Report. Available from http://www.dft.gov.uk/pgr/economics/rdg/dtc/phase3 / [accessed 02/11/09] Mott MacDonald (2005a). HADES User Manual 4.0. Available from http://www.dft.gov.uk/pgr/economics/rdg/dtc/phase3/ [accessed 02/11/09] Mott MacDonald (2011). Incorporating HADES into DIADEM: Results of testing programme. Report reference 241930/05. Small, K.A., (1982). The scheduling of consumer activities: work trips. American Economic Review 72 (3), 467–479. Small, K.A ., (1992a). Trip scheduling in urban transportation analysis. American Economic Review (Papers and Proceedings) 82 (2), 482–486. Small, K.A., (1992b). Urban Transportation Economics. In: Fundamentals of Pure and Applied Economics, 51. Harwood Academic Publishers. Vickrey, W.S., (1969). Congestion theory and transport investment. American Economic Review (Papers and Proceedings) 59, 251–261.

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

86

DIADEM User Manual Version 5.0 (SATURN)

Appendices Appendix A. Appendix B. Appendix C. Appendix D.

Description of algorithms _____________________________________________________________ Demand model functions _____________________________________________________________ Initial tour proportions from NTS data ___________________________________________________ History of DIADEM changes __________________________________________________________

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

87

88

90

97

99

DIADEM User Manual Version 5.0 (SATURN)

Appendix A. Description of algorithms

A.1.

Definitions and notation

DIADEM deals with commodity flows. Each combination of origin, destination, mode, time period and

demand segment constitutes a unique commodity.

The following notation is used:

X

a vector of commodity flows with elements X s

C ( X )

a vector of commodity costs with elements C s ( X ) , obtained from the assignment of X

V (X )

the value of the objective function for flows X

U ( X )

the search direction vector for flows X

λ

auxiliary cost estimate vector with elements λs (DMM only)

UX s

the upper limit on the flow for commodity s (DMM only)

UC s

the upper limit on the cost for commodity s (DMM only)

α

step length

R

factor for reducing step length

nsucc

number of iterations without a reduction in step length before step length is increased

A.2.

Algorithm 1/MSA/FSL

A.2.1.

Framework

N is the main iteration counter. M is the subiteration counter. L counts the number of iterations since the step length was decreased. 1. Initialise N=1, M=1, L=1 2.

Calculate demand XN

For N=1 use reference demand, otherwise calculate search direction U and

(

X N = X N −1 + αU N −1 X N −1

)

Any negative elements of XN should be reset to zero

244465/ITD/ITW/4/F 7 February 2011 http://pims01/pims/llisapi.dll/open/1453538064

88

DIADEM User Manual Version 5.0 (SATURN)

(Note: for MSA we always have α=1/N; for FSL α remains constant throughout) 3. Assign demand XN to obtain associated costs C(XN) 4. Calculate objective function VN=V(XN). 5. If N>1 and algorithm is not MSA or FSL check if VN