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 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
DOE OSTI2018

Stack Trace Analysis Tool (STAT)

STAT is a light weight debugging tool that gathers and merges stack traces from all of the processes in a parallel application. STAT uses the MRNet tree based overlay network to broadcast commands from the tool front-end to the STAT daemons and for the front-end to gather the traces from the STAT daemons. As the traces propagate through the MRNet network tree, they are merged across all tasks to fonn a single call prefix tree. The call prefix tree can be examined to identify tuks with similar function call patterns and to delineate a small set of equivalence classes. A representative task from each of these classes can then be fed into a full feature debugger like TotalView for root cause analysis.

ECP↗
DOE OSTI2019

Python GST Implementation (PyGSTi) v. 0.9

PyGSTi is a Python package for modeling and characterizing noise (errors) in small quantum information processors. In addition to being a basic framework for describing quantum circuits and noise models, it implements mainstream quantum characterization, verification, and validation (QCVV) protocols such as Gate Set Tomography (GST), Randomized Benchmarking (RB), Robust Phase Estimation, and Idle Tomography. It also implements prototype protocols used for timeseries analysis and crosstalk detection, all of which have the goal of better understanding the noise found in existing as-built experimental devices. The central protocol of pyGSTi (from where it derives its name) is Gate Set Tomography. GST is a theory and protocol for simultaneously estimating the state preparation, gate operations, and measurement effects of a physical system of one or many quantum bits (qubits). These estimates are based entirely on the statistics of experimental measurements, and their interpretation and analysis can provide a detailed understanding of the types of errors/imperfections in the physical system. In this way, GST provides not only a means of certifying the “goodness” of qubits but also a means of debugging (i.e. improving) them. The other protocols follow this similar pattern in that they use statistical inference and analysis of experimental data to estimate one or more properties of the noise in a device.

Nielsen, Erik↗
DOE OSTI2016

LabVIEW Task Manager v. 1.10.0

LabVIEW Task Manager is a debugging tool for use during code development in the National Instruments (NI) LabVIEW® IDE. While providing a dynamic & big-picture view of running code, an expandable/collapsible tree diagram displays detailed information (both static and dynamic) on all VIs in memory, belonging to a selected project/target. It allows for interacting with single or multiple selected VIs at a time, providing significant benefits while troubleshooting, and has the following features: Look & Feel similar to Windows® Task Manager; Selection of project/target; Lists all VIs in memory, grouped by class/library; Searches for and enumerates clones in memory; DropIn VI for including dynamically referenced clones (Clone Beacon); 'Refresh Now' (F5) re-reads all VIs in memory and adds new ones to the tree; Displays VI name, owning class/library, state, path, data size & code size; Displays VI FP Behavior, Reentrant?, Reentrancy Type, Paused? & Highlight?; Sort by any column, including by library name; Filter by item types vi, ctl, and vit/ctt; Filter out vi.lib and global VIs; Tracking of, and ability to toggle, execution highlighting on multiple selected VIs; Tracking of paused VIs with ability to Pause/Resume/TogglePause multiple selected VIs; DropIn VI for pausing on a condition; If a clone initiates a pause, a different pause symbol is used for all clones of that same reentrant original VI; Select multiple VIs and open or close their FPs or BDs; Double Click a VI from the tree to bring the BD (first choice) or FP to front, if already open; and Select multiple top-level VIs and Abort them.

Vargo, TimothyD.↗
DOE OSTI2021

CoMTE: Counterfactual Explanations for Supervised Machine Learning Frameworks on Multivariate Time Series Data

CoMTE is a novel explainability technique that provides counterfactual explanations for supervised machine learning frameworks on multivariate time series data. CoMTE outperforms state-of-the-art explainability methods on several different machine learning frameworks and data sets in comprehensibility and robustness. CoMTE can be used to debug machine learning frameworks and gain a better understanding of the underlying multivariate time series data. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525. SAND2021-1686 O

Leung, VitusJ.↗
DOE OSTI2021

HQ-Tracer

