Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software development”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 1,351 records · Page 75

DADiSP processing guide

A guide for DADiSP software, intended for use by the Lambda Point Experiment (LPE) Team during and after the United States Microgravity Payload (USMP)-1 mission, is presented. DADiSP is a Data Analysis and Display Software developed and marketed by DSP Development Corporation, Cambridge, Massachusetts. This guide is intended to be used in addition to the DADiSP Worksheet User Manual and Reference Manual which are supplied by the company with the software. Technical support for DADiSP is available from DSP at (617) 577-1133. Access to DADiSP on Acceleration Characterization and Analysis Project (ACAP) EGSE is being provided to the LPE team during USMP-1 for off-line processing of SAMS data.

Rogers, Melissa J. B.↗

Flight Dynamics Mission Support and Quality Assurance Process

This paper summarizes the method of the Computer Sciences Corporation Flight Dynamics Operation (FDO) quality assurance approach to support the National Aeronautics and Space Administration Goddard Space Flight Center Flight Dynamics Support Branch. Historically, a strong need has existed for developing systematic quality assurance using methods that account for the unique nature and environment of satellite Flight Dynamics mission support. Over the past few years FDO has developed and implemented proactive quality assurance processes applied to each of the six phases of the Flight Dynamics mission support life cycle: systems and operations concept, system requirements and specifications, software development support, operations planing and training, launch support, and on-orbit mission operations. Rather than performing quality assurance as a final step after work is completed, quality assurance has been built in as work progresses in the form of process assurance. Process assurance activities occur throughout the Flight Dynamics mission support life cycle. The FDO Product Assurance Office developed process checklists for prephase process reviews, mission team orientations, in-progress reviews, and end-of-phase audits. This paper will outline the evolving history of FDO quality assurance approaches, discuss the tailoring of Computer Science Corporations's process assurance cycle procedures, describe some of the quality assurance approaches that have been or are being developed, and present some of the successful results.

Oh, InHwan↗

Comparison of the NASCAP/GEO, POLAR, SEE Charging Handbook, and NASCAP-2K.1 Spacecraft Charging Codes

The NASA Charging Analyzer Program (NASCAP) spacecraft charging software developed by Maxwell Technologies has been widely used for the past fifteen to twenty years in satellite design and investigation of spacecraft charging related anomalies. Individual versions of the NASCAP software are available for use in low inclination, low Earth orbit environments (NASCAP[LEO) and geostationary orbit environments (NASCAP/GEO). In addition, the Potentials of Large objects in the Auroral Region (POLAR) code is available for use in LEO polar orbit environments. NASCAP/GEO and POLAR were both written in the 1980's using algorithms appropriate for the computers of the time. They solve the Poisson-Vlasov system for currents and densities assuming limited speed and memory of computer systems standard for the day. In addition, use of the charging models requires individual input files that are not readily transported into the various codes to facilitate comparison of results by the user.

Neergaard, Linda E.↗

From Shuttle Main Engine to the Human Heart: A Presentation to the Federal Lab Consortium for Technology Transfer

A NASA engineer received a heart transplant performed by Drs. DeBakey and Noon after suffering a serious heart attack. 6 months later that engineer returned to work at NASA determined to use space technology to help people with heart disease. A relationship between NASA and Drs. DeBakey and Noon was formed and the group worked to develop a low cost, low power implantable ventricular assist device (VAD). NASA patented the method to reduce pumping damage to red blood cells and the design of a continuous flow heart pump (#5,678,306 and #5,947,892). The technology and methodology were licensed exclusively to MicroMed Technology, Inc.. In late 1998 MicroMed received international quality and electronic certifications and began clinical trials in Europe. Ventricular assist devices were developed to bridge the gap between heart failure and transplant. Early devices were cumbersome, damaged red blood cells, and increased the risk of developing dangerous blood clots. Application emerged from NASA turbopump technology and computational fluid dynamics analysis capabilities. To develop the high performance required of the Space Shuttle main engines, NASA pushed the state of the art in the technology of turbopump design. NASA supercomputers and computational fluid dynamics software developed for use in the modeling analysis of fuel and oxidizer flow through rocket engines was used in the miniaturization and optimization of a very small heart pump. Approximately 5 million people worldwide suffer from chronic heart failure at a cost of 40 billion dollars In the US, more than 5000 people are on the transplant list and less than 3000 transplants are performed each year due to the lack of donors. The success of ventricular assist devices has led to an application as a therapeutic destination as well as a bridge to transplant. This success has been attributed to smaller size, improved efficiency, and reduced complications such as the formation of blood clots and infection.

Fogarty, Jennifer A.↗

Mechanistic source terms for the XE-100 reactor XSTERM Code Development Approach - 18587

X-Energy is developing the Xe-100 pebble bed modular High Temperature Gas Reactor (HTGR) as an advanced nuclear power source. To achieve its safety objectives, the Xe-100 reactor relies on materials inherent characteristics and passive safety features. Key features include the inherent high temperature characteristics of TRISO-coated fuel particles, graphite moderator, and helium coolant, along with passive heat removal capability of a low-power-density core. This paper will describe the approach adopted by X-Energy to develop and validate mechanistic source terms for the Xe-100. The Mechanistic Source Term (MST) approach for the Xe-100 reactor will build upon that of the prior DOE Next Generation Nuclear Program (NGNP) (Refs. 1, 2, 3 and 4). MST development is closely related to Fuel Qualification (FQ), Licensing Basis Event (LBE) selection and Probabilistic Risk Assessment (PRA). This paper provides a brief overview of the MST road map process. Software plays a crucial role in establishing and quantifying MSTs required for licensing the Xe-100. An insight into X-Energy s comprehensive, integrated software development program for calculating time-dependent radionuclide releases from the Xe-100 over a wide range of events is provided. (authors)

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗

A Python Library for Radiance Matrix-based Simulation Control and EnergyPlus Integration

Radiance matrix-based methods enable efficient parametric simulations, allowing users to vary sky conditions, fenestration systems, and other model parameters at a minimal cost to computation. However, the steep learning curve and complex workflow hinder the widespread adoption of matrix-based methods. The frads Python library with a series of command-line tools was developed to automate the entire matrix-based simulation process, lowering entry barriers and reducing human error. Co-simulation between EnergyPlus and Radiance was also enabled using the Python library from EnergyPlus. Key Innovations • Command-line based automation of Radiance matrix-based simulation methods • Python library facilitates broader adoption of Radiance matrix-based simulation methods • Radiance EnergyPlus run-time integration enabling the modeling of advanced control systems Practical Implications The frads library, with associated command-line tools, provides practitioners with the capability to easily adopt and use Radiance matrix-based simulation methods for various daylighting, solar control, and energy-related evaluations. Frads' current form is designed for 1) users familiar with a command-line interface and 2) software developers to integrate the matrix-based methods into existing software packages.

Wang, Taoning↗

WE-G-9A-01: Radiation Oncology Outcomes Informatics

The construction of databases and support software to enable routine and systematic aggregation, analysis and reporting of patient outcomes data is emerging as an important area. “How have results for our patients been affected by the improvements we have made in our practice and in the technologies we use?” To answer this type of fundamental question about the overall pattern of efficacy observed, it is necessary to systematically gather and analyze data on all patients treated within a clinic. Clinical trials answer, in great depth and detail, questions about outcomes for the subsets of patients enrolled in a given trial. However, routine aggregation and analysis of key treatment parameter data and outcomes information for all patients is necessary to recognize emergent patterns that would be of interest from a public health or practice perspective and could better inform design of clinical trials or the evolution of best practice principals. To address these questions, Radiation Oncology outcomes databases need to be constructed to enable combination essential data from a broad group of data types including: diagnosis and staging, dose volume histogram metrics, patient reported outcomes, toxicity metrics, performance status, treatment plan parameters, demographics, DICOM data and demographics. Developing viable solutions to automate aggregation and analysis of this data requires multidisciplinary efforts to define nomenclatures, modify clinical processes and develop software and database tools requires detailed understanding of both clinical and technical issues. This session will cover the developing area of Radiation Oncology Outcomes Informatics. Learning Objectives: Audience will be able to speak to the technical requirements (software, database, web services) which must be considered in designing an outcomes database. Audience will be able to understand the content and the role of patient reported outcomes as compared to traditional toxicity measures. Audience will be understand approaches, clinical process changes, consensus building efforts and standardizations which must be addressed to succeed in a multi-disciplinary effort to aggregate data for all patients. Audience will be able to discuss technical and process issues related to pooling data among institutions in the context of collaborative studies among the presenting institutions.

60 APPLIED LIFE SCIENCES↗

Quality control for community-based sea-ice model development

A new collaborative organization for sea-ice model development, the CICE Consortium, has devised quality control procedures to maintain the integrity of its numerical codes' physical representations, enabling broad participation from the scientific community in the Consortium's open software development environment. Using output from five coupled and uncoupled configurations of the Los Alamos Sea Ice Model, CICE, we formulate quality control methods that exploit common statistical properties of sea-ice thickness, and test for significant changes in model results in a computationally efficient manner. New additions and changes to CICE are graded into four categories, ranging from bit-for-bit amendments to significant, answer-changing upgrades. These modifications are assessed using criteria that account for the high level of autocorrelation in sea-ice time series, along with a quadratic skill metric that searches for hemispheric changes in model answers across an array of different CICE configurations. These metrics also provide objective guidance for assessing new physical representations and code functionality.

58 GEOSCIENCES↗

Engineering Computational Practices (Rev. 1)

This manual will attempt to motivate the use of an automated build system for the purposes of computational science and engineering. As part of this motivation, the surrounding computational practices of version control, documen tation, compute environment management, and regression testing will also be addressed as applied to the practice of computational engineering. Specifically, this manual intends to motivate the adoption of these traditional software engineering practices for use in research and production engineering simulation projects. This manual is not the first such effort in the greater scientific computing community. In fact, the authors relied heavily on the lesson plans of the Software Carpentry, established to teach computing skills to researchers in 1998. As the intention for this manual is to lay out fundamental practices of engineering computing, it will not attempt to fully teach the underlying concepts and will instead reference the well designed lesson plans of the Software Carpentry. Where possible, this manual will explain to general computing practices and concepts and limit discussion of specific software implementations to examples or vehicles for practice in concrete application. The specific software taught by the Software Carpentry curriculum is an excellent starting point to learn the core concepts of computational engi neering. However, the authors have found that applications to engineering simulation and analysis require translation of these software development concepts into the language and workflows of computational engineers. Adopting these computational tools may require engineers to re-imagine their workflows in some combination of traditional engineer ing and software concepts. It has also been necessary to extend existing software build systems for engineering practices beyond the simple wrap ping of engineering software execution. Where necessary, examples of specific software and their method of extension to engineering simulations will be given, with reference to the User Manual for recommended practical use. Where this manual relies on specific implementation examples, it should be understood that the practicing engineer may find that different software is more amenable to their specific work. It is always the overall collection of computational practices is more important than any specific software implementation. The ability to recognize which concepts are implemented by a software package will make a practicing engineer agile to changing project needs, computing resources, numeric solvers, programming languages, and even available funding.

42 ENGINEERING↗

Regular Topologies for Gigabit Wide-Area Networks

In general terms, this project aimed at the analysis and design of techniques for very high-speed networking. The formal objectives of the project were to: (1) Identify switch and network technologies for wide-area networks that interconnect a large number of users and can provide individual data paths at gigabit/s rates; (2) Quantitatively evaluate and compare existing and proposed architectures and protocols, identify their strength and growth potentials, and ascertain the compatibility of competing technologies; and (3) Propose new approaches to existing architectures and protocols, and identify opportunities for research to overcome deficiencies and enhance performance. The project was organized into two parts: 1. The design, analysis, and specification of techniques and protocols for very-high-speed network environments. In this part, SRI has focused on several key high-speed networking areas, including Forward Error Control (FEC) for high-speed networks in which data distortion is the result of packet loss, and the distribution of broadband, real-time traffic in multiple user sessions. 2. Congestion Avoidance Testbed Experiment (CATE). This part of the project was done within the framework of the DARTnet experimental T1 national network. The aim of the work was to advance the state of the art in benchmarking DARTnet's performance and traffic control by developing support tools for network experimentation, by designing benchmarks that allow various algorithms to be meaningfully compared, and by investigating new queueing techniques that better satisfy the needs of best-effort and reserved-resource traffic. This document is the final technical report describing the results obtained by SRI under this project. The report consists of three volumes: Volume 1 contains a technical description of the network techniques developed by SRI in the areas of FEC and multicast of real-time traffic. Volume 2 describes the work performed under CATE. Volume 3 contains the source code of all software developed under CATE.

Shacham, Nachum↗

A SPDS Node to Support the Systematic Interpretation of Cosmic Ray Data

The purpose of this project was to establish and maintain a Space Physics Data System (SPDS) node that supports the analysis and interpretation of current and future galactic cosmic ray (GCR) measurements by (1) providing on-line databases relevant to GCR propagation studies; (2) providing other on-line services, such as anonymous FTP access, mail list service and pointers to e-mail address books, to support the cosmic ray community; (3) providing a mechanism for those in the community who might wish to submit similar contributions for public access; (4) maintaining the node to assure that the databases remain current; and (5) investigating other possibilities, such as CD-ROM, for public dissemination of the data products. Shortly after the original grant to support these activities was established at Louisiana State University a detailed study of alternate choices for the node hardware was initiated. The chosen hardware was an Apple Workgroup Server 9150/120 consisting of a 120 MHz PowerPC 601 processor, 32 MB of memory, two I GB disks and one 2 GB disk. This hardware was ordered and installed and has been operating reliably ever since. A preliminary version of the database server was available during the first year effort and was used as part of the very successful SPDS demonstration during the Rome, Italy International Cosmic Ray Conference. For this server version we were able to establish the html and anonymous FTP server software, develop a Web page structure which can be easily modified to include new items, provide an on-line database of charge changing total cross sections, include the cross section prediction software of Silberberg & Tsao as well as Webber, Kish and Schrier for download access, and provide an on-line bibliography of the cross section measurement references by the Transport Collaboration. The preliminary version of this SPDS Cosmic Ray node was examined by members of the C&H SPDS committee and returned comments were used to refine the implementation.

Source record↗

An Integrated Development Environment for the Prototype Verification System

The steep learning curve of formal technologies is a well-known barrier to the adoption of formal verification tools in industry. This paper presents VSCode-PVS, a modern integrated development environment for the Prototype Verification System (PVS). This new environment integrates the editing and proof management functionalities of PVS in Visual Studio Code, a popular code editor widely used by software developers. VSCode-PVS provides functionalities that developers expect to find in modern verification tools but are not available in the standard Emacs front-end of PVS, such as auto-completion, point-and-click navigation of definitions, live diagnostics for errors, and literate programming. The main features and architecture of the environment are presented, along with a comparison with other similar tools.

Paolo Masci↗

Freddie Software Security Patching

Software applications become more complicated over time as they depend on many third-party, open-source libraries. The Freddie Platform Services team actively improves software security by addressing software bugs and vulnerabilities that negatively impact software applications, especially those providing real-time operations and services for the federal partners and industries. In order to detect bugs and patch vulnerabilities in software development and maintenance cycles, an automated and systematic approach is needed. This document describes what bugs and vulnerabilities are, and how they can be detected by using static code analyzers and software composition analysis tools. Once vulnerabilities are detected, the patching approaches, such as upgrading direct and transitive dependencies and loading custom classes first, are presented together with their strengths and weaknesses. In addition, patching walkthrough, example code, lessons learned throughout the vulnerability patching process and the recommended practices are discussed.

Chok Fung Lai↗

Flight Controller Software Protects Lightweight Flexible Aircraft

Lightweight flexible aircraft may be the future of aviation, but a major problem is their susceptibility to flutter-uncontrollable vibrations that can destroy wings. Armstrong Flight Research Center awarded SBIR funding to Minneapolis, Minnesota-based MUSYN Inc. to develop software that helps program flight controllers to suppress flutter. The technology is now available for aircraft manufacturers and other industries that use equipment with automated controls.

Source record↗

SU-F-J-100: Standardized Biodistribution Template for Nuclear Medicine Dosimetry Collection and Reporting

Purpose: As the field of Nuclear Medicine moves forward with efforts to integrate radiation dosimetry into clinical practice we can identify the challenge posed by the lack of standardized dose calculation methods and protocols. All personalized internal dosimetry is derived by projecting biodistribution measurements into dosimetry calculations. In an effort to standardize organization of data and its reporting, we have developed, as a sequel to the EANM recommendation of “Good Dosimetry Reporting”, a freely available biodistribution template, which can be used to create a common point of reference for dosimetry data. It can be disseminated, interpreted, and used for method development widely across the field. Methods: A generalized biodistribution template was built in a comma delineated format (.csv) to be completed by users performing biodistribution measurements. The template is available for free download. The download site includes instructions and other usage details on the template. Results: This is a new resource developed for the community. It is our hope that users will consider integrating it into their dosimetry operations. Having biodistribution data available and easily accessible for all patients processed is a strategy for organizing large amounts of information. It may enable users to create their own databases that can be analyzed for multiple aspects of dosimetry operations. Furthermore, it enables population data to easily be reprocessed using different dosimetry methodologies. With respect to dosimetry-related research and publications, the biodistribution template can be included as supplementary material, and will allow others in the community to better compare calculations and results achieved. Conclusion: As dosimetry in nuclear medicine become more routinely applied in clinical applications, we, as a field, need to develop the infrastructure for handling large amounts of data. Our organ level biodistribution template can be used as a standard format for data collection, organization, as well as for dosimetry research and software development.

60 APPLIED LIFE SCIENCES↗

Study of a Docker Use-Case for HEP

Over the past few years, container technology has become increasingly promising as a means to seamlessly make our software available across a wider range of platforms. In December 2015, we decided to put together a set of docker images that serve as a demonstration of this container technology for managing a run-time environment for art-related software projects, and also serve as a set of test cases for evaluation of performance. Docker[1] containers provide a way to “wrap up a piece of software in a complete filesystem that contains everything it needs to run”. In combination with Shifter[2], such containers provide a way to run software developed and deployed on “typical” HEP platforms (such as SLF 6, in common use at Fermilab and on OSG platforms) on HPC facilities at NERSC. Docker containers provide a means of delivering software that can be run on a variety of hosts without needing to be compiled specially for each OS to be supported. This could substantially reduce the effort required to create and validate a new release, since one build could be suitable for use on both grid machines (both FermiGrid and OSG) as well as any machine capable of running the Docker container. In addition, docker containers may provide for a quick and easy way for users to install and use a software release in a standardized environment. This report contains the results and status of this demonstration and evaluation.

97 MATHEMATICS AND COMPUTING↗

Enhancements supporting IC usage of PEM libraries on next-gen platforms

This milestone reports on the culmination of several years of effort by multiple PEM support software development teams to provide capabilities for use in LLNL-developed integrated codes on next-gen ASC platforms, including GPU support. We will provide a survey of relevant Application Program Interfaces (API) that are required to support LLNL IC code capability on relevant architectures, with a focus on Sierra and El Capitan. We will identify and summarize all dependencies between PEM supported libraries and IC supported physics codes. We will provide an assessment of algorithmic improvements that have been deployed, as well as future developments that are required to complete the GPU porting efforts. This assessment will include a description of programming models adopted by each of the PEM projects, distinct algorithmic challenges for each of the capabilities, and information about sharing GPU memory between the APIs and host codes. We will develop targeted test problems to assess computational performance. Finally, this milestone will result in identification of gaps in our effort to assist the LLNL ASC program in prioritization of effort for porting software to El Capitan.

97 MATHEMATICS AND COMPUTING↗