Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Modeling 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 811 records · Page 45

A Comprehensive Machine Learning Model for Metal–Ligand Binding Prediction: Applications in Chemistry and Biology

A machine-learning (ML) model that predicts metal–ligand binding constants was developed using the open-source Chemprop software. The model was trained on over 30,000 experimental log K 1 values, which include both protonation and metal–ligand stability constants, comprising over 3500 ligands and 10 2 metal ions from 73 total elements, thus generalizing beyond existing limited approaches, which focus only on specific metals or ligand families. The best-performing model included a combination of SMILES-based molecular representations along with descriptors for the metal ion and experimental conditions. It had an external test R 2 value of 0.942, and MAE value of 0.834. A “SMILES-only” simpler version also produced accurate predictions and preserved the binding trends, serving as a quick and easily accessible alternative for users without computational expertise. The SMILES-only model performed comparably to density functional theory (DFT) calculations but utilized a fraction of the computational resources. The model was successfully applied across diverse domains, including bioinorganic chemistry, heavy metal remediation, and sensor development and demonstrated its effectiveness as a rapid and reliable screening tool for both academic and industrial uses.

Ligands↗

Quantifying and Zoning Urban Heat Island Effects Using Unsupervised Machine Learning

This work explores the Urban Heat Island (UHI) effects in Maricopa County, Arizona, employing a simulation-based approach that combines large-scale building energy modeling with advanced spatial analysis. Utilizing the Automatic Building Energy Modeling (AutoBEM) software suite, we simulated the energy consumption for approximately 1.35 million buildings based on the Model America version 1.0 (MAv1) dataset. Our methodology incorporated spatial analysis at multiple scales, including individual buildings, clusters of zones determined by K-means clustering, and geographical level evaluation based on Zip codes. The results revealed significant variations in energy consumption and heat emissions across different building types and urban zones. High-emission hotspots identified through clustering pointed to areas most contributing to the UHI effects. Zip code-based area analysis further contextualized these findings, offering an urban context-based perspective on emission distribution and informing potential urban energy policies for mitigating UHI effects.

Chowdhury, Shovan [ORNL]↗

A report on NASA software engineering and Ada training requirements

NASA's software engineering and Ada skill base are assessed and information that may result in new models for software engineering, Ada training plans, and curricula are provided. A quantitative assessment which reflects the requirements for software engineering and Ada training across NASA is provided. A recommended implementation plan including a suggested curriculum with associated duration per course and suggested means of delivery is also provided. The distinction between education and training is made. Although it was directed to focus on NASA's need for the latter, the key relationships to software engineering education are also identified. A rationale and strategy for implementing a life cycle education and training program are detailed in support of improved software engineering practices and the transition to Ada.

Legrand, Sue↗

Graphics modelling of non-contact thickness measuring robotics work cell

A system was developed for measuring, in real time, the thickness of a sprayable insulation during its application. The system was graphically modelled, off-line, using a state-of-the-art graphics workstation and associated software. This model was to contain a 3D color model of a workcell containing a robot and an air bearing turntable. A communication link was established between the graphics workstations and the robot's controller. Sequences of robot motion generated by the computer simulation are transmitted to the robot for execution.

Warren, Charles W.↗

Power Operations of the Mars Exploration Rovers

