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.