\chapter{Simulation and Analysis Framework Systems Design}

The previous chapter has outlined a way to decompose and organize an
urban area and the transportation network that serves as its circulatory
system.  This chapter will discuss the design and structure of a
simulation framework suitable for executing and analyzing a model of an
arcology, as well as introducing some of the technical considerations
and design goals of mass transit systems based on this framework.
Finally, the ensuing chapters will discuss the specifics of the mass
transit system model program developed for this project to model and
analyze several types of transit scenarios.

This programming project serves to realize an urban multi-modal transit
simulation designed during the course of the systems engineering master's
program. The program will take a systems approach to modeling human
habitats and the transportation networks that keep them running. We
would use such a simulation framework to create a baseline model of
current day capacity, and then create future models to compare the
effects and quantify the benefits of investments in future infrastructure.
These kinds of tools would be instrumental in making a case for the
development and construction of highly efficient arcologies or other
forms of well-integrated compact cities. But nominally, we could apply
it towards evaluating and tracking the effectiveness of present day
transit oriented growth philosophies.

We again exercise the systems engineering framework described in figure
\ref{fig:system-development1} to organize our efforts in decomposing the
design of our simulation framework.


\section{Simulation Tool Use Cases}
\label{sec:Sim-Tool-Use-Cases}

%
\noindent
\shadowbox{\parbox[t][1\totalheight]{1\columnwidth}{%
\caption{Potential use cases for the simulation model}
\label{tab:simulation-model-use-cases}
\begin{enumerate}
 \item Set up a modeling scenario using input data.
 \item Execution of simulation model to produce output data.  The
       ability to perform multiple scenario simulations in parallel
       would greatly increase our data analysis throughput.
 \item Postprocessing and analysis of output data into performance
       metrics.
 \item Design of experiments methodology for exploration, optimization,
       and parametric analysis of the solution space.
\end{enumerate}

}}%


We'd want to be able to build up scenarios in two ways, from
constructing a collection of entities in a bottom-up manner, and by
breaking down aggregate data sources into a distribution of entities in
a top-down manner.  This would allow us to compare scenarios assembled
from data gathered from a sampling of individual detailed sources, and
from scenarios initialized using totals gathered at a higher level of
detail.  For example, we might know the number and type of cars
registered in a city, their fuel efficiency, and the estimated distance
they travel daily.  From this we could assemble a simulation that gives
us their average fuel consumption.  Conversely, we might take a survey
of all of the gas stations and know exactly how much fuel was pumped
into a number of vehicles in the city, and from that deduce the distance
each of them drive.  By comparing similar scenarios constructed from
different data sources, we might check our models for consistency as
well as calibrate it under a variety of existing sources of data.
	 
\begin{enumerate}
 \item{\bf Bottom-up scenario:} Since the arcology is designed from the
      ground-up, starting at the individual level, the structure of our
      model would allows us to calculate the aggregate performance at
      higher levels of organization, such as a the city and national
      level.
       
       \begin{itemize}
	\item Define number of simulation units, connectivity between
	      units, schedule of transaction events, schedule of
	      reaction events, initial conditions.
	      
	\item Output aggregate performance for groups of units.
       \end{itemize}
       
 \item{\bf Top-down scenario:} The present day scenario is built in a
      top-down fashion from various data sources. Statistics are only
      tracked from relatively high levels on the organizational
      hierarchy, so we must extrapolate some data to flow down to fill
      the detailed subcells of the structure.
       
       \begin{itemize}
	\item Define high-level consumption rates for groups (using
	      publicly tracked and available data), provide distribution
	      histograms for each type of resource and transaction rates
	      for each subunit.
	      
	\item Output unit-level quality of life, performance.
       \end{itemize}
\end{enumerate}
	 
What potential uses could this transportation network simulation have?
One of the main types of problems it shall address is passenger demand
generation.  Different types of transportation infrastructures could be
evaluated against each other to determine how well they meet that
demand. Many existing transportation problems tackle ways to increase
throughput or capacity. But the task of urban planning should also focus
on arranging its physical layout to economize demand loads in addition
to building out transit infrastructure for maximum capacity. For
example, instituting staggered work hours or telecommuting programs can
relieve peak rush hour traffic congestion without spending a fortune
widening highways or building additional transit lines just to increase
throughput for a few hours of peak usage a week. Local governments
should know how much incentive they ought to offer to businesses to
encourage them to implement flexible work hours.  Similarly, they'd want
to know how much to invest in telecommuting infrastructure (such as
municipal broadband) in order to provide productivity benefits similar
to simply adding highway lanes or additional thoroughfares.

