Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “coding standards”

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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS1992

Multi-mode modem/codec designs

The design of an integrated modem/codec unit which can receive coded and uncoded BPSK an QPSK using de facto standard coding schemes as well as 8PSK-TCM and 16PSK-TCM is examined. The design is totally compatible with today's modulation schemes and capable of processing tomorrow's TCM codes. This is accomplished in the modem by using quadrature channel carrier recovery processing and a version of the MAP phase detector algorithm. The symbol synchronization is accomplished with a derivative of an early-late gate designed to accommodate multilevel signals.

Osborne, William↗
NASA NTRS1994

Time synchronized video systems

The idea of synchronizing multiple video recordings to some type of 'range' time has been tried to varying degrees of success in the past. Combining this requirement with existing time code standards (SMPTE) and the new innovations in desktop multimedia however, have afforded an opportunity to increase the flexibility and usefulness of such efforts without adding costs over the traditional data recording and reduction systems. The concept described can use IRIG, GPS or a battery backed internal clock as the master time source. By converting that time source to Vertical Interval Time Code or Longitudinal Time Code, both in accordance with the SMPTE standards, the user will obtain a tape that contains machine/computer readable time code suitable for use with editing equipment that is available off-the-shelf. Accuracy on playback is then determined by the playback system chosen by the user. Accuracies of +/- 2 frames are common among inexpensive systems and complete frame accuracy is more a matter of the users' budget than the capability of the recording system.

Burnett, Ron↗
NASA NTRS1994

An experiment to assess the cost-benefits of code inspections in large scale software development

This experiment (currently in progress) is designed to measure costs and benefits of different code inspection methods. It is being performed with a real development team writing software for a commercial product. The dependent variables for each code unit's inspection are the elapsed time and the number of defects detected. We manipulate the method of inspection by randomly assigning reviewers, varying the number of reviewers and the number of teams, and, when using more than one team, randomly assigning author repair and non-repair of detected defects between code inspections. After collecting and analyzing the first 17 percent of the data, we have discovered several interesting facts about reviewers, about the defects recorded during reviewer preparation and during the inspection collection meeting, and about the repairs that are eventually made. (1) Only 17 percent of the defects that reviewers record in their preparations are true defects that are later repaired. (2) Defects recorded at the inspection meetings fall into three categories: 18 percent false positives requiring no author repair, 57 percent soft maintenance where the author makes changes only for readability or code standard enforcement, and 25 percent true defects requiring repair. (3) The median elapsed calendar time for code inspections is 10 working days - 8 working days before the collection meeting and 2 after. (4) In the collection meetings, 31 percent of the defects discovered by reviewers during preparation are suppressed. (5) Finally, 33 percent of the true defects recorded are discovered at the collection meetings and not during any reviewer's preparation. The results to date suggest that inspections with two sessions (two different teams) of two reviewers per session (2sX2p) are the most effective. These two-session inspections may be performed with author repair or with no author repair between the two sessions. We are finding that the two-session, two-person with repair (2sX2pR) inspections are the most expensive, taking 15 working days of calendar time from the time the code is ready for review until author repair is complete, whereas two-session, two-person with no repair (2sX2pN) inspections take only 10 working days, but find about 10 percent fewer defects.

Porter, A.↗
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 NTRS1984

Guidelines for development structured FORTRAN programs

Computer programming and coding standards were compiled to serve as guidelines for the uniform writing of FORTRAN 77 programs at NASA Langley. Software development philosophy, documentation, general coding conventions, and specific FORTRAN coding constraints are discussed.

Earnest, B. M.↗
NASA NTRS1995

NED and SIMBAD Conventions for Bibliographic Reference Coding

The primary purpose of the 'reference code' is to provide a unique and traceable representation of a bibliographic reference within the structure of each database. The code is used frequently in the interfaces as a succinct abbreviation of a full bibliographic reference. Since its inception, it has become a standard code not only for NED and SIMBAD, but also for other bibliographic services.

NED SIMBAD bibliographic reference coding astronom↗
NASA NTRS2003

XML-Based Generator of C++ Code for Integration With GUIs

