Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Code Manual”

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 793 records · Page 44
All sourcesNASA NTRSDOE OSTI
NASA NTRS2009

The Use of Pro/Engineer CAD Software and Fishbowl Tool Kit in Ray-tracing Analysis

This document is designed as a manual for a user who wants to operate the Pro/ENGINEER (ProE) Wildfire 3.0 with the NASA Space Radiation Program's (SRP) custom-designed Toolkit, called 'Fishbowl', for the ray tracing of complex spacecraft geometries given by a ProE CAD model. The analysis of spacecraft geometry through ray tracing is a vital part in the calculation of health risks from space radiation. Space radiation poses severe risks of cancer, degenerative diseases and acute radiation sickness during long-term exploration missions, and shielding optimization is an important component in the application of radiation risk models. Ray tracing is a technique in which 3-dimensional (3D) vehicle geometry can be represented as the input for the space radiation transport code and subsequent risk calculations. In ray tracing a certain number of rays (on the order of 1000) are used to calculate the equivalent thickness, say of aluminum, of the spacecraft geometry seen at a point of interest called the dose point. The rays originate at the dose point and terminate at a homogenously distributed set of points lying on a sphere that circumscribes the spacecraft and that has its center at the dose point. The distance a ray traverses in each material is converted to aluminum or other user-selected equivalent thickness. Then all equivalent thicknesses are summed up for each ray. Since each ray points to a direction, the aluminum equivalent of each ray represents the shielding that the geometry provides to the dose point from that particular direction. This manual will first list for the user the contact information for help in installing ProE and Fishbowl in addition to notes on the platform support and system requirements information. Second, the document will show the user how to use the software to ray trace a Pro/E-designed 3-D assembly and will serve later as a reference for troubleshooting. The user is assumed to have previous knowledge of ProE and CAD modeling.

Nounu, Hatem N.↗
DOE OSTI2021

Software Quality Assurance for EBR-II Fuels Irradiation and Physics Database (FIPD)

The Fuels Irradiation and Physics Database (FIPD) is an ongoing DOE project on archival of the EBR-II metal-alloy fuel irradiation experiments. As part of its use in support of license applications, the Quality Assurance Program Plan (QAPP) was drafted and endorsed by NRC in an effort to demonstrate its compliance with regulatory expectations. Software Quality Assurance (SQA) for the physics portion of FIPD is intended to qualify the calculated quantities such as fuel and cladding temperatures, neutron fluence and axially varying burnup estimates for irradiated fuel elements. This report covers the initial evaluation of SQA status of three neutron physics and thermo-fluid codes (REBUS, RCT and SE2RCT) that form the basis of calculated quantities for as-irradiated characteristics of the tested metallic fuel elements. The report also introduces an SQA plan to address the identified deficiencies. The REBUS, RCT, and SE2RCT codes are all part of the Argonne Reactor Code (ARC) code system. There is considerable knowledge and experience on REBUS and RCT but relatively less on SE2RCT. During FY2021, efforts focused on an assessment of how the data in the EBR-II Physics and Analysis DataBase (PADB) is generated with SE2RCT and used in FIPD. Additional tasks included considerations of uncertainties for power estimates in REBUS and RCT calculations and their impact on the combined RCT methodology. The RCT software usage in FIPD was assessed this year and the input/output details studied. A “requirements” document was created that identifies the key features of the RCT software being used in FIPD that need to have SQA documentation. A brief discussion on the history of RCT and its input is included in this report along with the basic SQA roadmap laid out in the requirements document. The SE2RCT software usage in FIPD is still being studied noting that there is no current manual. As part of the work done this year, two bugs were identified in the SE2RCT software which have a minor impact on the accuracy of the results it produces. No requirements document has been created, but one identified feature of SE2RCT being used that needs verification was its fuel pin temperature calculation. The work completed this year confirms that the approximations which will be included in the software verification report for SE2RCT are accurate. In addition to software quality assurance work for RCT and SE2RCT, an automated verification framework is proposed to simplify the software quality assurance process. The purpose of this framework is to streamline code verification and documentation while minimizing repetitive tasks for code developers and reviewers. The reduction of repeated input (between reference solution, software, and documentation input) throughout the SQA process reduces potential for human errors during the preparation of the supporting software quality records. The automation of the verification and documentation process proposed for this project leverages the existing verification structure already in place for the SAS4A/SASSYS-1 code.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
DOE OSTI2026

