Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Software Stack”

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 19 records
All sourcesNASA NTRSDOE OSTI
DOE OSTI2021

Virtual Framework for Development and Testing of Federation Software Stack

Softwarization of networked infrastructures combined with containerization of codes promises unprecedented computing capabilities distributed across the federations of computing systems and physical instruments. The development and testing of a software stack that implements these capabilities over an expensive physical production infrastructure is not cost-effective, and in the early stages, may potentially cause service disruptions. To address these aspects, we develop the Virtual Federated Science Instrument Environment (VFSIE), a digital twin of the physical infrastructure that emulates a multi-site federation. Each federated site is emulated using containers and virtual hosts that are connected over local-area networks, and the sites, in turn, are connected over an emulated wide-area network. We describe the framework design and implementation details. We also illustrate its application by emulating a federation of four laboratories that use Jupyter Notebook for computations and the EPICS software system for instrument control.

Al Najjar, Anees↗
DOE OSTI2024

Providing a Flexible and Comprehensive Software Stack Via Spack, an Extreme-Scale Scientific Software Stack, and Software Development Kits

To manage the complex demands of modern high-performance computing (HPC), software applications increasingly depend on software developed by other teams, often at other institutions. An HPC software ecosystem approach is required to support dependencies on third-party scientific software. An ecosystem approach provides layers of activity above the individual software product level that promote interoperability, quality improvement, porting, testing, and deployment. The U.S. Exascale Computing Project (ECP) developed its HPC software ecosystem using a three-pronged approach. First, the ECP adopted and invested in Spack, a package manager designed to handle complex HPC package dependencies. Second, the ECP created the Extreme Scale Scientific Software Stack, an effort that supports developing, deploying, and running scientific applications on HPC platforms. Third, the ECP supported software product communities, or software development kits, to develop and promote best practices, improve software interoperability, and other collaborative efforts. This article describes ECP contributions to HPC software ecosystem challenges.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2017

ASC ATDM Level 2 Milestone #6015: Asynchronous Many-Task Software Stack Demonstration

This report is an outcome of the ASC ATDM Level 2 Milestone 6015: Asynchronous Many-Task Software Stack Demonstration. It comprises a summary and in depth analysis of DARMA and a DARMA-compliant Asynchronous Many-Task (AMT) runtime software stack. Herein performance and productivity of the over- all approach are assessed on benchmarks and proxy applications representative of the Sandia ATDM applications. As part of the effort to assess the perceived strengths and weaknesses of AMT models compared to more traditional methods, experiments were performed on ATS-1 (Advanced Technology Systems) test bed machines and Trinity. In addition to productivity and performance assessments, this report includes findings on the generality of DARMAs backend API as well as findings on interoperability with node- level and network-level system libraries. Together, this information provides a clear understanding of the strengths and limitations of the DARMA approach in the context of Sandias ATDM codes, to guide our future research and development in this area.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

Implementing the LSST Software Stack for DESGW processing and the Integration of Convolutional Neural Networks into the DESGW Pipeline

The Dark Energy Survey Gravitational Wave (DESGW) group strives to understand thelargescale structure of the universe and galaxies by looking for electromagnetic signatures intelescope images following gravitational wave detections. The DESGW group uses a processing pipeline to perform difference imaging to look for potential candidates. In order to perform these searches more effectively, we first explored using an alternative processing pipeline, the LSST Software Stack to analyze the telescope images. Because the LSST software stack is currently transitioning between its generation 2 and generation 3 system, we decided that while the software will be usable in the future once generation 3 is complete, at the moment its incompleteness makes it impractical to use. We then decided to work on improving the current pipeline by developing a module that integrates a Convolutional Neural Network (CNN) to test difference imaging products for bad subtractions due to misalignment.

Navarro, Alexander↗
DOE OSTI2022

ArQTiC: A Full-stack Software Package for Simulating Materials on Quantum Computers

ArQTiC is an open-source, full-stack software package built for the simulations of materials on quantum computers. It currently can simulate materials that can be modeled by any Hamiltonian derived from a generic, one-dimensional, time-dependent Heisenberg Hamiltonian. ArQTiC includes modules for generating quantum programs for real- and imaginary-time evolution, quantum circuit optimization, connection to various quantum backends via the cloud, and post-processing of quantum results. By enabling users to seamlessly design, execute, and analyze materials simulations on quantum computers, ArQTiC opens this field to a broader community of scientists from a wider range of scientific domains.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2016

Charliecloud: Unprivileged containers for user-defined software stacks in HPC

Supercomputing centers are seeing increasing demand for user-defined software stacks (UDSS), instead of or in addition to the stack provided by the center. These UDSS support user needs such as complex dependencies or build requirements, externally required configurations, portability, and consistency. The challenge for centers is to provide these services in a usable manner while minimizing the risks: security, support burden, missing functionality, and performance. We present Charliecloud, which uses the Linux user and mount namespaces to run industry-standard Docker containers with no privileged operations or daemons on center resources. Our simple approach avoids most security risks while maintaining access to the performance and functionality already on offer, doing so in less than 500 lines of code. Charliecloud promises to bring an industry-standard UDSS user workflow to existing, minimally altered HPC resources.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2021

Port and optimize the CEED software stack to Aurora/Frontier EA (ECP Milestone Report)

The goal of this milestone was to port the CEED software stack, including Nek, MFEM and libCEED to the Frontier and Aurora early access hardware, work on optimizing the performance on AMD and Intel GPUs, and demonstrate impact in CEED-enabled ECP applications. As part of this milestone, we also performed a number of other activities, including continued optimizations for CEED applications at scale on Summit, performance evaluation on non-ECP hardware, including the Fugaku’s A64FX chip and the NVIDIA A100 GPU architecture, exploring the use of just-in-time compilations in applications at scale and potential of mixed precision optimizations in the CEED discretization and solver algorithms, and more. During the milestone period, the CEED team released new versions of 6 of its packages, including major releases of MFEM, NekRS and OCCA. We also organized the fifth CEED Annual meeting (CEED5AM) which included nearly 100 researchers from national labs, universities and industry.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2022

FY2022 Q4: Demonstrate multi-turbine simulation with hybrid-structured/unstructured-moving-grid software stack running primarily on GPUs and propose improvements for successful KPP-2 [Poster]

Milestone accomplishments staged the ExaWind team for successful completion of KPP-2 challenge problem in FY23, which requires the simulation on Frontier of at least four MW-scale turbines in an atmospheric boundary layer with at least 20B gridpoints. The ExaWind project and software stack is many faceted, with team members working on multiple areas, including linear-system solvers (Trilinos, hypre, AMReX), overset meshes, turbulence modeling, and in situ visualization, all with an aim for high fidelity predictions and performance portability. This milestone marks significant improvements on many fronts and provides the team with a pathway to exascale wind farm simulations in FY23.

17 WIND ENERGY↗
DOE OSTI2017

PIPER: Performance Insight for Programmers and Exascale Runtimes: Guiding the Development of the Exascale Software Stack

The PIPER project set out to develop methodologies and software for measurement, analysis, attribution, and presentation of performance data for extreme-scale systems. Goals of the project were to support analysis of massive multi-scale parallelism, heterogeneous architectures, multi-faceted performance concerns, and to support both post-mortem performance analysis to identify program features that contribute to problematic performance and on-line performance analysis to drive adaptation. This final report summarizes the research and development activity at Rice University as part of the PIPER project. Producing a complete suite of performance tools for exascale platforms during the course of this project was impossible since both hardware and software for exascale systems is still a moving target. For that reason, the project focused broadly on the development of new techniques for measurement and analysis of performance on modern parallel architectures, enhancements to HPCToolkit’s software infrastructure to support our research goals or use on sophisticated applications, engaging developers of multithreaded runtimes to explore how support for tools should be integrated into their designs, engaging operating system developers with feature requests for enhanced monitoring support, engaging vendors with requests that they add hardware measure- ment capabilities and software interfaces needed by tools as they design new components of HPC platforms including processors, accelerators and networks, and finally collaborations with partners interested in using HPCToolkit to analyze and tune scalable parallel applications.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2012

