Search NASA⌕ Search

SEARCH · Search NASA

Results for “COMPUTER PROGRAM DOCUMENTATION”

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 163 records · Page 9

H 2 Production Pathways Cost Analysis (2016 - 2021) (Final Report)

This final report documents cost analysis conducted for the Department of Energy over a five year period (2016 to 2021) pertaining to hydrogen production and delivery system components, focusing on the key remaining challenges of the technology pathways within the Hydrogen Production and Delivery sub-program portfolio. A particular focus was placed on electrolysis for the generation of hydrogen. The effort primarily used the H2A discounted cash flow computational model as a tool to project hydrogen cost ($/kgH 2 ) and determine status improvements resulting from technology advancements. The effort also considered cost as a function of production volume, employed error bars to illustrate uncertainties in the cost estimates, and utilized sensitivity analyses to show the potential for cost reductions. The project examined a range of hydrogen production and delivery related systems. These included WireTough wire-wrapped pressure vessels for hydrogen storage, proton exchange membrane (PEM) electrolysis, solid oxide electrolysis (SOE), anion exchange membrane (AEM) electrolysis, photoelectrochemical (PEC) electrolysis, solar thermochemical hydrogen (STCH) production, the cost of energy transmission, and a study on the necessary price of hydrogen to produce competitively-priced electricity via fuel cell conversion.

08 HYDROGEN↗

RAVEN Theory Manual

RAVEN is a software framework able to perform parametric and stochastic analysis based on the response of complex system codes. The initial development was aimed at providing dynamic risk analysis capabilities to the thermohydraulic code RELAP-7, currently under development at Idaho National Laboratory (INL). Although the initial goal has been fully accomplished, RAVEN is now a multi-purpose stochastic and uncertainty quantification platform, capable of communicating with any system code. In fact, the provided Application Programming Interfaces (APIs) allow RAVEN to interact with any code as long as all the parameters that need to be perturbed are accessible by input files or via python interfaces. RAVEN is capable of investigating system response and explore input space using various sampling schemes such as Monte Carlo, grid, or Latin hypercube. However, RAVEN strength lies in its system feature discovery capabilities such as: constructing limit surfaces, separating regions of the input space leading to system failure, and using dynamic supervised learning techniques. The development of RAVEN started in 2012 when, within the Nuclear Energy Advanced Modeling and Simulation (NEAMS) program, the need to provide a modern risk evaluation framework arose. RAVEN’s principal assignment is to provide the necessary software and algorithms in order to employ the concepts developed by the Risk Informed Safety Margin Characterization (RISMC) program. RISMC is one of the pathways defined within the Light Water Reactor Sustainability (LWRS) program. In the RISMC approach, the goal is not just to identify the frequency of an event potentially leading to a system failure, but the proximity (or lack thereof) to key safety-related events. Hence, the approach is interested in identifying and increasing the safety margins related to those events. A safety margin is a numerical value quantifying the probability that a safety metric (e.g. peak pressure in a pipe) is exceeded under certain conditions. Most of the capabilities, implemented having RELAP-7 as a principal focus, are easily deployable to other system codes. For this reason, several side activates have been employed (e.g. RELAP5-3D, any MOOSE-based App, etc.) or are currently ongoing for coupling RAVEN with several different software. The aim of this document is to provide a set of commented examples that can help the user to become familiar with the RAVEN code usage.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗

FUSRAP Case Study - Benefits and Lessons Learned from Implementation of a Modern Data Solution at Maywood - 18399