Meteorological and Soil Data from Ecohydrology Sensor Towers at Pump House and Snodgrass Mountain in East River Watershed, Colorado, 2019-2025

This data package includes hourly meteorological and soil sensor data at eight ecohydrology monitoring sites in East River Watershed, Colorado as part of the Watershed Function Scientific Focus Area (WFSFA) research led by Lawrence Berkeley National Lab (LBNL). Four field sites were located on the hillslope of East River (ER) near Pump House (PH) at Mount Crested Butte (ER-PHS1 to 4), and the other four are in the Snodgrass Mountain (SG) area (SG-EHS5 to 8). In terms of vegetation cover, three sites are in montane grasslands (ER-PHS1, ER-PHS2, and SG-EHS5), three are below evergreen conifer canopy (ER-PHS3, SG-EHS6, and SG-EHS7), and two are below deciduous aspen canopy (ER-PHS4 and SG-EHS8). The monitoring period began in October 2019 at the East River sites, in October 2020 at SG-EHS5 and SG-EHS6, and in October 2021 at SG-EHS7 and SG-EHS8. In September 2024, all four East River sites were fully retired. The four Snodgrass Mountain sites remain active. Each site is equipped with a comprehensive suite of meteorological sensors on a tripod and soil sensors that measure weather, energy fluxes, and soil variables. This data package includes measurements from ten different types of sensors and up to thirteen individual sensors per site, including (1) a weather station (measurement height ranges from 2.8~3.8 meters (m) above ground), (2) a quantum sensor for photosynthetic active radiation (PAR) (2.4~3.3m), (3) a net radiometer (1.7~2.1m), (4) an infrared radiometer (1.6~2.2m), (5) a sonic distance sensor (1.5~1.9m), (6) a soil carbon dioxide (CO2) flux chamber (0m), (7) a soil heat flux plate (-0.05m below ground), (8) a soil oxygen sensor (-0.3m), (9) a soil water potential sensor (-0.3m), and (10) soil water content sensors at 3~4 depths (-1.15 ~ -0.1m). A total of twenty-three variables is reported in this data package, including (1) atmospheric variables: air temperature (TA), atmospheric pressure (PA), vapor pressure (VP), and vapor pressure deficit (VPD), (2) precipitation variables: rain precipitation (P) and snow depth (D_SNOW), (3) energy fluxes variables: four-component net radiation (NETRAD) (shortwave/longwave incoming/outgoing radiation, SW_IN, SW_OUT, LW_IN, LW_OUT), photosynthetic photon flux density (PPFD), and soil heat flux (G), (4) soil variables: soil water content (SWC), soil water potential (SWP), soil temperature (TS), soil bulk electrical conductivity (COND_SOIL), and soil gaseous oxygen concentration (O2_SOIL), (5) wind variables: two-dimensional wind speed (WS), gust speed (WS_MAX), and wind direction (WD), and (6) surface variables: surface infrared temperature (T_CANOPY) and soil CO2 flux (CO2_SOIL). Please see the Methods section for data processing and QA/QC steps taken to generate the hourly datasets. The following files are included in this data package (notes on version: v{x}-{y}, where x is the metadata version, and y is the data version, when applicable): (1) “metadata_site_v{x}-{y}.csv” - a site metadata file that summarizes location information of all sites, including site ID, description, coordinates, timeframe, elevation, and vegetation cover, (2) “metadata_instrument_v{x}-{y}.csv” - an instrument metadata file that summarizes sensor information of all sites, including sensor manufacturer and model, measurement height, and sampling and averaging interval of all variables, (3) "data_{SITE_ID}_v{x}-{y}.csv" - eight data files that contain hourly data of each site indicated by {SITE_ID} in the filename, (4) “/figure/data_{SITE_ID}_v{x}-{y}.png" - eight figures that help visualize data of each site indicated by {SITE_ID} in the filename, (5) “/photo/*” - photos of each site indicated by {SITE_ID} in the filename, and (6) four file level metadata (flmd.csv) and data dictionary (*_dd.csv) files that summarize file, header, column, and variable information of all files. Notes: (1) Measurement height: Each variable name is followed by conventional positional qualifiers “H_V_R”, where H indicates the relative horizontal positions of that specific variable, V the vertical positions, and R the replicates. In this data package, only the vertical qualifier V varies, and V increases from the highest vertical position (V=1) to the lowest. Variables with the same qualifier are not necessarily measured by the same sensor, and the same variable with the same qualifier across different sites are not necessarily measured at the same height. Please refer to “metadata_instrument.csv” for the sensor information and measurement heights, and whether a variable is measured below the canopy. (2) Variable availability: Snow depth is not available at ER-PHS3 and SG-EHS7. SWC, soil temperature, and soil bulk EC at the deepest depth (<-1m) are not available at SG-EHS6 and SG-EHS7. The missing value code for numeric variables is -9999, except for SWP. For SWP, the missing value code is +9999, because SWP values are negative. (3) Sampling frequency: Please refer to “metadata_instrument.csv” for the increase of sampling frequency of some variables from 30-min to 1-min at ER-PHS1 to 4 in July 2020. (4) Sensors: While the methods of each sensor are not detailed, all sensors are commercially available, and their methods can be found in their manuals. Please refer to “metadata_instrument.csv” for the sensor manufacturer and model information. This work was supported by the Watershed Function Science Focus Area at Lawrence Berkeley National Laboratory funded by the US Department of Energy, Office of Science, Biological and Environmental Research under Contract No. DE-AC02-05CH11231.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS1987

