SEARCH · Engineering Papers

Results for “PYTHON”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 703 records · Page 39

All sources NASA NTRS DOE OSTI

DOE OSTI2023

Comparing the Performance of Julia on CPUs versus GPUs and Julia-MPI versus Fortran-MPI: a case study with MPAS-Ocean (Version 7.1)

Abstract. Some programming languages are easy to develop at the cost of slow execution, while others are fast at runtime but much more difficult to write. Julia is a programming language that aims to be the best of both worlds – a development and production language at the same time. To test Julia's utility in scientific high-performance computing (HPC), we built an unstructured-mesh shallow water model in Julia and compared it against an established Fortran-MPI ocean model, the Model for Prediction Across Scales–Ocean (MPAS-Ocean), as well as a Python shallow water code. Three versions of the Julia shallow water code were created: for single-core CPU, graphics processing unit (GPU), and Message Passing Interface (MPI) CPU clusters. Comparing identical simulations revealed that our first version of the Julia model was 13 times faster than Python using NumPy, where both used an unthreaded single-core CPU. Further Julia optimizations, including static typing and removing implicit memory allocations, provided an additional 10–20× speed-up of the single-core CPU Julia model. The GPU-accelerated Julia code was almost identical in terms of performance to the MPI parallelized code on 64 processes, an unexpected result for such different architectures. Parallelized Julia-MPI performance was identical to Fortran-MPI MPAS-Ocean for low processor counts and ranges from 2× faster to 2× slower for higher processor counts. Our experience is that Julia development is fast and convenient for prototyping but that Julia requires further investment and expertise to be competitive with compiled codes. We provide advice on Julia code optimization for HPC systems.

54 ENVIRONMENTAL SCIENCES↗

DOE OSTI2025

JHTDB-wind: a web-accessible large-eddy simulation database of a wind farm with virtual sensor querying

