Search NASA⌕ Search

SEARCH · Search NASA

Results for “Debugging”

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 199 records · Page 11
All sourcesNASA NTRSDOE OSTI
DOE OSTI2025

Electricity Baseline 2022 Background Data and Log File

The ElectricityLCI v2 Python package (https://github.com/USEPA/ElectricityLCI/tree/v2.0) was used to generate the 2022 electricity baseline: a regionalized life cycle inventory model of U.S. electricity generation, consumption, and distribution using standardized facility and generation data. ElectricityLCI implements a local data store for downloading and accessing public data on an individual's computer. The data store follows the folder definition provided by USEPA's esupy Python package (https://github.com/USEPA/esupy), which utilized the appdirs Python dependency (https://pypi.org/project/appdirs/). This submission includes the background data used to generate the 2022 electricity baseline inventory. Each zip archive stores the source files as found in their data stores. Sub-folders in each of the data stores are archived separately. For example, stewi.zip contains the JSON files, while stewi.facility.zip is the 'facility' sub-folder of stewi data store that stores the parquet files. To reproduce the data store, extract each zip file and drag-and-drop sub-folders in to their appropriate root folders to recreate the data stores, then copy the root folders to your data store folder (as returned by running the following on the command line: `python -c "import appdirs; print(appdirs.user_data_dir())"`). The main five data stores include: 'electricitylci', 'facilitymatcher', 'fedelemflowlist', 'stewi', and 'stewicombo'. The log file generated by the 2022 model run is also included, which contains the statements at the DEBUG level and above.

Electricity; LCA; data inventory↗
DOE OSTI2025

Electricity Baseline 2021 Background Data and Log File

The ElectricityLCI v2 Python package (https://github.com/USEPA/ElectricityLCI/tree/v2.0) was used to generate the 2021 electricity baseline: a regionalized life cycle inventory model of U.S. electricity generation, consumption, and distribution using standardized facility and generation data. ElectricityLCI implements a local data store for downloading and accessing public data on an individual's computer. The data store follows the folder definition provided by USEPA's esupy Python package (https://github.com/USEPA/esupy), which utilizes the appdirs Python dependency (https://pypi.org/project/appdirs/). An overview of the ElectricityLCI data stores may be found on the README (https://github.com/USEPA/ElectricityLCI/blob/v2.0/README.md#data-store). This submission includes the background data used to generate the 2021 electricity baseline inventory. Each zip archive stores the source files as found in their data stores. Sub-folders in each of the data stores are archived separately. For example, stewi.zip contains the JSON files, while stewi.facility.zip is the 'facility' sub-folder of stewi data store that stores the parquet files. To reproduce the data store, extract each zip file and drag-and-drop sub-folders in to their appropriate root folders to recreate the data stores, then copy the root folders to your data store folder (as returned by running the following on the command line: python -c "import appdirs; print(appdirs.user_data_dir())"). The main five data stores include: 'electricitylci', 'facilitymatcher', 'fedelemflowlist', 'stewi', and 'stewicombo'. The log file generated by the 2021 model run is also included, which contains the statements at the DEBUG level and above.

Electricity; LCA; LCI; Life Cycle; data inventory↗
DOE OSTI2025

Electricity Baseline 2020 Background Data and Log File

The ElectricityLCI v2 Python package (https://github.com/USEPA/ElectricityLCI/tree/v2.0) was used to generate the 2020 electricity baseline: a regionalized life cycle inventory model of U.S. electricity generation, consumption, and distribution using standardized facility and generation data. ElectricityLCI implements a local data store for downloading and accessing public data on an individual's computer. The data store follows the folder definition provided by USEPA's esupy Python package (https://github.com/USEPA/esupy), which utilizes the appdirs Python dependency (https://pypi.org/project/appdirs/). An overview of the ElectricityLCI data stores may be found on the README (https://github.com/USEPA/ElectricityLCI/blob/v2.0/README.md#data-store). This submission includes the background data used to generate the 2020 electricity baseline inventory. Each zip archive stores the source files as found in their data stores. Sub-folders in each of the data stores are archived separately. For example, stewi.zip contains the JSON files, while stewi.facility.zip is the 'facility' sub-folder of stewi data store that stores the parquet files. To reproduce the data store, extract each zip file and drag-and-drop sub-folders in to their appropriate root folders to recreate the data stores, then copy the root folders to your data store folder (as returned by running the following on the command line: python -c "import appdirs; print(appdirs.user_data_dir())"). The main five data stores include: 'electricitylci', 'facilitymatcher', 'fedelemflowlist', 'stewi', and 'stewicombo'. The log file generated by the 2020 model run is also included, which contains the statements at the DEBUG level and above.

Electricity; LCA; LCI; Life Cycle; data inventory↗
DOE OSTI2024

CCSI Toolset 3.21 Release

CCSI Toolset 3.21 Release Highlights Parallelization support was added for Sequential Design of Experiments (SDOE) computations using Dask (preliminary). Input type dependent ordering capability was added to the SDOE module. With this implementation the user can specify the level of difficulty to change an input (Easy or Hard) and FOQUS will generate the appropriate ordered design depending on the input difficulty combination. Python version support was extended. FOQUS is now compatible with Python 3.8 through 3.12. Platforms used for automated testing were expanded to include macOS ARM (Apple Silicon). Updates to the FOQUS documentation to include information on how to set paths for SimSinter and TurbineLite. Turbine configuration section was added to Debugging Documentation.

AS↗
DOE OSTI2011

Final Report Start-Up and Commissioning Tests on the DuraMelter 1200 HLW Pilot Melter System Using AZ-101 HLW Simulants

This document provides the final report on data and results obtained from commissioning tests performed on the one-third scale DuraMelter{trademark} 1200 (DM 1200) HLW Pilot Melter system that has been installed at VSL with an integrated prototypical off-gas treatment system. That system has replaced the DM1000 system that was used for HLW throughput testing during Part BI [1]. Both melters have similar melt surface areas (1.2 m{sup 2}) but the DM1200 is prototypical of the present RPP-WTP HLW melter design whereas the DM1000 was not. These tests were performed under a corresponding RPP-WTP Test Specification and associated Test Plan. This report is a followup to the previously issued Preliminary Data Summary Report. The DM1200 system will be used for testing and confirmation of basic design, operability, flow sheet, and process control assumptions as well as for support of waste form qualification and permitting. This will include data on processing rates, off-gas treatment system performance, recycle stream compositions, as well as process operability and reliability. Consequently, this system is a key component of the overall HLW vitrification development strategy. The results presented in this report are from the initial series of short-duration tests that were conducted to support the start-up and commissioning of this system prior to conducting the main body of development tests that have been planned for this system. These tests were directed primarily at system 'debugging,' operator training, and procedure refinement. The AZ-101 waste simulant and glass composition that was used for previous testing was selected for these tests.

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗
DOE OSTI2012

Langston University - High Energy Physics (LU-HEP)

This final report is presented by Langston University (LU) for the project entitled "Langston University High Energy Physics" (LUHEP) under the direction of principal investigator (PI) and project director Professor Joel Snow. The project encompassed high energy physics research performed at hadron colliders. The PI is a collaborator on the DZero experiment at Fermi National Accelerator Laboratory in Batavia, IL, USA and the ATLAS experiment at CERN in Geneva, Switzerland and was during the entire project period from April 1, 1999 until May 14, 2012. Both experiments seek to understand the fundamental constituents of the physical universe and the forces that govern their interactions. In 1999 as member of the Online Systems group for Run 2 the PI developed a cross-platform Python-based, Graphical User Interface (GUI) application for monitoring and control of EPICS based devices for control room use. This served as a model for other developers to enhance and build on for further monitoring and control tasks written in Python. Subsequently the PI created and developed a cross-platform C++ GUI utilizing a networked client-server paradigm and based on ROOT, the object oriented analysis framework from CERN. The GUI served as a user interface to the Examine tasks running in the D\O\ control room which monitored the status and integrity of data taking for Run 2. The PI developed the histogram server/control interface to the GUI client for the EXAMINE processes. The histogram server was built from the ROOT framework and was integrated into the D\O\ framework used for online monitoring programs and offline analysis. The PI developed the first implementation of displaying histograms dynamically generated by ROOT in a Web Browser. The PI's work resulted in several talks and papers at international conferences and workshops. The PI established computing software infrastructure at LU and U. Oklahoma (OU) to do analysis of DZero production data and produce simulation data for the experiment. Eventually this included the FNAL SAM data grid system, the SAMGrid (SG) infrastructure, and the Open Science Grid software stacks for computing and storage elements. At the end of 2003 Snow took on the role of global Monte Carlo production coordinator for the DØ experiment. A role which continues til this day. In January of 2004 Snow started working with the SAMGrid development team to help debug, deploy, and integrate SAMGrid with DØ Monte Carlo production. Snow installed and configured SG execution and client sites at LUHEP and OUHEP, and a SG scheduler site at LUHEP. The PI developed a python based GUI (DAJ) that acts as a front end for job submission to SAMGrid. The GUI interfaces to the DZero Mone Carlo (MC) request system that uses SAM to manage MC requests by the physics analysis groups. DAJ significantly simplified SG job submission and was deployed in DZero in an effort to increase the user base of SG. The following year was the advent of SAMGrid job submission to the Open Science Grid (OSG) and LHC Computing Grid (LCG) through a forwarding mechanism. The PI oversaw the integration of these grids into the existing production infrastructure. The PI developed an automatic MC (Automc) request processing system capable of operating without user intervention (other than getting grid credentials), and able to submit to any number of sites on various grids. The system manages production at all but 2 sites. The system was deployed at Fermilab and remains operating there today. The PI's work in distributed computing resulted in several talks at international conferences. UTA, OU, and LU were chosen as the collaborating institutions that form the Southwest Tier 2 Center (SWT2) for ATLAS. During the project period the PI contributed to the online and offline software infrastructure through his work with the Run 2 online group, and played a major role in Monte Carlo production for DZero. During the part of the project period in which the PI served as MC production coordinator MC production increased very significantly. In the first year of the PI's tenure as production coordinator production was 159M events and 6.7~TB of data. During the last year of the project period production was 2,342~M events and 262~TB of data. That is a factor of 15 increase in events and 39 in data volume. The increase occurred with improvements in computer hardware and networks, through the use of grid technology on diverse resources, and through increased automation and efficiency of the production process. LU HEP developed and deployed the automatic MC request processing system in use at FNAL. The complementary strategies of automation and grid production served DZero well. Fermilab has recognized LU HEP's contribution to DZero by allowing the PI to devote full time to research activities by appointing him a guest scientist for the last six years of the project period.

72 PHYSICS OF ELEMENTARY PARTICLES AND FIELDS↗
DOE OSTI2011

FY2011 Status Report on SN2ND Neutronics Solver Development

A change in focus of NEAMS to a broader set of reactor types necessitated significant effort being diverted away from SN2ND development in FY2011. Nevertheless, significant gains were made with regard to building the new preconditioner and meeting the objectives of 1) parallelism in energy, 2) a spatial multigrid concept, 3) using SN vector spaces to accommodate the adjoint and time dependent functionalities needed for NEAMS work, and 4) complete manuals and documentation. While the desired goal of an exportable SN2ND solver usable within the NEAMS community for neutronics analysis was not completed, we can be confident that this year’s work puts the SN2ND solver well on its way to meeting that objective. It is important to note that SN2ND is just as capable as any other methodology for doing thermal reactor analysis, but the motivation to execute on smaller scale machines has initiated focused development on simplified treatments such as those proposed in the MOCARV tool. All of the cited coding tasks were completed but not all are fully working (i.e. debugged). The spatial multigrid technique was by far the most time consuming part of the SN2ND development process. It required multiple new data structure concepts along with identifying the necessary changes in the vectors and their associated functions. Combining the spatial multigrid as part of a GMRES preconditioner operating on the full vector space, necessary for parallelization in energy, increased the complexity of that development. Research into spatial multigrid techniques for unstructured meshes, void treatments, and code optimization and acceleration are key development needs for SN2ND. Similar to previous years, a considerable amount of effort was spent on validation work. Again we focused on fast reactor problems such as ZPR experiments and the MONJU reactor in Japan. Conventional drawer homogenized models and partially heterogeneous models were used on the ZPR calculations. The drawer homogenized models produced excellent results for both eigenvalue and foil measurements on four loadings of ZPR-6/7. The partially heterogeneous models of ZPR-6/7 also produced good results, but additional work is necessary to generate consistent effective cross section data. Calculations for MONJU were homogeneous and also gave excellent results. Finally, mock-up heterogeneous calculations were setup and attempted to scope out the performance limitations of SN2ND on whole core heterogeneous calculations. Specifically, heterogeneous models of a PWR, a VHTR, and the MONJU reactor were created using anywhere from 2 group to 33 group cross section data. Meshes with greater than 100,000,000 vertices are necessary for accuracy and a specific non-scaling memory issue in PETSc restricted the SN2ND modeling (VHTR and PWR could not be solved). All of the calculations performed this year indicate that significant computational resources beyond those available today are required to obtain a high fidelity solution possible with SN2ND. The future goals for SN2ND are to get the new version fully working, reliable in execution, and to have comparable performance to the old solver such that it can be released within the NEAMS community. After its export to RSICC, we will rely upon further preconditioner research to be done in collaboration with university partners and through the exascale hub activities. Some of that research will focus on making SN2ND applicable to thermal reactor problems, spatial multigrid, and void treatments.