Ada style guide (version 1.1)

Ada is a programming language of considerable expressive power. The Ada Language Reference Manual provides a thorough definition of the language. However, it does not offer sufficient guidance on the appropriate use of Ada's powerful features. For this reason, the Goddard Space Flight Center Ada User's Group has produced this style guide which addresses such program style issues. The guide covers three areas of Ada program style: the structural decomposition of a program; the coding and the use of specific Ada features; and the textural formatting of a program.

Seidewitz, Edwin V.↗
NASA NTRS1993

The Automated Instrumentation and Monitoring System (AIMS) reference manual

Whether a researcher is designing the 'next parallel programming paradigm,' another 'scalable multiprocessor' or investigating resource allocation algorithms for multiprocessors, a facility that enables parallel program execution to be captured and displayed is invaluable. Careful analysis of execution traces can help computer designers and software architects to uncover system behavior and to take advantage of specific application characteristics and hardware features. A software tool kit that facilitates performance evaluation of parallel applications on multiprocessors is described. The Automated Instrumentation and Monitoring System (AIMS) has four major software components: a source code instrumentor which automatically inserts active event recorders into the program's source code before compilation; a run time performance-monitoring library, which collects performance data; a trace file animation and analysis tool kit which reconstructs program execution from the trace file; and a trace post-processor which compensate for data collection overhead. Besides being used as prototype for developing new techniques for instrumenting, monitoring, and visualizing parallel program execution, AIMS is also being incorporated into the run-time environments of various hardware test beds to evaluate their impact on user productivity. Currently, AIMS instrumentors accept FORTRAN and C parallel programs written for Intel's NX operating system on the iPSC family of multi computers. A run-time performance-monitoring library for the iPSC/860 is included in this release. We plan to release monitors for other platforms (such as PVM and TMC's CM-5) in the near future. Performance data collected can be graphically displayed on workstations (e.g. Sun Sparc and SGI) supporting X-Windows (in particular, Xl IR5, Motif 1.1.3).

Yan, Jerry↗
DOE OSTI2026

PlantCV v4: Image analysis software for high‐throughput plant phenotyping

PlantCV is an open-source Python project aimed at developing tools to address a range of image-based, plant phenotyping questions. PlantCV has been used for more than 10 years to automate trait collection from image data, and the newest release, PlantCV version 4, continues to lower the barrier to entry for users without substantial coding experience through extensive example use-case tutorials and simplified installation. In addition to usability, we document added functionality since the release of PlantCV v2, including support for more image types such as fluorescence, thermal, and hyperspectral data. Finally, we describe the development of a new subpackage focused on morphological trait measurements like leaf angle, and demonstrate its utility as compared to more manual methods of data collection.

Schuhl, Haley [Donald Danforth Plant Science Cente↗
DOE OSTI2022

Hydrogen Plus Other Alternative Fuels Risk Assessment Models (HyRAM+) Version 4.1 Technical Reference Manual

The HyRAM+ software toolkit provides a basis for conducting quantitative risk assessment and consequence modeling for hydrogen, methane, and propane systems. HyRAM+ is designed to facilitate the use of state-of-the-art models to conduct robust, repeatable assessments of safety, hazards, and risk. HyRAM+ integrates deterministic and probabilistic models for quantifying accident scenarios, predicting physical effects, characterizing hazards (thermal effects from jet fires, overpressure effects from delayed ignition), and assessing impacts on people. HyRAM+ is developed at Sandia National Laboratories to support the development and revision of national and international codes and standards, and to provide developed models in a publicly-accessible toolkit usable by all stakeholders. This document provides a description of the methodology and models contained in HyRAM+ version 4.1. The two most significant changes for HyRAM+ version 4.1 from HyRAM+ version 4.0 are direct incorporation of unconfined overpressure into the QRA calculations and modification of the models for cryogenic liquid flow through an orifice. In QRA mode, the user no longer needs to input peak overpressure and impulse values that were calculated separately; rather, the unconfined overpressure is estimated for the given system inputs, leak size, and occupant location. The orifice flow model now solves for the maximum mass flux through the orifice at constant entropy while conserving energy, which does not require a direct speed of sound calculation. This does not affect the mass flow for all-gaseous releases; the method results in the same speed of sound for choked flow. However, this method does result in a higher (and more realistic) mass flow rate for a given leak size for liquid releases than was previously calculated.

08 HYDROGEN↗
NASA NTRS1990

GCS programmer's manual

A variety of instructions to be used in the development of implementations of software for the Guidance and Control Software (GCS) project is described. This document fulfills the Radio Technical Commission for Aeronautics RTCA/DO-178A guidelines, 'Software Considerations in Airborne Systems and Equipment Certification' requirements for document No. 4, which specifies the information necessary for understanding and programming the host computer, and document No. 12, which specifies the software design and implementation standards that are applicable to the software development and testing process. Information on the following subjects is contained: activity recording, communication protocol, coding standards, change management, error handling, design standards, problem reporting, module testing logs, documentation formats, accuracy requirements, and programmer responsibilities.

Lowman, Douglas S.↗
NASA NTRS2014

A Walsh Function Module Users' Manual

The solution of partial differential equations (PDEs) with Walsh functions offers new opportunities to simulate many challenging problems in mathematical physics. The approach was developed to better simulate hypersonic flows with shocks on unstructured grids. It is unique in that integrals and derivatives are computed using simple matrix multiplication of series representations of functions without the need for divided differences. The product of any two Walsh functions is another Walsh function - a feature that radically changes an algorithm for solving PDEs. A FORTRAN module for supporting Walsh function simulations is documented. A FORTRAN code is also documented with options for solving time-dependent problems: an advection equation, a Burgers equation, and a Riemann problem. The sample problems demonstrate the usage of the Walsh function module including such features as operator overloading, Fast Walsh Transforms in multi-dimensions, and a Fast Walsh reciprocal.

Gnoffo, Peter A.↗
DOE OSTI2023

Virtual Flow Solver - Geophysics: A 3D Incompressible Navier-Stokes Solver

Virtual Flow Solver - Geophysics (VFS-Geophysics) is a three-dimensional (3D) incompressible Navier-Stokes solver based on the Curvilinear Immersed Boundary (CURVIB) method. The CURVIB is a sharp interface type of immersed boundary (IB) method that enables the simulation of fluid flows in the presence of geometrically complex moving bodies. The CURVIB method can be applied to wind/MHK turbine simulations and energy applications. VFS-Geophysics is the result of many years of research work by several graduate students, post-docs, and research associates that have been involved in the Computational Hydrodynamics and Biofluids Laboratory directed by Professor Fotis Sotiropoulos. The preparation of the present manual has been supported by the U.S. Department of Energy (DE-EE 0005482).

16 TIDAL AND WAVE POWER↗
DOE OSTI2021

Optimization of Asynchronous Communication Operations through Eager Notifications

UPC++ is a C++ library implementing the Asynchronous Partitioned Global Address Space (APGAS) model. We propose an enhancement to the completion mechanisms of UPC++ used to synchronize communication operations that is designed to reduce overhead for on-node operations. Our enhancement permits eager delivery of completion notification in cases where the data transfer semantics of an operation happen to complete synchronously, for example due to the use of shared-memory bypass. This semantic relaxation allows removing significant overhead from the critical path of the implementation in such cases. We evaluate our results on three different representative systems using a combination of microbenchmarks and five variations of the the HPCChallenge RandomAccess benchmark implemented in UPC++ and run on a single node to accentuate the impact of locality. We find that in RMA versions of the benchmark written in a straightforward manner (without manually optimizing for locality), the new eager notification mode can provide up to a 25% speedup when synchronizing with promises and up to a 13.5x speedup when synchronizing with conjoined futures. We also evaluate our results using a graph matching application written with UPC++ RMA communication, where we measure overall speedups of as much as 11% in single-node runs of the unmodified application code, due to our transparent enhancements.

Kamil, Amir↗
DOE OSTI2022

Automatic Segmentation of Building Envelope Point Cloud Data Using Machine Learning

About 50% of buildings in the US were constructed before energy codes were introduced. Modular overclad panel retrofits, in which a new envelope is constructed over the existing building, are a promising solution given that it minimizes occupant disruption and shortens construction time at the jobsite. Current state-of-the-art retrofit panel layout and dimensioning consists of three steps: 1) 3D point cloud data generation of the building envelope using commonly available surveying equipment, 2) manual segmentation of 3D point cloud data by a trained professional to identify and dimension window openings, door openings, and other architectural features, and 3) modular panel layout optimization and dimensioning by an architect or engineer. Among these steps, the second one remains the most difficult and costly because it is very labor-intensive. We propose a methodology to automatically label 3D point cloud data to reduce the time and expense spent in manual segmentation. Machine learning methods were employed to classify the point cloud data into distinct groups, each of which corresponds to different features of the building envelope. After classification, a segmentation algorithm was developed to perform boundary detection and separate the components of the façade. Finally, the algorithm returns the relative positions and dimensions of the features in the building envelope. The measurements obtained with the proposed automated method were compared against the actual dimensions to determine the overall algorithm accuracy. The proposed algorithm can then be used to reduce manual efforts for 3D point cloud labeling before modular panel layout optimization is performed.

