SEARCH · Engineering Papers
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
The Deep Lynx MOOSE Adapter connects the Deep Lynx data warehouse with any MOOSE executable. The Adapter can receive events from Deep Lynx and will take incoming data to format a template input file for the MOOSE executable. Returns from the MOOSE run are sent back to Deep Lynx for use by other applications.
optimas is a Python library that can coordinate a large number of numerical simulations on high-performance computing resources, with the aim of optimizing a given simulation result. More specifically, this library is currently used for design optimization of laser-plasma particle accelerators. In this context, the performance of particle accelerator designs are often evaluated with large-scale simulation codes, and many separate simulations need to be run - with different design parameters - in order to find the most performant design. optimas facilitates this process by providing a convenient interface to advanced optimizers (e.g. Bayesian optimization), and by coordinating the execution of the different simulations on HPC resources. (This is done by leveraging the library libensemble.) Compared to other open-source optimization libraries (e.g. Ax), optimas is more tailored towards execution on DOE HPC resources (e.g. Perlmutter, Summit, etc.) and is specialized for the type of simulation codes and workflows that are used in the community of laser-plasma acceleration.
AMSLib provides infrastructure to tightly couple multi-scale physics simulation code with ML surrogate model inference. It provides a wholistic runtime execution paradigm to supports uncertainty quantification, surrogate model inference, persistent data storing throughout the execution of a simulation.
Tsuchinoko is a Qt application for adaptive experiment execution and tuning. Live visualizations show details of measurements, and provide feedback on the adaptive engine's decision-making process. The parameters of the adaptive engine can also be tuned live to explore and optimize the search procedure. While Tsuchinoko is designed to allow custom adaptive engines to drive experiments, the gpCAM engine is a featured inclusion. This tool is based on a flexible and powerful Gaussian process regression at the core. A Tsuchinoko system includes 4 distinct components: the GUI client, an adaptive engine, and execution engine, and a core service. These components are separable to allow flexibility with a variety of distributed designs.
The IMG Annotation Pipeline is a collection of Bash and Python scripts to control a workflow for structural and functional annotation of prokaryotic genomes, metagenomes, and metatranscriptomes. The bash scripts in general control the overall workflow and are wrappers around 3rd party executables (not included in repo) that predict features or functions. Whereas the Python scripts do post-processing of raw output in terms of filtering or format transformation and in some cases contain some logic for picking the correct predictions or resolving overlaps. The pipeline is tailored to produce results required by IMG (https://img.jgi.doe.gov/) and is executed on every dataset submitted to IMG via https://img.jgi.doe.gov/submit. These consist of internal genomes, metagenomes and metatranscriptomes sequenced and assembled at the JGI, as well as datasets submitted by external users (non-lab/JGI affiliates).
Software that allows the execution of VISSIM simulations based on any airport access/egress mode share scenario. This is a standalone executable that takes the baseline VISSIM model provided by Seattle Tacoma International Airport (SEA) and a synthetic passenger dataset as inputs and generates travel time changes based on the congestion evaluation function built into the software.
The term "in situ processing" has evolved over the last decade to mean both a specific strategy for visualizing and analyzing data and an umbrella term for a processing paradigm. The resulting confusion makes it difficult for visualization and analysis scientists to communicate with each other and with their stakeholders. To address this problem, a group of over 50 experts convened with the goal of standardizing terminology. This paper summarizes their findings and proposes a new terminology for describing in situ systems. An important finding from this group was that in situ systems are best described via multiple, distinct axes: integration type, proximity, access, division of execution, operation controls, and output type. This paper discusses these axes, evaluates existing systems within the axes, and explores how currently used terms relate to the axes.
Here this work is based on the seminar titled ‘Resiliency in Numerical Algorithm Design for Extreme Scale Simulations’ held March 1–6, 2020, at Schloss Dagstuhl, that was attended by all the authors. Advanced supercomputing is characterized by very high computation speeds at the cost of involving an enormous amount of resources and costs. A typical large-scale computation running for 48 h on a system consuming 20 MW, as predicted for exascale systems, would consume a million kWh, corresponding to about 100k Euro in energy cost for executing 10 23 floating-point operations. It is clearly unacceptable to lose the whole computation if any of the several million parallel processes fails during the execution. Moreover, if a single operation suffers from a bit-flip error, should the whole computation be declared invalid? What about the notion of reproducibility itself: should this core paradigm of science be revised and refined for results that are obtained by large-scale simulation? Naive versions of conventional resilience techniques will not scale to the exascale regime: with a main memory footprint of tens of Petabytes, synchronously writing checkpoint data all the way to background storage at frequent intervals will create intolerable overheads in runtime and energy consumption. Forecasts show that the mean time between failures could be lower than the time to recover from such a checkpoint, so that large calculations at scale might not make any progress if robust alternatives are not investigated. More advanced resilience techniques must be devised. The key may lie in exploiting both advanced system features as well as specific application knowledge. Research will face two essential questions: (1) what are the reliability requirements for a particular computation and (2) how do we best design the algorithms and software to meet these requirements? While the analysis of use cases can help understand the particular reliability requirements, the construction of remedies is currently wide open. One avenue would be to refine and improve on system- or application-level checkpointing and rollback strategies in the case an error is detected. Developers might use fault notification interfaces and flexible runtime systems to respond to node failures in an application-dependent fashion. Novel numerical algorithms or more stochastic computational approaches may be required to meet accuracy requirements in the face of undetectable soft errors. These ideas constituted an essential topic of the seminar. The goal of this Dagstuhl Seminar was to bring together a diverse group of scientists with expertise in exascale computing to discuss novel ways to make applications resilient against detected and undetected faults. In particular, participants explored the role that algorithms and applications play in the holistic approach needed to tackle this challenge. This article gathers a broad range of perspectives on the role of algorithms, applications and systems in achieving resilience for extreme scale simulations. The ultimate goal is to spark novel ideas and encourage the development of concrete solutions for achieving such resilience holistically.
With heterogeneous systems, the number of GPUs per chip increases to provide computational capabilities for solving science at a nanoscopic scale. However, low utilization for single GPUs defies the need to invest more money in expensive accelerators. Although related work develops optimizations to improve application performance, none studies how these optimizations impact hardware resource usage or average GPU utilization. Here, this paper takes a data-driven analysis approach in addressing this gap by (1) characterizing how hardware resource usage affects device utilization, execution time, or both, (2) presenting a multiobjective metric to identify important application-device interactions that can be optimized to improve device utilization and application performance jointly, (3) studying hardware resource usage behaviors of several optimizations for a benchmark application, and finally (4) identifying optimization opportunities for several scientific proxy applications based on their hardware resource usage behaviors. Furthermore, we demonstrate the applicability of our methodology by applying the identified optimizations to a proxy application, which improves the execution time, device utilization, and power consumption by up to 29.6%, 5.3% and 26.5% respectively.
Heterogeneity is the prevalent trend in the rapidly evolving high-performance computing (HPC) landscape in both hardware and application software. The diversity in hardware platforms, currently comprising various accelerators and a future possibility of specializable chiplets, poses a significant challenge for scientific software developers aiming to harness optimal performance across different computing platforms while maintaining the quality of solutions when their applications are simultaneously growing more complex. Code synthesis and code generation can provide mechanisms to mitigate this challenge. We have developed a divide and conquer approach where different aspects of performance are handled by different stand-alone tools that are interfaced with the application through generated code. This portability system, ORCHA, enables users to configure and orchestrate their computations among available resources on a platform by specifying a high-level recipe, thereby permitting a many-to-many paradigm where each recipe results in a different variant of the application. The core design goal is to let users decide the application’s hardware mapping and orchestration by editing only the high-level recipe—without modifying the maintained source code or binding the application to a particular runtime system. Tools in ORCHA distribution are: CG-Kit for translating the recipe into an execution graph; Milhoja to execute the graph by orchestrating data and task movement among hardware resources; and Macroprocessor that enables users to define their own code-shorthand for higher composability and easier management of code variants. Additionally, the design of ORCHA permits tools to work in a plug-and-play mode where the application can build and run without CG-Kit and Milhoja, and either tool can be swapped out for other tools with similar capabilities by modifying the code generation portion of ORCHA. In this paper, we describe the design of ORCHA and the role that code-generation plays in isolating applications from tools. We demonstrate the breadth of configurations ORCHA enables with a case study in which an application configuration is realized on three distinct hardware mappings—a GPU-centric, a CPU/GPU balanced, and a CPU/GPU concurrent layouts by using different recipes.
Comprehensive analysis of high-performance computing (HPC) systems requires linking workload execution to system behavior. This kind of analysis is vital for diagnosing performance issues, managing capacity, detecting anomalous workloads, and understanding how applications interact with system hardware. This job-centric telemetry dataset unifies scheduler job records with node-level measurements, enabling direct association between workloads and their corresponding power, thermal, and performance characteristics. It contains sanitized, scheduler related metadata for 152,400 individual jobs that ran on the Frontier supercomputer and ended on selected days throughout 2024 and 2025, a subpopulation of ~6.8% of the total number of allocated jobs with non-zero run time on the system over that same period. Each is linked with files that contain telemetry time series records of the power utilization and temperature behavior of its allocated nodes and their processors during the run time of the job. Where available, a portion of the job files also contain network performance time series. Jobs are sampled from select days that reflect normal levels of user activity and possess job size distributions with large numbers of leadership class jobs (>20% of Frontier nodes). Jobs in this dataset attempt to best represent successful user workflows.
Constellation Energy and the United States Department of Energy (DOE) have established a public/private partnership to implement a pilot digital upgrade to replace legacy analog, safety-related reactor protection and emergency safety feature actuation systems (RPS/ESFAS) with modern digital systems. This effort is occurring at Constellation’s Limerick Generating Station. This project is being performed in accordance with industry processes that have been adapted to better support digital upgrades. These processes include IP-ENG-001, Standard Design Process, NISP-EN-04, Standard Digital Engineering Process and Electric Power Research Institute Report 3002011816, Digital Engineering Guide. The Light Water Reactor Sustainability (LWRS) Program at the Idaho National Laboratory (INL) has been supporting this effort. Latest INL HFE efforts in support of this project have focused on definition and implementation of the Human Factors Engineering (HFE) Program in support of Constellation design and related licensing efforts. This paper will present the development of the HFE 3D modeling execution of the Main Control Room safety upgrades. New equipment and modifications are planned for upgrading the new safety systems. 3D modeling allows for visualization of the new equipment and modifications to be shared with engineering and design teams for evaluation and review. Anthropometric considerations such as sight lines and functional reach can be evaluated directly using the 3D model. This effort has helped to provide visualizations for additional review with operations personnel and project stakeholders.
Mathematical models are often used to explore network-driven cellular processes from a systems perspective. However, a dearth of quantitative data suitable for model calibration leads to models with parameter unidentifiability and questionable predictive power. Here we introduce a combined Bayesian and Machine Learning Measurement Model approach to explore how quantitative and non-quantitative data constrain models of apoptosis execution within a missing data context. We find model prediction accuracy and certainty strongly depend on rigorous data-driven formulations of the measurement, and the size and make-up of the datasets. For instance, two orders of magnitude more ordinal (e.g., immunoblot) data are necessary to achieve accuracy comparable to quantitative (e.g., fluorescence) data for calibration of an apoptosis execution model. Notably, ordinal and nominal (e.g., cell fate observations) non-quantitative data synergize to reduce model uncertainty and improve accuracy. Finally, we demonstrate the potential of a data-driven Measurement Model approach to identify model features that could lead to informative experimental measurements and improve model predictive power.
Exploiting the relationships among data is a classical query optimization technique. As persistent data is increasingly being created and maintained programmatically, prior work that infers data relationships from data statistics misses an important opportunity. We present Coco, the first tool that identifies data relationships by analyzing database-backed applications. Once identified, Coco leverages the constraints to optimize the application's physical design and query execution. Instead of developing a fixed set of predefined rewriting rules, Coco employs an enumerate-test-verify technique to automatically exploit the discovered data constraints to improve query execution. Each resulting rewrite is provably equivalent to the original query. Using 14 real-world web applications, our experiments show that Coco can discover numerous data constraints from code analysis and improve real-world application performance significantly.
Information around the plug-and-perf treatment design at Utah FORGE by Fervo Energy. Objective and Purpose: - Develop a multistage hydraulic stimulation approach designed specifically to target the top three factors that control the technical and commercial viability of an EGS system: i) Achieving sufficient injectivity to support high cross-well flow rates ii) Distributing flow evenly across the wellbore and reservoir to maximize heat mining efficiency, ensure sustained heat transfer, and mitigate thermal breakthrough iii) Overcoming the effects of stress heterogeneity, stress shadowing, and variations in natural fracture properties during the stimulation treatment, leading to a more predictable stimulated reservoir volume and offset well placement - The following activities will be performed: i) Design, plan, and execute a multistage plug-and-perf stimulation treatment at a Fervo site with data acquisition and well testing activities aimed at addressing key technical aspects of the issues above ii) Perform data processing and interpretation of field results to translate the results form the Fervo site to a site-specific design at the Utah FORGE site iii) Design, plan, and execute a multistage plug-and-perf stimulation treatment design at the Utah FORGE site Methods and Approach: - Design a detailed data acquisition plan to maximize learning around: i) DFIT testing ii) Petrophysical logging, image logging iii) Permanent DAS/DTS fiber optic monitoring iv) Deep borehole microseismic monitoring v) Shallow borehole induced seismicity monitoring vi) Injection/production testing (RTA analysis, tracer testing) vii) Integrated numerical modeling and production forecasting
The SeaRAY is a deployable power system for maritime sensors, monitoring equipment, communications, unmanned underwater vehicles, and other similar payloads. This project is to design, deliver, and test a prototype low-power WEC that lowers the total cost of ownership and provides robust, new capabilities for customers in the maritime environment. Failure Modes, Effects, and Criticality Analysis (FMECA) is conducted to systematically identify all potential failure modes and their effects on the system, and to analyze the criticality of each risk based on the likelihood of the event and the severity of the impact. Actions may then be recommended to mitigate the criticality of a risk, either by reducing the likelihood of the risk or the severity of its impact. Risk assessment is executed iteratively as an integral part of the design process. By incorporating risk assessment early in the development cycle, mitigation of risk can be achieved cost effectively. The actions recommended to mitigate risk may be subsequently executed, and as the design progresses the risk assessment is reviewed and revised. Review of the risk assessment is integrated into structured design reviews, ensuring that critical risks are comprehended and that the Project will not progress to e.g. fabrication while intolerable risks remain. The risk assessment process results in the population and maintenance of Risk Registers (RRs). Each major system (and as needed, subsystem) will have a distinct RR. This allows each system or subsystem to be assessed individually, rendering the RRs to a manageable size for review.
A coupled hydrologic and snowpack stable water isotope model is used to assesses controls on isotopic inputs across the East River, Colorado, a large, mountainous basin. The hydrologic model uses the semi-empirical, spatially distributed and publicly available U.S. Geological Survey numerical code Precipitation-Modelling Runoff System (PRMS). Water and energy are tracked daily through the atmosphere, canopy and subsurface at a 100-m grid resolution. The isotope mass balance model follows previous work by Ala-aho et al. (2017) to track stable isotopes entering the soil system as snowmelt or rain. Water stores and fluxes needed for the isotope model use hydrologic model output for each timestep and model modeled grid location. This data package provides all files related to the hydrologic model (executable, input and output files), the isotopic model calibration and the historic isotopic model (water years 2015-2020). The isotope model source code and executable are provided. The file "readme.txt" includes information on the file structure, steps to run the model, and description of included folders.