SEARCH · Engineering Papers

Results for “source code”

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 109 records · Page 6

All sources NASA NTRS DOE OSTI

DOE OSTI2020

CTF Theory Manual (V.4.2)

Coolant-Boiling in Rod Arrays—Two Fluids (COBRA-TF) is a thermal/hydraulic (T/H) simulation code designed for light water reactor (LWR) vessel analysis. It uses a two-fluid, three-field (i.e. fluid film, fluid drops, and vapor) modeling approach. Both sub-channel and 3D Cartesian forms of 9 conservation equations are available for LWR modeling. The code was originally developed by Pacific Northwest Laboratory in 1980 and had been used and modified by several institutions over the last few decades. COBRA-TF also found use at the Pennsylvania State University (PSU) by the Reactor Dynamics and Fuel Modeling Group (RDFMG) and has been improved, updated, and subsequently re-branded as CTF. As part of the improvement process, it was necessary to generate sufficient documentation for the open-source code which had lacked such material upon being adopted by RDFMG. This document serves mainly as a theory manual for CTF, detailing the many two-phase heat transfer, drag, and important accident scenario models contained in the code as well as the numerical solution process utilized. Coding of the models is also discussed, all with consideration for updates that have been made when transitioning from COBRA-TF to CTF. Further documentation outside of this manual is also available at RDFMG which focus on code input deck generation and source code global variable and module listings

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗

DOE OSTI2017

PIXiE: an algorithm for automated ion mobility arrival time extraction and collision cross section calculation using global data association

Abstract Motivation Drift tube ion mobility spectrometry coupled with mass spectrometry (DTIMS-MS) is increasingly implemented in high throughput omics workflows, and new informatics approaches are necessary for processing the associated data. To automatically extract arrival times for molecules measured by DTIMS at multiple electric fields and compute their associated collisional cross sections (CCS), we created the PNNL Ion Mobility Cross Section Extractor (PIXiE). The primary application presented for this algorithm is the extraction of data that can then be used to create a reference library of experimental CCS values for use in high throughput omics analyses. Results We demonstrate the utility of this approach by automatically extracting arrival times and calculating the associated CCSs for a set of endogenous metabolites and xenobiotics. The PIXiE-generated CCS values were within error of those calculated using commercially available instrument vendor software. Availability and implementation PIXiE is an open-source tool, freely available on Github. The documentation, source code of the software, and a GUI can be found at https://github.com/PNNL-Comp-Mass-Spec/PIXiE and the source code of the backend workflow library used by PIXiE can be found at https://github.com/PNNL-Comp-Mass-Spec/IMS-Informed-Library. Supplementary information Supplementary data are available at Bioinformatics online.

Ma, Jian↗

DOE OSTI2022

Unified Language Frontend for Physic-Informed AI/ML

Artificial intelligence and machine learning (AI/ML) are becoming important tools for scientific modeling and simulation as in several other fields such as image analysis and natural language processing. ML techniques can leverage the computing power available in modern systems and reduce the human effort needed to configure experiments, interpret and visualize results, draw conclusions from huge quantities of raw data, and build surrogates for physics based models. Domain scientists in fields like fluid dynamics, microelectronics and chemistry can automate many of their most difficult and repetitive tasks or improve the design times by use of the faster ML-surrogates. However, modern ML and traditional scientific highperformance computing (HPC) tend to use completely different software ecosystems. While ML frameworks like PyTorch and TensorFlow provide Python APIs, most HPC applications and libraries are written in C++. Direct interoperability between the two languages is possible but is tedious and error-prone. In this work, we show that a compiler-based approach can bridge the gap between ML frameworks and scientific software with less developer effort and better efficiency. We use the MLIR (multi-level intermediate representation) ecosystem to compile a pre-trained convolutional neural network (CNN) in PyTorch to freestanding C++ source code in the Kokkos programming model. Kokkos is a programming model widely used in HPC to write portable, shared-memory parallel code that can natively target a variety of CPU and GPU architectures. Our compiler-generated source code can be directly integrated into any Kokkosbased application with no dependencies on Python or cross-language interfaces.

71 CLASSICAL AND QUANTUM MECHANICS, GENERAL PHYSIC↗

DOE OSTI2017

Extension of mutation testing for the requirements and design faults - 322

