Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “serialization”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 1,423 records · Page 79

DARHT Axis II Cathode 16 (S/N 22) History as Recorded in the Historian and Shot Data Databases

Long DARHT II injector cathode operating lifetimes are desirable for flash radiography of hydrodynamic tests at the dual-axis radiographic hydrotest facility (DARHT). The specification for cathode operating lifetime given to Spectra-Mat in the purchase orders for the 311X-M cathodes is ≥ 1000 hours at full operating temperature (~1120 oC). Of the five most-recent cathodes operated on DARHT II, only two have met this specification. It is desirable to have cathodes lifetimes considerably longer than the specified 1000 hours. In this report we present the thermal and vacuum history of cathode 16 (serial no. [S/N] 22), a 311X-M cathode, as recorded in the historian database and the shot data database. The hope is that by examining this history we can identify the parameter (or parameters) that are limiting the DARHT II 311X-M cathode lifetimes. This is the fifth in a series of 5 DARHT Tech Notes in which recent cathode thermal and vacuum histories are examined. The other tech notes in this series are DARHT Tech Notes Nos. 501 (cathode 12, S/N 15), 502 (cathode 13, S/N 19), 503 (cathode 14, S/N 20), and 504 (cathode 15, S/N 21). In DARHT Tech Note No. 506 we will compare the recorded thermal and vacuum histories of cathodes 12-16 and attempt to understand the cathode lifetime limitations based on the stored cathode data presented in DARHT Tech Notes 501-505 and other relevant information.

43 PARTICLE ACCELERATORS↗

Heterogeneous scalable framework for multiphase flows

Two categories of challenges confront the developer of computational spray models: those related to the computation and those related to the physics. Regarding the computation, the trend towards heterogeneous, multi- and many-core platforms will require considerable re-engineering of codes written for the current supercomputing platforms. Regarding the physics, accurate methods for transferring mass, momentum and energy from the dispersed phase onto the carrier fluid grid have so far eluded modelers. Significant challenges also lie at the intersection between these two categories. To be competitive, any physics model must be expressible in a parallel algorithm that performs well on evolving computer platforms. This work created an application based on a software architecture where the physics and software concerns are separated in a way that adds flexibility to both. The develop spray-tracking package includes an application programming interface (API) that abstracts away the platform-dependent parallelization concerns, enabling the scientific programmer to write serial code that the API resolves into parallel processes and threads of execution. The project also developed the infrastructure required to provide similar API s to other application. The API allow object-oriented Fortran applications direct interaction with Trilinos to support memory management of distributed objects in central processing units (CPU) and graphic processing units (GPU) nodes for applications using C++.

71 CLASSICAL AND QUANTUM MECHANICS, GENERAL PHYSIC↗

Design of the beam combination section for stochastic injection

The stochastic injection scenario proposed by D. Neuffer in early 1980’s [1] features the injection and acceptance of pions into the muon storage ring, and is used in the design and simulation of nuSTORM injection and ring [2,3]. The pions decay to muons in the long decay straight section of the ring, then the secondary muons are accepted by the straight FODO structure. The critical design element in this scenario is the Beam Combination Section (BCS), which serially includes a defocusing quadrupole, a bending dipole, and a focusing quadrupole. This paper describes in detail the the design of such a BCS and the matching from this BCS to the downstream side of magnetic horn used to collect the pions after target.

43 PARTICLE ACCELERATORS↗

Meshkit

MeshKit is an open-source library for mesh generation and related algorithms. MeshKit is designed both for users that perform mesh generation and for developers that develop meshing algorithm/application(s). MeshKit includes new meshing algorithms implemented first in this library, as well as interfaces to meshing algorithms/packages developed in DOE Labs and elsewhere. MeshKit uses a directed graph-based approach for organizing meshing problems that supports both traditional BREP-driven meshing as well as more general meshing processes and tools. One such tool is the Reactor Geometry (and mesh) Generator (RGG); RGG generates hexagonal and rectangular reactor geometries and meshes from text-based input in serial and parallel. It has been used to support a variety of reactor simulation codes and reactor types. Although primarily a library, MeshKit is also supporting a collaboration with Kitware to develop a graphical/GUI interface to the library.