An open source computer program has been developed to satisfy a need for simplified organization of structured input data for scientific simulation programs. Typically, such input data are parsed in from a flat American Standard Code for Information Interchange (ASCII) text file into computational data structures. Also typically, when a graphical user interface (GUI) is used, there is a need to completely duplicate the input information while providing it to a user in a more structured form. Heretofore, the duplication of the input information has entailed duplication of software efforts and increases in susceptibility to software errors because of the concomitant need to maintain two independent input-handling mechanisms. The present program implements a method in which the input data for a simulation program are completely specified in an Extensible Markup Language (XML)-based text file. The key benefit for XML is storing input data in a structured manner. More importantly, XML allows not just storing of data but also describing what each of the data items are. That XML file contains information useful for rendering the data by other applications. It also then generates data structures in the C++ language that are to be used in the simulation program. In this method, all input data are specified in one place only, and it is easy to integrate the data structures into both the simulation program and the GUI. XML-to-C is useful in two ways: 1. As an executable, it generates the corresponding C++ classes and 2. As a library, it automatically fills the objects with the input data values.

Hua, Hook↗
NASA NTRS1990

Finding the complete path and weight enumerators of convolutional codes

A method for obtaining the complete path enumerator T(D, L, I) of a convolutional code is described. A system of algebraic equations is solved, using a new algorithm for computing determinants, to obtain T(D, L, I) for the (7,1/2) NASA standard code. Generating functions, derived from T(D, L, I) are used to upper bound Viterbi decoder error rates. This technique is currently feasible for constraint length K less than 10 codes. A practical, fast algorithm is presented for computing the leading nonzero coefficients of the generating functions used to bound the performance of constraint length K less than 20 codes. Code profiles with about 50 nonzero coefficients are obtained with this algorithm for the experimental K = 15, rate 1/4, code in the Galileo mission and for the proposed K = 15, rate 1/6, 2-dB code.

Onyszchuk, I.↗
NASA NTRS2010

Comparison of ORSAT and SCARAB Reentry Analysis Tools for a Generic Satellite Test Case

Reentry analysis is essential to understanding the consequences of the full life cycle of a spacecraft. Since reentry is a key factor in spacecraft development, NASA and ESA have separately developed tools to assess the survivability of objects during reentry. Criteria such as debris casualty area and impact energy are particularly important to understanding the risks posed to people on Earth. Therefore, NASA and ESA have undertaken a series of comparison studies of their respective reentry codes for verification and improvements in accuracy. The NASA Object Reentry Survival Analysis Tool (ORSAT) and the ESA Spacecraft Atmospheric Reentry and Aerothermal Breakup (SCARAB) reentry analysis tools serve as standard codes for reentry survivability assessment of satellites. These programs predict whether an object will demise during reentry and calculate the debris casualty area of objects determined to survive, establishing the reentry risk posed to the Earth's population by surviving debris. A series of test cases have been studied for comparison and the most recent uses "Testsat," a conceptual satellite composed of generic parts, defined to use numerous simple shapes and various materials for a better comparison of the predictions of these two codes. This study is an improvement on the others in this series because of increased consistency in modeling techniques and variables. The overall comparison demonstrated that the two codes arrive at similar results. Either most objects modeled resulted in close agreement between the two codes, or if the difference was significant, the variance could be explained as a case of semantics in the model definitions. This paper presents the main results of ORSAT and SCARAB for the Testsat case and discusses the sources of any discovered differences. Discussion of the results of previous comparisons is made for a summary of differences between the codes and lessons learned from this series of tests.

Kelley, Robert L.↗
NASA NTRS2004

PVM Wrapper

PVM Wrapper is a software library that makes it possible for code that utilizes the Parallel Virtual Machine (PVM) software library to run using the message-passing interface (MPI) software library, without needing to rewrite the entire code. PVM and MPI are the two most common software libraries used for applications that involve passing of messages among parallel computers. Since about 1996, MPI has been the de facto standard. Codes written when PVM was popular often feature patterns of {"initsend," "pack," "send"} and {"receive," "unpack"} calls. In many cases, these calls are not contiguous and one set of calls may even exist over multiple subroutines. These characteristics make it difficult to obtain equivalent functionality via a single MPI "send" call. Because PVM Wrapper is written to run with MPI- 1.2, some PVM functions are not permitted and must be replaced - a task that requires some programming expertise. The "pvm_spawn" and "pvm_parent" function calls are not replaced, but a programmer can use "mpirun" and knowledge of the ranks of parent and child tasks with supplied macroinstructions to enable execution of codes that use "pvm_spawn" and "pvm_parent."

Katz, Daniel↗
NASA NTRS2018

PIV and Rotational Raman-Based Temperature Measurements for CFD Validation in a Single Injector Cooling Flow