Mutation Testing is a fault-based software testing technique that is considered to be the most efficient in detecting faults. It focuses on the software code level and follows a set of rules which are called mutation operators to systematically seed faults into the source code. Each seeded fault results is a new version of the software, which is called a mutant. Mutation testing promises to be effective in identifying adequate test data which can be used to find faults in the source code. However, traditional mutation testing is not geared towards the detection of requirements and design faults. To cover the full spectrum of possible faults, the mutation framework has been extended from the code level to the requirements and design level. Twenty-nine defects that appear in requirements and design documents were identified to define appropriate mutants. Then corresponding mutation operators that model the defects were developed. For each mutation operator, the strategy to generate a mutant and the evaluation of the number of possible mutants were defined. Existing code level cost reduction techniques were tailored for requirements and design mutation operators that result in a large number of mutants. With the extended mutation testing framework, the full spectrum of possible faults will be tested and identified to ensure the safety and functionality of the software. (authors)

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

DOE OSTI2019

ECP Milestone Memo WBS 2.3.4.13 ECP/VTK-m FY19Q1 [MS-19/01-03] ZFP / Release / Clip STDA05-17

The STDA05-17 milestone comprises the following 3 deliverables. VTK-m Release 2 We will provide a release of VTK-m software and associated documentation. The source code repository will be tagged at a stable state, and, at a minimum, tarball captures of the source code will be made available from the web site. A version of the VTK-m User's Guide documenting this release will also be made available. Productionize zfp compression The "ZFP: Compressed Floating-Point Arrays" project (WBS 1.3.4.13) is creating an implementation of ZFP compression in VTK-m. Their implementation will be focused on operating in CUDA. The VTK-m project will assist by generalizing the implementation to other devices (such as multi-core CPUs). We will also assist in productionizing the code such that it can be used by external projects and products. Clip Clip operations intersect meshes with implicit functions. It is the foundation of spatial subsetting algorithms, such as "box," and the foundation of data-based subsetting, such as "isovolume." The algorithm requires considering thousands of possible cases, and is thus quite difficult to implement. This milestone will implement clipping to be sufficient for Visit's and ParaView's needs.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2018

Using CAASCADE and CrayPAT for Analysis of HPC Applications

We describe our work on integrating CAASCADE with CrayPAT to obtain both static and dynamic information on characteristics of high-performance computing (HPC) applications. CAASCADE --- Compiler-Assisted Application Source Code Analysis and Database---is a system we are developing to extract features of application from its source code by utilizing compiler plugins. CrayPAT enable us to add runtime-based information to CAASCADE's feature detection. We present results from analysis of HPC applications.

Budiardja, Reuben↗

DOE OSTI2017

MCNP6 and SERPENT2 Performances with Unstructured Mesh Geometry

Traditionally, Monte Carlo codes model a nuclear reactor by combinatorial geometry. In this model, volume primitives (e,g, spheres, cylinders, parallelepipeds...) are combined together by Boolean operations (e.g. union, intersection, and complement) and replicated by lattice definitions to build the core geometry. Recently, high performances computing platforms allowed using unstructured mesh geometry in Monte Carlo codes. When this option is chosen, any type of core geometry can be modeled since the restriction of using volume primitives is removed. In an unstructured mesh geometry, Boolean operations and lattice definitions are not used since each volume is defined by triangular surfaces (facets). This study focuses on two Monte Carlo codes: MCNP (version 6.1.1 beta) developed at Los Alamos National Laboratory since 1957 and written in FORTRAN90, C, and C++ (267,000 total source code lines), and SERPENT (version 2.1.27) developed at VTT Technical Research Centre since 2004 and written in C (195,000 total source code lines). These two codes follow different approaches for the unstructured mesh geometry modeling: MCNP uses ABAQUS format, whereas SERPENT uses the STL format. In the STL (STereoLithographic) geometry model only the surfaces of the volume are meshed; the interior part of the volumes is not meshed. In the STL geometry model, the whole geometry is defined by the sequence of SOLID and ENDSOLID sections. Each volume of the geometry must have a SOLID and ENDSOLID section. The STL file contains no information specifying the materials of the volumes. MCNP and SERPENT can model any kind of complicated geometry using unstructured meshes. MCNP and SERPENT use the ABAQUS and STL file formats, respectively. The STL file format does not have tetrahedrons and has only triangular facets on the volumes boundary. This allows SERPENT simulations to run 10 times faster than MCNP. However, if Monte Carlo results have to be coupled to thermal-hydraulics codes, the interior of the geometry volumes must be meshed, which may reduce SERPENT performances.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2016

MDSplus quality improvement project