Jain, Rajeev↗

LANL SDAV Visualization Update [Slides]

Xeon Phi (MIC) on Stampede: •To demonstrate the portability of our algorithms, the same code was compiled to the Thrust OpenMP backend (including our own OpenMP implementation of scan) and run on a 2563 particle data set on an Intel Xeon Phi SE10P (MIC) Coprocessor on a single node of Stampede at TACC • PISTON version scales to more cores than running the existing serial algorithms with multiple MPI processes. Titan: • This test problem has ~90 million particles per process. • Due to memory constraints on the GPUs, we utilize a hybrid approach, in which the halos are computed on the CPU but the centers on the GPU. • The PISTON MBP center finding algorithm requires much less memory than the halo finding algorithm but provides the large majority of the speed-up, since MBP center finding takes much longer than FOF halo finding with the original CPU code. In-situ Integration in HACC: • Successfully ran 500 time-step, 512 3 particle simulation on Moonlight using our GPU halo and center finders integrated with HACC in-situ • Completed prototype integration with CosmoTools

97 MATHEMATICS AND COMPUTING↗

Development of the Mathematics of Learning Curve Models for Evaluating Small Modular Reactor Economics

The cost of nuclear power is a straightforward yet complicated topic. It is straightforward in that the cost of nuclear power is a function of the cost to build the nuclear power plant, the cost to operate and maintain it, and the cost to provide fuel for it. It is complicated in that some of those costs are not necessarily known, introducing uncertainty into the analysis. For large light water reactor (LWR)-based nuclear power plants, the uncertainty is mainly contained within the cost of construction. The typical costs of operations and maintenance (O&M), as well as fuel, are well known based on the current fleet of LWRs. However, the last currently operating reactor to come online was Watts Bar 1 in May 1996; thus, the expected construction costs for gigawatt (GW)-class reactors in the United States are based on information nearly two decades old. Extrapolating construction, O&M, and fuel costs from GW-class LWRs to LWR-based small modular reactors (SMRs) introduces even more complication. The per-installed-kilowatt construction costs for SMRs are likely to be higher than those for the GW-class reactors based on the property of the economy of scale. Generally speaking, the economy of scale is the tendency for overall costs to increase slower than the overall production capacity. For power plants, this means that doubling the power production capacity would be expected to cost less than twice as much. Applying this property in the opposite direction, halving the power production capacity would be expected to cost more than half as much. This can potentially make the SMRs less competitive in the electricity market against the GW-class reactors, as well as against other power sources such as natural gas and subsidized renewables. One factor that can potentially aid the SMRs in achieving economic competitiveness is an economy of numbers, as opposed to the economy of scale, associated with learning curves. The basic concept of the learning curve is that the more a new process is repeated, the more efficient the process can be made. Assuming that efficiency directly relates to cost means that the more a new process is repeated successfully and efficiently, the less costly the process can be made. This factor ties directly into the factory fabrication and modularization aspect of the SMR paradigm—manufacturing serial, standardized, identical components for use in nuclear power plants can allow the SMR industry to use the learning curves to predict and optimize deployment costs.

small modular reactors (SMRs)↗

LDRD Report: Scheduling Irregular Algorithms

This LDRD project was a campus exec fellowship to fund (in part) Donald Nguyen’s PhD research at UT-Austin. His work has focused on parallel programming models, and scheduling irregular algorithms on shared-memory systems using the Galois framework. Galois provides a simple but powerful way for users and applications to automatically obtain good parallel performance using certain supported data containers. The naïve user can write serial code, while advanced users can optimize performance by advanced features, such as specifying the scheduling policy. Galois was used to parallelize two sparse matrix reordering schemes: RCM and Sloan. Such reordering is important in high-performance computing to obtain better data locality and thus reduce run times.

97 MATHEMATICS AND COMPUTING↗

PETSc Users Manual (Rev. 3.3)