Maldonado Puente, Bryan↗
NASA NTRS2016

Automated ISS Flight Utilities

During my internship at NASA Johnson Space Center, I worked in the Space Radiation Analysis Group (SRAG), where I was tasked with a number of projects focused on the automation of tasks and activities related to the operation of the International Space Station (ISS). As I worked on a number of projects, I have written short sections below to give a description for each, followed by more general remarks on the internship experience. My first project is titled "General Exposure Representation EVADOSE", also known as "GEnEVADOSE". This project involved the design and development of a C++/ ROOT framework focused on radiation exposure for extravehicular activity (EVA) planning for the ISS. The utility helps mission managers plan EVAs by displaying information on the cumulative radiation doses that crew will receive during an EVA as a function of the egress time and duration of the activity. SRAG uses a utility called EVADOSE, employing a model of the space radiation environment in low Earth orbit to predict these doses, as while outside the ISS the astronauts will have less shielding from charged particles such as electrons and protons. However, EVADOSE output is cumbersome to work with, and prior to GEnEVADOSE, querying data and producing graphs of ISS trajectories and cumulative doses versus egress time required manual work in Microsoft Excel. GEnEVADOSE automates all this work, reading in EVADOSE output file(s) along with a plaintext file input by the user providing input parameters. GEnEVADOSE will output a text file containing all the necessary dosimetry for each proposed EVA egress time, for each specified EVADOSE file. It also plots cumulative dose versus egress time and the ISS trajectory, and displays all of this information in an auto-generated presentation made in LaTeX. New features have also been added, such as best-case scenarios (egress times corresponding to the least dose), interpolated curves for trajectories, and the ability to query any time in the EVADES output. As mentioned above, GEnEVADOSE makes extensive use of ROOT version 6, the data analysis framework developed at the European Organization for Nuclear Research (CERN), and the code is written to the C++11 standard (as are the other projects). My second project is the Automated Mission Reference Exposure Utility (AMREU).Unlike GEnEVADOSE, AMREU is a combination of three frameworks written in both Python and C++, also making use of ROOT (and PyROOT). Run as a combination of daily and weekly cron jobs, these macros query the SRAG database system to determine the active ISS missions, and query minute-by-minute radiation dose information from ISS-TEPC (Tissue Equivalent Proportional Counter), one of the radiation detectors onboard the ISS. Using this information, AMREU creates a corrected data set of daily radiation doses, addressing situations where TEPC may be offline or locked up by correcting doses for days with less than 95% live time (the total amount time the instrument acquires data) by averaging the past 7 days. As not all errors may be automatically detectable, AMREU also allows for manual corrections, checking an updated plaintext file each time it runs. With the corrected data, AMREU generates cumulative dose plots for each mission, and uses a Python script to generate a flight note file (.docx format) containing these plots, as well as information sections to be filled in and modified by the space weather environment officers with information specific to the week. AMREU is set up to run without requiring any user input, and it automatically archives old flight notes and information files for missions that are no longer active. My other projects involve cleaning up a large data set from the Charged Particle Directional Spectrometer (CPDS), joining together many different data sets in order to clean up information in SRAG SQL databases, and developing other automated utilities for displaying information on active solar regions, that may be used by the space weather environment officers to monitor solar activity. I consulted my mentor Dr. Ryan Rios and Dr. Kerry Lee for project requirements and added features, and ROOT developer Edmond Offermann for advice on using the ROOT library. I also received advice and feedback from Dr. Janet Barzilla of SRAG, who tested my code. Besides these inputs, I worked independently, writing all of the code by myself. The code for all these projects is documented throughout, and I have attempted to write it in a modular format. Assuming that ROOT is updated accordingly, these codes are also Y2038-compliant (and Y10K-compliant). This allows the code to be easily referenced, modified and possibly repurposed for non-ISS missions in the future, should the necessary inputs exist. These projects have taught me a lot about coding and software design - I have become a much more skilled C++ programmer and ROOT user, and I also learned to code in Python and PyROOT (and its advantages and disadvantages compared to C++/ ROOT). Furthermore, I have learned about space radiation and radiation modeling, topics that greatly interest me as I pursue a degree in physics. Working alongside experimental physicists like Dr. Rios, I have developed a greater understanding and appreciation for experimental science, something I have always leaned towards but to which I lacked significant exposure. My work in SRAG has also given me the invaluable opportunity to witness the work environment for physicists at NASA, and what a career in academia may look like at a government laboratory such as NASA Johnson Space Center. As I continue my studies and look forward to graduate school and a future career, this experience at NASA has given me a meaningful and enjoyable opportunity to put my skills to use and see what my future career path might hold.

