This document discusses the development of executable models of fissile reactor systems for hardware simulation and design. The models are converted from DESIRE simulation models to C++ code using an automatic conversion process. This allows the models to be run on Windows computers and used for engineering design and training simulations. The conversion process and numerical integration engine are described. The document also outlines the engineering design interface and simulator backend that have been developed to utilize the executable models.

1. Executable Models of Fissile Reactor Systems for
Hardware Simulation and Design
Determan, J.C.
LANL1
MS B2282
determan@lanl.gov
Day, C. M.
LANL1
MS B2142
dayc@lanl.gov
Klein, S.K.
LANL1
MS B2282
kleinsk@lanl.gov
Roybal, M.M.
LANL1
MS B2282
mmroybal@lanl.gov
1. Los Alamos National Lab
2. PO Box 1663, Los Alamos, NM 87545
ABSTRACT
Dynamic system simulation (DSS) of fissile solution
systems (FSS) is used at Los Alamos National Laboratory
(LANL) with the goal of understanding the underlying
physics of these systems. Currently this is of considerable
interest to the medical isotopes industry, which plans to
employ FSS to develop a method for producing urgently
needed medical isotopes, including Mo-99, the precursor of
Tc-99m. The DESIRE (Direct Executing Simulation in
Real Time) system has been used to perform DSS of FSS
for several years. A benchmark FSS, SUPO, operated for
several decades at LANL, has been modeled, and this
model validated against historical data. Proposed isotope
production systems have also been modeled. While the
DESIRE simulation models are useful to researchers, they
are not easily shared with industry partners more interested
in system design and operator training. To support these
needs a system for producing computer executable models
has been developed. The executable models can be run on
Windows-based computers, are designed for use by design
engineers, and are capable of serving as the backend of
hardware simulators for use in training scenarios. This
paper focuses on the development of the system for
producing and using the executable models described
above. LA-UR-15-20648 Version 2
Author Keywords
Fissile Solution Systems; Simulator; Medical Isotopes; C++
ACM Classification Keywords
I.6.1 SIMULATION AND MODELING
1. INTRODUCTION
There is an urgent need to develop new means for
producing isotopes used in nuclear medicine, specifically
molybdenum-99 (Mo-99), the precursor of technetium-99m
(Tc-99m). Each day in the United States, 50,000 doses of
Tc-99m are administered to patients, and approximately
60% of these doses are produced using Highly Enriched
Uranium (HEU) targets in aging nuclear reactors.
However, these reactors are planned for shutdown in the
near future [1]. Researchers at Los Alamos National
Laboratory (LANL) are working with industrial partners to
develop new methods for producing these isotopes using
Low Enriched Uranium (LEU). The goal of the specific
work described in this paper is to develop tools to aid in the
collaboration between LANL and industry. In short, tools
used for scientific research must be converted to tools
useful for engineering purposes.
Researchers at LANL use the DESIRE (Direct Executing
Simulation in Real Time) [2] system to simulate and study
the time behavior of a variety of fissile systems including
fissile solution systems (FSS) [3]. The DESIRE
mathematical model is directly exposed to users and
requires a high degree of familiarity with the underlying
reactor physics to modify the model and extract information
from the simulations. Engineers need tools that hide
unnecessary detail and provide convenient ways to modify
inputs and quickly extract results in a rapid product
development environment. An executable model, in this
instance written in a combination of C++ and C#, fits the
requirements. Being executable code, the model details are
hidden, and the required level of access to the model is built
into the user interface.
Two specific tools are under production:
• an engineering design tool; and
• an FSS simulator.
The same code underlies both tools, and is referred to as
SimApp: a numerical integration engine designed to operate
on model inputs converted from the DESIRE modeling
SCSC 2015, July 26-29, 2015, Chicago, IL, USA
© 2015 Society for Modeling & Simulation International (SCS)

