Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “programming language”

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 469 records · Page 26
All sourcesNASA NTRSDOE OSTI
NASA NTRS1986

Implementation of and Ada real-time executive: A case study

Current Ada language implementations and runtime environments are immature, unproven and are a key risk area for real-time embedded computer system (ECS). A test-case environment is provided in which the concerns of the real-time, ECS community are addressed. A priority driven executive is selected to be implemented in the Ada programming language. The model selected is representative of real-time executives tailored for embedded systems used missile, spacecraft, and avionics applications. An Ada-based design methodology is utilized, and two designs are considered. The first of these designs requires the use of vendor supplied runtime and tasking support. An alternative high-level design is also considered for an implementation requiring no vendor supplied runtime or tasking support. The former approach is carried through to implementation.

Laird, James D.↗
NASA NTRS1999

Java PathFinder: A Translator From Java to Promela

JAVA PATHFINDER, JPF, is a prototype translator from JAVA to PROMELA, the modeling language of the SPIN model checker. JPF is a product of a major effort by the Automated Software Engineering group at NASA Ames to make model checking technology part of the software process. Experience has shown that severe bugs can be found in final code using this technique, and that automated translation from a programming language to a modeling language like PROMELA can help reducing the effort required.

Havelund, Klaus↗
DOE OSTI2014

Why scientists should learn to program in Python

Scientists have been central to the historical development of the computer industry, but the importance of software only continues to grow for all areas of scientific research and in particular for powder diffraction. Knowing how to program a computer is a basic and useful skill for scientists. The article introduces the three types of programming languages and why scripting languages are now preferred for scientists. Of them, the authors assert Python is the most useful and easiest to learn. Python is introduced. Also presented is an overview to a few of the many add-on packages available to extend the capabilities of Python, for example, for numerical computations, scientific graphics and graphical user interface programming.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

Common Electric Power Transmission System Model JSON Schema Specification

The Common Electric Power Transmission System Model (CTM) is an intuitive, extensible, language-agnostic, and error-resistant specification of electric power network components parameter names and units, and relation between components, intended for use by the research community developing new computational methods for power systems operations and simulation. Power system datasets following the CTM specification can be read as dictionaries and manipulated in that form in most programming languages (e.g., Python, Julia, C++). This standard data structure in CTM makes it easy to work in multiple power systems domains (e.g., economic operation, reliability assessment, electricity markets, stability assessment, etc.) without requiring conversions between use-case-specific file formats with information loss in the process. This repository specifies CTM as a JSON Schema, provides documentation, derivate (code-generated) implementations of CTM, and example data and usage of the schema for important use cases.

Aravena Solis, Ignacio↗
DOE OSTI2026

Digitizing Today’s Buildings in the Real World: Lessons from Field Demonstrations

Digital twins, created by generating a virtual replica of a building, enable safe evaluation of operational scenarios and applications like fault detection and diagnosis and advanced controls. However, a prerequisite is the creation of a machine-readable digital representation of a building, currently hindered by fragmented information scattered across mechanical drawings, point lists, and natural language sequences. As a result, digital twin development remains labor-intensive, error-prone, and difficult to validate. To address these challenges, two efforts from ASHRAE aim to support the digitalization of buildings. ASHRAE s223 establishes a semantic model of buildings, representing system components, configuration, and data sources. ASHRAE s231 defines a vendor-neutral programming language for expressing their control logic. As the industry evaluates implementing them in their products, understanding the challenges that vendors and implementers may face is crucial. In this paper, we present findings and lessons learned from field demonstrations in five buildings that implemented control applications using ASHRAE s223 and s231. The demonstrations highlight how semantic modeling and formalized control descriptions can significantly reduce software development time, manual point mapping, and hard-coding. Beyond time efficiency, they enable reliable automation by minimizing human interpretation and providing a means for consistency across projects. We describe the processes and best practices for model creation and model usage, from translating heterogeneous building documentation into semantic representations to implementing control logic in real-world systems. Finally, we discuss the challenges that persist, including integration with legacy software environments, gaps in interoperability, and the level of expertise still required to effectively leverage semantic models.

Prakash, Anand Krishnan↗
DOE OSTI2017

CUDA Computation of the Feynman Distribution

