Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “coding productivity”

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 163 records · Page 9

Increasing productivity through Total Reuse Management (TRM)

Total Reuse Management (TRM) is a new concept currently being promoted by the NASA Langley Software Engineering and Ada Lab (SEAL). It uses concepts similar to those promoted in Total Quality Management (TQM). Both technical and management personnel are continually encouraged to think in terms of reuse. Reuse is not something that is aimed for after a product is completed, but rather it is built into the product from inception through development. Lowering software development costs, reducing risk, and increasing code reliability are the more prominent goals of TRM. Procedures and methods used to adopt and apply TRM are described. Reuse is frequently thought of as only being applicable to code. However, reuse can apply to all products and all phases of the software life cycle. These products include management and quality assurance plans, designs, and testing procedures. Specific examples of successfully reused products are given and future goals are discussed.

Schuler, M. P.↗

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗

Rocket-Plume Spectroscopy Simulation for Hydrocarbon-Fueled Rocket Engines

The UV-Vis spectroscopic system for plume diagnostics monitors rocket engine health by using several analytical tools developed at Stennis Space Center (SSC), including the rocket plume spectroscopy simulation code (RPSSC), to identify and quantify the alloys from the metallic elements observed in engine plumes. Because the hydrocarbon-fueled rocket engine is likely to contain C2, CO, CH, CN, and NO in addition to OH and H2O, the relevant electronic bands of these molecules in the spectral range of 300 to 850 nm in the RPSSC have been included. SSC incorporated several enhancements and modifications to the original line-by-line spectral simulation computer program implemented for plume spectral data analysis and quantification in 1994. These changes made the program applicable to the Space Shuttle Main Engine (SSME) and the Diagnostic Testbed Facility Thruster (DTFT) exhaust plume spectral data. Modifications included updating the molecular and spectral parameters for OH, adding spectral parameter input files optimized for the 10 elements of interest in the spectral range from 320 to 430 nm and linking the output to graphing and analysis packages. Additionally, the ability to handle the non-uniform wavelength interval at which the spectral computations are made was added. This allowed a precise superposition of wavelengths at which the spectral measurements have been made with the wavelengths at which the spectral computations are done by using the line-by-line (LBL) code. To account for hydrocarbon combustion products in the plume, which might interfere with detection and quantification of metallic elements in the spectral region of 300 to 850 nm, the spectroscopic code has been enhanced to include the carbon-based combustion species of C2, CO, and CH. In addition, CN and NO have spectral bands in 300 to 850 nm and, while these molecules are not direct products of hydrocarbon-oxygen combustion systems, they can show up if nitrogen or a nitrogen compound is present as an impurity in the propellants and/or these can form in the boundary layer as a result of interaction of the hot plume with the atmosphere during the ground testing of engines. Ten additional electronic band systems of these five molecules have been included into the code. A comprehensive literature search was conducted to obtain the most accurate values for the molecular and the spectral parameters, including Franck-Cordon factors and electronic transition moments for all ten band systems. For each elemental transition in the RPSSC, six spectral parameters - Doppler broadened line width at half-height, pressure-broadened line width at half-height, electronic multiplicity of the upper state, electronic term energy of the upper state, Einstein transition probability coefficient, and the atomic line center - are required. Input files have been created for ten elements of Ni, Fe, Cr, Co, Cu, Ca, Mn, Al, Ag, and Pd, which retain only relatively moderate to strong transitions in 300 to 430 nm spectral range for each element. The number of transitions in the input files is 68 for Ni; 148 for Fe; 6 for Cr; 87 for Co; 1 for Ca; 3 for Mn; 2 each for Cu, Al, and Ag; and 11 for Pd.

Tejwani, Gopal D.↗

CGRO Guest Investigator Program