Smith, M. A.↗
DOE OSTI2012

Exploring formal verification methodology for FPGA-based digital systems

With the Life Extension Programs (LEPs), many nuclear weapon (NW) analog electronic components are being replaced by modern digital devices, increasing system complexities dramatically. Ensuring the reliability, security, and robustness of these upgraded systems is critically important. Many custom hardware systems throughout the NW operations space rely on Field-Programmable Gate Arrays (FPGAs) to implement sophisticated logic. Effective verification, while increasing confidence, can reduce the overall effort in system debugging and testing.

Hu, Yalin↗
DOE OSTI2013

Final Scientific Report: A Scalable Development Environment for Peta-Scale Computing

This document is the final scientific report of the project DE-SC000120 (A scalable Development Environment for Peta-Scale Computing). The objective of this project is the extension of the Parallel Tools Platform (PTP) for applying it to peta-scale systems. PTP is an integrated development environment for parallel applications. It comprises code analysis, performance tuning, parallel debugging and system monitoring. The contribution of the Juelich Supercomputing Centre (JSC) aims to provide a scalable solution for system monitoring of supercomputers. This includes the development of a new communication protocol for exchanging status data between the target remote system and the client running PTP. The communication has to work for high latency. PTP needs to be implemented robustly and should hide the complexity of the supercomputer's architecture in order to provide a transparent access to various remote systems via a uniform user interface. This simplifies the porting of applications to different systems, because PTP functions as abstraction layer between parallel application developer and compute resources. The common requirement for all PTP components is that they have to interact with the remote supercomputer. E.g. applications are built remotely and performance tools are attached to job submissions and their output data resides on the remote system. Status data has to be collected by evaluating outputs of the remote job scheduler and the parallel debugger needs to control an application executed on the supercomputer. The challenge is to provide this functionality for peta-scale systems in real-time. The client server architecture of the established monitoring application LLview, developed by the JSC, can be applied to PTP's system monitoring. LLview provides a well-arranged overview of the supercomputer's current status. A set of statistics, a list of running and queued jobs as well as a node display mapping running jobs to their compute resources form the user display of LLview. These monitoring features have to be integrated into the development environment. Besides showing the current status PTP's monitoring also needs to allow for submitting and canceling user jobs. Monitoring peta-scale systems especially deals with presenting the large amount of status data in a useful manner. Users require to select arbitrary levels of detail. The monitoring views have to provide a quick overview of the system state, but also need to allow for zooming into specific parts of the system, into which the user is interested in. At present, the major batch systems running on supercomputers are PBS, TORQUE, ALPS and LoadLeveler, which have to be supported by both the monitoring and the job controlling component. Finally, PTP needs to be designed as generic as possible, so that it can be extended for future batch systems.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2012

