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

Code Coverage Status of the ARC code GAMSRC

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. GAMSOR serves as procedure to obtain the neutron and gamma power distribution information in the ARC code system. GAMSOR is a specially modified version of DIF3D (dif3d.x becomes dif3d_gamsor.x). After some work, it was determined that carrying out software on GAMSOR was impractical and would not fit well with commercial grade dedication. GAMSRC was written in the last decade to replace GAMSOR such that the user can rely soley upon the verified DIF3D (dif3d.x) code and GAMSRC to obtain the neutron and gamma power distribution information. GAMSRC is also fully verified and ready for commercial grade dedication. In the coming years, GAMSOR will be deprecated and GAMSRC will fully take over in the ARC code system. This document identifies the set of test problems used to assess the code coverage for GAMSRC. The goal is to document what parts of the existing GAMSRC code are touched by the set of test problems and which are not. The code coverage analysis of GAMSRC was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of GAMSRC. The code coverage tables are given for each submodule of GAMSRC. Because GAMSRC links to modules in DIF3D, some details on coverage changes to the DIF3D lined files is provided. As will be seen, most of the uncovered parts/files can be ignored because they are either for error message and debugging output or obviously not needed by GAMSRC today.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2025

Code Coverage Status of the ARC Code DASSH-F

The Argonne Reactor Code (ARC) software system supports users in their fast reactor design goals by providing neutronic, thermal-hydraulic, and structural analysis capabilities. DASSH-F serves as a steady state thermal hydraulic capability within the ARC system and replaces the SE2-ANL software that preceded it. This document identifies the set of test problems used to assess the code coverage for DASSH-F. The goal is to document what parts of the existing DASSH-F code are touched by the set of test problems and which are not. Because the verification work remains to be done on DASSH-F, one can assume that most of these issues will be resolved as part of that work. The code coverage analysis of DASSH-F was performed with the Code Coverage Tool of the Intel Fortran compiler which requires modifications to the compilation of DASSH-F. The code coverage tables are given for each submodule of DASSH-F. Because DASSH-F links to modules in DIF3D, some details on coverage changes to the DIF3D linked files is provided. As will be seen, most of the uncovered parts/files can be ignored because they are either for error message and debugging output or obviously not needed by DASSH-F today. Seven features of the DASSH-F code were identified to not be covered by the existing testing suite and thus additional verification test problems are suggested to fully cover these sections.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
DOE OSTI2026

RAPIDS2: A SciDAC Institute for Computer Science, Data, and Artificial Intelligence (University of Delaware)

This report summarizes the activities, technical accomplishments, and outcomes of the RAPIDS2 Institute project at the University of Delaware (UD). The RAPIDS2 Institute was a large multi-institution project with the objective of assisting SciDAC and Office of Science application teams in the use of DOE supercomputing resources to achieve scientific breakthroughs. The UD team contributed to this effort through work on formal software verification. This thrust aims to reduce software developer time and effort, especially regarding debugging and testing, and to increase confidence in the correctness of the results computed by the software.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Advancing $otsdaq$ for Optimized Data Acquisition

High-energy physics (HEP) experiments demand data acquisition (DAQ) systems capable of orchestrating complex detector operations, high data throughput, and responsive, real-time feedback. Traditional systems often have steep learning curves, making onboarding difficult for new users. The Off-The-Shelf Data Acquisition $otsdaq$ framework was developed to address these issues by providing a modular and flexible interface that is easier to operate while remaining customizable enough for experimental setups. As the upcoming Mu2e experiment prepares for deployment, improving stability, usability, and performance has become increasingly critical. Our work enhances $otsdaq$ with features that streamline visualization, correct data metrics, improve debugging workflows, and stabilize the user interface.

Mohammed, Ali (ORCID:0009000860386626)↗
DOE OSTI2026

DUNE Rucio Server Scalabiilty Studies

The DUNE collaboration has an ongoing production effort to simulate the full detectors and to analyze the various prototypes that are currently running. Rucio is used to manage the 40PB of files made to date. When 500 or more jobs were sending output to Rucio simultaneously via Rucio upload, we observed timeouts, unhandled exceptions, and Rucio server restarts due to slow performance. In collaboration with the core Rucio team we did a full review of the Rucio upload code and identified several optimizations that can be made. We also have deployed the Ingress load balancer in front of our Rucio servers and added a database connection pooling utility. These changes led to significant improvement both in reliability and scalability, yet we anticipate even better performance will eventually be required. We describe in this paper the initial state of the system, the various debugging processes that were used, and our plans to further improve scalability.

Calcutt, J. [Brookhaven Natl. Lab.]↗
DOE OSTI2026

L'Arlesienne de ROOT

Over many years, ROOT users have repeatedly stumbled over—and loudly rediscovered—the infamous 1 GB limit on individual I/O operations, a constraint that somehow survived long past the era when anyone thought a gigabyte was “a lot.” As experiments embraced ever-larger objects and collections, this limit became an increasingly unavoidable rite of passage. This contribution recounts the sustained, multi-year quest by ROOT I/O developers to finally retire this relic, navigating a maze of legacy APIs, memory-management assumptions, and integer boundaries that seemed determined to preserve the status quo. We describe how internal interfaces were carefully modernized to introduce fully 64-bit–capable code paths without breaking the mountains of existing user code that would definitely have noticed. With the limit now lifted, ROOT can finally handle multi-gigabyte objects in a single read or write operation, even when splitting them into an RNTuple is not an option (we’re looking at you, large RooWorkspaces and giant histograms), liberating users from yet another “fun” debugging adventure and clearing the way for the massive analyses of the HL-LHC and beyond.

