SEARCH · Engineering Papers

Results for “coded source”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 145 records · Page 8

All sources NASA NTRS DOE OSTI

DOE OSTI2015

System, methods and apparatus for program optimization for multi-threaded processor architectures

Methods, apparatus and computer software product for source code optimization are provided. In an exemplary embodiment, a first custom computing apparatus is used to optimize the execution of source code on a second computing apparatus. In this embodiment, the first custom computing apparatus contains a memory, a storage medium and at least one processor with at least one multi-stage execution unit. The second computing apparatus contains at least two multi-stage execution units that allow for parallel execution of tasks. The first custom computing apparatus optimizes the code for parallelism, locality of operations and contiguity of memory accesses on the second computing apparatus. This Abstract is provided for the sole purpose of complying with the Abstract requirement rules. This Abstract is submitted with the explicit understanding that it will not be used to interpret or to limit the scope or the meaning of the claims.

42 ENGINEERING↗

DOE OSTI2023

Finding inputs that trigger floating-point exceptions in heterogeneous computing via Bayesian optimization

Testing code for floating-point exceptions is crucial as exceptions can quickly propagate and produce unreliable numerical answers. The state-of-the-art to test for floating-point exceptions in heterogeneous systems is quite limited and solutions require the application’s source code, which precludes their use in accelerated libraries where the source is not publicly available. We present an approach to find inputs that trigger floating-point exceptions in black-box CPU or GPU functions, i.e., functions where the source code and information about input bounds are unavailable. Our approach is the first to use Bayesian optimization (BO) to identify such inputs and uses novel strategies to overcome the challenges that arise in applying BO to this problem. Here, we implement our approach in the XSCOPE framework and demonstrate it on 58 functions from the CUDA Math Library and 81 functions from the Intel Math Library. XSCOPE is able to identify inputs that trigger exceptions in about 73% of the tested functions.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2012

Boron injection/dilution capabilities in TRACB/NEM coupled code

The coupled code TRAC-BF1/NEM is a thermal-hydraulic-neutronic code which allows transient simulations considering neutronic 3D and thermal-hydraulic process in multiple channels with one-dimensional geometry. TRAC-BF1 and NEM can be executed either in stand-alone mode, i.e. without coupling, as well as coupled. In stand-alone calculations NEM code is used without coupling and the thermal-hydraulic conditions (fuel temperature, moderator density and boron concentration) and xenon concentration for each node are taken from the SIMULATE3 output files. The NEM's source code has been modified to be able to read these conditions from external files when it is executed without being coupled. The coupling between TRAC-BF1 and NEM follows an integration scheme in which the thermal-hydraulic solution of TRAC-BF1 is sent to NEM to incorporate the feedback effects through the cross sections. TRAC-BF1 solves heat conduction equations inside of the heat structures using the 3D power distribution from NEM. The coupling is carried out through the communication protocol functions of PVM (Parallel Virtual Machine). The present article presents a study which constitutes an advance in the simulation of injection, transport and mix of boron in the reactor, increasing the capabilities of TRAC-BF1/NEM coupled code. This article shows the modifications introduced in the TRAC-BF1/NEM's source code to allow a more realistic simulation of boron injection transients. The qualification of these improvements in both codes is performed simulating a steady state of a generic BWR at nominal power. The results have been compared with SIMULATE3 which is used as a reference to obtain the cross sections through the SIMTAB methodology. (authors)

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

DOE OSTI2022

ACES: Infrastructure As Code. Model Optimization and Performance Capability

