Search NASA⌕ Search

SEARCH · Search NASA

Results for “Computer program listings”

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 577 records · Page 32

Computer model to simulate testing at the National Transonic Facility

A computer model has been developed to simulate the processes involved in the operation of the National Transonic Facility (NTF), a large cryogenic wind tunnel at the Langley Research Center. The simulation was verified by comparing the simulated results with previously acquired data from three experimental wind tunnel test programs in the NTF. The comparisons suggest that the computer model simulates reasonably well the processes that determine the liquid nitrogen (LN2) consumption, electrical consumption, fan-on time, and the test time required to complete a test plan at the NTF. From these limited comparisons, it appears that the results from the simulation model are generally within about 10 percent of the actual NTF test results. The use of actual data acquisition times in the simulation produced better estimates of the LN2 usage, as expected. Additional comparisons are needed to refine the model constants. The model will typically produce optimistic results since the times and rates included in the model are typically the optimum values. Any deviation from the optimum values will lead to longer times or increased LN2 and electrical consumption for the proposed test plan. Computer code operating instructions and listings of sample input and output files have been included.

Mineck, Raymond E.↗

Continuation: The EOSDIS testbed data system

The continuation of the EOSDIS testbed ('Testbed') has materialized from a multi-task system to a fully functional stand-alone data archive distribution center that once was only X-Windows driven to a system that is accessible by all types of users and computers via the World Wide Web. Throughout the past months, the Testbed has evolved into a completely new system. The current system is now accessible through Netscape, Mosaic, and all other servers that can contact the World Wide Web. On October 1, 1995 we will open to the public and we expect that the statistics of the type of user, where they are located, and what they are looking for will drastically change. What is the most important change in the Testbed has been the Web interface. This interface will allow more users access to the system and walk them through the data types with more ease than before. All of the callbacks are written in such a way that icons can be used to easily move around in the programs interface. The homepage offers the user the opportunity to go and get more information about each satellite data type and also information on free programs. These programs are grouped into categories for types of computers that the programs are compiled for, along with information on how to FTP the programs back to the end users computer. The heart of the Testbed is still the acquisition of satellite data. From the Testbed homepage, the user selects the 'access to data system' icon, which will take them to the world map and allow them to select an area that they would like coverage on by simply clicking that area of the map. This creates a new map where other similar choices can be made to get the latitude and longitude of the region the satellite data will cover. Once a selection has been made the search parameters page will appear to be filled out. Afterwards, the browse image will be called for once the search is completed and the images for viewing can be selected. There are several other option pages, but once an order has been selected the Testbed will bring up the order list page and the user will then be able to place their order. After the order has been completed, the Testbed will mail the user to notify them of the completed order and how the images can be picked up.

Emery, Bill↗

Numerical derivative techniques for trajectory optimization

The adoption of robust numerical optimization techniques in trajectory simulation programs has resulted in powerful design and analysis tools. These trajectory simulation/optimization programs are widely used, and a representative list includes the GTS system, the POST program, and newer collocation methods such as OTIS and FONPAC. All of these programs rely on optimization algorithms which require objective function and constraint gradient data during the iteration process. However, most trajectory optimization problems lack simple analytical expressions for these derivatives. In the general case a function evaluation involves integrating aerodynamic, propulsive, and gravity forces over multiple trajectory phases with complex control models. With the newer collocation methods, the integration is replaced by defect constraints and cubic approximations for the state. While analytic gradient expressions can sometimes be derived for trajectory optimization problems, the derivation is cumbersome, time consuming, and prone to mistakes. Fortunately, an alternate method exists for the gradient evaluation, namely finite difference approximations. In this paper some finite difference gradient techniques developed for use with the GTS system are presented. These techniques include methods for computing first and second partial derivatives of single and multiple sets of functions. A key feature of these methods is an error control mechanism which automatically adjusts the perturbation size to obtain accurate derivative values.

Hallman, Wayne P.↗

Personal Computer Transport Analysis Program

