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 181 records · Page 10

A simplified, efficient approach to hybrid wind and solar plant site optimization

Abstract. Wind plant layout optimization is a difficult, complex problem with a large number of variables and many local minima. Layout optimization only becomes more difficult with the addition of solar generation. In this paper, we propose a parameterized approach to wind and solar hybrid power plant layout optimization that greatly reduces problem dimensionality while guaranteeing that the generated layouts have a desirable regular structure. Thus far, hybrid power plant optimization research has focused on system sizing. We go beyond sizing and present a practical approach to optimizing the physical layout of a wind–solar hybrid power plant. We argue that the evolution strategy class of derivative-free optimization methods is well-suited to the parameterized hybrid layout problem, and we demonstrate how hard layout constraints (e.g., placement restrictions) can be transformed into soft constraints that are amenable to optimization using evolution strategies. Next, we present experimental results on four test sites, demonstrating the viability, reliability, and effectiveness of the parameterized evolution strategy approach for generating optimized hybrid plant layouts. Completing the tool kit for parameterized layout generation, we include a brief tutorial describing how the parameterized evolutionary approach can be inspected, understood, and debugged when applied to hybrid plant layouts.

14 SOLAR ENERGY↗

NLR HPC Kestrel Jobs Data

Overview: Anonymized job-level records from the Kestrel HPC system at the National Laboratory of the Rockies (NLR). Each record represents a Slurm batch job with scheduling metadata, resource requests, utilization, energy estimates, and efficiency metrics. Sensitive fields (user, account, job name, submit line, working directory, submit script, and job type) are replaced with 7-character cryptographic hashes. System & Timeframe: Kestrel is located at the NLR campus. Standard compute nodes have 104 cores and 256 GB RAM; bigmem nodes have 2,000 GB. GPU nodes (gpu-h100 partition) use NVIDIA H100 GPUs. Data covers jobs submitted August 2023 through December 2025. Funding provided by the U.S. Department of Energy, EERE. Files: esif.hpc.kestrel.job-anon.zip — Anonymized job records (Hive-partitioned Parquet) datacard.md — Full dataset documentation ~11 million rows, 50 variables. Readable with PyArrow, pandas, DuckDB, Apache Spark, or any Parquet-compatible tool. Data Collection: Jobs collected via sacct with timezone-aware export (SLURM_TIME_FORMAT="%Y-%m-%dT%H:%M:%S%z"), loaded into PostgreSQL. Calculated columns updated via database triggers and batch functions. All timestamps use timestamptz and correctly handle DST transitions. Preprocessing: Anonymization of name, user, account, submit_line, work_dir, submit_script, and job_type via 7-char hex hashes Derived columns: queue_wait, cpu_eff, max/min/avg_mem_eff, energy estimates Simplified job state mapping (e.g., "CANCELLED by 132357" → "CANCELLED") Boolean flags: python_job, reframe_job Temporal decomposition: year, month, day, day_of_week, hour, minute from submit_time Shared node tracking: shared_job_count, nodes_shared, jobs_shared Key Variables: Scheduling: job_id, partition, state_simple, submit_time, start_time, end_time, queue_wait Resources: nodes_req/used, processors_req/used, memory_req, wallclock_req/used, gpus_requested Efficiency: cpu_eff, max/min/avg_mem_eff Energy: cpu_energy_tdp_estimated_max/used_watt_hours, consumed_energy_raw_joules, consumed_energy_raw_watt_hours Sharing: shared_job_count, nodes_shared, jobs_shared Partitions: short, standard, debug, gpu-h100 Job States: CANCELLED, COMPLETED, FAILED, PENDING, RUNNING QoS Levels: normal, high Important Notes: Timestamps include timezone offsets; DST transitions are handled correctly, though adding intervals across DST boundaries requires offset adjustment shared_job_count reflects physical node co-residency, not use of the shared partition Job step records and raw Slurm JSONB fields are excluded Do not attempt to re-identify individuals from hashed fields

97 MATHEMATICS AND COMPUTING↗

Handling debugger breakpoints in a shared instruction system