HQ-Tracer is a software plugin related to the open-source project Ghidra. It is used for taking an emulation instruction trace from open source platforms and displaying inside of Ghidra. It allows for software debugging, reverse engineering, and enables interactive forward and backward stepping and searching through the execution traces. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525. SAND2021-4552 O

Wright, ChristopherM.↗
DOE OSTI2022

JADE

JADE provides a simple, flexible interface to submit jobs to an HPC. JADE is an HPC workflow management system that enables researchers to run simulations efficiently. It provides a simple, flexible interface to define jobs, as well as dependencies between jobs, and then dispatch them to an HPC with maximized parallelization. It also provides detailed error reporting and resource utilization statistics to aid in debugging problems.

Thom, Daniel↗
DOE OSTI2023

Tools for analysis of optimization models

The software is code for analyzing, debugging, and solving optimization models. The code implements several algorithms and provides convenient APIs to apply these algorithms to optimization models. The algorithms are primarily based on graph theory. They compute well-known partitions of graphs, and use these partitions to provide the user information about their optimization model, including diagnosing certain types of structural modeling errors. Some algorithms may be used as a subroutine to solve an optimization problem, and may call an optimization solver to facilitate this. Well-known linear algebra routines are called to provide further diagnostics. The software contains no data and no models other than toy models used for testing.

Parker, Robert↗
DOE OSTI2016

Dual Active Bridge based DC Transformer LabVIEW FPGA Control Code [SWR-16-25]

In the area of power electronics control, Field Programmable Gate Arrays (FPGAs) have the capability to outperform their Digital Signal Processor (DSP) counterparts due to the FPGA’s ability to implement true parallel processing and therefore facilitate higher switching frequencies, higher control bandwidth, and/or enhanced functionality. National Instruments (NI) has developed two platforms, Compact RIO (cRIO) and Single Board RIO (sbRIO), which combine a real-time processor with an FPGA. The FPGA can be programmed with a subset of the well-known LabVIEW graphical programming language. The candidate software implements complete control algorithms in LabVIEW FPGA for a DC Transformer (DCX) based on a dual active bridge (DAB). A DCX is an isolated bi-directional DC-DC converter designed to operate at unity conversion ratio, M, defined by where Vin is the primary-side DC bus voltage, Vout is the secondary-side DC bus voltage, and n is the turns ratio of the embedded high frequency transformer (HFX). The DCX based on a DAB incorporates two H-bridges, a resonant inductor, and an HFX to provide this functionality. The candidate software employs phase-shift modulation of the two H-bridges and a feedback loop to regulate the conversion ratio at unity. The software also includes alarm-handling capabilities as well as debugging and tuning tools. The software fits on the Xilinx Virtex V LX110 FPGA embedded in the NI cRIO-9118 FPGA chassis, and with a 40 MHz base clock, supports a modulation update rate of 40 MHz, and user-settable switching frequencies and synchronized control loop update rates of tens of kHz.

Source record↗
DOE OSTI2022

pnnl/portfoliomanager-rb

This invention is a Ruby "gem" (library) that provides clients for ENERGY STAR Portfolio Manager (ESPM) Web Services, Inventive features: 100% coverage of version 18.0 of the ESPM API. Automated mapping between ESPM XML schemas and Ruby objects. Clients for both the "live" and "test" ESPM API environments. Debugging mode with HTTP request/response logging.

Borkum, Mark↗
DOE OSTI2026

Scientific Core Library Stack (SCLS) v2026