This manual describes the use of PETSc for the numerical solution of partial differential equations and related problems on high-performance computers. The Portable, Extensible Toolkit for Scientific Computation (PETSc) is a suite of data structures and routines that provide the building blocks for the implementation of large-scale application codes on parallel (and serial) computers. PETSc uses the MPI standard for all message-passing communication. PETSc includes an expanding suite of parallel linear, nonlinear equation solvers and time integrators that may be used in application codes written in Fortran, C, C++, Python, and MATLAB (sequential). PETSc provides many of the mechanisms needed within parallel application codes, such as parallel matrix and vector assembly routines. The library is organized hierarchically, enabling users to employ the level of abstraction that is most appropriate for a particular problem. By using techniques of object-oriented programming, PETSc provides enormous flexibility for users. PETSc is a sophisticated set of software tools; as such, for some users it initially has a much steeper learning curve than a simple subroutine library. In particular, for individuals without some computer science background, experience programming in C, C++ or Fortran and experience using a debugger such as gdb or dbx, it may require a significant amount of time to take full advantage of the features that enable efficient software use. However, the power of the PETSc design and the algorithms it incorporates may make the efficient implementation of many application codes simpler than “rolling them” yourself; For many tasks a package such as MATLAB is often the best tool; PETSc is not intended for the classes of problems for which effective MATLAB code can be written. PETSc also has a MATLAB interface, so portions of your code can be written in MATLAB to “try out” the PETSc solvers. The resulting code will not be scalable however because currently MATLAB is inherently not scalable; and PETSc should not be used to attempt to provide a “parallel linear solver” in an otherwise sequential code. Certainly all parts of a previously sequential code need not be parallelized but the matrix generation portion must be parallelized to expect any kind of reasonable performance. Do not expect to generate your matrix sequentially and then “use PETSc” to solve the linear system in parallel. Since PETSc is under continued development, small changes in usage and calling sequences of routines will occur. PETSc is supported; see the web site http://www.mcs.anl.gov/petsc for information on contacting support. A http://www.mcs.anl.gov/petsc/publications may be found a list of publications and web sites that feature work involving PETSc. We welcome any reports of corrections for this document.

97 MATHEMATICS AND COMPUTING↗

PETSc Users Manual (Rev. 3.4)

This manual describes the use of PETSc for the numerical solution of partial differential equations and related problems on high-performance computers. The Portable, Extensible Toolkit for Scientific Computation (PETSc) is a suite of data structures and routines that provide the building blocks for the implementation of large-scale application codes on parallel (and serial) computers. PETSc uses the MPI standard for all message-passing communication. PETSc includes an expanding suite of parallel linear, nonlinear equation solvers and time integrators that may be used in application codes written in Fortran, C, C++, Python, and MATLAB (sequential). PETSc provides many of the mechanisms needed within parallel application codes, such as parallel matrix and vector assembly routines. The library is organized hierarchically, enabling users to employ the level of abstraction that is most appropriate for a particular problem. By using techniques of object-oriented programming, PETSc provides enormous flexibility for users. PETSc is a sophisticated set of software tools; as such, for some users it initially has a much steeper learning curve than a simple subroutine library. In particular, for individuals without some computer science background, experience programming in C, C++ or Fortran and experience using a debugger such as gdb or dbx, it may require a significant amount of time to take full advantage of the features that enable efficient software use. However, the power of the PETSc design and the algorithms it incorporates may make the efficient implementation of many application codes simpler than “rolling them” yourself; For many tasks a package such as MATLAB is often the best tool; PETSc is not intended for the classes of problems for which effective MATLAB code can be written. PETSc also has a MATLAB interface, so portions of your code can be written in MATLAB to “try out” the PETSc solvers. The resulting code will not be scalable however because currently MATLAB is inherently not scalable; and PETSc should not be used to attempt to provide a “parallel linear solver” in an otherwise sequential code. Certainly all parts of a previously sequential code need not be parallelized but the matrix generation portion must be parallelized to expect any kind of reasonable performance. Do not expect to generate your matrix sequentially and then “use PETSc” to solve the linear system in parallel. Since PETSc is under continued development, small changes in usage and calling sequences of routines will occur. PETSc is supported; see the web site http://www.mcs.anl.gov/petsc for information on contacting support. A http://www.mcs.anl.gov/petsc/publications may be found a list of publications and web sites that feature work involving PETSc. We welcome any reports of corrections for this document.