A debugger debugs processes that execute shared instructions so that a breakpoint set for one process will not cause a breakpoint to occur in the other processes. A breakpoint is set by recording the original instruction at the desired location and writing a trap instruction to the shared instructions at that location. When a process encounters the breakpoint, the process passes control to the debugger for breakpoint processing if the breakpoint was set at that location for that process. If the trap was not set at that location for that process, the cacheline containing the trap is copied to a small scratchpad memory, and the virtual memory mappings are changed to translate the virtual address of the cacheline to the scratchpad. The original instruction is then written to replace the trap instruction in the scratchpad, so that process can execute the instructions in the scatchpad thereby avoiding the trap instruction.

97 MATHEMATICS AND COMPUTING↗

DebuggingDemo v. 1.0

Intentionally simple buggy code created for use in a debugging demonstration as part of recruiting tech talks. Code exemplifies a buffer overflow, leading to return address corruption. Code also demonstrates unused return value.

Gaines, Sherry↗

Python GST Implementation v. 0.9 beta

PyGSTi is an implementation of Gate Set Tomography in the python programming language. 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.

Nielsen, Erik↗

Improving User Notification on Frequently Changing HPC Environments

Today s HPC centers user environments can be very complex. Centers often contain multiple large complicated computational systems each with their own user environment. Changes to a system s environment can be very impactful; however, a center s user environment is, in one-way or another, frequently changing. Because of this, it is vital for centers to notify users of change. For users, untracked changes can be costly, resulting in unnecessary debug time as well as wasting valuable compute allocations and research time. Communicating frequent change to diverse user communities is a common and ongoing task for HPC centers. This paper will cover the OLCF s current processes and methods used to communicate change to users of the center s large Cray systems and supporting resources. The paper will share lessons learned and goals as well as practices, tools, and methods used to continually improve and reach members of the OLCF user community.

communication↗

Noise Inject Agent Tool

NINJA is a utility tool that quickly manifests message race bugs for debugging MPI applications

Sato, Kento↗

Stack Trace Ahalysis Tool

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 form a 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 TolalView for root cause analysis.

Lee, Gregory L.↗

Build and Execute Environment

At exascale, the challenge becomes to develop applications that run at scale and use exascale platforms reliably, efficiently, and flexibly. Workflows become much more complex because they must seamlessly integrate simulation and data analytics. They must include down-sampling, post-processing, feature extraction, and visualization. Power and data transfer limitations require these analysis tasks to be run in-situ or in-transit. We expect successful workflows will comprise multiple linked simulations along with tens of analysis routines. Users will have limited development time at scale and, therefore, must have rich tools to develop, debug, test, and deploy applications. At this scale, successful workflows will compose linked computations from an assortment of reliable, well-defined computation elements, ones that can come and go as required, based on the needs of the workflow over time. We propose a novel framework that utilizes both virtual machines (VMs) and software containers to create a workflow system that establishes a uniform build and execution environment (BEE) beyond the capabilities of current systems. In this environment, applications will run reliably and repeatably across heterogeneous hardware and software. Containers, both commercial (Docker and Rocket) and open-source (LXC and LXD), define a runtime that isolates all software dependencies from the machine operating system. Workflows may contain multiple containers that run different operating systems, different software, and even different versions of the same software. We will run containers in open-source virtual machines (KVM) and emulators (QEMU) so that workflows run on any machine entirely in user-space. On this platform of containers and virtual machines, we will deliver workflow software that provides services, including repeatable execution, provenance, checkpointing, and future proofing. We will capture provenance about how containers were launched and how they interact to annotate workflows for repeatable and partial re-execution. We will coordinate the physical snapshots of virtual machines with parallel programming constructs, such as barriers, to automate checkpoint and restart. We will also integrate with HPC-specific container runtimes to gain access to accelerators and other specialized hardware to preserve native performance. Containers will link development to continuous integration. When application developers check code in, it will automatically be tested on a suite of different software and hardware architectures.

Guan, Qiang↗

ArrayBridge: Interweaving declarative array processing with high-performance computing