The following are highlights from the research supported by this grant: (1) Theory of gamma-ray blazars: We studied the theory of gamma-ray blazars, being among the first investigators to propose that the GeV emission arises from Comptonization of diffuse radiation surrounding the jet, rather than from the synchrotron-self-Compton mechanism. In related work, we uncovered possible connections between the mechanisms of gamma-ray blazars and those of intraday radio variability, and have conducted a general study of the role of Compton radiation drag on the dynamics of relativistic jets. (2) A Nonlinear Monte Carlo code for gamma-ray spectrum formation: We developed, tested, and applied the first Nonlinear Monte Carlo (NLMC) code for simulating gamma-ray production and transfer under much more general (and realistic) conditions than are accessible with other techniques. The present version of the code is designed to simulate conditions thought to be present in active galactic nuclei and certain types of X-ray binaries, and includes the physics needed to model thermal and nonthermal electron-positron pair cascades. Unlike traditional Monte-Carlo techniques, our method can accurately handle highly non-linear systems in which the radiation and particle backgrounds must be determined self-consistently and in which the particle energies span many orders of magnitude. Unlike models based on kinetic equations, our code can handle arbitrary source geometries and relativistic kinematic effects In its first important application following testing, we showed that popular semi-analytic accretion disk corona models for Seyfert spectra are seriously in error, and demonstrated how the spectra can be simulated if the disk is sparsely covered by localized 'flares'.

Begelman, Mitchell C.↗

Ada software productivity prototypes: A case study

A case study of the impact of Ada on a Command and Control project completed at the Jet Propulsion Laboratory (JPL) is given. The data for this study was collected as part of a general survey of software costs and productivity at JPL and other NASA sites. The task analyzed is a successful example of the use of rapid prototyping as applied to command and control for the U.S. Air Force and provides the U.S. Air Force Military Airlift Command with the ability to track aircraft, air crews and payloads worldwide. The task consists of a replicated database at several globally distributed sites. The local databases at each site can be updated within seconds after changes are entered at any one site. The system must be able to handle up to 400,000 activities per day. There are currently seven sites, each with a local area network of computers and a variety of user displays; the local area networks are tied together into a single wide area network. Using data obtained for eight modules, totaling approximately 500,000 source lines of code, researchers analyze the differences in productivities between subtasks. Factors considered are percentage of Ada used in coding, years of programmer experience, and the use of Ada tools and modern programming practices. The principle findings are the following. Productivity is very sensitive to programmer experience. The use of Ada software tools and the use of modern programming practices are important; without such use Ada is just a large complex language which can cause productivity to decrease. The impact of Ada on development effort phases is consistent with earlier reports at the project level but not at the module level.

Hihn, Jairus M.↗

Trellises and Trellis-Based Decoding Algorithms for Linear Block Codes

A code trellis is a graphical representation of a code, block or convolutional, in which every path represents a codeword (or a code sequence for a convolutional code). This representation makes it possible to implement Maximum Likelihood Decoding (MLD) of a code with reduced decoding complexity. The most well known trellis-based MLD algorithm is the Viterbi algorithm. The trellis representation was first introduced and used for convolutional codes [23]. This representation, together with the Viterbi decoding algorithm, has resulted in a wide range of applications of convolutional codes for error control in digital communications over the last two decades. There are two major reasons for this inactive period of research in this area. First, most coding theorists at that time believed that block codes did not have simple trellis structure like convolutional codes and maximum likelihood decoding of linear block codes using the Viterbi algorithm was practically impossible, except for very short block codes. Second, since almost all of the linear block codes are constructed algebraically or based on finite geometries, it was the belief of many coding theorists that algebraic decoding was the only way to decode these codes. These two reasons seriously hindered the development of efficient soft-decision decoding methods for linear block codes and their applications to error control in digital communications. This led to a general belief that block codes are inferior to convolutional codes and hence, that they were not useful. Chapter 2 gives a brief review of linear block codes. The goal is to provide the essential background material for the development of trellis structure and trellis-based decoding algorithms for linear block codes in the later chapters. Chapters 3 through 6 present the fundamental concepts, finite-state machine model, state space formulation, basic structural properties, state labeling, construction procedures, complexity, minimality, and sectionalization of trellises. Chapter 7 discusses trellis decomposition and subtrellises for low-weight codewords. Chapter 8 first presents well known methods for constructing long powerful codes from short component codes or component codes of smaller dimensions, and then provides methods for constructing their trellises which include Shannon and Cartesian product techniques. Chapter 9 deals with convolutional codes, puncturing, zero-tail termination and tail-biting.Chapters 10 through 13 present various trellis-based decoding algorithms, old and new. Chapter 10 first discusses the application of the well known Viterbi decoding algorithm to linear block codes, optimum sectionalization of a code trellis to minimize computation complexity, and design issues for IC (integrated circuit) implementation of a Viterbi decoder. Then it presents a new decoding algorithm for convolutional codes, named Differential Trellis Decoding (DTD) algorithm. Chapter 12 presents a suboptimum reliability-based iterative decoding algorithm with a low-weight trellis search for the most likely codeword. This decoding algorithm provides a good trade-off between error performance and decoding complexity. All the decoding algorithms presented in Chapters 10 through 12 are devised to minimize word error probability. Chapter 13 presents decoding algorithms that minimize bit error probability and provide the corresponding soft (reliability) information at the output of the decoder. Decoding algorithms presented are the MAP (maximum a posteriori probability) decoding algorithm and the Soft-Output Viterbi Algorithm (SOVA) algorithm. Finally, the minimization of bit error probability in trellis-based MLD is discussed.

