SEARCH · Engineering Papers
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.
This is a fork of the omni-engineer software developed by Pietro Schirano. My collaborators and I are altering the software to work better with our LBNL infrastructure and requirements. The software is a coding agent wrapper around LLM model APIs, and can use any of the APIs provided by LBNL's CBorg service, or any service that uses an OpenAI endpoint(s).
Kynema-FMB (FKA: Kynema) is an open-source performance portable flexible multibody (FMB) dynamics solver designed for time-domain simulations. While originally tailored for wind turbine structural dynamics, the formulation and implementation are those of a general flexible-multidbody dynamics solver that can readily be applied to a wide range of systems. Kynema was designed with a narrow focus, namely to provide a lightweight, fast, accurate FMD solver for coupling to computational-fluid-dynamics (CFD) codes, especially the CFD codes in the Kynema suite, for fluid-structure-interaction (FSI) simulations. Kynema-FMB is equipped to model systems that can be represented as a collection of beams and rigid bodies that are connected through constraints. Degrees of freedom are defined in the inertial/global frame of reference and include displacements and rotations (formally as rotation matrices, but stored as quaternions). The underlying formulation is built on a Lie-group time integrator designed for index-3 differential-algebraic equations, which is second-order accurate in time (Bruls et al., 2012). Beam models are based on geometrically exact beam theory and are discretized as high-order spectral finite elements similar to those in BeamDyn (Wang et al., 2017). The governing equations for a FMD system like a wind turbine constitute a highly nonlinear system of constrained partial-differential equations. Kynema-FMB uses analytical Jacobians in the nonlinear-system solves in each time step. Linear systems use sparse storage and several third-party sparse-linear-system solvers are enabled. Ill conditioning of linear systems is mitigated with preconditioning described in Bottasso et al, 2008. Kynema-FMB is integrated with a simple open-source controller (ROSCO). There is an application programming interface (API) for coupling to geometry-resolved CFD (like that in Sharma et al., 2023) and actuator-force CFD (like that in Kuhn et al., 2025). In the latter, for actuator-line models, Kynema-FMB includes an internal blade-element solver that depends on user-provided lookup tables for coefficients of lift and drag, i.e., aerodynamic polars. Kynema-FMB is written in C++ and leverages Kokkos and Kokkos-Kernels (KokkosEcosystem) as its performance portability layer enabling simulations on both CPU and GPU systems. The repository is equipped with extensive automated testing at the unit and regression/system levels. The following describes the high-level development objectives conceived for Kynema: *Kynema will follow modern software development best practices, including test-driven development (TDD), version control, hierarchical automated testing, and continuous integration (CI) for a robust development environment. *The core data structures are memory efficient and enable vectorization and parallelization at multiple levels. *Data structures are data-oriented to exploit methods for accelerated computing including high utilization of chip resources (e.g., single instruction multiple data (SIMD) instruction sets) and parallelization using GP-GPUs. *The computational algorithms incorporate robust open-source libraries for mathematical operations, resource allocation, and data management. *The API design considers multiple stakeholder needs and ensure integration with existing and future ecosystems for data science, machine learning, and AI. *Kynema-FMB is written in modern C++ and leverages Kokkos as its performance-portability library with inspiration from the kynema stack.
Provides public APIs to the Fermilab control system. This service exposes several GraphQL endpoints for various, logical APIs that clients may use to retrieve control system data and, in some cases, make changes to the control system. This service is currently running on acsys-proxy.fnal.gov on port 8000 with the development instance on port 8001. The middle layer of the control system uses gRPCs for communications. The GraphQL resolvers of this service use various gRPC services to obtain the information that is returned. This uses the async-graphql and warp crates to provide GraphQL over http support. The resolvers use the tonic crate for gRPC client support.
Battery Analysis and Training Models for Optimization and Design Studies (BATMODS) is a Python package with an API for pre-built battery models. The original purpose of the package was to quickly generate synthetic data for machine learning models to train with. However, the models are generally useful for any battery simulations or analysis. BATMODS-lite includes the following: 1) A library and API for pre-built battery models 2) Kinetic/transport properties for common battery materials
AQDrop is a job management system designed to streamline access to the Advanced Quantum Testbed (AQT) at NERSC (National Energy Research Scientific Computing Center). It serves as a centralized middleware layer between researchers and quantum processing hardware. Key Features: AQDrop provides a FastAPI-based server backed by PostgreSQL for job submission, queue management, and role-based access control (members, operators, and administrators). Users submit Qiskit circuits via JSON payloads, which are queued, dispatched to the QPU through the Qubic API, and returned as measurement counts. A Python client library and web dashboard round out the interface options. Primary Use: Researchers submit quantum circuit jobs from a laptop or login node; an operator client executes those jobs on the AQT's physical QPU and returns results — all coordinated through the central API. Advantages: Compared to ad-hoc or direct hardware access, AQDrop adds structured queue management, auditable job-status tracking and OAuth2 authentication — reducing scheduling conflicts and unauthorized access. Its containerized deployment also improves reproducibility and scalability. Overall, AQDrop functions as a purpose-built quantum job broker tailored to NERSC's specific hardware and institutional access requirements.
API to store fact iA lightweight API service built with Litestar for collecting and storing system information from remote hosts. Designed to handle large-scale concurrency, the service receives HTTP submissions of system facts and package inventory from Ansible, curl, or other client tooling.nformation
Exascale computers offer transformative capabilities to combine data-driven and learning-based approaches with traditional simulation applications to accelerate scientific discovery and insight. However, these software combinations and integrations are difficult to achieve due to the challenges of coordinating and deploying heterogeneous software components on diverse and massive platforms. Here, we present the ExaWorks project, which addresses many of these challenges. We developed a workflow Software Development Toolkit (SDK), a curated collection of workflow technologies that can be composed and interoperated through a common interface, engineered following current best practices, and specifically designed to work on HPC platforms. ExaWorks also developed PSI/J, a job management abstraction API, to simplify the construction of portable software components and applications that can be used over various HPC schedulers. The PSI/J API is a minimal interface for submitting and monitoring jobs and their execution state across multiple and commonly used HPC schedulers. We also describe several leading and innovative workflow examples of ExaWorks tools used on DOE leadership platforms. Furthermore, we discuss how our project is working with the workflow community, large computing facilities, and HPC platform vendors to address the requirements of workflows sustainably at the exascale.
Rhamnogalacturonan II (RG-II) is a structurally complex pectic polysaccharide that exists as a borate ester cross-linked dimer in the cell walls of all vascular plants. The glycosyl sequence of RG-II is largely conserved, but there is evidence that galacturonic acid (GalA) methyl etherification and glucuronic acid (GlcA) methyl esterification vary in the A sidechain across plant species. Methyl esterification of the galacturonan backbone has also been reported but not confirmed. Here we describe a new procedure, utilizing aq. sodium borodeuteride (NaBD4)-reduced RG-II, to identify the methyl esterification status of backbone GalAs. Our data suggest that up to two different GalAs are esterified in the RG-II backbone. We also adapted a procedure based on methanolysis and NaBD4 reduction to identify 3-, 4-, and 3,4-O-methyl GalA in RG-II. These data, together with matrix-assisted laser desorption/ionization–time-of-flight mass spectrometry (MALDI-TOF) MS analysis of sidechain A generated from selected RG-IIs and their NaBD4-reduced counterparts, suggest that methyl etherification of the ß-linked GalA and methyl esterification of the GlcA are widespread. Nevertheless, the extent of these modifications varies between plant species. Our analysis of the sidechain B glycoforms in RG-II from different dicots and nonpoalean monocots suggests that this sidechain has a minimum structure of an O-acetylated hexasaccharide (Ara-[MeFuc]-Gal-AceA-Rha-Api-). To complement these studies, we provide further evidence showing that dimer formation and stability in vitro is cation and borate dependent. Taken together, our data further refine the primary sequence and sequence variation of RG-II and provide additional insight into dimer stability and factors controlling dimer self-assembly.
This dataset describes the performance and fuel efficiency of AVTA test vehicles operating in commercial courier fleets the Phoenix, AZ metro area between 2010 and 2016. Aftermarket data loggers were installed in two to four vehicles of each of 30+ distinct year/make/models (see reference ["INL Advanced Vehicle Testing Activity: On-road Logger and Laboratory Battery Pack Testing Vehicle List"](https://avt.inl.gov/sites/default/files/pdf/reports/DatasetVehicleList.pdf) for full list of vehicles). Loggers recorded vehicle operation as they were driven up to 160,000 miles in up to three years of fleet testing. Parameters were logged at 1-second intervals, including - vehicle speed, - engine and/or electric motor speed, - fuel and/or electricity consumption, and - ambient temperature. This dataset includes both raw second-by-second data and trip-level metrics. (This dataset will be shared by API; a small sample of the vehicle and logger data has been extracted and is available for download while the API is being developed.)
For one of each of the AVTA's plug-in hybrid electric vehicles, battery electric vehicles, and some hybrid electric vehicles tested in high-mileage courier fleets, the high-voltage traction battery packs were removed from the vehicle and tested at the beginning and end of fleet testing. For some vehicles, batteries also were tested at periodic intervals during fleet testing. Standard reference performance tests were conducted to characterize battery degradation over time. This dataset contains results from two or more rounds of battery tests for 21 distinct year/make/model vehicles (see reference ["INL Advanced Vehicle Testing Activity: On-road Logger and Laboratory Battery Pack Testing Vehicle List"](https://avt.inl.gov/sites/default/files/pdf/reports/DatasetVehicleList.pdf) for full list of vehicles). Each round of battery testing included the "Static Capacity Test" and the "Hybrid Pulse Power Characterization (HPPC) Test", conducted according to test procedures published in the United States Advanced Battery Consortium ["Battery Test Manual For Power-Assist Hybrid Electric Vehicles"](https://www.uscar.org/commands/files_download.php?files_id=57), ["Battery Test Manual For Plug-In Hybrid Electric Vehicles"](https://www.uscar.org/commands/files_download.php?files_id=168), and ["Electric Vehicle Battery Test Procedures Manual"](https://www.uscar.org/commands/files_download.php?files_id=5) prior to the time of testing. These tests were performed by Intertek Testing Services, North America. (This dataset will be shared by API; a small sample of the vehicle battery and test data has been extracted and is available for download while the API is being developed.)
The Marcellus Shale Energy and Environmental Laboratory (MSEEL) consists of two project areas within the dry gas producing region of the Marcellus shale play in Monongalia County, West Virginia. MSEEL is a collaborative field project led by West Virginia University, with Northeast Natural Energy LLC, several industrial partners, and sponsored by the US Department of Energy National Energy Technology Laboratory. The study areas are drilled approximately 8.5 miles apart to better understand the vertical and lateral changes in stratigraphy over a short distance. Two vertical pilot wells, MIP-3H and Boggess 17H were drilled in the fall of 2015 and spring of 2019, respectively. Core was recovered from the MIP-3H (API: 47-061-01707-00-00) 112 feet (34m) between depths of 7445 to 7557 feet, and from the Boggess 17H (API: 47-061-01812-00-00) 139 feet (42m) between depths of 7908 and 8012 ft. A full suite of triple combo (gamma ray, neutron, density logs), image logs, and advanced logging tools were run in both wells and calibrated to core analysis. Core analysis includes medical computed tomography (CT) scans, mineralogy and chemostratigraphy determined from handheld X-Ray fluorescence (hhXRF) and X-Ray powder diffraction (XRD) measurements, and determination of total organic content (TOC). Lithofacies were determined at core-scale using traditional core description techniques and medical CT-scan images. Log-scale facies are based on mineralogy and TOC data and developed using petrophysical logging data calibrated to core data (XRD and pyrolysis data). Chemostratigraphic analysis utilized hhXRF data to determine the major and trace element trends in the cores. In the two wells six shale lithofacies were recognized at the core and log scale. Both wells show organic-rich facies (TOC > 6.5%) primarily in the middle and lower Marcellus, with a slight decrease in thickness of this interval in the Boggess 17H. This interval is interpreted as an increase in paleo-productivity (increased Ni, Zn, and V), decreased sedimentation (decreased detrital proxies), and anoxic to euxinic conditions (increased Mo and chalcophile elements). Paleo-redox conditions in both wells are dynamic throughout deposition transitioning between euxinic/anoxic to dysoxic/oxic. This trend is seen through elemental proxies and calcite/pyrite concretion distributions.
Multidimensional, experimental and modeling evaluation of permeability evolution, the Caney Shale Field Lab, OK, USA
The Wellbore Exploration and Location Logistic System (WELLS) is a living national wellbore database - created and maintained by the National Energy Technology Laboratory (NETL). This resource contains more than seven million public wellbore records from state, federal, and tribal resources. Sourced from over 65 authoritative, yet disparate resources, the WELLS Database combines and synthesizes well data from oil, gas, underground injection, research, geothermal, geotechnical, groundwater and other types of wells in a single, unified system. This resource can be explored and visualized through the WELLS Interactive Application, also on EDX: https://edx.netl.doe.gov/dataset/wells-interactive-application The WELLS Database (formerly titled CO2-Locate) is an integrated national well dataset, representing open-source wellbore data from disparate state, tribal, and federal entities. The database provides publicly available well header data with key attributes such as well age, depth, and status. The database contains a fully integrated CSV file with all values in numerical columns, such as depth, converted into numbers. This version has a NETL derived API (American Petroleum Institute) number column and has been handled for redundancies, resulting in one record for every unique API number. The database also contains a fully integrated CSV file, where all original data are kept as text values. Additionally, the database includes a shapefile containing key attributes and coordinates from the integrated dataset, reformatted public wells CSV files, and a proprietary well density grid shapefile. Notes for consideration: The WELLS Database will be updated periodically with new datasets and information. A field dictionary with field (i.e., attribute) coverage across acquired public well resources, and the resulting integrated public well datasets are available in the spreadsheet, WELLS_Field_Dictionary.xlsx. Summary layers provided in this database are derived from proprietary layers and do not always contain key features (status, type, true vertical depth, or spud year) and therefore might not be shown when data are queried for those features.
The Institute for the Design of Advanced Energy Systems (IDAES) Integrated Platform is a versatile computational environment offering extensive process systems engineering (PSE) capabilities for optimizing the design and operation of complex, interacting technologies and systems. IDAES enables users to efficiently search vast, complex design spaces to discover the lowest cost, most environmentally sustainable solutions while supporting the full process modeling lifecycle, from conceptual design to dynamic optimization and control. The extensible, open platform empowers users to create models of novel processes and rapidly develop custom analyses, workflows, and end-user applications. IDAES-PSE 2.0.0 Release Highlights Removal of deprecated features from IDAES v1 Update to Pyomo v6.5 – this required a number of updates to support the new NL solver writer and to address some changes in Pyomo Creation of new testing suite for backward compatibility, model robustness and verification More general implementation of the Helmholtz EoS. This brings some new features like standard property diagrams, choice of mass or mole basis, and new state variable options Standardizing names in Heat Exchanger models (breaking change from v2.0.0a2): Control Volumes named hot_side and cold_side Ports names hot_side_inlet, hot_side_outlet, cold_side_inlet and cold_side_outlet Config Blocks names hot_side_config and cold_side_config Config arguments for user provided names for each side: hot_side_name and cold_side_name. Updating Keras surrogate tool to use v1.1 of OMLT New prototype API for model initialization (idaes.core.initialization) The new API uses "Model Initializer" objects instead of class methods, allowing for the definition of multiple initialization routines for a single model A number of common, model agnostic initialization routines have also been defined, including initialization from data, block-decomposition and a general hierarchical approach equivalent to the existing method for common unit models New metadata for thermophysical properties – valid_range This can be used to record the range of values over which a property value can be trusted, such as the range of experimental data used to regress parameters A number of new utility functions have been added to check for properties with values outside the valid range and to set bounds based on this metadata Updated construction of balance expressions in Control Volumes to remove unneeded terms In the past, unneeded terms were added as a constant 0 term, however they will now be dropped entirely from the expression This was necessary due to more strict unit checking in the new Pyomo solver writer which no longer ignores 0 terms Updates to metadata for thermophysical properties to better define known properties and units of measurement This results in more strict enforcement of standard naming for thermophysical and reaction properties Users can still define custom properties, but these must be done explicitly using the define_custom_properties() method instead of being implicitly created by add_property() Updated convergence tester utility tool to support definition of benchmark files (JSON format) and comparison of performance to benchmarks Set default iteration limit for IPOPT in IDAES config to 200 iterations Update scaling of example models to work with new Pyomo NL solver writer Improve testing of extensions and examples infrastructure to avoid need for downloading files Updated distillation column to centralize common functionality and remove a number of Pyomo warnings
The Institute for the Design of Advanced Energy Systems (IDAES) Integrated Platform is a versatile computational environment offering extensive process systems engineering (PSE) capabilities for optimizing the design and operation of complex, interacting technologies and systems. IDAES enables users to efficiently search vast, complex design spaces to discover the lowest cost, most environmentally sustainable solutions while supporting the full process modeling lifecycle, from conceptual design to dynamic optimization and control. The extensible, open platform empowers users to create models of novel processes and rapidly develop custom analyses, workflows, and end-user applications.. Deprecations • Convergence Analysis tool (idaes/core/util/convergence): deprecated in favor of new Parameter Sweep tools. To be removed in v3.0.0. New Beta Capabilities • Parameter Sweep Tool (idaes.core.util.parameter_sweep) o A new API for defining and performing parameter sweep studies on IDAES models has been developed • Diagnostics Tools (idaes.core.util.model_diagnostics) o New methods for identifying duplicate variables and constraints have been added to the diagnostics toolbox o New tools for detecting ill conditioning in Jacobians have been developed and are available in the model_diagnostics module. These provide alternatives to the existing DegeneracyHunter toolbox, and will eventually be merged with this capability, but initial working versions have been provided as beta capabilities for interested users o IpoptConvergenceAnalysis (replaces deprecated Convergence Analysis tool): A new tool for performing convergence analysis studies that leverages the new Parameter Sweep tools has been developed. This tool allows users to define the input parameters to their model and sampling methods for these (leveraging Pysmo's sampling tools) and to then solve their model across the sampled domains and return a summary of the solver performance (IPOPT only) Improved Models • Thickener model (idaes.models.unit_models.solid_liquid.thickener) o Improved model to include predictive correlations for unit sizing based on settling velocity measurements (steady-state only) • Modular Property Packages o Added general support for calculating critical properties of mixtures using defined Equation of State modules. New API defined for Equation of State modules in order to define the necessary constraints for calculating critical properties (most EoS modules DO NOT support calculation of critical properties (yet)) o Added new methods to Cubic Equation of State module to support calculation of critical properties
Data from award DE-FE0029488 - North Dakota Integrated Carbon Capture and Storage Complex Feasibility Study performed by the Energy & Environmental Research Center including the following: - 2D Seismic {Input data, sgy files, maps, logs, and descriptors} - Core Petrophysics {Core analysis of plugs from the two stratigraphic test wells (Flemmer-1 [API 33-057-00039] and BNI-1 [API 33-065-00018])} - North Dakota Oil and Gas File No 37380 Files - North Dakota Oil and Gas File No 37672 Files - Well Testing Data {Summary of well testing methods and results from the stratigraphic test wells (Flemmer-1 and BNI-1)} Additional References: https://www.netl.doe.gov/sites/default/files/2017-12/Wesley-Peck-_Mastering-the-Subsurface_CarbonSAFE-Phase-II_August-2017-final.pdf Peck, W.D., Ayash, S.C., Klapperich, R.J., Gorecki, C.D. (2019) The North Dakota integrated carbon storage complex feasibility study, International Journal of Greenhouse Gas Control, Volume 84, 2019, Pages 47-53, https://doi.org/10.1016/j.ijggc.2019.03.001
The Institute for the Design of Advanced Energy Systems (IDAES) Integrated Platform is a versatile computational environment offering extensive process systems engineering (PSE) capabilities for optimizing the design and operation of complex, interacting technologies and systems. IDAES enables users to efficiently search vast, complex design spaces to discover the lowest cost, most environmentally sustainable solutions while supporting the full process modeling lifecycle, from conceptual design to dynamic optimization and control. The extensible, open platform empowers users to create models of novel processes and rapidly develop custom analyses, workflows, and end-user applications. IDAES-PSE 2.5.0 Release Highlights Upcoming Changes IDAES will be switching to the new Pyomo solver interface in the next release. Whilst this will hopefully be a smooth transition for most users, there are a few important changes to be aware of. The new solver interface uses a different version of the IPOPT writer (“ipopt_v2”) and thus any custom configuration options you might have set for IPOPT will not carry over and will need to be reset. By default, the new Pyomo linear presolver will be activated with ipopt_v2. Whilst are working to identify any bugs in the presolver, it is possible that some edge cases will remain. IDAES will begin deploying a new set of scaling tools and APIs over the next few releases that make use of the new solver writers. The old scaling tools and APIs will remain for backward compatibility but will begin to be deprecated. New Models, Tools and Features New diagnostics check for near-parallel variables and constraints. New diagnostics tools for identifying causes of infeasibility in models. New example for creating a custom model of a liquid-liquid extractor unit operation. Bug Fixes Fixed bug in Gibbs reactor that caused it to appear to have additional spurious degrees of freedom. Fixed bug in the Modular Property Framework that would cause errors when trying to use phase-based material balances with phase equilibria. Fixed bug in Modular Properties Framework that caused errors when initializing models with non-vapor-liquid phase equilibria. Testing and Robustness Deployed the IDAES Diagnostics Toolbox to confirm that there are no structural or numerical issues in the core model libraries. Additional robustness tests for core model, and some associated improvements in the converge tester class. Fixed a number of issues that were causing unexpected warnings to be emitted during testing. Deprecations and Removals Removed examples for RIPE tool which has not been supported for a number of releases.
As the design complexity of modern accelerators grows, there is more interest in using advanced simulations that have fast execution time or yield additional insights like gradients. The FAST/IOTA facility has been working on implementing and experimentally validating an end-to-end digital twin that is both fast and gradient-aware, allowing for rapid prototyping of new software and experiments with minimal beam time costs. Our framework integrates physics and ML codes for linac and ring simulation through a set of generic interfaces between surrogate and physics-based sections. To reproduce device inputs and outputs, system state is exposed as a deterministic event loop in a specialized discrete event simulator architecture. Because Fermilab is undergoing control system transition, several APIs were implemented as final user interfaces - a fully asynchronous EPICS soft IOC, a gRPC-based Data Pool Manager (DPM), and legacy ACNET protocols. We discuss implementation details as well as challenges handling live data assimilation and future plans to extend modelling to main complex proton accelerators like PIPII and Booster.