Skip to content
Snippets Groups Projects
Commit a41f2b8b authored by Lewin Bormann's avatar Lewin Bormann :joy_cat:
Browse files

thesis: part 1 ch. 4 of Max' comments

parent b37f522a
No related branches found
No related tags found
No related merge requests found
......@@ -55,33 +55,31 @@ inference results. An \emph{experiment} in the context of this work means runnin
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\mysection{\cyclus}{methodology:cyclus}
\cyclus~is a nuclear fuel cycle simulator. It takes a fuel cycle specification in the
form of a \textsc{json} or \textsc{XML} document, and simulates a fuel cycle in many discrete steps, with a focus on
the flow of nuclear material. For example, \cyclus~simulates the enrichment of uranium before
its introduction into a reactor; the irradiation of fuel and the resulting power production in a reactor; the
subsequent reprocessing or selling of spent fuel; and the production of fissile or weapons-grade materials. \cyclus~is
very flexible, and can be extended in many ways. This flexibility is a result of the agent-based nature of \cyclus:
each facility, whether nuclear power plant or enrichment facility, is represented by an \emph{agent}. The agent can
trade with \emph{commodities} in order to fulfill its task; for example, an enrichment facility needs to purchase
\cyclus~is a nuclear fuel cycle simulator. It takes a fuel cycle specification, and simulates a fuel cycle in many
discrete time steps, with a focus on the flow of nuclear material. For example, \cyclus~simulates the enrichment of
uranium before its introduction into a reactor; the irradiation of fuel and the resulting power production in a reactor;
the subsequent reprocessing or selling of spent fuel; and the production of fissile or weapons-grade materials.
\cyclus~is very flexible, and can be extended in many ways. This flexibility is a result of the agent-based nature of
\cyclus: each facility, whether nuclear power plant or enrichment facility, is represented by an \emph{agent}. The agent
can trade with \emph{commodities} in order to fulfill its task; for example, an enrichment facility needs to purchase
natural uranium, and will offer enriched uranium on a virtual marketplace. The agents themselves are \gls{blackbox}es
and don't interact with each other except through exchange of \emph{commodities} (usual nuclear material), which
reduces the complexity of simulating a fuel cycle. Another way that \cyclus~manages to keep the simulation process
comparatively simple is by using an \emph{tick-tock} schedule; for each time step of \SI{1}{\day}, each agent has two
opportunities to discover the current simulation state and complete work:
once before the step (\emph{tick}), and once after (\emph{tock}). Between the tick and the
tock, a \emph{resource exchange} occurs, in which agents can exchange resources, usually nuclear
material. For example, a nuclear power plant may unload its reactor in the \emph{tick} phase, offer spent fuel and
obtain fresh fuel in the resource exchange phase, and add new fuel in the \emph{tock} phase. Agents
can also enter or leave a fuel cycle before respectively after a time step. This work doesn't make use of this feature,
and all agents exist for the entirety of the fuel cycle. \cite{HUFF201646,CyclusCEP20}
and don't interact with each other except through exchange of \emph{commodities} (usual nuclear material), which reduces
the complexity of simulating a fuel cycle. Another way that \cyclus~manages to keep the simulation process comparatively
simple is by using an \emph{tick-tock} schedule; for each time step of \SI{1}{\day}, each agent has two opportunities to
react to the current simulation state and complete work: once before the step (\emph{tick}), and once after
(\emph{tock}). Between the tick and the tock, a \emph{resource exchange} occurs, in which agents can exchange resources.
For example, a nuclear power plant may unload its reactor in the \emph{tick} phase, offer spent fuel and obtain fresh
fuel in the resource exchange phase, and add new fuel in the \emph{tock} phase. Agents can also enter or leave a fuel
cycle before respectively after a time step. This work doesn't make use of this feature, and all agents exist for the
entirety of the fuel cycle. \cite{HUFF201646,CyclusCEP20}
Agents are either built-in, defined as prototypes by an accompanying library called \textsc{Cycamore}, or can be
custom-built. In addition to these two kinds of agents, the fuel cycle simulated here also makes use of a library
called \cd{miso\_enrichment} written by Max Schalz, the supervisor of this work. \cd{miso\_enrichment} provides an
agent prototype called \cd{MIsoEnrich}, modelling a mixed isotope enrichment facility in a physically correct way.
called \cd{miso\_enrichment} written by Max Schalz. \cd{miso\_enrichment} provides an
agent prototype called \cd{MIsoEnrich}, modelling a multi isotope enrichment facility in a physically correct way.
It also provides another prototype called \cd{GprReactor}, which provides a reactor simulation. The specific
implementation is based on prior work expressing the reactor's characteristics based on \gls{gpr}, by first simulating
the reactor in \serpent~and interpolating based on the results from that simulation \cite{Antonio2019}. Because the
implementation is based on prior work expressing the reactor's characteristics using \gls{gpr} models, by first simulating
the reactor in \serpent~and interpolating from the results of that simulation \cite{Antonio2019}. Because the
simulation itself is time-consuming, results are stored as arrays (``kernels'') which are then consumed by the
\cd{miso\_enrichment} library. Using these two agents is essential to this work, as the predefined agents are not able
to provide these physically accurate calculations; \cyclus~itself is more focused on the interactions between agents,
......@@ -100,8 +98,10 @@ the course of sampling a specific fuel cycle (each sample requires different par
\cyclus~simulates the fuel cycle specified in its input, and generates an \textsc{\gls{SQLite}} database file
containing the entire simulation state as of the last time step. In this work, the database file rarely exceeded
\SI{400}{\kilo\byte}, and the run time of the simulation remained below \SI{2}{\second} on the \gls{hpc} nodes used for
the inference process. The resulting file is stored on a temporary \gls{filesystem} until the measurements have been
extracted.
the inference process. This relatively low use of resources allows running inference attempt within relatively small
time frames (less than one day) using a limited amount of computing resources. The simulation time is impacted by
increasing fuel cycle complexity and prolonged simulation time. The inference time also requires more simulation runs
for more unknown parameters being inferred.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\mysection{\cd{blackbox}: From Simulation Inputs to Likelihoods}{methodology:blackbox}
......@@ -149,9 +149,9 @@ result type is implemented as simple datastructure (\cd{namedtuple}).
In order to avoid duplicate calculations, \emph{memoization} is implemented by the \cd{CyclusLogLikelihood} class. The
likelihood for a parameter sample is stored in a lookup table, and returned without invocation of \cyclus~if the
sampling algorithm is trying to obtain the likelihood for the same parameter set later. For some runs, \SI{17}{\percent}
of \cyclus~simulations could be skipped (out of a total of more than $10^3$ simulations for each chain), each of which
would have taken up to three seconds.
sampling algorithm is trying to obtain the likelihood for the same parameter set later (the reason for this is unclear).
For some runs, \SI{17}{\percent} of \cyclus~simulations could be skipped (out of a total of more than $10^3$ simulations
for each chain), each of which would have taken up to three seconds.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\mysection{Driver: Where Inference Happens}{methodology:driver}
......@@ -167,15 +167,13 @@ quite simple:
\item Start sampling the model, intermittently saving traces (i.e., sample collections) to a durable storage space.
\end{enumerate}
Directly after the program has started execution, a log file is opened and all of the process output is sent to it. The
log file is usually located on the shared \gls{hpc} file system, and its name is derived from the experiment name, the
\emph{job} name (as in, cluster management system job), and the job ID (a large monotonically increasing integer), an
instance ID (starting at 1 up to the number of instances). This leads to unique log files for every single execution,
and the log files can be archived for later inspection in case of bugs or inference problems. They also contain
detailed information about the inference progress and calculated results. Log files will be used below to show that the
program works as intended.
Directly after the program has started execution, a log file is opened and all of the process output is sent to it.
Using both the job ID assigned by the cluster management system and each instance's serial ID creates unique log files
for every single execution. The log files can be archived for later inspection in case of bugs or inference
problems. They also contain detailed information about the inference progress and calculated results. Extracts from log
files will be used below to show that the program works as intended.
\gls{randomseed}s are derived from a universal base seed (which is set to \num{12345}), to which the instance ID is
\Gls{randomseed}s are derived from a universal base seed (which is set to \num{12345}), to which the instance ID is
added to produce the base seed. This guarantees that all jobs with the same instance ID will share the same random
seed. From the base seed, individual seeds for each Markov chain are derived, as well as auxiliary seeds (such as
randomized start values for the individual chains, or for the \emph{jitter} method described in
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment