Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “COMPUTER PROGRAM DOCUMENTATION”

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 739 records · Page 41
All sourcesNASA NTRSDOE OSTI
DOE OSTI2019

GALE 3.2 Verification Report

This report is documentation of the verification activities that have been performed on GALE-3.2 to ensure that the codes meet the requirements and specifications set forth by NRC and that the code meets its intended purpose. These activities are done in accordance with the GALE Software Quality Assurance Plan (PNNL-24249) and the GALE Configuration Management & Maintenance Plan (PNNL-24250). These two plans meet the requirements set for by both PNNL software quality assurance requirements and the NRC’s Software Quality Assurance Program and Guidelines (NUREG/BR-0167). The verification activities are documented to conform to Level 2 requirements of NUREG/BR-0167. Verifications were performed for both GALE-3.2 BWR and GALE-3.2 PWR Codes. The GALE 3.2 BWR and PWR codes are computerized mathematical models for calculating the releases of radioactive material in gaseous and liquid effluents. These computer codes are tools which can be used to determine conformance with the requirements of Appendix I to Title 10, Part 50 of the Code of Federal Regulations (10 CFR 50).

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS1978

Programming in HAL/S

HAL/S is a computer programming language; it is a representation for algorithms which can be interpreted by either a person or a computer. HAL/S compilers transform blocks of HAL/S code into machine language which can then be directly executed by a computer. When the machine language is executed, the algorithm specified by the HAL/S code (source) is performed. This document describes how to read and write HAL/S source.

Ryer, M. J.↗
NASA NTRS1989

KSC ice/frost/debris assessment for Space Shuttle Mission STS-30R

An ice/frost/debris assessment was conducted for Space Shuttle Mission STS-30R. Debris inspections of the flight elements and launch pad are performed before and after launch. Ice/frost conditions on the external tank are assessed by the use of computer programs, nomographs, and infrared scanner data during cryogenic loading of the vehicle followed by an on-pad visual inspection. High speed photography is analyzed after launch to identify ice/debris sources and evaluate potential vehicle damage. The ice/frost/debris conditions of Mission STS-30R and their overall effect on the Space Shuttle Program is documented.

Stevenson, Charles G.↗
DOE OSTI2024

New systems in MOOSE

The Multiphysics Object-Oriented Simulation Environment (MOOSE) serves as a common library of classes between applications developed for advanced reactor analysis, fusion device engineering, spent fuel cask analysis, geochemistry studies, among other fields. These applications drive the development of the framework to meet their needs. Systems in MOOSE group capabilities that share a common purpose and generally common code. They can be leveraged by all downstream applications, providing extensive code re-use and shared maintenance. They facilitate the discovery by new users of the classes meeting at least partially their needs, and offer the same opportunities for customization as other systems. The addition of a new system to MOOSE opens new ways of solving or discretizing nonlinear problems, of performing distributed postprocessing, and a plethora of other needs. While new systems can be introduced in downstream applications rather than at the framework level, the framework team monitors common needs across the community and often triggers their addition. Documentation, training material, development needs can be centralized, limiting duplicated work across the community. The last three years have seen a large expansion in the capabilities of MOOSE. The supporting role of the framework in the Nuclear Energy Advanced Modeling and Simulation (NEAMS) program has created numerous feature requests to support neutronics, thermal hydraulics, computational fluid dynamics and thermo-mechanics simulations in the Griffin, SAM, Pronghorn and Bison applications respectively. Similarly, laboratory-directed research and development (LDRD) projects in additive manufacturing, high-Reynolds flow simulations, structure optimization also necessitate an expansion of the framework capabilities. This summary reports on the new systems created in MOOSE, their design, their capabilities and some of the relevant interfaces.

22 - GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS2011

Towards a Standard for Provenance and Context for Preservation of Data for Earth System Science

