Search NASA⌕ Search

SEARCH · Search NASA

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 685 records · Page 38
All sourcesNASA NTRSDOE OSTI
NASA NTRS1981

Simulated aircraft takeoff performance with frosted wings

The absolute and relative safety of certain nocturnal frost formations on general aviation and transport type airfoils is evaluated by a computer simulation program. The frost layer aerodynamic penalty and takeoff program was used to calculate the frost thickness distribution on an airfoil with time, as well as the aerodynamic penalties associated with the frost layer during takeoff. The program was validated by nocturnal frost formation experiments on an inclined flat plate and by comparisons with documented aerodynamic penalties of an arbitrarily roughened airfoil. For various meteorological conditions and runway take-off velocities, a frost layer can be determined that produces no aerodynamic penalty, thus inferring the absolute safety of the airfoil with respect to frost. The relative safety of a frosted airfoil depends on the ability of the engine power reserve to overcome both as much as doubling of airfoil drag and an increased stall speed due to lift penalties.

Dietenberger, M. A.↗
NASA NTRS1989

Ice/frost/debris assessment for space shuttle mission STS-27R, December 2, 1988

An Ice/Frost/Debris assessment was conducted for Space Shuttle Mission STS-27R. Debris inspections of the flight elements and launch pad are performed before and after launch. Ice/frost conditions 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 viewed after launch to identify ice/debris sources and evaluate potential vehicle damage. The Ice/Frost/Debris conditions of Mission STS-27R and their effect on the Space Shuttle Program are documented.

Katnik, Gregory N.↗
NASA NTRS1989

KSC ice/frost/debris assessment for space shuttle mission STS-29R

An ice/frost/debris assessment was conducted for Space Shuttle Mission STS-29R. 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-29R and their effect on the Space Shuttle Program are documented.

Stevenson, Charles G.↗
NASA NTRS1990

Research summary, January 1989 - June 1990

The Research Institute for Advanced Computer Science (RIACS) was established at NASA ARC in June of 1983. RIACS is privately operated by the Universities Space Research Association (USRA), a consortium of 62 universities with graduate programs in the aerospace sciences, under a Cooperative Agreement with NASA. RIACS serves as the representative of the USRA universities at ARC. This document reports our activities and accomplishments for the period 1 Jan. 1989 - 30 Jun. 1990. The following topics are covered: learning systems, networked systems, and parallel systems.

Source record↗
NASA NTRS2005

Doclet To Synthesize UML

The RoseDoclet computer program extends the capability of Java doclet software to automatically synthesize Unified Modeling Language (UML) content from Java language source code. [Doclets are Java-language programs that use the doclet application programming interface (API) to specify the content and format of the output of Javadoc. Javadoc is a program, originally designed to generate API documentation from Java source code, now also useful as an extensible engine for processing Java source code.] RoseDoclet takes advantage of Javadoc comments and tags already in the source code to produce a UML model of that code. RoseDoclet applies the doclet API to create a doclet passed to Javadoc. The Javadoc engine applies the doclet to the source code, emitting the output format specified by the doclet. RoseDoclet emits a Rose model file and populates it with fully documented packages, classes, methods, variables, and class diagrams identified in the source code. The way in which UML models are generated can be controlled by use of new Javadoc comment tags that RoseDoclet provides. The advantage of using RoseDoclet is that Javadoc documentation becomes leveraged for two purposes: documenting the as-built API and keeping the design documentation up to date.

Barry, Matthew R.↗
NASA NTRS2016

Modeling in the State Flow Environment to Support Launch Vehicle Verification Testing for Mission and Fault Management Algorithms in the NASA Space Launch System

