SEARCH · Search NASA
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.
The Nalu Exascale Wind application assembles linear systems using data structures provided by the Tpetra package in Trilinos. This note describes the initialization and assembly process. The purpose of this note is to help Nalu developers and maintainers to understand the code surrounding linear system assembly, in order to facilitate debugging, optimizations, and maintenance.
In this project, Sandia National Laboratories (SNL) and Rigetti Quantum Computing (RQC) collaborated to test and evaluate (T&E) an 8-qubit quantum information processor developed by RQC. SNL provided quantum circuits and data analysis protocols to benchmark the performance of the device. These protocols included gate-set tomography (GST) on 1- and 2-qubit subsystems, as well as more advanced protocols for characterizing crosstalk and drift. RQC provided high- and low-level access to the 8-qubit device, via direct collaboration: SNL was able to specify T&E experiments as lists of quantum circuits, delivered to RQC via email, and RQC then ran these experiments and delivered the resulting data back to SNL for analysis. The collaboration characterized the performance of all 1-qubit gates on all 8 qubits, and a sample 2-qubit gate on one pair of qubits. Extensive investigation of crosstalk produced nondefinitive results, and revealed significant drift that interfered with crosstalk detection. Drift was analyzed. As a result of this collaboration, SNL was able to test protocols for crosstalk and drift, and improve them in light of experimental data, while RQC was able to learn about the performance of their device and improve it by debugging.
An analysis of the Diablo source code covered by its Software Quality Assurance test suite was performed. Intel’s code coverage tool was used to determine the percentage of covered files, blocks, and functions. Excluding non-functional legacy files and single use developer-only files, the code coverage tool showed that 55% of blocks, the most applicable metric and closest to lines of code, are covered. For a large software code, 70-80% coverage is generally considered a reasonable target.A significant percentage of the uncovered code can be categorized as features that are not practical to test, duplicate/unused legacy code, and niche features only used by select individuals. Additionally, large segments of code dedicated to debugging and error handling are untested, as the test problems do not error out. The remaining untested code can be considered general purpose for use by the analyst/user community. These untested general purpose features are identified in the document and should be prioritized when new testing is added. Suggestions for additional test problems that would have the biggest impact on increasing the code coverage metric are presented. Finally, it is important to note that the single biggest way to increase the overall coverage metric is to delete old and unused code. While admittedly tedious to perform, future code development would also benefit markedly from this. Deleting unused code would likely push the coverage metric north of 60%, which is not too far off the 70-80% target. Overall, the current test suite covers the majority of commonly used features in Diablo, but there remains significant room for improvement. These areas for improvement have been identified.
Understanding the stress development in fluids as they transition to solids is not well-understood. Computational models are needed to represent "birthing stress" for multiphysics applications such as polymer encapsulation around sensitive electronics and additive manufacturing where these stresses can lead to defects such as cracking and voids. The local stress state is also critical to understand and predict the net shape of parts formed in the liquid phase. In this one-year exploratory LDRD, we have worked towards a novel experimental diagnostic to measure the fluid rheology, degree of solidification, and the solid stress development simultaneously. We debugged and made viable a "first-generation" Rheo-Raman system and used it to characterize two types of solidifying systems: paraffin wax, which crystalizes as it solidifies, and thermoset polymers, which form a network of covalent bonds. We used the paraffin wax as a model system to perform flow visualization studies and did some preliminary modeling of the experiment, to demonstrate the inadequacy of the current modeling approaches. This work will inform an advanced fluid constitutive equation that includes a yield stress, temperature dependence, and an evolving viscosity when we pursue the full proposal, which was funded for FY20.
The Production Operations Management System (POMS) is a set of software tools which allows production teams and analysis groups across multiple Fermilab experiments to launch, modify and monitor large scale campaigns of related Monte Carlo or data processing jobs. POMS provides a web service interface that enables automated jobs submission on distributed resources according to customers’ requests and subsequent monitoring and recovery of failed submissions, debugging and record keeping. POMS interfaces with existing HEP data access, processing, movement and monitoring tools at Fermilab, including Jobsub, dCache, SAM, and FIFEmon, and in combination with them handles the creation and tracking of unique filenames for multistage campaigns. A flexible, interactive GUI interface exists as part of the system to visualize campaign stages, parallelization tracks and data flow. An important feature of POMS is a one-to-one connection between the GUI campaign visualizer and a text based representation of the complete campaign configuration. An extensible library of template campaign configurations is available. The templates are user modifiable and map cleanly to and from the GUI description of the campaign. Future releases of POMS will interface with Rucio for file movement.
In 2016/2017, the field of High-Performance Computing (HPC) entered a new era driven by fundamental physics challenges to produce ever more energy and cost-efficient processors. Since the convergence on the Message-Passing Interface (MPI) standard in the mid-1990s, application developers enjoyed a seemingly static view of the underlying machine — that of a distributed collection of homogeneous nodes executing in collaboration. However, after almost two decades of dominance, the sole use of MPI to derive parallelism acted as a limiter to improved future performance. While MPI is widely expected to continue to function as the basic mechanism for communication between compute nodes for the immediate future, additional parallelism is required on the computing node itself if high performance and efficiency goals are to be realized. When reviewing the architectures of the top HPC systems today, the change in paradigm is clear: the compute nodes of the leading machines in the world are either powered by many-core chips with a few dozen cores each, or use heterogeneous designs, where traditional CPUs marshal work to massively parallel compute accelerators which has as many as 200,000 processing threads in flight simultaneously. Complicating matters further for application developers, each processor vendor has its own preferred way of writing code for their architecture.The Kokkos EcoSystem was released by Sandia in 2017 to address this new era in HPC system design by providing a vendor independent performance portable programming system for scientific, engineering, and mathematical software applications written in the C++ programming language. Using Kokkos, application developers can be more productive because they will not have to create and maintain separate versions of their software for each architecture, nor will they have to be experts in each architecture's peculiar requirements. Instead, they will have a single method of programming for the diverse set of modern HPC architectures. While Kokkos started in 2011 as a programming model only, it soon became clear that complex applications needed more. It is also critical to have a portable mathematical functions and developers need tools to debug their applications, gain insight into the performance characteristics of their codes and tune algorithm performance parameters through automated processes. The Kokkos EcoSystem addresses those needs through its three main components: the Kokkos Core programming model, the Kokkos Kernels math library, and the Kokkos Tools project.
The Sandia Utilities form an RF toolkit extending the GNU Radio framework for straightforward interaction with bursty RF systems which can be cumbersome using built in capabilities of the framework or other open source extensions. Motivated by the abstract exercise of responding to a modulated burst of information with a unique modulated burst of information, the Sandia Utilities provide several dozen additional debug and signal processing blocks through four software modules. These blocks manifest their utility through a new general concept of operation for GNU Radio applications and extend many existing streaming capabilities to the PDU-based message passing API. Using these concepts and tools, it is straightforward to develop software capabilities to interact with existing and new bursty RF devices.
Multigroup neutron cross sections were generated for the deterministic radiation transport code SCEPTRE. ENDF/B-VII.1 nuclear data files were downloaded from Los Alamos National Laboratory (LANL), processed with the LANL cross-section preparation code NJOY-2012, and post-processed to produce a SCEPTRE-formatted cross section file. A simple radiation transport problem was used to compare results calculated with MCNP, a continuous-energy radiation transport code from LANL, to results calculated with SCEPTRE using the NJOY-2012-produced multigroup cross sections. This problem was used to debug the python scripts used to post-process the NJOY-2012 output and to assess the accuracy of the multigroup cross sections. These comparisons demonstrate that the multigroup cross sections generated in this work are accurate for most elements but yielded inaccurate results for several common transition metals. This discrepancy appears to result from poor treatment of the resolved resonance region of the continuous-energy cross sections. Further work is recommended to investigate alternative methods to treat these resonances with NJOY-2012.
The current one-year allocation (w20 qburst) is the first year in a two year allocation of the same name. The project has supported two publications in peer-review journals, another manuscript in preparation for publication, a white paper for the Astro2020 Decadal Survey, and a number of talks (see below). Code development continues on implementing a neutrino quantum kinetic equation solver into BURST, now called QBURST. While implementing coherent and forward-scattering processes into the dynamical neutrino evolution equations, multiple numerical issues have appeared. We have remedied a number of these issues through extensive debugging and testing, which include streamlining interpolation and implementing new ODE integration techniques. Further testing is required to solve the problem at a precision of better than one part in 10 6 . We expect that we will understand the numerical difficulties and implement solutions by end of year 2021.
To support an emulator model development of Building Optimization Testing (BOPTEST) framework, a team at the US Department of Energy’s Oak Ridge National Laboratory developed a medium-sized office building written in Modelica to serve as a reference test case. The reference test case was modeled based on an actual research platform that represents a typical medium-sized office building. This test case would encourage model-based design and testing of new controllers in which a developer first prototypes and debugs on a model before implementing in the real world. The developed preliminary model and control parameters will be further calibrated and tuned with actual measured data from experiments
OASIS: Open source AI Software Infrastructure for Science is developed for researchers in the scientific domain. OASIS provides a data API to ingest and serve scientific data formats and annotations within AI workflows. It delivers a unique integration of features such as coupling of data to AI models, scalable training, cloud deployment into a cohesive web and command-line interface, and state-of-the-art techniques to debug and enhance AI models.
A six-month research effort has advanced the hybrid kinetic-fluid modeling capability required for developing non-thermal warm x-ray sources on Z. The three particle treatments of quasi-neutral, multi-fluid, and kinetic are demonstrated in 1D simulations of an Ar gas puff. The simulations determine required resolutions for the advanced implicit solution techniques and debug hybrid particle treatments with equation-of-state and radiation transport. The kinetic treatment is used in preliminary analysis of the non-Maxwellian nature of a gas target. It is also demonstrates the sensitivity of the cyclotron and collision frequencies in determining the transition from thermal to non-thermal particle populations. Finally, a 2D Ar gas puff simulation of a Z shot demonstrates the readiness to proceed with realistic target configurations. The results put us on a very firm footing to proceed to a full LDRD which includes continued development transition criteria and x-ray yield calculation.
The ECP Proxy Application Project has an annual milestone to assess the state of ECP proxy applications. Our FY21 milestone (ADCD-504-11) proposed to: "Assess the performance and fidelity of proxy applications, including those in the ECP Proxy App Suite, relative to the ECP Application workload on heterogeneous platforms. Use proxy applications and selected ECP applications to assess the utility of critical elements of the Exascale toolchain, especially tools used to collect performance data. Identify gaps in coverage and/or common situations in which proxies may fail to adequately represent ECP applications." To satisfy this milestone, the following specific tasks were completed: Study ability of MACSio to represent I/O workloads of adaptive mesh codes; Prepare report on assessed performance and debugging tools; Perform cosine similarity study on Intel and P9 and submit paper; Complete LDMS/GPU subcontract, complete and receive report; Complete validation of LDMS data collection for GPUs and submit paper; and Perform cosine similarity study on GPUs.
Substrate thinning is necessary in devices with flip-chip BGA packages to enable both radiation testing and component qualification and high-spatial resolution beam-based failure analysis methods. We investigated three factors affecting device performance: subsurface damage from the thinning process, reduced heat spreading in thin substrates, and changes in device switching speed. We conclude subsurface damage to crystalline Si caused by the thinning process is removable with sufficient SiO 2 slurry polishing. Local temperature differences increase minimally in devices thinned to 3 μm. Compressive stress in the Si increases globally after device thinning and leads to slowing of ring oscillator frequency by about 0.5% compared to full-thickness devices. Future work will include extending the results to submicron Si thickness values, which also has important benefits for failure analysis, debug, and security assessments. We also plan to extend this type of work to other FPGAs and other devices like memory and processors.
Jefferson Lab (JLab) operates the CEBAF accelerator that provides a high energy (up to 12 GeV) and high current (up to 150 µA) polarized electron beam for fixed target experiments. JLab's mission is to provide substantial progress in understanding the Quantum Chromo Dynamics (QCD), the current theory of the spectrum and the dynamics of hadronic matter. Given the broad scientific program a general-purpose detector, CLAS12, has been designed and constructed. Such a detector requires a sophisticated trigger and current experiments use an on-line FPGA-based system that relies upon custom firmware and electronics both of which are difficult reconfigure from one experiment to the next. To overcome these challenges transitioning to a streaming readout has been proposed since it would allow a more flexible, easier to debug, software trigger to be developed. To facilitate this JLab is gaining experience with streaming readout systems and is actively working to design and test a streaming data acquisition architecture. Significant work has already been done to make existing front-end electronics compatible with operation in streaming mode. Software-wise, much work remains to be done but an existing framework, TriDAS, which was developed for underwater neutrino telescopes can, in principle, be used with the existing JLab hardware. A test stand is already in place in the INDRA DAQ development lab at JLab. This paper will present the development of this TriDAS based test system and it?s operation in-beam using parts of the CLAS12 detector to evaluate streaming readout for a large general purpose detector.
The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. DIF3D plays a pivotal role in the ARC system as the primary homogenized assembly neutronic calculation methodology for fast reactor problems. Over its 40 years history, ARC software usage with DIF3D has been applied to numerous fast and thermal spectrum reactor analysis projects with good to excellent comparison against experiments. With continued improvement of computation resources, many of the geometry modeling capabilities in DIF3D that were primarily used in low order schemes are not really needed anymore. Today, the diffusion and transport capabilities of DIF3D-VARIANT are primarily used in the reactor design process with some scattered usage of DIF3D-FD and DIF3D-Nodal. In recent work, the DIF3D software verification was completed for DIF3D-FD and DIF3D-VARIANT on the geometry options used in the Versatile Test Reactor project. While we can be confident that these capabilities of DIF3D are well used and thus trusted, it does not demonstrate that all possible input options of DIF3D are actually working, but just those that were tested as part of VTR are and that they are correct. Thus, the purpose of the present work is to identify a set of test problems for DIF3D and assess the code coverage of DIF3D for those test problems. The goal is to document what parts of the existing DIF3D code are touched by the set of test problems and which are not. Because the verification work done on DIF3D-VARIANT and DIF3D-FD was focused on the most common uses of DIF3D for fast reactor analysis, the code coverage assessment of those capabilities is the highest priority. This will ensure that nothing is being missed by the existing verification test problems that DIF3D relies upon. The DIF3D-Nodal capability will also be inspected for code coverage as part of this work to further ensure that regular regression testing of DIF3D will trap any likely errors the end user might experience with the DIF3D software. The code coverage analysis of DIF3D was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of DIF3D. The detailed coverage tables are given for each submodule of DIF3D separately, and for the submodules which are primarily developed for DIF3D, most of the source files could be at least partially touched. Most of the uncovered parts/files could be easily ignored, because they are either for error message and debugging output or obviously not needed by DIF3D. Out of the entire source codes of DIF3D, only a few uncovered modules deserve further investigation.
The Real Time Processing Systems Division at Fermilab has deployed new features to the Off-The-Shelf Data Acquisition framework (otsdaq) for the Mu2e experiment. The Mu2e experiment will search for the coherent neutrino-less conversion of a muon into an electron in the field of an aluminum nucleus with a sensitivity improvement of 10,000 times over existing limits. Such a charged lepton flavor-violating reaction probes new physics at a scale unavailable at present or planned high-energy colliders. The Mu2e Trigger and Data Acquisition (TDAQ) system uses otsdaq as its online Data Acquisition System (DAQ) framework. otsdaq integrates the artdaq and art frameworks for event transfer, filtering, and processing. otsdaq is a web-based DAQ software suite focusing on flexibility and scalability and provides a multi-user interface accessible through a web browser. artdaq handles the entire data stream, which is read over the peripheral component interconnect express (PCIe) bus to a software filter algorithm that selects events combined with the data flux coming from a cosmic-ray veto (CRV) system. Detector front-ends are configured through the PCIe bus by customized otsdaq plugins. The otsdaq slow controls infrastructure has been further developed using the experimental physics and industrial control system (EPICS) open-source platform for monitoring, controlling, alarming, and archiving. The detector control system (DCS) for Mu2e has been integrated into otsdaq. The production TDAQ and DCS system has been deployed at the experimental hall and is being debugged and optimized for experiment operations. We report on the feature enhancements and deployment of otsdaq for Mu2e.
We describe a powerful and generalized parameter sweep tool in this report that was originally developed to analyze the performance of existing and novel water treatment models being developed in WaterTAP. Since WaterTAP is built upon IDAES and Pyomo, the parameter sweep tool can be used to systematically explore and debug the behavior of most Pyomo and IDAES numerical models. In order to enable meaningful analyses, the parameter sweep tool has been designed with the following features: 1) Model flexibility: The parameter sweep tool does not enforce any restrictions on the types of models that can be used with it. As long as a Pyomo model can be solved and the parameter is active and mutable, the tool only needs functions that describe how to run the model, the sweep parameters, and the output quantities of interest. 2) Flexible sampling: The parameter sweep tool has inbuilt functions to generate samples from a random distribution or a multidimensional Euclidean space. Furthermore, the users have to ability to supply samples generated from a tool of their choice. 3) Multiple sweep types: A user can choose from one of 3 types of parameter sweeps depending on their needs. 4) Detailed outputs: Outputs generated by the parameter sweep tool can be stored in detailed H5 file or user-friendly CSV files for post processing. 5) Parallel computing: The parameter sweep supports shared and distributed memory parallel computing to enable the use of high performance computers (HPC) for large-scale analyses. 6) Modular: The parameter sweep tool is self-contained and can easily be integrated within an outer-loop analysis or as desired by the user. 7) Ease of use: The tool is well documented and a simple sweep can be easily executed by following the online documentation in a few lines of code. We demonstrate the use of the parameter sweep tool on a simple water treatment system from the WaterTAP repository and show its parallel scaling performance on an Apple laptop and NREL's Eagle HPC. The parameter sweep tool is actively being used with models currently being developed within WaterTAP and we expect its use to grow beyond it to other IDAES and Pyomo models.