Long-term data sets with data from many missions are needed to study trends and validate model results that are typical in Earth System Science research. Data and derived products originate from multiple missions (spaceborne, airborne and/or in situ) and from multiple organizations. During the missions as well as well past their termination, it is essential to preserve the data and products to support future studies. Key aspects of preservation are: preserving bits and ensuring data are uncorrupted, preserving understandability with appropriate documentation, and preserving reproducibility of science with appropriate documentation and other artifacts. Computer technology provides adequate standards to ensure that, with proper engineering, bits are preserved as hardware evolves. However, to ensure understandability and reproducibility, it is essential to plan ahead to preserve all the relevant data and information. There are currently no standards to identify the content that needs to be preserved, leading to non-uniformity in content and users not being sure of whether preserved content is comprehensive. Each project, program or agency can specify the items to be preserved as a part of its data management requirements. However, broader community consensus that cuts across organizational or national boundaries would be needed to ensure comprehensiveness, uniformity and long-term utility of archived data. The Federation of Earth Science Information Partners (ESIP), a diverse network of scientists, data stewards and technology developers, has a forum for ESIP members to collaborate on data preservation issues. During early 2011, members discussed the importance of developing a Provenance and Context Content Standard (PCCS) and developed an initial list of content items. This list is based on the outcome of a NASA and NOAA meeting held in 1998 under the auspices of the USGCRP, documentation requirements from NOAA and our experience with some of the NASA Earth science missions. The items are categorized into the following 8 high level categories: Preflight/Pre-Operations, Products (Data), Product Documentation, Mission Calibration, Product Software, Algorithm Input, Validation, Software Tools.

Ramaprian, Hampapuram K.↗
DOE OSTI2016

Water Network Tool for Resilience Version 0.1

Water utilities are vulnerable to a wide variety of human-caused and natural disasters. These disruptive events can result in loss of water service, contaminated water, pipe breaks, and failed equipment. Furthermore, long term changes in water supply and customer demand can have a large impact on the operating conditions of the network. The ability to maintain drinking water service during and following these types of events is critical. Simulation and analysis tools can help water utilities explore how their network will respond to disruptive events and plan effective mitigation strategies. The U.S. Environmental Protection Agency and Sandia National Laboratories are developing new software tools to meet this need. The Water Network Tool for Resilience (WNTR, pronounced winter) is a Python package designed to help water utilities investigate resilience of water distribution systems over a wide range of hazardous scenarios and to evaluate resilience-enhancing actions. The following documentation includes installation instructions and examples, description of software features, and software license. It is assumed that the reader is familiar with the Python Programming Language.

42 ENGINEERING↗
DOE OSTI2022

VERAView Programmer’s Manual

VERAView’s component-based design facilitates its extension and integration into other applications and systems. In addition to describing VERAView’s architecture and components, this document provides details on the component application programming interfaces (APIs), illustrates how to use the APIs independently of VERAView itself, and explains how to extend VERAView with custom visualizations.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

Countering Weapons of Mass Destruction (CWMD) Device Cybersecurity Characterization Process and Profile

Countering Weapons of Mass Destruction (CWMD) recognizes that threats in the cyberspace domain continue to grow, which requires CWMD devices and supporting systems to be both cybersecure (ability to protect or defend from cyber-attacks) and resilient (ability to maintain required capability in the face of adversity) to cyber threats. The CWMD cybersecurity characterization approach in this document supports existing cyber resilience activities within the Acquisition Lifecycle Framework. Similarly, this process supports existing Department of Homeland Security Cyber Resilience Test and Evaluation activities, which consist of iterative processes, starting at the initiation of system acquisition and continuing throughout the entire device and system life cycle. Cyber resilience is the ability of an information system to continue to operate while under attack, even if in a degraded or debilitated state,1 and to rapidly recover operational capabilities for essential functions after a successful attack.2 The goal of the security characterization task for CWMD is to support the development of a CBRN device-dependent profile that aligns with device network capabilities and maps to recommended security controls to create a characterization security profile impact levels. The impact levels for CWMD devices should be characterized as Low (L), Moderate (M), High (H) to align with the low, moderate, high control baselines. To estimate the impact levels, the device’s security-related attributes are translated into the security objectives: Confidentiality (C), Integrity (I), and Availability (A), known as the CIA triad. The potential impact for each device can be L, M, H, for devices that connect and transmit different types of data and may have different impact levels. National Institute of Standards and Technology Federal Information Processing Standards Publication 199 states, “the potential impact values assigned to the respective security objectives shall be the highest value from among those security categories that have been determined for each type of information resident on the information system.”3 As CWMD is determining the cybersecurity impact levels of CBRN devices based on network connections and data transfers, the impact levels are aligned with the associated attributes of network connections and communications. For example, if the device system is connected to a wireless network and transmits different data types based on the confidentiality of the data, the highest impact value for each security objective should represent the device’s CIA impact level. This document is intended to be used by test managers, test team, and program managers.

