Search NASA⌕ Search

SEARCH · Search NASA

Results for “runtime performance”

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 685 records · Page 38

Comfort in High-Performance Homes in a Hot-Humid Climate

TO5 2.3.2: Large-Scale Temperature Study Although space-conditioning systems are required to meet standards such as those in the Air Conditioning Contractors of America (ACCA) Manual RS (Rutkowski 1997) and the ASHRAE Standard 55 (ASHRAE 2013) comfort criteria, little is known about how space-conditioning systems are actually operating in the field and if these systems are meeting those standards. Unconventional space-conditioning systems may be necessary for low-load homes in the future. It is important to know how current systems are functioning in existing homes and to what temperatures occupants typically set the thermostats in their homes. The U.S. Department of Energy's Building America research team IBACOS set out to find some answers. By using low-cost data loggers and occupant surveys to monitor 37 single-family homes that have standard heating, ventilating, and air-conditioning (HVAC) equipment, the team gained insight into how sensitive occupants are to comfort in their homes relative to the ACCA and ASHRAE standards. This study focused on one climate zone (hot-humid); however, future studies may find differences among occupants- ideas of thermal comfort in other climate zones. Data were collected from installed sensors during a 2-month period from late August 2014 through late October 2014. The final aspect of this project was to review the business metrics associated with builders involved in a comfort and performance guarantee program. The results of this study-taken as an aggregate-show that the homes provided room-to-room temperature differences less than 6 degrees F 95% of the time. Temperature differences were less than 4 degrees F 80% of the time. Some homes showed better or worse performance. On average, two-story homes had a 3.3 degrees F temperature difference between rooms; single-story homes had an average of a 2.2 degrees F temperature difference between rooms. Occupants who did not use programmable thermostats had an average set point of 75 degrees F. Homes in which the thermostats were programmed with a setback schedule showed a median baseline temperature value of 74 degrees F and had a median afternoon setback of 75 degrees F. System runtime was analyzed and showed that the room-to-room temperature uniformity in some homes worsened during an on cycle, whereas the uniformity improved in other homes. That is, when the system was running, some rooms were receiving too much or too little air relative to the rest of the house, and the temperatures in those rooms were moving away from the temperatures of the other rooms in the house. Finally, analysis of the thermostat data shows a wide degree of variability among homes in the study. Interpretation of the measured data suggests that 21 occupants made no regular adjustments to the thermostats in their homes, seven had regular setbacks, seven showed varying setbacks, and 10 appeared to follow no pattern (with random adjustments). Ultimately, the data show that current systems are maintaining expected levels of comfort. As expected, it is more challenging to maintain a uniform temperature in all rooms of two-story homes, and future systems should address this issue. Furthermore, the data show that the majority of homes maintained relative humidity levels below 60% without any supplemental dehumidification

ACCA Manual RS↗

Generalized Ocean Color Inversion Model for Retrieving Marine Inherent Optical Properties

Ocean color measured from satellites provides daily, global estimates of marine inherent optical properties (IOPs). Semi-analytical algorithms (SAAs) provide one mechanism for inverting the color of the water observed by the satellite into IOPs. While numerous SAAs exist, most are similarly constructed and few are appropriately parameterized for all water masses for all seasons. To initiate community-wide discussion of these limitations, NASA organized two workshops that deconstructed SAAs to identify similarities and uniqueness and to progress toward consensus on a unified SAA. This effort resulted in the development of the generalized IOP (GIOP) model software that allows for the construction of different SAAs at runtime by selection from an assortment of model parameterizations. As such, GIOP permits isolation and evaluation of specific modeling assumptions, construction of SAAs, development of regionally tuned SAAs, and execution of ensemble inversion modeling. Working groups associated with the workshops proposed a preliminary default configuration for GIOP (GIOP-DC), with alternative model parameterizations and features defined for subsequent evaluation. In this paper, we: (1) describe the theoretical basis of GIOP; (2) present GIOP-DC and verify its comparable performance to other popular SAAs using both in situ and synthetic data sets; and, (3) quantify the sensitivities of their output to their parameterization. We use the latter to develop a hierarchical sensitivity of SAAs to various model parameterizations, to identify components of SAAs that merit focus in future research, and to provide material for discussion on algorithm uncertainties and future ensemble applications.

Werdell, P. Jeremy↗

