Results for “process systems engineering” — Page 6

NASA NTRS2019

Recommendation for a Medical System Concept of Operations for Gateway Missions

NASA’s exploration missions to cis-lunar space will establish a permanent gateway to future transport missions to Mars. These missions mandate a significant paradigm change for mission planning, spacecraft design, human systems integration, and in-flight medical care due to constraints on mass, volume, power, resupply, and medical evacuation capability. These constraints require medical system development to be tightly integrated with mission and habitat design to provide a sufficient medical infrastructure and enable mission success. This concept of operations provides a vision of medical care needs that will be used to guide the development of a medical system for the cis-lunar Gateway Habitat. This medical system will serve as the precursor to what is implemented in future exploration missions to Mars. This concept of operations documents an overview of the stakeholder needs and system goals of a medical system and provides examples of the types of activities for which the system will be used during the mission. This concept of operations informs the ExMC systems engineering effort to define the Gateway Habitat Medical System by documenting the medical activities and capabilities relevant to Gateway missions, as identified by the ExMC clinician community. In addition, this concept of operations will inform the subsequent systems engineering process of developing technical requirements, system architectures, interfaces, and verification and validation approaches for the medical system. This document supports the closure of ExMC Gap Med01: We do not have a concept of operations for medical care during exploration missions, corresponding to the ExMC-managed human system risk: Risk of Adverse Health Outcomes & Decrements in Performance due to Inflight Medical Conditions.

Rubin, David↗

NASA NTRSDate not supplied

Exploration Medical Capability Science and Research Overview and Update

The mission of the Exploration Medical Capability (ExMC) Element is to advance medical system design and risk-informed decision making for exploration beyond Low Earth Orbit to promote human health and performance in space. To accomplish this mission, ExMC focuses on several key areas: • Investigating specific risks that are relevant for human exploration spaceflight, including in-flight medical conditions, degraded or toxic medications, and renal stones • Developing medical probabilistic risk analysis tools that are integrated with systems engineering processes to inform the medical system trade space and support the development of robust requirements • Demonstrating and defining requirements for a prototype clinical decision support system • Developing and demonstrating novel medical technologies that will improve future medical capabilities in space This presentation will focus on selected scientific and technical conceptual drivers for the Element and its current and future research risks and gaps while providing an overview of the Element’s progress in 2021 and areas of focus for 2022.

Benjamin Easter↗

NASA NTRS2017

Life Support Goals Including High Closure and Low Mass Should Be Reconsidered Using Systems Analysis

Recycling space life support systems have been built and tested since the 1960s and have operated on the International Space Station (ISS) since the mid 2000s. The development of space life support has been guided by a general consensus focused on two important related goals, increasing system closure and reducing launch mass. High closure is achieved by recycling crew waste products such as carbon dioxide and condensed humidity. Recycling directly reduces the mass of oxygen and water for the crew that must be launched from Earth. The launch mass of life support can be further reduced by developing recycling systems with lower hardware mass and reduced power. The life support consensus has also favored using biological systems. The goal of increasing closure using biological systems suggests that food should be grown in space and that biological processors be used for air, water, and waste recycling. The goal of reducing launch mass led to use of Equivalent System Mass (ESM) in life support advocacy and technology selection. The recent consensus assumes that the recycling systems architecture developed in the 1960s and implemented on ISS will be used on all future long missions. NASA and other project organizations use the standard systems engineering process to guide hardware development. The systems process was used to develop ISS life support, but it has been less emphasized in planning future systems for the moon and Mars. Since such missions are far in the future, there has been less immediate need for systems engineering analysis to consider trade-offs, reliability, and Life Cycle Cost (LCC). Preliminary systems analysis suggests that the life support consensus concepts should be revised to reflect systems engineering requirements.

systems analysis↗

NASA NTRS2000

Applying Technology Ranking and Systems Engineering in Advanced Life Support