This paper focuses on data production and management practices dating back to 1999 that continue to evolve to support the project today. In 2000, the FUSRAP Maywood Project began using a software environmental data management system and laboratory information management system, developed by a single database administrator (DA) and authored in Microsoft Access{sup TM} (MS Access). The original databases included basic functionality including sample number assignment and label generation, tracking of LIMS gamma spec QC and assignment of basic qualifiers and basic database queries. The DA continued over the next fifteen years to refine the EDMS/LIMS by integrating project-specific data evaluation guidance document processes and Quality Assurance/Quality Control (QA/QC) charting and excursion warning tools. With the retirement of the original DA, the U.S. Army Corps of Engineers (USACE)-Cabrera Team procured and implemented a commercial-leaning solution using modern database tools and an established EDMS vendor. For the database transition process, the project team established and configured the new EDMS/LIMS with basic architecture and accessibility; evaluated existing workflows; established/revised LIMS and EDMS-related documentation (manuals and procedures); and conducted dry runs and validation testing. The overall team coordinated closely to facilitate a seamless transition from initial assessment and authoring, to data migration, and finally to resumption of normal ongoing operations. Key features of the new EDMS Subcontractor's software included lookup tables, an import wizard, data checking options and unique indexes. Since the database systems became operational, the technical staff gathered useful feedback from end users (e.g., lab staff, field engineers, task managers, and the third-party data validator) to refine the EDMS/LIMS operation. This feedback triggered improvements in the performance of onsite laboratory qualification forms, promoted consistency in sample ID numbers between the database sample planning screens and field chain-of-custodies, corrected bugs in the LIMS Duplicate Evaluation Report, eliminated data import issues such as blank, inconsistent or missing data from key fields. One of the advantages of the commercial database solution was that it allowed the project to cut cost over time due to the lower cost of database maintenance provided by the commercial database vendor versus the cost of an on-staff DA. Cost savings are estimated at $40,000 per year. There were also indirect cost savings resulting from implementation of the new database since it allowed better integration of the LIMS and EDMS. While there will always be challenges associated with long term records/data management for any old remediation site, the Maywood Team's approach to an upgraded EDMS/LIMS implementation serves as one element of the overall effort to enhance the integrity and reproducibility of critical data that supports the remediation program while at the same time, more effectively using available resources. These lessons-learned will enhance implementation of cost-effective solutions for similar environmental remediation sites. (authors)

97 MATHEMATICS AND COMPUTING↗

NEAMS Problem Draft (FY2020 Assessment)

This report documents the physical configuration required to model the assessment problem posed by the Reactor Physics focus area within the Department of Energy (DOE) Nuclear Energy Advanced Modeling and Simulation (NEAMS) program. This model is based on the Empire model developed by staff at Los Alamos National Laboratory under the MEITNER (Modeling-Enhanced Innovations Trailblazing Nuclear Energy Reinvigoration) program. The reference report does not provide dimensions for development of computational models; those data are provided elsewhere in published. Thus, this report has been prepared to provide a single reference that can be used to create consistent models by assessment participants.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Atomistic Materials Modeling of High-Pressure Hydrogen Interactions in Ethylene Propylene Diene Monomer (EPDM) Rubber

Elastomeric rubbers serve a vital role as sealing materials in the hydrogen storage and transport infrastructure. With applications including O-rings and hose-liners, these components are exposed to pressurized hydrogen at a range of temperatures, cycling rates, and pressure extremes. Cyclic (de)pressurization is known to degrade these materials through the process of cavitation. This readily visible failure mode occurs as a fracture or rupture of the material and is due to the oversaturated gas localizing to form gas bubbles. Computational modeling in the Hydrogen Materials Compatibility Program (H-Mat), co-led by Sandia National Laboratories and Pacific Northwest National Laboratory, employs multi-scale simulation efforts to build a predictive understanding of hydrogen-induced damage in materials. Modeling efforts within the project aim to provide insight into how to formulate materials that are less sensitive to high-pressure hydrogen-induced failure. In this document, we summarize results from atomistic molecular dynamics simulations, which make predictive assessments of the effects of compositional variations in the commonly used elastomer, ethylene propylene diene monomer (EPDM).

08 HYDROGEN↗

ZPRD Database: ZPPR-15 Monte Carlo Results

