% This file was converted from HTML to LaTeX with
% Tomasz Wegrzanowski's <maniek@beer.com> gnuhtml2latex program
% Version : 0.1
\documentstyle{article}
\begin{document}

\par {\bf Arcology
Systems Simulation}
\par {\bf Rowin
Andruscavage}
\par \underline{http://hairball.bumba.net/\verb|~|rwa2/school/ense799/Arcology.html}
\par University of Maryland 

\par ENSE799 Fall 2005
\par Dr. Mark Austin
\subsubsection*{Abstract:}
\par An arcology is a
combination of architecture with ecology, essentially forming an
environmentally friendly human living system well suited to systems
engineering analysis.  This document defines and describes a network
queuing simulation model that might be used to perform trade study
analysis on such a system.  The model attempts to structurally
decompose the human habitat into groups of subsystems on all scale
levels that interact through the exchange of resource groups.  The
resulting resource flows are quantified into performance metrics used
to compare different types of arcologies to current living
conditions.  Bottom-up scenarios of arcology models will be compared
to top-down scenarios constructed based on present day statistical
data.  Tradeoff studies focus on feasibility of coverage based on
differing transportation network topologies.  Finally, this document
outlines a verification and validation plan for models created using
the simulation engine.
\par \\

\section*{Table of
Contents}
\par \\


	\par {\bf Arcology
	Systems	1}
	\par Abstract:	1
	\par {\bf Table
	of Contents	2}
	\par {\bf System
	Description	4}
	\par {\bf System
	Model	6}
	\par {\bf Concept
	Requirements	6}
	\par Goals	6
	\par Objectives	8
	\par Use Case
	Diagrams	8
	\par {\bf System
	Structure	11}
	\par GeneralClasses
	Object Model Diagram	12
	\par Cell 	12
	\par LeafCell 	13
	\par CellHierarchy 	13
	\par Environment 	17
	\par TransportationInfrastructure
		18
	\par Transportation	18
	\par Reactions 	20
	\par Resources 	22
	\par {\bf System
	Behavior	25}
	\par Events: 	25
	\par Individual	26
	\par ResourceEngine
		28
	\par ReactionEngine
		29
	\par InputResources
		31
	\par OutputResources
		32
	\par Combustion 	32
	\par Refining 	34
	\par {\bf System
	Requirements Allocation	34}
	\par {\bf Requirements	34}
	\par Arcology
	Primitive Requirements	35
	\par Arcology Derived
	Requirements	35
	\par Simulation
	Requirements	35
	\par {\bf Requirements
	Traceability	36}
	\par Primary Energy
	Consumption by Fuel	36
	\par {\bf Specifications	37}
	\par Specs for
	Arcology Primitive Requirements	37
	\par Specs for
	Arcology Derived Requirements	38
	\par Specs for
	Simulation	38
	\par {\bf Tradeoff
	Analysis	38}
	\par {\bf Design /
	Decision Variables	39}
	\par System Wide
	Measures of Effectiveness	39
	\par Transportation
	System Preliminary Design Input Parameters	40
	\par Transportation
	System Measures of Effectiveness for Tradeoff Analysis	40
	\par {\bf Optimization
	Problem Formulation	41}
	\par {\bf Pareto Optimal
	Solution Space	41}
	\par {\bf Verification
	Test Plans	43}
	\par {\bf Simulation
	Requirements Verification	44}
	\par {\bf Simulation
	Specification Verification	49}
	\par {\bf Validation
	Evaluation Plans	49}
	\par {\bf Macro Level
	Validation Scenarios	50}
	\par {\bf Micro Level
	Validation Scenarios	51}
	\par {\bf Bibliography
	\& References	51}
	\par {\bf Appendix	52}
	\par {\bf Schedgen.pl
	Source Listing	52}
	\par {\bf Example Mixed
	Integer Programming Model	61}

\par 
\\

\section*{System
Description}
\par The concept of the
arcology was first introduced in the 1950s by architect Paolo Soleri
as the ultimate urban planning solution to the problems of
metropolitan growth. Continuing trends in the expansion of
metropolitan areas have contributed to explosive growth of low
density suburban sprawl, the decay of inner city urban areas, and
finally the indiscriminate destruction of natural environments to
make room for a human habitat system which is increasingly less
efficient, convenient, and aesthetic. The concept of the arcology
attempts to reverse those trends by providing a compact city
infrastructure that works. 

\par \\

\par What is an arcology?
Featured in several science fiction works as the city of the future,
an arcology is more than just a structure... a \verb|"|superbuilding\verb|"|
that contains everything you would expect to see in a current city.
The arcology integrates living spaces and working spaces with
transportation systems that connect it all. One of the fundamental
differences is that it heavily involves the third dimension into city
planning, whereas current planning is done by zoning commercial /
residential / industrial in an ad hoc fashion (well, by government
committee through series of votes, demonstrations, bribes, and legal
means applied in a reactive manner which fulfills actual requirements
just as well as ad hoc design process). Naturally, the arcology is
simply what a city would be if it was to be designed by competent
systems engineers (of course, a feat easier said than done). 

\par \\

\par Another advantage to
designing cities from the perspective of an arcology is that it
forces you to take all scale levels into account in the design. This
allows the arcology to transition better as new technologies are put
into place. 

\par \\

\par On the national level,
arcologies would be constructed to connect well to other arcologies,
with effective transportation and distribution systems. Current
cities have transportation problems. Many cities grew around ports.
However, shipping is no longer the primary means for distributing
goods. The United States has invested heavily in the highway system.
However, around many cities these get tied up in rush hour
congestion, resulting in delays and waste. Airports are usually built
too far from the city to connect well to mass transit systems, or
have been enveloped (and throttled) by the city and create a nuisance
to nearby residents. 

\par \\

\par On the personal level,
much infrastructure for living does not have flexibility for change.
We are still using much of the same infrastructure developed over a
century ago for power and telephone. Additional systems have sprouted
up on top of these networks, such as cable television and various
wireless networks that compete for spectrum, and a myriad of PBX,
fiber optics, etc. for corporations. Various combinations of water
mains, sewage systems, natural gas pipelines. A modular arcology
structure would need to be able to adapt to support new networks. 

\par \\

\par The purpose of an
arcology is to create a compact, organized structure for people to
live and work. It should be designed to improve and maximize upon the
quality of life of its residents, while also performing well
economically, in production, and in development. The transportation
system is one of the keys to making the system perform. This
connective tissue accounts for how well most of the rest of the
system can perform. 

\par \\

\par Paolo Soleri describes
several arcology designs that could be used to replace major cities
or serve well in several environmental settings.  This project would
create a tool that could be used to quantitatively analyze the
benefits of replacing cities with arcologies.  This report describes
the systems engineering of a tool to perform systems engineering
preliminary design \& benefits analysis.
\par \\

\par Previous
well-known works that tackle this task includes two open-ended games
from Maxis (now part of Electronic Arts) that approach the problem
from two different scales:  {\it SimCity} and {\it The Sims}. 
Beyond that, there is not much published in the way of city and
lifestyle simulation.  This is probably partly because most of this
analysis can be done more simply using historical data tracked by
government statistical agencies, and because most of the simulation
writers are more busy simulating more interesting things such as data
and transportation networks.  Not many people are in a position to
design cities, however, almost everyone needs to work within the
infrastructure of one, so it would be worthwhile to create a model if
only to serve as a dynamic demand generator used to plug input
parameters into these data and transportation networks.  Surely they
can use historical data as inputs, but this breaks down when a system
they are designing may have a significant effect on the input data.
\par \\

\par One item of study that
this type of simulation makes feasible is the relationship between
these data networks and transportation networks.  For example, if a
city decides to spend money upgrading their data infrastructure so
more people might be able to telecommute to work, this may have a
noticeable impact on the load on their mass transit system.  This
simulation could aid as a decision-making support tool that could
actually tie the network and transportation models together.
\par \\

\par Insets:
Concept art of arcologies in SimCity 3000
\par Below:
Arcologies from SimCity 2000
\par 
\par \\

\par The approach for this
project involved using Ilogix Rhapsody� in C++ Development
Edition to construct UML diagrams of the system.  Work proceeds under
the expectation that the code generation facilities of Rhapsody could
be used to embed C++ source code in the framework to compile and run
a working executable as part of the Systems Modeling and Analysis
course in the future.  As an added benefit, Rhapsody also provides
documentation generation of the model in rich text format.  This
project documentation is interspersed into this report with
appropriate commentary and then exported to html.
\par \\

\par One of the side effects
of using Rhapsody include some subtle differences in naming
conventions, presumably used to simplify the merging of the standard
OMG UML specification with the practical realities of software
engineering frameworks.  Notably, Rhapsody uses \verb|"|Object Model
Diagrams\verb|"| in place of both \verb|"|Class Diagrams\verb|"| and
\verb|"|Instance Diagrams\verb|"|.  Since this project deals with
abstract models, we will almost always be referring to class diagrams
except when dealing with actual scenarios.
\section*{System Model}
\subsection*{Concept Requirements}
\subsubsection*{Goals}
\par One of the
characteristics of systems such as cities that grew by evolution
rather than by design is that they lack fundamental policies that
drive their design.  Components of the city usually come about in a
reactionary manner: fire protection services are built after too many
buildings burn down, airports are built to serve cities after they
have already grown too dense to accommodate one in a central
location, tap water distribution systems are gutted out and replaced
only after the old ones were too heavily loaded to be sanitary.
\par \\

\par Hindsight being 20/20,
it is worthwhile to dwell on past mistakes and develop urban planning
with a systems engineering process worthy of supporting a
megalopolis.  The first step is to develop a set of goals and
objectives that drive the design of the city.  At first glance, the
goal of a city (at least as envisioned in {\it SimCity}) ought to be
to grow and prosper.  However, this overlooks the city's
primary responsibility to fulfill the needs and look after the well
being of its inhabitants.  For that, we can look at it from an
individual level on par with the scale of {\it The Sims}:
\par \\

\par 

\par {\bf Figure 1: The Sims
Entity Requirements Model}
\par {\it The Sims} offers
8 needs for each of their simulated characters: Hunger, Energy,
Comfort, Fun, Hygiene, Social, Bladder, and Room
\par This model takes an
even simpler approach:
\begin{itemize}
	\item \par Shelter --
	where people live and sleep  (accounts for Energy, Comfort, and
	Room)
	\item \par Food / Air / Water
	-- the raw materials people need to consume to live, or at
	least not starve to death  (accounts for Hunger)
	\item \par Health --
	maintenance factors, such as cleanliness, waste, (accounts for
	Hygiene and Bladder)
	\item \par Work -- most
	people need something productive to do when they aren't
	attending to their other needs.  This could take the form of working
	for money, or being educated to increase their knowledge bank of
	information.
	\item \par Entertainment --
	if people aren't doing something productive, they're
	probably doing something fun to while away their time (accounts for
	Fun and Social)
\end{itemize}
\par In order to fulfill
these needs for all of the city's inhabitants efficiently, what
they are really looking at is developing infrastructure to move
resources around so that each of these needs can be catered to.  This
simulation model takes on abstract views of these resources and the
transportation networks that move them around.  

\subsubsection*{Objectives}
\par So what should our
objectives be, if we are to meet our goals, how can we form an
objective function for optimization?  Of course, we're talking
about multivariate optimization of multiple goals.
\begin{itemize}
	\item \par Continually
	improve the quality of life for inhabitants
	\item \par Accelerate
	development of improvements to the body of knowledge
	\item \par Maximize
	productivity, performance.
	\item \par Optimize resource
	consumption to achieve balance with the environment.
	\item \par Avoid optimizing
	the whole at the expense of the few by trampling individual
	freedoms.  Add structure to the system by providing opportunities
	and alternatives, not imposing restrictions.
\end{itemize}
\par \\

\par In order for the
simulation model to be effective, it should be capable of assigning
metrics corresponding to these objectives, and computing them based
on the simulation inputs.  The simulation inputs and execution will
have to sufficiently model real life enough to be able to produce a
valid estimate of these performance metrics.
\subsubsection*{Use Case Diagrams}
\par As described, the
arcology use cases are simple enough, and represent a few different
modes of operation.  The system boundary is provided by the living
quarters, which, contrary to its name, extends beyond the
individual\verb|'|s residence and just encompasses all the locations where
they go about their business.  The arcology simulation model will
need to be flexible enough to model these types of activities in
order to be used for design.
\paragraph*{Live

}
\par 

\par {\bf Figure 2: Live Use Case
Diagram}
\par The
one new activity introduced by this diagram is the Travel
interaction.  As mentioned, not all of these use cases occur in one
location, so the Travel case takes care of moving the individual from
one location to another.  This interaction is performed through one
of the Cargo Transportation Infrastructure classes, which will be
detailed in the System Structure.
\subparagraph*{Actors:

}
\subparagraph*{Individual
{\it An inhabitant of the system.}}
\par 
\underline{Relations: }

\par {\bf itsFeed
}

\par Association
with Feed, Multiplicity of 1, Bi-directional 

\par {\bf itsSleep
}

\par Association
with Sleep, Multiplicity of 1, Bi-directional 

\par {\bf itsMaintenance
}

\par Association
with Maintenance, Multiplicity of 1, Bi-directional 

\par {\bf itsWork
}

\par Association
with Work, Multiplicity of 1, Bi-directional 

\par {\bf itsEntertain
}

\par Association
with Entertain, Multiplicity of 1, Bi-directional 

\par {\bf itsTravel
}

\par Association
with Travel, Multiplicity of 1, Bi-directional 

\subparagraph*{Industry
{\it Entity by which the individual is employed.}}
\par 
\underline{Relations: }

\par {\bf itsWork
}

\par Association
with Work, Multiplicity of 1, Bi-directional 

\subparagraph*{Cargo

}
\par {\it Transportation
Infrastructure responsible for moving people around (as well as
resources). }

\par 
\underline{Relations: }

\par {\bf itsTravel
}

\par Association
with Travel, Multiplicity of 1, Bi-directional 

\subparagraph*{Use
Cases: 
}
\subparagraph*{Sleep

}
\par {\it Everyone
needs a place to rest for a significant portion of the daily cycle. }

\par 
\underline{Relations: }

\par {\bf itsIndividual
}

\subparagraph*{Feed

}
\par {\it Consumption
of food and water resources. }

\par 
\underline{Relations: }

\par {\bf itsIndividual
}

\subparagraph*{Maintenance

}
\par {\it Miscellaneous
cleaning tasks, such as bathing, brushing teeth, doing laundry,
dishes, etc. would be represented here. }

\par 
\underline{Relations: }

\par {\bf itsIndividual
}

\subparagraph*{Work

}
\par {\it Work
is a transaction between and individual and an industry to exchange
money for productivity.  In this case, productivity fuels the
reactions that the industry performs. }

\par 
\underline{Relations: }

\par {\bf itsIndividual
}

\par {\bf itsIndustry
}

\subparagraph*{Entertain

}
\par {\it Entertainment
can take on several forms, from merely socializing with other
individuals, engaging in solitary entertainment interactions (TV,
games), to mass entertainment (theatre, etc.). }

\par 
\underline{Extension points: }

\par Social


\par 
\underline{Relations: }

\par {\bf itsIndividual
}

\subparagraph*{Travel

}
\par {\it An
individual is able to travel through the transportation
infrastructure to commute to work or to travel to places to fulfill
their other needs, such as for food or social interaction with
friends. }

\par 
\underline{Relations: }

\par {\bf itsIndividual
}

\par {\bf itsCargo
}

\par \\

\par Use cases for the
simulation model:
\begin{itemize}
	\item \par Set up a modeling
	scenario using input data.
	\begin{itemize}
		\item \par Build 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 \par Define \# of
			simulation units, connectivity between units, schedule of
			transaction events, schedule of reaction events, initial
			conditions.
			\item \par Output aggregate
			performance for groups of units.
		\end{itemize}
		\item \par Build top-down
		scenario:  The present day scenario is built in a top-down fashion
		from various government 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 \par Define
			high-level consumption rates for groups (using publicly tracked \&
			available data), provide distribution histograms for each type of
			resource \& transaction rates for each subunit.
			\item \par Output
			unit-level quality of life, performance.
		\end{itemize}
	\end{itemize}
	\item \par Execution of
	simulation model to produce output data.
	\item \par Postprocessing \&
	analysis of output data into performance metrics.
	\item \par Design-of-Experiments
	method of parametric analysis for solution space exploration \&
	optimization.
\end{itemize}
\subsection*{System Structure}
\par Rhapsody can organize
things into collections called packages, which roughly correspond to
namespaces in C++.  This allows elements to be sorted and separated
cleanly.
\par The basic model
consists of an overall package named GeneralHabitat, which contains
base classes and three more packages to organize resources,
reactions, and transportation methods.
\par 
GeneralHabitat
Package
\par {\it Generalized
resource queuing and transportation model of living support systems.}
\par \\

\par {\it A
scenario is required to build up a model of a system by creating a
hierarchy of cells that connect to each other via transportation
network infrastructures.  These cells then begin to perform resource
transactions between each other and resource reactions within
themselves to simulate the daily operations of the system and observe
it from different levels of detail, scaling from the individual to
the city to the world.  The transaction approach is well suited for
implementation in a discrete event simulation.}
\par \\

\par {\it Much
of the model is static, such as monetary costs for resources or the
structure of cells.  This model is not intended to perform dynamic
economic simulations or find ecological balances between the deaths
and birth rates of people or towns; those functions have been well
studied.  (That said, the nature of the event-driven simulation
framework makes it easy to patch in such functionality by
manipulating variables or cleverly reorganizing the scenario outside
of the simulation.)}
\par \\

\par {\it Instead,
this model is merely intended to construct an overglorified
spreadsheet used to perform preliminary design and calculate rough
benefits analysis on changes to ways of life, quantifying answers to
such questions as: \verb|"|how much energy might a city save if
everyone installed more efficient light bulbs?\verb|"| or \verb|"|how
much time can we save if we staggered a city\verb|'|s work schedule to
relieve rush hour congestion?\verb|"| }

\par \\

\par The GeneralClasses
object model diagram (Rhapsody\verb|'|s internal name for a UML class
diagram) depicts the base simulation classes and generally
encompasses the entire design of the simulation.  All object model
diagrams following this would actually constitute scenario-specific
use cases that highlight the use of the base simulation classes.
\subsubsection*{GeneralClasses
Object Model Diagram}
\par 

\par {\bf Figure 3:
GeneralClasses OMD}
\par 
\underline{Nested Packages: }

\par Resources


\par CellHierarchy


\par Transportation


\par Reactions


\subsubsection*{Cell

}
\par {\it The
fundamental unit of structure.  Each cell represents an identifiable
entity, which contains its own collection of resources.  These
resources can be traded with other cells, or undergo reactions within
the cell to transform groups of resources into other types of
resources.}
\par \\

\par {\it Generally,
there are five basic types of cells that work together: The entity
itself, the entity\verb|'|s environment, the entity\verb|'|s transportation
infrastructure, and leaf cells to represent individuals and
industries.}
\par \\

\par {\it To
further complicate matters, entities are arranged into hierarchies of
subcells.  This allows us to view the system on several levels of
detail, from global down to the individual.  To do this, we introduce
the constraint that a cell\verb|'|s resources always equals the sum of the
resources of all of its child subcells. }

\par 
\underline{Relations: }

\par {\bf itsSubCell
}

\par {\it Each
branch cell may contain several subcells }

\par {\bf Composedof
}

\par Composition
of Cell, Multiplicity of *, Bi-directional 

\par {\bf itsCell
}

\par {\bf Composedof
}

\par Association
with Cell, Multiplicity of 1, Bi-directional 

\par {\bf itsEnvironment
}

\par Composition
of Environment, Multiplicity of 1, Bi-directional 

\par {\bf itsTransportationInfrastructure
}

\par Composition
of TransportationInfrastructure, Multiplicity of 1, Bi-directional 

\par 
\underline{Superclasses: }

\par LeafCell


\par Public


\par 
\underline{Subclasses: }

\par City


\par Community


\par Environment


\par Household


\par Nation


\par Region


\par TransportationInfrastructure


\par World


\subsubsection*{LeafCell

}
\par {\it Leaf
cells are a special type of cell reserved for individuals and
industries.  These cannot be subdivided further into subcells, and
thus lack an environment or a transportation infrastructure to
support those subcells. }

\par 
\underline{Relations: }

\par {\bf itsResourceEngine
}

\par {\bf Contains
}

\par Composition
of ResourceEngine, Multiplicity of *, Bi-directional 

\par {\bf itsReactionEngine
}

\par Composition
of ReactionEngine, Multiplicity of *, Bi-directional 

\par 
\underline{Subclasses: }

\par Cell


\par Individual


\par Industry


\subsubsection*{CellHierarchy

}
\paragraph*{Object
Model Diagrams: 
}
\par We model the area of
interest by breaking it down into a hierarchy of cells and subcells
that work at a different level of detail.  There are essentially two
types of units, parent nodes and leaf nodes, with the only
distinction being that leaf nodes do not have any subcells.  One
possible scheme for defining this hierarchy is presented in the
CellTypes class diagram.  It\verb|'|s important that all of the subcells add
up exactly to form the parent cell, so in some cases, it would be
necessary to define subcells that represent everything that might be
left over after allocation into existing subcells.  For example, the
rural areas not part of a city would be lumped into a special
residual \verb|"|City\verb|"| subcell to be included as part of a
\verb|"|Nation\verb|"|.  Similarly, homeless people and vagrants would be
lumped together into a special \verb|"|Household\verb|"| or \verb|"|Community\verb|"|
subcell to be included as part of \verb|"|City\verb|"| data.  This should
be an acceptable practice, since these units may tend have similar
characteristics.
\subparagraph*{CellTypes

}
\par 

\par {\bf Figure 4: CellTypes OMD}
\paragraph*{Classes:

}
\subparagraph*{World

}
\par {\it The
limits of the size of the system.  Of course, the architecture of the
model is left open to envelop interplanetary commerce between worlds
in the distant future. }

\par 
\underline{Relations: }

\par {\bf itsRegion\_1
}

\par Aggregation
(me as the whole part) of Region, Multiplicity of *, Bi-directional 

\par 
\underline{Superclasses: }

\par Cell


\par Public


\subparagraph*{Region

}
\par {\it A
geographic region would tend to be composed of several nations with a
common situation.  Of course, large nations may exist over several
regions.  For our purposes, we\verb|'|ll simplify by assuming all nations
are smaller than the regions they are in. }

\par 
\underline{Relations: }

\par {\bf itsWorld\_1
}

\par Association
with World, Multiplicity of 1, Bi-directional 

\par {\bf itsNation
}

\par Aggregation
(me as the whole part) of Nation, Multiplicity of *, Bi-directional 

\par 
\underline{Superclasses: }

\par Cell


\par Public


\subparagraph*{Nation

}
\par {\it A
nation sets the policy for international trade and commerce.  Plus,
data is often available on the national level for input into the
top-down models. }

\par 
\underline{Relations: }

\par {\bf itsRegion
}

\par Association
with Region, Multiplicity of 1, Bi-directional 

\par {\bf itsCity
}

\par Aggregation
(me as the whole part) of City, Multiplicity of *, Bi-directional 

\par 
\underline{Superclasses: }

\par Cell


\par Public


\subparagraph*{City

}
\par {\it A
city would be the highest level of organization represented by an
individual arcology.  Several cities would be interconnected to form
a nation.  One \verb|"|city\verb|"| cell unit can be put aside to account
for all rural areas not included in other cities. }

\par 
\underline{Relations: }

\par {\bf itsNation
}

\par Association
with Nation, Multiplicity of 1, Bi-directional 

\par {\bf itsCommunity
}

\par Aggregation
(me as the whole part) of Community, Multiplicity of *,
Bi-directional 

\par {\bf itsIndustry
}

\par Aggregation
(me as the whole part) of Industry, Multiplicity of *, Bi-directional


\par 
\underline{Superclasses: }

\par Cell


\par Public


\subparagraph*{Community

}
\par {\it Families
tend to cluster into communities, which in turn form cities. }

\par 
\underline{Relations: }

\par {\bf itsCity
}

\par Association
with City, Multiplicity of 1, Bi-directional 

\par {\bf itsHousehold
}

\par Aggregation
(me as the whole part) of Household, Multiplicity of *,
Bi-directional 

\par 
\underline{Superclasses: }

\par Cell


\par Public


\subparagraph*{Household

}
\par {\it A
household would consist of a family of several individuals living
together in one residence.  }

\par \\

\par {\it A
family doesn\verb|'|t necessarily include extended family, or preclude the
existence of other arrangements such as roommates. }

\par 
\underline{Relations: }

\par {\bf itsCommunity
}

\par Association
with Community, Multiplicity of 1, Bi-directional 

\par {\bf itsIndividual
}

\par Aggregation
(me as the whole part) of Individual, Multiplicity of *,
Bi-directional 

\par 
\underline{Superclasses: }

\par Cell


\par Public


\subparagraph*{Individual

}
\par {\it A
leaf node in the hierarchy, the Individual cannot be broken down into
any more subcomponents (we can only hope).  Most individuals will
also work for an industry.}
\par \\

\par {\it Individuals
are free to move from place to place as part of their daily lives. 
This allows them to commute to work or to visit friends in another
household and transfer their resource consumption to stress the
infrastructure at other locations.}
\par \\

\par {\it When
individuals travel, it puts a strain on the transportation
infrastructure. }

\par 
\underline{Relations: }

\par {\bf itsHousehold
}

\par Association
with Household, Multiplicity of 1, Bi-directional 

\par {\bf itsIndustry
}

\par Association
with Industry, Multiplicity of 0,1, Bi-directional 

\par 
\underline{Superclasses: }

\par LeafCell


\par Public


\subparagraph*{Industry

}
\par {\it Cities
have a special type of leaf node called Industry, which essentially
employ several Individual units to perform certain specialized
reactions on particular resources in bulk.  Generally, they consume
energy resources to refine material resources. }

\par 
\underline{Relations: }

\par {\bf itsCity
}

\par Association
with City, Multiplicity of 1, Bi-directional 

\par {\bf itsIndividual
}

\par Association
with Individual, Multiplicity of *, Bi-directional 

\par 
\underline{Superclasses: }

\par LeafCell


\par Public


\subsubsection*{Environment

}
\par {\it A
special passive cell that will always yield any resources that it has
and accept any waste that is ejected into it.  Instead of interacting
with other cells on the same level, it only interacts with subcells. 
So, for example, a nation\verb|'|s resources can be split amongst its
cities, and city level waste gets deposited in the nation\verb|'|s
environment (as opposed to some other nation\verb|'|s environment). }

\par 
\underline{Relations: }

\par {\bf itsCell
}

\par Association
with Cell, Multiplicity of 1, Bi-directional 

\par 
\underline{Superclasses: }

\par Cell


\par Public


\subsubsection*{TransportationInfrastructure

}
\par {\it A
special cell that interacts with subcells.  It represents the
connective tissue that allows resources to transit between subcells,
and it takes both money and fuel in the process.  Several types of
transportation infrastructures can be defined with different
characteristics in terms of resource burn rates. }

\par 
\underline{Relations: }

\par {\bf itsCell
}

\par Association
with Cell, Multiplicity of 1, Bi-directional 

\par 
\underline{Superclasses: }

\par Cell


\par Public


\par 
\underline{Subclasses: }

\par Cargo


\par Pipeline


\par Radio


\par Wire


\par 
\underline{Attributes: }

\par {\bf Maintenance
}

\par {\it Monetary
maintenance cost incurred to keep this system up and running per unit
cycle. }

\par Type
of double, Public 

\par {\bf TransitCost
}

\par {\it Monetary
cost required to move a unit of resource through this transportation
infrastructure per unit distance. }

\par Type
of double, Public 

\par {\bf Value
}

\par {\it Infrastructure
build value, how much money needs to be invested to put this
transportation infrastructure in place so it can be used. }

\par Type
of double, Public 

\subsubsection*{Transportation}
\par The transportation
network serves as connective tissue that joins the nodes of the
structure together.  It is up to the scenario to define the
connectivity graph, but once accomplished this will compute the
overhead in terms of resource burn to transfer individuals and cargo
through the network. 

\paragraph*{Object
Model Diagrams: 
}
\subparagraph*{ConnectiveTissue

}
\par 

\par {\bf Figure 5:
ConnectiveTissue OMD}
\paragraph*{Classes:

}
\subparagraph*{Cargo

}
\par {\it A
generalized form of transportation for passengers and cargo.  Only
these forms of transportation can handle material goods and
individuals. }

\par 
\underline{Superclasses: }

\par TransportationInfrastructure


\par Public


\par 
\underline{Subclasses: }

\par AirTransport


\par GroundCargo


\par Rail


\par Ship


\par 
\underline{Attributes: }

\par {\bf NetworkCapacity
}

\par {\it The
number of transport units the transportation infrastructure can
handle.  As network capacity approaches this number, congestion
effects set in. }

\par Type
of int, Public 

\par {\bf numUnits
}

\par {\it Number
of transport units actively using the system at any given time.  When
this number nears the NetworkCapacity, congestion delays set in which
begin to cut into the efficiency of the system. }

\par Type
of int, Public 

\subparagraph*{AirTransport

}
\par Expensive but fast, and
often must be used in a multimodal fashion, where households must
transfer their wares up to the city level first before making airhops
between cities.
\par 
\underline{Superclasses: }

\par Cargo


\par Public


\subparagraph*{GroundCargo

}
\par Well connected,
reaching every location with road coverage.
\par 
\underline{Superclasses: }

\par Cargo


\par Public


\subparagraph*{Rail

}
\par High initial
infrastructure costs and not very well connected, but fairly
economical once everything is in place.
\par 
\underline{Superclasses: }

\par Cargo


\par Public


\subparagraph*{Ship

}
\par Only a boon to certain
cities, and requires some contention for port infrastructure.
\par 
\underline{Superclasses: }

\par Cargo


\par Public


\subparagraph*{Pipeline

}
\par {\it Pipeline
infrastructure is good for transporting fluid commodities, such as
water, natural gas, sewage, etc. }

\par 
\underline{Superclasses: }

\par TransportationInfrastructure


\par Public


\subparagraph*{Wire

}
\par {\it Distribution
system for electricity and information }

\par 
\underline{Superclasses: }

\par TransportationInfrastructure


\par Public


\subparagraph*{Radio

}
\par {\it Distribution
system for information }

\par 
\underline{Superclasses: }

\par TransportationInfrastructure


\par Public


\subsubsection*{Reactions

}
\par This package defines
reactions that can occur within cells to transform one set of
resources into another set of resources.  The definition of the
reaction governs changes to the quantities of inputs and outputs, and
balances them the same way a chemical reaction would be balanced.
\paragraph*{Object
Model Diagrams: 
}
\subparagraph*{ReactionTypes

}
\par The icons in the top
right of some of the classes indicate that those classes have
activity diagrams associated with them.  These diagrams can be viewed
in the corresponding System Behavior section.  The specific reactions
on the right inherit the activity diagrams from parent classes, where
they can be extended.  The \verb|"|Refining\verb|"| class appears to have
\verb|"|lost\verb|"| its activity diagram, though, probably due to a bug
in the way Rhapsody inherits statecharts; it should be possible to
fix by deleting the class and recreating it.
\par 

\par {\bf Figure 6: ReactionTypes
OMD}
\subparagraph*{CombustionReaction}
\par This diagram highlights
one of the reactions in detail.  Other reaction types would look very
similar to this diagram with different combinations of input and
output resources.
\par 

\par {\bf Figure 7:
CombustionReaction OMD}
\par \\

\subsubsection*{Resources

}
\par This package details
the various generalizations of resources available in the model.
\paragraph*{Object
Model Diagrams: 
}
\subparagraph*{Resource

}
\par {\it A
particular resource of interest that can be contained, traded, or
reacted within cells. }

\par 
\underline{Relations: }

\par {\bf itsResourceEngine
}

\par {\bf Manages
}

\par Association
with ResourceEngine, Multiplicity of 1, Bi-directional 

\par 
\underline{Subclasses: }

\par Fuel


\par Information


\par Money


\par Waste


\par 
\underline{Attributes: }

\par {\bf Qty
}

\par Type
of double, Public 

\par {\bf Unit
}

\par Type
of OMString, Public 

\subparagraph*{ResourcesTypes

}
\par 

\par {\bf Figure 8: ResourceTypes
OMD}
\subparagraph*{Money

}
\par Financial resources are
often exchanged for goods and services, so it\verb|'|s worth tracking how
much each cell has on reserve.
\par 
\underline{Superclasses: }

\par Resource


\par Public


\subparagraph*{Information

}
\par Information can also be
transferred and accounts for education activities or entertainment.
\par 
\underline{Superclasses: }

\par Resource


\par Public


\subparagraph*{Fuel

}
\par The Fuel superclass
generally refers to any resource that is useful.
\par 
\underline{Superclasses: }

\par Resource


\par Public


\par 
\underline{Subclasses: }

\par Air


\par Electricity


\par Food


\par Material


\par Petroleum


\par Water


\subparagraph*{Air

}
\par Rather than get too
specific in chemistry terms, this class represents clean useful air
for breathing or to provide oxygen for combustion.
\par 
\underline{Superclasses: }

\par Fuel


\par Public


\subparagraph*{Electricity

}
\par Electrical distribution
is one of the oldest networks in the world and serves as a catalyst
for many other useful reactions, or merely as a utility to improve
the quality of life.
\par 
\underline{Superclasses: }

\par Fuel


\par Public


\subparagraph*{Food

}
\par Anything people can
eat.
\par 
\underline{Superclasses: }

\par Fuel


\par Public


\subparagraph*{Material

}
\par Any kind of object or
artifact that might be transferred.  Along with the mass value
inherited from resource, material can also have a value density,
which can increase with the refinement reaction to represent a lot of
what industry does.
\par 
\underline{Superclasses: }

\par Fuel


\par Public


\subparagraph*{Petroleum

}
\par More traditional fuel
products that are not necessarily restricted to oil or derivatives. 
Anythings that burns to produce energy could be included, such as
coal and wood.
\par 
\underline{Superclasses: }

\par Fuel


\par Public


\subparagraph*{Water

}
\par Clean potable water for
drinking or for maintenance.
\par 
\underline{Superclasses: }

\par Fuel


\par Public


\subparagraph*{Waste

}
\par Superclass that
represents byproducts that cells probably don\verb|'|t want to keep around,
but that need to be tracked and disposed of appropriately.  Waste can
still put a load on the transportation infrastructure, and require
industrial resources to treat and refine properly.
\par 
\underline{Superclasses: }

\par Resource


\par Public


\par 
\underline{Subclasses: }

\par AirPollution


\par Garbage


\par Heat


\par Sewage


\subparagraph*{AirPollution

}
\par Any kind of gaseous
waste.
\par 
\underline{Superclasses: }

\par Waste


\par Public


\subparagraph*{Garbage

}
\par Solid waste products,
mostly discarded materials.
\par 
\underline{Superclasses: }

\par Waste


\par Public


\subparagraph*{Heat

}
\par Otherwise known as
entropy, almost every process surely creates waste heat that needs to
be dissipated.
\par 
\underline{Superclasses: }

\par Waste


\par Public


\subparagraph*{Sewage

}
\par Liquid waste that might
be drained through the sewage system.
\par 
\underline{Superclasses: }

\par Waste


\par Public


\subsection*{System Behavior}
\par The simulation model is
based on a discrete event simulation engine.  This means that state
changes in the system structure are triggered by the firing of events
which occur along the global time line queue.  The model executes by
populating the global time queue with scheduled events and firing
those events in order.  Every time an event is activiated, the system
global time is advanced to that time.  Any state transitions in the
model that were blocking on this event are executed so they can
perform their activities, which often result in the scheduling of
more events in the future.  Thus the simulation perpetuates events
and continues in time until there are no more events left on the
simulation queue.
\par \\

\subsubsection*{Events:

}
\paragraph*{evFeed

}
\par {\it Event
signalling that the person should make an attempt at going somewhere
to eat. }

\paragraph*{evSleep

}
\par {\it Event
signalling person to go somewhere (preferably home) so they can
sleep. }

\paragraph*{evWakeup

}
\par {\it Event
signalling a person to wake up and begin their day. }

\par \\

\subsubsection*{Individual}
\par The individual
transitions from state to state in their daily activities triggered
by these events.  A fairly simple schedule could be arranged as
follows to implement a statechart representing a typical person\verb|'|s
day.  The statechart depends on having the right combination of
events defined and triggered to advance the individual through the
full daily cycle.
\paragraph*{Statechart

}
\par \\

\par {\bf ROOT
}

\par Or-state


\par 
\underline{Substates: }

\par Live


\par Default
Transition 

\par 
\underline{Target: }

\par Live


\par {\bf Live
}

\par Or-state


\par 
\underline{Substates: }

\par Entertain


\par Feed


\par Maintenance


\par Sleep


\par Travel


\par Work


\par Default
Transition 

\par /evSleep();


\par 
\underline{Target: }

\par Sleep


\par {\bf Entertain
}

\par Or-state


\par Out
Transition 

\par 
\underline{Target: }

\par Sleep


\par {\bf Feed
}

\par Or-state


\par Out
Transition 

\par 
\underline{Target: }

\par Maintenance


\par Out
Transition 

\par 
\underline{Target: }

\par Work


\par {\bf Maintenance
}

\par Or-state


\par Out
Transition 

\par /evFeed();


\par 
\underline{Target: }

\par Feed


\par Out
Transition 

\par 
\underline{Target: }

\par Travel


\par {\bf Sleep
}

\par Or-state


\par Out
Transition 

\par /evWakeup();


\par 
\underline{Target: }

\par Maintenance


\par {\bf Travel
}

\par Or-state


\par Out
Transition 

\par 
\underline{Target: }

\par Work


\par Out
Transition 

\par 
\underline{Target: }

\par Entertain


\par {\bf Work
}

\par Or-state


\par Out
Transition 

\par /evFeed();


\par 
\underline{Target: }

\par Feed


\par Out
Transition 

\par 
\underline{Target: }

\par Travel


\par \\

\subsubsection*{ResourceEngine

}
\par {\it Each
resource engine keeps track of the flow of one resource within a
cell.  This includes the input of resource from the environment,
trade of resources with other cells, internal reactions that
transform resources to and from other resources, and waste resource
output back to the environment.}
\par \\

\par {\it The
resource engines are initialized to fire push/pull transaction events
at regular intervals.  Pull transactions would offer to exchange
monetary resources for goods and services such as food or
electricity.  Push transactions relate to the expulsion of waste, and
would end up in the immediate environment unless picked up by a
transportation system to take to, say, a waste processing plant
(represented by an industry) first. }

\par 
\underline{Relations: }

\par {\bf itsResource
}

\par {\it Each
ResourceEngine manages the quantity of one resource for each Cell
unit through transactions in/out of the environment, trade with other
Cell units via connective transportation cells, or internal reactions
within a Cell. }

\par {\bf Manages
}

\par Composition
of Resource, Multiplicity of 1, Bi-directional 

\par {\bf itsLeafCell
}

\par {\bf Contains
}

\par Association
with LeafCell, Multiplicity of 1, Bi-directional 

\par 
\underline{Attributes: }

\par {\bf Amount
}

\par {\it Amount
of resource requested per cycle }

\par Type
of double, Public 

\par {\bf Interval
}

\par {\it Time
interval between requests }

\par Type
of double, Public 

\paragraph*{Activity Diagram 
}
\par Resources essentially
attempt three types of transactions:
\begin{enumerate}
	\item \par A request for
	resources from its parent cell or environment, in client/server
	pattern.
	\item \par A peer-to-peer
	trading agreement scheduled through the scenario setup.
	\item \par A
	dump of resources back to its parent cell or environment.
\end{enumerate}
\par \\

\par {\bf ROOT
}

\par Or-state


\par 
\underline{Substates: }

\par Expel


\par Pull


\par state\_3


\par Trade


\par Default
Transition 

\par 
\underline{Target: }

\par Pull


\par {\bf Expel
}

\par {\it Push
transaction to deposit waste into the waste management infrastructure
(or the environment). }

\par Action
State 

\par 
\underline{EntryAction  }

\par evExpelResource();


\par Out
Transition 

\par 
\underline{Target: }

\par state\_3


\par {\bf Pull
}

\par {\it During
initial scenario setup, set a starting  }

\par Action
State 

\par 
\underline{EntryAction  }

\par evRequestResource();


\par Out
Transition 

\par 
\underline{Target: }

\par Trade


\par {\bf state\_3
}

\par Local
Termination State 

\par {\bf Trade
}

\par {\it Transaction
to exchange resource with another cell on the same level. }

\par Action
State 

\par 
\underline{EntryAction  }

\par evExchangeResource();


\par Out
Transition 

\par 
\underline{Target: }

\par Expel


\par \\

\subsubsection*{ReactionEngine

}
\par {\it Resources
are required to fuel several reactions that occur within a cell. 
These reactions are driven by the reactionengines associated with a
cell to consume several resources and turn them into other resources
and waste.  }

\par \\

\par {\it When
enough of the input resources become available, the reaction event
can commence.  Otherwise, the reaction engine asks the resource
engine to request the required resources through pull transactions.}
\par \\

\par {\it Several
reaction types are available, but the assigment and scheduling of
reaction events is up to the scenario builder. }

\par 
\underline{Relations: }

\par {\bf itsLeafCell
}

\par Association
with LeafCell, Multiplicity of 1, Bi-directional 

\par {\bf itsResourceEngine
}

\par {\bf Request
Resources }

\par Association
with ResourceEngine, Multiplicity of *, Uni-directional 

\par {\bf itsResource
}

\par {\bf Check
Inputs }

\par Association
with Resource, Multiplicity of *, Uni-directional 

\par {\bf itsInputResources
}

\par Association
with InputResources, Multiplicity of 1, Bi-directional 

\par {\bf itsOutputResources
}

\par Association
with OutputResources, Multiplicity of 1, Bi-directional 

\par 
\underline{Subclasses: }

\par Combustion


\par Consumption


\par Disposal


\par Refining


\par Utilization


\paragraph*{Activity Diagram 
}
\par \\

\par {\bf ROOT
}

\par Or-state


\par 
\underline{Substates: }

\par state\_0


\par state\_1


\par state\_2


\par state\_3


\par Default
Transition 

\par 
\underline{Target: }

\par state\_0


\par {\bf state\_0
}

\par {\it Poll
input resources to see if there are enough raw materials ready to
undergo the reaction. }

\par Action
State 

\par 
\underline{EntryAction  }

\par checkResources();


\par Out
Transition 

\par Condition
Connector 

\par 
\underline{Branches: }

\par [SufficientResources();]


\par Target:


\par state\_2


\par [InsufficientResources();]


\par Target:


\par state\_1


\par {\bf state\_1
}

\par {\it Record
an appropriate penalty for a failed reaction.  If no penalty action
is defined, then the failure is merely recorded.  These failures
could then lead to a detraction in the quality of life output metric.
}

\par Action
State 

\par 
\underline{EntryAction  }

\par ReactionFailed();


\par Out
Transition 

\par 
\underline{Target: }

\par state\_3


\par {\bf state\_2
}

\par {\it Reduce
input quantities and increase output quantities in the ratio defined
in this reaction. }

\par Action
State 

\par 
\underline{EntryAction  }

\par ExecuteReaction();


\par Out
Transition 

\par 
\underline{Target: }

\par state\_3


\par {\bf state\_3
}

\par Local
Termination State 

\par \\

\par \\

\subsubsection*{InputResources

}
\par {\it Proxy
to ReactionEngine that requests or collects resources available
within the cell. }

\par 
\underline{Relations: }

\par {\bf itsReactionEngine
}

\par Association
with ReactionEngine, Multiplicity of 1, Bi-directional 

\par {\bf itsResource
}

\par {\bf Decreases
}

\par Association
with Resource, Multiplicity of *, Uni-directional 

\par {\bf itsResourceEngine
}

\par {\bf RequestResources
}

\par Association
with ResourceEngine, Multiplicity of *, Uni-directional 

\par {\bf itsCombustion
}

\par Association
with Combustion, Multiplicity of 1, Bi-directional 

\par {\bf itsAir
}

\par Association
with Air, Multiplicity of 1, Uni-directional 

\par {\bf itsPetroleum
}

\par Association
with Petroleum, Multiplicity of 1, Uni-directional 

\subsubsection*{OutputResources

}
\par {\it Proxy
to ResourceEngine that increases associated output resources upon
successful reactions. }

\par 
\underline{Relations: }

\par {\bf itsReactionEngine
}

\par Association
with ReactionEngine, Multiplicity of 1, Bi-directional 

\par {\bf itsResource
}

\par {\bf Increases
}

\par Association
with Resource, Multiplicity of *, Uni-directional 

\par {\bf itsCombustion
}

\par Association
with Combustion, Multiplicity of 1, Bi-directional 

\par {\bf itsAirPollution
}

\par Association
with AirPollution, Multiplicity of 1, Uni-directional 

\par {\bf itsHeat
}

\par Association
with Heat, Multiplicity of 1, Uni-directional 

\subsubsection*{Combustion

}
\par {\it Reaction
in which air and petroleum fuel combine to produce waste gas (air
pollution) and heat.  Often a catalyst for operating the various
forms of cargo transportation. }

\par 
\underline{Relations: }

\par {\bf itsInputResources\_1
}

\par Association
with InputResources, Multiplicity of 1, Uni-directional 

\par {\bf itsInputResources\_2
}

\par Association
with InputResources, Multiplicity of 1, Bi-directional 

\par {\bf itsOutputResources\_1
}

\par Association
with OutputResources, Multiplicity of 1, Bi-directional 

\par 
\underline{Superclasses: }

\par ReactionEngine


\par Public


\paragraph*{Activity Diagram}
\par The activity diagram
for Combustion is grey to indicate that it was inherited from a
parent class.  Any changes to the inherited activity diagram would
have shown up in color.
\par \\


\par {\bf ROOT
}

\par Or-state


\par Inherited
 

\par 
\underline{Substates: }

\par state\_0


\par state\_1


\par state\_2


\par state\_4


\par Default
Transition 

\par Inherited


\par 
\underline{Target: }

\par state\_0


\par {\bf state\_0
}

\par Action
State 

\par Inherited
 

\par 
\underline{EntryAction  }

\par checkResources();


\par Out
Transition 

\par Inherited


\par Condition
Connector 

\par 
\underline{Branches: }

\par [SufficientResources();]


\par Target:


\par state\_2


\par [InsufficientResources();]


\par Target:


\par state\_1


\par {\bf state\_1
}

\par Action
State 

\par Inherited
 

\par 
\underline{EntryAction  }

\par ReactionFailed();


\par Out
Transition 

\par Inherited


\par 
\underline{Target: }

\par state\_4


\par {\bf state\_2
}

\par Action
State 

\par Inherited
 

\par 
\underline{EntryAction  }

\par ExecuteReaction();


\par Out
Transition 

\par Inherited


\par 
\underline{Target: }

\par state\_4


\par {\bf state\_4
}

\par Local
Termination State 

\par \\

\subsubsection*{Refining

}
\par {\it Process
taking in materials and energy as input and outputting refined,
higher quality material. }

\par 
\underline{Superclasses: }

\par ReactionEngine


\par Public


\par \\

\par Reaction diagrams for
Refining and the rest of the reactions would look similar to
combustion, with different combinations of resources connected to the
Input and Output classes.
\section*{System Requirements Allocation}
\subsection*{Requirements}
\par As
with everything else in this design document, a distinction must be
made between requirements for the arcology and requirements specific
to the arcology simulation model (the actual system of interest). 
The ability for the simulation to successfully model the fulfillment
of fundamental arcology requirements is in itself a requirement.
\par \\

\par The simulation tool
should be able to quantify estimates for real life occurrences.  One
of the odd requirements for this system is to provide special failure
cases in the event that all of an individual\verb|'|s use cases cannot be
met.  While the consequences for failure to fulfill a need (such as
starvation, homelessness, or sickness do to poor hygiene -- all
very real-world problems) does not necessarily have to be simulated
to achieve its purpose in the system, failures do need to be noted
and become part of the output of the system.  It is of interest to
note that failure {\it is} an option, and must be properly accounted
for as part of the normal operation of the system.
\par \\

\par We present separate
requirements for the archology and the simulation model.  The
simulation requirements are driven by the ability to model
interactions between elements that affect the archology requirements,
so they may be seen as further derived.
\subsubsection*{Arcology Primitive Requirements}
\begin{enumerate}
	\item \par Attend to basic
	occupant needs defined in the Individual use cases described in Live.
	\begin{enumerate}
		\item \par Provisions 
		({\bf Feed})
		\begin{enumerate}
			\item \par Food
			\item \par Water
			\item \par Other
			consumables (vitamins, nutrients, etc.)
		\end{enumerate}
		\item \par Indirect assets \&
		qualities
		\begin{enumerate}
			\item \par Shelter,
			security  ({\bf Sleep})
			\item \par Health, hygiene
			maintenance not covered by   ({\bf Maintenance})
			\begin{enumerate}
				\item \par Waste removal
			\end{enumerate}
		\end{enumerate}
	\end{enumerate}
	\item \par Self-sufficiency \&
	sustainability  ({\bf Work})
	\begin{enumerate}
		\item \par Extract required
		resources from environment
		\item \par Extract labor
		from occupants
	\end{enumerate}
	\item \par Improve quality of
	life for occupants  ({\bf Entertain})
	\begin{enumerate}
		\item \par Education
		\item \par Entertainment
		\item \par Social
		interaction
	\end{enumerate}
\end{enumerate}
\subsubsection*{Arcology Derived Requirements}
\begin{enumerate}
	\item \par Transformations of
	resources
	\begin{enumerate}
		\item \par Fuel to Waste -
		byproducts of Arcology Requirements 
		\item \par Construction /
		deconstruction mechanism - resulting from 
	\end{enumerate}
	\item \par Accounting \&
	transportation mechanism for resources
	\begin{enumerate}
		\item \par Solid - Arcology
		Requirements 
		\item \par Liquid - Arcology
		Requirements 
		\item \par Gaseous -
		Arcology Requirements 
		\item \par Information -
		Arcology Requirements ,
		\item \par Monetary credits
		- intermediary between exchanges and transformations.
	\end{enumerate}
	\item \par Transportation
	mechanism for resources \& occupants in order to satisfy all of
	the above  ({\bf Travel})
\end{enumerate}
\subsubsection*{Simulation Requirements}
\begin{enumerate}
	\item \par Insert scenarios
	as inputs
	\begin{enumerate}
		\item \par Numbers of units
		involved (people, transportation mechanisms, industrial entities,
		etc.)
		\item \par Available
		resources from environment, initial conditions
		\item \par Resource
		conversion rates, schedules, functions
	\end{enumerate}
	\item \par Simulation
	execution - model resource consumption/production rates, providing
	estimates on actual performance (pending validation of model)
	\item \par Output metrics
	defined and calculated
	\begin{enumerate}
		\item \par Qualitative
		measures of performance
		\item \par Quantitative
		measures of performance
		\item \par Allow possibility
		for formulating optimization problems to aid in benefits analysis \&
		decision-making in arcology design.
	\end{enumerate}
	\item \par Significant events
	(to be defined by modeling use case scenario case studies) should be
	modelable by scenario architecture -- important activities that
	have impact on performance measures should not be ignored.  Should
	provide at least approximate methods of simulating effects that are
	difficult to model.
	\item \par Specification of
	accuracy in estimates \& predictions.  (Goal of \verb|~|20\%)
\end{enumerate}
\subsection*{Requirements Traceability}
\par The simulation system
is capable of supporting both present day and arcology scenarios.  In
order to justify the derived simulation requirements, we\verb|'|ll perform a
traceability exercise by attempting to map real world data onto the
model.
\par \\

\par This data from Energy
Action provides Fuel consumption on several levels, including world,
regional, and national.  The cumulative value for World would be fed
into the top level cell.  4 subcells would be created below it to
contain the regions North America, Europe, Asia Pacific, and one to
contain everything else.  On the national level, we can again create
two subcells of North America; one to represent the USA and one to
hold accounting information for Canada, Mexico, and Latin America
combined.  

\par \\

\subsubsection*{Primary
Energy Consumption by Fuel}
\par {\bf Million
tonnes oil equivalent - 1999} 


	
		
		
			
				\par 
			
		
	

\par \\

\par Now by
cross-referencing population statistics for the year 1999 from the
International Energy Annual reference, we can arrive at the following
rough per-capita statistics:
\begin{description}
	]
	
		
		
		
		
		
			
				\par \\
				
			
			
				\par \\
				
			
			
				\par \\
				
			
			
				\par \\
				
			
		
		
			
				\par {\bf Population (millions)}
			
			
				\par {\bf Total
				Fuel }
				
				\par {\bf Consumption}
			
			
				\par {\bf Per capita}
			
		
		
			
				\par {\bf USA}
			
			
				\par 272.69
			
			
				\par 2204.9
			
			
				\par 8.0857
			
		
		
			
				\par {\bf N
				Amer}
			
			
				\par 400.52
			
			
				\par 2557.3
			
			
				\par 6.3849
			
		
		
			
				\par {\bf Europe}
			
			
				\par    863.73
			
			
				\par 1800.4
			
			
				\par 2.0844
			
		
		
			
				\par {\bf Asia
				Pac.}
			
			
				\par   3,375.40
			
			
				\par 2255
			
			
				\par 0.6681
			
		
		
			
				\par {\bf Other}
			
			
				\par 1,352.48
			
			
				\par 1920.7
			
			
				\par 1.4201
			
		
		
			
				\par {\bf World}
			
			
				\par 5,992.13
			
			
				\par 8533.4
			
			
				\par 1.4241
			
		
		
			
				\par \\
				
			
			
				\par \\
				
			
			
				\par \\
				
			
			
				\par \\
				
			
		
	
\end{description}
\par Despite the wide range
of per capita usage, the subpartitioning of the cell hierarchy
ensures that groups of like individuals are distributed near each
other, so we don\verb|'|t smooth too much of the complexity out of the real
system.  This will allow us to model the dynamics of, say, having an
energy-hungry populace concentrated in one part of the world.
\par We can further use
Energy Information Administration data to specify energy utilization
breakdown for residential, commercial/industrial (we need not make a
distinction for our purposes), and transportation uses.  

\par Finally, the reaction
equations can be used to close the loop on the system and estimate
how much waste products were produced that need to be dealt with or
absorbed by the environment.
\par \\

\par This traceability
process ensures that each complexity introduced in the detailed
simulation requirements supports a modeling capability requirement
that will be used to complete primary requirements and goals.
\subsection*{Specifications}
\par Again, specifications
for the archology and the simulation of the archology presented
separately:  

\subsubsection*{Specs for Arcology Primitive Requirements}
\begin{enumerate}
	\item \par Attend to basic
	occupant needs defined in the Individual use cases described in Live.
	\begin{enumerate}
		\item \par 
		Provisions
		\begin{enumerate}
			\item \par Food : > 1.77
			kg per diem
			\item \par Water : > 2.3
			kg per diem
			\item \par Other
			consumables (vitamins, nutrients, etc.)
		\end{enumerate}
		\item \par Indirect assets \&
		qualities
		\begin{enumerate}
			\item \par Shelter,
			security : distribution of 5 - 10 hours of sleep, personal living
			quarters with > 37 m2 of personal living space.
			\item \par Health, hygiene
			maintenance not covered by  -- timely delivery of emergency
			supplies \& services.
			\begin{enumerate}
				\item \par Waste removal --
				roughly equivalent to total of Provisions.
			\end{enumerate}
		\end{enumerate}
	\end{enumerate}
	\item \par Self-sufficiency \&
	sustainability 
	
	\begin{enumerate}
		\item \par Extract required
		resources from environment -- varies, should balance with
		environmental production rates, if known.
		\item \par Extract labor
		from occupants -- a distribution of around 1/3 of the daily
		cycle.  Provide > 19 m2 of work space.
	\end{enumerate}
	\item \par Improve quality of
	life for occupants :  maintain or increase amount of leftover time
	dedicated to the following:
	\begin{enumerate}
		\item \par Education
		\item \par Entertainment
		\item \par Social
		interaction
	\end{enumerate}
\end{enumerate}
\subsubsection*{Specs for Arcology Derived Requirements}
\begin{enumerate}
	\item \par Transformations of
	resources
	\begin{enumerate}
		\item \par Fuel to Waste --
		roughly 1 to 1 conversion factor by mass.
		\item \par Construction /
		deconstruction mechanism -- 
		
	\end{enumerate}
	\item \par Accounting \&
	transportation mechanism for resources -- Conversion, creation,
	consumption of each class of resource.
	\item \par Transportation
	mechanism for resources \& occupants -- 
	
	\begin{enumerate}
		\item \par Quantify measures
		of effectiveness -- cost, latency, throughput, efficiency
	\end{enumerate}
\end{enumerate}
\subsubsection*{Specs for Simulation}
\par These mostly deal with
measures necessary to create hardware and programming efficiency
requirements for successful execution, and have little else to do
with the planning or setup of the model. Therefore, we won't
dwell too much on these, but provide a placeholder for lower-level
specification by software engineers.
\begin{enumerate}
	\item \par Ability to model
	baseline scenario on the order of magnitude of \verb|~|1010
	units processing a 24 hour period of events on currently available
	computer hardware.
	\item \par Attain a
	reasonable execution time of less than 10 hours to process the
	scheduled event queue such that the baseline scenario, assuming \verb|~|100
	events per unit during the 24 hour period.
	\item \par Achieve real time
	or faster simulation speed of the baseline scenario.
\end{enumerate}
\section*{Tradeoff Analysis}
\par This simulation model
will essentially be a scoring system in and of itself, as it provides
output parameters that can be combined to form a composite score. 
Analytic Hierarchy Process would probably not be appropriately
applied here, since the model produces quantitative results well
suited for the scoring process, and is not so much intended to rank
cities based on their performance.
\par \\

\par The simulation system
culminates in the ability to reduce piles of data into simple
measures of effectiveness that can be used to compare several city
designs or evaluate several potential changes to the operation of one
city, and also reflect its impact on both higher levels of
organization on down to the low levels of individual life.
\par \\

\par Since most of the
measures of effectiveness are ratios that range between 0 and 1,
there are no concerns about recentering scores or establishing scale
factors.  Breaking down metrics to be expressed in this type of
nondimensional form has been a longtime stalwart of supporting
aerospace engineering research, where oftentimes theorists raised on
entirely different unit systems could compare performance based on
dimensionless parameters.
\par \\

\par The only task remaining
to form a composite score is choosing the weights to assign to each
performance metric.  The scoring method works best when all of the
weights are normalized.
\par \\

\par For this project, we
will perform an example preliminary design tradeoff study focusing on
the transportation system used to distribute goods to the population
at large.
\par \\

\par The optimization is
performed using a transportation model that optimizes delivery
schedules through a series of equidistant nodes.  The nodes are
specialized in producing a particular resource, which needs to be
distributed to the other nodes that don\verb|'|t have that resource.  A
common distribution paradigm is to have a large hub that collects all
of the resources, and then distributes the complete package to the
destination nodes.  This works well for relatively small nodes, for
example, distributing goods from a city (hub) to its surrounding
suburbs.  However, as the relative sizes of the nodes increase to the
point where adjacent nodes are peers, a different approach may be
warranted.
\par \\

\par The optimization
problem used is a mixed integer / linear program that takes several
input parameters characterizing the transportation network topology
and demand levels, and outputs an optimal schedule of flights.  We
will model our demand in terms of unique resources generated at a
particular node that must be distributed to all of the other nodes in
the system proportional to their population.  The problem was
originally designed for moving passengers through the airliners, thus
the passenger/aircraft terminology.  However, the same model could
apply just as well to moving freight through a network served by a
fleet of cargo vehicles.  

\par \\

\par As a simplification, we
will wrap up all of the user requirements declared in the
specifications into a unit package.  Therefore, every unit that makes
it through the transportation network will satisfy part of the
requirement for one individual in the system.
\par \\

\subsection*{Design / Decision Variables}
\subsubsection*{System Wide Measures of Effectiveness}
\par In general, the
complete city system can only improve properly if we choose the right
performance metrics to judge it by.  An optimization function that
optimizes the wrong metric will certainly cut you short of fulfilling
your goals.  For a city, the metrics we would want to track include:
\begin{itemize}
	\item \par Resource
	production / consumption ratio per cell.  An effective system would
	need to be efficient at doing a lot with the resources it has
	available to consume.  The emphasis should not be merely on
	stinginess with resources, because that can only cause stagnation.
	\item \par Transportation
	overhead -- Establish metrics to track the ratio of resources
	spent on the connective infrastructure compared to the nodes and
	activities it actually supports.  Of course, this also needs to be
	balanced with the need for growth and interconnectivity, so it
	should be considered secondary to productivity.
	\item \par Sustainability --
	The environment is usually the first to give resources or absorb
	waste when they are not serviceable elsewhere.  However, it is often
	not well known what the capacity of the environment to perform
	restorative reactions on waste resources to turn them back into
	useful resources.  The burden should be placed on the industries who
	exercise the environment the most to prove what its capacity is, and
	to achieve a suitable equilibrium.
	\item \par Quality of life --
	This can be measured by tracking the rate of failed reactions
	scheduled by the population to maintain their desired standard of
	living.  Of course, this is dependent upon how high that initial
	standard is set.  The only qualification for this model is to
	attempt to keep the quality from dropping below former levels.
\end{itemize}
\subsubsection*{Transportation System Preliminary Design Input
Parameters}
\par Define a distribution
system topology.  All nodes will be fully connected, but have
different hub/node size ratio.  What characterizes the difference
between hubs and ordinary nodes?  Hubs will have higher transit
demand levels as well as larger throughput limitations.
\par Number of people per
node ratio.  For the same total population, is it better to have them
distributed across several nodes, or occupy relatively few.  This
will likely be dependent on throughput limitations.
\par Population / number of
transport vehicle ratio.  For the same total population, is it better
to have fewer vehicles working complex routes, or many vehicles
working in parallel.
\subsubsection*{Transportation System Measures of Effectiveness
for Tradeoff Analysis}
\par The following criteria
form the core of the multi-criteria optimization performed for
tradeoff studies.
\begin{itemize}
	\item \par Maximize profit of
	running the system, represented by the total freight revenues less
	the total cost of operating the fleet of vehicles.  Revenue is
	generated by sending a unit of cargo to its destination.  A flat
	cost characterizes the expenses of each segment that the cargo
	haulers travel.  Plus, another flat cost characterizes daily
	maintenance expenses for having the vehicle in operation, to
	encourage the schedule to use fewer vehicles if possible.
	\item \par Maximize the
	coverage \& service of the system (minimize the number of
	unserved people).  Usually it\verb|'|s unprofitable to transport the last
	few units of cargo left at a node for the day, since they don\verb|'|t fill
	up the cargo holds enough to offset the fixed cost of the journey. 
	Minimizing this criteria attempts to serve all of these \verb|"|leftover\verb|"|
	bits at an operating loss if necessary.
	\item \par Minimize the
	deviation from an arbitrary desired fleet size.  A somewhat
	artificial metric, this criteria attempts to find a solution using a
	specific number of vehicles.  Often, the solution would require more
	vehicles than you may have in operation, and you would want to avoid
	temporarily leasing if possible, even if it affects the other
	optimization criteria.  On the other hand, the profit optimal
	solution may require less vehicles than you have in your fleet, but
	union labor mandates or other reasons may drive you to want to use
	those vehicles anyway without giving them a throwaway schedule.
\end{itemize}
\subsection*{Optimization Problem Formulation}
\par A computer script in
PERL generates the optimization problem and performs the
multi-criteria optimization runs to populate trade study curves.  The
source is listed in appendix A, and an example of its output is
listed in appendix B.  The model is written in the LINDO-esque
lp\_solve model format, but is then converted to the industry-standard
.mps format so just about any MIP solver can tackle it.  However, the
formatting of the variable names is tuned to accept the input format
of GNU glpk, the particular MIP solver used.
\subsection*{Pareto Optimal Solution Space}
\par We start by optimizing
for the minimum deviation from the desired fleet size.  The desired
fleet size is set pretty low, to 2, in order to get several points. 
The optimal fleet size given by optimizing most of the other metrics
is 6, so by relaxing the deviation from desired fleet size
constraint, we can get a feel for the pareto optimal curves.
\par \\

\par Allowing the deviation
to increase allows us to serve more customers, until all of them have
been accounted for.  This looks fairly linear now due to the small
number of nodes and aircraft involved.
\par 
\par Profit also increases
as we are allowed to utilize more vehicles:
\par 
\par \\

\par \\

\par Finally, we see that we
can increase profit margins by serving less people at a loss.
\par 
\par \\

\par \\

\par \\

\section*{Verification Test Plans}
\par Verification testing of
the archology simulation engine would consist of running through a
series of test cases presented in a test package.  Testing will
likely occur in phases, each which primarily concentrate first on
testing pieces of the core discrete event simulation building blocks
defined in the GeneralClasses object model diagram, and then on
testing the integrated interactions of scenarios built using those
classe, broken down as follows:
\begin{enumerate}
	\item \par The ability of the
	program to set up scenarios using the basic building blocks of
	units, partitioning them into smaller sub-units, each containing
	resources.
	\item \par The ability for
	units to exchange resources based on processing transaction events
	from the event queue.
	\item \par The ability for
	units to internally convert resources into other resources based on
	processing reaction events from the event queue.
	\item \par The placement of
	the transportation network to apply constraints on the connectivity
	of the units.  The transportation links should also be represented
	as units, so that they may consume resources themselves in the
	course of delivering their cargo.
	\item \par The successful
	execution of a simple example scenario.
\end{enumerate}
\par \\

\subsection*{Simulation Requirements Verification}
\begin{enumerate}
	\item \par {\bf Insert
	scenarios as inputs}
\end{enumerate}
\par Simulation
must read input files and populate data structure.  Provide printout
mechanism to dump state of data structure for verification of the
following capabilities:
\par \\

\begin{enumerate}
	\begin{enumerate}
		\item \par {\bf Numbers of
		units involved (people, transportation mechanisms, industrial
		entities, etc.)}
	\end{enumerate}
\end{enumerate}
\par Unit
test scenarios:
\begin{itemize}
	\item \par Create two peer
	units with transportation connector unit between them
	\item \par Create several
	nested subunits within a superunit.  This is illustrated in the Figure 4: CellTypes OMD
	diagram.
\end{itemize}
\par \\

\begin{enumerate}
	\begin{enumerate}
		\item \par {\bf Available
		resources from environment, initial conditions}
	\end{enumerate}
\end{enumerate}
\par Unit
test scenarios:  (refer to Figure 9: ResourceTest)
\begin{itemize}
	\item \par Create two
	different resources inside a unit
	\item \par Create \&
	verify two different resource quantities in a unit and a nested
	subunit
	\item \par Place maximum
	resource capacity constraints on a unit
	\item \par Create an
	environment unit, which can optionally act as an unlimited source
	and sink for various resources.
\end{itemize}
\par \\

\par 

\par {\bf Figure 9: ResourceTest}
\par \\

\par \\

\begin{enumerate}
	\begin{enumerate}
		\item \par {\bf Resource
		conversion rates, schedules, functions}
	\end{enumerate}
\end{enumerate}
\par Event
queue test scenarios:
\begin{itemize}
	\item \par Process resource
	conversion event within a unit to transform a quantity of resource
	into an equivalent quantity of waste.  See Figure 7: CombustionReaction OMD
	for an example.
	\item \par Process a
	push-based resource conversion event, where a multitude of inputs
	are converted to a multitude of outputs at the specified conversion
	ratio until one or more of the input resources are exhausted.
	\item \par Process a
	pull-based resource conversion event, where a multitude of inputs
	are converted to a multitude of outputs at the specified conversion
	ratio until either: 1) the requested output quantity is achieved, or
	2) one or more of the input quantities is exhausted, resulting in a
	lower yield than requested.
	\item \par Process a unit
	transaction event, in which a specified quantity of a resource is
	transferred from one unit to another unit to which there is
	connectivity through the transportation network.  The total quantity
	of resource in the system must be conserved.  See Figure 10: TransactionTest
	below:
\end{itemize}
\par \\

\par 

\par {\bf Figure 10:
TransactionTest}
\par \\

\begin{itemize}
	\item \par Test planning
	function events, which monitor the internal resource state of a unit
	and schedule more resource conversion events or transaction events
	on the queue at regular intervals and based on triggers
\end{itemize}
\par \\

\begin{enumerate}
	\item \par {\bf Simulation
	execution - model resource consumption/production rates, providing
	estimates on actual performance (pending validation of model)}
\end{enumerate}
\par After
individual unit tests \& operations have been verified, attempt to
load and run a simple but complete simulation scenario.  Given inputs
of a unit topology, initial resource distribution, and a queue of
events, verify that simulation ends in the correct final state.  See
Figure 11: ScenarioTest
\par \\

\par 

\par {\bf Figure 11: ScenarioTest}
\par \\

\begin{enumerate}
	\item \par {\bf Output metrics
	defined and calculated}
\end{enumerate}
\par Simulation
engine must have a logging and output mechanism.  Logging events
consist of polling functions that sit on the event queue, passively
poll the state of the system when executed, and log the data to a
file.  The logging functions should not affect the state of the
simulation in any way during the course of their execution.
\par \\

\begin{enumerate}
	\begin{enumerate}
		\item \par {\bf Qualitative
		measures of performance}
	\end{enumerate}
\end{enumerate}
\par As
this simulation primarily performs counting, most of the metrics will
be quantitative.  However, some qualitative metrics gathered could
include:
\begin{itemize}
	\item \par Error flag.  If a
	function within the simulation throws an exception, the entire
	simulation run should be marked as tainted.  This flag could also be
	raised when certain preconditions fail, for example, if a unit
	somehow ends up with a negative quantity of resources.  This type of
	situation could potentially allow the simulation to continue
	running, without any indication an error had occurred.
\end{itemize}
\par \\

\begin{enumerate}
	\begin{enumerate}
		\item \par {\bf Quantitative
		measures of performance}
	\end{enumerate}
\end{enumerate}
\par Most
metrics gathered by the logging functions would take snapshots of:
\begin{itemize}
	\item \par The state and
	topology of the unit mesh
	\item \par The amount of
	resources in each unit
	\item \par The total amount
	of resources that has been transferred over a transportation link
	\item \par Deficiency reports
	on amounts of resources that have been ``pulled'' from a
	unit, but upstream nodes were not able to provide enough resources.
	\item \par Congestion reports
	on amounts of resources that were unable to be ``pushed''
	to downstream nodes without violating their maximum resource
	capacity constraints.
\end{itemize}
\par \\

\begin{enumerate}
	\begin{enumerate}
		\item \par {\bf Allow
		possibility for formulating optimization problems to aid in
		benefits analysis \& decision-making in arcology design.}
	\end{enumerate}
\end{enumerate}
\par Optimization
can take place in the planning function events that schedule and
place new events on the simulation event queue.  While the algorithm
can vary, we can test the ability for the planning function event to
affect the scheduling of future events.  The planning functions must
have the ability to:
\begin{itemize}
	\item \par Query the event
	queue for future scheduled events
	\item \par Cancel an event in
	the event queue, but only if the event occurs in the future.  It
	cannot cancel events that have already been executed.
	\item \par Place new events
	on the event queue at an arbitrary future time.
\end{itemize}
\par \\

\begin{enumerate}
	\item \par {\bf Significant
	events (to be defined by modeling use case scenario case studies)
	should be modelable by scenario architecture -- important
	activities that have impact on performance measures should not be
	ignored.  Should provide at least approximate methods of simulating
	effects that are difficult to model.}
\end{enumerate}
\par This
requirement affects the ability of the simulation core engine to
assemble itself with enough complexity to create a valid model of the
system, and is thus in part tied to the validation of the engine.  At
a minimum, the simple building blocks of units, transportation
connectivity, resources, conversion events, and transaction events
must be flexible enough to be composed into more sophisticated
structures with complex behaviors
\par \\

\par For
example, let us attempt to model the transportation of a resource
from unit A to unit B.  In the simplest case, they have a
transportation network link between them, and a resource transaction
event fires to transfer the specified quantity of resource from A to
B.  End of story.
\par \\

\par In
a more complicated scenario, we might want to model different
mechanisms to transport those resources from A to B, so we'll
use the basic building blocks to model the resources being loaded up,
say, into a series of truck units.  The truck units would start with
a transportation connectivity link to unit A, and a quantity of
resources will be loaded up to the truck's capacity.  The truck
would then disembark, firing a reaction that disconnects its
transportation link to A, and schedules a new transportation
connectivity link to B at its arrival time.  It would also trigger a
resource consumption event that would allow it to burn fuel enroute
as a function of cargo weight and distance between A and B.
\par \\

\par The
simulation core building block units would need to demonstrate this
sort of composability to pass this verification test.
\par \\

\begin{enumerate}
	\item \par {\bf Specification
	of accuracy in estimates \& predictions.  (Goal of \verb|~|20\%)}
\end{enumerate}
\par This
is related to an output metric.  The simulation engine would need a
self-monitoring performance metric to keep track of the buildup of
standard uncertainty errors to estimate a system-wide predictability
error.  As the simulation proceeds with its projections, the errors
will compound to a point where it is not worthwhile for the
simulation to proceed much farther.
\par \\

\subsection*{Simulation Specification Verification}
\begin{enumerate}
	\item \par {\bf Ability to
	model baseline scenario on the order of magnitude of \verb|~|1010
	units processing a 24 hour period of events on currently available
	computer hardware.}
\end{enumerate}
\par An
example scenario of such proportions needs to be created and loaded
into the simulation engine without exceeding the memory or storage
limitations of the target computer platform.
\par \\

\begin{enumerate}
	\item \par {\bf Attain a
	reasonable execution time of less than 10 hours to process the
	scheduled event queue such that the baseline scenario, assuming \verb|~|100
	events per unit during the 24 hour period.}
\end{enumerate}
\par The
example scenario needs to be created with the appropriate number of
events of ``average'' complexity.  

\par \\

\begin{enumerate}
	\item \par Achieve real time
	or faster simulation speed of the baseline scenario.
\end{enumerate}
\par \\

\section*{Validation Evaluation Plans}
\par Validation of the
archology simulation tool occurs when it can be used to build models
of archology systems.  These models would represent some function
performed in a real life habitat system, and its behavior and results
would in turn need to be validated against performance metrics
collected from the actual system it represents.  Since we cannot
directly assess the sim tool's ability to create generic
models, the validation evaluations will focus on a range of sample
model calibration and validation scenarios.  We can measure the
performance of the models by comparing them with real world
performance.  If the models can prove their viability, then the
capability of the underlying simulation to build models will have
been intrinsically validated.
\par \\

\par Since the simulation
model essentially deals with discerning large scale effects based on
the accounting and execution of small scale actions, we will need to
validate models on two levels: macro and micro.  

\subsection*{Macro Level Validation Scenarios}
\par The macro scenarios
focus on evaluating the model's predictions of aggregate
changes to the system, e.g., what happens to city-wide energy
utilization when the population doubles.  At first glance, you might
expect the energy use to double.  However, if the increase is due to
the size of the average household increasing, then things like
lighting and air conditioning would be shared among individuals,
implying that the increase would be less than double.  This process
turns out to be as much a calibration step as a validation step.
\par \\

\par To go about validating
this scenario, you would first want to create a model that measures
energy use as a function of household size.  Then, to double the
population, create a new distribution of household sizes (accounting
for both the creation of new houses as well as the increases in
existing households).  Using the earlier function, we should be able
to estimate the new total energy usage based upon the distribution of
household sizes, and summing up the energy used per household.
\par \\

\par Live historical data
containing this information is available in the US census.  It will
be a stretch, since the census is only taken every decade.  Energy
utilization is also dependent upon a wide variety of other factors,
such as local fluctuations in the cost of power, the development \&
use of technologies such as efficient fluorescent light bulbs, and of
course the proliferation of new power-hungry devices such as personal
computers and microwaves.  Hence the necessity for the calibration
portion of the validation.  Calibration for this example scenario can
occur by using a ``control group'' of cities whose
populations and distributions of household sizes did not change at
all.  This would allow us to add a systematic increase/decrease
factor to each individual's energy utilization before factoring
in the household growth.
\par \\

\par After the model is
properly calibrated to agree with a group of baseline cities, we can
assess its prediction accuracy by giving it energy and census data
for one year, having it project the energy usage a decade later based
on that census data, and comparing that to the actual.  The
percentage error over a range of different cities would give us some
evaluation of the level of confidence we can place in its
projections.
\subsection*{Micro Level Validation Scenarios}
\par The micro scenarios, on
the other hand, focus on how well the model can handle the accounting
of changes on the individual level, to determine if different
operations make sense.  Listed here are some sample scenarios that
should be modelable and give predictable, expected results:
\begin{itemize}
	\item \par Suppose an
	individual installs their own power generator (e.g. solar panel) and
	hooks it into their electrical grid.  Their power consumption from
	the public utility should go down.  They may even be able to pump
	some power back into the public grid.
	\item \par Another individual
	does not have a kitchen, and must drive to the nearest food store to
	``eat-out'' every time they need to contend with a hunger
	event.  Their extra fuel consumption should show up on their usage
	metric.
	\item \par A commuter in the
	suburbs moves downtown and begins using public transportation.  The
	impact to their finances, commute time, fuel consumption, trips to
	the grocery store, and remaining leisure time should show up on
	their monitored metrics.
\end{itemize}
\section*{Bibliography
\& References}
\par \\

\par Soleri,
Paolo; {\it Arcology: The City in the Image of Man}; Bridgewood
Press 1999 

\par \\

\par Arcology.com:
Architecture + Ecology
\par \underline{http://www.arcology.com/}
\par \\

\par Arcosanti:
A Prototype Arcology 

\par \underline{http://www.arcosanti.org/}
\par \\

\par Francis
Frick; {\it A Seaside Arcology for Southern China}; University of
Hong Kong 2000
\par http://www.cityfarmer.org/frick.html

\par \\

\par Carfree
Cities
\par \underline{http://www.carfree.com/}
\par \\

\par Ilogix
Rhapsody in C++ 

\par \underline{http://www.ilogix.com/products/rhapsody/rhap\_incplus.cfm}
\par \\

\par Gigabyte\verb|'|s
SimCity 2000 Arcology page
\par \underline{http://www.angelfire.com/hi/gigabyte2/arco.html}
\par \\

\par SimCity
3000 Plus: The First Rowan University SC3000 Site
\par \underline{http://users.rowan.edu/\verb|~|cull2722/simcity3000.html}
\par \\

\par The
Sims Online
\par \underline{http://www.ea.com/eagames/official/thesimsonline/home/index.jsp?}
\par \\

\par Energy
Action
\par \underline{http://www.nef1.org/}
\par \\

\par International
Energy Annual Population Table
\par \underline{http://www.eia.doe.gov/emeu/iea/tableb1.html}
\par \\

\par DOA
Energy Information Administration
\par \underline{http://www.eia.doe.gov/}
\par \\

\par Artemis
Project: Reduction of Imported Consumables for Life Support
Maintenance
\par \underline{http://www.asi.org/adb/04/03/05/consumable-reduction.html}
\par \\

\section*{\\\\
}
\end{document}