According to the Advanced Life Support (ALS) Program Plan, the Systems Modeling and Analysis Project (SMAP) has two important tasks: 1) prioritizing investments in ALS Research and Technology Development (R&TD), and 2) guiding the evolution of ALS systems. Investments could be prioritized simply by independently ranking different technologies, but we should also consider a technology's impact on system design. Guiding future ALS systems will require SMAP to consider many aspects of systems engineering. R&TD investments can be prioritized using familiar methods for ranking technology. The first step is gathering data on technology performance, safety, readiness level, and cost. Then the technologies are ranked using metrics or by decision analysis using net present economic value. The R&TD portfolio can be optimized to provide the maximum expected payoff in the face of uncertain future events. But more is needed. The optimum ALS system can not be designed simply by selecting the best technology for each predefined subsystem. Incorporating a new technology, such as food plants, can change the specifications of other subsystems, such as air regeneration. Systems must be designed top-down starting from system objectives, not bottom-up from selected technologies. The familiar top-down systems engineering process includes defining mission objectives, mission design, system specification, technology analysis, preliminary design, and detail design. Technology selection is only one part of systems analysis and engineering, and it is strongly related to the subsystem definitions. ALS systems should be designed using top-down systems engineering. R&TD technology selection should consider how the technology affects ALS system design. Technology ranking is useful but it is only a small part of systems engineering.

Jones, Harry↗

NASA NTRSDate not supplied

Development of a Human Systems Integration Plan

NASA defines Human Systems Integration (HSI) as part of the overall systems engineering and acquisition strategy for space systems. The HSI Plan defines how HSI activities will be implemented across the lifecycle of the mission, as required by NPR 7123.1C, NASA Systems Engineering Processes and Requirements, and NPR 8705.2C Human-Rating Requirements for Space Systems. The goal of this presentation is to share with government and industry how an HSI Plan can be implemented. The presentation will cover HSI implementation for flight systems, vehicle processing, and interfaces. These are divided into six NASA HSI Domains: human factors engineering, operations resources, safety, training, maintainability and supportability, habitability and environment. HSI activities go across the mission’s lifecycle from pre-formulation and acquisition through design, development, operations, maintenance, and decommissioning. The HSI Plan includes a description of the HSI activities and products that are essential for human rating, operability, maintainability, supportability, and affordability of the mission systems. It also describes the role of the HSI Team required as part of the Human Rating process. The HSI Plan utilizes the operational expertise within NASA to ensure designs and testing are successful, leading to acceptable human spaceflight vehicles.

Jackelynne Silva-Martinez↗

NASA NTRS2012

Requirements Flowdown for Prognostics and Health Management

Prognostics and Health Management (PHM) principles have considerable promise to change the game of lifecycle cost of engineering systems at high safety levels by providing a reliable estimate of future system states. This estimate is a key for planning and decision making in an operational setting. While technology solutions have made considerable advances, the tie-in into the systems engineering process is lagging behind, which delays fielding of PHM-enabled systems. The derivation of specifications from high level requirements for algorithm performance to ensure quality predictions is not well developed. From an engineering perspective some key parameters driving the requirements for prognostics performance include: (1) maximum allowable Probability of Failure (PoF) of the prognostic system to bound the risk of losing an asset, (2) tolerable limits on proactive maintenance to minimize missed opportunity of asset usage, (3) lead time to specify the amount of advanced warning needed for actionable decisions, and (4) required confidence to specify when prognosis is sufficiently good to be used. This paper takes a systems engineering view towards the requirements specification process and presents a method for the flowdown process. A case study based on an electric Unmanned Aerial Vehicle (e-UAV) scenario demonstrates how top level requirements for performance, cost, and safety flow down to the health management level and specify quantitative requirements for prognostic algorithm performance.

video acuity↗

NASA NTRS2012

Integrating Engineering Data Systems for NASA Spaceflight Projects