97 MATHEMATICS AND COMPUTING↗

PETSc Users Manual (Rev. 3.5)

This manual describes the use of PETSc for the numerical solution of partial differential equations and related problems on high-performance computers. The Portable, Extensible Toolkit for Scientific Computation (PETSc) is a suite of data structures and routines that provide the building blocks for the implementation of large-scale application codes on parallel (and serial) computers. PETSc uses the MPI standard for all message-passing communication. PETSc includes an expanding suite of parallel linear, nonlinear equation solvers and time integrators that may be used in application codes written in Fortran, C, C++, Python, and MATLAB (sequential). PETSc provides many of the mechanisms needed within parallel application codes, such as parallel matrix and vector assembly routines. The library is organized hierarchically, enabling users to employ the level of abstraction that is most appropriate for a particular problem. By using techniques of object-oriented programming, PETSc provides enormous flexibility for users. PETSc is a sophisticated set of software tools; as such, for some users it initially has a much steeper learning curve than a simple subroutine library. In particular, for individuals without some computer science background, experience programming in C, C++ or Fortran and experience using a debugger such as gdb or dbx, it may require a significant amount of time to take full advantage of the features that enable efficient software use. However, the power of the PETSc design and the algorithms it incorporates may make the efficient implementation of many application codes simpler than “rolling them” yourself. ;For many tasks a package such as MATLAB is often the best tool; PETSc is not intended for the classes of problems for which effective MATLAB code can be written. PETSc also has a MATLAB interface, so portions of your code can be written in MATLAB to “try out” the PETSc solvers. The resulting code will not be scalable however because currently MATLAB is inherently not scalable; and PETSc should not be used to attempt to provide a “parallel linear solver” in an otherwise sequential code. Certainly all parts of a previously sequential code need not be parallelized but the matrix generation portion must be parallelized to expect any kind of reasonable performance. Do not expect to generate your matrix sequentially and then “use PETSc” to solve the linear system in parallel. Since PETSc is under continued development, small changes in usage and calling sequences of routines will occur. PETSc is supported; see the web site http://www.mcs.anl.gov/petsc for information on contacting support. A http://www.mcs.anl.gov/petsc/publications may be found a list of publications and web sites that feature work involving PETSc. We welcome any reports of corrections for this document.

97 MATHEMATICS AND COMPUTING↗

Development of the Mathematics of Learning Curve Models for Evaluating Small Modular Reactor Economics

