Cube Voyager Training Manual

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

Transportation Systems Engineering, IIT Bombay Page 2

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.



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

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,

Command keyword=value



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

Characters:

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

Case: Insensitive.

First

Character:

Any of the valid characters, except 0-9.

Temporary

variables:

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

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

Transpor

If a variab

NODEI or

as below,

For node

records:

For link

records:

Bold one

Main Ap

1. It

at

2. It

fo

Simple E

Script filRUN PGM=

NOV'2010

; Specif

FILEI LI

;Specifi

VAR=A,1

FILEI NO

VAR=N,1

FILEO NE

I

rtation System

ble from an i

LINKI file num

e NI.#

LI.#

es are the pre

pplications:

t can also b

ttributes for

t is useful fo

ormat with p

Example for

e: =NETWORK P

0\TAZ_AKAR

fication o

INKI[1] =

fication of

1-5,B,6-10

ODEI[1] =

1-5,X,6-15

ETO = {NET

Inputs with Script

ms Engineer

input file is t

mber must p

#.name N

#.name LI

eferred desig

be done by

links or nod

or developin

proper script

r developing

PRNFILE="G:

R\CUBE\NTNE

of Input li

{LINKI.Q},

f variable

0,Distance,

{NODEI.Q},

5,Y,16-25

TO.Q}

ring, IIT Bom

o be referen

recede the va

NI#.name N.

I#.name L.#

gnations as m

using the n

des can be ea

ng the highw

.

g the networ

:\SINU\AAK

ET00B.PRN"

ink and no

,

names pre

,11-20,Spe

,

Process

mbay

ced during N

ariable name

#.name N#.

#.name L#.

most users fo

network prog

asily overlap

way networks

rk from AS

KAR_PRASAD\

" MSG='Netw

ode files t

esent in th

eed,21-30,C

A Referenc

NODEMERGE

. The normal

.name

name

ollow that.

gramme that

pped on the i

s with link a

SCII files,

\SHP FROM

work for D

throgh FIL

he input A

Capasity,3

Outputs winforma

ce Manual o

or LINKMERG

designation

t the additio

nput networ

and node dat

TRANSCAD_0

Demo with 3

LEI and FIL

ASCII files

31-40,Direc

with Run ation

on Cube Voy

Pa

GE, the assoc

for the referr

onal variabl

rk.

ta as in spec

08TH

31 Zones'

LEO comman

s

ction,41-5

yager

ge 10

ciated

ring is

les or

cified

nds

50



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

Transpor

Script filRUN PGM=

CUBE\DEM

FILEI MA

NETWORK\

FILEI MA

NETWORK\

FILEO MA

CUBE\DEM

mo=71-72

FILEI MA

; Devidi

mw[11]=

mw[12]=

if(I=1-2

jloop

mw[21]=

;calcula

mw[22]=

0.485*MI

mw[23]=

;utility

rtation System

e: =MATRIX PR

MAND\02MAT

ATI[2] = "

\00LOO00B.

ATI[1] = "

\00LOO00A.

ATO[1] = "

MAND\MODES

2,NAME=HBW

ATI[3] = "

ding the pe

mi.3.hbwf

mi.3.hbwf

232) ; For

INCLUDE=1

EXP(-0.05

ation of u

EXP(0.08-

I.2.OVDIST

EXP(-4.62

y of IPT

Inp

ms Engineer

RNFILE="G:\

T00A.PRN" M

"G:\SINU\PR

.MAT"

"G:\SINU\PR

.MAT"

"G:\SINU\PR

SPLIT_HBWF.

WF_PT,HBWF_

"G:\SINU\PR

erson trips

f*0.7,

f*0.3

r Island Ci

1-1030

553*MI.2.IV

utility of

-0.0553*MI.

T_PT), ; ca

21-0.0553*M

puts with Script

ring, IIT Bom

\SINU\PROJ

MSG='Modal

ROJECT\NET

ROJECT\NET

ROJECT\NET

.MAT",

_PV

ROJECT\NET

s into CAT

ity

VTT_PT-0.0

train

.2.IVTT_PT

aculation

MI.1.TIME-

P

mbay

JECT\NETWOR

l Split for

TWORK THROU

TWORK THROU

TWORK THROU

TWORK THROU

TIVE as 70%

0192*MI.2.I

T-0.0192*MI

of utility

-0.0192*1.2

Process

A Referenc

RK THROUGH

r HBW-Offi

UGH CUBE\V

UGH CUBE\V

UGH

UGH CUBE\D

% and CHOI

IVTT_PT-0.

I.2.IVTT_P

y of bus

2*MI.1.TIM

OuRun

ce Manual o

H

ice Purpose

VOYAGER

VOYAGER

DEMAND\02DS

ICE as 30%

485*MI.2.O

PT-

ME),; cacul

utputs with n information

on Cube Voy

Pa

e'

ST00A.MAT"

OVDIST_PT)

