Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “design software”

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 847 records · Page 47
All sourcesNASA NTRSDOE OSTI
NASA NTRS1995

Surface modeling and grid generation for aeropropulsion CFD

The efforts in geometry modeling and grid generation at the NASA Lewis Research Center, as applied to the computational fluid dynamic (CFD) analysis of aeropropulsion systems, are presented. The efforts are mainly characterized by a focus on the analysis of components of an aeropropulsion system, which involve turbulent viscous flow with heat transfer and chemistry. Thus, this discussion will follow that characterization and will sequence through the components of typical propulsion systems consisting of inlets, compressors, combustors, turbines, and nozzles. For each component, some applications of CFD analysis will be presented to show how CFD is used to compute the desired performance information, how geometry modeling and grid generation are performed, and what issues have developed related to geometry modeling and grid generation. The discussion will illustrate the following needs related to geometry modeling and grid generation as observed in aeropropulsion analysis: (1) accurate and efficient resolution of turbulent viscous and chemically-reacting flowfields; (2) easy-to-use interfaces with CAD data for automated grid generation about complex geometries; and (3) automated batch grid generation software for use with design and optimization software.

Choo, Yung K.↗
NASA NTRS1996

SEDSAT 1 Technologies

The original goals of this project were to support the development of SEDSAT 1 for a tethered launch in July of 1997. This specifically required: (1) Monitoring development progress against a comprehensive delivery plan; (2) Incremental development and release of CDS and SEASIS software; (3) Supporting the integration of version 1.0 SEASIS software that will allow minimal autonomous operation without a software reload. These algorithms would include image quality evaluation, attitude determination, and autonomous earth imaging; and (4) Developing software requirements and design for ground segment software, concentrating on command and data download capability; and interface to external development efforts for a more comprehensive software suite to be used after the initial mission. Because of an unfavorable space shuttle safety review of the SEDS-3 tether deployer, and cost and schedule problems in upgrading the deployer, the mission was changed to an independent launch of SEDSAT. The original plan was to do a tether-less deployment from the space shuttle. Since this would have resulted in an unacceptable orbital lifetime, the mission was changed again to a tethered launch from a Delta II in June 1998. As a result of Marshall Space Flight Center's redirection of the SEDS-3 mission away from a tether launch, the whole question of a tether endmass had to be reconsidered. The net result of these multiple changes was twofold. First, we completed work needed to define some aspects of ground software on SEDSAT 1 that would remain constant no matter the launch mode. Second, we developed a set of concepts for using SEDSAT 1 technology to support alternative endmass missions on SEDS-3. Both of these are included.

Maier, Mark W.↗
NASA NTRS1997

NASA Software Safety Standard

If software is a critical element in a safety critical system, it is imperative to implement a systematic approach to software safety as an integral part of the overall system safety programs. The NASA-STD-8719.13A, "NASA Software Safety Standard", describes the activities necessary to ensure that safety is designed into software that is acquired or developed by NASA, and that safety is maintained throughout the software life cycle. A PDF version, is available on the WWW from Lewis. A Guidebook that will assist in the implementation of the requirements in the Safety Standard is under development at the Lewis Research Center (LeRC). After completion, it will also be available on the WWW from Lewis.

Rosenberg, Linda↗
NASA NTRS2001

Chandra Space Flight Software: Using Software to Autonomously Operation the Largest and Most Sensitive X-Ray Telescope in the World

Chandra is the world's largest and most sensitive X-ray telescope. The Chandra X-ray Observatory is the third in NASA's family of "Great Observatories." The Chandra X-ray Observatory, launched by Space Shuttle Columbia on July 23, 1999, is NASA's newest Great Observatory. The Chandra space flight software is the operational software, which controls and directs the Chandra X-ray Observatory. The Chandra flight software has executed faultlessly for over 13,000 hours on-orbit. The Chandra flight software directly controls the Pointing, Aspect Determination, Electrical Power Subsystem, Propulsion system, and the Command, Communications, and Data Management subsystems. The software controls the spacecraft operations during all phases of the mission. The software also performs thermal control of the telescope to maintain pointing accuracy and monitors radiation levels throughout the orbit so that the Science Instruments can be safed if radiation thresholds are exceeded. The efficient operation of Chandra flight software has enabled the gathering of crucial science data. The Chandra flight software fault protection is the key to early detection and prevention of science instrument or spacecraft damage in an operating platform/environment, which is completely unforgiving. Permanently open Sun Shade Door and ACIS focal plane radiator sensitivity exposes science instruments and mirrors to damage for pointing anomalies causing an attitude excursion. The Chandra flight software must prevent these attitude excursions from occurring for ANY failure. Another example is that the power system has an unregulated bus, which imposes severe operating requirements on Chandra flight software to control array pointing and battery connection/disconnect using a unique algorithmic and logic approach. The Chandra flight software has enabled a truly autonomous vehicle with greater than 99% of all mission data collected as planned. Less than 15% of spacecraft operations are conducted in view (1 hour out of 8) leading to very extended periods without ground contact. The Chandra flight software implements the flexible mission plan during this out of view period, manages the solid state recorder capacity, controls all pointing and maneuvers, provides fault detection for all satellite subsystems, and initiates communications with the ground at the appropriate time. This paper will describe the software architecture features, key design elements and software testing techniques that have facilitated Chandra's success.