By simulating demand, we can also create a transportation system that is
more sensitive to the needs of individual travelers rather than the
aggregate flow of passengers. This would allow us to create schedules
around the traveler's itinerary rather than forcing the traveler to
always plan around fixed train, bus, ferry, and aircraft timetables.  By
only tracking passenger flow through fixed schedules, we throw away
some valuable data on when the passenger really wants to depart or
arrive, which is a significant factor when comparing mass transit to
personal vehicle use. For instance, if everyone starts work exactly at
8:30, but buses only run hourly on the hour to that particular stop,
then the extra half hour everyone spends waiting per day essentially
counts as extra commuting time in their books. The system operators
might think they're doing quite well by only measuring the time
passenger spend sitting on the bus and making connections, but the
passengers would perceive much higher inconvenience and time costs.

A more effective public transportation system should succeed in making
the world ``smaller'' by making each district of a municipal area more
readily accessible, allowing people to travel between places where they
live, work, run errands, and seek entertainment. Under the trunk and
feeder paradigm often used to organize mass transit in metropolitan
areas today, travel through the system can take considerable time unless
your source and destinations happen to be near major hubs or just down
the street from each other on an established route. The worst case
scenario for many trips off of a main trunk line would consist of
catching a local feeder bus route to the nearest trunkline light rail
station, making a transfer at a major hub or two, and finally catching
another feeder route to your ultimate destination. Each transfer would
typically consist of at least 5-20 minutes of waiting for the next
connection.  Compared to driving your independently owned vehicle,
public transit would often take two to four times longer, even with
traffic. Commuters would travel twice per day, so the time savings of
taking a personally-owned vehicle could add up to an additional 1-2
hours of personal or family time at home each day. Public transportation
systems could use much improvement to make mass transit preferable to
driving, but often it becomes an alternative to escape congestion on the
roadways rather than the primary mode of travel. Drivers typically
support investment in public transportation only insofar as it gets
other cars off the road.

An advanced busing system (such as the HCPPT system proposed by
Cort$\acute{e}$s \cite{HCPPT}) would dynamically generate routes and
schedules based on individual source and destination requests from each
passenger, and thereby achieve efficiencies and meet customer
requirements far better than current fixed schedule transit fleets. This
could make public transportation much more attractive to people who
drive their own vehicles everywhere in order to maintain that degree of
flexibility. During peak commuting hours, intelligent scheduling has the
potential to reduce individual commute times, as most buses could be
scheduled more like express routes, filling up at one location and
proceeding directly to stops at a common destination with minimal stops
or transfers or jaunts down back roads along the way. During off-peak
hours, buses would not run nearly empty along the exact same routes at a
drastically reduced frequency, but would run only on demand, cutting
down unnecessary wait times and making them more convenient for midday
or late night errands.  All we'd need to implement an intelligent,
dynamically reroutable transit system is a robust communications network
with a simplified interface to provide route updates to vehicles and
transfer instructions to passengers.


\subsection{Performance Metrics}
\label{sub:Performance-Metrics} 

What defines a good inter-modal transit system? The conflicting goals
might be characterized as: speed, latency, coverage, and efficiency.

\begin{itemize}
 \item{\bf ``Speed''} refers to how fast the transit system can get a
      passenger or cargo item from point A to point B. Unfortunately,
      this does not depend entirely on the cruise speed of the vehicle
      alone, but also time spent making transfers and additional
      preparations (such as passenger check-in and luggage screening at
      airports)
 \item{\bf ``Latency''} refers to additional waiting time between when a
      passenger wants to go somewhere and when the transit system can
      actually take them.  It is affected primarily by the frequency of
      service, particularly how well it matches demand. Extra time that
      people have to wait at their source or destination should be
      counted against the system --- though this is often overlooked in
      transit performance metrics today. The data just isn't available,
      or people have relegated themselves to adjust their schedules
      around the system's timetables. This ``latency'' metric will
      usually be at odds with efficiency due to economies of scale,
      since making passengers wait longer times between pickups can
      cluster them into larger groups.
 \item{\bf ``Coverage''} refers to how well the transit system covers the
      service area, which should include how far people have to walk from
      their doorstop to enter the system. Broad coverage is more
      difficult to achieve for a mass transit system, especially as
      population density decreases and residences and businesses become
      more spread apart.
 \item{\bf ``Efficiency''} might refer to two terms: monetary frugality
      on fixed infrastructure and operating costs, as well as in terms of
      conservation of fuel and resource utilization. Efficiency pretty
      much always counterbalances against each of the three other goals,
      so we often must express how much extra money or fuel we are
      willing to expend to achieve gains in speed, latency, or coverage.