Offermann, Jan Tuzlic↗
NASA NTRS1983

Aeroelastic analysis for propellers - mathematical formulations and program user's manual

Mathematical development is presented for a specialized propeller dedicated version of the G400 rotor aeroelastic analysis. The G400PROP analysis simulates aeroelastic characteristics particular to propellers such as structural sweep, aerodynamic sweep and high subsonic unsteady airloads (both stalled and unstalled). Formulations are presented for these expanded propeller related methodologies. Results of limited application of the analysis to realistic blade configurations and operating conditions which include stable and unstable stall flutter test conditions are given. Sections included for enhanced program user efficiency and expanded utilization include descriptions of: (1) the structuring of the G400PROP FORTRAN coding; (2) the required input data; and (3) the output results. General information to facilitate operation and improve efficiency is also provided.

Bielawa, R. L.↗
NASA NTRS1996

User's Guide for MSAP2D: A Program for Unsteady Aerodynamic and Aeroelastic (Flutter and Forced Response) Analysis of Multistage Compressors and Turbines

This guide describes the input data required for using MSAP2D (Multi Stage Aeroelastic analysis Program - Two Dimensional) computer code. MSAP2D can be used for steady, unsteady aerodynamic, and aeroelastic (flutter and forced response) analysis of bladed disks arranged in multiple blade rows such as those found in compressors, turbines, counter rotating propellers or propfans. The code can also be run for single blade row. MSAP2D code is an extension of the original NPHASE code for multiblade row aerodynamic and aeroelastic analysis. Euler equations are used to obtain aerodynamic forces. The structural dynamic equations are written for a rigid typical section undergoing pitching (torsion) and plunging (bending) motion. The aeroelastic equations are solved in time domain. For single blade row analysis, frequency domain analysis is also provided to obtain unsteady aerodynamic coefficients required in an eigen analysis for flutter. In this manual, sample input and output are provided for a single blade row example, two blade row example with equal and unequal number of blades in the blade rows.

