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.
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.
BACKGROUND:Ontologies are invaluable in the life sciences, but building and maintaining ontologies often requires a challenging number of distinct tasks such as running automated reasoners and quality control checks, extracting dependencies and application-specific subsets, generating standard reports, and generating release files in multiple formats. Similar to more general software development, automation is the key to executing and managing these tasks effectively and to releasing more robust products in standard forms. For ontologies using the Web Ontology Language (OWL), the OWL API Java library is the foundation for a range of software tools, including the Protégé ontology editor. In the Open Biological and Biomedical Ontologies (OBO) community, we recognized the need to package a wide range of low-level OWL API functionality into a library of common higher-level operations and to make those operations available as a command-line tool. RESULTS:ROBOT (a recursive acronym for "ROBOT is an OBO Tool") is an open source library and command-line tool for automating ontology development tasks. The library can be called from any programming language that runs on the Java Virtual Machine (JVM). Most usage is through the command-line tool, which runs on macOS, Linux, and Windows. ROBOT provides ontology processing commands for a variety of tasks, including commands for converting formats, running a reasoner, creating import modules, running reports, and various other tasks. These commands can be combined into larger workflows using a separate task execution system such as GNU Make, and workflows can be automatically executed within continuous integration systems. CONCLUSIONS:ROBOT supports automation of a wide range of ontology development tasks, focusing on OBO conventions. It packages common high-level ontology development functionality into a convenient library, and makes it easy to configure, combine, and execute individual tasks in comprehensive, automated workflows. This helps ontology developers to efficiently create, maintain, and release high-quality ontologies, so that they can spend more time focusing on development tasks. It also helps guarantee that released ontologies are free of certain types of logical errors and conform to standard quality control checks, increasing the overall robustness and efficiency of the ontology development lifecycle.
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.
This report presents work performed in 2017 and is a reissue of the end-of-year report SAND2018-0240, A Proof-of-Concept Approach to DevOps and Microservices, January 2018, modified for unlimited release. This report describes the approach, investigation, and prototyping efforts to create an API management solution and automated deployment pipeline for REST-based microservices. Additionally, it reviews: the microservices created for testing purposes; our experiences and results in using an open-source API management tool; and future plans.
Consistent with the U.S. DOE’s EERE SHINES FOA objectives, the goal of this project was to enable integration from EMS to variable DER in a way that delivered visibility and opportunities for managing and controlling distributed resources using SEAMS technologies. This project implemented several SHINES technologies, which included: (1) three Stem battery systems; (2) six ConnectDER PV collars; (3) two E-Gear PV/Battery storage interfaces; and (4) eight Kitu smart inverter emulators. A Siemens Energy IP DEMS was deployed in a development environment and integrated with the SHINES technologies via OpenADR and IEEE 2030.5 protocols with documented architecture. In the case of IEEE 2030.5, a suite of technologies including a gateway, an API, software and a server from Kitu Systems (the Citadel, Convoy, Kitu Crosslink API, and Kitu Spark) were used to demonstrate that the utility could achieve visibility of distributed energy resources (DER) and control of single and multiple DER systems with a single command. The project also included a LCOE analysis of SHINES technologies compared to traditional system and circuit mitigation measures.
ODBC (Open Database Connectivity) is an industry-standard API (Application Program Interface) that provides a standard interface, based on SQL (Structured Query Language) between applications and databases. This insulates applications from specific details of different database management systems (DBMS). Microsoft Windows TM provides an implementation of ODBC, which, along with drivers for various databases, supports the API. Windows also provides a driver for Access databases.
RAVEN is a generic software framework to perform parametric and probabilistic analysis based on the response of complex system codes. The initial development was aimed to provide dynamic risk analysis capabilities to the Thermo-Hydraulic code RELAP-7, currently under development at the Idaho National Laboratory (INL). Although the initial goal has been fully accomplished, RAVEN is now a multi-purpose probabilistic and uncertainty quantification platform, capable to agnostically communicate with any system code. This agnosticism includes providing Application Programming Interfaces (APIs). These APIs are used to allow RAVEN to interact with any code as long as all the parameters that need to be perturbed are accessible by inputs files or via python interfaces. RAVEN is capable of investigating the system response, and investigating the input space using Monte Carlo, Grid, or Latin Hyper Cube sampling schemes, but its strength is focused to- ward system feature discovery, such as limit surfaces, separating regions of the input space leading to system failure, using dynamic supervised learning techniques. The development of RAVEN has started in 2012, when, within the Nuclear Energy Advanced Modeling and Simulation (NEAMS) program, the need to provide a modern risk evaluation framework became stronger. RAVEN principal assignment is to provide the necessary software and algorithms in order to employ the concept developed by the Risk Informed Safety Margin Characterization (RISMC) program. RISMC is one of the pathways defined within the Light Water Reactor Sustainability (LWRS) program. In the RISMC approach, the goal is not just the individuation of the frequency of an event potentially leading to a system failure, but the closeness (or not) to key safety-related events. Hence, the approach is interested in identifying and increasing the safety margins related to those events. A safety margin is a numerical value quantifying the probability that a safety metric (e.g. for an important process such as peak pressure in a pipe) is exceeded under certain conditions. The initial development of RAVEN has been focused on providing dynamic risk assessment capability to RELAP-7, currently under development at the INL and, likely, future replacement of the RELAP5-3D code. Most the capabilities that have been implemented having RELAP-7 as principal focus are easily deployable for other system codes. For this reason, several side activates are currently ongoing for coupling RAVEN with soft- ware such as RELAP5-3D, etc. The aim of this document is the explanation of the input requirements, focalizing on the input structure.