MDSplus is a data acquisition and analysis system used worldwide predominantly in the fusion research community. Development began 29 years ago on the OpenVMS operating system. Since that time there have been many new features added and the code has been ported to many different operating systems. There have been contributions to the MDSplus development from the fusion community in the way of feature suggestions, feature implementations, documentation and porting to different operating systems. The bulk of the development and support of MDSplus, however, has been provided by a relatively small core developer group of three or four members. Given the size of the development team and the large number of users much more effort was focused on providing new features for the community than on keeping the underlying code and documentation up to date with the evolving software development standards. To ensure that MDSplus will continue to provide the needs of the community in the future, the MDSplus development team along with other members of the MDSplus user community has commenced on a major quality improvement project. The planned improvements include changes to software build scripts to better use GNU Autoconf and Automake tools, refactoring many of the source code modules using new language features available in modern compilers, using GNU MinGW-w64 to create MS Windows distributions, migrating to a more modern source code management system, improvement of source documentation as well as improvements to the www.mdsplus.org web site documentation and layout, and the addition of more comprehensive test suites to apply to MDSplus code builds prior to releasing installation kits to the community. This paper should lead to a much more robust product and establish a framework to maintain stability as more enhancements and features are added. Finally, this paper will describe these efforts that are either in progress or planned for the near future.

70 PLASMA PHYSICS AND FUSION TECHNOLOGY↗

DOE OSTI2020

ECP ST Project 2.3.1.06-STPM08-RAJA (Final Report)

Modern high-performance computing architectures are diverse, with hardware designs that feature multicore CPUs and CPUs plus accelerators, such as GPUs or FPGAs. Achieving good application performance often requires using a programming model and managing application data in ways that are best suited to a particular platform. For large codes that are used daily in production, and are under continual development, architecture-specific ports are untenable. Maintainability requires single-source code that is performance portable across a range of architectures and programming model back-ends. This report describes RAJA, Umpire, and CHAI, three software libraries that provide complementary capabilities to enable application portability for high performance computing (HPC) platforms. In particular, these libraries provide software abstractions that insulate application source code from hardware architecture and programming model-specific implementation details. These development of these libraries was motivated by the needs of multiphysics applications in the Weapons Simulation and Computing Program (WSC) at Lawrence Livermore National Laboratory (LLNL). Funding though the Exascale Computing Project (ECP) Software Technology (ST) project 2.3.1.06 RAJA has fostered outreach and collaboration with the ECP application and software technology development communities. In this report, we describe ECP adoption and integration of these tools to this point. The larger goal of the report is to describe to the ECP community what these projects offer, how they are used, and how to approach adoption and integration of them.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2025

SetBERT: the deep learning platform for contextualized embeddings and explainable predictions from high-throughput sequencing

MOTIVATION: High-throughput sequencing (HTS) is a modern sequencing technology used to profile microbiomes by sequencing thousands of short genomic fragments from the microorganisms within a given sample. This technology presents a unique opportunity for artificial intelligence to comprehend the underlying functional relationships of microbial communities. However, due to the unstructured nature of HTS data, nearly all computational models are limited to processing DNA sequences individually. This limitation causes them to miss out on key interactions between microorganisms, significantly hindering our understanding of how these interactions influence the microbial communities as a whole. Furthermore, most computational methods rely on post-processing of samples which could inadvertently introduce unintentional protocol-specific bias. RESULTS: Addressing these concerns, we present SetBERT, a robust pre-training methodology for creating generalized deep learning models for processing HTS data to produce contextualized embeddings and be fine-tuned for downstream tasks with explainable predictions. By leveraging sequence interactions, we show that SetBERT significantly outperforms other models in taxonomic classification with genus-level classification accuracy of 95%. Furthermore, we demonstrate that SetBERT is able to accurately explain its predictions autonomously by confirming the biological-relevance of taxa identified by the model. AVAILABILITY AND IMPLEMENTATION: All source code is available at https://github.com/DLii-Research/setbert. SetBERT may be used through the q2-deepdna QIIME 2 plugin whose source code is available at https://github.com/DLii-Research/q2-deepdna.

Ludwig, David W↗

DOE OSTI2016

Subsurface Transport Over Multiple Phases Demonstration Software

The STOMP simulator is a suite of numerical simulators developed by Pacific Northwest National Laboratory for addressing problems involving coupled multifluid hydrologic, thermal, geochemical, and geomechanical processes in the subsurface. The simulator has been applied to problems concerning environmental remediation, environmental stewardship, carbon sequestration, conventional petroleum production, and the production of unconventional hydrocarbon fuels. The simulator is copyrighted by Battelle Memorial Institute, and is available outside of PNNL via use agreements. To promote the open exchange of scientific ideas the simulator is provided as source code. A demonstration version of the simulator has been developed, which will provide potential new users with an executable (not source code) implementation of the software royalty free. Demonstration versions will be offered via the STOMP website for all currently available operational modes of the simulator. The demonstration versions of the simulator will be configured with the direct banded linear system solver and have a limit of 1,000 active grid cells. This will provide potential new users with an opportunity to apply the code to simple problems, including many of the STOMP short course problems, without having to pay a license fee. Users will be required to register on the STOMP website prior to receiving an executable.

Source record↗

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 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↗