The cost of nuclear power is a straightforward yet complicated topic. It is straightforward in that the cost of nuclear power is a function of the cost to build the nuclear power plant, the cost to operate and maintain it, and the cost to provide fuel for it. It is complicated in that some of those costs are not necessarily known, introducing uncertainty into the analysis. For large light water reactor (LWR)-based nuclear power plants, the uncertainty is mainly contained within the cost of construction. The typical costs of operations and maintenance (O&M), as well as fuel, are well known based on the current fleet of LWRs. However, the last currently operating reactor to come online was Watts Bar 1 in May 1996; thus, the expected construction costs for gigawatt (GW)-class reactors in the United States are based on information nearly two decades old. Extrapolating construction, O&M, and fuel costs from GW-class LWRs to LWR-based small modular reactors (SMRs) introduces even more complication. The per-installed-kilowatt construction costs for SMRs are likely to be higher than those for the GW-class reactors based on the property of the economy of scale. Generally speaking, the economy of scale is the tendency for overall costs to increase slower than the overall production capacity. For power plants, this means that doubling the power production capacity would be expected to cost less than twice as much. Applying this property in the opposite direction, halving the power production capacity would be expected to cost more than half as much. This can potentially make the SMRs less competitive in the electricity market against the GW-class reactors, as well as against other power sources such as natural gas and subsidized renewables. One factor that can potentially aid the SMRs in achieving economic competitiveness is an economy of numbers, as opposed to the economy of scale, associated with learning curves. The basic concept of the learning curve is that the more a new process is repeated, the more efficient the process can be made. Assuming that efficiency directly relates to cost means that the more a new process is repeated successfully and efficiently, the less costly the process can be made. This factor ties directly into the factory fabrication and modularization aspect of the SMR paradigm—manufacturing serial, standardized, identical components for use in nuclear power plants can allow the SMR industry to use the learning curves to predict and optimize deployment costs. Thus, SMR deployment cost estimates can be modeled using learning curve theory to provide some insight into how and when SMRs would be competitive with both the GW-class reactors and other mutual competitors. However, assuming static learning curve behavior for all aspects of SMR construction is likely an invalid approach—not all components and systems in SMRs will be subject to learning, and those that are subject to learning may not learn at the same rate. A learning curvebased model must be capable of tracking these unique behaviors. At the same time, the behavior of the aggregated and integrated SMR deployment is a more useful metric for discussion and comparison—ultimately, the most useful learning curve information is that which describes power plant deployment as a whole. Therefore, the goal of SMR component and systems learning modeling includes a method to produce an overall power plant learning model. This report describes the mathematics of learning curves that can be used for estimating unit cost in future production for individual components and aggregated systems. All necessary assumptions are provided to support the derivations presented. Future work will demonstrate the implementation of this methodology and provide example calculations of SMR cost

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Efficiency Improvement Opportunities for Personal Computer Monitors. Implications for Market Transformation Programs

Displays account for a significant portion of electricity consumed in personal computer (PC) use, and global PC monitor shipments are expected to continue to increase. We assess the market trends in the energy efficiency of PC monitors that are likely to occur without any additional policy intervention and estimate that display efficiency will likely improve by over 40% by 2015 compared to today’s technology. We evaluate the cost effectiveness of a key technology which further improves efficiency beyond this level by at least 20% and find that its adoption is cost effective. We assess the potential for further improving efficiency taking into account the recent development of universal serial bus (USB) powered liquid crystal display (LCD) monitors and find that the current technology available and deployed in USB powered monitors has the potential to deeply reduce energy consumption by as much as 50%. We provide insights for policies and programs that can be used to accelerate the adoption of efficient technologies to capture global energy saving potential from PC monitors which we estimate to be 9.2 terawatt-hours [TWh] per year in 2015.

29 ENERGY PLANNING, POLICY, AND ECONOMY↗

Documentation for MeshKit - Reactor Geometry (&mesh) Generator

This report gives documentation for using MeshKit’s Reactor Geometry (and mesh) Generator (RGG) GUI and also briefly documents other algorithms and tools available in MeshKit. RGG is a program designed to aid in modeling and meshing of complex/large hexagonal and rectilinear reactor cores. RGG uses Argonne’s SIGMA interfaces, Qt and VTK to produce an intuitive user interface. By integrating a 3D view of the reactor with the meshing tools and combining them into one user interface, RGG streamlines the task of preparing a simulation mesh and enables real-time feedback that reduces accidental scripting mistakes that could waste hours of meshing. RGG interfaces with MeshKit tools to consolidate the meshing process, meaning that going from model to mesh is as easy as a button click. This report is designed to explain RGG v 2.0 interface and provide users with the knowledge and skills to pilot RGG successfully. Brief documentation of MeshKit source code, tools and other algorithms available are also presented for developers to extend and add new algorithms to MeshKit. RGG tools work in serial and parallel and have been used to model complex reactor core models consisting of conical pins, load pads, several thousands of axially varying material properties of instrumentation pins and other interstices meshes.

Jain, Rajeev↗

Development of Low Cost Gas Atomization of Precursor Powders for Simplified ODS Alloy Production