Towards a supported common NEAMS software stack

The NEAMS IPSC's are developing multidimensional, multiphysics, multiscale simulation codes based on first principles that will be capable of predicting all aspects of current and future nuclear reactor systems. These new breeds of simulation codes will include rigorous verification, validation and uncertainty quantification checks to quantify the accuracy and quality of the simulation results. The resulting NEAMS IPSC simulation codes will be an invaluable tool in designing the next generation of Nuclear Reactors and also contribute to a more speedy process in the acquisition of licenses from the NRC for new Reactor designs. Due to the high resolution of the models, the complexity of the physics and the added computational resources to quantify the accuracy/quality of the results, the NEAMS IPSC codes will require large HPC resources to carry out the production simulation runs.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2022

Software Deployment Process at NERSC: Deploying the Extreme-scale Scientific Software Stack (E4S) Using Spack at the National Energy Research Scientific Computing Center (NERSC)

One of the many benefits of using a high-performance computing (HPC) system at a Department of Energy (DOE) Office of Science (SC) HPC facility is the large number of software products, built and optimized for the system. The HPC center staff and HPC vendors provide optimized software such as libraries and even full scientific applications, ready to be used by users as building blocks to accelerate scientific discovery. Behind each provided packaged software module are a large number of decisions - which compiler, optimizations, variants/options - to build the software on the target system. And, even before the software gets deployed, the software must be developed, tested, and maintained, including deprecating old versions and ensuring compatibility across versions. The software lifecycle is complex and is further convoluted by a web of interdependencies on other software.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2020

Adapting DESGW Single Epoch Image Differencing to the LSST Software Stack

Optical follow-up for gravitational wave events remains an important factor in potentially unlocking the secrets of dark matter in the universe. The Dark Energy Survey Gravitational Wave (DESGW) Group currently processes optical data from Dark Energy Camera (DECam) using a custom software pipeline derived from existing DES Supernovae Processing pipelines. While effective, is difficult to maintain and develop a custom workflow as new processing strategies are discovered, and researchers are diverted to newer projects in dark energy investigations. By building a modified image ingestion script and implementing the open-source Legacy Survey of Space and Time (LSST) Processing Pipeline for DESGW data, the lifetime and efficiency of the DESGW difference imaging program can be extended.

79 ASTRONOMY AND ASTROPHYSICS↗
DOE OSTI2017

Enabling Diverse Software Stacks on Supercomputers using High Performance Virtual Clusters.

While large-scale simulations have been the hallmark of the High Performance Computing (HPC) community for decades, Large Scale Data Analytics (LSDA) workloads are gaining attention within the scientific community not only as a processing component to large HPC simulations, but also as standalone scientific tools for knowledge discovery. With the path towards Exascale, new HPC runtime systems are also emerging in a way that differs from classical distributed com- puting models. However, system software for such capabilities on the latest extreme-scale DOE supercomputing needs to be enhanced to more appropriately support these types of emerging soft- ware ecosystems. In this paper, we propose the use of Virtual Clusters on advanced supercomputing resources to enable systems to support not only HPC workloads, but also emerging big data stacks. Specifi- cally, we have deployed the KVM hypervisor within Cray's Compute Node Linux on a XC-series supercomputer testbed. We also use libvirt and QEMU to manage and provision VMs directly on compute nodes, leveraging Ethernet-over-Aries network emulation. To our knowledge, this is the first known use of KVM on a true MPP supercomputer. We investigate the overhead our solution using HPC benchmarks, both evaluating single-node performance as well as weak scaling of a 32-node virtual cluster. Overall, we find single node performance of our solution using KVM on a Cray is very efficient with near-native performance. However overhead increases by up to 20% as virtual cluster size increases, due to limitations of the Ethernet-over-Aries bridged network. Furthermore, we deploy Apache Spark with large data analysis workloads in a Virtual Cluster, ef- fectively demonstrating how diverse software ecosystems can be supported by High Performance Virtual Clusters.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Developing and Distributing HEP Software Stacks with Spack