Infrastructure as Code (IaC) refers to managing infrastructure (networks, physical/virtual machines, storage, and connection topology) in a descriptive model/language, rather than configuring it manually or using interactive configuration tools. Just like source code can be compiled to generate the same binary code, IaC enables generating the same environment every time it is applied. IaC is a key DevOps practice and is generally used in conjunction with continuous integration (CI) and continuous delivery (CD). In CI, all code changes are merged into a mainline branch and validated multiple times a day as developers check in their changes to the source code. In CD on the other hand, code changes are automatically packaged for a new release-to-production on a regular basis. This typically enables teams to deliver software changes much more quickly and often. Developing and managing the ACES platform using (IaC) is vital for the robust deployment and continued sustainment of this foundational computing capability. IaC and DevOps practices will help us solve many of the common challenges often encountered in developing and maintaining compute infrastructure. First, it will make the provisioning, deployment, and maintenance of the compute infrastructure across multiple environments much more efficient. Second, these processes help make the overall system much more stable by continuously testing new changes as they are introduced to the system. Third, it allows us to be much more confident of the security controls in place since they can be tested as part of the CI process and all new changes can be audited and tracked. Finally, IaC enables the ACES Platform to be adaptable to the emerging technologies due to its ability to spin up different test beds to evaluate and incorporate these technologies. This document addresses common infrastructure-management challenges, describes what happens if they are not addressed, and highlights the value of utilizing IaC to tackle them. Finally, we will provide a high-level overview of the IaC and DevOps practices being utilized by the ACES Platform team.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2017

An LLVM Instrumentation Plug-in for Score-P

Reducing application runtime, scaling parallel applications to higher numbers of processes/threads, and porting applications to new hardware architectures are tasks necessary in the software development process. Therefore, developers have to investigate and understand application runtime behavior. Tools such as monitoring infrastructures that capture performance relevant data during application execution assist in this task. The measured data forms the basis for identifying bottlenecks and optimizing the code.Monitoring infrastructures need mechanisms to record application activities in order to conduct measurements. Automatic instrumentation of the source code is the preferred method in most application scenarios. We introduce a plug-in for the LLVM infrastructure that enables automatic source code instrumentation at compile-time. In contrast to available instrumentation mechanisms in LLVM/Clang, our plug-in can selectively include/exclude individual application functions. This enables developers to fine-tune the measurement to the required level of detail while avoiding large runtime overheads due to excessive instrumentation.

Tschüter, Ronny↗

DOE OSTI2017

Program structure-based blocking

Embodiments relate to program structure-based blocking. An aspect includes receiving source code corresponding to a computer program by a compiler of a computer system. Another aspect includes determining a prefetching section in the source code by a marking module of the compiler. Yet another aspect includes performing, by a blocking module of the compiler, blocking of instructions located in the prefetching section into instruction blocks, such that the instruction blocks of the prefetching section only contain instructions that are located in the prefetching section.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2017

Program structure-based blocking

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2024

Accelerating Application Bulk Synchronous Writes in HPC Environments

High-bandwidth storage tiers are becoming more common for their capability to absorb high-rate, bursty I/Os. Notably, the designs of these fast storage tiers differ from system to system. The variation of these layers and non-uniform methods of access can pose chal- lenges for applications seeking to run at multiple HPC facilities. Therefore, in this work, we present Spectral, a rapid-output ab- straction library to accelerate application, bulk-synchronous writes on HPC systems. We design Spectral to enable applications to use high-bandwidth storage, such as node-local storage and dis- tributed, write-caches (e.g., burst buffers) transparently without requiring modifications to the application or file system source code. The key idea is to allow applications to spend most of the time performing productive work and to not require any source code changes for maximum portability on different HPC archi- tectures. Spectral internally re-routes write-only files through available, high-performance I/O resources before ultimately mi- grating them to the shared global parallel file system. For instance, on Summit, Spectral transparently places application outputs on node-local storage and then utilizes asynchronous migration to the center-wide GPFS file system. We evaluate Spectral on the Summit HPC system (1024 nodes) using the IOR benchmark and real scientific applications. Spectral shows linear performance scaling, improving application write performance by over an order of magnitude when compared to GPFS.

Khan, Awais↗

DOE OSTI2023

pvlib python: 2023 project update

