gibarra thesis maestria

InstItuto PolItécnIco nacIonal
EscuEla suPErIor dE FísIca y MatEMátIcas
dEvEloPMEnt oF thE GEMMa codE For thE
solutIon oF thE nEutron transPort EquatIon
wIth thE MEthod oF charactErIstIcs
For hPc aPPlIcatIons
by
GuIlllErMo Ibarra rEyEs
thEsIs subMIttEd to thE collEGE oF ProFEssors In PartIal
FulFIllMEnt oF thE rEquIrEMEnts For thE dEGrEE oF
MastEr oF scIEncE In MathEMatIcal PhysIcs
(nuclEar EnGInEErInG rEsEarch lInE)
at thE
InstItuto PolItécnIco nacIonal
thEsIs advIsors:
dr. arMando MIGuEl GóMEz torrEs (InIn)
dr. EdMundo dEl vallE GallEGos (IPn)
MExIco cIty, MExIco, JunE 2017
[This page intentionally left blank]
[This page intentionally left blank]
[This page intentionally left blank]
[This page intentionally left blank]
Abstract
With the ever increasing rise in computer processing power, high fidelity solutions of the neutron
transport equations once considered prohibitive are now feasible. This thesis proposes the constitution of the next generation neutron transport solver; a code capable of employing accurate
solution methods with the ability to incorporate parallel computing techniques using specialized
hardware and providing a flexible developmental environment. The latter is provided through
the use of a programming language capable of providing powerful development tools while harnessing multi-core architectures. The Gemma code is a 2D method of characteristics solver,
which was written completely in the D programming language. In doing so, flexibility is provided on two fronts, for the end user and future developers. Users interact with the code through
an input text file where the geometry, materials and calculation parameters are specified with
input cards. This approach eliminates the need for leaning any programming language and any
errors found are presented clearly. Regarding the developer, D provides effortless tools for debugging, testing and documentation purposes. For the benchmark problem 2D C5G7 excellent
results were obtained, with differences as low as 7 pcm. From this first iteration of the Gemma
code, the viability of an accurate solution method is demonstrated. A next step is the incorporation of a parallel module, given the highly parallelizable nature of the method of characteristics
a strong speed up is expected. D has a symmetric multiprocessing library incorporated and is
also capable of running native C code, thus the next proposed task is possible.
ix
Guillermo Ibarra-Reyes
Page x
Resumen
El aumento continuo del poder de computo ha hecho posible la solución precisa a la ecuación
de transporte neutrónico, que en algún momento se consideraba fuera del alcance de las herramientas disponibles. La presente tesis propone el desarrollo de un código de computo de
nueva generación para la solución de la ecuación de transporte, capaz de proporcionar soluciones precisas, además de poseer la habilidad de incorporar técnicas de computación paralela,
y sobre todo facilitar un ambiente de desarrollo flexible. Lo último se logra a través del uso de
un lenguaje de programación capaz de proporcionar herramientas poderosas con la posibilidad
de utilizar procesadores de multi-núcleos. El código Gemma resuelve la ecuación de transporte
de neutrones en dos dimensiones mediante el método de las características y está escrito completamente en el lenguaje D. Debido a esto, existe flexibilidad tanto para el usuario final como
para cualquier desarrollador futuro. La interacción con el código por parte del usuario se lleva
acabo a través de un archivo de entrada en donde se especifica la geometría del sistema, datos
de los materials y parámetros del cálculo con el uso de tarjetas de entrada. Bajo esta estrategia
se evita la necesidad de tener que aprender el lenguaje de programación, además cualquier error
encontrado se presenta de manera explicita. Con respecto a desarrolladores, el lenguaje D proporciona herramientas fáciles e intuitivas para los procesos de depuración, para efectuar pruebas
y llevar acabo la documentación. Para el problema benchmark C5G7 en dos dimensiones, se
obtuvieron resultados excelentes, con diferencias tan bajas como 7 pcm. Esta primera versión
de Gemma demuestra la viabilidad de obtener una solución precisa. Un siguiente paso será la
incorporación de un modulo de paralización. Dada la naturaleza del método de las características, se espera una aceleración considerable con respecto al tiempo de cálculo. El lenguaje D
tiene una biblioteca para el uso de multiprocesamiento simétrico, además es capaz de incorporar
el lenguaje C de forma nativa, por lo tanto este siguiente paso se considera posible.
xi
Guillermo Ibarra-Reyes
Page xii
For my father, Guillermo
Who made all the sacrifices so that
his children wouldn’t have to make any.
Guillermo Ibarra-Reyes
Page xiv
Acknowledgements
I would like to express my sincerest gratitude to my thesis advisors Dr. Edmundo del Valle Gallegos and Dr. Armando Miguel Gómez Torres. Both have offered more patience and freedom
that can be reasonably expected. Patience in providing me with the necessary time required to
grow as a student given the lack of nuclear physics background and freedom in allowing me to
pursue different avenues for this work, many times on a whim.
I would also like thank the Escuela Superior de Física y Matemáticas (ESFM) at the Instituto
Politécnico Nacional (IPN) and the Instituto Nacional de Investigaciones Nucleares (ININ) for
providing a productive environment that has been crucial to my professional development. I
am extremely grateful to Dr. Arturo Delfin Loya for his invaluable knowledge and experience,
which has been pivotal in learning the finer points of nuclear engineering.
Financial support for my postgraduate studies was provided by the Consejo Nacional de Ciencia
y Tecnología (CONACYT), this work would not have been achievable without their generous
contributions. This work contributes to the AZTLAN platform or the CONACYT-SENER National Strategic Project No. 212602.
I will forever be indebted to Samuel Vargas for his continued mentorship, particularly on all matters relating to nuclear analysis codes. I am immensely appreciative for his patience and willingness to provide direction in spite being constantly barraged with questions, some of which
were at ungodly hours through text messages. Through his advice and fruitful discussions the
Gemma code has been modified for the better. Above all the Sam has been a remarkable friend.
I have also been extremely fortunate and grateful for all the guidance provided by Dr. Graciela
Eréndira Núñez Palenius. In 2008 I found myself in another country away from family and in a
completely different way of life. Throughout that learning experience her counsel and aid were
invaluable in the transition process. I will never be able to fully express the impact that she has
had my career, but more importantly on my growth as a person.
Last but not least I would like to thank my family for all their encouragement and instilling in
me the joys of intellectual pursuits. Beyond a shadow of a doubt without them none of this
would have been possible. I am thankful for being able to share the past two years with Astrid
Solis, doing everything possible in dealing with school while attempting to maintain our sanity.
Finally my deepest appreciation for Elizabeth Negrete, as life has taken its natural progression,
I have always been able to count on her for inspiration, strength, and an ever welcoming laugh.
Guillermo Ibarra-Reyes
Page xvi
Contents
List of Figures
xix
List of Tables
xxi
1
2
Introduction
1.1 Background and Motivation . . . . . .
1.2 Nuclear Analysis Software . . . . . . .
1.3 High Performance Scientific Computing
1.3.1 Multi-Core Processing Units . .
1.3.2 Graphical Processing Units . . .
1.4 Neutron Transport Solution Methods . .
1.4.1 Neutron Transport Equation . .
1.5 Thesis Overview . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Method of Characteristics Formulation
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Method of Characteristics General Theory . . . . . . . . . . . . . . . . . . . .
2.2.1 Characteristic Form of the Transport Equation . . . . . . . . . . . . . .
2.2.2 Multigroup Energy Approximation . . . . . . . . . . . . . . . . . . .
2.2.3 Discrete Ordinates Approximation . . . . . . . . . . . . . . . . . . . .
2.2.4 Constant Material Properties and Flat Source Approximation within a
Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.5 Isotropic Scattering Approximation . . . . . . . . . . . . . . . . . . .
2.2.6 Algebraic Optimization of the MOC Framework Equations . . . . . . .
2.2.7 FSR Area Approximation . . . . . . . . . . . . . . . . . . . . . . . .
2.2.8 Summary of Principal MOC Equations . . . . . . . . . . . . . . . . .
2.3 MOC Solution Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Transport Sweep . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 Reduced Source Calculation . . . . . . . . . . . . . . . . . . . . . . .
2.3.3 Eigenvalue Calculation . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4 Convergence Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.5 Exponential Function Evaluation . . . . . . . . . . . . . . . . . . . . .
xvii
1
1
2
2
4
6
6
7
8
9
9
10
10
11
12
13
15
15
16
17
17
18
19
20
20
20
Contents
3
Geometric Modeling
3.1 Introduction . . . . . . . . . . . . . . .
3.2 CSG Implementation . . . . . . . . . .
3.2.1 Cell . . . . . . . . . . . . . . .
3.2.2 Lattice . . . . . . . . . . . . .
3.2.3 Assembly . . . . . . . . . . . .
3.2.4 Universe Surface Map Structure
3.3 Region Creation . . . . . . . . . . . . .
3.4 Track Generation . . . . . . . . . . . .
3.4.1 Global Cyclic Tracking . . . . .
3.4.2 Quadrature Set . . . . . . . . .
3.5 Track Segmentation . . . . . . . . . . .
3.5.1 Ray Tracing . . . . . . . . . . .
3.5.2 Surface Intersections . . . . . .
3.6 Region Segmentation . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
27
28
29
29
30
30
30
32
32
33
36
39
4
Developmental Aspects of the Gemma Code
4.1 The Benefits of D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Design Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Input File Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
41
42
44
5
Code Verification
5.1 LA-13511 Benchmark . . . . . . . . . . . . . . . .
5.1.1 One Energy Group with Isotropic Scattering .
5.1.2 Two Energy Groups with Isotropic Scattering
5.1.3 Problem Set . . . . . . . . . . . . . . . . . .
5.2 BWR Benchmark . . . . . . . . . . . . . . . . . . .
5.2.1 Eigenvalue Convergence . . . . . . . . . . .
5.2.2 Power Pin Results . . . . . . . . . . . . . .
5.3 C5G7 Benchmark . . . . . . . . . . . . . . . . . . .
5.3.1 Eigenvalue Convergence . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
47
47
47
48
49
51
51
53
53
54
6
Summary, Conclusions and Outlook
6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Proposed Developments . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
57
58
59
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Appendices
61
A Gemma Input Cards
A.1 Geometry Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Material Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Calculation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
61
66
66
Bibliography
69
Guillermo Ibarra-Reyes
Page xviii
List of Figures
1.1
1.2
TOP500 Performance Development . . . . . . . . . . . . . . . . . . . . . . .
Accelerators used in TOP500 computer systems . . . . . . . . . . . . . . . . .
3
4
2.1
2.2
2.3
Spatial Discretization of an arbitrary region with constant material properties. .
Area approximation for a FSR. . . . . . . . . . . . . . . . . . . . . . . . . . .
Bi-direction track sweep scheme for two angles. . . . . . . . . . . . . . . . . .
13
17
19
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
Surface building blocks in Gemma with their respective parameters.
Positive and negative side of a surface defined by f (x, y). . . . . . .
Cell universe representation of a pin-cell. . . . . . . . . . . . . . .
2⇥2 lattice array. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4x4 fuel lattice assembly. . . . . . . . . . . . . . . . . . . . . . . .
Discretization techniques in Gemma. . . . . . . . . . . . . . . . . .
Neutron flight direction representation. . . . . . . . . . . . . . . . .
Azimuthal weight illustration. . . . . . . . . . . . . . . . . . . . .
Ray tracing starting points. . . . . . . . . . . . . . . . . . . . . . .
Ray tracing threshold limits for evaluating end points. . . . . . . . .
Surface intersection scheme. . . . . . . . . . . . . . . . . . . . . .
Region intersection representation. . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
27
27
28
29
30
31
32
34
34
38
39
5.1
5.2
5.3
5.4
5.5
Layout of the BWR benchmark with burnable poison fuel pins.
BWR benchmark regions created in Gemma. . . . . . . . . .
BWR benchmark scalar flux distribution map. . . . . . . . . .
2D C5G7 benchmark problem configuration. . . . . . . . . .
C5G7 scalar flux distribution map. . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
52
53
55
56
A.1 Surface types with their respective parameters. . . . . . . . . . . . . . . . . . .
62
xix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
List of Figures
Guillermo Ibarra-Reyes
Page xx
List of Tables
1.1
Variables of the time-independent integro-differential k-eigenvalue equation . .
8
3.1
Legendre polar angle quadrature set. . . . . . . . . . . . . . . . . . . . . . . .
33
4.1
4.2
Summary of Gemma modules . . . . . . . . . . . . . . . . . . . . . . . . . .
Gemma input file keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
44
5.1
5.2
5.3
5.4
5.5
5.6
Cross sections (cm 1 ) of the benchmarks problems for the LA-13511 set. . . .
LA-13511 k• result analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . .
BWR k• result analysis for a track separation of 0.001 cm. . . . . . . . . . . .
BWR power pin analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Converged C5G7 eigenvalues at varying angles for a track separation of 0.01 cm.
Converged C5G7 eigenvalues at 64 azimuthal angles and varying track separations
50
51
53
54
54
55
A.1 Units used in the Gemma code . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Surface types for the Gemma code . . . . . . . . . . . . . . . . . . . . . . . .
xxi
62
62
List of Tables
Guillermo Ibarra-Reyes
Page xxii
Chapter 1
Introduction
1.1
Background and Motivation
The AZTLAN platform [1] is a Mexican initiative whose main objective is to develop nuclear
reactor analysis software using High Performance Computing (HPC) techniques. This project
works towards modernizing, improving and incorporating computational methods and codes
from previous studies into an integrated national platform. It represents a crucial initial step in
gaining a medium term time scale.
Mexico is making great strides in solving the neutron transport equation with various angle approximations [2, 3, 4], and the thermal hydraulic aspects of the nuclear core [5, 6]. However, no
significant efforts are focused on lattice codes.
Generally speaking, lattice codes provide the cross sections required by nuclear reactor analysis
codes. Although the development of a lattice code may require more time than the length of the
project; the AZTLAN Platform is just the first step in creating a comprehensive and accurate
software suite. For a truly independent nuclear analysis platform, a lattice code is necessary. As
with most nuclear reactor analysis tools, the cornerstone of an accurate lattice code is the proper
calculation of the neutron flux distribution. From there the other modules such as the resonance
calculation, energy group condensation and so forth can be developed [7].
This work presents the development of the Gemma code, a neutron transport solver with the
method of characteristics (MOC) for arbitrary 2 dimensional geometries. Upon using the MOC
solution method, an accurate solution is possible and given its highly parallelizable nature the
use of high performance computing is feasible. The latter represents an important advantage
due to MOC’s inherent slow convergence. Gemma’s developmental ideals focus on the ease of
use for end users as well as future potential developers and operates under the assumption that a
nuclear analysis code is accurate, fast, and flexible. The methodology implementation, as well
as the benchmarking process are explained in detail.
1
1.2. Nuclear Analysis Software
1.2
Nuclear Analysis Software
Current nuclear codes can model and evaluate fuel behavior, reactor kinetics, thermal hydraulic
conditions and probabilistic risk assessments. Results from these codes provide crucial information for the decision making process for risk informed activities, verification of similar codes
and the resolution of technical problems. An example of a comprehensive software package
for nuclear fuel analysis is provided by Studsvik [8], while SCALE [9] provides a package for
nuclear safety analysis and design.
At the center of these nuclear reactor applications lies an overwhelming dependence on an accurate calculation of the neutron flux distribution throughout the system. Typically these calculations are carried out in steady state using the Boltzmann transport equation, which depends
on position (3 independent variables), solid angle (2 independent variables) and energy. A deterministic solution of the transport equation requires the discretization of the 6 aforementioned
variables. High resolution distribution of the neutron flux represents a greater level of discretization which in turn increases the number of coupled algebraic equations.
Previously such detailed calculations were outside the realm of possibilities given the available
computational resources. Consequently simplifications or approximations were used to solve
the flux distribution. Some of these approximations include modeling reactor geometry in one
or two dimensions as opposed to three; considering isotropic neutron sources; assuming neutron scattering is isotropic; using the diffusion approximation in which the angular dependency
of the solution is eliminated; and adopting constant physical properties (nuclear cross sections)
through the use of few energy groups.
The use of certain approximations varies greatly, depending on the system being analyzed. For
example the diffusion approximation performs poorly in the presence of burnable poisons or a
highly absorbing medium, in cases where the flux gradient throughout the system is large and
near the system boundaries. Also for fresh fuel or uranium oxide (UO2 ) a two energy group is
sufficient to accurately predict the neutron flux, whereas the presence of plutonium, such as in
mixed oxide (MOX) reactors, requires a greater number of energy groups to properly model its
behavior.
1.3
High Performance Scientific Computing
High performance computing (HPC) has traditionally been associated with supercomputers.
Performance is commonly measured and benchmarked in "Flop/s" (FLoating point Operations
Per Second). The TOP500 [10] list presents the fastest computer systems according to their
LINPACK benchmark results. As of November 2016, the top spot belongs to the Sunway TaihuLight (National Supercomputing Center in Wuxi, China) with a speed of 93 PFlop/s (petaflops,
1015 Flop/s). In contrast, just 5 years earlier the top spot belonged to the Fujitsu "K Computer"
(RIKEN Advanced Institute for Computational Science in Kobe, Japan) with a speed of 10.51
PFlop/s. The exponential growth of the TOP500 computer systems are presented in Figure 1.1.
According to this data, by 2020 the first EFlop/s (exaflops, 1018 Flop/s) computer system is proGuillermo Ibarra-Reyes
Page 2
Chapter 1. Introduction
Figure 1.1: TOP500 Performance Development
jected to be built.
It is worth noting that the term HPC is not exclusive to supercomputers, in essence the term
applies to the use of parallel processing for running computationally intensive applications. Any
computer with more than one central processing unit (CPU) or core is capable of performing
such tasks, additionally that multi-core processors are commercially available to consumers.
The latter will be discussed further in Subsection 1.3.1. Granted, although an extreme case,
the Sunway TaihuLight consists of 40,960 SW26010 many-core processors, each processor chip
containing 256 processing cores plus an additional 4 auxiliary cores for system management
for a total of 10,649,600 cores [11]. At the consumer workstation level, the Intel Xeon E7 v4
processor family offers up to 24 processing core processors and multi-socketed motherboards
available presents the ability to create many core computer systems from consumer grade products.
Page 3
IPN-ESFM
1.3. High Performance Scientific Computing
Figure 1.2: Accelerators used in TOP500 computer systems
Another trend in supercomputing has been the use of heterogenous computing schemes, where
two or more distinct processor types are coupled together in order to provide a new flexible
computational environment. Under these conditions, the multi-core systems gains performance
not just by adding cores, but by the incorporation of specialized hardware accelerators for particular tasks. In terms of the TOP500 list from November of 2016, some of the accelerators or
co-processors present along with its quantity in systems include:
• NVIDIA Tesla K40 (26 systems)
• NVIDIA Tesla K80 (9 systems)
• Intel Xeon Phi 5110P (6 systems)
• NVIDIA Tesla K20x (6 systems)
• Intel Xeon Phi 5120D (5 systems)
• Intel Xeon Phi 7120P (4 systems)
• NVIDIA 2050 (4 systems)
• others (26 systems)
Figure 1.2 presents the usage of accelerators within the TOP500 computer systems since 2006,
the first year they were introduced. Graphical processing units are briefly presented in subsection 1.3.2.
1.3.1
Multi-Core Processing Units
For about 50 years Moore’s law [12], which states that the number of transistors in integrated circuits will double approximately every two years, had managed to keep pace. However this feat
Guillermo Ibarra-Reyes
Page 4
Chapter 1. Introduction
has seen its share of setbacks. Since 2007 Intel has operated on a "tick-tock" development and
manufacturing model, in which "ticks" represent manufacturing process shrink and "tocks" improve the microarchitecture. However in their 2015 earnings conference, Intel confirmed reports
in the delay of the 10 nanometer semiconductor node (10 nm) processor codename Cannonlake
and introduced an intermediary 14 nm Kaby Lake. The introduction of this third product points
to a break or redefinition of Moore’s law, where Intel’s cadence is now closer to 2.5 years as
opposed to 2 [13]. The 10 nm Cannonlake is set to be released by the end of 2017, possibly
following the new Process, Architecture, Optimization model. Other efforts to keep up with
Moore’s law include TSMC and IBM developing a 7 nm process technology [14].
The number of transistors created a heat barrier problem. Switching and leakage power of
several hundred-million transistor process chips represented a major cooling problem [15]. Additionally even with an ever increasing clock frequency, chip architecture advances and growing
cache sizes were not enough to keep pace with the one to one correspondence of Moore’s law
with respect to performance; the power-performance dilemma became a pressing issue. The solution was to reduce clock frequency and thus allowing the ability to place more than one CPU
core on the same die.
For over a decade, multicore processing units had been available to consumers. The number of
cores within each processor has increased dramatically. From the first dual core processors in
2006 (Intel Core Duo and AMD Athlon 64 X2) up to 24 cores on the Intel Xeon E7-8894 v4.
Cache size has not increased with the same pace, hence the amount of memory available for
each core has decreased, which in turn places a greater emphasis on the developer to efficiently
use the available resources in parallel computing applications.
Historically, the OpenMP (Open Multi-Processing) has been the standard technique for shared
memory parallel computing [16]. Its wide usage can be attributed to its standardized application
programming interface (API) for C, C++, and Fortran. Another reason for OpenMP’s popularity has been its ability to use sequential code in a parallel context, through the use of pragmas
(C/C++). For example the pragma omp parallel is used to fork additional threads perform the
task enclosed in the parallel construct. So with the simple annotation #pragma omp parallel, the
compiler internally handles the intricacies of thread parallelization. However this ease of use
comes at a price, developers are faced with the challenge of achieving efficient parallel scaling
given OpenMP’s blackbox approach.
In this thesis, the Gemma code is written in the D programming language [17]. D’s parallel
standard library (std.parallelism) implements high-level primitives for symmetric multiprocessing (SMP). Primitives include parallel foreach, parallel reduce, parallel eager map, pipelining
and future/promise parallelism [17]. This approach offers explicit parallel constructs that work
on a processor. Whereas OpenMP provides meta-data to allow the compiler to parallelize sequential code.
Page 5
IPN-ESFM
1.4. Neutron Transport Solution Methods
1.3.2
Graphical Processing Units
The initial design purpose of graphical processing units (GPUs) was a display accelerator capable of image creation in a frame buffer intended for output to a display device. By the early
2000s, GPUs were designed to produce a color for every pixel on the screen through the use of
programmable arithmetic units or pixel shaders [18]. These shaders were soon used for general
purpose computing, paving the way for the use of GPU computing in HPC applications.
Interacting with the GPU in the early days was cumbersome, computations were carried out
in the shading languages. In 2006, NVIDIA’s Compute Unified Device Architecture (CUDA)
opened the doors to general purpose graphical processing unit [19]. With CUDA there was no
longer a need to learn shader languages such as OpenGL or DirectX.
1.4
Neutron Transport Solution Methods
Neutron transport solution methods may be classified into two fundamentally different techniques, commonly referred to as stochastic or Monte Carlo and deterministic methods. Monte
Carlo methods are based on probabilistic interpretations of the neutron transport process, in
which the random number of histories of individual particles are calculated through the use of a
pseudo random number generator. In each history, random numbers are generated and sampled
using probability distributions for scattering angles, distance between collisions, type of interaction and so on. These results are averaged over a large number of histories and hence represent
the behavior. On the other hand deterministic methods rely on solving the transport equation;
which involves discretizing each of its independent variables, resulting in a very large algebraic
system of equations.
Generally speaking, the Monte Carlo method is more accurate. When considering the system
in its exact geometry and correct nuclear cross sections are known, the results from the Monte
Carlo simulation will only contain statistical errors. Even then the probable statistical error can
be reduced below a specified level by selecting a sufficient amount of particles to model.
The ability to model the true geometry of a system is a clear advantage of Monte Carlo methods.
Using the constructive solid geometry (CSG) technique, complex surfaces of objects are modeled using Boolean operators to combine simple objects or primitives [20]. Typical primitives
include: cuboids, cylinders, prisms and spheres. Whereas the allowable Boolean operations on
sets are: union, intersection and difference as well as geometric transformations. MCNP [21]
and Serpent [22] use CSG to model the geometry.
However Monte Carlo’s ability to treat complex geometries with great fidelity and to accurately
represent the extremely complex energy dependence of cross section data comes at a heavy cost,
in terms of set up and computational burden. For example, the central limit theorem states that
for any Monte Carlo simulation the statistical error in the estimation of a given quantity (with a
Guillermo Ibarra-Reyes
Page 6
Chapter 1. Introduction
probability of 0.68) is given as [23]:
Statistical error  p
s
NMC
(1.1)
where s is the standard deviation of the given problem and NMC is the number of the particles
used. From (1.1), decreasing the statistical error by a factor of 10 requires increasing NMC by
a factor of 100, resulting in an enormous computational expense. On the other hand, given the
appropriate approximations and discretization conditions, deterministic methods can produce
acceptable results in a fraction of the time required by Monte Carlo methods.
When a detailed distribution of a dependent variable, such as the spatial profiles of neutron flux
and power, are desired; Monte Carlo simulations may not be as appropriate as deterministic
methods [23]. The reason is that in Monte Carlo neutron flux or other quantities are not calculated at a point but rather in some incremental volume DV D~WDE of phase space. Determining a
detailed distribution of a variable requires dividing the domain of the problem in many small DV
so that the variable may be estimated in each cell. However, as DV is further divided in order
to increase the spatial resolution, the fraction of N histories contributing to each cell decreases
rapidly. Which in turn causes the statistical uncertainty to grow rapidly to unacceptable levels,
even when a large number of histories is used.
1.4.1
Neutron Transport Equation
The design and analysis of nuclear reactors relies on the accurate and detailed neutron distribution within the reactor, which is a function of space, angle, energy and time. This behavior
can be understood by solving the neutron transport equation, also know as the Boltzmann equation due to its connection to the study of the kinetic theory of gases. One of the most common
forms of the neutron transport equation is the time-independent integro-differential k-eigenvalue
equation [23]:
⇣
⌘
⇣
⌘ Z
~W · —y ~r, ~W, E + St (~r, E)y ~r, ~W, E =
•Z
⇣
⌘ ⇣
⌘
Ss ~r, E 0 ! E, ~W0 · ~W y ~r, ~W0 , E 0 d~W0 dE 0
0
4p
Z Z
⇣
⌘
c(~r, E) •
+
nS f ~r, E 0 y ~r, ~W0 , E 0 d~W0 dE 0
(1.2)
4pk 0 4p
the corresponding variables are defined in Table 1.1. The nuclear cross sections and fission
spectrum in (1.2) satisfy the following identities [7]:
Z •
0
St (~r, E) = Ss (~r, E) + Sg (~r, E) + S f (~r, E)
Z •Z
⇣
⌘
Ss (~r, E) =
Ss ~r, E 0 ! E, ~W · ~W0 d~W0 dE 0
0
c(~r, E) dE = 1
⇣
⌘
Ss ~r, E 0 ! E, ~W · ~W0 =
Page 7
4p
⇣
⌘
2n + 1
0
0
~
~
S
~
r,
E
!
E
P
W
·
W
.
sn
n
Â
n=0 4p
N
(1.3a)
(1.3b)
(1.3c)
(1.3d)
IPN-ESFM
1.5. Thesis Overview
Table 1.1: Variables of the time-independent integro-differential k-eigenvalue equation
Variable
unit
Description
~r
~W
E
k
c
y
St
Ss
Sf
n
cm
sr
MeV
neutrons/(cm2 sr)
cm 1
cm 1
cm 1
-
neutron position
angular direction vector
neutron energy
neutron multiplication factor
fission neutron energy spectrum
angular neutron flux
neutron macroscopic total cross section
neutron macroscopic scattering cross section
neutron macroscopic fission cross section
average number of neutrons produced per fission
Equation ⇣(1.2) can⌘ be simplified by defining the terms on the right hand side as the total neutron
source Q ~r, ~W, E :
⇣
⌘ Z
~
Q ~r, W, E =
•Z
⇣
⌘ ⇣
⌘
Ss ~r, E 0 ! E, ~W0 · ~W y ~r, ~W0 , E 0 d~W0 dE 0
0
4p
Z Z
⇣
⌘
c(~r, E) •
+
nS f ~r, E 0 y ~r, ~W0 , E 0 d~W0 dE 0 .
4pk o 4p
(1.4)
Now the time-independent integro-differential k-eigenvalue equation can be expressed as:
⇣
⌘
⇣
⌘
⇣
⌘
~W · —y ~r, ~W, E + St (~r, E) y ~r, ~W, E = Q ~r, ~W, E .
(1.5)
1.5
Thesis Overview
This Chapter presented the growth of computational power and its effect the HPC scientific
community. By leveraging the technological advances, high fidelity calculations are possible in
nuclear analysis software specifically the use of neutron transport theory. The neutron transport
equation was briefly introduced, in Chapter 2 the method of characteristics formulation will
be derived in greater detail. Chapter 3 presents the geometric and characteristic discretization
required for the MOC framework. The focus of Chapter 4 is the development aspects of the
Gemma code. Chapter 5 outlines benchmark cases and their corresponding results; including
homogeneous infinite slabs, pin cells, lattice assembly and the C5G7 problem. Finally Chapter
6 provides a discussion of the obtained results, conclusions, and proposed future work.
Guillermo Ibarra-Reyes
Page 8
Chapter 2
Method of Characteristics Formulation
2.1
Introduction
Solving the transport equation within a full reactor core without the need for separate lattice calculations, which generates homogenized few group cross sections, was at one point beyond the
limits of available computational resources. In order to circumvent impractical solution times,
the neutronic analysis of reactor cores was carried out in two stages; the generation of tabulated
neutron cross sections for homogenized regions such as pin cells or fuel assemblies followed
by the core calculations. Typically the core calculation solution methods employ the diffusion
approximation of the neutron transport equation.
The method of characteristics (MOC) is an attractive candidate for incorporating transport theory for full reactor core calculations. Due to the phenomenal increase in computing power in
the last decade, MOC is a viable technique and considered practical in terms of computation
time due to its highly parallelizable nature. Several lattice level codes have incorporated MOC
as a method of solving the multigroup transport equation. Such examples include AEGIS [24],
APOLLO [25], CASMO-5 [26], DRAGON [27] and OpenMOC [28].
MOC’s clear advantages over commonly used transport theory methods include: (a) the flexibility in handling complex geometries typically encountered in reactor cores, (b) the capability
to produce detailed flux and power distribution for the solution regions, (c) the potential to treat
anisotropic scattering and (d) the ability to consider neutronically large sized domains. Methods such as the collision probability method [29], discrete ordinates method [30] and the Monte
Carlo method [31] present difficulties with one or more of the previously mentioned features.
Problems include (a) for the discrete ordinates method, (b) for the Monte Carlo method, (c)
and (d) for the collision probability method. The aforementioned is one of the reasons MOC
has gained popularity for not only lattice level applications but also for whole core calculations
without homogenization.
A prerequisite for solving the transport equation by the MOC is the division of the problem
domain into smaller meshes or regions. Another prerequisite is the construction of a sufficiently
large number of characteristic lines or rays, along which the transport equation is solved. Geometric treatment of the system within the Gemma code, as well as the track generation routine
9
2.2. Method of Characteristics General Theory
are explained in Chapter 3. The following chapter explains the derivation of the set of equations
that form the method of characteristics.
2.2
Method of Characteristics General Theory
As mentioned earlier, deterministic methods discretize the independent variables from the transport equation resulting in an algebraic system of equations which is then solved. For steady state
cases, the independent variables are position, angular direction vector and energy. The energy
variable is discretized with the multigroup approximation. Handling of the angular direction
vector presents a few options. The most common techniques include the discrete ordinates
method, the spherical harmonics method and the integral transport methods [23, 32, 33].
One main distinction among these methods is the form of the neutron transport equation used.
The discrete ordinates and spherical harmonics methods use the multi-group integro-differential
form, while integral transport methods applies the integral form of the transport equation in its
scheme. This section covers the derivation of the integral transport methods, for more information on the discrete ordinates method or the spherical harmonics method may be found elsewhere
[23, 32, 33].
2.2.1
Characteristic Form of the Transport Equation
The characteristic form of the transport equation defines the neutron path and is obtained by
integrating the streaming operator ~W · —y over a characteristic (a straight line in the ~W direction)
[34]. For a neutron traveling in the ~W direction between the positions ~r0 and~r:
~r = ~r0 + s ~W
(2.1)
where s is the magnitude of the vector~r ~r0 . For the derivative along the neutron steaming path,
consider:
d
dx ∂
dy ∂
dz ∂
=
+
+
(2.2)
ds ds ∂ x ds ∂ y ds ∂ z
with
ds ~W = d~r.
(2.3)
Considering the dot products of (2.3), such that ds ~W · ı̂ı = dx, ds ~W · |ˆ = dy, and ds ~W · k̂k = dz and
substituting into (2.2):
⇣
⌘ ∂
⇣
⌘ ∂
⇣
⌘ ∂
d
~
~
~
ı
k
|
ˆ
= W · ı̂
+ W·
+ W · k̂
= ~W · —.
ds
∂x
∂y
∂z
(2.4)
Finally substituting (2.4) into (1.5):
⌘
⇣
⌘ ⇣
⌘
⇣
⌘
d ⇣
y ~r0 + s ~W, ~W, E + St ~r0 + s ~W, E y ~r0 + s ~W, ~W, E = Q ~r0 + s ~W, ~W, E .
ds
Guillermo Ibarra-Reyes
(2.5)
Page 10
Chapter 2. Method of Characteristics Formulation
The same substitution can be applied to the total neutron source:
⇣
⌘ Z •Z
⇣
⌘ ⇣
⌘
0
0 ~
0
0
~
~
~
~
~
~
Q ~r0 + s W, W, E =
Ss ~r0 + s W, E ! E, W · W y ~r0 + s W, W , E d~W0 dE 0
⇣
⌘ 0 4p
⇣
⌘ ⇣
⌘
c ~r0 + s ~W, E Z • Z
0
0
0
~
~
~
+
nS f ~r0 + s W, E y ~r0 + s W, W , E d~W0 dE 0 .
(2.6)
4pk
0
4p
The analytical solution of (2.5) requires the integrating factor:
Rs
e
hence:
0
St (~r0 +s0 ~W, E )ds0
(2.7)
⇣
⌘
⇣
⌘ Rs
0~
0
~
~
~
y ~r0 + s W, W, E = y ~r0 , W, E e 0 St (~r0 +s W, E )ds
Z s ⇣
⌘ Rs
00 ~
00
+ Q ~r0 + s0 ~W, ~W, E e s0 St (~r0 +s W, E )ds ds0 .
(2.8)
0
Equation (2.8) is the solution of the characteristic form of the continuous neutron transport
equation. A numerical solution requires appropriate discretizations. The following subsections
present the common approximations applied for this task.
2.2.2
Multigroup Energy Approximation
The multigroup energy approximation is a technique used to discretize the energy variable. In
this approximation, a finite number of energy groups are selected:
Emin = EG < EG
1
< · · · < Eg < Eg
1
< · · · < E2 < E1 = Emax
where Emin is small enough to make all neutrons with energies below this value negligible and
Emax is large enough that neutrons with energies above Emax are also negligible. The multigroup
form of the Boltzmann equation is expressed as:
⇣
⌘
⇣
⌘
⇣
⌘
~W · —yg ~r, ~W + St,g (~r) yg ~r, ~W = Qg ~r, ~W .
(2.9)
Similarly the characteristic form of the transport equation given in (2.5) can also be expressed
in a multigroup form:
⇣
⌘
⇣
⌘ ⇣
⌘
⇣
⌘
d
yg ~r0 + s ~W, ~W + St,g ~r0 + s ~W yg ~r0 + s ~W, ~W = Qg ~r0 + s ~W, ~W
(2.10)
ds
likewise the total neutron source is defined as:
⇣
⌘
Qg ~r0 + s ~W, ~W =
+
Page 11
G Z
Â
g0 =1 4p
⇣
⌘
⇣
⌘
Ss,g0 !g ~r0 + s ~W, ~W0 · ~W yg0 ~r0 + s ~W, ~W0 d~W0
⇣
⌘
~
cg ~r0 + s W
4pk
G
Â
g0 =1
⇣
⌘Z
⇣
⌘
~
nS f ,g0 ~r0 + s W
yg0 ~r0 + s ~W, ~W0 d~W0 .
4p
(2.11)
IPN-ESFM
2.2. Method of Characteristics General Theory
Therefore the solution to the multigroup characteristic neutron transport equation is the following:
⇣
⌘
⇣
⌘ Rs
0~
0
yg ~r0 + s ~W, ~W = yg ~r0 , ~W e 0 St,g (~r0 +s W)ds
Z s
⇣
⌘ Rs
00 ~
00
+ Qg ~r0 + s0 ~W, ~W e s0 St,g (~r0 +s W)ds ds0 .
(2.12)
0
The multigroup equations (2.11) and (2.12) of the characteristic form use the energy averaged
cross sections expressed as:
⇣
⌘
R Eg 1
~
S
(~
r,
E)
y
~
r,
W,
E
dE
t
Eg
⇣
⌘
St,g (~r) =
(2.13)
R Eg 1
~W, E dE
y
~
r,
Eg
⇣
⌘
R Eg 1
~W, E dE
nS
(~
r,
E)
y
~
r,
f
Eg
⌘
nS f ,g (~r) =
(2.14)
R Eg 1 ⇣
~W, E dE
y
~
r,
Eg
⌘ ⇣
⌘
R Eg0 1 R Eg 1 ⇣
0
0
00
0
~
~
~
⇣
⌘
y ~r, W, E dE 0 dE 00
Eg0
Eg Ss ~r, W · W, E ! E
0
⌘
Ss,g0 !g ~r, ~W · ~W =
(2.15)
R Eg0 1 ⇣
~W, E 0 dE 0
y
~
r,
E0
cg (~r) =
2.2.3
Z Eg
g
1
c (~r, E) dE.
Eg
(2.16)
Discrete Ordinates Approximation
The discrete ordinates approximations deals with the discretization of the angular variable.
Within the method of characteristics framework, it is introduced to approximate the integral
over the angular domain in the total neutron source (2.11). This represents applying quadrature
rules in the evaluation of the integral over the angular flux using a weighted sum of fluxes at M
specific angles. Therefore:
Z
⇣
⌘
⇣
⌘
M
fg (~r) =
yg ~r, ~W0 d~W0 ⇡ Â wm yg ~r, ~Wm
(2.17)
4p
m=1
Applying this approximation to (2.12) and (2.11), leads to:
⇣
⌘
Rs
0~
0
~
yg,m ~r0 + s Wm = yg,m (~r0 ) e 0 St,g (~r0 +s Wm )ds
Z s
⇣
⌘ Rs
00 ~
00
0~
+ Qg,m ~r0 + s Wm e s0 St,g (~r0 +s Wm )ds ds0 ,
(2.18)
0
where
⇣
⌘
Qg,m ~r0 + s ~Wm =
+
G
 Â