The Computational Science and AI Directorate at Fermilab is using Spack to support the development efforts of a large number of scientific programmers, in many independent projects and experiments. While independent, these projects share many dependencies. They are typically under continuous and fairly rapid development. They have to support deployment on diverse hardware. This is a different context than is typical for the management of HPC software, where Spack was born. To support our community, we have created a model that enables users to develop code with greater efficiency than is possible with Spack’s current development facilities. In this talk we will present: - a brief introduction to the science we support (particle physics) - how the code we work with is naturally organized into several layers of packages - how we are using Spack to manage those layers - how we leverage the layering to provide efficient support for developers, using our Spack extension “MPD”. - some suggestions for changes or additions to Spack to make such work easier.

Knoepfel, Kyle J. [Fermilab]↗
DOE OSTI2024

WETO Software Stack Best Practices

Wind energy researchers typically share one key characteristic: a passion for increasing wind energy in the global energy mix. The U.S. Department of Energy (DOE) supports this mission in a number of ways including allocating funding directly to various aspects of wind energy research through the Office of Energy Efficiency and Renewable Energy (EERE) via the Wind Energy Technologies Office (WETO). While the traditional output of research is academic publication, software development efforts are increasingly a major focus. Software tools in the research environment allow researchers to describe an idea and quickly increase the scope and scale as they study it further. As a product of research, these tools represent a direct pipeline from researcher to industry practitioners since they are the implementation of ideas described in academic publications. Given this vital role in wind energy research and commercial development, the broad research software portfolio supported by WETO must maintain a minimum level of quality to support the wind energy field in the growing transition to renewable energy. This report outlines a series o f best practices to be adopted by all WETO-supported software projects, as well as expectations that the communities interacting with these projects should have of the developers and tools themselves. Wind energy research software has a unique standing in the field of scientific software. The stakeholders are varied with a subset being: (1) DOE EERE leadership, (2) DOE WETO leadership and program managers, (3) National lab leadership, (4) Associated project principle investigators, (5) Research software engineers, (6) Wind energy researchers in academia (including graduate students, post docs, and national lab staff), (7) Industry researchers and practitioners, (8) Commercial software developers, and (9) The general public interested in wind energy. These software are typically the end-user of other generic software libraries, so the funding cycles are often tied to applied research rather than the development of the software itself. Since the developers are also wind energy researchers, these tools are typically designed in a way that closely resembles the application in which they're used. Additionally, the expertise and incentives for the developers have a high variability, and often neither are aligned with software engineering or computer science. Given the unique environment in which wind energy research software is produced and consumed, it is critical for model owners to understand the context of their software. A framework for developing this understanding is to answer the following questions of a given software project: What is it's purpose? What is its role in the field of wind energy? What is the profile of the expected users? For how long will it be relevant? What is the expected impact? These questions allow model owners to identify the appropriate methods for the design, development, and long term maintenance of their software. Additionally, the answer provide context for future planners to understand why particular decisions were made and discern the consequences of changing course. The information is aggregated from experience within WETO-supported software development groups as well as external organizations and efforts to define the craft of research software engineering. These best practices aim to make the collaborative development process efficient and effective while improving the model understanding across stakeholders. Additionally, the general adoption of a common framework for software quality ensures that the end users of WETO software can trust these tools and accurately understand the risks to workflow integration.

17 WIND ENERGY↗