pvlib python is a community-developed, open-source software toolbox for simulating the performance of solar photovoltaic (PV) energy components and systems. It provides reference implementations of over 100 empirical and physics-based models from the peer-reviewed scientific literature, including solar position algorithms, irradiance models, thermal models, and PV electrical models. In addition to individual low-level model implementations, pvlib python provides high-level workflows that chain these models together like building blocks to form complete “weather-to-power” photovoltaic system models. It also provides functions to fetch and import a wide variety of weather datasets useful for PV modeling. pvlib python has been developed since 2013 and follows modern best practices for open-source python software, with comprehensive automated testing, standards-based packaging, and semantic versioning. Its source code is developed openly on GitHub and releases are distributed via the Python Package Index (PyPI) and the conda-forge repository. pvlib python’s source code is made freely available under the permissive BSD-3 license. Here we (the project’s core developers) present an update on pvlib python, describing capability and community development since our 2018 publication (Holmgren, Hansen, & Mikofski, 2018).

14 SOLAR ENERGY↗

DOE OSTI2024

Data-Driven Protection Software to classify fault locations by protective zone in distribution systems with high PV penetration

The software contains (a) the source codes to generate Point-on-Wave (PoW) transient data for any feeder model in Alternative Transient Program (ATP) format. Codes provide options to change different steady state settings, including the loading condition and PV capacity and transient state setting like faults type, location and initiation time (b) data post-processing source code to converted data from native format to COMTRADE, csv, HDF5 (c) Docker container to train CNN to classify fault locations by protective zone. The container takes dataset and other training parameters (sampling rate, training epochs, batch size etc) as input to train CNN. The container writes back the trained CNN model, training and testing metrics and plots to the local workstation

Ramesh, Meghana↗

DOE OSTI2012

Report of experiments and evidence for ASC L2 milestone 4467: demonstration of a legacy application's path to exascale

This report documents thirteen of Sandia's contributions to the Computational Systems and Software Environment (CSSE) within the Advanced Simulation and Computing (ASC) program between fiscal years 2009 and 2012. It describes their impact on ASC applications. Most contributions are implemented in lower software levels allowing for application improvement without source code changes. Improvements are identified in such areas as reduced run time, characterizing power usage, and Input/Output (I/O). Other experiments are more forward looking, demonstrating potential bottlenecks using mini-application versions of the legacy codes and simulating their network activity on Exascale-class hardware. The purpose of this report is to prove that the team has completed milestone 4467-Demonstration of a Legacy Application's Path to Exascale. Cielo is expected to be the last capability system on which existing ASC codes can run without significant modifications. This assertion will be tested to determine where the breaking point is for an existing highly scalable application. The goal is to stretch the performance boundaries of the application by applying recent CSSE RD in areas such as resilience, power, I/O, visualization services, SMARTMAP, lightweight LWKs, virtualization, simulation, and feedback loops. Dedicated system time reservations and/or CCC allocations will be used to quantify the impact of system-level changes to extend the life and performance of the ASC code base. Finally, a simulation of anticipated exascale-class hardware will be performed using SST to supplement the calculations. Determine where the breaking point is for an existing highly scalable application: Chapter 15 presented the CSSE work that sought to identify the breaking point in two ASC legacy applications-Charon and CTH. Their mini-app versions were also employed to complete the task. There is no single breaking point as more than one issue was found with the two codes. The results were that applications can expect to encounter performance issues related to the computing environment, system software, and algorithms. Careful profiling of runtime performance will be needed to identify the source of an issue, in strong combination with knowledge of system software and application source code.

99 GENERAL AND MISCELLANEOUS↗

DOE OSTI2016

Friendly Extensible Transfer Tool Beta Version

Often data transfer software is designed to meet specific requirements or apply to specific environments. Frequently, this requires source code integration for added functionality. An extensible data transfer framework is needed to more easily incorporate new capabilities, in modular fashion. Using FrETT framework, functionality may be incorporated (in many cases without need of source code) to handle new platform capabilities: I/O methods (e.g., platform specific data access), network transport methods, data processing (e.g., data compression.).

Collins, William P.↗

DOE OSTI2019

Development of an Automated J-R Curve Analysis Software Based on the ASTM E1820-18 Normalization Method

