-
Notifications
You must be signed in to change notification settings - Fork 0
/
origen-comparison.tex
115 lines (108 loc) · 6.83 KB
/
origen-comparison.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
As a more rigorous sanity check, the ORIGEN 2.2~\cite{ationneeded} library was
compared against for several time steps and starting nuclides. ORIGEN 2.2 was
run against 22 ORIGEN libraries (\texttt{amo0tttr.\allowbreak{}lib},
\texttt{amo1ttta.\allowbreak{}lib}, \texttt{amo1tttc.\allowbreak{}lib},
\texttt{amo2ttta.\allowbreak{}lib}, \texttt{amo2tttr.\allowbreak{}lib},
\texttt{amopttta.\allowbreak{}lib}, \texttt{amoptttc.\allowbreak{}lib},
\texttt{amoptttr.\allowbreak{}lib}, \texttt{amopuutc.\allowbreak{}lib},
\texttt{amopuuua.\allowbreak{}lib}, \texttt{amopuuuc.\allowbreak{}lib},
\texttt{amopuuur.\allowbreak{}lib}, \texttt{amoruuua.\allowbreak{}lib},
\texttt{amoruuur.\allowbreak{}lib}, \texttt{bwru.\allowbreak{}lib},
\texttt{bwrus.\allowbreak{}lib}, \texttt{canduseu.\allowbreak{}lib},
\texttt{crbra.\allowbreak{}lib}, \texttt{crbrc.\allowbreak{}lib},
\texttt{crbrr.\allowbreak{}lib}, \texttt{emopuuuc.\allowbreak{}lib},
\texttt{fftfc.\allowbreak{}lib}, \texttt{pwrdu3th.\allowbreak{}lib},
\texttt{pwrputh.\allowbreak{}lib}, \texttt{pwru.\allowbreak{}lib},
\texttt{pwru50.\allowbreak{}lib}, \texttt{pwrue.\allowbreak{}lib}, and
\texttt{pwrus.\allowbreak{}lib}), 7 time steps ($t= 1$ second, 1 day, 1 month,
1 year, 10 years, 1000 years, and 1 million years), and 7 starting nuclides
(Th232, U233, U235, U238, Pu239, Pu241, Cm245, Cf249), and the results were
compared against CRAM using \texttt{sympy.\allowbreak{}lambdify} using
UMFPACK, \texttt{sympy.\allowbreak{}lambdify} using SuperLU, and a C solver
generated by transmutagen against the ORIGEN libraries' combined sparsity
pattern. Transmutation matrices were generated from the ORIGEN libraries and
decay data, meaning any discrepancies in the output values are due to the
method, not the data. To match the behavior of ORIGEN, additional transitions
were added to the matrix to represent $\alpha$ as a He4 production. This
resulted in 236 additional nonzero matrix entries, for a total of 12381, which
translated to an additional 226 nonzero entries that needed to be considered
for the generated C solver, for a total of 16256 (see
Section~\ref{sec:precomputed-lu-solve}). \todo{Discuss mass fraction vs. atom
fraction.}
The computations were run on a 2.2 GHz Dual Core AMD Opteron Processor 275
with 4 GB of RAM running in a Docker container with Debian 8, % meeseeks01
and a Mid 2012 MacbookPro with a 2.3 GHz Intel Core i7 and 8 GB 1600 MHz DDR3
RAM running macOS 10.11. % Aaron laptop
The speed of these analyses is summarized in Figures~\ref{fig:origen-meeseeks}
and~\ref{fig:origen-aaron}. The performance of ORIGEN is dependent on the time
step being computed. In the AMD Opteron runs, for small time steps (1 second
to 1 year) ORIGEN takes from 0.5\;s to 1\;s to run. At larger time steps, it
takes increasingly long---as long as 1110\;s at 1 million years. CRAM on the
other hand, has a runtime that is independent of the timestep. UMFPACK runs
from 130\;ms to 280\;ms, and SuperLU runs from 80\;ms to 150\;ms. The
generated C solver runs from 30\;ms to 50\;ms. On the MacBook Pro runs, the
results are similar, with absolute times being lower due to it being a faster
machine. The most notable difference is that on Linux, SuperLU is
significantly slower than UMFPACK (by about $1.5\times$), whereas on macOS
they are roughly the same, with UMFPACK perhaps being slightly faster.
% \begin{figure}[!ht]
% \centering
% \resizebox{0.9\textwidth}{!}{\input{origen-scopatz.pgf}}
% \caption{Runtimes for different solvers computing transmutation over several starting libraries, nuclides, and timesteps.
% (Scopatz machine)}
% \label{fig:origen-scopatz}
% \end{figure}
% Aaron's Mac: Mid 2012 MacbookPro, 2.3 GHz Intel Core i7, 8 GB 1600 MHz DDR3
\begin{figure}[!ht]
\centering
\resizebox{0.9\textwidth}{!}{\input{origen-aaron.pgf}}
\caption{Runtimes for different solvers computing transmutation over several starting libraries, nuclides, and timesteps.
(MacBook Pro)}
\label{fig:origen-aaron}
\end{figure}
\begin{figure}[!ht]
\centering
\resizebox{0.9\textwidth}{!}{\input{origen-meeseeks.pgf}}
\caption{Runtimes for different solvers computing transmutation over several starting libraries, nuclides, and timesteps.
(AMD Opteron)}
\label{fig:origen-meeseeks}
\end{figure}
In addition to performance comparison, the runs were also used to compare the
output of the four solvers. A large number of discrepancies were found for the
larger timesteps. However, according to the ORIGEN manual, ORIGEN is only
designed to give accurate values for time steps less than 100
days~\cite{ationneeded}.
All comparisons against the computed values were done with an absolute
tolerance of $10^{-5}$ and a relative tolerance of $10^{-3}$.\footnote{Using
\texttt{numpy.\allowbreak{}allclose}, which compares $|actual -
desired|$ to $atol + rtol|desired|$,
where $actual$ is the value computed by CRAM and $desired$ is the
value computed by ORIGEN.} The relative tolerance was chosen because ORIGEN
produces 4 digits of output. The absolute tolerance was chosen ORIGEN computes
the matrix exponential $e^{-A}$ using a Taylor expansion method using the error term
$\frac{e^{\mathrm{ASUM}}\mathrm{ASUM}^n}{n!}$,\footnote{ORIGEN computes this using
Sterling's approximation, i.e.,
$\frac{e^{\mathrm{ASUM}}(\frac{\mathrm{ASUM}e}{n})^n}{\sqrt{2\pi
n}}$. c.f. lines 5075-5100 of the ORIGEN 2.2 source code.} where
$\mathrm{ASUM}$ is the maximum of the column sums of the matrix $A$ and $n =
3.5\mathrm{ASUM} + 6$. Due to fission,\todo{Write more here} the maximum
column sum is $\approx 2$, giving $\frac{e^{2}2^{13}}{13!}\approx 10^{-5}$.
The transmutagen generated C solver agreed with SuperLU within an absolute
tolerance of $10^{-12}$ for all values on all timesteps, and with UMFPACK
within an absolute tolerance of $10^{-8}$. These discrepancies occurred at
the 1 million year time step. Against ORIGEN, for the 1 second timestep, no
major discrepancies were found. For 1 day, several discrepancies were found
above $10^{-5}$ in absolute error. For 1 month, in addition to similar such
discrepancies, Cf248 was not produced at all by ORIGEN against the
\texttt{brwu.\allowbreak{}lib}, \texttt{brwus.\allowbreak{}lib},
\texttt{pwrdu3th.\allowbreak{}lib}, \texttt{pwrputh.\allowbreak{}lib},
\texttt{pwru.\allowbreak{}lib}, \texttt{pwru50.\allowbreak{}lib},
\texttt{pwrue.\allowbreak{}lib}, and \texttt{pwrus.\allowbreak{}lib}
libraries, with the Cf249 starting nuclide, where the CRAM solver produced a
nonzero quantity. Analysis of the input data shows that some quantity should
be produced, and that ORIGEN is removing it from the output as part of its
internal optimizations. There were no such instances where CRAM produced a 0
value and ORIGEN did not. Furthermore, for these time steps, there were no
instances here the He4 values were not within the specified tolerances for the
ORIGEN atom fraction output, suggesting that the $\alpha$ as He4 production
accurately simulates ORIGEN's behavior.