NASA has a large range of custom-built and commercial data systems to support spaceflight programs. Some of the systems are re-used by many programs and projects over time. Management and systems engineering processes require integration of data across many of these systems, a difficult problem given the widely diverse nature of system interfaces and data models. This paper describes an ongoing project to use a central data model with a web services architecture to support the integration and access of linked data across engineering functions for multiple NASA programs. The work involves the implementation of a web service-based middleware system called Data Aggregator to bring together data from a variety of systems to support space exploration. Data Aggregator includes a central data model registry for storing and managing links between the data in disparate systems. Initially developed for NASA's Constellation Program needs, Data Aggregator is currently being repurposed to support the International Space Station Program and new NASA projects with processes that involve significant aggregating and linking of data. This change in user needs led to development of a more streamlined data model registry for Data Aggregator in order to simplify adding new project application data as well as standardization of the Data Aggregator query syntax to facilitate cross-application querying by client applications. This paper documents the approach from a set of stand-alone engineering systems from which data are manually retrieved and integrated, to a web of engineering data systems from which the latest data are automatically retrieved and more quickly and accurately integrated. This paper includes the lessons learned through these efforts, including the design and development of a service-oriented architecture and the evolution of the data model registry approaches as the effort continues to evolve and adapt to support multiple NASA programs and priorities.

Carvalho, Robert E.↗

NASA NTRS2011

Multi-Center Implementation of NPR 7123.1A: A Collaborative Effort

Collaboration efforts between MSFC and GRC Engineering Directorates to implement the NASA Systems Engineering (SE) Engine have expanded over the past year to include other NASA Centers. Sharing information on designing, developing, and deploying SE processes has sparked further interest based on the realization that there is relative consistency in implementing SE processes at the institutional level. This presentation will provide a status on the ongoing multi-center collaboration and provide insight into how these NPR 7123.1A SE-aligned directives are being implemented and managed to better support the needs of NASA programs and projects. NPR 7123.1A, NASA Systems Engineering Processes and Requirements, was released on March 26, 2007 to clearly articulate and establish the requirements on the implementing organization for performing, supporting, and evaluating SE activities. In early 2009, MSFC and GRC Engineering Directorates undertook a collaborative opportunity to share their research and work associated with developing, updating and revising their SE process policy to comply and align with NPR 7123.1A. The goal is to develop instructions, checklists, templates, and procedures for each of the 17 SE process requirements so that systems engineers will be a position to define work that is process-driven. Greater efficiency and more effective technical management will be achieved due to consistency and repeatability of SE process implementation across and throughout each of the NASA centers. An added benefit will be to encourage NASA centers to pursue and collaborate on joint projects as a result of using common or similar processes, methods, tools, and techniques.

Hall, Phillip B.↗

NASA NTRS2016

A Tailored Concept of Operations for NASA LSP Integrated Operations

An integral part of the Systems Engineering process is the creation of a Concept of Operations (ConOps) for a given system, with the ConOps initially established early in the system design process and evolved as the system definition and design matures. As Integration Engineers in NASA's Launch Services Program (LSP) at Kennedy Space Center (KSC), our job is to manage the interface requirements for all the robotic space missions that come to our Program for a Launch Service. LSP procures and manages a launch service from one of our many commercial Launch Vehicle Contractors (LVCs) and these commercial companies are then responsible for developing the Interface Control Document (ICD), the verification of the requirements in that document, and all the services pertaining to integrating the spacecraft and launching it into orbit. However, one of the systems engineering tools that have not been employed within LSP to date is a Concept of Operations. The goal of this project is to research the format and content that goes into these various aerospace industry ConOps and tailor the format and content into template form, so the template may be used as an engineering tool for spacecraft integration with future LSP procured launch services.

Systems↗

NASA NTRS2017

Tailoring a ConOps for NASA LSP Integrated Operations