lation of

n

yager

ge 12

"

, ;

Transpor

mw[24]=

;utility

mw[25]=

0.97*MI.

MW[29]=M

;[Denomi

MW[71]=(

MW[25]/M

MW[72]=(

Endjl

endif

4.3 GEN

This prog

zonal dat

for up to

what is to

files (pro

Productio

respectiv

As are s

dimensio

We have

and ZON

rtation System

EXP(3.458

y of Priva

EXP(0.9-0

.2.OVDIST_

MW[21]+MW[

inator]

(MW[21]/MW

MW[29])*MW

(MW[24]/MW

loop

NERATION

gramme used

ta according

o twenty pur

o be accomp

oductions and

ons and attra

vely. There m

stored into a

oned. Only th

e to set the

NES inbuilt v

Inp

ms Engineer

8-0.0553*MI

ate Vehicle

0.0553*MI.2

_PT),; cacu

22]+MW[23]

W[29])*MW[1

W[12]+MW[11

W[29])*MW[1

N Programm

d only for th

to specified

rposes. Ther

plished. Usua

d attractions

actions are t

may be up to

arrays and m

he first index

Maximum p

variables.

puts with Script

ring, IIT Bom

I.2.IVTT_P

es

2.IVTT_PT-

ulation of

]+MW[24]+M

12]+(MW[22

1],; cacul

12]; cacul

me

he Trip Gen

d expressions

re are no def

ally, you use

s) for use in a

to be compu

o twenty Ps

must be refe

x (purpose) i

purposes and

P

mbay

PT-0.0192*M

-0.0192*MI.

f utility o

MW[25],; ca

2]/MW[29])*

lation of P

lation of P

neration proc

s, and genera

fault process

e the Genera

a trip distrib

uted for each

and twenty

erenced with

is required; t

d maximum

Process

A Referenc

MI.2.IVTT_

.2.IVTT_PT

of Metro

aculation

*MW[12]+(M

PT Trips

PV Trips

cess. The Ge

ates arrays o

ses; it is your

ation program

bution model

h zone; they

As for each

h array nota

the second in

m number of

OuRun

ce Manual o

_PT),; cacu

T-

of sum of

MW[23]/MW[2

eneration pro

of production

r responsibil

m to produce

l.

y are referre

h zone. The c

ation. The a

ndex (zone)

f zones with

utputs with n information

on Cube Voy

Pa

ulation of

utilities

29])*MW[12

ogram proce

ns and attrac

lity to specif

e trip end dat

ed to as P an

computed P

arrays are do

is optional.

the MAXP

n

yager

ge 13

f

s

2]+(

esses

ctions

fy

ta

nd A,

s and

oubly

PURP



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.

ijjjiiij FDBOAT =

Where,

∑=

jijjj

i FDBA 1

∑=

iijii

j FOAB 1

=ijF the deterrence function

= ( ) ( )ijij CC βα exp

ijC = Highway travel time from i to j

ijT = Number of trips between zones i and j.

α = Calibration parameter – power function

β = Calibration parameter – exponential function

Transpor

Here we

Example

Script Fil

RUN PGM=

NOV'2010

FILEO MA

NOV'2010

mo=1, na

;and its

FILEI MA

NOV'2010

FILEI ZD

NOV'2010

z=#1, p1

zones=31

; Conver

PAR maxi

;Initial

SETPA p[

;;;;; LO

LOOKUP N

LOOKUP[1

LOOKUP[2

INTERPOL

R=' 1 -0

rtation System

are not calib

e on trip dis

le:

=DISTRIBUT

0\TAZ_AKAR

ATO[1] = "

0\TAZ_AKAR

ame=tripdi

s name

ATI[1] = "

0\TAZ_AKAR

DATI[1] =

0\TAZ_AKAR

1=#2, a1=#

1

rgence or

iters=45,

lizing the

[1]=zi.1.p

OOK UP FUN

NAME=FF,;

1]=1, RESU

2]=1, RESU

LATE=N, ;

0.020 -0.1

Inp

ms Engineer

brating and d

stribution u

TION PRNFIL

R\CUBE\NTDS

"G:\SINU\AA

R\CUBE\NTDS

istPA ; Su

"G:\SINU\AA

R\CUBE\HIGH

"G:\SINU\A

R\CUBE\TRIP

#3

stopping c

maxrmse=5

e productio

p1,A[1]=zi.

NCTION DECL

Gamma Func

ULT=2, ; AL

ULT=3, ; BE

No Interpo

123' ; Pur

puts with Script

ring, IIT Bom

directly forec

sing Gravit

LE="G:\SIN

ST00B.PRN"

AKAR_PRASA

ST00A.MAT"

ub Keyword

AKAR_PRASA

HWAY SKIMS

AAKAR_PRAS

P GENERATI

criteria

on and att

.1.a1

LARATION;;

ction Para

LPHA VALUE

ETA VALUE

olation ne

rpose 1, A

P

mbay

casting with

ty Model,

NU\AAKAR_PR

"

AD\SHP FROM

",

ds, specifi

AD\SHP FROM

S\INTISKIM.

SAD\SHP FRO

ION\TRIPGEN

tractions f

;;;;;;;;

ameters

E

eeded on in

Alpha, Beta

Process

A Referenc

h the calibrat

RASAD\SHP

M TRANSCAD

ication of

M TRANSCAD

.MAT"

OM TRANSCA

NOUTPUTPA.

from the z

ncome clas

a

ORu

ce Manual o

ed paramete

FROM TRANS

D_08TH

f output ma

D_08TH

AD_08TH

DAT",

zonal data

ss

Outputs withun informatio

on Cube Voy

Pa

ers α and β.

SCAD_08TH

atrix numb

file

h on

yager

ge 16

ber



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

Transpor

the codin

high way

calculatio

The prog

certain sp

required

way for t

In that c

underlyin

cost on e

time (T0)

The best

that it con

The majo

• SETUP

• LINKRE

• ILOOP

• ADJUST

• CONVE

* Tolls an

Example

rtation System

ng of the jun

y skims w.r.

ons.

gram operat

pecific oper

values for e

the program

case, the LIN

ng assumptio

each link. In

), and the ini

advice is tha

ntains variab

or phases in

— Optional

EAD — Obt

— Build pat

T — Examin

ERGE — Op

nd VOT can

e for genera

InpS

ms Engineer

nction or int

.t. time or d

tes by proce

rations. For

each link lik

m to determin

NKREAD p

on is that pa

most cases,

itial path tim

at the netwo

bles so that D

the process

lly, initialize

tain required

ths and assig

ne iteration r

ptional phase

n also be inco

ation of high

puts with Script

ring, IIT Bom

tersection m

distance whi

essing in va

normal proc

ke capacity,

ne these valu

hase can be

ath building

, the cost is

me (T1)

ork should co

DISTANCE

are:

e basic user a

d values for e

gn trips from

results, test f

e where user

orporated in

hway skims

P

mbay

movements a

ich can be u

arious phase

cessing, the

link travel

ues, the user

e used and f

and capacit

time. There

ontain a varia

E and SPEED

arrays and pr

each link

m each origin

for converge

r can specify

nto the links f

and highwa

Process

A Referenc

and controls.

used for the

s. In each p

re must be

time attribu

r must supply

formulated t

ty restraint a

are several

able that can

D informatio

rocesses

n zone

ence and adju

y their own c

for ridership

ay assignme

ORun

ce Manual o

. It also used

distribution

phase the pr

a way of co

utes. If there

y the proces

to provide th

are based up

ways to obt

n be used dir

on can be ea

ust link valu

convergence

p estimation

ent

Outputs with n informatio

on Cube Voy

Pa

d to generat

n and modal

rogram perf

omputing ce

e is no autom

ss to obtain t

hese values.

pon a genera

tain the free

rectly for T0

asily obtained

ues

rules

on freeways

on

yager

ge 18

te the

split

forms

ertain

matic

them.

. The

alized

flow

0, or

d.

s.



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.



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,

Must

Optional

Inputs with Script

Process Outputs with Run information



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

(1) Line

(2) Line frequency

(3) Travel time

(4) Average travel time excluding this line

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

(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



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.



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 Script

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

Documents

Cube Voyager Training Manual