The Personal Computer Transport Analysis Program (PCTAP) is C++ software used for analysis of thermal fluid systems. The program predicts thermal fluid system and component transients. The output consists of temperatures, flow rates, pressures, delta pressures, tank quantities, and gas quantities in the air, along with air scrubbing component performance. PCTAP s solution process assumes that the tubes in the system are well insulated so that only the heat transfer between fluid and tube wall and between adjacent tubes is modeled. The system described in the model file is broken down into its individual components; i.e., tubes, cold plates, heat exchangers, etc. A solution vector is built from the components and a flow is then simulated with fluid being transferred from one component to the next. The solution vector of components in the model file is built at the initiation of the run. This solution vector is simply a list of components in the order of their inlet dependency on other components. The component parameters are updated in the order in which they appear in the list at every time step. Once the solution vectors have been determined, PCTAP cycles through the components in the solution vector, executing their outlet function for each time-step increment.

DiStefano, Frank, III↗

Deploying and Tracking Software with NCCS Software Provisioning

The National Center for Computational Sciences (NCCS) at Oak Ridge National Laboratory has a long history of deploying ground-breaking leadership-class supercomputers for the U.S. Department of Energy. The latest in this line of supercomputers is Frontier, the first supercomputer to break the exascale barrier (1018 floating-point operations per second) on the TOP500 list. Frontier serves a wide array of scientific domains, from traditional simulation-based workloads to newer AI and Machine Learning workloads. To best serve the NCCS user community, NCCS uses Spack to deploy a comprehensive software stack of scientific software packages, providing straightforward access to these packages through Lmod Environment Modules. Maintaining a large software stack while also including multiple new compiler releases each year is a very time-consuming task. Additionally, it is not straightforward to provide a software stack alongside existing vendor-provided software such as the HPE/Cray Programming Environment (CPE), and existing CPE, Spack, and Lmod integration does not allow for multiple versions of GPU libraries such as AMD’s ROCm to be used. To address these challenges and shortcomings, NCCS has developed the NCCS Software Provisioning tool (NSP)1, a tool for deploying and monitoring software stacks on HPC systems. NSP allows NCCS to quickly and effectively provision software stacks from the ground up using template-driven recipes and configuration files. NSP is successfully deployed on Frontier and several other NCCS clusters, enabling the NCCS software team to quickly deploy software stacks for newly-released compilers, expand current software offerings, better support GPU-based software, and monitor Lmod module usage to identify unused software packages that can be removed from the software stack. In this work, we discuss the shortcomings of the previous CPE, Spack, and Lmod usage at NCCS, provide further details on the implementation and structure of NSP, then discuss the benefits that NSP provides.

Rentschler, Asa [ORNL] (ORCID:0009000597694743)↗

A computer program to calculate the longitudinal aerodynamic characteristics of upper-surface-blown wing-flap configurations

A user's manual is presented for a computer program in which a vortex-lattice lifting-surface method is used to model the wing and multiple flaps. The engine wake model consists of a series of closely spaced vortex rings with rectangular cross sections. The jet wake is positioned such that the lower boundary of the jet is tangent to the wing and flap upper surfaces. The two potential flow models are used to calculate the wing-flap loading distribution including the influence of the wakes from up to two engines on the semispan. The method is limited to the condition where the flow and geometry of the configurations are symmetric about the vertical plane containing the wing root chord. The results include total configuration forces and moments, individual lifting-surface load distributions, pressure distributions, flap hinge moments, and flow field calculation at arbitrary field points. The use of the program, preparation of input, the output, program listing, and sample cases are described.

Mendenhall, M. R.↗

Parallel VLSI architecture emulation and the organization of APSA/MPP

The Applicative Programming System Architecture (APSA) combines an applicative language interpreter with a novel parallel computer architecture that is well suited for Very Large Scale Integration (VLSI) implementation. The Massively Parallel Processor (MPP) can simulate VLSI circuits by allocating one processing element in its square array to an area on a square VLSI chip. As long as there are not too many long data paths, the MPP can simulate a VLSI clock cycle very rapidly. The APSA circuit contains a binary tree with a few long paths and many short ones. A skewed H-tree layout allows every processing element to simulate a leaf cell and up to four tree nodes, with no loss in parallelism. Emulation of a key APSA algorithm on the MPP resulted in performance 16,000 times faster than a Vax. This speed will make it possible for the APSA language interpreter to run fast enough to support research in parallel list processing algorithms.

Odonnell, John T.↗

