Cube Voyager Training Manual PDF

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


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


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


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


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


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 less than, or equal to, B.
A>B A is greater than B.
A<B A is less than B.


A <> B A is not equal to B.
|| is logical OR and && is the logical AND while making the comparisons.
Variables:
Variables used in expressions must have a valid name. There are some basic rules that must be
followed in assigning a name to a variable.
Rule Description
Length: Any reasonable length; network variables may not exceed 15 characters. If a
database file (.dbf) is to be written, the program will truncate the name to 10
characters (the maximum for the dbf).
Valid A-Z, a-z, 0-9, _$#@

Characters:
Case: Insensitive.
First Any of the valid characters, except 0-9.

Character:
Temporary Convention is to use underscore ”_” as the first character.

variables:
Variables are also used to reference items specific to a program. In a network-processing

program, they could reference the variables associated with a network. In a matrix program, they
could reference certain matrices.
Filename
format Description
MI.3.varname refers to the matrix named varname found on the file designated by MATI[3]=
on the FILEI control statement. If varname is a number, it refers to a relative
matrix on the file
NI.3.varname refers to the variable named varname found in the node portion of the network
file designated by NETI[3]= on the FILEI control statement.
LI.2.varname refers to the variable named varname found in the link portion of the network


file designated by NETI[2]= on the FILEI control statement.
ZI.5.varname refers to the array named varname generated by the file designated by
ZDATI[5]= on the FILEI control statement. Zonal data are read into zonal
arrays; each variable is an array with zones cells. Usually, the reference to a
zonal value would also include a subscript; for example, ZI.5.POP[I].
3. Explanation on Programmes
4.1 NETWORK Programme
Network is a utility program for processing highway networks. The program can process up to
ten input networks simultaneously, and can generate one output network. The program can read
input network files of various formats: ASCII records, standard database in dBASE style
(DBF), Cube geodatabase networks, or any Cube Voyager, TP+, MINUTP, Tranplan, or TRIPS
binary network format. The program generates a data record for each unique node and each link
found in any of the input files. For a valid node record, the Network program requires a node
variable, named N. For a valid link record, the Network program requires an A-node, named A,
and a B-node, named B. Each A-node and B-node must exist on a node record. To open, view,
and edit the network in Cube Graphics, the node records must also have two additional variables,
named X and Y, that represent the X- and Y-coordinates of each node.
This programme is having its own built in variables and built in functions which can be referred
from the help file. The program processes the input files in separate phases, which are listed below.
For most applications, the user need not be concerned with process phases; they are used only when
special processing is to be undertaken.
The basic phases are:
INPUT phase — Read ASCII and DBF files, re-code values from any input files specifically
•designated.
•NODEMERGE phase — Read all node data and organize it
•LINKMERGE phase — Read all link data and process it (main phase)
•SUMMARY phase — Report results of LINKMERGE phase


A Referencce Manual o yager
on Cube Voy

If a variab
ble from an input
i file is to be referenced during NODEMERGE
N or LINKMERG
GE, the assocciated
NODEI or LINKI file num
mber must precede the vaariable name. The normal designation for the referrring is
as below,
For nodee NI.#

#.name N
NI#.name N.#.name N#..name
records:
For link LI.#

#.name LII#.name L.##.name L#.name
records:
Bold onees are the preeferred desiggnations as most

m users foollow that.
Main Ap
pplications:
1. Itt can also be
b done by using the network
n proggramme thatt the additioonal variablles or
atttributes for links or noddes can be eaasily overlappped on the input networrk.
2. Itt is useful fo
or developinng the highw
way networkss with link and
a node datta as in speccified
foormat with proper
p script.
Simple Example
E forr developingg the networrk from AS
SCII files,
IInputs with Process Outputs with

w Run
Script informaation
Script file:
RUN PGM=
=NETWORK PRNFILE="G:
P :\SINU\AAK
KAR_PRASAD\
\SHP FROM TRANSCAD_0
08TH
NOV'2010
0\TAZ_AKAR
R\CUBE\NTNE
ET00B.PRN"
" MSG='Netw
work for Demo
D with 31
3 Zones'
; Specif
fication of
o Input li
ink and no
ode files throgh
t FIL
LEI and FIL
LEO comman
nds
FILEI LI
INKI[1] = {LINKI.Q},
,
;Specifi f variable names pre
fication of esent in th
he input ASCII
A files
s
VAR=A,1
1-5,B,6-10
0,Distance,
,11-20,Spe
eed,21-30,C
Capasity,3
31-40,Direc
ction,41-5
50
FILEI NO
ODEI[1] = {NODEI.Q},
,
VAR=N,1
1-5,X,6-15
5,Y,16-25
FILEO NE
ETO = {NET
TO.Q}
Transporrtation System
ms Engineerring, IIT Bom
mbay Page 10