Analysis methods and testing processes are essential activities in the engineering development and verification of the National Aeronautics and Space Administration's (NASA) new Space Launch System (SLS). Central to mission success is reliable verification of the Mission and Fault Management (M&FM) algorithms for the SLS launch vehicle (LV) flight software. This is particularly difficult because M&FM algorithms integrate and operate LV subsystems, which consist of diverse forms of hardware and software themselves, with equally diverse integration from the engineering disciplines of LV subsystems. M&FM operation of SLS requires a changing mix of LV automation. During pre-launch the LV is primarily operated by the Kennedy Space Center (KSC) Ground Systems Development and Operations (GSDO) organization with some LV automation of time-critical functions, and much more autonomous LV operations during ascent that have crucial interactions with the Orion crew capsule, its astronauts, and with mission controllers at the Johnson Space Center. M&FM algorithms must perform all nominal mission commanding via the flight computer to control LV states from pre-launch through disposal and also address failure conditions by initiating autonomous or commanded aborts (crew capsule escape from the failing LV), redundancy management of failing subsystems and components, and safing actions to reduce or prevent threats to ground systems and crew. To address the criticality of the verification testing of these algorithms, the NASA M&FM team has utilized the State Flow environment6 (SFE) with its existing Vehicle Management End-to-End Testbed (VMET) platform which also hosts vendor-supplied physics-based LV subsystem models. The human-derived M&FM algorithms are designed and vetted in Integrated Development Teams composed of design and development disciplines such as Systems Engineering, Flight Software (FSW), Safety and Mission Assurance (S&MA) and major subsystems and vehicle elements such as Main Propulsion Systems (MPS), boosters, avionics, Guidance, Navigation, and Control (GN&C), Thrust Vector Control (TVC), liquid engines, and the astronaut crew office. Since the algorithms are realized using model-based engineering (MBE) methods from a hybrid of the Unified Modeling Language (UML) and Systems Modeling Language (SysML), SFE methods are a natural fit to provide an in depth analysis of the interactive behavior of these algorithms with the SLS LV subsystem models. For this, the M&FM algorithms and the SLS LV subsystem models are modeled using constructs provided by Matlab which also enables modeling of the accompanying interfaces providing greater flexibility for integrated testing and analysis, which helps forecast expected behavior in forward VMET integrated testing activities. In VMET, the M&FM algorithms are prototyped and implemented using the same C++ programming language and similar state machine architectural concepts used by the FSW group. Due to the interactive complexity of the algorithms, VMET testing thus far has verified all the individual M&FM subsystem algorithms with select subsystem vendor models but is steadily progressing to assessing the interactive behavior of these algorithms with LV subsystems, as represented by subsystem models. The novel SFE applications has proven to be useful for quick look analysis into early integrated system behavior and assessment of the M&FM algorithms with the modeled LV subsystems. This early MBE analysis generates vital insight into the integrated system behaviors, algorithm sensitivities, design issues, and has aided in the debugging of the M&FM algorithms well before full testing can begin in more expensive, higher fidelity but more arduous environments such as VMET, FSW testing, and the Systems Integration Lab7 (SIL). SFE has exhibited both expected and unexpected behaviors in nominal and off nominal test cases prior to full VMET testing. In many findings, these behavioral characteristics were used to correct the M&FM algorithms, enable better test coverage, and develop more effective test cases for each of the LV subsystems. This has improved the fidelity of testing and planning for the next generation of M&FM algorithms as the SLS program evolves from non-crewed to crewed flight, impacting subsystem configurations and the M&FM algorithms that control them. SFE analysis has improved robustness and reliability of the M&FM algorithms by revealing implementation errors and documentation inconsistencies. It is also improving planning efficiency for future VMET testing of the M&FM algorithms hosted in the LV flight computers, further reducing risk for the SLS launch infrastructure, the SLS LV, and most importantly the crew.

Trevino, Luis↗
DOE OSTI2018

GALE 3.1 Verification Report

This report is documentation of the verification activities that have been performed on GALE-3.1 to ensure that the codes meet the requirements and specifications set forth by NRC and that the code meets its intended purpose. Additional benchmark tests for GALE-3.1 are documented in Appendix A of NUREG-0016, Revision 2 for GALE-BWR 3.1 and Appendix A of NUREG-0017, Revision 2 for GALE-PWR 3.1. 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.1 BWR and GALE-3.1 PWR Codes. The GALE 3.1 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↗
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↗