Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
B
Bayesian Cycle
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Iterations
Wiki
Requirements
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Test cases
Artifacts
Deploy
Releases
Package registry
Container registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Issue analytics
Insights
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
GitLab community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Nuclear Verification and Disarmament
Fuel Cycle and Enrichment
Bayesian Cycle
Commits
a41f2b8b
Commit
a41f2b8b
authored
3 years ago
by
Lewin Bormann
Browse files
Options
Downloads
Patches
Plain Diff
thesis: part 1 ch. 4 of Max' comments
parent
b37f522a
No related branches found
No related tags found
No related merge requests found
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
thesis/mainmatter/methodology.tex
+33
-35
33 additions, 35 deletions
thesis/mainmatter/methodology.tex
with
33 additions
and
35 deletions
thesis/mainmatter/methodology.tex
+
33
−
35
View file @
a41f2b8b
...
...
@@ -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 m
ixed
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 m
ulti
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 f
rom
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
o
f 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.
\
g
ls
{
randomseed
}
s are derived from a universal base seed (which is set to
\num
{
12345
}
), to which the instance ID is
\
G
ls
{
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
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment