Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Parallel Architectures”

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.

1,635 records · Page 91

Fast GPU 3D diffeomorphic image registration

3D image registration is one of the most fundamental and computationally expensive operations in medical image analysis. Here, we present a mixed-precision, Gauss–Newton–Krylov solver for diffeomorphic registration of two images. Our work extends the publicly available CLAIRE library to GPU architectures. Despite the importance of image registration, only a few implementations of large deformation diffeomorphic registration packages support GPUs. Our contributions are new algorithms to significantly reduce the run time of the two main computational kernels in CLAIRE: calculation of derivatives and scattered-data interpolation. Additionally, we deploy (i) highly-optimized, mixed-precision GPU-kernels for the evaluation of scattered-data interpolation, (ii) replace Fast-Fourier-Transform (FFT)-based first-order derivatives with optimized 8th-order finite differences, and (iii) compare with state-of-the-art CPU and GPU implementations. As a highlight, we demonstrate that we can register clinical images in less than 6 s on a single NVIDIA Tesla V100. This amounts to over 20 speed-up over the current version of CLAIRE and over 30 speed-up over existing GPU implementations.

97 MATHEMATICS AND COMPUTING↗

Locality-Aware Scheduling for Scalable Heterogeneous Environments

Heterogeneous computing promise boost performance of scientific applications by allowing massively parallel execution of computational tasks. However, manually managing extremely heterogeneous, multi-device systems is complicated and may result in sub-optimal performance. Specifically, data management is an extremely challenging problem on multi-device systems. In this work, we introduce two locality-aware schedulers for the Minos Computing Library (MCL), an asynchronous, task-based programming model and runtime for extremely heterogeneous systems. The first scheduler implements a pure locality-aware algorithm to maximize data reuse, though it might incur in ”hot-spots” that limit system utilization. The second scheduler mitigates this drawback by dynamically targeting between locality-awareness and system utilization based on the current workload and available computing devices. Our results show that locality-awareness greatly benefit applications that exhibit data reuse, providing up to 6.9x and 7.9x over the original MCL scheduler and equivalent OpenCL implementations, respectively. Moreover, our schedulers introduce negligible overhead compared with the original MCL scheduler and achieve similar performance for applications that don’t benefit from data locality.

Architecture, co-design, Task-based programming mo↗

Macromolecular differentiation of Golgi stacks in root tips of Arabidopsis and Nicotiana seedlings as visualized in high pressure frozen and freeze-substituted samples

The plant root tip represents a fascinating model system for studying changes in Golgi stack architecture associated with the developmental progression of meristematic cells to gravity sensing columella cells, and finally to "young" and "old", polysaccharide-slime secreting peripheral cells. To this end we have used high pressure freezing in conjunction with freeze-substitution techniques to follow developmental changes in the macromolecular organization of Golgi stacks in root tips of Arabidopsis and Nicotiana. Due to the much improved structural preservation of all cells under investigation, our electron micrographs reveal both several novel structural features common to all Golgi stacks, as well as characteristic differences in morphology between Golgi stacks of different cell types. Common to all Golgi stacks are clear and discrete differences in staining patterns and width of cis, medial and trans cisternae. Cis cisternae have the widest lumina (approximately 30 nm) and are the least stained. Medial cisternae are narrower (approximately 20 nm) and filled with more darkly staining products. Most trans cisternae possess a completely collapsed lumen in their central domain, giving rise to a 4-6 nm wide dark line in cross-sectional views. Numerous vesicles associated with the cisternal margins carry a non-clathrin type of coat. A trans Golgi network with clathrin coated vesicles is associated with all Golgi stacks except those of old peripheral cells. It is easily distinguished from trans cisternae by its blebbing morphology and staining pattern. The zone of ribosome exclusion includes both the Golgi stack and the trans Golgi network. Intercisternal elements are located exclusively between trans cisternae of columella and peripheral cells, but not meristematic cells. In older peripheral cells only trans cisternae exhibit slime-related staining. Golgi stacks possessing intercisternal elements also contain parallel rows of freeze-fracture particles in their trans cisternal membranes. We propose that intercisternal elements serve as anchors of enzyme complexes involved in the synthesis of polysaccharide slime molecules to prevent the complexes from being dragged into the forming secretory vesicles by the very large slime molecules. In addition, we draw attention to the similarities in composition and apparent site of synthesis of xyloglucans and slime molecules.

NASA Program Space Biology↗

Efficacy of Code Optimization on Cache-based Processors

The current common wisdom in the U.S. is that the powerful, cost-effective supercomputers of tomorrow will be based on commodity (RISC) micro-processors with cache memories. Already, most distributed systems in the world use such hardware as building blocks. This shift away from vector supercomputers and towards cache-based systems has brought about a change in programming paradigm, even when ignoring issues of parallelism. Vector machines require inner-loop independence and regular, non-pathological memory strides (usually this means: non-power-of-two strides) to allow efficient vectorization of array operations. Cache-based systems require spatial and temporal locality of data, so that data once read from main memory and stored in high-speed cache memory is used optimally before being written back to main memory. This means that the most cache-friendly array operations are those that feature zero or unit stride, so that each unit of data read from main memory (a cache line) contains information for the next iteration in the loop. Moreover, loops ought to be 'fat', meaning that as many operations as possible are performed on cache data-provided instruction caches do not overflow and enough registers are available. If unit stride is not possible, for example because of some data dependency, then care must be taken to avoid pathological strides, just ads on vector computers. For cache-based systems the issues are more complex, due to the effects of associativity and of non-unit block (cache line) size. But there is more to the story. Most modern micro-processors are superscalar, which means that they can issue several (arithmetic) instructions per clock cycle, provided that there are enough independent instructions in the loop body. This is another argument for providing fat loop bodies. With these restrictions, it appears fairly straightforward to produce code that will run efficiently on any cache-based system. It can be argued that although some of the important computational algorithms employed at NASA Ames require different programming styles on vector machines and cache-based machines, respectively, neither architecture class appeared to be favored by particular algorithms in principle. Practice tells us that the situation is more complicated. This report presents observations and some analysis of performance tuning for cache-based systems. We point out several counterintuitive results that serve as a cautionary reminder that memory accesses are not the only factors that determine performance, and that within the class of cache-based systems, significant differences exist.

VanderWijngaart, Rob F.↗

Utilizing Gaps and Key Performance Parameters to Inform NASA Environmental Control and Life Support and Human Health and Performance Capability Technology Decisions

Human spaceflight is a complex endeavor requiring multiple capabilities for transportation, crew health, scientific goals, and safe return to Earth. The difference between spaceflight proven capabilities and those needed for future exploration architectures is defined as a capability gap. Capability gaps are not technology specific. Each capability gap is approachable with a wide array of technologies that have unique benefits and challenges. Determining what a capability’s relevant and distinguishing key performance parameters (KPPs) are for a mission is critical. Mass, power, and volume are always constrained and important, but defining these in a way normalized by performance is challenging. Additionally, KPP definition for reliability, dormancy, and integration needs are very important and still evolving. This paper provides the approach of the Environmental Control and Life Support – Crew Health and Performance (ECLSS-CHP) System Capability Leadership Team (SCLT) has used to define gaps and KPPs in support of the NASA’s Capabilities Integration Team data call objectives. The nine ECLSS-CHP capability areas are decomposed to capabilities with ~76 gaps and supported with KPPs. Rather than defining very detailed gaps, ECLSS-CHP defines high-level gaps to be technology agnostic. Within a gap, detailed KPPs are defined to both compare technologies and measure progress within a technology over time. Ideally, KPPs are clearly defined, widely communicated both internally and externally, and provide a common nomenclature to describe the state of the art and the degree of improvement required for exploration missions. KPPs help define when the gap is closed, and the core mission objectives can be accomplished. Further technology improvements to enhance the capability, as measured by improved KPPs, must then be weighed against investments in open capability gaps that prevent NASA from achieving its exploration missions. It is uncommon that a technology maturation to improve all the relevant KPPs simultaneously but using KPPs is a critical technology investment decision making component. In addition to traditional technology selections, KPPs are informing how investments in ground testing prior to and in parallel with ISS technology demonstrations are required to improve reliability KPPs. The collection of all major technology activities within a capability area are captured on technology roadmaps to communicate how diverse program activities are coordinated to close gaps and infuse into exploration mission needs. A selection of ECLSS-CHP gaps and KPPs and their formulation, current state, and how they inform capability roadmap planning are discussed.

Life Support↗

Distributed out-of-memory NMF on CPU/GPU architectures

We propose an efficient distributed out-of-memory implementation of the non-negative matrix factorization (NMF) algorithm for heterogeneous high-performance-computing systems. The proposed implementation is based on prior work on NMFk, which can perform automatic model selection and extract latent variables and patterns from data. In this work, we extend NMFk by adding support for dense and sparse matrix operation on multi-node, multi-GPU systems. The resulting algorithm is optimized for out-of-memory problems where the memory required to factorize a given matrix is greater than the available GPU memory. Memory complexity is reduced by batching/tiling strategies, and sparse and dense matrix operations are significantly accelerated with GPU cores (or tensor cores when available). Input/output latency associated with batch copies between host and device is hidden using CUDA streams to overlap data transfers and compute asynchronously, and latency associated with collective communications (both intra-node and inter-node) is reduced using optimized NVIDIA Collective Communication Library (NCCL) based communicators. Benchmark results show significant improvement, from 32X to 76x speedup, with the new implementation using GPUs over the CPU-based NMFk. Good weak scaling was demonstrated on up to 4096 multi-GPU cluster nodes with approximately 25,000 GPUs when decomposing a dense 340 Terabyte-size matrix and an 11 Exabyte-size sparse matrix of density 10 -6 .

97 MATHEMATICS AND COMPUTING↗

Web Exploration Tools for a Fast Federated Optical Survey Database

We implemented several new web-based tools to improve the efficiency and versatility of access to the APS Catalog of the POSS I (Palomar Observatory-National Geographic Sky Survey) and its associated image database. The most important addition was a federated database system to link the APS Catalog and image database into one Internet-accessible database. With the FDBS, the queries and transactions on the integrated database are performed as if it were a single database. We installed Myriad the FDBS developed by Professor Jaideep Srivastava and members of his group in the University of Minnesota Computer Science Department. It is the first system to provide schema integration, query processing and optimization, and transaction management capabilities in a single framework. The attached figure illustrates the Myriad architecture. The FDBS permits horizontal access to the data, not just vertical. For example, for the APS, queries can be made not only by sky position, but also by any parameter present in either of the databases. APS users will be able to produce an image of all the blue galaxies and stellar sources for comparison with x-ray source error ellipses from AXAF (X Ray Astrophysics Facility) (Chandra) for example. The FDBS is now available as a beta release with the appropriate query forms at our web site. While much of our time was occupied with adapting Myriad to the APS environment, we also made major changes in Star Base, our DBMS for the Catalog, at the web interface to improve its efficiency for issuing and processing queries. Star Base is now three times faster for large queries. Improvements were also made at the web end of the image database for faster access; although work still needs to be done to the image database itself for more efficient return with the FDBS. During the past few years, we made several improvements to the database pipeline that creates the individual plate databases queries by StarBase. The changes include improved positions especially for galaxies, using a new median centroider and integrated magnitudes for galaxies with an improved density-to-intensity calibration with a "sky" background subtraction. In the original version of StarBase the object classification fainter than 19.5-20.0 mag., was an extrapolation of the networks trained on brighter objects. We have used a new catalog of galaxies at the NGP to train a neural network on objects fainter than 20th mag. This improved classification is used in the new version of StarBase. We have also added a FITS table option for the returned data from queries on the object catalog. The APS image database includes images in both colors so we have added a tool for querying the image database in both colors simultaneously. The images can be displayed in parallel or blinked for comparison.

Humphreys, Roberta M.↗

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗

Small Fast Spectrum Reactor Designs Suitable for Direct Nuclear Thermal Propulsion