SCLS (Scientific Core Library Stack) is an opinionated build and packaging system for scientific computing libraries developed at Lawrence Berkeley National Laboratory. It produces a coherent, reproducible stack of numerical libraries — including BLAS/LAPACK, MPI, sparse direct and iterative solvers, graph partitioners, and parallel I/O libraries (e.g., PETSc, SLEPc, HDF5, NetCDF, MUMPS, OpenBLAS) — that work together without manual repair by downstream scientific software. From a single recipe-and-flavor model, SCLS produces native RPM packages for RHEL-family Linux, DEB packages for Debian/Ubuntu, direct Unix-style prefix installs for HPC and locked-down environments, and native macOS builds. Multiple build "flavors" (e.g., GCC+OpenBLAS, GCC+MKL, Intel+MKL, debug) coexist in distinct prefixes on the same host. Compared to general-purpose meta-build frameworks, SCLS is deliberately curated rather than infinitely configurable. It enforces deterministic, audit-friendly behavior: explicit build dependencies, no silent feature autodetection, a clear open-source license policy, and rpath-based runtime linkage so installs integrate cleanly with standard package-manager workflows.

Messe, Christian [Lawrence Berkeley National Labor↗
DOE OSTI2024

PaRSEC: Scalability, flexibility, and hybrid architecture support for task-based applications in ECP

This paper highlights the most significant enhancements made to PaRSEC, a scalable task-based runtime system designed for hybrid machines, during the Exascale Computing Project (ECP). The enhancements focus on expanding the capabilities of PaRSEC to address the evolving landscape of parallel computing. Notable achievements include the integration of support for three major types of accelerators (NVIDIA, AMD, and Intel GPUs), the refinement and increased flexibility of the communication subsystem, and the introduction of new programming interfaces tailored for irregular applications. Additionally, the project resulted in the development of powerful debugging and performance analysis tools aimed at assisting users in understanding and optimizing their applications. We present a comprehensive demonstration of these advancements through a series of benchmarks and applications within ECP and beyond, thereby showcasing the enhanced capabilities of PaRSEC across the diverse architectures within the ECP, providing valuable insights into the runtime system’s adaptability and performance across varied computing environments.

Bouteiller, Aurelien↗
DOE OSTI2019

The MG-RAST API explorer: an on-ramp for RESTful query composition

Background The MG-RAST API provides search capabilities and delivers organism and function data as well as raw or annotated sequence data via the web interface and its RESTful API. For casual users, however, RESTful APIs are hard to learn and work with. Results We created the graphical MG-RAST API explorer to help researchers more easily build and export API queries; understand the data abstractions and indices available in MG-RAST; and use the results presented in-browser for exploration, development, and debugging. Conclusions The API explorer lowers the barrier to entry for occasional or first-time MG-RAST API users.

59 BASIC BIOLOGICAL SCIENCES↗
DOE OSTI2019

Managing genomic variant calling workflows with Swift/T

Bioinformatics research is frequently performed using complex workflows with multiple steps, fans, merges, and conditionals. This complexity makes management of the workflow difficult on a computer cluster, especially when running in parallel on large batches of data: hundreds or thousands of samples at a time. Scientific workflow management systems could help with that. Many are now being proposed, but is there yet the “best” workflow management system for bioinformatics? Such a system would need to satisfy numerous, sometimes conflicting requirements: from ease of use, to seamless deployment at peta- and exa-scale, and portability to the cloud. We evaluated Swift/T as a candidate for such role by implementing a primary genomic variant calling workflow in the Swift/T language, focusing on workflow management, performance and scalability issues that arise from production-grade big data genomic analyses. In the process we introduced novel features into the language, which are now part of its open repository. Additionally, we formalized a set of design criteria for quality, robust, maintainable workflows that must function at-scale in a production setting, such as a large genomic sequencing facility or a major hospital system. The use of Swift/T conveys two key advantages. (1) It operates transparently in multiple cluster scheduling environments (PBS Torque, SLURM, Cray aprun environment, etc.), thus a single workflow is trivially portable across numerous clusters. (2) The leaf functions of Swift/T permit developers to easily swap executables in and out of the workflow, which makes it easy to maintain and to request resources optimal for each stage of the pipeline. While Swift/T’s data-level parallelism eliminates the need to code parallel analysis of multiple samples, it does make debugging more difficult, as is common for implicitly parallel code. Nonetheless, the language gives users a powerful and portable way to scale up analyses in many computing architectures.

Science & Technology - Other Topics↗
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↗