A novel gas atomization reaction synthesis (GARS) method was developed in this project to enable production (at our partner’s facility) a precursor Ni-Cr-Y-Ti powder with a surface oxide and an internal rare earth (RE) containing intermetallic compound (IMC) phase. Consolidation and heat-treatment experiments were performed at Ames Lab to promote the exchange of oxygen from the surface oxide to the RE intermetallic to form nano-metric oxide dispersoids. Alloy selection was aided by an internal oxidation and serial grinding experiments at Ames Lab and found that Hf-containing alloys may form more stable dispersoids than Ti-containing alloy, i.e., the Hf-containing system exhibited five different oxide phases and two different intermetallics compared to the two oxide phases and one intermetallic in the Ti-containing alloys. Since the simpler Ti-containing system was less complex to characterize, and make observations on the effects of processing parameters, the Ti-containing system was selected by Ames Lab for experimental atomization trials at our partner. An internal oxidation model was developed at Ames Lab and used to predict the heat treatment times necessary for dispersoid formation as a function of powder size and temperature. A new high-pressure gas atomization (HPGA) nozzle was developed at Ames Lab with the aim of promoting fine powder production at scales similar to that of the high gas-flow and melt-flow of industrial atomizers. The atomization nozzle was characterized using schlieren imaging and aspiration pressure testing at Ames Lab to determine the optimum melt delivery tip geometry and atomization pressure to promote enhanced secondary atomization mechanisms. Six atomization trials were performed at our partner to investigate the effects of: gas atomization pressure and reactive gas concentration on the particle size distribution (PSD) and the oxygen content of the resulting powder. Also, the effect on the rapidly solidified microstructure (as a function of powder size) was investigated at Ames Lab as a function of reactive gas composition and bulk alloy composition. The results indicated that the pulsatile gas atomization mechanism and a significantly enhanced yield of fine powders reported in the literature for this type of process were not observed. Also it was determined that reactive gas may marginally improve the fine powder yield but further experiments are required. The oxygen content in the gas also did not have any detrimental effect on the microstructure (i.e. did not significantly reduce undercooling). On the contrary, the oxygen addition to the atomization gas may have mitigated some potent catalytic nucleation sites, but not enough to significantly alter the microstructure vs. particle size relationship. Overall the downstream injection of oxygen was not found to significantly affect either the particle size distribution or undercooling (as inferred from microstructure and XRD observations) but injection further upstream, including in the gas atomization nozzle, remains to be investigated in later work.

36 MATERIALS SCIENCE↗

Task Parallel Incomplete Cholesky Factorization using 2D Partitioned-Block Layout

We introduce a task-parallel algorithm for sparse incomplete Cholesky factorization that utilizes a 2D sparse partitioned-block layout of a matrix. Our factorization algorithm follows the idea of algorithms-by-blocks by using the block layout. The algorithm-byblocks approach induces a task graph for the factorization. These tasks are inter-related to each other through their data dependences in the factorization algorithm. To process the tasks on various manycore architectures in a portable manner, we also present a portable tasking API that incorporates different tasking backends and device-specific features using an open-source framework for manycore platforms i.e., Kokkos. A performance evaluation is presented on both Intel Sandybridge and Xeon Phi platforms for matrices from the University of Florida sparse matrix collection to illustrate merits of the proposed task-based factorization. Experimental results demonstrate that our task-parallel implementation delivers about 26.6x speedup (geometric mean) over single-threaded incomplete Choleskyby- blocks and 19.2x speedup over serial Cholesky performance which does not carry tasking overhead using 56 threads on the Intel Xeon Phi processor for sparse matrices arising from various application problems.

2D layout↗

Validation and Verification of the Correct Operation of the Thermo Fisher Scientific’s Genesys 10S spectrometer used in ANC122 and NF-ANC122