2. language to C++, combined with plug-in modules that
represent specific FSS models. These plug-in modules are
converted from DESIRE model inputs via a separate model
converter application.
One tool under production is a Hardware Simulator. The
C++ code described above will serve as the backend of the
simulator, and the simulator graphical interface is being
written in National Instruments (NI) LabVIEW. The
simulator will primarily be used to evaluate the human
factors associated with operating the system as well as a
training tool once the final design has been determined.
The other tool is an engineering design aid. A separate
graphical user interface for engineering design analysis has
been written in C#. The engineering design aid will allow
users to acquire detailed data from a wide range of design
and operational scenarios quickly and easily. The simulator
and design aid are described below.
2. DESIRE MODEL CONVERSION
Several requirements were imposed on the model
conversion process. At the highest level, the process should
be quick and capable of maintaining the semantics of the
original DESIRE code. A manual translation process might
take weeks or even months for a large model, and even if
carefully executed, such a process would likely be fraught
with errors. These considerations indicated that although
code translation can involve some degree of complexity, the
trade-off would be sound: it appeared possible that an
accurate and efficient code translation system could be
written in roughly the time it might take to convert just one
or two large models. Since multiple systems may be
considered of widely varying configurations, this approach
provides for rapid conversion of models once the models
have been developed and validated.
Once the decision to pursue an automatic code translation
system was made, a system that closely emulated DESIRE
was the next requirement. DESIRE is built around a
paradigm of declarative mathematical expressions
interpreted by a numerical integration engine, where the
user may select the exact form of numerical integration to
use. This paradigm is useful in DESIRE, as it allows
scientists and engineers to specify simulation models
without being experts in numerical integration. This
paradigm is also appropriate to code conversion as it allows
for design of a relatively simple code translator and
adoption of standard numerical techniques. Also, the
performance and accuracy of the converted model should
be very comparable to those of the original DESIRE model.
The alternative design of attempting to optimize the code,
rather than just translate it was considered, for example, but
rejected, as the likelihood was high that such a design
would produce models that gave radically different results,
albeit much more quickly, and would have taken longer to
develop.
The final requirement was to ensure that the converted
model could be easily added to the numerical integration
engine. Given that the numerical engine was written in
C++, an object-oriented language, the obvious design
choice was to write the numerical engine in terms of a
superclass, and produce the converted model as a plug-in
subclass. Thus, the numerical engine defines a set of pure
virtual methods in the superclass, which are instantiated
differently in each subclass produced by the converter.
Thus the numerical engine is written in terms of class
methods actually implemented only in the specific models.
While translation from DESIRE to C++ code is generally
straight-forward, there were a few specific challenges. The
concept of hierarchy of operations is identical between C++
and DESIRE, and many mathematical functions have the
same (or similar name) and parameter order. The types of
things that are more challenging include exponentiation,
and the C++ concept of integer division. DESIRE uses the
infix operator “^” for exponentiation, whereas C++ uses the
function “pow”, which is a prefix notation. Thus the
DESIRE code before and after a “^” has to be analyzed to
determine what the operands are, and they may both be
complicated expressions.
Implementing division also involved special considerations.
A statement such as “1/2” in DESIRE will generally be
interpreted very differently in C++, if extra steps are not
taken in the translation. All math is double precision
floating point in DESIRE, so the division in the example
statement will be double precision division, resulting in a
value of 0.5 (or very close to it). The straight-forward
representation of “1/2” in C++ will result in the execution
of integer division, resulting in a value of 0 (exactly). Thus,
in all divisions, the numerator was identified and forced to a
double precision value, such that all divisions would be
double precision, to replicate the behavior of DESIRE.
The above considerations may not sound so difficult, due to
the simplicity of the examples, but consider for a moment
that real mathematical expressions may contain several
levels of nested and intertwined usages of both division and
exponentiation and the reader will then understand that
some care was required to develop a generally functioning
translator.
Another consideration in translating DESIRE code to C++
is variable declarations. First of all, DESIRE does not
require declaration of simple variables, whereas all
variables must be declared in C++. Secondly, some
variables in DESIRE may only exist implicitly – in some
cases, state variables may only be referenced in terms of a
derivative statement. That is, “d/dt” is an operator in
DESIRE such that statements like:
d/dt <variable name> = <some expression>”
are common. Variables defined by a derivative statement
are state variables, and exist in an array manipulated by the
integration engine. Thus variable declarations have to be

3. inferred from the code, and state variables distinguished
from non-state variables. The implementation of state
variables and their derivatives will be discussed at greater
length in the following section.
For our purposes, it was also useful to distinguish constants
from variables, which the structure of DESIRE code allows.
Variables only modified above the keyword “DYNAMIC”
may be treated as constants, as they will not be updated
during the simulation. Identification of constant values
allows the specification of initial condition values that may
be modified in the user interface for the purposes of
engineering design studies.
The model converter does one other important step.
Several values, such as the numbers of state and non-state
variables, are determined during the translation process.
Information such as this is useful in the numerical
integration engine. This information is shared with the
numerical integration engine via virtual methods written by
the translator and called by the numerical integration
engine.
The integration routine is written in terms of loops over the
array of state variables and their derivatives. This is why
arrays are the representation of choice in the first place.
The translated model inputs fall into two groups:
initialization statements that are called once prior to the
main calculation loop and those statements that are
continually recalculated in the integration routine. The
translated model inputs are worked into the integration
routine via calls to the virtual methods mentioned in the
preceding section. It is these virtual methods that allow the
code to be split into a general purpose numerical engine and
a plugin module representing specific model inputs.
Figure 1 is a graphical representation of the SimApp
system.
3. NUMERICAL INTEGRATION ENGINE
The numerical integration engine is fairly basic at present,
but sufficient for the SimApp results to closely match
DESIRE results. DESIRE allows for a number of
integration methods of both fixed and adaptive step size.
At present only fixed step, fourth-order Runge-Kutta [4]
integration is implemented, as that is all that is used in the
DESIRE models that have been converted. State variables
and their derivatives are maintained in an array, and the
intermediate Runge-Kutta results are also maintained in
successive columns of the array. The state variables are
also represented as pointer variables that point to
appropriate positions in the array of state data. This allows
the translated model input to use variable names instead of
array references, to improve readability of the translated
code.
Figure 1. Graphical representation of SimApp.
4. ENGINEERING DESIGN INTERFACE
A primary goal of this work was to provide an engineering
design interface for controlling the simulation process.
Toward this end, initial conditions (system configuration,
material thicknesses, physical parameters, etc.) can be
modified, the simulation can be paused and resumed, plots

4. of key parameters as a function of time can be produced, a
table of calculation results can be viewed, and stability plots
can also be produced. The net result is that the user may
specify a wide variety of postulated scenarios via the initial
conditions, watch how the scenarios unfold, study plots and
data from the simulation, and verify the stability of the
reactor being studied under the different scenarios.
Figures 2 and 3 show the primary elements of the
engineering design interface. The main menu allows the
user to select which of the tools are displayed at any given
time.
Figure 2. Shown clockwise form the upper left are the simulation control panel, the time history plot and data variable selection
panel, the initial conditions panel, and the data plot panel.
Figure 3. The data display panel and the initial conditions panel have been swapped for the stability plot panel and data table
panel, respectively, in this view.