The rovers of the National Aeronautics and Space Administration’s (NASA) Mars Exploration Rovers (MER) project, Spirit (MER-A) and Opportunity (MER-B), safely landed on the surface of Mars three weeks apart during January 2004. Spirit and Opportunity were built and operated by the Jet Propulsion Laboratory (JPL), which is managed by the California Institute of Technology (Caltech) for NASA. Spirit landed at Gusev Crater, 14.8 degrees south of the equator, and operated continuously on the surface of Mars from January 4, 2004 until last contact from Spirit on March 22, 2010. Opportunity landed at Meridiani Planum, a location 2.5 degrees south of the Martian equator. Opportunity operated continuously on the Martian surface from January 25, 2004 until the last received transmission from Opportunity on June 10, 2018. The goal of the MER project was to determine if Mars ever had a habitable environment, in particular, if it ever had water. During their missions, both Spirit and Opportunity found evidence that liquid water once flowed on the surface of Mars. Both Spirit and Opportunity used a 1.33 m2 triple-junction solar array as their power sources. Based on observations of the original Mars rover, the Sojourner rover of the Mars Pathfinder mission that landed on Mars on July 4, 1997, the expectation was that the Martian dust would rapidly accumulate on the solar arrays of Spirit and Opportunity, and that the rovers would not have enough energy to continue operations after 90 Martian days (sols). Instead, due in part to lower dust accumulation rates than expected and numerous dust cleaning events, the Spirit and Opportunity rovers continued to operate on the Martian surface for over 2000 sols (MER-A) and 5000 sols (MER-B), respectively. During this time, the rovers experienced multiple Martian winters and several dust storms. Because the sources of solar array energy loss were known, the solar array energy output offered a method to scientifically estimate the loading and aeolian removal of dust from the solar arrays each sol. The MER Power operations team called this value that they calculated the solar array Dust Factor (DF). Dust Factor was defined as the fraction of sunlight that penetrates the accumulated dust on the surface of the solar array. A Dust Factor of 1.0 would indicate that the solar array was perfectly clean. A Dust Factor of 0.6 would indicate that only 60% of the available sunlight was able to penetrate the accumulated dust on the solar arrays. The MER Power subsystem operations team used the Multi-Mission Power Analysis Tool (MMPAT) to perform these Dust Factor calculations. The MMPAT software tool modeled the behavior of the solar arrays and the batteries as they interacted with the spacecraft power loads over the mission timeline. MMPAT also had knowledge (through telemetry and user inputs) of telemetered Power subsystem voltages and currents, atmospheric opacity (Tau), rover surface location, rover attitude, the planetary tilt and distance of Mars from the sun based on day of year, the instantaneous elevation of the sun based on time of day, temperatures (internal and external), terrain masking, and shadowing (due to the camera mast and antennas). Once all of the known sources of array energy loss are accounted, the remaining difference between the expected array energy and the actual array energy determines the solar array Dust Factor. The assumptions made while determining the Dust Factor are 1) that the single measured atmospheric opacity value (Tau) is constant over the course of the entire sol, 2) there is no measurable solar cell degradation, 3) there are no shorted strings and therefore, 4) all unexpected solar array energy losses are due to accumulated dust on the solar array. Although it cannot provide an absolute measure of dust loading, the determination of solar array Dust Factor provides a useful way of tracking dust accumulation and aeolian dust removal trends on Martian spacecraft. Any spacecraft on the Martian surface is vulnerable to dust, especially solar-powered spacecraft. The Spirit and Opportunity rovers were operational on the Martian surface for much longer than expected due in part to aeolian removal of dust from their solar arrays. The first few dust removal events were a pleasant surprise to the MER operations teams; however, over time a pattern began to arise. In over three Mars Years on the surface, the Power operations team tracked the solar array Dust Factor at Gusev Crater (location of MER-A) and observed that there were several significant dust removal and deposition events in Mars Year (MY) 27, even in the absence of a large dust storm. In MY 28 at Gusev Crater, the large atmospheric opacity (Tau) increase lagged significant dust removal events. Overall at Gusev Crater, there was a pattern of steady dust accumulation on the solar arrays, with a small number of significant dust cleaning events. At Meridiani Planum, where Opportunity rover operated for over seven Mars Years (late MY 26 to mid MY 34), a clear and consistent pattern of dust movement emerged. Meridiani Planum had a predictable, seasonally dependent pattern of gradual and continuous dust accumulation and removal. In summary, this paper explains the reasons for the development of the solar array Dust Factor and how it was used in mission operations. In particular, this paper describes the MMPAT software package, how it models array energy, including the important assumptions, model inputs and sources of error. And finally, this paper will show how the calculated solar array Dust Factor was used at Gusev Crater and Meridiani Planum to predict dust accumulation rates and weather patterns, and the importance of this generated data set for current and future solar- powered missions to Mars, such as the InSight lander and the planned Mars Sample Return rover.

Chin, Keith B.↗

Software dependability in the Tandem GUARDIAN system

Based on extensive field failure data for Tandem's GUARDIAN operating system this paper discusses evaluation of the dependability of operational software. Software faults considered are major defects that result in processor failures and invoke backup processes to take over. The paper categorizes the underlying causes of software failures and evaluates the effectiveness of the process pair technique in tolerating software faults. A model to describe the impact of software faults on the reliability of an overall system is proposed. The model is used to evaluate the significance of key factors that determine software dependability and to identify areas for improvement. An analysis of the data shows that about 77% of processor failures that are initially considered due to software are confirmed as software problems. The analysis shows that the use of process pairs to provide checkpointing and restart (originally intended for tolerating hardware faults) allows the system to tolerate about 75% of reported software faults that result in processor failures. The loose coupling between processors, which results in the backup execution (the processor state and the sequence of events) being different from the original execution, is a major reason for the measured software fault tolerance. Over two-thirds (72%) of measured software failures are recurrences of previously reported faults. Modeling, based on the data, shows that, in addition to reducing the number of software faults, software dependability can be enhanced by reducing the recurrence rate.

Lee, Inhwan↗

Model America - data and models of every U.S. building

The 5-year goal of the 'Model America' concept was to generate a model of every building in the United States. This data repository delivers on that goal. Oak Ridge National Laboratory (ORNL) has developed the Automatic Building Energy Modeling (AutoBEM) software suite to process multiple types of data, extract building-specific descriptors, generate building energy models, and simulate them on High Performance Computing (HPC) resources. For more information, see AutoBEM-related publications (bit.ly/AutoBEM). There were 125,714,640 buildings detected in the United States and this dataset contains 122,930,327 (97.8%) buildings which resulted in a successful simulation. Future, annual updates have been proposed that may include additional buildings, data improvements, or other algorithmic enhancements. This dataset of 122.9 million buildings includes: Models (state_county.zip) - OpenStudio (v3.1.0) and EnergyPlus (v9.4) building energy models. Please note that the download requires the free Globus Connect Personal (https://www.globus.org/globus-connect-personal); Each model has approximately 3,000 building input descriptors that can be extracted. Please see the EnergyPlus(v9.4) 2,784-page Input/Output Reference Guide (https://energyplus.net/sites/all/modules/custom/nrel_custom/pdfs/pdfs_v9.4.0/InputOutputReference.pdf) for everything that can be retrieved or simulated from these models. These models were derived from the following metadata, which is not included in this dataset: 1. ID - unique building ID 2. County - county name 3. State - state name 4. CZ - ASHRAE Climate Zone designation 5. Clim_Zone - text label of climate zone 6. est_year - estimated year of construction 7. est_commercial - estimated building type (0=residential, 1=commercial) 8. Centroid - building center location in latitude/longitude (from Footprint2D) 9. Footprint2D - building polygon of 2D footprint (lat1/lon1_lat2/lon2_...) 10. Height - building height (meters) 11. Area2D - footprint area (ft2) 12. BuildingType - DOE prototype building designation (IECC=residential) as implemented by OpenStudio-standards 13. WWR_surfaces - percent of each facade (pair of points from Footprint2D) covered by fenestration/windows (average 14.5% for residential, 40% for commercial buildings) 14. NumFloors - number of floors (above-grade) 15. Area - estimate of total conditioned floor area (ft2) 16. Standard - building vintage. These models are made free and openly available in hopes of stimulating any simulation-informed use case. Data is provided as-is with no warranties, express or implied, regarding fitness for a particular purpose. We wish to thank our sponsors which include Oak Ridge National Laboratory (ORNL) Laboratory Directed Research and Development (LDRD), U.S. Dept. of Energy's (DOE) Building Technologies Office (BTO), Office of Electricity (OE), Biological and Environmental Research (BER), and National Nuclear Security Administration (NNSA). This research used resources of the Argonne Leadership Computing Facility, which is a DOE Office of Science User Facility supported under Contract DE-AC02-06CH11357. Please cite as: New, Joshua R., Adams, Mark, Bass, Brett, Berres, Anne, and Clinton, Nicholas (2021). 'Model America - data and models of every U.S. building. [Data set].' Constellation, doi.ccs.ornl.gov/ui/doi/339, April 14, 2021

24 POWER TRANSMISSION AND DISTRIBUTION↗

Model America - Arizona extract from ORNL's AutoBEM v1.1

Oak Ridge National Laboratory (ORNL) has developed the Automatic Building Energy Modeling (AutoBEM) software suite to process multiple types of data, extract building-specific descriptors, generate building energy models, and simulate them on High Performance Computing (HPC) resources. For more information, see AutoBEM-related publications (bit.ly/AutoBEM).Two sets of sample data are provided for 2,555,152 buildings located within the boundary of Arizona in the United States:Data (846.3MB *.csv) - minimalist list of each building (rows) for the following fields (columns) • ID - unique building ID • Centroid - building center location in latitude/longitude (from Footprint2D) • Footprint2D - building polygon of 2D footprint (lat1/lon1_lat2/lon2_...) • State_abbr - state name • Area - estimate of total conditioned floor area (ft2) • Area2D - footprint area (ft2) • Height - building height (ft) • NumFloors - number of floors (above-grade) • WWR_surfaces - percent of each facade (pair of points from Footprint2D) covered by fenestration/windows (average 14.5% for residential, 40% for commercial buildings) • CZ - ASHRAE Climate Zone designation • BuildingType - DOE prototype building designation (IECC=residential) as implemented by OpenStudio-standards • Standard - building vintage • Sample Models (114GB*.zip by county) - OpenStudio and EnergyPlus building energy models named according to IDThis data is made free and openly available in hopes of stimulating any simulation-informed use case. Data is provided as-is with no warranties, express or implied, regarding fitness for a particular purpose. We wish to thank our sponsors which include Oak Ridge National Laboratory (ORNL), U.S. Dept. of Energy’s (DOE) Building Technologies Office (BTO), Office of Electricity (OE), and Biological and Environmental Research (BER).

54 ENVIRONMENTAL SCIENCES↗

Model America: Data and Models for every U.S. Building

The 5-year goal of the “Model America” concept was to generate a model of every building in the United States. This data repository delivers on that goal with "Model America v1". Oak Ridge National Laboratory (ORNL) has developed the Automatic Building Energy Modeling (AutoBEM) software suite to process multiple types of data, extract building-specific descriptors, generate building energy models, and simulate them on High Performance Computing (HPC) resources. For more information, see AutoBEM-related publications (bit.ly/AutoBEM). There were 125,715,609 buildings detected in the United States. Of this number, 122,146,671 (97.2%) buildings resulted in a successful generation and simulation of a building energy model. This dataset includes the full 125 million buildings. Future updates may include additional buildings, data improvements, or other algorithmic model enhancements in "Model America v2". This dataset contains OSM and IDF zip files for every U.S. county. Each zip file contains the generated buildings from that county. The .csv input data contains the following data fields: 1. ID - the Unique Building Identifier (UBID), generated using the Pacific Northwest National Laboratory (PNNL) BuildingID framework 2. Centroid - building center location in latitude/longitude (from Footprint2D) 3. Footprint2D - building polygon of 2D footprint (lat1/lon1_lat2/lon2_...) 4. State_abbr - state name 5. Area - estimate of total conditioned floor area (ft2) 6. Area2D - footprint area (ft2) 7. Height - building height (ft) 8. NumFloors - number of floors (above-grade) 9. WWR_surfaces - percent of each facade (pair of points from Footprint2D) covered by fenestration/windows (average 14.5% for residential, 40% for commercial buildings) 10. CZ - ASHRAE Climate Zone designation 11. BuildingType - DOE prototype building designation (IECC=residential) as implemented by OpenStudio-standards 12. Standard - building vintage This data is made free and openly available in hopes of stimulating any simulation-informed use case. Data is provided as-is with no warranties, express or implied, regarding fitness for a particular purpose. We wish to thank our sponsors which include Oak Ridge National Laboratory (ORNL) Laboratory Directed Research and Development (LDRD), U.S. Dept. of Energy’s (DOE) Building Technologies Office (BTO), Office of Electricity (OE), Biological and Environmental Research (BER), and National Nuclear Security Administration (NNSA). Update (September 23, 2025): We corrected the ID field in all state-level.csv input files to ensure one-to-one consistency with the corresponding .osm and .idf output files. The schema and file structure are unchanged; only the values in the ID column were modified. No files were added or removed, and the .zip bundles (containing .osm / .idf) are unchanged. The corrected .csv inputs were re-extracted in March 2025 from the original data generated ~ 2021 (Theta supercomputer runs), and published here to align input IDs with model outputs. Update (September 6, 2026): The Model America dataset was updated to replace the previous building ID field with the Unique Building Identifier (UBID), using the Pacific Northwest National Laboratory (PNNL) BuildingID framework. UBIDs provide standardized, location-based identifiers for individual building footprints and improve interoperability with other building and geospatial datasets. The data files containing the previous building identifiers were updated to include UBIDs. This update standardizes building identification; the underlying Model America building characteristics and energy simulation results were not recomputed as part of this update.

54 ENVIRONMENTAL SCIENCES↗

Software-Defined Network for End-to-end Networked Science at the Exascale

Domain science applications and workflow processes are currently forced to view the network as an opaque infrastructure into which they inject data and hope that it emerges at the destination with an acceptable Quality of Experience. There is little ability for applications to interact with the network to exchange information, negotiate performance parameters, discover expected performance metrics, or receive status/troubleshooting information in real time. The work we presen here is motivated by a vision for a new smart network and smart application ecosystem that will provide a more deterministic and interactive environment for domain science workflows. The Software-Defined Network for End-to-end Networked Science at Exascale (SENSE) system includes a model-based architecture, implementation, and deployment which enables automated end-to-end network service instantiation across administrative domains. An intent based interface allows applications to express their high-level service requirements, an intelligent orchestrator and resource control systems allow for custom tailoring of scalability and real-time responsiveness based on individual application and infrastructure operator requirements. This allows the science applications to manage the network as a first-class schedulable resource as is the current practice for instruments, compute, and storage systems. Deployment and experiments on production networks and testbeds have validated SENSE functions and performance. Emulation based testing verified the scalability needed to support research and education infrastructures. Key contributions of this work include an architecture definition, reference implementation, and deployment. This provides the basis for further innovation of smart network services to accelerate scientific discovery in the era of big data, cloud computing, machine learning and artificial intelligence.

97 MATHEMATICS AND COMPUTING↗

Software-defined network for end-to-end networked science at the exascale

Domain science applications and workflow processes are currently forced to view the network as an opaque infrastructure into which they inject data and hope that it emerges at the destination with an acceptable Quality of Experience. There is little ability for applications to interact with the network to exchange information, negotiate performance parameters, discover expected performance metrics, or receive status/troubleshooting information in real time. The work presented here is motivated by a vision for a new smart network and smart application ecosystem that will provide a more deterministic and interactive environment for domain science workflows. The Software-Defined Network for End-to-end Networked Science at Exascale (SENSE) system includes a model-based architecture, implementation, and deployment which enables automated end- to-end network service instantiation across administrative domains. An intent based interface allows applications to express their high-level service requirements, an intelligent orchestrator and resource control systems allow for custom tailoring of scalability and real-time responsiveness based on individual application and infrastructure operator requirements. This allows the science applications to manage the network as a first-class schedulable resource as is the current practice for instruments, compute, and storage systems. Deployment and experiments on production networks and testbeds have validated SENSE functions and performance. Emulation based testing verified the scalability needed to support research and education infrastructures. Key contributions of this work include an architecture definition, reference implementation, and deployment. This provides the basis for further innovation of smart network services to accelerate scientific discovery in the era of big data, cloud computing, machine learning and artificial intelligence.

47 OTHER INSTRUMENTATION↗

An Advanced Meso-Scale Peridynamic Modeling Technology using High-Performance Computing for Cost-Effective Product Design and Testing of Carbon Fiber Reinforced Polymer Composites in Light-weight Vehicles

We study a peridynamic composite modeling technology based on the discontinuous Galerkin finite element method, implemented in the commercial LS-DYNA software, for modeling and prediction of failure in carbon fiber reinforced polymer composites. The proposed technology is developed for the material failure analysis at the meso-scale, which provides the prevailing fiber-matrix interaction mechanism, without adoption of the representative volume element method and thus avoiding complicated numerical calibration procedures. Three types of experimental tests—in-plane coupon test, out-of-plane coupon test, and a component crash test—are simulated in a high-performance computing environment to assess the performance of the proposed peridynamic composite modeling technology.

36 MATERIALS SCIENCE↗

Urban Deployment Model (UDM) v1.0

The software, called the Urban Deployment Model (UDM), is an integrated set of tools for the simulation and analysis of static and mobile radiation detection systems in complex urban environments. The UDM includes a graphical user interface through which the workflow associated with setting up and executing a simulation may be established. The modular toolsets combine aspects of radiation transport, navigation, graph theory, optimization, and visualization to allow the complete end-to-end simulation of large scale, highly-distributed sensor networks.

Abgrall, Nicolas↗

Preliminary description of the area navigation software for a microcomputer-based Loran-C receiver

The development of new software implementation of this software on a microcomputer (MOS 6502) to provide high quality navigation information is described. This software development provides Area/Route Navigation (RNAV) information from Time Differences (TDs) in raw form using an elliptical Earth model and a spherical model. The software is prepared for the microcomputer based Loran-C receiver. To compute navigation infomation, a (MOS 6502) microcomputer and a mathematical chip (AM 9511A) were combined with the Loran-C receiver. Final data reveals that this software does indeed provide accurate information with reasonable execution times.

Oguri, F.↗

SRMS History, Evolution and Lessons Learned

Early in the development of the Space Shuttle, it became clear that NASA needed a method of deploying and retrieving payloads from the payload bay. The Shuttle Remote Manipulator System (SRMS) was developed to fill this need. The 50 foot long robotic arm is an anthropomorphic design consisting of three electromechanical joints, six degrees of freedom, and two boom segments. Its composite boom construction provided a light weight solution needed for space operations. Additionally, a method of capturing payloads with the arm was required and a unique End Effector was developed using an electromechanical snare mechanism. The SRMS is operated using a Displays and Controls Panel and hand controllers located within the aft crew compartment of the shuttle. Although the SRMS was originally conceived to deploy and retrieve payloads, its generic capabilities allowed it to perform many other functions not originally conceived of. Over the years it has been used for deploying and retrieving constrained and free flying payloads, maneuvering and supporting EVA astronauts, satellite repair, International Space Station construction, and as a viewing aid for on-orbit International Space Station operations. After the Columbia accident, a robotically compatible Orbiter Boom Sensor System (OBSS) was developed and used in conjunction with the SRMS to scan the Thermal Protection System (TPS) of the shuttle. These scans ensure there is not a breach of the TPS prior to shuttle re-entry. Ground operations and pre mission simulation, analysis and planning played a major role in the success of the SRMS program. A Systems Engineering Simulator (SES) was developed to provide a utility complimentary to open loop engineering simulations. This system provided a closed-loop real-time pilot-driven simulation giving visual feedback, display and control panel interaction, and integration with other vehicle systems, such as GN&C. It has been useful for many more applications than traditional training. Evolution of the simulations, guided by the Math Model Working Group, showed the utility of input from multiple modeling groups with a structured forum for discussion.There were many unique development challenges in the areas of hardware, software, certification, modeling and simulation. Over the years, upgrades and enhancements were implemented to increase the capability, performance and safety of the SRMS. The history and evolution of the SRMS program provided many lessons learned that can be used for future space robotic systems.

Jorgensen, Glenn↗

Turbo-Turtle v0.12.1

A collection of solid body modeling tools for 2D sketched, 2D axisymmetric, and 3D revolved models. It also contains general purpose meshing and image generation utilities appropriate for any model, not just those created with this package. Implemented for Abaqus and Cubit as backend modeling and meshing software. Orginal implementation targeted Abaqus so most options and descriptions use Abaqus modeling concepts and language. Turbo-Turtle makes a best effort to maintain common behaviors and features across each third-party software’s modeling concepts. As much as possible, the work for each subcommand is performed in Python 3 to minimize solution approach duplication in third-party tools. The third-party scripting interface is only accessed when creating the final tool specific objects and output. The tools contained in this project can be expanded to drive other meshing utilities in the future, as needed by the user community. This project derives its name from the origins as a sphere partitioning utility following the turtle shell (or soccer ball) pattern.s.

Brindley, Kyle↗