45 MILITARY TECHNOLOGY, WEAPONRY, AND NATIONAL DEF↗
DOE OSTI2018

An Open-Access Nuclear Knowledge and Innovation Toolkit to Make Use of Nuclear World and Increase Collaboration

Nuclear engineering began as an urgent weapons development program in the early 1940s, involving work in enrichment, reactor design, shielding design, and isotope production. This work led to investigations of peaceful uses of nuclear technology, including nuclear power production and applications of radiation. Such peaceful technologies, often derived from experience gained through the weapons program, often maintained some level or attitude of secrecy. As the field continued to develop, that secrecy led to different specializations developing with different sets of terminology and methods of computation. For example, radiation safety used buildup and shielding factors while reactor designers use diffusivity and cross sections. Impressive amounts of work went into theory and application development in each sub-field over the next few decades, with much of the work left without adequate documentation or with important documentation made only within the organization. This situation has led to a loss of knowledge and experience, a lack of collaboration across nuclear sub-fields, and immense amounts of time and effort spent on redundant work. This paper proposes an open-access system that combines preserving and passing on the knowledge in all nuclear sub-fields with tools to make that knowledge useful, referred to as the Nuclear Knowledge and Innovation Toolkit (NuKIT). Knowledge would be captured in user-entered and expert-verified databases of reactors, applications of radiation, isotope production methods, and other pertinent nuclear information complete with technical information and tags that can be used to organize and investigate the data. Tools include community tools like forums and the ability to create collaborative projects; visualization and presentation tools; and an online programming system that allows code sharing, collaborative editing, database manipulation, and integration with all other tools. Finally, NuKIT is envisioned to include commercialization tools to allow freelance work and to compensate data entry/moderation work to help encourage participation. Eventually, integration with industry-standard tools like MCNP, SCALE, etc. is expected. This paper will present some proposed work in the context of its use for isotopes and radiation application, as well as possible work to be done in the context of the Combined Materials Experimental Toolkit (CoMET) being developed by the Nuclear Science User Facilities (NSUF) program. It should be noted that any work done towards this system, by any group, will advance the full system. It should also be noted that similar work previously done can be integrated into NuKIT.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS1995

Summer Institute in Engineering and Computer Applications: Learning Through Experience

The document describing the Summer Institute project is made up of the following information: Administrative procedures; Seminars/Special Courses/Tours/College fair; Facilities/ Transportation; Staff and Administration; Collaboration; Participant/Project monitoring and evaluation; Fiscal and developmental activities; Job readiness/Job internship development and placement; and Student Follow-up/Tracking. Appendices include presentations, self-evaluations; abstracts and papers developed by the students during their participation in the program.

Langdon, Joan S.↗
DOE OSTI2017

Initial CEED API (CEED-MS10)

