SEARCH · Engineering Papers

Results for “Software Construction”

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 361 records · Page 20

All sources NASA NTRS DOE OSTI

NASA NTRS1989

The astronaut and the banana peel: An EVA retriever scenario

To prepare for the problem of accidents in Space Station activities, the Extravehicular Activity Retriever (EVAR) robot is being constructed, whose purpose is to retrieve astronauts and tools that float free of the Space Station. Advanced Decision Systems is at the beginning of a project to develop research software capable of guiding EVAR through the retrieval process. This involves addressing problems in machine vision, dexterous manipulation, real time construction of programs via speech input, and reactive execution of plans despite the mishaps and unexpected conditions that arise in uncontrolled domains. The problem analysis phase of this work is presented. An EVAR scenario is used to elucidate major domain and technical problems. An overview of the technical approach to prototyping an EVAR system is also presented.

Shapiro, Daniel G.↗

DOE OSTI2014

Recent improvements to software used for optimization of SRF linacs

This work describes a software tool that allows one to vary parameters and understand the effects on the optimized costs of construction plus 10 year operations of an SRF linac, where operation costs includes the cost of the electrical utilities but not the labor or other costs. The program includes estimates for the associated cryogenic facility, and controls hardware. The software interface provides the ability to vary the cost of the different aspects of the machine as well as to change the cryomodule and cavity types. Additionally, this work will describe the recent improvements to the software that allow one to estimate the costs of energy-recovery based linacs and to enter arbitrary values of the low field Q0 and Q0 slope. The initial goal when developing the software was to convert a spreadsheet format to a graphical interface and to allow the ability to sweep different parameter sets. The tools also allow one to compare the cost of the different facets of the machine design and operations so as to better understand tradeoffs. An example of how it was used to independently investigate cost optimization tradeoffs for the LCLS-II linac will also be presented.

Powers, Tom J.↗

DOE OSTI2021

Santa Barbara Desalination Digital Twin Technical Report

A digital twin is a computer model that has sufficient breadth and fidelity to enable diagnostic and predictive analyses for outputs of interest. We have constructed a digital twin of the SB desal plant using the ProteusLib software developed for NAWI under task 4.2.2, and specifically the ProteusLib models of pumps, filters, mixers, splitters, and reverse osmosis units and a seawater property model. The steps needed to configure this digital twin with the real conditions of the SB desal plant are: (1) Data reconciliation, which is gathering the data and plant connectivity and ensure that all relevant values are present and in the correct units and validating the data using material and energy balances, and correct for errors, gaps, or deviations; (2) Parameter estimation, which is matching model parameters with data from previous step, filling missing parameters with initial estimates, then iteratively refining estimated values. Once we completed the digital twin, we used the optimization capabilities of ProteusLib to compute outputs of interest over a chosen range of inputs. The primary output of interest to the owners of the plant is its specific energy consumption (kWh/acre-foot). The remainder of this report will provide more detail on the data reconciliation, parameter estimation, and analyses we performed.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗

DOE OSTI2024

GQuEST Control System Resolution

This is presentation display of the software theory research I have done this summer in the pursuit of constructing the most optimal FPGA for the GQuEST apparatus.

Nguyễn, David↗

DOE OSTI2021

Reinspection of a Clinical Proteomics Tumor Analysis Consortium (CPTAC) Dataset with Cloud Computing Reveals Abundant Post-Translational Modifications and Protein Sequence Variants

The Clinical Proteomic Tumor Analysis Consortium (CPTAC) has provided some of the most in-depth analyses of the phenotypes of human tumors ever constructed. Today, the majority of proteomic data analysis is still performed using software housed on desktop computers which limits the number of sequence variants and post-translational modifications that can be considered. The original CPTAC studies limited the search for PTMs to only samples that were chemically enriched for those modified peptides. Similarly, the only sequence variants considered were those with strong evidence at the exon or transcript level. In this multi-institutional collaborative reanalysis, we utilized unbiased protein databases containing millions of human sequence variants in conjunction with hundreds of common post-translational modifications. Using these tools, we identified tens of thousands of high-confidence PTMs and sequence variants. We identified 4132 phosphorylated peptides in nonenriched samples, 93% of which were confirmed in the samples which were chemically enriched for phosphopeptides. In addition, our results also cover 90% of the high-confidence variants reported by the original proteogenomics study, without the need for sample specific next-generation sequencing. Finally, we report fivefold more somatic and germline variants that have an independent evidence at the peptide level, including mutations in ERRB2 and BCAS1. In this reanalysis of CPTAC proteomic data with cloud computing, we present an openly available and searchable web resource of the highest-coverage proteomic profiling of human tumors described to date.

60 APPLIED LIFE SCIENCES↗

NASA NTRS1980

System architecture study of an orbital GPS user terminal

The generic RF and applications processing requirements for a GPS orbital navigator are considered. A line of demarcation between dedicated analog hardware, and software/processor implementation, maximizing the latter is discussed. A modular approach to R/PA design which permits several varieties of receiver to be constructed from basic components is described. It is a basic conclusion that software signal processing of the output of the baseband correlator is the best choice of transition from analog to digital signal processing. High performance sets requiring multiple channels are developed from a generic design by replicating the RF processing segment, and modifying the applications software to provide enhanced state propagation and estimation.

Martin, D. P.↗

NASA NTRS1989

A class Hierarchical, object-oriented approach to virtual memory management

The Choices family of operating systems exploits class hierarchies and object-oriented programming to facilitate the construction of customized operating systems for shared memory and networked multiprocessors. The software is being used in the Tapestry laboratory to study the performance of algorithms, mechanisms, and policies for parallel systems. Described here are the architectural design and class hierarchy of the Choices virtual memory management system. The software and hardware mechanisms and policies of a virtual memory system implement a memory hierarchy that exploits the trade-off between response times and storage capacities. In Choices, the notion of a memory hierarchy is captured by abstract classes. Concrete subclasses of those abstractions implement a virtual address space, segmentation, paging, physical memory management, secondary storage, and remote (that is, networked) storage. Captured in the notion of a memory hierarchy are classes that represent memory objects. These classes provide a storage mechanism that contains encapsulated data and have methods to read or write the memory object. Each of these classes provides specializations to represent the memory hierarchy.

Russo, Vincent F.↗

NASA NTRS1991

The M68HC11 gripper controller electronics

This document describes the instrumentation, operational theory, circuit implementation, calibration procedures, and general notes for the CIRSSE general purpose pneumatic hand. The mechanical design and the control software are discussed. The circuit design, PCB layout, hand instrumentation, and controller construction described in detail in this document are the result of a senior project.

Kelley, Robert B.↗

NASA NTRS1999

Intent Specifications: An Approach to Building Human-Centered Specifications

This paper examines and proposes an approach to writing software specifications, based on research in systems theory, cognitive psychology, and human-machine interaction. The goal is to provide specifications that support human problem solving and the tasks that humans must perform in software development and evolution. A type of specification, called intent specifications, is constructed upon this underlying foundation.

Leveson, Nancy G.↗

NASA NTRS2007

Automatic Command Sequence Generation

Automatic Sequence Generator (Autogen) Version 3.0 software automatically generates command sequences for the Mars Reconnaissance Orbiter (MRO) and several other JPL spacecraft operated by the multi-mission support team. Autogen uses standard JPL sequencing tools like APGEN, ASP, SEQGEN, and the DOM database to automate the generation of uplink command products, Spacecraft Command Message Format (SCMF) files, and the corresponding ground command products, DSN Keywords Files (DKF). Autogen supports all the major multi-mission mission phases including the cruise, aerobraking, mapping/science, and relay mission phases. Autogen is a Perl script, which functions within the mission operations UNIX environment. It consists of two parts: a set of model files and the autogen Perl script. Autogen encodes the behaviors of the system into a model and encodes algorithms for context sensitive customizations of the modeled behaviors. The model includes knowledge of different mission phases and how the resultant command products must differ for these phases. The executable software portion of Autogen, automates the setup and use of APGEN for constructing a spacecraft activity sequence file (SASF). The setup includes file retrieval through the DOM (Distributed Object Manager), an object database used to store project files. This step retrieves all the needed input files for generating the command products. Depending on the mission phase, Autogen also uses the ASP (Automated Sequence Processor) and SEQGEN to generate the command product sent to the spacecraft. Autogen also provides the means for customizing sequences through the use of configuration files. By automating the majority of the sequencing generation process, Autogen eliminates many sequence generation errors commonly introduced by manually constructing spacecraft command sequences. Through the layering of commands into the sequence by a series of scheduling algorithms, users are able to rapidly and reliably construct the desired uplink command products. With the aid of Autogen, sequences may be produced in a matter of hours instead of weeks, with a significant reduction in the number of people on the sequence team. As a result, the uplink product generation process is significantly streamlined and mission risk is significantly reduced. Autogen is used for operations of MRO, Mars Global Surveyor (MGS), Mars Exploration Rover (MER), Mars Odyssey, and will be used for operations of Phoenix. Autogen Version 3.0 is the operational version of Autogen including the MRO adaptation for the cruise mission phase, and was also used for development of the aerobraking and mapping mission phases for MRO.

Fisher, Forest↗

DOE OSTI2025

An Agile/XP software development process for modernizing the accelerator control system at Fermilab

