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 181 records · Page 10

All sources NASA NTRS DOE OSTI

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↗

NASA NTRS1995

Software engineering capability for Ada (GRASP/Ada Tool)

The GRASP/Ada project (Graphical Representations of Algorithms, Structures, and Processes for Ada) has successfully created and prototyped a new algorithmic level graphical representation for Ada software, the Control Structure Diagram (CSD). The primary impetus for creation of the CSD was to improve the comprehension efficiency of Ada software and, as a result, improve reliability and reduce costs. The emphasis has been on the automatic generation of the CSD from Ada PDL or source code to support reverse engineering and maintenance. The CSD has the potential to replace traditional prettyprinted Ada Source code. A new Motif compliant graphical user interface has been developed for the GRASP/Ada prototype.

Cross, James H., II↗

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↗

NASA NTRS1975

Advances in data compression

A rigorous real-variables treatment of general data compression and encoding problems, centered on formulation and proof of relevant existence theorems and a unified formulation of source coding (both noiseless and with a fidelity criterion) in inaccurately or incompletely specified statistical environments. Difficulties in modeling of sources with unknown or imperfectly known statistical descriptions are analyzed and source codes (SC) are classified (variable-rate noiseless SC, fixed-rate noiseless SC) and analyzed, along with types of code sequences (weighted-universal, maximin-universal, strongly or weakly minimax-universal). Universal coding on video data, variable-rate coding with distortion, and distortion-rate functions are discussed. Design strategies for universal coding algorithms are suggested, but the article is not oriented to specific methods of synthesizing data compression systems.

Davisson, L. D.↗

NASA NTRS2010

Support for Systematic Code Reviews with the SCRUB Tool

SCRUB is a code review tool that supports both large, team-based software development efforts (e.g., for mission software) as well as individual tasks. The tool was developed at JPL to support a new, streamlined code review process that combines human-generated review reports with program-generated review reports from a customizable range of state-of-the-art source code analyzers. The leading commercial tools include Codesonar, Coverity, and Klocwork, each of which can achieve a reasonably low rate of false-positives in the warnings that they generate. The time required to analyze code with these tools can vary greatly. In each case, however, the tools produce results that would be difficult to realize with human code inspections alone. There is little overlap in the results produced by the different analyzers, and each analyzer used generally increases the effectiveness of the overall effort. The SCRUB tool allows all reports to be accessed through a single, uniform interface (see figure) that facilitates brows ing code and reports. Improvements over existing software include significant simplification, and leveraging of a range of commercial, static source code analyzers in a single, uniform framework. The tool runs as a small stand-alone application, avoiding the security problems related to tools based on Web browsers. A developer or reviewer, for instance, must have already obtained access rights to a code base before that code can be browsed and reviewed with the SCRUB tool. The tool cannot open any files or folders to which the user does not already have access. This means that the tool does not need to enforce or administer any additional security policies. The analysis results presented through the SCRUB tool s user interface are always computed off-line, given that, especially for larger projects, this computation can take longer than appropriate for interactive tool use. The recommended code review process that is supported by the SCRUB tool consists of three phases: Code Review, Developer Response, and Closeout Resolution. In the Code Review phase, all tool-based analysis reports are generated, and specific comments from expert code reviewers are entered into the SCRUB tool. In the second phase, Developer Response, the developer is asked to respond to each comment and tool-report that was produced, either agreeing or disagreeing to provide a fix that addresses the issue that was raised. In the third phase, Closeout Resolution, all disagreements are discussed in a meeting of all parties involved, and a resolution is made for all disagreements. The first two phases generally take one week each, and the third phase is concluded in a single closeout meeting.

Holzmann, Gerald J.↗

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↗

NASA NTRS1973

Study of information transfer optimization for communication satellites

The results are presented of a study of source coding, modulation/channel coding, and systems techniques for application to teleconferencing over high data rate digital communication satellite links. Simultaneous transmission of video, voice, data, and/or graphics is possible in various teleconferencing modes and one-way, two-way, and broadcast modes are considered. A satellite channel model including filters, limiter, a TWT, detectors, and an optimized equalizer is treated in detail. A complete analysis is presented for one set of system assumptions which exclude nonlinear gain and phase distortion in the TWT. Modulation, demodulation, and channel coding are considered, based on an additive white Gaussian noise channel model which is an idealization of an equalized channel. Source coding with emphasis on video data compression is reviewed, and the experimental facility utilized to test promising techniques is fully described.

Odenwalder, J. P.↗

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↗