Crumbley, Tim↗
NASA NTRS2001

Automatic Debugging Support for UML Designs

Design of large software systems requires rigorous application of software engineering methods covering all phases of the software process. Debugging during the early design phases is extremely important, because late bug-fixes are expensive. In this paper, we describe an approach which facilitates debugging of UML requirements and designs. The Unified Modeling Language (UML) is a set of notations for object-orient design of a software system. We have developed an algorithm which translates requirement specifications in the form of annotated sequence diagrams into structured statecharts. This algorithm detects conflicts between sequence diagrams and inconsistencies in the domain knowledge. After synthesizing statecharts from sequence diagrams, these statecharts usually are subject to manual modification and refinement. By using the "backward" direction of our synthesis algorithm. we are able to map modifications made to the statechart back into the requirements (sequence diagrams) and check for conflicts there. Fed back to the user conflicts detected by our algorithm are the basis for deductive-based debugging of requirements and domain theory in very early development stages. Our approach allows to generate explanations oil why there is a conflict and which parts of the specifications are affected.

Schumann, Johann↗
NASA NTRSDate not supplied

Making & Breaking the Rules for DED Design

Design for Additive Manufacturing (DfAM) is widely used to describe design activities and guidelines employed in the creation of Additively Manufactured (AM) parts. Basic design rules for widely adopted processes like Powder Bed Fusion (PBF) are relatively understood including material performance, part size constraints, self-supporting angles, overhangs, wall thicknesses, and feature resolution. Complexity is often inherent with PBF using organically inspired solutions through generative design and topology optimization software to create designs that often cannot be realized via traditional manufacturing processes. The design rules for Directed Energy Deposition (DED) are less well known, and, in some cases, the lack of understanding is likely inhibiting broader application of the various DED processes. This presentation covers key design rules for DED fusion processes and elucidates opportunities like multi-material deposition and build approaches ranging from basic features to complex large-scale parts. Complementary to the opportunistic characteristics of DfAM for DED, Manufacture for AM (MfAM) encompasses the restrictive aspects of the manufacturing lifecycle with limitations due to bead width and wall thickness, self-supporting angles, surface texture, microstructural evolution, and residual stresses. AM enabled part design must always consider the entire value chain starting with incoming feedstock (e.g. plate, wire, or powder) and progressing through the printing process, post-processing (e.g. machining, inspection), and final system assembly. Key considerations, like the tradeoffs between feature resolution and build rate, for process and part selection and economic assessments will be discussed as DED is often traded against other AM processes. After highlighting typical DED design rules, we will also show how some of those rules can be broken via use cases and part designs that span the full spectrum of DED processes with examples of various DED part designs.

Additive Manufacturing↗
DOE OSTI2023

Generating MCNP Input Files for Unstructured Mesh Geometries