Reddy, T. S. R.↗
DOE OSTI2022

Hydrogen Plus Other Alternative Fuels Risk Assessment Models (HyRAM+) Version 5.0 Technical Reference Manual

The HyRAM+ software toolkit provides a basis for conducting quantitative risk assessment and consequence modeling for hydrogen, natural gas, and autogas systems. HyRAM+ is designed to facilitate the use of state-of-the-art models to conduct robust, repeatable assessments of safety, hazards, and risk. HyRAM+ integrates deterministic and probabilistic models for quantifying leak sizes and rates, predicting physical effects, characterizing hazards (thermal effects from jet fires, overpressure effects from delayed ignition), and assessing impacts on people. HyRAM+ is developed at Sandia National Laboratories to support the development and revision of national and international codes and standards, and to provide developed models in a publicly-accessible toolkit usable by all stakeholders. This document provides a description of the methodology and models contained in HyRAM+ version 5.0. The most significant change for HyRAM+ version 5.0 from HyRAM+ version 4.1 is the ability to model blends of different fuels. HyRAM+ was previously only suitable for use with hydrogen, methane, or propane, with users having the ability to use methane as a proxy for natural gas and propane as a proxy for autogas/liquefied petroleum gas. In version 5.0, real natural gas or autogas compositions can be modeled as the fuel, or even blends of natural gas with hydrogen. These blends can be used in the standalone physics models, but not yet in the quantitative risk assessment mode of HyRAM+.