\end{itemize}


\subsection{Transit Schedule Optimization}
\label{sub:Transit-Schedule-Optimization}

To achieve reasonable improvements in these multiple competing
performance goals, we must employ some manner of vehicle fleet
optimization in order to investigate the full potential performance of a
transit platform.  An intelligent transit system would take advantage of
existing and emerging ubiquitous computing and communications networks
to make itself more responsive to customer requests and to deliver
passengers in a more coordinated manner.  While fixed route schedules
might work well for normal demand based on projections, the true
performance of a transit system should take into account all available
emerging information.  This could include advance knowledge of special
events that create spikes in demand to certain stations, or even
unforeseen events such as breakdowns that close transit lines and
trigger a failure mode of operation with an altered schedule.

An optimization problem formulation should dynamically take in data
about the arrangement of stations, passenger requests for transit
between available stations, and properties describing the vehicle fleet
and constraints pertaining to their movements between stations, and
provide an optimized plan for delivering passengers to their
destinations.  This would allow us to identify and focus on the
performance impacts of physical design parameters independently of the
often arbitrary fixed scheduling methods.  The optimized schedule could
be calculated in near real time, incorporating updates from the evolving
system state in a rolling-horizon fashion. It would incrementally
compute the next series of interchanges and transfers in the future, at
first working on projected demand data augmented with more solid data
collected from vehicle and station sensors.

Once we identify transit scheduling paradigms that perform well, we
might simplify the network somewhat by establishing some fixed
strategies, patterns, or even routes.  However, we see no reason why a
fully dynamically-reoptimized transit system couldn't guide its
passengers through a constantly updating and changing network or
vehicles through the use of mobile phone text messages or a dedicated
digital guide.


\subsection{Coordination of Dynamic Optimal Schedules}
\label{sub:Coordination-of-Dynamic-Optimal-Schedules} 

The main way we'll be able to improve the efficiency of mass transit
(aside from simply improving fuel economy) would be to use existing
resources more effectively through extensive use of optimization. With
enough planning and foresight, optimal scheduling is straightforward to
perform. However, things never quite go as planned, due to a variety of
unpredictable factors such as weather and accidents and just plain
last-minute changes in schedules. In order for the optimal plan to be of
much use, we ought to continually collect enough data in real-time to
monitor and reevaluate schedules as able. This requires that we have a
communications system in place that allows us to poll the status of our
cargo, passengers, and transportation vehicles. Equipage for this type
of system would have been cost prohibitive in the not-too-distant past,
but now that geolocation devices, mobile computing, wireless
networking, and cellular data network backbones have become nearly
ubiquitous, we'd be silly not to put all this capability to good use.

So instead of having fixed timetables locked down and fixed weeks,
months, or even years in advance, based only on projections from
previous observation of seasonal flows in the past, we could
perform schedule optimization on actual data.  This data would factor in
individual requests from each customer, including their destination and
schedule constraints (or better yet, their schedule \emph{flexibility}).
Vehicles could report their current location and status, meaning they'll
always be right on time - especially since they could report their
arrival time themselves.  Monitoring and reporting of deteriorating road
or weather conditions could automatically update the schedules of every
vehicle in the network to account for and mitigate the effects of new
delays.




\subsection{Comparison Framework for Multiple Urban System Models}
\label{sub:Multiple-Model-comparison}

We have now specified an urban model that would generate demand on a
transit network, a system simulation engine, and a schedule optimization
algorithm that could direct the action.  What next?  We can set up an
iterative optimization of system design, analyzing the design parameters
for each particular simulation scenario. This will help us evaluate
urban design and infrastructure in ways that should help drive progress
towards efficient and sustainable societies that serve the people who
live in them.  We could propose a new construction or infrastructure
project, show its benefits in this kind of a simulated model, and later
validate those benefits using data collected from the real
system. Competing developers might even submit simulations of their
designs to provide benchmarks using this analysis platform.

The ability to compare several optimization components, several system
structures, different modeling methodologies, all using the same data
interchange format to facilitate direct comparisons between both real
and simulated evolution of the scenarios, allows us to take a systematic,
objective approach to tackling urban improvement projects. Adapting
such a simulated and real system performance comparison framework
will allow us to have more complete impact assessments by making sure
every study or proposal is analyzed consistently, using the same inputs,
and doesn't sweep away or ignore unwanted side effects and consequences.
Urban planners could use these studies to provide ammunition for driving
changes toward the way they envision their communities. An intensified
focus on operational efficiency and continuous improvement driven
by pervasive measurement and analysis will lead towards a leaner,
sustainable society where we could direct a higher ratio of resources
towards forward progress instead of mere subsistence.


\subsection{Transit Simulation Requirements}
\label{sub:Transit-Simulation-Requirements}

With that, we proceed to develop the outline for what our simulation
must accomplish:

%
\noindent
\shadowbox{\parbox[t][1\totalheight]{1\columnwidth}{%
\begin{enumerate}
\item Read scenarios as inputs

\begin{enumerate}
\item[1.1.] Hierarchical layout of transit stations and connectivity
\item[1.2.] Initialize simulation entities involved (people, vehicles,
	    residences, and workspaces, \emph{etc.})
\item[1.3.] Load demand schedules for passenger movement
\end{enumerate}

\item Simulation execution to evolve state of system entities

\item Output metrics defined and calculated

\begin{enumerate}
\item[3.1.] Passenger measures of performance
\item[3.2.] Vehicle measures of performance
\end{enumerate}
\end{enumerate}
%
}}% 


\section{Implementation of Simulation System Structure}


We used the Umbrello UML tool to create diagrams in this and subsequent
chapters\cite{umbrello}. While its code generation capabilities are not
as comprehensive as that of the commercial tools such as I-Logix
Rhapsody, it can generate class stubs for several languages including
Python objects (which is used for the simulation), and XML Schema (which
might be used eventually to help validate data interchange).


\subsection{Discrete Event Simulation Framework}

% FIXME: add summaries \& graphs artifact, Post Processing component
\begin{figure}[htp]
\epsfxsize=6.0truein
\centerline{\epsfbox{figures/Components.eps}}
\caption{Simulation Framework Component Data Dependencies}
\label{fig:Simulation-Components}
\end{figure}

The prototype framework depicted in figure
\ref{fig:Simulation-Components} consists of three major parts. The
simulation code written in Python makes heavy use of the SimPy module,
\cite{simpy} while the solution of the schedule optimization problem
occurs using the LP-solve mixed integer linear program
solver. \cite{lpsolve} These components are wrapped around a scenario
generation and post-processing framework that creates a directory tree
of scenarios, each with slightly different initial conditions for
factorial analysis.

The schedule optimizer formulation was first prototyped in Perl before
being ported to Python.  While Python typically has a much better
reputation than Perl in terms of code readability, Perl's in-line
variable output syntax made its code terse and much easier to read and
debug than the equivalent Python code.

Being the ``brains'' of this framework, the more complicated
optimization problem imposes a few major constraints that help simplify
the way we'd model our transit network. The transit system must consist
of a network of ``station'' nodes representing the entry, exit, and
transfer points for passengers and cargo. Passengers and cargo can only
move between nodes on vehicles, which can transfer them between any two
connected stations or waypoints at regular, synchronized intervals.  The
simulation can handle several vehicle types, which can differ in
passenger capacity per vehicle, cost per transit segment, connectivity
graph between nodes, the maximum number of vehicles allowed to visit a
station at the same time, and a host of other measures and constraints.

The most crippling part of the model deals with timing. Time is dealt
with in terms of synchronized discrete timesteps, during which the state
of the entire system can be represented at one point in time by a
complete set of variables. At each time step, the state of the system
must be such that every vehicle is located at a station or waypoint
node. By the next time step, all passenger transfers must have been made
and all vehicles must have completed their transit toward the next
station node (or else stayed in place at their current station). When
the simulation translates these actions to events in continuous time,
this means that all stations synchronously act in unison, where every
vehicle practically departs simultaneously, travel all at the same time,
and offload passengers at their destinations, and wait for passengers to
transfer to make connections. They all must act in rhythm to the beat of
a central drummer.  While this obviously constrains the flexibility of
the model in a big way, this arrangement allows the schedule optimizer
the flexibility it needs to balance hub-and-spoke transfers with more
direct routes, depending on the capacity and economics of the vehicles
made available.

Therefore, the model used in this analysis is that of equal-time
segments separating transit stations and waypoints.  Each and every
vehicle must wait for passenger transfers to complete before they
continue on to their next destination. The result is that, in reality,
some amount of time is bound to be wasted under this model as all
vehicles must stop and wait for the next beat of the synchronization
drum before proceeding.  A vehicle that is running a little bit late
might have to skip a beat completely.



\section{Simulation System Behavior}

The Scenario Generator runs first and generates a directory hierarchy of
scenario data and a makefile that allows us to run simulations in
parallel and only on scenario data that has not yet been computed.  This
allows us to add data points to large data sets without having to spend
a lot of time recomputing existing results.

Snapshots of the simulation state occur regularly and trigger the
creation of new optimization formulation files, which might be solved by
Python's LP-Solve module several times throughout the evolution of the
simulation.  The optimization returns an object with a list of schedule
results referenced by entities in the simulation to determine their
actions.

After the runs are complete, the yEd graph viewer can neatly organize
and display state snapshots of the transit entities in its pseudo-UML
object view. \cite{yed}  These visualizations of the simulation's graphML
state dumps greatly assisted development and debugging.  An example is
depicted by figure. \ref{fig:yEd-sample} %FIXME: add this example figure

Finally, a post processing script assembles the raw output of SimPy
data monitor taps into histograms for collective display on a summary
web page for comparison.  It also condenses a spreadsheet of input
parameters and output metrics for each scenario to allow further data
reduction as described in section
\ref{sub:Design-of-Experiments}.

The program uses the Psyco and SciPy modules to greatly increase the
execution speed of most operations.  Simply including the Psyco
optimizer replaces certain commonly-used interpreted Python routines
with optimized native code that gives the overall model a 1-2 order of
magnitude increase in computation speed. \cite{psyco} The SciPy library
additionally gives us a high performance numerical library for
performing calculations and efficiently manipulating large
matrices. \cite{scipy}


\subsection{Statistical Scenario Comparison}
\label{sub:Statistical-Scenario-Comparison}

The simulation uses some pseudo-random distributions to initialize
demand curves. In order for our simulation runs to maintain repeatability,
each of the scenarios include an initial random seed. A simulation
run with the same seed will always generate the same random variables.
Conversely, we can also vary the initial random seed across several
runs of the same scenario in order to do Monte Carlo type simulations
that gives us a proper distribution of output metrics as well.

The use of randomized initial distributions has another useful feature,
in that it prevents the optimization problem from becoming too symmetric.
Too much symmetry would result in multiple equal-cost branches to
search exhaustively. So adding a touch of entropy to the our system
allows our MIP solver to converge on a better solution slightly faster.



\subsection{Computational Considerations}
\label{sub:Computational-Considerations}

Large scale global optimization can require a lot of computing power. It
falls under the class of NP-hard problems that scale exponentially with
the number of transit nodes we add to the transportation system. Let's
look at some of the ways in which problems of this size can be tackled.

The simulation is set up to run in parallel across several CPUs,
scalable to a massive clustered system with a shared filesystem. Some
linear and mixed integer solvers also have the capability to partition
and solve individual optimization problems in parallel.  LP-Solve is not
one of them, but it does have the ability to export its model into other
optimization problem formulation language formats such as CPLEX or the
industry standard MPS, so we need not worry about supporting
parallelization.

We still would need to resort to a host of other tricks to reduce
the computational complexity enough to approach problems of any
appreciable size. Most of them involve introducing some sort of constraint
to reduce the number of branch and bound paths search in the solution
space.  But primarily we resort to LP-Solve options that allow us to
accept suboptimal but feasible solutions.