The ZPPR-15 experiments [1] were mockups of a 330 MWe Integral Fast Reactor (IFR). The ZPPR-15 assembly consisted of a clean, two zone, approximately circular core surrounded by a thin depleted uranium (DU) blanket with sodium (Na) cooling and a thick stainless steel reflector. The ZPPR-15 program was conducted in four phases: A, B, C, and D. Each phase was marked by a particular composition of the reference assembly, with the last three being representative of the three stages of the IFR fuel cycle. This report documents all MCNP [2] runs of the ZPPR-15 loadings that were included in the ZPRD database on GitLab. In the present work, eigenvalues and associated standard deviations were computed for each ZPPR-15 loading with the use of the three data libraries (ENDF/B-VII.0 [3], ENDF/B-VII.1 [4] and ENDF/B-VIII.0 [5]). Relevant results from the obtained outputs are also discussed in this report with two main objectives: a) provide and evaluate updated calculated values with respect to previous reports, notably Refs. [6] and [7] that were based on the use of the ENDF/B-VII.0 library. b) address any change in the observed reactivity effects relevant to the analysis of the experimental data when a different data library is used (previously reported results were mostly based on the use of ENDF/B-VII.0 data only).

Aliberti, Gerardo↗

2021 NIRT Mini Drill (After Action Report)

During the summer and fall of 2021, several functional area drills were held that focused on exercising Consequence Management’s (CM) ability to extract and use data from RadResponder for the purpose of answering intermediate-phase questions presented as technical inject requests for information (RFI) in Sandia National Laboratories (SNL) Consequence Management Operational System (COSMOS) software. The scenario chosen was that of Northern Lights 2016 (NL16) which was a large-scale nuclear power plant (NPP) release exercise in the state of Minnesota. The NL16 data was extracted from the Radiological Assessment and Monitoring System (RAMS) event where it was created and was reformatted for implanting to a new RadResponder event. Next, the beta-version of a laboratory sample data simulator was used to generate more sample data that was injected to the event. Five “mini-drills” were devised with each prompt defined by a data-based need. For each drill, a team of assessment and NARAC scientists worked the problem using the drill prompt and the available data in RadResponder. The teams held a kickoff meeting, had several days to work the problem, and then reported their results as well as observations in a hotwash. Several areas for improvement in both the software and process were identified during the course of these drills. This report will document the process of addressing each RFI and the discovered gaps in both software capability and methodology so that they can be considered for future development and investment by the CM and NIRT programs.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗

Software development infrastructure for the HYBRID modeling and simulation project

One of the goals of the HYBRID modeling and simulation project is to assess the economic viability of hybrid systems in a market that contains renewable energy sources like wind. The idea is that it is possible for the nuclear plant to sell non-electric energy cushions, which absorb (at least partially) the volatility introduced by the renewable energy sources. This system is currently modeled in the Modelica programming language. To assess the economics of the system, an optimization procedure is trying to find the minimal cost of electricity production. The RAVEN code is used as a driver for the whole problem. It is assumed that at this stage, the HYBRID modeling and simulation framework can be classified as non-safety “research and development” software. The associated quality level is Quality Level 3 software. This imposes low requirements on quality control, testing and documentation. The quality level could change as the application development continues.Despite the low quality requirement level, a workflow for the HYBRID developers has been defined that include a coding standard and some documentation and testing requirements. The repository performs automated unit testing of contributed models. The automated testing is achieved via an open-source python script called BuildingsP from Lawrence Berkeley National Lab. BuildingsPy runs Modelica simulation tests using Dymola in an automated manner and generates and runs unit tests from Modelica scripts written by developers. In order to assure effective communication between the different national laboratories a biweekly videoconference has been set-up, where developers can report their progress and issues. In addition, periodic face-face meetings are organized intended to discuss high-level strategy decisions with management. A second means of communication is the developer email list. This is a list to which everybody can send emails that will be received by the collective of the developers and managers involved in the project. Thirdly, to exchange documents quickly, a SharePoint directory has been set-up. SharePoint allows teams and organizations to intelligently share, and collaborate on content from anywhere.