The J-integral versus crack-growth resistance curve (J-R curve) is a useful tool for evaluating material fracture toughness in the ductile region. A widely accepted practice for conducting J-R curve testing is ASTM standard E1820, which introduces the normalization method. This method does not require compliance measurements during testing, significantly simplifying J-R curve testing compared with the conventional elastic unloading compliance (EUC) method. Despite the advantage in testing, analysis procedures for the normalization method are very complicated. Also, there is no open source software currently available to perform such analysis.The authors developed an open source automated J-R curve-analysis software based on the normalization method in ASTM E1820-18. Source codes were written in MATLAB and the compiled software, in the form of a stand-alone executable, has a user-friendly graphic interface and is readily compatible with modern Windows operating systems. Both source codes and the compiled executable file are available for download at https://code.ornl.gov/xc8/ANJR.git. Comparisons between resulting J-R curves from the software and manual analysis procedures show essentially identical results, indicating the suitability of applying the automated software for J-R curve analysis.

36 MATERIALS SCIENCE↗

DOE OSTI2013

Four-Dimensional Finite-Orbit-Width Fokker-Planck Code with Sources, for Neoclassical/Anomalous Transport Simulation of Ion and Electron (Final Technical Report)

Within the US Department of Energy/Office of Fusion Energy magnetic fusion research program, there is an important whole-plasma-modeling need for a radio-frequency/neutral-beam-injection (RF/NBI) transport-oriented finite-difference Fokker-Planck (FP) code with combined capabilities for 4D (2R2V) geometry near the fusion plasma periphery, and computationally less demanding 3D (1R2V) bounce-averaged capabilities for plasma in the core of fusion devices. Demonstration of proof-of-principle achievement of this goal has been carried out in research carried out under Phase I of the SBIR award. Two DOE-sponsored codes, the CQL3D bounce-average Fokker-Planck code in which CompX has specialized, and the COGENT 4D, plasma edge-oriented Fokker-Planck code which has been constructed by Lawrence Livermore National Laboratory and Lawrence Berkeley Laboratory scientists, where coupled. Coupling was achieved by using CQL3D calculated velocity distributions including an energetic tail resulting from NBI, as boundary conditions for the COGENT code over the two-dimensional velocity space on a spatial interface (flux) surface at a given radius near the plasma periphery. The finite-orbit-width fast ions from the CQL3D distributions penetrated into the peripheral plasma modeled by the COGENT code. This combined code demonstrates the feasibility of the proposed 3D/4D code. By combining these codes, the greatest computational efficiency is achieved subject to present modeling needs in toroidally symmetric magnetic fusion devices. The more efficient 3D code can be used in its regions of applicability, coupled to the more computationally demanding 4D code in higher collisionality edge plasma regions where that extended capability is necessary for accurate representation of the plasma. More efficient code leads to greater use and utility of the model. An ancillary aim of the project is to make the combined 3D/4D code user friendly. Achievement of full-coupling of these two Fokker-Planck codes will advance computational modeling of plasma devices important to the USDOE magnetic fusion energy program, in particular the DIII-D tokamak at General Atomics, San Diego, the NSTX spherical tokamak at Princeton, New Jersey, and the MST reversed-field-pinch Madison, Wisconsin. The validation studies of the code against the experiments will improve understanding of physics important for magnetic fusion, and will increase our design capabilities for achieving the goals of the International Tokamak Experimental Reactor (ITER) project in which the US is a participant and which seeks to demonstrate at least a factor of five in fusion power production divided by input power.

70 PLASMA PHYSICS AND FUSION TECHNOLOGY↗

DOE OSTI2020

High Performance Computing tutorials

This source code includes tutorials targeting a general audience that will help users to use high performance computing environments and systems at Livermore Computing and beyond. Examples of HPC tools covered include mpi and posix. Tutorials may include source code demonstrating usage.

Herriman, JaneE.↗

DOE OSTI2012

Compiled MPI: Cost-Effective Exascale Applications Development

