Cube Voyager Training Manual
February 1, 2017 | Author: John Smith | Category: N/A
Short Description
Download Cube Voyager Training Manual...
Description
A Reference Manual on
Travel Demand Modeling using CUBE – VOYAGER Software Package
Transportation Systems Engineering Civil Engineering Department IIT Bombay, Mumbai - 400 076
A Reference Manual on Cube Voyager
1. Introduction Cube Voyager is an integrated modeling system for transportation systems planning applications. The heart of the Cube Voyager system is a flexible control language referred to as a scripting language. This provides a flexible environment and grants control over all aspects of the modeling process. Hence it allows the incorporation of any methodology model ranging from standard four-step models, to discrete choice to activity-based approaches. Advanced methodologies provide junction-based capacity restraint for highway analysis and discrete choice multipath transit path building and assignment. Cube Voyager includes highly flexible network and matrix calculators for the calculation of travel demand and for the detailed comparison of scenarios. Cube Voyager was designed to provide an open and user-friendly framework for modelling a wide variety of planning policies and improvements at the urban, regional and long-distance level. Cube Voyager brings together these criteria with a comprehensive library of planning functions applied under the general Cube framework. This makes the management of data a snap, and the coding of complex methodologies simple via a step-by-step approach.
*Cube allows for the easy incorporation of other software including industry standard ArcGIS from ESRI and various Microsoft Office programs. Third party software may also be readily incorporated into the system.
Limitations: Cube Voyager software is the collection or the series of independent programs, any one of which could require a relatively large amount of input control data, and consume a considerably large amount of computer resources. Some programs could execute for hours, and can run most efficiently with large amounts of RAM. •
Maximum zones=32,000
•
Maximum nodes=999,999
•
Maximum links=999,999
•
Maximum of 999 internal working matrices & 255 matrices on input and output files
•
75 MB of disk space is required to install Cube Base and Cube Voyager.
•
If a computer can run Windows, it has enough RAM to run Cube Voyager.
Transportation Systems Engineering, IIT Bombay
Page 2
A Reference Manual on Cube Voyager
•
It can be possibility that several simultaneous applications could try to access the same input data files simultaneously. This could cause problems if one application is trying to update a file while other applications are accessing it.
Installation 1. First Install the Citilabs license CD. 2. Once the license is installed, Install the CUBE software CD (which can also be downloaded from the Citilabs website) and Cube Voyager should be selected during the installation of Cube 3. Insert the DK2 key (USB) and start exploring the CUBE Base.
1. Programmes in Voyager Cube Voyager contains totally a seven modules or programmes which can be used at several stages of the modeling of travel. Each programme is having several phases as it can perform multiple tasks during the single run of that programme. We can use number of control statements while writing the script in each phase. It should be noted that some specific control statements and phases can only be used for a particular programme. Hence, it is always necessary to have a look on help file to watch out what are those associated to that particular programme. The seven programmes are listed below, 1. NETWORK Programme, for building, comparing and manipulating networks. 2. HIGHWAY Programme, for path building, skimming and assignment of highway networks. 3. PUBLIC TRANSPORT Programme, for transit routes coding, skimming and assignment of public transport networks. 4. GENERATION Programme, for Trip generation 5. DISTRIBUTION Programme, for Trip distribution 6. FRATAR Programme, for growth factoring of matrix 7. MATRIX Programme, for matrix manipulations and model split modeling The brief explanation on above programmes will be given in the sub-sequent sections. There is another programme called PILOT which may not be that much necessary. There are no certain rules for programme but some limitations to be remembered. ¾ Programmes can be specified in any order. ¾ They allow for varieties of methodologies to be applied.
Transportation Systems Engineering, IIT Bombay
Page 3
A Reference Manual on Cube Voyager
¾ But user can be the responsible for “what makes the programme useful for their purpose and sense” ¾ Every module or programme is organized or specified and data input or output can be given by using the CUBE Base flat form.
2. Basics of Scripting Script file: Each of the above programmes must have a script file. Cube Voyager is operated by reading the control statements from a script file associated with that programme. All the input and output files should be specified in the script file either through application manager or a simple text editor. But is recommended to give the input and output files through application manger only. 3.1 General Syntax Note: The Voyager Scripting is NOT Case sensitive. Each statement begins with a control statement which tells the programme to what to do. The general syntax for a control statement is as below, Command keyword=value All control statements have the same general format. Each control statement should start with a command followed by one or more spaces and a “keyword=” and then the value. The key word should always be followed by “=” sign. If there are more number of continuous lines for a command , then they must finish with one of the operators of
. , - * / + = | &
For example, PATHLOAD PATH=COST,
; Here the PATHLOAD is the command and PATH is the ;keyword
and COST is the value
VOL[1]=MI.1.PEAK_OD_PV, ; Assigning PV trips, TOLLMATI=1,1, TOLLFACTOR=0.423, ; toll factor is in min/toll units, here 0.423 min/Rs ; ;(implies VOT=Rs.147/hr) EXCLUDEGROUP=1, ; exclude PT only links MW[1] = PATHTRACE(cost,1),PATHO=1 NAME=COST_PATH INCLUDECOSTS=T ALLJ=T, MW[2] = PATHTRACE(LI.DISTANCE), MW[3] = PATHTOLL,
Transportation Systems Engineering, IIT Bombay
Page 4
A Reference Manual on Cube Voyager MW[4] = MW[3]*MI.1.PEAK_OD_PV
In the above example whatever the statements written after ‘;’ sign can be taken as the comment. It is suggested to have comments for all required control lines in order to avoid the confusion in the later stages. For commenting the block of script the sign /*…..script……*/ is used as same as in C language. Every script file starts with the control line RUN PGM=HIGHWAY
and ends with the ENDRUN.
All the script should be written in between those control lines. A simple script is shown in the below example. Example Script: RUN PGM=GENERATION ;
----- land use data file
FILEI ZDATI[1] = {ZDATI.Q}, Z=#1,Emp=#2,BasEmp=#3,SerEmp=#4 ZONES = 25 ;
----- calculate productions by purpose P[1] = 0.8*zi.1.Emp
;
----- calculate attractions by purpose A[1] = 0.8*zi.1.BasEmp+0.5*zi.1.SerEmp
;
----- adjust zonal attractions so total attractions match total
productions PHASE=ADJUST A[1] = P[1][0]/A[1][0] * A[1]
; adjust a's to match p's
; set p's to a's in nhb ;
----- output zonal productions and attractions
ENDPHASE FILEO PAO[1] = {PAO.Q}, FORM=6.0, LIST=Z, P[1] A[1] ENDRUN
Many programs will share the same type of control statements, however the data entered on them may vary between programmes. Standard control statements which we use generally for a simple model are listed below, FILEI
; for specifying input files
Transportation Systems Engineering, IIT Bombay
Page 5
A Reference Manual on Cube Voyager
FILEO
; for specifying output files
LINKO NETO and NETI ; for specifying input and output files COMP ; it assigns the values to variables or matrices IF…ELSEIF…ELSE…ENDIF LOOKUP PRINT READ JLOOP
; for a particular I it operates for all the j in a matrix
*Each control statement is associated with some specific keywords and sub keywords, which can be referred from the help file.
Expressions: Simple expressions will be like, Speed = distance / time Where the speed, distance and time are the variable names. Of course there are some operators to be used in the expressions to make computations. Operator
Symbol
Level
Addition
+
1
Subtraction
-
1
Multiplication
*
2
Division
/
2
Modular
%
2
Exponentiation
^
3
Operators are preceded and succeeded by operands, which may be numeric constants, character constants, variables, functions with their associated arguments enclosed within (...) A program that deals with a variable number of matrices may have the working matrices referenced by using MW [] or MW [][]. Built-in functions are predefined processes that return a value to the expression; they must be followed by one, or more, expression arguments enclosed within parenthesis (). The number of
Transportation Systems Engineering, IIT Bombay
Page 6
A Reference Manual on Cube Voyager
arguments must match the requirements of the function. There are many number of numerical, trigonometric, and character functions as built-in. Some of those functions are listed below. EXP(x) EXPDIST(x,m,t) GAMMADIST(x,a,b,t) LN(x) MAX(x,y,...) POW(x,y) POISSONDIST(x,v,t) RAND() COS(x) DUPSTR(str,n) STRLEN(str) VAL(str) *Explore the help file for explanations and about more built in functions. Selection expressions are used to specify criteria for selecting something. The expression is always enclosed within (...), and, when evaluated, results in a single true or false value. The syntax is similar to standard C language. The following comparison operators are used to determine the relationship between the expressions on either side of the operator (the left expression is A, and the right expression is B)
Expression
Description
A=B
A equals B.
A == B
A equals B.
A != B
A is not equal to B.
A >= B
A is greater than, or equal to, B.
A B
A is greater than B.
A0) PAF=P[PURP]/ATTRSUM MW[PURP]=PAF * MW[PURP] ENDLOOP
; For Getting the Trip Length frequency in print file FREQUENCY VALUEMW=21 BASEMW=11, RANGE=1-50-5, TITLE='** Trips Vs Distance **'
;the DISTRIBUTION module does not have any explicit phases.
The module does
run within an implied ILOOP ; where I is the origin zones.
The module has a built in GRAVITY statement
for implementing this commonly ; used distribution method.
User defined distribution process can also be
defined.
ENDRUN
4.5 HIGHWAY programme
The Highway program supports junction or intersection constrained assignment as well as the typically link based capacity constrained assignment. Junction-constrained assignment requires
Transportation Systems Engineering, IIT Bombay
Page 17
A Referencce Manual o on Cube Voy yager
the codinng of the jun nction or inttersection movements m a controls.. It also usedd to generatte the and high wayy skims w.r..t. time or distance d whiich can be used u for the distributionn and modal split calculatioons. The proggram operattes by proceessing in vaarious phases. In each phase p the prrogram perfforms certain sppecific operrations. For normal proccessing, there must be a way of coomputing ceertain required values for each e link likke capacity, link travel time attribuutes. If theree is no autom matic t program m to determinne these valuues, the userr must supplyy the processs to obtain them. t way for the In that case, c the LIN NKREAD phase can bee used and formulated f t provide thhese values.. The to underlyinng assumptio on is that paath building and capacitty restraint are a based uppon a generaalized cost on each e link. In most cases,, the cost is time. There are several ways to obttain the free flow time (T0)), and the iniitial path tim me (T1) The best advice is thaat the netwoork should coontain a variaable that cann be used dirrectly for T00, or that it conntains variab bles so that DISTANCE D E and SPEED D informatioon can be eaasily obtainedd. The majoor phases in the process are: •SETUP — Optionallly, initializee basic user arrays a and prrocesses •LINKRE EAD — Obttain requiredd values for each e link •ILOOP — Build patths and assiggn trips from m each originn zone •ADJUST T — Examin ne iteration results, r test for f convergeence and adjuust link valuues •CONVE ERGE — Op ptional phasee where userr can specifyy their own convergence c rules * Tolls annd VOT can n also be incoorporated innto the links for f ridershipp estimation on freewayss. Examplee for genera ation of high hway skims and highwaay assignmeent
Inp puts with Script S
P Process
Transporrtation System ms Engineerring, IIT Bom mbay
O Outputs with Runn informatioon
Page 18
A Reference Manual on Cube Voyager
Script file: RUN PGM=HIGHWAY PRNFILE="G:\Sinu\Aakar_Prasad\Working Model_25_03_11\APP FILE\0THWY00B.PRN" FILEI TOLLMATI[1] = "G:\Sinu\Project\Network through CUBE\Supply_Assignment\Tolls.txt", NETIENTRY=ONRAMP, NETIEXIT=OFFRAMP, NETITOLLROAD=TOLLROAD
FILEO PATHO[1] = "G:\SINU\AAKAR_PRASAD\WORKING MODEL_25_03_11\HWAYPATH.PTH" FILEO NETO = "G:\SINU\AAKAR_PRASAD\WORKING MODEL_25_03_11\HWAYLOADED.NET" FILEI MATI[1] = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\CONGESTED_SKIM_PT.MAT"
FILEI NETI = {NETI.Q} FILEO MATO[1] = {MATO.Q}, MO=1-2, NAME=TIME,DISTANCE
PARAMETERS COMBINE = EQUI GAP = 0.005 time_cost1 = 0.5 distance_cost1 = 0.2 ; ----- SET CAPACITY and LINKCLASS PROCESS PHASE=LINKREAD CAPACITY = LI.CAPACITY ; set link classes for major roads IF (LI.LINKCLASS= 1-17) LINKCLASS = 1 ; Group
PT only routes for exclusion from assignment
IF (LI.LINKCLASS>20) ADDTOGROUP=1 ENDPROCESS PROCESS PHASE=ILOOP PATHLOAD PATH=COST, VOL[1]=MI.1.compcost, ; Assigning PV trips, TOLLMATI=1,1, TOLLFACTOR=0.423, ; toll factor is in min/toll units, here 2min/$ (implies VOT=$30/hr) EXCLUDEGROUP=1, ; exclude PT only links MW[1] = PATHTRACE(cost,1),PATHO=1 NAME=COST_PATH INCLUDECOSTS=T ALLJ=T, MW[2] = PATHTRACE(LI.DISTANCE)
Transportation Systems Engineering, IIT Bombay
Page 19
A Reference Manual on Cube Voyager ENDPROCESS PROCESS PHASE=ADJUST function { tc=t0*(1.0+0.15*((v/c)^8)) cost=time*time_cost1+li.distance*distance_cost1 } ENDPROCESS
ENDRUN
It is important to have a basic understanding of the logic of the program, so that when certain special operations are to be performed, they can be placed properly. Example of suggested basic application template RUN PGM=HIGHWAY FILEI FILEO FUNCTION
; include V, TC, and COST functions here
PHASE=SETUP ; normally this phase is not used ... PHASE=LINKREAD ; insert any statements required to: ; extract custom information from the input network. ... PHASE=ILOOP ; build paths, skim paths, load trips to paths ... PHASE=ADJUST ; revise special LW.values for next iteration ... PHASE=CONVERGE ; optional for user specified convergence tests ... ENDRUN
4.6 PUBLIC TRANSPORT Programme
The Public Transport program is the Cube Voyager program that lets you prepare public transport data and model public transport systems. It is the major programme for the total travel demand model for the Public transport analysis. It can offer many number services ranging from preparing the public transport data such as route coding to the public transport assignment using the most sophisticated methods such as stochastic user equilibrium method.
Transportation Systems Engineering, IIT Bombay
It is always
Page 20
A Reference Manual on Cube Voyager
suggested to have at least some outline knowledge on the public transport systems, its components and assignment techniques before using this programme. Some of its applications are listed below, ¾ Demand stratification by user class with variations in the behavior of classes represented
by different cost functions ¾ Comprehensive fares modeling ¾ Preparation of a public transport network for Public Transport’s modeling functionality ¾ Generation of the nontransit element of the public transport network (that is, access,
egress, transfer and park and ride legs) ¾ Skimming, network-wide and mode specific, composite and average travel costs, and
components of costs ¾ Reporting of input data, model infrastructure, multiple routes with probability of use, line
and link loads, secondary analyses The Public Transport program requires as input: •A highway or public transport network •Public transport system data •Line data •Fare data •Nontransit legs (developed externally or by Public Transport) •Generalized cost information •Demand The Public Transport program produces: •Nontransit legs •Enumerated routes •Skim and select-link matrices •Loaded lines and nontransit legs •Transfer matrices—results of loading analyses •A variety of reports of input data and model results A public transport network that can be displayed by Cube and used as an input network for further modeling. Preparing data
Transportation Systems Engineering, IIT Bombay
Page 21
A Reference Manual on Cube Voyager
We can use the Public Transport program to prepare data that supports public transport modeling. We can prepare:
•
A network, produced by Network or Public Transport, containing characteristics of zones, nodes and links (that is, node coordinates, walk and transit link times, distance, and so forth), over which the public transport system operates.
•
System information used to describe the characteristics of the public transport system such as modes, operators , wait curves and crowd curves.
•
Service or line data, defining the characteristics of the lines and nodes traversed.
•
Fare information based on stops or distance.
•
Nontransit legs, presenting opportunities to access the public transport system stops
from the zone centroids through number of links, egress from it and transfer between services during the course of a trip. Nontransit legs may be determined externally and/or generated by Public Transport under user control.
•
Control information or factors for route enumeration and evaluation.
The associated processes with Public transport programme Public Transport Network development
Develops a comprehensive public transport network from the basic network, public transport system data, lines, nontransit leg, and control information. The DATAPREP phase is mandatory for public transport network development. The phase provides the control statements for nontransit leg generation and/or input.
Transportation Systems Engineering, IIT Bombay
Page 22
A Reference Manual on Cube Voyager
Must
Optional
Inputs with Script
Process
Outputs with Run information
Script file: RUN PGM=PUBLIC TRANSPORT PRNFILE="G:\Sinu\Aakar_Prasad\Working Model_25_03_11\APP FILE\0TPTR00A.PRN" FILEO MATO[1] = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\APP FILE\SKIMFILE.MAT" FILEO REPORTO = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\APP FILE\REPORTFILE.PRN" FILEO ROUTEO[1] = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\APP FILE\ROUTEFILE.RTE" FILEO NETO = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\PT NET OUTPUT\PTNET.NET" FILEI FACTORI[1] = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\factor.fac" FILEI FAREI = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\FARES.FAR" FILEI SYSTEMI = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\system.pts" FILEI LINEI[1] = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\lines.lin" FILEI NETI = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\HIGHWAY NET FILE\OUTPUTSCENARIO3LOWCAR.NET" PARAMETERS TRANTIME[1] = (LI.DISTANCE ) 60 / 50 ; Specification of mode ;specific Transit time TRANTIME[2] = (LI.DISTANCE ) 60 / 60 ; Specification of mode ;specific Transit time TRANTIME[3] = (LI.DISTANCE ) 60 / 70 ; Specification of mode ;specific Transit time ;generate access/egress links list='\nGenerate Zone Access/Egress Legs' GENERATE, COST=li.DISTANCE, EXTRACTCOST=(LI.DISTANCE/LI.SPEED)*60 MAXCOST[1]=1.5,MAXCOST[2]=1,MAXCOST[3]=1.9, LIST=T, maxntlegs=4, NTLEGMODE=33 ;generate xfer non-transit legs list='\nGenerate Transfer Legs' GENERATE, COST=li.DISTANCE, EXTRACTCOST=(LI.DISTANCE/LI.SPEED)*60 MAXCOST[1]=1,MAXCOST[2]=1,MAXCOST[3]=2.3, LIST=T, NTLEGMODE = 34, maxntlegs=2,
Transportation Systems Engineering, IIT Bombay
Page 23
A Reference Manual on Cube Voyager fromnode=101-6000,tonode=101-6000, ONEWAY=F ; FROMNODE=1-5500, TONODE=1-5500 ENDPHASE
ENDRUN
Route enumeration and Evaluation
Route enumeration is a heuristic process that identifies a set of discrete routes between zone pairs along with the probability that passengers will use the routes to travel between the zones. Use keywords in the FACTORS control statement to control the route-enumeration process. A previously prepared public transport network is input with NETI. You must enumerate and evaluate routes before extracting skims. The ROUTEO file indicates that the script will enumerate routes. (Alternatively, you could input routes prepared in an earlier run with ROUTEI.) The SKIMIJ phase selects skimming, which the script must explicitly code. Skim functions select the skims for extraction. (Skimming automatically invokes the route-evaluation process.) The route-enumeration process finds minimum-generalized-cost routes between zone pairs to establish a baseline cost. Each route has an access leg, and one or more pairs of transit and nontransit legs, the last of which is an egress leg. First, the program generates minimum-cost routes for all O-D pairs and records the number of transfers required for these routes, MINXOD. Next, the program searches for “attractive” routes for each O-D. Attractive routes depend on the number of transfers: If the number of transfers equals MINXOD, number of transfers must be no greater than •MAXFERS. If number of transfers exceeds MINXOD, no. of transfers must be less than or equal to the •minimum of:
MINXOD+EXTRAXFERS2
EXTRAXFERS1
MAXFERS
These are should be specified in the factor file appropriately.
The route-evaluation process uses a simple tree structure to represent the possible routes from
an origin to a destination. Starting at the origin, passengers might use one or more access legs (first-level branches). At a stop, passengers choose between one or more transit alternatives for
Transportation Systems Engineering, IIT Bombay
Page 24
A Reference Manual on Cube Voyager
the next stage of the trip. One or more second-level branches linked to the first-level branch represent the available choices. Passengers continue, making choices from additional branches, until reaching their destination. All routes arrive at the same destination, though they arrive via different branches. For multirouting models, the first pass starts at the destination zone and calculates the conditional probabilities of each alternative at any decision point in the tree structure. (Trips arriving at the node may proceed towards the destination along any of the alternative next-level branches. Conditional probabilities define what proportion of the trips arriving at a node proceed along each alternative branch.) The second pass starts at the origin, and calculates the probability of choosing each discrete route. This is simply the product of all conditional probabilities along the route. By default, the process computes service-frequency-model calculations for identicalmode lines in a transit-leg bundle. However, when FREQBYMODE is set to F, the calculations consider all lines in a transit-leg bundle, without separating by mode. The route-evaluation process computes a single expected cost to destination (ECD) from any choice or decision point in a trip to the destination. Often called composite cost, the process uses this generalized cost for calculating the probability that passengers will use alternative routes. At choices between walking and alighting transit, the process uses logit models. The logit composite cost formula combines costs, producing a single value that represents the set of alternatives:
Models applied at decision points
1. Walk choices The route-evaluation process applies the walk-choice model when passengers have alternative walk choices for stops available.
Where P is the probability of walking to the stop i. CWi is the generalized cost for walking to the stop i
Transportation Systems Engineering, IIT Bombay
Page 25
A Reference Manual on Cube Voyager
2. Transit choices There are two models are available to be applied at transit stops to calculate the probabilities of choosing an alternative route. Those are, a. The service‐frequency model (SFM)
b. The service‐frequency‐and‐cost model (SFCM). The model assumes that travellers have knowledge of the travel time to the destination associated with each of the alternative routes, and that the traveller is less willing to use slower alternatives. SFM considers only service frequency while SFCM also considers the cost to the destination.
Choice set (5) Excess travel time over average
(6) Wait time without this line
(7) Proportion of time when line used
(8) Cum effective frequency
(9) Wait time including this line
(10) Average travel time including this line
(1) Line
(2) Line frequency
(3) Travel time
(4) Average travel time excluding this line
1
5
20
-
-
-
1
5
12
20
2
6
21
20
1
12
0.917
10.500
5.714
20.52
3
2
22
20.52
1.48
5.714
0.742
11.983
5.007
20.707
4
1
24
20.707
3.293
5.007
0.342
12.326
4.868
20.798
5
1
26
20.798
5.202
4.868
0
-
-
Notes: •Example uses a wait factor of 2 to weight the waiting times. •Column (7) = 1-MIN( (5)/(6)),1) •Column (8) = (2)*(7), accumulated over lines •Column (9) = 60.0/(7) * 0.5 * Wait Factor •Column (10) = ((2)*(3)*(7), accumulated over lines) / (8)
Transportation Systems Engineering, IIT Bombay
Page 26
A Reference Manual on Cube Voyager
Results of the service frequency & cost model
(1) Line
(2) Line frequency
(3) Effective frequency at stop
(4) Cum frequency at stop
(5) Proportion of trips
1
5
5
5
0.406
2
6
5.500
10.500
0.446
3
2
1.483
11.983
0.120
4
1
0.343
12.326
0.028
-
-
5 1 Notes: Column (5) = (3)/cumulative frequency at stop
Skimming – Quick reference
The program can provide several skims, suitable for different purposes. Summary of skim functions Function
Description
BESTJRNY
Skims best trip times
BRDINGS(RouteSet, Mode)
Skims number of boardings
BRDPEN(RouteSet, Mode)
Skims boarding penalty (perceived)
COMPCOST(RouteSet)
Skims composite costs
CWDCOSTP(RouteSet)
Skims crowding link travel times (perceived)
CWDWAITA(RouteSet)
Skims crowding wait times (actual)
CWDWAITP(RouteSet)
Skims crowding wait times (perceived)
DIST(RouteSet, Mode)
Skims distance
EXCESSDEMAND
Skims excess demand (where demand exceeds capacity in
Transportation Systems Engineering, IIT Bombay
Page 27
A Reference Manual on Cube Voyager
crowding model) EXCESSPROP
Skims excess proportion (where demand exceeds capacity in crowding model)
FAREA(RouteSet, Mode)
Skims fares in monetary units
FAREP(RouteSet, Mode)
Skims fares in generalized time units
IWAITA(RouteSet)
Skims initial wait times (actual)
IWAITP(RouteSet)
Skims initial wait times (perceived)
TIMEA(RouteSet, Mode)
Skims travel time (actual)
TIMEP(RouteSet, Mode)
Skims travel time (perceived)
ValOfChoice(RouteSet)
Skims value of choice
XFERPENA(RouteSet, Mode)
Skims transfer penalty (actual)
XFERPENP(RouteSet, Mode)
Skims transfer penalty (perceived)
XWAITA(RouteSet)
Skims transfer wait times (actual)
XWAITP(RouteSet)
Skims transfer times (perceived)
The loading process (assignment) allocates trips, either computed or from the input trip matrix, to services (transit lines) and nontransit legs. The loading process uses routing and travel time information obtained from the route-evaluation process. Crowding process in loading:
The Public Transport program supports two types of crowd models: •Link-travel-time adjustment •Wait-time adjustment It is important to include the following to have the crowding effect during PT assignment. 1. Include the CRUSHCAP and other required statements in the transit line file 2. Include syntax for specifying the crowd model in PT Assignment script file.
Transportation Systems Engineering, IIT Bombay
Page 28
A Reference Manual on Cube Voyager
An iterative process, crowd modeling enables a public transport system’s capacity to influence the system’s travel times and thus the routes found and their probability of use, as calculated during route evaluation. The crowd modeling process uses the loaded demand from an iteration to provide updated values for: •Link travel times (which may vary by user class) •Probability of being able to board a line at a particular stop These calculations incorporate a degree of damping to help stabilize the resulting assignments. The crowding process is viewed as a stochastic assignment, and results are obtained from the final iteration. Crowded networks might cause instabilities in the loadings between iterations, as demand switches toward less congested routes. In turn, those routes might become more heavily loaded, and thus less attractive at the next iteration. These changes might converge toward a solution, or might continue oscillating; oscillation is more likely in highly overloaded networks. The servicefrequency-and-cost model usually results in better convergence than the service-frequency model because the route-choice process is more responsive to changes in costs. What if demand exceeds the capacity of link???
If demand exceeds capacity and no alternative routes are available, then this transit leg acts as a “bottleneck”—not all of the travel demand is able to use the service during the modeled period. The demand remaining at the end of the modeled period would discharge once peak travel volumes subside; those travelers experience additional delays, which form a second component to the wait-time adjustment. “Flow metering” handles the bottleneck effect and the inability of demand to pass through that point. Flow metering removes the excess demand from later stages in the trip; thus demand at any downstream point reflects the number of travellers who can reach that point. For any origin-destination pair, the program can calculate the proportion of flow-metered demand (that is, demand unable to reach its destination due to network bottlenecks), and the number of trips affected.
Example for Route Enumeration, Evaluation and PT assignment:
Inputs with Script
Process
Transportation Systems Engineering, IIT Bombay
Outputs with Run information
Page 29
A Reference Manual on Cube Voyager
Script File: RUN PGM=PUBLIC TRANSPORT PRNFILE="G:\Sinu\Aakar_Prasad\Working Model_25_03_11\APP FILE\0TPTR00B.PRN" MSG='Public Transport Assignment' FILEO ROUTEO[1] = "G:\SINU\AAKAR_PRASAD\WORKING MODEL_25_03_11\UDATED_ROUTES.RTE" FILEI LINEI[1] = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\lines.lin" FILEI ROUTEI[1] = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\APP FILE\ROUTEFILE.RTE" FILEO STOP2STOPO[1] = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\STOP2STOP.DBF", ACCUMULATE=FIRSTLASTBYMODE,MODES=3,NODES=1-1000 FILEI SYSTEMI = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\system.pts" FILEO LINKO[1] = "G:\SINU\AAKAR_PRASAD\WORKING MODEL_25_03_11\UPDATED_LINK.DBF", NTLEGS=N,FMVOLS=Y FILEI FACTORI[1] = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\factor.fac" FILEI FAREI = "G:\Sinu\Aakar_Prasad\Working Model_25_03_11\FARES.FAR" FILEI NETI = {NETI.Q} FILEI MATI[1] = {MATI.Q} ;Input files ;Output Files FILEO NETO = {NETO.Q}, DEC=D FILEO MATO[1] = {MATO.Q}, MO=1-13, NAME = Compcost, ValOfChoice, IWAITA, XWAITA, IWAITP, XWAITP, TIMEAAM, TIMEPAM, BRDPENAM, XFERPENAAM, DISTAM, BRDINGSAM, BESTJRNY, DEC=13*2 FILEO REPORTO = {REPO.Q} ;Globals this invokes Loading PARAMETERS TRIPSIJ[1]=MI.1.1, NOROUTEMSGS=3000, NOROUTEERRS=3000 ; Specification of Crowd model CROWDMODEL, APPLY = T, ADJUSTWAIT = T, ADJUSTLINK = T, ITERATIONS = 3 ;Selection of Loading Reports REPORT LINEVOLS={Checkbox1}, STOPSONLY=T, SKIP0=T, LINES={Checkbox2}, SORT={sort1} ;Loading is done in Phase=SKIMIJ but it is not coded as PARAMETERS TRIPSIJ ;invokes it. ;RA loops over IJ pairs. Routes are enumerated, evaluated and skimmed. PROCESS PHASE = SKIMIJ MW[1]=COMPCOST(0) MW[2]=ValOfChoice(0)
;composite cost ;value of choice
Transportation Systems Engineering, IIT Bombay
Page 30
A Reference Manual on Cube Voyager MW[3]=IWAITA(0) MW[4]=XWAITA(0) MW[5]=IWAITP(0) MW[6]=XWAITP(0) MW[7]=TIMEA(0,ALLMODES) MW[8]=TIMEP(0,ALLMODES) MW[9]= BRDPEN(0,ALLMODES) MW[10]= XFERPENA(0, ALLMODES) ;avg MW[11]= DIST(0,ALLMODES) MW[12]= BRDINGS(0,ALLMODES) MW[13]=BESTJRNY
;initial wait time, actual, avg ;transfer wait time, actual, avg ;initial wait time, perceived, avg ;transfer wait time, perceived, avg ;time for all modes, actual, avg ;time for all modes, perceived, avg ;boarding penalty for all modes, avg ;transfer penalty for all modes, actual, ;distance for all modes, avg ;number of boardings for all modes, avg ;best journey time
ENDPROCESS ;MATO loops over J for each I. In-vehicle time skims, actual & perceived are ;reported here PROCESS PHASE = MATO if(ROWSUM(1) if(ROWSUM(7) FORM=10.2 if(ROWSUM(8) FORM=10.2
> 0) PRINTROW mw=1 > 0) PRINTROW mw=7
TITLE='Comp Cost', BASE1=T, FORM=10.2 TITLE='TIMEA ALLMODES', BASE1=T,
> 0) PRINTROW mw=8
TITLE='TIMEP ALLMODES', BASE1=T,
ENDPROCESS ENDRUN
.......................................................End of the Manual...........................................................
Transportation Systems Engineering, IIT Bombay
Page 31
A Reference Manual on Cube Voyager
Acknowledgement
It is very thankful to CITILABS as all the information in this manual is compiled from the Help file of CUBE, training material and also from the demo model developed using CUBE voyager. This manual is prepared for the internal use only for classroom teaching for the students. Please notify if there are any mistakes in the manual. TSE, IIT BOMBAY
Transportation Systems Engineering, IIT Bombay
Page 32
View more...
Comments