Scientists are increasingly turning to datacenter-scale computers to produce and analyze massive arrays. Despite decades of database research that extols the virtues of declarative query processing, scientists still write, debug and parallelize imperative HPC kernels even for the most mundane queries. This impedance mismatch has been partly attributed to the cumbersome data loading process; in response, the database community has proposed in situ mechanisms to access data in scientific file formats. Scientists, however, desire more than a passive access method that reads arrays from files. This paper describes ArrayBridge, a bi-directional array view mechanism for scientific file formats, that aims to make declarative array manipulations interoperable with imperative file-centric analyses. Our prototype implementation of ArrayBridge uses HDF5 as the underlying array storage library and seamlessly integrates into the SciDB open-source array database system. In addition to fast querying over external array objects, ArrayBridge produces arrays in the HDF5 file format just as easily as it can read from it. ArrayBridge also supports time travel queries from imperative kernels through the unmodified HDF5 API, and automatically deduplicates between array versions for space efficiency. Our extensive performance evaluation in NERSC, a large-scale scientific computing facility, shows that ArrayBridge exhibits statistically indistinguishable performance and I/O scalability to the native SciDB storage engine.

97 MATHEMATICS AND COMPUTING↗

Visualization for Classification in Deep Neural Networks

Recently, the techniques based on Deep Neural Networks (DNNs) have achieved a great performance in classification tasks in a wide range of applications, such as image recognition and natural language processing. However, DNN developers face a lot of trial and error during the development process and spend their efforts in debugging their network model through analyzing and understanding the classification results. As such, tools are needed that help the developers not only understand the results, but also suggest the ways to improve their model. In this paper, we propose a visual analytics tool for visualizing the classification results during the iterative development pipeline of a DNN model. Our tool enables exploring the classification results from any type of neural network models, identifying misclassified samples, examining the predicted score distributions of samples, and showing how the outcomes progressively change during the training process.

Chae, Junghoon↗

INL HPC Overview and CASL Computing Collaboration

October 2019 – INL is increasing the upper limit on Falcon’s high priority “dedicated” CASL queue to 10,000 cores January 2019 – INL will give CASL early-access to the Lemhi system for MAMBA calibration work. The system will likely still be in commission/test mode (subject to reconfiguration/reboots). This early-access to Lemhi should support the required MAMBA calibration runs FY19 -- INL will provide proactive user support for CASL users/jobs and code debugging. INL will specifically focus on helping industry users getting access to Falcon and running their jobs. FY19 CASL costs = $500k vs. $1.2M for a purchased dedicated machine.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

Women in Science: Fermilab Scientific Computing Specialist Krista Majewski

With February 11 marking the International Day of Women and Girls in Science, female physicists, engineers and computer scientists from CERN and Fermilab share their experiences of building careers in science. Krista Majewski came to Fermilab nine years ago as a software developer and now works in an operations role. She is a computing services specialist and part of the grid and cloud operations group, which manages computing clusters for the CMS experiment and other intensity frontier experiments at the lab. "My typical day would be maintaining the services that our group is responsible for and the machines that they run on. So if there are problems with a computing cluster where a user can't run their jobs, or they're trying to run on resources on the grid and they're unable to, then our group would be responsible for helping debug some of those issues," Krista says. Her path to programming at Fermilab has been winding. After receiving a degree in biomedical engineering, she went to work doing web development and programming for a large consulting firm, then moved to the financial industry. But programming called her back, and she earned a master's degree in computer science to start her new career. For Krista, programming is similar to something she enjoyed as child: solving puzzles. "I think it's a skill that you use in a lot of different ways," she says. Credits: Video production - Fermilab Creative Services Music Copyright: Universal Production Music Astral Light Chevalier Idea originally conceived by Tanya Levshina, Fermilab and Maria Dimou, CERN.

99 GENERAL AND MISCELLANEOUS↗

Validation of a Monte Carlo model for the MLC-Elekta Precise with MCNP6 - Paper 76

