The MCNP®6 Code: A Decade of Progress
Abstract not provided.
Engineering topics
Publications and source records attributed to Kelley, Timothy M..
Abstract not provided.
The SCEPTRE1 code models coupled photon and electron transport in material media using discrete ordinates methods. The code can use different solvers in 1D and 3D in parallel, promising users the ability to run problems that are significant both in physics and computational scale. One capability that is perhaps unique at this time in the NNSA complex is SCEPTRE’s coupled photon– electron transport physics in a discrete ordinates approach. For example, incident x–rays can generate a significant electron population, whose transport can be simulated within the same code. In this context, fully–coupled means that photons can produce electrons and electrons can produce photons; uncoupled or no–coupling means photons do not produce electrons. Partial–coupling, an intermediate option in which photons can produce electrons but electrons do not produce photons, is not considered in the present work. The MCNP code can treat this physics with a Monte Carlo approach. MCNP should be viewed as complementary to SCEPTRE in both computational method (Monte Carlo versus discrete ordinates) as well as data libraries. SCEPTRE and MCNP should provide important checks on each other, especially from complementary modeling frameworks of a S n (discrete ordinates) mesh based method versus Monte Carlo particle based method. In order to learn more about SCEPTRE, and how it might inform engineering work at the Laboratory, we used it to carry out a set of initial studies. This was a series of 1D simulations of photon beams hitting Aluminum slabs. Our studies mainly used SCEPTRE directly, and made little use of the closely associated RAPTURE code (more on this below). The goals of these studies were first, to familiarize ourselves with operating the code, and second, to begin to assess the importance of coupled electron–photon transport. To support these studies, we began to develop a set of scripts to initialize inputs, run tools, process outputs, and plot results. An initial version of these scripts has been committed to the Lightning workflow repository. This memo relates the results of those studies.
This physics manual is intended to document all of the methods used in version 8 of the Jayenne Implicit Monte Carlo solver library. The goal of this manual is to provide a general overview of the basic methods used, and provide a list of references that detail methods that have been implemented in to the Jayenne library.
The ASC Advanced Technology Development and Mitigation (ATDM) sub-program was established in 2014 to develop new simulation tools operating on exascale-class computers to serve NNSA (see Appendix B). Over the course of ATDM, LANL management have set a strategy for exascale-class application codes that follows two supportive and mutually risk-mitigating paths: evolution for established production integrated design codes (IDCs) – with a strong pedigree within the user community – based upon existing programming paradigms(MPI+X); and a new start ATDM project, Ristra, a high-risk/high-reward push for a next-generation multi-physics, multi-scale simulation toolkit based on emerging advanced programming systems(with an initial focus on data-flow task-based models exemplified by Legion). The role of Ristra as the high-risk/high-reward path for LANL’s codes was fully consistent with the goals of ATDM as described in Appendix B, in particular its emphasis on evolving ASC capabilities through novel computing programming models and computing technologies.
Code Analysis and Refactoring with Clang Tools is a small set of example code that demonstrates techniques for applying tools distributed with the open source Clang compiler. Examples include analyzing where variables are used and replacing old data structures with standard structures.
The first step to making more ambitious changes in the EAP code base is to disentangle the code into a set of independent, levelized packages. We define a package as a collection of code, most often across a set of files, that provides a defined set of functionality; a package a) can be built and tested as an entity and b) fits within an overall levelization design. Each package contributes one or more libraries, or an application that uses the other libraries. A package set is levelized if the relationships between packages form a directed, acyclic graph and each package uses only packages at lower levels of the diagram (in Fortran this relationship is often describable by the use relationship between modules). Independent packages permit independent- and therefore parallel|development. The packages form separable units for the purposes of development and testing. This is a proven path for enabling finer-grained changes to a complex code.