Canal, Philippe G. [Fermilab] (ORCID:0000000277487↗
DOE OSTI2026

L'Arlesienne de ROOT

Over many years, ROOT users have repeatedly stumbled over—and loudly rediscovered—the infamous 1 GB limit on individual I/O operations, a constraint that somehow survived long past the era when anyone thought a gigabyte was “a lot.” As experiments embraced ever-larger objects and collections, this limit became an increasingly unavoidable rite of passage. This contribution recounts the sustained, multi-year quest by ROOT I/O developers to finally retire this relic, navigating a maze of legacy APIs, memory-management assumptions, and integer boundaries that seemed determined to preserve the status quo. We describe how internal interfaces were carefully modernized to introduce fully 64-bit–capable code paths without breaking the mountains of existing user code that would definitely have noticed. With the limit now lifted, ROOT can finally handle multi-gigabyte objects in a single read or write operation, even when splitting them into an RNTuple is not an option (we’re looking at you, large RooWorkspaces and giant histograms), liberating users from yet another “fun” debugging adventure and clearing the way for the massive analyses of the HL-LHC and beyond.

Canal, Philippe G. [Fermilab] (ORCID:0000000277487↗
DOE OSTI2026

Knowledge Graph for End-to-End Traceability of an Integrated Human-Earth System Model

Integrated human-Earth system models inform energy-water-land system dynamics and policies, yet their results are difficult to trace through input-data, model structure, scenario configurations, and solved outputs. Because this information is siloed across disconnected artifacts, process-based IAMs have historically lacked a unified, queryable representation. Such lack of traceability prevents researchers from systematically isolating the multi-sector drivers of complex outcomes (such as tracing water-scarcity results back to distant energy-system dynamics) or conducting holistic uncertainty attribution across hundreds of interacting parameters. To address this concern, our work documents the software engineering process of a knowledge graph that unifies these four layers for the Global Change Analysis Model (GCAM-USA_Reference scenario, GCAM v9.1). The graph was built as a relational property graph in DuckDB from the run’s own artifacts: the input-preparation dependency map (gcamdata chunk map), the model’s XML input files, the run configuration, and the results database (BaseX), successfully mapping the model’s declared structure. The resulting graph comprises 204,321 nodes and 1,687,814 edges across 16 node types and 15 edge types, with approximately 16.3 million time-series values stored separately to maintain structural efficiency. To ensure representation fidelity, every edge carries an epistemic-status annotation recording the warrant for the relationship (structural, provenance, dependency, or model-derived), and a machine-readable provenance ledger classifying the origin of every schema element. Evaluation against a fixed five-benchmark suite with locked baselines reports zero structural orphans, zero dangling edge endpoints, and 100% of output-producing technologies traceable to raw input files. Two interactive interfaces present the graph, including a serverless browser application built on DuckDB-Wasm. By establishing the first end-to-end provenance framework for an IAM, this work enables researchers and scientists to systematically audit complex policy scenarios, debug model structures, and trace policy-relevant outputs to their data origins in real time.

Artifical Intelligence↗
DOE OSTI2025

Idiomatic Correctness-Checking via Julienne in Fortran 2023

This paper presents a unified approach to unit testing and runtime assertion checking using Fortran 2023. The paper describes the support for our approach in the Julienne framework. Julienne leverages recent Fortran standards to implement object-oriented design patterns, support testing parallel programs, and implement functional programming patterns in order to craft idioms inspired by natural-language expressions. The presented idioms employ novel operators to write expressions that evaluate to a test-diagnosis object encapsulating two components: (1) the test outcome or assertion outcome and (2) an automatically generated diagnostic string. Two other novel aspects of the approach include (1) the ability to enforce assertions inside pure procedures and (2) the ability to output rich diagnostic information inside pure procedures during error termination when assertions fail. The latter capability mitigates against a reason that Fortran programmers commonly cite for not writing pure procedures: difficulty obtaining useful program output inside pure procedures when debugging code. This paper demonstrates how the adoption of the proposed idioms leads naturally to a unifying theme across two otherwise disparate technologies: unit testing and runtime assertion checking. Finally, this paper describes the usage of the Julienne testing framework for writing unit tests and assertions in the Matcha high-performance computing application and the Fiats deep learning library.

Rouson, Damian↗
DOE OSTI2025

Using Containers to Speed Up Development, to Run Integration Tests and to Teach About Distributed Systems

GlideinWMS is a workload manager provisioning resources for many experiments, including CMS and DUNE. The software is distributed both as native packages and specialized production containers. Following an approach used in other communities like web development, we built our workspaces, system-like containers to ease development and testing. Developers can change the source tree or check out a different branch and quickly reconfigure the services to see the effect of their changes. In this paper, we will talk about what differentiates workspaces from other containers. We will describe our base system, composed of three containers: a one-node cluster including a compute element and a batch system, a GlideinWMS Factory controlling pilot jobs, and a scheduler and Frontend to submit jobs and provision resources. Additional containers can be used for optional components. This system can easily run on a laptop, and we will share our evaluation of different container runtimes, with an eye for ease of use and performance. Finally, we will talk about our experience as developers and with students. The GlideinWMS workspaces are easily integrated with IDEs like VS Code, simplifying debugging and allowing development and testing of the system even when offline. They simplified the training and onboarding of new team members and summer interns. And they were useful in workshops where students could have first-hand experience with the mechanisms and components that, in production, run millions of jobs.

Mambelli, Marco [Fermilab] (ORCID:0000000294892681↗
DOE OSTI2022

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↗
DOE OSTI2025

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↗
NASA NTRS1971

FORTRAN 4 digital program changer

Computer program modifies other source language programs as aid to debugging, checkout and final documentation to eliminate manual performance of rearranging and incrementing statement numbers, identifying and sequencing cards and inserting and/or removing end-of-batch symbols.

Madden, M. F.↗