; Specification of number of Zones
ZONES={zones}
ENDRUN
3.2 MATRIX Programme

The Matrix program processes zonal data and matrices according to specified
expressions. Zonal data and matrices can be input, and matrices and reports can be
output. Various file formats for both input and output are supported. There are no default
processes; you must specify what is to be accomplished. This program is also used when
invoked as a special function via RUN PGM= FRATAR, GENERATION, or
DISTRIBUTION. It is used for the following purposes:
•Computation of new matrix values , multiplication and addition of matrices
•Trip distribution (called by Distribution program)
•Trip generation (called by Generation program)
•Converting and merging matrices between various formats
• Transposing matrices
•Generating matrices
•Renumbering, aggregating, and disaggregating matrices
There are certain built-in variables (RECI.NUMRECORDS, Z, MW [], FIRSTZONE, RECI.NUMFIELD… etc)
that can be referenced. The built-in variable is usually protected, the user is not allowed to alter
their values.
If a variable from an input matrix file is to be referenced, the associated MATI or DBI file
number must precede the variable name. The normal designation for the referring is as below,
MI.#.name MI#.name DBA.#.name MO.#.name RECI.#.name
Bold ones are the preferred designations as most users follow that.
Main Applications:
1. All of the purposes mentioned above.
2. Model Split calculations, (utilities and calculating probabilities from the logit models or
probit models)
Simple Example for Model Split Calculations,

on Cube Voy

Inp
puts with P
Process Ouutputs with
Script Runn informationn
Script file:
RUN PGM=
=MATRIX PR
RNFILE="G:\
\SINU\PROJ
JECT\NETWOR
RK THROUGH
H
CUBE\DEM
MAND\02MAT
T00A.PRN" MSG='Modal
M l Split for
r HBW-Offi
ice Purpose
e'
FILEI MA
ATI[2] = "G:\SINU\PR
" ROJECT\NET
TWORK THROU
UGH CUBE\V
VOYAGER
NETWORK\
\00LOO00B.
.MAT"
FILEI MA
" ROJECT\NET
TWORK THROU
UGH CUBE\V
VOYAGER
NETWORK\
\00LOO00A.
.MAT"
FILEO MA
ATO[1] = "G:\SINU\PR
" ROJECT\NET
TWORK THROU
UGH
CUBE\DEM
MAND\MODES
SPLIT_HBWF.
.MAT",
mo=71-72
2,NAME=HBW
WF_PT,HBWF_
_PV
FILEI MA
" ROJECT\NET
TWORK THROU
UGH CUBE\D
DEMAND\02DS
ST00A.MAT"
"
; Devidi
ding the pe
erson trips
s into CAT
TIVE as 70%
% and CHOI
ICE as 30%
mw[11]= mi.3.hbwf
f*0.7,
mw[12]= mi.3.hbwf
f*0.3
if(I=1-2
232) ; For
r Island Ci
ity
jloop INCLUDE=1
1-1030
mw[21]= EXP(-0.05
553*MI.2.IV
VTT_PT-0.0
0192*MI.2.I
IVTT_PT-0.485*MI.2.O
OVDIST_PT), ;
;calcula
ation of utility
u of train
mw[22]= EXP(0.08-
-0.0553*MI.
.2.IVTT_PT
T-0.0192*MI
I.2.IVTT_P
PT-
0.485*MI
I.2.OVDIST
T_PT), ; ca
aculation of utility
y of bus
mw[23]= EXP(-4.62
21-0.0553*M
MI.1.TIME-
-0.0192*1.2
2*MI.1.TIM
ME),; cacul
lation of
;utility
y of IPT
mbay Page 12

on Cube Voy

mw[24]= EXP(3.458
8-0.0553*MI
I.2.IVTT_P
PT-0.0192*M
MI.2.IVTT_
_PT),; cacu
ulation of
f
y of Priva
;utility ate Vehicle
es
mw[25]= EXP(0.9-0
0.0553*MI.2
2.IVTT_PT-
-0.0192*MI.
.2.IVTT_PT
T-
0.97*MI.
.2.OVDIST_
_PT),; cacu
ulation of
f utility of
o Metro
MW[29]=M
MW[21]+MW[22]+MW[23]
]+MW[24]+M aculation of sum of utilities
MW[25],; ca s
;[Denomi
inator]
MW[71]=(
(MW[21]/MW
W[29])*MW[1
12]+(MW[22
2]/MW[29])*
*MW[12]+(M
MW[23]/MW[2
29])*MW[12
2]+(
MW[25]/M
MW[29])*MW
W[12]+MW[11
1],; cacul
lation of PT
P Trips
MW[72]=(
(MW[24]/MW
W[29])*MW[1
12]; cacul
lation of PV
P Trips
Endjl
loop
endif
NERATION
4.3 GEN N Programm
me
This proggramme used
d only for thhe Trip Gen
neration proccess. The Geeneration proogram proceesses
zonal datta according to specifiedd expressionss, and generaates arrays of
o productionns and attracctions
for up too twenty purrposes. Therre are no deffault processses; it is yourr responsibillity to speciffy
what is too be accomp
plished. Usuaally, you usee the Generaation program
m to producee trip end datta
files (prooductions and
d attractionss) for use in a trip distribbution modell.
Productioons and attraactions are to
t be compuuted for eachh zone; theyy are referreed to as P annd A,
respectivvely. There may
m be up too twenty Ps and twenty As for eachh zone. The computed
c Ps and
As are stored
s into arrays
a and must
m be refeerenced withh array notaation. The arrays
a are dooubly
dimensiooned. Only th
he first indexx (purpose) is
i required; the
t second inndex (zone) is optional.
We havee to set the Maximum purposes
p andd maximum
m number off zones with the MAXP
PURP
and ZON
NES inbuilt variables.
v
Inp
puts with P
Process Ouutputs with
Script Runn informationn
mbay Page 13


Script file:
RUN PGM=GENERATION PRNFILE="G:\SINU\PROJECT\NETWORK THROUGH

CUBE\DEMAND\02GEN00A.PRN" MSG='Trip Generation for 6 purposes'
FILEI ZDATI[1] = "G:\Sinu\Project\Network through CUBE\Demand\Planning

Variables.prn",
Z=#1,POP=#2,RW=#3,RWF=#4,RWI=#5,RWO=#6,RS=#7,OJ=#8,IJ=#9,OTJ=#10,TJ=#11
ZONES=1030
MAXPURP=3
; ----- calculate productions by purpose
P[1] = 0.743*RWF
P[2] = 0.420*RWI
P[3] = 0.286*RWO
; ----- calculate attractions by purpose

A[1] = 0.742*OJ
A[2] = 0.477*IJ
A[3] = 0.293*OTJ
PROCESS PHASE=ADJUST
; This phase is optional and if used is processed only once after the
;completion of the ILOOP phase.
; This phase is used to adjust and/or balance the final trip productions and
;attractions.
A[1] = P[1][0]/A[1][0] * A[1] ; adjust a's to match p's

A[2] = P[2][0]/A[2][0] * A[2]
P[3] = A[3] ; set p's to a's in nhb
ENDPROCESS
; FILEO PAO keyword is used to write the computed P and A values to

;file records


FILEO PAO[1] = "G:\SINU\PROJECT\NETWORK THROUGH CUBE\DEMAND\02GEN00A.DAT",
LIST=Z, P[1] P[2] P[3] A[1] A[2] A[3]
ENDRUN
4.4 DISTRIBUTION Programme

This programme used only for the Trip Distribution process. Trip distribution is the process of
estimating the number trips that will travel between all the zones in the system. Usually the
process uses the number of trip ends in each zone as the starting point. These margin totals are
distributed to the rows and column of a generated matrix. Usually, additional information about
some measure of travel between each zone pair should be included in the process. The most
commonly used distribution process is the “gravity” model, but other processes are also
employed. Cube Voyager does not have any automatic, or default, trip distribution process. The
Matrix program provides a framework that allows the user to perform distribution in a variety of
ways.
A Gravity Trip Distribution model of the following form is calibrated for distributing the total
internal passenger trips.
Tij = Ai Oi B j D j Fij
Where,
1
Ai =
∑ B j D j Fij
j
1
Bj =
∑ Ai Oi Fij
i
Fij = the deterrence function
= (C ij ) exp(β C ij )
α
Cij = Highway travel time from i to j
Tij = Number of trips between zones i and j.
α = Calibration parameter – power function
β = Calibration parameter – exponential function

on Cube Voy

Here we are not calib

brating and directly
d foreccasting withh the calibrated parameteers α and β.
Examplee on trip disstribution using Gravitty Model,
Inp
puts with P
Process Outputs withh
O
Script Ruun informatioon
Script Fille:
RUN PGM=
=DISTRIBUT
TION PRNFIL
LE="G:\SIN
NU\AAKAR_PR
RASAD\SHP FROM TRANS
SCAD_08TH
NOV'2010
0\TAZ_AKAR
R\CUBE\NTDS
ST00B.PRN"
"
FILEO MA
ATO[1] = "G:\SINU\AA
" AKAR_PRASA
AD\SHP FROM
M TRANSCAD
D_08TH
NOV'2010
0\TAZ_AKAR
R\CUBE\NTDS
ST00A.MAT"
",
mo=1, na
ame=tripdi
istPA ; Su
ub Keyword
ds, specifi
ication of
f output ma
atrix numb
ber
;and its
s name
FILEI MA
ATI[1] = "G:\SINU\AA
" AKAR_PRASA
AD\SHP FROM
M TRANSCAD
D_08TH
NOV'2010
0\TAZ_AKAR
R\CUBE\HIGH
HWAY SKIMS
S\INTISKIM.
.MAT"
FILEI ZD
DATI[1] = "G:\SINU\A
AAKAR_PRAS
SAD\SHP FRO
OM TRANSCA
AD_08TH
NOV'2010
0\TAZ_AKAR
R\CUBE\TRIP
P GENERATI NOUTPUTPA.DAT",
ION\TRIPGEN
z=#1, p1
1=#2, a1=#
#3
zones=31
1
; Conver
rgence or stopping criteria
c
PAR maxi
iters=45, maxrmse=5
;Initial
lizing the
e productio
on and att
tractions from
f the zonal
z data file
SETPA p[
[1]=zi.1.p
p1,A[1]=zi.
.1.a1
;;;;; LO
OOK UP FUN
NCTION DECL
LARATION;;
;;;;;;;;
LOOKUP NAME=FF,;
N Gamma Func
ction Para
ameters
LOOKUP[1
1]=1, RESU
ULT=2, ; AL
LPHA VALUE
E
LOOKUP[2
2]=1, RESU
ULT=3, ; BE
ETA VALUE
INTERPOL
LATE=N, ; No Interpo
olation ne
eeded on in
ncome clas
ss
R=' 1 -0
0.020 -0.1
123' ; Pur
rpose 1, Alpha,
A Beta
a
mbay Page 16


mw[11]=mi.1.1
; Creating Friction Factors
LOOP purp=1
alpha=FF(1,purp)
beta=FF(2,purp)
TSKIM=purp+10 ; Input Time Skim to MW[11]
GSKIM=purp+20 ; Output Gamma (Friction factors) Skim
; PUT GAMMA MATRICES IN MW[21]
mw[GSKIM]=(mw[TSKIM]^alpha)*exp(beta*mw[TSKIM])
ENDLOOP
;Trip Distribution Step

LOOP PURP=1 ; creates MW[1]
PAF=0
MW[PURP] = A[PURP] * MW[PURP+20]
ATTRSUM=ROWSUM(PURP)
IF (ATTRSUM>0) 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

on Cube Voy

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
way for the
t program
m to determinne these valuues, the userr must supplyy the processs to obtain them.
t
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 P
Process O
Outputs with
Script
S Runn informatioon
mbay Page 18


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)


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. It is always


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


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.


Must
Optional
Inputs with Process Outputs with

Script 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
TRANTIME[3] = (LI.DISTANCE ) 60 / 70 ; Specification of mode
;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,


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


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


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
(4) (5) (10)

Average Excess (6) (7) (9) Average
travel travel Wait Proportion (8) Wait travel
(2) (3) time time time of time Cum time time
(1) Line Travel excluding over without when line effective including including
Line frequency time this line average this line used frequency this line 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)


Results of the service frequency & cost model
(2) (3) (4)

(1) Line Effective Cum frequency at (5)
Line frequency frequency at stop stop 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


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, Skims transfer penalty (actual)

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


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 service-
frequency-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 Process Outputs with

Script Run information


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) ;composite cost