In 2006, NVIDIA Corporation introduced the Computer Unified Device Architecture (CUDA) for C, C++, and Fortran programming languages. The CUDA parallel computing platform uses the Graphics Processing Unit (GPU) of NVIDIA graphics card, and it is designed for parallel computations. In these computations, the same algorithms are executed on the data in parallel. The GPU contains many Streaming Multiprocessors (SM) that can independently execute blocks of threads. A thread is a sequence of serial programmed instructions. The SM executes threads in groups of 32 and a group of 32 threads is called warp. The threads within a block can be synchronized and have access to a shared memory that is visible only to them. Conversely, blocks of threads cannot be synchronized and have access only to the global memory of the graphics card. This memory is called device memory and is independent of the host memory controlled by the Central Processing Unit (CPU). A single thread has access to a local memory (register) that is not visible to any other thread. The part of the program that is executed on the graphics card is called kernel. Each thread of the kernel has a unique identification index that is accessible by the in-built variable threadIdx; the latter is a 3-component vector. A threads block can contain up to 1024 threads. Blocks of threads have a unique identification index that is accessible by the in-built variable blockIdx; the latter is a 3-component vector. The in-built variable blockDim contains the number of threads per block; this variable is a 3-component vector. Threads and blocks represent different levels of parallelism; a kernel is executed as a grid of blocks of threads. Figure 1 illustrates a grid of thread blocks for a GPU with 2 SM. A SM can execute multiple blocks of threads in parallel; a block of threads is executed on a single SM. A GPU can execute multiple kernels concurrently. This work has used the Quadro M5000 graphics card with the following technical specifications: - 2048 cores with 861 MHz frequency, - 16 streaming multiprocessors, - 5.2 trillion transistors, - 8.2 Gb device memory, - 64 kb register memory (per thread), - 48 kb shared memory (per block) - 211.6 GB/s memory bandwidth, and - 3.5 GFLOPS floating point performance.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2017

STARlight: A Monte Carlo simulation program for ultra-peripheral collisions of relativistic ions

© 2016 Elsevier B.V. Ultra-peripheral collisions (UPCs) have been a significant source of study at RHIC and the LHC. In these collisions, the two colliding nuclei interact electromagnetically, via two-photon or photonuclear interactions, but not hadronically; they effectively miss each other. Photonuclear interactions produce vector meson states or more general photonuclear final states, while two-photon interactions can produce lepton or meson pairs, or single mesons. In these interactions, the collision geometry plays a major role. We present a program, STARlight, that calculates the cross-sections for a variety of UPC final states and also creates, via Monte Carlo simulation, events for use in determining detector efficiency. Program summary Program Title: STARlight (v2.2) Program Files doi: http://dx.doi.org/10.17632/xjpf4rxtbj.1 Licensing provisions: GNU GPLv3 Programming Language: C++ External Routines: PYTHIA 8.2 and DPMJET 3.0 are needed for some final states. Nature of problem: The cross-section for ultra-peripheral collisions is obtained by integrating the photon fluxes in transverse impact parameter space, subject to the requirement (which is also impact parameter dependent) that the colliding nuclei do not interact hadronically. The program is a two step process. First, it calculates the cross-sections for the reaction of interest, as a function of W (photon–Pomeron or two-photon center of mass energy), Y (final state rapidity) and pT (final state transverse momentum). Second, STARlight generates Monte Carlo events which can be used to determine cross-sections within specific kinematic constraints or for studies of detector efficiencies. The second step includes the decay of any unstable particles produced in the reaction, with appropriate consideration of particle spins and parity. It outputs these events in ASCII format. Solution method: The program generates a two dimensional look-up table of the production cross-section as a function of final state rapidity and mass. The dimensions of the table are selectable, allowing the user to choose the desired accuracy. For certain final states, a second two-dimensional look-up table, giving the transverse momentum distribution, as a function of rapidity, is also used. With these look-up tables, the program generates final states. Particle decays and the final angular distributions are calculated for each event. Restrictions: The program is focused on ultra-relativistic collisions at Brookhaven's RHIC (Relativistic Heavy Ion Collider) and CERN's LHC (Large Hadron Collider), with final states that are visible in a central detector. At lower energies (i.e., at the CERN SPS), caution should be exercised because STARlight does not account for the longitudinal momentum transfer to the nucleus; this is larger at low beam energies. References: http://starlight.hepforge.org and references in this article.

71 CLASSICAL AND QUANTUM MECHANICS, GENERAL PHYSIC↗
DOE OSTI2017

Decision Analyses Related to Groundwater Remediation - 17051