User's Manual for LEWICE Version 3.2

A research project is underway at NASA Glenn to produce a computer code which can accurately predict ice growth under a wide range of meteorological conditions for any aircraft surface. This report will present a description of the code inputs and outputs from version 3.2 of this software, which is called LEWICE. This version differs from release 2.0 due to the addition of advanced thermal analysis capabilities for de-icing and anti-icing applications using electrothermal heaters or bleed air applications, the addition of automated Navier-Stokes analysis, an empirical model for supercooled large droplets (SLD) and a pneumatic boot option. An extensive effort was also undertaken to compare the results against the database of electrothermal results which have been generated in the NASA Glenn Icing Research Tunnel (IRT) as was performed for the validation effort for version 2.0. This report will primarily describe the features of the software related to the use of the program. Appendix A has been included to list some of the inner workings of the software or the physical models used. This information is also available in the form of several unpublished documents internal to NASA. This report is intended as a replacement for all previous user manuals of LEWICE. In addition to describing the changes and improvements made for this version, information from previous manuals may be duplicated so that the user will not need to consult previous manuals to use this software.

Wright, William↗

40 Years of Processing Pieces of Space

This year marks the 40th year anniversary for the Antarctic Search for Meteorite (ANSMET) program. In 1976, the ANSMET program led the first expedition to Antarctica. The ANSMET program is a US-led field-based science project that recovers meteorite samples from Antarctica. Once a year from late November to late January, a field team consisting of 8 to 12 people, spends 6-8 weeks camping on the ice and collecting meteorites. Since 1976, more than 22,000 meteorite samples have been recovered. These meteorites come from asteroids, planets and other bodies of the solar system. Once collected, the Antarctic meteorites are shipped to NASA/Johnson Space Center (JSC) Houston, TX. in a refrigerated truck and are kept frozen to minimize oxidation until they are ready for initial processing. In Antarctica each meteorite is given a field tag which consists of numbers, once in the lab, this is replaced by an official tag, consisting of the Antarctic field location and year collected. The types and numbers of meteorites that have been classified include 849 carbonaceous chondrites, 135 enstatites, 512 achondrites, 64 stony, 115 irons, 48 others (27 R chondrites, 7 ungrouped), 6,161 H chondrites, 7,668 L chondrites, and 4,589 LL chondrites. Although 80-85 percent of the collected meteorites fall in the ordinary chondrite group, the other approximately 15 percent represent rare types of achondrites and carbonaceous chondrites. These rare meteorites include 25 lunar meteorites, 15 Martian meteorites, scores of various types of carbonaceous chondrites, and unique achondrites. The Antarctic meteorites that have been collected are processed in the Meteorite Processing Lab at JSC in Houston, TX. Initial processing of the meteorites begins with thawing/drying the meteorites in a nitrogen glove box for 24 to 48 hours. The meteorites are then photographed, measured, weighed and a description of the interior and exterior of each meteorite is written. The meteorite is broken and a representative sample, either a 1-3 gram chip or thin section is sent to the Smithsonian Institution for classification. After Antarctic meteorites have been classified and approved by the Nomenclature Committee of the Meteoritical Society, they are announced in the Antarctic Meteorite Newsletter, which is published twice per year (fall and spring) so that scientists may review which meteorites are available to study. Requests for Antarctic Meteorite samples are welcomed from research scientists, regardless of their current state of funding for meteorite studies. Since its inception over 3,300 requests have been made for pieces of these meteorites and over 400 investigators worldwide are active in the study of meteorites.. Research on these samples has been published in more than1500 peer reviewed articles; a listing of papers for any meteorite sample can be generated by accessing http://curator.jsc.nasa.gov/antmet/referencesearch.cfm. Antarctic meteorite samples requested by scientists are prepared several different ways. Most samples are prepared as chips, either using a rock splitter or using a chisel and chipping bowl. In special situations, a researcher may request a meteorite slab in which case the samples are cut using a diamond-bladed bandsaw inside of a dry nitrogen glove box. The meteorites are always cut in a 100 percent liquid-free environment. Additionally, thin/thick sections of Antarctic meteorites are also prepared at JSC. The meteorite thin section lab at JSC can prepare standard 30-micron thin sections, thick sections of variable thickness (100 to 200 microns), or demountable sections using superglue, all section are prepared without using water. Although many of the techniques used back in the '70's are still used today, advances in computers, software, databases, available tools and instrumentation have helped to streamline and shorten the duration of the classification process. In conjunction with present day missions to asteroids and other planets, meteorite studies have not only led to a better understanding of the complex histories of these bodies but have also tied certain meteorite groups to particular asteroid bodies. New meteorite discoveries by the ANSMET program provide a cost effective method for obtaining samples of previously unsampled bodies, allowing scientists to learn more about the origin, composition, and evolution of the solar system. Preservation in our cleanrooms at NASA allows material to be archived for future generations and advances in instrumentation and analysis.