5. The simulation control panel allows the user to begin a new
simulation or to choose a previously stored simulation to re-
display. A new simulation may be paused and resumed, or
completely aborted. When a new simulation has
completed, or when a stored simulation is recalled, any new
combination of plots and data tables may be produced for
the simulation being studied.
The plot and data variable selection panel has two modes of
operation. The default mode of operation allows the user to
select from predefined groups of variables, while the
alternate mode allows access to all variables in the model.
The mode of operation is selected in the main menu.
Buttons in this interface allow the selected variables to be
either plotted or displayed in a table. The amount of data to
be displayed in the table can be varied with a slider from
just the final data record to all data records. The user may
specify specific X and Y plot scales, or put the plot into
automatic Y scale mode. A button also allows the currently
displayed data to be dumped to a comma separated value
(CSV) file for further analysis in a spreadsheet.
Initial condition variables are flagged during the model
conversion process. The person performing the model
conversion uses an interface in the model converter tool to
specify that specific variables should be used as initial
condition variables, and these variables are logically
grouped as appropriate. Different groups of initial
condition variables are then presented on separate tabs
within a control for modifying initial conditions. Typical
groups of initial condition variables include such things as
reactor core physical dimensions, operational parameters
controlling timing of specific events and more.
The data plot panel displays the time evolution of the
selected set of variables. Variables are identified via a
color coded legend. Clicking in the plot brings up a cursor
line that synchronizes the data table selected row to the plot
cursor line. The keyboard arrow keys are used to then
move simultaneously through both the plot and data table.
The data display panel presents user selected groups of data
variables. Columns represent the different variables and
rows represent data by time step in time ascending order.
The date table may show values for all time steps, only the
final step, or be filtered to display every nth
row, where n is
a selected power of ten. In addition to the ability to
produce CSV files of the entire data table mentioned above,
a highlighted portion of the table may be copied and then
pasted into a spreadsheet.
Stability plots are useful to the engineer looking to verify
the stability of an engineered system. Location of poles
from the system’s transfer function relative to the plot lines
in the stability plots indicate stability or instability of the
system. The stability plots shown are the Bode amplitude
and phase plots, and the Nyquist plot.
5. SIMULATOR BACKEND
The other primary goal for this work was to provide the
backend for a simulator. While the engineering design
interface aids in the initial design work, the simulator goes
much further. A simulator can initially exist purely as a
computer based tool, much like flight simulator software
currently in use today; however, as the physical control
panel is developed, the control panel can be used in
conjunction with the simulator backend and display to
verify control panel operation and to assist in training
operators for the real plant that will ultimately be built. The
frontend display of the simulator, shown in Figure 4, is
currently being built in NI LabVIEW.
The simulator backend uses the same code as the
engineering design interface. Specifically, the numerical
integration engine and the C++ plug-in modules of specific
simulation models from the same source code base are used
in both tools. A distinct interface to the capabilities of the
integration engine was provided for use by the LabVIEW
simulator front end. In the engineering design interface a
simulation loop that executes for a specified period of time
was provided as part of the integration engine, such that the
interface to the engineering design tool consists of a call to
start the simulation (given the simulation parameters, initial
condition values, and a list of variable to plot), and a
callback method for returning data to plot. The simulator
on the other hand will execute its own simulation loop as
essentially an endless loop that can be terminated by the
user via the control panel. Therefore an interface to lower-
level capabilities was provided for the simulator, including
such things as:
• Initialize the simulation
• Step the simulation
• Finish the simulation
• Data request methods (for display of simulator data)
• Input modification methods (change model operational
inputs to affect a change in the simulation from the
simulator control panel)
An additional difference between the simulator and the
engineering design tool is that the simulator execution
speed will need to be slowed down to mimic real time
operation. Using a 3.5 GHz, dual core machine with 48 GB
RAM, a 2000 s simulation executed via either DESIRE or
SimApp for either of the SUPO or Accelerator Driven
models will execute in just a few minutes, or roughly an
order of magnitude faster than real time operation. The
next section presents a comparison for simulation results
from DESIRE and SimApp models.

6. Figure 4. Example simulator front end.
6. COMPARISON TO DESIRE RESULTS
Detailed data comparisons have been done for two models,
SUPO (SUper POwer) [5] and the Accelerator Driven
Design. As mentioned earlier, SUPO was an actual FSS
operated at LANL for several decades, and the third in a
series of such FSS; the first was LOPO (LOw POwer), and
the second was HYPO (High POwer). The archived data
from SUPO was used to validate the DESIRE model of
SUPO. The Accelerator Driven model is a design only, so
there is no data for validation. Comparisons show good
agreement between the DESIRE models of the above
mentioned systems and corresponding models in SimApp.
It should be noted that exact agreement between the two
simulation systems is neither expected nor required, but
arriving at generally the same solution is desired; this level
of agreement has been achieved. Figures 5 – 8 compare
power, reactivity, average fuel temperature and average
core void fraction respectively between SimApp and
DESIRE, for one of the scenarios where there was the least
degree of agreement in the results at 1000 s. The traces in
each case are essentially identical.
Parameters compared included core temperature and void
profiles, reactivity, power, peak power, core-averaged
temperature and core-averaged void fraction. Forty
scenarios were compared using the SUPO model, where a
wide variety of operational parameters were varied.
Automated testing techniques were used to develop a test
application to drive simulations in the engineering design
interface, so that regression testing may be easily performed
in the future.
Figure 5. Power (kW) for SimApp and DESIRE.