CAGE100: Real-Time Multi-Port Packet Capture System for 100 Gigabit Ethernet Traffic

Future large scale sciences are anticipated to use massive amount of data in their experiments. DOE's ESnet (Energy Science Network) is developing a 100 Gbps backbone based on this state-of-the-art 100 Gigabit Ethernet standard. ESnet will serve thousands of DOE and non-DOE scientists with its high bandwidth backbone, and connect several national laboratories. Current Ethernet test and debug solutions, such as network traffic capturer/analyzer tools, support up to 10 Gbps speed, and the very few capable of handling 100 Gbps are extremely costly. Such tools are essential in the development of high speed devices and routers, and ultimately the success of 100 Gigabit Ethernet.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2013

Summary of DBCN Options in MCNP6

The functions of the DBCN card in MCNP6 have expanded considerably beyond their original uses for debugging and other low-level control of the code, and now include a variety of options affecting the general operation and physics of the transport process. In this document, we present a concise table summarizing the functions of this card. This document refers specifically to the first production release of MCNP6.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2012

Simplifying Performance Analysis of Large-scale Adaptive Scientific Applications

Performance analysis of parallel scientific codes is becoming increasingly difficult due to the rapidly growing complexity of applications and architectures. Existing tools fall short in providing intuitive views that facilitate the process of performance debugging and tuning. In this paper, we exploit a recent idea of projecting and visualizing performance data on the communication and hardware domain for faster, more intuitive analysis of applications. We leverage several performance analysis and visualization tools to showcase the discovery of scalability bottlenecks in a structured AMR library. Using novel techniques to project per-phase timing data, application data, and communication data on a communication graph, we identify a previously elusive scaling bottleneck in the library. We present solutions that mitigate this problem, resulting in 22% improvement in the performance for a 65,536-core run on an IBM Blue Gene/P system.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2013