Satterwhite, C. E.↗

Lessons Learned Using COTS Electronics for the International Space Station Radiation Environment

The mantra of 'Faster, Better, Cheaper' has to a large degree been interpreted as using Commercial Off-the-Shelf (COTS) components and/or circuit boards. One of the first space applications to actually use COTS in space along with radiation performance requirements was the Expedite the Processing of Experiments to Space Station (EXPRESS) Rack program, for the International Space Station (ISS). In order to meet the performance, cost and schedule targets, military grade Versa Module Eurocard (VME) was selected as the baseline design for the main computer, the Rack Interface Controller (RIC). VME was chosen as the computer backplane because of the large variety of military grade boards available, which were designed to meet the military environmental specifications (thermal, shock, vibration, etc.). These boards also have a paper pedigree in regards to components. Since these boards exceeded most ISS environmental requirements, it was reasoned using COTS mid-grade VME boards, as opposed to designing custom boards could save significant time and money. It was recognized up front the radiation environment of ISS, while benign compared to many space flight applications, would be the main challenge to using COTS. Thus in addition to selecting vendors on how well their boards met the usual performance and environmental specifications, the board's parts lists were reviewed on how well they would perform in the ISS radiation environment. However, issues with verifying that the available radiation test data was applicable to the actual part used, vendor part design changes and the fact most parts did not have valid test data soon complicated board and part selection in regards to radiation.

Blumer, John H.↗

The Automated Instrumentation and Monitoring System (AIMS): Design and Architecture

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 such information can help computer and software architects to capture, and therefore, exploit behavioral variations among/within various parallel programs to take advantage of specific hardware characteristics. A software tool-set that facilitates performance evaluation of parallel applications on multiprocessors has been put together at NASA Ames Research Center under the sponsorship of NASA's High Performance Computing and Communications Program over the past five years. The Automated Instrumentation and Monitoring Systematic has three major software components: a source code instrumentor which automatically inserts active event recorders into program source code before compilation; a run-time performance monitoring library which collects performance data; and a visualization tool-set which reconstructs program execution based on the data collected. Besides being used as a prototype for developing new techniques for instrumenting, monitoring and presenting parallel program execution, AIMS is also being incorporated into the run-time environments of various hardware testbeds to evaluate their impact on user productivity. Currently, the execution of FORTRAN and C programs on the Intel Paragon and PALM workstations can be automatically instrumented and monitored. Performance data thus collected can be displayed graphically on various workstations. The process of performance tuning with AIMS will be illustrated using various NAB Parallel Benchmarks. This report includes a description of the internal architecture of AIMS and a listing of the source code.

Yan, Jerry C.↗

Program for User-Friendly Management of Input and Output Data Sets

A computer program manages large, hierarchical sets of input and output (I/O) parameters (typically, sequences of alphanumeric data) involved in computational simulations in a variety of technological disciplines. This program represents sets of parameters as structures coded in object-oriented but otherwise standard American National Standards Institute C language. Each structure contains a group of I/O parameters that make sense as a unit in the simulation program with which this program is used. The addition of options and/or elements to sets of parameters amounts to the addition of new elements to data structures. By association of child data generated in response to a particular user input, a hierarchical ordering of input parameters can be achieved. Associated with child data structures are the creation and description mechanisms within the parent data structures. Child data structures can spawn further child data structures. In this program, the creation and representation of a sequence of data structures is effected by one line of code that looks for children of a sequence of structures until there are no more children to be found. A linked list of structures is created dynamically and is completely represented in the data structures themselves. Such hierarchical data presentation can guide users through otherwise complex setup procedures and it can be integrated within a variety of graphical representations.