g0 =1 m0 =1
⇣
⌘
~
cg ~r0 + s Wm
4pk
Guillermo Ibarra-Reyes
M
G
⇣
⌘
⇣
⌘
wm0 Ss,g0 !g ~r0 + s ~Wm0 , ~Wm0 · ~Wm yg0 ,m0 ~r0 + s ~Wm0
nS f ,g0
Â
0
g =1
⇣
⌘
~r0 + s ~Wm0
M
Â
0
m =1
⇣
⌘
wm0 yg0 ,m0 ~r0 + s ~Wm0 .
(2.19)
Page 12
Chapter 2. Method of Characteristics Formulation
Qi,g
si,m,k
i
k
Figure 2.1: Spatial Discretization of an arbitrary region with constant material properties.
The approximation from (2.17) can be expanded to consider azimuthal and polar angle quadratures m 2 {1, 2, . . . , M} and p 2 {1, 2, . . . , P} with weights wm and w p for the azimuthal plane
and axial plane, respectively. Applying this decomposition to (2.18) and (2.19):
yg,m,p (~r) = yg,m,p (~r0 ) e
Qg,m,p (~r) =
G
M
Rs
0
St,g (~r)ds0
P
where
2.2.4
0
Qg,m,p (~r) e
wm0 w p0 Ss,g0 !g
Â
Â
Â
0
0
0
g =1 m =1 p =1
+
+
Z s
Rs
s0 St,g
(~r0 +s00 ~Wm,p )ds00 ds0
(2.20)
⇣
⌘
~r, ~Wm0 ,p0 · ~Wm,p yg0 ,m0 ,p0 (~r)
M
P
cg (~r) G
nS f ,g0 (~r) Â Â wm0 w p0 yg0 ,m0 ,p0 (~r)
Â
4pk g0 =1
m0 =1 p0 =1
~r = ~r0 + s ~Wm,p .
(2.21)
(2.22)
Constant Material Properties and Flat Source Approximation within
a Region
In the discretization of the spatial domain, the system is divided into arbitrarily sized regions.
A characteristic or track t with an azimuthal angle m runs along a region i creating a spatial
discretization or segments of length si,m,t , see Figure 2.1. This subsection explores the effect of
assuming a constant total source term and constant material properties within a region.
A common assumption under the MOC framework is that the total source, Qg , is constant within
each discrete spatial region. This concept is known as the flat source approximation and the
spatial regions are termed flat source regions (FSRs). The assumption implies that the total
source does not vary along the length of the characteristic k entering a FSR i at~r0 and exiting at
~r0 + si,m,k~Wm :
⇣
⌘
⇣
⌘
Qi,g = Qi,g (~r0 ) = Qi,g ~r0 + si,m,k~Wm = Qi,g ~r0 + s~Wm , 0  s  si,m,k .
(2.23)
Page 13
IPN-ESFM
2.2. Method of Characteristics General Theory
Aside from a constant total source, constant material properties are also assumed across each
FSR. These properties are area averaged, where the area of the FSR is approximated by the
length of characteristic k and the effective width of k, see Figure 2.1 for the representation of
d Am,t . The effective width within this work is represented as the distance between the set of
characteristics for angle m and its corresponding weights. The area approximation will be discussed further in Subsection 2.2.7.
Hence the area averaged cross sections for FSR i with area Ai are defined as:
St,i,g =
nS f ,i,g =
Ss,i,g0 !g =
ci,g =
R
s2Ai St,g (s) fg (s) ds
R
(2.24)
R
s2Ai fg (s) ds
s2Ai nS f ,g (s) fg (s) ds
R
(2.25)
R
s2Ai fg (s) ds
s2Ai Ss,g0 !g (s) fg (s) ds
R
R
(2.26)
s2Ai fg (s) ds
s2Ai cg (s) fg (s) ds
R
s2Ai ds
(2.27)
.
In Gemma the neutron cross sections are specified as input parameters and each FSR contains
only one material. Therefore the previous area averaged integrals or material cross sections are
obtained from lattice codes such as the Serpent Monte Carlo code [22] or specified as parameters
for benchmark cases.
With the flat source approximation the integral over s from (2.20) can be solved analytically for
region i:
Z s
0
Qi,g,m,p (~r) e
Rs
s0 St,i,g
(~r0 +s00 ~Wm,p )ds00 ds0 = Qi,g,m,p 1
St,i,g
e
St,i,g sk,i,m,p
.
(2.28)
Therefore the outgoing angular flux for each characteristic k or segment passing through each
region i can be expressed as:
out
in
yk,i,g,m,p
= yk,i,g,m,p
e
St,i,g,m,p sk,i,m,p
+
Qi,g,m,p
1
St,i,g
e
St,i,g sk,i,m,p
.
(2.29)
The flat source total source term Qi,g,m,p for FSR i with an area Ai is now defined in terms of an
area averaged angular flux, y i,g,m,p within the FSR:
Qi,g,m,p =
G
M
P
wm0 w p0 Ss,i,g0 !g
Â
Â
Â
0
0
0
g =1 m =1 p =1
+
⇣
⌘
~Wm0 ,p0 · ~Wm,p y
i,g,m0 ,p0
M
P
ci,g G
nS f ,i,g0 Â Â wm0 w p0 y i,g0 ,m0 ,p0 .
Â
4pk g0 =1
m0 =1 p0 =1
(2.30)
The region average angular flux y i,g,m,p term is calculated from the segment-average angular
flux:
R sk,i,m,p
in
out
yi,g,m,p (s0 )ds0 yk,i,g,m,p yk,i,g,m,p Qi,g,m,p
0
ek,i,g,m,p =
y
=
+
.
(2.31)
R sk,i,m,p
St,i,g sk,i,m,p
St,i,g
ds0
0
Guillermo Ibarra-Reyes
Page 14
Chapter 2. Method of Characteristics Formulation
Finally the region average angular flux is calculated from the segment average angular fluxes:
y i,g,m,p =
 yek,i,g,m,psk,i,m,pd Am,k
k2i
 sk,i,m,pd Am,k
(2.32)
.
k2i
2.2.5
Isotropic Scattering Approximation
Another common approximation within the method of characteristics framework is the consideration of an isotropic source. Although higher order scattering derivations have been developed,
within this work the simplest approximation is considered. The anisotropy level of the source
may be represented by expanding the source as a function of Legendre polynomials [23]. As an
isotropic source, the total source is expressed in terms of scalar flux fi,g :
!
G
ci,g G
1
Qi,g (~r) =
Ss0 ,i,g0 !g fi,g0 (~r) +
nS f ,i,g0 fi,g0 (~r)
(2.33)
4p gÂ
k gÂ
0 =1
0 =1
where,
fi,g =
M
P
  wmw py i,g,m,p.
(2.34)
m=1 p=1
Expression (2.34) is an extension of the discrete ordinates approximation, which considers the
azimuthal and polar angles over the angular phase space in order to obtain the scalar flux.
2.2.6
Algebraic Optimization of the MOC Framework Equations
The MOC solution method is described in Section 2.3. However it is worth noting that being an
iterative solution method the equations may be optimized, resulting a reduction in the number
of floating point operations. This approach involves using algebra to remove terms, which in
essence moves operations from inner loops to outer loops. Such a technique is common among
the scientific community. In the case of the MOC framework, this approach has been described
by Kochunas [35] and used in the MPACT code [36].
For MOC updating the region scalar flux requires the following operations:
out
• outgoing angular flux yk,i,g,m,p
(2.29)
ek,i,g,m,p (2.31)
• segment average angular flux y
• region average angular flux y i,g,m,p (2.32)
• region average scalar flux fi,g (2.34)
From these expressions the outer and inner loops are clearly identified. For example, the calcuout
ek,i,g,m,p (inner loops).
lation of fi,g requires y i,g,m,p (outer loop) and consequently yk,i,g,m,p
and y
Page 15
IPN-ESFM
2.2. Method of Characteristics General Theory
Angular flux change along the characteristic can be expressed as:
✓
◆
Qi,g,m,p
in
out
in
Dyk,i,g,m,p = yk,i,g,m,p yk,i,g,m,p = yk,i,g,m,p
1
St,i,g
e
St,i,g sk,i,m,p
.
(2.35)
When considering isotropic scattering, a reduced source term is rather convenient and defined
as:
Qi,g,m,p
Qi,g
Qi,g =
=
.
(2.36)
St,i,g
St,i,g
The use of a precomputed reduced source term eliminates a division operation within the innermost loop and eliminates the angle dependence due to the discrete ordinates approximation. The
angular flux change may then be expressed as:
⇣
⌘
in
Dyk,i,g,m,p = yk,i,g,m,p
Qi,g 1 e St,i,g sk,i,m,p .
(2.37)
Using the new definitions of Qi,g and Dyk,i,g,m,p , the segment average angular flux can be expressed as:
Dyk,i,g,m,p
ek,i,g,m,p =
y
+ Qi,g .
(2.38)
St,i,g sk,i,m,p
Accordingly the region average angular flux may be defined as:
y i,g,m,p =
 Dyk,i,g,m,pd Am,k
k2i
St,i,g  sk,i,m,p d Am,k
+ Qi,g .
(2.39)
k2i
2.2.7
FSR Area Approximation
A key component of the MOC framework is the solution of the region averaged angular fluxes
in (2.39), which in turn is used to determine the scalar flux for each region. The total area approximation in a FSR is presented in Figure 2.2, where dm is the distance between characteristics
of the azimuthal angle m. Such that characteristic k of length si,k has an angle of q p with respect
to the polar axis when projected onto the azimuthal axis. Therefore the differential area may be
expressed as:
d Am,k = dm sin q p
(2.40)
leading to the FSR volume calculation:
Vi = Â sk,i,m,p d Am = Â sk,i,m dm wm
k2i
(2.41)
k2i
where,
sk,i,m,p =
sk,i,m
.
sin q p
(2.42)
The previous expression is the 3D projection of a track segment for the polar angle q p .
Guillermo Ibarra-Reyes
Page 16
Chapter 2. Method of Characteristics Formulation
kn-3
kn-2
kn-1
dm
kn
kn+1
kn+2
kn+3
Figure 2.2: Area approximation for a FSR.
Substituting the area and volume approximations into (2.39):
y i,g,m,p =
 dm sin q pDyk,i,g,m,p
k2i
+ Qi,g .
Vi St,i,g
(2.43)
Therefore:
M
P
   wmw pdm sin q pDyk,i,g,m,p
fi,g =
k2i m=1 p=1
"
Vi St,i,g
M
+
P
  wmw pQi,g
m=1 p=1
#
1
= 4p Qi,g +
 wmw pdm sin q pDyk,i,g,m,p .
Vi St,i,g k2i
2.2.8
(2.44)
Summary of Principal MOC Equations
The primary equations used to solve for the FSR total source and scalar flux within the MOC
framework are the following:
!
G
ci,g G
1
Qi,g =
Ss0 ,i,g0 !g fi,g0 (~r) +
nS f ,i,g0 fi,g0 (~r)
(2.45)
4pSt,i,g gÂ
k gÂ
0 =1
0 =1
⇣
⌘
in
Dyk,i,g,m,p = yk,i,g,m,p Qi,g 1 e St,i,g sk,i,m,p
(2.46)
!
1
fi,g = 4p Qi,g +
(2.47)
 wmw pdm sin q pDyk,i,g,m,p .
Vi St,i,g k2i
2.3
MOC Solution Method
The following section describes the methodology employed for the MOC solution method. This
solution method has been described by Kochunas [35] and within the OpenMOC code [28]. The
Page 17
IPN-ESFM
2.3. MOC Solution Method
solution algorithm calculates the eigenvalue ke f f while updating the eigenvector fi,g using (2.45)
- (2.47). Being an iterative method, the scalar flux is updated by a transport kernel. This kernel
represents an inner and outer iteration scheme. While the inner iteration calculates an approximate scalar flux for each region with an assumed constant total source; the outer iteration obtains
an updated total source using the scalar flux from the inner iteration.
2.3.1
Transport Sweep
The inner iteration or the transport sweep algorithm involves solving (2.46) and (2.47). Within
this step, fi,g is calculated for every FSR i and its respective energy group g. Although the track
generation and segmentation are discussed in another chapter, consider a 2D system with its
corresponding characteristics or tracks along its geometric area. At the system boundary a uniform incoming angular flux is assumed for each track. When starting the eigenvalue calculation,
the angular flux is set to some arbitrary value, such as 1, and updated in each inner iteration or
transport sweep.
Within the transport sweep the angular flux change (2.46) along each track for each energy group
is integrated in order to tally the contribution to the scalar flux within a FSR with an assumed
constant total source. Accounting for all the contributions involves a five nested loops over
azimuthal angles, tracks for each azimuthal angle, segments within a track, energy groups and
polar angles. The transport sweep pseudo algorithm is presented in Algorithm 1.
Algorithm 1 Transport sweep algorithm
fi,g = 0 8 i, g
foreach jm 2 M do
foreach k 2 Km do
foreach s 2 Sk do
foreach g 2 G do
foreach q p 2 P do
i = f (s)
Dy = f (i, s, g, jm , q p )
fi,g += fi,g (Dy)
y = Dy
end for
end for
end for
end for
if B.C. is reflective then
y(0) = y
else
y(0) = 0
end if
end for
Guillermo Ibarra-Reyes
// Initiate scalar flux tallies to 0
// Loop over azimuthal angles
// Loop over all tracks with angle jm
// Loop over all segments within track k
// Loop over all energy groups
// Loop over all polar angles
// Find current FSR
// Angular flux change (2.46)
// Tally FSR scalar flux (2.47)
// Update track angular flux
// Adjust incoming angular flux
Page 18
Chapter 2. Method of Characteristics Formulation
Angle 1, track 1 forward direction
Angle 1, track 1 reverse direction
Angle 2, track 28 forward direction
Angle 2, track 28 reverse direction
Figure 2.3: Bi-direction track sweep scheme for two angles.
For every track, the segments are loops over forward and reverse directions. This bi-direction
sweep has the advantage of increasing cache coherency, given that the track segments only need
to be loaded into cache once [37]. Figure 2.3 presents the sweep scheme for two azimuthal
angles.
2.3.2
Reduced Source Calculation
Meanwhile outer iteration or the reduced total source calculation solves (2.45). Given a scalar
flux fi,g , the reduced total source Qi,g is evaluated by looping over every region i and energy
group g. The reduced total source is described in Algorithm 2.
Algorithm 2 Reduced total source algorithm
Qi,g = 0 8 i, g 2 {I, G}
foreach i 2 I do
foreach g 2 G do
foreach g0 2 G do
Qs,g0 = Ss,i,g0 !g fi,g0
Q f ,g0 = ci,g nS f ,i,g0 fi,g0
end for
⇣
⌘
Q f ,g0
1
0
Qi,g = 4pSt,i,g  Qs,g + k
end for
end for
Page 19
g0
// Initiate reduced source tallies to 0
// Loop over all regions
// Loop over all energy groups
// Loop over all energy groups
// Scatter source for g’
// Fission source for g’
// Reduced total source (Eq. 2.45)
IPN-ESFM
2.3. MOC Solution Method
2.3.3
Eigenvalue Calculation
In the previous subsection, the reduced total source evaluation was presented. However in (2.45)
the 1/k term or eigenvalue of the system must also be determined. Within reactor physics, the
eigenvalue is calculated using the power method [23], an iterative algorithm for finding the
largest eigenvalue of a system given a scalar flux. The general form of the eigenvalue problem
is stated as:
1
Tf = cFf
(2.48)
k
where F represents the fission component, c represents the neutron production probability for
every energy group, and T represents the streaming, absorption and scattering of neutrons. Applying the power method to (2.48), the following iterative scheme is obtained:
f `+1 = T
k`+1 = k`
1
cFf `
k`
Ff `+1 1
1
Ff `
(2.49)
(2.50)
1
where ` represents the iteration index.
Within the MOC framework the updated scalar flux distribution fi,g is obtained from the inner
iteration, a better approximation for (2.50) is the following:
l
G
i
g
 Vi  nS f ,i,gfi,g`+1
k`+1 = k`
l
G
i
g
(2.51)
 Vi  nS f ,i,gfi,g`
2.3.4
Convergence Criteria
The quantities reduced total source and scalar flux for every region are updated within the MOC
iterative scheme. In nuclear reactor analysis, the scalar flux distribution is of particular interest.
Therefore a common approach is to continue iterations until the scalar flux converges or the difference falls below a given tolerance. The scalar flux distribution difference after each iteration
is given as:
v
!
u
u I G Q`+1 Q` 2
i,g
i,g
DQ = t Â
.
(2.52)
`
Q
i g
i,g
A typical tolerance value is e = 1 ⇥ 10 6 . The role of the convergence criteria within the general
calculation scheme is presented in Algorithm 3.
2.3.5
Exponential Function Evaluation
In terms of floating point mathematical arithmetic, the "cost" of evaluating functions varies. Although the exact number of cpu clock cycles differ from processor to processor, there is a well
Guillermo Ibarra-Reyes
Page 20
Chapter 2. Method of Characteristics Formulation
Algorithm 3 MOC solution algorithm
k0 = 1
fi,g = 1 8 i, g 2 {I, G}
y0,k,g,p = 0 8 k, g, p 2 {K, G, P}
for (` = 0; ` < MaxIter; `++) do
Ff `
l
1
G
`
=  Vi  nS f ,i,g fi,g
g
i
`
`
fi,g /= Ff 1 8 i, g 2 {I, G}
`
yd,k,g,p
/= Ff ` 1 8 d, k, g, p 2 {2, K, G, P}
` )
Q`+1 = f (fi,g
`+1
fi,g
= f (Q`+1 )
l
G
`+1
Vi nS f ,i,g fi,g
g
i
k`+1 = k` l
G
`
Vi nS f ,i,g fi,g
g
v i
!
u
u I G Q`+1 Q` 2
i,g
i,g
DQ = t
`
Qi,g
i g
 Â
 Â
ÂÂ
if ` > 0 && DQ < e then
break
end if
end for
Page 21
// Eigenvalue value initialization
// Initialize scalar flux to 1
// Initialize angular flux starting points
// Normalize scalar flux to fission source
// Normalize angular flux to fission source
// Transport sweep, Algorithm 1
// Source Update, Algorithm 2
// Update eigenvalue
// Total source difference
// Convergence reached, exit loop
IPN-ESFM
2.3. MOC Solution Method
defined relation among floating point operation costs. In order of increasing costs, the floating
point operations required in the MOC framework include: addition/subtraction, multiplication,
division, exponential and sine/cosine. The sine and cosine evaluation are considered slightly
more expensive than the exponential; however, given that trigonometric function evaluation is
not present within the iteration scheme. Therefore the exponential evaluation within (2.46) is by
far the most expensive floating point operation.
A common approach to reduce the computation burden involved with the evaluation of exponential functions is the use of look up tables. In a previous work [38], the calculation speedup and
tabulation error for different interpolation methods was investigated. The most efficient type of
interpolation was linear with a maximum approximation error given by:
1 l2
e=
+O
8 N2
✓
1
N3
◆
⇡
1 l2
.
8 N2
(2.53)
where l is the maximum argument within the exponent and N is the number of values in the interpolation table. From (2.46) the exponential argument is St,i,g sk,i,m,p . The maximum argument
is easily identified during the track segmentation phase, which is explained in detail in Chapter 3.
The construction of the evaluation table has been previously discussed in [28] and is summarized
as follows. From (2.53) the number of table values may be defined given a desired maximum
error:
lmax
N=p
(2.54)
8e
Equal logarithmic spacing for the table is defined as:
DN =
lmax
.
N
(2.55)
Finally the slope mn and y-intercept bn of the linear approximation for the exponential at angle
q p for each n 2 {0, 1, . . . , N 1} are defined as:
nDN
e sin q p
mn =
sin q p

nDN
nDN
sin q p
bn = e
1+
.
sin q p
(2.56)
(2.57)
Since mn and bn are evaluated and stored at every q p the table has 2PN values, where P is the
number of polar angles.
The interpolation table is carried out as follows. The n index for track k with a segment length
sk,i,m,p located in region i at energy group g is given by the floor function:
St,i,g sk,i,m,p
n = 2P
DN
Guillermo Ibarra-Reyes
⌫
(2.58)
Page 22
Chapter 2. Method of Characteristics Formulation
Given index n and the polar angle p the slope mn,p and y-intercepted bn,p within table t are
located at:
mn,p = t[n + 2p]
bn,p = t[n + 2p + 1].
(2.59)
(2.60)
Finally the approximated exponential is evaluated as:
eSt,i,g sk,i,m,p ⇡ mn ⇤ St,i,g sk,i,m,p
bn,p .
(2.61)
For the Gemma code a precision value e of 1 ⇥ 10 6 is selected. This value assures that the
approximation effect is low enough as to not impact the results while providing a speed up
factor of roughly 2.
Page 23
IPN-ESFM
2.3. MOC Solution Method
Guillermo Ibarra-Reyes
Page 24
Chapter 3
Geometric Modeling
3.1
Introduction
Within the method of characteristics, the neutron transport equation is solved along segments of
a track. Segments demarcate the flat source regions within the geometric system along a well
defined azimuthal angle trajectory. As long as these segments can be accurately generated, any
system may be modeled. This chapter presents the modeling scheme, region creation, track generation, and the track segmentation for the Gemma code.
When considering arbitrary geometries, the constructive solid geometry [20] (CSG) is commonly employed in Monte Carlo codes such as Serpent [22] and MCNP [21]. CSG allows
constructive models to be represented using primitive solids and boolean operators. Primitive
solids may include, but not limited to, blocks (cubes), triangular prisms, spheres, cylinders, and
cones. Such an approach permits the modeling of the highly repetitive structures as well as the
complex geometries found in nuclear reactors. The implementation strategy of the CSG method
for 2D systems is described in Section 3.2.
Given that integral transport methods (such as MOC) solve the transport equation along tracks
that span the geometry of the system being analyzed, a flexible ray tracing technique is required.
In cases with high material heterogeneity, a greater number of tracks is needed in order to accurate replicate the scalar flux in regions with moderators. On the opposite end of the spectrum,
a simple system such as a homogeneous infinite medium with a minimum number of tracks
should produce high fidelity results. Such an approach is fundamental in creating a flexible and
all purpose code. The track generation methodology is explained in detail in Section 3.4.
Another key component in the geometric modeling pre-processing is the track segmentation.
This routine combines the system representation via CSG and the track generation. In the
Gemma code a methodology is developed to optimize the track segmentation process. By exploiting the structured definition of the geometric system, the region finding algorithm reduces
the search pool to a subset of the total system. Further details on these algorithms are given in
Section 3.5.
25
3.2. CSG Implementation
r
s
x0, y0
x0, y0
s1
s2
sqr
cyl
x0, y0
rect
Figure 3.1: Surface building blocks in Gemma with their respective parameters.
3.2
CSG Implementation
Since Gemma is a 2 dimensional neutron transport solver, a simplified approach to the CSG is
adopted. With regards to the primitive shapes or surfaces available for construction, the options
are circles, squares, and, by extension, rectangles (see Figure 3.1). These surfaces are considered
infinite in the z direction. Although these options may seem limited, as will be demonstrated in
the following section, they are more perfectly adequate for defining 2D nuclear reactor structures.
The boolean operations are inspired by their application in Serpent [22], where a surface has
a positive and negative side. This distinction comes from the the location of a point within a
geometric shape. Consider a circle with radius r and a center located at (x0 , y0 ), the point (x, y)
is located within the circle if:
(x0
x)2 + (y0
y)2 < r2
(3.1)
Equation (3.1) may be expressed as:
f (x, y) = (x0
x)2 + (y0
y)2
r2
(3.2)
such that:
if f (x, y) = 0,
if f (x, y) < 0,
if f (x, y) > 0,
then (x, y) lies on the boundary
then (x, y) lies inside the surface
then (x, y) lies outside the surface.
Therefore the negative side represents the space within the surface and the positive side the complement, see Figure 3.2. Understanding the implications of the surfaces sides is necessary for
the user when defining cells, as discussed in the rest of the section. These concepts are also
required when finding the entry and exit points, if any, of the intersection of a given track with a
surface, see Section 3.5.
Although written in the D programming language (further details of the development are discussed in Chapter 4) the end user interacts with Gemma through an input file, this approach
provides great advantage to the user, in that they are not required to learn any programming
Guillermo Ibarra-Reyes
Page 26
Chapter 3. Geometric Modeling
-
+
f(x,y)
Figure 3.2: Positive and negative side of a surface defined by f (x, y).
3
2
1
Figure 3.3: Cell universe representation of a pin-cell.
language or having to deal with source code compilation processes. Once given the executable
file, any potential error will be related to run time. Gemma is programed in such a way that these
errors are caught and the user will be provided with a clear message on the error and correction
routes as opposed to presenting the usual jargon associated with typical run time faults.
In order to evaluate a system, the input file requires the definition of the geometry and specified the materials within the system. The geometric and material distribution information is
described by a universe. In Gemma a universe may be defined through various avenues, as is
described in the rest of the section.
3.2.1
Cell
The basic building block of universes is a cell. A cell may consist of surfaces and materials or
be filled with other universes. Additionally, cells may be built progressively for creating systems
such as a pin-cell, see Figure 3.3. This type of system may be modeled using the cell input card
in three steps: i) define the material within surface 1, ii) define the material inside surface 2 and
outside surface 1, and finally iii) by defining the material inside surface 3 and outside surface 2.
The input file cards for the Gemma code as well as a few examples are provided in Appendix A.
Page 27
IPN-ESFM
3.2. CSG Implementation
Figure 3.4: 2⇥2 lattice array.
The use of cells is an intuitive approach to model nested structures such as the aforementioned
pin-cell. With this approach the input file provides a high level abstraction for the cell input card,
while internally the input file parser handles the low level operation associated with creating a
data tree of the universe’s surface map. This mapping technique is used in all aspects of the
Gemma code relation to region creation, track generation and track segmentation. An example
of the mapping technique as well as further discussion is provided in Subsection 3.2.4.
3.2.2
Lattice
Within nuclear reactor systems, rectangular and hexagonal array structures filled with pin-cells
are the commonly found. Modeling these repeating structures is alleviated through the use of
lattices, commonly found in neutron transport codes such as MCNP and Serpent.
Although it is possible to model lattice arrays with the cell input card, such a task would be
tedious. The lattice input card is a macrocell structure consisting of pins. In Gemma, the pin
input card is used to populate a lattice. The pin input card provides an easier tool for defining
a pin-cell, in which the inner elements are circle surfaces, instead of defining multiple surfaces
only the inner pin radii are specified. Finally, for the lattice input card the number of rows and
columns, pin-cell pitch, and pin distribution are defined in order to create a lattice structure.
Figure 3.4 presents a 2⇥2 lattice array.
The lattice input card is not limited to pin elements. Another level of repeating structures, especially for defining reactor cores, is a lattice array of lattice structures. Gemma is also capable of
creating arrays of lattices, examples of a macro-lattice may be found in Appendix A.
Using the lattice input card is another form to create a universe to specify the desired system to
be evaluated. Being a universe, the mapping technique is possible.
Guillermo Ibarra-Reyes
Page 28
Chapter 3. Geometric Modeling
3
1
2
4
8
56
12
16
1
7
2
20
24
28
31
3
35
50
38
54
42
58
46
...
50
54
58 62
17
51
55
59
63
14
18
52 56
60
64
15
19
53 57
61
65
4
8
12
16
5
9
13
6
10
7
11
62
(a) Physical representation with surface ids.
(b) Surface map structure.
Figure 3.5: 4x4 fuel lattice assembly.
3.2.3
Assembly
A better representation of a lattice, such as the one shown in Figure 3.4, is the inclusion of the
channel. Physically a channel provides an enclosure for the fuel elements. Gemma provides
an effortless mechanism for adding additional surfaces to lattice universes. An example of a
assembly channel representation is given in Figure 3.5a. Gemma is also capable of creating
array of lattices, see Appendix A for greater detail.
3.2.4
Universe Surface Map Structure
Whenever a universe is defined, regardless of the card (cell, lattice, or assembly), a tree style
structure mapping the surface distribution is generated. Figure 3.5b presents the map generated
for a fuel lattice assembly. This data structure is the key component in the region creation process and track segmentation, as will be explained in the rest of the chapter.
It is worth noting that internally the lattice structure is counted as a surface. Although slightly
inconspicuous, this step permits the branching of the inner pin cells. This distinction allows
the map structure from Figure 3.5 to be understood as the following. Within surface 2 (cladding
material of the channel) is the lattice pin structure (surface 3), which contains the pin-cell square
surfaces (4, 8, 12, 16, etc.). Finally each pin-cell square surface is composed of pins or circle
surfaces.
The value of the tree map structure is evident when tracing the trajectory of a track in the system
defined by Figure 3.5. Given a track’s starting point (x0 , y0 ) and azimuthal angle/slope mj , all
possible intersections between the contents of the surface 1 are performed. If the track intersects
surface 2, the entry and exit points are added to a data structure for the track and now the contents
of surface 2 are evaluated. This process continues if an intersection with the contents exists.
Page 29
IPN-ESFM
3.3. Region Creation
(a) Surface discretization
(b) Pin-cell discretization
(c) Interface discretization
Figure 3.6: Discretization techniques in Gemma.
3.3
Region Creation
A principle approximation in the method of characteristics is that the scalar flux inside a region
is constant. In order to reduce the error associated with this approximation, a greater discretization of the geometric space is required. Gemma provides fine grain control over the creation of
regions.
Regions are created from the discretization of a surface. Within Gemma three discretization
options are available: i) surface (Figure 3.6a), ii) pin-cell (Figure 3.6b), and iii) the interface between surfaces (Figure 3.6c). In the case of surface and interface discretization, a desired region
area is defined. Gemma will then discretize the surface, while considering the aspect ratio of the
resulting region dimensions.
For the pin-cell discretization three parameters are defined: (1) cell division parameter n, where
the cell is divided into 2n sectors; (2) number of inner divisions nin , considers pin with the smallest radius and creates nin circles or rings with a smaller radius; (3) number of outer divisions
nout , adds nout rings after the pin with the largest radius.
3.4
Track Generation
The spatial domain is discretized through the use of tracks, which aim to trace the flight of a
neutron within the system. The neutron direction ~Wm is a function of an azimuthal angle j and a
polar angle q , see Figure 3.7. The following section presents the track generation methodology
using j and q , and their corresponding weights wm and w p , respectively.
3.4.1
Global Cyclic Tracking
Tracks may run along a certain region or the entire system. Gemma uses the latter tracing
scheme, also known as global tracking. Covering the domain requires azimuthal angles between
0  j  2p; however, neutrons that travel at angles between 0  j  p are identical to those
traveling between p  j  2p. Therefore it is only necessary to model the azimuthal angles
Guillermo Ibarra-Reyes
Page 30
Chapter 3. Geometric Modeling
z
^
Ω
m
θm
y
φm
x
Figure 3.7: Neutron flight direction representation.
between 0  j  p and account for the balance by doubling the respective azimuthal weight
wm . The same principle may be applied to the polar angle domain, thus only needing to model
angles between 0  q  p/2 and doubling the polar angle weight q p .
Another technique in track generation is the use of cyclic tracking. Cyclic tracks or a perfect
reflection provides a straightforward mechanism for treating boundary conditions. With this
approach a set of complementary angles are formed, such that tracks wrap around the system
geometry as closed cycles.
The formation of complementary angle set requires adjusting the starting angles according to
the system’s geometric dimensions, height h and width w, a number of azimuthal angles M and
a desired distance between the tracks dm . The unadjusted angles jm for index m 2 {0, 1, . . . , M
1} are given by:
2p
jm =
(m + 0.5) .
(3.3)
M
Considering the initial angles, the number of tracks along the bottom nx and left ny boundaries
are evaluated using the ceiling functions:
⇠
⇡
w
nx =
|sin jm |
(3.4)
dm
⇠
⇡
h
ny =
|cos jm |
(3.5)
dm
nt = nx + ny .
(3.6)
Thus, the adjusted azimuthal angle is defined as:
jm0
✓
hnx
= arctan
wny
with an adjusted distance between tracks:
dm0 =
w
sin jm0 .
nx
◆
(3.7)
(3.8)
For simplicity’s sake, the adjusted distance between tracks will hereafter be expressed as dm .
Page 31
IPN-ESFM
3.5. Track Segmentation
φ2
ω1
φ1
φ0
ω0
2π
ωM-1
φM-1
Figure 3.8: Azimuthal weight illustration.
3.4.2
Quadrature Set
A key component in the quadrature set is the weight associated with each angle. Weights represent the amount space taken up by the angle. A physical representation of the azimuthal weight
is given in Figure 3.8.
The adjusted azimuthal angles jm0 , henceforth stated as jm , has been previously defined. Whereas
the azimuthal weights are defined as:
8 
1 jm+1 jm
>
>
+ jm
if m = 0,
>
>
>
2p
2
>
>
< 1 j
jm jm 1
m+1 jm
wm =
+
if 0 < m < M 1,
(3.9)
>
2p
2
2
>
>

>
>
1
jm jm 1
>
>
2p jm +
if m = M 1.
:
2p
2
For modeling polar motion, the Legendre quadrature set is selected. Polar angles as well as
weights for various values are summarized in Table 3.1.
3.5
Track Segmentation
For the track segmentation, the tracks are first traced along the system geometry. Then the track
segmentation is carried out in two steps, starting with the intersection points for every surface
and finally the intersection points are evaluated for every region within each aforementioned surface. This two step segmentation relies heavily on the tree map structure previously generated.
A clear advantage of this approach is a reduced subset of items to sweep or calculate in order
to find an intersection. By performing the segmentation on the map structure, this methodology provides a robust mechanism for treating a wide spectrum of geometries. Due to Gemma’s
Guillermo Ibarra-Reyes
Page 32
Chapter 3. Geometric Modeling
Table 3.1: Legendre polar angle quadrature set.
N
j
2
4
1
1
2
1
2
3
1
2
3
4
6
8
±µ j
0.5773502691
0.3399810435
0.8611363115
0.2386191860
0.6612093864
0.9324695142
0.1834346424
0.5255324099
0.7966664774
0.9602898564
wj
PN (µ j )
j
1.0000000000
0.6521451549
0.3478548451
0.4679139346
0.3607615730
0.1713244924
0.3626837834
0.3137066459
0.2223810344
0.1012285363
10
1 0.1488743387 0.2955242247
2 0.4333953941 0.2692667193
3 0.6794095682 0.2190863625
4 0.8650633666 0.1494513492
5 0.9739065285 0.0666713443
1 0.1252334085 0.2491470458
2 0.3678314989 0.2334925365
3 0.5873179542 0.2031674267
4 0.7699026741 0.1600783286
5 0.9041172563 0.1069393260
6 0.9815606342 0.0471753364
12
±µ j
wj
ability to describe a system as a cell or a combination of surfaces and by extension lattices and
assemblies.
3.5.1
Ray Tracing
Ray tracing involves getting the start (x0 , y0 )and end (x1 , y1 ) points for all tracks for a given angle
of motion jm with a separation of dm . Obtaining the track starting points is straightforward.
Azimuthal angles less than p/2 are initiated along the left boundary while their complimentary
counterparts (greater than p/2) are drawn along the right boundary. All angles are then traced
along the bottom system boundary. The separations along each axis are defined as:
dm
,
|sin jm |
dm
Dy =
.
|cos jm |
Dx =
(3.10)
(3.11)
Finally the starting points are slightly modified to prevent tracks originating in a corner, see
Figure 3.9.
Each end point (x1 , y1 ) is a function of a starting point (x0 , y0 ), the system height h and width
w. The track’s end point includes one of two boundaries depending on a threshold value, see
Figure 3.10. For example, tracks originating on the left boundary will go to the top if x0 > xlim
otherwise it will end up on the right boundary. The limits are defined as:
✓
xlim = min w,
◆
h
,
tan jm
ylim = min (h, w tan jm ) .
(3.12)
(3.13)
The left corner point of the system (xbot , ybot ) and the top right corner (xtop , ytop ) are reference
points when calculating the start and end points of the tracks. Also the complementary azimuthal
Page 33
IPN-ESFM
3.5. Track Segmentation
y
dm
∆ym
Δym/2
φm
Δxm/2
x
∆xm
Figure 3.9: Ray tracing starting points.
(xtop, ytop)
w
ylim
αm
h
φm
(xbot, ybot)
xlim
Figure 3.10: Ray tracing threshold limits for evaluating end points.
Guillermo Ibarra-Reyes
Page 34
Chapter 3. Geometric Modeling
angle is defined as:
am =
p
2
jm
(3.14)
Tracks with angles less than p/2
For tracks with jm < p/2, ny tracks are drawn along the right boundary and nx along the bottom.
When tracing tracks on the left boundary the x coordinate remains fixed while the y coordinate is
varied by a value of Dx with the first track having point at (xbot , ybot +Dy/2). If y0 < (ytop ylim ),
the end point is located on the right boundary thus:
x1 = xtop ,
y1 = y + tan jm ,
(3.15)
(3.16)
otherwise the track extends to the top boundary where:
x1 = xbot + (ytop
y1 = ytop .
y) tan am ,
(3.17)
(3.18)
Tracks originating on the bottom boundary have an initial value of (xbot + Dx/2, ybot ). The
y coordinate remains constant while the x value is modified by Dx after each track initiation.
These tracks extend to the top boundary when x < (xtop xlim ) with an end point:
h
,
tan jm
y1 = ytop ,
x1 = x +
(3.19)
(3.20)
else the track goes to the right boundary:
x1 = xtop ,
y1 = y + (xtop
x) tan jx .
(3.21)
(3.22)
Complementary angle tracks
Within the Gemma code the complementary angles (jm > p/2) are traced along the right and
bottom boundaries in the opposite direction as the other angles. For example along the y axis
from top to bottom and on the bottom boundary from right to left. Such that when tracing along
the right boundary the first track has the start point of (xtop , ytop Dy/2). As more tracks are
created the y value is decreased by Dy. If y < (ytop ylim ), the track goes to the left boundary
with the coordinates:
x1 = xbot ,
y1 = y + w tan jm ,
(3.23)
(3.24)
else the track ends at the top boundary at the point.
x1 = xtop (ytop
y1 = ytop .
Page 35
y) tan am ,
(3.25)
(3.26)
IPN-ESFM
3.5. Track Segmentation
Finally the tracks along the bottom boundary initiate at (xtop Dx/2, ybot ), with each successive
track shifts to the left by Dx. The track will go to the left boundary while x < (xbot + xlim ) with
an end point at:
x1 = xbot ,
y1 = ybot + (x
xbot ) tan jm ,
(3.27)
(3.28)
else the end point is located at the top boundary:
h
,
tan jm
y1 = ytop .
x1 = x
3.5.2
(3.29)
(3.30)
Surface Intersections
Once the tracks are generated, Gemma proceeds to find the intersection points of the surfaces
along the track trajectory. The surface segmentation function performs a sweep of the surface
map structure. Given a track’s start position (x0 , y0 ) and slope m, the intersections are evaluated
and an array structure is generated containing the surface id and its intersection value xs , in lieu
of the point.
When generating the surface map structure, each surface is also assigned a sweep type which
assists the surface segmentation process and includes surface, pin, and lattice types. Sweep type
assignment is dependent on how the system was defined. For example within a cell representation all surfaces are surface sweeps, while the lattice representation defines the outer surface as
a surface sweep and its contents as pin sweeps. The assembly system definition is a combination
of a cell and lattice structure.
The map structure sweep is carried out on a level by level, where each level consists of a list
of surface ids. When starting, the current level is {1} and the upper level is 0. The sweep of
the current level consists of three steps: (1) to find the probable intersection of all surfaces in
the current level, if an intersection exists the surface id is added to a queue and the intersection
value xs are added to a temporary data structure or unsorted surface list; (2) the unsorted surface
list is converted to the standard surface intersection format; (3) the surfaces in queue are processed according to their sweep type. According to the surface sweep types in the third step, the
surfaces in queue with the type surface or lattice are added to the next level list while pin sweep
types are added. After each sweep the upper becomes the current level and the new current level
list is the next level. The algorithm is presented in Algorithm 4.
There are multiple subtleties in the surface intersections routine. The surface intersection list
consists of surface segments, the surface id and intersection xs . For example the pin cell system
illustrated in Figure 3.11 contains 5 surface segments, such that the surface intersection list is
defined as [(1, x0 ), (2, x1 ), (3, x2 ), (2, x3 ), (1, x4 ), (0, x5 )]. Surface 0 represents the ether or the
end of the system. This value is a token for subsequent segmentation steps.
Guillermo Ibarra-Reyes
Page 36
Chapter 3. Geometric Modeling
Algorithm 4 Surface intersection algorithm
current = [1]
upper = 0
surfSeg = []
while current do
nextLevel = []
unsortedSeg = []
queue = []
foreach surf 2 current do
if line intersects surf then
unsortedSeg ⇠= (surfId, xin , xout )
queue ⇠= surfId
end if
end for
surfSeg ⇠= process(unsortedSeg)
foreach surf 2 queue do
switch surfType do
case "surface", "lattice":
nextLevel ⇠= getMap(surf)
case "pin":
pins = getMap(surf)
foreach pin 2 pins do
if line intersects pin then
surfSeg ⇠= (pinId, xin )
surfSeg ⇠= (upper, xout )
upper = pinId
end if
end for
end for
upper = current[0]
current = nextLevel
end while
Page 37
IPN-ESFM
3.5. Track Segmentation
1
2
3
1 2
3
x0 x1 x2
2
x3 x4
1
x5
Figure 3.11: Surface intersection scheme.
The use of the upper surface is another key point in the surface intersection routine. Considering the system described in Figure 3.11, when performing the algorithm steps the following is
obtained.
• Sweep 1: current = [1], upper = 0
1. intersects surface 1 at x0 and x5
2. when considering the upper surface, the segments (1, x0 ) and (0, x5 ) are added to the
surface intersection list
3. the contents of the current level or surface 2 is added to queue and consequently to
the next level
• Sweep 2: current = [2], upper = 1
1. intersects surface 2 at x1 and x4
2. when considering the upper surface, the segments (2, x1 ) and (1, x4 ) are added to the
surface intersection list
3. the contents of the current level or surface 3 is added to queue and consequently to
the next level
• Sweep 3: current = [3], upper = 2
1. intersects surface 3 at x2 and x3
2. when considering the upper surface, the segments (3, x2 ) and (2, x3 ) are added to the
surface intersection list
3. there are no contents within the current level
This routine may be extended for systems of greater complexity. Given the map structure approach, the methodology scales linearly with the number of tracks within a system.
Guillermo Ibarra-Reyes
Page 38
Chapter 3. Geometric Modeling
2 3
9 10
17 18
1
2
3
1 16 24
8 15 23
19 11 4
20 12 5
22 21
14 13
7 6
8 15
1 2
23
24 17
3
18
19 11
2
4
1
Figure 3.12: Region intersection representation.
3.6
Region Segmentation
Once the surface segments are created for every track, the next step is to consider the regions
within each surface. Internally Gemma keeps the region distribution for every surface, this form
of bookkeeping assists in the region segmentation. The region segmentation process involves
analyzing every surface segment along the track, calculating the intersection points of the regions within the current surface between the respective entry and exit x position. The general
process is provided in Algorithm 5. The segmentation functions that depend on the refine type
are explained in the rest of the section.
As mentioned previously, the region refinement scheme is dependent of the system. In the case
of refining a surface or interface region, repeating rectangles with equal dimensions are created.
In the case of refining pin type cells, additional circle surfaces are created with varying radii.
When refining a surface, its refinement type is logged and required in the segmentation process
due to the repeating well defined regions created. Both region intersection functions rely on the
surface being examined, the entry position x0 and the exit position x1 .
Algorithm 5 Region segmentation general algorithm.
foreach surf; surfSeg do
x0 = getSur f Entry()
x1 = getSur f Exit()
refineType= getSur f Re f ine()
if refinetype == "surface": then
regionSeg ⇠= macroSegments(surf, x0 , x1 )
else if refinetype == "pin": then
regionSeg ⇠= pinSegments(surf, x0 , x1 )
end if
end for
Page 39
IPN-ESFM
3.6. Region Segmentation
When considering surfaces with a surface refine type, regions of equal dimensions are created.
Having this distribution of regions, given a starting position (xin , yin ) and slope m will find at
which region the track is in and its exit point (xout , yout ). This process is repeated until the exit
position (xout ) for any region lies outside the surface exit position x1 . When there is a positive
slope, m > 1, the process ends when xout x1 and vice versa.
In the case of the pin type, a different approach is employed. The distribution of regions within
these surfaces is based on the angle of intersection between a line and a circle. Regions may be
described as circular arcs between the angles q0 and q1 . In the case of the system represented in
Figure 3.12, region 19 is defined by the angles (0 , 45 ), while region 23 is between the angles
180 and 225 , and so forth. Applying this concept, an intermediate step is added to the region
segmentation process described previously for a surface refine type.
For the pin segmentation algorithm, the first step involves calculating the angle of intersection
qint created by the circle surface and the track. Given qint and the track’s slope m, the starting
region is found. Next the starting region’s exit point xout is evaluated, resulting in either reaching
the end of the surface (xout = x1 ) or the end of the current region. In the case of having to enter
another region, Gemma will find the next region based of the current region’s arc angles (q0 , q1 )
and the track’s slope m. The process is repeated until the end of the surface is reached. For
the system represented by Figure 3.12, the intersection of surface 3 corresponds to the track
intersecting the regions 23, 24, 17, 18 and 19.
Guillermo Ibarra-Reyes
Page 40
Chapter 4
Developmental Aspects of the Gemma
Code
From a developer’s viewpoint engineering analysis software should be accurate, fast and flexible. Fulfilling such lofty expectations requires having a clear plan of execution and achieving a
balance between the solution method, computer hardware and the software development techniques. Given the rare opportunity to create software from scratch, the choice of selecting a
programming language was crucial. Gemma is written primarily in D with a few sections in
C. This chapter provides some background information on the D programming language, the
design of Gemma, and using the code.
4.1
The Benefits of D
In the realm of programming languages, a major distinction can be made between compiled and
interpreted languages. The execution of a compiled language requires translating the source
code to machine code through the use of a compiler. For interpreted languages, the compiler
step is omitted. In some cases a virtual machine is employed, where interpreted languages are
first compiled to byte code; such that statements in the source code correspond to functions already compiled in machine code, as is the case in Python and Java (also Clojure, Groovy and
Scala). Although this distinction may be too broad in general compiled languages provide a
finer control over the CPU and memory usage thus providing a better efficiency in terms of performance, while interpreted languages afford greater flexibility.
The D programming language is a multi-paradigm systems programming language [17]. D aims
to deliver the flexibility associated with interpreted languages such as Python, while providing
performance comparable to compiled languages such as C++. The first major update to D was
in 2007 with the release of D2 and as of 2012 has been established as the official version. The
official compiler DMD is available under the Boost Software License [39].
There exists other compilers for the D language [40, 41, 42], of particular interest is the LLVM
based compiler LDC [43]. In compiler benchmarking, LDC and DMD were proven to be as
fast as the C++ compilers [44] and LDC was faster than clang++ [45]. It is worth noting that
41
4.2. Design Structure
the D compilers were also faster than its counterparts of the newer generation of programming
languages, Go and Rust, which are all billed as providing memory safe applications. With these
traits, D is a strong candidate for any general purpose applications.
Another factor that influences a new languages traction is ecosystem support. D provides native
support for C code through the application binary interface (ABI) as well as all the C fundamental and derived types. This support represents seamless access to existing C libraries, several
popular bindings current exist [46]. Creation of the library bindings involves creating a D interface file or the translation of the C header file.
4.2
Design Structure
Execution of the Gemma code requires a one time compilation step and all subsequent interactions through command line arguments and an input file. With this approach the end user is
not required to learn any aspects of the D language and the compilation process is automated
through the use of a Makefile. The input file provides an intuitive and flexible tool for specifying
a neutronic system. The anatomy of the Gemma input file is provided in Section 4.3.
Greater flexibility of software design comes from D’s multi-paradigm approach to development.
Gemma adopts the object oriented programming (OOP) developmental approach, where objects
contain data or attributes and a set of procedures or methods. Consider a track object, possible
attributes may include: starting point (x0 , y0 ), ending point (x1 , y1 ), or slope m; whereas methods
may include functions to modify attributes. The aforementioned attributes are described through
struct, a feature that permits defining a new data type through the combination of existing types
such as the fundamental data types or previously defined structs. In D, the class feature is
another feature for defining new types. However in contrast to structs, classes provide the OOP
paradigm:
Encapsulation: Controls access to attributes and methods.
Inheritance: Acquire implementations of another type or class.
Polymorphism: Ability to use a specialized type instead of a general type. A class that inherits another class is known as the subclass and the class that gets inherited is called
the superclass. Polymorphism permits using objects of a subclass when a superclass is
required.
The basic building blocks of programs in D are modules or individual source files. Contents of
a module may then be called throughout the program through the use of the import keyword. A
summary of the modules used in Gemma is presented in Table 4.1.
When designing large projects, care must be taken to account for multiple developers. Thats to
say that rarely will a project have a lone developer. Thus it is important to provide an productive developmental environment or programming best practices. Common approaches include
providing documentation, following a naming convention, version control and software testing.
Guillermo Ibarra-Reyes
Page 42
Chapter 4. Developmental Aspects of the Gemma Code
Table 4.1: Summary of Gemma modules
Module
Class
Description
cell.d
expEvaluate.d
geometry.d
quadrature.d
reader.d
report.d
shapes.d
solver.d
track.d
trackGenerator.d
Cell
ExpEvaluate
Map
Quadrature
InputFile
OutputFIle
Solver
Track
TrackGenerator
Cell definition
Exponential function evaluation table
Surface map structure
System quadrature information
Input file data and parser
Output file data structure
Geometric intersection library
Neutron transport equation solver routine
Track data structure
Cyclic track distribution
The rest of the section covers some of the software development practices in Gemma.
Another key feature of the Gemma code is the use of contract programming. Contracts are crucial in large projects for maintaining cleaner bug free code. In essence a contract is a condition
that must be true, otherwise the contract fails and the program has a bug. This design approach
provides a formal and precise interface specification for software components. D provides native support for contract programming in the form of assert contracts, pre and post contracts and
invariants.
Software testing practices aid in the debugging process. The ability to quickly identify and fix
bugs is of great importance, especially in the developmental process. Gemma provides testing
on three levels: unit testing, integration testing and regression testing. Unit testing is the most
basic test in where the functionality of a specific section in the code is verified, usually at the
function or class level. Integration testing involves verifying the functionality of a combination
of modules. Finally, regression tests are important when modifying or adding features to an existing software. A simple regression test would be running a case and asserting the same result
is obtained after undergoing changes.
Version control or a source control management (SCM) tool is also vital in the software development process. SCM tools allow developers to track source code changes, merge changes,
fix errors in earlier revisions and rollback in case of mistakes. Gemma uses Mercurial [47] for
SCM due to its intuitive approach, simple yet powerful functionality and decentralized model.
A decentralized model permits operating with a local repository on a computer and a global
repository on a server. This approach is considered a more natural workflow by the Gemma
developers.
Page 43
IPN-ESFM
4.3. Input File Specification
Table 4.2: Gemma input file keywords
Card
Usage
Category
surf
cell
pin
surf <id> <type> <parameters>
cell <universe id> <material> <surf id 1> <surf id 2> ...
pin <pin id>
<material 1> <radius 1>
<material 2> <radius 2>
..
.
geometry
geometry
geometry
lattice
refine
assembly
groups
material
<material n>
lattice <universe> <type> <x0 > <y0 > <rows> <columns> <pitch>
refine <type> <parameters>
assembly <lattice id> <mat 1> <surf id 1> <mat 2> <surf id 2> . . .
groups <G>
material <material>
<St,1 > . . . <St,G >
<nS f ,1 > . . . <nS f ,G >
<c1 > . . . <cG >
<Ss,1!1 > . . . <Ss,1!G >
..
.
<Ss,G!1 > . . . <Ss,G!G >
quadrature quadrature <num azimuthal> <spacing> <num polar>
boundary boundary <side> <condition>
system
system <universe id>
run
run <max iterations>
tolerance
tolerance <convergence criteria>
plot
<type> <plot paramaters>
4.3
geometry
geometry
geometry
neutronic data
neutronic data
simulation
simulation
simulation
simulation
simulation
simulation
Input File Specification
The problem to be solved is specified by a user through a text input file, which is composed of
the geometric system representation, neutronic data for the materials and the simulation parameters. The specification of the aforementioned information is carried out through the use of input
cards, see Table 4.2. Greater details of the input cards utilized by the Gemma code are provided
in Appendix A. Blank spaces are permitted between cards and comments are specified with the
% symbol.
After a stable version of Gemma has been released to end users, compile time errors are nonexistent. However execution of the binary file is not error free. Run time errors will arise from
incorrect definition or use of cards in the input file generated by the end user. In an effort to
provide a better user experience, Gemma adopted a defensive design approach in handling these
errors. Such that clear messages identifying the exact problem detected as opposed to jargon
related to the program function that encountered the error. Gemma covers over 50 errors assoGuillermo Ibarra-Reyes
Page 44
Chapter 4. Developmental Aspects of the Gemma Code
ciated with incorrect use of the cards, for example not specifying a material will produce the
error:
Reading input file..... OK
Checking materials.....
***ERROR*** Need to specify nuetronic data for fuel
Detection of an error results in the program’s termination.
Defining the geometry to be solved in Gemma is done through the creation of a universe. Universes may be defined with the cards cell, lattice, and assembly. The available cards in the
geometry section provide a flexible approach in the construction of a universe. Multiple universes may be defined; however the universe to be solved is specified by the system card.
The multigroup neutronic parameters are required for every material specified. These values
include the total cross section St , nu (average number of neutrons produced per fission) times
the fission cross section nS f , fission probability c, and the scattering cross section Ss for every
energy group in the order presented in Table 4.2, while the number of energy groups is specified
by the groups card.
Finally the last section includes the category of simulation cards. These include setting the
maximum number of iterations, the convergence criteria, and the quadrature set. The boundary
may be set to either reflective or vacuum for sides: all, top, bottom, left or right. There is no
limit on how many times this card may be used, each time the parser reads this instruction the
value is updated. An example of a simple 4⇥4 BWR lattice is the Listing 4.1.
Listing 4.1: 4⇥4 BWR type Gemma input file
% k = 0.986561
pin 1
fuel1 0.5
clad 0.6
water
pin 2
gad 0 . 5
clad 0.6
water
l a t t i c e 10 1 0 . 0 0 . 0 4 4 1 . 6
1 1 1 1
1 2 1 1
1 1 2 1
1 1 1 1
r e f i n e pin 1 2 2 2
r e f i n e pin 2 2 2 2
Page 45
IPN-ESFM
4.3. Input File Specification
groups 2
material fuel1
0.362022 0.572155
0.0186278 0.344137
1.0 0.0
0.333748 0.000664881
0.0 0.380898
m a t e r i a l gad
0.371785 1.75
0.0179336 0.157929
1.0 0.0
0.338096 0.000692807
0.0 0.383204
material clad
0.274144 0.280890
0.0 0.0
0.0 0.0
0.272377 0.000190838
0.0 0.277230
m a t e r i a l water
0.640711 1.69131
0.0 0.0
0.0 0.0
0.607382 0.0331316
0.0 1.68428
q u a d r a t u r e 12 0 . 1 0 6
boundary a l l
reflective
s y s t e m 10
r u n 1000
t o l e r a n c e 1e 6
Guillermo Ibarra-Reyes
Page 46
Chapter 5
Code Verification
Verification of the Gemma code was carried out through the use of well defined benchmark
problems. An infinite homogenous system with 1, 2 and 3 energy groups is evaluated and its
eigenvalue solution is verified in Section 5.1. Next a 4⇥4 BWR lattice benchmark problem is
modeled and the eigenvalue solution as well as the pin power analysis are given in Section 5.2.
Finally, Section 5.3 describes a heterogeneous PWR quarter core assembly C5G7 problem. In
all cases the solution is performed using serial computation.
5.1
LA-13511 Benchmark
A logical first step in the verification process is the analytical solution of an infinite medium. The
analytical benchmark LA-13511 [48] provides a set of problems in where the eigenvalue may
be solved. This section provides the derivation of the eigenvalue solution for a slab geometry at
various number of energy groups, description of the benchmark problems and the corresponding
eigenvalue results.
When considering a one dimensional slab with azimuthal symmetric scattering, the neutron
transport equation is reduced to:
∂ y (x, E, µ)
µ
+ St (x, E) y (x, E, µ) = 2p
∂x
Z
c(E)
+
2k
dE
0
Z1
1
Z
Ss x, E 0 ! E, µ, µ 0 y x, E 0 , µ 0 dµ 0
n(x, E )S f (x, E )dE
0
0
0
Z1
y x, E 0 , µ 0 dµ 0 (5.1)
1
where µ is the cosine of the angle in relation to a given direction.
5.1.1
One Energy Group with Isotropic Scattering
Under the assumption of isotropic scattering, the scattering cross section may be defined as:
1
Ss (~r, E 0 ! E, ~W0 ! ~W) =
Ss (r, E 0 ! E)
(5.2)
4p
47
5.1. LA-13511 Benchmark
Also assuming a homogenous medium when only considering one energy group, the transport
equation may be expressed as [49]:
∂ y(x, µ)
Ss
µ
+ St y(x, µ) =
∂x
2
Z1
1
nS f
y(x, µ )dµ +
2k
0
0
Z1
y(x, µ 0 )dµ 0
(5.3)
1
The previous expression may be transformed to include the mean free path l instead of the
position x. Such that:
l = St x,
(5.4)
therefore:
∂l
= St ,
∂x
resulting in:
µ ∂ y(l , µ)
St
∂l
✓
∂l
∂x
◆
(5.5)
nS Z1
Ss + k f
+ y(l , µ) =
2St
y(l , µ 0 )dµ 0 ,
(5.6)
1
finally the one speed transport equation for a slab may be reduced to:
∂ y(l , µ)
c
µ
+ y(l , µ) =
∂l
2
where:
Ss +
c=
St
nS f
k
Z1
y(l , µ 0 )dµ 0 ,
(5.7)
1
(5.8)
.
Parameter c represents the average number of secondary neutrons produced per neutron reaction.
5.1.2
Two Energy Groups with Isotropic Scattering
Analogous to the derivation for one energy group, the transport equation for a slab geometry
may be expressed as [50]:
∂ y1 (x, µ)
S11
µ
+ S1 y1 (x, µ) =
dx
2
µ
∂ y2 (x, µ)
S21
+ S2 y2 (x, µ) =
dx
2
Z1
1
Z1
1
S12
y1 (x, µ )dµ +
2
0
0
y1 (x, µ 0 )dµ 0 +
S22
2
Z1
1
Z1
y2 (x, µ 0 )dµ 0
(5.9)
y2 (x, µ 0 )dµ 0
(5.10)
1
where:
Si
Si j
is the total macroscopic cross section for group i
is the total neutron group transfer macroscopic cross section from group j to group i
Guillermo Ibarra-Reyes
Page 48
Chapter 5. Code Verification
The aforementioned total neutron group transfer macroscopic cross sections are defined as:
n1 S f ,1
k
n1 S f ,1
S21 = Ss,1!2 + c2
k
n2 S f ,2
S12 = Ss,2!1 + c1
k
n2 S f ,2
S22 = Ss,2!2 + c2
k
S11 = Ss,1!1 + c1
(5.11)
(5.12)
(5.13)
(5.14)
(5.15)
The two group expression maybe also be expressed with the mean free path notation using the
matrix vector notation:
∂ y(l , µ)
c
µ
+ Sy(l , µ) =
∂l
2
where:
and