97 MATHEMATICS AND COMPUTING↗

Cyber Science Capability Strategy

This document outlines LANL’s cyber science capability strategy, working in tandem with the IS&T strategy, to focus internal investments utilizing our unique skill sets, capabilities and facilities supporting national scientific priorities to address emerging challenges to national security. This strategy identifies LANL’s strengths as they relate to cyber science and is intended to guide internal investments to increase the strength, focus, and impact of LANL’s cyber capability building innovative scientific leadership. Subsequent documents (human capital development, implementation, capabilities, infrastructure, etc.) will develop plans targeting specific program areas including weapons, energy, and strategic partnership programs.

97 MATHEMATICS AND COMPUTING↗

Validation and Bias Quantification of Criticality Safety Codes for SRNS Operations

The validation and bias quantification methods employed by the Criticality Safety Engineering group at Savannah River Nuclear Solutions are discussed. Both SCALE and MCNP are validated against benchmark experiments, where these benchmark models have been divided into subgroups representative of the types of fissile material operations at SRNS. A quantification of the bias is made for each subgroup for each code and the three methods employed for quantification are discussed. The bias information is employed directly in the establishment of the Upper Safety Limit (USL) value of the neutron multiplication factor when using standardized documented SRNS methods. A simple example of validation and bias quantification is given and the procedure for setting the USL using the derived bias information is also presented.

97 MATHEMATICS AND COMPUTING↗

INTERSECT Architecture Specification: Microservice Architecture (V.0.5)

Oak Ridge National Laboratory (ORNL)’s Self-driven Experiments for Science / Interconnected Science Ecosystem (INTERSECT) architecture project, titled “An Open Federated Architecture for the Laboratory of the Future”, creates an open federated hardware/software architecture for the laboratory of the future using a novel system of systems (SoS) and microservice architecture approach, connecting scientific instruments, robot-controlled laboratories and edge/center computing/data resources to enable autonomous experiments, “self-driving” laboratories, smart manufacturing, and artificial intelligence (AI)-driven design, discovery and evaluation. The project describes science use cases as design patterns that identify and abstract the involved hardware/software components and their interactions in terms of control, work and data flow. It creates a SoS architecture of the federated hardware/software ecosystem that clarifies terms, architectural elements, the interactions between them and compliance. It further designs a federated microservice architecture, mapping science use case design patterns to the SoS architecture with loosely coupled microservices, standardized interfaces and multi programming language support. The primary deliverable of this project is an INTERSECT Open Architecture Specification, containing the science use case design pattern catalog, the federated SoS architecture specification and the microservice architecture specification. This document represents the microservice architecture specification of the INTERSECT Open Architecture Specification.

97 MATHEMATICS AND COMPUTING↗

INTERSECT Architecture Specification: Microservice Architecture (V.0.9)

Oak Ridge National Laboratory (ORNL)’s Self-driven Experiments for Science / Interconnected Science Ecosystem (INTERSECT) architecture project, titled “An Open Federated Architecture for the Laboratory of the Future”, creates an open federated hardware/software architecture for the laboratory of the future using a novel system of systems (SoS) and microservice architecture approach, connecting scientific instruments, robot-controlled laboratories and edge/center computing/data resources to enable autonomous experiments, “self-driving” laboratories, smart manufacturing, and artificial intelligence (AI)-driven design, discovery and evaluation. The project describes science use cases as design patterns that identify and abstract the involved hardware/software components and their interactions in terms of control, work and data flow. It creates a SoS architecture of the federated hardware/software ecosystem that clarifies terms, architectural elements, the interactions between them and compliance. It further designs a federated microservice architecture, mapping science use case design patterns to the SoS architecture with loosely coupled microservices, standardized interfaces and multi programming language support. The primary deliverable of this project is an INTERSECT Open Architecture Specification, containing the science use case design pattern catalog, the federated SoS architecture specification and the microservice architecture specification. This document represents the microservice architecture specification of the INTERSECT Open Architecture Specification.