Klimeck, Gerhard↗

SSME HPOTP post-test diagnostic system enhancement project

An assessment of engine and component health is routinely made after each test or flight firing of a space shuttle main engine (SSME). Currently, this health assessment is done by teams of engineers who manually review sensor data, performance data, and engine and component operating histories. Based on review of information from these various sources, an evaluation is made as to the health of each component of the SSME and the preparedness of the engine for another test or flight. The objective of this project is to further develop a computer program which automates the analysis of test data from the SSME high-pressure oxidizer turbopump (HPOTP) in order to detect and diagnose anomalies. This program fits into a larger system, the SSME Post-Test Diagnostic System (PTDS), which will eventually be extended to assess the health and status of most SSME components on the basis of test data analysis. The HPOTP module is an expert system, which uses 'rules-of-thumb' obtained from interviews with experts from NASA Marshall Space Flight Center (MSFC) to detect and diagnose anomalies. Analyses of the raw test data are first performed using pattern recognition techniques which result in features such as spikes, shifts, peaks, and drifts being detected and written to a database. The HPOTP module then looks for combination of these features which are indicative of known anomalies, using the rules gathered from the turbomachinery experts. Results of this analysis are then displayed via a graphical user interface which provides ranked lists of anomalies and observations by engine component, along with supporting data plots for each.

Bickmore, Timothy W.↗

1996 Coolant Flow Management Workshop

The following compilation of documents includes a list of the 66 attendees, a copy of the viewgraphs presented, and a summary of the discussions held after each session at the 1996 Coolant Flow Management Workshop held at the Ohio Aerospace Institute, adjacent to the NASA Lewis Research Center, Cleveland, Ohio on December 12-13, 1996. The workshop was organized by H. Joseph Gladden and Steven A. Hippensteele of NASA Lewis Research Center. Participants in this workshop included Coolant Flow Management team members from NASA Lewis, their support service contractors, the turbine engine companies, and the universities. The participants were involved with research projects, contracts and grants relating to: (1) details of turbine internal passages, (2) computational film cooling capabilities, and (3) the effects of heat transfer on both sides. The purpose of the workshop was to assemble the team members, along with others who work in gas turbine cooling research, to discuss needed research and recommend approaches that can be incorporated into the Center's Coolant Flow Management program. The workshop was divided into three sessions: (1) Internal Coolant Passage Presentations, (2) Film Cooling Presentations, and (3) Coolant Flow Integration and Optimization. Following each session there was a group discussion period.

Steven A. Hippensteele↗

Towards a Standard for Provenance and Context for Preservation of Data for Earth System Science

Long-term data sets with data from many missions are needed to study trends and validate model results that are typical in Earth System Science research. Data and derived products originate from multiple missions (spaceborne, airborne and/or in situ) and from multiple organizations. During the missions as well as well past their termination, it is essential to preserve the data and products to support future studies. Key aspects of preservation are: preserving bits and ensuring data are uncorrupted, preserving understandability with appropriate documentation, and preserving reproducibility of science with appropriate documentation and other artifacts. Computer technology provides adequate standards to ensure that, with proper engineering, bits are preserved as hardware evolves. However, to ensure understandability and reproducibility, it is essential to plan ahead to preserve all the relevant data and information. There are currently no standards to identify the content that needs to be preserved, leading to non-uniformity in content and users not being sure of whether preserved content is comprehensive. Each project, program or agency can specify the items to be preserved as a part of its data management requirements. However, broader community consensus that cuts across organizational or national boundaries would be needed to ensure comprehensiveness, uniformity and long-term utility of archived data. The Federation of Earth Science Information Partners (ESIP), a diverse network of scientists, data stewards and technology developers, has a forum for ESIP members to collaborate on data preservation issues. During early 2011, members discussed the importance of developing a Provenance and Context Content Standard (PCCS) and developed an initial list of content items. This list is based on the outcome of a NASA and NOAA meeting held in 1998 under the auspices of the USGCRP, documentation requirements from NOAA and our experience with some of the NASA Earth science missions. The items are categorized into the following 8 high level categories: Preflight/Pre-Operations, Products (Data), Product Documentation, Mission Calibration, Product Software, Algorithm Input, Validation, Software Tools.