Improving the Performance of NEML2 with Modern Graph Compilation Backends

NEML2 vectorizes constitutive-model evaluation for large-scale multiphysics simulation, using PyTorch as its tensor backend so that a batch of material-point updates runs on CPU or GPU through a single implementation. In the two prior reports in this series it was a C++-native library, deployed through TorchScript tracing and just-in-time (JIT) compilation; it has since been rewritten from the ground up into a Python-native library deployed through Ahead-of-Time Inductor (AOTInductor), a modern PyTorch graph-compilation backend. The rewrite is driven by a persistent tension, not a language preference: NEML2 composes constitutive models at runtime from a registry of small, independently-authored pieces, and that flexibility is difficult to reconcile with the compile-time knowledge an efficient GPU kernel needs. This report documents the rewrite and the investment that accompanied it: the AOTInductor export pipeline that turns a Python-authored model into a portable, Python-free compiled artifact loadable from pure C++; the eager and compiled runtimes and the new implicit solver layer built on them; a head-to-head benchmark of legacy JIT against AOTInductor; the physics-model catalog and its worked examples; the developer tooling; and the corresponding overhaul of MOOSE’s NEML2 integration that lets MOOSE consume it. A central objective is to examine whether modern PyTorch graph-compilation backends are effective for MOOSE GPU integration. The benchmark answers directly: AOTInductor outperforms legacy JIT on every GPU scenario measured, by 1.0–4.5×. Modern graph-compilation backends are effective for MOOSE GPU integration, and AOTInductor specifically – not compilation in the abstract – is why.