97 MATHEMATICS AND COMPUTING↗

300_underground robot (final research report)

Recent advancements in mobile robotics have displayed impressive capabilities in traversing and accessing areas that are inaccessible to humans either due to the characteristics of the environment or potential hazards. Furthermore, these advancements within the field of mobile robotics, more specifically uncrewed ground vehicles (UGVs), give the ability to potentially survey, observe, and map these inaccessible areas for humans. However, one of the most challenging areas to implement this technology is underground environments. The main challenge with implementing this technology in underground environments is the dependence on either GPS or RF communication for UGVs to navigate properly. Therefore, in order to properly demonstrate the mapping capabilities of the UGV this challenge must be resolved. The overall goal of this study is to demonstrate the mapping capabilities of a UGV while addressing this challenge and documenting the implementation and testing phase of the robot. The proposed solution to this challenge is to implement a SLAM algorithm onto the main computational device of the UGV utilizing the Robot Operating System (ROS). The algorithm is the open-source software package Slam Toolbox developed by Steve Macenski. Furthermore, the sllidar_ros2 package from Slamtec will be used to gather the lidar data from an A3M1 2D lidar. A separate program will be created to gather odometry information for our UGV robot. All of these software packages will run together in a Docker environment. Through working on this project I have developed a better understanding of the world of robotics/autonomous systems, especially with applications such as navigation and mapping. Furthermore, through this project, I have been given exposure to how research is conducted within a DOE lab setting. As robotics/autonomous systems become more advanced it's important to pursue more avenues of research such as this project as it will ensure the development of our capabilities.

42 ENGINEERING↗

Hardware Evaluation Outreach: Application development Challenges Now and for the Exascale Era

The intent of this document is to assist the programmer in understanding details of contemporary and Exascale hardware system design and how these designs provide opportunities and place constraints on next-generation simulation software design. We attempt to clarify hardware organization and component details for our most current and Exascale systems to help program developers understand how software needs to change in order to take best advantage of the performance available. Exascale success is specifically defined for ECP as a 50x improvement over baseline in the aggregate "capability volume" on several KPP axes, of which raw floating point performance is only one, but also includes characteristics such as problem size, system memory size, node memory size, power, and efficiency. This multi-axis approach is particularly important to understand in the context of delivered improvements in real applications, since, for instance, the floating point computation may comprise less than 10% of the actual computational work required. Given the Exascale requirements and the constraints these requirements put on the performance expectations of fundamental system components, the programmer will be forced to re-think several application implementation details in order to achieve exaflop performance on these systems. The remainder of this document aims to present more detail on Exascale era system hardware and the specific areas that the programmer should address to extract performance from these systems. We attempt to give the programmer guidance at both a high- and low-level, providing some abstract suggestions on how to refactor codes given the expected system architectures and some low-level recommendations on how to implement these modifications. We also include a section on training resources that are helpful for both programmers that are just beginning to understand code modifications for contemporary and Exascale systems and for those that have done some refactoring and are now trying to extract maximal application performance from these systems.

97 MATHEMATICS AND COMPUTING↗

Deliver Signal Phase and Timing (SPAT) for Energy Optimization of Vehicle Cohort Via Cloud-Computing and LTE Communications