7. Figure 6. Reactivity ($) for SimApp and DESIRE.
Figure 7. Average fuel temperature (°C) for SimApp and
DESIRE.
Figure 8. Average core void fraction for SimApp and
DESIRE.
Figure 9. Average core void fraction for SimApp and
DESIRE (final 400 s, detail).
Two categories of results may be identified. Most scenarios
reached a true steady state after some finite amount of time,
and these results compare very well (steady state values
within .01% or better for all parameters compared). A few
scenarios ended in long term but bounded oscillations,
where void reactivity feedback was driving bounded
oscillations between the reactivity and the core void.
Figure 9 shows an example of oscillations in the average
core void fraction. These scenarios still showed good
agreement (most parameters compared agreed within 0.1%
or better). Results could be obtained for the DESIRE
SUPO model consistently using a time step of 0.01 s,
whereas the SimApp model required a smaller time step of
0.0025 s on scenarios with the worst oscillations; this
smaller time step was used for all SimApp scenarios. The
jury is out on whether these bounded oscillations are a
physical reality or numerical artifact.
Differences in results between the DESIRE models and the
corresponding SimApp models can generally be ascribed to
two sources:
• Errors in the conversion process; and
• Differences in the DESIRE and SimApp implementations
of fourth-order Runge-Kutta numerical integration.
Errors from the conversion process were removed in two
stages. Gross errors in the conversion process produced
C++ code that would not compile; such errors were easily
identified and removed. More subtle errors in the
conversion process resulted in code that executed, but
resulted in gross differences in simulation results.
Differences in the simulation results were traced via
detailed data comparisons to specific lines of DESIRE
model input. Comparison of specific lines of DESIRE
inputs to the C++ code generated from these inputs helped
remove all remaining conversion process errors.
Once the conversion process was working well, differences
between the DESIRE and SimApp models were generally
small. The details of the fourth-order Runge-Kutta
implementations were focused upon next. Errors in the
SimApp Runge-Kutta implementation were discovered and
removed, resulting in the level of agreement between
DESIRE and SimApp models presented in this paper. It is
suspected that the remaining differences seen in simulation
results are due to very low level differences between the
DESIRE and SimApp implementations of the Runge-Kutta
method.
The bottom line is that the SimApp and DESIRE simulation
models are using the same model inputs (converted for
syntax by a reliable automated process), the same numerical
integration method (fourth-order Runge-Kutta, verified for
correctness), but with some unavoidable differences in the
fine details of implementation. A high level of agreement
between DESIRE and SimApp simulation model results
was expected and has been achieved.

8. 7. CONCLUSION
Our goal has been and continues to be to support the
process of developing new means of production for the
urgently needed medical isotope Mo-99, precursor of Tc-
99m. We have developed a simulation system consisting of
a numerical integration engine and automatically translated
plug-in modules that represent specific models of interest.
The plug-in modules are created from DESIRE simulation
input files already in use by researchers at LANL. This
simulation system is used in two specific tools needed to
support industrial partners in the medical isotope field. The
first of these tools is an engineering design interface that
will support on-going design work, and the second is an
FSS simulator, for use in operator training. The simulator
backend is essentially complete; work on the NI LabVIEW
frontend continues.
ACKNOWLEDGMENTS
This work was performed on behalf of the National Nuclear
Security Administration (NNSA), Office of Global Threat
Reduction (NA-21).
REFERENCES
1. Committee on Medical Isotope Production Without
Highly Enriched Uranium, Medical Isotope Production
Without Highly Enriched Uranium. The National
Academies Press, Washington D.C., USA, 2009.
2. Korn, G.A., Interactive Dynamic-System Simulation,
Second Edition. CRC Press, Boca Raton, FL, USA,
2011.
3. Kimpland, R. H., Klein, S. K., A Generic System Model
for a Fissile Solution Fueled System, LA-UR-13-22033,
2013. Available from reports@lanl.gov.
4. Press, W.H., Teukolsky, S.A., Vetterling, W.T.,
Flannery, B.P., Numerical Recipes in C, The Art of
Scientific Computing, Second Edition. Cambridge
University Press, New York, NY, USA, 1992.
5. Kasten, P.R., Reactor Dynamics of the Los Alamos
Water Boiler. Vol. 50 of C.E.P. Symposium, Nuclear
Engineering, 50, 11 (1954), 229-244.