NASA's Turbulent Heat Flux (THX) task under the Transformational Tools & Technologies project is focused on acquiring benchmark temperature and velocity data in turbulent shear layers for validation of computational fluid dynamics (CFD) codes. Standard CFD turbulence models lack the ability to accurately calculate a number of fundamental flow phenomena, including the turbulent transport of heat. In nearly all production class Reynolds-averaged Navier-Stokes (RANS) CFD codes, a gradient-diffusion approximation is used whereby a constant turbulent Prantdl number, Prt, is used to relate an eddy viscosity calculated for the momentum terms, to the turbulent heat flux terms. The default in most CFD codes is Prt = 0.9, however this is not representative of all flows. As discussed in Yoder et al. (2015) and Reynolds (1974), Prt = 0.7 is felt to be more appropriate for jets. Recent work, as discussed in Yoder (2016a), has explored more complex formulations including variable turbulent Prantdl number models. PARTICLE IMAGE VELOCIMETRY; TEMPERATURE MEASURING INSTRUMENTS; FILM COOLING; HIGH TEMPERATURE GASES; COMPUTATIONAL FLUID DYNAMICS; PREDICTION ANALYSIS TECHNIQUES; TURBULENCE MODELS; RAMAN SPECTRA; VELOCITY; MACH NUMBER; GAS TURBINE ENGINES; NOZZLE FLOW; THERMOCOUPLES; LASER INDUCED FLUORESCENCE; COOLING FLOWS (ASTROPHYSICS); RAMAN SPECTROSCOPY; HEAT FLUX

Wernet, Mark P.↗
NASA NTRS1976

Recommendations for the performance rating of flat plate terrestrial photovoltaic solar panels

A review of recommendations for standardizing the performance rating of flat plate terrestrial solar panels is given to develop an international standard code of practice for performance rating. Required data to characterize the performance of a solar panel are listed. Other items discussed are: (1) basic measurement procedures; (2) performance measurement in natural sunlight and simulated sunlight; (3) standard solar cells; (4) the normal incidence method; (5) global method and (6) definition of peak power.

Treble, F. C.↗
NASA NTRS2000

Software Released by LEWICE 2.0 Ice Accretion Software Development Project

Computational icing simulation methods are making the transition from the realm of research to commonplace use in design and certification. As such, standards of software management, design, validation, and documentation must be adjusted to accommodate the increased expectations of the user community with respect to accuracy, reliability, capability, and usability. With this in mind, in collaboration with Glenn's Engineering Design and Analysis Division, the Icing Branch of the NASA Glenn Research Center at Lewis Field began a software improvement project focused on the two-dimensional ice accretion simulation tool LEWICE. This project is serving as an introduction to the concepts of software management and is intended to serve as a pilot project for future icing simulation code development. The LEWICE 2.0 Software Development Project consisted of two major elements: software management and software validation. The software management element consisted of identifying features of well-designed and well-managed software that are appropriate for an analytical prediction tool such as LEWICE and applying them to a revised version of the code. This element included tasks such as identification of software requirements, development and implementation of coding standards, and implementation of software revision control practices. With the application of these techniques, the LEWICE ice accretion code became a more stable and reliable software product. In addition, the lessons learned about software development and maintenance can be factored into future software projects at the outset. The software validation activity was an integral part of our effort to make LEWICE a more accurate and reliable analysis tool. Because of the efforts taken to extensively validate this software, LEWICE 2.0 is more robust than previous releases and can reproduce results accurately across several computing platforms. It also differs from previous versions in the extensive quantitative comparisons of its results with a data base of ice shapes that were generated in Glenn's Icing Research Tunnel. The results of the shape comparisons were analyzed to determine the range of meteorological conditions under which LEWICE 2.0 is within the repeatability found for ice shapes obtained from experiments. These comparisons show that the average variation of LEWICE 2.0 from experimental data is 7.2 percent, whereas the overall variability of the experimental data is 2.5 percent. The LEWICE 2.0 Software Development Project resulted in the release, at the recent Icing Branch LEWICE Workshop, of a more useful and robust analysis tool than was previously available to the icing community. The lessons learned from this project will be applied to the Icing Branch s future software development efforts.

Potapczuk, Mark G.↗
NASA NTRS1990

Prediction of the Thrust Performance and the Flowfield of Liquid Rocket Engines