Fermilab is undergoing the most ambitious upgrade to its accelerator control system of the 21st century. As part of the ACORN project, hundreds of legacy control system applications written in C/C++ will be re-imagined and developed from the ground up. In addition, applications to support Fermilab’s new super-conducting linear accelerator are already under construction. To manage the development of modern controls applications, the Controls department has adopted an Agile software development process based on eXtreme Programming. In this paper we will describe our process and detail our experience applying it to the development of two case studies.

Diamond, John [Fermilab]↗

NASA NTRS2012

Constructing a Database from Multiple 2D Images for Camera Pose Estimation and Robot Localization

The LMDB (Landmark Database) Builder software identifies persistent image features (landmarks) in a scene viewed multiple times and precisely estimates the landmarks 3D world positions. The software receives as input multiple 2D images of approximately the same scene, along with an initial guess of the camera poses for each image, and a table of features matched pair-wise in each frame. LMDB Builder aggregates landmarks across an arbitrarily large collection of frames with matched features. Range data from stereo vision processing can also be passed to improve the initial guess of the 3D point estimates. The LMDB Builder aggregates feature lists across all frames, manages the process to promote selected features to landmarks, and iteratively calculates the 3D landmark positions using the current camera pose estimations (via an optimal ray projection method), and then improves the camera pose estimates using the 3D landmark positions. Finally, it extracts image patches for each landmark from auto-selected key frames and constructs the landmark database. The landmark database can then be used to estimate future camera poses (and therefore localize a robotic vehicle that may be carrying the cameras) by matching current imagery to landmark database image patches and using the known 3D landmark positions to estimate the current pose.

Wolf, Michael↗

DOE OSTI2026

Towards AI-assisted neutrino flavor theory design

Particle physics theories, such as those which explain neutrino flavor mixing, arise from a vast landscape of model-building possibilities. A model’s construction typically relies on the intuition of theorists. It also requires considerable effort to identify appropriate symmetry groups, assign field representations, and extract predictions for comparison with experimental data. We develop Autonomous Model Builder (AMBer), a framework in which a reinforcement learning agent interacts with a streamlined physics software pipeline to search these spaces efficiently. AMBer selects symmetry groups, particle content, and group representation assignments to construct models while minimizing the number of free parameters introduced. We validate our approach in well-studied regions of theory space and extend the exploration to a previously unexamined symmetry group. While demonstrated in the context of neutrino flavor theories, this approach of reinforcement learning with physics software feedback may be extended to other theoretical model-building problems in the future.

Baretz, Jason Benjamin↗

DOE OSTI2016

SU-F-T-486: A Simple Approach to Performing Light Versus Radiation Field Coincidence Quality Assurance Using An Electronic Portal Imaging Device (EPID)

Purpose: To develop an accurate, straightforward, and user-independent method for performing light versus radiation field coincidence quality assurance utilizing EPID images, a simple phantom made of readily-accessible materials, and a free software program. Methods: A simple phantom consisting of a blocking tray, graph paper, and high-density wire was constructed. The phantom was used to accurately set the size of a desired light field and imaged on the electronic portal imaging device (EPID). A macro written for use in ImageJ, a free image processing software, was then use to determine the radiation field size utilizing the high density wires on the phantom for a pixel to distance calibration. The macro also performs an analysis on the measured radiation field utilizing the tolerances recommended in the AAPM Task Group #142. To verify the accuracy of this method, radiochromic film was used to qualitatively demonstrate agreement between the film and EPID results, and an additional ImageJ macro was used to quantitatively compare the radiation field sizes measured both with the EPID and film images. Results: The results of this technique were benchmarked against film measurements, which have been the gold standard for testing light versus radiation field coincidence. The agreement between this method and film measurements were within 0.5 mm. Conclusion: Due to the operator dependency associated with tracing light fields and measuring radiation fields by hand when using film, this method allows for a more accurate comparison between the light and radiation fields with minimal operator dependency. Removing the need for radiographic or radiochromic film also eliminates a reoccurring cost and increases procedural efficiency.

60 APPLIED LIFE SCIENCES↗

DOE OSTI2018

Directional Software Algorithms and Sensor Evaluations

This report evaluates the relative performance of two directional gamma-ray spectrometers and processing algorithms that are used to construct images and spatially resolved spectra. Polaris, which was developed by H3D Inc., uses 18 pixelated CZT crystals to construct gamma-ray images in either Compton camera(CC) or coded aperture (CA) mode. The other sensor that is referenced in this report incorporates a commercial high-purity germanium based imager, called GeGI, with a coded aperture mask and processing software developed by Oak Ridge National Laboratory (ORNL). H3D and the University of Michigan provided several algorithms that can be used to process data collected by Polaris in CC mode. This evaluation compares the performance of these algorithms with a Directional Unfolded Source Term (DUST) approach developed by Sandia National Laboratories (SNL). DUST differs from the other algorithms because its primary objective is synthesis of spatially-resolved gamma ray spectra as opposed to image reconstruction.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2020