Predictive Signal Phase and Timing (SPAT) message set is one fundamental building block for vehicle-to-infrastructure (V2I) applications such as Eco-Approach and Departure (EAD) at traffic signal controlled urban intersections. Among the two complementary communication methods namely short-range sidelink (PC5) and long-range cellular radio link (Uu), this paper documents the work with long-range link: the complete data chain includes connecting to the traffic signals via existing backhaul communication network, collecting the raw signal phase state data, predicting the signal state changes and delivering the SPAT data via a geofenced service to requests over HTTP protocols. An Application Programming Interface (API) library is developed to support various cellular data transmission reduction and latency improvement techniques. An emulation-based algorithm is applied to predict the traffic signal state changes to provide adequate prediction horizon (e.g., at minimum 2 minutes) for the cohort energy optimization. In fact, the same connectivity and SPAT delivery methodology has been applied to traffic signalized intersections nationwide in the United States upon public agency approvals for access to their firewalled traffic control network and signal control systems or directly to individual controllers. This methodology proves its effectiveness and potential for rapid growth of such SPAT deliveries at mass production scale without needing infrastructure hardware retrofit or excessive communication means. To support the energy optimization of light and heavy-duty vehicle cohorts of mixed automation and propulsion systems (EV, ICE and hybrid), the connection and SPAT deliveries at two sites were completed, including public roads in Washtenaw County, Michigan and closed track test sites at American Center for Mobility (ACM) in Ypsilanti, Michigan. However, only closed test track results at ACM will be presented in this paper. A neuroevolution based optimizer is developed and implemented to control the speed of a vehicle cohort with different propulsion systems and automation levels. Closed track tests showed significant energy savings of the cohort operation.

99 GENERAL AND MISCELLANEOUS↗

Parallelization of a Proxy Transport App Using ComputeCPP and SYCL

This document details the attempts to parallelize a multi-group Monte Carlo proxy app using SYCL and the ComputeCPP Community Edition compiler. SYCL is a standard set by the Khronos Group and is described as a, “cross-platform abstraction layer that builds on the underlying concepts, portability and efficiency of OpenCL that enables code for heterogeneous processors to be written in a “single-source” style using completely standard C++.” ComputeCpp Community Edition (CE) is a heterogeneous parallel programming platform that provides a conformant implementation of the SYCL™ 1.2.1 Khronos specification. ComputeCPP provides a compiler and an SDK containing a build system to improve the usability of the compiler. The supported OpenCL 1.2 platforms for ComputeCpp are AMD® and Intel®, with experimental support for PTX which is used on Nvidia graphics cards as well as experimental support for ARM chips. All testing reported in this document was done on the Darwin computer cluster using an Nvidia GTX Titan X graphics card. Since ComputeCPP does not support using this card with OpenCL, ComputeCPP’s experimental PTX64 bit-code generation was used to generate device code.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

SIMD Programming for the SMASH Shock Physics Code

Many modern CPUs that are available to the NNSA as mission computing resources support vector instruction sets. Making good use of vector instructions, referred to as “vectorization”, is often critical to getting the best performance from these CPUs. While other codes choose to rely on compiler auto-vectorization, the SMASH shock physics code chooses to leverage APIs for explicit vectorization. These APIs are similar to directly calling the CPU vendor’s vector intrinsics, with the additional benefit of being vendor-agnostic. This document explains what the SIMD APIs are and how to use them in developing SMASH.

97 MATHEMATICS AND COMPUTING↗

The Capability Portfolio Analysis Tool (CPAT): A Mixed Integer Linear Programming Formulation for Fleet Modernization Analysis (Version 2.0.2).

In order to effectively plan the management and modernization of their large and diverse fleets of vehicles, Program Executive Office Ground Combat Systems (PEO GCS) and Program Executive Office Combat Support and Combat Service Support (PEO CS&CSS) commis- sioned the development of a large-scale portfolio planning optimization tool. This software, the Capability Portfolio Analysis Tool (CPAT), creates a detailed schedule that optimally prioritizes the modernization or replacement of vehicles within the fleet - respecting numerous business rules associated with fleet structure, budgets, industrial base, research and testing, etc., while maximizing overall fleet performance through time. This paper contains a thor- ough documentation of the terminology, parameters, variables, and constraints that comprise the fleet management mixed integer linear programming (MILP) mathematical formulation. This paper, which is an update to the original CPAT formulation document published in 2015 (SAND2015-3487), covers the formulation of important new CPAT features.

97 MATHEMATICS AND COMPUTING↗