Key components of CEED software development involve fast finite element operator storage and evaluation, architecture optimizations, performant algorithms for all orders, global kernels for finite element operators, efficient use of the memory sub-system, optimal data locality and motion, enhanced scalability and parallelism, and fast tensor contractions. As ultimate goals of the project, CEED is exploring and identifying the best algorithms for the full range of discretizations and applying algorithmic and software development to support ECP applications’ needs. In this milestone, we initiated the development and implementation of a common CEED API consisting of two main components: low-level and high-level APIs. We accomplished the goal of having the low-level component ready for the release of CEED v1.0 in the next quarter, see CEED-MS13. In this report we also provide a highlight from CEED’s integration with the MARBL app and the corresponding Laghos miniapp. A main theme in this work has been the systematic transition of advanced algorithms, developed and tested in Laghos, to the large-scale multi-physics settings of the MARBL code. The low-level CEED API provides a set of FE kernels and components for writing new low-level kernels. Examples include: vector and sparse linear algebra, element matrix assembly over a batch of elements, partial assembly and action for efficient high-order operators like mass, diffusion, advection, etc. The main goal of the low-level API is to establish the basis for the high-level API. Also, identifying such low-level kernels and providing a reference implementation for them serves as the basis for collaboration with vendors and STs. Another goal for the low-level API is to make it easy for applications with their own discretization infrastructure, who do not want to switch directly to using the high-level CEED API, to still evaluate and use the core operations provided by the low-level API. One of the challenges with high-order methods is that a global sparse matrix is no longer a good representation of a high-order linear operator, both with respect to the FLOPs needed for its evaluation, as well as the memory transfer needed for a matvec. Thus, another important question we tried to address while developing the low-level API is: is it possible to abstract out in a natural and efficient way the different implementations and data structures that arise when dealing with various computational device types: CPUs, GPUs, etc. Fully answering this question is beyond the scope of this particular milestone, since that requires longer time as we develop and expand the devices we support. The future high-level API will be the frontend provided by CEED consisting of high-level abstractions such as meshes, finite element spaces and solutions, bilinear forms, solvers, etc. At this high-level, an important aspect of the API will be to provide a uniform abstraction layer for writing code in a portable manner. To achieve that, we plan to utilize the MPI programming model combined with a device abstraction layer (DAL) for finite element computations that we will develop. The DAL will serve as the bridge between the low- and the high-level APIs, allowing a variety of programming models to be used for the low-level kernel implementations. The software artifacts delivered as part of this milestone include an initial CEED API software implementation (libCEED) provided through the CEED website, http://ceed.exascaleproject.org and the CEED GitHub organization, http://github.com/ceed. In addition to details and results from the above R&D efforts, in this document we are also reporting on other project-wide activities performed in Q1 of FY18, including: the Nek5000 v17.0 MFEM v3.3.2 and PETSc v3.8 releases, collaborations with ECP/ST and SciDAC projects, the inaugural Nek5000 hackathon and various outreach activities.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2017

Preparing NERSC users for Cori, a Cray XC40 system with Intel many integrated cores

The newest NERSC supercomputer Cori is a Cray XC40 system consisting of 2,388 Intel Xeon Haswell nodes and 9,688 Intel Xeon-Phi “Knights Landing” (KNL) nodes. Compared to the Xeon-based clusters NERSC users are familiar with, optimal performance on Cori requires consideration of KNL mode settings; process, thread, and memory affinity; fine-grain parallelization; vectorization; and use of the high-bandwidth MCDRAM memory. This paper describes our efforts preparing NERSC users for KNL through the NERSC Exascale Science Application Program, Web documentation, and user training. We discuss how we configured the Cori system for usability and productivity, addressing programming concerns, batch system configurations, and default KNL cluster and memory modes. Here, system usage data, job completion analysis, programming and running jobs issues, and a few successful user stories on KNL are presented.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS1976

TCV software test and validation tools and technique

The paper describes techniques for testing and validating software for the TCV (Terminal Configured Vehicle) program which is intended to solve problems associated with operating a commercial transport aircraft in the terminal area. The TCV research test bed is a Boeing 737 specially configured with digital computer systems to carry out automatic navigation, guidance, flight controls, and electronic displays research. The techniques developed for time and cost reduction include automatic documentation aids, an automatic software configuration, and an all software generation and validation system.

Straeter, T. A.↗
NASA NTRS1980

Overview of integrated programs for aerospace-vehicle design (IPAD)

An overview of a joint industry/government project, denoted Integrated Programs for Aerospace-Vehicle Design (IPAD), which focuses on development of technology and associated software for integrated company-wide management of engineering information is presented. Results to date are summarized and include an in-depth documentation of a representative design process for a large engineering project, the definition and design of computer-aided design software needed to support that process, and the release of prototype software to integrated selected design functions.

Fulton, R. E.↗
NASA NTRS2007

JMS Proxy and C/C++ Client SDK