In an effort to improve the current solutions in the design and analysis of liquid propulsive engines, a computational fluid dynamics (CFD) model capable of calculating the reacting flows from the combustion chamber, through the nozzle to the external plume, was developed. The Space Shuttle Main Engine (SSME) fired at sea level, was investigated as a sample case. The CFD model, FDNS, is a pressure based, non-staggered grid, viscous/inviscid, ideal gas/real gas, reactive code. An adaptive upwinding differencing scheme is employed for the spatial discretization. The upwind scheme is based on fourth order central differencing with fourth order damping for smooth regions, and second order central differencing with second order damping for shock capturing. It is equipped with a CHMQGM equilibrium chemistry algorithm and a PARASOL finite rate chemistry algorithm using the point implicit method. The computed flow results and performance compared well with those of other standard codes and engine hot fire test data. In addition, the transient nozzle flowfield calculation was also performed to demonstrate the ability of FDNS in capturing the flow separation during the startup process.

Wang, T.-S.↗
NASA NTRS1997

Safety Standard for Hydrogen and Hydrogen Systems: Guidelines for Hydrogen System Design, Materials Selection, Operations, Storage and Transportation

The NASA Safety Standard, which establishes a uniform process for hydrogen system design, materials selection, operation, storage, and transportation, is presented. The guidelines include suggestions for safely storing, handling, and using hydrogen in gaseous (GH2), liquid (LH2), or slush (SLH2) form whether used as a propellant or non-propellant. The handbook contains 9 chapters detailing properties and hazards, facility design, design of components, materials compatibility, detection, and transportation. Chapter 10 serves as a reference and the appendices contained therein include: assessment examples; scaling laws, explosions, blast effects, and fragmentation; codes, standards, and NASA directives; and relief devices along with a list of tables and figures, abbreviations, a glossary and an index for ease of use. The intent of the handbook is to provide enough information that it can be used alone, but at the same time, reference data sources that can provide much more detail if required.

Source record↗
NASA NTRS1995

A Loader for Executing Multi-Binary Applications on the Thinking Machines CM-5: It's Not Just for SPMD Anymore

The Thinking Machines CM-5 platform was designed to run single program, multiple data (SPMD) applications, i.e., to run a single binary across all nodes of a partition, with each node possibly operating on different data. Certain classes of applications, such as multi-disciplinary computational fluid dynamics codes, are facilitated by the ability to have subsets of the partition nodes running different binaries. In order to extend the CM-5 system software to permit such applications, a multi-program loader was developed. This system is based on the dld loader which was originally developed for workstations. This paper provides a high level description of dld, and describes how it was ported to the CM-5 to provide support for multi-binary applications. Finally, it elaborates how the loader has been used to implement the CM-5 version of MPIRUN, a portable facility for running multi-disciplinary/multi-zonal MPI (Message-Passing Interface Standard) codes.

Becker, Jeffrey C.↗
NASA NTRS1991

Numerical study of high-area-ratio H2/O2 rocket nozzles

Calculations were made for high-area-ratio H2/O2 rocket nozzles by using the RPLUS code which employs an implicit finite volume, lower-upper symmetric successive over-relaxation scheme to solve the Navier-Stokes equations and the species equations in a coupled manner. The combustion processes of hydrogen and oxygen are modeled by an 8-species and 18-step reaction mechanism, and the turbulence is simulated by the Baldwin-Lomax turbulence model with a pressure gradient correction on the van Driest's damping constant in the inner-layer model. The calculated results for two different rocket nozzles are presented as contours, profiles, and performance values. The predicted specific impulse and thrust agree well with the experimental data and those from the industry standard code. It is demonstrated that the RPLUS code can be used for analysis of rocket nozzles.

Kim, S. C.↗
NASA NTRS2005

Shuttle-Data-Tape XML Translator

JSDTImport is a computer program for translating native Shuttle Data Tape (SDT) files from American Standard Code for Information Interchange (ASCII) format into databases in other formats. JSDTImport solves the problem of organizing the SDT content, affording flexibility to enable users to choose how to store the information in a database to better support client and server applications. JSDTImport can be dynamically configured by use of a simple Extensible Markup Language (XML) file. JSDTImport uses this XML file to define how each record and field will be parsed, its layout and definition, and how the resulting database will be structured. JSDTImport also includes a client application programming interface (API) layer that provides abstraction for the data-querying process. The API enables a user to specify the search criteria to apply in gathering all the data relevant to a query. The API can be used to organize the SDT content and translate into a native XML database. The XML format is structured into efficient sections, enabling excellent query performance by use of the XPath query language. Optionally, the content can be translated into a Structured Query Language (SQL) database for fast, reliable SQL queries on standard database server computers.

Barry, Matthew R.↗