SEARCH · Search NASA
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 presentation covers a SpaceWire major concern poor Quality of Service (QoS) and provides recommendation to fix SpaceWire QoS for heritage SpaceWire designs.
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 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.6.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 Intersphinx extension automatically linking Jupyter notebook examples to project documentation New end-to-end diagnostics example demonstrated on a real problem New complementarity formulation for VLE with cubic equations of state, backward compatibility for old formulation New solver interface with presolve (ipopt_v2) in support of upcoming changes to the initialization and APIs methods, with default set to ipopt to maintain backwards compatibility; this will deprecate once all examples have been updated New forecaster and parameterized bidder methods within grid integration library Updated surrogates API and examples to support Keras 3, with backwards compatibility for older formats such as TensorFlow SavedModel (TFSM) Updated costing base dictionary to include the 2023 cost year index value Updated ProcessBlock to include information on the constructing block class Updated Flowsheet Visualizer to allow visualize() method to return value and functions Bug Fixes 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. Fixed typos flagged by June update to crate-ci/typos and removed DMF-related exceptions Minor corrections of units of measurement handling in power plant waste/transport costing expressions, control volume material holdup expressions, and BTX property package parameters Fixed throwing >7500 numpy deprecation warnings by replacing scalar value assignment with element extraction and item iteration calls Testing and Robustness Migrated slow tests (>10s) to integration, impacting test coverage but also yielding a nearly 30% decrease in local test runtime Pinned pint to avoid issues with older supported Python versions Pinned codecov versions to avoid tokenless upload behavior with latest version Bumped extensions to version 3.4.2 to allow pointing to non-standard install location Deprecations and Removals Python 3.8 is no longer supported. The supported Python versions are 3.9 through 3.12 The Data Management Framework (DMF) is no longer supported. Importing idaes.core.dmf will cause a deprecation warning to be displayed until the next release The SOFC Keras surrogates have been removed. The current version of the SOFC surrogate model in the examples repository is a PySMO Kriging model.
With the arrival of high luminosity B-factories like the Belle II experiment, τ decay measurements have become more precise than ever, allowing rarer processes to be explored, and finer details of τ decays to be studied. These are important to understand the spectrum of intermediate particles produced in τ decays. Therefore Monte Carlo generators, like the TAUOLA program, have to facilitate precision analysis as well as confront new models that constantly emerge with the availability of high statistics experimental data. New decay channels and models may lead to large variation of matrix elements size within the available phase space, as in the case when e + e - pairs are present in final state. It requires appropriate presampler of the phase space generator and a proper documentation to help users introduce their own models. While releasing a new update, it is important for the TAUOLA Monte Carlo library to maintain the general structure of the previous versions to preserve backward compatibility. The aim is to minimize changes from the user perspective. Finally, this paper presents a demonstration of new models implementation facilitated by the current update.
After using ROOT’s TTree I/O subsystem for over two decades and storing more than an exabyte of compressed High Energy Physics (HEP) data, advances in technology have motivated a complete redesign, RNTuple, which breaks backward-compatibility to take better advantage of these storage options. The RNTuple I/O subsystem has been designed to address performance bottlenecks and other shortcomings of TTree. Specifically, RNTuple comes with an updated, more compact binary data format that can be stored both in ROOT files and natively in object stores. It is designed for modern storage hardware (e.g. high-throughput low-latency NVMe SSDs), and provides robust and easy to use interfaces. The binary format of RNTuple is scheduled to become production grade in 2024, and recently has become mature enough to start exploring the integration into software used by HEP experiments. In this contribution, we discuss the developments to support the features as required by the ATLAS analysis Event Data Model (EDM) in RNTuple, which will enable its integration into the Athena software framework. With these developments in place, we evaluate the performance of the current most recent versions of RNTuple-based ATLAS data sets and compare this to that of TTree.
For several years, the ROOT team is developing the new RNTuple I/O subsystem in preparation of the next generation of collider experiments. Both HL-LHC and DUNE are expected to start data taking by the end of this decade. They pose unprecedented challenges to event data I/O in terms of data rates, event sizes, and event complexity. At the same time, the I/O landscape is becoming more diverse. HPC cluster file systems and object stores, NVMe disk cache layers in analysis facilities, and S3 storage on cloud resources are mixing with traditional XRootD-managed spinning disk pools.The ROOT team will finalize a first production version of the RNTuple binary format by the end of 2024. After this point, ROOT will provide backward compatibility for RNTuple data. This contribution provides an overview of the RNTuple feature set, the related R&D activities and the long-term vision for RNTuple. We report on performance, interface design, tooling, robustness, integration with experiment frameworks, and validation results, as well as recent R&D on parallel reading and writing and exploitation of modern hardware and storage systems. We will give an outlook on possible future features after a first production release.Collaboratively, the IT and EP departments at CERN have launched a formal project within the Research and Computing sector to evaluate the novel data format for physics analysis data utilized in LHC experiments and other fields. This part of the project focuses on validating the scalability of the EOS storage backend during the transition from the over 25 years old TTree production format to the newly developed RNTuple format, using both replicated and erasure-coded storage profiles.
TReactMech couples geomechanical processes (poroelasticity, failure, and inelastic strain) with multiphase nonisothermal flow (derived from TOUGH2) and reactive geochemical transport. At its core is the reactive-transport code TOUGHREACT v4.13. TReactMech is an efficient hybrid parallel simulator, solving the geomechanics using finite elements and MPI/PetSc, the multiphase flow using integrated finite difference and MPI/PETSc, and the reactive chemistry using OpenMP. The advantages of TReactMech are in its multiphase flow capabilities (e.g., supercritical CO2, supercritical water, air) and parallel geomechanics including full 3-D stress tensor, shear and tensile failure, coupled to porosity and permeability changes. It is backwardly compatible with TOUGH2 and TOUGHREACT v4.13, allowing for easier transitions between the codes. TReactMech can be used to simulate many natural and engineered subsurface systems, including geothermal reservoirs, borehole heat exchangers, geologic carbon sequestration, geologic storage of nuclear waste, groundwater resources, weathering, sediment diagenesis, seafloor hydrothermal circulation, hydrofracturing in unconventional reservoirs, and injection/production-induced surface deformation.
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. New features in the 2.2 release include: DiagnosticsToolbox DiagnosticsToolbox (idaes.core.util.model_diagnostics. DiagnosticsToolbox is a new self-guiding toolbox for assisting with diagnosing modeling issues. The toolbox contains a wide range of tools for identifying common modeling issues and conveying these to the user, and more features will be added in the coming months. To try the new toolbox, use the following steps: from idaes.core.util import DiagnosticsToolbox Build an instance of your model Ensure your models has zero degrees of freedom (as best you can) dt = DiagnosticsToolbox(model) dt.report_structural_issues() Follow the prompts Deprecations DegeneracyHunter is being deprecated in favor of the new DiagnosticsToolbox. The features and capabilities of DegeneracyHunter will be moved over to the DiagnositcsToolbox in the coming months. Removal of usage of Pyomo's expr.current due to deprecation upstream. Removed support for radial basis functions in ALAMOpy as these did not work in the current implementation. Those wishing to use radial basis functions should use Pysmo instead. New Capabilities MSContactor model for unit operations involving mass transfer between 2 or more streams, such as membrane, solvent extraction and solids leaching operations. Other Improvements Improved formulation for solubility products with additional parameters for better scaling of terms Better backward compatibility, verification and robustness testing of core models and APIs Added support for Separator models without energy balances
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.1.0 Release Highlights New IDAES Examples Repository Starting with this release, the IDAES examples are developed in the new IDAES/examples repository. Along with many content and usability improvements, the most significant changes are: To install the examples, after installing IDAES, run pip install idaes-examples The idaes get-examples command, previously used for this, has been removed The HTML version is now available at https://idaes-examples.readthedocs.io The previous URL, https://idaes.github.io/examples-pse, will not be updated and may be removed at some point in the future For more details, refer to the resources available at IDAES/examples. Removal of Non-Functional Apps A review of the code in the idaes/apps and idaes/models_extra folders was undertaken, and a number of tools were identified as being outdated or non-functional and no longer supported by their development teams. Due to this, the following tools have been removed: idaes/apps/alamopy_depr (note that the new ALAMOpy interface remains avaialble in idaes/core/surrogates) idaes/apps/helmet idaes/apps/ripe idaes/apps/roundingRegression idaes/models_extra/carbon_capture Pyomo 6.6 This version of IDAES is the first requiring Pyomo 6.6. This version of Pyomo contains multiple internal improvements and refactorings. While for the majority of cases this should have positive or no impact on solvability of IDAES models, we are aware of a small number of models that have been affected as a result of these changes. For more information, refer to the Pyomo 6.6.1 release notes. Other highlights Model Initialization A prototype API for a new approach to initializing IDAES models is now available which makes available some new techniques for initializing models. This is documented in the Initializing Models Reference Guide Modular Properties Framework Support for some transport properties Helmholtz Equation of State properties Better error checking for case where unit models are set to include phase equilibrium but the property package is set to support only a single phase Multi-Stream Contactor model: a new base model for systems involving contacting of two or more streams with mass transfer. This model is intended to be used as the foundation for models such as membrane separators, solvent extraction and other similar processes. This is documented in the Multi-Stream Contactor Reference Guide idaes/models_extra/power_generation report() methods for unit models using Helmholtz equation of state General Code Maintenance Streamlining of dependencies and creation of new optional dependency groupings to support non-core tools General linting of codebase to ensure compliance with most pylint checks Spell checking of all code and doc strings Removal of backward compatibility code for Python 2
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. 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.
The current Timing System at Fermilab has been around for 40 years and currently relies on 7 CAMAC crates and over 100 CAMAC cards to produce the Tevatron Clock (TCLK). Thanks to the ingenuity of those before us, this has allowed Fermilab the flexibility to change the timing and Events for its accelerator as beamlines and projects have changed over the years. With the advent of the Proton Improvement Plan-II (PIP-II), the Timing System at Fermilab is being reimagined into a single chassis with even greater flexibility and functionality for decades to come while tackling the ever-challenging task of maintaining backwards compatibility.
Fermilab is the first High Energy Physics institution to transition from X.509 user certificates to authentication tokens in production systems. All of the experiments that Fermilab hosts are now using JSON Web Token (JWT) access tokens in their grid jobs. Many software components have been either updated or created for this transition, and most of the software is available to others as open source. The tokens are defined using the WLCG Common JWT Profile. Token attributes for all the tokens are stored in the Fermilab FERRY system which generates the configuration for the CILogon token issuer. High security-value refresh tokens are stored in Hashicorp Vault configured by htvault-config, and JWT access tokens are requested by the htgettoken client through its integration with HTCondor. The Fermilab job submission system jobsub was redesigned to be a lightweight wrapper around HTCondor. For automated job submissions a managed tokens service was created to reduce duplication of effort and knowledge of how to securely keep tokens active. The existing Fermilab file transfer tool ifdh was updated to work seamlessly with tokens, as well as the Fermilab POMS (Production Operations Management System) which is used to manage automatic job submission and the RCDS (Rapid Code Distribution System) which is used to distribute analysis code via the CernVM FileSystem. The dCache storage system was reconfigured to accept tokens for authentication in place of X.509 proxy certificates. As some services and sites have not yet implemented token support, proxy certificates are still sent with jobs for backwards compatibility but some experiments are beginning to transition to stop using them. There have been some glitches and learning curve issues but in general the system has been performing well and is being improved as operational problems are addressed.
This white paper outlines potential approaches to supporting special values in the ZFP numerical compressor without breaking backwards compatibility. Other than infinities and NaNs, special values are often used to indicate the absence of data, where no value is defined, for example by designating finite but extreme “fill values” as special. Such fill values are commonly used in earth system science, among other applications, but if left as is during compression lead to artifacts and loss of precision in nearby true values. Multiple candidate solutions that would allow ZFP to recognize special values are here proposed. Until such support is available, we also sketch available workarounds.
In the Space Exploration Initiative (SEI) mission scenarios, expanding human presence is the primary driver for high data rate Mars-Earth communications. To support an expanding human presence, the data rate requirement will be gradual, following the phased implementation over time of the evolving SEI mission. Similarly, the growth and evolution of the space communications infrastructure to serve this requirement will also be gradual to efficiently exploit the useful life of the installed communications infrastructure and to ensure backward compatibility with long-term users. In work conducted over the past year, a number of alternatives for supporting high data rate Mars-Earth communications have been analyzed with respect to their compatibility with gradual evolution of the space communications infrastructure. The alternatives include RF, millimeter wave (MMW), and optical implementations, and incorporate both surface and space-based relay terminals in the Mars and Earth regions. Each alternative is evaluated with respect to its ability to efficiently meet a projected growth in data rate over time, its technology readiness, and its capability to satisfy the key conditions and constraints imposed by evolutionary transition. As a result of this analysis, a set of attractive alternative communications architectures have been identified and described, and a road map is developed that illustrates the most rational and beneficial evolutionary paths for the communications infrastructure.
Over the next decade, international plans and commitments are underway to develop an infrastructure at Mars to support future exploration of the red planet. The purpose of this infrastructure is to provide reliable global communication and navigation coverage for on-approach, landed, roving, and in-flight assets at Mars. The claim is that this infrastructure will: 1) eliminate the need of these assets to carry Direct to Earth (DTE) communications equipment, 2) significantly increase data return and connectivity, 3) enable small mission exploration of Mars without DTE equipment, 4) provide precision navigation i.e., 10 to 100m position resolution, 5) supply timing reference accurate to 10ms. This paper in particular focuses on two CCSDS recommendations for that infrastructure: CCSDS Proximity-1 Space Link Protocol and CCSDS File Delivery Protocol (CFDP). A key aspect of Mars exploration will be the ability of future missions to interoperate. These protocols establish a framework for interoperability by providing standard communication, navigation, and timing services. In addition, these services include strategies to recover gracefully from communication interruptions and interference while ensuring backward compatibility with previous missions from previous phases of exploration.
To accommodate a wide spectrum of applications and technologies, NASA s Exploration System's Missions Directorate has called for reconfigurable and modular technologies to support future missions to the moon and Mars. In response, Langley Research Center is leading a program entitled Reconfigurable Scaleable Computing (RSC) that is centered on the development of FPGA-based computing resources in a stackable form factor. This paper details the architecture and implementation of the Reconfigurable Processing Module (RPM), which is the key element of the RSC system. The RPM is an FPGA-based, space-qualified printed circuit assembly leveraging terrestrial/commercial design standards into the space applications domain. The form factor is similar to, and backwards compatible with, the PCI-104 standard utilizing only the PCI interface. The size is expanded to accommodate the required functionality while still better than 30% smaller than a 3U CompactPCI(TradeMark)card and without the overhead of the backplane. The architecture is built around two FPGA devices, one hosting PCI and memory interfaces, and another hosting mission application resources; both of which are connected with a high-speed data bus. The PCI interface FPGA provides access via the PCI bus to onboard SDRAM, flash PROM, and the application resources; both configuration management as well as runtime interaction. The reconfigurable FPGA, referred to as the Application FPGA - or simply "the application" - is a radiation-tolerant Xilinx Virtex-4 FX60 hosting custom application specific logic or soft microprocessor IP. The RPM implements various SEE mitigation techniques including TMR, EDAC, and configuration scrubbing of the reconfigurable FPGA. Prototype hardware and formal modeling techniques are used to explore the performability trade space. These models provide a novel way to calculate quality-of-service performance measures while simultaneously considering fault-related behavior due to SEE soft errors.
The RTSJ is a specification for supporting real-time execution in the Java programming language. The specification has been shaped by several guiding principles, particularly: predictable execution as the first priority in all tradeoffs, no syntactic extensions to Java, and backward compatibility.
An approach is defined that describes a method of iterating over massively large arrays containing sparse data using an approach that is implementation independent of how the contents of the sparse arrays are laid out in memory. What is unique and important here is the decoupling of the iteration over the sparse set of array elements from how they are internally represented in memory. This enables this approach to be backward compatible with existing schemes for representing sparse arrays as well as new approaches. What is novel here is a new approach for efficiently iterating over sparse arrays that is independent of the underlying memory layout representation of the array. A functional interface is defined for implementing sparse arrays in any modern programming language with a particular focus for the Chapel programming language. Examples are provided that show the translation of a loop that computes a matrix vector product into this representation for both the distributed and not-distributed cases. This work is directly applicable to NASA and its High Productivity Computing Systems (HPCS) program that JPL and our current program are engaged in. The goal of this program is to create powerful, scalable, and economically viable high-powered computer systems suitable for use in national security and industry by 2010. This is important to NASA for its computationally intensive requirements for analyzing and understanding the volumes of science data from our returned missions.