Advancement of U.S. scientific, security, and economic interests through a robust space exploration program requires high performance propulsion systems to support a variety of robotic and crewed missions beyond low Earth orbit. Past studies, in particular those in support of the Space Exploration Initiative (SEI), have shown nuclear thermal propulsion systems provide superior performance for high mass high propulsive delta-V missions. The recent NASA Design Reference Architecture (DRA) 5.0 Study re-examined mission, payload, and transportation system requirements for a human Mars landing mission in the post-2030 timeframe. Nuclear thermal propulsion was again identified as the preferred in-space transportation system. A common nuclear thermal propulsion stage with three 25,000-lbf thrust engines was used for all primary mission maneuvers. Moderately lower thrust engines may also have important roles. In particular, lower thrust engine designs demonstrating the critical technologies that are directly extensible to other thrust levels are attractive from a ground testing perspective. An extensive nuclear thermal rocket technology development effort was conducted from 1955-1973 under the Rover/NERVA Program. Both graphite and refractory metal alloy fuel types were pursued. Reactors and engines employing graphite based fuels were designed, built and ground tested. A number of fast spectrum reactor and engine designs employing refractory metal alloy fuel types were proposed and designed, but none were built. The Small Nuclear Rocket Engine (SNRE) was the last engine design studied by the Los Alamos National Laboratory during the program. At the time, this engine was a state-of-the-art graphite based fuel design incorporating lessons learned from the very successful technology development program. The SNRE was a nominal 16,000-lbf thrust engine originally intended for unmanned applications with relatively short engine operations and the engine and stage design were constrained to fit within the payload volume of the then planned space shuttle. The SNRE core design utilized hexagonal fuel elements and hexagonal structural support elements. The total number of elements can be varied to achieve engine designs of higher or lower thrust levels. Some variation in the ratio of fuel elements to structural elements is also possible. Options for SNRE-based engine designs in the 25,000-lbf thrust range were described in a recent (2010) Joint Propulsion Conference paper. The reported designs met or exceeded the performance characteristics baselined in the DRA 5.0 Study. Lower thrust SNRE-based designs were also described in a recent (2011) Joint Propulsion Conference paper. Recent activities have included parallel evaluation and design efforts on fast spectrum engines employing refractory metal alloy fuels. These efforts include evaluation of both heritage designs from the Argonne National Laboratory (ANL) and General Electric Company GE-710 Programs as well as more recent designs. Results are presented for a number of not-yet optimized fast spectrum engine options.

Schnitzler, Bruce G.↗

Overview of NASA ISRU Plans, Priorites, and Activities

Introduction:The National Aeronautics andSpace Administration (NASA) of the United States ofAmerica (US) has initiated the Artemis Moon to Marsprogram to send astronauts (the first woman andperson of color) back to the lunar surface, create asustainable human lunar exploration program, andlead the first human exploration mission to the Marssurface in the 2030’s [1]. A major objective of thisprogram is to characterize the resources that exist onthe Moon and Mars, and learn how to utilize them forsustained and affordable exploration. Commonlyknown as In Situ Resource Utilization (ISRU), thesearch for, acquisition, and processing of resources inspace has the potential to greatly reduce thedependency on transporting mission consumables andinfrastructure from Earth, thereby reducing missioncosts, risks, and dependency on Earth.ISRU is Enabling: Through the extraction andprocessing of resources into mission commoditiessuch as rocket propellants, life support consumables,and fuel cell reactants, ISRU enhances and evolvesthe cis-lunar, lander, and surface transportationsystems required for human exploration; expandingand enhancing HOW humans can explore and returnfrom the Moon. Through the extraction andprocessing of resources into metals, silicon, and othermanufacturing and construction feedstock, ISRUenhances and allows for the expansion of criticalinfrastructure using in situ manufacturing andconstruction capabilities that influence WHAT humanscan do on the Moon and in cis-lunar space. Becauseof this, ISRU supports and enables commercialinvolvement beyond NASA and governmentalagencies by both lowering the cost of sustainedtransportation to/from/on the Moon as well assupporting the market required for needing thesetransportation systems. Strategic Framework:To achieve this vision,NASA’s Space Technology Mission Directorate(STMD) ensures the coordinated development ofISRU and other critical space and surfaceinfrastructure elements such as propulsion, power,manufacturing, construction, and robotics through theStrategic Technology Architecture Roundtable(STAR) process. Through STAR, an integratedframework and process has been created allowing forcapabilities and technologies to be linked andassessed, gaps to be identified, specifications andmetrics to be established, and provide a means toprioritize and implement technology development andmissions. A critical part of the STAR effort has beenthe establishment of the Strategic Framework thatorganizes all work under four major Thrusts (Go,Land, Live, and Explore) and identifies the drivingOutcomes for each of these Thrusts. From the Thrustsand Outcomes, all work can be categorized and linkedbetween Capability Areas, and Technology Gaps canbe identified and addressed (Figure 1.)Figure 1. Strategic Framework and STAR FrameworkISRU Envisioned Future: To drive thedevelopment of technologies and capabilities, theSTAR process starts with establishing a ‘grand vision’of where each Outcome and Capability is aiming tobe considered complete. For ISRU, the EnvisionedFuture is “Scalable ISRU production/utilizationcapabilities including sustainable commodities on thelunar and Mars Surface”. This involves starting with10’s of metric tons of products, but evolves into 100’sto 1000’s of metric tons of water, oxygen, propellants,construction and manufacturing feedstock, andcommodities for habitat and food production andoperations. For ISRU, the ‘Prospect to Product’philosophy starts with Destination Reconnaissance &Resource Assessment, followed by ResourceAcquisition, Isolation, and Preparation, leading intoResource Processing (which is further subdivided intomission consumables and feedstocks for constructionand manufacturing). The ISRU Envisioned Futurealso considers what resources are available andattempts to address what and when these resourceswill be evaluated and harnessed, as well asconsidering which products/commodities can beobtained for early use and which ones require moretime and/or users of refined products.It Takes an Architecture: ISRU does not existon its own. By definition, it requires customers/users SHORT TITLE HERE: A. B. Author and C. D. Authorto use the products/commodities produced by ISRUsystems. Also, for an ISRU capability to exist, itmust obtain products and services from other systemsand infrastructure. An important aspect of the STARprocess and the ISRU Envisioned Futures Prioritiesstrategy is to identify and link all of these systems andcapabilities to achieve the desired end state (Figure2).Figure 2. ISRU as Part of a Larger ArchitectureISRU Capability Drivers: The guidingprinciples for NASA’s Space TechnologyDevelopment for Artemis are to develop criticaltechnologies and capabilities that enable (i) asustainable Lunar surface presence, (ii) the future goalof sending humans to Mars, and (iii) promotingcritical technologies to enable future science andcommercial missions. It is a major goal of theArtemis campaign to establish some sort of base campat the lunar South Pole by approximately the end ofthe decade. The ISRU Envisioned Futures Prioritiesstrategy is aligned with the Artemis campaign todevelop and demonstrate ISRU capabilities in thistimeframe that could lead to sustained surfaceoperations, infrastructure growth, and commercialoperations in the next decade (Figure 3).Figure 3. ISRU Dual Path to Full Implementation and CommercializationState of the Art and Gaps: To achieve theenvisioned future, an extensive effort was performedto understand the State of the Art (SOA) for ISRUgoing back decades, and to assess the SOA against thenear and long-term goals and objectives of the ISRUStrategic Outcome objectives. While the releasedISRU Envisioned Futures Priorities only includes atop-level definition of both the SOA and Gaps, furtherinformation on these for ISRU can be found in theISRU Gap Assessment Study performed for theInternational Space Exploration Coordination Group(ISECG) [2]. To provide further guidance to industryand academia, a top level assessment was performedand provide that divides critical areas of ISRUcapabilities and technologies into 3 categories:Significant Funding, Partially Covered/MoreRequired, and Limited/No Funded Activities.Envisioned Future Priorities- Next Steps forISRU: While a significant amount of work over abroad range of technology areas has been performedover the last several years for lunar ISRU, to reach theenvisioned future for ISRU, a lot more work isrequired at the technology level leading to bothsystems and technology demonstrations in the nearfuture. To guide investments within NASA, industry,and academia, 5 specific areas of high priority wereidentified. These are:1.Complete development of the Water and Oxygen Mining Paths and close technology gaps, with emphasis on oxygen extraction from Highland regolith and parallel paths for polar water mining.2.Expand development of metal extraction and feedstock for manufacturing and construction, with emphasis on aluminum and initial/easy to obtain/make construction feedstocks leading to more refined metals and other regolith resources. Also, evaluate biologically inspired/derived technologies in bio-mining, bio-plastic, and other feedstock commodities.3.Ensure the resource assessment needed for future ISRU commercial operations is coordinated with both near/long-term science objectives as well as Artemis mission locations of interest.4.Initiate NASA and industry-led system-level analyses, integration, and testing activities for ISRU capabilities. While significant work has been performed at the technology and subsystemlevel, it is now important to understand how these technology investments can be leveraged and utilized in actual systems and applications5.Initiate lunar ISRU technology flight demonstrations leading to initial ‘Pilot Plant’ end-to-end production capability demonstrations, led by industry

ISRU↗

HydraGNN_Predictive_GFM_2026 - Ensemble of predictive graph foundation models for atomistic materials modeling