MW[2]=ValOfChoice(0) ;value of choice


MW[3]=IWAITA(0) ;initial wait time, actual, avg
MW[4]=XWAITA(0) ;transfer wait time, actual, avg
MW[5]=IWAITP(0) ;initial wait time, perceived, avg
MW[6]=XWAITP(0) ;transfer wait time, perceived, avg
MW[7]=TIMEA(0,ALLMODES) ;time for all modes, actual, avg
MW[8]=TIMEP(0,ALLMODES) ;time for all modes, perceived, avg
MW[9]= BRDPEN(0,ALLMODES) ;boarding penalty for all modes, avg
MW[10]= XFERPENA(0, ALLMODES) ;transfer penalty for all modes, actual,
;avg
MW[11]= DIST(0,ALLMODES) ;distance for all modes, avg
MW[12]= BRDINGS(0,ALLMODES) ;number of boardings for all modes, avg
MW[13]=BESTJRNY ;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) > 0) PRINTROW mw=1 TITLE='Comp Cost', BASE1=T, FORM=10.2

if(ROWSUM(7) > 0) PRINTROW mw=7 TITLE='TIMEA ALLMODES', BASE1=T,
FORM=10.2
if(ROWSUM(8) > 0) PRINTROW mw=8 TITLE='TIMEP ALLMODES', BASE1=T,
FORM=10.2
ENDPROCESS
ENDRUN
.......................................................End of the Manual...........................................................


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

