The Computational Nuclear Engineering Research Group (CNERG) of the University
-of Wisconsin-Madison (UW) has been developing a next generation nuclear fuel
-cycle simulation platform called Cyclus whose genesis was driven by a variety
-of gaps seen in previous fuel cycle simulation efforts. Three major design and
-development philosophies encompass the current fleet of fuel cycle simulators:
-
-
-
A desire for usability, thus developing a tool which begins with a simple
-model in a visual development environment that aims to provide an intuitive
-user interface (e.g. DYMOND, DANESS, VISION)
-
A desire for rapid prototyping, thus developing a tool which begins with
-simple models in a scripting language that allows for quick answers to early
-problems (e.g. CAFCA, GENIUS v1)
-
A desire for detail/fidelity, thus developing a tool with an ad-hoc
-combination of existing complex analysis tools (e.g. COSI)
-
-
-
Experience has demonstrated that each of these philosophies are hindered from
-simulating interesting problems due to complexity limits. In most cases this
-complexity constrains first the usability of the tool followed by its
-extendability due to increasingly convoluted dependencies. The final victim is
-performance, as the ability to quickly solve simple problems is lost to the
-desire to solve more complex ones.
-
In addition to these technical challenges, there is also an institutional
-challenge. A combination of closed development platforms and closed
-development processes has made it difficult for an individual researcher to
-incorporate their ideas into a fuel cycle systems analysis. The ability to
-combine existing systems simulation tools with data about new facilities or
-fuel cycle concepts is so challenging that many researchers either choose to
-avoid systems analysis altogether or to write their own simplified tool
-(usually in category 2 above). These new, special purpose fuel cycle
-simulation tools involve a duplication of effort and generally lack any robust
-benchmarking.
-
Each of these approaches lacks a design basis in computational science and
-software development that can deliver the stated desired attributes of the
-final software product:
-
-
-
usability – accommodating a wide range of user sophistication
-
performance – solving simple problems in interactive time scales
-
fidelity – accommodating many levels of detail/fidelity, commensurate with a range of user sophistication
-
-
-
A complete nuclear fuel cycle simulator requires modeling efforts in a wide
-variety of physical and social science domains. This places a premium on a
-software development process that will facilitate fluid collaboration among a
-large group of geographically dispersed developers. With this constraint in
-mind, a number of software development practices can be identified as highly
-valuable for this effort:
-
-
-
openness – the process should have low institutional & technical obstacles to collaboration
-
modularity – a particular approach to modularity should be pursued to allow the core infrastructure to be independent of proprietary and/or sensitive data and/or models
-
extensibility – attention to both robustness and flexibility allows for myriad potential developer extensions
Cyclus will be a nuclear fuel cycle systems analysis software platform that
-encourages collaboration among a diverse set of researchers. Emphasis will be
-placed on both ease of collaboration through modularity as well as ubiquity in
-order to analyze a significant number of possible future fuel cycle scenarios
-succinctly and consistently.
In order to accomplish this mission, the Cyclus team has developed a vision
-for the development of a next generation fuel cycle simulator that includes
-elements of software architecture, software development process and
-fundamental design paradigms.
As indicated above, the software architecture and accompanying development
-process are critical to a simultaneously robust and flexible analysis platform.
The Cyclus development framework employs a modern, open source philosophy
-that ensures transparency, attracts contributions from a varied community of
-collaborators, and guarantees institution-independent access to all potential
-users. In this development path, a public source code repository provides
-unhindered access to the fundamental simulation framework and basic fuel
-process models volunteered by developers. Granting unfettered access only to
-the Cyclus engine allows for compartmentalization of the code and its input
-data. Thus, secure and proprietary model developers can be similarly encouraged
-to utilize the Cyclus framework. This modern development model passively
-distributes specialized content to interested research groups, and facilitates
-parallel model development efforts by institutions with complimentary goals.
-The transparency inherent in this type of open source development path also
-facilitates code review by exposing available content to verification and
-validation by collaborators with diverse areas of specialization and levels of
-expertise.
-
Another aspect of this development process is a preference for open source
-third party libraries where additional functionality is necessary and available
-from such libraries. This includes basic infrastructure such as file
-input/output, as well as model-specific capabilities like integer programming
-for network flow optimization.
Dynamically-loadable modules are the primary mechanism for extending Cyclus
-with new underlying models. The primary benefit of this approach is
-encapsulation: the trunk of the code is completely independent of the
-individual models and all customization and extension is implemented only in
-the loadable module. A secondary benefit of this encapsulation is the ability
-for contributors to choose different distribution and licensing strategies for
-their contributions. Finally, this strategy allows an individual developers
-to explore different levels of complexity within their modules, including
-wrapping other simulation tools as loadable modules for Cyclus.
Because of the wide array of use cases for Cyclus, flexibility in the user
-interface is important to provide different kinds of users with different
-experiences. This is true for input generation as well as output
-visualization. A variety of graphical user interface modes have been designed
-and will be implemented in parallel with the development of underlying modules.
-The graphical interface should be extensible by loadable modules in the same
-way as the core code to provide developers the same flexibility in managing
-their input as they have in implementing their models. Output visualization is
-also important - the discrete facility/discrete material paradigm generates a
-large volume of small data that needs to be aggregated in various ways to
-provide context to a variety of users.
The modeling paradigm adopted by Cyclus includes a number of deeply embedded
-fundamental concepts. These basic design choices comprise the bedrock on which
-most future design choices are made. The Cyclus team recognizes the
-accompanying inflexibility to the code and therefore does not anticipate that
-these attributes will change.
The modeling infrastructure is designed such that every facility in a global
-nuclear fuel cycle is treated individually. While modeling options will exist
-to allow collective action, this will be as a special case of the individual
-facility basis. Each facility will have two fundamental tasks: to transact
-nuclear material with other facilities and to transform that nuclear material
-from an input form to an output form. These materials will be modeled as
-discrete objects that exist for a finite time and whose composition and
-transaction history is logged throughout the simulation.
The transaction of nuclear materials will take place in “markets” that act as
-brokers to match a set of requests for material with a set of offers for that
-material. A variety of market models (see Vision: Software Architecture) will
-be available to perform this broker role, but each market will act
-independently of other markets. Markets will used to model a variety of
-decision making behaviors, not restricted to behaviors that simulate economic
-activity. Once the requests and offers have been matched, the facilities will
-exchange material objects.
Every discrete facility in Cyclus is owned by an institution that operates in
-a geographic region. An institution can be used to represent any entity that
-may own and operate a facility such as a private corporation, a government
-agency, or a non-governmental agency, among others. A region can be used to
-represent any geographic area, typically a politically relevant area such a
-sub-national region (e.g. a U.S. State), a nation-state, or a super-national
-region (e.g. the E.U.). While some performance parameters of the facility may
-depend on its institutional ownership or geographical location, the more
-important use of this capability is to control the way in which a facility
-engages in a market for trade of nuclear material based on by whom it is owned
-and/or operated.
While the market models that form the basis of material transactions represent
-largely social constructs, there is an initial desire to minimize the direct
-simulation of institutional decision making to seek optimal solutions.
-Instead, the fundamental approach is to drive a single simulation with a large
-multi-dimensional data set and then allow modern optimization technology to
-seek globally optimal solutions based on global objective functions. Since
-institutional decision making tends to seek an optimal solution only for the
-actor making that decision (local optimization), it may not lead to an outcome
-that optimizes for the largest population of stakeholders.
A number of research areas related to Cyclus have already been identified.
-In some cases, there is a lead institution already engaged in such research, or
-one or more institutions who have expressed interest:
-
-
-
Cyclus core infrastructure development lead: UW-Madison
-
Market model development interest: UW-Madison, UT-Austin
-
Region model development and deployment scenarios interest: Idaho
-
Reactor model development interest: UT-Austin
-
Separations model development
-
Geologic repository & waste form modeling lead: UW-Madison
-
Graphical interfaces for input and visualization interest: Utah
-
Social science to determine important metrics and measures interest: UW-Madison
-
Optimization and sensitivity infrastructure interest: NC State
-
-
-
\ No newline at end of file
diff --git a/Makefile b/Makefile
index 4b528d529..51f98e2af 100644
--- a/Makefile
+++ b/Makefile
@@ -39,7 +39,11 @@ help:
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
clean:
- -rm -rf $(BUILDDIR)/*.*
+ -rm -f $(BUILDDIR)/*.*
+ -rm -Rf $(BUILDDIR)/usrdoc
+ -rm -Rf $(BUILDDIR)/devdoc
+ -rm -Rf $(BUILDDIR)/basics
+ -rm -Rf $(BUILDDIR)/_*
html:
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)
diff --git a/_images/logo.png b/_images/logo.png
deleted file mode 100644
index a1227cbc4..000000000
Binary files a/_images/logo.png and /dev/null differ
diff --git a/_sources/CyclusIntroduction.txt b/_sources/CyclusIntroduction.txt
deleted file mode 100644
index aacdaa769..000000000
--- a/_sources/CyclusIntroduction.txt
+++ /dev/null
@@ -1,233 +0,0 @@
-.. summary Introduction to the Cyclus Fuel Cycle Simulator
-
-:version: Document v1.2 - 9/28/2011
-
-Introduction to the *Cyclus* Fuel Cycle Simulator
-=================================================
-
-
-The Computational Nuclear Engineering Research Group (CNERG) of the University
-of Wisconsin-Madison (UW) has been developing a next generation nuclear fuel
-cycle simulation platform called *Cyclus* whose genesis was driven by a variety
-of gaps seen in previous fuel cycle simulation efforts. Three major design and
-development philosophies encompass the current fleet of fuel cycle simulators:
-
- #. A desire for usability, thus developing a tool which begins with a simple
- model in a visual development environment that aims to provide an intuitive
- user interface (e.g. DYMOND, DANESS, VISION)
-
- #. A desire for rapid prototyping, thus developing a tool which begins with
- simple models in a scripting language that allows for quick answers to early
- problems (e.g. CAFCA, GENIUS v1)
-
- #. A desire for detail/fidelity, thus developing a tool with an ad-hoc
- combination of existing complex analysis tools (e.g. COSI)
-
-Experience has demonstrated that each of these philosophies are hindered from
-simulating interesting problems due to complexity limits. In most cases this
-complexity constrains first the usability of the tool followed by its
-extendability due to increasingly convoluted dependencies. The final victim is
-performance, as the ability to quickly solve simple problems is lost to the
-desire to solve more complex ones.
-
-In addition to these technical challenges, there is also an institutional
-challenge. A combination of closed development platforms and closed
-development processes has made it difficult for an individual researcher to
-incorporate their ideas into a fuel cycle systems analysis. The ability to
-combine existing systems simulation tools with data about new facilities or
-fuel cycle concepts is so challenging that many researchers either choose to
-avoid systems analysis altogether or to write their own simplified tool
-(usually in category 2 above). These new, special purpose fuel cycle
-simulation tools involve a duplication of effort and generally lack any robust
-benchmarking.
-
-Each of these approaches lacks a design basis in computational science and
-software development that can deliver the stated desired attributes of the
-final software product:
-
- * usability -- accommodating a wide range of user sophistication
- * performance -- solving simple problems in interactive time scales
- * fidelity -- accommodating many levels of detail/fidelity, commensurate with a range of user sophistication
-
-A complete nuclear fuel cycle simulator requires modeling efforts in a wide
-variety of physical and social science domains. This places a premium on a
-software development process that will facilitate fluid collaboration among a
-large group of geographically dispersed developers. With this constraint in
-mind, a number of software development practices can be identified as highly
-valuable for this effort:
-
- * openness -- the process should have low institutional & technical obstacles to collaboration
- * modularity -- a particular approach to modularity should be pursued to allow the core infrastructure to be independent of proprietary and/or sensitive data and/or models
- * extensibility -- attention to both robustness and flexibility allows for myriad potential developer extensions
-
-Mission
--------
-
-*Cyclus* will be a nuclear fuel cycle systems analysis software platform that
-encourages collaboration among a diverse set of researchers. Emphasis will be
-placed on both ease of collaboration through modularity as well as ubiquity in
-order to analyze a significant number of possible future fuel cycle scenarios
-succinctly and consistently.
-
-Vision
-------
-
-In order to accomplish this mission, the *Cyclus* team has developed a vision
-for the development of a next generation fuel cycle simulator that includes
-elements of software architecture, software development process and
-fundamental design paradigms.
-
-Current Status
---------------
-
-*Cyclus* is being developed in an open environment. For the current status of *Cyclus*, visit http://cyclus.github.com.
-
-Software Process & Architecture
-+++++++++++++++++++++++++++++++
-
-As indicated above, the software architecture and accompanying development
-process are critical to a simultaneously robust and flexible analysis platform.
-
-Open Source Development Process
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The *Cyclus* development framework employs a modern, open source philosophy
-that ensures transparency, attracts contributions from a varied community of
-collaborators, and guarantees institution-independent access to all potential
-users. In this development path, a public source code repository provides
-unhindered access to the fundamental simulation framework and basic fuel
-process models volunteered by developers. Granting unfettered access only to
-the *Cyclus* engine allows for compartmentalization of the code and its input
-data. Thus, secure and proprietary model developers can be similarly encouraged
-to utilize the *Cyclus* framework. This modern development model passively
-distributes specialized content to interested research groups, and facilitates
-parallel model development efforts by institutions with complimentary goals.
-The transparency inherent in this type of open source development path also
-facilitates code review by exposing available content to verification and
-validation by collaborators with diverse areas of specialization and levels of
-expertise.
-
-Another aspect of this development process is a preference for open source
-third party libraries where additional functionality is necessary and available
-from such libraries. This includes basic infrastructure such as file
-input/output, as well as model-specific capabilities like integer programming
-for network flow optimization.
-
-Dynamically-loadable Modules
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Dynamically-loadable modules are the primary mechanism for extending *Cyclus*
-with new underlying models. The primary benefit of this approach is
-encapsulation: the trunk of the code is completely independent of the
-individual models and all customization and extension is implemented only in
-the loadable module. A secondary benefit of this encapsulation is the ability
-for contributors to choose different distribution and licensing strategies for
-their contributions. Finally, this strategy allows an individual developers
-to explore different levels of complexity within their modules, including
-wrapping other simulation tools as loadable modules for *Cyclus*.
-
-Use Cases & Visualization
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Because of the wide array of use cases for *Cyclus*, flexibility in the user
-interface is important to provide different kinds of users with different
-experiences. This is true for input generation as well as output
-visualization. A variety of graphical user interface modes have been designed
-and will be implemented in parallel with the development of underlying modules.
-The graphical interface should be extensible by loadable modules in the same
-way as the core code to provide developers the same flexibility in managing
-their input as they have in implementing their models. Output visualization is
-also important - the discrete facility/discrete material paradigm generates a
-large volume of small data that needs to be aggregated in various ways to
-provide context to a variety of users.
-
-Modeling Paradigm
-+++++++++++++++++
-
-The modeling paradigm adopted by *Cyclus* includes a number of deeply embedded
-fundamental concepts. These basic design choices comprise the bedrock on which
-most future design choices are made. The *Cyclus* team recognizes the
-accompanying inflexibility to the code and therefore does not anticipate that
-these attributes will change.
-
-Discrete Facility & Discrete Material Objects
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The modeling infrastructure is designed such that every facility in a global
-nuclear fuel cycle is treated individually. While modeling options will exist
-to allow collective action, this will be as a special case of the individual
-facility basis. Each facility will have two fundamental tasks: to transact
-nuclear material with other facilities and to transform that nuclear material
-from an input form to an output form. These materials will be modeled as
-discrete objects that exist for a finite time and whose composition and
-transaction history is logged throughout the simulation.
-
-Market-based Material Transactions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The transaction of nuclear materials will take place in "markets" that act as
-brokers to match a set of requests for material with a set of offers for that
-material. A variety of market models (see Vision: Software Architecture) will
-be available to perform this broker role, but each market will act
-independently of other markets. Markets will used to model a variety of
-decision making behaviors, not restricted to behaviors that simulate economic
-activity. Once the requests and offers have been matched, the facilities will
-exchange material objects.
-
-Region-Institution-Facility Hierarchy
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Every discrete facility in *Cyclus* is owned by an institution that operates in
-a geographic region. An institution can be used to represent any entity that
-may own and operate a facility such as a private corporation, a government
-agency, or a non-governmental agency, among others. A region can be used to
-represent any geographic area, typically a politically relevant area such a
-sub-national region (e.g. a U.S. State), a nation-state, or a super-national
-region (e.g. the E.U.). While some performance parameters of the facility may
-depend on its institutional ownership or geographical location, the more
-important use of this capability is to control the way in which a facility
-engages in a market for trade of nuclear material based on by whom it is owned
-and/or operated.
-
-Optimization and Sensitivity
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-While the market models that form the basis of material transactions represent
-largely social constructs, there is an initial desire to minimize the direct
-simulation of institutional decision making to seek optimal solutions.
-Instead, the fundamental approach is to drive a single simulation with a large
-multi-dimensional data set and then allow modern optimization technology to
-seek globally optimal solutions based on global objective functions. Since
-institutional decision making tends to seek an optimal solution only for the
-actor making that decision (local optimization), it may not lead to an outcome
-that optimizes for the largest population of stakeholders.
-
-Research Areas
---------------
-
-A number of research areas related to *Cyclus* have already been identified.
-In some cases, there is a lead institution already engaged in such research, or
-one or more institutions who have expressed interest:
-
- #. *Cyclus* core infrastructure development lead: UW-Madison
-
- #. Market model development interest: UW-Madison, UT-Austin
-
- #. Region model development and deployment scenarios interest: Idaho
-
- #. Reactor model development interest: UT-Austin
-
- #. Separations model development
-
- #. Geologic repository & waste form modeling lead: UW-Madison
-
- #. Graphical interfaces for input and visualization interest: Utah
-
- #. Social science to determine important metrics and measures interest: UW-Madison
-
- #. Optimization and sensitivity infrastructure interest: NC State
-
- #. Transportation
-
- #. Non-proliferation analysis interest: UW
-
diff --git a/_sources/basics/Decay.txt b/_sources/basics/Decay.txt
deleted file mode 100644
index bbf7a2a52..000000000
--- a/_sources/basics/Decay.txt
+++ /dev/null
@@ -1,128 +0,0 @@
-.. summary Documentation for the Cyclus Decay Method
-
-*NOTE:* This wiki page is currently a work in progress.
-
-Radioactive Decay in Cyclus
-===========================
-
-Radioactive decay of a group of isotopes over time can be described by the
-following first order differential equation:
-
-.. math::
-
- \frac{d}{dt}\mathbf{N(\mathit{t})}=\textrm{A}\: \mathbf{N(\mathit{t})}
-
-where the vector `N(t)` contains the number density of all the
-isotopes being considered at time `t`, and A is called the decay
-matrix. The solution to this differential equation can be expressed in terms
-of a matrix exponential:
-
-.. math::
-
- \mathbf{N(\mathit{to+\Delta t})}=e^{\Delta t \textrm{A}}\: \mathbf{N(\mathit{to})}
-
-The decay method currently implemented in *Cyclus* computes this matrix
-exponential solution at any given time using a series approximation known as
-the Uniformization Method. This implementation was written by Kerry Dunn, and
-is explained in more detail below.
-
-The Uniformization Method
--------------------------
-
-The Uniformization Method is essentially a modification of the truncated Taylor
-Series expansion of the matrix exponential solution, which can be described by
-the following summation:
-
-.. math::
-
- \mathbf{N(\mathit{to+\Delta t})}\approx \sum_{k=0}^{p}\frac{\left (\Delta t \right )^k}{k!}\: \textrm{A}^k\: \mathbf{N(\mathit{to})}
-
-The primary disadvantage of using this Taylor Series expansion to compute the
-matrix exponential solution is that it can be subject to cancellation error as
-a result of summing terms with alternating signs. These terms with alternating
-signs occur because the diagonal elements in the decay matrix that represent
-the decay constants are all negative. Therefore, in order to eliminate the
-potential for cancellation error, the decay matrix must be modified so that it
-no longer contains these negative elements. This modification process is known
-as the uniformization technique.
-
-The first step in applying the uniformization technique is to define
-`alpha` to be equal to the absolute value of the maximum diagonal
-element of `A`:
-
-.. math::
-
- \alpha=max_i\left | a_i_i \right |
-
-Then, given `alpha`, the next step is to redefine the matrix
-exponential solution using a different matrix `P`:
-
-.. math::
-
- \textrm{P}=\frac{1}{\alpha}\textrm{A}+\textrm{I}
-
-where I is the identity matrix. Note that `P` is completely non-negative, so a
-Taylor Series expansion of this matrix exponential is not subject to the same
-cancellation error that occurs with the original decay matrix. By replacing `A`
-with `P`, the matrix exponential solution can now be expressed by the following
-summation:
-
-.. math::
-
- \mathbf{N(\mathit{to+\Delta t})}=e^{-\alpha \Delta t}\: e^{\Delta t (\alpha \textrm{P})}\: \mathbf{N(\mathit{to})}\approx e^{-\alpha \Delta t}\sum_{k=0}^{p}\frac{\left (\Delta t \right )^k}{k!}\: (\alpha \textrm{P})^k\: \mathbf{N(\mathit{to})}
-
-Note that this modified Taylor Series expansion can also be expressed in terms
-of the original matrix A by substituting the definition for `P`:
-
-.. math::
-
- \mathbf{N(\mathit{to+\Delta t})}\approx e^{-\alpha\Delta t}\sum_{k=0}^{p}\frac{\left (\Delta t \right )^k}{k!}\: (\textrm{A}+\alpha \textrm{I})^k\: \mathbf{N(\mathit{to})}
-
-
-Implementation in Cyclus
-------------------------
-
-Adding New Isotopes
--------------------
-
-Limitations
-+++++++++++
-
-When adding a new isotope, the most important thing to take into account is its
-half-life or decay constant. The isotope with the smallest half-life, or
-largest decay constant, will be the limiting factor for the time scale over
-which *Cyclus* can decay _all_ materials in one step. This occurs because the
-Uniformization Method requires the computation of an exponential term, which is
-limited by the size of a long double on the system being used to run *Cyclus*.
-To determine the maximum time scale that will be valid for a particular group
-of isotopes, the following equation can be used:
-
-.. math::
-
- {t_{max} = \frac{ln(\textrm{LDBL\_MAX})}{min(\lambda)}}
-
-where `LDBL_MAX` is the size of a long double and :math:`\lambda` is the
-largest decay constant of the group of isotopes being considered.
-
-As an example, suppose that the isotope with the smallest half-life being
-considered is Cm-232. This particular isotope has a decay constant of 1.5532
-nuclei per year. If the size of a long double is limited to LDBL_MAX =
-1.18973e+4932, then all materials can only be decayed for a maximum of 7311
-years. Adding any isotopes with a half-life smaller than Cm-232 would result
-in an even lower maximum time scale.
-
-References
-----------
-
- #. Cleve Moler and Charles van Loan, "Nineteen Dubious Ways to Compute the
- Exponential of a Matrix, Twenty-Five Years Later," *SIAM Review*, *45*,
- 3-49 (2003)
-
- #. Erwin Muller, Frederik Reitsma and Paulus P. Kruger, "A Stable Nuclide
- Transmutation Procedure Free of Numerical Roundoff," *PHYSOR 2006*, September
- 10-14, Vancouver, Canada (2006)
-
- #. R. B. Sidje and W. J. Stewart, "A numerical study of large sparse matrix
- exponentials arising in Markov chains," *Computational Statistics & Data
- Analysis*, *29*, 345-368 (1999)
-
diff --git a/_sources/basics/style_guide.txt b/_sources/basics/style_guide.txt
deleted file mode 100644
index f749d3e73..000000000
--- a/_sources/basics/style_guide.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-
-.. summary Style Guidelines for cyclus developers
-
-Style Guidelines for Developers
-===============================
-
-The purpose of this page is to introduce some general style guidelines to help
-with readability, maintainability and extensibility of the cyclus code base.
-
-
-Class File Organization
------------------------
-
-
-Class header files should be organized in the following order:
-
- * private
-
- * methods
-
- * virtual
- * static
- * non-static
-
- * data members
-
- * static
- * non-static
-
- * protected (in same order as above)
- * public (in same order as above)
-
-Within each section, methods should be grouped and ordered in logical
-categories in the following order:
-
- * "life-cycle" methods first (e.g. constructors, destructors, initializers)
- * operators (e.g. equivalence, assignment)
- * data access methods
- * other base-class-specific categories
- * other class-specific categories
-
-The order of method definition in the implementation file should be consistent
-with the order of declaration in the header file.
-
-Code Formatting
----------------
-
-Line lengths, tab spacing, and bracket placement will conform to the google c++
-style standard as much as possible. This requires that all tabs be replaced by
-spaces, and that an indentation is equal to two spaces. Further information on
-this style standard can be found in the `Google Style Guide`_.
-
-Notable items:
-
- * no tabs - expand all tabs to 2 spaces.
-
- * enum items should be all caps
-
- * trailing underscores must be used with all class member variables
-
- * opening braces should be placed on the same line as function args: `ReturnType functionName(Arg1Type arg_name) {`
-
- * loop and branching statements should use the opening and closing braces (i.e. not like this: `if (true) long_statement;`)
-
-.. _`Google Style Guide`: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
-
diff --git a/_sources/devdoc/CyclusStyleGuidelines.txt b/_sources/devdoc/CyclusStyleGuidelines.txt
deleted file mode 100644
index 35bb8737d..000000000
--- a/_sources/devdoc/CyclusStyleGuidelines.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-.. summary Style Guidelines for cyclus development
-
-Cyclus Style Guidelines
-=======================
-
-The purpose of this page is to introduce some general style guidelines to help
-with readability, maintainability and extensibility of the cyclus code base.
-
-
-Class File Organization
------------------------
-
-Class header files should be organized in the following order:
-
- * private
-
- * methods
-
- * virtual
-
- * static
-
- * non-static
-
- * data members
-
- * static
-
- * non-static
-
- * protected (in same order as above)
-
- * public (in same order as above)
-
-Within each section, methods should be grouped and ordered in logical
-categories in the following order:
-
- * "life-cycle" methods first (e.g. constructors, destructors, initializers)
-
- * operators (e.g. equivalence, assignment)
-
- * data access methods
-
- * other base-class-specific categories
-
- * other class-specific categories
-
-The order of method definition in the implementation file should be consistent
-with the order of declaration in the header file.
-
-Code Formatting
----------------
-
-Line lengths, tab spacing, and bracket placement will conform to the google c++
-style standard as much as possible. This requires that all tabs be replaced by
-spaces, and that an indentation is equal to two spaces. Further information on
-this style standard can be found in the `Google Style Guide`_.
-
-.. _`Google Style Guide`: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
-
-Notable items:
-
- * no tabs - expand all tabs to 2 spaces.
-
- * enum items should be all caps
-
- * trailing underscores must be used with all class member variables
-
- * opening braces should be placed on the same line as function args:
- `ReturnType functionName(Arg1Type arg_name) {`
-
- * loop and branching statements should generally use the opening and closing
- braces (i.e. not like this: `if (true) long_statement;`)
-
diff --git a/_sources/main.txt b/_sources/main.txt
deleted file mode 100644
index 75b053546..000000000
--- a/_sources/main.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-
-Wiki Contents:
-
-.. toctree::
- :maxdepth: 2
-
- CyclusIntroduction
- CyclusStyleGuidelines
- Decay
-
-.. stuff not converted yet
-
- GettingAndBuildingCyclus
- ProgramFlowAndDataStructureOverview
- OutputDatabase
- UserDocumentation
- DevelopersDocumentation
-
-
- these are within developer doc
-
- * [CyclusStyleGuidelines Style Guidelines]
- * [GuidelinesForImplementingNewModels Guidelines for New Models]
- * [GuidelinesForImplementingNewFacilityModels Facility]
- * [GuidelinesForImplementingNewInstModels Inst]
- * [GuidelinesForImplementingNewRegionModels Region]
- * [GuidelinesForImplementingNewMarketModels Market]
-
- * Milestones
- * [MilestoneZero Basic Functionality]
- * [MilestoneNullSimulation 0: Null Simulation]
- * [MilestoneOneInpro 1: Inpro Simulation]
- * [MilestoneTwoNWTRB 2: NWTRB Simulations]
- * [MilestoneGenRepo 3: Generic Repository]
diff --git a/_sources/wiki/CyclusIntroduction.txt b/_sources/wiki/CyclusIntroduction.txt
deleted file mode 100644
index aacdaa769..000000000
--- a/_sources/wiki/CyclusIntroduction.txt
+++ /dev/null
@@ -1,233 +0,0 @@
-.. summary Introduction to the Cyclus Fuel Cycle Simulator
-
-:version: Document v1.2 - 9/28/2011
-
-Introduction to the *Cyclus* Fuel Cycle Simulator
-=================================================
-
-
-The Computational Nuclear Engineering Research Group (CNERG) of the University
-of Wisconsin-Madison (UW) has been developing a next generation nuclear fuel
-cycle simulation platform called *Cyclus* whose genesis was driven by a variety
-of gaps seen in previous fuel cycle simulation efforts. Three major design and
-development philosophies encompass the current fleet of fuel cycle simulators:
-
- #. A desire for usability, thus developing a tool which begins with a simple
- model in a visual development environment that aims to provide an intuitive
- user interface (e.g. DYMOND, DANESS, VISION)
-
- #. A desire for rapid prototyping, thus developing a tool which begins with
- simple models in a scripting language that allows for quick answers to early
- problems (e.g. CAFCA, GENIUS v1)
-
- #. A desire for detail/fidelity, thus developing a tool with an ad-hoc
- combination of existing complex analysis tools (e.g. COSI)
-
-Experience has demonstrated that each of these philosophies are hindered from
-simulating interesting problems due to complexity limits. In most cases this
-complexity constrains first the usability of the tool followed by its
-extendability due to increasingly convoluted dependencies. The final victim is
-performance, as the ability to quickly solve simple problems is lost to the
-desire to solve more complex ones.
-
-In addition to these technical challenges, there is also an institutional
-challenge. A combination of closed development platforms and closed
-development processes has made it difficult for an individual researcher to
-incorporate their ideas into a fuel cycle systems analysis. The ability to
-combine existing systems simulation tools with data about new facilities or
-fuel cycle concepts is so challenging that many researchers either choose to
-avoid systems analysis altogether or to write their own simplified tool
-(usually in category 2 above). These new, special purpose fuel cycle
-simulation tools involve a duplication of effort and generally lack any robust
-benchmarking.
-
-Each of these approaches lacks a design basis in computational science and
-software development that can deliver the stated desired attributes of the
-final software product:
-
- * usability -- accommodating a wide range of user sophistication
- * performance -- solving simple problems in interactive time scales
- * fidelity -- accommodating many levels of detail/fidelity, commensurate with a range of user sophistication
-
-A complete nuclear fuel cycle simulator requires modeling efforts in a wide
-variety of physical and social science domains. This places a premium on a
-software development process that will facilitate fluid collaboration among a
-large group of geographically dispersed developers. With this constraint in
-mind, a number of software development practices can be identified as highly
-valuable for this effort:
-
- * openness -- the process should have low institutional & technical obstacles to collaboration
- * modularity -- a particular approach to modularity should be pursued to allow the core infrastructure to be independent of proprietary and/or sensitive data and/or models
- * extensibility -- attention to both robustness and flexibility allows for myriad potential developer extensions
-
-Mission
--------
-
-*Cyclus* will be a nuclear fuel cycle systems analysis software platform that
-encourages collaboration among a diverse set of researchers. Emphasis will be
-placed on both ease of collaboration through modularity as well as ubiquity in
-order to analyze a significant number of possible future fuel cycle scenarios
-succinctly and consistently.
-
-Vision
-------
-
-In order to accomplish this mission, the *Cyclus* team has developed a vision
-for the development of a next generation fuel cycle simulator that includes
-elements of software architecture, software development process and
-fundamental design paradigms.
-
-Current Status
---------------
-
-*Cyclus* is being developed in an open environment. For the current status of *Cyclus*, visit http://cyclus.github.com.
-
-Software Process & Architecture
-+++++++++++++++++++++++++++++++
-
-As indicated above, the software architecture and accompanying development
-process are critical to a simultaneously robust and flexible analysis platform.
-
-Open Source Development Process
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The *Cyclus* development framework employs a modern, open source philosophy
-that ensures transparency, attracts contributions from a varied community of
-collaborators, and guarantees institution-independent access to all potential
-users. In this development path, a public source code repository provides
-unhindered access to the fundamental simulation framework and basic fuel
-process models volunteered by developers. Granting unfettered access only to
-the *Cyclus* engine allows for compartmentalization of the code and its input
-data. Thus, secure and proprietary model developers can be similarly encouraged
-to utilize the *Cyclus* framework. This modern development model passively
-distributes specialized content to interested research groups, and facilitates
-parallel model development efforts by institutions with complimentary goals.
-The transparency inherent in this type of open source development path also
-facilitates code review by exposing available content to verification and
-validation by collaborators with diverse areas of specialization and levels of
-expertise.
-
-Another aspect of this development process is a preference for open source
-third party libraries where additional functionality is necessary and available
-from such libraries. This includes basic infrastructure such as file
-input/output, as well as model-specific capabilities like integer programming
-for network flow optimization.
-
-Dynamically-loadable Modules
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Dynamically-loadable modules are the primary mechanism for extending *Cyclus*
-with new underlying models. The primary benefit of this approach is
-encapsulation: the trunk of the code is completely independent of the
-individual models and all customization and extension is implemented only in
-the loadable module. A secondary benefit of this encapsulation is the ability
-for contributors to choose different distribution and licensing strategies for
-their contributions. Finally, this strategy allows an individual developers
-to explore different levels of complexity within their modules, including
-wrapping other simulation tools as loadable modules for *Cyclus*.
-
-Use Cases & Visualization
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Because of the wide array of use cases for *Cyclus*, flexibility in the user
-interface is important to provide different kinds of users with different
-experiences. This is true for input generation as well as output
-visualization. A variety of graphical user interface modes have been designed
-and will be implemented in parallel with the development of underlying modules.
-The graphical interface should be extensible by loadable modules in the same
-way as the core code to provide developers the same flexibility in managing
-their input as they have in implementing their models. Output visualization is
-also important - the discrete facility/discrete material paradigm generates a
-large volume of small data that needs to be aggregated in various ways to
-provide context to a variety of users.
-
-Modeling Paradigm
-+++++++++++++++++
-
-The modeling paradigm adopted by *Cyclus* includes a number of deeply embedded
-fundamental concepts. These basic design choices comprise the bedrock on which
-most future design choices are made. The *Cyclus* team recognizes the
-accompanying inflexibility to the code and therefore does not anticipate that
-these attributes will change.
-
-Discrete Facility & Discrete Material Objects
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The modeling infrastructure is designed such that every facility in a global
-nuclear fuel cycle is treated individually. While modeling options will exist
-to allow collective action, this will be as a special case of the individual
-facility basis. Each facility will have two fundamental tasks: to transact
-nuclear material with other facilities and to transform that nuclear material
-from an input form to an output form. These materials will be modeled as
-discrete objects that exist for a finite time and whose composition and
-transaction history is logged throughout the simulation.
-
-Market-based Material Transactions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The transaction of nuclear materials will take place in "markets" that act as
-brokers to match a set of requests for material with a set of offers for that
-material. A variety of market models (see Vision: Software Architecture) will
-be available to perform this broker role, but each market will act
-independently of other markets. Markets will used to model a variety of
-decision making behaviors, not restricted to behaviors that simulate economic
-activity. Once the requests and offers have been matched, the facilities will
-exchange material objects.
-
-Region-Institution-Facility Hierarchy
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Every discrete facility in *Cyclus* is owned by an institution that operates in
-a geographic region. An institution can be used to represent any entity that
-may own and operate a facility such as a private corporation, a government
-agency, or a non-governmental agency, among others. A region can be used to
-represent any geographic area, typically a politically relevant area such a
-sub-national region (e.g. a U.S. State), a nation-state, or a super-national
-region (e.g. the E.U.). While some performance parameters of the facility may
-depend on its institutional ownership or geographical location, the more
-important use of this capability is to control the way in which a facility
-engages in a market for trade of nuclear material based on by whom it is owned
-and/or operated.
-
-Optimization and Sensitivity
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-While the market models that form the basis of material transactions represent
-largely social constructs, there is an initial desire to minimize the direct
-simulation of institutional decision making to seek optimal solutions.
-Instead, the fundamental approach is to drive a single simulation with a large
-multi-dimensional data set and then allow modern optimization technology to
-seek globally optimal solutions based on global objective functions. Since
-institutional decision making tends to seek an optimal solution only for the
-actor making that decision (local optimization), it may not lead to an outcome
-that optimizes for the largest population of stakeholders.
-
-Research Areas
---------------
-
-A number of research areas related to *Cyclus* have already been identified.
-In some cases, there is a lead institution already engaged in such research, or
-one or more institutions who have expressed interest:
-
- #. *Cyclus* core infrastructure development lead: UW-Madison
-
- #. Market model development interest: UW-Madison, UT-Austin
-
- #. Region model development and deployment scenarios interest: Idaho
-
- #. Reactor model development interest: UT-Austin
-
- #. Separations model development
-
- #. Geologic repository & waste form modeling lead: UW-Madison
-
- #. Graphical interfaces for input and visualization interest: Utah
-
- #. Social science to determine important metrics and measures interest: UW-Madison
-
- #. Optimization and sensitivity infrastructure interest: NC State
-
- #. Transportation
-
- #. Non-proliferation analysis interest: UW
-
diff --git a/_sources/wiki/CyclusStyleGuidelines.txt b/_sources/wiki/CyclusStyleGuidelines.txt
deleted file mode 100644
index 9eca5c910..000000000
--- a/_sources/wiki/CyclusStyleGuidelines.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-.. summary Style Guidelines for cyclus development
-
-Introduction
-============
-
-The purpose of this page is to introduce some general style guidelines to help
-with readability, maintainability and extensibility of the cyclus code base.
-
-
-Class File Organization
-=======================
-
-Class header files should be organized in the following order:
-
- * private
-
- * methods
-
- * virtual
-
- * static
-
- * non-static
-
- * data members
-
- * static
-
- * non-static
-
- * protected (in same order as above)
-
- * public (in same order as above)
-
-Within each section, methods should be grouped and ordered in logical
-categories in the following order:
-
- * "life-cycle" methods first (e.g. constructors, destructors, initializers)
-
- * operators (e.g. equivalence, assignment)
-
- * data access methods
-
- * other base-class-specific categories
-
- * other class-specific categories
-
-The order of method definition in the implementation file should be consistent
-with the order of declaration in the header file.
-
-Code Formatting
-===============
-
-Line lengths, tab spacing, and bracket placement will conform to the google c++
-style standard as much as possible. This requires that all tabs be replaced by
-spaces, and that an indentation is equal to two spaces. Further information on
-this style standard can be found in the `Google Style Guide`_.
-
-.. _`Google Style Guide`: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
-
-Notable items:
-
- * no tabs - expand all tabs to 2 spaces.
-
- * enum items should be all caps
-
- * trailing underscores must be used with all class member variables
-
- * opening braces should be placed on the same line as function args:
- `ReturnType functionName(Arg1Type arg_name) {`
-
- * loop and branching statements should generally use the opening and closing
- braces (i.e. not like this: `if (true) long_statement;`)
-
diff --git a/_sources/wiki/Decay.txt b/_sources/wiki/Decay.txt
deleted file mode 100644
index 9704768d0..000000000
--- a/_sources/wiki/Decay.txt
+++ /dev/null
@@ -1,128 +0,0 @@
-.. summary Documentation for the Cyclus Decay Method
-
-*NOTE:* This wiki page is currently a work in progress.
-
-Radioactive Decay in Cyclus
-===========================
-
-Radioactive decay of a group of isotopes over time can be described by the
-following first order differential equation:
-
-.. math::
-
- \frac{d}{dt}\mathbf{N(\mathit{t})}=\textrm{A}\: \mathbf{N(\mathit{t})}
-
-where the vector `N(t)` contains the number density of all the
-isotopes being considered at time `t`, and A is called the decay
-matrix. The solution to this differential equation can be expressed in terms
-of a matrix exponential:
-
-.. math::
-
- \mathbf{N(\mathit{to+\Delta t})}=e^{\Delta t \textrm{A}}\: \mathbf{N(\mathit{to})}
-
-The decay method currently implemented in *Cyclus* computes this matrix
-exponential solution at any given time using a series approximation known as
-the Uniformization Method. This implementation was written by Kerry Dunn, and
-is explained in more detail below.
-
-The Uniformization Method
--------------------------
-
-The Uniformization Method is essentially a modification of the truncated Taylor
-Series expansion of the matrix exponential solution, which can be described by
-the following summation:
-
-.. math::
-
- \mathbf{N(\mathit{to+\Delta t})}\approx \sum_{k=0}^{p}\frac{\left (\Delta t \right )^k}{k!}\: \textrm{A}^k\: \mathbf{N(\mathit{to})}
-
-The primary disadvantage of using this Taylor Series expansion to compute the
-matrix exponential solution is that it can be subject to cancellation error as
-a result of summing terms with alternating signs. These terms with alternating
-signs occur because the diagonal elements in the decay matrix that represent
-the decay constants are all negative. Therefore, in order to eliminate the
-potential for cancellation error, the decay matrix must be modified so that it
-no longer contains these negative elements. This modification process is known
-as the uniformization technique.
-
-The first step in applying the uniformization technique is to define
-`alpha` to be equal to the absolute value of the maximum diagonal
-element of `A`:
-
-.. math::
-
- \alpha=max_i\left | a_i_i \right |
-
-Then, given `alpha`, the next step is to redefine the matrix
-exponential solution using a different matrix `P`:
-
-.. math::
-
- \textrm{P}=\frac{1}{\alpha}\textrm{A}+\textrm{I}
-
-where I is the identity matrix. Note that `P` is completely non-negative, so a
-Taylor Series expansion of this matrix exponential is not subject to the same
-cancellation error that occurs with the original decay matrix. By replacing `A`
-with `P`, the matrix exponential solution can now be expressed by the following
-summation:
-
-.. math::
-
- \mathbf{N(\mathit{to+\Delta t})}=e^{-\alpha \Delta t}\: e^{\Delta t (\alpha \textrm{P})}\: \mathbf{N(\mathit{to})}\approx e^{-\alpha \Delta t}\sum_{k=0}^{p}\frac{\left (\Delta t \right )^k}{k!}\: (\alpha \textrm{P})^k\: \mathbf{N(\mathit{to})}
-
-Note that this modified Taylor Series expansion can also be expressed in terms
-of the original matrix A by substituting the definition for `P`:
-
-.. math::
-
- \mathbf{N(\mathit{to+\Delta t})}\approx e^{-\alpha\Delta t}\sum_{k=0}^{p}\frac{\left (\Delta t \right )^k}{k!}\: (\textrm{A}+\alpha \textrm{I})^k\: \mathbf{N(\mathit{to})}
-
-
-Implementation in Cyclus
-------------------------
-
-Adding New Isotopes
--------------------
-
-Limitations
-+++++++++++
-
-When adding a new isotope, the most important thing to take into account is its
-half-life or decay constant. The isotope with the smallest half-life, or
-largest decay constant, will be the limiting factor for the time scale over
-which *Cyclus* can decay _all_ materials in one step. This occurs because the
-Uniformization Method requires the computation of an exponential term, which is
-limited by the size of a long double on the system being used to run *Cyclus*.
-To determine the maximum time scale that will be valid for a particular group
-of isotopes, the following equation can be used:
-
-.. math::
-
- {t_{max} = \frac{ln(\textrm{LDBL\_MAX})}{min(\lambda)}}
-
-where `LDBL_MAX` is the size of a long double and :math:`\lambda` is the
-largest decay constant of the group of isotopes being considered.
-
-As an example, suppose that the isotope with the smallest half-life being
-considered is Cm-232. This particular isotope has a decay constant of 1.5532
-nuclei per year. If the size of a long double is limited to LDBL_MAX =
-1.18973e+4932, then all materials can only be decayed for a maximum of 7311
-years. Adding any isotopes with a half-life smaller than Cm-232 would result
-in an even lower maximum time scale.
-
-References
-----------
-
- #. Cleve Moler and Charles van Loan, "Nineteen Dubious Ways to Compute the
- Exponential of a Matrix, Twenty-Five Years Later," *SIAM Review*, *45*,
- 3-49 (2003)
-
- #. Erwin Muller, Frederik Reitsma and Paulus P. Kruger, "A Stable Nuclide
- Transmutation Procedure Free of Numerical Roundoff," *PHYSOR 2006*, September
- 10-14, Vancouver, Canada (2006)
-
- #. R. B. Sidje and W. J. Stewart, "A numerical study of large sparse matrix
- exponentials arising in Markov chains," *Computational Statistics & Data
- Analysis*, *29*, 345-368 (1999)
-
diff --git a/_sources/wiki/DeploymentRegion.txt b/_sources/wiki/DeploymentRegion.txt
deleted file mode 100644
index e0f8bf6c9..000000000
--- a/_sources/wiki/DeploymentRegion.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-#summary Description of DeploymentRegion usage and implementation
-
-= Introduction =
-
-The DeploymentRegion is a region type in *Cyclus* that is associated with a list of allowed facilities. Any institution in that region must have only those facilities. It is instantiated at the beginning of the simulation and persists until the end of the simulation.
-
-A DeploymentRegion takes a set of explicit instructions from the user to deploy specific facilities at specific times.
-
-= Model Parameters =
-
-DeploymentRegion behavior is comprehensively defined by the following parameters:
- * {{{vector< Model > allowedfacilities}}} : The facilities which are allowed within this region.
- * For each allowed facility:
- * {{{vector< vector < double > > deploysched}}} : An Nx2 matrix where for each n,
- * a,,n,0,, = time
- * a,,n,1,, = total build demand for the facility
-
-= Optional Parameters =
-
-DeploymentRegion behavior may also be specified with the following optional parameters which have default values listed here.
-
- * string name : A non-generic name for this region.
-
-= Detailed Behavior =
-
-The DeploymentRegion is initiated at the beginning of the simulation and persists until the end of the simulation. The region is created with an Nx2 matrix which dictates when facilities in the region should be built. An example of such a matrix is shown below.
-
-Let us consider a region which would like to produce light water reactors (LWRs). This region would like to begin building 1000 MW,,e,, capacity at the initial month of the simulation and 2000 MW,,e,, at 3 years into the simulation. The demand vector would have values:
- {{{
-deploysched[0]=[0,1000]
-deploysched[1]=[36,2000] // 3 years = 36 months
- }}}
-
-When it receives a message, the DeploymentRegion simply passes that message either up the hierarchy to the market for which it was intended or down to the appropriate institution on the path to the recipient.
\ No newline at end of file
diff --git a/_sources/wiki/DevelopersDocumentation.txt b/_sources/wiki/DevelopersDocumentation.txt
deleted file mode 100644
index 2e7cd9e28..000000000
--- a/_sources/wiki/DevelopersDocumentation.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-#summary Documentation for Cyclus Developers
-#labels Phase-Implementation
-
-Documentation to assist with the development of *Cyclus* will be maintained in a variety of forms.
-
-== Fundamental Concepts ==
-
- * LogicianClass
- * CommodityClass
- * MaterialClass
- * CommunicatorClass
- * MessageClass
-
- * DynamicModule
- * GuidelinesForImplementingNewMarketModels
- * GuidelinesForImplementingNewRegionModels
- * GuidelinesForImplementingNewInstModels
- * GuidelinesForImplementingNewFacilityModels
- * GuidelinesForImplementingNewConverterModels
-
-== Milestone Definitions ==
-
-MilestoneNullSimulation
-
-MilestoneOneInpro
-
-MilestoneTwoNWTRB
-
-== Developers Wiki Notes ==
-
-Some specific topics will also be described in the Google Code project wiki pages.
-
- * GuidelinesForImplementingNewModels
-
-== Doxygen Code Documentation ==
-
-The definitive documentation of any software is the source code itself. *Cyclus* will relies on Doxygen for automation of rich documentation from appropriately formatted comments in the source code. Current Doxygen documentation can be found at http://cnerg.engr.wisc.edu/cyclus/docs/ . This page will be updated weekly during active development.
-
-In addition to following Doxygen comment notation in the source code, this relies on a properly configured Doxygen file.
- * cyclus/trunk/src/doc/doxy.conf.in is a cmake template file for doxygen settings.
- * To add or change options, edit this file and cyclus/trunk/src/doc/CMakeLists.txt
-
-Documentation is a make target in the cmake build system. Documentation will automatically be built when you "make all". You can build only the documentation by running "make cyclusdoc" instead of "make all" or "make". To avoid building documentation, use "make cyclus".
-
-== Diversions ==
-
-Relevant xkcd comics:
-
- * [http://xkcd.com/927/ Standards]
- * [http://xkcd.com/974/ The General Solution]
diff --git a/_sources/wiki/ExpGrowthRegion.txt b/_sources/wiki/ExpGrowthRegion.txt
deleted file mode 100644
index 71005b7a2..000000000
--- a/_sources/wiki/ExpGrowthRegion.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-#summary Description of ExpGrowthRegion usage and implementation
-
-= Introduction =
-
-The ExpGrowthRegion is a region type in *Cyclus* that is associated with a list of allowed facilities. Any institution in that region must have only those facilities. It is instantiated at the beginning of the simulation and persists until the end of the simulation.
-
-A ExpGrowthRegion takes a build time, intial demand, and demand growth rate from the user to deploy specific facilities at specific times.
-
-= Model Parameters =
-
-ExpGrowthRegion behavior is comprehensively defined by the following parameters:
- * {{{vector< Model > allowedfacilities}}} : The facilities which are allowed within this region.
- * For each allowed facility:
- * {{{vector< vector < double > > deploysched}}} : A matrix of size Nx3 where for each ,
- * a,,n,0,, = initial build time
- * a,,n,1,, = initial build demand
- * a,,n,2,, = exponential growth rate for further demand
-
-= Optional Parameters =
-
-ExpGrowthRegion behavior may also be specified with the following optional parameters which have default values listed here.
-
- * string name : A non-generic name for this region.
-
-= Detailed Behavior =
-
-The ExpGrowthRegion is initiated at the beginning of the simulation and persists until the end of the simulation. The region is created with a Nx3 matrix which dictates when facilities in the region should be built. An example of such a matrix is shown below.
-
-Let us consider a region which would like to produce light water reactors (LWRs). This region would like to begin building 1000 MW,,e,, capacity at 1 year into the simulation and would like to grow this demand at a rate of 1%. The region at year 3 would then like to begin building 5000 MW,,e,, capacity, if it has not already been reached, with a growth rate of 2% per month. Finally, at year 10, the region would like to maintain the current demand level, but no longer build any further reactors. The demand vector would have values:
- {{{
-deploysched[0]=[0,1000,0.01]; // 1% -> 0.01
-deploysched[1]=[60,5000,0.02]; // 5 years = 60 months
-deploysched[2]=[120,-1,0.0]; // 10 years = 120 months; -1 denotes current demand level
- }}}
-
-When it receives a message, the ExpGrowthRegion simply passes that message either up the hierarchy to the market for which it was intended or down to the appropriate institution on the path to the recipient.
\ No newline at end of file
diff --git a/_sources/wiki/GettingAndBuildingCyclus.txt b/_sources/wiki/GettingAndBuildingCyclus.txt
deleted file mode 100644
index efe05e377..000000000
--- a/_sources/wiki/GettingAndBuildingCyclus.txt
+++ /dev/null
@@ -1,97 +0,0 @@
-#summary Information on getting Cyclus from the repository and building it on a new system
-#labels Phase-Deploy
-
-== Requirements ==
-
-The Cyclus code requires the following software and libraries.
-
-||Package || Minimum Version ||
-|| `CMake` || 2.8 ||
-|| `HDF5` || 1.8.3 ||
-|| `libxml2` || 2 ||
-|| `boost` || 1.34.1 ||
-|| `lapack` || 3.4.0 ||
-|| `trilinos (teuchos)` || 10.8.4 ||
-
-An overview of some more complicated package builds and installations (e.g. lapack, teuchos, etc.) can be found on the InstallingDependenciesOnUnix or InstallingDependenciesOnWindows wiki pages.
-
-== Repository ==
-
-The Cyclus repository is version controlled using the subversion (SVN) version control system. It is hosted externally with googlecode and mirrored internally on the CNERG space.
- * The main repository is located at http://cyclus.googlecode.com/svn/
- * There is a *read only* mirror at file:////home/cnerg/svn/cyclus-mirror
- * Anyone may check out the code.
- * You do not have to register with googlecode if you do not have a google id, but anonymous users may never commit.
- * Note that the googlecode password for your google id is generated by google and you can find it at [https://code.google.com/hosting/settings]
- * To check out the code follow the [https://code.google.com/p/cyclus/source/checkout googlecode checkout instructions] .
- * Once you have checked out the code, you may commit a change to the google code repository if you are authorized as a committer .
- * To become a committer, you must ask for permission via email from one of the project owners ( currently [https://code.google.com/u/katyhuff/ Katy] or [https://code.google.com/u/uwgonuke Paul] )
- * Committing happens from your checked out copy of the repository.
- * For example, say you have the google username USERNAME and google password PASSWORD and are sitting in the cyclus/trunk/src directory of your checked out copy. You may want to commit your changes to a version controlled file called FILENAME. To do this you would type.
-{{{
-svn commit FILENAME --username USERNAME --password PASSWORD
-}}}
- * Google may prompt you for your password if you do not include the --username and --password flags.
- * Alternatively, if you are sitting in a directory in which you want to commit all of your changes at once, you would type:
-{{{
-~ : svn commit
-}}}
- * If instead FILENAME is a brand new file, not yet under version control, you can use the svn command add:
-{{{
-~: svn add FILENAME
-~: svn commit
-}}}
- * For some users, svn commit and svn add will not work and you may need to use the import command:
-{{{
-~: svn import FILENAME https://cyclus.googlecode.com/trunk/src/FILENAME --username USERNAME --password PASSWORD
-}}}
- * The two repositories (the trunk on the CNERG space and the trunk on googlecode) are synchronized using svnsync.
-
-== Build System ==
-
-In order to facilitate future compatibility with multiple platforms, Cyclus is built using [link: http://www.cmake.org Cmake]. This relies on CMake version 2.6 or higher and the CMakeLists.txt file in /cyclus/trunk/src/. It is recommended that you use CMake to build the Cyclus executable external to the source code. To do this, execute the following steps:
-{{{
-/cyclus/trunk/$ mkdir build
-/cyclus/trunk/$ cd build
-cyclus/trunk/build$ cmake ../src
-}}}
-You should see output like this:
-{{{
-...
-...
->> -- Configuring done
->> -- Generating done
->> -- Build files have been written to: /cyclus/trunk/build
-/cyclus/trunk/build$ make cyclus
->> Scanning dependencies of target cyclus
-...
-...
->> [100%] Building CXX object CMakeFiles/cyclus.dir/SourceFac.cpp.o
->> Linking CXX executable cyclus
->> [100%] Built target cyclus
-}}}
-Now, you can make cyclus, and run it with some input file, for this example, call it input.xml.
-{{{
-cyclus/trunk/build$ make
-cyclus/trunk/build$ ./cyclus input.xml
-}}}
-
-== Debugging Build ==
-
-If you are a developer, you may be interested in building Cyclus in such a was as to facilitate debugging. It is recommended that you create second build directory in which you'll build a Cyclus executable for which optimizations are disabled and debug symbols are added. To do this, execute the following steps:
-{{{
-/cyclus/trunk$ mkdir debug
-/cyclus/trunk$ cd debug
-/cyclus/trunk/debug$ cmake -DCMAKE_BUILD_TYPE:STRING=Debug ../src
-}}}
-As before, you should call make to actually build the cyclus executable.
-{{{
-/cyclus/trunk/debug$ make
-}}}
-Now when you call gdb, ddd, or some other debugger within this debug directory it will recognize the target as a debuggable target. To debug a run for some input file input.xml, try the following:
-{{{
-/cyclus/trunk/debug$ ddd ./cyclus input.xml
-}}}
-
-== Environment ==
-In order to utlize the `RelaxNG` input schema, it is necessary to set an environment variable that directs our search algorithm to your cyclus.rng file. That is, before you run cyclus, you must set the environment variable CYCLUS_SRC_DIR to the path to your src directory.
diff --git a/_sources/wiki/GuidelinesForImplementingNewFacilityModels.txt b/_sources/wiki/GuidelinesForImplementingNewFacilityModels.txt
deleted file mode 100644
index 7125c9061..000000000
--- a/_sources/wiki/GuidelinesForImplementingNewFacilityModels.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-#summary Developers notes for the implementation of a new FacilityModel
-#labels Phase-Implementation
-
-= Introduction =
-
-After reading GuidelinesForImplementingNewModels, this should provide additional information specific to implementing a new FacilityModel.
-
-= Details =
-
-In addition to inheriting from the main dynamic loading base class `Model`, all FacilityModel models also inherit from `Communicator`.
-
-A FacilityModel is one of the primary actors in the *Cyclus* system. All offers and requests originate at an instance of a FacilityModel and all shipments are executed by an instance of a FacilityModel.
-
-While running, *Cyclus* will use a FacilityModel in two ways. First, it will read user input to define a template instance of a FacilityModel. A choice of a FacilityModel model combined with some distinct set of parameters for that model results in a facility that is available for deployment by an InstModel institution if allowed by that institution's RegionModel region. Second, *Cyclus* will create copies of the FacilityModel facilities as they are deployed by the institutions. For this reason, the FacilityModel class defines a data member `fac_name` that is the name of the individual deployed facility.
-
-All FacilityModel models should know which set of Commodity objects they trade and/or which MarketModel markets they participate in. Each FacilityModel model should implement a method named `sendMessages` to generate offer and request messages to send to their markets and methods named `sendMaterial` and `receiveMaterial` to process shipment messages that originate with their markets.
\ No newline at end of file
diff --git a/_sources/wiki/GuidelinesForImplementingNewInstModels.txt b/_sources/wiki/GuidelinesForImplementingNewInstModels.txt
deleted file mode 100644
index 4d5900225..000000000
--- a/_sources/wiki/GuidelinesForImplementingNewInstModels.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-#summary Developers notes for the implementation of a new InstModel
-#labels Phase-Implementation
-
-= Introduction =
-
-After reading GuidelinesForImplementingNewModels, this should provide additional information specific to implementing a new InstModel.
-
-= Details =
-
-In addition to inheriting from the main dynamic loading base class `Model`, all InstModel models also inherit from `Communicator`.
-
-A InstModel's primary function is to
- * refer to the set of facilities operating in this institution
-
-All InstModel models may also implement a reciveMessage function if messages need to be amended by the institution before being sent up to the region or down to the facility. This is a virtual (but not pure virtual) function, so implementation is optional. Default behavior is to ignore the message.
-
-InstModel models are sent a tick and tock signal at the beginning and end of each month, respectively. Monthly tasks, such as facility deployment or bookkeeping should be undertaken within the handleTick and handleTock functions. These are virtual (but not pure virtual), so implementation of these functions is optional.
-
-*The InstModel model type is not yet stable and additional interface and data members are expected to be added.*
diff --git a/_sources/wiki/GuidelinesForImplementingNewMarketModels.txt b/_sources/wiki/GuidelinesForImplementingNewMarketModels.txt
deleted file mode 100644
index 8e7750742..000000000
--- a/_sources/wiki/GuidelinesForImplementingNewMarketModels.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-#summary Developers notes for the implementation of a new MarketModel
-
-= Introduction =
-
-After reading GuidelinesForImplementingNewModels, this should provide additional information specific to implementing a new MarketModel.
-
-= Details =
-
-In addition to inheriting from the main dynamic loading base class `Model`, all MarketModel models also inherit from `Communicator`.
-
-A MarketModel's primary function is to
- * receive offers and requests from facilities,
- * "_resolve_" the market by matching those offers and requests
- * generate/execute a set of orders for shipments of material between facilities that results from resolving the market
-
-Therefore, all MarketModel models should implement their own version of `receiveOfferRequest` that registers incoming offers and requests in a way that is appropriate for this market implementation. All MarketModel models must also implement their own version of `resolve`.
-
-All MarketModel models have an STL `set` of pointers to the `OfferRequest` messages that have arrived and an STL `deque` of pointers to the `Shipment` messages that it is generating. MarketModel models are also free to have additional storage modes for `OfferRequest` messages or `Shipment` messages that facilitates the operation of that particular MarketModel paradigm.
\ No newline at end of file
diff --git a/_sources/wiki/GuidelinesForImplementingNewModels.txt b/_sources/wiki/GuidelinesForImplementingNewModels.txt
deleted file mode 100644
index 35e0186c3..000000000
--- a/_sources/wiki/GuidelinesForImplementingNewModels.txt
+++ /dev/null
@@ -1,89 +0,0 @@
-#summary Some developers notes on implementing new dynamically loadable models
-
-= Introduction =
-
-The current code in `branches/paul-branch` has support for Markets, Facilities and Regions and loadable modules. The instructions here will describe both how to add specific modules within those types, as well as how to extend this to other types of loadable modules.
-
-= Creating New Models of the Existing Types =
-
-For each type of model, a set of stub files are available as skeletons for the new models. When creating a new model, it is important that all the functionality defined in these files remains in the final model definition.
-
-To create a new model, e.g. a new MarketModel of type !NewMarket:
- * copy !StubMarket.h and !StubMarket.cpp to a new location, e.g. !NewMarket.h & !NewMarket.cpp, respectively
- * change the internal references to !StubMarket to !NewMarket
- * add a new `add_library` line to the CMakeLists.txt file in that directory
- * add the XML input grammar for that model to the appropriate place in the [https://code.google.com/p/cyclus/source/browse/branches/paul-branch/src/cyclus.rng cyclus.rng] XML schema
-
-All models must provide the following:
- * a method named 'init' to initialize an instance of the model from an XML node pointer (xmlNodePtr)
- * this method must call the parent class method of the same name (e.g. MarketModel::init(cur))
- * this method should only initialize variables that are NOT members of the parent class
- * a method named 'copy' to initialize an instance of the model from another instance of the same model
- * this method must call the parent class method of the same name (e.g. MarketModel::copy(src))
- * this method should only initialize variables that are NOT members of the parent class
- * a method named 'print' to print a description of the model
- * this method should call the parent class method of the same name (e.g. MarketModel::print())
- * this method should only print information that is NOT part of the parent class(es)
- * this method assumes that a dangling output line (no std::endl) is left from the parent class output
- * two global functions `construct` and `destroy` that are used to instantiate objects of this model type. They are defined, for example, as follows:
-{{{
-extern "C" Model* construct() {
- return new NewMarket();
-}
-
-extern "C" void destruct(Model* p) {
- delete p;
-}
-}}}
-
-For further details about creating new models of particular types, consult the Model-specific reference:
- * GuidelinesForImplementingNewMarketModels
- * GuidelinesForImplementingNewRegionModels
- * GuidelinesForImplementingNewInstModels
- * GuidelinesForImplementingNewFacilityModels
-
-
-= Keeping Stub Files Current =
-
-It is very important to keep the Stub files in the Models directory (or in each of the model sub-directories) current. As the Model.h definition is improved/enhanced/developed, each of the model types will have to be updated to be consistent. Treat the StubModel and the StubCommModel in the same way as others to ensure it remains up-to-date.
-
-Similarly if a single model type is updated, e.g. !MarketModel.h, with new capability, each of the implemented models will need to be updated to be consistent. Treat the Stub`*` Models in each sub-directory in the same way as the others to ensure it remains up-to-date.
-
-= Extending Loadable Modules to Other Types =
-
-The current code already has support for loadable modules for MarketModel, FacilityModel, InstModel, and RegionModel. These are all derived from base class Model defined in [https://code.google.com/p/cyclus/source/browse/branches/paul-branch/src/Models/Model.h Model.h]. To support extension of this capability to other types of models, the files [https://code.google.com/p/cyclus/source/browse/branches/paul-branch/src/Models/StubModel.h StubModel.h] & [https://code.google.com/p/cyclus/source/browse/branches/paul-branch/src/Models/StubModel.cpp StubModel.cpp] is provided. (Stubs are also provided for new Models that are also Communicators: [https://code.google.com/p/cyclus/source/browse/branches/paul-branch/src/Models/StubCommModel.h StubCommModel.h] & [https://code.google.com/p/cyclus/source/browse/branches/paul-branch/src/Models/StubCommModel.cpp StubCommModel.cpp].)
-
-To extend to a new model type, e.g. !NewTypeModel:
- * copy !StubModel.h & !StubModel.cpp to a new location, !NewTypeModel.h & !NewTypeModel.cpp, respectively
- * change the internal references to StubModel to !NewTypeModel
- * add !NewTypeModel.cpp to the list of sources in the top level CMakeLists.txt file
- * add a sub-directory (e.g. NewType) to the Models directory for your models
- * this directory name will become a keyword and should match the model name
- * create a !StubNewType.h and !StubNewType.cpp file in that sub-directory that are stubs for new models of that type (you may want to copy the files Stub/StubStub.h and Stub/StubStub.cpp)
- * follow the directions for creating a new model above to make a Stub for your !NewType model
-
-All new models types must include:
- * a new `static int` variable called nextID that is initialized as 0 and provides a serialized ID for all instances of the models that are instantiated
- * a default constructor that
- * assigns the current value of nextID to the ID member variable and increments nextID
- * assigns a string that matches the model name to `model_type`
- * (for Communicators, this should also assign the correct value to `commType`)
- * a method named 'init' to initialize an instance of the model from an XML node pointer (xmlNodePtr)
- * this method must call the parent class method Model::init(cur)
- * this method should only initialize variables that are NOT members of the parent class
- * a method named 'copy' to initialize an instance of the model from another instance of the same model
- * this method must call the parent class method Model::copy(src)
- * (for Communicators, this method must call that parent class method Communicator::copy(src))
- * this method should only initialize variables that are NOT members of the parent class
- * a method named 'print' to print a description of the model
- * this method should call the parent class method of the same name (e.g. MarketModel::print())
- * this method should only print information that is NOT part of the parent class(es)
- * this method assumes that a dangling output line (no std::endl) is left from the parent class output
-
-Other notes on introducing new Model types:
- * You will probably need to extend the input parsing for this new Model type. Since the primary input for *Cyclus* uses XML, you will certainly need to add code to recognize and process primitives for this Model type. While you could, in theory, add a completely new input paradigm for Models of this type, you might need to extend the *Cyclus* grammar to include support for your Models.
- * You will probably need to create a primary storage location for your new models in *Cyclus*. Currently, most models are somehow registered with the Logician (exception: InstModel are only registered with their containing Region). You will need to extend the code appropriately to give a home to your new models.
-
-= References =
- # [http://oss.sgi.com/LDP/HOWTO/C++-dlopen/index.html C++ dlopen mini HOWTO]
- # [http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html Static, Shared Dynamic and Loadable Linux Libraries]
\ No newline at end of file
diff --git a/_sources/wiki/GuidelinesForImplementingNewRegionModels.txt b/_sources/wiki/GuidelinesForImplementingNewRegionModels.txt
deleted file mode 100644
index 8a0282b16..000000000
--- a/_sources/wiki/GuidelinesForImplementingNewRegionModels.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-#summary Developers notes for the implementation of a new RegionModel
-#labels Phase-Implementation
-
-= Introduction =
-
-After reading GuidelinesForImplementingNewModels, this should provide additional information specific to implementing a new RegionModel.
-
-= Details =
-
-In addition to inheriting from the main dynamic loading base class `Model`, all RegionModel models also inherit from `Communicator`.
-
-A RegionModel's primary functions are to
- * contain a set of institutions that operate in this region
- * define a set of allowed facilities for those institutions
- * Schedule the deployment of facilities by either
- 1. Determining when new facilities need to be built, or
- 2. deferring to an InstModel to make this determination.
- * Manage the deployment of facilities by interacting with the Institutions to select a specific facility type and facility parameters
- * Passing material offers/requests between a prescribed market and related facilities.
-
-All RegionModel models have an STL `set` of pointers to the `Model` instances that represent the allowed FacilityModel facilities. and an STL `vector` of pointers to the `Model` instances that represent the contained InstModel institutions.
-
-All RegionModel models may also implement a reciveMessage function if messages need to be amended by the region before being sent up to the market or down to the institution. This is a virtual (but not pure virtual) function, so implementation is optional. Default behavior is to ignore the message.
-
-RegionModel models are sent a tick and tock signal at the beginning and end of each month, respectively. Monthly tasks, such as facility deployment or bookkeeping should be undertaken within the handleTick and handleTock functions. These are virtual (but not pure virtual), so implementation of these functions is optional.
-
-= To Do =
-
-RegionModel models should be the mechanism for implementing demand growth. Different implementations of RegionModel models might implement different ways to model that growth. (Or is this all pre-processing?)
diff --git a/_sources/wiki/InstallingDependenciesOnUnix.txt b/_sources/wiki/InstallingDependenciesOnUnix.txt
deleted file mode 100644
index d96f5cec2..000000000
--- a/_sources/wiki/InstallingDependenciesOnUnix.txt
+++ /dev/null
@@ -1,40 +0,0 @@
-#summary Information on how to install some of the Cyclus dependencies
-
-== Overview ==
-
-This page will provide a short walk-through of some of the non-standard installation requirements for *Cyclus* dependencies. *Cyclus* strives to be a modularly designed code that allows dynamic loading of modules at run time; therefore, dependencies must be built as shared object libraries instead of static libraries. This is done through the use of the -fPIC (position independent code) flag when building the required dependencies. For your edification, [http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html this website] has a good review of shared libraries in general.
-
-== Some Quick Notes of Great Import ==
-
- # The following procedures will NOT work correctly if you have already acquired Lapack, BLAS, or Trilinos via Ubuntu's Synaptic Package Manager.
- * It is highly reccommended that you remove these libraries via Synaptic before reinstalling them in the following manner.
- # It is highly reccommended (specifically for novice users) that you install these libraries in /usr/local
- # Be very careful when using Teuchos. They have made the design decision to include definitions in their header files (due to heavy use of templates). Such header files can only be included in one location in the *Cyclus* source code.
-
-== Lapack ==
-
-Lapack can be installed on your Unix machine using the following steps:
-
- # Download Lapack from its [http://www.netlib.org/lapack/ website] and untar it in a preferred location
- # Make a build directory (e.g. one can place the source code in .../lapack/lapack-xx.yy.zz-Source and make the directory .../lapack/build)
- # Copy the configure_lapack script located in the *Cyclus* repository located in /trunk/dependencies/lapack and place it in your build folder
- # Change the configure script so that the last line points to your lapack source (e.g. .../lapack/lapack-xx.yy.zz-Source)
- * Note, by default the script will install the library at /usr/local.
- # Run the script (by typing ./configure_lapack.sh). Note that you may need to alter the script's permissions. To do so you can type "chmod 775 configure_lapack.sh".
- # From the build directory, type "make" (or "make -jN" where N is the number of threads you want to use [this speeds up the process])
- # From the build directory, type "make install"
-
-Note that the making process can take some time. It is suggested that you make with the -j flag.
-
-== Teuchos ==
-
-*Cyclus* uses the [http://trilinos.sandia.gov/packages/teuchos/ Teuchos] package of [http://trilinos.sandia.gov/ Trilinos]. Teuchos can be installed on your Unix machine using the following steps:
-
- # Download Trilinos from its [http://trilinos.sandia.gov/ website] and untar it in a preferred location
- # Make a build directory (e.g. one can place the source code in .../trilinos/trilinos-xx.yy.zz-Source and make the directory .../trilinos/build)
- # Copy the configure_trilinos script located in the *Cyclus* repository located in /svn/dependencies/trilinos and place it in your build folder
- # Change the configure script so that the last line points to your trilinos source (e.g. .../trilinos/trilinos-xx.yy.zz-Source)
- * Note, by default the script will install the library at /usr/local.
- # Run the script (by typing ./configure_trilinos.sh). Note that you may need to alter the script's permissions. To do so you can type "chmod 775 configure_trilinos.sh".
- # From the build directory, type "make" (or "make -jN" where N is the number of threads you want to use [this speeds up the process])
- # From the build directory, type "make install"
\ No newline at end of file
diff --git a/_sources/wiki/InstallingDependenciesOnWindows.txt b/_sources/wiki/InstallingDependenciesOnWindows.txt
deleted file mode 100644
index eb2243e66..000000000
--- a/_sources/wiki/InstallingDependenciesOnWindows.txt
+++ /dev/null
@@ -1,84 +0,0 @@
-#summary Information on how to install some of the Cyclus dependencies
-
-== Overview ==
-
-This page will provide a short walk-through of some of the installation requirements for *Cyclus* dependencies on a Windows platform. *Cyclus* strives to be a modularly designed code that allows dynamic loading of modules at run time; therefore, most dependencies must be built as shared object libraries instead of static libraries.
-
-== Cygwin ==
-
-Cygwin is a terminal program that simulates a linux-like environment on Windows platforms. To install [http://cygwin.com Cygwin] you will need to download a setup file and run it according to the instructions at the [http://cygwin.com/install.html Cygwin Install Page].
-
-Specifically, the Cygwin installation manager will walk through the installation process.
-
- # Select Install From Internet.
- # Choose a directory to install cygwin.
- # Choose a download mirror near you.
- # Choose packages to install
- * If you have two free gigabytes on your computer, the package configuration process can be simplified by choosing to download all packages. This will require clicking INSTALL the icon next to ALL.
- * If space is restricted, you may be more selective about packages. When selecting packages, choose the default action for ALL packages. Then, search for and select install for specific packages that cyclus and its dependencies rely on : svn, gcc, g++, g77, cmake, make, lapack, libxml2, libidn.
- # This will take some time to install
- # When installed, check that these were installed correctly by using the 'which' command. A path will be returned if the package is found. If not, rerun Cygwin's setup.exe and install just the packages that are not found.
- * To check for svn, open a Cygwin terminal and type 'which svn'.
- * To check for gcc, open a Cygwin terminal and type 'which gcc'
- * etc.
-
-== Boost ==
-
-Cyclus depends on boost. You may install boost at [http://www.boost.org their website]. .
-It is recommenced that Windows users use the boost installer executable rather than unpacking the binaries manually or building from source. So, download the installer.
-
- # When the installer asks what packages to install, be certain to include
- * the program_options library
- * the IOStream libraries
- * and the date_time library
- * in addition to the default header libraries.
- # If you have surplus space on your computer, don't hesitate to install all of the libraries available, but be prepared for the installation to take up to an hour for all packages.
- # The installer will ask what variants of the boost libraries to install. Be certain to install a dynamic and a static library. Threading is up to you.
-
-== HDF5 ==
-
-HDF5 is a hierarchical database library that Cyclus uses for record keeping. To install HDF5 on Windows :
-
- # Go to the hdf5 website.
- # Download the appropriate precompiled Windows binaries.
- # Extract the full directory structure somewhere temporary.
- # Move the contents of the resulting /bin directory to /usr/local/bin , or another preferred bin directory in your $PATH .
- # Move the contents of the /lib directory to /usr/local/lib (or elsewhere in your $PATH).
- # So too with the contents of the include directory, move them to /usr/local/include (or elsewhere).
- # This can optionally be repeated with the share directory as well.
-
-Make sure the location you placed the binary files is in your $PATH environment variable. Finally, add an environment variable that states $HDF5_ROOT = /usr/local/lib (or your favorite other location).
-
-== Teuchos ==
-
-Download the Trilinos source code to some location such as ~/trilinos_source .
-
-If CMake fails to find your c, cxx, or fortran compilers, double check that these are in your path. You may also inform CMake of your default compilers with environment variables that CMake pays attention to. To set the C compiler, for example, you would set the $CC environmet variable to /usr/bin/gcc-3 .
-
-
-``
-cd ~/trilinos_source
-cd ../
-mkdir trilinos_build
-cd trilinos_bild
-cmake-gui ../trilinos_source
-``
-
-From the gui (or via commandline flags, if you prefer), set the following advanced configuration flags for the Trilinos build :
-
- * BUILD_SHARED_LIBS=ON
- * CMAKE_INSTALL_PREFIX=/usr/local/ (or elsewhere)
- * Trilinos_ENABLE_TEUCHOS=ON
- * BLAS_LIBRARY_DIRS=/usr/lib
- * LAPACK_LIBRARY_DIRS=/usr/lib
- * BLAS_LIBRARY_NAMES="blas"
- * LAPACK_LIBRARY_NAMES="lapack"
-
-Finally, configure and generate the make file (in the gui, these are buttons). In the terminal type make, then type make install.
-
-
-
-== Cyclus ==
-
-You're now ready to build cyclus. Onward to GettingAndBuildingCyclus.
-
diff --git a/_sources/wiki/IntegrationTests.txt b/_sources/wiki/IntegrationTests.txt
deleted file mode 100644
index 8390ec39d..000000000
--- a/_sources/wiki/IntegrationTests.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-#summary Guidelines for Cyclus Integration Tests
-
-== Known Input Files ==
-
-== Python Script ==
-
-
-
diff --git a/_sources/wiki/MilestoneGenRepo.txt b/_sources/wiki/MilestoneGenRepo.txt
deleted file mode 100644
index 972900f3d..000000000
--- a/_sources/wiki/MilestoneGenRepo.txt
+++ /dev/null
@@ -1,313 +0,0 @@
-#summary Defining the capabilities to be demonstrated during Milestone-GenRepo
-#labels Phase-Requirements
-
-= Introduction =
-
-This is a milestone for Cyclus development led by
-[https://code.google.com/u/katyhuff/ Katy Huff]. It seeks to generate a generic
-geology disposal system model appropriate for fuel cycle analysis.
-
-*Target Date: 12/2012*
-
-= Details =
-
-This development activity happens in four major phases and will be
-presented as a PhD thesis from the University of Wisconsin - Madison upon
-completion.
-
-Test problems will help comprehensively define and confirm each unit of the
-module's functionality. In general, tests will include very basic calculation checks,
-information passing tests, and more complex multiple subcomponent integration tests. Every
-unit of functionality within the model will be tested as an integral part of development.
-
-When these unit tests pass, validation efforts will take place which show that the
-complete model behaves in agreement with the more detailed model on which it was based. Some
-simplification of the analytical model will occur based on both component level and system
-level abstraction. If it does not behave as expected, sensitivity analyses, model
-abstraction, and computational development will be iterated through until the model is
-validated.
-
-Additional information on this work can be found in a
-[http://homepages.cae.wisc.edu/~khuff/papers/prelim.pdf preliminary report].
-
-----
-
-= Phase I : Demonstration of Empty Infrastructure =
-
-This phase will generate an infrastructure for module loading and information
-passing between subcomponents. It will demonstrate the interchangeability of pieces of
-the repository and the calculation strategy that will later facilitate radionuclide
-transport and heat transport required for capacity limited loading.
-
-*Target Date : 12/2011*
-
-== Phase Ia : GenericRepository Loading ==
-
-Initial code development on the base case model has begun with creation of the
-FacilityModel subclass, GenericRepository. This phase is intended to guarantee
-that the subclass meets the requirements defined by the Cyclus FacilityModel
-interface and can be dynamically loaded by the simulator.
-
-This requires a comprehensive definition of the interface between the
-GenericRepository model and the rest of the Cyclus simulation. Fundamentally,
-this entails fully formed send and receive material functions as well as a
-function for making requests.
-
-A first phase in the demonstration milestone will be for the repository model
-to successfully load its subcomponent models from user input (i.e. the waste
-form, waste package, buffer, and lithology) with their corresponding defining
-parameters. This will require a directory structure, empty component model
-classes, a loading schema for components, and an interface between the
-GenericRepository model and the Cyclus simulation.
-
-== Phase Ib : Interfaces For Each Component Model ==
-
-A second phase will involve implementing an information exchange paradigm
-between the subcomponents. This will build upon empty component models which can
-be loaded via xml and will incoporate component loading according specific
-instructions dictating the repository design and will implement a consistent
-set of interal interfaces between components.
-
-The purpose of this information passing scheme will be to communicate sufficient
-temperature fluxes and contaminant concentrations at the boundaries of the control
-volumes for neighboring subcomponents to solve their internal transport calculations.
-
-When these aspects are implemented, a structure for the output database will be
-defined and appropriate bookkeeping will be implemented sufficient to communicate
-the heat and solute transport evolution within the repository.
-
-The component model class interfaces will be defined with care.
-For example, the mixed cell model will need dimensions, solid mass,
-degradation rate, etc. Apropriate input parameters for each component will be
-defined as well. For example, the buffer will need to have a number of waste
-packages within it.
-
-
-== Phase I : Feature Requirements ==
-
-This will build on the capabilities of MilestoneNullSimulation and
-MilestoneOneInpro by adding :
- * a GenericRepository facility class
- * which can be loaded via xml
- * according to specifications about subcomponents and models
- * and interfaces smoothly with the Cyclus simulator
-
-This will require :
- * a directory structure for component models
- * definition of the GenericRepository interface with Cyclus
- * definition of the base input parameters for loading
- * a loading schema for GenericRepository model
- * a component interface class
- * a stub (empty) component model class
- * empty component model classes for known future models
- * loading schema for component models
- * an internal interface between components
- * input scheme for design specification
- * definition of the output data structure
- * generation of requests based on arbitrary capacity, for now
- * a skeletal calculation timeline
-
-== Phase I : Tests ==
-
-Test problems will help comprehensively define and confirm each unit of the
-demonstration functionality. For this stage, tests will include very basic information
-passing tests as well as more complex multiple subcomponent integration tests. Every
-unit of functionality within the model will be tested as an integral part of development.
-
-=== Null Test ===
-
-A null test of the demonstration case, for example, will release a single contaminant
-radionuclide through each subcomponent sequentially. This test will pass if the bookkeeper
-properly writes to the database its (aphysically unhindered) path through each control volume.
-
-=== Database Writing Test ===
-
-The database writing test will determine whether an appropriate data table for the
-repository facility is placed in the bookkeeper.
-
-=== Subcomponent Loading Test ===
-
-Will determine whether all subcomponents were loaded properly.
-
-=== Subcomponent Interaction Tests ===
-
-These tests will determine whether the subcomponents interact properly.
-
-----
-
-= Phase II : Component Level Base Case Development=
-
-
-
-*Target Date: 6/2012*
-
-== Phase II : ==
-
-== Phase IIa : MixedCell Component Model ==
-
-Analytical Implementation.
-Abstraction.
-
-== Phase IIb : OneDimPPM Component Model ==
-
-Analytical Implementation.
-Abstraction.
-
-== Phase IIc : TwoDimPPM Component Model ==
-
-Analytical Implementation.
-Abstraction.
-
-== Phase IId : ThreeDimPPM Component Model ==
-
-Analytical Implementation.
-Abstraction.
-
-== Phase IIe : LumpedRadNuc Component Model ==
-
-Analytical Implementation.
-Abstraction.
-
-== Phase IIf : LumpedHeat Component Model ==
-
-Analytical Implementation.
-Abstraction.
-
-== Phase II : Feature Requirements ==
-
-This will build on the capabilities in Phase II by adding :
- * Fleshed out models for a series of models of nuclide and heat transport
-
-== Phase II : Tests ==
-
-Each component will be tested individually for computational accuracy.
-
-----
-= Phase III : System Level Base Case Development =
-
-== Phase IIIa : Data Collection and Validation ==
-
-
-
-== Phase IIIb : System Level Abstraction ==
-
-Analytical Implementation.
-Abstraction.
-
-== Phase III : Feature Requirements ===
-
-This will build on the capabilities in Phase II by adding :
- * A comprehensive notion of the effect of each module on the total simulation
-
-== Phase II : Tests ==
-
-All components will be tested in an integrated way for computational accuracy.
-
-
-
-----
-
-= Phase IV : Extensions =
-
-*Target Date: 11/2012*
-
-== Phase IVa : Heat and Time Driven Coalescent Behavior ==
-
-An anticipated extension will adapt the radionuclide transport model to
-incorporate the effects of heat and time driven coalescent behavior in clay and salt.
-This extension will focus on the porosity decrease in those media as time and heat
-drive collapse around the waste packages. Time dependent coalescence will be addressed
-fir, followed by temperature dependent coalescence.
-
-== Phase IVb : Dual Continuum Fracture Model ==
-
-Next, the capability to model fracture features of granite and borehole environments
-will be added to the modeling capability by adding a dual continuum fracture mode
-
-== Phase IVc : Intrusion Scenario or Fast Pathway ==
-
-A final potential extension may be implemented that will address the issue of modeling
-a disruption scenario with a fast advective pathway that intersects the repository.
-A fast pathway model intended to demonstrate a disrupted scenario is modeled as a single
-intersecting fracture in the clay matrix.
-
-
-----
-
-== Summary of Cyclus Readiness ==
-
-The readiness level of cyclus capabilities with respect to the various phases
-is summarized below. Capabilities are rated from 0 (no one has given significant
-thought to this feature) to 10 (completely ready).
-
-|| *Phase 1* || *Phase 1* || *Phase 1* ||
-|| *Model or Capability* || *Readiness* || *Details* ||
-|| Empty GenericRepository || 10 || issue63 ||
-|| Basic rng schema || 10 || issue64, r372 ||
-|| Subcomponent rng schema || 10 || issue65, ||
-|| Directory structure || 10 || issue66, r372 ||
-|| Component Interface class || 10 || issue67, r394, r395, 400 ||
-|| StubComponent class || 10 || issue68, r407 ||
-|| Process Logic || 5 || issue69, r426 ||
-|| Design spec. input schema || 1 || issue72, due 10/25 ||
-|| Database Table || 1 || issue73, due 10/30 ||
-|| Calculation Timeline || 1 || issue74, due 11/15 ||
-|| Empty MixedCell Class || 2 || issue75, due 11/20 ||
-|| Empty OneDimPPM Class || 2 || issue76, due 11/20 ||
-|| Empty TwoDimPPM Class || 2 || issue77, due 11/20 ||
-|| Empty ThreeDimPPM Class || 2 || issue78, due 11/20 ||
-|| Empty LumpedRadNuc Class || 2 || issue79, due 11/20 ||
-|| Empty LumpedHeat Class || 2 || issue80, due 11/20 ||
-|| Empty MixedCell Tests || 2 || issue81, due 11/25 ||
-|| Empty OneDimPPM Tests || 2 || issue82, due 11/25 ||
-|| Empty TwoDimPPM Tests || 2 || issue83, due 11/25 ||
-|| Empty ThreeDimPPM Tests || 2 || issue84, due 11/25 ||
-|| Empty LumpedRadNuc Tests || 2 || issue85, due 11/25 ||
-|| Empty LumpedHeat Tests || 2 || issue86, due 11/25 ||
-|| *Phase 2* || *Phase 2* || *Phase 2* ||
-|| *Model or Capability* || *Readiness* || *Details* ||
-|| Phase 1 capabilities || || ||
-|| MixedCell Driving Tests || || ||
-|| MixedCell Abstraction || || ||
-|| MixedCell Implementation || || ||
-|| OneDimPPM Driving Tests || || ||
-|| OneDimPPM Abstraction || || ||
-|| OneDimPPM Implementation || || ||
-|| TwoDimPPM Driving Tests || || ||
-|| TwoDimPPM Abstraction || || ||
-|| TwoDimPPM Implementation || || ||
-|| ThreeDimPPM Driving Tests || || ||
-|| ThreeDimPPM Abstraction || || ||
-|| ThreeDimPPM Implementation || || ||
-|| LumpedRadNuc Driving Tests || || ||
-|| LumpedRadNuc Abstraction || || ||
-|| LumpedRadNuc Implementation|| || ||
-|| LumpedHeat Driving Tests || || ||
-|| LumpedHeat Abstraction || || ||
-|| LumpedHeat Implementation || || ||
-|| || || ||
-|| || || ||
-|| || || ||
-|| *Phase 3* || *Phase 3* || *Phase 3* ||
-|| *Model or Capability* || *Readiness* || *Details* ||
-|| Phase 2 capabilities || || ||
-|| || || ||
-|| || || ||
-|| || || ||
-|| || || ||
-|| || || ||
-|| || || ||
-|| || || ||
-|| || || ||
-|| *Phase 4* || *Phase 4* || *Phase 4* ||
-|| *Model or Capability* || *Readiness* || *Details* ||
-|| Phase 3 capabilities || || ||
-|| || || ||
-|| || || ||
-|| || || ||
-|| || || ||
-|| || || ||
-|| || || ||
-|| || || ||
-|| || || ||
-
diff --git a/_sources/wiki/MilestoneNullSimulation.txt b/_sources/wiki/MilestoneNullSimulation.txt
deleted file mode 100644
index bab96fe59..000000000
--- a/_sources/wiki/MilestoneNullSimulation.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-#summary Defining the capabilities to be demonstrated at Milestone NullSimulation
-#labels Phase-Design,Phase-Requirements
-
-= Introduction =
-
-This is the first milestone for Cyclus development
-
-*Target Date: 2010.08.01*
-
-= Definition =
-
-The simplest possible simulation definition in Cyclus has a single SourceFacility trading in a NullMarket with a single SinkFacility. Each of the facilities will be owned by a FixedInst institution in a NullRegion region.
-
-Other simulations that must be supported by this milestone:
- * SourceFacility -> NullMarket -> 2 x SinkFacility
- * 2 x SourceFacility -> NullMarket -> SinkFacility
- * 2 x SourceFacility -> NullMarket -> 2 x SinkFacility
- * SourceFacility -> NullMarket A -> NullFacility -> NullMarket B -> SinkFacility
- * SourceFacility -> NullMarket A -> 2 x NullFacility -> NullMarket B -> SinkFacility
-
-All of these models should be defined to give interesting and different results for the different cases described here. (issue 6)
-
-= Implementation =
-A first round of test`*`.xml simulations supported by this milestone is in the null folder.
-
-
-|| *File* || *Simulation* ||
-|| test1.xml || SourceFacility -> GreedyMarket -> SinkFacility ||
-|| test2.xml || SourceFacility -> GreedyMarket -> 2 x SinkFacility ||
-|| test3.xml || 2 x SourceFacility -> GreedyMarket -> SinkFacility ||
-|| test4.xml || 2 x SourceFacility -> GreedyMarket -> 2 x SinkFacility ||
-|| test5.xml || SourceFacility -> GreedyMarket A -> NullFacility -> GreedyMarket B -> SinkFacility ||
-|| test6.xml || SourceFacility -> GreedyMarket A -> 2 x NullFacility -> GreedyMarket B -> SinkFacility ||
-|| test1null.xml || SourceFacility -> NullMarket -> SinkFacility ||
-|| test2null.xml || SourceFacility -> NullMarket -> 2 x SinkFacility ||
-|| test3null.xml || 2 x SourceFacility -> NullMarket -> SinkFacility ||
-|| test4null.xml || 2 x SourceFacility -> NullMarket -> 2 x SinkFacility ||
-|| test5null.xml || SourceFacility -> NullMarket A -> NullFacility -> NullMarket B -> SinkFacility ||
-|| test6null.xml || SourceFacility -> NullMarket A -> 2 x NullFacility -> NullMarket B -> SinkFacility ||
-
-
-= Output Format =
-Some output format must be defined for this milestone too, in order to parametrically tests input variation of these simulations.
diff --git a/_sources/wiki/MilestoneOneInpro.txt b/_sources/wiki/MilestoneOneInpro.txt
deleted file mode 100644
index 215f4c570..000000000
--- a/_sources/wiki/MilestoneOneInpro.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-#summary Defining the capabilities to be demonstrated at Milestone INPRO_01
-#labels Phase-Requirements
-
-= Introduction =
-
-This is an early milestone for Cyclus development based on a simple once-through INPRO study.
-
-*Target Date: 8/31/2010*
-
-= Details =
-
-This will build on the capabilities of MilestoneNullSimulation by adding:
- * EnrichmentFacility Model
- * DeployInst Model (or DeploymentRegion Model)
- * support for Decay in the Material class
- * RecipeReactorFacility Model
-
-There will also need to be some output methods/formatting and minor post-processing.
-
-The INPRO cases are not freely available, but Paul Wilson can be contacted for details.
diff --git a/_sources/wiki/MilestoneTwoNWTRB.txt b/_sources/wiki/MilestoneTwoNWTRB.txt
deleted file mode 100644
index 45c30deb9..000000000
--- a/_sources/wiki/MilestoneTwoNWTRB.txt
+++ /dev/null
@@ -1,305 +0,0 @@
-#summary Defining the capabilities to be demonstrated during Milestone-NWTRB
-#labels Phase-Requirements
-
-= Introduction =
-
-This is an early milestone for Cyclus development based on a set of Nuclear
-Waste Technical Review Board scenario definitions and desired output measures.
-
-*Target Date: 5/16/2011*
-
-= Details =
-
-This benchmarking and demonstration activity happens in four phases and will be
-presented at the NWTRB systems analysis workshop in June 2011. Details of
-scenario descriptions and assumptions may be found in the file :
- * !Scenarios_Final_04April2011.PDF
-
-----
-
-= Phase I : Characteristics of Spent Fuel Inventory as of December 2009 =
-
-*Target Date : 4/11/2011*
-
-== Assumptions ==
-
-Details of power plant characteristics and spent fuel inventories as of
-December 2009 are provided internally to workshop participants in:
- * !ExistingPlantData_06March2011.pdf
-
-== Phase I : Output Measures ==
-
- # Total mass of spent fuel in Jan 2010
- # Total mass of ( 234, 235, 236, and 238 ) U in SNF in Jan 2010 Total mass
- # of ( 238, 239, and 240 ) Pu in SNF in Jan 2010
- # Mass of FPs and MAs(Np, Am, Cm, Bk, Cf, Es, Fm) in SNF in Jan 2010
-
-== Phase I : Cyclus Simulation Description ==
-
-This will be a 1 month simulation, finding the spent fuel streams in January
-2010 resulting from the state of domestic spent fuel streams in December 2009.
-Reactors will be implemented as recipe based models. Storage facilities associated
-with each reactor will contain current amounts of spent fuel. The only commodities will
-be fresh and spent BWR and PWR assemblies.
-
-== Phase I : Feature Requirements ==
-
-This will build on the capabilities of MilestoneNullSimulation and
-MilestoneOneInpro by adding:
- * a facility catalog of facility models representing the domestic reactor
- fleet as of December 2009.
- * a material catalog of fresh and spent BWR and PWR assemblies
- * an in/out database system capable of keeping sufficient data about
- transactions to give output measures.
- * a bookkeeping system that records material changes and transactions into
- the in/out database
- * a storage facility capable of being instantiated with an initial quantity
- of material
- * Recipes : PWR I and BWR I
-----
-
-= Phase II : Spent Fuel Discharged Through 2100 =
-*Target Date : 4/18/2011*
-
-== Phase II : Assumptions ==
-
-Plants operate beginning on January 1 of the year of commercial operation and
-all plants operatre for 60 years.
-
-Deployment is driven by maintenance of current fleet 100.3GWe .
-
-
-== Phase II : Output Measures ==
-
- # BWR assemblies discharged
- # PWR assemblies discharged
- # Total mass of ( 234, 235, 236, and 238 ) U in SNF during simulation
- # Total mass of ( 238, 239, and 240 ) Pu in SNF during simulation
- # Mass of FPs and MAs(Np, Am, Cm, Bk, Cf, Es, Fm) in SNF during simulation
-
-== Phase II : Cyclus Simulation Description ==
-
-This will be a 1081 month (90 years + 1 month) simulation. The start time is
-December 2009, the end time is January 1, 2100. Fresh and spent PWR and BWR
-assemblies are the only four commodities. While there is no official
-repository, a sink facility (or one for each reactor) should represent spent
-fuel storage on site.
-
-== Phase II : Feature Requirements ==
-
-
-This will build on the capabilities in Phase I by adding :
- * A facility model with finite lifetime (for 60 year shutdown).
- * A region or institution capable of maintaining fleet power capacity as
- reactors shut down. (!DemandDrivenDeployRegion ?)
- * Institutions must report the power capacity of all reactors they own
- * Reactors must record a timeline of their own power production
- * Recipes : PWR II and BWR II
-
-----
-
-= Phase III : Impact of Repository Disposal =
-
-*Target Date: 4/25/2011*
-
-== Phase III : Assumptions ==
-
-*Repository* begins in 2040. Repository takes >10 year old fuel, and oldest
-fuel first. Two scenarios:
- * 1,500 MT/year repository capacity
- * 3,000 MT/year repository capacity
-
-
-
-== Phase III : Output Measures ==
-
- # BWR assemblies discharged
- # PWR assemblies discharged
- # natural uranium demand (for use in phase IV)
-
-== Phase III : Cyclus Simulation Description ==
-
-This will be a 1081 month (90 years + 1 month) simulation. The start time is
-December 2009, the end time is January 1, 2100. Fresh and spent PWR and BWR
-assemblies are the only four commodities. Recipe-based reactor facilities and
-capacity-limited sink facility to represent the repository.
-
-== Phase III : Feature Requirements ==
-
-This will build on the capabilities in Phase II by adding :
- * Tracking of assembly age.
- * A market capable of handling competing spent fuel and new uranium as well
- as material ages
-
-----
-
-= Phase IV : Impact of Reprocessing and Repository Disposal =
-
-*Target Date: 5/16/2011*
-
-== Phase IV : Assumptions ==
-
-This is a steady state scenario. The reprocessing capacity is enough to consume
-all used fuel.
-
-Reprocessing takes >2 year old fuel, youngest first. Only single pass PWR fuel
-will be reprocessed. The rest is stored immediately. PWR MOX is fabricated.
-Re-enrichment is also undertaken to make PWR UOX.
-
-There is a steady state scenario:
- * All plants are steady state, no new or replacement plants starting up
- * Separating/Re-Enriching facility is at full capacity (sufficient?)
- * MOX fuel fab and reUOX have sufficient capacity to recycle all separated
- pu and u, respectively.
-
-There are six complexified scenarios :
- # Separating/Re-Enriching capacity of 1,500MT/yr and all fuel 5 yrs old
- # Separating/Re-Enriching capacity of 1,500MT/yr and all fuel 25 yrs old
- # Separating/Re-Enriching capacity of 1,500MT/yr and all fuel 50 yrs old
- # Separating/Re-Enriching capacity of 1,300MT/yr and all fuel 5 yrs old
- # Separating/Re-Enriching capacity of 1,300MT/yr and all fuel 25 yrs old
- # Separating/Re-Enriching capacity of 1,300MT/yr and all fuel 50 yrs old
-
-
-== Phase IV : Output Measures ==
-
- # Mass of PWR SNF Mass of BWR SNF Mass of FPs and MAs(Np, Am, Cm, Bk, Cf,
- Es, Fm) in SNF in Jan 2010
- # Mass of PWR SNF reprocessed Mass of BWR SNF reprocessed
- # Number, mass, and composition of assemblies fabricated
- * new uranium PWR assemblies
- * new uranium BWR assemblies
- * recycled uranium PWR assemblies
- * PWR MOX assemblies
- # Mass of uranium tails generated
- * new
- * recycled
-
-
-== Phase IV : Cyclus Simulation Description ==
-
-This will be a 1081 month (90 years + 1 month) simulation. The start time is
-December 2009, the end time is January 1, 2100. Fresh and spent PWR and BWR
-assemblies are the only four commodities. Two infinite source facilities,
-recipe-based reactor facilities and capacity limited sink facility must be
-implemented. Markets capable of dealing with reprocessed fuel streams,
-separations, MOX fabrication, re-enrichment, and enrichment facility models
-must also be used.
-
-== Phase IV : Feature Requirements ==
-
-This will build on the capabilities in Phase III by adding :
-
-
- * Separations Facility
- * Reprocessing Facility
- * Appropriate markets for reprocessed fuel streams
- * re-enrichment facility. Same as enrichment facility?
-
-
-----
-
-= Phase V : Impact of Reprocessing and Repository Disposal =
-
-*Target Date: 5/18/2011*
-
-== Phase V : Assumptions ==
-
-*Reprocessing* begins in 2030. Two scenarios :
- * 1,500 MT/year repository capacity
- * 3,000 MT/year repository capacity
-
-Reprocessing takes >5 year old fuel, youngest first. Only single pass PWR fuel
-will be reprocessed and all of it will be reprocessed eventually. The rest is
-stored immediately. PWR MOX is fabricated. Re-enrichment is also undertaken
-to make PWR UOX.
-
-*Repository* begins in 2040 at 1,500 MT/year repository capacity. Repository
-accepts only >10 year old fuel, and oldest fuel first.
-
-
-== Phase V : Output Measures ==
-
- # Total mass of PWR spent fuel in repository
- # Total mass of BWR spent fuel in repository
- # Mass of FPs and MAs(Np, Am, Cm, Bk, Cf, Es, Fm) in SNF
- # Mass of PWR SNF reprocessed Mass of BWR SNF reprocessed
- # Percent reduction in total natural U demand
- # Number, mass, and composition of assemblies fabricated
- * new uranium PWR assemblies
- * new uranium BWR assemblies
- * recycled uranium PWR assemblies
- * PWR MOX assemblies
- # Mass of uranium tails generated
- * new
- * recycled
-
-
-== Phase V : Cyclus Simulation Description ==
-
-This will be a 1081 month (90 years + 1 month) simulation. The start time is
-December 2009, the end time is January 1, 2100. Fresh and spent PWR and BWR
-assemblies are the only four commodities. Two infinite source facilities,
-recipe-based reactor facilities and capacity limited sink facility must be
-implemented. Markets capable of dealing with reprocessed fuel streams, separations, MOX fabrication,
-re-enrichment, and enrichment facility models must also be used.
-
-== Phase V : Feature Requirements ==
-
-This will build on the capabilities in Phase IV by adding :
-
- * Appropriate markets for competing fresh and reprocessed fuel streams
-
-
-== Summary of Cyclus Readiness ==
-
-The readiness level of cyclus capabilities with respect to the various phases
-is summarized below. Capabilities are rated from 0 (no one has given significant thought to this feature) to 10 (completely ready).
-
-|| *Phase 1* || *Phase 1* || *Phase 1* ||
-|| *Model or Capability* || *Readiness* || *Details* ||
-|| GreedyMarket || 10 || source material being 'infinite,' greedy market is an appropriate choice. ||
-|| NullRegion || 10 || This simulation is just for a month, so a deployregion isn't necessary, but would be superior.. ||
-|| FixedInst || 10 || the fixed inst is ready, perhaps until we go with the deployregion ||
-|| SourceFacility || 10 || The fuel fabrication facility is a simple source. ||
-|| ReceipeReactor || 8 || The recipe reactor needs a notion of its lifetime and capacity. ||
-|| SinkFacility || 10 || The material is actually stored at the reactors, but reported as a single amount. ||
-|| Facility Catalog || 10 || Roy is in charge. This includes all facilities to be included in the simulation.||
-|| Facility lifetimes || 0 || This should be a default behavior for all facilities. Not yet implemented. ||
-|| Recipes || 3 || Roy is working on this via scale/origen. ||
-|| Database || 8 || Transactions and Model tables are working. A material history table is left. ||
-|| PWR I || || PWR assemblies have initial uranium mass of 0.43 MTU, initial 235U enrichment of 3.43% and a burn-up of 39 GWd/MT. ||
-|| BWR I || || BWR assemblies have initial uranium mass of 0.18 MTU, initial 235U enrichment of 2.39% and a burn-up of 32 GWd/MT. ||
-|| *Phase 2* || *Phase 2* || *Phase 2* ||
-|| *Model or Capability* || *Readiness* || *Details* ||
-|| Phase 1 capabilities || || ||
-|| GreedyMarket || 10 || When the source materal ceases to be infinite, this may no be the best choice ||
-|| DeployRegion || 9 || Perhaps not on critical path. May need to use capacity info to maintain capacity of 100.3 GWe||
-|| SourceFacility || 10 || The fuel fabrication facility is a simple source. ||
-|| StorageFacility (s) || 9 || Deifining this according to its relationship with reactors may be tricky, but is perhaps unnecessary. ||
-|| Capacity Factors || 0 || This may need to be a default behavior for all facilities. Enums may be necessary. ||
-|| Recipes || 3 || Roy is working on this via scale/origen. ||
-|| PWR II || || PWR assemblies with initial 235U enrichment of 4.4% and a burn-up of 55 GWd/MT. ||
-|| BWR II || || BWR assemblies with initial 235U enrichment of 4.35% and a burn-up of 55 GWd/MT. ||
-|| Decay Capability || 10 || There may be some issues with binning "other" isotopes. ||
-|| *Phase 3* || *Phase 3* || *Phase 3* ||
-|| *Model or Capability* || *Readiness* || *Details* ||
-|| Phase 2 capabilities || || ||
-|| StorageFacility (s) || 9 || The material should actually just be stored at the reactors until 2040. Sink Facilities won't do. ||
-|| SinkFacility (repo) || 10 || The material starts to be sent to a repo facility from the storage facilities in 2040. ||
-|| *Phase 4* || *Phase 4* || *Phase 4* ||
-|| *Model or Capability* || *Readiness* || *Details* ||
-|| Phase 3 capabilities || || ||
-|| SmartMarket || ? || A market needs to be able to handle competition between spent fuel and new uranium. ||
-|| ReEnrichmentFacility || 9 || While an EnrichmentFacility exists, it must be modified to do re-enrichment including impurities. ||
-|| SepMatrixFacility || 5 || Roy is in charge. This will need to separate plutonium from PWR II spent assemblies. ||
-|| ReprocessingFacility I || 0 || PWR MOX will mix fresh U tails (235U assay 0.2%) with spent Pu (max Pu content of 14%).||
-|| ReprocessingFacility II || 0 || PWR UOX from re-enriched spent U (any enrichment necessary for criticality) ||
-|| Recipes || 3 || Roy is working on this via scale/origen. ||
-|| PWR MOX || || made from spent PWRII, mixes fresh U tails (235U assay 0.2%) with spent Pu (max Pu content of 14%).||
-|| PWR UOX || || PWR UOX will be re-enriched spent U (any enrichment necessary for criticality) ||
-|| STEADY STATE || 0-10? || The request is to do a "steady state" calculation. Can we require the absence of transients? ||
-|| *Phase 5* || *Phase 5* || *Phase 5* ||
-|| *Model or Capability* || *Readiness* || *Details* ||
-|| Phase 4 || || This simulation is a repeat of phase 4, but dynamic, and includes a repository. ||
-
diff --git a/_sources/wiki/MilestoneZero.txt b/_sources/wiki/MilestoneZero.txt
deleted file mode 100644
index 74d7d0b6f..000000000
--- a/_sources/wiki/MilestoneZero.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-#summary This wiki page documents progress on the first milestone.
-
-== Design material object data structure and creation =
-
-The material object is the main data object passed between black box facilities. An object structure is a necessary part of the interface between facilities.
-
-I like most of the functionality that Kyle set up in the Material class for GENIUS, so for this cyclus deadline, I'm going to mostly exactly replicate it. However, I have been working on aleviating one main area of concern, which has two main consequences.
-
- * The enumeration of commodities is not extensible.
- * In the event that a user would like to invent a new link in the fuel cycle chain, he'll have to break the modularity of the code in order to introduce it, since enums cannot be written to once they are initialized.
- * I am working on retooling this into some sort of more polymorphic enum-like structure (e.g. a map or a list) that allows reading and writing while continuing to allow some of the case switching that a lot of the rest of the code functions upon.
- * GENIUS occaisionally uses a material constructor that can generate a material object by naming the type of commodity it is. This relies on specific case switching over commodities in the material class and is an inextensible quality of the code. It is not possible to reformulate this without breaking the encapsulation that cyclus is striving for.
-
-== Design region & institution data structures ==
-
-The structure of the region and institution hierarchy should not deviate heavily from the GENIUS method, but may require modification in order to reference the runtime-generated map of facility and commodity types available for deployment. That is, since deployment of facilities may rely on these region and institution structures, the type maps may need to be available to the region/institution interfaces. TBD.
-
-== Design message passing infrastructure ==
-
-For facilities to offer, request, recieve and send material, a message passing infrastructure must be created. This will likely be similar to the message passing infrastructure in GENIUS, but may require modification in order to reference the runtime-generated map of facility and commodity types.
\ No newline at end of file
diff --git a/_sources/wiki/OutputDatabase.txt b/_sources/wiki/OutputDatabase.txt
deleted file mode 100644
index 44182d99c..000000000
--- a/_sources/wiki/OutputDatabase.txt
+++ /dev/null
@@ -1,125 +0,0 @@
-#summary Design Goals for the Output Database
-
-*Cyclus* simulations are comprised of three major constructs (the interaction of which we are interested in documenting). In *Cyclus*, *_Agents_* create *_Resources_* and then trade these resources via *_Transactions_*. Accordingly, the output database is nominally divided into three catagories: Agents, Resources, and Transactions. The *Cyclus* database has been designed with three key concepts in mind: we wish for *Cyclus* to be extensible, i.e. we do not want to hinder the development of a new module, we wish for the output data structures to be as straight-forward as possible to reduce hindrince of post-processing, and we wish for the database to be efficient. With these three goals in mind, we have developed a the database structure that sacrifices some amount of size (i.e., there are multiple entries per table which could be consolidated) in order to allow for greater flexibility and readability (i.e. natural intuition of where to look for a given data object). In this database paradigm, for example, an external developer has the ability to create a new agent type, and retrieve any information he/she wishes with regard to output. The database structure does not stunt a developer's ability or creativity.
-
-=Provenance=
-
-Good provenance will be provided by an output database with sufficient data to allow reproducibility of the results. This robust reproducibility is essential to the scientific effort. In the case of *Cyclus*, the inclusion of a complete notion of the input specifications in the output database will be sufficient to allow for result reproduction as well as facilitate knowledge sharing, post-simulation analysis and error-checking. Such input specifications include a complete description of the simulation parameters and model configurations defined in the input.
-
-=Database Structure=
-
-As previously mentioned, *Cyclus* deals in three basic constructs: agents, resources, and transactions. A transaction in *Cyclus* is relatively static, i.e. every transaction has the same basic information (for example: who is the sender, who is the receiever, what was transacted, etc.). Conversely, agents and resources are highly variable. We therefore allow for each /implementation/ of an agent (e.g. a Facility Agent) and each /type/ of resource (e.g. a Material) to have both *_Static_* and *_Dynamic_* tables associated with them. As will be outlined in detail below, the output database structure of a *Cyclus* simulation will have, in general, the following heirarchichal structure:
- */output/agents
- */output/agents/implementation/staticParams
- */output/agents/implementation/variableParams
- */output/resources
- */output/resources/type/staticParams
- */output/resources/type/variableParams
- */output/transactions
-
-Accordingly, there are currently seven primary tables in the *Cyclus* output database:
- * an [OutputDatabase#Agent_Description_Table agent description table]
- * an [OutputDatabase#Agent_Static_State_Parameter_Table agent static parameter table]
- * an [OutputDatabase#Agent_Variable_State_Parameter_Table agent dynamic parameter table]
- * a [OutputDatabase#Resource_Description_Table resource description table]
- * a [OutputDatabase#Resource_Static_State_Parameter_Table resource static parameter table]
- * a [OutputDatabase#Resource_Variable_State_Parameter_Table resource dynamic parameter table]
- * a [OutputDatabase#Transaction_Description_Table transaction description table]
-
-=Agent Description Table=
-
-This table contains the generic information of each agent and information regarding its time of creation and deletion. The table parameters are the following:
- * the agent's unique ID
- * the agent's parent's unique ID
- * the agent's type (e.g., Region, Institution, Market, etc.)
- * the agent's implementation (e.g., !SourceFacility, !NullRegion, !GreedyMarket, etc.)
- * a timestamp of the agent's birth
- * a timestamp of the agent's death
-
-Note that there is one entry for each unique agent.
-
-As an example, let us assume that a agent X of type is owned by an agent Y and is created at time t1. Agent X has type T and implementation I and ends its service at time t2. The table entry is as follows:
-
-|| Agent ID || Parent ID || Type || Implementation || Birth || Death ||
-|| X || Y || T || I || t1 || t2 ||
-
-=Agent Static State Parameter Table=
-
-This table contains information about specific instances of agents that *_do not change_* with time. This table is unique to each different *_implementation_* of agent. For instance, a Reactor may have the following class hierarchy: Agent -> Facility -> Reactor. Accordingly, there will be a data entry for the Reactor in each table, with the reactor-specific information placed in the Reactor table. There are some tables which are associated with the *Cyclus* core, and thus will have an immutable form at each release (e.g. Regions, Institutions, Facilities, Markets). It is the responsibility of each developer to guarantee that their module output corresponds to this hierarchical structure if it is to be included in a *Cyclus* release.
-
-Let us take the !SourceFacility as it currently exists in *Cyclus*. It has, nominally, three static members: its monthly production capacity, its total inventory size, and its output commodity. For this example, let us assume that !SourceFacility X has a maximum production capacity of Y kg/month of commodity C and has a maximum inventory size of Z kg. Its static state parameter table, located at /output/agents/!SourceFacility/staticParams would therefore look like the following:
-
-|| Agent ID || Commodity || Capacity || Capacity Units || Inventory || Inventory Units ||
-|| X || C || Y || kg/month || Z || kg ||
-
-=Agent Variable State Parameter Table=
-
-This table is similar to the static parameter table described above, containing information about specific instances of agents that *_do change_* with time. This table is unique to each different *_implementation_* of agent. For instance, a Reactor may have the following class hierarchy: Agent -> Facility -> Reactor. Accordingly, there will be a data entry for the Reactor in each table, with the reactor-specific information placed in the Reactor table. There are some tables which are associated with the *Cyclus* core, and thus will have an immutable form at each release (e.g. Regions, Institutions, Facilities, Markets). It is the responsibility of each developer to guarantee that their module output corresponds to this hierarchical structure if it is to be included in a *Cyclus* release.
-
-Let us continue with the above example. An optional parameter for the !SourceFacility is the capacity factor, i.e. the percentage of maximum capacity Y is the facility able to operate at some time t. For this example, let us assume that at time t1, !SourceFacility X begins operation with capacity factor 0.95 and must go down for maintenence at time t2, reducing its capacity factor to 0.00. Its variable state parameter table, located at /output/agents/!SourceFacility/variableParams would therefore look like the following:
-
-|| Agent ID || Capacity Factor || CF Units || Time ||
-|| X || 0.95 || decimal % || t1 ||
-|| X || 0.00 || decimal % || t2 ||
-
-Note that there may be multiple entries per agent in this table.
-
-Additionally note that the timestamping works in the following manner: if the timestamp is equal to the agent's birth time stamp, then this is the first occurance of the variable parameter; if it is not, then one may assume that the parameter did not change during the period between two timestamps.
-
-=Resource Description Table=
-
-This table contains the generic information of each resource and information regarding its time of creation and deletion. The table parameters are the following:
- * the resource's unique ID
- * the resource's creating agent's unique ID
- * the resource's type (material, man-hours, etc.)
- * the resource's base unit (kg, hours, etc.)
- * a timestamp of the resource's birth
- * a timestamp of the resoruce's death (i.e., when it is consumed, etc.)
-
-For example, let us assume that facility with unique ID X, creates a resource of type T at time t1 whose unique ID is Y, in addition, let us assume that the base unit type is kilograms. Finally, let us assume that the resource is eventually consumed by a chemical process (e.g., used-fuel being reprocessed) at time t2. The table entry for this resource is as follows:
-
-|| Resource ID || Creating Agent || Type || Unit || Birth || Death ||
-|| R || X || T || kg || t1 || t2 ||
-
-=Resource Static State Parameter Table=
-
-This table contains information about specific instances of resources that *_do not change_* with time. This table is unique to each different *_implementation_* of a resource. For instance, UO,,2,, may have the following class hierarchy: Resource -> Material -> UO2. Accordingly, there will be a data entry for the UO,,2,, in each table, with the UO,,2,,-specific information placed in the UO2 table. There are some tables which are associated with the *Cyclus* core, and thus will have an immutable form at each release (e.g. Material). It is the responsibility of each developer to guarantee that their module output corresponds to this hierarchical structure if it is to be included in a *Cyclus* release.
-
-Let us use the Material class as an example. The static table for the material resource is relatively straight-forward (most of the work is done by the dynamic table). As a convention in *Cyclus*, we do not allow Materials to change form (in order for a Material to change form, the original resource must be destroyed and a new resource created). Let us assume that some material resource with ID R (and type Material) has the form uo2.
-
-|| Resource ID || Form ||
-|| R || UO,,2,, ||
-
-=Resource Variable State Parameter Table=
-
-This table contains information about specific instances of resources that *_do change_* with time. This table is unique to each different *_implementation_* of a resource. For instance, UO,,2,, may have the following class hierarchy: Resource -> Material -> UO2. Accordingly, there will be a data entry for the UO,,2,, in each table, with the UO,,2,,-specific information placed in the UO2 table. There are some tables which are associated with the *Cyclus* core, and thus will have an immutable form at each release (e.g. Material). It is the responsibility of each developer to guarantee that their module output corresponds to this hierarchical structure if it is to be included in a *Cyclus* release.
-
-We choose to provide the following example. Suppose some facility receives N kilograms of Used UO,,2,, at time t1 /and/ that Used UO,,2,, has the ability to decay, i.e. it is radioactive. Consider the following two scenarios:
- # sufficient time has passed to take into account the decay of the Used UO,,2,,
- # an amount, n, of the Used UO,,2,, is traded to another agent
-
-For simplicity, we assume that used UO,,2,, is comprised of only ^16^O and ^235^U. The decay isotopics are meaningless and only meant to be a qualitative example.
-
-|| Resource ID || Mass || Isotopics || Composition || Composition Units || Timestamp ||
-|| R || N || 8016, 92235 || 0.33, 0.67 || atomic || t1 ||
-|| R || N || 8016, 92235 || 0.34, 0.66 || atomic || t2 ||
-|| R || N - n || 8016, 92235 || 0.34, 0.66 || atomic || t3 ||
-
-Note that there may be multiple entries per agent in this table.
-
-=Transaction Description Table=
-
-This table contains the generic information of each transaction. The table parameters are the following:
- * the transaction's unique ID
- * the sending agent's unique ID
- * the receiving agent's unique ID
- * the resource being transacted
- * the price for the transaction (assumed going from receiver to sender)
- * the timestamp of the transaction
-
-For example, let us assume agent X sends resource R to agent Y at time t for price P, and the transactions unique ID is U. The table entry, at /output/transactions/, would be as follows:
-
-|| Transaction ID || Sender || Receiver || Resource || Price || Timestamp ||
-|| U || X || Y || R || P || t ||
-
-Note that it is assumed that the amount is in the resource's base unit.
\ No newline at end of file
diff --git a/_sources/wiki/ProgramFlowAndDataStructureOverview.txt b/_sources/wiki/ProgramFlowAndDataStructureOverview.txt
deleted file mode 100644
index 01658b41a..000000000
--- a/_sources/wiki/ProgramFlowAndDataStructureOverview.txt
+++ /dev/null
@@ -1,75 +0,0 @@
-#summary Describe & Design Program Flow and Data Structures
-
-= Program Flow Overview =
-
- # Read input
- # Setup model
- # Start time steps
- * Tick: collect offers/requests
- * Market resolution
- * Tock: distribute material objects
-
-== Problem Setup ==
-
- # Load markets based on market models
- # for each market
- # check whether the model for this market has been loaded already, and load if necessary
- # instantiate new market and initialize parameters
- # Assign commodities to markets
- # Load facilities based on facility models
- # for each facility
- # check whether the model for this facility has been loaded already, and load if necessary
- # instantiate a template for a new facility based on input parameters
- # assign commodities to facilities and cross-reference with markets
- # add template to facility template map
- # Load regions based on region models
- # for each region
- # check whether the model for this region has been loaded already, and load if necessary
- # instantiate new region and initialize parameters
- # create list of available facility templates for that region
- # Load simulation parameters
-
-== Facility Deployment ==
-
-When and how does facility deployment happen, based on the list of facility templates?
-
-== Tick ==
-
- # cycle through Regions
- # cycle through Institutions
- # deploy new facilities as necessary
- # cycle through facilities
- # update facility state as appropriate
- # prompt for requests/offers
-
-== Market Resolution ==
-
- * convert sets of requests/offers into sets of material transactions
-
-== Tock ==
-
- # cycle through Markets
- # cycle through transactions
- # preform material transactions
- # update facility state as appropriate
-
-= Data Structure Overview =
-
-== Abstract Base Classes ==
-
-=== Communicator ===
-
-Provides all functionality for message passing among facilities and markets, including offers/requests and transactions.
-
-=== Facility ===
-
-Provides base definition of facility and standard interface. All derived classes must implement this interface cleanly so that they can operate as plug-in modules.
-
-=== Market ===
-
-Provides base definition of a market and standard interface. All derived classes must implement this interface cleanly so that they can operate as plug-in modules.
-
-=== Region ===
-
-Provides base definition of a region and standard interface. All derived classes must implement this interface cleanly so that they can operate as plug-in modules.
-
diff --git a/_sources/wiki/UserDocumentation.txt b/_sources/wiki/UserDocumentation.txt
deleted file mode 100644
index 833fa3138..000000000
--- a/_sources/wiki/UserDocumentation.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-#summary Documentation for Cyclus Users
-#labels Phase-Implementation
-
-Documentation to assist with the use of *Cyclus* will be maintained in a variety of forms.
-
-== Installation ==
-
-An instruction manual for GettingAndBuildingCyclus is available on this wiki. Questions having to do with this process may be directed to [https://code.google.com/u/katyhuff/ Katy Huff].
-
-== Model Definitions ==
-
-Instance descriptions and parameter definitions for models available to *Cyclus* simulations are made available on this wiki and can be browsed from the TableOfContents to the left of this text. As new Models and Utility functions are defined, wiki pages will be added to describe them.
-
-== Doxygen Code Documentation ==
-
-The definitive documentation of any software is the source code itself. *Cyclus* relies on Doxygen for automation of rich documentation from appropriately formatted comments in the source code. Current Doxygen documentation can be found at http://cnerg.engr.wisc.edu/cyclus/docs/ This page is automatically updated nightly.
\ No newline at end of file
diff --git a/_sources/wiki/main.txt b/_sources/wiki/main.txt
deleted file mode 100644
index 75b053546..000000000
--- a/_sources/wiki/main.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-
-Wiki Contents:
-
-.. toctree::
- :maxdepth: 2
-
- CyclusIntroduction
- CyclusStyleGuidelines
- Decay
-
-.. stuff not converted yet
-
- GettingAndBuildingCyclus
- ProgramFlowAndDataStructureOverview
- OutputDatabase
- UserDocumentation
- DevelopersDocumentation
-
-
- these are within developer doc
-
- * [CyclusStyleGuidelines Style Guidelines]
- * [GuidelinesForImplementingNewModels Guidelines for New Models]
- * [GuidelinesForImplementingNewFacilityModels Facility]
- * [GuidelinesForImplementingNewInstModels Inst]
- * [GuidelinesForImplementingNewRegionModels Region]
- * [GuidelinesForImplementingNewMarketModels Market]
-
- * Milestones
- * [MilestoneZero Basic Functionality]
- * [MilestoneNullSimulation 0: Null Simulation]
- * [MilestoneOneInpro 1: Inpro Simulation]
- * [MilestoneTwoNWTRB 2: NWTRB Simulations]
- * [MilestoneGenRepo 3: Generic Repository]
diff --git a/_static/default.css b/_static/default.css
deleted file mode 100644
index 21f3f5098..000000000
--- a/_static/default.css
+++ /dev/null
@@ -1,256 +0,0 @@
-/*
- * default.css_t
- * ~~~~~~~~~~~~~
- *
- * Sphinx stylesheet -- default theme.
- *
- * :copyright: Copyright 2007-2011 by the Sphinx team, see AUTHORS.
- * :license: BSD, see LICENSE for details.
- *
- */
-
-@import url("basic.css");
-
-/* -- page layout ----------------------------------------------------------- */
-
-body {
- font-family: sans-serif;
- font-size: 100%;
- background-color: #11303d;
- color: #000;
- margin: 0;
- padding: 0;
-}
-
-div.document {
- background-color: #1c4e63;
-}
-
-div.documentwrapper {
- float: left;
- width: 100%;
-}
-
-div.bodywrapper {
- margin: 0 0 0 230px;
-}
-
-div.body {
- background-color: #ffffff;
- color: #000000;
- padding: 0 20px 30px 20px;
-}
-
-div.footer {
- color: #ffffff;
- width: 100%;
- padding: 9px 0 9px 0;
- text-align: center;
- font-size: 75%;
-}
-
-div.footer a {
- color: #ffffff;
- text-decoration: underline;
-}
-
-div.related {
- background-color: #133f52;
- line-height: 30px;
- color: #ffffff;
-}
-
-div.related a {
- color: #ffffff;
-}
-
-div.sphinxsidebar {
-}
-
-div.sphinxsidebar h3 {
- font-family: 'Trebuchet MS', sans-serif;
- color: #ffffff;
- font-size: 1.4em;
- font-weight: normal;
- margin: 0;
- padding: 0;
-}
-
-div.sphinxsidebar h3 a {
- color: #ffffff;
-}
-
-div.sphinxsidebar h4 {
- font-family: 'Trebuchet MS', sans-serif;
- color: #ffffff;
- font-size: 1.3em;
- font-weight: normal;
- margin: 5px 0 0 0;
- padding: 0;
-}
-
-div.sphinxsidebar p {
- color: #ffffff;
-}
-
-div.sphinxsidebar p.topless {
- margin: 5px 10px 10px 10px;
-}
-
-div.sphinxsidebar ul {
- margin: 10px;
- padding: 0;
- color: #ffffff;
-}
-
-div.sphinxsidebar a {
- color: #98dbcc;
-}
-
-div.sphinxsidebar input {
- border: 1px solid #98dbcc;
- font-family: sans-serif;
- font-size: 1em;
-}
-
-
-
-/* -- hyperlink styles ------------------------------------------------------ */
-
-a {
- color: #355f7c;
- text-decoration: none;
-}
-
-a:visited {
- color: #355f7c;
- text-decoration: none;
-}
-
-a:hover {
- text-decoration: underline;
-}
-
-
-
-/* -- body styles ----------------------------------------------------------- */
-
-div.body h1,
-div.body h2,
-div.body h3,
-div.body h4,
-div.body h5,
-div.body h6 {
- font-family: 'Trebuchet MS', sans-serif;
- background-color: #f2f2f2;
- font-weight: normal;
- color: #20435c;
- border-bottom: 1px solid #ccc;
- margin: 20px -20px 10px -20px;
- padding: 3px 0 3px 10px;
-}
-
-div.body h1 { margin-top: 0; font-size: 200%; }
-div.body h2 { font-size: 160%; }
-div.body h3 { font-size: 140%; }
-div.body h4 { font-size: 120%; }
-div.body h5 { font-size: 110%; }
-div.body h6 { font-size: 100%; }
-
-a.headerlink {
- color: #c60f0f;
- font-size: 0.8em;
- padding: 0 4px 0 4px;
- text-decoration: none;
-}
-
-a.headerlink:hover {
- background-color: #c60f0f;
- color: white;
-}
-
-div.body p, div.body dd, div.body li {
- text-align: justify;
- line-height: 130%;
-}
-
-div.admonition p.admonition-title + p {
- display: inline;
-}
-
-div.admonition p {
- margin-bottom: 5px;
-}
-
-div.admonition pre {
- margin-bottom: 5px;
-}
-
-div.admonition ul, div.admonition ol {
- margin-bottom: 5px;
-}
-
-div.note {
- background-color: #eee;
- border: 1px solid #ccc;
-}
-
-div.seealso {
- background-color: #ffc;
- border: 1px solid #ff6;
-}
-
-div.topic {
- background-color: #eee;
-}
-
-div.warning {
- background-color: #ffe4e4;
- border: 1px solid #f66;
-}
-
-p.admonition-title {
- display: inline;
-}
-
-p.admonition-title:after {
- content: ":";
-}
-
-pre {
- padding: 5px;
- background-color: #eeffcc;
- color: #333333;
- line-height: 120%;
- border: 1px solid #ac9;
- border-left: none;
- border-right: none;
-}
-
-tt {
- background-color: #ecf0f3;
- padding: 0 1px 0 1px;
- font-size: 0.95em;
-}
-
-th {
- background-color: #ede;
-}
-
-.warning tt {
- background: #efc2c2;
-}
-
-.note tt {
- background: #d6d6d6;
-}
-
-.viewcode-back {
- font-family: sans-serif;
-}
-
-div.viewcode-block:target {
- background-color: #f4debf;
- border-top: 1px solid #ac9;
- border-bottom: 1px solid #ac9;
-}
\ No newline at end of file
diff --git a/_static/logo.png b/_static/logo.png
deleted file mode 100644
index a1227cbc4..000000000
Binary files a/_static/logo.png and /dev/null differ
diff --git a/_static/sidebar.js b/_static/sidebar.js
deleted file mode 100644
index a45e1926a..000000000
--- a/_static/sidebar.js
+++ /dev/null
@@ -1,151 +0,0 @@
-/*
- * sidebar.js
- * ~~~~~~~~~~
- *
- * This script makes the Sphinx sidebar collapsible.
- *
- * .sphinxsidebar contains .sphinxsidebarwrapper. This script adds
- * in .sphixsidebar, after .sphinxsidebarwrapper, the #sidebarbutton
- * used to collapse and expand the sidebar.
- *
- * When the sidebar is collapsed the .sphinxsidebarwrapper is hidden
- * and the width of the sidebar and the margin-left of the document
- * are decreased. When the sidebar is expanded the opposite happens.
- * This script saves a per-browser/per-session cookie used to
- * remember the position of the sidebar among the pages.
- * Once the browser is closed the cookie is deleted and the position
- * reset to the default (expanded).
- *
- * :copyright: Copyright 2007-2011 by the Sphinx team, see AUTHORS.
- * :license: BSD, see LICENSE for details.
- *
- */
-
-$(function() {
- // global elements used by the functions.
- // the 'sidebarbutton' element is defined as global after its
- // creation, in the add_sidebar_button function
- var bodywrapper = $('.bodywrapper');
- var sidebar = $('.sphinxsidebar');
- var sidebarwrapper = $('.sphinxsidebarwrapper');
-
- // for some reason, the document has no sidebar; do not run into errors
- if (!sidebar.length) return;
-
- // original margin-left of the bodywrapper and width of the sidebar
- // with the sidebar expanded
- var bw_margin_expanded = bodywrapper.css('margin-left');
- var ssb_width_expanded = sidebar.width();
-
- // margin-left of the bodywrapper and width of the sidebar
- // with the sidebar collapsed
- var bw_margin_collapsed = '.8em';
- var ssb_width_collapsed = '.8em';
-
- // colors used by the current theme
- var dark_color = $('.related').css('background-color');
- var light_color = $('.document').css('background-color');
-
- function sidebar_is_collapsed() {
- return sidebarwrapper.is(':not(:visible)');
- }
-
- function toggle_sidebar() {
- if (sidebar_is_collapsed())
- expand_sidebar();
- else
- collapse_sidebar();
- }
-
- function collapse_sidebar() {
- sidebarwrapper.hide();
- sidebar.css('width', ssb_width_collapsed);
- bodywrapper.css('margin-left', bw_margin_collapsed);
- sidebarbutton.css({
- 'margin-left': '0',
- 'height': bodywrapper.height()
- });
- sidebarbutton.find('span').text('»');
- sidebarbutton.attr('title', _('Expand sidebar'));
- document.cookie = 'sidebar=collapsed';
- }
-
- function expand_sidebar() {
- bodywrapper.css('margin-left', bw_margin_expanded);
- sidebar.css('width', ssb_width_expanded);
- sidebarwrapper.show();
- sidebarbutton.css({
- 'margin-left': ssb_width_expanded-12,
- 'height': bodywrapper.height()
- });
- sidebarbutton.find('span').text('«');
- sidebarbutton.attr('title', _('Collapse sidebar'));
- document.cookie = 'sidebar=expanded';
- }
-
- function add_sidebar_button() {
- sidebarwrapper.css({
- 'float': 'left',
- 'margin-right': '0',
- 'width': ssb_width_expanded - 28
- });
- // create the button
- sidebar.append(
- '
«
'
- );
- var sidebarbutton = $('#sidebarbutton');
- light_color = sidebarbutton.css('background-color');
- // find the height of the viewport to center the '<<' in the page
- var viewport_height;
- if (window.innerHeight)
- viewport_height = window.innerHeight;
- else
- viewport_height = $(window).height();
- sidebarbutton.find('span').css({
- 'display': 'block',
- 'margin-top': (viewport_height - sidebar.position().top - 20) / 2
- });
-
- sidebarbutton.click(toggle_sidebar);
- sidebarbutton.attr('title', _('Collapse sidebar'));
- sidebarbutton.css({
- 'color': '#FFFFFF',
- 'border-left': '1px solid ' + dark_color,
- 'font-size': '1.2em',
- 'cursor': 'pointer',
- 'height': bodywrapper.height(),
- 'padding-top': '1px',
- 'margin-left': ssb_width_expanded - 12
- });
-
- sidebarbutton.hover(
- function () {
- $(this).css('background-color', dark_color);
- },
- function () {
- $(this).css('background-color', light_color);
- }
- );
- }
-
- function set_position_from_cookie() {
- if (!document.cookie)
- return;
- var items = document.cookie.split(';');
- for(var k=0; k
-
-
-
-
-
-
- Radioactive Decay in Cyclus — Cyclus
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
where the vector N(t) contains the number density of all the
-isotopes being considered at time t, and A is called the decay
-matrix. The solution to this differential equation can be expressed in terms
-of a matrix exponential:
-
-
\mathbf{N(\mathit{to+\Delta t})}=e^{\Delta t \textrm{A}}\: \mathbf{N(\mathit{to})}
-
The decay method currently implemented in Cyclus computes this matrix
-exponential solution at any given time using a series approximation known as
-the Uniformization Method. This implementation was written by Kerry Dunn, and
-is explained in more detail below.
The Uniformization Method is essentially a modification of the truncated Taylor
-Series expansion of the matrix exponential solution, which can be described by
-the following summation:
-
-
\mathbf{N(\mathit{to+\Delta t})}\approx \sum_{k=0}^{p}\frac{\left (\Delta t \right )^k}{k!}\: \textrm{A}^k\: \mathbf{N(\mathit{to})}
-
The primary disadvantage of using this Taylor Series expansion to compute the
-matrix exponential solution is that it can be subject to cancellation error as
-a result of summing terms with alternating signs. These terms with alternating
-signs occur because the diagonal elements in the decay matrix that represent
-the decay constants are all negative. Therefore, in order to eliminate the
-potential for cancellation error, the decay matrix must be modified so that it
-no longer contains these negative elements. This modification process is known
-as the uniformization technique.
-
The first step in applying the uniformization technique is to define
-alpha to be equal to the absolute value of the maximum diagonal
-element of A:
-
-
\alpha=max_i\left | a_i_i \right |
-
Then, given alpha, the next step is to redefine the matrix
-exponential solution using a different matrix P:
-
-
\textrm{P}=\frac{1}{\alpha}\textrm{A}+\textrm{I}
-
where I is the identity matrix. Note that P is completely non-negative, so a
-Taylor Series expansion of this matrix exponential is not subject to the same
-cancellation error that occurs with the original decay matrix. By replacing A
-with P, the matrix exponential solution can now be expressed by the following
-summation:
-
-
\mathbf{N(\mathit{to+\Delta t})}=e^{-\alpha \Delta t}\: e^{\Delta t (\alpha \textrm{P})}\: \mathbf{N(\mathit{to})}\approx e^{-\alpha \Delta t}\sum_{k=0}^{p}\frac{\left (\Delta t \right )^k}{k!}\: (\alpha \textrm{P})^k\: \mathbf{N(\mathit{to})}
-
Note that this modified Taylor Series expansion can also be expressed in terms
-of the original matrix A by substituting the definition for P:
When adding a new isotope, the most important thing to take into account is its
-half-life or decay constant. The isotope with the smallest half-life, or
-largest decay constant, will be the limiting factor for the time scale over
-which Cyclus can decay _all_ materials in one step. This occurs because the
-Uniformization Method requires the computation of an exponential term, which is
-limited by the size of a long double on the system being used to run Cyclus.
-To determine the maximum time scale that will be valid for a particular group
-of isotopes, the following equation can be used:
where LDBL_MAX is the size of a long double and \lambda is the
-largest decay constant of the group of isotopes being considered.
-
As an example, suppose that the isotope with the smallest half-life being
-considered is Cm-232. This particular isotope has a decay constant of 1.5532
-nuclei per year. If the size of a long double is limited to LDBL_MAX =
-1.18973e+4932, then all materials can only be decayed for a maximum of 7311
-years. Adding any isotopes with a half-life smaller than Cm-232 would result
-in an even lower maximum time scale.
#. Cleve Moler and Charles van Loan, “Nineteen Dubious Ways to Compute the
-Exponential of a Matrix, Twenty-Five Years Later,” SIAM Review, 45,
-3-49 (2003)
-
#. Erwin Muller, Frederik Reitsma and Paulus P. Kruger, “A Stable Nuclide
-Transmutation Procedure Free of Numerical Roundoff,” PHYSOR 2006, September
-10-14, Vancouver, Canada (2006)
-
#. R. B. Sidje and W. J. Stewart, “A numerical study of large sparse matrix
-exponentials arising in Markov chains,” Computational Statistics & Data
-Analysis, 29, 345-368 (1999)
The purpose of this page is to introduce some general style guidelines to help
-with readability, maintainability and extensibility of the cyclus code base.
Line lengths, tab spacing, and bracket placement will conform to the google c++
-style standard as much as possible. This requires that all tabs be replaced by
-spaces, and that an indentation is equal to two spaces. Further information on
-this style standard can be found in the Google Style Guide.
-
Notable items:
-
-
-
no tabs - expand all tabs to 2 spaces.
-
enum items should be all caps
-
trailing underscores must be used with all class member variables
-
opening braces should be placed on the same line as function args: ReturnType functionName(Arg1Type arg_name) {
-
loop and branching statements should use the opening and closing braces (i.e. not like this: if (true) long_statement;)
The purpose of this page is to introduce some general style guidelines to help
-with readability, maintainability and extensibility of the cyclus code base.
Line lengths, tab spacing, and bracket placement will conform to the google c++
-style standard as much as possible. This requires that all tabs be replaced by
-spaces, and that an indentation is equal to two spaces. Further information on
-this style standard can be found in the Google Style Guide.
-
Notable items:
-
-
-
no tabs - expand all tabs to 2 spaces.
-
enum items should be all caps
-
trailing underscores must be used with all class member variables
-
opening braces should be placed on the same line as function args:
-ReturnType functionName(Arg1Type arg_name) {
-
loop and branching statements should generally use the opening and closing
-braces (i.e. not like this: if (true) long_statement;)
-
-
-
\ No newline at end of file
diff --git a/searchindex.js b/searchindex.js
index c9b6ba608..a9d2c4441 100644
--- a/searchindex.js
+++ b/searchindex.js
@@ -1 +1 @@
-Search.setIndex({objects:{},terms:{all:[0,1,14,4,5,6,7,9,10,13,8,15],concept:[12,13],skeleton:0,chain:7,oss:0,lack:13,month:[9,15,12],kati:[3,4,16],signific:[3,13],code:[0,1,2,3,4,10,13,14,16],abil:[12,13],edu:[1,16],follow:[0,2,4,7,10,12,13,14],katyhuff:[4,16],hierarch:[10,12],whose:[12,13],privat:[14,13],complet:[0,3,12,7,13],depend:[11,10,4,2,13],staticparam:12,sensit:13,effort:[12,13],decim:12,readabl:[14,12],specif:[0,1,2,5,8,9,10,12,13,14,15],send:[5,12],logician:0,program:[1,10,6,13],sendmessag:5,decis:[2,13],under:4,aris:7,introduc:[0,14],passiv:13,"case":[12,13],consum:12,premium:13,string:[0,4],resoruc:12,"void":0,constructor:[0,14],util:[16,13],newtyp:0,mechan:[15,13],govern:13,veri:[0,2],frederik:7,brows:[0,16],relev:[1,13],gidden:3,hour:[10,12],level:[0,3,13],did:12,notabl:14,gui:10,list:[0,6],geograph:13,"\ufb02exibl":3,"try":4,item:14,vector:[15,7],progress:7,team:13,quick:[4,2,13],markov:7,ddd:4,setup:[10,6],dir:4,yolinux:0,smaller:7,natur:12,resourc:[1,12],direct:[0,16,4,13],cosi:13,sign:7,second:[4,5],design:[10,2,12,13],aggreg:13,nwtrb:[],pass:[6,12,15],download:[10,2],further:[0,14],functionnam:14,click:10,even:7,index:0,what:[10,4,12],sub:[0,13],preserv:3,neg:7,section:14,abl:[3,12],"while":[0,5,13],uniform:[11,7],current:[0,1,4,7,11,12,13,16],delet:[0,12],experiment:3,roundoff:7,deepli:13,boost:[10,4],"public":[14,13],regionmodel:[0,5,15],elimin:7,nuclid:7,led:3,deriv:[0,6],consolid:12,gener:[1,3,2,4,5,8,10,12,13,14],never:4,greedymarket:12,sophist:13,here:0,modular:13,configure_trilino:2,let:[3,12],committ:4,debugg:4,trunk:[4,2,13],path:[10,4,13],becom:[0,4],modifi:[3,7],sinc:[0,13],valu:[0,7],great:[3,4,2],sender:12,hdf5:[10,4],technolog:13,host:4,adopt:13,amount:12,base:[0,2,5,6,8,9,12,13,14,15],"_all_":7,social:13,action:[10,13],studi:7,explain:7,novic:2,via:[10,4,2,12],volunt:13,primit:0,modul:[0,1,2,6,10,12,13],prefer:[10,2,13],sgi:0,filenam:4,unix:[4,2],instabl:3,instal:[3,10,4,2,16],txt:[0,4],dangl:0,select:[3,10,15],highli:[2,12,13],bookkeep:[9,15],from:[0,1,2,4,5,9,10,12,13,8,15,16],describ:[0,12,7,16],would:[10,4,12,7],commun:[0,5,6,9,13,8,15],distinct:5,"super":13,univers:13,visit:13,two:[0,14,4,5,10,12,13],dure:[1,12],next:[3,10,7,13],websit:[10,2],call:[0,4,7,13],bedrock:13,recommend:4,basi:13,type:[0,1,2,3,4,9,10,12,13,15],more:[3,10,4,7,13],desir:13,relat:[15,13],benchmark:13,finit:13,enhanc:0,trail:14,flag:[10,4,2],kerri:7,prototyp:13,particular:[0,3,8,7,13],known:7,unpack:10,must:[0,2,4,6,7,10,12,8,14],reproduct:12,account:[12,7],graphic:13,retriev:12,valuabl:13,grant:13,prepar:10,outlin:[6,12],uniqu:12,histori:13,erwin:7,remain:0,minimum:4,returntyp:14,can:[1,2,4,6,7,10,13,14,16],learn:3,long_stat:14,purpos:[14,13],add_librari:0,appropri:[0,1,6,10,8,16],control:[4,13],defer:15,prompt:[4,6],genesi:13,give:0,process:[0,2,5,7,10,12,13,15,16],challeng:13,share:[0,10,2,12],indic:13,critic:13,sourc:[0,1,2,4,10,13,16],proprietari:13,explor:13,agenc:13,disadvantag:7,everi:[12,13],attract:13,occur:[12,7],differenti:7,multipl:[4,12],hoc:13,secur:13,rather:10,anoth:[0,10,12,13],write:13,how:[0,6],anyon:4,low:13,pure:[9,15],answer:13,instead:[1,10,4,2,13],simpl:13,idaho:13,polit:13,map:6,product:[12,13],recogn:[0,4,13],"recon\ufb01gur":3,after:[1,9,5,15,8],variant:10,gcc:10,usabl:13,embed:13,befor:[9,4,2,15],catalog:[],geolog:13,attent:[10,13],date:0,end:[9,15,12],underscor:14,philosophi:13,data:[1,14,5,6,7,9,12,13],parallel:13,physic:13,goal:[12,13],github:[4,13],essenti:[12,7],practic:13,third:13,date_tim:10,encapsul:13,trilinos_bild:10,favorit:10,correspond:12,element:[7,13],inform:[0,14,5,9,10,12,8,15],maintain:[1,14,16],environ:[10,4,11,13],incorpor:13,parti:13,volum:13,stewart:7,order:[14,4,7,12,13,8],origin:[5,12,7],nextid:0,composit:[12,13],help:14,receiev:12,anticip:13,over:7,move:10,mission:[11,13],trade:[5,12,13],through:[10,2,6,13],hierarchi:[12,13],effici:12,flexibl:[12,13],vari:13,dynam:[0,2,5,9,10,12,13,8,15],paramet:[1,3,5,6,12,13,15,16],style:[1,14],group:[3,14,7,13],matthew:3,build_shared_lib:10,platform:[10,4,13],window:[10,4],stubnewtyp:0,infrastructur:13,exchang:13,total:12,main:[9,8,4,5,15],might:[0,15],alter:2,non:[2,14,7,13],good:[2,12],"return":[0,10],greater:12,thei:[0,5,2,6,13],timestamp:12,libidn:10,initi:[0,14,6,13],nation:13,framework:13,facilit:[8,4,12,13],half:7,now:[10,4,7],"class":[0,1,14,5,6,9,12,8,15],introduct:[0,1,13,11,3],choic:[5,13],term:[3,7],eventu:12,grammar:0,name:[0,5],edit:[],separ:13,accommod:13,sidj:7,mode:[8,13],compris:[12,13],each:[0,3,14,5,6,9,12,13,15],debug:[4,11],found:[1,10,4,14,16],edif:2,higher:4,button:10,doxi:[],format:[1,14,16],compil:10,domain:13,replac:[14,7],individu:[5,13],dymond:13,procedur:[2,7],heavi:2,wrap:13,"static":[0,1,2,10,12,14],offerrequest:8,stubcommmodel:0,year:7,variableparam:12,our:4,happen:[4,6],trilinos_sourc:10,extract:10,special:13,out:[1,4],variabl:[0,1,14,4,10,12],accomplish:13,network:13,space:[10,4,14],facil:[0,5,6,9,12,13,8,15],robert:3,research:[11,13],categori:[14,13],optim:[4,13],rel:12,internet:10,print:0,bla:[10,2],correct:0,she:12,wisconsin:13,dunn:7,libraryarch:0,advanc:10,arg1typ:14,differ:[3,15,12,7,13],free:[8,10,7],dequ:8,small:13,reason:5,blas_library_nam:10,theori:0,ask:[10,4],org:4,limit:[7,13],muller:7,cxx:[10,4],care:2,precompil:10,std:0,"con\ufb01gur":3,indent:14,convent:12,thread:[10,2],capabl:[0,13],prescrib:15,could:[0,12],exponenti:7,synchron:4,mac:2,keep:[0,10],thing:[1,7],length:14,place:[0,2,10,12,13,14],due:[2,13],austin:13,assign:[0,14,6],first:[1,14,5,7,12,13],oper:[14,6,9,12,13,8,15],softwar:[1,3,16,4,13],rang:13,onc:[4,13],arrai:13,independ:[2,13],number:[2,7,13],capac:12,restrict:[10,13],mai:[0,2,4,9,10,12,13,15,16],instruct:[0,10,4,16],alreadi:[0,1,2,6,13],done:[4,2,12],construct:[0,12,13],lib:10,owner:4,stabl:[9,7],comic:1,open:[10,14,13],primari:[0,5,7,9,12,13,8,15],size:[12,7],given:[12,7],heirarchich:12,milestonetwonwtrb:[],nomin:12,script:[2,13],associ:12,top:0,hdf5_root:10,mkdir:[10,4],system:[1,3,2,4,5,7,11,13],messag:[9,8,5,6,15],inventori:12,too:10,statement:14,similarli:[0,13],termin:10,siam:7,compartment:13,unfett:13,"final":[0,10,12,13],schema:[0,4],creation:12,option:[9,10,15,12,13],tool:[3,13],copi:[0,5,4,2],isotop:[11,12,7],unhind:13,forward:12,"short":[10,2],pars:0,milestonezero:[],handletock:[9,15],than:[10,7],reinstal:2,wide:13,kind:13,target:[1,4],keyword:0,instanc:[0,5,15,12,16],provid:[0,3,2,5,6,9,10,12,13,8,15],marketmodel:[0,3,5,8],remov:2,stubmarket:0,stubstub:0,ubiqu:13,arg_nam:14,"18973e":7,dubiou:7,model_typ:0,stub:0,seri:7,pre:15,mini:0,sai:4,comput:[10,7,13],behavior:[9,3,15,13],installingdependenciesonunix:[],well:[0,10,12,13],modern:13,mind:[12,13],ani:[1,16,12,7,13],packag:[10,4,2],sourcefac:4,geniusv2:[],manner:[2,12],increment:0,deliv:13,need:[0,2,4,9,10,13,15],seen:13,"null":[],seek:13,trilinos_build:10,lapack_library_dir:10,wilson:3,engin:13,built:[1,10,4,2,15],equival:14,destroi:[0,12],paulu:7,note:[0,4,2,12,7],also:[0,5,7,9,10,13,8,15],discret:13,take:[10,2,12,7,13],which:[3,4,5,7,10,12,13],combin:[5,13],librari:[0,10,4,2,13],brace:14,divers:[1,3,13],singl:[0,13],analysi:[3,12,7,13],simplifi:[10,13],begin:[1,9,15,12,13],radioact:[3,11,12,7],allow:[2,5,10,12,13,15],fidel:13,usernam:4,price:12,object:[0,2,4,5,6,10,12,13],most:[0,3,7,10,12,13],prolifer:13,charl:7,cmakefil:4,deploi:[5,6],alpha:7,stubmodel:0,cap:14,xmlnodeptr:0,icon:10,sendmateri:5,simplic:12,paradigm:[0,3,8,12,13],placement:14,line:[0,2,14],doc:[1,16],later:7,flow:[1,6,13],drive:13,destruct:0,doe:[6,12,13],declar:14,determin:[15,7,13],databas:[1,10,12],accompani:13,constrain:13,left:[0,16],sum:7,cmakelist:[0,4],synapt:2,madison:13,reactor:[12,13],configure_lapack:2,consult:0,kruger:7,tableofcont:16,permiss:[4,2],carlsen:3,find:[10,4],xml:[0,4],absolut:7,onli:[0,1,2,7,12,13],locat:[0,2,4,10,12,13],acquir:[1,2],transact:[1,6,12,13],configur:[10,4,2,12],releas:12,written:[4,7],haven:1,version:[8,4],suppos:[12,7],analyz:13,rich:[1,16],factor:[12,7],fuel:[3,11,12,13],folder:2,darwin:2,local:[10,2,13],hindrinc:12,visual:13,meant:12,demonstr:13,contribut:[3,13],variou:13,get:[1,3,4,11,16],express:[7,13],fluid:13,secondari:13,reprocess:12,ldbl_max:7,mainten:12,usr:[10,2],program_opt:10,requir:[2,4,7,10,13,14],huff:[3,16],catagori:12,organ:[1,14],templat:[5,2,6],sacrific:12,method:[0,5,14,11,7],cleanli:6,continu:12,statist:7,contain:[0,12,7,15],septemb:7,where:[2,12,7,13],valid:[7,13],vision:[11,13],commod:[3,5,6,12],wiki:[7,16],conform:14,reduc:12,set:[0,3,4,5,6,9,10,13,8,15],aspect:13,commandlin:10,knowledg:12,search:[10,4],spars:7,milestoneoneinpro:[],see:[4,13],full:10,result:[8,10,5,12,7],arg:14,fail:10,close:[14,13],becaus:[7,13],servic:12,subject:7,expertis:13,mileston:[],statu:[11,13],kei:[3,12],correctli:[10,2],record:10,down:[9,15,12],nuclear:13,review:[2,7,13],particip:5,below:[12,7],daness:13,tend:13,state:[1,10,6,12,13],smallest:7,myriad:13,between:[8,15,12],"import":[0,4,2,7,13],experi:[3,13],approach:13,email:4,attribut:13,altern:[4,7],accord:[3,10],parent:[0,12],numer:7,were:10,inflex:13,posit:2,death:12,iostream:10,extens:[0,14,12,13],solv:13,market:[0,3,5,6,12,13,8,15],endl:0,popul:13,both:[0,3,12,13],protect:14,doxygen:[1,3,16],last:2,instmodel:[0,9,5,15],cycl:[3,14,6,11,13],similar:12,region:[0,5,6,9,12,13,15],equal:[14,12,7],shipment:[8,5],etc:[10,4,12],tutori:0,present:3,equat:7,agent:[1,12],logic:14,mani:[3,13],verif:13,com:[0,16,4,13],nullregion:12,comment:[1,16],among:[6,13],author:4,technic:13,point:2,instanti:[0,6],overview:[1,4,6],loan:7,inher:13,period:12,chmod:2,walk:[10,2],header:[2,10,14],taylor:7,cleve:7,linux:[0,10,2],cancel:7,respect:[0,9,15],throughout:13,assum:[0,12],xkcd:1,duplic:13,teucho:[10,4,2],divid:12,addition:12,inpro:[],convolut:13,three:[12,13],been:[4,6,12,13],destructor:14,whom:13,much:14,dlopen:0,interest:[3,4,12,13],modif:7,monthli:[9,15,12],addit:[5,9,10,12,13,8,15],trilino:[10,4,2],surplu:10,hesit:10,strategi:13,life:[14,7],wish:12,guidelinesforimplementingnewmodel:[9,8,5,15],stakehold:13,decai:[3,11,12,7],convert:6,"new":[0,1,4,5,6,7,9,11,12,13,8,15,16],gap:13,demand:15,standard:[1,2,14,6],convers:12,emploi:13,replic:[],multi:13,ident:7,look:12,amend:[9,15],straight:12,aim:13,defin:[0,3,5,7,12,15,16],g77:10,trilinos_enable_teucho:10,outcom:13,abov:[0,14,12,13],error:[12,7],fleet:13,anonym:4,loop:14,earli:[3,13],seven:12,engag:13,readi:10,libxml2:[10,4],metric:13,tabl:[1,12],therefor:[2,7,10,12,13,8],them:[3,10,2,12,16],sourcefacil:12,unit:12,transmut:7,utliz:4,conf:[],incom:8,engr:[1,16],pursu:13,pointer:[0,8,15],scienc:13,outdat:[0,1],develop:[0,1,14,3,4,5,9,12,13,8,15],welcom:3,minim:13,perform:[3,13],suggest:2,make:[0,1,2,4,10,13,15],government:13,cross:6,same:[0,14,12,7,13],member:[0,5,14,12,9],binari:10,complex:[3,13],largest:[7,13],pai:10,document:[1,3,12,16],difficult:13,nightli:16,cnerg:[1,3,16,4,13],structur:[1,10,6,12],fac_nam:5,expans:7,succinctli:13,assist:[1,16],cyclu:[0,1,2,3,4,5,7,10,11,12,13,14,16],driven:13,facilitymodel:[0,5,15],temporari:10,user:[3,2,4,5,10,13,16],ownership:13,improv:0,extern:[0,4,12],robust:[12,13],staticanddynam:0,respons:12,typic:13,expand:14,techniqu:7,recivemessag:[9,15],lower:7,task:[9,15,13],commensur:13,receiveofferrequest:8,relaxng:4,mention:12,commtyp:0,geniu:[3,13],thu:[12,13],sit:4,itself:[1,16],inherit:[9,8,5,15],without:3,qualit:12,exampl:[0,10,4,12,7],command:[10,4],thi:[0,1,2,3,4,5,6,7,8,9,10,12,13,14,15,16],choos:[10,12,13],entiti:13,undertaken:[9,15],model:[0,1,3,5,6,9,12,13,8,15,16],handletick:[9,15],guidelin:[1,14],dimension:13,ubuntu:2,usual:13,load:[2,5,6,9,10,8,15],stl:[8,15],identifi:13,entri:12,just:10,weekli:1,collabor:13,gdb:4,ldp:0,actor:[5,13],victim:13,stunt:12,increasingli:13,paul:[0,3,4],simultan:13,speed:2,yet:[9,4],languag:13,svnsync:4,rng:[0,4],rapid:13,cur:0,expos:13,modularli:[10,2],lapack:[10,4,2],scenario:[12,13],autom:[1,16],onward:10,except:0,dcmake_build_typ:4,fortran:10,add:[0,10,4,6],other:[0,1,14,4,10,13],densiti:7,compat:4,input:[0,4,5,6,12,13],successor:3,approxim:7,match:[0,3,8,13],build:[1,3,2,4,10,11,16],bin:10,transpar:13,read:[1,5,6,9,8,15],foundat:3,untar:2,utah:13,intuit:[12,13],regard:12,arriv:8,gettingandbuildingcyclu:10,five:7,know:5,birth:12,guid:[1,3,14,16],somewher:10,part:0,password:4,chemic:12,licens:13,measur:13,scan:4,like:[10,4,14,12,13],lost:13,should:[0,14,4,5,9,13,8,15],signal:[9,15],manual:[10,16],html:0,integ:13,collect:[3,6,13],benefit:13,necessari:[4,6,13],either:[15,13],have:[0,2,4,10,12,13,8,15,16],corpor:13,output:[0,1,4,12,13],mass:12,page:[1,2,4,7,10,14,16],underli:[3,13],www:[0,4],who:[12,13],deal:[3,12],interact:[15,12,13],some:[3,2,4,5,10,12,13,14],somehow:0,percentag:12,resolv:8,global:[0,13],intern:[0,4],sure:10,context:13,mirror:[10,4],home:0,successfulli:1,transport:13,distribut:[6,13],cmake_install_prefix:10,man:12,summat:7,implement:[0,14,5,6,7,9,11,12,13,8,15],lead:13,avoid:13,deploy:[9,15,5,6,13],definit:[0,1,2,3,6,7,14,16],ensur:[0,13],per:[12,7],substitut:7,suffici:12,larg:[7,13],newtypemodel:0,econom:13,content:[10,13],complic:4,refer:[0,1,6,7,9,11],hinder:[12,13],core:[0,3,4,12,13],encourag:[3,13],previou:13,run:[1,2,4,5,7,10],reitsma:7,post:12,"enum":14,broker:13,redefin:7,solut:[1,7,13],step:[4,2,6,7],newmarket:0,repositori:[11,4,2,13],immut:12,major:[12,13],appli:7,inclus:12,activ:[1,13],stage:3,plug:6,src:[0,4],about:[0,10,12,13],repeat:10,actual:4,constraint:13,materi:[6,7,12,13,8,15],complimentari:13,http:[0,1,16,4,13],simul:[3,6,10,11,12,13,16],stamp:12,milestonenullsimul:[],truncat:7,act:13,commit:4,disabl:4,block:3,cygwin:[10,4],blas_library_dir:10,own:[8,12,13],emphasi:13,consid:[12,7],tock:[9,6,15],init:0,cyclus_src_dir:4,regist:[0,8,4],within:[0,14,4,9,13,15],automat:[1,16],obstacl:13,diagon:7,creativ:12,environmet:10,contributor:13,chang:[0,3,2,4,12,13],updat:[0,1,6,16],subvers:4,storag:[0,8],your:[0,10,4,2],manag:[10,2,15,13],notion:12,recommenc:10,accordingli:12,certainli:0,van:7,log:13,wai:[0,5,7,13,8,15],area:[11,13],execut:[8,10,4,5,6],support:0,question:16,transform:13,"long":7,custom:13,avail:[0,5,6,10,13,16],start:[1,3,6],reli:[1,10,4,16],interfac:[9,6,13],includ:[0,2,4,6,10,12,13],suit:[],cyclusdoc:1,physor:7,resolut:6,paremet:[],machin:2,uo2:12,treat:[0,13],"function":[0,14,6,9,13,8,15,16],project:[3,4,11],properli:[],form:[1,16,12,13],offer:[3,5,6,13,8,15],altogeth:13,brand:4,basic:[3,12,13],twenti:7,idea:13,link:4,atom:12,nineteen:7,don:10,eas:13,"true":[14,13],sent:[9,15],extend:[0,1,13],notat:[],wisc:[1,16],made:[16,2,13],consist:[0,14,13],possibl:[14,12,13],whether:6,checkout:4,access:[14,13],googlecod:4,maximum:[12,7],cafca:13,howto:0,lapack_library_nam:10,receivemateri:5,growth:15,those:[0,8,15],time:[3,2,6,7,10,12,13],fundament:[1,3,11,13],problem:13,quickli:13,moler:7,expect:9,featur:3,loadabl:[0,1,13],creat:[0,1,4,5,6,12],certain:10,"abstract":6,meaningless:12,proven:[1,12],repres:[15,7,13],rerun:10,schedul:15,exist:[0,1,12,13],file:[0,1,2,4,10,13,14],guarante:[12,13],request:[3,5,6,13,8,15],strive:[10,2],encompass:13,work:[4,2,12,7],check:[1,10,4,6,12],probabl:0,tab:14,tick:[9,6,15],wast:13,googl:[0,4,14,16],want:[0,4,2,12],titl:[],when:[0,1,2,4,6,7,10,12,15],detail:[0,5,7,9,12,13,8,15],virtual:[9,14,15],"default":[0,9,10,2,15],bracket:14,role:13,futur:[4,13],branch:[0,14],varieti:[1,16,13],test:[],ignor:[9,15],you:[0,1,10,4,2],architectur:[3,13],node:0,canada:7,dispers:13,gigabyt:10,symbol:4,reccommend:2,milestonegenrepo:[],elsewher:10,scale:[7,13],reproduc:12,preform:6,previous:12,doubl:[10,7],uwgonuk:4,matrix:7,svn:[10,4,2],constant:7,receiv:[8,12],longer:7,algorithm:[3,4],scientif:12,directori:[0,10,4,2],vancouv:7,descript:[0,1,12,16],involv:13,kilogram:12,installingdependenciesonwindow:[],text:16,potenti:[7,13],institut:[0,5,6,9,12,13,15],cpp:[0,4],nuclei:7,cmake:[1,10,4],fpic:2},objtypes:{},titles:["Developing Models For Cyclus","Cyclus Developer Guide","Installing Dependencies on Unix","Cyclus","Getting and Building Cyclus","Developing Region Models","Program Flow and Data Structures","Radioactive Decay in Cyclus","Developing Market Models","Developing Institution Models","Installing Dependencies on Windows","Cyclus Fundamentals","Output Database","Introduction to the Cyclus Fuel Cycle Simulator","Style Guidelines for Developers","Developing Region Models","Cyclus User Guide"],objnames:{},filenames:["devdoc/make-models/main","devdoc/main","basics/dependencies_unix","index","basics/get_and_build","devdoc/make-models/facility","devdoc/flow_and_structure","basics/decay","devdoc/make-models/market","devdoc/make-models/institution","basics/dependencies_windows","basics/main","devdoc/output_dbase","basics/introduction","devdoc/style_guide","devdoc/make-models/region","usrdoc/main"]})
\ No newline at end of file
+Search.setIndex({objects:{},terms:{all:[0,1,2,4,5,6,7,9,10,13,8,15],code:[0,1,2,3,4,10,13,14,16],skeleton:1,chain:7,oss:1,lack:13,month:[9,15,12],kati:[3,4,16],signific:[3,13],concept:[12,13],abil:[12,13],edu:[0,16],follow:[1,2,4,7,10,12,13,14],katyhuff:[4,16],hierarch:[10,12],whose:[12,13],privat:[2,13],complet:[1,3,12,7,13],depend:[11,10,4,14,13],secur:13,xml:[1,4],sensit:13,nineteen:7,elsewher:10,readabl:[2,12],specif:[0,1,2,5,8,9,10,12,13,14,15],send:[5,12],effort:[12,13],logician:1,program:[0,10,6,13],sendmessag:5,decis:[14,13],under:4,aris:7,sent:[9,15],passiv:13,"case":[12,13],consum:12,premium:13,string:[1,4],resoruc:12,"void":1,util:[16,13],newtyp:1,mechan:[15,13],govern:13,veri:[1,14],frederik:7,brows:[1,16],relev:[0,13],gidden:3,valuabl:13,hierarchi:[12,13],level:[1,3,13],did:12,notabl:2,gui:10,list:[1,6],geograph:13,"\ufb02exibl":3,"try":4,item:2,vector:[15,7],progress:7,team:13,quick:[4,14,13],markov:7,refer:[0,1,6,7,9,11],overview:[0,4,6],prepar:10,dir:4,yolinux:1,smaller:7,natur:12,direct:[1,16,4,13],cosi:13,sign:7,second:[4,5],design:[10,14,12,13],aggreg:13,pass:[6,12,15],download:[10,14],further:[1,2],functionnam:2,click:10,even:7,index:1,what:[10,4,12],sub:[1,13],neg:7,sum:7,abl:[3,12],g77:10,uniform:[11,7],current:[0,1,4,7,11,12,13,16],delet:[1,12],version:[8,4],roundoff:7,"new":[0,1,4,5,6,7,9,11,12,13,8,15,16],boost:[10,4],method:[1,5,2,11,7],regionmodel:[1,5,15],elimin:7,nuclid:7,led:3,deriv:[1,6],absolut:7,gener:[0,3,2,4,5,8,10,12,13,14],never:4,greedymarket:12,sophist:13,here:1,modular:13,configure_trilino:14,modif:7,free:[8,10,7],variableparam:12,trunk:[4,14,13],path:[10,4,13],becom:[1,4],modifi:[3,7],sinc:[1,13],valu:[1,7],search:[10,4],sender:12,hdf5:[10,4],technolog:13,step:[4,14,6,7],later:7,amount:12,base:[1,2,5,6,8,9,12,13,14,15],"_all_":7,social:13,action:[10,13],chang:[1,3,14,4,12,13],explain:7,control:[4,13],via:[10,4,14,12],volunt:13,grammar:1,primit:1,approxim:7,prefer:[10,14,13],utah:13,sgi:1,filenam:4,unix:[4,14],instabl:3,instal:[3,10,4,14,16],total:12,dangl:1,select:[3,10,15],highli:[14,12,13],bookkeep:[9,15],from:[0,1,14,4,5,9,10,12,13,8,15,16],describ:[1,12,7,16],would:[10,4,12,7],commun:[1,5,6,9,13,8,15],distinct:5,doubl:[10,7],regist:[1,8,4],two:[1,2,4,5,10,12,13],next:[3,10,7,13],recommenc:10,call:[1,4,7,13],usr:[10,14],recommend:4,care:14,type:[0,1,14,3,4,9,10,12,13,15],more:[3,10,4,7,13],desir:13,kei:[3,12],relat:[15,13],benchmark:13,finit:13,enhanc:1,trail:2,flag:[10,4,14],kerri:7,prototyp:13,particular:[1,3,8,7,13],known:7,unpack:10,futur:[4,13],must:[1,2,4,6,7,10,12,8,14],reproduct:12,account:[12,7],graphic:13,retriev:12,hour:[10,12],setup:[10,6],outlin:[6,12],uniqu:12,histori:13,erwin:7,remain:1,itself:[0,16],returntyp:2,can:[0,2,4,6,7,10,13,14,16],learn:3,long_stat:2,purpos:[2,13],add_librari:1,appropri:[0,1,6,10,8,16],novic:14,defer:15,complic:4,prompt:[4,6],genesi:13,scan:4,process:[1,14,5,7,10,12,13,15,16],challeng:13,share:[1,10,14,12],termin:10,templat:[5,14,6],critic:13,minimum:4,proprietari:13,explor:13,agenc:13,everi:[12,13],attract:13,occur:[12,7],gcc:10,multipl:[4,12],hoc:13,sit:4,rather:10,anoth:[1,10,12,13],write:13,how:[1,6],anyon:4,pure:[9,15],answer:13,instead:[0,10,4,14,13],simpl:13,idaho:13,polit:13,map:6,product:[12,13],recogn:[1,4,13],"recon\ufb01gur":3,diagon:7,our:4,after:[0,9,5,15,8],variant:10,differenti:7,usabl:13,befor:[9,4,14,15],mac:14,geolog:13,attent:[10,13],mai:[1,14,4,9,10,12,13,15,16],end:[9,15,12],underscor:2,philosophi:13,data:[0,2,5,6,7,9,12,13],parallel:13,demonstr:13,goal:[12,13],"short":[10,14],essenti:[12,7],practic:13,third:13,date_tim:10,encapsul:13,grant:13,favorit:10,correspond:12,element:[7,13],inform:[1,2,5,9,10,12,8,15],maintain:[0,2,16],environ:[10,4,11,13],allow:[14,5,10,12,13,15],parti:13,volum:13,first:[0,2,5,7,12,13],order:[2,4,7,12,13,8],origin:[5,12,7],composit:[12,13],help:2,receiev:12,anticip:13,over:7,move:10,becaus:[7,13],trade:[5,12,13],through:[10,14,6,13],relaxng:4,emphasi:13,flexibl:[12,13],vari:13,dynam:[1,14,5,9,10,12,13,8,15],paramet:[0,3,5,6,12,13,15,16],style:[0,2],group:[3,2,7,13],treat:[1,13],binari:10,build_shared_lib:10,platform:[10,4,13],window:[10,4],complex:[3,13],transpar:13,infrastructur:13,creat:[0,1,4,5,6,12],decai:[3,11,12,7],main:[9,8,4,5,15],might:[1,15],alter:14,non:[2,14,7,13],good:[14,12],"return":[1,10],greater:12,thei:[1,5,14,6,13],timestamp:12,libidn:10,initi:[1,2,6,13],nation:13,framework:13,facilit:[8,4,12,13],half:7,now:[10,4,7],strive:[10,14],choic:[5,13],term:[3,7],document:[0,3,12,16],somewher:10,name:[1,5],van:7,separ:13,accommod:13,sidj:7,mode:[8,13],compris:[12,13],each:[1,3,2,5,6,9,12,13,15],debug:[4,11],found:[0,10,4,2,16],edif:14,higher:4,button:10,truncat:7,compil:10,domain:13,replac:[2,7],individu:[5,13],dymond:13,procedur:[14,7],heavi:14,contributor:13,"static":[0,1,2,10,12,14],expect:9,stubcommmodel:1,year:7,resourc:[0,12],happen:[4,6],trilinos_sourc:10,extract:10,special:13,out:[0,4],canada:7,accomplish:13,matrix:7,vancouv:7,open:[10,2,13],robert:3,research:[11,13],categori:[2,13],optim:[4,13],rel:12,internet:10,print:1,bla:[10,14],correct:1,statist:7,wisconsin:13,dunn:7,libraryarch:1,advanc:10,arg1typ:2,given:[12,7],committ:4,dequ:8,small:13,reason:5,blas_library_nam:10,theori:1,ask:[10,4],org:4,limit:[7,13],muller:7,repeat:10,basi:13,precompil:10,"con\ufb01gur":3,indent:2,nomin:12,thread:[10,14],prescrib:15,could:[1,12],script:[14,13],synchron:4,keep:[1,10],thing:[0,7],length:2,place:[1,2,10,12,13,14],releas:12,austin:13,licens:13,stewart:7,oper:[2,6,9,12,13,8,15],softwar:[0,3,16,4,13],major:[12,13],onc:[4,13],arrai:13,independ:[14,13],wast:13,system:[0,3,14,4,5,7,11,13],restrict:[10,13],date:1,instruct:[1,10,4,16],alreadi:[0,1,14,6,13],done:[4,14,12],construct:[1,12,13],lib:10,owner:4,stabl:[9,7],comic:0,custom:13,facil:[1,5,6,9,12,13,8,15],primari:[1,5,7,9,12,13,8,15],size:[12,7],idea:13,sourc:[0,1,14,4,10,13,16],heirarchich:12,convent:12,exponenti:7,associ:12,top:1,hdf5_root:10,mkdir:[10,4],capac:12,messag:[9,8,5,6,15],inventori:12,too:10,statement:2,similarli:[1,13],handletock:[9,15],siam:7,compartment:13,unfett:13,"final":[1,10,12,13],utliz:4,assign:[1,2,6],option:[9,10,15,12,13],tool:[3,13],copi:[1,5,4,14],lower:7,unhind:13,rerun:10,github:[4,13],accompani:13,twenti:7,number:[14,7,13],haven:0,receiveofferrequest:8,std:1,wide:13,kind:13,target:[0,4],keyword:1,provid:[1,3,14,5,6,9,10,12,13,8,15],marketmodel:[1,3,5,8],remov:14,structur:[0,10,6,12],exampl:[1,10,4,12,7],project:[3,4,11],ubiqu:13,arg_nam:2,were:10,posit:14,model_typ:1,stub:1,seri:7,pre:15,mini:1,sai:4,comput:[10,7,13],abov:[1,2,12,13],engag:13,modern:13,mind:[12,13],ani:[0,16,12,7,13],packag:[10,4,14],sourcefac:4,manner:[14,12],have:[1,14,4,10,12,13,8,15,16],disadvantag:7,need:[1,14,4,9,10,13,15],seen:13,previou:13,seek:13,trilinos_build:10,lapack_library_dir:10,wilson:3,engin:13,techniqu:7,equival:2,destroi:[1,12],note:[1,4,14,12,7],also:[1,5,7,9,10,13,8,15],discret:13,read:[0,5,6,9,8,15],build:[0,3,14,4,10,11,16],indic:13,combin:[5,13],brace:2,divers:[0,3,13],singl:[1,13],analysi:[3,12,7,13],simplifi:[10,13],begin:[0,9,15,12,13],radioact:[3,11,12,7],incorpor:13,"enum":2,fidel:13,usernam:4,price:12,object:[1,14,4,5,6,10,12,13],most:[1,3,7,10,12,13],prolifer:13,cygwin:[10,4],cmakefil:4,deploi:[5,6],alpha:7,stubmodel:1,cap:2,xmlnodeptr:1,icon:10,sendmateri:5,simplic:12,paradigm:[1,3,8,12,13],give:1,line:[1,2,14],doc:[0,16],adopt:13,init:1,drive:13,destruct:1,doe:[6,12,13],declar:2,determin:[15,7,13],databas:[0,10,12],pars:1,constrain:13,usual:13,modularli:[10,14],cmakelist:[1,4],synapt:14,madison:13,reactor:[12,13],configure_lapack:14,consult:1,kruger:7,cnerg:[0,3,16,4,13],tableofcont:16,permiss:[4,14],carlsen:3,find:[10,4],make:[0,1,14,4,10,13,15],involv:13,consolid:12,onli:[0,1,14,7,12,13],locat:[1,14,4,10,12,13],acquir:[0,14],transact:[0,6,12,13],configur:[10,4,14,12],solut:[0,7,13],written:[4,7],than:[10,7],experiment:3,suppos:[12,7],analyz:13,rich:[0,16],factor:[12,7],fuel:[3,11,12,13],folder:14,facilitymodel:[1,5,15],local:[10,14,13],meant:12,reinstal:14,contribut:[3,13],variou:13,get:[0,3,4,11,16],express:[7,13],fluid:13,secondari:13,reprocess:12,ldbl_max:7,mainten:12,program_opt:10,requir:[2,4,7,10,13,14],huff:[3,16],experi:[3,13],catagori:12,organ:[0,2],densiti:7,sacrific:12,throughout:13,"public":[2,13],stl:[8,15],she:12,contain:[1,12,7,15],staticparam:12,septemb:7,where:[14,12,7,13],valid:[7,13],vision:[11,13],commod:[3,5,6,12],wiki:[7,16],conform:2,set:[1,3,4,5,6,9,10,13,8,15],victim:13,commandlin:10,problem:13,knowledg:12,accord:[3,10],darwin:14,see:[4,13],full:10,result:[8,10,5,12,7],respons:12,fail:10,close:[2,13],improv:1,paul:[1,3,4],subject:7,expertis:13,stubstub:1,statu:[11,13],extend:[0,1,13],correctli:[10,14],record:10,nuclear:13,review:[14,7,13],particip:5,below:[12,7],daness:13,tend:13,state:[0,10,6,12,13],smallest:7,myriad:13,between:[8,15,12],"import":[1,4,14,7,13],author:4,entiti:13,approach:13,email:4,attribut:13,altern:[4,7],forward:12,spars:7,parent:[1,12],numer:7,wrap:13,inflex:13,dubiou:7,rapid:13,iostream:10,solv:13,market:[1,3,5,6,12,13,8,15],endl:1,addit:[5,9,10,12,13,8,15],both:[1,3,12,13],protect:2,doxygen:[0,3,16],last:14,instmodel:[1,9,5,15],extens:[1,2,12,13],moler:7,region:[1,5,6,9,12,13,15],certain:10,equal:[2,12,7],shipment:[8,5],etc:[10,4,12],instanc:[1,5,15,12,16],present:3,equat:7,agent:[0,12],logic:2,section:2,let:[3,12],verif:13,com:[1,16,4,13],nullregion:12,load:[14,5,6,9,10,8,15],among:[6,13],debugg:4,technic:13,point:14,instanti:[1,6],schedul:15,loan:7,inher:13,arriv:8,chmod:14,walk:[10,14],header:[2,10,14],taylor:7,differ:[3,15,12,7,13],checkout:4,linux:[1,10,14],cancel:7,typic:13,summat:7,mission:[11,13],xkcd:0,duplic:13,teucho:[10,4,14],three:[12,13],divid:12,fortran:10,addition:12,convolut:13,obstacl:13,been:[4,6,12,13],destructor:2,whom:13,much:2,dlopen:1,interest:[3,4,12,13],basic:[3,12,13],monthli:[9,15,12],deepli:13,popul:13,trilino:[10,4,14],surplu:10,hesit:10,strategi:13,life:[2,7],guidelinesforimplementingnewmodel:[9,8,5,15],stakehold:13,resolut:6,convert:6,reccommend:14,gap:13,decim:12,schema:[1,4],demand:15,univers:13,rang:13,standard:[0,2,14,6],convers:12,emploi:13,multi:13,therefor:[14,7,10,12,13,8],look:12,amend:[9,15],servic:12,tutori:1,aim:13,defin:[1,3,5,7,12,15,16],"while":[1,5,13],trilinos_enable_teucho:10,outcom:13,behavior:[9,3,15,13],error:[12,7],fleet:13,anonym:4,loop:2,bin:10,seven:12,increment:1,readi:10,libxml2:[10,4],metric:13,deliv:13,them:[3,10,14,12,16],stubmarket:1,sourcefacil:12,unit:12,transmut:7,encompass:13,incom:8,engr:[0,16],pursu:13,placement:2,pointer:[1,8,15],scienc:13,outdat:[0,1],develop:[0,1,2,3,4,5,9,12,13,8,15],welcom:3,minim:13,perform:[3,13],suggest:14,paulu:7,format:[0,2,16],exchang:13,cross:6,same:[1,2,12,7,13],member:[1,5,2,12,9],matthew:3,stubnewtyp:1,largest:[7,13],pai:10,eventu:12,difficult:13,nightli:16,http:[0,1,16,4,13],context:13,fac_nam:5,expans:7,succinctli:13,assist:[0,16],cyclu:[0,1,2,3,4,5,7,10,11,12,13,14,16],driven:13,capabl:[1,13],temporari:10,user:[3,14,4,5,10,13,16],ownership:13,mani:[3,13],extern:[1,4,12],robust:[12,13],staticanddynam:1,studi:7,expand:2,built:[0,10,4,14,15],recivemessag:[9,15],redefin:7,task:[9,15,13],commensur:13,trilinos_bild:10,scenario:[12,13],mention:12,commtyp:1,geniu:[3,13],thu:[12,13],well:[1,10,12,13],inherit:[9,8,5,15],qualit:12,without:3,command:[10,4],thi:[0,1,2,3,4,5,6,7,8,9,10,12,13,14,15,16],choos:[10,12,13],undertaken:[9,15],model:[0,1,3,5,6,9,12,13,8,15,16],handletick:[9,15],guidelin:[0,2],dimension:13,ubuntu:14,left:[1,16],comment:[0,16],identifi:13,entri:12,just:10,weekli:0,collabor:13,gdb:4,ldp:1,actor:[5,13],aspect:13,increasingli:13,isotop:[11,12,7],nextid:1,simultan:13,speed:14,yet:[9,4],languag:13,svnsync:4,death:12,cur:1,expos:13,lapack:[10,4,14],autom:[0,16],onward:10,wai:[1,5,7,13,8,15],except:1,dcmake_build_typ:4,cxx:[10,4],add:[1,10,4,6],other:[0,1,2,4,10,13],appli:7,compat:4,input:[1,4,5,6,12,13],blas_library_dir:10,successor:3,modul:[0,1,14,6,10,12,13],match:[1,3,8,13],take:[10,14,12,7,13],earli:[3,13],which:[3,4,5,7,10,12,13],government:13,preserv:3,foundat:3,untar:14,rng:[1,4],intuit:[12,13],period:12,gettingandbuildingcyclu:10,tabl:[0,12],five:7,know:5,birth:12,guid:[0,3,2,16],stunt:12,part:1,password:4,chemic:12,measur:13,ignor:[9,15],like:[10,4,2,12,13],lost:13,cleanli:6,should:[1,2,4,5,9,13,8,15],signal:[9,15],manual:[10,16],html:1,integ:13,collect:[3,6,13],benefit:13,necessari:[4,6,13],either:[15,13],reitsma:7,corpor:13,output:[0,1,4,12,13],page:[0,2,4,7,10,14,16],underli:[3,13],www:[1,4],who:[12,13],deal:[3,12],interact:[15,12,13],some:[3,2,4,5,10,12,13,14],somehow:1,percentag:12,resolv:8,global:[1,13],intern:[1,4],sure:10,act:13,respect:[1,9,15],home:1,successfulli:0,transport:13,distribut:[6,13],cmake_install_prefix:10,man:12,txt:[1,4],lead:13,assum:[1,12],fpic:14,deploy:[9,15,5,6,13],definit:[0,1,2,3,6,7,14,16],per:[12,7],substitut:7,larg:[7,13],newtypemodel:1,econom:13,content:[10,13],reproduc:12,ddd:4,hinder:[12,13],core:[1,3,4,12,13],encourag:[3,13],"18973e":7,run:[0,14,4,5,7,10],ident:7,broker:13,accordingli:12,host:4,newmarket:1,repositori:[11,4,14,13],immut:12,post:12,"super":13,activ:[0,13],stage:3,plug:6,src:[1,4],about:[1,10,12,13],actual:4,constraint:13,materi:[6,7,12,13,8,15],complimentari:13,introduct:[0,1,13,11,3],simul:[3,6,10,11,12,13,16],stamp:12,includ:[1,14,4,6,10,12,13],constructor:[1,2],commit:4,disabl:4,block:3,charl:7,arg:2,own:[8,12,13],effici:12,consid:[12,7],tock:[9,6,15],cyclus_src_dir:4,visit:13,within:[1,2,4,9,13,15],automat:[0,16],due:[14,13],down:[9,15,12],creativ:12,environmet:10,ensur:[1,13],updat:[0,1,6,16],subvers:4,storag:[1,8],your:[1,10,4,14],manag:[10,14,15,13],websit:[10,14],inclus:12,certainli:1,institut:[1,5,6,9,12,13,15],log:13,suffici:12,area:[11,13],execut:[8,10,4,5,6],support:1,question:16,transform:13,"long":7,"class":[0,1,2,5,6,9,12,8,15],avail:[1,5,6,10,13,16],start:[0,3,6],reli:[0,10,4,16],interfac:[9,6,13],low:13,cyclusdoc:0,physor:7,machin:14,uo2:12,bedrock:13,"function":[1,2,6,9,13,8,15,16],svn:[10,4,14],creation:12,form:[0,16,12,13],offer:[3,5,6,13,8,15],altogeth:13,great:[3,4,14],brand:4,regard:12,continu:12,link:4,atom:12,straight:12,don:10,eas:13,"true":[2,13],wisc:[0,16],made:[16,14,13],consist:[1,2,13],possibl:[2,12,13],whether:6,wish:12,access:[2,13],googlecod:4,maximum:[12,7],"abstract":6,cafca:13,howto:1,lapack_library_nam:10,receivemateri:5,growth:15,those:[1,8,15],fundament:[0,3,11,13],embed:13,quickli:13,similar:12,offerrequest:8,featur:3,loadabl:[0,1,13],physic:13,flow:[0,6,13],dure:[0,12],mirror:[10,4],meaningless:12,proven:[0,12],repres:[15,7,13],implement:[1,2,5,6,7,9,11,12,13,8,15],file:[0,1,2,4,10,13,14],guarante:[12,13],request:[3,5,6,13,8,15],exist:[0,1,12,13],work:[4,14,12,7],check:[0,10,4,6,12],probabl:1,tab:2,tick:[9,6,15],cmake:[0,10,4],googl:[1,4,2,16],want:[1,4,14,12],hindrinc:12,when:[0,1,14,4,6,7,10,12,15],detail:[1,5,7,9,12,13,8,15],virtual:[9,2,15],"default":[1,9,10,14,15],bracket:2,role:13,librari:[1,10,4,14,13],branch:[1,2],varieti:[0,16,13],mass:12,you:[0,1,10,4,14],architectur:[3,13],node:1,variabl:[0,1,2,4,10,12],dispers:13,gigabyt:10,symbol:4,introduc:[1,2],cleve:7,scale:[7,13],preform:6,previous:12,uwgonuk:4,network:13,reduc:12,constant:7,receiv:[8,12],longer:7,algorithm:[3,4],scientif:12,directori:[1,10,4,14],cycl:[3,2,6,11,13],space:[10,4,2],descript:[0,1,12,16],visual:13,kilogram:12,notion:12,text:16,potenti:[7,13],time:[3,14,6,7,10,12,13],cpp:[1,4],nuclei:7,avoid:13},objtypes:{},titles:["Cyclus Developer Guide","Developing Models For Cyclus","Style Guidelines for Developers","Cyclus","Getting and Building Cyclus","Developing Region Models","Program Flow and Data Structures","Radioactive Decay in Cyclus","Developing Market Models","Developing Institution Models","Installing Dependencies on Windows","Cyclus Fundamentals","Output Database","Introduction to the Cyclus Fuel Cycle Simulator","Installing Dependencies on Unix","Developing Region Models","Cyclus User Guide"],objnames:{},filenames:["devdoc/main","devdoc/make-models/main","devdoc/style_guide","index","basics/get_and_build","devdoc/make-models/facility","devdoc/flow_and_structure","basics/decay","devdoc/make-models/market","devdoc/make-models/institution","basics/dependencies_windows","basics/main","devdoc/output_dbase","basics/introduction","basics/dependencies_unix","devdoc/make-models/region","usrdoc/main"]})
\ No newline at end of file
- 
-
-