Hu, Gary (Tianchen) [Argonne National Laboratory (↗

DeepFreeze: Towards Scalable Asynchronous Checkpointing of Deep Learning Models

In the age of big data, deep learning has emerged as a powerful tool to extract insight and exploit its value, both in industry and scientific applications. One common pattern emerging in such applications is frequent checkpointing of the state of the learning model during training, needed in a variety of scenarios: analysis of intermediate states to explain features and correlations with training data, exploration strategies involving alternative models that share a common ancestor, knowledge transfer, resilience, etc. However, with increasing size of the learning models and popularity of distributed data-parallel training approaches, simple checkpointing techniques used so far face several limitations: low serialization performance, blocking I/O, stragglers due to the fact that only a single process is involved in checkpointing. This paper proposes a checkpointing technique specifically designed to address the aforementioned limitations, introducing efficient asynchronous techniques to hide the overhead of serialization and I/O, and distribute the load over all participating processes. Experiments with two deep learning applications (CANDLE and ResNet) on a pre-Exascale HPC platform (Theta) shows significant improvement over state-of-art, both in terms of checkpointing duration and runtime overhead.

checkpointing↗

Launch Complex 34, SWMU CC054 2023 DNAPL Source Zone Operations, Maintenance, and Monitoring, Site-Wide Long-Term Monitoring, and Hot Spot 6 Air Sparge System Annual Performance Monitoring and Phase Two Expansion Construction Completion Report Cape Canaveral Space Force Station, Florida

This Annual Performance Monitoring Report (PMR) for the Dense Non-Aqueous Phase Liquid (DNAPL) Source Zone (DSZ), Site-Wide Long-Term Monitoring (LTM), and Hot Spot 6 (HS 6) Air Sparge (AS) System presents the results of Year 14 operations and performance monitoring of the hydraulic containment (HC) Interim Measure (IM), details associated with construction and implementation of the HS 6 AS system expansion (Phase Two), and the results of operations and performance sampling of the HS 6 AS IM at Launch Complex 34 (LC34), located at Cape Canaveral Space Force Station (CCSFS), Florida. The timeframe for activities documented in this PMR extends from April 1, 2023 to March 31, 2024. LC34 has been designated Solid Waste Management Unit CC054 under the Kennedy Space Center (KSC) Resource Conservation and Recovery Act Corrective Action Program. The objective of the HC IM at LC34 is to contain the shallow and deep DSZ and surrounding dissolved-phase trichloroethene (TCE) high concentration plume via operation of a hydraulic containment system (HCS). The pre-IM design 300 micrograms per liter (μg/L) TCE groundwater contour was used to establish the deep zone capture area for deep recovery wells, and the shallow zone capture area was defined by the DSZ. The system began operating in 2010, and in 2015, the system was expanded to provide HC for areas within the 300 μg/L TCE groundwater isocontours of HS 3 and 4. In 2018 and 2019, an investigation was conducted to recharacterize the DSZ, which included investigating TCE mass in Layer 7. This data was subsequently used to optimize the pumping rates of the HCS and install additional recovery wells in Layer 7 to more adequately capture residual contaminant mass. The operational period for Year 14 of the HCS was from April 1, 2023 to March 31, 2024. Operational runtime for the system was 94 percent during Year 14, with downtime events attributed to planned maintenance, system repairs, and power outages. As of March 31, 2024, a total of 344,849,634 cumulative gallons of groundwater containing 94,656 pounds of chlorinated volatile organic compounds (CVOCs) have been removed by the HCS. During the reporting period covered under this report, the HCS recovered 31,176,393 gallons and approximately 6,319 pounds of CVOC mass. Total combined influent concentrations of TCE have decreased since startup from approximately 280,000 µg/L (January 2010) to 25,000 µg/L (March 2024). During the reporting period, all effluent concentrations from the HCS (aqueous and vapor) were below regulatory reporting limits, indicating the system continues to operate as intended. Performance monitoring was conducted in January 2024 within the DSZ to evaluate TCE contamination. Groundwater samples were collected via DPT at nine locations, consistent with previous events between 2017 and 2022. Full vertical profile sampling was completed at each DPT from 8 to 98 feet below land surface (bls), at 5-foot intervals. The DPT performance monitoring results are summarized in this PMR. The results revealed TCE remains at concentrations greater than 11,000 µg/L in the DSZ (1-percent solubility, indicative of DNAPL) at eight of the nine DPT locations and at depths ranging from 28 to 98 feet bls. An overall decreasing trend of TCE concentrations was observed in DPT samples during this reporting period, which is a reduction from the previous event (December 2022) and the peak event in December 2021, where TCE percentages appeared to increase in all depth zones because several recovery wells were turned off during the AS pilot study in the DSZ. The maximum TCE concentration in January 2024 was 1,600,000 µg/L in the 53 feet bls depth interval at DPT594 (previous maximum result in 2022 was 1,800,000 µg/L in the 48 feet bls depth interval at DPT599). This maximum concentration in the 53 feet bls depth interval is in the deep capture zone. During the January 2024 DPT event, the largest portion of TCE mass was observed in the 48 feet bls interval above/within Layer 4. This trend remains consistent with previous years and appears to indicate continued mass discharge from Layer 4 (fine-grained unit). In addition to DPT sampling, annual groundwater samples were collected from 11 deep monitoring wells in the DSZ area (Layers 7 and 8) in December 2023 to verify vertical and horizontal delineation. Three of the wells were also sampled biweekly to evaluate operations of recovery well RW21D (screened 86 to 106 feet bls), which was installed in January 2023. Of the Layer 7/8 monitoring sampled only annually, results were non-detect or less than groundwater cleanup target levels GCTLs in December 2023, with the exception of one well, IW45D2, which had a cis-1,2-dichloroethene (cDCE), detection greater than the GCTL. Of the three wells sampled biweekly during the operational period, the well located closest to Layer 7 recovery well RW21D (IW44D2, screened 105 to 115 feet bls) had concentrations of TCE, cDCE and vinyl chloride (VC) greater than GCTLs throughout the operational period, but displayed a decreasing trend since the peak concentrations in September 2023. The maximum TCE concentration during this operational period was 190,000 µg/L at IW44D2 in September 2023, but reduced to 700 µg/L in March 2024, indicating the HCS is still effectively removing mass from the source area. Expansion of the HCS and addition of new recovery wells is ongoing and will continue to be evaluated as the groundwater recovery scheme is optimized. Details of the expansion and optimization will be provided in a future PMR. The HS 6 AS IM was initiated in 2018 with 160 AS wells and expanded in 2019 with another 140 AS wells. An additional expansion of the HS 6 AS IM was completed during the reporting period covered under this report and details of the construction implementation and startup of the expansion are detailed in Section III of this report. The new expansion, referred to as Phase Two, was implemented between August 17, 2022 and August 28, 2023, and included the installation of 190 air sparge wells to treat an additional 11.2 acres. The original configuration (referred to as Phase One) operated until Phase Two came online, then all but 52 AS wells were turned off so the components could be moved and utilized in the Phase Two area. The 52 AS wells that remain on are in a barrier configuration preventing contaminated groundwater from impacting the treated area. The HS 6 AS system (both Phase One and Two) operated normally during the reporting period covered under this report. Semi-annual performance monitoring of the Phase One configuration was conducted in April and November 2023, consistent with previous years. For the Phase Two configuration, 21 new monitoring wells were installed and sampled quarterly, with a baseline event in July 2023, and quarterly events in November 2023 and February 2024 summarized in this report. Semi-annual monitoring results collected in April and October 2023 show concentrations of contaminants of concern (cDCE, trans-1,2-dichloroethene, and VC) have decreased to less than GCTLs in nearly all wells and not impacting the surface water drainage canal, indicating the HS 6 IM continues to meet objectives. The baseline and quarterly sampling for the Phase Two configuration indicate generally decreasing concentrations in wells within and around the perimeter of the treatment area. At least two more quarters of monitoring will be conducted and once those results are evaluated a reduced the sampling frequency may be considered. Overall, the tasks associated with Year 14 operation of the HC IM and operation of the HS 6 AS IM were performed in accordance with recommendations included in the previous 2022 LC34 (Year 13) PMR. Evaluation of results from the HC IM and HS 6 IM show that these systems are operating as designed and meeting performance objectives.

groundwater remediation↗

ChatHPC: Building the Foundations for a Productive and Trustworthy AI-Assisted HPC Ecosystem

ChatHPC democratizes large language models for the high-performance computing (HPC) community by providing the infrastructure, ecosystem, and knowledge needed to apply modern generative AI technologies to rapidly create specific capabilities for critical HPC components while using relatively modest computational resources. Our divide-and-conquer approach focuses on creating a collection of reliable, highly specialized, and optimized AI assistants for HPC based on the cost-effective and fast Code Llama fine-tuning processes and expert supervision. We target major components of the HPC software stack, including programming models, runtimes, I/O, tooling, and math libraries. Thanks to AI, ChatHPC provides a more productive HPC ecosystem by boosting important tasks related to portability, parallelization, optimization, scalability, and instrumentation, among others. With relatively small datasets (on the order of KB), the AI assistants, which are created in a few minutes by using one node with two NVIDIA H100 GPUs and the ChatHPC library, can create new capabilities with Meta’s 7-billion parameter Code Llama base model to produce high-quality software with a level of trustworthiness of up to 90% higher than the 1.8-trillion parameter OpenAI ChatGPT-4o model for critical programming tasks in the HPC software stack.

Young, Aaron [ORNL] (ORCID:0000000254484667)↗

High-throughput virtual laboratory for drug discovery using massive datasets

Time-to-solution for structure-based screening of massive chemical databases for COVID-19 drug discovery has been decreased by an order of magnitude, and a virtual laboratory has been deployed at scale on up to 27,612 GPUs on the Summit supercomputer, allowing an average molecular docking of 19,028 compounds per second. Over one billion compounds were docked to two SARS-CoV-2 protein structures with full optimization of ligand position and 20 poses per docking, each in under 24 hours. GPU acceleration and high-throughput optimizations of the docking program produced 350× mean speedup over the CPU version (50× speedup per node). GPU acceleration of both feature calculation for machine-learning based scoring and distributed database queries reduced processing of the 2.4 TB output by orders of magnitude. The resulting 50× speedup for the full pipeline reduces an initial 43 day runtime to 21 hours per protein for providing high-scoring compounds to experimental collaborators for validation assays.

97 MATHEMATICS AND COMPUTING↗

High Performance Computing Based Parallel HIearchical Modal Association Clustering (HPAR HMAC)

For many applications, clustering is a crucial step in order to gain insight into the makeup of a dataset. The best approach to a given problem often depends on a variety of factors, such as the size of the dataset, time restrictions, and soft clustering requirements. The HMAC algorithm seeks to combine the strengths of 2 particular clustering approaches: model-based and linkage-based clustering. One particular weakness of HMAC is its computational complexity. HMAC is not practical for mega-scale data clustering. For high-definition imagery, a user would have to wait months or years for a result; for a 16-megapixel image, the estimated runtime skyrockets to over a decade! To improve the execution time of HMAC, it is reasonable to consider an multi-core implementation that utilizes available system resources. An existing imple-mentation (Ray and Cheng 2014) divides the dataset into N partitions - one for each thread prior to executing the HMAC algorithm. This implementation benefits from 2 types of optimization: parallelization and divide-and-conquer. By running each partition in parallel, the program is able to accelerate computation by utilizing more system resources. Although the parallel implementation provides considerable improvement over the serial HMAC, it still suffers from poor computational complexity, O(N2). Once the maximum number of cores on a system is exhausted, the program exhibits slower behavior. We now consider a modification to HMAC that involves a recursive partitioning scheme. Our modification aims to exploit divide-and-conquer benefits seen by the parallel HMAC implementation. At each level in the recursion tree, partitions are divided into 2 sub-partitions until a threshold size is reached. When the partition can no longer be divided without falling below threshold size, the base HMAC algorithm is applied. This results in a significant speedup over the parallel HMAC.

Patlolla, Dilip R↗

Performance Portability of Molecular Docking Miniapp On Leadership Computing Platforms

Rapidly changing computer architectures, such as those found at high-performance computing (HPC) facilities, present the need for mini-applications (miniapps) that capture essential algorithms used in large applications to test program performance and portability, aiding transitions to new systems. The COVID-19 pandemic has fueled a flurry of activity in computational drug discovery, including the use of supercomputers and GPU acceleration for massive virtual screens for therapeutics. Recent work targeting COVID-19 at the Oak Ridge Leadership Computing Facility (OLCF) used the GPU-accelerated program AutoDock-GPU to screen billions of compounds on the Summit supercomputer. In this paper we present the development of a new miniapp, miniAutoDock-GPU, that can be used to evaluate the performance and portability of GPU-accelerated protein-ligand docking programs on different computer architectures. These tests are especially relevant as facilities transition from petascale systems and prepare for upcoming exascale systems that will use a variety of GPU vendors. The key calculations, namely, the Lamarckian genetic algorithm combined with a local search using a Solis-Wets based random optimization algorithm, are implemented. We developed versions of the miniapp using several different programming models for GPU acceleration, including a version using the CUDA runtime API for NVIDIA GPUs, and the Kokkos middle-ware API which is facilitated by C++ template libraries. A third version, currently in progress, uses the HIP programming model. These efforts will help facilitate the transition to exascale systems for this important emerging HPC application, as well as its use on a wide range of heterogeneous platforms.

Thavappiragasam, Mathialakan↗

Mission Data System Java Edition Version 7

The Mission Data System framework defines closed-loop control system abstractions from State Analysis including interfaces for state variables, goals, estimators, and controllers that can be adapted to implement a goal-oriented control system. The framework further provides an execution environment that includes a goal scheduler, execution engine, and fault monitor that support the expression of goal network activity plans. Using these frameworks, adapters can build a goal-oriented control system where activity coordination is verified before execution begins (plan time), and continually during execution. Plan failures including violations of safety constraints expressed in the plan can be handled through automatic re-planning. This version optimizes a number of key interfaces and features to minimize dependencies, performance overhead, and improve reliability. Fault diagnosis and real-time projection capabilities are incorporated. This version enhances earlier versions primarily through optimizations and quality improvements that raise the technology readiness level. Goals explicitly constrain system states over explicit time intervals to eliminate ambiguity about intent, as compared to command-oriented control that only implies persistent intent until another command is sent. A goal network scheduling and verification process ensures that all goals in the plan are achievable before starting execution. Goal failures at runtime can be detected (including predicted failures) and handled by adapted response logic. Responses can include plan repairs (try an alternate tactic to achieve the same goal), goal shedding, ignoring the fault, cancelling the plan, or safing the system.

Reinholtz, William K.↗

GeoThermalCloud: Cloud Fusion of Big Data and Multi-Physics Models using Machine Learning for Discovery, Exploration, and Development of Hidden Geothermal Resources

The primary goals of this project are exploring hidden geothermal resources in the U.S.A. and designing profitable enhanced geothermal systems (EGS). Many processes and parameters control geothermal exploration and energy production from geothermal fields. Diverse datasets (e.g., geology, geochemistry, geophysics, satellite, airborne geophysics) are available to help characterize subsurface geothermal conditions. Sparse and multi-scale characteristics of these datasets prohibit properly leveraging these datasets for geothermal exploration and profitable EGS design. Recent advancements in machine learning (ML) promise to resolve these issues. The tremendous challenges and risks of geothermal exploration and production bring the demand for novel ML methods and tools that can (1) analyze large field datasets, (2) assimilate model simulations (large inputs and outputs), (3) process sparse datasets, (4) perform transfer learning (between sites with different exploratory levels), (5) extract hidden geothermal signatures in the field and simulation data, (6) label geothermal resources and processes, (7) identify high-value data acquisition targets, and (8) guide geothermal exploration and production by selecting optimal exploration, production, and drilling strategies. To address these necessities, ML-based geothermal resources exploration and enhanced geothermal systems (EGS) design tools have been developed. The exploration tool is called GeoThermalCloud and EGS design tool is called GeoDT-ML. GeoThermalCloud (https://github.com/SmartTensors/GeoThermalCloud.jl) utilizes a LANL unsupervised ML platform called SmartTensors (https://tensors.lanl.gov/) to automate data analyses and interpretations by extracting hidden signatures to identify geothermal prospects. Also, it enables the identification of critical measurements needed to identify geothermal resource signatures. Alternatively, GeoDT-ML (https://github.com/SmartTensors/GeoThermalCloud.jl/tree/master/EGS) is an ML-based alternative to GeoDT (https://github.com/GeoDesignTool/GeoDT.git), a fast, simplified multi-physics solver to evaluate EGS project designs in uncertain geologic systems. GeoDT-ML leverages recent advances in deep learning and high-performance computing. It is a faster and simpler version of GeoDT. To make this project a success, we used capabilities of LANL, PNNL, Google, Stanford, and Julia Computing. We analyzed eight datasets of the U.S.A. using GeothermalCloud and demonstrated potential highly prospective geothermal resources and identified key factors defining highly prospective sites. The first data set includes 44 locations in southwest New Mexico and 18 geological, hydrogeological, geophysical, geothermal, geochemical attributes. We defined low- and medium-temperature hydrothermal systems and discovered a new highly prospective site. The second data set analyzed 18 shallow water chemistry attributes at 14,342 locations in the Great Basin. It demarcated modestly, moderately, and highly prospective sites including key attributes for each type of prospectivity. The third data set analyzed Utah FORGE data including satellite (InSAR), geophysical (gravity, seismic), geochemical, and geothermal attributes. Here, we performed prospectivity analysis to identify future drilling locations using geological, geochemical, and geophysical attributes. Maps of temperature at depth and heat flow are constructed based on the available data. Prospectivity maps were generated, and drilling locations were proposed for future geothermal field exploration. The fourth data set analyzed 21 attributes at 120 locations in Tularosa Basin, New Mexico; data comes from past play fairway analyses in this region. ML analyses identified geothermal signatures associated with modestly, moderately, and highly hydrothermal systems. We also defined dominant attributes and spatial distribution of the geothermal signatures. The fifth, sixth, seventh, and eighth datasets include Tohatchi Springs, New Mexico, Hawaii, Brady site, Nevada, and EGS Collab, respectively. Moreover, we coupled GeothermalCloud and magnetotellurics data to pinpoint drilling locations for developing geothermal projects in the Tularosa Basin, New Mexico. GeothermalCloud found potential prospective locations for geothermal resources near White Sands Missile Range and McGregor Range at Fort Bliss. Magnetotellurics data determined the potential depth (~1800m) of geothermal prospects at McGregor Range based on apparent resistivity structures/layers in the subsurface. The McGregor Range consists of three resistivity layers and two resistivity structures. Magnetotellurics data also helps identify that the western portion of the McGregor Range has thick and low-resistivity earth materials. The low resistivity to the west is most likely for a fault system. Assuming temperature is consistent with a geothermal reservoir, the west-central part of the McGregor Range has the highest geothermal potential because of the increase in porosity and associated permeability attributed to the interpreted fault system. Also, we devised a coupling strategy between a process model and GeothermalCloud to characterize hydrogeological conditions and geothermal conditions, respectively. The process model characterizes hydrogeological and geothermal conditions on highly prospective geothermal sites provided by GeothermalCloud. We developed a physics-informed neural network (PINN) version of the Burns equation that can be easily coupled with GeothermalCloud. Furthermore, we performed an optimal design decision maximizing the economic value of an EGS power plant. This study optimized the range of well spacing between injection and production wells maximizing net present value in dollars (NPV). For this task, we used the GeoDT to simulate the Utah FORGE EGS development cycle from the initial well design to the end of production. Next, we accomplished another crucial task, which is predicting permeability of geothermal reservoirs. Predicting permeability of geothermal reservoirs is a non-trivial task because of huge computational runtime of simulation and lack of measurements. To avoid these limitations, we used easy-to-measure chemical concentrations in the subsurface as measurement data and convolutional neural network based ML model of a high-fidelity model. Next, we predicted permeability using Markov chain Monte Carlo simulation. We found that Markov chain Monte Carlo simulation predicts permeability with a high certainty if the prediction zone in the simulation area has chemical concentration data. Finally, we analyzed the DOE funded INGENIOUS and GeoDAWN projects data. For discovering hidden geothermal systems in the Great Basin, the INGENIOUS project accumulated old data, collected new data, and released them in 2022. The dataset includes a total of 24 geological, geophysical, and geochemical attributes. Data resolution and scale significantly vary prohibiting an appropriate usage. To avoid such limitations, we brought all data in the same resolution and scale by applying the inverse distance weighting interpolation technique for predicting data in unsampled locations. Subsequently, we analyzed LiDAR data of the GeoDAWN project. We received data in tiles format. The DOE’s overarching goal is to use ML on LiDAR data for finding favorable geological structures (e.g., step up faults in Brady, Nevada). To serve the purpose, we need to label favorable geologic structures that correspond to LiDAR data. We wrote an algorithm to label the LiDAR data with the favorable geologic structures.

15 GEOTHERMAL ENERGY↗

Robust Trajectory Optimization for NRHO Rendezvous Using SPICE Kernel Relative Motion

In this paper, robust optimization is performed on trajectory correction maneuvers during the lunar lander return phase of an Artemis mission, treating the trajectory from one hour after low lunar orbit departure to arrival in the vicinity of the lunar Gateway as a relative motion problem. To enable rapid stochastic optimization techniques requiring many candidate trajectories, SPICE kernel relative motion as implemented by the Quadratic Interpolated State Transition (QIST) system is used as the underlying dynamics propagation. The optimization is performed with a genetic optimizer using linear covariance (LinCov) software in a simplified operational context, taking into account the availability of navigation sensors with varying measurement models, ranges, and accuracies. No numerical integration is used, since the relative motion around Gateway is fully characterized with the a priori computation of the QIST coefficients. Maneuver placements are computed to optimize the minimum 3σ delta-v of the trajectory, the position dispersion at a target point, and a convex combination of these two metrics. An order of magnitude runtime improvement is provided over legacy methods with less than 10% error introduced. All QIST results are shown to be in-family with legacy methods. The tradespace for optimal delta-v design is found to range from 77.0 to 93.9 m/s, while the range of optimal dispersion is between 1.4 and 11.7 km.

Relative Motion↗

Rapid Evaluation and Response to Impacts on Critical End-Use Loads Following Natural Hazard-Driven Power Outages: A Modular and Responsive Geospatial Technology

The disparate nature of data for electric power utilities complicates the emergency recovery and response process. The reduced efficiency of response to natural hazards and disasters can extend the time that electrical service is not available for critical end-use loads, and in extreme events, leave the public without power for extended periods. This article presents a methodology for the development of a semantic data model for power systems and the integration of electrical grid topology, population, and electric distribution line reliability indices into a unified, cloud-based, serverless framework that supports power system operations in response to extreme events. An iterative and pragmatic approach to working with large and disparate datasets of different formats and types resulted in improved application runtime and efficiency, which is important to consider in real time decision-making processes during hurricanes and similar catastrophic events. This technology was developed initially for Puerto Rico, following extreme hurricane and earthquake events in 2017 and 2020, but is applicable to utilities around the world. Given the highly abstract and modular design approach, this technology is equally applicable to any geographic region and similar natural hazard events. In addition to a review of the requirements, development, and deployment of this framework, technical aspects related to application performance and response time are highlighted.

24 POWER TRANSMISSION AND DISTRIBUTION↗

Utilizing GPUs to Accelerate Turbomachinery CFD Codes

GPU computing has established itself as a way to accelerate parallel codes in the high performance computing world. This work focuses on speeding up APNASA, a legacy CFD code used at NASA Glenn Research Center, while also drawing conclusions about the nature of GPU computing and the requirements to make GPGPU worthwhile on legacy codes. Rewriting and restructuring of the source code was avoided to limit the introduction of new bugs. The code was profiled and investigated for parallelization potential, then OpenACC directives were used to indicate parallel parts of the code. The use of OpenACC directives was not able to reduce the runtime of APNASA on either the NVIDIA Tesla discrete graphics card, or the AMD accelerated processing unit. Additionally, it was found that in order to justify the use of GPGPU, the amount of parallel work being done within a kernel would have to greatly exceed the work being done by any one portion of the APNASA code. It was determined that in order for an application like APNASA to be accelerated on the GPU, it should not be modular in nature, and the parallel portions of the code must contain a large portion of the code's computation time.

computer programming↗

Actor-based Runtime Verification with MESA

This work presents a runtime verification approach implemented in the tool MESA (MEssage-based System Analysis) which allows for using concurrent monitors to check for properties specified in data parameterized temporal logic and state machines. The tool is implemented as an internal Scala DSL. We employ the actor programming model to implement MESA where monitors are captured by concurrent actors that communicate via messaging. The paper presents a case study in which MESA is used to effectively monitor a large number of flights from live US airspace data streams. We also perform an empirical study by conducting experiments using monitoring systems with different num- bers of concurrent monitors and different layers of indexing on the data contained in events. The paper describes the experiments, evaluates the results, and discusses challenges faced during the study. The evaluation shows the value of combining concurrency with indexing to handle data rich events.

Mehlitz, Peter↗

DARMA-EMPIRE Integration and Performance Assessment – Interim Report

We begin by presenting an overview of the general philosophy that is guiding the novel DARMA developments, followed by a brief reminder about the background of this project. We finally present the FY19 design requirements. As the Exascale era arises, DARMA is uniquely positioned at the forefront of asychronous many-task (AMT) research and development (R&D) to explore emerging programming model paradigms for next-generation HPC applications at Sandia, across NNSA labs, and beyond. The DARMA project explores how to fundamentally shift the expression(PM) and execution(EM)of massively concurrent HPC scientific algorithms to be more asynchronous, resilient to executional aberrations in heterogeneous/unpredictable environments, and data-dependency conscious—thereby enabling an intelligent, dynamic, and self-aware runtime to guide execution.

97 MATHEMATICS AND COMPUTING↗

Towards Real-time, On-board, Hardware-Supported Sensor and Software Health Management for Unmanned Aerial Systems

Unmanned aerial systems (UASs) can only be deployed if they can effectively complete their missions and respond to failures and uncertain environmental conditions while maintaining safety with respect to other aircraft as well as humans and property on the ground. In this paper, we design a real-time, on-board system health management (SHM) capability to continuously monitor sensors, software, and hardware components for detection and diagnosis of failures and violations of safety or performance rules during the flight of a UAS. Our approach to SHM is three-pronged, providing: (1) real-time monitoring of sensor and/or software signals; (2) signal analysis, preprocessing, and advanced on the- fly temporal and Bayesian probabilistic fault diagnosis; (3) an unobtrusive, lightweight, read-only, low-power realization using Field Programmable Gate Arrays (FPGAs) that avoids overburdening limited computing resources or costly re-certification of flight software due to instrumentation. Our implementation provides a novel approach of combining modular building blocks, integrating responsive runtime monitoring of temporal logic system safety requirements with model-based diagnosis and Bayesian network-based probabilistic analysis. We demonstrate this approach using actual data from the NASA Swift UAS, an experimental all-electric aircraft.

System & Software Health Management↗

Network packet templating for GPU-initiated communication

Systems, apparatuses, and methods for performing network packet templating for graphics processing unit (GPU)-initiated communication are disclosed. A central processing unit (CPU) creates a network packet according to a template and populates a first subset of fields of the network packet with static data. Next, the CPU stores the network packet in a memory. A GPU initiates execution of a kernel and detects a network communication request within the kernel and prior to the kernel completing execution. Responsive to this determination, the GPU populates a second subset of fields of the network packet with runtime data. Then, the GPU generates a notification that the network packet is ready to be processed. A network interface controller (NIC) processes the network packet using data retrieved from the first subset of fields and from the second subset of fields responsive to detecting the notification.

97 MATHEMATICS AND COMPUTING↗