An integral part of the Systems Engineering process is the creation of a Concept of Operations (ConOps) for a given system, with the ConOps initially established early in the system design process and evolved as the system definition and design matures. As Integration Engineers in NASA's Launch Services Program (LSP) at Kennedy Space Center (KSC), our job is to manage the interface requirements for all the robotic space missions that come to our Program for a Launch Service. LSP procures and manages a launch service from one of our many commercial Launch Vehicle Contractors (LVCs) and these commercial companies are then responsible for developing the Interface Control Document (ICD), the verification of the requirements in that document, and all the services pertaining to integrating the spacecraft and launching it into orbit. However, one of the systems engineering tools that have not been employed within LSP to date is a Concept of Operations. The goal of this paper is to research the format and content that goes into these various aerospace industry ConOps and tailor the format and content into template form, so the template may be used as an engineering tool for spacecraft integration with future LSP procured launch services. This tailoring effort was performed as the authors final Masters Project in the Spring of 2016 for the Stevens Institute of Technology and modified for publication with INCOSE (Owens, 2016).

Knowledge↗

NASA NTRS1994

Improving cost efficiency in large programs

This paper examines the question of cost, from the birth of a program to its conclusion, particularly from the point of view of large multi-center programs, and suggests how to avoid some of the traps and pitfalls. Emphasis is given to cost in the systems engineering process, but there is an inevitable overlap with program management. (The terms systems engineering and program management have never been clearly defined.) In these days of vast Federal budget deficits and increasing overseas competition, it is imperative that we get more for each research and development dollar. This is the only way we will retain our leadership in high technology and, in the long run, our way of life.

Hodge, John D.↗

NASA NTRS2022

Design Thinking, Lean Startup, and High-Technology Marketing for Human-Centered Systems Engineering

The use of design thinking, lean startup, and high-technology marketing in systems engineering are presented as a case study. All were used and evaluated for their potential to improve systems engineering processes and design, address the challenges of culture change, increase the adoption rate of new technology, and engage with potential users and sponsors more effectively. Multiple examples of training and use on a model-based systems engineering initiative at a large government agency showcase how these approaches were tailored and used successfully for significant benefits such as enhanced collaboration and better problem definition and design solutions. Challenges remain for use by quiet thinkers and with virtual teams. These new ways of thinking are well aligned with creating and using new technologies and are suitable for situations involving innovation, uncertainty, and change within organizations. This case study intends to familiarize systems engineers with the application of these human-centered approaches, to interest systems engineers in incorporating these approaches into their work processes ,and to inspire the systems engineering research community to investigate further.

Karen J. Weiland↗

DOE OSTI2024

IDAES-PSE 2.6.0 Release

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.

AS↗

DOE OSTI2024

IDAES-PSE 2.7.0 Release

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.7.0 Release Highlights New features: AutoScaler and CustomScalerBase classes: Such tools are the core of the new scaling framework being implemented in IDAES. Wider adoption of scaling tools among users will result in quicker and more robust model solutions. Scaler for equilibrium reactor and saponification properties: These scaler models are examples to follow for how to use the new scaling tools. ONNX Surrogate support from Optimization & Machine Learning Toolkit (OMLT): ONNX is an open standard format to save and load ML/AI models that is widely supported by all major frameworks. This capability makes it easier for IDAES users to create surrogate models and use them without having to support each framework individually. 1D Membrane Model for CO2 Capture and Utilization: Supports ongoing efforts for modeling and optimizing polymer membrane processes for CO2 capture and conversion into formic acid. StreamScaler unit model: Unrelated to the CustomScalerBase, this unit model allows a stream’s extensive variables to be scaled by a fixed factor. This allows streams being processed by multiple units in parallel to be scaled down to unit scale and scaled back up to process scale. Bug fixes or improvements: Scaling, EoS, Diagnostics tool, Modular Properties, tests & documentation Deprecations: Old Cubic EoS

AS↗

DOE OSTI2025

IDAES-PSE 2.8.0 Release

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.

AS↗

DOE OSTI2023

IDAES-PSE 2.2.0 Release

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

DiagnosticsToolbox↗

DOE OSTI2023

IDAES-PSE 2.1.0 Release

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

IDAES↗

DOE OSTI2023

IDAES-PSE 2.0 Release

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

IDAES↗