Ramaprian, Hampapuram K.↗

Support Routines for In Situ Image Processing

This software consists of a set of application programs that support ground-based image processing for in situ missions. These programs represent a collection of utility routines that perform miscellaneous functions in the context of the ground data system. Each one fulfills some specific need as determined via operational experience. The most unique aspect to these programs is that they are integrated into the large, in situ image processing system via the PIG (Planetary Image Geometry) library. They work directly with space in situ data, understanding the appropriate image meta-data fields and updating them properly. The programs themselves are completely multimission; all mission dependencies are handled by PIG. This suite of programs consists of: (1)marscahv: Generates a linearized, epi-polar aligned image given a stereo pair of images. These images are optimized for 1-D stereo correlations, (2) marscheckcm: Compares the camera model in an image label with one derived via kinematics modeling on the ground, (3) marschkovl: Checks the overlaps between a list of images in order to determine which might be stereo pairs. This is useful for non-traditional stereo images like long-baseline or those from an articulating arm camera, (4) marscoordtrans: Translates mosaic coordinates from one form into another, (5) marsdispcompare: Checks a Left Right stereo disparity image against a Right Left disparity image to ensure they are consistent with each other, (6) marsdispwarp: Takes one image of a stereo pair and warps it through a disparity map to create a synthetic opposite- eye image. For example, a right eye image could be transformed to look like it was taken from the left eye via this program, (7) marsfidfinder: Finds fiducial markers in an image by projecting their approximate location and then using correlation to locate the markers to subpixel accuracy. These fiducial markets are small targets attached to the spacecraft surface. This helps verify, or improve, the pointing of in situ cameras, (8) marsinvrange: Inverse of marsrange . given a range file, re-computes an XYZ file that closely matches the original. . marsproj: Projects an XYZ coordinate through the camera model, and reports the line/sample coordinates of the point in the image, (9) marsprojfid: Given the output of marsfidfinder, projects the XYZ locations and compares them to the found locations, creating a report showing the fiducial errors in each image. marsrad: Radiometrically corrects an image, (10) marsrelabel: Updates coordinate system or camera model labels in an image, (11) marstiexyz: Given a stereo pair, allows the user to interactively pick a point in each image and reports the XYZ value corresponding to that pair of locations. marsunmosaic: Extracts a single frame from a mosaic, which will be created such that it could have been an input to the original mosaic. Useful for creating simulated input frames using different camera models than the original mosaic used, and (12) merinverter: Uses an inverse lookup table to convert 8-bit telemetered data to its 12-bit original form. Can be used in other missions despite the name.

Deen, Robert G.↗

Computer programs for calculating the static longitudinal aerodynamic characteristics of wing-body-tail configurations

Four computer programs developed to calculate the longitudinal aerodynamic characteristics of wing-body and wing-body-tail combinations are presented. The R1307 program is based on a linear method and is limited to the small range of angles of attack for which the lift and moment characteristics of wings and bodies are linear with angle of attack. The CRSFLW program is based on a crossflow method of predicting the forces and moments on bodies alone or wing-body combinations over a large angle of attack range. The SUBSON program predicts the longitudinal aerodynamic characteristics of wing-body-tail combinations at subsonic speeds and at angles of attack for which symmetrical pairs of vortices are shed from the body nose and the leading and side edges of the lifting surfaces. Program SUPSON predicts the longitudinal aerodynamic characteristics of wing-body-tail combinations at supersonic speeds in the same angle-of-attack range. A description of the use of each program, instructions for preparation of input, a description of the output, program listings, and sample cases for each program are included.

Mendenhall, M. R.↗

A Python Tool for Reconstructing MCNP6 Particle Histories from an HDF5 PTRAC File [Slides]

A Python tool for converting the MCNP6 HDF5 PTRAC file to a list of Python trees is presented. The particle trees store MCNP6 simulated events for each history using parent-child relationships, which ensures that branching processes are accurately reproduced. A variety of post-processing scripts are presented and used in conjunction with the Python particle trees to make special tallies that are currently not available in the MCNP6 software and visualize the particle tracks.

97 MATHEMATICS AND COMPUTING↗