Face Recognition Oak Ridge (FaRO): A Framework for Distributed and Scalable Biometrics Applications

The facial biometrics community has seen a recent abundance of high-accuracy facial analytic models become freely available. Although these models' capabilities in facial detection, landmark detection, attribute analysis, and recognition are ever-increasing, they aren't always straightforward to deploy in a real-world environment. In reality, the use of the field's ever growing collection of models is becoming exceedingly difficult as library dependencies update and deprecate. Researchers often encounter headaches when attempting to utilize multiple models requiring different or conflicting software packages. Face Recognition Oak Ridge (FaRO) is an open-source project designed to provide a highly modular, flexible framework for unifying facial analytic models through a compartmentalized plug-and-play paradigm built on top of the gRPC (Google Remote Procedure Call) protocol. FaRO's server-client architecture and flexible portability allows easy construction of modularized and heterogeneous face analysis pipelines, distributed over many machines with differing hardware and software resources. This paper outlines FaRO's architecture and current capabilities, along with some experiments in model testing and distributed scaling through FaRO.

Bolme, David↗

DOE OSTI2017

Resilience Design Patterns - A Structured Approach to Resilience at Extreme Scale (version 1.2)

We developed a new structured approach to the management of HPC resilience using the concept of resilience-based design patterns. In general, a design pattern is a repeatable solution to a commonly occurring problem. We identified the well-known solutions that are commonly used to deal with faults, errors and failures in HPC systems. In the initial design patterns specification (version 1.0), we described the various solutions, which address specific problems in the design of resilient HPC environments, in the form of patterns. Each pattern describes a problem caused by a fault, error or failure event in an HPC environment, and then describes the core of the solution of the problem in such a way that this solution may be adapted to different systems and implemented at different layers of the system stack. The catalog of these resilience design patterns provides designers with a collection of design elements. To construct complete resilience solutions using combinations of various patterns, we defined a framework that enhances HPC designers’ understanding of the important constraints and the opportunities for the design patterns to be implemented and deployed at various layers of the system stack. The design framework is also useful for establishing interfaces and mechanisms to coordinate flexible fault management across hardware and software components, as well as to consider the trade-off between performance, resilience, and power consumption when constructing a solution. The resilience design patterns specification version 1.1 included more detailed explanations of the pattern solutions, the context in which the patterns are applicable, and the implications for hardware or software design. It also provided several additional examples and detailed case studies to demonstrate the use of patterns to build realistic solutions. In this version 1.2 of the specification document, we have improved the pattern descriptions, including graphical representations of the pattern components. These improvements are largely based on critical comments, feedback and suggestions received from pattern experts and readers of the previous versions of the specification. The pattern classification has been modified to further clarify the relationships between pattern categories. This version of the specification also introduces a pattern language for resilience design patterns. The pattern language presents the patterns in the catalog as a network, revealing the relations among the resilience patterns. The language provides designers with the means to explore alternative techniques for handling a specific fault model that may have different effciency and complexity characteristics. Using the pattern language also enables the design and implementation of comprehensive resilience solutions as a set of interconnected resilience patterns that can be instantiated across layers of the system stack. The overall goal of this work is to provide hardware and software designers, as well as the users and operators of HPC systems, a systematic methodology for the design and evaluation of resilience technologies in HPC systems that keep scientific applications running to a correct solution in a timely and cost-effcient manner despite frequent faults, errors, and failures of various types.

97 MATHEMATICS AND COMPUTING↗

NASA NTRS1993

Automated propellant leak detection

An automated hydrogen leak detection system is being developed for earth-to-orbit rocket engine applications. The system consists of three elements, a sensor array, a signal processing unit, and a diagnostic processor. The sensor array consists of discrete solid state sensors which are located at specific potential leak sites and in potential leak zones. The signal processing unit provides excitations power for the sensors and provides analog to digital data conversion of the sensor signals. The diagnostic computer analyzes the sensor outputs to determine leak sources and magnitude. Leak data from the sensor network is interpreted using knowledge based software and displayed on-line through a graphical user interface including 3-D leak visualization. The system requirements have been developed assuming eventual application to the Space Shuttle Main Engine which requires approximately 72 measurement locations. A prototype system has been constructed to demonstrate the operational features of the system. This system includes both prototype electronics and data processing software algorithms. Experiments are in progress to evaluate system operation at conditions which simulate prelaunch and flight. The prototype system consists of a network using 16 sensors within a testbed which simulates engine components. Sensor response, orientation, and data analysis algorithms are being evaluated using calibrated leaks produced within the testbed. A prototype flight system is also under development consisting of 8 sensors and flight capable electronics with autonomous control and data recording.

Makel, D. B.↗