Lin, Shu↗

Space station human productivity study. Volume 4: Issues

The 305 Issues contained represent topics recommended for study in order to develop requirements in support of space station crew performance/productivity. The overall subject matter, space station elements affecting crew productivity, was organized into a coded subelement listing, which is included for the reader's reference. Each issue is numbered according to the 5-digit topical coding scheme. The requirements column on each Issue page shows a cross-reference to the unresolved requirement statement(s). Because topical overlaps were frequently encountered, many initial Issues were consolidated. Apparent gaps, therefore, may be accounted for by an Issue described within a related subelement. A glossary of abbreviations used throughout the study documentation is also included.

Source record↗

Cascade model of gamma-ray bursts: Power-law and annihilation-line components

If, in a neutron star magnetosphere, an electron is accelerated to an energy of 10 to the 11th or 12th power eV by an electric field parallel to the magnetic field, motion of the electron along the curved field line leads to a cascade of gamma rays and electron-positron pairs. This process is believed to occur in radio pulsars and gamma ray burst sources. Results are presented from numerical simulations of the radiation and photon annihilation pair production processes, using a computer code previously developed for the study of radio pulsars. A range of values of initial energy of a primary electron was considered along with initial injection position, and magnetic dipole moment of the neutron star. The resulting spectra was found to exhibit complex forms that are typically power law over a substantial range of photon energy, and typically include a dip in the spectrum near the electron gyro-frequency at the injection point. The results of a number of models are compared with data for the 5 Mar., 1979 gamma ray burst. A good fit was found to the gamma ray part of the spectrum, including the equivalent width of the annihilation line.

Harding, A. K.↗

Cascade model of gamma-ray bursts

If, in a neutron star magnetosphere, an electron is accelerated to an energy of 10 to the 11th or 12th power eV by an electric field parallel to the magnetic field, motion of the electron along the curved field line leads to a cascade of gamma rays and electron-positron pairs. This process is believed to occur in radio pulsars and gamma ray burst sources. Results are presented from numerical simulations of the radiation and photon annihilation pair production processes, using a computer code previously developed for the study of radio pulsars. A range of values of initial energy of a primary electron was considered along with initial injection position, and magnetic dipole moment of the neutron star. The resulting spectra was found to exhibit complex forms that are typically power law over a substantial range of photon energy, and typically include a dip in the spectrum near the electron gyro-frequency at the injection point. The results of a number of models are compared with data for the 5 Mar., 1979 gamma ray burst. A good fit was found to the gamma ray part of the spectrum, including the equivalent width of the annihilation line.

Sturrock, P. A.↗

Activities of the NASA/Marshall Space Flight Center pump stage technology team

