The document presents a model for optimizing passenger travel time in train timetabling by accounting for knock-on delays. It develops a stochastic goal function to minimize expected passenger transfer time considering primary delays and knock-on effects. Graph-based approaches are used to derive knock-on time and linearize it for optimization. Results show the optimized schedule reduces expected passenger time by 2.44% compared to the original planned schedule.
We experimentally study the fundamental problem of computing the volume of a convex polytope given as an intersection of linear inequalities. We implement and evaluate practical randomized algorithms for accurately approximating the polytope’s volume in high dimensions (e.g. one hundred). To carry out this efficiently we experimentally correlate the effect of parameters, such as random walk length and number of sample points, on accuracy andruntime. Moreover, we exploit the problem’s geometry by implementing an iterative rounding procedure, computing partial generations of random points and designing fast polytope boundary oracles. Our publicly available code is significantly faster than exact computation and more accurate than existing approximation methods. We provide volume approximations for the Birkhoff polytopes B11,...,B15, whereas exact methods have only computed that ofB10.
The presentation is an introduction to decision making with approximate Bayesian Methods. It consists of a review of Bayesian Decision Theory and Variational Inference along with a description of Loss Calibrated Variational Inference.
In general dimension, there is no known total polynomial algorithm for either convex hull or vertex enumeration, i.e. an algorithm whose complexity depends polynomially on the input and output sizes. It is thus important to identify problems (and polytope representations) for which total polynomial-time algorithms can be obtained. We offer the first total polynomial-time algorithm for computing the edge-skeleton (including vertex enumeration) of a polytope given by an optimization or separation oracle, where we are also given a superset of its edge directions. We also offer a space-efficient variant of our algorithm by employing reverse search. All complexity bounds refer to the (oracle) Turing machine model. There is a number of polytope classes naturally defined by oracles; for some of them neither vertex nor facet representation is obvious. We consider two main applications, where we obtain (weakly) total polynomial-time algorithms: Signed Minkowski sums of convex polytopes, where polytopes can be subtracted provided the signed sum is a convex polytope, and computation of secondary, resultant, and discriminant polytopes. Further applications include convex combinatorial optimization and convex integer programming, where we offer a new approach, thus removing the complexity's exponential dependence in the dimension.
We experimentally study the fundamental problem of computing the volume of a convex polytope given as an intersection of linear inequalities. We implement and evaluate practical randomized algorithms for accurately approximating the polytope’s volume in high dimensions (e.g. one hundred). To carry out this efficiently we experimentally correlate the effect of parameters, such as random walk length and number of sample points, on accuracy andruntime. Moreover, we exploit the problem’s geometry by implementing an iterative rounding procedure, computing partial generations of random points and designing fast polytope boundary oracles. Our publicly available code is significantly faster than exact computation and more accurate than existing approximation methods. We provide volume approximations for the Birkhoff polytopes B11,...,B15, whereas exact methods have only computed that ofB10.
The presentation is an introduction to decision making with approximate Bayesian Methods. It consists of a review of Bayesian Decision Theory and Variational Inference along with a description of Loss Calibrated Variational Inference.
In general dimension, there is no known total polynomial algorithm for either convex hull or vertex enumeration, i.e. an algorithm whose complexity depends polynomially on the input and output sizes. It is thus important to identify problems (and polytope representations) for which total polynomial-time algorithms can be obtained. We offer the first total polynomial-time algorithm for computing the edge-skeleton (including vertex enumeration) of a polytope given by an optimization or separation oracle, where we are also given a superset of its edge directions. We also offer a space-efficient variant of our algorithm by employing reverse search. All complexity bounds refer to the (oracle) Turing machine model. There is a number of polytope classes naturally defined by oracles; for some of them neither vertex nor facet representation is obvious. We consider two main applications, where we obtain (weakly) total polynomial-time algorithms: Signed Minkowski sums of convex polytopes, where polytopes can be subtracted provided the signed sum is a convex polytope, and computation of secondary, resultant, and discriminant polytopes. Further applications include convex combinatorial optimization and convex integer programming, where we offer a new approach, thus removing the complexity's exponential dependence in the dimension.
talk at Virginia Bioinformatics Institute, December 5, 2013ericupnorth
Extensible domain-specific programming for the sciences
The notion of scientists as programmers begs the question of what sort of programming language would be a good fit. The common answer seems to be both none of them and all of them. Many scientific applications are a combination of general-purpose and domain-specific languages: R for statistical elements, MATLAB for matrix-based computations, Perl-based regular expressions for string matching, C or FORTRAN for high performance parallel computations, and scripting languages such as Python to glue them all together. This clumsy situation demonstrates the need for different domain-specific language features.
Our hypothesis is that programming could be made easier, less error-prone and result in higher-quality code if languages could be easily extended, by the programmer, with the domain-specific features that a programmer or scientists needs for their particular task at hand. This talk demonstrates the meta-language processing tools that support this composition of programmer-selected language features, with several extensions chosen from the previously mentioned list of features.
Simulators play a major role in analyzing multi-modal transportation networks. As their complexity increases, optimization becomes an increasingly challenging task. Current calibration procedures often rely on heuristics, rules of thumb and sometimes on brute-force search. Alternatively, we provide a statistical method which combines a distributed, Gaussian Process Bayesian optimization method with dimensionality reduction techniques and structural improvement. We then demonstrate our framework on the problem of calibrating a multi-modal transportation network of city of Bloomington, Illinois. Our framework is sample efficient and supported by theoretical analysis and an empirical study. We demonstrate on the problem of calibrating a multi-modal transportation network of city of Bloomington, Illinois. Finally, we discuss directions for further research.
talk at Virginia Bioinformatics Institute, December 5, 2013ericupnorth
Extensible domain-specific programming for the sciences
The notion of scientists as programmers begs the question of what sort of programming language would be a good fit. The common answer seems to be both none of them and all of them. Many scientific applications are a combination of general-purpose and domain-specific languages: R for statistical elements, MATLAB for matrix-based computations, Perl-based regular expressions for string matching, C or FORTRAN for high performance parallel computations, and scripting languages such as Python to glue them all together. This clumsy situation demonstrates the need for different domain-specific language features.
Our hypothesis is that programming could be made easier, less error-prone and result in higher-quality code if languages could be easily extended, by the programmer, with the domain-specific features that a programmer or scientists needs for their particular task at hand. This talk demonstrates the meta-language processing tools that support this composition of programmer-selected language features, with several extensions chosen from the previously mentioned list of features.
Simulators play a major role in analyzing multi-modal transportation networks. As their complexity increases, optimization becomes an increasingly challenging task. Current calibration procedures often rely on heuristics, rules of thumb and sometimes on brute-force search. Alternatively, we provide a statistical method which combines a distributed, Gaussian Process Bayesian optimization method with dimensionality reduction techniques and structural improvement. We then demonstrate our framework on the problem of calibrating a multi-modal transportation network of city of Bloomington, Illinois. Our framework is sample efficient and supported by theoretical analysis and an empirical study. We demonstrate on the problem of calibrating a multi-modal transportation network of city of Bloomington, Illinois. Finally, we discuss directions for further research.
Vehicle routing and scheduling Models:
Travelling salesman problem
vehicle routing problem with time window
Pick up and delivery problem with time window
Solving a “Transportation Planning” Problem through the Programming Language “C”Shahadat Hossain Shakil
Solving a “Transportation Planning” problem through the programming language “C”
Presented by
Yousuf Mahid (0615012)
Shahadat Hossain Shakil (0615020)
Khadija Akhter (0615027)
This talk was part of a joint KLM-BigData Republic data science meetup to share results and learnings of a full-cycle data science project on passenger forecasting. I presented the data science part of the project, including how to frame the modeling problem, performance metrics, validation strategy, machine-learning algorithms and challenges from a data science perspective.
Pythran: Static compiler for high performance by Mehdi Amini PyData SV 2014PyData
Pythran is a an ahead of time compiler that turns modules written in a large subset of Python into C++ meta-programs that can be compiled into efficient native modules. It targets mainly compute intensive part of the code, hence it comes as no surprise that it focuses on scientific applications that makes extensive use of Numpy. Under the hood, Pythran inter-procedurally analyses the program and performs high level optimizations and parallel code generation. Parallelism can be found implicitly in Python intrinsics or Numpy operations, or explicitly specified by the programmer using OpenMP directives directly in the Python source code. Either way, the input code remains fully compatible with the Python interpreter. While the idea is similar to Parakeet or Numba, the approach differs significantly: the code generation is not performed at runtime but offline. Pythran generates C++11 heavily templated code that makes use of the NT2 meta-programming library and relies on any standard-compliant compiler to generate the binary code. We propose to walk through some examples and benchmarks, exposing the current state of what Pythran provides as well as the limit of the approach.
1. Timetabling for Passengers: A Knock-On Delay Model
Timetabling for Passengers:
A Knock-On Delay Model
Peter Sels1,2,3
, Thijs Dewilde1
, Dirk Cattrysse1
, Pieter
Vansteenwegen1
1
Katholieke Universiteit Leuven,
Centre for Industrial Management/Traffic & Infrastructure,
Celestijnenlaan 300a, 3001 Heverlee, Belgium
2
Logically Yours BVBA,
Plankenbergstraat 112 bus L7, 2100 Antwerp, Belgium
e-mail: sels.peter@gmail.com, corresponding author
3
Infrabel, Department of Rail Access,
Frankrijkstraat 91, 1070 Brussels, Belgium
December 5, 2013
2. Timetabling for Passengers: A Knock-On Delay Model
Table of Contents
1 Business Problem
Task
2 Solution Process Flows
Stochastic Action Model
Stochastic Goal Function: Expected Passenger Transfer Time
Grouping per Subsequent Action-Pair
Grouping per Subsequent Action-Pair towards Cost
3 Knock-On Time Derivation
4 Knock-On Time Linearisation
5 Results
6 Conclusions & Future Work
7 Questions
3. Timetabling for Passengers: A Knock-On Delay Model
Business Problem
Task
Task
Belgian Infrastructure Management Company: Infrabel:
Add Knock-on Delays as a term to
Expected Passenger Travel Time Goal Function
Goals:
Reduce Expected Passenger Time ⇒ Optimises Robustness
Fixed:
Infrastructure, Train Lines, Halting Pattern, Primary Delay Distributions
Variable:
Timing: Supplement Times at every Ride, Dwell, Transfer Action,
⇒ variable inter-Train Heading Times ⇒ variable Train Orders
Specifics:
One Busy Day, Morning Peak Hour
4. Timetabling for Passengers: A Knock-On Delay Model
Solution Process Flows
Context: FAPESP: Two Phased
FAPESP
zodzo,zd
13. Timetabling for Passengers: A Knock-On Delay Model
Solution Process Flows
Graph for Reflowing: add Source Sink Edges
transferdwellridesource sink
(a)
(a)
(b)
(b)
space increase
time increase
14. Timetabling for Passengers: A Knock-On Delay Model
Solution Process Flows
Graph for Retiming: add Knock-On Edges Cycles
transferdwellride knock-on
(and headway)cycle lin. comb. of cycles
space increase
time increase
train 1
train 2
15. Timetabling for Passengers: A Knock-On Delay Model
Solution Process Flows
Graph for Retiming: All Constraints
dwell
ride
turn around
symmetry
transfer
primary edges secondary edges
knock on
b + m + s = e b + m + s + (d * T) = e
b(egin), m(inimum), s(upplement), e(nd), d(integer), T(period)
constants: m, T
variables: b, s, e, d
symmetry
e = T - b or
e = T/2 - b or
...
cycles
sum_e_in_cycle :
sign_e_in_cycle *
(m_e + s_e + (d_e * T)) = 0
16. Timetabling for Passengers: A Knock-On Delay Model
Solution Process Flows
Reflowing decides on Rectangle Heights
Retime (=Timetabling) decides on Rectangle Widths
(a) Original Schedule
(b) Optimized Version
17. Timetabling for Passengers: A Knock-On Delay Model
Solution Process Flows
Stochastic Action Model
Action: Negative Exponential Delay Distribution
minimum
time:
m_a s_a
stochastic
delay time:
f_aflow:
action
95% 5%
m_r s_r
f_rflow:
ride action
95% 5%
m_d s_d
f_dflow:
dwell action
95% 5%
m_tr s_tr
f_trflow:
transfer action
95% 5%
m_src
f_srcflow:
source action
m_snk
f_snkflow:
sink action
18. Timetabling for Passengers: A Knock-On Delay Model
Solution Process Flows
Stochastic Goal Function: Expected Passenger Transfer Time
Stochastic Goal Function: Expected Passenger Transfer
Time
0 10 20 30 40
0
4
8
12
16
20
24
28
32
36
40
Figure: D0 is introduced supplement, D1 D0 is delta time of next chance
action. Curve maps planned time to expected time.
19. Timetabling for Passengers: A Knock-On Delay Model
Solution Process Flows
Grouping per Subsequent Action-Pair
Grouping per Subsequent Action-Pair
departing = ride’ + dwell’ + source
through = ride + dwell
changing = ride + transfer
arriving = ride + sink
f_source
f_source
s1' s1s2' s2
s1
f_transfer
f_sink
f_dwells1 s2
m1' m2'
20. Timetabling for Passengers: A Knock-On Delay Model
Solution Process Flows
Grouping per Subsequent Action-Pair towards Cost
Grouping per Subsequent Action-Pair towards Cost
f_source
f_source
s1' s1s2' s2
s1
f_transfer
f_sink
f_dwells1 s2
f_changing = f_transfer
f_arriving = f_sink
f_through = f_dwell
f_departing = f_source
flows planned time cost = expected time
m1' m2'
m1' + s1' + m2'+ s2'
m1 + s1 + m2+ s2
m1 + s1 + m2+ s2
m1 + s1
m1' + m2'+ cost(s1'+ s2')
m1 + m2 + cost(s1+ s2)
m1 + cost(s1)
m1 + m2+ cost(s1+ s2)
domain = planning: domain = execution:
21. Timetabling for Passengers: A Knock-On Delay Model
Solution Process Flows
Grouping per Subsequent Action-Pair towards Cost
In-Time and Over-Time
In-Time Over-Time
probability
D0
0
pa(x)dx
D1
D0
pa(x)dx
inc./dec. in D0 inc. dec.
expected time
D0
0
pa(x)D0dx
D1
D0
pa(x)D1dx
inc./dec. in D0 inc. dec.
departing = ride’ + dwell’ + source
through = ride + dwell
changing = ride + transfer
arriving = ride + sink
22. Timetabling for Passengers: A Knock-On Delay Model
Solution Process Flows
Grouping per Subsequent Action-Pair towards Cost
Cost curves of 4 Passenger Categories
(a) departing=ride’+dwell’
+source
(b) through=ride+dwell
(c) changing=ride+transfer (d) arriving=ride+sink
23. Timetabling for Passengers: A Knock-On Delay Model
Knock-On Time Derivation
Primary Delay Distributions
pi (x) = ai e−ai x
, pj (y) = aj e−aj y
, (1)
ci =
∞
0
xai e−ai x
dx =
1
ai
, cj =
∞
0
yaj e−aj y
dy =
1
aj
. (2)
train i: train j:
h=3’
x y
0 Tsj,isi,jsj,i
h=3’
24. Timetabling for Passengers: A Knock-On Delay Model
Knock-On Time Derivation
Knock-On Probability Derivation
Probability of knock-on delay
train i: train j:
h=3’
x y
0 Tsj,isi,jsj,i
h=3’
Integrate over 2 triangle areas where the delay difference
x ≥ y + si,j
y ≥ x + sj,i
as in
px≥y+si,j
(ai , aj , si,j ) =
∞
0
∞
y+si,j
ai e−ai x
· aj e−aj y
dxdy =
aj e−ai si,j
ai +aj
,
py≥x+si,j
(ai , aj , sj,i ) =
∞
0
∞
x+sj,i
ai e−ai x
· aj e−aj y
dydx = ai e−aj sj,i
ai +aj
.
(3)
25. Timetabling for Passengers: A Knock-On Delay Model
Knock-On Time Derivation
Knock-On (Train Passenger) Time Derivation
Train Time Cost of knock-on delay
tKOi,j (ai , aj , si,j ) =
∞
0
∞
y+si,j
ai e−ai x
· aj e−aj y
probabilty
(x − y − si,j )
tkoi,j ≥0
dxdy
=
aj e−ai si,j
ai (ai +aj ) ,
tKOj,i (ai , aj , sj,i ) =
∞
0
∞
x+sj,i
ai e−ai x
· aj e−aj y
probability
(y − x − sj,i )
tkoj,i ≥0
dydx
= ai e−aj sj,i
aj (ai +aj ) .
(4)
Passenger Time Cost of knock-on delay
pKOi,j (ai , aj , si,j ) = fj · tKOi,j = fj ·
aj e−ai si,j
ai (ai +aj ) ,
pKOj,i (ai , aj , sj,i ) = fi · tKOj,i = fi · ai e−aj sj,i
aj (ai +aj ) .
(5)
26. Timetabling for Passengers: A Knock-On Delay Model
Knock-On Time Derivation
Two Train Example: KO Formulas
h + si,j + h + sj,i = T or equivalently sj,i = T − 2h − si,j . (6)
0 = d
dsi,j
pKOi,j + pKOj,i
⇔ 0 = d
dsi,j
fj ·
aj e−ai si,j
ai (ai +aj ) + fi · ai e−aj (T−2h−si,j )
aj (ai +aj )
⇔ 0 = −fj ·
aj e−ai si,j
ai +aj
+ fi · ai e−aj (T−2h−si,j )
ai +aj
⇔ fj · aj e−ai si,j
= fi · ai e−aj (T−2h−si,j )
⇔ ln
fj ·aj
fi ·ai
= −aj (T − 2h − si,j ) + ai (si,j )
⇔ si,j =
aj (T−2h)+ln
fj aj
fi ai
ai +aj
(7)
From symmetry:
sj,i =
ai (T − 2h) + ln fi ai
fj aj
ai + aj
. (8)
27. Timetabling for Passengers: A Knock-On Delay Model
Knock-On Time Derivation
Two Train Example: Supplement Calculation
Two trains with:
train i: expected delay of 1/ai = 3 minutes and fi = 100 passengers
train j: expected delay of 1/aj = 1 minute and fj = 300 passengers
T = 60 minutes, period
h = 3 minutes, headway time
would be spread according to equations (7) and (8)
si,j =
aj (T−2h)+ln
fj aj
fi ai
ai +aj
= 1(60−2·3)+ln(300·1/(100·1/3))
1/3+1 = 42.15 min.
sj,i =
ai (T−2h)+ln
fi ai
fj aj
ai +aj
= 1/3(60−2·3)+ln(100·1/3/(300·1))
1/3+1 = 11.85 min.
and indeed as equation (6) requires 42.15 + 3 + 11.85 + 3 = 60 minutes.
28. Timetabling for Passengers: A Knock-On Delay Model
Knock-On Time Linearisation
All Knock-On Costs for N(N − 1) Trains
on Same Resource: Formula
∀R : pKOR =
i,j∈IR
i=j
fj ·
aj e−ai si,j
ai (ai + aj )
. (9)
Is non-linear in si,j , but since we use convex minimisation ⇒ use trick:
∀R : ∀i,j∈IR
i=j
: pKOR,i,j ≥ fj ·
aj e−ai si,j
ai (ai + aj )
. (10)
0
si,j
T/15 T
=si,j,0
= si,j,1
=si,j,2
koi,j,1
koi,j,0
koi,j,2
29. Timetabling for Passengers: A Knock-On Delay Model
Knock-On Time Linearisation
All Knock-On Costs for N(N − 1) Trains
on Same Resource: Linearisation
0
si,j
T/15 T
=si,j,0
= si,j,1
=si,j,2
koi,j,1
koi,j,0
koi,j,2
∀R : ∀i,j∈IR
i=j
:
(si,j,0, koi,j,0) = (0, fj ·
aj
ai (ai +aj ) )
(si,j,1, koi,j,1) = (T/15, fj ·
aj e−ai T/15
ai (ai +aj ) )
(si,j,2, koi,j,2) = (T, fj ·
aj e−ai T
ai (ai +aj ) ).
(11)
∀R : ∀i,j∈IR
i=j
:
pKOR,i,j ≥ koi,j,0 +
koi,j,1−koi,j,0
si,j,1−si,j,0
· (si,j − si,j,0)
pKOR,i,j ≥ koi,j,1 +
koi,j,2−koi,j,1
si,j,2−si,j,1
· (si,j − si,j,1)
(12)
30. Timetabling for Passengers: A Knock-On Delay Model
Results
Results: Flow * Duration Rectangle Representation
31. Timetabling for Passengers: A Knock-On Delay Model
Results
Planned Time
R.min R R.sup P.min P P.sup
02000060000100000
87.15%
12.85%
Planned
Train Time
reduced by:
4.35%
91.11%
8.89%
Ride(sup) Dwell(sup) Source(sup) Transfer(sup)
Ride(min) Dwell(min) Source(min) Transfer(min)
R.min R R.sup P.min P P.sup
0.0e+005.0e+071.0e+081.5e+08
69.99%
10.40%
0.00%
6.86%
2.94%
2.52%
6.30%
0.98%
Planned
Optimised
Passenger Time
reduced by:
2.44%
71.74%
3.40%0.00%
6.11%
3.01%
9.20%
6.45%
0.08%
Sink(sup)
Sink(min)
32. Timetabling for Passengers: A Knock-On Delay Model
Results
Expected Linear Time, as used in optimisation
R.min R R.sup P.min P P.sup
020000400006000080000120000
86.61%
13.39%
Expected
Lin. Train Time
improved with:
3.88%
90.10%
9.90%
Ride(sup) Dwell(sup) Source(sup) Transfer(sup)
Ride(min) Dwell(min) Source(min) Transfer(min)
R.min R R.sup P.min P P.sup
0.0e+005.0e+071.0e+081.5e+08
67.14%
10.50%
0.00% 0.07%
2.82%
7.92%
6.04%
0.97%0.00%
4.55%
Expected
Lin. Opt. Passenger
improved with:
8.66%
73.51%
4.46%
0.00% 0.11%
3.09%
9.97%
6.61%
0.13%0.00%
2.12%
Sink(sup) KnockOn(sup)
Sink(min) KnockOn(min)
33. Timetabling for Passengers: A Knock-On Delay Model
Results
Expected Non-Linear Time, as used in evaluation
R.min R R.sup P.min P P.sup
020000400006000080000120000
86.59%
13.41%
Expected
Non−Lin. Train Time
improved with:
3.80%
90.01%
9.99%
Ride(sup) Dwell(sup) Source(sup) Transfer(sup)
Ride(min) Dwell(min) Source(min) Transfer(min)
R.min R R.sup P.min P P.sup
0.0e+005.0e+071.0e+081.5e+08
67.36%
10.55%
0.00% 0.23%
2.83%
7.94%
6.06%
0.99%0.00%
4.04%
Expected
Non−Lin. Opt. Passenger
Time improved with:
7.06%
72.48%
4.48%
0.00% 0.44%
3.04%
10.23%
6.52%
0.20%0.00%
2.60%
Sink(sup) KnockOn(sup)
Sink(min) KnockOn(min)
34. Timetabling for Passengers: A Knock-On Delay Model
Results
Expected Linear Time, as used in optimisation
Table: Increasing primary delays, characterised by their average of a% of min.
dwell ride times. Graph size: 203 hourly trains, 5355 ride, 5152 dwell, 17553
major transfer, 31696 knock-on and 166 turn-around edges. Model size: 42609
supplement decision variables, 49415 integer decision variables, 41128 goal
function terms for major flows and 58441 evaluation function terms for all flows.
major major major all all
solver MILP flows flows flows non- flows flows non-
a time gap linearised linearised linearised linearised linearised
ko-time time time time time
reduction reduction reduction reduction reduction
% min. % % % % % %
2 95 76.2 57 8.66 7.06 1.71 0.42
4 43 71.0 52 6.61 4.42 0.84 -1.41
6 75 61.3 63 7.65 5.73 2.07 0.13
8 66 61.3 59 5.83 3.86 0.40 -1.61
2 112 72.6 66 10.58 9.19 2.54 1.31
35. Timetabling for Passengers: A Knock-On Delay Model
Conclusions Future Work
Conclusions
defined and implemented remapping, reflowing, retiming iterations
reflowing: obtains local passenger numbers ∀ trains, ∀ locations
retiming
defined all necessary constraints found
⇒ respects (ride, dwell, transfer, headway)-minimum times
added some our particular cycle set
⇒ solves model fast
defined stochastic passenger time goal function
derived documented
Knock-On delay model for MILP timetable optmisation
⇒ ideal order and headway of trains
⇒ ideal passenger robustness
auto-generated first national timetable with full goal function =
expected passenger time
reduction of passenger time with ±7%, mind current assumptions:
primary delay = 2% of minimum-time, everywhere
zone-to-station-(overly?)-diffused passenger streams
36. Timetabling for Passengers: A Knock-On Delay Model
Conclusions Future Work
Future Work
further verification with new data
measured (place, train)-dependent delays i.o. averaged one
asymmetric station-OD?
add spreading measure for alternative OD-routes and evaluate
effect
allow boundary timing conditions at frontiers/sub-zones
output TPP problems to platformer
guarantee/increase chance on feasibility
add station capacity constraints to retiming
add constraints avoiding simultaneous arrival/departure of train pair
that has to cross in station
adapt platformer so that it optimises for passengers i.o. maximising
# trains platformed
37. Timetabling for Passengers: A Knock-On Delay Model
Questions
Questions
Your Questions?
www.LogicallyYours.com/Research/
sels.peter@gmail.com
My Questions:
Is it best to use primary delays from the old timetable or to just
assume them to be relative to minimum times?
If relative, what is the best (average(?)) percentage to assume for
primary delays w.r.t minimum times?