Traditional decision analyses of groundwater remediation scenarios frequently fail because the probability of adverse, unanticipated events occurring is often high. This is driven by many factors including that (1) the models developed to represent the flow and transport in contaminated aquifers are typically simpler than reality and do not account for all the important governing processes, (2) probability distributions are assigned to critical performance parameters (such as model inputs or characteristics of the engineered remediation systems) even though some of these parameters might be unknown or not be very well constrained. However, there is a novel decision analysis methodology and a computational tool based on Bayesian Information-Gap Decision Theory (BIG-DT) that are designed to mitigate the shortcomings of the models and probabilistic decision analyses by leveraging a non-probabilistic decision theory -- information-gap decision theory. The new decision analysis methodology considers possible models that have not been explicitly enumerated and does not require us to commit to a particular probability distribution for model and remediation-design parameters. Both the set of possible models and the set of possible probability distributions grow as the degree of uncertainty increases. The fundamental question that BIG-DT asks is 'How large can these sets be before a particular decision results in an undesirable outcome?'. The decision that allows these sets to be the largest is considered to be the best option. In this way, BIG-DT enables robust decision-support for groundwater remediation problems. Here, we apply BIG-DT to a representative groundwater remediation scenario where different options for hydraulic containment and pump and treat are being considered. BIG-DT requires many model runs and high-performance computing resources are needed when complex models are used. We demonstrate the BIG-DT analyses on a series of synthetic problems that are designed to be consistent with real-world problems such as Los Alamos National Laboratory (LANL) contamination sites. We also discuss a general framework for how the BIG-DT analyses will be carried out at the chromium groundwater contamination site at LANL. BIG-DT is implemented in Julia (a high-level, high-performance dynamic programming language for technical computing) and is part of the MADS framework (http://mads.lanl.gov and http://madsjulia.github.io/Mads.jl). (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗
NASA NTRS1990

Investigation of air transportation technology at Princeton University, 1988-1989

The Air Transportation Technology Program at Princeton University, a program emphasizing graduate and undergraduate student research, proceeded along several avenues during the past year. A study of optimal trajectories for penetration of microbursts when encounter is unavoidable was conducted. The emphasis of current wind shear research is on developing an expert system for wind shear avoidance. A knowledge-based reconfigurable flight control system that is implemented with the Pascal programming language using parallel microprocessors was developed. This expert system could be considered a prototype for a failure-tolerant control system that can be constructed using existing hardware. Development of a real-time cockpit simulator continued during the year. The simulator provides a single-person crew station with both conventional and advanced control devices; it currently is programmed to simulate the Navion single-engine general aviation airplane. Alternatives for the air traffic control system giving particular attention to the institutional structure of the FAA are analyzed. A simple numerical procedure for estimating the stochastic robustness of control systems is being investigated. The revitalization of the general aviation industry is also discussed.

Stengel, Robert F.↗
NASA NTRS2011

Graphical Language for Data Processing

A graphical language for processing data allows processing elements to be connected with virtual wires that represent data flows between processing modules. The processing of complex data, such as lidar data, requires many different algorithms to be applied. The purpose of this innovation is to automate the processing of complex data, such as LIDAR, without the need for complex scripting and programming languages. The system consists of a set of user-interface components that allow the user to drag and drop various algorithmic and processing components onto a process graph. By working graphically, the user can completely visualize the process flow and create complex diagrams. This innovation supports the nesting of graphs, such that a graph can be included in another graph as a single step for processing. In addition to the user interface components, the system includes a set of .NET classes that represent the graph internally. These classes provide the internal system representation of the graphical user interface. The system includes a graph execution component that reads the internal representation of the graph (as described above) and executes that graph. The execution of the graph follows the interpreted model of execution in that each node is traversed and executed from the original internal representation. In addition, there are components that allow external code elements, such as algorithms, to be easily integrated into the system, thus making the system infinitely expandable.

Alphonso, Keith↗
NASA NTRS1977

VEEP - Vehicle Economy, Emissions, and Performance program

VEEP is a general-purpose discrete event simulation program being developed to study the performance, fuel economy, and exhaust emissions of a vehicle modeled as a collection of its separate components. It is written in SIMSCRIPT II.5. The purpose of this paper is to present the design methodology, describe the simulation model and its components, and summarize the preliminary results. Topics include chief programmer team concepts, the SDDL design language, program portability, user-oriented design, the program's user command syntax, the simulation procedure, and model validation.

Heimburger, D. A.↗
NASA NTRS1991

Computing Availability And Reliability For A System

Elements contributing most to failure of system identified quickly. Reliability/Availability Analysis (RELAV) computer program is comprehensive analytical software tool to determine reliability or availability of any general system modeled as embedded k-out-of-n groups of items (components) and/or subgroups. Used to assess performance of system during late testing phase of design of system, to model candidate designs and/or architectures, or to validate and form predictions during early phases of design. C-language program.

Bowerman, Paul N.↗
NASA NTRS2012

Spacecraft Avionics Software Development Then and Now: Different but the Same

NASA has always been in the business of balancing new technologies and techniques to achieve human space travel objectives. NASA s historic Software Production Facility (SPF) was developed to serve complex avionics software solutions during an era dominated by mainframes, tape drives, and lower level programming languages. These systems have proven themselves resilient enough to serve the Shuttle Orbiter Avionics life cycle for decades. The SPF and its predecessor the Software Development Lab (SDL) at NASA s Johnson Space Center (JSC) hosted flight software (FSW) engineering, development, simulation, and test. It was active from the beginning of Shuttle Orbiter development in 1972 through the end of the shuttle program in the summer of 2011 almost 40 years. NASA s Kedalion engineering analysis lab is on the forefront of validating and using many contemporary avionics HW/SW development and integration techniques, which represent new paradigms to NASA s heritage culture in avionics software engineering. Kedalion has validated many of the Orion project s HW/SW engineering techniques borrowed from the adjacent commercial aircraft avionics environment, inserting new techniques and skills into the Multi-Purpose Crew Vehicle (MPCV) Orion program. Using contemporary agile techniques, COTS products, early rapid prototyping, in-house expertise and tools, and customer collaboration, NASA has adopted a cost effective paradigm that is currently serving Orion effectively. This paper will explore and contrast differences in technology employed over the years of NASA s space program, due largely to technological advances in hardware and software systems, while acknowledging that the basic software engineering and integration paradigms share many similarities.

Mangieri, Mark L.↗
NASA NTRS2020

Connecting Users and Applications with Po.daac Hosted GHRSST Data

The 80+ GHRSST public datasets represent a rich resource for sea surface temperature research and applications given their time series length, resolution, spatial coverage, varying measurement types and processing levels, and availability in the full spectrum of PO.DAAC tools and services ecosystem. The PO.DAAC has created a publicly accessible recipe suite for the user community to perform straightforward yet powerful computations on GHRSST data using python recipes, Jupyter notebooks, R, Matlab, and the NCO programming language. These recipes include numerical computations for regional and global SST trends, anomaly derivations, EOF analysis, climate signal reproduction, and ocean phenology. For example, one recipe reproduces a famous SST based warming figure from the Fourth National Climate Assessment (USA) while another focuses on quantifying the regional changes in ocean SST phenology. Most are python-based while some contain hybrid calls and leverage the NCO programming interface too. All are available on the PO.DAAC user forum (https://podaac.jpl.nasa.gov/forum/) and/or via the open source NASA GitHub repository (https://github.com/nasa/podaac_tools_and_services). Several are available in the Jupyter notebook framework including podaacypy (https://github.com/nasa/podaacpy), a recipe for GHRSST granule metadata discovery and application, and more recently a Jupyter notebook developed to support data analysis and visualization of a cloud-based Zarr formatted Level 4 MUR dataset in the AWS Open Data Registry. Throughout the summer of 2020, the PO.DAAC intends to add and migrate more of its numerical recipes to the Jupyter notebook framework and publish them on its open source GitHub repository.

Gentemann, Chelle↗
DOE OSTI2021

Data From: Influence of Hydrological Perturbations and Riverbed Sediment Characteristics on Hyporheic Zone Respiration of CO2 and N-2, Journal of Geophysical Research-Biogeosciences

This data package contains pumping data (.txt), parameter matrices, and R code (.R, .RData) to perform bootstrapping for parameter selection for the bioclogging model development. The pumping data were collected from the Russian River Riverbank Filtration site located in Sonoma County, California from 2010-2017 from three riverbank collection wells located alongside the study site. The pumping data is directly correlated with water table oscillations, so the code performs these correlations and simulates stochastic versions of water table oscillations. See Metadata Description.pdf for full details on dataset production. This dataset must be used with the R programming language. This dataset and R code is associated with the publication "Influence of Hydrological Perturbations and Riverbed Sediment Characteristics on Hyporheic Zone Respiration of CO2 and N-2"This research was supported by the Jane Lewis Fellowship from the University of California, Berkeley, the Sonoma County Water Agency (SCWA), the Roy G. Post Foundation Scholarship, the U.S. Department of Energy, Office of Science Graduate Student Research (SCGSR) Program, U.S. Department of Energy, Office of Science, Office of Biological and Environmental Research under award DE-AC02-05CH11231, and the UFZ-Helmholtz Centre for Environmental Research, Leipzig, Germany.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS2000

A Visual Editor in Java for View

In this project we continued the development of a visual editor in the Java programming language to create screens on which to display real-time data. The data comes from the numerous systems monitoring the operation of the space shuttle while on the ground and in space, and from the many tests of subsystems. The data can be displayed on any computer platform running a Java-enabled World Wide Web (WWW) browser and connected to the Internet. Previously a special-purpose program bad been written to display data on emulations of character-based display screens used for many years at NASA. The goal now is to display bit-mapped screens created by a visual editor. We report here on the visual editor that creates the display screens. This project continues the work we bad done previously. Previously we had followed the design of the 'beanbox,' a prototype visual editor created by Sun Microsystems. We abandoned this approach and implemented a prototype using a more direct approach. In addition, our prototype is based on newly released Java 2 graphical user interface (GUI) libraries. The result has been a visually more appealing appearance and a more robust application.

Stansifer, Ryan↗
NASA NTRS2004

Microgravity Spray Cooling Research for High Powered Laser Applications

An extremely powerful laser is being developed at Goddard Space Flight Center for use on a satellite. This laser has several potential applications. One application is to use it for upper atmosphere weather research. In this case, the laser would reflect off aerosols in the upper atmosphere and bounce back to the satellite, where the aerosol velocities could be calculated and thus the upper atmosphere weather patterns could be monitored. A second application would be for the US. Air Force, which wants to use the laser strategically as a weapon for satellite defense. The Air Force fears that in the coming years as more and more nations gain limited space capabilities that American satellites may become targets, and the laser could protect the satellites. Regardless of the ultimate application, however, a critical step along the way to putting the laser in space is finding a way to efficiently cool it. While operating the laser becomes very hot and must be cooled to prevent overheating. On earth, this is accomplished by simply running cool tap water over the laser to keep it cool. But on a satellite, this is too inefficient. This would require too much water mass to be practical. Instead, we are investigating spray cooling as a means to cool the laser in microgravity. Spray cooling requires much less volume of fluid, and thus could be suitable for use on a satellite. We have inherited a 2.2 second Drop Tower rig to conduct our research with. In our experiments, water is pressurized with a compressed air tank and sprayed through a nozzle onto our test plate. We can vary the pressure applied to the water and the temperature of the plate before an experiment trial. The whole process takes place in simulated microgravity in the 2.2 second Drop Tower, and a high speed video camera records the spray as it hits the plate. We have made much progress in the past few weeks on these experiments. The rig originally did not have the capability to heat the test plate, but I did some heat transfer calculations and picked out a heater to order for the rig. I learned QBasic programming language to change the operating code for our drops, allowing us to rapidly cycle the spray nozzle open and closed to study the effects. We have derived an equation for flow rate vs. pressure for our experiment. We have recorded several videos of drops at different pressures, some with heated test plate and some without, and have noticed substantial differences in the liquid behavior. I have also changed the computer program to write a file with temperature vs. time profiles for the test plate, and once the necessary thermocouple comes in (it was ordered last week), we will have temperature profiles to accompany the videos. Once we have these temperature profiles to go with the videos, we will be able to see how the temperature is affected by the spray at different pressures, and how the spray changes its behavior once as the plate changes from hot to cool. With quantitative temperature data, we can then mathematically model the heat transfer from the plate to the cooling spray. Finally, we can look at the differences between trials in microgravity and those in normal earth gravity.

Zivich, Chad P.↗
NASA NTRS1990

A graphical language for reliability model generation

A graphical interface capability of the hybrid automated reliability predictor (HARP) is described. The graphics-oriented (GO) module provides the user with a graphical language for modeling system failure modes through the selection of various fault tree gates, including sequence dependency gates, or by a Markov chain. With this graphical input language, a fault tree becomes a convenient notation for describing a system. In accounting for any sequence dependencies, HARP converts the fault-tree notation to a complex stochastic process that is reduced to a Markov chain which it can then solve for system reliability. The graphics capability is available for use on an IBM-compatible PC, a Sun, and a VAX workstation. The GO module is written in the C programming language and uses the Graphical Kernel System (GKS) standard for graphics implementation. The PC, VAX, and Sun versions of the HARP GO module are currently in beta-testing.

Howell, Sandra V.↗