Cube Voyager Training Manual PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cube Voyager Training Manual PDF

Uploaded by

Copyright:

Available Formats

A Reference Manual on

Travel Demand Modeling using

Transportation Systems Engineering

1. First Install the Citilabs license CD.

;keyword and COST is the value

VOL[1]=MI.1.PEAK_OD_PV, ; Assigning PV trips,

TOLLFACTOR=0.423, ; toll factor is in min/toll units, here 0.423 min/Rs ;

EXCLUDEGROUP=1, ; exclude PT only links

MW[1] = PATHTRACE(cost,1),PATHO=1 NAME=COST_PATH INCLUDECOSTS=T ALLJ=T,

; ----- calculate attractions by purpose

; ----- adjust zonal attractions so total attractions match total

FILEO ; for specifying output files

A >= B A is greater than, or equal to, B.

A <= B A is less than, or equal to, B.

A>B A is greater than B.

A<B A is less than B.

A <> B A is not equal to B.

Valid A-Z, a-z, 0-9, _$#@

First Any of the valid characters, except 0-9.

Temporary Convention is to use underscore ”_” as the first character.

Variables are also used to reference items specific to a program. In a network-processing

file designated by NETI[2]= on the FILEI control statement.

For nodee NI.#

For link LI.#

Bold onees are the preeferred desiggnations as most

IInputs with Process Outputs with

3.2 MATRIX Programme

RUN PGM=GENERATION PRNFILE="G:\SINU\PROJECT\NETWORK THROUGH

FILEI ZDATI[1] = "G:\Sinu\Project\Network through CUBE\Demand\Planning

; ----- calculate attractions by purpose

A[1] = P[1][0]/A[1][0] * A[1] ; adjust a's to match p's

; FILEO PAO keyword is used to write the computed P and A values to

4.4 DISTRIBUTION Programme

Fij = the deterrence function

Cij = Highway travel time from i to j

Tij = Number of trips between zones i and j.

α = Calibration parameter – power function

β = Calibration parameter – exponential function

Here we are not calib

Examplee on trip disstribution using Gravitty Model,

; Creating Friction Factors

;Trip Distribution Step

; For Getting the Trip Length frequency in print file

4.5 HIGHWAY programme

the codinng of the jun

* Tolls annd VOT can

RUN PGM=HIGHWAY PRNFILE="G:\Sinu\Aakar_Prasad\Working Model_25_03_11\APP

FILEO PATHO[1] = "G:\SINU\AAKAR_PRASAD\WORKING MODEL_25_03_11\HWAYPATH.PTH"

FILEI NETI = {NETI.Q}

PARAMETERS COMBINE = EQUI GAP = 0.005

4.6 PUBLIC TRANSPORT Programme

• A network, produced by Network or Public Transport, containing characteristics of

The associated processes with Public transport programme

Inputs with Process Outputs with

PARAMETERS TRANTIME[1] = (LI.DISTANCE ) 60 / 50 ; Specification of mode

;generate xfer non-transit legs

Route enumeration and Evaluation

The route-enumeration process finds minimum-generalized-cost routes between zone pairs to

These are should be specified in the factor file appropriately.

Models applied at decision points

Where P is the probability of walking to the stop i.

(4) (5) (10)

2 6 21 20 1 12 0.917 10.500 5.714 20.52