This release contains data and parameters of HydraGNN-based graph foundation models trained as a result of the work published in the pre-print "Exascale Multi-Task Graph Foundation Models for Imbalanced, Multi-Fidelity Atomistic Data" by M. Lupo Pasini et al. (https://arxiv.org/abs/2604.15380). We jointly train on 16 open first-principles datasets (544+ million structures covering 85+ elements) using a multi-task architecture with per-dataset heads and a scalable ADIOS2/DDStore data pipeline. On Frontier, we execute six large-scale DeepHyper hyperparameter optimization campaigns in FP64 and promote the top-performing message-passing models to sustained 2,048-node training, yielding a PaiNN-based lead model. The version of HydraGNN used to generate the outputs provided in this release is HydraGNN v5.0 (https://github.com/ORNL/HydraGNN/releases/tag/v5.0) The list of datasets used for the training of the graph foundation model is the following: 1) Alexandria [1] 2) ANI1x [2] 3) MPTrj [3] 4) Open Catalyst 2020 (OC20) [4] 5) Open Catalyst 2022 (OC22) [5] 6) Open Catalyst 2025 (OC25) [6] 7) Open Direct ir Capture 2023 (ODAC23) [7] 8) Open Materials 2024 (OMat24) [8] 9) Open Molecules 2025 (OMol25) [9] 10) OMol25-neutral (subset of OMol25 that contains only molecules with zero total charge) 11) OMol25-non-neutral (subset of OMol25 that contains only molecules with non-zero total charge) 12) Open Polymers 2026 (OPoly2026) [10] 13) Nabla2DFT [11] 14) QCML [12] 15) QM7X [reference 13] 16) transition1x [14] Dataset references: [1] J. Schmidt et al., “A dataset of 175k stable and metastable materials calculated with the PBEsol and SCAN functionals,” Scientific Data, vol. 9, p. 64, 2022. [2] J. S. Smith et al., “The ANI-1ccx and ANI-1x data sets, coupled-cluster and density functional theory properties for molecules,” Scientific Data, vol. 7, p. 134, 2020. [Online]. Available: https: //www.nature.com/articles/s41597-020-0473-z [3] A. Jain et al., “Commentary: The Materials Project: A materials genome approach to accelerating materials innovation,” APL Materials, vol. 1, no. 1, p. 011002, 07 2013. [Online]. Available: https://doi.org/10.1063/1.4812323 [4] L. Chanussot et al., “Open catalyst 2020 (oc20) dataset and community challenges,” ACS Catalysis, vol. 11, no. 10, pp. 6059–6072, 2021. [Online]. Available: https://doi.org/10.1021/acscatal.0c04525 [5] K. Tran et al., “Open catalyst 2022 (oc22) dataset and challenges for oxidation electrocatalysts,” ACS Catalysis, vol. 13, no. 5, pp. 3066–3084, 2023. [Online]. Available: https://doi.org/10.1021/acscatal.2c05426 [6] S. J. Sahoo et al., “The open catalyst 2025 (oc25) dataset and models for solid-liquid interfaces,” arXiv preprint arXiv:2509.17862, 2025. [Online]. Available: https://arxiv.org/abs/2509.17862 [7] A. Sriram et al., “The open DAC 2023 dataset and challenges for sorbent discovery in direct air capture,” ACS Central Science, vol. 10, no. 5, pp. 923–941, 2024. [8] L. Barroso-Luque et al., “Open materials 2024 (omat24) inorganic materials dataset and models,” 2024. [Online]. Available: https://arxiv.org/abs/2410.12771 [9] D. S. Levine et al., “The open molecules 2025 (OMol25) dataset, evaluations, and models,” 2025. [Online]. Available: https://arxiv.org/abs/2505.08762 [10] D. S. Levine et al., The open polymers 2026 (OPoly26) dataset and evaluations,” arXiv preprint arXiv:2512.23117, 2025. [Online]. Available: https://arxiv.org/abs/2512.23117 [11] K. Khrabrov et al., “Nabla2dft: A universal quantum chemistry dataset of drug-like molecules and a benchmark for neural network potentials,” in NeurIPS 2024 Datasets and Benchmarks Track, 2024. [Online]. Available: https://openreview.net/forum?id=ElUrNM9U8c [12] S. Ganscha et al., “The QCML dataset, quantum chemistry reference data from 33.5M DFT and 14.7B semi-empirical calculations,” Scientific Data, vol. 12, p. 406, 2025. [13] J. Hoja et al., “QM7-X, a comprehensive dataset of quantum-mechanical properties spanning the chemical space of small organic molecules,” Scientific Data, vol. 8, p. 43, 2021. [Online]. Available: https://www.nature.com/articles/s41597-021-00812-2 [14] M. Schreiner et al., “Transition1x - a dataset for building generalizable reactive machine learning potentials,” Scientific Data, vol. 9, p. 779, 2022. The folder "datasets_ADIOS2_format" contains the set of pre-processed datasets in Adaptable I/O System (ADIOS) format (https://www.exascaleproject.org/research-project/adios/) that have been used for the development and training of GFMs in this work. The "datasets_ADIOS2_format" directory contains 2 sub-directories, one for the version "v1" of the datasets and one for the version "v2" of the datasets. The version "v1" of the datasets provides values of the total energy as they are extracted from the original data as it was released by the respective institutions. The version "v2" of the datasets provides values of the energy that have been realigned. The realignment was performed by training a linear regression model that predicts the total energy as a function of the chemical composition of the atomistic structure, and then subtract such prediction from the original value of the total energy. Both folders "v1" and "v2" contain 16 sub-directories, each corresponding to an ADIOS2-formatted dataset The folder "DeepHyper-results" contains the configurational files and model's parameters for all the 186 HPO trials that were successfully completed by the scalable hyperparameter optimization (HPO) runs on Frontier. The content of the folder "DeepHyper-results" I structured as follows: 1) task-list.txt: list of mpnn name, jobid, and deephyper task id 2) gfm_${MPNN}_${JOBID}_0.${TASKID}: run directory with checkpoint files 3) gfm_${MPNN}: deephyper summary directory (*.csv) for each specific MPNN type 4) deephyper-experiment-${JOBID}: output and error logs for each job The file "deephyper-sorted.csv" contains the details of each HydraGNN model built and tested by HPO, obtained by merging the (*.csv) filed from each HPO run executed. Out of all the HPO trials, we selected 10 to continue the training of the respective HydraGNN models. Due to limited computational budget available in the LRN070 allocation we could not complete the training till convergence for all these 10 selected models. The folder "models" contains multiple sub-folders, one per each HydraGNN model trained. Each model sub-folder contains the parameters of each HydraGNN model, with multiple checkpoint-restarts. The list of sub-folders are as follows: 1) multidataset_hpo-BEST1-fp64 2) multidataset_hpo-BEST2-fp64 3) multidataset_hpo-BEST3-fp64 4) multidataset_hpo-BEST4-fp64 5) multidataset_hpo-BEST5-fp64 6) multidataset_hpo-BEST6-fp64 7) multidataset_hpo-BEST7-fp64 8) multidataset_hpo-BEST8-fp64 9) multidataset_hpo-BEST9-fp64 10) multidataset_hpo-BEST10-fp64 Within each one of these folders, additional auxiliary log files are provided with descriptions about how the training proceeded. The lead PaiNN-model is contained inside "multidataset_hpo-BEST6-fp64". The file "mlp_branch_weights" contains the parameters of the multi-layer perceptron (MLP) used to reconcile the predictions of the 16 output decoding heads of the HydragNN architectures. The MLP takes in input the chemical composition of the atomistic structure and predicts averaging weights to linearly mix the predictions of each output decoding head toward consolidating them into a single one. The folder "1.1billion-structure-inference" contains 1.1 billion atomistic structures randomly generated. Each structures is associated with energy and forces predicted with the lead-PaiNN model combined with the MLP model for reconciliation of the multi-branch predictions generated by the 16 output decoding heads. The folder "1.1billion-structure-inference" contains 9,300 (*.tar.gz) subdirectories, one per Frontier compute node used to execute the inference at exascale. Once uncompressed, each (*.tar.gz) subdirectory contains an ADIOS2 (*.bp) file container, where each atomistic structure is stored as a PyTorch-Geometric Data object. The file "export_dataset_environment_variables.sh" contains the environment variables that need to be set before running the HydraGNN code to reproduce the results provided in this dataset release. The code that can be used to load the ADIOS2 files, load HydraGNN models, and run inference is available at: https://github.com/ORNL/HydraGNN/releases/tag/v5.0

36 MATERIALS SCIENCE↗

Hybrid PDES Simulation of HPC Networks Using Zombie Packets

Although high-fidelity network simulations have proven to be reliable and cost-effective tools to peer into architectural questions for high-performance computing (HPC) networks, they incur a high resource cost. The time spent in simulating a single millisecond of network traffic in the highest detail can take hours, even for static, well-behaved traffic patterns such as uniform random. Surrogate models offer a significant reduction in runtime, yet they cannot serve as complete replacements and should only be used when appropriate. Thus, there is a need for hybrid modeling, where high-fidelity simulation and surrogates run side-by-side. Here, we present a surrogate model for HPC networks in which: packets bypass the network, while the network state is left untouched, i.e., suspended. To bypass the network, we use historical data to estimate the arrival time at which every packet should be scheduled at; to suspend the network, all in-flight packets are scheduled to arrive at their destinations, and are kept in the system to awaken as zombies when switching back to high-fidelity. Speedup for a hybrid model is relative to the proportion of surrogate to high-fidelity. This light-weight surrogate obtained up to 76× speedup. Keeping the zombies in the network showed an increase in the accuracy of the high-fidelity simulation on restart when compared to restarting the network from an empty state.

HPC networks↗

Track reconstruction as a service for collider physics

Optimizing charged-particle track reconstruction algorithms is crucial for efficient event reconstruction in Large Hadron Collider (LHC) experiments due to their significant computational demands. Existing track reconstruction algorithms have been adapted to run on massively parallel coprocessors, such as graphics processing units (GPUs), to reduce processing time. Nevertheless, challenges remain in fully harnessing the computational capacity of coprocessors in a scalable and non-disruptive manner. This paper proposes an inference-as-a-service approach for particle tracking in high energy physics experiments. To evaluate the efficacy of this approach, two distinct tracking algorithms are tested: Patatrack, a rule-based algorithm, and Exa.TrkX, a machine learning-based algorithm. The as-a-service implementations show enhanced GPU utilization and can process requests from multiple CPU cores concurrently without increasing per-request latency. The impact of data transfer is minimal and insignificant compared to running on local coprocessors. This approach greatly improves the computational efficiency of charged particle tracking, providing a solution to the computing challenges anticipated in the High-Luminosity LHC era.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

Scalable Pattern Matching in Metadata Graphs via Constraint Checking

Pattern matching is a fundamental tool for answering complex graph queries. Unfortunately, existing solutions have limited capabilities: They do not scale to process large graphs and/or support only a restricted set of search templates or usage scenarios. Moreover, the algorithms at the core of the existing techniques are not suitable for today’s graph processing infrastructures relying on horizontal scalability and shared-nothing clusters, as most of these algorithms are inherently sequential and difficult to parallelize. In this article we present an algorithmic pipeline that bases pattern matching on constraint checking. The key intuition is that each vertex and edge participating in a match has to meet a set of constraints implicitly specified by the search template. These constraints can be verified independently and typically are less expensive to compute than searching the full template. The pipeline we propose generates these constraints and iterates over them to eliminate all the vertices and edges that do not participate in any match, thus reducing the background graph to a subgraph that is the union of all template matches—the complete set of all vertices and edges that participate in at least one match. Additional analysis can be performed on this annotated, reduced graph, such as full match enumeration, match counting, or computing vertex/edge centrality. Furthermore, a vertex-centric formulation for constraint checking algorithms exists, and this makes it possible to harness existing high-performance, vertex-centric graph processing frameworks. This technique (i) enables highly scalable pattern matching in metadata (labeled) graphs; (ii) supports arbitrary patterns with 100% precision; (iii) enables tradeoffs between precision and time-to-solution, while always selects all vertices and edges that participate in matches, thus offering 100% recall; and (iv) supports a set of popular data analytics scenarios. We implement our approach on top of HavoqGT, an open-source asynchronous graph processing framework, and demonstrate its advantages through strong and weak scaling experiments on massive scale real-world (up to 257 billion edges) and synthetic (up to 4.4 trillion edges) labeled graphs, respectively, and at scales (1,024 nodes / 36,864 cores), orders of magnitude larger than used in the past for similar problems. This article serves two purposes: First, it synthesises the knowledge accumulated during a long-term project. Second, it presents new system features, usage scenarios, optimizations, and comparisons with related work that strengthen the confidence that pattern matching based on iterative pruning via constraint checking is an effective and scalable approach in practice. The new contributions include the following: (i) We demonstrate the ability of the constraint checking approach to efficiently support two additional search scenarios that often emerge in practice, interactive incremental search and exploratory search. (ii) We empirically compare our solution with two additional state-of-the-art systems, Arabsque and TriAD. (iii) We show the ability of our solution to accommodate a more diverse range of datasets with varying properties, e.g., scale, skewness, label distribution, and match frequency. (iv) We introduce or extend a number of system features (e.g., work aggregation, load balancing, and the ability to cap the generated traffic) and design optimizations and demonstrate their advantages with respect to improving performance and scalability. (v) We present bottleneck analysis and insights into artifacts that influence performance. (vi) We present a theoretical complexity argument that motivates the performance gains we observe.

97 MATHEMATICS AND COMPUTING↗