This paper introduces JHTDB-wind (https://turbulence.idies.jhu.edu/datasets/windfarms, last access: 11 November 2025), a publicly accessible database containing large-eddy simulation (LES) data from wind farms. Building on the framework of the Johns Hopkins Turbulence Database (JHTDB), which hosts direct numerical simulation (DNS) and some LES datasets of canonical turbulent flows, JHTDB-wind stores the 4D space–time history of the flow and provides users the ability to access and query the data via a web-based virtual sensor interface. The initial dataset comprises LES results from a large wind farm with 10×6 turbines, modeled using a filtered actuator line method, under conventionally neutral atmospheric conditions. These data comprise 1 h (hour) of flow field data (velocity, pressure, potential temperature deviation, subgrid-scale (SGS) eddy viscosity, and turbine forces, approximately 15 TB (terabytes) and wind turbine data – including both turbine-level operational quantities and blade-level aerodynamic quantities (approximately 1.3 TB) – stored in Zarr and Parquet formats, respectively. Data retrieval is facilitated by the giverny Python package, allowing remote users to query the database in Python or MATLAB (C and Fortran support are available for flow field data). This paper details the simulation setup and demonstrates data access through examples that analyze wind farm flow structures and turbine performance. The framework is extensible to future datasets, including the JHTDB-wind diurnal cycle simulation analyzed in Xiao et al. (2025).

17 WIND ENERGY↗

DOE OSTI2026

rustpix

rustpix is a high-performance, open-source Rust library with first-class Python bindings (via PyO3) for processing pixel-detector data in neutron imaging. It targets time-stamping detectors such as Timepix3 (TPX3) at ORNL's Spallation Neutron Source (VENUS beamline), where each detected neutron deposits charge across a cluster of pixels within a very high-rate event stream (96M+ hits/sec). rustpix parses TPX3 event data in parallel using memory-mapped I/O, offers four interchangeable clustering algorithms (ABS adjacency-based search, DBSCAN, graph/union-find connected components, and a parallel grid method), and extracts weighted, super-resolved centroids to produce neutron-event lists. A streaming architecture lets it process files larger than available memory. rustpix is distributed as a pip-installable Python package (with NumPy integration), Rust crates, a command-line tool, and an interactive GUI; it writes HDF5, Apache Arrow, and CSV; and it is designed to extend to TPX4 and other detector types. Released as open-source under the MIT License.

Zhang, Chen [Oak Ridge National Laboratory (ORNL),↗

DOE OSTI2023

A Method for Projecting Cloud Shadows Onto a Central Receiver Field to Predict Receiver Damage

This work demonstrates methods of mapping high-spatial-resolution direct normal irradiance (DNI) data from satellites, Total Sky Imagers (TSIs), and analogous data sources onto a heliostat field for characterizing the spatial and temporal variation of the incident flux on a central receiver tower during cloud transient events. The mapping methods are incorporated into an optical software module that interfaces with CoPylot–SolarPILOT’s python API– to provide computationally efficient optical simulation of the heliostat field and the solar power tower. Eventually, this optical model will be incorporated into optimization models whereby a plant operator can understand the effects of cloud transient events on overall power production and receiver lifetime due to creep-fatigue damage and therefore make better informed decisions about receiver shutdown events. By more accurately modelling the effects of cloud events on receiver flux maps, this work may determine the magnitude and frequency of thermal cycling on receiver tubes and panels using actual or realistic cloud shapes instead of averaged DNI values–which may undercount the total cycle number. This work may also prevent unnecessary plant shutdowns due to overly precautionary control strategies and characterize the relative impact of various cloud types on receiver life. We plan to eventually integrate this methodology into the System Advisor Model (SAM) to improve performance model accuracy during periods of cloudiness. In this paper, we demonstrate generating DNI maps and mapping them to a solar field in CoPylot using 10 m resolution data from publicly available Sentinel-2 satellite data over the Crescent Dunes plant.

Mullin, Matthew↗

DOE OSTI2024

Parallax-corrected VISST-derived pixel-level products from satellite GOES-16

The NASA Langley group led by William Smith produced GOES-16 satellite cloud retrievals over an approximate 10 by 10 degree region over the CACTI field campaign location. These retrievals are described here: https://www.arm.gov/capabilities/vaps/visst and are available for download here . They use algorithms historically called VISST that are now referred to as SatCORPS. More information can be found in Trepte et al. (2019), Minnis et al. (2021), and Yost et al. (2021). If using this dataset, please cite these references, the CACTI VISST dataset DOI found at the download link above, and this dataset’s DOI. The CACTI VISST pixel-level retrievals are on a 2 km spatial grid and available every 15 minutes (every 10 minutes late in the campaign), producing 21,765 files for the entire field campaign between October 2018 and April 2019. They are not corrected for parallax error, which is an offset in the actual geographical location of a cloud above the surface due to the satellite viewing the cloud partly from the side off nadir. This dataset applies a correction for parallax using the location relative to the satellite and the retrieved cloud top height above the surface, which allows the dataset to be geo-located with surface-based observations. The parallax correction for each location depends on the longitude, latitude and cloud top height above ground level (AGL) for that longitude and latitude in the original VISST files. The cloud top height AGL requires first computing the surface elevation at each VISST grid point. Data from the Advanced Spaceborne Thermal Emission and Reflection (ASTER) Global Digital Elevation Map Version 3 at 30-m resolution is projected onto the VISST grid using conservative coarsening (conserving surface elevation) in the xESMF Python package. The surface elevation is then subtracted from the VISST-retrieved cloud top height above mean sea level. These cloud top heights AGL are then combined with longitude and latitude to estimate the latitude and longitude corrections. Due to variability in cloud top height, the parallax shifts produce an irregular grid of values since higher cloud tops are shifted further than lower cloud tops. A ball tree-based neighbor search with Haversine distance is performed using the Python-based scikit-learn library to find the nearest VISST grid point to each parallax correction-shifted point. The data value of the shifted point is then assigned to that VISST grid point. In this manner, the irregular geographical shifts to correct for parallax are projected back to the rectilinear VISST grid. Because relatively higher clouds should obscure lower clouds, the variable values for the highest cloud top are preferentially chosen if two or more values are assigned to a grid point. The parallax correction should be viewed as an improved but still imperfect estimation of the cloud top locations, largely because the cloud top height is an imperfect retrieval. Please see the attached README document for further information. Users are encouraged to contact the authors with any additional questions.

54 ENVIRONMENTAL SCIENCES↗

DOE OSTI2025

Projected Urban Morphology of the Los Angeles Area by the Year 2100

This dataset provides projections of urban building morphologies for the Los Angeles urban area at 30-meter spatial resolution. It contains 192 raster files that detail two primary building attributes: building footprint fractions (ranging from 0 to 1) and average building heights (ranging from 0 to 75 meters). The projections account for a wide range of future pathways, covering two Shared Socioeconomic Pathway (SSP) scenarios (SSP3 and SSP5), two population scenarios, two developed land intensification scenarios, and four distinct levels of intensification. The dataset was created using dual Generative Adversarial Networks (GANs) trained on 2015 land cover and building properties from the National Land Cover Database (NLCD) and Model America datasets. Supporting information on the dataset has been described in the LAUrbanAreaMorphologyProjections2100_README.txt file.

Pandey, Bhartendu↗

DOE OSTI2020

DayCent data and results for "Robust paths to net greenhouse gas mitigation and negative emissions via advanced biofuels"

DayCent data and results for:J. L. Field, T. L. Richard, E. A. Smithwick, H. Cai, M. S. Laser, D. S. LeBauer, S. P. Long, K. Paustian, Z. Qin, J. J. Sheehan, P. Smith, M. Q. Wang, L. R. Lynd, Robust paths to net greenhouse gas mitigation and negative emissions via advanced biofuels. Proceedings of the National Academy of Sciences (2020). https://doi.org/10.1073/pnas.1920877117 This zip file contains a UNIX-format DayCent model executable, input files, automation code, and associated directory structure necessary to re-produce the DayCent analysis underlying the manuscript. The main script 'autodaycent.py' (written for Python 2.7) opens an interactive command line routine that facilitates:* Calibrating the DayCent pine growth model.* Initializing DayCent for a set of case studies sites.* Executing an ensemble of model runs representing case study site reforestation, grassland restoration, or conversion to switchgrass cultivation. * Results analysis & generation of manuscript Fig. 3. Note that the interactive analysis code requires that all input files to be contained in the directory structure as uploaded, without modification. Executable versions of the DayCent model (https://www.nrel.colostate.edu/projects/daycent/) compatible with other operating systems are available upon request.Please send questions/comments to John.L.Field@gmail.com

Agro-ecosystem function and prediction↗

NASA NTRS2006

Distributed Computing Framework for Synthetic Radar Application

We are developing an extensible software framework, in response to Air Force and NASA needs for distributed computing facilities for a variety of radar applications. The objective of this work is to develop a Python based software framework, that is the framework elements of the middleware that allows developers to control processing flow on a grid in a distributed computing environment. Framework architectures to date allow developers to connect processing functions together as interchangeable objects, thereby allowing a data flow graph to be devised for a specific problem to be solved. The Pyre framework, developed at the California Institute of Technology (Caltech), and now being used as the basis for next-generation radar processing at JPL, is a Python-based software framework. We have extended the Pyre framework to include new facilities to deploy processing components as services, including components that monitor and assess the state of the distributed network for eventual real-time control of grid resources.

synthetic aperture radar (SAR)↗

NASA NTRS2008

PyPele Rewritten To Use MPI

A computer program known as PyPele, originally written as a Pythonlanguage extension module of a C++ language program, has been rewritten in pure Python language. The original version of PyPele dispatches and coordinates parallel-processing tasks on cluster computers and provides a conceptual framework for spacecraft-mission- design and -analysis software tools to run in an embarrassingly parallel mode. The original version of PyPele uses SSH (Secure Shell a set of standards and an associated network protocol for establishing a secure channel between a local and a remote computer) to coordinate parallel processing. Instead of SSH, the present Python version of PyPele uses Message Passing Interface (MPI) [an unofficial de-facto standard language-independent application programming interface for message- passing on a parallel computer] while keeping the same user interface. The use of MPI instead of SSH and the preservation of the original PyPele user interface make it possible for parallel application programs written previously for the original version of PyPele to run on MPI-based cluster computers. As a result, engineers using the previously written application programs can take advantage of embarrassing parallelism without need to rewrite those programs.

Hockney, George↗

NASA NTRS2007

Computational Workbench for Multibody Dynamics

PyCraft is a computer program that provides an interactive, workbenchlike computing environment for developing and testing algorithms for multibody dynamics. Examples of multibody dynamic systems amenable to analysis with the help of PyCraft include land vehicles, spacecraft, robots, and molecular models. PyCraft is based on the Spatial-Operator- Algebra (SOA) formulation for multibody dynamics. The SOA operators enable construction of simple and compact representations of complex multibody dynamical equations. Within the Py-Craft computational workbench, users can, essentially, use the high-level SOA operator notation to represent the variety of dynamical quantities and algorithms and to perform computations interactively. PyCraft provides a Python-language interface to underlying C++ code. Working with SOA concepts, a user can create and manipulate Python-level operator classes in order to implement and evaluate new dynamical quantities and algorithms. During use of PyCraft, virtually all SOA-based algorithms are available for computational experiments.

Edmonds, Karina↗

NASA NTRS2007

Information Metacatalog for a Grid

SWIM is a Software Information Metacatalog that gathers detailed information about the software components and packages installed on a grid resource. Information is currently gathered for Executable and Linking Format (ELF) executables and shared libraries, Java classes, shell scripts, and Perl and Python modules. SWIM is built on top of the POUR framework, which is described in the preceding article. SWIM consists of a set of Perl modules for extracting software information from a system, an XML schema defining the format of data that can be added by users, and a POUR XML configuration file that describes how these elements are used to generate periodic, on-demand, and user-specified information. Periodic software information is derived mainly from the package managers used on each system. SWIM collects information from native package managers in FreeBSD, Solaris, and IRX as well as the RPM, Perl, and Python package managers on multiple platforms. Because not all software is available, or installed in package form, SWIM also crawls the set of relevant paths from the File System Hierarchy Standard that defines the standard file system structure used by all major UNIX distributions. Using these two techniques, the vast majority of software installed on a system can be located. SWIM computes the same information gathered by the periodic routines for specific files on specific hosts, and locates software on a system given only its name and type.

Kolano, Paul↗

NASA NTRS2006

Simulating Responses of Gravitational-Wave Instrumentation

Synthetic LISA is a computer program for simulating the responses of the instrumentation of the NASA/ESA Laser Interferometer Space Antenna (LISA) mission, the purpose of which is to detect and study gravitational waves. Synthetic LISA generates synthetic time series of the LISA fundamental noises, as filtered through all the time-delay-interferometry (TDI) observables. (TDI is a method of canceling phase noise in temporally varying unequal-arm interferometers.) Synthetic LISA provides a streamlined module to compute the TDI responses to gravitational waves, according to a full model of TDI (including the motion of the LISA array and the temporal and directional dependence of the arm lengths). Synthetic LISA is written in the C++ programming language as a modular package that accommodates the addition of code for specific gravitational wave sources or for new noise models. In addition, time series for waves and noises can be easily loaded from disk storage or electronic memory. The package includes a Python-language interface for easy, interactive steering and scripting. Through Python, Synthetic LISA can read and write data files in Flexible Image Transport System (FITS), which is a commonly used astronomical data format.

Armstrong, John↗

NASA NTRS2011

Multidisciplinary Tool for Systems Analysis of Planetary Entry, Descent, and Landing

Systems analysis of a planetary entry (SAPE), descent, and landing (EDL) is a multidisciplinary activity in nature. SAPE improves the performance of the systems analysis team by automating and streamlining the process, and this improvement can reduce the errors that stem from manual data transfer among discipline experts. SAPE is a multidisciplinary tool for systems analysis of planetary EDL for Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune, and Titan. It performs EDL systems analysis for any planet, operates cross-platform (i.e., Windows, Mac, and Linux operating systems), uses existing software components and open-source software to avoid software licensing issues, performs low-fidelity systems analysis in one hour on a computer that is comparable to an average laptop, and keeps discipline experts in the analysis loop. SAPE uses Python, a platform-independent, open-source language, for integration and for the user interface. Development has relied heavily on the object-oriented programming capabilities that are available in Python. Modules are provided to interface with commercial and government off-the-shelf software components (e.g., thermal protection systems and finite-element analysis). SAPE currently includes the following analysis modules: geometry, trajectory, aerodynamics, aerothermal, thermal protection system, and interface for structural sizing.

Samareh, Jamshid A.↗

NASA NTRS2017

Automated Sensitivity Analysis of Interplanetary Trajectories for Optimal Mission Design

This work describes a suite of Python tools known as the Python EMTG Automated Trade Study Application (PEATSA). PEATSA was written to automate the operation of trajectory optimization software, simplify the process of performing sensitivity analysis, and was ultimately found to out-perform a human trajectory designer in unexpected ways. These benefits will be discussed and demonstrated on sample mission designs.

trajectory design↗

NASA NTRS2017

Abstract - Belbas, Nicholas (EC2)

Originally, I was brought into the Design and Analysis Branch in the Crew and Thermal Systems to work on administrative tasks like archiving and scheduling. However, I ended up splitting my time between secretarial tasks and a technical project. My technical project was originally meant to be a wireless sensor package for the 20ft Spacecraft Thermal Vacuum Chamber in the B7 High Bay. I would be using a miniature wifi development board and a temperature/humidity sensor along with custom 3D modeling to accomplish this. However, after some discussion with my technical mentor, the plan was changed to a mobile autonomous self-charging sensor platform. A mobile platform will allow the sensors to be moved around without depressurizing the chamber. Also, the self-charging aspect of the package allows for almost unlimited time in the chamber. If the on-board battery runs low, the robot can easily be driven to its charging dock and continue to transmit while charging. The driving base is based around a Raspberry Pi 3 board with a 12C PMW DC Motor controller and a PWM controller driving two small gear motors. The sensor transmitter itself is a RHT03 temperature and humidity sensor and Cozir CO2 sensor connected to an ESP8266 Huzzah board. The power distribution system utilizes a pair of 3.7v 3600mah lipo batteries wired to Powerboost 500 boards. Also, the self-charging mechanism utilizes two 12v-max inductive charging coils wired into the same Powerboost boards as the battery. The Raspberry pi is running Python 3.3 for the driving base and Javascript MJPEG library for transmitting live video from the onboard camera. The sensor package is running Arduino-based C++ and the program capturing the data is running PyqtGraph Python and HTML. The shell of the robot itself is a 3D printed case that will (work in progress) snap together. The photo to the left shows the two halves separated from each other. The black shell contains the power distribution boards and connectors while the white shell contains the driving base and data systems.

Belbas, Nicholas↗

NASA NTRS2017

Automated Sensitivity Analysis of Interplanetary Trajectories

trajectory design↗

NASA NTRS2017

Finite Element Modeling and Analysis of Mars Entry Aeroshell Baseline Concept

The structure that is developed and analyzed in this project must be able to survive all the various load conditions that it will encounter along its course to Mars with the minimal amount of weight and material. At this stage, the goal is to study the capability of the structure using a finite element model (FEM). This FEM is created using a python script, and is numerically solved in Nastran. The purpose of the model is to achieve an optimization of mass given specific constraints on launch and entry. The generation and analysis of the baseline Rigid Mid-Range Lift to Drag Ratio Aeroshell model is a continuation and an improvement on previous work done for the FEM. The model is generated using Python programming with the axisymmetric placement of nodes for beam and shell elements. The shells are assigned a honeycomb sandwich material with an aluminum honeycomb core and composite face sheets, and the beams are assigned the same material as the shell face sheets. There are two load cases assigned to the model: Earth launch and Mars entry. The Earth launch case consists of pressure, gravity, and vibration loads, and the Mars entry case consists of just pressure and gravity loads. The Earth launch case was determined to be the driving case, though the analyses are performed for both cases to ensure the constraints are satisfied. The types of analysis performed with the model are design optimization, statics, buckling, normal modes, and frequency response, the last of which is only for the Earth launch load case. The final results indicated that all of the requirements are satisfied except the thermal limits, which could not yet be tested, and the normal modes for the Mars entry. However, the frequency limits during Mars entry are expected to be much higher than the lower frequency limits set for the analysis. In addition, there are still improvements that can be made in order to reduce the weight while still meeting all requirements.

Ahmed, Samee W.↗

NASA NTRS2018

Rotorcraft Optimization Tools: Incorporating Rotorcraft Design Codes into Multi-Disciplinary Design, Analysis, and Optimization

One of the goals of NASA's Revolutionary Vertical Lift Technology Project (RVLT) is to provide validated tools for multidisciplinary design, analysis and optimization (MDAO) of vertical lift vehicles. As part of this effort, the software package, RotorCraft Optimization Tools (RCOTOOLS), is being developed to facilitate incorporating key rotorcraft conceptual design codes into optimizations using the OpenMDAO multi-disciplinary optimization framework written in Python. RCOTOOLS, also written in Python, currently supports the incorporation of the NASA Design and Analysis of RotorCraft (NDARC) vehicle sizing tool and the Comprehensive Analytical Model of Rotorcraft Aerodynamics and Dynamics II (CAMRAD II) analysis tool into OpenMDAO-driven optimizations. Both of these tools use detailed, file-based inputs and outputs, so RCOTOOLS provides software wrappers to update input files with new design variable values, execute these codes and then extract specific response variable values from the file outputs. These wrappers are designed to be flexible and easy to use. RCOTOOLS also provides several utilities to aid in optimization model development, including Graphical User Interface (GUI) tools for browsing input and output files in order to identify text strings that are used to identify specific variables as optimization input and response variables. This paper provides an overview of RCOTOOLS and its use

Analysi↗