The Los Alamos National Laboratory’s (LANL) Monte Carlo N-Particle (MCNP)1 transport code version 6.3 (also known as MCNP6.3) has the capability for tracking particles on unstructured mesh (UM) geometry models embedded into constructive solid geometry (CSG) cells. This feature has been developed for performing calculations of complex geometry models because manually creating CSG models is time-consuming and error-prone as the complexities of geometries increase. A UM geometry model is a collection of finite elements representing a solid geometry. The first step of the MCNP UM calculation is using other software packages to create a finite element mesh representation of a solid 3D geometry because the MCNP code cannot be used to generate a UM model. Computer-aided design (CAD) software is typically used to create a solid geometry model, which is later imported into mesh generation software to create a UM model. Some mesh generation software packages may also be used to create solid geometries and thus CAD files are not needed. The MCNP UM feature was originally designed for models generated by the Abaqus/CAE software suite. The MCNP code version 6.0 and later can process UM models formatted as Abaqus input files. Starting with a 6.3 version, the MCNP code can process HDF5 mesh input files. We only focus on the UM models formatted as Abaqus input files in this report since currently no external software can be used to generate HDF5 mesh input files for MCNP UM calculations. The MCNP code version 6.3 can be used to convert the Abaqus mesh input files into the HDF5 mesh input files, but this option is typically used by the MCNP code development team to test the HDF5 mesh input file feature. Several software packages (such as Abaqus, Attila4MC, or Cubit) can be used to create the Abaqus input files for MCNP UM calculations. An MCNP UM calculation using an Abaqus model requires two input file types: MCNP and Abaqus input files. The Abaqus input files needed for MCNP UM calcu lations must have the correct Abaqus syntax and meet the additional requirements by the MCNP code. The MCNP code can process only Abaqus input files that make use of part and assembly definitions, where elements in each part must be grouped into one or more element sets (i.e., elset) using *Elset keyword lines with specified naming formats. The MCNP and Abaqus input files required for MCNP UM simulations must be related; pseudo-cells in an MCNP input file must be constructed from mesh model data from an Abaqus input file. For large complex UM models, it is tedious to manually create MCNP UM input files. The um pre op (unstructured mesh pre operations) program with the -m option can be used to create a skeleton MCNP input file from an Abaqus input file [6]. Since the um pre op program was written in Fortran and was not written for optimized performance, this program is a deprecated feature in the MCNP code version 6.3 and may be removed in the next release of the code. To improve calculation flow of multiphysics calculations, a Python3 code called write mcnp um input has been developed to generate an MCNP input file instead of using the um_pre_op -m option. This Python code was initially released to the public in 2020. We have updated this Python code for MCNP6.3 and it was used to generate the MCNP input files used to verify the MCNP6.3 code. The write_mcnp_um_input code is included with the MCNP6.3 code package which will be released to the public through the Radiation Safety Information Computational Center (RSICC) at Oak Ridge National Laboratory. This report is a revision of LA-UR-20-27139 report.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗
NASA NTRS1986

Towards a general object-oriented software development methodology

An object is an abstract software model of a problem domain entity. Objects are packages of both data and operations of that data (Goldberg 83, Booch 83). The Ada (tm) package construct is representative of this general notion of an object. Object-oriented design is the technique of using objects as the basic unit of modularity in systems design. The Software Engineering Laboratory at the Goddard Space Flight Center is currently involved in a pilot program to develop a flight dynamics simulator in Ada (approximately 40,000 statements) using object-oriented methods. Several authors have applied object-oriented concepts to Ada (e.g., Booch 83, Cherry 85). It was found that these methodologies are limited. As a result a more general approach was synthesized with allows a designer to apply powerful object-oriented principles to a wide range of applications and at all stages of design. An overview is provided of this approach. Further, how object-oriented design fits into the overall software life-cycle is considered.

Seidewitz, ED↗
NASA NTRS1998

Reuse Metrics for Object Oriented Software

One way to increase the quality of software products and the productivity of software development is to reuse existing software components when building new software systems. In order to monitor improvements in reuse, the level of reuse must be measured. In this NASA supported project we (1) derived a suite of metrics which quantify reuse attributes for object oriented, object based, and procedural software, (2) designed prototype tools to take these measurements in Ada, C++, Java, and C software, (3) evaluated the reuse in available software, (4) analyzed the relationship between coupling, cohesion, inheritance, and reuse, (5) collected object oriented software systems for our empirical analyses, and (6) developed quantitative criteria and methods for restructuring software to improve reusability.

Bieman, James M.↗
NASA NTRS2016

Buckling Design and Imperfection Sensitivity of Sandwich Composite Launch-Vehicle Shell Structures