The complexity of petascale and exascale machines makes it increasingly difficult to develop applications that can take advantage of them. Future systems are expected to feature billion-way parallelism, complex heterogeneous compute nodes and poor availability of memory (Peter Kogge, 2008). This new challenge for application development is motivating a significant amount of research and development on new programming models and runtime systems designed to simplify large-scale application development. Unfortunately, DoE has significant multi-decadal investment in a large family of mission-critical scientific applications. Scaling these applications to exascale machines will require a significant investment that will dwarf the costs of hardware procurement. A key reason for the difficulty in transitioning today's applications to exascale hardware is their reliance on explicit programming techniques, such as the Message Passing Interface (MPI) programming model to enable parallelism. MPI provides a portable and high performance message-passing system that enables scalable performance on a wide variety of platforms. However, it also forces developers to lock the details of parallelization together with application logic, making it very difficult to adapt the application to significant changes in the underlying system. Further, MPI's explicit interface makes it difficult to separate the application's synchronization and communication structure, reducing the amount of support that can be provided by compiler and run-time tools. This is in contrast to the recent research on more implicit parallel programming models such as Chapel, OpenMP and OpenCL, which promise to provide significantly more flexibility at the cost of reimplementing significant portions of the application. We are developing CoMPI, a novel compiler-driven approach to enable existing MPI applications to scale to exascale systems with minimal modifications that can be made incrementally over the application's lifetime. It includes: (1) New set of source code annotations, inserted either manually or automatically, that will clarify the application's use of MPI to the compiler infrastructure, enabling greater accuracy where needed; (2) A compiler transformation framework that leverages these annotations to transform the original MPI source code to improve its performance and scalability; (3) Novel MPI runtime implementation techniques that will provide a rich set of functionality extensions to be used by applications that have been transformed by our compiler; and (4) A novel compiler analysis that leverages simple user annotations to automatically extract the application's communication structure and synthesize most complex code annotations.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2021

LIM1TR: Lithium-Ion Modeling with 1-D Thermal Runaway (V.1.0)

LIM1TR (Lithium-Ion Modeling with 1-D Thermal Runaway) is an open-source code that uses the finite volume method to simulate heat transfer and chemical kinetics on a quasi 1-D domain. The target application of this software is to simulate thermal runaway in systems of lithium-ion batteries. The source code for LIM1TR can be found at https://github.com/ajkur/lim1tr. This user guide details the steps required to create and run simulations with LIM1TR starting with setting up the Python environment, generating an input file, and running a simulation. Additional details are provided on the output of LIM1TR as well as extending the code with custom reaction models. This user guide concludes with simple example analyses of common battery thermal runaway scenarios. The corresponding input files and processing scripts can be found in the “Examples” folder in the on-line repository, with select input files included in the appendix of this document.

25 ENERGY STORAGE↗

DOE OSTI2015

Augmenting Traditional Static Analysis With Commonly Available Metadata

Developers and security analysts have been using static analysis for a long time to analyze programs for defects and vulnerabilities with some success. Generally a static analysis tool is run on the source code for a given program, flagging areas of code that need to be further inspected by a human analyst. These areas may be obvious bugs like potential bu er over flows, information leakage flaws, or the use of uninitialized variables. These tools tend to work fairly well - every year they find many important bugs. These tools are more impressive considering the fact that they only examine the source code, which may be very complex. Now consider the amount of data available that these tools do not analyze. There are many pieces of information that would prove invaluable for finding bugs in code, things such as a history of bug reports, a history of all changes to the code, information about committers, etc. By leveraging all this additional data, it is possible to nd more bugs with less user interaction, as well as track useful metrics such as number and type of defects injected by committer. This dissertation provides a method for leveraging development metadata to find bugs that would otherwise be difficult to find using standard static analysis tools. We showcase two case studies that demonstrate the ability to find 0day vulnerabilities in large and small software projects by finding new vulnerabilities in the cpython and Roundup open source projects.

97 MATHEMATICS AND COMPUTING↗