In order to advance rocket propulsion technology, the Consortium for Computational Fluid Dynamics (CFD) Application in Propulsion Technology has been formed at Marshall Space Flight Center (MSFC). The Consortium consists of three Teams: the turbine stage team, the pump stage team (PST), and the combustion devices team. The PST has formulated and is implementing a plan for pump technology development whose end product will be validated CFD codes suitable for application to pump components, test data suitable for validating CFD codes, and advanced pump components optimized using CFD codes. The PST's work during the fall of 1991 and the winter and spring of 1992 is discussed in this paper. This work is highlighted by CFD analyses of an advanced impeller design and collection of laser two-focus velocimeter data for the Space Shuttle Main Engine High Pressure Fuel Pump impeller.

Garcia, R.↗

Analysis of a hypersonic waverider research vehicle with a hydrocarbon scramjet engine

The results of a feasibility study of a hypersonic waverider research vehicle with a hydrocarbon scramjet engine are presented. The integrated waverider/scramjet geometry is first optimized with a vehicle synthesis code to produce a maximum product of the lift-to-drag ratio and the cycle specific impulse, hence cruise range. Computational fluid dynamics (CFD) is then employed to provide a nose-to-tail analysis of the system at the on-design conditions. Some differences are noted between the results of the two analysis techniques. A comparison of experimental, engineering analysis and CFD results on a waverider forebody are also included for validation.

Molvik, Gregory A.↗

A recent Cleanroom success story: The Redwing project

Redwing is the largest completed Cleanroom software engineering project in IBM, both in terms of lines of code and project staffing. The product provides a decision-support facility that utilizes artificial intelligence (AI) technology for predicting and preventing complex operating problems in an MVS environment. The project used the Cleanroom process for development and realized a defect rate of 2.6 errors/KLOC, measured from first execution. This represents the total amount of errors that were found in testing and installation at three field test sites. Development productivity was 486 LOC/PM, which included all development labor expended in design specification through completion of incremental testing. In short, the Redwing team produced a complex systems software product with an extraordinarily low error rate, while maintaining high productivity. All of this was accomplished by a project team using Cleanroom for the first time. An 'introductory implementation' of Cleanroom was defined and used on Redwing. This paper describes the quality and productivity results, the Redwing project, and how Cleanroom was implemented.

Hausler, Philip A.↗

Comparison of Mixing Calculations for Reacting and Non-Reacting Flows in a Cylindrical Duct

A production 3-D elliptic flow code has been used to calculate non-reacting and reacting flow fields in an experimental mixing section relevant to a rich burn/quick mix/lean burn (RQL) combustion system. A number of test cases have been run to assess the effects of the variation in the number of orifices, mass flow ratio, and rich-zone equivalence ratio on the flow field and mixing rates. The calculated normalized temperature profiles for the non-reacting flow field agree qualitatively well with the normalized conserved variable isopleths for the reacting flow field indicating that non-reacting mixing experiments are appropriate for screening and ranking potential rapid mixing concepts. For a given set of jet momentum-flux ratio, mass flow ratio, and density ratio (J, MR, and DR), the reacting flow calculations show a reduced level of mixing compared to the non-reacting cases. In addition, the rich-zone equivalence ratio has noticeable effect on the mixing flow characteristics for reacting flows.

Oechsle, V. L.↗

Evaluation of IGS Orbits with Satellite Laser Ranging

The accuracy with which orbits for the Global Positioning System (GPS) spacecraft, can be computed directly affects the accuracy of the resulting site coordinates and polar motion. Several groups routinely analyze GPS ground tracking data to compute precise orbits and terrestrial reference frame solutions. In this paper, we infer the accuracy of the orbits of two of the GPS satellites by comparing to independent laser ranges of subcentimeter accuracy obtained by a small but reasonably well distributed network of tracking sites. We find that all seven International GPS Service for Geodynamics (IGS) analysis centers achieve range residual root mean square (rms) errors at or below the 100 mm level. The best orbit solutions, from JPL, CODE, and the IGS combined product, yield a residual rms of about 50 mm. These residuals are consistent with three dimensional orbit errors of less than 150 mm. Estimating yaw rates for the spacecraft during shadow events, and using these estimates to compute the laser residual, significantly improves the fit. A small mean residual value of -15 to -30 mm seems to exist for most centers and laser sites which is not fully explained at present, but may be due to uncertainties in the corrections to the laser data, such as the reflector to spacecraft center of mass vector or small reference frame differences between the SLR sites and the GPS orbits.