Composite materials are increasingly being considered and used for launch-vehicle structures. For shell structures, such as interstages, skirts, and shrouds, honeycomb-core sandwich composites are often selected for their structural efficiency. Therefore, it is becoming increasingly important to understand the structural response, including buckling, of sandwich composite shell structures. Additionally, small geometric imperfections can significantly influence the buckling response, including considerably reducing the buckling load, of shell structures. Thus, both the response of the theoretically perfect structure and the buckling imperfection sensitivity must be considered during the design of such structures. To address the latter, empirically derived design factors, called buckling knockdown factors (KDFs), were developed by NASA in the 1960s to account for this buckling imperfection sensitivity during design. However, most of the test-article designs used in the development of these recommendations are not relevant to modern launch-vehicle constructions and material systems, and in particular, no composite test articles were considered. Herein, a two-part study on composite sandwich shells to (1) examine the relationship between the buckling knockdown factor and the areal mass of optimized designs, and (2) to interrogate the imperfection sensitivity of those optimized designs is presented. Four structures from recent NASA launch-vehicle development activities are considered. First, designs optimized for both strength and stability were generated for each of these structures using design optimization software and a range of buckling knockdown factors; it was found that the designed areal masses varied by between 6.1% and 19.6% over knockdown factors ranging from 0.6 to 0.9. Next, the buckling imperfection sensitivity of the optimized designs is explored using nonlinear finite-element analysis and the as-measured shape of a large-scale composite cylindrical shell. When compared with the current buckling design recommendations, the results suggest that the current recommendations are overly conservative and that the development of new recommendations could reduce the acreage areal mass of many composite sandwich shell designs by between 4% and 19%, depending on the structure.

Schultz, Marc R.↗
NASA NTRS2016

Design and Development of a Flight Route Modification, Logging, and Communication Network

There is an overwhelming desire to create and enhance communication mechanisms between entities that operate within the National Airspace System. Furthermore, airlines are always extremely interested in increasing the efficiency of their flights. An innovative system prototype was developed and tested that improves collaborative decision making without modifying existing infrastructure or operational procedures within the current Air Traffic Management System. This system enables collaboration between flight crew and airline dispatchers to share and assess optimized flight routes through an Internet connection. Using a sophisticated medium-fidelity flight simulation environment, a rapid-prototyping development, and a unified modeling language, the software was designed to ensure reliability and scalability for future growth and applications. Ensuring safety and security were primary design goals, therefore the software does not interact or interfere with major flight control or safety systems. The system prototype demonstrated an unprecedented use of in-flight Internet to facilitate effective communication with Airline Operations Centers, which may contribute to increased flight efficiency for airlines.

Merlino, Daniel K.↗
DOE OSTI2025

Designing a Framework for Solving Multiobjective Simulation Optimization Problems

Multiobjective simulation optimization (MOSO) problems are optimization problems with multiple conflicting objectives, where evaluation of at least one of the objectives depends on a black-box numerical code or real-world experiment, which we refer to as a simulation. Whereas an extensive body of research is dedicated to developing new algorithms and methods for solving these and related problems, it is challenging and time-consuming to integrate these techniques into real-world production-ready solvers. This is partly because of the diversity and complexity of modern state-of-the-art MOSO algorithms and methods and partly because of the complexity and specificity of many real-world problems and their corresponding computing environments. The complexity of this problem is only compounded when introducing potentially complex and/or domain-specific surrogate-modeling techniques, problem formulations, design spaces, and data acquisition functions. Here, this paper carefully surveys the current state of the art in MOSO algorithms, techniques, and solvers, as well as problem types and computational environments where MOSO is commonly applied. We then present several key challenges in the design of a parallel multiobjective simulation optimization framework (ParMOO) and how they have been addressed. Finally, we provide two case studies demonstrating how customized ParMOO solvers can be quickly built and deployed to solve real-world MOSO problems.

engineering design optimization↗
DOE OSTI2024

Enhancing the Functionality of a Hollow Scaffold Solid State Bioreactor via Computer Aided Design Optimization

The concern over greenhouse gases, methane (CH 4 ) and carbon dioxide (CO 2 ), is increasing rapidly. There have been strides to find solutions to this global issue but there is not a clear path to a successful end goal. The concentration of CH 4 and CO 2 in the atmosphere has increased significantly over the last 60 years, methane is a great source of concern due to its ability to trap a high amount of heat in the atmosphere. These greenhouse gases contribute to global warming which has caused changes in the environment, including the melting of ice caps, and altered weather patterns. Solutions for these pressing challenges have led to different avenues of methane mitigation one of which is the development of solid-state bioreactors. These reactors harness the power of biological species that have evolved to use methane as an energy source. The development and optimization of Hollow Scaffold Solid State Bioreactors (HS-SSBR) has become readily available due to the advancements in additive manufacturing technology and accessibility of computer aided design (CAD) software. With laboratory scale experiments, time and effort are of great importance. Enhancing the design of the HS-SSBR to create a more user-friendly interface, but also increase the functionality of the reactor. The reactor's design improvements focus on better dispersion of methane and circulation of media.