JMS Proxy and C/C++ Client SDK (JMS signifies "Java messaging service" and "SDK" signifies "software development kit") is a software package for developing interfaces that enable legacy programs (here denoted "clients") written in the C and C++ languages to communicate with each other via a JMS broker. This package consists of two main components: the JMS proxy server component and the client C library SDK component. The JMS proxy server component implements a native Java process that receives and responds to requests from clients. This component can run on any computer that supports Java and a JMS client. The client C library SDK component is used to develop a JMS client program running in each affected C or C++ environment, without need for running a Java virtual machine in the affected computer. A C client program developed by use of this SDK has most of the quality-of-service characteristics of standard Java-based client programs, including the following: Durable subscriptions; Asynchronous message receipt; Such standard JMS message qualities as "TimeToLive," "Message Properties," and "DeliveryMode" (as the quoted terms are defined in previously published JMS documentation); and Automatic reconnection of a JMS proxy to a restarted JMS broker.

Wolgast, Paul↗
NASA NTRS2013

Assess/Mitigate Risk through the Use of Computer-Aided Software Engineering (CASE) Tools

The NASA Engineering and Safety Center (NESC) was requested to perform an independent assessment of the mitigation of the Constellation Program (CxP) Risk 4421 through the use of computer-aided software engineering (CASE) tools. With the cancellation of the CxP, the assessment goals were modified to capture lessons learned and best practices in the use of CASE tools. The assessment goal was to prepare the next program for the use of these CASE tools. The outcome of the assessment is contained in this document.

Aguilar, Michael L.↗
DOE OSTI2019

Nuclear Physics Network Requirements Review Report

The Energy Sciences Network (ESnet) is the Office of Science’s high-performance network user facility, delivering highly reliable data transport capabilities optimized for the requirements of data-intensive science. In essence, ESnet is the circulatory system that enables the U.S. Department of Energy (DOE) science mission by connecting each and every DOE lab and its user facilities. ESnet is funded and stewarded by the Advanced Scientific Computing Research (ASCR) Program, and managed and operated by the Scientific Networking Division at Lawrence Berkeley National Laboratory (LBNL). ESnet is widely regarded as a global leader in the research and education networking community. ESnet connects DOE national laboratories, user facilities, and major experiments so scientists can use remote instruments and computing resources as well as share data with collaborators, transfer large data sets, and access distributed data repositories. While ESnet provides network connectivity, it cannot be characterized as an internet service provider as it is specifically built to provide a range of network services that are tailored to meet the unique requirements of DOE’s data-intensive science. In short, ESnet’s mission is to enable and accelerate scientific discovery by delivering unparalleled network infrastructure, capabilities, and tools. ESnet’s vision is summarized by these three points. 1. Scientific progress will be completely unconstrained by the physical location of instruments, people, computational resources, or data. 2. Collaborations at every scale, in every domain, will have the information and tools they need to achieve maximum benefit from scientific facilities, global networks, and emerging network capabilities. 3. ESnet will foster the partnerships and pioneer the technologies necessary to ensure that these transformations occur. In May 2019, ESnet and the Office of Nuclear Physics (NP) of the DOE Office of Science organized an ESnet requirements review of NP-supported activities. Preparation for this event included identification of key stakeholders to the process: program and facility management, research groups, technology providers, and a number of external observers. These individuals were asked to prepare formal case study documents about their relationship to the NP program to build a complete understanding of the current, near-term, and long-term status, expectations, and processes that will support the science going forward. A series of pre-planning meetings better prepared case study authors for this task and facilitated a smooth transition to the in-person review.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
NASA NTRS1985

Managing computer-controlled operations

A detailed discussion of Launch Processing System Ground Software Production is presented to establish the interrelationships of firing room resource utilization, configuration control, system build operations, and Shuttle data bank management. The production of a test configuration identifier is traced from requirement generation to program development. The challenge of the operational era is to implement fully automated utilities to interface with a resident system build requirements document to eliminate all manual intervention in the system build operations. Automatic update/processing of Shuttle data tapes will enhance operations during multi-flow processing.

Plowden, J. B.↗