In December of 2015, the old qualified Prim UV-Vis instrument used in the ANC122 and NFANC122 procedures failed its monthly calibration check. Attempts to get the system to pass by cleaning flow cells, replacing the light bulb and realigning the light path failed to get sustained reproducible results from the system. As it could no longer pass QA/QC requirements the decision to take it out of service was made. To replace the system, a previously purchased Thermo Fisher Scientific UV-VIS spectrometer (model Genesys 10S; Serial #: 2L5R059137) was retrieved from storage. This report shows that the system is performing as required and meeting all QC requirements listed in ANC122 and NF-ANC122

47 OTHER INSTRUMENTATION↗

PROTEUS-SN User Manual

PROTEUS-SN is a three-dimensional, highly scalable, high-fidelity neutron transport code developed at Argonne National Laboratory. The code is applicable to all spectrum reactor transport calculations, particularly those in which a high degree of fidelity is needed either to represent spatial detail or to resolve solution gradients. PROTEUS-SN solves the second order formulation of the transport equation using the continuous Galerkin finite element method in space, the discrete ordinates approximation in angle, and the multigroup approximation in energy. PROTEUS-SN’s parallel methodology permits the efficient decomposition of the problem by both space and angle, permitting large problems to run efficiently on hundreds of thousands of cores. PROTEUS-SN can also be used in serial or on smaller compute clusters (10’s to 100’s of cores) for smaller homogenized problems, although it is generally more computationally expensive than traditional homogenized methodology codes. PROTEUS-SN has been used to model partially homogenized systems, where regions of interest are represented explicitly and other regions are homogenized to reduce the problem size and required computational resources. PROTEUS-SN solves forward and adjoint eigenvalue problems and permits both neutron upscattering and downscattering. An adiabatic kinetics option has recently been included for performing simple time-dependent calculations in addition to standard steady state calculations. PROTEUS-SN handles void and reflective boundary conditions. Multigroup cross sections can be generated externally using the MC2-3 fast reactor multigroup cross section generation code or internally using the cross section application programming interface (API) which can treat the subgroup or resonance table libraries. PROTEUS-SN is written in Fortran 90 and also includes C preprocessor definitions. The code links against the PETSc, METIS, HDF5, and MPICH libraries. It optionally links against the MOAB library and is a part of the SHARP multi-physics suite for coupled multi-physics analysis of nuclear reactors. This user manual describes how to set up a neutron transport simulation with the PROTEUS-SN code. A companion methodology manual describes the theory and algorithms within PROTEUS-SN.

97 MATHEMATICS AND COMPUTING↗

Planning for Pre-Exascale Platform Environment (Fiscal Year 2015 Level 2 Milestone 5216)

This Plan for ASC Pre-Exascale Platform Environments document constitutes the deliverable for the fiscal year 2015 (FY15) Advanced Simulation and Computing (ASC) Program Level 2 milestone Planning for Pre-Exascale Platform Environment. It acknowledges and quantifies challenges and recognized gaps for moving the ASC Program towards effective use of exascale platforms and recommends strategies to address these gaps. This document also presents an update to the concerns, strategies, and plans presented in the FY08 predecessor document that dealt with the upcoming (at the time) petascale high performance computing (HPC) platforms. With the looming push towards exascale systems, a review of the earlier document was appropriate in light of the myriad architectural choices currently under consideration. The ASC Program believes the platforms to be fielded in the 2020s will be fundamentally different systems that stress ASC’s ability to modify codes to take full advantage of new or unique features. In addition, the scale of components will increase the difficulty of maintaining an errorfree system, thus driving new approaches to resilience and error detection/correction. The code revamps of the past, from serial- to vector-centric code to distributed memory to threaded implementations, will be revisited as codes adapt to a new message passing interface (MPI) plus “x” or more advanced and dynamic programming models based on architectural specifics. Development efforts are already underway in some cases, and more difficult or uncertain aspects of the new architectures will require research and analysis that may inform future directions for program choices. In addition, the potential diversity of system architectures may require parallel if not duplicative efforts to analyze and modify environments, codes, subsystems, libraries, debugging tools, and performance analysis techniques as well as exploring new monitoring methodologies. It is difficult if not impossible to selectively eliminate some of these activities until more information is available through simulations of potential architectures, analysis of systems designs, and informed study of commodity technologies that will be the constituent parts of future platforms.

97 MATHEMATICS AND COMPUTING↗