03 NATURAL GAS↗
DOE OSTI2023

Hydrogen Plus Other Alternative Fuels Risk Assessment Models (HyRAM+) Version 5.1 Technical Reference Manual

The HyRAM+ software toolkit provides a basis for conducting quantitative risk assessment and consequence modeling for hydrogen, natural gas, and autogas systems. HyRAM+ is designed to facilitate the use of state-of-the-art models to conduct robust, repeatable assessments of safety, hazards, and risk. HyRAM+ integrates deterministic and probabilistic models for quantifying leak sizes and rates, predicting physical effects, characterizing hazards (thermal effects from jet fires, overpressure effects from delayed ignition), and assessing impacts on people. HyRAM+ is developed at Sandia National Laboratories to support the development and revision of national and international codes and standards, and to provide developed models in a publicly-accessible toolkit usable by all stakeholders. This document provides a description of the methodology and models contained in HyRAM+ version 5.1. The most significant changes for HyRAM+ version 5.1 from HyRAM+ version 5.0 are updated default leak frequency values for propane, new default component counts for different fuel types, and an improved fuel specification view in the graphical user interface.

02 PETROLEUM↗
NASA NTRS1974

Airoscope command system

A PCM telemetry command system is presented having a capacity of 256 unique commands, an end-to-end actuation time of less than 250 milliseconds, and an address plus complementary command code to provide security against the acceptance of anything but intended commands. The system consists of a ground-based encoder and a balloon-borne decoder, both built using low-current drain, high reliability CMOS logic elements. Commands are normally issued by a simple switch closure to +5VDC on the appropriate input line, however as a backup mode, the 8-bit command may be entered manually on 8 toggle switches and executed via a SEND button. In any case, the command is then serialized into a PCM bit stream and sent via a P-Band radio link to the DECODER aloft. All 256 outputs from the DECODER are buffered through drivers and thus may be used to drive CMOS, TTL, or DTL logic.

Barrows, W.↗