y (l , µ)
y= 1
,
y2 (l , µ)

S 0
S=
,
0 1
ci j =
Z1
y(l , µ 0 )dµ 0
(5.16)
1

c
c
c = 11 12 ,
c21 c22
Si j
S2
S=
S1
S2
(5.17)
(5.18)
Derivation of the k• expressions for an infinite medium are presented in greater detail in the
LA-13511 benchmark [48].
5.1.3
Problem Set
From an analytical benchmark LA-13511 set, 18 problems are selected [48]. The problems
contain the identifier:
fissile material - energy groups - scattering order - geometry
Such that the benchmark problem Pua-1-0-IN represents an infinite geometry (IN) with plutonium type a solved for 1 energy group and isotropic scattering P0 . The problems selected for
testing included different materials for 1, 2 and 3 energy groups. A summary of the problems
solved, as well as their respective neutron cross section are provided in Table 5.1.
The problems were modeled as a 5 cm ⇥ 5 cm square geometry with reflective boundary conditions. For an infinite medium, the eigenvalue is independent of the number of tracks or number
of azimuthal angles. Results are presented in Table 5.2. In all cases the obtained eigenvalue is
in excellent agreement with the reported values.
Page 49
IPN-ESFM
5.1. LA-13511 Benchmark
Table 5.1: Cross sections (cm 1 ) of the benchmarks problems for the LA-13511 set.
Sa
nS f
St
Ssg!1
Benchmark problem: Pua-1-0-IN
Pua
1 1.0
0.0816
0.101184
0.264384
0.3264
0.225216
Benchmark problem: Pub-1-0-IN
Pub
1 1.0
0.0816
0.101184
0.231744
0.3264
0.225216
Benchmark problem: Ua-1-0-IN
Ua
1 1.0
0.065280
0.078336
0.176256
0.3264
0.248064
0.078336
0.182594753
0.3264
0.248064
0.078336
0.176733066
0.3264
0.248064
0.078336
0.174898045
0.3264
0.248064
0.081942
0.0928676
0.54628
0.464338
0.079365
0.1730686
0.407407
0.328042
0.0936
0.09984
0.29016
0.2503392
0.2208
0.3360
0.0792
0.0
0.0432
0.23616
0.06192
0.08256
0.167184
0.1728
0.167184
0.3456
0.078240
0.0
0.0720
0.26304
0.000222
0.06385
0.0
0.171799
0.26817
1.27698
0.247516
0.0
0.020432
1.21313
0.002053
0.07642
0.002621
0.12658
0.65696
2.52025
0.62568
0.0
0.029227
2.44383
0.00194
0.053633
0.00209
0.07391
0.88721
2.9727
0.83892
0.000767
0.04635
2.9183
0.00312
0.08654
0.00412
0.14324
0.88655
2.9628
0.83807
0.00116
0.04536
2.8751
0.6167162
0.0692
0.617209
0.11426
0.650917
2.13800
0.0
0.0
0.0342008
2.06880
0.0115248
0.12218
0.0070425
0.2425
0.33588
0.54628
0.31980
0.0
0.0045552
0.42410
0.012
0.100
1.100
0.018
0.150
1.800
0.240
0.975
3.100
0.024
0.000
0.000
0.171
0.600
0.000
Material
g
c
Sf
Benchmark problem: Ub-1-0-IN
Ub
1 1.0
0.065280
Benchmark problem: Uc-1-0-IN
Uc
1 1.0
0.065280
Benchmark problem: Ud-1-0-IN
Ud
1 1.0
0.065280
Benchmark problem: UD2O-1-0-IN
UD2O
1 1.0
0.054628
Benchmark problem: Ue-1-0-IN
Ue
1 1.0
0.06922744
Benchmark problem: Pu-2-0-IN
Pu
1 0.575 0.0936
2 0.425 0.08544
Benchmark problem: U-2-0-IN
U
1 0.575 0.06192
2 0.425 0.06912
Benchmark problem: UAL-2-0-IN
UAL
1 1.0
0.0
2 0.0
0.06070636
Benchmark problem: URRa-2-0-IN
URRa
1 1.0
0.0010484
2 0.0
0.050632
Benchmark problem: URRb-2-0-IN
URRb
1 1.0
0.000836
2 0.0
0.029564
Benchmark problem: URRc-2-0-IN
URRc
1 1.0
0.001648
2 0.0
0.057296
Benchmark problem: URRd-2-0-IN
URRd
1 1.0
0.61475
2 0.0
0.045704
Benchmark problem: UD2O-2-0-IN
UD2O
1 1.0
0.002817
2 0.0
0.097
Benchmark problem: URR-3-0-IN
URR
1 0.96
0.006
2 0.04
0.060
3 0.0
0.900
Guillermo Ibarra-Reyes
Ssg!2
Ssg!3
0.033
0.275
2.00
Page 50
Chapter 5. Code Verification
Table 5.2: LA-13511 k• result analysis.
5.2
Number of
energy groups
Benchmark
Problem
Reference
k•
1
Pua-1-0-IN
2.612903 2.612903
Pub-1-0-IN
2.290323 2.290322
Ua-1-0-IN
2.250000 2.250000
Ub-1-0-IN
2.330917 2.330917
Uc-1-0-IN
2.256083 2.256090
Ud-1-0-IN
2.232667 2.232665
UD2O-1-0-IN 1.133333 1.133333
Ue-1-0-IN
2.1806667 2.180666
0.000
0.043
0.000
0.000
0.310
0.090
0.000
0.046
2
Pu-2-0-IN
2.683767
U-2-0-IN
2.216349
UAL-2-0-IN
2.661745
URRa-2-0-IN 1.631452
URRb-2-0-IN 1.365821
URRc-2-0-IN 1.633380
URRd-2-0-IN 1.034970
UD2O-2-0-IN 1.000221
2.683767
2.216349
2.661744
1.631451
1.365821
1.633379
1.034970
1.000221
0.000
0.000
0.038
0.061
0.000
0.061
0.000
0.000
3
URR-3-0-IN
1.600000
0.000
1.600000
Calculated
k•
Difference
(PCM)
BWR Benchmark
Next a 2D BWR type benchmark problem is considered [51]. This problem consists of a 4 ⇥
4 lattice with reflective boundary conditions. Each fuel pin has a radius of 0.5 cm and encapsulated within a clad with a thickness of 0.1 cm and a pitch of 1.6 cm. The fuel pins consist
of 3 wt. % UO2 or the burnable poison fuel pins contain 3 wt. % UO2 with 3 wt. % Gd2 O3 ;
whereas, the cladding material is Zircaloy-2 and the moderator is light water. An illustration of
the benchmark problem, as well as each pin identifier, is depicted in Figure 5.1.
This benchmark problem was modeled in Gemma using two group cross sections obtained from
the DRAGON code [27], as explained by Yang [52]. In Gemma each pin was modeled as 9
rings divided into 4 sectors, for a total of 576 regions as represented in Figure 5.2. The total
flux convergence criteria was set to 1 ⇥ 10 5 and the scalar flux distribution is presented in
Figure 5.3.
5.2.1
Eigenvalue Convergence
The number of azimuthal angles was varied from 4 to 256 for a track separation of 0.001 cm,
the results of the converged eigenvalue as well as the difference in pcm with respect to the
reference value of k• = 0.986561 are presented in Table 5.3. As can be observed, the eigenvalue
are in excellent agreement with the reference value. It is worth nothing that with 32 azimuthal
Page 51
IPN-ESFM
5.2. BWR Benchmark
1
2
3
4
2
6
5
3
3
5
6
2
4
3
2
1
Figure 5.1: Layout of the BWR benchmark with burnable poison fuel pins.
Figure 5.2: BWR benchmark regions created in Gemma.
Guillermo Ibarra-Reyes
Page 52
Chapter 5. Code Verification
(a) Fast energy group
(b) Thermal energy group
Figure 5.3: BWR benchmark scalar flux distribution map.
Table 5.3: BWR k• result analysis for a track separation of 0.001 cm with k• = 0.986561.
# Azimuthal Angles
ke f f
Difference (pcm)
4
8
16
32
64
128
256
0.995606
0.987099
0.986892
0.986639
0.986602
0.986571
0.986565
916.82
54.53
33.55
7.91
4.16
1.01
0.41
angles and a track separation of 0.001 cm, the difference was less than 8 pcm and with 128 the
difference of the converged eigenvalue is within 1 pcm.
5.2.2
Power Pin Results
The relative pin error for 256 azimuthal angles at a track separation of 0.001 cm is presented in
Table 5.4. These values are normalized to the total power and are similar to the reported values.
5.3
C5G7 Benchmark
The C5G7 benchmark problem [53] with no spatial homogenization is the seven energy group
of the C5 mixed oxide (MOX) fuel assembly as previously specified by Cavarec et al [54]. In
the case of the 2D problem, the overall dimensions of the geometry are 64.26 ⇥ 64.26 cm, consisting of UO2 and MOX fuel lattices surrounded by a moderator see Figure 5.4. The top and
right have a reflective boundary condition and vacuum elsewhere.
Page 53
IPN-ESFM
5.3. C5G7 Benchmark
Table 5.4: BWR power pin analysis
Pin #
DRAGON
Gemma
Difference %
1
2
3
4
5
6
6.9391e-2
6.6246e-2
6.9398e-2
7.2549e-2
6.2429e-2
2.4344e-2
6.9380e-2
6.6257e-2
6.9406e-2
7.2554e-2
6.2395e-2
2.4345e-2
1.441e-2
1.660e-2
1.153e-2
6.890e-3
5.446e-2
4.110e-3
Table 5.5: Converged C5G7 eigenvalues at varying angles for a track separation of 0.01 cm.
Angle #
ke f f
Difference (pcm)
4
8
16
32
64
128
256
1.18550
1.18464
1.18511
1.18638
1.18664
1.18676
1.18676
88.49
160.97
121.36
14.33
7.59
17.70
17.70
Fuel lattices consist of 17 ⇥ 17 pin-cells with a a pitch of 1.26 cm and fuel-clad mixture pins
with a radius of 0.54 cm. The UO2 lattice array contains UO2 fuel while the MOX arrangement
is composed of MOX at concentrations of 4.3%, 7.0%, and 8.7%. Within both fuel bundles,
guide tubes and a fission chamber is also present with the same radius of 0.54 cm.
Within the Gemma code, the C5G7 pin-cells are modeled with 5 rings and 4 division, whereas
the moderator is represented with regions of 0.63 ⇥ 0.6 cm for a total of 33,524 regions. The
scalar flux convergence criteria is set to 1 ⇥ 10 5 and the flux distribution is presented in Figure 5.5.
5.3.1
Eigenvalue Convergence
The resulting converged eigenvalues are presented in Table 5.5 for different azimuthal angles
with a track separation of 0.01 cm and in Table 5.6 for different separations at 64 azimuthal
angles. As well as the difference in PCM with respect to the MCNP5 solution of ke f f = 1.18655
for each table. All results exhibit an excellent agreement with the reference solution.
Guillermo Ibarra-Reyes
Page 54
Chapter 5. Code Verification
Reflective B.C.
R
e
f
l
e
c
t
i
v
e
V
a
c
u
u
m
Vacuum B.C.
UO2
Guide Tube
Fission Chamber
4.3% MOX
7.0% MOX
8.7% MOX
Moderator
Figure 5.4: 2D C5G7 benchmark problem configuration.
Table 5.6: Converged C5G7 eigenvalues at 64 azimuthal angles and varying track separations
Page 55
Separation (cm) #
ke f f
Difference (pcm)
0.5
0.1
0.05
0.01
0.005
0.001
1.186390
1.186647
1.186647
1.186639
1.186648
1.186651
13.48
6.74
6.74
7.59
5.90
3.37
IPN-ESFM
5.3. C5G7 Benchmark
(a) Group 1
(b) Group 2
(c) Group 3
(d) Group 4
(e) Group 5
(f) Group 6
(g) Group 7
Figure 5.5: C5G7 scalar flux distribution map.
Guillermo Ibarra-Reyes
Page 56
Chapter 6
Summary, Conclusions and Outlook
Within the following chapter provides a summary of the thesis in Section 6.1, conclusions of the
results in Section 6.2 and an outlook of future proposed work in Section 6.3.
6.1
Summary
In the realm of nuclear engineering, great emphasis is placed on the accurate solution of the
neutron transport equation, these types of solutions in the past have been prohibitive due to
its computational expense. However with the ever increasing computer processing power, the
aforementioned high fidelity calculations are possible. The increase of computational power has
come in the form of multi-core processors and accelerators such as graphical processing units.
Incorporation of various hardware or heterogeneous computing is not a trivial task, much of the
complexities involved are products of using languages that were devised at a time where parallel
computing was not present. Gemma’s core vision for a next generation code involves the incorporation of accurate solution methods, computer hardware to reduce the computational burden
and providing a flexible platform for its development. Achievement of this lofty goal requires
the use of a programming language that benefits from the experience of legacy languages and
provides greater support for harnessing the computing power available.
Central to the analysis of nuclear systems is the scalar flux distribution, accomplished by the
solution of the neutron transport equation. Chapter 2 provided the method of characteristics formulation and integral form transformation from the steady state eigenvalue transport equation.
Within this formulation energy and angular dependence simplifications were made through the
multigroup and discrete ordinates approximations, respectively. Other key assumptions in the
method of characteristics methodology include a flat source approximation within each region
and the scattering term as well as all sources may be modeled as isotropic. From the principal equations derived for the method of characteristics the solution method was explained in
detail. This included the transport sweep algorithm, the reduced source calculation, and the
convergence criteria. Finally in an effort to speed up the calculation, the exponential function
evaluation technique was presented.
The first steps in the application of the method of characteristics include the track generation,
57
6.2. Conclusions
geometric modeling, and track segmentation routine, as described in Chapter 3. Definition of the
geometric space is carried out through the constructive solid geometry (CSG). For 2D systems
this approach consists of creating cells commonly known as universes, which are the combination of surfaces and materials. An extension of this methodology includes the creation of macros
for repeating surfaces such as pin-cells and lattice arrays. Theses cells generate a surface map
structure, which is then used for the discretization of each surface into the flat source regions
according to the user defined parameters. Tracks were then created using the global cycling
tracking approach as described in Section 3.4. Finally with the track information and the surface
map structure, the segmentation is performed in two steps; first by creating the surface segments
followed by the region segmentation, the algorithms for this approach were provided in Section
3.5.
Chapter 4 describes the development strategy of the Gemma code. The benefits for writing the
code in D were presented as well as the main program layout. Being a multi-paradigm different
programming strategies were applied, depending on the need. However for the most an object
oriented approach was taken with bits of code written in the functional style. Code flexibility
was incorporated for future developers and end users. End users benefit from a friendly text file
system to define the system geometry, materials information and calculation parameters through
input cards. Whereas on the developer side, D seamlessly allows the use of special code blocks
for debugging and testing purposes, which are triggered with compiler flags. This approach permits delivering a production ready code, while providing all the resources required for further
development. Special care was also taken to fully document the code and keep track of all modifications through the use of Mercurial source code management software.
Finally the Gemma code solved a series of benchmark problems in order to evaluate the converged eigenvalue as well as the pin power distribution for a different number of azimuthal
angles and characteristic spacing. A few of the LA-13511 infinite media problems for 1, 2 and
3 groups were evaluated. The problem’s analytical solution was presented alongside the difference between the converged eigenvalue and the reference solution, in every case there was an
excellent agreement between the calculated and reference solutions, the few differences were
attributed to round off errors. Regarding the BWR benchmark, the converged eigenvalue was
within 0.40 PCM when compared to the DRAGON solution. Finally Gemma solved the C5G7
problem with seven energy groups with 64 azimuthal angles, the converged eigenvalue solution
exhibited great agreement in comparison to the Monte Carlo solution.
6.2
Conclusions
The thesis focused on the development of a MOC neutron transport solver for 2D steady state
eigenvalue calculations. Aside from providing accurate solution, Gemma aims to provide a flexible code with the potential to incorporate multi-core hardware. With regards to flexibility, it is
addressed on two fronts for end users and future developers. Interaction with the Gemma code
is carried out through the use of a user generated text input file. This approach carries multiple
advantages to end users, including avoiding the need to learn aspects of a programming language
and a friendly interface with clearer error detection as opposed to run time errors associated with
Guillermo Ibarra-Reyes
Page 58
Chapter 6. Summary, Conclusions and Outlook
a compiled language.
In the first phase, the contents of this thesis, the Gemma code provided converged eigenvalue
solutions with an excellent agreement with their respective reference solutions. However this
accuracy comes at a price in the form of computational resources and time. Therefore the next
developmental phase of the Gemma code will be centered around performance. For this reason,
heavy importance was placed on writing Gemma in the D programming language. Being a compiled systems programming language in the C-style the aforementioned approach is possible.
Plans for the future of the Gemma code discussed in the next section.
6.3
Proposed Developments
This thesis work was carried out in the hopes of creating a neutron transport solver that would
form the centerpiece of a lattice code. A lattice code is capable of solving nuclear reactor physics
problems without the need for precomputed macroscopic cross sections. The leap from the current version of the Gemma code to a lattice code implies reading from nuclear data files, such as
the ENDF library, and performing the necessary homogenization and condensation scheme to
transform continuous microscopic cross sections for specific isotopes to few group macroscopic
cross sections for a specific area of the nuclear system under study.
At the center of the proposed vision for the Gemma lattice code still lies a neutron transport
solver. Ideally this solver would need to solve 3D systems, for which the computational burden
will be even more demanding. Therefore the Gemma code will need to be fine tuned to incorporate multiprocessing with the aid of multi-core processors and graphical processing units. An
inherent disadvantage of the method of characteristics is its slow convergence, this may be alleviated though the use of an acceleration scheme such as coarse mesh finite difference (CMFD).
Another key step towards a 3D solver will be extension of the ray tracing technique. A natural approach would be to use the same strategy as proposed in this work for a 2D geometry.
However, in Gemma the tracks as well as the segmentation are calculated and stored in memory,
thus placing more demand on storage and look up processes. Another approach is the on the fly
calculation seem in Monte Carlo codes, which would eliminate the memory storage of tracking
data but increase the computational burden.
An intuitive approach to ray tracing involves considering the highly repetitive structures. For
example in a light water reactor, identical pin-cells share the same segment lengths. With this
consideration, only the unique segments will be stored as opposed to all segments for every
characteristic. This modular ray tracing method is a must for 3D systems, but can also be
incorporated in 2D to reduce the computational and storage requirements.
Page 59
IPN-ESFM
6.3. Proposed Developments
Guillermo Ibarra-Reyes
Page 60
Appendix A
Gemma Input Cards
The neutron problem is defined by the user through a text file. This text file must contain the
material distribution through the system (geometry definition), the neutronic data of all specified
materials, and simulation parameters required by the method of characteristics. This appendix
outlines the definition process as well as the available options. Gemma uses the units outlined in
A.1 when specifying various parameters. Comments may be added freely throughout the input
file, Gemma will ignore everything after the % symbol. There are no restrictions on white space
within an input card or between them.
A.1
Geometry Specification
The geometry of the system may be specified through the use of surfaces and cells, á la constructive solid geometry, or through the use of macros for highly repetitive structures. The following
section presents the input cards associated with this specification.
surface definition
The surface card is defined as:
surf <id> <type> <parameters>
where
<id>
is the surface identifier, read as a string
<type>
is the surface type
<parameters> are the parameters required for the surface type.
The surface types and their respective parameters are summarized in A.2. Whereas a visual
representation of the surfaces are provided in A.1.
A few examples of the surf card usage are given as such.
% — square centered at the origin with sides of 2 cm —
surf 1 sqr 0.0 0.0 2.0
% — circle with a center at (5.0, 2.0) and a radius of 1.2 cm —
surf 1 cyl 5.0 2.0 1.2
61
A.1. Geometry Specification
Table A.1: Units used in the Gemma code
Quantity
Unit
Distance
cm
Area
cm2
Energy
MeV
Cross Section
cm 1
Neutron scalar flux 1/cm2
Table A.2: Surface types for the Gemma code
Type
Description
Parameters
sqr
rect
cyl
square
rectangle
circle
x0 , y0 , s
x0 , y0 , s1 , s2
x0 , y0 , r
r
s
x0, y0
x0, y0
cyl
sqr
s1
s2
x0, y0
rect
Figure A.1: Surface types with their respective parameters.
Guillermo Ibarra-Reyes
Page 62
Appendix A. Gemma Input Cards
cell definition
The system geometry is contained within universes. In the Gemma code, universes are created
and modified through the use of the input cards cell, lattice, and assembly. The cell input card
is the basic mechanism for defining universes while the others are extensions of the principle.
Each cell consists of the positive or negative side of a predefined surface and its material.
The cell input card is defined as:
cell <universe id> <material> <surf id 1> <surf id 2> . . .
where <universe id>
is the universe identifier, read as a string
<material>
is the cell material
<surf id 1> <surf id 2> . . . are the cell boundaries.
When using the cell input card if the universe id has not been previously specified a new universe
is created, otherwise more cells are added to the current universe. Consider the definition of a
pin-cell in the following example:
% — pin cell with a pitch of 1.2 cm —
surf 1 sqr 0.0 0.0 1.2
surf 2 cyl 0.0 0.0 0.5
surf 3 cyl 0.0 0.0 0.6
cell 1 fuel
-2
% fuel within surface 2
cell 1 clad -3 2 % clad between surfaces 3 and 2
cell 1 water -1 3 % water between surfaces 1 and 3
pin macro definition
Defining a pin-cell through the use of the cell input card, as seen in the last example, quickly
becomes tedious and repetitive. Luckily through the use of a the pin input card definition of
these structures is straightforward. The syntax is the following:
pin <pin id>
<material 1> <radius 1>
<material 2> <radius 2>
..
.
<material n>
where <pin id>
<material 1> <material 2> . . .
<radius 1> <radius 2> . . .
is the pin identifier
are the materials
are the outer radii of the material rings.
Material regions with their respective radii are defined in ascending order, with the last material
being the filled region. Although this macro doesn’t represent a actually universe, the way a
cell would, it provides a mechanism for representing highly repetitive structures as will be introduced in the next section with the lattice input card.
A pin macro of the pin-cell region mentioned in the previous example may be expressed as:
Page 63
IPN-ESFM
A.1. Geometry Specification
pin 1 fuel 0.5 clad 0.6 water
Notice that there is no center defined and all materials with a radius are understood to be circle
surfaces. Distribution of the pin macros are handled by the lattice input card.
lattice macro definition
The accompanying input card to pin for the creation of repeating structures is the lattice. The
surface macro information is defined though the pin card, whereas the lattice generates the
geometric distribution. The syntax is the following:
lattice <lattice id> <type> <x0 > <y0 > <rows> <columns> <pitch>
where
<lattice id>
<type>
<x0 >
<y0 >
<rows>
<columns>
<pitch>
is the lattice identifier
is the lattice type
is the x coordinate of the lattice origin
is the y coordinate of the lattice origin
is the number of rows
is the number of columns
is the pin pitch.
After the input card definition, the next line is comprised of the pin distribution map. There must
be a line for every specified row with n pins equal to the number of columns. Defining a lattice
creates a universe.
Currently the only available lattice type is a square, type 1. For particularly large lattice systems,
Gemma provides a mega lattice (type 5) or a lattice comprised of various builder lattices (type
0). An example of a square lattice is as follows.
pin 1
fuel1 0.5
clad 0.6
water
pin 2
gad 0.5
clad 0.6
water
lattice 10 1 0.0 0.0 4 4 1.6
1111
1121
1211
1111
Guillermo Ibarra-Reyes
Page 64
Appendix A. Gemma Input Cards
assembly macro definition
Another common nuclear systems structure is a lattice with the channel. Such an arrangement
consists of adding surfaces to a lattice, which is provided by the assembly input card. The syntax
for an assembly is the following:
assembly <asmby id> <lat id> <d1 > <mat 1> [<surf 2> <d2 > <mat 2> . . . ]
where <asmby id> is the assembly identifier
<lat id>
is the lattice universe id previously defined
<d1 >
is the separation of thickness of the first surface
<mat 1>
is the material within the first surface
<surf 2>
is the surface type of an additional surface
<d2 >
is the thickness of the additional surface
<mat 2>
is the material of the additional surface.
This input card adds additional surfaces, where the first surface is deduced from on the lattice
type. Hence only the separation between the first additional surface <d1 > and the surface material <mat 1>. Adding more surfaces requires a set of 3 parameters <surf n>, <dn > and <mat n>.
The assembly input card is another form to define a system universe.
surface refinement
Regions are created through the refine input card. The syntax is the following:
refine <type> [<id>] <parameters>
where <type>
is the refinement type, available: pin, surf, inter
<id>
is the item to be refined, either pin id or surface i;.
when using the inter type, this field is omitted.
<parameters>
are the refinement parameters based on the type
if pin type:
<n>
<inner>
<outer>
<parameters> = <n> <inner> <outer>
is the pin cell division factor, where division = 2n
is the number of inner rings added
is the number of outer rings added
if surf type or inter type:
<area>
<parameters> = <area>
is the desired area of regions.
The refine input card is highly recommended given the assumption within the method of characteristics that all regions exhibit a flat scalar flux. Therefore a greater system discretization, more
regions, diminishes the effect of this approximation. A few examples of the refine card include:
% — refine pin 1 with 8 total regions and 2 inner rings
refine pin 1 3 2 0
% — create regions of 0.5 cm for surface 8
refine surf 8 0.5
Page 65
IPN-ESFM
A.2. Material Description
A.2
Material Description
Being a deterministic neutron transport solver, neutron cross sections are required for every
material specified within the system to be solved. The group macroscopic cross sections are
defined with the groups and material input cards. The number of energy groups are specified
with the groups card, with the syntax:
groups <num groups>
where
<num groups>
is the number of energy groups.
The cross sections for every material is defined in the following manner:
material <material>
<St,1 > . . . <St,G >
<nS f ,1 > . . . <nS f ,G >
<St,1 > . . . <St,G >
<c1 > . . . <cG >
<Ss,1!1 > . . . <Ss,1!G >
..
.
<Ss,G!1 > . . . <Ss,G!G >
where
<material>
<St,1 > . . . <St,G >
<nS f ,1 > . . . <nS f ,G >
<c1 > . . . <cG >
<Ss,1!1 > . . . <Ss,1!G >
..
.
<Ss,G!1 > . . . <Ss,G!G >
A.3
is the previously defined material
are the group-wise St from 1 to G
are the group-wise nS f from 1 to G
are the group-wise c from 1 to G
are the group to group Ss in the order presented.
Calculation Parameters
track generation
The track generation parameters depends on the quadrature, number of azimuthal and polar
angles, as well as the desired separation between the tracks. This information is specified by the
user with the quadrature input card, with the syntax:
quadrature <num azim> <separation> <num polar>
where
<num azim>
<separation>
<num polar>
is the number of azimuthal angles, in multiples of 4
is the desired separation between tracks
is the number of polar angles, Legendre quadrature.
The recommend number of azimuthal angles is powers of 2 while for polar angles 6 is suggested.
Guillermo Ibarra-Reyes
Page 66
Appendix A. Gemma Input Cards
boundary conditions
Gemma can treat the boundaries as vacuum or reflective. Boundary conditions are assigned with
the boundary card and the syntax:
boundary <side> <condition>
where
<side>
<condition>
is the boundary being modified, options include: top, bottom, right, left or all
is the desired condition, options include: vacuum or reflective.
In the current version of Gemma, rectangular geometries are considered. Hence the reason for
assigning the aforementioned geometry sides.
universe selection
Multiple universes may be defined within an input file. However only one solution domain or
universe may be specified. The main universe is defined with the system input card:
system <uni id>
where
<uni id>
is the universe identifier, must be previously specified.
run parameters
Being a deterministic solver, in each iteration or transport sweep the scalar flux for every region
is calculated. This process continues until the aforementioned value converges. The convergence
criteria is defined though the tolerance card:
tolerance <e>
where
<e>
is the convergence criteria.
A value of e = 1 ⇥ 10 6 is suggested for most calculations. A maximum number of iterations
may also be defined with the run card:
run <max>
where
<max>
is the maximum number of iterations or transport sweeps.
This input card is provided in order to prevent an infinite number of loops. In case of the problem
not converging within the number of predetermined number of iterations a warning message is
provided.
Page 67
IPN-ESFM
A.3. Calculation Parameters
Guillermo Ibarra-Reyes
Page 68
Bibliography
[1] A. Gómez-Torres et al., “AZTLAN Platform: Plataforma Mexicana para el Análisis y Diseño de Reactores Nucleares,” in XXV Congreso Anual de la Sociedad Nuclear Mexicana,
2015.
[2] J. Hennart, E. Mund, and E. del Valle, “Third Order Nodal Finite Element Methods with
Transverse and Reduced Integration for Elliptic Problems,” Applied Numerical Mathematics, vol. 46, no. 2, pp. 209–230, 2003.
[3] E. del Valle and E. Mund, “RTk/SN Solutions of the Two-Dimensional Multigroup Transport Equations in Hexagonal Geometry,” Nuclear Science and Engineering, vol. 1, no. 148,
pp. 172–185, 2004.
[4] J. Hennart and E. del Valle, “Nodal Finite Element Approximations for the Neutron Transport Equation,” Mathematics and Computers in Simulation, vol. 80, no. 11, pp. 2168–2176,
2010.
[5] G. Espinosa-Paredes, “Instantaneous equations for multiphase flow in porous media without length-scale restrictions using a non-local averaging volume,” Nuclear Engineering
and Design, vol. 240, pp. 1160–1185, 2010.
[6] G. Espinosa-Paredes, “A derivation of the nonlocal volume-averaged equations for twophase flow transport,” Science and Technology of Nuclear Installations, 2012.
[7] D. Knott and A. Yamamoto, “Lattice physics computations,” in Handbook of Nuclear Engineering (D. Cacuci, ed.), vol. II Reactor Design, pp. 913–1239, Springer Science+Business
Media, 2010.
[8] Studsvik, “Nuclear Design and Reactor Performance.” http://www.studsvik.
com/our-solutions/nuclear-fuel--reactor-performance-optimisation/
software-products/reactor-design-and-performance-optimization/, [Online;
accessed 20-May-2017].
[9] O. R. N. Laboratory, “SCALE code system.” https://www.ornl.gov/scale/overview,
[Online; accessed 20-May-2017].
[10] TOP500, “TOP500 list november 2016.” https://www.top500.org/lists/2016/11/,
[Online; accessed 20-May-2017].
69
Bibliography
[11] J. Dongarra, “Report on the Sunway TaihuLight System.” http://www.netlib.org/
utk/people/JackDongarra/PAPERS/sunway-report-2016.pdf, [Online; accessed
20-May-2017] 2016.
[12] G. E. Moore, “Cramming More Components onto Integrated Circuits.,” Electronics,
vol. 38, no. 8, pp. 114–117, 1965.
[13] I. Corp, “Intel 10k anual report.” http://files.shareholder.com/downloads/INTC/
867590276x0xS50863-16-105/50863/filing.pdf, [Online; accessed 20-May-2017]
2016.
[14] N.
Felix,
“IBM
at
SPIE:
Seven
Advancements
for
Beyond
7nm
Chips.”
https://www.ibm.com/blogs/research/2017/02/
ibm-spie-seven-advancements-beyond-7nm-chips/, [Online;
accessed 20May-2017] 2017.
[15] G. Hagar and G. Wellein, Introduction to High Performance Computing for Scientists and
Engineers. Chapman & Hall, 2011.
[16] OpenMP Architecture Review Board, “OpenMP application programming interface
version 4.5.” http://www.openmp.org/wp-content/uploads/openmp-4.5.pdf, [Online; accessed 20-May-2017] 2015.
[17] D. L. Foundation, “D programming language.” https://dlang.org, [Online; accessed
20-May-2017] 2017.
[18] J. Sanders and E. Kandrot, Cuda by Example: an introduction to general-purpose GPU
programming. Addison-Wesley, 2011.
[19] N. Corporation, “CUDA toolkit.” https://developer.nvidia.com/cuda-toolkit,
[Online; accessed 20-May-2017] 2017.
[20] J. D. Foley, A. van Dam, S. K. Feiner, and J. F. Hughes, Computer Graphics: principles
and practice. Addison-Wesley, 1996.
[21] X.-. M. C. Team, MCNP – A General N-Particle Transport Code, Version 5. Los Alamos
National Laboratory.
[22] J. Leppänen, M. Pusa, T. Viitanen, V. Valtavirta, and T. Kaltiaisenaho, “The Serpent Monte
Carlo code: Status, development and applications in 2013,” Annals of Nuclear Energy,
vol. 82, pp. 142–150, 2015.
[23] E. E. Lewis and W. F. Miller, Computational Methods of Neutron Transport. John Wiley
& Sons, 1984.
[24] A. Yamamoto, T. Endo, M. Tabuchi, N. Sugimura, T. Ushio, M. Mori, M. Tatsumi, and
Y. Ohoka, “AEGIS: an advanced lattice physics code for light water reactor analyses,”
Nuclear Science and Engineering, vol. 42, no. 5, pp. 500–519, 2010.
Guillermo Ibarra-Reyes
Page 70
Bibliography
[25] R. Sanchez, I. Zmijarevi, M. Coste-Delclaux, E. Masiello, S. Santandrea, E. Martinolli,
L. Villate, N. Schwartz, and N. Guler, “APOLLO2 year 2010,” Nuclear Engineering and
Technology, vol. 42, no. 5, pp. 474–499, 2010.
[26] J. Rhodes, K. Smith, and D. Lee, “CASMO-5 development and applications,” Proc. ANS
Topical Meeting on Reactor Physics (PHYSOR-2006), pp. 10–14, 2006.
[27] G. Marleau, A. Hébert, and R. Roy, “A user guide for DRAGON version 4,” Institut
de génie nucléaire, Département de génie mécanique, École Polytechnique de Montréal,
2010.
[28] B. William, S. Shaner, L. Li, B. Forget, and K. Smith, “The OpenMOC method of characteristics neutral particle transport code,” Annals of Nuclear Energy, vol. 68, pp. 43–52,
2014.
[29] R. Sanchez, “Approximate solutions of the two-dimensional integral transport equation by
collision probability methods,” Nuclear Science and Engineering, vol. 64, no. 2, pp. 384–
404, 1977.
[30] B. Carlson, K. Lathrop, et al., Transport theory: the method of discrete ordinates. Los
Alamos Scientific Laboratory of the University of California, 1965.
[31] J. Spanier and E. Gelbard, Monte Carlo principles and neutron transport problems. Courier
Corporation, 2008.
[32] P. Reuss, Neutron Physics. EPD Sciences, 2008.
[33] D. Cacuci, Handbook of Nuclear Engineering: Vol. 1: Nuclear Engineering Fundamentals; Vol. 2: Reactor Design; Vol. 3: Reactor Analysis; Vol. 4: Reactors of Generations
III and IV; Vol. 5: Fuel Cycles, Decommissioning, Waste Disposal and Safeguards, vol. 2.
Springer Science & Business Media, 2010.
[34] A. Hébert, “Multigroup neutron transport and diffusion computations,” in Handbook of Nuclear Engineering (D. Cacuci, ed.), vol. II Reactor Design, pp. 751–911, Springer Science
& Business Media, 2010.
[35] B. Kochunas, A Hybrid Parallel Algorithm for the 3-D Method of Characteristics Solution
of the Boltzmann Transport Equation on High Performance Compute Clusters. PhD thesis,
University of Michigan, 2013.
[36] B. Kochunas, B. Collins, D. Jabaay, T. Downar, and W. Martin, “Overview of development and design of MPACT: Michigan parallel characteristics transport code,” tech. rep.,
American Nuclear Society, 2013.
[37] B. Kochunas, T. Downar, S. Mohamed, and J. Thomas, “Improved parallelization of the
modular ray tracing in the method of characteristics code DeCART,” in Proceedings of the
Joint International Topical Meeting on Mathematics and Computation and Supercomputing in Nuclear Applications (M&C+SNA 2007), 2007.
Page 71
IPN-ESFM
Bibliography
[38] A. Yamamoto, Y. Kitamura, and Y. Yamane, “Computational efficiencies of approximated
exponential functions for transport calculations of the characteristics method,” Annals of
Nuclear Energy, vol. 31, no. 9, pp. 1027–1037, 2004.
[39] W. Bright, “switch backend to Boost License #6680 commit.” https://github.com/
dlang/dmd/pull/6680, [Online; accessed 20-May-2017] 2017.
[40] G. Developers, “GDC D compiler.” https://gdcproject.org, [Online; accessed 20May-2017] 2017.
[41] Microsoft, “D Compiler for .NET.” http://dnet.codeplex.com, [Online; accessed 20May-2017] 2017.
[42] SDC-Developers, “The Stupid D Compiler.” https://github.com/SDC-Developers/
SDC, [Online; accessed 20-May-2017] 2017.
[43] L. Developers, “LDC – the LLVM-based D Compiler.” https://github.com/
ldc-developers/ldc, [Online; accessed 20-May-2017] 2017.
[44] G. U. attractivechaos,
“Programming language benchmarks.” https://
attractivechaos.github.io/plb/, [Online; accessed 20-May-2017] 2013.
[45] “Benchmarks
Round
Two:
Parallel
Go,
Rust,
D,
Scala
and
Nimrod..”
https://togototo.wordpress.com/2013/08/23/
benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/,
[Online;
accessed 20-May-2017] 2013.
[46] “D programming bindings.” https://github.com/D-Programming-Deimos/, [Online;
accessed 20-May-2017] 2017.
[47] “Mercurial SCM.” https://www.mercurial-scm.org, [Online; accessed 20-May2017].
[48] A. Sood, R. A. Forster, and D. K. Parsons, “Analytical benchmark test set for criticality
code verification,” Progress in Nuclear Energy, vol. 42, no. 1, pp. 55–106, 2003.
[49] J. J. Duderstadt and L. J. Hamilton, Nuclear reactor analysis, vol. 84. Wiley New York,
1976.
[50] C. Siewert and J. Thomas Jr, “On two-group critical problems in neutron-transport theory,”
Nuclear Science and Engineering, vol. 94, no. 3, pp. 264–270, 1986.
[51] S. G. Hong and N. Z. Cho, “CRX: a code for rectangular and hexagonal lattices based
on the method of characteristics,” Annals of Nuclear Energy, vol. 25, no. 8, pp. 547–565,
1998.
[52] X. Yang and N. Satvat, “MOCUM: A two-dimensional method of characteristics code
based on constructive solid geometry and unstructured meshing for general geometries,”
Annals of Nuclear Energy, vol. 46, pp. 20–28, 2012.
Guillermo Ibarra-Reyes
Page 72
Bibliography
[53] E. Lewis, M. Smith, N. Tsoulfanidis, G. Palmiotti, T. Taiwo, and R. Blomquist, “Benchmark specification for Deterministic 2-D/3-D MOX fuel assembly transport calculations
without spatial homogenization (C5G7 MOX),” NEA/NSC, 2001.
[54] C. Cavarec, J. Perron, D. Verwaerde, and J. West, “Benchmark calculations of power distribution within assemblies,” tech. rep., Nuclear Energy Agency, 1994.
Page 73
IPN-ESFM
VITA
Guillermo Ibarra Reyes was born on August 25, 1988 in Huetamo, Michoacán, México. Graduated from the Facultad de Ingeniería Química part of the univerdiad Michoacana de San Nicolás
de Hidalgo in June 2014 with a B.S. in Chemical Engineering. During his undergraduate time,
he was a teaching assistant for calculus, chemical engineering thermodynamics and transport operations courses. In the summer of 2014, he started a research internship at the Instituto Nacional
de Investigaciones Nucleares working on neutron cross section generation and benchmarking exercises with deterministic codes. He is also a member of the AZTLAN Platform project, which
aims to develop nuclear reactor analysis using High Performance Computing (HPC) techniques.
This project works towards modernizing, improving and incorporating computational methods
and codes from previous studies into an integrated national platform.