Watkins, M. M.↗

Establishing an IERS Sub-Center for Ocean Angular Momentum

The primary responsibilities of the NCAR component of this project are the following: (1) Acting as liaison with the international ocean modeling community; and (2) Developing standardized algorithms to compute desired ocean model products, and providing template source code for these algorithms in widely used global ocean models.

Bryan, Frank↗

A Two-Stage Procedure Toward the Efficient Implementation of PANS and Other Hybrid Turbulence Models

The main objective of this article is to introduce and to show the implementation of a novel two-stage procedure to efficiently estimate the level of scale resolution possible for a given flow on a given grid for Partial Averaged Navier-Stokes (PANS) and other hybrid models. It has been found that the prescribed scale resolution can play a major role in obtaining accurate flow solutions. The first step is to solve the unsteady or steady Reynolds Averaged Navier-Stokes (URANS/RANS) equations. From this preprocessing step, the turbulence length-scale field is obtained. This is then used to compute the characteristic length-scale ratio between the turbulence scale and the grid spacing. Based on this ratio, we can assess the finest scale resolution that a given grid for a given flow can support. Along with other additional criteria, we are able to analytically identify the appropriate hybrid solver resolution for different regions of the flow. This procedure removes the grid dependency issue that affects the results produced by different hybrid procedures in solving unsteady flows. The formulation, implementation methodology, and validation example are presented. We implemented this capability in a production Computational Fluid Dynamics (CFD) code, PAB3D, for the simulation of unsteady flows.

Abdol-Hamid, Khaled S.↗

Simulating Avionics Upgrades to the Space Shuttles

Cockpit Avionics Prototyping Environment (CAPE) is a computer program that simulates the functions of proposed upgraded avionics for a space shuttle. In CAPE, pre-existing space-shuttle-simulation programs are merged with a commercial-off-the-shelf (COTS) display-development program, yielding a package of software that enables high-fi46 NASA Tech Briefs, September 2008 delity simulation while making it possible to rapidly change avionic displays and the underlying model algorithms. The pre-existing simulation programs are Shuttle Engineering Simulation, Shuttle Engineering Simulation II, Interactive Control and Docking Simulation, and Shuttle Mission Simulator playback. The COTS program Virtual Application Prototyping System (VAPS) not only enables the development of displays but also makes it possible to move data about, capture and process events, and connect to a simulation. VAPS also enables the user to write code in the C or C++ programming language and compile that code into the end-product simulation software. As many as ten different avionic-upgrade ideas can be incorporated in a single compilation and, thus, tested in a single simulation run. CAPE can be run in conjunction with any or all of four simulations, each representing a different phase of a space-shuttle flight.

Deger, Daniel↗

System Synchronizes Recordings from Separated Video Cameras

A system of electronic hardware and software for synchronizing recordings from multiple, physically separated video cameras is being developed, primarily for use in multiple-look-angle video production. The system, the time code used in the system, and the underlying method of synchronization upon which the design of the system is based are denoted generally by the term "Geo-TimeCode(TradeMark)." The system is embodied mostly in compact, lightweight, portable units (see figure) denoted video time-code units (VTUs) - one VTU for each video camera. The system is scalable in that any number of camera recordings can be synchronized. The estimated retail price per unit would be about $350 (in 2006 dollars). The need for this or another synchronization system external to video cameras arises because most video cameras do not include internal means for maintaining synchronization with other video cameras. Unlike prior video-camera-synchronization systems, this system does not depend on continuous cable or radio links between cameras (however, it does depend on occasional cable links lasting a few seconds). Also, whereas the time codes used in prior video-camera-synchronization systems typically repeat after 24 hours, the time code used in this system does not repeat for slightly more than 136 years; hence, this system is much better suited for long-term deployment of multiple cameras.

Nail, William↗