36 MATERIALS SCIENCE↗
NASA NTRS1978

Development of user guidelines for ECAS display design, volume 1

Experiment computer application software (ECAS) display design and command usage guidelines were developed, which if followed by spacelab experiments, would standardize methods and techniques for data presentation and commanding via ECAS. These guidelines would provide some commonality among experiments which would enhance crew training and flight operations. The guidelines are applicable to all onboard experiment displays, whether allocated by ECAS or a dedicated experiment processor. A brief description of the spacelab data display system characteristics and of the services provided by the experiment computer operating system is included. Guidelines concerning data presentation and layout of alphanumeric and graphic information are presented along with guidelines concerning keyboard commanding and command feedback.

Dodson, D. W.↗
NASA NTRS2015

Simulation and Measurement of Stray Light in the CLASP

We are planning an international rocket experiment Chromospheric Lyman-Alpha Spectro-Polarimeter (CLASP) is (2015 planned) that Lyman Alpha line polarization spectroscopic observations from the sun. The purpose of this experiment, detected with high accuracy of the linear polarization of the Ly􀉲 lines to 0.1% by using a Hanle effect is to measure the magnetic field of the chromosphere-transition layer directly. For total flux of the sun visible light overwhelmingly larger and about 200 000 times the Ly􀉲 line wavelength region, also hinder to 0.1% of the polarization photometric accuracy achieved in the stray light of slight visible light. Therefore we were first carried out using the illumination design analysis software called stray light simulation CLASP Light Tools. Feature of this simulation, using optical design file (ZEMAX format) and structural design file (STEP format), to reproduce realistic CLASP as possible to calculate machine is that it was stray study. And, at the stage in the actual equipment that made the provisional set of CLASP, actually put sunlight into CLASP using coelostat of National Astronomical Observatory of Japan, was subjected to measurement of stray light (San test). Pattern was not observed in the simulation is observed in the stray light measurement results need arise that measures. However, thanks to the stray light measurement and simulation was performed by adding, it was found this pattern is due to the diffracted light at the slit. Currently, the simulation results is where you have taken steps to reference. In this presentation, we report the stray light simulation and stray light measurement results that we have implemented

CLASP↗
NASA NTRS1997

Reuse of a Formal Model for Requirements Validation

This paper reports experience from how a project engaged in the process of requirements analysis for evolutionary builds can reuse the formally specified design model produced for a similar, earlier project in the same domain. Two levels of reuse are described here. First, a formally specified generic design model was generated on one project to systematically capture the design commonality in a set of software monitors on board a spacecraft. These monitors periodically check for faults and invoke recovery software when needed. The paper summarizes the use of the design model to validate the software design of the various monitors on that first project. Secondly, the paper describes how the formal design model created for the first project was reused on a second, subsequent project. The model was reused to validate the evolutionary requirements for the second project's software monitors, which were being developed in a series of builds. Some mismatches due to the very different architectures on the two projects suggested changes to make the model more generic. In addition, several advantages to the reuse of the first project's formal model on the second project are reported.

Lutz, Robyn R.↗
NASA NTRS2010

Optimization Testbed Cometboards Extended into Stochastic Domain

COMparative Evaluation Testbed of Optimization and Analysis Routines for the Design of Structures (CometBoards) is a multidisciplinary design optimization software. It was originally developed for deterministic calculation. It has now been extended into the stochastic domain for structural design problems. For deterministic problems, CometBoards is introduced through its subproblem solution strategy as well as the approximation concept in optimization. In the stochastic domain, a design is formulated as a function of the risk or reliability. Optimum solution including the weight of a structure, is also obtained as a function of reliability. Weight versus reliability traced out an inverted-S-shaped graph. The center of the graph corresponded to 50 percent probability of success, or one failure in two samples. A heavy design with weight approaching infinity could be produced for a near-zero rate of failure that corresponded to unity for reliability. Weight can be reduced to a small value for the most failure-prone design with a compromised reliability approaching zero. The stochastic design optimization (SDO) capability for an industrial problem was obtained by combining three codes: MSC/Nastran code was the deterministic analysis tool, fast probabilistic integrator, or the FPI module of the NESSUS software, was the probabilistic calculator, and CometBoards became the optimizer. The SDO capability requires a finite element structural model, a material model, a load model, and a design model. The stochastic optimization concept is illustrated considering an academic example and a real-life airframe component made of metallic and composite materials.

Patnaik, Surya N.↗