Parallel tools GUI framework-DOE SBIR phase I final technical report

Many parallel performance, profiling, and debugging tools require a graphical way of displaying the very large datasets typically gathered from high performance computing (HPC) applications. Most tool projects create their graphical user interfaces (GUI) from scratch, many times spending their project resources on simply redeveloping commonly used infrastructure. Our goal was to create a multiplatform GUI framework, based on Nokia/Digia’s popular Qt libraries, which will specifically address the needs of these parallel tools. The Parallel Tools GUI Framework (PTGF) uses a plugin architecture facilitating rapid GUI development and reduced development costs for new and existing tool projects by allowing the reuse of many common GUI elements, called “widgets.” Widgets created include, 2D data visualizations, a source code viewer with syntax highlighting, and integrated help and welcome screens. Application programming interface (API) design was focused on minimizing the time to getting a functional tool working. Having a standard, unified, and userfriendly interface which operates on multiple platforms will benefit HPC application developers by reducing training time and allowing users to move between tools rapidly during a single session. However, Argo Navis Technologies LLC will not be submitting a DOE SBIR Phase II proposal and commercialization plan for the PTGF project. Our preliminary estimates for gross income over the next several years was based upon initial customer interest and income generated by similar projects. Unfortunately, as we further assessed the market during Phase I, we grew to realize that there was not enough demand to warrant such a large investment. While we do find that the project is worth our continued investment of time and money, we do not think it worthy of the DOE's investment at this time. We are grateful that the DOE has afforded us the opportunity to make this assessment, and come to this conclusion.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2013