Cancer treatment using radiotherapy techniques needs an accurate prediction of the dose delivered to the patient at each position. Treatment planning systems (TPS) allow the optimization of the dose delivered to the tumor volume while minimizing the dose absorbed by the surrounding healthy tissue. Commercial treatment planning systems use empirical deterministic algorithms that do not correctly estimate the dose in the surroundings of heterogeneities. This lack of accuracy is taken into account as bigger security margins in the treatment, reducing the potential effect of the treatment. However, Monte Carlo (MC) simulation techniques have proved to predict the dose distribution more accurately and also representing experimental data better. Nevertheless, the clinical application of these techniques has been limited by the long calculation times they require. As high performance computers decrease in cost MC simulations become more feasible to be used in TPS. The present work improves a simplified model of the MLC-Elekta Precise linear accelerator (linac or unit from now on) previously developed and correctly validated by the group. A multileaf collimator (MLC) has been modelled according to the manufacturer specifications and added to the previous model to allow higher conformity in the studies. The full geometry has been entered to the MCNP6 Monte Carlo code to simulate the transport of particles through the linac. The geometry also includes a cubic water phantom for dosimetry studies and validation with experimental data. The experimental data employed for the dose distribution comparison has been measured at the linac from the linac Hospital Universitari Clinic de Valencia (Spain). Additionally, particles are stored in a phase space surface before their entrance in the water to be analyzed and for performance optimization. Given the results presented, we conclude that this first approach to validate a model of the Elekta Precise linac from the Hospital Cl nic Universitari de Valancia represents well the depth-dose distribution, but fails at representing the dose profiles. It has been shown that they predict too much penumbra, probably caused by the filtration between the leaves. In order to solve this problems, further work is needed to improve the simulated model. This work will mainly focus on the multileaf collimator. Also, the codes developed by the group to analyze phase space files produced by MCNP6 have proven highly useful. As work progress and the codes are debugged, they will be published so that the community can take advantage of them.

61 RADIATION PROTECTION AND DOSIMETRY↗

SFDS: The criticality assembly for the experimental research of the nuclear spent fuel dissolver in CIAE - 14401

SFDS is the criticality assembly for the experimental research of the spent fuel dissolver in China Institute of Atomic Energy. The spent fuel dissolver, as the bottleneck of spent fuel reprocessing, has so many characteristics such as the dynamic changes, heterogeneous distribution, complex compositions that it is hard to analysis by theoretical method. Without enough experiments, clear bias and uncertainty of the analysis tools the handling limits for criticality safety in dissolver can't be determined. The SFDS, physical designed by MONK 9A code, uses two kinds of nuclear fuels, 3% enrichment solid UO{sub 2} rods and 5.5% enrichment UO{sub 2}(NO{sub 3}){sub 2} solution, will meet the demand of the critical experiments about the dissolvers. Seven series of critical experiments will be present on it, those are on pitches of rods, uranium concentrations of solutions, nitric acid concentrations of solutions, fission products, void fractions, temperatures and dissolve phases. More kinds of experiments could be introduced with the flexible structures of SFDS in the future. The current work on it are testing and debugging with full systems by water and it will be first critical later in 2015. It will become the first benchmark assembly for critical experiments research in the nuclear fuel cycle system in China. (authors)

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗

Advancing \textit{otsdaq}: Enhancements for Usability, Accuracy, and Robustness

High-energy physics (HEP) experiments require data acquisition (DAQ) systems that can orchestrate complex detector operations, high data throughput, and responsive, real-time feedback to operators. Traditional DAQ stacks, which are often bespoke, command-line driven and highly specific, impose large learning curves on users. The Off-The-Shelf Data Acquisition (\textit{otsdaq}) framework was created to address these issues by offering a highly customizable and scalable browser-based ’desktop’ environment, in which experiment-specific control and monitoring applications can be easily deployed and integrated. Although the initial development of the \textit{otsdaq} software was aimed at the Fermilab Test Beam Facility, \textit{otsdaq} is now being leveraged for broader deployment, including the upcoming Mu2e experiment, where real-time monitoring of field-programmable gate array (FPGA)-based Data Transfer Controllers (DTCs), Clock and Fanout (CFO) boards, and several other subsystems are critical. We contribute a set of targeted improvements to \textit{otsdaq}: bitmap visualization functionality for configured data, improved and corrected delta-based DTC throughput metrics, version control (VC)-backed source navigation for console messages, custom navigation hooks to eliminate disruptive user interface glitches, and copy-to-clipboard support for macro execution history. These changes improve usability, reduce debugging time, and increase accuracy in performance data as Mu2e moves toward commissioning.

Mohammed, A. [Unlisted, US]↗