\begin{itemize}
 \item The easiest way to reduce the computational complexity is to
       partition the problem into smaller parts. Since these types of
       ``traveling salesman'' problems scale exponentially with respect
       to the number of nodes, the number of branches to search would be
       drastically reduced by replacing an exponential term with a
       linear one.
 \item Adding link constraints is also another way of reducing the
       search space. Not every node needs to be linked to every other
       node. So often we will resort to building a connectivity matrix
       to define which source nodes can get to which destination
       nodes. With road and rail, only adjacent nodes are directly
       connected. Distant nodes would require transit through other city
       or station ``nodes''
 \item With aircraft, of course, most vehicles can travel directly from
       any node to just about any other node in the network. In this
       case, it may be helpful to add ``max passenger transfer''
       constraints, to keep the system for searching through
       impractically long schedules. An itinerary that made a passenger
       jump between more than two or three connecting airports would
       likely be rejected by that person. On the other hand, low
       priority bulk cargo may find some cost advantage through waiting
       for these multiple connections, filling in otherwise ``empty''
       space leftover on flights that could get closer to its
       destination. But at some point all of the extra handling and
       transfer overhead ought to outweigh the cost saved.
 \item Any constraint that would help ``lock down'' otherwise free
       variables would help reduce the search space. Feeding in initial
       conditions - like the current locations of the vehicles in the
       fleet, or stops that must be made by a certain time (for example,
       to ensure buses take all passengers to a stadium well before a
       game starts) may help speed the optimization solution search
       along.
 \item Sometimes it may be necessary to simply add other heuristic or
       even arbitrary constraints to help the system converge on a
       solution. By design, many of these constraints might not even
       affect the final solution, but constrain the search space enough
       to deliver an answer more quickly.
\end{itemize}

All else failing, many mixed-integer programming solvers, including
LP-solve, can return ``good enough'' solutions without completing an
exhaustive search of the solution space. Modern MIP solvers can also be
pretty clever about searching the ``most promising'' paths close to the
relaxed linear solution first.  Completing the exhaustive search often
yields little incremental improvement over the best previously
discovered feasible objective. Of course, this technique applies only if
a feasible integer solution can be found in reasonable time at all.

LP-Solve has a host of options that can allow it to return suboptimal
solutions before completing an exhaustive branch-and-bound search of the
solution space.  It can simply provide the first MIP solution it finds
after locating the relaxed linear solution using its simplex solver.  We
can also converge upon solutions faster by increasing its MIP gap
tolerance, which is the relative improvement between suboptimal
solutions it finds along its way.  This effectively reduces the
``depth'' of its branch-and-bound search.  Finally, it also offers a
wall clock timeout that stops an optimization from running virtually
forever and returns the current best suboptimal solution.

Finally, a sophisticated optimization could involve pre-computing most
of the possible schedules in advance, and then have the ability to
account for the effects of small changes with only minimal recalculation
of the final optimal solution. This type of incremental adjustment may
be necessary to recover from small, unexpected schedule breakdowns.
Suppose a vehicle suddenly announces that it will be arriving 30 minutes
late to a hub node. If recomputing the entire optimal solution taking
this new information into account would take a few hours of number
crunching, we obviously don't want everything to grind to a halt while
waiting for the scheduler to tell us what to do next. An ``incremental
update'' to the solution performed with minimal recalculation might be
achieved by determining which vast majority of system variables
shouldn't be affected, and formulate a highly-constrained optimization
problem that only searches through a small set of variables affected by
the unexpected change in one or two schedule input values. We'd need to
develop a heuristic to determine exactly how far out this limited set of
``affected variables'' should reach.

Another similar scheme might involve jumping back into a computational
snapshot of the state of the large optimization and only recalculate
internal values that have changed with the modified inputs. Perhaps some
solvers have this ability.



\section{Model Validation Against an Actual System}

Ultimately we would want to calibrate our simulation against an actual
transit system modeled by it. Due to the discrete timestep nature of our
schedule optimization model, the simulation would only be capable of
providing an approximation of a live system's performance. However, if
the live system uses the same schedule optimization algorithm used in
our simulation, we wouldn't expect simulated versus live performance to
differ appreciably unless vehicles run late and passengers miss
connections. The simulation currently does not model these types of
unexpected events, but adding such probabilistic failures to the
simulation shouldn't pose much of a challenge.  The challenge lies in
calibrating those probabilities against those that might occur in the
live system due to factors discussed in section
\ref{sub:Multiple-Schedule-Optimization}.


% LocalWords:  subcells Postprocessing trunkline MIP geo CDF truein Umbrello LP
% LocalWords:  infeasibility UML Logix XML SimPy timesteps waypoint en yEd MPS
% LocalWords:  Psyco SciPy filesystem CPLEX pre timestep sim arcologies graphML
% LocalWords:  doorstop reoptimized HCPPT Cort reroutable geolocation FIXME