Building a Community Infrastructure for Scalable On-Line Performance Analysis Tools around Open|SpeedShop

In this project we created a community tool infrastructure for program development tools targeting Petascale class machines and beyond. This includes tools for performance analysis, debugging, and correctness tools, as well as tuning and optimization frameworks. The developed infrastructure provides a comprehensive and extensible set of individual tool building components. We started with the basic elements necessary across all tools in such an infrastructure followed by a set of generic core modules that allow a comprehensive performance analysis at scale. Further, we developed a methodology and workflow that allows others to add or replace modules, to integrate parts into their own tools, or to customize existing solutions. In order to form the core modules, we built on the existing Open|SpeedShop infrastructure and decomposed it into individual modules that match the necessary tool components. At the same time, we addressed the challenges found in performance tools for petascale systems in each module. When assembled, this instantiation of community tool infrastructure provides an enhanced version of Open|SpeedShop, which, while completely different in its architecture, provides scalable performance analysis for petascale applications through a familiar interface. This project also built upon and enhances capabilities and reusability of project partner components as specified in the original project proposal. The overall project team’s work over the project funding cycle was focused on several areas of research, which are described in the following sections. The reminder of this report also highlights related work as well as preliminary work that supported the project. In addition to the project partners funded by the Office of Science under this grant, the project team included several collaborators who contribute to the overall design of the envisioned tool infrastructure. In particular, the project team worked closely with the other two DOE NNSA laboratories Los Alamos and Sandia leveraging co-funding for Krell by ASC’s Common Computing Environment (CCE) program as laid out in the original proposal. The ASC CCE co-funding, coordinated through LLNL, was for 50% of the total project funding, with the ASC CCE portion of the funding going entirely to Krell, while the ASCR funding itself was split between Krell and the funded partners. This report covers the entire project from both funding sources. Additionally, the team leveraged the expertise of software engineering researchers from Carnegie Mellon University, who specialize in software framework design, in order to achieve a broadly acceptable component framework. The Component Based Tool Framework (CBTF) software has been released to the community. Information related to the project and the released software can be found on the CBTF wiki page at: http://sourceforge.net/p/cbtf/wiki/Home.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2014

MPI-Bash: Parallel scripting right from the Bourne-Again Shell (Bash)

Parallel, scientific applications running on massively parallel supercomputers commonly produce large numbers of large data files. While parallel filesystems improve the performance of file generation, postprocessing activities such as archiving and compressing the data are often run sequentially (and therefore slowly), squandering the supercomputer's vast performance. Consequently, data that take hours to generate may take days to postprocess. Writing and debugging parallel postprocessing programs is often too time-consuming to be worthwhile, especially for one-off postprocessing operations. What the community needs is a simple mechanism for cobbling together scripts that distribute postprocessing work across a supercomputer's many nodes. MPI-Bash attempts to supply that mechanism by augmenting the GNU project's command shell, Bash, with support for the Message Passing Interface (MPI) and, if available, the Libcircle library for work distribution and load balancing. MPI-Bash makes it easy to parallelize bash scripts that run a set of Linux commands independently over a large number of input files. Because MPI-Bash includes various MPI functions for data transfer and synchronization, it is not limited to embarrassingly parallel workloads but can incorporate phased operations (i.e., all workers must finish operation X before any worker is allowed to begin operation Y).

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2014

RELAP5-3D Developer Guidelines and Programming Practices

Our ultimate goal is to create and maintain RELAP5-3D as the best software tool available to analyze nuclear power plants. This begins with writing excellent programming and requires thorough testing. This document covers development of RELAP5-3D software, the behavior of the RELAP5-3D program that must be maintained, and code testing. RELAP5-3D must perform in a manner consistent with previous code versions with backward compatibility for the sake of the users. Thus file operations, code termination, input and output must remain consistent in form and content while adding appropriate new files, input and output as new features are developed. As computer hardware, operating systems, and other software change, RELAP5-3D must adapt and maintain performance. The code must be thoroughly tested to ensure that it continues to perform robustly on the supported platforms. The coding must be written in a consistent manner that makes the program easy to read to reduce the time and cost of development, maintenance and error resolution. The programming guidelines presented her are intended to institutionalize a consistent way of writing FORTRAN code for the RELAP5-3D computer program that will minimize errors and rework. A common format and organization of program units creates a unifying look and feel to the code. This in turn increases readability and reduces time required for maintenance, development and debugging. It also aids new programmers in reading and understanding the program. Therefore, when undertaking development of the RELAP5-3D computer program, the programmer must write computer code that follows these guidelines. This set of programming guidelines creates a framework of good programming practices, such as initialization, structured programming, and vector-friendly coding. It sets out formatting rules for lines of code, such as indentation, capitalization, spacing, etc. It creates limits on program units, such as subprograms, functions, and modules. It establishes documentation guidance on internal comments. The guidelines apply to both existing and new subprograms. They are written for both FORTRAN 77 and FORTRAN 95. The guidelines are not so rigorous as to inhibit a programmer’s unique style, but do restrict the variations in acceptable coding to create sufficient commonality that new readers will find the coding in each new subroutine familiar. It is recognized that this is a “living” document and must be updated as languages, compilers, and computer hardware and software evolve.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2014

Final Report

The goal of this project was to create a community tool infrastructure for program development tools targeting Petascale class machines and beyond. This includes performance analysis, debugging, and correctness tools, as well as tuning and optimization frameworks. The infrastructure provides a comprehensive and extensible set of individual tool building components. Within this project we developed the basis for this infrastructure as well as set of core modules that allow a comprehensive performance analysis at scale. Further, we developed a methodology and workflow that allows others to add or replace modules, to integrate parts into their own tools, or to customize existing solutions.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2015

Turbocharging Quantum Tomography

Quantum tomography is used to characterize quantum operations implemented in quantum information processing (QIP) hardware. Traditionally, state tomography has been used to characterize the quantum state prepared in an initialization procedure, while quantum process tomography is used to characterize dynamical operations on a QIP system. As such, tomography is critical to the development of QIP hardware (since it is necessary both for debugging and validating as-built devices, and its results are used to influence the next generation of devices). But tomography suffers from several critical drawbacks. In this report, we present new research that resolves several of these flaws. We describe a new form of tomography called gate set tomography (GST), which unifies state and process tomography, avoids prior methods critical reliance on precalibrated operations that are not generally available, and can achieve unprecedented accuracies. We report on theory and experimental development of adaptive tomography protocols that achieve far higher fidelity in state reconstruction than non-adaptive methods. Finally, we present a new theoretical and experimental analysis of process tomography on multispin systems, and demonstrate how to more effectively detect and characterize quantum noise using carefully tailored ensembles of input states.

97 MATHEMATICS AND COMPUTING↗